一文带你了解云原生安全

1. 背景

2010年，云原生的概念第一次在WSO2的首席技术官Paul Fremantle的博客中被提及，其后经历了Pivotal、CNCF等机构的补充，加入了DevOps、持续交付、微服务、容器、服务网格（Service Mesh）、不可改变的基础设施、声明式API等技术，通过这些技术可以构建出高弹性、高虚拟化、高容错性、自恢复、易管理的分布式架构系统。

据Gartner分析师表示，到2025年，超过85%的企业将接受云优先原则，超过95%的新数字工作负载将被部署在云原生平台上，而在2021年这一比例只有30%。

随着云计算技术的不断发展，传统应用存在升级缓慢、架构臃肿、无法弹性扩展及快速迭代等问题。于是近年来云原生的概念应运而生，凭借着云原生弹性、敏捷、资源池和服务化等特性，企业服务器成本和虚拟损耗大幅减少。从物理主机，到虚拟化，再到容器化，客户不必再进行线下机房管理、使用资源占用量高的虚拟机，大大节约成本。

在这样的背景下，云原生安全问题逐渐引起了大家重视。

历史的经验告诉我们，所有繁荣景象之上，都悬着一把达摩克里斯之剑，Tripwire 2019年对311位IT安全专业人员进行了调研，发现60%的组织都遭遇过容器安全事故，容器的背后存在着巨大的安全隐患。

从计算的发展简史来看，每一次IT技术的演进带来的不仅是效率的提升，也有新的安全挑战。在这样的背景和趋势之下，我们应该如何考虑云原生安全问题？

个人理解，首先应该从比较权威的地方查找，他们对云原生安全是如何定义和考虑。

RSAC 2022

RSAC 2022举办在即，创新沙盒大赛谁将成最大赢家？
参考URL: https://www.freebuf.com/news/334473.html

2022年6月6-9日，RSA Conference 2022将在美国旧金山召开。作为全球网络安全行业一年一度的盛宴，RSAC大会被誉为安全界的“奥林匹克”，是网络安全的重要风向标之一。

自1991年举办首届大会以来，RSAC大会即将迈入第31个年头，会议规模也从一个小型的密码学论坛，发展成如今的全球安全顶级信息安全大会，吸引着全球网安企业、大咖、极客和优秀创业者共聚一堂。

推荐查看原文

2. 云原生计算基金会（CNCF）发布《云原生安全白皮书》

官方V2版本：https://github.com/cncf/tag-security/blob/main/security-whitepaper/v2/cloud-native-security-whitepaper.md
《“云”原生安全白皮书》青藤云译
https://www.doc88.com/p-78339090738580.html

根据CNCF的描述：
Cloud native development can be modeled in distinct phases that constitute the application lifecycle: “Develop,” “Distribute,” “Deploy” and “Runtime.” Cloud native security contrasts with traditional security approaches in that there is a tremendous opportunity to ensure that security is injected throughout these distinct phases instead of book ending the lifecycle with separately managed security informed interventions. Continuous learning of these concepts, tools, and processes, are critical for long term adoption and application.
Conclusion
Cloud native security, when executed strategically across an organization, can provide high availability, assurance, resilience, and redundancy at scale to ensure customers and developers have secure access to required resources at the velocity they expect. Security itself remains an interdisciplinary field that cannot be isolated from the development lifecycle or be treated as a purely technical domain. Developers, operators, and security personnel must all partner, exchange, and collaborate to continue to move the field and industry forward. As with any technical innovation, people who embark upon this journey driven through their passion are the ones who genuinely make the community and cloud native security possible.

Introduction
This paper intends to provide organizations and their technical leadership with a clear understanding of cloud native security, its incorporation in their lifecycle processes, and considerations for determining the most appropriate application thereof.

总结： 我们应该站在 容器的全生命周期去看。
也就是说，我们需要在整体的DevSecOps的开发流程中，考虑容器的安全！

3. OWASP Docker Top 10

官网： https://owasp.org/www-project-docker-top-10/
github官方： https://github.com/OWASP/Docker-Security
[推荐]云原生安全介绍
参考URL: https://blog.csdn.net/xlsj228/article/details/122834775

在安全领域，几乎每个人都知道OWASP(开源Web应用安全项目)，该组织会定期发布Web应用Top 10安全风险列表，是了解最需要关注哪些攻击方式的一个重要资源。

The OWASP® Foundation works to improve the security of software through its community-led open source software projects, hundreds of chapters worldwide, tens of thousands of members, and by hosting local and global conferences.

OWASP®基金会致力于通过其社区主导的开源软件项目，全球数百章，成千上万的成员以及主持本地和全球会议来提高软件的安全性。

威胁模型,原文

总结：OWASP更多的是从攻击者的角度来看，如何保护环境的经典方法正在查看环境，并列举向量进行攻击。

github原文

Title	Description
D01 - Secure User Mapping	Most often the application within the container runs with the default administrative privileges: root. This violates the least privilege principle and gives an attacker better chances further extending his activities if he manages to break out of the application into the container. From the host perspective the application should never run as root.
D02 - Patch Management Strategy	The host, the containment technology, the orchestration solution and the minimal operating system images in the container will have security bugs. Once publicly known it is vital for your security posture to address those bugs in a timely fashion. For all those components mentioned you need to decide when you apply regular and emergency patches before you put those into production.
D03 - Network Segmentation and Firewalling	You properly need to design your network upfront. Management interfaces from the orchestration tool and especially network services from the host are crucial and need to be protected on a network level. Also make sure that all other network based microservices are only exposed to the legitimate consumer of this microservice and not to the whole network.
D04 - Secure Defaults and Hardening	Depending on your choice of host and container operating system and orchestration tool you have to take care that no unneeded components are installed or started. Also all needed components need to be properly configured and locked down.
D05 - Maintain Security Contexts	Mixing production containers on one host with other stages of undefined or less secure containers may open a backdoor to your production. Also mixing e.g. frontend with backend services on one host may have negative security impacts.
D06 - Protect Secrets	Authentication and authorization of a microservice against a peer or a third party requires secrets to be provided. For an attacker those secrets potentially enable him to access more of your data or services. Thus any passwords, tokens, private keys or certificates need to be protected as good as possible.
D07 - Resource Protection	As all containers share the same physical CPU, disks, memory and networks. Those physical resources need to be protected so that a single container running out of control – deliberately or not – doesn’t affect any other container’s resources.
D08 - Container Image Integrity and Origin	The minimal operating system in the container runs your code and needs to be trustworthy, starting from the origin up until the deployment. You need to make sure that all transfers and images at rest haven’t been tampered with.
D09 - Follow Immutable Paradigm	Often container images don’t need to write into their filesystem or a mounted filesystem, once set up and deployed. In those cases you have an extra security benefit if you start the containers in read-only mode.
D10 - Logging	For your container image, orchestration tool and host you need to log all security relevant events on a system and API level. All logs should be remote, they should contain a common timestamp and they should be tamper proof. Your application should also provide remote logging.

注意，根据github描述， This is the OWASP Docker Top 10. It’s a work in progress.这是一项正在进行的工作。

4. kubernetes对云原生安全概述

云原生安全概述
官方：https://kubernetes.io/zh-cn/docs/concepts

分层去考虑安全性，云原生安全的 4 个 C 分别是云（Cloud）、集群（Cluster）、容器（Container）和代码（Code）。

• 云（Cloud）： 关注的是云提供商安全性、基础设施安全
  如果你是在你自己的硬件或者其他不同的云提供商上运行 Kubernetes 集群， 请查阅相关文档来获取最好的安全实践。
  官方也给出了 在 Kubernetes 集群中保护你的基础设施的建议：

• 集群（Cluster）：
  官方 关于集群，也给了相关建议。
  集群中的组件（你的应用）
  根据你的应用程序的受攻击面，你可能需要关注安全性的特定面，比如： 如果你正在运行中的一个服务（A 服务）在其他资源链中很重要，并且所运行的另一工作负载（服务 B） 容易受到资源枯竭的攻击，则如果你不限制服务 B 的资源的话，损害服务 A 的风险就会很高。 下表列出了安全性关注的领域和建议，用以保护 Kubernetes 中运行的工作负载。

总结：k8s官方 从分层的维度思考管理云原生安全问题。

Kubernetes安全专家认证-CKS认证

CKS是Kubernetes认证体系下的认证，CKS全称是Certified Kubernetes Security Specialist，中文名就是Kubernetes安全专家认证，考取这个证书之后证明考生具备在构建、部署和运行期间确保基于容器的应用程序和Kubernetes平台安全的必要能力，并且有资格在专业环境中执行这些任务。

5. 云安全解决方案（CWPP、CSPM、CASB、CNAPP）

Cloud Security Solutions: CWPP, CSPM, CASB, and More
参考URL: https://www.aquasec.com/cloud-native-academy/cspm/cloud-security-solutions-cwpp-cspm-casb-and-more/
[推荐]What’s The Difference Between CASB, CWPP, CSPM, and CNAPP?
参考URL: https://www.uptycs.com/blog/whats-the-difference-between-casb-cwpp-cspm-and-cnapp
三大云安全工具（CASB、CSPM、CWPP）的使用场景
参考URL: https://blog.csdn.net/m0_37740029/article/details/117324632

云安全毫无疑问已经成为一种趋势，无论是为政企等行业提供云服务平台的企业巨头，还是行业技术领袖，大家已经形成一种共识，就是未来的安全会在云端，云化已经成为一种趋势。我们经常会看到描述云安全的工具的一些术语如CASB,CSPM, CWPP。

其实这些都是 Gartner创造的术语。Gartner曾提出三大云原生安全管理工具，分别是CWPP、CSPM和CASB。

以下是云安全解决方案的主要类别：

• Cloud workload protection platform (CWPP)—a centralized solution for extending visibility into cloud resources, primarily to secure cloud workloads. CWPP enables you to perform security functions across multiple environments.
  云工作负载保护平台（CWPP） - 用于扩展可见性云资源的集中解决方案，主要是为了保护云工作负载。CWPP使您能够在多个环境中执行安全功能。

• Cloud security posture management (CSPM)—implements continuous, automated security and compliance processes, primarily to secure the infrastructure where workloads are deployed. CSPM helps prevent software configuration vulnerabilities and compliance risks.
  CSPM(Cloud Security Posture Management) 云安全配置管理 - 实现连续，自动安全和合规过程，主要是为了保护部署工作负载的基础架构。CSPM有助于防止软件配置漏洞和合规风险。

• Cloud access security broker (CASB)—solutions are implemented for the purpose of extending in-house visibility into cloud environments. CASB is located between on-premise and cloud infrastructure.
  (Cloud Security Access Broker) 云访问安全代理 - 该解决方案的实现是为了将内部可见性扩展到云环境中。CASB位于本地和云基础架构之间。

CWPP

什么是CWPP
参考URL: https://blog.csdn.net/inthat/article/details/120676278
[推荐]What’s The Difference Between CASB, CWPP, CSPM, and CNAPP?
参考URL: https://www.uptycs.com/blog/whats-the-difference-between-casb-cwpp-cspm-and-cnapp

云工作负载保护平台（CWPP）为所有类型的工作负载（包括物理服务器，虚拟机（VM），容器和无服务器工作负载）提供了以工作负载为中心的安全保护解决方案。

CWPP应该不受地理位置的影响，为物理机、虚拟机、容器和无服务器工作负载提供统一的可视化和控制力。CWPP产品通常结合使用网络分段、系统完整性保护、应用程序控制、行为监控、基于主机的入侵防御和可选的反恶意软件保护等措施，保护工作负载免受攻击。

总结： 简单来说只要是业务的载体（运行平台）都可以叫工作负载，包括物理服务器、虚拟机、容器和无服务器（serverless）。

CSPM

[推荐]What’s The Difference Between CASB, CWPP, CSPM, and CNAPP?
参考URL: https://www.uptycs.com/blog/whats-the-difference-between-casb-cwpp-cspm-and-cnapp

CSPM（云安全态势管理）: 云安全态势管理 (CSPM) 是 IT 安全工具的一个细分市场，旨在识别云中的错误配置问题和合规风险，其编程目的是持续监控云基础架构以发现安全策略执行中的安全漏洞。

CWPP从内部保护工作负载，而Cloud Security Postion Management（CSPM）通过评估云平台控制平面的安全且合规的配置，从外部保护工作负载。

CSPB

[推荐]What’s The Difference Between CASB, CWPP, CSPM, and CNAPP?
参考URL: https://www.uptycs.com/blog/whats-the-difference-between-casb-cwpp-cspm-and-cnapp

云访问安全代理（Cloud Access Security Broker，CASB，发音为KAZ-bee）是位于云服务消费者和云服务提供商（CSP）之间的内部或基于云的策略实施点，用于监视与云相关的活动，并应用与基于云的资源的使用相关的安全性、合规性和治理规则。

CASB可以通过API、转发代理、反向代理等方式来实现。

Cloud AccessSecurity Broker（CASB）本质上是用于云服务的防火墙。它提供了一个安全策略实施网关，以确保用户的操作得到授权并符合公司的安全策略。CASB可以识别组织使用的所有云服务，包括影子IT /未经批准或未经管理的SaaS和PaaS产品，并在必要时发出警报。它可以跟踪，报告和记录云使用情况，评估影子IT带来的风险，并进行事件监视。CASB具有审核和报告工具，可用于法规遵从性，包括云存储的数据。这些工具提供了用户身份验证，授权和策略执行，例如移动和加密文件，更改权限以及过滤消息。

CNAPP （云原生应用保护平台）

[推荐]What’s The Difference Between CASB, CWPP, CSPM, and CNAPP?
参考URL: https://www.uptycs.com/blog/whats-the-difference-between-casb-cwpp-cspm-and-cnapp

由Gartner创造的术语Cloud-Native Application Protection Platform（CNAPP）结合了CWPP和CSPM的功能，可扫描开发中的工作负载和配置并在运行时对其进行保护。

参考

快进键启动，一文带你了解云原生时代容器安全
参考URL: https://zhuanlan.zhihu.com/p/372881372
云原生时代，如何确保容器的全生命周期安全？
参考URL: https://segmentfault.com/a/1190000040340382
[推荐]云原生安全介绍
参考URL: https://blog.csdn.net/xlsj228/article/details/122834775
青藤云安全：蜂巢之声之如何确保容器的全生命周期安全
参考URL: https://zhuanlan.zhihu.com/p/160804637
云原生安全成熟度标准解读及信通院工作介绍
参考URL: https://www.doc88.com/p-19459797509286.html