当确保公共云数据与资源安全性时，不理解基本的安全概念或不知道如何使用特定的AWS安全特性将是弊大于利的。

　　成本和安全性已成为众多企业使用公共云的障碍。企业用户往往不会选择由公共云供应商所管理的陌生IT环境，他们一般更趋向于投资内部IT团队以求能够实现内部控制的本地资源。但是，时间以及业界人士对于公共云的态度都已经发生了改变。

　　虽然诸如AWS这样的公共云供应商已经花大力气解决这些应用障碍来帮助提高用户使用公共云的信心，为将资源迁入云提供方法，但还是存在着一些安全性方面的错误。漫不经心的安全性方法会带来漏洞，而这些漏洞是任何管理服务或安全工具都无法填补的。

　　只要企业IT专业人士们能够克服与工具相关的学习曲线并正确使用这些工具，那么AWS的安全服务套件就可用于保护云中的数据和资源。对于某些企业用户来说，AWS中的共享安全模式是难以使用的，而可用的托管工具将进一步让确保资源安全性的方法变得更为复杂。以下四个开发人员在AWS安全性方面易犯的特定错误是值得用户密切关注其云运行的。

　　避免分担责任

　　虽然AWS经常宣扬责任分担的概念，但这并不意味着所有的AWS客户都能够理解这一理念。

　　本地和主机托管安全配置涉及不同水平的实践工作。IT团队承担了确保数据与工作负载安全性中绝大多数或全部的责任。所以，当企业选择使用AWS时，其中一些IT专业人士会误以为是由云供应商来负责AWS中的所有安全性方面问题。这一误解可能会导致迁移后针对满足和维护客户严格合规性需求的争论。

　　“从风险管理策略的角度来看，很多客户都没有很仔细地审查他们的体系架构，他们都习惯性地持着一种‘确保系统安全性应当是供应商责任’的态度，”云安全联盟CEO Jim Reavis在一封电子邮件中如是写道。“这个问题在很多方面都有所体现，其中包括…忽视容错和冗余功能，例如使用多个可用区域。”

　　不正确配置角色和AWS安全组

　　AWS的身份和访问管理（IAM）控制着用户对服务和资源的访问。AWS安全性工具是集成整套服务和工具的基础，但是这并不意味着所有的开发人员都能够正确地进行集成操作。

　　首先，企业用户可能无法真正地遵循最小权限的授权原则，在实际工作中往往是授权用户对过多资源的过多访问。

　　“安全组应当被认为是一个防火墙，他们应该秉承一个‘除非明确说明否则否认一切’的原则，”Reavis说。

　　此外，IT团队通常会设置IAM角色和AWS安全组以满足企业自身需求，然后放松对这些访问控制的执行和更新。尤其是AWS安全组被证明是难以管理的——即便企业安排必要的人员和资源来解决这个问题，亦是如此。这有可能会导致跨整个云部署的漏洞。

　　企业需要建立一个合适的内部框架来对安全组和IAM策略进行定期评估。

　　日志功能的低效使用

　　日志记录工具通常可以帮助管理人员确定何时何地发生何种问题以及具体牵涉到哪一位用户；很多IT团队都能够依靠这些工具作为AWS中的安全性组件。但是，开发人员很可能会不习惯使用这样一些日志记录功能。

　　亚马逊CloudWatch日志服务会从弹性计算云实例和AWS CloudTrail事件中采集数据，这个服务让开发人员能够更深入地了解从应用运行性能到API调用的所有信息。CloudWatch日志服务为云部署提供了丰富的信息，而这些信息可用于在应对潜在问题中设置自定义警报或触发AWS Lambda函数的其他服务。

　　一些客户会使用一个记录API调用日志的服务—— CloudTrail。“对于记录所有AWS API调用来说，CloudTrail是一个非常有用的服务，”Reavis说。“它可以帮助企业用户的管理人员积极主动地排查各种各样的安全问题，它还有助于进行取证。但是很多客户都不使用这个服务。”

　　缺乏加密

　　数据加密已成为一个业界内普遍性的话题。使用任何类型智能设备的最终用户都可以使用加密功能来实现对个人数据的保护。

　　虽然企业用户可以使用AWS中类似的加密功能，但并不是所有的客户都愿意或习惯使用这类功能。AWS客户可以转而选择使用AWS密钥管理服务，或使用简单存储服务或弹性块存储中的内置加密功能。开发人员必须认真执行加密密钥的创建和管理流程，并将其认为是一个不同于管理实际数据存储的单独任务。

　　“太多的信息要么是完全不加密，要么是加密工作做得不好，”Reavis说。“可选项有很多很多——其中一些是由AWS提供的，另一些则是由第三方提供。一些加密解决方案是在服务器端执行的；而另一些则是在数据传输至云之前在客户端进行信息加密的，”他补充说。

　　AWS客户需要考虑通盘考虑加密。“目前还没有一个能够适合所有应用的全能解决方案，”Reavis指出。但是正确区分存储管理和加密密钥管理就可以更好地保护AWS工作负载。