SQL Server 2016 Row-level security

& Dynamic Data Masking

Goran Milanov

MVP, MCP, MCSA, MCT, PSM-I

gmilanov@live.com

www.goranmilanov.rs

SQL Server UG

http://sqlserverugbg.azurewebsites.net/

https://www.linkedin.com/grp/home?gid=4846324

unesite u pretraživač: linkedin sql server ug belgrade

PASS SQL Saturday #475 – Belgrade 2015

Po prvi put u Srbiji, jednodnevni događaj namenjen

SQL Server profesionalcima i entuzijastima.

U subotu, 28.11.2015. 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:

http://www.sqlsaturday.com/475/eventhome.aspx

Dobrodošli!

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.

Row-level security

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.

Customer Benefit

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

Common RLS use cases…

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

Security policy

• Collection of security predicates for managing security across multiple tables

CREATE SECURITY POLICY mySecurityPolicyADD FILTER PREDICATE dbo.fn_securitypredicate(wing, startTime, endTime) ON dbo.Orders

Performance?

Inline functions get optimized to provide comparable

performance to views… as if the logic were directly

embedded in the original query statement.

check new values check existing values

RLS Concepts

Filter predicate:INNER JOIN ...

Row-level security

Orders

Policy manager

User

Application

SecurityPolicy

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

RLS functionality

Demo RLS

Dynamic Data Masking

Regulatory Compliance

Sensitive Data Protection

Dynamic Data Masking

Dynamic Data Masking: Real-time obfuscation of data to prevent unauthorized access

Dynamic Data Masking

The Default mask returns 'XXXX', 0, or '01.01.2000 …' depending on the data type.1

The Email mask returns 'aXX@XXXX.com' where “a” is the first letter in the email address and “com” is the top-level domain name.

2

The Partial mask return the first N characters, a constant expression such as 'XXX-XX-XX' and the last M characters.

3

Dynamic Data Masking

Three types of masks are available:

Demo Dynamic Data Masking

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 MASKpermission 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.

DDM Limitations

• Computed columns (whether persisted or not)• Encrypted columns (Always Encrypted)• Generated always (temporal)• FILESTREAM• COLUMN_SET (XML, Sparse)

A masking rule cannot be defined for the following column types:

Questions?