Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Что такое закрепление сертификата?
Закрепление сертификатов — это метод безопасности, который ограничивает, какие сертификаты или центры сертификации (CA) принимают клиент при создании защищённой сессии. Клиент доверяет только специально закрепленным сертификатам или эмитентам и отклоняет другие сертификаты. Сообщество специалистов по безопасности изначально внедрило пиннинг, чтобы защититься от атак типа «человек посередине» (MITM), особенно после громких компрометаций центров сертификации.
Закрепление сертификатов и публичный веб-PKI
Эта статья посвящена публично доверенным серверным TLS-сертификатам, выданным через публичную Web PKI.
Глобальная экосистема CA, браузерных корневых программ, отраслевых стандартизаторов и производителей операционных систем управляет публичным Web PKI. Цепочки сертификатов, выдающие CA, якоря доверия и сроки службы сертификации эволюционируют со временем в ответ на инциденты с безопасностью, требования к соответствию и изменения в экосистеме.
Эти рекомендации не применяются к частным PKI или другим контролируемым трастовым средам, где организация владеет полным жизненным циклом сертификатов, моделью распределения доверия и процессом реагирования на инциденты.
Почему статическое закрепление больше не рекомендуется для публично доверенных сертификатов
Хотя когда-то закрепление сертификатов было лучшей практикой, сфера безопасности эволюционировала. Сегодня Microsoft, AWS, DigiCert, Cloudflare, Google и организации по безопасности, такие как OWASP, в целом не рекомендуют статический пиннинг (жёсткое задание сертификатов или центров сертификации в коде или конфигурации).
Главная проблема не в том, что закрепление сертификатов неэффективно. Напротив, в публичном веб-PKI это часто приносит больше операционных рисков, чем пользы безопасности.
- Операционный риск: Вам нужно регулярно менять сертификаты и CA для обеспечения безопасности и соответствия. Статическое закрепление затрудняет эти изменения, приводя к сбоям сервиса при обновлении или замене сертификатов.
- Недостаток ловкости: Публичный веб-PKI постоянно развивается. Экосистема может внедрять новые корни, промежуточные компоненты, профили сертификатов и требования к доверию в рамках нормальной работы. Закреплённые приложения могут не работать, если они не обновляются в соответствии с этими изменениями.
- Сложность и сопровождение: Управление и обновление пинов в распределённых приложениях связаны с высоким риском ошибок и плохо масштабируются. Несвоевременное обновление PIN-кодов может привести к нарушению работы сервиса.
- Консенсус отрасли: Крупные облачные провайдеры и органы по стандартам безопасности теперь рекомендуют не фиксировать статическое закрепление для публично доверенных сертификатов, за исключением редких и строго контролируемых случаев.
Руководство по Azure
Azure не рекомендует статическое закрепление публично доверенных сертификатов TLS-сервера.
Приложения, подключающиеся к сервисам Azure, должны полагаться на стандартную TLS-валидацию, управляемые платформой хранилища доверия, прозрачность сертификатов и другие современные защиты Web PKI, а не закреплять публично доверенные сертификаты или центры сертификации.
Публичный веб-PKI управляется внешне и меняется со временем. Вы не можете контролировать, когда центры сертификации меняют ключи, когда корневые программы браузера обновляют требования доверия, когда меняются цепочки сертификатов или когда экосистемные события безопасности требуют быстрого реагирования. Статическое закрепление создает зависимости от этих внешних компонентов и может привести к сбоям сервиса при изменениях.
Когда уместно закрепление
Не воспринимайте это руководство как рекомендацию против всех форм закрепления сертификатов.
Закрепление может быть действительным контролем безопасности, когда организация, развертывающая систему, контролирует всю модель доверия и жизненный цикл сертификатов. Вот некоторые примеры:
- Частные PKI
- Иерархии корпоративных доверий
- Системы идентификации устройств
- Контролируемые среды взаимной аутентификации
В таких случаях организация несёт на себя соответствующий операционный риск и может координировать изменения жизненного цикла сертификата в пределах собственной границы доверия.
Риски и ограничения статического закрепления
- Сбои в работе служб: Закрепленные приложения могут перестать работать при ротации, отзыве, замене сертификатов или их переносе в новые иерархии центров сертификации.
- Нагрузка на сопровождение: Поддержание закреплённых элементов в актуальном состоянии требует постоянного мониторинга и оперативного обновления.
- Сниженная маневренность: Статическое закрепление может задерживать или блокировать улучшения безопасности, миграции сертификационных центров и изменения доверия, вызванные экосистемами.
- Ограниченная гарантия безопасности: Публичные облачные сервисы могут использовать общие сертификационные центры. Привязка к общедоступному центру сертификации не гарантирует исключительности и может не обеспечить ожидаемого повышения безопасности.
Связанные материалы
- Сведения о центрах сертификации Azure
- OWASP: привязка сертификатов и открытых ключей
- Разработчик Apple: закрепление идентичности
- Лучшие практики менеджера сертификатов AWS
- Cloudflare: Как избежать простоев: современные альтернативы устаревшим практикам закрепления сертификатов
- Chromium: намерение устарить и удалить закрепление публичных ключей
- DigiCert: Отключите пиннинг сертификатов