1. Security, Security, Secuirty
=tg= Thomas Grohser, NTT Data
SQL Server MVP
SQL Server Performance Engineering
SQL Saturday #574 Washington, DC December 3rd 2016

2. select * from =tg= where topic =
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
AlwaysOn Automatic HA and DR
SQL 2016
Can’t wait to raise the bar again
=tg= Thomas Grohser,
NTT DATA
Senior Director Technical Solutions Architecture /
Focus on SQL Server Security, Performance Engineering,
Infrastructure and Architecture
New Papers coming 2017
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
23 Years with SQL Server

3. NTT DATA Overview Why NTT DATA for MS Services:
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 MS solutions delivered in the past 20 years

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

5. 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, …)

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

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

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

9. 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?

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

11. 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
Local System
Access to network shares can be configured to ServerName$ account if the server is a domain member
MSA (Managed Service Account) MSAG (Managed Service Account Group)
Best choice if your AD and SQL Server are current

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

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

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

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

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

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

18. 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 …

19. Permissions 103 – Options for Permissions
SQL Server has three options for each permission
GRANT Allow use
DENY Don’t allow
REVOKE No 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

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

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

22. 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_securityadmin modify 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

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

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

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

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

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

28. 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
Change ASAP after the restore to a dummy account with no privileges

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

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

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

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

34. QUESTIONS tg@grohser.com

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

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

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

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

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

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

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

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

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

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

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