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