Introduction
Building a new app is exciting but shipping an app with poorly secured storage is a headline waiting to happen.
When developers build apps that read and write data to the cloud, the question isn’t just where data lives, it’s who can access it, how that access is controlled, and what happens if someone tries to tamper with critical files.
Passwords get leaked, Keys get exposed in code repositories, Shared credentials get passed around Slack until nobody knows who has access to what. These aren’t hypothetical risks, they’re the most common causes of data breaches in cloud applications.
This guide shows you (developers) how to do it the right way with no passwords embedded in code, no shared keys floating around, no way for even an admin to delete protected data. Just clean, auditable, role-based access backed by industry-standard encryption.
Azure Blob Storage paired with Managed Identities, Key Vault, and RBAC gives your app exactly that and it’s less complicated than it sounds.
What Are We Actually Building?
A secure storage setup where:
- Your app accesses storage using an identity, not a password
- Encryption keys are stored in a dedicated vault, not in your app’s config
- Access is controlled by roles, not by sharing credentials
- Test files are immutable i.e nobody can modify or delete them, not even admins
- Infrastructure is double-encrypted from the moment the account is created
Let’s define some terms
- Managed Identity: An automatically managed account in Azure that your app uses to prove who it is without needing a username or password stored in your code.
- RBAC (Role-Based Access Control): A permission system where you assign roles (like “Reader” or “Contributor”) instead of handing out keys. The right people get the right access, nothing more.
- Key Vault: A dedicated Azure service for storing secrets, keys, and certificates. Instead of your app holding its own encryption keys, Key Vault holds them and only hands them out to authorised identities.
- Customer-Managed Key (CMK): An encryption key that you control, stored in Key Vault, used to encrypt your storage. More control than the default Microsoft-managed key.
- Infrastructure Encryption: A second layer of encryption applied at the hardware level. Your data is encrypted twice; once at the service level, once at the infrastructure level.
Step 1: Create an Encrypted Storage Account
This account has infrastructure encryption enabled i.e a second layer of encryption that cannot be turned off or changed after creation.
Step 2: Create a Managed Identity
Instead of your app using a key or password, it uses a managed identity which is an automatically managed account that Azure handles for you.
Step 3: Assign Storage Access to the Identity (RBAC)
Step 4: Assign Key Vault Administrator to Your Account
Before creating a Key Vault, you need to give yourself administrator permissions on the resource group.
Step 5: Create a Key Vault
Key Vault is where your encryption keys live and it is separate from your app, storage, locked down with its own access control.
Step 6: Create a Customer-Managed Encryption Key
Step 7: Give the Identity Permission to Use the Key
Before linking the key to your storage, the managed identity needs permission to use it for encryption operations.
Step 8: Configure Storage to Use Your Key Vault Key
Step 9: Create an Immutable Container for Testing
Developers need a container where files can’t be changed or deleted not even by an admin. This is critical for testing environments where file integrity must be guaranteed.
Test if it works:
Step 10: Create an Encryption Scope
The developers require an encryption scope that enables infrastructure encryption.
- In your storage account, go to Security + networking → Encryption
- Select the Encryption scopes tab
- Click + Add
- Give it a name (like secure-scope)
- Keep Encryption type as
Microsoft-managed key - Set Infrastructure encryption to
Enable - Click Create
Apply it to a new container:
- Go to Data storage → Containers
- Click + Container
- Give it a name (
securencrypt) - In the Advanced section, select your encryption scope
- Click Create
Every blob in this container now gets its own dedicated encryption layer on top of the account-level encryption.
Common issues
- Identity does not have the correct permissions” when saving encryption: Role assignments take 1-2 minutes to propagate across Azure. Wait, then try again.
- Failed to delete blobs due to policy: This is correct behaviour. The immutable policy is working as intended. Wait for the retention period to expire, or test with a shorter period.
- Managed identity not appearing in dropdown: Make sure you created a User-assigned managed identity, not a system-assigned one. They appear in different drop-downs.
- Key Vault key not visible when selecting for storage encryption: Confirm you assigned the Key Vault Crypto Service Encryption User role to the managed identity, not just the administrator role.
What part of this took longest to configure in your environment? The RBAC roles, the Key Vault setup, or the immutable policy? Share in the comments. It helps other developers know where to slow down.
답글 남기기