ABAC là gì? Giải mã cơ chế kiểm soát truy cập dựa trên thuộc tính

Khi hệ thống web ngày càng phát triển, kiểm soát quyền truy cập chỉ dựa trên vai trò người dùng có thể không đủ để đáp ứng các yêu cầu phân quyền phức tạp. ABAC (Attribute-Based Access Control) là mô hình kiểm soát truy cập dựa trên nhiều thuộc tính của người dùng, tài nguyên, hành động và môi trường, giúp hệ thống đưa ra quyết định quyền truy cập chi tiết hơn. Không chỉ dừng ở việc xác định người dùng thuộc role nào, ABAC cho phép xây dựng các policy dựa trên nhiều điều kiện khác nhau. Mô hình này đặc biệt hữu ích khi doanh nghiệp cần kiểm soát quyền theo dữ liệu, ngữ cảnh truy cập hoặc phạm vi trách nhiệm của từng người dùng. Vậy ABAC là gì, mô hình này hoạt động như thế nào và cần lưu ý gì khi triển khai? Cùng tìm hiểu chi tiết trong bài viết sau!

 

 

ABAC là gì?

ABAC (Attribute-Based Access Control) là mô hình kiểm soát truy cập dựa trên các thuộc tính của người dùng, tài nguyên, hành động và môi trường truy cập. Thay vì chỉ xác định người dùng thuộc role nào, ABAC sử dụng tập hợp các thuộc tính và điều kiện để quyết định một yêu cầu truy cập có được phép thực hiện hay không.

Ví dụ, hệ thống có thể cho phép nhân viên thuộc phòng Kinh doanh xem dữ liệu khách hàng do chính mình phụ trách trong giờ làm việc và từ thiết bị được xác thực. Khi đó, quyền truy cập không chỉ phụ thuộc vào vai trò mà còn được xác định dựa trên phòng ban, người sở hữu dữ liệu, thời gian, thiết bị và nhiều thuộc tính khác.

ABAC thường được xây dựng thông qua các policy (chính sách) để mô tả điều kiện truy cập. Cách tiếp cận này giúp hệ thống xử lý những yêu cầu phân quyền phức tạp mà các mô hình dựa hoàn toàn vào role khó đáp ứng.

 

 

Lợi ích attribute-based access control mang lại trong lĩnh vực phát triển web

Trong phát triển web, attribute-based access control cho phép doanh nghiệp xây dựng cơ chế phân quyền dựa trên nhiều điều kiện thay vì giới hạn ở một vài role cố định. Điều này đặc biệt hữu ích với các hệ thống có nhiều loại người dùng, dữ liệu nhạy cảm và quy trình nghiệp vụ phức tạp.

1. Phân quyền linh hoạt theo ngữ cảnh

ABAC cho phép hệ thống đưa ngữ cảnh của từng yêu cầu truy cập vào quá trình ra quyết định. Các thuộc tính như vị trí người dùng, phòng ban, loại tài nguyên, thời gian truy cập, thiết bị hoặc trạng thái của dữ liệu có thể được kết hợp để xây dựng điều kiện phân quyền.

Ví dụ, một nhân viên có thể được phép chỉnh sửa hồ sơ khách hàng thuộc khu vực mình phụ trách nhưng chỉ được xem dữ liệu của khu vực khác. Khi nhân viên chuyển phòng ban hoặc thay đổi phạm vi phụ trách, hệ thống chỉ cần cập nhật các thuộc tính liên quan thay vì tạo thêm nhiều role mới.

Cách phân quyền này phù hợp với những website và ứng dụng web có nghiệp vụ thay đổi thường xuyên, khi quyền truy cập cần phụ thuộc vào nhiều yếu tố trong từng tình huống cụ thể.

2. Giải quyết triệt để bài toán kiểm soát quyền sở hữu dữ liệu

Trong các hệ thống web, người dùng có thể có cùng vai trò nhưng không nhất thiết được phép truy cập cùng một dữ liệu. ABAC giải quyết vấn đề này bằng cách kết hợp các thuộc tính của người dùng, tài nguyên và mối quan hệ giữa chúng để xác định quyền truy cập.

Mô hình này cho phép hệ thống kiểm soát quyền ở cấp độ từng tài nguyên hoặc bản ghi, thay vì chỉ phân quyền theo chức năng hoặc role. Quyền truy cập có thể được xác định dựa trên các thuộc tính như người sở hữu dữ liệu, phòng ban, khu vực hoặc phạm vi trách nhiệm. Nhờ đó, hệ thống có thể kiểm soát chính xác ai được xem, chỉnh sửa hoặc thực hiện thao tác trên từng nhóm dữ liệu. Cách tiếp cận này cũng giúp hạn chế truy cập trái phép và duy trì cấu trúc phân quyền rõ ràng khi dữ liệu ngày càng mở rộng.

3. Đáp ứng kiến trúc bảo mật Zero Trust và các tiêu chuẩn khắt khe

Kiểm soát truy cập dựa trên thuộc tính phù hợp với tư duy Zero Trust, trong đó quyền truy cập được đánh giá dựa trên từng yêu cầu và các thuộc tính liên quan thay vì mặc định tin cậy người dùng chỉ vì họ đã đăng nhập vào hệ thống.

Một policy có thể yêu cầu đồng thời nhiều điều kiện, chẳng hạn người dùng phải thuộc đúng bộ phận, có quyền đối với tài nguyên, sử dụng thiết bị được phép và thực hiện truy cập trong một khoảng thời gian nhất định. Nếu một trong các điều kiện không đáp ứng, yêu cầu có thể bị từ chối. Cách tiếp cận này giúp doanh nghiệp xây dựng cơ chế kiểm soát truy cập chi tiết hơn cho các hệ thống chứa dữ liệu quan trọng hoặc phải đáp ứng yêu cầu bảo mật nghiêm ngặt.

4. Giảm thiểu rủi ro Role Explosion

Một hạn chế thường gặp của RBAC là số lượng role có thể tăng nhanh khi nghiệp vụ trở nên phức tạp. Ví dụ, thay vì chỉ có role "nhân viên", doanh nghiệp có thể phải tạo thêm nhiều role như nhân viên miền Bắc, nhân viên miền Nam, nhân viên miền Bắc chỉ được xem dữ liệu, nhân viên miền Bắc được chỉnh sửa dữ liệu... Đây là tình trạng thường được gọi là Role Explosion.

ABAC giải quyết vấn đề này bằng cách đưa các điều kiện khác nhau vào policy và sử dụng thuộc tính để xác định quyền truy cập. Thay vì tạo một role riêng cho từng trường hợp, hệ thống có thể duy trì một số role cơ bản kết hợp với các thuộc tính như phòng ban, khu vực, cấp bậc hoặc quyền sở hữu dữ liệu. Nhờ đó, mô hình phân quyền có thể được tổ chức gọn hơn khi số lượng người dùng, tài nguyên và trường hợp nghiệp vụ tăng lên. 

5. Khả năng mở rộng cao theo sự phát triển của nghiệp vụ

Khi doanh nghiệp mở rộng, hệ thống web thường phát sinh thêm phòng ban, loại tài nguyên, quy trình và yêu cầu phân quyền. Nếu quyền truy cập được gắn quá chặt với role, mỗi thay đổi nghiệp vụ có thể kéo theo việc tạo hoặc chỉnh sửa nhiều role.

Với ABAC, doanh nghiệp có thể bổ sung thuộc tính và policy để phản ánh các yêu cầu mới mà không nhất thiết phải tạo một role riêng cho từng trường hợp. Ví dụ, khi mở rộng thêm khu vực kinh doanh, hệ thống có thể bổ sung thuộc tính region và cập nhật policy tương ứng để xác định phạm vi dữ liệu được phép truy cập.

 

 

Các thành phần chính của ABAC

ABAC kiểm soát quyền truy cập bằng cách phân tích nhiều yếu tố trong một yêu cầu thay vì chỉ dựa trên vai trò của người dùng. Mỗi yêu cầu được xem xét dựa trên thông tin về chủ thể, tài nguyên, hành động và môi trường, sau đó đối chiếu với các quy tắc được định nghĩa trong policy. Năm thành phần chính của ABAC gồm Subject, Resource, Action, Environment và Policy, phối hợp với nhau để tạo ra quyết định cho phép hoặc từ chối truy cập

1. Subject - Chủ thể

Subject là đối tượng gửi yêu cầu truy cập đến hệ thống. Trong phần lớn trường hợp, Subject là người dùng đã đăng nhập nhưng cũng có thể là một tài khoản dịch vụ hoặc service cần truy cập tài nguyên để thực hiện một tác vụ.

Subject được mô tả thông qua tập hợp các thuộc tính liên quan đến danh tính và đặc điểm của đối tượng. Các thuộc tính có thể bao gồm user_id, role, phòng ban, chức vụ, khu vực làm việc, cấp quyền hoặc trạng thái tài khoản. Những thông tin này giúp hệ thống xác định chính xác ai đang yêu cầu truy cập và chủ thể đó có những đặc điểm nào.

Điểm quan trọng của ABAC là quyền truy cập không nhất thiết được xác định bởi một thuộc tính duy nhất của Subject. Hệ thống có thể kết hợp nhiều thuộc tính để tạo thành điều kiện phân quyền chi tiết hơn. Khi thuộc tính của Subject thay đổi, quyết định truy cập cũng có thể thay đổi theo policy mà không cần xây dựng lại toàn bộ hệ thống role.

2. Resource - Tài nguyên

Resource là đối tượng mà Subject muốn truy cập hoặc thực hiện hành động. Trong một website, Resource có thể là một trang, API endpoint, file, tài liệu, cơ sở dữ liệu, bản ghi khách hàng, đơn hàng hoặc một loại dữ liệu cụ thể. Tương tự Subject, Resource cũng có thể được mô tả bằng nhiều thuộc tính. Những thuộc tính này có thể bao gồm loại tài nguyên, mã tài nguyên, người sở hữu, phòng ban quản lý, khu vực, mức độ bảo mật, trạng thái hoặc thời điểm tạo dữ liệu.

Đưa thuộc tính của Resource vào policy giúp hệ thống kiểm soát quyền ở mức chi tiết hơn. Thay vì chỉ xác định một người có quyền truy cập vào một loại tài nguyên hay không, kiểm soát truy cập dựa trên thuộc tính có thể xác định người đó được truy cập tài nguyên nào và trong phạm vi nào.

3. Action - Hành động

Action mô tả thao tác mà Subject muốn thực hiện đối với Resource. Đây là thành phần giúp hệ thống xác định cụ thể người dùng đang yêu cầu quyền gì, thay vì chỉ kiểm tra quyền truy cập chung. Các Action phổ biến trong hệ thống web gồm read, create, update, delete hoặc các thao tác nghiệp vụ riêng như phê duyệt, xuất dữ liệu, tải file và thực thi một chức năng. Mỗi Action có thể được quy định những điều kiện truy cập khác nhau trong policy.

Phân biệt Action giúp hệ thống triển khai phân quyền theo mức độ thao tác. Một Subject có thể được phép xem một Resource nhưng không được phép chỉnh sửa hoặc xóa Resource đó. Nhờ vậy, ABAC có thể kiểm soát quyền chi tiết đến từng loại hành động thay vì cấp quyền theo cách tổng quát.

4. Environment - Môi trường

Environment bao gồm các thông tin mô tả bối cảnh tại thời điểm Subject gửi yêu cầu truy cập. Đây là thành phần giúp ABAC đưa các yếu tố bên ngoài người dùng và tài nguyên vào quá trình đánh giá quyền.

Một số thuộc tính Environment thường được sử dụng gồm:

- Thời gian: Xác định thời điểm yêu cầu được thực hiện, chẳng hạn ngày, giờ hoặc khoảng thời gian truy cập.

- Địa chỉ IP: Xác định nguồn kết nối của yêu cầu và hỗ trợ áp dụng các chính sách dựa trên mạng hoặc phạm vi IP được cho phép.

- Vị trí: Xác định khu vực địa lý mà yêu cầu truy cập được thực hiện khi hệ thống có thông tin phù hợp.

- Thiết bị: Bao gồm loại thiết bị, hệ điều hành hoặc các thông tin liên quan đến thiết bị đang gửi yêu cầu.

- Trạng thái kết nối: Xác định những đặc điểm của phiên hoặc kết nối hiện tại, chẳng hạn loại mạng, trạng thái bảo mật.

- Trạng thái hệ thống: Cung cấp thông tin về bối cảnh hoạt động của hệ thống tại thời điểm yêu cầu được xử lý.

5. Policy - Chính sách truy cập

Policy là tập hợp các quy tắc xác định điều kiện để hệ thống cho phép hoặc từ chối một yêu cầu truy cập. Đây là thành phần trung tâm trong ABAC, nơi các thuộc tính của Subject, Resource, Action và Environment được kết hợp để xây dựng logic phân quyền.

Một policy có thể bao gồm nhiều điều kiện khác nhau, chẳng hạn:

- Subject: Người dùng thuộc phòng ban nào, có vai trò gì hoặc đang ở trạng thái nào.

- Resource: Tài nguyên thuộc loại nào, do ai sở hữu hoặc có mức độ bảo mật ra sao.

- Action: Người dùng muốn xem, tạo, chỉnh sửa, xóa hay thực hiện thao tác nào.

- Environment: Yêu cầu được thực hiện vào thời điểm nào, từ thiết bị hoặc môi trường kết nối nào.

Khi có yêu cầu truy cập, hệ thống sẽ thu thập các thuộc tính liên quan và đưa vào quá trình đánh giá policy. Nếu các điều kiện được quy định đáp ứng đầy đủ, policy có thể đưa ra quyết định Permit; ngược lại, yêu cầu có thể bị Deny.

Policy cũng có thể được xây dựng và điều chỉnh độc lập với mã nguồn của từng chức năng. Điều này giúp doanh nghiệp dễ thay đổi quy tắc phân quyền khi nghiệp vụ phát sinh yêu cầu mới, đồng thời hạn chế việc phải tạo thêm nhiều role chỉ để đáp ứng những trường hợp truy cập khác nhau.

 

 

Kiến trúc hoạt động chuẩn của attribute-based access control

Kiến trúc ABAC được tổ chức thành nhiều thành phần với nhiệm vụ riêng trong quá trình kiểm soát truy cập. Khi người dùng gửi yêu cầu, hệ thống không chỉ kiểm tra danh tính mà còn thu thập các thuộc tính liên quan, lấy thông tin cần thiết và đối chiếu với các policy đã được cấu hình.

1. PEP (Policy Enforcement Point)

PEP (Policy Enforcement Point) là điểm thực thi chính sách, có nhiệm vụ tiếp nhận yêu cầu truy cập, gửi yêu cầu đánh giá và thực thi quyết định phân quyền từ PDP. PEP nằm trên đường đi của request, giúp đảm bảo mọi yêu cầu truy cập đến tài nguyên đều được kiểm tra theo policy trước khi được xử lý.

PEP không trực tiếp quyết định người dùng có quyền truy cập hay không. Thay vào đó, thành phần này chuyển thông tin yêu cầu đến PDP (Policy Decision Point) để đánh giá, sau đó nhận kết quả và thực hiện quyết định tương ứng.

PEP thường có thể được triển khai tại:

- API Gateway: Kiểm soát request trước khi chuyển đến các API hoặc service phía sau.

- Middleware: Kiểm tra quyền truy cập trong quá trình xử lý request của ứng dụng web.

- Web server hoặc application server: Chặn hoặc cho phép request trước khi người dùng tiếp cận tài nguyên.

2. PDP (Policy Decision Point)

PDP (Policy Decision Point) là thành phần ra quyết định truy cập trong kiến trúc ABAC. PDP có nhiệm vụ đánh giá yêu cầu truy cập dựa trên các thuộc tính của Subject, Resource, Action, Environment và các Policy đã được thiết lập để xác định request có được phép thực hiện hay không.

Khi nhận yêu cầu đánh giá từ PEP, PDP sẽ kiểm tra những thuộc tính cần thiết. Nếu thông tin chưa đầy đủ, PDP có thể yêu cầu PIP cung cấp thêm dữ liệu từ các nguồn liên quan. Sau đó, PDP đối chiếu các thuộc tính này với policy và tạo ra quyết định truy cập.

Quá trình xử lý của PDP có thể khái quát như sau:

- Nhận yêu cầu: Tiếp nhận thông tin request từ PEP.

- Thu thập thuộc tính: Sử dụng thông tin có sẵn hoặc yêu cầu PIP cung cấp thêm thuộc tính.

- Đánh giá policy: Đối chiếu các thuộc tính của request với những điều kiện được quy định trong policy.

- Đưa ra quyết định: Trả về kết quả như Permit hoặc Deny cho PEP.

- Thực thi kết quả: PEP sử dụng quyết định của PDP để cho phép request tiếp tục hoặc từ chối truy cập.

PDP vì vậy đóng vai trò “bộ phận ra quyết định” của ABAC, trong khi PEP chịu trách nhiệm “thực thi quyết định”. Tách biệt hai chức năng này giúp logic phân quyền được tập trung và dễ quản lý khi hệ thống có nhiều dịch vụ.

3. PIP (Policy Information Point)

PIP (Policy Information Point) là thành phần có nhiệm vụ thu thập và cung cấp các thuộc tính cần thiết cho PDP trong quá trình đánh giá quyền truy cập. PIP không trực tiếp quyết định cho phép hay từ chối request mà đóng vai trò cung cấp dữ liệu để PDP có đủ thông tin đối chiếu với policy.

Khi PDP nhận được yêu cầu nhưng chưa có đầy đủ thuộc tính cần thiết, PIP sẽ truy xuất thông tin từ các nguồn dữ liệu liên quan. Những nguồn này có thể bao gồm hệ thống quản lý người dùng, cơ sở dữ liệu, hệ thống nhân sự, dịch vụ định danh hoặc các nguồn cung cấp thông tin về môi trường truy cập.

Các loại thông tin PIP có thể cung cấp gồm:

- Thuộc tính Subject: ID người dùng, phòng ban, chức vụ, vai trò hoặc trạng thái tài khoản.

- Thuộc tính Resource: Người sở hữu, loại tài nguyên, trạng thái hoặc mức độ bảo mật của dữ liệu.

- Thuộc tính Environment: Thời gian, địa chỉ IP, thiết bị, vị trí hoặc trạng thái của phiên truy cập.

Sau khi thu thập được các thuộc tính, PIP cung cấp thông tin cho PDP để tiếp tục đánh giá policy. Nhờ đó, PDP có thể đưa ra quyết định dựa trên dữ liệu đầy đủ và phù hợp với trạng thái thực tế của request.

4. PAP (Policy Administration Point)

PAP (Policy Administration Point) là thành phần chịu trách nhiệm tạo, quản lý, cập nhật và duy trì các policy trong kiến trúc kiểm soát truy cập dựa trên thuộc tính. Đây là nơi các quy tắc kiểm soát truy cập được xây dựng dựa trên yêu cầu nghiệp vụ và chính sách bảo mật của hệ thống.

PAP không trực tiếp xử lý request hoặc quyết định cho phép truy cập. Thay vào đó, các policy được quản lý tại PAP sẽ được cung cấp cho PDP để PDP sử dụng trong quá trình đánh giá quyền truy cập.

Các chức năng chính của PAP gồm:

- Tạo policy: Xây dựng các quy tắc xác định điều kiện cho phép hoặc từ chối truy cập.

- Chỉnh sửa policy: Cập nhật điều kiện khi nghiệp vụ hoặc yêu cầu bảo mật thay đổi.

- Quản lý policy: Theo dõi, phân loại và duy trì các policy đang được hệ thống sử dụng.

- Kiểm soát phiên bản: Quản lý những thay đổi của policy để dễ kiểm tra và duy trì tính nhất quán.

- Phân phối policy: Cung cấp các policy cần thiết cho PDP để sử dụng khi đánh giá request.

 

 

Khi nào nên và không nên sử dụng mô hình ABAC?

Mô hình ABAC phù hợp với những hệ thống cần kiểm soát quyền truy cập dựa trên nhiều thuộc tính và điều kiện khác nhau. Tuy nhiên, mô hình này cũng có độ phức tạp nhất định trong quá trình xây dựng, quản lý policy và duy trì dữ liệu thuộc tính. Vì vậy, lựa chọn ABAC nên dựa trên mức độ phức tạp của nghiệp vụ, yêu cầu bảo mật và khả năng quản trị hệ thống.

1. Trường hợp nên sử dụng attribute-based access control

ABAC thường phù hợp khi hệ thống có nhiều đối tượng, tài nguyên và điều kiện truy cập cần được kiểm soát linh hoạt. Một số trường hợp có thể cân nhắc sử dụng attribute-based access control gồm:

- Hệ thống có nghiệp vụ phân quyền phức tạp: Quyền truy cập phụ thuộc đồng thời vào người dùng, tài nguyên, hành động và nhiều điều kiện khác.

- Cần kiểm soát quyền ở cấp độ dữ liệu: Hệ thống cần xác định người dùng được truy cập những bản ghi hoặc nhóm dữ liệu nào thay vì chỉ cấp quyền cho toàn bộ một loại tài nguyên.

- Quyền truy cập thay đổi theo ngữ cảnh: Quyền có thể phụ thuộc vào thời gian, thiết bị, vị trí, mạng kết nối hoặc trạng thái của hệ thống.

- Có nhiều nhóm người dùng và tài nguyên: Khi số lượng user, phòng ban, tài nguyên và quy tắc nghiệp vụ tăng, phân quyền ABAC giúp hạn chế việc phải tạo quá nhiều role riêng biệt.

- Hệ thống cần tích hợp nhiều ứng dụng hoặc service: Các policy có thể được quản lý tập trung và sử dụng để kiểm soát quyền trên nhiều thành phần của hệ thống.

- Yêu cầu bảo mật và kiểm soát truy cập ở mức cao: ABAC cho phép xây dựng các điều kiện truy cập chi tiết dựa trên nhiều thuộc tính và ngữ cảnh khác nhau.

2. Trường hợp không nên sử dụng ABAC

Không phải hệ thống nào cũng cần đến mô hình phân quyền dựa trên thuộc tính. Với những hệ thống có yêu cầu đơn giản, triển khai ABAC có thể tạo thêm độ phức tạp không cần thiết. Một số trường hợp không nên ưu tiên attribute-based access control bao gồm:

- Hệ thống có phân quyền đơn giản: Quyền truy cập chỉ cần phân chia theo một số role cố định như quản trị viên, nhân viên và khách.

- Số lượng người dùng và tài nguyên nhỏ: Khi hệ thống có ít đối tượng và quy tắc truy cập rõ ràng, xây dựng ABAC có thể không mang lại nhiều lợi ích.

- Nghiệp vụ ít thay đổi: Nếu các quy tắc phân quyền ổn định và không phụ thuộc nhiều vào ngữ cảnh, mô hình đơn giản hơn có thể đáp ứng nhu cầu.

- Đội ngũ chưa có khả năng quản lý policy: ABAC yêu cầu xây dựng, kiểm thử, theo dõi và duy trì nhiều policy cùng hệ thống thuộc tính tương ứng.

- Nguồn dữ liệu thuộc tính không đáng tin cậy hoặc khó duy trì: ABAC phụ thuộc vào độ chính xác và tính cập nhật của các thuộc tính được sử dụng để ra quyết định.

 

 

Hướng dẫn triển khai phân quyền ABAC trong hệ thống web

Triển khai phân quyền ABAC trong hệ thống web cần được thực hiện theo một quy trình rõ ràng, từ xác định thuộc tính đến xây dựng policy và tích hợp vào luồng xử lý request. Mỗi thành phần như PEP, PDP, PIP và PAP cần được phân định nhiệm vụ cụ thể để hệ thống có thể kiểm soát quyền chính xác và dễ quản lý. Quy trình dưới đây sẽ giúp xây dựng ABAC theo từng bước, đồng thời hạn chế các vấn đề về hiệu năng, bảo mật và khả năng mở rộng.

Bước 1: Mô hình hóa danh mục thuộc tính (Attribute modeling)

Attribute modeling là bước xác định những thuộc tính cần thiết để hệ thống có thể đưa ra quyết định truy cập. Thay vì bắt đầu bằng việc tạo role, cần phân tích nghiệp vụ để xác định Subject, Resource, Action và Environment có những thuộc tính nào và thuộc tính nào thực sự ảnh hưởng đến quyền truy cập.

Có thể phân loại thuộc tính thành các nhóm chính:

- Subject attributes: ID người dùng, phòng ban, chức vụ, vai trò, khu vực hoặc trạng thái tài khoản.

- Resource attributes: ID tài nguyên, loại tài nguyên, người sở hữu, phòng ban quản lý, mức độ bảo mật hoặc trạng thái dữ liệu.

- Action attributes: Đọc, tạo, cập nhật, xóa, phê duyệt, tải xuống hoặc các hành động nghiệp vụ khác.

- Environment attributes: Thời gian, địa chỉ IP, thiết bị, vị trí, loại mạng hoặc trạng thái phiên truy cập.

Sau khi xác định danh mục thuộc tính, cần quy định nguồn dữ liệu, kiểu dữ liệu, giá trị hợp lệ và cách cập nhật cho từng thuộc tính. Việc chuẩn hóa ngay từ đầu giúp tránh tình trạng cùng một thuộc tính nhưng được biểu diễn theo nhiều cách khác nhau giữa các service.

Bước 2: Lựa chọn kiến trúc & policy engine (PEP/PDP setup)

Sau khi xác định các thuộc tính, bước tiếp theo là thiết kế cách ABAC được tích hợp vào hệ thống web. Kiến trúc cần xác định rõ PEP nằm ở đâu, PDP xử lý policy như thế nào, PIP lấy thuộc tính từ nguồn nào và PAP được sử dụng để quản lý policy ra sao.

PEP thường được đặt tại những vị trí có thể kiểm soát request như API Gateway, middleware hoặc application layer. Khi có request, PEP chuyển thông tin cần thiết đến PDP để đánh giá. PDP sử dụng policy cùng các thuộc tính được cung cấp để đưa ra quyết định, sau đó PEP thực thi kết quả bằng cách cho phép request tiếp tục hoặc từ chối truy cập.

Đối với hệ thống có nhiều service, có thể cân nhắc sử dụng policy engine riêng để tập trung việc đánh giá policy. Khi lựa chọn policy engine, cần xem xét khả năng tích hợp với kiến trúc hiện tại, cách lưu trữ và quản lý policy, khả năng cung cấp thuộc tính, hiệu năng xử lý request, logging và khả năng mở rộng.

Bước 3: Định nghĩa quy tắc và xây dựng chính sách (Policy definition)

Sau khi có mô hình thuộc tính và kiến trúc xử lý, cần chuyển các yêu cầu nghiệp vụ thành policy có thể thực thi. Mỗi policy nên xác định rõ Subject nào được phép thực hiện Action nào trên Resource nào và trong điều kiện Environment nào. Khi xây dựng policy, nên ưu tiên các quy tắc rõ ràng, cụ thể và có thể kiểm thử. Đồng thời, cần xác định cách xử lý khi một request không đáp ứng policy hoặc khi có nhiều policy cùng áp dụng cho một request.

Quy trình xây dựng policy có thể gồm:

- Xác định tài nguyên và hành động cần kiểm soát.

- Xác định các thuộc tính cần dùng để ra quyết định.

- Chuyển yêu cầu nghiệp vụ thành các điều kiện trong policy.

- Xác định kết quả khi điều kiện được đáp ứng hoặc không được đáp ứng.

- Kiểm thử policy với nhiều trường hợp truy cập khác nhau.

- Ghi log quyết định để hỗ trợ kiểm tra và phát hiện vấn đề phân quyền.

Sau khi hoàn thiện, policy cần được đưa vào quy trình quản lý phiên bản và kiểm thử giống như mã nguồn. Điều này giúp kiểm soát những thay đổi về quyền truy cập và hạn chế lỗi khi hệ thống ngày càng phát triển.

Bước 4: Tích hợp Backend Middleware & truy vấn thuộc tính

Sau khi xây dựng policy, cần tích hợp cơ chế ABAC vào backend middleware để kiểm tra quyền trước khi request được xử lý đến tài nguyên. Middleware có thể đóng vai trò PEP, tiếp nhận request và thu thập những thông tin cần thiết như người dùng, tài nguyên, hành động và bối cảnh truy cập.

Middleware sau đó gửi các thuộc tính này đến PDP để đánh giá policy. Nếu PDP yêu cầu thêm thông tin, hệ thống có thể truy vấn dữ liệu từ các nguồn liên quan thông qua PIP. Sau khi nhận được quyết định, middleware sẽ cho phép request tiếp tục hoặc từ chối truy cập.

Khi triển khai bước này, cần chú ý:

- Xác định rõ điểm kiểm tra quyền trong backend.

- Chuẩn hóa cách lấy thuộc tính từ database hoặc các service khác.

- Hạn chế truy vấn dư thừa để tránh làm tăng thời gian xử lý request.

- Xử lý rõ trường hợp không tìm thấy thuộc tính hoặc nguồn dữ liệu tạm thời không khả dụng.

- Không để client tự quyết định hoặc gửi trực tiếp những thuộc tính quan trọng có thể ảnh hưởng đến quyền truy cập.

Bước 5: Kiểm thử chính sách (Policy testing & Dry-run)

Sau khi tích hợp ABAC, cần kiểm thử policy trước khi áp dụng hoàn toàn vào môi trường production. Mục tiêu là xác định policy có phản ánh đúng yêu cầu nghiệp vụ hay không và phát hiện những trường hợp có thể cho phép sai hoặc từ chối sai.

Có thể xây dựng bộ test dựa trên nhiều tổ hợp giữa Subject, Resource, Action và Environment. Mỗi trường hợp cần xác định trước kết quả mong đợi để đối chiếu với quyết định thực tế từ PDP.

Bên cạnh kiểm thử thông thường, Dry-run có thể được sử dụng để đánh giá policy mà chưa thực sự chặn request. Hệ thống ghi nhận quyết định mà policy sẽ đưa ra, sau đó so sánh với hành vi hiện tại để phát hiện những khác biệt trước khi policy được kích hoạt chính thức.

Quá trình kiểm thử nên bao gồm cả:

- Trường hợp được phép truy cập.

- Trường hợp bị từ chối truy cập.

- Trường hợp thiếu hoặc sai thuộc tính.

- Trường hợp nhiều policy cùng áp dụng.

- Trường hợp thuộc tính thay đổi theo thời gian hoặc ngữ cảnh.

- Trường hợp policy mới ảnh hưởng đến những request đang hoạt động.

Bước 6: Lưu nhật ký truy vết & kiểm toán (Logging & Audit trail)

Logging và Audit trail giúp ghi nhận quá trình đánh giá và thực thi quyền để có thể kiểm tra lại khi xảy ra sự cố hoặc cần rà soát hoạt động truy cập. Với ABAC, nhật ký nên cung cấp đủ thông tin để xác định request nào đã được xử lý và quyết định được đưa ra dựa trên những điều kiện nào.

Một bản ghi audit có thể lưu các thông tin như:

- Thời điểm: Request được thực hiện khi nào.

- Subject: Đối tượng thực hiện yêu cầu.

- Resource: Tài nguyên được yêu cầu truy cập.

- Action: Hành động được yêu cầu.

- Environment: Các thông tin môi trường liên quan.

- Policy: Policy được sử dụng để đánh giá.

- Decision: Kết quả như Permit hoặc Deny.

- Request ID: Mã định danh để truy vết request giữa nhiều service.

Nhật ký cần được bảo vệ khỏi việc chỉnh sửa trái phép và có chính sách lưu trữ phù hợp với yêu cầu của hệ thống. Việc duy trì audit trail đầy đủ giúp đội ngũ kỹ thuật truy vết request, phát hiện hành vi bất thường, kiểm tra lỗi phân quyền và phục vụ quá trình kiểm toán khi cần thiết.

 

 

Những lưu ý khi triển khai phân quyền ABAC

ABAC mang lại khả năng phân quyền linh hoạt nhưng cũng làm tăng số lượng điều kiện cần xử lý trong mỗi yêu cầu truy cập. Nếu thiết kế thuộc tính, policy và kiến trúc xử lý không hợp lý, hệ thống có thể phát sinh độ trễ hoặc trở nên khó quản lý. Vì vậy, khi triển khai ABAC cần cân bằng giữa mức độ chi tiết của phân quyền, hiệu năng hệ thống và khả năng duy trì policy.

1. Tối ưu hiệu năng và độ trễ API 

Trong ABAC, mỗi request có thể cần thu thập nhiều thuộc tính và thực hiện đánh giá policy trước khi được xử lý. Nếu PDP phải liên tục truy vấn database hoặc gọi nhiều service để lấy thuộc tính, thời gian phản hồi API có thể tăng lên, đặc biệt với hệ thống có lưu lượng lớn.

Do đó, cần xác định những thuộc tính thực sự cần thiết cho từng policy và hạn chế các truy vấn không cần thiết. Có thể sử dụng cơ chế cache cho những thuộc tính ít thay đổi, tối ưu việc truy vấn dữ liệu và giảm số lần giao tiếp giữa PEP, PDP và các nguồn cung cấp thuộc tính. Với những hệ thống yêu cầu độ trễ thấp, theo dõi thời gian đánh giá policy cũng cần được đưa vào quá trình giám sát hiệu năng.

2. Tránh bẫy phức tạp hóa hệ thống, ưu tiên mô hình lai

Không nên đưa mọi quy tắc phân quyền vào ABAC chỉ vì mô hình này có khả năng xử lý nhiều thuộc tính. Xây dựng quá nhiều thuộc tính và policy phức tạp có thể khiến logic phân quyền khó hiểu, khó kiểm thử và khó xác định nguyên nhân khi xảy ra lỗi.

Một hướng tiếp cận có thể cân nhắc là mô hình phân quyền lai (Hybrid), kết hợp ABAC với các mô hình khác như RBAC. Những quyền cơ bản, ổn định có thể được quản lý bằng role, trong khi những quyền phụ thuộc vào thuộc tính hoặc ngữ cảnh được xử lý bằng ABAC. Cách phân chia này giúp tận dụng ưu điểm của từng mô hình mà không làm policy trở nên phức tạp hơn mức cần thiết.

3. Xây dựng cơ chế giải quyết xung đột chính sách

Khi hệ thống có nhiều policy, một request có thể đồng thời khớp với nhiều quy tắc khác nhau và dẫn đến các quyết định không giống nhau. Nếu không xác định trước cách xử lý, hệ thống có thể đưa ra kết quả không nhất quán giữa các request hoặc giữa các service.

Vì vậy, cần xây dựng cơ chế giải quyết xung đột policy ngay từ khi thiết kế hệ thống. Policy cần được tổ chức theo cấu trúc rõ ràng và xác định cách ưu tiên khi có nhiều quyết định cùng áp dụng. Đồng thời, hệ thống nên ghi nhận policy nào đã được đánh giá và quyết định cuối cùng để đội ngũ kỹ thuật có thể kiểm tra, truy vết và điều chỉnh khi phát sinh một số vấn đề.

4. Kiểm thử toàn diện và giải bài toán bùng nổ tổ hợp thuộc tính

ABAC có thể sử dụng nhiều thuộc tính khác nhau của Subject, Resource, Action và Environment. Khi số lượng thuộc tính tăng lên, số trường hợp kết hợp giữa các giá trị cũng tăng theo, khiến việc kiểm thử toàn bộ policy trở nên phức tạp. Nếu chỉ kiểm tra một vài trường hợp phổ biến, hệ thống có thể bỏ sót những tổ hợp điều kiện dẫn đến cấp quyền sai hoặc từ chối nhầm.

Do đó, cần xây dựng bộ test bao phủ các nhóm thuộc tính quan trọng và tập trung vào những điều kiện có khả năng ảnh hưởng trực tiếp đến quyết định truy cập. Có thể kết hợp unit test, integration test, policy test và negative test để kiểm tra cả trường hợp được phép, bị từ chối, thiếu thuộc tính hoặc xuất hiện dữ liệu không hợp lệ. Đồng thời, nên tự động hóa quá trình kiểm thử để có thể chạy lại khi policy hoặc mô hình thuộc tính thay đổi.

5. Quản lý vòng đời chính sách & tránh hiện tượng policy creep

Khi hệ thống phát triển, số lượng policy thường tăng dần theo yêu cầu nghiệp vụ. Nếu liên tục bổ sung quy tắc mà không rà soát các policy hiện có, hệ thống có thể xuất hiện policy creep, tức là policy ngày càng nhiều, chồng chéo và khó xác định quy tắc nào đang thực sự cần thiết.

Để hạn chế vấn đề này, mỗi policy nên có mục đích, phạm vi áp dụng, chủ sở hữu và trạng thái rõ ràng. Policy cần được quản lý theo vòng đời từ tạo mới, kiểm thử, triển khai, cập nhật đến ngừng sử dụng. Định kỳ rà soát và loại bỏ những policy không còn phù hợp cũng giúp giảm xung đột, hạn chế logic dư thừa và giữ cho hệ thống phân quyền dễ quản lý.

6. Đảm bảo khả năng quan sát và truy vết

ABAC có nhiều thành phần cùng tham gia vào quá trình ra quyết định nên cần có khả năng quan sát và truy vết đầy đủ. Khi một request bị từ chối hoặc được cấp quyền không như mong đợi, đội ngũ kỹ thuật cần xác định được request nào đã xảy ra, những thuộc tính nào được sử dụng, policy nào được áp dụng, PDP đưa ra quyết định dựa trên điều kiện nào.

Vì vậy, hệ thống nên ghi nhận các thông tin cần thiết từ quá trình xử lý request và liên kết chúng bằng request ID hoặc correlation ID. Log và audit trail cần hỗ trợ theo dõi luồng từ PEP đến PDP, PIP và các nguồn dữ liệu liên quan. Khả năng quan sát tốt không chỉ giúp phát hiện lỗi phân quyền mà còn hỗ trợ kiểm toán, điều tra sự cố và đánh giá tác động khi policy được thay đổi.

 

 

So sánh ABAC với RBAC và ReBAC

ABAC, RBAC và ReBAC đều là các mô hình kiểm soát truy cập nhưng sử dụng những cơ chế khác nhau để xác định quyền. RBAC tập trung vào vai trò, ABAC dựa trên thuộc tính và điều kiện ngữ cảnh, trong khi ReBAC xác định quyền dựa trên mối quan hệ giữa chủ thể và tài nguyên. Lựa chọn mô hình phụ thuộc vào cấu trúc dữ liệu, mức độ phức tạp của nghiệp vụ và yêu cầu kiểm soát quyền của từng hệ thống.
 

 

Một số hạn chế của mô hình ABAC bạn nên cân nhắc

ABAC mang lại khả năng kiểm soát quyền truy cập linh hoạt nhưng cũng đi kèm một số hạn chế trong quá trình triển khai và vận hành. Khi số lượng thuộc tính và policy tăng lên, hệ thống có thể trở nên phức tạp hơn về thiết kế, kiểm thử và quản lý. Một số hạn chế cần cân nhắc gồm:

- Độ phức tạp cao: ABAC sử dụng nhiều thuộc tính và điều kiện để đưa ra quyết định, khiến việc thiết kế và duy trì hệ thống phân quyền phức tạp hơn các mô hình đơn giản như RBAC.

- Khó quản lý khi số lượng policy tăng: Hệ thống có thể phát sinh nhiều policy với các điều kiện chồng chéo, gây khó khăn trong việc kiểm tra, cập nhật và xác định quy tắc đang được áp dụng.

- Phụ thuộc vào chất lượng dữ liệu thuộc tính: Quyết định truy cập phụ thuộc vào các thuộc tính của Subject, Resource và Environment. Nếu dữ liệu thiếu, sai hoặc không được cập nhật kịp thời, kết quả phân quyền có thể không chính xác.

- Có thể ảnh hưởng đến hiệu năng: Thu thập thuộc tính từ nhiều nguồn và đánh giá policy trong mỗi request có thể làm tăng thời gian xử lý, đặc biệt với hệ thống có lưu lượng truy cập lớn.

- Khó kiểm thử toàn diện: Số lượng tổ hợp giữa nhiều thuộc tính và điều kiện có thể rất lớn, khiến việc kiểm thử đầy đủ các trường hợp truy cập trở nên khó khăn.

- Yêu cầu năng lực quản trị cao: Đội ngũ phát triển cần hiểu rõ mô hình thuộc tính, policy, kiến trúc PEP/PDP/PIP/PAP và quy trình kiểm soát quyền để vận hành ABAC hiệu quả.

 

 

Giải đáp câu hỏi thường gặp khi triển khai attribute-based access control

Khi triển khai attribute-based access control, doanh nghiệp thường gặp các vấn đề liên quan đến kiến trúc hiện tại, nơi lưu trữ policy, hiệu năng, giao diện và quá trình debug. Những vấn đề này cần được xử lý ngay từ giai đoạn thiết kế để ABAC có thể hoạt động ổn định mà không làm tăng độ phức tạp không cần thiết cho hệ thống.

1. Website hiện tại đang dùng RBAC, có cần đập đi xây lại để chuyển sang ABAC không?

Không nhất thiết phải xây dựng lại toàn bộ hệ thống từ đầu. Doanh nghiệp có thể triển khai ABAC theo từng phần, giữ lại RBAC cho những quyền cơ bản và bổ sung ABAC cho các trường hợp cần kiểm soát dựa trên thuộc tính hoặc ngữ cảnh. Có thể bắt đầu từ một nhóm chức năng hoặc tài nguyên có yêu cầu phân quyền phức tạp, sau đó xây dựng PEP, PDP và các policy tương ứng. Trong quá trình chuyển đổi, RBAC và ABAC có thể hoạt động song song để giảm rủi ro ảnh hưởng đến những chức năng đang vận hành ổn định. 

2. Nên lưu trữ các quy tắc Policy ở đâu để vừa an toàn vừa dễ quản lý?

Policy nên được quản lý tập trung tại một nguồn có cơ chế kiểm soát quyền truy cập, quản lý phiên bản và theo dõi thay đổi. Tùy kiến trúc hệ thống, policy có thể được lưu trong cơ sở dữ liệu, file cấu hình hoặc một policy store chuyên dụng. Quan trọng hơn vị trí lưu trữ là cơ chế bảo vệ và quản lý policy. Chỉ những thành phần hoặc người dùng được ủy quyền mới có thể tạo và thay đổi policy. Đồng thời, nên lưu lịch sử phiên bản, người thực hiện thay đổi và thời điểm thay đổi để có thể kiểm tra hoặc khôi phục khi xảy ra lỗi.

3. Truy vấn thuộc tính từ nhiều nguồn làm tăng độ trễ của API thì tối ưu ra sao?

Trước tiên cần xác định policy nào thực sự cần truy vấn thuộc tính và loại bỏ những dữ liệu không cần thiết khỏi quá trình đánh giá. Các thuộc tính ít thay đổi có thể được cache trong thời gian phù hợp để giảm số lần truy vấn database hoặc gọi service bên ngoài.

Ngoài ra, có thể tối ưu bằng cách gom nhóm dữ liệu cần lấy, giảm số lần giao tiếp giữa PEP, PDP và PIP, đồng thời theo dõi thời gian xử lý của từng thành phần. Với những thuộc tính có thể xác định ngay từ token hoặc session, hệ thống có thể sử dụng trực tiếp thay vì truy vấn lại nguồn dữ liệu trong mỗi request.

4. Xử lý render UI Frontend theo quyền thời gian thực thế nào?

Frontend có thể nhận thông tin quyền của người dùng từ Backend để quyết định nên hiển thị hay ẩn các thành phần giao diện. Ví dụ, nếu người dùng không có quyền chỉnh sửa thì frontend có thể không hiển thị nút “Chỉnh sửa” hoặc hiển thị nút ở trạng thái bị vô hiệu hóa.

Tuy nhiên, Frontend không được tự quyết định quyền truy cập. Khi người dùng thực hiện một thao tác, request vẫn phải được gửi đến Backend để PEP và PDP kiểm tra lại policy. Điều này đảm bảo người dùng không thể vượt qua phân quyền chỉ bằng cách tự thay đổi giao diện hoặc gửi request trực tiếp đến API.

Nếu quyền của người dùng có thể thay đổi trong lúc đang sử dụng website, frontend cần cập nhật lại trạng thái quyền từ Backend. Có thể thực hiện bằng cách gọi lại API lấy quyền theo một khoảng thời gian, refresh khi người dùng chuyển trang hoặc sử dụng cơ chế realtime như WebSocket/SSE nếu hệ thống yêu cầu cập nhật ngay khi quyền thay đổi.

5. Khi người dùng báo lỗi không có quyền truy cập, làm sao debug nhanh nguyên nhân?

Cần bắt đầu từ request cụ thể và sử dụng Request ID hoặc Correlation ID để truy vết toàn bộ luồng xử lý. Từ đó, đội ngũ kỹ thuật có thể kiểm tra request đã đi qua PEP nào, PDP đã nhận những thuộc tính gì, policy nào được áp dụng và quyết định cuối cùng là Permit hay Deny.

Log cũng nên ghi nhận nguyên nhân khiến policy không được đáp ứng mà không làm lộ những thông tin nhạy cảm. Nếu có audit trail đầy đủ, đội ngũ có thể nhanh chóng xác định lỗi nằm ở dữ liệu thuộc tính, policy, nguồn cung cấp thuộc tính hay quá trình thực thi quyết định. Điều này giúp rút ngắn thời gian xử lý sự cố và hạn chế việc phải kiểm tra thủ công toàn bộ hệ thống phân quyền.
 

Qua bài viết của Phương Nam Vina, có thể thấy ABAC là mô hình kiểm soát truy cập dựa trên thuộc tính, cho phép hệ thống xác định quyền dựa trên nhiều yếu tố như người dùng, tài nguyên, hành động và môi trường truy cập. So với cách phân quyền chỉ dựa trên role, ABAC có khả năng xử lý những nghiệp vụ cần kiểm soát quyền chi tiết, linh hoạt và thay đổi theo ngữ cảnh. Tuy nhiên, ABAC cũng làm tăng độ phức tạp trong việc xây dựng policy, quản lý thuộc tính, kiểm thử và giám sát hệ thống. Vì vậy, doanh nghiệp cần đánh giá yêu cầu phân quyền thực tế trước khi triển khai, đồng thời có thể kết hợp ABAC với RBAC hoặc các mô hình khác để tạo kiến trúc phù hợp với hệ thống.

Tham khảo thêm:

 PaaS là gì? Hiểu rõ sự khác biệt giữa PaaS, IaaS và SaaS

 IaaS là gì? Những điều cần biết về Infrastructure as a Service

 Monolithic architecture là gì? Đặc điểm của kiến trúc nguyên khối