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ị và phần mềm cần mua. Điểm xuất phát đúng là phạm vi hệ thống, dữ liệu, người dùng, mức độ ảnh hưởng, yêu cầu đã được xác định trong hồ sơ và khoảng trống của hệ thống đang vận hành.
Một kiến trúc tốt cần kết nối 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à những ví dụ về đầu tư rời rạc.
Tóm tắt: Hệ thống cấp độ 2 và cấp độ 3 cần được triển khai theo phương án ATTT của từng hệ thống, không theo một bộ sản phẩm cố định. Các lớp thường cần rà gồm quản trị, danh tính, mạng, máy chủ, ứng dụng/API, dữ liệu, backup, log, giám sát, ứng cứu và phục hồi. Mức độ kiểm soát cụ thể phải đối chiếu Nghị định 85/2016/NĐ-CP, Thông tư 12/2022/TT-BTTTT và hồ sơ đã được phê duyệt hoặc đang đề xuất.
Phạm vi search task của bài này: URL này sở hữu intent giải pháp/kiến trúc và các lớp kiểm soát cần triển khai cho hệ thống cấp độ 2–3. Nếu nhu cầu là trình tự triển khai bảo mật tổng quát từ khảo sát đến bàn giao, xem quy trình triển khai bảo mật hệ thống từ A–Z. Nếu chỉ cần hiểu một kiểm soát riêng, dùng các owner chuyên biệt như MFA là gì, WAF là gì hoặc checklist bảo mật website có cổng web công.

Căn cứ nào quyết định giải pháp bảo mật?
Nghị định 85/2016/NĐ-CP quy định khung 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 chi tiết việc xác định hệ thống, thuyết minh cấp độ và yêu cầu bảo đảm an toàn. Hai văn bản này là căn cứ nền; phương án triển khai phải tiếp tục bám vào phạm vi và hồ sơ của hệ thống cụ thể.
| Đầu vào | Câu hỏi cần trả lời | Ảnh hưởng đến giải pháp |
|---|---|---|
| Phạm vi | Hệ thống gồm những thành phần 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 xử lý, lưu, truyền và xuất? | 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à kiểm soát truy cập |
| 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 không? | Tránh mua trùng và xác định khoảng trống |
| Hồ sơ | Phương án ATTT đã mô tả gì? | Gắn triển khai với nội dung cần chứng minh |
Nếu chưa xác định được cấp độ hoặc phạm vi, nên xử lý phần này trước. Xem hướng dẫn xác định cấp độ an toàn thông tin và hồ sơ đề xuất cấp độ là gì.
Không nên so sánh cấp độ 2 và cấp độ 3 chỉ bằng số lượng công cụ
Cấp độ 3 không đơn giản là “cấp độ 2 cộng thêm vài thiết bị”. Yêu cầu phải được đối chiếu theo tiêu chí và phụ lục áp dụng, sau đó ánh xạ với hệ thống thật. 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, người dùng và hạ tầng khác nhau.
| Không nên dùng làm kết luận | Nên dùng để thiết kế |
|---|---|
| Cấp độ 2 chỉ cần firewall và antivirus | Đối chiếu đầy đủ yêu cầu quản lý và kỹ thuật của hệ thống |
| Cấp độ 3 bắt buộc mua một bộ sản phẩm cố định | Xác định kiểm soát, năng lực vận hành và bằng chứng cần có |
| Nhiều license đồng nghĩa bảo mật tốt | Đánh giá khả năng phòng ngừa, phát hiện, phản ứng và phục hồi |
| Có hồ sơ nghĩa là đã triển khai xong | Kiểm tra cấu hình, quy trình, log và kết quả vận hành |
| Mọi hệ thống cùng cấp độ dùng cùng kiến trúc | Thiết kế theo ranh giới, dữ liệu và phụ thuộc thực tế |
Vì vậy, bảng so sánh có trách nhiệm nên tập trung vào mức trưởng thành cần đạt, không khẳng định một danh sách thiết bị là bắt buộc cho mọi trường hợp.
Khung phòng thủ nhiều lớp cho hệ thống
NIST định nghĩa defense in depth là chiến lược kết hợp con người, công nghệ và vận hành qua nhiều lớp bảo vệ. Nguyên tắc này phù hợp khi thiết kế hệ thống theo cấp độ vì một kiểm soát đơn lẻ không thể ngăn mọi kiểu sự cố.

| Lớp | Mục tiêu | Kiểm soát cần rà |
|---|---|---|
| Quản trị | Xác định trách nhiệm, chính sách và chu kỳ kiểm tra | Phân công, quản lý thay đổi, quản lý rủi ro và báo cáo |
| 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 và thu hồi quyền |
| Mạng | Giới hạn bề mặt tấn công và khả năng lan truyền | Phân vùng, firewall/ACL, VPN, cổng mở và quản trị từ xa |
| Máy chủ/endpoint | Giảm lỗi cấu hình và thành phần dễ bị khai thác | Hardening, bản vá, EDR/antimalware khi phù hợp và tài khoản đặc quyền |
| Ứng dụng/API | Giảm lỗi xác thực, phân quyền và xử lý dữ liệu | Secure coding, kiểm thử, session, upload, API và WAF |
| Dữ liệu | Bảo vệ bí mật, toàn vẹn và khả năng phục hồi | Phân loại, quyền, mã hóa phù hợp, backup và kiểm soát xuất dữ liệu |
| Giám sát | Phát hiện sớm và có dữ liệu điều tra | Log, cảnh báo, dashboard, quy tắc phát hiện và người trực |
| Ứ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ạ khẩn cấp, restore test và diễn tập |
Lớp mạng và truy cập quản trị
Mục tiêu không phải là tạo càng nhiều VLAN càng tốt, mà là giới hạn đường truy cập theo chức năng và giảm khả năng một tài khoản hoặc máy chủ bị chiếm có thể đi ngang toàn hệ thống.
- Lập danh mục cổng và dịch vụ đang mở.
- Tách vùng public, ứng dụng, database, quản trị, backup và giám sát khi kiến trúc cần.
- Giới hạn SSH, RDP, console và giao diện quản trị bằng VPN, IP hoặc cơ chế phù hợp.
- Dùng tài khoản quản trị riêng, bật MFA và ghi log.
- Rà rule firewall/ACL theo nguyên tắc quyền tối thiểu.
- Kiểm soát kết nối của nhà cung cấp và đặt thời hạn cho quyền tạm thời.
Một rule “allow any” có tác động cao cần được xử lý sớm hơn nhiều hạng mục trang trí. Không dùng số lượng phát hiện làm thước đo; cần xếp ưu tiên theo khả năng và mức độ ảnh hưởng.
Lớp ứng dụng, API, WAF và chống DDoS
Với website, portal hoặc API công khai, lớp bảo vệ biên có thể gồm CDN, WAF, rate limit, chống bot và dịch vụ chống DDoS phù hợp. Đây là lớp hỗ trợ giảm request bất thường và tăng khả năng quan sát, không thay thế sửa lỗi code hoặc kiểm soát phân quyền trong backend.
- Kiểm thử xác thực, phân quyền, session, upload file và các endpoint quan trọng.
- Áp dụng rate limit theo hành trình như login, reset password, tìm kiếm và API.
- Triển khai WAF theo giai đoạn log, tuning rồi mới tăng mức block.
- Giới hạn truy cập trực tiếp tới origin khi kiến trúc cho phép.
- Quản lý khóa API, token, secret và quyền của tích hợp bên thứ ba.
- Theo dõi lỗi 4xx, 5xx, traffic tăng bất thường và false positive.
Xem thêm WAF là gì và giới hạn của WAF. Khi đã xác định đúng nhu cầu, có thể tham khảo dịch vụ triển khai WAF và chống DDoS.
Lớp máy chủ, endpoint và nền tảng
- Kiểm kê hệ điều hành, runtime, framework, CMS, plugin và thư viện.
- Rà thành phần hết hỗ trợ hoặc có lỗ hổng nghiêm trọng.
- Tắt dịch vụ và tài khoản không dùng.
- Giới hạn quyền file, thư mục, service account và secret.
- Thiết lập quy trình vá, kiểm thử và hoàn tác.
- Dùng EDR hoặc giải pháp bảo vệ endpoint khi phù hợp với kiến trúc và năng lực vận hành.
- Giám sát CPU, RAM, disk, process và thay đổi file quan trọng.
Không nên mua giải pháp endpoint nếu không có người đọc cảnh báo, quy trình cô lập và cách phối hợp với đội quản trị. Công cụ chỉ tạo dữ liệu; năng lực phản ứng mới quyết định hiệu quả.
Lớp danh tính và tài khoản đặc quyền
Nhiều sự cố bắt đầu từ mật khẩu bị lộ hoặc quyền không được thu hồi. Vì vậy, danh tính thường là hạng mục có tác động cao và có thể triển khai sớm.
- Bật MFA cho email, cloud, DNS, hosting, VPN, CMS, Git và tài khoản quản trị.
- Không dùng chung tài khoản admin khi cần truy vết cá nhân.
- Tách tài khoản dùng hằng ngày khỏi tài khoản đặc quyền.
- Rà quyền theo vai trò và thời hạn.
- Thu hồi quyền ngay khi nhân sự, đối tác hoặc nhà cung cấp thay đổi.
- Ghi log các thao tác cấp quyền và hoạt động quản trị quan trọng.
Lớp dữ liệu, backup và phục hồi
Backup chỉ có giá trị khi có thể khôi phục trong điều kiện sự cố. Một bản sao nằm cùng máy chủ chính hoặc dùng cùng tài khoản quản trị có thể bị ảnh hưởng cùng lúc với dữ liệu gốc.
| Hạng mục | Câu hỏi cần trả lời |
|---|---|
| Phân loại dữ liệu | Dữ liệu nào quan trọng, nhạy cảm hoặc cần giữ lâu? |
| Quyền truy cập | Ai được xem, sửa, xóa hoặc xuất dữ liệu? |
| Mã hóa | Dữ liệu nào cần bảo vệ khi truyền hoặc khi lưu? |
| Backup | Sao lưu cái gì, tần suất nào, giữ ở đâu và bằng tài khoản nào? |
| Restore | Lần thử khôi phục gần nhất là khi nào và kết quả ra sao? |
| RTO/RPO | Mức gián đoạn và mất dữ liệu chấp nhận được là bao nhiêu? |
RTO và RPO phải được xác định cùng chủ nghiệp vụ, không chỉ do đội kỹ thuật tự chọn. Hạ tầng dự phòng cần được kiểm thử; có máy chủ thứ hai nhưng không có quy trình failover chưa phải là khả năng phục hồi đã được chứng minh.
Log, giám sát và ứng cứu sự cố
Không phải mọi hệ thống đều cần cùng một sản phẩm SIEM hoặc mô hình SOC. Điều bắt buộc về mặt vận hành là xác định sự kiện nào cần ghi, lưu bao lâu, ai nhận cảnh báo và hành động nào phải thực hiện khi có dấu hiệu bất thường.
- Log đăng nhập, thay đổi quyền và thao tác quản trị.
- Log firewall, WAF, VPN, server, ứng dụng, API và database theo nhu cầu.
- Cảnh báo đăng nhập bất thường, lỗi tăng đột biến, thay đổi file hoặc đầy dung lượng.
- Quy trình phân loại mức độ và chuyển cấp xử lý.
- Runbook cho chiếm tài khoản, mã độc, rò rỉ dữ liệu, DDoS và gián đoạn dịch vụ.
- Cơ chế bảo toàn bằng chứng và báo cáo sau sự cố.
Nếu hệ thống đang có dấu hiệu bị xâm nhập, ưu tiên xử lý sự cố trước khi tiếp tục dự án. Xem quy trình xử lý website bị hack hoặc tấn công.
Cách ưu tiên roadmap cho giải pháp cấp độ 2–3
Roadmap của trang này dùng để ưu tiên các lớp kiểm soát theo gap và rủi ro của hệ thống đã xác định, không thay thế quy trình triển khai bảo mật tổng quát. Nếu cần thứ tự công việc từ khảo sát, thiết kế, triển khai đến bàn giao cho mọi hệ thống, xem Security Process A–Z.
Lộ trình không nên bắt đầu bằng việc làm hết mọi hạng mục cùng lúc. Hãy khóa rủi ro có tác động cao, tạo khả năng quan sát và phục hồi, sau đó nâng mức trưởng thành. Thời gian cụ thể phải được ước tính sau khảo sát.
| Giai đoạn | Ưu tiên | Đầu ra |
|---|---|---|
| Khảo sát | Phạm vi, tài sản, dữ liệu, quyền và hiện trạng | Sơ đồ, danh mục và bảng khoảng trống |
| Khóa rủi ro cao | Tài khoản, cổng mở, bản vá nghiêm trọng, backup và sự cố đang diễn ra | Rủi ro cấp bách được giảm hoặc cô lập |
| Thiết kế | Vùng mạng, quyền, WAF, log, backup và phục hồi | Kiến trúc mục tiêu và kế hoạch thay đổi |
| Triển khai | Cấu hình, kiểm thử và tích hợp cảnh báo | Bằng chứng và kết quả nghiệm thu |
| Vận hành | Rà log, bản vá, quyền, backup và diễn tập | Lịch, người phụ trách và báo cáo định kỳ |
Khung 30, 60 hoặc 90 ngày chỉ có thể dùng để tổ chức dự án sau khi đã biết phạm vi. Không nên cam kết một mốc cố định cho mọi hệ thống cấp độ 2 hoặc cấp độ 3.
Checklist xác định phạm vi dịch vụ
- Hồ sơ cấp độ đã có và còn khớp hiện trạng không?
- Hệ thống có bao nhiêu domain, API, máy chủ, database và môi trường?
- Có bao nhiêu tài khoản đặc quyền và bên thứ ba đang truy cập?
- Biện pháp nào đã triển khai nhưng thiếu bằng chứng?
- Khoảng trống nào có tác động cao nhất?
- Cần tư vấn kiến trúc, cấu hình, cung cấp giải pháp hay vận hành dài hạn?
- Ai sẽ tiếp nhận log, cảnh báo và bàn giao?
- Tiêu chí nghiệm thu và phạm vi không bao gồm là gì?
Không dùng ngưỡng “ba hoặc bốn dấu hiệu” để quyết định thuê dịch vụ. Một rủi ro nghiêm trọng đã có thể cần xử lý ngay; nhiều vấn đề nhỏ có thể được xử lý theo kế hoạch nội bộ.
Khi nào nên thuê đơn vị triển khai?
Nên cân nhắc hỗ trợ khi hệ thống có nhiều thành phần hoặc nhà cung cấp, đội nội bộ thiếu năng lực chuyên sâu, hồ sơ không khớp hiện trạng, cần triển khai đồng thời nhiều lớp hoặc cần một bên chịu trách nhiệm điều phối và bàn giao.
Phạm vi cần ghi rõ: khảo sát, thiết kế, cấu hình, license, kiểm thử, tài liệu, đào tạo, vận hành, SLA, số vòng tuning và các hạng mục không bao gồm. Không nên chấp nhận báo giá chỉ có tên sản phẩm mà không nêu đầu ra.
Nếu nhu cầu là triển khai giải pháp kỹ thuật theo phạm vi đã xác định, WebsiteHCM có thể hỗ trợ khảo sát, xây lộ trình, hardening, WAF, chống DDoS, backup, log, giám sát và bàn giao theo thỏa thuận. Khi cần phần hồ sơ, xem riêng dịch vụ lập hồ sơ đề xuất cấp độ ATTT.
FAQ
Cấp độ 2 có bắt buộc dùng WAF không?
Không thể kết luận chỉ từ cấp độ. WAF phù hợp khi có website, portal hoặc API công khai và phải được đánh giá trong phương án tổng thể.
Cấp độ 3 có bắt buộc triển khai SOC 24/7 không?
Không nên khẳng định một mô hình vận hành cố định khi chưa đối chiếu yêu cầu và hệ thống cụ thể. Cần xác định năng lực giám sát, thời gian phản ứng và bằng chứng cần có.
Có thể chỉ mua thiết bị mà không tư vấn kiến trúc không?
Có thể mua, nhưng rủi ro cấu hình sai hoặc đầu tư không đúng điểm yếu rất cao. Nên xác định phạm vi, luồng dữ liệu và tiêu chí nghiệm thu trước.
Có hồ sơ rồi có cần rà kỹ thuật không?
Có. Hồ sơ cần được đối chiếu với cấu hình và vận hành để xác định biện pháp đã triển khai, thiếu bằng chứng hoặc còn khoảng trống.
Triển khai mất bao lâu?
Phụ thuộc số lượng tài sản, hiện trạng, phạm vi thay đổi, kiểm thử, mua sắm và năng lực phối hợp. Chỉ nên chốt timeline sau khảo sát.
Kết luận
Giải pháp bảo mật hệ thống cấp độ 2 và cấp độ 3 là bài toán kiến trúc và vận hành, không phải danh sách sản phẩm. Cần đi từ phạm vi, dữ liệu, rủi ro và hồ sơ tới các lớp danh tính, mạng, máy chủ, ứng dụng, dữ liệu, log, ứng cứu và phục hồi.
Một giải pháp có chất lượng phải nêu rõ kiểm soát nào giải quyết rủi ro nào, ai vận hành, bằng chứng nào dùng để nghiệm thu và việc gì còn phải duy trì sau bàn giao. Đây là cơ sở để tránh mua sắm rời rạc và giảm khoảng cách giữa hồ sơ với hệ thống thật.
Nguồn tham khảo
Đ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ả.

