Nguyễn Văn Thanh

2.8. Mô hình hợp nhất

Các ràng buộc có thể được áp dụng tới chính các hệ thống role có thứ bậc, như được chỉ ra bởi mũi tên đậm tới RH trong Hình 2.1(b). Hệ thống role thứ bậc được yêu cầu của sự chia ra từng phần.

Ràng buộc này là cốt lõi của mô hình. Việc thêm và các ràng buộc có thể giới hạn số các role của người cấp cao (hay người cấp thấp) mà role nhất định có thể có. Hai hay nhiều role có thể được ràng buộc để không có sự phổ biến role của người cấp cao (hay người cấp thấp). Những loại này của các ràng buộc là hữu ích trong hoàn cảnh nơi mà việc xác thực thay đổi hệ thống role có thứ bậc được chuyển giao, nhưng trưởng security officer chuyển toàn bộ các loại trong thay đổi được làm.

Sự ảnh hưởng lẫn nhau một cách tế nhị xuất hiện giữa các ràng buộc và các hệ thống cấp bậc. Giả sử role của Test Engineer và Programmer được khai báo loại trừ lẫn nhau trong ngữ cảnh của Hình 2.3(b). Role là Project Supervisor vi phạm sự loại trừ lẫn nhau này. Trong một vài trường hợp như một sự vi phạm một ràng buộc loại trừ lẫn nhau bởi role của một người cấp cao có thể được chấp nhận, trong khi các trường hợp khác là không thể. Chúng tôi cảm thấy các mô hình không nên ngoài một hay các khả năng khác. Một hoàn cảnh giống như xảy ra với các yếu tố ràng buộc. Giả sử một user có thể được gán nhiều nhất một role. Liệu việc gán tới role test engineer trong Hình 2.3(b) có vi phạm ràng buộc này? Nói theo cách khác, các yếu tố ràng buộc chỉ áp dụng trực tiếp tới các thành viên và chúng xúc tiến để các thành viên thừa kế?

Hệ thống có cấp bậc trong Hình 2.3(c) miêu tả các ràng buộc có ích trong sự thể hiện của các role riêng tư như thế nào. Trong một vài trường hợp role là Test Engineer0, Programmar0 và Project Supervisor có thể được khai báo loại trừ lẫn nhau. Bởi vì những điều này không phổ biến trong các người cấp cao cho những role này, không có sự xung đột. Trong các role riêng tư chung sẽ không xó các người cấp cao thông thường với nhiều role khác nhau bởi vì chúng là những yếu tố toàn diện nhất trong hệ thống cấp bậc. Sự loại trừ lẫn nhau của các role riêng tư luôn luôn được chỉ rõ ngoài sự xuất hiện của các xung đột. Sự chia sẻ các bản sao của các role riêng tư có thể được riêng tư có thể được khai báo để có một yếu tố ràng buộc toàn diện nhất không của thành viên nào. Với cách này Test Engineer phải được gán tới role là Test Engineer0. Role là Test Engineer phục vụ như một phương tiện của sự chia sẻ permission với role là Project Supervisor.

2.9. Các mô hình quản lý

Giả sử rằng tất cả các thành phần của RBAC dưới sự điều khiển trực tiếp của một security officer. Trong các hệ thống lớn số các role có thể là hàng trăm hay hàng nghìn. Việc quản lý các role này và mối tương quan của chúng là một nhiệm vụ rất khó khăn mà thường được tập trung cao và được ủy quyền tới một đội quản lý nhỏ.

Bởi vì lợi thế chính của RBAC là việc quản lý các permission dễ dàng hơn, nó là đặc điểm tự nhiên để hỏi RBAC có thể được dùng để quản lý chính RBAC như thế nào? Tin tưởng rằng người dùng RBAC để quản lý RBAC sẽ như là một nhân tố quan trọng trong thành công của RBAC. Ở đây chúng tôi chỉ có thể chạm vào một vài vấn đề lớn.

ISO phát triển một số việc quản lý an toàn liên quan tới các chuẩn và tài liệu. Mô hình ISO là hướng đối tượng và bao gồm một hệ thống có thứ bậc dựa trên chính sách ngăn chặn (một thư mục chứa các file và một file chứa các bản ghi)

Các role có thể được kết hợp trong hướng tiếp cận ISO.

Có một chặng đường dàimô hình truyền thống cho sự truyền bá của các quyền truy cập, nơi mà quyền tới sự truyền bá các quyền được điều khiển bởi các quyền điều khiển đặc biệt. Giữa gần đây nhất và được phát triển nhất của loại mô hình ma trận truy cập của Sandhu [4]. Trong khi thông thường rất khó để phân tích những hậu quả của sự công bằng đơn giản của các quy luật cho sự truyền bá của các quyền, những mô hình này cho biết rằng những nguồn gốc đơn giản có thể được kết hợp tới sản lượng rất mềm dẻo và các hệ thống rất có ý nghĩa.

Trong ví dụ của công việc trên việc quản lý RBAC bởi Morlet và Sloman người mà định nghĩa công bằng mô hình phức tạp dựa trên các miền role, người làm chủ, người quản lý và quản trị bảo mật. Trong sự xác thực công việc của họ không được điều khiển hay được ủy nhiệm từ một điểm tập trung, nhưng đúng hơn là sự thương lượng giữa các nhà quản lý độc lập mà chỉ có một trách nhiệm giới hạn trong mỗi người.

Mô hình quản lý RBAC được minh họa trong Hình 2.6. Một nửa phần trên của hình này về bản chất giống với Hình 2.1(b). Các ràng buộc trong Hình 2.6 được áp dụng tới tất cả các thành phần. Nửa dưới của Hình 2.6 là ánh xạ của nửa trên cho các role quản lý và các permission quản lý. Nó được mong đợi mà các role quản lý AR và các quyền quản lý AP được tách biệt ra giữa các role thông thường R và các permission P. Mô hình hiển thị các permission có thể được gán tới các role và các permission quản lý có thể chỉ được gán tới các role quản lý.

Điều này gắn liền các ràng buộc.

Một nửa trên của Hình 2.6 có thể một dãy trong sự tinh tế qua RBAC0, RBAC1, RBAC2, và RBAC3. Nửa dưới có thể dãy đơn giản trong sự tinh tế qua ARBAC0, ARBAC1, ARBAC2, and ARBAC3 nơi mà A chứng tỏ sự quản lý.

Nhìn chung sẽ trông đợi mô hình quản lý tới mô hình đơn giản hơn chính mô hình RBAC. Do vậy ARBAC0 có thể được dùng để quản lý RBAC3, nhưng dường như không hợp lý khi dùng ARBAC3 để quản lý RBAC0.

Nó cũng quan trọng để nhận ra các ràng buộc có thể cắt cả trên và dưới của Hình 2.6. Chúng tôi xác nhận một ràng buộc gán liền mà các permission có thể được gán tới các role và các permission quản lý có thể tới các role quản lý. Nếu các role quản lý loại trừ lẫn nhau với sự lưu tâm tới các role thông thường, có một vị trí mà người quản lý bảo mật có thể quản lý RBAC nhưng không dùng các đặc quyền của chúng.

Làm sao để quản lý sự điều hành của hệ thống có thứ bậc? Một nguyên tắc có thể được xây dựng một cấp độ 2 trong việc quản lý hệ thống có thứ bậc tới việc quản lý cấp độ 1 và trên nó. Chúng tôi cảm thấy chỉ có một cấp độ 2 của hệ thống quản lý có thứ bậc là không cần thiết. Sau đây việc quản lý của quản lý hệ thống có thứ bậc được chuyển tới một security officer. Điều này là chấp nhận được với một tổ chức đơn hay một đơn vị quản lý đơn trong một tổ chức. Vấn đề đặt ra là những đơn vị này ảnh hưởng không trực tiếp được lấy ra trong mô hình. Xác thực sự quản lý trong RBAC có thể được nhìn nhận như khả năng để thay đổi sự gán lên user, gán lên quyền sử dụng và quan hệ hệ thống role có thứ bậc. Trong một mô hình quản lý các permission mà được xác thực các hoạt động quản lý này phải được định nghĩa rõ ràng. Chính xác bản chất các quyền truy cập là sự cài đặt cụ thể, nhưng bản chất chung của chúng là giống nhau.

Một trong những vấn đề chính trong mô hình quản lý là phạm vi việc xác thực quản lý được trao cho như thế nào trong các role quản lý. Để minh họa cho việc xem xét này hệ thống có thứ bậc hiển thị trong Hình 2.4(a). Hệ thống quản lý có thứ bậc trong Hình 2.4(b) hiển thị một role của security officer trưởng (CSO) mà người cấp cao hơn tới ba role của security officer SO1, SO2 và SO3. Mối quan tâm tới phạm vi của vấn đề mà các role trong Hình 2.4(a) có thể được được quản lý bởi các role của Hình 2.4(b). Chúng tôi sẽ nói role CSO có thể quản lý tất cả các role trong Hình 2.4(a). Giả sử SO1 quản lý công việc T1. Nhìn chung không muốn SO1 tự động thừa kế các khả năng quản ly role cấp thấp P. Bởi vậy phạm vi của SO1 có thể được giới hạn hoàn toàn tới T1. Đơn giản là, phạm vi của SO2 có thể được giới hạn tới T2.

Thừa nhận rằng SO3 có thể quản lý trọn vẹn các dự án con gồm có S3, T3, T4 và P3. Phạm vi của SO3 là giới hạn bởi S3 ở trên đỉnh và P3 ở dưới.

Nhìn chung, mỗi role quản lý sẽ được ánh xạ tới một vài tập hợp con của role hệ thống có cấp bậc có trách nhiệm cho ánh xạ này. Có các diện mạo khác của sự quản lý mà cần được phạm vi hóa. Cho ví dụ, SO1 có thể thêm các user tới role T1 nhưng việc di chuyển của chúng yêu cầu CSO tới hành động. Hơn nữa, cần tới phạm vi không chỉ các role một sự quản lý các role, mà lại các permission và user. Điều này quan trọng để điều khiển thay đổi trong chính hệ thống role có cấp bậc. Ví dụ, bởi vì SO3 quản lý các hệ thống có thứ bậc con giữa S3 và P3, SO3 có thể được xác thực tới việc thêm vào các nhiệm vụ truyền thống tới các dự án con.