Accesul partenerului la HSM printr-o VPN: definiți operațiile cu chei

Cineva din partea partenerului trebuie să semneze un document cu o cheie desemnată, iar cererea vine formulată ca o chestiune de rețea: trebuie să ajungă la HSM. Tratați acea propoziție ca pe un simptom al unui contract de serviciu nedefinit, nu ca pe o problemă de rutare, pentru că un tunel care ajunge la dispozitiv nu acordă nimic prin el însuși. În spatele cererii stau trei porți: accesibilitatea, identitatea HSM și politica de chei, iar fiecare este administrată într-un alt loc de o altă echipă. Scrieți-le una câte una, altfel veți ajunge să acordați o rută pentru că discuția despre certificat a fost mai dificilă.

Țineți în vedere cazul concret: partenerul depune un document aprobat pentru semnare cu o cheie numită, și nimic altceva. Tot ce urmează decurge din acea singură propoziție.

Accesibilitatea, identitatea și politica de chei sunt trei porți

Concentratorul VPN decide cine poate deschide un tunel și ce adrese poate atinge. HSM-ul decide singur ce înregistrare de utilizator prezentată în fața sa se poate autentifica. Politica de chei decide apoi ce poate face acea înregistrare de utilizator cu o cheie anume. Trecerea primei porți le lasă pe celelalte două exact cum erau, de aceea un handshake reușit dovedește atât de puțin și de aceea un partener poate ajunge la dispozitiv și totuși eșua la fiecare operație.

Atribuiți un proprietar fiecărei porți înainte de a scrie cerințele. Când nimeni nu deține a doua, rezultatul obișnuit este că se emite o identitate largă de administrator HSM, pentru că este singura acreditare care funcționează.

Prima poartă: calea de rețea oferită partenerului

Numiți clientul sau serviciul aprobat, destinația de care are nevoie, precum și protocolul și portul pe care acel serviciu ascultă. Apoi limitați accesul din partea VPN la acea pereche în ambele direcții, inclusiv calea de întoarcere, astfel încât politica să fie o propoziție pe care o puteți citi partenerului. Administrarea gateway-ului, interfețele de gestionare ale HSM și sistemele interne nelegate trebuie să stea în afara accesului obișnuit al partenerului, nu doar în afara rutei implicite.

Un segment dedicat face vizibile acele traversări, dar numele unui segment nu impune nimic. Traficul trebuie să treacă prin controlul prin care credeți că trece. Admiterea unei conexiuni de la partener nu este nici ea o afirmație că fiecare mașină de la partener este de încredere.

A doua poartă: ce se autentifică de fapt la HSM

O identitate VPN și o identitate HSM sunt obiecte separate dacă o integrare acceptată nu le unește în mod deliberat. Cu un client PKCS#11, aplicația efectuează o autentificare la un slot cu o acreditare stocată undeva pe gazda partenerului, iar acea autentificare este ceea ce evaluează HSM-ul.

AWS CloudHSM este o referință utilă pentru că documentația sa le ține separate: utilizatorii HSM sunt diferiți de utilizatorii IAM, iar tipul de utilizator determină ce poate face contul. Un ofițer cripto gestionează utilizatori și chei, dar nu este identitatea care efectuează operații criptografice, în timp ce un utilizator cripto poate folosi chei fără a le putea gestiona. Acea separare este forma dorită chiar și pe dispozitivul altui furnizor, unde numele rolurilor vor fi diferite.

Orice identitate emiteți trebuie să poată fi eliminată și atribuită la granularitatea de care veți avea nevoie mai târziu. O singură acreditare operațională partajată între mai mulți parteneri face izolarea și responsabilitatea mai dificile exact în incidentul în care ambele contează cel mai mult.

A treia poartă: care cheie și care operație

Semnarea, decriptarea, generarea de chei, ambalarea cheilor și administrarea utilizatorilor sunt permisiuni separate și trebuie listate separat. În termenii PKCS#11, atributele precum CKA_SENSITIVE și CKA_EXTRACTABLE descriu dacă materialul cheii poate părăsi modulul într-o formă utilizabilă, iar ele sunt setate per cheie, nu per dispozitiv. Citiți politica reală de pe cheie în loc să deduceți neexportabilitatea din cuvântul hardware sau din prezența unui tunel.

Apoi găsiți aprobarea de business. Dacă doar documentele aprobate pot fi semnate, ce componentă stabilește acea aprobare înainte ca cererea să ajungă la HSM? O interfață criptografică ce acceptă o cerere autorizată nu are habar dacă documentul a fost verificat, așa că acea verificare aparține serviciului din fața ei.

Un client permis care este compromis poate abuza și de operațiile pe care acreditarea sa le autorizează în mod legitim, fără a extrage vreodată o cheie privată. Protejarea materialului de cheie stocat și controlul utilizării cheilor sunt, prin urmare, două condiții de acceptare, nu una.

Refuzurile fac parte din testul de acceptare

Acceptați cererea de semnare permisă și acceptați și refuzurile: o identitate neautorizată, o cheie nelegată și o operație de administrare din calea partenerului. Înregistrați apelantul, operația, identificatorul cheii, timpul și rezultatul, iar materialul de cheie privată, acreditările și conținutul documentelor țineți-le în afara jurnalelor de diagnostic generale.

Atribuiți un proprietar pentru ieșirea partenerului, pentru o suspiciune de compromitere de partea partenerului și pentru modificările de politică și recuperare. Schimbarea unei rute nu restaurează încrederea într-o gazdă care poate fi deja compromisă, așa că revocarea trebuie să ajungă și la identitatea HSM.

Un handshake VPN finalizat aparține acelui registru. Nu poate ține locul unui singur rezultat specific HSM.