TÀI LIỆU THIẾT KẾ KỸ THUẬT: PBAC SECURITY FRAMEWORK (V2.0)¶
1. Bối cảnh và Mục tiêu (Background & Objectives)¶
1.1 Vấn đề của hệ thống hiện tại (RBAC cũ)¶
Hệ thống Datadict ban đầu được xây dựng dựa trên mô hình phân quyền theo vai trò truyền thống (RBAC - Role-Based Access Control). Ví dụ: Nếu là MANAGER thì được duyệt dữ liệu.
Tuy nhiên, khi hệ thống mở rộng, mô hình này bộc lộ nhiều điểm yếu nghiêm trọng:
1. Thiếu linh hoạt (Hardcode Logic): Việc kiểm tra quyền bị "đóng đinh" trong mã nguồn (code). Nếu muốn thay đổi quyền của MANAGER, lập trình viên phải tìm và sửa code ở hàng chục nơi khác nhau.
2. Rủi ro rò rỉ dữ liệu (IDOR Risk): Hệ thống trước đây dựa vào việc lập trình viên tự nhớ viết code lọc dữ liệu theo đơn vị (Org Unit). Nếu một lập trình viên quên viết dòng code lọc này, người dùng ở Sở A có thể xem được dữ liệu của Sở B.
3. Quản lý vai trò kiêm nhiệm khó khăn: Khi một cán bộ vừa làm Chuyên viên ở Phòng A, vừa làm Quản lý ở Phòng B, hệ thống cũ rất khó nhận biết họ đang thực hiện thao tác với "chiếc mũ" nào.
1.2 Mục tiêu của Kiến trúc PBAC V2.0¶
Để giải quyết triệt để các vấn đề trên, chúng ta chuyển đổi sang mô hình PBAC (Policy-Based Access Control) với các tiêu chí: * "Khai báo" thay vì "Lập trình" (Declarative vs Programmatic): Tách rời hoàn toàn các quy tắc bảo mật ra khỏi logic nghiệp vụ. Chuyển từ việc "Viết code để kiểm tra quyền" sang "Gắn nhãn (Annotation) yêu cầu quyền hạn". * Bảo vệ nhiều lớp (Defense in Depth): Đảm bảo dữ liệu an toàn ngay cả khi một lớp bảo vệ vô tình bị vượt qua. * Minh bạch hóa Phạm vi (Explicit Scope): Quyền hạn không chỉ là "Được làm gì" mà phải định nghĩa rõ "Được làm ở phạm vi nào".
2. Đánh giá và Phân tích Chuyên sâu (Architectural Analysis)¶
Quá trình nâng cấp kiến trúc được đúc kết từ tinh hoa của hai dự án lớn (Mobifone NOC và GreenCore SRS). Dưới đây là các quyết định phân tích cốt lõi:
Phân tích 1: Tại sao phải định nghĩa "Phạm vi" (Scope) một cách rõ ràng?¶
- Thiết kế cũ: Hệ thống kiểm tra "User có phải là MANAGER không?". Nếu đúng, hệ thống tự động ngầm hiểu "À, vậy thì chỉ cho xem dữ liệu của tổ chức đó".
- Thiết kế mới (Áp dụng): Quyền hạn được lưu trong CSDL dưới dạng
TÀI_NGUYÊN : HÀNH_ĐỘNG : PHẠM_VI(Ví dụ:DỮ_LIỆU_SỞ : DUYỆT : TỔ_CHỨC). - Lợi ích: Nếu ngày mai, Lãnh đạo yêu cầu
MANAGERđược quyền duyệt dữ liệu của toàn Thành phố, Quản trị viên chỉ cần vào màn hình Admin đổi Scope từTỔ_CHỨCthànhTOÀN_CẦU(ANY). Không cần sửa một dòng code nào.
Phân tích 2: Giải quyết bài toán kiêm nhiệm với "ActiveContext"¶
- Khi người dùng có nhiều vai trò, làm sao hệ thống biết họ đang hành động với tư cách nào?
- Giải pháp: Yêu cầu ứng dụng Web (Frontend) gửi kèm một thẻ định danh gọi là
ActiveContext(Ngữ cảnh làm việc) trong mỗi yêu cầu. Ví dụ: "Tôi là Nguyễn Văn A, đang thực hiện thao tác này với tư cách Quản lý của Phòng Hành chính". - Hệ thống sẽ kiểm tra chéo (Cross-check) xem anh A có thực sự là Quản lý Phòng Hành chính không. Nếu gian lận -> Khóa yêu cầu ngay lập tức (Fail-Fast).
Phân tích 3: Row-Level Security (Bảo vệ dữ liệu tận gốc)¶
- Thay vì lấy toàn bộ danh sách 10.000 bản ghi lên bộ nhớ rồi dùng code lọc ra 10 bản ghi thuộc Sở A (rất chậm và dễ sai sót).
- Kiến trúc mới sẽ tự động "cấy" thêm điều kiện lọc vào thẳng câu lệnh truy vấn cơ sở dữ liệu (SQL). Việc này được thực hiện tự động bởi bộ khung bảo mật, lập trình viên nghiệp vụ không cần quan tâm và cũng không thể vô tình can thiệp làm sai lệch.
3. Kiến trúc 6 Lớp Bảo mật (Defense in Depth)¶
Hệ thống áp dụng mô hình 6 lớp bảo vệ độc lập. Nếu Hacker (hoặc lỗi code) vượt qua được lớp ngoài, họ vẫn bị chặn lại ở các lớp trong.
| Lớp | Tên kỹ thuật | Mô tả thực tế | Trả lời câu hỏi |
|---|---|---|---|
| Lớp 1 | Authentication (Keycloak) | Trạm kiểm soát vé vào cổng hệ thống. | "Bạn là ai? Thẻ căn cước có hợp lệ không?" |
| Lớp 2 | Context Validation (Bộ lọc Ngữ cảnh) | Kiểm tra sự trung thực của chức danh khai báo. | "Bạn khai báo làm việc với tư cách Trưởng phòng X, điều đó có thật không?" |
| Lớp 3 | Action Authorization (Kiểm tra Hành động) | Đối chiếu sổ tay quyền hạn xem chức danh này có được làm việc này không. | "Bạn có được phép bấm nút 'Phê duyệt' không?" |
| Lớp 4 | Row-Level Security (Bảo mật dòng Dữ liệu) | Tự động giới hạn tầm nhìn, chỉ cấp phát những hồ sơ thuộc thẩm quyền. | "Bạn chỉ được nhìn thấy 5 hồ sơ của Phòng X, các hồ sơ khác sẽ tàng hình." |
| Lớp 5 | Business State Guard (Chốt chặn Trạng thái) | Kiểm tra tính hợp lệ về mặt quy trình nghiệp vụ. | "Hồ sơ này đã bị hủy, dù bạn có quyền 'Phê duyệt' thì cũng không được duyệt nữa." |
| Lớp 6 | Immutable Audit (Nhật ký Bất biến) | Camera giám sát ghi lại mọi hành động, không thể xóa sửa. | "Ai đã duyệt hồ sơ này, vào lúc nào, nội dung trước và sau khi duyệt là gì?" |
4. Các Thành phần Kỹ thuật Cốt lõi (For Developers)¶
4.1. CustomPermissionEvaluator (Bộ não điều phối)¶
Lớp đóng vai trò như một "Tổng đài viên". Khi nhận được yêu cầu kiểm tra quyền: 1. Quét danh sách quyền của người dùng. 2. Tìm Scope (Phạm vi) cao nhất mà người dùng được cấp. 3. Chuyển tiếp yêu cầu (Ủy quyền) cho "Chuyên gia" xử lý tài nguyên tương ứng (Chính là các Strategy).
4.2. ResourcePermissionStrategy (Chiến lược Tài nguyên)¶
Mỗi loại dữ liệu (Ví dụ: Dữ liệu Khám phá, Ma trận hiện trạng) sẽ có một "Chuyên gia" xử lý riêng (Strategy). Chuyên gia này có 3 nhiệm vụ:
1. hasActionPermission: Trả lời "Có/Không" cho yêu cầu thực hiện hành động.
2. buildSecurityPredicate: Tạo câu lệnh SQL tự động để lọc dữ liệu (Phục vụ Lớp 4).
3. isActionAllowedInCurrentState: Kiểm tra trạng thái hồ sơ (Phục vụ Lớp 5).
5. Phân bổ Vai trò (Role Mapping)¶
Áp dụng nguyên tắc Least Privilege (Chỉ cấp quyền tối thiểu cần thiết):
| Vai trò (Role) | Phạm vi mặc định (Scope) | Quyền hạn thực tế |
|---|---|---|
| ADMIN (Quản trị hệ thống) | ANY (Toàn cục) |
Được xem và thao tác trên dữ liệu của toàn Thành phố. Bỏ qua các rào cản về tổ chức. |
| MANAGER (Quản lý đơn vị) | ORGANIZATION (Tổ chức) |
Chỉ được xem và thao tác trên dữ liệu thuộc Tổ chức (Sở/Ban/Ngành) của chính mình. |
| APPROVER (Người phê duyệt) | ANY (Toàn cục) |
(Vai trò đặc thù) Có quyền phê duyệt các quy hoạch ảnh hưởng đến toàn Thành phố. |
| DATA_OWNER (Chủ quản dữ liệu) | OWN (Cá nhân/Sở hữu) |
Chỉ thao tác trên các điểm dữ liệu được giao phó đích danh. |
6. Lộ trình Triển khai Kỹ thuật (Execution Roadmap)¶
Lộ trình này chia nhỏ quá trình chuyển đổi để hạn chế rủi ro cho hệ thống đang vận hành:
- Giai đoạn 1: Đổ bê tông nền móng (Shared Module)
- Tạo bộ từ vựng chuẩn về Quyền hạn (Enums).
- Xây dựng bộ lọc Ngữ cảnh (ActiveContext).
- Xây dựng các lớp tiện ích tự động sinh câu lệnh SQL bảo mật.
- Giai đoạn 2: Lắp đặt "Bộ não" và "Chuyên gia" (Security Engine)
- Triển khai bộ điều phối trung tâm (
CustomPermissionEvaluator). - Triển khai các chiến lược chuyên biệt cho từng loại dữ liệu quan trọng (
Strategy).
- Triển khai bộ điều phối trung tâm (
- Giai đoạn 3: Dọn dẹp và Chuyển đổi (Refactor Controllers)
- Gỡ bỏ toàn bộ các đoạn code kiểm tra quyền thủ công cũ rải rác trong hệ thống.
- Gắn các biển báo (
@PreAuthorize) yêu cầu "Bộ não trung tâm" tự động kiểm tra quyền.
- Giai đoạn 4: Kiểm tra khả năng chịu tải và Bảo mật (Validation)
- Viết các kịch bản kiểm thử tự động giả lập Hacker cố tình vượt quyền, giả mạo Context để đảm bảo hệ thống phòng ngự thành công.