Hello大家好，在本课时我们将讨论AWS Control Tower。

AWS Control Tower是AWS organizations的一个功能延伸，它是设置在organizations的上层，并为您提供一些额外的控制。

通过Control Tower可以创建一个Landing zone，Landing zone是什么呢？**Landing zone可帮助客户更快速地设置符合 AWS 最佳实践的安全的多AWS账户的 AWS 环境。**如果您的账户还没有创建AWS组织，那么它首先将会为您创建一个组织。

在这个组织中，您有您自己的根OU，在这个OU有您的管理账户。

然后作为Landing zone的一部分，Landing zone还将为您创建一系列的OU和账户。比如安全OU，沙箱OU，以及生产OU。当然您可以在一定程度上配置您需要创建哪些OU在Landing zone配置向导的步骤。

在安全OU中，将会创建两个AWS账户，分别是审计账户和日志存档账户。审计账户适用于需要访问 AWS Control Tower 提供的审计信息的用户团队；日志存档账户适用于需要访问landing zone 内已注册 OU 内的所有已注册账户的所有日志信息的用户团队。

简单来说就是一个是用于Landing zone日志审计的，一个是用于将所有Landing zone内AWS账户的所有日志收集的。

沙箱OU默认没有创建账户，您可以在其中创建开发测试账户；在默认情况下生产OU也是空的，您可以将您的生产账户直接添加到这里。

Control Tower集成了AWS SSO单点登陆服务，单点登陆的目录源可以是AWS SSO目录本身，这是默认的配置；还支持SAML2.0身份提供商以及微软活动目录。

Control Tower会创建一系列的预防性护栏，您可以理解成护预防性栏是一种防护性的机制，基本上是一些服务控制策略，用于禁止某些API操作。

您也可以把它视为类似于在IAM中管理策略。**实际上Control Tower为您创建了一系列托管的SCP，**这些托管的SCP针对特定的用途进行了预配置。简单的说预防性护栏作用就是可确保您的账户保持合规性，因为它会禁止导致违反政策的行为；

那除了预防性护栏，**Control Tower也也创建了Detective护栏，Detective护栏可以检测您账户内资源的不合规情况，**例如违反政策的行为，并通过仪表板提供警报。它是基于AWS lambda函数和AWS config规则来实现的。

最后我们总结下Control Tower。

Control Tower用于创建一个可帮助客户更快速地设置符合 AWS 最佳实践的、安全的、多AWS账户的 AWS 环境，也就是AWS所谓的Landing zone，中文一般翻译为着陆区。

护栏用于治理和合规性，**首先是预防性护栏，这些护栏基于服务控制策略，用于禁止某些API操作；**然后还有Detective护栏，它是通过AWS config规则以及Lambda函数来实现的，用于监视和管理Landing zone的合规性。

最后需要注意一点是，**管理账户内的根用户是可以执行护栏中禁止的操作的。**这是和AWS组织的概念相同，在AWS组织中，SCP也不能控制和影响管理账户中的根用户。

好的，以上就是本课时的内容，希望能够给大家带来帮助。

希望此系列教程能为您通过AWS的认证考试带来帮助，如您有任何疑问，请联系我们：

• 如果您想获取本课程全部课时，请扫PPT的二维码加入。
• AWS爱好者的网址是www.iloveaws.cn，认证视频课程，免费的认证考试仿真题以及认证课程文章，都可以在网站找得到
• 可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章。
• 加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识。

我们今天的视频课程就到这里，感谢大家的观看，我们下一课程再见。

Hello大家好，我们接下来讨论AWS Directory Service，AWS目录服务的内容。

什么是微软活动目录（AD）

在认证考试中有很多的考点是关于微软AD部分的，也就是微软活动目录以及AWS活动目录服务—AWS Directory Service的内容。

微软活动目录知识面比较复杂，如果您完全不了解微软活动目录，那么学习本课时可能会有些吃力，建议先去看一些微软活动目录的基础知识。

那什么是微软活动目录呢？AD在Windows 2000 Server开始内置于Windows Server产品中。它是微软Windows Server中，负责架构中大型网络环境的集中式目录管理服务（Directory Services）。

负责处理以及存储在组织中的网络对象。对象可以是用户、组群、电脑、邮件、配置文件、打印机等等。

它是一种WINDOWS环境中集中管理方式，用于安全管理，创建账户，分配权限等等。

前面提到的这些对象，如用户、群组、电脑、打印机等等他们将被组织在一起，并组织成”树”，然后一组“树”被称为“森林”。

那么，我们为什么需要AD呢？ 我举个简单例子：

例如，我们有一个域控制器存储和管理着张三的用户名和密码，然后还有一些其他的Microsoft电脑连接到此域控制器。我们就可以在这些任何一台电脑上使用张三的登陆凭证登陆WINDOWS。AD负责登陆验证并对用户进行管理。

当然这只是AD的一个非常简单的一个功能举例，AD还有客户端计算机管理，组策略，资源管理等等功能在这里就不在展开了。

什么是ADFS?（微软活动目录联合服务）

那什么是ADFS呢？ADFS翻译过来是微软活动目录联合服务。它主要功能是提供了跨应用程序的单点登录。

所以这意味着可为任何支持ADFS提供如跨AWS控制台、Dropbox、Office365单点登录。

我们之前的课时介绍过这个流程：

用户连接到ADFS进行验证，ADFS 将使用您的 Microsoft AD 对用户进行身份验证，然后 ADFS 将返回一个响应，该响应将被传递到AWS 并与 STS 交换令牌，最终用户可以使用该临时凭证访问AWS管理控制台。在之后我们会讨论SSO，SSO使我们能够更轻松地做到这一点。

AWS Directory Services

好的，接下来我们讨论AWS Directory Services，AWS目录服务。这是由AWS管理的服务，有三种目录类型。

**第一个叫做 AWS Managed Microsoft AD,**正如其名，它是搭建在AWS云端的Microsoft AD。

您可以使用它在AWS 中创建您自己的 AD**，**在AWS本地管理用户，并支持MFA。如果您想使其和本地 AD 之间建立连接，必须将AWS 托管的Microsoft AD与本地 AD 建立信任关系。我们看下这种信任是什么样的：

位于右侧的AWS托管 AD 连接到本地 AD，并建立了信任关系，它支持 MFA，用户可以在本地，或者在AWS托管的AD任意端进行身份验证。

**AWS目录服务的第二个叫做AD Connector，**它是一个代理服务，能够从云端重定向请求到您的本地AD。

注意在使用AD Connector场景时，管理用户只能够在本地端进行，我们来看一下：

所以在这种场景下，在AD Connector端的身份验证，因为AD Connector它是一个代理服务，这里的请求会被代理发送 到本地的AD获取响应。

所以，在前面讲的使用Microsoft 托管AD的情况下，我们可以在本地和云端两个地方管理用户，需要建立信任关系。

而使用 AD Connector，用户只能在本地管理，来自云端的请求会通过这个代理来访问本地的AD。

**最后一个服务叫做Simple AD，**是由Samba 4 提供支持的独立托管目录。现在使用的很多需要微软AD支持的应用程序和工具都可以与 Simple AD 一起使用。

注意它不能与本地 AD 连接。

使用 Simple AD 是一种更低成本的解决方案，它不支持太多的功能，例如，不支持 MFA。Simple AD与一些AWS的服务也不兼容，如RDS SQL Server等。

但它会更简单，更低的成本，如果您的场景是需要一个简单的目录服务，用于支持基本AD功能的Windows 工作负载，那么Simple AD就会是一个更合适的方案。

好的 ，我们讨论了以上三种目录服务，也简单探讨了他们之间的区别，接下来我们将更加深入的探讨这三种目录服务，让大家非常清楚的了解他们之间的区别和使用场景。

AWS Directory Service – AWS Managed Microsoft AD

首先，AWS Managed Microsoft AD，我们后面就称其为AWS托管微软AD。

选择 使用AWS托管微软AD，它会部署到您的VPC中，大致是这样：

两个可用区，就会创建两个连接到 Virtual Private Cloud (VPC) 的域控制器，分别部署在两个不同的可用区中以实现高可用性。

然后我们就可以创建 EC2 Windows 实例，并加入域。我们可以在这些实例上部署传统AD应用程序，例如，sharepoint。

还支持将多个AWS账户和VPC中的Windows EC2 实例无缝加入到域中。

它和很多AWS资源无缝集成，比如我们在云中部署托管微软AD，可以将其与 RDS for SQL Server，WorkSpaces, Quicksight 等无缝集成使用。

可以创建AWS SSO，提供对第三方应用程序的访问。

AWS托管微软AD支持在AWS作为一个独立的存储库，或者可以加入到您的本地 AD。

多可用区部署将至少是两个可用区，支持增加更多的域控制器以提供更高的可用性，所以在这个例子中，我可以在添加两个域控制器，一共四个域控制器，提高了可用性。

另外，AWS托管微软AD的数据复制、快照和软件更新是自动为您配置和管理的。

最后总结下，使用AWS托管微软AD，可以与其他服务无缝集成，支持无缝加入EC2 实例，多可用区部署。

AWS Managed Microsoft AD – 集成

前面我们提到了AWS托管微软AD与很多资源和服务很好的集成，接下来让我们深入了解一下集成。

如：这是我们部署的AWS托管微软AD的域控，它可以和本地AD配置一个双向森林信任，就可以从云端扩展到使用您的本地的AD，后面我们会介绍这部分。

它还与一系列 AWS 服务集成，如最常用和重要的是：RDS for SQL Server，WorkSpaces，Quicksight，AWS Connect，WorkDocs，和AWS SSO单点登陆，

并且通过单点登录，我们可以访问更多 SAML 业务的应用程序， 例如 GitHub、Box、Dropbox、Office365 等，我们将在后面的课时看到这部分内容。

最后，您的传统 Active Directory 应用程序，例如您的 .NET 应用程序、SharePoint、以及您部署在 EC2 实例上的 SQL Server，显然都可以和AWS托管微软AD很好的集成。

所以大家可以看到，这将是与AWS产品集成度最高的目录服务。

连接到本地AD

好的，接下来我们来讨论如何将AWS托管微软AD连接扩展到您的本地 Active Directory ,注意这部分在考试中有很多考点。

您可以将本地部署的AD连接扩展到AWS托管的微软AD。两者之间需要设置一个 Direct Connect，DX，或者是通过VPN连接。

我们来看一下：

左边是您本地部署的AD，右侧是您部署VPC的AWS托管的微软AD，我们已经在两者之间建立了连接。在本地部署的微软AD，它负责管理本地的用户；在AWS托管的微软AD，负责管理在AWS上的用户。

AWS托管微软 AD 支持所有三个信任关系方向：传入、传出和双向，分别表示本地到AWS单向信任，AWS到本地单向信任，以及双向森林信任。

这块有一个重要的知识点要注意，上面说到的信任关系，和同步不是一个概念，不要混淆。

AWS托管的微软AD是不支持复制的，这就意味着在这两个不同的微软AD上的用户是相互独立的，这一点大家要了解。

但如果本地AD和AWS托管微软 AD建立了信任关系后，如果在其中一个AD中找不到某个用户，也会询问这个用户在另一个AD是否存在，因为两个AD建立了信任关系。但这并不到等于数据复制，所以理解这一点非常重要。我们来看一下：

您的传统AD应用程序可以连接到本地的AD，您的 EC2 实例可以进行无缝域加入到您的AWS托管微软 AD。然后因为我们建立了双向森林信任，您传统的 Active Directory 应用程序，如果它试图请求一个属于 AWS的上的域，因为配置了信任关系，它就有权限和能力访问到右侧AWS的AD并检查其中的用户。这是双向森林信任的一个场景。

解决方案-AD复制

好的，接下来我们看一个相关的解决方案架构，可能稍微有点复杂，大家要掌握这部分内容。

这个架构的场景是您想要部署在您本地的微软AD在AWS中建立一个副本，当本地和AWS之间的DX或者VPN出现故障时，仍然希望用户能够正常连接和访问。

这需要在AWS和本地AD之间建立信任关系，我们来看一下：

左边是我们的本地的微软AD,包括一个域；右侧是AWS VPC下有一个AWS托管的AD DC包括另一个域，他们之间没办法直接设置复制，设置复制的唯一方法，是启动一个EC2实例，在一个EC2 Windows实例上部署一个AD，并设置它与本地AD的复制。

通过配置这些复制，我们将在VPC上拥有一个本地微软AD的副本，这样将有助于最大程度的减少延迟，并且也有助于灾备恢复。

最后，我们可以在我们这个VPC中的EC2实例，和这个AWS托管的微软AD DC之间建立一个双向信任。从而达到我们上面提到的需求。

好的，这是一种解决方案架构，考试的时候可以会出现这个考点，希望大家能够掌握。

以上就是所有aws托管的微软AD的全部内容。

AWS Directory Service – AD Connector

接下里我们讨论 AD Connector ，这部分就简单的多了。

AD Connector是一个网关，一个代理， 它可以重定向您的请求到您本地的微软AD。

不支持缓存功能，不支持MFA，用户仅在本地进行管理，无法配置信任关系，需要VPN或者DX连接。

没有和 SQL Server做集成，也不能进行无缝连接，不能共享目录。

所以AD Connector是一个比较基础的组件，所以在考试中如果遇到需要目录服务代理的场景，就需要使用AD Connector。

使用AD Connector如果连接断开了基本上就废了。

那么它是如何工作的呢？我们来看一下：

左边是本地网路，右边是AWS，然后在两者之间通过一个DX或者VPN连接，我们已经配置了AD Connector，因此，如果我们的用户通过 AD Connector连接，AD Connector 收到用户的请求，然后访问本地的AD，代理身份验证并取回登陆信息回 给用户，所以这就是它的工作方式，在这种场景下可能会有一些延迟。

AWS Directory Service – Simple AD

最后我们讨论下Simple AD，这是一个非常具有成本效益的AD服务，并且它具备和兼容常见的目录功能。它支持加入EC2 实例，管理用户和组，但不支持MFA，也不支持RDS SQL Server 的集成，以及AWS SSO。

它只支持少量用户的场景，适合500-5000个用户，它由 Samba 4 提供支持，并且在API方面与Microsoft AD兼容；但它的成本更低，规模小，它只有基本的 AD 功能，或 LDAP 兼容性。

不支持配置与本地AD的信任关系。

以上我们讨论了AWS的目录服务的三种目录类型，考点最多的显然是第一个。希望大家可以掌握针对不同的场景选择适合的目录类型，在考试中也会有相应的考点。

好的，以上就是AWS目录服务的内容，希望能够给大家带来帮助。

希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问，请联系我们：

• 如果您想获取本课程全部课时，请扫PPT的二维码加入。
• AWS爱好者的网址是www.iloveaws.cn，认证视频课程，免费的认证考试仿真题以及认证课程文章，都可以在网站找得到
• 可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章。
• 加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识。

我们今天的视频课程就到这里，感谢大家的观看，我们下一课程再见。

Hello大家好，我们接下来讨论AWS联合身份验证的内容。

AWS联合身份验证

对于考试，联合身份验证部分是一块非常重要的内容。那什么是联合身份验证，它是做什么用的呢？

联合身份验证，是用来允许AWS外部用户，如您的公司目录中的用户，外部三方用户，通过代入AWS的角色，然后通过代入角色的临时安全凭证的方式访问AWS的资源。

我们看一下联合身份验证大致的流程：

• 首先，您的用户通过第三方的用户系统进行身份验证，AWS要信任这个第三方。
• 当用户登陆时从三方那拿回了凭证，然后通过交换或使用这个凭证来访问AWS资源。

联合身份验证的核心思想是通过AWS信任的第三方的用户系统来执行所有的用户管理行为。

AWS的联合身份有多种形式，我们需要了解所有这些形式，以及在面对不同的使用场景选择最适合的方案：

• 第一个是，SAML 2.0
• 第二个是，用户自定义身份代理
• 然后是使用Cognito的WEB身份验证及【12】不使用Cognito的WEB身份验证
• 还有SSO，单点登陆
• 以及AWS托管的 Microsoft AD (Non-SAML)

使用联合身份验证，不需要我们为这些用户在AWS账户中创建IAM用户，用户管理工作是在AWS外的用户系统中完成的。

那我们接下来的内容就开始讨论上面联合身份验证的几种形式。

SAML 2.0联合身份验证

首先，SAML 2.0联合身份验证。

SAML 2.0，也就是安全断言标记语言 2.0，它支持联合身份验证，是许多身份验证提供商 (IdP) 使用的一种开放标准。

如您的公司已使用支持 SAML 2.0 的身份提供商，比如本地的Active Directory（活动目录），或者ADFS（活动目录联合服务）等，那么可以使用 SAML来简化为AWS 配置联合身份验证的过程。

那在这种场景下，您公司的员工的用户已经在您公司支持 SAML 2.0的身份提供商中存在了，通过配置就可以实现联合单一登录 (SSO)，就可以通过临时凭证，然后实现这些用户的登录AWS控制台或调用 Amazon API 操作，而不需要为每个员工都创建一个 IAM 用户。

我们来看下大致的流程：

1、您公司的用户使用客户端应用程序来请求您公司的 IdP （身份提供商）进行身份验证。

2、IdP 根据身份存储对用户进行身份验证。

3、验证通过，IdP 构建一个具有用户相关信息的 SAML 断言，并将此断言发送到客户端应用程序。

4、客户端应用程序调用 AWS STS AssumeRoleWithSAML API，并传递 SAML 提供商的 ARN、要代入的角色的 ARN 以及来自 IdP 的 SAML 断言。

5、然后STS的API 对客户端应用程序的返回临时安全凭证。

6、最后客户端应用程序使用收到的这个临时安全凭证来调用 Amazon S3 API 操作。

同样，整个流程也适用于访问AWS控制台：

1、首先用户通过一个网站比如您公司的门户网站，验证用户的身份。通常在这个场景，门户网站充当处理您公司与 AWS 之间的信任交换的 IdP。

2、然后同样该门户网站生成一个 SAML 身份验证响应，将此返回给客户端浏览器

3、该客户端浏览器将被重定向到 AWS 单一登录终端节点并发布 SAML 断言。

4、SSO终端节点将代表用户请求临时安全凭证，并创建一个使用这些凭证的控制台登录 URL，并作为重定向返回给客户端。

5、最终该客户端浏览器将重定向到 AWS管理控制台。

综上，如果您公司的身份验证提供商 (IdP) 是支持SAML 2.0的，建议采用上述的两种方式调用AWS的API或者访问AWS管理控制台。

SAML 2.0联合身份验证 – Active Directory FS

还有一部分是ADFS联合身份验证过程，

整个过程与前面讨论的SAML 2.0的IdP过程基本是一致的。

可以看到不在使用IdP，取而代之使用ADFS对用户进行身份验证，后端使用AD作为身份存储，ADFS返回给用户SAML断言，发送给STS，然后用户使用临时凭证访问AWS管理控制台或者AWS资源。

那么如何配置SAML 2.0 联合身份验证呢？

在使用前面所述的基于 SAML 2.0 的联合身份验证之前，您必须先配置组织的 IdP 和您的 AWS 账户，使之相互信任。

然后在通过相应配置，就可以通过SAML 2.0 实现基于WEB的跨域SSO（单点登陆）。当您公司的用户登陆公司的门户后，即可获得对多个AWS账户的访问，而不需要在重复登陆AWS进行身份认证。

这种方式是通过客户端应用程序调用 AWS STS AssumeRoleWithSAML API，前面流程我们已经讨论过了，要记住这一点。

目前AWS有一个服务叫做AWS Single Sign-On，可以更加简单的实现上述的SAML 2.0联合身份验证，也是AWS更加推荐的方式，我们也会在后面的课时讨论。

自定义身份代理

前面我们讨论了基于SAML2.0的联合身份验证，那如果您公司的IdP不兼容SAML2.0，就需要使用自定义身份代理，来访问AWS控制台或资源。

这种方式需要在身份代理处分配给用户适当的IAM策略，所以需要在这里做更多的工作。为用户获取临时安全凭证通过AssumeRole（推荐）或 GetFederationToken API 操作。

我们看下整个流程，和之前有些区别：

• 用户进行登陆，然后到身份代理程序，通过公司的身份存储进行用户登陆验证；
• 验证通过后，身份代理程序直接和STS通信，获取临时安全凭证，用于允许用户执行授权的操作。大家注意，这部分和之前SAML2.0的流程是有区别的，之前是在用户侧和STS进行通信，而这里是身份代理程序直接和STS通信。
• 然后身份代理获取临时凭证后，将其传给用户，然后用户就可以通过这些凭证访问AWS的资源如EC2、S3等或访问AWS管理控制台。

所以这里主要和之前SAML2.0联合身份验证的主要区别是，自定义身份代理方案，不是用户侧和STS交互临时凭证，而是在身份代理这里与STS交互临时凭证。

**对于考试而言，只有在您的组织没有使用与 SAML 兼容的身份提供商 (IdP)时，才使用自定义身份代理。**还有一点，这个方案的身份代理部分是否配置正确非常的重要，而且会涉及到很多的工作。

Web联合身份验证 – AssumeRoleWithWebidentity API

好的，接下里我们讨论下Web 联合身份验证。

比如我们创建了一个移动程序，或者WEB应用程序，我们希望能够让用户访问到我们AWS账户下的指定的资源，如S3，DynamoDB，存储一些用户的数据，这是非常常见的场景。

• 第一种实现方式是编写代码然后通过调用 AssumeRoleWithWebIdentity API；这也是常用的方式；
• 而AWS更推荐使用AWS Cognito来取代上面这种方式。AWS认为Cognito更棒，除了实现所有功能，还允许匿名访问，支持数据同步，以及MFA认证。

那我们也看一下第一种方式的流程： 1、手机的应用程序调用第三方身份提供商对用户和应用程序进行身份验证，比如amazon，google,facebook等等。身份提供商会返回 Web 身份验证令牌到应用程序。 2、然后应用程序通过AssumeRoleWithWebIdentity API调用STS并传递Web 身份验证令牌，STS返回临时凭证，允许应用代入IAM角色和访问AWS资源。 3、最后应用程序就可以访问如这个图示中的例子DynamoDB的表。

那前面也提到了，AWS推荐使用AWS Cognito来实现WEB联合身份验证，我们来看一下。

• 需要使用 Amazon Cognito 创建一个IAM角色，这个角色的权限要遵循所需最小权限原则；
• 同样在OIDC IdP和Cognito两侧要建立信任。

我们来看下整个架构：

您的应用程序的用户可以使用他的三方如google、facebook、amazon、cognito账密登陆；

然后应用程序使用 Cognito API 操作将 登陆三方的令牌交换成 Cognito 令牌；

接着应用程序使用 Cognito 令牌从 AWS STS 请求临时安全凭证；

最后应用程序可使用临时安全凭证访问应用程序运行所需的 AWS 资源，与临时安全凭证关联的角色及其分配的策略将决定它可访问的资源。

整个流程和API的方式有些类似，但是使用Cognito的优势是：

• Cognito支持匿名用户，而WebIdentity API是不支持的。
• 它支持MFA,所以可以在过程中强制使用MFA，这样我们就有了更多的安全保障。
• 最后是数据同步。

另外如果大家在哪里看到一个叫做TVM，Token Vending Machine，这是AWS比较老的一个解决方案，目前使用Cognito来替代它。

最后如果在考试中看到WEB联合身份验证相关的内容，AWS总是希望您会选择使用Cognito，它有很多的优势，另外AWS总是希望您选择AWS的服务来实现需求。

Web联合身份验证 – 识别用户的身份

在使用Web 联合身份验证在 IAM 中创建访问策略时，可根据已使用外部身份提供商 (IdP) 进行身份验证的用户的 ID 指定权限，这是通过IAM的策略变量来实现的。策略变量对我们面对一些场景时是非常有帮助的。

那在IAM策略中如何获取用户登陆后外部身份提供商对应的该用户的ID呢：

我这里列了一下congnito，amazon，facebook，google这4家的方式：

• congnito是通过：cognito-identity.amazonaws.com:sub
• amazon.com是通过：www.amazon.com:user_id
• facebook是通过：graph.facebook.com:id
• google是通过：accounts.google.com:sub

我们来看一个例子：

这是一个IAM策略，允许操作，动作是s3:ListBucket。

关键是在这个condition，它的意思是只有在 Amazon S3 中的存储桶前缀与这个字符串匹配时，该策略才会为该存储桶授予访问权限。而这里变量www.amazon.com:user_id，会代入用户通过amazon.com登陆后对应的该用户的ID，所以也就是说，这个策略的作用是假定用户使用 Login with Amazon 登录，该用户只能访问对应自己的ID的这个存储桶前缀位置。

这为使用Web 联合身份验证时，分配用户的权限提供了更多的灵活性。

那我们最后概括一下，使用联合身份验证，来管理 AWS 外部的用户身份；而IAM策略可以通过策略变量代入用户ID的方式，为外部的联合身份用户分配适当的访问权限。

好的，以上就是联合身份验证的内容，希望能够给大家带来帮助。

希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问，请联系我们：

• 如果您想获取本课程全部课时，请扫PPT的二维码加入。
• AWS爱好者的网址是www.iloveaws.cn，认证视频课程，免费的认证考试仿真题以及认证课程文章，都可以在网站找得到
• 可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章。
• 加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识。

我们今天的视频课程就到这里，感谢大家的观看，我们下一课程再见。

我们开始今天的课程内容。

我们上节课讲了一个用户案例，通过将允许访问S3的权限策略附加到IAM角色，开发人员通过sts:Assumerole的方式获得该角色的临时访问凭证，然后使用此临时访问凭证访问AWS S3，我们也说了这种方式是AWS推荐的最佳实践，而不是为用户直接分配永久性的凭证。

看了课程的同学可能会有一个疑问，这种访问AWS资源的方式，当获取角色临时凭证后，需要手动将access key、secret key以及会话token复制到aws 的 credentials文件。而默认情况下临时凭证的有效期是一个小时，也就是说如果开发人员需要定期访问aws资源，就需要在凭证过期后再次运行sts assume-role命令，然后在将获取的新的临时凭证复制到aws 的 credentials文件中，这显然是一个低效的方式，而作为解决方案架构师来讲，如果您提供了这种方案给开发人员，开发人员恐怕不会遵循这个办法。

那怎么解决这个问题呢？AWS提供了一个自动化上述过程的一个方法，我们接下来来看一下如何实现。

是这样的，如果您调试是位于Amazon EC2实例上，而这台EC2附加了IAM角色，则AWS CLI将自动为您检索凭证，您不需要配置任何凭据。

指定AWS CLI承担角色的配置方法

而我们现在这个用户案例，需要在本地CLI调用AssumeRole，在使用返回的临时凭证访问AWS资源，所以您需要进行配置，指定AWS CLI承担的角色，然后AWS CLI就会自动为您进行相应的AssumeRole调用，那怎么指定AWS CLI承担的角色呢？

需要在aws cli的credentials文件中增加一个profile ，包括两个配置项：

• role_arn，需要配置为您需要担任角色的ARN，所以我们这里需要配置成我们在上节课新建的角色stroll的ARN
• source_profile，这里配置执行assume-role的IAM用户凭证所在的profile

我们现在来配置下：

切换到终端，这里是我们上节课执行的sts assume-role命令，–role-arn参数后面指定了想要承担角色stroll的arn，我们复制一下，然后编辑AWS credentials文件 。

可以看到我们新建了一个名为automate的profile，里面有包括我们前面PPT讲的两个配置项， 将复制的角色arn粘贴到role_arn这里。

source_profile，这里需要配置执行assume-role的IAM用户凭证所在的profile，对应我们这个案例就是开发人员的IAM用户zhangsan；zhangsan用户凭证所在的profile就是这里的default，我们在上节课将其access_id 、secret_key都配置在了default，大家还记得吧，所以我们直接配置为default 。

所以，通过这两个配置项，AWS会自动使用default字段的zhangsan的安全凭证，返回role_arn配置项配置的角色stroll的凭证，所以我们就可以通过aws cli命令，通过指定automate的profile 执行命令。

保存退出。

现在我们就将aws cli承担的角色的arn，以及执行assume-role的zhangsan用户凭证所在的profiile都配置完了，我们现在执行下命令：
aws s3 ls --profile automate

这里要注意–profile主要指定我们新创建的automate，看下命令执行结果：

可以看到成功列出了s3存储桶。

通过配置aws cli承担角色这种方式，我们就不必在临时凭证过期时在手动执行assume-role命令获取临时凭证，在手动配置到AWS credentials文件，而这一切都将由aws自动帮您搞定。

好的，以上就是我们今天的课程内容，我们介绍了配置AWS CLI承担IAM角色的步骤，希望同学们有收获。

希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问，请联系我们：

• 如果您想获取本课程全部课时，请扫PPT的二维码加入。
• AWS爱好者的网址是www.iloveaws.cn，认证视频课程，免费的认证考试仿真题以及认证课程文章，都可以在网站找得到
• 可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章。
• 加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识。

我们今天的视频课程就到这里，感谢大家的观看，我们下一课程再见。

Hello大家好，欢迎来到《AWS解决方案架构师认证 Professional(SAP)中文视频培训课程》，我们前几个视频课程都在讨论AWS STS服务，今天将继续AWS STS服务的内容—使用STS服务，为用户分配临时凭证访问AWS资源。

我们开始今天的课程内容。

1、一个用户案例：哪个方案最佳？

我们先看一个用户案例，张三是一个开发人员，他要在他本地的电脑环境测试他的代码。代码需要访问AWS S3，所以需要AWS的access & secret key 。那么以下哪个方案是实现需求的最佳的解决方案？

这是一个普遍的案例，相信在大多数组织中都发生过，开发人员想要在本地的电脑上测试他的代码，这样的话就不能附加角色到EC2，然后在要求研发人员登陆EC2上去做测试。在这种情况下，有三种方案能够满足开发人员的测试需求：

第一个方案，提供给研发人员access & secret key，然后告诉他不要与其他人员共享凭证。相信很多组织都是这么做的，可以满足需求，但不安全，而且多年的工作经历和教训告诉我们，他是一定会和其他人分享凭证的。

第二个方案，提供给研发人员access & secret key，然后确保凭证每90天进行一次轮换，这种方式看似比第一种方式安全些，因为增加了凭证的轮换。但是同样，如果这个凭证被泄露，90天的轮换间隔是一个很长的时间间隔，在泄露后轮换时间前，同样会造成安全隐患；而缩短轮换时间同样不是一个很好的解决方案，尤其是您的组织有几十、几百个用户需要凭证时，会给您的工作带来很高的复杂度。所以整体这个方案也不太理想。

第三个方案是允许研发人员使用AWS STS服务生成临时凭证，使用临时凭证访问资源。这个是最佳的解决方案。如果您在您的组织是解决方案架构师或者负责安全工程师，当开发人员或者其他人员请求凭证访问AWS资源时，请您采用这个方案。

在上节课将EC2元数据的临时凭证拷贝到了我本地的mac电脑，在本地访问AWS资源，那不是一个很理想的方式，接下来看下满足这个用户案例最佳的实现方式，也就第三个方案的具体配置步骤。

2、AWS STS服务生成临时凭证，使用临时凭证访问S3的实现步骤：

第三个方案是允许开发人员使用AWS STS服务生成临时凭证，使用临时凭证访问S3。所以我们要配置：通过将允许访问S3的权限策略附加到角色，开发人员通过sts:Assumerole的方式获得该角色的临时访问凭证，然后使用此临时访问凭证访问AWS S3。

PPT的图是最终的执行流程，非常清晰，开发人员在本地执行AssumeRole，然后IAM角色返回临时凭证，然后用户使用这个临时凭证访问S3，这种方式是AWS推荐的最佳实践，而不是通过将持久性凭证分配给用户直接使用。

所以接下来我们需要做三件事：
第一步，在IAM中建立一个角色（角色名：stroll）
第二步，附加一个S3ReadOnly策略到IAM角色，让这个角色有只读访问S3的权限
第三步，允许IAM用户也就是开发人员使用的用户执行STS Assume Role 权限，获得临时凭证
最终开发人员使用临时凭证访问S3。

为了加深大家的理解，还是老惯例直接实操演示：

注意，本课时的内容以及实操演示，其中IAM角色，IAM用户，以及S3存储桶都在同一个AWS账号下，并未跨AWS账号，本课时的内容只是为了帮助大家更好的理解获取角色的临时凭证访问资源。

当然，您也可以自行应用在跨AWS账户的方案中，比如实现在A账户中的用户通过B账户的角色临时凭证，访问B账户中的存储桶。

3、实操演示-配置：

登陆AWS管理控制台，进入IAM-用户，我们目前已经创建了开发用户zhangsan，没有附加任何权限。

然后，切换到我本地mac的终端，我们后面假设这个就是开发人员zhangsan要调试代码的终端，需要访问S3存储桶。

先看一下aws的credentials文件内容，我已经将zhangsan的访问密钥配置在了credentials文件的default中，可以核对下，ID后4位UDVX，切换到控制台，安全证书，密钥id后四位是UDVX是一致的，已经在本地终端credentials文件配置了IAM用户zhangsan的安全凭证。

我们现在在本地mac终端执行aws s3 ls ，返回的信息是访问被拒绝，无法访问，因为现在zhangsan这个用户没有附加任何权限。

我们现在进行第一步和第二步，在IAM中建立一个角色，并为该角色附加一个S3ReadOnly策略

进入IAM-角色-创建角色，有四个受信任实体的类型选项，我们在之前的视频课程使用过受信任实体为AWS产品-EC2，而这个案例研发人员要在本地调试，显然这个选项无法满足我们这个案例的需求。我们这次要选择受信任实体的类型为“其他AWS账户”，然后输入我们演示的账户的账户ID，大家还记得怎么查吧？在支持-支持中心，然后我们将账户ID复制进去， 然后下一步，附加权限策略我们选择s3readonly，下一步， 角色名称我们叫做stroll,然后创建角色。

现在角色已经创建完成了， 点击新创建的角色stroll，可以看到目前该角色只有一个s3readonly的访问策略，在看一下信任关系，委托人principal的内容为，所有在这个账户ID下的用户，允许执行sts:AssumeRole动作。

我们对比下在之前的课程中的附加到EC2的角色的principal内容，指定的是EC2 service ，我们今天这里指定的是账户arn，这里的区别大家要留意。

好的，我们继续

后面进行第三步，允许用户zhangsan STS Assume Role 权限。

也就是要配置IAM用户zhangsan允许执行STS Assume Role 权限，然后zhangsan就可以承担我们之前创建的stroll角色，使用此角色临时访问凭证只读访问AWS S3

下面我们开始配置第三步。

进入到IAM-用户-zhangsan，为了能够让zhangsan执行STS Assume Role 权限，我们添加一个内联策略，服务选择STS，操作选择assumerole,然后资源这里，我们要选择特定，需要指定允许zhangsan承担的角色的ARN，添加我们之前创建的角色的ARN，下一步，然后策略名称我们就输入AssumeRole，然后完成创建策略。

其实这里有两个策略限制对应的，第一个策略是允许zhangsan这个用户承担我们创建的stroll角色的权限，就是上一步配置的。第二个是在我们前面演示的stroll角色的信任关系中，指定了能够承担stroll角色的可信任的实体内容为所有在这个指定的账号id的用户,包括zhangsan都允许担任该角色，大家还记得吧？
所以大家要记得这两个对应关系。

PPT中的三个步骤我们配置完了，接下来就是要在我本地使用zhangsan用户获取我们创建角色的临时凭证，然后使用临时凭证访问S3。

4、实操演示-验证：

我们开始，切换到我本地的mac电脑终端，使用aws cli ，运行aws sts assume-role命令，为zhangsan用户生成我们创建角色stroll的临时安全凭证。

为了节省时间我已经将命令准备好了，cli命令以及对应的参数说明都可以到AWS的cli命令参考页面查询：

aws sts assume-role --role-arn arn:aws:iam::256454142732:role/stroll --role-session-name stroll。

我们看下这个命令，aws sts assume-role，参数–role-arn后，需要指定要承担角色arn，所以我们指定了我们创建的stroll角色的arn；–role-session-name指定唯一会话名称，我们就指定stroll。

我们现在复制一下命令到我mac终端执行一下，看一下返回结果，命令成功将临时凭证返回，包括accesskey secretkey以及session token等等。

我们现在执行下aws s3 ls，返回access denied ，还是禁止访问。因为我们这个zhangsan的用户，目前拥有的唯一权限策略就是sts:assume role，他本身没有s3相关权限。zhangsan需要通过以上这个aws sts assume-role命令返回stroll角色的临时凭证，然后使用这个临时凭证才可以访问S3。stroll是有s3readonly策略的，大家还记得吧。

所以我们现在编辑下aws credentials文件，将命令返回的临时凭证信息放进去，我们新建一个zhangsansts字段，然后将凭证复制进去。保存退出
然后 执行aws s3 ls --profile zhangsansts

可以看到我们现在可以访问S3存储桶，我们用户案例的演示就完成了。

以上这种授权访问AWS资源的方式是AWS推荐的最佳实践。

在补充一点知识，切换到AWS的assume-role命令参考页面，看一下[—duration-seconds ]参数，可以通过此参数指定临时凭证的过期间隔，默认为1小时，超过间隔后凭证将会轮换。

以上就是我们今天的课程内容，我们今天演示了IAM用户通过sts:assume role的方式，获得角色的临时访问凭证，通过将访问资源的权限附加到角色，然后用户使用临时访问凭证访问AWS资源。这种方式是AWS推荐的最佳实践，将凭证安全维持到了一个很高的级别，而不是通过将持久性凭证分配给用户使用这种粗放的方式。

注意，本课时的内容以及实操演示，其中IAM角色，IAM用户，以及S3存储桶都在同一个AWS账号下，并未跨AWS账号，本课时的内容只是为了帮助大家更好的理解获取角色的临时凭证访问资源。

好的，希望通过今天的课程，能够让大家更熟悉AWS STS服务。

希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问，请联系我们：

• 如果您想获取本课程全部课时，请扫PPT的二维码加入。
• AWS爱好者的网址是www.iloveaws.cn，认证视频课程，免费的认证考试仿真题以及认证课程文章，都可以在网站找得到
• 可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章。
• 加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识。

我们今天的视频课程就到这里，感谢大家的观看，我们下一课程再见。

Hello大家好，欢迎来到《AWS解决方案架构师认证 Professional(SAP)中文视频培训课程》，上节课我们在EC2上通过curl命令，获取了实例元数据中角色的临时凭证。这节课我们将要演示在EC2之外使用这些临时凭证，比如在您本地的电脑或者笔记本，使用生成的临时凭证访问S3，我们开始今天的课程内容，看看它是如何工作的。

登陆到首尔的ec2实例，通过curl命令，获取实例元数据中IAM角色S3ReadOnly的临时安全凭证，然后我们后面要将AccessKeyId、SecretAccessKey以及会话Token复制到我目前使用的mac电脑中的aws的credentials文件中，最终我们要演示通过我本地的mac电脑使用这些临时安全凭证访问S3。

我们先切换到我的mac电脑的终端，看下目前aws的credentials文件内容，可以看到credentials文件内容有之前我们课程使用的凭证，现在已经注释掉了。然后我们执行aws s3 ls 命令，目前无法列出S3存储桶。我们现在将ec2中sts服务为角色生成的临时凭证复制到使用的mac电脑的credentials文件中。

我们编辑本地mac电脑中的credentials文件，新增一个字段，我们取个名字叫ec2role。

然后我们将ec2中的角色临时凭证复制过来，我们已经将AccessKeyId、SecretAccessKey复制过来了，需要强调一点，在credentials文件中，要使用aws_session_token来配置会话token，我们复制一下。

好，现在我们把临时凭证的三个内容已经复制到了本地mac的credentials文件，我们保存一下。

然后运行命令 :

aws s3 ls --profile ec2role

使用–profile指定使用credentials文件中我们刚刚建立的ec2role的凭证。可以看到我们已经成功列出s3的存储桶，我的本地mac拥有和ec2的iam 角色同样的权限。

可能同学们会有疑问，那如果这些临时凭证被用户拷贝到本地使用，或者遗失泄露了，那岂不是会造成安全风险？

其实也不用太担心，因为我们在前面的内容讲到了，sts服务生成的临时安全凭证都会有有效期，有效期就在我们通过curl命令获取元数据时的最下面Expiration内容，过了有效期，临时凭证就会轮换，所以之前的临时凭证也就失效了。

好的，以上就是我们今天的内容，希望通过今天的内容能够让大家对于aws sts服务生成的临时凭证有更深入的理解。

希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问，请联系我们：

• 如果您想获取本课程全部课时，请扫PPT的二维码加入。
• AWS爱好者的网址是www.iloveaws.cn，认证视频课程，免费的认证考试仿真题以及认证课程文章，都可以在网站找得到
• 可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章。
• 加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识。

我们今天的视频课程就到这里，感谢大家的观看，我们下一课程再见。

Hello大家好，欢迎来到《AWS解决方案架构师认证 Professional(SAP)中文视频培训课程》，我们今天的视频课程内容是AWS STS。

STS是IAM角色、联合身份验证的基础，在AWS SAP考试中也会经常遇到AWS STS场景的题目。

我们开始今天的视频课程：

我们在之前的课程已经讨论了IAM角色是如何工作的，我们来复习下。

当前有一个EC2实例和一个S3存储桶，这个S3存储桶代表众多AWS资源之一。EC2想要访问这个AWS资源，有两种方式可以做到。

第一种方式是在EC2中通过aws configure命令配置AWS访问密钥和私有访问密钥后访问资源；

第二种方式是附加IAM角色到EC2实例，然后附加IAM角色策略让我们的EC2能够访问AWS资源。

本节课后面的内容我们主要讨论第二种—通过IAM角色的方式。

通过附加IAM角色访问AWS资源

我们已经创建一个IAM角色，并在这个IAM角色附加了1个策略—S3 ReadOlny，当为IAM角色附加策略后， 我们已将IAM角色附加到EC2实例，这样EC2实例就可以只读访问S3存储桶了。

接下来我们在更深入讨论前，先对上述部分做个演示。

我们登陆aws管理控制台，在首尔区域运行着一台ec2实例iloveawscn，这台实例已经附加了一个iam角色，角色名为S3ReadOnly，我们进入到IAM，看一下这个角色附加的策略，目前有一个策略附加到了该角色，为AmazonS3ReadOnlyAccess策略。

因为目前该IAM角色已经附加到了EC2实例，所以这台EC2实例可以继承该IAM角色的S3 ReadOnly策略。

让我们快速登录到该EC2实例，切换到root，然后执行aws s3 ls命令，可以看到我们有列出S3存储桶的权限，因为该实例附加了角色，而这个角色有S3ReadOnly权限，所以我们可以直接通过EC2只读访问S3存储桶。

以上我们复习了IAM角色的工作方式。

通过metadata检索IAM角色临时安全凭证

我们继续，大家还记得ec2 实例的metadata的知识点吧，我们在这个EC2实例上执行下：

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/S3ReadOnly/

看一下命令以及返回结果。通过curl命令，获得实例元数据条目 iam/security-credentials/S3ReadOnly ，这里的S3ReadOnly就是我们之前附加在这个ec2的IAM角色名称，最终命令检索角色S3ReadOnly提供的安全证书。

我们在看下命令的返回内容，这个命令主要返回三个信息，accessKeyId、SecretAccessKey以及会话Token，还有过期时间，表明以上临时安全凭证在过期时间之后将会失效，我们这台EC2实例，就是使用以上临时安全凭证获得S3的只读访问权限的。

我们也可以将这些安全凭证拷贝到自己本地的电脑，然后在本地电脑通过这个临时安全凭证也可以获得同这个实例一样的只读访问s3存储桶权限。我们在后面的课程将演示其是如何工作的。

我们回到PPT，有一点需要注意的是，我们在这个EC2的meta data中获取accessKeyId、SecretAccessKey以及会话Token临时安全凭证，并不是IAM角色生成的，它们是AWS STS服务生成的，STS是负责提供上述这些临时安全凭证的服务。IAM角色与STS服务之间会建立信任关系，通过STS服务获得这些凭证。

我们来看下，进入到IAM-角色，S3ReadOnly角色，会看到有一个信任关系选项卡，我们点击编辑信任关系看下策略内容：

Principal委托人指定了一个service，ec2.amazonaws.com这个service；
action是sts:assumeRole，整个策略的意思为允许ec2.amazonaws.com服务执行sts:assumerole来获取临时安全凭证。

sts:assumerole这个动作非常关键，如果我们将这部分内容去掉，那么将无法生成访问密钥等安全凭证，ec2也将无法访问s3存储桶。

好的，我希望通过上面的介绍，同学们已经了解，这些存储在EC2角色metadata的临时安全凭证，是由STS服务生成，IAM角色并不负责任何生成安全凭证工作。

我们继续

临时安全凭证知识点

接下来我们花点时间介绍下临时安全凭证。

AWS STS 创建可控制对您的 AWS 资源的访问的临时安全凭证，并将这些凭证提供给受信任用户，在前面的演示中，受信任用户就是附加了角色的EC2实例。

临时安全凭证是短期凭证，可将这些凭证的有效时间配置几分钟到几小时，在一定时间后失效。临时安全凭证一直会保持轮转，过期时间后，旧的凭证将会失效。

使用临时安全凭证，您就不必随应用程序分配或嵌入长期 AWS 安全凭证，我们要知道嵌入长期AWS安全凭证是不安全的。

可允许用户访问您的 AWS 资源，而不必为这些用户定义 AWS 身份。临时凭证是角色和联合身份验证的基础。

一般来讲，安全凭证的轮换在我们日常工作中是一个挑战性的工作，尤其是当我们生成了一个永久访问的凭证时， 出于安全考虑，我们要定期对凭证进行轮换，这样的话即使安全凭证泄露或者被公开，也可以降低安全风险。而使用临时安全凭证，我们就不需要太关注凭证的轮换。临时安全凭证的使用期限有限，因此，在不需要这些凭证时不必轮换或显式撤销这些凭证。临时安全凭证到期后无法重复使用。

好的，以上就是今天的视频课程内容，我们今天介绍了AWS STS服务的基础知识，并演示了通过metadata，获取IAM角色的临时安全凭证，以及介绍了临时安全凭证并不是IAM角色生成的，他们是AWS STS服务提供的，STS是负责提供上述这些临时安全凭证的服务。

希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问，请联系我们：

• 如果您想获取本课程全部课时，请扫PPT的二维码加入。
• AWS爱好者的网址是www.iloveaws.cn，认证视频课程，免费的认证考试仿真题以及认证课程文章，都可以在网站找得到
• 可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章。
• 加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识。

我们今天的视频课程就到这里，感谢大家的观看，我们下一课程再见。

这个是接下来演示采用的架构，上节课已经介绍过了，使用两个AWS账户，在后面的演示中我们统一把左边的账户称为中央账户或者ACCOUNT A，将右边的账户称为ACCOUNT B。我们最终的目标是要让ACCOUNT B的config和CloudTrail日志集中存储至中央账户的S3对应的两个存储桶中。

所以首先，我们现在要做的是在左边的中央账户中创建S3存储桶，我们现在登陆下左边的中央账户管理控制台。

创建存储桶

我们现在已经登陆了中央账户管理控制台，0960是我们中央账户的账户ID后四位

然后进入到S3，开始创建存储桶。

我们先创建一个iloveaws-central-cloudtrail存储桶，负责存储来自其他账户也就是account b的cloudtrail日志。
我们在创建一个iloveaws-central-config的存储桶，也是负责存储来自account b的 aws config日志。

现在两个存储桶就都成功创建了。

创建跟踪

接下来我们要做的是配置将account b的cloudtrail日志转发到存储桶。

切换到account b，打开Cloudtrail控制台，创建跟踪。跟踪名称的话我们个它起一个iloveawscn-account2732，然后到存储位置部分，默认情况下他会创建一个新的存储桶，我们选择否，然后必须指定存储桶名称，我们输入中央账户的存储桶名称iloveaws-central-cloudtrail，在创建跟踪前，我们还需要在做一项配置，我们看下PPT。

我们现在想要将account b的cloudtrail日志转发到account a的central-cloudtrail这个存储桶 ，在转发日志前在中央账户的cloudtrail存储桶要配置相应的的存储桶策略，允许account b 的cloudtrail日志写入存储桶。

所以让我们现在切换到中央账户的s3控制台，进入cloudtrail存储桶，我们需要到权限这里，创建一个存储桶策略。

我们已经提前准备好了策略内容，这个策略我们会附在课程后面，大家可以直接使用。

建立存储桶策略

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “AWSCloudTrailAclCheck20150319”,
“Effect”: “Allow”,
“Principal”: {
“Service”: “cloudtrail.amazonaws.com”
},
“Action”: “s3:GetBucketAcl”,
“Resource”: “arn:aws:s3:::iloveawscn-central-config”
},
{
“Sid”: “AWSCloudTrailWrite20150319”,
“Effect”: “Allow”,
“Principal”: {
“Service”: “cloudtrail.amazonaws.com”
},
“Action”: “s3:PutObject”,
“Resource”: “arn:aws:s3:::iloveawscn-central-config/*”,
“Condition”: {
“StringEquals”: {
“s3:x-amz-acl”: “bucket-owner-full-control”
}
}
}
]
}
我们现在将策略复制到这里，策略要做一些修改，在复制完成后你需要修改resource部分,将这里替换为您的存储桶的arn,arn
在策略的上方。我们现在替换下，注意要替换两个位置，还要注意一点的是，在putobject的arn地址后面，需要保留斜杠和星号，否则会出问题，然后我们保存策略。

我们在看下策略内容，策略定义了两个动作，允许GetBucketAcl和s3:PutObject。然后principal委托人，我们配置的内容为cloudtrail.amazonaws.com，配置的是cloudtrail的一个dns域名，这对于cloudtrail是可以工作的。如果你有一个EC2在其他账户，然后想要在中央账户中保存日志，您就必须在这里指定account id。在这个演示案例中，我们指定了principal是AWS 的cloudtrail服务，不需要明确指定账户id。

接下来我们复制这个策略，将策略附加到另一个s3存储桶中，也就是用于保存aws config日志的存储桶。
复制完成后我们修改下策略中的service内容，将它修改成config.amazonaws.com。然后将resource的arn修改为这个存储桶的arn，我们复制一下。同样注意putobject的resource地址的最后面要保留/*，然后保存。

好的，现在我们有了2个存储桶，分别作为存储其他账户也就是account b的aws config和cloudtrail日志，而且我们分别为两个存储桶创建了存储桶策略，策略的内容是允许cloudtrail和config日志存储至相应的存储桶。

现在我们再次切换到accout b 账户，回到创建跟踪步骤，我们之前已经填入了中央账户的存储桶名称，我们继续，创建。
创建完成后会在跟踪这里出现创建的跟踪的详细信息。现在cloudtrail就配置就配置完成了。

配置 AWS Config

接下来我们快速配置下AWS config的日志部分
来到AWS config控制台，开始配置

在S3存储桶配置部分，可以创建存储桶，可以选择在现在这个账户的已经存在存储桶，可以从另外账户选择存储桶，我们选择第三个，然后输入我们在中央账户创建好的用于存储config的存储桶名称：，下一步，跳过规则，下一步然后确认。

资源发现需要一些时间，我们现在就已经配置完成了，让我们切换到中央账户

以上，我们完成了cloudtrail和config日志的配置，现在我们要做的是到中央账户s3中，看一下日志的生成情况。

检查日志转发情况

进入到中央账户S3控制台，先进入到config存储桶，我们看到有一个新建的AWSlogs文件夹，进去后会看到发送config 日志的账户的账户id，就是我们account b的账户id，在继续会发现一个checkfile。在aws config配置中指定存储桶后，aws config会生成一个checkfile到这个存储桶中，用以检测所需相应的权限是否已经正确配置。所以当我们配置完成后，如果能看到存储桶中已经正确生成了checkfile,说明我们的配置是没有问题的，当有新的config日志生成发送到我们中央账户存储桶时，也一样能够正确的写入并存储。所以checkfile是一个快速确认配置的一个方式。因为生成account b 的config日志还需要等待一些时间，我们这里就没必要等了。

同样我们来到中央账户用于集中存储cloudtrail的S3存储桶ioveaws-central-cloudtrail，然后依次进入目录，可以看到已经有从我们的其他账户也就是account b的cloudtrail日志生成并写入到中央账户的存储桶了。我们已经在中央账户的两个存储桶中成功的收到了来自其他账户也就是account b的cloudtrail和aws config日志。

以上就是我们今天的课程内容， 我们演示了配置clouidtrail和aws config日志，实现了跨aws账户日志存储，将其他账户的日志存储到了中央账户存储桶。

希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问，请联系我们：

• 如果您想获取本课程全部课时，请扫PPT的二维码加入。
• AWS爱好者的网址是www.iloveaws.cn，认证视频课程，免费的认证考试仿真题以及认证课程文章，都可以在网站找得到
• 可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章。
• 加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识。
• 我们今天的视频课程就到这里，感谢大家的观看，我们下一课程再见。

我们开始今天的内容。

集中式日志存储架构

当前，在绝大多数组织中，日志的管理和分析都被列为 是非常核心的任务。它使组织能够更加了解业务运营情况、安全性、变更管理、各事件之间的关系等，可帮助持续对整个组织的架构运转情况全面的掌控。

一般来说，当讨论的是AWS时, 需要我们关注的日志服务有 像AWS Cloudtrail ,VPC flow 日志，aws config日志，可能还会有来自EC2的日志等等，因此，将所有AWS账户的日志转发到一个作为中央区域的账户的S3存储桶，集中管理和存储是非常有必要的。然后可以在这个中心区域分析整个组织的日志，也可以使用splunk等工具从S3存储桶中获取日志，进行安全、审计、监控、排错等其他的需求分析，通过单一的节点实现所有管理的AWS账户的日志存储、分析、监控需求。

实现集中日志架构注意事项

我们先看下在实现集中式日志架构时，需要考虑的一些注意事项。

首先，尽早定义日志所需保留时间等要求，以及日志生命周期策略，这对于您的组织在遵循某种审计、合规政策时显得更加的重要，对于不同的日志类型对应不同的日志保留要求是非常常见的。我们假设有一个日志需要保留5年，就要确保如果您把日志存储到了一个集中的中央账户的S3存储桶，你要确保日志将在存储桶中保留5年且不会被自动删除。

同样，生命周期策略也是同样重要，尤其是出于成本因素考虑的时候。比如，当组织的某个应用程序产生了重要的日志，并需要集中存储时，数据达到了TB级别，我们可以先分析一下后续对于此日志的需求，评估后续日志的检索次数和对于检索时间的要求，根据这些需求您可能不需要一直将全部TB级别的日志放在S3存储桶，可以将大部分日志转移至glacier满足您的需求并为您节省很多的成本，这一点恰好就是生命周期策略起到重要作用的地方。

第二个 是生命周期策略要自动化执行，比如上面提到的程序日志，将产生时间在1个月内的日志保存在S3中，以便在程序出现问题或其他需要的时候快速，高频进行检索；当在S3保留时间超过1个月后，将所有旧的应用程序日志自动转移到glacier以节省大量的成本。这些应该是自动化执行不需要我们人工去干预的。

第三点是我们的系统要能够自动化安装和配置日志传输代理程序。假设你有ec2实例在autoscaling环境，在后半夜一个新的ec2启动了，你需要确保这个新启动的实例的应用程序日志或者服务器日志，也要传输到S3存储桶中。要实现这个需求，就需要确保日志传输代理程序自动安装在了这个新启动的实例上。取决于不同的环境案例，可以将其在UserData实现，或者也可以将它集成在AMI中。

这个很好理解吧？因为如果您使用了autoscaling，非常可能发生的一个情况是一个EC2实例在后半夜因扩展规则自动启动，然后在运行一段时间比如当cpu使用率降低后这个新启动的实例又被终止了，如果您没有自动安装和配置日志传输代理程序，那么这个新启动的实例上的日志将会丢失。

最后一点是确保您实现的解决方案支持混合云架构。当前出于安全考虑企业更愿意将数据存放在本地私有云中，但是同时又希望可以获得公有云的资源，在这种情况下，现在很多组织都在朝着混合云架构方向发展，既拥有私有云，又同时使用多家公有云，如AWS ，阿里云等，所以不管你采用的什么解决方案，确认它支持混合云架构。

这是集中日志架构的一些注意事项。

AWS日志相关服务

因为我们的课程是AWS认证课程，所以我们需要了解如何使用AWS托管服务来构建集中式日志解决方案。
AWS提供了很多服务帮您构建，如AWS ElasticSearch Service、AWS S3、AWS CloudWatch servcie 、Kinesis Firehose等等

需要说明的一点是，在AWS中，在配置集中式日志存储方案时，以上提到的服务的配置方式都是不同的，比如配置CloudTrail服务构建集中式日志解决方案的方式是和VPCflow配置的方式是不同的，需要注意。

集中式日志存储实现快速演示

接下来我们快速演示下集中式日志存储架构。
我们介绍下演示的架构，使用两个AWS账户，在后面的演示中我们统一把把左边的账户成为中央账户或者ACCOUNT A，将右边的账户成为ACCOUNT B。我们将ACCOUNT B的config和CloudTrail日志集中存储至中央账户的S3对应的两个存储桶中。

当然，这个架构是只是使用了2个账户的架构，您的组织中可能还存在着account c,d,e，分别可以配置这些账户将对应的日志转发至中央账户的S3存储桶中集中存储，实现集中式日志存储架构。

登陆ACCOUNT A ，查看日志生成情况

我们现在登陆了中央账户account A，我们使用这个账户负责集中式日志存储。
打开S3控制台，可以看到有两个和本次演示相关的S3存储桶，iloveaws-central-config和iloveaws-central-cloudtrail,负责存储来自不同账户ACCOUNT B对应的aws config和cloudtrail日志。

我们快速打开ioveawscn-central-cloudtrail存储桶，可以看到来自另外一个aws账户ACCOUNT B的CloudTrail日志已经成功转发过来了，在s3存储桶中是按照账户id目录进行存储的，这个2732数字的文件夹就是account b的账户id。

登陆ACCOUNT B

我们切换到账户account b浏览器，我们看下ACCOUNT B账户id,和刚才在中央账户中的cloudtrail存储桶的文件夹的账户id是一样的。也就是说目前中央账户的s3存储桶中已经存储了来自不同AWS账户的ACCOUNTB的cloudtrail日志。

下面我们进入到account b的cloudtrail控制台，进入跟踪，我们看下我们已经创建好的配置。在存储位置部分，可以看到我们已经完成 将中央账户的s3存储桶ioveaws-central-cloudtrail配置到了cloudtrail配置的存储位置。

完成这一步后还无法成功转发日志到中央账户的s3，因为S3要开放相应的策略允许它访问。

登陆ACCOUNTA，查看存储桶策略

我们切换到中央账户的这个S3存储桶，我们提前配置好了存储桶策略，策略的作用是允许account B的cloudtrail日志转发写入这个存储桶。这里显示了具体的存储桶策略的内容，我们指定了cloudtrail.amazonaws.com这个aws service允许对这个存储桶GetBucketAcl ，PutObject行为，这个策略内容我之后会附到课程后面，大家直接复制修改后就可使用。

以上是cloudtail对应的配置演示。

我们前面演示了CloudTrail如何配置构建集中式日志存储，参照配置，可以将组织中所有账户的cloudtrail日志转发到中央账户的S3存储桶中集中存储。前面提到过不同的AWS服务（CloudTrail，VPCFlow）构建集中式日志解决方案的配置方式各不相同。同样cloudtrail和aws config的配置方式是不同的，我们下面将快速演示下aws config 日志如何配置构建集中日志存储。

我们回到中央账户的s3控制台，打开用于存储config日志的iloveawscn-central-config存储桶，我们同样可以看到来自于不同账户account b的aws config日志已经成功写入存储桶中

登陆ACCOUNT B

我们切换到account b打开aws config控制台，进入设置，查看s3存储桶配置部分，同样，可以看到我们已经将中央账户的s3负责存储config日志的存储桶名称配置到了这里。

为了将accountb的aws config日志转发到中央账户相应的存储桶中，我们同样要为config日志的存储桶配置存储桶策略，我们切换到中央账户的s3控制台，打开存储桶策略，我们看下我们已经配置策略的内容，基本上和前面cloudtral的策略差不多，Service这里我们改成了config.amazonaws.com。

好的，以上就是我们今天的课程内容， 我们下节课将从头开始配置本节课的快速演示内容，配置CloudTrail和aws Config日志实现跨AWS账户日志存储。

希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问，请联系我们：

• 如果您想获取本课程全部课时，请扫PPT的二维码加入。
• AWS爱好者的网址是www.iloveaws.cn，认证视频课程，免费的认证考试仿真题以及认证课程文章，都可以在网站找得到
• 可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章。
• 加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识。

我们今天的课程就到这里，感谢大家的观看，我们下一课程再见。

演示环境

为了演示我们准备了两个AWS账户，左边的账户我们使用safari浏览器登陆，准备创建组织，作为主账户；

右边的账户我们使用google chrome浏览器登陆，作为加入组织的成员账户。

我们现在已经分别使用根账号登陆了两个AWS账户，然后通过管理控制台右上角，我们分别可以看到两个账户对应的账户ID

创建组织

我们要在左边的这个账户上创建AWS组织，我们现在打开AWS Organizations管理控制台，点击创建组织。

默认情况下，组织在创建时已启用所有功能，包括整合账单功能。您也可以创建自己的组织并仅启用整合账单功能。

我们的演示选择创建启用所有功能的组织，选择后点击创建组织。

好的，现在组织已经创建完了，这里会看到一个默认账户作为主账户，也就是我们当前的AWS账户。

我们要使用AWS组织的整合账户以及策略控制功能，我们就需要添加其他账户进来作为成员账户，点击添加账户，

在这里可以邀请现有账户，以及创建新的账户，因为我们已经有一个想要作为成员账户的AWS账户，所以我们选择邀请现有AWS账户。

邀请账户加入组织

在电子邮件或者账户ID输入框中输入您要邀请的账户信息，我们将google chrome浏览器的账户id复制进来，邀请它加入组织。

这里要说明一个情况，也是大家可能会遇到的一个问题，如果您的AWS组织是刚刚创建的，AWS需要一段时间进行初始化，AWS官方的说明是需要1个小时，但是在实际的情况中很多反馈都需要24小时以上才能完成初始化。如果AWS没有初始化完成，在你进行邀请账户的时候，可能会提示“您超出了组织的账户限制或因组织仍在初始化而无法添加账户或类似的信息，如果您遇到了这个问题且等了很久还是这个提示，需要联系 AWS Support解决。

我们现在已经向2732这个账户成功发送了邀请，我们现在要做的，切换到google chrome浏览器。

进入到AWS Organizations管理控制台。

会看到有一个新的邀请，点击查看1个邀请，可以看到这个邀请的详细信息包括组织ID等等，以及该组织已启用所有功能，可以完全控制您的账户的说明，然后点击“接受邀请”。

当完成后，我们切换到主账户浏览器，刷新下，可以看到刚刚添加的账户已经成功加入了AWS组织。

整合账单

我们看下aws组织整合账单功能是否启用。

我们在切换到成员账户的浏览器，访问我的账单控制面板-整合账单，会跳转到AWS Organizations的控制台，提示此成员账户加入了的组织的详细信息以及已经启用了所有功能包括通过整合账单来为其付费。

说明整合账单功能已经成功启用了。

这样就实现了整合账单功能，在主账户上查看组织的账户的账单及统一支付账单，我们就不在这里演示了。

策略控制

好的，我们接下来开始策略控制内容，首先我们配置一个服务控制策略，然后将它应用到我们的成员账户，最后使用root账户登录成员账户，看一下策略生效情况。

我们现在开始配置策略，切换到在主账户浏览器，进入AWS Organizations管理控制台，策略—选择服务控制策略 ，然后启用服务控制策略。可以看到当前有一个FullAWSAccess策略，这个策略是默认策略，会附加到每个根、OU 和账户，策略内容是允许所有操作和所有服务。

我们开始创建策略，点击创建策略，我们将创建一个禁止访问s3的策略。

策略名称，我们输入denys3；然后策略部分，选择要添加操作的服务，选择S3,然后我们选择all actions。

添加资源,服务选择S3,资源类型选贼all resources, 添加。确认下策略的内容，没有问题，创建。

这样我们的策略就创建完成了，我们现在把这个策略附加到成员账户。

回到AWS组织的账户页面，点击成员账户iloveaws，然后选择策略选项卡。

看到了目前应用的策略，FullAWSAccess策略，默认会附加到成员账户，可以点击附加添加刚才我们创建的denys3策略。

在我们附加denys3策略前，我们先使用root用户登录成员账户，看下现在是否能否访问S3

我们切换到成员账户的浏览器，进入到S3,可以正常访问S3

接下来，我们在主账户的AWS组织管理控制台，将denys3策略附加到成员账户上。

附加后，现在成员账户应该无法访问S3服务，我们切换到成员账户浏览器，我们使用的是根用户登录的，访问下s3，无法访问。。。

所以，如果在aws组织主账户中附加了一个策略到成员账户，即便是成员账户的root用户，也会受到这个策略的限制。

好的，希望大家能够通过今天的内容熟悉了AWS Organizations服务，它是一个非常棒的服务，通过整合账单或者策略控制能够为您的组织带来很多帮助。

您也可以通过AWS组织的服务控制策略，为企业多账户环境提供安全保障，比如，创建策略内容为禁止所有成员账户禁用aws cloudtrail服务，然后将所有成员账户的cloudtrail操作日志都集中存储至一个中央S3存储桶，集中存储和分析账户的操作日志。希望AWS Organizations能够帮助您在AWS上构建您所需安全控制及安全体系。

以上就是我们今天的课程内容， 我们从头开始创建了aws组织，并邀请账户加入组织，演示了整合账单以及策略控制内容。在当前的AWS SAP认证考试中，AWS Organizations的题目在考试中出现的几率非常高，尤其是服务控制策略部分，考试中会对服务控制策略的应用场景和IAM有什么不同？或者策略应用到成员账户后根用户是否受到策略的影响，会将这些知识点虚拟一个场景出来，考察考生。

好了，希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问，请通过以下方式 请联系我们：

• 如果您想获取本课程全部课时，请扫PPT的二维码加入。
• AWS爱好者的网址是www.iloveaws.cn，认证视频课程，免费的认证考试仿真题以及认证课程文章，都可以在网站找得到
• 可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章。
• 加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识。