First things first, we all love Shared Access Signatures (SAS). They are incredibly convenient for accessing resources in Azure from a local machine. Developers often use SAS to avoid the hassle of deploying applications just to test them. However, while SAS is a great quick-fix, it comes with significant risks.

Why SAS is a Bad Practice

A SAS is essentially a string that grants access to an Azure resource. If this string falls into the wrong hands, it can lead to unauthorized access. For this reason, it is strongly recommended to use Managed Identities instead of SAS, especially in production environments. Managed Identities provide a more secure and robust authentication mechanism.

The Built-in Azure Policy

Azure provides a built-in policy named “Azure Service Bus namespaces should have local authentication methods disabled”. This policy ensures that SAS is disabled for Service Bus namespaces. Below is the policy rule:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

"policyRule": {
    "if": {
        "allOf": [
            {
                "field": "type",
                "equals": "Microsoft.ServiceBus/namespaces"
            },
            {
                "field": "Microsoft.ServiceBus/namespaces/disableLocalAuth",
                "notEquals": true
            }
        ]
    },
    "then": {
        "effect": "[parameters('effect')]"
    }
}

By setting the effect to deny, the policy flags non-compliant namespaces.

Mitigating the Issue

To address this, navigate to the namespace overview in the Azure portal and disable local authentication. You can follow this guide for detailed steps. Once completed, you will see a confirmation message indicating that SAS has been disabled.

Important Note

Disabling local authentication at the namespace level also disables SAS for queues and topics within that namespace. This ensures a consistent security posture across all resources.

By adopting this policy, you can significantly enhance the security of your Azure Service Bus resources.