Не оставляйте двери AD открытыми

Active Directory (AD) — дверь в хранилище информационных ресурсов многих предприятий, и она должна быть надежно заперта. Обеспечить безопасность AD — сложная задача, но, приняв ряд элементарных мер предосторожности (подчеркиваю — элементарных!), можно достаточно надежно защитить инфраструктуру AD. Безопасность неизбежно требует компромисса. Всегда есть способы повысить уровень защиты, но для этого придется пойти на некоторые затраты либо поступиться гибкостью или функциональностью. В данной статье я расскажу о пяти приемах, которые не связаны с серьезными затратами, но могут значительно повысить безопасность общей инфраструктуры AD.

Шаг 1. Оптимальные методы администрирования

Всегда можно повысить безопасность AD, автоматизировав процессы, выполняемые вручную, например построение контроллеров домена (DC). Однако пока не существует языка программирования для автоматизации поведения человека. Поэтому необходимо составить руководство по обслуживанию AD для администраторов. От них следует потребовать строгого соблюдения некоторых правил.

Применять отдельные административные учетные записи. Использование отдельных административных учетных записей — обязательное требование во многих организациях, но тем не менее об этом стоит напомнить. Вирус, заразивший компьютер администратора, представляет собой куда более серьезную потенциальную опасность, так как административные разрешения позволяют запускать программы и сценарии. Поэтому администраторам следует использовать непривилегированные учетные записи (например, user) для повседневной работы и отдельную административную учетную запись - для задач по обслуживанию AD, требующих расширенных разрешений. С помощью таких инструментов, как команда Runas, пользователь, зарегистрировавшийся с неадминистративной учетной записью, может запускать программы как администратор. Более подробную информацию о команде Runas можно найти в файле оперативной подсказки Windows.

Обеспечивать защиту рабочих станций администратора. Несмотря на все преимущества регистрации администраторов с неадминистративными учетными записями и запуска программ управления AD с помощью таких инструментов, как Runas, опасность по-прежнему велика, если компьютеры, на которых работают эти инструменты, защищены недостаточно надежно. Если взломщик незаметно для администратора получит власть над его компьютером, то использование альтернативных учетных данных не поможет — злоумышленник легко воспользуется системой. Если не удается надежно защитить компьютеры администраторов, необходимо организовать отдельную безопасную рабочую станцию, к которой администраторы обращаются через службы терминалов. Для большей безопасности рабочую станцию можно поместить в специальную организационную единицу (OU) и применить строгие параметры в Group Policy. Не следует забывать и о физической безопасности. Если компьютер администратора украден, то всю информацию с этой системы следует считать раскрытой.

Периодически выполнять проверку членства в административной группе. Один из способов несанкционированного получения расширенных разрешений — ввод своей учетной записи в административную группу AD, например Domain Admins, Administrators или Enterprise Admins. По этой причине следует уделить особое внимание членам административных групп AD. К сожалению, в AD нет встроенного механизма для предупреждения об изменении членства в определенных группах, но можно подготовить сценарий, который выдает список членов группы, и запускать его по крайней мере один раз в день. Имеет смысл также активизировать аудит этих групп; в результате записи о любых изменениях будут заноситься в журналы событий.

Ограничить круг лиц, которым известен пароль учетной записи Administrator. Овладев паролем учетной записи Administrator, взломщик получает расширенные разрешения в лесу, и проследить за его действиями трудно. Поэтому в большинстве случаев не стоит использовать учетную запись Administrator для управления AD. Вместо этого следует создать альтернативные административные учетные записи, ввести их в группу Domain Admins или Enterprise Admins, а затем выполнять почти все административные функции от имени этих записей. Учетную запись Administrator необходимо задействовать лишь в крайних случаях. Поскольку использование этой учетной записи сводится к минимуму, должен быть ограничен и круг лиц, которым известен пароль. А поскольку любой администратор может изменить пароль учетной записи Administrator, полезно отслеживать все попытки регистрации с этой учетной записью.

Быстрое изменение пароля учетной записи Administrator. Даже если доступ к учетной записи Administrator разрешен лишь нескольким лицам, необходимо предусмотреть процедуру быстрого изменения ее пароля. Полезно менять пароль каждый месяц, но, если администратор, который знает пароль (или имеет право изменить его), уходит из организации, пароль нужно изменить немедленно. Эта рекомендация относится и к паролю в режиме восстановления Directory Services Restore Mode (DSRM), назначаемому при первоначальном выборе DC и любых служебных учетных записей с административными разрешениями. Пароль DSRM используется для административной учетной записи, с которой администратор регистрируется после загрузки в режиме Restore Mode. Утилита Ntdsutil операционной системы Windows Server 2003 — простой инструмент командной строки, с помощью которого можно изменить данный пароль.

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

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

Шаг 2. Надежная защита DC

Применив оптимальные административные процедуры, следует перенести внимание на DC, поскольку контроллеры домена — самое уязвимое место во многих AD. Если хакер взломает или нарушит работу DC, то весь лес окажется в опасности. Поэтому необходимо выполнять следующие рекомендации.

Физическая безопасность DC. Физическая безопасность контроллеров домена — одна из самых актуальных проблем AD. Злоумышленник, получивший физический доступ к DC, может обойти практически все защитные барьеры. Как правило, физической безопасности ничто не угрожает, если DC располагаются в центрах обработки данных; чаще проблема возникает в офисах филиалов. В таких офисах DC часто находятся в запертых помещениях, к которым имеет доступ только ИТ-персонал. В некоторых ситуациях подобное решение неизбежно. Но в любом случае люди, имеющие физический доступ к DC, должны пользоваться безусловным доверием.

Автоматизация процедуры назначения DC. В общем случае гораздо безопаснее автоматизировать задачу, чем решать ее вручную.

Это особенно справедливо, когда требуется построить и назначить DC. Чем больше степень автоматизации процесса построения и настройки, тем менее уязвимыми будут DC. При ручной установке серверов между различными серверами, как правило, возникают небольшие различия. Даже если процесс полностью документирован, в конфигурации серверов неизбежно появляются различия. Автоматизируя процессы построения и настройки, можно с достаточной степенью уверенности считать, что все DC идентично настроены и защищены. Обеспечить одинаковую конфигурацию ранее построенных DC можно с помощью такого инструмента, как Group Policy.

Незамедлительная установка важных программных исправлений. Во времена Windows NT большинство администраторов применяли лишь самые необходимые исправления для системы безопасности. Нередко исправления содержали ошибки и становились причиной дополнительных проблем. В настоящее время такие вольности недопустимы. К счастью, качество программных исправлений, выпускаемых Microsoft, стало гораздо выше. Контроллеры домена — очевидные мишени, поэтому администраторам необходимо уделить особое внимание новым исправлениям. Можно подписаться на рассылаемые по электронной почте извещения о новых исправлениях для системы безопасности по адресу http://www.microsoft.com/ security/bulletins/alerts.mspx. Развернуть исправления для системы безопасности можно незамедлительно с помощью Automatic Updates или протестировать и установить их выборочно с использованием службы Microsoft Software Update Services (SUS).

Резервный файл. В операционных системах, предшествующих Windows 2003, не существует способа ограничить число объектов, создаваемых в контейнере пользователем с соответствующими разрешениями. Из-за отсутствия ограничений взломщик может, непрерывно создавая объекты, заполнить жесткий диск DC. Опасность можно несколько снизить, создав на каждом DC резервный файл размером от 10 до 20 Мбайт. Если на диске DC не хватает места, можно удалить резервный файл и получить небольшую передышку до тех пор, пока не будет найден выход из положения. Создать резервный файл совсем нетрудно. Это может быть документ Microsoft Word или текстовый файл, содержащий произвольный текст.

Программы поиска вирусов. Запускать программы поиска вирусов на DC еще важнее, чем на большинстве серверов, потому что контроллеры домена обеспечивают репликацию не только информации о каталогах, но и содержимого файлов через службу File Replication Service (FRS).

К сожалению, FRS — удобный способ для распространения вирусов на большом числе серверов. А поскольку FRS обычно реплицирует сценарии регистрации, то потенциальная опасность распространяется вплоть до уровня клиентов. Использование антивирусных программ значительно снижает риск репликации вирусов на серверах и клиентах.

Шаг 3. Оптимальные методы делегирования

Служба AD может стать уязвимой из-за ошибки в списках управления доступом (ACL), защищающих контент AD. Кроме того, чем сложнее механизм делегирования, тем сложнее обслуживать AD и вести диагностику неполадок. Поэтому я отдаю предпочтение простым подходам (Keep It Simple, Stupid , KISS). Чем проще процедура делегирования, тем лучше для администратора, особенно когда речь идет о безопасности. Данный метод применим и к проектированию AD вообще, как объясняется во врезке «Проектное решение — фундамент безопасности». Чтобы узнать, как упростить процедуру делегирования, я рекомендую прочитать статью Microsoft «Best Practices for Delegating Active Directory Administration» (http://tinyurl.com/vzlg).

Наряду с упрощением делегирования желательно придерживаться следующих оптимальных подходов.

Не стоит назначать разрешения учетным записям пользователей. Одно из главных правил делегирования — всегда назначать разрешения группам, а не пользователям; исключения возможны лишь при наличии очень серьезных оснований. Что происходит, когда сотрудник, которому были назначены разрешения, покидает компанию, переходит на другую должность или по каким-либо причинам должен быть лишен доступа? Гораздо труднее отследить все разрешения, закрепленные за учетной записью, отменить их и предоставить разрешения другому пользователю, чем просто удалить старую учетную запись из группы и ввести новую учетную запись. Даже если есть основания полагать, что разрешение другому лицу никогда не понадобится, нужно создать группу, поместить в нее пользователя, а затем назначить разрешения группе.

Не следует налагать разрешения на отдельные объекты. Наложение разрешений непосредственно на отдельные объекты (например, на объекты user или group) приводит к лишним сложностям. Для обслуживания таких разрешений требуется больше усилий, а впоследствии о них легко забыть. Во избежание проблем разрешения следует накладывать в основном на организационные единицы (OU) или контейнеры.

Документирование модели. Одна из самых важных задач при делегировании разрешений — документировать модель. Была ли создана ролевая модель? Как организованы процедуры предоставления доступа? Существуют ли исключения из общей модели? Все эти вопросы необходимо документировать не только для упрощения обслуживания. Каждый пользователь должен понимать порядок делегирования разрешений и уметь определить, когда разрешения имеют иную структуру (что может повысить уязвимость AD). Форма представления документации не важна. Документ лишь должен быть легко доступен для администраторов, которым он необходим.

Использование Dsrevoke. Мастер Delegation of Control, который можно запустить из таких инструментов, как оснастка Active Directory Users and Computers консоли Microsoft Management Console (MMC), очень удобен для первоначального делегирования доступа. Однако использование этого мастера или другого графического инструментария для отмены делегирования задач (например, удаления из списков ACL всех элементов, соответствующих определенной учетной записи) — задача по меньшей мере утомительная. Есть другой способ. Специалисты Microsoft разработали инструмент Dsrevoke, который просматривает все списки ACL в домене и отменяет ссылки на указанные учетные записи. Бесплатный инструмент можно загрузить по адресу http://www.microsoft.com/downloads/ details.aspx?familyid=77744807-c403-4bda-b0e4 -c2093b8d6383&displaylang=en.

Шаг 4. Мониторинг и аудит организации AD

Из-за большого числа компонентов AD трудно определить, что кто-то пытается обойти меры безопасности. Администратор может следовать описанным выше рекомендациям, но как узнать о попытках противостоять им? Сделать это можно с помощью мониторинга и аудита.

По крайней мере, следует отслеживать общую доступность контроллеров домена. Как правило, всегда выполняется мониторинг готовности хост-компьютера, чтобы гарантировать общую готовность инфраструктуры AD. Но в целях безопасности важно обнаружить неожиданный отказ DC, чтобы быстро установить причину неполадок. Возможно, DC в удаленном филиале был украден или взломщик получил физический доступ и остановил компьютер, чтобы установить «троянского коня».

Помимо отслеживания общей доступности контроллеров домена, можно использовать Performance Monitor для мониторинга многих характеристик AD, от числа запросов LDAP в секунду до объема реплицируемых данных. Для каждого показателя можно установить базовый уровень и затем отслеживать его. Например, резкое повышение числа запросов LDAP или запросов аутентификации в какой-то период времени может свидетельствовать о нападении. Для расширенного мониторинга (и даже рассылки предупреждений) можно использовать такой инструмент, как Microsoft Operations Manager (MOM).

Функции аудита, реализованные в операционных системах Windows и AD, позволяют заносить сведения об определенных событиях в журнал Security. В журналах можно отмечать самую разнообразную информацию, от различных изменений в конфигурации операционной системы до модификации AD. Однако использовать аудит следует с осторожностью. В результате частых проверок в журналах безопасности скапливается слишком много данных, среди которых трудно отыскать важные события. Рекомендации по выбору характеристик для аудита можно найти в статье Microsoft «Best Practice Guide for Securing Active Directory Installations» (http://tinyurl.com/3c928).

Шаг 5. Готовьтесь к худшему

Вероятно, самый важный аспект планирования безопасности — подготовка мер для устранения последствий успешных атак. Рекомендации данной статьи не гарантируют безопасности; они затрудняют задачу потенциальных взломщиков. Инфраструктура AD предприятия может быть закрытой, но вряд ли удастся воспрепятствовать нападению, если взломщик применит ранее неизвестный метод атаки против AD. Поэтому важно подготовиться к худшему, заранее составив план действий в критической ситуации. Если лес поражен целиком и нужно выполнять восстановление с «голого железа», то администратор сможет сэкономить драгоценное время, если хотя бы заранее обдумает свои действия.

Следует периодически восстанавливать лес в лабораторных условиях, чтобы убедиться в пригодности резервной копии. Процесс восстановления необходимо документировать. Хорошие поэтапные рекомендации по восстановлению изложены в статье Microsoft «Best Practices: Active Directory Forest Recovery» (http://tinyurl.com/3rk7b).

Сделайте первый шаг

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

Проектное решение — фундамент безопасности

Вирусы, «черви», спам и атаки вида отказа в обслуживании (DoS) — примеры типичных опасностей, с которыми приходится ежедневно сталкиваться пользователям Internet. Причина уязвимости Internet заключается в том, что при проектировании сети не учитывались проблемы безопасности. По замыслу авторов это должна была быть открытая система, способствующая свободному общению и обмену идеями между людьми. Создатели Internet не могли представить себе огромный коммерческий успех, который ожидал их детище. В результате сообщество пользователей Internet по сей день вынуждено заниматься латанием прорех в глобальной сети.

Этот пример показывает, как практическая реализация технологии определяет меры ее защиты (если защита вообще возможна), и Active Directory (AD) — не исключение. Если администратор выбирает открытую модель делегирования, в которой пользователям предоставляется больше доступа, чем им в действительности необходимо, или развертывает контроллеры домена (DC) на незащищенных компьютерах, то задача защиты всей системы значительно усложняется.

Я убежденный сторонник максимально простых решений при проектировании. Чем проще структура AD, тем лучше, особенно если речь идет об информационной безопасности. В сложных системах обычно больше объектов управления и, следовательно, объектов, которые требуется защитить. И наоборот, чем меньше доменов, тем меньше контроллеров домена. Чем меньше контроллеров домена, тем меньше требуется администраторов. При уменьшении числа организационных единиц (OU) снижается число мест, в которые нужно делегировать разрешения. Так что выгоды очевидны.

Технический руководитель в компании Cisco Systems. MVP по Windows Server Directory Services. rallen@rallenhome.com