【 Domain 2-新解决方案设计】——-IAM策略评估逻辑（IAM Policy Evaluation Logic）

Hello大家好，欢迎来到《AWS解决方案架构师认证 Professional(SAP)中文视频培训课程》，我们今天的视频课程内容是 AWS IAM策略评估逻辑。当你在调试IAM策略相关的问题时，理解这部分内容非常重要的。

接下来，让我们来了解下IAM策略是如何进行评估的。

策略决策图

我们来看一下这个策略决策图，这个图是我引用自AWS官方文档。包括了几乎所有AWS策略相关，比如组织 SCP、基于资源的策略、IAM 权限边界、会话策略以及基于身份的策略。

看着比较复杂，不过在实际环境中，通常都是根据组织的实际控制需求选择要使用的策略，而对于我们这节课内容来讲，主要了解第一块 “拒绝评估” 以及最后 “基于身份的策略” 部分内容，我们简化下这个决策图。

策略决策图（1，2步解析）

好，接下来我们来了解下决策过程。

首先，Decision starts with Deny，在AWS，所有的访问比如访问S3存储桶，或者是启动EC2实例等，默认情况下这些请求都会被拒绝，默认的情况下，所有请求都被拒绝，这称为隐式拒绝。

在默认所有请求都被拒绝之后，进行到第二步，开始评估附加到用户或IAM策略。因为这部分内容非常重要，我们在继续下部分内容前，先对这两步做个演示帮助大家理解。

策略决策图（1，2步演示）

切换到aws管理控制台，进入IAM-用户，我们现在有一个IAM用户iloveaws，进入到权限选项卡，可以看到没有相关S3的访问策略。我们切换浏览器，使用iloveaws这个用户登陆控制台后，访问一下S3管理控制台，可以看到是拒绝访问的。

大家应该想到为什么会出现访问被拒绝，正如前面所讲，在策略决策图第一步，策略决策开始时，默认情况下，所有请求都被拒绝，然后，在我们访问S3控制台时，实际发生的是，通过检查附加到iloveaws用户的策略，发现iloveaws用户没有附加相关允许S3的访问的策略，所以访问S3被拒绝。

我们接下来给这个用户附加s3的访问权限，添加完成后，我们看下这个策略内容，在策略中已经明确允许两个动作S3 GET以及S3 LIST。然后我们切换到iloveaws用户再次访问S3，我们刷新下页面，现在已经可以访问S3存储桶了。

总结下刚才的演示，我们使用iloveaws用户访问S3，首先，策略开始时默认请求都被拒绝，然后进行到策略评估第二步，评估附加到iloveaws用户策略，因为刚才我们附加了一个允许访问S3的策略到iloveaws用户，所以最终用户允许访问S3。这就是策略评估逻辑工作的过程。

显式拒绝

好的，我们继续，首先默认情况下请求都会被拒绝，第二步代码随后会检查附加到用户的策略，随后第三步，代码将要检查在策略中是否有应用于请求的 Deny 语句。应用于请求的deny语句，这称为显式拒绝。

如果策略中有显式拒绝出现，则整个请求被拒绝。如果没有显式拒绝， 有允许请求的语句，则将最终决定允许。

同样，为了帮助大家理解，接下来看一个演示案例。

假设现在我们有5个可用的S3存储桶，之后还会新建存储桶，想要达到目的为允许所有存储桶的访问，包括后续新增的，但是要拒绝第五个存储桶的访问请求。

为了达到这个目的，只需要两个步骤，第一步是配置允许所有S3存储桶的访问， 这样的话所有访问存储桶的请求都会被允许。

第二步，配置显式 拒绝访问第五个存储桶策略。这样即使在未来，又新创建了10个S3存储桶，在配置以上2个策略的情况下，同样用户除了无法访问第五个存储桶，其他的存储桶包括新创建的都允许访问，这样的话就可以满足上述的允许所有存储桶的访问，但是要拒绝第五个存储桶的访问的需求。

同样，我们来做个演示。

切换到IAM-iloveaws用户，删除之前添加的策略，然后为了完成上面的场景演示，我们为iloveaws添加一个新的策略，然后直接附加现有策略，搜索S3，选择S3FullAccess策略，然后完成策略添加。S3FullAccess策略内容为允许S3的所有访问权限， 这样我们就完成了上面PPT的第一步，允许访问所有S3存储桶。

接下来我们配置第二步，配置显式 拒绝访问第五个存储桶策略。

我们先切换到S3控制台，我们刚才已经配置了iloveaws用户允许访问所有当前的这几个存储桶的访问，现在要进行第二步配置，配置显式 拒绝访问第五个存储桶策略，对应的我们演示的iloveawscn5这个存储桶。最终我们要达到的目的是允许iloveaws用户除了拒绝访问iloveawscn5这个存储桶，其他的存储桶都被允许访问。

所以我们在添加一个策略，我们这次使用策略编辑器添加，希望大家能够熟悉策略编辑器的使用方式。服务选择S3,然后勾选所有S3操作，我们要添加显式拒绝策略，所以点击“切换以拒绝权限”， 然后添加资源，我们现在要拒绝iloveawscn5这个存储桶访问，所以需要在资源这里通过添加存储桶iloveawscn5的ARN,然后输入存储桶名称iloveawscn5。然后为策略取个名称，我们就叫denys3bucket,然后创建策略。

在附加策略前，我们还要对策略内容进行调整，看下我们创建的denys3bucket策略内容，前面的策略内容将resource为*的一些S3动作拒绝了，而我们只需要对resource为iloveawscn5这个存储桶显式拒绝，所以我们手动删除下上面的内容。

拒绝所有S3的动作，然后指定的资源是iloveawscn5这个存储桶。我们把这个策略附加到iloveaws用户。

看下现在iloveaws用户策略的情况，目前S3相关有两个策略，一个是允许所有S3访问的策略，另一个是我们刚才创建的拒绝访问iloveawscn5存储桶访问策略，我们看下现在存储桶访问的情况。

切换使用iloveaws这个用户，进入到S3控制台，进入iloveawscn5存储桶，发现拒绝访问，然后访问下其他存储桶，是可以成功进行访问的。我们在继续做个测试，编辑我们刚才创建的denys3bucket策略，然后将resource的内容修改为*，保存。

然后我们看下目前iloveaws用户策略的情况，目前有2个S3相关的策略，一个是允许所有S3访问的策略，另一个刚才修改后是拒绝所有S3访问的策略，那现在大家想一下，在附加这两个策略的情况下，哪个策略的优先级比较高会生效呢？

我们切换到iloveaws用户，进入到S3，刷新后发现，目前S3存储桶已经拒绝访问了。这意味着，添加的显式拒绝策略的优先级高于允许策略，所以大家要记住，在对同一个资源同时配置了允许和拒绝策略时，拒绝策略将会生效，这一点非常重要。

让我们回到策略决策图，当策略中有显示拒绝时，那么将最终拒绝请求；如果没有显示拒绝时，如果有允许语句，则最终允许请求。如果没有允许所请求的操作，则请求最终会被隐式拒绝。

以上就是IAM策略决策的过程，通过以上讲解，希望同学对这部分内容有所了解。

最后，我们看下显式拒绝和默认拒绝之间的区别。

如果没有允许访问该资源的策略，那么这个请求默认是会被拒绝的。比如一个用户如果没有附加任何S3策略，这个用户试图访问S3控制台时，这个请求默认被拒绝，这就是默认拒绝。

显式拒绝的话，我们在上面的演示中，对于iloveawscn5这个存储桶，我们创建了策略，且在策略中明确指定了拒绝语句， 拒绝该存储桶的访问，这个就是显式拒绝。

好的，以上就是我们今天IAM策略评估逻辑内容，希望通过这堂课的讲解和演示让大家对于IAM策略的评估逻辑内容有所掌握。

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

AWS爱好者的网址是www.iloveaws.cn。
可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章
加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识
加入【AWS知识星球】持续学习。

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

【 Domain 2-新解决方案设计】——-理解最小权限原则（Understanding Principle of Least Privilage）

Hello大家好，欢迎回来，我们今天的课程内容是 最小权限原则，对于解决方案架构师或者安全工程师来讲，在分配访问权限时这是需要遵循的一个非常重要的原则。

让我们来看下什么是最小权限原则。

根据定义，最小权限是指每个程序和系统用户都应该具有完成任务所必需的最小权限集合。因此，对于系统管理员而言，一个用户应该只能访问履行他的相关职责所需 访问的数据和硬件。

所以，假设一个开发人员如果希望访问特定的日志文件，那么他的权限就应该只具有访问这个特定日志文件的权限，他不应该能够做其他的操作，去获得未经授权的额外信息。

赋予每一个合法动作最小的权限，就是为了保护数据以及功能，避免受到错误或者恶意行为的破坏。

然而，在大部分组织实际的工作中，真正的普遍情况是，当一个开发人员或者其他相关人员请求开通访问权限时，系统管理员或者解决方案架构师都是盲目的提供了访问权限且没有限制，这样就导致了在组织内部有很多的漏洞，极有可能会造成重大安全风险。

接下来我们看一个简单的案例。

您的组织来了一个新的实习生，名为张三，岗位是实习系统管理员。组织的基础设置托管在AWS，您需要让这个实习生通过访问查看AWS管理控制台尽快熟悉岗位工作内容，要问的问题是，您会给他分配哪种类型的访问权限？有三个选项，

1. 第一个是你和他共享AWS的ROOT凭证，这种方式可以肯定能满足需求；
2. 第二个选项，给他建立一个新的张三用户，并分配完全访问权限，如果比较第二个选项和第一个选项，你会发现第二个选项好一些，因为我们在设计用户权限的时候，尽量不要共享凭证，也就是说不要和其他用户使用一套用户登陆凭证，因为这样当需要的时候很难对具体使用者的操作和行为进行追踪，因为大家用户公用嘛。
3. 第三个选项，建立一个新的张三用户，并分配只读访问权限，对于这个案例，很显然这个选项就足够了满足需求了。

所以您要了解，每当有人像您请求访问权限时，您只需要提供给他匹配他需求的权限。

我在给大家举个例子，我之前就职过的一个组织，这个组织对于系统安全方面要求非常高。当研发人员有访问指定服务器上的文件需求时， 首先必须写明原因并经过经理的审批，经理会评估研发人员的访问请求是否有必要，并询问想要访问文件具体的服务器、路径、文件名等信息，以及需要运行的命令等。

比如，开发人员需要说明他需要访问哪台服务器上的哪个日志文件，比如某一个IP的服务器上abc.log文件进行排查问题，需要使用tail、less两个命令，然后审批通过后，系统管理员只会分配给他们访问那台特定服务器的特定文件，以及只分配使用tail、less这两个命令的权限，这就是分配最小权限的一个案例。

好的，以上就是我们的今天的视频课程内容，今天介绍了最小权限原则，我们在后面用户策略等课程中会更详细的讨论这部分内容。

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

• AWS爱好者网址：www.iloveaws.cn
• 可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章
• 加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识
• 加入【AWS知识星球】持续学习。

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

【 Domain 1的组织复杂性设计（Design for Organizational Complexity）】——-将LINUX系统日志内容推送至CloudWatch（Pushing Linux system logs to CloudWatch）

Hello大家好，欢迎回来，我们今天的课程内容是CloudWatch日志。在这节课我们进行实操演示，推送LINUX系统的系统日志内容至CloudWatch的日志组。

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

在演示之前，先介绍下后面演示的架构。

我们已经在东京区域启动了一台EC2，我们后面要将这台EC2的系统messages日志内容，发送至位于中央区域的CloudWatch日志组，这样的话，研发人员或者需要访问这个日志的人员，只需要访问CloudWatch日志组，就可以查看/检索EC2的messages日志内容，当然，我们只是拿messages日志举例，您同样可以配置将运行在EC2中的应用程序的日志内容推送至CloudWatch日志组。

为了达到这个目的，我们需要完成以下配置：

• 首先，为EC2分配IAM角色，作用是允许EC2创建日志组且将日志内容发送至日志组等权限。
• 其次，在EC2上安装和配置CloudWatch logs代理。
• 最后，启动CloudWatch logs代理。

以上都完成后，EC2的messages日志自动从实例流向您在安装代理时创建的日志流。代理会确认它已启动，并保持运行状态，直到您禁用它为止，之后就可以在CloudWatch日志组中查看到EC2的messages日志的内容了。

那我们就开始配置吧，第一步，为EC2分配IAM角色，以允许EC2创建日志组且将日志发送至日志组等权限。

第一步：为EC2分配IAM角色

首先让我们先来到东京EC2的管理控制台，可以看到目前我们将要用于测试的这台EC2是没有分配IAM角色的，所以现在我们要为它分配IAM角色。

访问IAM控制台，角色-创建角色，然后附加策略，搜索CloudWatchAgentServerPolicy，然后附加到角色。然后为角色起个名称，我们就叫做CloudWatchAgentServerRole，然后完成创建角色，这样的话IAM角色就创建完成了。

然后我们回到EC2管理控制台，将创建的这个角色附加到EC2上。我们选择EC2，然后实例设置，附加IAM角色，完成附加角色。

我们看下角色附加的这个策略的内容，CreatLogGroup，允许创建日志组以及PutLogEvents允许将日志内容从操作系统推送至创建的日志组等等。

好的，我们现在就完成了第一步的配置，为EC2分配IAM角色，以允许EC2创建日志组且将日志发送至日志组等权限。

我们继续第二步配置，，在EC2上安装和配置CloudWatch logs代理。

在此之前，我们先访问下cloudwatch控制台，东京区域，可以看到目前是没有日志组的。

接下来切换到终端，开始第二步配置，在EC2上安装和配置CloudWatch logs代理，代理的作用的推送EC2日志内容至Cloudwatch。

第二步：在EC2上安装和配置CloudWatch logs代理

切换到终端，登陆东京EC2，我使用的是amazon linux 2操作系统，所以可以使用yum安装cloudwatch logs 代理。

如果您使用的是其他版本的linux，安装 CloudWatch Logs 代理的过程取决于EC2 实例是运行 Amazon Linux、Ubuntu、CentOS 还是 Red Hat。请根据实例上的 Linux 版本采用适当的步骤，这些步骤可通过查阅AWS官方的文档获得。

我们继续，通过yum方式安装cloudwatch logs 代理，输入命令yum install -y awslogs，awslogs是代理程序的软件包名称。现在awslogs这个代理已经安装完成了。

下一步，我们就要对 CloudWatch Logs 代理进行配置，首先我们先来到awslogs配置文件的目录 /etc/awslogs/ ，我们主要需要关注awscli.conf awslogs.conf这两个配置文件，首先我们先来看一下awscli.conf 这个文件，这里可以指定创建日志组的aws区域，我们将其修改为东京区域ap-northeast-1，然后保存退出。

我们在看一下另一个配置文件 awslogs.conf，vim awslogs.conf ，然后我们看下最后面的内容，默认有一个/var/log/messages配置，这个配置会建立一个日志组，名称为/var/log/messages，这个日志组对应的文件是系统的messages日志，这是默认就存在的配置，当然您也可以在这里添加更多的日志，比如应用程序日志，将其相应的信息填到此配置文件中，CloudWatch Logs 代理就会将其内容推送至cloudwatch控制台。

我们这个演示不在添加日志了，就使用默认配置，将EC2系统中的messages日志内容推送至cloudwatch日志组。

第三步：启动CloudWatch logs代理

好，第二步完成了，我们进行最后一步，运行CloudWatch Logs 代理,systemctl start awslogsd，然后看下运行情况，现在代理已经是running的状态了

CloudWatch Logs 代理程序启动后生成的日志文件在/var/log/awslogs.log，可以通过tail -f 来查看。

好的，现在已经完成了配置并启动了CloudWatch Logs 代理程序，现在让我们切换到cloudwatch控制台，进入到日志组。

查看CloudWatch 日志组

目前我们可以看到一个名为/var/log/messages的日志组，EC2系统的messages日志内容已经成功发送过来了。

这个日志组就是之前我们在CloudWatch Logs 代理配置文件awslogs.conf中那个默认的日志组，让我们在切换到终端，看下CloudWatch Logs 代理的配置文件awslogs.conf，如果您还需要将应用程序日志内容推送至cloudwatch，只需要在这里新增配置内容，将应用程序日志内容配置成推送至不同名称的日志组，比如applications日志组。

这样的话在cloudwatch控制台(切换到cloudwatch控制台)，就会生成不同的日志组，您就可以针对不同的日志组分配权限，比如应用程序日志组分配给对应研发权限，方便研发人员排查BUG；而系统messages日志组，您可以将其查看权限分配给对应运维人员。通过将不同的日志内容推送到不同的日志组然后将查看不同的日志组权限分配给不同的人员，这是一个很好的实践。

好的，以上就是今天的内容，我们进行实操演示，推送LINUX系统的系统日志内容至CloudWatch的日志组，希望对您有所帮助。

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

• AWS爱好者网址：www.iloveaws.cn
• 可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章
• 加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识
• 加入【AWS知识星球】持续学习。

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

【 Domain 1的组织复杂性设计（Design for Organizational Complexity）】——-理解CloudWatch Logs

Hello大家好，欢迎回来，我们今天的视频课程内容是理解CloudWatch Logs，我们开始今天课程内容。

将日志的内容集中存储

无论我们的服务器运行着是windows还是linux操作系统，每个操作系统都会产生日志文件。服务器可产生很多类型的日志文件，如系统日志、安全日志，如果您的应用程序在系统中运行，可能还包括应用程序产生的日志。

当应用程序遇到问题需要调试的时候， 就需要访问日志文件，一般会怎么做呢？因为日志文件生成并存储在服务器中，如果要调试应用程序，调查程序BUG，就需要访问服务器。

让我们举个例子，假设有个php程序运行在linux服务器上，出于某种原因，这个php的应用程序没有按照预期的情况正常运行，开发人员想要查看日志文件，这时候该怎么办？在这个场景下很多组织都是为开发人员分配了SSH权限，然后开发人员SSH服务器后查看日志调试。

这当然不是一个很好的安全实践，可能会造成不可控风险等。当前很多组织中，都会建立并遵循开发/部署流程和规范，并不会分配开发人员直接登录生产环境的服务器权限，也就是说开发人员无法访问服务器，那在这种情况下，开发人员怎么通过服务器上的日志文件进行调试排查问题呢？答案是集中式日志存储架构，将日志文件从系统中拉取并放置一个中心区域集中存储，并提供给开发人员查看/调试。

将/var/log/messages日志内容推送至cloudwatch日志组快速演示

为了让大家更好的理解，我们下面在举个例子。

切换到终端，我已登陆一台东京的EC2，进入到系统的/var/log目录，可以看到目录里面有很多日志文件。

假设我们要使用/var/log/messages日志来调试，一种方式是，像我现在这样手动ssh登陆到这台服务器上，然后通过tail、grep等命令，对messages日志进行检索并查看与排查问题相关的记录，并定位问题。然而，前面讨论过，最理想的方式是将这个文件推送到中心区域，然后在中心区域检索日志。

因为我们这节课是CloudWatch logs内容，针对以上这个场景，我在EC2上安装了CloudWatch logs代理，通过CloudWatch logs代理，将EC2中的messages日志内容推送至cloudwatch 日志组，然后可在cloudwatch日志组中检索日志，我们已经将上述的环境和服务都配置好了，现在快速演示下。

我们现在打开cloudwatch控制台，打开日志组，我们会看到一个/var/log/messages日志组，进入后是我之前登陆的EC2实例ID，然后可以看到刚刚登陆的那台EC2中的/var/log/messages日志所有内容，全部在这个日志组里面。

以上，我们只是拿messages日志举例，同样，在实际环境中，您也可以推送所有服务器上的应用程序的日志至一个中央区域日志服务器，这个中央区域日志服务器可以是cloudwatch，可以是rsyslog，也可以是EasticSearch等等。最重要的一点是，当您将所有的日志文件都推送到了一个中央区域的日志服务器后，在有调试BUG或者其他需要检索日志文件的时候，您就不需要分配服务器的ssh登陆权限给相应的人员，在登陆服务器查询对应的日志文件了。

以上，就是今天的CloudWatch logs的内容，在下节课我们将从头开始配置，实现将一个ec2的日志推送至CloudWatch的日志组的整个操作步骤。

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

• AWS爱好者网址：www.iloveaws.cn
• 可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章
• 加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识
• 加入【AWS知识星球】持续学习。

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

【 Domain 1的组织复杂性设计（Design for Organizational Complexity）】——-S3标准 ACL（Canned ACL）

Hello大家好，欢迎回来，我们今天的课程内容是S3的标准ACL，对于跨账户的S3的存储桶访问，掌握标准ACL知识点是非常重要的。

我们开始今天的课程。

S3 ACL基础知识

首先，我们要先介绍一下S3 ACL的基础知识。

ACL也就是访问控制列表 ， 是基于资源的访问策略选项之一 ，可用于管理对存储桶和对象的访问。使用 ACL 可向其他 AWS 账户授予基本的读/写权限。

每个存储桶和对象都有一个作为子资源而附加的 ACL，当S3存储桶中的对象收到访问请求时，AWS S3会检查与存储桶对象关联的ACL，以决定是允许还是拒绝访问请求。

另外还有一点大家需要牢记，当我们创建一个存储桶或者一个存储桶对象时，AWS S3默认会给资源分配一个资源拥有者完全控制权限。

为了让大家更容易理解这些内容，我们来做个实操演示。

get-object-acl命令

在AWS的CLI命令文档中，有一个命令为get-object-acl，这个命令的功能是列出存储桶中的对象的ACL内容。

我们上个ppt中已经讲过，每个存储桶和对象都有一个作为子资源而附加的 ACL，那如何知道附加的ACL的具体内容是什么呢，这就是get-object-acl这个命令的作用。

我们现在切换到终端，看下这个命令的使用方式。

默认情况下，S3资源所有者拥有完全控制权限

在切换终端前，我们先进入account a的s3管理控制台，我们之前在account a的iloveawscn存储桶，上传过一个test.txt文件，我们现在就使用get-object-acl命令，获取一下这个对象的ACL。

现在切换到终端，让我们执行命令:

aws s3api get-object-acl --bucket iloveawscn --key test.txt --profile accounta

我们看下get-object-acl命令的返回信息，displayname: xiaoliange，就是我的account A，permission是完全控制权限。

正如我们前面介绍过的内容，当我们创建一个存储桶或者一个存储桶对象时，AWS S3默认会给资源分配一个资源拥有者完全控制权限，而这个test.txt的资源拥有者就是这个account a账户,只有account a对于这个文件有完全控制权限。

我们继续，大家是否还记得上节课我们使用了account b的访问密钥上传了一个accountb_file文件到account a的存储桶？我们来到s3控制台看看一下，就是这个文件。

我们现在使用cli看下这个文件的acl内容是什么。

切换到终端，然后我修改下命令，key这里改成accountb_file 。–profile 指定account a的凭证，然后执行：

aws s3api get-object-acl --bucket iloveawscn --key accountb_file --profile accounta

我们看下返回结果,返回信息显示访问被拒绝，因为什么呢，因为这个文件的拥有者是account b，我们刚才使用了accounta的凭证执行命令，所以会提示访问被拒绝，因为没有权限。

所以，我们要使用accountb_file这个文件的拥有者，也就是accountb的凭证，来运行这个命令，获取acl。我们来执行一下，将命令的profile 使用凭证改为account b，运行下然后看下命令的返回结果：

aws s3api get-object-acl --bucket iloveawscn --key accountb_file --profile accountb

displayname:22749752，这是我的account b账户，可以看到这个文件的拥有者是account b,只有它拥有这个文件的完全访问权限。所以accounta对于这个文件没有任何访问权限，这也是为什么account a无法访问这个文件的原因。

在使用跨账户s3存储桶访问时，很多用户都遇到了这个问题而对于原因很困惑，希望通过以上的内容和实际的演示，能够帮助大家掌握这些知识点。

好，我们继续后面的课程内容。

S3标准ACL

下面的内容我们来介绍下S3的标准ACL。

Amazon S3 支持一系列预定义的授权，称为标准 ACL。每个标准 ACL 都有一组预定义的被授权者和许可。

我们前面介绍过，每一个存储桶对象都有一个与之关联的ACL，当我们上传对象时如不特别指定，对象会使用默认的ACL。

然而，当我们上传一个对象到S3存储桶时，也可以指定一个标准ACL，当 Amazon S3 收到包含标准 ACL 的请求时，它会向资源的 ACL 添加预定义的授权。可以使用 x-amz-acl 请求标头在请求中指定标准的 ACL。

我们看下ppt表格中有很多标准ACL，不同的标准ACL对应着不同的相关联的预定义授权。第一个是私有，它是默认的ACL,添加到ACL的权限为所有者将获得完全控制，其他人没有访问权限，想想我们上面测试的例子，就是使用了默认ACL的情况，accountb_flie文件的拥有者是account b，account a是没有访问权限的。

表格中另外一个比较常用的标准ACL是bucket-owner-full-control，它的作用是 对象所有者和存储桶拥有者均可获得对对象的完全控制权限。意思就是当跨账户S3访问时，当你从一个账户上传对象至另一个账户的存储桶时，如果你希望您的上传账户也就是对象的拥有者和另一个账户的存储桶拥有者都对这个对象有完全访问权限时，就可以在上传时指定这个bucket-owner-full-control标准ACL。

对应咱们前面做过的实操演示，accountb_file这个文件的拥有者是accountb ，account a是iloveawscn这个存储桶的拥有者，当我们使用account a的凭证访问accountb_file这个文件时，因为这个文件的acl只允许对象拥有者accountb完全控制，所以account a是无法访问的。如果想让这个文件的拥有者和存储桶的拥有者同时都有完全访问权限，就可以在上传时通过x-amz-acl在请求中指定使用bucket-owner-full-control这个标准ACL

这很容易实现，我们现在来测试下，切换到终端。

我们新创建了一个文件名为acl.txt的文本文件做测试，接下来我们要使用accountb的凭证，上传这个文件到accounta的iloveawscn存储桶，同时指定标准acl为bucket-owner-full-control ，我们现在来操作下：

aws s3 cp acl.txt s3://iloveawscn/ --acl bucket-owner-full-control --profile accountb

好，现在acl.txt使用accountb的凭证，指定了bucket-owner-full-control 的acl，已经成功上传到了accounta 的iloveawscn存储桶。

我们现在用之前介绍的get-object-acl命令，来获取下这个文件的acl,我们找一下之前的命令修改下，–key后的对象名称修改为acl.txt，然后执行：

aws s3api get-object-acl --bucket iloveawscn --key acl.txt --profile accountb

我们看下命令返回结果：

可以看到，对象的拥有者account b以及存储桶的拥有者account a，都是完全控制权限，这就是在执行上传时–acl的标准acl bucket-owner-full-control的作用。

理解这部分内容无论是对于实际应用还是认证考试都是非常重要的，我在总结一下，当你将一个对象从一个账户上传至其他aws账户的存储桶时，如果您希望上传后对象拥有者和存储桶拥有者对这个对象都有完全控制权限的话，就需要在上传时通过—acl 指定 bucket-owner-full-control的标准acl。

大家可以亲自做一下上面的测试，测试的环境准备也不是很困难，自己动手进行测试这对于知识的掌握非常有帮助。

好，以上就是我们今天的视频课程内容。

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

可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章
加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识
加入【AWS知识星球】持续学习。

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

【 Domain 1的组织复杂性设计（Design for Organizational Complexity）】——-配置跨账户S3存储桶的访问（Cross Account S3 Bucket Configuration）

Hello大家好，欢迎回来，我们今天的课程内容是跨账户S3存储桶的访问。

当前，在很多组织中，应用跨账户S3存储桶访问的架构组成是非常普遍的，同样，对于AWS SAP认证考试，掌握跨账户存储桶的访问知识点也是非常重要。

我们开始今天的课程。

使用存储桶策略配置跨账户S3存储桶访问

将S3存储桶的访问权限授予属于不同aws帐户的委托人，在很多组织的AWS架构中非常常见，为了能够让大家更容易的掌握这方面内容，我将要做个实操演示，画了个简单的架构图，后面的演示都依照此架构来进行。

我们看下图，假设当前组织有两个AWS账户，左边的ACCOUNT A 中包括组织所有的S3存储桶，右边的ACCOUNT B中运行着组织所有的EC2资源，假设ACCOUNT B中的EC2需要定期备份重要数据到ACCOUNT A中的存储桶，能不能实现呢？我们知道，创建的S3存储桶默认情况下是私有的，任何存储桶拥有者之外的账户都不能访问存储桶，在这种情况下，就需要使用存储桶策略来达成 跨账户进行S3存储桶访问，也就是说ACCOUNT A中的创建存储桶策略，允许ACCOUNT B访问存储桶。

在接下来的内容，我们来演示下如何实现。

配置S3存储桶策略

首先，来到ACCOUNT A的S3的管理控制台，进入iloveawscn这个存储桶，然后权限-进入存储桶策略，可以看到目前这个存储桶没有配置存储桶策略。

前面讲过，如果要让ACCOUNT B能够跨账户访问S3存储桶，是需要配置存储桶策略的，我已经准备好了一个简单的存储桶策略，一下就是存储桶策略的内容，大家可以直接使用它进行测试。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "cross",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::256454142732:root"
            },
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::iloveawscn",
                "arn:aws:s3:::iloveawscn/*"
            ]
        }
    ]
}

让我现在把策略粘贴过来，然后看下策略的具体内容：

Effect 是允许，Principal资源委托人，要配置为ACCOUNT B也就是EC2所在账户的arn。

我们切换到ACCOUNT B浏览器，复制一下账户id，256454142732，将它复制到存储桶策略的Principal。

Action为S3的所有动作。然后看Resource，要将此存储桶的arn将此部分替换。我们已经替换好了，为了更清楚我在演示下，替换完成后保存，这样我们的存储桶策略已经生效了。

这里需要在说明一点，大家并不需要自己从头开始写一个存储桶策略，AWS提供了策略生成器帮助我们生成策略，在aws官方文档中您也会找到很多存储桶策略的示例，我经常采用的方法是当需要写一个策略的时候使用百度或者谷歌搜索引擎通过搜索关键字，找到策略示例在aws官方文档的位置，然后修改后使用策略，个人觉得这种方式是最方便的。当然要熟练应用策略就需要您对策略的组成内容有所掌握。

好了，存储桶策略我们已经保存了，我们继续。

准备工作：将ACCOUNT A和ACCOUNT B凭证配置到CLI的credentials配置文件

然后切换到ACCOUNT B的浏览器，看下我提前做好的准备工作。

进入到IAM-用户，我已经创建好了一个名为ACCOUNT B的用户，并给这个用户分配了管理员访问权限，同时为ACCOUNT B用户生成了访问密钥。

另外我已经将ACCOUNT A和ACCOUNT B的访问密钥全部配置到了CLI的credentials配置文件中，也就是说，我现在可以使用CLI可分别指定使用ACCOUNTA或者B的密钥凭证来执行CLI命令，来看一下：

进入到CLI，我们看下credentials配置文件的内容，我配置了两个账户，上面的是ACCOUNT A账户和它对应的访问密钥，下面的是ACCOUNT B账户和它对应的访问密钥，所以目前cli的配置中包括了ACCOUNT A和B两个账户的密钥信息。

好的，以上介绍了目前提前配置的内容，那接下来我们继续演示。

使用ACCOUNT A和B的凭证测试访问S3存储桶

首先，在 CLI中，我们先用ACCOUNT A的密钥，使用cli命令列出iloveawscn这个存储桶里面的对象。使用—profile参数指定使用配置文件中的accounta凭证。

可以看到我们已经成功列出了存储桶中的对象，存储桶中有一个test.txt文件。

下面我们同样进行上述操作，但是使用ACCOUNT B的密钥凭证，看看能不能访问ACCOUNT A的存储桶的对象。也就是说测试ACCOUNT B实现跨账户访问ACCOUNT A中的S3存储桶。将—profile 后面修改为ACCOUNT B，看下结果，好的，同样允许访问并列出了存储桶中的对象。说明我们前面配置的存储桶策略已经生效了

接下来我们继续做测试，在我们cli的当前目录有个accountb_file文件，这是我们已经建立好的一个文本文件，我们cat一下文件内容就一行。

现在我们要将这个文件使用ACCOUNT B的凭证，将其拷贝到ACCOUNT A的iloveawscn存储桶中，这样的话这个文件是属于ACCOUNT B的。

来使用CLI操作下：

aws s3 cp accountb_file s3://iloveawscn/ —profile accountb

搞定，可以看到accountb_file这个文件已经成功从我本地拷贝至ACCOUNT A的存储桶中

我们到ACCOUNT A 的s3控制台确认下，进入存储桶然后刷新下，我们可以看到2个文件，test.txt是开始本课前就存在的文件，另一个accountb_file是刚才我们使用的ACCOUNT B的凭证上传的文件，文件已经成功上传至存储桶。

到这里，我们通过上面的演示，就已经成功实现了跨账户S3存储桶的访问。

我是根用户，为什么存储桶中有的文件我还是没权限操作？

接下来我想继续做个测试，切换到CLI，我想使用ACCOUNT A的凭证 ，将存储桶中的test.txt 拷贝到我本地，注意这个test.txt文件是之前课程通过ACCOUNT A 控制台上传的文件，我们现在来操作下：

aws s3 cp s3://iloveawscn/test.txt . —profile accounta

好的，test.txt文件已经成功拷贝到我本地，我们看下文件已存在。

现在让我同样使用ACCOUNT A凭证拷贝accountb_file这个文件到我本地，我改一下命令，然后执行：

aws s3 cp s3://iloveawscn/accountb_file . —profile accounta

提示拷贝发生错误，拒绝访问，这是为什么呢？

我们切换到accounta控制台页面，然后进入存储桶后找到accountb_file这个文件，在右侧面板属性可以看到很多属性是拒绝访问的。而我现在登陆到控制台的用户，是ACCOUNT A的根用户，在ACCOUNT A中拥有最大的管理员权限，但是同样还是提示拒绝访问这个文件。我们尝试下载这个文件，也无法下载。

这是很多学友比较困惑的地方，大家可以思考下原因，我们将在下节课讲解这部分内容。

好了，我们今天介绍了跨账户s3存储桶访问内容，希望大家能够通过今天的一系列的实操测试对这部分知识点有所掌握。

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

AWS爱好者网址：www.iloveaws.cn
可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章
加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识
加入【AWS知识星球】持续学习。

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

【 Domain 1的组织复杂性设计（Design for Organizational Complexity）】——-S3存储桶策略（S3 Bucket Policies）

AWS解决方案架构师认证 Professional / AWS Certified Solutions Architect– Professional系列的课程的最终目的是帮助大家顺利通过新版考试。随着后续系列课程的持续深入，我们的目标是将所有新版考试涉及到的内容、考点逐步推出系列课程，帮助大家备考。此系列课程也同样适用于想了解和学习AWS的同学，请大家多多支持。

Hello大家好，欢迎回来，我们今天的课程内容是S3存储桶策略。

基于资源的策略和基于用户策略

Amazon S3 提供的访问策略选项大致可分为 基于资源的策略和用户策略两类。附加到资源 (如存储桶和对象) 的访问策略称为基于资源的策略。例如，存储桶策略和访问控制列表 (ACL) 就是基于资源的策略。您也可以将访问策略附加到您账户中的用户。这些策略称为用户策略。您可以选择使用基于资源的策略、用户策略或这些策略的某种组合来管理您的 Amazon S3 资源权限。

我们今天课程的内容是基于资源策略的存储桶策略，那什么情况下需要使用存储桶策略呢？

通常来讲，在使用AWS时，一个和权限、策略相关的服务是IAM，它被用于在AWS账户下分配用户、组、角色使用资源的权限，您可以使用IAM为用户分配访问资源权限，然而，用户策略是用来管理您账户中用户的权限的。对于其他 AWS 账户或其他账户中用户的跨账户权限，则必须使用存储桶策略，而且，当您想基于存储桶来规划访问策略时就需要使用存储桶策略，存储桶策略是直接附加到存储桶上的。

下面我将会做一个演示，帮助大家了解存储桶策略的作用。

很多案例都在使用S3

现在大家看到的是AWS官方SAP-C01考试指南，在我们前面的课程出现过，这个PDF文件实际上是存储在AWS 上的S3存储桶中，我们可以使用curl命令验证下。我们复制一下URL，打开console，来验证下

curl -I https://d1.awsstatic.com/training-and-certification/docs-sa-pro/AWS_Certified_Solutions_Architect_Professional-Exam_Guide_EN_1.2.pdf

看下返回的信息，server 是amazons3 ，也就是说，aws将考试指南pdf放到了s3存储桶中，提供给所有人进行访问，任何人通过这个url，都可以访问并下载考试指南PDF。

我们在演示一个网站的案例，就是这个网站，AWS官方提供的AWS月成本计算器，我在工作中经常会使用这个网站，做一些AWS资源月使用成本的估算。

月成本计算器网站也是运行在S3中，我们同样使用curl命令来验证一下：

curl -I https://calculator.s3.amazonaws.com/index.html

同样可以看到这个网站也是托管在amazon s3上。

当前很多组织都在使用S3来托管网站、网页应用以及音、视频文件等等，因为它配置起来非常的简单。

配置对象允许所有人访问

下面我将演示上传一个文本文件到S3存储桶，并提供给所有人访问。

来到S3控制台，我们开始创建一个S3存储桶，名称为iloveawscn，区域就是目前的亚太区域就可以，然后下一步，完成存储桶的创建。

创建完成后，可以看到存储桶的访问属性是“存储桶和对象不是公有的”，也就是说存储桶和对象没有任何公有访问权限。

我们现在进入存储桶，然后上传一个txt文件，上传一个test.txt文件，不做任何配置，直接上传。

上传完成后，我们选择test.txt文件，在右侧可以看到对象的url，可以使用这个url打开或者下载这个文件。
我们复制下这个url , https://iloveawscn.s3-ap-northeast-1.amazonaws.com/test.txt

然后进入到console，curl一下这个url，看看是什么结果。不出所料，结果显示是拒绝访问的。因为现在存储桶缺省配置是阻止全部公共访问权限，所以当我们通过curl命令访问对象时就会被拒绝。

那如果您的应用场景是和前面的考试指南文件PDF一样，需要提供给所有用户访问或下载这个文件，最简单的方法就是把这个txt文件设置为公开，但在将这个对象设置为公开前，要先将这个存储桶的阻止公共访问权限关闭。现在还操作下:

进入这个存储桶，选择权限，然后编辑，将组织全部/公共访问权限的复选框去掉，然后保存。

然后点击test.txt文件，将其设置为公开。

好的，现在test.txt文件就成功设置为公开了，我们现在测试下，同样使用curl命令，我们先复制下这个文件的url，然后回到console，执行，可以看到我们已经可以成功访问这个txt文件，并获取到了文件的内容，说明我们这个txt文件已经成功设置成了公开，提供给所有人访问和下载。

开放允许特定IP段的存储桶策略

然而，还有一些应用场景，比如我现在只希望在我单位的网络情况下访问到存储桶中的文件，除此之外的网络禁止访问，也就是说，只开放允许特定的IP段访问存储桶对象，不在指定的IP段都希望是禁止访问的。要达成这个需求，就需要使用存储桶策略对允许访问的的IP以及相关配置项进行配置。

那我们现在就来配置一下吧：

我们现在进入到存储桶策略配置项，进入这个存储桶，选择权限-存储桶策略，现在策略是空的，没有内容。在存储桶策略中，可以对这个特定的存储桶进行各类访问控制配置。

那么接下来我们就要配置一个基于ip地址条件的存储桶策略。我已将策略准备好，现在将策略直接复制粘贴到这里。

我们看下这个策略的内容，Principal是*，代表所有；action配置的是所有s3动作，resource部分我们将这个存储桶的arn复制到这里。然后是ipaddress，需要将允许访问这个存储桶的ip替换到这里，我快速查看下我目前的公网ip :114.248.231.140，然后替换掉策略中的ip。注意我这里现在配置了我目前公网地址，是一个单独的ip地址，ip地址后面是/32，当然也可以配置成网段。DENY对应notipaddress，也就是只允许这个ip访问这个S3存储桶。

下面就是策略的内容，大家可以复制修改后使用。

{ "Version": "2012-10-17", "Id": "S3PolicyId1", "Statement": [ { "Sid": "statement1", "Effect": "Deny", "Principal": "*", "Action":["s3:*"] , "Resource": "arn:aws:s3:::examplebucket/*", "Condition" : { "NotIpAddress" : { "aws:SourceIp": "192.168.143.188/32" } } } ] }

目前存储桶策略就配置完了，策略已经生效，后面在当有向这个存储桶对象发出访问请求时， 存储桶策略将验证访问的ip是否为策略中配置的这个ip，如果是，将会允许对于这个s3存储桶的所有动作，如果不是这个ip，将拒绝访问这个存储桶。

我们测试下实际情况是不是这样的:

同样，复制下test.txt的url，进入到console，curl一下看返回结果，可以看到，可以成功返回文件内容，因为存储桶策略中目前配置的ip就是我现在的上网ip，所以我现在是可以访问test.txt的。

那接下来，我们将存储桶策略中的ip地址随便修改下，将它修改为和我现在的上网ip地址不同即可，然后，理论上当我在访问这个存储桶文件时就会由刚刚的允许访问变成禁止访问，这样才能说明刚加的限制ip访问的存储桶策略是生效的，那我们现在就测试下吧：

进入到我们创建的存储桶，然后选择存储桶策略，将里面的ip随便改一个，然后保存。

然后我们进入到console，再次执行下curl这个txt文件的url，发现已经是禁止访问了。说明我们的存储桶策略已经生效了，只有策略中指定的ip才可以访问存储桶中的对象。

好的，以上我们演示了一个存储桶策略的简单用例，希望能够通过这个简单的演示，能够让大家对于存储桶策略有个初步的认识，实际上，还有很多不同的存储桶策略，用来帮助我们达成的需求，我们之后的课程将进行讨论。

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

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

-AWS爱好者网址：www.iloveaws.cn
-可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章
-加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识
-加入【AWS知识星球】持续学习。