1. SQL Server 2016 Security and Privacy Features
9/10/2018
SQL Server 2016 Security and Privacy Features
Thomas LaRock
Head GeekTM

2. WHY ARE YOU HERE?
You are responsible for data security and privacy

3. WHY ARE YOU HERE? You are responsible for data security and privacy
You want to know more about features in SQL Server 2016

4. WHY ARE YOU HERE? You are responsible for data security and privacy
You want to know more about features in SQL Server 2016
You don’t like jail

5. A LITTLE ABOUT ME
Thomas has over 15 years experience in roles including programmer, developer, analyst, and DBA.
He enjoys working with data, probably too much to be healthy, really.

6. solarwinds.com/products
ABOUT SOLARWINDS
solarwinds.com/products

7. Brief History of SQL Server Security
AGENDA 1
Brief History of SQL Server Security 2
AlwaysEncrypted 3
Dynamic Data Masking 4
Row Level Security 5
Questions

8. Brief History of SQL Server Security
AGENDA 1
Brief History of SQL Server Security 2
AlwaysEncrypted 3
Dynamic Data Masking 4
Row Level Security 5
Questions

9. Brief History of SQL Server Security
AGENDA 1
Brief History of SQL Server Security 2
AlwaysEncrypted 3
Dynamic Data Masking 4
Row Level Security 5
Questions

10. Brief History of SQL Server Security
AGENDA 1
Brief History of SQL Server Security 2
AlwaysEncrypted 3
Dynamic Data Masking 4
Row Level Security 5
Questions

11. Brief History ofr SQL Server Security
AGENDA 1
Brief History ofr SQL Server Security 2
AlwaysEncrypted 3
Dynamic Data Masking 4
Row Level Security 5
Questions

12. A BRIEF HISTORY OF SQL SERVER SECURITY
3rd party (BitLocker, et al)

13. A BRIEF HISTORY OF SQL SERVER SECURITY
3rd party (BitLocker, et al)
Cell level encryption

14. A BRIEF HISTORY OF SQL SERVER SECURITY
3rd party (BitLocker, et al)
Cell level encryption
Transparent Data Encryption

15. A BRIEF HISTORY OF SQL SERVER SECURITY
3rd party (BitLocker, et al)
Cell level encryption
Transparent Data Encryption
AlwaysEncrypted
Dynamic Data Masking*
Row Level Security*
New!

16. TRANSPARENT DATA ENCRYPTION
9/10/2018
TRANSPARENT DATA ENCRYPTION
Protects data “at rest”
Performs real-time I/O encryption (and decryption) of both data and log files at the page level
Pages encrypted before written to disk, decrypted when read into memory
TDE does not increase the size of the encrypted database
Backup compression allowed, but futile
Replication requires TDE on distribution and subscriber databases
Tempdb encrypted
Does not encrypt data in flight
If database used for mirroring or log-shipping both databases will be encrypted as will the log trxs sent
Uses database encryption key (DEK); stored in database boot record
DEK secured using certificate in master –OR- by an asymmetric key protected by EKM
If the certificate ever becomes unavailable or if you must restore or attach the database on another server, you must have backups of both the certificate and the private key or you will not be able to open the database.
Even though the database is not encrypted, parts of the transaction log may still remain protected, and the certificate may be needed for some operations until the full backup of the database is performed.
Files related to buffer pool extension (BPE) are not encrypted when database is encrypted using TDE. You must use file system level encryption tools like Bitlocker or EFS for BPE related files.

17. AlwaysEncrypted Enabled at column level
Protects data at rest *AND* in memory
Uses Column Master Key (client) and Column Encryption Key (server)

18. AlwaysEncrypted

19. AlwaysEncrypted

20. Deterministic – good for static values; can be indexed
AlwaysEncrypted
SQL Server 2016 Fav Things
June 2016
Deterministic – good for static values; can be indexed
ALLOWED:
Equality JOINs,
Grouping
Indexing
Point lookups
Randomized – better security; cannot be indexed
NOT ALLOWED:
JOINs,
Filtering
Uses functions; deterministic and randomized
D - good for values that don't change (like names) and you know you will want to index
Equality predicates only
Using deterministic encryption allows grouping, filtering by equality, and joining tables based on encrypted values, but can also allow unauthorized users to guess information about encrypted values by examining patterns in the encrypted column.
R - good for things you want/need more secure and you know you don't need indexed
Not supported in WHERE clause at all
Cannot create index on column
Randomized encryption is more secure, but prevents equality searches, grouping, indexing, and joining on encrypted columns.
MUST use *_BIN2 collation (Latin1_General_BIN2)
©InfoAdvisors - All rights reserved

21. AlwaysEncrypted text/ntext/image XML/hierarchyid/geography/geometry
SQL Server 2016 Fav Things
June 2016
AlwaysEncrypted
text/ntext/image
XML/hierarchyid/geography/geometry
alias types/user-defined data types
SQL_VARIANT
rowversion (timestamp)
System alias (SYSNAME)
Computed columns
Identity columns
Sparse column sets
Temporal tables
Triggers (partial support)
Full text search
Replication
CDC
In Memory OLTP
Stretch database
Items not supported
©InfoAdvisors - All rights reserved

22. Foreign keys must match encryption types
SQL Server 2016 Fav Things
June 2016
AlwaysEncrypted
Foreign keys must match encryption types
Client code needs to support AE (currently this means .NET 4.6)
©InfoAdvisors - All rights reserved

23. AlwaysEncrypted

24. AlwaysEncrypted

25. AlwaysEncrypted Why you will love it AlwaysEncrypted, yeah
Allows designers to not only specify which columns need to be protected, but how
Parameters are encrypted as well
Built in to the engine, easier for devs
Why you will love it

26. DYNAMIC DATA MASKING Done at column level (NOT ENCRYPTION!)
SQL Server 2016 Fav Things
June 2016
DYNAMIC DATA MASKING
Done at column level (NOT ENCRYPTION!)
Data in the database, at rest, has no protection.
Meant to complement other methods
Performed at the end of a database query right before data returned
Performance impact small
Data in the database is not changed
(it's just a system function call? Performance impact?)
ad hoc queries should not be allowed if you want to protect the masked data (need to test)
Masked data can be completely viewable when querying from a temp table
Masking can be ‘unmasked’ by using a CAST statement in an ad hoc query
©InfoAdvisors - All rights reserved

27. DYNAMIC DATA MASKING CREATE TABLE Membership(
SQL Server 2016 Fav Things
June 2016
DYNAMIC DATA MASKING
CREATE TABLE Membership(
MemberID int IDENTITY PRIMARY KEY,    
FirstName varchar(100) MASKED WITH (FUNCTION = 'partial(1,"XXXXXXX",0)') NULL,    
LastName varchar(100) NOT NULL,    
Phone# varchar(12) MASKED WITH (FUNCTION = 'default()') NULL,    
varchar(100) MASKED WITH (FUNCTION = ' ()') NULL);
INSERT Membership (FirstName, LastName, Phone#, ) VALUES
('Roberto', 'Tamburello', ' ',
('Janice', 'Galvin', ' ',
('Zheng', 'Mu', ' ',
©InfoAdvisors - All rights reserved

28. 4 functions available today Default Email Custom String Random
SQL Server 2016 Fav Things
June 2016
DYNAMIC DATA MASKING
4 functions available today
Default
Custom String
Random
The purpose of dynamic data masking is to limit exposure of sensitive data, preventing users who should not have access to the data from viewing it.
Dynamic data masking does not aim to prevent database users from connecting directly to the database and running exhaustive queries that expose pieces of the sensitive data.
©InfoAdvisors - All rights reserved

29. DYNAMIC DATA MASKING Function Mask Example Default
SQL Server 2016 Fav Things
June 2016
DYNAMIC DATA MASKING
Function
Mask
Example
Default
Based on Datatype String – XXX Numbers – Date & Times :00: Binary – Single Byte 0
xxxx
:00:
First character of , then Xs, then .com (always .com)
Custom
First and last values, with Xs in middle
kxxxn
Random
For numeric types, with a range 12
©InfoAdvisors - All rights reserved

30. DYNAMIC DATA MASKING Data in database is not changed
Ad-hoc queries *can* expose data
Does not aim to prevent users from exposing pieces of sensitive data

31. DYNAMIC DATA MASKING Cannot mask an encrypted column (AE)
SQL Server 2016 Fav Things
June 2016
DYNAMIC DATA MASKING
Cannot mask an encrypted column (AE)
Cannot be configured on computed column
But if computed column depends on a mask, then mask is returned
Using SELECT INTO or INSERT INTO results in masked data being inserted into target (also for import/export)
Dynamic Data Masking is applied when running SQL Server Import and Export. A database containing masked columns will result in a backup file with masked data (assuming it is exported by a user without UNMASK privileges), and the imported database will contain statically masked data.
Creating mask does not prevent updates
©InfoAdvisors - All rights reserved

32. DYNAMIC DATA MASKING Why you will love it
Allows central, reusable design for standard masking
Offers more reliable masking and more usable masking
Removes whining about “we can do that later”
Why you will love it

33. Filtering result sets (predicate based access)
SQL Server 2016 Fav Things
June 2016
ROW LEVEL SECURITY
Filtering result sets (predicate based access)
Predicates applied when reading data
Can be used to block write access
User defined policies tied to inline table functions
For filter predicates, 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.
For block predicates, any operations that violate the predicate will fail with an error.
If 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, the rows are filtered or blocked as defined by the security policy.
Attempts to alter the schema of a table bound by a schema bound security policy will result in an error. However, columns not referenced by the predicate can be altered.
It is highly recommended to create a separate schema for the RLS objects (predicate function and security policy).
The ALTER ANY SECURITY POLICY permission is intended for highly-privileged users (such as a security policy manager). The security policy manager does not require SELECT permission on the tables they protect.
Avoid type conversions in predicate functions to avoid potential runtime errors.
Avoid using excessive table joins (and recursion) in predicate functions to maximize performance.
Avoid predicate logic that depends on session-specific SET options
Limitations:
DBCC SHOW_STATISTICS not allowed
Filestream not allowed
Polybase not allowed
Indexed views
CDC
Change Tracking
©InfoAdvisors - All rights reserved

34. ROW LEVEL SECURITY No indication that results have been filtered
SQL Server 2016 Fav Things
June 2016
ROW LEVEL SECURITY
No indication that results have been filtered
If all rows are filtered than NULL set returned
For block predicates, an error returned
Works even if you are dbo or db_owner role
Attempts to alter the schema of a table bound by a schema bound security policy will result in an error. However, columns not referenced by the predicate can be altered.
It is highly recommended to create a separate schema for the RLS objects (predicate function and security policy).
The ALTER ANY SECURITY POLICY permission is intended for highly-privileged users (such as a security policy manager). The security policy manager does not require SELECT permission on the tables they protect.
Avoid type conversions in predicate functions to avoid potential runtime errors.
Avoid using excessive table joins (and recursion) in predicate functions to maximize performance.
Avoid predicate logic that depends on session-specific SET options
Limitations:
DBCC SHOW_STATISTICS not allowed
Filestream not allowed
Polybase not allowed
Indexed views
CDC
Change Tracking
©InfoAdvisors - All rights reserved

35. Avoid type conversions in predicate functions to avoid runtime errors
SQL Server 2016 Fav Things
June 2016
ROW LEVEL SECURITY
Recommended to create schema for RLS objects (predicate functions and security policies)
Use ALTER ANY SECURITY POLICY permissions; this does not require SELECT on the columns
Avoid type conversions in predicate functions to avoid runtime errors
ALTER SCHEMA fails (not for columns not in filter)
Avoid excessive table joins (and recursion) in predicate functions
Avoid using excessive table joins (and recursion) in predicate functions to maximize performance.
Avoid predicate logic that depends on session-specific SET options
Limitations:
DBCC SHOW_STATISTICS not allowed
Filestream not allowed
Polybase not allowed
Indexed views
CDC
Change Tracking
©InfoAdvisors - All rights reserved

36. CDC nor change tracking
SQL Server 2016 Fav Things
June 2016
ROW LEVEL SECURITY
Not Allowed
DBCC SHOW_STATISTICS
FILESTREAM
Polybase
Indexed views
CDC nor change tracking
Carefully crafted queries: It is possible to cause information leakage through the use of carefully crafted queries. For example, SELECT 1/(SALARY ) FROM PAYROLL WHERE NAME='John Doe' would let a malicious user know that John Doe's salary is $100,000. Even though there is a security predicate in place to prevent a malicious user from directly querying other people's salary, the user can determine when the query returns a divide-by-zero exception.
©InfoAdvisors - All rights reserved

37. ROW LEVEL SECURITY Why you will love it
Allows a designer to do this sort of data protection IN THE DATABASE, not just rely on code
Replaces many, many pieces of code
Why you will love it

38. Security - Summary Key differences TDE AE DDM RLS Encryption Y N
SQL Server 2016 Fav Things
June 2016
Security - Summary
Key differences
TDE AE
DDM
RLS
Encryption Y N
Protect data in memory
Overhead
Low*
High
Low
Block updates
Pros/cons of each choice (CBR model)
-indexing
-Transparency to users
-Effectiveness of encryption methods
-ref integrity
-performance
-P18 of Rob's book?
©InfoAdvisors - All rights reserved

39. Data quality? Data availability? Data recovery? Query performance?
ROW LEVEL SECURITY
Data quality?
Data availability?
Data recovery?
Query performance?
Legal requirements?
Which one is right for you?

40. Brief History or SQL Server Security
AGENDA 1
Brief History or SQL Server Security 2
AlwaysEncrypted 3
Dynamic Data Masking 4
Row Level Security 5
Questions

41. © 2016 SOLARWINDS WORLDWIDE, LLC. ALL RIGHTS RESERVED.
Thank You!
The SOLARWINDS and SOLARWINDS & Design marks are the exclusive property of SolarWinds Worldwide, LLC, are registered with the U.S. Patent and Trademark Office, and may be registered or pending registration in other countries.  All other SolarWinds trademarks, service marks, and logos may be common law marks, registered or pending registration in the United States or in other countries.  All other trademarks mentioned herein are used for identification purposes only and may be or are trademarks or registered trademarks of their respective companies.
© 2016 SOLARWINDS WORLDWIDE, LLC. ALL RIGHTS RESERVED.

42. FOR MORE INFORMATION http://tinyurl.com/msdn-TDE