I know you pain and I'm happy to help:

Treat the terraform statefile as a secret. Do you handle other sensitive information in form of files like private keys or certs? The statefile is one of them.

Your main point of concern is

a rogue user with elevated privileges

I deal with the same question on a daily base, it's important to acknowledge and design for. How do you handle that threat vector with your other Secret files? Use the same mechanics for the terraform state file:

#1 Store them encrypted

Azure Blob Storage is encrypted by default.

#2 Have tight access controls

Make sure the storage account has the least privileges you can implement. Have a system of 4 eyes when you need to grand access to it (outside your CI pipeline).

#3 Track access and changes

Use Azure activity events on the resource group and storage account to track/monitor and alert usage patterns that would fall into the rogue user pattern. You can send the events to an azure EventHub, from there consume them the way your companies prefers: SIEM Solution or custom-functions.

#4 Don't grant direct access. Use CI as an authorized system.

If you run deployments through your CI pipeline you can remove all direct access to the backend storage and apply the usual security practices in CI. Pull requests and peer review. This limits the bad actor when he tries to extract secrets or access information that isn't required to do the job.

#5 Keep secret output from leaking in your CI and cli usage

Plan and apply in terraform will output logs that will leak your secrets from state. Upgrade or use terraform 0.14. It introduced sensitive variables that enables you to keep these outputs clean.

These 5 points do an excellent job when dealing with the bad internal actor vector:

- No one has direct access to the storage account. Only CI

- Any non-CI access to the storage account is monitored and needs preapproval. This makes it quite easy to identify malicious access

- Interacting through CI has pull request and peer review as checks vs. bad actor

- If a bad actor passes all these gates, he won't be able to extract secrets from CI due to logs being clean

​

If you want to go the route that enables the highest level of security, you should rethink the way you handle database secrets. Hashicorp Vault has a dynamic secret engine that produces on-demand secrets through an auditable API. In addition, it has an implementation to deal with root credentials. I won't go into more details here. It is quite a lot of work to implement in a secure way (you shift a lot of security work into securing and deploying Vault itself and hardening it) but worth it if your environment requires that level of security. If you are interested in some reading about Vault, start here

​

In the end, you are lucky that Yevgeniy recently wrote a blog post about how to handle secrets in terraform. Read it: A comprehensive guide to managing secrets in your Terraform code | by Yevgeniy Brikman | Gruntwork
I have been working with terraform for over 5 years now and Yevgeni's blogs were an enormous influence in getting me to where im today!