Partnerns HSM-åtkomst över en VPN: definiera nyckeloperationerna

Någon hos partnern måste signera ett dokument med en angiven nyckel, och begäran kommer formulerad som en nätverksfråga: de måste nå HSM:en. Behandla den meningen som ett symptom på ett odefinierat serviceavtal och inte som ett routingproblem, eftersom en tunnel som når enheten inte ger något i sig själv. Bakom begäran finns tre portar: nåbarhet, HSM-identitet och nyckelpolicyn, och var och en administreras på en annan plats av ett annat team. Skriv ned dem en i taget, annars slutar du med att bevilja en väg eftersom samtalet om certifikatet var svårare.

Håll det konkreta fallet för ögonen: partnern skickar in ett godkänt dokument för signering med en namngiven nyckel, och ingenting annat. Allt nedan följer av den enda meningen.

Nåbarhet, identitet och nyckelpolicyn är tre portar

VPN-koncentratorn avgör vem som får öppna en tunnel och vilka adresser de får vidröra. HSM:en avgör själv vilken användarpost som läggs fram för den och som får logga in. Nyckelpolicyn avgör sedan vad den användarposten får göra med en viss nyckel. Att passera den första porten lämnar de andra två exakt som de var, och därför bevisar en lyckad handskakning så lite och därför kan en partner nå enheten och ändå misslyckas i varje operation.

Knyt varje port till en ägare innan du skriver krav. När ingen äger den andra är det vanliga resultatet att en bred HSM-administratörsidentitet delas ut, eftersom det är den enda behörighet som fungerar.

Första porten: nätverksvägen partnern får

Namnge den godkända klienten eller tjänsten, det mål den behöver, samt protokollet och porten som tjänsten lyssnar på. Begränsa sedan åtkomsten från VPN-sidan till det paret i båda riktningarna, inklusive returvägen, så att policyn blir en mening du kan läsa upp för partnern. Gateway-administration, HSM:ens hanteringsgränssnitt och orelaterade interna system bör ligga utanför partnerns vanliga åtkomst, inte bara utanför standardvägen.

Ett dedikerat segment gör dessa övergångar synliga, men namnet på ett segment genomdriver ingenting. Trafiken måste passera genom den kontroll som du tror att den passerar. Att släppa in en anslutning från partnern är heller inte ett påstående att varje maskin hos partnern är pålitlig.

Andra porten: vad som faktiskt autentiserar sig mot HSM:en

En VPN-identitet och en HSM-identitet är separata objekt om inte en stödd integration medvetet slår samman dem. Med en PKCS#11-klient utför applikationen en inloggning mot en slot med en behörighet som lagras någonstans på partnerns värd, och det är den inloggningen som HSM:en bedömer.

AWS CloudHSM är en användbar referens eftersom dokumentationen håller de två åtskilda: HSM-användare skiljer sig från IAM-användare, och användartypen avgör vad kontot får göra. En kryptoansvarig hanterar användare och nycklar men är inte den identitet som utför kryptografiska operationer, medan en kryptoanvändare kan använda nycklar utan att kunna hantera dem. Den uppdelningen är den form du vill ha även på en annan leverantörs enhet, där rollnamnen kommer att skilja sig.

Vilken identitet du än utfärdar måste den kunna tas bort och tillskrivas med den detaljgrad du behöver senare. En delad operativ behörighet över flera partner gör innestängning och ansvarsskyldighet svårare just i incidenten där båda betyder mest.

Tredje porten: vilken nyckel, och vilken operation

Signering, dekryptering, nyckelgenerering, nyckelinslagning och användaradministration är separata behörigheter och måste listas separat. I PKCS#11-termer beskriver attribut som CKA_SENSITIVE och CKA_EXTRACTABLE om nyckelmaterial kan lämna modulen i användbar form, och de sätts per nyckel och inte per enhet. Läs den faktiska policyn på nyckeln i stället för att sluta dig till icke-exporterbarhet från ordet hårdvara eller från förekomsten av en tunnel.

Hitta sedan affärsgodkännandet. Om bara godkända dokument får signeras, vilken komponent fastställer det godkännandet innan begäran når HSM:en? Ett kryptografiskt gränssnitt som tar emot en auktoriserad begäran har ingen aning om dokumentet har granskats, så den kontrollen tillhör tjänsten framför det.

En tillåten klient som komprometteras kan också missbruka de operationer som dess behörighet lagligen auktoriserar, utan att någonsin extrahera en privat nyckel. Att skydda lagrat nyckelmaterial och att kontrollera nyckelanvändning är därför två acceptansvillkor, inte ett.

Avslag är en del av acceptanstestet

Acceptera den tillåtna signeringsbegäran och acceptera även avslagen: en obehörig identitet, en orelaterad nyckel och en administrationsoperation från partnerns väg. Logga den som anropar, operationen, nyckelidentifieraren, tiden och utfallet, och håll privat nyckelmaterial, behörigheter och dokumentinnehåll utanför allmänna diagnostikloggar.

Tilldela en ägare för partnerns utträde, för en misstänkt kompromettering på partnersidan och för policyändringar och återställning. Att ändra en väg återställer inte förtroendet för en värd som kanske redan är komprometterad, så återkallandet måste även nå HSM-identiteten.

En slutförd VPN-handskakning hör hemma i det registret. Det kan inte ersätta ett enda HSM-specifikt resultat.