Azure security baseline for Azure Synapse dedicated SQL pool (formerly SQL DW)

Article
11/14/2022
45 minutes to read

This security baseline applies guidance from the Azure Security Benchmark version 2.0 to Azure Synapse dedicated SQL pool (formerly SQL DW). The Azure Security Benchmark provides recommendations on how you can secure your cloud solutions on Azure. The content is grouped by the security controls defined by the Azure Security Benchmark and the related guidance applicable to Azure Synapse dedicated SQL pool.

You can monitor this security baseline and its recommendations using Microsoft Defender for Cloud. Azure Policy definitions will be listed in the Regulatory Compliance section of the Microsoft Defender for Cloud dashboard.

When a section has relevant Azure Policy Definitions, they are listed in this baseline to help you measure compliance to the Azure Security Benchmark controls and recommendations. Some recommendations may require a paid Microsoft Defender plan to enable certain security scenarios.

Note

Controls not applicable to Azure Synapse dedicated SQL pool (formerly SQL DW), and those for which the global guidance is recommended verbatim, have been excluded. To see how Azure Synapse dedicated SQL pool (formerly SQL DW) completely maps to the Azure Security Benchmark, see the full Azure Synapse dedicated SQL pool (formerly SQL DW) security baseline mapping file.

Network Security

For more information, see the Azure Security Benchmark: Network Security.

NS-1: Implement security for internal traffic

Guidance: When you deploy Azure Synapse Analytics resources, create or use an existing virtual network. Make sure all Azure virtual networks follow an enterprise segmentation principle that aligns with the business risks.

Does your system incur higher risk for the organization? Then isolate that system within its own virtual network. Sufficiently secure the virtual network with a network security group (NSG) or Azure Firewall.

Use Microsoft Defender for Cloud Adaptive Network Hardening to NSG configurations. These configurations limit ports and source IPs with reference to external network traffic rules.

Based on your applications and enterprise segmentation strategy, restrict or allow traffic between internal resources under your NSG rules. For specific, well-defined applications (such as a 3-tier app), this handling can be a highly secure deny by default.

Use Microsoft Sentinel to discover the use of legacy insecure protocols, such as:

SSL/TLSv1
SMBv1
LM/NTLMv1
WDigest
Unsigned LDAP binds
Weak ciphers in Kerberos

The minimal TLS version setting allows customers to choose which version of TLS their SQL data warehouses uses. Currently, TLS 1.0, 1.1, and 1.2 are supported. Setting a minimal TLS version ensures that newer TLS versions are supported. For example, choosing a TLS version 1.1 means only connections with TLS 1.1 and 1.2 are accepted. Connections with TLS 1.0 are rejected.

Do you want to access Azure Synapse Analytics data warehouses from your local computer? Then make sure that the firewall on your network and local computer allows outgoing communication on TCP port 1433.

When "Deny public network access" is set to "Yes", only connections via private endpoints are allowed. If this setting is "No" (the default), customers can connect by using:

Public endpoints with IP-based firewall rules or with virtual-network-based firewall rules.
Private endpoints by using Azure Private Link.

This behavior is outlined in the network access overview.

Responsibility: Shared

Microsoft Defender for Cloud monitoring: The Azure Security Benchmark is the default policy initiative for Microsoft Defender for Cloud and is the foundation for Microsoft Defender for Cloud's recommendations. The Azure Policy definitions related to this control are enabled automatically by Microsoft Defender for Cloud. Alerts related to this control may require an Microsoft Defender plan for the related services.

Azure Policy built-in definitions - Microsoft.Sql:

Name _{(Azure portal)}	Description	Effect(s)	Version _(GitHub)
Public network access on Azure SQL Database should be disabled	Disabling the public network access property improves security by ensuring your Azure SQL Database can only be accessed from a private endpoint. This configuration denies all logins that match IP or virtual network based firewall rules.	Audit, Deny, Disabled	1.1.0

NS-2: Connect private networks together

Guidance: With Azure ExpressRoute or Azure virtual private network (VPN), create private connections between Azure datacenters and on-premises infrastructure in a colocation environment. ExpressRoute connections don't go over the public internet. Compared with typical internet connections, ExpressRoute connections offer:

More reliability
Faster speeds
Lower latencies

Do you need to use point-to-site VPN and site-to-site VPN? Then connect on-premises devices or networks to a virtual network. You can use any combination of these VPN options and Azure ExpressRoute.

To connect two or more virtual networks in Azure together, use virtual network peering. Network traffic between peered virtual networks is private. This traffic is kept on the Azure backbone network.

With Private Link, you may connect to an Azure SQL server through a private endpoint. A private endpoint is a private IP address within a specific virtual network and subnet. The SQL administrator can choose to approve or reject a private endpoint connection. The administrator may optionally add a short text response.

Responsibility: Shared

Azure Policy built-in definitions - Microsoft.Sql:

Name _{(Azure portal)}	Description	Effect(s)	Version _(GitHub)
Private endpoint connections on Azure SQL Database should be enabled	Private endpoint connections enforce secure communication by enabling private connectivity to Azure SQL Database.	Audit, Disabled	1.1.0

NS-3: Establish private network access to Azure services

Guidance: With Azure Private Link, enable private access to Azure Synapse Analytics from your virtual networks without crossing the internet. Private access is another defense in-depth measure to the authentication and traffic security that Azure services offers.

You may also choose to deny public network access to the Azure SQL server that hosts your data warehouses. When enabled, this configuration allows connections only through private endpoints.

PolyBase and the COPY statement are commonly used to load data into Azure Synapse Analytics from Azure Storage accounts. Connectivity from PolyBase and the COPY statement to the account may break, though. In that breakage scenario, the Azure Storage account limits access only to a set of virtual network subnets through:

Private endpoints
Service endpoints
IP-based firewalls

Use Azure Virtual Network service endpoints to provide secure access to Azure Synapse Analytics. Azure Virtual Network uses an optimized route over the Azure backbone network without crossing the internet.

Responsibility: Shared

Azure Policy built-in definitions - Microsoft.Sql:

Name _{(Azure portal)}	Description	Effect(s)	Version _(GitHub)
Private endpoint connections on Azure SQL Database should be enabled	Private endpoint connections enforce secure communication by enabling private connectivity to Azure SQL Database.	Audit, Disabled	1.1.0

NS-4: Protect applications and services from external network attacks

Guidance: Protect your Azure Synapse Analytics resources against attacks from external networks, including:

Distributed denial of service (DDoS) attacks.
Application-specific attacks.
Unsolicited, potentially malicious internet traffic.

Using Azure Firewall, protect applications and services against potentially malicious traffic from the internet and other external locations. To protect your assets against DDoS attacks, enable DDoS standard protection on your Azure virtual networks. Use Microsoft Defender for Cloud to detect misconfiguration risks to your network-related resources.

Azure Synapse Analytics isn't intended to run web applications. So you don't need to protect it from external network attacks targeting web applications. There's no need to configure any other settings or deploy any extra network services.

Responsibility: Shared

NS-6: Simplify network security rules

Guidance: Using Azure Virtual Network service tags, define network access controls on NSGs or Azure Firewalls that are configured for your Azure Synapse Analytics resources. Use service tags in place of specific IP addresses when creating security rules. Specify the service tag name in the rule's source or destination, which allows or denies the traffic for the corresponding service. Microsoft manages the address prefixes that the service tag encompasses. Microsoft then automatically updates the service tag as addresses change.

When you use a service endpoint for your Azure Synapse SQL pool, outbound traffic to Azure SQL database public IP addresses is required. Open NSGs to Azure SQL Database IPs to allow connectivity. Using NSG service tags for Azure SQL Database fills this requirement.

Responsibility: Shared

NS-7: Secure Domain Name Service (DNS)

Guidance: Follow the best practices for DNS security to help prevent common attacks, such as:

Dangling DNS
DNS amplifications attacks
DNS poisoning and spoofing

Are you using Azure DNS as your authoritative DNS service? Then protect DNS zones and records from accidental or malicious modification by using Azure RBAC and resource locks.

You may use DNS aliases to connect to the Azure SQL server that houses your data warehouses. PowerShell and REST APIs accept calls to create and manage DNS aliases for your logical SQL server name. You may use a DNS alias in place of the server name. Client programs can use the alias in their connection strings. The DNS alias provides a translation layer that can redirect your client programs to different servers. This layer spares you the difficulties of finding and editing all the clients and their connection strings.

When you start developing the client programs, have them use a DNS alias in their connection strings. You make the properties of the alias point to a test version of your server. Later, when the new system goes live in production, update the alias's properties to point to the production server. No change to the client programs is necessary.

Responsibility: Shared

Identity Management

For more information, see the Azure Security Benchmark: Identity Management.

IM-1: Standardize Azure Active Directory as the central identity and authentication system

Guidance: Azure Synapse Analytics uses Azure Active Directory (Azure AD) as the default identity and access management service. Standardize Azure AD to govern your organization's identity and access management in:

Microsoft Cloud resources, such as:
- Azure portal
- Azure Storage
- Azure Virtual Machine (Linux and Windows)
- Azure Key Vault
- PaaS
- SaaS applications
Your organization's resources, such as applications on Azure or your corporate network resources.

Make securing Azure AD a high priority in your organization's cloud security practice. Azure AD provides an identity secure score. This score helps you assess your identity security posture compared with Microsoft's best practice recommendations. Use the score to gauge how closely your configuration matches best practice recommendations. Then use the score to make improvements in your security posture.

Note: Azure AD supports external identities. Users without a Microsoft account may sign in to their applications and resources with their external identity.

For dedicated SQL pools (formerly SQL DW), Azure AD authentication uses contained database users to authenticate identities at the database level. With Azure AD, you may connect from SQL Server Management Studio using Active Directory Universal Authentication, which includes multi-factor authentication. Azure AD supports similar connections from SQL Server Data Tools (SSDT) that use Active Directory Interactive Authentication.

Three Azure RBAC built-in roles are available for the management of dedicated SQL pools (formerly SQL DW):

SQL DB Contributor lets you manage SQL data warehouses, but not access to them. You can't manage their security-related policies or their parent SQL servers.
SQL Security Manager lets you manage the security-related policies of SQL servers and data warehouses, but not access to them.
SQL Server Contributor lets you manage SQL servers and data warehouses, but not access to them. You can't manage their security-related policies.

Azure SQL also supports SQL authentication. With this authentication method, the user submits a user account name and associated password to establish a connection. This password is stored in one of two places:

The master database for user accounts that are linked to a sign-in.
The database containing the user accounts not linked to a sign-in.

A sign-in is a single account in the master database, to which a user account in one or more databases can be linked. With a sign-in, the credential information for the user account is stored with the sign-in.

A user account is an individual account in any database that may or may not be linked to a sign-in. With a user account that isn't linked to a sign-in, the credential information is stored with the user account.

Responsibility: Shared

Azure Policy built-in definitions - Microsoft.Sql:

Name _{(Azure portal)}	Description	Effect(s)	Version _(GitHub)
An Azure Active Directory administrator should be provisioned for SQL servers	Audit provisioning of an Azure Active Directory administrator for your SQL server to enable Azure AD authentication. Azure AD authentication enables simplified permission management and centralized identity management of database users and other Microsoft services	AuditIfNotExists, Disabled	1.0.0

IM-2: Manage application identities securely and automatically

Guidance: Azure Synapse Analytics supports managed identities for its Azure resources. Use managed identities with Azure Synapse Analytics instead of creating service principals to access other resources. Azure Synapse Analytics can natively authenticate to the Azure services or resources that support Azure AD authentication. It does this authentication through a predefined access grant rule, without using credentials that are hardcoded in source code or configuration files.

Responsibility: Shared

IM-3: Use Azure AD single sign-on (SSO) for application access

Guidance: Azure Synapse Analytics uses Azure Active Directory to provide identity and access management to:

Azure resources
Cloud applications
On-premises applications

This management includes enterprise identities, such as employees, and external identities, such as:

Partners
Vendors
Suppliers

With this arrangement, single sign-on (SSO) may manage and secure access to your organization's data and resources. The management may occur on-premises and in the cloud. Connect all your users, applications, and devices to Azure AD. You'll experience seamless, secure access, and greater visibility and control.

Understand Application SSO with Azure AD

Responsibility: Shared

IM-7: Eliminate unintended credential exposure

Guidance: Azure Synapse Analytics may allow customers to deploy or run the following entities that may have identities or secrets:

Code
Configurations
Persisted data

Implement Credential Scanner to identify credentials within those entities. Credential Scanner will also encourage moving discovered credentials to more secure locations, such as Azure Key Vault.

For GitHub, use the native secret scanning feature. This feature identifies credentials or other forms of secrets within the code.

Responsibility: Shared

Privileged Access

For more information, see the Azure Security Benchmark: Privileged Access.

PA-1: Protect and limit highly privileged users

Guidance: The most critical built-in roles for Azure AD are the Global Administrator and the Privileged Role Administrator:

Global Administrator or Company Administrator: Users with this role have access to all administrative features in Azure AD. This role also allows access to services that use Azure AD identities.
Privileged Role Administrator: Users with this role can manage role assignments in Azure AD and Azure AD Privileged Identity Management (PIM). This role also allows management of all aspects of PIM and administrative units.

Note: If you use custom roles with certain privileged permissions that are assigned, you might need to govern other critical roles. Also, you might apply similar controls to the administrator account of critical business assets.

Limit the number of highly privileged accounts or roles. Protect these accounts at an elevated level. Directly or indirectly, users with this privilege can read and modify every resource in your Azure environment.

Enable just-in-time (JIT) privileged access to Azure resources and Azure AD using Azure AD PIM. JIT grants temporary permissions to do privileged tasks only when users need it. PIM can also generate security alerts when there's suspicious or unsafe activity in your Azure AD organization.

Create standard operating procedures around the use of dedicated administrative accounts.

When you first deploy Azure SQL, specify an admin sign-in and an associated password for that sign-in. This administrative account is called Server admin. To identify the administrator accounts for a database, open the Azure portal. Then navigate to the properties tab of your server or managed instance. You can also configure an Azure AD admin account with full administrative permissions. This action is required if you want to enable Azure Active Directory authentication.

You may create more sign-ins and users with scoped administrative privileges. These sign-ins and users are added to the built-in Azure SQL admin roles for SQL authentication and Azure AD authentication accounts.

Responsibility: Shared

PA-3: Review and reconcile user access regularly

Guidance: To make sure that Azure AD accounts and their access are valid, Azure Synapse Analytics uses those accounts regularly to:

Manage its resources
Review user accounts
Access assignments

Use Azure AD and access reviews to review:

Group memberships
Access to enterprise applications
Role assignments

Azure AD reporting can provide logs to help discover stale accounts. Use Azure AD PIM to create access review report workflows. These workflows make the review process easier.

You can also configure Azure AD PIM to alert you when an excessive number of administrator accounts are created. Or configure Azure AD PIM to identify administrator accounts that are stale or improperly configured.

Note: Some Azure services support local users and roles that aren't managed through Azure AD. Manage these users separately.

When you use SQL authentication, create contained database users in the database. Place one or more database users into a custom database role. Apply specific permissions that are appropriate to that group of users.

You can manage your dedicated SQL Pools (formerly SQL DW) using built-in Azure RBAC roles. The roles available are:

SQL DB Contributor. This role lets you manage SQL databases, but not access them. Also, you can't manage their security-related policies or their parent SQL servers.
SQL Server Contributor. This role lets you manage SQL servers and databases, but not access them or their security-related policies.
SQL Security Manager. This role lets you manage the security-related policies of SQL servers and databases, but not access them.

For more information, read the following articles:

Responsibility: Shared

PA-6: Use privileged access workstations

Guidance: Secured, isolated workstations are critically important for the security of sensitive roles, such as:

Administrator
Developer
Critical service operator

Use highly secured user workstations or Azure Bastion for administrative tasks. To deploy a secure and managed user workstation for administrative tasks, use:

Azure AD
Microsoft Defender Advanced Threat Protection (ATP)
Microsoft Intune

You can centrally manage the secured workstations to enforce secured configuration, which includes:

Strong authentication
Software and hardware baselines
Restricted logical and network access

For more information, read the following articles:

Responsibility: Shared

PA-7: Follow just enough administration (least privilege principle)

Guidance: Azure Synapse Analytics is integrated with Azure RBAC to manage its resources. With Azure RBAC, you can manage Azure resource access through role assignments. You may assign these roles to:

Users
Groups
Service principals
Managed identities

There are predefined built-in roles for certain resources. These roles can be inventoried or queried through such tools as:

Azure CLI
Azure PowerShell
Azure portal

Always limit the privileges you assign to resources through Azure RBAC to what the roles require. This practice complements the just-in-time (JIT) approach of Azure AD PIM. Review this practice periodically.

Use built-in roles to give permissions. Only create custom roles when necessary.

When you first deploy Azure SQL, specify an admin sign-in and an associated password for that sign-in. This administrative account is called Server admin. To identify the administrator accounts for a database, open the Azure portal. Then navigate to the properties tab of your server or managed instance. You may also configure an Azure AD admin account with full administrative permissions. This action is required if you want to enable Azure Active Directory authentication.

When you use SQL authentication, create contained database users in the database. Place one or more database users into a built-in or custom database role. Add specific permissions for that role which are appropriate to that user or group of users.

Responsibility: Shared

PA-8: Choose approval process for Microsoft support

Guidance: Do you have a support scenario where Microsoft needs to access data that's related to the Azure SQL Database in your dedicated SQL pool? With Azure Customer Lockbox, there's an interface for you to review, approve, or reject data access requests.

Do you have a support scenario where Microsoft needs to access customer data? Azure Synapse Analytics supports Customer Lockbox to provide an interface for you to review, approve, or reject customer data access requests.

Understand Customer Lockbox

Responsibility: Shared

Data Protection

For more information, see the Azure Security Benchmark: Data Protection.

DP-1: Discover, classify, and label sensitive data

Guidance: Discover, classify, and label your sensitive data. Then design the appropriate controls to make sure your organization's technology systems store, process, and transmit sensitive information securely.

Use Azure Information Protection (and its associated scanning tool) for sensitive information within Office documents on:

Azure
On-premises
Microsoft 365
Other locations

With the help of Azure SQL Information Protection, classify and label information that's stored in Azure SQL Databases.

Data discovery and classification is built into Azure SQL and supports the following capabilities:

Discovery and recommendations. The classification engine scans your database and identifies columns that contain potentially sensitive data. It then provides you with an easy way to review and apply recommended classification through the Azure portal.
Labeling. How do you apply sensitivity-classification labels persistently to columns? Use new metadata attributes that have been added to the SQL Server database engine. You can then use this metadata for sensitivity-based auditing and protection scenarios.
Query result-set sensitivity. The sensitivity of a query result set is calculated in real time for auditing purposes.
Visibility. View the database-classification state in a detailed dashboard in the Azure portal. Download a report in Excel format to use for compliance and auditing purposes and other needs.

For more information, read the following article:

Data discovery and classification for dedicated SQL pools (formerly SQL DW)

Responsibility: Shared

Azure Policy built-in definitions - Microsoft.Sql:

Name _{(Azure portal)}	Description	Effect(s)	Version _(GitHub)
Sensitive data in your SQL databases should be classified	Microsoft Defender for Cloud monitors the data discovery and classification scan results for your SQL databases and provides recommendations to classify the sensitive data in your databases for better monitoring and security	AuditIfNotExists, Disabled	3.0.0-preview

DP-2: Protect sensitive data

Guidance: Use Azure RBAC to manage access to Azure SQL databases in your Synapse SQL pool. With the SQL Security Manager Azure RBAC built-in role, you may manage the security-related policies of SQL servers and databases, but not access them.

Authorization is controlled by your user account's database role memberships and object-level permissions. As a best practice, grant users the least privileges necessary.

Use the Azure Synapse SQL data discovery and classification feature. You can also set up a dynamic data masking (DDM) policy in the Azure portal. The DDM recommendations engine flags certain fields from your database. These fields are potentially sensitive fields that may be good candidates for masking.

By encrypting data at rest, transparent data encryption (TDE) helps protect Azure Synapse SQL against the threat of malicious offline activity. Without requiring changes to the application, TDE at rest does real-time encryption and decryption of:

The database
Associated backups
Transaction log files

In Azure, the default setting for TDE is to protect the data encryption key (DEK) with a built-in server certificate. You can instead use customer-managed TDE. Customer-managed TDE is also referred to as Bring Your Own Key (BYOK) support for TDE. In this scenario, the TDE protector that encrypts the DEK is a customer-managed asymmetric key. This asymmetric key is stored in a customer-owned and managed Azure Key Vault. (Azure Key Vault is Azure's cloud-based external key management system.) The asymmetric key never leaves the key vault.

Responsibility: Shared

Azure Policy built-in definitions - Microsoft.Sql:

Name _{(Azure portal)}	Description	Effect(s)	Version _(GitHub)
Microsoft Defender for SQL should be enabled for unprotected SQL Managed Instances	Audit each SQL Managed Instance without advanced data security.	AuditIfNotExists, Disabled	1.0.2
Transparent Data Encryption on SQL databases should be enabled	Transparent data encryption should be enabled to protect data-at-rest and meet compliance requirements	AuditIfNotExists, Disabled	2.0.0

DP-3: Monitor for unauthorized transfer of sensitive data

Guidance: Monitor the unauthorized transfer of data to locations that are outside of enterprise visibility and control. This process typically involves monitoring for anomalous activities (large or unusual transfers) that could indicate unauthorized data exfiltration.

With Microsoft Defender for Storage and Microsoft Defender for SQL, alert on an anomalous transfer of information. These anomalies might indicate unauthorized transfers of sensitive information.

Azure Information Protection (AIP) provides monitoring capabilities for information that's been classified and labeled.

If necessary to achieve data loss prevention (DLP), prevent data exfiltration by using a host-based DLP solution to enforce detective or preventative controls.

Advanced Threat Protection for Azure Synapse Analytics

Responsibility: Shared

Azure Policy built-in definitions - Microsoft.Sql:

Name _{(Azure portal)}	Description	Effect(s)	Version _(GitHub)
Microsoft Defender for SQL should be enabled for unprotected SQL Managed Instances	Audit each SQL Managed Instance without advanced data security.	AuditIfNotExists, Disabled	1.0.2

DP-4: Encrypt sensitive information in transit

Guidance: To complement access controls, protect data in transit against 'out of band' attacks (such as traffic capture) using encryption. Make sure attackers can't easily read or modify the data.

Azure Synapse Analytics supports data encryption in transit with TLS v1.2 or greater.

Although data encryption in transit is optional for traffic on private networks, it's critical for traffic on external and public networks. For HTTP traffic, make sure any clients connecting to your Azure resources can negotiate TLS v1.2 or greater. For remote management, use SSH (for Linux) or RDP/TLS (for Windows) instead of an unencrypted protocol. Disable obsolete versions of these entities:

SSL
TLS
SSH versions and protocols
Weak ciphers

By default, Azure provides encryption for data in transit between Azure data centers.

Responsibility: Shared

DP-5: Encrypt sensitive data at rest

Guidance: To complement access controls, Azure Synapse Analytics encrypts data at rest to protect against 'out of band' attacks (such as accessing underlying storage) using encryption. This practice helps ensure that attackers can't easily read or modify the data.

Azure provides encryption for data at rest by default. For highly sensitive data, you may implement extra encryption at rest on all Azure resources where available. Azure manages your encryption keys by default. But Azure also lets you manage your own keys (customer-managed keys) for certain Azure services to meet regulatory requirements.

By encrypting data at rest, TDE helps protect Azure Synapse SQL against the threat of malicious offline activity. Without requiring changes to the application, TDE at rest does real-time encryption and decryption of:

The database
Associated backups
Transaction log files

In Azure, the default setting for TDE is that the DEK is protected by a built-in server certificate. You can instead use customer-managed TDE, or BYOK support for TDE. The TDE protector that encrypts the DEK is a customer-managed asymmetric key in this scenario. This asymmetric key is stored in a customer-owned and managed Azure Key Vault, and it never leaves the key vault.

Responsibility: Shared

Azure Policy built-in definitions - Microsoft.Sql:

Name _{(Azure portal)}	Description	Effect(s)	Version _(GitHub)
SQL managed instances should use customer-managed keys to encrypt data at rest	Implementing Transparent Data Encryption (TDE) with your own key provides you with increased transparency and control over the TDE Protector, increased security with an HSM-backed external service, and promotion of separation of duties. This recommendation applies to organizations with a related compliance requirement.	AuditIfNotExists, Disabled	1.0.2
SQL servers should use customer-managed keys to encrypt data at rest	Implementing Transparent Data Encryption (TDE) with your own key provides increased transparency and control over the TDE Protector, increased security with an HSM-backed external service, and promotion of separation of duties. This recommendation applies to organizations with a related compliance requirement.	AuditIfNotExists, Disabled	2.0.1
Transparent Data Encryption on SQL databases should be enabled	Transparent data encryption should be enabled to protect data-at-rest and meet compliance requirements	AuditIfNotExists, Disabled	2.0.0

Asset Management

For more information, see the Azure Security Benchmark: Asset Management.

AM-1: Ensure security team has visibility into risks for assets

Guidance: Make sure security teams are granted Security Reader permissions in your Azure tenant and subscriptions. These permissions let those teams monitor for security risks using Microsoft Defender for Cloud.

Monitoring for security risks could be the responsibility of a central security team or a local team. That decision depends on how security team responsibilities are structured. But you must always aggregate security insights and risks centrally within an organization.

You can apply Security Reader permissions broadly to an entire tenant (Root Management Group) or scoped to management groups or specific subscriptions.

Note: More permissions might be necessary to get visibility into workloads and services.

Responsibility: Customer

AM-2: Ensure security team has access to asset inventory and metadata

Guidance: Make sure security teams have access to a continuously updated inventory of assets on Azure, such as Azure Synapse Analytics. Security teams often need this inventory to evaluate their organization's potential exposure to emerging risks. The inventory is also needed as an input to continuous security improvements. Create an Azure AD group to contain your organization's authorized security team. Then assign them read access to all Azure Synapse Analytics resources. This action can be done with a single high-level role assignment within your subscription.

Apply tags to your Azure resources, resource groups, and subscriptions to logically organize them into a taxonomy. Each tag consists of a name and a value pair. For example, you can apply the name "Environment" and the value "Production" to all the resources in production.

Use Azure Virtual Machine Inventory to automate the collection of information about software on Virtual Machines. In the Azure portal, these information items are available:

Software Name
Version
Publisher
Refresh Time

To get access to install dates and other information, enable guest-level diagnostics. Then bring the Windows Event Logs into a Log Analytics Workspace.

Azure Synapse Analytics doesn't allow running an application or the installation of software on its resources.

Responsibility: Shared

AM-3: Use only approved Azure services

Guidance: Use Azure Policy to audit and restrict which services users can provision in your environment. Use Azure Resource Graph to query for and discover resources within their subscriptions. You can also use Azure Monitor to create rules for triggering alerts when an unapproved service is detected.

Responsibility: Shared

AM-6: Use only approved applications in compute resources

Guidance: Not applicable; Azure Synapse Analytics doesn't deploy any customer-facing compute resources. It doesn't allow customers to install applications on the service.

Responsibility: Shared

Logging and Threat Detection

For more information, see the Azure Security Benchmark: Logging and Threat Detection.

LT-1: Enable threat detection for Azure resources

Guidance: For your Azure Synapse Analytics resources, use the Microsoft Defender for Cloud built-in threat detection capability and enable Microsoft Defender. Microsoft Defender for Azure Synapse Analytics provides an extra layer of security intelligence. It detects unusual and potentially harmful attempts to access or exploit your Azure Synapse Analytics resources.

You can define an auditing policy for a specific database. Or define it as a default server policy in Azure (which hosts Azure Synapse). A server policy applies to all existing and newly created databases on the server.

If you enable server auditing, it always applies to the database. The database will be audited, whatever the database auditing settings.

When you enable auditing, you can write the auditing to a log within:

Your Azure Storage account
Log Analytics workspace
Event Hubs

Forward any logs from Azure Synapse Analytics to your SIEM, which you can use to set up custom threat detections. Make sure you're monitoring different types of Azure assets for potential threats and anomalies. Focus on getting high-quality alerts to reduce false positives for analysts to sort through. Alerts can be sourced from log data, agents, or other data.

Responsibility: Shared

Azure Policy built-in definitions - Microsoft.Sql:

Name _{(Azure portal)}	Description	Effect(s)	Version _(GitHub)
Microsoft Defender for SQL should be enabled for unprotected SQL Managed Instances	Audit each SQL Managed Instance without advanced data security.	AuditIfNotExists, Disabled	1.0.2

LT-2: Enable threat detection for Azure identity and access management

Guidance: Azure AD provides the user logs listed below. For more sophisticated monitoring and analytics use cases, you can view the logs in Azure AD reporting. Or you can integrate the logs with Azure Monitor, Microsoft Sentinel, or other SIEM or monitoring tools.

Sign-ins. The sign-ins report provides information about the usage of managed applications and user sign-in activities.
Audit logs. Audit logs provide traceability for all changes done by various features within Azure AD. Examples of audit logs include changes made to any resources within Azure AD, like adding or removing:
- Users
- Apps
- Groups
- Roles
- Policies
Risky sign-ins. A risky sign-in indicates a sign-in attempt that might have been performed by someone who isn't the user account's legitimate owner.
Users flagged for risk. A risky user indicates a user account that might have been compromised.

Microsoft Defender for Cloud can also trigger alerts on certain suspicious activities. These activities include an excessive number of failed authentication attempts or deprecated accounts in the subscription. Besides the basic security hygiene monitoring, Microsoft Defender for Cloud's Threat Protection module can also collect more in-depth security alerts from:

Individual Azure compute resources (virtual machines, containers, or app service)
Data resources (SQL DB and storage)
Azure service layers

With this capability, you have visibility into account anomalies inside individual resources.

Responsibility: Shared

Azure Policy built-in definitions - Microsoft.Sql:

Name _{(Azure portal)}	Description	Effect(s)	Version _(GitHub)
Microsoft Defender for SQL should be enabled for unprotected SQL Managed Instances	Audit each SQL Managed Instance without advanced data security.	AuditIfNotExists, Disabled	1.0.2

LT-3: Enable logging for Azure network activities

Guidance: For security analysis, enable and collect:

NSG resource logs
NSG flow logs
Azure Firewall logs
Web Application Firewall (WAF) logs

Use the logs to support:

Incident investigations
Threat hunting
Security alert generation

You can send the flow logs to an Azure Monitor Log Analytics workspace. Then use Traffic Analytics to provide insights.

Azure Synapse Analytics logs all network traffic that it processes for customer access. Enable the network flow capability within your deployed offering resources.

Use Advanced Threat Protection (ATP) for Azure Synapse SQL. ATP detects anomalous activities that indicate unusual and potentially harmful attempts to access or exploit databases. ATP can trigger various alerts, such as:

"Potential SQL injection."
"Access from unusual location."

ATP is part of the Advanced data security (ADS) offering. It can be accessed and managed through the central SQL ADS portal.

Collect DNS query logs to help correlate other network data. Implement a third-party solution from Azure Marketplace for DNS logging, per your organization's need.

Responsibility: Shared

LT-4: Enable logging for Azure resources

Guidance: Activity logs, which are automatically available, contain all write operations (PUT, POST, and DELETE) for your Azure Synapse Analytics resources. Activity logs don't contain read operations (GET). Use activity logs to find an error when troubleshooting. Or use the logs to monitor how a user in your organization modified a resource.

Enable Azure resource logs for Azure Synapse Analytics. Use Microsoft Defender for Cloud and Azure Policy to enable resource logs and log data collecting. These logs can be critical for investigating security incidents and doing forensic exercises.

Azure Synapse Analytics also produces security audit logs. Enable these audit logs to track database events. You may write these events to an audit log within:

Your Azure storage account
Log Analytics workspace
Event Hubs

Define an auditing policy for a specific database. Or define it as a default server policy in Azure (which hosts the dedicated SQL pools).

Advanced Threat Protection for Azure Synapse Analytics-enabled SQL Server detects anomalous activities. These activities can indicate unusual and potentially harmful attempts to access or exploit databases. Advanced Threat Protection is part of the Microsoft Defender for SQL offering. That offering is a unified package for advanced SQL security capabilities. You can access and manage Advanced Threat Protection through the central Microsoft Defender for SQL portal.

Responsibility: Shared

Azure Policy built-in definitions - Microsoft.Sql:

Name _{(Azure portal)}	Description	Effect(s)	Version _(GitHub)
Auditing on SQL server should be enabled	Auditing on your SQL Server should be enabled to track database activities across all databases on the server and save them in an audit log.	AuditIfNotExists, Disabled	2.0.0

LT-5: Centralize security log management and analysis

Guidance: Centralize logging storage and analysis to enable correlation. For each log source, assign:

A data owner
Access guidance
Storage location
What tools are used to process and access the data
Data retention requirements

Integrate Azure activity logs into your central logging. Ingest logs through Azure Monitor to aggregate security data that are generated by:

Endpoint devices
Network resources
Other security systems

In Azure Monitor, use Log Analytics workspaces to query and do analytics. Then use Azure Storage accounts for long term and archival storage.

Also enable and onboard data to Microsoft Sentinel or a third-party SIEM.

Many organizations choose Microsoft Sentinel for 'hot' data that's used frequently. Those organizations choose Azure Storage for 'cold' data that's used less frequently.

Azure Synapse Analytics tracks database events. It writes these events to an audit log within one of these entities:

Your Azure storage account
Log Analytics workspace
Event Hubs

These audit logs help you maintain regulatory compliance and understand database activity. With the logs, you also gain insight into discrepancies and anomalies that could indicate business concerns or suspected security violations. For applications that may run on Azure Synapse Analytics, forward all security-related logs to your SIEM for centralized management.

Responsibility: Shared

LT-6: Configure log storage retention

Guidance: Do you have any storage accounts or Log Analytics workspaces that are used for storing Azure Synapse Analytics logs? Then set the log retention period according to your organization's compliance regulations.

Responsibility: Shared

Azure Policy built-in definitions - Microsoft.Sql:

Name _{(Azure portal)}	Description	Effect(s)	Version _(GitHub)
SQL servers with auditing to storage account destination should be configured with 90 days retention or higher	For incident investigation purposes, we recommend setting the data retention for your SQL Server' auditing to storage account destination to at least 90 days. Confirm that you are meeting the necessary retention rules for the regions in which you are operating. This is sometimes required for compliance with regulatory standards.	AuditIfNotExists, Disabled	3.0.0

LT-7: Use approved time synchronization sources

Guidance: Not applicable; Azure Synapse Analytics doesn't support configuring your own time synchronization sources.

Azure Synapse Analytics service relies on Microsoft time synchronization sources. It isn't exposed to customers for configuration.

Responsibility: Shared

Posture and Vulnerability Management

For more information, see the Azure Security Benchmark: Posture and Vulnerability Management.

PV-1: Establish secure configurations for Azure services

Guidance: With a blueprint definition in Azure Blueprints, automate the deployment and configuration of services and application environments, including:

Azure Resources Manager templates
Azure RBAC controls
Policies

Auditing for Azure Synapse Analytics tracks database events. It writes these events to an audit log within one of the following entities:

Your Azure storage account
Log Analytics workspace
Event Hubs

Define an auditing policy for a specific database. Or define it as a default server policy in Azure (which hosts dedicated SQL pools for Azure Synapse). Microsoft Defender provides a set of advanced SQL security capabilities, including SQL Vulnerability Assessment and Advanced Threat Protection.

Set up alerts for databases in Azure Synapse Analytics using the Azure portal.

Responsibility: Shared

PV-2: Sustain secure configurations for Azure services

Guidance: With Microsoft Defender for Cloud, monitor your configuration baseline. With the Azure Policy [Deny] and [DeployIfNotExists] effects, enforce secure configuration across Azure compute resources including VMs, containers, and others.

Define an SQL auditing policy for a specific database. Or define it as a default server policy in Azure (which hosts dedicated SQL pools). The default auditing policy includes all actions and a set of action groups. The actions and action groups will audit:

All queries and stored procedures executed against the database.
Successful and failed sign-ins.

For more information, read the following articles:

Responsibility: Shared

PV-3: Establish secure configurations for compute resources

Guidance: With Microsoft Defender for Cloud and Azure Policy, create secure configurations on all compute resources including VMs, containers, and others.

Responsibility: Customer

PV-6: Do software vulnerability assessments

Guidance: Microsoft does vulnerability management on the underlying systems that support Azure Synapse Analytics.

Responsibility: Microsoft

Azure Policy built-in definitions - Microsoft.Sql:

Name _{(Azure portal)}	Description	Effect(s)	Version _(GitHub)
SQL databases should have vulnerability findings resolved	Monitor vulnerability assessment scan results and recommendations for how to remediate database vulnerabilities.	AuditIfNotExists, Disabled	4.0.0
Vulnerability assessment should be enabled on SQL Managed Instance	Audit each SQL Managed Instance which doesn't have recurring vulnerability assessment scans enabled. Vulnerability assessment can discover, track, and help you remediate potential database vulnerabilities.	AuditIfNotExists, Disabled	1.0.1
Vulnerability assessment should be enabled on your SQL servers	Audit Azure SQL servers which do not have recurring vulnerability assessment scans enabled. Vulnerability assessment can discover, track, and help you remediate potential database vulnerabilities.	AuditIfNotExists, Disabled	2.0.0

PV-8: Conduct regular attack simulation

Guidance: As necessary, conduct penetration testing or red team activities on your Azure resources. Make sure you remediate all critical security findings.

To make sure your penetration tests don't violate Microsoft policies, follow the Microsoft Cloud Penetration Testing Rules of Engagement. Using Microsoft's strategy and execution of Red Teaming and live site penetration, test against Microsoft-managed cloud:

Infrastructure
Services
Applications

For more information, read the following articles:

Responsibility: Customer

Endpoint Security

For more information, see the Azure Security Benchmark: Endpoint Security.

ES-2: Use centrally managed modern antimalware software

Guidance: Protect your cloud service or its resources with a centrally managed modern antimalware software. Use a centrally managed endpoint antimalware solution. Make sure it can do real-time and periodic scanning.

Microsoft Defender for Cloud can automatically:

Identify the use of several popular antimalware solutions for your virtual machines (VMs).
Report the endpoint protection running status.
Make recommendations.

Microsoft Antimalware for Azure Cloud Services is the default antimalware for Windows VMs. For Linux VMs, use a third-party antimalware solution. Use Microsoft Defender for Cloud's Threat detection for data services to detect malware uploaded to Azure Storage accounts.

Responsibility: Customer

Backup and Recovery

For more information, see the Azure Security Benchmark: Backup and Recovery.

BR-1: Ensure regular automated backups

Guidance: A data warehouse snapshot creates a restore point. You can use this restore point to recover or copy your data warehouse to a previous state. Because a dedicated SQL pool is a distributed system, a data warehouse snapshot has many files that are located in Azure storage. Snapshots capture incremental changes from the data that's stored in your data warehouse. Snapshots of your dedicated SQL pool are automatically taken throughout the day. These snapshots create restore points that are available for seven days. (This retention period can't be changed.) SQL pool supports an eight-hour recovery point objective (RPO). In the primary region, you may restore your data warehouse from any snapshot within the past seven days. You can also manually trigger snapshots if necessary.

With user-defined restore points, manually trigger snapshots. This action creates restore points of your data warehouse before and after large changes. This capability makes sure restore points are logically consistent. Consistency provides more data protection if there are any workload interruptions or user errors, resulting in quick recovery time.

User-defined restore points are available for seven days and are automatically deleted on your behalf. You can't alter the retention period of user-defined restore points. 42 user-defined restore points are guaranteed at any point in time. Those restore points must be deleted before creating another restore point. You can trigger snapshots to create user-defined restore points through PowerShell or the Azure portal.

A geo-backup is created once a day to a paired data center. The RPO for a geo-restore is 24 hours. You can restore the geo-backup to a server in another region where dedicated SQL pool is supported. A geo-backup lets you restore your data warehouse if you can't access the restore points in your primary region. If you don't require geo-backups for your dedicated SQL pool, you may disable them. This action reduces the storage costs of disaster recovery.

If you're using a customer-managed key to encrypt your DEK, make sure your key is being backed up.

Back up and restore in dedicated SQL pools (formerly SQL DW)

Responsibility: Shared

BR-2: Encrypt backup data

Guidance: With restore points in a dedicated SQL pool, recover or copy your data warehouse to a previous state in the primary region. Use data warehouse geo-redundant backups to restore to another geographical region. Snapshots are a built-in feature that creates restore points. You don't have to enable this capability. However, keep the dedicated SQL pool in an active state for restore point creation.

What happens after you encrypt a dedicated SQL pool with TDE using a key from Key Vault? TDE also encrypts any newly generated backups with the same TDE protector. If the TDE protector is changed, old backups of the dedicated SQL Pool aren't updated to use the latest TDE protector.

How do you prepare to restore a backup that was encrypted with a TDE protector from Key Vault? Make sure the key material is available to the target server. Keep all old versions of the TDE protector in Key Vault, so dedicated SQL Pool backups can be restored.

Responsibility: Shared

BR-3: Validate all backups including customer-managed keys

Guidance: With dedicated SQL pool restore points, recover or copy your data warehouse to a previous state in the primary region. Use data warehouse geo-redundant backups to restore to a different geographical region.

When you drop a dedicated SQL pool, a final snapshot is created and saved for seven days. You may restore the dedicated SQL pool to the final restore point that was created at deletion. If the dedicated SQL pool is dropped in a paused state, no snapshot is taken. In that scenario, create a user-defined restore point before dropping the dedicated SQL pool.

Regularly make sure you can restore customer-managed keys that are backed up.

Responsibility: Shared

BR-4: Mitigate risk of lost keys

Guidance: Make sure you can prevent and recover from the loss of keys. Enable soft delete and purge protection in Azure Key Vault. This action protects keys against accidental or malicious deletion.

Enable soft delete and purge protection in Key Vault

Responsibility: Shared

Next steps

See the Azure Security Benchmark V2 overview
Learn more about Azure security baselines

Azure security baseline for Azure Synapse dedicated SQL pool (formerly SQL DW)

Network Security

NS-1: Implement security for internal traffic

NS-2: Connect private networks together

NS-3: Establish private network access to Azure services

NS-4: Protect applications and services from external network attacks

NS-6: Simplify network security rules

NS-7: Secure Domain Name Service (DNS)

Identity Management

IM-1: Standardize Azure Active Directory as the central identity and authentication system

IM-2: Manage application identities securely and automatically

IM-3: Use Azure AD single sign-on (SSO) for application access

IM-7: Eliminate unintended credential exposure

Privileged Access

PA-1: Protect and limit highly privileged users

PA-3: Review and reconcile user access regularly

PA-6: Use privileged access workstations

PA-7: Follow just enough administration (least privilege principle)

PA-8: Choose approval process for Microsoft support

Data Protection

DP-1: Discover, classify, and label sensitive data

DP-2: Protect sensitive data

DP-3: Monitor for unauthorized transfer of sensitive data

DP-4: Encrypt sensitive information in transit

DP-5: Encrypt sensitive data at rest

Asset Management

AM-1: Ensure security team has visibility into risks for assets

AM-2: Ensure security team has access to asset inventory and metadata

AM-3: Use only approved Azure services

AM-6: Use only approved applications in compute resources

Logging and Threat Detection

LT-1: Enable threat detection for Azure resources

LT-2: Enable threat detection for Azure identity and access management

LT-3: Enable logging for Azure network activities

LT-4: Enable logging for Azure resources

LT-5: Centralize security log management and analysis

LT-6: Configure log storage retention

LT-7: Use approved time synchronization sources

Posture and Vulnerability Management

PV-1: Establish secure configurations for Azure services

PV-2: Sustain secure configurations for Azure services

PV-3: Establish secure configurations for compute resources

PV-6: Do software vulnerability assessments

PV-8: Conduct regular attack simulation

Endpoint Security

ES-2: Use centrally managed modern antimalware software

Backup and Recovery

BR-1: Ensure regular automated backups

BR-2: Encrypt backup data

BR-3: Validate all backups including customer-managed keys

BR-4: Mitigate risk of lost keys

Next steps

Feedback

Additional resources

Additional resources