1. Security Enhancements in SQL Server 2016
Leonel Abreu
Security Enhancements in SQL Server 2016

2. Thank you to our AWESOME sponsors!

3. Security Enhancements in SQL Server 2016

4. Agenda What’s new in SQL Server 2016 Other Security Enhancements Demos
Dynamic Data Masking
Row Level Security
Always encrypted
Other Security Enhancements
Additional Info
Demos
A practical “how to”

5. is this familiar or not?

6. is this familiar or not? - - -
* * * *
* * * *
* * * *

7. Dynamic Data Masking Masking rules Default Custom string Email Random
Image extracted from MSDN

8. Row Level Security Allow to control how the users accesses data
The same query return different rows
Simplifies application development
No additional coding required
Database side security and easy to deploy
Reduces application complexity

9. Row Level Security
Protect data privacy by ensuring the right access across rows
Fine-grained access control over specific rows in a database table
Help prevent unauthorized access when multiple users share the same tables, or to implement connection filtering in multitenant applications
Administer via SQL Server Management Studio or SQL Server Data Tools
Enforcement logic inside the database and schema bound to the table.
User 1
User 2
User 3
SQL Database
Row-Level Security (RLS) simplifies the design and coding of security in your application. RLS enables you to implement restrictions on data row access. For example ensuring that workers can access only those data rows that are pertinent to their department, or restricting a customer's data access to only the data relevant to their company.
The access restriction logic is located in the database tier rather than away from the data in another application tier. The database system applies the access restrictions every time that data access is attempted from any tier. This makes your security system more reliable and robust by reducing the surface area of your security system.
Implement RLS by using the CREATE SECURITY POLICY Transact-SQL statement, and predicates created as inline table valued functions.
Limitations during the preview:
RLS is incompatible with database export using Data Tier Application Framework (DACFx). You must drop all RLS policies before exporting.
Security policies cannot target views.
Certain query patterns using OR logic can trigger un-optimized table scans, decreasing query performance.
No syntax highlighting in SQL Server tools.

10. How does it work?

11. Key Elements Predicate function Security predicate Security policy
User-defined inline table-valued function (iTVF) implementing security logic
Can be arbitrarily complicated, containing joins with other tables
Security predicate
Applies a predicate function to a particular table (SEMIJOIN APPLY)
Two types: filter predicates and blocking predicates
Security policy
Collection of security predicates for managing security across multiple tables
Source:
Row-Level Security enables customers to control access to rows in a database table based on the characteristics of the user executing a query (e.g., group membership or execution context).
Row-level filtering of data selected from a table is enacted through a security predicate filter defined as an inline table valued function. The function is then invoked and enforced by a security policy. The policy can restrict the rows that may be viewed (a filter predicate), but does not restrict the rows that can be inserted or updated from a table (a blocking predicate). There is no indication to the application that rows have been filtered from the result set; if all rows are filtered, then a null set will be returned.
Filter predicates are applied while reading data from the base table, and it affects all get operations: SELECT, DELETE (i.e. user cannot delete rows that are filtered), and UPDATE (i.e. user cannot update rows that are filtered, although it is possible to update rows in such way that they will be subsequently filtered). Blocking predicates are not available in this version of RLS, but equivalent functionality (i.e. user cannot INSERT or UPDATE rows such that they will subsequently be filtered) can be implemented using check constraints or triggers.
Filter predicates and security policies have the following behavior:
Define a security policy that filters the rows of a table. The application is unaware that any rows have been filtered for SELECT, UPDATE, and DELETE operations, including situations where all the rows have been filtered out. The application can INSERT any rows, regardless of whether or not they will be filtered during any other operation.
Define a predicate function that joins with another table and/or invokes a function. The join/function is accessible from the query and works as expected without any additional permission checks.
Issue a query against a table that has a security predicate defined but disabled. Any rows that would have been filtered or restricted are not affected.
The dbo user, a member of the db_owner role, or the table owner queries against a table that has a security policy defined and enabled. Rows are filtered/restricted as defined by the security policy.
Attempts to alter the schema of a table bound by a security policy will result in an error. However, columns not referenced by the filter predicate can be altered.
Attempts to add a predicate on a table that already has one defined (regardless of whether it is enabled or disabled) results in an error.
Attempts to modify a function used as a predicate on a table within a security policy results in an error.
Defining multiple active security policies that contain non-overlapping predicates, succeeds.
CREATE SECURITY POLICY mySecurityPolicy
ADD FILTER PREDICATE dbo.fn_securitypredicate(wing, startTime, endTime)
ON dbo.patients

12. Always Encrypted Prevents Disclosure Queries on Encrypted Data
Client-side encryption of sensitive data using keys that are never given to the database system.
Queries on Encrypted Data
Support for equality comparison, incl. join, group by and distinct operators.
Application Transparency
Minimal application changes via server and client library enhancements.
Prevents data disclosure
According to msdn:
Allows customers to securely store sensitive data outside of their trust boundary.
Data remains protected from high- privileged, yet unauthorized users.
Source: us/library/mt163865(v=sql.130).aspx

13. Always Encrypted
Help protect data at rest and in motion, on-premises & cloud
Trusted
Apps
SELECT Name FROM Patients WHERE
@SSN=' '
SQL Server
SELECT Name FROM Patients WHERE
@SSN=0x7ff654ae6d
Client side
Enhanced ADO.NET
Library
dbo.Patients
Jane Doe
Name
SSN
USA
Country
Jim Gray
John Smith
Query
Result Set
Jim Gray
Name
Jane Doe
1x7fg655se2e
SSN
USA
Country
0x7ff654ae6d
John Smith
0y8fj754ea2c
dbo.Patients
Column
Master Key
Column Encryption Key
Result Set
Jim Gray
Name
ciphertext
dbo.Patients
Jane Doe
Name
1x7fg655se2e
SSN
USA
Jim Gray
0x7ff654ae6d
John Smith
0y8fj754ea2c
Country
Source:
Always Encrypted is a feature designed to protect sensitive data, such as credit card numbers or national identification numbers (e.g. U.S. social security numbers), stored in SQL Server databases. Always Encrypted allows clients to encrypt sensitive data inside client applications and never reveal the encryption keys to SQL Server. As a result, Always Encrypted provides a separation between those who own the data (and can view it) and those who manage the data (but should have no access). By ensuring on-premises database administrators, cloud database operators, or other high-privileged, but unauthorized users, cannot access the encrypted data, Always Encrypted enables customers to confidently store sensitive data outside of their direct control. This allows organizations to encrypt data at rest and in use for storage in Azure, to enable delegation of on-premises database administration to third parties, or to reduce security clearance requirements for their own DBA staff.
Always Encrypted makes encryption transparent to applications. An Always Encrypted-enabled driver installed on the client computer achieves this by automatically encrypting and decrypting sensitive data in the SQL Server client application. The driver encrypts the data in sensitive columns before passing the data to SQL Server, and automatically rewrites queries so that the semantics to the application are preserved. Similarly, the driver transparently decrypts data, stored in encrypted database columns, contained in query results.

14. Key Provisioning 1. Generate CEKs and Master Key 2. Encrypt CEK
Column Encryption Key
(CEK)
Column
Master Key
(CMK)
2. Encrypt CEK
Encrypted
CEK
CMK Store:
Certificate Store
HSM
Azure Key Vault …
CMK
3. Store Master Key Securely
Security
Officer
Source:
Creating and registering a custom Column Master Key Store Provider
Information the driver receives from SQL Server for query parameters which need to be encrypted, and for query results which need to be decrypted, includes:
An encrypted value of a column encryption key, which should be used to encrypt or decrypt a parameter or a result.
The name of a key store provider that encapsulates a key store containing the column master key which was used to encrypt the column encryption key.
A key path that specifies the location of the column master key in the key store.
The name of the algorithm that was used to encrypt the column encryption key.
The driver uses the above information to use the key store provider implementation to decrypt the retrieved encrypted value of the column encryption key, which is subsequently used to either encrypt a query parameter or to decrypt a query result.
The driver comes with an implementation for one system provider: SqlColumnEncryptionCertificateStoreProvider which can be used to store column master keys in Windows Certificate Store.
You can use a custom key store provider by extending the SqlColumnEncryptionKeyStoreProvider class and registering it using the SqlConnection.RegisterColumnEncryptionKeyStoreProviders() method.
4. Upload Encrypted CEK to DB
Encrypted CEK
Database

15. Demo

16. Other security enhancements
Audit success/failure of database operations
Enhanced auditing for OLTP with ability to track history of record changes
Transparent Data Encryption support for storage of In- memory OLTP Tables
Backup encryption now supported with compression
Source:

17. Q & A

18. Security resources MSDN Documentation
Security Center for SQL Server Database & Azure SQL Database
SQL Server Security Blog
Additional examples, useful tips and tricks