Ce guide présente les bonnes pratiques d'exécution d'Active Directory sur Google Cloud. Il est consacré aux pratiques spécifiques à Google Cloud ou particulièrement importantes lors du déploiement d'Active Directory sur Google Cloud. Il constitue un complément aux bonnes pratiques publiées par Microsoft pour sécuriser Active Directory.
Architecture
Les sections suivantes décrivent les bonnes pratiques liées à l'architecture.
Choisir le modèle d'architecture qui répond le mieux à vos besoins
Pour déployer Active Directory sur Google Cloud, vous devez d'abord déterminer quelle architecture de domaine et de forêt utiliser. Si vous vous servez déjà d'Active Directory, vous devez également décider si vous intégrez les deux environnements, et la façon de procéder.
La conception qui correspond le mieux à votre situation dépend d'un certain nombre de facteurs, y compris la conception de votre réseau sur site, la façon dont les ressources Google Cloud et sur site interagissent, ainsi que vos exigences en termes de disponibilité et d'autonomie administrative. Consultez nos modèles pour l'utilisation d'Active Directory dans un environnement hybride pour découvrir la façon dont ces facteurs doivent déterminer votre conception.
Si vous souhaitez maintenir une limite de confiance entre Google Cloud et votre environnement sur site, envisagez de mettre en œuvre le modèle de forêt de ressources. Celui-ci vous permet de déployer une forêt distincte sur Google Cloud, et d'établir une approbation de forêt à sens unique pour intégrer la forêt Google Cloud à votre forêt Active Directory existante sur site.
Distinguer les tests de la production
Selon votre utilisation d'Active Directory, il peut être nécessaire d'y apporter des modifications fréquentes pendant le développement et les tests des applications. Les développeurs doivent pouvoir créer et modifier des comptes Active Directory, modifier les appartenances aux groupes si les applications en utilisent pour gérer les autorisations, ou associer et supprimer des ordinateurs.
Pour éviter que les tâches de développement et de test n'affecte les charges de travail de production ou n'entrave la sécurité de votre déploiement, envisagez de déployer une forêt ou un domaine Active Directory distinct pour le développement et les tests.
Cela vous permet également de valider les modifications administratives avant de les appliquer en production. Par exemple, de tels changements incluent l'expérimentation de stratégies de groupe, des tests sur les scripts d'automatisation ou les actions potentiellement risquées, telles que l'augmentation du niveau fonctionnel d'une forêt.
Configurer la fédération Cloud Identity en plus de déployer Active Directory sur Google Cloud
Le déploiement d'Active Directory sur Google Cloud vous permet de gérer les VM Windows sur Google Cloud, de vous connecter à celles-ci avec vos comptes utilisateur existants, et d'assurer la compatibilité avec les applications qui s'appuient sur Kerberos, NTLM ou LDAP pour l'authentification.
Cependant, vous devez vous authentifier avec une identité Google pour utiliser Google Cloud Console, l'outil de ligne de commande gcloud ou d'autres outils Google et Google Cloud. Le déploiement d'Active Directory sur Google Cloud ne remplace donc pas la fédération de votre domaine Active Directory existant avec Google Cloud si vous avez l'intention d'utiliser Active Directory en tant que système principal de gestion des utilisateurs.
Par exemple, si vous déployez une forêt distincte sur Google Cloud, vous pouvez configurer la fédération sur votre forêt Active Directory sur site, comme illustré dans le schéma suivant. Les utilisateurs disposant de comptes dans la forêt Active Directory sur site peuvent ensuite utiliser des outils nécessitant une identité Google ainsi que les applications qui s'appuient sur Active Directory pour l'authentification.
Si vous préférez étendre votre forêt ou votre domaine existant à Google Cloud, vous pouvez également configurer la fédération à l'aide de contrôleurs de domaine et de serveurs AD FS déployés sur Google Cloud.
La fédération vous permet également d'appliquer un cycle de vie courant pour les comptes Google et Active Directory. Ainsi, lorsque vous désactivez un compte utilisateur dans votre forêt Active Directory sur site, l'utilisateur Google correspondant est également suspendu.
Mise en réseau
La section suivante décrit les bonnes pratiques liées à la mise en réseau.
Déployer Active Directory dans un réseau VPC partagé
Pour pouvoir utiliser Active Directory dans plusieurs projets, déployez des contrôleurs de domaine dans un réseau VPC partagé. L'utilisation d'un réseau VPC partagé présente plusieurs avantages :
Chaque application pouvant nécessiter un accès à Active Directory peut potentiellement être déployée dans un projet distinct. Vous pouvez ainsi isoler les ressources et gérer l'accès individuellement.
Vous pouvez utiliser un projet dédié pour les contrôleurs de domaine Active Directory, ce qui vous permet de contrôler précisément quels utilisateurs peuvent accéder aux ressources Google Cloud associées.
Les réseaux VPC partagés vous permettent de centraliser la gestion des adresses IP et la configuration des pare-feu pour assurer la cohérence entre plusieurs projets.
Comme les VPC sont des ressources globales, vous pouvez utiliser le même réseau VPC partagé dans plusieurs régions.
Ne pas exposer les contrôleurs de domaine en externe
Pour réduire la surface d'attaque d'Active Directory, évitez d'attribuer des adresses IP externes aux contrôleurs de domaine.
Étant donné que les instances de VM sans adresses IP externes n'ont pas d'accès à Internet par défaut, vous devez prendre des mesures supplémentaires pour vous assurer que l'activation de Windows et ses mises à jour ne sont pas altérées sur les contrôleurs de domaine.
Pour assurer la compatibilité avec l'activation de Windows, activez l'accès privé à Google sur le sous-réseau dans lequel vous prévoyez de déployer des contrôleurs de domaine et assurez-vous que les instances de VM peuvent accéder à kms.windows.googlecloud.com. Vous pouvez ainsi procéder à l'activation sans accès direct à Internet.
Plusieurs options permettent de gérer les mises à jour Windows :
Si vous disposez d'un serveur WSUS sur site, vous pouvez configurer la connectivité hybride et vos contrôleurs de domaine de sorte que le serveur WSUS soit utilisé comme source pour les mises à jour.
Vous pouvez activer l'accès à Internet via une passerelle NAT en déployant Cloud NAT.
Si vous avez configuré la connectivité hybride, vous pouvez également acheminer le trafic sortant via une passerelle NAT ou un serveur proxy sur site.
Réserver à l'avance des adresses IP statiques pour les contrôleurs de domaine
Étant donné que les contrôleurs de domaine servent de serveurs DNS, ils doivent être dotés d'une adresse IP qui ne change pas. Pour ce faire, réservez et attribuez des adresses IP internes statiques aux VM du contrôleur de domaine.
Lorsque vous réservez une adresse IP, une adresse non utilisée est choisie automatiquement par défaut. Pour vous assurer que les adresses IP des contrôleurs de domaine sont faciles à mémoriser, réservez une adresse IP statique interne.
Sur les contrôleurs de domaine, définissez l'adresse IP de la carte réseau sur la même adresse. Bien que cette étape soit facultative, elle empêche Active Directory d'envoyer des messages d'avertissement indiquant que l'adresse IP de la machine peut toujours être attribuée de manière dynamique.
Déployer des contrôleurs de domaine sur plusieurs zones
Pour augmenter la disponibilité, déployez au moins deux contrôleurs de domaine répartis sur plusieurs zones. Étant donné que les sous-réseaux et les adresses IP ne sont pas liés à une zone, vous pouvez déployer tous les contrôleurs de domaine dans un seul sous-réseau.
Si vous prévoyez de déployer des charges de travail sur plusieurs régions, envisagez de déployer des contrôleurs de domaine dans chaque région pertinente. Les sous-réseaux étant des ressources régionales, le déploiement dans une autre région nécessite un sous-réseau supplémentaire.
Créer un site par région
Lorsqu'un client essaie de localiser un contrôleur de domaine, il le recherche d'abord sur le site Active Directory qui correspond à l'adresse IP du client. Si aucun contrôleur de domaine n'est disponible sur ce site, le client continue sa recherche et tente de localiser un contrôleur de domaine sur un autre site.
Vous pouvez exploiter ce comportement en créant un site distinct pour chaque région dans laquelle vous déployez des contrôleurs de domaine ou des clients de domaine. Les clients préfèrent alors utiliser automatiquement des contrôleurs de domaine situés dans la même région, ce qui peut aider à réduire la latence et les coûts liés au transfert de données sortantes entre les régions.
Si des clients de certaines régions ne disposent pas d'un contrôleur de domaine, vous pouvez influencer le choix des contrôleurs de domaine par ces clients en ajustant les coûts des liens sitelink pour refléter la proximité géographique des régions et en activant le paramètre Essayer le site le plus proche suivant.
L'utilisation de plusieurs sites influence le comportement de réplication entre les contrôleurs de domaine. Cette méthode présente un inconvénient, à savoir que la réplication entre sites peut se produire moins fréquemment que la réplication intra-site.
Toutefois, vous ne pouvez pas créer de sites Active Directory dans le service Microsoft AD géré, car ce dernier n'est pas compatible avec la fonctionnalité de sites et de services Active Directory.
Utiliser les zones de transfert privées Cloud DNS
Lorsque vous créez une instance de VM dans Compute Engine, le système d'exploitation est préconfiguré pour utiliser un serveur DNS par défaut donnant accès au DNS interne et au DNS public.
Avant de pouvoir associer une machine à un domaine Active Directory, vous devez vous assurer que la machine est capable de résoudre les enregistrements DNS gérés par Active Directory. Le serveur DNS par défaut configuré par Compute Engine pour une instance de VM permet d'accéder au DNS interne et au DNS public, mais ne peut pas résoudre les noms DNS gérés par Active Directory.
Vous devez créer une zone de transfert DNS privée dans Cloud DNS pour permettre aux clients de résoudre les enregistrements DNS gérés par Active Directory. Configurez la zone afin de transférer les requêtes correspondant à votre domaine Active Directory vers vos contrôleurs de domaine.
L'utilisation d'une zone de transfert DNS privée présente plusieurs avantages par rapport à la configuration des clients pour utiliser directement les contrôleurs de domaine Active Directory en tant que serveurs DNS :
Vous n'avez pas besoin d'ajuster la configuration de mise en réseau des instances de VM. Cela simplifie le processus de création de VM.
Lorsque vous promouvez ou rétrogradez un contrôleur de domaine, il vous suffit de mettre à jour la configuration de la zone de transfert DNS privée, sans avoir à modifier les paramètres du client.
Les instances de VM ont toujours accès au DNS interne.
Tous les enregistrements DNS qui ne correspondent pas au domaine Active Directory sont gérés par Cloud DNS, ce qui réduit la charge sur vos contrôleurs de domaine.
Si vous utilisez plusieurs domaines, créez une zone de transfert DNS privée distincte pour chaque domaine Active Directory.
Les zones de transfert privées Cloud DNS s'étendent à un seul VPC. Si vous utilisez plusieurs VPC connectés à l'aide de l'appairage, vous pouvez exposer les zones de transfert privées sur d'autres VPC en configurant l'appairage DNS.
Vous devez toujours configurer manuellement les paramètres DNS sur les contrôleurs de domaine. Utilisez 127.0.0.1 comme serveur DNS principal et, de manière facultative, utilisez l'adresse IP d'un autre contrôleur de domaine comme serveur DNS secondaire. Pour en savoir plus, consultez la section Paramètres DNS recommandés et autres options.
Connectivité hybride
La section suivante décrit les bonnes pratiques liées à la connectivité hybride.
Utiliser le transfert entrant DNS pour résoudre les noms DNS Google Cloud sur site
Les clients de votre réseau sur site doivent pouvoir résoudre les noms DNS des ressources déployées sur Google Cloud. Si vous étendez votre forêt ou déployez une forêt de ressources sur Google Cloud, configurez le transfert entrant DNS afin que les clients sur site puissent rechercher des enregistrements DNS pour les ressources déployées sur Google Cloud. Pour utiliser le transfert entrant, créez une règle de serveur DNS permettant d'attribuer une adresse IP au système de transfert entrant et la rendre accessible au réseau sur site.
Si le domaine DNS utilisé sur Google Cloud (par exemple, cloud.example.com) est un sous-domaine du domaine DNS utilisé sur site (par exemple, example.com), configurez la délégation DNS. Créez un enregistrement NS dans le domaine sur site qui pointe vers l'adresse IP du système de transfert entrant. L'enregistrement NS redirige les clients qui tentent de rechercher un nom DNS dans le domaine hébergé par Google Cloud vers l'adresse IP du système de transfert entrant.
Si les domaines DNS utilisés sur Google Cloud et votre domaine Active Directory sur site sont différents (par exemple, cloud.example.com et corp.example.com), configurez le transfert DNS conditionnel dans vos domaines sur site et utilisez l'adresse IP du système de transfert entrant comme cible. Lorsqu'on leur demande de résoudre un nom DNS dans le domaine hébergé par Google Cloud, les contrôleurs de domaine sur site transmettent la requête à l'adresse IP du système de transfert entrant.
Lorsque vous utilisez le transfert DNS entrant, assurez-vous que vos pare-feu sont configurés correctement.
Le transfert entrant DNS n'est pas nécessaire si vous étendez votre domaine existant à Active Directory. Dans ce scénario, tous les enregistrements DNS du domaine sont automatiquement répliqués sur Google Cloud et votre environnement sur site, et mis à disposition pour la recherche dans les deux environnements.
Utiliser le transfert sortant DNS pour résoudre les noms DNS sur site à partir de Google Cloud
Les clients exécutés sur Google Cloud doivent pouvoir résoudre les noms des ressources déployées sur site. Si vous étendez votre forêt ou déployez une forêt de ressources sur Google Cloud, créez une zone de transfert privée dans Cloud DNS pour transférer les requêtes DNS des domaines sur site vers vos serveurs DNS sur site.
Lorsque vous utilisez le transfert DNS sortant, assurez-vous que vos pare-feu sont configurés correctement.
Le transfert sortant DNS n'est pas nécessaire si vous étendez votre domaine existant à Active Directory. Dans ce scénario, tous les enregistrements DNS du domaine sont automatiquement répliqués sur Google Cloud et votre environnement sur site, et mis à disposition pour la recherche dans les deux environnements.
Utiliser des tunnels VPN pour sécuriser le trafic LDAP
Active Directory exploite de manière intensive le protocole LDAP. Contrairement à la plupart des autres protocoles utilisés par Active Directory, LDAP n'est pas chiffré par défaut.
Google Cloud assure le chiffrement du trafic entre les machines virtuelles. L'utilisation du protocole LDAP non chiffré dans votre VPC est donc acceptable. Si vous connectez votre VPC à un réseau sur site, assurez-vous que le trafic LDAP n'est échangé que sur des canaux approuvés.
Si vous utilisez Cloud VPN pour connecter Google Cloud et votre réseau sur site, le trafic est automatiquement chiffré à l'aide d'IPSec entre Google Cloud et votre point de terminaison VPN sur site.
Cloud Interconnect et l'interconnexion partenaire ne fournissent pas de chiffrement. Pour garantir une communication sécurisée, établissez un tunnel VPN sur l'interconnexion à l'aide d'un serveur VPN depuis Google Cloud Marketplace.
Utiliser l'authentification sélective et AES pour les approbations de forêts
Lors de la création d'une relation d'approbation entre les forêts Active Directory, préférez les approbations de forêts aux approbations externes et profitez des fonctionnalités suivantes pour renforcer la sécurité :
Activez l'authentification sélective pour les approbations sortantes dans la forêt de ressources. L'authentification sélective garantit que les utilisateurs de la forêt organisationnelle ne peuvent pas accéder aux ressources de la forêt de ressources, à moins d'avoir défini explicitement l'autorisation.
Appliquez une limite de forêt pour la délégation complète Kerberos pour les approbations entrantes dans la forêt organisationnelle. Cette fonctionnalité permet d'éviter les attaques par élévation des privilèges en interdisant aux ressources de la forêt de ressources de demander des tickets d'octroi de ticket (TGT, Ticket Granting Tickets) aux utilisateurs de la forêt organisationnelle.
Activez l'option L'autre domaine prend en charge le chiffrement AES via Kerberos lors de la création d'approbations. Cette option garantit que les tickets utilisés pour l'authentification interforêt sont chiffrés à l'aide d'AES au lieu de l'algorithme RC4 moins sécurisé.
Sécurité
La section suivante décrit les bonnes pratiques liées à la sécurité.
Éviter que la sécurité de Google Cloud n'interfère avec la sécurité d'Active Directory
Active Directory vous permet d'exercer un contrôle précis sur les utilisateurs qui sont autorisés à accéder aux ressources. Lorsque des machines sont déployées en tant qu'instances de VM sur Compute Engine et que les utilisateurs ont accès au projet Google Cloud sous-jacent, vous devez tenir compte des chemins supplémentaires qui pourraient permettre à un utilisateur d'accéder à une machine :
Un membre du projet doté du rôle Administrateur d'instances Compute dans un projet Google Cloud peut utiliser la fonctionnalité de réinitialisation de mot de passe pour créer des comptes d'administrateur local. Les comptes d'administrateur local constituent une menace pour la sécurité de votre domaine Active Directory, car ils peuvent être utilisés pour compromettre les stratégies de groupe ou pour installer des logiciels malveillants susceptibles d'enregistrer les identifiants de domaine d'autres utilisateurs connectés.
En ajoutant un script de démarrage, un membre de projet privilégié peut injecter du code malveillant dans une VM exécutée en tant que
nt authority\systemlors du prochain redémarrage de la machine.En utilisant la console série, un membre de projet privilégié peut également accéder à la console d'administration spéciale (SAC, Special Administration Console) de Windows. Windows considère les ouvertures de session via la console SAC comme des ouvertures de session locales. La console SAC peut donc être utilisée à mauvais escient pour échapper aux règles qui refusent les ouvertures de session via RDP, mais acceptent les ouvertures de session locales.
Un membre de projet privilégié peut utiliser la console SAC pour émettre une commande
crashdump, ce qui peut entraîner l'écriture d'un vidage de mémoire sur le disque. Ce vidage de mémoire peut inclure des informations sensibles et des identifiants.En installant le disque persistant sur une autre VM ou en utilisant des instantanés, un membre de projet privilégié peut accéder au contenu du disque, y compris potentiellement aux vidages de mémoire, à partir de machines auxquelles l'utilisateur n'aurait pas autrement l'autorisation de se connecter.
Le service Microsoft AD géré vous permet d'être mieux protégé contre ces chemins d'accès supplémentaires par défaut. Le service ne permet pas aux utilisateurs privilégiés de votre projet de réinitialiser le mot de passe de l'administrateur de domaine, d'exécuter des scripts de démarrage ou d'accéder à la console série sur les VM du contrôleur de domaine AD.
Pour limiter davantage ces risques, assurez-vous que les autorisations IAM des projets contenant des instances de VM associées au domaine sont gérés suivant le principe du moindre privilège. Pour réduire davantage ces risques, utilisez des règles d'administration, des stratégies de groupe et des VM protégées :
Utilisez une règle d'administration pour désactiver l'accès au port série.
Appliquez une stratégie de groupe permettant d'empêcher la création de comptes d'administrateur local en désactivant le gestionnaire de comptes. Définissez une préférence Fichiers .ini dans votre stratégie de groupe (Configuration ordinateur > Préférences > Paramètres Windows > Fichiers .ini) pour appliquer le paramètre suivant :
- Action : Mettre à jour
- Chemin d'accès au fichier :
C:\Program Files\Google\Compute Engine\instance_configs.cfg - Nom de la section :
accountManager - Nom de propriété :
disable - Valeur de propriété :
true
Appliquez une stratégie de groupe permettant de supprimer tous les comptes d'administrateur local des instances de VM. Utilisez la fonctionnalité Utilisateurs et groupes locaux (Configuration ordinateur > Préférences > Paramètres du panneau de configuration > Utilisateurs et groupes locaux) pour supprimer l'appartenance au groupe Administrateurs et aux autres groupes sensibles.
Envisagez d'utiliser des VM protégées en association avec le chiffrement de disque BitLocker pour éviter que le disque persistant ou les instantanés ne soient lisibles par des utilisateurs non autorisés.
Éviter que la sécurité d'Active Directory n'interfère avec la sécurité de Google Cloud
Dans un domaine Active Directory, les machines font confiance aux contrôleurs de domaine pour gérer l'authentification et l'autorisation à leur place. Sauf en cas de restriction par une stratégie de groupe, la stratégie de sécurité locale d'une machine ou l'authentification sélective, un utilisateur qui a réussi à prouver son identité à l'un des contrôleurs de domaine est autorisé à se connecter à n'importe quelle machine du domaine.
Les utilisateurs d'Active Directory pouvant se connecter à n'importe quelle machine, les pirates informatiques peuvent effectuer des mouvements latéraux au sein d'un domaine. Ces mouvements peuvent entraîner des élévations de privilèges si certaines instances de VM sont exemptées de restrictions de pare-feu ou utilisent des comptes de service Google Cloud : les identifiants d'un compte de service sont accessibles à tous les processus et utilisateurs d'une instance de VM. Tout utilisateur pouvant se connecter à une machine à l'aide d'Active Directory peut donc obtenir ces identifiants de compte de service pour accéder à toutes les ressources Google Cloud auxquelles le compte de service est autorisé à accéder.
Lors de la configuration du service Microsoft AD géré, celui-ci crée un groupe pour permettre à des utilisateurs spécifiques de se connecter facilement avec le protocole RDP aux VM associées au domaine.
Pour réduire le risque de mouvements latéraux, organisez les utilisateurs en niveaux administratifs et utilisez les stratégies de groupe Interdire l'accès à cet ordinateur à partir du réseau et Interdire l'ouverture de session par les services Bureau à distance pour restreindre l'accès aux VM en fonction du niveau d'accès.
La topologie d'une forêt de ressources vous permet de bénéficier de l'authentification sélective pour restreindre davantage l'ensemble des utilisateurs d'autres forêts autorisés à se connecter à vos VM. Vous pouvez simplifier la gestion des autorisations d'authentification sélective en alignant les structures de ressources Google Cloud et Active Directory : si les unités organisationnelles Active Directory sont mappées aux projets Google Cloud, vous pouvez accorder aux utilisateurs le droit de s'authentifier à un niveau qui correspond au projet Google Cloud.
Dans les cas où ni l'authentification sélective ni les stratégies de groupe ne sont applicables, créez un compte de service distinct, exportez les clés de compte de service, enregistrez-les sur le disque local de l'instance de VM ou dans un partage de fichiers, et protégez-les à l'aide d'une LCA NTFS afin que seuls les utilisateurs Active Directory autorisés puissent lire et utiliser les clés.
Utiliser des projets dédiés pour les contrôleurs de domaine
Les contrôleurs de domaine jouent un rôle crucial dans la sécurité d'un domaine Active Directory. La compromission d'un contrôleur de domaine unique peut entraîner celle de l'ensemble de votre forêt Active Directory.
Pour limiter les risques d'accès non autorisés, utilisez un projet Google Cloud distinct pour déployer des contrôleurs de domaine et accorder l'accès à ce projet suivant le principe du moindre privilège. Lors de la création du projet, gardez à l'esprit que certaines autorisations peuvent être héritées des dossiers parents. Pour éviter d'accorder par inadvertance un accès par héritage, envisagez de créer le projet en dehors de votre hiérarchie de dossiers habituelle.
Lors de la configuration des stratégies IAM pour le projet, accordez une attention particulière à la restriction de l'accès aux instances de VM, aux disques persistants qui contiennent la base de données ntds.dit, ainsi qu'aux emplacements de stockage susceptibles de contenir des sauvegardes.
En plus d'utiliser les stratégies IAM pour limiter l'accès au projet, vous devez également protéger le projet contre toute suppression accidentelle.
Utiliser des VM et des projets distincts pour gérer Active Directory
Pour gérer Active Directory, vous devez pouvoir utiliser des outils, tels que Utilisateurs et ordinateurs Active Directory ou Centre d'administration Active Directory. Ces outils nécessitent que vous vous connectiez à l'aide d'un compte de domaine privilégié. La machine sur laquelle vous exécutez ces outils est ainsi une cible attrayante pour le vol d'identifiants ou l'enregistrement de clés.
Pour minimiser le risque qu'un pirate informatique obtienne des identifiants de domaine privilégié, utilisez des instances de VM dédiées pour l'administration du domaine et traitez ces VM de gestion comme des postes de travail à accès privilégié :
Utilisez des stratégies de groupe pour vous assurer que seul un sous-ensemble sélectionné d'utilisateurs a le droit de se connecter aux VM de gestion. Si vous avez mis en œuvre une administration à plusieurs niveaux, ce groupe d'utilisateurs correspond au niveau 0.
Tout comme les contrôleurs de domaine, les VM administratives peuvent être mises en danger par les membres du projet qui créent des comptes d'administrateur local, se connectent via la console série ou altèrent leurs disques persistants. Pour limiter les risques d'accès non autorisés, utilisez un projet Google Cloud distinct pour les VM administratives et accordez l'accès à ce projet suivant le principe du moindre privilège.
Si vous prévoyez d'accéder aux VM administratives à partir d'un réseau sur site à l'aide de la connectivité hybride, déployez les VM administratives dans un sous-réseau VPC dédié. Un sous-réseau dédié aux VM de gestion vous permet de mieux distinguer les VM d'administration des autres VM lors de la configuration de vos pare-feu sur site. Si vous utilisez un VPC partagé, appliquez des autorisations au niveau du sous-réseau pour vous assurer que seuls les administrateurs privilégiés sont autorisés à déployer des instances de VM dans le sous-réseau de gestion. Cette pratique permet de garantir que si les pare-feu sur site appliquent des règles différentes pour les VM de gestion et les autres VM, les utilisateurs ne peuvent pas échapper aux règles de pare-feu en plaçant des VM autres que de gestion dans le sous-réseau de gestion.
En outre, envisagez de restreindre la stratégie de groupe qui gère les restrictions d'ouvertures de session pour les VM de gestion dans le sous-réseau de gestion. Cette pratique aligne les restrictions d'ouvertures de session (basées sur une stratégie de groupe) et les règles de pare-feu (basées sur le sous-réseau/l'adresse IP).
En plus d'utiliser les stratégies IAM pour limiter l'accès au projet, vous devez également protéger le projet contre toute suppression accidentelle.
Utiliser des règles de pare-feu pour sécuriser les contrôleurs de domaine et les serveurs
Les contrôleurs de domaine exposent un certain nombre de services, y compris LDAP, DNS, Kerberos et RPC. Selon vos cas d'utilisation, les VM déployées sur Google Cloud et les machines exécutées sur site peuvent avoir besoin d'accéder à différents sous-ensembles de ces services afin d'exploiter Active Directory.
Lorsque vous utilisez le service Microsoft AD géré, les contrôleurs de domaine AD sont déployés dans un projet locataire dédié. Le réseau qui héberge les contrôleurs de domaine AD est automatiquement protégé par des règles de pare-feu renforcées spécifiques à AD.
Pour réduire la surface d'attaque des contrôleurs de domaine et des VM, vous devez configurer des pare-feu pour bloquer les communications réseau qui ne sont pas strictement requises. Pour obtenir plus d'informations sur les configurations de pare-feu nécessaires pour accéder à Active Directory à partir de votre VPC ou de vos réseaux sur site, consultez notre guide sur l'utilisation d'Active Directory via des pare-feu.
Organiser les ressources et les utilisateurs Active Directory en niveaux administratifs
Certaines machines d'une forêt Active Directory sont plus critiques que d'autres pour la sécurité globale d'Active Directory. Les contrôleurs de domaine et les VM administratives sont deux exemples de machines particulièrement critiques et donc particulièrement sensibles aux attaques potentielles.
Pour identifier la criticité de chacune de vos machines, utilisez une taxonomie de niveaux. Alors que le nombre approprié de niveaux dépend de votre configuration spécifique, vous pouvez commencer par distinguer trois niveaux :
Niveau 0 (essentiel) : ce niveau comprend toutes les machines qui sont essentielles à la sécurité de votre forêt Active Directory. Dès qu'une machine de niveau 0 est compromise, vous devez supposer que votre forêt entière l'est également.
Niveau 1 (critique) : ce niveau comprend la majorité des serveurs de votre environnement, y compris les serveurs d'applications et de bases de données. Un serveur de niveau 1 compromis peut avoir un impact commercial substantiel, mais ne constitue pas une menace immédiate pour l'ensemble de la forêt.
Niveau 2 (normal) : ce niveau comprend les postes de travail ou autres machines à usage général. Une machine de niveau 2 compromise ne doit avoir qu'un impact limité sur l'entreprise et la sécurité globale.
Bien que l'impact immédiat d'une machine de niveau 2 compromise puisse sembler limité, il existe un risque d'effets indirects : lorsqu'un utilisateur disposant d'un accès administrateur aux machines de niveau 0 ou 1 est invité à se connecter à une machine de niveau 2 compromise, il peut être victime d'un enregistreur de clés ou d'autres formes de vol d'identifiants. Les identifiants enregistrés peuvent ensuite être utilisés pour attaquer des machines de niveaux supérieurs, provoquant une escalade de l'impact global.
Pour éviter de telles répercussions, assurez-vous non seulement de classer les machines, mais également les comptes utilisateur, et de limiter l'ensemble de machines auxquelles ces utilisateurs ont accès :
Niveau 0 (essentiel) : utilisateurs ayant accès aux machines de niveau 0.
Niveau 1 (critique) : utilisateurs ayant accès aux machines de niveau 1.
Niveau 2 (normal) : utilisateurs ayant accès aux machines de niveau 2.
Utilisez le tableau suivant comme guide pour déterminer quels utilisateurs doivent avoir accès aux ressources :
| Groupe | Niveau | Accès au domaine | Accès aux ordinateurs de niveau 0 | Accès aux ordinateurs de niveau 1 | Accès aux ordinateurs de niveau 2 |
|---|---|---|---|---|---|
| Administrateurs Active Directory | 0 | Administrateur | Utilisateur en accès limité | Bloqué | Bloqué |
| Administrateurs du serveur de gestion | 0 | Utilisateur en accès limité | Administrateur | Bloqué | Bloqué |
| Administrateurs de serveur | 1 | Utilisateur en accès limité | Bloqué | Administrateur | Bloqué |
| Administrateurs de postes de travail VDI | 2 | Utilisateur en accès limité | Bloqué | Bloqué | Administrateur |
| Utilisateurs de postes de travail VDI | 2 | Utilisateur en accès limité | Bloqué | Bloqué | Utilisateur en accès limité |
Consultez la documentation Microsoft pour obtenir plus d'informations et des bonnes pratiques sur l'implémentation d'un modèle de niveau administratif dans Active Directory.
Lorsque vous utilisez le modèle de niveau administratif dans votre forêt Active Directory, assurez-vous que son intégrité n'est pas compromise par les relations d'approbation entre les forêts. Si la forêt approuvée applique également un modèle d'administration à plusieurs niveaux, utilisez l'authentification sélective pour vous assurer que les utilisateurs de la forêt approuvée ne sont autorisés à accéder qu'aux ressources du même niveau :
Si la forêt approuvée n'implémente pas d'administration à plusieurs niveaux, mappez la forêt approuvée à un certain niveau et utilisez l'authentification sélective pour vous assurer que les utilisateurs de la forêt approuvée ne sont autorisés à accéder qu'aux ressources de ce niveau.
Utiliser VPC Service Controls et l'accès privé à Google pour les hôtes sur site
Les API Microsoft AD gérées permettent de réinitialiser le mot de passe administrateur et d'effectuer d'autres opérations sensibles. Pour les déploiements de production critiques, nous vous recommandons d'activer VPC Service Controls et d'utiliser l'accès privé à Google pour les hôtes sur site afin de renforcer la sécurité.
Gestion
La section suivante décrit les bonnes pratiques liées à la gestion d'Active Directory.
Aligner les structures de ressources Google Cloud et Active Directory
Lorsque vous déployez un nouveau domaine ou une nouvelle forêt Active Directory sur Google Cloud, vous devez définir une structure d'unité organisationnelle (UO) pour organiser vos ressources avec votre domaine Active Directory. Plutôt que de concevoir une structure entièrement nouvelle ou d'appliquer la structure que vous utilisez dans votre environnement sur site, créez une structure d'unité organisationnelle qui est alignée sur votre hiérarchie de ressources Google Cloud :
Si vous utilisez un modèle d'administration à plusieurs niveaux, les UO de premier niveau doivent refléter vos niveaux d'administration.
Créez des UO pour les utilisateurs et les groupes de chaque niveau. Si vous prévoyez de gérer un grand nombre d'utilisateurs et de groupes, créez des sous-unités organisationnelles selon les besoins.
Pour chaque niveau, créez une UO
Projectset créez des sous-unités organisationnelles pour chaque projet Google Cloud contenant des ressources Active Directory. Utilisez la sous-unité organisationnelle spécifique au projet pour gérer les comptes d'ordinateurs, les comptes de service ou d'autres ressources Active Directory correspondant aux ressources Google Cloud du projet. Assurez-vous qu'il existe un mappage 1:1 entre les UO et les projets.
Le schéma suivant est un exemple de hiérarchie qui suit ces principes :
Si le nombre de projets contenant des ressources Active Directory est modéré, vous pouvez créer une structure d'unité organisationnelle plate sous l'UO Projects. Si vous prévoyez de gérer un grand nombre de projets et que vous avez conçu votre hiérarchie de ressources Google Cloud pour qu'elle utilise plusieurs niveaux de dossiers, envisagez de refléter cette structure de dossiers sous l'UO Projects.
L'alignement de la structure d'UO Active Directory et de la hiérarchie des ressources Google Cloud présente plusieurs avantages :
Lorsque vous déléguez des autorisations administratives à un projet Google Cloud à l'aide de stratégies IAM, vous devrez peut-être également accorder aux utilisateurs du projet certains privilèges dans Active Directory. Par exemple, les administrateurs Compute Engine peuvent avoir besoin d'associer des machines au domaine sous une certaine UO. L'alignement des UO et des projets Google Cloud vous permet d'accorder ces autorisations au même niveau de précision dans Active Directory et Google Cloud.
Si vous prévoyez de gérer les ordinateurs à l'aide d'objets de stratégie de groupe (GPO, Group Policy Object), une structure d'UO qui reflète la hiérarchie des ressources Google Cloud vous aide à garantir que les GPO sont appliqués de manière cohérente sur toutes les VM d'un projet ou d'un dossier donné.
Si vous utilisez une approbation interforêt avec une authentification conditionnelle, vous pouvez utiliser les UO qui correspondent aux projets Google Cloud pour accorder l'autorisation Autorisation d'authentifier par projet.
Lorsque vous supprimez un projet dans Google Cloud, vous pouvez simplement supprimer l'UO associée, ce qui réduit le risque de laisser des ressources non actualisées dans votre répertoire.
Si vous pensez que votre structure d'UO doit être différente de la structure de votre projet, cela peut indiquer que celle-ci est trop précise ou abstraite.
Utiliser les serveurs de temps de Google
L'authentification Kerberos repose sur des horodatages dans le cadre de son protocole. Pour que l'authentification réussisse, les horloges de la machine cliente et du serveur doivent être synchronisées dans une certaine marge. Par défaut, Active Directory n'autorise pas plus de cinq minutes de différence.
Dans un environnement Active Directory sur site, les éléments suivants sont configurés par défaut pour la synchronisation de l'heure :
- Les machines associées au domaine synchronisent leur temps avec un contrôleur de domaine.
- Les contrôleurs de domaine synchronisent leur heure avec l'émulateur PDC de leur domaine.
- Les émulateurs PDC de tous les domaines synchronisent leur heure avec l'émulateur PDC du domaine racine de la forêt.
Dans cette configuration, l'émulateur PDC du domaine racine de la forêt est la source ultime de temps pour Active Directory, et il est courant de configurer cette machine pour qu'elle utilise un serveur NTP externe comme source de temps.
Sur Compute Engine, la configuration par défaut des VM Windows consiste à utiliser le serveur de métadonnées (metadata.google.internal) comme serveur NTP, qui à son tour s'appuie sur les serveurs NTP de Google pour obtenir bonne heure. La jointure d'une VM à un domaine Active Directory ne modifie pas cette configuration par défaut.
Conservez la configuration par défaut de Compute Engine, sauf si l'émulateur PDC du domaine racine de votre forêt est déployé en dehors de Google Cloud.
Si votre émulateur PDC est déployé en dehors de Google Cloud, configurez-le pour utiliser time.google.com en tant que source NTP.
Vous pouvez également restaurer le comportement Active Directory par défaut, pour la synchronisation de l'heure avec l'émulateur PDC, en reconfigurant les VM Compute Engine de sorte qu'elles utilisent la source NTP DOMHIER et en configurant des règles de pare-feu afin d'autoriser le trafic NTP entrant (UDP/123) vers vos contrôleurs de domaine.
Consolider et surveiller les journaux d'audit
Lorsque vous déployez Active Directory sur Google Cloud, la sécurité de votre forêt Active Directory et celle de vos projets Google Cloud sont liées : une activité suspecte dans Active Directory et Windows peut mettre en danger la sécurité de certaines autres ressources de la même manière qu'une activité suspecte dans Google Cloud peut mettre en danger votre forêt Active Directory.
Des journaux d'audit cohérents sont un outil important pour identifier précocement les menaces ou les erreurs de configuration. Ils vous permettent également de reconstruire et d'examiner les activités passées. Cloud Audit Logging vous permet d'enregistrer et d'analyser les journaux des activités d'administration et les journaux d'accès aux données. De même, vous pouvez analyser le trafic réseau à l'aide de la journalisation des règles de pare-feu et des journaux de flux VPC. Cependant, ces services de plate-forme ne connaissent pas les événements liés à la sécurité dans Active Directory. Pour établir un outil d'audit cohérent qui couvre à la fois les événements d'audit liés à la plate-forme et ceux liés à Active Directory, installez l'agent Cloud Logging sur les contrôleurs de domaine et les machines associées au domaine pour exporter les journaux d'événements liés à la sécurité Windows vers Cloud Logging.
Par défaut, le journal des événements liés à la sécurité Windows est susceptible de ne pas enregistrer tous les événements dont vous avez besoin à des fins d'audit. Consultez les recommandations Microsoft sur la configuration des stratégies d'audit et de la surveillance d'Active Directory pour détecter les signes de compromission afin de vous assurer d'enregistrer tous les événements d'audit pertinents.
Si vous traitez un grand nombre d'événements, il est facile de manquer des événements critiques. Pour éviter de manquer des événements critiques, créez des métriques basées sur les journaux pour les événements susceptibles d'être particulièrement critiques ou suspects et pensez à configurer des alertes pour être informé lorsque le taux d'événements change ou dépasse les seuils acceptables.
Étape suivante
Découvrez les modèles pour l'utilisation d'Active Directory dans un environnement hybride qui conviennent le mieux à votre situation.
Apprenez à configurer Active Directory pour permettre la jonction automatique de VM à un domaine.
Testez d'autres fonctionnalités de Google Cloud. Consultez nos tutoriels.