Основные понятия

Глава 6: Управление доступом

Опубликовано 11 мая 2004 | Обновлено 26 июня 2006

Управление доступом состоит из процессов и технологий контроля и наблюдения за доступом к ресурсам в соответствии с действующими правилами. Управление доступом включает в себя следующее:

• проверку подлинности;

• авторизацию;

• отношения доверия;

• аудит системы безопасности.

На этой странице

Проверка подлинности Авторизация Доверие и федерация Аудит системы безопасности

Проверка подлинности

В рамках платформы управления идентификаторами и доступом корпорации Майкрософт рекомендуется использовать службы каталогов Microsoft® Active Directory® в качестве технологии для хранения идентификационной информации, включая криптографические ключи, используемые для проверки учетных данных пользователей в ходе такого процесса.

Для проверки подлинности приложения, интегрированные с Microsoft Windows Server™ 2003, Microsoft Windows® XP Professional и Windows Security Services, используют встроенные функции операционной системы.

Службы проверки подлинности Windows

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

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

Архитектура службы проверки подлинности Windows

Windows Server 2003 и Microsoft Windows XP используют полный набор методов проверки подлинности и протоколов безопасности, удовлетворяющий большому числу требований приложений в отношении проверки подлинности. Такие механизмы с различными характеристиками безопасности, как служба Microsoft .NET Passport, проверка подлинности открытых ключей с помощью сертификатов или смарт-карт, а также использование проверки подлинности на основе имени и пароля пользователя предоставляют различные возможности их использования по причине различия в требованиях для учетных данных. Кроме того, механизм передачи данных определяет допустимые протоколы, которые можно использовать для проверки подлинности.

Система безопасности службы проверки подлинности платформы управления идентификаторами и доступом корпорации Майкрософт является многоуровневой. Она включает в себя как низкоуровневые интерфейсы, предоставляющие большую гибкость и управление, так и высокоуровневые интерфейсы, обладающие меньшей гибкостью, но простыми интерфейсами прикладного программирования (API-интерфейсы). Следующий рисунок демонстрирует уровни протоколов проверки подлинности и API-интерфейсов приложений.

Рис. 6.1. Структура иерархии протоколов и API-интерфейса проверки подлинности в операционной системе Windows

Из предыдущего рисунка видно, что на вершине стека проверки подлинности службы и API-интерфейсы высокого уровня предоставляют механизмы межпроцессного взаимодействия (IPC), предлагающие безопасный проверенный канал для передачи данных приложений. Примерами таких служб и API-интерфейсов являются модель DCOM, механизм удаленного вызова процедур (RPC), Microsoft ASP.NET, ASP, WinInet и прочие.

Механизм RPC корпорации Майкрософт является мощным, эффективным и безопасным IPC механизмом, позволяющим выполнять обмен данными и вызовы процедур, находящиеся в других процессах. Указанные процессы могут находиться на том же самом компьютере, в локальной сети или в Интернет.

WinInet представляет собой интерфейс протокола приложений, предназначенный для поддержки протоколов безопасности Интернет, таких как протокол уровня защищенных сокетов (SSL) поверх протоколов Интернет. Для реализации поддержки безопасности в WinInet используется интерфейс поставщика поддержки безопасности (SSPI) для поставщика безопасности защищенного канала (реализация SSL для Windows NT®).

В некоторых случаях API-интерфейсы, которые предоставляются данными службами, дают разработчику приложения полный контроль над процессом проверки подлинности и защиты данных. Например, API-интерфейсы DCOM разрешают разработчику выбрать определенный протокол проверки подлинности, такой как Kerberos или протокол NT LAN Manager (NTLM)/вопрос-ответ. В нем также указывается, должны ли данные быть подписаны (тем самым защищая против изменения данных злоумышленником) или зашифрованы (тем самым защищая против просмотра передаваемых данных). Прочие службы и API-интерфейсы зависят от конфигурации системы. Наилучший пример представляет средство ASP.NET, размещенное на сервере с установленными службами IIS 6.0, которые могут быть настроены на использование механизма проверки подлинности при запуске требуемого сценария.

Интерфейс поставщика поддержки безопасности

Интерфейс SSPI является прикладным интерфейсом самого нижнего уровня и представляет собой разработанную корпорацией Майкрософт версию API-интерфейса универсальной службы безопасности (GSS). Дополнительные сведения об API-интерфейсе службы GSS см. в документах RFC 1508 и 1509 на веб-узле ITEF Request for Comments.

Дополнительные сведения об интерфейсе SSPI см. на веб-узле MSDN в статье The Security Support Provider Interface Revisited (на английском языке).

Идея, лежащая в основе SSPI и API-интерфейса GSS, состоит в том, что сетевая проверка подлинности при взаимодействии двух сторон, как правило, проходит по единому сценарию. Сторонам необходимо обменяться одним или несколькими пакетами данных в определенной последовательности. Поскольку они могут взаимодействовать друг с другом посредством одного из многочисленных сетевых протоколов — например, с помощью протокола передачи гипертекста (HTTP), RPC, протокола передачи блоков сообщений сервера (SMB), протокола Internet Inter-ORB (IIOP), DCOM, протокола удаленного вызова методов Java (RMI) и прочих протоколов, — было бы разумным не ограничиваться в использовании только однократного согласования при проверке подлинности в самом сетевом протоколе. Лучшим решением является предоставление универсального интерфейса, генерирующего «маркеры проверки подлинности», которые представляют собой блоки двоичных данных, участвующих в последовательности процедуры проверки подлинности. Обмен указанными маркерами происходит при использовании любого протокола приложений.

Например, в протоколе RPC согласование при установке соединения используется для синхронизации протоколов между клиентом и сервером. Протокол RPC просто выделяет место при обмене данных для непрозрачных маркеров проверки подлинности произвольного размера. По большей части работа SSPI и API-интерфейсов GSS заключается в формировании и проверке данных маркеров.

Как указывалось ранее, операционные системы клиентских компьютеров и Windows Server используют разнообразные протоколы проверки подлинности. Данные протоколы являются «пакетами системы безопасности» (иногда называемые пакетами проверки подлинности), состоящими из библиотек DLL, загружаемых службой локального администратора безопасности LSAS. SSPI является интерфейсом для всех пакетов системы безопасности, который присутствует в операционных системах клиентских компьютеров и Windows Server. В указанных пакетах системы безопасности обычно реализован один из сетевых протоколов проверки подлинности, например: Kerberos версии 5, протокол NTLM/вопрос-ответ, протокол краткой проверки подлинности, протокол уровня защищенных сокетов SSL или протокол безопасности уровня транспорта TLS. Приложения могут использовать данные протоколы для безопасной и беспрепятственной интеграции с Active Directory с целью проверки подлинности, а также использовать возможности протоколов для защиты своих данных.

Пакет согласования протоколов безопасности (SPNEGO) — это специальный пакет системы безопасности, который служит для необходимого согласования протоколов проверки подлинности. Рекомендуется в приложениях использовать пакет SPNEGO вместо непосредственного использования интерфейса SSPI совместно с протоколом Kerberos версии 5 или NTLM. Дополнительные сведения о пакете SPNEGO см. на веб-узле MSDN в статье Windows Security (на английском языке).

Проверка подлинности на основе протокола Kerberos

Протокол проверки подлинности Kerberos версии 5 описан на странице IETF RFC 1510 веб-узла «Request for Comments». Данный протокол является безопасным и масштабируемым, что делает его идеальным для проверки подлинности в интегрированной сетевой среде.

На клиентских компьютерах и серверах с установленной на них операционной системой Microsoft Windows 2000 Server либо более поздней версией протокол Kerberos версии 5 является базовым средством проверки подлинности для Active Directory. Данный протокол интегрирован в протоколы SMB, HTTP и RPC, а также используется клиент-серверными приложениями, которые используют указанные протоколы. Платформа Windows предлагает пользователям беспрепятственно и комплексно использовать это мощное средство обеспечения безопасности.

Протокол Kerberos версии 5 представляет особую важность для платформы управления идентификаторами и доступом корпорации Майкрософт, поскольку он основан на открытом стандарте. Большинство других поставщиков программного обеспечения также создали собственные реализации протокола Kerberos версии 5, основанного на реализации Массачусетского технологического института (MIT), что создало основу для совместимости механизмов проверки подлинности между платформами и приложениями от Майкрософт и других компаний.

Для достижения такой совместимости Windows предоставляет два способа настройки протокола Kerberos версии 5.

• Можно установить отношения доверия между доменом Windows и областью действия протокола Kerberos версии 5 на основе реализации MIT. Данные отношения позволяют клиентам области проходить проверку подлинности и получать доступ к ресурсам домена Windows.

• Клиенты, использующие операционные системы, отличные от Windows, могут использовать учетные записи Active Directory для прохождения проверки подлинности на контроллере домена.

В интрасети реализации протокола Kerberos версии 5 на платформе Windows обеспечивают единый вход (SSO) пользователей благодаря основным характеристикам протокола и особенностям реализации его в настольных и серверных операционных системах Windows.

Имеется одно значительное ограничение, которое препятствует тому, чтобы протокол Kerberos версии 5 стал универсальным решением для проверки подлинности приложений и обеспечения безопасности. Это ограничение заключается в том, что практически невозможно настроить проверку подлинности Kerberos для использования в Интернет. Причины таких особенностей детально обсуждаются далее в этой главе в разделе «Единый веб-вход».

Дополнительные сведения о протоколе проверки подлинности Kerberos версии 5 см. на веб-узле Microsoft TechNet в документе Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability (на английском языке).

Протокол уровня защищенных сокетов SSL 3.0 и протокол безопасности уровня транспорта TLS 1.0

Протоколы SSL 3.0 и TLS 1.0 тесно связаны между собой, и поэтому их можно использовать для решения общей задачи обеспечения безопасного соединения между двумя приложениями. Протокол SSL 3.0 является собственностью фирмы Netscape Communications, в то время как TLS 1.0 представляет собой стандарт IETF RFC 2246, определенный на веб-узле «Request for Comments». Протоколы похожи друг на друга, однако протокол TLS имеет несколько значительных усовершенствований, поэтому Майкрософт рекомендует, по возможности, использовать его. И TLS, и SSL предоставляют возможность проходить проверку подлинности на стороне сервера при установлении безопасного канала данных. При этом также можно использовать проверку подлинности на стороне клиента.

Протоколы SSL и TLS чаще всего используются для обеспечения защиты данных и целостности (шифровании) поверх протокола HTTP. Другие протоколы также обеспечивают поддержку протоколов SSL или TLS. Например, упрощенный протокол доступа к каталогам (LDAP) включает в себя SSL для реализации LDAP поверх SSL, или LDAPS. В дополнение к этому собственные приложения или приложения сторонних разработчиков могут использовать протоколы SSL или TLS с помощью интерфейса SSPI и определять пакет системы безопасности SChannel.

Протоколы SSL и TLS используют проверку подлинности, основанную на сертификатах, и безопасную передачу данных с использованием симметричных ключей шифрования. В Интернет протоколы SSL и TLS используются для проверки подлинности на стороне сервера. В протоколах SSL и TLS со стороны клиента проверяются следующие условия для проверки подлинности серверов:

• сертификат сервера является действительным;

• сервер предоставил доказательства владения соответствующим закрытым ключом, связанным с сертификатом сервера X.509;

• проверяемый сервер представляет собой тот же самый сервер, указанный в сертификате.

Протоколы SSL и TLS также поддерживают и предоставляют проверку подлинности на стороне клиента для платформы Windows Server 2003 посредством клиентских сертификатов X.509. Одновременная проверка подлинности на стороне клиента и сервера носит название взаимной проверки подлинности. Для завершения проверки подлинности на стороне клиента, клиент предоставляет действительный клиентский сертификат, оцениваемый сервером по тем же самым критериям, применяемым при проверке подлинности на стороне сервера. После проверки клиентского сертификата Windows Server разрешает сопоставление его с учетной записью в Active Directory. Active Directory обеспечивает гибкость при сопоставлениях сертификатов, допуская сопоставления «один-к-одному» и «многие-к-одному».

По отношению к другим протоколам проверки подлинности протоколы SSL и TLS обладают хорошими характеристиками в отношении обеспечения безопасности при использовании цифровых сертификатов X.509 для проверки подлинности.

Примечание.   Протоколы SSL и TLS обеспечивают пользователей процедурой единого веб-входа (SSO) посредством диспетчера учетных данных Windows на клиентском компьютере с Windows XP, описанного далее в данной главе.

Проверка подлинности с использованием службы Microsoft Passport

Служба Microsoft Passport представляет собой веб-службу, осуществляющую проверку подлинности пользователей с использованием базы данных цифровых идентификаторов. Пользовательские идентификаторы Passport хранятся на безопасном веб-узле. Служба Passport предоставляет возможность проверки подлинности и единого веб-входа на многих веб-узлах. Данная служба используется на многих веб-узлах корпорации Майкрософт, а также на некоторых узлах, не принадлежащих Майкрософт.

Разработчики могут создавать приложения, которые используют службу Passport. При этом такие приложения будут принимать подключения только от зарегистрированных пользователей службы Passport. Если эта служба определяет достоверность пользовательских данных, она возвращает билет проверки подлинности, который дешифруется приложением для определения учетных данных пользователя. По причине требований о сохранении конфиденциальности при обычной проверке подлинности служба Passport предоставляет соответствующему приложению только уникальный идентификатор паспорта (PUID).

В дальнейшем приложение, как правило, сопоставляет PUID с учетной записью локального пользователя для получения цифрового идентификатора, действующего в данной организации. Windows Server 2003 предоставляет полную интеграцию со службой PUID при установке параметра проверки подлинности Passport в IIS 6.0. В дополнение к этому можно сопоставить пользователей службы Passport с учетными записями Active Directory для обеспечения полной интеграции механизма проверки подлинности с моделью безопасности Windows.

Проверка подлинности Passport предоставляет пользователям возможность использовать единый вход в приложениях, ориентированных на использование в Интернет. Для этого служба Passport выдает билет проверки подлинности, зашифрованный в файле «cookie» HTTP. Наличие файла «cookie», сохраняемого в течение сеанса работы обозревателя, обеспечивает проверку подлинности при работе нескольких приложений без необходимости нескольких сеансов регистрации пользователя в службе проверки подлинности Passport.

Дополнительные сведения о службе Passport см. на веб-узле MSDN в документе .NET Passport Service Guide Kit (на английском языке).

Протокол краткой проверки подлинности

Краткая проверка подлинности представляет собой еще один протокол проверки подлинности, стандарт которого определен в документе RFC 2617 на веб-узле «Request for Comments». Данный протокол входит в пакет проверки подлинности Windows Server 2003. Протокол краткой проверки подлинности обеспечивает совместимость механизмов проверки подлинности в Интернет для Windows- и не-Windows-платформ.

В Windows Server 2003 также имеется реализация данного протокола в качестве механизма простой проверки подлинности и уровня безопасности (SASL), определенного в документе RFC 2831 на веб-узле «Request for Comments». SASL является еще одним абстрактным уровнем между приложением и нижележащим протоколом и позволяет легко привлекать различные механизмы проверки подлинности без изменения самого приложения. В некотором отношении он подобен описанному ранее механизму SPNEGO. Протокол SASL главным образом используется для проверки подлинности в протоколе LDAP.

Протокол краткой проверки подлинности обладает характеристиками безопасности, аналогичными характеристикам протокола NTLM. Протоколы NTLM и краткой проверки подлинности являются протоколами типа «вопрос-ответ», где сервер, выполняющий проверку подлинности, генерирует вопрос, содержащий некоторый объем случайных данных. После этого клиент формирует ответ путем шифрования данных, содержащихся в вопросе, с помощью ключа, полученного из пароля пользователя. Сервер или доверенная служба, например Active Directory, проверяет правильность пароля пользователя путем сравнения ответа клиента со значением, вычисленным на основе учетных данных пользователя, находящихся в хранилище идентификаторов. Если ответ соответствует вычисленному значению, то считается, что пользователь знает пароль и проверка подлинности завершается успешно.

В целом протокол краткой проверки подлинности не является таким же безопасным, как протокол Kerberos версии 5, из-за того что он зависит от надежности паролей, используемых в механизме «вопрос-ответ». Однако отсутствие паролей, передаваемых серверу в незашифрованном виде в ходе проверки подлинности, представляет собой лучшее решение, чем обычная проверка подлинности или проверка подлинности в формах. Протоколы SSL и TLS часто используются для защиты протокола краткой проверки подлинности от атак.

Протокол краткой проверки подлинности не обладает в большинстве случаев такими же возможностями масштабирования, как протокол Kerberos версии 5, однако он работает в случаях, когда Kerberos не используется. Пример такого случая — проверка подлинности на внешнем веб-узле.

Протокол краткой проверки подлинности обеспечивает единый вход только для единичного URL-адреса Интернета. Если пользователь переходит на другой узел или даже на другой сервер того же узла, то потребуется ввести свои учетные данные повторно.

Проверка подлинности в формах

Проверка подлинности в формах основывается на формах входа на веб-страницы, на которых учетные данные пользователя почти всегда вводятся в виде незашифрованного имени пользователя и пароля. Таким образом, данный тип проверки подлинности не представляет собой протокол проверки подлинности между клиентом и сервером в том же смысле, что и протокол Kerberos версии 5 или протокол краткой проверки подлинности, описанный в предыдущем разделе.

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

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

Разработчикам приложений, использующих проверку подлинности в формах, рекомендуется выполнять проверку подлинности пользователей в Active Directory с использованием привязки протокола LDAP либо посредством API-интерфейса Windows, например процедуры LogonUser(), выполнять проверку учетных данных пользователей и необязательное создание контекста безопасности, как описано далее в этой главе в разделе «Авторизация».

В приложениях, в которых реализована проверка подлинности в формах, для обеспечения единого входа пользователя обычно используются файлы «cookie» HTTP или модификации URL-адресов. ASP.NET обеспечивает соответствующие механизмы для защиты «cookies» от несанкционированного чтения с помощью шифрования и от изменений с помощью цифровых подписей.

В документе данной серии под названием «Разработка приложений на основе ASP.NET с учетом механизмов идентификации» содержатся дополнительные сведения для разработчиков по использованию проверки подлинности с помощью форм на платформе Windows.

Обычная проверка подлинности

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

Единый вход

Важной частью любой дискуссии о методах проверки подлинности является концепция единого входа (SSO). Существует несколько подходов для обеспечения единого входа как части процесса проверки подлинности:

• интегрированный единый вход на локальный компьютер;

• единый веб-вход;

• сопоставление учетных данных, или единый вход в рамках предприятия.

Идея, лежащая в основе единого входа, заключается в устранении необходимости повторного ввода учетных данных пользователя. При этом уровень безопасности используемого типа проверки подлинности не рассматривается. Некоторые типы единого входа могут быть предпочтительнее других в плане безопасности.

В дополнение к этому термины «единый вход в экстрасеть» и «единый вход в интрасеть» используются для описания технологий обеспечения единого входа в сценариях работы в интрасетях и экстрасетях. Единый вход в экстрасеть всегда связан с Интернетом, в то время как единый вход в интрасеть могут использовать различные типы приложений и служб, включая веб-приложения, приложения с «толстым» клиентом и терминальные сеансы работы.

Интегрированный единый вход на локальный компьютер

Безопасная регистрация требует, чтобы пользователь подтвердил свою идентификацию в сети, но повторный ввод пароля для доступа к различным ресурсам не очень желателен. Платформа Microsoft Windows позволяет извлечь выгоду из возможности использования единого идентификатора пользователя (хранящегося в Active Directory) в пределах всей сети. Поскольку учетные данные, используемые для регистрации пользователя на рабочей станции, часто совпадают с учетными данными для доступа к ресурсам сети, то они (имя пользователя и пароль) кэшируются локальным администратором безопасности (LSA) операционной системы клиентского компьютера. При регистрации пользователя в домене механизм проверки подлинности Windows использует кэшированные учетные данные для обеспечения единого входа при доступе к ресурсам сети.

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

Протокол проверки подлинности Kerberos версии 5, протокол NTLM и технологии проверки подлинности с использованием смарт-карт интегрированы в процесс входа в клиентских и серверных операционных системах, чтобы обеспечить единый вход для пользователей в пределах домена или леса Windows интрасети организации. Active Directory предоставляет доверенную сторону, которая позволяет выполнять проверку пользователей на серверах без необходимости локально хранить информацию о таких пользователях.

Расширенные механизмы доверия, например перекрестные отношения доверия между лесами в Windows Server 2003, позволяют идентификаторам из одного леса использовать единый вход при получении доступа к ресурсам другого леса.

Единый веб-вход

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

Веб-приложения отличаются от традиционных «толстых» клиент-серверных приложений, поскольку реализация методов проверки подлинности напрямую зависит от веб-сервера. Данная зависимость позволяет использовать общий подход для добавления механизмов проверки подлинности в одно приложение (веб-сервер), при этом решая вопросы проверки подлинности для большого количества приложений, размещенных на сервере. В пределах интрасетей серверные и клиентские продукты Microsoft обеспечивают единый веб-вход на основе реализации протокола проверки подлинности Kerberos версии 5 в Internet Explorer и службах IIS 6.0, как описано в документе данной серии «Управление доступом в интрасетях».

К сожалению, реализация протокола Kerberos превосходно работает в сценариях для интрасети, но показывает плохие результаты при использовании ее для приложений Интернет. Различия между единым веб-входом в интра- и экстрасети получаются из сочетания трех факторов:

• присущие трудности при развертывании интернет-ориентированного центра распределения ключей (KDC), например контроллера домена Active Directory;

• многие обозреватели не поддерживают проверку подлинности Kerberos поверх протокола HTTP;

• присущие уязвимости в протоколе KDC.

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

Вторая проблема обычно представляет больший интерес для разработчиков приложений для экстрасетей. В отличие от приложений для интрасетей, стандарты которых неукоснительны, немногие организации могут диктовать тип и версию программного обеспечения, используемого внешними пользователями и деловыми партнерами при работе с приложениями для экстрасетей. Microsoft Internet Explorer версии 6.0 и выше представляет собой единственный имеющийся коммерческий обозреватель, поддерживающий проверку подлинности Kerberos поверх HTTP.

Стандартным подходом решения проблемы единого входа для нескольких веб-приложений является использование сеансовых файлов «cookies» в соответствии с механизмом управления состоянием HTTP, определенным в документе IETF RFC 2109 на веб-узле «Request for Comments». Некоторые независимые поставщики программного обеспечения (ISV) предлагают решения, которые позволяют обеспечить единый веб-вход во внешние веб-приложения.

Служба Microsoft Passport, подробно обсуждаемая выше, также обеспечивает единый вход пользователя на узлы, которые поддерживают проверку подлинности службой Passport.

Можно сочетать единый веб-вход с технологиями единого входа в сеть предприятия, например с применением веб-узла сервера портала SharePoint Portal Server, который включает в себя веб-части для организации возможности работы устаревших приложений в пределах одного каталога идентификаторов, используемых для проверки подлинности. В данном примере единый веб-вход обеспечивает доступ к веб-узлу, а единый вход в сеть предприятия обеспечивает использование устаревших приложений.

Сопоставление учетных данных и единый вход в сеть предприятия

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

Microsoft BizTalk® Server, Host Integration Server, SharePoint® Portal Server, Windows Credential Manager и продукты независимых поставщиков программного обеспечения, например PassLogix, Protocom и Version3, используют различные методы единого входа в сети предприятия для устаревших систем, приложений, использующих свои собственные каталоги идентификаторов, и даже для доступа к ресурсам, расположенным в недоверенных доменах Windows.

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

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

Дополнительные сведения о сопоставлении учетных данных в рамках единого входа в сеть предприятия см. в документе данной серии «Управление доступом в интрасетях».

Диспетчер учетных данных Windows

Операционные системы Windows XP Professional и Windows Server 2003 включают в себя функцию хранения имен и паролей пользователей, предоставляющую, кроме того, механизмы управления учетными данными. В зависимости от выбранного метода проверки подлинности данное средство может сохранять учетные данные пользователя и повторно использовать их в следующих сеансах получения доступа.

Рис. 6.2. Средство хранения имен и паролей пользователей позволяет выполнять единый вход для нескольких наборов учетных данных

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

• комбинации имя пользователя/пароль для протокола Kerberos версии 5 и NTLM;

• цифровые сертификаты X.509 для проверки подлинности клиентов с использованием протоколов SSL/TLS;

• учетные данные службы Microsoft Passport для проверки подлинности в Интернет.

Примечание.   Существует возможность использовать диспетчер учетных данных Windows для обеспечения единого веб-входа с помощью проверки подлинности клиентских сертификатов SSL/TLS X.509. По умолчанию пользователю предоставляется выбор сертификата для проверки подлинности при наличии более чем одного действительного сертификата. Диспетчер учетных данных обеспечивает автоматическое предоставление нужного сертификата при попытке доступа к какому-либо ресурсу.

Дополнительные сведения о диспетчере учетных данных Windows см. в документе данной серии «Управление доступом в интрасетях».

К началу страницы

Авторизация

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

Приложения, интегрированные с операционной системой Windows Server 2003 и Active Directory, используют встроенные функции операционной системы для прохождения авторизации.

Windows Server 2003 поддерживает два механизма авторизации: модель олицетворения на основе списков управления доступом (ACL) Windows и новый диспетчер авторизации на основе ролей. Кроме того, приложения Microsoft ASP.NET для авторизации могут использовать роли ASP.NET. Оба механизма подробно обсуждаются в следующих разделах.

Олицетворение и списки управления доступом Windows

Впервые модель олицетворения и списков управления доступом ACL была применена в операционной системе Microsoft Windows NT 3.1, что обеспечило авторизацию для служб и приложений. Олицетворение представляет собой результат тесной связи механизмов проверки подлинности и авторизации с целью обеспечения беспрепятственной работы пользователей и возможности легкого управления.

Пакет проверки подлинности проверяет пользователя, а затем создает для него «контекст безопасности». Контекст безопасности представляет собой идентификатор и группы, к которым принадлежит пользователь, а также набор прав пользователя. После создания пакетом проверки подлинности контекста безопасности приложение или служба использует его для разрешения доступа к ресурсам. Другими словами, при попытке доступа к ресурсам служба олицетворяет пользователя на локальном компьютере, используя контекст безопасности данного пользователя вместо своего контекста.

Это представляет собой важное понятие, поскольку большинство служб имеют существенные привилегии на компьютере. Например, служба протокола передачи блоков сообщений сервера (SMB), обеспечивающая доступ к файлам и принтерам на серверах с операционной системой Windows, работает под учетной записью локальной системы и имеет доступ к любому ресурсу. Для ограничения доступа пользователей к файлам согласно правилам, установленных владельцем файла или системным администратором, служба SMB олицетворяет удаленного пользователя.

Другая часть модели авторизации Windows — списки управления доступом на основе объектов. Список управления доступом для объекта определяет, какой уровень доступа имеют субъекты безопасности (пользователи или группы) в отношении данного объекта. Например, список управления доступом к файлу может определять, что один пользователь имеет право на чтение файла, в то время как другой пользователь имеет право на чтение и удаление файла.

В данной модели окончательное решение по предоставлению доступа к объектам возлагается на операционную систему, а точнее на диспетчер объектов NT. Диспетчер объектов NT сравнивает контекст безопасности пользователя со списком управления доступом для объекта. Поскольку окончательное решение остается за операционной системой, модель олицетворения/списков управления доступом по соображениям безопасности вполне пригодна для случаев, когда нескольким приложениям может потребоваться доступ к системному ресурсу.

Однако есть следующие случаи, когда можно улучшить модель олицетворения/списков управления доступом.

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

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

• Бизнес-правила. Модель олицетворения/списков управления доступом точно определяет параметры авторизации для объектов, однако сложно описать правила бизнес-логики, например время суток или другие параметры, зависящие от времени. Например, требуется применить какую-либо политику авторизации, которая разрешает некоторым пользователям выполнять некоторые действия в течение некоторого времени.

Для решения данных вопросов в помощь системным администраторам и разработчикам приложений в Windows Server 2003 включен диспетчер авторизации. Версию диспетчера авторизации для Windows 2000 можно найти на странице Windows 2000 Authorization Manager Runtime узла Microsoft.com.

Диспетчер авторизации Windows Server 2003

Диспетчер авторизации в Windows Server 2003 представляет собой новый интерфейс управления доступом на основе ролей (RBAC). Диспетчер авторизации предоставляет разработчикам следующие возможности:

• упрощение администрирования управления доступом для приложений;

• обеспечение упрощенной и естественной модели для разработки приложений;

• возможность реализации гибких и динамичных решений по обеспечению авторизации.

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

Рис. 6.3. Как диспетчер авторизации определяет и использует роли

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

Кроме того, диспетчер авторизации динамически осуществляет проверку прав, предоставленных во время выполнения. Данная возможность относится к отдельной проблеме авторизации, которая существует в бизнес-приложениях для Интернет, например приложениях для формирования отчетности по затратам или приложениях для торговли по Интернет.

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

Бизнес-правила обычно реализуются с помощью сценария Microsoft Visual Basic® Scripting Edition или JScript®, который выполняется при проверке прав доступа во время работы приложения. Если условия бизнес-правил удовлетворены, приложение выполняет требуемые операции.

Политики диспетчера авторизации, которые определяют логические роли и задания, используемые приложением, могут храниться в разделе приложения в Active Directory или Active Directory Application Mode, либо в XML-файле на сервере или в сети.

Дополнительные сведения об использовании RBAC диспетчером авторизации Windows Server 2003 см. на веб-узле TechNet в статье Authorization Manager Concepts (на английском языке).

IIS 6.0 представляет собой пример того, как приложение может использовать платформу диспетчера авторизации, основанную на ролях. Интеграция поставляемых с Windows Server 2003 служб IIS 6.0 с диспетчером авторизации реализует URL-авторизацию IIS 6.0. Такая интеграция позволяет администраторам веб-приложений управлять доступом к URL-адресам на основе ролей пользователей, LDAP-запросов и бизнес-правил.

Процесс авторизации доступа пользователей к веб-страницам в IIS 6.0 может потребовать управления многочисленными независимыми списками управления доступом (DACL) к ресурсам, используемым веб-приложением. Ресурсы веб-приложений могут состоять из файлов веб-страниц, записей баз данных и ключей реестра. Обслуживание DACL-списков требует от администраторов точных знаний о том, какие требования к внутренним разрешениям предъявляются в отношении каждого объекта для выполнения им задач в рамках веб-приложения.

URL-авторизация IIS 6.0 позволяет администраторам упростить процесс управления доступом путем авторизации доступа пользователей к URL-ресурсам, относящимся к веб-приложению. Когда клиент запрашивает URL-ресурс, URL-авторизация IIS 6.0 проверяет права пользователя на основании его ролей. При необходимости веб-приложение может, кроме того, ограничить доступ к ресурсам и операциям с помощью платформы диспетчера авторизации, основанной на ролях.

Авторизация ASP.NET

Платформа ASP.NET обеспечивает модель авторизации на основе ролей, которая использует группы Active Directory и роли, определенные для приложения. Существует несколько схожих черт между диспетчером авторизации RBAC и авторизацией ASP.NET на основе ролей, однако они реализованы с помощью различных механизмов. Роли ASP.NET представляют наибольший интерес для отдельных приложений, которые, скорее всего, не входят в большой программный пакет.

К началу страницы

Доверие и федерация

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

Отношения доверия существуют между отдельными областями, при этом область определяет границу безопасности. В средах Windows NT и Active Directory можно установить отношения доверия между доменами. В Windows Server 2003 можно установить более высокие уровни доверия между лесами. Однако домены в пределах одного леса имеют неявные отношения доверия друг с другом.

Приложения, интегрированные с операционной системой Windows Server 2003 и Active Directory, используют встроенные функции операционной системы для установления и обеспечения отношений доверия.

Управление отношениями доверия

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

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

Внешние отношения доверия

Операционная система Microsoft Windows NT Server вводит понятие отношений доверия доменов. Отношения доверия доменов Windows NT, или, как сейчас это называется, внешние отношения доверия, разрешают одному домену Windows NT доверять другому домену Windows NT как имеющему полномочия для проверки подлинности пользователей, принадлежащих такому домену. Внешние отношения доверия могут быть однонаправленными или двунаправленными. Направление отношений доверия устанавливает направление, в котором выполняется процедура проверки подлинности и доступ, как показано на следующем рисунке.

Рис. 6.4. Отношения между доверяющим и доверяемым доменами

Модель, используемая в Windows NT Server 4.0, являлась достаточно гибкой и позволяла отделам создавать необходимые домены Windows NT 4.0 в соответствии с шаблонами восходящего массового развертывания. Проблема заключалась в том, что поскольку большие компании создавали все больше и больше одноуровневых доменов, управление внешними отношениями доверия становилось серьезной задачей. Поскольку каждый созданный домен может иметь N отношений доверия, общее количество отношений доверия быстро росло при увеличении количества доменов. Небольшая фирма с 4-мя доменами могла иметь только 12 различных отношений доверия, однако большая компания с 10-ю доменами могла иметь 90 отношений доверия. Компания с сотней доменов могла иметь еще большее число отношений доверия.

Леса на основе серверов Windows

Чтобы упростить задачу по управлению отношениями доверия в больших организациях, в Microsoft Windows 2000 Server было введено понятие леса Active Directory. Лес Active Directory сохраняет при необходимости гибкость восходящей модели отношений доверия Windows NT Server 4.0, однако создает проблему упрощения нисходящего управления отношениями доверия, как показано на следующем рисунке.

Рис. 6.5. Единичный лес на основе сервера Windows 2000

Рисунок демонстрирует организацию с единственным лесом на основе сервера Windows 2000. Отношения доверия в пределах леса устанавливаются неявно; такие отношения соответствуют двунаправленным внешним отношениям доверия, однако создаются автоматически при добавлении доменов (аналогично деревьям в лесу) в данный лес. Домены в пределах леса имеют иерархическую структуру, что позволяет зеркально отобразить структуру организации в ее собственной сети.

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

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

Дополнительные сведения о свойствах границ безопасности в доменах и лесах Windows см. на веб-узле Microsoft.com в документе Creating and Enhancing Security Boundaries (на английском языке).

В случае если организация имеет несколько лесов в Windows 2000 Active Directory и ей требуется установить отношения доверия между доменами из различных лесов, следует установить явные отношения доверия между всеми доменами одного леса со всеми доменами другого леса. Настройка такой конфигурации не намного проще, чем установка отношений доверия между всеми доменами Windows NT Server 4.0, поэтому явно требуется лучшее решение.

Отношения доверия лесов на основе Windows Server 2003

Для упрощения развертывания нескольких лесов в операционной системе Windows Server 2003 введено понятие отношений доверия лесов. Отношения доверия лесов позволяют администраторам объединять в федерацию два леса Active Directory с помощью отношений доверия с целью обеспечения беспрепятственной проверки подлинности и авторизации в пределах указанных лесов. Отношения доверия лесов представляют собой единственную связь доверия между корневыми доменами лесов, которая устанавливает переходные отношения доверия между всеми доменами каждого из лесов. Например, если Лес А доверяет Лесу Б, тогда все домены Леса А доверяют всем доменам Леса Б на основе отношений доверия лесов. Следующий рисунок иллюстрирует эту концепцию.

Рис. 6.6. Отношения доверия лесов на основе Windows Server 2003

Однако отношения доверия лесов не транзитивны. То есть если Лес А доверяет Лесу Б, а Лес Б доверяет Лесу С, то при этом Лес А не доверяет автоматически Лесу С.

Дополнительные сведения об использовании и настройке перекрестных отношений доверия между лесами на основе Windows Server 2003 см. на веб-узле Microsoft TechNet в документе Planning and Implementing Federated Forests in Windows Server 2003 (на английском языке).

Использование отношений доверия лесов

Отношения доверия лесов реализуют концепцию лесов, объединенных в федерацию, в Windows Server 2003. Как указывалось ранее, отношения доверия лесов, которые устанавливаются между их корневыми доменами, позволяют устанавливать переходные отношения доверия между всеми доменами обоих лесов.

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

Использование теневых учетных записей вместо отношений доверия

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

Концепция использования теневых учетных записей для пользователей может не быть очевидной, но в качестве примера можно рассмотреть случай, когда организация использует Active Directory для проверки подлинности пользователей во внутренней сети, но в дополнение к этому требуется обеспечить проверку подлинности пользователей из экстрасети. Имеется два варианта для проверки подлинности пользователей из экстрасети:

• использование отношений доверия лесов или доменов между граничной сетью (также называемой DMZ, демилитаризованной зоной или подсетью-экраном) и интрасетью;

• создание теневых учетных записей в граничной сети.

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

В организациях, где требуется полная изоляция между сетями, лучшим решением проблемы является использование теневых учетных записей. Майкрософт рекомендует создавать теневые учетные записи с помощью автоматических средств, например таких, которые имеются в Microsoft Identity Integration Server 2003 Enterprise Edition (MIIS 2003 SP1). Теневые учетные записи позволяют даже улучшить безопасность сети в некоторых сценариях, если они используют механизмы проверки подлинности, не основанные на паролях, для менее безопасных серверов, находящихся, например, в экстрасетях. В качестве примера можно привести проверку подлинности, основанную на клиентских сертификатах протоколов уровня защищенных сокетов (SSL) 3.0 и безопасности уровня транспорта (TLS) 1.0, либо механизмы проверки подлинности с однократным использованием пароля, например программное средство проверки подлинности SecurID, разработанное фирмой RSA Security Inc.

Отношения доверия на основе инфраструктуры открытых ключей

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

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

Например, путь сертификации корневого центра сертификации содержит один сертификат, который является самозаверенным. Для подчиненного центра сертификации, расположенного непосредственно под корневым центром, путь сертификации использует два сертификата: свой собственный сертификат и сертификат корневого центра сертификации.

Процесс импортирования корневого сертификата в хранилище доверяемого корневого центра сертификации представляет собой самый простой путь установления доверенных отношений на основе инфраструктуры открытых ключей для компьютера и его приложений. Например, если веб-сервер компании Contoso Pharmaceuticals (вымышленная организация) обладает корневым сертификатом центра сертификации фирмы Fabrikam Inc. (также вымышленная организация), размещенном в хранилище корневого центра сертификации, то в этом случае веб-сервер компании Contoso Pharmaceuticals будет доверять любому действительному сертификату, изданному центром сертификации фирмы Fabrikam Inc. Данный процесс устанавливает только отношения доверия для транзакции, однако идентификатор и контекст на веб-сервере не устанавливается. Чтобы выполнить сопоставление идентификаторов и контекста, следует выполнить другие действия, такие как сопоставление некоторой информации сертификата с участником безопасности Active Directory.

Дополнительные сведения о взаимной проверке подлинности с использованием сопоставления сертификатов Active Directory см. на веб-узле Microsoft Windows 2000 Server в документе Step-by-Step Guide to Mapping Certificates to User Accounts (на английском языке).

Хотя механизм с использованием хранилища доверенного корневого центра сертификации достаточно просто воплотить в жизнь, он может не удовлетворять требованиям безопасности в сложных сценариях, в которых устанавливаются федеративные отношения доверия между двумя организациями, такими как, например, Contoso Pharmaceuticals и Fabrikam Inc.. Рассмотрим случай, когда пользователи обеих фирм Contoso Pharmaceuticals и Fabrikam Inc. могут предоставить действительные сертификаты для доступа к веб-узлу фирмы Contoso Pharmaceuticals. Внешний каталог Active Directory в данном случае содержал бы сопоставления сертификатов центров сертификации фирм Contoso Pharmaceuticals и Fabrikam Inc.

Одним из способов будет создание сопоставления на основе темы сертификата, например: E=fred@fabrikam.com. Проблема при таком подходе состоит в том, что отношения доверия ничем не ограничены. Неограниченные отношения доверия означают, что компания Contoso Pharmaceuticals полностью доверяет фирме Fabrikam Inc. и не издает сертификат с темой E=fred@contoso.com, где fred@contoso.com является пользователем фирмы Contoso Pharmaceuticals, а не Fabrikam Inc. При таком сценарии обладатель сертификата может получить доступ к конфиденциальным данным на узле фирмы Contoso Pharmaceuticals. Данная проблема возникает не из-за того, что в отношениях доверия на основе инфраструктуры открытых ключей имеются слабые места, а по причине слишком широкого определения сертификата. Проблема решается путем более точной настройки механизма отношений доверия на основе инфраструктуры открытых ключей, при которой фирма Fabrikam Inc. должна была бы издать сертификаты для домена @fabrikam.com, а не для домена @contoso.com.

Квалифицированное подчинение

В сетях Windows 2000 не существовало полноценной перекрестной сертификации структур иерархий центров сертификации. Единственной возможной альтернативой было создание списков сертификатов доверенных отношений (CTL), которые доверяли определенным центрам сертификации и ограничивали использование сертификатов.

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

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

Квалифицированное подчинение позволяет налагать дополнительные условия на отношения доверия в пределах и между доменами в текущей инфраструктуре открытых ключей для расширения структуры отношений доверия. При квалифицированном подчинении квалифицированные подчиненные центры сертификации в текущей структуре иерархии отношений доверия могут иметь различные правила издания сертификатов и их использования.

Примером того, как условия отношений доверия могут использоваться для решения вышеописанной проблемы при достаточно широком определении сертификата, может служить использование ограничений пространства имен при установлении перекрестной сертификации между структурами иерархий фирм Contoso Pharmaceuticals и Fabrikam Inc.. При таком подходе фирма Contoso Pharmaceuticals будет принимать только те сертификаты от фирмы Fabrikam Inc., в которых определен домен fabrikam.com.

Дополнительные сведения о квалифицированном подчинении см. на веб-узле Microsoft TechNet в документе Qualified subordination (на английском языке).

Реализация федерации

Управление идентификаторами в федерации представляет собой стандартную технологию и информационный технологический процесс, который обеспечивает распределенную идентификацию, проверку подлинности и авторизацию в рамках организации и используемой платформы. Системы, объединенные в федерацию, взаимодействуют в пределах организации и связывают процессы, использующие различные технологии, хранилища идентификаторов, меры по обеспечению безопасности и программные модели. Организации, находящейся в пределах федеративной системы, требуется стандартизированный и безопасный способ предоставления услуг для доверенных партнеров и клиентов. Кроме того, в организации должны быть реализованы определенные бизнес-правила, например:

• какие другие организации и пользователи имеют доверие;

• какие типы учетных данных и запросов принимаются;

• каковы политики в отношении конфиденциальности.

Операционная система Microsoft Windows Server 2003 R2 вводит понятие служб федерации Active Directory (ADFS), что обеспечивает безопасное распространение учетных данных пользователей. Службы федерации Active Directory обеспечивают возможность единого входа для проверки подлинности пользователя в нескольких веб-приложениях в пределах одного сеанса работы. Это достигается за счет безопасного обмена цифровыми идентификаторами и имеющимися правами, называемыми «заявками», не ограничиваясь границами безопасности и границами предприятий.

Службы федерации работают с Active Directory и с Active Directory Application Mode (ADAM). Если точнее, то ADFS работает и с каталогами Active Directory, развернутыми на всем предприятии, и с экземплярами ADAM. При работе с Active Directory службы федерации используют преимущества надежных технологий проверки подлинности Active Directory, включая протокол Kerberos, цифровые сертификаты X.509 и смарт-карты. При работе с ADAM, службы федерации используют привязку к упрощенному протоколу доступа к каталогам (LDAP) для целей проверки подлинности пользователей.

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

Дополнительные сведения о службах федерации Active Directory см. на веб-узле Microsoft.com в документе Overview of Active Directory Federation Services (ADFS) in Windows Server 2003 R2 (на английском языке).

К началу страницы

Аудит системы безопасности

Аудит представляет собой средство наблюдения за событиями управления доступом и изменениями идентификаторов объектов. Аудит безопасности, как правило, используется для текущего контроля в целях обнаружения нарушений в работе и брешей в защите. Такие технологические решения, как журнал событий безопасности Windows, интерфейс управления Windows (WMI) и программные продукты, например MOM 2005 SP1, обеспечивают полный аудит системы безопасности и выдачу соответствующих отчетов.

Аудит службы каталогов

Active Directory и ADAM полностью интегрированы в систему аудита Windows Server 2003. Журнал событий безопасности Windows регистрирует изменения в объектах каталогов и их атрибутах, а также в политике авторизации для объектов каталогов и их атрибутов, схемы и групповой политики. Тщательный контроль обеспечивается настройкой событий аудита — успеха, отказа или попытки действия.

Аудит процедуры проверки подлинности

Все механизмы проверки подлинности Windows, описанные выше, генерируют события аудита, регистрируемые в журнале событий безопасности Windows. Можно настроить типы генерируемых событий (например, успех или отказ проверки подлинности) с использованием групповой политики, либо можно настроить каждый сервер вручную.

Кроме того, Windows Server 2003 обеспечивает точное управление событиями проверки подлинности путем размещения их по категориям в соответствии с типом проверки подлинности. Например, один тип событий аудита отслеживает консольные входы в систему, в то время как другой отслеживает попытки доступа к сетевым ресурсам. События аудита проверки подлинности всегда однозначно ведут к определенному участнику безопасности.

После того как пользователь прошел проверку подлинности в одном хранилище идентификаторов, следующим шагом будет определение тех объектов, к которым у него имеется доступ. Авторизация представляет собой процесс управления доступом к ресурсам.

Аудит авторизации

Платформа Windows Server обеспечивает полную поддержку для осуществления аудита действий по авторизации. В модели олицетворения/списков управления доступом диспетчер объектов NT сообщает о событиях аудита при доступе к ресурсам в соответствии с настройками аудита. Можно установить данные настройки в групповой политике либо выполнить ручную настройку каждого сервера. Когда система генерирует такие события аудита, они регистрируются в журнале событий безопасности системы.

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

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

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

Аудит отношений доверия

В Windows Server 2003 осуществляется полный детальный аудит конфигурации отношений доверия. Можно осуществлять аудит событий создания, удаления и изменения отношений доверия. События аудита отношений доверия регистрируются в журнале событий безопасности.

Загрузить

Получите серию статей Microsoft по управлению идентификаторами и доступом

Уведомления об обновлениях

Зарегистрируйтесь, чтобы получать информацию об обновлениях и новых выпусках

Обратная связь

Отправить замечания или пожелания

К началу страницы