Khóa luận Kiểm chứng cơ chế bảo mật dựa trên AST

) { r | (user(si),r))UA}. Hình 2.2: Mô hình RBAC0 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]. 2.6. Role có cấp bậc (a) (b) (c) Hình 2.3: Các ví dụ của Role Hierarchies (a) Role Hierarchies (b) Quản lý Role Hierarchies (c) Sự riêng tư và phạm vi của RoleHình 2.4: Role Hierarchies cho một dự án Mô hình RBAC1 giới thiệu role có thứ bậc (RH), giống như đã trình bày sơ qua trong Hình 2.1. Chúng cũng được cài đặt thông thường trong hệ thống như các role cung cấp. Role có thứ bậc có một nghĩa tự nhiên cho các role có cấu trúc để phản ánh một tổ chức của permission và trách nhiêm. Ví dụ về role có thứ bậc được thấy trong Hình 2.3. Bởi việc quy ước các role nhiều quyền lực hơn được hiện thị phía trên các sơ đồ và các role ít quyền lực hơn phía dưới sơ đồ. Trong Hình 2.3(a) role của người có chức vụ thấp là Health-care provider. Role là Physician là người có chức cao hơn Health-care provider và do đó thừa kế tất cả các permission từ Health-care provider. Thừa kế của permission nói rõ ra, cho ví dụ, trong Hình 2.3(a), role là Primary-care Physician thừa kế permission từ Physician và Health-care provider. Cả Primary-care Physician và Specialist Physician đều thừa kế permission từ role của Physician, nhưng mỗi loại này sẽ có những permission khác nhau được gán trực tiếp tới chúng. Hình 2.3(b) giải thích đa thừa kế của permission, nơi mà role là Project Supervisor thừa kế cả role của Tester và Programmer. Bằng chứng là, những cấp bậc này thứ tự từng phần. Một thứ tự từng phần là một phản thân, bổ ngữ trực tiếp và không đối xứng. Sự thừa kế là phản thân bởi vì một role thừa kế permission riêng của nó, bổ ngữ trực tiếp là một yêu cầu tự nhiên trong ngữ cảnh này, và quy tắc không đối xứng ngoài các role mà thừa kế từ một cái khác và vì thế sẽ không cần thiết. Công thức định nghĩa của RBAC1 được đưa ra bên dưới. Định nghĩa 2 mô hình RBAC1 có những thành phần sau: U, R, P, S, PA, UA, và user không được thay đổi từ RBAC0, RH R x R là một phần thứ tự trên R gọi là role có cấp bậc hay mối quan hệ role có ưu thế hơn, cũng được viết như , và roles : S2R được thay đổi từ RBAC0 để yêu cầu các role (si) { r | (r’ r)[(user(si), r’)UA]}. Hình 2.5: Mô hình tổng quát của RH (RBAC1) Chú ý rằng một user được cho phép tới thiết lập một session với nhiều sự kết hợp của role người chức vụ thấp tới user là thành viên của nó. Hơn nữa, các permission trong một session được gán trực tiếp tới các role của session cũng tốt như việc được gán tới các role của người cấp bậc thấp tới những cái này. Điều này thỉnh thoảng có ích trong thứ bậc để hạn chế phạm vi của thừa kế. Xem xét thứ bậc của Hình 2.3(b) nơi mà role là Project Supervisor là người cấp cao hơn role của cả Tester và Programmer. Bây giờ giả sử rằng Tester mong muốn giữ một vài permission riêng tư tới role của họ và chống lại sự thừa kế của họ trong thứ bậc tới người điều hành dự án. Tình hình này có thể tồn tại cho lý do chính đáng, cho ví dụ, truy cập tới một công việc chưa hoàn thành trong tiến trình có thể không thích hợp cho một người có chức vụ cao hơn trong khi RBAC có thể hữu ích có thể giống như truy cập tới Tester. Tình hình này có thể được giúp đỡ bởi việc định nghĩa một role là Test Engineer0 mới và liên quan tới nó tới Test Engineer như hiển thị trong Hình 2.3(c). Permission riêng tư của các Test Engineer có thể được gán tới role là Test Engineer0. Test Engineer được gán tới role là Test Engineer0 và thừa kế permission từ role là Test Engineer, mà được thừa kế ở trên trong hệ thống thứ bậc bởi role là Project Supervisor. Permission của Test Engineer0, tuy nhiên, không được thừa kế bởi role là Project Supervisor. Có thể gọi các role giống như Test Engine0 như các role riêng tư. Hình 2.3(c) cũng hiển thị một role riêng tư của Programmer0. Trong một vài hệ thống hiệu quả của các role riêng tư đạt được bởi khối bên trên thừa kế của các permission chắc chắn. Trong một vài trường hợp của hệ thống thứ bậc không mô tả sự phân phối của permission chính xác. Điều này thích hợp để giới thiệu các role riêng tư và giữ nghĩa của hệ thống thứ bậc liên quan xung quanh những role không thay đổi. Hình 2.4 hiển thị, nhiều điểm chung, một hệ thống thừa kế con của các role có thể được xây dựng như thế nào. Hệ thống thứ bậc của Hình 2.4(a) có bốn role công việc, T1, T2, T3, T4, tất cả đều thừa kế permission từ role dự án phổ biến rộng P. Role S ở trên cùng của hệ thống thứ bậc dành cho Project Supervisor. Công việc T3 và T4 là một dự án con với P3 như role dự án con rộng, và S3 như role giám sát dự án con. Role T1’ trong Hình 2.4(c) là một role riêng tư cho những thành viên của những nhiệm vụ T1. Giả sử dự án con trong Hình 2.4(a) gồm có vai trog S3, T3, T4 và P3, yêu cầu một hệ thống thứ bậc con riêng tư trong các permission riêng tư của dự án có thể được chia sẻ ngoài hệ thống thứ bậc bởi S. Trong toàn thể hệ thống cấp bậc con được tái tạo trong dáng vẻ được hiện thị trong Hình 2.4(c). Các permission có thể thừa kế bởi S có thể được gán tới S3, T3, T4 và P3, thích hợp trong khi một trong các quyền riêng tư có thể được gán tới S3, T4, T4 và P3’, cho phép những sự thừa kế của chúng chỉ trong dự án con. Nhưng trước khi thành viên của đội dự án con được gán trực tiếp tới S3’, T3’, T4’, hay P3’. Hình 2.4(c) làm cho nó rõ ràng như các role riêng tư tồn tại trong hệ thống và trợ giúp trong việc truy cập để xem lại tới quyết định sự tự nhiên của các permission riêng tư là gì. 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ệ UA và PA và user 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 role là Programmer và role 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 role mà permission đượ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 session mà user 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. 2.8. Mô hình hợp nhất RBAC3 là sự kết hợp của RBAC1 và RBAC2 để cung cấp cả hai hệ thống thứ bậc role và các ràng buộc. Có một số kết quả xảy ra bởi đưa ra hai khái niệm đó cùng nhau. 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ý Hình 2.6: Mô hình RBAC 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. 2.10. Kết luận Như đã trình bày một tập hợp của các mô hình RBAC mà sự thống hóa từ đơn giản tới phức tạp. Các mô hình này cung cấp một cấu trúc phổ biến của sự tham chiếu tới một sự nghiên cứu khác và phát triển trên lĩnh vực này. Chúng tôi đã trình bày một mô hình quản lý nơi mà RBAC có thể được dùng để quản lý chính nó. Sự trợ giúp này trêm vị trí của chúng rằng RBAC có chính sách trung lập hơn một mô hình của chính sách bảo mật cụ thể. Nhiều điều còn lại được làm tới sự nhận thức khả năng của RBAC. Một trong những vấn đề nghiên cứu đáng chú ý trong lĩnh vực này là phát triển tới một sự tiếp cận có hệ thống tới thiết kế và phân tích của các cấu hình RBAC. Như đã đề cập từ trước, có ít sự thảo luận trong tài liệu về các ràng buộc trong ngữ cảnh của RBAC [8, 9, 14]. Một sự phân loại và nguyên tắc phân loại của các ràng buộc có thể hữu ích. Một ký hiệu hình thức cho trạng thái và sự thi hành các ràng buộc. Cùng với một vài biện pháp khó của sự thi hành sẽ được phát triển. Khả năng về lý do của các ràng buộc và phân tích mạng lưới các hiệu ứng của cấu hình một RBAC dưới dạng các đối tượng chính sách cấp cao hơn là một lĩnh vực nghiên cứu mở quan trọng. Khía cạnh của việc quản lý RBAC cần thiết cho công việc tương lai. Phát triển có hệ thống các phương pháp mà đề cập với sự thiết kế và phân tích của hệ thống role có cấp bậc, các ràng buộc, và việc quản lý RBAC trong một sườn thống nhất là một mục tiêu nghiên cứu đầy thử thách. Nhiều trong các vấn đề mở này v