HSM для управления ключами: чек-лист вопросов для закупки

Зачем вам HSM и что именно надо защитить

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

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

До сравнения Thales, Entrust и Utimaco зафиксируйте, какие сценарии вы реально защищаете. Иначе закупка превращается в спор про абстрактные характеристики, а потом внезапно выясняется, что не хватает интерфейсов, режима HA или правильного разделения прав.

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

Важно различать термины. HSM - это защищенный модуль, который хранит ключи и выполняет криптооперации. KMS чаще про управление ключами и политиками на уровне сервиса и иногда использует HSM как корень доверия. "Шифрование на сервере" означает, что ключи и операции живут в обычной ОС, а риск компрометации там выше.

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

Собираем требования до сравнения Thales, Entrust, Utimaco

Ошибки при выборе обычно начинаются не с вендора, а с размытых ожиданий. Зафиксируйте, какие операции HSM будет делать каждый день и что вы будете считать успехом через 6-12 месяцев.

Соберите список сценариев и отдельно отметьте, что для вас важнее всего в каждом из них.

TLS для веб-сервисов и API чаще упирается в частоту операций, задержку и понятное подключение к балансировщикам или веб-серверам. Подпись документов и транзакций сильнее зависит от ролей, аудита и процедур выпуска и отзыва ключей. Шифрование баз данных часто упирается в интеграции с конкретными СУБД и в то, где живут приложения (on-prem, виртуалки, контейнеры). Если у вас есть собственный удостоверяющий центр, отдельно опишите сценарий HSM для CA: выпуск сертификатов, хранение ключей корневого и промежуточных CA, требования к церемониям и доступу нескольких ответственных.

Дальше составьте карту приложений и платформ. Один и тот же HSM может отлично подходить для PKI, но быть неудобным для контейнерной среды, если нет нужного способа подключения или поддержки под вашу ОС.

Для встреч с поставщиками помогает короткий опросник:

• Какие системы будут использовать HSM и через какие интерфейсы они подключаются.
• Какие ОС и среды обязательны (физические серверы, виртуализация, контейнеры) и кто отвечает за поддержку после обновлений.
• Сколько площадок нужно, есть ли требования по разнесению и работе при потере связи.
• Каким будет рост: число ключей, операций в секунду, сервисов и админ-пользователей.
• Какие ограничения есть по закупке и эксплуатации (сертификации, требования регулятора, окна обслуживания, 24/7).

Пример: банк с двумя ЦОД в Казахстане может начать с TLS и подписи платежей, а через год добавить собственный CA для внутренних сервисов. Если это заранее не записать, легко выбрать устройство, которое подходит по криптографии, но не закрывает нужные площадки или масштабирование.

Производительность: какие цифры запрашивать и как не ошибиться

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

Начните с простого расчета: сколько операций в секунду нужно в среднем и на пике, и какую задержку выдерживает самый критичный сервис. Например, портал в обычные часы делает 300 подписей в секунду, а в день отчетности вырастает до 3 000. Если SLA требует ответ за 200-300 мс, вам важна не только "максимальная пропускная способность", но и стабильная задержка на пике.

Как запросить бенчмарк, чтобы он был полезным

Просите тест не "вообще RSA/ECC", а на ваших алгоритмах, размерах ключей и режимах. RSA-2048 и RSA-4096 отличаются кратно, как и ECDSA P-256 против P-384. Влияют и режим работы, и включенный аудит, и сеть вместо PCIe, и число параллельных сессий.

В запросе к вендору (Thales, Entrust, Utimaco или любому другому) зафиксируйте и затем проверьте в отчете:

• Профиль нагрузки: операции, их доля, требуемая задержка, длительность пика.
• Параметры криптографии: алгоритмы, размеры ключей, режимы (подпись или расшифрование).
• Условия стенда: версия прошивки, драйверов, SDK, режим безопасности, включенные политики и аудит.
• Архитектура: сетевой HSM или PCIe, число клиентов и сессий, каналы, защита канала между приложением и HSM.
• Лицензии и ограничения: есть ли опции, которые влияют на параллелизм и производительность.

Не принимайте "до N ops/sec" без условий. Если в отчете нет режима работы, версий и настроек, такая цифра не помогает принять решение.

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

Если вы закупаете HSM вместе с проектом интеграции, заранее договоритесь о пилоте на вашей нагрузке и с вашими приложениями. В таких задачах системный интегратор вроде GSE.kz может помочь собрать стенд, воспроизвести пиковые запросы и сравнить результаты в одинаковых условиях.

HA и отказоустойчивость: вопросы про кластер и восстановление

Если HSM используется для критичных сервисов (подпись, TLS, шифрование БД), простой быстро превращается в простой всей системы. Поэтому про HA стоит говорить до выбора модели и лицензий. По факту вы покупаете не только устройство, но и схему работы при сбоях.

Кластер: как он реально работает

Сначала уточните, какой режим вам нужен.

Active-active обычно дает масштабирование и переживает падение узла без остановки, но сложнее в настройке и предъявляет требования к синхронизации. Active-standby проще, но важно понять, сколько занимает переключение и что будет с текущими сессиями приложений.

Задайте вендору прямые вопросы и попросите ответы письменно, с условиями:

• Какой режим поддерживается и что входит в лицензию (кластер, число узлов, ограничения по расстоянию между площадками).
• Что происходит при обрыве сети, перезагрузке, отказе питания: есть ли автоматический failover и как ведут себя приложения.
• Как синхронизируются ключи и политики: нужен ли отдельный защищенный канал, какая задержка допустима, что будет при рассинхронизации.
• Какие RTO и RPO вы получаете для ваших сервисов.
• Как проводится плановое обслуживание без простоя: обновления, замена узла, ротация сертификатов, тест переключения.

Тесты и эксплуатация

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

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

Интеграции с PKI: CA, интерфейсы и совместимость

Даже хороший HSM не принесет пользы, если он плохо стыкуется с вашей PKI. Начните с простого: какая у вас CA и RA сегодня и что вы планируете завтра. Часто интеграция с Microsoft AD CS, EJBCA или другими CA определяет, какие модули и клиенты вам вообще нужны.

Попросите не общие слова, а точный список поддерживаемых интерфейсов и режимов. Обычно проверяют PKCS#11, JCE для Java-стека, CNG/KSP для Windows и AD CS, а также KMIP, если модуль участвует в управлении ключами вне PKI. Отдельно уточните совместимость с вашими версиями ОС и виртуализации.

Дальше разберите выпуск и хранение ключей CA и OCSP. Важные вопросы: генерируются ли ключи внутри HSM, можно ли запретить экспорт, как настраиваются роли операторов и какие операции требуют участия нескольких человек (dual control). Требования к алгоритмам и длинам ключей сверяйте не с презентацией, а с ограничениями клиентов и провайдеров.

Ограничения часто проявляются на уровне драйверов: версии PKCS#11, особенности KSP, несовместимость с конкретной сборкой Windows Server или Linux. Попросите матрицу совместимости и список известных проблем.

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

Если своей лаборатории нет, интегратор вроде GSE.kz обычно помогает собрать такой стенд и зафиксировать результаты до закупки.

Жизненный цикл ключей: создание, хранение, ротация, уничтожение

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

Первый вопрос - где рождается ключ. Для большинства задач лучший вариант - генерация внутри HSM, чтобы приватный ключ ни разу не покинул защищенную среду. Импорт ключей тоже бывает нужен (миграция, сторонняя PKI, legacy), но тогда заранее решите, какие импорты вы запрещаете, какие допускаете и кто имеет право это делать.

Дальше - ротация. Срок (раз в 6-12 месяцев) редко бывает единственным триггером. Бывают события: компрометация учетной записи, увольнение сотрудника с доступом, смена алгоритмов, обновление регуляторных требований. Продумайте массовую замену и влияние на сервисы: TLS, подпись документов, шифрование баз, токены.

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

Мини-чек-лист вопросов:

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

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

Процедуры замены и аварийные сценарии (key rollover)

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

Если ключ скомпрометирован: кто решает и что делаем

Заранее договоритесь, кто имеет право объявить инцидент и запустить замену: владелец сервиса, ИБ, PKI-администратор, руководитель смены. Без этого время уйдет на согласования.

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

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

Замена без остановки и переезд на новый HSM

Фраза "без простоя" часто означает "без простоя HSM", но приложения все равно придется переключать. Уточните, поддерживается ли параллельная работа старых и новых ключей, сколько можно держать два ключа активными и что будет с сессиями клиентов.

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

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

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

Безопасность и аудит: доступы, логи, соответствие требованиям

Безопасность HSM - это не только "криптография внутри коробки", но и то, как вы потом докажете на проверке, кто и что делал. Поэтому вопросы про аудит и доступы лучше закрывать до пилота, а не после закупки.

Доступы: кто может что делать

Начните с модели ролей. Уточните, поддерживает ли устройство разделение полномочий и двухконтроль: например, чтобы один администратор не мог в одиночку создать мастер-ключ, поменять политики и одновременно выгрузить бэкап. Отдельно спросите про усиленную аутентификацию для администраторов (смарт-карты, аппаратные токены, MFA) и про то, как хранятся и меняются учетные данные операторов.

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

Логи и проверяемость

Вам нужны события не только "успешный вход", но и все операции с ключами и политиками: создание, импорт/экспорт (если разрешен), активация, ротация, уничтожение, изменение прав, попытки запрещенных действий. Уточните, как логи защищены от подмены, есть ли подпись или цепочка целостности и как они выгружаются в SIEM, включая сценарий обрыва связи.

Для сверки ожиданий с реальностью зафиксируйте у вендора:

• какие события логируются по умолчанию и что можно включить дополнительно
• как быстро логи попадают во внешнюю систему и что происходит при переполнении
• какие отчеты доступны для аудита (по ключам, администраторам, изменениям политик)
• как подтверждается двухконтроль и видно ли это в отчетах
• срок хранения логов на устройстве и вне его

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

Частые ловушки при закупке и внедрении HSM

Частая ошибка - считать, что раз устройство сертифицировано и "умеет криптографию", то дальше все заработает само. На практике сложность почти всегда в нагрузке, процессах и интеграциях.

Попросите вендора или интегратора назвать типовые провалы внедрений именно в вашем сценарии: подпись транзакций, выпуск сертификатов, шифрование баз, TLS-ключи. Хороший ответ - это список реальных проблем и способов их избежать, а не маркетинговые формулировки.

Часто недооценивают нагрузку: массовая подпись платежей утром и в конце дня создает пики. Если приложение начинает ставить операции в очередь, задержка становится заметной пользователям, а команда потом лечит это "костылями". Просите цифры и условия тестов: алгоритмы, размер ключей, параллельные сессии, задержка на 95-м перцентиле.

Вторая ловушка - роли и процедуры. Когда "пароль у одного человека", а ключевые операции (инициализация, восстановление, импорт/экспорт, бэкап) не описаны и не отрепетированы, вы получаете риск и простой. Закупка должна включать регламенты, а не только устройство.

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

Перед подписанием договора проверьте:

• какие 3-5 типовых ошибок внедрения видит поставщик и как предлагает их избежать
• как будет проверяться производительность на вашем стенде и кто отвечает за методику
• какие роли нужны (M of N, разделение обязанностей) и какие процедуры должны быть утверждены
• как выглядит план ротации и уничтожения ключей и что будет при просрочке сертификата
• какие интеграции считаются поддерживаемыми и какие нужно подтвердить стендовыми тестами

Если вы работаете через системного интегратора, закрепляйте эти пункты в плане работ и приемке, а не оставляйте "на потом".

Короткий чек-лист вопросов для RFP и встреч с вендорами

Чтобы сравнение Thales, Entrust и Utimaco было честным, задавайте вопросы в одинаковых терминах и просите ответы с цифрами, схемами и условиями теста. Важно не только "поддерживает или нет", но и как это работает в вашей нагрузке.

10 вопросов, которые быстро проясняют картину

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

• Производительность: какие операции измерялись, на какой модели и прошивке, с какими настройками, и какая задержка на 95-м перцентиле.
• Масштабирование: как меняется скорость при росте числа сессий и клиентов, есть ли ограничения по подключениям и лицензиям.
• HA и обслуживание: какая схема кластера, можно ли обновлять и менять узлы без простоя, какие RTO/RPO заявляются и как проводился тест отказа.
• Интеграции: какие интерфейсы доступны (PKCS#11, KMIP и др.), с какими PKI/CA проверялась совместимость, кто отвечает за коннекторы и их поддержку.
• Жизненный цикл ключей: как устроены ротация и политики, как делается бэкап (что именно сохраняется), как выполняется безопасное уничтожение и как реализован двухконтроль (M of N).

Что попросить как подтверждение, а не обещание

Ответы без документов потом сложно защитить и на закупочной комиссии, и на аудите. Попросите:

• отчет по нагрузочному тесту (условия, профили операций, результаты по задержке)
• схему HA с описанием failover и процедурой восстановления после потери узла
• матрицу совместимости (ваши ОС, гипервизор, PKI, приложения) и список ограничений
• черновики регламентов: ввод в эксплуатацию, ротация, аварийная замена ключей, контроль ролей
• описание логов и интеграции с SIEM: какие события пишутся, как обеспечивается целостность, сроки хранения

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

Пример сценария и следующие шаги по внедрению

Представьте банк или госорганизацию: есть внутренняя PKI, выпуск сертификатов для сотрудников и систем, подпись документов, шифрование каналов и требования к непрерывности (подпись должна работать даже при отказе узла или обновлении).

Чтобы закупка HSM была проверяемой, формулируйте требования как тесты. Например: "кластер переживает отказ одного узла без остановки сервиса", "ротация выполняется по регламенту и не ломает интеграции", "восстановление после потери устройства возможно по процедуре с участием нескольких ролей". Сразу определите, что считается простоем, например недоступность подписи для критичных систем дольше 1 минуты.

Пилот на 1-2 недели лучше строить вокруг реальных операций. На выходе вам нужны измеримые результаты: производительность на типичных операциях, проверка HA (отключение узла, переключение, восстановление), сценарий ротации, проверка логов и аудит-следа, а также понятные инструкции для администраторов и дежурной смены.

Дальше двигайтесь короткими шагами: утвердите 3-5 ключевых сценариев, по ним подготовьте RFP и организуйте стенд, максимально похожий на прод. Назначьте владельцев процедур (PKI, инфраструктура, безопасность) и тех, кто принимает тесты.

Интеграцию можно делать внутренней командой, но часто быстрее работает системный интегратор с опытом PKI и дата-центров и с поддержкой 24/7. В Казахстане такие проекты, включая проектирование, внедрение и дальнейшую эксплуатацию с вендор-нейтральным подходом, может выполнять GSE.kz.