MAC (Mandatory Access Control): "Thiết Quân Luật" Phân Quyền - Khi Admin cũng không có quyền sinh sát

Chào anh em! Trong chuỗi bài mổ xẻ về System Architecture và phân quyền, chúng ta đã đi qua RBAC (vai trò), ABAC (thuộc tính) và DAC (tùy ý ). Hầu hết các dự án startup, outsource hay SaaS ngoài kia chỉ chần xài đến cỡ ABAC là đã "bá đạo" lắm rồi.

Nhưng giả sử ngày mai, sếp nhận được một dự án từ... Bộ Quốc Phòng, Cục Tình Báo, hoặc là một hệ thống lõi của Ngân Hàng Trung ưng. sếp bảo: "hệ thống này rò rỉ một byte dữ liệu là anh em mình đi tù. RBAC không đủ an toàn đâu!".

Lúc này, chào mừng anh em bước vào thế giới của MAC – Mandatory Access Control (Kiểm soát truy cập bắt buộc). Mô hình phân quyền độc tài, cứng nhắc và "hạng nặng" nhất thế giới phần mềm.

1. Bản Chất Của MAC Là Gì? Tại Sao Gọi Là "Độc Tài"?

Để hiểu MAC, anh em hãy nhớ lại Google Drive (mô hình DAC). Bạn tạo ra một file, bạn là Chủ sở hữu (Owner), bạn thích share cho ai thì share. Admin hệ thống can thiệp vào là vi phạm quyền riêng tư.

MAC thì ngược lại hoàn toàn! Trong MAC, khái niệm "chủ sở hữu" không có ý nghĩa gì cả. Hệ thống (System/OS) mới là kẻ nắm quyền sinh sát tối cao. Hoạt động của MAC dựa trên 2 yếu tố cốt lõi:

1. Nhãn bảo mật (Security Labels): Mọi dữ liệu (Resource/Object) khi sinh ra đều bị dán một cái nhãn cấp độ. Ví dụ Top Secret (Tuyệt mật), Secret (Mật), Confidential (Kín), Unclassified (Bình thường).
2. Mức độ giải mật (Clearance Levels): Mọi người dùng (User/Subject) đều được cấp một thẻ bài chứng nhận mức độ được phép tiếp cận.

Luật chơi thép: Hệ thống sẽ tự động đối chiếu Thẻ bài của User và Nhãn của Data. Khớp thì cho qua, không khớp thì cấm. Ngay cả khi bạn là người gõ ra cái file Top Secret đó, bạn cũng KHÔNG THỂ gửi nó cho thằng bạn cùng phòng có thẻ bài Secret. Hệ thống sẽ chặn đứng bạn lại!

2. Mô Hình Bell-LaPadula: Trái Tim Của MAC

Nói đến MAC thì không thể không nhắc đến mô hình toán học Bell-LaPadula – chuẩn mực bảo mật được Bộ Quốc phòng Mỹ thiết kế để chống rò rỉ thông tin. Nó hoạt động dựa trên 2 định lý kinh điển mà anh em Architect nào cũng phải thuộc lòng:

Định lý 1: Simple Security Property (No Read Up - Không đọc lên)

• Nghĩa là: User chỉ được phép đọc dữ liệu có cấp độ nhỏ hơn hoặc bằng cấp độ thẻ bài của mình
• Ví dụ: User cấp Secret được đọc file Secret và file Unclassified. Nhưng tuyệt đối mù màu trước file Top Secret. (Cái này quá hiển nhiên, giống RBAC)

*Định lý 2: The -Property (No Write Down - Không ghi xuống)

Đây mới là cái "ăn tiền" và tạo nên sự bá đạo của MAC!

Nghĩa là: User đang ở cấp độ cao, KHÔNG ĐƯỢC PHÉP ghi, copy hay sửa đổi dữ liệu ở cấp độ thấp hơn.

Tại sao lại có cái luật quái gở này? Hãy tưởng tượng: Một Tướng quân (cấp Top Secret) đang mở song song 2 cửa sổ: Một file kế hoạch tác chiến (Top Secret) và một email thông báo nội bộ (Unclassified). Nếu không có luật này, vị tướng có thể lỡ tay (hoặc bị dính mã độc Trojan) copy một đoạn text từ kế hoạch tác chiến, dán vào cái email Unclassified rồi gửi cho toàn quân. Thế là lộ bí mật quốc gia!

Với luật "No Write Down", hệ thống sẽ khóa chết hành vi này. Dữ liệu chỉ có thể đi ngang hoặc đi lên (No Read Up, No Write Down), không bao giờ có chuyện "chảy" ngược xuống cấp thấp.

3. Những "Nỗi Đau" Khi Triển Khai MAC Trong Thực Tế

Với 20 năm làm nghề, mình từng thấy vài team "ngáo" kiến trúc, nghe MAC bảo mật ngon quá lôi về áp dụng cho cái app quản lý nhân sự. Kết quả là... đập đi làm lại sau đúng 1 tháng. Dưới đây là những cái bẫy chết người:

Bẫy #1: Over-engineering (Dùng dao mổ trâu giết gà) MAC cực kỳ đắt đỏ để thiết lập và duy trì. Bạn không thể tự tạo nhãn bừa bãi. Phải có một hội đồng An ninh (Security Officer) ngồi định nghĩa từng nhãn, phê duyệt từng clearance cho user. Áp dụng MAC cho web bình thường chẳng khác nào bắt nhân viên đi qua cửa từ, quét võng mạc chỉ để vào phòng pha cafe.

Bẫy #2: UX (Trải nghiệm người dùng) như một cơn ác mộng Luật "No Write Down" khiến user phát điên. Tưởng tượng một nhân viên cấp cao không thể reply lại email của cấp dưới chỉ vì hệ thống sợ họ lỡ tay rò rỉ thông tin mật xuống cái thread email đó. Họ phải dùng 2 máy tính vật lý khác nhau, hoặc hệ thống phải thiết kế luồng "Hạ cấp tài liệu" (Declassification) qua 3 lớp duyệt mệt mỏi.

Bẫy #3: Không tự code MAC trên Application Layer Nếu làm RBAC hay ABAC, anh em tự code Middleware bằng Node.js/PHP/Java là chạy ngon. Nhưng MAC thì khác! MAC hiếm khi được code ở tầng Ứng dụng (Application Layer). Nó phải được cắm rễ từ tầng Hệ điều hành (OS) hoặc Database Engine. Kinh nghiệm thực chiến: Nếu khách hàng ép dùng MAC, đừng tự code! Hãy dùng các hệ điều hành có sẵn MAC như SELinux (Security-Enhanced Linux), AppArmor, hoặc các tính năng Label Security của Oracle DB, PostgreSQL (dùng extension sepgsql).

Tổng Kết Lại

MAC không phải là thứ để anh em đem ra lòe sếp hay khoe skill code. Nó là "vũ khí hạng nặng" chỉ được rút ra khi hệ thống đối mặt với những yêu cầu tuân thủ an ninh (Compliance) khắt khe nhất của chính phủ hay quân sự.

Nắm được MAC, Bell-LaPadula (Bảo mật) và Biba (Toàn vẹn dữ liệu) là anh em đã chạm tới những khái niệm cực sâu của Security Architecture, đủ sức "chém gió" sòng phẳng với bất kỳ chuyên gia bảo mật nào.

Anh em nào hay cấu hình VPS Linux chắc chắn từng đụng mặt SELinux rồi đúng không? Có anh em nào từng cay cú vì cài Web Server, chỉnh đúng quyền chmod 777, chown đủ kiểu rồi mà web vẫn báo lỗi 403 Forbidden, cuối cùng phát hiện ra do SELinux nó chặn chưa? Đó chính là MAC đang hoạt động đấy! Anh em thường tìm hiểu nguyên lý để cấu hình nó, hay gõ luôn lệnh setenforce 0 để tắt mẹ nó đi cho nhẹ nợ? Khai thật đi! 😆