Переведено: 16 июля 2006 г.
Службы сертификации Microsoft® Windows® 2000 предоставляют потребителям встроенную инфраструктуру открытых ключей (Public Key Infrastructure, PKI), позволяющую осуществлять безопасный обмен информацией через сеть Интернет, внешние сети, а также интрасети. Службы сертификации осуществляют проверку и подтверждают подлинность каждой из сторон, участвующих в обмене электронными данными. Кроме этого они позволяют пользователям домена входить в него с помощью смарт-карт, обеспечивая тем самым дополнительную безопасность. В данной статье описываются службы сертификации Windows 2000 и развертывание инфраструктуры открытых ключей (PKI) в сети Windows 2000.
На этой странице:
Введение
Одним из важных требований для современного предприятия является защита своих внутренних коммуникаций. Информация, передаваемая по внешним каналам связи, должна быть еще более защищенной, чем та, что передается по внутренним каналам, поскольку она может быть еще более секретной
Улучшение связи между сотрудниками, поставщиками и потребителями позволяет организациям сокращать издержки, быстрее выводить продукцию на рынок и устанавливать более надежные и крепкие отношения с потребителями. Использование этих новых возможностей должно осуществляться безопасно особенно в такой потенциально враждебной среде, как Интернет, где третьи лица могут попытаться получить доступ к информации, передаваемой по этой сети, выдавая себя за других, а также попытаться помешать Вашему бизнесу. Противодействовать этим потенциальным угрозам призваны следующие три типа служб безопасности:
| • | Неотрекаемости. Служба (подтверждение подлинности), которая позволяет получателю сообщения удостовериться в подлинности отправителя сообщения. |
| • | Конфиденциальности. Служба, гарантирующая то, что сообщение будет прочитано только теми, кому оно предназначалось. |
| • | Целостности. Служба, позволяющая получателю удостовериться, что сообщение не подвергалось изменениям после того, как было отослано отправителем. |
Службы сертификации Microsoft® Windows® 2000 позволяют Вам создать центр сертификации (CA) для управления инфраструктурой открытых ключей (PKI) Windows 2000. Центр сертификации (CA) выдает сертификаты, которые служат для подтверждения подлинности, а также подтверждения прочих атрибутов владельца сертификата другим сущностям. Инфраструктура открытых ключей (PKI) обращается к системе цифровых сертификатов (также называемых сертификатами открытого ключа) и к центру сертификации, который выполняет проверку подлинности каждой из сторон, участвующей в процессе обмена электронными данными. Тем самым она позволяет осуществлять безопасный обмен информацией в открытых сетях, таких как Интернет, других внешних сетях и интрасетях.
В первой половине этого документа описываются службы сертификации Windows 2000. Во второй описывается создание иерархии центров сертификации (CA) и развертывание служб сертификации в сети Windows 2000. Эта статья рассчитана на системных архитекторов, планирующих внедрение служб сертификации.
В Приложении A приводится дополнительная информация о создании цепочек сертификатов служб сертификации Windows 2000. В Приложении Б описана совместимость и стандарты, которых придерживаются службы сертификации Windows 2000.
Для тех, кто не знаком с принципами криптографии и работой инфраструктуры открытых ключей, рекомендуется обратиться к официальному документу «Основы криптографии и инфраструктуры открытых ключей (PKI)» (EN) ("Cryptography and PKI Basics") в сети Интернет. Для получения дополнительной информации о выявлении и устранении проблем, связанных со службами сертификации Windows 2000, включая рекомендации по оптимизации развертывания инфраструктуры открытых ключей (PKI), обратитесь к официальному документу "Решение проблем при развертывании инфраструктуры открытых ключей (PKI) Windows 2000 и входе в систему со смарт-картой" (EN) (ссылка на данный документ дана в разделе «Дополнительная информация»).
Службы сертификации
Компонент Службы сертификации Windows 2000 представляет собой настраиваемые службы для управления сертификатами. Службы сертификации Windows 2000 можно использовать для создания центра сертификации (CA), в задачи которого входит получение запросов на сертификаты, проверка как самой информации в запросе, так и проверка подлинности того, кто подает запрос, а также выдача и отзыв сертификатов, и опубликование списка отзыва сертификатов CRL (Certificate Revocation List, CRL). При использовании служб сертификации Windows 2000 управление сертификатами осуществляется с помощью оснастки Сертификаты (Certificates).
Обзор служб сертификации Windows 2000
Службы сертификации Windows 2000 позволяют:
| • | Использовать оснастки. Подавайте заявки пользователей на сертификаты центру сертификации (CA), используя оснастку Веб (Web) или Сертификаты (Certificates), в зависимости от политики, используемой центром сертификации (CA). |
| • | Использовать шаблоны. Используйте шаблоны сертификата для того, чтобы упростить выбор запрашивающей стороне, когда она подает запрос на сертификат, в зависимости от политики, используемой центром сертификации (CA) . |
| • | Публиковать в Active Directory. Используйте все преимущества службы каталогов Windows 2000 для публикации доверенных корневых сертификатов, выданных сертификатов и списков CRL (в лесу Windows 2000 публикация - это создание в каталоге объекта, который либо содержит информацию, которая должна быть доступна, либо ссылается на нее). |
| • | Использовать смарт-карты. Пользуйтесь возможностью входа в домен на базе ОС Windows с помощью смарт-карт. |
Вы сможете ознакомиться со следующими возможностями служб сертификации Windows 2000 в подразделах, приведенных ниже:
| • | Политики центра сертификации (CA) Windows 2000 |
| • | Центр сертификации (CA) предприятия |
| • | Изолированный центр сертификации (CA) |
| • | Списки отзыва сертификата |
| • | Местоположение информации центра сертификации (CA) при ее публикации в Active Directory |
| • | Подача заявок через веб-страницы |
| • | Распространение сертификатов центра сертификации (CA) |
| • | Обновление центра сертификации (CA) |
Политики центра сертификации Windows 2000
При установке служб сертификации Windows 2000, Вы должны сделать выбор, какую из двух возможных вариантов политик центра сертификации Вы будете использовать. Каждая из политик обладает разными характеристиками при обработке запросов сертификатов, выдаче сертификатов, отзыве сертификатов и публикации списков CRL. (Политики центра сертификации (CA) никак не связаны с групповыми политиками Windows 2000. Тем не менее, групповая политика играет роль в инфраструктуре открытых ключей (PKI) Windows 2000. Для получения информации об этом, обратитесь к разделу "Распространение сертификатов центра сертификации (CA)").
Этими двумя политиками служб сертификации центра сертификации ОС Windows 2000 являются: политика предприятия и изолированная политика. Во время установки служб сертификации Вам необходимо выбрать политику, которую будет использовать центр сертификации (CA). В качестве альтернативы Вы можете установить изолированный центр сертификации (CA) и затем заменить изолированную политику на свою собственную политику.
Политика предприятия и изолированная политика отличаются способом взаимодействия с Active Directory, выполнением проверки подлинности, а также тем, используют ли они шаблоны сертификатов:
| • | Политика предприятия. Центр сертификации (CA), использующий политику предприятия, далее будем называть центром сертификации (CA) предприятия: |
| • | Изолированная политика. Центр сертификации (CA), использующий изолированную политику, будем называть изолированным центром сертификации (CA): |
В сети Windows 2000, установка как центра сертификации (CA) предприятия, так и изолированного центра сертификации (CA) администратором корневого домена или администратором предприятия приводит к созданию объектов CA и CRL в Active Directory. Поэтому в обоих случаях большая часть процесса построения цепочек сертификатов и проверки отзыва сертификатов осуществляется с помощью LDAP-запросов 2 к Active Directory.
Кроме этого, установка корневых центров сертификации (CA) (как изолированного, так и предприятия) администратором корневого домена или администратором предприятия, автоматически приводит к добавлению корневого сертификата в Active Directory, а все клиенты Windows 2000 в сети предприятия автоматически получают копии сертификатов этих центров сертификации (CA).
Как центр сертификации (CA) предприятия, так и изолированный центр сертификации (CA) могут выпускать сертификаты, предназначенные для цифровых подписей, безопасной электронной почты, использующей S/MIME3, и для прохождения проверки подлинности на безопасных веб-серверах с помощью SSL4 (Secure Sockets Layer, SSL) или TLS5 (Transport Layer Security, TLS). Кроме этого центры сертификации (CA) предприятия могут выпускать сертификаты для входа в домен Windows 2000 с помощью смарт-карт. Центр сертификации (CA) предприятия может также выпускать сертификаты, которые могут использоваться для проверки подлинности пользователя на сервере Microsoft IIS (Internet Information Services, IIS) в лесу.
Примечание. Все сертификаты для входа со смарт-картой и сертификаты агента подачи заявок должны быть выпущены центром сертификации (CA) предприятия. Это требование должно выполняться из-за дополнительной безопасности, обеспечиваемой центрами сертификации при проверке подлинности стороны, запрашивающей сертификаты. Если Вам необходимо использовать такую функциональность в Вашем предприятии, то Вам следует установить центр сертификации (CA) предприятия в Вашей иерархии центров сертификации инфраструктуры открытых ключей. Центры сертификации (CA) предприятия и изолированные центры сертификации (CA) описываются более детально в следующих двух подразделах.
Центр сертификации предприятия
Для установки центра сертификации (CA) предприятия необходимо выбрать политику центра сертификации предприятия во время установки служб сертификации Windows 2000. Центр сертификации предприятия Windows 2000 имеет самую простую административную модель с самыми низкими расходами в пересчете на один сертификат. Для минимизации административной нагрузки, связанной с выпуском сертификатов, и обеспечения встроенной единой точки управления, центр сертификации (CA) предприятия работает совместно со следующими двумя службами Windows 2000:
| • | Active Directory. Центр сертификации (CA) предприятия использует Active Directory в качестве регистрационной базы данных. Создание пользователя в домене Windows 2000 автоматически приведет к регистрации пользователя во всех центрах сертификации (CA) предприятия в лесу. Это позволит пользователям, обладающим соответствующими правами, запрашивать сертификаты у любого центра сертификации (CA) предприятия. Центры сертификации (CA) предприятия используют информацию, опубликованную в Active Directory при заполнении данных в сертификате. |
| • | Модель безопасности Windows 2000. Центр сертификации (CA) предприятия использует службы безопасности Windows 2000 для идентификации пользователя запрашивающего сертификат и для проверки его полномочий, основанной на его членстве в группах Windows 2000. |
В следующих трех разделах будут описаны такие особенности центров сертификации (CA) предприятия:
| • | Шаблоны сертификатов центра сертификации (CA) предприятия |
| • | Подача заявки центру сертификации (CA) предприятия |
| • | Модель безопасности центра сертификации (CA) |
Шаблоны сертификатов центра сертификации предприятия
Центры сертификации (CA) предприятия Windows 2000 используют шаблоны сертификатов для контроля содержимого выдаваемых сертификатов. Эти шаблоны определяют информацию, записываемую в сертификат, расширения сертификатов и происхождение информации. Они также упрощают использование и управление центром сертификации, скрывая технические детали содержимого сертификата. Windows 2000 поставляется с широким набором шаблонов, которые опубликованы в Active Directory и являются глобальными для всего леса Windows 2000.
Существует два типа шаблонов:
| • | Специализированные шаблоны, которые создают сертификаты, использовать которые можно только для одного приложения. Например, шаблон сертификата входа со смарт-картой (Smart Card Logon Certificate Template), который используется специально для входа со смарт-картой. В качестве другого примера можно привести шаблон для файловой системы EFS (Encrypting File System, EFS)6 или шаблон для S/MIME. |
| • | Многоцелевые шаблоны. Они создают сертификаты, предназначенные для использования в нескольких приложений, например, SSL, S/MIME и EFS. Существуют шаблоны и для компьютеров и для пользователей, для использования в SSL-серверах или в центрах распространения ключей KDC (Key Distribution Centers, KDC)7. |
Подача заявок центру сертификации (CA) предприятия
Ниже описывается процесс подачи заявок пользователей и компьютеров центру сертификации (CA) предприятия:
| • | Проверка подлинности пользователя доменом. Центр сертификации (CA) предприятия использует проверку подлинности домена для идентификации пользователя, т.е. он использует персональный маркер доступа пользователя Windows 2000 для подтверждения его подлинности. Это означает, что если пользователь вошел в домен Windows 2000 и запросил сертификат у центра сертификации (CA) предприятия, то Active Directory выполнит идентификацию пользователя для центра сертификации (CA) предприятия. Все запросы сертификатов обрабатываются центром сертификации (CA) от имени пользователя для получения правильного контекста безопасности8. Это позволяет модулю политики (политики центра сертификации) назначать права доступа пользователя к шаблону и к центру сертификации (CA). Модуль политики также может найти пользователя в Active Directory. |
| • | Автоматическая подача заявки компьютером. Центр сертификации (CA) предприятия использует проверку подлинности домена для идентификации компьютера, т.е. он использует системный маркер доступа компьютера Windows 2000 в качестве доказательства его подлинности. Автоматическая подача заявки компьютером, активируемая с помощью службы групповой политики Windows 2000, является механизмом, с помощью которого компьютеры автоматически получают сертификаты. Вы используете групповую политику для определения шаблонов, которые можно применять к компьютеру. В начале загрузки список сертификатов (расположенный в Моем (MY) хранилище сертификатов локального компьютера) и доступный компьютеру сравнивается с шаблонами, примененными групповой политикой. Если компьютер не имеет сертификат для каждого соответствующего шаблона, то компьютер будет подавать заявки центру сертификации (CA) предприятия в лесу для получения сертификата этого шаблона. |
Модель безопасности центра сертификации (CA) предприятия
Глобальная в пределах леса модель безопасности центра сертификации (CA) предприятия, управляется списками DACL объектов Active Directory. Списки DACL управляют следующими аспектами:
| • | Кто в предприятии может подавать заявку на сертификат. |
| • | На какие типы сертификатов они могут подавать заявку. |
| • | В какой центр сертификации (CA) предприятия они могут подавать запрос на сертификат. |
Центры сертификации содержат списки DACL для определения пользователей, которым разрешено подавать заявки. В шаблонах сертификатов в Active Directory имеется список DACL, в котором указаны пользователи, которые могут подавать заявку на сертификаты с помощью шаблонов. В центрах сертификации (CA) предприятия также имеется список шаблонов, которые они могут использовать для обработки запросов.
Для того, чтобы пользователь мог подать заявку на сертификат в центр сертификации (CA) предприятия, должны выполниться следующие три условия:
| • | Пользователь должен состоять в группе, у которой есть права на использование шаблона, опубликованного в Active Directory. |
| • | Пользователь должен состоять в группе, у которой есть права на использование центра сертификации (CA) предприятия. |
| • | Центр сертификации (CA) предприятия должен быть настроен на выдачу шаблона, запрашиваемого пользователем. |
В центре сертификации (CA) предприятия также имеется список DACL, который используется для управления администрированием центра сертификации. Административные задачи по управлению центром сертификации (CA) предприятия включают в себя:
| • | Отзыв сертификатов. |
| • | Изменение периода публикации списка CRL, заданного по умолчанию. |
| • | Изменение списка точек распространения списков отзыва (списка CDP - CRL Distribution Point), опубликованного в сертификатах центром сертификации (CA) предприятия. CDP являются элементами каталога или другими источниками распространения для списков CRL. |
| • | Изменение списка доступа к информации о размещении центров сертификации (списка AIA - Authority Information Acces) опубликованного в сертификате центром сертификации (CA) предприятия. Адреса AIA представляют собой унифицированные указатели местоположения ресурса (uniform resource locators, URL), которые однозначно определяют местонахождение в Интернет. В сертификатах, которые выдает центр сертификации (CA), адреса AIA предоставляют проверяющей стороне информацию о том, где можно получить сертификат центра сертификации (CA). Адреса AIA могут быть URL следующих типов: HTTP, FTP, LDAP или ссылкой на файл. |
| • | Влючение или выключение публикации сертификатов в Active Directory. |
| • | Обновление центра сертификации (CA) предприятия. |
| • | Изменение списков DACL в центре сертификации (CA) предприятия. |
| • | Изменение списка шаблонов сертификатов, используемых центром сертификации (CA) предприятия. |
Изолированный центр сертификации
Для установки изолированного центра сертификации (CA) необходимо выбрать политику изолированного центра сертификации (CA) во время установки службы сертификации Windows 2000. Изолированный центр сертификации (CA) Windows 2000, как понятно из его названия, может работать независимо от Active Directory и других компонентов леса Windows 2000. Вы можете установить изолированный центр сертификации (CA) на сервер, работающий под управлением ОС Windows 2000 в домене Windows NT® 4.0 точно так же, как и в лесу Windows 2000.
При запросе сертификата сторона, запрашивающая сертификат у изолированного центра сертификации, должна указать полную идентифицирующую информацию о себе и о типе сертификата, который она запрашивает (в отличие от запроса к центру сертификации (CA) предприятия, в случае которого информация о пользователе уже присутствует в Active Directory а тип сертификата описывается шаблоном сертификата). По умолчанию, все запросы, отсылаемые к изолированному центру сертификации, переводятся в состояние ожидания до тех пор, пока администратор изолированного центра сертификации (с помощью оснастки Центр сертификации (CA)) не выполнит проверку подлинности запрашивающей стороны и не одобрит запрос. Кроме этого, администратор (или пользователь) должны явно перенести сертификат изолированного центра сертификации в корневое хранилище для того, чтобы пользователи домена могли ему доверять.
Изолированный центр сертификации не может выдавать сертификаты для входа в домен Windows 2000 с помощью смарт-карт. Тем не менее, другие типы сертификатов могут выпускаться и храниться на смарт-карте.
Примечание. Изолированный центр сертификации (CA) не всегда работает независимо от Active Directory. Если администратор корневого домена устанавливает изолированный центр сертификации (CA) в лесу Windows 2000, то изолированный центр сертификации (CA) будет иметь возможность пользоваться всеми преимуществами Active Directory и публикации объектов CA и CRL.
Списки отзыва сертификатов
Список отзыва сертификатов (список CRL) обслуживается центром сертификации (CA). В нем хранятся серийные номера отозванных сертификатов. Центры сертификации (CA) предприятия Windows 2000 публикуют списки CRL в Active Directory. Изолированный центр сертификации (CA) будет публиковать списки CRL в Active Directory только в том случае, если он был установлен администратором предприятия. Вы можете изменить расписание публикации списков CRL (минимальный период публикации – один час).
Поскольку репликация9 Active Directory занимает некоторое время, то список CRL действуют дольше, чем интервал публикации. Срок действия списка CRL на 10 процентов больше, чем длительность периода публикации, и может максимально достигать 12 часов. Если заданного по умолчанию для репликации каталога времени недостаточно, то, редактируя реестр, Вы можете указать время, на которое увеличится срок действия списка CRL. Центр сертификации (CA) предприятия вставляет единый идентификатор ресурса (URI)10 в расширение сертификата, известное также, как расширение CDP. Также можно публиковать списки CRL в других местах с помощью HTTP, FTP или сслыки на файл.
Как только произойдет обновление Active Directory после новой публикации списка CRL, путем репликации изменения будут внесены во все контроллеры домена в лесу. Время, затрачиваемое на репликацию, зависит от пропускной способности сети и расписания репликации:
| • | Внутрисайтовая репликация. Наличие одного сайта Windows 2000 и LAN-соединения между всеми контроллерами домена позволяют провести внутрисайтовую репликацию в течение нескольких минут. |
| • | Межсайтовая репликация. Наличие двух и более сайтов Windows 2000, использующих WAN-соединение, приводит к тому, что репликация между ними занимает больше времени, чем в пределах одного сайта. В зависимости от имеющейся топологии межсайтовой репликации возможна ситуация, когда обновление должно производиться через несколько сайтов, что приводит к дополнительным задержкам. Чтобы компенсировать эти задержки срок действия списка CRL увеличивается. Как было сказано выше, для выполнения репликации, к сроку действия списка CRL по умолчанию добавляется 10 процентов времени от длительности периода публикации (и может максимально доходить до 12 часов). Например, для центра сертификации (CA) период публикации указан в 24 часа, т.е. каждые 24 часа он будет публиковать новые списки CRL. С учетом добавленного времени реальное значение будет составлять приблизительно 26.4 часа (сюда также включено время на синхронизацию). |
Местоположение информации центра сертификации (CA) при ее публикации в Active Directory
Различная информация инфраструктуры открытых ключей (PKI) должна быть широко доступна. В Windows 2000, эта информация публикуется в Active Directory. Опубликованные данные содержат информацию о:
| • | Сертификатах пользователей - для приложений, использующих асинхронный обмен данными таких, как S/MIME и EFS. |
| • | Сертификатах центра сертификации (CA) - для построения цепочки сертификатов к доверенному корневому центру. |
| • | Списках CRL - для возможности проверки статуса (смотрите также предыдущий подраздел). |
В Active Directory центр сертификации (CA) предприятия может публиковать сертификаты для пользователей, сертификаты для центров сертификации (CA) и списки CRL.
Для особых типов данных в Active Directory есть три раздела каталогов: данные домена (domain data directory partition), данные конфигурации (configuration data directory partition), данные схемы (schema data directory partition). Раздел каталога данные домена (domain data directory partition) содержит все объекты в каталоге для данного домена. В каждом домене данные домена реплицируются на каждый контроллер этого домена (репликация на контроллеры других доменов не происходит). Раздел каталога данные конфигурации (configuration data directory partition) содержит топологию репликации и связанные метаданные. Приложения, использующие в своей работе Active Directory, хранят информацию в этом разделе. Эти данные являются общими для всех доменов в доменном дереве или леса. Данные конфигурации реплицируются на все контроллеры домена в лесу. Раздел каталога данные схемы (schema data directory partition) содержит все типы объектов (и их атрибуты), которые могут создаваться в Active Directory. Эти данные являются общими для всех доменов в доменном дереве или леса. Данные схемы реплицируются на все контроллеры домена в лесу.
Глобальный каталог ОС Windows 2000, играет важную роль во время входа пользователей в систему (для домена, работающего только в основном режиме) и в создании запросов. Он является базой данных, которая хранится на одном или нескольких контроллерах домена. В том случае, если контроллер домена также является и глобальным каталогом, то кроме трех разделов каталога: данных домена, данных конфигурации, данных схемы, он также хранит и реплицирует четвертую категорию информацию – частичную реплику (partial replica) раздела каталога данных домена для всех доменов. Эта частичная реплика содержит подмножество свойств всех объектов для всех доменов в лесу, которые реплицируются на все контроллеры домена в лесу.
Сертификаты пользователей публикуются в объекте пользователя (User) в разделе каталога данные домена (domain data directory partition). Сертификаты пользователя также реплицируются в глобальный каталог Windows 2000 для обеспечения доступа к сертификату через лес.
Сертификаты центра сертификации (CA) опубликованы в объекте CertificationAuthority, а списки CRL - в объекте CRLDistributionPoint в Active Directory. Чтобы гарантировать возможность построения цепочки центров сертификации (СА) и доступности информации о состоянии отзыва независимо от структуры домена, эти объекты публикуются в разделе домена данные конфигурации (configuration data directory partition), содержимое которого реплицировано во всем лесу. Точки CDP и указатели AIA в сертификатах организованы таким образом, что они работают независимо от того, к какому домену принадлежит контроллер домена в лесу.
Подача заявок через веб-страницы
В состав центров сертификации (CA) Windows 2000 входит веб-клиент, являющийся дополнительным компонентом. Он по умолчанию устанавливается в каждый центр сертификации (СА). Вы также можете установить его на любой отдельный сервер Windows 2000 в лесу, на котором работает IIS.
Каждый тип центра сертификации (CA) Windows 2000 имеет отдельный веб-клиент. Веб-клиенты позволяют центрам сертификации (СА) Windows 2000 поддерживать конечных пользователей, использующих различные веб-обозреватели и работающих в разных ОС, позволяя им подавать заявки в центр сертификации (CA) Windows 2000. Это означает, что Вы можете развернуть службу подачи заявок через веб-страницы для поддержки других систем (не Windows 2000) отдельно от центра сертификации (CA). У центра сертификации (CA) может быть любое количество веб-клиентов, тем самым Вы можете, например, использовать один центр сертификации (CA) для поддержки нескольких языков, т.е. можете установить французский или китайский веб-клиент и использовать для них одну службу сертификации.
Распространение сертификатов центра сертификации (CA)
В сети Windows 2000, существуют следующие три механизма распространения сертификатов центра сертификации (CA) на компьютеры, работающие под управлением ОС Windows 2000:
| • | Корневое хранилище сертификатов предприятия. Корневое хранилище сертификатов предприятия находится в Active Directory. Когда администратор домена устанавливает корневой центр сертификации (CA) Windows 2000 (как предприятия, так и изолированный) в лесу, то в процессе установки обновляется корневое хранилище предприятия, путем внесения новых сертификатов. Кроме этого, администраторы могут использовать средство DSStore из комплекта Windows 2000 Resource Kit для добавления сертификатов изолированного центра сертификации (CA) в хранилище сертификатов. Когда компьютер предприятия загружается, содержимое корневого хранилища сертификатов предприятия копируется на него и затем обновляется каждые восемь часов. С помощью этого простого механизма осуществляется распространение сертификатов на все компьютеры в лесу. |
| • | Групповая политика Windows 2000. Вы можете также использовать возможности групповой политики Windows 2000 для распространения любых сертификатов центра сертификации (CA) в группе компьютеров в пределах леса. В случае использования внешнего центра сертификации (CA), которому должна доверять лишь определенная группа пользователей или компьютеров в лесу, но не все предприятие в целом (например, такое возможно при использовании приложений электронной коммерции), то для этих целей к таким компьютерам Вы можете применить соответствующие настройки групповой политики. |
| • | Распространение сертификатов клиентам нижних уровней. Когда клиенты нижних уровней подают заявку центру сертификации (CA) Windows 2000 с помощью веб-клиента, то в ответ на запрос сертификата от центра сертификации (CA) клиенту будет загружена полная цепочка сертификатов (включая корневые сертификаты). |
Обновление центра сертификации (CA)
Все сертификаты имеют ограниченный срок действия. Конечные объекты (пользователи) могут просто запросить другой сертификат. Однако, для центров сертификации (СА) проблема является более серьезной, поскольку другие стороны используют в своей работе их сертификаты, т.е. центры сертификации (CA) являются частью цепочки сертификатов. Кроме того, срок действия центра сертификации (CA) должен быть больше, чем срок действия сертификата, который выдает этот центр сертификации (CA). Поэтому важно, чтобы центр сертификации (CA) был способен обновлять свои сертификаты для того, чтобы они были действительными. В следующих трех подразделах описываются следующие аспекты относительно обновления центра сертификации (CA), которые необходимо Вам рассмотреть:
| • | Срок действия центра сертификации и выдаваемых им сертификатов |
| • | Сертификаты корневого центра сертификации (CA) |
| • | Центры сертификации (CA), выдающие сертификаты конечным пользователям и компьютерам |
Срок действия центра сертификации и выдаваемых им сертификатов
Центры сертификации (CA) Windows 2000 при выпуске сертификатов придерживаются определенного правила. В соответствии с этим правилом, когда центр сертификации (CA) выпускает сертификат, он гарантирует, что срок действия нового сертификата не будет превышать срок действия собственного сертификата центра сертификации (CA). Если собственный сертификат центра сертификации (CA) действителен в течение 6 месяцев, то максимальный срок действия нового сертификата, который выпустит этот центр сертификации (CA) также будет равен 6 месяцам. Это гарантирует то, что когда срок действия сертификата центра сертификации (CA) истечет, сроки действия всех сертификатов, которые выпустил данный центр сертификации (CA) также истекут. В случае, если необходимо, чтобы центр сертификации (CA) выдавал сертификаты сроком на 1 год, а его собственный сертификат при этом действителен только на 1 год или менее одного года, то необходимо будет каждый раз обновлять центр сертификации (CA), для того, чтобы он мог выпускать новые сертификаты сроком на 1 год.
Сертификаты корневого центра сертификации (CA)
Корневой центр сертификации (CA) (который, вероятно, является автономным центром сертификации (СА)) должен иметь надежный сертификат. Из-за высокой стоимости распространения, может возникнуть желание просто создать очень большой ключ и установить очень большой срок действия сертификата. Слабая сторона этого подхода в том, что чем дольше сертификат является действительным, тем больше неуверенность в его надежности, что обуславливается постоянными развитиями в технологиях, особенно в криптоанализе.
Существует альтернатива созданию очень большого ключа и выпуска сертификата с этим ключом с длительным сроком действия. Если у корневого центра сертификации (CA) есть два сертификата с одинаковыми именем владельца и ключом, но с различными сроками действия, то приложения могут использовать любой из них для проверки сертификатов, выпущенных центром сертификации (CA). Это упрощает требования к распространению сертификатов. Если центр сертификации (CA) для своего обновления использует тот же ключ, что и раньше, то нет необходимости всем зависящим сторонам предварительно получать новый сертификат для проверки сертификатов подписанных этим новым сертификатом. Распространение нового корневого сертификата может происходить в любое время после того, как сертификат был создан и особенно после того, как новый корневой сертификат использовался для выпуска новых сертификатов.
Работа администратора успроститься, если ему не придется постоянно гадать о сроках действия сертификатов. Этого можно добиться путем создания ключа большой длины, который, к тому же, будет иметь длительный срок действия, а затем созданием сертификатов, у которых срок действия будет меньше чем срок действия ключа. Например, создайте RSA ключ длиной 4096-бит (с приблизительным сроком действия 20 лет) и используйте его для создания сертификатов, срок действия которых будет составлять 5 лет. Сертификат может обновляться тем же ключом каждые 4 года, при этом срок действия его будет равен тем же 5 годам. Ключ может использоваться в течение 20 лет, но при каждом обновлении сертификата администратору придется определять, можно ли будет текущий ключ безопасно использовать в течение следующих пяти лет.
Центры сертификации (CA), выдающие сертификаты конечным пользователям и компьютерам
Центры сертификации (CA), выдающие сертификаты конечным пользователям и компьютерам, сталкиваются с задачами, отличными от тех, что были рассмотрены ранее для центров сертификации (CA), выдающих сертификаты для корневого центра сертификации (CA). Подход к обновлению также отличается. Эти центры сертификации (CA) обрабатывают запросы сертификатов, поступившие от пользователей, и публикуют состояние отзыва сертификата. Отзыв конечных сертификатов происходит чаще, чем отзыв сертификата центра сертификации (CA). Это означает, что срок действия ключей значительно короче, а количество сертификатов, которыми необходимо управлять, значительно выше. При этом у центра сертификации (CA), выдающего конечные сертификаты, количество отозванных сертификатов значительно выше, чем у центра сертификации (CA), который выпускает сертификаты только для центров сертификации (СА).
Рекомендуется часто обновлять сертификат центра сертификации (CA) новым ключом. Тем самым атака злоумышленника на ключ принесет ему меньше пользы и причинит меньше вреда атакуемому. При создании нового ключа также создается новая точка CDP. Это гарантирует то, что ключ, используемый для подписания сертификата, также соответствует ключу, используемому для подписания списка CRL. Создание дополнительных точек CDP означает, что вместо одного большого списка CRL создано множество маленьких списков CRL, что приводит к сокращению времени загрузки индивидуальных списков CRL. (Такой процесс создания большого количества маленьких списков CRL вместо одного большого известен как разделение списка CRL). Клиенты (как компьютеры, так и пользователи) могут определить, правильный ли у них список CRL, путем проверки подписи списка CRL. Такая проверка обеспечивает большую надежность при работе с другими клиентами.
Связанные вопросы
В данном разделе описаны следующие темы, связанные со службами сертификации Windows 2000:
| • | Экспортные правила |
| • | Сертификаты SGC |
| • | Поддержка CSP сторонних производителей |
Экспортные правила
Существует всеобщее заблуждение о том, что любая продукция, связанная с криптографией подпадает под действие контроля над экспортом. На самом деле экспортные ограничения действуют только для составляющих, которые непосредственно задействованы в процессе шифрования. Такими составляющими являются алгоритмы симметричного шифрования и технологии открытых ключей, которые используются при обмене ключами во время сеанса симметричного шифрования.
Технология цифровой подписи открытым ключом не подпадает под действия экспортного ограничения, поскольку данные, которые подписываются, не являются зашифрованными. Вся продукция корпорации Microsoft способна создавать открытые ключи для подписи одинаковой сложности. Тем не менее, все-таки существует различие в сложности открытых ключей, используемых при обмене между продукцией Microsoft, которая идет на экспорт, и которая подпадает под действие экспортного контроля. Благодаря недавно принятым новым экспортным правилам различие между разными версиями продукции теперь намного меньше, чем прежде.
Службы сертификации Windows 2000 выполняют только операции подписания и, следовательно, используют только пары открытых ключей для подписи. Открытые ключи, которые используются для подписания сертификатов, обладают одинаковой сложностью, как в версии Windows 2000, выпускаемой для Северной Америки, так и для версий Windows 2000 идущих на экспорт. Генерирование ключа владельца осуществляется на стороне клиента, а не на стороне центра сертификации (CA). Поэтому центр сертификации (CA) Windows 2000 поддерживает как разрешенные для экспорта клиенты, так и те, в отношении которых действуют экспортные ограничения.
Сертификаты SGC
Серверное шифрование SGC (Server Gated Cryptography, SGC) является частью ОС Windows 2000 (SGC также входит в состав ОС Windows 95, Windows 98 и Windows NT). Шифрование SGC обеспечивает стойкое 128-битное шифрование для использования в сфере сетевых банковских услуг (online banking), а также других предназначенных для этого случаях, при этом оно взаимодействует со всеми реализациями SGC ведущих производителей. Шифрование SGC гарантирует, что информация, которой обмениваются две стороны, может быть прочитана только ими, и не может быть изменена без их ведома.
SGC представляет собой расширение протокола SSL (SSL - Secure Sockets Layer). Протокол SSL является широко используемым решением для установки безопасного соединения с веб-сайтом. Например, Microsoft IIS для соединения TCP/IP предоставляет протокол SSL, обеспечивающий шифрование данных, проверку подлинности сервера и целостность сообщения.
Безопасная процедура установления связи SSL инициирует установление TCP/IP соединения. Результатом процедуры установления связи является согласование между клиентом и сервером уровня безопасности, который они будут использовать, чтобы для соединения были соблюдены все требования аутентификации. После чего, SSL используется только для шифрования и расшифровки потока байт протокола, который используется приложением (например, HTTP). Это означает, что как вся запрашиваемая по протоколу HTTP информация, так и получаемая по протоколу HTTP информация будет полностью зашифрованной, включая URL-ссылку, к которой обращается клиент, любые данные, введенные в специальные формы (такие как номера кредитных карт), любая информация для авторизации по HTTP (имена пользователей и пароли), и все данные, возвращаемые сервером клиенту.
Различие между SSL и SGC состоит в том, что SGC используется только в строго ограниченных целях—в основном для защиты банковской информации. Результатом этого стало то, что, экспортный закон США, который в других случаях запрещает экспорт продукции стойкого шифрования, разрешил использование стойкого шифрования SGC в большей части стран11. Поскольку c другой стороны SSL может использоваться для любых целей, то экспортным законом США определено наличие двух версий продукции: версия для Северной Америки, в которой использовались бы криптографические ключи длиной в 128-бит, и международная версия, в которой использовались бы криптографические ключи длиной 40-бит.
На одном компьютере Вы можете использовать как SGC, так и SSL. Цифровые сертификаты для SSL и SGC не являются взаимозаменяемыми. Сертификат SGC может функционировать как сертификат SSL, но не наоборот. Это означает, что для того, чтобы можно было использовать стойкое шифрование, и у банка и у клиента должны быть установлены сертификаты SGC. Если это условие не выполняется, то сессия сводится к обычной SSL-сессии.
При создании Интернет-сервера авторизованного зарубежного банка, вместо обычного сертификата сервера устанавливается сертификат SGC. Серверная часть безопасного канала (schannel12 ) определяет, что это сертификат SGC и включает 128-битное шифрование SSL. После того, как этот сертификат будет переслан клиенту (что является частью процедуры установления связи по SSL), клиентская часть schannel также определит его наличие и обеспечит 128-битное шифрование SSL для этого соединения. (Для того, чтобы это работало не требуется, чтобы у сервера или у клиента была внутренняя версия schannel).
Сертификаты SGC обладают двумя характеристиками:
| • | В сертификате SGC есть специальное поле EKU расширенного использования ключа (EKU - extended key usage). |
| • | Сертификаты SGC выдаются специальными авторизованными центрами сертификации (CA) |
Если необходимо, чтобы в сертификате SGC было действительным только специальное поле EKU, то в этом случае любой центр сертификации (CA) может выдать сертификат SGC. Несмотря на то, что любой центр сертификации (CA), включая центр сертификации служб сертификации Windows 2000, может создать сертификат со специальным полем EKU, будет действительно работать только сертификат, выданный авторизованным центром сертификации (СА).
Поддержка CSP сторонних производителей
ОС Windows 2000 и службы сертификации Windows 2000 поддерживают использование CSP (CSP - cryptographic service providers) сторонних производителей. CSP представляет собой программу, установленную на Ваш компьютер (или на устройство, к которому компьютер имеет доступ), которая выполняет связанные с криптографией операции, такие как обмен секретными ключами, цифровая подпись данных и аутентификация с помощью открытых ключей. По умолчанию как для корневого центра сертификации (CA) предприятия, так и для корневого изолированного центра сертификации (CA) используется CSP корпорации Microsoft - Microsoft Base Cryptographic Provider.
На алгоритмы, используемые в CSP, не накладываются никакие ограничения действующих экспортных правил США. Кроме того, нет никаких требований, которые бы предписывали, что все CSP должны работать по одному принципу. Некоторые CSP разрабатываются для конечных пользователей (как в случае с CSP для смарт-карт), а другие – для серверных операций (как в случае с криптографическими ускорителями для PCI и SCSI).
Проектирование инфраструктуры открытых ключей (PKI) и ее развертывание в Windows 2000
В данном разделе описываются проблемы, связанные с организацией и развертыванием служб сертификации Windows 2000. В разделе представлены следующие две темы:
| • | Проектирование иерархии центров сертификации (СА) |
| • | Развертывание служб сертификации |
Для получения детальной информации об устранении проблем с развертыванием обратитесь также к разделу «Оптимизация развертывания инфраструктуры открытых ключей (PKI)» ("Optimizing PKI Deployment") официального документа «Решение проблем при развертывании инфраструктуры открытых ключей (PKI) Windows 2000 и входе в систему с помощью смарт-карт» (EN) (ссылка на данный документ дана в разделе "Дополнительная информация").
Проектирование иерархии центров сертификации (СА)
При проектировании иерархии центров сертификации (СА) вначале необходимо определить количество центров сертификации (СА) и их расположение. В данном разделе описываются общие принципы построения иерархии центров сертификации (СА) в Вашей организации. Информация представлена в следующих темах:
| • | Емкость базы данных центра сертификации (CA) |
| • | Сетевое соединение |
| • | Делегирование административных полномочий |
| • | Облегчение реорганизации предприятия |
| • | Доступность служб |
| • | Публикация сертификатов |
Емкость базы данных центра сертификации (CA)
Microsoft провела тестирование серверов, на которых были запущены службы сертификации Windows 2000 с базами данных, количество сертификатов в которых превышало один миллион. В течение длительного времени обычный пользователь использует несколько сертификатов в зависимости от используемых приложений, срока действия сертификатов и т.д.
Принято считать, что один центр сертификации (CA) Windows 2000 рассчитан на поддержку 250,000 пользователей. Нет никаких практических ограничений на общее количество серверов со службами сертификации, которые может поддерживать лес Windows 2000. Следовательно, службы сертификации Windows 2000 могут поддерживать любое количество пользователей в лесу Windows 2000.
Даже при такой емкости, хранилище базы данных, используемое службами сертификации работает с частью своей известной емкости хранения, а количество сертификатов, поддерживаемых одним центром сертификации (СА) в следующих выпусках ОС Windows 2000 Server будет значительно увеличено.
Сетевое соединение
Клиентам Windows 2000 или веб-клиентам для подачи заявки на сертификат центру сертификации (CA) Windows 2000 требуется наличие DCOM соединения. (DCOM представляет собой средство передачи сообщений, с помощью которого распределенные приложения могут осуществлять вызов процедур, доступных на компьютерах в сети). Для того, чтобы пользователи могли использовать веб-клиент для подачи заявок на сертификат, необходимо наличие веб-соединения между пользователями и сервером IIS, и DCOM соединения между сервером IIS и центром сертификации (СА).
Делегирование административных полномочий
Если административная модель Вашей организации является высоко децентрализованной, то Вы можете отразить эту децентрализацию в иерархии центров сертификации (СА). Кроме того, иерархия центров сертификации (СА) может охватывать несколько лесов Windows 2000: подчиненный центр сертификации (CA) может находиться в том же домене, что и родительский, в дочернем по отношению к родительскому домену, или в домене отдельного леса. После создания подчиненного центра сертификации (CA) Вы можете делегировать полномочия на управление им группе администраторов, закрепив за ними ответственность за центр сертификации (CA) с помощью групповой политики. В данном случае единственным правом, которым будет обладать вышестоящий центр сертификации (CA), будет возможность отзыва сертификата подчиненного центра сертификации (CA).
Облегчение реорганизации предприятия
Наличие нескольких центров сертификации (СА) в отличие от только одного центра сертификации (CA) в организации упрощает администрирование, поскольку Вы можете в этом случае «перемещать центр сертификации (CA)». Сегодня много предприятий продаются и покупаются корпорациями. Для того, чтобы нормально распоряжаться такими корпоративными приобретениями, требуется реорганизация ИТ-инфраструктуры к тому виду, который бы соответствовал всем этим изменениям. Использование служб сертификации Windows 2000 позволяет упростить задачи по реорганизации инфраструктур открытых ключей (PKI), когда все пользователи принадлежат одному центру сертификации (CA), поскольку добавление центра сертификации (CA) с его пользователями в иерархию или удаление из нее происходит относительно просто. Однако, невозможно переместить подгруппу пользователей одного центра сертификации (CA) на новый центр сертификации (CA) без принудительной подачи запроса на сертификат нового центра сертификации (CA). Это приводит к значительному увеличению стоимости и неудобству изменений. Поэтому необходимо принимать во внимание эти факторы при планировании структуры центров сертификации (СА).
Доступность служб
Центры сертификации (CA) Windows 2000 (как и в случае с контроллерами домена) обеспечивают высокую доступность, если их используется несколько. Организация нескольких центров сертификации (СА) гарантирует, что в лесу будет хотя бы один центр сертификации (СА), способный обработать запросы подачи заявок.
Публикация сертификатов
При использовании служб сертификации Windows 2000 сертификаты пользователей публикуются в объекте пользователя в том домене, членом которого является пользователь. Чтобы опубликовать сертификат в объекте пользователя в Active Directory центр сертификации (CA) должен иметь доступ к контроллеру домена в домене пользователя. Поэтому, не только пользователь должен иметь сетевой доступ к центру сертификации (CA) для того, чтобы сделать запрос, но и центр сертификации (CA) должен иметь сетевой доступ к контроллеру домена в домене пользователя.
Развертывание служб сертификации
В данном разделе раскрываются следующие темы по развертыванию служб сертификации Windows 2000:
| • | Организация иерархии центров сертификации (СА) |
| • | Использование изолированного центра сертификации (CA) для Вашего автономного корневого центра сертификации (CA) |
| • | Аппаратные поставщики служб криптографии |
| • | Период публикации списка CRL |
| • | Рекомендации по выбору конфигурации аппаратного обеспечения |
Организация иерархии центров сертификации (СА)
Поскольку Вы создаете иерархию, то необходимо сначала создать ее вершину, а затем спускаться вниз. Поэтому для начала создайте корневой центр сертификации (CA). Если в качестве корневого центра сертификации (CA) в Вашей организации используется коммерческий центр сертификации (CA) третьей стороны, то его создавать не нужно, т.к. он уже существует. А вся ответственность по обеспечению его безопасности ложится на обслуживающую его третью сторону.
Если Вы все же решили создать собственный корневой центр сертификации (CA), то первичное требование, которое должно соблюдаться, это то, что он должен быть безопасен. То, насколько он должен быть безопасным определяется тем, что именно находится под угрозой и каков возможный масштаб нападения.
Наиболее часто корневой центр сертификации (CA) используют автономно, поместив его в хранилище или в другое безопасное место, и используют его только для выпуска небольшого количества сертификатов (безопасный корневой центр сертификации (CA) используется только для выдачи сертификатов подчиненным центрам сертификации (СА)). Компьютер, который используется как безопасный корневой центр сертификации (CA) не должен быть членом какого-либо домена и вообще не должен иметь сетевой карты. Такая физическая защита гарантирует, что корневой центр сертификации (CA) невозможно будет просто взломать, и что те работающие в сети подчиненные центры сертификации (CA), которые стали ненадежными, можно будет безопасно отозвать.
Физическую безопасность можно будет усилить введением высокого уровня процедур безопасности, таких, как требования нескольких одновременных операторов для взаимного подтверждения действий.
Использование изолированного центра сертификации (CA) для Вашего автономного корневого центра сертификации (CA)
Выполняя свои функции в сети Windows 2000, изолированные центры сертификации (CA) могут быть настроены на работу автономно (без непосредственного подключения к сети). Задача автономных центров сертификации (СА) – обрабатывать запросы, поступающие от подчиненных центров сертификации (СА). Хотя такая конфигурация является более безопасной, это увеличивает административную нагрузку. Во время установки подчиненного центра сертификации (CA), создается запрос на сертификат, подписанный по стандарту PKCS-10 (Public Key Cryptography Standards, PKCS). Данный запрос сертификата должен быть вручную перенесен с помощью сменных носителей на автономный центр сертификации (CA). При получении такого запроса автономный центр сертификации (CA) создает сообщение по стандарту PKCS-7, в котором содержится указанный в запросе PKCS-10 сертификат центра сертификации (CA). Установка подчиненного центра сертификации (CA) завершится только тогда, когда сообщение по стандарту PKCS-7 будет физически перенесено назад на подчиненный центр сертификации (CA). (Для получения дополнительной информации о семействе стандартов PKCS для шифрования открытым ключом, обратитесь к разделу "Стандарты шифрования с открытым ключом " в Приложении Б).
Кроме того, администраторы должны вручную публиковать сертификаты и списки CRL в Active Directory, а также вручную регулярно обновлять списки CRL (это определяется сроком действия списков CRL). Для получения информации о том, как это выполняется, обратитесь к разделу «DSStore—Новое средство для инфраструктуры открытых ключей Windows 2000» ("DSStore—New Tool for Windows 2000 PKI") официального документа «Решение проблем при развертывании инфраструктуры открытых ключей (PKI) Windows 2000 и входе в систему с помощью смарт-карт» (EN) (ссылка на этот документ дана в разделе "Дополнительная информация"), или можете обратиться к разделу справки Windows 2000, посвященному автономным корневым центрам сертификации (СА).
Важно. Убедитесь, что перед выдачей автономным корневым центром сертификации (CA) сертификата подчиненному центру сертификации (CA) Вы изменили AIA-расширения и положения CDP (в соответствии со значениями, отображенными приложением DSStore) в оснастке Центр сертификации (CA). (Для получения информации о важности этих расширений сертификата обратитесь к разделу "Приложение A. Формирование цепочек сертификатов в Windows 2000").
Аппаратные поставщики служб криптографии
Традиционно организации используют аппаратные поставщики служб криптографии (CSP) для повышения производительности путем переноса выполнения операций шифрования на специализированное оборудование. Первичной задачей служб сертификации является обеспечение безопасности материала закрытого криптографического ключа. Защита материала ключа с помощью специализированного, устойчивого ко взлому аппаратного обеспечения, усиливает его безопасность, а также безопасность центра сертификации (CA) и сертификатов, которые он выпускает. Для таких центров сертификации (СА), как автономные центры сертификации (CA) и других важных центров сертификации (СА), рекомендуется использовать аппаратный поставщик CSP.
Период публикации списка CRL
В Вашей организации необходимо установить баланс между необходимостью частой (насколько это необходимо) публикации информации в списках CRL и в связанной с этим большой нагрузкой на сеть и на сервер.
Частая публикация списков CRL увеличивает нагрузку на сервер. Увеличение нагрузки вызвано тем, что клиенты вынуждены загружать список CRL каждый раз, когда он публикуется заново по истечении своего срока действия.
Чем чаще центр сертификации (CA) публикует список CRL в Active Directory, тем быстрее становятся известны изменения в состоянии сертификатов. Несмотря на это, всякий раз, когда срок действия списка CRL истекает и он публикуется вновь, публикуется заново и полный список отозванных сертификатов, даже если никаких изменений не произошло. Частая публикация списка CRL увеличивает объем трафика в сети, поскольку данные Active Directory реплицируются на все контроллеры домена в лесу. (Для получения информации о том, как репликация влияет на публикацию списка CRL, обратитесь к рассмотренному ранее разделу "Списки отзыва сертификатов". Для получения информации о решении проблем, вызванных репликацией в среде инфраструктуры открытых ключей Windows 2000, обратитесь к разделу «Задержка, вызванная репликацией Active Directory» ("Latency Caused by Active Directory Replication") в официальном документе «Решение проблем при развертывании инфраструктуры открытых ключей (PKI) Windows 2000 и входе в систему с помощью смарт-карт» (EN) (ссылка на этот документ дана в разделе "Дополнительная информация").
Баланс между необходимостью частой публикации и минимизацией влияния на инфраструктуру должен быть изначально заложен при проектировании и вводе в эксплуатацию иерархии центров сертификации (CA). Для большинства сертификатов нет необходимости часто публиковать их состояние в списке отзыва, поскольку они не представляют большой угрозы. Такие сертификаты могут выдаваться центрами сертификации (СА), у которых период публикации списка CRL довольно большой (например, одна неделя). Особо ценные сертификаты могут выдаваться другими центрами сертификации (СА), у которых период публикации списка CRL более короткий (один день). Обычно в организации используется несколько сертификатов, имеющих особую ценность, благодаря чему список CRL имеет маленький размер. Выдача более значимых сертификатов с коротким сроком действия (от трех до шести месяцев), после того, как отозванные сертификаты будут удалены из списков CRL, также способствует установлению баланса между частотой публикации и нагрузкой на сеть и сервер.
Рекомендации по выбору конфигурации аппаратного обеспече ия
Сертификаты и публикация сертификатов включает в себя множество аспектов, поэтому рекомендации по выбору конфигурации аппаратного обеспечения могут быть только общими. В Таблице 1 представлены ориентировочные размеры служб сертификации.
Таблица 1 – Общие рекомендации по выбору конфигурации аппаратного обесп чения для служб сертификации
| Размер службы | Минимальный объем физической памяти | Рекомендуемый объем физической памяти | Ожидаемый размер базы данных |
| Сертификаты, размером до 10 кБ | 64 MБ | 128 MБ | До 200 кБ |
| Сертификаты, размером 10–100 кБ | 128 MБ | 256 MБ | 200 кБ–2 ГБ |
| Сертификаты, размером 100 кБ–1 MБ | 256 MБ | 512 MБ | 2–20 ГБ |
Размер базы данных 1 –20 кБ (килобайт) на каждый запрос.
Заключение
Обеспечение безопасности при передаче информации, как по внутренним, так и по внешним каналам связи, особенно через сеть Интернет, является важным аспектом современных систем, работающих в сети. Инфраструктура открытых ключей Windows 2000 и службы сертификации, предоставляют необходимые для этого службы безопасности, включая проверку доказательства происхождения, конфиденциальности и целостности данных.
Службы сертификации Windows 2000 используют центры сертификации (CA) и сертификаты, выдаваемые ими, для проверки и аутентификации каждой из сторон, участвующей в процессе электронного обмена данными. В данном документе описывается, как службы сертификации Windows 2000, инфраструктура открытых ключей и использование криптографии способствует безопасному обмену информации через сеть Интернет, другие внешние сети и интрасети.
Приложение A. Формирование цепочек сертификатов в Windows 2000
В данном приложении описывается формирование цепочек сертификатов в среде служб сертификации Windows 2000. Эта тема рассматривается в следующих подразделах:
| • | Доверенные корневые сертификаты |
| • | Корневое хранилище сертификатов предприятия на основе службы каталогов Active Directory |
| • | Проверка промежуточных сертификатов |
| • | Проверка отзыва |
| • | Требования, выдвигаемые к цепочке сертификатов, для получения возможности входа с помощью смарт-карт |
Для получения дополнительной информации о цепочках сертификатов и их применении в сетях, использующих доверенный открытый ключ, обратитесь к официальным документам, связанным с инфраструктурой открытых ключей, а также к ссылке на учебник по основам криптографии: «Прикладная криптография: протоколы, алгоритмы, исходный код на С» («Applied Cryptography: Protocols, Algorithms, and Source Code in C»)(EN), приведенной ниже в разделе "Дополнительная информация".
Доверенные корневые сертификаты
Для того, чтобы цепочки сертификатов считались действительными, они должны подтверждаться доверенным корневым сертификатом. При установке центра сертификации (CA) эти корневые сертификаты распространяются следующим образом:
| • | Добавляются администратором компьютера с помощью Мастера импорта сертификатов (Certificate Import wizard) оснастки Сертификаты (Certificates). |
| • | Добавляются администратором домена с помощью групповой политики открытых ключей (Для получения дополнительной информации об этом, включая информацию о том, что именно необходимо предпринять, пользуйтесь результатами поиска в справочной системе Windows 2000, осуществив поиск по ключевым словам "public key policies"). |
| • | Добавляются из Active Directory в том случае, когда администратор домена устанавливает центр сертификации (CA), или добавляются с помощью средства DSStore из комплекта Windows 2000 Resource Kit. Вы используете средство DSStore для установки корневого сертификата в Active Directory, чтобы затем клиенты могли получать сертификаты от Active Directory, когда они обрабатывают события автоматической подачи заявки. (Для получения дополнительной информации о средстве DSStore обратитесь к официальному документу «Решение проблем при развертывании инфраструктуры открытых ключей (PKI) Windows 2000 и входе в систему с помощью смарт-карт» (EN) (ссылка на этот документ дана в разделе "Дополнительная информация"), |
Корневое хранилище сертификатов предприятия на основе службы каталогов 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 в Вашем лесу. |
| • | Каждый сертификат из цепочки сертификатов должен быть доступен, т.е. либо он уже должен быть на компьютере или должен быть доступен по сети с помощью стандартных протоколов (таких, как http:, ldap: или доступа к файлам). Это означает, что вся информация об отзыве для каждого сертификата в цепочке сертификата должна быть доступна. |
| • | Вся информация об отзыве для каждого сертификата в цепочке сертификатов должна быть доступна. |
| • | Ни один сертификат из цепочки сертификатов не должен быть отозван. |
| • | Оба сертификата должны иметь цепочку к доверенным корневым сертификатам. |
| • | Сертификаты смарт-карт должны быть основаны на шаблоне сертификата SmartCard Logon или SmartCard User. |
Приложение Б. Совместимость и стандарты
В данном приложении описаны стандарты, которых придерживаются службы сертификации Windows 2000, и конкретное применение этих стандартов. Также описывается, как и где эти стандарты используются службами сертификации. Эти темы раскрываются в следующих подразделах:
| • | Международный союз электросвязи (ITU) |
| • | Сообщество IETF |
| • | Стандарты шифрования с открытым ключом (PKCS) |
Международный союз электросвязи
Международный союз электросвязи (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 описываются в следующих подразделах:
| • | Названия полей в сертификатах |
| • | Расширения сертификатов |
| • | Сертификаты и расширения списков CRL |
| • | Особые расширения Windows 2000 |
| • | Год 2000 и сертификаты |
| • | Международные наборы символов и DNS-имена |
Названия полей в сертификатах
В соответствии с 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. Подмножество представлено такими символами:
| • | A-Z |
| • | a-z |
| • | 0-9 |
| • | (пробел) ' ( ) + , - . / : = ? |
Если набор символов 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
| Тип сертификата | Центры сертификации (CA) предприятия | Изолированные центры сертификации (CA) |
| Сертификат корневого центра сертификации (CA) | (Basic Constraints) Основные ограничения (Key Usage) Использование ключа (Subject Key Identifier) (CRL Distribution Point (CDP)) (Certificate Template) Шаблон сертификата Версия центра сертификации (CA) | (Basic Constraints) Основные ограничения (Key Usage) (Subject Key Identifier) (CRL Distribution Point (CDP)) (Certificate Template) Шаблон сертификата Версия центра сертификации (CA) |
| Сертификат подчиненного центра сертификации (CA) | (Basic Constraints) Основные ограничения (Key Usage) Использование ключа (CRL Distribution Point (CDP)) Точка распространения списков отзыва (CDP) Идентификатор ключа центра сертификации (CA) Доступ к сведениям о центрах сертификации (AIA) Шаблон сертификата Версия центра сертификации (CA) | (Basic Constraints) Основные ограничения (Key Usage) (CRL Distribution Point (CDP)) Точка распространения списков отзыва (CDP) (Authority Information Access (AIA)) Версия центра сертификации (CA) |
| Сертификат конечного владельца | (Key Usage) Использование ключа Использование расширенного ключа Точка распространения списков отзыва (CDP) Идентификатор ключа центра сертификации (CA) (Subject Alternate Name) Альтернативное имя владельца (Certificate Template) Шаблон сертификата | (Key Usage) Использование ключа Использование расширенного ключа Точка распространения списков отзыва (CDP) Идентификатор ключа центра сертификации (CA) Доступ к сведениям о центрах сертификации (AIA) |
Расширения сертификатов и списков CRL
Ниже приводится описание некоторых из наиболее важных расширений сертификатов и списков CRL:
- Расширение Основные ограничения используется только для сертификатов центров сертификации (СА). Оно содержит логический флаг для указания сертификата центра сертификации (CA). Это расширение помечено как критическое в сертификате. В данный момент центры сертификации (CA) предприятия и изолированные центры сертификации (CA) Windows 2000 не поддерживают опцию длины пути в этом расширении.
Расширение Использование ключа определяет криптографические операции, для которых могут использоваться пары ключей. Возможны следующие варианты использования:
- Цифровая подпись
- Неотрекаемость
- Шифрование ключей
- Шифрование данных
- Согласование ключей
- Подписание сертификатов
- Подписание списка отзыва (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), ссылка на который дана выше в данном разделе. |
Обсуждение статьи на форуме