Если вы хотите ознакомиться с остальными частями этой статьи, пожалуйста, прочитайте:
Это наша вторая статья из цикла, посвященного Microsoft PKI. В нашей первой статье мы кратко рассмотрели, как подготовить и как планировать наш Microsoft PKI. В этой статье мы будем немного более техничными. Мы рассмотрим некоторые проблемы при проектировании PKI. В этой статье мы покажем вам, как избежать общих ошибок на фазе проектирования.
Когда вы проектируете ваш PKI, то необходимо учитывать следующие вещи:
Давайте поближе посмотрим на каждую из этих проектных проблем.
Количество и уровни CA вы должны учитывать сразу, в зависимости от ваших требований к безопасности и доступности. Вы должны постараться организовать вашу иерархию в соответствии с вашими нуждами. В действительности не существует каких- либо рекомендаций относительно того, сколько уровней CA вам нужно, хотя очень редко кому-либо необходимо 4 или более уровней. Однако, существует правило большого пальца, которое мы представили в таблице 1 ниже, которое здорово поможет вам идти в верном направлении:
| Уровень CA | Комментарии |
|---|---|
 |
|
 |
|
 |
|
Как дополнительное примечание, вы можете вспомнить из предыдущей статьи, что существует нечто, называемое политикой сертификата (certificate policy), которая описывает как и кто будет выпускать и распределять сертификаты для субъектов (субъекты – это пользователи, компьютеры, устройства и т.п.). Если вам кажется, что вам может понадобиться более одной политики сертификата (certificate policy) из-за правовой, географической организационной особенности, то вам определенно нужна трехуровневая иерархия PKI hierarchy, т.к. для соблюдения этого требования необходимо 2 или более политики CA второго уровня.
Когда вы реализуете PKI, вы всегда должны начинать с корневого (root) CA, вне зависимости от того, имеем ли мы дела с одноуровневой, двухуровневой или трехуровневой иерархией PKI hierarchy. Т.к. корневой (root) CA всегда будет в основании доверительных отношений (trust), и очень часто реализуется с использованием самовыпускающегося сертификата (self-issued certificate), то очень важно защищать закрытый ключ (private key) вашего корневого (root) CA всеми доступными способами. Так должно быть всегда, вне зависимости от количества уровней, из которых состоит ваша иерархия PKI. Если ваша иерархия PKI состоит из 2 или более уровней, то для вашего корневого (root) CA необходим минимальный доступ, т.к. к корневому CA будет необходим доступ только для второстепенного CA. Однако, по мере того, как увеличивается расстояние до корневого (root) CA (т.е. увеличивается количество уровней), требования к безопасности снижаются и доступ увеличивается. Это очень важный фактор, когда мы начнем установку CA, о котором мы расскажем позднее в этой статье.
Перед тем, как вы начнете установку CA, вы должны спланировать, какой будет размер закрытого ключа (private key) для CA, а также, как он должен быть защищен. Давайте посмотрим на размер ключа, который является очень важным по причине безопасности и совместимости. В таблице 2 ниже представлены рекомендуемые размеры ключей:
| CA роль | Размер ключа |
|---|---|
| Root CA (корневой) | 4096 |
| Policy CA (политика) | 4096 |
| Issuing CA (выпускающий) | 2048 |
Обычно, целях безопасности рекомендуется использовать ключ размером 4096, особенно для корневого (root) CA. Однако, в результате этого могут возникнуть различные проблемы с совместимостью, примером могут служить сетевые продукты компании Cisco (в зависимости от используемой версии Cisco IOS). Это возникает в результате того, что многие продукты сторонних производителей имеют проблемы с обработкой ключа, размер которого больше 2048. А т.к. сетевое оборудование может быть интегрировано в решения, как 802.1x для проверки и совместимости, размер ключа имеет значение. Поэтому необходимо быть абсолютно уверенными, что вы знаете используемое вами оборудование, а также его ограничения для обработки сертификатов перед тем, как вы начнете реализовывать ваш PKI.
После того, как вы определились с размером ключа CA, который вы будете использовать, пришло время узнать о том, как защищать закрытый ключ CA private key.
По умолчанию, CA использует поставщика услуг по шифрованию Microsoft Cryptographic Service Provider (CSP) и защищает свой закрытый ключ (private key) с помощью встроенного программного интерфейса для защиты данных Data Protection API (DPAPI). В результате этого возникает проблема, т.к. все члены группы локальных администраторов (local administrators group) имеют доступ к закрытому ключу CA, и любой член этой группы может экспортировать закрытый ключ CA, а затем создать фальшивый CA, который сможет выпускать фальшивые сертификаты. Еще одна проблема с безопасностью заключается в атаках с переполнением буфера (buffer overrun) с помощью вредоносного программного обеспечения.
Итак, что же делать? Самый лучше ответ – это зависит от… Вам придется выбирать между требованиями к безопасности и стоимостью и удобством, связанными с защитой закрытого ключа (private key) CA, и очень часто иерархия CA диктует свои правила. Ниже в таблице 3 приведены некоторые из наиболее общих способов для защиты закрытого ключа (private key) CA. Мы оставим это на ваше собственное усмотрение. Просто помните, что это, вероятно, один из самых важных компонентов в вашем PKI.
| Метод защиты | Pros (+) | Cons (-) |
|---|---|---|
| Local Certificate Store (локальное хранилище) |
|
|
| Chip based authentication (чиповая аутентификация — Смарт карты или USB ключи) |
|
|
| Encrypted Virtual machines (зашифрованные виртуальные машины) |
|
|
| Hardware Security Module (HSM — аппаратные модули безопасности) |
|
|
В дополнение к рекомендациям, представленным в таблице 3, вы также можете увеличить безопасность CA, убедившись, что все CA, за исключением выпускающего CA, работают в автономном режиме (offline). Под этим мы понимаем, что они должны быть вне сети и подключаться к сети лишь тогда, когда для CRL и выпущенным сертификатам для всех CAs во всем PKI необходимо обновление. Обычно, корневой и стратегический CA выключаются полностью, но опять же это зависит от того, насколько хороша у вас физическая безопасность, и как защищаются закрытые ключи CA private keys, а также насколько надежно ваше аппаратное обеспечение.
Последняя область, на которую мы обратим внимание перед тем, как начнем реализацию PKI, это размещение публикации для списков Certificate Revocation Lists (CRL) и общих ключей (public key) CA. Их также называют точки размещения сертификатов (Certificate Distribution Points или CDP). Существуют различные протоколы, которые можно использовать для описания CDP. Это:
Ниже на рисунке 1, мы изобразили, где публиковать CRL и открытые ключи CA (public key), а также рекомендуемый порядок протоколов.
Рисунок 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, который состоит из комбинации автономных, отдельно стоящих CA и корпоративных выпускающих CA. Мы настоятельно рекомендуем вам изучить таблицы, представленные в этой статье, т.к. в них содержатся очень полезные советы, которых мы лишь кратко коснулись. В нашей следующей статье, посвященной PKI, мы будем использовать рекомендации, представленные в этой статье, а также покажем вам, как устанавливать PKI с помощью поэтапного метода.
Внешние ресурсы
Для написания этой статьи использовалось много великолепных ресурсов. Все замечательные статьи по Microsoft PKI собраны в одном месте, вы можете найти их на веб портале Microsoft PKI Web Portal
http://www.microsoft.com/pki
Хотите увидеть, как Microsoft делает PKI, то проверьте IT Showcase -Deploying PKI Inside Microsoft
http://www.microsoft.com/technet/itsolutions/msit/security/deppkiin.mspx
Источник www.windowsecurity.com
Tags: dns, ftp, ldap, mac, vpn