When it comes to data, security is very important (not that other resources should be left unsecured). Under the Azure SQL Database blade, we have a set of options related to security. SECURITY options include Advanced Threat Protection, Auditing, Dynamic Data Masking, and Transparent data encryption. Advanced Threat Protection and Auditing can be applied on the server level (for all databases on the server) or for a single database.

Advanced Threat Protection contains three subsections: 

• Data Discovery & Classification (preview)
• Vulnerability Assessment
• Threat Detection

The Data Discovery & Classification (preview) feature is still in beta but can be very useful. A scan of the database will be performed, and recommendations will be provided on which columns in your database should be marked as classified. This can be especially useful when considering data that should be considered regarding the general data protection regulation (GDPR).

Vulnerability Assessment will perform a security scan and provide security recommendations for your database. Examples of recommendations would be to to track firewall rules or to classify sensitive data.

Threat Detection applies machine learning to your security. This feature analyzes normal behavior and alerts you to any action that is out of the ordinary. For example, if one of the SQL logins always accesses the database in work hours and suddenly tries to log in during other periods, you will be alerted. Or, if one of the logins is always coming from a specific IP address and tries to access the database from the other side of the world, action will be detected and you will be alerted.

A screenshot of advanced threat protection is shown here:

Auditing allows us to track events and log them to the storage account. We can define the log retention period, and whether events are logged on the database or server level. As auditing is often a requirement for many organizations, especially in order to be compliant to different standards, this option allows you to fulfill that requirement. A screenshot for audit logs is shown here:

Before we proceed to dynamic data masking, let's run a simple query. Selecting the top 100 rows on the table SalesLT.Customers will return all information on the first 100 customers from the table. Here we have various types of data, and we may not want everyone with access to the database to see everything. Let's take a phone number, for example. Note that in the following screenshot, we can see that running the query will return the phone column:

The dynamic data masking blade will provide information on all the masking rules currently applied and recommendations for rules that you also may want to consider for masking. Note that the SQL administrator is excluded from data masking, and that you can add additional users to be excluded. A screenshot of dynamic data masking is shown here:

To add a new rule, we need to provide the Schema, Table, Column, and Masking field format. The Masking field format will allow you to control what masked data looks like in a query result. An example of how to add the phone column for data masking is shown here:

Once the data masking rule is applied, we can run the query again. As you can see in the following screenshot, the result will be different when the masking rule is applied, and the phone column will then return xxx for all values:

Using dynamic data masking, we can control user access to data and prevent them seeing confidential information. For example, if we have billing information and contact information in the same table, we may want to provide access to the table to different users but allow them to see different information. We can allow our sales department to see an email or phone number, but want to prevent them from seeing credit card information. On the other hand, we don't want to prevent everyone from seeing credit card information and want to allow this information to be accessed by the finance department. Dynamic data masking is ideal for this scenario, wherein users can have access to the same table but see different sets of information. 

Transparent data encryption (TDE) is used for encrypting databases in rest mode. This feature is available for on-premises versions of SQL Server but requires an implementation that isn't so simple. For Azure SQL Databases, this feature is turned on automatically for newly created databases. This wasn't always the case, and for older databases you can turn it on simply by switching the TDE option on. As simple as that, databases (and all backups) are encrypted at rest. Transparent database encryption is shown in the following screenshot: