Skip to content

Temporarily exempt the landing zone state storage account from specific policies

Context and Problem Statement

Our landing zone implementation adheres to the ASC, CIS 1.4.0, ISO 27001:2013, and NIS2 compliance standards. However, currently, the storage account that is used to store the terraform state files is not deployed using IaC. Also we have not yet come to a decision which security aspects should be applied to the state storage account and which should be exempted.

Decision Drivers

  • The requirement to be compliant with the ASC, CIS 1.4.0, ISO 27001:2013, and NIS2 compliance standards
  • The ability to access the state storage account from Microsoft hosted DevOps agents
  • The fact that we are currently developing a secure and compliant Bicep module for storage accounts

Considered Options

  • Temporarily exempt the storage account from specific ASC, CIS 1.4.0, ISO 27001:2013, and NIS2 policies

Temporarily exempt the storage account from specific ASC, CIS 1.4.0, ISO 27001:2013, and NIS2 policies

For ISO 27001:2013 we exempt the following policies:

  • "Storage accounts should restrict network access"

For ASC we exempt the following policies:

  • "Storage accounts should use private link"
  • "Storage accounts should restrict network access using virtual network rules"
  • "Storage accounts should prevent shared key access"
  • "[Preview]: All Internet traffic should be routed via your deployed Azure Firewall"

For CIS 1.4.0 we exempt the following policies:

  • "Storage accounts should restrict network access"
  • "Storage accounts should restrict network access using virtual network rules"
  • "Storage accounts should use customer-managed key for encryption"

For NIS2 we exempt the following policies:

  • "Storage accounts should restrict network access using virtual network rules"
  • "Storage accounts should restrict network access"

Decision Outcome

Chosen option: "Temporarily exempt the storage account from specific ASC, CIS 1.4.0, and ISO 27001:2013 policies", because: * This allows to (re)consider deploying the storage account from Bicep using our compliant Bicep module * This allows us to access the storage account from a Microsoft hosted DevOps agent or from a self hosted agent that is not connected to the landing zone (yet) * This allows consider whether we want to use customer managed keys in this particular case.