AWS安全实践.doc

AWS安全实践

目录
AWS安全最佳实践#1：禁用root API 访问密钥 2
AWS安全最佳实践#2：在任何时候开启MFA令牌 5
AWS安全最佳实践#3：通过Admin权限减少IAM用户的数量 7
AWS安全最佳实践#4：利用EC2的Roles功能 9
AWS安全最佳实践#5：最小化权限 13

标签：安全,Amazon Web Services,应用,aws

部分内容来源于网络，有侵权请联系删除！
AWS安全最佳实践#1：禁用root API 访问密钥
从本文起，我们开始撰写一系列博文来总结AWS安全相关的十大最佳实践，这些经验总结来自安全工作者和AWS工作人员的大规模AWS部署实践。其中大部分操作起来都非常简单，但却影响着AWS实践的成败。
在AWS的说明中，“root”用户是用来建立AWS账户的登录凭证。曾今，在连接AWS服务的许多地方都必须使用“root”用户。然而，时至今日，“root”用户在AWS基础设施运维中已经可有可无。
在这里，我们推荐禁用这个用户，甚至是删除AWS root API 访问密钥。使用root用户登录Security Credentials page，删除或者禁止任何你可以看到的访问秘钥。

进入Credentials页面时收到的AWS控制台警告
在禁用AWS访问密钥之前你还需要一些准备工作。
1. 通过管理策略建立至少2个（不超过3个）IAM用户
需要注意的是，你肯定不期望将每个IAM用户都设置为管理员用户！Evident Security Platform（ESP）可以帮助你完成这个设置，并在管理员权限设置不足或者太多时进行提醒。

当设置太多管理员用户时ESP会进行提醒
2. 在实例需要访问其他AWS服务时为其配置IAM Roles
常见用例是存储或者检索S3 bucket、SQS、SNS等服务中的对象，更多信息可访问这里。在这个系列后续的博文中，我们将详细阐述EC2的Roles。
3. 在你的账户中开启Billing和Recovery相关功能
同样是登入root user的前提下，进入 My Account并填写以下几个信息：Alternate Contacts、Security Challenge Questions和IAM User Access to Billing Information。

在移除root 账户和 API访问秘钥之前，一个新的AWS账户需要完整填写上述信息
首先，你的内部邮件分发列表将能够分别从AWS收到与账户相关的支持、账单及安全提醒，当然这个邮件列表是你注册到AWS时所设定的。
其次，最重要的是，当你丢失root账户凭证或者更糟糕的状况发生时，你可以恢复你的账户，如果你为root账户或者IAM凭证做了相关折中设置。
最后，通过IAM用户你可以设置和获得账单分析数据，这样你就可以搭配使用类似Cloudability的第三方花费管理平台。

AWS安全最佳实践#2：在任何时候开启MFA令牌
本文章属于AWS安全最佳实践的第二篇。在上篇禁用root API访问秘钥的文章中，我们推荐建立至少2个（不超过3个）的IAM用户来代替root AWS用户。之所以建立2个是为了避免单点故障（Single Point of Failure），而不超过3个则是为了更好的掌控（这一点我们将在后续的博文中详述）。这篇文章我们将深入探讨Multi-Factor Authentication（MFA），讲述你需要它的原因和需要使用它的地方，同时我们还将分析为什么缺少它基础设施就会存在安全隐患。
在任何时候开启MFA令牌
如果你已经完成了本系列第一篇文章中的操作，那么你现在已经使用IAM替代了原有的root账户，现在我们来谈谈Multi-Factor Authentication（MFA）。首先，什么是MFA？我们不妨看看AWS MFA 页面中的一段介绍：“一个简单的最佳实践，它会在username和password上添加一个额外的安全层”。在这个页面中，你可以获得配置MFA的详细信息，那么它究竟是什么？简单的说，它是一个安全层，多于一种类型的身份验证。因此，你的密码可以是一种类型的身份验证，它可以喝其他类型的认证一起组成一个MFA。安全，就是这么简单。
MFA通常通过添加一个与用户名和密码独立的物理或者虚拟设备实现。这些设备会产生随机值来补充用户名和密码组合，从而更好地验证用户身份。在技术公司蓬勃发展的当下，使用物理令牌来补充密钥已经非常常见，使用移动设备上的App也非常常见（可能这种方式更容易被人们接受，同时也不容易丢失）。作为对字母数字的补充，生物识别技术也愈来愈普遍，设备通过扫描人体的不同部分进行身份验证，比如视网膜、指纹等。
那么，我们为什么需要添加一个额外的安全层？在现实世界中，你看电影的时候不可能永远坐在最后一排，你偶尔也会看到前方的人为了订购一杯拿铁在App上键入密码，你更避免不了无处不在的摄像头监视……在你周围，监视和记录已经无处不在。当今社会已经不再是那个只在图书馆监视电子邮件的时代了。
时至今日，攻破只使用用户名和密码的身份验证已不再是难题。只看看各大门户的头条，或大或小的公司出现密码丢失和被窃取的情况已不再罕见。同时，这类事件已影响到所有人，不再只针对那些位高权重的人物，它涉及到所有进行数据访问的人和设备。作为一个例子，你可以想象一下用户名和密码可以完成的操作，如果它们一旦出现在搜索引擎上，那么将给你或者你的公司带来什么样的风险？除此之外，又有多少用户或者应用程序认证在公共源代码控制中被捕获？而这里需要注意的是，AWS Identity and Access Controls可能提供的不仅仅是基础设施访问权限，同样还包含了其中的应用程序和数据。
时下，你已经可以看到许多在传统安全实践上的努力，比如最小密码长度限制、密码复杂性需求、密码更换周期缩短，以及各种措施的组合。然而这些措施看起来也许不错，事实上它们可能适得其反。有一些常见的例子就是：使用一些相似密码组成的循环图样将密码储存在一个电子邮件或者文字信息中（现在的版本是将它写在键盘或者显示器上），给密码加上一个字母，亦或是交叉易记的单词和特殊字符。需要注意的是，这些方式可能永远达不到预期的作用。在这些例子中，增加安全需求其实导致了更多的隐患，这些漏洞在为身份验证带来帮助之前已经对安全产生隐患。可以想象，有多少公司密码寄托在一个用户的私人邮件账户中，它们完全脱离了业务的控制。
鉴于潜在的安全隐患以及它所造成的不良后果，在这里添加一个额外的安全层将非常有意义业务的未来。既然如此，一个已有密码策略搭配附加安全层可以为业务和用户带来好处，并让你时刻保持安全，那么如何才能在AWS上实现MFA？
在AWS友好的MFA中，你首先需要一个物理或者虚拟设备。再次提示， AWS MFA页面提供了一个兼容设备列表，它可以指导你很好的起步。同时需要注意的是，不是所有MFA都被AWS支持，因此你首先需要检查这个。当你选择一个MFA之后，首先考虑如何让它与你的工作流集合，以及在丢失后如何恢复，比如它们真的丢失了或者移动设备更换。
AWS为MFA设置和使用提供了非常好的第三方支持：
1. User Console - Securing-access-to-AWS-using-MFA-Part-I
2. Programmatic API Access - Securing-access-to-AWS-using-MFA-Part-
3. S3 Versioning - Securing-access-to-AWS-using-MFA-Part-
请仔细阅读这些指南，并检查嵌入你业务的每个安全层，从而阻止你公司因为密码泄露出现在明天的媒体头条上。同时，你需要确保你的灾难恢复计划已经包括了你所实现的安全计划。

AWS安全最佳实践#3：通过Admin权限减少IAM用户的数量
本文章属于AWS安全最佳实践的第三篇。按照前两篇文章的进展，我们禁用了AWS root用户——移除了所有root密钥，为其分配MFA，随后销毁或者丢弃它们。这样一来，Root用户不再对AWS环境进行访问，以往的操作将通过新建立的IAM用户完成。这样做就能万无一失了么？简而言之，上述操作只完成了这个系列博文教材的前两步。因此，在本期中，我们将概述下一个问题：当你离家度假，并锁住了房间，那么有多少人可以继续进入你的房间，谁又拥有这个房间的钥匙？
通过Admin权限减少IAM用户的数量
事实上，这就是博文上述问题，究竟有多少人进入了你的房间，因此我们可以通过很简单的描述回答。
当你离开家，你通常会对进入房间的钥匙进行规划，并将它们交给合适的人。这些钥匙的设置通常会基于多个原因，比如：首先，你的管家可能拥有所有房间的钥匙，除下橱柜里的暗格（或者保险箱），但毫无疑问的是，你会对管家的身份进行严格的审查；其次，你可能也会给一些近亲或者好友钥匙；最后，为了防止钥匙被遗忘进房间或者其他原因，你可能还会拥有一些备份钥匙。这些逻辑同样可以映射到AWS基础设施访问权限的设置上——基于种种原因指定用户权限。
着眼美国的邮政服务。在你离家时，他们同样希望可以正常投递。那么他们是否可以拥有你家的钥匙？通常情况下，他们应该可以访问你的邮箱，但是也只限于邮箱。取代允许当地邮政运营商将邮件放到厨房的某个角落，你会给其规划一个独立的访问空间，因为你做不到对他们的完全信任。在你度假的过程中，如果你的邮箱钥匙被破坏，那么你完全可以清楚你所面临的风险。但是一旦本地邮政运营商拥有你房间的钥匙，并将它丢失，那么你的旅程很显然会被缩短。
在分配AWS控制权上，这个方法同样需要考虑。在每个钥匙的设定上，你需要考虑的都应该是最小权限。比如：为了执行某个任务，这个用户或者应用程序究竟需要获得哪些权限？在密钥丢失或者被攻破的情况下，机构究竟会面临一个什么样的风险？在得失计算上是否会涉及到知识产权和金融相关？造成的结果是否会对收入及名誉产生影响？显然，把权限划分的越细，密钥丢失或被攻破所造成的损失越小。
这里有一些例子：
如果你的EC2应用程序需要存储数据到S3，那么是否需要考虑相同的应用程序也具备了发布更多像这样EC2实例的能力？
在AWS，你完全不需要考虑这一点，AWS IAM通过给EC2实例指配“Role”让其获得存储的能力，但也只限于存储，任何应用程序都无法获得非指定权限，更多详情可访问 Using EC2 Instance Roles一文。它的优点是，你不再需要整合键到应用程序或者实例；建立一个拥有特定权限的组，简单的把实例划进去就好了。在这个系列的“利用EC2的Roles功能”一节中，我们将详细介绍这个功能。
这里还存在一个类似的情况，你是否期望每个IAM用户都拥有删除S3 buckets的权限？在实际应用中，大部分情况下你可能都不期望如此，在多数情况下，IAM用户都被赋予AWS环境的完全访问权限，包括所有服务的建立和删除操作。然而，鉴于云计算的低存储成本，控制用户和应用程序的删除权限绝对是个值得推荐的最佳实践。在AWS中，你可以很便捷地给IAM用户限制删除信息的能力，Using IAM Policies to Control Bucket Access 一文可以帮助你进行设置。而在这个系列博文的“认真对待world-readable/listable S3 bucket策略”一节，我们将对这个设置进行详细讨论。
在AWS中，有很多途径来实现最小权限设置，而在传统的企业基础设施中，这个操作实现起来并不轻松。
虽然限制访问是一个不错的最佳实践，但是很多情况下有些处理同样需要我们提升权限。实际工作中，你可能需要一个用户来删除S3对象，你也可能在离开时赋予某个用户管理员权限。就像在度假中，你可能期望赋予某个人进入你家的权力，并期望在回家后就回这个权力。这是个临时的密钥，AWS允许你给任何用户赋予一些临时的权力，并在任何时候收回。Evident.io Security Platform可以代表你(ESP)通过 Security Token Service 来设置只读API调用。你可以通过AWS来控制认证信息期满，从而避免提供任何的静态密钥。
AWS安全最佳实践#4：利用EC2的Roles功能
经过阅读这个系列的前三篇文章你就会发现，本AWS安全主题基本上都是通过预处理完成的。而主动防御的要旨就在于降低非法分子的可攻击空间，随着可攻击空间不断越少，机构受到的损失就会越小。毫无疑问，更少破坏就意味着你可以拥有更多时间去休息、游戏、度假等等。
在这之前，我们通过禁用root账户、多重身份验证、控制管理员数量来进行主动防御。在本期，我们将进入AWS应用程序部署的DevOps世界。
本系列博文主要包括：
1. 禁用root API访问秘钥
2. 在任何时候开启MFA令牌
3. 通过Admin权限减少IAM用户的数量
4. 利用EC2的Roles功能
5. 最小化特权：通过strong/explicit策略限制IAM实体行为
6. 定期循环所有秘钥
7. 在任何可能的地方通过STS AssumeRole来设置IAM角色
8. 使用AutoScaling来抑制DDoS攻击
9. 除非你有怪癖，在任何EC2/ELB 安全组中都禁用0.0.0.0/0
10. 认真对待world-readable/listable S3 bucket策略
最佳实践四：利用EC2的Roles功能
如果你需要在AWS上部署的不只是一个简单的网络服务器，那么很快你就会看向AWS巨大的服务列表。实际上之所以使用AWS，我们肯定期望使用这些服务做一些令人敬佩的事情，同时以一个非常小的技术成本。
假如你期望EC2实例上的应用程序可以在S3上存储数据，通过SQS队列或任意AWS服务组合来处理数据，那么你必须获得使用各个服务API的许可。而在AWS上，与API交互的唯一许可就是认证令牌。AWS通过API Access和Secret keys来实现认证令牌，运行在EC2实例上的应用程序必须使用这个密钥与S3匹配。
为了实现这些操作，其中的一个途径就是建立一个IAM用户，为这个用户生成 Access Key，并将其放入一个配置文件供应用程序读取。
因此，一个巨大的问题出现。既然这个文件是可读的，而权限则基于这个密钥所有者IAM用户所获得的许可，这就可能产生巨大的安全隐患。还记得这个系列上篇博文中关于管理员用户的介绍？不错，如果这个密钥来自管理员用户，那么它将获得访问所有AWS服务和资源的权限。发挥一下你的想象力，如果这个拥有 Access key的EC2实例被破解会发生什么样的事情。
在Evident.io，我们看到的一个顶级安全问题就是IAM凭证被窃取。这些事件发生的大多数原因都是因为意外非恶意情况下的API Access key泄露，其中包括代码提交到一个GitHub repo，或者将配置文件放到一个公开的 S3 bucket上。
在过去，我们通过组合使用配置管理、文件加密、EC2实例元数据等途径来增加Access key的读取难度。然而，这些方法都不是非常理想的。
推荐阅读IAM Roles for EC2。
在AWS中，IAM允许用户建立Role。而在Role上，你可以强制它使用 AWS Security Token Service。换句话说，一个IAM用户可以通过Role来增加它们的特权等级。同时，Role还可以与其他服务（比如SAML）联合使用为公司目录增加 Identity Federation保障。最后，Role还可以授权第三方机构（比如Evident.io）来访问你的资源。在实际应用中，Evident.io所有第三方访问都应该通过Role实现，家的唯一钥匙必须由自己管理。
在AWS，EC2实例同样被允许获得Role证书。那么，应用程序又该如何获得这些证书？
如果你使用了官方的AWS SDKs 或者AWS CLI，这里基本上不需要任何额外工作。这些SDK清楚如何为EC2实例获取STS生成的临时证书。即使你编写的应用程序没有使用任何AWS SDK，你仍然可以通过EC2实例的元数据服务获取这个证书。
推荐阅读文档
$ curl http://169.254.169.254/latest/meta-data/iam/security-credentials/s3access
结果
{
"Code" : "Success",
"LastUpdated" : "2012-04-26T16:39:16Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "AKIAIOSFODNN7EXAMPLE",
"SecretAccessKey" : "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"Token" "token",
"Expiration" : "2012-04-27T22:39:16Z"
}
这个Access和Secret Key可以被任何需要AWS证书的代码使用。
从安全的角度来看，通过以下5个最佳实践我们可以将事情完成的非常好：
1. 减少可攻击空间
对于一个EC2实例来说，EC2 Role证书是唯一的，如果一个实例被破解，你只需要终止这个实例并通过AutoScaling发布一个新实例。对比轮转IAM Access Key，这个操作非常简单。
2. 临时身份验证证书
令牌期满后，STS会自动轮转证书，SDKs 和CLI可帮助你自动化这个操作。
3. 可审计活动
你可以通过AWS CloudTrail服务（
4. 自动化化生成身份验证证书
分配给IAM用户的Access Key并不是静态的，因此不必要在配置文件中存储。
5. 特权限制
Role通过IAM策略分配，因此你可以指定Role的可访问AWS服务和资源。如果一组实例需要给一个指定的SNS话题发送信息，那么你可以在策略中将它限制到这个话题的ARN。
这么做还有一个好处就是，在DevOps上，你不需要再去操心给部署脚本提供Access Keys，或者在使用EC2上的部署工具链时还需要设计一个加密数据包。在给应用程序部署分配AWS Access Keys时，你拥有了一个简单、内嵌的途径。

AWS安全最佳实践#5：最小化权限
在这个系列的前几篇博文中，我们讨论了如何让EC2实例更安全地使用AWS服务，其中提到最多的就是减少密钥数量。在之前我们也讨论过，使用Roles一个更潜在的好处就是控制EC2实例所拥有的权限。在这篇博文中，我们就会深入探讨这个问题。
提醒一下，本系列博文主要包括：
1. 禁用root API访问秘钥
2. 在任何时候开启MFA令牌
3. 通过Admin权限减少IAM用户的数量
4. 利用EC2的Roles功能
5. 最小化权限：通过strong/explicit策略限制IAM实体行为
6. 定期循环所有秘钥
7. 在任何可能的地方通过STS AssumeRole来设置IAM角色
8. 使用AutoScaling来抑制DDoS攻击
9. 除非你有怪癖，在任何EC2/ELB 安全组中都禁用0.0.0.0/0
10. 认真对待world-readable/listable S3 bucket策略
最佳实践五：最小化权限——通过strong/explicit策略限制IAM实体行为
如果你有一个文件用于处理对一个S3 bucket有存储和检索文件需求的应用程序，从SQS中取得它的任务列表，并且需要给另一个应用程序发送作业的完成通知。
而在AWS服务中，也只有应用程序调用AWS API服务时才会被验证。同时，在上文中，我们提到Roles使用AWS STS为应用程序取得一个临时的验证令牌。那么我如何才能保证，应用程序只为S3、SQS和SNS使用这个服务。
最小化权限：在权限分配上，系统中每个程序和用户都应该只获得完成这个作业的最小权限子集。首先，通过这个原则可以最小化事故或者错误发生时产生的不良影响。其次，将权限应用程序间交互降到最低有助于进行正确的操作，从而非故意、不需要或者不正确的权限使用将很少发生。这样依赖，如果一个错误因某个权限误用产生，需要审查的应用程序数量也可以降到最低。换句话说，如果有个机制可以提供“防火墙”特性，最小化权限设计提供了防火墙选址的基本原则。军事安全中的“need-to-know”就是这个原则的一个体现。
AWS IAM Policies让我们可以在IAM实体上实现Least Privilege 这个理念。IAM就是一个用户，用户可以在IAM服务中建立Groups或者Roles。通过使用策略来限制EC2 Role的访问，用户可以保证EC2实例只做该做的事情。
同时，通过明确某个服务API可以访问的资源，IAM策略还可以进一步控制 API调用S3、SQS和SNS的范围和目标。换句话说，用户不仅可以限制EC2实例到使用S3 PutObject，还可以将其限制到某个S3 Bucket的访问。S3是一个非常特殊的服务，通过S3 Bucket Policy，用户可以进一步限制S3 bucket中的访问权限。在S3安全访问上，我们将更深入的讨论 IAM和 S3 bucket策略。
在某个EC2 Role失控时，通过权限控制，影响可以被控制到可预知范围。如果失控的是管理员权限，那么影响可能扩大到所有AWS服务。
在与开发人员交流时了解到，他们应用程序只需要S3 GetObject、S3 PutObject、SQS ReceiveMessage、SQS SendMessage和SNS Publish权限。因此这里只存在5个服务API调用，或者在IAM Policy 文档语言的5个action。同时，还有基于指定资源的Bucke、SQS Queue和SNS Topic。
用户还可以使用AWS Policy Generator工具来建立一个策略文档，随后将IAM Role与应用程序的EC2实例关联。生成的策略文档如下所示，它可以立即被附属于一个IAM实体上的管理策略和内联策略。
{
"Statement": [
{
"Sid": "Stmt1426373228429",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::MyCoolBucket/apps"
},
{
"Sid": "Stmt1426373293262",
"Action": [
"sqs:ReceiveMessage",
"sqs:SendMessage"
],
"Effect": "Allow",
"Resource": "arn:aws:sqs:us-east-1:222222222222:MyAppQueue"
},
{
"Sid": "Stmt1426373337375",
"Action": [
"sns:Publish"
],
"Effect": "Allow",
"Resource": "arn:aws:sns:us-east-1:222222222222:MyAppTopic"
}
]
}
那么，一个管理员权限的策略文档是什么样的？我查询了aws-cli，并找到了AdministratorAccess AWS-managed 权限的 IAM Policy最新版本文档：
$ aws iam get-policy-version --policy-arn arn:aws:iam::aws:policy/AdministratorAccess --version-id v1
{
"PolicyVersion": {
"CreateDate": "2015-02-06T18:39:46Z",
"VersionId": "v1",
"Document": {
"Version": "2012-10-17",
"Statement": [
{
"Action": "*",
"Resource": "*",
"Effect": "Allow"
}
]
},
"IsDefaultVersion": true
}
}
如你所见，对于IAM User来说，Group或Role这种等级的权限可以带来非常显著的效果。