Pull to refresh
0

Безопасное управление Active Directory. Часть 3 (заключительная)

Reading time 4 min
Views 12K
Сегодня мы завершаем небольшую серию заметок, касающихся безопасного управления Active Directory. Этот материал — перевод текста от Brian Svidergol, автора книги «Active Directory CookBook».

Как всегда – фокус на идеях, которые помогут вашей инфраструктуре стать более защищенной. С предыдущими двумя частями можно ознакомиться по ссылкам ниже:
Часть 1
Часть 2

В этой части мы говорим о мониторинге событий, связанных с AD.


Почему необходимо отслеживать и успешные и неудачные операции?

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

Например, вы хотите узнать, кто изменил настройки контроллера домена. Изменение прошло успешно. Для того, чтобы провести изменение, необходимо было успешно авторизоваться в домене. А затем успешно использовать средства удаленного администрирования (RDP или MMC). Вся эта история прямо пронизана успешными действиями, если вы не отслеживаете их – сложно понять, кто изменил что и когда.
Другой пример: вы видите большое количество событий, связанных с неудачной попыткой служебной учетной записи авторизоваться в домене. Замечательно, что вы можете отследить неудачные попытки. Плохо, что вы не понимаете, отчего прекратились попытки: то ли атакующий всё-таки сумел авторизоваться, то ли ему надоело пробовать. В обоих случаях лучше отслеживать и успешные и неудачные операции.

Как проводить мониторинг AD?

Предлагаю сфокусироваться на группе Domain Admins (хотя эти рекомендации применимы ко всем важным security-группам): следует проводить мониторинг всех изменений членства в группе, отслеживать и добавления, и удаления. Иначе вы возможно не узнаете, что атакующий временно добавил себя в Domain Admins, а сделав свои дела – удалился.

Теперь поговорим о групповых политиках. Неправильная стратегия аудита GP может привести к печальным последствиям. Например, атакующий желает провести фишинговую атаку на рабочих станциях вашей организации, но текущие настройки IE мешают или снижают эффективность такой атаки. Хорошим вариантом для атакующего может стать изменение объекта групповой политики, GPO.
Другой пример: атакующему необходимо установить вредоносную программу на все машины, включенные в домен. В этом случае он также может эффективно использовать групповые политики, создать новый объект.

Таким образом, постоянный мониторинг GP играет важную роль в защите инфраструктуры. Вам необходимо отслеживать создание и изменение объектов (GPO), а также привязок объектов (GPO links). Вам также необходимо знать, кто инициировал изменения. Мониторинг AD можно настроить относительно быстро, если вы используете выделенные подсети для административных задач (вспоминаем часть 2). Вместо того, чтобы устанавливать многочисленные фильтры на отдельные серверы, IP-адреса или контейнеры/группы, вы можете проводить мониторинг целой подсети.

Как уменьшить количество оповещений?

Каждый, кто хоть раз устанавливал System Center Operations Manager (SCOM) – знает, о чем я говорю. Сегодня решения для мониторинга стали сложнее и поддерживают огромное количество систем. SystemCenter расширяется с помощью специальных пакетов, которые существуют буквально для любого серверного ПО или оборудования. В тот момент, когда все эти пакеты устанавливаются и подключаются, — администраторы оказываются заваленными многочисленными оповещениями о «проблемах» в инфраструктуре. В результате, админы перестают реагировать на эти оповещения если всё в порядке. И начинают судорожно просматривать их только в случае инцидентов, когда одна или несколько систем уже фактически перестали работать.

Моя стратегия достаточно проста: я смотрю на консоль системы мониторинга каждый раз, когда возникает проблема. Я пытаюсь понять, дала ли система мониторинга нам достаточно информации для предотвращения инцидента? Были ли отправлены оповещения правильным сотрудникам? Часто администраторы получают оповещения «по группе», т.е. не только о системах, которые они обслуживают, а также и за коллег. Даже если админы увидят оповещение, они не будут реагировать, поскольку «всё равно эту проблему будет решать другой отдел».

Подводя итоги, предлагаю три простых вопроса, которые помогут уменьшить количество оповещений:

  1. Была ли реакция (действие) со стороны администраторов на оповещение? Если нет – почему? Возможно ли сразу гасить такие оповещения? Не повлияет ли это на работающие системы?
    Если да – сразу настраивайте такие оповещения, чтобы они не приходили админам.
  2. Получаете ли вы оповещения, о системах, за которые отвечают другие сотрудники? Если да – получают ли другие сотрудники эти же оповещения? Если ответ снова «да» — удалите себя из списка рассылки. Если другие сотрудники не подписаны на эти оповещения – добавьте их и удалите себя. Получать оповещения должен только ответственный за неё.
  3. Получаете ли вы оповещения в виде CMC об инцидентах, не являющихся критичными? (на диске осталось 20% свободного места) Если да – удалите свой номер из рассылки. СМС-оповещения должны приходить только в случае возникновения серьезных инцидентов в продуктивной среде, иначе вы перестанете адекватно на них реагировать.


Оригинальный текст этой заметки на англ.языке.
Tags:
Hubs:
+3
Comments 0
Comments Leave a comment

Articles

Information

Website
www.netwrix.ru
Registered
Founded
2006
Employees
101–200 employees
Location
США