Data security recommendations
This article lists all the data security recommendations you might see in Microsoft Defender for Cloud.
The recommendations that appear in your environment are based on the resources that you're protecting and on your customized configuration.
To learn about actions that you can take in response to these recommendations, see Remediate recommendations in Defender for Cloud.
Tip
If a recommendation description says No related policy, usually it's because that recommendation is dependent on a different recommendation.
For example, the recommendation Endpoint protection health failures should be remediated relies on the recommendation that checks whether an endpoint protection solution is installed (Endpoint protection solution should be installed). The underlying recommendation does have a policy. Limiting policies to only foundational recommendations simplifies policy management.
Azure data recommendations
(Enable if required) Azure Cosmos DB accounts should use customer-managed keys to encrypt data at rest
Description: Recommendations to use customer-managed keys for encryption of data at rest are not assessed by default, but are available to enable for applicable scenarios. Data is encrypted automatically using platform-managed keys, so the use of customer-managed keys should only be applied when obligated by compliance or restrictive policy requirements. To enable this recommendation, navigate to your Security Policy for the applicable scope, and update the Effect parameter for the corresponding policy to audit or enforce the use of customer-managed keys. Learn more in Manage security policies. Use customer-managed keys to manage the encryption at rest of your Azure Cosmos DB. By default, the data is encrypted at rest with service-managed keys, but customer-managed keys (CMK) are commonly required to meet regulatory compliance standards. CMKs enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more about CMK encryption at https://aka.ms/cosmosdb-cmk. (Related policy: Azure Cosmos DB accounts should use customer-managed keys to encrypt data at rest).
Severity: Low
(Enable if required) Azure Machine Learning workspaces should be encrypted with a customer-managed key (CMK)
Description: Recommendations to use customer-managed keys for encryption of data at rest are not assessed by default, but are available to enable for applicable scenarios. Data is encrypted automatically using platform-managed keys, so the use of customer-managed keys should only be applied when obligated by compliance or restrictive policy requirements. To enable this recommendation, navigate to your Security Policy for the applicable scope, and update the Effect parameter for the corresponding policy to audit or enforce the use of customer-managed keys. Learn more in Manage security policies. Manage encryption at rest of your Azure Machine Learning workspace data with customer-managed keys (CMK). By default, customer data is encrypted with service-managed keys, but CMKs are commonly required to meet regulatory compliance standards. CMKs enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more about CMK encryption at https://aka.ms/azureml-workspaces-cmk. (Related policy: Azure Machine Learning workspaces should be encrypted with a customer-managed key (CMK)).
Severity: Low
(Enable if required) MySQL servers should use customer-managed keys to encrypt data at rest
Description: Recommendations to use customer-managed keys for encryption of data at rest are not assessed by default, but are available to enable for applicable scenarios. Data is encrypted automatically using platform-managed keys, so the use of customer-managed keys should only be applied when obligated by compliance or restrictive policy requirements. To enable this recommendation, navigate to your Security Policy for the applicable scope, and update the Effect parameter for the corresponding policy to audit or enforce the use of customer-managed keys. Learn more in Manage security policies. Use customer-managed keys to manage the encryption at rest of your MySQL servers. By default, the data is encrypted at rest with service-managed keys, but customer-managed keys (CMK) are commonly required to meet regulatory compliance standards. CMKs enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. (Related policy: Bring your own key data protection should be enabled for MySQL servers).
Severity: Low
(Enable if required) PostgreSQL servers should use customer-managed keys to encrypt data at rest
Description: Recommendations to use customer-managed keys for encryption of data at rest are not assessed by default, but are available to enable for applicable scenarios. Data is encrypted automatically using platform-managed keys, so the use of customer-managed keys should only be applied when obligated by compliance or restrictive policy requirements. To enable this recommendation, navigate to your Security Policy for the applicable scope, and update the Effect parameter for the corresponding policy to audit or enforce the use of customer-managed keys. Learn more in Manage security policies. Use customer-managed keys to manage the encryption at rest of your PostgreSQL servers. By default, the data is encrypted at rest with service-managed keys, but customer-managed keys (CMK) are commonly required to meet regulatory compliance standards. CMKs enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. (Related policy: Bring your own key data protection should be enabled for PostgreSQL servers).
Severity: Low
(Enable if required) SQL managed instances should use customer-managed keys to encrypt data at rest
Description: Recommendations to use customer-managed keys for encryption of data at rest are not assessed by default, but are available to enable for applicable scenarios. Data is encrypted automatically using platform-managed keys, so the use of customer-managed keys should only be applied when obligated by compliance or restrictive policy requirements. To enable this recommendation, navigate to your Security Policy for the applicable scope, and update the Effect parameter for the corresponding policy to audit or enforce the use of customer-managed keys. Learn more in Manage security policies. 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. (Related policy: SQL managed instances should use customer-managed keys to encrypt data at rest).
Severity: Low
(Enable if required) SQL servers should use customer-managed keys to encrypt data at rest
Description: Recommendations to use customer-managed keys for encryption of data at rest are not assessed by default, but are available to enable for applicable scenarios. Data is encrypted automatically using platform-managed keys, so the use of customer-managed keys should only be applied when obligated by compliance or restrictive policy requirements. To enable this recommendation, navigate to your Security Policy for the applicable scope, and update the Effect parameter for the corresponding policy to audit or enforce the use of customer-managed keys. Learn more in Manage security policies. 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. (Related policy: SQL servers should use customer-managed keys to encrypt data at rest).
Severity: Low
(Enable if required) Storage accounts should use customer-managed key (CMK) for encryption
Description: Recommendations to use customer-managed keys for encryption of data at rest are not assessed by default, but are available to enable for applicable scenarios. Data is encrypted automatically using platform-managed keys, so the use of customer-managed keys should only be applied when obligated by compliance or restrictive policy requirements. To enable this recommendation, navigate to your Security Policy for the applicable scope, and update the Effect parameter for the corresponding policy to audit or enforce the use of customer-managed keys. Learn more in Manage security policies. Secure your storage account with greater flexibility using customer-managed keys (CMKs). When you specify a CMK, that key is used to protect and control access to the key that encrypts your data. Using CMKs provides additional capabilities to control rotation of the key encryption key or cryptographically erase data. (Related policy: Storage accounts should use customer-managed key (CMK) for encryption).
Severity: Low
All advanced threat protection types should be enabled in SQL managed instance advanced data security settings
Description: It is recommended to enable all advanced threat protection types on your SQL managed instances. Enabling all types protects against SQL injection, database vulnerabilities, and any other anomalous activities. (No related policy)
Severity: Medium
All advanced threat protection types should be enabled in SQL server advanced data security settings
Description: It is recommended to enable all advanced threat protection types on your SQL servers. Enabling all types protects against SQL injection, database vulnerabilities, and any other anomalous activities. (No related policy)
Severity: Medium
API Management services should use a virtual network
Description: Azure Virtual Network deployment provides enhanced security, isolation, and allows you to place your API Management service in a non-internet routable network that you control access to. These networks can then be connected to your on-premises networks using various VPN technologies, which enable access to your backend services within the network and/or on-premises. The developer portal and API gateway can be configured to be accessible either from the Internet or only within the virtual network. (Related policy: API Management services should use a virtual network).
Severity: Medium
App Configuration should use private link
Description: Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your app configuration instances instead of the entire service, you'll also be protected against data leakage risks. Learn more at: https://aka.ms/appconfig/private-endpoint. (Related policy: App Configuration should use private link).
Severity: Medium
Audit retention for SQL servers should be set to at least 90 days
Description: Audit SQL servers configured with an auditing retention period of less than 90 days. (Related policy: SQL servers should be configured with 90 days auditing retention or higher.)
Severity: Low
Auditing on SQL server should be enabled
Description: Enable auditing on your SQL Server to track database activities across all databases on the server and save them in an audit log. (Related policy: Auditing on SQL server should be enabled).
Severity: Low
Auto provisioning of the Log Analytics agent should be enabled on subscriptions
Description: To monitor for security vulnerabilities and threats, Microsoft Defender for Cloud collects data from your Azure virtual machines. Data is collected by the Log Analytics agent, formerly known as the Microsoft Monitoring Agent (MMA), which reads various security-related configurations and event logs from the machine and copies the data to your Log Analytics workspace for analysis. We recommend enabling auto provisioning to automatically deploy the agent to all supported Azure VMs and any new ones that are created. (Related policy: Auto provisioning of the Log Analytics agent should be enabled on your subscription).
Severity: Low
Azure Cache for Redis should reside within a virtual network
Description: Azure Virtual Network (VNet) deployment provides enhanced security and isolation for your Azure Cache for Redis, as well as subnets, access control policies, and other features to further restrict access. When an Azure Cache for Redis instance is configured with a VNet, it is not publicly addressable and can only be accessed from virtual machines and applications within the VNet. (Related policy: Azure Cache for Redis should reside within a virtual network).
Severity: Medium
Azure Database for MySQL should have an Azure Active Directory administrator provisioned
Description: Provision an Azure AD administrator for your Azure Database for MySQL to enable Azure AD authentication. Azure AD authentication enables simplified permission management and centralized identity management of database users and other Microsoft services (Related policy: An Azure Active Directory administrator should be provisioned for MySQL servers).
Severity: Medium
Azure Database for PostgreSQL should have an Azure Active Directory administrator provisioned
Description: Provision an Azure AD administrator for your Azure Database for PostgreSQL to enable Azure AD authentication. Azure AD authentication enables simplified permission management and centralized identity management of database users and other Microsoft services
(Related policy: An Azure Active Directory administrator should be provisioned for PostgreSQL servers).
Severity: Medium
Azure Cosmos DB accounts should have firewall rules
Description: Firewall rules should be defined on your Azure Cosmos DB accounts to prevent traffic from unauthorized sources. Accounts that have at least one IP rule defined with the virtual network filter enabled are deemed compliant. Accounts disabling public access are also deemed compliant. (Related policy: Azure Cosmos DB accounts should have firewall rules).
Severity: Medium
Azure Event Grid domains should use private link
Description: Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your Event Grid domains instead of the entire service, you'll also be protected against data leakage risks. Learn more at: https://aka.ms/privateendpoints. (Related policy: Azure Event Grid domains should use private link).
Severity: Medium
Azure Event Grid topics should use private link
Description: Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your topics instead of the entire service, you'll also be protected against data leakage risks. Learn more at: https://aka.ms/privateendpoints. (Related policy: Azure Event Grid topics should use private link).
Severity: Medium
Azure Machine Learning workspaces should use private link
Description: Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your Azure Machine Learning workspaces instead of the entire service, you'll also be protected against data leakage risks. Learn more at: https://aka.ms/azureml-workspaces-privatelink. (Related policy: Azure Machine Learning workspaces should use private link).
Severity: Medium
Azure SignalR Service should use private link
Description: Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your SignalR resources instead of the entire service, you'll also be protected against data leakage risks. Learn more at: https://aka.ms/asrs/privatelink. (Related policy: Azure SignalR Service should use private link).
Severity: Medium
Azure Spring Cloud should use network injection
Description: Azure Spring Cloud instances should use virtual network injection for the following purposes: 1. Isolate Azure Spring Cloud from Internet. 2. Enable Azure Spring Cloud to interact with systems in either on premises data centers or Azure service in other virtual networks. 3. Empower customers to control inbound and outbound network communications for Azure Spring Cloud. (Related policy: Azure Spring Cloud should use network injection).
Severity: Medium
SQL servers should have an Azure Active Directory administrator provisioned
Description: Provision an Azure AD 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. (Related policy: An Azure Active Directory administrator should be provisioned for SQL servers).
Severity: High
Azure Synapse Workspace authentication mode should be Azure Active Directory Only
Description: Azure Synapse Workspace authentication mode should be Azure Active Directory Only Azure Active Directory only authentication methods improves security by ensuring that Synapse Workspaces exclusively require Azure AD identities for authentication. Learn more. (Related policy: Synapse Workspaces should use only Azure Active Directory identities for authentication).
Severity: Medium
Code repositories should have code scanning findings resolved
Description: Defender for DevOps has found vulnerabilities in code repositories. To improve the security posture of the repositories, it is highly recommended to remediate these vulnerabilities. (No related policy)
Severity: Medium
Code repositories should have Dependabot scanning findings resolved
Description: Defender for DevOps has found vulnerabilities in code repositories. To improve the security posture of the repositories, it is highly recommended to remediate these vulnerabilities. (No related policy)
Severity: Medium
Code repositories should have infrastructure as code scanning findings resolved
Description: Defender for DevOps has found infrastructure as code security configuration issues in repositories. The issues shown below have been detected in template files. To improve the security posture of the related cloud resources, it is highly recommended to remediate these issues. (No related policy)
Severity: Medium
Code repositories should have secret scanning findings resolved
Description: Defender for DevOps has found a secret in code repositories. This should be remediated immediately to prevent a security breach. Secrets found in repositories can be leaked or discovered by adversaries, leading to compromise of an application or service. For Azure DevOps, the Microsoft Security DevOps CredScan tool only scans builds on which it has been configured to run. Therefore, results might not reflect the complete status of secrets in your repositories. (No related policy)
Severity: High
Cognitive Services accounts should enable data encryption
Description: This policy audits any Cognitive Services accounts that are not using data encryption. For each account with storage, you should enable data encryption with either customer managed or Microsoft managed key. (Related policy: Cognitive Services accounts should enable data encryption).
Severity: Low
Cognitive Services accounts should use customer owned storage or enable data encryption
Description: This policy audits any Cognitive Services account not using customer owned storage nor data encryption. For each Cognitive Services account with storage, use either customer owned storage or enable data encryption. Aligns with Microsoft Cloud Security Benchmark. (Related policy: Cognitive Services accounts should use customer owned storage or enable data encryption.)
Severity: Low
Diagnostic logs in Azure Data Lake Store should be enabled
Description: Enable logs and retain them for up to a year. This enables you to recreate activity trails for investigation purposes when a security incident occurs or your network is compromised. (Related policy: Diagnostic logs in Azure Data Lake Store should be enabled).
Severity: Low
Diagnostic logs in Data Lake Analytics should be enabled
Description: Enable logs and retain them for up to a year. This enables you to recreate activity trails for investigation purposes when a security incident occurs or your network is compromised. (Related policy: Diagnostic logs in Data Lake Analytics should be enabled).
Severity: Low
Email notification for high severity alerts should be enabled
Description: To ensure the relevant people in your organization are notified when there is a potential security breach in one of your subscriptions, enable email notifications for high severity alerts in Defender for Cloud. (Related policy: Email notification for high severity alerts should be enabled).
Severity: Low
Email notification to subscription owner for high severity alerts should be enabled
Description: To ensure your subscription owners are notified when there is a potential security breach in their subscription, set email notifications to subscription owners for high severity alerts in Defender for Cloud. (Related policy: Email notification to subscription owner for high severity alerts should be enabled).
Severity: Medium
Enforce SSL connection should be enabled for MySQL database servers
Description: Azure Database for MySQL supports connecting your Azure Database for MySQL server to client applications using Secure Sockets Layer (SSL). Enforcing SSL connections between your database server and your client applications helps protect against 'man in the middle' attacks by encrypting the data stream between the server and your application. This configuration enforces that SSL is always enabled for accessing your database server. (Related policy: Enforce SSL connection should be enabled for MySQL database servers).
Severity: Medium
Enforce SSL connection should be enabled for PostgreSQL database servers
Description: Azure Database for PostgreSQL supports connecting your Azure Database for PostgreSQL server to client applications using Secure Sockets Layer (SSL). Enforcing SSL connections between your database server and your client applications helps protect against 'man in the middle' attacks by encrypting the data stream between the server and your application. This configuration enforces that SSL is always enabled for accessing your database server. (Related policy: Enforce SSL connection should be enabled for PostgreSQL database servers).
Severity: Medium
Function apps should have vulnerability findings resolved
Description: Runtime vulnerability scanning for functions scans your function apps for security vulnerabilities and exposes detailed findings. Resolving the vulnerabilities can greatly improve your serverless applications security posture and protect them from attacks. (No related policy)
Severity: High
Geo-redundant backup should be enabled for Azure Database for MariaDB
Description: Azure Database for MariaDB allows you to choose the redundancy option for your database server. It can be set to a geo-redundant backup storage in which the data is not only stored within the region in which your server is hosted, but is also replicated to a paired region to provide recovery options in case of a region failure. Configuring geo-redundant storage for backup is only allowed when creating a server. (Related policy: Geo-redundant backup should be enabled for Azure Database for MariaDB).
Severity: Low
Geo-redundant backup should be enabled for Azure Database for MySQL
Description: Azure Database for MySQL allows you to choose the redundancy option for your database server. It can be set to a geo-redundant backup storage in which the data is not only stored within the region in which your server is hosted, but is also replicated to a paired region to provide recovery options in case of a region failure. Configuring geo-redundant storage for backup is only allowed when creating a server. (Related policy: Geo-redundant backup should be enabled for Azure Database for MySQL).
Severity: Low
Geo-redundant backup should be enabled for Azure Database for PostgreSQL
Description: Azure Database for PostgreSQL allows you to choose the redundancy option for your database server. It can be set to a geo-redundant backup storage in which the data is not only stored within the region in which your server is hosted, but is also replicated to a paired region to provide recovery options in case of a region failure. Configuring geo-redundant storage for backup is only allowed when creating a server. (Related policy: Geo-redundant backup should be enabled for Azure Database for PostgreSQL).
Severity: Low
GitHub repositories should have Code scanning enabled
Description: GitHub uses code scanning to analyze code in order to find security vulnerabilities and errors in code. Code scanning can be used to find, triage, and prioritize fixes for existing problems in your code. Code scanning can also prevent developers from introducing new problems. Scans can be scheduled for specific days and times, or scans can be triggered when a specific event occurs in the repository, such as a push. If code scanning finds a potential vulnerability or error in code, GitHub displays an alert in the repository. A vulnerability is a problem in a project's code that could be exploited to damage the confidentiality, integrity, or availability of the project. (No related policy)
Severity: Medium
GitHub repositories should have Dependabot scanning enabled
Description: GitHub sends Dependabot alerts when it detects vulnerabilities in code dependencies that affect repositories. A vulnerability is a problem in a project's code that could be exploited to damage the confidentiality, integrity, or availability of the project or other projects that use its code. Vulnerabilities vary in type, severity, and method of attack. When code depends on a package that has a security vulnerability, this vulnerable dependency can cause a range of problems. (No related policy)
Severity: Medium
GitHub repositories should have Secret scanning enabled
Description: GitHub scans repositories for known types of secrets, to prevent fraudulent use of secrets that were accidentally committed to repositories. Secret scanning will scan the entire Git history on all branches present in the GitHub repository for any secrets. Examples of secrets are tokens and private keys that a service provider can issue for authentication. If a secret is checked into a repository, anyone who has read access to the repository can use the secret to access the external service with those privileges. Secrets should be stored in a dedicated, secure location outside the repository for the project. (No related policy)
Severity: High
Microsoft Defender for Azure SQL Database servers should be enabled
Description: Microsoft Defender for SQL is a unified package that provides advanced SQL security capabilities. It includes functionality for surfacing and mitigating potential database vulnerabilities, detecting anomalous activities that could indicate a threat to your database, and discovering and classifying sensitive data.
Protections from this plan are charged as shown on the Defender plans page. If you don't have any Azure SQL Database servers in this subscription, you won't be charged. If you later create Azure SQL Database servers on this subscription, they'll automatically be protected and charges will begin. Learn about the pricing details per region.
Learn more in Introduction to Microsoft Defender for SQL. (Related policy: Azure Defender for Azure SQL Database servers should be enabled).
Severity: High
Microsoft Defender for Resource Manager should be enabled
Description: Microsoft Defender for Resource Manager automatically monitors the resource management operations in your organization. Defender for Cloud detects threats and alerts you about suspicious activity. Learn more in Introduction to Microsoft Defender for Resource Manager. Enabling this Defender plan results in charges. Learn about the pricing details per region on Defender for Cloud's pricing page: Defender for Cloud Pricing. (No related policy)
Severity: High
Microsoft Defender for SQL should be enabled for unprotected Azure SQL servers
Description: Microsoft Defender for SQL is a unified package that provides advanced SQL security capabilities. It surfaces and mitigates potential database vulnerabilities, and detects anomalous activities that could indicate a threat to your database. Microsoft Defender for SQL is billed as shown on pricing details per region. (Related policy: Advanced data security should be enabled on your SQL servers).
Severity: High
Microsoft Defender for SQL should be enabled for unprotected SQL Managed Instances
Description: Microsoft Defender for SQL is a unified package that provides advanced SQL security capabilities. It surfaces and mitigates potential database vulnerabilities, and detects anomalous activities that could indicate a threat to your database. Microsoft Defender for SQL is billed as shown on pricing details per region. (Related policy: Advanced data security should be enabled on SQL Managed Instance).
Severity: High
Network Watcher should be enabled
Description: Network Watcher is a regional service that enables you to monitor and diagnose conditions at a network scenario level in, to, and from Azure. Scenario level monitoring enables you to diagnose problems at an end-to-end network level view. Network diagnostic and visualization tools available with Network Watcher help you understand, diagnose, and gain insights to your network in Azure. (Related policy: Network Watcher should be enabled).
Severity: Low
Private endpoint connections on Azure SQL Database should be enabled
Description: Private endpoint connections enforce secure communication by enabling private connectivity to Azure SQL Database. (Related policy: Private endpoint connections on Azure SQL Database should be enabled).
Severity: Medium
Public network access on Azure SQL Database should be disabled
Description: 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. (Related policy: Public network access on Azure SQL Database should be disabled).
Severity: Medium
Public network access should be disabled for Cognitive Services accounts
Description: This policy audits any Cognitive Services account in your environment with public network access enabled. Public network access should be disabled so that only connections from private endpoints are allowed. (Related policy: Public network access should be disabled for Cognitive Services accounts).
Severity: Medium
Public network access should be disabled for MariaDB servers
Description: Disable the public network access property to improve security and ensure your Azure Database for MariaDB can only be accessed from a private endpoint. This configuration strictly disables access from any public address space outside of Azure IP range, and denies all logins that match IP or virtual network-based firewall rules. (Related policy: Public network access should be disabled for MariaDB servers).
Severity: Medium
Public network access should be disabled for MySQL servers
Description: Disable the public network access property to improve security and ensure your Azure Database for MySQL can only be accessed from a private endpoint. This configuration strictly disables access from any public address space outside of Azure IP range, and denies all logins that match IP or virtual network-based firewall rules. (Related policy: Public network access should be disabled for MySQL servers).
Severity: Medium
Public network access should be disabled for PostgreSQL servers
Description: Disable the public network access property to improve security and ensure your Azure Database for PostgreSQL can only be accessed from a private endpoint. This configuration disables access from any public address space outside of Azure IP range, and denies all logins that match IP or virtual network-based firewall rules. (Related policy: Public network access should be disabled for PostgreSQL servers).
Severity: Medium
Redis Cache should allow access only via SSL
Description: Enable only connections via SSL to Redis Cache. Use of secure connections ensures authentication between the server and the service and protects data in transit from network layer attacks such as man-in-the-middle, eavesdropping, and session-hijacking. (Related policy: Only secure connections to your Azure Cache for Redis should be enabled).
Severity: High
SQL databases should have vulnerability findings resolved
Description: SQL Vulnerability assessment scans your database for security vulnerabilities, and exposes any deviations from best practices such as misconfigurations, excessive permissions, and unprotected sensitive data. Resolving the vulnerabilities found can greatly improve your database security posture. Learn more (Related policy: Vulnerabilities on your SQL databases should be remediated).
Severity: High
SQL managed instances should have vulnerability assessment configured
Description: Vulnerability assessment can discover, track, and help you remediate potential database vulnerabilities. (Related policy: Vulnerability assessment should be enabled on SQL Managed Instance).
Severity: High
SQL servers on machines should have vulnerability findings resolved
Description: SQL Vulnerability assessment scans your database for security vulnerabilities, and exposes any deviations from best practices such as misconfigurations, excessive permissions, and unprotected sensitive data. Resolving the vulnerabilities found can greatly improve your database security posture. Learn more (Related policy: Vulnerabilities on your SQL servers on machine should be remediated).
Severity: High
SQL servers should have an Azure Active Directory administrator provisioned
Description: Provision an Azure AD 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. (Related policy: An Azure Active Directory administrator should be provisioned for SQL servers).
Severity: High
SQL servers should have vulnerability assessment configured
Description: Vulnerability assessment can discover, track, and help you remediate potential database vulnerabilities. (Related policy: Vulnerability assessment should be enabled on your SQL servers).
Severity: High
Storage account should use a private link connection
Description: Private links enforce secure communication, by providing private connectivity to the storage account (Related policy: Storage account should use a private link connection).
Severity: Medium
Storage accounts should be migrated to new Azure Resource Manager resources
Description: To benefit from new capabilities in Azure Resource Manager, you can migrate existing deployments from the Classic deployment model. Resource Manager enables security enhancements such as: stronger access control (RBAC), better auditing, ARM-based deployment and governance, access to managed identities, access to key vault for secrets, Azure AD-based authentication, and support for tags and resource groups for easier security management. Learn more (Related policy: Storage accounts should be migrated to new Azure Resource Manager resources).
Severity: Low
Storage accounts should prevent shared key access
Description: Audit requirement of Azure Active Directory (Azure AD) to authorize requests for your storage account. By default, requests can be authorized with either Azure Active Directory credentials, or by using the account access key for Shared Key authorization. Of these two types of authorization, Azure AD provides superior security and ease of use over shared Key, and is recommended by Microsoft. (Related policy: policy)
Severity: Medium
Storage accounts should restrict network access using virtual network rules
Description: Protect your storage accounts from potential threats using virtual network rules as a preferred method instead of IP-based filtering. Disabling IP-based filtering prevents public IPs from accessing your storage accounts. (Related policy: Storage accounts should restrict network access using virtual network rules).
Severity: Medium
Subscriptions should have a contact email address for security issues
Description: To ensure the relevant people in your organization are notified when there is a potential security breach in one of your subscriptions, set a security contact to receive email notifications from Defender for Cloud. (Related policy: Subscriptions should have a contact email address for security issues)
Severity: Low
Transparent Data Encryption on SQL databases should be enabled
Description: Enable transparent data encryption to protect data-at-rest and meet compliance requirements (Related policy: Transparent Data Encryption on SQL databases should be enabled).
Severity: Low