HSM — не сейф для ключей. Что на самом деле защищает HSM?
Фраза «ключ хранится в HSM» звучит успокаивающе. Проблема в том, что безопасность ключа определяется не адресом его хранения. Можно поставить дорогой аппаратный модуль в стойку, а затем разрешить приложению экспортировать ключ, выдать администратору лишние права и забыть про ротацию. Формально HSM есть. Криптографическая архитектура при этом остаётся слабой.
Ключ начинается не с хранения, а с генерации
Первый вопрос к системе управления ключами звучит не «где лежит ключ?», а «где и как он появился?». Если ключ сгенерирован снаружи, а потом загружен в HSM, важно понимать, где ещё существовала его копия, каким генератором случайных чисел она была создана и кто имел к ней доступ.
Дальше начинается менее эффектная, но более важная часть: политика использования. Какое приложение имеет право обратиться к конкретному ключу? Может ли оно только подписывать или ещё экспортировать объект? Кто способен изменить атрибуты? Может ли один администратор единолично провести критическую операцию?
HSM умеет ограничивать доступ, но архитектура должна эти ограничения задать. Сам аппаратный модуль ошибочную модель ролей не исправляет.
Криптопериод заканчивается раньше, чем ломается железо
Ключ не должен жить столько же, сколько серверная стойка. Для него задают криптопериод, после которого он выводится из активного использования и заменяется новым. Управление ключами охватывает весь жизненный цикл: генерацию, хранение, использование, резервирование, восстановление, отзыв и уничтожение.
Ротация ограничивает последствия компрометации и позволяет менять ключи без аварийной перестройки инфраструктуры.
Отсюда же вопрос резервирования. «Ключ никогда не покидает HSM» не должен означать «после отказа устройства бизнес останавливается». Для критичных систем заранее проектируют безопасный backup или клонирование, резервный модуль и процедуру восстановления. И эту процедуру надо проверять на практике.
Уничтожение — это не полное удаление
Удалить ключ из HSM одной командой это не то же самое, что гарантировать, что ключа больше нигде нет. Если где-то в цепочке был разрешен экспорт «на всякий случай», у ключа может существовать копия за пределами модуля — в бэкапе, в резервном HSM, в архивном снапшоте, а иногда и в логах, если процесс был настроен небрежно. Физическое стирание объекта из одного устройства ничего не говорит о судьбе этих копий.
Корректное уничтожение является процессом с границами. Сначала нужно перечислить все места, где ключевой материал мог физически существовать, затем вывести его из каждого из них, а не только из «основного» HSM, и зафиксировать это в аудите как отдельное, проверяемое событие. Для ключей подписи к этому добавляется ещё один шаг. Это отзыв сертификата или публичного ключа, чтобы система перестала доверять артефактам, подписанным уже не существующим ключом. Без этого шага уничтожение ключа защищает архитектуру, но не защищает от уже подписанные им данных.
Российская реальность: ГОСТ мало реализовать
Для российских систем криптографическая архитектура имеет дополнительный слой требований. ГОСТ Р 34.10-2012 используется для формирования и проверки электронной подписи, а ГОСТ Р 34.11-2012 определяет функцию хэширования. Оба стандарта остаются действующими. Актуальные рекомендации Росстандарта продолжают описывать их применение, в том числе в инфраструктуре открытых ключей X.509. Но поддержка ГОСТ-алгоритмов сама по себе ещё не делает устройство СКЗИ.
В регулируемой инфраструктуре важно различать аппаратную платформу HSM, ее программную реализацию, среду функционирования и сертифицированное средство защиты с конкретной областью применения. ФСБ России отдельно регулирует сертификацию средств защиты информации и применение СКЗИ. Поэтому фраза «наш HSM соответствует ГОСТ» отвечает на технический вопрос, но не закрывает регуляторный.
Как превратить HSM в дорогую игрушку
Почти все ошибки происходят не внутри устройства, а вокруг него. Разрешили экспорт ключей «на всякий случай». Оставили одному администратору полномочия на все. Не определили криптопериоды. Купили один модуль и назвали это отказоустойчивостью. Настроили аудит так, что события пишутся в журнал, но никто не проверяет, кто и зачем выполнял критические операции.
В результате организация защищает металлическую коробку, а не криптографический процесс. Поэтому HSM стоит оценивать не только по производительности и количеству поддерживаемых ключей. Важнее другое: где возникает ключ, может ли он покинуть защищенный контур, кто имеет право использовать его, как проходит ротация, что произойдёт при отказе и каким образом ключ будет гарантированно выведен из эксплуатации.
HSM защищает не файл с ключом. Он защищает выполнение криптографических операций и жизненный цикл. Но только если вся архитектура вокруг модуля построена с тем же уровнем строгости.
В проектах «Потенциала» вопрос «может ли ключ покинуть защищенный контур» — это первый вопрос любого аудита существующей криптографической инфраструктуры заказчика, до разговора о конкретном оборудовании или сертификации. Опыт показывает, что там, где ответ «да, но только в исключительных случаях», исключения рано или поздно становятся правилом.