HSM-tilgang for partnaren over ein VPN: definer nøkkeloperasjonane

Nokon hos partnaren må signere eit dokument med éin angitt nøkkel, og førespurnaden kjem formulert som eit nettverksspørsmål: dei må nå HSM-en. Behandle den setninga som eit symptom på ein udefinert tenesteavtale og ikkje som eit ruteproblem, fordi ein tunnel som når eininga ikkje gir noko i seg sjølv. Tre portar ligg bak førespurnaden: tilgjenge, HSM-identitet og nøkkelpolicy, og kvar av dei blir administrert på ein annan stad av eit anna team. Skriv dei ned éin om gongen, elles endar du med å gi ein rute fordi samtalen om sertifikatet var vanskelegare.

Hald det konkrete tilfellet framfor auga: partnaren sender inn eit godkjent dokument for signering med éin namngitt nøkkel, og ingenting anna. Alt nedanfor følgjer av den eine setninga.

Tilgjenge, identitet og nøkkelpolicy er tre portar

VPN-konsentratoren avgjer kven som kan opne ein tunnel og kva adresser dei kan røre. HSM-en avgjer sjølv kva brukaroppføring som blir lagd fram for han, og som kan logge inn. Nøkkelpolicyen avgjer deretter kva den brukaroppføringa kan gjere med éin bestemt nøkkel. Å passere den første porten lèt dei to andre vere nøyaktig som dei var, og difor beviser eit vellukka handtrykk så lite, og difor kan ein partnar nå eininga og likevel mislukkast i kvar operasjon.

Knyt kvar port til ein eigar før du skriv krav. Når ingen eig den andre, er det vanlege resultatet at ein brei HSM-administratoridentitet blir delt ut, fordi det er den einaste legitimasjonen som verkar.

Første port: nettverksvegen partnaren får

Namngi den godkjende klienten eller tenesta, målet ho treng, og protokollen og porten den tenesta lyttar på. Avgrens deretter tilgangen frå VPN-sida til det paret i begge retningar, inkludert returvegen, slik at policyen blir ei setning du kan lese opp for partnaren. Gateway-administrasjon, HSM-administrasjonsgrensesnitt og urelaterte interne system bør liggje utanfor vanleg partnartilgang, ikkje berre utanfor standardruta.

Eit dedikert segment gjer desse kryssingane synlege, men namnet på eit segment handhevar ingenting. Trafikken må passere gjennom den kontrollen du trur han passerer. Å sleppe inn ei tilkopling frå partnaren er heller ikkje ei erklæring om at kvar maskin hos partnaren er påliteleg.

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

Ein VPN-identitet og ein HSM-identitet er separate objekt med mindre ein støtta integrasjon medvite slår dei saman. Med ein PKCS#11-klient utfører applikasjonen ei innlogging mot ein slot med ein legitimasjon som er lagra ein stad på verten til partnaren, og det er den innlogginga HSM-en vurderer.

AWS CloudHSM er ei nyttig referanse fordi dokumentasjonen held dei to frå kvarandre: HSM-brukarar er forskjellige frå IAM-brukarar, og brukartypen avgjer kva kontoen kan gjere. Ein kryptooffiser administrerer brukarar og nøklar, men er ikkje identiteten som utfører kryptografiske operasjonar, medan ein kryptobrukar kan bruke nøklar utan å kunne administrere dei. Den delinga er forma du vil ha også på eininga til ein annan leverandør, der rollenamna vil vere forskjellige.

Kva identitet du enn gjev ut, må han kunne fjernast og tilskrivast med den detaljgraden du treng seinare. Éin delt operativ legitimasjon på tvers av fleire partnarar gjer inneslutning og ansvarlegheit vanskelegare nettopp i hendinga der begge tyder mest.

Tredje port: kva nøkkel, og kva operasjon

Signering, dekryptering, nøkkelgenerering, nøkkelinnpakking og brukaradministrasjon er separate løyve og må listast opp kvar for seg. I PKCS#11-termar skildrar attributt som CKA_SENSITIVE og CKA_EXTRACTABLE om nøkkelmateriale kan forlate modulen i brukbar form, og dei blir sette per nøkkel og ikkje per eining. Les den faktiske policyen på nøkkelen i staden for å slutte ikkje-eksporterbarheit frå ordet maskinvare eller frå tilstadeveret av ein tunnel.

Finn så forretningsgodkjenninga. Viss berre godkjende dokument kan signerast, kva komponent fastset den godkjenninga før førespurnaden når HSM-en? Eit kryptografisk grensesnitt som godtar ein autorisert førespurnad, veit ikkje om dokumentet er gjennomgått, så den kontrollen høyrer til tenesta framfor det.

Ein tillaten klient som er kompromittert kan også misbruke operasjonane legitimasjonen hans lovleg autoriserer, utan nokon gong å trekkje ut ein privat nøkkel. Å verne lagra nøkkelmateriale og å kontrollere nøkkelbruk er difor to akseptvilkår, ikkje eitt.

Avslag er ein del av aksepttesten

Godta den tillatne signeringsførespurnaden, og godta også avslaga: ein uautorisert identitet, ein urelatert nøkkel og ein administrasjonsoperasjon frå banen til partnaren. Logg den som kallar, operasjonen, nøkkelidentifikatoren, tidspunktet og utfallet, og hald privat nøkkelmateriale, legitimasjon og dokumentinnhald utanfor generelle diagnostikklaggar.

Tildel ein eigar for utmelding av partnaren, for ein mistenkt kompromittering på partnarsida, og for policyendringar og gjenoppretting. Å endre ein rute gjenopprettar ikkje tillit til ein vert som kanskje allereie er kompromittert, så tilbakekallinga må også nå HSM-identiteten.

Eit fullført VPN-handtrykk høyrer heime i den oversikta. Det kan ikkje erstatte eit einaste HSM-spesifikt resultat.