Mô hình này giới thiệu về hệ thống phân cấp vai trò (RH). Cây phân cấp vai trò là một khía cạnh quan trọng trong mô hình RBAC. Phân cấp vai trò xác định mối quan hệ kế thừa giữa các vai trò. Nếu vai trò r1 kế thừa vai trò r2 nếu tất cả các đặc quyền của r2 cũng là đặc quyền của r1.
34
Hình 2.4. Mô hình Hierarchical RBAC [4] 2.1.2.3. Constrained RBAC
Constrained RBAC thêm các quan hệ Separation of Duty (SoD - sự phân chia trách nhiệm) vào mô hình RBAC. SoD đƣợc sử dụng để thực thi các chính sách xung đột lợi ích mà các tổ chức có thể sử dụng để ngăn chặn ngƣời sử dụng vƣợt quá một mức độ hợp lý cho các quyền của họ.
Giống nhƣ một yếu tố bảo mật cơ bản, SoD đã đƣợc công nhận một cách rộng rãi cho các ứng dụng trong kinh doanh, các ngành công nghiệp và chính phủ. Mục đích của nó là để đảm bảo rằng các sai sót và gian lận bên trong một tổ chức chỉ là kết quả của việc thông đồng giữa các cá nhân. Để giảm thiểu khả năng thông đồng, các cá nhân thuộc các nhóm kỹ năng khác nhau hoặc lợi ích khác nhau đƣợc phân công nhiệm vụ cần thiết và riêng biệt trong việc thực hiện các chức năng của một doanh nghiệp. Mục đích ở đây chính là để đảm bảo rằng các sai sót và gian lận không xảy ra và cũng không có việc thông đồng của nhiều ngƣời sử dụng. Chuẩn RBAC này cho phép cả SoD tĩnh và SoD động [6].
a) Các Quan hệ Static SoD (SSD)
Trong một hệ thống RBAC, một ngƣời sử dụng có thể ở trong một hoặc nhiều vai trò khác nhau. Nhƣ vậy có thể có sự xung đột về lợi ích của ngƣời dùng khi ngƣời dùng ở trong hai vai trò khác nhau mà hai vai trò này lại mâu thuẫn với nhau [6]. Ví dụ trong hệ thống ngân hàng hai vai trò nhân viên thu ngân và vai trò nhân viên giám sát
35
là hai vai trò hoàn toàn trái ngƣợc nhau hay nói cách khác là xung đột nhau. Vì vậy không bao giờ cho phép một nhân viên ngân hàng vừa đóng vai trò nhân viên thu ngân lại vừa đóng vai trò nhân viên giám sát.
Quan hệ SSD đƣợc đƣa ra để giải quyết các vấn đề xung đột lợi ích nhƣ đã nói ở trên. Mô hình tổng quát các quan hệ SSD đƣợc minh họa trong hình dƣới đây:
Hình 2.5. Mô hình SSD trong Hierarchy RBAC [6]
b) Các quan hệ Dynamic SoD (DSD)
Các quan hệ tách nhiệm vụ động (Dynamic SoD) cũng giống nhƣ các quan hệ tách nhiệm vụ tĩnh (Static SoD) ở chỗ cả hai đều đƣợc sử dụng để giới hạn các quyền có thể đƣợc cung cấp đến ngƣời sử dụng. Tuy nhiên, các quan hệ DSD khác với các quan hệ SSD ở ngữ cảnh mà trong đó những sự giới hạn đó đƣợc áp đặt. Các mối quan hệ SSD định nghĩa và đặt các ràng buộc trên khu vực tổng số quyền của ngƣời sử dụng, còn DSD lại đặt các ràng buộc lên trên các vai trò có thể đƣợc kích hoạt trong một phiên làm việc của ngƣời sử dụng. DSD cho phép một user đƣợc xác thực cho hai hoặc nhiều vai trò mà không tạo ra một sự xung đột lợi ích giữa các vai trò khi chúng hoạt động độc lập. Điều này có nghĩa rằng nếu một vai trò thuộc một quan hệ SSD đƣợc kích hoạt trong phiên làm việc của ngƣời sử dụng thì các vai trò có liên quan khác không thể đƣợc kích hoạt trong cùng một phiên làm việc đó [6]. Mô hình tổng quát của các quan hệ DSD đƣợc minh họa nhƣ trong hình dƣới đây:
36
Hình 2.6: Mô hình quan hệ DSD [6]
2.2. Metamodel cho bảo mật theo mô hình RBAC
Sau khi nghiên cứu miền bảo mật và một số tài liệu tham khảo cũng nhƣ qua quá trình cài đặt thử nghiệm, chúng tôi đã xây dựng đƣợc một MetaModel cho ngôn ngữ mô hình hóa chuyên biệt miền cho miền bảo mật theo mô hình RBAC nhƣ sau:
37
Trong đó:
- Users là ngƣời dùng trong hệ thống, ngƣời dùng có thể là ngƣời hoặc một hệ thống.
- Roles là vai trò của ngƣời dùng trong một tổ chức.
- Permissions là cầu nối giữa vai trò(Roles) và hành động(Action) trên các nguồn tài nguyên của hệ thống (Resource).
- Actions là các hành động có thể thực hiện trên nguồn tài nguyên.
- AuthorizationConstrains là ràng buộc khi một vai trò đƣợc cấp quyền thực hiện một hành động trên nguồn tài nguyên.
- Map là thuật ngữ biểu đồ, để đại diện cho mỗi biểu đồ RBAC, một biểu đồ gồm nhiều node, các node đó chính là các concept thuộc miền RBAC mà chúng tôi đã xác định ở trên.
- SubRole chỉ mối quan hệ kế thừa trong Role, nếu r1 kế thừa r2 thì r1 sẽ thực hiện đƣợc tất cả các hành động trên nguồn tài nguyên của r2.
- AsignRole là mối quan hệ giữa User và Roles, một User đƣợc gán nhiều vai trò đƣợc gán cho nhiều vai trò.
- RoleHasP chỉ mối quan hệ giữa Role và Permission, một vai có thể có nhiều sự cho phép.
- PermissionAccessAction chỉ mối quan hệ giữa Permission và Action, một sự cho phép có thể cho phép thực hiện nhiều hành động trên các nguồn tài nguyên.
- AccessResource một sự cho phép thực hiện các hành động có thể là sự cho phép trên nhiều tài nguyên khác nhau.
Ngoài ra mối quan hệ giữa Map và các khái niệm khác là mối quan hệ cộng hợp (Composition), vì trong một biểu đồ chứa nhiều node trên đó.
38
2.3. Xác định các luật ràng buộc trên metamodel.
Các ràng buộc trên metamodel RBAC được xác định như sau:
- Luật 1 : Trong một mô hình không có hai Role trùng tên nhau. context Map
inv: self.RootRole->forAll(r1:Roles,r2:Roles|r1<>r2 implies r1.name<>r2.name)
- Luật 2: Trong một mô hình không có hai Permission trùng tên nhau. context Map
inv: self.RootPermission->forAll(p1:Permission,p2:Permission|p1<>p2 implies p1.Name<>p2.Name).
- Luật 3: Trong một mô hình không có hai Resource giống nhau (trùng tên, trùng kiểu). context Map
inv: self.RootSource->forAll(r1:Resource, r2:Resource| (r1.name=r2.name)and(r1.Type=r2.Type) implies r1=r2)
- Luật 4: Trong cây kế thừa vai trò không có một vai trò kế thừa tới chính nó. context Roles inv: self<>oppositeEnd
- Luật 5: Trong mô hình không có vai trò có quyền thấp kế thừa vai trò quyền cao. context Map
inv: self.RootRole->forAll(r:Roles|if (r.name=RoleName::User) then r.SubRole->size()=0 else if (r.name=RoleName::PowerUser) then r.SubRole ->forAll(i:Roles|i.name=RoleName::User) else if (r.name=RoleName::Owner)
then r.SubRole ->forAll(i:Roles|i.name=RoleName::User or i.name=RoleName::PowerUser) else if (r.name=RoleName::Administrator) then r.SubRole ->forAll(i:Roles|i.name=RoleName::User or i.name=RoleName::PowerUser or i.name=RoleName::Owner)
else true endif endif endif endif)
39 context Map
inv: self.RootRole->forAll(r1:Roles, r2:Roles|(r1<>r2)and(r1.SubRole
->exists(i:Roles|i=r2)) implies (r2.SubRole->forAll(j:Roles|j<>r1)))
- Luật 7: Trong một Permission không có hai Action giống nhau. context Permisson
inv: self.PermissionAccessAction->forAll(r1:Action,r2:Action |r1<>r2 implies r1.name<>r2.name)
Tóm lại trong chương này chúng tôi đã trình bày được về miền bảo mật theo mô hình RBAC, trên cơ sở nghiên cứu về miền chúng tôi đã xây dựng được metamodel biểu diễn cho DSML thuộc miền, cũng như xây dựng các luật ràng buộc bằng OCL cho metamodel.
40
CHƢƠNG 3. XÂY DỰNG NGÔN NGỮ CHUYÊN BIỆT MIỀN RBAC TRÊN ELIPSE
Trong Eclipse có hỗ trợ dự án EMF và GMF cho phát triển cú pháp trừu tượng và cú pháp cụ thể để xây dựng DSML, và dự án GMT cho xây dựng bộ sinh mã nguồn tự động cho ngôn ngữ DSML. Trong chương này chúng tôi trình bày về kết quả cài đặt hai dự án EMF và GMF cho DSML RBAC trong Eclipse.
3.1. Cú pháp trừu tƣợng
Sau khi nghiên cứu miền bảo mật theo mô hình RBAC, chúng tôi đã xác định đƣợc metamodel và các luật ràng buộc trên metamodel. Tiếp theo chúng tôi đã cài đặt thử nghiệm cú pháp trừu tƣợng cho DSML bằng dự án EMF của Eclipse. Các thành phần tạo ra trong dự án EMF gồm: hai mô hình Ecore và genmodel, và mã nguồn của mô hình là EMF.model, EMF.edit, EMF.editor. Dƣới đây là các mô hình, mã nguồn đƣợc tạo ra trong dự án xây dựng DSML cho RBAC.
a) Mô hình ecore
Để xây dựng mô hình Ecore, chúng tôi đã sử dụng mô hình Ecore diagram để xây dựng. Với mô hình Ecore diagram cho phép chúng ta xây dựng Metamodel một cách trực quan bằng các, thao tác kéo thả. Khi tạo ra một mô hình ecore diagram thì sẽ tạo ra một mô hình Ecore tƣơng ứng. Kết quả thu đƣợc hai mô hình ecorediag và ecore của dự án RBAC nhƣ trong hình 3.1.
41
Hình 3.1. Mô hình RBAC.ecorediag
EMF đã cung cấp một công cụ cho phép tạo mô hình ecrore một cách trực qua bằng thao tác kéo thả, đó là công cụ Ecorediagram, khi đó để tạo ra mô hình ecore thay vì phải sử dụng các khái niệm trừu tƣợng của mô hình ecore ngƣời dùng có thể sử dụng các ký hiệu trực quan trong thanh công cụ của Ecorediagram, trong hình trên là các đối tƣợng trong metamodel đã đƣợc xây dựng một cách trực quan trong mô hình RBAC.ecorediag. Khi đó sẽ có một mô hình RBAC.ecore đƣợc tạo ra tƣơng ứng với mô hình RBAC.ecorediag nhƣ hình dƣới đây:
42
Hình 3.2. Mô hình RBAC.ecore
b) Mô hình genmodel
Sau khi xây dựng mô hình Ecore, bƣớc tiếp theo trong dự án EMF tạo ra mô hình genmodel từ mô hình ecore. Mô hình genmodel đƣợc sinh ra từ mô hình ecore đƣợc bổ sung thêm các thông tin cho EMF.model, EMF.edit, EMF.editor, EMF.test. Mô hình RBAC.genmodel nhƣ hình dƣới đây:
43
Hình 3.3. Mô hình RBAC.genmodel
Hình trên cho thấy trong mô hình genmodel các thông tin về các thành phần sinh từ mô hình này, sẽ đƣợc xác định trong các thuộc tính.
c) Mã nguồn của mô hình (EMF.Model)
Mã nguồn của mô hình đƣợc tạo ra từ mô hình genmodel nhờ bộ Generator của dự án EMF. Mã nguồn của metamodel của dự án EMF RBAC gồm có 3 package:
44
khái niệm trong metamodel, và khai báo các enum, interface của Factory, Package. - rbac.impl: Gồm các tệp java của các lớp triển khai các interface đƣợc khai báo trong gói RBAC.
- rbac.util: gồm hai tệp tƣơng ứng với hai lớp RbacAdapterFactory.java và RbacSwitch.java.
Hình 3.4. Mã nguồn của mô hình tự động sinh từ mô hình RBAC.genmodel
d) Các thành phần của EMF.Edit, và EMF.Editor.
Mã nguồn của các thành phần này cũng đƣợc tự động sinh ra từ genmodel nhờ bộ Generator của dự án EMF.
45
Hình 3.5. RBAC.edit và RBAC.Editor được sinh ra từ genmodel
3.2. Cú pháp cụ thể
Trong dự án EMF chúng tôi đã xây dựng đƣợc cú pháp trừu tƣợng cho DSML. Tiếp theo, chúng tôi sẽ xây dựng cú pháp cụ thể cho DSML bằng dự án GMF của Eclipse. Trong đó các ký hiệu đại diện các khái niệm của DSML cho RBAC sẽ đƣợc xây dựng nhƣ bảng dƣới đây:
46
Các mô hình xây dựng trong dự án GMF cho DSMl RBAC gồm: a) Graphical Definition Model RBAC.gmfgraph
Cho phép định nghĩa các Figure, Node, Connection,Compartment , Diagram Label cho các khái niệm thuộc miền nhƣ hình dƣới đây:
Khái niệm (Concept) Ký hiệu (Notation)
Node User Node Role
Node Permission
Node Action trong node Permission
Node AuthorizationConstrain
Node Resource
Connection User AssignRole <AssignRole> Connection SubRole <Inherit>
Connection Role Has Permission <Role Has Permission> Connection Permission Has
Authorizationconstrain <PermissionHasAuthorizationconstrain > Connection
PermissionAcessResource
< AcessResource>
47
Hình 3.6.Mô hình BAC.gmfgraph
Trong đó:
+ Figure: Định nghĩa các hình đại diện cho các node và các connection gồm:
- Các Polyline: Định nghĩa hình dáng đƣờng ở cuối liên kết của các connection. Ví dụ hình hƣới đây định nghĩa cho liên kết giữa Role và Permission.
48
Hình 3.7. Xây dựng PolyLine cho link RoleHasPermission
- Các Figure Descriptor: Các hình đại diện cho các khái niệm miền và các liên kết giữa các khái niệm trong mô hình miền. Nhƣ hình dƣới đây là định nghĩa hình (ký hiệu) cho khái niệm Role và hình liên kết giữa Role và Permission.
49
Hình 3.8. Xây dựng Figure cho Role và Link RoleHasPermission
+ Các Node: Định nghĩa các khái niệm miền là node trong mô hình. Với mỗi một node ta cần xác định hình đã đ ƣ ợ c định nghĩa ở trên. Nhƣ hình dƣới đây định nghĩa node: Role.
50
Hình 3.9. Xây dựng node Roles
+ Các Connection: Định nghĩa các liên kết (association ) tồn tại giữa các khái niệm miền. Trong đó xác định hình dáng liên kết bằng hình dạng đƣợc định nghĩa ở trên. Nhƣ hình dƣới đây định nghĩa Connection giữa Role và Permission.
Hình 3.10 Xây dựng Connection RoleHasPermission
+ Các Diagram Label: Định nghĩa các hình chứa các nhãn đã định nghĩa trong các hình của các node, hoặc trong các connection. Nhƣ hình dƣới đây xác định Diagram label cho node Role.
51
Hình 3.11. Diagram Label RolesName
+ Compartment: Nếu trong mô hình miền có những khái niệm là một phần của khái niệm khác, thì cần xây dựng Compartment cho khái niệm chứa. Nhƣ trong khái niệm miền RBAC có khái niệm Action đƣợc chứa trong khái niệm Permission. Nhƣ vậy cần tạo ra Compartment của khái niệm Permission.
52
b) Tooling Definition Model
Mô hình này đƣợc sử dụng để xác định thanh palette, tạo các tools, tạo các actions… Cho các phần tử đồ họa.
Trong dự án GMF RBACG có xây dựng một thanh Palette cho các khái niệm và liên kết. Các ký hiệu này đƣợc chia làm ba nhóm: Node, Link, và Permission Access Action (tách riêng node Acction ra một nhóm riêng). Kết quả của Tooling Definition Model trong dự án GMF RBACG nhƣ hình dƣới đây:
53
c) Mapping Definition Model
Mô hình này cho phép chúng ta liên kết ba mô hình với nhau đó là: Domain (RBAC.Ecore), Graphical definition (RBAC.gmfgraph) và tooling definition (RBAC.gmftool). Đây là mô hình quan trọng để phát triển dự án GMF và mô hình này là đầu vào để chuyển sang mô hình cuối cùng là Generation Model.
Mô hình này sẽ ánh xạ các khái niệm miền ở mức trừu tƣợng trong mô hình RBAC.ecore thành các khái niệm miền ở mức cụ thể trong RBAC.gmfgraph gắn với tool trong Palette của mô hình RBAC.gmftool. Trong Mapping Definition Model của dự án GMF RBACG cần ánh xạ các Node và Link giữa các Node, hình dƣới đây là mô hình RBAC.gmftool đã xây dựng.
Hình 3.13. Các Node, link Mapping trong RBAC1.gmfmap
Trong đó:
+ Các Node cần ánh xạ của dự án GMF RBACG: Role, Permission, Action, Resource, AuthorizationConstrain với node Acction đƣợc định nghĩa trong node Permission. Ví dụ nhƣ ánh xạ node Role nhƣ hình dƣới đây:
54
Hình 3.14. Ánh xạ node Role
Hình tiếp theo là ánh xạ của node Permission trong đó xác định node chứa bên trong là node Action.
55
Hình 3.15. Ánh xạ Node Action và Permission
+ Các Link cần ánh xạ trong dự án RBACG: SubRole, RoleHasPermission PermissionHasAuthorization, PermissionAccessResource. Ví dụ nhƣ hình dƣới đây tạo link ánh xạ Link RoleHasPermission.
56
Hình 3.16. Ánh xạ Link Role Has Permission
d) Code Generation
Đây là mô hình cuối cùng trong dự án GMF. Sau khi xây dựng mô hình Mapping definition bƣớc tiếp theo tạo mô hình Generator từ mô hình Mapping definition. Cuối cùng tạo generate diagram code từ mô hình Generator.
57
Hình 3.17. Generate diagram code của dự án GMF RBAC
Kết quả của bƣớc trên sẽ tạo ra tệp Plugin.xml của tool DSML RBAC thu đƣợc từ kết quả của dự án GMF RBACG
58
Hình 3.18. Cửa sổ Extensions của Plugin.xml trong dự án GMF RBACG
Kết quả dự án GMF RBAC chúng tôi đã xây dựng đƣợc một DSML RBAC Application Pug-in với Eclipse nhƣ sau:
59
Hình 3.19. DSML cho RBAC
Trong dự án GMF, cung cấp cửa sổ tiện ích Gashboard cho phép chúng ta xây dựng lần lƣợt các mô hình trong dự án.
60
3.3. Thêm các ràng buộc viết bằng OCL
Trong dự án xây dựng DSML nếu chúng ta chƣa thêm các ràng buộc vào metamodel thì DSML xây dựng ra chƣa có khả năng kiểm tra đƣợc các mô hình do ngƣời sử dụng tạo ra có vi phạm các luật trong miền hay không. Ví dụ ngƣời dùng có thể tạo ra một mô hình mà trong mô hình có hai Role trùng tên nhau. Để làm cho DSML xây dựng ra đúng đắn, chúng ta cần thêm vào các ràng buộc cho Metamodel, các ràng buộc nhƣ đã xây dựng trong mục 2.3. Chúng ta có thể thêm các ràng buộc vào mô hình ecore trong dự án EMF hoặc mô hình gmfmap trong dự án GMF. Trong luận văn này, chúng tôi thêm các ràng buộc vào mô hình gmfmap,