Presentation is loading. Please wait.

Presentation is loading. Please wait.

SQL Server 2016 Security and Privacy Features

Similar presentations


Presentation on theme: "SQL Server 2016 Security and Privacy Features"— Presentation transcript:

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


Download ppt "SQL Server 2016 Security and Privacy Features"

Similar presentations


Ads by Google