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

我们来看下网络ACL的一些重要知识点。

网络ACL知识点

1、网络ACL是无状态的，这意味着允许入站流量的响应，返回的数据流必须被出站规则明确允许（反之亦然）。
2、网络ACL是在子网级别运行；而安全组在实例级别运行。我们看下PPT右侧的图：

子网1中有一台EC2，安全组是与这台EC2的网络接口关联的，因此安全组是在实例级别运行的。然而，对于网络ACL，它不是在实例级别运行，而是在子网级别运行。

我们看下图，子网1关联了一个网络ACL,这个子网1中可能有数百台EC2实例，那么对于这个网络ACL规则的调整，是会影响关联的子网1中的所有EC2实例的。

假设来自互联网网关的数据流会使用路由表中的路由，路由到合适的子网，与子网关联的网络 ACL 规则控制允许进入子网的数据流，与实例关联的安全组规则控制允许进入实例的数据流。

3、VPC中的每个子网都必须与一个网络ACL相关联。如果您没有明确地将子网与网络ACL相关联，则子网将自动与默认网络ACL关联。

4、（上面提到了默认网络ACL）默认网络ACL的内容为允许所有入站和出站的流量， 也就是允许所有流量流进和流出与其关联的子网。所以，当我们在子网启动实例后，如果使用的是默认网络ACL，那么至少网络ACL对于启动的实例是放行的。

5、您也可以创建自定义网络 ACL 并将其与子网相关联。

默认情况下，每个自定义网络 ACL 都拒绝所有入站和出站流量，直至您添加规则。所以如果您自己创建了自定义网络ACL，要注意默认情况下会拒绝所有出入站流量，需要根据实际需求自行调整规则，这一点也是容易忽视的地方。

安全组和NACL的差异

我们接下来看下安全组和网络ACL的差异，这也是很多同学可能比较关心的部分。

1、安全组在实例级别运行，网络ACL在子网级别运行。

2、安全组仅支持配置允许规则，在安全组无法配置拒绝规则。例如配置显式拒绝某个IP地址访问EC2实例，这个安全组做不到；而网络ACL支持允许规则和拒绝规则。我举个例子，比如我们有一台EC2，对外开放了80端口的访问，如果想要拒绝某个来源IP对实例的80端口访问，这个通过安全组是做不到的，需要使用网络ACL添加相应的拒绝规则。

3、安全组是有状态的，返回的数据流会被自动允许；而网络ACL是无状态的，返回数据流必须被规则明确允许，就是说使用网络ACL配置了允许进站的规则必须要有相应允许出站的规则。

4、规则判断的区别，安全组会在决定是否允许数据流前评估所有规则；网络ACL会按照规则的数字，顺序处理所有规则，这块我们后面会进行演示。

5、安全组只有在与实例关联的情况下，规则才会被应用到实例；而网络ACL自动应用于与之关联的子网的所有实例，网络ACL提供了额外的防御层。

以上就是安全组与网络ACL的差异。

接下来的内容我们切换到AWS管理控制台，演示前面讲的内容。

NACL实操演示

我们切换到EC2的控制台，当前有一台EC2在运行，我们使用这个EC2来做下面的演示。

首先，看下这台EC2的安全组的入站规则，当前对所有来源开放了ICMP，以及TCP的22端口。如果我们现在要禁止一个特定的IP访问这台EC2的22端口，使用安全组是做不到的，因为前面讲了，安全组只支持配置允许的规则，这就需要配置网络ACL添加相应的拒绝规则。

我们看下当前的网络ACL，进入到VPC控制台，然后安全性-网络ACL，可以看到目前我们有一个网络ACL，默认值为“是”，意味着它是创建的默认网络ACL；

这个网络ACL目前关联了3个子网。您可以将网络 ACL 与多个子网关联。但是，一个子网一次只能与一个网络 ACL 关联。当您将一个网络 ACL 与一个子网关联时，将会删除之前的关联。

页面下方是网络ACL的入站规则和出站规则，当前入站和出站各包括两条规则，我们看一下规则，规则左边是编号列表，第一条规则编号为100，允许了所有的流量入站；第二条规则编号为*号，规则内容为禁止所有流量入站。

网络ACL是按顺序评估规则，从编号最小的规则开始，以判断是否允许流量进入或离开任何与网络 ACL 关联的子网，也就是说在网络ACL中，规则的编号越小，它的优先级就越高。

假设现在有入站流量匹配到了编号100这条规则，那么网络ACL就会放行此入站流量，而不会在继续向后评估规则。也就是说网络ACL从最小编号的规则开始匹配，匹配了规则的流量就会执行该规则相应的放行或者禁止动作，而不在继续向后匹配规则。

我们看下现在的默认网络ACL的规则，默认允许了与其关联的子网的所有入站和出站的流量。

接下来我们就测试下，在我的本地终端是否能够访问这台EC2。

我们切换到EC2控制台页面，复制这台EC2的外网IP，然后在切换到我本地的终端，使用PING命令来测试下：

ping 54.180.109.183

可以看到返回的信息显示可以PING通的，我本地电脑是可以和这台EC2通信的。

接下来我们做个测试，修改下这台EC2所在子网关联的网络ACL的入站规则，我们添加一个入站规则：
添加规则，编号输入90 ，然后选择所有流量，协议，端口范围以及源都保持和编号规则100的内容一致，然后允许/拒绝这里选择拒绝，然后完成添加规则。

我们看下，新添加的规则的编号为90，内容为拒绝所有入站流量；之前默认的规则编号100，内容为允许所有入站流量。

然后我们切换到本地终端在PING一下EC2的IP ：

ping 54.180.109.183

可以看到目前我们已经无法ping通ec2了，ping的访问被拒绝了。

这是因为我们新添加的规则拒绝了所有的入站流量，当我的本地流量到达网络ACL时，网络ACL规则开始评估流量，新添加的这个规则的编号为90，目前优先级最高，规则内容为禁止所有入站流量，我们刚刚访问流量匹配了这条规则，所以被网络ACL禁止访问，有规则匹配后，就不会再继续向下匹配其他规则，所以我们的入站流量被拒绝了。

我们继续做测试，我们编辑下入站规则，把之前添加的规则编号由90修改为110。然后，现在允许规则的优先级高于拒绝规则的优先级，我们继续PING下EC2，可以看到我们的PING又被放行了。

接下来我们看下另一个案例，默认网络ACL规则内容为放行所有入站和出站的流量，我们前面讲过，如果我们想要拒绝某个特定的来源IP对实例的访问，这个需求通过安全组是做不到的，需要使用网络ACL。

看下我现在本地出口的ip，为114.245.93.139，假设我们现在要配置网络ACL规则，拒绝我这个IP访问EC2，但是允许除此IP外的其他访问流量，我们来配置下网络ACL。

编辑入站规则，我们将之前测试添加的规则删除，然后新添加一个规则，配置编号为90使其优先级当前最高，然后所有流量，所有协议，全部端口，将 “源” 配置为我的出口IP，然后选择拒绝，保存。

我们看下现在的规则，如果有来源IP为114.245.93.139的流量到达网络ACL，编号90的规则就会匹配流量，规则拒绝此来源IP的访问并不会向后在匹配其他规则；

如果来源不是此特定IP的其他的流量，那么就不会匹配编号90的规则,会继续匹配后面的规则，也就是编号100的规则，规则内容是放行所有入站流量，所以最终入站请求会被放行。这样就实现了上述案例的需求，禁止某个特定IP的入站访问，但是允许其他除此IP外访问的需求。

好的，我们在回到前面的PPT，默认网络ACL的内容为允许所有入站和出站的流量，但如果您自己创建了自定义网络ACL，默认的情况下，自定义的网络ACL是拒绝所有入站和出站流量的，直到您添加相应的规则，我们来测试下是不是这样

我们创建一个自定义的网络ACL,然后看下出站、入站的规则，可以看到创建的自定义的网络ACL是拒绝所有入站和出站流量的，需要根据需求自行添加相应允许规则。

很多同学在实际使用网络ACL的时候都忽视了这一点，导致无法访问EC2，所以这里单独提出来讲一下。

好的，以上就是我们今天的视频课程内容，希望能够帮助大家更深入的理解网络ACL。

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

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

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

今天的课程内容信封加密，是KMS部分比较重要的内容。

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

什么是信封加密？

我们先看下什么是信封加密。信封加密是类似数字信封技术的一种加密手段。

这种技术将加密数据的数据密钥封入信封中存储、传递、和使用，不再使用主密钥直接加解密数据。也就是说，信封加密使用客户主密钥生成数据密钥，然后用离线的数据密钥在本地加密大量数据，而不再使用主密钥直接加解密数据。

我们上节课实操演示了使用KMS的客户主密钥也就是CMK进行加密，将需要加密的明文内容为“www.iloveaws.cn”直接发送到AWS KMS中进行加密。那什么情况下使用信封加密呢？我们来看下：

• 首先，AWS KMS支持发送最大4KB的数据进行直接加密，如果需要加密的数据比较大的话就需要信封加密。
• 其次，信封加密可提供巨大的性能优势，当使用 AWS KMS 直接加密数据时，整个数据必须通过网络进行传输。信封加密降低了网络负载，因为通过网络发送的只有请求，同时传输的数据密钥也更小。避免向 AWS KMS 发送整个数据块并遭遇网络延迟。
• 最后，将需要加密的数据通过网络传输至KMS，虽然是通过安全信道通信，也有可能会在传输过程中存在诸多风险，如窃听、钓鱼，且一些组织的安全政策也不允许用户将数据传输至AWS进行加密。

以上就是信封加密的定义及主要优势，我们之前课程提到的集成了 AWS KMS 的 AWS 服务和客户端工具包，也是使用信封加密的方法来保护数据的。

好的，我们继续。

信封加密的工作流程

我们来看下信封加密是如何工作的。

1、首先，我们创建一个客户主密钥，也就是CMK。
2、CMK生成后，我们使用CMK生成数据密钥，一旦请求KMS生成数据密钥时，用户能够得到一个明文数据密钥和一个密文的数据密钥，共2个数据密钥。
3、然后使用明文数据密钥加密您服务器上的文件，生成密文文件。
4、将密文文件和密文数据密钥一同存储到持久化存储设备或服务中。

完成加密后，将明文文件，以及明文数据密钥删除。

以上，是加密流程部分。

当您完成上述加密操作后，只保留密文密钥和密文文件，这样即使密文密钥和密文文件被窃取，也无法解密获得用户的明文文件。

接下来我们看下解密的步骤：

1、需要解密文件时，首先从持久化存储设备或服务中读取密文数据密钥和密文文件
2、然后，调用KMS服务的Decrypt接口，解密数据密钥，取得明文数据密钥
3、最后，使用明文数据密钥解密文件

好的，以上就是信封加密的加密和解密的过程，下面的内容我们快速实操演示下使用CMK生成数据密钥的操作。

实操演示：CMK生成数据密钥

首先，我们需要使用aws cli命令生成数据密钥，打开aws cli的kms命令参考页面，在此页面的最后【可用命令】部分，打开generate-data-key命令页面。

我们前面讲过了，通过调用generate-data-key命令，KMS会返回明文数据密钥以及密文数据密钥，然后使用明文数据密钥加密您自己服务器上的数据。

我们看下这个命令的摘要，命令需要指定cmk的密钥ID
然后还需要一个命令参数—数据密钥的长度，数据密钥的长度我们测试就使用AES_256，生成256位密钥。

好的，命令我们看完了，我们先到KMS管理控制台复制下CMK的密钥ID，然后切换到终端。

输入命令：aws kms generate-data-key --key-id 231973f0-4cbe-4ef5-8ac3-0ef3f8164960 --key-spec AES_256

key-id后面指定CMK的密钥ID，我们粘贴下，然后key-spec 我们输入 AES_256 然后运行命令。

好的，可以看到，命令执行后，返回了明文数据密钥以及密文数据密钥，然后您就可以使用明文数据密钥对您的服务器上的文件进行加密，加密后您可以将密文数据密钥和密文文件一同存储到持久化存储设备或服务中。

需要解密文件时，使用KMS的decrypt接口，将密文数据密钥解密为明文数据密钥，在使用明文数据密钥为本地文件解密。

好的，以上就是我们今天的课程内容，我们今天讲了KMS-信封加密的内容以及加解密的流程，并对生成数据密钥进行了实操演示。

信封加密在KMS服务部分是非常重要的内容，在考试中也会有相应的考点，希望本节课程会为同学们理解信封加密带来帮助。

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

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

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

Hello大家好，欢迎来到《AWS解决方案架构师认证 Professional(SAP)中文视频培训课程》

在上节课我们在KMS管理控制台中创建了一个CMK客户主密钥，并定义了密钥管理员及密钥用户。
这节课将使用这个CMK进行加密和解密的操作演示。

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

我们在上节课创建了一个IAM用户kms-test ，并将这个用户配置成为创建的CMK的密钥用户。
接下来的内容，我们要在aws cli使用kms-test用户的访问密钥，通过aws cli命令来演示加密和解密数据。

配置AWS CLI

首先我们要在aws cli中配置kms-test用户的访问密钥：

• 切换到终端，运行 aws configure，然后将kms-test用户的访问密钥复制进来。
• 进入IAM->用户->kms-test->安全证书，创建访问密钥，然后将访问密钥ID复制到AWS CLI，然后复制私有访问密钥.
• 接下来是AWS区域配置，因为我们在配置KMS生成CMK是在首尔（ap-northeast-2）区域，所以我们要在CLI中配置区域为ap-northeast-2，需要和创建CMK配置同一区域。

好的，我们现在完成了将kms-test用户的访问密钥配置至aws cli。

为kms-test用户添加KMS相关IAM权限

在终端中运行 aws kms list-keys 命令，命令返回为access denied，操作被拒绝，提示kms-test用户没有相应的权限，因为我们目前没有为该用户添加kms相应权限。

访问IAM控制台，我们现在为该用户添加权限，IAM->用户->kms-test->权限，添加内联策略，服务选择KMS，操作选择listkeys，然后下一步查看策略，名称输入kmslistkeys，然后完成策略的创建。现在kms-test用户就拥有kmslistkeys权限。

我们回到终端再次运行aws kms list-keys 命令，可以看到已经成功将我的账户在这个区域的cmk全部列出来了。那我们之前创建的CMK是哪一个呢，我们到KMS控制台来看一下密钥ID，尾数后四位4960，所以AWS CLI命令返回中间的这个CMK是我们上节课创建的。

接下来，我们使用这个CMK来进行加密操作，我们需要使用相应的AWS CLI命令来达成。

看过之前课程的同学都知道，可以通过AWS CLI命令参考页面找到这些命令。
打开kms cli命令参考页面，我们看下，在后面可用命令这里，我们这节课关注的是kms encrypt和decrypt，加密、解密对应的KMS命令，分别打开相应的页面。

实操演示：KMS加密

先演示加密操作，切换到kms encrypt页面，这个页面包括命令描述，参数、命令选项，示例等等。

我们看下加密命令摘要，有两个必有选项：

• key-id ，后面需要指定我们创建的cmk的密钥ID，使用此CMK进行加密。
• plaintext， 后面指定需要加密的明文内容。

切换到终端，我们运行下命令。

我们输入命令：
aws kms encrypt --key-id 231973f0-4cbe-4ef5-8ac3-0ef3f8164960 --plaintext “www.iloveaws.cn”

• 参数key-id 后面内容为我们使用的CMK的密钥ID
• 参数plaintext 后面我们输入一个想要加密的明文内容，我们就输入 “www.iloveaws.cn”，然后执行。

我们看下命令的返回结果，包括CiphertextBlob和keyid，以及EncryptionAlgorithm加密算法。

CiphertextBlob这个密文blob的内容就是我们命令指定的plaintext内容www.iloveaws.cn加密后的base64编码的密文。

我们现在只需要CiphertextBlob的内容，不需要命令返回密钥ID以及加密算法，修改下命令，在命令后面加上 query CiphertextBlob ,执行命令：

aws kms encrypt --key-id 231973f0-4cbe-4ef5-8ac3-0ef3f8164960 --plaintext “www.iloveaws.cn” --query CiphertextBlob

看下返回结果。现在的返回结果只包括了加密后的密文blob，但是内容两边的引号也不是密文的内容，所以我们还需要在命令后添加一个选项，让命令返回的结果不包括加密密文两边的引号，需要再命令后添加–output text ，我们执行下命令：

aws kms encrypt --key-id 231973f0-4cbe-4ef5-8ac3-0ef3f8164960 --plaintext “www.iloveaws.cn” --query CiphertextBlob --output text

好的，现在命令返回的内容就只有加密后的密文blob内容。

我们现在进行加密的最后一步，现在加密命令返回的密文内容是基于base64编码的，如果后面要使用AWS CLI进行解密，就需要将base64编码进行解码为二进制文件，需要在命令后面加入 | base64 –decode 参数。

我们来操作下，在命令后面添加 | base64 –decode，然后我们将解码后加密的内容输出至一个文件，encrypttest文件，运行命令：

aws kms encrypt --key-id 231973f0-4cbe-4ef5-8ac3-0ef3f8164960 --plaintext “www.iloveaws.cn” --query CiphertextBlob --output text | base64 --decode > encrypttest

我们尝试查看下生成文件encrypttest的内容，less encrypttest ,可以看到为二进制文件，无法查看该文件的内容。

好的，目前我们已经通过aws cli 命令，使用kms-test用户将明文www.iloveaws.cn内容加密，将加密密文生成至encrypttest文件。

实操演示：KMS解密

接下来我们要对之前加密的内容进行解密，同样切换到aws cli kms decrypt命令参数页面 ，看下解密的命令参数。

同样在解密命令摘要这里，命令必选的参数为–ciphertext-blob，通过–ciphertext-blob参数指定需要解密的密文，我们切换到终端，进行解密操作。

输入命令：

aws kms decrypt --ciphertext-blob fileb://encrypttest

ciphertext-blob 后面要指定之前加密步骤生成的密文文件，通过fileb://来指定，然后执行命令。

我们看到命令返回时包括KEYID，plaintext以及加密算法。

同样，我们只需要plaintext明文的内容，在命令后加入参数 query Plaintext 和 output text ，输入命令：
aws kms decrypt --ciphertext-blob fileb://encrypttest --query Plaintext --output text

看下命令返回结果，可以看到现在已经能成功只将plaintext的内容返回，同样，返回的是base64编码的内容，我们进行下解码，在运行命令后追加| base64 —decode ,然后运行命令：

aws kms decrypt --ciphertext-blob fileb://encrypttest --query Plaintext --output text | base64 --decode

可以看到命令已经成功将我们之前加密的明文内容www.iloveaws.cn解密。

好的，以上我们通过aws cli kms命令，完成了加密和解密操作的演示，在整个演示的过程中，使用的主密钥一直存储在KMS中，由AWS进行保存，我们并没有接触到主密钥，而是通过密钥ID来进行加密操作，这也在一定程度上保障了主密钥的安全性。

演示中使用的加密、解密的cli命令和参数都可以通过aws cli命令参考页面查询到，也希望有条件的同学可以自己动手操作一下，这样有利于知识的掌握。

以上，就是本节课的所有内容。

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

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

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

AWS KMS是一项托管服务，使用KMS可轻松创建和控制加密数据所用的加密密钥。该服务提供可用性高的密钥生成、存储、管理和审计解决方案。

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

AWS KMS它是一项托管服务，用于创建和管理加密密钥，在 AWS KMS 中创建的客户主密钥均受硬件安全模块 (HSM) 保护。

KMS服务的特点和优势

KMS服务有以下特点和优势：

• 完全托管，具有可扩展性、持久性和高可用性；
• KMS提供了单一控制点，集中式管理密钥，可以随时创建新密钥，以及对密钥的生命周期和权限进行集中控制；
• KMS与AWS服务集成，可简化密钥使用以加密AWS工作负载中的数据，AWS KMS 可与大部分其他 AWS 服务无缝集成，因此在这些服务中加密数据甚至仅需要勾选“加密”复选框即可完成加密。
• 成本低廉，使用KMS服务不需要事先承诺用量，也没有预付费用。

KMS实操演示内容

接下来的内容我们来演示下如何使用KMS服务，大致分成三个部分：

1. 首先创建一个CMK。CMK也就是客户主密钥，是主密钥的逻辑表示，它包含元数据如密钥ID、创建日期、描述和密钥状态，CMK还包括用于加密和解密数据的密钥材料。
2. 然后定义密钥管理员及密钥用户。可以在创建CMK时定义，或者创建后在添加。
3. 完成前面两步后，密钥用户使用 密钥ID 来加密和解密数据。

KMS实操演示内容-创建客户主密钥

首先，我们先进入KMS管理控制台，看下左边的内容：

AWS托管密钥，是指由AWS KMS集成的AWS服务代表您在您的账户中创建、管理和使用的CMK。举个例子大家就理解了：在创建EBS卷时，如果选择了加密此卷而在主密钥选择了默认，则AWS服务就会在这里创建一个AWS托管密钥CMK，可以看到我这里就有一个AWS托管CMK，就是创建卷选择加密后自动由AWS服务创建的。

在很多场景下，我们需要对密钥进行更多的管理和控制，以及使用密钥加密自己的数据等等，在这种情况下就无法使用AWS托管密钥了，需要在客户管理的密钥这里，创建密钥。

客户管理的密钥，是指在您的AWS账户中创建、拥有和管理的CMK，在这里的CMK您可以完全控制。

我们要在这里创建一个CMK，点击“创建密钥”。

密钥类型可以选择对称和非对称，我们选择对称，使用单个加密密钥加密和解密。

然后看下高级选项，可以选择密钥的来源：KMS、外部、以及自定义密钥库，也就是说，可以将您的外部对称的256位密钥导入KMS。

我们选择KMS，然后下一步，创建别名和描述，我们输入别名，iloveawscntest，标签我们暂不设置，下一步。

定义密钥管理权限，在这一步我们需要配置一个密钥管理员， 密钥管理员拥有对密钥的控制权限。

在这里已经列出了我的所有IAM用户和角色，可以看到有一个IAM用户zhangsan，我们选择他将其配置为密钥管理员，然后下一步。

然后定义密钥使用权限，我们先不配置，一会在配置。

下面“其他AWS账户”，可以指定使用此密钥的其他AWS账户，密钥是支持跨账户使用的，我们不配置，点击下一步。

审核和编辑密钥策略， 我们看下目前密钥策略的内容。

principal委托人内容为根用户，拥有所有的KMS操作权限。

在往下看，可以看到我们之前步骤定义的密钥管理员zhangsan用户允许的KMS操作，点击完成。

好的，CMK就已经创建完成了，这里列出了CMK的别名和密钥ID。别名是一个显示名称，使用它来表示CMK。在拥有多个CMK时，通过别名可以让我们更容易辨别CMK。

点击密钥ID，我们看下可以查看到哪些具体信息以及配置。

• 可以在“密钥策略”这里点击“切换到策略视图”，查看和编辑策略信息。
• 密钥管理员部分，可以看到我们已经添加的zhangsan用户做为密钥管理员，也可以通过“添加”按钮添加更多的密钥管理员。
• 密钥用户，是指哪些IAM用户和角色使用此密钥用于加密操作。我们之前没有添加密钥用户，现在创建个用户然后添加到密钥用户：

KMS实操演示内容-添加密钥用户

进入到IAM-用户，创建一个kms-test用户，访问类型选择“编程访问”，然下一步直到完成创建用户。

然后回到KMS，刷新一下，然后点击“添加”，添加密钥用户，选择刚刚创建的KMS-TEST用户，可以看到我们已经完成了添加密钥用户。

添加了kms-test用户为密钥用户后，这个用户就可以通过他的访问密钥ID和私有访问密钥来加密或者解密他自己的数据。

最后要补充一点，不论是您创建的CMK，还是其他AWS服务创建的CMK，都无法从KMS服务中导出，这样是为了确保CMK的安全，也就避免了您自己遗失了密钥从而造成安全隐患；

如果您有数据需要加密，是通过KMS使用这个密钥ID来加密、解密您的数据。AWS KMS 服务创建的密钥永远不会在创建密钥的 AWS 区域以外传输，并且只能在创建密钥的区域内使用，（这个非常非常重要）这个知识点要掌握，考试会涉及到。

好的，以上就是我们今天的课程内容，我们今天介绍了AWS Key Management Service（KMS）服务，并且演示创建了CMK，以及配置密钥管理员、密钥用户等内容。

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

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

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

【 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知识星球】持续学习。

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