Active Directory : Protégez vos données de Active Directory

Un certain nombre de stratégies vous permettent de vous assurer que seules les bonnes personnes ont accès aux bonnes données au sein de votre infrastructure Active Directory.

Darren Mar-Elia

Adapté de « Protection des données critiques en gérant le cycle de vie identité Active Directory » (Realtime Publishers)

Vous devez protéger vos données d'identité basée sur Active Directory. C' est une partie importante d'assurer n'importe quel système d'identité que vous mis en place qui fonctionne avec Active Directory est protégée, tel qu'il est capable de faire son travail de l'authentification et l'autorisation des bonnes personnes pour les bonnes ressources.

Il faut s'assurer que les données dans Active Directory sont sacro-sainte et seuls les utilisateurs ayant un motif pour accéder aux informations Active Directory sont accordés cet accès. Tous les grands provisionnement identité processus dans le monde ne vous aident pas si votre Active Directory est une foire d'empoigne que n'importe qui peut jouer avec au contenu de son coeur. Vous avez besoin de prendre un regard profond à votre modèle de sécurité Active Directory et de déterminer les meilleures techniques et les meilleures pratiques pour sécuriser les données résidant sur.

Les défis de la sécurisation de Active Directory

Gérer le modèle de sécurité Active Directory n'est pas exactement simple. La nature d'un service de répertoire hiérarchique qui sert beaucoup de moyens (y compris répertoire de l'application, répertoire de l'authentification, répertoire de gestion de bureau et ainsi de suite), le modèle de sécurité peut être une poignée. Plus important encore, si vous ne prenez pas une approche proactive de la gestion de la sécurité de votre Active Directory, il peut rapidement devenir incontrôlables.

Considérons, par exemple, la simple tâche consistant à déléguer la gestion des comptes utilisateur dans Active Directory. En raison de la nature granulaire du modèle de sécurité Active Directory, une tâche apparemment simple comme la gestion des comptes d'utilisateurs puisse évoluer vers un nombre vertigineux d'autorisations, que vous aurez à déléguer :

  • Autorisation de créer des objets utilisateur
  • Autorisation de supprimer des objets utilisateur
  • Autorisation pour déplacer des objets utilisateur
  • Autorisations sur les propriétés de l'objet utilisateur (cela peut décomposer en propriétés sensibles, tels que le département, gestionnaire et appartenances et des propriétés non sensibles telles que l'adresse de bureau et numéro de téléphone)
  • Autorisation pour réinitialiser son mot de passe ou débloquer son compte
  • Autorisation de contrôler qui peut modifier les autorisations de l'utilisateur

Cette liste n'est pas exhaustive, mais elle met en évidence la complexité potentielle d'administration délégation juste cette tâche un. Considérer que chacune de ces tâches (ou au moins des groupes d'entre eux) peut être déléguée à d'autres sous-groupes. Ces jeux d'autorisations pourrait également varier selon l'unité d'organisation (UO) dans lequel sont situés les utilisateurs. Ajouter au mélange qu'objets parents dans Active Directory peuvent hériter des autorisations de leurs enfants (par exemple, les autorisations peuvent se déplacer de l'unité d'organisation Marketing sur l'UO utilisateurs sous Marketing). Vous pouvez voir de choses vraiment peuvent être gommées si vous ne faites pas attention.

Non seulement la complexité du modèle de sécurité Active Directory est difficile, elle exige discipline à établir un modèle de bon de délégation et rangez au fil du temps. Les demandes ponctuelles et commerciales inhabituelles doivent vous conduire à faire des compromis. Le but ultime est de protéger les données dans Active Directory qui est critique pour l'authentification de votre organisation et les mécanismes d'autorisation, il est donc important de garder une poignée sur la sécurité de Active Directory.

Comprendre le modèle de sécurité Active Directory

Modèle de sécurité compréhension Active Directory est de comprendre la structure Active Directory. Pas contrairement à une base de données relationnelle, Active Directory contient un schéma qui définit les classes disponibles, des objets et leurs attributs associés. Un objet utilisateur dans Active Directory est une instanciation de la classe de schéma « user ». Cet objet utilisateur, selon le schéma, contient un ensemble d'attributs tels que prénom, nom, département, manager, numéro de téléphone et ainsi de suite.

Chaque objet dans Active Directory possède également un descripteur de sécurité associé. Ce descripteur de sécurité définit les autorisations sur cet objet. Celles-ci montrent un exemple de jeu d'autorisations de l'objet d'un utilisateur, ou liste de contrôle d'accès (ACL), vu de Active Directory utilisateurs et ordinateurs.

L'ACL est composé d'un ensemble d'entités de sécurité (généralement des utilisateurs ou groupes) qui ont des droits sur cet objet et les droits ou les autorisations associées à chaque entité de sécurité. Une autorisation particulière peut être un « Autoriser » ou « Refuser ». Permettre par défaut. Ceci accorde une autorisation à l'entité de sécurité. Si Deny est sélectionnée, cette autorisation est explicitement refusée à cette entité de sécurité. En effet, si un objet hérite des autorisations de son parent et il se heurtent Allow et Deny entrées de contrôle d'accès (ACE) pour une autorisation donnée, puis généralement Deny va gagner.

Standards et étendues des droits

Pas chaque classe d'objet dans Active Directory a le même jeu d'autorisations associés. C'est super car cela signifie que vous pouvez personnaliser les autorisations pour le type de l'objet impliqué. Considérez cet exemple : une autorisation de « déclencher la réplication » associée à un objet de contexte d'appellation de Active Directory vous permet de déléguer qui peut forcer la réplication entre deux contrôleurs de domaine. Déclencher la réplication n'est pas pertinente pour un objet utilisateur, cependant. En effet, chaque objet possède un ensemble associé de « droits standards ». Citons familiers tels que :

  • Lire
  • Écriture
  • Liste
  • Create
  • Delete
  • Lecture et écriture de propriétés

Au-delà du droit classique, une classe de schéma peut aussi ont étendu les droits. Les exemples familiers des droits étendus sont les autorisations sur un objet ordinateur. Un ordinateur dispose des autorisations telles que "Read et Write les attributs du nom du hôte" spécifique à la classe de l'ordinateur de chaque objet.

L'extensibilité du modèle de sécurité d'Active Directory vous permet de créer une délégation granulaire et riche de tâches pour vos administrateurs et utilisateurs. Si vous étendez le schéma Active Directory avec une nouvelle classe d'objet, elle peut avoir son propre ensemble de droits étendus qui contrôlent la délégation spécifique à ce type d'objet (mais il faut aussi être conscient des différences diverses au sein des classes d'objet que vous souhaitez déléguer).

Comprendre l'héritage de la sécurité

Un autre aspect qui rend le modèle de sécurité Active Directory difficile est la notion d'héritage des autorisations par le biais de la hiérarchie Active Directory. Un jeu d'autorisations au sommet d'un domaine peut couler vers le bas grâce à des unités d'organisation imbriquées aux objets au niveau le plus bas de la hiérarchie du domaine.

Vous pouvez contrôler cet héritage, aussi bien de haut en bas mais aussi de bas en haut. Par exemple, disons que vous voulez régler les autorisations pour les objets utilisateur au sein d'une hiérarchie d'UO composé d'une unité d'organisation Marketing niveau supérieur et deux sous-unités appelées utilisateurs-Orient et l'Occident-utilisateurs. Vous souhaitez tirer parti de l'héritage pour définir des autorisations pour tous les objets utilisateur au niveau de l'unité d'organisation Marketing et ont ce filet vers le bas pour tous les objets utilisateur dans les deux sous-unités. Vous pouvez le faire en créant le nouveau ACE au sein ACL de l'unité d'organisation Marketing (à l'aide de Active Directory utilisateurs et ordinateurs par exemple) et ensuite, après avoir défini les autorisations, faites-le s'appliquent à tous les « objets Descendant utilisateur. »

Si vous exécutiez l'unité d'organisation utilisateurs-East, vous pouvez décider de ne s'appliquent pas les autorisations sur vos objets utilisateur au niveau supérieur. Si vous disposez des autorisations suffisantes, vous pouvez désactiver essentiellement l'héritage qui descend de l'unité d'organisation Marketing. Vous pouvez le faire en décochant simplement la case dans la section avancé de l'éditeur ACL dans Active Directory utilisateurs et ordinateurs. Qui brise cette chaîne d'héritage.

Comprendre la délégation

Dans le cadre d'Active Directory, la délégation est le processus par lequel vous accordez des autorisations d'objets Active Directory. Il permet aux utilisateurs et groupes effectuent des tâches spécifiques contre des objets Active Directory. Délégation implique une sorte de plan méthodique pour donner les bons utilisateurs les bonnes permissions sur les objets Active Directory le droit, dans l'ensemble de votre structure d'Active Directory.

Un exemple de délégation peut être un groupe appelé à aider les administrateurs de bureau, à laquelle tous aider l'équipe Bureau membres appartiennent. Vous pouvez accorder à ce groupe la possibilité de réinitialiser les mots de passe utilisateur sur tous les objets utilisateur dans votre domaine Active Directory. Cela leur permet de gérer une des premières tâches de leur travail. Un autre exemple courant de délégation est laisser les admins à joindre des ordinateurs au domaine. Il s'agit d'un délégué d'autorisations sur des objets ordinateur, généralement appliqué aux unités d'organisation où les objets ordinateur pourraient résider.

Création d'un modèle de délégation pour Active Directory est probablement un des plus importantes tâches de planification que vous pouvez effectuer. Cela est particulièrement vrai lorsqu'il s'agit de déléguer l'accès à des données sensibles, qui s'est tenues dans Active Directory. Il n'est pas grave si vous avez juste déployé Active Directory ou si vous êtes en train de migrer vos 10 ans d'Active Directory vers une nouvelle structure de domaine. Dans les deux cas, il est jamais trop tard pour planifier et créer un modèle de délégation qui protège les objets critiques d'accès Active Directory et délégués convenablement.

Il y a beaucoup de données dans Active Directory qui peuvent et doivent être sécurisés, mais pas tout cela se rapporte à votre système d'identité. La liste suivante met en évidence les zones de commencer par en termes de protection de vos données d'identité dans Active Directory :

**Propriétés de l'utilisateur :**Attributs sur vos utilisateurs peuvent ou peuvent pas être sensibles et requièrent la délégation. Il y a certains attributs, tels que le titre du poste, département et gestionnaire de l'utilisateur — qui sont souvent gérés par le département RH. Si Active Directory est intégré dans un système RH, ces attributs pourraient être gérés par le biais de ce système. Dans ce cas, vous souhaiteriez empêcher tous les utilisateurs d'être en mesure de modifier ces attributs eux-mêmes.

**Appartenances :**Vous pouvez utiliser des groupes pour contrôler l'accès à une variété de ressources, de serveurs de fichiers publics sensibles de base de données. Contrôle qui dispose d'autorisations pour modifier les appartenances aux groupes est probablement l'une des premières étapes que vous devriez prendre dans vos tâches de délégation Active Directory. Cela se traduit qui peut écrire dans l'attribut membres sur des objets de groupe Active Directory. Un utilisateur disposant de cette autorisation peut modifier les appartenances aux groupes.

**OU se déplace :**Bien que les objets tels que les utilisateurs de mobiles entre les unités d'organisation peut sembler assez bénigne du point de vue de la gestion de l'identité, une telle démarche peut souvent avoir des effets en aval. Certaines organisations ont automatisé des processus associés à l'adhésion OU qui pourrait changer les choses, telles que les appartenances aux groupes d'un utilisateur ou quoi les paramètres de stratégie de groupe qu'ils traitent. Ces changements pourraient accorder par inadvertance à l'utilisateur un accès involontaire aux ressources. En conséquence, déplacement d'objets utilisateur OU devrait être étroitement contrôlée.

Outils de délégation

Vous avez peu d'aide en ce qui concerne la délégation. Ceci vient sous la forme de l'Active Directory Users et l'Assistant délégation de contrôle des ordinateurs (DoC). L'Assistant de DoC est disponible lorsque vous cliquez-droit sur un objet de conteneur (par exemple, un domaine ou une unité d'organisation) dans Active Directory utilisateurs et ordinateurs. Essentiellement, il s'avère un ensemble de tâches standards, que vous pouvez déléguer au sein d'Active Directory dans un modèle.

Il vous permet également de créer des tâches de délégation personnalisée en choisissant des classes d'objets et de choisir quels sont les droits dont vous avez besoin sur ces classes. L'Assistant de DoC timbres un jeu d'autorisations que vous avez demandés sur le conteneur avec lequel vous travaillez.

L'Assistant de DoC, tâches délégation simple facile, mais elle a plusieurs inconvénients :

  • Il prend uniquement en charge un petit ensemble de tâches de délégation (bien que vous pouvez étendre le jeu).
  • C'est une moment dans le temps délégation. En d'autres termes, aucun État de la délégation que vous venez de faire n'est conservé. Autorisations sont simplement marquées sur les objets Active Directory sur lequel vous êtes concentré. Vous ne pouvez pas modifier cette délégation, par le biais de l'Assistant, après le fait. Vous devez entrer et modifier manuellement les autorisations sur l'ACL directement.
  • L'Assistant de DoC vous ne donne aucune vue d'ensemble de la délégation à travers votre Active Directory entière. Parce qu'en fin de compte, c'est juste estampage privilèges, il n'y a aucun moyen de « garder une trace » de quelles délégations vous avez fait sans regarder les ACL de chaque objet de Active Directory d'intérêt.

Active Directory délégation meilleures pratiques

Un certain nombre de bonnes pratiques ont émergé au cours des années qui sont à considérer lorsque vous déterminez comment créer votre modèle de délégation et de protéger vos données de Active Directory. Une approche commune est l'approche "axée sur le rôle" à déléguer des tâches au sein d'Active Directory. Il s'agit de la liste des tâches que vous attendez les gens à effectuer au sein d'Active Directory. Cette liste doit être assez longue, comme vous voudrez vraiment étoffer toutes ces choses que vous attendez les gens à faire contre votre Active Directory, surtout quand il s'agit de modifier des objets sensibles.

L'étape suivante consiste à identifier ces groupes d'utilisateurs qui ont besoin d'effectuer chaque tâche ou un rôle. En effectuant ce mappage entre les groupes qui ont besoin d'accéder à Active Directory et les types d'accès que vous souhaitez prendre en charge, vous créez efficacement un modèle de délégation basée sur les rôles que vous pouvez rendre réel à travers les autorisations dans Active Directory.

Vous pouvez concevoir un modèle de délégation de Active Directory qui entonne sécurité d'Active Directory des tâches ou des rôles et puis assigne les tâches aux groupes d'utilisateurs. Cette approche peut grandement simplifier la gestion de la sécurité Active Directory et prenez-le de réactif octroi d'autorisations de gestion proactive d'accès aux données de Active Directory.

Tenir compte de tous ces aspects et leur impact sur le niveau global de sécurité des données stockées dans vos annuaires Active Directory. La combinaison et l'analyse de toutes ces techniques peuvent aider Mettez vos données de Active Directory à un niveau sécuritaire de lockdown.

Darren Mar-Elia

Darren Mar-Elia est MVP de Microsoft Group Policy, créateur du célèbre site sur stratégie de groupe gpoguy.com et co-auteur de "Microsoft Windows Group Policy Guide" (Microsoft Press, 2005). Il est aussi directeur technique et fondateur de SDM Software Inc. Le contacter au Darren@gpoguy.com.

Pour en savoir plus sur cette question et autres titres d'éditeurs en temps réel, consultez le en temps réel éditeurs Web site.

Contenus associés