Tóm tắt Luận văn Mở rộng công cụ Activiti cho đặc tả và cài đặt chính sách an ninh

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ ĐỖ ANH VIỆT MỞ RỘNG CÔNG CỤ ACTIVITI CHO ĐẶC TẢ VÀ CÀI ĐẶT CHÍNH SÁCH AN NINH Ngành: Công nghệ Thông tin Chuyên ngành: Kỹ thuật Phần mềm Mã số: 60480103 TÓM TẮT LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN Hà Nội – 2018 MỞ ĐẦU Quy trình nghiệp vụ đóng một vai trò then chốt để doanh nghiệp có thể quản lý và vận hành một cách nhịp nhàng, đạt hiệu quả cao. Có thể khẳng định, một doanh nghiệp xây dựng được quy trình tốt sẽ phát triển bền vững và có tính cạnh tranh cao hơn [1]. Mô hình hóa quy trình nghiệp vụ thường tập trung vào mô hình hóa chính xác chức năng của quy trình mà bỏ qua các yêu cầu về an ninh. Nguyên nhân chủ yếu là do thực tế rằng các chuyên gia trong lĩnh vực quy trình nghiệp vụ không phải là chuyên gia về an ninh. Các yêu cầu về an ninh thường xuyên được xem xét sau khi định nghĩa hệ thống. Cách tiếp cận này dẫn đến các lỗ hổng an ninh và rõ ràng cần thiết phải tăng cường nỗ lực an ninh trong các giai đoạn trước phát triển do việc sửa lỗi sẽ hiệu quả và tiết kiệm chi phí hơn. Các nghiên cứu thực nghiệm cho thấy tại mức thiết kế quy trình nghiệp vụ thì khách hàng và người dùng cuối có thể biểu diễn các yêu cầu an ninh của họ và sau đó có thể thể hiện tại mức cao, các yêu cầu an ninh dễ dàng xác định bởi người mô hình hóa quy trình nghiệp vụ. Các yêu cầu an ninh có thể được mô hình hóa trong quy trình nghiệp vụ và cần thiết phải xem xét các yêu cầu an ninh này trong bất kì ứng dụng nào tại mức độ trừu tượng cao nhất. Một trong các yêu cầu an ninh là điều khiển truy nhập tức là kiểm soát việc truy cập và thực hiện các hành động trên các nguồn tài nguyên hệ thống được được bảo vệ. RBAC (Role-Based Access Control) điều khiển truy cập theo vai trò là một phương pháp điều khiển truy cập hiệu quả nhất hiện nay. Tuy nhiên, các nền tảng cho phép mô hình hóa quy trình nghiệp vụ hiện nay như Oracle BPM, Acitivi BPM đều chưa hỗ trợ tích hợp điều khiển truy cập theo vai trò RBAC một cách đầy đủ. Chính vì vậy, em xin chọn đề tài “Mở rộng công cụ Activiti cho đặc tả và cài đặt chính sách an ninh”. CHƯƠNG 1. KIẾN THỨC NỀN TẢNG 1.1. Mô hình hóa chuyên biệt miền Các hệ thống phần mềm hiện nay ngày càng trở nên phức tạp, muốn cải thiện hiệu suất phát triển phần mềm không chỉ tốc độ mà còn chất lượng hệ thống được tạo ra, các nhà nghiên cứu đã cố gắng tìm ra một phương pháp tự động chuyển từ mô hình sang code và mô hình hóa chuyên biệt miền (DSM) đã ra đời. DSM sử dụng một ngôn ngữ mô hình hóa chuyên biệt miền (DSML) để sinh code đầy đủ từ mô hình và code được sinh ra có ít lỗi hơn là code viết bằng tay[2]. 1.1.1. Khái niệm DSM về cơ bản nâng cao mức độ trừu tượng trong khi thu hẹp không gian thiết kế. Cùng với ngôn ngữ mô hình hóa chuyên biệt miền DSML, vấn đề sẽ được giải quyết khi việc mô hình hóa trực quan giải pháp mà chỉ sử dụng các khái niệm miền quen thuộc. Sản phẩm cuối cùng được sinh tự động bởi các bộ sinh code chuyên biệt miền. Với DSM, không cần ánh xạ từ khái niệm miền sang khái niệm thiết kế và cuối cùng sang khái niệm ngôn ngữ lập trình. DSM tuân theo công thức: cung cấp mức độ trừu tượng cao hơn và thực hiện ánh xạ tự động từ các khái niệm mức cao hơn sang các khái niệm mức thấp hơn đã biết và sử dụng trước đó. Hình 1.1: Thu hẹp khoảng cách trừu tượng giữa ý tưởng miền và cài đặt Các thành phần chính của DSM là ngôn ngữ, bộ sinh code và framework miền. Kiến trúc ba lớp DSM là : Hình 1.2: Kiến trúc cơ bản của DSM Ngôn ngữ chuyên biệt miền : cung cấp cơ chế trừu tượng để giải quyết sự phức tạp của miền cho trước. Điều này được thực hiện bằng cách cung cấp các khái niệm và các luật trong một ngôn ngữ biểu diễn miền ứng dụng hơn là các khái niệm của một ngôn ngữ lập trình nhất định. Bộ sinh code xác định làm sao thông tin được lấy ra từ mô hình và chuyển đổi sang code. Trong trường hợp đơn giản nhất, mỗi symbol (ký tự) mô hình hóa tạo ra code nhất định, bao gồm các giá trị được nhập vào trong symbol là các tham số. Framework miền: cung cấp giao diện giữa code được sinh ra và các nền tảng phía dưới. Code sinh ra không được thực hiện một mình mà còn cùng với code thêm vào trong một số môi trường đích. 1.1.2. Ngôn ngữ mô hình hóa chuyên biệt miền Ngôn ngữ chuyên biệt miền (DSL) là một ngôn ngữ lập trình hoặc một ngôn ngữ đặc tả thực thi, thông qua các ký hiệu thích hợp và trừu tượng, tập trung vào biểu diễn; và thường được giới hạn trong một miền cụ thể. DSL làm tăng mức độ trừu tượng bằng cách sử dụng các khái niệm quen thuộc với chuyên gian miền. Trong mô hình hóa chuyên biệt miền, DSL được gọi là DSML được sử dụng cho việc xây dựng mô hình đồ họa cho một hệ thống phần mềm. DSML thường gồm cú pháp (syntax) và ngữ nghĩa (semantics). Cú pháp bao gồm cú pháp trừu tượng (abstract syntax) và cú pháp cụ thể (concrete syntax). Cú pháp trừu tượng biểu thị cấu trúc và các quy tắc ngữ pháp của một ngôn ngữ. Trong khi cú pháp cụ thể giải quyết các symbol ký hiệu và các biểu mẫu hiển thị mà ngôn ngữ sử dụng. Để tăng sự trừu tượng thiết kế, cần mở rộng cả cú pháp và ngữ nghĩa. Cú pháp Cú pháp định nghĩa các thành phần hợp lệ trong một ngôn ngữ nhất định. Cú pháp chỉ xác định một cấu trúc có hợp lệ nhưng nó có thể có ngữ nghĩa không hợp lệ. Cú pháp trừu tượng: xác định cấu trúc khái niệm của một ngôn ngữ: cấu trúc của một ngôn ngữ mô hình hóa, các thuộc tính của nó và các kết nối của chúng với nhau. Cú pháp cụ thể: Cú pháp cụ thể xác định các thành phần từ cú pháp trừu tượng được biểu diễn trực quan như thế nào. Ngữ nghĩa Mỗi khái niệm mô hình hóa đều có một số ý nghĩa, ngữ nghĩa. Khi thêm một thành phần vào mô hình hoặc kết nối các phần tử với nhau, chúng ta tạo ra ý nghĩa. Trong DSM, ngữ nghĩa của ngôn ngữ mô hình hóa đến trực tiếp từ miền vấn đề.. 1.2. Mô hình hóa đặc tả chính sách truy nhập RBAC 1.2.1. RBAC và các rằng buộc phân quyền Điều khiển truy cập dựa theo vai trò RBAC là một mô hình điều khiển truy cập, trong đó việc quản trị an ninh có thể được đơn giản hóa bằng cách sử dụng các vai trò để tổ chức các quyền truy nhập và cuối cùng giảm bớt sự phức tạp và chi phí quản trị an ninh [3]. Mô hình tham chiếu RBAC được định nghĩa dưới dạng 3 thành phần mô hình : Core RBAC (RBAC lõi), Hierachy RBAC (RBAC phân cấp) và Authorization Constraints (các rằng buộc phân quyền). Core RBAC [3] định nghĩa tối thiểu các phần tử, các tập phần tử và các mối quan hệ để đạt được một hệ thống điều khiển truy nhập dựa theo vai trò một cách hoàn chỉnh. Hình 1.3: Core RBAC [3]  Một user được định nghĩa là một con người.  Một role là một chức năng công việc trong ngữ cảnh của tổ chức, liên quan đến quyền hạn và trách nhiệm của người dùng được gán vai trò đó  Một object là một thực thể chứa hoặc nhận thông tin ví dụ như container chứa thông tin (file, thư mục, ) hoặc có thể đại diện cho các nguồn tài nguyên hệ thống (máy in, ổ cứng,)  Một permission là một sự chấp nhận để thực hiện một hành động trên một hoặc nhiều đối tượng được RBAC bảo vệ.  Một operation là một hành động trên một đối tượng được bảo vệ, ví dụ trong hệ thống file, các hoạt động có thể là đọc file, ghi file và xóa file. Một mô hình RBAC được sử dụng rộng rãi do Sandhu và các cộng sự [4] giới thiệu :  Các tập hợp USERS, ROLES, PRMS, SESSIONS ( người dùng, vai trò, quyền và phiên làm việc tương ứng)  UA ⊆ USERS x ROLES (mối quan hệ gán người dùng với vai trò)  PA ⊆ PRMS x ROLES (mối quan hệ gán quyền với vai trò)  RH ⊆ ROLES x ROLES (mối quan hệ phân cấp vai trò) Một USER có thể là thành viên của nhiều ROLES và một ROLE có thể có nhiều USERS. Một ROLE có thể có nhiều PRMS và cùng PRMS có thể được gán cho nhiều ROLES. Một USER có thể kích hoạt một tập con các ROLES được gán cho mình trong một SESSION. Các PRMS có sẵn cho USER là sự kết hợp của PRMS từ tất cả các ROLES được kích hoạt trong SESSION. Các phân cấp vai trò có thể được hình thành bởi quan hệ RH. Authorizaiton Constraints là một khía cạnh quan trọng của RBAC và được xem như là động lực chính đằng sau RBAC. Mục đích của Authorizaiton Constraints không chỉ để giảm nguy cơ gian lận hoặc vi phạm an ninh mà còn tăng cơ hội phát hiện lỗi trong cấu trúc an ninh của tổ chức. Authorizaiton Constraints có thể cần được áp dụng với các chức năng và mối hệ RBAC để ngăn chặn việc sử dụng thông tin sai lệch và các hành động gian lận. Một vài loại Authorizaiton Constraints như rằng buộc SoD tĩnh và động, rằng buộc ngữ cảnh, rằng buộc cardinality. 1.2.2. MetaModel cho RBAC Hình 1.4: MetaModel của RBAC [7] 1.3.1. Mô hình hóa quy trình nghiệp vụ Quy trình nghiệp vụ được định nghĩa là một tập các sự kiện, hành động và quyết định liên quan đến các tác nhân và nguồn tài nguyên, tất cả tạo ra một kết quả mang lại giá trị cho tổ chức hoặc khách hàng của tổ chức[7]. Quy trình nghiệp vụ đóng vai trò cốt lõi để căn cứ theo đó doanh nghiệp quản lý và vận hành một cách nhịp nhàng và đạt hiệu quả cao. Hình 1.5: Quy trình nghiệp vụ [7] Quản lý quy trình nghiệp vụ BPM chính là các nguyên tắc, các phương pháp và các công cụ để thiết kế, phân tích, thực thi và giám sát các quy trình nghiệp vụ. Mục đích của quản lý quy trình nghiệp vụ BPM là giảm sai sót của con người và sự gián đoạn của quy trình để tập trung các bên liên quan vào vai trò nhiệm vụ của họ. Với sự giúp đỡ của BPM, các tổ chức doanh nghiệp có thể hoạt động hiệu quả hơn và có khả năng thích nghi tốt với những thay đổi. 1.3.1.1. Vòng đời quy trình nghiệp vụ Việc tạo ra một quy trình nghiệp vụ bao gồm 5 pha được gọi là vòng đời BPM. Năm pha này là: Thiết kế, Mô hình hóa, Thực thi, Giám sát và Tối ưu. Mỗi pha được thiết kế để cài đặt một giải pháp quy trình thành công. Nhờ có vòng đời BPM, người ta có thể hiểu việc cài đặt một quy trình nghiệp vụ là một quá trình liên tục do những những thay đổi luôn xảy ra trong môi thường kinh doanh. Hình 1.6: Vòng đời BPM 1.3.1.2. Tiêu chuẩn ký hiệu BPMN Có nhiều tiêu chuẩn BPM khác nhau được giới thiệu cho việc phát triển quy trình nghiệp vụ nhưng BPMN 2.0 là tiêu chuẩn được sử dụng rộng rãi nhất do nó hỗ trợ cả thiết kế và các tính năng thêm các chi tiết kĩ thuật vào nó. Một sơ đồ BPMN đơn giản bao gồm các thành phần đại diện cho luồng công việc, đem lại hữu ích cho cả người sử dụng và người phát triển quy trình. Bốn loại thành phần BPMN cơ bản là: Flow objects, Connecting objects, Swim lanes và Artifacts. Hình 1.7: Metamodel của BPMN [8] 1.3.2. Công cụ Activiti Activiti được phát triển bởi Tom Baeyens và Joram Barez [9] dưới dạng mã nguồn mở, để thực thi các quy trình nghiệp vụ được biểu diễn bằng BPMN 2.0. Activti là nền tảng tốt nhất để xây dựng BPM cho giao tiếp giữa con người với con người. Nó có thể được sử dụng rất dễ dàng trong mọi môi trường Java, hỗ trợ tất cả các khía cạnh của BPM trong ngữ cảnh phát triển phần mềm. Người dùng có thể xây dựng bất kì ngôn ngữ quy trình tùy chỉnh nào phù hợp với yêu cầu của mình vì nó cho phép họ sử dụng các công cụ đã biết thay vì việc thay thế bằng một công cụ hoàn toàn mới. Thậm chí, nếu người dùng thiếu kiến thức về kỹ thuật thì họ cũng có thể dễ dàng cài đặt và chạy quy trình với tiện ích cài đặt. Activi có một cơ chế xử quy trình BPMN 2.0 siêu nhanh và ổn định, cung cấp nền tảng tốt nhất cho sự hợp tác giữa người dùng ít hiểu biết về kỹ thuật và nhà phát triển kỹ thuật [10]. Activiti được chia thành các mô-đun khác nhau. Activiti Modeler, Activiti Designer, and Activiti Kickstart được sử dụng trong pha mô hình hóa để thiết kế quy trình. Activiti Engine được tích hợp với ứng dụng và được đặt tại vị trí trung tâm như một phần của pha thực thi. Để giám sát và quản lý quy trình, Activiti Explorer và Activiti Rest được sử dụng. Hình 1.8: Các thành phần của Activiti [9] CHƯƠNG 2. TÍCH HỢP MÔ ĐUN CHÍNH SÁCH TRUY CẬP RBAC VỚI ACTIVITI 2.1. Phương pháp tích hợp RBAC vào BPM Các yêu cầu an ninh là mối quan tâm lớn trong việc thiết kế, xây dựng và thực thi các hệ thống hướng quy trình nói chung và hệ thống BPM nói riêng, tuy nhiên chúng thường coi là các yêu cầu phi chức năng. Chức năng của hệ thống và yêu cầu an ninh thường không độc lập với nhau nên sự phân chia này khiến cho hệ thống khó đảm bảo việc thỏa mãn tất cả các yêu cầu. Vì vậy, cần tích hợp các yêu cầu an ninh vào tất cả các pha của vòng đời BPM nghĩa là từ pha thiết kế, mô hình hóa đến pha thực thi đến pha giám sát và pha tối ưu. Trong phạm vi luận văn, tôi chỉ tập trung vào việc tích hợp các yêu cầu an ninh RBAC vào pha thiết kế và mô hình hóa quy trình bằng BPMN 2.0, ngoài ra, áp đặt các yêu cầu an ninh vào pha thực thi. Thiết kế và mô hình hóa quy trình nghiệp vụ thường tập trung vào mô hình hóa chính xác chức năng của quy trình mà bỏ qua các yêu cầu về an ninh. Nguyên nhân chủ yếu là do thực tế rằng các chuyên gia trong lĩnh vực quy trình nghiệp vụ không phải là chuyên gia về an ninh. Các yêu cầu về an ninh thường xuyên được xem xét sau khi định nghĩa hệ thống. Cách tiếp cận này dẫn đến các lỗ hổng an ninh và rõ ràng cần thiết phải tăng cường nỗ lực an ninh trong các giai đoạn trước phát triển do việc sửa lỗi sẽ hiệu quả và tiết kiệm chi phí hơn. Các nghiên cứu thực nghiệm cho thấy tại mức thiết kế quy trình nghiệp vụ thì khách hàng và người dùng cuối có thể biểu diễn các yêu cầu an ninh của họ và sau đó có thể thể hiện tại mức cao, các yêu cầu an ninh dễ dàng xác định bởi người mô hình hóa quy trình nghiệp vụ [8]. Đầu tiên, các thuộc tính an ninh phải là một phần quy trình nghiệp vụ giống như Activity hay Event. Điều này yêu cầu một ngôn ngữ tích hợp cả yêu cầu an ninh và yêu cầu nghiệp vụ và sự lựa chọn hàng đầu là mở rộng ngôn ngữ mô hình hóa quy trình bằng việc thêm vào cái khái niệm về an ninh. Một cách tiếp cận meta-modelling cho việc mở rộng metamodel của BPMN cùng với các yêu cầu an ninh, trong đó, cho phép tích hợp các thuộc tính RBAC mở rộng vào BPM. Hình 2.1: Metamodel của BPMN tích hợp với một số chính sách an ninh[8] 2.2. Tích hợp RBAC vào Activiti Việc có thể tích hợp RBAC vào Activiti BPM, cần phải thực hiện một số thay đổi trên mã nguồn của Activiti : Mã nguồn của Activiti bao gồm ba mô-đun chính: mô-đun thiết kế, mô-đun thực thi và mô-đun quản lý. Trong đó, mô-đun thiết kế bao gồm tất cả các mô-đun con có tên bắt đầu “org.activiti.designer” được thiết kế dưới dạng các dự án Eclipse Plug-in. Mô-đun thực thi là “activiti-engine” cung cấp tất các chức năng cần thiết cho các mô-đun khác. Mô-đun quản lý là “activiti-webapp-activiti2” là một ứng dụng web cho việc triển khai quy trình sau khi mô hình hóa. 2.2.2. Mô hình hóa các chính sách truy nhập RBAC Các bước để tích hợp RBAC vào mô-đun thiết kế của Activiti bao gồm:  Bước 1: Sử dụng Eclipse EMF để mô hình hóa mô hình miền metamodel của RBAC. Sau khi EMF metamodel của RBAC được xây dựng, Eclipse EMF cho phép tự động sinh ra các lớp Java từ mô hình này. Bước này được thực hiện ở mô-đun “org.activiti.designer.model”.  Bước 2: Sử dụng các lớp Java được sinh ra từ mô hình để xây dựng các mô tả RBAC cho quy trình.  Bước 3: các lớp Java mô tả RBAC của quy trình cần được export dưới định dạng .xml cho phép triển khai trên Activiti Explorer 2.2.2.1. Xây dựng mô hình dữ liệu RBAC sử dụng Eclipse EMF  Tạo Ecore diagram : Mở mô-đun “org.activiti.designer.model”, chọn Folder “model” trong cửa sổ Package Explore > New/Other/ Ecore Tools/Ecore Diagram > đặt tên cho Ecore diagram là SecureBPMN20  Kéo thả các concept (Class, attribute, reference,..) từ Palette vào Visual Editor để xây dựng metamodel RBAC Hình 2.2: Ecore Diagram của RBAC trong Eclipse  Mô hình Ecore tương ứng thu được từ ecorediagram  Tạo EMF Generator Model: mã nguồn Activiti đã tạo ra file bpmn20.genmodel nên chỉ cần Reload dữ liệu là đủ. Chuột phải bpmn20.genmodel > Reload> chọn Ecore model > chọn tất cả các package xuất hiện > finish  Sinh code Java sau khi tạo được hai mô hình .ecore và .genmodel. Chuột phải nút gốc bpmn2 > Generate all 2.2.2.2. Xây dựng mô tả RBAC trong quy trình Mô-đun “activiti-engine” của Activiti thực hiện nhiệm vụ tạo các mô tả RBAC thông qua dữ liệu của các lớp Java được sinh ra từ mô hình. Mô tả RBAC được sinh ra từ việc người dùng kéo thả các component Security trong Palette và điền thông tin trong tab Security của Properties.  Xây dựng tab Security trong Palette: Có 2 chính sách RBAC là SoD và BoD tương ứng với 2 component sẽ được tạo trong tab Security. Các component này cần được định nghĩa hình dạng, kích thước và chức năng. Thông tin về chính sách an ninh được lưu trữ trong các lớp Java tương ứng là SeparationOfDuty và BindingOfDuty. Để biết 2 component này rằng buộc trên Activity nào của quy trình, SecurityFlow được sử dụng. Nguồn của SecurityFlow là SoD/BoD, đích của nó là UserTask cần bảo vệ.  Xây dựng tab Security của Properies: được khai báo trong plugin.xml. Các thuộc tính Security sẽ được định nghĩa trong lớp PropertyRbacSection. <propertyTab afterTab="org.activiti.designer.mainConfigTab" category="Activiti" id="org.activiti.designer.securityTab" label="Security"> <propertySection class="org.activiti.designer.security.property.PropertyRbacSection" filter="org.activiti.designer.security.property.PropertyRbacFilter" id="org.activiti.designer.securityTab.usertask" tab="org.activiti.designer.securityTab"> <propertySection class="org.activiti.designer.security.property.SodBodSection" filter="org.activiti.designer.security.property. SodBodFilter" id="org.activiti.designer.securityTab.sodbod" tab="org.activiti.designer.securityTab"> 2.2.2.3. Lưu mô tả RBAC dưới dạng xml Mô-đun “org.activiti.designer.export.bpmn20” thực hiện nhiệm vụ lưu toàn bộ mô tả về quy trình dưới dạng các lớp Java sang định dạng xml. Bao gồm export các thuộc tính Security trong tab Properties và export mô tả hình dạng, vị trí, kích thước các component Security trong Palette.  Export các thuộc tính Security trong tab Properties được mô tả bởi các lớp Java sinh ra từ mô hình: ... <seperationOfDuty id="Sod1" name="sod" outgoingSecurityFlow="sf1 sf2" permissions="perm_id_1 perm_id_2 dynamicEnforcement="false"> <securityFlow id="sf1" name="sf1" sourceRefNode="Sod1" targetRefNode="usertask2"> <pemission id="perm_id_1" pName="Perm-usertask1-Full Access" roles="role_id_1" actions="action_id_1"> <atomicActivityAction id="action_id_1" actionName="Full Access" activityId="usertask2" permissions=" perm_id_1"> ...  Export mô tả hình dạng, vị trí, kích thước các component Security trong Palette: <bpmndi:BPMNPlane bpmnElement="QuyTrinhDieuXe" id="BPMNPlane_QuyTrinhDieuXe"> ... ... Hàm writeBpmnElement thực hiện đọc tất cả các đối tượng trong sơ đồ Diagram, nếu một đối tượng là thể hiện của SecurityFlowNode thì nó sẽ được lưu các thông tin vị trí, kích thước trong tag xml “SecurityShape” : 2.2.3. Thực thi các chính sách truy nhập RBAC Các bước để tích hợp RBAC vào mô-đun quản lý của Activiti phục vụ cho việc thực thi các chính sách truy cập RBAC bao gồm:  Bước 1: “activiti-engine” phải cung cấp các chức năng khôi phục mô tả RBAC của quy trình từ fie xlml. Lớp BpmnParse thực hiện nhiệm vụ này.  Bước 2: Trong quá trình quy trình được chạy, các chính sách truy nhập RBAC phải được kiểm tra. SoD và BoD được kiểm tra khi người thực hiện UserTask được chọn để gán. Đầu tiên, hệ thống sẽ liệt kê tất cả người dùng có quyền thực hiện task này. Sau khi lựa chọn, hệ thống sẽ kiểm tra xem người dùng có thỏa mãn rằng buộc SoD hay BoD hay không bằng cách kiểm tra người đó có nằm trong danh sách người dùng có quyền thực hiện các task tiếp theo. Ví dụ, UserTaskA và UserTaskB bị rằng buộc SoD, khi gán người thực hiện UserTaskA hệ thống cũng sẽ liệt kê tất cả người có quyền thực hiện UserTaskB; nếu người được chọn thực hiện UserTaskA cũng nằm trong danh sách thực hiện UserTaskB thì sẽ vi phạm SoD và hệ thống hiển thị thông báo lỗi: không cho phép người dùng đó được thực Task. Hàm checkSoD trong lớp ReassignAssigneeListener thực hiện nhiệm vụ này. CHƯƠNG 3. CÀI ĐẶT VÀ THỰC NGHIỆM Kết quả của luận văn được triển khai thử nghiệm tại Trung tâm Tư vấn Thiết kế Mobifone – Chi nhánh Tổng Công ty Viễn thông Mobifone. Hiện tại, trong trung tâm đang thực thi rất nhiều quy trình nghiệp vụ, tuy nhiên, hầu hết các quy trình được thực hiện một cách thủ công và không hiệu quả dẫn đến việc quản lý trở nên khó khăn, thủ tục rườm ra, gây lãng phí tiền bạc và công sức. Yêu cầu cần có một công cụ tự động quá quy trình nghiệp vụ tại trung tâm. Với ưu điểm là đơn giản, triển khai nhanh chóng, Activiti BPM là lựa chọn phù hợp. Được sự cho phép của lãnh đạo trung tâm, tác giả đã triển khai thử nghiệm hai quy trình là quy trình điều xe và quy trình đặt văn phòng phẩm. Trong phạm vi luận văn, tác giả xin trình bày chi tiết việc triển khai quy trình điều xe. Các bước thực hiện bao gồm:  Bước 1: Cài đặt Activiti BPM trên server  Bước 2: Mô hình hóa quy trình trên Activiti Designer  Bước 3: Thực thi và giám sát quy trình trên Activiti Explorer 3.1. Mô hình hóa quy trình trên Activiti Designer Mô tả quy trình điều xe đang được thực hiện như sau:  Khi nhân viên có yêu cầu đặt xe, nhân viên làm giấy yêu cầu xin xe có chữ ký của người quản lý (trưởng phòng). Nếu trưởng phòng/giám đốc có yêu cầu đặt xe thì không cần chữ ký này.  Yêu cầu được chuyển sang nhân viên phòng tổng hợp để trình và chờ trưởng phòng tổng hợp điều xe.  Trưởng phòng tổng hợp sẽ xem xét và chỉ định xe  Nhân viên phòng tổng hợp gọi điện cho lái xe thông báo về thời gian. Quy trình điều xe trên sẽ được mô hình hóa trên Activiti Designer như sau:  Chạy Activiti Desginer trên Eclipse bằng cách chuột phải vào module “org.activiti.designer.eclipse” > Run As > Eclipse Appliction. Một giao diện Eclipse mới được mở ra.  Tạo dự án tên “TVTK_Project” mới : File > New > Others > Activiti Project  Tạo Diagram tên “QuyTrinhDieuXe” : chuột phải thư mục diagram chọn File > New > Others > Activiti Diagram  Giao diện mô hình hóa quy trình nghiệp vụ bao gồm Editor, Palette và Properties. Trong đó, Palette và Properties đã mở rộng thêm tab “Security” cho việc định nghĩa các chính sách an ninh SoD và BoD.  Kéo thả các component trong Palette để mô hình hóa quy trình điều xe. Các thuộc tính của từng component phải được cung cấp đầy đủ, bao gồm id, form,.. Sử dụng SeparationOfDuty và Security Flow để rằng buộc phân quyền đối với trưởng phòng và người quản lý điều xe. Hình 3.11: Quy trình điều xe trên Acitivi Designer  Một Form được sử dụng để mô tả phiếu yêu cầu. Để thêm/sửa/xóa các thuộc tính cho Form, nhấn chuột vào nút New/Edit/Delete. Form được cài đặt tại Start Event cho phép bất kỳ người dùng vào bắt đầu quy trình sẽ nhìn thấy Form và được yêu cầu điền thông tin. Hình 3.12: Khai báo các data objects của quy trình điều xe  Định nghĩa một exclusive gateway sau khi người dùng điền thông tin vào Form. Nó sẽ kiểm tra chức vụ của người yêu cầu là “Nhân viên” hay “Trưởng phòng”. Có hai đầu ra từ gateway, một nếu chức vụ là “Nhân viên” thì yêu cầu phải được chuyển đến trưởng phòng; hai nếu chức vụ đã là “Trưởng phòng” thì yêu cầu được chuyển trực tiếp đến quản lý điều xe. Hình 3.13: Cấu hình rẽ nhánh cho Gateway  Trường hợp chức vụ là nhân viên, yêu cầu sẽ được chuyển đến task Manager Aproval. Task này được gán cho người dùng hoặc nhóm người dùng có quyền thực hiện. Ngoài ra, task chỉ thực hiện đồng ý hoặc từ chối yêu cầu nền cần thuộc tính bắt buộc requestResult kiểu enum có hai giá trị true và false.  Để thiết lập Permission cho UserTask vào tab Security, chọn Action và Role và ấn nút Add. Một Permission được định nghĩa bởi một Action và một Role, một UserTask có thể chứa nhiều Permission.  Để rằng buộc người đã có quyền thực hiện task Manager Approval thì không thể là người quyền thực hiện task Car Supervisor Approval, SeparationOfDuty được sử dụng. SeparationOfDuty sử dụng các SecurityFlow để xác định các task phải rằng buộc; sau đó, liệt kê tất cả các Permission được định nghĩa trong các task; cuối cùng, lựa chọn các Permission mà SeparationOfDuty sẽ thực hiện. Hình 3.16: Cấu hình SeparationOfDuty  Nếu Manager đã đồng ý yêu cầu thì luồng sẽ chuyển đến Car Supervisor Approval - một UserTask, được cấu hình tương tự với Manager Approval.  Dựa vào quyết định của Manager và Car Supervisor mà quy trình sẽ tự động gửi thông báo bằng mail cho những người liên quan sử dụng Mail Task. Nếu yêu cầu được chấp nhận thì thông báo sẽ được gửi cho cả lái xe và người yêu cầu về lịch trình. Còn nếu yêu cầu bị từ chối thì người yêu cầu sẽ nhận được thông báo về lý do bị yêu cầu bị từ chối. Hình 3.18: Cấu hình MailTask 3.2. Thực thi và giám sát quy trình trên Activiti Explorer Quy trình điều xe trên sẽ được triển khai trên Activiti Designer như sau:  Đăng nhập hệ thống dưới vai trò Admin  Tạo các nhóm người dùng tương ứng với các vai trò trong quy trình: Staff, Manager và Car Supervisor. Vào Manage > Groups > Create Group.  Tạo người dùng và gán cho các nhóm người dùng: Vào Manage > Users > Create User.  Triển khai quy trình : Manage > Deployments > Upload New và lựa chọn tệp QuyTrinhDieuXe.bpmn20.xml đã được mô hình hóa trong Activti Designer. Sau đó, quy trình đã sẵn sàng được thực thi.  Thực thi quy trình : Bất kì người dùng nào trong tổ chức đăng nhập vào hệ thống đều có quyền đều có khởi tạo riêng một instance của quy trình cho yêu cầu của mình. Vào Process > Process definitions > chọn quy trình > Start process, một Form xuất hiện, người dùng cần điền đầy đủ thông tin. Hình 3.22: Biểu mẫu thông tin yêu cầu  Phê duyệt yêu cầu: Từ thông tin mà người yêu cầu xe cung cấp, hệ thống sẽ kiểm tra trường Role, nếu Role là Staff thì yêu cầu sẽ được chuyển cho người có vai trò Manager để phê duyệt. Người này đăng nhập hệ thống, vào Tasks > Queued. Do task này được gán cho Group nên chưa có một Assignee cụ thể nào được gán, vì vậy mọi thông tin trong task đều ẩn.  Gán người thực hiện quy trình: Khi nhấn Reassign, hệ thống sẽ bắt đầu kiểm tra chính sách an ninh của người được gán cho Task. Ở đây, Separation Of Duty được dùng để rằng buộc cho Manager và CarSupervisior nên bất kì người dùng nào thuộc cả hai nhóm này đều không có quyền thực hiện Task. Nếu user đăng nhập vi phạm: Hình 3.24: Thông báo vi phạm chính sách RBAC Còn nếu không vi phạm thì người đăng nhập có thể gán lại task cho người khác trong cùng nhóm. Một cửa sổ hiện lên danh sách người dùng thuộc nhóm. Nếu người đăng nhập lại chọn một user vi phạm Separation Of Duty thì thông báo lỗi lại hiện ra, còn không thì Task sẽ được gán cho user vừa được chọn. Khi user đó đăng nhập thì mọi thông tin trong task đều hiện lên và user có quyền thực hiện Task.  Gửi thông báo cho các bên liên quan: thực thiện bởi MailTask, cấu hình gửi mail được thiết lập trong Activiti Designer, kết quả nhận được là : Hình 3.27: Mail thông báo kết quả phê duyệt Như vậy, quy trình đã được triển khai công, các chính sách an ninh đã được kiểm tra trước khi gán cho người dùng. KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN BPM là một công cụ giúp cho việc quản lý và vận hành doanh nghiệp được hiệu quả hơn. Vấn đề an ninh là một trong các vấn đề quan trọng cần phải được xem xét trong tất cả các pha của vòng đời BPM và việc cài đặt chính sách an ninh vào BPM là thực sự cần thiết. Trong luận văn, tác giả đã trình bày phương pháp tích hợp các chính sách truy nhập (cụ thể là điều khiển truy nhập theo vai trò RBAC) vào pha mô hình hóa của vòng đời BPM bằng mở rộng ngôn ngữ BPMN 2.0 cho các yêu cầu an ninh. Ứng dụng phương pháp để mở rộng công cụ Activiti BPM cho việc cài đặt các chính sách an ninh. Tại pha mô hình hóa của Activti, xây dựng metamodel cho BPMN tích hợp RBAC và sinh ra cú pháp trừu tượng; sau đó, tại pha thực thi quy trình, kiểm tra một số chính sách an ninh trước khi phân quyền cho người sử dụng. Kết quả của luận văn đã được ứng dụng vào việc xây dựng một số quy trình nghiệp vụ tại Trung tâm Tư vấn Thiết kế Mobifone. Tuy nhiên, trong luận văn mới chỉ dừng lại ở bước tích hợp các chính sách an ninh vào pha mô hình hóa của BPM và tại pha thực thi, việc kiểm tra tính thỏa mãn của các chính sách an ninh khi phân quyền cho người dùng đang dừng lại ở các trường hợp đơn giản. Hệ thống lớn lên, các chính sách an ninh ngày càng phức tạp thì việc kiểm tra, phát hiện việc vi phạm các rằng buộc lại trở nên nan giải hơn. Ví dụ, trong trường hợp, người dùng được gán nhiều quyền, các quyền lại được kế thừa lẫn nhau, làm sao để kiểm tra người dùng có quyền thực thi quy trình hay không. Để giảm sự phức tạp của việc quản lý an ninh, cần phải sử dụng các công cụ hỗ trợ việc kiểm tra tính đúng đắn, tính toàn vẹn của các yêu cầu an ninh trong BPM. USE tool là một công cụ cho phép mô hình hóa phần mềm và kiểm tra tính chính xác của các mô tả UML, USE rất đơn giản và hiệu quả cho việc kiểm tra các chính sách an ninh. Vì vậy, hướng phát triển tiếp theo của luận văn là sử dụng USE tool cho việc thực thi chính sách an ninh của BPM. Hy vọng trong thời gian tới, tác giả có thể phát triển và hoàn thiện nội dung này. TÀI LIỆU THAM KHẢO [1] thieu-cua-doanh-nghiep-367.html , truy nhập lần cuối vào ngày 20/30/2018 [2] Steven Kelly, Juha-Pekka Tolvanen, “Domain-Specific Modeling” [3] American National Standards Institute Inc. Role Based Access Control, ANSI-INCITS 359-2004, 2004. [4] R. Sandhu, E. Coyne, H. Feinstein, C. Youman. Role-based access control models, IEEE Computer, vol. 29, no. 2, pp. 38–47, Feb. 1996. [5] Implementing Advanced RBAC Administration Functionality with USE, Tanveer Mustafa, Karsten Sohr, Duc-Hanh Dang, Michael Drouineaud, 2008 [6] Chu Thị Minh Huệ, Đặng Đức Hạnh, “Ngôn ngữ mô hình chuyên biệt miền cho mô hình bảo mật RBAC”, 2011 [7] Marlon Dumas, “Business Process Management Course - Lecture 1: Introduction to BPM” , 2014 [8] Alfonso RODRIGUEZ, Eduardo FERNANDEZ-MEDINA, Marlo PIATTINI, “A BPMN Extension for the Modeling of Security Requirement in Business Processes”, 2007 [9] Zakir Laliwala, Irshad Mansuri, Activiti 5.x Business Process Management, 2014 [10] https://en.wikipedia.org/wiki/Activiti_(software), truy cập lần cuối 21/03/2018 [11] Achim D.Brucker, Isabelle Hang, Gero Luckemeyer, Raj Ruparel “SecureBPMN: Modeling and Enforcing Access Control Requirements in Business Processes”, 2012