drdre4664/Zero-trust-iam-lab

# Zero Trust 与 IAM 安全实验室 ## 概述 在 AWS 上的一个生产级 Zero Trust 架构实现，展示了受监管金融环境中使用的企业身份与访问管理模式。涵盖最小权限 IAM 策略、Service Control Policies (SCPs)、基于属性的访问控制 (ABAC)、MFA 强制执行以及自动化 IAM 安全审计。 ## 实现的 Zero Trust 原则 | 原则 | 实现 | |-----------|---------------| | 永不信任，始终验证 | 所有敏感操作都需要 MFA | | 最小权限访问 | 具有权限边界的细粒度 IAM 策略 | | 假设被入侵 | SCPs 甚至在使用管理员凭证时也能防止权限提升 | | 显式验证 | ABAC —— 基于资源标签和用户属性授予访问权限 | | 限制影响范围 | 权限边界限制最大权限 | ## 架构 ``` ┌─────────────────────────────────────────────────────────────┐ │ AWS Organization │ │ │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ Service Control Policies (SCPs) │ │ │ │ (Account-level guardrails — cannot be bypassed) │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │ │ │ Dev Env │ │ Staging Env │ │ Production Env │ │ │ │ │ │ │ │ │ │ │ │ IAM Roles │ │ IAM Roles │ │ IAM Roles │ │ │ │ + Boundaries│ │ + Boundaries│ │ + Boundaries │ │ │ └──────────────┘ └──────────────┘ └──────────────────┘ │ │ │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ ABAC Tag-Based Access │ │ │ │ Environment=prod + Team=security = Access │ │ │ │ Environment=prod + Team=dev = Denied │ │ │ └─────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────┘ ``` ## 展示的企业 IAM 能力 | 能力 | 实现 | 行业标准 | |-----------|---------------|-------------------| | 最小权限 | 细粒度 IAM 策略 | CIS AWS Benchmark | | 权限边界 | IAM 边界策略 | AWS Well-Architected | | Service Control Policies | 组织级护栏 | AWS Organizations | | ABAC | 基于标签的访问控制 | NIST 800-207 Zero Trust | | MFA 强制执行 | 条件性 IAM 策略 | PCI-DSS, SOX | | IAM 审计 | Python 安全扫描器 | CIS Benchmark 1.x | | 特权访问 | 紧急破窗角色 | PAM 最佳实践 | ## 仓库结构 ``` zero-trust-iam-lab/ ├── terraform/ │ ├── main.tf # Core IAM resources │ ├── variables.tf │ ├── outputs.tf │ └── scp.tf # Service Control Policies ├── policies/ │ ├── least-privilege.json # App developer policy │ ├── security-analyst.json # Security team policy │ ├── permission-boundary.json # Maximum permission cap │ └── mfa-enforcement.json # Deny without MFA ├── src/ │ └── iam_auditor.py # IAM security scanner └── docs/ ├── zero-trust-concepts.md └── iam-best-practices.md ``` ## 展示的技能 - Zero Trust 架构设计 - AWS IAM 最小权限实现 - Service Control Policies (SCPs) - 权限边界 - 基于属性的访问控制 (ABAC) - MFA 强制执行策略 - 自动化 IAM 安全审计 - Python AWS SDK (boto3) 脚本编写 ## 经验总结 ### Zero Trust 架构 - Zero Trust 不是你可以购买的产品——它是一个建立在三个原则之上的安全模型：**永不信任，始终验证**；**假设被入侵**；**最小权限访问**。每个访问决策都必须经过显式验证，无论请求是来自网络内部还是外部 - 传统安全模型信任网络边界内的所有内容——Zero Trust 完全消除了这种假设，这就是为什么在现代环境中（员工、承包商和服务从任何地方访问资源时）它至关重要的原因 - **MFA 是 Zero Trust 模型中影响最大的单一控制措施**——它确保即使凭证被泄露（被盗、被暴力破解、被钓鱼），攻击者如果没有第二因素也无法进行身份验证 ### IAM 策略 vs Service Control Policies (SCPs) - **IAM 策略**控制特定用户或角色允许执行的操作——它们在身份级别应用 - **SCPs** 在 AWS 组织级别应用并充当上限——即使 IAM 策略授予了权限，SCP 也可以完全阻止其被使用；任何用户或角色（包括账户管理员）都无法覆盖 SCP - 这种分层方法意味着配置错误或被入侵的 IAM 角色无法超越 SCP 设置的护栏——这是“假设被入侵”原则的实践 ### 权限边界 - 权限边界设定了角色可以拥有的**最大权限**——即使有人稍后尝试附加限制更少的策略，边界也会限制实际生效的内容 - 这可以防止权限提升——获得 IAM 角色访问权限的攻击者无法在边界允许的范围之外为自己授予额外的权限 - 权限边界对于可以创建其他角色的角色尤为重要——如果没有它们，开发者角色可能会创建管理员角色并提升自己的访问权限 ### ABAC 与 RBAC - **RBAC (基于角色的访问控制)** 根据用户的角色授予访问权限——例如，所有开发者都获得相同的访问权限 - **ABAC (基于属性的访问控制)** 根据用户和资源两者的属性（标签）授予访问权限——例如，标记为 `Team=security` 的开发者可以访问标记为 `Environment=prod` 的资源，而标记为 `Team=dev` 的开发者则不能 - 在大型环境中，ABAC 比 RBAC 更精细且更具可扩展性——你不需要为每种访问组合创建新角色；你只需正确标记资源和身份即可 ### 实践中的最小权限 - 最小权限意味着只赋予身份**完成其工作所需的权限，仅此而已**——当它只需要一个特定的 bucket 时，不会授予对所有 S3 buckets 的读取权限 - 被入侵身份的影响范围与其拥有的访问权限成正比——最小权限限制了攻击者使用被盗凭证可以造成的破坏程度 - IAM 审计（在本实验中通过 Python 扫描器实现自动化）至关重要，因为权限会随着时间的推移而积累——角色被添加了权限却很少移除，从而导致权限蔓延

标签：AWS, DPI, Python, 安全合规, 无后门, 网络代理, 身份与访问管理, 逆向工具, 零信任架构