Безопасное администрирование службы каталогов Active Directory Domain Services (AD DS).

Безопасное администрирование службы каталогов Active Directory Domain Services (AD DS).

Одним из самых важных компонентов проектирования безопасности AD DS является выбор методик безопасного администрирования. Поскольку администраторы располагают полным доступом в среде AD DS, они могут обойти или модифицировать любые системы безопасности. При создании методик администрирования нужно принять во внимание следующие соображения:

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

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

3) Группу Schema Admins (Администраторы схемы) следует ограничить лишь временными членами. Большинство организаций очень редко изменяют схему, поэтому нет никакой необходимости регулярно входить в систему в качестве администратора схемы. Для обеспечения безопасности процесса изменения схемы группа Schema Admins должна быть пустой. Доверенного пользователя нужно добавлять в группу только в том случае, когда в схеме необходимо выполнить административную задачу. После выполнения задачи удалите этого пользователя из группы.

4) Используйте политику Restricted Group (Группы с ограниченным доступом) для ограничения группового членства критически важных учетных записей домена и леса. При реализации политики Restricted Group контроллеры доменов наблюдают за членством в группах, причем все пользователи, не включенные в политику ограничения групп, автоматически удаляются.

5) Убедитесь, что администраторы используют две различные учетные записи. Для пользователей, которые будут выполнять административные роли, создайте две учетные записи: стандартную учетную запись для ежедневной работы и административную учетную запись для выполнения административных задач. Административную учетную запись не следует использовать для электронной почты и запуска ежедневных приложений, например Microsoft Office, а также для просмотра Интернета.

6) Ко всем административным учетным записям применяйте принцип минимальных привилегий. Аккуратно определите разрешения, необходимые для каждой административной группы, и назначайте только эти права доступа. Например, если администратору требуется управлять специфическими учетными записями пользователей или компьютеров либо управлять лишь некоторыми параметрами этих учетных записей, создайте подразделение (OU) в качестве контейнера этих учетных записей, а затем делегируйте права доступа административной учетной записи. Кроме того, не назначайте группе Account Operators (Операторы учета) разрешения модификации учетных записей пользователей и групп. Разрешения по умолчанию позволяют этой группе модифицировать компьютерные учетные записи контроллеров доменов, включая их удаление. По умолчанию группа Account Operators не содержит членов и должна оставаться пустой.

7) Скрывайте учетную запись администратора домена. При установке AD DS в каждом домене содержится учетная запись Administrator. Эта административная учетная запись по умолчанию создается во время установки домена. С ее помощью можно получать доступ и администрировать службу каталогов. Эту учетную запись нельзя отключить или блокировать. Вам следует переименовать эту учетную запись, чтобы она не отображалась как Administrator. При переименовании учетной записи измените также текст в поле описания учетной записи. Кроме того, следует создать фиктивную учетную запись с именем Administrator без особых прав доступа и отслеживать коды ошибок 528, 529 и 534 в подключениях с переименованной и фиктивной учетными записями.

8) Никогда не используйте совместно административные учетные записи. В некоторых организациях все старшие администраторы знают пароль учетной записи Administrator по умолчанию и все используют эту учетную запись для выполнения административных задач. Совместное использование административных учетных данных не позволяет определить, кто вносил изменения в каталог, так что использовать такую методику не рекомендуется. При совместном использовании административных учетных записей и паролей также может возникнуть проблема безопасности, когда администраторы покидают команду или компанию.

9) Обеспечьте безопасность административного входа в систему. Чтобы свести к минимуму вероятность злонамеренного использования или взлома административной учетной записи, выполните следующие действия для включения строгих учетных данных администраторов:

1)Требуйте смарт-карты для административного входа. Администраторы служб должны использовать смарт-карты для интерактивного входа в систему. Помимо физического хранения административным пользователям смарт-карты также позволяют использовать случайно генерируемые строгие пароли для получения административного доступа. Требование смарт-карт можно включить с помощью политики Interac-tive logon: Require smart card (Интерактивный вход: требовать смарт-карту), применяемой к каждой административной учетной записи.

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

3) Ограничьте рабочие станции, на которые могут входить администраторы служб. Каждой административной учетной записи можно разрешить входить лишь на определенные рабочие станции. В случае взлома одной из административных учетных записей ограничение доступных рабочих станций позволит ограничить места, где можно использовать эту учетную запись.
* Применяйте к рабочим станциям специальную политику безопасности. Например, переместите все рабочие станции администраторов служб в отдельное подразделение (OU), а затем примените для рабочих станций строгую политику безопасности. Вы можете разрешить локальный вход только учетным записям администраторов служб.

4) Убедитесь, что на всех административных рабочих станциях установлены все обновления безопасности и антивирусного программного обеспечения.

5) Советуйте администраторам выполнять административные задачи с помощью Remote Desktop (Удаленный рабочий стол). Функцию удаленного рабочего стола можно включить на любом сервере Windows Server 2008 R2 и настроить параметры безопасности, чтобы с помощью Remote Desktop к серверу могли подключаться лишь указанные администраторы. Если на клиентских компьютерах Windows ХР установить клиента Remote Desktop 6 или использовать клиента Windows Vista, можно будет включить шифрование сети для всех подключений Remote Desktop.

6) Обеспечьте безопасность носителей резервных копий. При архивации контроллеров доменов в организации на резервный носитель копируется все хранилище каталогов. Хотя эти данные зашифрованы, злоумышленник, получивший в свое распоряжение такой носитель, располагает неограниченным временем для расшифровки и получения доступа к данным. Вы можете предотвратить физический доступ неавторизованных пользователей к носителям резервных копий, выполнив следующие действия:

-храните носитель резервной копии в защищенном месте, где обеспечена проверка доступа;

- храните носитель с архивом в безопасном месте вне сайта;

- установите требования безопасности к транспортировке носителей резервных копий.

7) Установите квоты владения объектами. Например, на контроллерах домена Windows Server 2008 R2 можно использовать квоты, ограничивающие число объектов, которыми может владеть принципал безопасности (пользователь, группа, компьютер или служба) в разделе каталога домена, конфигурации и приложений. По умолчанию владельцем объекта является принципал безопасности, который создал этот объект, хотя права владения можно передавать. Квоты AD DS исключают возможность создания неограниченного количества объектов в разделе каталогов, что может использоваться для осуществления атак Denial-Of-Service (Отказ обслуживания). По умолчанию квоты не установлены, и любой принципал безопасности может создавать неограниченное количество объектов. Для установки квот используется команда Dsmod Quota.