Khi đọc về ACL và RBAC tôi dường như hiểu nó một cách dễ dàng - có tên người dùng hoặc vai trò được cấp quyền truy cập vào một tài sản. Tôi cũng có thể thấy làm thế nào tôi có thể thực hiện những điều đó.

tức là hình ảnh này cung cấp cho một cái nhìn rõ ràng về ACL và RBAC cho tôi (như trong tôi có thể tiếp tục và bảng cơ sở dữ liệu thiết kế dựa trên trên): (Hình ảnh lịch sự của pressbooks )

Những gì tôi đang đấu tranh với là ABAC. Nhiều hình ảnh tôi tìm thấy cho đến nay là gợn sóng bằng tay hoặc quá phức tạp hoặc đề nghị sử dụng thực thể bên ngoài của bên thứ 3 thực hiện Ủy quyền. Hoặc đưa ra các ví dụ thuộc tính kỳ lạ tôi không hoàn toàn chắc chắn làm thế nào để sử dụng.

Ví dụ bắt đầu

Vì vậy, hãy để tôi bắt đầu với một cái gì đó trong cuộc sống thực. Nói rằng tôi có một công ty với 70-200 người. Và tài sản của tôi để bảo vệ là một trang web với nhiều trang khác nhau. Tôi muốn cho phép một số người truy cập vào một số tài sản nhất định.

Ví dụ: tôi muốn một người Lesliecó quyền truy cập vào một trang web được gọi Price Managervà cho phép cô ấy chỉ quản lý giá cho Travelnhóm giá trên trang đó, nhưng không thể quản lý giá cho Productnhóm trên cùng một trang. Làm thế nào tôi có thể thực hiện điều này bằng cách sử dụng ABAC?

Trêu chọc cho đến nay, tôi đoán là tôi có thể gán Lesliemột số thuộc tính (nhưng thuộc tính nào và những thuộc tính này là gì?) Và sau đó có một bảng cơ sở dữ liệu lưu trữ các thuộc tính đó. Sau đó, tôi có thể thiết kế một công cụ xem xét các thuộc tính đó (nhưng không xem Leslielà "Vai trò" như được thực hiện trong RBAC) và quyết định từ đó có cấp quyền truy cập vào trang hay không. Làm thế nào mà động cơ sẽ trông như thế nào? Là một khối đơn giản nếu / khác? Thứ gì khác?

Điều gì xảy ra nếu Leslie sau đó thay đổi vị trí của mình và ai đó cần thay đổi quyền truy cập của cô ấy? Nó sẽ trông như thế nào nếu cô ấy cần phải có quyền truy cập Productvà thu hồi Travel? Nó sẽ được mã hóa như thế nào nếu cô ấy cần phải thu hồi quyền truy cập vào Price Managertrang hoàn toàn và do đó không còn có quyền truy cập vào cả Travel, hoặc Product?

Tài sản trong trường hợp của tôi, chỉ để phục hồi lại Price Manager, và người dùng có thể truy cập các nhóm giá khác nhau trên trang đó, chẳng hạn như Travelgiá cả, Productgiá cả, v.v.

Những gì tôi đang tìm kiếm là một lộ trình đầy đủ hợp lý để làm rõ các chi tiết và hướng tới việc thực hiện đến nơi tôi có thể thực hiện và thực hiện nó mà không cần đoán. tức là nó có thể được hoàn thành về mặt khái niệm và / hoặc có ví dụ cụ thể để tôi có thể hình dung cấu trúc cơ sở dữ liệu, v.v.

Tiền thưởng: ABAC có phải là một cách thích hợp cho nhu cầu cấp phép tương đối nhỏ, tức là quản lý 70-200 người và truy cập vào khoảng 150 - 450 tài sản? Thay vào đó, sẽ tốt hơn nếu gắn bó với ACL / RBAC?

Việc triển khai ABAC phức tạp hơn ACL / RBAC. Một số khung thậm chí cung cấp cho bạn các bit của cơ sở hạ tầng để đối phó với cái sau. Nếu người và tài sản có thể được nhóm theo một số vai trò / danh mục tương đối nhỏ và cố định thì có lẽ tốt nhất nên gắn bó với ACL / RBAC. Nếu quyền khác nhau giữa người này với người khác thì ABAC có thể cung cấp giải pháp tốt hơn và linh hoạt hơn.

Nếu bạn chọn đi xuống đường dẫn ABAC, điều đầu tiên bạn cần làm là dành thời gian đọc và hiểu tiêu chuẩn XACML . Các ví dụ được cung cấp trong tài liệu sử dụng cú pháp tương thích XACML và ban đầu chúng hơi khó nhai. Tôi đoán bạn không muốn thực hiện một giải pháp tương thích tiêu chuẩn nên bạn chỉ cần những ý tưởng chung từ nó.

Các khái niệm

XACML xoay quanh 4 khái niệm và thuộc tính của chúng: chủ thể , hành động , tài nguyên và môi trường . Có một vài điều nữa, nhưng đây là những điều quan trọng nhất. Mọi thứ khác được xây dựng trên đầu của họ. Nếu tôi đặt câu với những khái niệm này thì đó có thể là một điều gì đó dọc theo dòng: chủ thể thực hiện các hành động trên tài nguyên trong một môi trường nhất định . Áp dụng điều này vào kịch bản của bạn sẽ chuyển thành một cái gì đó như:

• Leslie mở trang web quản lý giá.
• Leslie tạo ra một mức giá du lịch bằng cách sử dụng trang web quản lý giá.

Bộ sưu tập thuộc tính

Điều đầu tiên chúng ta cần làm là thu thập các thuộc tính có liên quan của các khái niệm đã nêu ở trên. Lý tưởng nhất là bạn không nên gán bất kỳ thuộc tính cụ thể nào vì XACML cố gắng không phô trương và chỉ dựa vào những gì hệ thống cung cấp một cách tự nhiên. Và vì vậy chúng tôi có:

Môn học

Bất kỳ diễn viên nào, có thể là một người hoặc một dịch vụ, trong hệ thống của bạn. Chủ đề của chúng tôi là Leslie. Những thuộc tính nào được yêu cầu để xác định duy nhất Leslie? Có lẽ một số những điều sau đây: first name, last name, e-mail, ssn, company id, position(s).

Hoạt động

Bất kỳ hành động được thực hiện bởi các đối tượng. Có thể là các hoạt động CRUD tiêu chuẩn hoặc một cái gì đó phức tạp hơn. Hành động của chúng tôi là open/viewvà create. Các thuộc tính cho những hành động này có thể khác nhau dựa trên khung ứng dụng web bạn đang sử dụng. Chúng ta sẽ nói nhiều hơn về điều này khi chúng ta có được tài nguyên.

Nguồn

Khá tự giải thích. Tài nguyên của chúng tôi là price manager page, travel pricesvà the newly created price. Có thể có nhiều hơn, nếu bạn thực sự muốn. Bạn có thể muốn ẩn các hành động mà người dùng không thể thực hiện. Ví dụ. những create price buttoncó thể là một nguồn tài nguyên có thể được hiển thị / ẩn dựa vào việc người dùng có quyền truy cập để tạo ra giá. Vì cách duy nhất để người dùng xem danh sách giá có thể là thông qua trang này, có lẽ nên thực thi ủy quyền ở cấp độ này thay vì tiếp tục xuống ngăn xếp.

Truy cập vào tài nguyên là phức tạp nhất để thực hiện, đặc biệt là những tài nguyên đến từ cơ sở dữ liệu. Tùy chọn hạt mịn hơn là bảo mật cấp hàng. Một số cơ sở dữ liệu có một mức độ hỗ trợ nhất định cho nó. Một số người triển khai XACML đã tạo ra một siêu bộ SQL. Điều này thực sự phụ thuộc vào nhu cầu ủy quyền của bạn, nhưng điều bạn không muốn làm là lấy mọi thứ từ một bảng và sau đó quyết định những gì sẽ hiển thị. Bạn có thể nhóm tài nguyên theo các nhóm quyền, trừu tượng chúng đằng sau API và thực thi ủy quyền tại các điểm cuối API.

Môi trường

Tôi không thể định nghĩa đúng (XACML cũng không có định nghĩa đúng) nhưng giả sử đó là "bong bóng" trong đó tất cả điều này xảy ra. Điều này bao gồm: web application, web server, operating system, browser, office. Bạn có thể trích xuất các thuộc tính như: ip address, time of day, user locale, user agent, operating system version. Bạn có thể sử dụng những thứ này để chặn truy cập của người dùng từ các môi trường không được ứng dụng của bạn hỗ trợ (ví dụ: trình duyệt cũ, hệ điều hành cũ, máy tính bên ngoài mạng của bạn, truy cập ngoài giờ làm việc).

Yêu cầu ủy quyền

Khi chúng tôi đã thu thập tất cả các thuộc tính cần thiết, chúng tôi tập hợp chúng trong một yêu cầu ủy quyền và chuyển tiếp nó đến một thực thể có thể đưa ra quyết định ủy quyền dựa trên các giá trị của các thuộc tính này. Trong XACML, nơi bạn thu thập các thuộc tính này và thi hành các quyết định được đưa ra sau đó được gọi là điểm thực thi chính sách (PEP) và các quyết định đưa ra điểm được gọi là điểm quyết định chính sách (PDP). Các vị trí mà từ đó các giá trị thuộc tính được lấy được gọi là điểm thông tin chính sách s (PIP). PEP, PDP và PIP có thể là một phần trong ứng dụng của bạn, chúng có thể là các hệ thống bên ngoài. Bạn có thể tìm thấy một sơ đồ về cách chúng giao tiếp với nhau trong tiêu chuẩn XACML.

Quá trình quyết định

Quá trình ra quyết định dựa trên các quy tắc . Các quy tắc có thể được nhóm thành các chính sách có thể được nhóm lại thành các bộ chính sách . Mỗi người trong số họ có một mục tiêu . Mục tiêu được sử dụng để quyết định nếu bất kỳ quy tắc nào áp dụng cho yêu cầu ủy quyền. Hãy nghĩ về nó như một bộ lọc. Mục tiêu chứa các điều kiện được xây dựng bằng cách sử dụng tên và giá trị thuộc tính. Ví dụ: các quy tắc cho ứng dụng của bạn có thể được nhóm thành một cái gì đó như:

Ứng dụng web (bộ chính sách)
| - đích: tên ứng dụng == "Ứng dụng web"
`- Phiên bản 1.0 (bộ chính sách)
    | - mục tiêu: phiên bản ứng dụng == "1.0"
    `- Xem trình quản lý giá (chính sách)
        | - mục tiêu: web-page-name == "trình quản lý giá" && action-name == "view"
        `- Leslie có thể xem trình quản lý giá (quy tắc)
            | - mục tiêu: tên chủ đề == "Leslie"
            `- sự cho phép: cho phép

PDP sẽ khớp mọi thứ trong tập hợp trên với các giá trị thuộc tính trong yêu cầu cấp phép. Điều gì xảy ra nếu không có quy tắc phù hợp với nó tùy thuộc vào việc triển khai PDP của bạn. Khi PDP đã đưa ra quyết định ( allow, denyhay not-applicable) nó sẽ gửi nó trở lại với PEP có tác dụng khi nó bằng cách cấp hoặc từ chối truy cập vào các tài nguyên. Cùng với phản hồi, PDP có thể gửi danh sách obligationsvà advicesPEP phải hoặc phải hoàn thành trong quy trình thực thi. Tùy thuộc vào cách các quy tắc được lưu trữ (tệp văn bản hoặc cơ sở dữ liệu), quản trị viên có thể sử dụng trình soạn thảo văn bản tiêu chuẩn hoặc ứng dụng chỉnh sửa tùy chỉnh để thay đổi các quy tắc này khi thấy phù hợp. Truy cập thu hồi của Leslie tới người quản lý giá sơ yếu lý lịch chỉ đơn giản là thay đổi sự cho phép từ allowđếndeny, được cấp PEP thực hiện công việc của mình.

Thực thi

Điều này phụ thuộc nhiều vào ngăn xếp công nghệ của bạn. Một số khung web có các điểm thực thi tự nhiên (ví dụ: ASP.NET MVC có các bộ lọc thuộc tính). Các lớp kinh doanh của bạn có thể phải xác định các điểm thực thi đó. Tôi thấy việc áp dụng thực thi tại các điểm cuối dịch vụ (nghĩ microservice) hoặc cấp độ UI dễ dàng hơn.

Lợi ích khác

Một tác dụng phụ tuyệt vời của việc thực hiện điều này là bạn kết thúc với một lộ trình kiểm toán khá phong phú có thể được sử dụng cho các mục đích khác.