Планирование доверительных отношений в среде Windows Server 2003
Когда я много лет назад работал в армии, текущей серверной операционной системой была Windows NT 4.0. Я помню, что с доверительными отношениями было особенно трудно иметь дело, потому что у каждого подразделения был свой домен Windows NT со своим собственным администратором. Что делало эту ситуацию настолько сложной, так это то, что армейские правила требовали, чтобы Департамент управления информацией (мой офис) имел доверительные отношения со всеми другими доменами, которые существовали на базе.
Чтобы установить эти доверительные отношения, нам пришлось вручную указать нашему домену установить доверительные отношения с удаленным доменом. Затем администратору удаленного домена пришлось вручную устанавливать с нами доверительные отношения. Конечно, были пароли, которые нужно было вводить каждый раз при установлении доверия, и обмен этими паролями стал серьезной политической проблемой.
Создание доверительных отношений способом, который я только что описал, просто означало, что каждый домен в базе доверял пользователям из моего офиса, а мой офис доверял пользователям из любого другого домена. Эти доверительные отношения не создавали доверительные отношения между какими-либо удаленными доменами. Если между удаленными доменами требовались доверительные отношения, администраторы этих доменов должны были предоставить соответствующие документы для использования, затем нам приходилось анализировать последствия создания такого доверия для безопасности, а затем вручную устанавливать доверие.
Доверительные отношения были для нас большой проблемой. Поскольку в базе было очень много доменов, нам приходилось поддерживать бесчисленное количество индивидуальных доверительных отношений. Также было много ситуаций, когда нам приходилось уничтожать и создавать заново трасты, потому что они внезапно переставали работать без видимой причины.
Теперь, когда я рассказал вам одну из своих «военных историй» из армейских дней, давайте перенесемся в настоящее. Windows Server 2003 устраняет описанные выше проблемы (как и Windows 2000 Server). В Windows Server 2003 домен не является независимым объектом, как это было в Windows NT Server. Вместо этого домен считается объектом в Active Directory. Все объекты в Active Directory (включая домены) считаются частью леса.
Интересным фактом существования доменов как части более крупной структуры (леса) является то, что лесу известны все домены, входящие в его состав. Кроме того, никто не может просто создать новый домен и сделать его частью существующего леса, если у него нет соответствующих прав администратора.
Поскольку лес знает обо всех доменах в нем и поскольку каждый домен авторизован администратором уровня леса (членом группы администраторов предприятия), предполагается, что все домены в лесу заслуживают доверия. Поэтому Windows создает автоматические доверительные отношения между каждым доменом в лесу и каждым другим доменом в лесу.
Поскольку каждый домен автоматически доверяет каждому другому домену, вы можете предположить, что у кого-либо нет причин снова сталкиваться с ситуацией, подобной моему кошмару с армией, если все домены основаны на Active Directory. В некотором смысле это правда. Если бы я сегодня работал на армию, вполне возможно, что я смог бы создать лес, охватывающий всю базу. Каждая единица по-прежнему может поддерживать свой собственный домен, но домен будет частью леса, и доверительные отношения на уровне леса будут создаваться автоматически. На самом деле, я знаю несколько крупных компаний, у которых сети настроены именно таким образом.
Хотя доверие на уровне леса значительно упрощает администрирование, оно не всегда уместно. Например, рассмотрим мой более ранний пример с армией. Лес, охватывающий всю базу, в такой ситуации был бы неуместен из-за того, что многие подразделения имеют дело с секретной информацией.
Просто чтобы быть совершенно ясным, я хочу указать, что наличие доверия одного домена к другому домену не дает автоматически пользователям в доверенном домене доступ к каким-либо ресурсам в доверяющем домене. Администратор этого домена должен предоставлять разрешения. Даже в этом случае лес, охватывающий всю армейскую базу, не подходит для вооруженных сил, потому что армия не захочет рисковать тем, что администратор преднамеренно или злонамеренно предоставит разрешения на доступ к секретным материалам кому-то из другого домена.
Итак, в армии много придирчивых правил и бюрократии, так что насчет корпорации? Что ж, в корпоративном мире даже бывают ситуации, когда лес в масштабах всей компании — плохая идея. Представьте на минуту, что вы работаете в крупной компании с офисами в разных городах. Теперь представьте, что сеть компании устроена так, что у компании есть только один лес, и у каждого отдельного офиса есть свой домен в этом лесу. На первый взгляд эта структура звучит не так уж плохо. Это может показаться даже логичным. Имейте в виду, однако, что осуществимость такого дизайна сводится к доверию.
Например, представьте, что вы сетевой администратор в офисе нашей вымышленной компании в Майами, штат Флорида. Однажды вам звонят из штаб-квартиры компании и хотят, чтобы вы предоставили доступ к определенному общему файлу группе маркетинга в офисе в Лас-Вегасе, штат Невада. Помните, что офис в Лас-Вегасе состоит из независимого домена, над которым у вас нет абсолютно никакого контроля. Вы можете слепо подчиняться штаб-квартире корпорации и назначать необходимые права, но помните, что у вас нет контроля над членством в группе маркетинга. Лучшее, что вы можете сделать, это надеяться, что сетевой администратор в Лас-Вегасе не сделает кого-то, кто нанесет вред вашим ресурсам, членом маркетинговой группы.
Как видите, все сводится к доверию. Вопрос в том, насколько вы доверяете администраторам других доменов? Что, если один из других администраторов нацелен на господство в сети? Обычно администратор уровня домена имеет административные разрешения на свой домен, но не на лес. Это означает, что они не имеют абсолютно никакого контроля над другими доменами. Однако все, что нужно администратору, чтобы стать администратором уровня леса, — это добавить свою учетную запись в группу администраторов предприятия. Существует множество эксплойтов повышения привилегий, которые можно использовать для добавления пользователя в группу администраторов предприятия. Поскольку рассматриваемый пользователь уже является администратором домена, такие эксплойты становится намного проще осуществить. Проще говоря, администратору уровня домена не потребуется много времени, чтобы повысить себя до администратора всего леса. Как только они это сделают, они получат полный контроль над каждым доменом в лесу, включая ваш.
Как видите, существует множество ситуаций, в которых полное доверие нежелательно. Если вашей компании требуется немного больше изоляции между доменами из соображений безопасности, рассмотрите возможность реализации нескольких лесов, а не одного леса.
Что хорошо в наличии нескольких лесов, так это то, что вы можете создавать доверительные отношения между лесами, где это необходимо. Однако когда между лесами создается доверие, оно существует только между доменами, которые явным образом одобрили доверие. Например, предположим, что домен с именем Posey был частью леса с несколькими доменами. Как часть этого леса, между доменом Posey и любым другим доменом в лесу будут автоматически устанавливаться доверительные отношения. Теперь предположим, что администратор домена Posey решил создать внешнее доверие с другим лесом. Администратор не сможет указать домену доверять всему лесу, поскольку внешние доверительные отношения могут быть созданы только на уровне домена. Следовательно, администратор должен явно указать, каким доменам во внешнем лесу он хотел бы доверять.
Представьте, что администратор домена Posey создал кучу внешних доверительных отношений без ведома администратора уровня леса своей компании. Это не имеет значения, потому что эти трасты не могут подорвать безопасность леса. Тот факт, что домен Posey доверяет некоторым доменам из внешнего леса, не означает, что другие домены в том же лесу, что и домен Posey, будут соблюдать это доверие. На самом деле, что касается других доменов, доверия даже не существует. Если другие домены в лесу хотят соблюдать внешние доверительные отношения, администраторы этих доменов должны явно определить доверительные отношения от своего собственного домена к внешним доменам.
Вывод
Как видите, бывают случаи, когда доверие каждого из доменов вашей компании друг к другу представляет серьезную угрозу безопасности. В таких случаях вы можете изолировать домены или группы доменов, создав отдельные леса. Затем вы можете создавать внешние доверительные отношения, которые позволяют определенным доменам доверять другим внешним доменам, не опасаясь случайного установления непреднамеренных доверительных отношений.