This is part two of our series looking at the cloud crypto services offered by the big three hosting companies: Amazon, Google and Microsoft. In part 1, we looked at what kinds of keys and secrets the providers will let you store, and what crypto operations you can do with them. Here, we're going to look at the way access to keys is controlled for users and services.It's useful to think about how this works in a traditional self-contained hosted application first. Usually an application gets access to its "working keys", which are stored either in an encrypted file (a software keystore) or a hardware security module (HSM), by presenting credentials which might include passwords, API keys, certificates etc. The big three cloud providers more or less replicate this functionality but with some extra possibilities. They typically already have an identity service which controls access to other cloud resources. The idea is to leverage the same service to control access to keys according to some policy. Authentication to the identity service by an application is usually by username and password, but human users (e.g. administrators) can also use multi-factor authentication.
Amazon's cloud uses their identity and access management (IAM) service to control access to keys. Each key stored in the KMS has a usage policy, and this is combined with the IAM policy for a particular user to decide if a user or service is allowed to do what they asked to do with a key. This includes separate permissions for using the key for encryption and decryption, or changing a key's policy for example.
Google's cloud also has an IAM service which regulates access to keys. Each key (but not each key version in the case of auto-rollover keys) has an IAM policy. There are a number of pre-set roles that govern what users and services can do with the keys. Custom roles is currently a beta feature.
Microsoft Azure key vault is a little different from the other two. It uses its Active Directory (AD) IAM service in a similar way, but access control is managed at the level of a "vault" or collection of keys rather than on a key-by-key basis. User profiles in AD can have access to a vault to carry out operations that correspond to their individual policy for all the keys in that vault, which may cover only certain cryptographic operations for example. Keys themselves also have usage policies in their key_opts attribute. The operations include separate permissions for encrypt/decrypt and wrap/unwrap, even though as explained in our last post these are the same operations at the moment because symmetric keys are not supported. Azure also supports generic secret values that can only be extracted into software, not used directly as keys. These are stored in the same vault as keys but have a separate access control policy.
All the big providers offer access control systems for their cloud crypto functions that work in roughly the same way, leveraging their existing IAM services. However, there are detailed differences partially explained by the choices about cryptographic operations to support. All of their offerings are pretty complicated, with numerous permission policies possible and multiple levels of control from keys to users. Our next post will look at how logging and monitoring works for these cloud crypto services.
For more information on cloud KMS offerings read our white paper.