Nguyễn Văn Thanh



tải về 296.99 Kb.
trang6/11
Chuyển đổi dữ liệu05.09.2016
Kích296.99 Kb.
#31705
1   2   3   4   5   6   7   8   9   10   11

2.7. Các ràng buộc


Mô hình RBAC2 giới thiệu khái niệm của ràng buộc được hiển thị trong Hình 2.1(b). Mặc dù được gọi trong mô hình RBAC1 và RBAC2, đây không thực sự một ngụ ý của sự tiến triển. Mỗi ràng buộc hay hệ thống thứ bậc các vai trog có thể được giới thiệu đầu tiên. Điều này được chỉ ra bởi sự liên kết có một không hai giữa RBAC1 và RBAC2 trong Hình 2.1(a).

Các ràng buộc là một diện mạo quan trọng của RBAC và thỉnh thoảng tranh luận cho nguồn gốc cho sự thúc đẩy của RBAC. Một ví dụ phổ biến mà các role tháo rời qua lại lẫn nhau, giống như quản lý việc mua và quản lý tài khoản trả. Trong hầu hết các tổ chức (ngoại trừ rất nhỏ) giống như các nhân riêng lẻ sẽ không được phép để là thành viên của cả hai role, bởi vì việc tạo ra một khả năng cho sự gian lận. Đây là một nguyên tắc nổi tiếng và được ưa chuộng được gọi sự ngăn cách các trách nhiệm.

Những ràng buộc là một cơ chế quyền lực đặt cấp cao hơn chính sách của tổ chức. Điều chắc chắn là các role được khai báo loại trừ lẫn nhau, ở đó cần quan tâm quá nhiều về nhiệm vụ của từng user riêng biệt tới các role. Những hoạt động sau đó có thể được ủy nhiệm và chuyển giao ngoài sự sợ hãi của sự thỏa hiệp toàn bộ cơ chế các đối tượng của tổ chức. Vì vậy, việc quản lý RBAC được kiểm soát toàn bộ bởi security officer, những ràng buộc là hữu ích cho sự tiện lợi, nhưng hiệu quả cùng lúc có thể lớn hơn giành được bởi sự quan tâm đúng đắn của phần việc của security officer. Tuy nhiên, nếu sự quản lý của RBAC được chuyển giao, những ràng buộc trở thành một cơ cấu bởi security officer có chức vụ cao hơn có thể giới hạn khả năng của user mà có thể thực hiện đặc quyền quản lý. Nó cho phép chief security officer (trưởng nhân viên an ninh) thiết lập ngoài phạm vi rộng của việc chấp nhận và lạm dụng như yêu cầu bắt buộc trên các security officer khác và những user mà tham gian trong việc quản lý RBAC.

Với sự quan tâm tới những ràng buộc RBAC có thể được áp dụng tới quan hệ UAPAuser và các chức năng của vai trong với các session khác nhau. Các ràng buộc được khẳng định mà, được áp dụng tới các quan hệ và các chức năng, trả về một giá trị có thể chấp nhận được hay không thể chấp nhận được. Các ràng buộc có thể được xem như các câu trong một vài ngôn ngữ chính thức thích hợp. Bằng trực giác, các ràng buộc được xem xét tốt hơn theo từng loại của chúng và bản chất



Sau đây là định nghĩa bên dưới.

Định nghĩa 3: RBAC2 không được thay đổi từ RBAC0 ngoại trừ việc yêu cầu có một tập hợp của các ràng buộc mà quyết định dù giá trị của các thành phần khác nhau của RBAC0 có được chấp nhận hay không. Chỉ các giá trị được chấp nhận sẽ được cho phép. Xem xét việc cài đặt chung gọi cho những ràng buộc đơn giản mà có thể kiểm tra hiệu quả và làm cho có hiệu lực. May mắn thay, trong RBAC các ràng buộc đơn giản có thể đi một cách lâu dài.

Hầu như tất cả, các ràng buộc áp dụng liên quan tới trách nhiệm của user có một bản sao mà áp dụng liên quan tới trách nhiệm permission. Vậy thì thảo luận các ràng buộc trên hai thành phần song song.

Hầu hết các ràng buộc được đề cập đến trong ngữ cảnh của RBAC là các role loại trừ lẫn nhau. Cũng giống như user được gán nhiều nhất một role trong sự thiết lập loại trừ lẫn nhau. Điều này hỗ trợ những nhiệm vụ tách rời nhau. Sự cung cấp của ràng buộc này yêu cầu ít sự tiến triển. Hai ràng buộc trên permission nhiệm vụ khó nhận sự chuyển giao trong tài liệu. Thực tế là, một ràng buộc loại trừ lẫn nhau trên permission nhiệm vụ có thể cung cấp thêm sự chắc chắn cho các nhiệm vụ tách rời nhau. Hai ràng buộc yêu cầu mà các nhiệm vụ giống nhau được gán tới nhiều nhất một role trong sự thiết lập loại trừ lẫn nhau. Xem xét hai role loại trừ lẫn nhau, quản lý tài khoản và quản lý mua. Sự loại trừ lẫn nhau về mặt UA chỉ định mà một cá nhân riêng lẻ không thể là thành viên của cả 2 role. Sự loại trừ lẫn nhau về mặt PA chỉ định mà các permission giống nhau không thể được gán tới 2 role.

Cho ví dụ, permission đưa ra kiểm tra không nên được gán tới cả 2 role. Thông thường như một permission sẽ được gán tới role quản lý các tài khoản. Các ràng buộc loại trừ lẫn nhau trên PA sẽ ngăn chặn permission dù cố ý hay không cố ý, được gán tới role quản lý việc mua. Trực tiếp hơn nữa, các ràng buộc loại trừ trên PA là có ích để giới hạn sự phân phối các permission. Cho ví dụ, điều này có thể không quan trọng khi role A hay role B đưa ra tín hiệu xác thực cho một tài khoản đặc biệt, nhưng có thể yêu cầu chỉ một trong 2 role với permission này. Thông thường thành viên của user trong sự kết hợp khác nhau của các role có thể được cho rằng chấp nhận hay không. Như vậy nó có thể được chấp nhận cho một người dùng là thành viên của roleProgrammerrole một Tester trong các dự án khác nhau, nhưng không được chấp nhận để nhận cả 2 role trong cùng một dự án. Tương tự cho việc gán permission.

Một ví dụ khác của ràng buộc gán cho user là một role có thể có một số lượng thành viên tối đa. Cho trường hợp, chỉ có một người trong role của chủ tọa của một văn phòng. Tương tự, số lượng của các role tới từng user riêng lẻ có thể được hạn chế. Chúng tôi gọi các yếu tố ràng buộc. Do đó, số các rolepermission được gán có thể có các yếu tố ràng buộc để điều khiển sự phân phối quyền lực của các permission. Nó có thể được chú ý mà các yếu tố ràng buộc tối thiểu có thể khó để cài đặt. Cho ví dụ nếu có một số tối thiểu user của một role, hệ thống có thể làm gì nếu một trong số họ không xuất hiện? Hệ thống hiểu chuyện này đã xảy ra như thế nào?

Khái niệm tiên quyết của các role được dựa trên một sự tương thích và thích hợp, nhờ đó một user có thể được gán tới role A chỉ khi nếu một user đã là thành viên của một role B. Cho ví dụ, chỉ những người dùng mà role là thành viên của một dự án có thể được gán tới role của việc testing trong dự án đó. Trong ví dụ này role tiên quyết là người có chức vụ thấp tới một role mới là không có thật. Điều kiện giữa các role không thể so sánh được giống như xảy ra trong thực hành. Hai ràng buộc gán trên permission áp dụng nhiều hơn trên role kết thúc của quan hệ PA. Nó có thể có ích, với sự kiên nhẫn, để yêu cầu permission p được gán tới một role chỉ nếu role đó có permission q rồi. Cho trường hợp, trong nhiều hệ thống permission để đọc một file được yêu cầu permission để đọc một thư mục chứa file được chỉ định. Việc gán các mẫu ngoài permission sẽ không hoàn thành.

Các ràng buộc được gán tới user là hiệu quả chỉ nếu phù hợp bên ngoài kiến thức được giữ lại trong việc gán định danh user tới nguời thực sự. Nếu một vài cá nhân riêng lẻ được gán 2 hay nhiều định danh user, sự ngăn cách và các yếu tố điều khiển phá hủy. Phải có sự tương ứng một – một giữa định danh user và người thực sự. Một trách nhiệm tương tự áp dụng tới các ràng buộc permission. Nếu cùng một thao tác được thừa nhận bởi 2 permission khác nhau, hệ thống RBAC không thể thực thi hiệu quả các yếu tố và các ràng buộc riêng biệt.

Các ràng buộc có thể được áp dụng tới các session, và chức năng user và các role kết hợp với một session. Nó có thể chấp nhận cho một user là thành viên của 2 role nhưng user không thể hoạt động cả 2 role cùng lúc. Các ràng buộc khác trên các session có thể giới hạn số các sessionuser có thể hoạt động cùng lúc. Do đó, số các session mà một permission được gán được giới hạn.

Một hệ thống thứ bậc role có thể được xem như một ràng buộc. Ràng buộc này là một permission gán tới role một người có chức vụ thấp phải được gán tới tất cả các role của người có chức vụ cao hơn. Hay tương đương, ràng buộc mà user được gán tới một role của người có chức vụ cao hơn phải được gán tới tất cả các role của người có chức vụ thấp hơn. Trong một số ý nghĩa, RBAC1 là thừa và con của RBAC2. Tuy nhiên, chúng tôi cảm thấy nó thích hợp để đánh giá hiện trạng của hệ thống role có thứ bậc riêng của chúng. Chúng giảm sự ràng buộc chỉ bởi sự giới thiệu thừa của việc gán permission hay gán user. Nó thích hợp hơn để trợ giúp hệ thống thứ bậc trực tiếp hơn gián tiếp bởi cách của gán dư thừa.



tải về 296.99 Kb.

Chia sẻ với bạn bè của bạn:
1   2   3   4   5   6   7   8   9   10   11




Cơ sở dữ liệu được bảo vệ bởi bản quyền ©hocday.com 2024
được sử dụng cho việc quản lý

    Quê hương