Issue - anonymous public blob access enabled on storage account in deployment template

[cruscio]

Describe the Issue https://github.com/microsoft/fhir-loader#portal-deployment-recommended

The Portal deployment template creates a storage account with public anonymous blob access. It would be nice if this hardened by default (and maybe provide the option to enable it with parameters if the operator explicitly chooses to). My organization's policy, and I'd assume most others in the healthcare space, disallows anonymous blob access to prevent information disclosure vulnerabilities. Specifically for FHIR (healthcare interoperability) this would seem a necessary default to lock down.

[cruscio]

There's a workaround - we can deploy the bash script with edits - just wanted to raise the concern about the template to you.

[erikhoward]

@cruscio - Thanks for the input! I'll add this to our backlog.

[evachen96]

Hi @cruscio, thanks for submitting this issue! Our engineering team looked into this and was unable to repro - our deployment template creates a Private storage account with blob anonymous access disabled. Would you be able to share the steps that you took and a screenshot showing the blob access level? Additionally, confirming if you are using the latest version of the FHIR Loader? Thanks!

[cruscio]

I opened this based on an error message shared by a colleague attempting portal deployment, and my own reading of the JSON/BASH in the repo.

I just tested both now and here are my findings:

CLI Deployment

Took the az storage account create command from the bash script, replaced a couple variables and get a validation error based on a tenant policy that disallows blob anonymous access:

az storage account create --name crufhirloader57 --resource-group cru-fhirloader57 --location CentralUS --sku Standard_LRS --encryption-services blob

[...]
Additional Information:Type: PolicyViolation
Info: {
    "evaluationDetails": {
        "evaluatedExpressions": [
            {
                "result": "True",
                "expressionKind": "Field",
                "expression": "type",
                "path": "type",
                "expressionValue": "Microsoft.Storage/storageAccounts",
                "targetValue": "Microsoft.Storage/storageAccounts",
                "operator": "Equals"
            },
            {
                "result": "False",
                "expressionKind": "Field",
                "expression": "Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
                "path": "properties.allowBlobPublicAccess",
                "targetValue": "false",
                "operator": "Equals"
            }
        ]
    },
[...]

Portal Deployment

Running the portal deployment myself, by launching the deployment link in the README, I only edited the selection of an existing resource group, and clicked [Next] through everything else. At the review stage, I'm getting an unrelated validation error than our policy violation for public anonymous blob access:

{
  "code": "InvalidTemplate",
  "message": "Deployment template validation failed: 'The template variable 'fhirResourceGroupName' is not valid: The language expression property array index '4' is out of bounds.. Please see https://aka.ms/arm-functions for usage details.'."
}

However, looking at the deployment template, I'm not seeing anything that sets the storage account to false for allowBlobPublicAccess or AllowBlobAnonymousAccess. I'd expect a similar outcome with the deployment template if it got past the above error.

---

I may have more to learn about the differences between AllowBlobAnonymousAccess, allowBlobPublicAccess, and publicNetworkAccess. Apologies for any confusion here.

It's my understanding both the Portal Deployment and the CLI Deployment create a storage account with allowBlobPublicAccess = true (They don't explicitly set false and the default is true) - and Public access means Anonymous access based on this documentation

To allow or disallow anonymous access for a storage account, set the account's AllowBlobPublicAccess property. This property is available for all storage accounts that are created with the Azure Resource Manager deployment model.

[evachen96]

@cruscio Thanks for the additional details! The team is looking into it.

[evachen96]

Hi @cruscio - we've merged a PR that should fix this issue now. Let us know if you still face any issues! Thanks.