Presentation is loading. Please wait.

Presentation is loading. Please wait.

SQLintersection Session: Tuesday, 12:00-1:00pm NEW SECURITY FEATURES IN SQL SERVER 2016 & AZURE SQL DB Aaron Bertrand

Similar presentations


Presentation on theme: "SQLintersection Session: Tuesday, 12:00-1:00pm NEW SECURITY FEATURES IN SQL SERVER 2016 & AZURE SQL DB Aaron Bertrand"— Presentation transcript:

1 SQLintersection Session: Tuesday, 12:00-1:00pm NEW SECURITY FEATURES IN SQL SERVER 2016 & AZURE SQL DB Aaron Bertrand abertrand@sqlsentry.com

2 © SQLintersection. All rights reserved. http://www.SQLintersection.com Speaker: Aaron Bertrand  Product Evangelist at SQL SentrySQL Sentry  Editor of blogs blogs.sqlsentry.com and sqlperformance.comblogs.sqlsentry.comsqlperformance.com  Community moderator at dba.stackexchange.comdba.stackexchange.com  Microsoft MVP since 1997  Twitter: @AaronBertrand@AaronBertrand

3 © SQLintersection. All rights reserved. http://www.SQLintersection.com Reminder: Intersect with Speakers and Attendees  Tweet tips and tricks that you learn and follow tweets posted by your peers!  Follow: #SQLintersection and/or #DEVintersection  Join us – Wednesday Evening – for SQLafterDark  Doors open at 7:30 pm  Trivia game starts at 8:00 pm Winning team receives a copy of SQL Sentry’s Plan Explorer Pro!  Raffle at the end of the night Lots of great items to win!  The first round of drinks is sponsored by SQL Sentry and SQLskills &

4 © SQLintersection. All rights reserved. http://www.SQLintersection.com Overview  Introduction  Main security vulnerabilities  Current Defenses  New security features in SQL Server 2016 / Azure SQL DB

5 © SQLintersection. All rights reserved. http://www.SQLintersection.com Main security vulnerabilities  “Man in the middle” for data in transit  Accidental disclosure (“leakage”)  including multi-tenant  Physical access to data files / backups  Internal malice / security circumvention  SQL injection

6 © SQLintersection. All rights reserved. http://www.SQLintersection.com Current Defenses  Encrypted connection (TLS / IPSec) – in transit only  Transparent data encryption (TDE) – at rest only  Column-Level Encryption – at rest only  Backup encryption – at rest only  Secure data center – physical only  Hope and a prayer – ask Home Depot or Target how that works

7 © SQLintersection. All rights reserved. http://www.SQLintersection.com Transparent Data Encryption Limitations  Enterprise Edition only  Only protects data at rest  Whole database only  Backup compression can take longer and be counter-productive  tempdb also inherits encryption – stays even after disabling TDE  Data always accessible to sysadmin

8 © SQLintersection. All rights reserved. http://www.SQLintersection.com Column-Level Encryption Limitations  All encryption / decryption happens inside SQL Server  Only protects data at rest  Need to change T-SQL code to encrypt/decrypt  Data always accessible to sysadmin

9 © SQLintersection. All rights reserved. http://www.SQLintersection.com SQL Server 2016 / Azure SQL DB adds…  Dynamic Data Masking  Row-Level Security  Always Encrypted  Azure Active Directory Authentication  Auditing  Threat Detection

10 © SQLintersection. All rights reserved. http://www.SQLintersection.com Dynamic Data Masking  Obfuscate sensitive data for non-privileged users  “Hide certain column data from otherwise valid users.”  Provide “sanitized” access to developers / QA / support  What are the last 4 digits of your social security number?  Who can see unmasked data?  sysadmin, db_owner, and those granted with UNMASK  Can’t be used to thwart people with direct query access  Can run exhaustive queries to learn about the data

11 © SQLintersection. All rights reserved. http://www.SQLintersection.com Mask Types  Default  For strings, return XXXX (or fewer Xs)  For numbers, return 0  For dates, return 2000-01-01 at midnight  For binary, return single byte (ASCII 0)  Email Returns first character, then XXX@XXXX.com  Partial Allows you to specify prefix/pattern/suffix  Random For numbers only, specify a range

12 © SQLintersection. All rights reserved. http://www.SQLintersection.com Dynamic Data Masking Limitations  UNMASK is at the database level only  Can’t enforce masking on one table and allow unmasking on another  Cannot mask encrypted, sparse, FILESTREAM, computed, full-text keys Information Leakage Is Possible

13 © SQLintersection. All rights reserved. http://www.SQLintersection.com Dynamic Data Masking Demo

14 © SQLintersection. All rights reserved. http://www.SQLintersection.com Row-Level Security  Restrict access to rows based on identity, roles, tenant, or other context  “Hide specific rows from otherwise valid users.”  Can use USER_NAME(), SESSION_CONTEXT(), IS_ROLEMEMBER(), etc.  SESSION_CONTEXT() can be set as read-only during login  Unlike CONTEXT_INFO, which is vulnerable to malice  Inline TVF determines access based on rules  Filter predicate silently restricts output to valid rows  Block predicate raises exception when attempting to update restricted row  AFTER INSERT, AFTER UPDATE, BEFORE UPDATE, BEFORE DELETE

15 © SQLintersection. All rights reserved. http://www.SQLintersection.com Row-Level Security Limitations  WITH SCHEMABINDING is default behavior and highly recommended  If you bypass this, anyone with ALTER FUNCTION can change predicates  Block predicates not supported on partitioned views  Not supported: Filestream, indexed views Information Leakage Is Possible

16 © SQLintersection. All rights reserved. http://www.SQLintersection.com Row-Level Security Demo

17 © SQLintersection. All rights reserved. http://www.SQLintersection.com Always Encrypted  Protect data at rest, in memory, and in motion  “Allow only specific users to see certain data in any scenario.”  Use certificates to separate encryption security from DBA/sysadmin  Secure keys in:  Windows Certificate Store, Azure Key Vault, hardware security module (HSM)  Data can only be decrypted where you want it to be

18 © SQLintersection. All rights reserved. http://www.SQLintersection.com Always Encrypted Limitations  Predicate limitations:  Random encryption does not support indexes or predicates at all  Deterministic encryption only supports point lookups (equality)  Also only binary2 collations are supported for strings  Joins against temp tables/table variables on those cols fail  Applications must use strong parameters  Key rotation is cumbersome  Working in SSMS can be a pain

19 © SQLintersection. All rights reserved. http://www.SQLintersection.com Always Encrypted Limitations  Unsupported:  xml, rowversion, image/text/ntext, sql_variant, hierarchyid, filestream, rowguidcol, geography/geometry, alias/user-defined types  Identity columns, masked columns, computed columns, sparse, full-text  Replication, Change data capture, columns with statistics  PK columns on tables with Change Tracking  Temporal tables, Stretch tables, Polybase  Triggers yield Msg 206 if you reference encrypted columns (even with *)  Many limitations around indexes/constraints

20 © SQLintersection. All rights reserved. http://www.SQLintersection.com Always Encrypted

21 © SQLintersection. All rights reserved. http://www.SQLintersection.com Always Encrypted vs. Other Encryption Techniques 1 2 1 : Only with deterministic 2 : Not if you usually load data from SQL scripts

22 © SQLintersection. All rights reserved. http://www.SQLintersection.com Always Encrypted Demo

23 © SQLintersection. All rights reserved. http://www.SQLintersection.com My Recommendation for On-Premises  Use Always Encrypted for any sensitive data  Use Dynamic Data Masking to prevent casual access to columns  Be careful with table-level permissions  Separate data by database if you have different masking requirements  Use Row-Level Security to prevent access to rows  Use WITH SCHEMABINDING and put RLS objects in their own schema  For extra protection, combine these  Can’t mask encrypted column but can mask some, encrypt others, add RLS  Combine that with TLS and/or IPSec for encrypted connections  To further thwart man-in-the-middle attempts

24 © SQLintersection. All rights reserved. http://www.SQLintersection.com Azure SQL Database  Azure Active Directory Authentication  Auditing allows you to observe behavior patterns over time  Threat detection reports anomalies in behavior  e.g. SQL injection, atypical usage

25 © SQLintersection. All rights reserved. http://www.SQLintersection.com

26 Don’t forget to complete an online evaluation on EventBoard! New Security Features in SQL Server 2016 & Azure SQL DB Your evaluation helps organizers build better conferences and helps speakers improve their sessions. Questions? Thank you!

27 Save the Date 24-28 October 2016 We’re back in Vegas baby! www.SQLintersection.com


Download ppt "SQLintersection Session: Tuesday, 12:00-1:00pm NEW SECURITY FEATURES IN SQL SERVER 2016 & AZURE SQL DB Aaron Bertrand"

Similar presentations


Ads by Google