Bài 76. Quản lý danh tính (3): mô hình điều khiển truy cập: RBAC, DAC, MAC, rule-based

Khóa học CompTIA Security+ SY0-801 · Phần 4: Vận hành bảo mật · Bài 76 · 🎯 Objective 4.5 · ⏱️ Đọc khoảng 17 phút · 🧪 Không cần lab · 📝 5 câu bài tập cuối bài

🎯 Mục tiêu bài học

• Phân biệt năm mô hình DAC, MAC, RBAC, ABAC, rule-based: ai quyết định quyền truy cập và dựa vào đâu.
• Hiểu các nguyên tắc nền tảng: đặc quyền tối thiểu, need-to-know, phân tách nhiệm vụ, deny mặc định.
• Biết ACL và cách quyền được gán, kế thừa và rà soát.
• Chọn mô hình phù hợp cho từng tình huống thường gặp trong đề.

📎 Vị trí trong đề thi: tiếp nối Bài 75 (xác thực), bài này lo phân quyền (authorization), chữ A thứ hai trong AAA ở Bài 2. Nó dùng lại phân loại tài sản và dữ liệu (Bài 66, Bài 50) và ACL của firewall (Bài 60). Bài 77 sẽ lo quyền đặc biệt (PAM).

💡 Liên hệ thực tế: ai được mở sổ doanh thu?

Sổ doanh thu của cửa hàng chị Lan nằm trong một thư mục chung. Mới đầu, mỗi người tự chia sẻ cho ai họ muốn: chị Lan chia cho kế toán, kế toán lại chia tiếp cho một cộng tác viên, người này chia tiếp cho bạn của mình. Chẳng ai còn biết ai đang đọc được gì. Đây là tình huống minh họa, không phải vụ việc có thật.

Nam hỏi một câu đơn giản: ai có quyền quyết định ai được xem? Mỗi cách trả lời tương ứng một mô hình: để chủ sở hữu tự quyết (DAC), để hệ thống quyết theo nhãn mật (MAC), để quyền đi theo vai trò (RBAC), hay theo thuộc tính và ngữ cảnh (ABAC). Với cửa hàng nhỏ, Nam chọn RBAC: có vai trò Chủ cửa hàng, Kế toán, Thu ngân; ai giữ vai trò nào nhận đúng quyền đó.

🧭 Hình 76a. Mô hình càng chặt thì càng khó quản lý: MAC chặt nhất, DAC linh hoạt nhất.

📘 Kiến thức cốt lõi

🧱 Nguyên tắc nền tảng

🧰 Năm mô hình điều khiển truy cập

DAC (Discretionary Access Control), điều khiển truy cập tùy quyền chủ sở hữu

• Chủ sở hữu tài nguyên tự quyết định ai được truy cập (thường qua ACL gắn trên tài nguyên).
• Ví dụ: quyền tệp trên Windows (NTFS) và Linux; chia sẻ tài liệu trên dịch vụ đám mây.
• Ưu: linh hoạt, dễ dùng. Nhược: khó kiểm soát tập trung; người dùng có thể chia sẻ quá mức hoặc chuyển quyền cho người không đáng; mã độc chạy bằng quyền của người dùng cũng kế thừa quyền của người đó.

MAC (Mandatory Access Control), điều khiển truy cập bắt buộc

• Hệ thống (chính sách trung tâm) quyết định, người dùng và cả chủ sở hữu không tự đổi được. Dựa trên nhãn phân loại của tài nguyên (ví dụ Công khai, Mật, Tối mật) và mức được phép (clearance) của người dùng.
• Người dùng chỉ truy cập nếu mức của họ đủ cao và thỏa need-to-know.
• Ví dụ: môi trường quân sự, chính phủ; trên hệ điều hành có SELinux.
• Ưu: chặt chẽ, ít sai sót do con người. Nhược: cứng nhắc, tốn công thiết lập và duy trì nhãn.

RBAC (Role-Based Access Control), điều khiển truy cập theo vai trò

• Quyền gán cho vai trò; người dùng nhận quyền thông qua vai trò của họ (Kế toán, Thu ngân, Quản trị).
• Đổi việc chỉ cần đổi vai trò, không sửa quyền từng người; dễ rà soát và áp đặc quyền tối thiểu.
• Ưu: quản lý tập trung, mở rộng tốt, hợp tổ chức có cơ cấu vai trò rõ. Nhược: vai trò thiết kế kém sẽ phình thành quá nhiều vai trò (role explosion) hoặc vai trò quá rộng.

ABAC (Attribute-Based Access Control), điều khiển truy cập theo thuộc tính

• Quyết định dựa trên thuộc tính của người dùng (phòng ban, chức danh), tài nguyên (nhãn, chủ sở hữu) và ngữ cảnh (giờ, vị trí, trạng thái thiết bị), được đánh giá bởi chính sách.
• Ví dụ: "Nhân viên phòng tài chính chỉ đọc báo cáo trong giờ làm và từ thiết bị đã đăng ký."
• Ưu: rất chi tiết, linh hoạt, theo ngữ cảnh, hợp zero trust. Nhược: phức tạp thiết kế, khó kiểm thử và giải thích.

Rule-based access control (điều khiển theo quy tắc)

• Áp quy tắc cố định cho mọi người bất kể vai trò, thường do hệ thống thực thi: danh sách ACL của firewall, giới hạn theo giờ, chặn theo địa chỉ IP.
• Đừng nhầm với role-based: role-based dựa trên vai trò của người dùng, rule-based dựa trên quy tắc áp cho tất cả hoặc theo điều kiện.

⚠️ Trong các tài liệu, chữ viết tắt RBAC đôi khi dùng cho role-based và đôi khi cho rule-based. Đọc ngữ cảnh: "vai trò, chức danh" là role-based; "quy tắc, điều kiện, giờ, IP" là rule-based.

🔍 So sánh nhanh

👥 RBAC trong thực tế

👥 Hình 76b. Đổi việc chỉ cần đổi vai trò, không phải sửa quyền từng người.

Cách thiết kế tốt:

• Bắt đầu từ công việc thực tế (ai làm gì), nhóm thành vai trò gọn, đặt tên rõ.
• Mỗi vai trò chỉ chứa quyền cần thiết; tránh vai trò "mọi thứ".
• Tách vai trò xung đột (người tạo thanh toán không được giữ vai trò duyệt thanh toán) để thực thi phân tách nhiệm vụ.
• Rà soát định kỳ vai trò và thành viên (attestation, Bài 74), gỡ vai trò không còn dùng.
• Kết hợp nhóm (group) để gán vai trò nhanh cho nhiều người.

📋 ACL và kế thừa quyền

ACL (Access Control List) là danh sách ai (hoặc cái gì) được làm gì trên một tài nguyên. Trên tệp, ACL liệt kê người dùng và quyền (đọc, ghi, thực thi, xóa). Trên mạng, ACL của firewall liệt kê nguồn, đích, cổng, hành động cho phép hoặc chặn (Bài 60) và có deny mặc định ở cuối.

Kế thừa quyền (inheritance): thư mục con thường nhận quyền từ thư mục cha. Tiện nhưng cũng là nguồn quyền thừa ngoài ý muốn; cần xem quyền hiệu lực (effective permissions), là kết quả sau khi gộp quyền cá nhân, nhóm và kế thừa, để biết ai thực sự truy cập được gì.

⏱️ Các điều kiện bổ sung

Ngoài mô hình chính, thường thêm ràng buộc: theo giờ (time-of-day), theo vị trí địa lý hoặc địa chỉ mạng, theo trạng thái thiết bị (đã vá, có EDR), hết hạn tự động (tài khoản tạm), giới hạn đồng thời. Đây là các điều kiện thuộc rule-based hoặc ABAC và là nền tảng của chính sách truy cập có điều kiện.

🎯 Mẹo làm bài: "Chủ sở hữu tự quyết định ai được truy cập" → DAC. "Hệ thống quyết định, theo nhãn và mức được phép, người dùng không đổi được" → MAC. "Quyền gán theo vai trò, chức danh" → RBAC (role-based). "Dựa trên thuộc tính người, tài nguyên và ngữ cảnh" → ABAC. "Quy tắc áp cho mọi người, ACL, giờ, IP" → rule-based. "Quân sự, chính phủ, nhãn Mật và Tối mật" → MAC. "Chỉ cấp vừa đủ quyền" → đặc quyền tối thiểu. "Một việc cần hai người" → phân tách nhiệm vụ. "Không có quy tắc cho phép thì chặn" → implicit deny. "Quyền cứ chồng chất khi đổi việc" → privilege creep (Bài 74). "Quá nhiều vai trò, khó quản lý" → role explosion.

🧠 Áp vào câu chuyện của Nam

📖 Thuật ngữ cần nhớ

📌 Tóm tắt nhanh

• Câu hỏi then chốt: ai quyết định quyền truy cập, và dựa vào đâu.
• DAC (chủ sở hữu), MAC (hệ thống, nhãn), RBAC (vai trò), ABAC (thuộc tính, ngữ cảnh), rule-based (quy tắc như ACL).
• Nguyên tắc nền tảng: đặc quyền tối thiểu, need-to-know, phân tách nhiệm vụ, implicit deny.
• RBAC quản lý tốt khi thiết kế vai trò gọn; ABAC linh hoạt nhất; MAC chặt nhất; DAC dễ nhất nhưng khó kiểm soát.
• Kiểm tra quyền hiệu lực, rà soát định kỳ và gỡ quyền thừa.

💬 Hỏi & Đáp nhanh

❓ Nên chọn mô hình nào cho doanh nghiệp nhỏ? Thường RBAC là điểm khởi đầu hợp lý: dễ hiểu, dễ rà soát. Có thể bổ sung điều kiện (giờ, thiết bị) khi cần, và dùng DAC có kiểm soát cho thư mục cộng tác thông thường.

❓ MAC có dùng được ngoài quân sự không? Có, ở các môi trường cần ép chính sách chặt, như hệ thống nhạy cảm cao, hoặc qua tính năng trên hệ điều hành (như SELinux). Tuy nhiên chi phí thiết lập và duy trì khiến nhiều tổ chức dùng RBAC hoặc ABAC thay thế.

❓ ABAC khác RBAC ở điểm nào quan trọng nhất? RBAC hỏi "bạn là ai (vai trò gì)", còn ABAC hỏi thêm "bạn đang ở hoàn cảnh nào": thiết bị, giờ, vị trí, độ nhạy của dữ liệu. ABAC cho quyết định chi tiết hơn nhưng phức tạp hơn.

📝 Bài tập đánh giá

Tự chọn đáp án cho từng câu, rồi đối chiếu với phần đáp án ở cuối bài.

Câu 1. Trong mô hình nào, chủ sở hữu tài nguyên tự quyết định ai được truy cập?

• A. MAC
• B. DAC
• C. RBAC
• D. ABAC

Câu 2. Một cơ quan dùng nhãn Mật và Tối mật, người dùng không thể tự thay đổi quyền truy cập. Đây là mô hình nào?

• A. MAC
• B. DAC
• C. Rule-based
• D. Federation

Câu 3. Nhân viên kế toán được cấp quyền thông qua vai trò Kế toán; khi chuyển phòng chỉ cần đổi vai trò. Đây là mô hình nào?

• A. DAC
• B. MAC
• C. Rule-based
• D. RBAC (role-based)

Câu 4. Chính sách "chỉ cho đọc báo cáo trong giờ làm việc và từ thiết bị đã đăng ký" dựa trên thuộc tính và ngữ cảnh. Mô hình nào phù hợp nhất?

• A. DAC
• B. MAC
• C. ABAC
• D. Implicit deny

Câu 5. Người tạo lệnh thanh toán không được phép là người duyệt lệnh đó. Đây là nguyên tắc nào?

• A. Need-to-know
• B. Phân tách nhiệm vụ (separation of duties)
• C. Implicit deny
• D. Single sign-on

👉 Đáp án

Câu 1: B — DAC để chủ sở hữu tự quyết định quyền truy cập.

Câu 2: A — MAC dựa trên nhãn phân loại và mức được phép; người dùng không tự đổi được.

Câu 3: D — RBAC gán quyền theo vai trò; đổi việc chỉ cần đổi vai trò.

Câu 4: C — ABAC quyết định dựa trên thuộc tính của người dùng, tài nguyên và ngữ cảnh.

Câu 5: B — Phân tách nhiệm vụ yêu cầu nhiều người cho một việc nhạy cảm để giảm gian lận.

📚 Bài viết thuộc khóa học CompTIA Security+ của VNExperts

🧭 Điều hướng