云安全
云安全 (Cloud Security)
云安全态势评估技能,用于检测 IAM 权限提升、公共存储暴露、网络配置风险以及基础设施即代码 (IaC) 的误配置。本技能并非针对活跃云入侵的事件响应(见 incident-response)或应用程序漏洞扫描(见 security-pen-testing),而是侧重于通过系统性的云配置分析来防止被利用。
---
目录
---
概述
本技能的功能
本技能提供云安全态势管理 (CSPM) 的方法论和工具——系统性地检查云配置,以发现会产生可利用攻击面的误配置。涵盖内容包括 IAM 权限提升路径、存储公开暴露、网络权限过大以及基础设施代码安全。
与其他安全技能的区别
| 技能 | 关注点 | 方法 |
|-------|-------|----------|
| cloud-security (本技能) | 云配置风险 | 预防性 —— 在被利用前进行评估 |
| incident-response | 活跃的云事件 | 响应性 —— 对已确认的云入侵进行分诊 |
| threat-detection | 行为异常 | 主动性 —— 在云日志中猎寻攻击者活动 |
| security-pen-testing | 应用程序漏洞 | 攻击性 —— 主动利用发现的弱点 |
前置条件
需要对 JSON 格式的 IAM 策略文档、S3 存储桶配置和安全组规则具有读取权限。如需持续监控,请集成云服务商 API(如 AWS Config, Azure Policy, GCP Security Command Center)。
---
云态势检查工具
cloud_posture_check.py 工具可运行三种类型的检查:iam(权限提升)、s3(公共访问)和 sg(网络暴露)。它能根据配置文件结构自动检测检查类型,或接受显式的 --check 标志。
# 分析 IAM 策略中的权限提升路径
python3 scripts/cloud_posture_check.py policy.json --check iam --json
评估 S3 存储桶配置的公共访问情况
python3 scripts/cloud_posture_check.py bucket_config.json --check s3 --json
检查安全组规则中是否存在开放的管理端口
python3 scripts/cloud_posture_check.py sg.json --check sg --json
运行所有检查,并针对面向互联网的风险提升严重等级
python3 scripts/cloud_posture_check.py config.json --check all \
--provider aws --severity-modifier internet-facing --json
受监管数据上下文(将所有发现结果的严重等级提升一级)
python3 scripts/cloud_posture_check.py config.json --check all \
--severity-modifier regulated-data --json
通过 AWS CLI 管道传输 IAM 策略
aws iam get-policy-version --policy-arn arn:aws:iam::123456789012:policy/MyPolicy \
--version-id v1 | jq '.PolicyVersion.Document' | \### 退出码
| 代码 | 含义 | 建议操作 |
|------|---------|-----------------|
| 0 | 无高/危风险项 | 无需操作 |
| 1 | 存在高危风险项 | 24 小时内修复 |
| 2 | 存在严重风险项 | 立即修复 —— 若处于活跃状态请升级为事件响应 |
---
IAM 策略分析
IAM 分析用于检测权限提升路径、过度授权、公共主体暴露以及数据外泄风险。
权限提升模式
| 模式 | 严重程度 | 关键操作组合 | MITRE |
|---------|----------|------------------------|-------|
| Lambda PassRole 提升 | 严重 (Critical) | iam:PassRole + lambda:CreateFunction | T1078.004 |
| EC2 实例配置文件滥用 | 严重 (Critical) | iam:PassRole + ec2:RunInstances | T1078.004 |
| CloudFormation PassRole | 严重 (Critical) | iam:PassRole + cloudformation:CreateStack | T1078.004 |
| 自行附加策略提升 | 严重 (Critical) | iam:AttachUserPolicy + sts:GetCallerIdentity | T1484.001 |
| 内联策略自行提升 | 严重 (Critical) | iam:PutUserPolicy + sts:GetCallerIdentity | T1484.001 |
| 策略版本后门 | 严重 (Critical) | iam:CreatePolicyVersion + iam:ListPolicies | T1484.001 |
| 凭据收割 | 高 (High) | iam:CreateAccessKey + iam:ListUsers | T1098.001 |
| 用户组权限提升 | 高 (High) | iam:AddUserToGroup + iam:ListGroups | T1098 |
| 密码重置攻击 | 高 (High) | iam:UpdateLoginProfile + iam:ListUsers | T1098 |
| 服务级通配符 | 高 (High) | iam:* 或 s3:* 或 ec2:* | T1078.004 |
IAM 风险项严重程度指南
| 风险类型 | 条件 | 严重程度 |
|-------------|-----------|----------|
| 全局管理员通配符 | Action=* Resource=* | 严重 (Critical) |
| 公共主体 | Principal: '*' | 严重 (Critical) |
| 危险操作组合 | 双操作权限提升路径 | 严重 (Critical) |
| 单一权限提升操作 | 作用于通配符资源 | 高 (High) |
| 数据外泄操作 | s3:GetObject, secretsmanager:GetSecretValue 作用于 * | 高 (High) |
| 服务通配符 | service:* 操作 | 高 (High) |
| 指定资源的数据操作 | 范围合理 | 低/正常 (Low/Clean) |
最小权限建议
对于每个严重或高危风险项,工具会输出一个 least_privilege_suggestion 字段,提供具体的修复指导:
- 将
Action: * 替换为所需的具体操作列表
- 将
Resource: * 替换为具体的 ARN 模式
- 使用 AWS Access Analyzer 识别实际使用的权限
- 将危险的操作组合拆分到具有不同信任策略的不同角色中
---
S3 暴露评估
S3 评估从四个维度进行检查:公共访问阻止配置、存储桶 ACL、存储桶策略主体暴露以及默认加密。
S3 配置检查矩阵
| 检查项 | 风险条件 | 严重程度 |
|-------|------------------|----------|
| 公共访问阻止 | 四个标志位中任一缺失或为 false | 高 (High) |
| 存储桶 ACL | public-read-write | 严重 (Critical) |
| 存储桶 ACL | public-read 或 authenticated-read | 高 (High) |
| 存储桶策略主体 | "Principal": "*" 且为 Allow | 严重 (Critical) |
| 默认加密 | 无 ServerSideEncryptionConfiguration | 高 (High) |
| 默认加密 | 非标准 SSEAlgorithm | 中 (Medium) |
| 无公共访问阻止配置 | 状态未知 | 中 (Medium) |
推荐的 S3 基线配置
eEncryptionConfiguration": {
"Rules": [{
"ApplyServerSideEncryptionByDefault": {
"SSEAlgorithm": "aws:kms",
"KMSMasterKeyID": "arn:aws:kms:region:account:key/key-id"
},
"BucketKeyEnabled": true
}]
},
"ACL": "private"
}存储桶级别和 AWS 账户级别的四项公共访问阻止设置必须全部启用。如果两者未同时强制执行,账户级设置可能会被存储桶级设置覆盖。
---
安全组分析
安全组分析会标记将管理端口、数据库端口或所有流量暴露给互联网 CIDR(0.0.0.0/0, ::/0)的入站规则。
关键端口暴露规则
| 端口 | 服务 | 发现严重程度 | 修复方案 |
|------|---------|-----------------|-------------|
| 22 | SSH | Critical | 限制为 VPN CIDR 或使用 AWS Systems Manager Session Manager |
| 3389 | RDP | Critical | 限制为 VPN CIDR 或使用 AWS Fleet Manager |
| 0–65535 (全部) | 所有流量 | Critical | 删除该规则;仅添加必要的特定端口 |
高风险数据库端口规则
| 端口 | 服务 | 发现严重程度 | 修复方案 |
|------|---------|-----------------|-------------|
| 1433 | MSSQL | High | 仅允许来自应用层安全组的访问 —— 迁移至私有子网 |
| 3306 | MySQL | High | 仅允许来自应用层安全组的访问 —— 迁移至私有子网 |
| 5432 | PostgreSQL | High | 仅允许来自应用层安全组的访问 —— 迁移至私有子网 |
| 27017 | MongoDB | High | 仅允许来自应用层安全组的访问 —— 迁移至私有子网 |
| 6379 | Redis | High | 仅允许来自应用层安全组的访问 —— 迁移至私有子网 |
| 9200 | Elasticsearch | High | 仅允许来自应用层安全组的访问 —— 迁移至私有子网 |
严重程度修正符
当评估的资源可直接通过互联网访问(如负载均衡器、API 网关、公共 EC2)时,请使用 --severity-modifier internet-facing。当资源处理 PCI、HIPAA 或 GDPR 监管数据时,请使用 --severity-modifier regulated-data。这两个修正符都会将每项发现的严重程度提升一个级别。
---
IaC 安全审查
基础设施即代码 (IaC) 审查可在部署前的定义阶段捕捉配置问题。
IaC 检查矩阵
| 工具 | 检查类型 | 运行时机 |
|------|-------------|-------------|
| Terraform | 资源级检查 (aws_s3_bucket_acl, aws_security_group, aws_iam_policy_document) | Pre-plan, pre-apply, PR 门禁 |
| CloudFormation | 模板属性验证 (PublicAccessBlockConfiguration, SecurityGroupIngress) | 模板 lint, 部署门禁 |
| Kubernetes manifests | 容器权限、网络策略、密钥暴露 | PR 门禁, 准入控制器 (admission controller) |
| Helm charts | 同 Kubernetes | PR 门禁 |
Terraform IAM 策略示例 —— 错误 vs 正确
# 错误:将产生关键级 (Critical) 发现
resource "aws_iam_policy" "bad_policy" {
policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Action = "*"
Resource = "*"
}]
})
}
正确:最小权限原则
resource "aws_iam_policy" "good_policy" {
policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Action = ["s3:GetObject", "s3:PutObject"]
Resource = "arn:aws:s3:::my-specific-bucket/*"
}]
})
}完整 CSPM 检查参考:references/cspm-checks.md
---
云供应商覆盖矩阵
| 检查类型 | AWS | Azure | GCP |
|-----------|-----|-------|-----|
| IAM 权限提升 | 全覆盖 (IAM 策略, 信任策略, ESCA |
| LATION_COMBOS) | 部分 (RBAC 分配, 服务主体风险) | 部分 (IAM 绑定, 工作负载身份) |
| 存储公开访问 | 全面 (S3 存储桶策略, ACL, 公开访问阻止) | 部分 (Blob SAS 令牌, 容器访问级别) | 部分 (GCS 存储桶 IAM, 统一存储桶级访问) |
| 网络暴露 | 全面 (安全组, NACL, 端口级分析) | 部分 (NSG 规则, 入站端口分析) | 部分 (防火墙规则, VPC 防火墙) |
| IaC 扫描 | 全面 (Terraform, CloudFormation) | 部分 (ARM 模板, Bicep) | 部分 (Deployment Manager) |
---
工作流
工作流 1:快速状态检查 (20 分钟)
适用于新配置的资源或部署前审查:
# 1. 导出 IAM 策略文档
aws iam get-policy-version --policy-arn ARN --version-id v1 | \
jq '.PolicyVersion.Document' > policy.json
python3 scripts/cloud_posture_check.py policy.json --check iam --json
2. 检查 S3 存储桶配置
aws s3api get-bucket-acl --bucket my-bucket > acl.json
aws s3api get-public-access-block --bucket my-bucket >> bucket.json
python3 scripts/cloud_posture_check.py bucket.json --check s3 --json
3. 审查安全组中开放的管理端口
aws ec2 describe-security-groups --group-ids sg-123456 | \
jq '.SecurityGroups[0]' > sg.json
python3 scripts/cloud_posture_check.py sg.json --check sg --json决策:退出码 2 = 阻止部署并修复;退出码 1 = 计划在 24 小时内修复。
工作流 2:全面云安全评估 (多日)
第一天 — IAM 与身份:
1. 导出所有附加到生产角色的 IAM 策略
2. 对每项策略运行 cloud_posture_check.py --check iam
3. 映射所有发现的权限提升路径
4. 识别权限过高的服务账户和角色
5. 审查跨账户信任策略
第二天 — 存储与网络:
1. 枚举所有 S3 存储桶并导出配置
2. 对数据存储桶运行 cloud_posture_check.py --check s3 --severity-modifier regulated-data
3. 导出所有 VPC 的安全组配置
4. 对面向互联网的资源运行 cloud_posture_check.py --check sg
5. 审查 NACL 规则以查找网络分段漏洞
第三天 — IaC 与持续集成:
1. 审查版本控制中的 Terraform/CloudFormation 模板
2. 检查 CI/CD 流水线中的 IaC 安全门禁
3. 根据 references/cspm-checks.md 验证发现的问题
4. 制定按优先级排序的修复计划 (紧急 $\rightarrow$ 高 $\rightarrow$ 中)
工作流 3:CI/CD 安全门禁
将状态检查集成到部署流水线中,防止配置错误的资源进入生产环境:
# 在 terraform apply 之前验证 IaC
terraform show -json plan.json | \
jq '[.resource_changes[].change.after | select(. != null)]' > resources.json
python3 scripts/cloud_posture_check.py resources.json --check all --json
if [ $? -eq 2 ]; then
echo "发现严重云安全问题 — 阻止部署"
exit 1
fi
在修改前验证现有的 S3 存储桶
aws s3api get-bucket-policy --bucket "${BUCKET}" | jq '.Policy | fromjson' | \
python3 scripts/cloud_posture_check.py - --check s3 \
--severity-modifier regulated-data --json---
反模式
1. 在不检查权限提升组合的情况下运行 IAM 分析 — 孤立的高风险操作可能看起来风险较低。真正的危险在于组合:单独的 iam:PassRole 并不关键,但 iam:PassRole + lambda:CreateFunction 是一个确定的权限提升路径。务必分析
1. 仅关注单个操作而非完整语句 —— 应分析完整的语句,而非孤立的单个操作。
2. 仅启用存储桶级(bucket-level)公共访问阻止 —— AWS S3 同时具有账户级和存储桶级的公共访问阻止设置。存储桶级设置可以覆盖账户级设置。两者必须同时配置。如果任何存储桶存在显式覆盖,仅配置账户级阻止是不够的。
3. 将公开资源的 --severity-modifier internet-facing 视为可选 —— 面向互联网的资源比内部资源的暴露面大得多。面向互联网的基础设施中的高危发现应被视为严重(critical)。对于 DMZ、负载均衡器和 API 网关配置,请务必应用 --severity-modifier internet-facing。
4. 仅检查管理员策略 —— 权限提升路径通常源于那些组合了看似无害权限的非管理员策略。必须检查所有附加到生产环境身份的策略,而不仅仅是具有明显高权限的策略。
5. 在没有根因分析的情况下修复发现项 —— 在不了解授予原因的情况下删除危险权限,会导致该权限被重新添加。在删除每个高风险权限之前,请记录其业务合理性,以防止其被悄悄重新引入。
6. 忽略服务账户的过度授权 —— 服务账户在开发期间经常被过度配置,且在生产环境中从未被精简。生产环境中的每个服务账户必须通过 AWS Access Analyzer 或同等工具进行审计,以识别并删除未使用的权限。
7. 不对受监管数据工作负载应用严重程度修饰符 —— 通用 S3 存储桶中的高危发现与包含 PHI(受保护健康信息)或持卡人数据的存储桶中的相同发现截然不同。在评估受监管数据环境中的资源时,请务必使用 --severity-modifier regulated-data。
---
交叉引用
| 技能 | 关系 |
|-------|-------------|
| incident-response | 严重发现(如公开 S3、确认激活的权限提升)可能会触发事件分类 |
| threat-detection | 云姿态发现可创建威胁猎寻目标 —— 过度授权的角色很可能是横向移动的目的地 |
| red-team | 红队演习专门测试在姿态评估中发现的云配置错误的可利用性 |
| security-pen-testing | 云姿态发现项会提供给渗透测试评估的基础设施安全部分 |