|
Страница 4 из 5
CryptoAPI
| | Рисунок 2. CryptoAPI: комплексное решение для поддержки служб шифрования. | CryptoAPI — такой же базовый компонент защитной архитектуры Windows 2000, как и Active Directory. Задача CryptoAPI состоит в универсализации работы с низкоуровневыми службами шифрования для всех приложений и компонентов операционной системы. Как показано на Рисунке 2, это достигается путем установки программных модулей CSP — поставщиков услуг шифрования. С помощью стандартного интерфейса модули формируют ключи и цифровые подписи, предоставляют сервисы шифрования, хэширования, обслуживают сертификаты. По принципу работы CryptoAPI аналогичен интерфейсу ODBC, через который приложение может получить доступ к различным базам данных. CryptoAPI позволяет снизить затраты на создание приложений Windows 2000 по трем направлениям. Во-первых, разработчикам не приходится изобретать системы шифрования. Во-вторых, они могут сразу выпустить приложение, способное поддерживать различные протоколы и стандарты шифрования. В-третьих, при изменении системы шифрования нет необходимости перерабатывать приложение. Хотя CryptoAPI был реализован еще в Windows NT 4.0, теперь в него включен ряд важных дополнений в части поддержки PKI. Например, он позволяет запрашивать и публиковать сертификаты, списки недействительных сертификатов (Certificate Revocation Lists, CRL), а также дает возможность проследить историю сертификата, когда серверному приложению необходимо проверить его подлинность. Поскольку CryptoAPI работает со стандартами PKCS и X.509 версии 3, его можно использовать для управления сертификатами, размещаемыми в хранилище сертификатов Windows 2000, в Active Directory, а также в независимых сертификационных центрах (Certificate Authorities, CA). Certificate Server Приложение Certificate Server, также впервые реализованное в Windows NT 4.0, формирует базовые функции сертификационного центра в части запроса, выпуска, публикации и управления сертификатами. Certificate Server предоставлял средства аутентификации по Authenticode и обеспечивал возможность интеграции с Exchange Server через протокол Secure MIME (S/MIME). Вместе с тем он разрабатывался лишь как инструмент аутентификации клиентов с помощью открытого ключа в Internet Information Server (IIS). При этом управление настройками Cetrtificate Server производилось ручным редактированием текстовых файлов. Данному продукту явно не хватало функций управления, важных для применения PKI в корпорации, например средств настройки типов сертификата и параметров политик. Кроме того, он поддерживает только двухуровневые иерархии сертификационных центров (чего явно недостаточно для крупномасштабных систем). В Windows 2000 название Certificate Server заменено на Certificate Services. При этом приложение стало более мощным и тесно интегрированным с операционной системой. Модули расширения в составе Microsoft Management Console (MMC) предоставляют графические инструменты настройки как на стороне клиента, так и на стороне сервера. Certificate Services может работать с собственным автономным хранилищем данных. Однако, в целях оптимального решения корпоративных задач, для хранения и публикаций сертификатов приложение использует Active Directory. С помощью AD можно связывать сертификаты и пользователей, а также посредством GPE контролировать, кому, от чьего имени и для каких целей Certificate Services выдала сертификаты. Наконец, данная служба теперь поддерживает многоуровневые иерархии. На Рисунке 3 видно, как сильно «похудела» Certificate Services по сравнению с Certificate Server, чьи отдельные части были переданы другим компонентам операционной системы.
| | Рисунок 3. Модульная структура Certificate Server в Windows 2000 | Например, функции управления сертификатами теперь включены в состав CryptoAPI, а автономное хранилище информации о сертификатах размещено в Active Directory. Поскольку Certificate Services получает доступ к своему хранилищу сертификатов через CryptoAPI, то можно публиковать сертификаты в системах каталогов независимых компаний. Службы аутентификации
| | Рисунок 4. Роль SSPI в работе Authentication Services. | SSPI — это еще один прикладной интерфейс для доступа к службам аутентификации. Клиент-серверные приложения должны выполнять аутентификацию клиента на сервере, а иногда сервера на клиенте. SSPI предоставляет таким приложениям необходимый уровень абстракции, аналогичный функциям интерфейса CSP. На Рисунке 4 показано, как SSPI изолирует приложения от деталей протоколов безопасности сети, тем самым уменьшая объем прикладного кода, необходимого для поддержки различных протоколов аутентификации. Интерфейс обеспечивает выполнение аутентификации, базирующейся на протоколах с секретным или открытым ключами. Независимо от типа протокола, в основе этого процесса лежат хранящиеся в Active Directory защитные реквизиты. При этом нет никакой необходимости иметь отдельные учетные записи для NTLM и Kerberos. PKI-аутентификация выполняется Active Directory, связывающей элементы сертификата и соответствующий объект типа «пользователь». Приложения могут задействовать SSPI напрямую, а также либо через вызовы протокола RPC с аутентификацией (Authenticated RPC), либо через интерфейс распределенной модели DCOM. К числу других существенных преобразований в процедуре аутентификации относится замена NTLM, весьма уязвимого протокола аутентификации в версии NT 4.0, который работает с хранящимися в SAM хэш-кодами паролей. Тем не менее, в целях совместимости c NT, Windows 2000 продолжает его поддерживать. Так, при включении систем Windows 2000 в рабочие группы Windows NT, NTLM-аутентификация по-прежнему будет использовать хранящиеся в SAM защитные реквизиты. В свою очередь, при подключении системы Windows NT к серверу Windows 2000 в домене Active Directory, SAM функционировать не будет, а Windows 2000 выполнит проверку аутентичности пользователя с помощью хэшированных паролей NTLM, которые хранятся в его личном объекте AD. При обновлении версии NT и установке нового клиента AD для Windows 9x, можно избавиться от ненадежной NTLM-аутентификации, поскольку протоколом аутентификации для Windows 2000 по умолчанию является Kerberos. Этот протокол обеспечивает более высокий уровень защиты, чем NTLM. Кроме того, он представляет собой отраслевой стандарт, который позволит реализовать принцип однократной регистрации в системе (SSO). Наконец, Kerberos решает типичные для NTLM проблемы, такие, как низкая производительность и слабые возможности заимствования прав в многоуровневых серверных приложениях. |