在AWS中阻碍安全性的四个误区

　　欢迎大家阅读本篇文章，从物理服务器向“云环境”转移的过程不仅仅是一项技术任务，同时也意味着我们的思维方式需要作出针对性的转变。本篇文章讲述了在AWS中阻碍安全性的四个误区，课课家教育平台提醒您：文章中有许多的小细节容易忽略，所以请大家仔细阅读本篇文章哦~

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

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

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

　　分享：AWS平台提供了从业务流程梳理、建模到运行、监控、优化的全周期管理和面向角色的BPM Total Solution。AWS BPM业务流程管理开发平台是一个易于部署和使用的业务流程管理基础平台软件。

　　探讨企业通过技术来改善流程，主要有两种方法：一种是通过集成和授权来驱动传统的遗留应用系统;另一种是利用现代的BPM系统执行BPM应用。在BPM系统中，流程即为应用程序，这种可理解为流程所定义的每个步骤视为个人或其他应用系统所执行的任务，更加明确的说BPM应用包含了流程和应用程序两部分。

　　应用整合：

　　通过适合的技术可以将外部应用系统的身份、局部应用、业务互交、数据等整合到一起，AWS平台为实现集成提供了开放的工具、产品和技术，通过AWS平台实现集成的几种常见模式：

　　⊕ 身份被集成：登录状态被三方Portal门户掌管

　　⊕ 集成身份：登录状态由AWS Portal掌管，整合其他web应用

　　⊕ 数据交换：流程中将请求/结果放入ESB企业服务总线或JMS队列

　　⊕ 协同外部系统数据：流程中读写外部数据(XML、WebServices、DB、Other)

　　⊕ 协同外部文件格式：流程表单与常用文件格式的转换(Word、Excel、XML、PDF)

　　⊕ 协同外部沟通平台：流程与外部通讯技术的集成(短信、MSN、EMail、RTX)

　　⊕ 协同外部Web界面：流程中调用外部Web应用界面(SSO、URL Binding)

　　⊕ 外部启动/执行AWS流程：在三方外部系统执行AWS流程(SDK API、WebServices)

　　⊕ 协同外部流程/状态：由AWS流程触发外部系统流程或更改数据的状态(API、WebServices、DB)

　　业务活动监控(Business Activity Montior，BAM)平台 BAM提供了对业务绩效指标的实时访问,以改进业务运作的速度和效率，并将这些变化和趋势由一系列的图形仪表动态的展现给用户。

　　BAM能够让高管人员以可视化的方式从自己Web Portal上监控业务或流程的“关键指标”(Key Performance Indicator，简称 KPI)，AWS平台为实现对流程、变化的业务数据进行时时监控提供了平台级支持。在AWS BAM平台中预设了十余个流程绩效和运行状态的监控，通过Adobe Flex技术将数据动态推送到Web客户端，在实施项目案例时也可根据BAM提供的接口快速封装成自己的业务仪表盘，并通过统一的授权机制将仪表部署给特定用户。

　　在中国，大多数集团企业或行业客户IT建设尚处于初级磨合阶段，大量BPM应用需要进行设计或重建，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工作负载。

     小结：相信最后大家阅读完毕本篇文章后，学到了不少知识吧？正所谓“三人行必有我师”，对于云计算你有哪些独特理解，分享给大家，我们一起学习!当然如果大家还想要了解更多相关方面的详细内容的话呢，请登录课课家教育平台咨询哟~