Службы сертификации Windows 2000

Приложение A. Формирование цепочек сертификатов в Windows 2000

В данном приложении описывается формирование цепочек сертификатов в среде служб сертификации Windows 2000. Эта тема рассматривается в следующих подразделах:

Для получения дополнительной информации о цепочках сертификатов и их применении в сетях, использующих доверенный открытый ключ, обратитесь к официальным документам, связанным с инфраструктурой открытых ключей, а также к ссылке на учебник по основам криптографии: «Прикладная криптография: протоколы, алгоритмы, исходный код на С» («Applied Cryptography: Protocols, Algorithms, and Source Code in C»)(EN), приведенной ниже в разделе "Дополнительная информация".

Доверенные корневые сертификаты

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

Корневое хранилище сертификатов предприятия на основе службы каталогов Active Directory

Корневое хранилище сертификатов предприятия на основе службы каталогов Active Directory содержит доверенные корневые сертификаты. Как понятно из названия, это хранилище находится в Active Directory. Кроме этого существуют локальные корневые хранилища сертификатов предприятия на индивидуальных компьютерах. При установке администратором центра сертификации (CA), в Active Directory создается контейнер: корневое хранилище сертификатов предприятия (enterprise root certificate store), со следующим различимым именем13:

CN=,CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=com

CN=,CN=Центры сертификации,CN=Службы открытых ключей,CN=Службы,CN=Конфигурация,DC=,DC=com 

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

Для получения дополнительной информации об использовании DSStore для управления этими корневыми сертификатами на основе службы каталогов Active Directory, обратитесь к официальному документу «Решение проблем при развертывании инфраструктуры открытых ключей (PKI) Windows 2000 и входе в систему с помощью смарт-карт» (EN) (ссылка на этот документ дана в разделе "Дополнительная информация").

Проверка промежуточных сертификатов

Большинство моделей иерархической организации центров сертификации (СА) используют несколько уровней центров сертификации (СА). Использование многоуровневой иерархии упрощает администрирование и позволяет использовать конфигурацию с высокой безопасностью, где корневые центры сертификации (CA) закрыты в хранилище и используются только для подписи (или отзыва) подчиненных центров сертификации (СА). Часть процесса проверки цепочки включает в себя получение и анализ всех промежуточных сертификатов в цепочке сертификатов. В большинстве случаев, возможно, что клиент потерял все или часть сертификатов цепочки, используемой для проверки сертификата. В случае потери клиентом части или всей цепочки сертификатов центра сертификации (CA), используются AIA-расширения для определения и восстановления утерянных промежуточных сертификатов центра сертификации (CA). AIA-расширения используется функцией API CertGetCertificateChain(), которая вызывается приложениями для обработки цепочек сертификатов.

Центр сертификации (CA) Windows 2000 включают информацию AIA во все выданные сертификаты, включая промежуточные сертификаты. Обычно AIA использует ссылки LDAP, HTTP или прямые ссылки на файл для указания места, где постоянно находятся промежуточные сертификаты. Ниже приведен пример ldap:/// AIA: 

URL=ldap:///CN=W2K%20NTDEV%20Ent%20User%20CA,CN=AIA,CN=Public%2 0Key%20Services,CN=Services,CN=Configuration,DC=ntdev,DC=microsoft,DC=com ?cACertificate?base?objectclass=certificationAuthority

Проверка отзыва

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

Информация об отзыве хранится в CDP-расширении каждого сертификата. Как и в случае с AIA, CDP содержат ссылки, указывающие на то место, где находятся списки CRL, которые могут быть получены приложениями (с помощью функции CertGetCertificateChain() API). Эту информацию можно просмотреть через интерфейс пользователя сертификата, доступ к которому Вы можете получить, щелкнув дважды на сертификате в оснастке Сертификаты (Certificates). Ниже приведен пример ldap:/// CDP: 

URL=ldap:///CN=W2K%20NTDEV%20Machine%20CA%202,CN=W2KMACHINE CA,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=n tdev,DC=microsoft,DC=com?certificateRevocationList?base?objectclass=cRLDi stributionPoint

Примечание. В списке CRL указываются серийные номера отозванных сертификатов.

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

Существует и другой способ входа в систему (отличающийся от обычного входа с использованием паролей и процесса проверки подлинности Kerberos) – вход с помощью смарт-карт. Для входа с помощью смарт-карт используются сертификаты X.509 версии 3 (их описание представлено в разделе "Сертификаты X.509 версии 3" Приложения Б). Для того, чтобы можно было пользоваться входом с помощью смарт-карт, необходимо, чтобы и у контроллера домена, и у клиента были действующие сертификаты, выданные центрами сертификации (CA) предприятия Windows 2000. При этом оба сертификата должны удовлетворять следующим требованиям:

Наверх страницы

Приложение Б. Совместимость и стандарты

В данном приложении описаны стандарты, которых придерживаются службы сертификации Windows 2000, и конкретное применение этих стандартов. Также описывается, как и где эти стандарты используются службами сертификации. Эти темы раскрываются в следующих подразделах:

Международный союз электросвязи

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

Сертификаты X.509 версии 3

Большинство сертификатов, которые используются сегодня, основаны на стандарте X.509 ITU-T. При работе с сертификатами Windows 2000 придерживается этого стандарта.

Сертификат X.509 содержит в себе открытый ключ и информацию о человеке или объекте, которому этот сертификат был выдан, информацию о самом сертификате, а также дополнительную информацию о центре сертификации (СА), выдающего сертификат. Информация о владельце может включать название объекта (имя, получившего сертификат), открытый ключ, алгоритм открытого ключа и, в качестве опции, уникальный идентификатор владельца. Расширения стандарта позволяет добавлять для сертификата X.509 версии 3 информацию, связанную с идентификаторам ключа, информацию об использовании ключа, политику сертификата, дополнительные названия и атрибуты, ограничения пути сертификации и расширения для отзыва сертификатов, включая причины отзыва и разделение списка CRL, выполняемое при обновлении центра сертификации (CA).

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

Сообщество IETF

Сообщество IETF (Internet Engineering Task Force, IETF) является открытым международным сообществом проектировщиков сетей, операторов, производителей и исследователей, заинтересованных в развитии архитектуры сети Интернет. Сообщество IETF подразделяется на несколько рабочих групп в соответствии с тематическими разделами. Каждая рабочая группа разрабатывает стандарты для Интернет в соответствии с собственной тематикой. Каждый стандарт публикуется в документе RFC (RFC - Request for Comments) под определенным номером. Впоследствии стандарт может пересматриваться, в результате чего публикуется документ RFC под новым номером, а первоначальный документ считается устаревшим.

Рабочая группа IETF, нацеленная на разработку основ взаимодействия инфраструктуры открытых ключей, получила название PKIX. (Адрес веб-узла PKIX, представлен в разделе "Дополнительная информация"). Стандарты инфраструктуры открытых ключей для сети Интернет все еще разрабатываются. Не смотря на это, Microsoft разрабатывала службы сертификации, придерживаясь существующих стандартов, для обеспечения совместимости с инфраструктурой открытых ключей. В особенности Microsoft заботилась о том, чтобы службы сертификации Windows 2000 соответствовали требованиям документа RFC 2459 (описываемого далее).

Документ RFC 2459

Спецификация RFC 2459 является одним из стандартов, описывающих использование сертификата X.509 инфраструктуры открытых ключей в Интернет. Особенности RFC 2459 описываются в следующих подразделах:

Названия полей в сертификатах

В соответствии с RFC 2459 центры сертификации (CA) Windows 2000 заносят информацию в поля: Имя владельца (Subject name), Имя издателя (Issuer name), Альтернативное имя владельца (Alternate Subject Name) и Альтернативное имена издателей (Alternate Issuer names) в определенной кодировке. В RFC 2459 определены три типа кодировки для применения в сертификатах: PrintableString, BMPString и Unicode Transformation Format 8 (UTF-8). Использование кодировки TeletexString также разрешено, чтобы обеспечить поддержку клиентов, которые не соответствуют этому RFC. Каждый тип кодировки поддерживает различные наборы символов. Набор символов, используемый в сертификатах, определяет тип кодировки, которая должна использоваться.

По умолчанию используется кодировка PrintableString. Набор символов, которые поддерживаются кодировкой PrintableString, являются подмножеством символов ASCII. Подмножество представлено такими символами:

Если набор символов PrintableString не подходит для использовании, то применяется BMPString. BMPString использует набор символов Unicode, благодаря чему он может применяться для ввода символов из большинства международных наборов символов (в Unicode используется два байта для кодирования каждого символа, что позволяет создать 65,536 комбинаций символов). В том случае, если невозможно использовать набор символов PrintableString, и если известно, что при подаче заявки клиент не поддерживает Unicode, используется набор символов TeletexString. Платформа Windows 2000 в настоящее время не поддерживает кодировку UTF-8.

Некоторые продукты инфраструктуры открытых ключей не поддерживают Unicode в сертификатах. Отсутствие такой поддержки может привести к проблемам с совместимостью, которые сложно выявить. Большинство производителей высказали свои намерения поддерживать RFC 2459 в своей продукции. Чем больше продуктов будет обновлено и начнет поддерживать этот тип кодировки, тем меньше будет возникать проблем. В настоящее время перед использованием в сертификатах символов отсутствующих в PrintableString, важно проверять, чтобы все продукты инфраструктуры открытых ключей, использующие сертификаты центра сертификации (CA) Windows 2000, могли поддерживать кодировку Unicode, используемую в сертификатах.

Расширения сертификатов

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

В Таблице 2 представлены все расширения RFC 2459, которые используют в сертификатах при их создании центры сертификации (CA) Windows 2000. 

Таблица 2 – Используемые центром сертификации (СА) Windows 2000 расширения сертификатов RFC 2459

Расширения сертификатов и списков CRL

Ниже приводится описание некоторых из наиболее важных расширений сертификатов и списков CRL:

• Расширение Основные ограничения используется только для сертификатов центров сертификации (СА). Оно содержит логический флаг для указания сертификата центра сертификации (CA). Это расширение помечено как критическое в сертификате. В данный момент центры сертификации (CA) предприятия и изолированные центры сертификации (CA) Windows 2000 не поддерживают опцию длины пути в этом расширении.

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

  • Цифровая подпись 
    
  • Неотрекаемость 
    
  • Шифрование ключей 
    
  • Шифрование данных 
    
  • Согласование ключей 
    
  • Подписание сертификатов 
    
  • Подписание списка отзыва (CRL) 
  Расширение Использование ключа в сертификатах центра сертификации (CA) позволяет использовать цифровую подпись, подписание сертификата и списка отзыва (CRL). Дополнительно с подписанием сертификатов и списков отзыва (CRL) разрешено использование цифровой подписи, поскольку иногда центру сертификации (CA) требуется подписывать объекты, отличные от сертификатов и списков отзыва (CRL). Сертификаты конечных пользователей могут использоваться в таких случаях:
  • Только для подписания. Цифровую подпись разрешено использовать только в сертификатах, предназначенных для подписания.  
    
  • Только для обмена ключами. Для сертификатов, которые могут использоваться только для обмена ключами. При этом шифрование ключей и данных выполняется с помощью ключей RSA. Центры сертификации (CA) Windows 2000 не поддерживают открытые ключи Диффи-Хелмана. 
    
  • Как для подписания, так и для обмена ключами. Для сертификатов, которые используются как в операциях подписания, так и обмена ключами, разрешено использование цифровой подписи, шифрование ключей и данных. 
• Точки распространения списков отзыва (CDP - CRL distribution points). Расширение CDP указывает, где опубликован список CRL. В месте опубликования содержится состояние отзыва сертификата. Центры сертификации (CA) Windows 2000 используют URI-идентификаторы разных типов. По умолчанию центр сертификации (CA) предприятия использует URI-идентификаторы LDAP и HTTP. Изолированный центр сертификации (CA) использует URI-идентификаторы HTTP и FILE. Если необходимо указать дополнительные местонахождения, следует изменить список URI с помощью оснастки Центр сертификации (CA) консоли MMC.
Идентификатор ключа центра сертификации (CA) (Authority Key Identifier, AKI). Расширение AKI позволяет определить, какой ключ использовался для подписания сертификата. Это бывает очень полезно в случае, когда производилось обновление центра сертификации (CA), после чего у него может быть несколько ключей. Также центры сертификации (CA) Windows 2000 дополнительно могут включать в сертификаты информацию об издателе и серийном номере сертификата, позволяющую точно определить центр сертификации (CA), выдавший данный сертификат. Такая возможность может быть полезна для использования в высоконадежных приложениях.
• Доступ к сведениям о центрах сертификации (Authority Information Access, AIA). Расширение AIA позволяет определить местонахождение центра сертификации (CA), выдавшего сертификат. Большинство протоколов инфраструктуры открытых ключей включают полную цепочку сертификатов, однако это не гарантируется. Центры сертификации (CA) Windows 2000 используют URI-идентификаторы разных типов. По умолчанию центр сертификации (CA) предприятия использует URI-идентификаторы LDAP и HTTP. Изолированный центр сертификации (CA) использует URI-идентификаторы HTTP и FILE. Если необходимо указать дополнительные местонахождения, следует изменить список URI с помощью оснастки Центр сертификации (CA) консоли MMC.
• Альтернативное имя владельца. У сертификатов пользователей существует много типов названий для их идентификации. Центры сертификации (CA) предприятия в этом расширении могут использовать имена Kerberos и адрес электронной почты.

Особые расширения Windows 2000

Центры сертификации (CA) предприятия Windows 2000 включают в себя два особых расширения Microsoft. Эти расширения используются в задачах управления:

•	Шаблон сертификата. Это расширение используется центрами сертификации (СА) предприятия для определения того, какой шаблон использовался при создании сертификата.
•	Версия центра сертификации (CA). Версия центра сертификации (CA) показывает, сколько раз происходило обновления центра сертификации (CA) и сколькими ключами для подписи обладает центр сертификации (CA).

Год 2000 и сертификаты

Сертификаты и списки CRL содержат дату. Для сертификатов дата показывает срок действия. Для списков CRL дата показывает, когда список CRL был создан и когда ожидается следующее опубликование списка CRL. В рекомендации RFC 2459 определено, что для дат с 1949 по 2050 год будет использоваться двухразрядное обозначение года. Для дат после 2050 года будет применяться четырехразрядное обозначение. Службы сертификации Windows 2000 полностью соответствуют этим рекомендациям.

Международные наборы символов и DNS-имена

Сообщество IETF гарантирует, что во всех новых документах RFC включена поддержка международных наборов символов, разрешено использование UTF-8 или определены сроки, в которые должна быть обеспечена поддержка UTF-8 (в стандартах инфраструктуры открытых ключей определено, что полную поддержку UTF-8 должны обеспечить к 2003 году). Не все стадии этого процесса еще завершены. Нерешенным пока остается вопрос, каким образом использовать международный набор символов в URI-идентификаторах. На момент завершения разработки служб сертификации Windows 2000 не существовало еще стандарта, который бы описывал это. URI-идентификаторы указываются в сертификатах для определения того, где были опубликованы списки CRL и сертификаты центра сертификации (CA). URI-идентификаторы частично происходят от DNS-имени центра сертификации (CA). Поэтому центры сертификации (CA) Windows 2000 не поддерживают использование международного набора символов в DNS-имени сервера.

Стандарты шифрования с открытым ключом (PKCS)

Стандарты шифрования с открытым ключом (PKCS) представляют собой семейство стандартов для шифрования с открытым ключом, которые были разработаны RSA лабораториями при сотрудничестве с компаниями Apple, Digital, Lotus, Microsoft, MIT, Northern Telecom, Novell и Sun. Стандарты PKCS описывают синтаксис для многочисленных структур данных, используемых при шифровании с открытым ключом.

В частности, стандарты PKCS описывают синтаксис для:

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

Все стандарты различаются по своим номерам (с 1 по 15). Службы сертификации Windows 2000 используют следующие стандарты PKCS:

•	PKCS-1. В данном стандарте описывается создание цифровых подписей на основе алгоритма открытого ключа RSA совместно с алгоритмами хеширования. В нем также описывается, каким образом происходит шифрование симметричных ключей с помощью алгоритма RSA для обмена ключами. Этот стандарт также используется совместно со стандартом PKCS-7 для определения того, как создаются подписанные сообщения. В данном стандарте также описывается предоставление открытых ключей RSA и закрытых ключей. Службы сертификации Windows 2000 придерживаются документа RFC 2459, который ссылается на стандарт PKCS-1 в части создания подписи для сертификатов X.509 с помощью RSA и того, когда в них вносить открытые ключи RSA.
•	PKCS-7. В данном стандарте описывается, как ставится цифровая подпись и происходит шифрование любого блока данных. Также описывается возможность включения в сообщение дополнительной информации (например, времени подписания сообщения) и ее защиты той же цифровой подписью. А также описывается использование особой формы сообщения PKCS-7, известного как вырожденное сообщение (degenerate message), для транспортировки сертификатов и списков CRL. В стандарте PKCS-7 также определено, каким образом осуществляется шифрования данных с помощью алгоритма шифрования симметричными ключами (например, с помощью алгоритма шифрования содержимого (content-encryption algorithm)) и открытых ключей RSA для шифрования симметричных ключей (например, с помощью алгоритма обмена ключами (key-exchange algorithm)).
•	PKCS-10. Этот стандарт описывает принцип формирования сообщения для запроса сертификата. Запрос сертификата состоит из открытого ключа и дополнительного набора атрибутов. Например, ими могут быть: различимое имя или адрес электронной почты запрашивающей стороны, подписанные закрытым ключом, который соответствует указанному в запросе открытому ключу. Сообщение PKCS-10 является тем стандартом, которого придерживаются службы сертификации Windows 2000 для получения запроса сертификата. После получения запроса службы сертификации Windows 2000 обрабатывают его и либо отклоняют его, либо выдают сертификат X.509 для запросившей стороны. Информация, которую получит запросившая сторона, будет представлена либо в виде одного сертификата X.509, либо в виде сертификата и всей цепочки сертификатов вплоть до корневого сертификата. В данном случае информация будет представлена в форме вырожденного сообщения PKCS-7.

03/00

Дополнительная информация

Для получения самой последней информации об ОС Windows 2000 Server, обратитесь к веб-узлу http://www.microsoft.com/windows2000/ (EN).  


Для получения дополнительной информации ознакомьтесь с:

Учебником по основам криптографии: Шнейер, Брюс. «Прикладная криптография: протоколы, алгоритмы, источники на С» издание второе, издательство John Wiley & Sons, 1995 (Schneier, Bruce. Applied Cryptography: Protocols, Algorithms, and Source Code in C. 2nd Ed. John Wiley & Sons, 1995) (EN).

Официальным документом: «Решение проблем при развертывании инфраструктуры открытых ключей (PKI) Windows 2000 и входе в систему со смарт-картой» Troubleshooting Windows 2000 PKI Deployment and Smart Card Logon (EN).

Официальным документом: «Архитектура Active Directory» Active Directory Architecture (EN). 


1	В ОС Windows 2000 используется список управления доступом (ACL), в котором представлен перечень ограничений безопасности, применяемых к целому объекту, к набору свойств объекта или к отдельно взятому свойству объекта. У каждого объекта Active Directory есть два связанных с ним списка ACL: разграничительный список контроля доступа (DACL- discretionary access control list) и системный список управления доступом (System Access Control List, SACL). В списке DACL перечисляются учетные записи пользователей, группы и компьютеры, которым разрешен (или запрещен) доступ к объекту. Список DACL состоит из записей ACE (Access Control Entries, ACE), каждая из которых представляет собой разрешение или запрет пользователям, группам или компьютерам, перечисленных в списке DACL. Запись ACE содержит идентификатор безопасности (SID) с правами доступа, такими, как разрешение на чтение, запись или полный доступ. Список SACL отвечает за ведение аудита в журнале безопасности при соответствующих действиях над объектом (например, доступ к файлу) для пользователей или групп.
2	LDAP представляет собой протокол службы каталогов, который работает поверх TCP/IP. Он является простейшим протоколом доступа к каталогу, используемым для добавления, модификации и удаления хранящейся в Active Directory информации. Он также используется для запроса и получения данных из Active Directory. Клиенты Active Directory должны использовать протокол LDAP для получения информации из Active Directory или для сохранения информации в Active Directory. Active Directory использует этот протокол для взаимодействия с LDAP-совместимыми клиентскими приложениями. При наличии соответствующих разрешений Вы можете использовать любое LDAP-совместимое клиентское приложение для просмотра, подачи запроса, добавления, модификации или для удаления информации в Active Directory.
3	MIME представляет собой способ передачи через Интернет нетекстовых данных с помощью электронной почты. MIME кодирует нетекстовые данные с помощью символов ASCII и затем преобразовывает их на приемной стороне к исходному виду. S/MIME является расширением MIME, которое поддерживает безопасную почту. S/MIME позволяет отправителю подписать сообщение цифровой подписью, чтобы обеспечить возможность проверки происхождения сообщения и целостность данных. S/MIME позволяет передавать сообщение в зашифрованном виде для обеспечения конфиденциальности.
4	SSL (Secure Sockets Layer, SSL) - это открытый стандарт, предложенный Netscape Communications, для установки безопасного канала связи с целью предотвращения перехвата важной информации, например такой, как номера кредитных карт. Изначально он разрабатывался для обеспечения безопасности цифрового обмена финансовыми данными через сеть Интернет, но теперь он может применяться и в других Интернет-службах.
5	Протокол TLS (Transport Layer Security, TLS) является стандартным протоколом, используемым для обеспечения защищенных веб-соединений в сети Интернет и интрасетях. Он позволяет клиентам осуществлять проверку подлинности серверов или серверам выполнять проверку подлинности клиентов (вторая возможность является опцией). В целях конфиденциальности он также обеспечивает безопасность канала путем шифрования.
6	Файловая система EFS является новой возможностью в Windows 2000, которая защищает секретные данные, хранящиеся в файлах на NTFS-разделах. Для обеспечения конфиденциальности этих файлов EFS использует шифрование с симметричным ключом совместно с  технологией открытых ключей.
7	Центр распределения ключей Kerberos (Key Distribution Center, KDC) является сетевой службой, поставляющей билеты сессии и временные ключи сессии, используемые в протоколе аутентификации Kerberos. В ОС Windows 2000 KDC работает в качестве привилегированного процесса на всех контроллерах домена. KDC использует Active Directory для управления секретной учетной информацией, такой как пароли учетных записей.
8	Контекст безопасности обращается к атрибутам безопасности или правилам, действующим в данный момент. Например, правила, определяющие, какие действия пользователь может совершать над защищенным объектом, указаны информацией безопасности в маркере доступа пользователя и в дескрипторе безопасности объекта. Вместе маркер доступа и дескриптор безопасности формируют контекст безопасности для действий пользователя над объектом.
9	Для получения общих сведений о репликации Active Directory обратитесь к официальному документу "Архитектура Active Directory" ("Active Directory Architecture") (EN), ссылка на который приведена выше в данном разделе. Для получения подробной информации обратитесь к документу "Репликация Active Directory" ("Active Directory Replication") (EN) в сети Интернет.
10	URI представляет собой строку символов, используемых для указания ресурса (например, файла) по его типу и местонахождению из любой точки сети Интернет. URI включают в себя единое название ресурса (Uniform Resource Names, URN) и единый указатель местоположения ресурса (Uniform Resource Locators, URL).
11	SGC обычно доступны для сертифицированных банковских и финансовых учреждений во всем мире. Исключением являются банки и финансовые институты, расположенные в странах, в отношении которых действует эмбарго США (список эмбарго включает в себя Кубу, Иран, Ирак, Ливию, Северную Корею, Сирию и Судан), а также несколько других направлений (в списке которых присутствует Россия и Китайская народная республика).
12	Безопасный канал (schannel - Secure Channel) пакета безопасности поддерживает протоколы на основе открытых ключей SSL (Secure Sockets Layer, SSL) версии 2 и 3, а также TLS (Transport Layer Security, TLS). Протокол TLS является стандартом IETF для SSL и для протокола PCT (PCT- Private Communication Technology). Schannel определяет, какой из этих протоколов необхоимо использовать при осуществлении связи с другим компьютером. Протоколы SSL, TLS и PCT используют сертификаты для подтверждения подлинности. IIS 5.0 поставляется международным клиентам с файлом SCHANNEL.DLL, поддерживающим стандартные 40-битные схемы шифрования. Кроме этого, если сервер IIS получает от центра сертификации (CA) сертификат SGC, то SCHANNEL.DLL поддерживает создание 128-битного канала, с помощью ключей сертификата SGC.
13	Каждый объект Active Directory имеет различаемое имя LDAP (иногда используется аббревиатура DN - distinguished name). Для получения информации о том, как Active Directory обрабатывает DN-имена LDAP, обратитесь к официальному документу "Архитектура Active Directory" ("Active Directory Architecture") (EN), ссылка на который дана выше в данном разделе.




Обсуждение статьи на форуме