Partner HSM Access Over a VPN: Define the Key Operations

Somebody at the partner has to sign a document with one designated key, and the request arrives phrased as networking: they need to reach the HSM. Treat that sentence as a symptom of an undefined service contract rather than a routing problem, because a tunnel that reaches the appliance grants nothing by itself. Three gates sit behind the request, reachability, HSM identity and key policy, and each is administered in a different place by a different team. Write them down one at a time or you will end up granting a route because the certificate conversation was harder.

Keep the concrete case in view: the partner submits an approved document for signature with one named key, and nothing else. Everything below follows from that single sentence.

Reachability, identity and key policy are three gates

The VPN concentrator decides who may open a tunnel and which addresses they may touch. The HSM decides, on its own, which user record presented to it may log in. The key policy then decides what that user record may do with one specific key. Passing the first gate leaves the other two exactly as they were, which is why a successful handshake proves so little and why a partner can reach the appliance and still fail every operation.

Map each gate to an owner before writing requirements. When nobody owns the second one, the usual outcome is that a broad HSM administrator identity gets handed out because it is the only credential that works.

Gate one: the network path the partner is given

Name the approved client or service, the destination it needs, and the protocol and port that service listens on. Then limit the VPN-side access to that pair in both directions, including the return path, so the policy is a sentence you can read back to the partner. Gateway administration, HSM management interfaces and unrelated internal systems should sit outside ordinary partner access, not merely outside the default route.

A dedicated segment makes those crossings visible, but the name of a segment enforces nothing. Traffic has to pass through the control you think it passes through. Admitting a connection from the partner is also not a statement that every machine at the partner is trustworthy.

Gate two: what actually authenticates to the HSM

A VPN identity and an HSM identity are separate objects unless a supported integration deliberately joins them. With a PKCS#11 client, the application performs a login against a slot with a credential stored somewhere on the partner's host, and that login is what the HSM evaluates.

AWS CloudHSM is a useful reference because its documentation keeps the two apart: HSM users are distinct from IAM users, and user type governs what the account may do. A crypto officer manages users and keys but is not the identity that performs cryptographic operations, while a crypto user can use keys without being able to manage them. That split is the shape you want even on a different vendor's appliance, where the role names will differ.

Whatever identity you issue, it has to be removable and attributable at the granularity you will need later. One shared operational credential across several partners makes containment and accountability harder in exactly the incident where both matter most.

Gate three: which key, and which operation

Signing, decryption, key generation, key wrapping and user administration are separate permissions and must be listed separately. In PKCS#11 terms, attributes such as CKA_SENSITIVE and CKA_EXTRACTABLE describe whether key material can leave the module in usable form, and they are set per key rather than per appliance. Read the actual policy on the key instead of inferring non-exportability from the word hardware or from the presence of a tunnel.

Then find the business approval. If only approved documents may be signed, which component establishes that approval before the request reaches the HSM? A cryptographic interface that accepts an authorised request has no idea whether the document was reviewed, so that check belongs to the service in front of it.

A permitted client that is compromised can also misuse the operations its credential legitimately authorises without ever extracting a private key. Protecting stored key material and controlling key use are therefore two acceptance conditions, not one.

Denials are part of the acceptance test

Accept the permitted signing request, and accept the refusals as well: an unauthorised identity, an unrelated key, and a management operation from the partner's path. Record the caller, the operation, the key identifier, the time and the outcome, and keep private key material, credentials and document contents out of general diagnostic logs.

Assign an owner for partner offboarding, for a suspected compromise on the partner side, and for policy changes and recovery. Changing a route does not restore trust in a host that may already be compromised, so revocation has to reach the HSM identity as well.

A completed VPN handshake belongs in that record. It cannot stand in for a single HSM-specific result.