bendan 2020-08-13
我想大家对 IAM 这个服务不会陌生,可能我们使用 AWS 云计算的第一个服务就是它,第一步就是需要创建账号授权等操作,它的全称是 Identity and Access Management,从名字我们可以知道,它是用来管理用户、访问密钥等安全凭证,以及控制用户和应用程序可以访问哪些 AWS 资源的权限的服务。
可以不过分的说,IAM 贯穿 AWS 云计算的各项服务,任何服务之间的请求都需要身份验证和授权,所有的身份验证和授权都由 IAM 这个服务来承担。正是因为 IAM 服务中的策略可以实现 API 级别细粒度的设置,所以我们可以对某个用户赋予特定 API 的操作权限,这样可以避免赋予过大的权限引起安全问题。
借助 AWS IAM 这项服务,使得我们在 AWS 云中的资源变得非常安全,任何用户想要访问云中的资源,哪怕是一个简单的 API 请求,都需要获得 IAM 的授权。除用户之外,你拥有的任何服务想要访问其他服务的数据,都需要经过 IAM 的验证和授权,可以说在 AWS 云中到处都是关卡,因此只要给用户合适的、最低的权限,我们的服务与数据将会变得很安全。
我们开发的应用程序,或多或少会去调用云中的资源,调用资源应用程序就需要有相应的权限,其他云厂商会要求用户去云中获取一个 AK/SK 凭证,然后通过其 SDK 集成来获得云中的资源,一般会 AK/SK 会写在代码中,然后发布到云中的虚拟机或者其他服务。总之这个密钥 AK/SK 是明文写在代码中,如果代码泄露,任何人都可以调用我们云中对应的资源,这将使我们的服务和数据变得非常不安全,并且这些凭证需要开发人员管理,也造成了大量的额外工作,那么 AWS 是如何解决这个问题的呢?
AWS IAM 为用户提供了角色这一身份,它类似于用户,角色访问云中的资源同样是需要 AK/SK 凭证,但又与用户不同的是,用户申请的凭证是永久的,而角色获取的凭证是临时的,这使得即便凭证泄露,也只会造成有限的影响。
那么整个使用流程是怎么样的呢?当我们启动 EC2 实例的时候,可以为其指定一个角色,并给这个角色赋予应用程序访问 AWS 资源的权限,IAM 将向 EC2 实例动态提供临时凭证,这些凭证会自动轮换。在 EC2 实例上运行的应用程序将 AWS 凭证包含在其 AWS API 请求中,这样我们的应用程序就可以安全的访问云中的资源了。当然是用角色这种方式有多种优势。因为角色凭证是临时的,并且会自动轮换,所以用户不必管理凭证,也不必担心长期安全风险。此外,如果多个实例使用单个角色,则可以对该角色进行更改,而此更改会自动传播到所有实例。
因为有了 IAM,我们在云资源访问上面可以做到非常细粒度的管控,从而保障云中资源可以互相安全的访问。但是不要认为在云中有了 IAM 就万事大吉,那我们继续了解 AWS 在其他安全方面做了哪些保障。
虽然我们通过 IAM 保障了在云中资源的安全,但是并不是所有的服务都可以透过 IAM 去进行管控。比如我们开发的应用程序,需要连接各式各样的数据库,而每种数据库都有自己的权限管控。
一般来说,我们都是把数据库的账户和密码明文的写在应用程序配置文件里,这就和上面案例出现一样的问题,如果代码泄露,那数据库登陆凭证必定也会泄露,这就可能导致我们的数据泄露,从而影响数据库安全,并且数据库凭证开发或者运维人员也相应都会知晓,这也增加了泄露的风险。面对这个问题,一般企业可能会把数据库置于内网中,让外网无法直接连接,这算是一种解决方案,但是数据库账户密码泄露这个隐患没有办法杜绝。
面对以上数据库凭证泄露问题,AWS 推出了轮换、管理和检索密钥服务 AWS Secrets Manager,它采用一种巧妙的方式解决了这个泄露问题。那我们下面介绍一下它的实现原理:
MyCustomAppCreds
的密钥存储在 Secrets Manager 中。然后,Secrets Manager 对凭证进行加密并将凭证作为<u>受保护的密钥文本</u>存储在密钥中。MyCustomAppCreds
的密钥。通过以上的步骤,我们可以看到,整个过程只有 Admin 数据库管理员一个人知道账号密码,开发 MyCustomApp 的人员不需要知道数据库账户密码。当然我们需要赋予 MyCustomAPP 所在 EC2 访问 Secrets Manager 的权限。通过这种方式,巧妙的解决了应用程序数据库凭证泄露的问题,数据库凭证完全由 Secrets Manager 进行管理,并且 Secrets Manager 可以对数据库凭证进行周期性的轮换,哪怕某个时段密钥泄露,也不会产生长远的安全问题。
Secrets Manager 还可以审核和监控密钥使用情况,任何查看密钥凭证的用户都会被记录下来,也在一定程度上面保障的密钥的安全。
当然这么好的服务是需要收费的,不过我也给大家透露一个免费的方式,那就是 AWS Systems Manager 中的 Parameter Store。如果你只想找一个凭证托管中心,不需要加密和轮换,那 Parameter Store 非常适合你,它的标准版是完全免费的,并且我们也可以把它当做我们的配置中心。
越来越多的地区和企业对数据的安全要求越来越严格,数据的安全有着存储加密安全和传输加密安全。
Google 从2016 年就将 Chrome 特性在非安全站点上禁用,同时新的特性将只支持 HTTPS,意在推进HTTPS 的普及。AWS 在数据加密传输上面也起着积极作用,用户可以通过 AWS Certificate Manager 申请免费的域名证书,让您的应用轻松升级为 HTTPS,保障数据在传输中的安全。
还有就是数据存储安全,对数据要求比较严格的企业,都会要求数据在静态存储的时候需要进行加密,那么在 AWS 云中各项数据的存储加密都是由 AWS Key Management Service(KMS)来管理。KMS 主要管理数据的加密密钥,主要采用信封加密,信封加密是一种加密方法,它使用数据密钥对明文数据进行加密,然后使用其他密钥对数据密钥进行加密。
KMS 可以和众多的 AWS 服务进行集成,保证数据在静态存储的时候加密安全,比如为 EBS 磁盘加密,保障 EBS 中数据的存储安全,我们前面说的 Secrets Manager,其对凭证的加密密钥也有 KMS 进行管理,可以说整个 AWS 云中数据的存储安全都由 KMS 来负责,可见这个服务的重要性。
KMS 还具有很多的其他特性,比如我们可以使用自定义密钥,对密钥的使用进行监控审计等。为了安全,开始对您的数据进行加密吧,整个过程只需要点点鼠标即可完成,非常方便。
用户迁移上云使用最多的服务是什么,想必应该都是云中的虚拟机,在 AWS 云中的虚拟机是 EC2,对于 EC2 的安全方面,AWS 做到了哪些加固呢?
首先在网络安全层面,在 VPC 中有安全组,我们可以只允许请求特定端口的流量进来,在一定程度上面保障了 EC2 的安全,不过 AWS Systems Manager 为我们提供了一个更新安全的方式,通过 Systems Manager 我们可以管理批量的 EC2 主机,为 EC2 系统定期更新最新的漏洞补丁,保障运行系统的安全。
我们远程 Linux 服务器使用 22 号端口,远程 Windows 使用 3389,这些都需要我们服务器运行相应的服务,开发服务就有被不发分子探测登陆,当你密码设置的比较简单的时候,机器很容易被人攻破,当然我们可以修改为其他端口,或者用安全组进行限制,这是一种方法。Systems Manager 中的 Session Manager 为我们提供了一种类似于堡垒机的服务,我们的 EC2 主机可以不用开启任何远程服务,只需要为其赋予具有访问 Systems Manager 权限的角色即可,我们直接通过 AWS Console 来远程操作我们的 EC2 主机,这让我们的机器变得很安全,并且所有的操作命令都会被记录下来,以便于进行审计。
我们在 EC2 上面安装了众多的应用软件,在 AWS 的安全服务中,有没有一项服务可以去扫描我们的系统和应用,去监测其中是否有潜在的风险问题呢?
当然也是有的,Amazon Inspector 是一项安全漏洞评估服务,它可自动评估资源以确定是否存在漏洞或者与最佳实践是否有偏差,然后创建按严重性级别进行优先级排序的详细安全结果列表,我们可以根据这个列表的建议,使用 Systems Manager 对 EC2 做批量更新。
Amazon Inspector 还有一个知识库,其中包含数百条与常见安全标准和漏洞定义相对应的规则,内置规则的示例包括检查从 Internet 对您的 EC2 实例进行的访问、当前启用的远程根登录,或已安装的易受***的软件版本,AWS 安全研究人员会定期更新这些规则,所以我们不必担心规则会过期等问题。
应用了这么多的安全相关的服务,相信你的应用环境已经很安全了吧,不过 AWS 还有很多保障你应用和数据安全的服务,我这里简单介绍一下:
AWS 对用户数据安全看的非常重要,保护客户数据是重中之重,因而推出众多的服务来保证数据和服务的安全。AWS 大规模地快速创新,不断将用户的反馈整个到云服务中,并且 AWS 还在持续升级核心安全服务来保障用户的数据。
AWS 负责云本身的安全,客户负责云中安全,这就是云计算中的共担责任。本文根据不同使用场景介绍 AWS 的安全服务,大家应该有了一个大概的了解,懂得上云之后的一些安全配置,有助于您制定自己的云中保障计划。