SQL Server 2016 New Security Features

1. #SQLSAT454
SQL Server 2016 New Security
Features
Gianluca Sartori
@spaghettidba

2. #SQLSAT454
Sponsors

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

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

5. #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

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

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

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

9. #SQLSAT454
ALWAYS ENCRYPTED

10. #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.

11. #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

12. #SQLSAT454
Always Encrypted – How it works
App
SELECT Name FROM
Patients WHERE SSN=@SSN
@SSN='198-33-0987'
Column
Encryption
Key
Jane Doe
Name
1x7fg655se2
e
SSN
USA
Country
Jim Gray 0x7ff654ae6d USA
John Smith 0y8fj754ea2c USA
dbo.Patients
Result Set
Jim Gray
Name
Query
Application - Trusted SQL Server - Untrusted
SELECT Name FROM
Patients WHERE SSN=@SSN
@SSN=0x7ff654ae6d
Enhanced
ADO.NET
Library
SQL Server
Native Client
.NET 4.6
Column
Master
Key

13. #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

14. #SQLSAT454
DEMO
Working with Always Encrypted

15. #SQLSAT454
TDE vs Always Encrypted
Always Encrypted TDE
Column level Database level
Client encryption Server encryption
Server doesn’t know
encryption keys
Server knows encryption
keys
Data in memory is encrypted Data in memory is in
plaintext
Data travels the network
encrypted
Data travels the network in
plaintext

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

17. #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

18. #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 = @param;

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

20. #SQLSAT454
Performance Impact

21. #SQLSAT454
Space Usage Impact

22. #SQLSAT454
Q&A
Questions?

23. #SQLSAT454
DYNAMIC DATA MASKING

24. #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.

25. #SQLSAT454
Dynamic Data Masking
Database
Non-Privileged
User
Privileged User
Unmasked Data
DATA
Jane Doe
Name
062-56-4651
SSN
2.500
Salary
Jim Gray 915-12-9845 2.350
John Smith 354-21-9184 1.500
dbo.Employees
062-56-4651
SSN
Masked Data
XXX-XX-XXXX
SSN

26. #SQLSAT454
Dynamic Data Masking
 Obfuscates data using 3 masking functions
 Default: depends on data type
 Email: 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)

27. #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

28. #SQLSAT454
DEMO
Working with Dynamic Data Masking

29. #SQLSAT454
Q&A
Questions?

30. #SQLSAT454
ROW-LEVEL SECURITY

31. #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.

32. #SQLSAT454
Row-Level Security
LATAM
Salesperson
EMEA
Salesperson
Evil Inc.
Name
EMEA
Area
2.500
Budget
Wealthy Corp. LATAM 2.350
Greedy Corp. APAC 1.500
dbo.Customer
Manager
APAC
Salesperson

33. #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

34. #SQLSAT454
Row-Level Security – How it works
EMEA
Salesperson
Evil Inc.
Name
EMEA
Area
2.500
Budget
Wealthy Corp. LATAM 2.350
Greedy Corp. APAC 1.500
dbo.Customer
DBA
Security Policy
SELECT *
FROM Customer
SELECT *
FROM Customer
APPLY itvf_securityPredicate()

35. #SQLSAT454
DEMO
Working with Row-Level Security

36. #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!

37. #SQLSAT454
Q&A
Questions?

38. #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

39. #SQLSAT454
Evaluations
 Don’t forget to compile evaluations form here
 http://speakerscore.com/sqlsat454

40. #SQLSAT454
THANKS!
#sqlsat454