La délégation Kerberos permet à un service de demander des ressources ou d'effectuer des actions au nom d'un utilisateur, tout en conservant les principes de sécurité d'authentification et d'autorisation.
Délégation au sein Kerberos joue un rôle central en facilitant des interactions sécurisées et transparentes entre les services au nom des utilisateurs.
Kerberos, pierre angulaire des architectures de sécurité réseau modernes, offre un cadre robuste pour authentifier les utilisateurs et les services sur un réseau non sécurisé. Il élimine le besoin de transmettre directement les mots de passe, en utilisant plutôt des tickets cryptographiques pour prouver l’identité. Cependant, dans des environnements informatiques complexes, des situations surviennent fréquemment dans lesquelles un service doit agir au nom d'un utilisateur pour accéder à d'autres services. Cette exigence a conduit au développement de la délégation Kerberos.
Cette capacité est vitale dans les scénarios où les processus lancés par l'utilisateur impliquent plusieurs niveaux de services, chacun nécessitant protocoles d'authentification. Le concept peut paraître simple, mais sa mise en œuvre et les considérations de sécurité qu’il implique sont complexes et nuancées. Il est essentiel que les professionnels de l'informatique et de la cybersécurité comprennent les mécanismes, les applications et les risques associés à la délégation Kerberos pour sécuriser efficacement leurs environnements.
Comment fonctionne la délégation Kerberos
Le protocole Kerberos a été conçu à l'origine pour un environnement réseau plus simple, dans le but d'authentifier les utilisateurs auprès de services accessibles directement. La nécessité pour les services de communiquer au nom des utilisateurs est devenue évidente à mesure que les infrastructures informatiques évoluaient vers des architectures plus stratifiées et intégrées. Afin de s'adapter à ce changement, Kerberos a développé la délégation, permettant des interactions plus complexes tout en maintenant les garanties de sécurité.
Le processus de délégation dans Kerberos implique plusieurs étapes clés :
- L'utilisateur s'authentifie auprès du centre de distribution de clés Kerberos (KDC) et reçoit un ticket d'octroi de tickets (TGT).
- Lors de l'accès à un service nécessitant une délégation, le service demande un ticket de service au KDC au nom de l'utilisateur, indiquant la nécessité d'accéder à un autre service en aval.
- Le KDC émet un ticket de service que le service initial peut utiliser pour demander l'accès au service en aval au nom de l'utilisateur.
Ce mécanisme garantit que les informations d'identification des utilisateurs ne sont jamais exposées aux services, conformément aux principes de sécurité de Kerberos.
Types de délégation Kerberos
Pour répondre à différents niveaux de besoins de sécurité et d'architectures d'applications, trois types différents de délégation Kerberos ont été développés. Ces types de délégation (délégation sans contrainte, contrainte et contrainte basée sur les ressources) offrent chacun différents mécanismes permettant aux services d'agir au nom des utilisateurs, avec des contrôles spécifiques sur les services accessibles.
Délégation sans contrainte
Il s'agit de la forme de délégation la plus permissive au sein de Kerberos, permettant à un service de demander l'accès à tout autre service au nom de l'utilisateur. Avec délégation sans contrainte, une fois qu'un utilisateur s'authentifie auprès d'un service, ce service peut obtenir des tickets pour tout autre service pour l'utilisateur.
Cette forme de délégation est puissante mais présente des risques de sécurité importants si elle n'est pas soigneusement gérée, car elle accorde essentiellement au service des pouvoirs étendus pour agir au nom de l'utilisateur.
Délégation contrainte
Introduite pour atténuer les risques associés à la délégation sans contrainte, la délégation contrainte limite les services auxquels un délégué peut demander l'accès au nom de l'utilisateur. Cela nécessite de spécifier à l'avance quels services sont autorisés à être délégués, fournissant ainsi un environnement contrôlé et sécurisé pour que la délégation ait lieu.
Cette configuration repose sur l'extension Service for User to Proxy (S4U2Proxy), qui permet à un service d'obtenir un ticket pour un service spécifique au nom de l'utilisateur, mais uniquement si ce service est explicitement autorisé.
Délégation contrainte basée sur les ressources
Une évolution de la délégation contrainte, la délégation contrainte basée sur les ressources, améliore encore la sécurité et la flexibilité en permettant à l'administrateur du service cible de contrôler quels services peuvent lui déléguer.
Introduit en Windows Server 2012, ce type déplace la configuration de la délégation du contrôleur de domaine vers la ressource elle-même. Il exploite les extensions Service for User to Self (S4U2Self) et S4U2Proxy pour permettre à un service de demander l'accès au nom de l'utilisateur en fonction des autorisations définies au niveau des ressources, et non globalement sur l'ensemble du domaine.
Chaque type de délégation répond à des préoccupations de sécurité et à des besoins opérationnels spécifiques :
- Délégation sans contrainte convient aux environnements hautement fiables où la facilité d'utilisation l'emporte sur le potentiel d'abus.
- Délégation contrainte fournit une approche équilibrée, offrant de la flexibilité tout en limitant considérablement les risques d'utilisation abusive en restreignant la délégation à des services spécifiés.
- Délégation contrainte basée sur les ressources offre le plus haut niveau de contrôle et de sécurité, permettant aux propriétaires de ressources de gérer directement quels services peuvent agir en leur nom, minimisant ainsi le risque de délégation non autorisée.
Considérations et risques de sécurité
Les considérations et les risques de sécurité sont primordiaux dans le monde complexe de la délégation Kerberos. Chaque type de délégation (sans contrainte, contrainte et contrainte basée sur les ressources) comporte des vulnérabilités spécifiques qui pourraient potentiellement être exploitées si elles ne sont pas correctement gérées. Comprendre ces risques et les mesures pour les atténuer est essentiel pour maintenir l’intégrité et la sécurité d’un environnement informatique.
Risques de délégation sans contrainte
- Le risque le plus important lié à une délégation sans contrainte est la possibilité d'un compromis compte de service être utilisé pour accéder à tout autre service au sein du réseau au nom des utilisateurs. Cela pourrait conduire à les déplacements verticaux et élévations de privilèges et un mouvement latéral au sein du réseau si des attaquants prennent le contrôle d'un tel compte.
- Les stratégies d'atténuation consistent notamment à limiter l'utilisation de la délégation sans contrainte à des services hautement fiables, à utiliser des formes de délégation plus sécurisées lorsque cela est possible et à recourir à une surveillance et à un audit stricts pour détecter les activités inhabituelles.
Risques de délégation contraints
- Même si une délégation limitée limite la portée des services auxquels un compte délégué peut accéder, des erreurs de configuration ou des paramètres trop permissifs peuvent néanmoins présenter des opportunités pour les attaquants. Par exemple, si un compte de service est autorisé à déléguer à des services sensibles et que ce compte est compromis, l'impact pourrait être substantiel.
- L'atténuation de ces risques implique de revoir régulièrement les services autorisés dans l'attribut msDS-AllowedToDelegateTo et de garantir que seuls les services nécessaires sont autorisés.
Risques de délégation contrainte basée sur les ressources
- La décentralisation de la délégation de pouvoir aux propriétaires de ressources augmente la flexibilité mais introduit également le risque de politiques ou de configurations de sécurité incohérentes entre différentes ressources. Si un propriétaire de ressource autorise par inadvertance la délégation d’un service non sécurisé, cela pourrait compromettre la ressource.
- Pour atténuer ces risques, les organisations doivent établir des politiques claires pour configurer une délégation limitée basée sur les ressources, proposer une formation aux propriétaires de ressources et mener des audits réguliers pour garantir le respect des meilleures pratiques de sécurité.
Comment identifier si Kerberos est utilisé
Il existe quelques méthodes que vous pouvez utiliser pour identifier la présence de Kerberos :
- Vérifiez les journaux système :
- Sur les systèmes Linux, les événements d'authentification Kerberos sont généralement enregistrés dans /var/log/messages ou /var/log/syslog.
- Sur les systèmes Windows, ils se trouvent généralement dans l'Observateur d'événements sous la catégorie « Sécurité ».
- Recherchez les erreurs ou les avertissements liés à Kerberos.
- Les messages d'erreur courants incluent :
- "KDC_ERR_SERVER_NOT_FOUND"
- "KDC_ERR_CLIENT_NOT_TRUSTED"
- "KDC_ERR_INVALID_CREDENTIAL"
- "KRB5KDC_ERR_ETYPE_NOSUPP"
- "KRB5KDC_ERR_PREAUTH_FAILED"
- Recherchez les fichiers de configuration Kerberos :
- Sur les systèmes Linux, les fichiers de configuration Kerberos se trouvent généralement dans /etc/krb5.conf.
- Sur les systèmes Windows, ils se trouvent généralement dans %WINDIR%\krb5.ini.
- Vérifiez les fichiers de configuration pour les erreurs ou les incohérences.
- Assurez-vous que le domaine Kerberos est correct et que les serveurs KDC sont correctement répertoriés.
- Vérifiez le registre :
- Sur les systèmes Windows, la configuration Kerberos est également stockée dans le registre.
- La clé de registre appropriée est HKLM\SYSTEM\CurrentControlSet\Services\Kdc.
- Vérifiez la clé de registre pour les erreurs ou les incohérences.
- Assurez-vous que le domaine Kerberos est correct et que les serveurs KDC sont correctement répertoriés.
- Utilisez un renifleur de réseau :
- Un renifleur de réseau peut être utilisé pour capturer le trafic d'authentification Kerberos.
- Cela peut être utile pour résoudre les problèmes Kerberos ou pour surveiller l'activité Kerberos.
- Recherchez des erreurs ou des anomalies dans le trafic Kerberos.
- Utilisez un outil de test Kerberos :
- Il existe un certain nombre d'outils de test Kerberos disponibles qui peuvent être utilisés pour tester le processus de configuration et d'authentification Kerberos.
- Certains de ces outils incluent:
- kinite
- cliste
- kdcdiag
- krb5-test-client
- serveur de test krb5
- Utilisez les outils de test Kerberos pour tester le processus de configuration et d'authentification Kerberos.
- Recherchez des erreurs ou des incohérences dans les résultats des tests.
Configuration et gestion
La configuration et la gestion de la délégation Kerberos constituent une étape essentielle pour garantir qu'elle remplit son objectif sans compromettre la sécurité. Chaque type de délégation (sans contrainte, contrainte et contrainte basée sur les ressources) nécessite des étapes de configuration spécifiques, impliquant à la fois le Active Directory environnement et paramètres de service individuels.
Délégation sans contrainte :
- Activez-le sur un compte de service en définissant l'indicateur TRUSTED_FOR_DELEGATION dans le fichier Active Directory compte d'utilisateur .
- Aucune restriction n'est imposée sur les services pour lesquels le délégué peut demander des billets au nom de l'utilisateur, ce qui rend cruciale une sélection minutieuse des comptes pour ce type de délégation afin d'éviter les risques de sécurité.
Délégation contrainte (S4U2Proxy) :
- Configurez en spécifiant les services auxquels un compte de service particulier peut présenter des informations d'identification déléguées. Cela se fait en modifiant l'attribut msDS-AllowedToDelegateTo dans le compte de service. Active Directory objet.
- Nécessite la définition de l'indicateur TRUSTED_TO_AUTH_FOR_DELEGATION sur le compte de service si la transition de protocole (S4U2Self) sera également utilisée, permettant aux services de demander des tickets au nom des utilisateurs sans authentification Kerberos initiale.
Délégation contrainte basée sur les ressources :
- Configurez en définissant des autorisations sur le service cible Active Directory objet, en particulier dans l’attribut msDS-AllowedToActOnBehalfOfOtherIdentity. Cela permet au propriétaire de la ressource de contrôler quels services peuvent lui déléguer directement.
- Contrairement à la délégation contrainte traditionnelle, la délégation contrainte basée sur les ressources ne nécessite pas de modifications sur le compte de service du délégué, ce qui simplifie la gestion et augmente la flexibilité.
Conclusion
La délégation Kerberos offre un cadre robuste qui permet aux utilisateurs de répondre aux exigences de sécurité complexes des environnements réseau modernes. Grâce à la délégation, Kerberos est devenu une solution permettant d'authentifier les utilisateurs sur des réseaux non sécurisés. Même si cette capacité est puissante, elle nécessite une compréhension globale et une gestion méticuleuse si l’on veut l’exploiter efficacement tout en atténuant les risques de sécurité inhérents.
Dans toutes les formes de délégation Kerberos, les considérations de sécurité sont de la plus haute importance. En raison du risque d'abus ou de mauvaise configuration, d'une gestion vigilante, d'audits réguliers et du principe de moindre privilège sont nécessaires. En comprenant les risques spécifiques associés à chaque type de délégation et en employant les meilleures pratiques, les organisations peuvent réduire considérablement les vulnérabilités.
Conformité avec la cyber assurance : MFA pour les accès administrateurs et Active Directory
Réévaluez votre protection MFA – eBook
