AWS-安全秘籍-全-

AWS 安全秘籍（全）

原文：annas-archive.org/md5/d3b64380faef86adc6afd7f2257d6ce3

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

《AWS 安全食谱》第二版讨论了安全顾问在确保其基础设施安全时所面临的最常见问题的实际解决方案。本书探讨了各种 AWS 服务和功能，这些服务和功能有助于实现安全模型和概念，例如机密性、完整性和可用性（CIA）三元组，认证、授权和账务（AAA）三元组，以及不可否认性。本书首先帮助您熟悉 AWS 的基本安全功能，如身份与访问管理（IAM）、账户别名和计费警报，然后深入探讨访问管理、密钥管理、数据安全、网络安全、Web 安全、监控、合规性、先进的身份管理以及其他安全服务和实践。在全书中，您将遇到诸如 IAM、AWS Organizations、IAM 身份中心、密钥管理服务（KMS）、CloudHSM、S3、虚拟私有云（VPC）、CloudWatch、CloudTrail、Config、GuardDuty、Macie、Inspector、安全中心、Cognito、资源访问管理器、Systems Manager 参数存储、Secrets Manager、Trusted Advisor 和 AWS Artifact 等 AWS 安全服务。每一章都侧重于重要的安全领域，并逐步推进到云安全最佳实践，并集成额外的安全服务。到本书结束时，您将精通与确保 AWS 部署相关的所有技术，并为 AWS 认证安全专家认证做好准备。

本书的适用对象

如果您是 IT 安全专业人员、云安全架构师或云应用开发人员，负责安全相关的角色，并希望使用 AWS 基础设施进行安全的应用部署，那么本书适合您。本书也将对有意参加 AWS 认证安全专家认证的人有帮助。

本书内容

第一章，设置 AWS 账户和组织，介绍了 AWS 安全性的重要功能，从设置 IAM 服务、账户别名和计费警报开始。它还涵盖了使用 AWS Organizations 进行多账户管理，并通过 IAM 身份中心进行用户管理，实现集中式身份创建和访问管理。完成本章内容后，您将为本书中讨论的企业级 AWS 安全管理概念做好准备。

第二章，使用 IAM 策略和角色进行访问管理，展示了在 AWS 中进行安全访问管理的重要性，用于控制谁能访问资源以及他们可以执行的操作，确保环境安全合规。本章涵盖了 IAM 策略、IAM 角色和各种策略类型，提供了详细的创建和管理策略、设置权限边界以及实施跨账户和跨服务访问的方法。这些知识对于建立跨 AWS 基础设施的强大和可扩展的安全姿态至关重要。

第三章，使用 KMS 和 CloudHSM 进行密钥管理，讲解了如何通过加密将明文转换为不可读的密文，以保护信息免受未经授权的访问，解密则反转此过程。使用 AWS KMS 和 CloudHSM，本章涵盖了创建、管理和保护加密密钥，支持对称和非对称加密。包括密钥创建、密钥轮换、权限管理和跨账户密钥共享的方法，以确保 AWS 中数据的强大保护。

第四章，使用策略和技术在 S3 上保护数据，专注于保护 Amazon S3，AWS 的对象存储服务，使用独特的键值系统存储数据。基于 第二章 的 IAM 策略，我们将探讨使用 访问控制列表（ACLs）、存储桶策略、预签名 URL、加密、版本控制和复制来保护 S3 数据。包括创建存储桶策略、使用 ACLs、生成预签名 URL、通过版本控制保护文件以及加密 S3 数据的方法。

第五章，网络与 EC2 安全与 VPC，涵盖了 Amazon VPC，这是 AWS 云中创建私有隔离网络的关键组件。用户可以完全控制其虚拟网络，允许自定义 IP 范围、子网、路由表和网关。本章包括设置 VPC 资源、创建子网、启动 EC2 实例、配置安全组和 NACLs、通过网关端点连接到 S3、使用 VPC 流日志以及设置 NAT 网关的方法。

第六章，使用证书、CDN 和防火墙进行 Web 安全，强调通过证书、内容交付网络（CDNs）和防火墙实现 Web 安全。涵盖了使用 X.509 证书进行 TLS 加密、利用负载均衡器进行有效的流量分发和 TLS 终止，以及利用 CDN 提升加载速度和安全性。此外，探讨了 AWS 内部防火墙的集成，以定义和执行网络安全边界。这些组件的实际实施提供了构建安全、可扩展 Web 基础设施的知识。

第七章，通过 CloudWatch、CloudTrail 和 Config 进行监控，探讨了通过 Amazon CloudWatch、AWS CloudTrail 和 AWS Config 进行安全监控和审计的作用。CloudWatch 负责日志记录、监控和警报；CloudTrail 记录 AWS API 调用；AWS Config 根据规则评估配置。本章还介绍了使用 简单通知服务（SNS）进行通知，并提供了设置这些服务和查询日志的实际操作示例。

第八章，遵守 GuardDuty、Macie、Inspector 和 Analyzer，详细介绍了定期合规检查和通知对于维护账户安全的重要性。本章介绍了 AWS 服务，如 Amazon GuardDuty、Amazon Macie 和 Amazon Inspector，这些服务利用机器学习和先进算法进行合规性监控。内容涵盖了设置和使用这些服务的实际步骤，以及 AWS 安全中心和 IAM 分析器，以进行全面的安全管理。

第九章，高级身份与目录管理，建立在前几章关于 IAM 的基础之上。它探讨了使用 Amazon Cognito 和 AWS 目录服务进行高级用户身份和目录管理。内容涵盖了 Cognito 的用户池用于用户注册和认证、身份池用于 AWS 服务访问，以及目录解决方案，如 AWS Simple AD 和与 Microsoft Entra ID 的集成。本章提供了实际的操作示例，但部分内容可能需要额外的 Microsoft 产品和 AWS 服务的知识。

第十章，AWS 安全的附加服务与实践，探讨了额外的 AWS 安全服务和实践，以进一步保障您的 AWS 基础设施安全。它介绍了 AWS 资源访问管理器、系统管理器参数存储、Secrets Manager、Trusted Advisor 和 AWS Artifact，以及 Amazon Machine Images（AMIs）和 AWS Marketplace 安全产品的使用。每项服务都有实际操作示例，并附有进一步学习资源以供更深层次的探索。

为了最大化地利用本书

要练习本书中的示例，您需要一个有效的 AWS 账户。您应该已经具备一些关于 AWS 服务的基础知识，如 IAM、S3、EC2 和 VPC。此外，了解云计算、计算机网络和 IT 安全的基本知识，可以帮助您更快地掌握本书内容。

如果您使用的是本书的数字版本，我们建议您自己输入代码，或者通过 GitHub 仓库访问代码（链接将在下一节提供）。这样做将帮助您避免与复制和粘贴代码相关的潜在错误。

下载示例代码文件

你可以从 GitHub 下载本书的示例代码文件，链接为 github.com/PacktPublishing/AWS-Security-Cookbook-Second-Edition。如果代码有更新，它将在 GitHub 仓库中更新。

我们还提供了其他来自我们丰富书籍和视频目录的代码包，访问 github.com/PacktPublishing/ 了解更多信息。

实践中的代码

本书的 实践中的代码 视频可以在 bit.ly/2OQfDum 观看。

使用的约定

本书中使用了多种文本约定。

文本中的代码：表示文本中的代码单词、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟网址、用户输入和 Twitter 句柄。以下是一个示例：“创建一个存储桶策略，允许我们的awsseccb_user1 用户访问，并将其保存为bucket-policy-allow-list.json：”

代码块的设置如下：

 "Principal": {
  "AWS": [
    "arn:aws:iam::873506153865:root",
    "arn:aws:iam::671100771477:root"
  ]
}

任何命令行输入或输出如下所示：

 aws sts assume-role --role-arn ROLE_ARN --role-session-name SESSION_NAME --profile AWSSecCBUser1S --external-id awssecb-cust-0819

粗体：表示新术语、重要单词或屏幕上看到的单词。例如，菜单或对话框中的单词会像这样出现在文本中。以下是一个示例：“对于NAT 网关（$），选择1 个可用区，对于VPC 端点，选择S3 网关，对于DNS 选项，选择启用 DNS 主机名和启用 DNS 解析。”

提示或重要注意事项

以这种方式显示。

各部分

本书中有几个经常出现的标题（准备工作、如何做...、它是如何工作的...、更多内容... 和 另见）。

为了清晰地说明如何完成一个食谱，请按如下方式使用这些部分：

准备工作

本节告诉你在食谱中可以期待什么，并描述如何设置任何软件或完成食谱所需的初步设置。

如何操作…

本节包含按照食谱所需的步骤。

它是如何工作的…

本节通常包含对前一节内容的详细解释。

更多内容…

本节包含与食谱相关的附加信息，旨在帮助你更深入理解该食谱。

另见

本节提供了有用的链接，指向与食谱相关的其他有用信息。

联系我们

我们欢迎读者的反馈。

一般反馈：如果你对本书的任何部分有疑问，请通过电子邮件联系我们，邮件地址为 customercare@packtpub.com，并在邮件主题中提及书名。

勘误：虽然我们已尽最大努力确保内容的准确性，但错误仍然可能发生。如果你在本书中发现错误，我们将非常感激你向我们报告此问题。请访问 www.packtpub.com/support/errata，选择你的书籍，点击“勘误提交表格”链接并输入详细信息。

盗版：如果您在互联网上发现任何我们作品的非法复制品，请提供该材料的所在地址或网站名称，我们将不胜感激。请通过版权@packtpub.com 与我们联系，并附上链接。

如果您有兴趣成为作者：如果您在某个领域拥有专业知识并且有意编写或参与书籍创作，请访问authors.packtpub.com。

分享您的想法

阅读完AWS Security Cookbook后，我们很想听听您的想法！请点击这里直接访问亚马逊的书籍评价页面并分享您的反馈。

您的评价对我们以及技术社区非常重要，能够帮助我们确保提供卓越的优质内容。

下载本书的免费 PDF 副本

感谢您购买本书！

您喜欢随时随地阅读，但又无法随身携带纸质书籍吗？

您的电子书购买是否无法在您选择的设备上使用？

不用担心，现在购买每本 Packt 书籍，您将免费获得该书的无 DRM 版本 PDF。

随时随地、在任何设备上阅读。可以直接从您最喜欢的技术书籍中搜索、复制并粘贴代码到您的应用程序中。

福利不仅仅这些，您还可以获得独家折扣、新闻通讯以及每日发送到您邮箱的精彩免费内容。

按照以下简单步骤即可获得福利：

1. 扫描二维码或访问以下链接

packt.link/free-ebook/9781835081891

1. 提交您的购买凭证

2. 就是这样！我们将直接通过电子邮件发送您的免费 PDF 以及其他福利。

第一章：设置 AWS 账户和组织

应用程序或平台的安全性通常由保密性、完整性、可用性、身份验证、授权、审计和不可否认性等特性来定义。这些特性被分为 保密性、完整性和可用性（CIA）三元组和 身份验证、授权和审计（AAA）三元组。对这些安全特性有深入的理解将有助于我们更好地理解和实施本书中详细介绍的 AWS 安全概念。

在本章中，我们将首先了解如何为新的 AWS 账户设置 身份与访问管理（IAM）服务，并设置 账户别名 和 账单警报。然后，我们将学习如何设置 AWS 组织 服务，该服务允许我们通过一个 管理账户 创建和管理多个 AWS 账户。我们还将了解用户管理和使用 AWS IAM 身份中心（前身为 AWS SSO）的 单点登录（SSO），该服务集中管理 AWS 账户和应用程序中的身份创建与访问管理，适用于各种规模和类型的组织。

本章内容略长于本书其他章节，因为它为后续章节奠定了基础。我们可以跳过本章中关于设置 AWS 组织和 IAM 身份中心的第二和第三个食谱，并在其他章节中独立执行大部分食谱。但如果我们的目标是在企业环境中工作，那么在继续阅读本书的其他部分之前，最好完成本章中的所有食谱。

本章包括以下食谱：

• 设置 IAM、账户别名和账单警报

• 使用 AWS 组织进行多账户管理

• 用户管理和使用 IAM 身份中心进行 SSO

技术要求

在深入本章的食谱之前，我们需要确保具备以下知识和要求：

• AWS 账户：建议为本章使用一个新的 AWS 账户。我们可以在 aws.amazon.com 上注册一个免费层账户。

• 权限：我们需要以根用户身份操作，或者拥有管理员权限，才能配置 IAM、AWS 组织和 IAM 身份中心。

• 熟悉 AWS：对 AWS 管理控制台以及 IAM 和 S3 等 AWS 服务有一定了解将对我们有帮助。

• 互联网连接：由于 AWS 是基于云的，因此稳定的互联网连接对于访问和管理 AWS 服务至关重要。

• AWS 命令行接口（CLI）：要执行 AWS CLI 命令，我们需要 AWS CLI V2。两种推荐的使用 AWS CLI V2 的方法是通过 AWS IAM 身份中心在本地或虚拟机上进行设置，或使用AWS CloudShell。我们将在使用 IAM 身份中心进行用户管理和 SSO教程中学习如何使用 IAM 身份中心设置 AWS CLI V2。

重要提示

我们还可以使用传统的访问密钥来配置 AWS CLI。然而，IAM 身份中心和 CloudShell 都使用基于会话的短期凭证，从而减少了与传统长期访问密钥相关的风险。AWS CloudShell 提供了浏览器集成的 shell，直接嵌入 AWS 管理控制台，便于随时进行操作，无需本地设置。然而，CloudShell 可能并非在所有区域都可用。

本书的代码文件可在 github.com/PacktPublishing/AWS-Security-Cookbook-Second-Edition 获取。本章的代码文件可在 github.com/PacktPublishing/AWS-Security-Cookbook-Second-Edition/tree/main/Chapter01 获取。

设置 IAM、账户别名和计费警报

IAM 是 AWS 中用于管理访问 AWS 资源的主要服务。设置 AWS 账户后，建议进行一些基本的 IAM 配置，以增强账户的安全性，例如使用多重身份验证（MFA）保护根账户。MFA 是一种安全机制，要求用户提供两个或更多的验证因素才能访问资源，如用户名和密码，以及发送到手机的验证码。IAM 提供了一个检查清单来指导这些初步活动。

虽然不在 AWS 检查清单中，但建议在新账户中设置账户别名并创建计费警报。账户别名是我们可以为 AWS 账户创建的一个唯一标识符，用来代替账户登录 URL 中默认的 12 位账户 ID。创建账户别名通过提供个性化和易记的登录 URL 来提升用户体验，增加安全性，因为它能够隐藏实际的账户号码，同时通过将我们组织的名称纳入 AWS 登录流程中，增强品牌一致性。

在新 AWS 账户中设置计费警报的一个主要优势是能够有效监控和管理成本。当账户支出超过预设的阈值时，它会提醒我们，从而帮助防止意外费用并保持预算控制。

准备工作

我们需要一个新创建的 AWS 账户来完成本教程中的所有步骤。如果账户不是新的，我们可以按照本教程进行验证，检查配置是否正确，并配置缺失的内容。

要在此方案中使用虚拟 MFA 设备设置 MFA，我们需要在手机上安装认证器应用，Google Authenticator 是一个流行的认证器应用，我们可以使用。我们也可以使用YubiKey Universal 2nd Factor (U2F) 安全密钥，任何U2F 兼容设备，或硬件 MFA 设备。U2F 是一种认证标准，旨在仅通过安全密钥访问在线服务，无需任何驱动程序或客户端软件。

如何操作...

首先，我们将为新的 AWS 账户设置 IAM。然后，我们将设置一个账户别名以改善用户体验，并设置账单警报以防止非计划的使用和账单。

为 AWS 账户设置 IAM

我们可以按照以下步骤为新的 AWS 账户设置 IAM：

1. 使用根用户邮箱凭证登录 AWS 账户，并从 IAM 仪表板内执行以下步骤。对于一个新的 AWS 账户，IAM 仪表板应该如下所示：

图 1.1 – 新账户的 IAM 仪表板

1. 点击添加 MFA，位于安全建议下。

2. 如果没有被重定向到分配 MFA标签，请手动转到分配 MFA标签。

3. 输入一个有意义的 MFA 设备名称，帮助我们识别该设备，然后选择认证器应用，如以下图所示。如果我们设置了不同的选项，如准备工作部分所讨论的那样，我们可以在此处选择该选项，而不是认证器应用选项。

图 1.2 – 选择 MFA 设备

1. 向下滚动并点击下一步。AWS 现在将提供一个二维码。

重要说明

我们可以将二维码图像保存在安全的地方，以便在不访问当前认证器应用设置的情况下重新配置认证器应用，例如，如果当前的手机停止工作。或者，我们也可以在发生此类事件时联系 AWS 支持，他们可以帮助我们重置认证器应用的配置。

1. 使用安装在手机上的认证器应用（例如 Google Authenticator）扫描二维码，并输入两个成功的令牌密钥以激活它。

   启用 MFA 后，我们需要提供来自此应用的令牌，以及用户名和密码，才能登录 AWS 控制台。

2. 返回 IAM 仪表板，确保我们在图 1.1中看到的安全建议中的所有勾选项现在都是绿色的。

图 1.3 – IAM 仪表板上的安全建议

一旦所有安全建议都变为绿色，表示符合要求，AWS 可能不会再显示这些建议。

接下来，我们将设置账户别名和账单警报。即使这些内容不在安全建议中，也建议在新 AWS 账户上进行此操作。

设置账户别名

我们可以在 IAM 仪表板中按如下方式配置账户别名：

1. 在 IAM 页面中，在账户别名下，点击创建以打开创建别名弹出页面。

图 1.4 – AWS 账户详情

1. 在创建别名弹出页面中，在首选别名下输入一个独特且有意义的别名，并点击创建别名。

   这将为我们的账户创建一个账户别名。账户别名将替换此账户中 IAM 用户的登录 URL中的账户 ID，如图 1.4所示，并使我们的 IAM 用户更容易记住登录 URL。请注意，IAM 用户仍然可以使用默认登录 URL 和我们在图 1.4中看到的账户 ID 进行登录。

现在，我们也来创建一个计费警报。

创建计费警报

在本节中，我们将设置一个计费警报，以便在超出设定的限制时通知我们：

1. 登录到 AWS 管理控制台，点击屏幕右上角账户名称旁边的下拉菜单，选择计费和成本管理。

图 1.5 – 账户下拉菜单

1. 在计费和成本管理主页页面，点击左侧边栏中的计费偏好设置。

2. 点击编辑，在警报偏好设置窗格中。

3. 在警报偏好设置页面，勾选接收 CloudWatch 计费警报复选框。如果你正在使用免费的层级账户，你还可以勾选接收 AWS 免费层警报，并在接收警报的附加电子邮件地址 - 可选文本框中提供一个附加的电子邮件地址来接收警报。点击更新以保存你的偏好设置。

4. 进入 CloudWatch 服务仪表板，将区域设置为美国东部（北弗吉尼亚），在左侧展开警报，点击所有警报。在本书写作时，AWS 仅允许我们在将区域设置为美国东部（北弗吉尼亚）时创建计费警报。我们将在本书后面的章节中进一步了解 CloudWatch 服务。

5. 点击创建警报，在创建警报页面，点击选择指标。

6. 在浏览标签中，点击计费，然后点击总估计费用。

7. 选择EstimatedCharges指标的复选框，如下图所示，然后点击选择指标。

图 1.6 – 配置指标

1. 保持指标名称为EstimatedCharges，货币为美元（USD）。对于统计，选择最大值，对于周期，选择6 小时。

2. 在条件下，选择阈值类型为静态，在每当 EstimatedCharges 为...中选择大于，并在比...大中定义触发报警的值。还可以展开其他配置。在报警的数据点中，指定1中的1，并在缺失数据处理中选择将缺失数据视为缺失。

图 1.7 – 配置指标的条件 - 条件

1. 点击下一步进入通知页面。在通知页面中，选择报警，然后选择创建新主题，为主题提供一个名称和一个接收通知的电子邮件地址，如下图所示，然后点击创建主题。

图 1.8 – 配置指标的通知 - 通知

我们创建了一个新的简单通知服务（SNS）主题来发送电子邮件。我们也可以选择一个现有的 SNS 主题，而不是创建一个新的。

1. 点击下一步，在名称和描述下，输入报警的名称。

2. 点击下一步进入预览和创建页面。点击创建报警。报警应该已经成功创建。

请注意，Amazon SNS 在订阅主题确认之前不会向端点发送消息。

它是如何工作的…

IAM 是 AWS 服务，帮助我们管理和验证 AWS 内用户的身份（认证）并验证其对 AWS 服务的权限（授权）。IAM 是一个全球服务，与区域无关。IAM 有四个核心概念：

• 用户：可以在 IAM 中创建用户并赋予其访问 AWS 资源所需的权限。

• 组：用户可以被添加到组中，然后可以将权限授予组，而不是单独的用户。这是推荐的最佳实践。

• 策略：策略是 JSON 文档，用于定义用户或组的权限。

• 角色：角色通常用于赋予用户临时权限访问 AWS 服务。例如，我们可以将具有 S3 权限的角色附加到 EC2 服务。角色也用于角色切换，正如我们在第二章中看到的那样。

根用户账户是我们使用主电子邮件登录的账户。它对我们账户中的所有内容都有访问权限。IAM 仪表板提供了一组检查项，以确保我们的根账户安全。IAM 检查表中的第一项检查我们是否为根账户启用了 MFA。MFA 将强制执行额外的身份验证层，除了用户名和密码，还需要使用虚拟或硬件 MFA 设备的令牌。

清单中的第二项检查我们是否有可用于程序访问的根账户活动访问密钥。最佳实践是使用根账户创建其他账户并进行必要的配置，然后使用这些账户进行日常活动。正如我们在本章的进一步食谱中将看到的，我们可以结合使用 IAM 身份中心和 AWS Organizations 服务，以便更好地管理组织中 AWS 账户的用户身份。

尽管账户别名和账单报警不在 IAM 安全推荐清单中，我们仍然设置了它们。正如在食谱介绍中所看到的，创建 AWS 账户别名可以提升用户体验、增加安全性，并确保品牌一致性。账单报警将在我们超过设定的限制时触发警报，并提醒我们。这是一个良好的做法，能够避免意外使用和未计划的开销。

还有更多...

让我们快速回顾一些与 IAM 和安全相关的重要概念：

• 身份验证是通过用户名和密码，或访问密钥与秘密访问密钥等凭证来验证用户身份的过程。AWS 中用于身份验证的主要访问凭证有两种：

  • 访问密钥 ID 和秘密访问密钥：这些用于程序化访问，并与 AWS API、CLI、SDK 及任何开发工具一起使用。

  • 用户名和密码：这些用于管理控制台访问。

• 授权是检查用户是否具有执行某项操作的权限的过程，通常通过策略来定义。我们将在第二章中详细了解 IAM 策略。

• 机密性确保从源发送的数据在传输过程中不被其他人读取。这可以通过加密技术来实现。

• 数据完整性确保数据来自正确的人，并且在传输过程中未被篡改。这可以通过加密技术来实现。

• 可用性确保在需要时服务可以正常使用。

• 会计帮助我们在发生安全事件时识别责任方。

• 不可否认性防止用户否认某项活动。加密技术在这里也能帮助我们。

• AWS 共享责任模型定义了 AWS 和其客户在 AWS 云中保护解决方案的责任。AWS 负责云的安全性，包括保护支撑所有 AWS 云服务的基础设施。这包括硬件、软件、网络和设施，确保 AWS 云服务的正常运行。另一方面，客户负责云中的安全性。这项责任包括管理在云中部署的工作负载、使用的客户操作系统，以及网络、主机、IAM 和存储资源的配置，以便进行数据管理和业务沟通。还包括根据所使用的云抽象（例如基础设施即服务）定期更新和修补云资源上的软件。

• 第三方审计人员定期评估 AWS IAM 是否符合一系列标准，包括服务组织控制（SOC）、支付卡行业数据安全标准（PCI DSS）、联邦风险与授权管理程序（FedRAMP）和国际标准化组织（ISO）等标准。

更多关于 IAM 用户和用户组的信息

在本教程中，我们没有创建 IAM 用户或用户组，因为现在推荐使用 IAM 身份中心用户，而不是 IAM 用户。但是，如果需要，我们可以从 IAM 仪表板的左侧边栏创建用户和用户组。

IAM 用户的主要问题在于它们与长期凭证（如访问密钥）关联，如果没有正确管理，这可能会带来安全风险。以下是根据 AWS 提供的常见 AWS 访问密钥使用场景，以及更安全的替代方案推荐：

替代方案	使用案例	推荐
CLI	通过 AWS CLI 访问 AWS 账户。	在这种情况下，按照以下步骤操作：

• 使用AWS CloudShell，这是一种集成在浏览器中的命令行界面（CLI），用于执行命令。

• 选择 AWS CLI V2 并通过IAM 身份中心中的用户设置身份验证；我们将在后续详细探讨 IAM 身份中心。

本地代码	从本地开发环境访问 AWS 账户。	使用配备 AWS 工具包的集成开发环境（IDE），它通过 IAM 身份中心促进身份验证。
在 AWS 计算服务 上运行的应用	在 AWS 计算服务（如 Amazon EC2、Amazon ECS 或 AWS Lambda）上管理应用代码。	为计算资源（如 EC2 实例或 Lambda 函数）分配 IAM 角色，确保为访问自动提供临时凭证。
第三方服务	用于启用管理或与 AWS 资源交互的第三方应用程序或服务。	作为标准，选择通过 IAM 角色使用临时安全凭证，避免创建长期凭证（如访问密钥）。避免生成 AWS 账户根用户的访问密钥。
在 AWS 外运行的应用程序	管理 AWS 计算服务上的应用程序代码，如 Amazon EC2、Amazon ECS 或 AWS Lambda。	尽管在这种用例中使用访问密钥是可以接受的，但请确保执行以下操作：

• 避免将访问密钥以明文形式存储在代码库中或直接嵌入代码中。

• 停用或删除冗余的访问密钥。

• 实施最小权限原则。

• 定期轮换访问密钥。

表 1.1 – AWS 访问密钥的使用案例（按 AWS 分类）

上述建议旨在减少安全漏洞的潜在风险。

另请参见

• 我们可以在www.cloudericks.com/blog/getting-started-with-aws-iam了解更多关于 IAM 及其安全工具和功能的信息，例如 IAM 分析器、IAM 访问顾问和 IAM 凭证报告。

• 我们在本配方中了解了账单警报。我们可以通过www.cloudericks.com/blog/getting-started-with-aws-budgets了解 AWS Budgets 并理解它与账单警报的区别。

• 我们在本配方中简要介绍了 Amazon SNS。要了解更多关于 SNS 的信息，可以参考www.cloudericks.com/blog/getting-started-with-amazon-sns-service。

• 本书不涉及超出安全领域的 AWS 基础知识。我们可以在www.cloudericks.com/blog/getting-started-with-aws-cloud了解云计算和 AWS 基础知识。

• 在aws.amazon.com/compliance/shared-responsibility-model阅读更多关于 AWS 共享责任模型的信息。

• 在docs.aws.amazon.com/IAM/latest/UserGuide/iam-compliance-validation.html阅读更多关于 AWS IAM 的合规性验证。

使用 AWS Organizations 进行多账户管理

组织通常有多个基于使用情况（如生产、开发、测试等）分类的 AWS 账户。AWS Organizations 服务帮助我们集中管理所有 AWS 账户，其组织单元（OU）功能帮助我们将 AWS 账户按使用情况分层管理。在本教程中，我们将学习如何创建 AWS 组织和 OU，并将 AWS 账户添加到 OU 中。我们将在 AWS 管理控制台中创建 AWS 组织，但将从管理控制台和 CLI 中同时创建 OU 并添加账户。

准备工作

我们需要一个不属于任何 AWS 组织的有效 AWS 账户，才能完成本教程中的所有步骤。

对于我们使用 CLI 命令的部分，我们需要配置 AWS CLI V2，具体方法可参考技术 要求部分。

如何操作...

我们将首先创建一个 AWS 组织，然后在该 AWS 组织中创建 OU 和 AWS 账户。

从管理控制台创建一个 AWS 组织

首先，让我们按如下方式创建一个 AWS 组织：

1. 以根用户或具有管理员权限的用户身份登录 AWS 管理控制台，并转到AWS Organizations服务控制台。

2. 点击创建组织。它将创建一个组织，并将我们引导到AWS 账户页面，该页面应该如下所示：

图 1.9 – AWS Organizations 中的账户

如果我们检查同一页面上的左侧边栏，我们可以看到组织 ID，如下图所示：

图 1.10 – AWS Organizations 侧边栏

接下来，我们将在根 OU 下创建一个 OU。

从管理控制台创建 OU 和账户

要在根 OU 下创建一个 OU，我们可以按照以下步骤进行：

1. 在AWS Organizations服务控制台页面，转到AWS 账户页面。

2. 选择Root OU，然后在操作菜单中，选择创建新组织单元。

图 1.11 – 创建新的组织单元

1. 在下一个屏幕上，输入Sandbox作为组织单元名称，然后点击创建组织单元。

我们现在可以创建一个 AWS 账户并将其移动到Sandbox OU，如下所示：

1. 在AWS Organizations服务控制台页面，转到AWS 账户页面。

2. 点击添加 AWS 账户。

3. 选择创建 AWS 账户，并为AWS 账户名称提供awsseccb-sandbox-1值。对于账户所有者的电子邮件地址，提供一个你可以访问的电子邮件地址。为IAM 角色名称提供OrganizationAccountAccessRole值。

图 1.12 – 向组织中添加账户

1. 向下滚动并点击创建AWS 账户。

   我们应该立即看到一个显示AWS 正在创建 1 个账户的屏幕。账户创建可能需要一些时间。

2. 一旦账户创建完成，在组织中的AWS 账户页面中，选择新创建的账户。从操作下拉菜单中选择移动。

图 1.13 – 选择账户并在 OU 之间移动

1. 在目标部分选择所需的 OU，然后点击移动AWS 账户。

图 1.14 – 选择目标 OU 以移动账户

新创建的账户现在应该属于所选的 OU。

从 CLI 创建 OU 和账户

在本节中，我们将通过 CLI 创建一个 OU 和账户。请记住，在执行 CLI 命令时，要用相关步骤中的 ID 替换我的 ID。命令也会与代码文件一起提供。此外，如果我们从 AWS CloudShell 执行命令，则无需指定 CLI 配置文件。让我们开始吧：

1. 使用create-organizational-unit子命令，在根 OU 下创建名为Workloads的 OU，使用我们的根 OU 的 ID：

   aws organizations create-organizational-unit --parent-id r-bim7 --name Workloads --profile awssecadmin
   

   这应该会给我们一个类似于以下内容的响应：

图 1.15 – create-organizational-unit 子命令的响应

1. 我们可以使用create-account子命令创建一个 AWS 账户：

   aws organizations create-account --email awsseccb_sandbox2@cloudericks.com --account-name awsseccb-sandbox-2 --profile awssecadmin
   

   这应该会给我们一个类似于以下内容的响应：

图 1.16 – create-account 子命令的响应

1. 我们可以使用describe-create-account-status子命令检查请求的状态，通过提供上一步收到的请求 ID：

   aws organizations describe-create-account-status --create-account-request-id car-6582b2c63be845ebaa474c9268cea8c1 --profile awssecadmin
   

   如果请求成功，我们应该会得到以下响应：

图 1.17 – describe-create-account-status 的响应

1. 我们可以通过提供在上一步中收到的账户 ID，使用list-parents子命令来验证账户是否在根 OU 下创建，并获取根 OU 的 ID：

   aws organizations list-parents --child-id 206722961012 --profile awssecadmin
   

   这应该会给我们一个类似于以下内容的响应：

图 1.18 – list-parents 子命令的响应

1. 使用move-account子命令，将我们的新账户从根 OU 移动到之前通过 CLI 创建的新的 OU，提供上一步的账户 ID、根 ID 和 OU ID：

   aws organizations move-account --account-id 206722961012 --source-parent-id r-bim7 --destination-parent-id ou-bim7-0s1nqy2w --profile awssecadmin
   

   该命令不会返回任何内容。

2. 使用list-parents子命令检查我们账户的父级，如S tep 4 中所做的那样。我们应该会得到一个响应，其中新 OU 作为父级：

图 1.19 – list-parents 子命令的响应

1. 我们可以使用 list-children 子命令列出根 OU 下的所有 OU，并将子类型设置为 ORGANIZATIONAL_UNIT：

   aws organizations list-children --parent-id r-bim7 --child-type ORGANIZATIONAL_UNIT --profile awssecadmin
   

   如果我们总共有两个 OU，假设我们在前面的示例中创建了一个，这应该会给我们类似以下的响应：

图 1.20 – list-children 子命令的响应

要获取 OU 的详细信息及其名称，我们可以使用 describe-organizational-unit 子命令，传入名为 organizational-unit-id 的单一参数，并传入其 ID。

工作原理...

从管理控制台中，我们创建了一个 AWS 组织，在其下创建了 OU，并将账户添加到这些 OU 下。默认情况下，会创建一个名为 Root 的 OU。用于创建组织的账户称为管理账户（以前称为 主账户），并且是在根 OU 下创建的。

我们只能从一个未加入任何组织的 AWS 账户启动创建新组织的操作。我们不能将另一个 AWS 账户后期变更为管理账户，因此，创建组织的账户需要谨慎选择。我们可以将账户移动到任何 OU，包括根 OU。我们也可以在一个 OU 内创建子 OU。

AWS Organizations 的委托管理员功能允许指定的 AWS 服务（如 AWS IAM 身份中心）将组织中的成员账户指定为管理员，以便在所有账户中管理该服务。这使得不同的团队可以使用单独的账户来管理 AWS 服务，这些账户是根据他们的角色和责任量身定制的。目前支持此功能的服务包括 AWS IAM 身份中心、AWS Config、AWS 防火墙管理器、Amazon GuardDuty、AWS IAM 访问分析器、Amazon Macie、AWS Security Hub、Amazon Detective、AWS 审计管理器、Amazon Inspector 和 AWS 系统管理器。

从 CLI 中，我们使用 create-account 子命令创建了一个 AWS 账户。此命令会立即返回请求 ID，并异步执行。我们可以使用 describe-create-account-status 子命令，通过提供请求 ID 来检查请求的状态。要检查账户是否已创建，我们可以查看 AWS CloudTrail 日志 中的 CreateAccountResult 事件。

create-account 子命令还接受其他参数，即 role-name 和 iam-user-access-to-billing。role-name 参数用于指定将在新成员账户中自动预配置的 IAM 角色名称。此角色为成员账户提供管理员权限，并信任管理账户。这意味着管理账户中的用户可以承担该角色，前提是管理账户的管理员允许这样做。默认值是 OrganizationAccountAccessRole。如果我们登录到子账户并检查 OrganizationAccountAccessRole 角色，我们会看到它附加了 Administrator Access 策略。如果我们检查 Trust relationships 部分，我们会看到我们的管理账户已被添加为受信任实体。现在，管理账户的管理员可以切换角色到子账户并获得管理员访问权限。对于非管理员用户来说，要承担子账户中的 OrganizationAccountAccessRole 角色并切换角色登录到子账户，用户应该被授予该角色的 AssumeRole 权限。

必须将 iam-user-access-to-billing 参数设置为 ALLOW，以便 IAM 用户访问账户账单信息。如果设置为 DENY，只有根用户才能访问账户账单信息。默认值是 ALLOW。我们还创建了一个 OU，并将账户移至该 OU。在示例中，我们使用了 list-children 子命令与 ORGANIZATIONAL_UNIT 子类型来列出根下的所有 OU。我们还可以将 child-type 设置为 ACCOUNT 来列出所有账户。

还有更多内容...

让我们快速浏览一下关于 AWS Organizations 服务的一些重要细节：

• AWS Organizations 服务在所有区域均支持；然而，终端节点位于美国东部（弗吉尼亚北部）用于商业组织，AWS GovCloud（美国西部）用于 AWS GovCloud（美国）组织。

• AWS Organizations 服务是一个全球性服务。我们不需要选择或指定任何区域来创建组织实体。

• 使用 AWS Organizations 不会产生额外费用。

• 我们可以在一个 AWS Organization 中管理的账户数量是有变化的。我们可以请求 AWS 支持来增加这个限制。

• 一个账户一次只能属于一个组织，而且在一个组织内，一个账户一次只能属于一个 OU。

• 我们可以将 OU 和账户嵌套最多五层（包括根）。

• 我们可以使用服务控制策略（SCPs）来限制 AWS 服务操作，仅对根账户、IAM 用户和组织中账户的 IAM 角色有效。

• SCPs 只能拒绝访问；不能允许访问。

• 当 权限边界（IAM 特性）和 SCP 同时存在时，只有在权限边界、SCP 和基于身份的策略都允许该操作时，操作才会被允许。

• 当前可以与 AWS Organizations 集成的受支持服务包括 AWS 账户管理、AWS 应用迁移服务 (MGN)、AWS Artifact、AWS 审计管理器、AWS Backup、AWS CloudFormation Stacksets、AWS CloudTrail、Amazon CloudWatch Events、AWS Compute Optimizer、AWS Config、AWS Control Tower、Amazon Detective、Amazon DevOps Guru、AWS Directory Service、AWS Firewall Manager、Amazon GuardDuty、AWS Health、AWS IAM、IAM 访问分析器、Amazon Inspector、AWS License Manager、Amazon Macie、AWS Marketplace、AWS Network Manager、AWS 资源访问管理器、AWS 安全中心、Amazon S3 Storage Lens、Amazon Security Lake、AWS Service Catalog、服务配额、AWS IAM 身份中心（AWS SSO 的继任者）、AWS Systems Manager、标签策略、AWS Trusted Advisor、AWS Well-Architected Tool、Amazon VPC IP 地址管理器 (IPAM) 和 Amazon VPC 可达性分析器。我们可以从受支持服务的仪表板启用集成。有关更新的服务列表，请参阅本指南的 另见 部分。

让我们了解一些有用的 AWS CLI 子命令，用于 AWS Organizations：

• create-gov-cloud-account 可用于在 AWS GovCloud (US) 区域创建账户，前提是我们有相关权限。

• invite-account-to-organization 向另一个账户发送邀请，邀请其加入我们的组织。

• remove-account-from-organization 将账户从组织中移除。

• create-organization 用于创建一个 AWS 组织，而 delete-organization 用于删除一个 AWS 组织。

• leave-organization 将账户从其父组织中移除。

• create-organizational-unit 用于创建一个组织单元（OU），而 delete-organizational-unit 用于删除一个组织单元（OU）。要删除一个 OU，必须先移除所有账户和子 OU。

• update-organizational-unit 用于重命名一个组织单元（OU）。

• describe-account 用于检索该账户的信息，应该从主账户调用。describe-organization 用于检索组织的信息。describe-organizational-unit 用于检索一个组织单元（OU）的信息。

• list-accounts 列出组织中的所有账户。list-accounts-for-parent 列出给定目标根或 OU 的子账户。list-create-account-status 列出与给定状态匹配的账户创建请求。list-roots 列出当前组织中定义的根。

• tag-resource 和 untag-resource 可用于管理标签。

与 AWS 交互的不同方式

我们可以通过多种方式与 AWS 进行交互，包括 AWS 管理控制台、AWS CLI、AWS 软件开发工具包 (SDKs)、AWS CloudFormation、外部工具如 HashiCorp 的 Terraform、直接的 AWS API 调用、AWS PowerShell 工具、AWS 云开发工具包 (CDK) 和 AWS 无服务器应用模型 (SAM)。根据具体任务和所需的自动化水平，每种方法都有其独特的优势。

对于本书中的食谱范围，我们将主要集中于 AWS 管理控制台和 CLI。管理控制台通常用于一次性配置和操作，提供直观和可视化的方式来管理 AWS 资源。另一方面，CLI 特别适合处理重复性任务，支持自动化和脚本化。掌握 CLI 不仅能简化我们的 AWS 操作并打下坚实的基础，还能帮助我们理解其他交互方式的细微差别，如 AWS SDK、CloudFormation、Terraform 等。

另请参阅

• 我们可以通过访问www.cloudericks.com/blog/getting-started-with-aws-organizations了解更多关于 AWS Organizations 的信息，包括最佳实践和配额。

• 要了解我们可以使用的所有 AWS CLI 命令，请参考 AWS CLI 文档中的 Organizations 部分，网址为docs.aws.amazon.com/cli/latest/reference/organizations/index.htm。

• 可以与 AWS Organizations 集成的服务可以在docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html找到。

• 本书中我们使用了 AWS CLI。然而，如果你想了解更多关于 CloudShell 的内容，可以访问www.cloudericks.com/blog/getting-started-with-aws-cloudshell。

• 我们可以通过访问www.cloudericks.com/blog/getting-started-with-aws-control-tower了解如何使用 AWS Control Tower，而不是直接使用 AWS Organizations。

用户管理和 SSO 与 IAM 身份中心

在本食谱中，我们将首先启用 IAM 身份中心服务（之前称为 AWS SSO），并学习如何在 IAM 身份中心中创建用户和组。接着，我们将创建权限集，并将一个组与该权限集一起分配给一个 AWS 账户。最后，我们将看到如何通过 AWS 访问门户使用 SSO 登录 AWS 管理控制台和 AWS CLI。

SSO 是一种用户认证过程，允许用户使用一套登录凭证访问多个应用程序或系统。这意味着在登录一次后，用户可以访问其他 AWS 账户和应用，而无需为每个系统重新登录。这简化了用户体验，并通过减少用户需要记住和维护的密码数量，从而增强了安全性。

准备工作

我们需要一个启用了 AWS Organizations 的 AWS 账户。要设置 AWS Organizations，我们可以按照本章中的多账户管理与 AWS Organizations食谱进行操作。

要使用 CLI 和 IAM 身份中心，我们需要按照本章的技术要求部分安装并配置 AWS CLI V2。

如何执行...

首先，我们将启用 IAM 身份中心。然后，我们将创建一个组和一个用户，并将该用户添加到该组。之后，我们将创建权限集，并使用该权限集为组分配 AWS 账户的访问权限。

启用 IAM 身份中心并创建用户和组

要启用 IAM 身份中心并创建一个组和用户，我们可以按照以下步骤进行：

1. 登录到 AWS 管理控制台并转到IAM 身份中心。

   如果我们还没有启用 IAM 身份中心，我们应该看到如下图所示的屏幕：

图 1.21 – IAM 身份中心仪表板

1. 如图 1.21所示，从 IAM 身份中心仪表板点击启用。

   我们现在应该被带到IAM 身份中心仪表板。

图 1.22 – IAM 身份中心的推荐设置步骤

1. 如图 1.22所示，点击选择您的身份来源下的步骤 1。

2. 将身份源的值保持为身份中心目录。

3. 对于访问控制的属性，点击启用。

4. 从左侧边栏点击组，然后点击创建组，如下图所示：

图 1.23 – IAM 身份中心侧边栏和组页面

1. 在创建组页面的组详情部分，输入awsseccbadmins作为组名称，并在描述下设置AWS 安全食谱管理员组。

2. 向下滚动，保持添加用户到组部分为空，不添加任何用户，点击创建组。

3. 从 IAM 身份中心仪表板的左侧边栏点击用户，然后点击添加用户。

4. 在基本信息部分，指定awsseccbadmin1作为用户名，在密码下选择向该用户发送带有密码设置说明的电子邮件。我们也可以生成一次性密码并与用户共享。

图 1.24 – IAM 身份中心中的指定用户详情页面

1. 填写基本信息部分中的其他字段，即电子邮件地址、确认电子邮件地址、名字、姓氏和显示名称。

2. 保持其他部分不变，即联系方法、工作相关信息、地址、偏好设置和附加属性，然后点击页面右下角的下一步。

3. 在将用户添加到组页面中，选择我们在本节中创建的awsseccbadmins组，然后点击下一步。

4. 在审查并添加用户页面上，审查详细信息并点击添加用户。现在我们应该能看到新用户已添加到用户页面。

5. 新添加的用户需要检查电子邮件，并按照指示接受邀请并完成密码设置。

图 1.25 – IAM 身份中心中新用户的邀请邮件

完成指令后，我们应该已经登录到 AWS 访问门户，在那里可以看到分配给我们的应用程序。目前，由于我们还没有分配任何应用程序，我们应该会看到您没有任何应用程序的消息。

接下来，我们将创建一个权限集。

创建具有 AWS 托管策略的权限集

按照指示创建一个权限集，我们可以在下一节分配 AWS 账户访问权限时使用：

1. 点击左侧边栏中的权限集，如图 1 23所示，在权限集页面上点击创建****权限集。

2. 选择预定义权限集作为权限集类型，对于选择 AWS 托管策略，选择AdministratorAccess。

图 1.26 – 在 IAM 身份中心中选择权限集类型

1. 向下滚动并点击下一步。

2. 在指定权限集详细信息页面上，将权限集名称的值保持为AdministratorAccess，会话时长保持为1 小时，添加一个有意义的描述，其他字段保持空白，然后点击下一步。

3. 在审查和创建页面上，审查所有内容后点击创建。

   新的权限集现在应该出现在权限集页面上。

接下来，我们将为 AWS 账户分配awsseccbadmins小组。

提供 AWS 账户的访问权限

我们可以按照以下步骤为小组提供一个或多个 AWS 账户的访问权限：

1. 点击左侧边栏中的AWS 账户选项，如图 1 23所示，进入AWS账户页面。

2. 选择我们希望授予访问权限的所有 AWS 账户，并点击分配用户或组。我已选择aws-sec-cookbook-1账户。

图 1.27 – IAM 身份中心中的 AWS 账户页面

1. 在选择用户和组页面的组标签页中，选择我们在本节中创建的awsseccbadmins组，然后点击下一步进入分配权限集页面。

2. 在分配权限集页面上，为我们的小组选择要分配给所选 AWS 账户的权限集。点击下一步进入审查和提交****分配页面。

图 1.28 – IAM Identity Center 中的权限集选择

1. 在审阅和提交任务页面上，审阅所有内容并点击提交。

2. 使用 AWS Identity Center 的AWS 访问门户 URL登录 AWS 访问门户。我们可以从我们的 Identity Center 仪表板中获取 URL。当用户被创建时，邀请邮件中也会包含该 URL。

   您需要点击AWS 账户（1）以查看新分配的 AWS 账户，然后点击账户以获取登录到管理控制台或命令行或编程访问的选项，利用临时凭证。

图 1.29 – AWS 访问门户

1. 点击管理控制台以登录分配给我们的 AWS 账户。点击用户名旁边的下拉菜单以验证账户详情。

我们可以按照相同步骤为用户（而不是组）提供对一个或多个 AWS 账户的访问权限。然而，最好的做法是为组分配权限，并根据需要添加或删除用户到这些组中。

使用 IAM Identity Center 为 AWS CLI 配置 SSO

在前一节中，我们看到如何使用 IAM Identity Center 从 AWS 访问门户登录到 AWS 管理控制台。在本节中，我们将学习如何配置 AWS CLI V2 与 IAM Identity Center：

1. 作为 IAM Identity Center 用户登录到 AWS 访问门户。我们应该看到一个类似图 1 .29的屏幕。

2. 从 AWS 访问门户中点击命令行或编程访问，而不是像在提供对 AWS 账户的访问子节的步骤 7中所做的那样进入管理控制台。

   我们应该看到一个弹出窗口，列出了不同选项以及使用 CLI 的必要步骤。

图 1.30 – 使用 IAM Identity Center 时使用 AWS CLI 的工作步骤

1. 假设我们已经安装了 AWS CLI V2，打开命令提示符（或终端），运行aws configure sso命令，并按照图 1 .30中显示的说明进行操作。提供SSO 起始 URL和SSO 区域，以及可选的 SSO 会话名称，如下图所示：

图 1.31 – 配置 AWS CLI V2 的 SSO

一旦我们为SSO 会话名称、SSO 起始 URL、SSO 区域和SSO 注册范围提供了值，浏览器将打开进行授权。请注意，我提供了自定义的SSO 起始 URL而不是默认的一个，如图 1 .30所示；两者都可以使用。授权完成后，命令提示符将恢复。

1. 运行aws s3 ls命令并附上配置文件名称进行验证，如图 1 .31所示。

我们只需要为 AWS 账户和角色组合配置一次 SSO，如下面的工作原理...部分所述。配置完成后，我们可以使用该配置文件通过aws sso login和aws sso logout命令登录和退出，如下所示。

在 AWS CLI 中使用 IAM Identity Center 进行 SSO 登录和退出

我们可以使用配置的 AWS CLI V2 配置文件登录和退出 AWS 账户，方法如下：

1. 使用aws sso login命令登录，提供我们已经配置的 CLI 配置文件名称（如我们在图 1 .31中看到的）。执行aws sso login命令，提供相同的配置文件名称，如下所示：

图 1.32 – 使用 SSO 从 CLI 登录 AWS 账户

aws sso login命令将打开一个浏览器进行授权，类似于aws sso login命令。授权完成后，命令提示符将恢复。

重要提示

如果我们有多个配置文件或者没有使用默认配置文件，即使在 SSO 登录后，执行 AWS CLI 命令时也需要指定配置文件。此外，如果我们尝试使用我们没有访问权限的配置文件，当调用GetRoleCredentials操作时，将会收到一个错误，指出发生了错误（ForbiddenException）：无法访问。

1. 使用aws sso logout命令退出登录，并执行aws sso logout命令，提供与之前相同的配置文件名称。

图 1.33 – 使用 SSO 从 CLI 退出 AWS 账户

工作原理...

AWS IAM Identity Center 是 AWS SSO 的后继者，帮助我们在多个 AWS 账户和应用程序之间安全地集中管理访问权限。IAM Identity Center 是处理 AWS 上身份验证和授权的建议方法。适用于各种规模的组织。

从 AWS IAM Identity Center 仪表板，我们可以配置对 AWS 组织内的 AWS 账户、诸如 Microsoft 365、salesforce 等多个云应用程序、EC2 Windows 实例以及其他启用 SAML 2.0 的应用程序的访问权限。配置完成后，我们只需登录到 AWS 访问门户，然后通过 SSO 登录到所有配置的 AWS 账户和应用程序，无需提供任何其他额外凭据。

身份提供者（IdP）是存储和验证用户身份的服务。我们可以利用 IdP 在不提供额外凭据的情况下登录多个应用程序使用 SSO。我们在本文中使用了 IAM Identity Center 的内置 IdP。但是，除了内置 IdP，我们还可以使用许多支持的 IdP，如 Microsoft Entra ID（以前是 Active Directory 或 Azure AD）、Okta、Ping Identity、Jump Cloud 和 Google Workspace。

在本食谱中，在启用 IAM 身份中心时，我们还启用了 访问控制的属性。我们可以根据用户身份源中的现有属性将用户分配给 AWS 中的工作负载，从而控制对资源的访问，实现 基于属性的访问控制 (ABAC) 。ABAC 是一种基于与用户、资源或环境相关的属性（特征或属性）来调节访问的方法。与 基于角色的访问控制 (RBAC) 不同，RBAC 根据用户在组织中的角色授予访问权限，而 ABAC 使用各种属性，如用户位置、访问时间，甚至访问资源的敏感性。这允许更灵活、情境感知和政策驱动的访问控制，从而实现更精细和动态的权限管理。

我们可以使用权限集为不同的 AWS 账户和应用程序分配不同的权限级别给用户或组。例如，我们可以为开发者账户授予完全访问权限，为生产账户授予只读访问权限。我们可以选择预定义权限集选项，像本食谱中一样选择可用的 AWS 管理策略之一，或者我们可以创建自定义权限集。

以下来自 IAM 身份中心的截图列出了在选择预定义权限集选项时当前可用的策略。

图 1.34 – 预定义权限集的策略

使用自定义权限集选项时，我们可以选择 AWS 管理的策略、客户管理的策略和内联策略，甚至可以选择设置权限边界。我们将在 第二章 的 在 IAM 身份中心中创建客户管理策略 食谱中看到自定义权限集。

在本食谱中，我们的用户为一个 AWS 账户分配了一个权限集。如果我们有多个权限集并且可以访问多个 AWS 账户，我们可以从 AWS 访问门户选择 AWS 账户和权限集进行登录，如下图所示：

图 1.35 – 带有多个 AWS 账户和权限的 AWS 访问门户

即使在为 CLI 配置 AWS SSO 时，我们也会被要求选择 AWS 账户和权限集。首先，我们将被要求选择 AWS 账户，如下所示：

图 1.36 – AWS CLI 账户选择

在选择账户后，如果在选定的 AWS 账户中有多个角色可供选择，我们将被提供选择角色（基于权限集）的选项。

图 1.37 – AWS CLI 角色选择

还有更多……

我们只能通过组织的管理账户或注册为 IAM 身份中心委托管理员的成员账户来管理 IAM 身份中心。否则，我们将看到类似以下的错误消息：

图 1.38 – 非委托管理员的成员账户错误消息

我们可以通过以下步骤将成员账户设置为委托管理员：

1. 登录到我们组织的管理账户的 AWS 管理控制台，并进入IAM 身份中心仪表板。

2. 在 IAM 身份中心的左侧边栏点击设置。

3. 转到管理标签页。

4. 找到委托管理员部分并点击注册账户。这将显示我们 AWS 组织的组织结构。

5. 在组织结构部分，选择我们希望设置为委托管理员的成员账户，然后点击注册账户。

我们应该看到一条消息，提示成员账户已成功注册为 IAM 身份中心的委托管理员。授予成员账户管理员权限可能需要一些时间。

我们可以自定义默认的 AWS 访问门户 URL（例如，d-90679fa661.awsapps.com/start/），使用自定义子域名（例如，awsseccb.awsapps.com/start），以便让用户更容易记住。要自定义 URL，我们可以在 IAM 身份中心仪表板右侧的设置概述部分点击自定义按钮，如图 1 图 22所示，并配置自定义子域名。自定义完成后，我们将无法再次更改它。

另见

• 我们可以在www.cloudericks.com/blog/demystifying-aws-iam-identity-center-formerly-aws-sso了解更多关于 IAM 身份中心的信息。

• 我们可以在www.cloudericks.com/blog/getting-started-with-aws-cli了解更多关于 AWS CLI 的信息。

第二章：使用 IAM 策略和角色进行访问管理

安全访问管理对有效管理谁可以访问我们的 AWS 资源以及他们可以执行哪些操作至关重要。这些知识确保我们的 AWS 环境保持安全且合规，允许我们精确控制权限，并最小化未经授权访问的风险。它使我们能够实施强大的安全防御体系，保护我们的数据和资源，同时还为我们提供了一种可扩展和高效的方式，来管理用户和服务在 AWS 基础设施中的访问权限。在本章中，我们将学习如何使用 IAM 策略 和 IAM 角色 来进行 AWS 云中的安全访问管理。

AWS 支持多种策略类型，例如 基于身份的策略、基于资源的策略、会话策略、权限边界、服务控制策略 (SCPs) 和 访问控制列表 (ACLs)。虽然我们将通过详细的示例学习大多数策略类型，但 ACLs 仅会进行理论讨论，因为不再推荐使用 ACLs。接下来，我们将学习 IAM 角色以及如何使用它们来实现跨账户访问，这是实施身份账户架构所必需的，并且如何使用角色进行跨服务访问，以便让一个 AWS 服务安全地访问另一个服务。我们将在本书的后续章节中继续探索 IAM 策略和角色。

本章将覆盖以下内容：

• 创建客户管理的 IAM 策略

• 在 IAM 策略中使用策略变量

• 在 IAM 身份中心创建客户管理的策略

• 为 IAM 实体设置 IAM 权限边界

• 使用 SCPs 在 AWS Organizations 中集中治理

• IAM 跨账户角色切换和身份账户架构

• 通过 EC2 实例上的 IAM 角色实现跨服务访问

技术要求

在深入本章的内容之前，我们需要确保以下要求已满足：

• 我们需要一个有效的 AWS 账户来完成本章中的大部分示例。我们可以使用一个属于 AWS 组织的账户或一个独立账户来完成大部分示例。我将使用我们在 第一章 的 AWS Organizations 的多账户管理 示例中创建的 awsseccb-sandbox-1 AWS 组织 成员账户。不过，除非特别说明，否则我不会使用 AWS Organizations 的功能，这意味着你也可以使用独立账户来跟随这些步骤。请注意，某些示例可能有不同的 AWS 账户要求，这些要求会在相关示例中说明。

• 对于管理操作，我们需要一个具有对我们正在使用的 AWS 账户的AdministratorAccess权限的用户。这可以是 IAM Identity Center 用户或 IAM 用户。我将使用我们在第一章的使用 IAM Identity Center 进行用户管理和 SSO配方中创建的awsseccbadmin1 IAM Identity Center 用户。但是，除非另有说明，我不会使用任何 IAM Identity Center 功能，这意味着如果用户在我们正在处理的账户中具有所需的权限，您也可以跟随这些步骤使用 IAM 用户。如果您使用 IAM 用户，您可以按照第一章的设置 IAM、账户别名和账单提醒配方创建用户。请注意，某些配方可能有特定的用户要求，这些要求将在这些配方中进行说明。

• 要在本地机器或虚拟机上执行 AWS命令行界面（CLI）命令，我们需要安装 AWS CLI v2。使用 IAM 用户的 IAM 访问密钥配置 AWS CLI，或者从 IAM Identity Center 获取 IAM Identity Center 用户的临时凭证。第一章详细介绍了如何使用 IAM 和 IAM Identity Center 设置 CLI。除非另有说明，我们可以使用 IAM 或 IAM Identity Center 管理用户，尽管 AWS 建议使用 IAM Identity Center。此外，通过 AWS 控制台提供的AWS CloudShell为执行本章讨论的大多数 CLI 命令提供了方便的方法。使用 IAM 和 IAM Identity Center 时，我们需要为每个用户每个账户创建一个配置文件。因此，最好将账户名称作为配置文件名称的一部分。例如，对于awsseccb-sandbox-1沙箱账户的管理员用户，我们可以设置一个 CLI Sandbox1Admin1配置文件：awsseccbadmin1。对于 IAM Identity Center，我们需要为每个用户每个账户每个权限集分配创建一个配置文件，因此还可以在名称中包含分配详情。

• 对于某些配方，我们需要一个亚马逊简单存储服务（S3）存储桶来测试策略。因此，建议您对亚马逊 S3 服务有基本的了解。除非另有说明，我们可以使用以下配置创建 S3 存储桶：对于存储桶名称，请提供一个唯一的名称，因为每个存储桶在 AWS 账户中都需要一个唯一的名称。对于对象所有权，选择禁用 ACL（推荐）。对于此存储桶的阻止公共访问设置，选择阻止所有公共访问。对于存储桶版本控制，选择禁用。对于默认加密，选择使用 Amazon S3 管理的服务端加密（SSE-S3）。在高级设置下的对象锁中，选择禁用。

本书的代码文件可以在github.com/PacktPublishing/AWS-Security-Cookbook-Second-Edition获取。本章的代码文件可以在github.com/PacktPublishing/AWS-Security-Cookbook-Second-Edition/tree/main/Chapter02获取。

创建客户管理的 IAM 策略

在这个配方中，我们将创建一个客户管理的基于身份的 IAM 策略来管理对 S3 桶的访问。我们将授予列出所有 S3 桶的权限，并进一步使用Condition策略元素，根据请求者的 IP 地址限制该权限。我们将使用 AWS 管理控制台来完成此配方，但你也可以通过使用提供的 JSON 代码，按照本章接下来的配方在 IAM 策略中使用策略变量，通过 AWS CLI 完成。

IAM 策略可以与 IAM 和 IAM 身份中心一起使用。在本配方中，我们将使用与 IAM 实体的 IAM 策略。在本章中的配方在 IAM 身份中心中创建客户管理的策略中，我们将学习如何使用相同的策略与 IAM 身份中心实体一起使用。

准备就绪

为了成功完成这个配方，我们需要以下内容：

• 一个有效的 AWS 账户，awsseccb-sandbox-1，以及一个具有对该账户的AdministratorAccess权限的用户，awsseccbadmin1，参照本章的技术要求部分。

• 为了测试这个配方，我们需要一个名为awsseccb_iam_user1的 IAM 用户，具有最小权限或没有权限，并且需要一个 S3 桶，参照本章的技术要求部分。

如何操作...

我们将首先使用awsseccbadmin1管理员用户创建 IAM 策略，然后将其附加到awsseccb_iam_user1 IAM 用户上。

从 AWS 管理控制台创建客户管理的 IAM 策略

我们可以通过以下方式使用 AWS 管理控制台中的 IAM 创建策略：

1. 以awsseccb-sandbox-1的awsseccbadmin1用户身份登录，并具有AdministratorAccess权限，进入IAM仪表板。

2. 从左侧边栏点击策略。

3. 点击创建策略。这将为我们提供一个可视化编辑器，如下图所示。

图 2.1 – 为策略指定权限

如果我们已经创建了 JSON 格式的策略，我们可以点击JSON标签，直接输入并保存。在这种情况下，我们可以跳过步骤 4到步骤 6。

1. 在选择服务部分，点击S3。此时我们应该看到如下界面：

图 2.2 – 配置 S3 资源的权限

1. 在访问级别标题下，展开List并选择ListAllMyBuckets，如下面的图所示：

图 2.3 – 选择访问级别权限

重要提示

在资源部分，由于ListAllMyBuckets操作并不特定于任何特定资源，因此将选择通配符（）来表示所有资源。如果选择了如ListBucket等特定于某个桶的操作，并且我们希望将其限制为单个桶，则需要选择特定，点击添加 ARN，并输入我们目标桶的Amazon 资源名称（ARN*），格式为arn:aws:s3:::<bucket_name>。ARN 是 AWS 用来在其云服务中指定资源的唯一标识符。

1. 在请求条件部分，选择来自 IP 的请求，提供我们的 IP 地址，并点击添加 IP。我们还可以按照以下图示的格式指定无类域间路由（CIDR）格式的 IP 地址范围。

图 2.4 – 配置请求条件

可选地，我们可以点击+ 添加另一个条件来根据需要添加更多条件。

1. 点击下一步进入审查并创建页面。

2. 在政策名称字段中输入MyS3ListAllBucketsPolicy，在描述 - 可选字段中输入MyS3ListAllBucketsPolicy（或任何我们想要的名称和描述）。

3. 向下滚动以查看政策详细信息并点击创建政策。

4. 进入策略并验证从JSON标签生成的策略 JSON：

图 2.5 – 生成的政策 JSON

请确保 IP 地址是你自己的，而不是从示例代码中复制的。

我们可以按照通过 AWS 管理控制台将 IAM 策略附加到 IAM 组小节，将我们创建的策略分配给 IAM 组。如果我们使用 IAM 身份中心，我们可以按照本章中的在 IAM 身份中心创建客户管理策略配方将策略与 IAM 身份中心组关联。

通过 AWS 管理控制台将 IAM 策略附加到 IAM 组

最佳实践是通过组向用户添加权限。因此，创建一个名为awsseccbusers的组，并将我们的awsseccb_iam_user1用户添加到该组。我们可以通过以下方式将权限分配给 IAM 组：

1. 使用awsseccb-sandbox-1账户中的awsseccbadmin1管理员用户登录控制台并进入IAM仪表板。

2. 在IAM仪表板的左侧边栏中点击用户组。

3. 点击awsseccbusers组以进入该组页面。

4. 进入权限标签页，从添加权限下拉菜单中点击附加策略。

图 2.6 – 配置组的权限

1. 在添加权限页面，选择MyS3ListAllBucketsPolicy策略，向下滚动并点击添加权限。

   现在，我们应该能够在权限标签下看到已添加到组中的新策略。

重要提示

我们也可以从IAM仪表板的策略标签中将策略附加到组或用户。

1. 现在我们可以通过以下方式验证更改：

   1. 使用我们在设置 IAM、帐户别名和计费提醒食谱中所学的 IAM 用户登录 URL，作为awsseccb_iam_user1用户登录到 AWS 管理控制台，第一章。

   2. 进入S3服务。

   3. 点击左侧边栏中的桶。

   我们应该能够看到所有的桶：

图 2.7 – 列出 Amazon S3 中的桶

我们只授予了ListAllMyBuckets权限，因此我们会在访问栏下看到权限不足。

在本节中，我们学习了如何将 IAM 策略分配给 IAM 组。然而，建议使用 IAM Identity Center 来使用 IAM 策略，我们将在接下来的食谱中探讨。

它是如何工作的...

在本食谱中，我们创建了一个客户管理型 IAM 策略。如同我们在章节介绍中所见，IAM 策略有多种类型。我们在本食谱中探讨了基于身份的策略。基于身份的策略定义了针对 IAM 实体（如用户、组或角色）的权限。基于身份的策略可以是管理型策略或内联策略。管理型策略是可以通过将它们与多个 IAM 实体关联来重用的策略，而内联策略是直接附加到 IAM 实体的策略。

管理型策略可以进一步分为 AWS 管理型策略和客户管理型策略。AWS 管理型策略由 AWS 创建和维护，虽然我们可以查看和使用它们，但不能编辑它们。客户管理型策略是当 AWS 管理型策略不足时，我们为满足需求而创建的策略。尽管我们可以直接将管理型策略分配给用户，但建议始终将它们分配给一个组，然后将用户添加到该组中。内联策略直接附加到 IAM 实体上，无法重用。

了解 IAM 策略结构

IAM 策略是 JSON 文档，遵循 AWS 中大多数策略类型的结构，除了 ACL（访问控制列表），它是基于 XML 的，以及虚拟私有云（VPC）终端节点。以下是一个 IAM 策略的示例：

图 2.8 – 一个 IAM 策略示例

以下是 IAM 策略文档的主要元素：

• Version元素表示策略语言版本。在图 2.8中，我们使用的是2012-10-17版本的策略语言，这是最新版本。

• 可选的Id元素指定了策略的标识符，主要用于区分策略的不同版本或实例。下面是一个示例："Id": "S3ReadOnlyPolicyID1"。

• Statement元素包含了主要的策略信息，包括权限、资源和条件。声明作为数组被添加到Statement元素中。

一个 IAM 策略的Statement元素可以包含以下子元素：

• 可选的Sid元素表示声明 ID。这可以用来提供策略的描述。

• Effect元素指定是否允许或拒绝对资源的访问。支持的值有Allow和Deny。

• Action元素指定该声明应用的权限或权限（例如，s3:ListAllMyBuckets）。我们还可以指定*来表示任何操作。

• 可选的NotAction元素是Action元素的反义，指定策略允许或拒绝除列出操作以外的所有操作。Action和NotAction元素可以包含在同一个 IAM 策略中，但不能在同一个策略的单个声明中使用。策略中的每个声明应当指定Action或NotAction之一。

• Resource元素指定声明应用到的资源 ARN（例如，S3 桶）。对于 S3 桶，ARN 应遵循以下格式：arn:aws:s3:::<bucket_name>/<key_name>。若要指定多个值，请用逗号分隔它们。我们可以指定*来表示任何资源。在此示例中，我们使用了ListAllMyBuckets策略，并将Resource设置为*，因为ListAllMyBuckets策略不是特定于某个资源的策略。我们希望使用像ListBucket这样的资源特定策略，并将其限制在某个桶中，如图 2 * .8*所示。

• 可选的NotResource元素是Resource的反义，指定所有资源，除了列出的资源，这些资源适用相应的操作。单个声明将包含Resource或NotResource，但不能同时包含两者。不过，它们可以作为两个不同声明的一部分包含在同一个 IAM 策略中。

• Principal元素用于标识 AWS 用户、账户、服务或其他实体，这些实体被授予或拒绝访问某个资源的权限。它主要用于基于资源的策略中，指定哪些实体可以访问特定的 AWS 资源。基于身份的策略不使用Principal元素，因为这些策略是直接附加到用户、组或角色上的，因此不需要包含Principal元素。权限边界也不包含Principal元素；相反，它们作为限制 IAM 实体（包括用户和角色，但不包括组）可以拥有的权限的上限。服务控制策略（SCP）也不包含Principal元素。以下是一个Principal元素的示例："Principal": {"AWS": "arn:aws:iam::Account-ID-without-hyphens:user/Rick"}。

• 可选的NotPrincipal元素是Principal元素的反义词，指定除列出的主体之外，哪些主体被策略允许或拒绝。与Principal元素类似，我们不能在服务控制策略（SCP）或权限边界中使用它。我们可以在单个策略声明中使用Principal和NotPrincipal中的一个，但不能同时使用它们。然而，它们可以在同一个整体策略中的不同声明中使用。

• 可选的Condition元素允许我们在条件下执行策略，如我们在图 2.8*中看到的那样。我们使用布尔运算符将条件与请求中的值进行匹配。例如，在这个示例中，我们使用了IpAddress条件与aws:SourceIp参数结合，只在请求来自指定的 IP 地址时允许执行操作。我们还可以使用 CIDR 表示法指定一个 IP 地址范围。CIDR 是一种分配和路由 IP 地址的方法，不依赖传统的基于类的系统。以下是一些所有支持 IAM 访问控制的 AWS 服务所支持的预定义条件键：aws:CurrentTime、aws:CurrentTime、aws:CurrentTime、aws:CurrentTime、aws:CurrentTime、aws:CurrentTime、aws:CurrentTime、aws:SecureTransport 和 aws:UserAgent。

还有更多……

让我们来了解一些与 AWS 策略相关的核心概念，包括 AWS 策略类型和策略评估逻辑。

AWS 策略类型

以下是 AWS 中一些重要策略类型的列表，包含示例和使用场景：

• 基于身份的策略：

  • 示例：附加到用户、组或角色的 IAM 策略。

  • 使用场景：它们允许开发人员对特定的 S3 存储桶进行只读访问。

• 基于资源的策略：

  • 示例：S3 存储桶策略和 IAM 角色信任策略。

  • 使用场景：它们授予另一个 AWS 账户中的用户对指定存储桶的读写访问权限。

• 会话策略：

  • 示例：限制临时假设角色时的权限策略。

  • 用例：它们为开发人员提供了临时的增强权限用于故障排除，同时通过限制只读访问来确保安全。

• 权限边界：

  • 示例：它们为 IAM 用户或角色设置了最大权限限制。

  • 用例：它们防止 IAM 用户将自身权限提升到定义的边界之外，以确保安全性和合规性。

  以下元素在权限边界中不支持：Principal、NotPrincipal和NotResource。

  权限边界作为限制任何附加策略可以授予的最大权限的机制，确保了权限分配的安全性和控制层次。权限边界不授予访问权限。本质上，如果基于身份的策略允许某些操作，除非这些操作也在权限边界的范围内，否则无法执行。如果基于身份的策略尝试授予超出权限边界允许的权限，则这些超额权限将受到限制。换句话说，有效权限是基于身份的策略和权限边界的交集。

• SCPs：

  • 示例：一个限制在 AWS 组织中所有账户删除 IAM 角色的策略。

  • 用例：它们通过确保某些 IAM 实体和策略不被修改或删除来增强安全性。

  以下元素在 SCP 中不支持：Principal、NotPrincipal和NotResource。

  AWS 组织中的 SCP 功能与权限边界类似，充当限制组织内 AWS 账户中 IAM 实体最大权限的护栏。SCP 不授予权限，而是限制权限，与 IAM 权限策略协同工作。有效权限是 IAM 策略和 SCP 的允许项的交集，任何在其中一个中显式的拒绝都会覆盖允许的权限。因此，IAM 实体只能执行 IAM 策略和 SCP 都允许的操作。

• ACLs：

  • 示例：它们指定了另一个 AWS 账户中的哪些主体可以访问特定的 S3 桶。

  • 用例：它们通过授予特定权限以访问存储在 S3 桶中的数据，实现 AWS 账户之间的安全数据共享。

每种策略类型都是 AWS 环境中的重要工具，促进了访问控制和安全性的复杂生态系统，确保了最佳的操作效率和安全性。本章讨论了基于身份的策略，在本书的后续章节中我们将讨论更多这些策略的变体以及其他类型的策略。接下来，我们将查看 IAM 策略评估逻辑的概述。

IAM 策略评估逻辑

AWS IAM 策略评估逻辑决定了一个请求是否被允许或拒绝，依据的是附加在发起请求的 IAM 主体（用户或角色）上的策略，以及适用的任何权限边界或基于资源的策略。

当没有 SCP 和权限边界时，会考虑所有权限的并集进行评估。以下是评估过程中涉及的简要步骤：

• 评估逻辑会检查是否存在任何适用于请求的显式 拒绝 语句。如果存在至少一个显式 拒绝，请求将被拒绝，无论是否有 允许 语句。

• 如果没有显式的 拒绝 语句，逻辑会检查是否存在任何显式的 允许 语句。如果至少有一个 允许，请求将被允许，前提是没有显式的 拒绝 语句。

• 如果没有适用于请求的显式 允许 或 拒绝 语句，默认情况下请求会被拒绝，因为 IAM 是一个默认 拒绝、显式 允许 系统。

如果我们使用 SCP 或权限边界，则会考虑其他策略与 SCP 或权限边界的交集进行评估。这是因为 SCP 和权限边界设置了你可以拥有的最大权限。因此，如果 SCP 或权限边界授予了 S3 访问权限，而身份策略授予了 EC2 权限，那么我们的有效权限将是零。为了更好地理解 SCP，可以参考 第一章 中关于 SCP 的讨论。

接下来，我们将探讨一些与 IAM 策略相关的额外概念。

关于 IAM 策略的附加说明

让我们快速浏览一些与 AWS 策略相关的额外概念：

• AWS 管理型 - 职能类型是 AWS 管理型 类型的一个子集，旨在与常见的 IT 职能对齐。目前的职能列表包括管理员、计费、数据库管理员、数据科学家、开发者高级用户、网络管理员、只读访问、安全审计员、支持用户、系统管理员和仅查看用户。

• AWS 策略生成器 可以生成以下几种策略类型：简单队列服务（SQS）队列策略、S3 存储桶策略、VPC 端点策略、IAM 策略和 简单通知服务（SNS）主题策略。它目前可以通过 awspolicygen.s3.amazonaws.com/policygen.html 访问。

• 如果在同一策略中为同一操作和资源设置了 允许 和 拒绝 效果，拒绝 将始终覆盖 允许。

• IAM 策略不能用于授予匿名用户权限，这与 S3 ACL 和 存储桶策略 不同。

• IAM 策略不能应用于 root 用户，只能应用于 IAM 用户。

要真正掌握并充分利用 AWS IAM，理解 AWS 策略的细节至关重要。通过全面了解策略管理和策略评估逻辑，我们可以尝试在安全性和操作效率之间找到平衡。有关最新的策略类型、评估规则和最佳实践，请始终参考官方 AWS 文档。

另见

我们可以继续在这里学习 AWS 策略和权限：www.cloudericks.com/blog/demystifying-aws-policies-and-permissions。

在 IAM 策略中使用策略变量

IAM 策略变量是一组预定义的占位符，我们可以在 IAM 策略文档中使用，它们将在运行时被实际值替换。它们有助于创建更动态和灵活的策略。在此示例中，我们将创建一个 S3 桶，并在其中创建与 IAM 用户名匹配的文件夹。借助${aws:username}策略变量，我们将允许 IAM 用户仅列出与其用户名匹配的文件夹内容。我们将使用 AWS CLI 来完成此示例，但您也可以通过在 AWS 管理控制台中使用前述示例提供的 JSON 代码来完成。

准备工作

为了成功完成此示例，我们需要以下内容：

• 一个正常工作的awsseccb-sandbox-1 AWS 账户，一个具有AdministratorAccess权限的用户，awsseccbadmin1，以及相应的Sandbox1Admin1 CLI 配置文件，按照本章的技术要求部分进行操作。

• 为了测试此示例，我们需要两个 IAM 用户，awsseccb_iam_user1 和 awsseccb_iam_user2，它们在沙箱账户中具有最小或没有权限，并且相应的 CLI 配置文件分别命名为 Sandbox1User1 和 Sandbox1User2。按照最佳实践，创建一个名为awsseccb_iam_users的用户组，并将这些用户添加到该组中。

• 一个符合本章技术要求部分的 S3 桶。在 S3 桶中创建文件夹，文件夹名称为我们为测试此示例而创建的 IAM 用户名，即awsseccb_iam_user1 和 awsseccb_iam_user2。

如何操作…

在本节中，我们将使用 AWS CLI 创建一个 IAM 策略，然后将其附加到一个用户组上。我们还将探索在此示例中使用策略变量的方法。让我们开始吧：

1. 创建一个名为s3-list-user-folder-policy.json的文件，并使用以下 JSON 策略，但请将我的桶名称替换为您的桶名称：

    {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": "s3:ListBucket",
         "Resource": "arn:aws:s3:::cloudericks-demo",
         "Condition": {
           "StringLike": {
             "s3:prefix": "${aws:username}/*"
           }
         }
       }
     ]
   }
   

重要提示

策略 JSON 文件以及所有 CLI 命令都包含在代码文件中。

1. 使用create-policy子命令创建策略：

   aws iam create-policy --policy-name S3ListMyFolderPolicy --policy-document file://s3-list-user-folder-policy.json --profile Sandbox1Admin1
   

   这应该返回策略的详细信息及其 ARN：

图 2.9 – 创建策略命令响应

1. 使用attach-group-policy子命令将策略附加到该组，使用前一个命令中的策略 ARN：

   aws iam attach-group-policy --group-name awsseccb_iam_users --policy-arn arn:aws:iam::207849759248:policy/S3ListMyFolderPolicy --profile Sandbox1Admin1
   

2. 通过运行 aws s3 ls 命令，并使用 AwsSecCbUser 配置文件针对 awsseccb_iam_user1 用户以及 awsseccb_users 组中的 awsseccb_iam_user1 桶名称和文件夹名称，验证更改：

   aws s3 ls cloudericks-demo/awsseccb_iam_user1/ --profile Sandbox1User1
   

   这应该会返回一个成功的响应，列出 awsseccb_iam_user1 文件夹中的所有对象。

图 2.10 – 列出 S3 文件夹

1. 通过运行 aws s3 ls 命令，并使用 Sandbox1User2 配置文件针对 awsseccb_iam_user2 用户以及 awsseccb_iam_user1 桶名称和文件夹名称，验证更改：

   aws s3 ls cloudericks-demo/awsseccb_iam_user1/ --profile Sandbox1User2
   

   这应该会返回一个 AccessDenied 响应，因为 awsseccb_iam_user2 无法列出 awsseccb_iam_user1 文件夹。

图 2.11 – 列出其他用户的 S3 文件夹

如果我们尝试使用 Sandbox1User2 配置文件列出 awsseccb_iam_user2 文件夹的内容，并且该配置文件属于 awsseccb_iam_user2 IAM 用户，我们应该获得一个成功的响应，列出 awsseccb_iam_user1 文件夹中的所有对象。

它的工作原理...

在这个示例中，我们创建了一个包含 ${aws:username} 策略变量的 IAM 策略，限制 IAM 用户只能列出 S3 存储桶内某个文件夹的内容，前提是该用户的用户名与文件夹名称匹配。${aws:username} 策略变量代表发出请求的 IAM 用户名。这意味着，如果我们将此策略分配给名为 awsseccb_iam_user1 的用户，那么在策略评估期间，IAM 策略中的 ${aws:username} 策略变量将在运行时被替换为 ${aws:username}，该用户将仅获得访问此文件夹的权限。

还有更多内容

AWS 支持一组预定义的策略变量，可以在 IAM 策略中使用。以下是常用的 IAM 策略变量列表：

• ${aws:username} : 此变量会被发出请求的 IAM 用户名替换。

• ${aws:userid} : 此变量表示发出请求的 IAM 用户或角色的唯一标识符。

• ${aws:CurrentTime} : 当前的日期和时间（UTC 格式），格式为 YYYY-MM-DDTHH:MM:SSZ。

• ${aws:EpochTime} : 当前的日期和时间（UTC 格式），表示自 1970 年 1 月 1 日以来的秒数（Unix 纪元时间）。

• ${aws:principaltype} : 发出请求的主体类型（用户、账户、角色、联合用户等）。

• ${aws:SecureTransport} : 一个布尔值，指示请求是否通过 SSL 发送。

• ${aws:SourceIp} : 请求者的 IP 地址。此变量对于限制对某些 IP 范围的访问非常有用。

• ${aws:UserAgent} : 请求者客户端应用程序的用户代理字符串。

• ${aws:Requester} : 请求者的 AWS 账户 ID。在跨账户场景中非常有用。

• ${aws:sourceVpc}、${aws:sourceVpce} 和 ${aws:sourceVpcIpv4CidrBlock} 是用于根据请求的源 VPC、VPC 终端节点或 IPv4 CIDR 块控制访问的变量。

• ${aws:TagKeys} 和 ${aws:RequestTag/tag-key} 用于匹配请求中的标签。

• ${aws:MultiFactorAuthPresent}：一个布尔值，表示请求是否使用了 多因素认证（MFA）。

• ${s3:x-amz-acl}、${s3:x-amz-acl}、${s3:x-amz-copy-source} 等是 S3 特定的服务变量，允许策略匹配与 S3 请求相关的各种条件。

• ${s3:prefix} 和 ${s3:max-keys} 是用于根据 S3 请求参数控制访问的特定变量。

这个列表并不详尽，因为 AWS 会持续发展，可能会引入新的变量或为 IAM 之外的不同服务提供特定的变量。要获得最当前和最全面的列表，最好参考官方 AWS 文档。

另见

我们可以在这里阅读更多关于 AWS 策略变量的内容：www.cloudericks.com/blog/understanding-aws-policy-variables-with-practical-examples。

在 IAM 身份中心创建客户管理的策略

要在 IAM 身份中心创建客户管理的策略，我们需要首先创建一个 自定义权限集，然后将用户或组分配到一个或多个 AWS 账户，并为其指定该权限集。在 第一章 的 用户管理与 IAM 身份中心的 SSO 食谱中，我们使用 AWS 管理的策略创建了一个权限集。在本食谱中，我们将创建一个基于本章 创建客户管理的 IAM 策略 食谱中创建的客户管理 IAM 策略的自定义权限集，然后，我们将使用组将用户分配到具有该权限集的 AWS 账户。

准备工作

我们需要以下内容才能成功完成此食谱：

• 设置了 IAM 身份中心实例的 AWS 账户。如果我们使用 AWS Organizations，如我们在 第一章 中看到的，这将是 管理账户。我们也可以使用 AWS 组织中的 委派管理员 账户来完成此操作。我们在 第一章 中学习了 委派管理员 账户。我们可以使用在 第一章 中设置的 aws-sec-cookbook-1 管理账户。或者，您可以按照独立的 AWS 账户进行操作，该账户没有 AWS Organizations，但设置了 IAM 身份中心实例，在这种情况下，只需使用该账户，我在本食谱中提到的 aws-sec-cookbook-1。

重要提示

作为良好的实践，我们可以通过使用委派管理员进行管理更改，限制对管理账户的访问，正如我们在第一章中用户管理和 SSO 与 IAM 身份中心食谱的更多内容…部分所述。这对于大型组织尤其建议，旨在限制具有管理账户访问权限的人数。

• 我们需要一个具有AdministratorAccess权限的用户来执行本食谱的操作，计划使用的是aws-sec-cookbook-1账户。在这里，我将使用在第一章中创建的awsseccbadmin1用户。

• 我们可以使用没有分配到我们账户aws-sec-cookbook-1的awsseccbuser1用户来测试食谱。我们还可以将awsseccbadmin1用户分配到另一个 AWS 账户，比如awsseccb-sandbox-1，该用户尚未与此权限集在该账户中有任何分配，并测试该分配。

• 我们需要在所有要进行分配的账户中，按照本章从 AWS 管理控制台创建客户托管 IAM 策略部分的创建客户托管 IAM 策略食谱，创建一个名为MyS3ListAllBucketsPolicy的客户托管 IAM 策略。由于我们计划在当前aws-sec-cookbook-1账户中进行分配，因此我们需要在aws-sec-cookbook-1账户内创建此策略。要在awsseccb-sandbox2账户中进行分配，我们需要在awsseccb-sandbox2账户内创建此策略。如果你正在按照本书中的食谱操作，我们已经在awsseccb-sandbox-1账户中创建了此策略，因此，如果我们计划将策略分配给该账户，则不需要再次创建该策略。策略的 JSON 文件包含在代码文件中，名为s3-list-all-my-buckets-policy.json。

• 一个遵循本章技术要求部分的 S3 存储桶。

• 要执行 CLI 命令，我们需要为awsseccbadmin1用户配置一个使用 IAM 身份中心的 CLI 配置文件，名为AWSSecCBAdmin1。在将客户托管策略分配给相同账户的awsseccbuser1用户后，我们还需要为该用户配置一个名为AwsSecCbUser1的 CLI 配置文件。需要注意的是，CLI 配置文件必须按账户和分配的每个用户分别配置，最佳实践是将账户名作为配置文件的一部分。因此，如果你想将awsseccbadmin1的权限分配给另一个账户，比如awsseccb-sandbox-1，我们可以创建一个名为Sandbox1Admin1的配置文件。

如何执行...

最初，我们将从管理控制台创建一个权限集并用于分配。之后，我们将使用 AWS CLI 复制该过程。

通过 AWS 管理控制台的客户托管 IAM 策略

我们将首先创建一个使用现有 IAM 策略的权限集，然后将其分配到 AWS 账户中。让我们开始吧：

1. 使用awsseccbadmin1用户登录到aws-sec-cookbook-1并进入IAM 身份中心仪表盘。

2. 使用位于屏幕右上角的区域下拉菜单，将区域更改为us-east-1，因为我们在第一章的用户管理和 SSO 与 IAM 身份中心教程中已将 IAM 身份中心的区域配置为us-east-1。如果你选择了不同的区域，请选择该区域。

重要提示

AWS Organizations 服务仅允许在任意时刻在一个 AWS 区域中使用 IAM 身份中心。如果我们希望在设置完一个区域后将 IAM 身份中心迁移到另一个区域，我们需要先删除最初选择区域中的现有配置，然后在新区域重新设置它。

1. 从左侧边栏点击权限集。

2. 在权限集页面中，点击创建权限集。

3. 在权限集类型页面中，选择自定义权限集并点击下一步。

4. 在指定策略和权限边界页面中，展开客户管理策略，然后点击附加策略。

5. 输入策略名称为MyS3ListAllBucketsPolicy。如果你使用了不同的名称，请在此处提供该名称。

图 2.12 – 选择客户管理的 IAM 策略

1. 向下滚动并点击下一步。

2. 在指定权限集详细信息页面中，将权限集名称设置为MyListAllBucketsPermission，描述设置为我的 S3 列出所有桶权限，将会话时长设置为1 小时，将页面中的其他字段留空，然后点击页面右下角的下一步。

3. 在审核并创建页面中，检查所有内容后点击创建。新的权限集应该会出现在权限集页面上。

4. 将awsseccbuser1用户（或包含此用户的组）分配到我们的aws-sec-cookbook-1 AWS 账户。选择我们在本教程中早些时候创建的MyListAllBucketsPermission权限集。关于分配权限集的详细步骤，我们可以参考第一章中的用户管理和 SSO 与 IAM 身份中心教程。

5. 为了验证分配，使用 AWS 身份中心的 AWS 访问门户 URL 以awsseccbuser1身份登录。我们可以从身份中心仪表盘中获取该 URL。该 URL 也包含在用户创建时发送到用户邮箱的邀请邮件中。登录访问门户后，我们现在应该能够看到aws-sec-cookbook-1账户（或任何其他分配给我们的账户）。

6. 从访问门户登录到aws-sec-cookbook-1账户，进入AmazonS3服务。

7. 从左侧边栏点击Buckets。我们应该能看到该账户下所有可用的桶。

我们现在将创建一个权限集并使用 CLI 将其分配到 AWS 账户。但是，在继续之前，我们应该先移除本节中做的分配，因为我们将使用 AWS CLI 进行相同的分配。

通过 AWS CLI 使用客户管理的 IAM 策略

在本节中，我们将首先创建一个权限集，然后使用该权限集将包含我们用户的组分配到 AWS 账户。让我们开始吧：

1. 为aws-sec-cookbook-1账户中的awsseccbadmin1用户配置 CLI，使用AwsSecCbAdmin配置文件名，并按照第一章中的用户管理和 SSO 与 IAM 身份中心的食谱登录。

重要提示

正如我们在第一章中学到的，我们可以使用aws configure sso命令，该命令主要用于通过 IAM 身份中心初步设置配置文件，提供sso_start_url和sso_region的值。此配置通常是一次性活动，除非我们需要更改或更新配置文件的设置。之后，每次我们想开始一个会话时，可以使用aws configure sso命令，使用aws configure sso命令注销会话。

1. 使用create-permission-set命令创建权限集：

   aws sso-admin create-permission-set \
       --instance-arn <Your-SSO-Instance-ARN> \
       --name MyS3ListAllBucketsPermissionCLI \
       --description "S3 List All Buckets Permission" \
       --session-duration "PT1H" \
       --profile AwsSecCbAdmin
   

   我们可以从 AWS 管理控制台中 IAM 身份中心的设置页面获取<Your-SSO-Instance-ARN>的值。

   如果权限集创建成功，我们应该收到类似以下的新权限集 ARN 的响应：

图 2.13 – create-permission-set 子命令的请求与响应

1. 使用attach-customer-managed-policy-reference-to-permission-set子命令将我们的客户管理策略附加到权限集：

   aws sso-admin attach-customer-managed-policy-reference-to-permission-set \
       --instance-arn <Your-SSO-Instance-ARN> \
       --permission-set-arn <Your-permission-set-ARN> \
       --customer-managed-policy-reference Name=MyS3ListAllBucketsPolicy \
       --profile AwsSecCbAdmin
   

   对于<Your-permission-set-ARN>，我们需要使用从前一个命令中获得的权限集 ARN。此命令不会返回任何响应。

2. 使用create-account-assignment子命令将权限集分配给我们的 AWS 账户和组：

   aws sso-admin create-account-assignment \
       --instance-arn <Your-SSO-Instance-ID> \
       --permission-set-arn <Your-Permission-Set-ARN> \
       --target-id <Target-Account-ID> \
       --target-type AWS_ACCOUNT \
       --principal-id <Your-Group-ID> \
       --principal-type GROUP
   

   <Target-Account-ID>是我们要分配权限的账户 ID，<Your-Group-ID>是组的 ID（而非名称），这两者都可以在 AWS 管理控制台的 IAM 身份中心中找到。此命令应该立即返回Status为IN_PROGRESS的响应：

图 2.14 – create-account-assignment 子命令的响应

1. 使用list-account-assignments子命令验证分配：

   aws sso-admin list-account-assignments \
       --instance-arn <Your-SSO-Instance-ARN> \
       --account-id <Assigned-Account-ID> \
       --permission-set-arn <Your-Permission-Set-ARN> \
       --profile AwsSecCbAdmin
   

   这应该给我们一个包含分配详细信息的响应：

图 2.15 – list-account-assignments 子命令的响应

1. 为awsseccbuser1用户配置名为AwsSecCbUser1的 CLI 配置文件，并按照第一章中的用户管理与 SSO 结合 IAM 身份中心食谱使用该配置文件登录。

2. 接下来，通过运行aws s3ls命令验证访问：

   aws s3 ls --profile AwsSecCbUser1
   

   这应该列出awsseccb_user1有权限查看的所有 S3 桶，符合MyS3ListAllBucketsPolicy的要求：

图 2.16 – 登录成功后列出所有桶

我们从 AWS 组织的管理账户完成了该食谱。我们也可以从指定为委托管理员的成员账户中进行操作。

它是如何工作的...

在这个食谱中，我们学习了如何基于我们已经在创建客户托管 IAM 策略食谱中创建的客户托管策略来创建权限集。在第一章中，我们深入研究了 AWS IAM 身份中心服务，并探索了基于 AWS 托管策略创建权限集的过程。

我们将Region设置为us-east-1，这是我们在创建 IAM 身份中心时配置的相同区域。AWS Organizations 服务允许在任何给定时间仅在一个 AWS 区域内使用 IAM 身份中心。如果我们希望在设置后将 IAM 身份中心迁移到其他区域，则需要首先删除最初选择的区域中的现有配置。

在 AWS 管理控制台中，我们在创建权限集时通过指定策略名称将客户托管策略附加到权限集。在命令行中，这是一项两步过程。首先，我们创建了权限集，然后将客户托管策略附加到权限集中。一个具有相同名称的策略需要在分配该权限集的成员账户中可用。可以从管理账户或指定为 IAM 身份中心委托管理员的成员账户创建权限集。客户托管策略必须位于接收权限集的成员账户中，而不是管理或管理员账户中。

在食谱的命令行部分，我们使用了两个与 IAM 身份中心相关的 AWS CLI v2 命令命名空间：sso-admin和sso。我们首先使用aws configure sso命令配置了一个 CLI 配置文件，其中包含sso_start_url和sso_region等值。除非需要更改或更新配置文件的设置，否则此配置通常是一次性活动。之后，我们使用了aws configure sso命令，每次想要登录时都可以使用该命令。

sso-admin命名空间中的命令帮助管理员管理 IAM 身份中心设置，如将用户组分配到具有特定权限集的 AWS 账户，或列出 IAM 身份中心实例。另一方面，sso命名空间中的命令旨在提供最终用户体验，如登录和退出启用了 IAM 身份中心的 AWS 账户。sso命名空间的命令通过 IAM 身份中心进行身份验证，使用临时 AWS 凭证，无需再次输入用户名和密码，从而通过消除管理多个凭证的需要，提高访问 AWS 服务的安全性。

还有更多...

尽管 AWS SSO 服务在 AWS 管理控制台中已经更名为 AWS IAM 身份中心，但 CLI 命名空间如sso-admin和aws sso保持不变，以确保向后兼容。

另请参见

• 我们可以在awscli.amazonaws.com/v2/documentation/api/latest/reference/sso-admin/index.html找到有关sso-admin命名空间及其命令的更多详细信息。

• 我们可以在awscli.amazonaws.com/v2/documentation/api/latest/reference/sso/index.html找到有关sso命名空间及其命令的更多详细信息。

为 IAM 实体设置 IAM 权限边界

本教程展示了如何使用权限边界为 IAM 实体（如 IAM 用户或 IAM 角色）设置最大权限限制。最初，我们将为一个用户赋予 S3 的完全访问权限。随后，我们会应用一个权限边界，将该用户的 S3 权限限制为仅具有只读访问权限。与 SCPs 类似，权限边界并不授予权限；它们只是定义了约束。换句话说，如果没有基于身份、基于资源或会话策略的配合，在权限边界或 SCP 允许的范围内的操作将无法执行。

准备工作

为了成功完成本教程，我们需要以下内容：

• 一个有效的 AWS 账户，awsseccb-sandbox-1，以及具有该账户AdministratorAccess权限的用户，awsseccbadmin1，按照本章节中的技术要求部分。

• 一个 IAM 用户，awsseccb_iam_user1，该用户对账户awsseccb-sandbox-1具有AmazonS3FullAccess权限。

• 了解如何创建一个 Amazon S3 桶。

如何操作...

我们可以按如下方式创建一个权限集：

1. 以awsseccbadmin1身份登录到awsseccb-sandbox-1的 AWS 管理控制台，然后进入IAM仪表板。

2. 在左侧边栏点击用户，然后点击本教程中将要使用的用户名称，在我们的例子中是awsseccb_iam_user1。

3. 向下滚动到权限边界部分，点击设置权限边界。

图 2.17 – 设置权限边界

1. 搜索AmazonS3ReadOnlyAccess，选择它，然后点击Set boundary。

2. 使用awsseccb_iam_user1用户登录到我们的 AWS 管理控制台，进入 S3 服务仪表板，并尝试以默认配置创建一个存储桶。即使用户具有AmazonS3FullPermission，我们仍然会收到类似下面的错误信息。

图 2.18 – 创建存储桶失败

1. 使用awsseccbadmin1用户登录到账户，进入awsseccb_iam_user1的Permissions boundary部分，并点击Remove boundary，如下面的图所示。在确认对话框弹出时，点击Remove boundary。

图 2.19 – 移除权限边界

1. 使用awsseccb_iam_user1用户登录到我们的 AWS 管理控制台，进入 S3 服务仪表板，并尝试以默认配置创建一个存储桶。现在我们应该能够成功创建存储桶。

2. 使用awsseccbadmin1用户登录到管理控制台，进入IAM仪表板，并移除所有现有权限，无论是直接分配的还是继承的。对于从组继承的权限，可以通过在Groups选项卡下的User groups membership部分中将用户从所有组中移除来实现。从Users窗格中，点击awsseccb_iam_user1用户的名称，并进入Groups选项卡。直接分配的权限可以从Permissions选项卡中移除。确认在Permissions选项卡中没有附加任何权限策略。

3. 进入Permissions boundary部分，点击Set permissions boundary，搜索AmazonS3FullAccess，选择它，然后点击Set boundary。

4. 使用awsseccb_iam_user1用户登录到我们的 AWS 管理控制台，进入 S3 服务仪表板，并尝试以默认配置创建一个存储桶。我们应该会收到类似于步骤 5中的错误信息。这表明即使我们在权限集内允许了权限，如果没有身份基础、资源基础或会话策略的支持，在权限边界内允许的操作也无法执行。

在继续后续操作之前，您可以移除权限边界。

工作原理...

在 AWS IAM 中，权限边界作为一种控制机制，用于设置用户或组可以拥有的最大权限，无论是否附加了任何直接的策略。通过将权限边界附加到用户，我们定义了其权限的上限。在所述场景中，演示用户最初继承了完全的 S3 访问权限。然而，当将权限边界策略，如AmazonS3ReadOnlyAccess，应用到该用户时，它将限制其 S3 权限为只读访问。当权限边界、SCP 和基于身份的策略同时应用时，只有当所有三个组件都明确允许该操作时，操作才会被授权。在仅存在 SCP 和权限边界的情况下，如果没有任何基于身份或基于资源的策略授权该操作，默认结果是拒绝。

还有更多...

在仅存在 SCP 和权限边界的情况下，如果没有任何基于身份或基于资源的策略授权该操作，默认结果是拒绝。

另见

我们可以在www.cloudericks.com/blog/getting-started-with-permissions-boundaries-in-aws 阅读有关 IAM 实体权限边界的更多信息。

使用 SCP 在 AWS Organizations 中集中治理

AWS 中的SCPs允许我们在整个 AWS 组织、组织单元（OUs）或甚至单个账户中管理权限。SCPs 通过允许管理员高效地在多个 AWS 账户中实施一致的合规性和安全策略，满足了集中治理的关键需求。通过使用 SCP，组织可以提升其安全态势，更有效地管理风险，并确保通过集中化的策略管理框架遵守内部政策和外部监管要求。在本教程中，我们将使用 SCP 限制在特定区域内创建 Amazon S3 存储桶。

准备工作

我们需要一个已启用 AWS Organizations 服务的有效 AWS 账户。我将使用我们在第一章中创建的aws-sec-cookbook-1账户。

如何操作...

我们可以按如下方式探索 SCP：

1. 登录到 AWS 管理控制台并导航到AWS Organizations服务。

2. 在左侧边栏中点击策略。

图 2.20 – 策略仪表板

1. 点击服务控制策略。如果我们是第一次使用 SCP，请点击启用服务控制策略。在服务控制策略窗格中，我们可以看到一个名为FullAWSAccess的策略已经存在。

2. 在服务控制策略窗格中，点击创建策略。

3. 在策略名称字段中输入SandboxS3BucketCreate，并可选地在**策略描述 - 可选字段中输入SandboxS3BucketCreate。

4. 将给定的策略粘贴到策略部分，然后向下滚动并点击创建策略。该策略允许在除us-east-1以外的任何区域创建 S3 存储桶。

    {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "Statement1",
         "Effect": "Deny",
         "Action": [
           "s3:CreateBucket"
         ],
         "Resource": [
           "*"
         ],
         "Condition": {
           "StringEquals": {
             "aws:RequestedRegion": "us-east-1"
           }
         }
       }
     ]
   }
   

5. 在服务控制策略面板中，选择我们创建的策略，点击操作下拉菜单，然后点击附加策略。

6. 选择我们要附加策略的组织单位（OU）或账户，然后点击附加策略。我选择了在第一章中创建的awsseccb-sandbox-1账户。我们可以根据需要选择多个 OU 和账户。

7. 登录到我们附加策略的账户，举例来说是awsseccb-sandbox-1，作为一个具有AdministratorAccess权限的用户，并尝试在us-east-1区域创建一个 S3 存储桶。我们应该会收到一条错误信息，表示我们没有所需的权限。

图 2.21 – 权限不足错误

1. 在另一个区域创建一个 S3 存储桶，例如us-east-2，应该会成功。

2. 要分离策略，我们可以登录到管理账户，导航到我们创建的服务控制策略，进入目标选项卡，选择账户，然后点击分离。

图 2.22 – 用于从账户中分离策略的目标选项卡

1. 一旦您分离了策略，返回到我们的测试账户，举例来说是awsseccb-sandbox-1，并尝试在us-east-1区域创建一个 S3 存储桶。这一次我们应该能够创建存储桶。

它是如何工作的…

我们使用了一个 SCP，通过在 SCP 中定义一个Deny语句来限制在特定区域创建 S3 存储桶，目标是创建 S3 存储桶的操作（s3:CreateBucket），并将其与一个检查请求区域是否是要限制的区域（例如，us-east-1）的条件相关联。这种方法确保了对 S3 存储桶部署的集中控制和治理，使组织能够执行区域合规标准，增强安全态势，并优化其 AWS 环境中的资源利用。

默认情况下，SCPs 是禁用的，但我们可以启用它们。如果启用 SCPs，它们需要明确允许允许的服务和操作。当我们启用 SCPs 时，AWS 会将一个名为FullAWSAccess的 SCP 附加到该组织内的所有账户和组织单位（OU）。这个 SCP 允许所有操作和服务。我们可以随后创建额外的 SCPs 来拒绝某些服务或操作，且Deny始终优先。这是默认策略。在此策略下，当 AWS 引入新服务或操作时，我们无需做任何操作，因为它们已经被FullAWSAccess SCP 允许。

我们也可以用另一个只允许特定服务和功能的 SCP 替换 FullAWSAccess SCP。如果这样做，我们必须显式地将 AWS 后续引入的任何新服务或操作添加到该 SCP 中。然而，如果我们遵循前面提到的策略，即保留 FullAWSAccess SCP，并添加另一个包含服务和操作拒绝列表的 SCP，当 AWS 引入新服务或操作时，我们无需做任何操作。

如果启用了 SCP，每个账户、根 OU 和其他 OU 都需要至少附加一个 SCP。因此，如果我们需要用另一个 SCP 替换 FullAWSAccess SCP，首先需要创建并附加另一个 SCP，然后再卸载 FullAWSAccess SCP。

还有更多内容...

SCPs 类似于 IAM 中的权限边界，定义了实体可能拥有的最大权限，但本身并不授予权限。因此，当权限边界、SCP 和基于身份的策略同时应用时，只有在所有三个组件都显式允许的情况下，某个操作才会被授权。此外，在只有 SCP 和权限边界而没有任何基于身份或资源的策略授权操作的情况下，默认结果是拒绝。这强调了权限必须显式授予的原则，缺乏明确的权限时，访问将不被允许。我们在本章前面已经讨论过策略类型。

另请参阅

我们可以在这里阅读更多关于服务控制策略的示例：www.cloudericks.com/blog/understanding-aws-scps-and-the-deny-list-and-allow-list-strategies。

IAM 跨账户角色切换和身份账户架构

许多组织使用多个 AWS 账户来分别管理不同的操作环境，如开发、测试和生产。具有不同岗位职责的用户可能需要在这些环境中具有不同的访问权限。然而，管理多个 IAM 用户，每个用户在各个 AWS 账户中拥有不同的访问凭证，可能是复杂且耗时的任务。

AWS IAM 中的角色授予一组特定的权限，类似于用户账户。与用户不同，我们不会直接登录角色；相反，我们可以切换到自己账户中的角色或其他 AWS 账户中的角色。这会用角色的权限替代我们原有的权限。根据角色切换的方式，通常采用两种主要策略来简化跨多个 AWS 账户的用户访问管理，避免每个账户都需要单独的 IAM 用户和访问凭证。

第一种角色切换方式是通过 SSO（单点登录），用户通过中央访问门户进行身份验证，并获得对多个账户的访问权限，每个账户具有不同的角色和权限。在这种模式下，角色切换是自动进行的。第二种角色切换方式则利用身份账户架构，用户登录到身份账户或中央账户，并使用 AWS 的角色切换功能访问多个账户的资源，每个账户分配了特定的角色和权限。

在 AWS 将 AWS SSO 更名为 IAM 身份中心后，AWS 推荐使用 IAM 身份中心服务作为最佳实践，而不是直接使用 IAM。因此，今天管理多个账户时，首选的方法是使用带有 IAM 身份中心的 SSO。然而，许多，特别是小型组织，不希望维护 AWS Organizations 服务的开销，仍然广泛使用角色切换功能。我们可以将角色切换功能与 IAM 身份中心结合使用，这种兼容性促进了从传统的使用 IAM 用户和身份账户架构的方式到使用 IAM 身份中心的平滑过渡。

在本食谱中，我们将学习实施第二种方法，即使用身份账户架构，利用角色切换功能将角色从源账户切换到目标账户。使用 IAM 身份中心（以前称为 AWS SSO）的第一种方法已在《第一章》的食谱中以及本章早期的食谱中进行了探讨。

重要提示

角色切换可以由 IAM 用户、IAM 身份中心中的用户、SAML 联邦角色甚至 Web 身份联邦角色执行。但是，AWS 账户的根用户不能进行角色切换。

在 AWS Organizations 中，所有成员账户会自动创建一个带有信任策略的全访问角色。该角色可以帮助管理账户切换角色到 AWS Organizations 中创建的任何成员账户。因此，计划在 AWS Organizations 中在管理账户和成员账户之间切换角色的管理员可以跳过本食谱中的设置部分，直接进入角色切换的部分，利用在 AWS Organizations 设置过程中配置的角色，正如在《第一章》中《使用 AWS Organizations 管理多个账户》食谱中所展示的那样。

准备工作

为了成功完成本食谱，我们需要以下内容：

• 两个 AWS 账户，一个作为源账户，另一个作为目标账户。这些可以是独立账户，也可以是 AWS 组织中的账户。我们可以使用在第一章中的多账户管理与 AWS 组织示例中创建的两个成员账户，即 awsseccb-sandbox-1 作为源账户，awsseccb-sandbox-2 作为目标账户。

• 在源账户和目标账户中都需要一个具有管理员权限的用户来创建角色和策略。使用 IAM 身份中心，我们可以创建一个单一用户，awsseccbadmin1，并授予其两个账户的管理员访问权限。如果选择传统的 IAM，则必须在每个账户中单独创建一个具有该权限的用户。

• 在源账户（例如我们的 awsseccb-sandbox-1）中，创建一个名为 awsseccb_iam_user1 的 IAM 用户，该用户没有权限或具有 IAMUserChangePassword 权限（如果您选择了用户必须在下次登录时创建新密码 - 推荐选项）。我们也可以使用 IAM 身份中心。然而，在这里使用 IAM 身份中心可能显得有些多余，因为我们可以使用 IAM 身份中心的访问门户登录多个 AWS 账户，而无需使用账户切换功能。不过，我们仍然可以这样做，为了更好地理解这些概念，您也可以尝试该选项。

• 一个符合本章技术要求部分的 S3 存储桶。

• 要执行与 AWS CLI 相关的步骤，我们需要为 awsseccbadmin1 管理员用户设置两个 AWS CLI 配置文件。首先，AWSSecCBAdmin1D 用于目标账户，其次，AWSSecCBAdmin1S 用于源账户。此外，我们还需要一个名为 AWSSecCBUser1S 的配置文件，用于源账户中的 awsseccbuser1 用户。使用常规 IAM 时，每个用户每个账户都需要 AWS CLI 配置文件。使用 IAM 身份中心时，每个用户每个角色（PermissionSet）每个账户都需要一个 AWS CLI 配置文件。

如何操作...

要切换角色，目标账户必须具有可分配的角色和信任策略，使得源账户可以承担该角色。此外，源账户还需要一个授权该切换的策略。我们将首先通过 AWS 管理控制台配置目标账户和源账户。我们也可以使用 AWS CLI 实现这一点。

通过 AWS 管理控制台设置目标账户

在目标账户中，我们需要一个角色以及一个信任策略，允许源账户承担此角色。我们将创建一个带有现有权限策略的角色，并为信任关系指定源账户的账户 ID。让我们开始：

1. 以管理员用户 awsseccbadmin1 登录目标账户的 AWS 管理控制台，例如 awsseccb-sandbox-2。

2. 进入IAM仪表板。

3. 在左侧边栏点击角色。

4. 点击创建角色。

5. 在 Select trusted entity 页面中，在 Trusted entity type 下，选择 AWS account，如下面的图所示。

图 2.23 – 为角色选择受信任的实体类型

1. 向下滚动，选择 Another AWS Account，输入源账户的 12 位数字 Account ID（在我的案例中，将是 awsseccb-sandbox-1 账户的 ID），然后点击页面右下角的 Next。

图 2.24 – 配置源账户的账户 ID

1. 在 Add permissions 页面中，搜索 S3，选择 AmazonS3ReadOnlyAccess，然后点击页面右下角的 Next。

2. 在 Name, review, and create 页面中，在 Role name 字段中输入 SA-S3ReadOnly，在 Description 字段中输入 Amazon S3 Read Only Access Role。我给这个角色加上了 SA 前缀，用以表示这是一个切换账户角色。

3. 审核角色详细信息后，点击页面右下角的 Create role。

4. 一旦看到成功消息 Role SA-S3ReadOnly created，点击 View role，记下角色的 ARN，然后选择 Link to switch rolesin console。

接下来，我们将在源账户中创建一个 IAM 策略，以授予源账户中的用户假设新创建的角色的权限。

通过 AWS 管理控制台设置源账户

当源账户中的管理员切换角色时，只需在目标账户中创建带有信任策略的角色即可。不需要在源账户中创建或附加策略，因为管理员已拥有 sts:AssumeRole 权限。因此，如果我们是源账户中的管理员，可以跳过本食谱中源账户的设置部分。

我们可以按照以下步骤在源账户中创建所需的 IAM 策略：

1. 登录到源账户的 AWS 管理控制台（在我的案例中是 awsseccb-sandbox-1），以 awsseccbadmin1 管理员身份，进入 IAM 仪表盘。

2. 从左侧边栏点击 Policies。

3. 点击 Create policy。

4. 点击 JSON 标签，然后在 policy editor 中粘贴以下策略 JSON。记得将 arn:aws:iam::DESTINATION_ACCOUNT_ID:role/ROLE_NAME 替换为我们在前一部分中记下的角色 ARN。或者，我们可以直接将 DESTINATION_ACCOUNT_ID 替换为目标账户的 ID，将 ROLE_NAME 替换为我们在前一部分中创建的角色名称：

   {
       "Version": "2012-10-17",
       "Statement": {
         "Effect": "Allow",
         "Action": "sts:AssumeRole",
         "Resource": "arn:aws:iam::DESTINATION_ACCOUNT_ID:role/ROLE_NAME"
       }
   }
   

5. 点击页面右下角的 Next。

6. 在 Review and create 页面中，在 Policy name 字段中输入 AR_Sandbox2_S3ReadOnly，在 Description 字段中输入 AssumeRole policy for S3ReadOnlyAccess in awsseccb-sandbox-2。

7. 审查详细信息并点击页面右下角的创建策略。我们应该会看到一个Policy AR_Sandbox2_S3ReadOnly已创建的消息。

8. 将此策略附加到源账户中的awsseccbusers组，该组包含awsseccbuser1用户。在 IAM 中，我们可以直接将策略附加到源账户中的组。而在 IAM 身份中心中，我们必须首先创建一个包含此策略的权限集，并在分配源账户时将其分配给该组，如在第一章中所示。

接下来，我们将从源账户切换到目标账户。

通过 AWS 管理控制台切换角色

为了从源账户切换到目标账户，请按照以下步骤操作：

1. 使用分配了切换角色权限的用户（如awsseccb_iam_user1）登录源账户的 AWS 管理控制台，假设该账户为awsseccb-sandbox-1。如果通过 AWS IAM 身份中心访问门户进行登录，确保选择带有AssumeRole策略的源账户角色。

2. 点击用户名旁边的下拉菜单，然后点击切换角色，如下图所示：

图 2.25 – 带有切换角色按钮的用户菜单

这里，我正在第二次切换角色，以显示角色历史的详细信息。在第一次尝试时，你将不会看到角色历史的详细信息。

1. 在切换角色屏幕中，针对账户，输入目标账户的账户号码，针对IAM 角色名称，输入SA-S3ReadOnly。

图 2.26 – 切换角色屏幕

一旦我们以所需的用户身份（此处为awsseccb_iam_user1）或所需的源账户身份（此处为awsseccb-sandbox-1）登录，也可以通过粘贴在步骤 10中的角色切换链接来切换角色，该链接位于通过 AWS 管理控制台设置目标账户一节中。

1. 点击切换角色。

2. 这时，我们应该已经成功登录到新账户。我们可以通过任务栏中账户名称旁边的下拉菜单来验证这一点：

图 2.27 – 切换角色后用户菜单

1. 转到S3服务，验证我们是否能够看到所有的存储桶及其详细信息。

2. 我们可以通过点击切换回按钮返回到父账户，如图 2.27所示。

接下来，我们将看到如何通过命令行创建一个角色。

通过 AWS CLI 设置目标账户

使用 AWS CLI，首先，我们需要在目标账户中创建一个嵌入信任策略的角色，然后将权限策略与此角色关联。我们将使用AWSSecCBAdmin1D CLI 配置文件来运行 CLI 命令，该配置文件为目标账户（在我这里是 awsseccb-sandbox-2）中的 awsseccbadmin1 用户配置了 AdministratorAccess 权限。让我们开始吧：

1. 首先，我们需要创建一个 信任策略，允许目标账户信任源账户，并将文件保存为 trust-policy.json：

   {
       "Version": "2012-10-17",
       "Statement": [
         {
           "Effect": "Allow",
           "Principal": {
             "AWS": "arn:aws:iam::<SOURCE_ACCOUNT_ID>:root"
           },
           "Action": "sts:AssumeRole"
         }
       ]
     }
   

   将 <SOURCE_ACCOUNT_ID> 替换为您源账户的 12 位账户 ID。

2. 使用上一步中创建的信任关系文件创建角色：

   aws iam create-role \
       --role-name SA-S3ReadOnlyRoleCLI \
       --assume-role-policy-document file://trust-policy.json \
       --profile AWSSecCBAdmin1D
   

   如果成功，命令将返回包含新创建角色的详细信息，包括 RoleId 和角色的 ARN。

3. 将 AmazonS3ReadOnlyAccess 权限策略附加到新创建的角色：

   aws iam attach-role-policy \
       --role-name SA-S3ReadOnlyRoleCLI \
       --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
       --profile AWSSecCBAdmin1D
   

   该命令没有输出。

接下来，我们需要在源账户中创建一个授权角色切换的策略。

使用 AWS CLI 设置源账户

我们将使用 AWSSecCBAdmin1S CLI 配置文件来运行命令，该配置文件为源账户（在我这里是 awsseccb-sandbox-1）中的 awsseccbadmin1 用户配置了 AdministratorAccess 权限。让我们开始吧：

1. 创建一个策略，允许源账户身份在目标账户中假设角色，并将文件保存为 assume-role-policy-cli.json：

   {
       "Version": "2012-10-17",
       "Statement": {
         "Effect": "Allow",
         "Action": "sts:AssumeRole",
         "Resource": "arn:aws:iam::DESTINATION_ACCOUNT_ID:role/SA-S3ReadOnlyRoleCLI"
       }
   }
   

   将 DESTINATION_ACCOUNT_ID 替换为目标账户的 12 位账户 ID。

2. 创建一个策略，允许使用我们在 步骤 1 中创建的 assume-role-policy-cli.json 文件假设目标账户中的 S3ReadOnlyRoleCLI 角色：

   aws iam create-policy \
       --policy-name AR_Sandbox2_S3ReadOnly_CLI \
       --policy-document file://assume-role-policy-cli.json \
       --profile AWSSecCBAdmin1S
   

3. 将该策略附加到源账户中的 awsseccbusers 组，该组包含 awsseccbuser1 用户。使用 IAM 时，我们可以直接将策略附加到源账户中的组；使用 IAM 身份中心时，我们必须先创建一个包含该策略的权限集，并在将其分配给源账户的组时进行分配，就像我们在 第一章 中看到的那样。

接下来，我们将从源账户切换角色到目标账户。

通过 CLI 切换角色

我们需要使用 AWSSecCBUser1S CLI 配置文件来运行命令，该配置文件为源账户中的 awsseccbuser1 用户配置了 sts:AssumeRole 权限。让我们开始吧：

1. 在 .aws/config 文件中为该角色建立一个新的配置文件。在 Unix 或 Linux 系统中，该文件位于用户的主目录下。对于 Windows 用户，可以在 C:\Users\USERNAME\.aws\config 找到该文件。确保将 USERNAME 替换为您的实际 Windows 用户名：

   [profile switchrole]
   role_arn = arn:aws:iam::DESTINATION_ACCOUNT_ID:role/SA-S3ReadOnlyRoleCLI
   source_profile = AWSSecCBUser1S
   

   我们需要将角色的 ARN 替换为我们在目标账户中创建的角色的 ARN。无论是进行跨账户角色假设，还是在同一账户内进行角色假设，我们都需要遵循这一步骤。

2. 使用这个新用户配置文件运行aws s3 ls命令，如下所示：

   aws s3 ls –profile switchrole
   

   这应该会返回目标账户中桶的名称，表示成功的响应。

重要说明

要获取角色的凭证，AWS CLI 会内部使用sts:AssumeRole来利用与source_profile关联的凭证假设该角色，在我们的案例中，source_profile是AWSSecCBUser1S。因此，与source_profile关联的身份应该具备sts:AssumeRole权限，以便假设role_arn中提到的角色。

1. 我们还可以通过运行aws sts assume-role命令来验证角色切换的变化：

   aws sts assume-role \
       --role-arn ROLE_ARN \
       --role-session-name SESSION_NAME \
       --profile AWSSecCBUser1S
   

   如果aws sts assume-role命令成功执行，应该会返回AccessKeyId，SecretAccessKey和SessionToken。我们可以通过 API，包括 CLI，使用从aws sts assume-role命令返回的凭证。

工作原理...

在这个示例中，我们配置了两个账户，一个是源账户，一个是目标账户，目的是能够从源账户切换角色并登录到目标账户，前提是目标账户中有一个角色。这个功能用于身份账户架构，在这种架构中，所有 IAM 用户都在单一 AWS 账户中进行管理，通常被称为身份账户，并且可以切换角色以访问多个账户中的资源，从而避免为每个账户单独提供登录凭证。

要在账户之间切换角色，我们要切换到的账户必须为此目的设置一个角色。目标账户中的角色应该包括一个信任策略，允许源账户假设此角色，源账户必须拥有包含sts:AssumeRole权限的策略，以允许该角色的假设。总之，要在两个 AWS 账户之间切换角色——我们称之为源账户和目标账户——需要以下配置：

• 首先，目标账户中必须存在一个可以由源账户中的身份（用户或服务）假设的角色。

• 其次，源账户中的身份必须被授予sts:AssumeRole权限。此权限应在其策略中指定要假设的角色的 ARN。此步骤对于单一账户内或两个不同账户之间的角色切换都是必需的。

• 对于跨账户角色切换，如本示例中所见，目标账户还必须附加一个信任策略到角色上，允许源账户假设该角色。

目标账户中附加到角色的信任策略是基于资源的策略示例，而授权角色切换的源账户中的策略则是基于身份的策略示例。隐式地，配方中使用了会话策略。附加到目标账户中角色的 IAM 策略充当会话策略。当角色被假定时，无论是在同一账户内还是跨账户，AWS 安全令牌服务（STS）会为会话生成临时安全凭证。这些凭证包括会话策略，定义了临时会话中可用的权限。

一旦假定角色，授予的权限将完全由会话策略决定。此外，任何与假定角色的 IAM 身份关联的权限将暂时放弃，从而确保临时会话严格在所假定角色的权限范围内操作，减少未经授权访问的风险。此外，显式使用aws sts assume-role命令可以获取临时安全凭证。成功后，该命令会提供AccessKeyId、SecretAccessKey和SessionToken。这些凭证可以通过 API 使用，包括 AWS CLI，从而根据假定角色的会话策略定义的权限，控制对 AWS 资源的访问。

当我们在 AWS Organizations 中设置新账户时，AWS 会自动在新成员账户中创建一个 IAM 角色。此角色旨在允许管理账户中的管理员假定该角色并访问成员账户。这个角色通常被命名为OrganizationAccountAccessRole，但在 AWS 组织中创建账户时，我们可以将其更改为其他名称，正如我们在第一章中所看到的。如果我们使用的是不属于 AWS Organizations 的账户，则需要手动创建这些角色。

如果我们使用 AWS IAM 身份中心与 AWS Organizations 配合使用，我们可以通过访问门户轻松登录到不同的 AWS 账户，而实现我们在本配方中讨论的身份账户架构以切换角色并登录到不同 AWS 账户就变得多余了。然而，角色在多种用例中仍然有用，包括跨服务访问，正如我们将在下一个配方中看到的那样。

还有更多……

让我们快速探讨在切换角色时如何使用外部 ID功能以增强安全性。

混淆代理问题是一种安全漏洞，发生在一个具有受限访问权限的程序无意中授予未经授权的访问权限给其资源。当一个受信任实体将权限委托给一个较少受信任的实体时，问题就会出现，该较少受信任的实体代表受信任的实体行事，但方式不当，可能导致安全漏洞。在我们的配方中，源账户尝试在目标账户中扮演角色时，由于源账户较少受信任，可能导致对目标账户敏感资源的未经授权访问，因此该漏洞非常相关。这种风险源于通过角色假设机制委托权限，在这种情况下需要适当的控制措施以防止滥用和未经授权的访问。

现在，让我们看看如何通过使用外部 ID 进行跨账户角色切换来解决混淆代理问题。外部 ID 作为一个唯一的密钥，用于在两个 AWS 账户之间建立信任关系，通常用于 AWS 账户希望授权第三方账户访问其资源的场景。具体来说，在涉及跨账户 IAM 角色的场景中，如我们在此配方中看到的，资源拥有账户（信任账户）指定外部 ID。第三方（被信任账户）必须使用该外部 ID 来扮演指定的角色。通过要求角色假设和请求者使用匹配的外部 ID，系统确保只有经过验证的授权实体（通过外部 ID 和适当的权限验证）才能访问资源，从而避免这种安全漏洞。

在设置目标账户时，图 2 .24 中的 要求外部 ID（当第三方将假设此角色时的最佳实践） 选项未被选中。为了使用外部 ID，我们可以选择此选项，并添加我们选择的外部 ID 值。一旦配置了外部 ID，在切换角色时需要提供外部 ID，如下所示的命令，否则将拒绝访问：

 aws sts assume-role --role-arn ROLE_ARN --role-session-name SESSION_NAME --profile AWSSecCBUser1S --external-id awssecb-cust-0819

另见

• 阅读更多关于使用 external-id 的内容，访问 www.cloudericks.com/blog/mitigating-confused-deputy-problem-external-ids-secure-cross-account-access-aws。

• 阅读更多关于 AWS 中身份账户架构的内容，访问 www.cloudericks.com/blog/implementing-identity-account-architecture-within-aws。

通过 IAM 角色在 EC2 实例上进行跨服务访问

在本配方中，我们将创建一个 IAM 角色，允许 EC2 实例访问 S3 API，并将其附加到 EC2 实例上。IAM 角色为 AWS 服务或用户提供临时权限，以访问另一个 AWS 服务。这避免了将访问密钥和秘密访问密钥等凭证硬编码到 EC2 实例中的需要。

准备工作

完成本配方中的步骤，我们需要以下内容：

• 一个有效的 AWS 账户，awsseccb-sandbox-1，以及该账户的拥有AdministratorAccess权限的用户，awsseccbadmin1，根据本章节的技术要求部分。

• 具备 IAM、EC2 和 S3 服务的基本知识。

如何操作...

我们可以为 EC2 实例创建一个具有访问 S3 API 权限的 IAM 角色，方法如下：

1. 进入IAM仪表盘。

2. 点击左侧边栏中的角色。

3. 点击创建角色。

4. 在可信实体类型下，选择AWS 服务，在服务或用例下，选择EC2作为将使用此角色的服务，然后点击下一步。

图 2.28 – 选择可信实体

1. 选择AmazonS3FullAccess并点击下一步。

图 2.29 – 权限策略

1. 输入角色名称（例如，MyS3AccessRole）。

2. 可选地添加标签并点击创建角色。

   我们可以按如下方式将角色与 EC2 实例关联：

   1. 进入EC2仪表盘。

   2. 点击左侧边栏中的实例。

   3. 选择我们的实例，点击操作，点击安全，然后点击修改IAM 角色：

图 2.30 – 将 IAM 角色附加到实例

1. 选择我们的新 IAM 角色并点击更新 IAM 角色。我们应该会看到成功信息。

2. 通过 SSH 连接到我们的实例，并运行以下命令：

 aws s3 ls

1. 您将获得以下输出：

图 2.31 – 列出 S3 桶

当我们从实例运行此命令时，我们应该能够看到我们账户中的所有桶，因为我们更新了角色。

它是如何工作的...

在本配方中，我们已授予 EC2 实例 S3 访问权限，使其能够从实例内执行受支持的 S3 操作，无论是通过 CLI 还是代码，而无需直接嵌入凭证。如果在 EC2 机器中嵌入 AWS 凭证，则如果机器遭到破坏，凭证可能会被泄露。

当为 EC2 实例创建 IAM 角色时，如本配方所示，AWS 会自动生成一个 EC2 实例配置文件。这个配置文件作为数字徽章，明确标示了实例可使用的服务。实质上，它包含了 IAM 角色，为我们的 EC2 实例提供了与特定 AWS 服务（如 S3）进行安全高效交互所需的权限。每当 EC2 实例执行需要这些权限的任务（例如与 S3 交互）时，它就“假设”这个角色。

还有更多...

IAM 角色有助于促进 AWS 环境中的安全跨服务访问。这些角色可以跨各种 AWS 服务使用，以向实体（如 Lambda 函数、ECS 任务，甚至是 AWS 组织中的用户或组）授予临时权限。通过定义精细的权限，IAM 角色能够实现不同服务之间的无缝集成与协作，同时遵循最小权限原则。

例如，IAM 角色可以分配给 Lambda 函数，以访问特定的 AWS 资源，如 S3 桶或 DynamoDB 表，而无需使用硬编码的凭证。同样，ECS 任务可以担任 IAM 角色，以便在容器化应用程序部署过程中与其他 AWS 服务交互。此外，AWS 组织可以利用 IAM 角色在多个账户之间安全地委派权限。

IAM 用户和角色都是被分配特定权限策略的 IAM 身份。用户与静态凭证（如访问密钥）关联，这些凭证可能会暴露，而 IAM 角色为每个会话提供临时安全凭证，减少了对长期静态凭证的依赖。角色可以由包括用户、组、应用程序或 AWS 服务在内的各种实体担任。

实质上，IAM 角色作为实现 AWS 生态系统中安全高效跨服务访问控制的基础元素，促进了敏捷性、可扩展性和强大的安全实践。

与 IAM 角色相关的重要概念

让我们快速浏览一些关于 IAM 角色的更多重要概念：

• 角色的信任策略允许受信账户中的用户切换或担任该角色。

• 信任策略中不能指定通配符（*****）作为主体。

• 当用户担任一个角色时，暂时放弃自己的权限，直到用户停止使用该角色为止。

• 一些服务允许直接将策略附加到资源，而无需使用角色作为代理。这些资源包括 S3 桶、Glacier 金库、Amazon SNS 主题和 Amazon SQS 队列。

• 角色可以由通过外部身份提供者服务认证的外部用户使用，以访问 AWS 资源。

• 角色允许移动应用程序使用 AWS 资源，而无需将 AWS 访问密钥嵌入应用程序中。

• 角色链式操作是指通过 AWS CLI 或 API，角色通过担任第二个角色的过程。

• 要在 EC2 实例启动时将角色信息传递给实例，我们可以在实例配置文件中添加角色。实例配置文件可以看作是 IAM 角色的容器。list-instance-profiles-for-role CLI 命令列出角色的实例配置文件。

• 权限边界是我们可以用来设置基于身份的策略可以授予 IAM 实体（如用户或角色）最大权限的功能。put-role-permissions-boundary CLI 命令可用于创建或更新角色的权限边界，而delete-role-permissions-boundary则会删除角色的权限边界。

• attach-role-policy CLI 命令将策略附加到角色，而detach-role-policy则从角色中分离策略。

• put-role-policy CLI 命令创建或更新内联策略，get-role-policy 检索角色中的指定内联策略，delete-role-policy 删除指定的内联策略。

另见

我们可以在www.cloudericks.com/blog/secure-cross-service-access-ec2-instance-profiles-iam-roles 阅读更多关于 EC2 实例配置文件和 IAM 角色的内容。

第三章：使用 KMS 和 CloudHSM 进行密钥管理

加密就像将我们的消息转换成秘密代码，以便只有预期的接收者能够理解。想象一下，我们有一条不希望任何其他人阅读的消息。原始形式的消息被称为明文。在我们对其进行编码后，它变成了密文，对于不知道如何解码的人来说，看起来像无意义的话语。将明文转换为密文称为加密，将密文转换回明文称为解密。为了进行加密和解密，我们使用一组称为加密算法的数学规则。加密算法的示例包括Rivest-Shamir-Adleman（RSA）、高级加密标准（AES）、数据加密标准（DES）、三重数据加密标准（3DES）、Blowfish、Blowfish、椭圆曲线加密（ECC）、国际数据加密算法（IDEA）和非常好的隐私（PGP）。

你可能会想，如果加密算法是公开的知识，那么有什么阻止任何人解密数据呢？答案在于使用加密密钥 - 一组唯一的字符字符串，与算法一起使用时保护数据。有两种主要类型的加密：对称和非对称。对称加密使用相同的密钥进行加密和解密，这要求该密钥在涉及的各方之间保密。相比之下，非对称加密使用密钥对 - 一个用于加密，另一个用于解密。例如，公钥可以公开共享，用于加密，而私钥则由预期接收者严格保护，用于解密。因此，即使算法的广泛知识，由于加密密钥的机密性，加密数据的隐私仍然受到保护。

AWS 密钥管理服务（KMS）是 AWS 云中的主要服务，帮助我们创建和管理加密密钥，也是本章的主要焦点。KMS 支持对称和非对称加密密钥。根据所有权，我们可以将 KMS 密钥分类为客户管理的密钥、AWS 管理的密钥和AWS 拥有的密钥。使用客户管理的密钥，我们创建和管理密钥。使用 AWS 管理的密钥，AWS 在我们的账户中为特定服务（如 S3、EBS 等）创建密钥，并为我们管理密钥。AWS 还有另一种称为 AWS 拥有的密钥，AWS 为服务（如 S3 的默认加密）创建和管理的密钥。使用客户管理和 AWS 管理的密钥，我们可以通过 CloudTrail 日志查看各种密钥及其使用情况。然而，对于 AWS 拥有的密钥，我们没有任何可见性。

在本章中，我们将学习如何使用 AWS CloudHSM。CloudHSM 是 AWS 中的另一个服务，它允许我们管理加密密钥，但使用专用的 HSM 来增强安全性。KMS 则使用共享的硬件安全模块（HSMs）。

本章中，我们将涵盖以下配方：

• 在 KMS 中创建密钥

• 使用外部密钥材料创建密钥（BYOK）

• 在 KMS 中旋转密钥

• 使用授权程序化授予权限

• 使用带条件密钥的密钥策略

• 在账户之间共享客户管理的密钥

• 创建、初始化和激活 CloudHSM 集群

技术要求

在深入研究本章的配方之前，我们需要确保已经具备以下要求：

• 我们需要一个有效的 AWS 账户来完成本章中的配方。可以使用属于 AWS Organizations 的账户或独立账户。我将使用我们在第一章中为使用 AWS Organizations 进行多账户管理创建的awsseccb-sandbox-1账户。但我不会使用 AWS Organizations 的任何功能，这意味着你也可以使用独立账户来跟随这些步骤。

• 对于管理员操作，我们需要一个具有AdministratorAccess权限的用户来操作我们正在使用的 AWS 账户。这个用户可以是IAM 身份中心用户或 IAM 用户。我将使用在第一章中我们为用户管理和使用 IAM 身份中心的单点登录创建的 IAM 身份中心用户awsseccbadmin1。不过，我不会使用 IAM 身份中心的任何功能，这意味着如果用户在账户中拥有AdministratorAccess权限，你也可以使用 IAM 用户来执行这些步骤。你可以参考第一章中的设置 IAM、账户别名和账单警报配方来创建 IAM 用户。

• 对加密的基本知识（包括对称密钥、非对称密钥和公钥基础设施（PKI））有一定了解，将帮助你理解本章中的配方。

本书的代码文件可以在github.com/PacktPublishing/AWS-Security-Cookbook-Second-Edition 找到。本章的代码文件可以在github.com/PacktPublishing/AWS-Security-Cookbook-Second-Edition/tree/main/Chapter03 找到。

在 KMS 中创建密钥

在这个配方中，我们将创建一个自定义管理的 KMS 密钥，密钥类型设置为对称密钥。对称密钥是我们使用 KMS 创建的最常见的密钥。还需要注意的是，KMS 密钥，作为 KMS 中的主要资源，曾被称为客户主密钥（CMKs）。这种更名有助于避免与“客户管理密钥”这一术语混淆，后者也可以缩写为 CMKs。

准备就绪

我们需要以下内容来完成此操作：

• 一个有效的 AWS 账户（awsseccb-sandbox-1）和一个用户（awsseccbadmin1），如技术 要求部分所述。

• 两个用户或角色。这些可以是 IAM 用户或角色，包括与 IAM 身份中心用户对应的角色。我将使用awsseccb_admin1用户作为密钥管理员。密钥管理员可以通过 KMS API 管理密钥。我将使用另一个用户awsseccb_user1作为密钥用户。密钥用户可以使用客户管理的密钥加密和解密数据。我们甚至可以使用相同的用户同时作为密钥管理员和密钥用户。我还将解释如何使用与 IAM 身份中心用户对应的角色作为密钥管理员或密钥用户。

如何操作...

我们可以通过控制台在 KMS 中创建一个客户管理的密钥，具体步骤如下：

1. 登录到 AWS 管理控制台并进入密钥管理服务。

2. 从左侧边栏点击客户管理密钥。

3. 点击创建密钥。

4. 在配置密钥步骤中，如下图所示，选择对称作为密钥类型，并选择加密和解密作为密钥用途：

图 3.1 – 配置密钥类型和密钥使用

1. 展开高级选项并验证密钥材料来源已设置为KMS - 推荐，并且区域性已设置为单一区域密钥，如图所示。然后，点击下一步进入添加标签步骤：

图 3.2 – 高级选项

1. 在添加标签步骤中，输入seccb-dev-encryption作为别名，并为描述输入Sec CB 项目的开发加密密钥。可选地，通过点击添加标签按钮添加标签。点击下一步进入定义关键管理权限步骤。

2. 在定义关键管理权限步骤中，选择关键管理员，这些是可以通过 KMS API 管理此密钥的 IAM 用户和角色。我已选择awsseccb_admin1。然而，正如我们所见，如果使用 IAM 身份中心用户，我们可以选择与该 IAM 身份中心用户和权限集组合对应的角色。

图 3.3 – 定义关键管理权限

1. 对于密钥删除，勾选允许密钥管理员删除此密钥。点击下一步进入定义密钥使用权限步骤。

2. 关于定义密钥使用权限步骤，选择密钥用户，即可以使用客户管理密钥进行数据加密和解密的 IAM 用户和角色。在同一步骤中，我们还可以选择其他 AWS 账户，使其能够使用该密钥。我选择了awsseccb_user1用户。与步骤 7类似，如果我们使用 IAM Identity Center 用户，我们可以选择与该 IAM Identity Center 用户和权限集组合对应的角色。点击下一步。

3. 审查密钥配置、别名和描述、标签和密钥策略（JSON 格式）。点击完成以创建密钥。我们应该看到一条消息，显示密钥已创建，并显示密钥 ID 的详细信息，如下图所示：

图 3.4 – 密钥创建成功消息

AWS 生成的密钥策略保存在代码文件中，供参考，文件名为generated-key-policy.json。

在本教程中，我们创建了一个 KMS 密钥。在下一节中，我们将介绍一些与 KMS 密钥相关的重要概念。

工作原理...

在 AWS KMS 中创建加密密钥是一个简单的过程。首先，我们需要一个具有管理权限的 IAM 用户或 IAM Identity Center 用户的有效 AWS 账户，以便创建和管理密钥。我们需要kms:CreateKey权限来创建新的 KMS 密钥。为了添加标签，我们还需要kms:TagResource权限。在本教程中，我们使用了一个具有AdministratorAccess权限的用户，因此拥有这两项权限。

在配置密钥时，我们选择了用于一般加密和解密目的的对称 KMS 密钥选项，如图 3.1所示。在高级选项部分，我们将密钥材料的来源选择为 KMS，这是推荐的选项。在加密学领域，密钥材料指的是在加密算法中使用的比特字符串，是加密和解密我们数据的核心元素。每个 AWS KMS 密钥都与一个密钥材料相关联，相关信息存储在其元数据中。默认情况下，AWS 负责使用 FIPS 验证的硬件安全模块创建密钥材料，并且该材料永远不会以未加密的形式离开 AWS KMS。唯一的例外是非对称密钥对的公钥，它可以导出供外部使用。

密钥材料的来源是 AWS KMS 中 KMS 密钥的一个特定属性，用于指示其密钥材料的来源。从图 3.2中我们可以看到，KMS 密钥的密钥材料来源值可以是以下之一：

• KMS - 推荐是默认选项，也是最推荐的选项。如果选择此选项，AWS 会处理密钥材料的创建和管理。

• 外部（导入密钥材料）适用于那些希望导入自己密钥材料的用户。这样我们就需要管理和保护这些材料。

• 使用AWS CloudHSM 密钥库时，AWS KMS 在我们的 AWS CloudHSM 集群中创建密钥材料。

• 外部密钥存储 用于当密钥材料存储在 AWS 之外的外部密钥管理器中时。这是专门针对外部密钥存储中的 KMS 密钥。

如我们在 图 3 .3 中看到的那样，我们可以将 IAM 用户或角色指定为密钥管理员。密钥管理员是可以通过 KMS API 管理此密钥的 IAM 用户和角色。我们还选择了允许密钥管理员删除密钥的选项。类似地，我们可以将 IAM 用户或角色指定为密钥用户。密钥用户是能够使用客户管理的密钥来加密和解密数据的 IAM 用户和角色。

KMS 密钥策略是一个 JSON 文档，指定谁可以访问该密钥以及在什么条件下访问。与密钥一起，AWS 会创建一个默认的密钥策略，并为我们选择的密钥管理员和密钥用户分配所需的权限。如果我们查看生成的密钥策略，应该能够看到 kms:Create* 、 kms:Describe* 、 kms:Enable* 、 kms:List* 、 kms:Put* 、 kms:Update* 、 kms:Revoke* 、 kms:Disable* 、 kms:Get* 、 kms:Delete* 、 kms:TagResource 、 kms:UntagResource 、 kms:ScheduleKeyDeletion 和 kms:CancelKeyDeletion 等权限，适用于密钥管理员。对于密钥用户，我们应该看到 kms:Encrypt 、 kms:Decrypt 、 kms:ReEncrypt* 、 kms:GenerateDataKey* 和 kms:DescribeKey 等权限。这些权限也能帮助我们了解在 KMS 中可以执行哪些操作。

还有更多...

在这个实例中，我们使用 KMS 提供的标准选项创建了一个密钥。我们可以根据自己的需求配置这些选项。例如，在这个实例中，我们选择了允许密钥管理员删除密钥的选项。根据我们的安全需求，我们可以取消选择该选项，禁止密钥管理员删除密钥。

提示

尝试使用 KMS 中所有可用的选项，并熟悉它们。这将帮助您在工作场景、考试或面试中遇到类似情境时，做出正确的选择。

让我们快速了解一些关于 AWS KMS 服务的重要要点：

• 我们在这个实例中创建了一个对称密钥。AWS KMS 也支持非对称密钥。AWS KMS 允许您创建和管理用于加密和签名的非对称密钥对，方便那些需要公钥基础设施（PKI）场景的应用，例如加密数据，使得只有私钥持有者才能解密，或者为数据签名以验证发送者身份。

• AWS KMS 密钥最多可以加密 4 KB 大小的数据，因此通常用于加密其他密钥，例如 数据密钥。这些数据密钥然后用来加密实际的数据。这些数据密钥并不在 AWS KMS 服务中创建和管理。

• KMS 是一个区域性服务，因此 KMS 管理的密钥是区域特定的。因此，要使用 KMS 密钥，相应的服务也应位于同一地区。例如，要使用我们为加密 S3 数据而创建的密钥，S3 存储桶需要位于相同区域。

• KMS 支持一个叫做 多区域密钥 的功能，它允许数据在与加密数据时不同的区域进行解密。需要注意的是，这些密钥当前并不是全球性的。相反，存在一个主密钥，并将其复制到其他区域的副本密钥中。

• 拥有 S3 管理员权限的用户，除非是用于加密该文件的密钥的密钥用户，否则没有权限查看使用 KMS 密钥加密的文件。

• 密钥管理员没有权限使用这些密钥加密或解密数据。然而，密钥管理员可以修改密钥策略，将自己添加为密钥用户。这也是审计和日志服务变得重要的地方。

• AWS KMS 与 AWS CloudTrail 集成，提供所有密钥使用的日志，帮助满足合规性和监管要求。这一集成功能使用户能够跟踪何时以及是谁使用了 KMS 密钥进行加密和解密，提供审计日志，这对于取证分析和合规性审计至关重要。

• 我们无法直接删除密钥。密钥管理员可以禁用密钥和/或安排删除密钥。在写这篇文章时，管理员可以在安排删除密钥时指定一个 7 到 30 天（含）的等待期。对于多区域密钥，我们需要首先删除副本密钥；只有在删除副本密钥后，才能删除主密钥。因此，删除多区域密钥的最短天数是 14 天：7 天用于删除副本密钥，7 天用于删除主密钥。

• 一旦密钥被禁用，我们将无法解密使用该密钥加密的任何数据，直到我们重新启用该密钥。

• 一旦密钥被删除，我们将无法解密任何使用该密钥加密的数据。

另见

• 对加密的良好理解将帮助你更好地理解 AWS KMS 服务。你可以在这里了解加密的相关知识：www.secdops.com/blog/getting-started-with-encryption。

• AWS KMS 是一项功能丰富的服务。你可以在这里了解更多关于 KMS 及其功能的信息：www.cloudericks.com/blog/getting-started-with-aws-key-management-service-kms。

使用外部密钥材料创建密钥（BYOK）

当我们在 AWS KMS 中创建密钥时，AWS 会为该密钥创建并管理密钥材料。我们也可以使用在 AWS 外部创建的自有密钥材料来创建密钥。在这个操作中，我们将学习如何将密钥材料导入到 AWS KMS。使用外部密钥材料来创建密钥被称为 自带密钥 (BYOK)，对于那些有严格合规性或政策要求，强制使用他们控制的密钥的组织来说，这非常有用。该密钥应该是一个 256 位的对称密钥。BYOK 不支持使用非对称密钥。

准备就绪

我们将需要以下内容来完成这个操作：

• 一个有效的 AWS 账户，awsseccb-sandbox-1，以及一个用户，awsseccbadmin1，如技术要求部分所述。

• 在本地机器上安装最新的 OpenSSL。如果尚未安装，请访问 OpenSSL 官方网站：www.openssl.org，下载最新版本的 OpenSSL 并根据说明进行安装。运行openssl version命令以确保安装的是最新版本的 OpenSSL。

重要提示

如果你是 macOS 用户，可能会遇到一个重要的兼容性问题：macOS 默认使用 LibreSSL 配合openssl命令，而不是 OpenSSL。为了确保使用正确版本的 OpenSSL，你可能需要通过 Homebrew 安装它，并在指定完整路径时直接调用它，或者甚至调整系统的PATH设置。如何操作的简易步骤指南可以参考以下博客文章：www.secdops.com/blog/using-openssl-alongside-the-default-libressl-on-macos。

假设我们已经设置并能正确运行openssl version命令，接下来我们将使用它创建外部密钥材料。

如何操作...

我们将通过将密钥材料来源设置为外部，从 AWS KMS 开始创建我们的密钥。然后，我们将从 AWS KMS 服务下载密钥导入包装器，在本地生成密钥，并使用导入包装器将其包装。最后，我们将上传我们包装好的密钥材料及导入包装器来完成密钥创建。

为外部密钥创建密钥配置

我们可以为外部密钥创建一个密钥配置，如下所示：

1. 登录到 AWS 管理控制台，进入密钥管理服务。

2. 从左侧边栏点击客户管理密钥，然后点击页面右上角的创建密钥。

3. 在配置密钥步骤中，对于密钥类型，选择对称密钥，对于密钥用途，选择加密和解密。

4. 展开高级选项菜单，选择外部（导入密钥材料）。然后，勾选复选框表示你理解使用外部密钥时的安全性和持久性影响。对于区域性，选择单区域密钥。点击下一步进入添加标签步骤。

5. 在添加标签步骤中，将别名设置为seccb-dev-external-key，将描述设置为开发环境的外部密钥。可选地，通过点击添加标签按钮来添加标签。点击下一步进入定义密钥管理权限步骤。

6. 在定义密钥管理权限步骤，选择密钥管理员，即可以通过 KMS API 管理此密钥的 IAM 用户和角色。我选择了awsseccb_admin1用户，如图 3.3所示。如果您使用的是 IAM 身份中心用户，您可以选择一个角色，该角色对应于该 IAM 身份中心用户与权限集的组合。

7. 对于密钥删除，选中允许密钥管理员删除此密钥。点击下一步进入定义密钥使用权限步骤。

8. 关于定义密钥使用权限步骤，选择密钥用户——即可以使用客户管理密钥进行加密和解密数据的 IAM 用户和角色。在同一步骤中，您可以选择性地添加可以使用此密钥的其他 AWS 账户。我选择了awsseccb_user1用户。如果您使用的是 IAM 身份中心用户，可以选择一个角色，该角色对应于该 IAM 身份中心用户与权限集的组合。点击下一步。

9. 审查密钥配置、别名和描述、标签以及密钥策略的 JSON 格式。点击完成以创建密钥。密钥将如图 3.4所示创建。您现在应该还会看到下载包装公钥和导入令牌步骤。

10. 关于下载包装公钥和导入令牌步骤，在配置部分，对于选择包装密钥规格，选择RSA_4096 - 推荐，对于选择包装算法，选择RSAES_OAEP_SHA_256。

图 3.5 – 下载包装公钥和导入令牌

1. 点击下载包装公钥和导入令牌将令牌下载到您的桌面。然后，点击下一步进入上传您的包装密钥材料页面。保留下载的导入参数文件，以便我们接下来的步骤使用。

在本节中，我们创建了一个密钥配置。在下一节中，我们将生成我们的密钥材料，然后返回此页面并点击下一步进入上传您的包装密钥材料步骤。如果我们查看客户管理密钥页面，我们应该看到状态现在设置为待导入。

使用 OpenSSL 生成密钥材料

假设我们已经按照准备工作部分设置了 OpenSSL，我们可以按照以下步骤生成密钥材料并使用 AWS KMS 在上一节中提供的包装密钥对其进行加密：

1. 由于我们使用的是对称密钥，我们可以使用以下命令生成 256 字节的随机数据并将其保存到名为MyExternalKeyMaterial.bin的文件中。这将作为我们的密钥材料：

   openssl rand -out ExternalKeyMaterialPlaintext.bin 32
   

   这将生成一个名为ExternalKeyMaterialPlaintext.bin的文件。

2. 在相同的文件夹中执行以下命令，并为inkey参数提供我们包装密钥的名称：

   openssl pkeyutl -encrypt -in ExternalKeyMaterialPlaintext.bin -out ExternalKeyMaterialEncrypted.bin -inkey WrappingPublicKey.bin -keyform DER -pubin -pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256 -pkeyopt rsa_mgf1_md:sha256
   

   这将生成一个名为ExternalKeyMaterialEncrypted.bin的文件。

通过这个，我们已经生成了密钥材料。在接下来的部分，我们将把这些密钥材料上传到 AWS。

从管理控制台继续创建密钥

我们可以按以下方式在 AWS 管理控制台上传我们的密钥材料：

1. 返回到控制台中上传已包装的密钥材料步骤的页面。这是我们在为外部密钥创建密钥配置部分中停止的地方。

2. 如果我们不在上传已包装的密钥材料步骤的页面上，我们可以通过仪表板进入密钥管理服务，点击左侧边栏中的客户管理的密钥，然后点击我们为其下载了包装密钥的密钥下的别名超链接。进入密钥材料标签并点击导入密钥材料。然后，点击下一步进入上传已包装的密钥材料步骤的页面。

3. 在上传已包装的密钥材料步骤的页面，点击选择文件，然后在包装密钥材料下选择ExternalKeyMaterialEncrypted.bin文件。

4. 点击选择文件，然后在导入令牌下选择我们在前一部分从 KMS 下载的导入令牌。

5. 保留密钥材料到期 - 可选选项未勾选，然后点击上传密钥材料。我们应该会看到一个消息，提示密钥已上传。

   密钥现在已经可以使用。如果我们检查客户管理的密钥页面，我们应该看到状态已从待导入变为启用。

它是如何工作的...

在这个食谱中，我们通过将密钥材料来源设置为外部创建了一个 AWS KMS 密钥。之后，我们选择了一个允许的加密方案来包装密钥并下载了密钥包装器。这个密钥包装器是用来加密并安全上传我们的密钥材料到 AWS KMS 服务的公钥。我们还下载了一个来自 AWS KMS 服务的导入令牌，连同密钥包装器一起。导入令牌用于确保上传的密钥是我们为包装令牌下载的正确密钥。

还有更多...

在这个食谱中，我们在上传外部密钥材料之前，使用SHA_256对其进行包装。我们也可以使用SHA_1，但它的安全性较差。如果我们使用 SHA-1，我们可以使用以下命令生成加密的外部密钥材料，ExternalKeyMaterialEncrypted.bin：

 openssl pkeyutl -encrypt –in ExternalKeyMaterialPlaintext.bin -out ExternalKeyMaterialEncrypted.bin -inkey WrappingPublicKey.bin -keyform DER -pubin -pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha1

让我们快速浏览一些关于将密钥导入 AWS KMS 的更多细节：

• 当我们导入密钥材料时，我们需要根据安全要求生成具有随机性的密钥材料。我们还需要对密钥材料的持久性负责。

• 使用导入的密钥材料，我们可以为密钥材料设置到期日期，也可以手动删除它。我们可以通过将密钥材料导入 KMS 密钥的方式在未来重新启用该密钥。

• 我们不能删除具有 AWS 密钥材料的 KMS 密钥。然而，我们可以在 7 到 30 天的通知期内安排删除该 KMS 密钥。

• 一旦 KMS 密钥被删除，通过该密钥加密的任何数据都无法解密。这对于 AWS 密钥材料的 KMS 密钥和导入密钥材料的 KMS 密钥都适用。

• 导入到 KMS 密钥中的密钥材料将永久与该 KMS 密钥关联。

• 我们可以重新导入密钥材料。然而，我们不能再次导入不同的密钥材料到该 KMS 密钥。

• 使用具有外部密钥材料的 KMS 密钥加密的密文无法通过另一个 KMS 密钥解密，即使我们使用相同的密钥材料。

• 必须先删除带有导入密钥材料的 KMS 密钥，然后才能将密钥材料重新导入到另一个 KMS 密钥中。

• 如果密钥材料被删除，我们可以将密钥材料重新导入到现有的 KMS 密钥中。

• 在影响 KMS 密钥的区域性故障情况下，AWS 不会自动恢复任何导入的密钥材料。在这种情况下，我们需要拥有密钥材料的副本以便重新导入。

另见

您可以在以下博客文章中阅读更多关于外部密钥和 BYOK 的信息：www.cloudericks.com/blog/aws-kms-with-external-key-material-the-byok-solution。

在 KMS 中轮换密钥

密钥轮换是指更改用于保护数据的加密密钥的过程。这一做法对于在密钥被泄露时最小化风险至关重要。AWS 支持客户管理密钥的自动和手动密钥轮换。

定期轮换密钥是一项最佳实践，在使用密钥时需要遵循。根据监管规则或公司政策，密钥轮换也可能是一个要求。这些规则和政策可能还会提供有关密钥轮换频率的指导。我们将在本食谱中查看密钥轮换的不同情况。

准备工作

为了完成这个食谱，我们需要以下内容：

• 一个有效的 AWS 账户，awsseccb-sandbox-1，和一个用户，awsseccbadmin1，如技术要求部分所述。

• 一个具有 AWS 密钥材料的客户管理的 KMS 密钥。我将使用我们在创建 KMS 密钥食谱中创建的别名为seccb-dev-encryption的密钥。

如何操作……

我们可以为具有 AWS 密钥材料的客户管理的 KMS 密钥指定每年（365 天）的自动密钥轮换，如下所示：

1. 登录到 AWS 管理控制台，并转到密钥管理服务。

2. 在导航窗格中点击客户管理的密钥，列出我们创建的所有密钥。

3. 点击我们需要进行轮换的客户管理密钥的别名或密钥 ID属性。

4. 转到密钥轮换选项卡并点击编辑。

5. 对于密钥轮换，选择启用并设置轮换周期（天数），其值为365，如下面的图所示：

图 3.6 – 自动密钥轮换

1. 点击保存。我们将收到操作成功的通知。

至此，我们已经学会了如何启用自动密钥轮换。我们将在本方案的后续部分进一步学习密钥轮换。

工作原理...

AWS 管理的密钥每年会自动轮换一次，之前是每 3 年轮换一次。对于客户管理的密钥，AWS 支持自动和手动两种密钥轮换方式。在自动轮换模式下，只有 KMS 密钥的支持密钥会进行轮换。这意味着 KMS 密钥的 ID、ARN、区域、策略、权限和其他属性保持不变。因此，我们不需要更改使用此 KMS 密钥的应用程序或别名。

在这个方案中，我们选择了每年自动轮换 KMS 密钥的选项。AWS 现在每年轮换一次密钥，并保留旧的支持密钥的副本，用于解密使用旧支持密钥加密的数据。AWS 会保留较旧的支持密钥，直到我们删除它们。

还有更多内容...

让我们快速回顾一下与 AWS KMS 密钥轮换相关的一些重要点：

• 每年（365 天）自动轮换密钥仅适用于具有 AWS 密钥材料的 KMS 密钥。

• 如果我们希望密钥轮换有不同的周期，可以手动轮换带有 AWS 密钥材料的 KMS 密钥。

• 在自动密钥轮换中，只有 KMS 密钥会被轮换，而与其加密的数据密钥不会被轮换。

• 在自动密钥轮换中，新的加密操作会使用新的支持密钥。然而，使用旧支持密钥加密的数据会用该旧密钥进行解密。为此，AWS 会保留所有支持密钥，直到我们删除 KMS 密钥。

• 在自动密钥轮换中，即使我们禁用了密钥轮换，旧的支持密钥仍然可用来解密使用该密钥加密的数据。

• 使用自动密钥轮换时，如果禁用轮换并重新启用，它将继续使用旧的密钥轮换计划（如果支持密钥不到一年）。如果支持密钥已经超过 365 天，它将立即进行轮换，然后每 365 天再轮换一次。

• 在自动密钥轮换中，如果密钥处于待删除状态，则不会发生密钥轮换。如果取消删除操作，则如果支持密钥不到一年，它将继续使用旧的密钥轮换计划。如果支持密钥超过 365 天，则会立即进行轮换，并且每 365 天进行一次轮换。

• 对于由 AWS CloudHSM 集群支持的自定义密钥存储，不支持自动密钥轮换。对于这样的 KMS 密钥，Origin 字段的值为 AWS_CloudHSM。在这种情况下，我们需要手动轮换密钥，并更改任何加密数据或别名以使用新密钥。

• 对于 AWS 管理的密钥，我们无法更改轮换频率，目前为 1 年。

• 自动密钥轮换可以通过 EventBridge 中的 KMS 密钥轮换事件进行监控。

• 我们可以使用 AWS KMS API 启用和禁用自动密钥轮换。在手动密钥轮换时，使用别名来引用 KMS 密钥是一种良好的实践。我们可以更新别名，使其指向新的目标 KMS 密钥，而不是旧的密钥。

• 即使是手动轮换，AWS KMS 也能识别用于加密的正确密钥并用于解密，只要我们保留旧的 KMS 密钥。

• 我们可以使用 AWS KMS API 的 update-alias 子命令来更新别名。

另请参见

你可以阅读更多关于 AWS KMS 密钥轮换的内容，包括手动密钥轮换，访问 www.cloudericks.com/blog/understanding-aws-kms-key-rotation。

通过授权编程方式授予权限

KMS 授权可用于为 AWS KMS API 操作（如加密、解密、描述密钥等）提供临时细粒度的权限。我们可以使用授权向某个账户中的用户或甚至另一个账户中的用户提供访问权限。在这个配方中，我们将授权一个用户，使其能够使用 AWS KMS 加密和解密文件。

准备工作

我们需要以下内容来完成这个配方：

• 一个有效的 AWS 账户，其中有两个用户：一个具有AdministratorAccess权限的用户和一个没有权限的用户。这些用户的 CLI 配置文件应已配置好。我将分别称这些用户及其 CLI 配置文件为Adminuserprofile和testusernopermission，按照 第一章 中的配方。

• 一个 KMS 密钥。我们可以通过遵循本章之前的配方来创建一个。或者，可以使用以下命令通过 AWS CLI 创建 KMS 密钥：

  aws kms create-key --profile Adminuserprofile
  

  这将提供类似于以下的输出：

图 3.7 – 使用 CLI 创建密钥

在继续之前，我们必须通过运行以下命令检查我们的测试用户是否拥有任何权限。确保将我的 key-id 替换为你的 key-id：

 aws kms encrypt --plaintext "$(echo -n 'hello heartin' | base64)" --key-id ea7136c3-7d8a-4ed4-89cc-4ca0af7d6958 --profile testusernopermission

我们应该会收到类似于以下截图中的错误信息：

图 3.8 – 用户权限检查的响应

在前面的命令中，我们可以仅指定密钥 ID（如我们所做的），也可以指定完整的密钥 ARN，或使用别名（如果有的话）。

接下来，我们将学习如何使用授权，以便我们可以通过编程方式授予权限。

如何操作...

我们可以授予 testuser 加密权限，然后按如下方式使用它进行加密：

1. 我们可以从 IAM 控制台获取用户的 ARN，或者根据前面的格式准备一个。我们还可以使用 aws iam get-user 命令从控制台获取用户的 ARN：

   aws iam get-user --user-name testuser --profile Adminuserprofile
   

   此命令将返回类似于以下的响应：

图 3.9 – 获取用户命令的响应

1. 使用create-grant子命令为testuser授予Encrypt权限，提供用户的 ARN：

   aws kms create-grant --key-id ea7136c3-7d8a-4ed4-89cc-4ca0af7d6958 --grantee-principal arn:aws:iam::201882936474:user/testuser --operations "Encrypt" --profile Adminuserprofile
   

   我们应该获得类似以下截图所示的响应：

图 3.10 – create-grant子命令的响应

1. 使用testuser通过encrypt子命令加密数据：

   aws kms encrypt --plaintext "$(echo -n 'hello heartin' | base64)" --key-id ea7136c3-7d8a-4ed4-89cc-4ca0af7d6958 --profile testusernopermission
   

   这一次，我们应该获得如下所示的成功响应：

图 3.11 – 获取权限后加密命令的响应

1. 使用list-grants子命令验证密钥的授权：

   aws kms list-grants --key-id ea7136c3-7d8a-4ed4-89cc-4ca0af7d6958 --profile Adminuserprofile
   

   这应该返回一个类似以下的响应：

图 3.12 – list-grant命令的响应

1. 使用revoke-grant子命令撤销授权：

   aws kms revoke-grant --key-id ea7136c3-7d8a-4ed4-89cc-4ca0af7d6958 --grant-id e6579fcfec8d84ce9a48398a5e33466de47b75e06f99b4e1edd178914c559bb5 --profile Adminuserprofile
   

2. 我们可以通过尝试使用testuser加密，并运行list-grants子命令来验证授权是否已被撤销。运行encrypt命令，类似于此示例中的第 2 步。我们现在应该获得一个类似以下的错误消息：

图 3.13 – 撤销权限后加密命令的响应

1. 运行list-grant子命令，类似于此示例中的第 3 步。我们现在应该获得类似以下的响应：

图 3.14 – 撤销所有授权后的list-grant命令响应

同样，我们可以为其他操作授予权限。

它是如何工作的...

在这个示例中，我们使用aws kms CLI 命令的create-grant子命令授予了用户权限。我们验证了在授权之前，用户无法执行加密操作。我们验证了授权之后，用户可以执行加密操作。

然后，我们使用aws kms CLI 命令的revoke-grant子命令撤销了授权。我们还使用了其他子命令，如list-grants来列出特定密钥 ID 的授权，以及encrypt来加密明文数据。

还有更多内容...

在这个示例中，我们只为一个操作授予了权限。我们可以为多个操作授予权限，如下所示：

 aws kms create-grant --key-id 1ab77c7a-7ca4-4387-a4c5-2fba3cb5c0f5 --grantee-principal arn:aws:iam::135301570106:user/testuser --operations "Encrypt" "Decrypt" --profile Adminuserprofile

让我们快速浏览一些与授权和撤销权限相关的重要概念：

• 支持的授权操作包括Encrypt、Encrypt、Encrypt、Encrypt、Encrypt、Encrypt、Encrypt、RetireGrant和DescribeKey。

• 我们可以使用 AWS KMS API 的encrypt子命令，通过密钥将明文转换为密文。

• 我们可以使用 AWS KMS API 的 decrypt 子命令，在加密时使用的相同密钥的帮助下，将密文转换为明文。

• 我们可以使用 AWS KMS API 的 re-encrypt 子命令，在服务器端使用新的 CMK 解密并重新加密数据，而无需在客户端暴露明文。此子命令还可以用来更改密文的加密上下文。

• 加密上下文是一组可选的附加键值对，作为额外的身份验证检查。用于加密的相同加密上下文需要在解密和重新加密时使用。由于加密上下文不是秘密信息，它将以明文形式出现在 AWS CloudTrail 日志中，因此对于监控和审计加密操作非常有用。

• 授权是密钥策略的替代方案。

• 在同一账户内，我们可以使用密钥 ID 或密钥 ARN 与 create-grant 子命令。对于其他账户的用户，需指定 ARN。

• create-grant 子命令具有一个约束参数，接受加密上下文。

• 当我们创建授权时，由于 AWS 遵循最终一致性模型，权限可能不会立即反映出来。通过在后续请求中使用从 create-grant 子命令接收到的授权令牌，我们可以避免由于最终一致性导致的延迟。

• list-grants 子命令用于列出某个密钥的所有授权，并提供附加的 starting-token、page-size 和 max-items 参数，用于分页结果。

• AWS CLI 分页参数 starting-token、page-size 和 max-items 的功能如下：

  • max-items 参数指定 API 需要返回的最大项目数量。

  • 如果 API 调用返回的结果超过了 max-items 所指定的数量，则响应中会提供 NextToken，需要将其作为 starting-token 传递到下一次请求中。

  • page-size 参数指定单次 API 调用中要检索的最大元素数。例如，如果 page-size 为 10 且 max-items 为 100，则后台会发起 10 次 API 调用，并返回 100 个项目。

• revoke-grant 子命令可以由创建该授权的账户的根用户、授权的 RetiringPrincipal 或被授予该授权进行 RetireGrant 操作的 GranteePrincipal 运行。

• AWS 文档建议，在清理时，当我们不再使用授权时，通过 retire-grant 子命令撤销该授权。然而，当我们有意拒绝依赖该授权的操作时，应使用 revoke-grant 子命令撤销授权。

• list-retirable-grants 子命令可以用来列出所有具有指定 RetiringPrincipal 的授权。

• list-retirable-grants子命令提供了limit和marker参数，用于限制需要返回的可重试授权。这里，limit是需要返回的最大项数，而marker是上次请求返回的NextMarker的值，当需要返回的项数超过limit参数所指定的数目时使用。

另见

要了解 AWS KMS 中的授权基础，请参考这篇博客文章：www.cloudericks.com/blog/understanding-grants-in-aws-kms。

使用带条件密钥的密钥策略

在这个示例中，我们将学习如何使用密钥策略，特别是带条件的密钥策略。KMS 密钥的基于资源的策略被称为密钥策略。管理 KMS 资源的访问时，我们可以单独使用密钥策略，也可以将 IAM 策略和授权与密钥策略一起使用。与其他基于资源的策略（如桶策略）不同，密钥策略是强制性的，用于管理和使用密钥。当密钥被创建时，AWS 会自动创建一个默认的密钥策略，就像我们在创建 KMS 密钥示例中看到的那样。

准备中

我们需要以下内容来完成这个示例：

• 一个有效的 AWS 账户，awsseccb-sandbox-1，和一个用户，awsseccbadmin1，如技术要求部分所述。

• 在us-east-1区域创建一个 S3 桶。我将使用一个名为awssecuritykmsbucket的桶。

如何操作……

我们可以通过以下方式演示如何使用带条件密钥的密钥策略：

1. 使用控制台的默认配置创建密钥，如下所示：

   1. 转到管理控制台中的密钥管理服务（KMS）。

   2. 从左侧边栏选择客户管理的密钥并点击创建密钥。

   3. 在配置密钥面板中，选择密钥类型下的对称。然后，在密钥使用下选择加密和解密。点击下一步。

   4. 提供别名和描述值，保持其他选择不变，然后点击下一步。

   5. 在下一个屏幕上，不要添加任何密钥管理员。相反，直接点击下一步。

   6. 在定义密钥使用权限面板中，也不要添加任何密钥用户。直接点击下一步。

   7. 此时，我们应该看到如下图所示的策略。请审阅并点击完成：

图 3.15 – 密钥策略审核

1. 我们可以按照以下方式，将此 KMS 密钥添加为同一区域内 S3 桶的加密密钥：

   1. 转到我们 S3 桶的属性标签页。

   2. 向下滚动到默认加密并点击编辑。

   3. 在默认加密面板中，选择加密类型下的使用 AWS 密钥管理服务（KMS）密钥的服务器端加密（SSE-KMS）。

   4. 在AWS KMS 密钥下，输入我们创建的密钥的 ARN。

   5. 对于Bucket Key，选择禁用。

   6. 点击保存更改。

图 3.16 – 为 S3 存储桶添加加密密钥

1. 将文件上传到 S3，并验证加密和解密是否正常工作：

   1. 将文件上传到 S3 存储桶中。

   2. 点击该文件，然后点击打开。我们应该能查看文件的内容。

图 3.17 – 查看 S3 存储桶内容

1. 通过添加密钥策略声明来拒绝 S3 服务的密钥使用：

   1. 在管理控制台中转到 密钥管理服务。

   2. 点击客户管理的密钥。

   3. 点击我们需要修改的密钥。

   4. 点击密钥策略选项卡。

   5. 点击切换到策略视图。

   6. 点击编辑，添加以下密钥策略声明并确保逗号正确，然后点击保存更改。

    {
       "Effect": "Deny",
       "Principal": {
           "AWS": "arn:aws:iam::135301570106:root"
       },
       "Action": [
           "kms:Encrypt",
           "kms:Decrypt",
   "kms:ReEncrypt*",
           "kms:GenerateDataKey*",
           "kms:CreateGrant",
           "kms:ListGrants",
           "kms:DescribeKey"
       ],
       "Resource": "*",
       "Condition": {
           "StringEquals": {
               "kms:ViaService": "s3.us-east-1.amazonaws.com"
           }
       }
   }
   

2. 回到我们在步骤 3中打开的相同文件，点击打开以打开文件。现在我们将无法查看文件，并将收到以下错误。这是因为 S3 没有权限使用密钥执行解密操作：

图 3.18 – 尝试查看 S3 存储桶内容时发生的错误

如果我们直接在浏览器中运行 URL，而不从 S3 控制台点击打开，则无论是否有密钥条件策略，由于使用了 SSE-KMS 加密，文件将无法显示。

它是如何工作的...

在本食谱中，我们创建了一个具有默认权限的密钥，并尝试使用该密钥对 S3 存储桶中的文件进行加密和解密。我们成功地完成了加密和解密操作。然后，我们为 S3 服务使用 kms:ViaService 条件密钥添加了显式的拒绝，并再次尝试解密相同的文件。这一次，我们无法解密。

正如我们在本食谱的步骤 1中看到的，默认的密钥策略为所有者账户的根用户提供完全权限，并启用访问 KMS 密钥所需的 IAM 策略。它还允许密钥管理员管理 KMS 密钥，并允许密钥用户使用 KMS 密钥。此外，我们在使用 ViaService API 时，需要指定 S3 服务的区域。我使用了us-east-1，因为我的存储桶位于 us-east-1。

在我们的密钥策略 JSON 中，我们使用了以下元素：

• Effect ：指定是否允许或拒绝权限。

• Principal ：指定谁获得权限。允许的值包括 AWS 账户（根账户）、IAM 用户、IAM 角色和支持的 AWS 服务。

• Action ：指定要允许或拒绝的操作（例如，kms:Encrypt）。

• Resource ：指定应用策略的资源。我们使用 * 来表示所有资源。

• Condition ：用于指定密钥策略生效的任何条件。这是一个可选元素。

我们还可以指定一个可选的 Sid 参数。Sid 代表 语句标识符，可以包含描述我们策略的字符串值。

还有更多...

让我们快速了解一些关于使用密钥策略的重要概念：

• 为了管理 KMS 资源的访问，我们可以单独使用密钥策略，也可以将 IAM 策略和授权与密钥策略一起使用。

• 为了允许访问 KMS 密钥，我们始终需要使用密钥策略，可以单独使用，或者与 IAM 策略或授权一起使用。

• KMS 中的主要资源是 KMS 密钥。

• KMS 密钥的 ARN 具有以下形式：arn:aws:kms:<region>:<accountID>:key/<key ID>。

• 一些 KMS 操作还允许使用别名作为资源。别名 ARN 具有以下形式：arn:aws:kms:<region>:<accountID>:alias/<alias name>。

• 任何用户，包括根用户，都可以访问 KMS 密钥，但前提是密钥策略允许。

• 从管理控制台创建 KMS 密钥时，默认的密钥策略会将完全权限授予所有者账户的根用户，并启用访问 KMS 密钥所需的 IAM 策略。它还将允许密钥管理员管理 KMS 密钥，并允许密钥用户使用 KMS 密钥。从程序方式创建 KMS 密钥时，默认的密钥策略将完全权限授予所有者账户的根用户。它还启用访问 KMS 密钥所需的 IAM 策略。

• 当我们添加密钥管理员或密钥用户时，他们会被添加到策略文档语句中，并授予所需的权限。我们在 创建 KMS 密钥 配方中看到了密钥管理员和密钥用户的完整权限列表。

• AWS 在一些默认权限中添加了通配符，例如 kms:Create*、kms:Describe* 等，以便如果 AWS 创建一个新的以相同前缀开头的操作，管理员或用户将自动获得这些权限。

• AWS 提供了全局条件密钥以及特定服务的密钥。

• 全局条件密钥包括 aws:PrincipalTag、aws:PrincipalTag、aws:PrincipalTag、aws:PrincipalTag、aws:PrincipalTag、aws:PrincipalTag、aws:PrincipalTag、aws:PrincipalTag、aws:userid 和 aws:username。

• AWS KMS 条件密钥包括 kms:BypassPolicyLockoutSafetyCheck、kms:BypassPolicyLockoutSafetyCheck、kms:BypassPolicyLockoutSafetyCheck、kms:BypassPolicyLockoutSafetyCheck、kms:BypassPolicyLockoutSafetyCheck、kms:BypassPolicyLockoutSafetyCheck、kms:BypassPolicyLockoutSafetyCheck、kms:BypassPolicyLockoutSafetyCheck、kms:BypassPolicyLockoutSafetyCheck、kms:BypassPolicyLockoutSafetyCheck、kms:BypassPolicyLockoutSafetyCheck、kms:BypassPolicyLockoutSafetyCheck、kms:BypassPolicyLockoutSafetyCheck、kms:BypassPolicyLockoutSafetyCheck、kms:WrappingAlgorithm 和 kms:WrappingKeySpec。

另请参见

• 你可以在这里阅读更多关于 AWS KMS 密钥策略的内容：www.cloudericks.com/blog/understanding-key-policies-in-aws-kms。

• 你可以在这里阅读关于密钥策略和授权之间的区别：www.cloudericks.com/blog/understanding-aws-kms-key-policies-vs-grants。

• 你可以在这里阅读更多关于 AWS KMS 条件密钥的内容：www.cloudericks.com/blog/understanding-aws-kms-condition-keys。

• 你可以在这里阅读更多关于 AWS 中的策略和权限的内容：www.cloudericks.com/blog/demystifying-aws-policies-and-permissions。

跨账户共享客户管理的密钥

在这个操作中，我们将学习如何在一个账户中使用来自另一个账户的 KMS 密钥。

准备工作

我们需要以下内容来完成此操作：

• 两个工作中的 AWS 账户。我将使用我们在第一章中创建的账户，第一个账户的账户 ID 为135301570106，第二个账户的账户 ID 为380701114427。

• 账户 2 中拥有AdministratorAccess权限的用户。这可以是一个 IAM 用户或一个 IAM 身份中心用户。CLI 配置文件应为该用户配置。我将称这个 CLI 配置文件为Adminuserprofile。

• 另一个没有管理员权限的账户 2 用户。CLI 配置文件应为该用户配置。我将称这个用户及其 CLI 配置文件为Testuserprofile。

如何操作...

首先，我们将在第一个账户中创建一个新的 KMS 密钥。然后，我们将授权第二个账户使用它。最后，我们将使用该 KMS 密钥从第二个账户测试第一个账户。

创建密钥并授权给另一个账户

在本节中，我们将在账户 1 中创建一个密钥，并赋予账户 2 密钥使用权限。让我们开始吧：

1. 登录到 AWS 管理控制台并进入密钥管理服务。

2. 从左侧边栏点击客户管理的密钥，然后在页面右上角点击创建密钥。

3. 在配置密钥窗格中，选择密钥类型为对称，选择密钥使用为加密和解密。然后点击下一步。

4. 在添加标签窗格中，提供别名和描述值。点击下一步。

5. 在定义关键管理权限屏幕上，如果需要，我们可以添加任何密钥管理员，并勾选允许密钥管理员删除此密钥的复选框。然后点击下一步。

6. 在定义密钥使用权限屏幕上，向下滚动到其他 AWS 账户部分，然后点击添加另一个 AWS 账户，如下面的图所示：

图 3.19 – 其他 AWS 账户部分

1. 输入第二个 AWS 账户的账户 ID，然后点击下一步。

图 3.20 – 添加其他 AWS 账户

1. 在审查页面，审查密钥策略详细信息并点击完成。已添加到密钥策略中的声明可以在代码文件中找到，文件名为key-policy-sharing-keys.json。

2. 一旦收到密钥创建成功的消息，点击查看密钥以查看密钥的详细信息。我的新创建的密钥的 ARN 如下：

   arn:aws:kms:us-east-1:201882936474:key/24ce962a-ee5e-411e-9cb6-ebbee39e253c
   

在本节中，我们在账户 1 中创建了一个密钥，并授予账户 2 权限。在下一节中，我们将在账户 2 中使用此密钥。

以来自账户 2 的管理员用户身份使用该密钥

现在，让我们尝试以来自账户 2 的管理员权限用户身份使用该密钥。

使用以下命令，通过账户 2 中的管理员用户配置文件在 CLI 中加密数据：

 aws kms encrypt --plaintext "$(echo -n 'hello heartin' | base64)" --key-id arn:aws:kms:us-east-1:201882936474:key/24ce962a-ee5e-411e-9cb6-ebbee39e253c --profile Adminuserprofile

我们应该看到以下响应：

图 3.21 – 运行加密命令后，管理员用户的响应

在下一节中，我们将以来自账户 2 的非管理员用户身份使用该密钥。

以来自账户 2 的非管理员用户身份使用该密钥

在继续之前，我们可以通过使用非管理员用户配置文件运行上一节中步骤 1 显示的命令，验证非管理员用户是否没有权限加密账户 1 中的数据。现在，按照以下步骤操作：

1. 要将 KMS 密钥作为非管理员用户使用，账户 2 的根用户或管理员用户必须将权限委托给非管理员用户。为此，他们必须执行以下步骤：

   1. 转到账户 2 的IAM仪表盘。

   2. 点击左侧面板中的策略。

   3. 点击创建策略。

   4. 转到JSON标签。

   5. 输入以下策略。确保更新Sid值和Resource参数，以反映您的资源详细信息：

    {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "DelegateCMKAccessFrom201882936474",
               "Effect": "Allow",
               "Action": [
                   "kms:Encrypt",
                   "kms:Decrypt",
                   "kms:ReEncrypt*",
                   "kms:GenerateDataKey*",
                   "kms:DescribeKey"
               ],
               "Resource": "arn:aws:kms:us-east-1:201882936474:key/24ce962aee5e-411e-9cb6-ebbee39e253c"
           }
       ]
   }
   

   1. 点击下一步。

   2. 在审查并创建面板中，针对策略详细信息，为我们的策略提供名称和描述详细信息。

   3. 点击创建策略。

   4. 如果您使用的是 IAM 用户，请将此策略直接分配给该 IAM 用户或该用户所在的组。如果您使用的是 IAM 身份中心用户，您可以使用自定义权限集分配此策略，正如我们在第二章的在 IAM 身份中心中创建客户管理的策略示例中所看到的那样。

2. 使用以下命令，通过账户 2 的非管理员用户配置文件在 CLI 中加密数据：

   aws kms encrypt --plaintext "$(echo -n 'hello heartin' | base64)" --key-id arn:aws:kms:us-east-1:201882936474:key/24ce962a-ee5e-411e-9cb6-ebbee39e253c --profile testprofilenopermission
   

   我们应该看到以下响应：

图 3.22 – 运行加密命令后，非管理员用户的响应

在这个示例中，我们创建了一个新的 KMS 密钥。我们也可以编辑现有的 KMS 密钥，并添加另一个账户的详细信息。

它是如何工作的...

在本教程中，我们在账户 1 中创建了一个 KMS 密钥，并为账户 2 授予了权限。之后，我们成功地通过管理员用户的配置文件从 CLI 对另一个账户的数据进行了加密。要使用非管理员用户进行加密，账户 2 的管理员用户需要将权限委托给需要访问的用户或角色。我们通过 IAM 策略完成了这一步骤。

有关策略文档结构的更多详细信息，请参考使用带条件的密钥的密钥策略教程。

还有更多内容...

在本教程中，我们尝试通过 AWS CLI 对数据进行加密。尽管大多数集成服务（如 S3 和 EC2）支持跨账户委托密钥权限，但它们可能不支持在控制台中自动选择密钥。请查看每个服务的文档以获取更多详情。如果在管理控制台中存在限制，则需要通过 API 并指定密钥的 ARN 来完成此操作。

另请参见

本章中，我们探讨了 AWS KMS 的许多功能。KMS 在 AWS 云中有许多应用和集成，如 S3 加密、EBS 加密等。包括所有这些应用和集成需要一本专门讲解 KMS 的书。您可以在www.cloudericks.com/blog/applications-of-aws-kms-within-aws-cloud上探索更多关于 KMS 在 AWS 云中的应用和集成。

创建、初始化和激活 CloudHSM 集群

在本教程中，我们将创建一个 AWS CloudHSM 集群。CloudHSM 是 AWS 云上的专用硬件安全模块（HSM），我们可以用它来生成和使用加密密钥。而 AWS KMS 则使用共享 HSM。CloudHSM 非常适合那些要求最高隔离和控制的场景。

准备工作

完成本教程，我们需要以下资源：

• 一个有效的 AWS 账户，awsseccb-sandbox-1，以及一个用户，awsseccbadmin1，如技术要求部分所述。

• 了解 VPC 和 EC2。如果您是 EC2 的新手或想复习相关概念，可以先练习第五章中的教程，然后再回来完成本教程。

重要提示

与 AWS KMS 相比，AWS CloudHSM 通常会产生更高的费用，并且不提供免费层选项。对于那些出于教育或学习目的使用 CloudHSM 的人来说，至关重要的是在完成相关教程后立即删除已创建的资源。这一主动步骤有助于防止任何意外费用的产生。

如何操作...

首先，我们需要创建一个集群，初始化它，然后从与集群位于同一 VPC 中的 EC2 实例激活它。

创建 CloudHSM 集群

在本节中，我们将使用默认 VPC 创建一个 CloudHSM 集群，具体步骤如下：

1. 进入管理控制台中的CloudHSM服务。

2. 点击Create cluster。如果我们看不到Create cluster选项，可以点击左侧边栏中的Clusters，然后点击右侧窗格中的Create cluster。

3. 对于VPC，选择我们要使用的 VPC 或选择默认 VPC。此项设置之后无法更改。

提示

您也可以创建一个带有私有和公共子网的自定义 VPC，并使用它们替代我们在本章中使用的默认 VPC，尤其是在为生产环境配置 CloudHSM 时。我们将在第五章中深入讨论 VPC。

1. 根据 AWS 的建议，选择至少两个可用区中的子网。我为本例选择了三个子网，分别位于us-east-1a、us-east-1b和us-east-1c。

2. 向下滚动，在Cluster source下，选择Create a new cluster选项。点击Next进入Back-up retention步骤。我们还有一个Restore cluster from existingbackup选项。

3. 在Back-up retention步骤中，在Backup retention页面的Backup retention period (in days)字段中，根据您的需求，输入一个 7 到 379 天之间的期限。我输入的是7。点击Next进入Addtags步骤。

4. 在Add tags步骤中，可选地为集群添加标签以进行分类。然后，点击Next进入Review步骤。

5. 在Review页面查看详细信息，包括VPC、VPC、Days to expire under Back-up retention policy和Tags。我们还会看到一个警告，说明在集群创建后无法更改 VPC 或子网。

6. 审核后，点击Create cluster。我们应该会立即看到一条消息，说明集群正在创建中，状态为Creation in progress。集群创建完成可能需要几分钟。如果集群创建成功，我们将看到一条成功消息，状态为Uninitialised。

在本节中，我们创建了一个 CloudHSM 集群。接下来，我们需要初始化并激活集群。

初始化集群并创建我们的第一个 HSM

我们可以通过以下步骤初始化集群并创建我们的第一个 HSM：

1. 选择我们的集群，然后从Actions下拉菜单中点击Initialize。假设我们尚未创建任何 HSM，这将引导我们进入创建第一个 HSM 的向导。

2. 在Create HSM in the cluster步骤中，选择创建集群时选择的一个可用区并点击Create。

   创建 HSM 可能需要一些时间。此过程成功后，我们应该会进入Download certificate signing request步骤，并看到一条成功消息，如下图所示：

图 3.23 – 下载证书签名请求

1. 点击Cluster CSR按钮下载证书签名请求（CSR）。可选地，如图 3.23所示，我们可以通过遵循本食谱中的更多信息...部分和另见部分，验证集群 HSM 的身份和真实性。

2. 点击下一步进入上传证书步骤。

3. 通过在本地机器上运行openssl命令生成私钥，如下所示：

   openssl genrsa -aes256 -out customerCA.key 2048
   

   当提示时，输入并重新输入一个长度为 4 到 1,023 个字符的密码短语。

4. 由于这是用于测试和开发目的，我们可以通过运行以下命令，使用我们的私钥创建一个自签名证书：

   openssl req -new -x509 -days 3652 -key customerCA.key -out customerCA.crt
   

   在提示时回答问题，并提供与以下截图中显示的值类似的答案：

图 3.24 – 生成自签名证书

1. 使用 AWS 文档中提供的 OpenSSL 命令语法签署集群 CSR。记得提到您从 AWS 管理控制台下载的csr文件的准确名称，并在其所在文件夹中运行它：

   openssl x509 -req -days 3652 -in cluster-2i67czpb6yy_ClusterCsr.csr -CA customerCA.crt -CAkey customerCA.key -CAcreateserial -out cluster-2i67czpb6yy_ClusterCsr.crt
   

   这应该会创建一个名为cluster-2i67czpb6yy_ClusterCsr.crt的文件。

2. 回到本节步骤 5的上传证书页面，并上传签名的集群证书和签名证书（颁发证书）：

图 3.25 – 上传证书

1. 点击上传并初始化。我们应该立即看到集群初始化正在进行的消息。初始化完成后，我们将看到一条消息，说明我们必须在使用集群之前设置集群密码。我们需要在与 CloudHSM 集群相同 VPC 中的 EC2 实例上执行此操作。

2. 点击左侧边栏上的集群，并验证我们集群的状态是否设置为已初始化。

3. 我们还需要进入集群并复制我们 HSM 的ENI IP 地址值。

在本节中，我们初始化了集群并创建了第一个 HSM。在下一节中，我们将启动一个 EC2 客户端实例，放入与集群相同的 VPC 中并激活集群。

激活集群

在本节中，我们将从 AWS 管理控制台启动一个 EC2 客户端实例以为我们的 HSM 激活集群。请按照以下步骤操作：

1. 首先，我们需要启动一个 EC2 客户端实例，并设置以下选项：

   1. 在操作系统下选择Amazon Linux 2023。

   2. 在实例类型下选择t2.micro。

   3. 使用创建新密钥对链接来创建新密钥对，并安全保存私钥。我将其命名为ec2forhsm.pem。

   4. 在网络设置下，选择与我们集群相同的 VPC，在我的情况下是默认 VPC。自动分配公共 IP选项应设置为启用。在防火墙（安全组）子部分，选择选择现有安全组，对于常见安全组，选择默认安全组和我们 HSM 的安全组。

   5. 编辑安全组，添加一个入站规则以允许 SSH（端口范围 22）从我们连接的系统的 IP 地址进行访问，选择我的IP选项。

2. 将自签名证书customerCA.crt复制到 EC2 机器上。在 Mac 或 Linux 上，我们可以使用scp命令来完成，命令如下。记得使用你的 EC2公共 IPv4 DNS值替换我的值，它是ec2-user@ec2-54-172-128-95.compute-1.amazonaws.com：

   scp -i ec2forhsm.pem customerCA.crt ec2-user@ec2-54-172-128-95.compute-1.amazonaws.com:/home/ec2-user
   

3. SSH 进入 EC2 实例。不同操作系统的确切命令或步骤可能会有所不同。在 Mac 或 Linux 上，我们可以使用以下命令。如果遇到权限密钥权限问题，可以运行chmod 400 ec2forhsm.pem命令来解决：

   ssh -i "ec2forhsm.pem" ec2-user@ec2-54-172-128-95.compute-1.
   amazonaws.com
   

4. 运行sudo yumupdate命令更新操作系统。

5. 运行以下命令以获取最新的 CloudHSM 客户端 RPM：

   wget https://s3.amazonaws.com/cloudhsmv2-software/CloudHsmClient/Amzn2023/cloudhsm-cli-latest.amzn2023.x86_64.rpm
   

6. 运行以下命令以安装 CloudHSM 客户端：

   sudo yum install ./cloudhsm-cli-latest.amzn2023.x86_64.rpm
   

7. 将我们 HSM 的ENI IP 地址值添加到配置中。我们在前一节的步骤 12中提到过该值，初始化集群并创建我们的第一个 HSM。记得用你的 IP 替换我的 IP：

   sudo /opt/cloudhsm/bin/configure -a 172.31.33.71
   

8. 将自签名证书customerCA.crt复制到/opt/cloudhsm/etc/：

   sudo cp /home/ec2-user/customerCA.crt /opt/cloudhsm/etc/
   

9. 以交互模式运行 CloudHSM CLI：

   /opt/cloudhsm/bin/cloudhsm-cli interactive
   

10. 使用cluster activate命令设置初始管理员密码：

图 3.26 – 激活 CloudHSM 集群

1. 使用user list命令验证用户列表：

图 3.27 – 在集群中列出用户

1. 我们可以使用quit命令退出该工具。

2. 返回控制台中的集群，并验证是否没有显示一条消息，提示集群在更新密码之前无法使用。

在本节中，我们激活了我们的 HSM 集群。HSM 集群不属于免费套餐。因此，如果你创建该集群用于开发或测试目的，请记得删除 HSM 和集群，以避免产生意外费用。

它是如何工作的...

在这个步骤中，我们创建了一个 CloudHSM 集群，对其进行了初始化，然后在其中创建了我们的第一个 HSM。我为了方便使用了默认 VPC。对于实际应用场景，建议将 HSM 安装在自定义 VPC 中的私有子网内。我们将在第五章中详细讨论 VPC。

在初始化集群之前，我们需要下载 CSR 并签署它。我们在执行这些步骤时使用了自签名证书：

1. 使用 OpenSSL 创建私钥。

2. 使用私钥创建一个自签名的签名证书（发行证书）。

3. 使用自签名的签名证书（发行证书）签署我们从 AWS 管理控制台下载的 CSR。

4. 最后，将我们签名的 CSR 证书和自签发的发行证书上传到 AWS。

对于实际使用案例，应该由证书授权机构（例如 Verisign）签署它以创建一个签名证书。对于开发和测试目的，我们可以使用自签名证书并通过 OpenSSL 签署它，就像我们在本教程中看到的那样。

首先，我们以具有 PRECO 角色的用户身份登录系统，PRECO 是我们集群中第一个 HSM 上存在的临时用户角色。更改此用户的默认密码后，我们观察到其类型从 PRECO 变更为 CO。AU 类型的用户也存在。

在 CloudHSM 中，我们有四种主要的用户类型：

• 预加密管理员（PRECO）

• 加密管理员（CO）

• 加密用户（CU）

• 设备用户（AU）

PRECO 是 AWS 创建的用户角色，我们可以在更新密码之前使用它。更新密码后，用户类型会变更为 CO。我们可以创建更多 CO 角色的用户。第一个 CO 用户被称为主 PCO。CO 负责管理用户。CU 负责管理密钥，包括创建、删除、共享、导入和导出它们。CU 还负责执行加密操作，如加密、解密、签名、验证等。最后，AU 是权限有限的用户，通常由 AWS 用于克隆和同步活动。

还有更多内容…

我们可以使用可以从 AWS 下载的证书来验证 HSM 的身份。写本文时，可以从 CloudHSM 下载并验证六个证书：集群 CSR、HSM 证书、AWS 硬件证书、制造商硬件证书、AWS 根证书和制造商根证书。

另请参见

• 您可以在这里了解更多关于 CloudHSM 的内容：www.cloudericks.com/blog/getting-started-with-cloud-hsm。

• 您可以在这里了解更多关于 CloudHSM 与 KMS 之间的异同：www.cloudericks.com/blog/aws-cloudhsm-vs-aws-kms。

第四章：使用策略和技术保护 S3 数据

在本章中，我们将深入探讨如何保护Amazon 简单存储服务（S3），它是 AWS 平台上的对象存储。与传统的层次文件系统不同，对象存储基于键值原理，每个对象都有一个唯一的键作为标识符。可以将 S3 看作一个地方，每个数据项都有一个特殊的名称来帮助你找到它，而不是像常规的文件系统那样将文件分类到文件夹中。

我们已经在第二章的创建客户管理的 IAM 策略食谱中讨论了 IAM 策略及其在 S3 中保护数据的使用方法。接下来，我们将扩展这些知识，重点介绍如何使用访问控制列表（ACLs）和桶策略来确保 S3 数据安全。我们还将探索其他重要的 S3 数据保护方法，如使用 S3 的预签名 URL、加密、版本控制和复制等功能。

本章包括以下食谱：

• 创建 S3 桶策略

• 使用 S3 ACLs

• 创建 S3 预签名 URL

• 使用 S3 版本控制和对象锁定保护文件

• 对 S3 数据进行加密

技术要求

在深入本章的食谱之前，我们需要确保具备以下知识和要求：

• 由于 AWS 基于云的特性，稳定的互联网连接对于访问和管理服务至关重要。

• 我们需要一个有效的 AWS 账户来完成本章的大多数食谱，某些食谱可能需要多个 AWS 账户（如各自食谱中所提及）。

• 基础的 AWS 核心概念知识，以及对AWS 管理控制台、AWS CLI，尤其是 Amazon S3 的使用熟练度，将对我们有很大帮助。如果你是 S3 服务的新手，可以参考以下网址了解如何开始使用 S3：www.cloudericks.com/blog/getting-started-with-amazon-s3-on-aws-cloud

• 如果我们使用 IAM Identity Center 来管理用户而不是直接使用 IAM，掌握IAM Identity Center的知识，尤其是第一章和第二章的内容，会非常有帮助。

• 为了执行 AWS CLI 命令，我们需要安装AWS CLI v2。如果我们使用 IAM Identity Center 来管理用户，则还需要根据每个食谱的需要使用 AWS IAM Identity Center 进行配置。或者，如果我们使用 IAM 用户来执行任何食谱，则需要使用其访问密钥和秘密访问密钥来配置 CLI 配置文件。

重要提示

虽然可以直接使用 IAM 来管理用户，但 AWS 现在推荐尽可能使用 IAM Identity Center（原 AWS SSO）来增强安全性和便利性。

本书的代码文件可在github.com/PacktPublishing/AWS-Security-Cookbook-Second-Edition 获取。本章的代码文件可在github.com/PacktPublishing/AWS-Security-Cookbook-Second-Edition/tree/main/Chapter04 获取。

创建 S3 桶策略

之前，我们探讨了如何创建 IAM 策略。IAM 策略通常用于跨 AWS 服务的用户级权限，而桶策略则特定于单个 S3 桶，并提供更细粒度的桶级控制。例如，桶策略独特地支持授予匿名用户访问权限，默认强制服务器端加密（SSE），并根据源 IP 或 VPC 限制访问。

在本食谱中，我们将首先通过管理控制台使用策略生成器创建一个桶策略，允许每个人执行ListBucket和GetObject操作。然后，我们将通过 AWS CLI 创建一个桶策略，提供对特定 IAM 用户的访问权限。您可以使用管理控制台或 AWS CLI 中的任何一种策略；但是，我想展示这两种方法的实现。我还将在本食谱的更多内容部分提供主类型的示例。

准备工作

我们需要以下内容才能成功完成此操作：

• 一个有效的 AWS 账户至关重要。我将使用我们在第一章中创建的awsseccb-sandbox-1账户。不过，我将不使用 AWS Organizations 或 IAM 身份中心的任何功能。

• 具有AdministratorAccess权限的awsseccb_admin1用户也很重要。

• 我们还需要一个 S3 桶和其中的一个文件。我将使用名为awsseccbbucketpolicy的桶和名为image-cloudericks.png的文件。请将它们替换为您的桶名称和文件名。S3 桶应配置为取消选中所有公共访问，特别是与桶策略相关的设置。我们可以在创建桶时进行此设置，如图 4.1所示。对于其余设置，请保持默认值，在本书编写时，默认设置如下：

  • 已选择禁用 ACL（推荐）

  • 桶版本控制已设置为禁用

  • 默认加密已设置为使用 Amazon S3 管理的服务器端加密密钥（SSE-S3）

  • 桶密钥已设置为启用

  • 对象锁定（位于高级设置下）已设置为禁用

图 4.1 – 取消选中桶策略的设置

• 通过浏览器访问桶的https://<bucket-name>.s3.amazonaws.com 桶 URL，替换 <bucket-name> 为你的桶名称（例如，seccbbucket.s3.amazonaws.com/ ），验证桶不允许公开列出。

图 4.2 – 在开始操作前验证桶的访问权限

• 如在从 CLI 授予 IAM 用户 ListBucket 访问权限部分所述，若要使用 IAM 用户作为主体，我们需要一个没有权限的 IAM 用户，名为 awsseccb_user1。

• 如果我们希望执行涉及 CLI 命令的步骤，还需要为执行 CLI 命令设置一个环境，包含两个 CLI 配置文件：AwsSecCbAdmin 和 AwsSecCbUser，分别对应 awsseccb_admin1 和 awsseccb_user1 用户，具体配置请参考本章的技术要求部分。

接下来，我们将使用桶策略授予每个人列出我们桶内容的权限，然后重试此步骤。

如何操作...

我们将首先使用策略生成器从控制台生成策略，稍后将通过 CLI 执行该策略。

从控制台授予 ListBucket 和 GetObject 访问权限

我们可以通过以下方式授予公开访问权限以列出桶的内容：

1. 进入控制台中的S3服务，点击我们的桶名称，转到权限选项卡，然后点击桶策略。

2. 点击编辑，然后点击右上角的策略生成器。

3. 在AWS 策略生成器页面中，选择或输入以下数据：

   1. 对于选择策略类型，选择 S3桶策略。

   2. 对于效果，选择允许。

   3. 对于主体，输入 * 值。

   4. 对于AWS 服务，将选择 Amazon S3。

   5. 对于操作，选择 ListBucket。

   6. 对于Amazon 资源名称（ARN），从编辑桶策略页面复制并粘贴桶 ARN（例如，arn:aws:s3:::seccbbucket）。

图 4.3 – AWS 策略生成器页面

1. 点击添加声明。

2. 点击生成策略。

   生成的策略应类似于以下内容。

图 4.4 – 桶策略

1. 将策略复制到桶策略编辑器中，然后点击保存更改。

2. 在浏览器中，提供桶的 URL（例如，seccbbucket.s3.amazonaws.com）。此时，桶的内容应列出：

图 4.5 – 列出桶的内容

1. 在桶策略编辑器中，将 s3:ListBucket 改为 s3:GetObject，并在资源的末尾添加 /*（例如，"Resource": "arn:aws:s3:::seccbbucket/*"），然后点击保存更改**。

2. 从存储桶访问对象 URL，并将其粘贴到浏览器中。现在我们应该能够成功地检索对象了：

图 4.6 – 从存储桶访问图像

如果我们将资源更改为 arn:aws:s3:::seccbbucket/*，并且没有指定对象操作（如 s3:GetObject），我们将收到一个错误，提示该操作不适用于任何资源。这是因为，当我们在存储桶上添加任何前缀（如 * ）时，它被视为对象操作；否则，它被视为存储桶级别的操作。

接下来，我们将看看如何通过 CLI 为 IAM 用户授予 ListBucket 访问权限。

从 CLI 为 IAM 用户授予 ListBucket 访问权限

在前一节中，我们使用了一个允许所有人访问的策略，通过将 Principal 设置为 * 来实现。在本节中，我们将使用一个允许特定 IAM 用户访问的存储桶策略，以演示如何通过 CLI 创建存储桶策略。让我们开始吧：

1. 如果你在前一节中跟着操作，请删除该策略，并确保你没有访问列表存储桶的权限。

2. 创建一个存储桶策略，允许我们的 awsseccb_user1 用户访问该对象，并将其保存为 bucket-policy-allow-list.json：

    {
     "Id": "Policy1560416549842",
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "ListAllBuckets",
         "Action": [
           "s3:ListBucket"
         ],
         "Effect": "Allow",
         "Resource": "arn:aws:s3:::awsseccbbucketpolicy",
         "Principal": {
           "AWS": "arn:aws:iam::207849759248:user/awsseccb_user1"
         }
       }
     ]
   }
   

   请记得将我的 S3 存储桶名称 awsseccbbucketpolicy 替换为你的存储桶名称，将我的 AWS 账户 ID 207849759248 替换为你自己的 AWS 账户 ID。

3. 将策略附加到存储桶：

   aws s3api put-bucket-policy --bucket awsseccbbucketpolicy --policy file://bucket-policy-allow-list.json --profile AwsSecCbAdmin
   

4. 使用为 awsseccb_user1 用户创建的 AwsSecCbUser 配置文件，列出存储桶的内容，使用如下截图所示的 aws s3 ls bucketname 命令：

图 4.7 – 使用 CLI 列出存储桶内容

现在你已经了解了如何通过控制台和 CLI 创建策略，接下来可以使用每个可用的操作和条件练习更多场景。

它是如何工作的…

在本食谱中，我们创建了 S3 存储桶策略。一个存储桶策略声明可以包含以下组件：Sid、Sid、Sid、Sid、Resource 和 Condition。除了 Principal 之外，这些都与 IAM 策略相同，我们在第二章的《创建客户管理的 IAM 策略》一节中探讨过它们。

存储桶策略的 Principal 组件可以是帐户、用户、角色或所有人（由 * 表示）。它可以包含资源的 ARN（通过 ARN 元素指定）或规范 ID（通过 CanonicalUser 元素指定）。有关 Principal 的更多细节，请参见本食谱的 更多信息 部分。

对于存储桶策略，资源是存储桶或对象，并使用存储桶 ARN 表示。存储桶 ARN 应该是 arn:aws:s3:::bucket_name 形式。对象资源表示为 arn:aws:s3:::bucket_name/key_name 形式。为了表示存储桶中的所有对象，我们可以使用 arn:aws:s3:::bucket_name/* 。我们可以将每个存储桶中的每个资源表示为 arn:aws:s3:::* 。

还有更多内容...

存储桶策略遵循与 IAM 策略相同的 JSON 文档结构，但有一个额外的主体字段。主体是适用策略声明的用户或实体。IAM 策略没有主体，因为它是附加到 IAM 用户的。在 IAM 策略中，执行该策略的 IAM 用户就是主体。

在使用存储桶策略中的主体时，请考虑以下示例：

• 根用户可以表示如下：

   "Principal": {
      "AWS": "arn:aws:iam::1312086767378:root"
  }
  

• IAM 用户可以表示如下：

   "Principal": {
      "AWS": "arn:aws:iam::312086767378:user/demouser"
  }
  

• 联邦用户可以表示如下：

   "Principal": {
      "AWS": "arn:aws:iam::312086767378:user/demouser"
  }
  

• IAM 角色可以表示如下：

   "Principal": {
      "AWS": "arn:aws:iam::your-account-id:role/MyRole"
  }
  

• 角色会话可以表示如下：

   "Principal": {
      "AWS": "arn:aws:sts::767883004914:assumed-role/UserRole/MySession"
  }
  

• 规范用户 ID 可以表示如下：

   "Principal": {
      "CanonicalUser": "5df5b6014ae606808dcb64208aa09e4f19931b3123 456e152c4dfa52d38bf8fd"
  }
  

• AWS 会话可以表示如下：

   "Principal": {
      "Service": "cloudfront.amazonaws.com"
  }
  

• 多个主体可以在数组中表示如下：

   "Principal": {
      "AWS": [
          "arn:aws:iam::873506153865:root",
          "arn:aws:iam::671100771477:root"
      ]
  }
  

• 匿名用户可以表示如下：

   "Principal" : "*"
  

让我们快速浏览一些与 S3 存储桶策略相关的重要细节：

• Conditions 元素是一个可选元素，允许我们有条件地执行策略。我们在其中一个示例中使用了 Conditions。

• 目前，我们大约有 50 个存储桶策略操作，包括适用于对象的操作（例如，s3:PutObject），适用于存储桶的操作（例如，s3:CreateBucket），以及适用于存储桶子资源的操作（例如，PutBucketAcl）。

• 当前具有权限的存储桶子资源列表包括 BucketPolicy、BucketPolicy、BucketPolicy、BucketPolicy、BucketPolicy、BucketPolicy、BucketPolicy、BucketPolicy、BucketPolicy、BucketPolicy、BucketPolicy、BucketPolicy、BucketPolicy、BucketPolicy、BucketPolicy、BucketPolicy、BucketPolicy、BucketPolicy、ReplicationConfiguration 和 AnalyticsConfiguration。

• 我们不能在 S3 存储桶策略中指定 IAM 组作为主体。如果我们添加一个组而不是用户，则会出现错误：策略中的无效主体。

• 以下是一些可在策略中的条件中使用的 S3 特定条件键：s3:x-amz-acl，s3:x-amz-copy-source，s3:x-amz-metadatadirective，s3:x-amz-server-side-encryption，s3:VersionId，s3:LocationConstraint，s3:delimiter，s3:max-keys，s3:prefix，s3:xamz-server-side-encryption-aws-kms-key-id，s3:ExistingObjectTag/，s3:RequestObjectTagKeys，s3:RequestObjectTag/，s3:object-lock-remainingretention-days，s3:object-lock-mode，s3:object-lock-retain-untildate，和s3:object-lock-legal-hold。

另请参见

• 我们可以通过第二章中的《创建客户管理的 IAM 策略》章节了解 IAM 策略。有关 ACL、桶策略和 IAM 策略的详细比较，请参阅当前章节中《使用 S3 ACLs》食谱的更多内容部分。

• 我们可以在docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html找到许多桶策略示例。

使用 S3 ACLs

在 Amazon S3 中，ACL 用于管理对桶和对象的访问。随着我们深入了解 ACL，重要的是要认识到它们现在被视为 AWS 生态系统中的遗留工具。AWS 建议选择更现代的解决方案，如 IAM 和桶策略，这些方案提供了更强的灵活性和安全性。然而，理解 ACL 仍然有益，尤其是在处理早期开发的系统或应用程序时，这些系统或应用程序是在 IAM 和桶策略出现之前开发的。

在本食谱中，我们将学习如何通过 AWS 管理控制台使用 ACL 向公众（所有人）授予列出桶中文件的权限。我们将在食谱的更多内容部分列出更多用例。

准备开始

我们需要以下内容才能成功完成此食谱：

• 一个有效的 AWS 账户是必需的。我将使用我们在第一章中创建的awsseccb-sandbox-1账户。但是，我不会使用 AWS Organizations 或 IAM Identity Center 的任何功能。

• 一个具有AdministratorAccess权限的awsseccb_admin1用户。

• 如果我们想按照本章中 CLI 命令的步骤操作，我们需要设置一个环境，用于执行具有两个 CLI 配置文件的 CLI 命令，分别是AwsSecCbAdmin和AwsSecCbUser，用于awsseccb_admin1和awsseccb_user1用户（分别）。

• 我们还需要一个 S3 桶以及其中的一个文件。我将使用一个名为awsseccbacldemo的桶，其中有一个名为image-cloudericks.png的文件。请将其替换为你的桶名和文件名。该 S3 桶应该配置为启用 ACL。我们可以在创建桶时进行设置，如图 4.8所示。另请确保阻止所有公共访问选项未勾选，尤其是在涉及 ACL 设置时。我们可以在创建桶时进行设置，如图 4.9所示。对于其余设置，保持默认设置即可，在撰写本书时，默认设置如下：

  • 桶版本控制设置为禁用

  • 默认加密设置为使用 Amazon S3 管理的服务器端加密密钥（SSE-S3）

  • 桶密钥设置为启用

  • 对象锁定（位于高级设置下）设置为禁用

在创建 S3 桶时，我们可以根据此配方启用所需的 ACL 设置，具体设置如下：

图 4.8 – 启用 Amazon S3 对象所有权的 ACL

此外，我们可以根据此配方的要求取消勾选阻止所有公共访问选项，如下图所示：

图 4.9 – 取消勾选 ACL 的“阻止所有公共访问”设置

通过浏览器访问桶的 URL（https://<桶名>.s3.amazonaws.com），替换<桶名>为我们的桶名称（例如，awsseccbacldemo.s3.amazonaws.com），验证我们的桶是否不允许所有人列出内容，类似于图 4.2。

接下来，允许所有人列出桶的内容。

如何操作...

执行以下步骤以允许所有人列出桶的内容：

1. 进入控制台的S3服务。

2. 点击我们的桶名称（例如，awsseccbacldemo），进入桶的页面。

3. 进入桶的权限标签页，向下滚动到访问控制列表（ACL）标签页，并点击编辑。

4. 在编辑访问控制列表（ACL）页面下，找到每个人（公共访问），勾选对象下的列出复选框，并勾选我理解这些更改对我的对象和桶的影响声明旁边的复选框。

图 4.10 – 编辑 ACL 页面

1. 向下滚动并点击保存更改。

2. 使用https://<桶名>.s3.amazonaws.com链接通过浏览器访问桶，替换<桶名>为你的桶名称（例如，awsseccbacldemo.s3.amazonaws.com/）。你应该能够列出桶的内容。

图 4.11 – 显示桶内容的 XML 文件

在本版本的书中，我们专注于涉及 ACL 的较小范围场景，与本书前一版覆盖的更广泛的使用案例不同，因为目前 ACL 被认为是一个遗留选项。

它是如何工作的...

本食谱提供了在 AWS 中启用 S3 桶内容公共列出的步骤。关键步骤是通过 AWS 管理控制台修改 ACL 设置。在此过程中，我们特别配置了 ACL，以允许公共访问列出桶的内容，同时确保不授予对桶对象的通用读取访问权限。

在这个食谱中，我们通过管理控制台允许所有人列出桶的内容。我们也可以通过 CLI 做到这一点。ACL 提供了桶、对象及其 ACL 的基本读写权限。具体来说，它们可以授予以下权限，并且可以在使用 AWS CLI 时进行设置：

• READ : 允许列出桶中的对象，并读取对象及其元数据

• WRITE : 启用在桶中创建、覆盖或删除对象；此权限不适用于单个对象

• READ_ACP : 授予读取桶或对象的 ACL 的权限

• WRITE_ACP : 允许为桶或对象写入 ACL

• FULL_CONTROL : 包括所有先前的权限，提供对桶或对象的完全控制

在实施 READ ACLs 以进行公共访问之前，我们通过启用 ACL 并确保取消勾选 阻止所有公共访问 设置，特别是针对与 ACL 相关的选项，来准备桶。需要注意的是，ACL，通常被视为一个遗留功能，相较于更现代的选项，如 IAM 和桶策略，默认是禁用的。同样，出于安全考虑，公共访问默认是被阻止的。

还有更多内容...

让我们深入探讨一些与 Amazon S3 中的 ACL 相关的重要概念：

• 基本权限 : ACL 提供桶、对象及其 ACL 的基本读写权限。

• 访问授予 : ACL 授予对 AWS 账户和预定义组的访问权限，但不能拒绝访问。Amazon S3 ACL 中的预定义组是由 AWS 设置的固定类别，表示广泛的用户集，例如 所有用户（面向公众），已验证用户（面向任何已登录的 AWS 用户）和 日志传递（面向将日志传递到桶中的服务）。这些组简化了权限设置，而无需指定单个用户账户。在指定受让人时，可以使用以下方法：

  • AmazonCustomerByEmail : 将 Type 设置为 AmazonCustomerByEmail，并在 EmailAddress 字段中使用规范 ID

  • CanonicalUser : 将 Type 设置为 CanonicalUser；账户的电子邮件提供在 ID 字段中

  • Group : 当 Type 为 Group 时，使用预定义组的 URI 在 URI 字段中

• 默认控制 : 默认情况下，ACL 授予资源所有者完全控制，并不给予其他任何人的权限。

• 内部表示：ACL 以 XML 文档的格式呈现，指定访问权限和受让人。

• 非所有者对象访问：ACL 允许使用像bucket-owner-full-control这样的预设 ACL 授予对不是桶所有者拥有的对象的访问权限。

• 预设 ACL：这些是简化的 ACL 权限，可以用于通过命令行提供资源的权限。目前，支持以下预设 ACL：private、private、private、private、private、private、bucket-owner-full-control和log-delivery-write。

• 细粒度对象权限：与桶策略相比，ACL 提供了一种更简单的方式来为多个对象分配单独的权限。

• 阻止公共访问覆盖：S3 的Block Public Access设置可以覆盖授予公共访问的 ACL。

• 记录访问尝试：可以使用 S3 访问日志记录成功和拒绝的访问尝试。

• 不支持条件：与 IAM 或桶策略不同，ACL 不支持授予访问权限的条件子句。

• 管理挑战：在大型环境中管理 ACL 可能会很复杂。

• 安全最佳实践：定期审查和审核 ACL 设置对于维护安全性至关重要。

• 作用域和应用差异：我们有以下区别：

  • ACLs：按资源（桶或对象）指定

  • 桶策略：应用于整个桶，并可用于根据对象前缀定义访问权限

  • IAM 策略：与桶策略的范围相似，但分配给 IAM 用户和组，允许更集中和细粒度的访问控制。

让我们快速浏览一些与预设 ACL 相关的重要概念：

• bucket-owner-read和bucket-owner-full-control预设 ACL 仅适用于对象，若在创建桶时指定这些 ACL 则会被忽略。

• log-delivery-write预设 ACL 仅适用于桶。

• 使用aws-exec-read预设 ACL 时，所有者获得FULL_CONTROL权限，Amazon EC2 获得对来自 S3 的Amazon Machine Image（AMI）的读取权限。

• 使用log-delivery-write预设 ACL 时，LogDelivery组获得对桶的WRITE和READ_ACP权限。这用于 S3 访问日志记录。

• 在发出 API 调用时，我们可以在请求中使用x-amz-acl请求头指定预设 ACL。

重要说明

在跨账户访问的情况下，如果账户 A 中的用户将对象上传到账户 B（由账户 B 拥有）的桶中，即使账户 B 是桶的拥有者，也无法访问该对象。然而，账户 A 可以在上传文档时使用bucket-owner-read或bucket-owner-full-control预设 ACL，授予桶所有者权限。

比较 ACL、桶策略和 IAM 策略

ACL 与 IAM 策略和桶策略的不同之处如下：

• ACL 仅提供对存储桶、对象及其 ACL 的基本读/写权限。IAM 策略和存储桶策略提供比 ACL 更细粒度的权限。

• ACL 只能授予对 AWS 账户和预定义组的访问权限。ACL 不能授予 IAM 用户权限。IAM 策略和存储桶策略可以用于授予 IAM 用户访问权限。

• 默认情况下，ACL 允许资源所有者拥有完全控制权限，其他人则没有任何权限。存储桶策略和 IAM 策略默认不附加到资源上。

• ACL 只能授予权限。存储桶策略和 IAM 策略可以显式拒绝访问。

• ACL 不能有条件地允许或拒绝访问。存储桶策略和 IAM 策略可以有条件地允许或拒绝访问。

• ACL 在内部表示为 XML 文档。存储桶策略和 IAM 策略表示为 JSON 文档。

IAM 策略与 ACL 和存储桶策略的不同之处：

• IAM 策略是基于用户的，并应用于用户。ACL 和存储桶策略是基于资源的策略，并应用于资源。

• IAM 策略可以是内联的（直接嵌入到用户、组或角色中）或独立的（可以附加到任何 IAM 用户、组或角色）。ACL 和存储桶策略是存储桶的子资源。

• IAM 策略只能赋予 IAM 用户访问权限。存储桶策略和 ACL 可以用于提供匿名访问权限以及对 root 用户的访问。

重要提示

我们可以混合使用 ACL、存储桶策略和 IAM 策略。如果存储桶和用户在同一账户内，所有策略将同时进行评估。

另请参见

• 我们可以在第二章的 创建自定义管理的 IAM 策略 章节中了解 IAM 策略。

• 我们可以在 www.cloudericks.com/blog/demystifying-aws-policies-and-permissions 上了解更多关于 IAM 策略和权限的信息。

创建 S3 预签名 URL

我们可以通过设置过期时间来授予访问 S3 对象的临时权限，使用预签名 URL。在本食谱中，我们将学习如何使用预签名 URL。我们可以通过管理控制台、AWS CLI 或使用 Python、Java 等编程语言的 SDK 来实现这一点。

准备工作

我们将需要以下内容来成功完成此食谱：

• 一个有效的 AWS 账户；我将使用我们在第一章中创建的awsseccb-sandbox-1账户。

• 一个 S3 存储桶及其中的一个文件；我将使用名为 seccbbucket 的存储桶，里面有一个名为 image-cloudericks.png 的文件。

如何操作...

我们将首先从控制台创建一个预签名 URL，然后通过 AWS CLI 创建。

从 AWS 控制台生成预签名 URL

我们可以从控制台创建一个预签名 URL 并按如下方式进行测试：

1. 登录到 AWS 管理控制台，导航到 S3 服务，然后进入我们的 S3 存储桶。

2. 选择我们需要为其创建预签名 URL 的对象，点击 对象操作 下拉菜单，并选择 通过预签名 URL 分享。

3. 在以下图中输入 分钟数 的值为 5，然后点击 创建预签名 URL。

图 4.12 – 创建预签名 URL

我们应该会收到一个类似于 复制预签名 URL 的通知：

图 4.13 – 复制预签名 URL 信息

1. 复制并粘贴 URL，然后在 分钟数 所述的时间范围内从浏览器中运行它。我们应该能够成功查看我们的文件。

   如果在指定的时间后运行 URL，我们应该会收到一个类似于 AccessDenied 的错误信息：

图 4.14 – 过期后访问预签名 URL

接下来，我们将了解如何使用 CLI 进行预签名。

从 CLI 生成预签名 URL

我们可以通过 CLI 创建一个预签名 URL 并按如下方式进行测试：

1. 使用 CLI 预签一个 URL，如下所示：

   aws s3 presign s3://seccbbucket/image-cloudericks.png --expires-in 100 – profile AwsSecCbAdmin
   

   该命令将输出类似于以下内容的预签名 URL。

图 4.15 – 从 CLI 生成预签名 URL（部分）

1. 在 URL 过期前后，在浏览器中运行该 URL（就像我们在上一部分中所做的那样）。

接下来，我们将探索如何使用 SDK（例如 Python SDK）进行预签名。

它是如何工作的...

在 从 AWS 控制台生成预签名 URL 部分，我们从 AWS 控制台生成了一个预签名 URL。在 从 CLI 生成预签名 URL 部分，我们从 CLI 生成了一个预签名 URL。

与预签名相关的大多数 API 都会接受以下数据来生成预签名的定时 URL：

• 存储桶和对象

• 过期日期和时间

• HTTP 方法

• 安全凭证

在这个实例中，我们在代码中指定了存储桶、对象和过期时间。HTTP 操作是 GET。对于安全凭证，我们指定了一个具有操作权限的用户配置文件，在我们的示例中是 get_object。任何拥有有效凭证的人都可以生成预签名 URL。然而，如果生成 URL 的用户没有执行预期操作的权限（例如 get_object），则该操作最终会失败。

还有更多...

我们还可以使用 SDK，如 Python SDK，来预签一个 URL。在 Python SDK 中，我们还使用 boto3 库。Boto 是 AWS 的 Python SDK，它可以简化通过 Python 创建、配置和管理 AWS 服务（例如 EC2 和 S3）。

另见

有关与预签名 URL 相关的 Python 和 Boto3 的更多用例，请参考以下链接：boto3.amazonaws.com/v1/documentation/api/latest/guide/s3-presigned-urls.html。

使用 S3 版本控制和对象锁定保护文件

在这个步骤中，我们将学习如何实施S3 对象锁定。S3 对象锁定是一项功能，允许用户在指定的时间段内或无限期内防止 S3 中对象的删除或覆盖。这项功能对于满足法规合规要求和实施数据保护策略至关重要。通过对象锁定，您可以应用写一次，读多次（WORM）模型，确保数据在指定的保留期过后不能被修改或删除。这使得它成为保护关键业务和合规敏感数据的有效工具。

S3 版本控制是 S3 对象锁定的前提条件。因此，我们还将快速查看如何在准备工作部分启用版本控制。如果为桶启用了版本控制，S3 将保留该文件的每个版本的副本。版本控制通过提供恢复机制来保护数据，以防止诸如删除和覆盖等无意操作，因此也可以被视为一种与安全相关的功能。

准备工作

我们需要以下内容才能成功完成这个步骤：

• 一个有效的 AWS 账户；我将使用在第一章中创建的awsseccb-sandbox-1账户。

• 一个启用了桶版本控制的 S3 桶；我将使用一个名为seccbbucket的桶，桶中有一个名为image-cloudericks.png的文件。

  我们可以在创建 S3 桶时启用版本控制，如下所示：

图 4.16 – 为新桶启用版本控制

我们还可以为现有桶启用 S3 版本控制，操作步骤如下：导航到 S3 桶的属性标签，点击编辑旁边的桶版本控制。在桶版本控制下，选择启用，然后点击保存更改。

图 4.17 – 为现有桶启用版本控制

接下来，我们将为我们的桶启用对象锁定。

如何操作...

我们可以按如下步骤启用对象锁定：

1. 登录 AWS 管理控制台，进入S3服务。

2. 导航到 S3 桶，进入桶的属性标签，点击编辑旁边的对象锁定。

3. 在编辑对象锁定页面，选择启用，并勾选复选框确认启用对象锁定将永久允许桶中的对象被锁定。

图 4.18 – 启用对象锁定

1. 通过在默认保留期下选择启用来保护放入桶中的新对象。一旦启用默认保留期，我们将获得额外的选项来配置对象锁定。

图 4.19 – 启用默认保留期

1. 在默认保留模式下选择治理，在默认保留期限中输入30，然后点击保存更改。

2. 上传一个新对象到我们的 S3 桶。我已上传了一个image-heartin.png文件。

3. 转到桶的对象标签，点击新对象的名称以转到该对象的属性标签。

4. 向下滚动并验证对象锁保留下的保留配置。

图 4.20 – 设置默认保留模式后的新对象的对象锁保留

1. 可选地，我们可以在对象锁保留屏幕上点击编辑，如图 4.20所示，执行以下操作之一：禁用保留，将保留模式从治理模式更改为合规模式，或者使用保留直到日期选项延长保留日期。

重要提示

在治理模式下，S3 对象锁中的对象在设置的保留期限结束之前无法更改。要在保留日期之前删除这些对象，必须点击编辑来禁用保留，如图 4.20所示。在合规模式下，我们无法禁用保留，且对象保持不可更改，直到保留期结束。要在保留期到期之前删除这些对象，唯一的方法是关闭关联的 AWS 账户。在这两种模式下，我们可以将保留日期延长到未来的某个日期，但无法缩短它。

1. 可选地，转到任何现有对象的属性标签，向下滚动到对象锁保留，点击编辑以启用该对象的对象锁。我们应该会看到一个类似于配置默认保留的屏幕，如图 4.19所示，在该屏幕中我们可以为此对象配置保留。

2. 可选地，转到任何新对象或现有对象的属性标签，向下滚动到对象锁法律保持，点击编辑以启用法律保持，如下图所示。

图 4.21 – 启用对象锁法律保持

可选地，等待保留日期到期后，再尝试删除我们在合规模式下添加了对象锁的对象。

它是如何工作的...

Amazon S3 对象锁是一个旨在保护您的 S3 对象免受删除或覆盖的功能。它在执行合规性、法律或监管要求的数据保留政策时特别有用。要使用对象锁，您必须首先在 S3 桶中启用版本控制。版本控制是 S3 在同一桶中保留多个对象版本的一种方式，允许您保存、检索并恢复存储在桶中的每个对象的每个版本。启用版本控制后，对象锁可以保护单个对象版本。

对象锁定有两种主要的保留模式：治理模式和合规模式。在治理模式下，具有特定权限的用户可以在对象保留期到期之前覆盖或删除对象版本。此模式非常适合内部数据管理，因为它在保护和灵活性之间提供了平衡。相比之下，合规模式提供了更严格的保护级别。一旦对象在合规模式下被锁定，任何人，包括 AWS 账户中的根用户，都无法在保留期结束之前覆盖或删除该对象版本。此模式适用于需要保留数据以遵守法律或监管标准的场景。

此外，对象锁定提供了一种名为法律保留的功能，增加了额外的保护层。无论对象的保留模式如何，都可以对对象应用法律保留，它会防止对象版本的删除，无时间限制。法律保留非常适用于需要出于法律原因保留对象的情况。需要注意的是，保留模式和法律保留都可以应用于单个对象或作为默认设置应用于桶级别。这些功能共同使 S3 对象锁定成为一个强大的工具，确保关键数据不会被删除或更改，从而帮助组织遵守合规要求并保护其数据免受意外丢失或删除。

还有更多...

在了解了 S3 对象锁定的内容后，我们迅速来看一下Glacier Vault Lock，这是 AWS 中的一项重要功能，尤其是在数据需要长期存储时，它有助于确保 AWS Glacier 中的数据安全。Glacier Vault Lock 的核心是 WORM 原则。这意味着数据存储后可以访问，但无法修改。通过建立并锁定策略，我们可以确保没有人，甚至是管理员或创建者，能够修改或删除这些规则或它们保护的数据。这些策略可以从基础的设置（例如设置数据保留期）到更详细的内容（如指定删除权限角色，甚至创建永久归档）不等。

设置 Glacier Vault Lock 涉及以下步骤：

1. 启动 Glacier Vault：通过 AWS 管理控制台开始在 Amazon Glacier 中创建一个金库。

2. 创建 Vault Lock 策略：制定一个政策，概述您的数据保留偏好。此策略定义了在金库中使用和修改数据的指南。

3. 启动 Vault Lock：将您的策略应用于金库。这将开始过程，但不会立即激活策略。

4. 审查并最终确认：AWS 提供了一个特定的时间框架（通常为 24 小时），让您审查并最终确认您的策略。在此期间后，不允许进行任何更改。

5. 锁定策略：通过确认并永久锁定您的策略来结束这段等待期。一旦锁定，策略将不可逆转，确保数据按照您已建立的规则安全。

通过遵循这些步骤，Glacier Vault Lock 可以有效地用于保护需要长期存储的关键数据，满足合规性和安全性要求。

与 S3 相关的其他重要安全功能包括：

• S3 加密：Amazon S3 加密提供了保护我们静态数据的方式。主要有两种类型：SSE，即 Amazon S3 在将数据写入磁盘时进行加密，并在访问时解密；以及客户端加密，即我们在将数据上传到 S3 之前在本地进行加密。对于 SSE，我们可以选择S3 管理密钥（SSE-S3）、AWS 密钥管理服务密钥（SSE-KMS）和客户提供的密钥（SSE-C）。我们将在本书稍后讨论 AWS 的密钥管理服务（KMS）后，进一步讨论 S3 加密。

• S3 访问点：Amazon S3 访问点通过提供具有定制访问策略的独特主机名，便于管理 S3 中大规模共享数据集的访问。例如，如果我们正在操作一个数据湖，多个部门访问同一个 S3 桶，我们可以为每个部门创建单独的访问点——如finance-data-access或hr-data-access——每个访问点具有特定的权限和网络控制。这使我们能够根据每个部门的需求定制访问，确保数据处理的安全性和高效性。因此，S3 访问点为需要明确基于角色的访问控制的场景提供了简化的解决方案，大大简化了复杂数据访问需求的管理。

• S3 访问日志：Amazon S3 访问日志是增强安全性和监控我们 S3 桶活动的关键组成部分。这些日志提供了对特定 S3 桶所做所有请求的详细记录，包括请求者信息、桶名称、请求时间以及执行的操作。这些信息对于安全分析和审计跟踪至关重要，帮助我们跟踪访问模式、识别可疑活动，并确保符合安全政策。通过分析这些日志，我们可以深入了解使用趋势和潜在的安全漏洞，从而改善我们在 S3 中的整体数据保护策略。

• S3 复制：Amazon S3 复制，包括 跨区域复制（CRR）和跨账户复制，在提高数据安全性和可用性方面起着至关重要的作用。使用 CRR，数据会自动在多个 AWS 区域之间复制，从而提供地理多样化，这对于灾难恢复和满足数据驻留要求至关重要。跨账户复制则通过在不同 AWS 账户之间复制数据，增加了额外的安全层。这对于数据完整性和隔离至关重要的场景（如审计）来说是理想的。两种复制策略都可以通过特定策略进行管理，从而精确控制哪些数据会被复制及其复制方式。

另见

• 请查看第三章中的使用带条件密钥的密钥策略教程，了解如何使用 AWS KMS 密钥在 S3 存储桶中进行加密。

• 本书虽然涵盖了 S3 的关键安全功能，但为每个功能提供教程超出了本书的范围。如需获取始终更新且完整的列表，可以访问博客文章 www.cloudericks.com/blog/a-comprehensive-list-of-s3-security-features-within-aws-cloud。

在 S3 上加密数据

在本教程中，我们将学习使用 SSE 技术对 S3 上静态数据进行加密。服务器端加密可以通过三种方式完成：SSE-S3、SSE-KMS 和 SSE-C。而客户端加密是在客户端进行加密后再发送到服务器。

准备工作

我们需要一个配置了以下资源的有效 AWS 账户：

• 我们需要一个 S3 存储桶。我将使用名为awssecbucket的存储桶。请将其替换为你的存储桶名称。

• 我们需要一个具有AdministratorAccess权限的用户。为该用户配置 CLI 配置文件。我将在awssecadmin CLI 上同时调用该用户和配置文件。

• 我们需要在 KMS 中创建一个客户管理的密钥。请参考第三章中的创建 KMS 密钥教程来创建密钥。我创建了一个名为MyS3Key的密钥。

如何操作...

在本教程中，我们将学习 SSE 的各种应用场景。

使用 SSE-S3 的 SSE

我们可以通过控制台上传一个带有 SSE-S3 的对象，方法如下：

1. 在控制台中导航到你的 S3 存储桶。

2. 在对象窗格下，点击上传 | 添加文件，选择文件后，点击上传。

3. 现在转到属性选项卡。在我们的存储桶中，向下滚动到默认加密窗格并点击编辑。在加密类型下，选择使用 Amazon S3 管理的密钥进行服务器端加密 (SSE-S3)，然后在存储桶密钥下，选择启用。最后，点击保存更改。

图 4.22 – 默认加密选项

重要提示

需要特别注意的是，如果我们尝试打开或下载该对象，我们仍然可以看到该对象原样显示，因为 S3 会使用相同的密钥解密该对象。

使用 SSE-KMS 的 SSE

我们可以通过以下方式使用控制台上传一个对象，并使用 SSE-KMS：

1. 导航至您的 S3 桶。

2. 现在转到属性面板。在属性选项卡中，向下滚动到默认加密面板并点击编辑。在加密类型下，选择使用 AWS Key Management Service 密钥进行服务器端加密（SSE-KMS）；在AWS KMS 密钥面板中，选择从您的 AWS KMS 密钥中选择并选择该密钥；在桶密钥下，选择启用，最后点击保存更改。

图 4.23 – 使用 KMS 更改加密选项

1. 我们可以按照以下方式更改现有对象的加密为 SSE-KMS。转到该对象的属性选项卡。向下滚动到服务器端加密设置面板并点击编辑。在加密设置下，选择使用桶设置作为默认加密并点击保存更改。

图 4.24 – 更改现有对象的加密选项

1. 我们可以通过以下命令从 CLI 上传一个对象并使用 SSE-KMS：

   aws s3 cp image-heartin-k.png s3://awsseccookbook/image-heartin-k.png \
   --sse aws:kms \
   --sse-kms-key-id cd6b3dff-cfe1-45c2-b4f8-b3555d5086df \
   --profile awssecadmin
   

   我们将收到以下响应：

图 4.25 – 从 CLI 上传对象时使用 SSE-KMS 的响应

重要提示

sse-kms-key-id 是您创建的 KMS 密钥的 ID（有关详细信息，请参阅准备工作部分）。

使用 SSE-C 的 SSE

我们可以按照以下方式从 CLI 上传一个对象并使用 SSE-C：

1. 使用以下命令从 CLI 上传一个对象，并通过 SSE-C 进行加密。提供任意一组数字作为密钥。稍后检索对象时，您需要使用相同的密钥：

   aws s3 cp image-heartin-k.png s3://awsseccookbook/imageheartin-k.png \
   --sse-c AES256 \
   --sse-c-key 12345678901234567890123456789012 \
   --profile awssecadmin
   

   我们将收到以下响应：

图 4.26 – 从 CLI 上传对象时使用 SSE-C 的响应

1. 按照以下方式检索使用 SSE-C 加密的对象，提供我们在上一个命令中使用的相同密钥：

   aws s3 cp s3://awsseccookbook/image-heartin-k.png imageheartin-k1.png \
   --sse-c AES256 \
   --sse-c-key 12345678901234567890123456789012 \
   --profile awssecadmin
   

   我们将收到以下响应：

图 4.27 – 使用 SSE-C 加密的对象的检索响应

提示

如果我们在下载使用 SSE-C 加密的对象时不指定sse-c选项，那么在调用HeadObject 操作：Bad Request时，我们将收到一个致命错误：发生错误（400）异常。如果我们在下载使用 SSE-C 加密的对象时不指定用于加密的正确密钥（使用sse-c-key选项），那么在调用HeadObject 操作：Forbidden时，我们将收到一个致命错误：发生错误（403）异常。

工作原理...

在SSE with SSE-S3部分，我们使用 SSE-S3 加密从控制台上传了一个对象。我们将现有对象的加密更改为 SSE-S3 加密。我们还上传了一个使用 SSE-S3 加密的对象。在从 CLI 执行 SSE-S3 加密时，sse参数的值是可选的。默认值为AES256。

在SSE with SSE-KMS部分，我们使用 SSE-KMS 加密上传了一个对象。我们将现有对象的加密更改为 SSE-KMS 加密。我们还使用 SSE-KMS 加密从 CLI 上传了一个对象。在从 CLI 执行 SSE-KMS 加密时，sse-c参数的值是可选的。默认值为AES256。

在SSE with SSE-C部分，我们使用 SSE-C 加密从 CLI 上传了一个对象。与其他两种 SSE 技术 SSE-S3 和 SSE-KMS 不同，控制台目前没有明确的 SSE-C 选项。我们需要使用 API 来执行此操作。在这个示例中，我们使用了一个 32 位数字作为密钥。然而，在现实世界中，密钥通常是使用密钥生成工具生成的。当我们在本书后面讨论 KMS 时，我们将更多地了解密钥。

还有更多...

让我们快速浏览一些与 S3 加密相关的重要概念：

• S3 上的数据可以在静态（存储在 AWS 磁盘上）或传输（移动到和从 S3）时进行加密。静态加密可以使用 SSE 或通过从客户端上传加密数据来完成。

• S3 静态数据的 SSE 技术使用对称密钥进行加密。

• 使用 SSL/TLS（HTTPS）进行传输中的数据加密使用非对称密钥进行加密。

• S3 默认加密（作为存储桶属性可用）提供了一种设置 S3 存储桶默认加密行为的方式，使用 SSE-S3 或 SSE-KMS。启用此属性不会影响存储桶中的现有对象，仅适用于上传的新对象。

• 使用客户端端加密时，我们需要自行管理密钥。我们也可以通过 SDK 使用 KMS 来管理密钥。然而，并非所有 SDK 目前都支持。

• 传输中的加密可以通过客户端端加密或使用 SSL/TLS（HTTPS）来实现。

• SSE 类型 SSE-S3 和 SSE-KMS 遵循信封加密，而 SSE-C 不使用信封加密。

SSE-S3 的一些重要特点包括以下内容：

• AWS 负责所有密钥管理。

• 它遵循信封加密。

• 它使用对称密钥加密数据。

• 每个对象都使用唯一的密钥加密。

• 它使用 AES-256 算法。

• 数据密钥使用主密钥加密，主密钥会定期自动轮换。

• 它是免费的。

SSE-KMS 的一些重要特性包括：

• 密钥由 AWS KMS 管理。

• 密钥可以被多个服务共享（包括 S3）。

• 作为客户，我们可以更好地控制密钥，例如创建主密钥和数据密钥，以及禁用和轮换主密钥。

• 它遵循信封加密方式。

• 它使用对称密钥加密数据。

• 数据密钥使用主密钥加密。

• 它使用 AES-256 算法。

• 我们可以选择在上传对象时加密特定的对象密钥。

• 我们可以使用 CloudTrail 监控 KMS API 调用，从而实现更好的审计。

• 它不是免费的。

SSE-C 的一些重要特性包括：

• 密钥由我们（客户）管理。

• 客户提供密钥和数据；S3 使用此密钥进行加密后删除该密钥。

• 解密时也必须提供密钥。

• 它不使用信封加密。

• 它使用对称密钥加密数据。

• 它使用 AES-256 算法。

• 由于你也在上传对称密钥，AWS 将强制你在上传数据时使用 HTTPS。

• 它是免费的。

• 默认情况下，S3 允许通过 HTTP 和 HTTPS 访问数据；可以通过桶策略中的以下条件元素强制使用 HTTPS：

   "Condition": {
  "Bool": {
  "aws:SecureTransport": "false"
  }
  }
  

  没有 HTTPS 的任何请求都会因该条件而失败。

另见

• 了解 Amazon S3 加密的基础知识，请访问www.cloudericks.com/blog/understanding-amazon-s3-encryption。

• 了解更多关于 SSE-KMS 加密的 S3 桶密钥， 请访问www.cloudericks.com/blog/understanding-s3-bucket-key-for-sse-kms-encryption。

• 阅读更多关于加密的信息，访问www.secdops.com/blog/getting-started-with-encryption。

第五章：使用 VPC 进行网络和 EC2 安全性

亚马逊 虚拟私有云（VPC）是 AWS 云中的基础组件，允许在 AWS 云内创建与广泛的 AWS 公共云隔离的私有网络。它使我们能够将 AWS 资源部署到我们在 AWS 账户内定义的虚拟专用网络（VPN）中。这个虚拟网络类似于我们可能在自己的数据中心运行的传统网络，但具有 AWS 可扩展基础设施的额外优势。

用户对其虚拟网络环境拥有完全控制权。这意味着他们可以选择 IP 地址范围，设置公共和私有子网，并自定义路由表和网络网关，以满足自己的需求。这种灵活性使得可以在公共子网中部署可以访问互联网的实例（例如 Web 服务器），同时将仅限内部使用的实例（例如数据库服务器）放置在私有子网中。

此外，Amazon VPC 提供了一套强大的安全功能，如安全组、网络访问控制列表（NACLs）、流日志、VPN 连接、与 AWS 身份与访问管理（IAM）的集成、PrivateLink、终端节点服务和网关终端节点。这些安全特性共同增强了 VPC 内的安全措施，为 AWS 资源的部署和管理创造了一个安全、强大且受控的网络环境。

本章包括以下操作：

• 轻松设置 VPC 及 VPC 资源

• 创建一个裸 VPC 并设置公共和私有子网

• 使用用户数据启动带有 Web 服务器的 EC2 实例

• 创建和配置安全组

• 使用 NACL（网络访问控制列表）

• 使用 VPC 网关终端节点连接到 S3

• 配置和使用 VPC 流日志

• 设置和配置 NAT 网关

技术要求

在深入了解本章的操作之前，我们需要确保具备以下知识和要求：

• 我们需要一个有效的 AWS 账户才能完成本章的操作。我们可以使用一个属于 AWS 组织的账户或一个独立账户。我将使用我们在第一章中创建的awsseccb-sandbox-1账户，该账户来自于多账户管理与 AWS 组织的操作实例。但是，我不会使用任何 AWS 组织功能，这意味着你也可以使用独立账户按照这些步骤进行操作。

• 对于管理操作，我们需要一个具有AdministratorAccess 权限的用户来访问我们正在使用的 AWS 账户。这个用户可以是 IAM 身份中心用户，也可以是 IAM 用户。我将使用我们在第一章中创建的awsseccbadmin1 IAM 身份中心用户。但是，我不会使用任何 IAM 身份中心的功能，因此，如果用户在账户中具有AdministratorAccess权限，你也可以使用 IAM 用户跟随这些步骤。你可以通过遵循第一章中的设置 IAM、账户别名和账单警报方法来创建 IAM 用户。

• 对计算机网络的基本概念有一定的基础理解会很有帮助。你可以在www.secdops.com/blog/essential-computer-networking-concepts-for-the-cloud 学习本章所需的计算机网络概念。

本书的代码文件可以在github.com/PacktPublishing/AWS-Security-Cookbook-Second-Edition找到。本章的代码文件可以在github.com/PacktPublishing/AWS-Security-Cookbook-Second-Edition/tree/main/Chapter05找到。

设置 VPC 及 VPC 资源，轻松完成

在本方法中，我们将创建一个 VPC，并包括一些网络资源，如公有子网、私有子网、路由表、Internet 网关（IGW）、网络地址转换（NAT）网关以及VPC 终端节点（S3 网关）。如果需要，我们也可以单独创建这些组件，正如在本章后续的其他方法中所看到的那样。为了探索所有可能性，我将在此方法中选择所有可供选择的网络资源组件。其中一些组件，如 NAT 网关，可能会产生费用。根据需要选择组件及其数量。

准备工作

要遵循这个方法，我们需要一个有效的awsseccb-sandbox-1 AWS 账户，以及一个awsseccbadmin1 用户，正如在技术 要求 部分所描述的那样。

如何操作...

请注意，这里展示的默认选项可能会随时间变化，因此在创建 VPC 之前，请检查预览，确保仅创建你所需要的资源。让我们开始吧：

1. 登录 AWS 管理控制台并进入VPC 服务。

2. 在左侧边栏，点击虚拟私有云下的您的 VPC。我们将进入您的 VPC页面，在那里可以看到我们的 VPC。如果这是我们第一次使用 VPC，我们将只看到默认的 VPC。

3. 在Your VPCs页面，点击Create VPC。在Create VPC屏幕中，选择VPC and more，然后选择Auto-generate。之后，提供awsseccb项目前缀，如下图所示：

图 5.1 – 创建带有网络资源的 VPC

1. 在IPv4CIDR 块下提供10.0.0.0/16值。

2. 对于IPv6 CIDR 块，我们有两个选项：No IPv6 CIDR block和Amazon-provided IPv6 CIDR block。选择No IPv6CIDR block。

3. 对于Tenancy，有两个选项：Default和Dedicated。选择Default。

4. 对于可用区（AZ）数量，选择2；对于公共子网数量，选择2；对于私有子网数量，选择2，如下面的图所示：

图 5.2 – 配置可用区（AZ）数量和子网

可选地，在展开Customize AZs后，我们可以为子网选择 AZ，并使用Customize subnets CIDRblocks选项来自定义 CIDR 块。

1. 对于NAT 网关 ($)，选择1 in 1 AZ；对于VPC 端点，选择S3 Gateway；对于DNS 选项，选择Enable DNS hostnames和EnableDNS resolution。

图 5.3 – 配置 NAT 网关、VPC 端点和 DNS 选项

AWS 将在页面的右侧窗格中显示 VPC 预览以及它将创建的网络资源，如下所示：

• 名为awsseccb-vpc的 VPC

• 子网名为awsseccb-subnet-public1-us-east-1a、awsseccb-subnet-public1-us-east-1a、us-east-1b, awsseccb-subnet-public2-us-east-1b和awsseccb-subnet-private2-us-east-1b

• 路由表名为awsseccb-rtb-public、awsseccb-rtb-private1-us-east-1a和awsseccb-rtb-private2-us-east-1b

• 网络连接名为awsseccb-igw、awsseccb-nat-public1-us-east-1a和awsseccb-vpce-s3

重要提示

所有公共子网共享一个路由表，而每个私有子网都有一个路由表。尽管预览中没有显示，但也会创建一个主路由表，用于规定未与任何路由表关联的子网的默认规则。选择公共子网时，必须创建一个 IGW，并将其连接到这些公共子网，从而实现互联网访问。此外，NAT 网关提供对私有子网实例的互联网访问，同时防止直接的入站互联网流量，必须部署在公共子网中，因此也依赖于 IGW 来处理外向互联网流量。

1. 点击Create VPC以创建包含预览中显示的网络资源的 VPC。

2. 验证预览中列出的所有资源是否已经创建。

在这个示例中，我们创建了一个 VPC 及其 VPC 资源。要仅创建 VPC 而不添加其他资源，我们可以选择仅 VPC选项，而不是如图 5 1中所示的VPC 及更多选项。

它是如何工作的……

在这个示例中，我们成功配置了一个 VPC 及其相关的网络资源。让我们更深入了解这些组件。VPC 是专属于我们 AWS 账户的虚拟网络。它与 AWS 云中的其他虚拟网络隔离。它允许我们将 AWS 资源（如 EC2 实例）部署到我们定义的网络中。

IPv4 CIDR 块定义了分配给我们 VPC 的一系列私有 IPv4 地址，便于 VPC 内部的通信，同时保持与外部网络的隔离。在这个示例中，我们为 VPC 选择了一个10.0.0.0/16无类域间路由（CIDR）块，它代表了 AWS 为 VPC 允许的最广泛的地址范围。CIDR 是一种分配 IP 地址和路由 IP 数据包的方法。它允许将多个 IP 地址表示为一个单一的表达式，从而大大简化了网络配置和管理。对于初学者来说，CIDR 是一个稍微复杂的话题。你可以通过www.secdops.com/blog/understanding-ip-addresses-and-subnetting了解更多有关 CIDR 的信息。

IPv6 CIDR 块是我们 VPC 的可选 IPv6 地址范围。选择无 IPv6 CIDR 块意味着我们的 VPC 将只使用 IPv4 地址。IPv6 地址提供了更大的地址空间，并且在未来的技术发展和全球范围扩展中变得越来越重要。

租用模式选项让我们可以选择为 VPC 选择共享或专用的硬件主机。默认选项允许 AWS 将我们的实例部署在任何共享硬件上，这对于大多数使用场景已足够。专用选项通常用于合规或监管要求。

可用区（AZs）是区域内的不同位置，旨在与其他 AZ 中的故障隔离。通过选择多个 AZ，我们可以实现高可用性。每个子网与特定的 AZ 绑定，以确保容错和低延迟。在这个示例中，我们创建了两个 AZ。

子网是 IP 网络的逻辑子划分。在 AWS 等云环境中，子网通过细分网络并在资源之间引导流量来帮助组织 VPC。这种细分允许创建公共子网，为如 Web 服务器等资源提供直接的互联网访问，以及私有子网。私有子网专为需要受限访问的资源（如数据库服务器）设计，通常只允许从网络内部或特定子网（如 Web 服务器子网）访问。

使用VPC 及更多选项创建 VPC 时，子网会在可用区（AZs）之间平均分配。因此，我们可以选择多个子网，数量是我们选择的 AZs 数量的倍数。如果我们选择1 个 AZ，则公共子网有0和1选项，私有子网有0、1和2选项。类似地，如果我们选择 3 个 AZs，则公共子网有0和2选项，私有子网有0、3和6选项。在这个配方中，我们创建了四个子网——两个公共子网和两个私有子网。

IGW 是一种资源，允许我们 VPC 中的实例与互联网进行通信。任何需要直接访问互联网的子网都必须使用 IGW。由于我们选择在配方中创建公共子网，AWS 创建了一个 IGW，并将我们的公共子网与该 IGW 关联。对于公共子网，我们还需要将所有互联网流量路由到 IGW。这是通过使用路由表来完成的。

路由表包含一组规则，称为路由，这些规则决定了来自我们子网或 VPC 路由器的网络流量的去向。以下是 AWS 在与我们公共子网关联的路由表中创建的路由：

图 5.4 – 包含 IGW 路由的路由表

当我们选择VPC 及更多选项时，所有公共子网共享一个路由表，而每个私有子网都与一个独立的路由表关联。除此之外，每个 VPC 都会创建一个主路由表，无论我们是选择仅 VPC还是VPC 及更多选项。主路由表规定了未与任何路由表关联的子网的默认规则。默认情况下，任何子网都不会显式地与主路由表关联。

所有没有在 VPC 内显式关联任何路由表的子网，都会隐式地与主路由表关联。这意味着主路由表的路由行为适用于所有未与其他路由表关联的子网。在这个配方中，所有子网都与路由表关联，因此主路由表不会有任何关联。我们可以通过移除某个子网与路由表的关联来进行实验，届时我们会看到它将隐式地与默认路由表关联。如果需要，我们可以设置不同的路由表作为主路由表。

因此，配置了两个公共子网和两个私有子网时，将会有四个路由表：一个用于公共子网，一个用于每个私有子网，以及一个主路由表。如果配置包含两个公共子网和四个私有子网，则总共有六个路由表：一个用于公共子网，一个用于每个私有子网，以及一个主路由表。

NAT 网关允许私有子网中的实例发起出站互联网流量，但阻止来自互联网的无请求入站流量。这对于更新、修补或下载不需要直接从外部访问的实例的依赖项至关重要。NAT 是一种使私有子网资源能够访问互联网或其他网络服务，而不暴露其私有 IP 地址的方法。通过将这些私有 IP 地址转换为公共 IP 地址，NAT 网关为私有子网内的服务提供了安全的互联网访问，从而确保私有网络的内部结构不会受到外部流量和威胁的影响。NAT 网关部署在公共子网中，因此，如果我们选择不使用VPC 和更多选项创建任何公共子网，并尝试选择 NAT 网关选项，则会收到错误消息。

VPC 端点使我们的 VPC 与 AWS 服务之间可以进行私密连接，无需流量经过互联网。选择S3 网关端点允许我们的实例安全地访问 S3 存储桶，而无需使用 IGW 或 NAT 网关，从而提高安全性并可能降低成本。最后，在 VPC 中启用DNS 主机名和DNS 解析等 DNS 选项，可以使我们的 AWS 资源通过主机名而不是 IP 地址进行通信，从而简化网络管理和配置。

尽管在创建 VPC 时未在预览中显示，但也创建了一个 NACL。NACL 充当防火墙，用于控制子网级别的流量。NACL 会检查并过滤进入和离开我们 VPC 内每个子网的流量。当我们使用VPC 和更多选项或仅 VPC选项创建 VPC 时，系统会创建一个默认的 NACL，该 NACL 允许所有入站和出站流量。创建的子网会自动与默认 NACL 关联。然而，我们可以将其关联更改为其他 NACL。以下是默认 NACL 的入站规则：

图 5.5 – 默认 NACL 的入站规则

当我们创建 VPC 时，AWS 会在我们的 VPC 内创建一个名为default的安全组。在 AWS 中，安全组充当虚拟防火墙，管理 EC2 实例的入站和出站流量。它在实例级别操作，而 NACL 控制子网级别的流量。安全组和 NACL 相辅相成，在 AWS 环境中提供分层安全性。我们可以使用安全组对单个实例进行细粒度的、有状态的控制，而 NACL 提供额外的无状态、子网级别的安全性，在流量到达实例之前允许或阻止某些类型的流量。

还有更多内容...

每个 AWS 区域都有一个由 AWS 提供的默认 VPC，其中包括每个 AZ 中的公共子网、一个 IGW 以及配置的 DNS 解析。默认 VPC 使得可以立即启动 Amazon EC2 实例，而无需创建 VPC。以下是默认 VPC 的一些重要设置：

• 默认 VPC 中的子网通过 IGW 具有外向互联网路由。

• 每个 AZ 都会创建一个子网。

• DHCP 选项集已更新。我的默认 VPC 具有以下选项：domain-name = ec2.internal 和 domain-name-servers =AmazonProvidedDNS。

让我们快速回顾一下与 AWS VPC 相关的更多重要概念：

• AWS VPC 由子资源组成，如 IGW、路由表、NACL、安全组和子网。

• AWS 在每个区域都创建了一个默认 VPC 供我们使用。以下是它的一些重要特性：

  • 默认 VPC 中的子网可以路由到互联网。

  • 每个 AZ 都会创建一个子网。

  • DHCP 选项集已更新。

• VPC 对等连接可以通过使用私有 IP 地址的直接路由将一个 VPC 连接到另一个 VPC，使关联的实例表现得像是处于同一个网络中。

• VPC 对等连接可以在同一区域内进行，也可以跨区域，甚至跨 AWS 账户进行。

• 当前不支持 VPC 的传递对等连接。每个 VPC 必须与每个所需的 VPC 通过类似星形拓扑的结构进行对等连接。

• 为了避免管理多个 VPC 对等连接的开销，我们可以使用 AWS Transit Gateway 将所有 VPC 甚至本地网络连接到一个网关。

• 除了标准的网络地址和广播地址的保留 IP 地址外，AWS 还保留了三个额外的 IP 地址。因此，VPC 中总共保留了五个地址。

让我们快速回顾一下与 AWS 子网相关的一些重要概念：

• 子网的第一个 IP 地址代表子网 ID，而最后一个 IP 地址代表子网的定向广播地址。因此，我们不能将子网的第一个和最后一个 IP 地址分配给主机。AWS 会保留额外的 IP 地址。

• 网络中第一个子网的第一个 IP 地址表示子网 ID，同时也表示网络 ID。同样，网络中最后一个子网的最后一个 IP 地址表示子网和网络的定向广播地址。当从网络外部使用这些 IP 地址时，它们将被视为网络的 IP 地址，而在网络内部使用时，它们将被视为子网的 IP 地址。

• AWS VPC 中的子网始终与一个 AZ 关联。虽然我们不能将一个子网与多个 AZ 同时关联，但我们可以将多个子网与一个 AZ 关联。

• AWS 允许我们选择没有连续 IP 地址的子网，如下图所示。然而，使用连续 IP 地址范围是一种良好的实践，就像我们在本示例中使用的10.0.1.0/24和10.0.2.0/24一样。

图 5.6 – 没有连续 IP 地址的子网

我们将在本章后续的配方中学习网络 ACL、安全组和 IGW。

另请参见

• 我们可以在www.cloudericks.com/blog/understanding-aws-default-vpc 上阅读更多关于默认 VPC 的信息。

• 阅读更多关于主路由表的信息，访问www.cloudericks.com/blog/understanding-the-main-route-table-in-aws-vpc。

• 虽然我们已经扩展了对 VPC 及其相关网络资源的理解，但需要记住，本书的主要焦点是安全性，而不是网络。牢固掌握网络原理无疑对开发有效的安全措施至关重要；然而，深入探讨网络的复杂性可能会将我们的注意力从我们旨在探讨的广泛安全主题上转移开。希望深入了解网络知识的读者可以在www.cloudericks.com/blog/beginners-roadmap-to-mastering-aws-networking 上进一步学习。

创建裸 VPC 并设置公有和私有子网

公有子网专门设计用于使其中的实例能够从互联网访问。这是通过通过配置路由表将互联网流量路由到 IGW 来实现的。在本章中的最小化努力设置 VPC 及其资源配方中，我们在创建 VPC 时选择了VPC 及更多选项，如图 5.1所示，这会自动设置公有和私有子网，并配置一个预设的 IGW 和路由表。在这个配方中，我们将选择仅 VPC选项，创建一个没有额外网络资源的 VPC，并设置 IGW 和路由表，以便为我们子网中的实例提供互联网访问。

准备就绪

要跟随这个配方，我们需要一个有效的awsseccb-sandbox-1 AWS 账户和一个awsseccbadmin1用户，正如技术要求部分所述。

如何操作...

首先，我们将创建一个裸 VPC 和一个子网，然后设置 IGW 和路由表。

创建裸 VPC

我们可以按如下方式仅创建 VPC，而不添加其他资源：

1. 登录 AWS 管理控制台，进入控制台中的VPC服务。

2. 在左侧边栏中，点击虚拟私有云标题下的您的 VPC。我们将被带到您的 VPC页面，在那里可以看到我们的 VPC。如果是第一次使用 VPC，我们应该会看到默认 VPC。

3. 在您的 VPC页面，点击创建 VPC，在创建 VPC屏幕上，选择仅 VPC选项。为awsseccb-vpc2命名。对于IPv4 CIDR 块，选择IPv4 CIDR 手动输入并将值设置为10.0.0.0/24。对于IPv6 CIDR 块，选择没有 IPv6CIDR 块。

图 5.7 – 仅创建 VPC

1. 向下滚动，保持自动生成的标签（键为名称，值为awsseccb-vpc2）不变，可选择性地添加新标签，然后点击创建 VPC。

我们的 VPC 现在已经创建好了。接下来，我们将在 VPC 中创建一个子网。

在 VPC 中创建子网

我们在上一节中创建了一个 CIDR 块范围为10.0.0.0/24的 VPC。接下来我们将添加一个子网，子网的子网掩码为/25。我们需要在 VPC 的 IP 地址范围内创建子网，并确保与其他子网没有重叠。让我们开始吧。

1. 进入控制台中的VPC服务。

2. 在左侧边栏点击子网。

3. 点击创建子网。

4. 在创建子网页面下，选择我们在上一节中创建的 VPC，使用下拉框选择VPC ID。

5. 在子网设置下，将子网名称字段设置为awsseccb-vpc2-public-subnet。如果我们计划创建一个私有子网，请将其命名为awsseccb-vpc2-private-subnet。完成本节的剩余步骤，但跳过本章的剩余部分。

6. 在可用区下选择无偏好。

7. 对于IPv4 VPC CIDR 块，保持默认值。

8. 对于IPv4 子网 CIDR 块，提供一个 IP 地址范围，该范围应为我们 VPC 的 IP 地址范围的一个子集。我将使用10.0.0.0/25。

9. 向下滚动并点击创建子网来创建子网。

10. 从侧边栏进入子网页面，我们应该能够看到新的子网。

我们已经在这个操作步骤中创建了一个子网，但目前没有互联网连接。如果你打算创建一个私有子网，那么你已经完成了。如果你想将子网设置为公共子网，请继续按照本食谱中的其余部分进行操作。

启用自动分配公共 IPv4 地址

为了将子网设置为公共子网，建议启用自动分配公共 IPv4 地址功能，操作如下：

1. 选择我们创建的子网，点击操作下拉菜单，点击编辑子网设置。

2. 选择启用自动分配公共 IPv4 地址并点击保存。

3. 从侧边栏进入子网页面。我们应该能够看到我们的第一个子网的自动分配公共 IPv4 地址已设置为是。

接下来，我们将创建一个 IGW。

创建并配置 IGW

我们可以为设置公共子网创建并附加一个 IGW，步骤如下：

1. 进入控制台中的VPC服务。

2. 从左侧边栏点击互联网网关。

3. 点击创建互联网网关。

4. 为 名称标签 给予一个描述性名称，例如 awsseccb-vpc2-igw。保持自动生成的标签（键是Name，值是awsseccb-vpc2-igw），可以选择添加其他标签，然后点击 创建互联网网关。我们应该看到一条成功消息，表明 IGW 已经创建。如果我们进入 互联网网关 页面，我们会看到我们创建的 IGW 的 状态 当前是 未连接。

5. 选择我们创建的 IGW，点击 操作 下拉菜单，然后点击 附加到 VPC。

6. 在 附加到 VPC 页面，选择我们在本教程中创建的 VPC，并点击 附加互联网网关。如果我们进入 互联网网关 页面，我们会看到我们创建的 IGW 的 状态 现在是 已附加。

接下来，我们将创建和配置路由表。

创建和配置路由表

我们可以按照以下方式创建和配置路由表，以设置公共子网：

1. 点击左侧边栏中的 路由表。

2. 点击 创建路由表。

3. 提供 awsseccb-vpc2-rtb-public 名称并选择我们在本教程中创建的 VPC。

4. 保持自动生成的标签（键是Name，值是awsseccb-vpc2-rtb-public），可以选择添加其他标签，然后点击 创建路由表。

5. 点击左侧边栏中的 路由表，选择我们创建的路由表，点击 操作 下拉菜单或进入 路由 标签，然后点击 编辑路由。

6. 在 编辑路由 页面，点击 添加路由。

7. 在 目标 中选择 0.0.0.0/0，在 目标 中选择 互联网网关，然后选择我们在本教程中创建的 IGW，点击 保存更改。如果我们想要为 IPv6 地址添加路由，可以添加类似的条目，将目标设置为 ::/0。

8. 进入我们的路由表并选择 子网关联 标签。

9. 点击 编辑子网关联，选择我们在本教程中创建的子网，然后点击 保存关联。

我们现在可以将 EC2 实例启动到我们的公共子网，并设置适当的安全组规则来验证这些更改。

它是如何工作的...

我们首先创建了一个裸 VPC。当我们使用 仅 VPC 选项创建裸 VPC 时，VPC 还会创建一个主路由表、一个默认 NACL 和一个默认安全组。主路由表决定了未与任何路由表关联的子网的默认规则。在我们的例子中，主路由表仅包括一个本地路由，允许 VPC 内部的通信。这对于允许同一 VPC 内的实例彼此通信而不需要通过互联网或其他外部网络非常重要。

网络 ACL 充当子网级别的防火墙，用于控制流量。在我们的情况下，创建了一个默认的 NACL，允许所有流量。AWS 中的安全组就像虚拟防火墙一样，用于控制 EC2 实例的入站和出站流量。在我们的情况下，创建了一个默认的安全组，允许所有流量。我们将在本章的后续配方中再次看到 NACL 和安全组的使用。

我们选择了启用自动分配公共 IPv4 地址选项，这使得它在创建 EC2 实例时成为该子网的默认选项。如果我们在实例创建时需要，我们可以覆盖这一设置。我们还可以稍后为我们的 EC2 实例创建并附加一个弹性 IP 地址。

我们创建并附加了一个 IGW（互联网网关）。我们还创建并配置了一个路由表以实现互联网访问。如果需要，我们可以通过编辑路由来将主路由表设置为公共路由。然而，如果我们将主路由表设置为公共路由，它将隐式地使所有新子网成为公共子网，直到我们将其与私有路由表关联。因此，最好为公共访问创建一个单独的路由表，然后将需要公共访问的子网附加到该 VPC。接下来，我们将执行这一操作。

还有更多...

在本章前面的配方中，以最小的努力设置 VPC 及 VPC 资源，我们详细讨论了 VPC 和 VPC 资源。因此，我不会再重复。即使您不想实践如何操作部分，请参考该配方的工作原理、更多内容...和另见部分。

另见

• 阅读更多关于 IGW 的信息，见www.cloudericks.com/blog/understanding-internet-gateway-in-aws。

• 阅读更多关于 AWS VPC 路由表的信息，见www.cloudericks.com/blog/understanding-aws-vpc-route-tables。

使用用户数据启动带有 Web 服务器的 EC2 实例

在这个配方中，我们将使用 EC2 用户数据功能，在启动 EC2 实例时设置一个简单的 Web 服务器。我们将使用这个实例来测试在前面配方中创建的 VPC 和公共子网。我们还将在未来的配方中使用这个实例，任何需要启动 EC2 实例的地方都将用到它。EC2 用户数据功能还通过启用自动安全补丁，确保实例在启动时更新到最新的保护措施，从而显著提高了安全性，并减少了漏洞。此外，它保证了所有实例的安全配置一致，防止配置漂移，并从一开始就严格遵循既定的安全标准。

准备工作

我们需要以下内容来成功完成此配方：

• 一个有效的awsseccb-sandbox-1 AWS 账户，以及一个awsseccbadmin1用户，如技术要求部分所述。

• 一个名为awsseccb-vpc的 VPC，按照本章中的通过最小努力设置 VPC 及其资源步骤创建。

如何操作...

我们将首先使用 EC2 用户数据设置一个作为 Web 服务器的 EC2 实例，并通过浏览器验证它。然后我们将看到如何使用安全外壳（SSH）登录到该实例。

使用 EC2 用户数据设置 Web 服务器

我们可以通过以下方式使用用户数据启动一个带有 Web 服务器的 EC2 实例：

1. 登录到 AWS 管理控制台并转到EC2仪表板。

2. 从左侧边栏点击实例。

3. 点击页面右上角的启动实例。

4. 对于名称，输入Cloudericks Web Server。

5. 在应用程序和操作系统镜像（Amazon 机器镜像）部分，选择Amazon Linux，在Amazon 机器镜像（AMI）中选择Amazon Linux 2023 AMI。

图 5.8 – 选择 Amazon Linux

1. 对于实例类型，选择t2.micro。

2. 对于密钥对（登录），请选择我们已经生成并且可以访问的密钥对名称，或者，如果没有密钥对，请点击创建新的密钥对链接并完成以下步骤：

   1. 输入一个密钥对名称。

   2. 设置密钥对类型为RSA。

   3. 设置私钥文件格式为.pem。

   4. 点击创建密钥对。

重要说明

我们应当妥善保存密钥。如果使用的是 Unix 或 Mac 系统，则需要使用chmod 400命令将文件权限更改为只读访问。

1. 在网络设置部分，点击编辑并执行以下操作：

   1. 对于VPC，选择我们命名为awsseccb-vpc的 VPC。

   2. 对于子网，选择us-east-1a 可用区中的公共子网。如果您已按照准备工作部分中的说明创建了子网，则这些信息已包含在子网名称中。

   3. 设置自动分配公共 IP为启用。

图 5.9 – 启动实例的网络设置

1. 在防火墙（安全组）部分的网络设置中，选择创建安全组。对于安全组名称，输入cloudericks-web-server。对于描述，在描述字段中将默认的安全组名称替换为cloudericks-web-server。

图 5.10 创建安全组

1. 在网络设置部分的入站安全组规则中，添加HTTP和HTTPS的规则，源类型选择任何地方。添加SSH规则，源类型选择我的 IP，只允许来自我们 IP 的 SSH。

重要说明

我们允许了来自自己 IP 地址的 SSH 流量。在生产环境中，SSH 访问通常会被限制为跳板主机或堡垒主机，这是一台专门配置的服务器，用于从外部来源安全且受控地访问内部网络。通过堡垒主机设置，我们首先登录到堡垒主机，然后从那里安全地登录到我们的 Web 服务器。我们还可以使用如 图 5.13 所示的选项之一，如 EC2 实例连接、会话管理器和 EC2 串行控制台。

1. 在 高级详情 部分，将以下脚本代码复制并粘贴到 用户数据 字段中：

    #!/bin/bash
   sudo su
   yum update -y
   yum install -y httpd
   cd /var/www/html
   echo "<html><h1>Cloudericks Web Server</h1></html>" > index.html
   systemctl start httpd.service
   systemctl enable httpd.service
   

2. 保持其他值和选择不变，点击 启动实例。实例启动成功后，转到 实例 页面，选择我们的新 EC2 实例，并查看其参数。

3. 复制 Public IPv4 DNS 或 Public IPv4 地址，在浏览器标签页中打开，并使用 http 而不是 https。我们应该能够看到 Web 服务器的 index.html 页面。

图 5.11 – 从浏览器访问 Web 服务器的 index.html 页面

在本节中，我们创建了一个简单的 Web 服务器，并通过 HTTP 从互联网访问网页。由于我们使用的是 HTTP 而不是 HTTPS，因此它被列为 不安全。如果我们尝试使用 HTTPS 运行该 URL，它将返回类似于以下的响应：

图 5.12 – 无 HTTPS 网站

在下一节中，我们将使用 SSH 连接到实例，并在 第六章 中启用该机器的 HTTPS。

使用 SSH 连接到 EC2 实例

我们可以按如下方式通过 SSH 连接到 EC2 实例：

1. 转到 EC2 仪表盘中的 实例 页面。

2. 选择我们的实例，并从 操作 下拉菜单中点击 连接。这将为我们提供连接 EC2 实例的方式，如 EC2 实例连接、会话管理器、SSH 客户端 和 EC2 串行控制台。

图 5.13 – 连接实例选项

1. 转到 SSH 客户端 标签页。我们应该能看到通过 SSH 连接到实例的步骤，如下图所示：

图 5.14 – 使用 SSH 客户端连接到实例

1. 我们可以按照给定步骤连接到 EC2 实例。如果是第一次连接实例，我们会收到确认消息，要求信任该站点并继续连接。输入 yes 以继续：

图 5.15 – 使用 SSH 连接到实例

我们使用 SSH 连接到我们的实例。值得注意的是，除了传统的 SSH 连接外，还有一些其他的选项，例如 EC2 实例连接、会话管理器和 EC2 串行控制台，正如我们在 图 5 .13 中所看到的那样。

工作原理...

首先，我们使用 EC2 用户数据设置了一个 Web 服务器。EC2 用户数据功能允许我们配置一组脚本或命令，这些脚本或命令在实例首次启动时仅运行一次。此功能对于安装软件、更新系统、下载文件或配置符合特定要求的设置非常有用。用户数据脚本在实例启动之前就会注入到实例中，因此它是一种高效的启动方式，能够在实例变为可用的瞬间就为其配置所需的所有设置和软件。这有助于确保实例从投入使用之初就已经为其角色做好了充分准备，无论是 Web 服务器、数据库还是其他任何服务。此功能显著简化了部署过程，避免了手动设置，并使得云架构设计更加灵活且具有可扩展性。

我们也使用 SSH 连接到我们的实例。SSH 是一种加密网络协议，用于在不安全的网络上实现客户端与服务器之间的安全通信。它广泛应用于多种网络服务，其中最常见的是远程命令行登录和执行。SSH 提供了一个安全的通道，即使在不安全的网络上也能加密交换的数据，以防止未经授权的访问、窃听和劫持。除了其主要的远程安全管理功能外，SSH 还支持隧道、转发 传输控制协议（TCP）端口，并使用相关协议（如 SFTP 或 SCP）传输文件。由于其多功能性和安全特性，SSH 成为管理服务器、配置网络和通过互联网安全传输数据的必备工具。

还有更多...

我们使用 SSH 连接到我们的实例。AWS 还提供了一些连接实例的其他选项，正如我们在 图 5 .14 中所看到的那样。让我们快速探索一下它们。

EC2 实例连接提供了一种简单且安全的方式，让你可以直接从 AWS 管理控制台使用 SSH 连接到你的实例。与传统的 SSH 不同，传统 SSH 需要你管理 SSH 密钥，而实例连接会为每个连接会话生成一次性使用的 SSH 密钥，自动处理密钥管理。这种方法通过避免手动共享和管理 SSH 密钥来增强安全性，并通过 AWS IAM 策略提供了一个简单的访问控制方式。

AWS Systems Manager 会话管理器是 AWS Systems Manager 的一项功能，允许你通过交互式 Shell 或自动化脚本管理 EC2 实例，而无需打开入站端口、设置堡垒主机或管理 SSH 密钥。它提供了安全的、可审计的实例管理，而不需要传统访问方法的复杂性。会话管理器的会话是加密的，并且可以被记录和审计，是企业在关注安全性和合规性时的理想选择。它还与 AWS IAM 集成，用于访问控制。

EC2 串行控制台允许你通过提供安全的串行访问来排查启动和网络连接问题。这在无法通过 SSH 或 RDP 连接实例时特别有用。访问串行控制台不需要网络连接，因此它是解决防止实例正确启动问题的宝贵工具。对 EC2 串行控制台的访问通过 IAM 策略进行控制，确保只有授权用户可以使用此功能。

这些连接方式各自适用于不同的使用场景，从通过 EC2 实例连接简化 SSH 密钥管理、通过会话管理器提供安全且可审计的访问，到通过 EC2 串行控制台提供最后的故障排除工具。根据我们的安全需求、操作实践和故障排除需求，我们可以选择最适合我们场景的方法。

另见

• 阅读更多关于不同方式连接到 EC2 实例的内容，请访问www.cloudericks.com/blog/different-ways-to-connect-to-ec2-instances-in-aws。

• 我们可以通过加密 EBS 实例来进一步提高 EC2 的安全性，具体步骤请参考www.cloudericks.com/blog/steps-to-encrypt-ebs-data-with-aws-kms。

创建和配置安全组

在本食谱中，我们将学习如何通过 VPC 仪表板创建安全组。也可以按照类似的步骤从 EC2 仪表板创建安全组。我们还可以在启动 EC2 实例时创建安全组。

准备工作

要完成本食谱中的步骤，我们需要以下配置：

• 一个有效的 AWS 账户是必需的。我将使用在 第一章 中创建的awsseccb-sandbox-1账户。但我不会使用 AWS Organizations 或 IAM 身份中心的任何功能。

• 我们需要创建一个 VPC 并在其下创建一个公有子网。可以按照本章中的创建一个裸 VPC 并设置公有和私有子网的食谱来创建 VPC 和子网。

如何操作...

我们可以按如下方式从 VPC 仪表板创建安全组：

1. 转到 VPC 仪表板。

2. 在左侧边栏的安全性下，点击安全组。

3. 在安全组页面，点击创建安全组。

4. 提供安全组名称和描述的值；选择我们的 VPC。

图 5.16 – 创建安全组

1. 在同一页面的入站规则下，我们需要添加以下规则：

   1. 点击添加规则。将类型设置为HTTP，将源类型设置为Anywhere-IPv4，并将源设置为0.0.0.0/0。

   2. 点击添加规则。将类型设置为HTTPS，将源类型设置为Anywhere-IPv4，并将源设置为0.0.0.0/0。

   3. 点击添加规则。将类型设置为SSH，将源类型设置为我的 IP。我们的 IP 地址应自动填充在源下。

图 5.17 – 设置安全组的入站规则

提示

如果需要 IPv6 流量，我们还可以在规则中将Source下的 CIDR 范围设置为::/0。

1. 在出站规则下，我们可以看到已经创建了一个默认规则，如下所示：

图 5.18 – 默认出站规则

重要提示

默认的安全组出站规则允许所有出站流量。为了增强安全性，我们可以只为所需的协议提供出站访问，如 HTTP 和 HTTPS。

如果我们需要更改出站规则，以便仅允许 HTTP 和 HTTPS 流量，可以在同一页面编辑默认规则，如下所示：

1. 将类型设置为HTTP，将目标类型设置为Anywhere-IPv4，并将目标设置为0.0.0.0/0。

2. 点击添加规则。将类型设置为HTTPS，将目标类型设置为Anywhere-IPv4，并将目标设置为0.0.0.0/0。

图 5.19 – 安全组的出站规则

提示

如果需要 IPv6 流量，我们还可以在规则中将Destination下的 CIDR 范围设置为::/0。

1. 向下滚动并点击创建安全组。

   我们应该会看到一条成功消息，表示安全组已创建。

重要提示

确切的规则对于每个方案会有所不同。前述规则可能适用于托管 Web 服务器的公共子网实例。我们还为本地 IP 提供了 SSH 访问；然而，在大多数项目中，我们通常会为专用机器提供 SSH 访问，这些机器被称为跳跃主机或堡垒主机。

它是如何工作的...

在这个方案中，我们创建并配置了一个包含入站和出站规则的安全组，适用于在公共子网中运行 Web 服务器的 EC2 实例。我们将使用这些步骤在其他方案中创建安全组。具体规则可能会根据使用案例有所不同。我们也可以指定另一个安全组，而不是提供 CIDR 范围，以表明只有具有该安全组的实例才应该被允许。

在本章节后面的使用 NACL食谱中，我们将显式允许1024 – 65535临时端口范围的出站请求。由于安全组是有状态的，这在安全组中不需要。如果打开了一个出站端口，则通过该端口发送的请求的响应也会被允许，而不受入站规则的限制。同样，如果打开了一个入站端口，则通过该端口发送的请求的响应也会被允许，而不受出站规则的限制。

还有更多...

我们通过 VPC 仪表板创建了安全组。我们也可以通过 EC2 仪表板创建安全组。有关更多详细信息，请参阅本食谱中另请参阅部分的链接。

让我们快速浏览一些与安全组相关的重要概念：

• 安全组不能跨 VPC 使用。

• 我们可以通过 EC2 启动向导、EC2 仪表板或 VPC 仪表板来创建安全组。

• 安全组是有状态的，不像 NACL 那样无状态。

• 基于使用情况，最好创建多个安全组。例如，我们可以创建单独的安全组：一个用于 SSH，另一个用于应用程序特定的端口。我们可以配置安全组规则，允许来自另一个安全组的实例，而不是提供 CIDR。我们还可以指定自己的安全组，只允许同一安全组中的实例相互通信。

另请参阅

• 阅读有关 AWS 中安全组的更多信息，请访问www.cloudericks.com/blog/understanding-security-groups-in-aws。

• 有关安全组规则的参考资料，请访问docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules-reference.html。

使用 NACL

在本食谱中，我们将创建一个新的 NACL，且不支持 SSH，并将我们的一个子网与该 NACL 关联。通过这样做，我们将看到无法通过 SSH 连接到该子网中的 EC2 实例。之后，我们将为 NACL 添加 SSH 支持，并再次尝试 SSH。

准备工作

要完成本食谱中的步骤，我们需要以下内容：

• 我们需要创建一个 VPC 并在其下创建一个公共子网。我们可以通过参考本章节中的创建一个裸 VPC 并设置公共和私有子网食谱来创建 VPC 和子网。

• 我们需要为我们的实例创建一个安全组；该安全组应允许 SSH 的入站流量。我们可以通过参考本章节中的创建和配置安全组食谱来完成此操作。

• 我们需要一个启动到公共子网中的 EC2 实例；我们可以通过参考本章节中的使用用户数据启动带有 Web 服务器的 EC2 实例食谱来完成此操作。

如何操作...

我们可以创建一个没有 SSH 权限的 NACL，如下所示：

1. 进入控制台中的VPC服务。

2. 点击左侧边栏中的网络 ACL。

3. 点击页面顶部的创建网络 ACL。

4. 在 创建网络 ACL 的 网络 ACL 设置 中，提供一个名称并从下拉列表中选择我们在上一节中创建的 VPC 作为 VPC 字段。

5. 点击 创建网络 ACL 来创建网络 ACL。

图 5.20 – 创建网络 ACL

如果我们进入 NACL 列表，我们会看到新创建的 NACL 没有任何关联的子网。

图 5.21 – 没有任何关联子网的新 NACL

1. 选择我们的新 NACL，向下滚动，并分别从其 入站规则 和 出站规则 标签中验证新 NACL 的入站和出站规则。

   入站规则应如下所示：

图 5.22 – 新创建的 NACL 的入站规则

出站规则应如下所示：

图 5.23 – 新创建的 NACL 的出站规则

1. 点击 子网关联 标签。

2. 点击 编辑子网关联。

3. 选择我们创建的子网（AWSPublicSubnet），然后点击 保存更改。

图 5.24 – 关联子网

选择我们的新网络 ACL 并检查其子网关联。我们的公共子网现在应该已经与其关联。

图 5.25 – 关联子网的 NACL

1. 尝试 SSH 连接到我们的公共 EC2 实例。在 CLI 中运行以下命令：

   ssh -i "<key path>" <EC2 user name@the public ip>
   

   <key path> 路径是你下载的密钥对路径，它是 通过用户数据启动带有 Web 服务器的 EC2 实例 配方中提到的 准备工作 部分的一部分。对于 <EC2 用户名@公共 IP>，请进入 实例，选择我们创建的 EC2 实例，然后点击 连接。点击 SSH 客户端 标签。复制 示例 命令的第二部分，如 ec2-user@54.198.244.252。它将类似于以下内容：

   ssh -i "C:\Users\DELL\Downloads\awsdemo.pem" ec2-user@35.174.184.142
   

提示

如果我们使用 AWS CloudShell，我们可以直接使用 SSH 客户端 标签中的 示例 命令，而无需任何修改。它看起来类似于 ssh -i "awsdemo.pem" ec2-user@35.174.184.142。确保在运行命令之前上传密钥对文件。

具体的命令或步骤可能因操作系统而异。在 Windows、macOS 和大多数 Linux 系统上，我们可以使用 SSH 命令。

操作应该会超时，如下图所示：

图 5.26 – 没有 SSL 的连接超时响应

1. 现在，我们可以按照以下方式为我们的 NACL 添加 SSH 支持：

   1. 返回到 VPC 控制台，点击左侧边栏中的 网络 ACLs，然后选择我们的 NACL。

   2. 点击 入站规则。

   3. 点击 编辑入站规则。

   4. 点击 添加新规则。

   5. 在 规则编号 下输入 100，在 类型 下选择 SSH (22)，将源设置为 0.0.0.0/0，将 允许/拒绝 设置为 允许，然后点击 保存更改。

重要提示

如果我们现在尝试 SSH 连接到 EC2 实例，SSH 将会失败，因为我们没有启用出站流量的临时端口。

1. 点击 出站规则。

2. 点击 编辑出站规则。

3. 点击 添加新规则。

4. 在 规则编号 下输入 100，在 类型 下选择 自定义 TCP，将 端口范围 设置为 1024 - 65535，将 允许/拒绝 设置为 允许，将 目标 设置为 0.0.0.0/0，然后点击 保存更改。

5. 尝试 SSH 连接到我们的公共 EC2 实例。不同操作系统间的具体命令或步骤可能有所不同。在 Windows、macOS 和大多数 Linux 系统上，我们可以使用以下 SSH 命令：

   ssh -i "C:\Users\DELL\Downloads\awsdemo.pem" ec2-user@35.174.184.142
   

   现在，我们应该能够成功 SSH 连接了。

图 5.27 – 成功的 SSH 响应

在本教程中，我们只添加了一个入站规则和一个出站规则。根据需要，我们可以添加更多规则。

它是如何工作的…

NACL 允许我们为 VPC 的子网定义入站和出站规则。我们可以明确地允许或拒绝通过某个端口或端口范围的流量。AWS 创建的默认 NACL 允许所有入站和出站流量。然而，默认情况下，自定义 NACL 会拒绝所有入站和出站流量。首先，我们创建了一个新的 NACL。然后，我们将公共子网与该 NACL 关联，并验证我们无法从本地机器 SSH 连接。新的 NACL 默认会拒绝所有入站和出站流量。为了允许 SSH，我们在 NACL 中添加了一个入站规则用于 SSH，并添加了一个出站规则以允许 1024 – 65535 的临时端口范围。

重要提示

临时端口是用于 IP 通信的短暂端口，适用于 TCP、用户数据报协议（UDP）、流控制传输协议（SCTP）等传输协议。它通常用于返回流量，即我们连接的实例或服务的返回流量。例如，服务器在端口 22 接收 SSH 流量，然后通过某个临时端口与客户端通信。在本教程中，我们添加了允许临时端口范围的出站规则，这是 AWS 针对面向公众的实例建议的端口范围，适用于不同类型的客户端。

还有更多内容...

让我们快速回顾一下与网络 ACL 相关的一些重要概念：

• 当我们创建一个 VPC 时，AWS 会创建一个默认的 NACL。在 VPC 的 NACL 列表中，默认 列的值会显示为 是，表示这是默认的 NACL。

• 默认的 NACL 允许所有入站和出站流量。然而，当我们创建一个新的自定义 NACL 时，默认情况下所有的入站和出站流量都会被拒绝。

• 每个子网只能与一个 NACL 关联。默认情况下，一个子网会与默认的 NACL 关联。

• 一个子网一次只能与一个 NACL 关联。当我们将其与新的 NACL 关联时，当前的关联将被移除。

• 一个 NACL 可以与多个子网关联。

• NACL 包含一组编号的规则，这些规则按规则编号的顺序进行评估。如果我们在Deny规则之前有Allow规则，且规则针对相同端口，那么该端口的访问将被允许。类似地，如果我们在Allow规则之前有Deny规则，且规则针对相同端口，那么该端口的访问将被拒绝。AWS 建议最初使用 100 的倍数作为规则编号，这样如果需要添加新规则，就能在其间添加。

• 我们可以使用 NACL 阻止特定 IP 地址，但使用安全组无法做到这一点。

• NACL 在安全组之前进行评估。

• 安全组被视为有状态的，而 NACL 被视为无状态的。使用安全组时，如果我们从实例发送请求，响应会被允许，无论入站规则如何。类似地，如果我们允许入站请求，相应的出站响应也会被允许，无论出站规则如何。使用 NACL 时，我们需要显式地为任何端口允许入站和出站流量。

另见

阅读更多关于 NACL 的信息，请访问www.cloudericks.com/blog/understanding-network-acls-in-aws-vpc。

使用 VPC 网关端点连接到 S3

在此配方中，我们将为 S3 创建一个VPC 网关端点，并从我们的私有子网连接到 S3，而不使用互联网访问。

准备工作

为了完成此配方中的步骤，我们需要准备以下内容：

• 我们需要一个 VPC 以及关联的子网。我们可以参考本章中的创建一个裸 VPC 并设置公共和私有子网配方来创建。

• 我们需要配置一个网关和路由表以实现互联网访问。我们可以参考本章中的创建一个裸 VPC 并设置公共和私有子网配方。

• 子网应与默认的 NACL 关联。否则，我们应定义适当的入站和出站规则，以便可以通过公共 EC2 实例登录到私有 EC2 实例。我们可以参考本章中的使用 NACL配方。

• 我们需要在任何区域中创建一个 S3 存储桶。我将使用us-east-1区域。

• 我们应该确保私有子网没有互联网访问权限。通过在私有子网中运行aws s3 ls --region us-east-1来验证这一点。我们的请求应该会因超时而失败。如果已配置了 NAT 网关或 NAT 实例，请从主路由表中删除其路由。

• 将具有 S3 访问权限的 IAM 角色与私有 EC2 实例关联。

提示

如果没有正确配置 IAM 角色，可能会遇到无法定位凭证的错误。你可以通过运行aws configure来配置凭证。解决问题后，请再次测试，然后再继续操作。

如何操作...

我们可以按如下方式为 S3 创建一个 VPC 端点网关：

1. 在控制台中进入VPC服务。

2. 从左侧边栏点击终端节点。

3. 点击创建终端节点。

4. 在创建终端节点面板中，在终端节点设置下，输入VPCEndpoint作为名称标签的值。

5. 在服务类别下，选择AWS 服务。

6. 在服务名称下，选择com.amazonaws.us-east-1.s3

图 5.28 – 为终端节点创建选择服务名称

1. 对于VPC，选择我们在准备工作部分创建的 VPC。

2. 对于路由表，选择我们在准备工作部分创建的路由表。

3. 保持策略字段设置为完全访问。

4. 点击创建终端节点。我们应该看到成功消息。

5. 连接到我们的 EC2 实例，并尝试从私有子网运行以下 S3 命令：

    aws s3 ls --region us-east-1
   

图 5.29 – S3 列表操作的成功响应

这应该能够成功列出 S3 项目。

它是如何工作的...

VPC 终端节点允许我们从 VPC 私密地连接到支持的 AWS 服务。通过 VPC 终端节点，VPC 中的实例不需要公共 IP 地址就可以与支持的 AWS 服务通信。VPC 与支持的 AWS 服务之间的流量不会离开 AWS。VPC 终端节点可以视为高可用的虚拟设备。

在本教程中，我们配置了一个网关类型的 VPC 终端节点，以便从子网访问 S3。我们从子网中删除了所有公共路由，但仍然能够连接到 S3。VPC 网关终端节点也支持DynamoDB，并且与 VPC 网关类似工作。对于大多数其他服务，VPC 终端节点通过接口终端节点进行支持。

还有更多...

让我们快速回顾一些与 VPC 终端节点相关的重要概念。有两种类型的 VPC 终端节点：

• 接口终端节点：这是一种具有私有地址的弹性网络接口（ENI），允许流量进入支持的服务。大约有 20 种支持的服务。这些服务的例子包括 Amazon API Gateway、Amazon CloudWatch、AWS Config、AWS KMS 等。

• 网关终端节点：像 NAT 网关一样，它们没有私有 IP 地址。仅支持有限的服务，如 S3 和 DynamoDB。

另请参见

阅读更多关于 VPC 网关终端节点的内容，请访问 www.cloudericks.com/blog/understanding-aws-vpc-gateway-endpoint。

配置和使用 VPC 流日志

在本教程中，我们将在 VPC 级别启用流日志。

准备工作

我们需要以下资源来完成本教程中的步骤：

• 需要一个CloudWatch 日志组。详细步骤将在本节后续提供。

• 我们需要设置一个 VPC。如果之前没有创建 VPC，请参考创建一个裸 VPC 并设置公有和私有 子网 的食谱。

• 还需要一个具有发布权限的 IAM 角色，该角色能够完全访问 CloudWatch 日志组。

我们可以执行以下步骤来创建 CloudWatch 日志组：

1. 转到 AWS 控制台中的 CloudWatch 服务。

2. 从左侧边栏点击日志。

3. 点击日志组，然后点击创建日志组。

4. 给日志组命名，以描述其目的，保持其他值为默认值，然后点击创建。

如何操作...

我们可以通过控制台按以下步骤配置 VPC 流日志：

1. 转到控制台中的VPC服务。

2. 点击您的 VPC。

3. 选择我们的 VPC。

4. 点击流日志选项卡。

5. 点击操作下拉菜单，然后选择创建流日志。

6. 在流日志设置下，提供名称，并在过滤器中选择全部。

7. 对于最大聚合间隔，根据个人偏好选择时间。

8. 将目标设置为发送到CloudWatch 日志。

9. 从目标日志组下拉菜单中选择我们在准备工作部分创建的日志组。

10. 从下拉列表中选择我们在准备工作部分创建的IAM 角色选项。

11. 对于日志记录格式，选择AWS默认格式。

12. 点击创建流日志。我们应该看到一个成功的消息。我们应该能够在流日志中查看所有后续的 IP 流量日志。以下是来自 VPC 日志日志组的日志记录示例：

图 5.30 – 一个示例日志记录

它是如何工作的...

VPC 流日志帮助我们捕获到达和离开 VPC 的 IP 流量。VPC 流日志的数据可以发布到 CloudWatch 日志或 S3 存储桶。我们可以选择仅记录接受的流量、拒绝的流量或两者。VPC 流日志可以在不同级别创建，例如 VPC 级别、子网级别和网络接口级别。

在本食谱中，在过滤器下拉菜单中，我们选择了全部，以记录所有进出 VPC 的 IP 流量。我们可以选择接受来记录仅接受的流量，选择拒绝来记录仅拒绝的流量，选择全部来记录接受和拒绝的流量。我们需要一个 CloudWatch 日志组和一个具有权限的 IAM 角色，以便记录到该日志组。

还有更多...

让我们快速了解一些与流日志相关的重要概念：

• 目前，一旦流日志配置创建完成，我们无法更改其配置，例如更改关联的 IAM 角色。

• 以下是一些流量类型，包括此处列出的流量，不会被流日志监控：

  • 流量到达默认 VPC 路由器的保留 IP 地址

  • 动态主机配置协议（DHCP）流量

  • 流量设置为169.254.169.254以查询实例元数据

  • 与 Amazon DNS 服务器通信时的流量；但是，指向我们自己 DNS 服务器的流量会被记录。

  • Windows 许可证激活流量

另见

• 在www.cloudericks.com/blog/understanding-aws-vpc-flow-logs了解更多关于 VPC 流日志的信息。

• 在docs.aws.amazon.com/vpc/latest/userguide/flow-logs-records-examples.html查找日志记录的示例。

设置和配置 NAT 网关

在本教程中，我们将学习如何创建和配置 NAT 网关，这是 AWS 中最新和首选的 NAT 选项。

准备工作

要完成本教程中的步骤，我们需要以下内容：

• 一个有效的 AWS 账户是必需的。我将使用我们在第一章中创建的awsseccb-sandbox-1账户。

• 通过遵循本章中的创建裸 VPC 并设置公共和私有子网教程，创建一个 VPC、子网、IGW 和路由表。

• 按照创建和配置安全组教程和与 NACLs 一起使用教程的准备工作部分，在公共和私有子网中启动具有适当安全组配置的实例。

如何操作…

我们可以按如下方式创建 NAT 网关：

1. 转到VPC 仪表板。

2. 点击左侧面板中的NAT 网关。

3. 点击创建NAT 网关。

4. 在NAT 网关设置下，输入NAT-Gateway作为名称。

5. 对于子网，在下拉列表中选择我们的公共子网。

6. 对于连接类型，选择公共。

7. 点击分配弹性 IP，填充弹性 IP 的分配 ID 并选择它作为弹性 IP 分配 ID，或者如果我们已经创建了弹性 IP，我们可以选择其中一个。填写后的页面应如下所示：

图 5.31 – NAT 网关设置

1. 点击创建 NAT 网关。我们会看到一条消息，提示 NAT 网关已成功创建。

2. 点击路由表，选择我们的公共路由表，转到路由标签页。点击编辑路由，然后点击添加路由。选择0.0.0.0/8作为目标。在目标的下拉菜单中，选择NAT 网关，然后选择我们在步骤 8中创建的 NAT 网关。点击保存更改。

3. 返回到 EC2 实例，选择我们的实例，点击连接，然后在连接到实例页面上，再次点击连接。

4. 尝试从终端运行任何需要互联网访问的命令，示例如下：

   ping google.com
   

   如果有通向互联网的路由，我们应该收到成功的响应；否则，连接会超时：

图 5.32 – ping 命令的成功响应

我们也可以运行如下的 yum 更新命令：

sudo yum update

按照剩余提示操作。如果有通往互联网的路由，更新将会成功；否则，操作将超时。

它是如何工作的……

私有子网中的实例可能需要访问互联网，进行补丁管理、软件下载等操作。NAT 允许 VPC 中的私有子网与互联网进行通信。NAT 是通过修改数据包的 IP 头部，在传输过程中重新映射 IP 地址的过程。AWS 为我们提供了两种在 VPC 中实现 NAT 的方式：NAT 网关和 NAT 实例。在本示例中，我们创建并配置了一个 NAT 网关。与 NAT 实例不同，NAT 网关不与任何安全组关联，因此我们没有创建或配置任何安全组。

在创建 NAT 网关后，我们需要在与私有子网关联的路由表中为其添加一条路由。由于我们的私有子网与主路由表关联，因此我们在主路由表中添加了该路由。如果某个子网没有明确与任何路由表关联，它将隐式地与主路由表关联。如果我们的架构中私有子网使用了不同的路由表，我们需要在该路由表中为 NAT 网关添加路由。

还有更多……

让我们快速浏览一些与 NAT 网关相关的重要概念：

• NAT 网关由 AWS 维护，AWS 负责补丁管理、可用性和扩展。

• NAT 网关不与任何安全组关联。NAT 网关在一个可用区内是冗余的，但不能跨可用区使用。因此，为了更好的可用性，我们可能需要为每个区域创建一个 NAT 网关。

• 当前，NAT 不支持 IPv6 流量。我们需要使用仅出口的 IGW 而不是 NAT 来处理 IPv6 流量。我们可以从 VPC 控制台创建一个仅出口的 IGW。

另见

• 了解更多关于 NAT 网关的信息，请访问www.cloudericks.com/blog/understanding-nat-gateways-in-aws。

• 了解如何使用 PrivateLink 安全地将我们的 VPC 连接到支持的 AWS 服务、其他 VPC 和本地应用程序，而无需将流量暴露到公共互联网，请访问www.cloudericks.com/blog/understanding-aws-privatelink。

第六章：使用证书、CDN 和防火墙实现 Web 安全

在今天这个互联的数字环境中，Web 安全至关重要。为了保持数据的完整性和机密性，结合使用多种工具和技术是至关重要的。本章重点介绍三大关键组件——证书、内容分发网络（CDN）和防火墙。我们还将看到如何将证书与负载均衡器一起使用。证书，尤其是 X.509，在通过启用TLS（即传输层安全性）来确保客户端和服务器之间的通信安全方面发挥着至关重要的作用。这种加密有助于保护传输中的数据，对于防止数据泄露和维护隐私至关重要。

负载均衡器通过高效地将传入的网络流量分配到多个服务器，增强了 Web 服务的可靠性和性能。通过这样做，它们确保没有单一服务器承受过多负载，从而防止了停机并优化了资源使用。当与证书一起使用时，负载均衡器提供了管理安全措施（如 TLS 终止）的灵活性，允许集中处理证书，这简化了安全管理并提升了性能。

CDN 通过在多个地理位置缓存内容，靠近用户，从而提高网站加载速度并减少带宽成本。它们还通过防御分布式拒绝服务（DDoS）攻击，增强 Web 应用程序的可用性和性能，增加了一层安全防护。

最后，防火墙在定义和执行网络安全边界方面至关重要。它们监控和控制进出网络的流量。在 AWS 等环境中集成防火墙有助于构建强大的防御，抵御潜在威胁，为整体安全策略做出重要贡献。本章将探讨这些组件在 AWS 中的实际应用，提供构建安全、可扩展 Web 基础设施的知识。

本章将涵盖以下食谱：

• 为 EC2 实例上的 Web 服务器启用 HTTPS

• 使用 ACM 创建 SSL/TLS 证书

• 创建 ELB 目标组

• 使用带有 TLS 终止的应用负载均衡器（ELB）

• 使用带有 TLS 终止的网络负载均衡器（EC2）

• 使用 CloudFront 和 TLS 安全化 S3

• 使用 WAF

技术要求

在深入本章的食谱之前，我们需要确保具备以下要求和知识：

• 为了完成本章中的操作，我们需要一个有效的 AWS 账户。我们可以使用属于 AWS 组织的账户或独立账户。我将使用我们在第一章的多账户管理与 AWS Organizations食谱中创建的awsseccb-sandbox-1账户。 但是，我不会使用任何 AWS Organizations 功能，这意味着你也可以使用独立账户来跟随这些步骤。

• 对于管理操作，我们需要一个具有AdministratorAccess权限的用户来操作我们将使用的 AWS 账户。这个用户可以是 IAM 身份中心用户或 IAM 用户。我将使用我们在第一章的用户管理与 IAM 身份中心 SSO食谱中创建的awsseccbadmin1 IAM 身份中心用户。 但是，我不会使用任何 IAM 身份中心功能，这意味着如果该用户在账户中具有AdministratorAccess权限，你也可以作为 IAM 用户跟随这些步骤。你可以参考设置 IAM、账户别名和账单警报食谱来创建一个 IAM 用户。

本书的代码文件可以在github.com/PacktPublishing/AWS-Security-Cookbook-Second-Edition找到。本章的代码文件可以在github.com/PacktPublishing/AWS-Security-Cookbook-Second-Edition/tree/main/Chapter06找到。

为 EC2 实例上的 Web 服务器启用 HTTPS

在第五章的使用用户数据启动带 Web 服务器的 EC2 实例食谱中，我们启动了一个没有启用 HTTPS 的 EC2 实例。在这个食谱中，我们将展示如何使用自签名证书在该 Web 服务器上启用 HTTPS。这将帮助我们理解在 EC2 实例上启用 HTTPS 的基本概念。然而，实际应用中，建议使用本章其他食谱中提到的、由证书颁发机构（CA）签署的证书方法，例如AWS 证书管理器（ACM）。

准备工作

为了成功完成本食谱，我们需要以下内容：

• 一个有效的 AWS 账户awsseccb-sandbox-1，以及一个用户awsseccbadmin1，如技术要求部分所述。

• 一个名为Cloudericks Web Server的 EC2 实例，启动自第五章的使用用户数据启动带 Web 服务器的 EC2 实例食谱。

如何操作...

我们将使用自签名证书启用 HTTPS，如下所示：

1. 安装 Apache mod_ssl模块：

   sudo yum install -y mod_ssl
   

2. 生成私钥是为 Web 服务器设置 HTTPS 加密的第一步。私钥是 SSL/TLS 加密过程中的关键组成部分。使用以下命令生成私钥：

   sudo openssl genrsa -out /etc/pki/tls/private/localhost.key 2048
   

   这将不会返回任何内容，但会生成一个 2,048 位的 RSA 私钥，并保存在/etc/pki/tls/private/localhost.key 文件中。

3. 使用以下命令生成一个证书签名请求（CSR），该请求使用前一步生成的私钥：

   sudo openssl req -new -key /etc/pki/tls/private/localhost.key -out /etc/pki/tls/certs/localhost.csr
   

4. 在命令行中运行前一步的命令后，当提示时，输入如下图所示的值：

图 6.1 – 证书签名请求

1. 使用前一步生成的 CSR 来创建一个自签名证书：

   sudo openssl x509 -req -days 365 -in /etc/pki/tls/certs/localhost.csr -signkey /etc/pki/tls/private/localhost.key -out /etc/pki/tls/certs/localhost.crt
   

图 6.2 – 创建自签名证书

当我们运行此命令时，OpenSSL 会读取 CSR，使用私钥对其进行签名，并生成一个自签名证书（localhost.crt）。该证书随后可以被您的 Web 服务器（例如，Apache）用来启用 HTTPS 加密，并与客户端建立安全通信。证书将保存在/etc/pki/tls/certs/localhost.crt 位置。

1. 使用以下命令重新启动 Apache 服务器：

   sudo systemctl restart httpd
   

2. 使用 HTTPS 前缀访问我们的 Web 服务器 URL，如在第五章中的使用 EC2 用户数据设置 Web 服务器一节的最后一步所示。我们现在应该会收到响应，但也可能会出现不安全的警告，因为我们使用了自签名证书。

图 6.3 – 带有自签名证书的 HTTPS URL

在本节中，我们使用自签名证书在我们的 EC2 实例上为 Web 服务器启用了 HTTPS。在下一篇文章中，我们将探讨如何通过使用 CA 签名的证书来增强安全性。

它是如何工作的...

首先，我们安装了 Apache mod_ssl 模块。此模块为我们的 Apache 服务器添加了 TLS 支持。mod_ssl 模块是启用 Apache 中 SSL/TLS 支持所必需的，必须在生成自签名证书之前安装并配置该模块。该模块的当前版本还支持 SSL v3 和所有版本的 TLS。首先，使用 OpenSSL 生成私钥。然后，创建一个证书签名请求（CSR）并使用该密钥生成自签名证书。重启 Apache 以应用更改，并允许通过防火墙的 HTTPS 流量。在 Web 浏览器中测试 HTTPS 访问。

还有更多...

在本教程中，我们使用了自签名证书，并遇到了不安全的警告，如 图 6 .3 所示。为了解决这个问题，我们可以通过 CA 生成证书。CA 是在验证组织或个人后发放数字证书的实体。通过从 CA 获取证书，我们可以确保 SSL/TLS 证书被大多数 Web 浏览器和用户设备信任，从而消除关于不安全连接的警告。CA 在互联网的运作及加密通信的建立中发挥着至关重要的作用。

证书颁发机构（CA）有多种类型，从大型、广泛认可的机构到发行证书给公众，到较小的私人 CA，这些 CA 可能是某个组织内部使用的。像 Verisign、Comodo 和 DigiCert 这样的公共 CA 提供广泛的验证服务，包括 扩展验证 (EV) 和 组织验证 (OV) 证书，这些证书提供更高的安全性和信任度。对于处理敏感交易的网站，这些证书可以提升可信度和用户信任。

像 AWS、Microsoft Azure 和 Google Cloud 这样的云服务提供商提供集成的 SSL/TLS 证书管理解决方案，简化了证书在其生态系统中的配置、管理和部署。ACM 非常适合 AWS 原生服务，自动化证书续期和管理，但它限制了证书的导出到 AWS 以外的地方。Microsoft Azure 的 Key Vault 允许集中管理证书，包括来自外部 CA 的证书，并与 Azure 服务无缝集成。Google Cloud 为其负载均衡器提供托管的 SSL 证书，支持自动续期和部署。

此外，对于需要快速、成本效益高的解决方案的开发人员和小型企业，像 Let’s Encrypt 这样的自动化 CA 提供 域名验证 (DV) 证书，且无需费用。这些证书通过自动化过程颁发，旨在确保申请人控制证书中列出的域名。这种方法高效且非常适合快速保护网站。

最终，选择证书颁发机构取决于我们的具体安全需求、所需的信任级别和预算。每种类型的 CA 提供不同的功能和安全级别，因此选择与您的安全目标和客户信任相符的 CA 至关重要。

另见

阅读更多关于 SSL 和 TLS 的内容，访问 www.secdops.com/blog/ssl-tls-and-https-a-beginners-guide-to-web-security。

使用 ACM 创建 SSL/TLS 证书

在本示例中，我们将使用AWS 证书管理器（ACM）为我们拥有的公共域名创建一个X.509 证书。ACM 公共证书用于 AWS 服务，如弹性负载均衡（ELB），Amazon CloudFront，AWS Elastic Beanstalk，Amazon API Gateway 和AWS CloudFormation。

准备工作

我们需要以下内容才能成功完成此示例：

• 一个有效的 AWS 帐户，awsseccb-sandbox-1，和一个用户，awsseccbadmin1，如技术 要求部分所述。

• 与任何域名提供商（包括 AWS）一起，访问其控制面板的域名。我将使用一个名为trainso.io的域名。

如何实施...

我们可以按以下步骤在 ACM 中创建 TLS 证书：

1. 转到AWS 证书管理器仪表板。如果您是第一次使用 ACM，您应该看到开始选项。目前，AWS 提供选项，以便我们可以提供证书，并创建私有 CA。

图 6.4 – AWS 证书管理器仪表板

1. 在左侧边栏中，我们应该看到导入证书，列出证书，请求证书和AWS 私有 CA选项。点击请求证书。

2. 选择请求公共证书并点击下一步。

图 6.5 – 证书类型配置

1. 在域名文本框中输入完全合格的域名。为了包括所有子域，我将使用带有域名的通配符*.trainso.io。

2. 对于验证方法，选择DNS 验证 - 推荐。

图 6.6 – 选择验证方法

1. 对于密钥算法，选择RSA 2048。

图 6.7 – 选择关键算法

1. 在添加标签屏幕上，如有需要添加标签，然后点击请求。我们应该在证书页面上看到新证书。我们还可以使用左侧边栏的列出证书选项进入证书页面。我们的证书状态将是等待验证。

2. 在证书页面上，点击超链接的证书 ID 进入证书页面。

3. 向下滚动到域名部分，复制 CNAME 名称和 CNAME 值，并将其添加到我们的域名提供商控制面板中的 DNS 记录中。请注意，对于大多数域名提供商，你只需要复制并粘贴 CNAME 值中的第一部分（即在第一个点 . 之前的部分），而不需要复制完整的 CNAME（Canonical Name）。例如，如果我们的 CNAME 值是_b262683f801a4eb13d8eb4a36cd8a2ba.trainso.io.，我们可能只需要在域名提供商控制面板中输入_b262683f801a4eb13d8eb4a36cd8a2ba作为 CNAME 值，而不包括后面的.trainso.io.。域名提供商可以是 Amazon Route 53 或外部提供商，如 Namecheap 或 GoDaddy。DNS 配置不在本书的范围之内，但我会在此教程的另见部分提供一些有用的参考。

4. 一旦 CNAME 记录更新完毕，我们可以进入证书界面并查看状态。成功后，证书的状态栏的值会变为已颁发。DNS 更改可能需要一些时间才能传播。如果状态为待验证，请过一段时间再检查，或使用刷新按钮刷新页面，直到状态变为已颁发。

工作原理...

在这个教程中，我们使用 ACM 创建了一个证书。我们可以为一个或多个域名请求证书。我们需要指定一个完全限定的域名，例如www.trainso.io，或者一个使用通配符的域名，如*.trainso.io，表示trainso.io的所有子域名。

在颁发证书之前，我们需要验证域名的所有权。我们可以通过 DNS 验证或邮件验证来完成此操作。在本教程中，我们使用了 DNS 验证。AWS 会为每个域名提供一个 CNAME 记录用于 DNS 验证。我们需要在域名的 DNS 管理服务中更新这个 CNAME 记录。Route 53 是 Amazon 的 DNS 管理服务。

还有更多...

ACM 公共证书支持 AWS 服务，如 ELB、Amazon CloudFront、AWS Elastic Beanstalk、Amazon API Gateway 和 AWS CloudFormation。AWS 不允许我们使用 ACM 公共证书来为我们的 EC2 实例启用 SSL/TLS。然而，通过 ACM 私有 CA 颁发的证书可以用于 EC2 实例、容器，甚至我们自己的服务器。

AWS 不会向我们收取通过 ACM 提供的公共 TLS 证书的费用。我们只需支付我们创建的 AWS 资源费用，以便运行我们的应用程序。然而，创建 ACM 私有 CA 并非免费的。对于私有 CA，我们需要支付月费，并为我们颁发的私有证书付费。一旦我们删除了私有 CA，就不再收费；然而，如果我们恢复了私有 CA，将会按照其被删除期间的时间收费。

另见

• 我们可以在这里了解更多关于 DNS 的内容：www.secdops.com/blog/mastering-dns-resources-and-recipes。

• 我们可以在这里阅读更多关于 ACM 服务集成的内容，并查看当前支持的服务列表：https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html。

创建 ELB 目标组

在此步骤中，我们将学习如何创建弹性负载均衡器（ELB）目标组。应用程序负载均衡器和网络负载均衡器将流量路由到 ELB 目标组，而经典负载均衡器则将流量路由到单个 EC2 实例。

准备工作

为了遵循此步骤，我们需要以下内容：

• 一个有效的 AWS 账户，awsseccb-sandbox-1，以及一个用户awsseccbadmin1，如技术要求部分所述。

• 一个 VPC，awsseccb-vpc，按照第五章中的通过最小化努力设置 VPC 及其资源步骤进行。

• 在前述awsseccb-vpc VPC 中的两个 EC2 实例，按照第五章中的使用用户数据启动 EC2 实例并配置 Web 服务器步骤进行，但有以下例外。在创建时分别命名为Cloudericks Web Server和Cloudericks Web Server 2。

小贴士

名称通过一个键为Name的标签在内部表示。

• 子网应为公共子网，分别选择us-east-1a和us-east-1b可用区。对于第二个实例，将用户数据中的Cloudericks Web Server替换为Cloudericks Web Server 2，以区分两个 Web 服务器。密钥对和安全组可以在两个实例之间共享。

• 在继续之前，确保我们的实例正在运行并且可以通过浏览器直接访问。为了增强安全性，在配置并测试完 ELB 后，我们可以通过 ELB 的安全组限制访问这些实例。

如何操作...

我们可以按照以下步骤创建目标组：

1. 登录到 AWS 管理控制台并进入EC2服务。

2. 在左侧边栏的负载均衡下，点击目标组。

3. 点击创建目标组。

4. 在指定组详细信息页面的基本配置部分，选择实例作为选择目标类型。

图 6.8 – 选择目标类型

1. 对于目标组名称，输入cloudericks-tg，或者一个与您的使用案例相关的有意义的名称。

2. 对于协议：端口，选择HTTP；对于端口，输入80；对于IP 地址类型，选择IPv4。

3. 对于VPC，选择包含我们 EC2 实例的awsseccb-vpc VPC。

4. 在协议版本下，选择HTTP1。

图 6.9 – 选择协议版本

1. 在健康检查部分，对于健康检查协议，选择HTTP，对于健康检查路径，输入/index.html。保持其他值不变，然后点击下一步。

2. 在注册目标面板中，选择Cloudericks Web Server 和 Cloudericks Web Server 2 EC2 实例，并点击作为待处理目标添加下面。实例现在应该出现在审核目标下。

3. 点击创建目标组。我们应该看到目标组已成功创建的消息。

   目标的健康状态现在为未使用。当它们被附加到 ELB 后，状态将发生变化。

它是如何工作的...

在这个食谱中，我们为 EC2 实例创建了一个使用 HTTP 协议的目标组。我们可以使用 HTTP 或 HTTPS 协议创建带有目标组的应用程序负载均衡器。网络负载均衡器需要一个使用 TCP 或 TLS 协议的目标组。我们还可以为 IP 地址和 AWS Lambda 函数创建目标组。通过选择IP 地址选项，我们可以选择 AWS 外部的公共 IP 地址。

对于健康检查，我们将协议设置为 HTTP，路径设置为/index.html。如果需要，我们可以通过在高级健康检查设置下选择覆盖端口选项，来覆盖健康检查的端口。我们可以设置等待实例响应的时间（超时），健康检查之间的时间（间隔），在声明实例不健康之前的连续失败次数（不健康阈值），在声明实例健康之前的连续成功次数（健康阈值），以及检查成功的 HTTP 响应代码（成功代码）。

当目标组实例创建时，它们的初始状态为未使用。当目标组附加到 ELB 后，状态将变为初始状态。如果健康检查通过，则状态变为健康。其他支持的状态包括如果健康检查失败，则为不健康，或者如果目标正在注销并且正在进行连接排空，则为排空。

还有更多...

在这个食谱中，我们创建了一个使用 HTTP 协议的目标组。目标组可以使用HTTP、HTTP、HTTP、HTTP、HTTP、GENEVE 和 TCP_UDP 协议创建。我们可以按照这个食谱中的步骤，使用其他协议创建目标组。例如，我们可以添加一个使用 HTTPS 协议并将端口设置为443的目标组，然后将启用了 SSL/TLS 的 EC2 实例添加到该目标组。对于通过网络负载均衡器进行 HTTPS 请求的 TCP 透传，这对于在 EC2 上进行 TLS 终止是必要的，我们应该将协议设置为 TCP，但端口设置为443。

另请参见

我们可以在 www.cloudericks.com/blog/understanding-load-balancing-in-aws 上阅读更多关于 AWS 负载均衡的信息。

使用带 TLS 终止的应用程序负载均衡器在 ELB 上

应用负载均衡器（ALBs）在请求层（OSI 模型的应用层）工作，用于 HTTP 和 HTTPS 请求。ALBs 为请求和基于路径参数的路由提供应用层的高级路由功能。架构模式，例如微服务架构，可以使用 ALBs 将请求路由到不同的 Web 服务器，同时利用请求参数。

准备工作

要跟随此教程，我们需要以下内容：

• 一个有效的 AWS 账户，awsseccb-sandbox-1，以及一个用户awsseccbadmin1，如技术要求部分所述。

• 创建一个目标组cloudericks-tg，包含两个 EC2 实例，按照本章的创建 ELB 目标组教程操作，此外，以下资源应作为准备工作的一部分创建——一个 VPC，awsseccb-vpc，以及一个安全组，cloudericks-web-server。

• 为了将 HTTPS（安全 HTTP）作为 ELB 监听协议，我们需要一个 ACM 证书。我们可以按照本章的创建 SSL/TLS 证书与 ACM教程来创建一个 ACM 证书。

操作方法...

我们可以按以下步骤创建并测试 ALB：

1. 转到控制台中的EC2服务。

2. 在左侧栏中，点击负载均衡，然后点击左侧栏中的负载均衡器。

3. 点击创建负载均衡器。

4. 我们应该看到创建三种主要类型负载均衡器的选项——即应用负载均衡器、网络负载均衡器和网关负载均衡器。点击创建下的应用负载均衡器。

图 6.10 – 负载均衡器类型

1. 在基本配置屏幕中，输入负载均衡器名称，例如cloudericks-app-lb，或根据需要输入一个有意义的名称。在方案中选择面向互联网，在IP 地址类型中选择IPv4。

图 6.11 – 基本配置

1. 在网络映射部分，选择我们的 VPC，awsseccb-vpc。

2. 在网络映射部分，在映射中选择我们实例所在的可用区和公有子网。

图 6.12 – 选择可用区和子网

1. 选择cloudericks-web-server安全组，该安全组允许HTTP和HTTPS从任何地方访问。

2. 在监听器和路由部分，将协议设置为HTTPS。端口会自动设置为443。在默认操作中，选择我们的目标组cloudericks-tg。

图 6.13 – 添加 HTTPS 监听器

1. 在安全监听器设置下，选择证书来源为来自 ACM，并选择我们为本教程创建的 ACM 证书作为证书名称。

图 6.14 – 选择 SSL/TLS 服务器证书

1. 可选地，你可以为此负载均衡器添加 AWS WAF 或创建一个 AWS Global Accelerator，如下图所示。我们暂时跳过这些内容。

图 6.15 – 配置 AWS WAF 和 AWS Global Accelerator

1. 查看详情并点击 创建负载均衡器。如果我们进入目标组 cloudericks-tg，实例的健康状态最初会显示为 Initial，经过一段时间后，状态应该会变为 Healthy。

2. 从 ELB 的 描述 标签页复制 DNS 名称，在其前面加上 https:// 前缀，如下图所示，然后在浏览器中输入此 URL。如果出现安全警告，选择 高级，然后点击链接继续。这将显示其中一个 Web 服务器。通过多次刷新页面，可以观察到来自两个 Web 服务器的响应。

图 6.16 – 负载均衡器的响应，显示我们的第一个实例数据

我们会收到一个警告，因为我们的 URL（ELB DNS）与证书的域名不匹配，在我的案例中是 *.trainso.io。

1. 为域名创建一个 CNAME 记录，将 Name（或 Host）设置为 cloudericks.trainso.io（如果 DNS 服务提供商自动附加域名，则此值仅为 cloudericks），将 Value 设置为我们的 DNS 名称，在我的案例中是 cloudericks-app-lb-901703641.us-east-1.elb.amazonaws.com。记得将 trainso.io 替换为你为其创建证书的域名。

2. 一旦 DNS 更改被传播（可能需要一些时间），我们应该能够访问我们的子域名 URL（例如，我的案例中是 cloudericks.trainso.io），并且应该能收到成功的响应，如下图所示：

图 6.17 – 成功的 HTTPS 响应，带有 SSL/TLS 证书

重要提示

有多种方式可以通过 ELB 指定我们的域名，包括创建一个 Route 53 账户并更改我们域名的服务器名称，或者为子域名添加 CNAME 记录。

它是如何工作的...

在本例中，我们创建了一个面向互联网的负载均衡器。我们将监听协议设置为 HTTPS（安全 HTTP），并在 配置安全设置 页面上选择了一个 ACM 证书。我们将安全策略设置为 ELBSecurityPolicy-2016-08。安全策略是一种 SSL 协商配置，用于与客户端协商 SSL 连接。

我们在 ELB 层终止了 TLS。请注意，从 ELB 到实例的连接没有使用 TLS。ALB 仅支持在 ELB 层进行 TLS/SSL 终止。网络负载均衡器和经典负载均衡器可以通过使用 TCP 协议在端口443上，在 EC2 实例层终止 TLS/SSL。

当我们在 ELB 层终止 HTTPS 请求的 TLS 时，请求会在 ELB 解密，并通过私有网络以未加密的形式发送到 EC2 实例。若在 EC2 实例终止 HTTPS 请求的 TLS，则该请求不会在 ELB 解密，而只会在 EC2 实例上解密。

在 ELB 层进行 TLS 终止可以避免在 EC2 实例上进行 TLS 终止的开销，更加高效。然而，如果有端到端加密的合规性要求，我们应该在 EC2 实例层进行终止。

更多内容...

让我们快速浏览一些与 ALB 相关的重要概念：

• ALB 只支持 HTTP 或 HTTPS 协议。对于其他协议，例如 TCP，我们需要使用网络负载均衡器或经典负载均衡器。

• ALB 只支持在 ELB 层进行 TLS/SSL 终止。

• 我们可以在目标组层为 ALB 启用粘性会话。然而，我们不能在个别 EC2 实例上启用 ALB 的粘性会话。

• 如果启用了路径模式，我们可以通过 ALB 实现基于路径的路由。

• 我们为 SSL/TLS 协商设置了安全策略为ELBSecurityPolicy-2016-08，这是默认设置。以下是当前可用的策略：ELBSecurityPolicy-2016-08，ELBSecurityPolicyTLS-1-2-2017-01，ELBSecurityPolicy-TLS-1-1-2017-01，ELBSecurityPolicyTLS-1-2-Ext-2018-06，ELBSecurityPolicy-FS-2018-06，ELBSecurityPolicy-2015-05，ELBSecurityPolicy-TLS-1-0-2015-04，ELBSecurityPolicy-FS-1-2-Res-2019-08，ELBSecurityPolicy-FS-1-1-2019-08，以及ELBSecurityPolicy-FS-1-2-2019-08。

另见

我们可以在docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html 阅读更多关于为 ALB 创建监听器的信息。

在 EC2 上使用网络负载均衡器进行 TLS 终止

网络负载均衡器用于负载均衡 TCP 流量，工作在 OSI 模型的第 4 层。与其他类型的负载均衡器相比，它们提供了非常高的性能，并且能够支持每秒数百万个请求，延迟极低。

准备就绪

要按照此方案操作，我们需要以下内容：

• 如技术要求部分所述，我们需要一个有效的 AWS 账户，awsseccb-sandbox-1，以及用户awsseccbadmin1。

• 创建一个目标组cloudericks-tg-tcp，按照本章的创建 ELB 目标组的步骤，但选择 TCP 而不是 HTTP 作为协议，端口选择443。作为准备该步骤的一部分，应该已经创建了以下资源 - 一个 VPC，awsseccb-vpc，和一个安全组，cloudericks-web-server。对于此步骤，我们需要一个 EC2 实例，按照第五章中的使用用户数据启动带有 Web 服务器的 EC2 实例的步骤。

• 为我们的 Web 服务器启用 HTTPS，按照在 EC2 实例上为 Web 服务器启用 HTTPS的步骤，因为我们希望在此步骤中的 EC2 实例上使用 HTTPS。确保我们的实例可以使用https://前缀访问。

• 要将 HTTPS（安全 HTTP）作为 ELB 监听协议，我们需要一个 ACM 证书。我们可以按照本章的使用 ACM 创建 SSL/TLS 证书的步骤创建 ACM 证书。

如何做…

我们可以创建并测试一个在 EC2 实例上进行 TLS 终止的网络负载均衡器，如下所示：

1. 登录 AWS 管理控制台，转到EC2服务。

2. 从左侧边栏点击负载均衡器。

3. 点击创建负载均衡器。我们应该看到创建三种类型的负载均衡器的选项，应用负载均衡器，网络负载均衡器和经典负载均衡器，如图 6 .10所示。

4. 在网络负载均衡器下，点击创建。

5. 在创建网络负载均衡器屏幕上，在基本配置部分，输入cloudericks-nw-lb作为负载均衡器名称；对于方案，选择面向互联网；对于IP 地址类型，选择IPv4。

6. 在网络映射部分，对于VPC，选择我们的 VPC，awsseccb-vpc。

7. 在网络映射部分，在映射下，选择我们的实例所在的可用区和公共子网，如图 6 .12所示。

8. 在安全组下，选择cloudericks-web-server安全组。

9. 对于协议，选择TCP，并将端口的值设置为443。对于目标组，选择cloudericks-tg-tcp。

10. 可选地，您可以为此负载均衡器创建 AWS 全球加速器。暂时跳过。对于 ALB，我们还有包括 AWS WAF 的选项，正如我们在图 6 .15中看到的。

11. 其他细节保持不变，点击创建负载均衡器。

12. 从 ELB 的描述选项卡中复制 DNS 名称，将https://前缀添加到其中，如下图所示，在浏览器中输入此 URL。如果出现安全警告，请选择高级，然后点击继续链接。这将显示一个 Web 服务器。通过多次刷新页面，您可以观察来自两个 Web 服务器的响应。

图 6.18 – 网络负载均衡器响应

在这里，我们在 EC2 实例上执行 TLS 终止；因此，我们不需要为负载均衡器配置证书。我们在浏览器中收到警告，因为我们使用的是自签名证书。如果我们使用由 CA 签名的证书，我们将不会收到警告。

工作原理...

在这个示例中，我们创建了一个网络负载均衡器（NLB），在 EC2 上进行了 TLS 终止。大部分选项与本章中在 ELB 上使用应用负载均衡器进行 TLS 终止示例中所见相同。在这个示例中，我们使用了 TCP 协议和端口443。这样做是为了让 NLB 只需将 HTTPS 请求简单地传递给 EC2 实例，而不在 ELB 层解密它。目标组也应配置为 TCP 协议，并使用端口443，允许 TCP 透传。如果我们选择 TLS（安全 TCP）而不是 TCP，NLB 将在 ELB 自身解密请求。

还有更多...

在这个示例中，我们对 HTTPS 请求进行了 TCP 透传，并在 EC2 实例上执行了 TLS 终止。在 EC2 实例上进行 TLS 终止将消耗更多的 EC2 资源，并为 EC2 实例提供额外的负载。我们还需要在所有 EC2 实例上管理证书。然而，如果由于合规性或政府政策要求需要端到端加密，这是首选方式。否则，首选方法是在 ELB 层执行 SSL/TLS 终止，就像我们在本章中在 ELB 上使用应用负载均衡器进行 TLS 终止示例中所见。要在 NLB 上终止 SSL/TLS，我们需要将协议设置为 TLS（安全 TCP）并选择 ACM 证书。

另请参阅

我们可以在这里阅读有关 AWS 负载均衡器 TLS 终止的更多信息：www.cloudericks.com/blog/understanding-tls-termination-with-load-balancers-in-aws。

使用 CloudFront 和 TLS 保护 S3

在这个示例中，我们将学习如何通过添加 CloudFront 分发层来保护 S3 存储桶。我们将在 CloudFront 分发上启用 SSL/TLS 以允许 HTTPS 流量。最初，我们将利用默认的 CloudFront 证书（*.cloudfront.net），然后继续配置 CloudFront 分发以使用 ACM 证书的自定义域。

准备工作

我们需要以下内容才能成功完成这个示例。

• 一个名为awsseccb-sandbox-1的有效 AWS 帐户和一个名为awsseccbadmin1的用户，如技术要求部分所述。

• 我们需要一个名为index.html的 S3 存储桶。文件的内容应为<h1> Cloudericks Web Server </h1>。我们可以通过参考第二章的技术要求部分来创建一个 S3 存储桶。

• 对于本食谱中使用自定义域名和 ACM 证书的 CloudFront 分发部分，我们需要创建一个 ACM 证书，按照本章的使用 ACM 创建 SSL/TLS 证书食谱进行操作。

如何操作...

我们可以为 S3 桶添加一个 CloudFront 分发，无论是否使用自定义域名。我们将在本食谱中介绍这两种方法。

使用默认 CloudFront 域的 CloudFront 分发

我们可以按如下方式将 CloudFront 分发添加到具有默认 CloudFront 域和证书的 S3 桶：

1. 登录到 AWS 管理控制台并进入CloudFront服务。

2. 如果你是 CloudFront 新手，你应该会看到一个包含创建 CloudFront 分发按钮的页面。点击它。否则，你可以先从左侧边栏点击分发，然后选择CloudFront 分发。

图 6.19 – 创建 CloudFront 分发

1. 在源站面板中，对于源站域名，选择我们为本食谱创建的 S3 桶。保持源站路径为空。对于名称，使用自动生成的值。对于源访问，选择源访问控制设置。

图 6.20 – 设置源站详情

1. 点击创建新 OAC。对于名称，我们可以使用自动填充的名称。对于签名行为，选择签名请求（推荐）。保持默认设置，如下图所示，然后点击创建。

图 6.21 – 创建新 OAC

1. 在我们的创建分发页面上选择新的 OAC。保持启用源盾的值为否。

2. 在默认缓存行为下，对于路径模式，使用默认值；对于自动压缩对象，选择是；对于查看器协议策略，选择将 HTTP 重定向到 HTTPS；对于允许的 HTTP 方法，选择GET, HEAD；对于限制查看器访问，选择否。

图 6.22 – 配置默认缓存行为

1. 保持缓存键和源请求以及功能关联的默认设置。

2. 向下滚动到Web 应用防火墙（WAF）并选择不启用安全性保护选项。

图 6.23 – WAF 选择选项

1. 对于价格类，请选择使用所有边缘位置（最佳性能）。

图 6.24 – 选择价格类

1. 对于自定义 SSL 证书 - 可选，不要做任何选择；对于支持的 HTTP 版本，选择HTTP/2；对于默认根对象 - 可选，输入index.html。

图 6.25 – 选择 SSL 证书和默认根对象

1. 对于标准日志记录，选择关闭，对于IPv6，选择开启。启用标准日志记录后，会检索查看者请求的日志，并将其传递到 Amazon S3 存储桶。因此，启用此功能需要指定目标存储桶，并确定是否需要记录 cookie。启用 cookie 记录后，CloudFront 会在标准日志中包含 cookie。

2. 点击创建分发。我们将收到一个提示，询问是否要复制需要更新在我们的 S3 存储桶中的 S3 存储桶策略。

图 6.26 – 复制 S3 策略通知

1. 点击复制策略，并将此策略粘贴到我们的 S3 存储桶的存储桶策略部分。如果您不确定如何操作，可以参考第四章中的创建 S3 存储桶策略部分。如果您错过了这一步，您将需要独立设置它，可以参考亚马逊文档 docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html 。

2. 从我们的 CloudFront 分发中复制分发域名，并在浏览器中运行。我们应该会得到以下截图中的输出：

图 6.27 – 通过 CloudFront 分发的响应

在这里，我们不需要指定文件名，因为我们已经指定了一个默认对象。

1. 可选地，我们还可以直接指定我们的 S3 存储桶中的文件名，如下截图所示。这个文件在准备就绪部分中没有创建，所以如果您想要运行类似的 URL，您需要创建它。

图 6.28 – 直接访问 S3 中的文件

接下来，我们将学习如何使用自己的 ACM 证书和自定义域名。

带有自定义域名和 ACM 证书的 CloudFront 分发

我们可以按照以下步骤为 S3 存储桶添加一个带有自定义域名和 ACM 证书的 CloudFront 分发：

1. 按照本教程中CloudFront 分发使用默认 CloudFront 域名部分的步骤 1 到 9，直到设置价格类别。然而，有一个例外 - 如果在该部分创建了源访问控制（OAC），则无需创建新的，可以重用现有的 OAC。

2. 对于备用域名（CNAME）- 可选，输入我们拥有证书的域名的子域名，如下截图所示。请记得将trainso.io替换为您的域名。

图 6.29 – 设置备用域名（CNAME）

1. 对于自定义 SSL 证书，如图 6 .30所示，选择我们为本教程创建的 ACM 证书，取消遗留客户端支持，对于安全策略，选择TLSv1.2_2021，这是当前推荐的版本。对于支持的 HTTP 版本，选择HTTP/2，对于默认根对象 - 可选，输入index.html。

图 6.30 – ACM 证书配置

1. 对于标准日志记录，选择关闭，对于IPv6，选择开启。

2. 点击创建分发。将显示复制策略消息与一个存储桶策略。确保更新我们 S3 存储桶的存储桶策略，就像我们在前一节中所做的那样。

3. 为域名创建一个CNAME记录，名称（或主机）设置为我们在步骤 2中输入的子域名，我的情况下是cloudericksws.trainso.io（如果 DNS 服务提供商自动附加域名，则只是cloudericksws），值设置为我们的 CloudFront 域名，我的情况下是d31z3ldyzun0k3.cloudfront.net。

4. 经过一段时间，考虑到 DNS 传播延迟，从浏览器中运行子域名，我们应该会得到一个成功的响应。

图 6.31 – 使用自定义域的响应

除了自定义子域名，我们也可以使用前一节中看到的 CloudFront 域名访问网页。

图 6.32 – 使用 CloudFront 域名的响应

在本节中，我们通过 CloudFront 使用自定义域和 ACM 证书访问了我们私有 S3 存储桶的内容。

工作原理...

在本教程中，我们创建了一个 CloudFront 分发层覆盖一个私有 S3 存储桶，以便通过 HTTPS 安全访问 S3 存储桶。我们配置了将所有 HTTP 请求重定向到 HTTPS 请求。如果我们选择 HTTP 和 HTTPS，则允许 HTTP 和 HTTPS 请求。如果我们只选择 HTTPS，则所有 HTTP 请求将被丢弃。

在本教程的使用默认 CloudFront 域的 CloudFront 分发部分中，我们使用了 CloudFront 提供的默认证书（ .cloudfront.com ）进行 SSL 加密。这个证书使我们能够在不需要创建证书的情况下使用 HTTPS。在本教程的使用自定义域和 ACM 证书的 CloudFront 分发*部分中，我们指定了一个通配符域名（ *.trainso.io ）作为备用域名（CNAMEs）。这将允许任何子域名作为 DNS 服务提供商端的 CNAME 记录，并转发到我们的网页。

我们选择了为自定义域创建的 ACM 证书，并在 DNS 服务提供商处输入了指向 CloudFront 域名的 CNAME 记录。添加 CNAME 记录的具体步骤可能与 DNS 服务提供商相关。您可以查看 DNS 服务提供商的文档（aws.amazon.com/route53/what-is-dns/）了解更多详细信息。

还有更多...

在这个步骤中，我们使用了自有的 ACM 证书作为 CNAME，它已在外部 DNS 提供商处配置，使我们能够使用子域访问 S3 存储桶中的网页。或者，我们可以使用 Route 53 来管理我们的域的 DNS，并将顶级域名指向我们的 CloudFront 分发。

另请参见

我们可以在此处了解如何使用 Route 53 将流量路由到 CloudFront 分发：docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-cloudfront-distribution.html。

使用 WAF

AWS WAF（即Web 应用防火墙）是一项用于监控我们 Web 流量的防火墙服务。与仅检查端口和 IP 地址的安全组和网络 ACLs（NACLs）不同，AWS WAF 可以根据预定义的签名匹配内容，帮助检测常见的攻击方式，如 SQL 注入和跨站脚本攻击。目前，我们只能在 API Gateway、CloudFront 和 ALBs 中使用 WAF，不能直接与 EC2 或 Route 53 等服务一起使用。

AWS WAF 可以与 CloudFront 分发、ALBs 和 API Gateway 一起使用，每种服务具有独特的特性，影响 WAF 的使用。CloudFront 是全球性的，意味着 WAF 规则在所有区域统一适用，为全球应用提供一致的保护。相比之下，ALBs 和 API Gateway 是区域性的，因此 WAF 规则必须为每个区域单独配置，虽然可以根据需求定制安全策略，但也增加了管理的复杂性。使用 CloudFront 配合 WAF 更加简单，并能通过边缘位置减少延迟，而 ALBs 和 API Gateway 提供了更细粒度的控制，但可能会由于需要多次配置而导致区域性能差异和潜在的更高成本。了解这些差异有助于根据应用架构和地理分布优化安全性和性能。

准备工作

我们需要以下内容才能成功完成此操作：

• 一个有效的 AWS 账户，awsseccb-sandbox-1，以及一个用户，awsseccbadmin1，如技术 要求部分所述。

• 要创建一个与 CloudFront 分发配合使用的 WAF，我们需要按照本章的 使用 CloudFront 和 TLS 保护 S3 配方，在 S3 存储桶上创建 CloudFront 分发。

如何操作...

我们可以按照以下步骤为 CloudFront 分发创建和配置 AWS WAF：

1. 登录 AWS 管理控制台并进入WAF & Shield仪表板。

图 6.33 – WAF & Shield 仪表板

我们应该在侧边栏中看到AWS WAF、AWS Shield和AWS Firewall Manager的菜单项。如果 AWS 决定将它们分开，请前往 AWS WAF 仪表板并继续进行此步骤。

1. 点击创建web ACL。

2. 在Web ACL 详情部分，对于资源类型，选择Amazon CloudFront 分发；对于名称，输入cloudericks-webacl；并可选地，在描述字段提供描述。我们将使用自动填充的CloudWatch 指标名称字段值。

图 6.34 – 配置 Web ACL

1. 在关联的 AWS 资源部分，点击添加AWS 资源。

2. 在添加 AWS 资源页面，选择我们为此步骤创建的CloudFront 分发，然后点击添加。

3. 一旦我们回到关联的 AWS 资源部分，选择我们的 CloudFront 分发。

4. 对于Web 请求体检查，选择默认，然后点击下一步。

5. 在添加规则和规则组页面，展开添加规则下拉菜单并选择添加我的规则和规则组。

6. 在添加我的规则和规则组页面，选择规则构建器。

图 6.35 – 选择规则类型

1. 在规则构建器下，进入规则部分，输入名称badstring-rule并将类型设置为常规规则。

图 6.36 – 配置规则构建器

1. 在语句部分，对于检查，选择查询字符串；对于匹配类型，选择包含单词；对于匹配字符串，输入badstring。对于文本转换，选择无。

图 6.37 – 设置字符串语句

1. 在然后部分，选择阻止作为动作并点击添加规则。

图 6.38 – 添加规则

1. 在添加规则和规则组页面，对于默认 Web ACL 动作（不匹配任何规则的请求），选择允许并点击下一步。

2. 在设置规则优先级页面，选择我们的规则并点击下一步。

3. 在配置指标页面，选择我们的规则，保留自动生成的指标名称，选择启用采样请求作为请求采样选项，然后点击下一步。

4. 在审核并创建 Web ACL页面，审查更改并点击创建 Web ACL。如果我们前往 CloudFront 分发，它将开始部署。请等待直到部署完成。

5. 使用包含 badstring 的查询字符串从浏览器中运行 URL – 例如，https://d1w6mgtt0jnmgz.cloudfront.net/?name=badstring 。这时我们应该得到一个 403 错误，如下所示：

图 6.39 – 403 错误

如果我们在 URL 中没有任何地方使用 badstring 这个词，就不会出现错误。

1. 取消将 Web ACL 与我们的 CloudFront 发行版关联，如下所示：

   1. 点击我们的 Web ACL。

   2. 转到 关联的 AWS 资源 选项卡。

   3. 选择我们的 CloudFront 发行版。

   4. 点击 删除 。

2. 等待状态变为 已部署 ，然后从包含 badstring 的查询字符串的浏览器中再次运行 URL。此时页面应该可以成功加载，没有任何错误。

   我们还可以在创建 CloudFront 发行版时启用 WAF，并可以在 CloudFront 发行版中禁用保护。

工作原理……

Web ACL 是 AWS WAF 中的主要组件。Web ACL 包含一个或多个规则。规则包含条件语句（例如，阻止从一组 IP 地址访问）。我们使用规则构建器添加了我们自己的规则。规则构建器有一个 IF 部分和一个 THEN 部分。IF 部分包含条件，而 THEN 部分包含当 IF 部分中的条件满足时需要执行的操作。在此配方中，我们添加了一个简单的规则，检查查询字符串是否包含字符串 badstring ，并阻止这类请求。

在 IF 部分，我们目前可以检查以下请求组件 – 一个头部，一个单一查询参数，所有查询参数，URI 路径，查询字符串，主体和 HTTP 方法。我们还可以检查 IP 地址是否属于 IP 集或请求是否来自特定国家。在此配方中，我们创建了一个常规规则。我们还可以创建一个基于速率的规则来为单个用户设置速率限制。例如，WAF 可以基于用户发出的 4xx 错误 数量来阻止用户。

我们可以从 WAF 仪表板的左侧边栏创建支持资源，例如 IP 集，Regex 模式集和规则组。我们可以使用 WAF 仪表板左侧边栏中的 AWS Marketplace 链接找到 AWS Marketplace 规则组。除了创建我们自己的规则外，我们还可以添加 AWS 管理的规则组。目前，在控制台中有三类托管规则组 – AWS 管理的规则组，Cyber Security Cloud Inc. 管理的安全组和 Fortinet 管理的规则组。

还有更多……

在撰写本文时，AWS WAF 和 AWS Shield 服务具有相同的服务主页，正如我们在 如何做…… 部分看到的那样。在此配方中，我们详细介绍了 AWS WAF。在本节中，我们将简要介绍与 AWS Shield 相关的一些重要概念。

AWS Shield 是一项托管的分布式拒绝服务（DDoS）保护服务，提供始终开启的检测和自动内联缓解措施，以最小化应用程序的停机时间和延迟，无需联系 AWS 支持即可享受 DDoS 保护。

AWS Shield 有两个层级——Standard 和 Advanced。Shield Standard 防御针对我们网站或应用程序的已知基础设施攻击，包括网络（第 3 层）和传输层（第 4 层），并且与 Amazon CloudFront 和 Amazon Route 53 配合使用时效果最佳。AWS Shield Advanced 提供更高水平的保护，针对攻击我们运行在 EC2、ELB、CloudFront、AWS Global Accelerator 和 Route 53 资源上的应用程序。

另见

• 你可以在这里阅读更多关于 AWS WAF、AWS Shield 和 AWS Firewall Manager 的信息：docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html。

• 你可以在这里阅读更多关于 AWS Shield 的信息：aws.amazon.com/shield/。

第七章：使用 CloudWatch、CloudTrail 和 Config 进行监控

我们已经讨论了许多关于安全的方面，例如保密性、完整性和可用性（CIA）以及认证、授权和审计（AAA）。审计可以通过持续监控、警报和定期审计来实现。适当的监控和警报也可以通过自动修复来提高可用性。在本章中，我们将研究Amazon CloudWatch、AWS CloudTrail和AWS Config。CloudWatch 是 AWS 中用于日志记录、监控和警报的主要服务。CloudTrail 可以记录 AWS API 调用。AWS Config 可以记录并评估配置是否符合预定义的配置规则。我们还将了解简单通知服务（SNS），它将帮助我们发送通知。

本章将涵盖以下食谱：

• 创建 SNS 主题以发送电子邮件

• 使用 CloudWatch 警报和指标

• 创建一个 CloudWatch 日志组

• 使用 EventBridge（之前是 CloudWatch Events）

• 在 CloudTrail 中读取并过滤日志

• 在 CloudTrail 中创建轨迹

• 使用 Athena 查询 S3 中的 CloudTrail 日志

• 使用 CloudFormation 模板将 CloudWatch 与 CloudTrail 集成

• 设置和使用 AWS Config

技术要求

在开始本章的操作之前，我们需要确保具备以下要求和知识：

• 我们需要一个有效的 AWS 账户来完成本章的所有操作。我们可以使用属于 AWS 组织的一部分的账户或独立账户。我将使用我们在第一章的使用 AWS 组织进行多账户管理食谱中创建的awsseccb-sandbox-1账户。不过，我不会使用任何 AWS 组织功能，这意味着你也可以使用独立账户跟随这些步骤。

• 对于管理操作，我们需要一个具有AdministratorAccess权限的用户来操作 AWS 账户。这可以是一个身份与访问管理（IAM）身份中心用户或 IAM 用户。我将使用我们在第一章的使用 IAM Identity Center 进行用户管理和 SSO食谱中创建的awsseccbadmin1 IAM Identity Center 用户。不过，我不会使用任何 IAM Identity Center 功能，这意味着如果用户在账户中具有AdministratorAccess权限，你也可以使用 IAM 用户执行这些步骤。你可以按照设置 IAM、账户别名和账单警报食谱创建一个 IAM 用户。

本章的代码文件可在github.com/PacktPublishing/AWS-Security-Cookbook-Second-Edition/tree/main/Chapter07找到。

创建 SNS 主题以发送电子邮件

在本示例中，我们将学习如何创建一个 SNS 主题来发送电子邮件。SNS 是一个托管的发布/订阅消息服务，可以与多种端点一起使用，如电子邮件、短信（SMS）、Lambda、简单队列服务（SQS）等。

准备开始

为了成功完成本示例，我们需要一个有效的 AWS 账户，一个如技术要求部分所述的用户，以及一个有效的电子邮件地址。

如何操作...

我们可以按照以下方式配置 SNS 主题来发送电子邮件：

1. 进入控制台中的简单通知服务（SNS）。

2. 在左侧边栏，点击主题。

3. 点击创建主题。

4. 对于类型，选择标准。

5. 对于名称和显示名称（可选）字段，输入有意义的值。我输入的名称是MyEmailTopic，显示名称是My Email Topic。

6. 保持其他选项不变，向下滚动至页面底部，点击创建主题。

7. 进入我们主题的订阅标签。

8. 点击创建订阅。

9. 在创建订阅页面，将协议字段设置为电子邮件，并提供一个我们可以访问的电子邮件地址作为端点字段的值。

10. 向下滚动并点击创建订阅。我们的订阅状态将初始为等待确认。

11. 登录您的电子邮件，点击确认订阅超链接。我们应该会收到订阅确认消息。如果我们返回 AWS 控制台中的订阅并刷新页面，我们的状态应该是已确认。

我们已经在本示例中创建了一个 SNS 主题。我们将在本章中的后续示例中使用该主题。

它是如何工作的...

在本示例中，我们创建了一个带电子邮件订阅的 SNS 主题。为了避免垃圾邮件，AWS 要求我们通过点击发送到指定电子邮件地址的确认链接手动确认该电子邮件地址的所有权。

更多内容...

在本示例中，我们选择了电子邮件协议。当前支持的协议有：电子邮件、Amazon Kinesis 数据 Firehose、Amazon SQS、Amazon SQS、电子邮件-JSON、Amazon SQS、Amazon SQS、平台应用端点和SMS。电子邮件-JSON与电子邮件协议不同。电子邮件-JSON协议将输出结构化为 JSON，适用于自动读取并处理电子邮件的服务。

参见

• 您可以在www.cloudericks.com/blog/getting-started-with-amazon-sns-service上阅读更多关于 SNS 的信息。

• 我们还可以使用简单电子邮件服务（SES）来发送电子邮件通知，而不是使用 SNS。SES 是一种基于云的电子邮件服务，用于发送和接收电子邮件。它使用简单邮件传输协议（SMTP）接口，所有到 SMTP 端点的连接应使用传输层安全性（TLS）加密。SES 的默认端口是25，但为了避免弹性计算云（EC2）限制电子邮件流量，我们还可以使用端口587或2587。了解更多关于 SES 的信息，请访问 www.cloudericks.com/blog/getting-started-with-amazon-ses。

使用 CloudWatch 警报和度量标准

在这个示例中，我们将使用已有的度量标准来创建一个CloudWatch 警报。作为关于 CloudWatch 的第一个示例，我们还将学习一些 CloudWatch 的重要功能。

准备就绪

为了成功完成这个示例，我们需要以下内容：

• 一个有效的 AWS 账户和如技术要求部分所述的用户。

• 根据本章中创建 SNS 主题以发送电子邮件示例中的步骤创建一个带有电子邮件订阅的 SNS 主题。

如何操作...

我们可以使用现有的度量标准创建 CloudWatch 警报，步骤如下：

1. 进入控制台中的CloudWatch服务。

2. 从左侧边栏展开警报，然后点击处于警报状态。

3. 点击创建警报。

4. 点击选择度量标准。这将显示我们基于所使用服务的所有可用度量标准。

图 7.1 – 选择度量标准

1. 点击计费。

2. 点击按服务。

3. 选择Amazon EC2并点击选择度量标准。这将带我们到指定度量标准和条件页面。

4. 在指定度量标准和条件页面的度量标准部分，使用以下屏幕截图所示的默认设置：

图 7.2 – 估计费用度量标准配置

1. 在条件部分，定义阈值为1，并使用其他字段的默认值。

图 7.3 – 度量标准的条件

1. 点击下一步。

2. 在配置操作页面，选择警报状态触发器中的处于警报状态。在向以下 SNS 主题发送通知下，选择选择现有 SNS 主题选项，并选择我们在准备就绪部分中为这个示例创建的 SNS 主题。保持其他选项不变，如下图所示：

图 7.4 – 度量标准的通知配置

1. 向下滚动并点击下一步。

2. 为我们的警报提供名称和警报描述（可选）值。我已将名称设置为MyEC2BillingAlarm，并将警报描述设置为My EC2 Billing Alarm。点击下一步。

3. 查看详细信息，向下滚动，并点击创建警报。警报现在会出现在警报页面上。最初，警报的状态字段将显示为数据不足。该状态应在一段时间后更改为正常。确保我们有一个正在运行的 EC2 实例。当警报状态更改为报警状态时，我们应该会收到配置 SNS 的电子邮件通知。

重要提示

我为阈值使用了一个相对较低的值，并使用了足够的 EC2 服务来触发警报。您可以根据需要使用适合您的要求的阈值值。

工作原理...

在创建 CloudWatch 警报时，我们指定了度量标准。我们还可以指定评估度量标准的时间段、在触发警报之前评估的此类时间段的数量，以及在评估期间内，超过阈值所需的数个数据点，才能触发警报。警报触发器还可以进一步触发其他操作，例如通过电子邮件发送通知、配置自动扩展操作以及执行 EC2 操作，例如重启失败的实例。

CloudWatch 警报有三种状态，分别是数据不足、正常和报警。在获取足够的数据进行分析之前，状态将为数据不足。当它有足够的数据点进行评估，并且结果在指定的时间段内没有超过阈值时，状态将为正常。如果结果在指定的时间段内超过了阈值，则触发警报，CloudWatch 警报将进入报警状态。

还有更多内容...

让我们通过一些与 CloudWatch 相关的重要概念：

• CloudWatch 度量标准支持警报、度量标准和仪表盘。

• CloudWatch Logs 提供日志流和日志组，以便我们可以记录来自应用程序的数据。

• CloudWatch 事件支持使用 AWS Lambda 进行通知和自动修复。

• AWS 提供了一些开箱即用的度量标准，并允许我们为应用程序创建自定义度量标准。

• 亚马逊 CloudWatch 可以与 AWS X-Ray 集成，以提供与应用程序性能相关的跟踪和度量。

• CloudWatch 与 SNS、SQS、AWS Lambda、AWS Auto Scaling 等服务集成，用于通知和自动修复。

• 在左侧边栏的警报下，我们有一个专门的计费选项。

• 默认的 EC2 度量标准支持重要的操作，包括 CPU 利用率、磁盘读写操作、网络输入和输出操作，以及状态检查失败。

另见

• 了解 CloudWatch 自定义度量标准，请阅读：www.cloudericks.com/blog/getting-started-with-amazon-cloudwatch-custom-metrics。

• CloudWatch 仪表板为我们提供了一个单一的地方来查看相关的指标。阅读关于在 CloudWatch 中创建仪表板的内容，请访问 www.cloudericks.com/blog/creating-an-amazon-cloudwatch-dashboard。

创建一个 CloudWatch 日志组

在这个配方中，我们将创建一个 CloudWatch 日志组，该日志组将在本书中的其他配方中使用。

准备工作

为了成功完成这个配方，我们需要一个有效的 AWS 账户和一个如 技术 要求 部分所描述的用户。

如何做...

我们可以按如下方式创建 CloudWatch 日志组：

1. 在控制台中进入 CloudWatch 服务。

2. 从左侧边栏展开 日志。

3. 点击 日志组 并点击 创建日志组。

4. 给日志组起一个能描述其用途的名称，其他设置保持默认，然后点击 创建。

这将为我们创建一个新的日志组。

它是如何工作的...

创建日志组时需要提供的设置不多。我们可以在其他配方中使用这个日志组，在那里我们将日志记录到 CloudWatch。一个日志组是多个日志流的集合。一个日志流是来自同一来源的日志事件序列。日志组中的日志流共享相同的保留、监控和访问控制设置。我们可以指定每个日志组中包含哪些日志流。一个日志组中的日志流数量没有限制。

更多内容...

日志组可能会被其他服务和功能使用，例如我们在本书中看到的 VPC 流日志。日志组也可以用于我们自定义构建的应用程序和微服务。

另见

阅读更多关于 CloudWatch 日志的信息，请访问 www.cloudericks.com/blog/getting-started-with-amazon-cloudwatch-logs。

使用 EventBridge（以前是 CloudWatch 事件）

在这个配方中，我们将学习如何创建并使用 EventBridge 服务（以前称为 CloudWatch Events）。CloudWatch 事件为我们提供了来自各种 AWS 资源的近实时系统事件流，我们可以创建规则来根据事件数据采取行动。

准备工作

我们需要以下内容来成功完成这个配方：

• 一个有效的 AWS 账户和一个如 技术 要求 部分所描述的用户。

• 创建一个 SNS 主题，并通过本章中的 创建 SNS 主题以发送电子邮件 配方订阅电子邮件。

如何做...

我们可以按如下方式使用 EventBridge（或 CloudWatch 事件）：

1. 在控制台中进入 Amazon EventBridge 服务。

2. 在左侧边栏，展开 总线 并点击 规则。点击 创建规则。

提示

如果你正在使用 CloudWatch 服务创建事件，你需要从控制台进入Amazon CloudWatch服务。在左侧边栏中，选择事件下的规则，你将被重定向到 EventBridge 控制台，以创建一个带有CloudWatch 事件控制台已废弃消息的规则，并使用 EventBridge 控制台创建和管理事件总线和规则。点击创建规则。其余步骤与创建事件相同。

1. 输入my-sec-cb-rule-1作为名称和一个可选的描述我的安全 CB 规则 1。将事件总线选择保持为默认。最后，选择带事件模式的规则作为规则类型。点击下一步。

图 7.5 – 规则详情

1. 在事件源下，选择AWS 事件或 EventBridge合作伙伴事件。

2. 在示例事件 - 可选下，保持示例事件类型为AWS 事件的默认选择，并且不选择任何示例事件。

重要提示

包含示例事件是可选的，但推荐这样做，因为它们可以帮助我们编写和测试事件模式或过滤条件。我们可以在创建事件模式时引用示例事件，或者使用它来测试事件模式是否匹配。

1. 在创建方式下，选择使用模式表单。

2. 在事件模式下，按照图 7 .6所示操作：

   1. 将事件源设置为AWS 服务。

   2. 将AWS 服务设置为EC2。

   3. 将事件类型设置为EC2 实例状态变更通知。

   4. 将事件类型规格 1设置为任何状态。

   5. 将事件类型规格 2设置为任何实例。

图 7.6 – 事件模式部分

1. 点击下一步。

2. 在目标 1下，按照图 7 .7的示例操作。对于目标类型，选择AWS 服务。在选择目标下，选择SNS 主题。对于主题，选择我们为此食谱创建的主题，如准备部分所提到的。

图 7.7 – 目标 1 部分

1. 点击下一步。

2. 在标签页面，可选择性地添加标签并点击下一步。标签是分配给 AWS 资源的标签，由一个键和一个可选的值组成。标签可用于搜索和筛选资源或跟踪 AWS 成本。

3. 在审核和创建页面，检查所有详细信息，并点击右下角的创建规则。

   我们现在应该会收到一封包含状态变更详情的通知电子邮件，每当 EC2 实例的状态发生变化时。要进行测试，请进入 EC2 控制台并创建一个新实例或更改现有实例的状态。

它是如何工作的...

在本教程中，我们选择了一个事件模式，并将服务名称设置为EC2，事件类型设置为EC2 实例状态变化通知，以匹配状态发生变化的 EC2 事件。除了事件模式，我们还可以选择计划，按计划调用我们的目标，就像使用 cron 作业一样。

我们配置为通知任何状态变化。我们也可以选择一个特定状态，比如待处理、运行中、关机中、已停止、停止中或已终止。我们还配置为将此规则应用于账户内的所有实例。我们也可以选择一个特定的 EC2 实例。我们选择了我们的 SNS 主题作为目标。当我们配置目标时，CloudWatch 事件将提供必要的权限，以便在规则触发时调用目标。

还有更多...

在配置事件时，我们选择了SNS 主题作为目标。以下是目前可供我们选择的目标类型的完整列表：Amazon Redshift、Amazon Redshift、Amazon Redshift、Batch 作业队列、CloudWatch 日志组、CodeBuild 项目、Amazon Redshift、EBS 创建快照、Amazon Redshift、EC2 重启实例 API 调用、ECS 任务、Firehose 流、Glue 工作流、Incident Manager 响应计划、Inspector 评估模板、Kinesis 流、Lambda 函数、SageMaker 管道、SNS 主题、SQS 队列、Step Functions 状态机、System Manager 自动化、Amazon Redshift、System Manager 运行命令。

另请参见

你可以在www.cloudericks.com/blog/getting-started-with-amazon-cloudwatch-events了解更多关于 CloudWatch 事件的信息。

在 CloudTrail 中读取和过滤日志

在这个教程中，我们将学习如何读取和过滤CloudTrail 日志事件，这些事件是自动生成的，并通过 CloudTrail 仪表盘提供。

准备工作

我们需要一个有效的 AWS 账户。我将使用我们在第一章中创建的awsseccb-sandbox-1账户。

如何操作...

我们可以按以下方式检查自动填充的事件日志：

1. 登录到管理控制台，进入CloudTrail服务。

2. 点击左侧边栏的事件历史。这将带我们进入事件历史页面。

图 7.8 – 事件历史

1. 在查找属性下，从下拉菜单中选择用户名。在下一个字段中输入我们的用户名（或列表中的任何名称，如图 7.8所示），并使用按日期和时间筛选字段搜索该用户在 10 天内的所有活动。现在我们应该能看到筛选后的列表。

2. 点击右上角的下载事件图标，然后点击下载为 CSV，将结果下载为 CSV 文件。

图 7.9 – 下载事件

我们也可以将结果下载为 JSON 文件。

它是如何工作的...

AWS CloudTrail 是 Amazon 提供的一项服务，可以持续监控并记录 AWS 账户中的 API 活动。无需额外配置，CloudTrail 会将 API 活动事件记录到我们的账户中，并且事件日志可以通过 CloudTrail 控制台访问 90 天。在进入 事件历史 页面后，我们可以基于各种标准和时间范围进行过滤。在本教程中，我们是根据 用户名 参数进行过滤的。除了 用户名 外，我们还可以根据以下参数进行过滤：事件名称、资源类型、资源名称、事件来源、事件 ID、AWS 访问密钥 和 只读。

还有更多...

在这个教程中，我们查询了来自控制台的日志。我们也可以通过命令行界面（CLI）查询日志。以下是一些用于查询 CloudTrail 日志的重要 CLI 命令：

• aws cloudtrail lookup-events 命令可用于查询过去 90 天内自动生成的事件日志。如果有更多结果，将返回分页令牌。

• 我们可以通过指定 max-items 选项来限制 aws cloudtrail lookup-events 命令返回的项数；例如，aws cloudtrail lookup-events --max-items 10。

• 我们可以使用 start-time 和 end-time 参数指定日期范围；例如，aws cloudtrail lookup-events --start-time 2019-01-12 --end-time 2019-10-12。我们也可以通过这些参数指定小时、分钟和秒；例如，--start-time 2019-01-12T00:30:45。

• 我们可以使用 lookup-attributes 参数指定任何参数的值；例如，aws cloudtrail lookup-events --lookupattributes "AttributeKey=Username,AttributeValue=i-07d6614e1dec5e537"。

让我们再看一些与 CloudTrail 日志相关的重要概念：

• CloudTrail 服务通过分析事件并响应这些事件，帮助我们实现事件驱动的安全性。

• CloudTrail 仅记录涉及 AWS API 调用的事件。因此，如果在 EC2 实例上运行的应用程序抛出错误，它将不会被捕获。CloudWatch 可以用于记录来自 EC2 上的应用程序或 Lambda 函数的日志。

• 默认情况下，CloudTrail 将在一个区域记录事件。然而，我们可以将 CloudTrail 配置为多区域的跟踪。CloudTrail 可以与其他 AWS 服务集成，以提供额外的安全性和合规性。这些集成包括：CloudWatch 用于触发警报、GuardDuty 用于分析模式、Macie 用于发现、分类和保护敏感数据等。

• 当前的 CloudTrail 定价模型如下：每个区域的第一层是免费的（简单存储服务（S3）和 Lambda 数据事件除外）。免费层之后，CloudTrail 会对管理事件和数据事件进行收费。

另见

您可以在www.cloudericks.com/blog/getting-started-with-aws-cloudtrail 阅读更多关于 CloudTrail 的内容。

在 CloudTrail 中创建轨迹

在本食谱中，我们将学习如何在CloudTrail中创建轨迹，并如何从关联的S3 存储桶中读取日志。默认情况下，CloudTrail API 事件日志会保存 90 天。数据事件，例如 S3 存储桶操作和 Lambda 调用，默认情况下也不会被记录。为了将日志保存超过 90 天，启用 S3 或 Lambda 的数据事件日志记录，并且在日志搜索中提供更多灵活性，我们可以创建一个轨迹，将数据记录到 S3 存储桶中。

准备工作

为了成功完成此食谱，我们需要一个有效的 AWS 账户，以及在技术 要求部分中描述的用户。

如何执行...

我们可以按如下方式在 CloudTrail 中创建轨迹：

1. 登录到控制台中的CloudTrail服务。

2. 在左侧边栏点击轨迹。

3. 点击创建轨迹。

4. 提供一个轨迹名称值为aws-sec-cb-events。

5. 保持为我组织中的所有账户启用未勾选。要启用此选项，我们需要登录到我们组织的管理账户。

6. 在存储位置下，选择创建一个新的S3 存储桶。

7. 对于轨迹日志存储桶和文件夹，输入一个新的 S3 存储桶的唯一名称，并指定一个文件夹（前缀）来存储您的日志。我们也可以使用自动填充的值。记住——存储桶名称必须是全局唯一的。

8. 对于日志文件 SSE-KMS 加密，取消勾选启用复选框。

9. 对于日志文件验证，选择启用。

10. 不要为SNS通知投递选择启用。

11. 不要为CloudWatch 日志选择启用。

12. 可选地，添加标签并点击下一步。

13. 对于事件类型，选择管理事件。

图 7.10 – 选择事件类型

1. 在管理事件下，选择读取和写入用于API 活动，然后点击下一步。

图 7.11 – 配置管理事件

1. 在屏幕右下角点击下一步。

2. 在审查和创建页面上，检查所有详细信息，然后点击创建轨迹。我们应该会看到轨迹成功创建的消息。

3. 转到轨迹页面，点击我们轨迹的 S3 存储桶名称，进入我们轨迹的 S3 存储桶。我们也可以手动进入 S3 仪表板并访问此存储桶。我们应该会看到CloudTrail和CloudTrail-Digest文件夹。在这些文件夹中，我们应该会看到按区域划分的子文件夹。

4. 进入文件夹，直到我们看到实际的日志文件。

图 7.12 – CloudTrail 日志文件

1. 在 S3 中选择一个文件，然后在操作下拉菜单中点击使用 S3 Select 查询。

图 7.13 – 使用 S3 Select 的查询

1. 选择 JSON 作为格式，行 作为 JSON 内容类型，GZIP 作为压缩选项。

图 7.14 – 输入设置

1. 对于 输出设置，选择 JSON 格式。

2. 向下滚动，我们现在应该看到 结构化查询语言（SQL）查询语句。根据需要修改 SQL，并点击 运行 SQL 查询。

图 7.15 – 运行 SQL 查询

我们应该在另一个文本框中看到实际的结果，如下图所示：

图 7.16 – 查询结果响应（部分）

1. 点击 下载结果 下载结果。我们可以使用任何兼容的应用程序打开下载的文件，例如 Microsoft Word。

我们创建了一个跟踪，并在本教程中使用了它。从 跟踪 页面，我们可以进入跟踪的配置页面，然后可以选择 删除 或 停止日志记录（如有需要）。

它是如何工作的...

对于存储超过 90 天的日志，我们需要创建一个跟踪（trail），并将日志发送到 S3 桶中。在本教程中，我们创建了一个多区域的跟踪。我们配置了记录所有事件的选项，也可以选择记录特定活动。我们还在跟踪的配置页面看到可以停止日志记录的选项。停止日志记录将阻止任何新事件发送到日志，但现有日志仍然可以访问。

我们在 AWS CloudTrail 中配置了管理事件，以监控 AWS 服务 API 活动并跟踪读写操作，以及对资源和配置的更改，涵盖我们 AWS 账户中的所有活动。此设置捕获了如创建、删除、修改和描述 AWS 资源等操作，确保对审计和合规性的全面监管。

还有更多内容...

在这个食谱中，我们没有启用数据事件和 Insights 事件。数据事件记录诸如 S3 对象变更和 Lambda 函数调用等操作，提供详细的资源监控，但启用它们会增加日志记录成本。CloudTrail 允许记录数据事件选项，如S3、S3、S3、Amazon Q 应用、Amazon Q 商业应用、Amazon Q 商业数据源、Amazon Q 商业索引、S3、S3、AWS Cloud Map 命名空间、AWS Cloud Map 服务、B2B 数据交换、Bedrock 代理别名、Bedrock 知识库、Cassandra 表、S3、CloudTrail 渠道、CloudWatch 指标、S3、CodeWhisperer 自定义、Cognito 身份池、S3、EBS 直接 API、EMR 写前日志工作区、S3、Guard Duty 检测器、IoT 证书、IoT Greengrass 组件版本、IoT Greengrass 部署、IoT SiteWise 资产、IoT SiteWise 时间序列、IoT 设备、IoT TwinMaker 实体、IoT TwinMaker 工作区、Kendra 排名、Kinesis 流、Kinesis 流消费者、Kinesis 视频流、S3、机器学习 MIModel、托管区块链、托管区块链网络、托管区块链查询、医疗影像数据存储、Neptune 图数据库、用于 Active Directory 的私有 CA 连接器、用于 SCEP 的私有 CA 连接器、RDS 数据 API - 数据库集群、S3 访问点、S3 对象 Lambda、S3、SageMaker 端点、SageMaker 特征存储、SageMaker 指标实验试验组件、SNS 平台端点、SNS 主题、S3、Step Functions 状态机、供应链、SWF 域、系统管理器、系统管理器托管节点、瘦客户机设备、瘦客户机环境、Timestream 数据库、Timestream 表和X-Ray 跟踪等。这些选项提供了对我们 AWS 资源活动的额外洞察。

Insight 事件日志侧重于检测与修改或管理 AWS 资源相关的 API 调用的异常使用模式或潜在的安全威胁。Insight 事件不能单独选择，必须与管理事件配对，以确保对 AWS API 活动的全面日志记录和上下文分析，服务于安全、合规和操作目的。

在这个食谱中，我们直接从 S3 控制台查询了 S3 中的日志。为了在查询 S3 中的 CloudTrail 日志时获得更多的灵活性，我们可以使用 Amazon Athena。我们将在本章的使用 Athena 查询 S3 中的 CloudTrail 日志食谱中学习如何使用 Amazon Athena 查询 CloudTrail 日志。

另见

在 www.cloudericks.com/blog/deep-dive-into-aws-cloudtrail 了解更多关于 CloudTrail 的内容。

使用 Athena 查询 S3 中的 CloudTrail 日志

在这个配方中，我们将学习如何使用Amazon Athena查询 CloudTrail 日志。使用 Athena 查询 CloudTrail 日志为我们提供了更大的灵活性。例如，当多个账户将日志发送到 CloudTrail 的 S3 桶时，我们无法在 CloudTrail 控制台中基于账户 ID 进行筛选。然而，我们可以使用 Athena 来基于账户 ID 查询 CloudTrail 的 S3 桶中的日志。

准备工作

我们需要以下内容才能成功完成这个操作：

• 一个有效的 AWS 账户和技术 要求部分中描述的用户。

• 在 CloudTrail 中创建的追踪，按照本章节中的在 CloudTrail 中创建追踪配方操作。

• 如果我们是 Athena 新手，在运行查询之前，我们需要设置一个查询结果存储位置在 Amazon S3，步骤如下：

  1. 为查询结果创建一个桶。我将我的桶命名为aws-sec-cb2-query-results。为您的桶选择一个唯一的名称。

  2. 转到管理控制台中的Athena服务。

  3. 转到查询编辑器标签。如果我们是 Athena 新手，我们应该会看到一个警告，提示在运行第一次查询之前，您需要在 Amazon S3 中设置查询结果位置。点击编辑设置。

  4. 浏览 S3 并选择我们为查询结果创建的桶。

  5. 保持其他选项不变，点击保存。

图 7.17 – 设置查询结果位置

如何操作…

我们可以按照以下步骤设置 Athena 并查询 CloudTrail 日志：

1. 登录到管理控制台中的CloudTrail服务。

2. 点击左侧边栏中的事件历史。这将带我们进入事件历史页面。

3. 点击创建 Athena 表，如我们在图 7 9中看到的。

4. 对于存储位置，选择我们追踪的 S3 桶。

图 7.18 – 创建 Athena 表

1. 向下滚动并点击创建表。我们应该看到一个成功消息，表已经创建。

2. 现在，转到管理控制台中的Athena服务。

3. 转到查询编辑器标签。我们应该在左侧的表下看到我们的表，并在右侧看到查询编辑器窗口。表在从 CloudTrail 仪表板启动创建后，可能需要一些时间才能在 Athena 仪表板上显示。我们可以使用左侧边栏中的刷新图标手动刷新表格列表。

4. 点击我们表格旁边的三个点按钮，然后点击预览表。将创建一个示例查询，我们可以修改它以满足我们的需求。

   我在查询中将限制设置为2，如下所示：SELECT * FROM "default"."cloudtrail_logs_aws_cloudtrail_logs_370598287390_66c52071"limit 2;。

5. 点击运行。

6. 点击页面右上方的下载结果图标，以 CSV 格式下载结果。

   如果我们访问为存储结果创建的 S3 存储桶，在我的案例中是 aws-sec-cb2-query-results，我们应该能在那里看到保存的查询结果。

它是如何工作的...

在本教程中，我们使用 Amazon Athena 查询存储在 S3 中的 CloudTrail 日志。Athena 使用基于 SQL 的查询并创建虚拟表。如果我们是 Athena 新手，在执行查询之前，应该先在 Amazon S3 中设置查询结果存储位置。我们从 CloudTrail 仪表盘创建了一个 Athena 表。然后，我们进入 Athena 并运行了一个预览查询。我们修改了查询并执行了它。最后，我们从结果页面将结果导出为 CSV 文件。

还有更多...

让我们快速了解与 Amazon Athena 相关的一些重要概念：

• Athena 是 AWS 提供的一项查询服务，用于通过 SQL 在 Amazon S3 中分析数据。

• Athena 只能查询 S3 数据，而不能直接查询 CloudTrail。

• Amazon Athena 现在支持联合查询。我们可以跨存储在关系型、非关系型、对象存储和自定义数据源中的数据运行 SQL 查询，然后将结果存储到 Amazon S3。撰写时，该功能处于预览阶段。Athena 是无服务器的。我们无需设置任何基础设施，只需为我们运行的查询付费。

• Athena 与 AWS Glue 集成，使我们能够爬取数据源，填充表和分区定义，甚至维护模式版本控制。

跨账户 CloudTrail 日志记录

通过跨账户 CloudTrail 日志记录，我们可以将日志存储在与生成日志的账户不同的账户中。通过将日志存储在单独的账户中，我们将日志与源账户隔离，从而防止任何有权限访问源账户的人篡改日志。我们可以为日志账户提供账户级别的访问权限给有限的人群。将多个账户的日志发送到单一账户也为我们提供了一个中心位置来查询日志。

要设置跨账户的 CloudTrail 日志记录，我们需要两个 AWS 账户：一个日志账户（存储日志的地方）和一个日志发送账户（发送日志的地方）。如果我们使用 AWS Organizations，可以通过在创建轨迹时选择为我组织中的所有账户启用，从管理账户启用跨账户的 CloudTrail。这样，组织的轨迹将在所有成员账户中创建，这意味着我们不需要修改存储桶策略。然而，启用此选项可能会导致额外费用，因为如果成员账户已经有轨迹，则每个区域内只有第一个轨迹是免费的。

在本食谱中，我们没有选择使用 AWS Organizations 启用跨账户 CloudTrail 日志记录的选项。要在不使用 AWS Organizations 的情况下设置跨账户 CloudTrail 日志记录，首先在日志账户中配置一个 CloudTrail 跟踪，并设置一个 S3 桶来存储日志。修改桶策略以允许 CloudTrail 服务和来自两个账户的特定 IAM 角色将日志写入桶中。然后，在日志账户中创建一个跟踪，并指定日志账户的 S3 桶作为存储位置。验证来自日志账户的日志是否正确存储在日志账户中指定的 S3 桶内。此设置将源账户的日志隔离，并集中存储日志，从而增强了安全性和可管理性。

另见

• 阅读更多关于 Amazon Athena 的信息，请访问www.cloudericks.com/blog/getting-started-with-amazon-athena。

• 阅读更多关于跨账户 CloudTrail 日志记录的信息，请访问www.cloudericks.com/blog/getting-started-with-cross-account-cloudtrail-logging。

利用 CloudFormation 模板将 CloudWatch 与 CloudTrail 集成

在本食谱中，我们将学习如何将 CloudWatch 与 CloudTrail 集成。集成后，我们可以在 CloudWatch 中基于 CloudTrail 日志创建度量过滤器和警报。我们还将学习如何使用 AWS 提供的 CloudFormation 模板，在 CloudWatch 中创建一组使用 CloudTrail 日志的警报。

准备工作

我们需要以下内容才能成功完成这个食谱：

• 一个有效的 AWS 账户和如技术 要求部分所述的用户。

• 通过遵循本章节的在 CloudTrail 中创建跟踪食谱，创建一个跟踪。

重要提示

在创建跟踪时，你也可以通过对这些步骤做少量修改来执行本食谱中的操作。

如何操作...

我们可以按照以下步骤将 CloudWatch 与现有的跟踪集成：

1. 进入管理控制台中的CloudTrail服务。

2. 从左侧边栏点击跟踪。

3. 点击我们的跟踪名称，进入跟踪的配置页面。

4. 向下滚动到CloudWatch 日志部分，并点击编辑。

5. 对于CloudWatch Logs，选择启用复选框。

6. 对于日志组，选择新建并保持日志组名称不变，在我的案例中为aws-cloudtrail-logs-370598287390-b9277b0a。我们也可以通过现有选项使用现有日志组。

7. 对于IAM 角色，选择新建，提供角色名称，然后点击保存更改。

8. 从s3-us-west-2.amazonaws.com/awscloudtrail/cloudwatch-alarms-for-cloudtrail-api-activity/CloudWatch_Alarms_for_CloudTrail_API_Activity.json下载 CloudFormation 模板并保存在本地。

9. 进入管理控制台中的CloudFormation服务并点击创建堆栈。

10. 对于准备模板，请选择选择现有模板选项。

图 7.19 – 准备模板

1. 在指定模板下，选择上传模板文件选项，使用选择文件选项上传我们在本节第 8 步下载的模板。

图 7.20 – 指定模板

1. 向下滚动并点击下一步。

2. 在指定堆栈详细信息页面，提供堆栈名称和电子邮件地址，以便在 API 活动触发警报时，我们能收到通知。

3. 保持云跟踪日志组名称不变，然后点击下一步。

4. 在配置堆栈选项页面，保持默认设置不变，然后点击下一步。

5. 在审核并创建页面，检查所有内容，然后点击提交。等待我们的 CloudFormation 堆栈创建完成。

6. 在 CloudFormation 堆栈成功创建后，我们将收到一封电子邮件，要求我们验证电子邮件地址。要开始接收警报激活时的电子邮件通知，请点击电子邮件中的确认订阅链接。

7. 如果我们进入CloudWatch中的警报页面，我们将能够查看新创建的警报。我们可以等待警报状态变为OK或ALARM，并操作这些警报，以更好地了解它们。

它是如何工作的...

在这个教程中，我们通过设置 CloudTrail 将 CloudWatch 与 CloudTrail 集成。CloudTrail 请求我们授权将与我们账户中的 API 活动相关的 CloudTrail 事件传递到我们的日志组中。我们从控制台允许了这一操作。授予了以下权限：

• CreateLogStream，在我们指定的日志组中创建一个日志流

• PutLogEvents，将 CloudTrail 事件传递到日志流

我们使用了 AWS 提供的 CloudFormation 模板来为与安全性和网络相关的 API 活动设置了一些 CloudWatch 警报。如果我们删除 CloudFormation 堆栈，所有的警报也会被删除。

AWS 使用 SNS 发送通知，并为我们创建了 SNS 主题订阅。我们需要通过验证我们的电子邮件地址来确认电子邮件订阅，因为 SNS 在我们手动确认订阅之前不会发送通知。

还有更多...

在这个教程中，我们将 CloudWatch 与 CloudTrail 集成，并使用 Amazon 提供的 CloudFormation 模板创建了一些与安全性和网络相关的 API 活动警报。你可以按照本章中与 CloudWatch 警报和指标配合使用一节的另见部分的参考，将这些警报添加到仪表板中。

另见

阅读更多关于 CloudFormation 的信息，请访问 www.cloudericks.com/blog/aws-cloudformation-for-absolute-beginners。

设置和使用 AWS Config

在本教程中，我们将学习如何设置和使用 AWS Config。我们可以使用 Config 来记录和评估 AWS 资源的配置。我们可以创建定义安全标准的规则，并查找不符合安全标准的资源。Config 还支持在检测到问题时自动修复。

准备工作

为了成功完成本教程，我们需要以下内容：

• 一个有效的 AWS 账户和如技术 要求部分所述的用户。

• 如果您想添加 SNS 主题以接收通知，可以按照本章中的创建一个发送电子邮件的 SNS 主题教程创建一个带有电子邮件订阅的 SNS 主题。

• 为了测试，我们需要至少一个未启用多因素身份验证（MFA）的 IAM 用户。

如何操作...

首先，我们将首次设置 AWS Config，然后我们将看到如何使用 AWS Config。让我们开始吧：

1. 当我们第一次登录管理控制台中的AWS Config服务时，我们将看到一个入门页面。点击开始使用，我们将进入设置页面。

2. 在录制方式部分，对于录制策略，选择所有资源类型，带有可自定义的覆盖**。

图 7.21 – AWS Config 录制方式

1. 对于录制频率，选择连续录制。

图 7.22 – 录制频率

1. 在覆盖设置部分，点击删除。

图 7.23 – 覆盖设置

1. 在数据治理部分，选择创建 AWS Config 服务关联角色。或者，我们可以选择我们账户中的角色。

2. 在交付方式部分，选择创建一个存储桶并给出一个 S3 存储桶名称。

图 7.24 – 交付方式部分

1. 在Amazon SNS 主题部分，选择将配置更改和通知流式传输到 Amazon SNS 主题，然后选择从您的账户选择主题，最后选择我们在准备工作部分中创建的主题。或者，我们可以创建一个新主题，或者选择另一个账户中的主题。

图 7.25 – 选择 Amazon SNS 主题

1. 在页面底部，点击下一步。

2. 在AWS 托管规则页面，搜索并选择iam-user-mfa-enabled规则。点击下一步。如果需要，我们可以添加更多规则。完成设置过程后，我们也可以添加规则。

3. 在审核页面，审核更改并点击右下角的确认。我们将被重定向到 AWS Config 仪表板。在仪表板中，我们可以看到按合规性评分的符合性包、合规状态、按非合规资源计数的非合规规则、资源清单、AWS Config 使用指标和AWS Config 成功指标。

4. 如果我们有一个没有启用 MFA 的 IAM 用户，如在准备工作部分讨论的那样，我们应该看到该用户不符合我们的iam-user-mfa-enabled规则。

   请注意，非合规资源在仪表板中显示可能需要一些时间。我们还可以对规则执行以下操作：管理修复、重新评估、删除结果和删除规则。

工作原理...

在这个教程中，我们在我们的账户上设置了 AWS Config。我们选择了记录此区域中支持的所有资源和包括全局资源（例如，AWS IAM 资源），以记录所有区域的所有资源。我们也可以通过取消勾选记录此区域中支持的所有资源，然后在特定类型字段中选择我们想要记录的资源，来配置特定资源的记录。

我们启用了 SNS 通知，通过从我们的账户选择一个带有电子邮件订阅的 SNS 主题来接收电子邮件通知。我们还可以选择另一个账户的 SNS 主题，方法是选择从另一个账户选择主题选项。在AWS Config 角色部分，我们选择了创建 AWS Config 服务链接角色。该角色授予 Config 只读访问权限，以便我们记录配置信息。该角色还授予将信息发送到 S3 和 SNS 的权限。

在这里，我们选择了iam-user-mfa-enabled规则，这是一个周期性规则。周期性规则定期运行，而非周期性规则（基于配置更改的规则）会在关联的配置发生更改时立即运行。

还有更多内容...

让我们了解一些与 AWS Config 相关的重要概念：

• 我们可以使用 AWS Config 进行的一些检查包括：检查是否启用了 MFA，检查 S3 存储桶是否为公开的，数据库是否已加密，VPC 流日志是否启用等。

• 我们可以使用 AWS Lambda 编写自己的自定义规则。

• AWS Config 可以为规则执行自动修复操作。例如，我们可以根据规则更改 EC2 实例的配置。然而，AWS 可能会停止并重新启动 EC2 实例，因此我们需要考虑可能的停机时间。

• 要从新的控制台配置自动修复，我们可以进入我们的规则，点击操作下拉菜单，选择管理修复。

• 我们可以在多个账户中使用相同的 Config 规则，以确保它们都遵循一组共同的规则。

• 我们可以在 AWS Config 中创建一个聚合器，查看跨所有区域的多个账户的 AWS 资源清单或 Config 规则合规性状态。在当前控制台中，我们可以通过从左侧边栏进入聚合视图，然后点击添加聚合器来创建聚合器。

• AWS Config 的收费基于记录的规则评估次数。

创建自定义规则的步骤可以总结如下：

1. 创建一个 IAM 角色，该角色可以被 Lambda 使用，并具有所需的权限。为了向 AWS Config 报告，我们需要提供AWSConfigRulesExecutionRole。为了将日志发送到 CloudWatch，我们需要添加AWSLambdaBasicExecutionRole。最后，我们需要授予它访问它将要监控的服务的权限（例如，访问 S3 时需要AmazonS3ReadOnlyAccess）。

2. 通过选择我们在上一步中创建的 IAM 角色，并使用任何支持的编程语言，来创建一个 Lambda。

3. 在 Lambda 中编写一些代码，以评估我们正在监控的服务参数（例如，S3 存储桶属性），每次评估后更新一个ResultToken对象，并将一组ResultToken对象返回给 Config。ResultToken对象应包含以下信息：ComplianceResourceType（例如，AWS::S3::Bucket），ComplianceResourceId（例如，存储桶名称），ComplianceType（COMPLIANT或NON_COMPLIANT）和OrderingTimestamp。

4. 在 Config 控制台中，我们可以进入规则，然后选择添加规则，并选择添加自定义规则。当你执行此操作时，相关的屏幕名称可能会有所不同。

5. 将触发类型字段设置为配置更改或周期性。

6. 接下来，我们可以选择为我们的规则设置修复操作或通知。

7. 点击保存。我们的规则应与其他规则一起列在规则页面上。

另见

阅读更多关于 AWS Config 的内容，请访问 www.cloudericks.com/blog/getting-started-with-aws-config.vp。

第八章：GuardDuty、Macie、Inspector 和 Analyzer 的合规性

定期检查账户的合规性，并在发现任何不合规时收到通知，是保持账户安全的重要步骤。在本章中，我们将了解 AWS 内的一些服务，这些服务可以帮助我们检查合规性，通过附加的智能和规则。我们将学习Amazon GuardDuty、Amazon Macie和Amazon Inspector，它们利用机器学习和高级算法帮助我们检查合规性。AWS Config 是另一项可以帮助合规性的服务，但我们已在第七章中讲解过它。

本章包括以下操作：

• 设置并使用 Amazon GuardDuty

• 聚合来自多个账户的 GuardDuty 发现结果

• 设置并使用 Amazon Macie

• 设置并使用 Amazon Inspector

• 设置并使用 AWS Security Hub

• 使用 IAM Analyzer 检查未使用的访问权限

技术要求

在开始本章的操作之前，我们需要确保具备以下要求和知识：

• 我们需要一个有效的 AWS 账户来完成本章中的操作。如果我们使用 AWS 组织，我们可以使用组织的管理账户，因为在本章中我们将在 AWS 组织级别配置很多内容。我将使用在第一章中的多账户管理与 AWS 组织食谱中创建的aws-sec-cookbook-1账户。

• 对于管理员操作，我们需要一个具有AdministratorAccess权限的用户，才能访问我们正在使用的 AWS 账户。

本章的代码文件可在github.com/PacktPublishing/AWS-Security-Cookbook-Second-Edition/tree/main/Chapter08 获取。

设置并使用 Amazon GuardDuty

在本食谱中，我们将学习如何设置并使用 Amazon GuardDuty。GuardDuty 分析来自 CloudTrail 管理日志、VPC 流日志和 Route 53 DNS 日志等源的数据，并使用机器学习、异常检测和集成的威胁情报来发现恶意活动和未经授权的行为。请注意，如果您使用其他 DNS 解析器，如 OpenDNS 或 GoogleDNS，或设置了自己的 DNS 解析器，GuardDuty 无法访问和处理来自这些源的数据。GuardDuty 可以与 CloudWatch 和 SNS 集成，以触发警报并发送通知。GuardDuty 还可以聚合来自多个账户的数据。

准备工作

要成功完成这个操作，我们需要一个有效的 AWS 账户和一个用户，具体要求请参见技术要求部分。我们还需要一个 S3 存储桶。

如何操作...

如果我们第一次使用 GuardDuty，我们需要先启用 GuardDuty。让我们开始吧：

1. 在 AWS 管理控制台中转到GuardDuty服务。

2. 如果我们是第一次使用 GuardDuty，应该会看到如下选项。如果 GuardDuty 已经启用，请跳到步骤 4。

图 8.1 – 启用 GuardDuty

1. 选择Amazon GuardDuty - 全功能，然后点击开始使用。我们现在应该看到欢迎使用 GuardDuty屏幕；点击启用 GuardDuty。

2. 在GuardDuty仪表板的左侧边栏点击发现。我们可以看到这里的发现按高、中和低分类。由于我们刚刚启用它，初始时可能不会看到任何发现。

图 8.2 – 发现屏幕

1. 我们可以点击任何一个事件，查看该发现提供的更多信息。然后我们可以向下滚动到操作、目标和附加信息部分，了解更多关于该事件的信息。

接下来，我们将在 GuardDuty 中进行 IP 白名单和黑名单管理。

在 GuardDuty 中进行 IP 白名单和黑名单管理

我们可以按照以下方式在 GuardDuty 中进行 IP 白名单和黑名单管理：

1. 创建并上传以下两个文件，一个是信任的 IP 列表，另一个是威胁列表，并将它们上传到 S3 存储桶：

   • trusted-ips.txt：这是一个文本文件，包含我们希望信任的 IP 和 CIDR 范围。每个 IP 或 CIDR 范围应该占一行。

图 8.3 – 信任的 IP 文件

• threat-lists.txt：这是一个文本文件，包含我们希望添加到可疑 IP 列表中的 IP 和 CIDR 范围。每个 IP 或 CIDR 范围应该占一行。

图 8.4 – 威胁列表文件

1. 现在，返回到GuardDuty仪表板。在左侧边栏点击列表。

2. 在信任的 IP 列表下，点击添加信任的 IP 列表。

3. 在名为添加信任的 IP 列表的弹出屏幕中，在列表名称字段为我们的列表命名。对于位置，输入您信任的 IP 列表的 S3 URL，格式为https://myguarddutydemo.s3.amazonaws.com/trusted-ips.txt。对于格式，选择纯文本。然后勾选我同意复选框。最后，点击添加列表。我们现在应该可以在信任的 IP 列表下看到我们的列表。

4. 勾选我们列表旁边的复选框。点击操作下拉菜单，然后点击激活。我们应该看到一条成功消息，指示该列表已被激活。可能需要一些时间才能使更改生效。

5. 在威胁 IP 列表下，点击添加威胁 IP 列表。我们应该看到一个名为添加威胁 IP 列表的弹出屏幕。

6. 重复步骤 3 到 5，但添加我们的威胁列表，而不是信任的 IP 列表。我们应该会在威胁 IP 列表下看到我们的列表。

7. 为了验证信任的 IP 列表和威胁 IP 列表是否正常工作，我们可以模拟来自列表中 IP 的流量，并检查 GuardDuty 的发现结果：

   • 白名单 IP（受信任的 IP）：从我们 trusted-ips.txt 文件中的 IP 地址生成流量。监控 GuardDuty 发现，确保该流量未被标记为可疑或恶意。

   • 黑名单 IP（威胁 IP）：从我们威胁列表文件中的 IP 地址生成流量。检查 GuardDuty 发现，确认该流量是否被标记为可疑或恶意。

8. 审查 GuardDuty 仪表盘和发现，以确保白名单中的 IP 不会生成任何警报，并且黑名单中的 IP 已被正确标记。这样可以确认我们的列表被 GuardDuty 有效使用。

在本节中，我们通过分别将几个 IP 地址添加到受信任的 IP 列表和威胁列表中，将这些 IP 地址列入白名单和黑名单。我们将在本教程的 工作原理… 部分深入了解它们是如何工作的。

工作原理…

我们首先启用了 GuardDuty。当我们启用 GuardDuty 时，我们授予它权限以分析各种日志和数据源，如 VPC 流日志、AWS CloudTrail 管理事件日志、DNS 查询日志、AWS CloudTrail S3 数据事件日志、EKS 审计日志、Lambda 网络活动日志和 RDS 登录活动日志，以生成安全发现，正如你在执行本教程 如何操作… 部分的 第 3 步 时看到的那样。此外，GuardDuty 可以分析 弹性块存储（EBS）卷数据以检测恶意软件。当我们第一次在支持的区域启用 GuardDuty 时，我们的账户会自动加入 30 天的免费试用期，这期间可能还会默认包括一些保护计划。

默认情况下，当我们第一次启用 GuardDuty 时，所有保护计划都会激活，除了 S3 的运行时监控和恶意软件保护。这些可以通过 GuardDuty 控制台或 API 启用。GuardDuty 的恶意软件保护和运行时监控服务的使用受 Amazon GuardDuty 服务条款的约束。我们可以随时暂停或禁用 GuardDuty 或任何特定的保护计划，停止其处理和分析数据、事件和日志。然而，暂停或禁用 GuardDuty 不会影响 S3 的恶意软件保护。要停止对我们的 S3 存储桶进行恶意软件扫描，我们必须单独删除每个存储桶的恶意软件保护计划。请注意，GuardDuty 不管理或提供其分析的日志和数据的访问权限；我们可以通过各自的控制台或 API 配置这些数据源。

为了进行测试，我们从 GuardDuty 控制台生成了示例发现；GuardDuty 生成了 54 个示例事件（在我的案例中 – 这可能会有所不同，因为 GuardDuty 会在一年中增加和淘汰发现类型）。GuardDuty 事件分为三个严重性级别，从最低到最高，分别由蓝色、黄色和红色图标表示，蓝色为最轻，红色为最严重。点击发现后，我们将获得关于该发现的更多信息。

我们通过将一些 IP 地址添加到受信任 IP 和威胁列表中，分别将它们列入白名单和黑名单。GuardDuty 不会对已包含在受信任 IP 列表中的 IP 地址生成检测结果。这是为了避免误报，特别是来自公司 IP 地址的误报。然而，我们需要记住，攻击也可能来自内部。威胁列表由已知的恶意 IP 地址组成。我们提供的地址将与 AWS 基于其研究和经验所提供的地址一起使用。

我们可以将一个 IP 或 CIDR 范围添加到受信任 IP 列表和威胁列表中，格式多样，包括纯文本格式（每行一个 IP 或 CIDR），结构化威胁信息表达式（STIX）、开放威胁交换（OTX）CSV、FireEye iSIGHT 威胁情报 CSV、Proofpoint ET 情报源 CSV、AlienVault 声誉源 CSV。目前，受信任 IP 列表最多可以有 2,000 行，威胁列表最多可以有 250,000 行。

还有更多……

作为一项新功能，Amazon GuardDuty S3 恶意软件保护可以检测上传到我们选择的 Amazon S3 存储桶中的恶意文件。我们可以为属于我们账户的 S3 存储桶启用恶意软件保护，并使用 GuardDuty 控制台中嵌入的 Amazon CloudWatch 指标来监控恶意软件扫描状态。我们在 图 8 .1* 中已经看到了这个选项。

让我们了解一些与 GuardDuty 相关的重要概念：

• GuardDuty 通过分析 VPC 流日志来检测受损的 EC2 实例——例如，GuardDuty 可以检测实例是否被用于 拒绝服务（DOS）攻击。

• GuardDuty 可以检测我们的实例是否被用于加密货币挖矿。它还可以检测我们的凭证是否被盗，例如通过访问恶意 IP、使用 EC2 实例配置文件访问 EC2 以外的资源，或对 AWS 资源（如 S3、EC2、RDS 等）发出异常的 API 调用。

• GuardDuty 可以扫描并检测 EC2 实例和 EKS 基础设施中的恶意文件。它还可以帮助识别上传到 S3 存储桶中的恶意文件。

• GuardDuty 是一项区域性服务。即使启用了多个账户并使用了多个 AWS 区域，GuardDuty 的安全检测结果仍然保留在生成底层数据的同一地区。

• 我们可以将来自不同账户的 GuardDuty 检测结果汇总到一个账户中。我们将在 GuardDuty 中汇总多个账户的检测结果 配方中讨论这个内容。

• 我们可以将不同账户和区域的 GuardDuty 检测结果导出到一个 Amazon S3 存储桶中，以简化所有检测结果的汇总。这是一个新功能，区别于将多个账户的检测结果汇总到一个账户中。

• 我们可以使用 CloudWatch 和 SNS 来监控 GuardDuty 的检测结果并发送通知。

• GuardDuty 的定价是基于分析的数据量：

  • 对于 VPC 流日志和 DNS 日志分析，GuardDuty 根据分析的数据大小收费。

  • 对于 CloudTrail 事件，GuardDuty 会根据分析的事件数量收费。

• GuardDuty 支持商家或服务提供商处理、存储和传输信用卡数据，并已通过支付卡行业(PCI) 数据安全(DSS) 标准的合规性验证。

设置 Amazon EventBridge 以监控来自 GuardDuty 的发现

设置 Amazon EventBridge 以监控来自 GuardDuty 的发现的步骤总结如下：

1. 转到管理控制台中的EventBridge 服务。

重要说明

EventBridge 曾被称为 Amazon CloudWatch 事件。目前，如果我们导航到 CloudWatch 并点击事件部分下的规则，我们将被重定向到 EventBridge 控制台。

1. 在左侧边栏中点击总线下的规则。

2. 点击创建规则以进入创建规则页面。

3. 在定义规则详细信息页面中，为我们的规则提供名称和描述。将事件总线的值保持为默认，规则类型为带事件模式的规则，然后点击下一步。

4. 在构建事件模式部分，向下滚动到事件模式。

5. 设置事件源为AWS 事件或 EventBridge合作伙伴事件。

6. 设置AWS 服务为GuardDuty。

7. 设置事件类型为GuardDuty 发现。

8. 点击下一步。在目标下，执行以下操作：

   1. 在选择目标下，从下拉菜单中选择SNS 主题。

   2. 选择一个主题。你可以通过参考 第七章 中的创建 SNS 主题以发送电子邮件配方来创建 SNS 主题。

9. 点击下一步。

10. 可选地，点击添加新标签，然后点击下一步。

11. 审核规则并点击创建规则。

12. 返回GuardDuty服务并点击左侧边栏的设置。

13. 向下滚动到示例发现并点击生成示例发现。稍后，检查我们为 SNS 主题配置的电子邮件地址的收件箱，应该会收到一封关于 GuardDuty 发现的邮件。

14. 要配置和修改 GuardDuty 更新 EventBridge 和 S3 的频率，我们可以转到GuardDuty服务，点击左侧边栏的设置，并在发现导出选项部分点击编辑。

15. 如果我们尚未配置导出到 S3，则会提供一个立即配置选项来进行配置。

另见

阅读更多关于 GuardDuty 的信息，请访问 www.cloudericks.com/blog/getting-started-with-amazon-guardduty。

汇总来自多个账户的 GuardDuty 发现

在这个流程中，我们将配置 GuardDuty 以 聚合发现结果，将多个 AWS 账户的发现结果汇总到一个账户中。将多个账户的发现结果聚合到一个专用账户中，可以为我们提供一个查询所有账户发现结果的集中位置。我们也可以在一个地方为所有账户进行配置更改。

准备中

我们需要以下内容来成功完成这个流程：

• 需要两个有效的 AWS 账户。我们将它们称为聚合账户和日志账户。聚合账户将聚合来自成员账户的日志。

• 记下成员账户的 AWS 账户 ID 和电子邮件地址。如果我们使用的是 AWS Organizations 和 IAM 身份中心，正如我们在 第一章 中看到的，我们可以从 AWS Organizations 服务或 IAM 身份中心服务的管理账户中获取这些信息。

• 我们应该通过本章节中的 设置和使用 Amazon GuardDuty 流程，启用聚合账户和成员账户中的 GuardDuty。

如何操作...

我们可以按照以下方式配置 GuardDuty，以聚合成员账户的发现结果：

1. 进入聚合账户的管理控制台中的 GuardDuty 服务。

2. 从左侧边栏点击 账户。

3. 点击 通过邀请添加账户。

4. 输入成员账户的 AWS 账户 ID 和电子邮件地址，然后点击 下一步。

5. 我们应该能在 账户 页面看到我们的账户。状态 字段将显示 邀请未发送。

6. 选择我们刚刚添加的账户，点击 操作 下拉菜单，然后点击 邀请。

7. 在弹出窗口中，您可以选择性地提供消息。保持 同时向受邀者 AWS 账户的根用户发送电子邮件通知，并在受邀者的个人健康仪表板中生成警报 的选项未选中，然后点击 发送邀请。我们账户的状态应该会变为 已邀请。

8. 进入成员账户的管理控制台中的 GuardDuty 服务。

9. 如果我们现在启用 GuardDuty，启用后将跳转到 邀请 页面。否则，请从左侧边栏进入 账户 页面并点击 接受邀请。

10. 从左侧边栏点击 设置，进入 设置 页面并点击 生成示例发现。

11. 进入聚合账户中的 GuardDuty 仪表板，检查是否有来自我们成员账户的发现结果。

在这个流程中，我们配置了一个成员账户，将日志发送到聚合账户。聚合账户将聚合来自我们添加的成员账户以及以后添加的任何其他成员账户的日志。

它是如何工作的...

首先，我们登录到主账户，这个账户将聚合所有 GuardDuty 发现结果。然后，我们邀请了一个成员账户。我们已经记下了该账户的账户 ID，并且应该知道该账户的根邮箱地址。接着，我们登录到成员账户并接受邀请。之后，我们从成员账户生成了示例发现结果。最后，我们重新登录到主账户并验证，发现成员账户的发现结果已经出现在主账户中。

还有更多...

GuardDuty 会保留生成的发现结果 90 天。它将活动发现结果导出到 Amazon EventBridge（EventBridge）。此外，我们还可以选择将这些发现结果导出到 Amazon S3 存储桶。这使我们能够跟踪账户中潜在可疑活动的历史数据，并评估推荐的修复步骤的有效性。我们可以按照以下步骤进行：

1. 按如下方式配置 KMS 密钥：

   1. 创建或选择一个 KMS 密钥：选择现有的 KMS 密钥或创建一个新的密钥。

   2. 将策略附加到 KMS 密钥：将策略附加到 KMS 密钥，以授予 GuardDuty 访问权限。请参阅代码文件中的guardduty_kms_policy.json文件，了解示例策略内容。

2. 按如下方式配置 S3 存储桶：

   1. 选择一个 S3 存储桶：可以创建一个新的存储桶或使用现有的存储桶。

   2. 更新存储桶策略：更新存储桶策略以允许 GuardDuty 上传。请参阅代码文件中的guardduty_s3_bucket_policy.json文件，了解示例策略内容。

3. 在 GuardDuty 控制台中按如下方式配置发现导出：

   1. 进入 GuardDuty 仪表盘。

   2. 通过点击左侧边栏的设置选项进入设置。

   3. 按如下方式配置导出选项：

      1. 向下滚动到发现导出选项部分。

      2. 点击立即配置。

      3. 输入 S3 存储桶和 KMS 密钥的 ARN。提供将导出发现结果的 S3 存储桶 ARN。提供用于加密发现结果的 KMS 密钥 ARN。

      4. 点击保存以应用设置。

通过执行上述步骤，我们可以配置 AWS GuardDuty 将其发现结果导出到 S3 存储桶，确保跨账户和区域聚合并保护数据。请确保根据需要使用实际值更新示例策略文件。

另见

在 GuardDuty 中阅读有关导出发现功能的更多信息：docs.aws.amazon.com/guardduty/latest/ug/guardduty_exportfindings.html。

设置和使用 Amazon Macie

在本文档中，我们将学习如何设置和使用 Amazon Macie。Macie 是 AWS 中基于机器学习的服务，主要用于发现、分类和保护敏感数据。Macie 可以分析 S3 存储桶中的数据，以查找诸如凭据、财务信息、受保护健康信息（PHI）、个人可识别信息（PII）、API 密钥、源代码等敏感信息，并将其分类为不同的安全级别。Macie 可与 CloudWatch 配合使用来发出警报并发送通知。Macie 还可以分析来自 CloudTrail 的 API 调用以检测异常。

准备工作

我们需要以下内容才能成功完成此文档：

• 我们需要一个有效的 AWS 帐户和用户，如技术要求部分所述。

• 我们需要一个 S3 存储桶。存储桶应该位于我们配置 Macie 的同一区域中。我已在us-east-1区域创建了一个存储桶。

• 我们的 S3 存储桶应包含以下带有假敏感数据的文件，并提供与章节相关的代码文件：

  • credit-cards-data.txt带有样本信用卡数据

  • custom-data-license-plates.txt带有样本车牌

如何做…

我们可以按照以下步骤配置 Macie 来发现和分类 S3 存储桶中的风险：

1. 转到 AWS 管理控制台中的Amazon Macie服务。

重要提示

如果我们是第一次使用 Macie，应该会看到一个带有开始按钮的页面。单击开始。确保所选的区域与我们的存储桶相同，查看服务角色权限，并启用 Macie 开始 30 天的试用期。然后我们将进入摘要页面。自动敏感数据发现的 30 天免费试用不包括敏感数据发现作业。如果您启动并执行作业，则将根据作业分析的未压缩数据总量收取费用。

1. 在 Macie 仪表板的左侧边栏中单击作业。

重要提示

如果我们尚未为敏感数据发现结果配置存储库，将收到警告。我们需要在启用 Macie 后的 30 天内设置此存储库。请注意，Macie 仅存储我们的敏感数据发现结果和发现结果，有效期为 90 天。我们可以立即单击配置以配置现有或新的存储桶作为敏感数据发现结果的存储库，或者我们可以稍后（在 30 天内）使用设置左侧边栏下的发现结果菜单项进行配置。

1. 单击创建作业以启动作业创建过程。

2. 在选择 S3 存储桶页面，选择选择特定的存储桶以选择要在作业中包含的存储桶。我们将选择在本文档的准备工作部分创建的存储桶。

3. 滚动到底部并单击下一步。

4. 对于审查 S3 存储桶页面，请审查和验证我们的存储桶选择，然后选择下一步。

5. 对于精细化范围页面，选择一次性作业，为采样深度提供100%的值，然后点击下一步。

重要提示

不选择一次性作业，我们可以选择定期作业选项，并将更新频率设置为每日、每周或每月，但让我们为这个示例选择一次性作业。在高级设置下，我们可以指定包含或排除某些对象的标准以进行作业分析。如果没有提供标准，作业将分析存储桶中的所有对象。目前，我们应该将这些设置保持为默认设置。

1. 对于管理的数据标识符选项，选择推荐。

图 8.5 – 管理的数据标识符选项

1. 向下滚动并点击下一步。

2. 对于自定义数据标识符，不添加任何内容，然后点击下一步。

3. 对于选择允许列表，不添加任何内容，然后点击下一步。

4. 在输入常规设置窗格中，在作业名称下输入AWS Sec CB Demo。可选地，提供作业描述并根据需要添加任何标签。点击下一步。

5. 在审阅和创建页面上，仔细检查配置设置以确保其准确性，并查看作业的预估总成本。点击提交。

6. 如果我们转到作业页面，我们的作业状态将为活动（运行中）。等到状态变为完成。可能需要 10 到 15 分钟。

7. 从列表中点击超链接作业名称，然后从显示结果下拉菜单中，点击显示发现以查看发现情况。点击发现以了解更多信息。

图 8.6 – Macie 发现选项卡

在本节中，我们看到如何使用 Amazon Macie 查找包含银行账号或信用卡号等财务信息的 S3 对象。接下来，我们将看到如何使用自定义的 Macie 数据标识符。

添加自定义的 Macie 数据标识符

我们可以按照以下步骤配置和使用自定义的 Macie 数据标识符：

1. 导航回 AWS 管理控制台中的 Macie 服务。

2. 点击左侧边栏中的自定义数据标识符。

3. 点击创建。

4. 在名称下提供UKLicensePlates。对于描述 - 可选，输入英国车牌，并将正则表达式设置为以下内容：([0-9][a-zA-Z][a-zA-Z]-?[0-9][a-zA-Z][a-zA-Z])|([a-zA-Z][a-zA-Z][a-zA-Z]-?[0-9][0-9][0-9])|([a-zA-Z][a-zA-Z]-?[0-9][0-9]-?[a-zA-Z][a-zA-Z])|([0-9][0-9][0-9]-?[a-zA-Z][a-zA-Z][a-zA-Z])|([0-9][0-9][0-9]-?[0-9][a-zA-Z][a-zA-Z])

5. 将其他所有内容保持默认，然后点击提交。

6. 通过按照上一节中的步骤创建新作业；但是，在自定义数据标识符页面上，选择在本节中创建的UKLicensePlates。

图 8.7 – 选择自定义数据标识符

1. 一旦任务的状态显示为完成，在任务页面，从显示结果下拉菜单中，点击显示发现。我们应该能够看到一个新的发现，对应我们的自定义标识符任务。

它是如何工作的...

Macie 可以用于分析 S3 存储桶和 CloudTrail 日志。在本配方中，我们探索了 Amazon Macie，这是一项基于机器学习的 AWS 服务，帮助发现、分类和保护存储在 S3 存储桶中的敏感数据。我们设置了 Macie，启动了一个发现任务来扫描特定的 S3 存储桶，并观察它如何成功识别预定义的敏感数据类型，例如信用卡号码。接着，我们通过使用正则表达式创建了一个名为UKLicensePlates的自定义数据标识符，以识别存储在 S3 存储桶中的特定格式。这个自定义标识符被加入到新的发现任务中。任务完成后，我们确认 Macie 成功识别了六个车牌号码，展示了它在发现预定义和用户定义的敏感数据类型方面的能力。

还有更多...

让我们了解一些与 Macie 相关的重要概念：

• Macie 可以在企业中用于多种用途。Macie 可以检测是否有敏感数据或源代码从异常的 IP 地址下载。Macie 可以检测哪些用户导致了最严重的高风险事件。Macie 可以按位置对事件进行分组，帮助我们检测来自未知位置的活动。Macie 还可以提供我们账户中 CloudTrail 事件的高层次分析。如果我们看到任何意外的调用，可以深入调查以找出根本原因。

• Macie 和 GuardDuty 在分析 API 调用方面有功能重叠。与 GuardDuty 不同，Macie 的重点更多在于访问模式，例如上传或下载的数据量是否超过正常情况。一般来说，最好将 Macie 与 GuardDuty 结合使用，以获得更好的保护。

• Macie 可以与 CloudWatch 一起使用，用于触发警报和发送通知。

• Macie 可以汇总来自多个账户的数据。在设置好所需权限后，我们可以从集成页面的账户选项卡添加其他账户。

• Macie 目前对 S3 内容分类和 CloudTrail 事件处理收费。

• Macie 是一个区域性服务。Macie 必须在每个区域逐个启用，并帮助你查看该区域内所有账户的发现。

配置 Macie 警报通知与 Amazon EventBridge 和 SNS 的步骤可以总结如下：

1. 进入控制台中的Amazon EventBridge服务。

2. 从左侧边栏中点击总线下的规则。

3. 点击创建规则进入创建规则页面。

4. 在定义规则详细信息页面，为我们的规则提供名称和描述。将事件总线和规则类型保持为带有事件模式的规则，然后点击下一步。

5. 在构建事件模式部分，向下滚动到事件模式。

6. 设置事件来源为AWS 服务。

7. 设置AWS 服务为Macie。

8. 设置事件类型为Macie 发现。

9. 点击下一步。

10. 在目标部分，选择选择目标，从下拉菜单中选择SNS 主题。

11. 选择一个主题。你可以通过按照第七章中的创建 SNS 主题以发送电子邮件流程来创建 SNS 主题。

12. 点击下一步。

13. 可选地，点击添加新标签，然后点击下一步。

14. 审查规则并点击创建规则。

15. 返回到Macie 服务并按照上一部分中的步骤为我们的 S3 存储桶创建任务。

16. 一段时间后，检查我们为 SNS 主题配置的电子邮件收件箱，我们应该会收到关于 Macie 发现结果的电子邮件。

默认情况下，Macie 会自动将其发现结果发送到 Amazon EventBridge，进行进一步处理并与其他 AWS 服务集成。你可以根据以下步骤配置 Macie 将发现结果发送到额外的目标，并定义更新发送到每个目标的频率：

1. 进入 Macie 控制台，点击左侧边栏上的设置。

2. 向下滚动到发现结果发布，更新策略发现的频率。

另请参见

了解更多关于 Amazon Macie 的信息，请访问 www.cloudericks.com/blog/getting-started-with-amazon-macie。

设置和使用 Amazon Inspector

在本流程中，我们将学习如何设置和使用 Amazon Inspector。Inspector 是一项执行自动化安全评估的服务，用于发现部署在 AWS 上的应用程序中的漏洞或偏离标准实践的情况。我们可以直接在控制台中查看 Inspector 的发现结果，或者从 Inspector 提供的详细评估报告中查看。

准备工作

我们需要以下内容才能成功完成这个流程：

• 我们需要一个有效的 AWS 账户和一个用户，如技术要求部分所述。

• 还需要在默认 VPC 中，一个位于 VPC 公共子网的 EC2 实例。对于Amazon Machine Image (AMI)，选择Amazon Linux 2023 AMI。对于实例类型，选择t2.micro。对于密钥对（登录），选择一个已有的，或者创建一个新的。 在网络设置中，确保自动分配公共 IP的值为启用，并选择创建安全组，同时将允许 SSH 流量来自的值设置为任何地方。

如何执行...

我们可以按如下方式设置 Inspector：

1. 在控制台中进入Amazon Inspector服务。

2. 如果是第一次登录，我们应该看到一个开始使用页面。目前，对于首次使用 Inspector 的账户，提供 15 天的免费试用。点击 开始使用。在 激活 Inspector 页面上，我们应该看到一条如下的消息：当您激活 Inspector 时，您授权 Inspector 获得权限，代表您在 AWS 中发现、分类并保护敏感数据，并生成有关潜在安全问题的发现报告。这将仅为您的账户激活 Inspector。点击 激活 Inspector 并等待完全激活。在左侧边栏中，我们应该能看到如下选项：

图 8.8 – Amazon Inspector 的左侧边栏

如果我们展开 发现，我们可以看到选项，如 按漏洞、按实例、按容器镜像、按容器仓库、按 Lambda 函数 和 所有发现。我们还应该会看到类似以下的消息，但由于 Amazon 经常更新其用户界面和消息，具体内容可能会有所不同。

图 8.9 – 启动 Amazon Inspector 后的消息

1. 等待一段时间后，点击左侧边栏中的 账户管理，进入 实例 选项卡，验证我们的实例状态是否为 正在积极监控。监控方式 栏将显示 无代理，因为我们使用的是基于 EBS 的 EC2 实例。

2. 在左侧边栏中，展开 发现，然后点击 所有发现。

图 8.10 – Inspector 的发现菜单

由于我们使用的是刚刚启动的 EC2 实例，并且是 Amazon Linux，我们不会看到太多发现，但我们应该会看到一个 严重性 为 中等 的发现，内容为 端口 22 可通过互联网网关访问 –TCP。

我们在本节中快速探索了如何查看 Inspector 发现。接下来，我们将在本节的 更多内容... 部分中查看 Inspector 仪表板中提供的更多选项。

它是如何工作的...

Amazon Inspector 对 EC2 的扫描会从实例中提取元数据，并将其与安全建议进行比较，以生成发现，重点关注软件包漏洞和网络可达性问题。网络可达性扫描每 24 小时进行一次，而软件包漏洞扫描的频率则根据扫描方式有所不同。Amazon Inspector 根据账户的扫描模式设置，采用基于代理和无代理的扫描方式来收集软件清单并检测漏洞。

基于代理的扫描使用 SSM 代理从符合条件的实例中持续收集软件清单。这些扫描在 Linux 实例中识别操作系统和应用程序编程语言包的漏洞。要执行基于代理的扫描，实例必须具有受支持的操作系统，由 SSM 管理，并且不被特定标签排除。Amazon Inspector 使用各种 SSM 关联和插件定期收集清单数据并更新漏洞发现。此外，无代理扫描作为混合扫描模式的一部分，利用 EBS 快照从实例中收集清单数据，扫描操作系统和应用程序包漏洞。

Amazon Inspector 提供两种扫描模式：基于代理的扫描和混合扫描。基于代理的模式为 SSM 管理的实例提供持续扫描，而混合扫描结合了两种方法，对于 SSM 管理的实例使用基于代理的扫描，对于符合条件的 EBS 支持的实例使用无代理扫描。用户可以配置扫描模式，管理排除项，并确保适当设置 SSM 代理以优化漏洞检测，并保持对其 EC2 实例的有效安全监控。

还有更多...

我们在这个示例中探讨了 EC2 实例如何进行扫描。Amazon Inspector 还支持对以下资源进行扫描：

• Amazon 弹性容器注册表（ECR）：Amazon Inspector 扫描存储在 Amazon ECR 中的容器映像以查找漏洞。这确保您环境中使用的容器映像是安全的且没有已知问题。

• AWS Lambda：Amazon Inspector 扫描 AWS Lambda 函数以查找漏洞，检查代码和依赖项以确保无服务器应用程序保持安全。

在这个示例中，我们在左侧边栏中探索了发现选项以查看发现。左侧边栏还提供了其他几个选项，包括以下内容：

• 导出 SBOMs：软件材料清单（SBOM）提供了系统内软件组件及其关系的详细列表。Amazon Inspector 可以生成和导出 SBOMs，这有助于理解和管理软件依赖关系，确保符合安全政策，并识别潜在漏洞。这有助于组织维护其软件组件的全面清单。

• 抑制规则：Amazon Inspector 中的抑制规则允许用户通过抑制特定类型或来源的发现来管理发现。这有助于减少噪音并专注于关键漏洞。用户可以根据漏洞 ID、资源标签或资源类型等标准创建抑制规则，以确保安全报告中只突出显示相关的发现。

• 按需扫描：按需扫描允许用户根据需要手动启动扫描，以检测 EC2 实例的漏洞或网络可达性问题。这在部署新软件或进行重大基础设施变更后特别有用。在 按需扫描 菜单下，使用 CIS 扫描 选项，我们可以评估 EC2 实例是否符合 互联网安全中心（CIS）基准，CIS 基准是保护 IT 系统和数据的最佳实践。这些扫描帮助组织遵循安全标准，并通过识别和解决不符合标准的配置，提升安全防护水平。

关于 Inspector Classic 的说明

Inspector 仪表板当前有一个名为 切换到 Inspector Classic 的侧边栏链接。Inspector Classic 是 Amazon Inspector 的原始版本，旨在帮助 AWS 用户通过检查漏洞和合规性问题来自动化应用程序的安全评估。尽管 Inspector Classic 最初至关重要，但它已在很大程度上被新的 Amazon Inspector 所取代，后者提供了增强的功能，并对安全评估提供了更全面、简化的方法。

Inspector Classic 仍然可供已有依赖关系的用户使用，但建议过渡到新的 Amazon Inspector，以便获取最新功能、提高性能和增强的安全能力。AWS 继续支持 Inspector Classic 以保持向后兼容性，但新用户和评估应该使用更新版的 Amazon Inspector 以实现最佳的安全管理。对于有兴趣使用 Inspector Classic 的用户，请参阅本书的第一版或在 另见 部分 提供的链接。

另见

• 你可以阅读更多关于 Amazon Inspector 的内容，访问 www.cloudericks.com/blog/a-deep-dive-into-amazon-inspector-capabilities-and-integrations。

• 阅读有关 Inspector Classic 的内容，请访问 www.cloudericks.com/blog/understanding-inspector-classic-and-transitioning-to-the-new-amazon-inspector。

设置和使用 AWS Security Hub

在本教程中，我们将探讨如何设置和使用 AWS Security Hub。Security Hub 聚合了来自 Config、GuardDuty、Macie 和 Inspector 等服务的发现，提供了一个集中平台来管理安全警报和自动化合规性检查。Security Hub 可以使用 CIS AWS 基础基准进行自动化合规性检查，在启用 Security Hub 时默认启用此功能。

准备工作

我们需要以下内容才能成功完成本教程：

• 如 技术 要求 部分所述，提供一个有效的 AWS 账户和用户。

• 按照 设置和使用 AWS Config 教程中的说明，设置 AWS Config 并启用记录功能，详见 第七章。

• 设置以下一个或多个服务：Amazon GuardDuty、Amazon Macie 和 Amazon Inspector，按照第七章 和 第八章 中的相应方法进行操作。

如何操作…

我们可以按照以下方式在一个区域内设置 Security Hub：

1. 进入 AWS 管理控制台中的Security Hub服务。

2. 如果我们是第一次使用 Security Hub，应该会看到一个开始使用 Security Hub的部分。点击前往 Security Hub。在启用 AWS Config部分，我们应该看到一条消息，提示需要启用 AWS Config 并进行记录，可能还会提供相应步骤。我假设你已经按照准备工作部分中的内容完成了这些步骤。

图 8.11 – 启用 Security Hub 时的启用 AWS Config 消息

1. 在安全标准部分，从可用选项中选择我们要启用的安全标准，如图 8.12所示。在委托管理员部分，我们可以添加一个委托管理员账户来管理该组织的 Security Hub。最后，点击启用Security Hub。

图 8.12 – 在启用 Security Hub 时设置安全标准

我们应该看到一个包含摘要、安全标准、见解等部分的界面。发现的更新可能需要一些时间。所以，在进行后续步骤之前，请稍等片刻。

1. 点击左侧边栏中的安全标准。如果我们是从步骤 2继续操作，针对AWS Foundational Security Best Practices v1.0.0和CIS AWS Foundations Benchmark v1.2.0标准，我们应该能看到查看结果和禁用标准选项。对于未启用的其他标准，我们应该看到启用标准选项。如果我们没有从步骤 2继续操作，我们应该使用启用标准选项启用AWS Foundational Security Best Practices v1.0.0和CIS AWS Foundations Benchmark v1.2.0标准，并稍等片刻，直到看到每个标准的安全得分。

2. 一旦AWS Foundational Security Best Practices v1.0.0的安全得分可用，点击查看结果。我们应该看到安全得分和失败的控制项值，如下所示，但具体细节可能因账户而异。

图 8.13 – 查看安全标准的结果

1. 点击左侧边栏中的见解。我们应该看到一个现有见解的列表，这些是已保存的过滤器，显示相关的发现。我们可以选择其中一个现有的见解，或通过点击创建见解按钮来创建一个新的见解。

图 8.14 – 见解

1. 从左侧边栏点击发现，进入发现页面。在这里，您可以查看来自各种服务集成的发现列表。您可以根据多个标准过滤此列表，例如生成发现的服务或发现的严重性。

图 8.15 – 发现

1. 从左侧边栏点击集成，进入集成页面，在这里我们可以看到当前启用的集成列表以及尚未启用的集成。对于已启用的集成，我们可以在集成页面禁用它们。

图 8.16 – 集成

1. 从左侧边栏点击使用情况，查看估算的使用情况和定价，包括试用期间的使用情况。

2. 从左侧边栏进入配置。

3. 如果未启用中央配置，我们将看到一个链接开始中央配置，并显示以下警告信息：本地配置仅限于新帐户，您对组织的安全设置的访问有限。如需更多配置选项，请切换到中央配置。切换后，配置策略将替代新组织帐户的有限配置设置。我们建议使用中央配置进行帐户管理**。

4. 在配置页面的帐户部分，我们可以添加额外的成员帐户，与此帐户共享其发现。邀请将发送给成员帐户，他们必须接受邀请。

5. 从左侧边栏点击自定义操作，将选定的洞察和发现发送到 Amazon EventBridge。

6. 从左侧边栏点击自动化，根据我们定义的标准更新安全中心发现。

7. 从左侧边栏点击地区，查看多个地区的发现。要开始汇总发现，点击配置发现汇总按钮，设置汇总地区，然后将其他地区链接到该地区，以便统一查看安全发现。

   我们还可以通过点击左侧边栏的常规，然后点击禁用 AWS 安全中心来禁用安全中心。但是，如果适用的费用不是限制因素，始终建议为所有地区启用安全中心。

它是如何工作的……

AWS 安全中心作为 AWS 环境中安全监控和管理的集中平台。要开始使用，请在 AWS 管理控制台中激活该服务。启用后，配置安全中心以从多个 AWS 服务（如 Amazon GuardDuty、AWS Inspector 和 Amazon Macie）收集发现，以及第三方工具和自定义集成。

该服务为安全问题提供持续监控，在统一的仪表板上收集和组织发现。它根据问题的严重性和影响优先排序，帮助用户首先解决最关键的问题。在 Security Hub 控制台中，用户可以调查这些发现，以深入了解潜在的安全威胁和漏洞。此外，Security Hub 还通过与 AWS Lambda 集成支持自动响应，允许用户对检测到的安全问题自动执行修复措施。

总结来说，AWS Security Hub 提供了一个全面的解决方案，用于管理安全态势、合规性和事件响应，从而简化了安全操作并增强了 AWS 环境中的整体保护。

还有更多……

让我们快速浏览一下与 Security Hub 及其相关服务相关的一些重要概念：

• Security Hub 是一个区域性服务。如果成本不是问题，建议在所有区域启用它。

• Security Hub 可以与第三方安全工具集成，如 Alert Logic、Armor、Atlassian Opsgenie 等。

• 我们可以从 发现 页面归档安全发现，以便旧的发现不会出现在页面上。

• CIS 为不同的服务器、应用程序和云提供商提供安全标准。例如，它们为 AWS 安全提供了一套特定的安全标准。

• AWS 的 CIS 基准可以分为四类：身份与访问管理、日志记录、监控和网络。

• IAM 访问分析器使用基于逻辑的推理分析我们 AWS 环境中的基于资源的策略，以告知我们账户中的哪些资源与外部主体共享。

• AWS 防火墙管理器可用于跨账户和应用程序管理防火墙规则。

学习和理解 AWS 的 CIS 安全基准控制，可以在处理 AWS 基础设施时为我们提供更强的安全感。这些控制措施还可以帮助我们在工作中做出更好的决策，甚至在考试时也能有所帮助。

另见

• 了解更多关于 AWS Security Hub 的信息，请访问 www.cloudericks.com/blog/getting-started-with-aws-security-hub。

• 你可以在 docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards.html 查找 Security Hub 支持的 CIS 安全标准列表。

使用 IAM 访问分析器检查未使用的访问权限

在本示例中，我们将展示如何利用 IAM 访问分析器来识别和管理环境中未使用的 IAM 资源。通过重点检测未使用的角色、访问密钥和其他关键组件，确保遵循安全最佳实践。通过配置分析器扫描未使用的资源，并解释其生成的结果，我们可以获得潜在安全风险的有价值见解。通过处理任何识别出的未使用资源，我们降低了未授权访问或滥用的风险，从而增强了 IAM 环境的整体安全性。

准备工作

成功完成此示例所需的条件：

• 一个有效的 AWS 账户和一个用户，如技术要求部分所述。

• 我们需要在 AWS 账户中有一些 IAM 用户和角色；可以通过参考第一章 和 第二章中的示例来创建这些。

如何操作...

我们可以按如下方式使用 IAM 分析器检查未使用的访问权限：

1. 导航到控制台中的IAM服务。

2. 在访问报告下，点击访问分析器。

3. 点击创建分析器。

4. 在分析部分，我们可以看到外部访问分析和未使用的访问分析选项。选择未使用的访问分析选项。

图 8.17 – 配置结果类型

1. 在分析器详情部分，保持自动生成的名称不变。对于信任区，选择当前组织。

2. 向下滚动并点击创建分析器。等待一段时间，直到结果被加载出来。

3. 在左侧边栏点击访问分析器，以查看包含结果摘要的结果概览页面。

4. 点击左侧边栏中的未使用的访问权限。我们应该看到与未使用访问权限相关的结果。

它是如何工作的...

使用 IAM 分析器检查未使用的访问权限，方法是将其作为安全扫描器来检查 IAM 资源。它分析整个环境中的角色、访问密钥和权限。通过检查这些资源最近是否被使用，它能够识别在特定期间内未被激活的元素。这可能表明不必要的访问权限或被遗忘的配置，可能会导致安全漏洞。通过这些见解，你可以加强访问控制并改善 IAM 环境的安全性。

还有更多内容...

尽管识别未使用的资源是一项有价值的功能，但 IAM 分析器还提供了更广泛的功能，帮助增强你的 IAM 安全性。

• 验证权限：IAM 分析器可以根据最佳实践验证策略，并识别可能授予无意访问权限的过度宽松设置。

• 监控外部共享：跟踪与 AWS 账户外部实体共享的资源。这有助于识别与无意访问权限相关的潜在安全风险，可能是外部用户或应用程序的权限。

• 自定义策略检查：定义你自己的安全标准，并利用 IAM 分析器根据这些自定义检查验证 IAM 策略。这使你能够在组织内强制执行特定的安全要求。

• 自动化策略生成：通过利用 IAM 分析器根据 CloudTrail 中的访问活动日志生成 IAM 策略，简化策略创建过程。这有助于确保策略反映实际的使用模式。

• 持续监控：IAM 分析器不是一次性的扫描工具；它提供对你的 IAM 环境的持续监控。这允许你在 IAM 配置变化时主动识别潜在的安全问题。

设置 Amazon EventBridge 来监控我们从 Access Analyzer 获取的结果的步骤总结如下：

1. 转到控制台中的Amazon EventBridge服务。

2. 在左侧边栏的总线下点击规则。

3. 点击创建规则进入创建规则页面。

4. 在定义规则详细信息页面，提供规则的名称和描述。保持事件总线为默认，并将规则类型设置为带有事件模式的规则，然后点击下一步。

5. 在构建事件模式部分，向下滚动至事件模式。

6. 将事件源设置为AWS 服务。

7. 将AWS 服务设置为Access Analyzer。

8. 将事件类型设置为访问分析器查找。

9. 将事件类型规格 1设置为按 ARN 的任何资源。

10. 点击下一步。在目标下，从选择目标的下拉菜单中选择SNS 主题。

11. 选择一个主题。你可以通过参考第七章中的创建 SNS 主题以发送电子邮件食谱来创建 SNS 主题。

12. 点击下一步。

13. 可选，点击添加新标签，然后点击下一步。

14. 审核规则后点击创建规则。

另见

阅读有关确保 IAM 安全的必要工具，详情请见www.cloudericks.com/blog/essential-tools-to-secure-iam。

第九章：高级身份与目录管理

在前几章中，我们已经为IAM 身份中心（前称AWS SSO）、IAM 用户、IAM 组、IAM 角色和 IAM 策略在身份与访问管理方面打下了基础，现在我们将深入探讨用户身份和目录管理的更高级内容。

我们将首先深入探讨在 AWS 中使用Amazon Cognito进行无服务器身份即服务的用户管理策略。本章将重点介绍 Cognito 的两个关键功能：用户池和身份池。用户池充当强大且可扩展的目录，处理用户注册、身份验证和与我们的应用程序集成，并具备多因素身份验证（MFA）和联合身份登录等功能。相反，身份池为经过身份验证的用户分配临时的 AWS 凭证，允许他们使用 AWS 服务，如 Amazon S3、Amazon DynamoDB 和 AWS Lambda。

接下来，我们将深入探讨 AWS 中的目录服务解决方案，包括 AWS Simple AD、AWS Active Directory 和 AD Connect。我们还将研究Microsoft Entra ID（之前称为Azure Active Directory）与 IAM 身份中心的集成，这使得 Entra ID 用户能够轻松访问 AWS 资源。

重要说明

本章的教程可能需要一些额外的知识，包括熟悉 Microsoft 产品（如 Active Directory 和 Microsoft Entra ID），以及本书尚未覆盖的 AWS 服务和功能。本章的教程并非理解和实践本书后续教程的必需内容。因此，如果你在阅读本书时缺乏对所需产品或服务的了解，并且目前不需要这些解决方案，可以仅阅读教程步骤以了解内容，直到需要时再进行实践，并确保你具备所需的先决知识。你也可以通过教程中提供的链接，学习到足够的所需产品和服务知识。

本章包含以下教程：

• 使用 Amazon Cognito 用户池

• 使用身份池访问 AWS 资源

• 使用 AWS Simple AD 创建轻量级目录解决方案

• 在 AWS 中使用 Microsoft Entra ID 作为身份提供者

技术要求

在开始本章的教程之前，我们需要确保具备以下要求和知识：

• 我们需要一个有效的 AWS 账户来完成本章中的食谱。如果我们使用 AWS Organizations，可以使用组织的管理账户，因为本章中将会在 AWS 组织层级配置许多内容。我将使用在第一章的使用 AWS Organizations 进行多账户管理食谱中创建的aws-sec-cookbook-1账户。

• 对于管理操作，我们需要具有AdministratorAccess权限的用户，以访问我们正在使用的 AWS 账户。

本书的代码文件可在 github.com/PacktPublishing/AWS-Security-Cookbook-Second-Edition 获得。本章的代码文件可在 github.com/PacktPublishing/AWS-Security-Cookbook-Second-Edition/tree/main/Chapter09 获得。

与 Amazon Cognito 用户池合作

Amazon Cognito 主要用于两种使用场景：通过其用户池功能为我们的应用程序提供安全的用户身份管理，以及通过其身份池功能利用临时凭证提供对 AWS 资源的安全访问。在本食谱中，我们将通过从 AWS 管理控制台创建用户池并在其中创建用户来探索 Amazon Cognito 的用户池功能。

准备就绪

若要完成此食谱，我们需要 Amazon Simple Notification Service（SNS）以便在我们计划使用 SMS 验证时发送 SMS。

重要提示

当我们开始使用 Amazon SNS 发送 SMS 消息时，我们的 AWS 账户会在 SMS 沙箱中操作。此沙箱作为一个安全空间，允许我们测试 Amazon SNS 功能而不会影响我们的发送者声誉。在沙箱中，我们只能向经过验证的目标电话号码发送 SMS 消息。

如果我们的 AWS 账户位于 SMS 沙箱中，并且我们希望在此食谱中使用 SMS 验证，可以按照以下步骤将电话号码添加到沙箱目标电话号码中：

1. 登录到 AWS 管理控制台并导航到 Amazon SNS 服务。

2. 点击左侧边栏中的文本消息（SMS）。

3. 在账户信息下确认该账户位于 SMS 沙箱中。

4. 在沙箱目标电话号码部分，点击添加电话号码。

5. 在添加电话号码页面，输入电话号码，并选择正确的国家代码。同时，选择验证消息的语言，即将要发送的验证消息语言。

6. 点击添加电话号码。这将带我们进入验证电话号码页面。

7. 在验证电话号码页面，输入收到的验证码并点击验证电话号码。

如果成功验证，手机号码现在应该会显示在短信（SMS）页面的沙箱目标电话号码部分，并且验证状态应显示为已验证。

我们可以通过本食谱中另见部分提供的链接进一步探索 Amazon SNS。假设我们已经按照本节中的讨论设置好环境，现在可以开始创建 Cognito 用户池。

如何操作...

我们可以通过以下方式在 AWS 管理控制台中创建一个 Cognito 用户池：

1. 登录到 AWS 账户管理控制台并导航到 Cognito 服务。我们应该看到根据业务案例开始的选项。默认选项是将用户目录添加到您的应用程序，这是通过用户池完成的。

图 9.1 – 创建用户池业务案例

下拉菜单还包括授予访问 AWS 服务权限选项，适用于使用身份池的业务案例。

1. 选择将用户目录添加到您的应用程序的业务案例，如图 9.1所示，并点击创建用户池。我们也可以通过点击左侧边栏的用户池菜单选项，进入用户池页面来创建用户池。

2. 在提供商类型下，只选择Cognito 用户池（这是默认选项）。在Cognito 用户池登录选项下，选择用户名、电子邮件和电话号码。保持其他选项不变，点击下一步。

图 9.2 – 配置身份验证提供商

1. 在配置安全要求页面，将密码策略模式设置为Cognito 默认（这是默认选项）。

2. 对于多重身份验证，选择需要 MFA - 推荐，然后选择身份验证器应用程序。

图 9.3 – 在用户池创建期间配置 MFA 设置

1. 在用户账户恢复部分，选择启用自助账户恢复 - 推荐。在用户账户恢复消息的传递方式下，选择仅通过电子邮件。然后点击下一步。

图 9.4 – 在用户池创建期间配置用户账户恢复设置

1. 在配置注册体验页面，选择启用自助注册，允许 Cognito 自动发送消息以验证和确认 - 推荐，并选择发送电子邮件消息，验证电子邮件地址。保持其他值不变，点击下一步。

重要提示

启用用户池中的用户注册功能允许来自互联网上任何地方的个人注册账户并登录到我们的应用程序。在我们准备好允许公众注册访问应用程序之前，需要避免启用该功能。我们还可以通过在注册体验页面中集成最多 50 个自定义属性来个性化注册体验。然而，重要的是要注意，一旦用户池建立，这些自定义属性的名称将无法修改。

1. 在配置消息传递页面，选择使用 Cognito 发送电子邮件。

重要提示

我们可以初步使用 Cognito 的默认电子邮件地址进行开发，该地址每天最多支持发送 50 封电子邮件。如果我们已经通过 Amazon SES 建立了一个已验证的发件人，并希望使用其功能，则应选择使用 Amazon SES 发送电子邮件 - 推荐选项，并输入必要的 SES 详细信息。

1. 在短信设置中，提供SecCbCognitoUserPoolRole作为IAM 角色名称。保持其他设置不变，然后点击下一步。

图 9.5 – 用户池创建期间的短信设置

重要提示

如果我们的 AWS 账户当前处于 SMS 沙盒环境中，我们必须将计划用于 SMS 验证的任何电话号码添加并验证到沙盒的已验证目标电话号码列表中，具体内容请参见本食谱中的准备工作部分。如果我们的账户不在沙盒中，我们需要按照 Amazon 在屏幕上提供的说明配置 SMS 消息服务，如图 9.5所示。请注意，设置 SMS 消息服务的详细过程超出了本书的范围。

1. 在集成应用程序页面，选择SecCbUserPool下的用户池名称，然后选择使用 Cognito 托管 UI。在域名部分，选择使用 Cognito 域名并输入一个唯一的域名前缀。

重要提示

我们还可以输入自己拥有的自定义域名，用于 Cognito 托管的注册和登录页面。要使用自定义域名，提供 DNS 记录和来自AWS 证书管理器（ACM）的证书是先决条件。对于生产工作负载，AWS 推荐使用自定义域名，以提升专业性和品牌形象。

1. 在初始应用客户端部分，提供Sec Cb App作为应用客户端名称。在客户端密钥下，选择生成客户端密钥，对于允许的回调 URL，提供一个身份验证后重定向的 URL，例如 www.cloudericks.com。点击下一步。

重要提示

客户端密钥作为应用程序服务器端身份验证 API 请求的一种方式，提供了一层安全性，帮助防止第三方冒充您的客户端。需要注意的是，一旦 Amazon Cognito 为您的应用客户端生成了客户端密钥，便无法修改或删除。

1. 审查所有细节并点击创建用户池。现在我们应该能在用户池页面上看到我们的新用户池。

2. 从用户池页面，点击我们创建的用户池的超链接名称，访问其设置页面。设置页面应包含用户池概览部分以及删除用户池按钮，如下图所示：

图 9.6 – 用户池概览页面

1. 向下滚动并导航到用户选项卡，这是第一个选项卡。

图 9.7 – 用户池的用户选项卡

1. 点击创建用户。

2. 在创建用户页面，选择电子邮件和电话作为用于登录的别名属性。

图 9.8 – 配置用于登录的别名属性

1. 选择不发送邀请作为邀请信息选项。

图 9.9 – 配置邀请信息

1. 提供用户名、电子邮件地址、电话号码和临时密码，然后点击创建用户。

图 9.10 – 新用户配置

新用户应该出现在用户选项卡中，如下图所示：

图 9.11 – 包含新用户的用户选项卡

1. 从用户池的设置页面，导航到应用集成标签并点击初始应用客户端的超链接应用客户端名称，该客户端是在本教程中创建的。现在我们应该能看到我们应用的设置页面。

2. 在应用程序设置页面的托管 UI部分，点击查看托管 UI。现在我们应该能看到默认的托管 UI 登录页面，如下所示：

图 9.12 – 托管 UI 登录页面

1. 输入我们在本教程中创建的用户的用户名和密码，然后点击登录。我们将进入更改密码屏幕。

2. 在更改密码屏幕中，在带有新密码和再次输入新密码标签的复选框下输入新密码，然后点击发送。这将会向创建用户时提供的电话号码发送一个一次性密码（OTP），并要求我们输入该密码以进行验证，如下图所示：

图 9.13 – 短信验证

一旦验证成功，我们将被重定向到配置的 URL。如果您在跟随教程并提供了www.cloudericks.com URL，您应该看到一个类似于以下的页面：

图 9.14 – 登录后页面

在本食谱中，我们创建了一个用户池，并通过 AWS 管理控制台创建了一个用户。或者，用户也可以通过托管 UI 的注册选项自行注册。对于登录和注册体验的自定义，以及配置 用户组、消息传递、应用集成 和 用户池 属性，可以通过用户池的设置页面进入相应的标签页进行操作，如 图 9 .7 所示。

它是如何工作的...

Amazon Cognito 提供了两项主要功能：用户池和身份池。用户池作为安全目录，处理应用用户的注册和登录操作，而身份池则是向认证用户颁发 AWS 凭证的机制，允许访问 AWS 服务。在本食谱中，我们创建了一个用户池。

对于用户池的登录选项，我们选择了 用户名、电子邮件 和 电话号码。我们可以将电子邮件或电话号码作为用户名，并使用它们代替用户名进行登录。为了增强安全性，我们还选择了多因素认证（MFA）并指定了账户恢复机制。为了提供更好的注册体验，我们启用了自助注册，并配置了自动消息验证。

我们使用了 Cognito 域 选项来托管 Cognito 的注册和登录页面，以简化操作。我们也可以使用自己拥有的自定义域。要使用自定义域，必须提供 DNS 记录和来自 ACM 的证书。对于生产工作负载，AWS 推荐使用自定义域，以增强专业性和品牌形象。

在我们的过程中没有设置自定义属性。不过，可以通过引入最多 50 个自定义属性来定制注册体验。一旦用户池建立，必须记住这些自定义属性的名称会变得固定，无法更改。然而，我们可以稍后添加新的属性。

在这个过程中还创建了一个初始的应用客户端，采用了默认设置。Amazon Cognito 客户端应用通过认证用户，并与 Amazon Cognito 交换令牌来获取临时 AWS 凭证。这些临时 AWS 凭证可以用来访问 AWS 资源。

Cognito 中的客户端应用可以分为三类：

• 公共客户端：通常是客户端应用程序，比如移动设备上的原生应用或基于浏览器的应用。在这种情况下，应用程序会从不能被信任存储客户端密钥的设备上发起 API 请求，因为这些设备可能会暴露密钥。

• 机密客户端：通常是服务器端应用程序，能够安全存储客户端密钥。API 请求会通过中央服务器路由，该服务器被认为是安全的，能够保护这些敏感信息。

• 自定义应用：此选项允许进行更为个性化的设置。您可以根据独特的需求和安全考虑，定义特定的授权类型、身份验证流程，以及是否需要客户端密钥。

我们将在下一节中探讨更多细节，包括替代的业务案例。

还有更多内容...

在此方案中，我们通过选择将用户目录添加到您的应用业务案例创建了一个 Amazon Cognito 用户池，如图 9.1所示。我们也可以从下拉菜单中选择授予访问 AWS 服务权限业务案例来创建身份池，如下图所示：

图 9.15 – 创建身份池业务案例

在此方案中，提供者类型下，我们仅选择了 Cognito 用户池（这是默认选项），如图 9.2所示。如该图所示，Cognito 用户池选项默认被选中且无法取消，此外我们还可以选择一个名为联合身份提供者的选项。如果我们选择联合身份提供者选项，将获得额外的登录选项，允许我们使用来自流行社交身份提供者（如 Facebook、Google、Amazon 和 Apple）的凭证，或通过 SAML 或Open ID Connect（OIDC）协议从外部目录获取凭证，如下图所示：

图 9.16 – 用户池的联合登录选项

选择Cognito 用户池选项是强制性的，因为它在我们的用户池中为直接用户和联合用户维护用户档案。然而，如果我们的目标是仅提供联合登录选项，我们可以在用户池中关闭自注册功能，从而强制要求只有管理员才有权限创建用户档案。此外，如果我们希望限制通过用户池进行的登录，可以取消选择用户池作为应用客户端中的身份提供者（IdP）。

我们还可以将 Amazon Cognito 与Amazon Verified Permissions集成，后者是一个精细化的授权服务，旨在强制执行基于角色和属性的访问控制，适用于使用 Amazon Cognito 进行身份验证的应用程序。Verified Permissions 根据用户的身份或访问令牌，评估其属性与特定资源的访问规则，并做出授权决策——要么授权访问，要么拒绝访问。此服务允许将所有应用程序和资源的授权集中到一个策略存储中。策略是用Cedar语言编写的，Cedar 是一种专门设计用于制定访问控制协议的开源语言。

在本配方中，我们通过控制台创建了一个用户池。我们也可以使用 aws cognito-idp create-user-pool CLI 命令创建一个用户池，传递 pool-name 和 region。尽管我们可以直接通过命令行指定所有用户池设置并参考文档，但使用包含所有配置的输入 JSON 文件是一种更简便和安全的方法。

另见

• 我们可以在 www.cloudericks.com/blog/getting-started-with-amazon-cognito 阅读更多关于 Amazon Cognito 的内容。

• 我们可以在 www.cloudericks.com/blog/getting-started-with-amazon-sns-service 阅读更多关于 Amazon SNS 服务的内容。

• 我们可以在 www.cloudericks.com/blog/getting-started-with-amazon-verified-permissions 阅读更多关于 Amazon Verified Permissions 的内容。

• 我们可以在 www.cloudericks.com/blog/integrating-amazon-cognito-with-amazon-verified-permissions 学习如何将 Amazon Cognito 与 Amazon Verified Permissions 集成。

使用身份池访问 AWS 资源

正如本章前面讨论的，Amazon Cognito 有两个主要的使用场景。虽然用户池帮助我们处理应用程序的身份和访问管理，身份池则扩展了这一功能，提供临时的 AWS 凭证，使我们能够安全地访问各种 AWS 服务，而无需长期密钥。在本配方中，我们将深入探讨身份池的使用，以有效地访问 AWS 资源。让我们深入了解身份池领域，利用其能力将身份池融入到我们的应用程序中，确保安全且可扩展地访问 AWS 资源，利用临时 AWS 凭证。

准备工作

为了完成本配方，除了 技术要求 部分提到的要求外，我们还需要确保以下附加要求已经到位：

• 一个 Amazon Cognito 用户池：Amazon Cognito 用户池作为我们身份池的身份骨架。在本章前面的 与 Amazon Cognito 用户池 配方中，我们创建了一个用户池。

• 带有 ALLOW_USER_PASSWORD_AUTH 的应用客户端：我们需要设置一个配置了 ALLOW_USER_PASSWORD_AUTH 流程的应用客户端。可以通过在 AWS 管理控制台中导航到用户池设置，选择 应用集成 标签，并创建一个应用客户端来实现。或者，我们可以在初始应用客户端设置过程中包含身份验证流程，如 与 Amazon Cognito 用户池 配方中所述。

• Amazon S3 存储桶：我们需要一个具有默认选项的 S3 存储桶，正如在第二章的技术要求部分中讨论的那样，用于展示用户池。我将使用一个存储桶名称myawsbucket，位于us-east-1区域。S3 存储桶名称必须是全球唯一的；选择一个可用名称，并将我的存储桶名称替换为你选择的存储桶名称。

接下来，我们将看到如何实现 Cognito 身份池。

如何操作...

我们可以使用身份池有效地访问 AWS 资源，如下所示：

1. 在 AWS 控制台中导航到Amazon Cognito服务，搜索我们创建的 Cognito 用户池。进入用户标签，点击创建用户按钮。

图 9.17 – 创建用户选项

1. 提供用户资料详情：将用户名设置为testuser，将电子邮件地址设置为 testuser@cloudericks.com。对于临时密码，选择设置密码选项，输入一个安全密码，最后点击创建用户。

图 9.18 – 创建用户的详细信息

重要说明

为了避免通过 AWS CLI 认证此用户时遇到 MFA 挑战，我们应该在创建 Cognito 用户池时，在配置安全要求设置中选择无 MFA选项。

1. 在 AWS 管理控制台中，进入AmazonCognito 服务。

2. 点击身份池，然后点击创建身份池。

3. 通过选择已认证访问和Amazon Cognito 用户池，配置身份池中的已认证身份来源。点击下一步进入配置权限页面。

图 9.19 – 配置认证提供者

1. 在配置权限页面，选择创建新 IAM 角色，并通过指定角色名称为已认证用户设置 IAM 角色。我们可以使用MY_IDP_AUTHROLE作为IAM 角色名称。点击下一步。

图 9.20 – 选择已认证角色

1. 输入用户池 ID和应用客户端 ID的值。

图 9.21 – 用户池详情

保留其他值为默认值并点击下一步。

图 9.22 – 访问控制的属性

1. 为身份池命名，并点击下一步完成配置。

图 9.23 – 最终配置页面

1. 在审查并创建页面，审查所有内容并点击创建身份池。

2. 我们应该看到一个提示，说明角色已成功创建；点击 查看角色。

图 9.24 – 成功创建角色后的身份池提示

1. 已认证用户的角色应具有访问 S3 存储桶的权限。确保授予 AmazonS3ReadonlyAccess 操作的访问权限。点击 添加权限 下拉菜单，选择 添加策略。搜索 AmazonS3ReadonlyAccess 策略，选择它并点击 添加权限。

图 9.25 – 权限策略

1. 要在用户池中验证用户，我们可以使用 Amazon Cognito Identity SDK 或直接使用 AWS CLI 的 cognito-idp 命令。为此，进入 AWS CloudShell，并通过提供我们要验证的用户的 <username>、<username>、<client-id> 和 <region> 运行以下命令：

   aws cognito-idp initiate-auth
   --auth-flow USER_PASSWORD_AUTH
    --auth-parameters USERNAME=<username>,PASSWORD=<password>
    --client-id <client-id> --region <region>
   

   我们应该得到一个挑战响应，要求我们提供一个新密码。

图 9.26 – 挑战响应，要求我们提供一个新密码

1. 我们需要通过以下命令响应挑战，给用户设置一个新密码，提供 user-pool-id、user-pool-id、user-pool-id、user-pool-id、session 和 region。其中 session 应该是我们在前一条命令中收到的：

   aws cognito-idp admin-respond-to-auth-challenge
   --user-pool-id <user-pool-id> --client-id <client-id>
    --challenge-name NEW_PASSWORD_REQUIRED --challenge-responses NEW_PASSWORD=<new-password>,USERNAME=<username>
    --session <session> --region <region>
   

   我们应该看到一个界面，显示 RefreshToken 和 IdToken。我们应该看到如下界面，并注意记录 IdToken 的值。

图 9.27 – 密码更改后的响应

1. 要获取 IdentityId，请运行以下命令，提供我们之前创建的身份池的 <identity-pool-id>、<region> 和 <user-pool-id>，以及我们从前一步获得的 <id-token>：

   aws cognito-identity get-id
   --identity-pool-id <identity-pool-id>
   --logins "cognito-idp.<region>.amazonaws.com/<user-pool-id>=<id-token>" --region <region>
   

   我们应该看到一个界面，显示出 IdentityId。

图 9.28 – get-id 命令的响应

1. 使用从前一步骤获得的 IdentityId 来获取临时 AWS 凭证：

   aws cognito-identity get-credentials-for-identity
   --identity-id <identity-id> --logins "cognito-idp.<region>.amazonaws.com/<user-pool-id>=<id-token>"
   --region <region>
   

   此命令将返回临时的 AWS 访问密钥和秘密密钥，以及一个会话令牌。

图 9.29 – get-credentials-for-identity 命令的响应

1. 使用前一步骤中获得的临时凭证配置 AWS CLI。

   aws configure set aws_access_key_id <access-key>
   aws configure set aws_secret_access_key <secret-key>
   aws configure set aws_session_token <session-token>
   

   这些命令不会返回任何响应，如下所示：

图 9.30 – 配置 AWS CLI

1. 我们现在可以使用 AWS CLI，通过 aws s3ls 命令列出我们的 S3 存储桶。

图 9.31 – 对 s3 ls 命令的响应

1. 导航回我们的身份池，然后点击用户统计。我们应该看到我们已经通过身份池成功进行了身份验证。

图 9.32 – 用户统计

在这个示例中，我们使用身份池来访问 AWS 资源。

工作原理...

要使用 Amazon Cognito 用户池作为 IdP 并通过 AWS CLI 列出 S3 存储桶，我们首先创建了一个用户池和其中的一个用户。然后，我们设置了一个身份池，定义了 IAM 角色，并为经过身份验证的用户配置了权限，包括列出 S3 存储桶。

接下来，我们通过 AWS CLI 的cognito-idp命令获取了一个 ID 令牌，启动了身份验证，并从身份池获取了一个 ID。通过获取的 ID，我们检索了临时 AWS 凭证。配置 AWS CLI 后，我们使用它来列出我们的 S3 存储桶。

该过程通过基于身份的身份验证，允许安全且受控制的访问 S3 资源，确保用户被授权在 S3 服务上执行特定操作。

还有更多...

让我们进一步了解一些与 Amazon Cognito 相关的概念，这将有助于我们进一步理解该服务：

• 社交身份提供者：Cognito 用户池和身份池都可以配置为允许用户使用社交身份提供者（如 Facebook、Google 或 Amazon）进行登录。这扩展了我们应用程序的身份验证选项，并为希望使用其现有社交媒体帐户登录的用户提供了无缝的登录体验。

• MFA：我们可以在 Cognito 用户池和身份池中启用 MFA 以增强安全性。使用 MFA，用户需要提供额外的身份验证因子，例如来自移动应用或短信的一次性代码，除了他们的密码。这显著增强了用户身份验证的安全性。

• 自定义身份验证挑战：Cognito 用户池允许我们设置自定义身份验证挑战。这对于需要用户在身份验证过程中完成特定任务或提供额外信息的场景非常有用。我们可以根据应用程序的要求自定义挑战流程。

深入探讨 Amazon Cognito 的每个功能需要一本专著。因此，在本示例和上一示例的“参见”部分提供了额外的链接，以便您进一步探索。

另请参阅

• 我们可以在Amazon Cognito 与联合身份提供者使用了解联合身份提供者的使用方法。

• 阅读更多关于如何使用 AWS Cognito 日志进行安全事件故障排除的内容，访问 www.cloudericks.com/blog/troubleshooting-security-incidents-using-aws-cognito-logs。

使用 AWS Simple AD 创建轻量级目录解决方案

AWS Simple AD，由一个兼容 Samba 4 Active Directory 的服务器提供支持，是由 AWS 提供的轻量级独立托管目录服务，特别适合中小型企业，满足其对目录服务的需求，同时避免了管理本地基础设施的复杂性。该服务有两个选项，Small 选项适用于最多 500 个用户（或大约 2,000 个对象，包括用户、组和计算机）的环境，而 Large 选项适用于最多 5,000 个用户（或大约 20,000 个对象）的环境。

Simple AD 提供了基本服务，如用户帐户管理、组成员管理、组策略应用、Amazon EC2 实例的安全连接以及基于 Kerberos 的 单点登录（SSO）功能。它兼容依赖 Microsoft Active Directory 的多种应用程序和工具，方便用户访问 AWS 应用程序，如 WorkSpaces、Amazon WorkDocs 和 Amazon WorkMail。然而，Simple AD 不支持某些服务，包括 Amazon AppStream 2.0、Amazon Chime 或 Amazon RDS for SQL Server 和 Oracle。

准备工作

为了成功完成此操作，我们需要以下内容：

• 一个有效的 AWS 账户和用户，具体描述见 技术 要求 部分。

• 配置一个至少包含两个子网并跨多个可用区的 VPC，遵循 第五章 中的 Setting up VPC plus VPC resources with minimal effort 配方。

如何操作...

我们将使用以下步骤：

1. 登录到 AWS 管理控制台并进入 Directory Service。我们应该会看到如下屏幕。

图 9.33 – 设置目录屏幕

1. 从下拉菜单中选择 Simple AD，如 图 9.34 所示，然后点击 图 9.33 中显示的 Set up directory 按钮。点击 Next。

图 9.34 – 设置目录的下拉菜单

1. 在 Select directory type 页面，确保选择了 Simple AD，然后点击 Next。

2. 在 Enter directory information 页面，选择 Directory size 下的 Small。对于 Directory DNS name，输入 corp.cloudericks.com，对于 Directory NetBIOS name - optional，输入 CORP。

图 9.35 – 配置 Simple AD

1. 向下滚动并为 管理员密码 提供一个值，并在 确认密码 字段中确认密码。对于 目录描述 - 可选 ，提供 Cloudericks 企业目录 的描述，并点击 下一步。

2. 对于 VPC ，选择至少有两个子网的 VPC，如 准备工作 部分所述。在 子网 下选择两个公共子网并点击 下一步。

3. 在 子网 下，选择域控制器的子网。确保它们位于不同的可用区，并点击 下一步。

4. 在 审核与创建 页面，审核所有详细信息并点击 创建目录 。目录的状态将显示为 创建中，创建完成后会变为 活动。

它是如何工作的…

AWS Simple AD 提供一个托管的与 Active Directory 兼容的目录服务，为用户提供一个简单的解决方案，用于用户身份验证、组管理和域加入操作。用户可以通过 AWS 管理控制台或 CLI 轻松创建 Simple AD 目录，指定域详细信息和规模要求。

创建完成后，Simple AD 支持标准目录功能，如 LDAP 身份验证和基于 Kerberos 的单点登录（SSO），使组织能够高效地管理用户帐户和访问控制。此服务对于寻求成本效益且不想管理复杂基础设施的小型和中型企业尤其有利，它提供了一种简单、无忧的 Active Directory 解决方案。

AWS Simple AD 允许高效的用户和组管理，支持基于 Kerberos 的单点登录（SSO），实现无缝访问多个应用程序，并与各种 AWS 服务（如 Amazon EC2、RDS 和 WorkSpaces）集成。Simple AD 还支持 LDAP，使其适用于需要目录服务进行身份验证和信息检索的应用程序。

还有更多…

以下是我们使用 AWS Simple AD 的不同方式：

• 用户和组管理 ：Simple AD 允许高效管理用户和组。您可以创建、修改和删除用户帐户，并将其组织到组中，便于访问控制和权限管理。

• SSO ：Simple AD 支持基于 Kerberos 的单点登录（SSO），使用户可以一次登录，便能访问多个应用程序和服务，无需重新输入凭证。

• 轻量级目录访问协议（LDAP）：Simple AD 支持 LDAP，允许需要目录服务的应用程序进行身份验证并从目录中检索信息。

• 与 AWS 服务的集成 ：Simple AD 与多种 AWS 服务无缝集成，使您能够管理 AWS 环境中资源的访问和权限。

• Amazon EC2 ：使用域凭证管理对 EC2 实例的访问。

• Amazon RDS ：与 RDS 实例集成进行数据库身份验证。

• Amazon WorkSpaces ：使用 Simple AD 管理用户对虚拟桌面的访问。

• 具成本效益的目录服务：Simple AD 为需要基本目录服务但不需要完整 Active Directory 设置的小到中型企业提供了一种成本效益高的解决方案。

在本食谱中，我们探讨了 Simple AD，这是一种适用于中小型企业的具有成本效益且简单的目录服务。AWS 还支持其他目录解决方案，包括AWS 托管 Microsoft AD，提供完全托管的 Active Directory 服务；AD 连接器，作为将目录请求重定向到本地 AD 的网关；Amazon Cognito 用户池，为 Web 和移动应用提供用户注册和登录功能；以及Amazon Cloud Directory，用于管理分层数据关系的可扩展目录。

另请参见

• 了解更多关于 Simple AD 的信息，访问www.cloudericks.com/blog/getting-started-with-aws-simple-ad。

• 阅读有关 AWS 中的不同目录解决方案，如 AWS 托管 Microsoft AD、Simple AD、AD 连接器、Amazon Cognito 用户池和 Amazon Cloud Directory 的详细信息，访问www.cloudericks.com/blog/exploring-aws-directory-solutions。

在 AWS 中使用 Microsoft Entra ID 作为身份提供者

在当今的技术环境中，许多组织采用多云策略，利用不同的公共云（如 AWS 和 Azure）来部署应用程序。这些组织中的一种常见做法是使用 Microsoft Entra ID 来管理用户身份。AWS IAM 身份中心提供了一种简便的方法，将我们的 AWS 账户与 Microsoft Entra ID 连接。这种集成带来了两个显著的好处：身份管理的集中化和用户体验的增强。

将身份管理集中到一个位置简化了 IT 团队的责任，并加强了安全协议。此外，它还免除了用户处理多个登录凭证的麻烦，简化了登录过程，减少了 IT 支持的需求。在本食谱中，我们将深入探讨将 Microsoft Entra ID 与 AWS IAM 身份中心集成，使用 Microsoft Entra ID 作为身份提供者（IdP）。最后，我们将通过演示如何使用 Entra ID 用户来管理 S3 桶作为 AWS 资源来完成此设置。

准备工作

为完成本食谱，除了技术要求部分中提到的内容之外，我们还需要确保以下附加要求得到满足：

• 拥有一个已设置 AWS IAM 身份中心的 AWS 账户是至关重要的。有关如何设置 IAM 身份中心的指导，请参考第一章的相关内容。

• 还必须拥有一个活动的 Microsoft Entra ID 租户。

• 在 Microsoft Entra ID 租户中拥有一个管理员用户是执行本食谱中的配置步骤的必要条件。

• 需要一个演示用户，包含名字、姓氏、显示名称和用户主体名称的属性数据，用于测试配置。我们将此演示用户命名为demouser1。

重要提示

为了通过 Azure 中的 AWS SSO 企业应用程序成功将用户集成到 AWS IAM 身份中心中，用户需要提供以下属性的值：名字、姓氏、显示名称和用户主体名称。如果缺少这些属性，配置过程可能会遇到错误，从而妨碍用户平稳、安全地过渡到 AWS 环境。

接下来，我们将展示如何在 AWS 中使用 Microsoft Entra ID 作为 IdP。

如何操作…

我们首先从 AWS 下载元数据文件，配置 Microsoft Azure 以通过该元数据文件进行 IAM 身份中心集成，然后继续在 AWS 中设置 AWS IAM 身份中心。之后，我们将返回 Azure 完成配置，最后在 AWS 中验证用户。

从 AWS 下载元数据文件

1. 登录具有管理 IAM 身份中心权限的 AWS 账户管理控制台，并进入 IAM 身份中心服务。

2. 点击左侧边栏中的设置。

3. 在设置页面，找到身份源部分，点击操作下拉菜单，选择更改身份源。

4. 在更改身份源页面，选择外部身份提供者，然后点击下一步。

重要提示

在更改身份源页面，目前有三个选项：身份中心目录、活动目录和外部身份提供者。如果选择身份中心目录选项，则允许在 IAM 身份中心中管理用户和组，用户通过 AWS 访问门户登录。活动目录选项用于管理 AWS 托管的 Microsoft AD 中的用户和组。我们还可以灵活地使用 AWS 托管的 Microsoft AD 或 AD Connector 将 IAM 身份中心连接到现有的活动目录。在这种情况下，用户也通过 AWS 访问门户登录。第三个选项外部身份提供者，适用于通过外部 IdP（如 Microsoft Entra ID）管理用户和组。在这里，用户首先登录到 IdP 的登录页面，正如我们在本食谱中所看到的，然后被重定向到 AWS 访问门户，在那里他们可以访问自己的 AWS 账户和云应用程序。

点击下一步后，我们应该看到配置外部身份提供者页面，页面内容大致如下：

图 9.36 – 配置外部身份提供者页面

1. 在配置外部身份提供者页面中，在服务提供者元数据部分，点击下载元数据文件并将其保存在计算机上。此文件将在配置外部 IdP（例如 Microsoft Entra ID）时使用。

我们从 IAM 身份中心下载的元数据文件包含 IAM 身份中心证书及其元数据详细信息，这对于我们的 IdP（本例中是 Microsoft Entra ID）与 IAM 身份中心建立信任关系是必要的。作为替代，我们也可以直接从网页上复制这些信息并手动输入到 IdP 的服务提供者配置部分。

配置 Microsoft Azure 以进行 IAM 身份中心集成

我们可以按照以下步骤配置 Microsoft Azure 以进行 IAM 身份中心集成：

1. 使用具有应用管理员角色或更高权限角色的用户登录到 Microsoft Azure 门户。

2. 导航至Microsoft Entra ID，并从左侧边栏点击企业应用。

3. 点击新建应用，在浏览 Microsoft Entra Gallery页面中，搜索AWS IAM身份中心。

4. 输入应用名称并点击创建。

5. 在应用成功创建后，打开该应用。

6. 从左侧边栏点击单点登录并选择SAML作为 SSO 方法。

7. 点击上传元数据文件，在上传元数据文件面板中，点击文件夹图标，选择我们在前一节步骤 5中下载的元数据文件。然后点击添加。

8. 在基础 SAML配置面板中点击保存。

9. 向下滚动到页面的SAML 证书部分并下载联合元数据XML 文件。

现在，我们可以返回 AWS 管理控制台的配置外部身份提供者页面，继续执行所需的步骤。有关 Azure 端步骤的详细操作步骤和截图，请参见本食谱中的另见部分。

继续进行 AWS IAM 身份中心设置

我们可以继续在 AWS 管理控制台中执行所需的 AWS IAM 身份中心步骤：

1. 返回到配置外部身份提供者页面，如我们在从 AWS 下载元数据文件部分所做的那样。

2. 在身份提供者元数据部分，点击选择文件，上传我们在配置 Microsoft Azure 以进行 IAM 身份中心集成部分下载的文件。

图 9.37 – 上传身份提供者元数据

1. 向下滚动并点击下一步。

2. 向下滚动，在审查并确认部分，输入ACCEPT，如以下图所示，然后点击更改身份源。

图 9.38 – 审查并确认身份源更改

1. 在设置页面中，我们现在应该看到启用自动配置的消息，并有一个启用按钮。点击启用。

2. 一旦启用了配置，我们应该看到我们的身份源的SCIM 端点和访问令牌值，如下图所示。保存这些信息。

图 9.39 – 访问令牌

现在让我们返回 Azure 门户，继续进行配置。

继续在 Microsoft Azure 中进行配置

现在让我们进入我们在配置 Microsoft Azure 与 IAM 身份中心集成部分中创建的 AWS IAM 身份中心企业应用，继续设置：

1. 在左侧边栏的管理部分，点击配置，并将配置模式设置为自动。

2. 在管理员凭证部分，输入我们在前一节第 6 步中保存的 AWS 身份中心 SCIM 端点，在租户 URL下输入，并在秘密令牌下输入访问令牌。

3. 点击测试连接，如果成功，点击保存，然后在配置下点击保存。

4. 在配置标签页上，点击开始配置。

5. 在左侧边栏的管理部分，点击用户和组，然后在右侧面板中点击添加用户/组。

6. 选择我们为演示创建的demouser1用户并点击分配。

一旦配置成功，我们可以返回 AWS IAM 身份中心验证用户配置。用户在 AWS 中出现可能需要一些时间，通常大约需要 30 分钟。关于在 Azure 侧完成步骤的详细步骤和截图可以在本食谱的另见部分找到。

在 AWS IAM 身份中心验证用户

我们可以通过以下方式验证在 AWS IAM 身份中心的自动用户配置：

1. 返回到 IAM 身份中心仪表板。

2. 从左侧边栏点击用户。我们应该能在 AWS 身份中心中看到demouser1用户。现在我们可以使用该用户的 Microsoft Entra ID 凭据登录 AWS 身份中心。

图 9.40 – Azure 用户在 AWS 中

1. 点击设置并复制 AWS 访问门户 URL。

2. 将这个 URL 粘贴到另一个浏览器中。我们应该会看到一个提示，要求使用 Microsoft Entra ID 凭据登录。输入用户的主体名称和密码。

图 9.41 – 以 Microsoft 用户身份登录

在输入用户的主体名称和密码后，我们应该会被重定向到 AWS 账户，并作为已登录用户进入。

图 9.42 – Azure 用户在 AWS 账户中的凭证

在本教程中，我们使用 Microsoft Entra ID 作为 IdP，并使用 Microsoft Entra ID 凭据登录到 AWS 账户。接下来，我们需要使用 权限集 为该用户提供必要的权限和访问权限。我们还可以按照本教程中所做的类似方法，使用其他受支持的 IdP，而不仅仅是 Microsoft Entra ID。

它是如何工作的……

AWS Identity Center 和 Azure Entra ID 之间的单点登录（SSO）使用户能够使用其 Azure AD 凭据登录 AWS Identity Center。这带来许多好处，包括提高安全性和用户便利性、减少管理开销以及改善合规性。

AWS Identity Center 和 Azure Entra ID 之间的单点登录（SSO）通过从 Azure AD 生成 SAML 断言并将其发送到 AWS Identity Center 来实现。然后，AWS Identity Center 验证 SAML 断言并为用户创建会话，使他们能够无需再次输入凭据即可访问 AWS Identity Center 应用程序。

当将用户从 Azure 配置到 AWS IAM Identity Center 时，至关重要的是将他们无缝集成到 AWS 中，就像他们是本地 AWS 用户一样。这涉及将他们分配到特定的 AWS 账户，并授予与他们在组织中各自角色相符的权限集。

还有更多……

让我们探索一些与将 IAM Identity Center 与 Microsoft Entra ID 集成相关的重要概念：

• 用户预配：这是在应用程序或系统中自动创建和管理用户帐户的过程。在 AWS IAM Identity Center 和 Microsoft Entra ID 之间的 SSO 上下文中，用户预配使我们能够为已经在 Microsoft Entra ID 中的用户自动创建 AWS Identity Center 用户帐户。这可以通过减少未经授权访问我们应用程序和资源的风险来提高安全性，还可以通过释放 IT 员工专注于其他任务来减少管理开销。

• 组同步：这是在两个系统之间保持用户组同步的过程。在 IAM Identity Center 和 Microsoft Entra ID 之间的 SSO 上下文中，组同步使我们能够在 Microsoft Entra ID 和 IAM Identity Center 之间保持用户组同步。这确保了用户始终在两个系统中被分配到正确的组，这可以通过确保他们始终能够访问所需的应用程序和资源来改善用户体验。

• 属性映射：这是在两个系统之间映射用户属性的过程。在 AWS Identity Center 和 Microsoft Entra ID 之间的 SSO 上下文中，属性映射使我们能够在 Microsoft Entra ID 和 IAM Identity Center 之间映射用户属性。这一点非常重要，因为 IAM Identity Center 使用用户属性做出授权决策，因此通过映射正确的属性，我们可以确保用户始终被授予正确的访问权限。

让我们现在查看一些额外的参考资料，帮助我们进一步探索将 IAM Identity Center 与 Microsoft Entra ID 集成，特别是关于 Azure 端的变更。

另见

• 我们可以通过www.cloudericks.com/blog/understanding-automatic-provisioning-with-aws-iam-identity-center深入了解 AWS IAM Identity Center 中的自动化配置功能。

• 包含在 Azure 端需要进行的配置的详细步骤和说明超出了本书的范围。我们可以通过www.cloudericks.com/blog/understanding-microsoft-entra-sso-integration-with-iam-identity-center了解更多关于 Microsoft Entra SSO 与 AWS IAM Identity Center 的集成信息。

第十章：AWS 安全的附加服务和实践

在本书中，我们已经探讨了许多与安全相关的概念和服务。还有更多安全服务和实践可以帮助我们保护 AWS 基础设施的安全。在本章中，我们将探讨一些值得关注的额外服务和实践。与其他章节不同，我们不会对这些服务进行深入探讨。你可以参考另见部分提供的链接，进一步学习。我们将了解一些与安全相关的托管服务，如AWS 资源访问管理器（AWS RAM）、AWS Systems Manager 参数存储、AWS Secrets Manager、AWS Trusted Advisor和AWS Artifact。我们还将了解如何使用Amazon 机器镜像（AMIs）和来自 AWS Marketplace 的安全产品。

在本章中，我们将涵盖以下配方：

• 设置和使用 AWS RAM

• 使用 Systems Manager 参数存储存储敏感数据

• 使用 AWS Secrets Manager 管理 RDS 凭证

• 创建 AMI 而不是使用 EC2 用户数据

• 使用来自 AWS Marketplace 的安全产品

• 使用 AWS Trusted Advisor 获取建议

• 使用 AWS Artifact 进行合规性报告

技术要求

在深入了解本章的配方之前，我们需要确保已满足以下要求：

• 完成本章中的配方，至少需要一个有效的 AWS 账户。除非配方中特别提到，否则我将使用在第一章中的多账户管理与 AWS Organizations配方中创建的awsseccb-sandbox-1账户，并且不会使用任何 AWS Organizations 功能。

• 对于管理操作，我们需要一个具有AdministratorAccess权限的用户来访问我们正在使用的 AWS 账户。

本书的代码文件可以在github.com/PacktPublishing/AWS-Security-Cookbook-Second-Edition上找到。本章的代码文件可以在github.com/PacktPublishing/AWS-Security-Cookbook-Second-Edition/tree/main/Chapter10上找到。

设置和使用 AWS RAM

AWS RAM 使我们能够与其他 AWS 账户或 AWS 组织内部的其他账户安全地共享 AWS 资源。我们可以共享的资源包括传输网关、子网、AWS License Manager 配置和 Amazon Route 53 解析器规则。在这个配方中，我们将学习如何使用 AWS RAM 来共享子网。

准备工作

我们需要以下内容才能成功完成配方：

• 设置为管理账户并已按照在第一章中的多账户管理与 AWS Organizations配方中讨论的方式配置的 AWS Organizations。我将使用在该配方中创建的aws-sec-cookbook-1账户。

• 在组织内的成员帐户以共享资源。

• 通过遵循第五章中的设置 VPC 及其 VPC 资源的最小化步骤食谱创建 VPC 和子网，然而，您可以跳过创建 NAT 网关。

如何操作...

我们可以按如下方式设置和使用 AWS RAM：

1. 转到 AWS 管理控制台中的资源访问管理器服务。如果我们是第一次使用该服务，请点击左侧边栏中的设置，选择启用与 AWS Organizations 的共享选项，点击保存设置，然后返回到资源访问管理器仪表板。

图 10.1 – 启用与 AWS Organizations 的共享

1. 点击创建一个资源共享。

2. 对于资源共享名称，提供my-subnet-share值。

3. 在资源 - 可选部分，在选择资源类型的下拉菜单中，选择子网，然后从子网列表中选择我们为本食谱创建的子网，正如在准备部分所讨论的那样。

4. 向下滚动并点击下一步。我们将进入关联托管权限页面。保持默认设置，向下滚动并点击下一步。

5. 在授予访问权限给主体页面的主体部分，选择仅在您的组织内共享，在选择主体类型下，选择AWS 帐户，输入另一个 AWS 帐户的帐户号，点击添加，向下滚动并点击下一步。这将跳转到审核和创建页面。审核详细信息，向下滚动并点击创建资源共享。

6. 要验证资源共享，登录到我们在步骤 6中指定的帐户，然后进入 AWS 资源访问管理器仪表板。在左侧边栏中点击共享给我的资源下的资源共享。

图 10.2 – 我们成员帐户中的共享资源

我们应该能看到被共享的子网。我们需要选择与我们创建共享时相同的区域，以查看这些共享。

它是如何工作的...

首先，我们在我们的 AWS 组织中启用了共享。这可以通过AWS RAM控制台完成，正如我们在本食谱中看到的那样。如果我们没有在 AWS 组织内启用共享，我们添加的帐户将被视为外部帐户，即使它们是我们组织的一部分。我们为一个子网添加了资源共享，并将其与我们组织单元（OU）内的另一个帐户共享。

还有更多...

我们与 AWS RAM 共享了一个子网资源类型。目前可用的资源类型选项包括：Aurora 数据库集群、容量预留、CodeBuild 项目、CodeBuild 报告组、专用主机、映像构建组件、映像构建镜像食谱、映像构建镜像、许可证配置、解析器规则、流量镜像目标、传输网关等。

另见

你可以在www.cloudericks.com/blog/getting-started-with-aws-ram阅读有关 AWS RAM 的更多信息。

使用 AWS 系统管理器参数存储存储敏感数据

我们可以使用系统管理器参数存储存储数据，可以选择加密或不加密，然后从各种服务中引用它，而无需在任何地方硬编码数据。在本操作中，我们将学习如何在 AWS 系统管理器参数存储中加密存储数据，然后从 EC2 实例中检索它。

准备就绪

我们需要以下内容才能成功完成本操作：

• 一个有效的 AWS 账户和在技术要求部分描述的用户。

• 在默认 VPC 中的 EC2 实例，位于 VPC 内的公共子网中。对于Amazon 机器映像（AMI），选择Amazon Linux 2023 AMI；对于实例类型，选择t2.micro；对于密钥对（登录），选择你有权限访问的现有密钥对或创建一个新密钥对。在网络设置下，确保自动分配公有 IP的值为启用，并选择创建安全组，将允许来自设置为任何地方的 SSH 流量。我们在第五章中学习了 EC2。

• 你将受益于熟悉 KMS。在第三章中，我们学习了 KMS。

如何操作...

首先，我们将在 AWS 系统管理器参数存储中创建一个参数。然后，我们将附加一个角色，用于从 EC2 实例访问 AWS 系统管理器。最后，我们将从该 EC2 实例检索参数信息。

在 AWS 系统管理器参数存储中创建参数

我们可以按照以下方式创建一个系统管理器参数存储参数：

1. 进入 AWS 管理控制台中的系统管理器服务。

2. 从左侧边栏点击参数存储。

3. 点击创建参数。

4. 在创建参数页面，填写名称为MySecureParameter，描述（可选）填写My Secure Parameter，并选择层级为标准。

5. 对于类型，选择SecureString；对于KMS 密钥源，选择我的当前账户；对于KMS 密钥 ID，保持默认值alias/aws/ssm不变；对于值，输入MySecureValue。

6. 向下滚动并点击创建参数。我们应该会看到如下信息：创建参数请求成功！

接下来，我们将创建并将角色附加到我们的 EC2 实例，以便访问 AWS Systems Manager。

创建并附加角色以使用 AWS Systems Manager

要从 EC2 实例使用 AWS Systems Manager，我们需要将角色附加到 EC2 实例，如下所示：

1. 转到 AWS 管理控制台中的IAM仪表板。

2. 从左侧边栏点击角色，然后点击创建角色。

3. 在受信实体类型下，选择AWS 服务，然后从服务列表中选择EC2，作为服务或使用案例。

4. 向下滚动并选择EC2 角色用于 AWS Systems Manager。点击下一步。

图 10.3 – 选择受信实体

1. 在添加权限面板上，点击下一步。

2. 在名称、审核并创建页面中，输入角色名称为MySSMManInstanceRole，描述为Amazon SSM 管理实例核心角色。审核整个页面，然后点击创建角色。我们应该会看到角色创建成功的消息。

3. 如同在《第二章》的通过 IAM 角色在 EC2 实例上进行跨服务访问一节中看到的那样，将此角色附加到我们的 EC2 实例。

从 AWS Systems Manager 参数存储中检索参数

我们可以从 EC2 实例中检索参数值。SSH 进入 EC2 实例并运行以下命令：

 aws ssm get-parameters --names MySecureParameter --with-decryption --region us-east-1

我们应该会收到类似以下的响应：

图 10.4 – 获取参数

参数值将被解密。我们还有一个get-parameter子命令，用于aws ssm CLI 命令；但是，当前AWS 提供的 AmazonEC2RoleForEC2角色不包括它。你可以手动添加权限，然后使用get-parameter。

它是如何工作的...

在本节中，我们在 AWS Systems Manager 参数存储中创建了一个参数并检索了它。我们可以从任何服务中使用该参数，而无需硬编码其值。现在，我们可以从一个地方更新该参数的值。

为了检索和解密加密的参数值，我们使用了get-parameters子命令，该命令是aws ssm CLI 命令的一部分，并带有--with-decryption选项。如果未指定，则默认选项为--no-with-decryption，并且不会解密值。

我们还可以通过将类型设置为String而不是Secure String来创建不加密的参数。

还有更多...

在本节中，我们只使用了 AWS Systems Manager 的一个功能，即参数存储。让我们快速浏览一下 AWS Systems Manager 的其他一些重要功能：

• AWS Systems Manager 允许我们将 EC2 实例、S3 存储桶和关系数据库服务（RDS）实例等资源进行分组。完成此操作后，我们可以执行一些操作，例如在一组资源中安装补丁。

• 我们可以在 AWS 系统管理器参数存储中使用该参数，来自不同的服务，如 EC2、Lambda 和 CloudFormation。我们也可以在系统管理器的run命令中使用该参数。

• run命令可用于在一组 EC2 机器上自动执行管理任务和配置更改。

• 简单的系统管理器 EC2 角色允许我们从 EC2 实例上使用run命令。

• 我们可以手动指定 EC2 目标实例或基于附加到 EC2 实例的标签来指定目标实例。

• 当我们从控制台配置run命令时，AWS 会为我们提供相应的 CLI 命令，我们可以执行。

• 要使用run命令，需要在实例上安装 SSM 代理。

• 我们还可以使用run命令对本地系统执行操作。

另见

• 你可以在www.cloudericks.com/blog/getting-started-with-aws-systems-manager-ssm上阅读更多关于 AWS 系统管理器的信息。

• 你可以在www.cloudericks.com/blog/using-aws-kms-with-aws-ssm-parameter-store上阅读更多关于将 KMS 与 AWS 系统管理器参数存储结合使用的信息。

使用 AWS Secrets Manager 管理 RDS 凭证

在本食谱中，我们将学习如何使用 AWS Secrets Manager 管理 RDS 凭证。这是一种更安全的方式来管理和轮换 RDS 凭证，而不是手动操作。

准备工作

我们需要以下内容才能成功完成本食谱：

• 一个有效的 AWS 账户和如技术要求部分所述的用户。

• 在 RDS 中创建的 RDS 数据库实例，采用默认设置，但有以下例外：

  • 对于实例配置，选择无服务器 v2以保持最低成本。

  • 对于凭证设置，请提供主用户名和主密码的值，如下图所示：

图 10.5 – RDS 数据库的凭证设置

重要提示

如果我们在图 10 5中选择了在 AWS Secrets Manager 中管理选项，那么 RDS 将生成一个密码并将其存储在 Secrets Manager 中，而无需执行本食谱中列出的步骤。然而，我们希望演示如何手动存储密钥，因此选择了自主管理选项。

如何操作……

我们可以按如下方式配置 AWS Secrets Manager 来管理 RDS 数据库的凭证：

1. 进入 AWS 管理控制台中的Secrets Manager服务。

2. 在左侧边栏，点击Secrets。在Secrets页面，点击存储新密钥。

3. 对于密钥类型，选择Amazon RDS 数据库的凭证，如下图所示：

图 10.6 – 在 AWS Secrets Manager 中选择秘密类型选项

1. 将 主用户名 和 主密码 的值分别提供给 用户名 和 密码 字段。

2. 对于 加密密钥 选项，从下拉菜单中选择默认的加密密钥。我们也可以按照 第三章 中的食谱创建一个 KMS 加密密钥并使用它，但在此食谱中，我们将使用默认密钥。

3. 在 数据库 部分，选择我们在 准备阶段 创建的数据库并点击 下一步。

4. 提供 prod/CloudericksApp/Postgres 作为 秘密名称 字段的值，并提供 Cloudericks 应用程序的 Postgress 生产数据库访问权限 作为 描述 字段的值。可选地，添加任何标签，然后点击 下一步。

5. 对于 配置自动轮换，启用 自动轮换。然后，选择 计划表达式生成器 作为 轮换计划，将 时间单位 设置为 天，并将 天数 设置为 30。对于 窗口持续时间 - 可选，保持默认选项，并选中 在秘密存储时立即轮换。下一次轮换将在您的计划 上开始。

图 10.7 – 配置自动轮换

1. 在 轮换函数 部分，选择 创建轮换函数。对于 Lambda 轮换函数，提供 postgres-rotation-lambda 名称。选择 单用户 作为 轮换策略，然后点击 下一步。

图 10.8 – 配置轮换函数

1. 在 审查 页面，仔细检查所有详细信息。此外，还提供了不同语言的示例代码，包括 Java、JavaScript、C#、Python3、Ruby、Go 和 Rust，演示如何从我们的应用程序中检索秘密，如 图 10 .9 所示。最后，点击 存储。

图 10.9 – 从 Secrets Manager 检索秘密的示例代码

1. 一旦收到成功消息，转到新秘密以验证详细信息。

2. 向下滚动并转到 概述 标签页，然后点击 检索秘密值 以查看我们的秘密。如果你想编辑它们，可以使用 编辑 按钮进行修改。

   如果我们想删除一个秘密，可以进入该秘密，点击 操作 下拉菜单，然后点击 删除秘密。我们必须指定一个等待期，时间为 7 到 30 天之间，才能删除该秘密。

它是如何工作的...

在这个食谱中，我们将我们的 RDS 数据库凭证存储在 Secrets Manager 中。对于秘密类型，我们选择了 Amazon RDS 数据库凭证。以下是当前在控制台中可用的其他秘密类型选项：Redshift 集群凭证、DocumentDB 数据库凭证、其他数据库凭证 和 其他类型的秘密（例如，API 密钥）。

我们启用了 30 天的自动密钥轮换。我们还可以选择 60 天或 90 天，或提供最多 365 天的自定义周期。我为此配方选择了默认加密密钥。您也可以使用您创建的 KMS 密钥。我们在第三章中学习了有关 KMS 密钥的知识。

配置秘密后，我们的应用程序可以通过 Secrets Manager 进行 API 调用，以编程方式检索秘密。在存储秘密时，AWS 为我们提供了用于不同语言的示例代码以检索秘密。目前，Java、JavaScript、C＃、Python3、Ruby、Go 和 Rust 均有示例代码。

我们看到警告称，此秘密存储后会立即进行第一次轮换。因此，如果我们的任何应用程序仍在使用硬编码凭据，并且未更新为使用 API 获取最新凭据，则这些应用程序将失败。

还有更多内容...

AWS Secrets Manager 可能看起来像 AWS Systems Manager 参数存储。让我们快速比较 Secrets Manager 和参数存储：

• Secrets Manager 主要用于存储数据库凭据、API 密钥和 SSH 密钥。参数存储主要用于存储许可证代码、配置数据、用户定义的参数和数据库字符串，并且较少用于密码。

• AWS Secrets Manager 按秘密每月和每次 API 调用收费。AWS Systems Manager 参数存储不收取标准参数的费用，但根据存储的高级参数数量和每次 API 交互收费高级参数。

• Secrets Manager 具有与 RDS 数据库的内置集成。Secrets Manager 支持对 RDS 进行秘密的内置轮换。它还支持使用自定义 Lambda 函数对非 RDS 数据库进行轮换。

• 参数存储已与 AWS Systems Manager 集成。

另请参阅

在www.cloudericks.com/blog/comparing-aws-secrets-manager-and-parameter-store中阅读有关 AWS Secrets Manager 和 Parameter Store 的比较。

创建 AMI 而不使用 EC2 用户数据

在此配方中，我们将创建一个带有 Web 服务器的 AMI，然后从该 AMI 启动实例。从 AMI 创建的实例比通过 EC2 用户数据定义相同配置的实例具有更快的启动时间。在第五章的使用用户数据启动带 Web 服务器的 EC2 实例配方中，我们使用 EC2 用户数据更新了操作系统并在启动时设置了简单的 Web 服务器。

准备工作

我们需要以下内容才能成功完成该配方：

• 按技术要求部分描述的工作 AWS 帐户和用户。

• 根据第五章中的使用用户数据启动带 Web 服务器的 EC2 实例配方启动的 EC2 实例。

如何做...

我们可以从 EC2 实例创建 AMI 如下：

1. 进入控制台中的EC2 服务。

2. 点击实例，选择我们的实例，点击操作，展开镜像和模板，然后点击创建镜像。

3. 在创建镜像屏幕上，提供镜像名称和镜像描述 - 可选。对于其他参数使用默认值，然后点击创建镜像。

4. 如果我们进入 AMI 列表，我们的 AMI 应该显示其初始状态为待处理。一旦状态变为可用，就可以从这个 AMI 创建一个新实例。在启动实例时，从我的AMI 标签中选择我们的 AMI。

它是如何工作的...

在这个食谱中，我们从一个 EC2 实例创建了一个 AMI。与启动实例相关的信息，包括任何特定于组织的配置，都可以保存到 AMI 中。我们在这个食谱中使用了 Amazon Linux 2023 作为基础 AMI，因此使用了特定于 Amazon Linux 2023 的命令。如果你使用的是 Amazon Linux 2，也可以使用相同的命令。

我们在第五章 中使用 EC2 用户数据做了类似的配置。来自 AMI 的实例比通过 EC2 用户数据定义的具有相同配置的实例具有更快的启动时间。这是因为我们可以在 AMI 中预安装软件包，而在启动时使用用户数据时需要安装它们。

还有更多...

让我们快速浏览一些与 AMI 相关的重要概念：

• 可以从一个 AMI 启动多个 EC2 实例。

• AMI 是特定于某一地区的，但我们可以跨区域复制它们。在启动实例时，我们可以在 Amazon 提供的 AMI、我们自己的 AMI、AWS Marketplace AMI 和社区 AMI 之间进行选择。我们还可以根据其他参数筛选列表。

• 我们只应使用我们信任的公共 AMI。在使用 AMI 之前，我们可以检查其评分。

• AMI 存储在 S3 中。因此，我们将根据 S3 定价收费，这也取决于我们的免费使用配额和使用情况。不过，我们将无法从 S3 控制台查看 AMI 或其存储桶。

• 默认情况下，AMI 对我们的账户和区域是私有的。我们可以将 AMI 设置为公共，供其他 AWS 账户使用，或通过 AWS Marketplace 销售它们。

另请参阅

• 你可以在 www.cloudericks.com/blog/getting-started-with-amis-for-ec2-instances-in-aws 阅读更多关于 AMI 的内容。

• 阅读更多关于 AMI 加固的内容，请访问 www.cloudericks.com/blog/ami-hardening-for-ensuring-security-and-stability-in-our-aws-environment。

使用来自 AWS Marketplace 的安全产品

在这个教程中，我们将学习如何使用 AWS Marketplace 中的各种安全产品。许多第三方公司会在 EC2 实例上安装和配置他们的产品和解决方案，并将它们作为 AMI 在 AWS Marketplace 上提供。Marketplace AMIs 可以被视为预先配置软件的 EC2 实例。或者，我们也可以直接从这些供应商那里购买产品，并自行进行配置。

准备就绪...

我们需要一个可用的 AWS 账户，以及在技术 要求部分中描述的用户。

如何做...

我们可以按照以下步骤找到并使用 AWS Marketplace 中与安全相关的 AMI：

1. 转到仪表板上的EC2服务。

2. 从左侧边栏点击实例，然后点击启动实例。

3. 在应用程序和操作系统镜像（Amazon Machine Image）下，点击浏览更多 AMI。

图 10.10 – 从 AWS Marketplace 浏览 AMIS

1. 转到AWS Marketplace AMIs选项卡，在搜索栏中搜索安全。截至本文撰写时，有 10719 个 AMI 可用。

图 10.11 – AWS Marketplace AMIs

我们可以根据左侧边栏的操作系统、软件免费试用、软件定价计划和支持等参数进一步筛选结果。一旦我们决定了一个产品，我们可以按照第五章中的步骤，完成启动实例的过程。

工作原理...

AWS 可能无法提供我们需要的所有安全产品。许多第三方公司开发了与 AWS 服务相辅相成的安全和合规解决方案。我们看到了如何在 AWS Marketplace 中找到这样的 AMI。一旦我们决定了一个产品，我们可以使用该 AMI 启动一个实例。关于我们选择的特定产品的更多详细信息，我们可以参考相应产品的文档。

还有更多...

网络数据包检查，也称为深度数据包检查（DPI），检查数据包头和数据包内容，以检测不符合规定的数据、病毒、垃圾邮件等，并可以采取阻止和记录等措施。它结合了传统防火墙的功能与入侵检测系统（IDS）或入侵预防系统（IPS）的功能。

AWS Web 应用程序防火墙（WAF），AWS 中的防火墙服务，可以检查已知的漏洞，如 SQL 注入，跨站脚本等。然而，AWS 无法进行完整的网络数据包检查，也缺乏 IDS 和 IPS 的功能。不过，我们可以使用 AWS Marketplace 中的解决方案。供应商包括 Alert Logic、Trend Micro、McAfee、Palo Alto Networks 和思科系统等。

参见

您可以在 AWS Marketplace 中阅读有关安全产品的信息，网址为www.cloudericks.com/blog/getting-started-with-aws-marketplace。

使用 AWS 可信顾问进行建议

在本教程中，我们将学习如何使用可信顾问。可信顾问是 AWS 中提供与成本优化、性能、安全、容错性和服务限制相关建议的在线工具。

准备工作

我们需要一个可用的 AWS 账户，以及技术要求部分所描述的用户。

如何操作...

我们可以按照以下方式使用可信顾问：

1. 转到 AWS 管理控制台中的可信顾问服务。我们应该在仪表板登陆页面上看到建议类别和基本建议，如下图所示：

图 10.12 – 可信顾问仪表板

1. 点击左侧边栏中的安全，查看与安全相关的建议。

图 10.13 – 安全建议页面

1. 点击下载所有检查以下载所有检查，或者点击建议的下载按钮以下载该建议的详细信息。

2. 点击刷新所有检查以下载所有检查，或者点击建议的刷新按钮以刷新该建议的详细信息。

3. 点击左侧边栏中的服务限制，查看与服务限制相关的建议，例如使用超过服务配额 80%的服务。

重要提示

截至本文撰写时，除了安全和服务限制之外，所有其他建议都需要升级才能使用。我们可以在点击左侧边栏中的建议或者在左侧边栏中的任何建议类别选项中除了安全和服务限制之外进行升级。

工作原理...

可信顾问提供与成本优化、性能、安全、容错性、服务限制和运营卓越相关的建议。有两种服务级别：基本计划和完全可信顾问。基本计划是免费的，涵盖核心检查和建议。完全可信顾问功能适用于开发者、商业和企业 AWS 支持计划。

还有更多...

可信顾问基本计划目前在成本优化、性能、容错性和运营卓越方面没有可用的建议。对于这些类别，只有完全可信顾问才提供建议。对于安全和服务限制类别，一些建议既适用于基本计划，也适用于完全可信顾问。

另请参阅

您可以在www.cloudericks.com/blog/understanding-aws-trusted-advisor了解更多关于 Trusted Advisor 的信息。

使用 AWS Artifact 进行合规性报告

在本教程中，我们将学习如何使用 AWS Artifact。AWS Artifact 是一个免费的自助门户，用于访问 AWS 的合规性报告。AWS Artifact 可用于访问 AWS 的安全和合规性报告，并选择在线协议。

准备工作

我们需要一个可用的 AWS 账户，以及在技术 要求部分描述的用户。

如何操作...

我们可以按照以下方式使用 AWS Artifact：

1. 转到控制台中的AWS Artifact服务。

2. 在左侧边栏中点击报告查看可用报告。

图 10.14 – AWS Artifact 的报告

1. 在左侧边栏中点击协议查看账户协议和组织协议。

图 10.15 – 协议

提示

我们可以从组织的主账户中点击组织协议选项卡，管理主账户和组织中所有成员账户的协议。

1. 选择任何协议，然后点击下载协议按钮下载协议。如果出现接受 NDA 下载报告的消息，我们需要选择我已阅读并同意所有 NDA 条款复选框。

点击接受 NDA并下载。

图 10.16 – 接受并下载报告

工作原理...

我们已经学会使用 AWS Artifact 来检查合规性报告。以下是目前在 AWS Artifact 中可用的一些报告：可访问性符合性报告（VPAT）– Amazon Cognito 用户池，英文版 HDS 认证，ABS 云计算实施指南 2.0 – 工作簿，可访问性符合性报告（VPAT）– Amazon API 网关，可访问性符合性报告（VPAT）– Amazon AppFlow，可访问性符合性报告（VPAT）– Amazon AppStream 2.0，可访问性符合性报告（VPAT）– Amazon 简单队列服务，可访问性符合性报告（VPAT）– Amazon 简单通知服务（SNS），以及可访问性符合性报告（VPAT）– Amazon 简单邮件服务（SES）。

还有更多...

在本书中，我们看到了许多 AWS 服务，帮助我们在 AWS 上保护基础设施。然而，这并不是一个详尽的列表。AWS 还不断添加更多服务和功能。让我们快速浏览一些与安全相关的更多服务：

• Amazon Detective 是一个可以通过分析和可视化安全数据来帮助找到潜在安全问题根本原因的服务。截至本文撰写时，此服务处于预览阶段。

• AWS 控制塔帮助我们根据与安全和合规性相关的最佳实践建立和管理多账户 AWS 环境。最终用户可以根据公司范围内集中建立的合规性政策提供新账户，云管理员可以查看着陆区域的完整概述。着陆区域是所有需要合规的 OU、账户、用户和其他资源的容器。着陆区域应该位于组织的非成员账户中。

• AWS 许可证管理器帮助我们管理来自第三方供应商（如微软、甲骨文和 SAP）的许可证，当我们将它们引入 AWS 时。我们可以控制它们的使用，甚至为不同用户组设置定制规则。

• AWS 个人健康仪表板是一项提供给高级支持计划客户的服务，用于监视、管理和优化他们的 AWS 环境。

• AWS 良构架构工具是基于 AWS 良构架构框架的管理服务。我们可以根据当前 AWS 最佳实践定义工作负载，这个工具将提供如何改进我们的云架构的指导。

另请参阅

您可以在www.cloudericks.com/blog/getting-started-with-aws-artifact了解关于 AWS Artifact 的信息。