Encryption in the cloud

A false sense of security

In many projects, one of the key aspects of perceived data security was whether the data was encrypted or not. I remember a particular case when the management insisted that the data must be encrypted locally before writing to the database but then nobody cared where the key was stored or whether it was protected or not. But as long as the developer could point to the rows and show that they are in an unreadable form, everybody was assured.

All while the API was happy to serve everything in plain text without checking the requester.

Encryption outside the cloud

The term "encryption" is usually used with files. In the case of non-encrypted files, everybody who has them can read the information inside.

In terms of access control, the only question is whether you have the file or not:

With encryption, you can split the required part into two, the encrypted file and the key, with an added benefit of the latter being significantly smaller than the former. To get access to the information, you need both:

In terms of access control, you have finer control over who has the information:

Therefore, not taking account problems with the algorithms, an encrypted file is just as secure as the key itself. If you protect the key you can control access to the information. If you put the key next to the encrypted file, encryption means nothing.

Encryption in the cloud

In the cloud, you usually don't get access to the encrypted files themselves. For example, S3 either sends you the object in plain-text or denies the operation if you don't have access to both the file and the key. Apart from the naming and a promise, there is no observable proof that the file is stored encrypted.

Encryption then is not about splitting a file into two, but about splitting the permissions into two. You need access not only to the object but also to the key.

KMS

When it comes to encryption inside AWS, KMS is the service to use. It stands for Key Management System and it manages the keys and the policies.

Key policies define who can use the key. This is the part of the access control that is added with encryption.

In the case of an encrypted S3 object, you use Bucket/IAM policies to grant access to the object, then you use Key/IAM policies to grant access to the key. If a requestor lacks either one, the access is denied.

Inter-service permissions

Since one part of the permissions is detached from the datastore service, KMS opens the way to define permissions across services. If you store data in S3 but archive it to Redshift, you need to make sure the permissions are kept in sync. Someone who has access to one of the services gets access to the data which increases the likelihood of leaks.

With KMS you can use the same key for both S3 and Redshift, giving you centralized control over the data access. This would be hard to enforce without key policies.

Encryption is access control

Since from a practical point of view, encryption does nothing else but splits permissions into two required parts, it does not make data more secure. It just gives you more control.

If you use too broad permissions or you don't properly check access on your APIs then it does not matter if the data is stored encrypted or plain-text. Instead of asking "Is the data encrypted?", start asking "Who has access to the data?". After some thinking, you'll see that you can make that list shorter by utilizing the encryption infrastructure.

That is when your systems will be more secure.