Next, let's take a look at the hardware security module.
When you're looking at the services, if it reminds you of what we just
finished discussing for the Trusted Platform Module,
then you're right on track.
What we're doing here with the hardware security module though is actually
removing it from the internal components of a compute system.
When you're looking at FIPS 140‑2, the four levels include level
1, which means the lowest level of security to meet the
requirements for basic cryptographic modules.
That means that you have at least one approved security function or approved
algorithm. Encryption of a PC board is an example of level 1.
Level 2 enhances required physical security mechanisms listed in level 1 and
requires the capabilities exist to illustrate evidence of tampering, so this
would include the system being tamperproof,
having perimeters, having internal covers, and things like locks.
Level 3 also increases upon level 2 and includes preventing the
intruder from gaining access to information and data held within the
cryptographic module, so this would be in conjunction with
additional physical security as well.
At level 4, it's the highest rating that provides the highest level
of security with mechanisms providing complete protection. Detection
of an attempted breach triggers the immediate zeroization of all
plaintext critical security data.
That means that it will actually delete the data if someone is
successfully tampering. What would the justification for a hardware
security module be? Well, imagine if a bad actor is able to compromise
the server system that houses the private key, which is universally
used to decrypt confidential data and provide validation of all data
departing the system,
then that compromise could actually lead to accesses of both
confidentiality and integrity for the entire enterprise.
If you offload the private key material onto the hardware security module,
the compromise of the data doesn't necessarily mean the compromise of the
key. In the cloud, there is also the capability of using hardware security
modules. Here, the cloud consumer could actually be managing their own KMS
system where they generate key material, and that key material could actually
be imported to one or more cloud hardware security modules that will be
available in a dedicated fashion inside of an availability zone of the cloud
service provider.
In this way,
the cloud consumer could then offload the cryptographic function for their data,
their processing, and their compute in a way that protects
them from compromise of those systems actually leading to
compromise of the key material.
If in fact you have multiple availability zones that
you would be participating in,
then the cloud service provider could make it available that there
is replication to other dedicated hardware security modules that
are inside of their cloud environment.
Next, we're going to take a look at security groups.