Partner-HSM-toegang via een VPN: definieer de sleutelbewerkingen

Iemand bij de partner moet een document ondertekenen met één aangewezen sleutel, en het verzoek komt binnen als een netwerkvraag: ze moeten de HSM bereiken. Behandel die zin als een symptoom van een ongedefinieerd servicecontract en niet als een routeringsprobleem, want een tunnel die het apparaat bereikt, geeft op zichzelf niets. Achter het verzoek zitten drie poorten: bereikbaarheid, HSM-identiteit en sleutelbeleid, en elk ervan wordt op een andere plek door een ander team beheerd. Schrijf ze één voor één op, anders verleen je uiteindelijk een route omdat het gesprek over het certificaat moeilijker was.

Houd het concrete geval voor ogen: de partner dient een goedgekeurd document in voor ondertekening met één genoemde sleutel, en niets anders. Alles hieronder volgt uit die ene zin.

Bereikbaarheid, identiteit en sleutelbeleid zijn drie poorten

De VPN-concentrator bepaalt wie een tunnel mag openen en welke adressen hij mag aanraken. De HSM bepaalt zelf welk gebruikersrecord dat eraan wordt voorgelegd mag inloggen. Het sleutelbeleid bepaalt vervolgens wat dat gebruikersrecord met één specifieke sleutel mag doen. Het passeren van de eerste poort laat de andere twee precies zoals ze waren, daarom bewijst een geslaagde handshake zo weinig en daarom kan een partner het apparaat bereiken en toch elke bewerking mislukken.

Koppel elke poort aan een eigenaar voordat je eisen schrijft. Als niemand de tweede bezit, is de gebruikelijke uitkomst dat een brede HSM-beheerdersidentiteit wordt uitgegeven, omdat dat de enige referentie is die werkt.

Eerste poort: het netwerkpad dat de partner krijgt

Noem de goedgekeurde client of dienst, de bestemming die deze nodig heeft, en het protocol en de poort waarop die dienst luistert. Beperk daarna de toegang vanaf de VPN-kant tot dat paar in beide richtingen, inclusief het retourpad, zodat het beleid een zin is die je de partner kunt voorlezen. Gateway-beheer, HSM-beheerinterfaces en niet-gerelateerde interne systemen horen buiten de gewone partnertoegang te staan, niet alleen buiten de standaardroute.

Een eigen segment maakt die overgangen zichtbaar, maar de naam van een segment dwingt niets af. Verkeer moet door de controle gaan waarvan je denkt dat het erdoorheen gaat. Een verbinding van de partner toelaten is ook geen verklaring dat elke machine bij de partner betrouwbaar is.

Tweede poort: wat zich werkelijk authenticeert bij de HSM

Een VPN-identiteit en een HSM-identiteit zijn afzonderlijke objecten, tenzij een ondersteunde integratie ze bewust samenvoegt. Met een PKCS#11-client voert de toepassing een login uit op een slot met een referentie die ergens op de host van de partner is opgeslagen, en die login is wat de HSM beoordeelt.

AWS CloudHSM is een nuttige referentie omdat de documentatie de twee gescheiden houdt: HSM-gebruikers verschillen van IAM-gebruikers, en het gebruikerstype bepaalt wat het account mag doen. Een crypto-officer beheert gebruikers en sleutels maar is niet de identiteit die cryptografische bewerkingen uitvoert, terwijl een crypto-gebruiker sleutels kan gebruiken zonder ze te kunnen beheren. Die splitsing is de vorm die je ook op het apparaat van een andere leverancier wilt, waar de rolnamen zullen verschillen.

Welke identiteit je ook uitgeeft, deze moet verwijderbaar en toerekenbaar zijn op de granulariteit die je later nodig hebt. Eén gedeelde operationele referentie over meerdere partners maakt indamming en verantwoording juist moeilijker in het incident waarin beide het meest tellen.

Derde poort: welke sleutel, en welke bewerking

Ondertekenen, ontsleutelen, sleutelgeneratie, sleutelverpakking en gebruikersbeheer zijn afzonderlijke machtigingen en moeten afzonderlijk worden vermeld. In PKCS#11-termen beschrijven attributen zoals CKA_SENSITIVE en CKA_EXTRACTABLE of sleutelmateriaal de module in bruikbare vorm kan verlaten, en ze worden per sleutel ingesteld en niet per apparaat. Lees het werkelijke beleid op de sleutel in plaats van niet-exporteerbaarheid af te leiden uit het woord hardware of uit de aanwezigheid van een tunnel.

Zoek vervolgens de zakelijke goedkeuring. Als alleen goedgekeurde documenten mogen worden ondertekend, welke component stelt die goedkeuring vast voordat het verzoek de HSM bereikt? Een cryptografische interface die een geautoriseerd verzoek accepteert, weet niet of het document is beoordeeld, dus die controle hoort bij de dienst ervoor.

Een toegestane client die is gecompromitteerd kan ook misbruik maken van de bewerkingen die zijn referentie rechtmatig autoriseert, zonder ooit een privésleutel te extraheren. Het beschermen van opgeslagen sleutelmateriaal en het beheersen van sleutelgebruik zijn daarom twee acceptatievoorwaarden, niet één.

Weigeringen horen bij de acceptatietest

Accepteer het toegestane ondertekeningsverzoek, en accepteer ook de weigeringen: een niet-geautoriseerde identiteit, een niet-gerelateerde sleutel en een beheersbewerking vanaf het pad van de partner. Leg de aanroeper, de bewerking, de sleutelidentificatie, de tijd en de uitkomst vast, en houd privésleutelmateriaal, referenties en documentinhoud buiten algemene diagnoselogs.

Wijs een eigenaar aan voor het uitfaseren van de partner, voor een vermoede compromittering aan de partnerzijde, en voor beleidswijzigingen en herstel. Het wijzigen van een route herstelt het vertrouwen niet in een host die mogelijk al gecompromitteerd is, dus intrekking moet ook de HSM-identiteit bereiken.

Een voltooide VPN-handshake hoort in dat register. Deze kan niet in de plaats staan van één HSM-specifiek resultaat.