HSM, KMS и программное хранение ключей CA и сервисной подписи

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

На практике команды выбирают между тремя основными моделями: аппаратным модулем HSM, управляемым сервисом KMS и программным хранением, при котором закрытый ключ в некоторый момент оказывается в памяти приложения. Эти варианты нельзя расположить на одной шкале от «плохого» к «хорошему»: они создают разные границы доверия, накладывают разные ограничения и подходят для разных ролей внутри PKI.

Что именно необходимо защитить

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

• Корневой ключ CA находится на вершине цепочки доверия. Его компрометация требует сложного восстановления доверия, поэтому приоритетами становятся изоляция, строгий контроль доступа и минимальное число операций. Высокая производительность обычно не нужна.
• Ключ выпускающего CA подписывает сертификаты конечных субъектов или нижестоящих CA. Он используется чаще корневого и обычно должен быть доступен онлайн, поэтому к защите добавляются требования по высокой доступности и контролю темпа выпуска.
• Ключ сервисной подписи может подписывать токены, пакеты, образы, конфигурации, webhook-запросы или другие прикладные объекты. Для него часто критичны задержка, пропускная способность и интеграция с приложением.
• Ключи конечных сервисов обычно многочисленны и имеют меньший радиус поражения. Для них может быть оправдана более дешёвая модель защиты при условии короткого срока жизни и автоматической ротации.

Одинаковое хранилище для всех ролей упрощает схему только внешне. Оно либо делает массовые операции слишком дорогими, либо ослабляет защиту наиболее критичных ключей. Зрелая архитектура обычно использует несколько уровней: например, изолированный корневой CA, защищённый онлайн-ключ выпускающего CA и отдельные ключи сервисной подписи с собственными политиками.

Главное различие: где проходит криптографическая граница

Ключевой вопрос звучит так: может ли операционная система или процесс приложения получить закрытый ключ в открытом виде?

В HSM генерация и операции подписи выполняются внутри криптографического модуля. Приложение передаёт данные или их хеш и получает результат. Если ключ создан как неизвлекаемый, штатный интерфейс не позволяет получить его открытый материал. Именно аппаратный модуль становится границей, отделяющей ключ от сервера, его памяти и администраторов ОС.

В managed KMS приложение также вызывает удалённую операцию через API и обычно не получает материал ключа. Однако граница принадлежит облачному провайдеру. Конкретная стойкость зависит от класса сервиса: ключ может обслуживаться программной криптографической системой провайдера, аппаратным модулем или выделенным HSM. Само слово KMS не гарантирует аппаратной защиты.

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

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

HSM: максимальная изоляция при высокой операционной цене

HSM — специализированный криптографический модуль, рассчитанный на генерацию, хранение и использование ключей внутри контролируемой аппаратной границы. Это может быть локальное устройство, сетевой модуль или аппаратная услуга провайдера. Приложения взаимодействуют с ним через поддерживаемый API, часто через интерфейс PKCS#11 либо интеграцию конкретного производителя.

Экспорт и резервное копирование

Основное преимущество HSM — возможность пометить ключ как неизвлекаемый и выполнять подпись без передачи закрытого материала на хост. Но «неизвлекаемый» не всегда означает «не подлежащий резервированию». Для высокой доступности и аварийного восстановления производители могут поддерживать защищённое клонирование, репликацию разделов или экспорт резервной копии под ключом обёртывания. Такие механизмы нельзя приравнивать к экспорту открытого ключевого материала, однако они должны быть включены в модель угроз.

До создания ключа необходимо определить, как будет восстанавливаться кластер, кто контролирует резервные токены или ключи обёртывания и можно ли перенести объект между совместимыми устройствами. Ошибка здесь обнаруживается слишком поздно — при отказе оборудования или миграции.

Доступ и аудит

HSM позволяет отделить управление устройством от использования ключа. Можно разнести роли администратора, оператора резервного копирования и клиента подписи, а критические действия проводить с участием нескольких ответственных лиц. Однако полнота аудита зависит не только от устройства. Обычно нужны как минимум три слоя событий:

• аутентификация, изменение разделов и политик внутри HSM;
• вызовы криптографического API со стороны клиента или шлюза;
• бизнес-события PKI: кто запросил сертификат или подпись, по какой политике и с каким результатом.

Журнал HSM может подтвердить факт операции, но не всегда знает её прикладной смысл. Поэтому устройство не заменяет аудит CA или сервиса подписи.

Производительность и доступность

Пропускная способность зависит от модели устройства, алгоритма, размера ключа, сетевого режима и числа разделов. Перед покупкой важно тестировать реальный профиль: генерацию ключей, RSA- или ECDSA-подпись, параллельность, установление сессий и поведение при переключении между узлами.

Один HSM создаёт критическую точку отказа. Для онлайн-CA или высоконагруженной подписи обычно необходимы несколько модулей, синхронизация ключей, резервные клиентские маршруты и проверенная процедура переключения. Наличие второго устройства ещё не означает готовность к отказу: клиентская библиотека может удерживать неработающую сессию, а репликация — требовать ручной операции.

Когда HSM оправдан

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

Слабой стороной HSM становится не криптография, а сложность эксплуатации. Ошибочная политика, общий PIN, незащищённый клиентский сервер или отсутствие контроля запросов подписи способны свести пользу аппаратной границы к минимуму.

Managed KMS: неизвлекаемые ключи без собственного оборудования

Облачный KMS предоставляет операции с ключами через API. Провайдер отвечает за инфраструктуру сервиса, а клиент управляет идентификаторами ключей, правами, политиками, версиями и журналированием. Некоторые продукты предлагают разные уровни защиты: программный, HSM-backed или выделенный аппаратный.

Что означает «ключ не экспортируется»

В типичной схеме приложение не получает закрытый ключ и вызывает операцию подписи удалённо. Но при выборе сервиса нужно проверить происхождение ключа и правила его жизненного цикла:

• сгенерирован ли ключ внутри KMS или импортирован клиентом;
• какой уровень защиты назначен конкретной версии;
• возможен ли экспорт и в какой форме;
• как создаются резервные копии и реплики;
• можно ли восстановить удалённый ключ;
• какие алгоритмы, параметры и форматы подписи поддерживаются.

Маркетинговые термины вроде «customer-managed key» обычно описывают управление политикой и жизненным циклом, а не физическое владение модулем. Их нельзя использовать как доказательство того, что ключ находится в выделенном HSM.

Аудит и контроль доступа

KMS удобно интегрируется с облачной IAM и централизованным аудитом. Можно разделить право администрировать ключ, менять политику и выполнять подпись. Журналы желательно отправлять в отдельный контур, где рабочая учётная запись сервиса не может их изменять или удалять.

Главный риск — чрезмерно широкая IAM-политика. Неэкспортируемый ключ всё равно можно злоупотребить как удалённым оракулом подписи. Если атакующий получил право вызывать операцию, ему необязательно извлекать материал. Поэтому ограничивать нужно не только администраторов, но и инициаторов запросов, набор допустимых операций, окружение, сетевой путь и темп обращений.

Задержка, лимиты и зависимость от сети

Каждая операция проходит через сеть и инфраструктуру провайдера. Для выпуска внутренних сертификатов это часто приемлемо, но сервисная подпись на пути пользовательского запроса может почувствовать задержку. Следует заранее измерить:

• типичную и хвостовую задержку;
• доступную пропускную способность и квоты;
• поведение при ограничении частоты запросов;
• время повторной попытки и влияние повторов на бизнес-операцию;
• последствия недоступности региона, IAM или сетевого канала.

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

Высокая доступность

Managed KMS снимает с команды обслуживание устройств, но не устраняет необходимость проектировать отказоустойчивость клиента. Зависимостями становятся DNS, сеть, облачная IAM, квоты и регион сервиса. Реплика ключа в другом регионе полезна только тогда, когда приложение умеет безопасно переключаться и требования к размещению данных допускают такую схему.

Для CA важно определить поведение при недоступности KMS. Обычно безопаснее остановить выпуск сертификатов, чем временно перейти на менее защищённый программный ключ. Для сервисной подписи решение зависит от назначения: иногда допустима очередь, иногда нужен второй независимый ключ с заранее определённой областью доверия.

Когда KMS подходит лучше всего

• система уже работает в облаке и использует его IAM и аудит;
• ключ не должен находиться в памяти приложения;
• команда не хочет эксплуатировать собственный HSM;
• поддерживаемые алгоритмы и форматы соответствуют протоколу;
• сетевые задержки и квоты укладываются в профиль нагрузки;
• зависимость от провайдера и региона приемлема.

Программное хранение: гибкость с широкой зоной доверия

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

Преимущества

• минимальная задержка криптографических операций;
• нет платы за каждый удалённый вызов;
• доступны алгоритмы и библиотеки, которые могут отсутствовать в KMS или HSM;
• проще развернуть разработку, тестовый контур и автономную систему;
• легче переносить ключ между совместимыми приложениями.

Риски

Процесс, способный подписать данные локально, обычно способен прочитать ключ или воспользоваться им без дополнительного сетевого разрешения. Уязвимость удалённого выполнения кода, доступ к отладчику, дамп памяти, небезопасная телеметрия или захват резервной копии могут привести к компрометации.

Контейнеризация сама по себе не создаёт криптографическую границу. Администратор узла, привилегированный контейнер или уязвимость оркестратора могут получить доступ к памяти и смонтированным секретам. Переменная окружения также не является специальным защищённым хранилищем: она может попасть в диагностические данные, сведения о процессе или ошибочно записанный журнал.

Как уменьшить риск

• хранить зашифрованный ключ отдельно от данных, необходимых для его расшифрования;
• выдавать секрет только конкретной workload-идентичности, а не всему узлу или пространству имён;
• загружать ключ непосредственно перед использованием и не создавать лишних копий;
• отключать дампы памяти и ограничивать отладочные интерфейсы в рабочем контуре;
• изолировать сервис подписи от бизнес-приложения и предоставлять ему узкий внутренний API;
• вести удалённый неизменяемый аудит и ограничивать частоту операций;
• сокращать срок жизни ключа и заранее автоматизировать ротацию.

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

Сравнение по ключевым критериям

Экспортируемость

HSM: может аппаратно запрещать получение открытого материала, сохраняя специальные механизмы защищённого резервирования. KMS: обычно не отдаёт материал ключа приложению, но гарантии зависят от типа ключа, способа импорта и уровня защиты. Программная модель: ключ по определению доступен процессу и потенциально может быть извлечён при компрометации среды исполнения.

Аудит

HSM: даёт низкоуровневые события устройства, которые нужно связывать с журналом сервиса. KMS: обычно удобен для централизованного облачного аудита и IAM, но требует отдельной защиты журналов. Программная модель: обеспечивает наиболее гибкий прикладной журнал, однако взломанный процесс может попытаться обойти или подделать его.

Производительность

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

Высокая доступность

HSM: требует нескольких модулей, синхронизации, резервных процедур и тестирования клиента. KMS: инфраструктуру обслуживает провайдер, но приложение остаётся зависимым от сети, IAM, региона и лимитов. Программная модель: легко реплицируется технически, однако безопасная доставка одинакового ключа на множество узлов повышает риск его утечки.

Стоимость

HSM: включает оборудование или аренду, лицензии, интеграцию, резервные устройства, специалистов и регламентные операции. KMS: снижает стартовые затраты, но формирует постоянную плату за ключи, операции, аппаратный уровень и межрегиональную архитектуру. Программная модель: выглядит дешёвой, но требует затрат на hardening, менеджер секретов, мониторинг, реагирование и более частую ротацию.

Compliance

Ни один вариант не обеспечивает соответствие требованиям автоматически. Сертификация HSM или аппаратной платформы KMS относится к конкретному криптографическому модулю, конфигурации и режиму работы. Она не подтверждает безопасность всей PKI, корректность IAM или качество процедур выпуска.

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

Почему неизвлекаемый ключ всё равно можно скомпрометировать

HSM и KMS защищают материал ключа, но не понимают, что именно разрешено подписывать. Если сервис обладает широким правом вызова, атакующий может отправлять собственные данные и получать корректные подписи. Такая атака не оставляет файла с закрытым ключом, но последствия могут быть сопоставимыми.

Поэтому вокруг криптографического модуля нужен policy enforcement point — CA или сервис подписи, который проверяет запрос до обращения к ключу. Для внутренней PKI он может ограничивать шаблоны имён, допустимые расширения сертификата, срок действия, тип субъекта и источник запроса. Для прикладной подписи — формат сообщения, назначение ключа, идентификатор клиента и допустимый контекст.

Полезны независимые ограничения:

• разные ключи для разных протоколов и окружений;
• запрет общего ключа для сертификатов и произвольной подписи;
• короткоживущие полномочия workload вместо постоянных токенов;
• лимиты частоты и сигнализация об аномальном объёме;
• двухэтапное одобрение редких административных операций;
• криптографически связанный журнал запроса и результата;
• автоматическая блокировка при нарушении политики.

Практические архитектурные варианты

Изолированный корневой CA и онлайн-выпускающий CA

Корневой ключ размещается в отключаемом или строго изолированном HSM и используется только для подписания сертификатов выпускающих CA и регламентных объектов. Онлайн-выпуск выполняет отдельный CA с ключом в сетевом HSM или KMS. Такая схема уменьшает число операций с наиболее критичным ключом и позволяет независимо масштабировать рабочий выпуск.

KMS через централизованный сервис подписи

Приложения не получают прямой доступ к KMS. Они вызывают внутренний сервис, который проверяет схему данных, назначение ключа и полномочия клиента, после чего обращается к KMS. Это облегчает смену провайдера, унифицирует аудит и не позволяет каждому приложению использовать ключ как универсальный оракул подписи. При выборе централизованного криптографического сервиса полезно также сравнить Vault Transit и облачный KMS с учётом того, где фактически будет находиться граница доверия.

HSM через PKI или криптографический брокер

Сервис управления секретами или PKI может делегировать операции внешнему HSM через PKCS#11. Например, централизованная платформа способна использовать managed key для PKI и сервисной подписи, не помещая закрытый материал в собственное хранилище. При этом обычный программный криптографический движок той же платформы может хранить управляемые ключи внутри своего защищённого хранилища. Эти режимы нельзя считать эквивалентными: граница доверия у них различается.

Программный ключ в выделенном сервисе

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

Как выбрать модель

1. Оцените последствия компрометации. Определите, что придётся перевыпустить, какие системы перестанут доверять подписям и можно ли быстро отозвать полномочия.
2. Зафиксируйте требование к экспорту. Формулировка должна быть технической: например, открытый материал не должен быть доступен ОС, приложению и администраторам инфраструктуры.
3. Опишите профиль нагрузки. Нужны алгоритмы, число операций в секунду, допустимая задержка, пики, размер подписываемых данных и требования к пакетной обработке.
4. Определите допустимый простой. Решите, можно ли остановить выпуск или подпись при отказе и какие операции допустимо поставить в очередь.
5. Проверьте интеграцию. Важны не только заявленные алгоритмы, но и конкретные схемы подписи, параметры, кодирование результата, API и клиентские библиотеки.
6. Постройте модель полномочий. Разделите создание, изменение политики, использование, отключение, удаление и резервное копирование ключа.
7. Посчитайте полную стоимость. Включите высокую доступность, резервный регион, сетевой трафик, операции API, лицензии, сопровождение, аудит и регулярные учения восстановления.
8. Сопоставьте решение с требованиями compliance. Проверяйте конкретный модуль и режим, а не общее название продукта.

Для корневого CA с большим радиусом доверия типичным выбором становится HSM и минимальное время онлайн. Для облачного выпускающего CA часто подходит HSM-backed KMS, если сервис поддерживает нужный алгоритм и обеспечивает приемлемую доступность. Для высоконагруженной сервисной подписи выбор зависит от задержки: это может быть производительный HSM-кластер, KMS с асинхронной обработкой или изолированный программный сервис для ключей с ограниченным ущербом.

Что проверить на пилоте

Решение нельзя принимать только по документации. Пилот должен воспроизводить рабочий путь операции и сценарии отказа.

• Ключ действительно создаётся в выбранной границе и не может быть выгружен штатными полномочиями приложения.
• Сервис поддерживает требуемый алгоритм, параметры и формат подписи.
• IAM запрещает приложению создавать, удалять, экспортировать и переназначать ключи.
• Каждую подпись можно связать с аутентифицированным инициатором и бизнес-запросом.
• Журналы уходят в отдельное хранилище и недоступны для изменения рабочей учётной записи.
• Измерены медианная и хвостовая задержка при обычной и пиковой нагрузке.
• Проверено поведение при исчерпании квоты, сетевом тайм-ауте и недоступности одного узла или региона.
• Повтор запроса не создаёт неконтролируемую повторную бизнес-операцию.
• Ротация не нарушает проверку ранее созданных подписей и цепочек сертификатов.
• Удаление или отключение ключа защищено от случайного выполнения и имеет понятную процедуру восстановления, если она поддерживается.
• Команда провела восстановление из резервной копии или переключение на реплику, а не только описала его в регламенте.

Типичные ошибки

• Считать KMS синонимом HSM. Уровень защиты нужно проверять для конкретного типа и версии ключа.
• Давать приложению прямой универсальный доступ к подписи. Неэкспортируемый ключ не защищает от злоупотребления разрешённым API.
• Использовать один ключ для нескольких назначений. Это увеличивает радиус поражения и затрудняет независимую ротацию.
• Оценивать только цену устройства или вызова. Основные расходы могут находиться в высокой доступности, интеграции, специалистах и аудите.
• Создавать единственную копию неизвлекаемого ключа. Строгая защита без проверенного восстановления превращает аппаратный отказ в потерю PKI.
• Реплицировать программный ключ на каждый узел. Масштабирование производительности одновременно масштабирует поверхность компрометации.
• Считать сертификат соответствия свойством всей системы. Валидированный модуль не исправляет слабую IAM, общий PIN или неконтролируемый выпуск.
• Игнорировать вывод из эксплуатации. Миграция должна учитывать старые подписи, цепочки доверия, резервные копии и отложенное уничтожение ключа.

Итог

HSM создаёт наиболее явную аппаратную границу и подходит для ключей с максимальным радиусом доверия, но требует зрелой эксплуатации, резервирования и бюджета. Managed KMS предоставляет похожую модель удалённых операций без собственного оборудования, однако переносит доверие и доступность к провайдеру, сети и облачной IAM. Программное хранение обеспечивает гибкость и скорость, но оставляет закрытый ключ доступным среде исполнения.

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