Comments 5
Начало статьи, где исторический экскурс - понравилось. Дальше всё нуднее и нуднее. Чего в статье на мой личный взгляд, явно не хватает, так это место админов резервного копирования и самих систем резервного копирования. Также было бы интересно раскрыть роль RODC и технику защиты с помощью него именно в современном Мире, а не когда его придумали.
RODC сейчас используется интеграции с Entra и в общем случае их ставить не надо.
Спасибо за комментарий, внесу корректировки в стиль повествования!
Немного философствуя на тему места СРК и её администраторов в такой модели - по всем признакам оно именно в нулевом тире, но требует особого внимания из-за её роли для бизнеса (вряд ли первым лицам Компании станет хорошо, когда до них дойдёт информация об отсутствии резервных копий, или о том что они были зашифрованы очередной ransomwar'ью вместе со всей остальной инфраструктурой).
Стоит начать хотя бы с "лучших практик" самого вендора СРК (вот например для Veeam, их B&R до сих пор достаточно часто встречается в ру-сегменте), с последующим эшелонированием и наслоением мер (привет мониторинг событий ИБ, изолированные инсталляции СРК для реализации 3-2-1-1-0 и т.д.).
Касательно RODC: они и до сих пор применяются по прямому назначению, например в крупном энтерпрайзе с множеством филиалов - не только для оптимизации потоков аутентификации и сетевой нагрузки, но и для защиты доменных служб в трудно-контролируемых локациях (на ум приходят и другие сценарии, но они, вероятно, менее целесообразны, из-за наличия всех прочих защитных механизмов)
Я правильно понимаю, что в такой модели нужно каждые 1/4 часа вводить пароль и втыкать флешку? Как быть, если задача требует больше этого времени на выполнение и прерывать её нельзя ? Ограничение времени логина админов - шикарный способ отстрелить себе лицо в любой нештатной ситуации.
Благодарю за вопрос, на самом деле тут стоит уточнить для доступа к каким ресурсам может потребоваться запрос логина и пароля при истечении срока жизни билета Kerberos.
Если говорить про RDP-сессию - то не придётся заново вводить логин и пароль при истечении срока жизни билета, здесь всё решается параметрами таймаута и блокировки RDP-сеансов, если же говорить про сетевые ресурсы - например DFS или простые сетевые папки - может быть заново затребован логин и пароль.
На практике с какими-либо сложностями при такой конфигурации не сталкивался (применял её в собственной инфраструктуре)
Агрегируем практики по харденингу Active Directory Domain Services