设计对 AWS 资源的安全访问

看起来您只提供了来源链接，而没有贴出需要翻译的正文内容。请把要翻译的文本粘贴在这里，我就可以为您完成简体中文翻译。

考试指南：解决方案架构师 – 助理

🛡️ 领域 1 – 设计安全架构

📘 任务陈述 1.1

安全访问 意味着您能够清晰回答以下问题：

1. 谁 正在尝试访问 AWS？
2. 他们 被允许做什么？
3. 他们 被允许在哪里进行（哪个账户 / 哪些资源）？
4. 他们 如何证明自己是真正的身份（密码、MFA、联合身份）？
5. 访问 应该持续多长时间（临时 vs. 长期）？

此任务主要涉及 身份 + 权限 + 多账户设置。

Knowledge

1️⃣ 多账户的访问控制与管理

随着公司规模扩大，单一的 AWS 账户会变得混乱：

多账户策略 能帮助您：

• 隔离工作负载（dev / prod）
• 一致地应用安全规则
• 降低风险

常见模式

注意： SCP 不授予 权限。它们只设定账户/OU 中允许的最大操作。仍然需要 IAM 权限来实际授权任何操作。

2️⃣ AWS 联合访问与身份服务

IAM 与 IAM Identity Center

与其为每位员工创建一个 AWS 用户名，许多组织采用 联合 方式，让用户使用已有的企业登录凭证进行登录。

简单对比

推荐： 对人使用 角色 + 联合，避免创建大量带长期凭证的 IAM 用户。

3️⃣ AWS 全球基础设施

区域与可用区

• 某些服务是 全局 的（例如 IAM、Route 53）——身份或权限概念适用于整个系统。
• 大多数资源是 区域 的——它们 存在 于特定的 Region 中。

您的访问规则可能会包含 允许的操作所在位置，例如：

• “仅允许在 eu‑west-1 部署”
• “拒绝在未批准的 Region 之外创建资源”

4️⃣ AWS 安全最佳实践

最小权限原则

最小权限意味着：

1. 除非必要，勿授予 “admin” 权限。
2. 仅授予完成工作所需的操作。
3. 限制对特定资源的访问——尽量避免使用 Resource: "*"。

示例

*如果看到类似 Action: "*" 的宽泛权限，最佳答案通常是 更细化的权限 + 条件。

5️⃣ AWS 共享责任模型

安全是共享的：
AWS 负责保护云平台；您负责保护放入云中的内容。

技能

A – 对 IAM 用户和根用户应用最佳实践

多因素身份验证 (MFA)

• 根用户 是账户的主密钥。
• 为根用户启用 MFA，并且 绝不要在日常任务中使用根用户。
• 管理工作请使用角色或受控身份。

情景提示： 如果题目说明“根用户每天使用”，几乎总是需要：启用 MFA 并 停止日常使用根用户。

B – 设计灵活的授权模型（用户、组、角色、策略）

• 人员 → 通过 Identity Center / federation 登录 → 承担角色。
• 应用/服务 → 使用 角色（代码中不放长期访问密钥）。

C – 基于角色的访问控制 (RBAC) 策略

• 通过 承担角色 授予访问权限，而不是通过永久的管理员权限。

AWS STS（安全令牌服务）

• 发放 临时凭证 → 减少长期密钥泄露风险。
• 支持简洁的 跨账户访问。

跨账户访问

• 账户 A 的用户承担 账户 B 中的角色。
• 没有共享密码，也不在账户之间复制访问密钥。

D – 多账户安全策略

Control Tower 与服务控制策略 (SCP)

• 使用结构化的账户布局（例如 prod / dev / security）。
• 通过 SCP 在组织范围内应用防护栏，保持共享安全功能的隔离。

SCP 思维方式

有效权限 = IAM 允许 且 未被 SCP 阻止。

E – 确定资源策略的适用场景

某些 AWS 服务支持 基于资源的策略（例如 S3 桶策略、SNS 主题策略、SQS 队列策略）。在以下情况下使用它们：

• 在资源本身上 直接授予跨账户访问。
• 允许服务 代表你执行操作（例如 Lambda 调用 S3 桶）。
• 条件在资源层面比在 IAM 策略中更容易表达。

摘要

• 识别 谁、什么、在哪里、如何以及需要多长时间的访问权限。
• 利用 多账户设计、AWS Organizations 和 Control Tower 实现隔离和治理。
• 优先 使用联合身份 + 角色，而非长期 IAM 用户。
• 应用 最小权限原则、多因素认证 (MFA) 和服务控制策略 (SCP) 来强制防护措施。
• 使用 资源策略，在它们能够简化跨账户或服务间权限时。

将这些概念随时用于 Design Secure Architectures（设计安全架构）领域的 Solutions Architect – Associate（解决方案架构师 – 助理）考试。

基于资源的策略

定义： 策略是直接附加到资源的。

常见示例

• S3 存储桶
• SQS 队列
• SNS 主题
• KMS 密钥
• Lambda 函数

典型用法

• 跨账户访问存储桶、队列或主题
• 服务间权限
• 强制条件（例如，“仅限 HTTPS”）

Decision Table

何时使用 IAM 角色对目录服务进行联合

当满足以下情况时，联合是理想的选择：

• 用户已经拥有企业身份（Google Workspace、Okta、Azure AD、AD 等）
• 您希望实现轻松的入职和离职管理
• 您希望减少长期 IAM 用户的数量

速查表

Recap Checklist ✅

If you can explain these ideas in simple terms, you are well‑prepared for Task Statement 1.1:

1. 根用户已启用 MFA 保护且不用于日常工作
2. 更倾向使用 IAM 角色而非长期 IAM 用户
3. 实施最小权限原则：仅授予所需的操作，仅针对所需的资源
4. 多个 AWS 账户集中管理
5. 跨账户访问使用角色切换：临时凭证
6. 员工访问使用联合身份或 IAM Identity Center
7. 了解何时使用基于身份的策略与基于资源的策略

AWS 白皮书和官方文档

这些是 Task Statement 1.1 背后的 主要 AWS 文档。
您无需全部记住它们；只需用来了解 为什么 AWS 安全会以这种方式工作。

核心白皮书

• AWS Well‑Architected Framework – Security Pillar – 安全访问设计的原则（最小权限、身份管理、治理）。
• IAM Best Practices – 用户、角色、组、策略；为何角色和临时凭证是首选。
• AWS Shared Responsibility Model – AWS 负责保护的部分与您必须自行保护的部分。

身份与联合参考

• IAM User Guide – 深入了解策略、角色、权限评估、策略冲突。
• IAM Identity Center (AWS SSO) Documentation – 大规模员工访问管理。
• AWS Security Token Service (STS) Documentation – 临时凭证与角色扮演（跨账户访问的关键）。

多账户与治理参考

• AWS Organizations User Guide – 组织单元（OU）和账户结构（对 SCP 行为至关重要）。
• Service Control Policies (SCPs) Documentation – SCP 如何限制权限（对“即使管理员也不能……”场景的重要性）。
• AWS Control Tower Overview – 可视化标准化、安全的多账户设置（通常在大型组织或治理问题中被暗示）。