October 25, 2018
Cloud Backups and Encryption – WST
Many institutions utilize cloud-based storage as part of their backup solution. Whether it is a pure server to cloud backup, a local backup repository with an offsite cloud storage component, or somewhere in between, the flexibility of many of these solutions can be awesome. The usage of these services does not have to be a trade-off in security either if it is done correctly. Encryption is the key (no pun intended).
To protect data sent to the cloud, it must be encrypted. Just about any backup service will do this, but how exactly? With cloud backup solutions, encryption can be several things, but three main types are most common: encryption during transit, post-egress encryption, and pre-egress encryption. Here is a quick rundown of these concepts.
- Encryption During Transit
This means your data is encrypted while it is sent to the cloud repository. This is essential, and almost any provider will do this. Encryption during transit generally means your data is sent over an encrypted TLS connection while talking to the cloud server.
- Post-egress Encryption
Usually means that your backup data is encrypted on the cloud provider’s servers once it gets there. This is a good thing, but it means that the provider manages the encryption key or password, so if they get breached, the keys probably are compromised as well. Your encrypted data + compromised keys = bad guys reading your data, which is bad.
- Pre-egress Encryption
This is the best and only effective way to protect your data when using cloud backups. With pre-egress encryption, you encrypt your data with a key or password only you know and have access to BEFORE it is sent to the cloud provider. This protects your data as soon as it has left your organization and arrives in the cloud as a big unreadable blob of data. This way, if the cloud vendor is compromised, the bad guys can look at your data all they want. Without the key to decrypt, it is worthless.
The ideal solution would be one with pre-egress encryption and encryption during transit. You manage your own encryption key and you alone can read your information. The one big caveat to a solution such as this is: You are responsible for your key. If you lose it, you cannot read your data . . .Period. So, the key(s) must be protected and backed up separately. Also, testing restores from this type of backup is essential. Make sure your key works to decrypt during a restore. The last thing you want is to find out you stored the key wrong when needing to recover a server!