Active Directory для чайников часть 6 (Делегирование KERBEROS)

Делегирование в Kerberos — это механизм, который позволяет сервисам, работающим от имени пользователя, действовать от его имени при обращении к другим сервисам. Это используется в ситуациях, когда сервису нужно получить доступ к ресурсам от имени пользователя, например, в сложных инфраструктурах с промежуточными службами.

Основные виды делегирования:​
Ограниченное делегирование (Constrained Delegation, KCD):
Позволяет указать конкретные сервисы, к которым может обращаться делегированный сервис от имени пользователя.
Используется для ограничения круга сервисов, доступных через делегирование, что повышает безопасность.
Требует использования расширений протокола Kerberos в Active Directory.

Неограниченное делегирование (Unconstrained Delegation):
Предоставляет сервису возможность представлять пользователя для любых ресурсов в сети.
Менее безопасный вариант, так как сервис получает полные привилегии пользователя.

Делегирование с протоколом S4U2Proxy:
Используется для передачи прав аутентификации от одного сервиса к другому.
Включает поддержку ограниченного делегирования, чтобы избежать лишних привилегий.

Пример использования:​Представьте систему, где веб-сервер получает запрос от пользователя и должен обратиться к базе данных. Если база данных использует Kerberos для аутентификации, веб-сервер должен получить делегированные права пользователя, чтобы выполнить запрос.



Как работает делегирование:​
Пользователь аутентифицируется и получает тикет Kerberos для доступа к первому сервису (например, веб-серверу).
Первый сервис (веб-сервер) запрашивает делегированный тикет от имени пользователя, чтобы обратиться к другому сервису (например, базе данных).
Если делегирование разрешено, контроллер домена выдает тикет, который веб-сервер может использовать для доступа ко второму сервису.
Настройка в Active Directory:​Для делегирования требуется:




Настроить учетные записи сервисов в Active Directory.
Определить, какие сервисы могут использовать делегирование (особенно в случае ограниченного делегирования).
Проблемы безопасности:​
Неограниченное делегирование может быть использовано злоумышленниками для захвата привилегий пользователей.
Уязвимости типа "золотой билет" в Kerberos могут усилить риск делегирования.
Делегирование Kerberos полезно, но его использование требует тщательной настройки и мониторинга, чтобы избежать компрометации безопасности.





Простой пример чтобы было понятно почему существую виды делегирования.


Неограниченное делегирование: Веб-сервер может использовать учетные данные пользователя для доступа к любому ресурсу в сети, например, к базе данных или файловому серверу.
Ограниченное делегирование: Веб-сервер может использовать учетные данные пользователя только для доступа к базе данных, но не к другим ресурсам.
S4U2Proxy: Веб-приложение использует делегированные права пользователя для запроса данных из базы данных через промежуточный API-сервис.




S4U2Proxy (Service for User to Proxy) нужен для безопасного делегирования прав, когда исходный пользователь не передает свои учетные данные (например, TGT), а сервис получает тикет от имени пользователя через контроллер домена. Это решает ряд проблем, связанных с безопасностью и гибкостью.



Проблемы с другими видами делегирования:​
Неограниченное делегирование:
Риск компрометации: Если злоумышленник скомпрометирует сервисный аккаунт, он сможет действовать от имени любого пользователя для доступа к любым ресурсам в сети.
Чрезмерные привилегии: Сервис имеет больше прав, чем требуется, что противоречит принципу минимизации прав (least privilege).

Ограниченное делегирование:
Требует полного списка сервисов: Необходимо заранее указать все ресурсы, к которым разрешено обращаться. Это неудобно в динамических или сложных системах.
Не поддерживает кросс-доменные сценарии: Ограниченное делегирование работает только внутри одного домена Active Directory, что делает его непрактичным для междоменных операций.

Как решает проблемы S4U2Proxy:​
Безопасность: Учетные данные пользователя (TGT) никогда не передаются сервису, что снижает риск их компрометации.
Гибкость: Позволяет динамически запрашивать делегированные тикеты только для конкретных сервисов, определяя их по необходимости.
Кросс-доменная поддержка: S4U2Proxy позволяет делегировать права между доменами, если установлены доверительные отношения.
Пример:​Представьте, что веб-сервису нужно получить доступ к API и базе данных. С S4U2Proxy веб-сервис запрашивает контроллер домена о делегированном тикете только для этих ресурсов, не получая доступ к другим. Это делает делегирование более управляемым и безопасным.

Пример использования S4U2Proxy с сервисами для резервного копирования:​
Сценарий:
У вас есть корпоративная система резервного копирования (сервис A), которая сохраняет данные пользователей в облачное хранилище (сервис B).
Сервис A должен отправлять файлы пользователей в сервис B от их имени, чтобы соблюсти требования безопасности и аудита.

Участники:
Пользователь: Иван Иванов (учетная запись AD: ivan.ivanov).
Сервис A: Система бэкапов (корпоративное приложение).
Сервис B: Облачное хранилище (например, Azure Files или Amazon S3 с Kerberos-аутентификацией).

Процесс:
Иван Иванов аутентифицируется в Active Directory, чтобы инициировать резервное копирование своих данных.
Сервис A получает тикет Kerberos для работы от имени Ивана Иванова.
Вместо передачи учетных данных пользователя сервису B, сервис A запрашивает контроллер домена:
"Мне нужен делегированный тикет для доступа к облачному хранилищу от имени ivan.ivanov."

Контроллер домена проверяет:
Может ли сервис A использовать делегирование?
Имеет ли сервис A разрешение на доступ к сервису B?

Если все условия выполнены, контроллер домена выдает сервису A делегированный тикет только для облачного хранилища (сервис B).
Сервис A использует этот тикет, чтобы загрузить данные пользователя в облачное хранилище от имени Ивана.

Преимущества S4U2Proxy в этом случае:
Безопасность: Сервис A не получает прямого доступа к учетным данным Ивана, а только временный делегированный тикет.
Ограничение прав: Тикет действует только для облачного хранилища (сервис B) и не может быть использован для других ресурсов.
Динамическая настройка: Не нужно заранее прописывать, к каким именно хранилищам должен быть доступ (как в ограниченном делегировании).

Отличие от других видов делегирования:
Неограниченное делегирование: Сервис A получил бы полный доступ ко всем ресурсам, к которым имеет доступ Иван, включая другие серверы и приложения, что создает угрозу.
Ограниченное делегирование: Требуется вручную указывать доступ к сервису B для всех возможных сценариев, что неудобно и негибко.

Итог: S4U2Proxy идеально подходит для случаев, когда нужно безопасно передавать права пользователя сервисам, ограничивая доступ только нужными действиями и минимизируя риски.


Ограниченное делегирование: Полезно, когда нужно предоставить доступ сервису только к конкретным ресурсам внутри одного домена.
Неограниченное делегирование: Уместно в доверенной среде для сервисов, которым нужен полный доступ ко всем ресурсам от имени пользователя.
S4U2Proxy: Используется, когда нужно динамически и безопасно делегировать права пользователя для работы с конкретными сервисами, особенно в кросс-доменных сценариях.