Краткое руководство Microsoft PKI. Часть 2. Проектирование

Если вы хотите прочитать другие статьи из этой серии, перейдите по ссылке:

• Краткое руководство Microsoft PKI. Часть 1. Планирование
• Краткое руководство Microsoft PKI. Часть 3. Установка
• Краткое руководство Microsoft PKI. Часть 4. Устранение неполадок

подпишитесь на нашу рассылку обновлений статей в режиме реального времени

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

Разработка PKI

При разработке PKI необходимо учитывать несколько моментов:

• Как должна выглядеть иерархия ЦС (например, количество ЦС и их роли)
• Как вы хотите защитить закрытые ключи центров сертификации?
• Где следует создавать точки публикации

Рассмотрим подробнее каждую из этих проблем проектирования.

Разработка хорошо масштабируемой иерархии ЦС

Количество и уровни центров сертификации, которые вы должны внедрить, в основном зависят от ваших требований к безопасности и доступности. Вы должны попытаться организовать свою иерархию в соответствии с вашими потребностями. На самом деле не существует руководства по передовой практике с точки зрения того, сколько уровней CA вам нужно, хотя крайне редко кому-то требуется 4 или более уровней; однако есть эмпирическое правило, которое мы перечислили в таблице 1 ниже, и оно может подтолкнуть вас в правильном направлении:

Таблица 1: Необходимое количество уровней CA

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

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

Закрытые ключи ЦС

Перед тем, как приступить к установке ЦС, вы должны иметь план того, каким должен быть размер закрытого ключа ЦС, а также как он должен быть защищен. Начнем с размера ключа, который очень важен как с точки зрения безопасности, так и с точки зрения совместимости. В таблице 2 ниже перечислены рекомендуемые размеры ключей:

Таблица 2: Рекомендуемый размер ключа ЦС

Обычно из соображений безопасности рекомендуется размер ключа 4096, особенно для корневого ЦС. Однако это может создать всевозможные проблемы несовместимости, например, с сетевыми продуктами на базе Cisco (в зависимости от используемой версии Cisco IOS). Это связано с тем, что многие сторонние продукты имеют проблемы с обработкой ключей размером больше 2048. А поскольку сетевое оборудование может быть интегрировано в такие решения, как 802.1x, для проверки и соответствия, размер ключа будет иметь значение. Поэтому убедитесь, что вы знаете, какое оборудование будет использоваться и какие ограничения могут быть в отношении обработки сертификатов, прежде чем приступить к реализации PKI.

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

Защита закрытого ключа ЦС

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

Итак, что нужно сделать? Ну, лучший ответ — «это зависит». Вам придется сбалансировать свои требования безопасности с затратами и удобством использования, связанными с защитой закрытого ключа ЦС, и часто именно иерархия ЦС диктует ваши варианты. В таблице 3 ниже мы перечислили некоторые из наиболее распространенных способов защиты закрытого ключа центра сертификации. Мы оставляем на ваше усмотрение оценку рисков с точки зрения того, как лучше всего защитить закрытый ключ ваших центров сертификации. Просто помните, что это, вероятно, самый важный компонент для защиты вашей PKI.

Таблица 3. Некоторые из наиболее распространенных способов защиты закрытого ключа ЦС

В дополнение к рекомендациям, перечисленным в таблице 3, вы также хотите повысить безопасность центров сертификации, убедившись, что все центры сертификации, кроме выдающих центров сертификации, находятся в автономном режиме. Под этим мы подразумеваем, что они должны, по крайней мере, быть вне сети и подключаться к сети только тогда, когда CRL и выданные сертификаты для всех ЦС во всей вашей PKI нуждаются в обновлении. В большинстве случаев корневой и политический центры сертификации полностью отключены, но, опять же, это должно зависеть от того, насколько хороша ваша физическая безопасность и как защищены закрытые ключи центров сертификации, а также насколько надежно ваше оборудование.

Где создавать точки публикации

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

• HTTP
• LDAP (что в мире Microsoft обычно означает Active Directory)
• FTP
• Общий доступ к файлам (SMB)

На рисунке 1 ниже показано, где публиковать открытые ключи CRL и CA, а также рекомендуемый порядок протоколов для наиболее распространенных протоколов.

Фигура 1:
Рекомендуемый порядок протокола CDP (щелкните здесь, чтобы увеличить изображение)

Как видите, рекомендуемым первичным протоколом должен быть HTTP, и для этого есть веская причина. Рекомендуется использовать HTTP, так как это лучший протокол как для внутренних, так и для внешних точек публикации. HTTP идеально подходит, если вам нужно выдавать сертификаты как для внутренних, так и для внешних пользователей одновременно. Особенно важно учитывать внешнее использование, поскольку вы хотели бы убедиться, что сертификаты, используемые для доступа VPN, NAQ или Wi-Fi, проверяются на отзыв, прежде чем пользователям будет разрешен доступ к вашей внутренней сети. Также важно отметить, что если CDP недоступен для данного протокола, время ожидания (обычно через 30 секунд) истекает, и он переходит к следующему протоколу в списке. Таким образом, имея правильную конфигурацию с самого начала, вы обеспечиваете отличный пользовательский интерфейс, поскольку CRL можно проверять из внутренних и внешних расположений без проблем с тайм-аутом и без ущерба для вашей настройки безопасности сети. Однако, если вы по тем или иным причинам должны выбрать протокол по умолчанию, которым является LDAP, то в этом нет ничего плохого, особенно если ваша PKI будет использоваться только для внутренних целей. Просто имейте в виду, что если вы используете PKI, интегрированную в Active Directory, и выдаете сертификаты внешним пользователям, то потребуется, чтобы они могли выполнять запросы LDAP к вашей Active Directory (при условии, что вы используете Active Directory в качестве репозитория CDP LDAP).

Однако вы также должны убедиться, что у вас есть избыточная настройка веб-сервера, используя настройку DNS с циклическим перебором, если ваш предпочтительный протокол — HTTP. Если вы хотите использовать LDAP, у вас уже есть избыточная настройка, если в вашем домене есть два или более контроллера домена.

Вывод

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

Внешние ресурсы

Эта серия статей написана с помощью множества замечательных ресурсов. Все отличные статьи Microsoft PKI собраны в одном месте, которое вы можете найти на веб-портале Microsoft PKI.
http://www.microsoft.com/pki

Хотите увидеть, как Microsoft использует PKI, посмотрите презентацию IT — Развертывание PKI внутри Microsoft.
http://www.microsoft.com/technet/itsolutions/msit/security/deppkiin.mspx

И это отличная книга — Microsoft Windows Server 2003 PKI и безопасность сертификатов.
http://www.microsoft.com/mspress/books/6745.asp

Если вы хотите прочитать другие статьи из этой серии, перейдите по ссылке:

• Краткое руководство Microsoft PKI. Часть 1. Планирование
• Краткое руководство Microsoft PKI. Часть 3. Установка
• Краткое руководство Microsoft PKI. Часть 4. Устранение неполадок

подпишитесь на нашу рассылку обновлений статей в режиме реального времени