Partnerens HSM-tilgang over en VPN: definer nøkkeloperasjonene

Noen hos partneren må signere et dokument med én angitt nøkkel, og forespørselen kommer formulert som et nettverksspørsmål: de må nå HSM-en. Behandle den setningen som et symptom på en udefinert tjenesteavtale og ikke som et rutingproblem, fordi en tunnel som når enheten ikke gir noe i seg selv. Tre porter ligger bak forespørselen: tilgjengelighet, HSM-identitet og nøkkelpolicy, og hver av dem administreres på et annet sted av et annet team. Skriv dem ned én om gangen, ellers ender du med å gi en rute fordi samtalen om sertifikatet var vanskeligere.

Hold det konkrete tilfellet for øye: partneren sender inn et godkjent dokument for signering med én navngitt nøkkel, og ingenting annet. Alt nedenfor følger av den ene setningen.

Tilgjengelighet, identitet og nøkkelpolicy er tre porter

VPN-konsentratoren avgjør hvem som kan åpne en tunnel og hvilke adresser de kan berøre. HSM-en avgjør selv hvilken brukerpost som legges fram for den, og som kan logge inn. Nøkkelpolicyen avgjør deretter hva den brukerposten kan gjøre med én bestemt nøkkel. Å passere den første porten lar de to andre være nøyaktig som de var, og derfor beviser et vellykket håndtrykk så lite, og derfor kan en partner nå enheten og likevel mislykkes i hver operasjon.

Knytt hver port til en eier før du skriver krav. Når ingen eier den andre, er det vanlige resultatet at en bred HSM-administratoridentitet blir utdelt, fordi det er den eneste legitimasjonen som virker.

Første port: nettverksbanen partneren får

Navngi den godkjente klienten eller tjenesten, målet den trenger, og protokollen og porten den tjenesten lytter på. Begrens deretter tilgangen fra VPN-siden til det paret i begge retninger, inkludert returveien, slik at policyen blir en setning du kan lese opp for partneren. Gateway-administrasjon, HSM-administrasjonsgrensesnitt og urelaterte interne systemer bør ligge utenfor vanlig partnertilgang, ikke bare utenfor standardruten.

Et dedikert segment gjør disse kryssingene synlige, men navnet på et segment håndhever ingenting. Trafikken må passere gjennom den kontrollen du tror den passerer. Å slippe inn en tilkobling fra partneren er heller ikke en erklæring om at hver maskin hos partneren er pålitelig.

Andre port: hva som faktisk autentiserer seg mot HSM-en

En VPN-identitet og en HSM-identitet er separate objekter med mindre en støttet integrasjon bevisst slår dem sammen. Med en PKCS#11-klient utfører applikasjonen en innlogging mot en slot med en legitimasjon som er lagret et sted på partnerens vert, og det er den innloggingen HSM-en vurderer.

AWS CloudHSM er en nyttig referanse fordi dokumentasjonen holder de to fra hverandre: HSM-brukere er forskjellige fra IAM-brukere, og brukertypen avgjør hva kontoen kan gjøre. En kryptooffiser administrerer brukere og nøkler, men er ikke identiteten som utfører kryptografiske operasjoner, mens en kryptobruker kan bruke nøkler uten å kunne administrere dem. Den delingen er formen du vil ha også på en annen leverandørs enhet, der rollenavnene vil være forskjellige.

Uansett hvilken identitet du utsteder, må den kunne fjernes og tilskrives med den detaljgraden du trenger senere. Én delt operativ legitimasjon på tvers av flere partnere gjør inneslutning og ansvarlighet vanskeligere nettopp i hendelsen der begge betyr mest.

Tredje port: hvilken nøkkel, og hvilken operasjon

Signering, dekryptering, nøkkelgenerering, nøkkelinnpakking og brukeradministrasjon er separate tillatelser og må listes opp hver for seg. I PKCS#11-termer beskriver attributter som CKA_SENSITIVE og CKA_EXTRACTABLE om nøkkelmateriale kan forlate modulen i brukbar form, og de settes per nøkkel og ikke per enhet. Les den faktiske policyen på nøkkelen i stedet for å slutte ikke-eksporterbarhet fra ordet maskinvare eller fra tilstedeværelsen av en tunnel.

Finn så forretningsgodkjenningen. Hvis bare godkjente dokumenter kan signeres, hvilken komponent fastslår den godkjenningen før forespørselen når HSM-en? Et kryptografisk grensesnitt som godtar en autorisert forespørsel, aner ikke om dokumentet er gjennomgått, så den kontrollen tilhører tjenesten foran det.

En tillatt klient som er kompromittert kan også misbruke operasjonene legitimasjonen dens lovlig autoriserer, uten noen gang å trekke ut en privat nøkkel. Å beskytte lagret nøkkelmateriale og å kontrollere nøkkelbruk er derfor to akseptbetingelser, ikke én.

Avslag er en del av aksepttesten

Godta den tillatte signeringsforespørselen, og godta også avslagene: en uautorisert identitet, en urelatert nøkkel og en administrasjonsoperasjon fra partnerens bane. Logg den som kaller, operasjonen, nøkkelidentifikatoren, tidspunktet og utfallet, og hold privat nøkkelmateriale, legitimasjon og dokumentinnhold utenfor generelle diagnostikklagger.

Tildel en eier for partnerens utmelding, for en mistenkt kompromittering på partnersiden, og for policyendringer og gjenoppretting. Å endre en rute gjenoppretter ikke tillit til en vert som kanskje allerede er kompromittert, så tilbakekallingen må også nå HSM-identiteten.

Et fullført VPN-håndtrykk hører hjemme i den oversikten. Det kan ikke erstatte et eneste HSM-spesifikt resultat.