1. Fast Start for Microsoft Azure – SQL Server IaaS Workshop

2. Section 5: SQL Server Security
Lesson 1: Overview
Security Best Practices

3. Network eavesdropping
Attack Types
Brute force attacks
Spoofing
Network eavesdropping
Password cracking
Dictionary attacks
Credential theft
Security is an very important aspect when it comes to computers and it should be at the top of everyone’s mind. When building environments, machines that are connected to internet, security becomes job one. One must take deliberate steps to protect the machines running in the cloud. Below are some of the well-known threats /attacks that are applicable to all types of computer environments:
Password cracking. As soon as an attacker knows a valid administrator username and password combination they own your machine. If you use default account names, you are giving the attacker a head start. Then the attacker only has to crack the account’s password. The use of blank or weak passwords makes the attacker’s job even easier. The two main methods used to crack passwords are brute force and dictionary attacks.
Brute force attacks: An attacker guesses identity and/or credentials through the use of brute force.
Attacks that use the raw computer processing power to try different permutations of any variable that could expose a security hole. For example, if an attacker knew that access required an 8-character username and a 10-character password, the attacker could iterate through every possible permutation (256 multiplied by itself 18 times) in order to attempt to gain access to the machine. Scripts make this even easier so no programming knowledge is required.
Dictionary attacks: An attacker guesses identity and/or credentials through the use of common terms in a dictionary designed for that purpose.
The Confiker.B worm used a dictionary of weak passwords in order to compromise machines. Use of a list of likely credentials (usernames, passwords, coding methods) make gaining access relatively easy especially when delivered by a script. This approach is more socially focused than the "brute force" attack method, which increases the likelihood of success in a shorter amount of time.
Spoofing. An attempt to gain access to a system by using a false identity. This can be accomplished by using stolen user credentials or a false IP address. After the attacker successfully gains access as a legitimate user or host, elevation of privileges or abuse using authorization can begin.
Credential theft. An attacker gains access to credentials through data theft; for instance, phishing or social engineering.
Using weak passwords.
Storing clear text credentials in configuration files.
Passing clear text credentials over the network.
Network eavesdropping. An attacker steals identity and/or credentials off the network by reading network traffic not intended for them.

4. Azure IaaS Virtual Machine Security Recommendations
Password cracking
Use complex passwords
Rename default privileged accounts
Brute force attacks
Change passwords on regular basis
Dictionary attacks
Restrict and protect accounts
Give administrators dedicated admin accounts
Objective: Discuss how to reduce the risks of different attacks.

5. Azure IaaS Virtual Machine Security Recommendations
Spoofing
Evaluate best suitable antivirus software or intrusion detection software available in the market for use in Windows Azure Virtual Machines
Credential theft
Mark privileged accounts as “sensitive and cannot be delegated” in AD DS
Do not surf the web from a data center
Do not check from a data center
Network eavesdropping
Consider an RDP gateway or jump box in Azure as point of connectivity to all other IaaS virtual machines for administration
Enable network security: Do not store the LAN Manager hash value on the next password change
Objective: Discuss how to reduce the risks of attacks.

6. Lesson Knowledge Check
Question: How can dictionary attacks be prevented? Answer: Restrict and protect accounts Give administrators dedicated admin accounts Question: How can credential theft be prevented? Answer:Mark privileged accounts as “sensitive and cannot be delegated” in AD DS Do not surf the web from a data center Do not check from a data center
© 2015 Microsoft Corporation

7. Section 5: SQL Server Security
Lesson 2: SQL Server Feature
Security Features

8. SQL Server Audit
SQL Server Audit is a mechanism that allows you setup logging and tracking of certain security events in order to have a digital audit of the desired and required events SQL Server Audit – think of this as the destination and behavior of what you’re auditing Server Audit Specification – instance-level actions Database Audit Specification – database-level actions

9. How does SQL Server use Certificates?
Certificate server - SQL Server can be used to issue certificates to users within the server for authentication and encryption purposes Service Broker - Service Broker can use secure, authenticated communication between two services in a conversation. Code authentication – SQL Server can use a certificate in a database to add a digital signature to a database object such as a stored procedure or function. This is a common way to guarantee the authenticity of a code module. Data encryption – SQL Server can use a certificate to encrypt or decrypt data. However, be aware that certificate-based cryptography incurs greater performance overhead than cryptography with a symmetric key.

10. Data Encryption with SQL Server
Concept of Defense in Depth SQL Server offers encryption at the cell level and at file level (data at rest) by using TDE Cell level encryption is implemented as a series of built-ins and a key management hierarchy It is a manual process that requires a re-architecture of the application to call the encryption and decryption functions It also requires the schema to be modified to store the data as varbinary and then re- cast back to the appropriate data type Cannot use any of the automatic query optimization techniques
One of the most interesting phenomena in the computing arena within the last few years is the growing concern for security, which, at this point, is being treated on a par with efficiency and cost (as a matter of fact, security became one of the primary factors when evaluating any technology-based solution) . The main driving factors behind this trend are the increasing number of computer worms and viruses (combined with ubiquity of the Internet), the financial impact of their destructive nature, as well as mounting international political tensions. Microsoft Secure Computing initiative, launched in early 2002, triggered major programming efforts geared towards securing the Windows 2003 operating system code; however, signs of this tendency were present in a number of other, previously released products.
Recently there have been more stringent security standards that many companies have to comply to, especially the companies that deal with sensitive data (credit card numbers, SSN etc). The examples of these standards are PCI, Sarbanes-Oxley and HIPAA (Health Insurance Portability and Accountability Act ) to name a few. Also there have been several situations where tapes/hard drives or laptops containing sensitive data when lost or stolen are vulnerable to unauthorized access, either by running a software attack tool against them or by transferring the computer‘s hard disk to a different computer.
SQL Server 2000 and earlier versions did not have built-in support for encrypting the data stored in a database. Why would you need to encrypt data that is stored in a well-secured database on a secure server nestled safely behind state-of-the-art firewalls? Because of an important, age-old security principal called defense in depth. Defense in depth means layering defenses so that even if attackers successfully pierce your outermost defenses they still must get through layer after layer of defense to get to the prize. In a database, it means that if an attacker gets through the firewall and through Windows security on the server to the database, he or she still has to do some brute force hacking to decrypt your data. In addition, in these days of legislated data and privacy protection, data must have strong protection.
SQL Server offers encryption at the cell level. Cell-level encryption was introduced in Microsoft SQL Server 2005 and is still fully supported. Cell-level encryption is implemented as a series of built-ins and a key management hierarchy. Using this encryption is a manual process that requires a re-architecture of the application to call the encryption and decryption functions. In addition, the schema must be modified to store the data as varbinary and then re-cast back to the appropriate data type when read. The traditional limitations of encryption are inherent in this method as none of the automatic query optimization techniques can be used.
Comparison with TDE
Cell-level encryption has a number of advantages over database-level encryption. It offers a more granular level of encryption. In addition, data is not decrypted until it is used (when a decryption built-in function is called) so that even if a page is loaded into memory, sensitive data is not in clear text. Cell-level encryption also allows for explicit key management. Keys can be assigned to users and protected by passwords to prevent automatic decryption. This offers another degree of control (users can, for example, have individual keys for their own data); however, the administrator is further burdened with maintaining the keys (although Extensible Key Management, described earlier in this module, can also be used for easier administration). Because cell-level encryption is highly configurable, it may be a good fit for applications that have targeted security requirements.
The primary disadvantages of cell-level encryption are the application changes needed to use it, the performance penalties, and the administration cost. As noted previously, encryption and decryption requires that you use built-ins. This is an entirely manual process and requires the varbinary data type; this means columns must be changed from their original data type to varbinary. For security, the encryption is always salted so the same data will have a different value after encryption. As a result, referential constraints such as foreign keys, and candidate keys such as primary keys do not provide any benefit on these encrypted columns. This also affects query optimization—indexes on the encrypted columns offer no advantage so range and equality searches turn into full table scans. TDE allows full use of indexes and other traditional query optimization tools as well as performing the encryption in bulk.
As a rough comparison, performance for a very basic query (that selects and decrypts a single encrypted column) when using cell-level encryption tends to be around 20% worse. This inversely scales with workload size resulting in performance degradations that are several magnitudes worse when attempting to encrypt an entire database. One sample application with 10,000 rows was four times worse with one column encrypted, and 20 times worse with nine columns encrypted. Because cell-level encryption is custom to each application, performance degradation will vary depending on application and workload specifics. As noted in Impact on the Database, this compares to 3-5% for TDE on average and 28% in the worst case (assuming the encryption scan is not running).
Although these performance concerns for cell-level encryption can be mitigated by explicit application design, more care must be exercised to prevent the accidental leakage of data. For example, consider a quick scheme to enable fast equality searches by using hashes of the sensitive data. If these hashes are stored in a column along with the encrypted data, it quickly becomes obvious if two rows have identical values because the hashes will be the same. Extra security reviews must be used to ensure that unintended data disclosures do not occur so both the database and application must be security aware. TDE prevents these data leak scenarios by encrypting at the broadest scope. In both cell-level encryption and database-level encryption, information is decrypted on the server; decrypted data is sent to clients in plaintext. SSL is recommended to protect this channel.

11. Transparent Data Encryption
Performs all of the cryptographic operations at the database level Removes any need for application developers to create custom code to encrypt and decrypt data Data is encrypted as it is written to disk, and decrypted as it is read from disk As SQL Server manages encryption And decryption transparently, there is no need for application changes
Transparent Data Encryption
Transparent data encryption performs all of the cryptographic operations at the database level, which removes any need for application developers to create custom code to encrypt and decrypt data. Data is encrypted as it is written to disk, and decrypted as it is read from disk. By using SQL Server to manage encryption and decryption transparently, you can secure business data in the database without requiring any changes to existing applications.
A Database Encryption Key (DEK) is used to perform the encryption and decryption, and this DEK is stored in the database boot record for availability during recovery scenarios. You can use a service master key or Hardware Security Module (HSM) to protect the DEK. HSMs are usually USB devices or smartcards and are therefore less likely to be stolen or lost.
When enabling TDE, you should immediately back up the certificate and the private key associated with the certificate. If the certificate ever becomes unavailable or if you must restore or attach the database on another server, you must have backups of both the certificate and the private key or you will not be able to open the database. The encrypting certificate or asymmetric should be retained even if TDE is no longer enabled on the database. Even though the database is not encrypted, the database encryption key may be retained in the database and may need to be accessed for some operations.

12. Encryption hierarchy – enabling TDE
Encryption Hierarchy Service Master Key Database Master Key Certificates Database Encryption Key (DEK)
Service Master Key
At the root of encryption Hierarchy is the Windows Data Protection API (DPAPI), which secures the key hierarchy at the machine level and is used to protect the service master key (SMK) for the database server instance. The Service Master Key resides in the master database is generated automatically the first time any key needs to be encrypted. By default, the Service Master Key is encrypted using the Windows data protection API and using the local machine key. The Service Master Key can only be opened by the Windows service account under which it was created or by a principal/User with access to both the service account name and its password.
Database Master Key
The Service Master Key protects the Database Master Key (DMK). The database master key is a symmetric key used to protect the private keys of certificates and asymmetric keys that are present in the database. It is important to remember that one Database Master Key can be created in a User Database as well but only the master key created in the Master Database is relevant to TDE. It is used to protect the private key of the Certificate which is in turn is protects the DEK created in the user database.
Certificates
The Certificates used to protect the Database Encryption Key (DEK) also reside in the master database. More than one certificate can be created per instance of SQL Server but only one certificate can be used to encrypt the DEK at any point. There is another way of protecting/encrypting the DEK using asymmetric keys which will not be covered in detail here.
It is very important to backup the certificate and store it at a safe location, preferably on a different location. Without a valid certificate, the encrypted database cannot be restored from a backup nor can it be attached to a server.
Any number of certificates can be created in master database. But at any given point of time, only one certificate can be used to Encrypt the ―Database Encryption Key (DEK) ―residing in the User database. Metadata of the certificates can be viewed by querying the sys.certificates catalog view.
When altering the DEK to use a different certificate, always retain a copy of the old certificate. The rule of thumb must be, Never delete a certificate. Only Archive.
The sys.certificates catalog view will have an additional column that will show if and when the certificate was backed up. This will not include the location to which it was backed up to for obvious reasons.
Database Encryption Key (DEK)
At the leaf level in the Encryption Hierarchy is the Database Encryption Key (DEK). The DEK is encrypted using the Certificate created in the master database or by an Asymmetric Key. Only asymmetric keys that reside on an external EKM (Extensible Key Management) provider will be allowed as DEK encryptors. The actual data in the database and the log file is encrypted using the Database Encryption Key. The Database Encryption Key is stored in the Boot Record of the database and persists in the database when the database is backed up or when the database is detached from the server. The DEK will remain encrypted in the database even when the Encryption on the database is turned off. Users will have an option to change the Database Encryption Key to use a different Encryption Algorithm or to use a different Certificate. One should exercise caution when changing the DEK as it will force an Encryption Scan on the entire database to use the new DEK. Encryption Scan is a very resource intensive operation (both CPU and I/O) and should be done during a maintenance window or during periods of low system activity.

13. An unauthorized user obtains the backup tapes for a database
Scenarios
A lost or stolen laptop contains SQL Server database with sensitive data
An unauthorized user obtains the backup tapes for a database
A discontent employee copies the database files and takes them to a competitor
Consider all these scenarios. There is one thing in common, when TDE is enabled, without the password or HSM, no one will be able to pen the database and get access to the data in it.
Without the required password or HSM to decrypt the DEK, the database cannot be opened.

14. Demonstration: TDE
This demo refers to Section 5 Security - Transparent Data Encryption.docx

15. Contained Databases
Database that is isolated from other databases and from the instance of SQL Server that hosts the database
Helps user to isolate their database from the instance in 4 ways:
Much of the metadata that describes a database is maintained in the database
All metadata are defined using the same collation
User authentication can be performed by the database
The SQL Server environment (DMV's, XEvents, etc.) reports and can act upon containment information
Partial Containment was implemented to resolve two of the most common dependencies, logins and collation
Enable at Instance level first: sp_configure 'contained database authentication', 1
Enable at Database level: ALTER DATABASE <name> SET CONTAINMENT = PARTIAL
A contained database is a database that is isolated from other databases and from the instance of SQL Server that hosts the database. SQL Server 2014 helps user to isolate their database from the instance in 4 ways.
Much of the metadata that describes a database is maintained in the database. (In addition to, or instead of, maintaining metadata in the master database.)
All metadata are defined using the same collation.
User authentication can be performed by the database, reducing the databases dependency on the logins of the instance of SQL Server.
The SQL Server environment (DMV's, XEvents, etc.) reports and can act upon containment information.
Some features of partially contained databases, such as storing metadata in the database, apply to all SQL Server 2014 databases. Some benefits of partially contained databases, such as database level authentication and catalog collation, must be enabled before they are available. Partial containment is enabled using the CREATE DATABASE and ALTER DATABASE statements or by using SQL Server Management Studio.
A fully contained database includes all the settings and metadata required to define the database and has no configuration dependencies on the instance of the SQL Server Database Engine where the database is installed. In previous versions of SQL Server, separating a database from the instance of SQL Server could be time consuming and required detailed knowledge of the relationship between the database and the instance of SQL Server. Partially contained databases make it easier to separate a database from the instance of SQL Server and other databases.
The contained database considers features with regard to containment. Any user-defined entity that relies only on functions that reside in the database is considered fully contained. Any user-defined entity that relies on functions that reside outside the database is considered uncontained.

16. Contained Databases – Security Best Practices
Thoroughly check permissions on the contained database. Giving the ALTER ANY USER permissions can grant access to the database without SQL Administrator knowledge
Database owners have the ALTER ANY USER permission, audit users periodically on this database
Disable the guest account as contained database users can access other databases if guest is enabled
Avoid creating users that duplicates a login as it could cause a denial of service for the SQL login
Consider using Windows Authentication when possible to take advantage of Kerberos and password policies
Passwords in contained databases are stored within the database. Anyone with access can perform a dictionary attack. Consider restricting access to the database or using Window Authentication
There are some threats that should be understood and therefore mitigated when migrating to a contained database. Most of the issues are related to the USER WITH PASSWORD authentication process, which moves the boundary from the DB engine level to the database level
Users in a contained database that have the ALTER ANY USER permission, such as members of the db_owner and db_securityadmin fixed database roles, can grant access to the database without the knowledge or permission if the SQL Server administrator. Granting users access to a contained database increases the potential attack surface area against the whole SQL Server instance. Administrators should understand this delegation of access control, and be very careful about granting users in the contained database the ALTER ANY USER permission. All database owners have the ALTER ANY USER permission. SQL Server administrators should periodically audit the users in a contained database.
Accessing Other Databases Using the guest Account
Database owners and database users with the ALTER ANY USER permission can create contained database users. After connecting to a contained database on an instance of SQL Server, a contained database user can access other databases on the Database Engine, if the other databases have enabled the guest account.
Some applications might require that a user to have access to more than one database. This can be done by creating identical contained database users in each database. Use the SID option when creating the second user with password. The following example creates two identical users in two databases.
Creating a Duplicate User in Another Database
Creating a User that Duplicates a Login
If a contained database user with password is created, using the same name as a SQL Server login, and if the SQL Server login connects specifying the contained database as the initial catalog, then the SQL Server login will be unable to connect. The connection will be evaluated as the contained database user with password principal on the contained database instead of as a user based on the SQL Server login. This could cause an intentional or accidental denial of service for the SQL Server login.
As a best practice, members of the sysadmin fixed server role should consider always connecting without using the initial catalog option. This connects the login to the master database and avoids any attempts by a database owner to misuse the login attempt. Then the administrator can change to the contained database by using the USE <database> statement. You can also set the default database of the login to the contained database, which completes the login to master, and then transfers the login to the contained database.
As a best practice, do not create contained database users with passwords who have the same name as SQL Server logins.
If the duplicate login exists, connect to the master database without specifying an initial catalog, and then execute the USE command to change to the contained database.
When contained databases are present, users of databases that are not contained databases should connect to the Database Engine without using an initial catalog or by specifying the database name of a non-contained database as the initial catalog. This avoids connecting to the contained database which is under less direct control by the Database Engine administrators.
Logins that have the ALTER ANY DATABASE permission, such as members of the dbcreator fixed server role, and users in a non-contained database that have the CONTROL DATABASE permission, such as members of the db_owner fixed database role, can change the containment setting of a database. If the containment setting of a database is changed from NONE to either PARTIAL or FULL, then user access can be granted by creating contained database users with passwords. This could provide access without the knowledge or consent of the SQL Server administrators. To prevent any databases from being contained, set the Database Engine contained database authentication option to 0. To prevent connections by contained database users with passwords on selected contained databases, use login triggers to cancel login attempts by contained database users with passwords.
Increasing Access by Changing the Containment Status of a Database
Attaching a Contained Database
By attaching a contained database, an administrator could give unwanted users access to the instance of the Database Engine. An administrator concerned about this risk can bring the database online in RESTRICTED_USER mode, which prevents authentication for contained database users with passwords. Only principals authorized through logins will be able to access the Database Engine.
Users are created using the password requirements in effect at the time that they are created and passwords are not rechecked when a database is attached. By attaching a contained database which allowed weak passwords to a system with a stricter password policy, an administrator could permit passwords that do not meet the current password policy on the attaching Database Engine. Administrators can avoid retaining the weak passwords by requiring that all passwords be reset for the attached database.
Password Policies
Passwords in a database can be required to be strong passwords, but cannot be protected by robust password policies. Use Windows Authentication whenever possible to take advantage of the more extensive password policies available from Windows.
Contained database users with passwords cannot use Kerberos Authentication. When possible, use Windows Authentication to take advantage of Windows features such as Kerberos.
Kerberos Authentication
Offline Dictionary Attack
The password hashes for contained database users with passwords are stored in the contained database. Anyone with access to the database files could perform a dictionary attack against the contained database users with passwords on an unaudited system. To mitigate this threat, restrict access to the database files, or only permit connections to contained databases by using Windows Authentication.
Escaping a Contained Database
If a database is partially contained, SQL Server administrators should periodically audit the capabilities of the users and modules in contained databases.
Denial of Service Through AUTO_CLOSE
Do not configure contained databases to auto close. If closed, opening the database to authenticate a user consumes additional resources and could contribute to a denial of service attack.

17. Lesson Knowledge Check
Question: Which SQL Server feature helps in encryption/decryption without creating/modifying any code in the application ?
Answer: TDE
Question: What are the steps to enable database containment for a given database?
Answer: Enable at Instance level first: sp_configure 'contained database authentication', 1
Enable at Database level: ALTER DATABASE <name> SET CONTAINMENT = PARTIAL
© 2015 Microsoft Corporation

18. Section 5: SQL Server Security
Lesson 2: SQL Server Feature
SQL 2016 Security Features

19. Benefits of Always Encrypted
9/10/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.

20. 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
dbo.Patients
Jane Doe
Name
SSN
USA
Country
Jim Gray
John Smith
Enhanced ADO.NET
Library
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
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.
dbo.Patients
Jane Doe
Name
1x7fg655se2e
SSN
USA
Jim Gray
0x7ff654ae6d
John Smith
0y8fj754ea2c
Country

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

22. Demonstration: Always Encrypted
This demo refers to Section 5 Security - Always Encrypted.docx

23. 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.
Status: Public preview

24. Benefits of row-level security
9/10/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.
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.

25. RLS Concepts Predicate function Security predicate Security policy
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
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

26. Example
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)
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
Security

27. Demonstration: Row Level Security
This demo refers to Section 5 Security - Row Level Security.docx
© 2015 Microsoft Corporation

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
SQL Database
SQL Server 2016 CTP2
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).
Status: Public preview

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. Lesson Knowledge Check
Question: What are the types of encryption Always Encrypted supports? Answer: Deterministic and Randomized Encryption
© 2015 Microsoft Corporation