1. Organizational Security & Compliance
Microsoft SQL Server
George Walters
Senior Partner Technical Strategist for ISV Partners
@gwalters69 on twitter

2. Why is security important?
Data Breaches Stolen data Ransomware Value to the business
eBay
December 10, 2017:  Due to a customer privacy leak, the personal information of many eBay customers, including usernames, first and last names, and purchase history, were made available via a Google’s Shopping platform.
The breach was due to “an improper feed signal” between the two companies. According to an eBay spokesperson, the companies are trying to find the root cause.  The purchase histories that were leaked revealed very sensitive products, such as HIV home test kits, pregnancy test, and drug testing kits. Within a couple days, the users real names were masked with dashes. This is just another example of one of the many ways that your personal information can become compromised, through no fault of your own.
Alteryx
December 19, 2017:  Alteryx, a California-based data analytics firm, was found culpable of not protecting the personal information of more than 120 million American households. The company had purchased this data from Experian, a giant credit reporting agency similar to Equifax. What we now know is that the exposed data was openly housed on an Amazon Web Services cloud storage bucket. All that anyone needed to access peoples’ private information was the URL, along with an Amazon AWS account. The impact of this breach is yet to be seen, but could very well be substantial based on the information that was available to potential cybercriminals. We will update this post as further details emerge.

3. Progress on SQL Engine security … A Journey through time
Redefined engineering security processes (2005) (Trustworthy Computing)
SQL Server no longer a windows admin! (2005)
Common Criteria certification at high assurance level (2005 Service Pack 2)
T-SQL Encrypt/Decrypt functions (2005)
Audit (2008)
Transparent data encryption (2008)
Encryption key management (2008)
Support for Windows Server core (2012)
Enhanced separation of duty (2014) (DBA unable to see data?)
Always Encrypted, Row Level Security, and more! (2016 EE, SP1 across editions)
.NET CLR options (2017)

4. Organizational Security & Compliance Help enable security & compliance with built-in security & IT controls
DATA PROTECTION
Powerful Encryption Technologies
Advanced Security Infrastructure
Data Protection Extends to Azure SQL Database
User-Defined Server Roles
Default Schema for Groups
Contained Database Authentication
Azure Active Directory
CONTROL ACCESS
OPTIONAL CASE STUDY
Great Western Bank
“As a subsidiary of National Australia Bank, we must meet the standards required of very large banks, such as the BASEL II accords,” says Van Zanten. “With SQL Server 2012, we can meet the reporting and data requirements asked of $500 billion banks, so we are well-positioned to grow to our goal of about $25 billion in assets.”
OPTIONAL PRODUCT DETAIL
Now let’s take a step back and look at security across the release. SQL Server helps ensure security through tools for data protection controlled access and enabled compliance.
Within data protection, SQL Server delivers encryption technology built on an advanced security infrastructure – this includes industry-recognized encryption technologies and advanced capabilities like transparent data encryption delivered in 2008.
Specifically, SQL Server 2012 delivers additional capabilities to further control access; and we’ll discuss these in more detail on the next slide. (If you don’t cover the next slide, pull the speaking notes forward)
And finally, SQL Server helps organizations ensure compliance through third-party certifications and verifications. SQL Server delivers necessary capabilities that allow customers to become compliant with internal and external compliance policies. Since SQL Server 2008, 3rd party firms have been able to verify and document best practices on how SQL Server can enable HIPPA and PCI compliance.
Additionally, release over release SQL Server pursues and achieves Common Criteria Certification EAL 4 which is required by US Govt software purchases and many international industries and agencies.
SQL Server Audit
Audit Resilience
User-Defined Audit
Audit Filtering
Third-Party Verified (Common Criteria)
Compliance in the Cloud
COMPLIANCE

5. Transparent Data Encryption
Data Protection Known for the lowest vulnerabilities across major DBMS vendors
Beginning with SQL Server 2016, all algorithms other than AES128, AES192, and AES256 are deprecated. To use older algorithms (not recommended) you must set the database to database compatibility level 120 or lower.
Powerful Encryption Technologies
ASE256 for backup keys
SHA512 for password hashes
Built On Advanced Security Infrastructure
Built-in cryptography hierarchy
Transparent data encryption
Extensible key management
Sign code modules
Data Protection in the Cloud
Encrypted connection on-premises and in Azure SQL database
Audit, TDE, Always Encrypted in Azure SQL database or Azure SQL Managed Instance
Client Application
SQL Server
Transparent Data Encryption
Encrypted Data Page
As end users continue to demand access to data, and as corporate and industry compliance policies tighten, the topic of security becomes paramount. The security of your environment is only as good as the product you’re using, and amongst the major database players we have the best track record. SQL Server consistently reports the lowest database vulnerabilities among the major RDBMs vendors. This means fewer inherent security vulnerabilities, less patching, and less downtime—all factors that affect Mission Critical Confidence.
SQL Server delivers powerful encryption technologies
Advanced Encryption Standard (AES) 256 is available for encryption with key length 256-bit.
Secure Hashing Algorithm (SHA) 512 is available for hashing with key length of 512-bit.
SQL Server is built on advanced security infrastructure:
Use the built-in cryptography hierarchy to create asymmetric keys, symmetric keys, and certificates.
You can perform all encryption transparently at the database level through a security-enhanced database encryption key (DEK). Then you can enable application developers to access encrypted data without changing existing applications.
You can use an Enterprise Key Management system to consolidate your enterprise encryption. Separate your data from the keys using Hardware Security Modules to store the keys in separate hardware.
Use a key or certificate to add a digital signature to code modules, such as stored procedures and functions. Then you can associate additional permissions to the signature for the duration of the code module execution.
Data protection in the cloud:
All communications between Windows Azure SQL Database database and your applications require SSL encryption at all times. You can use ADO.NET encryption when accessing your Windows Azure SQL Database database and Reporting Services from outside the cloud.

6. Transparent Database encryption

7. Transparent Database Encryption code
USE master; GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>'; Go
CREATE CERTIFICATE MyServerCert WITH SUBJECT = 'My DEK Certificate'; go
USE AdventureWorks2012;
-- RED ALERT: BACKUP THE CERTIFICATE !!!
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER CERTIFICATE MyServerCert;
ALTER DATABASE AdventureWorks2016
SET ENCRYPTION ON;

8. BUILT ON ADVANCED SECURITY INFRASTRUCTURE CONTROL ACCESS IN THE CLOUD
Control Access Provide access to information only for users who need it
User-Defined Server Roles: allow flexible database access for better separation of duties
Default Schema for Groups: allow database schema ties to Windows Group for better schema management
Contained Database Authentication: allow authentication into user database without logins for better application manageability
SharePoint ActiveDirectory: help secure end-user data analytics with built-in IT controls, including SharePoint & ActiveDirectory security models
Enforce enterprise-wide password policies & authentication
Roles and proxy accounts
Security enhanced metadata access
Execution context
BUILT ON ADVANCED SECURITY INFRASTRUCTURE
SQL Server authentication
Azure Active Directory
Server-side firewall
CONTROL ACCESS IN THE CLOUD
So let’s take a look at the detailed features SQL Server 2012 delivers to help customers further control access to their data. We do this in a number of incremental but important ways:
User-Defined Server Roles offer administrators more fine-grained access to what DBAs and other staff can and can’t see. Before, an admin with rights literally had rights to all the data. Now, with SQL Server 2012, organizations can control what Admins and DBAs can see across the system at a detailed level based on roles. This is especially important across government agencies where stringent access is required.
Default Schema for Groups is a customer delighter. This support allows you to more easily follow Microsoft security best practices. When you connect to SQL Server using Windows Groups, you can now define a default schema directly (it used to be grayed out) which means no workarounds or extra user accounts to manage or remove.
Contained Database Authentication is built on the Data-Tier Application Component delivered in R2, which packages up application schema. Contained Database Authentication increases compliance by allowing users to be authenticated directly into user databases without logins. User information for login (username and password) is not stored inside master database but user databases directly. This feature comes to life with AlwaysOn to facilitate better portability of user databases among servers in the case of server failover without the need to configure logins for all database servers in the cluster.
Additionally, as Microsoft continues to deliver broadly accessible BI tools, the security and access around that data is critical.
SQL Server 2012 supports tighter alignment with SharePoint and ActiveDirectory to ensure the right users are accessing the right data at the right time.

9. SUPPORTS INTERNAL/EXTERNAL POLICIES
Help Ensure Compliance Increase audit manageability across all SQL Server editions
SQL Server Audit for all editions helps enable standardization & better performance
Audit Resilience: recover audit from temporary file & network issues
User-Defined Audit: allow custom audit events for greater flexibility
Audit Filtering: filter unwanted audit events for greater flexibility
Automatic software updates
Policy-Based Management
SQL Server Audit infrastructure
Custom auditing with DDL triggers
BUILT-IN TOOLS
Common Criteria Certifications
Help enable PCI 2.0, HIPAA
Compliance with cloud:
No access or retention of customer data with Power BI Reporting and enterprise gateway
Microsoft Data Centers are ISO/IEC 27001:2005, SAS 70 Type I and II, PCI DSS & FISMA compliant
SUPPORTS INTERNAL/EXTERNAL POLICIES
Next, let’s talk about how SQL Server can help you better manage auditing and ensure compliance. Auditing an instance of SQL Server involves tracking and logging events that occur on the system. SQL Server Audit, which is now available for all SQL Server editions, provides built-in tools that enable you to define audits that automatically record activity in log files, the Windows Application log, or the Windows Security log. You can also create audit specifications to determine which server and database actions to include in the audit.
SQL Server Audit enables you to create custom auditing solutions using triggers to capture and audit data definition language (DDL) activities. You can also extend triggers to respond to DDL events as well as data manipulation language (DML) events and log DDL events, improving auditing and enhancing security.
Microsoft is committed independent third-party evaluation of our products and in using the Common Criteria as a proven and accepted process to ensure compliance with Common Evaluation Methodologies. SQL Server has completed an IT security evaluation at the Basic Assurance Level (EAL1+) and was certified by BSI (Bundesamt fur Sicherheit in der Informationtechnik, which is the Federal Office for Information Security in Germany).
SQL Server has also been audited for HIPAA and PCI Data Security Standard Compliance.
This same level of commitment to compliance applies to the cloud. Windows Azure SQL Reporting, along with Windows Azure, is designed to help the customer protect its data. Microsoft does not access or retain customer data except as required by accepted business practices to serve our customers, unless otherwise authorized by the customer. In addition, Microsoft Data Centers are certified by ISO/IEC 27001:2005, an internationally recognized specification of standards for information security. They also have SAS 70 Type I and II industry standards; PCI DSS credit card standards; and FISMA, a set of federal IT security standards.

10. Mission-critical performance
Security
Availability
Scalability
Operational analytics
Insights on operational data; Works with in-memory OLTP and disk-based OLTP
In-memory OLTP enhancements
Greater T-SQL surface area, terabytes of memory supported, and greater number of parallel CPUs
Query data store
Monitor and optimize query plans
Native JSON
Expanded support for JSON data
Temporal database support
Query data as points in time
Always encrypted
Sensitive data remains encrypted at all times with ability to query
Row-level security
Apply fine-grained access control to table rows
Dynamic data masking
Real-time obfuscation of data to prevent unauthorized access
Other enhancements
Audit success/failure of database operations
TDE support for storage of in- memory OLTP tables
Enhanced auditing for OLTP with ability to track history of record changes
Enhanced AlwaysOn
Three synchronous replicas for auto failover across domains
Round robin load balancing of replicas
Automatic failover based on database health
DTC for transactional integrity across database instances with AlwaysOn
Support for SSIS with AlwaysOn
Enhanced database caching
Cache data with automatic, multiple TempDB files per instance in multi- core environments

11. Always Encrypted SQL Server 2016+ Azure SQL Database
Azure SQL Managed Instance

12. Benefits of Always Encrypted
11/27/2018
Benefits of Always Encrypted
Prevents Data Disclosure
Client-side encryption of sensitive data using 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.
Allows customers to securely store sensitive data outside of their trust boundary.
Data remains protected from high-privileged, yet unauthorized users.
© 2015 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

13. Always Encrypted Help protect data at rest and in motion, on-premises & cloud
Trusted
Apps
SELECT Name FROM Patients WHERE
@SSN=' '
SQL Server
SELECT Name FROM Patients WHERE
@SSN=0x7ff654ae6d
Client side
Enhanced ADO.NET
Library
dbo.Patients
Jane Doe
Name
SSN
USA
Country
Jim Gray
John Smith
Query
Result Set
Jim Gray
Name
Jane Doe
1x7fg655se2e
SSN
USA
Country
0x7ff654ae6d
John Smith
0y8fj754ea2c
dbo.Patients
Column
Master Key
Column Encryption Key
Result Set
Jim Gray
Name
ciphertext
dbo.Patients
Jane Doe
Name
1x7fg655se2e
SSN
USA
Jim Gray
0x7ff654ae6d
John Smith
0y8fj754ea2c
Country
Source:
Always Encrypted is a feature designed to protect sensitive data, such as credit card numbers or national identification numbers (e.g. U.S. social security numbers), stored in SQL Server databases. Always Encrypted allows clients to encrypt sensitive data inside client applications and never reveal the encryption keys to SQL Server. As a result, Always Encrypted provides a separation between those who own the data (and can view it) and those who manage the data (but should have no access). By ensuring on-premises database administrators, cloud database operators, or other high-privileged, but unauthorized users, cannot access the encrypted data, Always Encrypted enables customers to confidently store sensitive data outside of their direct control. This allows organizations to encrypt data at rest and in use for storage in Azure, to enable delegation of on-premises database administration to third parties, or to reduce security clearance requirements for their own DBA staff.
Always Encrypted makes encryption transparent to applications. An Always Encrypted-enabled driver installed on the client computer achieves this by automatically encrypting and decrypting sensitive data in the SQL Server client application. The driver encrypts the data in sensitive columns before passing the data to SQL Server, and automatically rewrites queries so that the semantics to the application are preserved. Similarly, the driver transparently decrypts data, stored in encrypted database columns, contained in query results.

14. Types of Encryption for Always Encrypted
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
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 plain text value
Source:
Selecting Deterministic or Randomized Encryption
Always Encrypted supports two types of encryption: randomized encryption and deterministic encryption.
Deterministic encryption uses a method which always generates the same encrypted value for any given plain text value. Using deterministic encryption allows grouping, filtering by equality, and joining tables based on encrypted values, but can also allow unauthorized users to guess information about encrypted values by examining patterns in the encrypted column. This weakness is increased when there is a small set of possible encrypted values, such as True/False, or North/South/East/West region. Deterministic encryption must use a column collation with a binary2 sort order for character columns.
Randomized encryption uses a method that encrypts data in a less predictable manner. Randomized encryption is more secure, but prevents equality searches, grouping, indexing, and joining on encrypted columns.
Use deterministic encryption for columns that will be used as search or grouping parameters, for example a government ID number. Use randomized encryption, for data such as confidential investigation comments, which are not grouped with other records, or used to join tables, and which are lthe row which contains the encrypted column of interest.

15. Key Provisioning 1. Generate CEKs and Master Key 2. Encrypt CEK
Column Encryption Key
(CEK)
Column
Master Key
(CMK)
2. Encrypt CEK
Encrypted
CEK
CMK Store:
Certificate Store
HSM
Azure Key Vault …
CMK
3. Store Master Key Securely
Security
Officer
Source:
Creating and registering a custom Column Master Key Store Provider
Information the driver receives from SQL Server for query parameters which need to be encrypted, and for query results which need to be decrypted, includes:
An encrypted value of a column encryption key, which should be used to encrypt or decrypt a parameter or a result.
The name of a key store provider that encapsulates a key store containing the column master key which was used to encrypt the column encryption key.
A key path that specifies the location of the column master key in the key store.
The name of the algorithm that was used to encrypt the column encryption key.
The driver uses the above information to use the key store provider implementation to decrypt the retrieved encrypted value of the column encryption key, which is subsequently used to either encrypt a query parameter or to decrypt a query result.
The driver comes with an implementation for one system provider: SqlColumnEncryptionCertificateStoreProvider which can be used to store column master keys in Windows Certificate Store.
You can use a custom key store provider by extending the SqlColumnEncryptionKeyStoreProvider class and registering it using the SqlConnection.RegisterColumnEncryptionKeyStoreProviders() method.
4. Upload Encrypted CEK to DB
Encrypted CEK
Database

16. Example Client - Trusted CMK Store SQL Server - Untrusted
using (SqlCommand cmd = new SqlCommand(
"SELECT Name FROM Customers WHERE SSN
, conn)) {
cmd.Parameters.Add(new SqlParameter(
SqlDbType.VarChar, 11).Value =
" ");
SqlDataReader reader =
cmd.ExecuteReader();
Enhanced ADO.NET
exec sp_describe_parameter_encryption
@params = VARCHAR(11)'
= N'SELECT * FROM Customers WHERE SSN
Param
Encryption Type/ Algorithm
Encrypted CEK Value
CMK Store Provider Name
CMK Path
@SSN
DET/ AES 256
CERTIFICATE_STORE
Current User/ My/f2260…
Plaintext CEK
Cache
Encryption metadata
EXEC sp_execute_sql
N'SELECT * FROM Customers WHERE SSN =
Result set (plaintext)
Source:
Param
Encryption Type/ Algorithm
Encrypted CEK Value
CMK Store Provider Name
CMK Path
@Name
Non-DET/ AES 256
CERTIFICATE_STORE
Current User/ My/f2260…
Name
Jim Gray
Encryption metadata
Name
0x19ca706fbd9
Result set (ciphertext)

17. Setup (SSMS or SSDT) User Experience: SSMS or SSDT (Visual Studio)
Select columns to be encrypted
Analyze schema and application queries to detect conflicts (build time)
Set up the keys: master & CEK
Static schema analysis tool (SSDT only)
UI for selecting columns (no automated data classification)
Key setup tool to automate selecting CMK, generating and encrypting CEK and uploading key metadata to the database
Source:

18. Existing App – Setup User Experience: SSMS or SSDT (Visual Studio)
UI for selecting columns (no automated data classification)
Select candidate columns to be encrypted
Analyze schema and application queries to detect conflicts and identify optimal encryption settings
Set up the keys
Encrypt selected columns while migrating the database to a target server (e.g. in Azure SQL Database
Key Setup tool to streamline selecting CMK, generating and encrypting CEK and uploading key metadata to the database
Encryption tool creating new (encrypted) columns, copying data from old (plain text) columns, swapping columns and re-creating dependencies
Select desired encryption settings for selected columns
UI for configuring encryption settings on selected columns (accepting/editing recommendations from the analysis tool)
Schema/workload analysis tool analyzing the schema and profiler logs
Source:

19. Server & Tools Business
11/27/2018
Summary: Always encrypted Protect data at rest and in motion, on-premises & cloud
Capability
ADO.Net client library provides transparent client-side encryption, while SQL Server executes T-SQL queries on encrypted data
Benefits
Sensitive data remains encrypted and queryable at all times on-premises & cloud.
Unauthorized users never have access to data or keys
No application changes
Data remains encrypted during query
TCE-enabled ADO .NET library
Apps
SQL Server
Encrypted query
No app changes
Master key
Columnar key
Source: Source:
When it comes to mission critical security we are introducing a unique encryption technology that protects data at rest and in motion and can be full queried while encrypted. The new ADO .NET library provide transparent client-side ecryption, while SQL Server executes T-SQL queries on encrypted data. The master keys stay with the application and not with SQL Server. This can work on-premises or SQL Server in Azure VM. So think about the hybrid scenarios where you wanted to take advantage of Azure cloud computing, but for certain data could not take advantage of cloud scale due to data security requirements. This technology ensures your data is always encrypted. Best of all no application changes are required.
© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

20. Row-Level Security
SQL Server 2016 Azure SQL Database

21. Row-level security
Protect data privacy by ensuring the right access across rows
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 bound to the table.
Customer 1
Customer 2
Customer 3
SQL Database
Row-Level Security (RLS) simplifies the design and coding of security in your application. RLS enables you to implement restrictions on data row access. For example ensuring that workers can access only those data rows that are pertinent to their department, or restricting a customer's data access to only the data relevant to their company.
The access restriction logic is located in the database tier rather than away from the data in another application tier. The database system applies the access restrictions every time that data access is attempted from any tier. This makes your security system more reliable and robust by reducing the surface area of your security system.
Implement RLS by using the CREATE SECURITY POLICY Transact-SQL statement, and predicates created as inline table valued functions.
Limitations during the preview:
RLS is incompatible with database export using Data Tier Application Framework (DACFx). You must drop all RLS policies before exporting.
Security policies cannot target views.
Certain query patterns using OR logic can trigger un-optimized table scans, decreasing query performance.
No syntax highlighting in SQL Server tools.

22. Benefits of row-level security
11/27/2018
Benefits of 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.
Source:
Row level security introduces predicate based access control. It features a flexible, centralized, predicate-based evaluation that can take into consideration metadata (such as labels) or any other criteria the administrator determines as appropriate. The predicate is used as a criterion to determine whether or not the user has the appropriate access to the data based on user attributes. Label based access control can be implemented by using predicate based access control. For more information, see Row-Level Security.
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.
© 2015 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

23. Row Level Security Concepts
Predicate function
User-defined inline table-valued function (iTVF) implementing security logic
Can be arbitrarily complicated, containing joins with other tables
Security predicate
Applies a predicate function to a particular table (SEMIJOIN APPLY)
Two types: filter predicates and blocking predicates
Security policy
Collection of security predicates for managing security across multiple tables
Source:
Row-Level Security enables customers to control access to rows in a database table based on the characteristics of the user executing a query (e.g., group membership or execution context).
Row-level filtering of data selected from a table is enacted through a security predicate filter defined as an inline table valued function. The function is then invoked and enforced by a security policy. The policy can restrict the rows that may be viewed (a filter predicate), but does not restrict the rows that can be inserted or updated from a table (a blocking predicate). There is no indication to the application that rows have been filtered from the result set; if all rows are filtered, then a null set will be returned.
Filter predicates are applied while reading data from the base table, and it affects all get operations: SELECT, DELETE (i.e. user cannot delete rows that are filtered), and UPDATE (i.e. user cannot update rows that are filtered, although it is possible to update rows in such way that they will be subsequently filtered). Blocking predicates are not available in this version of RLS, but equivalent functionality (i.e. user cannot INSERT or UPDATE rows such that they will subsequently be filtered) can be implemented using check constraints or triggers.
Filter predicates and security policies have the following behavior:
Define a security policy that filters the rows of a table. The application is unaware that any rows have been filtered for SELECT, UPDATE, and DELETE operations, including situations where all the rows have been filtered out. The application can INSERT any rows, regardless of whether or not they will be filtered during any other operation.
Define a predicate function that joins with another table and/or invokes a function. The join/function is accessible from the query and works as expected without any additional permission checks.
Issue a query against a table that has a security predicate defined but disabled. Any rows that would have been filtered or restricted are not affected.
The dbo user, a member of the db_owner role, or the table owner queries against a table that has a security policy defined and enabled. Rows are filtered/restricted as defined by the security policy.
Attempts to alter the schema of a table bound by a security policy will result in an error. However, columns not referenced by the filter predicate can be altered.
Attempts to add a predicate on a table that already has one defined (regardless of whether it is enabled or disabled) results in an error.
Attempts to modify a function used as a predicate on a table within a security policy results in an error.
Defining multiple active security policies that contain non-overlapping predicates, succeeds.
CREATE SECURITY POLICY mySecurityPolicy
ADD FILTER PREDICATE dbo.fn_securitypredicate(wing, startTime, endTime)
ON dbo.patients

24. Example
Fine-grained access control over rows in a table based on one or more pre-defined filtering criteria, e.g., 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)
Source:

25. RLS in Three Steps Database Security Policy Application Patients
Microsoft Research 2013
11/27/2018 4:23 AM
RLS in Three Steps
Two App user (e.g., nurse) selects from Patients table
One Policy manager creates filter predicate and security policy in T-SQL, binding the predicate to the Patients table
Three Security Policy transparently rewrites query to apply filter predicate
Nurse
Database
Policy Manager
Filter Predicate:
INNER JOIN…
Security
Policy
Application
Patients
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)
Policy manager creates a filter predicate and security policy
App user (e.g., a nurse) selects from the Patients table
The query is transparently rewritten to apply the filter predicate
Notice: No app changes!
SELECT * FROM Patients
SEMIJOIN APPLY dbo.fn_securitypredicate(patients.Wing);
SELECT * FROM Patients
SELECT Patients.* FROM Patients,
StaffDuties d INNER JOIN Employees e ON (d.EmpId = e.EmpId)
WHERE e.UserSID = SUSER_SID() AND Patients.wing = d.Wing;
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

26. Create Security Policy
-- The following syntax creates a security policy with a filter predicate for the Customer table, and leaves the security policy disabled
CREATE SECURITY POLICY [FederatedSecurityPolicy]
ADD FILTER PREDICATE [rls].[fn_securitypredicate]([CustomerId])
ON [dbo].[Customer];
-- Create a new schema and predicate function, which will use the application user ID stored in CONTEXT_INFO to filter rows.
CREATE FUNCTION rls.fn_securitypredicate int)     
RETURNS TABLE     
WITH SCHEMABINDING
AS     
RETURN (
SELECT 1 AS fn_securitypredicate_result     
WHERE         
DATABASE_PRINCIPAL_ID() = DATABASE_PRINCIPAL_ID('dbo')
-- application context         
AND CONTEXT_INFO() = GO
Creates a security policy for row level security.
The following examples demonstrate the use of the CREATE SECURITY POLICY syntax.
For an example of a complete security policy scenario, see Row Level Security.
Source:
Row-level filtering of data selected from a table is enacted through a security predicate filter defined as an inline table valued function. The function is then invoked and enforced by a security policy. The policy can restrict the rows that may be viewed (a filter predicate), but does not restrict the rows that can be inserted or updated from a table (a blocking predicate). There is no indication to the application that rows have been filtered from the result set; if all rows are filtered, then a null set will be returned.
Filter predicates are applied while reading data from the base table, and it affects all get operations: SELECT, DELETE (i.e. user cannot delete rows that are filtered), and UPDATE (i.e. user cannot update rows that are filtered, although it is possible to update rows in such way that they will be subsequently filtered). Blocking predicates are not available in this version of RLS, but equivalent functionality (i.e. user cannot INSERT or UPDATE rows such that they will subsequently be filtered) can be implemented using check constraints or triggers.
Filter predicates and security policies have the following behavior:
Define a security policy that filters the rows of a table. The application is unaware that any rows have been filtered for SELECT, UPDATE, and DELETE operations, including situations where all the rows have been filtered out. The application can INSERT any rows, regardless of whether or not they will be filtered during any other operation. Define a predicate function that joins with another table and/or invokes a function. The join/function is accessible from the query and works as expected without any additional permission checks.
Issue a query against a table that has a security predicate defined but disabled. Any rows that would have been filtered or restricted are not affected.
The dbo user, a member of the db_owner role, or the table owner queries against a table that has a security policy defined and enabled. Rows are filtered/restricted as defined by the security policy.
Attempts to alter the schema of a table bound by a security policy will result in an error. However, columns not referenced by the filter predicate can be altered.
Attempts to add a predicate on a table that already has one defined (regardless of whether it is enabled or disabled) results in an error.
Attempts to modify a function used as a predicate on a table within a security policy results in an error.
Defining multiple active security policies that contain non-overlapping predicates, succeeds.
Source:

27. Dynamic Data Masking
SQL Server 2016 Azure SQL Database

28. Dynamic Data Masking
Prevent the abuse of sensitive data by hiding it from users
Configuration made easy in the new Azure portal
Policy-driven at the table and column level, for a defined set of users
Data masking applied in real-time to query results based on policy
Multiple masking functions available (e.g. full, partial) for various sensitive data categories (e.g. Credit Card Numbers, SSN, etc.)
Table.CreditCardNo
Real-time data masking; partial masking
Azure SQL Database
SQL Server 2016 CTP2+
Source:
Dynamic data masking limits sensitive data exposure by masking it to non-privileged users. Dynamic data masking helps prevent unauthorized access to sensitive data by enabling customers to designate how much of the sensitive data to reveal with minimal impact on the application layer. It’s a policy-based security feature that hides the sensitive data in the result set of a query over designated database fields, while the data in the database is not changed. Dynamic data masking is easy to use with existing applications, since masking rules are applied in the query results, and there is no need to modify existing queries.
For example, a call center support person may identify callers by several digits of their social security number or credit card number, but those data items should not be fully exposed to the support person. A developer can define a masking rule to be applied to each query result that masks all but the last four digits of any social security number or credit card number in the result set. For another example, by using the appropriate data mask to protect personally identifiable information (PII) data, a developer can query production environments for troubleshooting purposes without violating compliance regulations.
Dynamic data masking limits the exposure of sensitive data and prevents accidental viewing by engineers that access directly databases for troubleshooting purposes or non-privileged application users. Dynamic data masking doesn’t aim to prevent privileged database users from connecting directly to the database and running exhaustive queries that expose pieces of the sensitive data. Dynamic data masking is complimentary to other SQL Server security features (auditing, encryption, row level security…) and it is highly recommended to enable them in addition in order to protect better the sensitive data in the database.
Since data is masked just before being returned to the user, changing the data type to an unmasked type will return unmasked data.
Dynamic data masking is available in SQL Server 2016 Community Technology Preview 2 (CTP2). However, to enable dynamic data masking, you must use trace flags 209 and 219. For Azure SQL Database, see Get started with SQL Database Dynamic Data Masking (Azure Preview portal).

29. Other security enhancements
Audit success/failure of database operations
Enhanced auditing for OLTP with ability to track history of record changes
Transparent Data Encryption support for storage of In- memory OLTP Tables
Backup encryption now supported with compression
Source:

30. gMSA support Group Managed Service Accounts (gMSA)
Automatically set domain scope for Managed Service Accounts
Automatic password rotation
Much more secure than regular domain accounts
Enables cross-system security context
Why would I want a gMSA?
No need to manually change passwords on all AlwaysOn instances
How does it work?
Passwords are managed by domain
What versions will it be supported in?
Supported in SQL Server 2014 and SQL Server 2016

31. Domain-independent Availability Groups
Environments supported:
Cross domains (with trust)
Cross domains (no trust)
No domain at all
Cluster management via PowerShell only
SQL management as normal
Use of certificate-secured endpoints like DBM
What versions will it be supported in?
SQL Server 2016
SQL 2017: Cross-Windows-and-Linux Availability Groups

32. SQL 2017 new Security Features
.NET CLR (common language runtime)
CLR uses Code Access Security (CAS) in the .NET Framework, which is no longer supported as a security boundary. (Safe might no longer be safe!)
sp_configure option called clr strict security is introduced to enhance the security of CLR assemblies.
New Permissions
DATABASE SCOPED CREDENTIAL is now a class of securable, supporting CONTROL, ALTER, REFERENCES, TAKE OWNERSHIP, and VIEW DEFINITION permissions.
ADMINISTER DATABASE BULK OPERATIONS, which is restricted to SQL Database, is now visible in sys.fn_builtin_permissions.

33. Security resources SQL Server Security Center
center-for-sql-server-database-engine-and-azure-sql-database
SQL Server Security Documentation (2016)
2016#Security
SQL Server 2017 New Features
2017
SQL Injection Resources
injection

34. SQL Server 2017
Industry-leading performance and security NOW ON LINUX and DOCKER
1/10th the cost of Oracle
Choice of platform and language
Industry-leading performance 
Most secure over the last 7 years
Only commercial DB with AI built-in
End-to-end mobile BI on any device
Microsoft
Tableau
Oracle
$120
$480
$2,230 R
1/10
Self-service BI per user
T-SQL
Java
C/C++
C#/VB.NET
PHP
Node.js
Python
Ruby
#1 TPC-H performance 1TB, 10TB, 30TB
#1 TPC-E performance
#1 price/performance
R and Python + in-memory at massive scale
Native T-SQL scoring
A fraction of the cost
#1 price/performance in TPC-H non-clustered as of 9/1/
#1 TPC-H non-clustered benchmark as of 9/1/
#1 TPC-E performance as of 9/1/
In-memory across all workloads
Most consistent data platform
Private cloud
Public cloud

35. Thank you!
@gwalters69 on twitter
Resources: