Доступ партнёра к HSM через VPN: определите ключевые операции

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

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

Доступность, идентичность и политика ключей — это трое ворот

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

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

Первые ворота: сетевой путь, который получает партнёр

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

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

Вторые ворота: что на самом деле аутентифицируется в HSM

Идентичность VPN и идентичность HSM — отдельные объекты, если только поддерживаемая интеграция намеренно не связывает их. С клиентом PKCS#11 приложение выполняет вход в слот с учётными данными, хранящимися где-то на хосте партнёра, и именно этот вход оценивает HSM.

AWS CloudHSM — полезный ориентир, потому что его документация разделяет эти две вещи: пользователи HSM отличаются от пользователей IAM, а тип пользователя определяет, что может делать учётная запись. Крипто-офицер управляет пользователями и ключами, но не является той идентичностью, которая выполняет криптографические операции, тогда как крипто-пользователь может использовать ключи, не имея возможности управлять ими. Это разделение — та форма, которую вы хотите даже на устройстве другого поставщика, где имена ролей будут другими.

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

Третьи ворота: какой ключ и какая операция

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

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

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

Отказы — часть приёмочного теста

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

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

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