La délégation restreinte basée sur les ressources (RBCD) est une fonctionnalité de sécurité Active Directory (AD) qui permet aux administrateurs de déléguer des autorisations afin de gérer les ressources de manière plus sûre et avec un meilleur contrôle. Introduite dans Windows Server 2012 R2 en tant qu'amélioration de la délégation restreinte traditionnelle Kerberos (KCD), la RBCD peut contribuer à réduire le risque d'escalade des privilèges et à maintenir le principe du moindre privilège.
Pourquoi utiliser la délégation sous contrainte basée sur les ressources ?
En utilisant la RBCD pour déléguer des autorisations à un niveau granulaire, les administrateurs peuvent s'assurer que les utilisateurs et les services disposent de l'accès minimum requis pour effectuer leurs tâches. Le maintien de ce niveau de moindre privilège réduit le risque d'accès non autorisé ou d'utilisation abusive d'informations sensibles.
La délégation restreinte basée sur les ressources est particulièrement utile pour les comptes de service qui doivent accéder aux ressources au nom des utilisateurs, mais qui ne doivent pas avoir un accès complet aux comptes des utilisateurs. Dans le cadre de la délégation basée sur les ressources, la délégation des autorisations est basée sur les ressources plutôt que sur les comptes de service qui accèdent à ces ressources.
La RBCD permet aux administrateurs d'accorder à des utilisateurs ou groupes spécifiques la possibilité de se faire passer pour d'autres utilisateurs lorsqu'ils accèdent à une ressource particulière, sans pour autant leur accorder des autorisations générales pour toutes les ressources du domaine. Par exemple, supposons que :
- Une application doit accéder à un partage de fichiers mais ne doit pas pouvoir supprimer ou modifier les fichiers qui s'y trouvent. En activant la fonction RBCD, vous pouvez configurer le compte du service d'application de manière à ce qu'il se fasse passer pour un utilisateur lors de l'accès au partage de fichiers. Ainsi, le compte n'aura accès qu'aux fichiers dont l'application a besoin.
- Une application interagit avec une base de données. Pour renforcer la sécurité et contrôler l'accès à la base de données, vous pouvez utiliser la RBCD pour déléguer des autorisations au compte du service d'application, ce qui lui permet d'usurper l'identité des utilisateurs lorsqu'ils accèdent à la base de données.
Comment activer la délégation contrainte basée sur les ressources
Pour permettre l'utilisation de la délégation contrainte basée sur les ressources, vous devez modifier l'attribut AD msDS-AllowedToActOnBehalfOtherIdentity. Vous modifiez l'attribut pour spécifier les principaux responsables de la sécurité (tels que les utilisateurs ou les groupes) autorisés à déléguer leurs privilèges à un service s'exécutant sur l'ordinateur.
Une fois configurés, les mandants de sécurité spécifiés peuvent alors déléguer leurs privilèges au compte de service qui exécute le service. Cette délégation permet au service d'usurper l'identité de ces principaux lorsqu'il accède aux ressources. Le service peut alors accéder aux ressources au nom des utilisateurs sans avoir besoin d'autorisations excessives. Cette approche permet de maintenir le principe du moindre privilège et de renforcer la sécurité.
Pour configurer l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity, vous pouvez utiliser PowerShell ou des utilitaires basés sur le protocole LDAP (Lightweight Directory Access Protocol). Pour éviter tout accès non autorisé et maintenir un environnement sécurisé lors de la modification de l'attribut, n'accordez des autorisations de délégation qu'aux principaux responsables de la sécurité nécessaires.
Délégation restreinte basée sur les ressources et risques de sécurité AD
La modification de l'attribut msDS-AllowedToActOnBehalfOtherIdentity peut avoir des conséquences sur la sécurité si elle n'est pas effectuée avec précaution et avec l'attention nécessaire. Voici quelques-uns des risques encourus :
- L'escalade des privilèges : Un compte de service ou un utilisateur obtient un accès non autorisé à des ressources.
- Augmentation de la surface d'attaque : Un attaquant exploite les autorisations déléguées d'un service ou d'un compte d'utilisateur compromis pour accéder à des ressources sensibles ou effectuer des actions malveillantes.
- Complexité et difficultés de gestion : La gestion et la maintenance de l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity peuvent s'avérer complexes, en particulier dans les grands environnements comportant de multiples comptes de service et ressources. Des configurations erronées ou des incohérences peuvent entraîner des failles de sécurité ou des conséquences involontaires.
- Difficultés d'audit et de contrôle : Le suivi et l'audit de l'utilisation des autorisations déléguées peuvent s'avérer difficiles et nécessitent une journalisation et une surveillance supplémentaires pour garantir que les autorisations déléguées sont utilisées de manière appropriée et sécurisée.
Un autre risque de sécurité potentiel dans le contexte de la délégation contrainte basée sur les ressources concerne le compte krbtgt. Il est possible de configurer la délégation Kerberos sur le compte krbtgt lui-même. Cette possibilité est préoccupante en raison du rôle critique que joue le compte krbtgt dans le processus d'authentification Kerberos.
L'authentification ne nécessite que des autorisations d'écriture génériques, ce qui constitue un niveau de privilège inférieur aux droits d'administration du domaine. Cela signifie qu'un attaquant, même s'il n'a obtenu que des autorisations limitées, peut être en mesure de manipuler les paramètres de délégation du compte krbtgt sans avoir besoin d'un accès administratif complet au domaine.
Cette situation potentiellement dangereuse peut créer une vulnérabilité dans le processus d'authentification Kerberos. Un attaquant qui réussit à exploiter cette vulnérabilité peut être en mesure d'obtenir un accès non autorisé à des ressources ou d'effectuer des actions malveillantes dans le domaine, ce qui entraîne de graves failles de sécurité. Les exemples incluent la génération d'une requête de ticket TGS (Ticket Granting Service) vers le compte krbtgt en tant qu'utilisateur, ce qui a pour effet de générer un ticket d'octroi de ticket (Ticket Granting Ticket) similaire à un Golden Ticket.
Les problèmes ne s'arrêtent pas là. Il a été découvert que ce risque de sécurité peut également se produire dans certains environnements Azure AD. Lorsque vous utilisez Azure AD et que vous activez la fonction Seamless SSO, un objet de compte d'ordinateur automatique nommé AZUREADSSOACC est généré au sein de votre locataire. Lorsque cet objet est configuré avec RBCD, tout utilisateur ajouté à l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity de cet objet peut se faire passer pour n'importe quel utilisateur au sein du groupe dans Azure AD.
Par conséquent, vous devez vous assurer que l'attribut de cet objet reste vide et n'est jamais configuré. Si vous découvrez que l'attribut a été configuré, il est fort probable que votre système ait été compromis, ce qui expose votre groupe Azure AD à un risque important.
Évaluer et corriger les risques de sécurité de la RBCD
Pour identifier les erreurs de configuration et les failles de sécurité potentielles et pour déterminer si la sécurité de votre Active Directory a été compromise, vous devez effectuer des analyses de sécurité AD périodiques.
Vous pouvez utiliser des outils tels que Purple Knight ou Semperis Directory Services Protector (DSP). Lorsqu'ils sont exécutés dans votre environnement, ces outils analysent et recherchent des indicateurs spécifiques, y compris les signes des exploits dont il est question ici.
Ces analyses peuvent vous aider à répondre à d'importantes questions relatives à la sécurité AD :
- Le compte krbtgt est-il configuré avec la RBCD ?
- La configuration est-elle correcte ?
- Des utilisateurs ont-ils le droit de configurer la RBCD sur le compte krbtgt ?
- Qui peut demander un ticket TGS avec les autorisations de l'objet sur lequel il a été configuré, comme le compte krbtgt et tous les contrôleurs de domaine (DC) de la forêt ?
Purple Knight et DSP examinent spécifiquement le compte krbtgt et les objets DC, mais englobent également tous les objets informatiques. Il est très peu probable que cette alerte apparaisse dans un environnement AD classique et non compromis. Si elle est détectée, elle indique clairement que votre système a été compromis.
La figure 1, par exemple, montre un rapport identifiant le compte krbtgt avec la RBCD activée pour un hacker.
La figure 2 montre un rapport qui identifie le même problème pour les DC de l'environnement.
La figure 3 montre un rapport identifiant le risque de sécurité dans un environnement Azure AD.
Gérer judicieusement la RBCD pour maintenir la sécurité d'AD
La délégation restreinte basée sur les ressources peut être une fonction de sécurité AD puissante pour les administrateurs qui souhaitent déléguer des autorisations avec un contrôle et une sécurité accrus. Cependant, malgré ses avantages, la délégation basée sur les ressources nécessite une gestion et un contrôle minutieux de ses configurations afin d'éviter les risques et les vulnérabilités en matière de sécurité.
Des analyses de sécurité régulières, une bonne gestion des autorisations et le respect du principe du moindre privilège sont essentiels au maintien d'un environnement sécurisé. En comprenant et en traitant les risques potentiels associés à la RBCD, les administrateurs peuvent tirer parti de ses capacités pour améliorer la sécurité et l'efficacité de leur infrastructure Active Directory.
En savoir plus sur la sécurité AD
