1. Advanced Security Protecting Data from the DBA
=tg= Thomas Grohser
Advanced Security Protecting Data from the DBA

2. select * from =tg= where topic =
=tg= Thomas Grohser
Senior Director Technical Solutions Architecture
Focus on SQL Server Security, Performance Engineering, Infrastructure and Architecture
Wrote some of
Close Relationship with
SQLCAT (SQL Server Customer Advisory Team)
SCAN (SQL Server Customer Advisory Network)
TAP (Technology Adoption Program)
Product Teams in Redmond
Active PASS member and
PASS Summit Speaker
Remark
SQL 4.21
First SQL Server ever used (1994)
SQL 6.0
First Log Shipping with failover
SQL 6.5
First SQL Server Cluster (NT4.0 + Wolfpack)
SQL 7.0
2+ billion rows / month in a single Table
SQL 2000
938 days with 100% availability
SQL 2000 IA64
First SQL Server on Itanium IA64
SQL 2005 IA64
First OLTP long distance database mirroring
SQL 2008 IA64
First Replication into mirrored databases
SQL 2008R2 IA64
SQL 2008R2 x64
First 256 CPUs & > STMT/sec
First Scale out > STMT/sec
First time 1.2+ trillion rows in a table
SQL 2012
> Transactions per second
> 1.3 Trillion Rows in a table
SQL 2014
> Transactions per second
Fully automated deploy and management
SQL 2016
AlwaysOn Automatic HA and DR, crossed the PB in storage
SQL vNext
Can’t wait to push the limits even further

3. Ultimate Security Goal:
 URLT
 CNURLT
Avoid being the headline

4. Basic plan for security
What needs to be protected? From whom? At which cost? What’s the risk if we don’t do it?

5. What needs to be protected?
Data Reading Adding / Changing / Removing Code, Queries, Schema a.k.a. Intellectual Property

6. Protected from whom? Hobby hacker Disgruntled employee
Criminals / Competitors (Professional hacker seeking money)
Disgruntled employee with skills
Professional Hacker seeking fame
Stupid Users
Social engineering
Stupid Code
Government
Disgruntled DBA

7. At which cost? What’s worse? Loosing data and it’s gone
Loosing data to someone else
With other words:
Would you rather destroy data than have it stolen?

8. The problem with security

9. One tiny little hole is enough…

10. SQL Server offers a lot of build in security
Logins, Users and Roles Permissions (Server, Database, Schema, Table, Column, …) Row Level Security Encryption (Data, Transparent Database, Backups) Auditing

11. Problem is …
It all requires that the DBA is trusted Would you trust this guy? I definitely do not! Not joking! Everyone can be coerced into doing something bad.

12. How to protect data from the DBA
Don’t store the data CVV and CVV2 are great example Hash the data and store the hash instead Passwords are a great example Encrypt the data in the application CCN, SSN, Account numbers Use Always Encrypted for the above task Limit what DBA’s can do

13. Demo

14. Preventing DBAs and sysadmins from modifying data
It is impossible to DENY a member of the sysadmin server role anything
Workaround for writing operations
On the table you want to prevent editing by sysadmins add a DML Trigger
Check for either specific logins (use ORIGINAL_LOGIN()) and commit else rollback or
Check for sysadmin membership and rollback, else commit
Then create individual server level triggers that prevent sysadmins from dropping, altering or disabling them (individual triggers on each event)
ALTER_TRIGGER
CREATE_TRIGGER
DROP_TRIGGER
Then create a global DDL trigger (DDL_EVENTS) preventing sysadmins from dropping, altering or disabling them
Make sure you have one backdoor account that can drop or disable triggers
You might want to exclude other triggers in normal user databases
Problem here is that disable trigger will not fire an event…

15. So how can we limit the DBA
Simple don’t make her/him a member of the sysadmin server role
Easy?
Yes it is we just have to use a “security hole” for the good …

16. Database Owner
Don’t confuse with member of db_owner database role or dbo schema Use MyDatabase EXEC = 'NoRightsLogin' Default = User that creates the database or restores it (normally a member of sysadmin server role – just keep that in mind)

17. Stored Procedures
ALTER PROC dbo.DoHarm WITH EXECUTE AS OWNER -- Powerful and dangerous!!! AS -- Evil Things can happen here; Procedures can be executed under the security context of the database owner, whatever that user can do the procedure can do in that database.

18. Trustworthy databases
ALTER DATABASE SET TRUSTWORTY ON This widens the ability of a stored procedure to execute under the context of the database owner and run server level commands as well. Excellent feature if stored procedure deployment is controlled. Deadly feature if not.

19. Using this for the good…
!!! No other database should be owned by a sysadmin or trustworth
Create a “tool” database Make it owned by sa and trustworthy Securely deploy vetted and audited code that wraps admin functions in stored procedures. Don’t give DBA’s sysadmin, give them execute on the procedures. Stephen Mokszycki had a detailed talk about the same process earlier today: “Outsourcing database administration to your users.”
Run.Backup …
List.LogSpace …
Find.BlockingTransactions …

20. So what about stuff you did not wrap in a procedure?
Four or more eye principle Don’t allow a DBA to access the machine as sysadmin alone Make them team up and watch each other Have someone independent approve the access Have them use a special workstation that records keystrokes and the screen output and have an independent auditor review the session after every access.

21. Secure Setup
User
DBA 1
DBA 2
Manager

22. Summary
Protecting the data from the DBA is possible but a lot of work is required to do so. It boils down to a simple question Is the data I am protecting worth the effort or can I take out an insurance policy that is more cost effective?

23. THANK YOU! and may the force be with you…
Questions?
(9 to 5 5 days a week :-)
(24x7)
Please fill out the evaluations.