Encrypting backups is a relatively new feature in SQL servers, first introduced in SQL 2014; with recent data leaks, you might be left thinking, ‘should I be encrypting my SQL backups’?
I am not saying hackers copy your backup files when they steal data. Most attacks will be aimed at production systems with the most up-to-date data.
The fresher the data, the higher the price.
However, there is a much higher chance that the permissions have been incorrectly set on a backup drive, as that is not where you have focused your attention.
An admin might have set it up for read-only access for everyone (either by mistake or just for convenience) on the network share instead of just a few authorized people.
There’s so much pressure to hit deadlines and get things to work.
Focusing on the main goals leads to less consideration of the rest of the environment.
The problem is people can get distracted and are sometimes lazy. Not just those trying to protect data but even those trying to steal it.
Why would I spend days or weeks breaking into a safe if there is a less well-guarded repository with almost identical prizes?
If I can steal a backup file in a few hours instead of data from a production system in a week, I will go with the path of least resistance.
Should you encrypt SQL backups or not?
Do your backups leave your data centre
Do your backups leave your business?
The answer to both of those questions should probably be yes. If you do not have any off-site backups and your site suffers from a disaster, you have lost your production systems and jams too.
You might be worried about overheads; the speed hit, and the size of the backups. I have tested this, and the size increase is negligible, with a speed difference depending on whether you are using HDDs or SSDs; in the long term, neither should be a problem.
So I would suggest doing some tests, but you should encrypt SQL backups.
[…] you only have one option; sort your SQL backup strategy now – once and for […]