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