SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 

Wow. Just Wow

By Steve Jones,

Wow. Just Wow.

Yes, I meant to use a capital letter there. The Red Cross' Blood Service in Australia had database backups on a website that anyone could access. That means that anyone could download the backup, which contained PII (Personally Identifiable Information) about donors. This was a mysql dump file, which is shockingly easy to restore, so anyone could have read the file inside of an hour.

To be fair here, this wasn't the Red Cross' fault. A partner had put the file on a website, perhaps for developers or an analyst to download, but the web server had directory browsing available and was serving data on a public IP. That's three major faults, and perhaps a fourth since the backup file wasn't protected at all.

How many of us have innocently taken a backup, put it in a location for someone else to download inside our company, and not thought anything of the action? If you have done this, would you know if the file were accessed and downloaded by the wrong person? In most cases we wouldn't because the correct person might download the file as well and we wouldn't think anything had ever gone wrong.

That's a problem with data. We don't get necessarily notified if someone makes a copy. We certainly have no way of knowing if the backup files we create are ever restored by an unauthorized user, much less just copied. We often just assume that data at rest is just at rest and isn't ever mishandled without our knowing about it.

This is a good reason why we should be practicing security by default in most every case. All our backups should be protected at the very least with passwords. Even if everyone in the organization knows the password, some random person that might steal a laptop or browse an unsecured web server won't know it. The password also shouldn't be easily guessed, and if possible, the data should be encrypted. Always.

What's more, I would hope that we would use secure ways of moving information around with our fellow employees and partners. I know Dropbox is a very convenient and tempting mechanism to use, but is it really appropriate? It might be good enough if you've protected the data in other ways, but I'd be very, very wary of using any public service that doesn't allow for some sort of security that can be tied to individual, authenticated users.

No matter how you choose to protect and transfer database backups, I'd also be sure that you don't leave the information there indefinitely. Have expiration times where files are removed. All encryption and protection can be cracked, given enough time and resources, so don't leave your files there forever.

 
Total article views: 159 | Views in the last 30 days: 1
 
Related Articles
FORUM

Unable to restore the password protected backup

Restore the password protected backup using sql server 2005

FORUM

Protecting SSRS reports

Protecting SSRS reports

BLOG

Day 2 of 31 Days of Disaster Recovery: Protection From Restoring a Backup of a Contained Database

Day 2 of 31 Days of Disaster Recovery: Protection From Restoring a Backup of a Contained Database ...

FORUM

Backups password protected ...

I'm thinking about password protecting my backups as another level of security. However, I know I c...

FORUM

IBM TSM Data Protection Backups and Log Replication

Problems losing transaction log backups...

Tags
editorial    
security    
 
Contribute