CKV_AZURE_59 false positive: Terraform check ignores public_network_access on azurerm_storage_account

Describe the issue

Check ID: CKV_AZURE_59 ("Ensure that Storage accounts disallow public access"), Terraform implementation.

The check evaluates only the public_network_access_enabled boolean on azurerm_storage_account. It does not evaluate the public_network_access string attribute, introduced in AzureRM provider 5.5, which accepts Disabled, Enabled and SecuredByPerimeter.

As a result, a storage account that sets public_network_access = "Disabled" is correctly secured but fails the check. A false positive here is arguably worse than a missed check, because it encourages #checkov:skip annotations on resources that are genuinely compliant.

The logic for the change: the check should pass where either attribute indicates public access is off, fail where either indicates it is on, and continue to fail where neither is set, since the provider default is Enabled. This would also bring the Terraform check into line with the ARM implementation of the same ID, which already inspects properties/publicNetworkAccess and treats Enabled as the forbidden value.

Examples

resource "azurerm_storage_account" "example" {
  name                     = "examplestorageacct"
  resource_group_name      = "example-rg"
  location                 = "uksouth"
  account_tier             = "Standard"
  account_replication_type = "LRS"
  public_network_access    = "Disabled"
}

Actual outcome:

Check: CKV_AZURE_59: "Ensure that Storage accounts disallow public access"
	FAILED for resource: azurerm_storage_account.example

Expected outcome: PASSED.

Version (please complete the following information):

• Checkov Version 3.3.16

Additional context

public_network_access was added to azurerm_storage_account in AzureRM provider 5.5. Provider documentation for the attribute: https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/storage_account

One decision worth flagging: I have treated public_network_access = "SecuredByPerimeter" as passing, on the basis that access in that mode is governed by a network security perimeter rather than being open to the internet. That is a policy judgement rather than an implementation one. If you would rather it failed, it is a one-line change and I will amend it.

I will raise a PR shortly covering both attributes, with tests for all six states: string Disabled / Enabled / SecuredByPerimeter, boolean false / true, and neither attribute set.