The Challenge of Successfully Incorporating HSM Security Within Cloud Environments
- Itsik Musseri
- 3 minute read
Companies that have a continued need to protect confidential data and maintain regulatory compliance, regardless of whether they handle payment information, customer profiles, or valuable business data, routinely adopt multiple security safeguards. One common safeguard is a Hardware Security Module (HSM) - which within the cloud migration context, becomes one of the most complex issues to solve.
The way HSM works
In favor of the readers that aren't certain what is HSM all about let's unpack the use and definition of hardware security modules:
HSM acts as a trust anchor and provides protection for identities, applications, and transactions by ensuring strong encryption, decryption, and authentication for a wide variety of applications. The HSM includes protection features, such as physical tamper resistance and strong authentication, and in the case of smart cards, an HSM can be physically isolated thereby making it virtually invulnerable to attacks over a network.
HSM capabilities can be obtained by companies in multiple delivery formats and each model provides its own set of advantages and disadvantages that decision makers must carefully weigh against each other.
This is the model typically supporting legacy IT where a physical HSM is within a company’s data centre and managed by their IT operations.
Public Cloud Service Provider HSM
This type of HSM is a cloud-hosted hardware security module service on a cloud service provider’s platform, such as AWS Hardware Security Module. This model normally permits the hosting of encryption keys and performs cryptographic operations. It follows a fully managed service, where sensitive workloads can be protected without the need to worry about the operational overhead of managing an HSM cluster.
3rd Party HSM-as-a-Service
This model is an alternative to on-premises HSM or a Public Cloud Service Provider HSM. It uses a private connection between the provider and the client, thereby offering on-premise HSM-grade security for key management and the consistency of a single administrative environment, regardless of where encryption keys are used.
HSM, Key Management, Cloud migration - and everything in Between
The fundamental problem that companies face is how to best protect and manage “the keys to the kingdom” in a distributed environment where applications can be designed for on-premise, purely as cloud-native, or a hybrid IT architecture with an application’s individual workloads distributed across both on-premise data centers within the direct control of the company and within public cloud services not fully under their control.
In order to understand the magnitude of the problem facing companies, it is important to look at the problem from multiple layers.
- The first layer involves the fact that there are a number of vendors that represent each of the key delivery models – On-Premise HSM, Public Cloud Service Provider HSM, and 3rd Party HSM-as-a-Service. This means that in a hybrid IT adoption approach companies must first have strong vendor management practices established since they must deal with each vendor having their own release schedule for capability updates or security patches. Developers and Configuration Management resources must understand varying API service definitions, assess which functionality or capability features to enable within each product, and determine how to best integrate the products into the enterprise.
- Managing the platform is another layer that becomes more complicated as IT teams must support cloud to ground network connectivity and inter-connectivity between multiple cloud service providers. However, the Public Cloud Service Provider HSM and 3rd Party HSM-as-a-Service options change the IT operating model of a company, such that the processing of secrets, and the traditional IT role of performing updates and maintenance is now deferred to the cloud service provider. As companies reduce the need to execute these operational tasks, they must ensure that a more agile mindset is adopted internally, thereby continually being ready to assess the impact of changes made by the cloud service provider and ensure end-to-end testing can be completed with no, or only marginal, service interruption to their systems and business applications. In fact, this requires strong internal partner management capabilities as routinely described in DevOps models requiring Continuous Integration / Continuous Deployment (CI/CD) pipelines.
- Furthermore, the complexity of managing the platform increases as the number of moving parts required to coordinate a single change grows. Without the ability to manage each HSM in a single pane of glass as a unified service, then IT operations must continually monitor each constituent part and then stitch performance and monitoring data together with additional technologies.
In summary, companies wanting to successfully adopt cloud must be prepared for the difficult task of integrating their systems and applications with any plausible combination of the three HSM delivery models. Achieving this success without some degree of code changes or no integration barriers is not realistic. Companies need a ‘hardware’ degree of security and performance with the ‘software’ degree of usability and agility. The business goal should be to advocate the continued need to uniformly push regulatory and compliance needs across the enterprise and not settle for excuses based on siloed process problems or perceived technology limitations.