Customer managed keys for encryption at rest are not as good as they sound.
You are probably familiar with the concept of encryption at rest. The idea is that it protects the data even if the primary access control fails. If someone steals your laptop, removes the disk and re-attaches it to another laptop, then your normal operating system access control will fail. The attacker’s operating system will be in control, and it will allow them to steal your data.
Encryption at rest would prevent that. That is why encryption at rest is a highly sought security control. It was in high demand by customers, and the IT industry responded with a variety of implementations.
Encryption at rest can be implemented at several layers of the software stack – disk/volume, file, database, column and application. If you add virtualization, then you can also encrypt data at 2 additional layers – host disk or host filesystem.
As a rule of thumb – the lower layer encryption is implemented, the easier and cheaper it is. That is because the lower you are in the stack – the more “standard” are the IT operations, fewer customizations and further it is from the customer. The opposite is true – the higher is the layer of encryption implementation, the less standardisation there is and more customer responsibility and management is required.
Compare the two extreme cases: If your credit card data is encrypted at rest only at the disk layer, then this encryption is transparent to your file system, database server, and your application. If any of these layers are compromised, then the attacker would see the data in clear. The opposite is true – if encryption is implemented at the highest application layer, then it would protect the data even in the event of disk, file or database compromise.
The layers are also important because somewhere in the stack is the demarcation line between customer and infrastructure (cloud) vendor responsibility.
Encryption requires keys, and keys require management. Keys need to be generated, distributed, stored, protected, rotated, and destroyed. It is not hard, but it requires attention and care. To make customer’s life easier, cloud providers offer vendor- and customer-managed encryption keys.
Vendor-managed key is completely managed by vendor. It is “transparent” to customers and hackers, who operate at higher layers of the stack. It is easy to use, and it costs nothing.
Customer managed encryption key sounds more promising. If the key is managed by the customer, then it is surely above the vendor responsibility line – somewhere high in the stack, isn’t it? At least it implies that the customer owns the key, and so the customer’s data is protected from the cloud vendor.
GCP calls it CMEK, AWS calls it CMK.
Well, the actual implementation is not how it sounds. In reality, the customers do not “own” the keys. Lion’s share of the key management – generation, storage, replication, assignment, internal access control, and destruction – remains with the vendor. That means there is a risk of data compromise by the vendor. Only a small portion of the “management” is delegated to customers. That is why encryption with these keys can be implemented at low layers of the stack – within cloud vendor responsibility and control – as in the picture above.
In reality, what they call a customer managed key is “mostly-vendor-managed key”.
AWS gives customers the ability to rotate, revoke, and control access to the keys through granular access policies.
GCP gives customers even less “management” – you can rotate and revoke the keys, but you cannot set granular access policies to them.
One good way to cut through the marketing gimmick is to ask the question – is the data encrypted before it is transferred to cloud storage? If the answer is no, then the data is barely protected.
A better solution is application-layer encryption, with fully customer-owned and managed keys, which, by the way, could be delegated to cloud providers for generation, storage and management :). The difference, though, is in this scenario, the data is encrypted before it is transferred to cloud storage.
That is a harder implementation, but it gives the best protection. I would request it for all sensitive data. For less sensitive data, vendor-managed encryption with so-called-customer managed keys may be just good enough, depending on your organisation’s risk appetite.