Làm thế nào để thiết kế vai trò kiểm soát truy cập?


15

Tôi đang cố gắng làm theo mô hình kiểm soát truy cập cơ sở vai trò để hạn chế những gì người dùng có thể hoặc không thể làm trong hệ thống của tôi.

Cho đến nay tôi có các thực thể sau:

người dùng - Những người sẽ sử dụng hệ thống. Ở đây tôi có tên người dùng và mật khẩu. vai trò - Bộ sưu tập các vai trò mà người dùng có thể có. Những thứ như tài nguyên của người quản lý, quản trị viên, v.v. - Những thứ mà người dùng có thể thao tác. Giống như hợp đồng, người sử dụng, dự thảo hợp đồng, vv hoạt động - Những điều mà người dùng có thể làm với các nguồn tài nguyên. Thích tạo, đọc, cập nhật hoặc xóa.

Bây giờ, sự nghi ngờ của tôi tăng lên ở đây trong sơ đồ nơi tôi có một mối quan hệ như thế này:

các hoạt động (0 .. *) được thực thi theo tài nguyên (0 .. *) tạo ra bảng tôi gọi là quyền và sẽ lưu trữ hoạt độngtài nguyên .

Bảng quyền sẽ trông như thế này (một hàng của nó): ID: 1, hoạt động: tạo, tài nguyên: hợp đồng.

Có nghĩa là một sự cho phép để tạo ra một hợp đồng .

Tôi đã làm theo cách này vì tôi cảm thấy một số tài nguyên có thể không có tất cả các loại hoạt động. Chẳng hạn, để đăng ký hợp đồng , người dùng có thể tải lên các tệp , nhưng thao tác này không có sẵn để đăng ký nhà cung cấp .

Vì vậy, bây giờ khi quản trị viên sẽ cấp quyền cho một vai trò , anh ta sẽ không có danh sách tài nguyên với mỗi thao tác được đăng ký trong hệ thống.

Tôi nghĩ rằng mỗi tài nguyên có bộ sưu tập các hoạt động riêng có thể được thực thi theo anh ta.

Tôi có thể làm rõ nếu một cái gì đó không thể hiểu được.

Đây có phải là cách chính xác để thực hiện rbac?

BIÊN TẬP

Ý tôi là bằng cách có một bảng quyềnhoạt độngtài nguyên , tôi có thêm HAI bảng vì tôi muốn liên kết tài nguyên với các hoạt động . Tôi cũng có thể vừa thực hiện tài nguyênquyền trong đó bảng quyền sẽ lưu trữ quyền.

Nhưng sau đó, điều sẽ xảy ra là một số quyền thậm chí không tồn tại đối với một số tài nguyên sẽ xuất hiện khi quản trị viên sẽ chỉ định chúng.

Vì vậy, tôi muốn biết từ quan điểm thiết kế cơ sở dữ liệu nếu quyền này của bảng có một hoạt động cột và tài nguyên khác là chính xác? Tôi sẽ gặp vấn đề nếu nó vẫn như thế này?


2
Bạn có ý nghĩa gì bởi "chính xác?" Lưu ý: không trả lời với một tautology như "thực hành tốt nhất." Nêu các yêu cầu cụ thể của bạn.
Robert Harvey

1
Định nghĩa của tôi về "chính xác" thường là "đáp ứng hiệu quả nhất các yêu cầu chức năng và phi chức năng của phần mềm của bạn." Lưu ý rằng NIST cung cấp các hướng dẫn chi tiết và thực tiễn tốt nhất để bảo mật dựa trên vai trò. Xem csrc.nist.gov/groups/SNS/rbac
Robert Harvey

Bạn có thể quan tâm đến việc tìm kiếm nó được thực hiện như thế nào trong dự án pundit .
Antarr Byrd

1
Bạn nên xem xét sử dụng một thư viện cho việc này.
RibaldEddie

Có rất nhiều thư viện sẽ thực hiện RBAC hoặc ABAC cho bạn
David Brossard

Câu trả lời:


10

Thiết kế của bạn có vẻ khá gần gũi với tôi. Chỉ cần một vài gợi ý.

người dùng - Những người sẽ sử dụng hệ thống. Ở đây tôi có tên người dùng và mật khẩu.

Khỏe

vai trò - Bộ sưu tập các vai trò mà người dùng có thể có. Những thứ như người quản lý, quản trị viên, v.v.

Cũng tốt thôi. Nhưng bạn cũng sẽ cần một thực thể / bảng "UserRoles" sẽ cho bạn biết người dùng nào có vai trò nào. Có khả năng một người dùng nhất định có thể có hai vai trò trở lên.

tài nguyên - Những thứ mà người dùng có thể thao tác. Giống như hợp đồng, người dùng, dự thảo hợp đồng, vv

Có thể chỉ là một câu hỏi về ngữ nghĩa. Tôi không nghĩ người dùng trực tiếp thao túng tài nguyên; vai trò làm. Do đó, nó đi người dùng -> vai trò người dùng -> vai trò -> hoạt động -> tài nguyên

hoạt động - Những điều mà người dùng có thể làm với các tài nguyên. Thích tạo, đọc, cập nhật hoặc xóa.

vâng, ngoại trừ "vai trò" thay vì "người dùng"

Bảng quyền sẽ trông như thế này (một hàng của nó): ID: 1, hoạt động: tạo, tài nguyên: hợp đồng. Có nghĩa là một sự cho phép để tạo ra một hợp đồng.

Hừm. Có hai cách để đi với điều này. Bạn có thể có bảng quyền mà bạn mô tả, nhưng bạn cũng sẽ cần một RolePermissionsbảng / thực thể bổ sung cho bạn biết vai trò nào có quyền. Nhưng tôi không chắc đó là cần thiết.

Một cách đơn giản hơn để làm điều đó là một bảng quyền / thực thể với các cột / thuộc tính này: ID vai trò, ID hoạt động, ResourceID. Theo cách đó, các hoạt động x kết hợp tài nguyên được gán trực tiếp cho một vai trò, thay vì được nạp vào một quyền được gán cho một vai trò. Nó loại bỏ một thực thể. Thực sự không cần một bảng cấp phép không phân biệt vai trò riêng biệt, trừ khi bạn muốn xác định trước những kết hợp quyền nào được phép và những quyền nào không được phép.


Trước hết, tôi hoàn toàn đồng ý với "vai trò" thay vì "người dùng" chỉnh sửa. Đó cũng là điều tôi muốn nói. Bây giờ, điều là tôi cũng muốn liên kết các tài nguyên với các hoạt động. Ví dụ: tài nguyên hợp đồng có một hoạt động như upload_file. Vì vậy, điều tôi không muốn là hoạt động upload_file cũng xuất hiện trong một tài nguyên khác không có hoạt động upload_file như nhà cung cấp (tài nguyên khác) khi quản trị viên gán quyền cho vai trò.
imran.razak

12

Tôi sẽ không sử dụng hoặc thực hiện RBAC. Thay vào đó tôi sẽ sử dụng ABAC. Hãy để tôi giải thích...

  • RBAC hoặc kiểm soát truy cập dựa trên vai trò là về quản lý người dùng và phân công vai trò. Trong RBAC, bạn có thể nói rằng Alice là một người quản lý. Bạn có thể xác định quyền tĩnh cùng với đó. Chẳng hạn, một người quản lý có thể phê duyệt các khoản vay. Vì vậy, có một liên kết từ Alice đến người quản lý để phê duyệtLoan như một sự cho phép. Có rất nhiều hệ thống sẽ cho phép bạn làm điều đó để bạn không cần phải thực hiện các bảng của riêng mình. Ngay cả LDAP cũng hỗ trợ cho các bộ RBAC giới hạn. Điều đó là ổn miễn là bạn có một bộ vai trò và quyền tương đối nhỏ. Nhưng nếu bạn muốn tính đến các quyền cụ thể như trường hợp của bạn thì sao? Xem, xóa, chèn? Nếu bạn muốn tính đến các mối quan hệ thì sao?
  • ABAC hoặc kiểm soát truy cập dựa trên thuộc tính là về ủy quyền chi tiết, dựa trên chính sách. Với ABAC, bạn có thể sử dụng các vai trò như được xác định trong RBAC và viết chính sách, vd
    • Người quản lý có thể xem tài liệu trong bộ phận của họ
    • Nhân viên có thể chỉnh sửa tài liệu họ sở hữu

Trong câu hỏi của bạn, về cơ bản bạn đã xác định mô hình thông tin. Các đối tượng của bạn và thuộc tính của chúng, ví dụ như người dùng (tên, mật khẩu, bộ phận ...); một đối tượng (ví dụ như một hợp đồng) và như vậy.

Mô hình thông tin

Do đó, trong ABAC, bạn sẽ tách hoàn toàn mã / logic ứng dụng khỏi logic ủy quyền, sau đó được lưu trữ dưới dạng chính sách sử dụng các thuộc tính. Bản thân các quyền được lưu trữ ngay trong chính sách (xem ví dụ ở trên). Kiến trúc triển khai ABAC trông như sau

Kiến trúc kiểm soát truy cập dựa trên thuộc tính

Vấn đề là nếu bạn thực hiện một cách tiếp cận ABAC, bạn viết các chính sách cho ABAC (trong XACML hoặc ALFA - có rất nhiều công cụ cho việc đó) và bạn không bao giờ phải điều chỉnh RBAC hoặc mã tùy chỉnh thực hiện lại hoặc kiểm soát truy cập.


1
Trong ví dụ về chính sách của bạn, nó nói rằng Người quản lý có thể xem tài liệu trong bộ phận của họ. Có nghĩa là hệ thống sẽ có các quyền, vai trò và loại tài nguyên được xác định trước?
imran.razak

Không. Điều đó có nghĩa là bạn sẽ có thứ gì đó (LDAP? Bảng?) Liên kết người dùng (Alice) với vai trò của cô ấy (người quản lý ...). Sau đó, bạn sẽ có một bảng chứa siêu dữ liệu tài liệu (thường là một bảng trong ứng dụng bạn đang bảo vệ). Bản thân quyền (xem, chỉnh sửa, xóa) được lưu trữ trong chính sách.
David Brossard
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.