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. You can see the recommendations in the portal that apply to your resources.

To learn about actions that you can take in response to these recommendations, see Remediate recommendations in Defender for Cloud.

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 a Microsoft Entra administrator provisioned

Description: Provision a Microsoft Entra administrator for your Azure Database for MySQL to enable Microsoft Entra authentication. Microsoft Entra authentication enables simplified permission management and centralized identity management of database users and other Microsoft services (Related policy: a Microsoft Entra administrator should be provisioned for MySQL servers).

Severity: Medium

Azure Database for PostgreSQL should have a Microsoft Entra administrator provisioned

Description: Provision a Microsoft Entra administrator for your Azure Database for PostgreSQL to enable Microsoft Entra authentication. Microsoft Entra authentication enables simplified permission management and centralized identity management of database users and other Microsoft services
(Related policy: a Microsoft Entra 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 a Microsoft Entra administrator provisioned

Description: Provision a Microsoft Entra administrator for your SQL server to enable Microsoft Entra authentication. Microsoft Entra authentication enables simplified permission management and centralized identity management of database users and other Microsoft services. (Related policy: a Microsoft Entra administrator should be provisioned for SQL servers).

Severity: High

Azure Synapse Workspace authentication mode should be Microsoft Entra ID Only

Description: Azure Synapse Workspace authentication mode should be Microsoft Entra ID Only Microsoft Entra ID only authentication methods improves security by ensuring that Synapse Workspaces exclusively require Microsoft Entra ID identities for authentication. Learn more. (Related policy: Synapse Workspaces should use only Microsoft Entra ID 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 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 open-source relational databases should be enabled

Description: Microsoft Defender for open-source relational databases detects anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases. Learn more in Introduction to Microsoft Defender for open-source relational databases.

Enabling this plan will result in charges for protecting your open-source relational databases. If you don't have any open-source relational databases in this subscription, no charges will be incurred. If you create any open-source relational databases on this subscription in the future, they will automatically be protected and charges will begin at that time. (No related policy)

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 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 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 should have a Microsoft Entra administrator provisioned

Description: Provision a Microsoft Entra administrator for your SQL server to enable Microsoft Entra authentication. Microsoft Entra authentication enables simplified permission management and centralized identity management of database users and other Microsoft services. (Related policy: a Microsoft Entra 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 Microsoft Entra ID (Microsoft Entra ID) to authorize requests for your storage account. By default, requests can be authorized with either Microsoft Entra ID credentials, or by using the account access key for Shared Key authorization. Of these two types of authorization, Microsoft Entra ID 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

Web Application Firewall (WAF) should be enabled for Application Gateway

Description: Deploy Azure Web Application Firewall (WAF) in front of public facing web applications for additional inspection of incoming traffic. Web Application Firewall (WAF) provides centralized protection of your web applications from common exploits and vulnerabilities such as SQL injections, Cross-Site Scripting, local and remote file executions. You can also restrict access to your web applications by countries/regions, IP address ranges, and other http(s) parameters via custom rules. (Related policy: Web Application Firewall (WAF) should be enabled for Application Gateway).

Severity: Low

Geo-redundant backups should be enabled for PostgreSQL Servers

Description: What is geo-redundant backup? Geo-redundant backup replicates server backups to a paired Azure region, providing resilience against regional failures.

Why is it a security concern? If geo-redundant backups are disabled, a regional outage could result in data loss and extended downtime, impacting availability and compliance.

How could attackers exploit it or how could it lead to data breaches? While not directly exploitable, lack of geo-redundancy increases the impact of disasters or targeted attacks on a single region.

Severity: Low

require_secure_transport should be set to on for Azure Database for PostgreSQL servers

Description: What is require_secure_transport? require_secure_transport is a server-level parameter that enforces the use of SSL/TLS for all client connections to PostgreSQL. When set to on, clients must connect using encrypted channels.

Why is it a security concern? If this setting is disabled (off), clients may connect over unencrypted channels, exposing sensitive data such as credentials, queries, and results to interception or manipulation.

How could attackers exploit it or how could it lead to data breaches? An attacker on the network could perform a man-in-the-middle attack, intercepting or altering data exchanged between the client and server if encryption is not enforced.

Severity: High

Private endpoint should be configured for Azure Database for PostgreSQL Servers

Description:

What is a private endpoint? A private endpoint in Azure allows resources to be accessed securely over a private IP address within a virtual network. For Azure Database for PostgreSQL servers, configuring a private endpoint ensures that database traffic does not traverse the public internet.

Why is it a security concern? Without a private endpoint, the server may be exposed to public network access, increasing the risk of unauthorized access, data interception, and denial-of-service attacks.

How could attackers exploit it or how could it lead to data breaches? An attacker could scan public IP ranges to discover exposed servers and attempt brute-force or exploit-based attacks. Public exposure also increases the risk of data exfiltration via compromised clients.

Severity: High

'Allow access to Azure services' should be disabled for PostgreSQL Servers

Description:

What is 'Allow access to Azure services'? This setting creates a firewall rule that permits all Azure services to connect to the PostgreSQL server. While convenient, it introduces significant risk by allowing connections from any Azure subscription.

Why is it a security concern? Enabling this setting bypasses network isolation controls, potentially exposing the database to unauthorized access from external Azure tenants.

How could attackers exploit it or how could it lead to data breaches? An attacker operating from another Azure subscription could attempt brute-force attacks or exploit vulnerabilities if this rule is enabled.

Severity: High

Public IP access should be disabled for Azure Database for PostgreSQL Servers

Description:

What is public network access? Public network access allows clients to connect to the PostgreSQL server over the internet using its public IP address. While convenient, it introduces significant risk by exposing the server to external attacks.

Why is it a security concern? If public access is enabled, attackers can scan IP ranges and attempt brute-force or exploit-based attacks against the server.

How could attackers exploit it or how could it lead to data breaches? An attacker could gain unauthorized access or disrupt service availability by exploiting vulnerabilities exposed through public endpoints.

Severity: Medium

pgaudit.log_level should be set to "log" for Azure Database for PostgreSQL Servers

Description:

What is pgaudit.log_level? pgaudit.log_level is a configuration parameter that determines the PostgreSQL log level used for audit messages generated by the pgaudit extension. Valid values include log, notice, warning, and info.

Why is it a security concern? If pgaudit.log_level is set to a level other than log, audit messages may be suppressed or redirected, reducing visibility into critical database activity. This can hinder detection of suspicious behavior and delay incident response.

How could attackers exploit it or how could it lead to data breaches? An attacker could perform unauthorized actions that go unlogged if the audit level is set too low or too high, bypassing monitoring systems and forensic tools.

Note: This recommendation is relevant only if the pgaudit extension is installed. The pgaudit extension must be installed per database, but the pgaudit.log_level setting is configured at the server level.

Severity: Medium

pgaudit.log should include role, ddl, and misc for Azure Database for PostgreSQL Servers

Description:

What is pgaudit.log? pgaudit.log is a configuration parameter that defines which classes of statements are logged by the pgaudit extension. Common classes include READ, WRITE, ROLE, DDL, and MISC.

Why is it a security concern? If ROLE, DDL, and MISC are not included in pgaudit.log, critical operations such as privilege changes, schema modifications, and session-level commands may go unlogged. This reduces visibility into potentially malicious or unauthorized activity.

How could attackers exploit it or how could it lead to data breaches? An attacker could escalate privileges, alter database structure, or execute session-level commands without detection if these classes are excluded from audit logging.

Note: This recommendation is relevant only if the pgaudit extension is installed. The pgaudit extension must be installed per database, but the pgaudit.log setting is configured at the server level.

Severity: High

pgaudit.log_statement_once should be set to “on” for Azure Database for PostgreSQL Servers

Description:

What is pgaudit.log_statement_once? pgaudit.log_statement_once is a configuration parameter that controls whether audit logs include repeated statements more than once per session. When set to on, only the first occurrence of a repeated statement is logged.

Why is it a security concern? If this setting is disabled (off), repeated statements may flood the audit logs, making it harder to identify meaningful activity and increasing storage and processing overhead.

How could attackers exploit it or how could it lead to data breaches? While not directly exploitable, excessive logging can obscure malicious activity in a flood of benign entries, delaying detection and response.

Note: This recommendation is relevant only if the pgaudit extension is installed. The pgaudit extension must be installed per database, but the pgaudit.log_statement_once setting is configured at the server level.

Severity: Medium

pgaudit.log_statement should be set to “on” for Azure Database for PostgreSQL Servers

Description:

What is pgaudit.log_statement? pgaudit.log_statement is a configuration parameter that controls whether the full SQL statement text is included in audit logs generated by the pgaudit extension. When set to on, it ensures that each logged action includes the exact command executed.

Why is it a security concern? If pgaudit.log_statement is not set to on, audit logs may lack the actual SQL statements, making it difficult to understand what actions were performed. This reduces the effectiveness of monitoring and incident response.

How could attackers exploit it or how could it lead to data breaches? Without full statement logging, malicious or unauthorized queries may be recorded only as generic actions, obscuring the true intent and impact of the activity.

Note: This recommendation is relevant only if the pgaudit extension is installed. The pgaudit extension must be installed per database, but the pgaudit.log_statement setting is configured at the server level.

Severity: Medium

logfiles.retention_days should be greater than 3 for PostgreSQL Servers

Description:

What is logfiles.retention_days? This parameter defines how many days PostgreSQL server logs are retained. The default is 3 days, which may be insufficient for compliance or investigation needs.

Why is it a security concern? If logs are purged too quickly, security teams may not have enough historical data to detect patterns, investigate incidents, or meet regulatory requirements.

How could attackers exploit it or how could it lead to data breaches? Attackers could rely on short retention periods to cover their tracks, knowing that evidence will be deleted quickly.

Severity: Medium

connection_throttle should be set to “on” for PostgreSQL Servers

Description:

What is connection_throttle? connection_throttle is a PostgreSQL configuration parameter that controls whether connection throttling is enabled. When set to on, the server can limit excessive connection attempts, reducing risk from brute-force or DoS attacks.

Why is it a security concern? If disabled (off), attackers can flood the server with connection attempts, potentially exhausting resources and causing downtime.

How could attackers exploit it or how could it lead to data breaches? Attackers could launch a DoS attack by opening thousands of connections, impacting availability and possibly creating conditions for privilege escalation during recovery.

Severity: Medium

AWS data recommendations

'Delete on termination' setting should be enabled for EBS volumes attached instance

Description: Defender for Cloud identified a missing 'Delete on termination setting' EBS volume attached instance. This setting automatically removes the instance's primary storage upon termination. Without it, orphaned volumes may retain sensitive data, increasing the risk of unauthorized access and compliance issues.

Severity: Low

Access logging should be enabled for LightSail buckets

Description: Defender for Cloud identified that access logging is not configured on your LightSail bucket. Access logging records activities performed on the bucket and helps verify that only authorized actions occur. Without it, unauthorized access may go undetected, reducing security visibility and complicating forensic investigations and incident response.

Severity: Low

Audit logs export should be enabled on Amazon DocumentDB clusters

Description: Defender for Cloud identified that audit log export to CloudWatch is disabled in Amazon DocumentDB clusters. Audit logs capture critical information about user and system activities that support forensic analysis during security incidents. Without this information, there is an increased risk that unauthorized actions may go undetected, potentially delaying incident response and remediation.

Severity: Low

Auto minor version upgrades should be enabled on MemoryDB clusters

Description: Defender for Cloud identified MemoryDB cluster without auto minor-version upgrades enabled. MemoryDB clusters rely on these upgrades to automatically install essential security patches and minor software improvements. Without this automation, clusters could remain vulnerable to security issues. Enabling the upgrade process helps maintain a robust security posture.

Severity: Low

Automated backup policies should be enabled on AlloyDB clusters

Description: Defender for Cloud identified that the automated backup policy is disabled for the AlloyDB cluster, meaning daily snapshots for recovery are not automatically created. Without these backups, your clusters are exposed to risks such as data loss from accidental deletion or ransomware, which could compromise disaster recovery and compliance requirements.

Severity: Medium

Automated snapshot retention should be enabled for Redshift clusters

Description: Defender for Cloud identified that automated snapshot retention is not enabled for your Amazon Redshift cluster. Automated snapshots provide point-in-time recovery capabilities for your data warehouse. Without proper retention, critical recovery data may be lost, increasing the risk of data loss from accidental deletion, corruption, or ransomware attacks, and potentially violating compliance requirements.

Severity: Low

Automatic backups should be enabled for Elasticache clusters

Description: Defender for Cloud identified that automatic backups are not enabled for your Elasticache clusters. Elasticache clusters are critical caching resources that, without regular backups, are vulnerable to data loss from accidental or malicious deletions. This poses a risk of extended downtime and compromised data integrity, potentially impacting overall service reliability. We recommend enabling automatic backups to safeguard your data and maintain operational continuity.

Severity: Medium

Automatic backups should be enabled for serverless Elasticache

Description: Defender for Cloud identified that automatic backups are not enabled for your serverless ElastiCache. Without periodic snapshots, your ElastiCache lacks a recovery point to restore data in cases of accidental or malicious deletion, increasing the risk of irrecoverable data loss. Enabling automatic backups minimizes potential disruptions and protects the integrity of your cached data.

Severity: Medium

Automatic backups should be enabled on FSx for Lustre

Description: Defender for Cloud identified that an FSx for Lustre file system that does not have automatic backups enabled. Automatic backups are scheduled, incremental snapshots that preserve recovery points. Without these backups, the file system is at risk of irreversible data loss from accidental deletions, corruption, or malicious activities. Enabling automatic backups is essential for maintaining data resilience and ensuring business continuity.

Severity: Medium

Automatic backups should be enabled on FSx for OpenZFS

Description: Defender for Cloud identified an FSx for OpenZFS file system that does not have automatic backups enabled. Automatic backups are scheduled, incremental snapshots that serve as recovery points. Without them, the FSx for OpenZFS resource is prone to severe data loss from accidental deletions, file corruption or potentially malicious activities.

Severity: Medium

Automatic backups should be enabled on FSx for Windows File Server

Description: Defender for Cloud identified that automatic backups have not been configured on your FSx for Windows File Server. Automatic backups create regular recovery points that are essential for quickly restoring data in the event of accidental deletion, malicious activity, or system failures. This poses a risk of extended downtime and potentially irreversible data loss, since without these recovery points there is no managed snapshot to restore from.

Severity: Medium

Automatic security updates should be enabled on RedisOSS ElastiCache clusters

Description: Defender for Cloud identified that auto-upgrade is disabled in your RedisOSS ElastiCache clusters. Auto-upgrade automatically installs the latest security patches and software updates to protect cluster nodes from known vulnerabilities. This poses a risk by leaving your clusters open to cyberattacks that exploit outdated software. Learn more.

Severity: Low

Automatic snapshots should be enabled for MemoryDB clusters

Description: Defender for Cloud identified MemoryDB cluster without automatic snapshot configuration. Automated snapshot automatically preserves resource snapshots for a specified duration, ensuring critical recovery data is available after incidents. Without it, there is an increased risk of data loss through accidental deletion or corruption.

Severity: Medium

AWS Key Management Service encryption should be configured for EventBridge Pipe

Description: Configuring AWS Key Management Service (KMS) encryption for EventBridge Pipe ensures that data at rest is encrypted using customer-controlled keys, providing enhanced security and compliance capabilities. This measure allows to better manage and rotate encryption keys according to internal policies or regulatory requirements. If this is not implemented, the data will be encrypted using AWS-managed keys, which may not meet stringent security or compliance standards. This recommendation is particularly important for organizations handling sensitive or regulated data, such as personally identifiable information (PII), financial records, or intellectual property. To implement this, configure the EventBridge Pipe to use a customer-managed KMS key in the AWS Management Console or via the AWS CLI.

Severity: Low

AWS Key Management Service encryption should be enabled for SageMaker domain

Description: Defender for Cloud identified that your SageMaker domain is using AWS-managed KMS keys instead of customer-managed keys. AWS KMS encryption protects data at rest by allowing you to control key management-including rotation and access-ensuring compliance with stringent security requirements. Without customer-managed keys, sensitive data may be at higher risk of unauthorized access and non-compliance. Learn more.

Severity: Low

AWS Key Management Service encryption should be enabled on SageMaker endpoints

Description: Defender for Cloud identified a lack of AWS Key Management Service (KMS) encryption on Sagemaker endpoints. KMS encryption secures sensitive data by managing encryption keys-including their lifecycle activities such as generation, rotation, and deletion. Without KMS enabled, endpoints risk exposure to data breaches and unauthorized access. Learn more.

Severity: Medium

Backup retention should be enabled for LightSail Relational Database Service

Description: Defender for Cloud identified that backup retention is disabled on your LightSail Relational Database Service. Backup retention automatically saves backups of your database over time so that you can restore data in case of accidental deletion or malicious corruption. Without it, recovery becomes more difficult and you risk losing up-to-date data if an attacker compromises your database.

Severity: Medium

Broad Owner or Editor roles should be eliminated from service accounts on BigQuery datasets

Description: Defender for Cloud identified service accounts with excessive permissions on BigQuery datasets. The evaluation discovered service accounts assigned broad roles such as OWNER, WRITER, or roles/bigquery.admin that provide more access than necessary. This poses a risk of lateral movement and data exfiltration if these credentials are compromised. It is essential to restrict permissions to roles that align with the service account's functional requirements, such as 'BigQuery Data Viewer' or 'BigQuery Data Editor'

Severity: High

CloudWatch query metrics should be enabled on Athena workgroups

Description: Defender for Cloud identified an Athena workgroup without CloudWatch query metrics publishing enabled. This poses a risk of detection evasion and silent data harvesting, since without metrics on query volume, scanned bytes, and execution counts, anomalous activity such as a single principal suddenly scanning very large data volumes goes unnoticed, letting reconnaissance and slow exfiltration through Athena run undetected.

Severity: Medium

Cluster endpoint encryption should be enabled for DAX clusters

Description: Defender for Cloud identified that cluster endpoint encryption is not enabled in clusters. Cluster endpoint encryption protects data during transmission between clients and the cluster. Without it, sensitive information may be intercepted or accessed by unauthorized parties, potentially compromising data confidentiality and integrity. Enable encryption to secure data in transit and reduce the risk of cyber attacks.

Severity: Medium

Cross-account access should be restricted on Amazon SNS topics

Description: Defender for Cloud identified that your Amazon SNS topic is configured for cross-account access, allowing external AWS accounts to interact with it. Cross-account access means that users outside your trusted environment can publish or subscribe to your topics. This poses a risk by potentially exposing sensitive notifications to unauthorized parties and misuse. Restricting such access will help secure your topic from external threats.

Severity: Medium

Customer-managed encryption keys should be enabled for CodeArtifact domains

Description: Defender for Cloud identified that customer-managed keys (CMKs) are not enabled on your domains. CMKs are encryption keys that you control, including their lifecycle, rotation, and access policies. Without CMK configuration, your domains rely solely on provider-managed keys, reducing oversight and potentially leaving sensitive data more vulnerable to unauthorized access.

Severity: Low

Customer-managed encryption keys should be enabled for Datastream streams

Description: Defender for Cloud identified Datastream streams that are not using Customer-Managed Encryption Keys (CMEK). This assessment evaluates whether your Datastream streams have CMEK enabled, a control that allows direct key rotation and access policy management. Without CMEK, the automatic encryption provided by Google Cloud may not meet the stringent requirements for sensitive data, leaving your workload more exposed to potential key compromise or unauthorized access. Learn more: https://cloud.google.com/datastream/docs

Severity: Low

Customer-managed encryption keys should be enabled for ElastiCache clusters

Description: Defender for Cloud identified ElastiCache clusters that lack Customer Managed Key (CMK) encryption. CMK encryption uses custom keys that allow for controlled rotation and enhanced security compared to default keys. This poses a risk by potentially exposing your clusters to unauthorized data access and compliance issues. Learn more.

Severity: Low

Customer-managed encryption keys should be enabled for GCP Spanner databases

Description: Defender for Cloud identified databases that are not configured with customer-managed encryption keys (CMEK). CMEK refers to encryption keys created and managed by your organization, as opposed to platform-managed keys. Without CMEK, databases may not meet regulatory or policy requirements, potentially exposing your data to unauthorized access or compliance issues due to reduced control over key lifecycle management.

Severity: Low

Customer-managed encryption keys should be enabled for Memorystore for Redis instances

Description: Defender for Cloud identified that customer managed encryption keys are not enabled for Memorystore for Redis instances. This evaluation checks if encryption operations are solely managed by default Google-managed keys, which restricts key rotation, audit logging, and timely access control enhancements. Such limitations pose a risk by potentially compromising data protection and compliance efforts, as organizations lack explicit ownership and governance over their encryption keys.

Severity: Low

Customer-managed encryption keys should be enabled for Pub/Sub topics

Description: Defender for Cloud identified Pub/Sub topics using default Google-managed encryption keys instead of customer-managed encryption keys (CMEK). CMEK allows you to control key rotation and access policies, while reliance on default keys limits control and may increase the risk of unauthorized access and compliance issues. Learn more.

Severity: Low

Customer-managed encryption keys should be enabled for Vertex AI Datastore

Description: Defender for Cloud identified that Vertex AI Datastore is not configured with Customer Managed Encryption Keys (CMK), meaning it rely on the default Google-managed encryption. This poses a risk because GCP-managed keys do not allow you to control rotation policies, set granular access permissions, or audit key usage, potentially failing to meet strict compliance and data sovereignty requirements in regulated industries.

Severity: Low

Customer-managed encryption keys should be enabled for Vertex AI Engine

Description: Defender for Cloud identified that Vertex AI Engine instance is not configured with Customer Managed Encryption Keys (CMK), meaning it rely on the default Google-managed encryption. This poses a risk because GCP-managed keys do not allow you to control rotation policies, set granular access permissions, or audit key usage, potentially failing to meet strict compliance and data sovereignty requirements in regulated industries.

Severity: Low

Customer-managed encryption keys should be enabled on AlloyDB clusters

Description: Defender for Cloud identified that AlloyDB cluster is not configured with Customer Managed Encryption Keys (CMK), meaning it rely on the default Google-managed encryption. This poses a risk because GCP-managed keys do not allow you to control rotation policies, set granular access permissions, or audit key usage, potentially failing to meet strict compliance and data sovereignty requirements in regulated industries.

Severity: Low

Customer-managed encryption keys should be enabled on Amazon SNS topics

Description: Defender for Cloud identified that your AWS SNS topics are using default encryption instead of customer-managed keys (CMK). CMK encryption enables you to control key policies and audit key usage, offering improved protection against unauthorized access and supporting compliance with internal and regulatory security standards. This configuration oversight may expose sensitive data to increased risks.

Severity: Low

Customer-managed encryption keys should be enabled on Artifact Registry repositories

Description: Defender for Cloud identified that repositories are secured using platform-managed encryption keys instead of customer-managed encryption keys (CMEK). CMEK are keys that you control, offering advanced lifecycle management and stricter access control. Using platform-managed keys increases the risk of data protection vulnerabilities and may not meet compliance requirements. We recommend configuring CMEK to enhance encryption security and control.

Severity: Low

Customer-managed encryption keys should be enabled on Comprehend EntityRecognizer Models

Description: Defender for Cloud identified an Amazon Comprehend EntityRecognizer without customer-managed encryption keys configured for the trained model. This poses a risk of reduced control over model encryption and potential unauthorized access. The ModelKmsKeyId property specifies the KMS key used to encrypt trained custom models. Using customer-managed keys ensures model integrity and provides greater control over access to sensitive ML models.

Severity: Medium

Customer-managed encryption keys should be enabled on Comprehend EntityRecognizer Volume

Description: Defender for Cloud identified an Amazon Comprehend EntityRecognizer without customer-managed encryption keys configured for the storage volume. This poses a risk of reduced control over data encryption and potential unauthorized access. The VolumeKmsKeyId property specifies the KMS key used to encrypt data on the storage volume attached to ML compute instances. Using customer-managed keys provides greater control over encryption and helps protect sensitive training data.

Severity: Medium

Customer-managed encryption keys should be enabled on Filestore instances

Description: Defender for Cloud identified Filestore instances without Customer-Managed Encryption Keys (CMEK). This poses a risk of reduced control over encryption key rotation and access policies in Cloud KMS, which could compromise compliance with regulatory and organizational standards. Learn more: https://cloud.google.com/filestore/docs/cmek

Severity: Low

Customer-managed encryption keys should be enabled on MemoryDB clusters

Description: Defender for Cloud identified that MemoryDB cluster is not using Customer Managed Keys (CMK) for encryption. Using Customer Managed Keys (CMK) allow enhanced control over key lifecycle and detailed auditing, ensuring that encryption practices meet compliance requirements.

Severity: Low

Customer-managed encryption keys should be used on DMS replication instances

Description: Defender for Cloud identified that encryption at rest is not enabled on your AWS DMS replication instance. This poses a risk of unauthorized data exposure if the underlying storage is compromised. Encryption at rest protects sensitive data by encrypting it while stored on disk, ensuring that even if physical storage media is accessed, the data remains unreadable without the proper KMS key.

Severity: Medium

Customer Managed Key encryption at rest should be configured on Amazon MSK clusters

Description: Defender for Cloud identified Amazon MSK provisioned clusters using an AWS-managed KMS key for data-at-rest encryption instead of a Customer Managed Key (CMK). Without a CMK, the customer cannot rotate the key on a defined schedule, revoke key access to render the data unreadable if the cluster is compromised or audit per-operation key usage through CloudTrail. MSK Serverless clusters do not support CMK and are excluded from this assessment. (No related policy)

Severity: Medium

Customer-managed KMS encryption at rest should be configured on Amazon Kendra indexes

Description: Defender for Cloud identified that an Amazon Kendra index is not configured with a customer-managed KMS key for encryption at rest. This poses a risk of reduced control over key rotation, access policies, and auditability. Using a customer-managed key helps enforce least-privilege access to encrypted data and supports stronger separation of duties.

Severity: Medium

Customer-managed KMS encryption should be enabled on Amazon Bedrock Agents

Description: Defender for Cloud identified that Amazon Bedrock Custom Models are being deployed without customer-managed KMS encryption in place. Amazon Bedrock Custom Models can be created or imported without explicitly selecting a customer-managed key, which causes model artifacts to be encrypted with AWS-managed keys instead. This poses a risk by reducing control over key rotation, strict access policies, and audit transparency, potentially leading to compliance and security vulnerabilities.

Severity: Low

Customer-managed KMS key for encryption at rest should be configured on Amazon MQ broker

Description: Defender for Cloud identified Amazon MQ brokers that use AWS-owned KMS keys for encryption at rest instead of customer-managed keys. Using customer-managed KMS keys provides stronger control over key policies, rotation and auditability compared to AWS-owned keys. This helps meet compliance requirements, enables granular access control and reduces reliance on default key management configurations.

Severity: Medium

Customer-managed KMS key should be configured for encryption on Amazon AppFlow Flows

Description: Defender for Cloud identified Amazon AppFlow Flows that are not encrypted with a customer-managed KMS key. Using customer-managed KMS keys provides stronger control over key policies, rotation and auditability compared to AWS-owned keys. This helps meet compliance requirements and reduces reliance on default key management configurations.

Severity: Medium

Customer-managed KMS key should be configured on OpenSearch Service domains

Description: Defender for Cloud identified OpenSearch Service domains that use AWS-owned keys for encryption at rest instead of a customer-managed KMS key. Using non-customer-managed keys limits control over key access policies, key rotation and key usage auditing, increasing the risk of unauthorized data access. (No related policy)

Severity: Medium

Customer-managed KMS keys should be used for encryption on Amazon Keyspaces tables without replica regions

Description: Defender for Cloud identified an Amazon Keyspaces table using AWS-owned KMS keys instead of customer-managed keys for encryption. This poses a risk of reduced control over encryption key management, including key rotation and access policies. Customer-managed KMS keys provide greater control over encryption and enable stricter security controls. Note: Tables configured with replication regions use AWS-owned keys by default; customer-managed KMS keys are not supported for multi-region tables.

Severity: Medium

Data encryption at rest should be enabled on ElastiCache clusters

Description: Defender for Cloud identified that encryption at rest is not enabled on your ElastiCache cluster. Encryption at rest converts stored data into a cryptographically secure format, protecting information even if the underlying storage is breached. Without this safeguard, unauthorized access or data tampering may occur, risking compliance and overall system integrity.

Severity: Medium

Data integrity verification should be enabled on DataSync tasks

Description: Defender for Cloud identified a DataSync task with verify mode set to NONE, so DataSync does not validate that data written to the destination matches the source. This poses a risk of silent data manipulation, since corruption or tampering of files during or after transfer between on-premises and AWS storage will not be detected, undermining trust in the destination data.

Severity: Low

Database drop protection should be enabled for GCP Spanner databases

Description: Defender for Cloud identified that database drop protection is disabled for your databases. Database drop protection prevents accidental or unauthorized deletion by requiring additional confirmation before removing a database. Without this safeguard, your critical data is exposed to potential loss from human error or misconfigured automation.

Severity: Medium

Default backup schedule for new databases should be enabled

Description: Enabling a default backup schedule for new Spanner Instance ensures automated data protection right from the creation of the databases. This helps in maintaining consistent backups without manual intervention and reduces the risk of human error. Regular backups provide recovery options in case of accidental data deletion, corruption, or system failures. If the default backup schedule is not enabled, new databases may remain unprotected and vulnerable, increasing the risk of permanent data loss. It is recommended to enable this setting to enhance database resiliency and business continuity.

Severity: Medium

Defined snapshots retention periods should be enforced for Redshift clusters

Description: Defender for Cloud identified indefinite retention in Amazon Redshift snapshots, where snapshots are configured to never expire (retention period set to -1). This poses a risk of accumulating unnecessary storage costs and prolonged exposure of potentially sensitive data. Defining a retention period ensures that outdated snapshots are automatically purged, reducing both financial impact and security vulnerabilities.

Severity: Low

Deletion protection should be enabled on Amazon DocumentDB clusters

Description: Defender for Cloud identified that deletion protection is not enabled on your Amazon DocumentDB clusters. Deletion protection is a safeguard that prevents accidental or malicious removal of database clusters. Without it, your DocumentDB clusters are exposed to risks of unauthorized deletions leading to significant downtime and operational disruption. Activate deletion protection to maintain the security and availability of your data.

Severity: Medium

Deletion protection should be enabled on Firestore databases

Description: Defender for Cloud identified Firestore databases with deletion protection disabled in Firestore. Deletion protection prevents databases from being removed unless explicitly turned off. Without this safeguard, accidental or malicious deletions may lead to irreversible data loss and operational disruptions in production environments.

Severity: Medium

Deletion protection should be enabled on Neptune DB clusters

Description: Defender for Cloud identified that deletion protection is not enabled on your Neptune DB cluster. This poses a risk of accidental or malicious data loss, as the database can be permanently deleted without any safeguard. Enabling deletion protection ensures the cluster cannot be removed until the setting is explicitly disabled, protecting critical data from unintended destruction.

Severity: Medium

Encryption at rest should be enabled for EBS volumes in Auto Scaling Groups

Description: Defender for Cloud identified Auto Scaling Group launch templates that provision EBS volumes without encryption at rest. This poses a risk of unauthorized data exposure, as snapshots or copies of unencrypted volumes can be read by any principal with sufficient EBS permissions, bypassing the running instance's access controls. Encryption at rest ensures that storage-level access alone does not reveal the data, since decryption additionally requires permissions on the KMS key.

Severity: Medium

Encryption at rest should be enabled on OpenSearch Service domains

Description: Defender for Cloud identified OpenSearch Service domains without encryption at rest enabled. Without encryption at rest, stored data can be exposed if underlying storage is accessed without authorization, increasing the risk of unauthorized access to sensitive data. (No related policy)

Severity: Medium

Encryption at rest should be enabled on Neptune DB instances

Description: Defender for Cloud identified that encryption at rest is not enabled on your Neptune DB instance. This poses a risk of unauthorized access to sensitive data if the underlying storage is compromised. Encryption at rest protects stored data by encrypting it using a secure key, ensuring that data remains unreadable without proper decryption credentials.

Severity: Medium

Encryption in transit should be enabled on cluster-based cache

Description: Defender for Cloud identified that encryption in transit is not enabled in your cluster-based cache used by ElastiCache. Encryption in transit safeguards data as it moves between cache nodes and client applications. Without it, sensitive information may be exposed to interception or tampering during transmission, creating a risk of data breaches and non-compliance with security best practices.

Severity: Medium

Encryption in transit should be enabled on MemoryDB clusters

Description: Defender for Cloud identified that TLS (Transport Layer Security) encryption is not enabled on your MemoryDB cluster. TLS secures data and client communications by encrypting transmitted information. Without TLS enabled, data in transit is susceptible to interception and alteration by unauthorized parties.

Severity: Medium

Encryption with AWS Key Management Service should be enabled on EventBridge Event Bus

Description: Defender for Cloud identified that your EventBridge Event Bus is not using a customer-managed AWS Key Management Service key for data encryption. Customer-managed KMS keys provide enhanced control with key rotation features, which are critical for protecting sensitive data. Without this configuration, your Event Bus relies on AWS-managed keys that may not meet strict compliance and security standards.

Severity: Low

Ensure AWS Backup plans include cross-Region or cross-account copy actions

Description: AWS Backup plans without cross-Region or cross-account copy actions store recovery points in a single location, increasing the risk of data loss due to regional outages, account compromise, or ransomware. Configuring copy actions improves backup resilience by ensuring recovery points are preserved in an independent security and availability boundary.

Severity: Low

Expected S3 bucket owner should be configured for query results on Athena workgroups

Description: Defender for Cloud identified Athena workgroups without an expected S3 bucket owner configured for query results, or whose ResultConfiguration can be overridden by callers because EnforceWorkGroupConfiguration is disabled. This poses a risk of bucket-name squatting: if the configured result bucket is deleted or its name predicted, an attacker can create a bucket with the same name in their own AWS account, and Athena would write sensitive query results into the attacker-controlled bucket.

Severity: Low

Explicit prompt override control should be configured for Amazon Bedrock Agents

Description: Defender for Cloud identified uncontrolled prompt override settings in Amazon Bedrock Agents. These agents, which execute generative AI tasks, are at risk when prompt override controls are misconfigured-allowing unsafe instructions to bypass established safety mechanisms. This misconfiguration could result in unpredictable AI behavior and potential security or compliance breaches, undermining the trusted operation of your services.

Severity: Medium

File access auditing should be enabled on FSx for Windows File Server

Description: Defender for Cloud identified that file access auditing is not enabled on FSx for Windows File Server. File access auditing involves monitoring and logging file operations such as reads and modifications to create an audit trail. Without these logs, unauthorized file access or modifications may go undetected, increasing the risk of delayed incident response and hampering forensic investigations.

Severity: Low

File-level audit visibility should be configured on DataSync tasks

Description: Defender for Cloud identified a DataSync task without file-level audit visibility: the log level is not set to log all transferred objects, and no Standard Task Report with transferred-file details is configured. This poses a risk of undetected data exfiltration, since without per-file records forensic teams cannot determine which objects were copied to an attacker-controlled destination.

Severity: Medium

Glue Data Catalog metadata registration should be configured on AppFlow flows

Description: Defender for Cloud identified AppFlow flows with Amazon S3 destination that do not have Glue Data Catalog metadata registration enabled. Without catalog integration, data schemas and lineage are not recorded, reducing governance visibility and increasing the risk of undetected or untracked data movement.

Severity: Low

In-transit encryption should be enabled for Memorystore for Redis instances

Description: Defender for Cloud identified that in-transit encryption is disabled for Memorystore for Redis instances. In-transit encryption, usually provided via TLS, safeguards data as it travels across the network. Without it, sensitive cached data is transmitted in plaintext, exposing it to interception, traffic inspection, and man-in-the-middle attacks, which may compromise data confidentiality and integrity.

Severity: Medium

KMS managed key configuration should be enabled for SQS server side encryption

Description: Defender for Cloud identified that your SQS queue is not configured to use KMS managed keys for server-side encryption. KMS managed keys are fully controlled by the Key Management Service and provide enhanced oversight of key lifecycle and access auditing. Without these controls, your queue faces increased risk of unauthorized key usage and reduced protection of sensitive data at rest.

Severity: Medium

KMS-based encryption should be enforced for query results on Athena workgroups

Description: Defender for Cloud identified an Athena workgroup that does not enforce KMS-based encryption (SSE-KMS or CSE-KMS) with a customer-managed key for query results. This poses a risk of unauthorized data access: without customer-managed keys, access cannot be revoked via key policy if credentials are compromised; without workgroup enforcement, callers can bypass encryption settings at query time.

Severity: Low

Knowledge Base field mapping should be securely configured on Amazon Bedrock

Description: Defender for Cloud identified misconfigured field mappings in Amazon Bedrock Knowledge Bases. This poses a risk of corrupting embeddings and causing inaccurate document retrieval, potentially leading to unsafe or misleading outputs in retrieval-augmented generation (RAG) pipelines when mappings for vector, text, and metadata fields are incomplete or incorrect.

Severity: High

LockConfiguration should be enabled on Backup Vault

Description: Defender for Cloud identified that the LockConfiguration is not enabled on your Backup Vault. LockConfiguration prevents unauthorized modifications or deletions of critical backup settings, ensuring that recovery points remain secure. Without this control, the Backup Vault is at increased risk of accidental or malicious changes that can compromise data resilience and backup integrity. Learn more.

Severity: Medium

Logging should be enabled and encrypted on EMR clusters

Description: Defender for Cloud identified EMR clusters that either do not publish cluster logs to Amazon S3 or Amazon CloudWatch Logs, or publish logs without encryption configured for the chosen destination. Cluster logs may contain operational details such as application logs, query text and error traces. Without log publishing, visibility into cluster activity is reduced, and without encryption on the chosen log destination there is a risk of unauthorized access to log contents.

Severity: Medium

Managed admin credentials should be enabled for Amazon Redshift clusters

Description: Defender for Cloud identified that your Amazon Redshift clusters are not using managed admin credentials. Managed admin credentials involve securely storing administrative credentials in AWS Secrets Manager with automatic rotation, which minimizes the risk of credential exposure. Without this setup, there is an increased risk of unauthorized database access and potential data breaches.

Severity: Medium

Object versioning should be enabled on LightSail buckets

Description: Defender for Cloud identified that object versioning is disabled on your LightSail bucket. Object versioning automatically saves and retains historical copies of objects, which is essential for recovering data from accidental deletions, modifications, or corruption. Without this feature, any unauthorized changes or errors can permanently compromise your data integrity.

Severity: Low

Parser override should be disabled for Amazon Bedrock Agents

Description: Defender for Cloud identified a custom parser override setting (ParserMode = OVERRIDDEN) in Amazon Bedrock Agents. Custom parser overrides modify the default parsing mechanism to meet specific output requirements but can increase operational complexity, potentially causing parsing errors or exposing security vulnerabilities if not rigorously maintained. We recommend disabling this override unless strict output validation is essential.

Severity: High

Point-in-Time Recovery (PITR) should be enabled on Amazon Keyspaces tables

Description: Defender for Cloud identified an Amazon Keyspaces (Cassandra) table with Point-in-Time Recovery (PITR) disabled. Without PITR, malicious or accidental destructive operations (DROP/TRUNCATE TABLE, mass DELETE, ransomware-style overwrite via compromised credentials) cannot be rolled back, resulting in permanent data loss. PITR allows tables to be restored to any point in time within the recovery window, providing protection against data destruction and ransomware impact.

Severity: Medium

Point-in-Time Recovery should be enabled for Firestore databases

Description: Defender for Cloud identified Firestore databases with Point-in-Time Recovery (PITR) disabled. PITR is a feature that enables data recovery from a specific timestamp within the retention period, protecting against accidental deletions and erroneous writes. Without PITR, your databases are at risk of extended data loss and potential challenges in restoring data integrity after incidents.

Severity: Medium

Prompt execution state should be enabled for critical agent stages on Amazon Bedrock

Description: Defender for Cloud identified disabled prompt execution state for critical agent stages in Amazon Bedrock. Critical agent stages-such as orchestration and knowledge base response generation-are vital for ensuring complete reasoning and accurate outputs. Disabling these stages poses a risk of generating unsafe, incomplete, or incorrect responses, which could lead to compromised agent behavior and overall system integrity.

Severity: High

Public Access Block configuration should be enabled on AWS S3 Access Point

Description: Defender for Cloud identified the Public Access Block configuration is not enabled on your AWS S3 Access Point. Public Access Block settings are designed to prevent inadvertent public exposure by automatically blocking public access to S3 resources, regardless of bucket or object-level permissions. Without this setting, there's an increased risk of unauthorized access to sensitive data stored in your S3 buckets.

Severity: High

Public access for publishers should be disabled on Amazon SNS topics

Description: Defender for Cloud identified that your SNS topics have unrestricted publisher access enabled. This setting allows any entity to publish notifications to your topics, which can lead to unauthorized alerts, spam, or even malicious messages that weaken your notification system reliability and security. By ensuring publisher access is restricted, you minimize these risks and enhance the overall integrity of your messaging infrastructure.

Severity: High

Public access for subscribers should be disabled on Amazon SNS topic

Description: Defender for Cloud identified that SNS Topic subscriptions are publicly accessible. Here, "public access" means any entity can subscribe and receive notifications, exposing your messaging system to unauthorized monitoring and data leakage. Such exposure can allow malicious actors to intercept or misuse sensitive information. We recommend configuring subscriptions to allow only approved subscribers. Learn more.

Severity: High

Public email domains should be barred from receiving privileged roles on BigQuery

Description: Defender for Cloud identified highly privileged BigQuery roles (e.g., OWNER, WRITER, or Admin) assigned to members with public email domains. Public email domains are external to your organization's identity lifecycle management, which poses a risk of unauthorized data modification, deletion, or permission escalation.

Severity: High

Public read access on LightSail buckets should be disabled

Description: Defender for Cloud identified that your LightSail bucket permits public read access. This setting allows anyone to access stored objects without authentication, making sensitive data vulnerable to unauthorized exposure and exploitation.

Severity: High

Public sharing should be disabled on QuickSight accounts

Description: Defender for Cloud identified that public sharing is enabled in Amazon QuickSight account settings. This poses a risk of unauthorized data access, as dashboards and visuals can be shared publicly without requiring a QuickSight account or AWS credentials. Disable public sharing to reduce the risk of data exposure.

Severity: Medium

Query results output location should be configured on Athena workgroups

Description: Defender for Cloud identified an Athena workgroup without a centrally defined S3 output location for query results. This poses a risk of query results landing in unmanaged or attacker-controlled S3 buckets: without a workgroup-level output location, callers must specify their own destination at query time, bypassing centralized audit, bucket policies, and data governance controls.

Severity: Low

Resource labels should be configured on Artifact Registry repositories

Description: Defender for Cloud identified missing resource labels in repositories. Resource labels are key-value pairs that categorize repositories and enable automated enforcement of security policies. Without proper labels, there is an increased risk of misconfigurations and unauthorized access due to inconsistent security controls.

Severity: Low

Secure connectors should be enabled for AlloyDB instances

Description: Defender for Cloud identified insecure client connection settings in AlloyDB instance. The evaluation checks the 'Require connectors' property, which when set to false permits direct PostgreSQL protocol connections without a secure mediator such as the AlloyDB Auth Proxy. This bypasses IAM-based authentication and automatic TLS encryption, increasing the risk of weaker authentication and potential exposure of unencrypted traffic within your VPC.

Severity: Medium

Security configuration should be enabled on EMR clusters

Description: Defender for Cloud identified EMR clusters that are not associated with a security configuration. A security configuration defines settings for encryption, authentication (Kerberos is recommended), authorization etc. Without a security configuration, data processed and stored within EMR clusters may be exposed to unauthorized access.

Severity: High

Security groups should be configured for MemoryDB clusters

Description: Defender for Cloud identified MemoryDB cluster without any security groups configured. Security groups function as firewall rules that regulate both inbound and outbound traffic for your cluster. Without them, your cluster is exposed to the risk of unauthorized access and potential data breaches. Enabling security groups can significantly reduce this risk by ensuring that only approved traffic is allowed to access your MemoryDB cluster.

Severity: Medium

Security groups should be configured to restrict access for ElastiCache

Description: Defender for Cloud identified insufficient security group configurations in your ElastiCache service. Security groups are network filters that control traffic between resources; when not properly configured, they fail to enforce fine-grain access restrictions, potentially exposing your cache to unauthorized access and exploitation. This increases the risk of data breaches and other security incidents. Learn more.

Severity: Low

Security groups should restrict access for ElastiCache

Description: Defender for Cloud identified lax security group restrictions in your ElastiCache setup. Security groups act as virtual firewalls that manage user and instance access, and insufficient segmentation can result in unauthorized access, increasing the risk of data exposure and potential malicious activity. We recommend reviewing and enforcing granular access rules to ensure that only authorized users and processes interact with your ElastiCache resources.

Severity: Low

Security logs should be enabled for ElastiCache Replication Group

Description: Defender for Cloud identified that logging is not enabled for your ElastiCache Replication Group. This recommendation was triggered upon detecting the absence of engine-logs, which capture detailed operational events, or slow-logs, which track latency issues. Without these logs, potential anomalies and unauthorized activities may go undetected, increasing the risk of delayed incident response or security breaches. Learn more.

Severity: Low

Sensitive data exposure mitigation should be enabled on AWS CloudFormation stack outputs

Description: Defender for Cloud identified exposed sensitive outputs in your AWS CloudFormation stack. CloudFormation outputs are used to pass data between stacks but should not include sensitive information such as passwords, API keys, tokens, or credentials. Exposing these details increases the risk of unauthorized data access. Remove these outputs or securely store secret data using AWS Secrets Manager or SSM Parameter Store. For more details, visit: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/outputs-section-structure.html

Severity: High

Sensitive parameters should have NoEcho attribute enabled on AWS CloudFormation stacks

Description: Defender for Cloud identified AWS CloudFormation stacks with parameters missing the NoEcho attribute. The NoEcho attribute masks sensitive values from logs and outputs, preventing credentials and other confidential data from being inadvertently exposed. Without it, your stacks may leak critical information, heightening the risk of unauthorized access. We recommend updating your templates to incorporate the NoEcho setting where applicable.

Severity: High

Server-side encryption should be enabled for Amazon Bedrock Knowledge Bases data sources

Description: Defender for Cloud identified a lack of specific server-side encryption configuration in Amazon Bedrock Knowledge Base data sources. Without proper ServerSideEncryptionConfiguration, ingested documents, metadata, and processing artifacts may be stored unencrypted or with AWS-managed keys, reducing customer control over encryption, key rotation, and audit capabilities, thus increasing the risk of unauthorized data access and diminished security governance.

Severity: Medium

Server-side encryption should be enabled on Kinesis streams

Description: Defender for Cloud identified missing server-side encryption on Kinesis data streams. This poses a risk of unauthorized disclosure of stream records at rest, because anyone with read access to the underlying storage can retrieve plaintext data.

Severity: Medium

Server-side encryption should be enabled on SQS queues

Description: Defender for Cloud identified that server-side encryption (SSE) is not enabled on your SQS queues. SSE is a method that uses encryption keys to transform sensitive data into an unreadable format until it is properly decrypted. Without this safeguard, your SQS queues are at risk of unauthorized data access, potentially exposing sensitive information and leading to data breaches and compliance issues.

Severity: High

Strict cross-account access restrictions should be configured on LightSail buckets

Description: Defender for Cloud identified cross-account access in your LightSail bucket. Cross-account access occurs when AWS accounts outside your trusted environment are granted permissions to access bucket objects. This poses a risk of unauthorized data exposure if these external accounts are unknown or unmonitored. Restricting access exclusively to accounts with a legitimate need can help safeguard your sensitive information.

Severity: Medium

Termination protection should be enabled on Amazon QuickSight accounts

Description: Defender for Cloud identified that termination protection is disabled on the Amazon QuickSight account. This poses a risk of permanent data loss and service disruption, because an unauthorized or compromised principal could delete the QuickSight subscription and remove all dashboards, datasets, analyses, and account configuration.

Severity: Medium

Unattached EBS volumes should be removed or attached to EC2 instance

Description: Defender for Cloud identified unattached EBS volume. EBS volumes are persistent block storage devices intended for attachment to EC2 instances. Unattached volumes may indicate orphaned resources from terminated instances, increasing the attack surface and possibly holding sensitive data that no longer receives active security monitoring.

Severity: Low

Unexpired subscriptions should have expiration policies configured on Pub/Sub subscriptions

Description: Defender for Cloud identified missing expiration policies in Pub/Sub subscriptions. Expiration policies determine how long an inactive subscription remains active before auto deletion. Without this configuration, subscriptions may continue storing data indefinitely, leading to increased storage costs and a higher risk of sensitive information being retained longer than necessary. For more information, visit https://cloud.google.com/pubsub/docs/subscription-properties#expiration_period

Severity: Low

Unused CodeArtifact domains should be removed

Description: Defender for Cloud identified CodeArtifact domains lacking active repositories or artifacts in CodeArtifact. An unused domain is one that does not host current content but may still hold legacy settings such as outdated permissions or encryption keys. This poses a risk by expanding your control plane attack surface and potentially allowing unauthorized access. Learn more.

Severity: Low

VPC configuration should be enabled on Amazon Comprehend EntityRecognizer

Description: Defender for Cloud identified an Amazon Comprehend EntityRecognizer that is not configured to run inside a customer VPC. Without a VpcConfig, the training compute uses AWS-managed networking with default outbound internet access, providing no customer-controlled boundary on what the training job can reach. Configuring VpcConfig with security groups and subnets places the training compute inside the customer VPC, where Security Groups, route tables, and (optionally) VPC endpoints constrain its outbound network access. This restricts a compromised training-time component from exfiltrating training data (which often contains sensitive entity samples such as PII or business identifiers) to attacker-controlled endpoints, and enables VPC Flow Logs for audit.

Severity: Medium

Workgroup configuration enforcement should be enabled on Athena workgroups

Description: Defender for Cloud identified an Athena workgroup that does not enforce workgroup-level configuration. This poses a risk of client-side override attacks, where a caller supplies its own ResultConfiguration at query time (via SDK, JDBC, or API) to ship sensitive query results to an attacker-controlled S3 bucket or to weaken encryption, bypassing the workgroup's centrally defined output location and encryption controls.

Severity: High

Related content

• Learn about security recommendations
• Review security recommendations