Secure SQL Server Design Tactics and Technology

Thanks to Our Sponsors! Sponsors

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!

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

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

Tables, Views, and Stored Procedures

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

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

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

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;

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

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;

What’s My Role?

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

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)

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!!!!

SQL Server’s Built-in Features

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

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)

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

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 RowLevelSecurity.OrdersCustomerIdPredicate(@userId 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) = @userId; -- 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);

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 sp_set_session_context @key = 'UserId', @value = 4; -- Get #4's data SELECT * FROM Sales.Orders; -- Change the session context EXEC sp_set_session_context @key = 'UserId', @value = 5; -- Get #5's data REVERT;

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

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, Email VARCHAR(253) MASKED WITH (FUNCTION = 'email()') NOT NULL, Phone VARCHAR(20) MASKED WITH (FUNCTION = 'default()') NOT NULL ); INSERT INTO dbo.DynamicDataMaskingDemo (FirstName, LastName, Email, Phone) VALUES ('Dan', 'Mallott', 'dmallott@wmp.com', '312-754-4749'); SELECT * FROM dbo.DynamicDataMaskingDemo; CREATE USER TestUser WITHOUT LOGIN; GRANT SELECT ON dbo.DynamicDataMaskingDemo TO TestUser; EXECUTE AS USER = 'TestUser'; REVERT;

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

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;

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

Retrofitting

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

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

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

Questions?

Who Am I? Dan Mallott Twitter: @DanielMallott Blog: https://www.danielmallott.com Github: https://github.com/danielmallott LinkedIn: http://lnked.in/danmallott 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

More Reading Transparent Data Encryption Database Encryption Key https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption?view=sql-server-2017 Database Encryption Key https://docs.microsoft.com/en-us/sql/t-sql/statements/create-database-encryption-key-transact-sql?view=sql-server-2017 Row Level Security https://docs.microsoft.com/en-us/sql/relational-databases/security/row-level-security?view=sql-server-2017 Dynamic Data Masking https://docs.microsoft.com/en-us/sql/relational-databases/security/dynamic-data-masking?view=sql-server-2017 Always Encrypted https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/always-encrypted-database-engine?view=sql-server-2017 SQL Server Audit https://docs.microsoft.com/en-us/sql/relational-databases/security/auditing/sql-server-audit-database-engine?view=sql-server-2017 https://docs.microsoft.com/en-us/azure/sql-database/sql-database-auditing