几周之前，初创公司Code Spaces受到了DDOS进行蓄意勒索的攻击，在公司没有支付勒索金的情况下，攻击者进入了AWS的EC2控制面板并删除了数据。

　　这是无疑是一个噩梦，无论如何阻止它，但类似的事件已经出现了——尽管不是如此戏剧性的结果。安全专家说，通常在这些情况下，其他用户无意中张贴他或她的AWS帐户根密钥在公众地方 -——例如Github或StackOverflow，攻击者的目标不是勒索或是窃取数据，还是窃取这些免费的计算资源，因为it’s free IT IT。

　　最近一个不愿透露具体信息的公司说有人能够运转在偏远地区价值成千上万美金的“流氓”AWS实例。即使这家公司(我们的目标是X公司)没有发现违反或张贴其凭据的迹象，AWS也会发行信贷金额。

　　Evident.io 创始人兼首席执行官Tim Prendergast.这样说道：“Evident.io公司为AWS提供了一个叫做SaaS安全产品，X公司的SaaS出现问题后，Evident.io公司并没有花太长的时间就发现了里面的错误之处”。即使该公司并没有推出它的根密钥，同时Tim Prendergast又指出它确实有“高出两位数的安全控件没有得到正确的实施”。

　　事实上，这类公司通常面临一下三大领域的挑战，所以建议都应该在安装的早期考虑所有不安全的因素。

　　三种规避措施

　　首先，有一个根密钥或IAM用户密钥被暴露的情况发生时，它可能具有正如前文所提到那样的渗透性。

　　其次，缺乏良好的密码规划。企业往往不设置密码验证来确定是否正确。所以公司强制使用两个“强密码”和多种认证因素就显得尤其重要。

　　最后，很多企业对于他们如何设置的用户权限或角色都显得比较松懈，许多给所有用户全面管理访问的时候却没有理由这么做，这正是类似于有太多的Windows用户有充分的管理权限的时光。这为潜在的攻击者开辟了一个巨大的空间，他们只需要一个用户的密码，便可以访问到整个大杂烩。

　　Prendergast说：“用户可以通过钓鱼网站或者访问电子邮件和一个键盘记录器来获取如何登录账户的信息”。如果网络钓鱼受害者有管理员权限，那么损失也将变得不容乐观。

　　最佳实践

　　不用多说，根据AWS的最佳实践，张贴在公共网站密钥认证是一个禁忌。这本来是众所周知的，但可怕的是它发生的次数竟然不在少数。

　　AWS用户的首席技术官说：“我曾经看见有人在StackOverflow上输入AWS根密钥两次，但是当我提醒他们时，他们却并不知情”，这是另外一种实践方式。在这两种情况下，亚马逊将计入欺诈性收费返还给客户。

　　当被问及对此事以及发表评论时，一个AWS的发言人说：“客户不应该使用他们的根帐户的访问键，应该使用身份访问管理(IAM)来创建与AWS资源交互应用程序的临时安全证书。当然，这些IAM访问键必须加以认真的管理。

　　最后她补充道：“开发商有责任按照亚马逊指导和利用这些机制。当亚马逊意识到可能暴露的凭据时会主动通知受影响的客户，并提供有关如何保护他们的访问键的指导”。

　　事情是这样的，Prendergast最后说道：“许多AWS帐户是以小开发者为中心的聚集地。他们并没有首席信息安全官或者经常连任何安全专家都没有，这就意味着安全需要开发人员负责，但是这并不是开发人员的焦点。而且从技术上来讲，对于API级别的任何安全问题是用户的责任而不是亚马逊的”。因此AWS账户安全问题任重而道远。