Partnerens HSM-adgang over en VPN: definér nøgleoperationerne

Nogen hos partneren skal underskrive et dokument med én bestemt nøgle, og anmodningen kommer formuleret som netværk: de skal nå HSM'en. Behandl den sætning som et symptom på en udefineret servicekontrakt og ikke som et routingproblem, for en tunnel, der når apparatet, giver intet i sig selv. Bag anmodningen ligger tre gates: tilgængelighed, HSM-identitet og nøglepolitik, og hver af dem administreres et andet sted af et andet team. Skriv dem ned én ad gangen, ellers ender du med at give en rute, fordi samtalen om certifikatet var sværere.

Hold det konkrete tilfælde for øje: partneren indsender et godkendt dokument til underskrift med én navngivet nøgle og intet andet. Alt nedenfor følger af den ene sætning.

Tilgængelighed, identitet og nøglepolitik er tre gates

VPN-koncentratoren afgør, hvem der må åbne en tunnel, og hvilke adresser de må røre. HSM'en afgør selv, hvilken brugerpost, der præsenteres for den, der må logge ind. Nøglepolitikken afgør derefter, hvad den brugerpost må gøre med én bestemt nøgle. At passere den første gate efterlader de to andre præcis som de var, og derfor beviser et vellykket håndtryk så lidt, og derfor kan en partner nå apparatet og alligevel fejle på hver operation.

Knyt hver gate til en ejer, før du skriver krav. Når ingen ejer den anden, er det sædvanlige resultat, at der udstedes en bred HSM-administratoridentitet, fordi det er den eneste legitimationsoplysning, der virker.

Gate et: den netværkssti, partneren får

Navngiv den godkendte klient eller tjeneste, det mål den har brug for, og den protokol og port, som tjenesten lytter på. Begræns derefter adgangen på VPN-siden til det par i begge retninger, inklusive returvejen, så politikken er en sætning, du kan læse op for partneren. Gateway-administration, HSM-styringsinterfaces og urelaterede interne systemer bør ligge uden for partnerens almindelige adgang, ikke blot uden for standardruten.

Et dedikeret segment gør de krydsninger synlige, men et segments navn håndhæver intet. Trafik skal passere gennem den kontrol, du tror, den passerer. At tillade en forbindelse fra partneren er heller ikke en erklæring om, at hver maskine hos partneren er troværdig.

Gate to: hvad der faktisk autentificerer sig over for HSM'en

En VPN-identitet og en HSM-identitet er separate objekter, medmindre en understøttet integration bevidst sammenkæder dem. Med en PKCS#11-klient udfører applikationen et login mod en slot med en legitimationsoplysning, der er gemt et sted på partnerens vært, og det login er det, HSM'en vurderer.

AWS CloudHSM er en nyttig reference, fordi dokumentationen holder de to adskilt: HSM-brugere er forskellige fra IAM-brugere, og brugertypen styrer, hvad kontoen må gøre. En crypto officer administrerer brugere og nøgler, men er ikke den identitet, der udfører kryptografiske operationer, mens en crypto user kan bruge nøgler uden at kunne administrere dem. Den opdeling er den form, du ønsker, selv på en anden leverandørs apparat, hvor rollenavnene vil være anderledes.

Uanset hvilken identitet du udsteder, skal den kunne fjernes og henføres med den granularitet, du får brug for senere. Én delt driftslegitimationsoplysning på tværs af flere partnere gør inddæmning og ansvarlighed sværere i netop den hændelse, hvor begge betyder mest.

Gate tre: hvilken nøgle, og hvilken operation

Signering, dekryptering, nøglegenerering, nøgleindpakning og brugeradministration er separate tilladelser og skal opregnes separat. I PKCS#11-termer beskriver attributter som CKA_SENSITIVE og CKA_EXTRACTABLE, om nøglemateriale kan forlade modulet i brugbar form, og de sættes pr. nøgle og ikke pr. apparat. Læs den faktiske politik på nøglen i stedet for at udlede ikke-eksporterbarhed af ordet hardware eller af tilstedeværelsen af en tunnel.

Find derefter forretningsgodkendelsen. Hvis kun godkendte dokumenter må underskrives, hvilken komponent fastslår den godkendelse, før anmodningen når HSM'en? En kryptografisk grænseflade, der accepterer en autoriseret anmodning, aner ikke, om dokumentet er gennemgået, så den kontrol hører til tjenesten foran den.

En tilladt klient, der er kompromitteret, kan også misbruge de operationer, som dens legitimationsoplysning lovligt autoriserer, uden nogensinde at udtrække en privat nøgle. Så at beskytte lagret nøglemateriale og at styre nøglebrug er to acceptbetingelser, ikke én.

Afvisninger er en del af accepttesten

Accepter den tilladte signeringsanmodning, og accepter også afvisningerne: en uautoriseret identitet, en urelateret nøgle og en administrationsoperation fra partnerens sti. Registrer kalderen, operationen, nøgleidentifikatoren, tidspunktet og resultatet, og hold privat nøglemateriale, legitimationsoplysninger og dokumentindhold ude af generelle diagnostiske logfiler.

Udpeg en ejer til udfasning af partneren, til en mistænkt kompromittering hos partneren og til politikændringer og genopretning. At ændre en rute genopretter ikke tilliden til en vært, der måske allerede er kompromitteret, så tilbagekaldelse skal også nå HSM-identiteten.

Et gennemført VPN-håndtryk hører i den registrering. Det kan ikke erstatte et enkelt HSM-specifikt resultat.