Client to HSM Security Best Practices

While the Luna HSM is very secure, it is not the only component in the overall system. The HSM's application partitions become useful when client applications can communicate with those partitions, however this expands the potential attack surface. Good practices can go a long way toward minimizing that exposure.

This section suggests areas where practical choices and consistency can enhance security without sacrificing operational convenience.

Security around Password-authenticated systems

Two things must be secured:

>NTLS private key,

>partition password.

Securing the partition password

The partition password is needed when logging in, so the primary means of protecting the partition password is to protect the connection to the HSM via NTLS or STC. NTLS and STC certificates reside in a subdirectory of the Luna HSM Client directory, on every system that connects to an application partition on a Luna Network HSM.

To secure an enterprise connection to the HSM the following means are available:  

>Use operating system controls and permissions on the client to prevent unauthorized users from accessing the key material.

>Use network segregation / software-defined networking or subnetting to prevent unauthorized machines from accessing the network HSM at all.

>Implement a full firewall security flow policy, to assist in preventing unauthorized network access, allowing only certain IP addresses and ports to be open to the network HSM.

>Practice proper password hygiene, in the form of a key and partition password-rotation policy, to prevent over-exposure should an NTLS key and/or partition password be compromised. (See sysconf user commands and Manage Appliance User Passwords.)

Securing the NTLS private key

To secure a PaaS*/container connection to the HSM the following means are available:

>make use of whatever vault or secret-store approach a given PaaS implementation provides but ensure that it is truly secure and not merely a pretense of "security"-by-obfuscation  

>avoid bundling NTLS keys or partition passwords in VM/container images, but instead use the aforementioned PaaS vault/secret  

>if the PaaS implementation provides some form of service mesh, then take advantage of it to further mitigate client private-key/partition-password vulnerability, as the service mesh would prevent an attacker from being able to use the key/password outside of the service mesh; this forces the attacker to use the exposed material in a more secure and monitored environment, where the attack could be outright prevented or at least detected much sooner.

(*PaaS = Platform as a Service)