aws安全实践.docx
《aws安全实践.docx》由会员分享，可在线阅读，更多相关《aws安全实践.docx（15页珍藏版）》请在冰点文库上搜索。
aws安全实践
AWS安全实践
AWS安全最佳实践#1：
禁用rootAPI访问密钥2
AWS安全最佳实践#2：
在任何时候开启MFA令牌5
AWS安全最佳实践#3：
通过Admin权限减少IAM用户的数量7
AWS安全最佳实践#4：
利用EC2的Roles功能9
AWS安全最佳实践#5：
最小化权限13
标签：
安全,AmazonWebServices,应用,aws
AWS安全最佳实践#1：
禁用rootAPI访问密钥
从本文起，我们开始撰写一系列博文来总结AWS安全相关的十大最佳实践，这些经验总结来自安全工作者和AWS工作人员的大规模AWS部署实践。
其部分操作起来都非常简单，但却影响着AWS实践的成败。
在AWS的说明中，“root”用户是用来建立AWS账户的登录凭证。
曾今，在连接AWS服务的许多地方都必须使用“root”用户。
然而，时至今日，“root”用户在AWS基础设施运维中已经可有可无。
在这里，我们推荐禁用这个用户，甚至是删除AWSrootAPI访问密钥。
使用root用户登录SecurityCredentialspage，删除或者禁止任何你可以看到的访问秘钥。
进入Credentials页面时收到的AWS控制台警告
在禁用AWS访问密钥之前，你还需要一些准备工作。
1.通过管理策略建立至少2个（不超过3个）IAM用户
需要注意的是，你肯定不期望将每个IAM用户都设置为管理员用户！
EvidentSecurityPlatform（ESP）可以帮助你完成这个设置，并在管理员权限设置不足或者太多时进行提醒。
当设置太多管理员用户时ESP会进行提醒
2.在实例需要访问其他AWS服务时为其配置IAMRoles
常见用例是存储或者检索S3bucket、SQS、SNS等服务中的对象，更多信息可访问这里。
在这个系列后续的博文中，我们将详细阐述EC2的Roles。
3.在你的账户中开启Billing和Recovery相关功能
同样是登入rootuser的前提下，进入MyAccount并填写以下几个信息：
AlternateContacts、SecurityChallengeQuestions和IAMUserAccesstoBillingInformation。
在移除root账户和API访问秘钥之前，一个新的AWS账户需要完整填写上述信息
首先，你的部分发列表将能够分别从AWS收到与账户相关的支持、账单及安全提醒，当然这个列表是你注册到AWS时所设定的。
其次，最重要的是，当你丢失root账户凭证或者更糟糕的状况发生时，你可以恢复你的账户，如果你为root账户或者IAM凭证做了相关折中设置。
最后，通过IAM用户你可以设置和获得账单分析数据，这样你就可以搭配使用类似Cloudability的第三方花费管理平台。
AWS安全最佳实践#2：
在任何时候开启MFA令牌
本文章属于AWS安全最佳实践的第二篇。
在上篇禁用rootAPI访问秘钥的文章中，我们推荐建立至少2个（不超过3个）的IAM用户来代替rootAWS用户。
之所以建立2个是为了避免单点故障（SinglePointofFailure），而不超过3个则是为了更好的掌控（这一点我们将在后续的博文中详述）。
这篇文章我们将深入探讨Multi-FactorAuthentication（MFA），讲述你需要它的原因和需要使用它的地方，同时我们还将分析为什么缺少它基础设施就会存在安全隐患。
在任何时候开启MFA令牌
如果你已经完成了本系列第一篇文章中的操作，那么你现在已经使用IAM替代了原有的root账户，现在我们来谈谈Multi-FactorAuthentication（MFA）。
首先，什么是MFA？
我们不妨看看AWSMFA页面中的一段介绍：
“一个简单的最佳实践，它会在username和password上添加一个额外的安全层”。
在这个页面中，你可以获得配置MFA的详细信息，那么它究竟是什么？
简单的说，它是一个安全层，多于一种类型的身份验证。
因此，你的密码可以是一种类型的身份验证，它可以喝其他类型的认证一起组成一个MFA。
安全，就是这么简单。
MFA通常通过添加一个与用户名和密码独立的物理或者虚拟设备实现。
这些设备会产生随机值来补充用户名和密码组合，从而更好地验证用户身份。
在技术公司蓬勃发展的当下，使用物理令牌来补充密钥已经非常常见，使用移动设备上的App也非常常见（可能这种方式更容易被人们接受，同时也不容易丢失）。
作为对字母数字的补充，生物识别技术也愈来愈普遍，设备通过扫描人体的不同部分进行身份验证，比如视网膜、指纹等。
那么，我们为什么需要添加一个额外的安全层？
在现实世界中，你看电影的时候不可能永远坐在最后一排，你偶尔也会看到前方的人为了订购一杯拿铁在App上键入密码，你更避免不了无处不在的摄像头监视……在你周围，监视和记录已经无处不在。
当今社会已经不再是那个只在图书馆监视电子的时代了。
时至今日，攻破只使用用户名和密码的身份验证已不再是难题。
只看看各大门户的头条，或大或小的公司出现密码丢失和被窃取的情况已不再罕见。
同时，这类事件已影响到所有人，不再只针对那些位高权重的人物，它涉及到所有进行数据访问的人和设备。
作为一个例子，你可以想象一下用户名和密码可以完成的操作，如果它们一旦出现在搜索引擎上，那么将给你或者你的公司带来什么样的风险？
除此之外，又有多少用户或者应用程序认证在公共源代码控制中被捕获？
而这里需要注意的是，AWSIdentityandAccessControls可能提供的不仅仅是基础设施访问权限，同样还包含了其中的应用程序和数据。
时下，你已经可以看到许多在传统安全实践上的努力，比如最小密码长度限制、密码复杂性需求、密码更换周期缩短，以及各种措施的组合。
然而这些措施看起来也许不错，事实上它们可能适得其反。
有一些常见的例子就是：
使用一些相似密码组成的循环图样将密码储存在一个电子或者文字信息中（现在的版本是将它写在键盘或者显示器上），给密码加上一个字母，亦或是交叉易记的单词和特殊字符。
需要注意的是，这些方式可能永远达不到预期的作用。
在这些例子中，增加安全需求其实导致了更多的隐患，这些漏洞在为身份验证带来帮助之前已经对安全产生隐患。
可以想象，有多少公司密码寄托在一个用户的私人账户中，它们完全脱离了业务的控制。
鉴于潜在的安全隐患以及它所造成的不良后果，在这里添加一个额外的安全层将非常有意义业务的未来。
既然如此，一个已有密码策略搭配附加安全层可以为业务和用户带来好处，并让你时刻保持安全，那么如何才能在AWS上实现MFA？
在AWS友好的MFA中，你首先需要一个物理或者虚拟设备。
再次提示，AWSMFA页面提供了一个兼容设备列表，它可以指导你很好的起步。
同时需要注意的是，不是所有MFA都被AWS支持，因此你首先需要检查这个。
当你选择一个MFA之后，首先考虑如何让它与你的工作流集合，以及在丢失后如何恢复，比如它们真的丢失了或者移动设备更换。
AWS为MFA设置和使用提供了非常好的第三方支持：
1.UserConsole-Securing-access-to-AWS-using-MFA-Part-I
2.ProgrammaticAPIAccess-Securing-access-to-AWS-using-MFA-Part-
3.S3Versioning-Securing-access-to-AWS-using-MFA-Part-
请仔细阅读这些指南，并检查嵌入你业务的每个安全层，从而阻止你公司因为密码泄露出现在明天的媒体头条上。
同时，你需要确保你的灾难恢复计划已经包括了你所实现的安全计划。
AWS安全最佳实践#3：
通过Admin权限减少IAM用户的数量
本文章属于AWS安全最佳实践的第三篇。
按照前两篇文章的进展，我们禁用了AWSroot用户——移除了所有root密钥，为其分配MFA，随后销毁或者丢弃它们。
这样一来，Root用户不再对AWS环境进行访问，以往的操作将通过新建立的IAM用户完成。
这样做就能万无一失了么？
简而言之，上述操作只完成了这个系列博文教材的前两步。
因此，在本期中，我们将概述下一个问题：
当你离家度假，并锁住了房间，那么有多少人可以继续进入你的房间，谁又拥有这个房间的钥匙？
通过Admin权限减少IAM用户的数量
事实上，这就是博文上述问题，究竟有多少人进入了你的房间，因此我们可以通过很简单的描述回答。
当你离开家，你通常会对进入房间的钥匙进行规划，并将它们交给合适的人。
这些钥匙的设置通常会基于多个原因，比如：
首先，你的管家可能拥有所有房间的钥匙，除下橱柜里的暗格（或者保险箱），但毫无疑问的是，你会对管家的身份进行严格的审查；其次，你可能也会给一些近亲或者好友钥匙；最后，为了防止钥匙被遗忘进房间或者其他原因，你可能还会拥有一些备份钥匙。
这些逻辑同样可以映射到AWS基础设施访问权限的设置上——基于种种原因指定用户权限。
着眼美国的邮政服务。
在你离家时，他们同样希望可以正常投递。
那么他们是否可以拥有你家的钥匙？
通常情况下，他们应该可以访问你的，但是也只限于。
取代允许当地邮政运营商将放到厨房的某个角落，你会给其规划一个独立的访问空间，因为你做不到对他们的完全信任。
在你度假的过程中，如果你的钥匙被破坏，那么你完全可以清楚你所面临的风险。
但是一旦本地邮政运营商拥有你房间的钥匙，并将它丢失，那么你的旅程很显然会被缩短。
在分配AWS控制权上，这个方法同样需要考虑。
在每个钥匙的设定上，你需要考虑的都应该是最小权限。
比如：
为了执行某个任务，这个用户或者应用程序究竟需要获得哪些权限？
在密钥丢失或者被攻破的情况下，机构究竟会面临一个什么样的风险？
在得失计算上是否会涉及到知识产权和金融相关？
造成的结果是否会对收入及名誉产生影响？
显然，把权限划分的越细，密钥丢失或被攻破所造成的损失越小。
这里有一些例子：
如果你的EC2应用程序需要存储数据到S3，那么是否需要考虑相同的应用程序也具备了发布更多像这样EC2实例的能力？
在AWS，你完全不需要考虑这一点，AWSIAM通过给EC2实例指配“Role”让其获得存储的能力，但也只限于存储，任何应用程序都无法获得非指定权限，更多详情可访问UsingEC2InstanceRoles一文。
它的优点是，你不再需要整合键到应用程序或者实例；建立一个拥有特定权限的组，简单的把实例划进去就好了。
在这个系列的“利用EC2的Roles功能”一节中，我们将详细介绍这个功能。
这里还存在一个类似的情况，你是否期望每个IAM用户都拥有删除S3buckets的权限？
在实际应用中，大部分情况下你可能都不期望如此，在多数情况下，IAM用户都被赋予AWS环境的完全访问权限，包括所有服务的建立和删除操作。
然而，鉴于云计算的低存储成本，控制用户和应用程序的删除权限绝对是个值得推荐的最佳实践。
在AWS中，你可以很便捷地给IAM用户限制删除信息的能力，UsingIAMPoliciestoControlBucketAccess一文可以帮助你进行设置。
而在这个系列博文的“认真对待world-readable/listableS3bucket策略”一节，我们将对这个设置进行详细讨论。
在AWS中，有很多途径来实现最小权限设置，而在传统的企业基础设施中，这个操作实现起来并不轻松。
虽然限制访问是一个不错的最佳实践，但是很多情况下有些处理同样需要我们提升权限。
实际工作中，你可能需要一个用户来删除S3对象，你也可能在离开时赋予某个用户管理员权限。
就像在度假中，你可能期望赋予某个人进入你家的权力，并期望在回家后就回这个权力。
这是个临时的密钥，AWS允许你给任何用户赋予一些临时的权力，并在任何时候收回。
Evident.ioSecurityPlatform可以代表你（ESP）通过SecurityTokenService来设置只读API调用。
你可以通过AWS来控制认证信息期满，从而避免提供任何的静态密钥。
AWS安全最佳实践#4：
利用EC2的Roles功能
经过阅读这个系列的前三篇文章你就会发现，本AWS安全主题基本上都是通过预处理完成的。
而主动防御的要旨就在于降低非法分子的可攻击空间，随着可攻击空间不断越少，机构受到的损失就会越小。
毫无疑问，更少破坏就意味着你可以拥有更多时间去休息、游戏、度假等等。
在这之前，我们通过禁用root账户、多重身份验证、控制管理员数量来进行主动防御。
在本期，我们将进入AWS应用程序部署的DevOps世界。
本系列博文主要包括：
1.禁用rootAPI访问秘钥
2.在任何时候开启MFA令牌
3.通过Admin权限减少IAM用户的数量
4.利用EC2的Roles功能
5.最小化特权：
通过strong/explicit策略限制IAM实体行为
6.定期循环所有秘钥
7.在任何可能的地方通过STSAssumeRole来设置IAM角色
8.使用AutoScaling来抑制DDoS攻击
9.除非你有怪癖，在任何EC2/ELB安全组中都禁用0.0.0.0/0
10.认真对待world-readable/listableS3bucket策略
最佳实践四：
利用EC2的Roles功能
如果你需要在AWS上部署的不只是一个简单的网络服务器，那么很快你就会看向AWS巨大的服务列表。
实际上之所以使用AWS，我们肯定期望使用这些服务做一些令人敬佩的事情，同时以一个非常小的技术成本。
假如你期望EC2实例上的应用程序可以在S3上存储数据，通过SQS队列或任意AWS服务组合来处理数据，那么你必须获得使用各个服务API的许可。
而在AWS上，与API交互的唯一许可就是认证令牌。
AWS通过APIAccess和Secretkeys来实现认证令牌，运行在EC2实例上的应用程序必须使用这个密钥与S3匹配。
为了实现这些操作，其中的一个途径就是建立一个IAM用户，为这个用户生成AccessKey，并将其放入一个配置文件供应用程序读取。
因此，一个巨大的问题出现。
既然这个文件是可读的，而权限则基于这个密钥所有者IAM用户所获得的许可，这就可能产生巨大的安全隐患。
还记得这个系列上篇博文中关于管理员用户的介绍？
不错，如果这个密钥来自管理员用户，那么它将获得访问所有AWS服务和资源的权限。
发挥一下你的想象力，如果这个拥有Accesskey的EC2实例被破解会发生什么样的事情。
在Evident.io，我们看到的一个顶级安全问题就是IAM凭证被窃取。
这些事件发生的大多数原因都是因为意外非恶意情况下的APIAccesskey泄露，其中包括代码提交到一个GitHubrepo，或者将配置文件放到一个公开的S3bucket上。
在过去，我们通过组合使用配置管理、文件加密、EC2实例元数据等途径来增加Accesskey的读取难度。
然而，这些方法都不是非常理想的。
推荐阅读IAMRolesforEC2。
在AWS中，IAM允许用户建立Role。
而在Role上，你可以强制它使用AWSSecurityTokenService。
换句话说，一个IAM用户可以通过Role来增加它们的特权等级。
同时，Role还可以与其他服务（比如SAML）联合使用为公司目录增加IdentityFederation保障。
最后，Role还可以授权第三方机构（比如Evident.io）来访问你的资源。
在实际应用中，Evident.io所有第三方访问都应该通过Role实现，家的唯一钥匙必须由自己管理。
在AWS，EC2实例同样被允许获得Role证书。
那么，应用程序又该如何获得这些证书？
如果你使用了官方的AWSSDKs或者AWSCLI，这里基本上不需要任何额外工作。
这些SDK清楚如何为EC2实例获取STS生成的临时证书。
即使你编写的应用程序没有使用任何AWSSDK，你仍然可以通过EC2实例的元数据服务获取这个证书。
推荐阅读文档
$curl169.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和SecretKey可以被任何需要AWS证书的代码使用。
从安全的角度来看，通过以下5个最佳实践我们可以将事情完成的非常好：
1.减少可攻击空间
对于一个EC2实例来说，EC2Role证书是唯一的，如果一个实例被破解，你只需要终止这个实例并通过AutoScaling发布一个新实例。
对比轮转IAMAccessKey，这个操作非常简单。
2.临时身份验证证书
令牌期满后，STS会自动轮转证书，SDKs和CLI可帮助你自动化这个操作。
3.可审计活动
你可以通过AWSCloudTrail服务（aws.amazon./cn/cloudtrail/）检测Role的行为。
4.自动化化生成身份验证证书
分配给IAM用户的AccessKey并不是静态的，因此不必要在配置文件中存储。
5.特权限制
Role通过IAM策略分配，因此你可以指定Role的可访问AWS服务和资源。
如果一组实例需要给一个指定的SNS话题发送信息，那么你可以在策略中将它限制到这个话题的ARN。
这么做还有一个好处就是，在DevOps上，你不需要再去操心给部署脚本提供AccessKeys，或者在使用EC2上的部署工具链时还需要设计一个加密数据包。
在给应用程序部署分配AWSAccessKeys时，你拥有了一个简单、嵌的途径。
AWS安全最佳实践#5：
最小化权限
在这个系列的前几篇博文中，我们讨论了如何让EC2实例更安全地使用AWS服务，其中提到最多的就是减少密钥数量。
在之前我们也讨论过，使用Roles一个更潜在的好处就是控制EC2实例所拥有的权限。
在这篇博文中，我们就会深入探讨这个问题。
提醒一下，本系列博文主要包括：
1.禁用rootAPI访问秘钥
2.在任何时候开启MFA令牌
3.通过Admin权限减少IAM用户的数量
4.利用EC2的Roles功能
5.最小化权限：
通过strong/explicit策略限制IAM实体行为
6.定期循环所有秘钥
7.在任何可能的地方通过STSAssumeRole来设置IAM角色
8.使用AutoScaling来抑制DDoS攻击
9.除非你有怪癖，在任何EC2/ELB安全组中都禁用0.0.0.0/0
10.认真对待world-readable/listableS3bucket策略
最佳实践五：
最小化权限——通过strong/explicit策略限制IAM实体行为
如果你有一个文件用于处理对一个S3bucket有存储和检索文件需求的应用程序，从SQS中取得它的任务列表，并且需要给另一个应用程序发送作业的完成通知。
而在AWS服务中，也只有应用程序调用AWSAPI服务时才会被验证。
同时，在上文中，我们提到Roles使用AWSSTS为应用程序取得一个临时的验证令牌。
那么我如何才能保证，应用程序只为S3、SQS和SNS使用这个服务。
最小化权限：
在权限分配上，系统中每个程序和用户都应该只获得完成这个作业的最小权限子集。
首先，通过这个原则可以最小化事故或者错误发生时产生的不良影响。
其次，将权限应用程序间交互降到最低有助于进行正确的操作，从而非故意、不需要或者不正确的权限使用将很少发生。
这样依赖，如果一个错误因某个权限误用产生，需要审查的应用程序数量也可以降到最低。
换句话说，如果有个机制可以提供“防火墙”特性，最小化权限设计提供了防火墙选址的基本原则。
军事安全中的“need-to-know”就是这个原则的一个体现。
AWSIAMPolicies让我们可以在IAM实体上实现LeastPrivilege这个理念。
IAM就是一个用户，用户可以在IAM服务中建立Groups或者Roles。
通过使用策略来限制EC2Role的访问，用户可以保证EC2实例只做该做的事情。
同时，通过明确某个服务API可以访问的资源，IAM策略还可以进一步控制API调用S3、SQS和SNS的围和目标。
换句话说，用户不仅可以限制EC2实例到使用S3PutObject，还可以将其限制到某个S3Bucket的访问。
S3是一个非常特殊的服务，通过S3BucketPolicy，用户可以进一步限制S3bucket中的访问权限。
在S3安全访问上，我们将更深入的讨论IAM和S3bucket策略。
在某个EC2Role失控时，通过权限控制，影响可以被控制到可预知围。
如果失控的是管理员权限，那么影响可能扩大到所有AWS服务。
在与开发人员交流时了解到，他们应用程序只需要S3GetObject、S3PutObject、SQSReceiveMessage、SQSSendMessage和SNSPublish权限。
因此这里只存在5个服务API调用，或者在IAMPolicy文档语言的5个action。
同时，还有基于指定资源的Bucke、SQSQueue和SNSTopic。
用户还可以使用AWSPolicyGenerator工具来建立一个策略文档，随后将IAMRole与应用程序的EC2实例关联。
生成的策略文档如下所示，它可以立即被附属于一个IAM实体上的管理策略和联策略。
{
"Statement":
[
{
"Sid":
"Stmt29",
"Action":
[
"s3:
GetObject",
"s3:
PutObject"
],
"Effect":
"Allow",
"Resource":
"arn:
aws:
s3:
:
:
MyCoolBucket/apps"
},
{
"Sid":
"Stmt62",
"Action":
[
"sqs:
ReceiveMessage",
"sqs:
SendMessage"
],
"Effect":
"Allow",
"Resource":
"arn:
aws:
sqs:
us-east-1:
2:
MyAppQueue"
},
{
"Sid":
"Stmt75",
"Action":
[
"sns:
Publish"
],
"Effect":
"Allow",
"Resource":
"arn:
aws:
sns:
us-east-1:
2:
MyAppTopic"
}
]
}
那么，一个管理员权限的策略文档是什么样的？
我查询了aws-cli，并找到了AdministratorAccessAWS-managed权限的IAMPolicy最新版本文档：
$awsiamget-policy-version--policy-arnarn:
aws:
iam:
:
aws:
polic
升级会员 