Риски делегации Kerberos

Я проводил часы за часами, пытаясь изучить и понять аутентификацию Windows, Kerberos, SPN и ограниченное делегирование в IIS 7.5. Одна вещь, которую я просто не понимаю, это то, почему «рискованно» оставлять делегирование включенным (то есть не отключать делегирование для чувствительных учетных записей) для администраторов, генеральных директоров и т. Д. Может кто-нибудь, пожалуйста, объясните мне это простыми словами? Пожалуйста, сформулируйте свой ответ относительно среды интранета.

Я полагаю, что это не должно вызывать беспокойства, поскольку делегирование просто позволяет интерфейсному веб-серверу, например, действовать от имени лица, прошедшего проверку подлинности Windows, при взаимодействии с другими серверами. Если у человека есть доступ, у него есть доступ, я не понимаю, почему это должно вызывать беспокойство.

Пожалуйста, прости мое невежество. Я в первую очередь разработчик, но моя компания в настоящее время работает очень скудно, и я вынужден тоже надеть шляпу администратора сервера ... к сожалению, она все еще не очень хорошо подходит, смеется.

Два примера:

1. Ограниченное делегирование позволяет выполнять олицетворение, не имея учетных данных пользователя или токена аутентификации. Для примера посмотрите этот ответ .

2. В более типичном сценарии неограниченного делегирования «мясо-и-картофель», будь то встроенная проверка подлинности Windows или проверка подлинности на основе форм, наличие доступа делегирования к токену проверки подлинности пользователя очень эффективен. Это буквально означает, что токен может использоваться для олицетворения этого пользователя для доступа к любому сетевому ресурсу. Любой, кто участвует в этом процессе, например, разработчик, может использовать это ненадлежащим образом для получения несанкционированного доступа.

В обоих примерах, если флажок «учетная запись чувствительна и не может быть делегирована», это не проблемы безопасности. Также возможно спроектировать систему / функцию, где эти возможности существуют, но находятся под жестким контролем.

Этот флажок следует установить для учетных записей администратора, таких как члены группы «Администраторы предприятия», поскольку (надеюсь), что для этих учетных записей редко требуется использовать приложения, требующие олицетворения. Это также хорошая идея для руководителей высшего звена, имеющих доступ к конфиденциальной информации, таких как ИТ-директор, главный операционный директор, глава финансов / казначейства и т. Д.

Таким образом, суть заключается в том, что Microsoft предоставила этот флажок и сопровождающее предупреждение по очень веской причине, и его не следует сбрасывать со счетов или воспринимать легкомысленно, если только не будет продемонстрировано, что в конкретном сценарии отсутствует нежелательный риск или какой-либо компенсирующий контроль. Обычно это включает проверку некоторыми квалифицированными специалистами, которые не участвуют в фактической реализации или разработке приложения или системы.

Я установил тысячи клиентов с делегированием большей части неограниченных. Я думаю, что важно отметить, что если вы не доверяете своему приложению (скажем, развернуто в IIS) или вы предоставляете свои учетные данные делегированной учетной записи службы для свободного использования другими пользователями, тогда ограниченное делегирование, вероятно, является хорошей идеей. Однако, если вы не ожидаете, что кто-либо сможет переписать ваше приложение, вы сохраните свои учетные данные учетной записи службы в безопасности и будете уверены, что ваши приложения будут делегировать только те службы, для которых они предназначены, тогда обычно не о чем беспокоиться. Я видел, как некоторые «заботящиеся о безопасности» клиенты очень сильно сосредоточены на таких проблемах, в то время как их ресурсы можно было бы лучше потратить на работу с реальными угрозами безопасности ...