Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Remediating exposures for Azure Storage blob containers

Amazon Security Hub can generate exposure findings for Azure Storage blob containers.

On the Security Hub console, the Azure Storage blob container involved in an exposure finding and its identifying information are listed in the Resources section of the finding details. Programmatically, you can retrieve resource details with the GetFindingsV2 operation of the Security Hub CSPM API.

After identifying the resource involved in an exposure finding, you can delete the resource if you don't need it. Deleting a nonessential resource can reduce your exposure profile and Amazon costs. If the resource is essential, follow these recommended remediation steps to help mitigate the risk. The remediation topics are divided based on the type of trait.

A single exposure finding contains issues identified in multiple remediation topics. Conversely, you can address an exposure finding and bring down its severity level by addressing just one remediation topic. Your approach to risk remediation depends on your organizational requirements and workloads.

Reachability traits for Azure Storage blob containers

Here are reachability traits for Azure Storage blob containers and suggested remediation steps.

The storage account allows anonymous blob access

When anonymous read access is enabled, unauthenticated clients can read blob data without authorization. When the storage account permits anonymous (public) blob access and a container's access level allows it, anyone on the public internet can read the data in that container. Following standard security principles, disallow anonymous access at the account level and require every request to be authorized, unless your scenario explicitly depends on public read access.

Remediation

Take one or more of the following actions to address this exposure:

Disallow anonymous access for the storage account

Set the storage account's AllowBlobPublicAccess property to false. Disallowing anonymous access at the account level overrides the access settings of all containers in the account and blocks future anonymous requests. For more information, see Prevent anonymous read access in the Microsoft Azure documentation.

Set the container access level to private

If individual containers were configured for public access, set each container's anonymous access level to Private so that all requests require authorization. Before changing the setting, review any client applications that might depend on anonymous access. For more information, see Configure anonymous read access in the Microsoft Azure documentation.

Misconfiguration traits for Azure Storage blob containers

Here are misconfiguration traits for Azure Storage blob containers and suggested remediation steps.

The storage account does not require HTTPS for transfer operations

When a storage account does not require secure transfer, it accepts requests over unencrypted HTTP. Data and credentials sent over HTTP can be intercepted or modified in transit by an attacker on the network path. Following standard security principles, require secure transfer so that the account accepts requests only over HTTPS.

Remediation

Take one or more of the following actions to address this exposure:

Require secure transfer

Enable the Secure transfer required property on the storage account (the enableHttpsTrafficOnly property). When secure transfer is required, any request made over HTTP is rejected. For more information, see Require secure transfer in the Microsoft Azure documentation.

Enforce a minimum TLS version

Set the storage account's minimum TLS version to 1.2 (the minimumTlsVersion property) so that requests that use older, less secure protocol versions are rejected. Confirm that your clients support TLS 1.2 before you enforce this setting. For more information, see Configure the minimum TLS version for a storage account in the Microsoft Azure documentation.

The storage account is not encrypted with customer-managed keys

By default, Azure Storage encrypts data at rest with Microsoft-managed keys. Customer-managed keys (CMK) give you control over the key that protects your data, including the ability to rotate, revoke, and audit access to the key. If your organization's compliance requirements call for control over encryption keys, the absence of customer-managed keys is a gap. Following data protection best practices, configure the storage account to use customer-managed keys stored in Azure Key Vault or a managed HSM.

Remediation: Configure customer-managed keys

Store a key in Azure Key Vault or Azure Key Vault Managed HSM, with soft delete and purge protection enabled. Grant a managed identity the get, wrapkey, and unwrapkey permissions, and then configure the storage account to use that key for encryption. You can switch between customer-managed and Microsoft-managed keys at any time. For more information, see Customer-managed keys for storage encryption in the Microsoft Azure documentation.

The storage account allows cross-tenant access

Cross-tenant access settings, such as cross-tenant object replication or cross-tenant shared access signature (SAS) delegation, can cause data to leave the Microsoft Entra tenant that owns the storage account. If your workload does not require sharing data across tenants, leaving these settings enabled increases the risk of data leaving your tenant boundary. Following standard security principles, disable cross-tenant access unless it is explicitly required.

Remediation: Disable cross-tenant access settings

On the storage account, disable cross-tenant object replication (set allowCrossTenantReplication to false) and, where supported, restrict cross-tenant SAS delegation. Review your replication and sharing requirements before making the change. For more information, see Azure Storage account overview in the Microsoft Azure documentation.

The storage account has blob soft delete disabled

Blob soft delete protects individual blobs, snapshots, and versions from accidental or malicious deletion and overwrite. It retains the deleted data for a configurable retention period, during which you can restore it. When soft delete is disabled, deleted or overwritten blob data cannot be recovered, which exposes your account to permanent data loss. Following data protection best practices, enable blob soft delete with an appropriate retention period.

Remediation: Enable blob soft delete

Enable blob soft delete on the storage account and set a retention period (1 to 365 days) that meets your recovery requirements. For more complete protection, enable container soft delete and blob versioning as well. For more information, see Soft delete for blobs in the Microsoft Azure documentation.

The storage account allows permanent deletion of soft-deleted blobs

When permanent delete is allowed (the allowPermanentDelete property is true), soft-deleted blobs and snapshots can be removed before the soft delete retention period expires. This undermines the protection that soft delete provides, because a user or a compromised principal can permanently destroy recoverable data before the retention period expires. Following data protection best practices, do not allow permanent deletion of soft-deleted blobs unless you have a specific, well-understood requirement.

Remediation: Disable permanent delete

Set the storage account's allowPermanentDelete property to false so that soft-deleted blobs and snapshots remain recoverable for the full retention period. For more information, see Soft delete for blobs in the Microsoft Azure documentation.

The Azure Storage blob container has blob versioning disabled

Blob versioning automatically maintains previous versions of a blob. When a blob is modified or deleted, the prior state is preserved as a previous version that you can restore. When versioning is disabled, overwrites and deletes cannot be rolled back to an earlier state, which increases the risk of unrecoverable data loss or corruption. Following data protection best practices, enable blob versioning, together with soft delete, for optimal data protection.

Remediation: Enable blob versioning

Enable versioning on the storage account's blob service. To control the cost of retaining many versions, use a lifecycle management policy to delete old versions automatically. For more information, see Blob versioning in the Microsoft Azure documentation.

The storage container does not have an immutability policy

An immutability policy stores blob data in a WORM (Write Once, Read Many) state. In this state, data cannot be modified or deleted for a specified interval (a time-based retention policy) or until a legal hold is cleared. Without an immutability policy, business-critical or compliance-relevant data in the container can be overwritten or deleted, including by privileged users. Where regulatory or data-integrity requirements apply, configure an immutability policy for the container.

Remediation: Configure an immutability policy

Configure a time-based retention policy or a legal hold on the container. Lock the time-based policy when testing is complete so that the data is fully protected in a WORM state. Enable soft delete before applying immutability policies for additional protection. For more information, see Immutable storage for blob data in the Microsoft Azure documentation.