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