1. Secure SQL Server Design
Tactics and Technology

2. Thanks to Our Sponsors!
Sponsors

3. A Quick Note
This is meant to be a high-level survey of the tactics and technology available for securing SQL Server
If you are looking for in-depth treatment of these topics, this may not be the session for you!

4. What’s On Deck Introduction Secure Database Objects What’s My Role?
SQL Server Built-in Features and How/When to Use Them
When You Can’t Start Fresh
Questions

5. Some Scary Facts About Data Breaches
Introduction
95% of all breached records were in Government, retail, and technology in 2016
There is a hacker
attack every
39 seconds
The average cost of a data breach is expected to exceed $150M in 2020
Over 3.8 million
records are stolen
every day
95% of data
breaches are due
to human
error

6. Tables, Views, and Stored Procedures

7. How Can We Limit Access to Sensitive Data?
Tables, Views, and Stored Procedures
Views can be used to hide sensitive data in underlying tables – you only expose the columns you want exposed and you can apply masks to them
Since views are selectable and filterable (and indexable in certain cases) just like tables, they can be good substitutes for tables themselves
(Remember that views do execute the underlying SQL every time, so they are not exactly like tables)
We can split tables to hold sensitive data in a side table that is more secure
Yes, this has some drawbacks
We can use schemas to separate tables with sensitive data (along with logically organizing our databases)
Access to tables can be secured individually; schemas are much the same
Tables
Views

8. Splitting Tables Tables, Views, and Stored Procedures
USE SQL_Saturday_Louisville; GO CREATE TABLE dbo.TableWithoutSensitiveInfo ( Id INT IDENTITY(1,1) NOT NULL CONSTRAINT PK_TableWithoutSensitiveInfo PRIMARY KEY CLUSTERED, FirstName VARCHAR(250) NOT NULL, LastName VARCHAR(250) NOT NULL, HireDate DATETIME2(7) NOT NULL CONSTRAINT DF_TableWithoutSensitiveInfo DEFAULT(SYSDATETIME()) ); CREATE TABLE dbo.TableWithSensitiveInfo Id INT NOT NULL CONSTRAINT FK_Id FOREIGN KEY REFERENCES dbo.TableWithoutSensitiveInfo(Id), SSN CHAR(10) NOT NULL, Salary DECIMAL(17,2) NOT NULL, BirthDate DATE NOT NULL CREATE UNIQUE CLUSTERED INDEX UX_TableWithSensitiveInfo ON dbo.TableWithSensitiveInfo(Id);

9. Splitting Tables with Schemas
Tables, Views, and Stored Procedures
Splitting Tables with Schemas
USE SQL_Saturday_Louisville; GO CREATE SCHEMA NonSecureData AUTHORIZATION dbo; CREATE TABLE NonSecureData.Employee ( Id INT IDENTITY(1,1) NOT NULL CONSTRAINT PK_TableWithoutSensitiveInfo PRIMARY KEY CLUSTERED, FirstName VARCHAR(250) NOT NULL, LastName VARCHAR(250) NOT NULL, HireDate DATETIME2(7) NOT NULL CONSTRAINT DF_TableWithoutSensitiveInfo DEFAULT(SYSDATETIME()) ); CREATE SCHEMA SecureData AUTHORIZATION dbo; CREATE TABLE SecureData.Employee Id INT NOT NULL CONSTRAINT FK_Id FOREIGN KEY REFERENCES NonSecureData.Employee(Id), SSN CHAR(10) NOT NULL, Salary DECIMAL(17,2) NOT NULL, BirthDate DATE NOT NULL CREATE UNIQUE CLUSTERED INDEX UX_TableWithSensitiveInfo ON SecureData.Employee(Id);

10. Using a View Tables, Views, and Stored Procedures
USE SQL_Saturday_Louisville; GO CREATE VIEW dbo.HumanResourcesEmployeeView WITH SCHEMABINDING, -- So we prevent mucking with the underlying tables without also modifying this guy VIEW_METADATA, -- So we report metadata as though this were a table ENCRYPTION -- So we can't see the underlying definition in the system tables AS SELECT NSDE.Id ,NSDE.FirstName ,NSDE.LastName ,NSDE.HireDate ,SDE.BirthDate ,'XXX-XX-' + SUBSTRING(SDE.SSN, 8, 4) AS SSN ,SDE.Salary FROM NonSecureData.Employee AS NSDE INNER JOIN SecureData.Employee AS SDE ON NSDE.Id = SDE.Id; CREATE USER HumanResourcesUser WITHOUT LOGIN; GRANT SELECT ON dbo.HumanResourcesEmployeeView TO HumanResourcesUser; EXECUTE AS USER = 'HumanResourcesUser'; SELECT * FROM dbo.HumanResourcesEmployeeView; SELECT SSN FROM SecureData.Employee; REVERT;

11. Stored Procedures Can Help
Tables, Views, and Stored Procedures
Using Stored Procedures (and restricting access to only Stored Procedures) is the easiest basic way to handle security
Stored Procedures will return only the data that they need to return
Using stored procedures for other data management activities allows you to apply business logic and make sure inputs are properly sanitized
By disallowing direct access to tables, you are effectively preventing SQL injection attacks (assuming you properly sanitize inputs)
Using only stored procedures for data management will have impact on your application developers!
However, most ORMs have the facility to use stored procedures for data access
Dapper is an excellent micro-ORM that plays well with stored procedure data access

12. Using a Stored Procedure
USE SQL_Saturday_Louisville; GO CREATE PROCEDURE dbo.GetEmployees AS BEGIN SELECT NSDE.Id ,NSDE.FirstName ,NSDE.LastName ,NSDE.HireDate ,SDE.BirthDate ,'XXX-XX-' + SUBSTRING(SDE.SSN, 8, 4) AS SSN ,SDE.Salary FROM NonSecureData.Employee AS NSDE INNER JOIN SecureData.Employee AS SDE ON NSDE.Id = SDE.Id; END; GRANT EXECUTE ON dbo.GetEmployees TO HumanResourcesUser; EXECUTE AS USER = 'HumanResourcesUser'; EXEC dbo.GetEmployees; SELECT * FROM NonSecureData.Employee; REVERT;

13. What’s My Role?

14. How Do We Manage Security for All These Objects?
What’s My Role?
Roles allow you to logically group permissions at the database or server level
You are probably familiar with some roles already:
db_owner
db_datareader
db_datawriter
sysadmin
securityadmin
serveradmin
These are predefined roles with predefined sets of permissions
For example, db_datareader gives role members the right to read data from any table in the database

15. How Do We Manage Security for All These Objects?
What’s My Role?
How Do We Manage Security for All These Objects?
Roles allow you to logically group permissions at the database or server level
You are probably familiar with some roles already:
db_owner
db_datareader
db_datawriter
sysadmin
securityadmin
serveradmin
These are predefined roles with predefined sets of permissions (e.g. db_datareader can read all tables)

16. Should We Be Satisfied With the Built In Roles?
What’s My Role?
The built in roles are very broad-based and not suitable for environments where more detailed permissions are required
We can define our own roles that group permissions logically
We can mix permissions to give each role only the permissions it needs
This is called the principle of least privilege and is considered best practice
From here, we can assign users to roles based on their membership
Or, for extra security and to integrate with what our System Administrators are doing already, we can assign Active Directory groups to roles
Then, when we need to revoke access, simply removing the user from the role or the user from the Active Directory group will do the job
NO!!!!

17. SQL Server’s Built-in Features

18. Built-in Features Always Encrypted Row Level Security
Dynamic Data Masking
Transparent Data Encryption
SQL Server Audit

19. WHY WOULD I WANT TO USE IT?
Always Encrypted
Always Encrypted
WHAT IS IT?
Always Encrypted is a feature that allows you to control encryption inside client applications and never share the keys with the Database Engine
Anyone reading a column encrypted with Always Encrypted will only see an encrypted binary string
WHY WOULD I WANT TO USE IT?
Using Always Encrypted can help to protect sensitive data by removing the ability to read it at all from the database
WHAT ARE THE DRAWBACKS?
Not all clients support Always Encrypted
Data encrypted via the “Randomized” routine cannot be used for joins or other operations requiring equality operations
Encrypted columns cannot be updated using the database engine directly
Columns must use a different collation (any of the BIN2 collations)

20. WHY WOULD I WANT TO USE IT?
Row Level Security
Row Level Security
WHAT IS IT?
Row level security allows you to use either group membership or execution context to restrict access to data rows in a specific table using a table-valued function applied as a WHERE clause to a query
This happens transparently to consumers!
WHY WOULD I WANT TO USE IT?
Row level security is transparent to consumers and helps to centralize security logic, particularly when there are multiple consumers (e.g. a web application and PowerBI)
There is generally broad compatibility with most SQL Server features
WHAT ARE THE DRAWBACKS?
There may be a performance hit depending on the logic of the table-valued function
Partitioned Views are not supported
You cannot create an index on a view on top of a table with a row level security policy in force
Temporal tables do not automatically inherit the security policies of their parents

21. How to Enable Row Level Security
USE SQL_Saturday_Louisville; GO -- Create a schema to store our security objects CREATE SCHEMA RowLevelSecurity; -- Create our function -- NOTE: this is reusable! CREATE FUNCTION INT) RETURNS TABLE WITH SCHEMABINDING -- To remove the need for additional permissions on security objects AS RETURN SELECT 1 AS OrdersCustomerIdPredicateResult WHERE CAST(SESSION_CONTEXT(N'UserId') AS INT) -- May want to also filter by login if you have multiple logins or applications -- Create our security policy on our table CREATE SECURITY POLICY RowLevelSecurity.OrdersCustomerId ADD FILTER PREDICATE RowLevelSecurity.OrdersCustomerIdPredicate(CustomerId) ON Sales.Orders, ADD BLOCK PREDICATE RowLevelSecurity.OrdersCustomerIdPredicate(CustomerId) ON Sales.Orders AFTER INSERT WITH (STATE = ON);

22. Testing Row Level Security
USE SQL_Saturday_Louisville; GO -- For demo purposes, create a user without login CREATE USER CustomerApplicationUser WITHOUT LOGIN; GRANT SELECT, UPDATE, DELETE, INSERT ON Sales.Orders TO CustomerApplicationUser; -- Don't let the user update the column we're filtering on DENY UPDATE ON Sales.Orders(CustomerID) TO CustomerApplicationUser; -- Execute as our temporary user EXECUTE AS USER = 'CustomerApplicationUser'; -- Set the session context. Ordinarily, this would be set from the application EXEC = = 4; -- Get #4's data SELECT * FROM Sales.Orders; -- Change the session context EXEC = = 5; -- Get #5's data REVERT;

23. WHY WOULD I WANT TO USE IT?
Dynamic Data Masking
Dynamic Data Masking
WHAT IS IT?
Dynamic Data Masking applies a masking function to data when it is read by non-privileged users
Like Row Level Security, this process is transparent to users
WHY WOULD I WANT TO USE IT?
Rather than relying on application-level filters, Dynamic Data Masking allows you to specify a mask for data that applies to all queries
Like Row Level Security, there is broad compatibility with other SQL Server features
You can specify your own masking function, or use the default
WHAT ARE THE DRAWBACKS?
Columns encrypted using Always Encrypted cannot also have a mask applied to them
You cannot apply a mask to a computed column, unless one of the underlying columns is also masked
It may still be possible to derive the underlying data by applying a clever WHERE clause

24. How to Use Dynamic Data Masking
USE SQL_Saturday_Louisville; GO CREATE TABLE dbo.DynamicDataMaskingDemo ( Id INT IDENTITY(1,1) NOT NULL CONSTRAINT PK_DynamicDataMaskingDemo PRIMARY KEY CLUSTERED, FirstName VARCHAR(250) MASKED WITH (FUNCTION = 'partial(1, "XXXXXX", 0)') NOT NULL, LastName VARCHAR(250) NOT NULL, VARCHAR(253) MASKED WITH (FUNCTION = ' ()') NOT NULL, Phone VARCHAR(20) MASKED WITH (FUNCTION = 'default()') NOT NULL ); INSERT INTO dbo.DynamicDataMaskingDemo (FirstName, LastName, , Phone) VALUES ('Dan', 'Mallott', ' '); SELECT * FROM dbo.DynamicDataMaskingDemo; CREATE USER TestUser WITHOUT LOGIN; GRANT SELECT ON dbo.DynamicDataMaskingDemo TO TestUser; EXECUTE AS USER = 'TestUser'; REVERT;

25. Transparent Data Encryption
WHAT IS IT?
Transparent Data Encryption (TDE) is the practice of encrypting the data in a database while it is at rest
This includes backup files taken using SQL Server’s built-in backup functionality!
WHY WOULD I WANT TO USE IT?
Provides an additional level of security for your data at rest, making it more resistant to being compromised if the storage device is stolen
By extending encryption to backups, those are protected as well, which may become more important depending on the storage media and location
WHAT ARE THE DRAWBACKS?
The server OS probably already covers this need, whether via Bit Locker or some other method
The ability to read the data is entirely dependent on the certificate, and that extends to the backups as well! If you lose the certificate, your backups become unreadable
The good news is that TDE integrates with several Key Management providers, including Azure Key Management
Instant file initialization is not available when using TDE

26. How To Enable TDE Transparent Data Encryption
USE [master]; GO -- Use a stronger password than this! CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Password123!'; -- Create a certificate based on our Master Key -- Also, back it up! CREATE CERTIFICATE SpeakingDatabaseServerCertificate WITH SUBJECT = 'Server Database Encryption Certificate'; USE SQL_Saturday_Louisville; -- Create the Database-level Encryption Key CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER CERTIFICATE SpeakingDatabaseServerCertificate; -- Turn it on - this may take a minute. ALTER DATABASE SQL_Saturday_Louisville SET ENCRYPTION ON;

27. WHY WOULD I WANT TO USE IT?
SQL Server Audit
SQL Server Audit
WHAT IS IT?
SQL Server Audit allows you to log events and the details about those events when they happen on the server level or the database level
Audits can include permission changes, object access, and more granular actions such as when a specific user or group of users accesses data on a specific table
WHY WOULD I WANT TO USE IT?
SQL Server Audit provides a built-in way to log events and ensure security policies are followed while ensuring traceability in the event of an external audit
SQL Server Audit can help detect attacks against the server; for example, a high number of failed logins may indicate a malicious attack
WHAT ARE THE DRAWBACKS?
As with many other features, anyone with sysadmin can alter the auditing or even turn it off altogether
Events are logged to the Windows Event Log or file, both of which can be difficult to access easily
By itself, SQL Server Audit does not perform any active alerting

28. Retrofitting

29. All this is great, but what do I do with my existing database?

30. Things You Can Do Today (and By Today, I Mean Monday)
Retrofitting 1
Enable Transparent Data Encryption
Yes, your OS probably handles this already (or your system administrator or your SAN administrator), and, yes, it’s just a check box item in Azure
However, you don’t want to find our your unencrypted database backup is sitting on a publicly available S3 or Azure Blob instance, and this will help mitigate that 2
Take an inventory of your users and their permissions (if you don’t have this already)
If you are going to a role-based system, this is a necessary first step, since you have to design the roles
This will also help track down anyone who has way more highly elevated permissions than they should 3
Talk to your boss about conducting a security audit 4
Talk to your security/compliance people
Find out what they are already doing and how they think you can help 5
Talk to your application developers about how they consume data
Most likely, they will use some sort of ORM, probably Hibernate or Entity Framework
This can help you understand what object changes you can make without affecting application functionality and which will require code changes
Your application developers may be unaware of some of these features as well

31. Start Planning Deeper Changes
Retrofitting
Month One
Month Two
Month Three
Month Four
Month Five
Month Six
Planning
Execution
Test!
Engage with the entire IT team to start planning deeper changes, such as:
Stronger role-based access
Data access through views or stored procedures only
Schema-based data grouping
SQL Server Audit strategies
Usage of Dynamic Data Masking and Row Level Security
Some projects may be able to be done transparently, such as switching to views for data access; however, it’s a good idea to make sure your entire team is on board
As always, make sure to have a solid test plan in place
Don’t just make changes to production - these can be RGEs (Resume Generating Events)!

32. Questions?

33. Who Am I? Dan Mallott Twitter: @DanielMallott
Blog:
Github:
LinkedIn:
Principal for West Monroe Partners
In the industry since 2011
Primary experience with SQL Server, starting with SQL Server 2005
Also worked with Oracle, PostgreSQL, and Cassandra
Been both a DBA and a developer
Have a couple Microsoft certifications
DataStax Certified Professional

34. More Reading Transparent Data Encryption Database Encryption Key
Database Encryption Key
Row Level Security
Dynamic Data Masking
Always Encrypted
SQL Server Audit