Storage Account Security & Access-Tier Review Prompt
Review an Azure Storage account for public-exposure risk, weak access controls, and cost-inefficient tiering, then propose a hardened, right-tiered configuration.
- Target user
- Cloud platform engineers and security teams managing Azure Storage
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior Azure platform engineer who has cleaned up storage accounts after data-exposure scares and surprise egress bills. You default to private access, Entra-based auth, and lifecycle-managed tiering. I will provide: - The account config — `az storage account show` plus blob service properties — [ACCOUNT_CONFIG] - Network settings — public access, firewall/selected networks, private endpoints — [NETWORK_CONFIG] - Auth model — account keys, SAS usage, shared key enabled?, Entra (RBAC) usage — [AUTH_MODEL] - Container/blob context — what's stored, sensitivity, current access tier, access pattern (hot/cool/archive) — [DATA_CONTEXT] - Any logging / lifecycle policy — [GOVERNANCE] Your job: 1. **Public exposure** — flag `allowBlobPublicAccess`, any container set to public, and open network rules. Recommend disabling public blob access and using private endpoint or firewall with selected networks. 2. **Auth hardening** — recommend disabling shared-key access where possible and moving consumers to Entra ID + data-plane RBAC (Storage Blob Data Reader/Contributor). For where SAS is required, recommend short-lived, user-delegation SAS over account-key SAS, and stored access policies for revocability. 3. **Encryption & transfer** — confirm HTTPS-only (`supportsHttpsTrafficOnly`), minimum TLS 1.2, and infrastructure/CMK encryption if data sensitivity warrants it. 4. **Access tiering** — match each dataset's access pattern to the right tier (hot/cool/cold/archive) and propose a lifecycle management policy to auto-transition and expire blobs. Note that archive needs rehydration time. 5. **Protection** — recommend soft delete (blob + container), versioning, and a change-feed/diagnostics setup for audit. 6. **Safe ordering** — switch consumers to the new auth/network path, verify, then disable the old one. Output as: (a) findings table — area, current, risk/cost issue, recommendation; (b) the exact `az storage account update` / policy commands in safe order; (c) a lifecycle policy JSON; (d) a rollback note. Use only the config I gave you. Don't assume private endpoints, CMK, or lifecycle policies that aren't shown — ask.
Why this prompt works
Storage accounts sit at the intersection of two recurring Azure problems: accidental data exposure and silent cost waste. A single public container or an open network rule can leak data, while mis-tiered blobs and missing lifecycle policies quietly inflate the bill. This prompt reviews both dimensions at once from the actual account configuration, so the recommendations are grounded in your real settings — allowBlobPublicAccess, shared-key status, network rules, and current tiers — rather than generic hardening advice.
The auth section reflects how mature Azure shops actually secure storage: disable shared-key access, move consumers to Entra ID with data-plane RBAC, and where SAS is unavoidable prefer short-lived user-delegation SAS with stored access policies so tokens can be revoked. These are precisely the controls that turn a storage account from a standing liability into a managed boundary, and they are easy to get wrong without a clear migration order.
The guardrails address the two highest-impact mistakes. Disabling shared-key or public access without first confirming every consumer’s auth path will instantly break account-key-based tools and integrations, and archiving blobs makes them unreadable until a multi-hour rehydration. By requiring consumer verification before lockdown and caution before archiving, the prompt lets you harden and right-tier aggressively while keeping every destructive or breaking step reversible and human-approved.