Доступ партнера до 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.