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

Thank you to our AWESOME sponsors!

Security Enhancements in SQL Server 2016

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”

is this familiar or not?

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

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

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

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.

How does it work?

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: https://msdn.microsoft.com/en-us/library/dn765131(v=sql.130).aspx 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

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: https://msdn.microsoft.com/en- us/library/mt163865(v=sql.130).aspx

Always Encrypted Help protect data at rest and in motion, on-premises & cloud Trusted Apps SELECT Name FROM Patients WHERE SSN=@SSN @SSN='198-33-0987' SQL Server SELECT Name FROM Patients WHERE SSN=@SSN @SSN=0x7ff654ae6d Client side Enhanced ADO.NET Library dbo.Patients Jane Doe Name 243-24-9812 SSN USA Country Jim Gray 198-33-0987 John Smith 123-82-1095 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: https://msdn.microsoft.com/en-us/library/mt163865(v=sql.130).aspx 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.

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: https://msdn.microsoft.com/en-us/library/mt147923(v=sql.130).aspx 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

Demo

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: https://msdn.microsoft.com/en-us/library/bb510411(v=sql.130).aspx#Security

Q & A

Security resources MSDN Documentation https://msdn.microsoft.com/en-us/library/dn765131.aspx Security Center for SQL Server Database & Azure SQL Database https://msdn.microsoft.com/en-us/bb510589.aspx SQL Server Security Blog Additional examples, useful tips and tricks http://blogs.msdn.com/b/sqlsecurity/