Poll Results: Yes, Your DBAs Can Read the Data.
Last week, I asked if your database administrators could read all of the data in all databases. The results (which may be different from this post, because I’m writing the post ahead of time and the poll is still open):
- Yes: 61%
- Yes, but we trust them not to: 29%
- Yes, if they bypass tech restrictions, but we trust them not to: 4%
- No, it would be impossible: 6%
90% of DBAs can easily read everything.
In small companies, there’s not really a way around this. At the end of the day, someone has to be personally accountable for things like setting up encryption, and in small companies, people wear multiple hats. In small to midsize companies, there’s often just one database administrator, period, and they have rights to all the databases.
SQL Server’s Always Encrypted feature was supposed to assist with that by encrypting data at the app database driver level before it even went across the wire to Microsoft SQL Server. I didn’t see much adoption of that, but not because it’s a bad feature or there’s anything technically wrong about it, but:
- It takes both developer and DBA work to implement
- It can result in some pretty stiff performance penalties if it’s not done correctly, or if your app has some oddball query patterns (like leading wildcard string searches)
- Data often ends up getting decrypted and dumped in an unencrypted data warehouse or data lake anyway
Those aren’t unsolvable problems by any means. The larger companies get, and the more security regulations they’re subject to, the more likely they can afford the work of mitigating those risks and paying for other security best practices.
This makes it harder to get a DBA job.
The fact that DBAs can read everything means the company really wants to know someone before they trust ’em with the ability to see everything. In small to midsize companies, that trust is typically built up over time by hiring the employee first as a developer or sysadmin, and then gradually segueing them over to database administration after they’ve proven their trustworthiness.
I don’t really have anything to add to this. It’s just the way the data business works. But I like conducting polls like this so that people can read the poll results from their peers and say, “Oh, I get it – it’s not just my shop that has these kinds of problems.”
10 Comments. Leave new
Our dba staff can read everything but it doesn’t matter. We are a software development house and none of data is from clients.
[…] Brent Ozar wraps up a survey: […]
How do you prevent DBAs from reading data if they are sysadmins? Am I missing something?
Indeed you are! I wish I could teach this in a blog post comment, but that’s a little beyond the time I have. Some other kind soul might help you out, or – I know this is going to sound radical – but there’s something called “the documentation.”
That’s good enough for me! I will dig. Thanks for the response!
Brent, my question for you is: how popular is the Always Encrypted feature?
Have you seen people using it or is like PolyBase?
Based on what you see in the above post, what do you guess my answer would be?
Myself I’ve only seen it implemented in 3 places and in two of those places it was implemented so poorly that it was refactored out. Who knew that allocating only a few hours of DBA time to a project at the end of the project could lead to bad “full stack” decisions in data design haha.
Great Poll/post! Some of our customers had us implement Dynamic Data Masking, which is cool except sysadmins are immune to the masking so our DBAs can still read everything. So we implemented Audited “break glass” sysadmin accounts that shouldn’t be used for nearly anything, while larger permissions were granted to non-sysadmin DBAs to do their job but with masked data (so non sysadmin DBAs can read plans, etc). It works pretty well, but all data is still visible to DBAs – since some tasks require sysadmin. Anyway – fun poll here; thanks for sharing.
Freshly in surprised that is as low as 90% because there’s more chance of me finding teeth on a hen than a DBA locked out from all data.