Risques de la délégation Kerberos

J'ai passé des heures et des heures à essayer d'apprendre et de comprendre l'authentification Windows, Kerberos, SPN et la délégation contrainte dans IIS 7.5. Je ne comprends tout simplement pas pourquoi il est «risqué» de laisser la délégation activée (c'est-à-dire de ne pas désactiver la délégation pour les comptes sensibles) pour les administrateurs, les PDG, etc. Quelqu'un peut-il m'expliquer cela en termes simples? Veuillez encadrer votre réponse par rapport à un environnement intranet.

Mon raisonnement est que cela ne devrait pas être un problème, car la délégation permet simplement à un serveur Web frontal, par exemple, d'agir au nom de la personne authentifiée Windows lors de la communication avec d'autres serveurs. Si la personne y a accès, elle y a accès, je ne comprends pas pourquoi cela devrait être une préoccupation.

Veuillez pardonner mon ignorance. Je suis principalement un développeur, mais mon entreprise fonctionne très maigre ces jours-ci et je suis obligé de porter le chapeau d'administration du serveur aussi ... malheureusement, il ne convient toujours pas très bien, lol.

Deux exemples:

1. La délégation contrainte permet l'emprunt d'identité sans avoir les informations d'identification ou le jeton d'authentification de l'utilisateur. Pour un exemple, voir cette réponse .

2. Dans un scénario de délégation sans contrainte plus typique de la viande et des pommes de terre, que ce soit l'authentification intégrée à Windows ou l'authentification par formulaire, avoir un accès de délégation au jeton d'authentification d'un utilisateur est très puissant. Cela signifie littéralement que le jeton peut être utilisé pour emprunter l'identité de cet utilisateur pour accéder à n'importe quelle ressource réseau. Toute personne impliquée dans ce processus, comme un développeur, pourrait l'utiliser de manière néfaste pour obtenir un accès non autorisé.

Dans les deux exemples, si la case est cochée «le compte est sensible et ne peut pas être délégué», il ne s'agit pas de problèmes de sécurité. Il est également possible d'architecturer un système / une fonctionnalité où ces capacités existent, mais sont étroitement contrôlées.

Cette case doit être cochée pour les comptes administratifs, tels que les membres du groupe Enterprise Admins, car (espérons-le) ces comptes ont rarement besoin d'utiliser des applications qui nécessitent l'emprunt d'identité. C'est également une bonne idée pour les cadres supérieurs qui ont accès à des informations sensibles, comme un CIO, COO, responsable Finance / Trésorerie, etc.

Donc, en fin de compte, Microsoft a fourni cette case à cocher et l'avertissement qui l'accompagne pour une très bonne raison, et elle ne doit pas être ignorée ou prise à la légère, sauf s'il peut être démontré qu'un scénario particulier n'a pas d'exposition au risque indésirable, ou un contrôle compensatoire. Cela implique généralement une vérification par une ou plusieurs personnes qualifiées qui ne sont pas impliquées dans la mise en œuvre ou le développement d'une application ou d'un système.

J'ai configuré des milliers de clients avec la délégation de la plupart des contraintes. Je pense qu'il est important de noter que si vous ne faites pas confiance à votre application (disons déployée sur IIS) ou que vous donnez à votre compte de service délégué les informations d'identification pour que les autres les utilisent librement, la délégation contrainte est probablement une bonne idée. Cependant, si vous ne vous attendez pas à ce que quelqu'un ait la possibilité de réécrire votre application, vous conservez les informations d'identification de votre compte de service en toute sécurité et vous êtes sûr que vos applications ne délégueront que le ou les services pour lesquels elles ont été conçues, n'a généralement rien à craindre. J'ai vu certains clients "soucieux de la sécurité" se concentrer très fortement sur des problèmes comme celui-ci, alors que leurs ressources pourraient être mieux utilisées pour travailler sur de vraies menaces de sécurité ...