cyaoyang/aws-iam-access-management

# AWS IAM 访问管理 ## 执行摘要 本项目演示了在 AWS 中实现安全的身份与访问管理（IAM）。它侧重于通过应用最小权限原则、实施基于角色的访问控制（RBAC）、启用多因素认证（MFA）以及验证用户权限来保护云资源。 本实现反映了企业云环境中通常采用的安全实践。 # 业务场景 一家不断发展的科技公司最近将其基础架构迁移到了 AWS。 随着员工数量的增加，使用 root 账户进行管理不再安全，也不具备可扩展性。 公司需要一个满足以下要求的 IAM 解决方案： - 分离管理职责 - 限制开发人员访问 - 为审计人员提供只读可见性 - 使用 MFA 保护特权账户 - 遵循最小权限原则 作为云安全工程师，您的任务是设计并实施此解决方案。 # 项目目标 - 创建 IAM 用户 - 创建 IAM 角色 - 配置 RBAC - 应用最小权限 - 启用 MFA - 验证权限 # 使用的 AWS 服务 | 服务 | 用途 | |--------------|-----------------------| | IAM | 身份管理 | | MFA | 安全认证 | | IAM Policies | 授权 | | IAM Roles | RBAC | # 架构图 # 解决方案设计 ## IAM 用户 | 用户 | 角色 | |---------|--------------| | Alice | 管理员 | | Bob | 开发人员 | | Charlie | 审计人员 | ## IAM 角色 | 角色 | 权限 | |---------------|-----------------------| | Administrator | 完全访问权限 | | Developer | 开发资源 | | Auditor | 只读 | ## 权限模型 本项目的权限模型是遵循**最小权限原则**和**基于角色的访问控制（RBAC）**设计的。 创建了三个 IAM 用户来代表常见的组织角色： - **Administrator** - **Developer** - **Auditor** 为了简化权限管理并演示 RBAC，每个用户都被分配到相应的 IAM 组： - **Admin-Group** - **Developer-Group** - **Auditor-Group** 权限被分配给 IAM 组，而不是直接分配给单个用户。这种方法简化了管理，提高了可扩展性，并确保具有相同工作职责的用户继承一致的权限集。 每个角色仅被授予履行其职责所需的权限，从而减少了攻击面，并将未经授权的访问或意外更改 AWS 资源的风险降至最低。 ### 管理员 **Administrator** 用户被授予 **AdministratorAccess** 托管策略，以模拟负责管理 AWS 环境的云管理员。此角色对 AWS 资源具有不受限制的访问权限，包括身份与访问管理（IAM）、计算、存储、网络和安全服务。 由于这是一个高度特权的角色，因此应始终使用**多因素认证（MFA）**进行保护，并且仅在需要执行管理任务时使用。 ### 开发人员 **Developer** 用户被授予以下权限： - Amazon EC2 – 完全访问权限 - Amazon S3 – 完全访问权限 - Amazon CloudWatch Logs – 只读 此权限集使开发人员能够部署和管理应用程序资源，同时防止他们修改 IAM 配置或其他安全关键设置。通过限制管理权限，组织降低了 AWS 环境发生意外或恶意更改的风险。 ### 审计人员 **Auditor** 用户被授予对以下内容的只读权限： - IAM - Amazon EC2 - Amazon S3 - AWS CloudTrail - Amazon CloudWatch - AWS Config 这些权限允许审计人员审查安全配置、监控资源使用情况、检查审计日志和验证合规性，而无需修改或删除 AWS 资源的能力。只读访问在支持治理和安全审计活动的同时，维护了环境的完整性。 ### 应用的安全原则 此权限模型演示了几个核心的云安全原则： - **最小权限原则：** 用户仅获得执行其分配的任务所需的权限。 - **基于角色的访问控制（RBAC）：** 权限是根据工作职责而不是单个用户分配的。 # 实施说明 ## 步骤 1 — 创建 IAM 用户 ### 为什么？ 创建单独的 IAM 用户而不是使用 AWS root 账户可以通过确保每个操作都能追溯到特定用户（不可否认性）来提高问责制。它还通过减少在日常管理任务中使用高度特权的 root 账户来加强安全性。 ### 截图 ### 安全考虑 * 每个人都应该在 AWS 云中拥有自己的身份。 * 每个特权账户都应受到多因素认证（MFA）的保护。 * 每个账户都应使用至少包含 12 个字符的强密码进行保护，密码必须包含大小写字母和至少一个特殊字符。 * AWS root 账户不应用于日常管理任务。相反，管理员应使用仅具有执行其工作职能所需权限的 IAM 用户或 IAM 角色。 * 权限应遵循最小权限原则，仅授予用户履行其职责所需的访问权限。 ## 步骤 2 — 配置最小权限 * 管理员用户被置于具有 AdministratorAccess 权限的 admin-group 中 * 开发人员用户被置于具有 AmazonEC2FullAccess、AmazonS3FullAccess 和 CloudWatchLogsReadOnlyAccess 权限的 developer-group 中 * 审计人员用户被置于具有 AmazonEC2ReadOnlyAccess、AmazonS3ReadOnlyAccess、AWSCloudTrail_ReadOnlyAccess、CloudWatchReadOnlyAccess 和 IAMReadOnlyAccess 权限的 auditor-group 中。 ## 步骤 3 — 启用 MFA * 管理员用户被配置为在登录时使用 google authenticator 执行 MFA。管理员用户需要输入其密码（您所知道的信息）以及安装在其移动设备上的 google authenticator 生成的 6 位数字 PIN 码（您所拥有的物品）才能通过 AWS 云的身份验证。 ## 步骤 4 — 创建 IAM 角色 ### 目标 创建 IAM 角色以提供对 AWS 资源的临时、基于角色的访问，而无需依赖长期凭证。IAM 角色通过允许仅在需要时承担权限来提高安全性，并且通常被需要临时提升访问权限的 AWS 服务、应用程序和用户使用。 ### 为什么？ 与 IAM 用户不同，IAM 角色没有永久凭证。相反，它们是临时承担的，这减少了长期访问密钥的暴露并支持最小权限原则。 创建了三个 IAM 角色来代表常见的组织职责： | IAM 角色 | 用途 | |----------|---------| | **InfrastructureAdminRole** | 为基础架构管理任务提供管理访问权限。 | | **ApplicationDeveloperRole** | 允许开发人员部署和管理应用程序资源，同时限制对安全敏感服务的访问。 | | **SecurityAuditorRole** | 为安全审查、合规审计和监控活动提供只读访问。 | ### 实施过程 - 创建了 **InfrastructureAdminRole**。 - 附加了 **AdministratorAccess** 策略。 - 创建了 **ApplicationDeveloperRole**。 - 附加了 Amazon EC2、Amazon S3 和 Amazon CloudWatch Logs 的权限。 - 创建了 **SecurityAuditorRole**。 - 附加了针对 IAM、Amazon EC2、Amazon S3、AWS CloudTrail 和 Amazon CloudWatch 的只读策略。 ### 截图 ### 安全考虑 - IAM 角色提供临时凭证而不是永久访问密钥。 - 基于角色的权限减少了直接为单个用户分配过多权限的需要。 - 分离管理、开发和审计角色支持最小权限原则和职责分离。 - 在生产环境中，尽可能首选 IAM 角色而不是长期的 IAM 用户凭证。 ## 步骤 5 — 测试权限 我将使用 IAM 作为平台来测试每个用户的权限。 * 管理员用户应该能够读取并对 IAM 进行更改，例如向开发人员用户添加 AdministratorAccess 权限。截图证明了管理员用户确实能够执行上述操作。 * 除非开发人员用户的工作职责明确要求，否则他们不应有权查看或管理 IAM 用户、组、角色或策略。 最后，审计人员用户应该能够查看 IAM，但不应能够管理系统，例如为自身添加 AdministratorAccess 权限。 ### 权限边界演示 该组织使用一个标准的 Developer IAM 组，该组提供对 Amazon EC2、Amazon S3 和 Amazon CloudWatch Logs 的访问权限。 为了演示权限边界的使用，创建了第二个 Developer 用户（Bob）并将其分配到同一个 Developer 组。但是，Bob 还被分配了一个权限边界，将其有效权限限制为仅能访问 Amazon EC2。 这种方法允许组织维护单个 Developer 组，同时将单个用户限制为其特定项目职责所需的权限。它演示了如何在不增加 IAM 组复杂性的情况下使用权限边界强制执行最小权限原则。 * John 应该只能访问 EC2 而不能访问 S3。 # 安全决策 在设计和实施此 IAM 解决方案期间，做出了以下安全决策，以符合 AWS 安全最佳实践和基本的云安全原则。 ## 为什么需要最小权限？ 通过仅授予每个用户执行其分配的职责所需的权限来实施最小权限原则。 - **Administrator** 被授予管理 AWS 环境的完全管理访问权限。 - **Developer** 仅被授予应用程序开发所需的 AWS 服务的访问权限，包括 Amazon EC2、Amazon S3 和 Amazon CloudWatch Logs。 - **Auditor** 被授予只读访问权限以审查配置、日志和资源，而没有修改它们的能力。 限制权限可以减少攻击面，限制凭证泄露的影响，并有助于防止对云资源的意外或未经授权的更改。 ## 为什么需要基于角色的访问控制（RBAC）？ 基于角色的访问控制（RBAC）通过根据工作职责将权限分配给 IAM 组，而不是直接将权限分配给单个用户，从而简化了权限管理。 创建了三个 IAM 组： - **Admin-Group** - **Developer-Group** - **Auditor-Group** 用户通过其组成员身份继承权限，随着组织的发展，这使得权限模型更易于管理、更加一致且更具可扩展性。 ## 为什么需要多因素认证（MFA）？ 启用多因素认证（MFA）是为了在密码之外提供额外的安全层。 即使用户的密码因网络钓鱼、凭证重用或暴力破解攻击而遭到泄露，MFA 也会在授予访问权限之前要求第二种形式的验证。 MFA 对于管理员等特权账户尤为重要，因为这些账户具有提升的权限，一旦遭到泄露，可能会对 AWS 环境产生重大影响。 ## 为什么需要权限边界？ 使用权限边界是为了演示组织如何在防止权限提升的同时安全地委派权限。 Developer IAM 组提供对 Amazon EC2、Amazon S3 和 Amazon CloudWatch Logs 的访问权限，以支持一般的开发活动。但是，将权限边界应用于特定开发人员，以将其有效权限限制为仅其分配的项目所需的权限。 这种方法允许组织维护一个标准的 Developer IAM 组，同时对单个用户强制执行最小权限，而无需创建多个专门的 IAM 组。它还可以防止用户获得超出权限边界定义限制的权限，即使将来附加了额外的 IAM 策略也是如此。 # 遇到的挑战 示例： 最初，了解 IAM 策略如何与 IAM 角色交互需要进行额外的测试。通过使用不同的用户账户验证权限，我对 AWS 授权行为有了更清晰的了解。 # 经验教训 该项目巩固了我对 AWS 身份与访问管理的理解，并突出了有效的访问控制如何降低云环境中的安全风险。 # 未来改进 未来的增强功能包括： - AWS IAM Identity Center - IAM Access Analyzer - ABAC - AWS Organizations SCPs - 自动化 IAM 审计 # 展示的技能 - AWS IAM - RBAC - IAM Policies - MFA - 最小权限 - 云安全 - 身份管理 # 参考 AWS IAM 文档 AWS 安全最佳实践 NIST 访问控制原则

标签：AWS, DPI, IAM, RBAC, 权限管理, 模型越狱, 零信任架构