安全厂商 Threat Stack 分析了AWS使用模式，发现其中73%都有某种形式的错误配置，这会带来潜在安全风险。

　　4月18日的AWS峰会上，安全厂商 Threat Stack 展示了很多常见的用户错误安全配置，这些错误配置可致用户云实例暴露在安全风险之下。

　　Threat Stack 分析了使用AWS的200家公司，想找出是否有潜在安全问题，结果是：不仅有，还有很多。最大问题之一是，73%的用户在云实例上向公共互联网开放了SSH服务器远程管理服务。

　　Threat Stack 首席技术官山姆·比斯比说道：“要说明的是，这不是SSH里的漏洞，而是糟糕的安全组(防火墙)配置。”

　　任何类型服务器上的典型SSH，都要求某种形式的身份认证。AWS中发现的问题是，安全组配置允许互联网上任意源直接通过SSH访问环境中的任意系统。

　　“尽管有技术途径可以安全运行类似的架构，这些方法却一般都被认为太过复杂，不值当那些额外的工作或风险。”

　　暴露SSH服务非常危险，因为会导致更大的面向公众的区域，而这些区域是可被也会被攻击的。举个例子，如果某环境中有1000个系统开放了SSH，那就有可能在整个暴露面上扩散攻击，减小检测几率。

　　1000台主机每台出现一个非法登录，比一台主机上出现1000个非法登录，要难发现得多。

　　从比斯比的经验来看，SSH主机会很快遭到攻击。

　　“我上一次在互联网上开放SSH做测试时，只过了不到10秒，那台主机上的SSH就遭到了攻击。”

　　另一个安全薄弱环节，是AWS用户很少使用多因子身份验证(MFA)。据 Threat Stack 的分析，62%的公司没有为他们的AWS云实例采用MFA来保证安全。

　　至于MFA采用率为什么不高，比斯比有几个想法。

　　我认为不知道MFA的技术员人数已经急剧下降了。可能是人们低估了投资，以及存在MFA太难的错误认知吧。

　　Threat Stack 还发现，不是全部AWS用户，都在所有AWS区域内使用 AWS CloudTrail审计与合规服务。27%的用户没有在至少1个AWS区域上配置CloudTrail。

　　“这种做法很常见，因为用户惯于只在利用到的区域提供监测——尽管可以自由监测未使用区域。这种做法在系统监测(CPU和硬盘)上挺实用，但不适用于安全或合规监测。”

　　比如说，如果一家公司只在北弗吉尼亚运行有主机，那在东京就不会出现他们的系统，如果这情况有变，那就必须紧急召人处理，因为这意味着他们的资源要么被黑了，要么提供错了。

　　“我个人觉得AWS的教育策略开始走下坡路了，他们需要在客户行为上做出小的选择。”

　　例如，CloudTrail应默认在所有区域都启用，而MFA应该是强制性的。

　　我认为，安全作为一种功能供用户随意启用或禁用的做法不再有效，这也是现下安全合作伙伴如此之多的原因之一。如果AWS能默认更多地照管好安全基础，那我们就可以不再强调这些基本的错误配置，而聚焦更难的问题了。

　　责任编辑：DJ编辑