Giải pháp bảo mật cho hệ thống cấp độ 2 hoặc cấp độ 3 không nên bắt đầu bằng danh sách thiết bị cần mua. Điểm xuất phát phải là phạm vi hệ thống, dữ liệu, người dùng, mức độ ảnh hưởng, phương án an toàn thông tin và những khoảng trống đang tồn tại trong vận hành.
Một kiến trúc phù hợp phải nối được con người, quy trình và công nghệ. Có WAF nhưng không sửa lỗi ứng dụng, có backup nhưng chưa thử khôi phục, hoặc có SIEM nhưng không ai xử lý cảnh báo đều là đầu tư rời rạc, khó chứng minh hiệu quả.
Nguyên tắc: cấp độ không tự tạo ra một “combo sản phẩm” cố định. Các kiểm soát phải được ánh xạ từ yêu cầu áp dụng sang tài sản, cấu hình, quy trình, người vận hành và bằng chứng của hệ thống cụ thể.
Sáu đầu vào quyết định kiến trúc bảo mật
| Đầu vào | Câu hỏi cần trả lời | Ảnh hưởng đến giải pháp |
|---|---|---|
| Ranh giới | Hệ thống gồm website, API, máy chủ, database và dịch vụ nào? | Xác định tài sản, vùng mạng và điểm cần bảo vệ |
| Dữ liệu | Dữ liệu nào được lưu, truyền, xuất và chia sẻ? | Quyết định quyền, mã hóa, log và backup |
| Người dùng | Ai truy cập, từ đâu và với vai trò nào? | Quyết định MFA, phân quyền và truy cập từ xa |
| Tác động | Điều gì xảy ra khi bị lộ, sửa sai hoặc gián đoạn? | Quyết định mức ưu tiên, dự phòng và phục hồi |
| Hiện trạng | Kiểm soát nào đã có và có bằng chứng vận hành không? | Tránh mua trùng, nhận diện khoảng trống thật |
| Hồ sơ/phương án | Yêu cầu nào phải được triển khai và chứng minh? | Gắn công việc kỹ thuật với đầu ra nghiệm thu |
Nếu phạm vi hoặc cấp độ chưa được xác định, nên xử lý bước đó trước bằng hướng dẫn xác định cấp độ an toàn thông tin. Trang này tập trung vào cách chuyển đầu vào đã có thành kiến trúc và roadmap triển khai.
Cấp độ 2 và cấp độ 3 khác nhau ở mức kiểm soát, không phải số lượng tool
Không nên hiểu cấp độ 2 chỉ cần firewall và antivirus, còn cấp độ 3 là mua thêm SIEM, SOC hoặc nhiều license hơn. Hai hệ thống cùng cấp độ vẫn có thể cần kiến trúc khác nhau vì chức năng, dữ liệu, lưu lượng, phụ thuộc và năng lực vận hành khác nhau.
| Khía cạnh | Hệ thống cấp độ 2 | Khi yêu cầu và rủi ro tăng ở cấp độ 3 |
|---|---|---|
| Phạm vi kiểm soát | Đủ các lớp áp dụng và có người chịu trách nhiệm | Cần độ bao phủ, tính nhất quán và khả năng kiểm chứng cao hơn |
| Danh tính | Tài khoản cá nhân, quyền theo vai trò, MFA ở điểm quan trọng | Kiểm soát đặc quyền, truy cập từ xa và rà quyền chặt hơn |
| Phân vùng | Tách các vùng chính, giới hạn cổng và luồng quản trị | Kiểm soát luồng chi tiết hơn, giảm khả năng lan truyền |
| Giám sát | Log và cảnh báo cho sự kiện quan trọng | Tăng phạm vi log, tương quan, trực xử lý và bằng chứng phản ứng |
| Phục hồi | Backup, restore test và trách nhiệm rõ | Yêu cầu cao hơn về dự phòng, RTO/RPO và diễn tập |
| Vận hành | Quy trình cơ bản được ban hành và thực hiện | Tăng tần suất kiểm tra, diễn tập, báo cáo và cải tiến |
Bảng trên là khung định hướng, không thay thế việc đối chiếu yêu cầu pháp lý, phụ lục áp dụng và hồ sơ của từng hệ thống.
Kiến trúc phòng thủ nhiều lớp cần bao phủ những gì?
NIST mô tả defense in depth là chiến lược kết hợp con người, công nghệ và năng lực vận hành qua nhiều lớp bảo vệ. Cách tiếp cận này phù hợp với hệ thống theo cấp độ vì một kiểm soát đơn lẻ không thể ngăn, phát hiện và phục hồi trước mọi kiểu sự cố.
| Lớp | Mục tiêu | Kiểm soát cần rà | Bằng chứng |
|---|---|---|---|
| Quản trị | Rõ trách nhiệm và chu kỳ kiểm tra | Phân công, thay đổi, rủi ro, nhà cung cấp | Quyết định, quy trình, biên bản rà soát |
| Danh tính | Đúng người, đúng quyền, đúng thời gian | Tài khoản cá nhân, MFA, quyền tối thiểu, thu hồi | Danh sách quyền, log cấp/thu hồi, cấu hình MFA |
| Mạng | Giảm bề mặt tấn công và di chuyển ngang | Phân vùng, firewall/ACL, VPN, cổng quản trị | Sơ đồ, rule, kết quả kiểm tra cổng |
| Máy chủ/endpoint | Giảm lỗi cấu hình và thành phần dễ khai thác | Hardening, bản vá, đặc quyền, EDR khi phù hợp | Baseline cấu hình, phiên bản, ticket vá |
| Ứng dụng/API | Bảo vệ xác thực, phân quyền và dữ liệu | Secure coding, kiểm thử, WAF, rate limit | Báo cáo test, rule, log và ticket khắc phục |
| Dữ liệu | Bảo đảm bí mật, toàn vẹn và phục hồi | Phân loại, quyền, mã hóa phù hợp, backup | Ma trận quyền, cấu hình, kết quả restore |
| Giám sát | Phát hiện và điều tra kịp thời | Log, cảnh báo, dashboard, người trực | Sự kiện mẫu, ticket và báo cáo xử lý |
| Ứng cứu/phục hồi | Cô lập, khắc phục và khôi phục có kiểm soát | Runbook, danh bạ, RTO/RPO, diễn tập | Biên bản diễn tập và kết quả khôi phục |
Bốn nguyên tắc tránh đầu tư sai
- Không mua tool trước khi khóa use case: mỗi sản phẩm phải gắn với tài sản, rủi ro, người vận hành và đầu ra.
- Không dùng virtual patch thay bản vá vĩnh viễn: WAF có thể giảm rủi ro tạm thời nhưng lỗi ứng dụng vẫn cần được sửa.
- Không thu log khi không có hành động: phải xác định sự kiện cần cảnh báo, người nhận và thời gian phản hồi.
- Không xem backup là hoàn thành nếu chưa restore: khả năng phục hồi chỉ được chứng minh bằng kiểm thử.
Với hệ thống có website hoặc API công khai, xem riêng phạm vi triển khai WAF và chống DDoS. WAF chỉ là một lớp trong kiến trúc, không thay thế danh tính, mạng, bản vá, backup và ứng cứu.
Roadmap triển khai từ gap đến vận hành
| Giai đoạn | Công việc | Đầu ra cần nghiệm thu |
|---|---|---|
| 1. Khảo sát | Khóa phạm vi, tài sản, dữ liệu, quyền, kiến trúc và kiểm soát hiện có | Sơ đồ hiện trạng, inventory và ma trận khoảng trống |
| 2. Ưu tiên | Xếp hạng theo khả năng xảy ra, tác động và phụ thuộc | Backlog có owner, deadline, biện pháp tạm thời |
| 3. Thiết kế | Ánh xạ yêu cầu sang kiểm soát, cấu hình, quy trình và bằng chứng | Kiến trúc đích, phạm vi mua sắm và kế hoạch rollback |
| 4. Triển khai | Cấu hình, tích hợp, kiểm thử và xử lý chặn nhầm/lỗi tương thích | Kết quả test, cấu hình, ticket và rủi ro còn lại |
| 5. Bàn giao | Quyền, dashboard, runbook, đào tạo và kênh escalation | Tài liệu vận hành và biên bản tiếp nhận |
| 6. Duy trì | Rà quyền, vá, restore test, diễn tập và cập nhật kiến trúc | Báo cáo định kỳ và bằng chứng cải tiến |
Nếu cần trình tự triển khai tổng quát từ khảo sát đến bàn giao cho mọi hệ thống, xem quy trình triển khai bảo mật hệ thống từ A–Z. Trang này chỉ tập trung vào cách thiết kế và ưu tiên giải pháp cho hệ thống cấp độ 2–3.
Tiêu chí nghiệm thu giải pháp bảo mật
- Mỗi kiểm soát có tài sản áp dụng, owner và mục tiêu rõ ràng.
- Cấu hình thực tế khớp sơ đồ và tài liệu bàn giao.
- Luồng nghiệp vụ quan trọng vẫn hoạt động sau thay đổi.
- Rule, quyền và ngoại lệ có lý do, người phê duyệt và thời hạn rà soát.
- Log/cảnh báo đến đúng người và có ticket xử lý mẫu.
- Backup đã được thử khôi phục; RTO/RPO được chủ nghiệp vụ xác nhận khi áp dụng.
- Runbook ghi rõ cách cô lập, rollback, phục hồi và escalation.
- Các khoảng trống chưa đóng được ghi nhận cùng rủi ro và kế hoạch xử lý.
Không nghiệm thu chỉ bằng hóa đơn license, ảnh chụp dashboard hoặc việc thiết bị đã online. Giải pháp chỉ có giá trị khi kiểm soát hoạt động, tạo bằng chứng và đội vận hành biết phải làm gì khi có cảnh báo.
Thông tin cần chuẩn bị trước khi nhận phương án
- Phạm vi hệ thống, sơ đồ hiện trạng và danh mục tài sản.
- Cấp độ dự kiến/được phê duyệt và phương án ATTT liên quan.
- Loại dữ liệu, người dùng, kết nối bên thứ ba và truy cập từ xa.
- Cấu hình firewall, cloud, server, ứng dụng/API, backup và log hiện có.
- Sự cố, phát hiện kiểm thử hoặc yêu cầu khắc phục đang tồn tại.
- Năng lực đội vận hành, giờ hỗ trợ và hệ thống nhận cảnh báo.
- Ngân sách, thời gian, cửa sổ thay đổi và phụ thuộc nhà cung cấp.
Không gửi mật khẩu, private key hoặc dữ liệu nhạy cảm trong bước tư vấn ban đầu. Quyền truy cập phải được cấp theo phạm vi, thời hạn và nguyên tắc tối thiểu.
Câu hỏi thường gặp
Cấp độ 2 có bắt buộc dùng WAF không?
Không nên trả lời chỉ từ tên cấp độ. Cần đối chiếu yêu cầu áp dụng, kiến trúc và rủi ro của hệ thống. Với website/API công khai, WAF có thể là một kiểm soát phù hợp nhưng không thay thế sửa lỗi ứng dụng.
Cấp độ 3 có bắt buộc SOC 24/7 không?
Cần xác định yêu cầu giám sát, thời gian phản ứng, phạm vi hệ thống và mô hình vận hành phù hợp. Không nên mua một dịch vụ SOC chỉ để có tên sản phẩm nếu log, use case, escalation và trách nhiệm chưa được thiết kế.
Có hồ sơ rồi có cần rà kỹ thuật không?
Có. Hồ sơ mô tả phương án; rà kỹ thuật giúp xác minh biện pháp đã được triển khai đúng, còn hoạt động và có bằng chứng.
Nguồn tham khảo
- Nghị định 85/2016/NĐ-CP về bảo đảm an toàn hệ thống thông tin theo cấp độ
- Thông tư 12/2022/TT-BTTTT hướng dẫn Nghị định 85/2016/NĐ-CP
- NIST CSRC: Defense in Depth
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.