How to Protect Against Ransomware as a DBA

Over the years I’ve been called in to work with numerous clients that were hit with ransomware. Even the times that the customer paid the ransom to unlock their encrypted files, there were still issues. Often times there were still issues with the files where they will not restore or data/log files can’t attach to the instance.

Hopefully everyone has attended some type of security training that warns you about clicking unknown links in email or attachments. That training should include not to download random files and software from untrusted websites, connecting to unknown networks, using unfamiliar USB devices, using strong passwords, and avoiding giving out personal data. Other things are more corporate level with having enterprise security software, firewalls, forcing multi-factor authentication and other security measures.

For organizations, having secure backups is a key element to be protected in the event a ransomware attack occurs.

As data professionals, we have a unique opportunity to make sure that during a worse case situation, we have our databases backed up and stored offsite. A very easy way to accomplish this is shipping them somewhere else. For me, this has usually been to Azure, AWS, or Oracle Cloud.

My go to has been Azure. Storage is affordable and the replication options are simple in order to have those backups geo-replicated. It all comes down to how paranoid you need to be.

With an Azure subscription, you can create a dedicated Azure Resource Group, or use an existing one. Create a dedicate storage account, or use an existing one. Create a container for your files and get the Access Key that will be needed to communicate.

I then use AZCopy to sync the backup files from my database servers to my Azure container. With AZCopy, you’ll need to automate the task of calling AZCopy to sync after each backup job. (Full, Diff, and Transaction log).

What is very important is to setup a purge of the files in Azure, otherwise you may end up with excessive files and wasted funds on storage.

For example, 284TiB might be a bit excessive for this company.