企业官网建设流程全解析

Azure 存储账户配置审计实战：基于 Anthropic-Cybersecurity-Skills 检测失配的 Azure Storage

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills

本指南以 detecting-misconfigured-azure-storage 技能为核心，系统讲解如何在订阅级对 Azure Storage 账户展开安全审计：从枚举全部存储账户、识别公开访问的 Blob 容器、核查网络 ACL 与防火墙、验证加密与 TLS 版本，到审计 SAS 令牌与访问密钥、确认诊断日志是否开启，最终产出一份可直接汇报的审计报告。读完本文，你将掌握用 Azure CLI、Azure Resource Graph、PowerShell 与 Defender for Storage 组合检测 Azure 存储失配配置的完整实战方法，并能借助仓库自带的 agent.py 自动化审计脚本提升效率。

适用场景与边界

该技能适用于以下典型任务：

• 跨订阅对 Azure Storage 账户执行安全审计；
• 响应 Microsoft Defender for Storage 关于匿名访问或数据外泄的告警；
• 合规验证需要确认加密、网络限制与访问日志是否满足要求；
• 排查通过公共 Blob 容器暴露的数据泄露风险；
• 新订阅接入时建立存储安全基线。

技能同时明确界定了不适用边界：Azure SQL 或 Cosmos DB 的安全审计应使用专门的数据库安全工具；存储操作的实时威胁检测应交给 Defender for Storage；对 Azure Files 或 Data Lake Gen2 的专项审计需要在现有检查项基础上改造后使用。

前置条件

六步审计工作流

Step 1：枚举全部存储账户与基础配置

首先跨订阅列出所有存储账户，评估其基础安全设置。最直接的方式是使用 Azure CLI 的 JMESPath 查询：

# 列出所有订阅下的存储账户 az storage account list \ --query "[].{Name:name, ResourceGroup:resourceGroup, Location:location, Kind:kind, Sku:sku.name, HttpsOnly:enableHttpsTrafficOnly, MinTLS:minimumTlsVersion, PublicAccess:allowBlobPublicAccess}" \ -o table

当订阅数量多、需要跨订阅聚合时，用 Azure Resource Graph 效率更高：

az graph query -q " Resources | where type == 'microsoft.storage/storageaccounts' | project name, resourceGroup, subscriptionId, location, properties.allowBlobPublicAccess, properties.enableHttpsTrafficOnly, properties.minimumTlsVersion, properties.networkAcls.defaultAction " -o table

基础配置阶段重点核查的字段包括：allowBlobPublicAccess（是否允许匿名读）、enableHttpsTrafficOnly（是否强制 HTTPS）、minimumTlsVersion（最低 TLS 版本）以及networkAcls.defaultAction（网络默认放行还是拒绝）。

Step 2：检测公开可访问的 Blob 容器

匿名公开访问是 Azure 存储最常见的失配配置之一，可能导致 API 密钥、数据库连接串等敏感文件被任何人读取。检测分三层推进：先定位开启allowBlobPublicAccess的账户，再列出其中设置了公共访问级别的容器，最后用curl实测匿名枚举是否可行。

# 检查每个存储账户的公共 Blob 访问设置 for account in $(az storage account list --query "[].name" -o tsv); do public=$(az storage account show --name "$account" --query "allowBlobPublicAccess" -o tsv) echo "$account: allowBlobPublicAccess=$public" done # 列出设置了公共访问级别的容器 for account in $(az storage account list --query "[?allowBlobPublicAccess==true].name" -o tsv); do key=$(az storage account keys list --account-name "$account" --query "[0].value" -o tsv) echo "=== $account ===" az storage container list \ --account-name "$account" \ --account-key "$key" \ --query "[?properties.publicAccess!='off' && properties.publicAccess!=null].{Container:name, PublicAccess:properties.publicAccess}" \ -o table 2>/dev/null done # 对发现的公共容器实测匿名访问 curl -s "https://ACCOUNT.blob.core.windows.net/CONTAINER?restype=container&comp=list" | head -50

Blob 服务层面还有两个值得核查的防御项（见 api-reference.md）：软删除（soft delete）应开启并保留 7–14 天，容器权限应设为off：

# 设置容器为私有 az storage container set-permission --name mycontainer \ --account-name mystorageacct --public-access off # 启用 Blob 软删除并保留 14 天 az storage blob service-properties delete-policy update \ --account-name mystorageacct --enable true --days-retained 14

Step 3：审计网络访问与防火墙规则

存储账户的防火墙规则决定其是否对公网开放。先找出defaultAction为Allow（即对所有网络开放）的账户，再逐账户输出详细的 IP 规则、VNet 规则与bypass配置，最后检查是否配置了 Blob 服务的私有终结点。

# 找出对所有网络开放（defaultAction=Allow）的存储账户 az storage account list \ --query "[?networkRuleSet.defaultAction=='Allow'].{Name:name, DefaultAction:networkRuleSet.defaultAction, VNetRules:networkRuleSet.virtualNetworkRules}" \ -o table # 逐账户审计网络规则 for account in $(az storage account list --query "[].name" -o tsv); do echo "=== $account ===" az storage account show --name "$account" \ --query "{DefaultAction:networkRuleSet.defaultAction, IPRules:networkRuleSet.ipRules[*].ipAddressOrRange, VNetRules:networkRuleSet.virtualNetworkRules[*].virtualNetworkResourceId, Bypass:networkRuleSet.bypass}" \ -o json done # 查找配置了私有终结点的存储账户 az network private-endpoint list \ --query "[?privateLinkServiceConnections[0].groupIds[0]=='blob'].{Name:name, Storage:privateLinkServiceConnections[0].privateLinkServiceId}" \ -o table

发现违规后可执行如下修复命令（参考 api-reference.md）：

# 查看当前网络规则 az storage account network-rule list --account-name mystorageacct --resource-group myrg # 默认动作改为拒绝 az storage account update --name mystorageacct --resource-group myrg \ --default-action Deny # 添加允许的 IP 规则 az storage account network-rule add --account-name mystorageacct \ --resource-group myrg --ip-address 203.0.113.0/24

Step 4：验证加密设置与密钥管理

存储账户必须启用静态加密，并明确密钥来源（Microsoft 托管密钥或客户托管密钥 CMK）。同时核查是否存在启用基础设施级双重加密（requireInfrastructureEncryption）以及 TLS 版本低于 1.2 的账户。

# 检查所有存储账户的加密配置 for account in $(az storage account list --query "[].name" -o tsv); do echo "=== $account ===" az storage account show --name "$account" \ --query "{Encryption:encryption.services, KeySource:encryption.keySource, KeyVaultUri:encryption.keyVaultProperties.keyVaultUri, InfraEncryption:encryption.requireInfrastructureEncryption}" \ -o json done # 找出未启用基础设施双重加密的账户 az storage account list \ --query "[?encryption.requireInfrastructureEncryption!=true].{Name:name, KeySource:encryption.keySource}" \ -o table # 找出 TLS 版本低于 1.2 的账户 az storage account list \ --query "[?minimumTlsVersion!='TLS1_2'].{Name:name, TLS:minimumTlsVersion}" \ -o table

若账户不满足加密与传输安全基线，可执行修复（见 api-reference.md）：

# 强制 HTTPS az storage account update --name mystorageacct -g myrg --https-only true # 最低 TLS 1.2 az storage account update --name mystorageacct -g myrg --min-tls-version TLS1_2

Step 5：审计 SAS 令牌与访问密钥

过度授权的 SAS 令牌与长期不轮换的账户密钥是凭据风险的常见来源。审计要点包括：密钥最近轮换时间、是否允许共享密钥访问（建议 AAD 专属场景下禁用），以及容器上存储访问策略（stored access policy）的治理情况。

# 检查存储账户密钥最近轮换时间 for account in $(az storage account list --query "[].name" -o tsv); do echo "=== $account ===" az storage account keys list \ --account-name "$account" \ --query "[].{KeyName:keyName, CreationTime:creationTime}" \ -o table done # 检查是否允许共享密钥访问（AAD-only 场景应关闭） az storage account list \ --query "[].{Name:name, AllowSharedKeyAccess:allowSharedKeyAccess}" \ -o table # 审查容器上的存储访问策略（SAS 治理） for account in $(az storage account list --query "[].name" -o tsv); do key=$(az storage account keys list --account-name "$account" --query "[0].value" -o tsv 2>/dev/null) for container in $(az storage container list --account-name "$account" --account-key "$key" --query "[].name" -o tsv 2>/dev/null); do policies=$(az storage container policy list --container-name "$container" --account-name "$account" --account-key "$key" 2>/dev/null) [ -n "$policies" ] && echo "$account/$container: $policies" done done

修复方面，将公共访问关闭的命令为（见 api-reference.md）：

az storage account update --name mystorageacct -g myrg --allow-blob-public-access false

Step 6：检查诊断日志与监控

缺失诊断日志意味着安全事件无法回溯。需核查两处：Azure Monitor 的诊断设置（诊断设置列表）与 Blob 服务的 Storage Analytics 日志属性。

# 检查存储账户的诊断设置 for account in $(az storage account list --query "[].name" -o tsv); do rg=$(az storage account show --name "$account" --query "resourceGroup" -o tsv) echo "=== $account ===" az monitor diagnostic-settings list \ --resource "/subscriptions/$(az account show --query id -o tsv)/resourceGroups/$rg/providers/Microsoft.Storage/storageAccounts/$account" \ --query "[].{Name:name, Logs:logs[*].category, Metrics:metrics[*].category}" \ -o json 2>/dev/null || echo " No diagnostic settings configured" done # 检查 Blob 服务日志属性 for account in $(az storage account list --query "[].name" -o tsv); do key=$(az storage account keys list --account-name "$account" --query "[0].value" -o tsv 2>/dev/null) az storage logging show \ --account-name "$account" \ --account-key "$key" \ --services b 2>/dev/null done

关键概念速查

安全基线速查表

以下检查清单源自 api-reference.md，可与上面六步工作流配合使用：

Defender for Storage 告警参考

当审计与实时告警结合时，以下 Defender 告警类别需重点关注（来源 api-reference.md）：

自动化：用 agent.py 脚本批量审计

仓库在该技能目录下提供了 scripts/agent.py，将上述手动审计逻辑封装成可复用的命令行工具。脚本通过subprocess调用 Azure CLI 并以 JSON 解析输出（见az_cli()函数），支持以下操作：

# 审计订阅下所有存储账户（默认动作） python3 agent.py audit-all # 审计单个存储账户 python3 agent.py audit <account-name> <resource-group> # 仅列出存储账户 python3 agent.py list # 检查指定账户的公共容器 python3 agent.py public <account-name> # 检查指定账户的网络规则 python3 agent.py network <account-name> <resource-group>

从源码看（agent.py），audit_storage_account()聚合了多类检查：enableHttpsTrafficOnly未开启记为HIGH，minimumTlsVersion低于TLS1_2记为HIGH，allowBlobPublicAccess开启则记为CRITICAL；check_network_rules()（agent.py）在defaultAction为Allow且无任何 IP/VNet 规则时追加网络失配问题。audit_all_accounts()最终汇总账户总数、发现总数与 CRITICAL 级问题数，输出结构化的 JSON 报告，便于接入后续自动化流程（如生成工单或汇总仪表盘）。

常见实战场景：开发者误配导致的存储暴露

背景：某开发者为 Web 应用创建存储账户存放静态文件，开启了 Blob 公共访问，却不慎将 API 密钥与数据库连接串放进了公开容器。

处置流程：

1. 运行az storage account list过滤allowBlobPublicAccess=true的账户；
2. 枚举访问级别为blob或container的容器；
3. 列出公共容器内容，识别敏感文件；
4. 检查 Defender for Storage 告警，确认是否有来自异常 IP 的访问；
5. 立即将存储账户的allowBlobPublicAccess设为false；
6. 轮换公共容器中暴露的所有凭据；
7. 启用网络 ACL，将访问限制到应用 VNet；
8. 通过 Azure CDN 或 Front Door 提供合法的公共内容分发。

常见陷阱：直接关闭公共访问会立刻中断以公共方式提供内容的既有应用。应与开发团队协调，先接入 Azure CDN 再禁用公共访问；在密钥轮换前生成的 SAS 令牌，除非底层存储密钥重新生成，否则将一直有效至到期。

报告输出格式

审计完成后，可按以下模板输出报告（示例）：

Azure Storage Security Audit Report ====================================== Subscription: Production (SUB-ID) Assessment Date: 2026-02-23 Storage Accounts Audited: 24 CRITICAL FINDINGS: [STOR-001] Public Blob Access Enabled Account: webapp-static-prod Container: uploads (PublicAccess: blob) Risk: Anonymous users can read all blobs in the container Contents: 1,247 files including .env and config.json Remediation: Disable allowBlobPublicAccess, use Azure CDN with SAS [STOR-002] Storage Account Open to All Networks Account: contenteditable="false">【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills