Risques de la délégation Kerberos


8

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.

Réponses:


7

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.


Tout d'abord, une réponse incroyablement utile et approfondie. Je ne peux pas vous dire combien je l'apprécie. :) Je me demande encore ce qui est nécessaire pour que cela soit exploité car les gens n'auront certainement pas accès aux références de notre exécutif. Il convient également de noter que les systèmes que nous autorisons la délégation contrainte sont accessibles à tous les employés du réseau de toute façon. En outre, j'essaie d'accomplir cela avec le mode pipeline intégré et AUCUNE usurpation d'identité ASP.NET.
Chiramisu

1
Même si vous utilisez le mode pipeline intégré, si le jeton d'authentification est présent, il peut être exploité par IIS et quelle que soit l'application en cours d'exécution. Lorsque vous utilisez l'authentification intégrée de Windows, le jeton d'authentification fait partie de l'en-tête http. Il peut être utile d'essayer d'effectuer un test de pénétration sur la configuration proposée pour déterminer si ce que vous pensez est correct.
Greg Askew

Merde! Une partie de l'en-tête HTTP? Il doit au moins être chiffré non? Sinon, c'est juste fou! Pourquoi Microsoft ferait-il même une recommandation aussi ridicule? Je crains de ne pas avoir le premier indice sur les tests au stylo, alors je vais devoir vous croire sur parole. Pourtant, aucune des applications sur ce serveur intranet particulier n'est restreinte en interne, donc je pense que ce serait sûr. Les jetons sont à durée limitée et générés dynamiquement, n'est-ce pas? Nous limitons uniquement certaines pages à l'aide de balises allow/ denyautorisation.
Chiramisu

2

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é ...


J'apprécie grandement vos idées; très utile. J'ai depuis longtemps abandonné la configuration de la délégation sur notre Intranet et suis retombé dans l'exécution d'AppPool dans IIS sous un compte spécial avec accès à la ressource nécessaire telle qu'elle était précédemment configurée. J'espère revoir cette question et trouver une vraie solution, mais le manque de temps et d'expérience avec la délégation empêche cet espoir pour l'instant. :(
Chiramisu
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.