本文是云原生安全的基础介绍，将带读者了解云原生安全的基础设施分类、云原生安全平台所需具备的特性等，让您全面认识云原生安全。
云原生安全是指将安全纳入企业整体云原生应用开发的战略。这一方法解决了建立安全应用程序所需的基础设施、团队和流程的变化。因此，云原生安全强调应用安全，以确保在云环境中检测和修复漏洞。
实现云原生安全需要一个整体的规划使安全得以渗透到整个软件开发生命周期（SDLC）中。安全平台可以帮助开发人员交付基于云原生理念的设计，开发团队应该负责提供安全代码。每个设计决策都应考虑到云原生架构，以确保应用程序是完全基于云原生架构的。
确保基于云架构的安全会面临一些挑战。开发人员可以通过基础设施即代码（IaC）配置动态地部署基础设施，通常是与应用程序代码同时编写基础设施代码。开发人员可以将安全工具整合到他们的工作流程中，为补救措施提供见解和建议。例如，他们可以用命令行界面（CLI）工具进行本地测试，并使安全数据在集成开发环境（IDE）中可见。
尽管企业已经体会到了云原生应用的优势，但企业对管理和维持此类应用环境的安全依旧缺乏经验。在云原生环境中，安全的含义是否真的与传统环境不同？这对你的安全策略和控制有什么影响？云原生环境的首要安全考虑因素有以下几个：
随着微服务和容器在云原生环境中取代单体和传统的多层应用，软件交付和部署正在变得持续。如亚马逊之类的大型企业每天都会进行数百次部署。在这些类型的环境中，安全检查必须要轻量、持续并且嵌入到开发工具链中，否则就有可能被绕过。
传统企业的安全是保护 endpoint 的安全，分割网络和保护网络边界（network perimeter）的安全。在云原生环境中，您不能依赖固定的路由、网关、网络边界，甚至无法依赖 agent ——基于此，您的数据中心正面临威胁。此外，您的 server 工作负载比以往更容易暴露给攻击面。因此，将重点转移到确保数据中心和 server 工作负载的安全是当务之急。
在微服务模型中，端到端的可见性、监控和检测都将变得更复杂和难以执行，特别是当部署和升级都在持续不断进行时。因此攻击检测需要动态工作（如，减少对静态签名的依赖），实时扩展，并且在不损害生产环境的性能和稳定性的情况下进行。
一些微服务应用程序运行在虚拟机上的容器中，而其他的则运行在裸机 Linux 上。但现如今保护主机、虚拟机层、容器和应用程序的安全功能往往是互相独立的，缺乏整合。这种方法为执行实时安全响应和行动带来了复杂性和不必要的障碍。打个比方，您会把关键任务的容器部署到一个需要打补丁的虚拟机上吗？但是，如果您没有虚拟机级别的可见性，您又怎么会知道这个虚拟机需要打补丁呢？因此现在亟需在混合堆栈中整合可见性、监控和安全保护，包括 Linux 主机、虚拟机、容器以及最后的应用程序及服务。
为了帮助您了解云原生安全策略，我们将安全基础设施分为4类——Cloud 层、容器层、集群层和代码层。
Cloud 层由运行云资源的基础设施组成。当你在云服务提供商（CSP）设置 server 时，该提供商负责大多数基础设施安全。但是，您仍然需要负责配置服务、保护您的数据安全，并对其进行监督。
影响 Cloud 层的典型安全问题包括错误配置和自动攻击。攻击者会积极利用因错误或疏忽造成的错误配置，如未改变的默认设置或对管理控制台的弱访问保护。攻击者还可以利用自动化来扫描漏洞并迅速发起攻击。
容器层由容器镜像组成，这些镜像可能包含了您能扫描的漏洞。企业常常会忽略一些问题，如镜像安全、使用未知来源和弱权限配置。因此，保持容器定期更新十分重要，这样可以尽量减少已知漏洞造成的不良后果。此外，您还应该扫描和验证容器中运行的任何程序。
确保所使用的任何镜像是由已知的来源构建的或者来自一个受信任的镜像仓库。一个镜像签名工具，如 Docker Content Trust (DCT)，可以帮助您确保容器内容来自可信任的来源。
确保所有容器都使用特权用户运行，而不是使用主机的 root 权限。
集群层由构成 Worker 节点和控制平台的 Kubernetes 组件构成。正是在这一层，您要保护 Kubernetes 工作负载。Kubernetes 组件使用加密通信，请求 TLS 证书来验证彼此的身份。
需要保护的最关键组件是 kube-api-server ，因为它是 Kubernetes 的主要接口。默认情况下，该 server 只能通过 HTTPS 访问，您也可以使用第三方身份认证程序来进一步保护它。通常情况下，企业使用自定义的基于角色的访问控制（RBAC）规则进行 API server 授权，所以您可以管理集群及其工作负载，而无需 Secure Shell 访问。
代码层，也被称为应用层，提供最高级别的安全控制。你可以限制暴露的 endpoint、端口和服务来管理安全风险。你应该使用 TLS 加密来保护内部和外部服务之间的通信。
代码层的典型安全问题包括不安全的代码、不充分的风险评估以及第三方软件依赖项的漏洞。您应该使用静态代码分析攻击来识别不安全的代码并确保安全的 code 实践。您需要定期扫描并测试您的应用程序以抵御跨站点请求伪造（CSRF）和跨站点脚本（XSS）等攻击。
大多数云原生应用都包含第三方代码库或依赖项，这些库或者依赖项通常未经静态分析检查。您可以使用软件成分分析工具来识别有漏洞的依赖项。
企业通常会实施云原生安全策略以保证整个技术栈的安全，以下列举出了5个常见的云原生安全策略：
共同承担安全责任
DevOps 团队应该与安全团队紧密合作。开发人员通常不是安全专家，但他们可以学习安全coding 实践。同样，安全专家可以了解用于开发、测试和部署应用程序的工具和流程，从而帮助他们提高安全性。
云原生安全需要各种管理开发和安全团队的方法，并需要密切沟通协同工作。共同承担责任和协作是工作文化转变的一部分，这使组织能够将安全性整合到开发过程中。
安全左移是另一个重要的文化转变，这通常需要新的安全工具来处理云原生应用开发环境的规模和速度。这一方式主要是为了在软件开发流程的早期就开始采纳安全方法，如漏洞扫描。开发人员必须在将应用程序代码部署到生产之前确保其安全性。
另一个保护基础设施的方式是避免 serverless 的特性。攻击者可以利用在 serverless 功能代码和容器中的漏洞。他们还可以利用云基础设施的错误配置来访问敏感数据，提升权限，并横向移动。
您应该在 CI/CD 流水线中避免使用不受信任的容器镜像。安全团队应该在开发人员将镜像部署到应用程序之前检查它们是否包含漏洞。
保护依赖项
应用程序代码通常包含开源的依赖项，例如在 Python 软件包索引（PyPI）里发现的依赖项。您可以使用引入了综合漏洞数据库的自动化工具来保护应用程序的依赖项。云原生编排工具通过触发应用程序的安全动作可以帮助您在开发期间维护安全性。您可以持续运行此类工具以避免将漏洞依赖包引入容器和 serverless 功能中，因为它们会运行在生产环境中。
这一方法，也称为多层安全，主要使用网络监控来检测和修复单个威胁。安全团队应该监控网络的每一层，您可以使用多个工具和技术来防止和响应攻击并为正在进行的攻击制定应急计划。
企业常常对其多云模型采用能兼容多个云的安全方法。一个云原生安全平台（CNSP）可以帮助您管理来自不同供应商的多个云的安全。您只需一个安全策略，其中包含了多方必须遵循的最佳实践——这有助于简化您的云原生监控、灾备恢复和合规工作。
企业在启用安全策略推动云原生转型之前，他们需要考虑以下这些需求：
- 高度的安全自动化：传统基于告警的安全操作已经无法跟上当前近乎无限规模、动态性质更强的云原生系统。因此，手动工作流程根本不是一个选项。规模化的自动检测和响应是云原生安全的必备条件。
- 设计时要考虑到“混沌”：在微服务架构中，任何功能可能都会牵涉到许多软件组件，它们在运行时中被拼接在一起。从安全的角度来说，这意味着检测逻辑和控制不能依赖于对运行状态和安全健康状态的先验理解。因此云原生安全必须拥抱混沌工程原则——主动实验、经常测试并快速补救。
- 快速检测、就地遏制、迅速恢复：云原生应用最终是分布式计算应用。在这样的环境下，通常不可能及时执行全局安全决策。因此，您最好优先考虑哪些允许快速检测、快速恢复，并在全系统的恶意行为表现出来之前在本地控制影响的行动。即使安全决策不是100%精确，在本地采取行动和快速恢复也会为您提供一个更具弹性的系统。
云计算在不断急速发展，随着创新的步伐不断加快，需要开发出新的技术和工具来帮助企业紧跟技术的发展。很多时候，企业会将他们现有的企业本地的软件基础设施移植到云中，进而导致企业内部被强制使用过时的抽象和安全模型，从而无法体会到云原生所带来的优势。
为本地托管时代建立的安全模型和工具是一个特别重要的责任。因为现存的工具中大多数是在云计算作为一级托管平台普及之前设计的，无法提供足够的安全性。在快节奏和竞争激烈的空间中，能够扩展、保护您的应用程序是十分重要的。想要在现代云时代保持竞争力，企业应该专注于构建云原生应用程序，并使用云原生安全平台来帮助保护它们。
