Obtenir une vue d'ensemble des droits d'accès dans un réseau Microsoft peut s'avérer une tâche difficile, comme peuvent en témoigner tous ceux qui ont récemment fait l'objet d'un audit. La collecte et l'organisation des données de sécurité en rapports détaillés peuvent prendre beaucoup de temps et d'efforts. Il existe de multiples raisons pour lesquelles le processus de collecte des données est difficile et prend du temps, mais le facteur commun est que les informations de sécurité sont dispersées dans de multiples magasins de sécurité.
Dans un environnement Windows, les informations de la base de données de sécurité sont dispersées selon les méthodes suivantes :
- Les principes de sécurité (utilisateurs et groupes) sont dispersés dans Active Directory et dans les bases de données de sécurité des serveurs membres (SAM).
- Les groupes peuvent être profondément imbriqués (par exemple, le groupe A est dans le groupe B est dans le groupe C est dans ....).
- L'appartenance à un groupe peut s'étendre à plusieurs bases de données de sécurité (par exemple, les administrateurs du domaine se trouvent dans les administrateurs du serveur).
- Un domaine Windows peut faire confiance à d'autres domaines Windows et à des domaines Kerberos externes.
- Des listes de contrôle d'accès (ACL) existent sur l'objet à sécuriser.
S'il est efficace de stocker les informations dans un magasin unique, il peut s'avérer difficile d'établir des rapports sur ces informations. Les outils administratifs actuels n'ont pas la sophistication nécessaire pour fournir un véritable rapport d'accès, car ils sont à un ou deux pas de fournir une vue holistique de l'accès. Les déclarations suivantes soulignent certaines des limites des outils d'administration qui empêchent d'établir des rapports efficaces sur l'accès.
- Les outils d'administration imposent une vision limitée du processus administratif et se concentrent sur la tâche immédiate plutôt que sur l'ensemble du cycle de vie de la gestion des identités et des accès. Il incombe donc aux administrateurs de valider les paramètres dans un autre outil ou de s'assurer que les autres processus ont été exécutés correctement.
- Les outils administratifs ne fournissent pas les liens nécessaires pour rendre compte de l'utilisation de l'identité dans l'environnement.
- Les outils d'administration reposent sur le fait que d'autres fonctions de provisionnement ont été correctement exécutées. (par exemple, l'ajout d'un groupe à une liste de contrôle d'accès ne permet pas à l'administrateur d'ajuster l'appartenance à un groupe, car cela nécessite un outil distinct avec un objectif distinct).
Comme les outils administratifs actuels ne dépassent pas leur contexte de sécurité actuel, le personnel administratif doit se rendre dans chaque magasin, extraire les données et les fusionner manuellement pour en faire des rapports pertinents.
Résoudre le(s) défi(s)
Alors que je créais une solution, que CSS a publiée l'année dernière sous la forme d'un outil software appelé Distributed Authorization Reporting Tool (DART), j'ai été confronté à de nombreux défis qui devaient être résolus. La découverte de groupes a sans doute été l'obstacle le plus important rencontré au cours du développement de la solution. La façon dont les groupes fonctionnaient et interagissaient, par exemple, a rendu le processus de codage vraiment intéressant :
Les groupes ont plusieurs types (locaux, globaux et universels) et peuvent être sécurisés.
- Les groupes peuvent avoir des (sous) groupes comme membres
- Les groupes peuvent être profondément imbriqués. Au fur et à mesure que le niveau d'imbrication augmente, le nombre de groupes auxquels un utilisateur doit être associé dans les rapports augmente de façon exponentielle. Par exemple, un domaine comptant 20 000 utilisateurs et 12 000 groupes peut rapidement devenir 1 600 000 relations de sécurité.
- Les groupes peuvent être imbriqués dans les bases de données de sécurité (par exemple, les administrateurs de domaine dans le groupe Administrateurs d'un serveur membre).
- Les groupes peuvent compter plus de 5 000 membres, ce qui nécessite un traitement spécial lors de l'énumération des membres.
- L'appartenance d'un utilisateur à un groupe n'est pas nécessairement accordée par le fait d'être "membre" d'un groupe. L'appartenance à un groupe peut également être calculée.
Tous les utilisateurs ne font pas partie du groupe calculé "utilisateurs du domaine". Le groupe principal d'un utilisateur peut être réaffecté à un autre groupe. La leçon à retenir est que vous ne pouvez pas traiter tous les utilisateurs comme des membres du groupe simplement parce qu'ils appartiennent à ce domaine.
Au fur et à mesure que j'abordais chaque problème, je me suis rapidement rendu compte que les relations entre les données de sécurité seraient essentielles à l'élaboration d'une solution. Comme je l'ai découvert, la clé de la solution consistait à construire un tableau montrant la relation entre les utilisateurs et les groupes, qui pouvait être facilement comparée à une liste de contrôle d'accès. J'aime appeler ces associations des "chaînes de sécurité", car elles montrent l'utilisateur et la manière dont il est devenu membre d'un groupe particulier.
Restez à l'écoute pour mon prochain article de blog dans la série : La PIM reste la même...
