Multi-Cloud Key Management: Selection and Migration
Cloud services are typically described as sharing responsibility for security, but the reality is that you don’t working shoulder to shoulder with the vendor. Instead you implement security with the building blocks they provide you, possibly filling in gaps where they don’t provide solutions. One of the central goals of this research project was to show that it is possible to take control of data security, supplanting embedded encryption and key management services, even when you don’t control the environment. And with key management you can gain as much security as your on-premise solution provides – in some cases even continuing leverage familiar tools – with minimal disruption to existing management processes. That said, if you decided to Bring Your Own Keys (and select a cloud HSM), or bring your own software key management stack, you are signing on for additional setup work. And it’s not always simple – the cloud variants of HSM and software key management services are different than their on-premise counterparts. This section will highlight some differences to consider when managing keys in the cloud. Governance Let’s cut to the heart of the issue: If you need an HSM, you likely have regulatory requirements or contractual obligations driving your decisions. Many of these requirements spell out specific physical and electronic security levels, typically something like FIPS 140-2 Level 2 or 140-2 Level 3. And the regulations often specify usage models, such as requiring periodic key rotation, split administrative authority, and other best practices. Cloud vendors usually publish certifications on their HSM, if not HSM specifics. You’ll likely need to dig through their documentation to understand how to manage the HSM to meet your operational requirements, and what interfaces its functions are available through – typically some or all of web application, command-line tool, and API. It’s one thing to have a key rotation capability, for example, but another to prove you are using it consistently and properly. So key management service administrative actions are a favorite audit item. As your HSM is now in the cloud, you need to determine how you will access the HSM logs and move them into your SIEM or compliance reporting tools. Integration A key question is whether it is okay for your cloud provider to perform encryption and decryption on your behalf, so long as your master keys are always kept within an HSM. Essentially, if your requirement is that all encryption and signing operations must happen in hardware, you need to ensure your cloud vendor provides that option. Some SaaS solutions do not: you provide them keys derived from your master key, and the service performs the actual encryption without necessarily using an HSM. Some IaaS platforms let you choose to keep bulk encryption in their HSM platform, or leverage their software service. Find out whether your potential cloud provider offers what you need. For IaaS migrations of applications and databases which encrypt data elements or columns, you may need to change the API calls to leverage the HSM or software key management service. And depending upon how your application authenticates itself to the key management server, you may also need to change to this code as well. The process to equip volume encryption services with keys varies between cloud vendors, so your operations team should investigate how startup provisioning works. Finally, as we mentioned under governance, you will need to get log files from the HSM or software key manager. Logs are typically provided on demand via API calls to the cloud service, or dumped into a storage repository where you can access raw events as needed. But HSMs are a special service with additional security controls, so you will need to check with your vendor for how to access log files and what formats they offer data in. Management Whether using hardware or software, you can count on the basic services of key creation, secure storage, rotation, and encryption. But a number of concerns pop up when moving to the cloud because things work a bit differently. One is dual-administrator functions, sometimes called ‘split-key’ authority. Two or more administrators must authorize certain sensitive administrative functions. For cloud-based key management you’ll need to designate your HSM operators. These operators will are typically issued identity certificates and hardware tokens to authenticate to the HSM or key manager. We recommend that these certificates be stored in password managers on-premise, and the hardware tokens secured on-premise as well. We suggest you do not tie the role of HSM operator to an individual, but instead use a service account, so you’re not locked out of the HSM when an admin leaves the company. You’ll want to modify your existing processes to accomodate changes the cloud brings. And prior to production deployment you should practice key import and rotation to ensure there are no hiccups. Operations In NIST’s definition of cloud computing one of the essential characteristics – which separates it from hosting providers and on-premise virtualization technologies – is availability on-demand and through self-service. HSM is new enough that it is not yet always fully self-service. You may need to work through a partially manual process to get set up and vetted before you can use the service. This is normally a one-time annoyance, which should not affect ongoing agility or access. It is worth reiterating that HSM services cost more than software-only native key management services. SaaS services tend to charge a set-up fee and a flat monthly rate, so costs are predictable. IaaS charges are generally based on the number of keys used, so if you expect to generate lots of keys – such as one per document – costs can skyrocket. Check to see how keys are generated, how often, and how often they are rotated, for a handle on operating costs. For disaster recovery you need to fully understand your cloud provider’s failover and recovery models, and whether you need to replicate keys back to your on-premise HSM. To provide infrastructure failover you may extend services across multiple
