Vennoottoegang tot 'n HSM oor 'n VPN: definieer die sleutelbewerkings

Iemand by die vennoot moet 'n dokument met een aangewese sleutel onderteken, en die versoek kom in netwerktaal aan: hulle moet die HSM bereik. Behandel daardie sin as 'n simptoom van 'n ongedefinieerde dienskontrak eerder as 'n roeteprobleem, want 'n tonnel wat die toestel bereik, verleen op sigself niks nie. Agter die versoek lê drie hekke: bereikbaarheid, HSM-identiteit en sleutelbeleid, en elkeen word op 'n ander plek deur 'n ander span geadministreer. Skryf hulle een vir een neer, anders eindig jy met die verlening van 'n roete omdat die sertifikaatgesprek moeiliker was.

Hou die konkrete geval in die oog: die vennoot dien 'n goedgekeurde dokument vir ondertekening met een genoemde sleutel in, en niks anders nie. Alles hieronder volg uit daardie enkele sin.

Bereikbaarheid, identiteit en sleutelbeleid is drie hekke

Die VPN-konsentrator besluit wie 'n tonnel mag oopmaak en watter adresse hulle mag aanraak. Die HSM besluit op sy eie watter gebruikersrekord wat aan hom voorgelê word, mag aanmeld. Die sleutelbeleid besluit dan wat daardie gebruikersrekord met een spesifieke sleutel mag doen. Om die eerste hek verby te steek, laat die ander twee presies soos hulle was, en daarom bewys 'n suksesvolle handdruk so min en kan 'n vennoot die toestel bereik en tog elke bewerking faal.

Koppel elke hek aan 'n eienaar voordat jy vereistes skryf. Wanneer niemand die tweede een besit nie, is die gewone uitkoms dat 'n breë HSM-administrateuridentiteit uitgedeel word omdat dit die enigste geloofsbrief is wat werk.

Hek een: die netwerkpad wat die vennoot kry

Noem die goedgekeurde kliënt of diens, die bestemming wat dit nodig het, en die protokol en poort waarop daardie diens luister. Beperk dan die VPN-kant se toegang tot daardie paar in beide rigtings, insluitend die terugpad, sodat die beleid 'n sin is wat jy aan die vennoot kan voorlees. Poortbeheer, HSM-bestuurskoppelvlakke en onverwante interne stelsels moet buite gewone vennoottoegang lê, nie net buite die verstekroete nie.

'n Toegewyde segment maak daardie oorgange sigbaar, maar die naam van 'n segment dwing niks af nie. Verkeer moet deur die beheer gaan wat jy dink dit gaan deur. Om 'n verbinding van die vennoot toe te laat, is ook nie 'n verklaring dat elke masjien by die vennoot betroubaar is nie.

Hek twee: wat werklik by die HSM verifieer

'n VPN-identiteit en 'n HSM-identiteit is afsonderlike objekte tensy 'n ondersteunde integrasie hulle doelbewus saamvoeg. Met 'n PKCS#11-kliënt voer die toepassing 'n aanmelding teen 'n slot uit met 'n geloofsbrief wat ergens op die vennoot se gasheer gestoor is, en dit is daardie aanmelding wat die HSM evalueer.

AWS CloudHSM is 'n nuttige verwysing omdat sy dokumentasie die twee apart hou: HSM-gebruikers verskil van IAM-gebruikers, en die gebruikerstipe bepaal wat die rekening mag doen. 'n Kripto-offisier bestuur gebruikers en sleutels, maar is nie die identiteit wat kriptografiese bewerkings uitvoer nie, terwyl 'n kripto-gebruiker sleutels kan gebruik sonder om hulle te kan bestuur. Daardie skeiding is die vorm wat jy wil hê, selfs op 'n ander verskaffer se toestel, waar die rolname sal verskil.

Watter identiteit jy ook al uitreik, dit moet verwyderbaar en toeskryfbaar wees op die korreligheid wat jy later nodig sal hê. Een gedeelde operasionele geloofsbrief oor verskeie vennote maak indamming en verantwoordbaarheid moeiliker in juis die voorval waar albei die meeste saak maak.

Hek drie: watter sleutel, en watter bewerking

Ondertekening, ontsyfering, sleutelgenerering, sleutelomhulling en gebruikersadministrasie is afsonderlike toestemmings en moet afsonderlik gelys word. In PKCS#11-terme beskryf eienskappe soos CKA_SENSITIVE en CKA_EXTRACTABLE of sleutelmateriaal die module in bruikbare vorm kan verlaat, en hulle word per sleutel eerder as per toestel gestel. Lees die werklike beleid op die sleutel eerder as om nie-uitvoerbaarheid af te lei uit die woord hardeware of uit die teenwoordigheid van 'n tonnel.

Soek dan die besigheidgoedkeuring. As slegs goedgekeurde dokumente onderteken mag word, watter komponent vestig daardie goedkeuring voordat die versoek die HSM bereik? 'n Kriptografiese koppelvlak wat 'n gemagtigde versoek aanvaar, het geen idee of die dokument nagegaan is nie, so daardie kontrole hoort by die diens voor dit.

'n Toegelate kliënt wat gekompromitteer is, kan ook die bewerkings misbruik wat sy geloofsbrief wettig magtig sonder om ooit 'n private sleutel te onttrek. Die beskerming van gestoorde sleutelmateriaal en die beheer van sleutelgebruik is dus twee aanvaardingsvoorwaardes, nie een nie.

Weierings is deel van die aanvaardingstoets

Aanvaar die toegelate ondertekeningsversoek, en aanvaar ook die weierings: 'n ongemagtigde identiteit, 'n onverwante sleutel en 'n bestuursbewerking vanaf die vennoot se pad. Teken die oproeper, die bewerking, die sleutelidentifiseerder, die tyd en die uitkoms aan, en hou private sleutelmateriaal, geloofsbriewe en dokumentinhoud uit algemene diagnostiese logboeke.

Wys 'n eienaar aan vir vennoot-uitfasering, vir 'n vermoede van kompromittering aan die vennoot se kant, en vir beleidsveranderings en herstel. Om 'n roete te verander, herstel nie vertroue in 'n gasheer wat moontlik reeds gekompromitteer is nie, so herroeping moet ook die HSM-identiteit bereik.

'n Voltooide VPN-handdruk hoort in daardie rekord. Dit kan nie in die plek van 'n enkele HSM-spesifieke resultaat staan nie.