Уже довольно давно читал замечательную модель нарушителя, одним из видов нарушителя в которой был "привилегированный пользователь, осуществляющий настройку сетевого взаимодействия...". Формулировку мог забыть - суть в том, что такой нарушитель как администратор домена в модели нарушителя учитывался (назовем его "темный админ"). И для нейтрализации угрозы с его стороны, согласно "Модели..." осуществлялся "комплекс мероприятий по подбору кадров", т.е. админ выбирался самый что ни есть лояльный и потому про все те негативные последствия, которые можно устроить из под админской учетки можно смело забыть...
Модели угроз - моделями угроз... а риски нужно как-то смягчать. Мероприятия направленные на повышение лояльности - это замечательно, про них не стоит забывать. Но также не стоит забывать, что доменный администратор это не человек, а пользователь системы, обладающий самыми обширными правами, и какие-то действия в системе, если "повезет" могут происходить из под этого пользователя без его ведома. Поэтому в этой статье попробуем перебрать варианты технической защиты от злого админа.
Вывод критически важных машин из домена
В любой инфраструктуре найдутся такие узлы, нарушение работы которых будет иметь наиболее значительные последствия для всей организации (например, компьютеры управляющие системами ДБО). Тем более, что настройку обновлений через WSUS вполне можно настроить и без домена. Впрочем, для того, чтобы все ПО (а не только от Microsoft) всегда были в актуальном состоянии, можно использовать патч-менеджеры (скажем, GFI LanGuard или модуль мониторинга уязвимостей Kaspersky Endpoint Security). Недостатки - администрирование ногами и утрата всех преимуществ домена, а также первый шаг к "зоопарку" машин. Плюсы - дешево и, как правило, легко реализуемо... и самая надежная защита от "темного админа".Усиленная аутентификация или разделение секрета
При двуфакторной аутентификации или разделение секрета (например, половину пароля знает админ Вася, а другую - админ Петя) для работы под доменным админом мы снижаем риск, что кто-то проникнет в сеть "обычным способом", т.е. введет логин и пароль. От "темного админа" это не спасет, от зловредов, которые будут совершать свои зловредные манипуляции во время сеанса работы доменного админа тоже... Зато затруднит жизнь админам и спасибо они за это не скажут.Учетка для сисадмина - "дайте две!"
Одна учетная запись пользовательская - для использования для интернет-серфинга, просмотра почты ну и всех прочих "неадминских" дел админа. Другая учетная запись - уже "истинно админская", но сконфигурированная таким образом, чтобы доступ был только к корпоративной сети. По возможности обрезать все потенциальные пути проникновения зловредов. Естественно, при большом желании доменный админ все это может перенастроить (но зачем оно ему надо, если он не "темный").
Средства аудита групповых политик
Продукты логирующие любые изменения групповых политик есть (сравнение с эталоном и указание кто и когда внес изменения), но нам нужно, чтобы администратор никак не мог повлиять на работу мониторинга. В теории модули доверенной загрузки, контролирующие целостность определенных ключей реестра, должны справляться с этой задачей - на практике не пробовал. Суть в том, чтобы на критичных машинах при изменение определенных групповых политик (читай, определенных ключей реестра) высвечивалось сообщение пользователю. А еще лучше приходил на почту алерт специалисту по безопасности. Тогда, можно будет уже идти к админам и интересоваться: "А чего это вы ребята включили RDP и удаленный редактор реестра на той самой машинке? И если не вы то кто?"
Комментариев нет:
Отправить комментарий