Nhiều người tìm “mẫu hồ sơ đề xuất cấp độ” với kỳ vọng có một file chung để điền và nộp. Trên thực tế, bộ hồ sơ phải phản ánh đúng phạm vi, dữ liệu, kiến trúc, đơn vị vận hành và phương án bảo đảm an toàn thông tin của từng hệ thống. Một biểu mẫu có sẵn chỉ giúp tổ chức bố cục, không thể thay thế khảo sát và thuyết minh.
Tóm tắt: Bài viết này cung cấp khung tham khảo để chuẩn bị bộ hồ sơ, không phải file biểu mẫu chính thức duy nhất. Các nhóm tài liệu nền thường gồm mô tả tổng quan, tài liệu thiết kế hoặc tài liệu tương đương, thuyết minh đề xuất cấp độ, phương án bảo đảm ATTT và phụ lục bằng chứng. Thành phần, thủ tục và mẫu văn bản phải được đối chiếu với quy định và trường hợp cụ thể.
Căn cứ nền gồm Nghị định 85/2016/NĐ-CP và Thông tư 12/2022/TT-BTTTT. Nếu chưa rõ khái niệm và vai trò của từng tài liệu, nên đọc trước bài hồ sơ đề xuất cấp độ là gì.
Khung hồ sơ này dùng để làm gì?
Khung tham khảo phù hợp để doanh nghiệp hoặc đơn vị vận hành kiểm tra mình đã có tài liệu nào, đang thiếu đầu vào nào và nên sắp xếp nội dung theo thứ tự nào. Nó không thay thế việc xác định đúng chủ thể, thẩm quyền, cấp độ và thủ tục áp dụng.
Cách dùng phù hợp là lấy khung làm checklist, sau đó gắn mỗi mục với nguồn dữ liệu, người xác nhận, trạng thái và bằng chứng. Không nên sao chép nội dung của hệ thống khác vì tên gọi giống nhau.
| Có thể dùng khung để | Không nên dùng khung để |
|---|---|
| Kiểm kê thành phần tài liệu | Tự kết luận hồ sơ đã hợp lệ hoặc được phê duyệt |
| Phân công người cung cấp đầu vào | Sao chép cấp độ của hệ thống khác |
| Chuẩn hóa mục lục và thuật ngữ | Mô tả kiểm soát chưa triển khai |
| Rà sự thống nhất giữa hồ sơ và hiện trạng | Thay thế ý kiến chuyên môn hoặc thủ tục chính thức |
Cấu trúc tham khảo của bộ hồ sơ đề xuất cấp độ
| Nhóm tài liệu | Nội dung chính | Điểm cần kiểm tra |
|---|---|---|
| Văn bản hành chính theo trường hợp | Tên hệ thống, đơn vị liên quan, cấp độ đề xuất và danh mục hồ sơ | Đúng loại văn bản, thẩm quyền, người ký và nơi nhận |
| Mô tả tổng quan | Mục tiêu, chức năng, phạm vi, người dùng, dữ liệu và mô hình vận hành | Không viết như phần giới thiệu thương hiệu |
| Thiết kế hoặc tài liệu tương đương | Sơ đồ, máy chủ, ứng dụng, database, API, mạng và kết nối bên thứ ba | Phản ánh đúng bản production hiện tại |
| Thuyết minh đề xuất cấp độ | Căn cứ từ phạm vi, chức năng, dữ liệu và mức độ ảnh hưởng | Không chọn cấp độ trước rồi viết ngược lập luận |
| Phương án bảo đảm ATTT | Biện pháp quản lý và kỹ thuật theo cấp độ đề xuất | Phân biệt đã có, đang làm và còn thiếu |
| Phụ lục và bằng chứng | Danh mục tài sản, quyền, cấu hình, log, backup, báo cáo và kế hoạch khắc phục | Không để lộ mật khẩu, token hoặc dữ liệu không cần thiết |
Với hệ thống đề xuất cấp độ cao hơn, có thể có thêm yêu cầu và ý kiến chuyên môn tương ứng. Không nên dùng bảng trên thay cho việc đọc đúng quy định áp dụng.
Mục lục tham khảo để tổ chức nội dung
Mục lục dưới đây giúp nhóm kỹ thuật, vận hành và quản lý phối hợp trên cùng một nguồn dữ liệu. Có thể điều chỉnh theo hệ thống và yêu cầu của đơn vị có thẩm quyền.
| Phần | Nội dung | Đầu ra mong muốn |
|---|---|---|
| 1. Thông tin chung | Tên, chủ quản, vận hành, địa chỉ và phạm vi | Một tên và một ranh giới thống nhất |
| 2. Tổng quan | Mục tiêu, chức năng, người dùng, dữ liệu và quy mô | Người đọc hiểu hệ thống phục vụ việc gì |
| 3. Kiến trúc kỹ thuật | Máy chủ, ứng dụng, database, API, mạng và dịch vụ thuê ngoài | Sơ đồ và danh mục hiện trạng |
| 4. Thuyết minh cấp độ | Căn cứ pháp lý, tác động và cấp độ đề xuất | Lập luận có thể kiểm tra |
| 5. Phương án ATTT | Quản lý, tài khoản, mạng, máy chủ, ứng dụng, dữ liệu, log và phục hồi | Mapping yêu cầu với biện pháp |
| 6. Khoảng trống và kế hoạch | Hạng mục thiếu, ưu tiên, người phụ trách và thời hạn | Kế hoạch có thể theo dõi |
| 7. Phụ lục | Sơ đồ, tài sản, quyền, checklist và bằng chứng | Tài liệu hỗ trợ không mâu thuẫn với phần chính |
Khung văn bản đề nghị hoặc tờ trình
Không nên gọi một khung chung là “mẫu chính thức” nếu chưa xác nhận trường hợp sử dụng. Tùy quy trình, đơn vị có thể cần văn bản đề nghị thẩm định, đề nghị phê duyệt, xin ý kiến chuyên môn, tờ trình hoặc quyết định. Trước khi soạn, cần chốt người ký, nơi nhận và danh mục tài liệu kèm theo.
- Tên cơ quan hoặc tổ chức lập văn bản.
- Số, địa danh và ngày ban hành.
- Cơ quan hoặc đơn vị nhận văn bản.
- Căn cứ liên quan tới thủ tục cụ thể.
- Tên chính thức của hệ thống.
- Đơn vị chủ quản và đơn vị vận hành.
- Cấp độ đề xuất.
- Danh mục tài liệu gửi kèm.
- Thông tin người liên hệ.
- Người ký, chức danh và hình thức xác nhận phù hợp.
Phần hành chính không bù được việc thiếu mô tả, sơ đồ hoặc phương án ATTT. Vì vậy, chỉ hoàn thiện văn bản này sau khi tên hệ thống, phạm vi và cấp độ sơ bộ đã được thống nhất.
Khung tài liệu mô tả tổng quan
Tài liệu tổng quan phải giúp người rà soát hiểu hệ thống đang phục vụ nghiệp vụ nào, cho ai và xử lý dữ liệu gì. Tránh dùng các câu quảng bá không cung cấp thông tin kỹ thuật hoặc quản lý.
| Mục | Câu hỏi cần trả lời |
|---|---|
| Tên và mục tiêu | Hệ thống tên gì và giải quyết nghiệp vụ nào? |
| Chức năng | Người dùng có thể đăng nhập, gửi, sửa, duyệt, xuất hoặc tích hợp dữ liệu ra sao? |
| Người dùng | Nhóm nội bộ, khách hàng, đối tác hoặc công chúng nào truy cập? |
| Dữ liệu | Dữ liệu nào được thu thập, lưu, truyền và xóa? |
| Môi trường | Hệ thống chạy trên cloud, hosting, VPS hay on-premise? |
| Bên thứ ba | Phụ thuộc DNS, CDN, email, thanh toán, SMS, API hoặc backup nào? |
| Phạm vi ngoài | Thành phần liên quan nào không thuộc bộ hồ sơ này? |
Nếu tài liệu gốc không còn, cần dựng lại hiện trạng từ DNS, hosting, cloud, source code, tài khoản và phỏng vấn người vận hành. Không dùng tài liệu cũ chỉ vì có sẵn.
Khung tài liệu thiết kế hoặc tài liệu tương đương
Tài liệu cần thể hiện ranh giới, luồng kết nối và thành phần kỹ thuật. Độ chi tiết phải đủ để đối chiếu phương án bảo vệ nhưng không công khai bí mật kỹ thuật ngoài phạm vi cần thiết.
| Nhóm | Nội dung nên có |
|---|---|
| Sơ đồ tổng thể | Người dùng, Internet, lớp bảo vệ, web/app, database, storage, backup và API |
| Mạng và truy cập | Vùng public/private, firewall, VPN, quản trị và kết nối bên ngoài |
| Máy chủ | Vai trò, nền tảng, vị trí và người vận hành |
| Ứng dụng | CMS/framework, module, service và thành phần phụ thuộc quan trọng |
| Database | Loại dữ liệu, nơi lưu, tài khoản, quyền và cơ chế sao lưu |
| Danh tính | Nhóm tài khoản, vai trò, quyền cao và MFA |
| Dịch vụ ngoài | DNS, CDN, email, thanh toán, SMS, cloud storage và API |
| Kiểm soát hiện có | Firewall/WAF, TLS, bản vá, backup, log, monitoring và ứng cứu |
Với cổng web công khai, đối chiếu thêm checklist bảo mật website có cổng web công để không bỏ sót tài khoản, API, upload, WAF, log và backup.
Checklist thuyết minh đề xuất cấp độ
| Nội dung | Câu hỏi cần trả lời |
|---|---|
| Phạm vi | Hồ sơ bao gồm và không bao gồm thành phần nào? |
| Chức năng | Hệ thống phục vụ hoạt động gì và mức độ phụ thuộc ra sao? |
| Người dùng | Ai truy cập, từ đâu và với quyền gì? |
| Dữ liệu | Dữ liệu nào được xử lý và mức độ quan trọng thế nào? |
| Bí mật | Nếu dữ liệu bị lộ, đối tượng và phạm vi ảnh hưởng là gì? |
| Toàn vẹn | Nếu dữ liệu bị sửa hoặc giả mạo, hậu quả là gì? |
| Sẵn sàng | Nếu hệ thống ngừng hoạt động, nghiệp vụ nào bị ảnh hưởng? |
| Cấp độ đề xuất | Căn cứ nào kết nối các yếu tố trên với cấp độ? |
Nếu hệ thống dự kiến cấp độ 2, dùng checklist ATTT cấp độ 2 để rà khoảng trống; không dùng checklist như chứng nhận tự động.
Khung phương án bảo đảm an toàn thông tin
Phương án cần phân biệt yêu cầu quản lý và kỹ thuật, sau đó ánh xạ mỗi biện pháp với thành phần, người phụ trách, trạng thái và bằng chứng. Không nên chỉ liệt kê tên sản phẩm.
| Nhóm | Nội dung cần mô tả | Bằng chứng |
|---|---|---|
| Tổ chức và trách nhiệm | Chủ quản, vận hành, giám sát, phê duyệt và ứng cứu | Phân công hoặc ma trận trách nhiệm |
| Tài khoản và MFA | Cấp, thu hồi, quyền tối thiểu và xác thực mạnh | Danh sách quyền và cấu hình |
| Mạng | Phân vùng, cổng mở, VPN, firewall và truy cập quản trị | Sơ đồ và rule đã rà |
| Máy chủ | Hardening, bản vá, dịch vụ thừa và tài khoản đặc quyền | Checklist và lịch cập nhật |
| Ứng dụng/API | Xác thực, phân quyền, input, upload, session và kiểm thử | Báo cáo và ticket khắc phục |
| Dữ liệu | Phân loại, quyền, mã hóa phù hợp và kiểm soát xuất | Ma trận dữ liệu và log |
| Backup | Tần suất, vị trí, thời gian giữ và thử khôi phục | Log và kết quả restore test |
| Log/giám sát | Nguồn log, cảnh báo, thời gian lưu và người xử lý | Dashboard, ticket hoặc báo cáo |
| Ứng cứu | Tiếp nhận, cô lập, điều tra, khôi phục và báo cáo | Runbook và biên bản diễn tập/sự cố |
Nếu website hoặc API cần lớp lọc trước ứng dụng, có thể đánh giá WAF và chống DDoS. Đây chỉ là một lớp trong phương án tổng thể.
Phụ lục và bằng chứng nên chuẩn bị
- Danh sách domain, máy chủ, ứng dụng, database và dịch vụ bên thứ ba.
- Sơ đồ kiến trúc và kết nối.
- Ma trận vai trò và quyền truy cập.
- Chính sách tài khoản, mật khẩu và MFA.
- Danh sách nguồn log và thời gian lưu.
- Lịch backup và kết quả thử khôi phục.
- Báo cáo rà soát hoặc kiểm thử và tình trạng khắc phục.
- Kế hoạch xử lý hạng mục còn thiếu.
- Quy trình ứng cứu và danh sách liên hệ.
Bằng chứng phải được làm sạch dữ liệu nhạy cảm trước khi chia sẻ. Không đưa mật khẩu, token, khóa riêng hoặc dữ liệu cá nhân không cần thiết vào phụ lục.
Lỗi thường gặp khi dùng mẫu
| Lỗi | Hậu quả | Cách xử lý |
|---|---|---|
| Copy hồ sơ khác | Sai phạm vi, dữ liệu và cấp độ | Khảo sát hệ thống thật trước |
| Chỉ hoàn thiện văn bản hành chính | Thiếu nội dung cốt lõi | Bổ sung mô tả, thiết kế, thuyết minh và phương án |
| Dùng sơ đồ cũ | Không thấy thành phần và rủi ro hiện tại | Dựng lại và xác nhận phiên bản |
| Viết biện pháp chung chung | Không kiểm chứng được | Gắn kiểm soát với thành phần, người và bằng chứng |
| Không ghi khoảng trống | Tạo cảm giác an toàn giả | Phân biệt trạng thái và lập kế hoạch |
| Không cập nhật sau thay đổi | Hồ sơ nhanh lỗi thời | Đặt chu kỳ rà và trigger cập nhật |
Khi nào nên tự làm và khi nào nên thuê hỗ trợ?
Có thể tự làm khi phạm vi nhỏ, tài liệu cập nhật và đội nội bộ hiểu cả nghiệp vụ lẫn kỹ thuật. Nên cân nhắc hỗ trợ khi hệ thống có nhiều nhà cung cấp, không còn thiết kế gốc, có deadline, từng bị góp ý hoặc cần xử lý đồng thời khoảng trống bảo mật.
Nếu cần hỗ trợ về khảo sát, phạm vi, quy trình và đầu ra, xem dịch vụ lập hồ sơ đề xuất cấp độ ATTT. Chỉ khi đã cần dự toán ngân sách, mới nên chuyển sang bảng giá theo phạm vi.
FAQ
Đây có phải mẫu chính thức để tải và nộp không?
Không. Đây là khung tham khảo nội dung. Đơn vị phải xác nhận biểu mẫu, thủ tục và thẩm quyền áp dụng cho trường hợp cụ thể.
Có thể chỉ điền mẫu mà không khảo sát không?
Không nên. Hồ sơ phải phản ánh phạm vi, dữ liệu, kiến trúc và biện pháp thật; các thông tin này chỉ có sau khi rà hiện trạng.
Không còn tài liệu thiết kế gốc thì làm sao?
Có thể dựng tài liệu hiện trạng tương đương từ sơ đồ, tài sản, cấu hình, tài khoản, kết nối và xác nhận của người vận hành.
Phụ lục có bắt buộc giống nhau cho mọi hệ thống không?
Không. Phụ lục cần đủ để hỗ trợ nội dung và chứng minh phương án; số lượng phụ thuộc hệ thống, cấp độ và yêu cầu áp dụng.
Khi nào phải cập nhật hồ sơ?
Cần rà lại khi phạm vi, chức năng, dữ liệu, kiến trúc, đơn vị vận hành hoặc mức độ ảnh hưởng thay đổi và theo chu kỳ quản lý được quy định.
Kết luận
Mẫu hồ sơ đề xuất cấp độ nên được hiểu là khung tổ chức tài liệu, không phải file điền sẵn có thể dùng cho mọi hệ thống. Một bộ hồ sơ có giá trị phải dùng nguồn dữ liệu thống nhất, giải thích được cấp độ và gắn phương án ATTT với hiện trạng cùng bằng chứng.
Hãy bắt đầu bằng khảo sát, khoanh phạm vi và xác định dữ liệu. Sau đó mới dùng khung để soạn tài liệu, rà chéo và hoàn thiện theo đúng thủ tục. Cách làm này giảm việc sửa lại và tránh tạo một bộ hồ sơ đẹp nhưng không phản ánh hệ thống đang vận hành.
Nguồn chính thức
Đ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ả.
