Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng đội vận hành của bạn đã làm mọi thứ đúng: hệ thống chạy ổn định, uptime 99,99%, incident được xử lý gọn gàng. Nhưng vào một buổi sáng thứ Hai, một kỹ sư phát hiện có ai đó đã dùng credential rò rỉ để đăng nhập vào production database từ hai tuần trước — và bạn không hề biết. Không có cảnh báo, không có log, không có ai truy vết được kẻ tấn công đã làm gì trong 14 ngày đó.
Đây chính là khoảng trống mà Security Operations (SecOps) lấp đầy. Nếu như suốt khóa học này chúng ta bàn về "làm cho hệ thống chạy đúng và nhanh", thì SecOps trả lời câu hỏi khác: "làm sao biết được ai đang chạm vào hệ thống, họ có quyền không, và nếu có kẻ xấu thì mình phát hiện và phản ứng thế nào?".
Với một kỹ sư vận hành hay SRE, SecOps không phải là "việc của team bảo mật". Trong hầu hết công ty công nghệ Việt Nam quy mô vừa (startup 30–200 người), không có team security riêng — chính bạn, người cầm quyền truy cập vào infrastructure, mới là tuyến phòng thủ đầu tiên. Bài này giúp bạn nắm bốn trụ cột thực chiến của SecOps ở góc độ vận hành: quản lý danh tính và quyền (IAM), audit logging, giám sát tập trung qua SIEM, và quy trình phản ứng khi có sự cố an ninh. Đây là kiến thức tối thiểu để bạn không trở thành mắt xích yếu nhất.
Khái niệm cốt lõi
SecOps là gì và phạm vi của nó
SecOps là sự giao thoa giữa vận hành (Operations) và bảo mật (Security): áp dụng tư duy vận hành — giám sát liên tục, cảnh báo, quy trình phản ứng, tự động hóa — vào các vấn đề an ninh. Thay vì coi bảo mật là một dự án "làm một lần rồi thôi", SecOps coi nó là một hoạt động vận hành thường trực, giống như bạn giám sát latency hay error rate hằng ngày.
Trong bài này chúng ta tập trung bốn mảng cốt lõi mà một người làm Ops chắc chắn phải chạm tới:
- Vulnerability management — quản lý lỗ hổng và vá lỗi. Mảng này đã được bàn kỹ ở Bài 34, nên ở đây ta chỉ nhắc rằng nó là một phần của SecOps: bạn cần biết hệ thống của mình có lỗ hổng nào, mức độ nghiêm trọng ra sao, và vá theo thứ tự ưu tiên.
- Identity & Access Management (IAM) — ai được truy cập cái gì, ở mức nào.
- Audit logging — ghi lại mọi hành động nhạy cảm để có thể truy vết về sau.
- Security Incident Response — phản ứng khi có sự cố an ninh.
Identity & Access Management (IAM)
IAM là nền tảng của mọi thứ. Nếu quản lý quyền lỏng lẻo, mọi lớp bảo vệ khác đều vô nghĩa. Có vài nguyên tắc cốt lõi bạn phải khắc cốt ghi tâm:
Least Privilege (Đặc quyền tối thiểu). Mỗi người, mỗi service chỉ được cấp đúng quyền cần thiết để làm việc, không hơn. Một developer cần đọc log production thì cấp quyền read-only vào log, đừng cấp luôn quyền admin toàn bộ AWS account cho tiện.
Role-Based Access Control (RBAC). Thay vì gán quyền cho từng cá nhân, bạn định nghĩa các "vai trò" (developer, on-call engineer, DBA...) và gán quyền cho vai trò. Khi có người mới vào, chỉ cần gán vai trò; khi họ nghỉ, gỡ vai trò. Điều này giúp quản lý quyền của 100 người trở nên khả thi.
Multi-Factor Authentication (MFA). Mật khẩu bị lộ là chuyện thường xuyên. MFA (thêm một lớp xác thực thứ hai như OTP, app authenticator, khóa cứng) khiến một mật khẩu rò rỉ không đủ để kẻ tấn công vào được. Với các tài khoản có quyền production, MFA là bắt buộc, không phải tùy chọn.
Deprovisioning kịp thời. Khi một nhân viên nghỉ việc, quyền truy cập của họ phải bị thu hồi trong vòng vài giờ, không phải vài tuần. "Ghost account" — tài khoản của người đã nghỉ nhưng vẫn còn quyền — là một trong những lỗ hổng phổ biến và nguy hiểm nhất.
Một khái niệm nâng cao đáng nhắc là Just-In-Time (JIT) access: thay vì cấp quyền production vĩnh viễn, kỹ sư chỉ được cấp quyền tạm thời (ví dụ 4 tiếng) khi thực sự cần xử lý sự cố, và quyền tự hết hạn sau đó.
Audit Logging
Audit log là "hộp đen" của hệ thống — ghi lại ai đã làm gì, khi nào, từ đâu. Khác với application log (ghi hành vi ứng dụng) hay access log (ghi request), audit log tập trung vào các hành động nhạy cảm về mặt an ninh: đăng nhập, thay đổi quyền, truy cập dữ liệu nhạy cảm, thay đổi cấu hình hạ tầng.
Một audit log entry tốt cần trả lời được: chủ thể (user/service nào), hành động (tạo/sửa/xóa/đọc gì), đối tượng (tài nguyên nào), thời điểm chính xác, và ngữ cảnh (IP, session, kết quả thành công hay thất bại). Các cloud provider đều cung cấp sẵn: AWS có CloudTrail, GCP có Cloud Audit Logs, Azure có Activity Log.
Nguyên tắc sống còn: audit log phải bất biến (immutable) và tách khỏi hệ thống được giám sát. Nếu kẻ tấn công chiếm được server và có thể xóa luôn log trên chính server đó, thì log vô dụng. Vì vậy audit log thường được đẩy sang một nơi lưu trữ riêng, chỉ ghi thêm (append-only), người vận hành thông thường không có quyền xóa.
SIEM — Security Information and Event Management
Bạn có audit log từ AWS, log từ ứng dụng, log từ firewall, log từ database... rải rác khắp nơi. SIEM là hệ thống thu gom tất cả về một chỗ, chuẩn hóa, tương quan (correlate) và cảnh báo khi phát hiện dấu hiệu tấn công.
Điểm mấu chốt của SIEM là correlation — khả năng nối các sự kiện rời rạc thành một câu chuyện. Ví dụ: một lần đăng nhập thất bại thì bình thường. Nhưng 500 lần đăng nhập thất bại từ cùng một IP trong 2 phút, rồi một lần thành công, rồi ngay sau đó là một truy vấn database lấy toàn bộ bảng khách hàng — SIEM sẽ nối ba sự kiện này lại và bắn cảnh báo "nghi ngờ brute-force dẫn đến data exfiltration".
Các công cụ SIEM phổ biến gồm Splunk (mạnh nhưng đắt), Elastic Security (dựa trên ELK, phổ biến ở Việt Nam vì có bản mã nguồn mở), Wazuh (mã nguồn mở, nhiều startup Việt dùng), và các dịch vụ cloud như AWS Security Hub / GuardDuty, Microsoft Sentinel. Với đội nhỏ, đừng nghĩ ngay đến Splunk đắt tiền — Wazuh hoặc Elastic Security đủ để bắt đầu.
Security Incident Response
Đây là quy trình phản ứng khi nghi ngờ hoặc xác nhận có sự cố an ninh. Nó khác với incident response thông thường (Bài 5) ở một điểm cực kỳ quan trọng: trong sự cố an ninh, việc bảo toàn bằng chứng (evidence preservation) đôi khi quan trọng hơn việc khôi phục nhanh. Nếu bạn reboot server bị hack ngay lập tức, bạn có thể xóa mất dấu vết của kẻ tấn công trong RAM.
Khung chuẩn thường dùng là của NIST, gồm sáu giai đoạn: Preparation (chuẩn bị) → Identification (phát hiện) → Containment (cô lập) → Eradication (loại bỏ) → Recovery (khôi phục) → Lessons Learned (rút kinh nghiệm).
Tình huống thực tế
Tình huống 1: Ghost account tại một fintech Việt Nam
Một công ty fintech ở TP.HCM (khoảng 150 nhân sự) trải qua một đợt audit bảo mật để chuẩn bị gọi vốn vòng Series A. Đội tư vấn phát hiện có 23 tài khoản AWS IAM đang active nhưng thuộc về nhân viên đã nghỉ việc — người rời công ty sớm nhất đã nghỉ từ 11 tháng trước. Tệ hơn, 3 trong số đó có quyền AdministratorAccess, và 1 tài khoản có access key được commit nhầm vào một repo GitLab nội bộ mà hàng chục người có thể đọc.
Diễn giải: Vấn đề gốc là không có quy trình deprovisioning gắn với offboarding. Khi HR cho nhân viên nghỉ, không ai báo cho team infra để thu hồi quyền cloud. Quyền cứ thế tồn đọng. Access key trong repo là một "quả bom hẹn giờ" — chỉ cần repo bị lộ hoặc một cựu nhân viên bất mãn, kẻ xấu có toàn quyền phá hoặc rút dữ liệu.
Bài học: Deprovisioning phải được tự động hóa và gắn chặt với quy trình HR. Công ty này sau đó tích hợp offboarding của HR với việc vô hiệu hóa IAM tự động, bật CloudTrail để giám sát, và dùng công cụ quét secret (như gitleaks) trong CI để chặn access key lọt vào code. Họ cũng chuyển sang dùng IAM Role tạm thời thay vì access key vĩnh viễn.
Tình huống 2: SIEM bắt được exfiltration tại một sàn TMĐT Đông Nam Á
Một sàn thương mại điện tử quy mô khu vực (giả định, tương tự các sàn lớn ở Đông Nam Á) đã triển khai Elastic Security làm SIEM. Một đêm, hệ thống bắn cảnh báo: một service account vốn chỉ dùng để chạy báo cáo hằng đêm đột nhiên thực hiện hàng loạt truy vấn SELECT * trên bảng users và bảng payment_methods, với lưu lượng dữ liệu ra ngoài tăng gấp 40 lần bình thường, vào lúc 3 giờ sáng.
SIEM correlate ba tín hiệu: (1) service account đăng nhập từ một IP chưa từng thấy, (2) pattern truy vấn khác hẳn baseline, (3) volume dữ liệu bất thường. Cảnh báo được đẩy vào kênh on-call security trong vòng 90 giây. Đội trực cô lập service account đó ngay, thu hồi credential, và phát hiện nguyên nhân: credential của service account bị hard-code trong một microservice cũ và đã rò rỉ.
Diễn giải: Điểm hay ở đây là SIEM không chỉ log — nó thiết lập baseline hành vi bình thường và cảnh báo khi có bất thường. Nếu chỉ có log thô, không ai đọc log lúc 3 giờ sáng để phát hiện. Correlation và alerting tự động là thứ biến hàng terabyte log thành hành động kịp thời.
Bài học: Đầu tư SIEM với alert dựa trên hành vi (behavioral baseline), đừng chỉ dựa vào rule cứng. Và quan trọng không kém: service account cũng cần được quản lý danh tính chặt chẽ như tài khoản người — thậm chí chặt hơn, vì chúng thường có quyền lớn và ít bị soi.
Tình huống 3: Xử lý sự cố sai cách — reboot xóa mất bằng chứng
Một startup SaaS ở Hà Nội nhận cảnh báo có process lạ chạy trên một EC2 instance production, nghi bị đào tiền ảo (cryptomining). Kỹ sư trực, theo phản xạ vận hành thông thường, lập tức reboot instance để "làm sạch". Sau reboot, process lạ biến mất, hệ thống trở lại bình thường, ai cũng thở phào.
Nhưng ba tuần sau, sự cố tái diễn. Lần này không ai biết kẻ tấn công đã vào bằng đường nào, vì toàn bộ bằng chứng — process đang chạy, kết nối mạng active, file tạm trong RAM — đã bị xóa sạch trong lần reboot đầu tiên. Họ phải điều tra lại từ đầu, tốn nhiều ngày.
Diễn giải: Trong sự cố an ninh, phản xạ "khôi phục nhanh" của Ops lại phản tác dụng. Đúng ra, kỹ sư nên cô lập (containment) instance khỏi mạng — tách nó ra khỏi security group, chặn traffic — nhưng giữ nguyên trạng thái để chụp snapshot ổ đĩa và dump memory phục vụ điều tra (forensics), rồi mới xử lý.
Bài học: Security incident response cần một runbook riêng, nhấn mạnh "cô lập nhưng bảo toàn bằng chứng" trước khi "khôi phục". Đây là điểm khác biệt cốt lõi so với incident vận hành thông thường.
Hướng dẫn từng bước
Đây là lộ trình xây dựng nền tảng SecOps cơ bản cho một đội Ops chưa có gì:
- Kiểm kê danh tính (IAM audit). Liệt kê toàn bộ tài khoản người và service account có quyền vào hệ thống nhạy cảm. Loại bỏ ngay các ghost account. Ghi rõ mỗi tài khoản có quyền gì và tại sao.
- Áp dụng least privilege và bật MFA. Rà soát từng quyền, gỡ bỏ quyền thừa. Bắt buộc MFA cho mọi tài khoản chạm được production. Chuyển các vai trò lặp lại sang RBAC.
- Bật audit logging ở mọi tầng. Bật CloudTrail (hoặc tương đương), database audit log, và log đăng nhập của các hệ thống quan trọng. Đảm bảo log được đẩy sang nơi lưu trữ tách biệt, append-only, mà người vận hành thường không xóa được.
- Tập trung log về một SIEM. Bắt đầu với công cụ vừa túi tiền (Wazuh hoặc Elastic Security nếu đội nhỏ). Đưa các nguồn log quan trọng nhất vào trước: audit log, log đăng nhập, log truy cập database.
- Thiết lập một số cảnh báo cốt lõi. Đừng cố cảnh báo mọi thứ. Bắt đầu với vài use case rõ ràng: đăng nhập bất thường (địa điểm/thời gian lạ), leo thang quyền (privilege escalation), truy cập khối lượng dữ liệu lớn bất thường, thay đổi cấu hình IAM.
- Viết runbook cho security incident. Nêu rõ các bước: xác nhận → cô lập (giữ bằng chứng) → điều tra → loại bỏ → khôi phục → postmortem. Ghi rõ ai được quyết định cô lập một hệ thống production.
- Diễn tập. Chạy một buổi mô phỏng sự cố an ninh (ví dụ credential rò rỉ) để đội quen với runbook trước khi sự cố thật xảy ra.
Lỗi thường gặp & mẹo
Lỗi: Cấp quyền quá rộng "cho tiện". Rất nhiều đội cấp AdministratorAccess cho tất cả developer vì "phân quyền chi tiết mất thời gian". Đây là con dao hai lưỡi — một tài khoản bị lộ là toàn bộ hệ thống thất thủ. Mẹo: bắt đầu từ quyền tối thiểu và mở rộng khi thực sự cần, đừng làm ngược lại.
Lỗi: Bỏ quên service account. Người ta chăm chút MFA cho tài khoản người nhưng lại để service account dùng credential vĩnh viễn, hard-code trong code. Service account thường là mục tiêu ngon nhất. Mẹo: dùng secret manager (đã bàn ở Bài 33), xoay credential định kỳ, và giám sát hành vi service account trong SIEM.
Lỗi: Có log nhưng không ai đọc. Bật audit log rồi để đó, không có alert, không có ai review. Log chỉ hữu ích khi biến thành cảnh báo hoặc được điều tra. Mẹo: thà có ít nguồn log nhưng được giám sát chủ động, còn hơn thu gom mọi thứ rồi bỏ mặc.
Lỗi: Coi mọi cảnh báo an ninh như incident vận hành. Reboot ngay, xóa ngay, khôi phục ngay — và xóa mất bằng chứng. Mẹo: security incident có runbook riêng, ưu tiên cô lập và bảo toàn bằng chứng.
Lỗi: Alert fatigue. Cấu hình SIEM cảnh báo quá nhiều thứ, đội trực bị "ngập" và bắt đầu bỏ qua cảnh báo — đến khi cảnh báo thật thì cũng bị lờ đi. Mẹo: tinh chỉnh rule liên tục, ưu tiên chất lượng hơn số lượng cảnh báo (tinh thần này giống hệt Bài 18 về signal vs noise).
Mẹo bổ sung: Áp dụng nguyên tắc defense in depth — nhiều lớp phòng thủ. Ngay cả khi IAM bị thủng, audit log và SIEM vẫn giúp bạn phát hiện; ngay cả khi phát hiện muộn, forensics tốt vẫn giúp bạn hiểu và vá.
Bài tập thực hành
- IAM audit thực tế. Chọn một hệ thống bạn đang quản lý (cloud account, database, hoặc server). Liệt kê toàn bộ tài khoản có quyền truy cập. Với mỗi tài khoản, trả lời: chủ nó là ai (còn làm việc không), có quyền gì, quyền đó có thừa không. Đánh dấu những tài khoản cần thu hồi hoặc thu hẹp quyền.
- Thiết kế 3 cảnh báo SIEM. Cho hệ thống của bạn, viết ra ba use case cảnh báo an ninh cụ thể (dạng "nếu X xảy ra thì cảnh báo"). Với mỗi cái, xác định cần nguồn log nào và điều kiện kích hoạt. Ví dụ: "Nếu một tài khoản admin đăng nhập từ IP ngoài Việt Nam ngoài giờ hành chính thì cảnh báo".
- Viết mini-runbook security incident. Giả định kịch bản: một access key production bị phát hiện trong một public repo GitHub. Viết runbook 6 bước (theo khung NIST) mà đội bạn sẽ thực hiện, ghi rõ ai làm gì và thứ tự ưu tiên — đặc biệt là bước cô lập và bảo toàn bằng chứng.
- Phân tích tình huống. Đọc lại Tình huống 3 (reboot xóa bằng chứng). Nếu bạn là kỹ sư trực đêm đó, hãy viết ra chuỗi hành động đúng mà bạn sẽ làm, giải thích tại sao mỗi bước quan trọng.
Tóm tắt
SecOps đưa tư duy vận hành — giám sát liên tục, cảnh báo, quy trình, tự động hóa — vào bài toán an ninh, và với đội Ops quy mô vừa, chính bạn là tuyến phòng thủ đầu tiên. Bốn trụ cột cần nắm là: IAM (least privilege, RBAC, MFA, deprovisioning kịp thời), audit logging (bất biến, tách biệt, ghi ai-làm-gì-khi-nào-từ-đâu), SIEM (thu gom, tương quan, cảnh báo dựa trên baseline hành vi), và security incident response (cô lập và bảo toàn bằng chứng trước khi khôi phục — điểm khác biệt cốt lõi so với incident vận hành thường).
Ba tình huống thực tế cho thấy bài học xương máu: ghost account là lỗ hổng âm thầm nhưng chết người; SIEM với correlation biến biển log thành hành động kịp thời; và phản xạ "khôi phục nhanh" của Ops có thể phá hỏng cuộc điều tra an ninh. Hãy bắt đầu nhỏ — kiểm kê danh tính, bật MFA, tập trung vài nguồn log quan trọng, viết một runbook — rồi mở rộng dần. An ninh không phải đích đến, mà là một hoạt động vận hành thường trực.