编者按: 整个十月的网络安全意识月, ISACA Now博客每周都会发布关于热点安全话题的新文章. 有关更多ISACA网络安全资源，请访问我们的 网络安全意识月网页.
云安全漏洞一直是新闻头条. 然而,, 这些违规事件通常都有模糊的解释——“数据库配置错误”或未命名的“第三方”管理不善.“围绕云计算的模糊性可能会使澳门赌场官方下载的安全看起来令人望而生畏. 对安全的担忧导致一些首席信息官限制其组织使用公共云服务.
然而, 挑战并不在于云本身的安全性, 而是在政策和技术的安全性和技术的控制. 在几乎所有的情况下, 是用户, 不是云提供商, 谁未能管理用于保护组织数据的控制. “首席信息官需要确保他们的安全团队不会因为毫无根据的云安全担忧而阻碍云计划,” 高德纳公司副总裁分析师杰伊·海泽说. “夸大的恐惧会导致失去机会和不适当的支出.首席信息官必须改变他们的提问方式，从“云安全吗??到“我是否安全地使用云服务??”
获取云服务可能很简单. 我们与首选的云服务提供商(CSP)签约，很快就能够以相对简单的方式立即部署服务和系统, 尤其是当我们用这些服务处理私人事务的时候. 然而, 如果您被指派或负责利用CSP作为您的工作的一部分，事情可能会变得棘手 整体云策略. 即使一开始脸红, 您可以使用所有托管迁移服务和自助迁移工具, 选择和迁移到CSP可能看起来很简单，并不过于复杂.
从云中的虚拟机开始是一个相对容易理解和接受的概念，当时云计算在2006年左右还是新鲜事物. 业界早已熟悉主机之间的责任, 客户操作系统和虚拟化. 在这个程度上, 当组织被问及云工作负载的实现时, 当客户的责任放在虚拟机上时，几乎没有争议. 然而，随着云服务变得越来越复杂，共享责任模型被引入.
共享责任模型是一个云安全框架，它规定了云计算的安全义务. 共享责任模型是成功的云部署的基本要素之一. 共享责任模型的正确实现有助于实现几个目标, 比如利用云的特性, 高效节约资源, 并且在过程之间有清晰的定义, 人与技术. 下面的模型描述了 责任分担模式.
共享模型的目的是在CSP运行时帮助减轻客户的运营负担, 管理和控制从主机操作系统和虚拟化层到服务运行所在设施的物理安全性的组件. 客户承担客户操作系统的责任和管理(包括更新和安全补丁), 其他相关应用软件, 以及csp提供的安全防火墙的配置.
在共享责任模型中, 客户需要仔细考虑他们选择的服务，因为他们的责任取决于所使用的服务, 将这些服务集成到云环境中, 以及任何适用的法律法规. 共享责任的性质还提供了允许部署的灵活性和客户控制. 如上图所示, 责任的区分通常被称为“云的安全”与“云中的安全”.
客户责任矩阵旨在帮助明确云消费者和云计算服务提供商之间可能共享的控制. 然而, 在大多数情况下, 客户关系管理要么是事后才想到的, 或者开发了一次，但没有认真维护和/或管理. 在某种程度上, 对客户关系管理的忽视是技术发展速度的结果, 哪一个不是借口, 但我们都需要考虑和认识到这一点. 正如我们最初指出的, 云用户仍然对他们自己在云中的责任感到困惑和误解, 特别是如果它碰巧是一项提供多种功能的创新服务. 客户很容易获得一种虚假的安全感.
新的创新抽象服务继续引入解释客户和csp之间责任的新方法. 即使提供了客户责任矩阵(CRM), 大多数(如果不是全部的话)crm没有达到受联邦命令或法规约束的组织所需的粒度级别，以帮助正确配置杠杆系统和服务.
所以, 云消费者继续使用创新的新服务，其错误的假设类型与云计算最初被采用时相同, 客户将能够以交钥匙的方式开始利用托管服务，而不需要额外的配置. 正如我们现在所知，这种假设在很大程度上是不正确的. 完全托管的云服务确实存在, 提供明确的共同责任模型，并努力通知客户他们的责任. 然而, 如果说大多数csp为所有客户提供这种程度的定制服务是不公平的.
As 云安全漏洞 并不是csp的错, 被误导的大多数人继续误导其他人关于云计算的“风险”, 当几乎所有云安全漏洞都是由于客户配置错误或未配置(运行所有默认配置的系统)而发生时. 网上已经发生了数百起关于配置和需要澳门赌场官方软件的争论, 以及应该向客户提供什么, 哪一个通常被称为“基线配置”.要使用NIST对基线配置的定义: 系统的一组规格说明, 或系统内的配置项(CI), 这已经在特定时间点得到了正式审查和商定, 这只能通过变更控制程序来改变. 基线配置被用作未来构建、发布和/或变更的基础.”
您可以将基线配置视为系统默认值. 当你在云中启动/启动一个服务，然后点击“下一步”，没有配置任何东西，所有选项都使用默认值, 您最终将使用默认配置基线部署系统/服务(没有选择任何选项)。. 然而，你刚刚跳过的所有这些选项也是你作为客户的责任. So, 如果您要部署具有所有默认选项的工作负载，并提供了配置服务的多个方面(如加密)的选项, 由于没有加密，你的系统被攻破了, 你现在和将来都有责任, 因为你有选择的余地, 但最终没有将加密配置为启用. 我们刚才所描述的本质上就是责任共担模式. 如果您的组织未能妥善保护云系统并遭到破坏, 你, 最终负责的是客户，而不是云服务提供商.
