2023云原生安全值得关注的3个方向

news2024/11/19 1:48:07

如果说过去几年教会了我们什么的话，那就是云原生和开源环境中安全的重要性。 Log4j 等漏洞产生的重大影响，在无数的行业中浮现，对于云原生环境中的其他安全问题也越来越受到重视。

组织不再质疑是否要迁移到云端，而是在寻找最快、最有效的方法。在这些过渡和升级中，安全性常常被忽视。正因为如此，加上开源软件在各地的兴起，我们很可能会在 2023 年看到更多云原生安全问题，这只是时间问题。

eBPF

eBPF 允许组织编写自定义代码以在内核中运行。通过使 Linux 内核可编程，eBPF 在网络、可观察性和安全性等领域引入了新一代云原生工具。

eBPF 可由执行字节码指令、存储对象和 Helper 帮助函数组成，字节码指令在内核执行前必须通过 BPF 验证器 Verfier 的验证，同时在启用 BPF JIT 模式的内核中，会直接将字节码指令转成内核可执行的本地指令运行。

同时，eBPF 也逐渐在观测（跟踪、性能调优等）、安全和网络等领域发挥重要的角色。Facebook、NetFlix 、CloudFlare 等知名互联网公司内部广泛采用基于 eBPF 技术的各种程序用于性能分析、排查问题、负载均衡、防范 DDoS 攻击，据相关信息显示在 Facebook 的机器上内置一系列 eBPF 的相关工具。

相对于系统的性能分析和观测，eBPF 技术在网络技术中的表现，更是让人眼前一亮，BPF 技术与 XDP（eXpress Data Path）和 TC（Traffic Control）组合可以实现功能更加强大的网络功能，更可为 SDN 软件定义网络提供基础支撑。XDP 只作用与网络包的 Ingress 层面，BPF 钩子位于网络驱动中尽可能早的位置，无需进行原始包的复制就可以实现最佳的数据包处理性能，挂载的 BPF 程序是运行过滤的理想选择，可用于丢弃恶意或非预期的流量、进行 DDOS 攻击保护等场景；而 TC Ingress 比 XDP 技术处于更高层次的位置，BPF 程序在 L3 层之前运行，可以访问到与数据包相关的大部分元数据，是本地节点处理的理想的地方，可以用于流量监控或者 L3/L4 的端点策略控制，同时配合 TC egress 则可实现对于容器环境下更高维度和级别的网络结构。

许多 CNCF 项目，包括 Cillium、Falco 和 Pixie，旨在将 eBPF 的优势引入云原生，而其他项目，如 Istio，正在重新设计以包含 eBPF 工具。 eBPF 可以通过多种方式提高云原生安全性。例如，Cillium 可以帮助提供对容器工作负载的更多可见性，而 Falco 提供了一个行为活动监视器，旨在检测容器运行时中的异常活动。

eBPF 是一套通用执行引擎，提供了可基于系统或程序事件高效安全执行特定代码的通用能力，通用能力的使用者不再局限于内核开发者；

SBOM

SBOM 的概念相对简单——它提供软件中的组件列表，长期以来一直作为供应链管理的一部分用于传统制造业。在实践中，它提供了很多好处，包括依赖项的安全警报以及对工件来源和软件供应链的更完整视图。

云原生环境中随着微服务、分布式应用的不断发展，带来了更多的风险。这并不是为了减少维护人员所做的工作;它们是现代软件供应链的重要组成部分，提供从小型模块到整个基于容器的平台的一切。由于代码的重要性，他们的价值被低估，薪酬也被低估。可悲的是，有好几次坏角色主动提出接管代码维护工作，却加入了恶意软件，希望代码能够自动安装，因为它有一段值得信赖的历史。

随着我们的代码越来越多地成为团队的一部分，我们可以期望看到更多类似这样的攻击。我们如何保护自己和应用程序?首先也是最重要的是，我们需要了解软件供应链确实存在，我们不是孤立地构建代码，而且我们已经很久没有这样做了，如果我们曾经这样做过的话。开源和第三方库是我们如何制作软件的一个重要部分，它们只会变得更加重要。

我们可以采取哪些步骤来确保软件供应链的安全?在提供管理软件材料清单的工具方面已经做了大量的工作：扫描库的代码，使用静态和动态分析，向代码中添加数字签名和散列，并将其全部纳入托管存储库。但有一个方面还不清楚：我们如何验证这项工作以及我们正在使用的代码?毕竟，古老的安全格言之一仍然是“信任但要验证”。

SBOM 在云原生中变得越来越普遍，它们将继续成为软件供应链安全的重要组成部分。 Kubernetes 已经采用 SBOM 并将其作为构建和发布的一部分生成。