TEST NAME

Ensure stored access policies SAP are used when generating shared access signature SAS tokens

Description

Use stored access policies (SAP) when generating shared access signature (SAS) tokens in Azure to centrally manage permissions, expiration, and revocation settings for resource access. Stored access policies can be applied to blob containers, file shares, queues, and tables.

Rationale

Stored access policies provide centralized control over SAS token access, allowing administrators to update permissions or revoke access. This approach strengthens security by reducing the risk of unauthorized access to storage resources.

Impact

There is no cost for creating stored access policies, however there is some administrative overhead involved in managing these policies.

Recommendation and Steps

**Remediate from Storage Explorer**

To create a SAP:

1. In Storage Explorer, expand `Storage Accounts`.
1. Expand a storage account.
1. Expand `Blob Containers`, `File Shares`, `Queues`, or `Tables`, and right-click a blob container, file share, queue, or table.
1. Click `Manage Stored Access Policies...`.
1. Under `Access Policies`, click `Add`.
1. Modify the `ID`, `Start time`, `Expiry time`, and permissions appropriately.
1. Click `Save`.
1. Repeat steps 1-7 as needed to create SAP.

When generating SAS, select a SAP from the `Access policy` drop-down.

**Remediate from Azure Portal**

If SAS have been created without a SAP, the SAS can be revoked by regenerating the storage account access keys:

**Note:** Regenerating access keys can affect any applications or Azure services that are dependent on the storage account key.

1. Go to `Storage accounts`.
1. Click on a storage account.
1. Under `Security + networking`, click `Access keys`.
1. Next to each key, click `Rotate key`.
1. Click `Yes` to confirm.
1. Repeat steps 1-5 as needed to revoke SAS.

Associated Items

Affected Objects

TEST NAME

Ensure Allowed Protocols for shared access signature SAS tokens is set to HTTPS Only

Description

Shared access signatures (SAS) can be used to grant limited access to Azure Storage resources. When generating a SAS, it is possible to specify the allowed protocols for a request made with the SAS. It is recommended to allow requests over HTTPS only.

Rationale

If a SAS is passed over HTTP and intercepted, an attacker performing a man-in-the-middle attack can read the SAS. Then, they can use that SAS just as the intended user could have. This can potentially compromise sensitive data or allow for data corruption by the malicious user.

Impact

SAS can pose security risks if they are not managed carefully.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure that shared access signature SAS tokens expire within an hour

Description

Shared access signature (SAS) tokens provide restricted access to Azure Storage resources (such as blobs, files, queues, or tables) for a defined time period with specific permissions. It enables users to interact with the resources without exposing account keys, offering precise control over the permitted actions (e.g., read, write) and the duration of access. To minimize security risks, SAS tokens should be configured with the shortest possible lifespan, ideally lasting no longer than an hour.

Rationale

A short lifespan for SAS tokens is recommended to minimize the risk of unauthorized access. SAS tokens grant time-limited access to resources, and a longer duration increases the opportunity for misuse if the token is compromised. By setting a shorter lifespan, the potential for security breaches is reduced.

Impact

SAS can pose security risks if they are not managed carefully.

Recommendation and Steps

**Remediate from Azure Portal**

If SAS have been created without a short lifespan and were created with a stored access policy (SAP), the SAS can be revoked by deleting the SAP or updating the SAP expiration time to a time in the past:

1. Go to `Storage accounts`.
1. Click on a storage account.
1. Under `Data storage`, click `Containers`.
1. Click the three dots next to a listed item.
1. Click `Access policy`.
1. Click the three dots next to an access policy.
1. Click `Delete`.
1. Click `Save`.
1. Repeat steps 1-8 as needed to revoke SAS created with SAP.

If SAS have been created without a short lifespan and were not created with a SAP, the SAS can be revoked by regenerating the storage account access keys:

**Note:** Regenerating access keys can affect any applications or Azure services that are dependent on the storage account key.

1. Go to `Storage accounts`.
1. Click on a storage account.
1. Under `Security + networking`, click `Access keys`.
1. Next to each key, click `Rotate key`.
1. Click `Yes` to confirm.
1. Repeat steps 1-5 as needed to revoke SAS.

Associated Items

Affected Objects

TEST NAME

Ensure Critical Data is Encrypted with Microsoft Managed Keys MMK

Description

Microsoft Managed Keys (MMK) [also known as Platform-managed keys (PMK)] provides a very low overhead method of encrypting data at rest and implementing encryption key management. Keys maintained in an MMK implementation are automatically managed by Azure and require no customer interaction.

Rationale

The encryption of data at rest is a foundational component of data security. Data at rest without encryption is easily compromised through loss or theft. Encrypting data at rest introduces confidentiality to the data by obfuscating the data contents with a cipher algorithm and provides an authentication requirement through the use of cryptographic keys. MMK makes the encryption of data at rest very easy to implement and maintain.

Impact

Recommendation and Steps

Microsoft Managed Keys (MMK) [also known as Platform-managed keys (PMK)] provides a very low overhead method of encrypting data at rest and implementing encryption key management. Keys maintained in an MMK implementation are automatically managed by Azure and require no customer interaction.

The encryption of data at rest is a foundational component of data security. Data at rest without encryption is easily compromised through loss or theft. Encrypting data at rest introduces confidentiality to the data by obfuscating the data contents with a cipher algorithm and provides an authentication requirement through the use of cryptographic keys. MMK makes the encryption of data at rest very easy to implement and maintain.

Associated Items

Affected Objects

TEST NAME

Ensure Critical Data is Encrypted with Customer Managed Keys CMK

Description

Customer Managed Keys introduce additional depth to security by providing a means to manage access control for encryption keys. Where compliance and security frameworks indicate the need, and organizational capacity allows, sensitive data at rest can be encrypted using Customer Managed Keys (CMK) rather than Microsoft Managed keys.

Rationale

By default in Azure, data at rest tends to be encrypted using Microsoft Managed Keys. If your organization want to control and manage encryption keys for compliance and defense-in-depth, Customer Managed Keys can be established. 

While it is possible to automate the assessment of this recommendation, the assessment status for this recommendation remains 'Manual' due to ideally limited scope. The scope of application - which workloads CMK is applied to - should be carefully considered to account for organizational capacity and targeted to workloads with specific need for CMK.

Impact

If the key expires due to setting the 'activation date' and 'expiration date', the key must be rotated manually.

Using Customer Managed Keys may also incur additional man-hour requirements to create, store, manage, and protect the keys as needed.

Recommendation and Steps

Customer Managed Keys introduce additional depth to security by providing a means to manage access control for encryption keys. Where compliance and security frameworks indicate the need, and organizational capacity allows, sensitive data at rest can be encrypted using Customer Managed Keys (CMK) rather than Microsoft Managed keys.

By default in Azure, data at rest tends to be encrypted using Microsoft Managed Keys. If your organization want to control and manage encryption keys for compliance and defense-in-depth, Customer Managed Keys can be established. 

While it is possible to automate the assessment of this recommendation, the assessment status for this recommendation remains 'Manual' due to ideally limited scope. The scope of application - which workloads CMK is applied to - should be carefully considered to account for organizational capacity and targeted to workloads with specific need for CMK.

Associated Items

Affected Objects

TEST NAME

Ensure Network Access Rules are set to Deny-by-default

Description

Restricting default network access provides a foundational level of security to networked resources. To limit access to selected networks, the default action must be changed.

Rationale

Resources using Virtual Network interfaces should be configured to deny-by-default all access from all networks (including internet traffic). Access can be granted to traffic from specific Azure Virtual networks, allowing a secure network boundary for specific applications to be built. If necessary, access can also be granted to public internet IP address ranges to enable connections from specific internet or on-premises clients.

For all traffic inbound from- and outbound to- the internet, a NAT Gateway is recommended at minimum, and ideally all traffic flows through a security gateway device such as a firewall. Security gateway devices will provide an additional level of visibility to inbound and outbound traffic and usually perform advanced monitoring and response activity such as intrusion detection and prevention (IDP), and deep packet inspection (DPI) which help detect activity indicating vulnerabilities and threats.

Impact

All allowed networks and protocols will need to be allow-listed which creates some administrative overhead. 

Implementing a deny-by-default rule may result in a loss of network connectivity. Careful planning and a scheduled implementation window allowing for downtime is highly recommended.

Recommendation and Steps

Restricting default network access provides a foundational level of security to networked resources. To limit access to selected networks, the default action must be changed.

Resources using Virtual Network interfaces should be configured to deny-by-default all access from all networks (including internet traffic). Access can be granted to traffic from specific Azure Virtual networks, allowing a secure network boundary for specific applications to be built. If necessary, access can also be granted to public internet IP address ranges to enable connections from specific internet or on-premises clients.

For all traffic inbound from- and outbound to- the internet, a NAT Gateway is recommended at minimum, and ideally all traffic flows through a security gateway device such as a firewall. Security gateway devices will provide an additional level of visibility to inbound and outbound traffic and usually perform advanced monitoring and response activity such as intrusion detection and prevention (IDP), and deep packet inspection (DPI) which help detect activity indicating vulnerabilities and threats.

Associated Items

Affected Objects

TEST NAME

Ensure public network access is Disabled

Description

Disable public network access to prevent exposure to the internet and reduce the risk of unauthorized access. Use private endpoints and Azure Role-Based Access Control (RBAC) to securely manage access within trusted networks.

Rationale

Disabling public network access improves security by ensuring that a service is not exposed on the public internet.

Impact

Disabling public network access restricts access to the service. This enhances security but may require the configuration of private endpoints for any services or users needing access within trusted networks.

Recommendation and Steps

Disable public network access to prevent exposure to the internet and reduce the risk of unauthorized access. Use private endpoints and Azure Role-Based Access Control (RBAC) to securely manage access within trusted networks.

Disabling public network access improves security by ensuring that a service is not exposed on the public internet.

Associated Items

Affected Objects

TEST NAME

Ensure Private Endpoints are used to access {service}

Description

Use private endpoints to allow clients and services to securely access data located over a network via an encrypted Private Link. To do this, the private endpoint uses an IP address from the VNet for each service. Network traffic between disparate services securely traverses encrypted over the VNet. This VNet can also link addressing space, extending your network and accessing resources on it. Similarly, it can be a tunnel through public networks to connect remote infrastructures together. This creates further security through segmenting network traffic and preventing outside sources from accessing it.

Rationale

Securing traffic between services through encryption protects the data from easy interception and reading.

Impact

A Private Endpoint costs approximately US$7.30 per month. If an Azure Virtual Network is not implemented correctly, this may result in the loss of critical network traffic.

Recommendation and Steps

Use private endpoints to allow clients and services to securely access data located over a network via an encrypted Private Link. To do this, the private endpoint uses an IP address from the VNet for each service. Network traffic between disparate services securely traverses encrypted over the VNet. This VNet can also link addressing space, extending your network and accessing resources on it. Similarly, it can be a tunnel through public networks to connect remote infrastructures together. This creates further security through segmenting network traffic and preventing outside sources from accessing it.

Securing traffic between services through encryption protects the data from easy interception and reading.

Associated Items

Affected Objects

TEST NAME

Ensure Key encryption key is set to a customer-managed key for Azure Managed Lustre file systems

Description

Enable customer-managed encryption keys (CMEK) for Azure Managed Lustre file systems to enhance data security and provide greater control over encryption processes. By using CMEK, organizations can manage their own encryption keys within Azure Key Vault, allowing them to rotate, revoke, or otherwise control access to these keys in accordance with their security policies.

Rationale

Using customer-managed encryption keys (CMEK) gives organizations complete control over encryption keys, ensuring compliance and enhancing data security. CMEK allows for key rotation, revocation, and lifecycle management, thus improving data protection and facilitating immediate control over data access in Azure Managed Lustre file systems.

Impact

There are costs and configuration overhead associated with setting up and managing customer-managed keys.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure soft delete on Backup vaults is Enabled

Description

Soft delete provides additional protection for Backup vault data. With soft delete enabled, deleted backup data can be recovered within the retention period.

Rationale

Important backup data could be accidentally deleted or removed by a malicious actor. With soft delete enabled, data is retained for at least 14 days before permanent deletion, allowing for the recovery of the backup data.

Impact

There is no additional cost for backup data in the soft delete state for up to and including 14 days. However, retention beyond 14 days may incur additional charges.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure immutability for Backup vaults is Enabled

Description

Immutable vaults safeguard backup data by preventing any operations that could result in the loss of recovery points. The immutable vault setting can be locked, making it irreversible and preventing malicious actors from disabling it and deleting backups.

Rationale

Enabling the immutable vault ensures that backup data is protected from unauthorized or accidental deletion. By locking the setting and making it irreversible, malicious actors are prevented from disabling the setting and deleting backups.

Impact

There is no additional cost for enabling vault immutability; however, a vault with locked immutability cannot be deleted without contacting Azure support and will incur the standard vault costs.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure backup data in Backup vaults is encrypted using customer-managed keys CMK

Description

Backup vaults offer two encryption options: Microsoft-managed keys, which provide automatic encryption without user intervention, and customer-managed keys (CMK), which allow organizations to retain full control over their encryption keys for enhanced security and compliance.

Rationale

Using customer-managed keys (CMKs) to encrypt Backup vaults enhances security by granting organizations complete control over their encryption keys.

Impact

There are costs and configuration overhead associated with setting up and managing customer-managed keys.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure Use infrastructure encryption for this vault is enabled on Backup vaults

Description

In addition to using customer-managed keys for encryption at rest in the Backup vault, you can enable an additional layer of platform-managed infrastructure encryption. This dual-layer approach enhances the protection of your backup data.

Rationale

Enabling infrastructure encryption on a Backup vault adds a second layer of protection to backup data, enhancing security and ensuring compliance for sensitive data storage. This dual-layer strategy reduces the risk of unauthorized access by keeping data encrypted even if one layer is compromised.

Impact

Enabling infrastructure encryption on a backup vault does not incur additional costs; however, infrastructure encryption must be configured when creating the vault and requires customer-managed keys for encryption at rest. This recommendation is linked to `Ensure backup data in Backup vaults is encrypted using customer-managed keys (CMK)` and should be applied alongside it if you choose to implement this recommendation.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure Cross Region Restore is set to Enabled on Backup vaults

Description

Cross region restore enables data restoration in a secondary Azure paired region, even when the primary region is fully operational. This allows organizations to conduct drills and validate regional resiliency, thereby ensuring preparedness for potential outages.

Rationale

Enabling cross region restore facilitates proactive resilience testing and disaster recovery planning by allowing data restoration drills in a secondary region without needing a primary region outage. This capability helps organizations validate recovery processes, identify gaps in regional failover, and ensures critical data can be accessed and restored during real disruptions.

Impact

Enabling cross region restore on a Backup vault incurs additional costs, and once it is enabled, it cannot be disabled.

- Cross region restore is an irreversible storage property.
- Cross region restore is currently supported for limited workloads.
- Cross region restore can only be enabled if the redundancy of the vault is GRS.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure Cross Subscription Restore is set to Disabled or Permanently Disabled on Backup vaults

Description

Disable cross subscription restore for Backup vaults to ensure that backup data can only be restored within the same subscription as the Backup vault, preventing restoration to targets in other subscriptions.

Rationale

Cross subscription restores increases security risks by widening access to sensitive backup data, potentially leading to accidental or intentional exposure, unauthorized access, or data exfiltration across environments.

Impact

Organizations may need to consider alternatives for disaster recovery scenarios, and if utilizing multiple subscriptions, may need to make adjustments or consider alternatives for data access. Costs could be incurred if alternative or additional backup infrastructure is required to account for the disabling of cross subscription restore.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure soft delete on Recovery Services vaults is Enabled

Description

Soft delete provides additional protection for Recovery Services vault data. With soft delete enabled, deleted backup data can be recovered within the retention period.

Rationale

Important backup data could be accidentally deleted or removed by a malicious actor. With soft delete enabled, data is retained for at least 14 days before permanent deletion, allowing for the recovery of the backup data.

Impact

There is no additional cost for backup data in the soft delete state for up to and including 14 days. However, retention beyond 14 days may incur additional charges.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure immutability for Recovery Services vaults is Enabled

Description

Immutable vaults safeguard backup data by preventing any operations that could result in the loss of recovery points. The immutable vault setting can be locked, making it irreversible and preventing malicious actors from disabling it and deleting backups.

Rationale

Enabling the immutable vault ensures that backup data is protected from unauthorized or accidental deletion. By locking the setting and making it irreversible, malicious actors are prevented from disabling the setting and deleting backups.

Impact

There is no additional cost for enabling vault immutability; however, a vault with locked immutability cannot be deleted without contacting Azure support and will incur the standard vault costs.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure backup data in Recovery Services vaults is encrypted using customer-managed keys CMK

Description

Recovery Services vaults offer two encryption options: Microsoft-managed keys, which provide automatic encryption without user intervention, and customer-managed keys (CMK), which allow organizations to retain full control over their encryption keys for enhanced security and compliance.

Rationale

Using customer-managed keys (CMKs) to encrypt Recovery Services vaults enhances security by granting organizations complete control over their encryption keys.

Impact

There are costs and configuration overhead associated with setting up and managing customer-managed keys.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure Use infrastructure encryption for this vault is enabled on Recovery Services vaults

Description

In addition to using customer-managed keys for encryption at rest in the Recovery Services vault, you can enable an additional layer of platform-managed infrastructure encryption. This dual-layer approach enhances the protection of your backup data.

Rationale

Enabling infrastructure encryption on an Azure Recovery Services vault adds a second layer of protection to backup data, enhancing security and ensuring compliance for sensitive data storage. This dual-layer strategy reduces the risk of unauthorized access by keeping data encrypted even if one layer is compromised.

Impact

Enabling infrastructure encryption on an Azure Recovery Services vault does not incur additional costs; however infrastructure encryption must be set when configuring the encryption of the vault for the first time and requires customer-managed keys for encryption at rest. Once configured, the infrastructure encryption setting cannot be changed. This recommendation is linked to `Ensure that backup data in Recovery Services vaults is encrypted using customer-managed keys (CMK)` and should be applied alongside it if you choose to implement this recommendation.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure public network access on Recovery Services vaults is Disabled

Description

Disable public network access on Recovery Services vaults to prevent exposure to the internet and reduce the risk of unauthorized access. Use private endpoints and Azure Role-Based Access Control (RBAC) to securely manage access within trusted networks.

Rationale

Disabling public network access improves security by ensuring that a Recovery Services vault is not exposed on the public internet.

Impact

Disabling public network access on Recovery Services vaults restricts access to the vault. This enhances security but may require the configuration of private endpoints for any services or users needing access within trusted networks.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure Cross Region Restore is set to Enabled on Recovery Services vaults

Description

Cross region restore enables data restoration in a secondary Azure paired region, even when the primary region is fully operational. This allows organizations to conduct drills and validate regional resiliency, thereby ensuring preparedness for potential outages.

Rationale

Enabling cross region restore facilitates proactive resilience testing and disaster recovery planning by allowing data restoration drills in a secondary region without needing a primary region outage. This capability helps organizations validate recovery processes, identify gaps in regional failover, and ensures critical data can be accessed and restored during real disruptions.

Impact

Enabling cross region restore on a Recovery Services vault incurs additional costs, and once it is enabled, it cannot be disabled.

- Cross region restore can only be enabled on Recovery Services vaults using the GRS replication type.
- Cross region restore is available for Azure Virtual Machines, SQL/SAP HANA databases running inside Azure VMs, and Recovery Services Agent (Preview) in the vault. There is no support for classic VMs.
- Cross region restore is currently an irreversible storage property.
- When cross region restore is enabled, Azure upgrades backup storage from GRS to read-access geo-redundant storage (RA-GRS). Pricing is updated accordingly.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure Cross Subscription Restore is set to Disabled or Permanently Disabled on Recovery Services vaults

Description

Disable cross subscription restore for Recovery Services vaults to ensure that backup data can only be restored within the same subscription as the Recovery Services vault, preventing restoration to targets in other subscriptions.

Rationale

Cross subscription restores increases security risks by widening access to sensitive backup data, potentially leading to accidental or intentional exposure, unauthorized access, or data exfiltration across environments.

Impact

Organizations may need to consider alternatives for disaster recovery scenarios, and if utilizing multiple subscriptions, may need to make adjustments or consider alternatives for data access. Costs could be incurred if alternative or additional backup infrastructure is required to account for the disabling of cross subscription restore.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure soft delete for Azure File Shares is Enabled

Description

Azure Files offers soft delete for file shares, allowing you to easily recover your data when it is mistakenly deleted by an application or another storage account user.

Rationale

Important data could be accidentally deleted or removed by a malicious actor. With soft delete enabled, the data is retained for the defined retention period before permanent deletion, allowing for recovery of the data.

Impact

When a file share is soft-deleted, the used portion of the storage is charged for the indicated soft-deleted period. All other meters are not charged unless the share is restored.

Recommendation and Steps

**Remediate from Azure Portal**

1. Go to `Storage Accounts`.
1. For each storage account with file shares, under `Data storage`, click `File shares`.
1. Under `File share settings`, click the value next to `Soft delete`.
1. Under `Soft delete for all file shares`, click the toggle to set it to `Enabled`.
1. Under `Retention policies`, set an appropriate number of days to retain soft deleted data between 1 and 365, inclusive.
1. Click `Save`.

**Remediate from Azure CLI**

For each storage account requiring remediation, run the following command to enable soft delete for file shares and set an appropriate number of days for deleted data to be retained, between 1 and 365, inclusive:

```
az storage account file-service-properties update --account-name  --enable-delete-retention true --delete-retention-days 
```

**Remediate from PowerShell**

For each storage account requiring remediation, run the following command to enable soft delete for file shares and set an appropriate number of days for deleted data to be retained, between 1 and 365, inclusive:

```
Update-AzStorageFileServiceProperty -ResourceGroupName  -AccountName  -EnableShareDeleteRetentionPolicy $true -ShareRetentionDays  
```

Associated Items

Affected Objects

TEST NAME

Ensure SMB protocol version is set to SMB 3.1.1 or higher for SMB file shares

Description

Ensure that SMB file shares are configured to use the latest supported SMB protocol version. Keeping the SMB protocol updated helps mitigate risks associated with older SMB versions, which may contain vulnerabilities and lack essential security controls.

Rationale

Using the latest supported SMB protocol version enhances the security of SMB file shares by preventing the exploitation of known vulnerabilities in outdated SMB versions.

Impact

Using the latest SMB protocol version may impact client compatibility.

Recommendation and Steps

**Remediate from Azure Portal**

1. Go to `Storage accounts`.
1. Click the name of a storage account.
1. Under `Data storage`, click `File shares`.
1. Under `File share settings`, click the link next to `Security`.
1. If `Profile` is set to `Maximum compatibility`, click the drop-down menu and select `Maximum security` or `Custom`.
1. If selecting `Custom`, under `SMB protocol versions`, uncheck the boxes next to `SMB 2.1` and `SMB 3.0`.
1. Click `Save`.
1. Repeat steps 1-7 for each storage account requiring remediation.

**Remediate from Azure CLI**

For each storage account requiring remediation, run the following command to set the SMB protocol version:

```
az storage account file-service-properties update --resource-group  --account-name  --versions SMB3.1.1
```

**Remediate from PowerShell**

For each storage account requiring remediation, run the following command to set the SMB protocol version:

```
Update-AzStorageFileServiceProperty -ResourceGroupName  -StorageAccountName  -SmbProtocolVersion SMB3.1.1
```

Associated Items

Affected Objects

TEST NAME

Ensure SMB channel encryption is set to AES-256-GCM or higher for SMB file shares

Description

Implement SMB channel encryption with AES-256-GCM for SMB file shares to ensure data confidentiality and integrity in transit. This method offers strong protection against eavesdropping and man-in-the-middle attacks, safeguarding sensitive information.

Rationale

AES-256-GCM encryption enhances the security of data transmitted over SMB channels by safeguarding it from unauthorized interception and tampering.

Impact

Using the AES-256-GCM SMB channel encryption may impact client compatibility.

Recommendation and Steps

**Remediate from Azure Portal**

1. Go to `Storage accounts`.
1. Click the name of a storage account.
1. Under `Data storage`, click `File shares`.
1. Under `File share settings`, click the link next to `Security`.
1. If `Profile` is set to `Maximum compatibility`, click the drop-down menu and select `Maximum security` or `Custom`.
1. If selecting `Custom`, under `SMB channel encryption`, uncheck the boxes next to `AES-128-CCM` and `AES-128-GCM`.
1. Click `Save`.
1. Repeat steps 1-7 for each storage account requiring remediation.

**Remediate from Azure CLI**

For each storage account requiring remediation, run the following command to set the SMB channel encryption:

```
az storage account file-service-properties update --resource-group  --account-name  --channel-encryption AES-256-GCM
```

**Remediate from PowerShell**

For each storage account requiring remediation, run the following command to set the SMB channel encryption:

```
Update-AzStorageFileServiceProperty -ResourceGroupName  -StorageAccountName  -SmbChannelEncryption AES-256-GCM
```

Associated Items

Affected Objects

TEST NAME

Ensure root squash for NFS file shares is configured

Description

Permissions for NFS file shares are enforced by the client OS rather than by the Azure Files service. Root squash is an administrative security feature in NFS that prevents unauthorized root-level access to the NFS server by client machines. This functionality is an important part of protecting user data and system settings from manipulation by untrusted or compromised clients.

Rationale

Administrators should enable root squash in environments where multiple users or systems access the NFS share, especially in scenarios where client machines are not fully trusted. By converting root users to anonymous users, root squash ensures that even if a client machine is compromised, the attacker cannot exploit root privileges to access or modify critical files on the NFS server.

Impact

There is no additional cost associated with enabling root squash; however, there may be some minor administrative overhead involved in configuring and managing permissions with root squash enabled.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure Encryption key source is set to Customer Managed Key for Azure NetApp Files accounts

Description

Customer-managed keys (CMK) for Azure NetApp Files volume encryption enable organizations to use their own keys instead of platform-managed ones, providing full control over encryption.

Rationale

Using customer-managed keys (CMKs) to encrypt Azure NetApp Files volumes enhances security by granting organizations complete control over their encryption keys.

Impact

There are costs and configuration overhead associated with setting up and managing customer-managed keys.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure that soft delete for blobs on Azure Blob Storage storage accounts is Enabled

Description

Blobs in Azure storage accounts may contain sensitive or personal data, such as ePHI or financial information. Data that is erroneously modified or deleted by an application or a user can lead to data loss or unavailability.

It is recommended that soft delete be enabled on Azure storage accounts with blob storage to allow for the preservation and recovery of data when blobs or blob snapshots are deleted.

Rationale

Blobs can be deleted incorrectly. An attacker or malicious user may do this deliberately in order to cause disruption. Deleting an Azure storage blob results in immediate data loss. Enabling this configuration for Azure storage accounts ensures that even if blobs are deleted from the storage account, the blobs are recoverable for a specific period of time, which is defined in the Retention policies, ranging from 7 to 365 days.

Impact

All soft-deleted data is billed at the same rate as active data. Additional costs may be incurred for deleted blobs until the soft delete period ends and the data is permanently removed.

Recommendation and Steps

**Remediate from Azure Portal**

1. Go to `Storage Accounts`.
1. For each Storage Account with blob storage, under `Data management`, go to `Data protection`.
1. Check the box next to `Enable soft delete for blobs`.
1. Set the retention period to a sufficient length for your organization.
1. Click `Save`.

**Remediate from Azure CLI**

For each storage account requiring remediation, run the following command to enable soft delete for blobs:

```
az storage blob service-properties delete-policy update --days-retained  --account-name  --enable true
```

Associated Items

Affected Objects

TEST NAME

Ensure stored access policies SAP are used when generating shared access signature SAS tokens

Description

Use stored access policies (SAP) when generating shared access signature (SAS) tokens in Azure to centrally manage permissions, expiration, and revocation settings for resource access. Stored access policies can be applied to blob containers, file shares, queues, and tables.

Rationale

Stored access policies provide centralized control over SAS token access, allowing administrators to update permissions or revoke access. This approach strengthens security by reducing the risk of unauthorized access to storage resources.

Impact

There is no cost for creating stored access policies, however there is some administrative overhead involved in managing these policies.

Recommendation and Steps

**Remediate from Storage Explorer**

To create a SAP:

1. In Storage Explorer, expand `Storage Accounts`.
1. Expand a storage account.
1. Expand `Blob Containers`, `File Shares`, `Queues`, or `Tables`, and right-click a blob container, file share, queue, or table.
1. Click `Manage Stored Access Policies...`.
1. Under `Access Policies`, click `Add`.
1. Modify the `ID`, `Start time`, `Expiry time`, and permissions appropriately.
1. Click `Save`.
1. Repeat steps 1-7 as needed to create SAP.

When generating SAS, select a SAP from the `Access policy` drop-down.

**Remediate from Azure Portal**

If SAS have been created without a SAP, the SAS can be revoked by regenerating the storage account access keys:

**Note:** Regenerating access keys can affect any applications or Azure services that are dependent on the storage account key.

1. Go to `Storage accounts`.
1. Click on a storage account.
1. Under `Security + networking`, click `Access keys`.
1. Next to each key, click `Rotate key`.
1. Click `Yes` to confirm.
1. Repeat steps 1-5 as needed to revoke SAS.

Associated Items

Affected Objects

TEST NAME

Ensure Versioning is set to Enabled on Azure Blob Storage storage accounts

Description

Enabling blob versioning allows for the automatic retention of previous versions of objects. With blob versioning enabled, earlier versions of a blob are accessible for data recovery in the event of modifications or deletions.

Rationale

Blob versioning safeguards data integrity and enables recovery by retaining previous versions of stored objects, facilitating quick restoration from accidental deletion, modification, or malicious activity.

Impact

Enabling blob versioning for a storage account creates a new version with each write operation to a blob, which can increase storage costs. To control these costs, a lifecycle management policy can be applied to automatically delete older versions.

Recommendation and Steps

**Remediate from Azure Portal**

1. Go to `Storage accounts`.
1. Click the name of a storage account with blob storage.
1. In the `Overview` page, on the `Properties` tab, under `Blob service`, click `Disabled` next to `Versioning`.
1. Under `Tracking`, check the box next to `Enable versioning for blobs`.
1. Select the radio button next to `Keep all versions` or `Delete versions after (in days)`.
1. If selecting to delete versions, enter a number of in the box after which to delete blob versions.
1. Click `Save`.
1. Repeat steps 1-7 for each storage account with blob storage.

**Remediate from Azure CLI**

For each storage account requiring remediation, run the following command to enable blob versioning:

```
az storage account blob-service-properties update --account-name  --enable-versioning true
```

**Remediate from PowerShell**

For each storage account requiring remediation, run the following command to enable blob versioning:

```
Update-AzStorageBlobServiceProperty -ResourceGroupName  -StorageAccountName  -IsVersioningEnabled $true
```

Associated Items

Affected Objects

TEST NAME

Ensure Allowed Protocols for shared access signature SAS tokens is set to HTTPS Only

Description

Shared access signatures (SAS) can be used to grant limited access to Azure Storage resources. When generating a SAS, it is possible to specify the allowed protocols for a request made with the SAS. It is recommended to allow requests over HTTPS only.

Rationale

If a SAS is passed over HTTP and intercepted, an attacker performing a man-in-the-middle attack can read the SAS. Then, they can use that SAS just as the intended user could have. This can potentially compromise sensitive data or allow for data corruption by the malicious user.

Impact

SAS can pose security risks if they are not managed carefully.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure locked immutability policies are used for containers storing business-critical blob data

Description

Require locked immutability policies for all containers that store business-critical blob data. This measure protects the data from modifications or deletions, ensuring that critical information remains intact and unaltered, regardless of user actions or access permissions.

Rationale

Implementing a locked immutability policy creates a Write Once, Read Many (WORM) storage model that safeguards critical data from accidental or malicious changes and deletions. Enforcing immutability minimizes data loss and tampering risks, enhancing data security and supporting regulatory requirements for data retention and integrity.

Impact

Enforcing locked immutability policies for blob storage may increase long-term retention costs and require additional administrative effort for policy management.

Once the policy is locked, the container cannot be deleted or edited, and the storage account cannot be deleted until the retention period has elapsed.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure that shared access signature SAS tokens expire within an hour

Description

Shared access signature (SAS) tokens provide restricted access to Azure Storage resources (such as blobs, files, queues, or tables) for a defined time period with specific permissions. It enables users to interact with the resources without exposing account keys, offering precise control over the permitted actions (e.g., read, write) and the duration of access. To minimize security risks, SAS tokens should be configured with the shortest possible lifespan, ideally lasting no longer than an hour.

Rationale

A short lifespan for SAS tokens is recommended to minimize the risk of unauthorized access. SAS tokens grant time-limited access to resources, and a longer duration increases the opportunity for misuse if the token is compromised. By setting a shorter lifespan, the potential for security breaches is reduced.

Impact

SAS can pose security risks if they are not managed carefully.

Recommendation and Steps

**Remediate from Azure Portal**

If SAS have been created without a short lifespan and were created with a stored access policy (SAP), the SAS can be revoked by deleting the SAP or updating the SAP expiration time to a time in the past:

1. Go to `Storage accounts`.
1. Click on a storage account.
1. Under `Data storage`, click `Containers`.
1. Click the three dots next to a listed item.
1. Click `Access policy`.
1. Click the three dots next to an access policy.
1. Click `Delete`.
1. Click `Save`.
1. Repeat steps 1-8 as needed to revoke SAS created with SAP.

If SAS have been created without a short lifespan and were not created with a SAP, the SAS can be revoked by regenerating the storage account access keys:

**Note:** Regenerating access keys can affect any applications or Azure services that are dependent on the storage account key.

1. Go to `Storage accounts`.
1. Click on a storage account.
1. Under `Security + networking`, click `Access keys`.
1. Next to each key, click `Rotate key`.
1. Click `Yes` to confirm.
1. Repeat steps 1-5 as needed to revoke SAS.

Associated Items

Affected Objects

TEST NAME

Ensure double encryption is used for Azure Data Box in high-security environments

Description

Enabling double encryption on Azure Data Box applies an additional layer of encryption to safeguard data during physical transfer. This approach enhances confidentiality and integrity, ensuring that sensitive information remains secure against unauthorized access if the device is lost, stolen, or intercepted.

Rationale

Double encryption ensures strong security for high-risk or regulated environments where data protection is critical. It enhances defense-in-depth and minimizes the risk of exposure, even during physical compromise in transit.

Impact

Double encryption with Azure Data Box is available at no additional cost; however, enabling it may increase order processing and data copy times.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure Public network access is set to Disabled on Azure Elastic SAN

Description

Azure Elastic SAN is a scalable, high-performance cloud-based storage solution. Disabling public network access at the SAN level ensures that Elastic SAN resources are accessible only through private networks.

Rationale

Disabling public network access for Azure Elastic SAN at the SAN level enhances security by preventing unauthorized external access to sensitive storage resources.

Impact

Disabling public network access at the SAN level incurs no direct cost. However, there may be costs and configuration overhead associated with setting up and managing private network access to securely connect to Azure Elastic SAN resources.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure customer-managed keys CMK are used to encrypt data at rest on Azure Elastic SAN volume groups

Description

Azure Elastic SAN volume groups offer two encryption options: Microsoft-managed keys, which provide automatic encryption without user intervention, and customer-managed keys (CMK), which allow organizations to retain full control over their encryption keys for enhanced security and compliance.

Rationale

Using customer-managed keys (CMKs) to encrypt Azure Elastic SAN volume groups enhances security by granting organizations complete control over their encryption keys.

Impact

There are costs and configuration overhead associated with setting up and managing customer-managed keys.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure stored access policies SAP are used when generating shared access signature SAS tokens

Description

Use stored access policies (SAP) when generating shared access signature (SAS) tokens in Azure to centrally manage permissions, expiration, and revocation settings for resource access. Stored access policies can be applied to blob containers, file shares, queues, and tables.

Rationale

Stored access policies provide centralized control over SAS token access, allowing administrators to update permissions or revoke access. This approach strengthens security by reducing the risk of unauthorized access to storage resources.

Impact

There is no cost for creating stored access policies, however there is some administrative overhead involved in managing these policies.

Recommendation and Steps

**Remediate from Storage Explorer**

To create a SAP:

1. In Storage Explorer, expand `Storage Accounts`.
1. Expand a storage account.
1. Expand `Blob Containers`, `File Shares`, `Queues`, or `Tables`, and right-click a blob container, file share, queue, or table.
1. Click `Manage Stored Access Policies...`.
1. Under `Access Policies`, click `Add`.
1. Modify the `ID`, `Start time`, `Expiry time`, and permissions appropriately.
1. Click `Save`.
1. Repeat steps 1-7 as needed to create SAP.

When generating SAS, select a SAP from the `Access policy` drop-down.

**Remediate from Azure Portal**

If SAS have been created without a SAP, the SAS can be revoked by regenerating the storage account access keys:

**Note:** Regenerating access keys can affect any applications or Azure services that are dependent on the storage account key.

1. Go to `Storage accounts`.
1. Click on a storage account.
1. Under `Security + networking`, click `Access keys`.
1. Next to each key, click `Rotate key`.
1. Click `Yes` to confirm.
1. Repeat steps 1-5 as needed to revoke SAS.

Associated Items

Affected Objects

TEST NAME

Ensure Allowed Protocols for shared access signature SAS tokens is set to HTTPS Only

Description

Shared access signatures (SAS) can be used to grant limited access to Azure Storage resources. When generating a SAS, it is possible to specify the allowed protocols for a request made with the SAS. It is recommended to allow requests over HTTPS only.

Rationale

If a SAS is passed over HTTP and intercepted, an attacker performing a man-in-the-middle attack can read the SAS. Then, they can use that SAS just as the intended user could have. This can potentially compromise sensitive data or allow for data corruption by the malicious user.

Impact

SAS can pose security risks if they are not managed carefully.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure that shared access signature SAS tokens expire within an hour-CISStorageTwo

Description

Shared access signature (SAS) tokens provide restricted access to Azure Storage resources (such as blobs, files, queues, or tables) for a defined time period with specific permissions. It enables users to interact with the resources without exposing account keys, offering precise control over the permitted actions (e.g., read, write) and the duration of access. To minimize security risks, SAS tokens should be configured with the shortest possible lifespan, ideally lasting no longer than an hour.

Rationale

A short lifespan for SAS tokens is recommended to minimize the risk of unauthorized access. SAS tokens grant time-limited access to resources, and a longer duration increases the opportunity for misuse if the token is compromised. By setting a shorter lifespan, the potential for security breaches is reduced.

Impact

SAS can pose security risks if they are not managed carefully.

Recommendation and Steps

**Remediate from Azure Portal**

If SAS have been created without a short lifespan and were created with a stored access policy (SAP), the SAS can be revoked by deleting the SAP or updating the SAP expiration time to a time in the past:

1. Go to `Storage accounts`.
1. Click on a storage account.
1. Under `Data storage`, click `Queues`.
1. Click the three dots next to a listed item.
1. Click `Access policy`.
1. Click the three dots next to an access policy.
1. Click `Delete`.
1. Click `Save`.
1. Repeat steps 1-8 as needed to revoke SAS created with SAP.

If SAS have been created without a short lifespan and were not created with a SAP, the SAS can be revoked by regenerating the storage account access keys:

**Note:** Regenerating access keys can affect any applications or Azure services that are dependent on the storage account key.

1. Go to `Storage accounts`.
1. Click on a storage account.
1. Under `Security + networking`, click `Access keys`.
1. Next to each key, click `Rotate key`.
1. Click `Yes` to confirm.
1. Repeat steps 1-5 as needed to revoke SAS.

Associated Items

Affected Objects

TEST NAME

Ensure that Enable Infrastructure Encryption for Each Storage Account in Azure Storage is Set to enabled

Description

Enabling encryption at the hardware level on top of the default software encryption for Storage Accounts accessing Azure storage solutions.

Rationale

Azure Storage automatically encrypts all data in a storage account at the network level using 256-bit AES encryption, which is one of the strongest, FIPS 140-2-compliant block ciphers available. Customers who require higher levels of assurance that their data is secure can also enable 256-bit AES encryption at the Azure Storage infrastructure level for double encryption. Double encryption of Azure Storage data protects against a scenario where one of the encryption algorithms or keys may be compromised. Similarly, data is encrypted even before network transmission and in all backups. In this scenario, the additional layer of encryption continues to protect your data. For the most secure implementation of key based encryption, it is recommended to use a Customer Managed asymmetric RSA 2048 Key in Azure Key Vault.

Impact

The read and write speeds to the storage will be impacted if both default encryption and Infrastructure Encryption are checked, as a secondary form of encryption requires more resource overhead for the cryptography of information. This performance impact should be considered in an analysis for justifying use of the feature in your environment. Customer-managed keys are recommended for the most secure implementation, leading to overhead of key management. The key will also need to be backed up in a secure location, as loss of the key will mean loss of the information in the storage.

Recommendation and Steps

**Remediate from Azure Portal**

1. During Storage Account creation, in the `Encryption` tab, check the box next to `Enable infrastructure encryption`.

**Remediate from Azure CLI**

Replace the information within <> with appropriate values:

```
az storage account create \
 --name  \
 --resource-group  \
 --location  \
 --sku Standard_RAGRS \
 --kind StorageV2 \
 --require-infrastructure-encryption
```

**Remediate from PowerShell**

Replace the information within <> with appropriate values:

```
New-AzStorageAccount -ResourceGroupName  `
 -AccountName  `
 -Location  `
 -SkuName Standard_RAGRS `
 -Kind StorageV2 `
 -RequireInfrastructureEncryption
```

**Enabling Infrastructure Encryption after Storage Account Creation**

If infrastructure encryption was not enabled on blob storage creation, there is no ***official*** way to enable it. Please see the additional information section.

Associated Items

Affected Objects

TEST NAME

Ensure Soft Delete is Enabled for Azure Containers and Blob Storage

Description

The Azure Storage blobs contain data like ePHI or Financial, which can be secret or personal. Data that is erroneously modified or deleted by an application or other storage account user will cause data loss or unavailability.

It is recommended that both Azure Containers with attached Blob Storage and standalone containers with Blob Storage be made recoverable by enabling the **soft delete** configuration. This is to save and recover data when blobs or blob snapshots are deleted.

Rationale

Containers and Blob Storage data can be incorrectly deleted. An attacker/malicious user may do this deliberately in order to cause disruption. Deleting an Azure Storage blob causes immediate data loss. Enabling this configuration for Azure storage ensures that even if blobs/data were deleted from the storage account, Blobs/data objects are recoverable for a particular time which is set in the Retention policies, ranging from 7 days to 365 days.

Impact

Additional storage costs may be incurred as snapshots are retained.

Recommendation and Steps

**Remediate from Azure Portal**
1. Go to `Storage Accounts`.
1. For each Storage Account, under `Data management`, go to `Data protection`.
1. Check the box next to `Enable soft delete for blobs`.
1. Check the box next to `Enable soft delete for containers`.
1. Set the retention period for both to a sufficient length for your organization.
1. Click `Save`.

**Remediate from Azure CLI**

Update blob storage retention days in below command
```
az storage blob service-properties delete-policy update --days-retained  --account-name  --account-key  --enable true
```
Update container retention with the below command
```
az storage account blob-service-properties update
 --enable-container-delete-retention true
 --container-delete-retention-days 
 --account-name 
 --resource-group 
```

Associated Items

Affected Objects

TEST NAME

Ensure Storage Logging is Enabled for Queue Service for Read Write and Delete requests

Description

The Storage Queue service stores messages that may be read by any client who has access to the storage account. A queue can contain an unlimited number of messages, each of which can be up to 64KB in size using version 2011-08-18 or newer. Storage Logging happens server-side and allows details for both successful and failed requests to be recorded in the storage account. These logs allow users to see the details of read, write, and delete operations against the queues. Storage Logging log entries contain the following information about individual requests: Timing information such as start time, end-to-end latency, and server latency, authentication details, concurrency information, and the sizes of the request and response messages.

Rationale

Storage Analytics logs contain detailed information about successful and failed requests to a storage service. This information can be used to monitor individual requests and to diagnose issues with a storage service. Requests are logged on a best-effort basis.

Storage Analytics logging is not enabled by default for your storage account.

Impact

Enabling this setting can have a high impact on the cost of the log analytics service and data storage used by logging more data per each request. Do not enable this without determining your need for this level of logging, and do not forget to check in on data usage and projected cost. Some users have seen their logging costs increase from $10 per month to $10,000 per month.

Recommendation and Steps

**Remediate from Azure Portal**

1. Go to `Storage Accounts`.
1. For each storage account, under `Monitoring`, click `Diagnostics settings`.
1. Select the `queue` tab indented below the storage account.
1. To create a new diagnostic setting, click `+ Add diagnostic setting`. To update an existing diagnostic setting, click `Edit setting` on the diagnostic setting.
1. Check the boxes next to `StorageRead`, `StorageWrite`, and `StorageDelete`.
1. Select an appropriate destination.
1. Click `Save`.

**Remediate from Azure CLI**

Use the below command to enable the Storage Logging for Queue service.
```
az storage logging update --account-name  --account-key  --services q --log rwd --retention 90
```

Associated Items

Affected Objects

TEST NAME

Ensure Storage logging is Enabled for Blob Service for Read Write and Delete requests

Description

The Storage Blob service provides scalable, cost-efficient object storage in the cloud. Storage Logging happens server-side and allows details for both successful and failed requests to be recorded in the storage account. These logs allow users to see the details of read, write, and delete operations against the blobs. Storage Logging log entries contain the following information about individual requests: timing information such as start time, end-to-end latency, and server latency; authentication details; concurrency information; and the sizes of the request and response messages.

Rationale

Storage Analytics logs contain detailed information about successful and failed requests to a storage service. This information can be used to monitor each individual request to a storage service for increased security or diagnostics. Requests are logged on a best-effort basis.

Storage Analytics logging is not enabled by default for your storage account.

Impact

Being a level 2, enabling this setting can have a high impact on the cost of data storage used for logging more data per each request. Do not enable this without determining your need for this level of logging or forget to check in on data usage and projected cost.

Recommendation and Steps

**Remediate from Azure Portal**

1. Go to `Storage Accounts`.
1. For each storage account, under `Monitoring`, click `Diagnostics settings`.
1. Select the `blob` tab indented below the storage account.
1. To create a new diagnostic setting, click `+ Add diagnostic setting`. To update an existing diagnostic setting, click `Edit setting` on the diagnostic setting.
1. Check the boxes next to `StorageRead`, `StorageWrite`, and `StorageDelete`.
1. Select an appropriate destination.
1. Click `Save`.

**Remediate from Azure CLI**

Use the below command to enable the Storage Logging for Blob service.
```
az storage logging update --account-name  --account-key  --services b --log rwd --retention 90
```

Associated Items

Affected Objects

TEST NAME

Ensure Storage Logging is Enabled for Table Service for Read Write and Delete Requests

Description

Azure Table storage is a service that stores structured NoSQL data in the cloud, providing a key/attribute store with a schema-less design. Storage Logging happens server-side and allows details for both successful and failed requests to be recorded in the storage account. These logs allow users to see the details of read, write, and delete operations against the tables. Storage Logging log entries contain the following information about individual requests: timing information such as start time, end-to-end latency, and server latency; authentication details; concurrency information; and the sizes of the request and response messages.

Rationale

Storage Analytics logs contain detailed information about successful and failed requests to a storage service. This information can be used to monitor each individual request to a storage service for increased security or diagnostics. Requests are logged on a best-effort basis.

Storage Analytics logging is not enabled by default for your storage account.

Impact

Being a level 2, enabling this setting can have a high impact on the cost of data storage used for logging more data per each request. Do not enable this without determining your need for this level of logging or forget to check in on data usage and projected cost.

Recommendation and Steps

**Remediate from Azure Portal**

1. Go to `Storage Accounts`.
1. For each storage account, under `Monitoring`, click `Diagnostics settings`.
1. Select the `table` tab indented below the storage account.
1. To create a new diagnostic setting, click `+ Add diagnostic setting`. To update an existing diagnostic setting, click `Edit setting` on the diagnostic setting.
1. Check the boxes next to `StorageRead`, `StorageWrite`, and `StorageDelete`.
1. Select an appropriate destination.
1. Click `Save`.

**Remediate from Azure CLI**

Use the below command to enable the Storage Logging for Table service.

```
az storage logging update --account-name  --account-key  --services t --log rwd --retention 90
```

Associated Items

Affected Objects

TEST NAME

Ensure Azure Resource Manager ReadOnly locks are considered for Azure Storage Accounts

Description

Adding an Azure Resource Manager `ReadOnly` lock can prevent users from accidentally or maliciously deleting a storage account, modifying its properties and containers, or creating access assignments. The lock must be removed before the storage account can be deleted or updated. It provides more protection than a `CannotDelete`-type of resource manager lock.

This feature prevents `POST` operations on a storage account and containers to the Azure Resource Manager control plane, _management.azure.com_. Blocked operations include `listKeys` which prevents clients from obtaining the account shared access keys. 

Microsoft does not recommend `ReadOnly` locks for storage accounts with Azure Files and Table service containers.

This Azure Resource Manager REST API documentation (spec) provides information about the control plane `POST` operations for _Microsoft.Storage_ resources.

Rationale

Applying a `ReadOnly` lock on storage accounts protects the confidentiality and availability of data by preventing the accidental or unauthorized deletion of the entire storage account and modification of the account, container properties, or access permissions. It can offer enhanced protection for blob and queue workloads with tradeoffs in usability and compatibility for clients using account shared access keys.

Impact

'- Prevents the deletion of the Storage account Resource entirely.
- Prevents the deletion of the parent Resource Group containing the locked Storage account resource.
- Prevents clients from obtaining the storage account shared access keys using a `listKeys` operation.
- Requires Entra credentials to access blob and queue data in the Portal.
- Data in Azure Files or the Table service may be inaccessible to clients using the account shared access keys.
- Prevents modification of account properties, network settings, containers, and RBAC assignments.
- Does not prevent access using existing account shared access keys issued to clients.
- Does not prevent deletion of containers or other objects within the storage account.

Recommendation and Steps

**Remediate from Azure Portal**

1. Navigate to the storage account in the Azure portal.
1. Under the `Settings` section, select `Locks`.
1. Select `Add`.
1. Provide a Name, and choose `ReadOnly` for the type of lock. 
1. Add a note about the lock if desired.

**Remediate from Azure CLI**

Replace the information within <> with appropriate values:

```
az lock create --name  \
 --resource-group  \
 --resource  \
 --lock-type ReadOnly \
 --resource-type Microsoft.Storage/storageAccounts
```

**Remediate from PowerShell**

Replace the information within <> with appropriate values:

```
New-AzResourceLock -LockLevel ReadOnly `
 -LockName  `
 -ResourceName  `
 -ResourceType Microsoft.Storage/storageAccounts `
 -ResourceGroupName 
```

Associated Items

Affected Objects

TEST NAME

Ensure that Secure transfer required is set to Enabled

Description

Enable data encryption in transit.

Rationale

The secure transfer option enhances the security of a storage account by only allowing requests to the storage account by a secure connection. For example, when calling REST APIs to access storage accounts, the connection must use HTTPS. Any requests using HTTP will be rejected when 'secure transfer required' is enabled. When using the Azure files service, connection without encryption will fail, including scenarios using SMB 2.1, SMB 3.0 without encryption, and some flavors of the Linux SMB client. Because Azure storage doesn?t support HTTPS for custom domain names, this option is not applied when using a custom domain name.

Impact

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure the Minimum TLS version for storage accounts is set to Version 1.2

Description

In some cases, Azure Storage sets the minimum TLS version to be version 1.0 by default. TLS 1.0 is a legacy version and has known vulnerabilities. This minimum TLS version can be configured to be later protocols such as TLS 1.2.

Rationale

TLS 1.0 has known vulnerabilities and has been replaced by later versions of the TLS protocol. Continued use of this legacy protocol affects the security of data in transit.

Impact

When set to TLS 1.2 all requests must leverage this version of the protocol. Applications leveraging legacy versions of the protocol will fail.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure Cross Tenant Replication is not enabled

Description

Cross Tenant Replication in Azure allows data to be replicated across multiple Azure tenants. While this feature can be beneficial for data sharing and availability, it also poses a significant security risk if not properly managed. Unauthorized data access, data leakage, and compliance violations are potential risks. Disabling Cross Tenant Replication ensures that data is not inadvertently replicated across different tenant boundaries without explicit authorization.

Rationale

Disabling Cross Tenant Replication minimizes the risk of unauthorized data access and ensures that data governance policies are strictly adhered to. This control is especially critical for organizations with stringent data security and privacy requirements, as it prevents the accidental sharing of sensitive information.

Impact

Disabling Cross Tenant Replication may affect data availability and sharing across different Azure tenants. Ensure that this change aligns with your organizational data sharing and availability requirements.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure that Allow Blob Anonymous Access is set to Disabled

Description

The Azure Storage setting ?Allow Blob Anonymous Access? (aka allowBlobPublicAccess) controls whether anonymous access is allowed for blob data in a storage account. When this property is set to True, it enables public read access to blob data, which can be convenient for sharing data but may carry security risks. When set to False, it disallows public access to blob data, providing a more secure storage environment.

Rationale

If Allow Blob Anonymous Access is enabled, blobs can be accessed by adding the blob name to the URL to see the contents. An attacker can enumerate a blob using methods, such as brute force, and access them.

Exfiltration of data by brute force enumeration of items from a storage account may occur if this setting is set to 'Enabled'.

Impact

Additional consideration may be required for exceptional circumstances where elements of a storage account require public accessibility. In these circumstances, it is highly recommended that all data stored in the public facing storage account be reviewed for sensitive or potentially compromising data, and that sensitive or compromising data is never stored in these storage accounts.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure Azure Resource Manager Delete locks are applied to Azure Storage Accounts

Description

Azure Resource Manager _CannotDelete (Delete)_ locks can prevent users from accidentally or maliciously deleting a storage account. This feature ensures that while the Storage account can still be modified or used, deletion of the Storage account resource requires removal of the lock by a user with appropriate permissions.

This feature is a protective control for the availability of data. By ensuring that a storage account or its parent resource group cannot be deleted without first removing the lock, the risk of data loss is reduced.

Rationale

Applying a _Delete_ lock on storage accounts protects the availability of data by preventing the accidental or unauthorized deletion of the entire storage account. It is a fundamental protective control that can prevent data loss

Impact

'- Prevents the deletion of the Storage account Resource entirely.
- Prevents the deletion of the parent Resource Group containing the locked Storage account resource.
- Does not prevent other control plane operations, including modification of configurations, network settings, containers, and access.
- Does not prevent deletion of containers or other objects within the storage account.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure Redundancy is set to geo-redundant storage (GRS) on critical Azure Storage Accounts

Description

Geo-redundant storage (GRS) in Azure replicates data three times within the primary region using locally redundant storage (LRS) and asynchronously copies it to a secondary region hundreds of miles away. This setup ensures high availability and resilience by providing 16 nines (99.99999999999999%) durability over a year, safeguarding data against regional outages.

Rationale

Enabling GRS protects critical data from regional failures by maintaining a copy in a geographically separate location. This significantly reduces the risk of data loss, supports business continuity, and meets high availability requirements for disaster recovery.

Impact

Enabling geo-redundant storage on Azure storage accounts increases costs due to cross-region data replication.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure Allow Azure services on the trusted services list to access this storage account is Enabled for Storage Account Access

Description

_NOTE:_ This recommendation assumes that the `Public network access` parameter is set to `Enabled from selected virtual networks and IP addresses`. Please ensure the prerequisite recommendation has been implemented before proceeding:?
- Ensure Default Network Access Rule for Storage Accounts is Set to Deny

Some Azure services that interact with storage accounts operate from networks that can't be granted access through network rules. To help this type of service work as intended, allow the set of trusted Azure services to bypass the network rules. These services will then use strong authentication to access the storage account. If the `Allow Azure services on the trusted services list to access this storage account` exception is enabled, the following services are granted access to the storage account: Azure Backup, Azure Data Box, Azure DevTest Labs, Azure Event Grid, Azure Event Hubs, Azure File Sync, Azure HDInsight, Azure Import/Export, Azure Monitor, Azure Networking Services, and Azure Site Recovery (when registered in the subscription).

Rationale

Turning on firewall rules for a storage account will block access to incoming requests for data, including from other Azure services. We can re-enable this functionality by allowing access to `trusted Azure services` through networking exceptions.

Impact

This creates authentication credentials for services that need access to storage resources so that services will no longer need to communicate via network request. There may be a temporary loss of communication as you set each Storage Account. It is recommended to not do this on mission-critical resources during business hours.

Recommendation and Steps

**Remediate from Azure Portal**

1. Go to `Storage Accounts`.
1. For each storage account, under `Security + networking`, click `Networking`.
1. Click on the `Firewalls and virtual networks` heading.
1. Under `Exceptions`, check the box next to `Allow Azure services on the trusted services list to access this storage account`.
1. Click `Save`.

**Remediate from Azure CLI**

Use the below command to update `bypass` to `Azure services`.
```
az storage account update --name  --resource-group  --bypass AzureServices
```

Associated Items

Affected Objects

TEST NAME

Ensure that Enable key rotation reminders is enabled for each Storage Account

Description

Access Keys authenticate application access requests to data contained in Storage Accounts. A periodic rotation of these keys is recommended to ensure that potentially compromised keys cannot result in a long-term exploitable credential. The Rotation Reminder is an automatic reminder feature for a manual procedure.

Rationale

Reminders such as those generated by this recommendation will help maintain a regular and healthy cadence for activities which improve the overall efficacy of a security program. 

Cryptographic key rotation periods will vary depending on your organization's security requirements and the type of data which is being stored in the Storage Account. For example, PCI DSS mandates that cryptographic keys be replaced or rotated 'regularly,' and advises that keys for static data stores be rotated every 'few months.'

For the purposes of this recommendation, 90 days will prescribed for the reminder. Review and adjustment of the 90 day period is recommended, and may even be necessary. Your organization's security requirements should dictate the appropriate setting.

Impact

This recommendation only creates a periodic reminder to regenerate access keys. Regenerating access keys can affect services in Azure as well as the organization's applications that are dependent on the storage account. All clients that use the access key to access the storage account must be updated to use the new key.

Recommendation and Steps

**Remediate from Azure Portal**

1. Go to `Storage Accounts`
1. For each Storage Account that is not compliant, under `Security + networking`, go to `Access keys`
1. Click `Set rotation reminder`
1. Check `Enable key rotation reminders`
1. In the `Send reminders` field select `Custom`, then set the `Remind me every` field to `90` and the period drop down to `Days`
1. Click `Save`

**Remediate from Powershell**

```
$rgName = 
$accountName = 
$account = Get-AzStorageAccount -ResourceGroupName $rgName -Name $accountName
if ($account.KeyCreationTime.Key1 -eq $null -or $account.KeyCreationTime.Key2 -eq $null){
 Write-output (You must regenerate both keys at least once before setting expiration policy)
} else {
 $account = Set-AzStorageAccount -ResourceGroupName $rgName -Name $accountName -KeyExpirationPeriodInDay 90
}
$account.KeyPolicy.KeyExpirationPeriodInDays
```

Associated Items

Affected Objects

TEST NAME

Ensure Allow storage account key access for Azure Storage Accounts is Disabled

Description

Every secure request to an Azure Storage account must be authorized. By default, requests can be authorized with either Microsoft Entra credentials or by using the account access key for Shared Key authorization.

Rationale

Microsoft Entra ID provides superior security and ease of use compared to Shared Key and is recommended by Microsoft. To require clients to use Microsoft Entra ID for authorizing requests, you can disallow requests to the storage account that are authorized with Shared Key.

Impact

When you disallow Shared Key authorization for a storage account, any requests to the account that are authorized with Shared Key, including shared access signatures (SAS), will be denied. Client applications that currently access the storage account using the Shared Key will no longer function.

Recommendation and Steps

**Remediate from Azure Portal**

1. Go to `Storage accounts`.
1. Click on a storage account.
1. Under `Settings`, click `Configuration`.
1. Under `Allow storage account key access`, click the radio button next to `Disabled`.
1. Click `Save`.
1. Repeat steps 1-5 for each storage account requiring remediation.

**Remediate from Azure CLI**

For each storage account requiring remediation, run the following command to disallow shared key authorization:

```
az storage account update --resource-group  --name  --allow-shared-key-access false
```

**Remediate from PowerShell**

For each storage account requiring remediation, run the following command to disallow shared key authorization:

```
Set-AzStorageAccount -ResourceGroupName  -Name  -AllowSharedKeyAccess $false
```

Associated Items

Affected Objects

TEST NAME

Ensure Storage for Critical Data are Encrypted with Customer Managed Keys -CMK-

Description

Enable sensitive data encryption at rest using Customer Managed Keys (CMK) rather than Microsoft Managed keys.

Rationale

By default, data in the storage account is encrypted using Microsoft Managed Keys at rest. All Azure Storage resources are encrypted, including blobs, disks, files, queues, and tables. All object metadata is also encrypted. If you want to control and manage this encryption key yourself, however, you can specify a customer-managed key. That key is used to protect and control access to the key that encrypts your data. You can also choose to automatically update the key version used for Azure Storage encryption whenever a new version is available in the associated Key Vault.

While it is possible to automate the assessment of this recommendation, the assessment status for this recommendation remains 'Manual.' This is because the recommendation pertains to storage accounts that store critical data and is therefore not applicable to all storage accounts.

Impact

If the key expires by setting the 'activation date' and 'expiration date', the user must rotate the key manually.

Using Customer Managed Keys may also incur additional man-hour requirements to create, store, manage, and protect the keys as needed.

Recommendation and Steps

**Remediate from Azure Portal**

1. Go to `Storage Accounts`
2. For each storage account, under `Security + networking`, go to `Encryption`
3. Set `Encryption type` to `Customer-managed keys`
4. Select an encryption key or enter a key URI
5. Click `Save`

Associated Items

Affected Objects

TEST NAME

Ensure Allowed Protocols for shared access signature SAS tokens is set to HTTPS Only

Description

Shared access signatures (SAS) can be used to grant limited access to Azure Storage resources. When generating a SAS, it is possible to specify the allowed protocols for a request made with the SAS. It is recommended to allow requests over HTTPS only.

Rationale

If a SAS is passed over HTTP and intercepted, an attacker performing a man-in-the-middle attack can read the SAS. Then, they can use that SAS just as the intended user could have. This can potentially compromise sensitive data or allow for data corruption by the malicious user.

Impact

SAS can pose security risks if they are not managed carefully.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure that Storage Account Access Keys are Periodically Regenerated

Description

For increased security, regenerate storage account access keys periodically.

Rationale

When a storage account is created, Azure generates two 512-bit storage access keys which are used for authentication when the storage account is accessed. Rotating these keys periodically ensures that any inadvertent access or exposure does not result from the compromise of these keys.

Cryptographic key rotation periods will vary depending on your organization's security requirements and the type of data which is being stored in the Storage Account. For example, PCI DSS mandates that cryptographic keys be replaced or rotated 'regularly,' and advises that keys for static data stores be rotated every 'few months.'

For the purposes of this recommendation, 90 days will prescribed for the reminder. Review and adjustment of the 90 day period is recommended, and may even be necessary. Your organization's security requirements should dictate the appropriate setting.

Impact

Regenerating access keys can affect services in Azure as well as the organization's applications that are dependent on the storage account. All clients who use the access key to access the storage account must be updated to use the new key.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure that shared access signature SAS tokens expire within an hour-CISStorage

Description

Shared access signature (SAS) tokens provide restricted access to Azure Storage resources (such as blobs, files, queues, or tables) for a defined time period with specific permissions. It enables users to interact with the resources without exposing account keys, offering precise control over the permitted actions (e.g., read, write) and the duration of access. To minimize security risks, SAS tokens should be configured with the shortest possible lifespan, ideally lasting no longer than an hour.

Rationale

A short lifespan for SAS tokens is recommended to minimize the risk of unauthorized access. SAS tokens grant time-limited access to resources, and a longer duration increases the opportunity for misuse if the token is compromised. By setting a shorter lifespan, the potential for security breaches is reduced.

Impact

SAS can pose security risks if they are not managed carefully.

Recommendation and Steps

Associated Items

Affected Objects

TEST NAME

Ensure Private Endpoints are used to access Storage Accounts

Description

Use private endpoints for your Azure Storage accounts to allow clients and services to securely access data located over a network via an encrypted Private Link. To do this, the private endpoint uses an IP address from the VNet for each service. Network traffic between disparate services securely traverses encrypted over the VNet. This VNet can also link addressing space, extending your network and accessing resources on it. Similarly, it can be a tunnel through public networks to connect remote infrastructures together. This creates further security through segmenting network traffic and preventing outside sources from accessing it.

Rationale

Securing traffic between services through encryption protects the data from easy interception and reading.

Impact

A Private Endpoint costs approximately US$7.30 per month. If an Azure Virtual Network is not implemented correctly, this may result in the loss of critical network traffic.

Recommendation and Steps

**Remediate from Azure Portal**

1. Open the `Storage Accounts` blade
1. For each listed Storage Account, perform the following:
1. Under the `Security + networking` heading, click on `Networking` 
1. Click on the `Private endpoint connections` tab at the top of the networking window
1. Click the `+ Private endpoint` button
1. In the `1 - Basics` tab/step:
 - `Enter a name` that will be easily recognizable as associated with the Storage Account (*Note*: The Network Interface Name will be automatically completed, but you can customize it if needed.)
 - Ensure that the `Region` matches the region of the Storage Account
 - Click `Next`
1. In the `2 - Resource` tab/step:
 - Select the `target sub-resource` based on what type of storage resource is being made available
 - Click `Next`
1. In the `3 - Virtual Network` tab/step:
 - Select the `Virtual network` that your Storage Account will be connecting to
 - Select the `Subnet` that your Storage Account will be connecting to
 - (Optional) Select other network settings as appropriate for your environment
 - Click `Next`
1. In the `4 - DNS` tab/step:
 - (Optional) Select other DNS settings as appropriate for your environment
 - Click `Next`
1. In the `5 - Tags` tab/step:
 - (Optional) Set any tags that are relevant to your organization
 - Click `Next`
1. In the `6 - Review + create` tab/step:
 - A validation attempt will be made and after a few moments it should indicate `Validation Passed` - if it does not pass, double-check your settings before beginning more in depth troubleshooting.
 - If validation has passed, click `Create` then wait for a few minutes for the scripted deployment to complete.

Repeat the above procedure for each Private Endpoint required within every Storage Account.

**Remediate from PowerShell**

```
$storageAccount = Get-AzStorageAccount -ResourceGroupName '' -Name ''

$privateEndpointConnection = @{ 
 Name = 'connectionName'
 PrivateLinkServiceId = $storageAccount.Id
 GroupID = blob|blob_secondary|file|file_secondary|table|table_secondary|queue|queue_secondary|web|web_secondary|dfs|dfs_secondary
}

$privateLinkServiceConnection = New-AzPrivateLinkServiceConnection @privateEndpointConnection

$virtualNetDetails = Get-AzVirtualNetwork -ResourceGroupName '' -Name ''

$privateEndpoint = @{
 ResourceGroupName = ''
 Name = ''
 Location = ''
 Subnet = $virtualNetDetails.Subnets[0]
 PrivateLinkServiceConnection = $privateLinkServiceConnection
}

New-AzPrivateEndpoint @privateEndpoint 
```

**Remediate from Azure CLI**

```
az network private-endpoint create --resource-group  --name  --vnet-name  --subnet  --private-connection-resource-id  --connection-name  --group-id 
```

Associated Items

Affected Objects

TEST NAME

Ensure that Public Network Access is Disabled for storage accounts

Description

Disallowing public network access for a storage account overrides the public access settings for individual containers in that storage account for Azure Resource Manager Deployment Model storage accounts. Azure Storage accounts that use the classic deployment model will be retired on August 31, 2024.

Rationale

The default network configuration for a storage account permits a user with appropriate permissions to configure public network access to containers and blobs in a storage account. Keep in mind that public access to a container is always turned off by default and must be explicitly configured to permit anonymous requests. It grants read-only access to these resources without sharing the account key, and without requiring a shared access signature.
It is recommended not to provide public network access to storage accounts until, and unless, it is strongly desired. A shared access signature token or Azure AD RBAC should be used for providing controlled and timed access to blob containers.

Impact

Access will have to be managed using shared access signatures or via Azure AD RBAC.

For classic storage accounts (to be retired on August 31, 2024), each container in the account must be configured to block anonymous access. Either configure all containers or to configure at the storage account level, migrate to the Azure Resource Manager deployment model.

Recommendation and Steps

**Remediate from Azure Portal**

First, follow Microsoft documentation and create shared access signature tokens for your blob containers. Then, 

1. Go to `Storage Accounts`.
1. For each storage account, under the `Security + networking` section, click `Networking`.
1. Set `Public network access` to `Disabled`.
1. Click `Save`.

**Remediate from Azure CLI**

Set 'Public Network Access' to `Disabled` on the storage account 

```
az storage account update --name  --resource-group  --public-network-access Disabled
```

**Remediate from PowerShell**

For each Storage Account, run the following to set the `PublicNetworkAccess` setting to `Disabled`
```
Set-AzStorageAccount -ResourceGroupName  -Name  -PublicNetworkAccess Disabled
```

Associated Items

Affected Objects

TEST NAME

Ensure Default Network Access Rule for Storage Accounts is Set to Deny

Description

Restricting default network access helps to provide a new layer of security, since storage accounts accept connections from clients on any network. To limit access to selected networks, the default action must be changed.

Rationale

Storage accounts should be configured to deny access to traffic from all networks (including internet traffic). Access can be granted to traffic from specific Azure Virtual networks, allowing a secure network boundary for specific applications to be built. Access can also be granted to public internet IP address ranges to enable connections from specific internet or on-premises clients. When network rules are configured, only applications from allowed networks can access a storage account. When calling from an allowed network, applications continue to require proper authorization (a valid access key or SAS token) to access the storage account.

Impact

All allowed networks will need to be whitelisted on each specific network, creating administrative overhead. This may result in loss of network connectivity, so do not turn on for critical resources during business hours.

Recommendation and Steps

**Remediate from Azure Portal**

1. Go to `Storage Accounts`.
1. For each storage account, under `Security + networking`, click `Networking`.
1. Click the `Firewalls and virtual networks` heading.
1. Set `Public network access` to `Enabled from selected virtual networks and IP addresses`.
1. Add rules to allow traffic from specific networks and IP addresses.
1. Click `Save`.

**Remediate from Azure CLI**

Use the below command to update `default-action` to `Deny`.
```
 az storage account update --name  --resource-group  --default-action Deny
```

Associated Items

Affected Objects

TEST NAME

Ensure stored access policies SAP are used when generating shared access signature SAS tokens

Description

Use stored access policies (SAP) when generating shared access signature (SAS) tokens in Azure to centrally manage permissions, expiration, and revocation settings for resource access. Stored access policies can be applied to blob containers, file shares, queues, and tables.

Rationale

Stored access policies provide centralized control over SAS token access, allowing administrators to update permissions or revoke access. This approach strengthens security by reducing the risk of unauthorized access to storage resources.

Impact

There is no cost for creating stored access policies, however there is some administrative overhead involved in managing these policies.

Recommendation and Steps

**Remediate from Storage Explorer**

To create a SAP:

1. In Storage Explorer, expand `Storage Accounts`.
1. Expand a storage account.
1. Expand `Blob Containers`, `File Shares`, `Queues`, or `Tables`, and right-click a blob container, file share, queue, or table.
1. Click `Manage Stored Access Policies...`.
1. Under `Access Policies`, click `Add`.
1. Modify the `ID`, `Start time`, `Expiry time`, and permissions appropriately.
1. Click `Save`.
1. Repeat steps 1-7 as needed to create SAP.

When generating SAS, select a SAP from the `Access policy` drop-down.

**Remediate from Azure Portal**

If SAS have been created without a SAP, the SAS can be revoked by regenerating the storage account access keys:

**Note:** Regenerating access keys can affect any applications or Azure services that are dependent on the storage account key.

1. Go to `Storage accounts`.
1. Click on a storage account.
1. Under `Security + networking`, click `Access keys`.
1. Next to each key, click `Rotate key`.
1. Click `Yes` to confirm.
1. Repeat steps 1-5 as needed to revoke SAS.

Associated Items

Affected Objects

TEST NAME

Ensure Storage Explorer is using the latest version

Description

Ensure all users accessing Azure Storage resources with Storage Explorer are using the latest version of the software, applying updates promptly to safeguard against new vulnerabilities and benefit from the latest security enhancements.

Rationale

Using the latest version of Storage Explorer is essential for safeguarding access to Azure Storage resources.

Impact

Using the latest version of Storage Explorer is free and requires minimal administrative effort.

Recommendation and Steps

**Remediate from Storage Explorer for MacOS**

1. Go to `Storage Explorer`.
1. From the menu bar, click `Microsoft Azure Storage Explorer`.
1. Click `Check for Updates`.
1. Follow the instructions to install the latest version of Storage Explorer.

Associated Items

Affected Objects

TEST NAME

Ensure that shared access signature SAS tokens expire within an hour-StorgaeExplorer

Description

Shared access signature (SAS) tokens provide restricted access to Azure Storage resources (such as blobs, files, queues, or tables) for a defined time period with specific permissions. It enables users to interact with the resources without exposing account keys, offering precise control over the permitted actions (e.g., read, write) and the duration of access. To minimize security risks, SAS tokens should be configured with the shortest possible lifespan, ideally lasting no longer than an hour.

Rationale

A short lifespan for SAS tokens is recommended to minimize the risk of unauthorized access. SAS tokens grant time-limited access to resources, and a longer duration increases the opportunity for misuse if the token is compromised. By setting a shorter lifespan, the potential for security breaches is reduced.

Impact

SAS can pose security risks if they are not managed carefully.

Recommendation and Steps

Associated Items

Affected Objects