Modèles pour l'utilisation d'Active Directory dans un environnement hybride

Ce document décrit les exigences en termes de déploiement d'Active Directory sur Google Cloud et vous aide à choisir l'architecture adaptée.

En fédérant Active Directory avec Cloud Identity ou Google Workspace (voir les modèles d'authentification des utilisateurs du personnel dans un environnement hybride), vous pouvez autoriser les utilisateurs de vos domaines Active Directory existants à s'authentifier et à accéder aux ressources sur Google Cloud. Vous pouvez également déployer Active Directory sur Google Cloud si vous prévoyez de l'utiliser pour gérer des serveurs Windows sur Google Cloud ou si vous utilisez des protocoles non compatibles avec Google Cloud.

Avant de déployer Active Directory sur Google Cloud, vous devez d'abord choisir quelle architecture de domaine et de forêt utiliser, et comment l'intégrer à votre forêt Active Directory existante.

Évaluer les exigences

Active Directory est compatible avec une série d'architectures de domaine et de forêt. Dans un environnement hybride, l'une des options consiste à étendre un seul domaine Active Directory sur plusieurs environnements. Vous pouvez également utiliser des domaines ou des forêts distincts et les connecter à l'aide des relations d'approbation. La meilleure architecture est celle qui répond à vos besoins.

Pour choisir la meilleure architecture, examinez ces facteurs :

• Alignement avec les zones de sécurité existantes
• Interaction entre les ressources sur site et Google Cloud
• Autonomie administrative
• Disponibilité

Ces facteurs sont expliqués plus en détail dans les sections suivantes.

Alignement avec les zones de sécurité existantes

Commencez par examiner la conception de votre réseau sur site.

Dans votre environnement sur site, vous avez peut-être segmenté votre réseau en plusieurs zones de sécurité (par exemple à l'aide de VLAN ou de sous-réseaux distincts). Dans un réseau ayant été segmenté en zones de sécurité, la communication au sein d'une zone de sécurité peut être sans restriction ou soumise à des règles légères de pare-feu et d'audit. En revanche, toute communication entre les zones de sécurité est soumise à des règles strictes de pare-feu, d'audit ou d'inspection du trafic.

Toutefois, le rôle des zones de sécurité dépasse opérations de restriction et d'audit de la communication réseau. Celles-ci doivent également mettre en œuvre des limites de confiance.

Limites de confiance

Chaque machine d'un réseau exécute plusieurs processus. Ces processus peuvent communiquer entre eux en local à l'aide de la communication inter-processus. Ils peuvent également communiquer entre différentes machines à l'aide de protocoles tels que HTTP. Dans ce réseau de communication, les pairs ne s'accordent pas toujours le même niveau de confiance. Par exemple, les processus peuvent faire davantage confiance aux processus qui s'exécutent sur la même machine qu'aux processus qui s'exécutent sur d'autres machines. De même, certaines machines pourraient être considérées comme étant plus fiables que d'autres.

Une limite de confiance impose des inégalités entre les parties de communication. En d'autres termes, elle fait davantage confiance à un groupe de parties de communication qu'à un autre.

Les limites de confiance sont essentielles pour limiter l'impact d'une attaque. Les attaques prennent rarement fin lorsqu'un seul système a été compromis, qu'il s'agisse d'un seul processus ou d'une machine complète. À la place, un pirate est susceptible d'étendre l'attaque sur d'autres systèmes. Étant donné que les systèmes situés dans des limites de confiance ne font pas de distinction entre eux, il est plus facile de propager une attaque à l'intérieur de cette limite de confiance que d'attaquer des systèmes à travers celle-ci.

Une fois qu'un système situé dans une limite de confiance a été compromis, tous les autres systèmes de cette limite de confiance doivent être considérés comme étant compromis également. Cette hypothèse peut vous aider à identifier les limites de confiance ou à confirmer si une limite de système représente en réalité une limite de confiance. Exemple :

Supposons qu'un pirate ait réussi à atteindre le niveau d'accès à la cible A le plus élevé (par exemple, accès administrateur ou accès root à une machine ou une application). S'il parvient à exploiter ces privilèges pour obtenir le même niveau d'accès à la cible B, A et B sont, par définition, dans la même limite de confiance. Dans le cas contraire, une limite de confiance se situe entre A et B.

En limitant la communication réseau, les zones de sécurité peuvent contribuer à mettre en œuvre des limites de confiance. Pour qu'une zone de sécurité soit considérée comme une véritable limite de confiance, les charges de travail situées de chaque côté de la limite doivent traiter de manière différente les requêtes provenant de la même zone de sécurité et les requêtes provenant de zones de sécurité distinctes, en accordant à cette deuxième catégorie une vigilance accrue.

Modèle zéro confiance

Le modèle zéro confiance est le modèle de réseau préféré sur Google Cloud.

S'il existe un seul système compromis au sein d'une limite de confiance, vous pouvez considérer que tous les systèmes de cette limite sont également compromis. Cette hypothèse suggère que les limites de confiance à faible portée sont plus efficaces. Avec une limite de confiance à portée plus faible, le nombre de systèmes compromis est moins élevé et le pirate est confronté à davantage de limites avant de pouvoir propager l'attaque.

Le modèle zéro confiance mène l'idée à sa conclusion logique : chaque machine du réseau est traitée comme une zone de sécurité et une limite de confiance uniques. Toutes les communications entre les machines sont soumises au même niveau de contrôle et de pare-feu, et toutes les requêtes de réseau sont traitées comme si elles provenaient d'une source non fiable.

Sur le plan de la mise en réseau, vous pouvez mettre en œuvre un modèle zéro confiance en utilisant des règles de pare-feu pour limiter le trafic, ainsi que des journaux de flux VPC et la journalisation des règles de pare-feu pour analyser le trafic. Au niveau de l'application, vous devez vous assurer que toutes les applications gèrent de manière cohérente et sécurisée l'authentification, l'autorisation et l'audit.

Limites de confiance dans Active Directory

Dans un domaine Active Directory, les machines font confiance aux contrôleurs de domaine pour gérer l'authentification et l'autorisation à leur place. Une fois que l'utilisateur a prouvé son identité auprès de l'un des contrôleurs de domaine, il peut se connecter par défaut à toutes les machines du même domaine. Tous les droits d'accès accordés à l'utilisateur par le contrôleur de domaine (sous forme de privilèges et d'appartenances à des groupes) s'appliquent à de nombreuses machines du domaine.

Les règles de groupe vous permettent de restreindre l'accès ou les droits des utilisateurs sur certaines machines. Une fois qu'une machine est compromise, un pirate peut toutefois voler des mots de passe, des hachages de mots de passe ou des jetons Kerberos à d'autres utilisateurs du domaine connectés à cette même machine. Le pirate peut alors exploiter ces identifiants pour propager l'attaque sur d'autres domaines de la forêt.

Compte tenu de ces facteurs, il est préférable de supposer que toutes les machines d'une forêt se trouvent dans une limite de sécurité de confiance.

Par rapport aux limites de domaine, qui ont pour objectif de contrôler la réplication et d'accorder l'autonomie administrative aux différentes parties de l'organisation, les limites de forêt peuvent offrir une isolation plus forte. Les forêts peuvent servir de limite de confiance.

Alignement des forêts Active Directory et des zones de sécurité

Le fait de considérer la forêt comme une limite de confiance possède un impact sur la conception des zones de sécurité. Si une forêt s'étend sur deux zones de sécurité, il est plus facile pour un pirate de supprimer la limite entre ces deux zones. Par conséquent, les deux zones de sécurité deviennent une seule et unique limite de confiance.

Dans un modèle zéro confiance, chaque machine d'un réseau peut être considérée comme une zone de sécurité distincte. Le déploiement d'Active Directory dans un réseau de ce type entrave ce concept et élargit les limites de sécurité en place pour inclure toutes les machines de la forêt Active Directory.

Pour utiliser une zone de sécurité en tant que limite de confiance, vous devez vous assurer que l'intégralité de la forêt Active Directory se trouve dans cette zone de sécurité.

Impact sur l'extension d'Active Directory à Google Cloud

Lorsque vous planifiez un déploiement sur Google Cloud nécessitant Active Directory, vous devez choisir entre deux options permettant d'aligner le déploiement sur vos zones de sécurité existantes :

• Étendre une zone de sécurité existante à Google Cloud. Vous pouvez étendre une ou plusieurs de vos zones de sécurité existantes à Google Cloud en provisionnant un VPC partagé sur Google Cloud, puis en le connectant à la zone existante à l'aide de Cloud VPN ou de Cloud Interconnect.

  Les ressources déployées sur site et sur Google Cloud partageant une zone commune peuvent également partager une forêt Active Directory commune. Il n'est donc pas nécessaire de déployer une forêt distincte pour Google Cloud.

  Prenons l'exemple d'un réseau existant doté d'un réseau de périmètre de développement et d'un réseau de périmètre de production en tant que zones de sécurité avec une forêt Active Directory distincte dans chacune. Si vous étendez les zones de sécurité à Google Cloud, tous les déploiements sur Google Cloud feront également partie de l'une de ces deux zones de sécurité et pourront utiliser les mêmes forêts Active Directory.

  

• Introduire de nouvelles zones de sécurité. Dans certains cas, l'extension d'une zone de sécurité peut ne pas s'appliquer, soit parce que vous ne souhaitez pas développer davantage une zone, soit parce que les exigences de sécurité des zones de sécurité existantes ne correspondent pas aux exigences des déploiements Google Cloud. Vous pouvez considérer Google Cloud comme des zones de sécurité supplémentaires.

  À titre d'exemple, prenons un environnement sur site doté d'un périmètre réseau, mais qui ne fait pas de distinction entre les charges de travail de développement et les charges de travail de production. Pour séparer ces charges de travail sur Google Cloud, vous pouvez créer deux VPC partagés et les utiliser en tant que nouvelles zones de sécurité. Vous allez ensuite déployer deux forêts Active Directory supplémentaires sur Google Cloud, une par zone de sécurité. Si nécessaire, vous pouvez établir des relations d'approbation entre les forêts pour activer l'authentification sur les zones de sécurité.

  

Interaction entre les ressources sur site et Google Cloud

Le deuxième facteur à prendre en compte lorsque vous étendez Active Directory à Google Cloud est l'interaction des utilisateurs et des ressources sur site et sur Google Cloud. Selon votre cas d'utilisation, cette interaction peut être faible à élevée.

Interaction faible

Si vous utilisez Active Directory sur Google Cloud dans le but de gérer un parc de serveurs Windows et de permettre aux administrateurs de se connecter à ces serveurs, le niveau d'interaction entre les environnements est faible :

• L'ensemble des employés interagissant avec les ressources sur Google Cloud est limité au personnel administratif.
• Il est possible que les applications déployées sur Google Cloud n'interagissent pas du tout avec les applications sur site ou qu'elles le fassent sans l'aide d'installations d'authentification Windows telles que Kerberos et NTLM.

Dans un scénario léger, vous pouvez intégrer vos environnements sur site et Google Cloud de l'une des deux manières suivantes :

• À l'aide de deux forêts Active Directory disjointes : vous pouvez isoler les deux environnements en utilisant deux forêts Active Directory distinctes, qui ne partagent pas de relation d'approbation. Pour autoriser les administrateurs à s'authentifier, vous devez gérer un ensemble distinct de comptes utilisateur dans la forêt Google Cloud.

  Le fait de conserver un ensemble de comptes utilisateur en double augmente la charge de travail administrative et peut entraîner l'oubli de la désactivation des comptes lorsque des employés quittent l'entreprise. Une meilleure approche consiste à provisionner ces comptes automatiquement.

  Si les comptes utilisateur de l'environnement Active Directory sur site sont provisionnés par un système d'information de gestion des ressources humaines, vous pouvez peut-être utiliser un mécanisme semblable pour provisionner et gérer les comptes utilisateur dans la forêt Google Cloud. Vous pouvez également vous servir d'outils tels que Microsoft Identity Manager pour synchroniser les comptes utilisateur entre les environnements.

• À l'aide de deux forêts Active Directory avec approbation interforêt : vous pouvez utiliser deux forêts Active Directory et les associer à une approbation interforêt pour vous éviter d'avoir à gérer des comptes qui existent en double. Les administrateurs utilisent le même compte utilisateur pour s'authentifier auprès des deux environnements. Bien que le niveau d'isolation entre les environnements puisse être considéré comme inférieur, utiliser des forêts distinctes vous permet de maintenir une limite de confiance entre votre environnement sur site et Google Cloud.

Interaction modérée

Votre cas d'utilisation est peut-être plus complexe. Exemple :

• Les administrateurs qui se connectent aux serveurs Windows déployés sur Google Cloud peuvent avoir besoin d'accéder à des partages de fichiers hébergés sur site.
• Les applications peuvent se servir de Kerberos ou de NTLM pour s'authentifier et communiquer au-delà des limites de l'environnement.
• Vous souhaitez peut-être autoriser les employés à utiliser l'authentification Windows intégrée (IWA, Integrated Windows Authentication) pour s'authentifier auprès d'applications Web déployées sur Google Cloud.

Dans un scénario modéré, l'utilisation de deux forêts Active Directory disjointes peut s'avérer trop restrictive. Kerberos ne permet pas de s'authentifier auprès des deux forêts et l'authentification passthrough NTLM nécessite le maintien de la synchronisation des comptes utilisateur et des mots de passe.

Dans ce cas, nous vous recommandons d'utiliser deux forêts Active Directory avec une approbation interforêt.

Interaction forte

Certaines charges de travail, y compris les déploiements VDI (Virtual Desktop Infrastructure, ou infrastructure de bureau virtuel), peuvent nécessiter une interaction forte entre les ressources sur site et les ressources déployées sur Google Cloud. Lorsque les ressources de plusieurs environnements sont étroitement couplées, il peut être difficile de maintenir une limite de confiance entre les environnements, et l'utilisation de deux forêts avec approbation interforêt peut se révéler trop restrictive.

Dans ce cas, nous vous recommandons d'utiliser une seule forêt Active Directory et de la partager au sein de plusieurs environnements.

Autonomie administrative

Le troisième facteur à prendre en compte lorsque vous étendez Active Directory à Google Cloud est l'autonomie administrative.

Si vous prévoyez de distribuer les charges de travail sur site et sur Google Cloud, les charges de travail que vous allez exécuter sur Google Cloud peuvent être très différentes de celles que vous conservez sur site. Vous pouvez même décider de confier la gestion des deux environnements à deux équipes différentes.

La réparation des responsabilités entre les différentes équipes nécessite d'accorder à chaque équipe une certaine autonomie administrative. Dans Active Directory, vous pouvez autoriser vos équipes à gérer les ressources à l'aide de la délégation des tâches administratives ou des domaines distincts.

La délégation des tâches administratives est un moyen simple de déléguer des tâches administratives et d'accorder une certaine autonomie aux équipes. Le fait de conserver un seul domaine peut également contribuer à assurer la cohérence entre les environnements et les équipes.

Toutefois, vous ne pouvez pas déléguer toutes les fonctionnalités d'administration, et le partage d'un seul domaine peut augmenter la charge de travail administrative associée à la coordination entre les équipes. Dans ce cas, nous vous recommandons d'utiliser des domaines distincts.

Disponibilité

Le dernier facteur à prendre en compte lorsque vous étendez Active Directory à Google Cloud est la disponibilité. Pour chaque domaine d'une forêt Active Directory, le contrôleur de domaine sert de fournisseur d'identité aux utilisateurs concernés.

Lorsqu'un utilisateur se sert de Kerberos pour s'authentifier, il doit interagir avec un contrôleur de domaine Active Directory lors des étapes suivantes :

• La première authentification (obtention d'un ticket d'octroi de ticket).
• Lors de la réauthentification périodique (actualisation d'un ticket d'octroi de ticket)
• L'authentification avec une ressource (obtention d'un ticket de service).

La première authentification et la réauthentification périodique nécessitent de communiquer avec un seul contrôleur de domaine, à savoir le contrôleur du domaine dont l'utilisateur est membre.

Lors de l'authentification avec une ressource, il peut être nécessaire d'interagir avec plusieurs contrôleurs de domaine, selon le domaine dans lequel se trouve la ressource :

• Si la ressource est située dans le même domaine que l'utilisateur, ce dernier peut utiliser le même contrôleur de domaine (ou un contrôleur de domaine différent du même domaine) pour terminer le processus d'authentification.
• Si la ressource est située dans un domaine différent, mais qu'il existe une relation d'approbation directe avec le domaine de l'utilisateur, ce dernier doit interagir avec au moins deux contrôleurs de domaine : un dans le domaine de ressources et un dans le domaine de l'utilisateur.
• Si la ressource et l'utilisateur font partie de domaines différents et s'il n'existe qu'une relation d'approbation indirecte entre ces domaines, il est nécessaire de communiquer avec les contrôleurs de domaine de chaque domaine du chemin de confiance pour terminer l'authentification.

L'emplacement d'utilisateurs et de ressources dans différents domaines ou forêts Active Directory peut limiter la disponibilité globale. Comme l'authentification nécessite d'interagir avec plusieurs domaines, l'interruption d'un domaine peut affecter la disponibilité des ressources dans d'autres domaines.

Compte tenu de l'impact potentiel de la topologie d'Active Directory sur la disponibilité, nous vous recommandons d'aligner votre topologie d'Active Directory sur votre stratégie hybride.

Charges de travail distribuées

Pour tirer parti des fonctionnalités uniques de chaque environnement informatique, vous pouvez utiliser une approche hybride pour répartir les charges de travail entre ces environnements. Dans ce type de configuration, les charges de travail que vous déployez sur Google Cloud sont susceptibles de dépendre d'autres infrastructures ou d'applications s'exécutant sur site, ce qui rend la connectivité hybride à haute disponibilité indispensable.

Si vous déployez une forêt ou un domaine Active Directory distinct sur Google Cloud, et que vous utilisez une approbation pour sa connexion à l'environnement Active Directory sur site, vous devez ajouter une autre dépendance entre Google Cloud et votre environnement sur site. Cette dépendance a très peu d'impact sur la disponibilité.

Charges de travail redondantes

Si vous utilisez Google Cloud pour assurer la continuité des activités, vos charges de travail sur Google Cloud reflètent certaines charges de travail de votre environnement sur site. Cette configuration permet à un environnement de reprendre le rôle de l'autre environnement en cas d'échec. Ainsi, vous devez examiner chaque dépendance entre ces environnements.

Si vous déployez une forêt ou un domaine Active Directory distincts sur Google Cloud et que vous utilisez une approbation pour les connecter à Active Directory sur site, il vous faudra peut-être créer une dépendance compromettant l'objectif de cette configuration. Si l'environnement Active Directory sur site devient indisponible, toutes les charges de travail déployées sur Google Cloud qui s'appuient sur l'authentification interdomaine ou interforêt peuvent également devenir indisponibles.

Si votre objectif est d'assurer la continuité des activités, vous pouvez utiliser des forêts Active Directory distinctes dans chaque environnement qui ne sont pas connectés les uns aux autres. Vous pouvez également étendre un domaine Active Directory existant à Google Cloud. En déployant des contrôleurs de domaine supplémentaires sur Google Cloud et en répliquant le contenu du répertoire sur les différents environnements, vous assurez le fonctionnement des environnements de manière indépendante.

Modèles d'intégration

Une fois que vous avez évalué vos besoins, utilisez l'arbre de décision ci-dessous pour identifier une architecture de domaine et de forêt adaptée.

Les sections suivantes décrivent chacun de ces modèles.

Forêts synchronisées

Dans le modèle de forêts synchronisées, vous déployez une forêt Active Directory distincte sur Google Cloud. Vous utilisez cette forêt pour gérer les ressources déployées sur Google Cloud, ainsi que les comptes utilisateur nécessaires à la gestion de ces ressources.

Plutôt que de créer une approbation entre la nouvelle forêt et une forêt existante sur site, synchronisez les comptes. Si vous utilisez un système d'information de gestion des ressources humaines en tant que système principal pour la gestion des comptes utilisateur, vous pouvez le configurer pour qu'il provisionne les comptes utilisateur dans la forêt Active Directory hébergée par Google Cloud. Vous pouvez également vous servir d'outils tels que Microsoft Identity Manager pour synchroniser les comptes utilisateur entre les environnements.

Nous vous conseillons d'utiliser le modèle de forêts synchronisées si une ou plusieurs des conditions suivantes s'appliquent :

• Votre usage prévu de Google Cloud correspond à l'un des modèles de déploiement redondant et vous souhaitez éviter les dépendances d'exécution entre votre environnement sur site et Google Cloud.
• Vous souhaitez maintenir une limite de confiance entre l'environnement Active Directory sur site et l'environnement Active Directory hébergé par Google Cloud, soit en tant que mesure de défense en profondeur, soit parce qu'un environnement vous inspire davantage confiance que l'autre.
• Vous prévoyez une interaction faible à nulle entre les ressources gérées par Active Directory sur site et sur Google Cloud.
• Vous avez besoin d'un nombre peu élevé de comptes utilisateur dans l'environnement Active Directory hébergé par Google Cloud.

Avantages :

• Le modèle de forêts synchronisées vous permet de maintenir une forte isolation entre les deux environnements Active Directory. Un pirate qui parviendrait à compromettre un environnement n'aurait pas grand chose à gagner en attaquant le deuxième environnement.
• Vous n'avez pas besoin de configurer une connectivité hybride sur vos réseaux sur site et Google Cloud pour assurer le fonctionnement d'Active Directory.
• L'environnement Active Directory hébergé par Google Cloud n'est pas affecté par les pannes d'Active Directory sur site. Ce modèle est parfaitement adapté aux scénarios de continuité des activités ou aux scénarios nécessitant une haute disponibilité.
• Vous pouvez accorder un niveau élevé d'autonomie administrative aux équipes qui gèrent la forêt Active Directory hébergée par Google Cloud.
• Ce modèle est compatible avec le service géré pour Microsoft Active Directory.

Bonnes pratiques :

• Ne synchronisez pas les mots de passe des comptes utilisateur entre les deux forêts Active Directory. Cette action compromet l'isolation entre les différents environnements.
• Ne vous fiez pas à l'authentification directe, car elle nécessite la synchronisation des mots de passe des comptes d'utilisateurs.
• Assurez-vous que lorsqu'un employé quitte l'entreprise, ses comptes associés aux deux environnements Active Directory sont désactivés ou supprimés.

Forêt de ressources

Dans le modèle de forêt de ressources, vous déployez une forêt Active Directory distincte sur Google Cloud. Cette forêt vous permet de gérer les ressources déployées sur Google Cloud, ainsi qu'un ensemble minimal de comptes utilisateur d'administration nécessaires à la gestion de la forêt. En établissant une approbation de forêt pour votre forêt Active Directory existante sur site, vous autorisez les utilisateurs de la forêt existante à s'authentifier et à accéder aux ressources gérées par la forêt Active Directory hébergée par Google Cloud.

Si nécessaire, vous pouvez transformer ce modèle en une topologie en étoile avec votre forêt Active Directory existante au centre, connectée à de nombreuses forêts de ressources.

Nous vous conseillons d'utiliser le modèle de forêts de ressources si une ou plusieurs des conditions suivantes s'appliquent :

• Votre usage prévu de Google Cloud correspond à l'un des modèles de déploiement distribué, et une dépendance entre votre environnement sur site et Google Cloud est acceptable.
• Vous souhaitez maintenir une limite de confiance entre l'environnement Active Directory sur site et l'environnement Active Directory hébergé par Google Cloud, soit en tant que mesure de défense en profondeur, soit parce qu'un environnement vous inspire davantage confiance que l'autre.
• Vous prévoyez une interaction modérée entre les ressources gérées par Active Directory sur site et sur Google Cloud.
• De nombreux utilisateurs ont besoin d'accéder aux ressources déployées sur Google Cloud (par exemple, aux applications Web qui utilisent l'IWA pour l'authentification).

Avantages :

• Le modèle de forêt de ressources vous permet de maintenir une limite de confiance entre les deux environnements Active Directory. Selon la configuration de la relation d'approbation, un pirate qui parviendrait à compromettre un environnement obtiendrait un accès limité, voire nul, au deuxième environnement.
• Ce modèle est entièrement compatible avec le service Microsoft AD géré.
• Vous pouvez accorder un niveau élevé d'autonomie administrative aux équipes qui gèrent la forêt Active Directory hébergée par Google Cloud.

Bonnes pratiques :

• Connectez les deux forêts Active Directory à l'aide d'une approbation unidirectionnelle de sorte que l'environnement Active Directory hébergé par Google Cloud fasse confiance à la forêt Active Directory existante, mais sans réciprocité.
• Servez-vous de l'authentification sélective pour limiter les ressources de l'environnement Active Directory hébergé par Google Cloud auxquelles les utilisateurs de l'environnement Active Directory sur site ont accès.
• Recourez à des connexions redondantes Dedicated Interconnect, Partner Interconnect ou Cloud VPN pour garantir une connectivité réseau à disponibilité élevée entre votre réseau sur site et Google Cloud.

Domaine étendu

Dans le modèle de domaine étendu, vous étendez un ou plusieurs de vos domaines Active Directory existants à Google Cloud. Pour chaque domaine, vous déployez un ou plusieurs contrôleurs de domaine sur Google Cloud, ce qui entraîne la réplication et la disponibilité sur Google Cloud de toutes les données du domaine, ainsi que du catalogue global. En utilisant des sites Active Directory distincts pour vos sous-réseaux sur site et sur Google Cloud, vous vous assurez que les clients communiquent avec les contrôleurs de domaine les plus proches.

Nous vous conseillons d'utiliser le modèle de domaine étendu si une ou plusieurs des conditions suivantes s'appliquent :

• Votre usage prévu de Google Cloud correspond à l'un des modèles de déploiement redondant, et vous souhaitez éviter les dépendances d'exécution entre votre environnement sur site et Google Cloud.
• Vous prévoyez une interaction forte entre les ressources gérées par Active Directory sur site et sur Google Cloud.
• Vous souhaitez accélérer l'authentification pour les applications qui s'appuient sur LDAP pour l'authentification.

Avantages :

• L'environnement Active Directory hébergé par Google Cloud n'est pas affecté par les pannes d'Active Directory sur site. Ce modèle est parfaitement adapté aux scénarios de continuité des activités ou aux scénarios nécessitant une haute disponibilité.
• Vous pouvez limiter les communications entre votre réseau sur site et Google Cloud. Cette action peut permettre d'économiser de la bande passante et d'améliorer la latence.
• La totalité du contenu du catalogue global est répliquée dans Active Directory et est facilement accessible depuis les ressources hébergées par Google Cloud.

Bonnes pratiques :

• Si vous répliquez tous les domaines, la communication entre le réseau sur site et celui de Google Cloud est limitée à la réplication d'Active Directory entre les contrôleurs de domaine. Si vous ne répliquez qu'un seul sous-ensemble parmi les domaines de votre forêt, les serveurs associés à un domaine exécutés sur Google Cloud peuvent encore avoir besoin de communiquer avec les contrôleurs des domaines non répliqués. Assurez-vous que les règles de pare-feu qui s'appliquent à la communication entre l'environnement sur site et Google Cloud prennent en compte tous les cas pertinents.
• Sachez que la réplication sur plusieurs sites ne s'effectue qu'à certains intervalles. Par conséquent, les mises à jour sur une surface de contrôleur de domaine sur site vers Google Cloud ne s'effectuent qu'après un délai (et inversement).
• Nous vous recommandons d'utiliser des contrôleurs de domaine en lecture seule (RODC, Read-Only Domain Controller) pour conserver une copie en lecture seule des données du domaine sur Google Cloud. Toutefois, sachez qu'il existe un compromis en ce qui concerne la mise en cache des mots de passe utilisateur. Si vous autorisez les RODC à mettre en cache les mots de passe et à pré-remplir le cache de mot de passe, il est possible qu'une panne des contrôleurs de domaine sur site n'ait aucune incidence sur les ressources déployées sur Google Cloud. Cependant, les avantages de l'utilisation d'un contrôleur de domaine en lecture seule sur un contrôleur de domaine standard sont limités. Si vous désactivez la mise en cache des mots de passe, un RODC compromis peut ne présenter qu'un risque limité pour le reste de votre environnement Active Directory, mais Google Cloud sera désormais affecté par une panne des contrôleurs de domaine sur site.

Forêt étendue

Dans le modèle de forêt étendue, vous déployez un nouveau domaine Active Directory sur Google Cloud, mais vous l'intégrez à votre forêt existante. Vous utilisez ce nouveau domaine pour gérer les ressources déployées sur Google Cloud, ainsi qu'un ensemble minimal de comptes utilisateur d'administration alloués à la gestion du domaine.

En étendant les relations d'approbation implicites à d'autres domaines de la forêt, vous permettez aux utilisateurs existants d'autres domaines de s'authentifier et d'accéder aux ressources gérées par le domaine Active Directory hébergé par Google Cloud.

Nous vous conseillons d'utiliser le modèle de forêt étendue si une ou plusieurs des conditions suivantes s'appliquent :

• Votre usage prévu de Google Cloud correspond à l'un des modèles de déploiement distribué, et une dépendance entre votre environnement sur site et Google Cloud est acceptable.
• Les ressources que vous prévoyez de déployer sur Google Cloud nécessitent une configuration ou une structure de domaine différente de celle fournie par vos domaines existants. Ou encore, vous souhaitez accorder une autonomie administrative élevée aux équipes qui gèrent le domaine hébergé par Google Cloud.
• Vous prévoyez une interaction modérée à forte entre les ressources gérées par Active Directory sur site et sur Google Cloud.
• De nombreux utilisateurs ont besoin d'accéder aux ressources déployées sur Google Cloud (par exemple, aux applications Web qui utilisent l'IWA pour l'authentification).

Avantages :

• La totalité du contenu du catalogue global est répliquée dans Active Directory et est facilement accessible depuis les ressources hébergées par Google Cloud.
• Le trafic de réplication entre le réseau sur site et Google Cloud est limité à la réplication du catalogue global. Cela pourrait contribuer à limiter votre consommation de bande passante globale.
• Vous pouvez accorder un niveau élevé d'autonomie administrative aux équipes qui gèrent le domaine Active Directory hébergé par Google Cloud.

Bonnes pratiques

• Recourez à des connexions Dedicated Interconnect, Partner Interconnect ou Cloud VPN redondantes pour garantir une connectivité réseau à disponibilité élevée entre votre réseau sur site et Google Cloud.

Forêt de ressources avec domaine étendu

Le modèle de forêt de ressources avec domaine étendu est une extension du modèle de forêt de ressources. Le modèle de forêt de ressources vous permet de maintenir une limite de confiance entre plusieurs environnements et d'assurer l'autonomie administrative. Un des inconvénients de la forêt de ressources réside dans le fait que sa disponibilité globale dépend de la disponibilité des contrôleurs de domaine sur site et d'une connectivité réseau fiable à votre centre de données sur site.

Vous pouvez contourner ces limites en combinant le modèle de forêt de ressources au modèle de domaine étendu. En répliquant le domaine, vos comptes utilisateur sont situés dans Google Cloud. Ainsi, et vous pouvez vous assurer que les utilisateurs peuvent s'authentifier auprès des ressources hébergées par Google Cloud, même en cas d'indisponibilité des contrôleurs de domaine sur site ou de perte de la connectivité réseau.

Nous vous conseillons d'utiliser le modèle de forêt de ressources avec domaine étendu si une ou plusieurs des conditions suivantes s'appliquent :

• Vous souhaitez maintenir une limite de confiance entre votre forêt Active Directory principale et la forêt de ressources.
• Vous souhaitez éviter qu'une panne des contrôleurs de domaine sur site ou qu'une perte de connectivité réseau à votre environnement sur site n'affecte vos charges de travail hébergées par Google Cloud.
• Vous prévoyez une interaction modérée entre les ressources gérées par Active Directory sur site et sur Google Cloud.
• De nombreux utilisateurs d'un même domaine Active Directory ont besoin d'accéder aux ressources déployées sur Google Cloud (par exemple, aux applications Web qui utilisent l'IWA pour l'authentification).

Avantages :

• Les ressources hébergées par Google Cloud ne sont pas affectées par les pannes d'Active Directory sur site. Ce modèle est parfaitement adapté aux scénarios de continuité des activités ou aux scénarios nécessitant une haute disponibilité.
• Le modèle vous permet de maintenir une limite de confiance entre les deux forêts Active Directory. Selon la configuration de la relation d'approbation, un pirate qui parviendrait à compromettre un environnement obtiendrait un accès limité, voire nul, à l'autre environnement.
• La communication entre le réseau sur site et celui de Google Cloud est limitée à la réplication d'Active Directory entre les contrôleurs de domaine. Vous pouvez mettre en œuvre des règles de pare-feu permettant d'interdire toute autre communication, renforçant ainsi l'isolation entre les environnements.
• Vous pouvez accorder un niveau élevé d'autonomie administrative aux équipes qui gèrent la forêt Active Directory hébergée par Google Cloud.
• Vous pouvez faire appel au service Microsoft AD géré pour la forêt de ressources.

Bonnes pratiques :

• Déployez les contrôleurs de domaine du domaine étendu dans un projet Google Cloud et un VPC distincts afin de séparer ces composants de ceux de la forêt de ressources.
• L'appairage de VPC permet de connecter le VPC au VPC partagé ou au VPC utilisé par la forêt de ressources, et de configurer des pare-feu permettant de limiter la communication à l'authentification des utilisateurs Kerberos et à la création d'approbations de forêts.
• Connectez les deux forêts Active Directory à l'aide d'une approbation unidirectionnelle de sorte que l'environnement Active Directory hébergé par Google Cloud fasse confiance à la forêt Active Directory existante, mais sans réciprocité.
• Servez-vous de l'authentification sélective pour limiter les ressources de la forêt de ressources auxquelles les utilisateurs d'autres forêts ont accès.
• Sachez que la réplication sur plusieurs sites ne s'effectue qu'à certains intervalles. Par conséquent, les mises à jour sur une surface de contrôleur de domaine sur site vers Google Cloud ne s'effectuent qu'après un délai (et inversement).
• Nous vous recommandons d'utiliser des RODC pour le domaine étendu. Veillez toutefois à autoriser la mise en cache des mots de passe afin de conserver certains avantages en matière de disponibilité par rapport au modèle de forêt de ressources.

Étapes suivantes

• Obtenez davantage d'informations sur le service Microsoft AD géré.
• Passez en revue les bonnes pratiques pour le déploiement d'une forêt de ressources Active Directory sur Google Cloud.
• Découvrez comment déployer un environnement Active Directory tolérant aux pannes sur Google Cloud.
• Prenez connaissance des bonnes pratiques en matière de conception des VPC.
• Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Cloud Architecture Center.