First things first, we all love Shared Access Signatures (SAS), I know, I’m not pretending I don’t. I like SAS a lot because I can use them on my local machine, to access resources in Azure. Everybody who has written code for cloud applications, knows the struggle of having to deploy the app, just to test it. It’s painful, it takes time and SAS is a great quick-fix for this pain in the ass.
However, having a magical string that gives access to an(y) Azure Resource is a major bad practice. A SAS is just a string and it can very easily land in the wrong hands. It is therefore strongly recommended to use Identities instead of local authentication (SAS), at least in production. The benefits of using Identities over SAS deserve their own blog-post.
Luckily, Azure has already a built-in policy called “Azure Service Bus namespaces should have local authentication methods disabled” and the rule looks like this:
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.ServiceBus/namespaces"
},
{
"field": "Microsoft.ServiceBus/namespaces/disableLocalAuth",
"notEquals": true
}
]
},
"then": {
"effect": "[parameters('effect')]"
}
}
By using effect deny, the policy will flag the Namespace as non-compliant.
In the namespace overview, we can take action and mitigate the issue, by disabling local access. When done, we get this friendly, yet informative message.
Keep in mind, that this applies even for queues & topics. Once you disable Local Authentication in the namespace, SAS is disabled everywhere!