SQL Server 2016 Row-level security & Dynamic Data Masking. Goran Milanov MVP, MCP, MCSA, MCT, PSM-I

Transcription

1

2 SQL Server 2016 Row-level security & Dynamic Data Masking Goran Milanov MVP, MCP, MCSA, MCT, PSM-I

3 SQL Server UG unesite u pretraživač: linkedin sql server ug belgrade

4 PASS SQL Saturday #475 Belgrade 2015 Po prvi put u Srbiji, jednodnevni događaj namenjen SQL Server profesionalcima i entuzijastima. U subotu, ugostićemo 16 vrhunskih stručnjaka i predavača iz Srbije i inostranstva. Pridružite nam se, proširite svoja znanja, razmenite iskustva sa predavačima i učesnicima. Prisustvo događaju je besplatno uz obaveznu registraciju. Otvorite svoj PASS nalog i registrujte se za događaj na: Dobrodošli!

5 Row-level security

6 Row-level security Row-Level Security (RLS) restricts which users can view what data in a table. SQL Server 2016 introduces this feature, which is very useful in multi-tenant environments where you may want to limit data access based on customer ID.

7 Customer Benefit Fine-grained Access Control Keeping multi-tenant databases secure by limiting access by other users who share the same tables. Application Transparency RLS works transparently at query time, no app changes needed. Compatible with RLS in other leading products. Centralized Security Logic Enforcement logic resides inside database and is schema-bound to the table it protects providing greater security. Reduced application maintenance and complexity. Store data intended for many consumers in a single database/table while at the same time restricting row-level read & write access based on users execution context.

8 Common RLS use cases Traditional RLS workloads Custom business logic to determine which rows each user can SELECT, INSERT, UPDATE, DELETE based on their role, department, security level, etc. Target sectors: Finance, insurance, healthcare, oil/gas, government institutions, etc. Multi-tenant databases Ensuring tenants can only access their own rows of data in a shared database, with enforcement logic in the database rather than in the app tier E.g. multi-tenant shards with elastic database tools on Azure SQL Database Reporting, analytics, data warehousing Different users access same database through various reporting tools, and work with different subsets of data based on their identity/role

9 RLS Concepts Performance? Inline functions get optimized to provide comparable performance to views as if the logic were directly embedded in the original query statement. Predicate function User-defined inline table-valued function implementing security logic Can be arbitrarily complicated, e.g. containing joins with other tables Reusable! Security predicate Binds a predicate function to a particular table, applying it for all queries Two types: Filter predicates silently filter rows available to read operations (SELECT, UPDATE, DELETE) Block predicates explicitly block write operations (AFTER INSERT, AFTER UPDATE, BEFORE UPDATE, BEFORE DELETE) that violate check new values Security policy Collection of security predicates for managing security across multiple tables check existing values CREATE SECURITY POLICY mysecuritypolicy ADD FILTER PREDICATE dbo.fn_securitypredicate(wing, starttime, endtime) ON dbo.orders

10 Row-level security User Security Policy Orders Filter predicate: INNER JOIN... Policy manager Application

11 RLS functionality Today I CAN create security predicates to filter read operations I CAN create security predicates to block write operations (incl. separate logic for each operation) I CAN create/alter/drop and enable/disable security policies I CAN be sure that a policy s behavior will not change, due to schema binding & permission checks I CAN audit changes to security policies I CAN create a policy manager persona who can manage security policies but not see any of the data stored in the database tables (separation of roles) I CAN use RLS on my memory-optimized tables Remarks One active predicate per operation on a table E.g. cannot have multiple filter predicates on same table (solution: combine logic into a single function) Programmability feature to help code more secure applications Not intended to protect against information leakage through potential side-channel attacks if users can execute arbitrary T-SQL

12 Demo RLS

13 Dynamic Data Masking

14 Dynamic Data Masking Dynamic Data Masking: Real-time obfuscation of data to prevent unauthorized access Regulatory Compliance Sensitive Data Protection

15 Dynamic Data Masking

16 Dynamic Data Masking Three types of masks are available: 1 The Default mask returns 'XXXX', 0, or ' ' depending on the data type. 2 The mask returns 'axx@xxxx.com' where a is the first letter in the address and com is the top-level domain name. 3 The Partial mask return the first N characters, a constant expression such as 'XXX-XX-XX' and the last M characters.

17 Demo Dynamic Data Masking

18 DDM Permissions You do not need any special permission to create a table with a dynamic data mask, only the standard CREATE TABLE and ALTER on schema permissions. Adding, replacing, or removing the mask of a column, requires the ALTER ANY MASK permission and ALTER permission on the table. It is appropriate to grant ALTER ANY MASK to a security officer. Users with SELECT permission on a table can view the table data. Columns that are defined as masked, will display the masked data. Grant the UNMASK permission to a user to enable them to retrieve unmasked data from the columns for which masking is defined. The CONTROL permission on the database includes both the ALTER ANY MASK and UNMASK permission.

19 DDM Limitations A masking rule cannot be defined for the following column types: Computed columns (whether persisted or not) Encrypted columns (Always Encrypted) Generated always (temporal) FILESTREAM COLUMN_SET (XML, Sparse)

20 Questions?

21