三大主流云计算的默认配置风险
默认云配置带来的危险
在涉及云的语境下听到“默认设置”这个词，你脑海中可能会浮现出一些东西：设置新应用时的默认管理员密码、公共AWS S3存储桶，或者默认用户访问权限。相比安全性，供应商往往更为重视客户眼中的可用性和易用性，导致默认设置大行其道。但有一点需要澄清：设置或控制措施是默认的，并不意味着就是推荐的或者安全的。
下面我们就来看看可能让企业陷入风险之中的几个默认设置案例。
Azure
不同于Azure SQL Managed Instances，Azure SQL Databases的内置防火墙可配置为允许服务器级或数据库级连接。这就给了用户很多选择可以用来确保正确的连接。
如果要让Azure内部的应用连接Azure SQL Database，可以用服务器的“Allow Azure Services”设置，将起始和结束IP地址设置为0.0.0.0。名为“AllowAllWindowsAzureIps”的设置听起来似乎无害，但这个选项会将Azure SQL Database防火墙配置为不仅允许来自你自家Azure配置的所有连接，也允许来自任意Azure配置的所有连接。开启这个功能，你的数据库就向来自其他客户的连接敞开了大门，给登录和身份管理带来了更大压力。
需要注意的是，Azure SQL Database是否允许任意公共IP地址连接。这么做不寻常，而且，尽管可以用默认设置，但不意味着就应该用。你应该会想要减小SQL服务器的攻击面，而减小攻击面的方法之一就是用细粒度的IP地址定义防火墙规则。定义数据中心和其他资源的确切可用地址列表。
Amazon Web Services （AWS）
EMR是Amazon的大数据解决方案，提供数据处理、交互式数据分析，以及使用开源框架的机器学习。Yet Another Resource Negotiator（YARN）是EMR使用Hadoop框架的先决条件。问题在于，EMR主服务器上的YARN暴露了表现层状态转移（REST）API，允许远程用户向集群提交新的应用。AWS中的安全控制在这里默认是不启用的。
这个默认配置可能不会被注意到，因为其处在两个不同的交叉口。我们在查找对互联网开放的端口时发现了这个问题，但由于是个平台，EMR底层还有EC2基础设施支持，客户就会感到困惑。而且，他们检查配置的时候也会疑惑，因为可以看到EMR配置中启用了“block public access”（阻止公共访问）设置。但即使启用了这一默认设置，EMR还是暴露了22和8088端口，这两个端口可以用于远程代码执行。如果服务控制策略（SCP）、访问控制列表或主机防火墙（如Linux IPTables）没阻止这一点，互联网上的知名扫描器就会积极搜索这些默认设置了。
谷歌云平台（GCP）
GCP体现了身份是云端新边界的理念，采用了强大的细粒度权限系统。然而，GCP的服务账户成了最影响用户的一个普遍问题。这个问题存在于GCP CIS Benchmarks中。
由于服务账户用于为GCP中的服务赋予执行授权API调用的能力，创建时的默认设置常被误用。服务账户允许其他用户或其他服务账户冒充自己。我们必须了解这种担忧更进一步的含义，那就是你的环境中可能会围绕这些默认设置出现完全不受限制的访问。换句话说，在云端，一个小小的错误配置所引发的震荡可能远远超出目力所及范围。云攻击路径可能始于错误配置，但经过提权、横向移动和隐藏有效权限后，以获得敏感数据而告终。
所有用户托管（但非用户创建）的默认服务账户都分配有Editor角色，用以支持它们在GCP中提供的服务。简单删除Editor角色未必就能修复这个问题，因为这么做可能会破坏服务的功能。所以我们有必要深入了解权限，必须确切知道随着时间流逝服务账户在用或没在用哪些权限。由于编程身份更容易遭到滥用的风险，利用安全平台获得最小权限就变得至关重要了。
以上只是主流云平台中的几个例子，希望能启发读者仔细审查自己的控制措施和各项配置。云提供商并未达到完美境界。他们跟我们一样，也容易受到人为失误、漏洞和安全缺陷的影响。尽管云服务提供商提供了很安全的基础设施，最好还是更进一步，永远不要自满于自己的安全状况。默认设置往往会留下盲点，达到真正的安全需要付出努力和长期维护。
