Risiken der Kerberos-Delegation

Ich habe stundenlang versucht, Windows-Authentifizierung, Kerberos, SPNs und eingeschränkte Delegierung in IIS 7.5 zu lernen und zu verstehen. Eine Sache, die ich einfach nicht verstehe, ist, warum es "riskant" ist, die Delegierung für Administratoren, CEOs usw. aktiviert zu lassen (dh die Delegierung für vertrauliche Konten nicht zu deaktivieren). Kann mir dies bitte jemand in einfachen Worten erklären? Bitte formulieren Sie Ihre Antwort in Bezug auf eine Intranetumgebung.

Ich bin der Meinung, dass dies kein Problem sein sollte, da die Delegierung es einem Front-End-Webserver beispielsweise einfach ermöglicht, bei der Kommunikation mit anderen Servern im Namen der Windows-authentifizierten Person zu handeln. Wenn die Person Zugang hat, hat sie Zugang, ich verstehe nicht, warum dies ein Problem sein sollte.

Bitte vergib mir meine Unwissenheit. Ich bin in erster Linie ein Entwickler, aber meine Firma läuft heutzutage sehr schlank und ich bin gezwungen, auch den Serveradministratorhut zu tragen ... leider passt er immer noch nicht sehr gut, lol.

Zwei Beispiele:

1. Die eingeschränkte Delegierung ermöglicht den Identitätswechsel ohne die Anmeldeinformationen oder das Authentifizierungstoken des Benutzers. Ein Beispiel finden Sie in dieser Antwort .

2. In einem typischeren Szenario mit uneingeschränkter Fleisch-und-Kartoffel-Delegierung ist der Delegierungszugriff auf das Authentifizierungstoken eines Benutzers sehr leistungsfähig , unabhängig davon, ob es sich um eine Windows-integrierte Authentifizierung oder eine Formularauthentifizierung handelt. Das bedeutet wörtlich, dass Token verwendet werden kann, um sich als dieser Benutzer auszugeben und auf eine Netzwerkressource zuzugreifen. Jeder, der an diesem Prozess beteiligt ist, wie z. B. ein Entwickler, kann dies auf schändliche Weise nutzen, um unbefugten Zugriff zu erhalten.

Wenn in beiden Beispielen das Kontrollkästchen "Konto ist vertraulich und kann nicht delegiert werden" aktiviert ist, handelt es sich nicht um Sicherheitsprobleme. Es ist auch möglich, ein System / Feature zu entwerfen, in dem diese Funktionen vorhanden sind, das jedoch streng kontrolliert wird.

Dieses Kontrollkästchen sollte für Administratorkonten aktiviert werden, z. B. für Mitglieder der Gruppe "Unternehmensadministratoren", da diese Konten (hoffentlich) selten Anwendungen verwenden müssen, für die ein Identitätswechsel erforderlich ist. Dies ist auch eine gute Idee für Führungskräfte, die Zugriff auf vertrauliche Informationen haben, z. B. CIO, COO, Leiter Finanzen / Treasury usw.

Unter dem Strich hat Microsoft dieses Kontrollkästchen und die dazugehörige Warnung aus einem sehr guten Grund bereitgestellt. Es sollte nicht verworfen oder leicht genommen werden, es sei denn, es kann nachgewiesen werden, dass ein bestimmtes Szenario keine unerwünschte Risikoexposition oder eine Ausgleichskontrolle aufweist. Dies beinhaltet normalerweise die Überprüfung durch einige qualifizierte Personen, die nicht an der tatsächlichen Implementierung oder Entwicklung einer Anwendung oder eines Systems beteiligt sind.

Ich habe Tausende von Kunden mit Delegation eingerichtet, die meisten davon ohne Einschränkungen. Ich denke, es ist wichtig zu beachten, dass eine eingeschränkte Delegierung wahrscheinlich eine gute Idee ist, wenn Sie Ihrer Anwendung nicht vertrauen (z. B. auf IIS bereitgestellt) oder wenn Sie unsere Anmeldeinformationen für Ihr delegiertes Dienstkonto zur freien Verwendung an andere weitergeben. Wenn Sie jedoch nicht erwarten, dass jemand Ihre Anwendung neu schreiben kann, bewahren Sie die Anmeldeinformationen Ihres Dienstkontos sicher auf und vertrauen darauf, dass Ihre Apps nur an die Dienste delegiert werden, für die sie entwickelt wurden ist normalerweise kein Grund zur Sorge. Ich habe gesehen, dass sich einige "sicherheitsbewusste" Kunden sehr stark auf solche Themen konzentrieren, während ihre Ressourcen besser für echte Sicherheitsbedrohungen eingesetzt werden könnten ...