assaf534/iam-policy-classification-engine

# IAM 策略分类引擎 一个智能体系统，可将 **AWS** 和 **GCP** IAM 策略分类为 `WEAK` 或 `STRONG`，解释*原因*，并自动为任何弱策略生成修复后的最小权限版本。  -orange)  📄 **[完整设计与评估报告 (PDF)](Report.pdf)** — 包含架构、分类标准、结果及局限性。 ## 为什么会有这个项目 IAM 配置错误是导致云安全漏洞最常见的根本原因之一。人工审查无法规模化，而纯粹的静态代码检查工具往往只能产生浅层的、基于规则的结果，从而遗漏诸如权限提升之类的组合攻击。 本项目采用了一种**混合智能体方法**：快速确定性规则负责处理明确的结构性检查，而 LLM 则负责处理真正需要推理的部分（例如，识别危险的操作*组合*）。当策略较弱时，修复子代理会在保留推断意图的前提下对其进行重写。 ## 它的功能 - 根据策略结构自动**检测云平台**（AWS 还是 GCP）。 - 在消耗任何 LLM token 之前，**验证**输入是否为格式良好的 IAM JSON。 - 使用 8 条 AWS 规则 / 4 条 GCP 规则以及 LLM 权限提升检查，将策略**分类**为 `WEAK` 或 `STRONG`。 - 根据严重程度对发现的问题进行**评分**，以得出最终结论。 - 将弱策略**修复**为更严格的版本，然后通过重新运行确定性规则来**重新验证**修复结果。 ## 架构 ``` Input policy JSON │ ▼ cloud_detector ──► routes to AWS or GCP pipeline │ ▼ validator ──► fails fast on malformed input (no LLM call) │ ▼ classifier (top-level agent) ├── deterministic rule tools (structural checks) └── LLM check (Groq) (privilege-escalation reasoning) │ ▼ scoring model ──► WEAK / STRONG │ ▼ (only if WEAK) remediator (sub-agent) ──► tightened policy ──► re-verify ``` **设计原理** | 组件 | 类型 | 原因 | |-----------|------|-----| | Validator | 确定性 | 在进行任何付费/LLM 工作之前拒绝错误输入。 | | 规则工具 | 确定性 | 作为代码实现，二元结构检查更快、更便宜，且没有幻觉。 | | 权限提升检查 | LLM | 危险的操作组合太多，无法硬编码；需要语义推理。 | | Remediator | LLM 子代理 | 没有自主性 — 仅在判定为 `WEAK` 时运行，并将明确的发现作为输入。 | ## 分类规则 **AWS (8 条规则)** | # | 规则 | 严重程度 | |---|------|----------| | 1 | 通配符操作 (`Action: "*"`) | Critical | | 2 | 对敏感操作使用通配符资源 | High | | 3 | 对敏感服务使用通配符 (`iam:*`, `s3:*`, …) | High | | 4 | 敏感操作缺少 MFA 条件 | Medium | | 5 | 过度宽松的 Principal (`Principal: "*"`) | Critical | | 6 | 权限提升路径 *(LLM)* | Critical | | 7 | 缺少网络限制 (`SourceIp`/`SourceVpc`) | Medium | | 8 | 无条件的跨账户 Principal | High | **GCP (4 条规则 + LLM)** | # | 规则 | 严重程度 | |---|------|----------| | 1 | 基础角色 (`roles/owner`, `roles/editor`) | Critical | | 2 | 公开访问 (`allUsers` / `allAuthenticatedUsers`) | Critical | | 3 | 敏感管理员角色 | High | | 4 | 没有条件的敏感角色 | Medium | | 5 | 通过角色组合实现权限提升 *(LLM)* | Critical | **评分模型：** 任何 Critical 发现，或 2 个以上的 High，或 1 个 High + 2 个 Medium，或 2 个以上的 Medium ⇒ `WEAK`。否则为 `STRONG`（如果残留单个较低严重程度的发现，则会带有警告）。 ## 项目结构 ``` . ├── main.py # Orchestrator: analyze_policy() entry point + demo runner ├── cloud_detector.py # Routes input to the AWS or GCP pipeline ├── validator.py # AWS input validation ├── classifier.py # AWS classifier (tools + LLM Rule 6) ├── tools.py # AWS deterministic rule checks ├── remediator.py # AWS remediation sub-agent ├── gcp_validator.py # GCP input validation ├── gcp_classifier.py # GCP classifier (tools + LLM Rule 5) ├── gcp_tools.py # GCP deterministic rule checks ├── gcp_remediator.py # GCP remediation sub-agent ├── requirements.txt └── .env.example # Template for your Groq API key ``` ## 设置 1. 安装依赖： pip install -r requirements.txt 2. 添加你的 Groq API key (免费获取于 )： cp .env.example .env # 然后编辑 .env 并设置 GROQ_API_KEY= ## 运行 ``` python main.py ``` 这会在带有标签的演示集（10 个 AWS + 3 个 GCP 策略）上运行完整 pipeline，并针对每一个策略打印出分类、发现的问题、修复方案和验证结果。 ## 输出示例 ``` { "cloud": "aws", "classification": "WEAK", "findings": [ { "rule": "Rule 1: Wildcard Action", "severity": "Critical", "detail": "Statement uses Action='*', granting permission to perform every AWS API call." } ], "remediated_policy": { "...tightened policy..." }, "remediation_verified": true } ``` ## 结果 在一个涵盖每一条规则、范围从明显较弱到隐蔽权限提升的标签集上进行了评估： | 测试集 | 一致性 | 平均时间 / 策略 | |-------|-----------|-------------------| | AWS (10 个策略) | 10 / 10 | ~1.67 s | | AWS + GCP (13 个策略) | 13 / 13 | ~1.69 s | 延迟主要由 Groq API 往返时间决定；`STRONG` 策略的判定耗时约 0.5 秒（单次 LLM 调用），`WEAK` 策略耗时约 1.6–2.9 秒（权限提升检查 + 修复）。 ## 技术栈 - **语言：** Python - **LLM：** 通过 Groq API 调用 Llama 3.3 70B（免费层级 — 选择它是因为它在零成本下提供了强大的推理能力；规模大于 8B 模型，因为权限提升检查需要多跳推理） - **框架：** 无 — 直接调用 API，以保持 agent 循环的透明度 ## 局限性 - 修复保留了*推断的*意图，而不是保证的意图 — 输出在部署前应经过人工审查。 - 权限提升检测取决于 LLM 的质量；较弱的模型可能会漏掉隐蔽的组合。 - 策略是孤立评判的，不了解周围的负载或环境。 - GCP Remediator 偶尔可能会建议不存在的角色名称；生产系统会根据云提供商的 API 验证建议的角色。

标签：AI智能体, AWS, DLL 劫持, DPI, GCP, IAM, Sysdig, 大语言模型, 最小权限, 模块化设计, 自动化修复, 逆向工具