3

I have a few servers which backup to a Data Domain. This is accessible via a UNC path, i.e. \\datadomain\SqlBackups\ and all that seems to be done is we give the SQL Server access to the data server via Firewall rules, and we give SQL DB Service Account full access to the SqlBackups folder.

The server is configured to map the Y:\ drive to this location so backups go to Y:\<InstanceName>\<DatabaseName>.

This works until something happens with the drive mapping. For example, sometimes on reboot the mapping is lost so backups fail.

I just want to backup to the UNC path which I've tested and it works without fault. However I'm told there are security implications for this, something about making the UNC path visible to potential hackers... which doesn't make sense to me as you can just easily find out where a mapped drive points to.

Can anybody shed any light on this from a SQL Server / Windows Server Security point of view? What's so bad about backing up the UNC path?

Improve this question
8
  • Have you asked more details from whoever claims that "there are security implications"?
    – vonPryz
    Commented May 11, 2017 at 10:45
  • Yes. A shrug of the shoulders and something about hacking. We have to go through our change control process to amend this and I've already spoken to one of the chairs who happens to be the one who said there are security implications, which are a mystery to me. By mapping the drive, you aren't exactly hiding the true path, it can easily be identified. Don't see the problem, but I guess I'm just reaching out in case there are indeed known issues I should be aware of as a DBA. In other words I want to be fully informed before I challenge this.
    – Molenpad
    Commented May 11, 2017 at 10:59
  • 2
    As long as the UNC path share has security around it (Access Control) then you control who you want to allow security to this resource. If it's not a hidden share and people can browse the network to see it, then it is no different than pointing to it via UNC or telling a drive letter on Windows to point to it. If you control who has access to your network and the share, there's two levels of security. You could also encrypt the backup & then copy it over and it's secure regardless of who accesses it. You can also hide the share. Secure with Access Controls, Data in Transit, and Data at Rest.
    – IT Thug Ninja
    Commented May 11, 2017 at 12:13
  • 1
    I would like to agree that a dependency on a mapped drive is silly in that it is just going to the same place. The only other reason, aside from security, I could think to keep a mapped drive is that if the backup destinations change frequently for some reason the drive can be changed without affecting the jobs. There are many other compensating controls for this though so it seems a flimsy excuse.
    – Matt
    Commented May 11, 2017 at 12:18
  • 1
    I don't think they are worried about security of the backup per-say, I think they are worried about losing control of the policies that are mapping the network drives. As Matt mentioned, I think that if they need to change the location of the mapped drive they can easily do it through policies... The Server that holds backups in general rarely change... Only SQL Servers should have access... but if they would ever change, Every SQL Server backup script would have to change to point to the new location... Not a big deal... less often than losing the map drive.
    – JohnG
    Commented May 11, 2017 at 19:31

1 Answer 1

Reset to default
1

We have a lot of SQL Server VMs and we've found it best to backup database to a centralized location via a Windows share and keeping our VMs slim. However, we've been backing up to the administrative Windows $ shares--which I have yet to see any administrator turn off -- though it can be done.

As for your question: usually you map a drive only for convenience sake because you want to or provides and expected benefit, but you still have to map it to a UNC name. The network packets to and from the mapped drive are still going to contain UNC information. That information doesn't get obfuscated because you mapped it to a drive letter. Actually systems that have mapped drives have been more vulnerable to trojans like Cryptolocker!

If there are legitimate data hacking concerns, just turn on backup encryption--knowing it will add some CPU cycles to the mix(and the new task of acquiring, managing, and maintaining certificates). Our network is fairly secure so we are not currently encrypting our backups--but that day is probably coming sooner rather than later. Additionally, it sounds like the questions need to be re-directed to the owners and creators of the data domain, since that's where the share resides and most of the risk exists (not to mention the UNC share name).

If the powers that be are wondering about a UNC hack, I'd have start asking questions like:

1.> "is our network in danger of being hacked or have we been hacked already? What's your confidence level for this scenario?"

2.> "are server backups currently being encrypted?"

3.> "have Windows admin/$ UNC shares turned off?"

4.> "are certificates readily available for encryption -- should we go that route?"

5.> "do we even have a corporate certificate policy we can rely on in order to acquire certificates from a reliable source?"

6.> and my personal favorite, "do I need to air gap my SQL Server?"

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.