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

select * from =tg= where topic = =tg= Thomas Grohser Senior Director Technical Solutions Architecture email: Thomas.grohser@nttdata.com tg@grohser.com 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 @@Version 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 & >500.000 STMT/sec First Scale out > 1.000.000 STMT/sec First time 1.2+ trillion rows in a table SQL 2012 > 220.000 Transactions per second > 1.3 Trillion Rows in a table SQL 2014 > 400.000 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

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

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

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

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

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?

The problem with security

One tiny little hole is enough…

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

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.

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

Demo

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…

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 …

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

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.

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.

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 …

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.

Secure Setup User DBA 1 DBA 2 Manager

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?

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