Các mô hình một họ tham chiếu

2.5. Mô hình cơ sở

Một số tài liệu về kiểm soát truy cập nói về permission từ chối “negative permission”. Cái này từ chối, chứ không cho phép truy cập. Trong bài, việc từ chối truy cập được gọi là sự hạn chế chứ không phải là một permission từ chối.

Bản chất của permission phụ thuộc nhiều vào các chi tiết thực hiện của một hệ thống mà loại hệ thống đó là gì. Một mô hình khái quát của kiểm soát truy cập do đó phải coi các permission như các biểu tượng không ngắt quãng về mặt nào đó. Mọi hệ thống đều bảo vệ các object trừu tượng mà nó thực hiện. Do đó, một hệ điều hành bảo vệ các thứ như file, thư mục, thiết bị, và các cổng và các thao tác như đọc, viết và thực thi. Một hệ thống quản lí cơ sở dữ liệu có quan hệ sẽ bảo vệ các mối quan hệ, các tipple, thuộc tính và các hiển thị với các thao tác SELECT, UPDATE, DELETE, và INSERT. Một ứng dụng kế toán sẽ bảo vệ các tài khoản và các sổ cái với các thao tác debit (ghi bên nợ), credit (ghi bên có), transfer (chuyển khoản), create-account (tạo tài khoản), và delete-account (xóa tài khoản). Thao tác credit (ghi vào bên có) đó nên được phân cho một role chứ không nên bắt buộc phải phân cho role đó cả thao tác debit (ghi vào bên nợ) nữa.

Các permission có thể áp dụng cho một object hay nhiều object. Ví dụ, một permission có thể cụ thể như đọc lệnh truy cập vào một file riêng biệt nào đó hoặc có thể là chung chung như đọc lệnh truy cập tới tất cả các file thuộc một bộ phận nào đó. Các permission cá nhân được cho vào một permission chung , do đó chúng có thể được giao với tư cách một đơn vị riêng biệt. Việc làm này phụ thuộc nhiều vào sự cài đặt.

Mỗi session là một tham chiếu của một user tới những role có thể, ví dụ, một user thiết lập một session khi mà user kích hoạt một vài tập con của các role mà anh ấy hay cô ấy là một thành viên. Mũi tên hau đầu từ session to R trong Hình 2.1(b) cho biết những role được kích hoạt cùng lúc. Permission có thể được user kết hợp các permission từ tất cả các role được kích hoạt trong session đó. Mỗi session được kết hợp với một đơn người dùng, như cho biết bởi mũi tên một đầu từ session tới U trong Hình 2.1(b). Sự kết hợp này lưu giữ hằng cho cuộc sống của một session.

• 
  U, R, P và S (user, roles, permission và session riêng biệt)
  
• 
  PA P x R, một quan hệ nhiều – nhiều gán cho permission tới role.
  
• 
  UA U x R, một quan hệ nhiều – nhiều gán cho user tới role.
  
• 
  user: SU, một chức năng ánh xạ mỗi session s_i tới một user user(s_i) (Hằng số cho thời gian tồn tại của session) và
  
• 
  roles: S2^R, một chức năng tham chiếu mỗi session s_i tới một sự thiết lập roles roles(si) { r | (user(s_i),r))UA}.
  

Chúng tôi mong chờ mỗi role được gán ít nhất một permission và mỗi user được gán ít nhất một role. Với mô hình này, tuy nhiên, không yêu cầu điều này.

Như đã được nói ở trên, RBAC0 xử lý các permission như những ký hiệu chưa được thông dịch bởi vì bản chất rõ ràng của một permission là sự cài đặt và sự phụ thuộc hệ thống. Các permission được sửa đổi để thiết lập U, R và P và quan hệ PA và UA được gọi bởi các permission quản lý. Những điều này sẽ được thảo luận sau trong mô hình quản lý cho RBAC. Còn bây giờ thừa nhận rằng chỉ có một mình nhân viên bảo vệ có thể thay đổi những thành phần này.

Những session dưới sự điều khiển của những user riêng lẻ. Như những mô hình có liên quan, một user có thể tạo ra một session và chọn để kích hoạt một vài tập con của những role của user. các role hoạt động trong một session có thể đuợc thay đổi trong sự thận trọng của user. Session giới hạn bởi năng lực của user. Một vài hệ thống sẽ giới hạn một session nếu nó không hoạt động động trong thời gian quá dài. Nói đúng ra, đây là một ràng buộc và hợp lý trong RBAC2.

Một trách nhiệm là một nghĩa vụ trên một phần của user để thi hành một hay nhiều nhiệm vụ, nói chung là rất cần thiết cho các hoạt động trơn tru của một tổ chức. Trong trách nhiệm của chúng tôi được xem như một khái niệm nâng cao mà không thuộc trong RBAC0. Chúng tôi đã chọn không kết hợp trách nhiệm trong mô hình nâng cao và cảm nhận sự không kết hợp các khái niệm giống như trách nhiệm trong mô hình điều khiển truy cập yêu cầu nghiên cứu trong tương lai. Một cách tiếp cận là xử lý chúng giống như với các permission. Những cách tiếp cận khác có thể là cơ sở cho mô hinhg điều khiển truy cập mới giống như nhiệm vụ dựa trên sự xác thực [4].