Sự tiến hóa của bảo mật Cloud Native vào năm 2026

Bảo mật đám mây gốc đã trải qua một sự thay đổi kiến trúc cơ bản vào năm 2026. Vùng biên đã biến mất. Các workload mang tính nhất thời, các cụm trải rộng trên nhiều đám mây, và bán kính ảnh hưởng của một container bị xâm nhập có thể gây thảm họa nếu không có phòng thủ theo chiều sâu. Các mô hình bảo mật truyền thống - quy tắc tường lửa tĩnh, đường hầm VPN, kiểm tra vùng biên - không thể mô hình hóa các cấu trúc liên kết microservice động.

Bài đăng này đề cập đến bốn trụ cột kiến trúc định nghĩa bảo mật đám mây gốc ngày nay: định danh workload, tính toàn vẹn chuỗi cung ứng, phòng thủ hành vi thời gian chạy và thực thi chính sách dưới dạng mã. Mỗi phần bao gồm các cấu hình cấp độ sản xuất với các công cụ cụ thể.

Trụ cột 1: Định danh Workload với SPIFFE và SPIRE

Sự thay đổi cơ bản nhất là thay thế sự tin cậy dựa trên vị trí mạng (địa chỉ IP, phân đoạn VLAN) bằng định danh workload mật mã. Mọi dịch vụ phải chứng minh mình là ai, chứ không phải mình ở đâu.

SPIFFE (Secure Production Identity Framework for Everyone) cung cấp tiêu chuẩn. Mọi workload đều nhận được một SPIFFE ID, được biểu thị dưới dạng URI: spiffe://trust-domain/namespace/workload-name. Định danh được cung cấp dưới dạng chứng chỉ X.509 có thời hạn ngắn gọi là SPIFFE Verifiable Identity Document (SVID), được tự động xoay vòng bởi SPIRE (môi trường thời gian chạy SPIFFE).

# SPIRE agent ClusterSpiffeID registration via the SPIRE Kubernetes Workload Registrar
apiVersion: spire.spiffe.io/v1alpha1
kind: ClusterSpiffeID
metadata:
  name: payment-service
spec:
  spiffeIDTemplate: "spiffe://prod.example.org/ns/{{ .PodMeta.Namespace }}/sa/{{ .PodMeta.ServiceAccountName }}"
  podSelector:
    matchLabels:
      app: payment-service
  dnsNameTemplates:
    - "payment-service.{{ .PodMeta.Namespace }}.svc.cluster.local"

Sau khi SPIRE cấp SVID, các proxy sidecar của Envoy sử dụng chúng để thiết lập mTLS (mutual TLS) giữa mỗi cặp dịch vụ. Istio và Linkerd đều tích hợp với SPIRE thông qua SPIFFE Workload API.

Lợi thế quan trọng: ngay cả khi kẻ tấn công xâm nhập một node Kubernetes và truy cập mạng pod, chúng không thể giả mạo SVID của payment-service để đánh cắp dữ liệu thanh toán từ order-service. Chứng chỉ X.509 được ràng buộc mật mã với định danh của workload.

Xoay vòng SVID là tự động và có thể cấu hình. Đối với các workload bảo mật cao, hãy đặt TTL ngắn:

# SPIRE Server configuration
server:
  default_svid_ttl: "1h"
  ca_ttl: "24h"
  ca_key_type: "ec-p384"

TTL ngắn giới hạn cửa sổ phơi nhiễm nếu chứng chỉ bằng cách nào đó bị đánh cắp.

Trụ cột 2: Tính toàn vẹn chuỗi cung ứng phần mềm

Các cuộc tấn công SolarWinds và XZ Utils đã chứng minh rằng chính pipeline xây dựng là một bề mặt tấn công. Vào năm 2026, bảo mật chuỗi cung ứng là bắt buộc đối với các ngành công nghiệp được quản lý và ngày càng được mong đợi ở mọi nơi.

SLSA (Cấp độ chuỗi cung ứng cho các tạo phẩm phần mềm)

SLSA Cấp độ 3 yêu cầu:

1. Xây dựng theo kịch bản: không có bước xây dựng thủ công
2. Mã nguồn được kiểm soát phiên bản: các commit đã ký
3. Dịch vụ xây dựng: môi trường xây dựng kín, cô lập (GitHub Actions, Google Cloud Build)
4. Nguồn gốc: chứng thực đã ký về những gì đã được xây dựng và cách thức

Tự động tạo nguồn gốc SLSA trong GitHub Actions:

# .github/workflows/build.yml
jobs:
  build:
    permissions:
      id-token: write
      contents: read
      attestations: write
    steps:
      - uses: actions/checkout@v4
      - name: Build container image
        run: |
          docker build -t myapp:${{ github.sha }} .
          docker push registry.example.com/myapp:${{ github.sha }}
      
      - name: Attest build provenance
        uses: actions/attest-build-provenance@v1
        with:
          subject-name: registry.example.com/myapp
          subject-digest: sha256:${{ steps.build.outputs.digest }}
          push-to-registry: true

Tạo SBOM và đánh giá liên tục

Mọi hình ảnh container nên có một SBOM đã ký ở định dạng SPDX hoặc CycloneDX. Syft tạo chúng; Grype đánh giá chúng dựa trên NVD theo thời gian thực:

# Generate SBOM attached to the image
syft registry.example.com/myapp:latest \
  -o spdx-json \
  --file myapp-sbom.spdx.json

# Evaluate against CVE databases
grype sbom:myapp-sbom.spdx.json \
  --fail-on critical \
  --only-fixed

Tích hợp điều này vào CI như một cổng bắt buộc. Nếu một lỗ hổng zero-day được tiết lộ sau khi triển khai, kho SBOM của bạn ngay lập tức cho bạn biết những workload đang chạy nào bị ảnh hưởng - cho phép khắc phục mục tiêu thay vì vá lỗi mọi thứ một cách hoảng loạn.

Chứng thực chuỗi cung ứng in-toto

Để đảm bảo mức độ tin cậy cao nhất, in-toto ghi lại bằng chứng mật mã của mọi bước trong chuỗi cung ứng - từ commit của nhà phát triển đến đẩy hình ảnh container:

# in-toto link metadata for the "build" step
import in_toto.runlib

link = in_toto.runlib.in_toto_run(
    name="build",
    link_signing_key=signing_key,
    material_paths=["src/", "requirements.txt"],
    product_paths=["dist/app.tar.gz"],
    run_command=["python", "setup.py", "build"]
)
link.dump("build.link")

Chuỗi các tệp .link cung cấp một dấu vết bằng chứng có thể chấp nhận được trước tòa từ nguồn đến tạo phẩm - điều mà một hệ thống CI bị xâm nhập không thể giả mạo nếu không có khóa ký của nhà phát triển.

Trụ cột 3: Phòng thủ thời gian chạy với eBPF

Các biện pháp phòng ngừa là cần thiết nhưng không đủ. Một lỗ hổng zero-day hoặc một container bị cấu hình sai vẫn có thể dẫn đến một tiến trình bị xâm nhập. Bảo mật thời gian chạy cung cấp lớp thực thi hành vi.

eBPF (extended Berkeley Packet Filter) chạy các chương trình được sandbox bên trong nhân Linux, cung cấp khả năng hiển thị không có overhead đối với các lệnh gọi hệ thống, truy cập tệp và kết nối mạng mà không cần sửa đổi mã ứng dụng hoặc tải các module nhân.

Tetragon (từ Cilium) dịch các sự kiện nhân eBPF thành các chính sách thực thi:

# Tetragon TracingPolicy: block shell execution from web service pods
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: prevent-shell-from-web
spec:
  kprobes:
  - call: "sys_execve"
    syscall: true
    selectors:
    - matchNamespaces:
      - namespace: production
        values: [web-service]
      matchArgs:
      - index: 0
        operator: "Equal"
        values:
        - "/bin/sh"
        - "/bin/bash"
        - "/usr/bin/python3"
        - "/usr/bin/curl"
      matchActions:
      - action: Sigkill
        argName: comm

Chính sách này sẽ tiêu diệt bất kỳ tiến trình nào cố gắng execve một shell trong các pod sản xuất web-service - ngay lập tức ngăn chặn các nỗ lực RCE ngay cả khi CVE cơ bản chưa được biết đến trước đó.

Cilium Network Policy thực thi kiểm soát truy cập Lớp 7 (HTTP/gRPC) ở cấp độ nhân:

apiVersion: cilium.io/v1
kind: CiliumNetworkPolicy
metadata:
  name: payment-service-policy
spec:
  endpointSelector:
    matchLabels:
      app: payment-service
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: order-service
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "POST"
          path: "/v1/charge"

Chỉ order-service mới có thể gọi POST /v1/charge trên payment-service. Bất kỳ lưu lượng truy cập nào khác - bao gồm cả di chuyển ngang nội bộ từ một pod bị xâm nhập - đều bị loại bỏ ở cấp độ nhân trước khi nó đến ứng dụng.

Trụ cột 4: Chính sách dưới dạng mã với OPA Gatekeeper

Kiểm soát nhập học Kubernetes thực thi các chính sách bảo mật toàn cụm tại thời điểm triển khai. OPA Gatekeeper đánh giá mọi yêu cầu máy chủ API dựa trên các chính sách Rego:

# Deny containers running as root
package kubernetes.admission

deny[msg] {
  input.request.kind.kind == "Pod"
  container := input.request.object.spec.containers[_]
  not container.securityContext.runAsNonRoot == true
  msg := sprintf("Container '%v' must not run as root. Set securityContext.runAsNonRoot: true", [container.name])
}

# Require read-only root filesystem
deny[msg] {
  input.request.kind.kind == "Pod"
  container := input.request.object.spec.containers[_]
  not container.securityContext.readOnlyRootFilesystem == true
  msg := sprintf("Container '%v' must have a read-only root filesystem", [container.name])
}

Các chính sách này chặn các triển khai pod không an toàn trước khi chúng đến bộ lập lịch. Kết hợp với GitOps (Flux v2, ArgoCD), trạng thái cụm của bạn hoàn toàn được kiểm soát bởi chính sách - không có kubectl apply thủ công nào có thể bỏ qua kiểm soát nhập học.

Kiến trúc phòng thủ theo chiều sâu

Bốn trụ cột xếp chồng lên nhau thành một mô hình phòng thủ theo chiều sâu mạch lạc:

Không có lớp nào là đủ. Kẻ tấn công vượt qua định danh (SVID bị đánh cắp) vẫn sẽ bị phát hiện hành vi thời gian chạy. Một bản dựng bị xâm nhập vượt qua kiểm tra SBOM vẫn phải đối mặt với việc thực thi chính sách OPA khi nhập học.

Bạn cũng có thể thích

• Quan sát bảo mật eBPF với Cilium Tetragon: Thực thi runtime theo thời gian thực trong Kubernetes
• eBPF & Cilium trong Kubernetes: Định tuyến thông lượng cao, Chính sách mạng & Khả năng quan sát Hubble
• Cilium và Calico với eBPF: Thông lượng mạng Kubernetes, bảo mật & Service Mesh
• Cilium Service Mesh với eBPF: mTLS không sidecar & Benchmark (2026)

Kiểm tra kiến thức