Рекомендации

Хранилище безопасно, но не настолько, как лист бумаги в банковском хранилище. В конце концов, это сетевое программное обеспечение. Если ваш корневой CA размещен за пределами StarVault, не помещайте его в StarVault; вместо этого выпустите сертификат промежуточного CA с более коротким сроком действия и поместите его в StarVault. Это соответствует лучшим отраслевым практикам.

Механизм секретов поддерживает генерацию самоподписанных корневых CA, а также создание и подписание CSR для промежуточных CA. В каждом случае, по соображениям безопасности, закрытый ключ можно экспортировать только во время генерации, и возможность сделать это является частью командного пути (поэтому ее можно внести в политики ACL).

Если вы планируете использовать промежуточные CA с StarVault, рекомендуется разрешить StarVault создавать CSR и не экспортировать закрытый ключ, а затем подписывать их с помощью корневого CA (который может быть вторым монтированием механизма pki secrets).

Механизм секретов PKI поддерживает несколько эмитентов в одном монтировании. Однако для упрощения конфигурации настоятельно рекомендуется, чтобы операторы ограничивали монтирование одним сертификатом. Если вы хотите выпускать сертификаты от нескольких разных CA, смонтируйте механизм секретов PKI в нескольких точках монтирования с отдельными сертификатами CA в каждой.

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

Общим шаблоном является использование одного монтируемого центра в качестве корневого CA и использование этого CA только для подписи промежуточных CA CSR от других секретных механизмов PKI.

Чтобы сохранить старые CA активными, существует два подхода к обеспечению ротации:

Еще один вариант использования нескольких эмитентов в одном монтировании — разделение выпуска по времени жизни TTL. Для сертификатов с коротким сроком действия промежуточный ключ, хранящийся в StarVault, часто превосходит промежуточный ключ, хранящийся в HSM. Однако для сертификатов с большим сроком действия часто важно, чтобы промежуточный ключевой материал был защищен в течение всего срока действия сертификата конечного субъекта. Это означает, что два промежуточных устройства в одном и том же хранилище - одно с поддержкой HSM и одно с поддержкой StarVault - могут удовлетворять обоим вариантам использования. Операторы могут задавать роли, устанавливающие максимальные TTL для каждого эмитента, потребители монтирования могут решать, что использовать.

Некоторые типы ключей влияют на производительность. Подписание сертификатов с помощью ключа RSA будет медленнее, чем при выпуске с помощью ключа ECDSA или Ed25519. Генерация ключей (с помощью конечных точек /issue/:role) с использованием ключей RSA также будет медленной: Генерация ключей RSA включает в себя поиск подходящих случайных простых чисел, в то время как ключи Ed25519 могут быть случайными данными. С увеличением количества бит (RSA 2048 → 4096 или ECDSA P-256 → P-521) время подписи также увеличивается.

Это имеет значение в обоих направлениях: дороже не только выдача, но и проверка соответствующей подписи (скажем, в TLS). Тщательное рассмотрение типов ключей как эмитента, так и выданных сертификатов может оказать значительное влияние на производительность не только StarVault, но и систем, использующих эти сертификаты.

Обычно рекомендуется использовать иерархическую структуру CA, с корневым сертификатом, который выдает один или несколько промежуточных (в зависимости от использования), которые, в свою очередь, выдают leaves сертификаты.

Это позволяет усилить гарантии хранения или политики защиты корневого CA, в то же время позволяя StarVault управлять промежуточными CA и выдачей leaves. Разные промежуточные центры могут выдаваться для разных целей, например для подписи VPN, подписи электронной почты или тестирования в сравнении с производственными службами TLS. Это помогает ограничить CRL конкретными целями: например, VPN-службам не важен отозванный набор сертификатов подписи электронной почты, если они используют отдельные сертификаты и разных посредников, и поэтому им не нужно содержимое обоих CRL. Кроме того, это позволяет посредникам с повышенным риском (например, выпускающим сертификаты подписи электронной почты с большим сроком действия) иметь HSM-поддержку, не влияя на производительность более простых в обращении посредников и сертификатов (например, TLS-посредников).

StarVault поддерживает использование параметра allowed_domains для ролей и параметра permitted_dns_domains для установки расширения Name Constraints для корневого и промежуточного поколений. Это позволяет на нескольких уровнях разделить проблемы между службами на основе TLS.

В StarVault есть поддержка шаблонизированных URL-адресов AIA. При конфигурации URL-адреса для каждого кластера, указывающего на этот кластер Performance Replication, информация AIA будет автоматически указывать на кластер, выпустивший этот сертификат.

В StarVault, с поддержкой ACME, такая же конфигурация используется для того, чтобы клиенты ACME могли обнаружить URL этого кластера.

В движок PKI Engine добавлена поддержка протокола Automatic Certificate Management Environment (ACME). Это стандартизированный способ обработки проверки, выдачи, ротации и отзыва сертификатов сервера.

Многие экосистемы, от веб-серверов, таких как Caddy, Nginx и Apache, до сред оркестровки, таких как Kubernetes (через cert-manager), поддерживают выдачу сертификатов по протоколу ACME. Для развертываний без встроенной поддержки существуют отдельные инструменты, такие как certbot, поддерживающие получение и обновление сертификатов от имени потребителей. StarVault’s PKI Engine включает только серверную поддержку ACME; клиентская функциональность не предусмотрена.

Этот механизм секретов соответствует философии StarVault о недолговечности секретов. Поэтому не ожидается, что CRL будут разрастаться; единственный способ возврата закрытого ключа - это передача его запрашивающему клиенту (этот механизм секретов не хранит сгенерированные закрытые ключи, за исключением сертификатов CA). В большинстве случаев, если ключ утерян, сертификат можно просто проигнорировать, так как срок его действия истечет в ближайшее время.

Если сертификат действительно должен быть отозван, можно использовать обычную функцию отзыва StarVault, и любое действие по отзыву приведет к перегенерации CRL. Когда CRL перегенерируется, все сертификаты с истекшим сроком действия удаляются из CRL (а все отозванные сертификаты с истекшим сроком действия удаляются из хранилища механизма секретов). Это дорогостоящая операция! Из-за структуры стандарта CRL StarVault должен считать все отозванные сертификаты в память, чтобы перестроить CRL, а клиенты должны получить обновленный CRL.

Этот механизм секретов не поддерживает несколько конечных точек CRL со скользящими окнами дат; часто такие механизмы имеют точку перехода с разницей в несколько дней, но это попадает в ожидаемую область фактических сроков действия сертификатов, выдаваемых этим механизмом секретов.

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

Часто используется несколько конечных точек в случае, если одна конечная точка CRL не работает, чтобы клиентам не приходилось решать, что делать в случае отсутствия ответа. Запустите StarVault в режиме HA, и конечная точка CRL должна быть доступна, даже если определенный узел не работает.

Этот механизм секретов обслуживает CRL из предсказуемого места, но механизм секретов не может знать, где он запущен. Поэтому необходимо настроить нужные URL-адреса для сертификата-эмитента, точек распространения CRL и серверов OCSP вручную с помощью конечной точки config/urls. Поддерживается возможность использования более одного из них путем передачи нескольких URL в качестве строкового параметра, разделенного запятой.

И CRL, и OCSP позволяют проверить статус отзыва сертификатов. Оба эти метода включают в себя внутреннюю безопасность и аутентичность (ответы и CRL, и OCSP подписываются выдавшим их CA внутри StarVault). Это означает, что оба метода можно распространять по небезопасным и неаутентифицированным каналам, таким как HTTP.

PKI Secrets Engine поддерживает автоматическое создание CRL (включая опциональные Delta CRL, которые могут создаваться чаще, чем полные CRL) через конечную точку /config/crl. Кроме того, через конечную точку /config/auto-tidy можно автоматически настраивать очистку отозванных и просроченных сертификатов. Обе эти функции должны быть включены, чтобы обеспечить совместимость с более широкой экосистемой PKIX и производительность кластера.

Механизм секретов PKI способен поддерживать различные размеры кластеров и количество аннулированных сертификатов.

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

Если единый CRL становится слишком большим для базового механизма хранения или для отдельного узла, мы рекомендуем использовать OCSP вместо CRL. Они содержат гораздо меньше записей, а флаг disabled CRL не зависит от unified_crls, что позволяет сохранить унифицированный OCSP.

Однако, если кросс-кластерный трафик становится слишком большим (или если CRL все еще необходимы в дополнение к OCSP), мы рекомендуем разделить CRL между разными кластерами. Это было стандартным поведением StarVault, но с введением шаблонизированной информации AIA для каждого кластера, информация Authority Information Access (AIA) сертификата листа будет указывать непосредственно на кластер, который его выпустил, что позволит приложению определить правильный CRL для этого сертификата. Это более точно имитирует поведение разделения CRL в Let’s Encrypt.

Такое разделение можно использовать и для OCSP, если кросс-кластерный трафик для записей об отзыве становится слишком большим.

Для пользователей, которые хотят управлять отзывом вручную, использование журналов аудита для отслеживания выпуска сертификатов позволит внешней системе определить, какие сертификаты были выпущены. Их можно вручную отследить на предмет отзыва, а также создать собственный CRL, используя отслеженные извне отзывы. Это позволит использовать роли, установленные на no_store=true, так что StarVault будет использоваться только как орган выдачи и не будет хранить никаких сертификатов, выпущенных или отозванных. Для самых больших объемов отзыва это может быть лучшим вариантом.

Библиотека Go x509 имеет свой механизм разбора и структурирования субъектов сертификата. С эмитентами, созданными в StarVault, все в порядке, но при использовании сертификатов CA, созданных извне, они могут быть разобраны неправильно во всех частях PKI. В частности, CRL содержат (измененную) копию имени эмитента. Этого можно избежать, используя OCSP для отслеживания отзыва, но учтите, что характеристики производительности у OCSP и CRL разные.

Чтобы управлять сертификатами для служб в масштабе, лучше всего автоматизировать обновление сертификатов, насколько это возможно. StarVault Agent поддерживает автоматическое обновление запрошенных сертификатов на основе поля validTo. Другие решения могут включать использование cert-manager в Kubernetes или OpenShift, подкрепленного CA StarVault.

С момента своего создания этот механизм секретов использует SHA256 для хэшей подписей, а не SHA1. Для ключей RSA также используется минимум 2048 бит. Программное обеспечение, способное работать с подписями SHA256, должно также уметь работать с 2048-битными ключами, а 1024-битные ключи считаются небезопасными и запрещены в Интернет PKI.

Когда срок действия токена истекает, он аннулирует все связанные с ним аренды. Это означает, что долгоживущие CA-церты нуждаются в соответствующих долгоживущих токенах, о чем легко забыть. Корневые и промежуточные сертификаты CA не имеют связанных с ними аренд, чтобы предотвратить непреднамеренный отзыв, если не используется токен с достаточно большим сроком действия. Чтобы отозвать эти сертификаты, используйте конечную точку pki/revoke.

Механизм секретов StarVault PKI поддерживает множество опций для ограничения выдачи через роли. Необходимо тщательно продумать конструкцию, чтобы убедиться, что не дается больше разрешений, чем необходимо. Кроме того, роли, как правило, должны выполнять одну задачу; несколько ролей предпочтительнее, чем слишком свободные роли, позволяющие произвольную выдачу (например, allow_any_name следует использовать редко, если вообще использовать).

Помимо стандартной телеметрии StarVault по обработке запросов, PKI предоставляет метрики количества и длительности для вызовов issue, sign, sign-verbatim и revoke. Ключи метрик имеют вид mount-path,operation,[failure] с метками для имени роли.

Обратите внимание, что эти метрики рассчитаны на один узел, поэтому их необходимо агрегировать по узлам и кластерам.

Поскольку по умолчанию StarVault HMAC проверяет строковые ключи, необходимо настроить монтирование секретов PKI, чтобы получить точное представление о выдаче, происходящей под этим монтированием.

Ниже приведены некоторые предлагаемые ключи для отмены HMAC для запросов:

Ниже приведены некоторые предлагаемые ключи для отмены HMAC для ответов:

Следующие ключи рекомендуется не использовать в un-HMAC из-за их чувствительности:

StarVault поддерживает ACL-политики на основе путей для ограничения доступа к различным путям в StarVault.

Ниже приведен сжатый пример ACL для механизма PKI Secrets Engine. Это всего лишь предложение; могут быть использованы и другие персоны и подходы к политике.

Предлагаются следующие роли:

Для этих ролей предлагаются следующие ACL в сжатой табличной форме:

При работе с кластерами Performance Secondary некоторые наборы данных поддерживаются во всех кластерах, а другие по соображениям производительности и масштабируемости хранятся в пределах одного кластера.

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

Основной эффект заключается в том, что в механизме секретов PKI листовые сертификаты, выпущенные с параметром no_store равным false, хранятся локально в кластере, который их выпустил. Это позволяет активному узлу как первичного, так и вторичного кластеров Performance Secondary выдавать сертификаты для большей масштабируемости. В результате эти сертификаты и любые их аннулирования видны только на кластере, выдавшем их. Это дополнительно означает, что каждый кластер имеет свой собственный набор CRL, отличный от других кластеров. Эти CRL должны быть либо объединены в один CRL для распространения с одного URI, либо операторы сервера должны знать, как получить все CRL со всех кластеров.

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

*Только если для соответствующей роли установлено значение no_store - true и generate_lease - false. Если значение generate_lease равно true, создание аренды будет передано активному узлу; если значение no_store равно false, весь запрос будет передан активному узлу.

В Go отсутствует поддержка PSS-сертификатов, ключей и CSR, использующих идентификатор rsaPSS OID (1.2.840.113549.1.1.10). Он требует, чтобы все RSA-сертификаты, ключи и CSR использовали альтернативный идентификатор rsaEncryption OID (1.2.840.113549.1.1.1).

При использовании OpenSSL для генерации CA или CSR из PKCS8-кодированных ключей PSS, полученные CA и CSR будут иметь идентификатор rsaPSS. Go и StarVault отвергнут их. Вместо этого используйте OpenSSL для генерации или преобразования в файл закрытого ключа PKCS#1v1.5 и используйте его для генерации CSR. В зависимости от роли и механизма подписания StarVault все равно будет использовать подпись PSS, несмотря на OID rsaEncryption в запросе, поскольку поля SubjectPublicKeyInfo и SignatureAlgorithm ортогональны. При создании внешнего CA и импорте его в StarVault убедитесь, что идентификатор rsaEncryption OID присутствует в поле SubjectPublicKeyInfo, даже если алгоритм подписи основан на PSS.

Эти сертификаты, сгенерированные Go (с OID rsaEncryption, но с подписями на основе PSS), в остальном совместимы с сертификатами, полностью основанными на PSS. OpenSSL и NSS поддерживают разбор и проверку цепочек с использованием этого типа сертификатов. Обратите внимание, что некоторые реализации TLS могут не поддерживать сертификаты этого типа, если они не поддерживают схемы подписи rsa_pss_rsae_*. Кроме того, некоторые реализации позволяют сертификатам rsaPSS OID содержать ограничения на параметры подписи, разрешенные этим сертификатом, но Go и StarVault не поддерживают добавление таких ограничений.

На данный момент в Go отсутствует поддержка подписи CSR с помощью алгоритма подписи PSS. При использовании управляемого ключа, требующего алгоритма RSA PSS (например, PKCS#11 HSM) в качестве основы для ключа промежуточного ЦС, попытка сгенерировать CSR (через pki/intermediate/generate/kms) не пройдет проверку подписи. В этом случае CSR нужно будет сгенерировать вне StarVault, а подписанный итоговый сертификат можно импортировать в монтировку.

В Go также отсутствует поддержка создания ответов OCSP с алгоритмом подписи PSS. StarVault автоматически понижает рейтинг эмитентов с алгоритмами подписи отзыва на основе PSS до PKCS#1v1.5, но следует учитывать, что некоторые устройства KMS (например, HSM) могут не поддерживать этот алгоритм с тем же ключом. В результате ответчик OCSP может не подписывать ответы, возвращая внутреннюю ошибку.

Движок секретов PKI имеет полный HTTP API. Более подробную информацию см. в разделе API движка PKI secrets.