How much security does your backup really need?
Because your backups contain your customers' most precious data, applications, and virtual systems, security obviously comes into play. When in production, you already have security controls in place to ensure only the appropriate individuals and/or organizations to access these critical assets. And, in the same way, when they are both being backed up and stored for potential use later, security needs to be in focus with the same level of intensity.
But exactly which security controls are necessary to protect backups?
There are a few aspects of security you should consider when planning backup security. While most vendors have some answer to each of the following security controls, it’s important to be thinking about how they implement each one:
- Session Encryption in Transit – When backing up to a cloud provider, everyone and their brother uses some level of SSL encryption to ensure the channel is secure. But how encrypted is the data? The lowest is 128-bit AES, with many vendors providing 256-bit. But, I’ve seen vendors provide as high as 2048-bit encryption. 2048!!! Now that level of encryption feels a lot like they’re pandering to the conspiracy theorist crowd, but it at least makes the point that if you want a higher level of encryption at rest, it’s available.
- Data Encryption Point and Level – This is part an “encryption at rest” control, but I want you thinking about when the data gets encrypted. Is it before it’s ever transmitted? Once it has reached the storage medium (whether local or cloud)? And what level of encryption is being used? It seems like every backup vendor has settled with 256-bit AES, but I do know LOGICnow’s MAXBackup supports up to 448-bit encryption.
- Private Key Key Access – OK, here's quick primer on encryption. There are two keys – a public key used to encrypt the data and a private key used to decrypt it. You only care about who has access to the private key. Some vendors retain access (for support purposes), while others give sole control to either a provider like you or directly to your customer (sort of your choice). Without making too many recommendations here, the less people who have access to the key, the better.
- Backup Location – Some customers are worried about government access, or extradition of data when it comes to cloud storage of backups. In theory, the limited access to the private key should address this, but let’s assume a government somewhere has built the modern day version of Alan Turing’s WWII decryption machine Bombe and can crack just about any encryption. If such a beast existed, and your organization was worried about government access, the location of the data geographically would become very important. Many cloud backup vendors only have a few US and Canadian locations. If this is an issue for one of your customers, having the option of having multiple locations worldwide from which to choose would be advantageous.
- Physical Security – whether your backups reside locally or in the cloud, if someone can just walk in and take a set of drives, you’ve given someone unlimited entry to begin hacking away at your other security measures and work to access your backed up data. You’ll need to address any on-premise physical security concerns (hint: storing the backup storage in an unlocked closet somewhere isn’t practicing good security). If using a cloud provider, it’s likely they have many levels of physical security already in place (but it never hurts to ask).
- Backup Access – Think about who has access to backup data sets and go all “insider threat” for a moment. Just because someone manages an SQL Server doesn’t mean you want to allow them to make an image-level backup of the server over to some portable 1TB drive they brought in, right? You should be scrutinizing who has the ability to define, modify, and run backup jobs within the backup solution you employ to ensure backups are being created in the secure manner you intend.
- Recovery Access – Same issue, but in reverse. I’ve seen some backup vendors providing delegated recovery abilities, and it worries me a bit. Not that it’s bad, but if it’s not managed properly, users can start recovery processes (utilizing the private key via the recovery app in the background) and potentially gain access to data they shouldn’t by redirecting the recovery location to somewhere conducive to inappropriate access.
While this isn’t necessarily a comprehensive list, it does get you thinking about all the security controls that are possible, and potentially necessary.
Which begs the question, do you need all of them?
The answer isn’t so much a yes or no, as it really depends on the security requirements of your customer. My recommendation is that you take a layered approach to the security of your backup and recovery. For example, backup security isn’t just about whether the data’s encrypted at rest, right? Right. It’s about creating a backup environment using a mix of a backup solution with the right security capabilities, security-conscious storage providers, and your own security policies and procedures to ensure your customer’s backups are safe.