Các mô hình trong GMF:
Mô hình ―Graphical Definition - *.gmfgraph‖ để định nghĩa các node, link, các figure, chính là các ký hiệu thể hiện cho các thành phần trong ngôn ngữ.
Mô hình ―Tooling Definition - *.gmftool‖ để định nghĩa các thành phần giao diện, trong cửa sổ soạn thảo thể hiện cho ngôn ngữ.
Mô hình ―Mapping Model ‖ kết hợp ba mô hình là Domain Model, Graphical Definition, Tooling definition với nhau mục đích sẽ ánh xạ các thành phần cú pháp trừu tƣợng và trong các thành phần cú pháp cụ thể gắn với thể hiện công cụ trên giao diện thiết kế của ngôn ngữ mô hình hóa chuyên biệt miền.
Cuối cùng từ mô hình ―Mapping model‖ tạo ra mô hình ―Generator Model‖ và cuối cùng tạo ―Diagram Plug – in‖ từ ―Generator Model‖. Mô hình này là mô hình cuối cùng phải xây dựng trong dự án GMF .
Nhìn chung trong chương này chúng tôi đã trình bày và phân tích được MDD với hướng tiếp cận DSM cũng như phân tích lợi ích của phương pháp này mang lại. Trình bày được phương pháp công cụ để xây dựng DSML cũng như lý thuyết nền tảng của DSML.
CHƢƠNG 2. MÔ HÌNH HÓA CHUYÊN BIỆT MIỀN CHO MIỀN BẢO MẬT
Trong chương này chúng tôi sẽ tập trung vào trình bày về miền bảo mật, trên cơ sở nghiên cứu về miền bảo mật theo mô hình RBAC chúng tôi xây dựng Metamodel cho miền bảo mật, cùng với các luật ràng buộc.
2.1. Miền bảo mật
Đối với mỗi một hệ thống để đảm bảo an ninh cho hệ thống cần xây dựng cho hệ thống một chính sách bảo mật tốt. Một chính sách bảo mật có thể nắm bắt đƣợc các yêu cầu bảo mật của một hệ thống và mô tả các bƣớc phải thực hiện để hệ thống đạt đƣợc anh ninh. Một chính sách bảo mật đƣợc mô tả chính thức bằng một mô hình bảo mật, một số mô hình bảo mật nhƣ: ACL, BLP, ABAC, LBAC, MLS, RBAC…. Tuy nhiên với giới hạn về mặt thời gian, chúng tôi chỉ dừng lại tìm hiểu về mô hình bảo mật RBAC và sử dụng miền bảo mật RBAC (Role based access controls) để cài đặt để minh họa cho dự án xây dựng ngôn ngữ mô hình hóa chuyên biệt miền DSML.
2.1.1. Giới thiệu về miền bảo mật
Bảo mật đóng một vai trò trung tâm trong phát triển và hoạt động của các hệ thống phần mềm phân tán với quy mô lớn, nhƣ thƣơng mại điện tử. Tuy nhiên một phân tích quy trình phát triển phần mềm ngày nay cho thấy các kỹ nghệ thiết kế bảo mật cẩn thận trong thiết kế tổng thể thƣờng bị bỏ quên. Các tính năng bảo mật thƣờng đƣợc tích hợp sau trong giai đoạn quản trị hệ thống. Có một số lý do cho vấn đề này. Thứ nhất, bảo mật là một khía cạnh ―ngang‖ của phát triển phần mềm mà ảnh hƣởng gần nhƣ đến tất cả các thành phần của ứng dụng và sự tích hợp của nó vào trong quy trình phát triển phần mềm chƣa đƣợc hiểu đúng đắn. Thứ hai, thiếu các công cụ hỗ trợ kỹ nghệ bảo mật. Thứ ba, tích hợp bảo mật vào trong hệ thống thực hiện thủ công là rất khó và thƣờng phát sinh lỗi do các nhà phát triển cá nhân thiếu kinh nghiệm. Các nhà phát triển nói chung thì thƣờng không phải là chuyên gia về bảo mật và họ cần đƣợc hƣớng dẫn cụ thể để xây dựng các ứng dụng bảo mật. Việc tích hợp bảo mật mức độ thấp sẽ làm giảm chất lƣợng của các ứng dụng [1].
RBAC là một mô hình kiểm soát truy cập đƣợc công nhận rộng rãi. RBAC là một giải pháp đƣợc đề xuất vào năm 1992 bởi Ferraiolo và Kuhn, tích hợp các tính năng hiện có của ứng dụng xác định phƣơng pháp tiếp cận tổng quát mô hình điều khiển truy cập dựa trên vai trò. Role – Based Access Control (RBAC) [1]. Chi tiết về mô hình
bảo mật RBAC chúng tôi sẽ trình bày trong mục tiếp theo.
2.1.2. Điều khiển truy cập dựa trên vai trò (RBAC)
RBAC là một một hình cho kiểm soát truy cập mà ngƣời dùng và đặc quyền của họ đƣợc tách rời nhau bằng vai trò. Việc tách ra nhƣ vậy không chỉ là có đƣợc khái niện hữu ích mà còn thu đƣợc một chính sách kiểm soát truy cập tƣơng đối chặt chẽ [1]. Trong đó ngƣời dùng (User) sẽ đƣợc gán cho các vai trò (Role) và đặc quyền (Permission) đƣợc gán cho các roles.
Hình 2.1. Kiểm soát truy cập truyền thống và RBAC [12]
RBAC là một cơ chế kiểm soát truy cập mô tả chính sách kiểm soát truy cập phức tạp, giảm lỗi, giảm chi phí trong quản trị. Chính sách kiểm soát truy cập đƣợc thể hiện trong các thành phần: Mối quan hệ giữa vai trò và đặc quyền (Role-Permission), ngƣời dùng và vai trò (User-Role) và vai trò với vai trò (Role- Role). Sự phức tạp của quản trị đƣợc giảm đi nhờ vào việc gán các Users vào các Roles, gán Permissions tới các Roles và tổ chức các Roles vào cây thừa kế nhƣ hình dƣới đây:
Hình 2.2. Tổ chức các đối tượng trong mô hình RBAC [12]
RBAC hỗ trợ ba nguyên lý bảo mật nổi tiếng đó là: Đặc quyền tối thiểu (Least Privilege), tách các nhiệm vụ (separation of duties), trừu tƣợng dữ liệu (Data Abstraction). Các mô hình RBAC đƣợc định nghĩa trong bốn mức: RBAC cơ bản (Core RBAC), mô hình RBAC phân cấp (Hierarchical RBAC), tách tĩnh nhiệm vụ (Static Separation of Duty Relations) và tách động nhiệm vụ (Dynamic Separation of Duty Relations) [6].
2.1.2.1. Core RBAC
Core RBAC xác định một tập các thành phần tối thiểu của các thành phần RBAC, tập các thành phần trong mô hình core RBAC và mối quan hệ của chúng định nghĩa trong hình dƣới và gồm tập 5 phần tử cơ bản là ngƣời dùng (USERS), vai trò (ROLES), đối tƣợng (OBS), các hoạt động (OPS), và đặc quyền (PRMS). Mô hình core RBAC định nghĩa các thuật ngữ mà ngƣời dùng đƣợc gán vai trò và sự cho phép đƣợc gán cho vai trò. Nghĩa là vai trò là cầu nối giữa ngƣời sử dụng và đặc quyền của ngƣời dùng. Ngoài ra, mô hình core RBAC còn bao gồm tập các phiên làm việc (SESSIONS), mỗi một phiên làm việc là một ánh xạ giữa một ngƣời dùng và một tập con các trạng thái kích hoạt của các vai trò đƣợc gán cho ngƣời sử dụng [6].
Hình 2.3. Mô hình Core RBAC [6]
Một user đƣợc xác định nhƣ một ngƣời hoặc một phần mềm agent; Một Role là một chức năng công việc trong một tổ chức. Role kết hợp tất cả các đặc quyền cần thiết để thực hiện các công việc hoặc chức năng tƣơng ứng. Đặc quyền đƣợc thể hiện trong các điều khoản của permission gán một vai trò bằng các mối quan hệ Permission Assignment; Một Permission đại diện cho quyền thực thi một hành động trên một hoặc nhiều đối tƣợng hoặc tài nguyên đƣợc bảo vệ; Một object là tài nguyên hoặc tập các tài nguyên mà đƣợc bảo vệ bởi cơ chế bảo mật; Một operation là một tập các hành động trên một đối tƣợng đƣợc bảo vệ. Kiểu của operations phụ thuộc vào kiểu của đối tƣợng bảo vệ. Ví dụ, một file hệ thống có thể có quyền read, write, hoặc thực excute file; trong một hệ quản trị cơ sở dữ liệu operations có thể là insert, delete, append, update [6].
2.1.2.2. Hirerarchical RBAC
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.
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
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ệ
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:
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 đó.
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)
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.
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.
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:
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:
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