1. Security, Security, Secuirty =tg= Thomas Grohser, NTT Data SQL Server MVP SQL Server Performance Engineering SQL Saturday #506 BI Edition April 30 th 2016, Baltimore, Maryland

2. select * from =tg= where topic = =tg= Thomas Grohser, NTT DATA Senior Director Technical Solutions Architecture email: Thomas.grohser@nttdata.com / tg@grohser.com Focus on SQL Server Security, Performance Engineering, Infrastructure and Architecture New Papers coming 2016 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 21 Years with SQL Server

3. And one more thing … All I know about BI is how to not install it

4. NTT DATA Overview 20,000 professionals – Optimizing balanced global delivery $1.6B – Annual revenues with history of above-market growth Long-term relationships – >1,000 clients; mid-market to large enterprise Delivery excellence – Enabled by process maturity, tools and accelerators Flexible engagement – Spans consulting, staffing, managed services, outsourcing, and cloud Industry expertise – Driving depth in select industry verticals Why NTT DATA for MS Services: NTT DATA is a Microsoft Gold Certified Partner. We cover the entire MS Stack, from applications to infrastructure to the cloud Proven track record with 500+ MS solutions delivered in the past 20 years Why NTT DATA for MS Services: NTT DATA is a Microsoft Gold Certified Partner. We cover the entire MS Stack, from applications to infrastructure to the cloud Proven track record with 500+ MS solutions delivered in the past 20 years

5. Drawing at the end of the session  Drop your business card or fill out provided blank card and drop in the cup  Must be present at the time of drawing at the end of the session to win:

6. Agenda  Make you aware what security means and know how to build a secure environment.

7. Setting the Goal  Security defined  Authenticating users  Is the person/application really who they claim to be  Limiting access to Authenticated users  Limiting data as needed to users/applications  Protection data from getting stolen  Protecting “lost” data from being used  Protecting Intellectual Property (the code, schema, …)

8. Threads  Hobby hacker  Disgruntled employee  Criminals / Competitors (Professional hacker seeking money)  Disgruntled employee with skills  Professional Hacker seeking fame  Disgruntled DBA  Stupid Users  Social engineering  Government  People like me

9. General Problems I see  Management does not care  To many people have access to too much data  Shared passwords  Writing down of passwords  The wrong people have passwords  Security vs. Agility & Convenience  DBA’s / Developers don’t know how security exactly works (we are fixing the last right now)

10. Basic Security Concepts  Separation of duties  Two factor authentication  Least amount of privileges  Only grant access to data the user needs  Auditing  Security is NOT a magic command or option you can turn on  Security is a concept, commitment and a lifestyle

11. Physical Security  Who has physical access to your server?  How is access controlled?  Who else is in the same building/room?  Is there an alarm system?  What happens to the access control in case of a power loss  Who has physical access to your network/office?  What happens to a defect hard disk / SSD?

12. Network Security  Which devices can connect to the network?  Port Security  Automatic IP assignment  Is the Wi Fi accessible outside the office?  How secure is the password / encryption?  VPN  How is access controlled  RSA Token  Certificates  How often are passwords changed

13. Server Security  Who installed the OS?  Who configured the OS?  Is the Windows domain secure?  Who is domain admin?  Who knows the passwords of the service accounts?  How often are passwords changed?  Who can login on the server and who has local admin rights?  Where did the OS and SQL Server installation media come from?  Who installed SQL Server with which options

14. SQL Server Service – Service Account  Network Service  SQL Server can’t access network shares (for backup, log shipping, …)  Windows User  The DBA should not know the password  No Single person should know the password  It is possible to use a throw away password  Domain User  Required for constraint delegation  The DBA should not know the password  No Single person should know the password  It is possible to use a throw away password  Local System  Access to network shares can be configured to ServerName$ account if the server is a domain member

15. SQL Server logins  SQL Server logins are only available if configured during setup  Created on SQL Server  Can be created without the DBA knowing the password  Can be shared across servers (use sp_help_revlogin)  Can use Windows expiration and complexity rules  Needed for inter server communication via linked servers if domains are not trusted and for many Unix/Linux/Mac/Solaris applications  Technically deprecated since SQL 6.5 but will not go away any time soon

16. Special logins  sa  public  They exist even if SQL Server logins are not configured during setup but sa can’t be used to login in that case

17. Windows Active Directory Basics  There are Accounts and Groups  Accounts can be members of groups  Groups can be members of other groups  Each account or group has a unique ID the so called SID  Prior to SQL 2012 logins based on windows groups can’t be assigned a default schema

18. Mapping logins to users  In SQL Server you can create Logins that are mapped to Windows accounts or groups  The Windows account or group must exist  The mapping is done trough the SID  If the account gets renamed in AD it will continue to work in SQL Server  A user/application can login if either the Account or a group that the account is direct or indirect a member of is mapped on a SQL Server  If multiple logins exist the user is a member of the security is composed from all of them

19. Server Roles  Once a login is created/mapped on a SQL Server instance it can be made a member of one or more server roles  Very careful with this. Server roles assign a lot of power to the user and as a wise comic character once said. With great power comes great responsibility  sysadmin Anything  securityadmin Anything after granting yourself sysadmin  serveradmin Shutdown Server and change server settings  setupadmin Add remove linked servers  processadmin Kill Processes  diskadmin Create/Modify disk files  dbcreator Create or restore databases  bulkadmin Execute BULK INSERT  SQL 2012+: Custom server roles e.g.: CodeDebugger that can see server state and execution plans

20. Permissions 101 – Object Hierarchy  Instance  Database  Schema  Table, View, Procedure,… (Object)  Column  If a user gets SELECT granted on a table he/she can run a select against that table.  Granting SELECT on a schema allows the user to select data from every table in that schema

21. Permissions 102 – Basic Permissions  Each type of object has different permissions. Here are a few examples  Table  SELECT  INSERT  UPDATE  DELETE  Stored Procedure  EXECUTE  Schema  ALTER  EXECUTE  SELECT  INSERT  UPDATE  DELETE ……

22. Permissions 103 – Options for Permissions  SQL Server has three options for each permission  GRANTAllow use  DENY Don’t allow  REVOKENo setting, get GRANT/DENY from someplace else (DEFAULT = NO)  If you would permission each user on each object only GRANT and DENY would be needed. Once groups and the object hierarchy come into play REVOKE is needed too.  Granting a user SELECT on a schema and DENY SELECT on a table in that schema allows the user to select from each but this one table.  To remove that one exception you would place a REVOKE on the previously DENY.  Yes you could just GRANT SELECT it but then in case you REVOKE the SELECT from the schema the user still would have the select on the one table

23. Permissions 104 – The danger of DENY  If a user is DENYed access at one level this will always override a GRANT in another level.  The only exception is for members of the sysadmin role. It is impossible to REVOKE or DENY something for a sysadmin.

24. ROLES (Database Roles)  Since assigning lots of permissions to individual users is not effective you can assign permissions to roles and then add users (or other roles) as members. These users inherit then all permissions from the role.  If a user is member of multiples roles the permissions are combined  As before a DENY in one role will have priority over a GRANT in another.

25. Default Database Roles  db_owner perform all configuration and maintenance activities on the database, drop the database and take backup (you can use a trigger to prevent both)  db_securityadminmodify role membership and manage permissions/can elevate to db_owner  db_accessadmin can add or remove access to the database for Windows logins, Windows groups, and SQL Server logins.  db_backupoperator can back up the database.  db_ddladmin run any Data Definition Language (DDL) command in a database.  db_datawriter add, delete, or change data in all user tables.  db_datareader read all data from all user tables.  db_denydatawriter cannot add, modify, or delete any data in the user tables  db_denydatareader cannot read any data in the user tables

26. USER  Tying it all together (simplified)  Windows Account mapped to SQL Server Login (or SQL Server Login)  Mapped to a User in a database  User is member of database roles  Database roles have permissions on objects

27. Dangerous groups  All employees group  All service accounts  Groups that group groups  If they get there SID into a database they can access it  Granting or Denying permissions on these groups can have unexpected and unwanted side effects

28. Server Level Permissions  There is also a battery of more granular permissions that can be granted or denied (a few listed here)  ADMINISTER BULK OPERATIONS  ALTER ANY CREDENTIAL  ALTER ANY DATABASE  ALTER ANY LOGIN  ALTER ANY LINKED SERVER  ALTER SERVER STATE  ALTER TRACE  CREATE ANY DATABASE  IMPERSONATE  SHUTDOWN  VIEW ANY DEFINITION  VIEW ANY DATABASE  VIEW SERVER STATE

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

30. 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.

31. 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. This should never be set on a DWH/BI database

32. Big problem with RESTORE DATABASE  To execute restore database the user must be at least DATABASE CREATOR on the server  The default owner of the database is the login that restored the database  An execute as owner stored procedure can now restore any other database (including MSDB, the newly restored MSDB could have a job defined running as SA doing whatever it wants …)  Workaround have a RestoreLogin that is only database creator, a trigger that prevents this login from restoring a database named msdb or model and execute the restore as EXEC ('RESTORE DATABASE d1 FROM DISK = ''c:\...'';') AS LOGIN = 'RestoreLogin‘

33. Security for HA/DR  Logins must by synchronized to second location  If you initialize Logshipping and/or AlwaysOn via GUI then the secondary nodes do not have the same owner  Unless you use the restore trick from before then in case of LogShipping, Database Mirroring and AlwaysOn the secondary databases have a different owner in case of a failover (high privilege owner)  Linked Servers must be created on each node  Certificates must be installed on each node

34. The Goal  For the same user have different permissions in the DWH than on the OLTP source system  Use  Always On Readable Mirrors  Database Mirroring with snapshots or  Standby Read Only Log Shipping to bring the data to the DWH server

35. The Problem  In all three cases the database on the DWH server is read only and permissions can not be changed

36. The Solution  Use AD Groups to give the same user two different identities

38. THANK YOU! and may the force be with you… Questions? thomas.grohser@nttdata.com tg@grohser.com

39. Encryption  Best done in application layer and then send to SQL Server as encrypted value.  Encrypted columns limit search ability  OS file system encryption (EFS)  Works  Is a pain in the a#%#%$  Slow, hard to maintain

40. TDE – Transparent Database Encryption  Encrypts the whole database  Great for making sure the data can’t be read from a stolen/copied disk  Great for encrypting backups  Bad for compressing backups  Excellent for whitelisting databases on instances  Only as good as the Certificate Management

41. Keys and Certificates for TDE  Database Master Key in master database  Used to protect all certificates in master database  Certificates in master database  Used to protect the database encryption key  Database Encryption Key  Used to encrypt the database

42. Key Management  Separate from DBA or Automate  I create them all on a central server and then Backup/Restore to the one I need the databases deployed. The Central server maintains a whitelist that is maintained by the security department and cannot be modified by the DBA’s even if they are logged in as sysadmin

43. Preventing DBAs and sysadmins from modifying data  It is impossible to DENY a member of the sysadmin server role anything  Workaround  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 execute  You might want to exclude triggers in normal databases

44. master database and stuff that starts with sp_  sp_ … is not TLA (two letter acronym) for stored procedure  sp_ … is short for special  Every object created in master database that starts with sp_ appears magically in every database  Yes not just stored procedures also table for example  DEMO

45. Auditing  Who can read the audit logs?  What to audit?  Audit logs can become very large very quickly  How to prevent a text from going into the audit log or a Trace / X-Event SELECT CASE WHEN 42=42 THEN 'Secret Text' ELSE ENCRYPTBYPASSPHRASE('', '') END

46. Linked Servers  The user context must be forwarded or mapped to the other server  SQL Server Logins must be forwarded or mapped to SQL Login  Windows Logins can be forwarded or mapped to SQL Server Login  Constrained Delegation  Catch all to an account includes public / guest users on the source server. Use with caution  DEMO  No way to script existing SQL Logins.  Create process to manage

47. Secure Deployment  Audit code before it goes into production  Deployment account is the only account that can execute DDL  Audit all other accounts for DDL or even have a rollback trigger for DDL

48. Baseline Security  Have a script with your default security settings  Run it every n hours on each server

49. Using Trustworthy Databases for the Good  Have an Admin database on each server (stay out of master), I like to call it X  Make it owned by sa and TRUSTWORTHY  Make sure all code is vetted  Create schemas like  Run  Find  List ……  Create a Database Role DBA_F5_Role and add the DBA Users to it  Create procedures WITH EXECUTE AS OWNER like  Run.Backup …  List.LogSpace …  Find.BlockingTransactions … ……  Create a login the DBA’s can use in case an unforeseen event happens  Remove sysadmin role from the DBA user accounts