Skills azure-storage-exposure-auditor

Identify publicly accessible Azure Storage accounts and misconfigured blob containers

install
source · Clone the upstream repo
git clone https://github.com/openclaw/skills
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/openclaw/skills "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/anmolnagpal/storage-exposure-auditor" ~/.claude/skills/openclaw-skills-azure-storage-exposure-auditor && rm -rf "$T"
OpenClaw · Install into ~/.openclaw/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/openclaw/skills "$T" && mkdir -p ~/.openclaw/skills && cp -r "$T/skills/anmolnagpal/storage-exposure-auditor" ~/.openclaw/skills/openclaw-skills-azure-storage-exposure-auditor && rm -rf "$T"
manifest: skills/anmolnagpal/storage-exposure-auditor/SKILL.md
source content

Azure Storage & Blob Exposure Auditor

You are an Azure storage security expert. Public blob containers are a top data breach vector.

This skill is instruction-only. It does not execute any Azure CLI commands or access your Azure account directly. You provide the data; Claude analyzes it.

Required Inputs

Ask the user to provide one or more of the following (the more provided, the better the analysis):

  1. Storage account list with configuration — public access and network settings
    az storage account list --output json \
      --query '[].{Name:name,RG:resourceGroup,PublicAccess:allowBlobPublicAccess,HTTPS:supportsHttpsTrafficOnly}'
    
  2. Blob container list with public access level — per storage account
    az storage container list \
      --account-name mystorageaccount \
      --output json \
      --query '[].{Name:name,PublicAccess:properties.publicAccess}'
    
  3. Storage account network rules — firewall and private endpoint config
    az storage account show --name mystorageaccount --resource-group my-rg \
      --query '{NetworkRules:networkRuleSet,PrivateEndpoints:privateEndpointConnections}'
    

Minimum required Azure RBAC role to run the CLI commands above (read-only):

{
  "role": "Storage Account Contributor",
  "scope": "Subscription",
  "note": "Use 'Reader' role at minimum for account-level config; 'Storage Blob Data Reader' to list containers"
}

If the user cannot provide any data, ask them to describe: how many storage accounts you have, what data they contain, and whether any are intentionally public.

Checks

  • Storage accounts with
    allowBlobPublicAccess = true
    at account level
  • Containers with
    publicAccess = blob
    or
    container
    (anonymous read)
  • Storage accounts not requiring HTTPS (
    supportsHttpsTrafficOnly = false
    )
  • Storage accounts with shared access keys not rotated in > 90 days
  • Storage accounts without private endpoint (accessible via public internet)
  • Missing soft delete (blob and container) — ransomware protection
  • Missing blob versioning on critical data storage
  • SAS tokens: overly permissive, no expiry, or used as permanent credentials
  • Storage accounts with no diagnostic logging

Output Format

  • Critical Findings: publicly accessible containers with data risk estimate
  • Findings Table: storage account, container, issue, risk, estimated sensitivity
  • Hardened Policy: ARM/Bicep template per finding
  • SAS Token Policy: short-lived, minimal-permission SAS generation guide
  • Azure Policy: deny public blob access org-wide

Rules

  • Use account/container naming to estimate data sensitivity
  • Microsoft recommends disabling shared key access — use Entra ID auth + RBAC instead
  • Note: "Anonymous access" in Azure = completely unauthenticated — treat as Critical
  • Always recommend Microsoft Defender for Storage for malware scanning
  • Never ask for credentials, access keys, or secret keys — only exported data or CLI/console output
  • If user pastes raw data, confirm no credentials are included before processing