DevOps 8 — Bảo mật, Vận hành & SRE

Bạn đã biết cách build, đóng gói, triển khai và giám sát ứng dụng qua các bài trước. Nhưng đưa được code lên production mới chỉ là một nửa câu chuyện. Nửa còn lại — và thường là phần khiến người ta mất ngủ lúc 3 giờ sáng — là làm sao để hệ thống an toàn, luôn sống, và phục hồi nhanh khi có sự cố. Bài này đi từ con số 0 đến mức "hero" về ba trụ cột: bảo mật (DevSecOps), khả năng mở rộng & sẵn sàng cao, và kỹ thuật vận hành theo triết lý SRE.

Hãy ghi nhớ một câu thần chú xuyên suốt: bảo mật và độ tin cậy không phải là tính năng bạn gắn vào cuối cùng — chúng là thuộc tính bạn nuôi từ dòng code đầu tiên.

DevSecOps — Dịch chuyển bảo mật sang trái

"Shift left" nghĩa là gì?

Trong mô hình cũ, bảo mật là chốt chặn cuối cùng: đội security audit ứng dụng ngay trước khi go-live, tìm ra lỗ hổng, và bắt dev sửa gấp. Hậu quả là sửa muộn, đắt, và đầy căng thẳng. Một lỗi tìm thấy ở giai đoạn thiết kế rẻ hơn hàng trăm lần so với lỗi tìm thấy ở production.

DevSecOps đảo ngược điều này: đẩy các hoạt động kiểm tra bảo mật về phía trái của vòng đời phần mềm (gần lúc viết code hơn), và tự động hóa chúng trong pipeline CI/CD. Bảo mật trở thành trách nhiệm của mọi người, không chỉ một đội riêng.

Các loại quét tự động trong pipeline

Có bốn nhóm kiểm tra chính, mỗi loại soi một góc khác nhau:

Tích hợp vào CI/CD

Nguyên tắc thực tế: chạy quét nhanh (SAST, dependency scan) ở mỗi pull request để phản hồi tức thì; chạy quét nặng (DAST) định kỳ hoặc trên nhánh chính. Đặt ngưỡng phá build (fail gate) hợp lý — ví dụ chỉ chặn merge khi phát hiện lỗ hổng mức Critical/High, còn mức thấp thì cảnh báo. Nếu chặn mọi thứ, dev sẽ tìm cách bỏ qua, và bảo mật mất tác dụng.

# Ví dụ một stage scan trong GitLab CI
dependency-scan:
  stage: test
  script:
    - trivy fs --severity HIGH,CRITICAL --exit-code 1 .
  allow_failure: false   # Critical/High thì phá build

Mẹo: bật quét lỗ hổng trên image cơ sở (base image) và dùng image tối giản như distroless hoặc alpine để giảm bề mặt tấn công.

Quản lý secret — Đừng bao giờ commit mật khẩu

Vấn đề

Secret là mọi thứ không được lộ: mật khẩu database, API key, chứng chỉ TLS, token. Sai lầm kinh điển và chết người nhất là commit secret vào Git. Một khi đã đẩy lên repo, secret coi như lộ vĩnh viễn — kể cả khi bạn xóa commit sau đó, nó vẫn nằm trong lịch sử và có thể bị bot quét GitHub thu thập trong vài phút.

Các tầng giải pháp

1. Biến môi trường (environment variables) — Mức cơ bản. Code đọc secret từ process.env/os.environ thay vì viết cứng. File .env cho dev local, nhưng phải thêm .env vào .gitignore.

2. Secret manager của nền tảng — Kubernetes Secrets, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault. Tách secret khỏi cấu hình ứng dụng, có phân quyền truy cập.

3. HashiCorp Vault — Mức nâng cao. Vault lưu secret được mã hóa, hỗ trợ secret động (sinh credential database tạm thời, tự hết hạn), xoay vòng (rotation) tự động, và ghi log mọi lần truy cập.

Nguyên tắc vàng

• Không hardcode, không commit, không log secret ra console.
• Xoay vòng định kỳ và xoay ngay khi nghi ngờ rò rỉ.
• Dùng công cụ quét secret như gitleaks hoặc truffleHog trong pre-commit hook và CI để chặn từ gốc.
• Cấp quyền theo phạm vi nhỏ nhất: mỗi dịch vụ chỉ thấy secret nó cần.

Bảo mật mạng

TLS/HTTPS ở khắp nơi

Mọi lưu lượng — cả bên ngoài lẫn nội bộ giữa các dịch vụ — nên được mã hóa bằng TLS. Dùng Let's Encrypt để cấp chứng chỉ miễn phí, tự động gia hạn (qua certbot hoặc cert-manager trên Kubernetes). Bắt buộc HTTPS, redirect mọi HTTP sang HTTPS, và bật HSTS.

Reverse proxy & firewall

Đặt một reverse proxy (Nginx, Traefik, hoặc API Gateway) trước ứng dụng để: kết thúc TLS, giới hạn tốc độ (rate limiting) chống tấn công brute-force/DDoS, ẩn cấu trúc nội bộ, và thêm header bảo mật. Cấu hình firewall để chỉ mở đúng cổng cần thiết — ví dụ chỉ 443 ra Internet, còn cổng database (5432, 3306) tuyệt đối không phơi ra ngoài.

Least privilege & Network Policy

Least privilege (đặc quyền tối thiểu) là nguyên tắc nền tảng: mỗi tài khoản, dịch vụ, container chỉ được cấp đúng quyền tối thiểu để làm việc của nó — không hơn. Container không chạy bằng root. Service account chỉ đọc đúng bucket nó cần.

Trên Kubernetes, NetworkPolicy kiểm soát luồng giao tiếp giữa các pod theo mô hình "default deny" — mặc định cấm hết, rồi mở từng đường cụ thể:

# Chỉ cho pod 'api' nói chuyện với pod 'db'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-allow-api
spec:
  podSelector:
    matchLabels: { app: db }
  ingress:
    - from:
        - podSelector:
            matchLabels: { app: api }
      ports:
        - port: 5432

Scaling — Mở rộng để chịu tải

Dọc vs Ngang

• Scale dọc (vertical / scale up): tăng sức mạnh cho một máy — thêm CPU, RAM. Đơn giản nhưng có trần phần cứng và là điểm chết đơn lẻ. Phù hợp database truyền thống.
• Scale ngang (horizontal / scale out): thêm nhiều bản sao (instance) chạy song song sau một load balancer. Gần như không có trần, chịu lỗi tốt hơn, nhưng đòi hỏi ứng dụng stateless (không lưu trạng thái cục bộ trên từng instance — session để ở Redis/DB chung).

Quy tắc thực dụng: thiết kế stateless ngay từ đầu để scale ngang dễ dàng. Đây là điều kiện tiên quyết cho cloud-native.

Autoscaling

Tự động tăng/giảm số instance theo tải, giúp tiết kiệm chi phí lúc vắng và chịu được lúc cao điểm. Trên Kubernetes:

• HPA (Horizontal Pod Autoscaler): thêm/bớt pod theo CPU, memory, hoặc custom metric (ví dụ độ dài hàng đợi).
• Cluster Autoscaler: thêm/bớt node (máy) khi pod không có chỗ chạy.

Load balancer, CDN, Cache

Ba thành phần phối hợp giảm tải và tăng tốc:

• Load balancer phân phối request đều ra các instance (round-robin, least-connections) và bỏ instance hỏng ra khỏi vòng (qua health check).
• CDN (Content Delivery Network): đặt nội dung tĩnh (ảnh, JS, CSS) ở các điểm gần người dùng trên toàn cầu, giảm độ trễ và tải cho server gốc.
• Cache (Redis, Memcached): lưu kết quả truy vấn đắt đỏ trong bộ nhớ. Nguyên tắc: cache giảm tải database mạnh nhất, nhưng phải xử lý đúng việc vô hiệu hóa cache (cache invalidation) — một trong hai bài toán khó nhất của khoa học máy tính.

High Availability & Disaster Recovery

Tư duy: chấp nhận mọi thứ sẽ hỏng

Phần cứng hỏng, mạng đứt, vùng dữ liệu (region) sập. Hệ thống sẵn sàng cao (HA) được thiết kế để không có điểm chết đơn lẻ (no single point of failure) — luôn có bản dự phòng sẵn sàng tiếp quản.

Các kỹ thuật then chốt

• Replication: nhân bản dữ liệu sang nhiều node/zone. Có thể đồng bộ (an toàn hơn, chậm hơn) hoặc bất đồng bộ (nhanh hơn, có rủi ro mất dữ liệu nhỏ).
• Failover: khi node chính chết, một bản sao tự động được "thăng cấp" thành chính. Có thể tự động hoặc thủ công.
• Backup: sao lưu định kỳ, lưu ở vị trí khác với production. Quan trọng nhất: kiểm tra phục hồi (restore test) thường xuyên — một backup chưa từng được restore thành công thì coi như không có backup.

RTO và RPO

Hai chỉ số định lượng khả năng phục hồi sau thảm họa, và chúng định hình toàn bộ chiến lược của bạn:

• RTO (Recovery Time Objective): Bao lâu để khôi phục dịch vụ sau sự cố? (Ví dụ: 1 giờ.)
• RPO (Recovery Point Objective): Bao nhiêu dữ liệu được phép mất, tính theo thời gian? (Ví dụ: tối đa 5 phút dữ liệu cuối.)

RTO/RPO càng nhỏ thì chi phí càng cao. Hãy chọn con số dựa trên giá trị nghiệp vụ, không phải tham vọng kỹ thuật.

Site Reliability Engineering (SRE)

SRE là cách Google biến vận hành thành một bài toán kỹ thuật phần mềm. Triết lý cốt lõi: dùng code và dữ liệu để quản lý độ tin cậy, thay vì dựa vào nỗ lực thủ công và "anh hùng cứu hỏa".

SLI, SLO và Error Budget

• SLI (Indicator): một số đo thực tế về chất lượng dịch vụ — ví dụ tỷ lệ request thành công, độ trễ p99.
• SLO (Objective): mục tiêu cho SLI — ví dụ "99.9% request thành công trong 30 ngày".
• Error budget (ngân sách lỗi): phần "được phép hỏng". Nếu SLO là 99.9%, thì 0.1% là ngân sách lỗi.

Đây là ý tưởng đẹp nhất của SRE: error budget cân bằng tốc độ phát triển và độ ổn định. Còn ngân sách → đội dev được tự do release tính năng mới nhanh. Hết ngân sách (đã hỏng quá nhiều) → đóng băng tính năng, dồn lực vào ổn định. Không cần tranh cãi cảm tính giữa dev và ops nữa — con số tự quyết định.

Toil — Kẻ thù của SRE

Toil là công việc vận hành lặp đi lặp lại, thủ công, không tạo giá trị lâu dài và có thể tự động hóa (ví dụ: restart service bằng tay, gia hạn chứng chỉ thủ công). SRE đặt mục tiêu giữ toil dưới một ngưỡng (Google: <50% thời gian), phần còn lại dành cho kỹ thuật để diệt tận gốc toil bằng automation.

Postmortem không đổ lỗi (Blameless)

Khi sự cố xảy ra, viết postmortem: mô tả điều gì đã xảy ra, dòng thời gian, nguyên nhân gốc, và hành động khắc phục. Nguyên tắc không đổ lỗi (blameless): tập trung vào hệ thống và quy trình đã cho phép lỗi xảy ra, không phải vào cá nhân. Khi người ta không sợ bị trừng phạt, họ chia sẻ trung thực — và tổ chức mới thực sự học được. Một sự cố là một bài học đắt tiền; lãng phí nó bằng cách đổ lỗi là tệ gấp đôi.

On-call

Chế độ trực sự cố. SRE lành mạnh nghĩa là: lịch trực công bằng, có runbook rõ ràng cho từng loại cảnh báo, cảnh báo phải có thể hành động (không spam báo động giả gây "alert fatigue"), và sau mỗi ca trực mệt mỏi thì cải tiến để lần sau nhẹ hơn.

Chaos Engineering (giới thiệu)

Chaos engineering là chủ động tiêm lỗi vào hệ thống production (hoặc gần production) để kiểm chứng nó thực sự chịu lỗi như thiết kế — tắt ngẫu nhiên một instance, thêm độ trễ mạng, lấp đầy ổ đĩa. Tiên phong là Netflix Chaos Monkey. Triết lý: thà tự gây ra lỗi nhỏ có kiểm soát vào giờ hành chính, còn hơn để lỗi lớn tự nổ lúc 3 giờ sáng. Bắt đầu nhỏ, có "blast radius" giới hạn, và luôn có nút dừng.

Checklist vận hành production

Trước khi tự tin đưa hệ thống ra thật, soi qua danh sách này:

Bảo mật

• Quét SAST + dependency + container đã bật trong CI, có fail gate cho Critical/High.
• Không có secret nào trong Git; secret nằm ở Vault/secret manager.
• TLS bật ở mọi endpoint; chứng chỉ tự động gia hạn.
• Firewall mở tối thiểu; database không phơi ra Internet.
• Container chạy non-root; least privilege cho mọi service account.

Độ tin cậy & Scaling

• Ứng dụng stateless, scale ngang được; autoscaling đã cấu hình.
• Load balancer có health check; không có điểm chết đơn lẻ.
• Cache & CDN cho nội dung phù hợp.
• Replication bật; failover đã được test thật.

Disaster Recovery

• Backup tự động, lưu ở vị trí tách biệt.
• Đã restore thử backup thành công gần đây.
• RTO/RPO được định nghĩa và khớp nhu cầu nghiệp vụ.

Vận hành & SRE

• SLO và error budget được định nghĩa và theo dõi.
• Monitoring + alerting hành động được, không spam.
• Runbook cho mỗi cảnh báo; lịch on-call rõ ràng.
• Quy trình postmortem blameless đã có.

Tóm tắt

Bảo mật và độ tin cậy là thuộc tính phải được nuôi từ đầu, không phải gắn vào cuối. DevSecOps đẩy kiểm tra bảo mật (SAST, DAST, dependency scan) vào pipeline và tự động hóa chúng. Quản lý secret đúng cách — không bao giờ commit, dùng Vault/secret manager, xoay vòng — là phòng tuyến cơ bản nhất. Bảo mật mạng dựa trên TLS khắp nơi, reverse proxy, firewall và least privilege. Về độ tin cậy: scaling ngang với ứng dụng stateless và autoscaling giúp chịu tải; HA & DR với replication, failover, backup (đã test restore) cùng RTO/RPO rõ ràng giúp sống sót qua thảm họa. Cuối cùng, SRE biến vận hành thành kỹ thuật: SLO/error budget cân bằng tốc độ và ổn định, diệt toil bằng automation, postmortem blameless để học hỏi, và chaos engineering để chủ động kiểm chứng sức chịu đựng.

Tự kiểm tra

1. "Shift left" trong DevSecOps nghĩa là gì, và tại sao tìm lỗ hổng sớm lại rẻ hơn?
2. Phân biệt SAST, DAST và dependency scan — mỗi loại soi điều gì?
3. Vì sao tuyệt đối không được commit secret vào Git, kể cả khi xóa sau đó? Vault giải quyết vấn đề này thế nào?
4. RTO và RPO khác nhau ở điểm nào? Cho ví dụ một con số cho mỗi chỉ số.
5. Error budget hoạt động ra sao để cân bằng giữa phát triển tính năng và độ ổn định?
6. Tại sao postmortem phải "không đổ lỗi", và điều đó mang lại lợi ích gì cho tổ chức?

Đọc tiếp

Đây là bài cuối của loạt DevOps zero-to-hero. Để nhìn lại bức tranh tổng thể và xâu chuỗi các khái niệm, hãy quay lại DevOps 1 — Giới thiệu. Nếu bạn muốn ôn lại nền tảng đã dẫn tới bài này, gợi ý xem lại các chủ đề về CI/CD và container/orchestration trong những bài trước của loạt, vì chính chúng là nơi bạn tích hợp các bước quét bảo mật và cấu hình autoscaling mà bài này mô tả.

Use case thực tế

(Tình huống minh hoạ, số liệu mang tính ước lượng để giảng giải.)

Đội vận hành hệ thống Internet Banking của NCB cần đưa ba trụ cột của bài này vào thực tế cho luồng "chuyển khoản liên ngân hàng" — luồng nhạy cảm nhất về cả bảo mật lẫn độ tin cậy.

Bảo mật (DevSecOps). Pipeline CI/CD của dịch vụ chuyển khoản bật SAST (Semgrep) + SCA (Trivy) ở mỗi pull request, đặt fail gate cho lỗ hổng Critical/High. Trong một đợt quét, Trivy phát hiện một thư viện phụ thuộc có CVE mức High → build bị chặn, dev nâng phiên bản trước khi merge, tránh đẩy lỗ hổng lên production. Toàn bộ secret (mật khẩu DB core, khóa ký giao dịch) rời khỏi file cấu hình, chuyển vào Vault với secret động TTL 60 phút và xoay vòng tự động; gitleaks chạy trong pre-commit chặn mọi lần lỡ tay commit khóa.

Độ tin cậy & SRE. Đội đặt SLO = 99,9% giao dịch thành công trong 30 ngày, tương ứng error budget ~43 phút/tháng (ước lượng). Ứng dụng chạy stateless sau load balancer trên hai zone, DB primary–replica có failover; backup được restore thử hàng tháng với RTO mục tiêu 1 giờ, RPO 5 phút. Khi một sự cố timeout cổng thanh toán "đốt" gần hết error budget, đội đóng băng tính năng mới, dồn lực ổn định và viết postmortem blameless — biến sự cố thành runbook cho ca on-call sau.

Ghi nhớ

• Bảo mật và độ tin cậy là thuộc tính nuôi từ dòng code đầu tiên, không phải tính năng gắn vào cuối; "shift left" giúp bắt lỗi sớm, rẻ hơn nhiều lần.
• DevSecOps tự động hóa SAST, DAST, SCA/dependency scan và IaC/container scan trong CI/CD, với fail gate hợp lý (chặn Critical/High) để dev không tìm cách né.
• Không bao giờ commit secret vào Git — đã đẩy là coi như lộ vĩnh viễn; dùng biến môi trường → secret manager → Vault (secret động, xoay vòng), và quét bằng gitleaks/truffleHog.
• Bảo mật mạng dựa trên TLS ở khắp nơi, reverse proxy + firewall mở tối thiểu, không phơi cổng database, và least privilege / NetworkPolicy "default deny".
• Scale ngang cần ứng dụng stateless; kết hợp autoscaling (HPA, Cluster Autoscaler), load balancer, CDN và cache để chịu tải và tăng tốc.
• HA & DR: thiết kế không có điểm chết đơn lẻ với replication, failover, backup — và một backup chưa từng restore thành công thì coi như không có.
• RTO/RPO định lượng khả năng phục hồi và định hình chi phí; chọn con số theo giá trị nghiệp vụ, không theo tham vọng kỹ thuật.
• SRE biến vận hành thành kỹ thuật: SLO/error budget cân bằng tốc độ và ổn định, diệt toil bằng automation, postmortem blameless để học hỏi, chaos engineering để chủ động kiểm chứng.

Nguồn tham khảo

• Google — Site Reliability Engineering (SRE Book) — SLI/SLO, error budget, toil, on-call, postmortem
• Google — The Site Reliability Workbook — áp dụng thực hành SRE, ví dụ triển khai SLO
• OWASP Top Ten — các rủi ro bảo mật ứng dụng web phổ biến nhất
• CIS Benchmarks — cấu hình cứng hóa (hardening) cho hệ điều hành, container, Kubernetes, cloud
• NIST Cybersecurity Framework — khung quản trị rủi ro an ninh mạng
• HashiCorp Vault Documentation — quản lý secret, secret động, xoay vòng
• Kubernetes Documentation — Network Policies — kiểm soát luồng mạng giữa các pod