Highlight
Security by obscurity? No, that’s not my intention here, this is not a security recommendation, but an adoption one.
Intro
If you read my post explaining why storage accounts can’t be shared for logic app state, then you already know that each logic app needs it’s own storage. Is there a risk attached to it? Kind off, but it’s not a security one.
Core issue
Many organizations try to tackle the issue of data siloing and unmanaged data respositories. Storage accounts is the most commony used data repository service in Azure, and for the right reasons. But this can become an issue at larger scale.
Imagine your organization; as many on the plant currently are trying to; is trying to ensure a central data lake is used to store and process company’s data. But instead of having a few central data lakes, your organization also deployed 100 logic apps, and that means 100 storage accounts.
What will happen? The most human thing of course. Development teams instead of using central data lake they will see a storage account in their resource group and leverage it because very often they have full ownership of that RG. This might not be a problem if your organization is small, but at larger scale, it is really an issue. I’ve seen organizations which found out that their storage accounts which were intended for logic apps suddenly were used by big data services like Synapse, Fabric or Databricks and stored up to 2 petabytes of data; yes, 2 petabytes. The only reason they’ve found about it was because costs started ramping up where they shouldn’t. Now imagine this problem in an enterprise scale company.
Solution? Not really, but it helps
My tip is a small, move the provisioned storage accounts into storage resource group where developers only have read access to storage and read/write storage data, nothing more.
Does it solve it?
In short? No, but it helps. It helps because majority of developer’s won’t see the storage in their RG and will at least ask the right question first “Where do I store my data?” and the answer will be an organizational data lake.
While there will still be these 1-5% of developers who will find this storage via logic app connection string and possibly do something they shouldn’t it’s stil much better solution. This is because it’s easier to clean up after small fraction of use-cases than if 90% of them would do it, and trust me, they would.
Real solution?
The real solution to this problem might be SQL database used to state storage, but Today this is still a preview feature, so we have to wait and find out how it ends up being.
that said, I wrote a small blog post about SQL database and how it potentially can also reduce cost of your logic apps if you want to read about it here.
Summary
What do you think about it? Is the proper adoption of the platform worth extra effort* of provisioning storage in another RG? Let me know your thoughts?
*Extra effort is a little far fetched obviously because with Bicep or Terraform this is very straightforward.
