SQL Server 2016 Security Features Marek Chmel Microsoft MVP: Data Platform Microsoft MCT: Regional Lead MCSE: Data Platform Certified Ethical Hacker

Sponsors

Session Agenda  Dynamic Data Masking  Row Level Security  Always Encrypted  Transparent Data Encryption  Threat Detection  Other Security Enhancements

Dynamic Data Masking

Masking with Minimal Impact on Applications  No need to modify existing application queries  Complimentary to other data protection features

Dynamic Data Masking Walkthrough ALTER TABLE [Employee] ALTER COLUMN [SocialSecurityNumber] ADD MASKED WITH (FUNCTION = ‘SSN()’) ALTER TABLE [Employee] ALTER COLUMN [ ] ADD MASKED WITH (FUNCTION = ‘ ()’) ALTER TABLE [Employee] ALTER COLUMN [Salary] ADD MASKED WITH (FUNCTION = ‘RANDOM(1,20000)’) GRANT UNMASK to admin1 SELECT [Name], [SocialSecurityNumber], [ ], [Salary] FROM [Employee] Non -Privileged User Privileged User

Masking types DefaultFull masking according to the data types of the designated field: i.e. String will result in “XXXX” Masking will expose the first letter of an address and will end in “.com” i.e. Custom StringWill expose the first and last letter and adds a custom padding string in the middle. i.e KXXXa RandomFor use only on numeric. Will replace the original value within a specified range.

DEMO Dynamic Data Masking

The need for row-level security Fine-grained access control over specific rows in a database table Help prevent unauthorized access when multiple users share the same tables, or to implement connection filtering in multitenant applications Administer via SQL Server Management Studio or SQL Server Data Tools Enforcement logic inside the database and schema is bound to the table

Benefits of Row-Level Security Store data intended for many consumers in a single database/table while at the same time restricting row-level read and write access based on users’ execution context.

RLS Concepts CREATE SECURITY POLICY mySecurityPolicy ADD FILTER PREDICATE dbo.fn_securitypredicate(wing, startTime, endTime) ON dbo.patients Predicate function User-defined inline table-valued function (iTVF) implementing security logic Can be arbitrarily complicated, containing joins with other tables Security predicate Binds a predicate function to a particular table, applying it for all queries Two types: filter predicates and blocking predicates (coming soon) Security policy Collection of security predicates for managing security across multiple tables

RLS Example Fine-grained access control over rows in a table based on one or more pre-defined filtering criteria, such as user’s role or clearance level in organization  Concepts:  Predicate function  Security policy CREATE FUNCTION int) RETURNS TABLE WITH SCHEMABINDING AS return SELECT 1 as [fn_securitypredicate_result] FROM StaffDuties d INNER JOIN Employees e ON (d.EmpId = e.EmpId) WHERE e.UserSID = SUSER_SID() = d.Wing; CREATE SECURITY POLICY dbo.SecPol ADD FILTER PREDICATE dbo.fn_securitypredicate(Wing) ON Patients WITH (STATE = ON)

Common RLS use cases Traditional RLS workloads Custom business logic to determine which rows each user can SELECT, INSERT, UPDATE, and DELETE based on their role, department, and security level Target sectors: Finance, insurance, healthcare, energy, and government Multitenant 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 For example: multitenant shards with elastic database tools in SQL Database Reporting, analytics, and data warehousing Different users access same database through various reporting tools, and work with different subsets of data based on their identity/role

DEMO Row Level Security

The need for Always Encrypted Allows customers to securely store sensitive data outside of their trust boundary. Data remains protected from high-privileged, yet unauthorized users.

How it works Help protect data at rest and in motion, on-premises and in the cloud

Types of encryption for Always Encrypted Two types of encryption available Randomized encryption uses a method that encrypts data in a less predictable manner Deterministic encryption uses a method which always generates the same encrypted value for any given plaintext value Randomized encryption Encrypt(' ') = 0x17cfd50a Repeat: Encrypt(' ') = 0x9b1fcf32 Allows for transparent retrieval of encrypted data but NO operations More secure Deterministic encryption Encrypt(' ') = 0x85a55d3f Repeat: Encrypt(' ') = 0x85a55d3f Allows for transparent retrieval of encrypted data AND equality comparison E.g. in WHERE clauses and joins, distinct, group by

Key provisioning

DEMO Always Encrypted

Support for Transparent Data Encryption  In SQL Server 2016, the storage for memory-optimized tables will be encrypted as part of enabling TDE on the database  Simply follow the same steps as you would for a disk-based database

Considerations for TDE  Key management  Backup  History  Always On  You will need the same encryption key across all db’s in the group  TempDB  The TempDB will be encrypted if any database on the instance is encrypted.

DEMO Transparent Data Encryption

Database Threat Protection  New feature on Azure SQL Database  Works together with auditing  Analyzes audit logs for possible threats  Notifies reactively if it finds an anomaly  Works with any tier of Azure SQL DB  Requires a storage account for audit logs

Evaluation forms  Session evaluation forms  Event evaluation forms