列举网首页
由于云基础架构往往处于一个动态的网络环境中，因此其中的各个组件也是不断变化的。总体而言，云端安全性的目标就是，要通过确保系统能够按照预期运行，并能够维持其整体的安全态势。为此，我们有必要重新认识如下三个关键性概念：
边界：传统安全性的本质是基于保护一个受信任的边界，即所谓的“堡垒(fortress)”。然而，分布在互联网上的云服务环境，则具有能够动态衍生出多个相互连接的端点和层次的特点。因此，任何云安全模型都应该以身份认证和访问管理为中心，专注于加强对于可疑帐户的权限管控(这通常需要依赖于行为建模)
提高云端安全性的十项规则
规则 1：不要忽视开发用的密钥与证书
由于供职于一家需要每天持续扫描数以百万计的公、私有代码库的公司，我们深知构建健全的密钥与证书政策的重要性。您应该确保自己的开发人员仅使用短期有效的证书密钥，并在投入正式的生产环境之前，撤销这些仅作开发用途的证书，并且应当执行包括检测和管理存储库中的证书等，各项完备的设置与检查。我的一位资深客户就曾指出(https://www.itcentralst***/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 条安全军规，能够方便您更全面地制定出防护措施，并构建出更好的云端安全性态势。
