security-assessment

安全评估

步骤 1：收集上下文

询问用户：

您希望我评估哪个工作负载或 AWS 环境的安全性？请提供：

• 工作负载名称以及要分析的代码包／目录
• 合规要求（SOC2、HIPAA、PCI-DSS、FedRAMP、GDPR 等）
• 已知问题（可选）

如果已提供上下文，或当前代码库中包含 IaC，请直接继续。

步骤 2：身份与访问管理发现

分析代码库中的所有 IAM 配置。

您必须检查：

• IAM 角色定义（信任策略和权限策略）
• IAM 策略文档（托管策略和内联策略）
• 服务关联角色和权限边界
• 基于资源的策略（S3 存储桶策略、KMS 密钥策略、SQS 策略）
• Cognito／Identity Center 配置
• API Gateway 授权器
• Lambda 执行角色

对于每项 IAM 资源，请记录：

• 文件路径和行号
• 允许的操作（标记通配符）
• 资源范围（标记通配符）
• 信任关系（谁可以代入）
• 是否遵循最小权限原则

您必须将以下情况标记为高风险：

• 任何对变更操作使用 "Action": "*" 或 "Action": "service:*" 的情况
• 任何允许写入／删除操作的策略中出现 "Resource": "*" 的情况
• 条件过于宽泛的跨账户信任
• 敏感操作缺少 Condition 代码块
• IAM 策略附加到 * 主体
• 长期有效的凭证（代码或配置中的访问密钥）

步骤 3：加密与数据保护发现

分析所有资源的加密配置。

您必须检查：

• KMS 密钥定义和密钥策略
• 所有存储的静态加密设置（S3、EBS、RDS、DynamoDB、EFS、Secrets Manager）
• 传输加密设置（TLS 配置、侦听器规则、安全策略）
• 证书管理（ACM、自签名）
• 密钥管理（Secrets Manager、Parameter Store SecureString、环境变量）
• 数据分类标签

您必须将以下情况标记为高风险：

• 任何未启用静态加密的存储资源
• 任何侦听器或端点使用低于 1.2 的 TLS 版本
• 允许使用弱加密套件（RC4、DES、3DES、基于 MD5 的 MAC）的安全策略
• 生产配置中的自签名或过期证书
• 环境变量、硬编码字符串或配置文件中的密钥（而非使用 Secrets Manager／Parameter Store）
• 未启用轮换的 KMS 密钥
• 未设置默认加密的 S3 存储桶

步骤 4：网络防护发现

分析所有网络安全配置。

您必须检查：

• VPC 定义（子网、路由表、互联网网关）
• 安全组规则（入站和出站）
• 网络 ACL
• WAF 规则和 Web ACL
• VPC 端点（接口型和网关型）
• NAT 网关及其部署位置
• 负载均衡器安全性（侦听器、目标组、安全策略）
• API Gateway 端点类型和限流

您必须将以下情况标记为高风险：

• 安全组在 443／80 以外的端口上允许 0.0.0.0/0 入站
• 安全组允许 0.0.0.0/0 通过 SSH（22）或 RDP（3389）入站
• 公有子网托管数据库或内部服务
• 缺少 S3／DynamoDB 的 VPC 端点（流量经 NAT／互联网传输）
• 面向互联网的端点未配置 WAF
• 出站规则过于宽松（所有流量发往所有目标）

---STOP--- 检查点：发现阶段已完成——请先呈现调查结果。

以下是我发现的安全状况：

• IAM：{找到的角色、策略和访问模式摘要}
• 加密：{静态和传输加密状态摘要}
• 网络：{VPC、安全组、WAF 配置摘要}

是否继续进行完整的安全评估，还是要调整范围？

在用户明确确认之前，不要继续执行。

---

步骤 5：检测与响应发现

分析安全监控和事件响应配置。

你必须检查：

• CloudTrail 配置
• GuardDuty 启用情况
• Security Hub 配置
• Config 规则
• VPC Flow Log 设置
• 针对安全事件（根用户登录、未经授权的 API 调用）的 CloudWatch 警报
• 自动化响应配置（Lambda 修复、Step Functions）
• S3 访问日志记录

步骤 6：计算资源保护发现

分析计算资源安全配置。

你必须检查：

• Lambda 函数配置（运行时、层、VPC 连接、预留并发）
• ECS/EKS 任务定义（特权模式、用户、功能、密钥注入）
• EC2 启动模板（IMDSv2、用户数据、安全组）
• 容器镜像来源和扫描配置
• SSM Session Manager 配置（与 SSH 访问的对比）

以下情况必须标记为 HIGH RISK：

• 容器在未说明理由的情况下以特权模式运行
• 启用了 IMDSv1 的 EC2 实例（跳数限制 > 1，且未要求使用 IMDSv2）
• Lambda 函数具有过于宽泛的 VPC 访问权限
• 未配置容器镜像扫描
• 在 SSM Session Manager 足以满足需求的情况下启用了 SSH 访问

步骤 7：根据 WA 框架问题进行评估

针对每个问题，请提供：状态、证据（文件:行）、差距、风险。

SEC 1 — 如何安全地运行工作负载？

• 查找：安全基线、账户隔离、威胁检测、自动化响应
• 证据：Config 规则、GuardDuty 配置、安全自动化

SEC 2 — 如何管理人员和机器的身份？

• 查找：集中式身份管理、角色分离、凭证生命周期、MFA 配置
• 证据：Identity Center 配置、IAM 角色信任策略、Cognito 设置

SEC 3 — 如何管理人员和机器的权限？

• 查找：最小权限、权限边界、访问分析、定期审查流程
• 证据：IAM 策略、权限边界 ARN、Access Analyzer 配置

SEC 4 — 如何检测和调查安全事件？

• 查找：CloudTrail、GuardDuty、Security Hub、VPC Flow Logs、DNS 日志记录
• 证据：跟踪配置、检测器设置、日志组定义、警报规则

SEC 5 — 如何保护网络资源？

• 查找：VPC 分段、安全组、WAF、私有子网、VPC 端点
• 证据：VPC 构造、安全组规则、WAF ACL、端点定义

SEC 6 — 如何保护计算资源？

• 查找：补丁管理、容器扫描、运行时保护、最小权限
• 证据：启动模板、任务定义、Lambda 配置、扫描配置

SEC 7 — 如何对数据进行分类？

• 查找：数据分类标签、敏感度标签、数据目录配置
• 证据：资源标签、Macie 配置、Glue 目录设置

SEC 8 — 如何保护静态数据？

• 查找：所有存储均启用加密、KMS 策略、密钥轮换
• 证据：IaC 中每项存储资源的加密属性

SEC 9 — 如何保护传输中的数据？

• 查找：强制使用 TLS 1.2+、证书管理、仅允许 HTTPS
• 证据：侦听器配置、安全策略、重定向规则

SEC 10 — 如何预测、响应和从事件中恢复？

• 查找：响应自动化、取证能力、遏制流程
• 证据：修复 Lambda、隔离流程、备份配置

步骤 8：风险评估

对每项发现，按影响 × 可能性进行评估：

影响：轻微（数据暴露有限，未违反合规要求） | 中等（部分数据暴露，存在轻微合规缺口） | 严重（数据全面泄露、违反监管要求、权限提升）

可能性：低（需要串联利用漏洞，且有强有力的补偿性控制） | 中（付出适度努力即可利用，且有部分控制措施） | 高（容易利用，且没有补偿性控制）

影响	可能性	风险等级
严重	高	严重
严重	中	高
严重	低	高
中等	高	高
中等	中	中等
中等	低	中等
轻微	高	中等
轻微	中	低
轻微	低	低

---STOP--- 检查点：评估已完成——请在生成报告前确认发现。

评估摘要：

• 严重发现：{count}
• 高风险发现：{count}
• 中等/低风险发现：{count}

要我生成完整的安全报告，还是先讨论具体发现？

在用户明确确认之前，不要继续执行此步骤之后的内容。

步骤 9：生成发现

# Security Assessment: {Workload Name}

## Executive Summary
- **Date**: {date}
- **Compliance Scope**: {frameworks}
- **Packages Analyzed**: {list}
- **Findings**: {X} Critical, {Y} High, {Z} Medium, {W} Low
- **Overall Security Posture**: {1-5} — {one-line justification}

## Security Scorecard
| Domain | Score (1-5) | Key Strength | Key Gap |
|--------|-------------|--------------|---------|
| Identity & Access | {score} | {strength} | {gap} |
| Data Protection (at rest) | {score} | {strength} | {gap} |
| Data Protection (in transit) | {score} | {strength} | {gap} |
| Network Protection | {score} | {strength} | {gap} |
| Compute Protection | {score} | {strength} | {gap} |
| Detection & Response | {score} | {strength} | {gap} |

## Critical and High Risk Findings
{For each: ID, domain, title, description, evidence (file:line), impact assessment, recommendation, effort, AWS services}

## Medium Risk Findings
{Same format, condensed}

## Low Risk Findings
{Summary table: ID | Domain | Title | Recommendation}

## Compliance Mapping
{If compliance requirements specified, map findings to relevant framework controls}
| Finding ID | SOC2 CC | HIPAA | PCI-DSS | Notes |
|------------|---------|-------|---------|-------|

## Prioritized Remediation Plan

### Quick Wins (< 1 week)
| Finding | Action | Impact | Effort |
|---------|--------|--------|--------|
{Enable encryption, tighten SG rules, rotate keys, fix TLS versions}

### Foundation (1-4 weeks)
| Finding | Action | Impact | Effort | Dependencies |
|---------|--------|--------|--------|--------------|
{Implement least privilege, add WAF, enable GuardDuty, add VPC endpoints}

### Strategic (1-3 months)
| Finding | Action | Impact | Effort | Dependencies |
|---------|--------|--------|--------|--------------|
{Zero-trust network, automated response, forensic capabilities, compliance program}

## Next Steps
{Top 5 concrete security actions the team should take this week}

步骤 10：提供后续协助

完成评估后，提供以下选项：

你希望我：

• 为特定角色设计最小权限 IAM 策略？
• 为安全控制措施（GuardDuty、Security Hub、Config 规则）生成 IaC？
• 针对特定威胁创建事件响应手册？
• 将发现详细映射到特定合规框架？
• 设计网络分段架构？
• 在尽量减少影响的前提下收紧特定安全组规则？

校准指南

• 具备全方位加密、最小权限 IAM、VPC 分段、GuardDuty 和 Security Hub 的工作负载属于成熟状态——重点关注加固、检测深度和响应自动化
• 每项发现都必须有代码证据——在确认尚未启用加密之前，不要直接建议“应启用加密”
• 明确指出协议层风险：TLS < 1.2 始终为严重风险，弱密码套件始终为高风险
• 如果指定了合规要求，将每项严重/高风险发现映射到相关合规控制
• 静态分析不足时，“无法确定”是有效结论（例如，实际 IAM 使用模式需要 Access Analyzer 数据）
• 在列出差距之前，显著肯定良好的安全实践