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