Voice of the DBA

Tag: security

Do I have a Database Master Key in a database? #SQLNewBlogger

Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

How can I tell if I have a Database Master Key in a database? It’s actually easy. I query the sys.symmetric_keys DMV for data. If I get a result that has a name of ##MS_DatabaseMasterKey##, then I have a database master key.

You can see this below. I’ve queried this DMV in my Sandbox database.

Now, what if I go to another database, say the Finances database. I see nothing.

Let’s add a master key here and then query. Note, I am not disclosing the real password here. Never do this, even in test systems.

This instance has been used with TDE, so if I go to master, I’ll get this:

You can see that I not only have a DMK, I have a Service Master Key (SMK), which protects the instance.

When I create my DMK, the only parameter I can provide is a password, after the optional “ENCRYPTION BY PASSWORD” keywords. I don’t name it, so I can count on the naming being fairly consistent. I don’t think that the name would change from version to version, but it could.

I’d prefer that MS not create magic numbers or names, and instead, add a column to the DMV that denotes this is a DMK.

References

sys.symmetric_keys – https://msdn.microsoft.com/en-us/library/ms189446.aspx

CREATE MASTER KEY – https://msdn.microsoft.com/en-us/library/ms174382.aspx

Connect Item to add a flag – https://connect.microsoft.com/SQLServer/feedback/details/3118588

January 13, 2017
Securing Your Instances

I wrote a post about finding the port number of a SQL instance using PowerShell. Almost immediately I was taken to task by someone that noted port scanners can easily find SQL ports, so it’s silly to move off 1433. Just use it because applications expect it. I can see that, and changing ports doesn’t provide much security, but it does provide some obscurity, which may or may not be helpful. Certainly this also creates administrative and support burdens for a system. If you want other opinions, there’s a Q&A on Stack Exchange for this topic as well.

Tom LaRock wote a post that this can be a way to obfuscate your database, prevent simple default connections, and potentially detect security issues before they become a problem. I tend to learn towards this approach as well, because these small changes can potentially provide a little protection. A port scan is quick, but firewalls are getting better at detecting these. Certainly criminals get smarter, but changing a port number isn’t intended to stop everyone. If it stops a few, then that’s fine.

Security comes about because of layers, and limitations, and will never be perfect. There will always be ways that someone can get around security, but the more layers, the more obstacles you place in their way, the fewer people that will overcome all of them. I’d also note that plenty of attacks come from vandals. People that are just bored and looking for easy ways to get into a system. Most of these people are using pre-written scripts and programs that try out defaults. These aren’t concerted, directed attacks. They’re attacks from boredom.

I’m curious today how many of you think a little bit of security from obfuscating ports is a good idea. I wouldn’t recommend the SQL Browser be open, but that legitimate connections know about the port needed, and use that in their connection strings. I think it helps, and if this limits some attacks, especially inside-the-firewall virus attacks from trusted machines, I think it’s worth doing.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 3.4MB) podcast or subscribe to the feed at iTunes and Libsyn.

January 13, 2017
Backup Data Security

It seems there is no end to the insecure ways in which people manage data. I haven’t seen this one before, but I’m sure it’s happened. In fact, I bet it’s happening right now in more than one company. A company was using rsync to keep data files copied between two insecure servers. Insecure because of a lack of username and password on the systems. In this case, the problem was a subcontractor that dealt with confidential US military personnel data.

I appreciate that many of you are talented scripters that solve problems and build great solutions. I wonder how many of you actually think about security and the potential implications of small mistakes in configuration that others might make. When you build that PoSh script to copy backup files, are you ensuring the transfer takes place in a secure manner? Do you assume that because you use an IP address or server with no DNS entries to receive data that no one else can find it?

All too often I find that sysadmins and developers make assumptions about the security of their process. They think because discovering the process or information would be hard for them or they wouldn’t bother, the data will be secure. And we find that time and time again that the ways in which we build systems without considering security aren’t secure. Someone will find a way to access the data, often with a fairly simple technique. Steal a laptop that’s unencrypted. Get a user to click on a link that installs keystroke logger or uses phishing to gain credentials. Scan a server for known software running with un-patched vulnerabilities or default accounts. I can’t tell you how many times I’ve logged into Oracle database servers with “System” and “Manager” in various organizations.

Certainly our software platforms haven’t been well designed with security in mind. All sorts of expected, happy path behaviors are assumed by software developers, many of which are susceptible to attacks. While modern platforms are better designed and patches are becoming widely available, far too few companies apply these patches and consider security in the software they build on top of the OSes, databases, and other frameworks used for software. As an industry, we are far too guilty of granting more security than needed, opening more ports than necessary, re-using accounts too often, and assuming that our network paths are secure.

Good security comes from having layers that don’t open our systems to a single mis-configuration or simple attack. Disks should be encrypted, minimal privileges granted, accounts not re-used across systems, and network communications, even for simple copies, secured. I know this can slow some development and be painful to implement, but as we become used to using secure credentials and techniques in all of our work, the complexity will fade into the background, and it will be as easy to deploy a secure system as an insecure one.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 4.2MB) podcast or subscribe to the feed at iTunes and Libsyn.

January 12, 2017
Post TDE–Getting Unencrypted Backups

I saw a question posted recently about someone that had disabled TDE and was still having issues restoring a backup. This doesn’t seem like that should be an issue, but it can be. A little testing shows how.

Let’s assume I have an encrypted TDE database. If I run a query, I can see the status as 3, which is encrypted.

If I take a backup at this point, the backup will be encrypted, and to restore this on another instance, I’d need to first restore the certificate. I don’t want to do that, so let’s remove encryption. This is a simple command

ALTER DATABASE TDE_Primer

SET ENCRYPTION OFF;

This runs quickly.

If I now query for encryption, I see this.

A one means that this is an unencrypted database, but a DEK (Database Encryption Key) exists. If I were to detach and examine this database file with a hex editor, the pages would be decrypted.

I’ll now take a backup and move that to another instance. Once I’ve copied that over, I’ll try to restore the backup. In T-SQL, I’ll see this:

Why is this? The database was decrypted, as was the backup. In fact, if I open my backup file in a hex editor, I can see row data.

The Problem

When SQL Server goes to restore the file, it reads part of the header. In here, the process must detect the DEK and try to decrypt that key. However, since this new instance does not have the certificate, this doesn’t work and an error is thrown, despite not needing the key since the data isn’t encrypted.

The issue here is the DEK still exists in the source database.

The Solution

Let’s fix this. I’ll return to my first instance and the original database that was TDE encrypted and now is not. I can issue this:

DROP DATABASE ENCRYPTION KEY

Once I do this, it completes quickly. This is a standard DDL command, but one that’s not often used.

Once I do this, I’ll take another backup and return to the second instance. Now when I try the restore, I see this:

If you’re having issues restoring a database that used to be TDE encrypted, try removing the DEK and then backing it up.

December 28, 2016