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

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.

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. Ensure that all Azure virtual networks follow an enterprise segmentation principle that aligns with the business risks. Any system that might incur higher risk for the organization should be isolated within its own virtual network and sufficiently secured with a network security group (NSG) and/or Azure Firewall.

Use Azure Security Center Adaptive Network Hardening to recommend network security group configurations that limit ports and source IPs based with the reference to external network traffic rules.

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

Use Azure Sentinel to discover the use of legacy insecure protocols such as SSL/TLSv1, SMBv1, LM/NTLMv1, wDigest, Unsigned LDAP Binds, and weak ciphers in Kerberos.

The minimal Transport Layer Security (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, and connections with TLS 1.0 are rejected.

To access Azure Synapse Analytics data warehouses from your local computer, ensure that the firewall on your network and local computer allow outgoing communication on TCP port 1433.

When "Deny public network access" is set to "Yes", only connections via private endpoints are allowed. When this setting is "No" (default), customers can connect by using either public endpoints (with IP-based firewall rules or with virtual-network-based firewall rules) or private endpoints (by using Azure Private Link), as outlined in the network access overview.

Responsibility: Shared

Azure Security Center monitoring: The Azure Security Benchmark is the default policy initiative for Security Center and is the foundation for Security Center's recommendations. The Azure Policy definitions related to this control are enabled automatically by Security Center. Alerts related to this control may require an Azure 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: Use Azure ExpressRoute or Azure virtual private network (VPN) to create private connections between Azure datacenters and on-premises infrastructure in a colocation environment. ExpressRoute connections don't go over the public internet, and they offer more reliability, faster speeds, and lower latencies than typical internet connections. For point-to-site VPN and site-to-site VPN, you can connect on-premises devices or networks to a virtual network using 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 and is kept on the Azure backbone network.

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

Responsibility: Shared

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

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: Use Azure Private Link to enable private access to Azure Synapse Analytics from your virtual networks without crossing the internet.

Private access is an additional defense in depth measure to the authentication and traffic security offered by Azure services.

You can also choose to deny public network access to the Azure SQL server that hosts your data warehouses. When enabled, this configuration ensures that only connections via Private Endpoints are allowed.

PolyBase and the COPY statement is commonly used to load data into Azure Synapse Analytics from Azure Storage accounts. Note that if the Azure Storage account that you're loading data from limits access only to a set of virtual network subnets via Private Endpoints, Service Endpoints, or IP-based firewalls, the connectivity from PolyBase and the COPY statement to the account will break.

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

Private access is an additional defense in-depth measure to the authentication and traffic security offered by Azure services.

Responsibility: Shared

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

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, and unsolicited and potentially malicious internet traffic. Use Azure Firewall to protect applications and services against potentially malicious traffic from the internet and other external locations. Protect your assets against DDoS attacks by enabling DDoS standard protection on your Azure virtual networks. Use Azure Security Center to detect misconfiguration risks to your network-related resources.

Azure Synapse Analytics is not intended to run web applications, and does not require you to configure any additional settings or deploy any extra network services to protect it from external network attacks targeting web applications.

Responsibility: Shared

Azure Security Center monitoring: None

NS-5: Deploy intrusion detection/intrusion prevention systems (IDS/IPS)

Guidance: Use Azure Firewall threat intelligence-based filtering to alert on and/or block traffic to and from known malicious IP addresses and domains. The IP addresses and domains are sourced from the Microsoft Threat Intelligence feed. When payload inspection is required, you can deploy a third-party intrusion detection/intrusion prevention system (IDS/IPS) from Azure Marketplace with payload inspection capabilities. Alternately, you can use host-based IDS/IPS or a host-based endpoint detection and response (EDR) solution in conjunction with or instead of network-based IDS/IPS.

Responsibility: Shared

Azure Security Center monitoring: None

NS-6: Simplify network security rules

Guidance: Use Azure Virtual Network Service Tags to define network access controls on network security groups or Azure Firewall configured for your Azure Synapse Analytics resources. You can use service tags in place of specific IP addresses when creating security rules. By specifying the service tag name in the appropriate source or destination field of a rule, you can allow or deny the traffic for the corresponding service. Microsoft manages the address prefixes encompassed by the service tag and automatically updates the service tag as addresses change.

When using a service endpoint for your Azure Synapse SQL pool, outbound to Azure SQL database Public IP addresses is required: Network Security Groups (NSGs) must be opened to Azure SQL Database IPs to allow connectivity. You can do this by using NSG service tags for Azure SQL Database.

Responsibility: Shared

Azure Security Center monitoring: None

NS-7: Secure Domain Name Service (DNS)

Guidance: Follow the best practices for DNS security to mitigate against common attacks like dangling DNS, DNS amplifications attacks, DNS poisoning and spoofing, etc.

When Azure DNS is used as your authoritative DNS service, ensure DNS zones and records are protected from accidental or malicious modification using Azure RBAC and resource locks.

The Azure SQL server that houses your data warehouses supports the use of DNS aliases to connect to it. PowerShell and REST APIs accept calls to create and manage DNS aliases for your logical SQL server name. A DNS alias can be used 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 having to find and edit 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, you can update the properties of the alias to point to the production server. No change to the client programs is necessary.

Responsibility: Shared

Azure Security Center monitoring: None

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. You should standardize Azure AD to govern your organization's identity and access management in:

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

Securing Azure AD should be a high priority in your organization's cloud security practice. Azure AD provides an identity secure score to help you assess identity security posture relative to Microsoft's best practice recommendations. Use the score to gauge how closely your configuration matches best practice recommendations, and to make improvements in your security posture.

Note: Azure AD supports external identities that allow users without a Microsoft account to 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. Azure AD supports connections from SQL Server Management Studio that use 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).

  1. SQL DB Contributor lets you manage SQL data warehouses, but not access to them. Also, you can't manage their security-related policies or their parent SQL servers.
  2. SQL Security Manager lets you manage the security-related policies of SQL servers and data warehouses, but not access to them.
  3. SQL Server Contributor lets you manage SQL servers and data warehouses, but not access to them, and not 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 the master database for user accounts linked to a login or stored in the database containing the user accounts not linked to a login. A login is an individual account in the master database, to which a user account in one or more databases can be linked. With a login, the credential information for the user account is stored with the login. A user account is an individual account in any database that may be, but does not have to be, linked to a login. With a user account that is not linked to a login, the credential information is stored with the user account.

Responsibility: Shared

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

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/resources that supports Azure AD authentication through a pre-defined access grant rule without using credentials hard coded in source code or configuration files.

Responsibility: Shared

Azure Security Center monitoring: None

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, and on-premises applications. This includes enterprise identities, such as employees, as well as external identities like partners, vendors, and suppliers. This enables single sign-on (SSO) to manage and secure access to your organization's data and resources on-premises and in the cloud. Connect all your users, applications, and devices to the Azure AD for seamless, secure access and greater visibility and control.

Responsibility: Shared

Azure Security Center monitoring: None

IM-4: Use strong authentication controls for all Azure Active Directory based access

Guidance: Azure Synapse Analytics uses Azure Active Directory (Azure AD), which supports strong authentication controls through multi-factor authentication (MFA) and strong passwordless methods.

  • Multi-factor authentication - Enable Azure AD MFA, and then follow Azure Security Center Identity and Access Management recommendations for best practices in your MFA setup. MFA can be enforced on all, select users, or at the per-user level based on sign-in conditions and risk factors.
  • Passwordless authentication - Three passwordless authentication options are available: Windows Hello for Business, Microsoft Authenticator app, and on-premises authentication methods such as smart cards.

For administrators and privileged users, ensure the highest level of the strong authentication method is used, followed by rolling out the appropriate strong authentication policy to other users.

Azure Synapse Analytics supports legacy password-based authentication such as Cloud-only accounts (user accounts created directly in the Azure) that have a baseline password policy, or Hybrid accounts (user accounts that come from on-premises Active Directory) that will follow the on-premises password policies. When using password-based authentication, Azure AD provides a password protection capability that prevents users from setting passwords that are easy to guess. Microsoft provides a global list of banned passwords that is updated based on telemetry, and customers can augment the list based on their needs (such as branding or cultural references). This password protection can be used for cloud-only and hybrid accounts.

Note: Authentication based on password credentials alone are susceptible to popular attack methods. For higher security, use strong authentication such as MFA and a strong password policy. For third-party applications and marketplace services that might have default passwords, you should change them upon the service initial setup.

Responsibility: Shared

Azure Security Center monitoring: None

IM-5: Monitor and alert on account anomalies

Guidance: Azure Synapse Analytics is integrated with Azure Active Directory, which provides the following data sources:

  • Sign-ins - The sign-ins report provides information about the usage of managed applications and user sign-in activities.
  • Audit logs - Provides traceability through logs for all changes done by various features within Azure AD. Examples of audit logs include changes made to any resource within Azure AD, like adding or removing users, apps, groups, roles, and policies.
  • Risky sign-ins - A risky sign-in is an indicator for a sign-in attempt that might have been performed by someone who is not the legitimate owner of a user account.
  • Users flagged for risk - A risky user is an indicator for a user account that might have been compromised.

These data sources can be integrated with Azure Monitor, Azure Sentinel, or third-party SIEM systems.

Azure Security Center can also alert you about certain suspicious activities, such as an excessive number of failed authentication attempts or deprecated accounts in the subscription.

Azure Advanced Threat Protection (ATP) is a security solution that can use Active Directory signals to identify, detect, and investigate advanced threats, compromised identities, and malicious insider actions.

Dedicated SQL Pools support 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 the master database for user accounts linked to a login or stored in the database containing the user accounts not linked to a login. Auditing for dedicated SQL pools(formerly SQL DW) tracks database events and writes them to an audit log in your Azure storage account, Log Analytics workspace, or Event Hubs for downstream processing and analysis.

Responsibility: Shared

Azure Security Center monitoring: None

IM-6: Restrict Azure resource access based on conditions

Guidance: Azure Synapse Analytics supports Azure Active Directory (Azure AD) conditional access for a more granular access control based on user-defined conditions, such as user logins from certain IP ranges will need to use multifactor authentication for login. Granular authentication session management policy can also be used for different use cases. These conditional access policies will only apply to user accounts that are authenticating to Azure AD to access and manage the Azure Synapse Analytics service, but they will not apply to service principals, keys, or tokens used to connect to your Azure Synapse Analytics resource.

Responsibility: Shared

Azure Security Center monitoring: None

IM-7: Eliminate unintended credential exposure

Guidance: Azure Synapse Analytics allows customers to deploy/run {code or configurations or persisted data} potentially with identities/secrets. It's recommended to implement Credential Scanner to identify credentials within {code or configurations or persisted data}. Credential Scanner will also encourage moving discovered credentials to more secure locations like Azure Key Vault.

For GitHub, you can use the native secret scanning feature to identify credentials or other forms of secrets within the code.

Responsibility: Shared

Azure Security Center monitoring: None

IM-8: Secure user access to legacy applications

Guidance: Ensure you have modern access controls and session monitoring for legacy applications and the data they store and process. While VPNs are commonly used to access legacy applications, they often have only basic access control and limited session monitoring.

Azure AD Application Proxy enables you to publish legacy on-premises applications to remote users with SSO while explicitly validating trustworthiness of both remote users and devices with Azure AD Conditional Access.

Alternatively, Microsoft Cloud App Security is a Cloud Access Security Broker (CASB) service that can provide controls for monitoring users application sessions and blocking actions (for both legacy on-premises applications and cloud software as a service (SaaS) applications).

Responsibility: Shared

Azure Security Center monitoring: None

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, as users assigned to these two roles can delegate administrator roles:

  • Global Administrator / Company Administrator: Users with this role have access to all administrative features in Azure AD, as well as services that use Azure AD identities.
  • Privileged Role Administrator: Users with this role can manage role assignments in Azure AD, as well as within Azure AD Privileged Identity Management (PIM). In addition, this role allows management of all aspects of PIM and administrative units.

Note: You might have other critical roles that need to be governed if you use custom roles with certain privileged permissions assigned. You might also want to apply similar controls to the administrator account of critical business assets.

You should limit the number of highly privileged accounts or roles and protect these accounts at an elevated level. Users with this privilege can directly or indirectly read and modify every resource in your Azure environment.

You can enable just-in-time (JIT) privileged access to Azure resources and Azure AD using Azure AD PIM. JIT grants temporary permissions to perform privileged tasks only when users need it. PIM can also generate security alerts when there is 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, you specify an admin login and an associated password for that login. This administrative account is called Server admin. You can identify the administrator accounts for a database by opening the Azure portal and navigating to the properties tab of your server or managed instance. You can also configure an Azure AD admin account with full administrative permissions, this is required if you want to enable Azure Active Directory authentication.

In addition to the built-in Azure SQL admin roles for SQL authentication and Azure AD authentication accounts, you may create additional logins and users with scoped administrative privileges.

Responsibility: Shared

Azure Security Center monitoring: None

PA-2: Restrict administrative access to business-critical systems

Guidance: Azure Synapse Analytics uses Azure role-based access control (Azure RBAC) to isolate access to business-critical systems by restricting which accounts are granted privileged access to the subscriptions and management groups they are in.

Ensure that you also restrict access to the management, identity, and security systems that have administrative access to your business-critical access controls, such as Active Directory Domain Controllers (DCs), security tools, and system management tools with agents installed on business-critical systems. Attackers who compromise these management and security systems can immediately weaponize them to compromise business-critical assets.

All types of access controls should be aligned to your enterprise segmentation strategy to ensure consistent access control.

For management operations, use the built-in Azure role-based access control (Azure RBAC) roles which must be explicitly assigned. Use the Azure AD PowerShell module to perform ad-hoc queries to discover accounts that are members of administrative groups.

Authorization is controlled by your user account's database role memberships and object-level permissions. As a best practice, create custom roles when needed. Add users to the role with the least privileges required to do their job function. Do not assign permissions directly to users. The server admin account is a member of the built-in db_owner role, which has extensive permissions and should only be granted to few users with administrative duties. For applications, use the EXECUTE AS to specify the execution context of the called module or use Application Roles with limited permissions. This practice ensures that the application that connects to the database has the least privileges needed by the application. Following these best practices also fosters separation of duties.

Responsibility: Shared

Azure Security Center monitoring: None

PA-3: Review and reconcile user access regularly

Guidance: Azure Synapse Analytics uses Azure Active Directory (Azure AD) accounts to manage its resources, review user accounts, and access assignments regularly to ensure the accounts and their access are valid. You can use Azure AD and access reviews to review group memberships, access to enterprise applications, and role assignments. Azure AD reporting can provide logs to help discover stale accounts. You can also use Azure AD Privileged Identity Management (PIM) to create access review report workflows to facilitate the review process.

In addition, Azure AD PIM can also be configured to alert you when an excessive number of administrator accounts are created, and to identify administrator accounts that are stale or improperly configured.

Note: Some Azure services support local users and roles which are not managed through Azure AD. You will need to manage these users separately.

When using SQL authentication, create contained database users in the database. Ensure that you place one or more database users into a custom database role with specific permissions 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:

  1. SQL DB Contributor- Lets you manage SQL databases, but not access to them. Also, you can't manage their security-related policies or their parent SQL servers.
  2. SQL Server Contributor- Lets you manage SQL servers and databases, but not access to them, and not their security-related policies.
  3. SQL Security Manager- Lets you manage the security-related policies of SQL servers and databases, but not access to them.

Responsibility: Shared

Azure Security Center monitoring: None

PA-4: Set up emergency access in Azure AD

Guidance: Azure Synapse Analytics uses Azure Active Directory (Azure AD) to manage its resources. To prevent being accidentally locked out of your Azure AD organization, set up an emergency access account for access when normal administrative accounts cannot be used. Emergency access accounts are usually highly privileged, and they should not be assigned to specific individuals. Emergency access accounts are limited to emergency or 'break glass' scenarios where normal administrative accounts can't be used.

You should ensure that the credentials (such as password, certificate, or smart card) for emergency access accounts are kept secure and known only to individuals who are authorized to use them only in an emergency.

When you first deploy Azure SQL, you specify an admin login and an associated password for that login. This administrative account is called Server admin. You can identify the administrator accounts for a database by opening the Azure portal and navigating to the properties tab of your server. If Azure AD accounts are unavailable, SQL authentication accounts can be used to access and manage dedicated SQL Pools.

Responsibility: Shared

Azure Security Center monitoring: None

PA-5: Automate entitlement management

Guidance: Azure Synapse Analytics is integrated with Azure Active Directory (Azure AD) to manage its resources. Use Azure AD entitlement management features to automate access request workflows, including access assignments, reviews, and expiration. Dual or multi-stage approval is also supported.

When using SQL authentication, create contained database users in the database. Ensure that you place one or more database users into a custom database role with specific permissions appropriate to that group of users. SQL Server audit lets you create server audits, which can contain server audit specifications for server level events, and database audit specifications for database level events. Audited events can be written to the event logs or to audit files.

Responsibility: Shared

Azure Security Center monitoring: None

PA-6: Use privileged access workstations

Guidance: Secured, isolated workstations are critically important for the security of sensitive roles like administrator, developer, and critical service operator. Use highly secured user workstations and/or Azure Bastion for administrative tasks. Use Azure Active Directory (Azure AD), Microsoft Defender Advanced Threat Protection (ATP), and/or Microsoft Intune to deploy a secure and managed user workstation for administrative tasks. The secured workstations can be centrally managed to enforce secured configuration including strong authentication, software and hardware baselines, and restricted logical and network access.

Responsibility: Shared

Azure Security Center monitoring: None

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

Guidance: Azure Synapse Analytics is integrated with Azure role-based access control (Azure RBAC) to manage its resources. Azure RBAC allows you to manage Azure resource access through role assignments. You can assign these roles to users, groups service principals, and managed identities. There are pre-defined built-in roles for certain resources, and these roles can be inventoried or queried through tools such as Azure CLI, Azure PowerShell, or the Azure portal. The privileges you assign to resources through the Azure RBAC should be always limited to what is required by the roles. This complements the just-in-time (JIT) approach of Azure AD Privileged Identity Management (PIM) and should be reviewed periodically.

Use built-in roles to allocate permissions and only create custom roles when required.

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

When using SQL authentication, create contained database users in the database. Ensure that you place one or more database users into a built-in or custom database role with specific permissions appropriate to that user or group of users.

Responsibility: Shared

Azure Security Center monitoring: None

PA-8: Choose approval process for Microsoft support

Guidance: In support scenarios where Microsoft needs to access data related to the Azure SQL Database in your dedicated SQL pool, Azure Customer Lockbox provides an interface for you to review and approve or reject data access requests.

In support scenarios where Microsoft needs to access customer data, Azure Synapse Analytics supports Customer Lockbox to provide an interface for you to review and approve or reject customer data access requests.

Responsibility: Shared

Azure Security Center monitoring: None

Data Protection

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

DP-1: Discovery, classify and label sensitive data

Guidance: Discover, classify, and label your sensitive data so that you can design the appropriate controls to ensure sensitive information is stored, processed, and transmitted securely by the organization's technology systems.

Use Azure Information Protection (and its associated scanning tool) for sensitive information within Office documents on Azure, on-premises, Microsoft 365, and other locations.

You can use Azure SQL Information Protection to assist in the classification and labeling of information 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 via the Azure portal.

Labeling- You can apply sensitivity-classification labels persistently to columns by using new metadata attributes that have been added to the SQL Server database engine. This metadata can then be used 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- You can view the database-classification state in a detailed dashboard in the Azure portal. Also, you can download a report in Excel format to use for compliance and auditing purposes and other needs.

Responsibility: Shared

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

Azure Policy built-in definitions - Microsoft.Sql:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Sensitive data in your SQL databases should be classified Azure Security Center 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 role-based access control (RBAC) to manage access to Azure SQL databases in your Synapse SQL pool. The SQL Security Manager Azure RBAC built-in role lets you manage the security-related policies of SQL servers and databases, but not access to them. Authorization is controlled by your user account's database role memberships and object-level permissions. As a best practice, you should grant users the least privileges necessary.

Use the Azure Synapse SQL Data Discovery and Classification feature. Additionally, you can set up a dynamic data masking (DDM) policy in the Azure portal. The DDM recommendations engine flags certain fields from your database as potentially sensitive fields which may be good candidates for masking.

Transparent data encryption (TDE) helps protect Azure Synapse SQL against the threat of malicious offline activity by encrypting data at rest. It performs real-time encryption and decryption of the database, associated backups, and transaction log files at rest without requiring changes to the application. In Azure, the default setting for TDE is that the DEK is protected by a built-in server certificate. Alternatively, you can use customer-managed TDE, 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, which is stored in a customer-owned and managed Azure Key Vault (Azure's cloud-based external key management system) and never leaves the key vault.

Responsibility: Shared

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

Azure Policy built-in definitions - Microsoft.Sql:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Azure 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 for unauthorized transfer of data to locations outside of enterprise visibility and control. This typically involves monitoring for anomalous activities (large or unusual transfers) that could indicate unauthorized data exfiltration.

Azure Defender for Storage and Azure Defender for SQL can alert on an anomalous transfer of information that might indicate unauthorized transfers of sensitive information.

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

If required for compliance of data loss prevention (DLP), you can use a host-based DLP solution to enforce detective and/or preventative controls to prevent data exfiltration.

Responsibility: Shared

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

Azure Policy built-in definitions - Microsoft.Sql:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Azure 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, data in transit should be protected against 'out of band' attacks (such as traffic capture) using encryption to ensure that attackers cannot easily read or modify the data.

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

While this is optional for traffic on private networks, this is critical for traffic on external and public networks. For HTTP traffic, ensure that 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. Obsolete SSL, TLS, SSH versions and protocols, and weak ciphers should be disabled.

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

Responsibility: Shared

Azure Security Center monitoring: None

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 helps ensure that attackers cannot easily read or modify the data.

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

Transparent data encryption (TDE) helps protect Azure Synapse SQL against the threat of malicious offline activity by encrypting data at rest. It performs real-time encryption and decryption of the database, associated backups, and transaction log files at rest without requiring changes to the application. In Azure, the default setting for TDE is that the DEK is protected by a built-in server certificate. Alternatively, you can use customer-managed TDE, 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, which is stored in a customer-owned and managed Azure Key Vault (Azure's cloud-based external key management system) and never leaves the key vault.

Responsibility: Shared

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

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: Ensure security teams are granted Security Reader permissions in your Azure tenant and subscriptions so they can monitor for security risks using Azure Security Center.

Depending on how security team responsibilities are structured, monitoring for security risks could be the responsibility of a central security team or a local team. That said, security insights and risks must always be aggregated centrally within an organization.

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

Note: Additional permissions might be required to get visibility into workloads and services.

Responsibility: Customer

Azure Security Center monitoring: None

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

Guidance: Ensure that security teams have access to a continuously updated inventory of assets on Azure, like Azure Synapse Analytics. Security teams often need this inventory to evaluate their organization's potential exposure to emerging risks, and as an input to continuous security improvements. Create an Azure Active Directory (Azure AD) group to contain your organization's authorized security team and assign them read access to all Azure Synapse Analytics resources, which can be simplified by 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. Software Name, Version, Publisher, and Refresh Time are available from the Azure portal. To get access to install dates and other information, enable guest-level diagnostics and bring the Windows Event Logs into a Log Analytics Workspace.

Azure Synapse Analytics does not allow running an application or the installation of software on its resources. Describe any other features in your offering which allows or supports this functionality, as applicable.

Responsibility: Shared

Azure Security Center monitoring: None

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 to trigger alerts when a non-approved service is detected.

Responsibility: Shared

Azure Security Center monitoring: None

AM-4: Ensure security of asset lifecycle management

Guidance: Establish or update security policies that address asset lifecycle management processes for potentially high impact modifications. These modifications include but are not limited to: identity providers and access, data sensitivity, network configuration, and administrative privilege assignment. Outline any high-impact configurations that the customer should be aware of.

Remove Azure resources when they are no longer needed.

Responsibility: Shared

Azure Security Center monitoring: None

AM-5: Limit users' ability to interact with Azure Resource Manager

Guidance: Use Azure Conditional Access to limit users' ability to interact with Azure Resources Manager by configuring "Block access" for the "Microsoft Azure Management" App.

Responsibility: Shared

Azure Security Center monitoring: None

AM-6: Use only approved applications in compute resources

Guidance: Not applicable; Azure Synapse Analytics does not deploy any customer facing compute resources or does not allow customers to install applications on the service.

Responsibility: Shared

Azure Security Center monitoring: None

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: Use the Azure Security Center built-in threat detection capability and enable Azure Defender (formerly Azure Advanced Threat Protection) for your Azure Synapse Analytics resources. Azure Defender for Azure Synapse Analytics provides an additional layer of security intelligence that detects unusual and potentially harmful attempts to access or exploit your Azure Synapse Analytics resources.

An auditing policy can be defined for a specific database or 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 server auditing is enabled, it always applies to the database. The database will be audited, regardless of the database auditing settings.

When you enable auditing, you can write them to an audit log in your Azure Storage Account, Log Analytics workspace, or Event Hubs.

Forward any logs from Azure Synapse Analytics to your SIEM, which can be used to set up custom threat detections. Ensure that you are 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 Security Center monitoring: The Azure Security Benchmark is the default policy initiative for Security Center and is the foundation for Security Center's recommendations. The Azure Policy definitions related to this control are enabled automatically by Security Center. Alerts related to this control may require an Azure Defender plan for the related services.

Azure Policy built-in definitions - Microsoft.Sql:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Azure 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 Active Directory (Azure AD) provides the following user logs, which can be viewed in Azure AD reporting or integrated with Azure Monitor, Azure Sentinel, or other SIEM/monitoring tools for more sophisticated monitoring and analytics use cases:

  • Sign-ins - The sign-ins report provides information about the usage of managed applications and user sign-in activities.
  • Audit logs - Provides traceability through logs 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, and policies.
  • Risky sign-ins - A risky sign-in is an indicator for a sign-in attempt that might have been performed by someone who is not the legitimate owner of a user account.
  • Users flagged for risk - A risky user is an indicator for a user account that might have been compromised.

Azure Security Center can also trigger alerts on certain suspicious activities, such as excessive number of failed authentication attempts or deprecated accounts in the subscription. In addition to the basic security hygiene monitoring, Azure Security Center's Threat Protection module can also collect more in-depth security alerts from individual Azure compute resources (virtual machines, containers, app service), data resources (SQL DB and storage), and Azure service layers. This capability allows you to have visibility on account anomalies inside individual resources.

Responsibility: Shared

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

Azure Policy built-in definitions - Microsoft.Sql:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Azure 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: Enable and collect network security group (NSG) resource logs, NSG flow logs, Azure Firewall logs, and Web Application Firewall (WAF) logs for security analysis to support incident investigations, threat hunting, and security alert generation. You can send the flow logs to an Azure Monitor Log Analytics workspace and 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 indicating unusual and potentially harmful attempts to access or exploit databases and it can trigger various alerts, such as, "Potential SQL injection," and, "Access from unusual location." ATP is part of the Advanced data security (ADS) offering and can be accessed and managed via the central SQL ADS portal.

Ensure that you are collecting DNS query logs to assist in correlating other network data. Implement a third-party solution from Azure Marketplace for DNS logging as per your organization's need.

Responsibility: Shared

Azure Security Center monitoring: None

LT-4: Enable logging for Azure resources

Guidance: Activity logs, which are automatically available, contain all write operations (PUT, POST, DELETE) for your Azure Synapse Analytics resources except read operations (GET). Activity logs can be used to find an error when troubleshooting or to monitor how a user in your organization modified a resource.

Enable Azure resource logs for Azure Synapse Analytics. You can use Azure Security Center and Azure Policy to enable resource logs and log data collecting. These logs can be critical for investigating security incidents and performing forensic exercises.

Azure Synapse Analytics also produces security audit logs. Enable these audit logs to track database events and writes them to an audit log in your Azure storage account, Log Analytics workspace, or Event Hubs. An auditing policy can be defined for a specific database or 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 indicating unusual and potentially harmful attempts to access or exploit databases. Advanced Threat Protection is part of the Azure Defender for SQL offering, which is a unified package for advanced SQL security capabilities. Advanced Threat Protection can be accessed and managed via the central Azure Defender for SQL portal.

Responsibility: Shared

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

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, ensure that you have assigned a data owner, access guidance, storage location, what tools are used to process and access the data, and data retention requirements.

Ensure that you are integrating Azure activity logs into your central logging. Ingest logs via Azure Monitor to aggregate security data generated by endpoint devices, network resources, and other security systems. In Azure Monitor, use Log Analytics workspaces to query and perform analytics, and use Azure Storage accounts for long term and archival storage.

In addition, enable and onboard data to Azure Sentinel or a third-party SIEM.

Many organizations choose to use Azure Sentinel for 'hot' data that is used frequently and Azure Storage for 'cold' data that is used less frequently.

Auditing for Azure SQL Azure Synapse Analytics tracks database events and writes them to an audit log in your Azure storage account, Log Analytics workspace, or Event Hubs. These audit logs help you maintain regulatory compliance, understand database activity, and 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

Azure Security Center monitoring: None

LT-6: Configure log storage retention

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

Responsibility: Shared

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

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 does not support configuring your own time synchronization sources.

Azure Synapse Analytics service relies on Microsoft time synchronization sources, and is not exposed to customers for configuration.

Responsibility: Shared

Azure Security Center monitoring: None

Incident Response

For more information, see the Azure Security Benchmark: Incident Response.

IR-1: Preparation – update incident response process for Azure

Guidance: Ensure your organization has processes to respond to security incidents, has updated these processes for Azure, and is regularly exercising them to ensure readiness.

Responsibility: Customer

Azure Security Center monitoring: None

IR-2: Preparation – setup incident notification

Guidance: Set up security incident contact information in Azure Security Center. This contact information is used by Microsoft to contact you if the Microsoft Security Response Center (MSRC) discovers that your data has been accessed by an unlawful or unauthorized party. You also have options to customize incident alert and notification in different Azure services based on your incident response needs.

Responsibility: Customer

Azure Security Center monitoring: None

IR-3: Detection and analysis – create incidents based on high quality alerts

Guidance: Ensure you have a process to create high-quality alerts and measure the quality of alerts. This allows you to learn lessons from past incidents and prioritize alerts for analysts, so they don't waste time on false positives.

High-quality alerts can be built based on experience from past incidents, validated community sources, and tools designed to generate and clean up alerts by fusing and correlating diverse signal sources.

Azure Security Center provides high-quality alerts across many Azure assets. You can use the ASC data connector to stream the alerts to Azure Sentinel. Azure Sentinel lets you create advanced alert rules to generate incidents automatically for an investigation.

Export your Azure Security Center alerts and recommendations using the export feature to help identify risks to Azure resources. Export alerts and recommendations either manually or in an ongoing, continuous fashion.

Responsibility: Customer

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

Azure Policy built-in definitions - Microsoft.Sql:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Azure 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

IR-4: Detection and analysis – investigate an incident

Guidance: Ensure analysts can query and use diverse data sources as they investigate potential incidents, to build a full view of what happened. Diverse logs should be collected to track the activities of a potential attacker across the kill chain to avoid blind spots. You should also ensure insights and learnings are captured for other analysts and for future historical reference.

The data sources for investigation include the centralized logging sources that are already being collected from the in-scope services and running systems, but can also include:

  • Network data - use network security groups' flow logs, Azure Network Watcher, and Azure Monitor to capture network flow logs and other analytics information.

  • Snapshots of running systems:

    • Use Azure virtual machine's snapshot capability to create a snapshot of the running system's disk.

    • Use the operating system's native memory dump capability to create a snapshot of the running system's memory.

    • Use the snapshot feature of the Azure services or your software's own capability to create snapshots of the running systems.

Azure Sentinel provides extensive data analytics across virtually any log source and a case management portal to manage the full lifecycle of incidents. Intelligence information during an investigation can be associated with an incident for tracking and reporting purposes.

Responsibility: Customer

Azure Security Center monitoring: None

IR-5: Detection and analysis – prioritize incidents

Guidance: Provide context to analysts on which incidents to focus on first based on alert severity and asset sensitivity.

Azure Security Center assigns a severity to each alert to help you prioritize which alerts should be investigated first. The severity is based on how confident Security Center is in the finding or the analytics used to issue the alert, as well as the confidence level that there was malicious intent behind the activity that led to the alert.

Additionally, mark resources using tags and create a naming system to identify and categorize Azure resources, especially those processing sensitive data. It is your responsibility to prioritize the remediation of alerts based on the criticality of the Azure resources and environment where the incident occurred.

Responsibility: Customer

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

Azure Policy built-in definitions - Microsoft.Sql:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Azure 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

IR-6: Containment, eradication and recovery – automate the incident handling

Guidance: Automate manual repetitive tasks to speed up response time and reduce the burden on analysts. Manual tasks take longer to execute, slowing each incident and reducing how many incidents an analyst can handle. Manual tasks also increase analyst fatigue, which increases the risk of human error that causes delays, and degrades the ability of analysts to focus effectively on complex tasks.

Use workflow automation features in Azure Security Center and Azure Sentinel to automatically trigger actions or run a playbook to respond to incoming security alerts. The playbook takes actions, such as sending notifications, disabling accounts, and isolating problematic networks.

Responsibility: Customer

Azure Security Center monitoring: None

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: You can use Azure Blueprints to automate deployment and configuration of services and application environments including Azure Resources Manager templates, Azure RBAC controls, and policies, in a single blueprint definition.

Auditing for Azure Synapse Analytics tracks database events and writes them to an audit log in your Azure storage account, Log Analytics workspace, or Event Hubs. An auditing policy can be defined for a specific database or as a default server policy in Azure (which hosts dedicated SQL pools- Azure Synapse). Azure Defender provides a set of advanced SQL security capabilities, including SQL Vulnerability Assessment and Advanced Threat Protection.

You can use Azure Blueprints to automate deployment and configuration of services and application environments including Azure Resources Manager templates, Azure RBAC controls, and policies, in a single blueprint definition.

You can set up alerts for databases in Azure Synapse Analytics using the Azure portal.

Responsibility: Shared

Azure Security Center monitoring: None

PV-2: Sustain secure configurations for Azure services

Guidance: Use Azure Security Center to monitor your configuration baseline and enforce using Azure Policy [deny] and [deploy if not exist] to enforce secure configuration across Azure compute resources including VMs, containers, and others.

A SQL auditing policy can be defined for a specific database or 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, which will audit all the queries and stored procedures executed against the database, as well as successful and failed logins.

Responsibility: Shared

Azure Security Center monitoring: None

PV-3: Establish secure configurations for compute resources

Guidance: Use Azure Security Center and Azure Policy to establish secure configurations on all compute resources including VMs, containers, and others.

Responsibility: Customer

Azure Security Center monitoring: None

PV-6: Perform software vulnerability assessments

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

Responsibility: Microsoft

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

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 required, conduct penetration testing or red team activities on your Azure resources and ensure remediation of all critical security findings.

Follow the Microsoft Cloud Penetration Testing Rules of Engagement to ensure your penetration tests are not in violation of Microsoft policies. Use Microsoft's strategy and execution of Red Teaming and live site penetration testing against Microsoft-managed cloud infrastructure, services, and applications.

Responsibility: Customer

Azure Security Center monitoring: None

Endpoint Security

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

ES-2: Use centrally managed modern anti-malware software

Guidance: Protect your {offering name} or its resources with a centrally managed modern anti-malware software.

  • Use a centrally managed endpoint anti-malware solution capable of real-time and periodic scanning.

  • Azure Security Center can automatically identify the use of several popular anti-malware solutions for your virtual machines (VMs), report the endpoint protection running status, and then make recommendations.

  • Microsoft Antimalware for Azure Cloud Services is the default anti-malware for Windows VMs. For Linux VMs, use a third-party anti-malware solution. You can use Azure Security Center's Threat detection for data services to detect malware uploaded to Azure Storage accounts.

  • How to configure Microsoft Antimalware for Cloud Services and Virtual Machines

  • Supported endpoint protection solutions

Responsibility: Customer

Azure Security Center monitoring: None

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 leverage to recover or copy your data warehouse to a previous state. Since dedicated SQL pool is a distributed system, a data warehouse snapshot consists of many files that are located in Azure storage. Snapshots capture incremental changes from the data stored in your data warehouse. Snapshots of your dedicated SQL pool are automatically taken throughout the day creating restore points that are available for seven days. This retention period cannot be changed. SQL pool supports an eight-hour recovery point objective (RPO). You can restore your data warehouse in the primary region from any one of the snapshots taken in the past seven days. Note that you can also manually trigger snapshots if necessary.

User-Defined Restore Points enable you to manually trigger snapshots to create restore points of your data warehouse before and after large modifications. This capability ensures that restore points are logically consistent, which provides additional data protection in case of any workload interruptions or user errors for quick recovery time. User-defined restore points are available for seven days and are automatically deleted on your behalf. You cannot change the retention period of user-defined restore points. 42 user-defined restore points are guaranteed at any point in time so they 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 per 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 any other region where dedicated SQL pool is supported. A geo-backup ensures you can restore data warehouse in case you cannot access the restore points in your primary region. If you do not require geo-backups for your dedicated SQL pool, you can disable them and save on disaster recovery storage costs.

If you are using a customer-managed key to encrypt your Database Encryption Key, ensure your key is being backed up.

Responsibility: Shared

Azure Security Center monitoring: None

BR-2: Encrypt backup data

Guidance: Use dedicated SQL pool restore points to 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. Snapshots are a built-in feature that creates restore points. You do not have to enable this capability. However, the dedicated SQL pool should be in an active state for restore point creation.

Once a dedicated SQL Pool is encrypted with TDE using a key from Key Vault, any newly generated backups are also encrypted with the same TDE protector. When the TDE protector is changed, old backups of the dedicated SQL Pool are not updated to use the latest TDE protector.

To restore a backup encrypted with a TDE protector from Key Vault, make sure that the key material is available to the target server. Therefore, we recommend that you keep all the old versions of the TDE protector in key vault, so dedicated SQL Pool backups can be restored.

Responsibility: Shared

Azure Security Center monitoring: None

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

Guidance: Use dedicated SQL pool restore points to 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 can restore the dedicated SQL pool to the final restore point created at deletion. If the dedicated SQL pool is dropped in a paused state, no snapshot is taken. In that scenario, make sure to create a user-defined restore point before dropping the dedicated SQL pool.

Periodically ensure that you can restore backed-up customer-managed keys.

Responsibility: Shared

Azure Security Center monitoring: None

BR-4: Mitigate risk of lost keys

Guidance: Ensure that you have measures in place to prevent and recover from the loss of keys. Enable soft delete and purge protection in Azure Key Vault to protect keys against accidental or malicious deletion.

Responsibility: Shared

Azure Security Center monitoring: None

Governance and Strategy

For more information, see the Azure Security Benchmark: Governance and Strategy.

GS-1: Define asset management and data protection strategy

Guidance: Ensure you document and communicate a clear strategy for continuous monitoring and protection of systems and data. Prioritize discovery, assessment, protection, and monitoring of business-critical data and systems.

This strategy should include documented guidance, policy, and standards for the following elements:

  • Data classification standard in accordance with the business risks
  • Security organization visibility into risks and asset inventory
  • Security organization approval of Azure services for use
  • Security of assets through their lifecycle
  • Required access control strategy in accordance with organizational data classification
  • Use of Azure native and third-party data protection capabilities
  • Data encryption requirements for in-transit and at-rest use cases
  • Appropriate cryptographic standards

For more information, see the following references:

Responsibility: Customer

Azure Security Center monitoring: None

GS-2: Define enterprise segmentation strategy

Guidance: Establish an enterprise-wide strategy to segmenting access to assets using a combination of identity, network, application, subscription, management group, and other controls.

Carefully balance the need for security separation with the need to enable daily operation of the systems that need to communicate with each other and access data.

Ensure that the segmentation strategy is implemented consistently across control types including network security, identity and access models, and application permission/access models, and human process controls.

Responsibility: Customer

Azure Security Center monitoring: None

GS-3: Define security posture management strategy

Guidance: Continuously measure and mitigate risks to your individual assets and the environment they are hosted in. Prioritize high value assets and highly-exposed attack surfaces, such as published applications, network ingress and egress points, user and administrator endpoints, etc.

Responsibility: Customer

Azure Security Center monitoring: None

GS-4: Align organization roles, responsibilities, and accountabilities

Guidance: Ensure that you document and communicate a clear strategy for roles and responsibilities in your security organization. Prioritize providing clear accountability for security decisions, educating everyone on the shared responsibility model, and educate technical teams on technology to secure the cloud.

Responsibility: Customer

Azure Security Center monitoring: None

GS-5: Define network security strategy

Guidance: Establish an Azure network security approach as part of your organization's overall security access control strategy.

This strategy should include documented guidance, policy, and standards for the following elements:

  • Centralized network management and security responsibility
  • Virtual network segmentation model aligned with the enterprise segmentation strategy
  • Remediation strategy in different threat and attack scenarios
  • Internet edge and ingress and egress strategy
  • Hybrid cloud and on-premises interconnectivity strategy
  • Up-to-date network security artifacts (such as network diagrams, reference network architecture)

For more information, see the following references:

Responsibility: Customer

Azure Security Center monitoring: None

GS-6: Define identity and privileged access strategy

Guidance: Establish an Azure identity and privileged access approaches as part of your organization's overall security access control strategy.

This strategy should include documented guidance, policy, and standards for the following elements:

  • A centralized identity and authentication system and its interconnectivity with other internal and external identity systems
  • Strong authentication methods in different use cases and conditions
  • Protection of highly privileged users
  • Anomaly user activities monitoring and handling
  • User identity and access review and reconciliation process

For more information, see the following references:

Responsibility: Customer

Azure Security Center monitoring: None

GS-7: Define logging and threat response strategy

Guidance: Establish a logging and threat response strategy to rapidly detect and remediate threats while meeting compliance requirements. Prioritize providing analysts with high-quality alerts and seamless experiences so that they can focus on threats rather than integration and manual steps.

This strategy should include documented guidance, policy, and standards for the following elements:

  • The security operations (SecOps) organization's role and responsibilities
  • A well-defined incident response process aligning with NIST or another industry framework
  • Log capture and retention to support threat detection, incident response, and compliance needs
  • Centralized visibility of and correlation information about threats, using SIEM, native Azure capabilities, and other sources
  • Communication and notification plan with your customers, suppliers, and public parties of interest
  • Use of Azure native and third-party platforms for incident handling, such as logging and threat detection, forensics, and attack remediation and eradication
  • Processes for handling incidents and post-incident activities, such as lessons learned and evidence retention

For more information, see the following references:

Responsibility: Customer

Azure Security Center monitoring: None

Next steps