none
Les "20 Security Best Practices" que vous devez connaître avant de déployer vos Domain Controllers sur Azure | Contribution TechNet

    Discussion générale

  •  

    Suite à la réalisation de plusieurs audits Azure chez différents clients grand comptes (Banques, Assurances, ...etc), j'ai pu constaté que la plupart de leurs DC (Domain Controllers AD) hébergés dans le Cloud Azure (sous forme de VM Azure : mode Infra-as-a-Service), n'ont pas été Setupés, configurés et protégés correctement.

    Plusieurs "Best Practices" relatives à l'exécution des Domain Controllers sur Azure (VM) sont souvent "oubliés" et rarement pris en considération lors de la phase "Build/Implementation".

    Si vous avez décidé d'étendre votre infrastructure AD vers Azure, je vous invite à prendre connaissance des items détaillés ci-dessous avant de vous lancer dans la création/build de VMs DCs.

    Note : Le terme "Étendre" ici fait référence à un nouveau site distant (Site Active Directory) qui sera simplement le VNET/Subnet Azure et non pas la synchronisation d'annuaires : AD to AAD (Azure AD).

     

    Liste des "Best Practices" que vous devez connaître avant de déployer vos DCs sur Azure (VM)
    • #1 : Tout d'abord, bien lire le guide "Guidelines for Deploying Windows Server Active Directory on Azure Virtual Machines" proposé par MS. Ce document vous détaille et explique bien la différence entre le déploiement d'infrastructure AD OnPrem (Infra AD traditionnelle) et le déploiement des Contrôleurs de domaine sur Azure (sur VM, connectées à des VNET/Réseaux Virtuels Azure). Je vous invite à prendre le temps de lire et comprendre tous les items détaillés dans cet article.
    • #2 : Déployez au moins deux Contrôleurs de domaine AD (2 VMs Azure)
    • #3 : Créez un Groupe à Haute Disponibilité (Availability Set) et placez-y vos Contrôleurs de domaine (au moins 2 DCs) : consulter cet article pour en savoir plus.
    • #4 : Déployez des Contrôleurs de domaine en mode "Core" plutôt qu'en mode GUI (Graphical User Interface)
      • HK Recommendation : pensez à déployer des DCs en mode Core avec un full remote management (via RSAT depuis un Bastion Environnement). Si vous déployez encore des DC sous Windows Server 2012 ou 2012 R2, vous pouvez déployer des DCs en mode MSI (Core + Minimal Server Interface > All GUI Tools)
        • Note : je vous invite à consulter cet article pour en savoir plus sur les différents modes : GUI | MSI | Core
    • #5 : Déployez des RODC (Read-Only Domain Controller) plutôt que des WDC (Writable Domain Controller)
      • Note importante : avant de déployer des RODC, vérifiez que vous Applications (à intégrer dans l'AD) supportent bien ce type de DC. Si vos Apps ont besoin d'écrire dans la base AD, déployez plutôt des WDC. Je vous invite à consulter cet article si vous avez besoin de tester la comptabilité de vos applications avec le RODC.
    • #6 : Ensuite, (TRES, TRES IMPORTANT), configurez des @IP Statiques sur vos DCs, cela doit se faire via le Portail Azure, PowerShell ou Azure CLI (depuis les Propriétés de la NIC de la VM DC) et non pas via les propriétés TCP/IP v4 de la Guest NIC :
      • Tips : vous pouvez configurer l'adresse IP (Statique) sur vos DCs via :
        • Le Portail Azure : consulter cet article pour en savoir plus.
        • Windows PowerShell [Module PS Azure] : consulter cet article pour en savoir plus.
        • Azure CLI [commande az vm]: consulter cet article pour en savoir plus.
    • #7 : Créer/Utiliser un Compte de Stockage Azure dédié pour stocker les vDisks (VHD) des Domain Controllers
    • #8 : En plus du vDisk OS créé/attaché à la VM automatiquement lors de sa création/provisioning, il est important de créer/attacher un nouveau vDisk à la VM DC (Data Disk) pour y stocker/placer la base de données AD, Fichiers Logs,SYSVOL 
    • #9 NE JAMAIS configurer de "Host Cache Prerence", lors de l'ajout du nouveau vDisk DATA (Disque de données pour AD Database, Logs & SySVOL), choisissez "None" comme valeur.
    • #10 : Utiliser les fonctionnalités RBAC (Role-Based Access Control /Contrôle d'accès en fonction du rôle) pour limiter/contrôler QUI doit ACCEDER/GERER le compte de Stockage and les clés d'accès
    • #11 : Activer le chiffrement de disque Azure (Azure Disk Encryption) avec une clé de chiffrement (KEK : Key Encryption key) pour les disques systèmes (OS vDisk) mais aussi les disques de données (Data vDisk). Azure Key Vault sera utilisé pour stocker les clés, il doit être déployé/hébergé dans la même Région & Abonnement Azure
    • #12 : Même chose pour Le coffre Key Vault, pensez à définir/implémenter une stratégie RBAC pour limiter l'accès au Key Vault stockant vos clés.
    • #13 : A l'aide d'un NSG (Network Security Group), créez et configurer des règles pour :
      • Autoriser que le traffic "Entrant" requis (Ports requis) pour les Domain Controllers
      • Refuser tout autre traffic
    • #14 : Implémentez des règles AppLocker pour autoriser que les .EXE, scripts... requis/utilisés par les DCs
    • #15 : NE JAMAIS créer/définir une @IP public pour les VMs faisant office de Domain Controllers.
    • #16 : Et bien évidemment, ne jamais activer le RDP (Remote Desktop Protocol) sur les DCs, pour réduire la surface d'attaque, et puis, on est d'accord, ce sont des DCs et non pas des serveurs RDS ou Citrix XA :).
    • #17 : Déployer et configurer l'agent Antimalware (en suivant votre standard OnPrem)
    • #18 : Déployer et configurer l'agent de monitoring (en suivant votre standard OnPrem)
    • #19 : Si votre architecture réseau le permet, implémentez une IPSec Policy pour sécuriser les communications entre vos DCs OnPrem et ceux sur Azure.
    • #20 : Et enfin, veillez à bien documenter toutes les options/fonctionnalités de sécurité implémentées, ainsi que toute modification apportée, cela vous permettra d'identifier les effets de bord/impacts post-implémentation d'une ou plusieurs Security Features spécifiques. e.g : mauvaise implémentation d'IPSec peut avoir un impact sur toute la communication inter-site (deny any<>any by default).

    A bientôt, Keep in touch :).

    #HK | Another IT Guy | https://hichamkadiri.wordpress.com


    Hicham KADIRI | Just Another IT Guy
    Livre de référence RDS 2012 R2 désormais disponible !
    RDS 2012 R2 reference book is now available !
    Découvrez tous mes eBooks )

    vendredi 23 février 2018 12:30

Toutes les réponses