提高云端数据安全的十条“军规”

据统计（https://www.statista.com/statistics/1062879/worldwide-cloud-storage-of-corporate-data/），随着云服务在各个新兴行业的爆炸式增长，全球已有 50% 的企业数据存储到了云端。各个企业从中获取到的好处包括但不限于：提高服务的敏捷性、易于扩展、以及更具成本效益。

不过，如果我们从安全性的角度来考虑的话，事情就不那么乐观了。一直以来，有不少人认为，将一个企业最有价值的大部分（甚至是全部）资产，拱手交给第三方云平台，是充满挑战的。我们应该想方设法从云服务提供商处，获取 7*24 小时、全天候的安全支持，以保护自己的应用部署和数据存储。那么，光靠云服务提供商的安全防护够吗？显然不够，我们还得发挥主观能动性。

常言道：知易行难。下面我将和您重点探讨云安全的基本概念，以及正确实现云端数据保护的十条“军规”。

云端的安全性，往往需要遵循一种被称为“责任共担”的模型（https://aws.amazon.com/compliance/shared-responsibility-model/）。该模型规定：服务提供商只对“云服务”的安全性负责，而租户需要对“云服务中具体部分”的安全性负责。也就是说，在使用云服务运行自己的应用时，作为云服务的租户，您仍然需要按比例分担安全配置或管理的部分工作。当然，使用云服务的程度不同，您的责任范围可能存在着巨大的差异性。例如：若您订阅了基础设施即服务 (IaaS)，则您需要自行负责操作系统的相关补丁和更新工作。而如果您只是用到了对象存储，那么您的职责范围将仅限于数据丢失的防护（DLP）。

虽然具体的应用场景存在着巨大的多样性，但是我们有必要从中找出一些通用的准则。例如，绝大多数云服务的漏洞在本质上都能被归结为：错误配置。就算云服务提供商已经为您提供了强大的安全工具，如果您不慎或者是不会用的话，在安全配置中也会存在错误或漏洞，进而会无形中拉低了整体应用服务的安全态势。因此，为了合理有效地构建出云端“护栏”，我们需要在既知其然、又知其所以然的基础上，尽量减少错误发生的可能性、及其影响范围。

在我们开始讨论十项重要的云端安全防护策略之前，让我们先了解一下，与“传统”信息安全相比，云端安全到底有哪些不同之处。

由于云基础架构往往处于一个动态的网络环境中，因此其中的各个组件也是不断变化的。总体而言，云端安全性的目标就是，要通过确保系统能够按照预期运行，并能够维持其整体的安全态势。为此，我们有必要重新认识如下三个关键性概念：

边界：传统安全性的本质是基于保护一个受信任的边界，即所谓的“堡垒（fortress）”。然而，分布在互联网上的云服务环境，则具有能够动态衍生出多个相互连接的端点和层次的特点。因此，任何云安全模型都应该以身份认证和访问管理为中心，专注于加强对于可疑帐户的权限管控（这通常需要依赖于行为建模）。

可扩展性：由于数据的存储和处理都是动态的，因此云安全框架也应该能够考虑到基础设施的演变。换句话说，它需要了解系统的状态，根据策略做出相应的调整。

监控：随着云端资源的丰富、以及新的攻击源头的出现，针对云服务的威胁态势也在瞬息万变。各种安全风险的激增，漏洞的深藏，以及攻击的复杂化，都需要我们通过持续监控，快速掌握现有云端安全环境的变化，并能够对动态的系统做出及时且积极的反应与处置。

规则 1：不要忽视开发用的密钥与证书

由于供职于一家需要每天持续扫描数以百万计的公、私有代码库的公司，我们深知构建健全的密钥与证书政策的重要性。您应该确保自己的开发人员仅使用短期有效的证书密钥，并在投入正式的生产环境之前，撤销这些仅作开发用途的证书，并且应当执行包括检测和管理存储库中的证书等，各项完备的设置与检查。我的一位资深客户就曾指出（https://www.itcentralstation.com/product_reviews/gitguardian-internal-monitoring-review-671614-by-danny）：如果有人跟他说，密钥与证书检测并非优先事项的话，他会通过在 Google 上自定义搜索，来证明展示证书密钥泄露的危害性。这也正是我为何将其放在列表首位的原因。

规则 2：持续查看默认配置

云服务提供商通常会预先配置好一些通用的访问控制策略。这些策略虽然易于快速上手，但是正是由于其通用性，导致了它们不一定适用于您的真实应用服务，特别是在有新的云服务被引入时，它们往往需要在默认控制策略的基础上，进行定制化的配置。当然，您也可以通过选择禁用不必要的配置、或未使用到的服务，来减少受攻击面。

规则 3：列出所有可被公开访问的存储

对于云端存储被攻击者通过可开放访问的接口进行入侵之类的新闻，您也许已经司空见惯了。可见，无论您为对象和数据选择哪种存储方法，请检查并确保只公开那些需要被访问的组件和存储。

规则 4：定期审查访问控制

如前所述，云服务的安全性与您的身份认证、及访问管理策略密切相关。随着基于身份的安全系统，在整体安全措施中逐渐占据主导地位，它们形成了所谓的“零信任（zero-trust）”策略的基础。作为实践，我们可以积极主动地实施“最小特权原则”，对云端的服务、系统、以及网络的访问进行安全加固。同时，我们也应当定期安排手动和自动化的检查方式，来审查管控的执行是否严格。

规则 5：利用网络结构

上述类似的规则和实践也适用于网络结构。您应该利用云服务平台提供的控制工具，来构建更高效、更细粒度的策略，实现对访问请求的仔细检查，并按需分流。

规则 6：预防性记录和监控

没有强大的监控和日志记录，我们将无法获悉当前应用的安全态势。通过基于风险的日志记录策略，您不但应该确保违规监控的启用和正常运行，还可以在安全事件发生之后，协助开展各项调查工作。在理想情况下，您应当能够通过 API、或其他机制，在自己的日志系统上，聚合来自各种云端的日志。

规则 7：完善您的资产清单

纵然我们可以使用由云服务平台提供的 API，来减轻库存管理的巨大压力，也应该通过有关所有权、用例、以及敏感性级别等附加信息，通过定制化的策略，来完善自己的云端资产清单。

规则 8：提防 DNS 劫持

各类云服务经常需要通过、并在 DNS 条目之间传递信任关系。因此，定期检查您的 DNS 的正确性和云应用的配置，可以有效地以防止出现 DNS 被毒化、接管、以及劫持等情况的发生。

规则 9：灾难恢复计划并非只是可选项

云服务环境虽然提高了应用系统的可用性，但是它并不会提供自动化的灾难恢复 (DR) 服务。您应该全面考虑通过何种级别的投资，来应对云端环境可能发生的灾难性事件。您可以设计一套 DR 流程，以便通过外部帐户、提供商、甚至是在本地环境中恢复自己的应用服务。

规则 10：减少手动配置

云原生安全工具和控制往往是以自动化的形式交付的。请记住，漏洞源于错误配置，而错误配置通常源于手动操作。因此，对于我们人类而言，需要完成的手动工作越多，出错的可能性就越大。对此，您需要鼓励自己的团队善用、多用自动化，尽可能地使用安全即代码（security-as-code）的方式，保持安全策略的一致性。

对于安全专业人员而言，云应用安全的管理是极富挑战性的。毕竟在云端，责任范围变得不再静止，不再清晰，且不断变化。不过，值得庆幸的是，在应对各项新的安全需求、应对新的威胁时，我们不再是单兵作战了。各个云服务提供商平台往往能够提供丰富的工具集，方便我们在安全需求和灵活性之间取得平衡。希望我上文为您提供的 10 条安全军规，能够方便您更全面地制定出防护措施，并构建出更好的云端安全性态势。