Aksesi i partnerit në HSM përmes një VPN: përcaktoni operacionet e çelësit

Dikush te partneri duhet të nënshkruajë një dokument me një çelës të caktuar, dhe kërkesa vjen e formuluar si çështje rrjeti: duhet të arrijnë HSM. Trajtojeni atë fjali si simptom të një kontrate shërbimi të papërcaktuar, jo si problem rrugëtimi, sepse një tunel që arrin pajisjen nuk jep asgjë në vetvete. Pas kërkesës qëndrojnë tre porta: arritshmëria, identiteti i HSM dhe politika e çelësit, dhe secila administrohet në një vend tjetër nga një ekip tjetër. Shkruajini një nga një, përndryshe do të përfundoni duke dhënë një rrugë sepse biseda për certifikatën ishte më e vështirë.

Mbajeni rastin konkret para sysh: partneri dorëzon një dokument të miratuar për nënshkrim me një çelës të emërtuar, dhe asgjë tjetër. Gjithçka më poshtë rrjedh nga ajo fjali e vetme.

Arritshmëria, identiteti dhe politika e çelësit janë tre porta

Koncentratori VPN vendos kush mund të hapë një tunel dhe cilat adresa mund të prekë. HSM vendos vetë cili regjistrim përdoruesi i paraqitur para tij mund të hyjë. Pastaj politika e çelësit vendos çfarë mund të bëjë ai regjistrim përdoruesi me një çelës të caktuar. Kalimi i portës së parë i lë dy të tjerat pikërisht ashtu si ishin, prandaj një shtrëngim duarsh i suksesshëm provon kaq pak dhe prandaj partneri mund të arrijë pajisjen dhe gjithsesi të dështojë në çdo operacion.

Caktoni një pronar për çdo portë përpara se të shkruani kërkesat. Kur askush nuk zotëron të dytën, rezultati i zakonshëm është që lëshohet një identitet i gjerë administratori HSM, sepse është kredenciali i vetëm që funksionon.

Porta e parë: rruga e rrjetit që i jepet partnerit

Përmendni klientin ose shërbimin e miratuar, destinacionin që i nevojitet, dhe protokollin e portën në të cilat ai shërbim dëgjon. Pastaj kufizoni aksesin nga ana e VPN në atë çift në të dy drejtimet, duke përfshirë rrugën e kthimit, që politika të jetë një fjali që mund t'ia lexoni partnerit. Administrimi i portës, ndërfaqet e menaxhimit të HSM dhe sistemet e brendshme të palidhura duhet të qëndrojnë jashtë aksesit të zakonshëm të partnerit, jo vetëm jashtë rrugës së parazgjedhur.

Një segment i dedikuar i bën të dukshme ato kalime, por emri i një segmenti nuk zbaton asgjë. Trafiku duhet të kalojë përmes kontrollit për të cilin mendoni se kalon. Pranimi i një lidhjeje nga partneri nuk është as deklaratë se çdo makinë te partneri është e besueshme.

Porta e dytë: çfarë autentifikohet vërtet te HSM

Një identitet VPN dhe një identitet HSM janë objekte të ndara, përveç nëse një integrim i mbështetur i bashkon me dashje. Me një klient PKCS#11, aplikacioni kryen një hyrje në një slot me një kredencial të ruajtur diku në hostin e partnerit, dhe pikërisht këtë hyrje vlerëson HSM.

AWS CloudHSM është një referencë e dobishme sepse dokumentacioni i tij i mban të dy të ndarë: përdoruesit e HSM janë të veçantë nga përdoruesit e IAM, dhe lloji i përdoruesit përcakton çfarë mund të bëjë llogaria. Një oficer kripto menaxhon përdoruesit dhe çelësat, por nuk është identiteti që kryen operacione kriptografike, ndërsa një përdorues kripto mund të përdorë çelësat pa mundur t'i menaxhojë. Ai ndarje është forma që dëshironi edhe në pajisjen e një furnizuesi tjetër, ku emrat e roleve do të jenë të ndryshëm.

Çfarëdo identiteti që lëshoni, ai duhet të jetë i heqshëm dhe i atribueshëm në atë hollësi që do t'ju nevojitet më vonë. Një kredencial i vetëm operativ i përbashkët për disa partnerë e bën përmbajtjen dhe përgjegjshmërinë më të vështirë pikërisht në incidentin ku të dyja kanë rëndësinë më të madhe.

Porta e tretë: cili çelës dhe cili operacion

Nënshkrimi, dekriptimi, gjenerimi i çelësave, mbështjellja e çelësave dhe administrimi i përdoruesve janë leje të ndara dhe duhet të renditen veçmas. Në terma PKCS#11, atributet si CKA_SENSITIVE dhe CKA_EXTRACTABLE përshkruajnë nëse materiali i çelësit mund të dalë nga moduli në formë të përdorshme, dhe ato vendosen për çdo çelës, jo për pajisjen. Lexoni politikën aktuale mbi çelësin në vend që të nxirrni mospasjeportueshmërinë nga fjala harduer ose nga prania e një tuneli.

Pastaj gjeni miratimin e biznesit. Nëse vetëm dokumentet e miratuara mund të nënshkruhen, cili komponent e vendos atë miratim përpara se kërkesa të arrijë HSM? Një ndërfaqe kriptografike që pranon një kërkesë të autorizuar nuk e ka idenë nëse dokumenti u shqyrtua, prandaj ai kontroll i takon shërbimit përpara saj.

Një klient i lejuar që komprometohet mund të abuzojë edhe me operacionet që kredenciali i tij autorizon ligjërisht, pa nxjerrë kurrë një çelës privat. Prandaj mbrojtja e materialit të çelësit të ruajtur dhe kontrolli i përdorimit të çelësave janë dy kushte pranimi, jo një.

Refuzimet janë pjesë e provës së pranimit

Pranoni kërkesën e lejuar të nënshkrimit dhe pranoni gjithashtu refuzimet: një identitet të paautorizuar, një çelës të palidhur dhe një operacion menaxhimi nga rruga e partnerit. Regjistroni thirrësin, operacionin, identifikuesin e çelësit, kohën dhe rezultatin, dhe mbani materialin privat të çelësit, kredencialet dhe përmbajtjen e dokumenteve jashtë regjistrave të përgjithshëm të diagnostikimit.

Caktoni një pronar për daljen e partnerit, për një dyshim komprometimi nga ana e partnerit, dhe për ndryshimet e politikës dhe rikuperimin. Ndryshimi i një rruge nuk e rikthen besimin te një host që mund të jetë komprometuar tashmë, prandaj anulimi duhet të arrijë edhe identitetin e HSM.

Një shtrëngim duarsh VPN i përfunduar i takon atij regjistri. Ai nuk mund të zëvendësojë asnjë rezultat specifik për HSM.