Certificate chaining engine и certificate revocation checking — faq – pki extensions
Предлагаю немного отвлечься от autoenrollment и поговорить о часто задаваемым вопросам, которые относятся к проблемам certificate chaining engine. Данный FAQ основывается на вопросах, которые часто задаются на форумах TechNet.
Q: За что отвечают расширения CRL Distribution Points (CDP) и Authority Information Access (AIA) в цифровых сертификатах?
A: Расширение Authority Information Access всегда содержит ссылки на сертификат Certification Authority (CA), который издал рассматриваемый сертификат. Например, у вас есть сервер CA, который издаёт пользователям сертификаты. Каждый такой сертификат будет содержать ссылку на скачивание сертификата этого самого CA. Это необходимо для построения цепочки сертификатов. Как известно, любая иерархия PKI включает себя как минимум один корневой CA (Root CA) и может содержать несколько уровней промежуточных CA. Используя расширение AIA конечного сертификата, клиент скачивает сертификат издающего CA, который в расширении AIA так же содержит ссылки на скачивание сертификата вышестоящего CA. Этот процесс происходит до тех пор, пока цепочка не закончится самоподписанным сертификатом и который уже не содержит расширения AIA. Поскольку корневой сертификат самоподписанный, он является конечной точкой цепочки. По корневому сертификату определяется доверие цепочке. Чтобы доверять такой цепочке, корневой сертификат, на котором эта цепочка заканчивается, должен быть установлен в контейнере Trusted Root CAs в оснастке Certificates консоли MMC.
Расширение CRL Distribution Point содержит ссылки на файлы CRL, которые периодически публикует сервер CA, который издал рассматриваемый сертификат. Этот файл содержит серийные номера и прочую информацию о сертификатах, которые были отозваны. Сертификаты могут быть отозваны, когда есть подозрения или уже констатирован факт получения несанкционированного доступа к закрытому ключу третьим лицом. Закрытый ключ должен быть доступен только тому пользователю или компьютеру, которому выдан данный сертификат. Если третье лицо получило доступ к закрытому ключу, это лицо может воспользоваться им для получения конфиденциальной информации или выдавать себя за легитимного пользователя. В таких случаях администратор CA может отозвать такой сертификат. В таком случае если сертификат содержится в файле CRL, предъявителю данного сертификата никакого доверия не будет. Следует понимать, что CDP/AIA рассматриваемого сертификата содержат ссылки на файлы вышестоящего CA. Даже если владельцем рассматриваемого сертификата является сервер CA (Intermediate CA), ссылки будут указывать на файлы вышестоящего CA.
Более подробно вопрос рассмотрен по ссылке: Certificate Chaining Engine — как это работает.
Q: Нужны ли расширения CDP и AIA в сертификатах корневых CA?
A: Нет. Как уже было сказано, CDP и AIA содержат ссылки на файлы вышестоящего CA, а корневой сертификат является высшей точкой в иерархии и выше корневого CA ничего быть не может. Поэтому данные расширения бесполезны для сертификатов корневых CA и обычно просто отсутствуют.
Более подробно вопрос рассмотрен здесь: Certificate chaining engine (CCE) и отзыв корневых сертификатов
Q: На каком сервере CA я могу отозвать определённый сертификат?
A: каждый сервер CA поддерживает свой список CRL в который может включать только те сертификаты, которые были выданы именно этим CA. Это означает, что сертификат отозвать может только CA, который указан в поле Issuer рассматриваемого сертификата.
Q: Стоит ли использовать Certificate Hold в качестве причины отзыва сертификата? Если да, то в каких случаях?
A: Причина отзыва как Certificate Hold обладает одной особенностью — его можно извлечь обратно из CRL файла, после чего он перестанет считаться отозванным. Данная причина задумана для случаев когда сотрудник уходит в отпуск и такой отзыв позволит избежать использование отозванного сертификата на этот период. Однако, данную причину не следует никогда использовать. Это связано с тем, что после извлечения сертификата из CRL вы не можете узнать был ли он отозван в какой-то период времени. Например, вы отозвали сертификат с причиной Certificate Hold и через некоторое время передумали и извлекли сертификат из CRL. В последствии вы получаете документ, подписанный этим сертификатом именно в период фактического нахождения сертификата в CRL. Фактически получается, что документ был подписан в тот момент, когда сертификат был отозван. Поскольку он был потом извлечён из CRL, вы больше не можете доказать, что сертификат был отозван на момент подписания документа. По этой причине вы не должны использовать данную причину отзыва.
Q: При установке сертификата на сервер иногда получаю ошибку: The revocation function was unable to check revocation because the revocation server was offline. 0x80092021 (-2146885613). Что это может означать и как эту ошибку исправить?
A: Данная ошибка указывает на то, что системе не удалось проверить сертификат на отзыв. Иными словами, система извлекла ссылку из CDP расширения сертификата и по этой ссылке не удалось скачать CRL файл. В данном случае вы должны обратиться к администратору сервера CA, чтобы тот обеспечил доступность файла по ссылкам в CDP расширении. Если же вы сами исполняете эти обязанности, то вы должны самостоятельно решить этот вопрос — настроить точки публикации CRL файлов. В качестве временного решения (например, вы опубликовали CRL только в Active Directory и у вас несколько доменов в лесу, причиной этого может быть репликация AD. В таком случае вы можете скачать CRL файл локально на компьютер (любым удобным способом) и выполнить команду: certutil –addstore –f Root <pathfile.crl>
где <pathfile.crl> — путь к файлу CRL.
Q: При открытии файла сертификата я вижу следующее сообщение: Windows does not have enough information to verify this certificate. Что это означает и как с этим бороться?
A: Данное сообщение говорит о том, что системе не удалось найти сертификат вышестоящего CA. Как уже было отмечено, этот сертификат можно скачать по ссылке (ссылкам) в расширении AIA, но по всей видимости они нерабочие. Вы можете попробовать вручную скачать файл по этим ссылкам и вероятней всего вам это не удастся. Для решения этой проблемы вы должны опубликовать физический файл в соответствующие места: папка веб-сервера (для протокола HTTP) или контейнер AIA в Active Directory (для протокола LDAP). Если файл сертификата CA публикуется только в AD и у вас лес с несколькими доменами, данная ошибка может быть кратковременно вызвана задержками репликации. В таком случае для временного решения вы можете скачать файл на локальную машину (любым удобным для вас способом) и выполнить одну из двух команд:
certutil –addstore –f SubCA <pathfile.crt> — если вышестоящий CA не является корневым
certutil –addstore –f Root <pathfile.crt> — если вышестоящий CA является корневым.
где <pathfile.crt> — путь к файлу CER/CRT.
Q: Я отозвал сертификат, опубликовал новый CRL, однако при запуске файла сертификата я не вижу ошибок, что сертификат отозван. Почему?
A: Когда вы запускаете файл сертификата (просматриваете его содержимое), проверка на отзыв не происходит. Система только строит цепочку, но ни один сертификат на отзыв не проверяется. Это by design. Для проверки статуса сертификата вы можете воспользоваться следующими командами:
certutil –url <pathfile.cer> — этой командой вызывается удобный графический интерфейс, в котором вы можете выяснить статус отзыва сертификата.
certutil –verify –urlfetch <pathfile.cer> — данная команда выведет очень подробный текстовый лог проверки. Рекомендуется для использования профессионалами, которые в состоянии проанализировать этот лог.
где <pathfile.cer> — путь к файлу проверяемого сертификата.
Q: Я отозвал сертификат, опубликовал новые CRL, однако certutil показывает, что сертификат не отозван. Как так?
A: Это вызвано тем, что CRL’ы, как и ответы от OCSP Responder кешируются в оперативной памяти и жёстком диске. Для обновления кеша в памяти, следует перезапустить приложение, которое проверяет статус сертификата. А на самом диске CRL кешируется на срок действия конкретного CRL. Это значит, что клиент будет использовать данный кешированный CRL до срока указанного в поле Next update конкретного CRL файла. Кеширование используется для экономии ресурсов и пропускной способности сети. Но вы можете очистить кеш CRL (при этом удалятся все кешированные CRL), вы можете воспользоваться следующей командой:
certutil -setreg chainChainCacheResyncFiletime @now
после этого обязательно следует выполнить следующую команду:
certutil –delreg chainChainCacheResyncFiletime
Данные команды поддерживаются системами начиная с Windows XP SP3. Предыдущие системы не поддерживают очистку кеша CRL.
Q: Какие протоколы разрешены для расширений CDP/AIA?
A: Для Windows систем доступны только следующие протоколы:
HTTP:// — только для публикации в расширение сертификата.
LDAP:// — для публикации физических файлов и для публикации ссылки в расширение сертификата.
FILE:// — только для публикации физических файлов в сетевой папке (например, на веб-сервере). Хотя Windows Server 2003 и предыдущие системы позволяли такие ссылки в расширениях CDP/AIA, начиная с Windows Vista/Windows Server 2008 они больше не допускаются и не используются.
C:path — только для публикации физических файлов в файловой системе локального компьютера.
Более подробно можно прочитать по ссылке: CRL Distribution Points и Authority Information Access
Q: есть ли какие-то best practices по планированию расширений CDP/AIA?
A: да, существют определённые best practices по настройке расширений CDP/AIA на сервере CA. И вот как они выглядят в общем виде:
1) не следует использовать ссылки вида LDAP:// если ваши сертификаты могут использоваться вне пределах вашего леса AD. Это вызвано тем, что скачивать файлы по таким ссылкам могут только клиенты текущего леса, остальные клиенты будут получать ошибки по этим ссылкам. Целесообразно использовать более универсальные протоколы как HTTP. Данный протокол поддерживается множеством систем, в том числе и мобильными системами (смартфоны) и пользователями других операционных систем. При использовании HTTP рассмотрите возможность высокой доступности этих веб-серверов, как NLB-кластер или использования двух различных веб-серверов. В таком случае вы должны будете указать ссылки на скачивание файла для каждого веб-сервера.
2) используйте веб-сервера, которые доступны как изнутри сети, так и из интернета (если сертификаты могут использоваться пользователями интернета, например SSL-сертификаты) по одному и тому же URL.
3) при планировании ссылок, которые будут публиковаться в расширениях CDP/AIA сертификатов следует учитывать их очерёдность. Если вы решили использовать 2 независимых веб-сервера, первым указывайте тот, который будет являться основным. Это обусловлено тем, что клиент скачивает файлы по ссылкам в порядке их следования. Первая ссылка будет использоваться в первую очередь. Для ссылок публикации физического файла очерёдность не имеет значения.
4) для HTTP ссылок никогда не используйте SSL (т.е. HTTPS ссылки), поскольку это вызовет бесконечную проверку сертификатов, в результате чего вы никогда не скачаете нужный файл.
Более подробно можно прочитать по ссылкам: CRL Distribution Points и Authority Information Access, OCSP или CRL?
Q: Какие версии ОС Windows поддерживают нативного клиента OCSP?
A: Только ОС начиная с Windows Vista/Windows Server 2008 включают в себя клиента OCSP. Предыдущие системы никогда не поддерживали и не будут поддерживать клиента OCSP. Для них придётся приобретать отдельный программный продукт сторонних компаний.
Q: Я хочу использовать OCSP Responder как для внутренней, так и для внешней сети (интернета). На какое имя должен выдаваться сертификат OCSPResponseSigning?
A: на самом деле клиенту всё равно на какое имя выдаётся данный сертификат. Главное — сертификат должен отвечать следующим условиям:
1) должен быть выдан тем же CA для которого OCSP Responder осуществлял проверку статуса сертификата.
2) в Application Policies (Extended Key Usage) должен быть указан: OCSP Signing
3) в сертификате должно присутствовать расширение: OCSP No Revocation Checking
4) срок действия сертификата должен быть действующий.
Q: Мы в компании перешли на Windows Vista/Windows 7 и развернули OCSP Responder. Однако в сети уже выпущено огромное количество сертификатов, которые не содержат ссылок на OCSP Responder. Надо ли перевыпускать все сертификаты для включения в них ссылки на OCSP?
A: нет, вам не нужно перевыпускать все сертификаты, которые уже используются. Вы можете для доменных клиентов настроить групповую политику так, чтобы они получили адрес вашего OCSP Responder и которым они будут пользоваться при проверке сертификатов. В качестве руководства по настройке этой политики можете воспользоваться вот этой ссылкой: Appendix A: Managing OCSP Settings with Group Policy
Что бы почитать?
Certificate update and enrollment
После обработки всех ожидающих запросов, клиент проверяет статус каждого существующего сертификата. Если сертификат отозван или его срок истёк, он помещается в список ToBeDeleted.
Примечание: просроченные сертификаты будут помещены в этот список только если в групповой политике выставлен флаг Renew expired certificates, update pending certificates, and remove revoked certificates и сертификат не используется для шифрования.
Если срок действия сертификата преодолел отметку 80% и шаблон этого сертификата находится в списке доступных шаблонов (который был получен после нескольких уровней фильтрации в предыдущих шагах), клиент отправляет запрос на обновление сертификата. При этом запрос подписывается текущим сертификатом.
Если в реестре для текущего сертификата указан PolicyID, клиент будет пытаться найти тот же ID в списке политик CEP и запрос на обновление сертификата отправлять на сервер CES, который указан в политике. Если PolicyID для текущего сертификата не указан, то запрос будет отправляться на тот сервер CES, политика которого является по умолчанию (см fig.2).
Примечание: здесь и далее. Если по каким-либо причинам запрос подписать невозможно, клиент вместо обновления сертификата выполняет стандартную процедуру запроса сертификата с генерацией новой ключевой пары.
Примечание: здесь и далее. Если необходимый шаблон находится в выдаче более одного CA, клиент по очереди посылает запрос на каждый сервер CES в соответствии с их сортировкой.
Если версия шаблона (Major Version), который использовался при предыдущем энроллменте отличается от текущего Major Version шаблона, клиент посылает запрос на обновление сертификата. При этом запрос подписывается текущим сертификатом. Если в ответ на запрос был получен сертификат, клиент помещает его в список ToBeAdded.
Примечание: при каждом редактировании шаблона (кроме вкладки Security) изменяется только Minor Version. И держатели сертификатов этого шаблона не увидят, что шаблон изменён, поскольку они проверяют только Major Version.
В случае, если после внесения изменений в шаблон необходимо переиздать все сертификаты этого шаблона, администратор должен изменить Major Version. Для этого администратор в оснастке certtmpl.msc должен выбарть нужный шаблон, нажать правой кнопкой и выбарть Reenroll All Certificate Holders.
Если шаблон, который использовался при предыдущем энроллменте был заменён более новым (вкладка Superseded Templates нового шаблона содержит устаревший шаблон), клиент отправляет запрос на обновление сертификата. При этом запрос подписывается текущим сертификатом.
Если в реестре для текущего сертификата указан PolicyID, клиент будет пытаться найти тот же ID в списке политик CEP и запрос на обновление сертификата отправлять на сервер CES, который указан в политике. Если PolicyID для текущего сертификата не указан, запрос будет отправляться на тот сервер CES, политика которого является по умолчанию (см fig.2).
Для необработанных шаблонов клиент отправляет запросы на получение сертификатов на основе этих шаблонов.Если в ответ на запрос был получен сертификат, клиент помещает его в список ToBeAdded и записывает PolicyID, который использовался при энроллменте. Этот ID будет использоваться при обновлении сертификата.
Когда все запросы, сертификаты и шаблоны были обработаны, триггер автоэнроллмента очищает список ToBeDeleted и все сертификаты из списка ToBeAdded копирует в контейнер Personal.
Вопросы реализации
Если подходить с технологической точки зрения, то при создании собственного центра сертификации в первую очередь следует определить требуемый тип иерархии CA, что, в свою очередь, определяет необходимое количество серверов (меньше двух никак не получится). В табл.
Следует также определить, будете ли вы использовать внешний или собственный корневой CA. Выбирая известный внешний корневой CA, такой как VeriSign или Thawte, вы избавитесь от необходимости задавать явное внешнее доверительное отношение с этим корневым CA, добавляя его сертификат в свое хранилище.
Кроме того, не придется организовывать обмен корневыми сертификатами с другими участниками обмена документами. Это может оказаться весьма важным фактором, поскольку организация такого обмена — занятие достаточно трудоемкое, а сертификаты основных внешних сертификационных центров, как правило, есть везде.
Как видно из табл. 1, использование внешнего корневого CA избавляет нас от необходимости поддерживать сервер CA, но лишает гибкости в вопросе выбора политики сертификации, особенно это касается срока действия сертификата. Следует также принять во внимание стоимость приобретения сертификата уровня центра CA.
Хотя, как правило, цена такого сертификата меньше затрат на приобретение сервера, программного обеспечения и сопровождение сервера CA. Вне зависимости от выбранного типа инфраструктуры PKI, необходимо убедиться, что находящийся в вашем ведении CA высшего уровня работал в изолированном режиме, т. е. не был подключен ни к какой сети.
Эта мера позволяет снизить риск компрометации сервера или закрытого ключа каким-нибудь хакером. Если решено использовать собственный корневой CA, я рекомендую, чтобы промежуточные CA высшего уровня работали изолированно из тех же соображений безопасности.
Другое важное соображение, которое следует принять во внимание, — это срок действия пользовательских сертификатов и сертификатов CA. Как правило, срок действия пользовательских сертификатов в организации составляет от одного года до двух лет. Слишком длительный срок действия ключа повышает риск его компрометации, слишком короткий срок при повышении безопасности создает дополнительные неудобства для владельца ключа (плюс затраты, связанные с его обновлением и административные расходы).
Сертификаты уровня CA имеют более длительный срок действия, поскольку истечение срока действия сертификата CA автоматически означает прекращение действия всех выданных им сертификатов. В большинстве случаев срок действия сертификата CA устанавливается от двух до пяти сроков действия выданных им сертификатов.
Когда срок действия сертификата подходит к концу, выполняется обновление этого сертификата, и новый сертификат CA обрабатывает запросы на сертификацию. Как ориентировочные значения можно принять 20-летний жизненный цикл для корневого сертификата, промежуточные CA имеют срок действия 10 лет, выдающие CA — пять лет, но, конечно, эти значения могут варьироваться в зависимости от принятых в организации политик и бизнес-требований.
Далее требуется определить необходимую стойкость ключа шифрования для своих сертификатов. Чем больше длина ключа в битах, тем более стойким он считается и тем меньше вероятность, что он может быть вычислен с использованием математических методов. Обратной стороной медали в данном случае является длительное время, необходимое для создания или обновления сертификатов и расшифровки сообщений, зашифрованных асимметричным ключом.
Как работает cdp
Видя всё это безобразие, разработчики из VMware как-то сели крепко подумать и решили выпустить некое API, которое сейчас известно под именем VAIO. Фактически, это технология, позволяющая сделать классический I/O фильтр, который даёт возможность следить за I/O потоками гостевых машин и делать что-то с этим знанием.
Причём с момента включения этого фильтра ни один изменившейся на диске байт не останется без нашего внимания. А дальше дело за малым: берём эти блоки, копируем из одной машину в другую – и мы восхитительны. Буквально пара недель работы программистов, неделька на тестирование, и можно релизить.
Хотелось бы так, но нет. На практике всё несколько сложнее. Давайте разбираться.
Вот так выглядит общая схема работы. Для видавшего виды VBR пользователя здесь знакомо только слово Proxy. И, пожалуй, да, на прокси вся схожесть с классическими схемами работы и заканчивается.
Погнали по списку:
Координатор. Умывальников начальник и мочалок командир. Управляет всеми процессами, отвечает за связь с vCenter, говорит другим компонентам, что делать, и всячески следит, чтобы всё было хорошо. На местах выглядит как Windows сервис. Единственный, кто знает про существование таких вещей, как vCenter и виртуальные машины. Все остальные работают только с дисками. Поэтому всё, что не связано с репликацией контента, делает координатор. Например, создаёт виртуалку на таргете, к которой мы прицепим реплицируемые диски.
Source filter. Та самая штука, которая занимается перехватом IO запросов. Соответственно, работает уже на ESXi. Дабы повысить надёжность и производительность, один инстанс фильтра работает с одним виртуальным диском. Фильтры держат связь с демоном.
Технически, фильтр – это библиотека, живущая внутри процесса виртуальной машины. И если с ним что-то случается (залипла память, скрешился и т.п.), то следом прилетает виртуалке, внутри которой он работает. Поэтому жизнеспособности фильтров было уделено огромное внимание. Ну и если вы сомневаетесь по поводу прямоты рук создателей фильтра: такие штуки можно устанавливать на хосты только после прохождения строгой сертификации получившегося изделия со стороны VMware.
Важно:VBR производит установку на кластер. Довести фильтр до каждого хоста – это уже задача самой VMware. Причём если вы добавляете новую ноду в кластер, то наш бандл на него будет установлен автоматически. Зачем? Давайте представим, что произойдёт, если в кластере появится новая нода и для какой-то из машин сработает vMotion на эту ноду? Всё верно – CDP реплика сломается. Однако вся эта автоматика не отменяет необходимости пройти через Manage I/O filters визард – для актуализации настроек. Поэтому, если добавили ноду, то быстренько проходим “Manage I/O filters” визард, который обнаружит новичка и всё настроит.
Source Daemon. Используется один на каждый хост. В отличие от мифического фильтра, который где-то там работает, демон – это вполне конкретный процесс на хосте. Отвечает за связь с координатором и общается с прокси на предмет поиска оптимального маршрута трафика. Работает по медленному TCP, так как шустрый UDP не гарантирует доставку. И да, это именно тот случай, где это критично и необходимо.
Зачем нужна прокладка в виде демона и почему бы фильтру самому не работать с прокси? Это ограничение технологии со стороны VMware, не позволяющее фильтру работать с внешней сетью. То есть фильтр с демоном связь установить может, а с прокси нет. Это называется by design, и ничего с этим не поделаешь. Во всяком случае, сейчас. И напомню: демон не знает ни про какие виртуальные машины. Он работает с потоками данных от дисков. И ничего другого в его мире не существует. Поэтому диски одной машины могут обрабатываться сразу несколькими прокси. Мы, конечно, стараемся отвозить диски одной машины через один прокси, но если она не справляется, то подключится другая. И это нормально!
Source Proxy. Агрегирует в себе всю информацию, полученную от фильтров через демонов. Хранит всё строго в RAM, с возможностью подключения дискового кэша, если оперативка кончилась. По этому очень (ОЧЕНЬ!) требователен к RAM, дисковому кешу и задержкам на сети. Так что только SSD и прочее адекватное железо.
Прокси занимается составлением так называемых микроснапшотов, которые отправляются дальше. Данные перед передачей обязательно дедуплицируются: если в каком-то секторе произошло 100500 перезаписей, то до прокси дойдут все, но с самого прокси будет отправлена только одна последняя. Так же, само собой, всё сжимается и шифруется.
На местах прокси представляют собой Windows машины, которые могут взаимозаменять друг друга, переключать нагрузку и так далее.
Target Proxy. Всё то же самое, но в обратном порядке. Принимает трафик от сорсных проксей, расшифровывает, разжимает, отправляет дальше. Так же может быть как физический, так и виртуальный.
Target Daemon. Занимается записью данных на датастор. Полная копия сорсного демона.
Target Filter. В нормальном состоянии находится в выключенном виде. Начинает работать только во время фейловера и фейлбека, но об этом позже.
Таргетные компоненты от сорсных в данном случае отличаются только названием и своим местом в логической схеме. Технически они абсолютно идентичны и могут меняться ролями на ходу. И даже одновременно работать в двух режимах, чтобы одна машина реплицировалась с хоста, а другая на хост.
Немного о прокси
И хотя кажется, что прокси серверам в схеме CDP отведена роль тупых молотильщиков трафика, без их успешного взаимодействия всё остальное теряет смысл. И задачи там решаются достаточно серьёзные, так что не будем принижать их вклад в общее дело.
Что хочется сказать про этих ребят:
Дисковый кеш – это исключительно запасной план на случай закончившейся оперативки. Всё придумано и сделано так, будто находится исключительно в RAM. Поэтому, пожалуйста, не жадничайте и дайте серверам памяти.
Не надо заставлять один и тот же прокси сервер выступать в роли сорсного и таргетного. Ничего хорошего из этого не выйдет. Запретить вам так сделать мы не можем, однако будем долго отговаривать.
В идеальном мире на один ESXi – один прокси.
А вот физический или виртуальный на том же хосте – этого вам никто не скажет, и надо тестировать. Часто бывает, что виртуальный оказывается быстрее физического.
Да и вообще, общая логика такова, что чем больше вы сможете развернуть прокси серверов, тем лучше будет результат. Особенно если речь идёт о репликации между удалёнными дата центрами.
Также самые внимательные заметят, что на шаге назначения проксей есть кнопка Test с таинственным набором цифр внутри.
Давайте разбираться что же это такое и откуда оно взялось. Все эти скорости и количества являются ничем иным, как усреднёнными максимумами за последний час, полученными от vCenter. То есть это не мы что-то там померили в моменте, ловко запустив какие-то таинственные тесты, а такова родная статистика хостов за последний час.
Давайте теперь пройдёмся по строчкам.
Source Proxy CPU: количество ядер CPU на всех доступных проксях, которые могут работать в качестве сорса. Видим vCPU, но читаем как ядра CPU.
Source Proxy RAM. Здесь уже посложней будет. Цифра перед скобками показывает, сколько оперативки нам может понадобиться для данной CDP политики.
Формула расчёта довольно простая: RPO* пропускную способность.
Пропускную способность кого/чего? Да всех дисков всех вируталок, участвующих в этой политике. Напоминаю, что берётся максимальное значение за последний час.
То есть предположим, что наш RPO – 15 секунд, и что диски выдают 150 Мб/сек. Значит, нам понадобится 2250 Мб RAM.
А цифра в скобках – это вся доступная оперативка на всех наших проксях, Но, как обычно, есть нюансы. Во-первых, половина RAM считается зарезервированной под нужды ОС и других приложений. Это можно подправить ключиком в реестре в любую сторону (сие остаётся полностью на вашей совести).
Во-вторых, учтите, что в случае возникновения задержек на сети или задумчивости хранилища, данные будут сохраняться в кеше до двух минут, после чего будет включена аварийная сирена. И если в течение этих двух минут память переполнится, то подключится медленный дисковый кэш.
Source Proxy Bandwidth. Здесь опять всё просто. Число перед скобками мы получаем от vCenter, а число в скобках считается на основе доступного количества ядер с округлением до целого. Если мы шифруем трафик, то это 150 Мб/с на ядро. Если не шифруем, то 200 Мб/с на ядро.
Target Proxy CPU. Всё ровно так же, как у сорса: взяли и посчитали все доступные ядра на доступных проксях.
Target Proxy RAM. Хочется, как и в предыдущем пункте, сказать, что всё такое же, но нет. Здесь в формулу для расчёта внесён поправочный коэффициент 0.5. А значит, что если мы за те же 15 секунд хотим обработать 150 Мб/c от дисков, то понадобится нам уже только 1125 RAM (вместо 2250, как это было с сорсом).
Target Proxy Bandwith. Здесь тоже не обошлось без скидок. Считаем, что одно ядро при шифровании трафика будет обрабатывать 350 Мб/c, а без шифрования – все 400 Мб/c.
И помним важное: таргет и прокси меняются ролями в момент фейловера. То есть вся схема начинает работать в обратную сторону. Поэтому на таргете и есть неактивный фильтр, который оживает в момент фейловера. А фильтр на бывшем сорсе, соответственно, выключается.
Установка серверов ca
В первую очередь устанавливается сервер ROOTCA, затем SUBCA и, наконец, сервер ISSUING. В целом процесс практически одинаков для каждого из трех CA; в табл. 2 приведены отличия в установке этих серверов, которая была произведена для построения трехуровневой иерархии нашего примера.
Для начала установки каждого из наших CA в приложении «Установка/удаление программ» в панели управления выберите закладку «Установка компонентов Windows». Выберите Certificate Services и нажмите Next. В диалоговом окне с предупреждением о том, что вы не можете изменить имя сервера или его членство в домене, следует нажать Yes.
Далее предлагается установить уровень авторизации сертификата (Certification Authority Type). Выберите тип CA в соответствии со значениями, приведенными в табл 2. После выбора типа CA отметьте флажок Advanced options (Дополнительно), как показано на экране 1, и нажмите Next (Далее). Параметр Enterprise CA будет недоступен, если компьютер не является членом домена AD.
Мастер Windows Components Wizard позволяет задать параметры пары открытый/закрытый ключ, а также выбрать провайдера службы шифрования Cryptographic Service Provider (CSP) и алгоритм, используемый для шифрования и формирования электронной подписи. Выбор различных поставщиков CSP и алгоритмов шифрования обеспечивает разные возможности, в том числе учет экспортных требований по криптостойкости ключей шифрования и поддержку внешних устройств, таких как смарт-карты для хранения ключей.
Обычно, если у пользователя нет каких-то специфических требований, можно оставить значение по умолчанию (Microsoft Base Cryptographic Provider 1.0 и SHA-1). Далее мастер позволяет установить длину ключа в соответствии со значениями, приведенными в табл. 2, после чего следует нажать Next.
На странице CA Identifying Information (Идентификация CA), изображенной на экране 2, указывается информация, которая должна быть включена в сертификат, а также информация, которую операторы CA смогут использовать для проверки полномочий при выдаче подтверждения или отказа в ответ на запрос на сертификацию.
Наиболее важным на этой станице является параметр CA name. Имя должно быть уникальным, подсистема безопасности использует его для определения местоположения соответствующего родительского сертификата в цепочке сертификации. Другие поля позволяют идентифицировать организацию (эта информация может совпадать для всех CA).
Последнее поле указывает срок действия данного корневого сертификата. Поскольку корневой CA сертифицирует сам себя, этот параметр доступен только через интерфейс ROOTCA. Продолжительность жизни сертификатов подчиненных и выдающих CA зависит от продолжительности действия родительского CA и управляется через системный реестр на серверах ROOTCA и SUBCA соответственно. Более подробно об этом будет рассказано ниже.
Для продолжения работы мастера нужно нажать Next. Процедура установки сформирует криптографический ключ и предложит указать местоположение для файлов базы данных, используемой службой сертификатов Certificate Service. Мастер позволяет разделить первичную (primary) базу данных и журнал базы транзакций.
Я рекомендую, чтобы эти файлы были размещены на различных разделах. Помимо размещения файлов базы данных необходимо указать папку общего доступа для организации точки доступа к информации авторизации Authority Information Access (AIA) для получения сертификата CA.