Using a software-based key-management system that is purpose-built for the cloud, an organization can store all its keys, tokens, certificates, and passphrases in a virtual "master vault" that is universally managed by the company's policies, controls, and business logic.
We'll get into how policy-based key management works below using Gazzang zTrustee as an example, but let's start with some definitions:
- A deposit is anything stored in the key manager. It could be a key or a configuration file. For the purposes of this article, we'll make it an encryption key.
- A client is an application or service that can deposit and retrieve sensitive information objects from the key manager.
- A policy is a rule established by the data owner that enforces the circumstances under which a key can be retrieved or revoked.
- A trustee can be a person or automated process that controls access to a deposit but can neither view nor access the content.
In a case where the key manager is being used to store a master encryption key, the data owner who deposited the key can define policies for how that key can be retrieved. This is important for establishing who, or in many cases what, can access the key and is a necessary step in preventing unauthorized access and meeting compliance requirements for safeguarding keys. Policy examples might include:
- TTL (time to live) — for example, making the deposit retrievable for a specific time period
- Limits on the number of times a key can be retrieved
- Single-use URLs
- Geographic location of the key requestor
- Authorize/denial votes by designated trustees
For auditing purposes, the universally unique identifiers of the keys and associated access policies should be viewable by a key-management administrator; however, the contents of the key file must remain opaque.
Here are two real-world cases of how policy-based key management works:
- An executive needs to share sensitive documents with outside counsel. The documents can be encrypted on the client side, with the master encryption key stored on the zTrustee server. In this case, the data owner can set a policy that permits key retrieval via single-use URL. The executive shares the URL with the authorized outside counsel, who can then use it to open the encrypted file. After the file is retrieved, the URL expires, and the document is once again inaccessible.
- A company needs to reboot its Apache Web server for maintenance reasons. To reboot, the server needs an SSL certificate and a private key to authenticate to the systems around it. An alert is generated and sent to designated trustees requesting authorization to release the certificate and key from the zTrustee server. If the request falls within policy (for instance, reboots can only happen on Wednesdays at 1 a.m.), the request is approved, and zTrustee sends the encrypted package to the server. If not, the trustees can deny the request or ask for more information. They never have to see the key or access the contents.