Отношения доверия в лесах и доменах

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

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

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

Доверие бывает следующих типов:

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

Вообще говоря, злоумышленник может использовать доверие для несанкционированного доступа в другом домене, поэтому необходимо устанавливать дополнительные ограничения на отношения доверия. Во-первых, необходимо использовать фильтрацию SID. Этот механизм включается автоматически и обеспечивает неприменение внешних идентификаторов безопасности при доступе к внутренним ресурсам леса. Если бы такой механизм отсутствовал, получилось бы, что администраторы доверяемого домена становились бы администраторами в доверяющем. Аналогичная ситуация произошла бы и с другими участниками безопасности. Поэтому в доверяющем домене идентификаторы безопасности из других доменов не должны произвольно использоваться. Механизм фильтрации SID можно отключить, но делать это крайне не рекомендуется.

Также с точки зрения безопасности важно понимать, что вновь созданное отношение доверия уязвимо из-за потенциально широкого доступа к объектам группы Все. Любой пользователь из доверяемого домена будет иметь полномочия этой группы в доверяющем домене, даже если ему явно не назначено разрешение на доступ к объектам. Поэтому доступ к важным ресурсам этой группы следует ограничить еще до создания доверительных отношений. То же самое касается группы Сеть. Также доверие следует ограничить следующим образом:

Для функционирования доверия также необходимо соблюдение ряда физических условий. Во-первых, домены должны быть физически соединены кабелем, во-вторых, необходима адекватная настройка системы DNS, ведь имена должны разрешаться по обе стороны доверия. Если пространство имен DNS разделено между разными серверами, то они должны быть доступны по обе стороны доверия. В-третьих, если внутренние границы сети соединены между собой брандмауэрами, то на последних необходимо открыть следующие порты: RPC локального администратора безопасности (по умолчанию он динамический, но для уменьшения числа открытых портов его номер необходимо задать в следующем разделе реестра HKLM\system\currentcontrolset\servicies\ntds\parameters – параметр TCP/IP Port ); RPC NETLOGON ( он задается в реестре по адресу HKLM\system\currentcontrolset\servicies\netlogon\parameters ), а также порты с номерами 88 для аутентификации Kerberos, 135 – для контроля над Action Control Listами объектов.

Внедряя доверие, необходимо руководствоваться следующими рекомендациями:

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

Лабораторная работа 10. Создание доверия между доменами

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