#SQLSAT454 SQL Server 2016 New Security Features Gianluca

#SQLSAT454 Sponsors

#SQLSAT454 Gianluca Sartori  Independent SQL Server consultant  SQL Server MVP, MCTS, MCITP, MCT  Works with SQL Server since version 7  Scuderia Ferrari  Blog: spaghettidba.comspaghettidba.com  Twitter:

#SQLSAT454 Agenda  Security Boundaries  Always Encrypted  Row Level Security  Dynamic Data Masking

#SQLSAT454 Why New Security Features?  SQL Server has plenty security features  TDE  Protects database files and backups at rest  Cell-Level Encryption  Encrypts single values in database tables  SSL  Protects data on the network

#SQLSAT454 Security Boundaries – Open Apps SSMS Database Developer DBA Manager User Software Vendor Unauthorized Users

#SQLSAT454 Security Boundaries – Non Sensitive Apps SSMS Database Developer DBA Manager User Software Vendor Unauthorized Users Copy

#SQLSAT454 Security Boundaries – Sensitive Apps SSMS Database Developer DBA Manager User Software Vendor Unauthorized Users Copy

#SQLSAT454 ALWAYS ENCRYPTED

#SQLSAT454 Always Encrypted – Key Features Prevents Data Disclosure End-to-end encryption of individual columns in a table with 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.

#SQLSAT454 Always Encrypted  Sensitive data is encrypted at column level  Data is protected from high-privileged users  DBAs  System Admins  Hackers  Data is stored securely outside security boundaries  The database never sees unencrypted data  Cloud providers  Third-parties

#SQLSAT454 Always Encrypted – How it works App SELECT Name FROM Patients Column Encryption Key Jane Doe Name 1x7fg655se2 e SSN USA Country Jim Gray0x7ff654ae6dUSA John Smith0y8fj754ea2cUSA dbo.Patients Result Set Jim Gray Name Query Application - TrustedSQL Server - Untrusted SELECT Name FROM Patients Enhanced ADO.NET Library SQL Server Native Client.NET 4.6 Column Master Key

#SQLSAT454 Encryption Types  Deterministic Encryption Same plaintext value  Same encrypted value Supports indexing, equality comparison, JOINs, DISTINCT  Randomized Encryption Same plaintext value  Different encrypted value Supports retrieval of encrypted data No SQL operations supported

#SQLSAT454 DEMO Working with Always Encrypted

#SQLSAT454 TDE vs Always Encrypted Always EncryptedTDE Column levelDatabase level Client encryptionServer encryption Server doesn’t know encryption keys Server knows encryption keys Data in memory is encryptedData in memory is in plaintext Data travels the network encrypted Data travels the network in plaintext

#SQLSAT454 Custom encryption vs Always Encrypted Always EncryptedCustom Encryption Slight application changesNeeds obtrusive changes Disallows saving plaintext data Plaintext data can be saved by accident Allows indexing of cyphertext * * depending on encryption algorithm

#SQLSAT454 Always Encrypted - Limitations  Deterministic encryption needs _BIN2 collation  Not all datatypes supported  Partial support for triggers  Unsupported features:  Full-text search  Replication  Change Data Capture  In-Memory OLTP  Stretch Database

#SQLSAT454 What changes for Applications?  ConnectionString must include new key: Column Encryption Setting=enabled;  Ad-hoc queries not supported SELECT SomeColumn FROM SomeTable WHERE EncrypedColumn = 'SomeValue';  Needs correctly parameterized queries SELECT SomeColumn FROM SomeTable WHERE EncrypedColumn

#SQLSAT454 Always Encrypted for Existing Data  Existing columns must be encrypted client side  Easiest way: Import / Export wizard Ad-hoc wizard In SSMS 2016?

#SQLSAT454 Performance Impact

#SQLSAT454 Space Usage Impact

#SQLSAT454 Q&A Questions?

#SQLSAT454 DYNAMIC DATA MASKING

#SQLSAT454 Dynamic Data Masking – Key Features Limits Sensitive Data Exposure Sensitive data is masked. Administrators designate how much of the sensitive data to reveal. Useful for Compliance Helps adhering to privacy standards imposed by regulation authorities. Application Transparency No application changes. Existing queries keep working.

#SQLSAT454 Dynamic Data Masking Database Non-Privileged User Privileged User Unmasked Data DATA Jane Doe Name SSN Salary Jim Gray John Smith dbo.Employees SSN Masked Data XXX-XX-XXXX SSN

#SQLSAT454 Dynamic Data Masking  Obfuscates data using 3 masking functions  Default:depends on data type  aXXX.XXXX.com  Partial:prefixXXXXXXsuffix  Data is stored unmasked  Masking happens on resultset formation  GRANT UNMASK to disclose data  Works in Azure SQL Database (preview)

#SQLSAT454 Dynamic Data Masking - Limitations  Not all datatypes supported  Not intended as a complete protection feature for sensitive data  Ad-Hoc queries disclose data. Ex: WHERE Salary > 2000  INSERT…SELECT does not preserve masking  Some quirks  Not suitable for handing out copies of the database to software vendors or third-parties

#SQLSAT454 DEMO Working with Dynamic Data Masking

#SQLSAT454 Q&A Questions?

#SQLSAT454 ROW-LEVEL SECURITY

#SQLSAT454 Row Level Security – Key Features Fine-grained access control In multi-tenant databases, limits access by other users who share the same tables. Centralized Security Logic Predicate-based access control logic resides inside the database and is schema-bound to the tables it protects. Application Transparency No application changes. Existing queries keep working.

#SQLSAT454 Row-Level Security LATAM Salesperson EMEA Salesperson Evil Inc. Name EMEA Area Budget Wealthy Corp.LATAM2.350 Greedy Corp.APAC1.500 dbo.Customer Manager APAC Salesperson

#SQLSAT454 Row-Level Security - Concepts  Predicate function User-defined inline iTVF implementing access control logic. Can be arbitrarily complicated  Security predicate Applies a predicate function to a particular table (APPLY) Two types: filter predicates and blocking predicates  Security policy Collection of security predicates Manages security across multiple tables

#SQLSAT454 Row-Level Security – How it works EMEA Salesperson Evil Inc. Name EMEA Area Budget Wealthy Corp.LATAM2.350 Greedy Corp.APAC1.500 dbo.Customer DBA Security Policy SELECT * FROM Customer SELECT * FROM Customer APPLY itvf_securityPredicate()

#SQLSAT454 DEMO Working with Row-Level Security

#SQLSAT454 Row-Level Security - Limitations  SCHEMABINDING: all tables in the predicate function must reside in the database  Performance impact: queries are rewritten  When authenticating the application, CONTEXT_INFO() can be used to filter on real user  Not really secure if users can run ad-hoc queries  Don’t lock out the DBA!

#SQLSAT454 Q&A Questions?

#SQLSAT454 Resources Always Encrypted on MSDN Getting Started With Always Encrypted Performance impact of Always Encrypted Dynamic Data Masking on MSDN Using Dynamic Data Masking Row-Level Security on MSDN Introduction to Row-Level Security Row-Level Security Limitations

#SQLSAT454 Evaluations  Don’t forget to compile evaluations form here 

#SQLSAT454 THANKS! #sqlsat454