不了解基本的安全概念或不知道如何使用特定的AWS安全功能在保护公共云数据和资源时弊大于利。成本和安全性一直是许多企业采用公共云的障碍。企业用户往往不会选择由公有云提供商管理的陌生IT环境，他们通常更愿意投资内部IT团队以实现对本地资源的内部控制。但时间和行业对公共云的态度已经发生了变化。尽管AWS等公有云提供商为解决这些应用障碍做出了巨大努力，以帮助提高用户使用公有云的信心，并提供将资源迁移到云中的方法，但仍然存在一些安全错误。粗心的安全方法会造成任何管理服务或安全工具都无法填补的漏洞。AWS的安全服务套件可用于保护云中的数据和资源，只要企业IT专业人员能够克服与工具相关的学习曲线并正确使用它们即可。对于一些企业用户来说，AWS中的共享安全模型难以使用，可用的托管工具将进一步复杂化确保资源安全的方法。开发人员在AWS安全性方面犯下的以下四个具体错误值得他们的云操作密切关注。避免分担责任虽然AWS经常吹捧分担责任的概念，但这并不意味着所有AWS客户都理解它。本地和托管安全配置涉及不同级别的动手工作。IT团队承担确保数据和工作负载安全的大部分或全部责任。因此，当企业选择使用AWS时，其中一些IT专业人员错误地认为云提供商负责AWS的所有安全方面。这种误解可能会导致迁移后关于满足和维护客户严格的合规性需求的争论。“从风险管理战略的角度来看，许多客户并没有非常仔细地审查他们的架构，他们有一种习惯性的态度，即‘实现系统安全应该是供应商的责任’，”云安全联盟首席执行官吉姆雷维斯在一封电子邮件中写道。“问题以多种方式表现出来，包括......忽略容错和冗余功能，例如使用多个可用区。”角色和AWS安全组配置不当AWS的身份和访问管理(IAM)控制用户对服务和资源的访问权限。AWS安全工具是集成整套服务和工具的基础，但这并不意味着所有开发人员都能正确集成。首先，企业用户可能无法真正遵循最小权限的授权原则，而在实际工作中，授权用户往往拥有过多的权限访问过多的资源。“安全组应该被视为防火墙，他们应该有一个‘拒绝一切，除非明确说明’的原则，”Reavis说。此外，IT团队经常设置IAM角色和AWS安全组来满足自己的需求，然后放松对这些访问控制的执行和更新。事实证明，尤其是AWS安全组难以管理——即使组织部署了必要的人员和资源来解决该问题。这有可能导致整个云部署中出现漏洞。组织需要建立合适的内部框架来定期评估安全组和IAM策略。日志记录工具的无效使用通常可以帮助管理人员确定何时、何地、发生了什么问题以及涉及哪个用户；许多IT团队可以依赖这些工具作为AWS中的安全组件。但是，开发人员可能不习惯使用其中的某些日志记录功能。AmazonCloudWatchLogService从ElasticCompute云实例和AWSCloudTrail事件中收集数据，使开发人员能够更深入地了解从应用程序性能到API调用的所有内容。CloudWatch日志服务为云部署提供了大量信息，可用于设置自定义警报或触发AWSLambda函数以响应潜在问题的其他服务。一些客户使用记录API调用的服务-CloudTrail。“CloudTrail是一项非常有用的服务，用于记录所有AWSAPI调用，”Reavis说。“它帮助企业用户的管理主动排查各种安全问题，帮助取证。但很多客户并没有使用这项服务。”缺乏加密数据加密已经成为一个行业共性话题。使用任何类型的智能设备的最终用户都可以使用加密来保护他们的个人数据。虽然企业用户可以在AWS中使用类似的加密功能，但并非所有客户都愿意或习惯使用此类功能。AWS客户可以选择使用AWS密钥管理服务，或使用简单存储服务或弹性块存储中的内置加密功能。开发人员必须谨慎对待创建和管理加密密钥的过程，并将其视为与管理实际数据存储不同的任务。“太多的信息要么根本没有加密，要么加密没有做好，”Reavis说。“有很多很多选择——其中一些由AWS提供，另一些由第三方提供。一些加密解决方案在服务器端执行；而另一些则在数据传输到云之前在客户端执行。加密信息，”他补充道。AWS客户需要从整体上考虑加密。“没有适合所有应用的万能解决方案，”Reavis指出。但正确区分存储管理和加密密钥管理可以更好地保护AWS工作负载。
