Шифрование HSM: функционирование и приватные ключи (2026)

Безопасность цифровых транзакций зависит от компонента, часто неизвестного IT-руководству: аппаратного модуля безопасности (HSM). Это специализированное устройство генерирует, хранит и защищает криптографические ключи, никогда не раскрывая их внешней программной среде. По данным доклада ENISA Threat Landscape 2025, кибератаки на инфраструктуры PKI увеличились на 43 % между 2023 и 2025 годами. Поэтому понимание работы HSM-шифрования становится стратегической необходимостью для любого предприятия, управляющего квалифицированными электронными подписями, банковскими транзакциями или обменом конфиденциальными данными. Данная статья раскрывает архитектуру HSM, жизненный цикл приватных ключей, применяемые криптографические протоколы и критерии выбора для B2B-организаций.

Аппаратная архитектура HSM: криптографический сейф

HSM по определению — это неприступное физическое устройство (tamper-resistant). В отличие от программного решения, оно интегрирует механизмы обнаружения вторжения, которые запускают автоматическое стирание ключей при попытке физического нарушения (механизм так называемого zeroization).

Внутренние компоненты и защищённая изоляция

Внутренняя архитектура HSM опирается на несколько дополняющих друг друга уровней:

• Выделенный криптографический процессор: выполняет криптографические операции (RSA, ECDSA, AES, SHA-256) изолированно от хост-системы.

• Аппаратный генератор случайных чисел (TRNG): производит истинную энтропию, необходимую для надёжности сгенерированных ключей — аппаратные TRNG значительно превосходят программные PRNG по непредсказуемости.

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

• Неприступный корпус (tamper-evident enclosure): любая попытка открытия запускает тревогу и стирание секретов.

HSM сертифицированы по стандартам FIPS 140-2/140-3 (уровни 2–4), опубликованным NIST, и Common Criteria EAL 4+ для наиболее требовательных европейских применений. Например, HSM уровня FIPS 140-3 уровень 3 требует многофакторной аутентификации для любого доступа к ключам и устойчив к активным физическим атакам.

Режимы развёртывания: on-premise, PCIe и облачный HSM

На рынке B2B сосуществуют три физические формы:

• Сетевой HSM (appliance): стойка, подключённая к локальной сети, общая для нескольких серверов приложений. Обычно используется поставщиками услуг доверия (ПУД/TSP), сертифицированными по eIDAS.

• Карта PCIe HSM: модуль, встроенный непосредственно в сервер, обеспечивающий лучшие задержки для приложений с большим объёмом подписей.

• Облачный HSM: управляемый сервис от облачных провайдеров (Azure Dedicated HSM, AWS CloudHSM, Google Cloud HSM). Оборудование остаётся физически выделенным клиенту, но размещается в центре обработки данных провайдера — подходит для предприятий, желающих избежать управления оборудованием, сохраняя исключительный контроль над ключами.

Выбор между этими режимами напрямую определяет уровень соответствия, достижимый с помощью Регламента eIDAS 2.0, особенно для квалифицированных подписей (QES), требующих квалифицированного устройства создания подписи (QSCD) — сертифицированный HSM — идеальный QSCD.

Жизненный цикл приватных ключей в HSM

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

Генерация и загрузка ключей

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

• Генерация пары ключей (открытого/приватного) непосредственно в HSM через встроенный TRNG.

• Приватный ключ никогда не покидает аппаратный периметр HSM — даже системные администраторы не имеют доступа к нему в открытом виде.

• Открытый ключ, исключительно он, экспортируется для включения в сертификат X.509, выданный Центром сертификации (ЦС).

Некоторые протоколы, например PKCS#11 (стандарт OASIS) или JCE (Java Cryptography Extension), позволяют деловым приложениям вызывать криптографические операции HSM через стандартизированные вызовы API, никогда не манипулируя ключами напрямую.

Криптографические операции: подпись, расшифровка, деривация

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

• Приложение вычисляет цифровой отпечаток (хеш) документа, используя функцию хеширования (SHA-256 или SHA-384).

• Хеш передаётся в HSM через интерфейс PKCS#11 или CNG (Cryptography Next Generation в Windows).

• HSM подписывает хеш внутри приватным ключом RSA-2048 или ECDSA P-256 в зависимости от конфигурации.

• Цифровая подпись возвращается приложению — никогда сам ключ.

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

Резервное копирование, ротация и уничтожение ключей

Полный жизненный цикл ключа включает:

• Зашифрованное резервное копирование: ключи могут быть экспортированы в зашифрованном виде (Wrapped Key) с использованием ключа шифрования ключей (KEK), сам хранящегося в другом главном HSM — принцип Key Ceremony, документированный ЦС.

• Периодическая ротация: рекомендуется каждые 1–3 года в зависимости от продолжительности жизни сертификатов и уровня риска. Регламент eIDAS 2.0 и политики ETSI TS 119 431 устанавливают эти сроки для поставщиков услуг доверия.

• Отзыв и уничтожение: в конце жизни ключ уничтожается путём zeroization — необратимая операция, гарантирующая невозможность восстановления.

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

Криптографические протоколы и стандарты, поддерживаемые HSM

Современный корпоративный HSM поддерживает расширенный набор криптографических примитивов и протоколов.

Асимметричные и симметричные алгоритмы

Интеграция постквантовых алгоритмов (PQC) — актуальная тема: NIST завершил в 2024 году первые стандарты PQC (FIPS 203, 204, 205), и несколько производителей HSM (Thales, nCipher/Entrust, Utimaco) предлагают в 2026 году микрокоды, поддерживающие эти алгоритмы в гибридном режиме RSA+Kyber.

Интерфейсы и протоколы интеграции

Экосистема интеграции HSM опирается на несколько открытых стандартов:

• PKCS#11: наиболее распространённый C API интерфейс, поддерживаемый OpenSSL, EJBCA и большинством серверов приложений Java.

• Microsoft CNG/KSP: встроенная интеграция в экосистему Windows Server / Active Directory Certificate Services.

• KMIP (Key Management Interoperability Protocol): стандарт OASIS для централизованного управления ключами между гетерогенными HSM — особенно полезен в многооблачных архитектурах.

• Собственные REST API: современные облачные HSM раскрывают REST API для гладкой интеграции DevOps (Infrastructure as Code, провайдеры Terraform).

Овладение этими интерфейсами необходимо для интеграции HSM в платформу электронной подписи для предприятий с большим объёмом.

Критерии выбора HSM для B2B-предприятий в 2026 году

Перед лицом разнообразного рыночного предложения, несколько объективных критериев должны руководить решением о покупке или подписке на HSM-as-a-Service.

Уровень сертификации и нормативное соответствие

Для использования в контексте квалифицированной электронной подписи (eIDAS) или банковских процессов, подпадающих под PSD2/DSP2:

• FIPS 140-3 уровень 3 минимум для чувствительных персональных или финансовых данных.

• Сертификация Common Criteria EAL 4+ с профилем защиты EN 419221-5 для QSCD eIDAS — это референциальный стандарт списков доверия европейских организаций (ETSI TS 119 612).

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

Производительность, высокая доступность и TCO

Высокопроизводительные сетевые HSM (Thales Luna Network HSM 7, Entrust nShield Connect XC) демонстрируют производительность в несколько тысяч операций RSA-2048 в секунду с конфигурациями active-active для высокой доступности. TCO на 5 лет on-premise HSM включает: оборудование, техническое обслуживание, квалифицированный персонал и управление Key Ceremonies — элементы, которые часто делают Cloud HSM более привлекательным для малых и средних предприятий.

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

Управление ключами и контроль доступа

HSM стоит столько же, сколько качество его управления:

• Принцип M-of-N: любая критическая операция (генерация главного ключа, инициализация) требует одновременного присутствия M администраторов из N назначенных — обычно 3 из 5.

• Неизменяемые журналы аудита: каждая криптографическая операция трассируется в синхронизированных и подписанных логах, требование GDPR (ст. 5.2, подотчётность) и стандартов ETSI.

• Разделение ролей: администратор HSM, оператор ключей и аудитор — разные роли — в соответствии с требованиями политик сертификации ETSI EN 319 401.

Понимание требований Регламента eIDAS 2.0 необходимо для надлежащей калибровки управления ключами в контексте квалифицированной европейской подписи.

Нормативно-правовая база для корпоративного шифрования HSM

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

Регламент eIDAS № 910/2014 и пересмотр eIDAS 2.0

Регламент eIDAS устанавливает технические и юридические условия квалифицированных электронных подписей (QES). Его статья 29 требует, чтобы квалифицированные устройства создания подписи (QSCD) гарантировали конфиденциальность приватного ключа, его уникальность и невозможность его деривации. Эти технические требования могут быть выполнены только сертифицированным HSM в соответствии с профилем защиты EN 419221-5 или эквивалентом. Пересмотренный Регламент eIDAS 2.0 (Регламент ЕС 2024/1183, вступивший в силу в мае 2024 года) усиливает эти обязательства введением европейского кошелька цифровой идентификации (EUDIW), который также опирается на соответствующие QSCD.

Применяемые стандарты ETSI

Семейство стандартов ETSI точно регулирует практику поставщиков услуг доверия (TSP):

• ETSI EN 319 401: общие требования безопасности для TSP, включая управление HSM и разделение ролей.

• ETSI EN 319 411-1/2: политики и практики сертификации для ЦС, выдающих квалифицированные сертификаты.

• ETSI EN 319 132: профиль XAdES для продвинутой электронной подписи — операции подписи опираются на HSM.

• ETSI TS 119 431-1: специфические требования для дистанционных служб подписи (Remote Signing), где HSM управляется TSP от имени подписанта.

Французский Гражданский кодекс (статьи 1366–1367)

Статья 1366 Гражданского кодекса признаёт юридическую ценность электронного документа при возможности идентификации его автора и гарантии его целостности. Статья 1367 приравнивает квалифицированную электронную подпись к собственноручной подписи. Защита приватного ключа HSM — технический механизм, обеспечивающий эту неопровержимую презумпцию ответственности перед судами.

GDPR № 2016/679

Когда HSM обрабатывает ключи, связанные с идентификацией физических лиц (номинативные квалифицированные сертификаты, журналы аудита, включающие идентификационные данные), GDPR полностью применяется. Статья 25 (privacy by design) требует встроить защиту данных с самого начала — HSM отвечает на это требование, делая технически невозможным доступ к приватным ключам вне установленного операционного процесса. Статья 32 требует реализации надлежащих технических мер: HSM представляет лучшую практику в области криптографической защиты.

Директива NIS2 (ЕС 2022/2555)

Транспонированная в французское законодательство Законом от 15 апреля 2025 года, Директива NIS2 требует от важнейших операторов и операторов важных услуг (ОЭ/ОЭУ) реализовать меры по управлению рисками, включающие явно безопасность цепочки поставок криптографических инструментов. Использование сертифицированных HSM для защиты ключей подписи и шифрования входит непосредственно в эту базу, в частности для секторов здравоохранения, финансов, энергетики и цифровой инфраструктуры.

Ответственность и юридические риски

Компрометация приватного ключа в результате отсутствия HSM или недостаточной конфигурации может возложить гражданскую и уголовную ответственность на ответственного за обработку, подвергнуть организацию санкциям CNIL (до 4 % глобального оборота), и ретроактивно аннулировать все подписи, совершённые скомпрометированным ключом. Отсутствие логирования операций HSM представляет собой явное несоответствие стандартам ETSI и GDPR.

Сценарии использования: HSM в действии в B2B-предприятиях

Сценарий 1 — Платформа квалифицированной подписи для многосайтового промышленного холдинга

Европейский промышленный холдинг с 15 филиалами, управляющий примерно 4 000 контрактов с поставщиками в год, решает централизовать цепочку квалифицированной электронной подписи. Команда безопасности развёртывает два сетевых HSM в конфигурации высокой доступности active-active в двух разных центрах обработки данных (стратегия географической отказоустойчивости). Квалифицированные ключи подписи каждого юридического лица генерируются и хранятся исключительно в HSM, доступные через интерфейс PKCS#11, раскрытый платформе подписи SaaS.

Результаты, наблюдаемые через 12 месяцев: ноль инцидентов безопасности, связанных с управлением ключами, полное соответствие при аудите eIDAS, проведённом аккредитованным органом оценки соответствия (CAB), и снижение на 67 % сроков подписания контрактов (с среднего 8,3 дней до 2,8 дней). Общая стоимость развёртывания HSM была амортизирована за 14 месяцев благодаря выигрышам в производительности и устранению остаточных бумажных процессов.

Сценарий 2 — Юридическая консалтинговая фирма и управление подписью мандатов клиентов

Фирма по корпоративному праву из 45 специалистов, ведущая дела о слиянии и поглощении, а также коммерческие споры, стремится защитить потоки подписей мандатов, писем о задачах и процессуальных документов. Столкнувшись с невозможностью использовать on-premise HSM (отсутствие выделённой IT-команды), фирма подписывается на услугу Cloud HSM, встроенную в решение электронной подписи для юридических фирм.

Каждый партнёр имеет квалифицированный сертификат, приватный ключ которого хранится в выделенном HSM провайдера, сертифицированном FIPS 140-3 уровень 3 и внесённом в европейский список доверия. Фирма получает выгоду от полной прослеживаемости операций (синхронизированные логи, экспортируемые для обоснования доказательств в случае спора), без какой-либо аппаратной инфраструктуры для управления. Сокращение административного времени, связанного с управлением документами, оценивается в 3,5 часа на сотрудника в неделю по отраслевым бенчмаркам сопоставимых фирм.

Сценарий 3 — Медицинское учреждение и защита данных электронного рецепта

Больничный коллектив из примерно 1 200 коек внедряет безопасный электронный рецепт (e-prescription) в соответствии с требованиями ANS (Агентство цифровых технологий во Франции) и структуры Mon Espace Santé. Рецепты должны быть подписаны профессиональным сертификатом здравоохранения (CPS), приватный ключ которого ни при каких обстоятельствах не может быть раскрыт на рабочих станциях практикующих врачей.

IT-служба развёртывает HSM, сертифицированный Common Criteria EAL 4+, интегрированный в свою внутреннюю инфраструктуру управления идентификацией (IGC). Ключи CPS врачей хранятся в HSM; врачи аутентифицируются через смарт-карту + PIN для запуска делегированной HSM операции подписи. Этот механизм соответствует Регламенту eIDAS и стандартам ETSI и снижает на 89 % риск кражи ключа по сравнению с программным хранилищем на рабочей станции, обеспечивая централизованный отзыв менее чем за 5 минут в случае увольнения или потери карты.

Часто задаваемые вопросы

Какое различие между HSM и хранилищем паролей, таким как программный менеджер паролей?

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

Является ли HSM обязательным для выпуска квалифицированной электронной подписи в соответствии с eIDAS?

Да, регламент eIDAS требует, чтобы любая квалифицированная подпись (QES) была основана на устройстве создания квалифицированной подписи (QSCD). На практике HSM, сертифицированный в соответствии с признанными стандартами, такими как FIPS 140-3 уровень 3 или Common Criteria EAL 4+, является эталонным устройством для удовлетворения этого требования. Без этого аппаратного компонента поставщик услуг доверия не может получить квалификацию, необходимую для выпуска подписей, имеющих такую же юридическую силу, что и рукописная подпись в Европейском союзе.

Что происходит, если HSM выйдет из строя: теряются ли закрытые ключи?

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

Обеспечивает ли Cloud HSM тот же уровень безопасности, что и HSM, развёрнутый на локальных серверах?

Cloud HSM использует физически выделенное оборудование, размещённое в центре обработки данных поставщика: клиент сохраняет исключительный контроль над своими ключами, не делясь ими с другими пользователями. Уровень аппаратной сертификации обычно эквивалентен уровню HSM на локальных серверах. Различие заключается в разделённой ответственности за физическую безопасность центра обработки данных и зависимости от доступности услуг поставщика. Для использования в соответствии с eIDAS или строгими отраслевыми нормативными требованиями следует убедиться, что выбранная услуга внесена в список квалифицированных устройств, опубликованный компетентным национальным органом.

Как интерфейс PKCS#11 позволяет приложению подписывать документы без доступа к закрытому ключу?

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

Заключение

Шифрование HSM представляет краеугольный камень любой инфраструктуры квалифицированной электронной подписи и безопасного управления приватными ключами в предприятии. Сочетая аппаратную изоляцию, доказанные криптографические алгоритмы, строгое управление ключами и соответствие стандартам FIPS 140-3, Common Criteria и ETSI, HSM предлагает несравнимый уровень защиты от современных угроз и европейских нормативных требований. Выберете ли вы on-premise развёртывание, карту PCIe или управляемый Cloud HSM, главное — согласовать выбор со своим уровнем подверженности риску и юридическими обязательствами по eIDAS, GDPR и NIS2.

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