Category: Security

Ben Johnston does some testing:

This is the third part of a series on SQL Server Dynamic Data Masking. The first part in the series was a brief introduction to dynamic data masking, completing solutions, and use cases. The second part covered setting up masking and some examples. This part starts exploring side channel attacks against dynamic data masking.

This article will show that are plenty of security concerns with using Dynamic Data Masking as a general-purpose security tool, but don’t let it completely keep you from using it. The point of the article is to show you the weakness of the tool, particularly for ad-hoc uses with users who might be keen to snoop around the data in ways you might not expect.

I’m not very big on Dynamic Data Masking at all, and this is a big part of why. That said, if your end users don’t have the ability to send arbitrary queries along (e.g., they can only execute stored procedures and none of those stored procedures let you send in arbitrary T-SQL), then it’s not that bad.

Matthew McGiffen retrieves some data:

In this post we’ll look at how you interact with data that is encrypted using Always Encrypted. The examples here will show how you run queries from SSMS, in later posts we’ll look at stored procedures and application code – as well as what happens in the background when you execute a query.

For these examples we’re going to be using the database we created in the last post.

Always Encrypted definitely changes the way you work with those encrypted columns, and you might run into some frustrating errors along the way, as things you could get away with before are no longer possible.

Eitan Blumin has some myths for us:

Many organizations assume that their SQL Server is secure because it is behind a firewall. However, firewalls only block traffic to specified ports and protocols, and they do not protect against attacks that come through allowed traffic. Therefore, it’s important to secure SQL Server at a more granular level.

Furthermore, even if your SQL Server is not connected to the internet, it can still be hacked through internal attacks or by using compromised devices that connect to your network… If at least one privileged user can connect to the SQL Server, that means a malicious attacker potentially could do the same.

My one quibble is that number 5 isn’t a myth. I accept the importance of performing auditing, and people I know who have insane transactional throughput requirements still perform auditing, but there certainly is a performance effect. Otherwise, definitely worth the read.