Posted inSecurity

Tự động hóa bảo mật Infrastructure as Code với Checkov: Ngăn ngừa lỗi cấu hình trong CI/CD

Security tutorial - IT technology blog
Security tutorial - IT technology blog

Vấn đề thực tế: Cái giá đắt của những lỗi cấu hình đám mây âm thầm

Quý trước, một nhóm kỹ sư tại một công ty fintech quy mô vừa đã tạo một pull request Terraform tưởng chừng rất bình thường: một staging bucket nội bộ và một pod Kubernetes phụ trợ. Quá trình code review diễn ra thuận lợi. Cả hai reviewer đều phê duyệt merge trong vòng 15 phút, và các thay đổi được deploy thẳng lên AWS. Chưa đầy 48 giờ sau, các công cụ quét tự động của Shodan đã phát hiện một S3 bucket không được mã hóa với quyền public read, trong khi container Kubernetes thì chạy với root UID 0 và mở cổng privileged ra bên ngoài.

Đây không phải là trường hợp cá biệt. Dữ liệu từ Palo Alto Networks chỉ ra rằng hơn 65% sự cố bảo mật đám mây bắt nguồn trực tiếp từ lỗi cấu hình (misconfiguration), chứ không phải do các lỗ hổng zero-day trên hypervisor. Các vụ xâm nhập môi trường production hiếm khi đòi hỏi mã độc tinh vi. Thay vào đó, nguyên nhân chỉ là do kỹ sư bỏ quên cờ encrypted = true trên một EBS volume, hoặc vô tình để allowPrivilegeEscalation: true bên trong manifest deployment.

Nhiều nhóm phát triển đối xử với Infrastructure as Code (IaC) hệt như code ứng dụng thông thường, tin tưởng rằng quy trình peer review truyền thống sẽ bắt được mọi lỗi sai. Nhưng các file hạ tầng lại là một câu chuyện hoàn toàn khác. Các manifest thường dàn trải qua hàng nghìn dòng HCL, YAML và JSON. Ngay cả những platform architect dày dạn kinh nghiệm cũng dễ dàng bỏ sót các dải CIDR egress chưa được giới hạn, tính năng access logging bị tắt, hoặc các policy KMS quá lỏng lẻo khi phải review những bản diff khổng lồ dưới áp lực thời gian.

Phân tích nguyên nhân gốc rễ: Vì sao cấu hình mặc định của hạ tầng lại khiến chúng ta thất bại

Hạ tầng thiếu an toàn liên tục lọt vào production xuất phát từ những điểm yếu mang tính cấu trúc trong cách các tài nguyên cloud nguyên bản và engine IaC tương tác với nhau.

1. Cấu hình mặc định quá lỏng lẻo và xu hướng viết code ngắn gọn

Các nhà cung cấp đám mây ưu tiên trải nghiệm onboarding mượt mà hơn là thiết lập các giá trị mặc định có tính phòng thủ. Trong Terraform, việc bỏ qua một block cấu hình tùy chọn thường sẽ rơi về trạng thái ít hạn chế nhất. Chẳng hạn, khai báo một aws_ebs_volume mà không có block encryption sẽ không đưa ra cảnh báo nào—Terraform đơn giản là khởi tạo một ổ đĩa không được mã hóa. Các kỹ sư khi cố viết code gọn gàng đã vô tình đưa vào các lỗ hổng bảo mật chỉ vì bỏ sót những dòng thiết lập mà họ cứ ngỡ là đã được bật sẵn theo mặc định.

2. Độ trễ của việc kiểm toán tại runtime

Các công cụ Cloud Security Posture Management (CSPM) truyền thống thường chỉ kiểm tra hạ tầng cloud đang chạy sau khi đã triển khai xong. Khi một công cụ CSPM phát hiện rule ingress mở toang trên port 22, cảnh báo đó lại rơi vào một kênh Slack hoặc hàng đợi PagerDuty vốn đã quá tải:

  • Tài nguyên chứa lỗ hổng đã hoạt động và đang tiếp xúc trực tiếp với lưu lượng internet.
  • Các mạng botnet tự động có thể đã quét trúng instance đó chỉ trong vòng vài phút sau khi tạo.
  • Việc khắc phục tài nguyên đang chạy đòi hỏi hotfix khẩn cấp, can thiệp thủ công trên console, và tiềm ẩn nguy cơ configuration drift.

3. Quá tải nhận thức trong quá trình Code Review

Peer review thường tập trung vào logic chức năng và kiến trúc: “Cấu hình này có khởi tạo read replica ở us-east-1 đúng không?” Người review hiếm khi đủ sức kiểm tra xem hàng chục quy tắc kiểm soát chi tiết của CIS benchmark có được thỏa mãn trên từng tài nguyên con lồng nhau hay không. Việc xác thực bảo mật đòi hỏi tự động hóa có thể lặp lại, chứ không thể dựa vào trí nhớ của con người.

Chúng ta cũng thấy vấn đề tương tự với secret và quá trình bootstrap máy chủ. Bất cứ khi nào cần tạo thông tin đăng nhập root thô, tôi luôn tránh việc gõ bừa chuỗi ký tự thủ công và chuyển sang dùng các công cụ như trình tạo mật khẩu client-side tại toolcraft.app/vi/tools/security/password-generator, vốn thực thi hoàn toàn trong bộ nhớ trình duyệt mà không gửi bất kỳ dữ liệu nào qua mạng. Mã nguồn hạ tầng cũng đòi hỏi chính xác tư duy đó: hãy mặc định rằng mọi tài nguyên trần đều không an toàn cho đến khi các bước kiểm tra tự động xác nhận điều ngược lại.

So sánh các giải pháp: Review thủ công vs. CSPM tại Runtime vs. Quét IaC tĩnh

Các nhóm kỹ thuật nhìn chung dựa vào ba chiến lược chính để ngăn chặn lỗi cấu hình đám mây lọt vào production. Mỗi phương pháp đều có những đánh đổi rõ ràng.

Phương pháp Thời điểm phát hiện Ưu điểm Nhược điểm
Peer Review thủ công Pull Request Hiểu rõ ngữ cảnh nghiệp vụ của nhóm; không cần cài thêm phần mềm mới. Chậm, thiếu nhất quán và thường xuyên bỏ sót các tiêu chuẩn CIS benchmark tinh vi.
Bộ quét CSPM tại Runtime Môi trường Cloud trực tiếp (AWS, GCP, Azure) Phát hiện tình trạng drift qua console và những thay đổi hạ tầng ngoài luồng. Bị động; lỗi đã lọt vào production trước; dễ gây mệt mỏi vì quá nhiều cảnh báo.
Phân tích IaC tĩnh (Shift-Left) Pre-Commit cục bộ & CI/CD Chặn đứng lỗi bảo mật trước khi cấp phát tài nguyên trên cloud; phạm vi ảnh hưởng bằng 0. Cần thời gian tinh chỉnh pipeline ban đầu và quản lý chính sách baseline.

Chỉ trông cậy vào review thủ công chắc chắn sẽ bỏ sót lỗ hổng. Chờ đợi cảnh báo từ CSPM runtime đồng nghĩa với việc team của bạn sẽ mãi mắc kẹt trong vòng xoáy chữa cháy trên production. Phân tích IaC tĩnh giải quyết triệt để khoảng trống này, bắt trọn các lỗi cấu hình khi tài nguyên vẫn chỉ là những file văn bản vô hại.

Giải pháp: Tự động hóa kiểm tra Shift-Left với Checkov

Cách sạch sẽ và hiệu quả nhất để bảo vệ các file IaC là sử dụng Checkov, một static analysis engine mã nguồn mở do Bridgecrew phát triển và hiện được duy trì bởi Palo Alto Networks. Checkov có khả năng phân tích cú pháp của Terraform, Kubernetes manifest, Helm chart, CloudFormation và Dockerfile.

Công cụ này kiểm tra hạ tầng dựa trên hơn 1.000 quy tắc tích hợp sẵn, được ánh xạ theo các tiêu chuẩn CIS Benchmark, NIST 800-53, HIPAA và PCI-DSS. Quan trọng nhất, nó chặn đứng các cấu hình mất an toàn trước khi lệnh terraform apply hoặc kubectl apply kịp chạm tới API.

Bước 1: Cài đặt và chạy Checkov cục bộ

Bạn có thể chạy Checkov thông qua Python hoặc Docker. Với môi trường Python cục bộ:

# Cài đặt Checkov
pip3 install checkov

# Xác nhận binary CLI hoạt động bình thường
checkov --version

Nếu bạn muốn chạy dạng container để không cần phụ thuộc vào môi trường Python:

docker run --tty --volume $(pwd):/tf --workdir /tf bridgecrew/checkov --directory .

Bước 2: Bắt lỗi bảo mật trong Terraform

Xét đoạn code Terraform tối giản nhưng chứa lỗi dưới đây trong file main.tf:

resource "aws_s3_bucket" "app_data" {
  bucket = "my-app-user-backups-bucket"
}

resource "aws_ebs_volume" "web_disk" {
  availability_zone = "us-east-1a"
  size              = 40
  # Thiếu: encrypted = true
}

Thực hiện quét có chủ đích đối với thư mục này:

checkov -d . --framework terraform

Chỉ sau vài giây, Checkov sẽ gắn cờ cảnh báo ổ đĩa chưa được mã hóa và bucket thiếu các biện pháp kiểm soát:

Check: CKV_AWS_18: "Đảm bảo S3 bucket đã bật access logging"
	FAILED for resource: aws_s3_bucket.app_data
	File: /main.tf:1-3

Check: CKV_AWS_3: "Đảm bảo toàn bộ dữ liệu lưu trữ trong EBS được mã hóa an toàn"
	FAILED for resource: aws_ebs_volume.web_disk
	File: /main.tf:5-8
	Guide: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/aws-policies/aws-general-policies/ensure-ebs-volume-is-encrypted

Bước 3: Kiểm tra các manifest Kubernetes mất an toàn

Checkov đánh giá các file YAML của Kubernetes cũng hiệu quả không kém. Dưới đây là một file deployment.yaml được cấp quyền quá mức:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-api
spec:
  replicas: 2
  template:
    spec:
      containers:
      - name: payment-api
        image: payment-api:v1.2.0
        securityContext:
          privileged: true
          runAsUser: 0

Lọc phạm vi quét để kiểm tra riêng tài nguyên Kubernetes:

checkov -f deployment.yaml --framework kubernetes

Lượt quét sẽ phát hiện cả hành vi thực thi dưới quyền root (UID 0) lẫn cờ container privileged đầy nguy hiểm:

Check: CKV_K8S_16: "Không chạy container dưới quyền user root"
	FAILED for resource: Deployment.default.payment-api
	File: /deployment.yaml:9-15

Check: CKV_K8S_17: "Không sử dụng privileged container"
	FAILED for resource: Deployment.default.payment-api
	File: /deployment.yaml:9-15

Bước 4: Tích hợp Checkov vào GitHub Actions

Quét cục bộ hỗ trợ rất tốt cho từng lập trình viên, nhưng các rào chắn tự động trong CI/CD mới là thứ bảo vệ toàn bộ đội ngũ. Workflow GitHub Actions sau (.github/workflows/iac-security.yml) sẽ quét mọi PR nhắm vào nhánh main của bạn:

name: Quét bảo mật IaC

on:
  pull_request:
    branches: [ main ]
  push:
    branches: [ main ]

jobs:
  checkov:
    name: Chạy Checkov Scanner
    runs-on: ubuntu-latest
    steps:
      - name: Checkout mã nguồn
        uses: actions/checkout@v4

      - name: Cài đặt môi trường Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Cài đặt Checkov
        run: pip install checkov

      - name: Thực thi quét Checkov
        run: |
          checkov -d . \
            --compact \
            --quiet \
            --framework terraform,kubernetes \
            --soft-fail

Chiến lược triển khai: Hãy đặc biệt lưu ý đến tham số --soft-fail trong workflow trên. Việc áp đặt quét chặn nghiêm ngặt ngay lập tức trên một codebase cũ sẵn có sẽ làm gãy hàng tá bản build ngay ngày đầu tiên. Hãy bắt đầu với --soft-fail để đánh giá mức độ rủi ro baseline hiện tại, ghi nhận các khoản nợ kỹ thuật tồn đọng, bổ sung file .checkov.yml ở cấp repository để tạm bỏ qua những trường hợp ngoại lệ đã được duyệt, rồi sau đó mới gỡ cờ này khi các lỗi hiện tại đã được khắc phục xong.

Xử lý các ngoại lệ có tài liệu rõ ràng

Một số tác vụ đặc thù bắt buộc phải có cấu hình nới lỏng theo đúng thiết kế. Thay vì tắt toàn bộ danh mục quy tắc hoặc bỏ qua cả file, hãy ghi chú các trường hợp bỏ qua rõ ràng ngay trong code bằng comment inline:

resource "aws_s3_bucket" "public_assets" {
  bucket = "static-company-logos"
  
  #checkov:skip=CKV_AWS_20:"Bucket này chủ đích để public phục vụ tài nguyên tĩnh trên CDN"
}

Việc tích hợp Checkov vào pipeline phân phối phần mềm sẽ chuyển đổi bảo mật đám mây từ một quy trình kiểm toán hậu triển khai nặng nề thành một chốt chặn tự động mượt mà, được tích hợp trực tiếp vào từng pull request của nhóm bạn.

Share:
Tags: