Tout sur la portée de groupe AGDLP pour Active Directory – Compte, global, local de domaine, permissions

Récemment, j’ai reçu quelques questions de clients potentiels sur la portée de groupe de sécurité AD. Je voulais prendre une minute pour donner un aperçu de ce que sont les portées de groupe et pourquoi elles sont significatives. Je vais également parler un peu des modèles de meilleures pratiques de Microsoft pour l’utilisation de la portée du groupe et discuter de certains des points positifs et négatifs de chacun.

La portée du groupe est importante à comprendre si vous voulez contrôler efficacement les risques dans la façon dont vous utilisez les groupes AD. La portée d’un groupe détermine où le groupe peut être appliqué dans la forêt ou le domaine. L’étendue détermine également qui peut être membre d’un groupe. Microsoft n’ayant pas intégré à Active Directory de nombreuses limitations concernant les groupes qui peuvent être imbriqués les uns dans les autres, l’imbrication des groupes peut présenter des risques opérationnels et de sécurité considérables pour une organisation. La seule aide réelle qu’offre AD pour combattre les risques potentiels de l’imbrication des groupes de sécurité est la portée du groupe.

Il existe trois portées de groupe : universelle, globale et locale au domaine. Chaque portée de groupe définit les membres possibles d’un groupe et où les autorisations du groupe peuvent être appliquées au sein du domaine. Le tableau ci-dessous, tiré directement de Microsoft Technet, présente l’ensemble des règles relatives à l’étendue des groupes. Mais les règles ne sont que la moitié de l’histoire. L’autre moitié, plus importante, réside dans la compréhension de la manière d’utiliser et d’appliquer correctement ces scopes.

Portée du groupe Le groupe peut inclure comme membres… Le groupe peut se voir attribuer des permissions dans… La portée du groupe peut être convertie en….
Universal
  • Accounts from any domain within the forest in which this Universal Group resides
  • Global groups from any domain within the forest in which this Universal Group resides
  • Universal groups from any domain within the forest in which this Universal Group resides
Any domain or forest
  • Domain local
  • Global (as long as no other universal group exist as members)
Global
  • Accounts from the same domain as the parent global group
  • Global groups from the same domain as the parent global group
Member permissions can be assigned in any domain Universal (as long as no other domain local groups exist as members)
Domain Local
  • Accounts from any domain
  • Global groups from any domain
  • Universal groups from any domain
  • Domain local groups but only from même domaine que le groupe local du domaine parent
Les autorisations des membres ne peuvent être attribuées que dans le même domaine que le groupe local du domaine parent Universel (tant qu’aucun autre groupe local de domaine n’existe en tant que membre)

Le but d’une AD bienL’objectif d’un DA bien architecturé est de fournir aux utilisateurs appropriés ni plus ni moins que les niveaux d’accès nécessaires aux informations et aux ressources dont ils ont besoin pour faire leur travail. Les modèles de sécurité basés sur les rôles, les attributs et les ressources sont autant de moyens différents utilisés par les organisations pour atteindre cet objectif dans l’ensemble de l’infrastructure informatique, y compris AD. Une bonne compréhension de la portée des groupes et de la manière de l’appliquer est nécessaire pour réaliser ces modèles dans l’environnement. AGDLP et AGUDLP sont les modèles structurels de meilleures pratiques de Microsoft pour l’architecture AD et ils peuvent aider les organisations à suivre ces modèles de sécurité.

Le modèle AGDLP fournit un guide sur la façon d’imbriquer les groupes les uns dans les autres sans compromettre la sécurité ou sacrifier l’efficacité opérationnelle. Le modèle stipule ce qui suit : Les comptes d’utilisateurs et d’ordinateurs doivent être membres de groupes globaux, qui sont à leur tour membres de groupes locaux de domaine qui décrivent les autorisations de ressources.

Le raisonnement derrière cela peut être un peu délicat, mais je vais faire de mon mieux pour le décomposer ici. Les groupes globaux sont utilisés pour contenir les comptes d’utilisateurs et d’ordinateurs et peuvent inclure d’autres groupes globaux du même domaine. Considérez les groupes globaux comme des « groupes de comptes ». Ces groupes comprendront des utilisateurs qui se ressemblent dans le sens où ils font tous partie du même domaine, puisque les groupes globaux ne peuvent pas contenir de membres d’autres domaines. Les utilisateurs auront probablement d’autres points communs, tels que le fait d’appartenir au même service, d’avoir le même responsable, ou toute autre similarité de cette nature. Par exemple, tous les utilisateurs qui font partie du département marketing du siège social de New York d’une entreprise seraient mis dans le même groupe global appelé « Marketing ».

En raison de la flexibilité de leurs restrictions d’adhésion, les groupes locaux de domaine sont idéaux pour accorder des autorisations sur les ressources. Plus précisément, ces groupes sont utilisés parce que des groupes du domaine parent ainsi que d’autres domaines et forêts de confiance peuvent y être ajoutés. Cela permet aux administrateurs d’accorder l’accès à une ressource à toute personne de l’environnement si elle en a besoin. Si les groupes globaux sont les « groupes de comptes », les groupes locaux du domaine sont les « groupes de ressources ». Un exemple de groupe de ressources en action peut être un groupe local de domaine qui accorde l’accès à un partage de fichiers appelé « Documents de marketing ». En imbriquant le groupe global « New York Marketing » dans le groupe local de domaine « Documents de marketing », nous venons de donner à tous les utilisateurs du département marketing de New York l’accès au contenu du partage « Documents de marketing ». Voici une représentation graphique de ce scénario AGDLP:

AD Workflow

L’utilisation des groupes locaux de domaine devient particulièrement importante lorsque vous avez affaire à des situations impliquant des forêts de confiance. Dans un cas comme celui-ci, il y a de bonnes chances que les comptes d’une forêt aient besoin d’accéder aux ressources de l’autre forêt. Si un groupe global était utilisé pour accorder l’accès à une ressource, il n’y aurait aucun moyen pour les comptes de la deuxième forêt d’avoir accès à cette ressource, puisque les comptes et les groupes ne peuvent pas être imbriqués dans des groupes globaux d’un domaine ou d’une forêt différents.

Pour continuer avec notre exemple, peut-être que notre entreprise fictive acquiert une autre entreprise à Miami et que les groupes informatiques décident de faire confiance aux forêts des deux entreprises ensemble. Si nous suivons le modèle AGDLP, le département marketing de l’entreprise de Miami devrait avoir son propre groupe global dans sa forêt. Afin de donner au département marketing de la nouvelle société l’accès au partage des documents marketing, tout ce que l’administrateur doit faire est d’imbriquer le groupe global Miami Marketing dans le groupe local du domaine Documents marketing. Voir la représentation graphique ci-dessous pour un aperçu simplifié:

AD Workflow Multiple

Le modèle AGUDLP est très similaire à AGDLP (comme son nom l’indique) mais introduit le « U » pour groupes universels dans l’équation. Les appartenances de ces groupes sont stockées dans le catalogue global, ce qui est davantage une nécessité dans les environnements multi-domaines. L’utilisation de ce modèle dépend vraiment de l’importance accordée au catalogue global dans l’organisation. S’il y a un intérêt direct à ce que le catalogue global soit aussi complet que possible (vous avez peut-être une importante main-d’œuvre mobile et vous comptez beaucoup sur la capacité des employés à se retrouver facilement dans Outlook), alors le modèle AGUDLP vous aidera dans cette entreprise. Cependant, pour les environnements plus petits qui n’ont qu’un seul domaine, ce modèle peut ajouter une couche inutile de complexité.

La raison pour laquelle ces modèles constituent la meilleure pratique de Microsoft est double. Du point de vue de la sécurité, si l’on devait utiliser des groupes globaux pour donner aux utilisateurs des autorisations sur les ressources, il faudrait ajouter des utilisateurs d’autres domaines et forêts dans le domaine où résident les ressources. En général, les domaines et les forêts distincts existent pour une bonne raison et les délimitations entre les domaines et les forêts ne sont pas censées être floues. En utilisant des groupes locaux de domaine pour accorder des autorisations à des ressources spécifiques, un administrateur peut donner aux membres d’autres domaines et forêts l’accès à la ressource sans avoir besoin de leur donner un accès direct au reste du domaine où se trouve cette ressource. Trop souvent, nous voyons des organisations utiliser des groupes globaux pour définir les permissions sur les ressources et finir par surprovisionner les accès et les droits en conséquence lorsque les utilisateurs entrent et sortent du groupe.

D’un point de vue opérationnel, les modèles AGDLP et AGUDLP facilitent également la gestion de l’appartenance à un groupe dans le sens où les permissions et l’organisation des utilisateurs sont gérées dans des endroits distincts. Les permissions des ressources sont définies pour les groupes locaux du domaine et n’ont pas besoin d’être modifiées une fois qu’elles sont déterminées, ce qui limite la fréquence à laquelle il est nécessaire de se rendre sur la ressource pour ajuster ces permissions. En plus de contenir des restrictions intégrées pour l’adhésion, les groupes globaux sont également facilement modifiables et, par conséquent, fournissent un endroit parfait pour que les utilisateurs y résident puisque les utilisateurs se déplacent constamment dans l’organisation nécessitant différents niveaux d’accès.

Il convient de noter que ce n’est pas parce que ces modèles sont les meilleures pratiques de Microsoft qu’ils sont parfaits pour tout le monde. Dans les grands environnements, l’utilisation de groupes locaux de domaine pour gérer les autorisations de ressources peut conduire à la génération d’un très grand nombre de groupes. Cela pourrait faire en sorte qu’un utilisateur soit membre de milliers de groupes au moment où il obtient l’accès à toutes les ressources dont il a besoin et pourrait, à son tour, entraîner des problèmes tels que le token bloat.

En fin de compte, suivre les modèles AGDLP et AGUDLP offre des avantages très réels à une organisation. Le problème réside souvent dans la mise en œuvre de l’infrastructure pour suivre le modèle étant donné qu’il repose sur plus qu’un administrateur avisé pour remuer les groupes dans AD. Ces modèles nécessitent une vigilance et une surveillance constantes de la part de l’informatique pour être appliqués. De nombreuses mesures doivent être prises pour les mettre en œuvre et les maintenir, telles que l’attribution de propriétaires aux groupes qui comprennent les besoins des utilisateurs de ces groupes, la garantie que les bons utilisateurs sont dans les bons groupes et que les groupes contiennent les autorisations correctes sur les ressources.

La bonne nouvelle est qu’il existe des outils qui peuvent aider à ces étapes. StealthAUDIT fournit un point de départ pour mettre les organisations sur la bonne voie en les aidant à comprendre à quels groupes l’accès est actuellement accordé, quels utilisateurs sont dans ces groupes et quels droits ces utilisateurs ont. De plus, StealthAUDIT peut contribuer à la transformation du modèle d’accès d’une organisation et à l’identification des propriétaires de groupes en donnant à l’entreprise le pouvoir de gérer ses propres groupes puisqu’elle sait mieux que quiconque qui a besoin d’accéder à quoi. Bien que l’adoption de l’AGDLP ou de l’AGUDLP puisse représenter un effort monumental, les avantages résiduels peuvent contribuer grandement à assurer un environnement sécurisé et durable.

Découvrez StealthAUDIT ici.

Ne manquez pas un post ! Abonnez-vous au blog de sécurité The Insider Threat ici:

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *