很显然，许多组织在积极采用云。但问题是，他们完全了解云吗?是否知道如何保护在云端构建的应用程序?就像任何新兴技术一样，种种神话和误区自然随之出现。

　　说到安全，哪怕小小的失误都会导致违规或网络攻击，从而使贵组织蒙受惨重损失。为了尽量减小这种事情的可能性，有必要了解最常见的云原生安全误区以及对策，确保贵组织避免不必要的风险。

　　别让云原生误区破坏安全

　　要建立更强大的安全态势，第一步是教育：知道在云原生环境中不该做什么与知道该做什么同样重要。

　　本文旨在揭穿云原生安全方面最常见的误区，并给出切实可行的建议。

　　误区一：云提供商负责所有安全措施

　　许多组织以为，由于将应用程序托管在云服务提供商(CSP)处，该CSP就提供所有安全措施，但事实并非如此。实际上，云服务提供商和组织分担安全方面的责任。

　　简单来说，CSP保护应用程序在上面运行的基础设施，组织负责保护应用程序内的活动和数据。CSP确保它们运行的计算、存储和数据库服务是安全的。由于CSP采用多租户模式，其中许多应用程序共享相同的服务器，因此它们还提供公司之间的硬隔离。

　　云提供商无法在组织的应用程序内实施安全措施。这是由于每家组织以独特的方式构建应用程序、使用存储空间和配置系统——这意味着CSP不可能对应用程序内的安全采取一刀切的解决方案。虽然一些提供商提供开箱即用的安全功能，比如AWS Control Tower，但组织须支付额外费用，仍要做大量的定制工作。

　　使用云的所有组织为其应用程序及各部分(包括操作系统、源代码和数据)的安全负责。组织可以采取的最强有力的安全措施之一是，通过授权实施访问控制。授权确保用户及其他技术只能在需要时访问所需的系统和数据。下面探讨如何实施授权。

　　误区二：你可以在云原生环境中使用同样的本地安全措施

　　组织犯的另一个常见错误是，试图将来自本地环境的安全措施原封不动地搬到云端。基于边界的安全措施(比如防火墙和浏览器隔离系统)在云端不起作用，因为网络不再是可以通过周围设置屏障来保护的静态环境。

　　相反，如果黑客闯入网络，你必须专注于保护数据安全。同样，这时候访问控制和授权有了用武之地。然而，与基于边界的安全一样，传统的本地访问控制措施不适用于云。

　　由于微服务架构、容器化应用程序和应用编程接口(API)，需要自己的授权策略和安全配置的单个组件急剧增多。单点登录、SAML、OIDC和OAuth2等传统技术可以帮助你解决应用程序的身份验证，但无法帮助解决授权，这仍然取决于你的开发人员。

　　你应该在云原生环境中使用策略即代码。策略即代码意味着，你将标准的软件工程实践运用于管理系统的规则和条件(版本控制、代码审查、自动化测试和持续交付等)。有了策略即代码，策略与应用云平台分离开来，这意味着可以在不更改应用代码的情况下更改策略。策略即代码的去耦性使团队更容易编写、扩展、监测、审计和协作策略。

　　误区三：策略执行需要定制的解决方案

　　最后一个误区来源于现实，因为创建定制的单个策略一度是控制访问的唯一方法，但现在不再是这样了。现有技术使组织能够跨诸多云原生应用程序、服务和平台，运用统一授权策略。

　　可以理解为什么组织仍会有这种信念。软件开发通常依赖创建一次性定制解决方案，以解决某个问题，因为每家组织配置系统和基础架构的方式不一样。多年来，授权策略也是如此。但在云原生环境下，由于独立的组件数量更多，以这种方式对待策略执行更耗时、更乏味、更容易出错。

　　与其为每组新的策略需求实施定制解决方案，不如考虑通过策略即代码将策略决策与业务逻辑的其余部分分离开来，并依赖额外技术帮助你跨云原生堆栈，高效地运用和扩展统一授权。

　　Open Policy Agent(OPA)是一个开源策略引擎，让你可以编写和验证策略即代码。Styra在2018年将它捐给了云原生计算基金会，2021年它达到了毕业状态。由于组织可以在整个云原生技术堆栈中使用同样的语言和策略框架，OPA简化了策略创建和日常治理。策略是用Rego编写的，Rego是专门针对复杂的层次数据结构表达策略而构建的。又由于它是开源的，所以有丰富的生态系统，组织可以从中获取对开发者友好的工具和集成，还有提供建议的从业者社区。