Tóm tắt Luận văn Thạc sĩ Công nghệ thông tin: Mở rộng công cụ activiti cho đặc tả và cài đặt chính sách an ninh
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (971.8 KB, 25 trang )
ĐẠ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.
id="org.activiti.designer.securityTab"
label="Security">
</propertyTab>
filter="org.activiti.designer.security.property.PropertyRbacFilter"
id="org.activiti.designer.securityTab.usertask"
tab="org.activiti.designer.securityTab">
</propertySection>
filter="org.activiti.designer.security.property. SodBodFilter"
id="org.activiti.designer.securityTab.sodbod"
tab="org.activiti.designer.securityTab">
</propertySection>
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>
</securityFlow>
<role id="role_id_1" name="Manager" permissions="perm_id_1"></role>
</atomicActivityAction>
...
</process>
Export mô tả hình dạng, vị trí, kích thước các component Security
trong Palette:
<bpmndi:BPMNDiagram id="BPMNDiagram_QuyTrinhDieuXe">
...
<bpmndi:SecurityShape securityElement="Sod1" id="SS_Sod1">
<omgdc:Bounds height="60" width="60" x="372" y="237">
</omgdc:Bounds>
</bpmndi:SecurityShape>
<bpmndi:SecurityEdge securityElement="sf1" id="sf1">
<omgdi:waypoint x="402" y="237"></omgdi:waypoint>
<omgdi:waypoint x="544" y="225"></omgdi:waypoint>
</bpmndi:SecurityEdge>
...
</bpmndi:BPMNPlane>
</bpmndi:BPMNDiagram>
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] , 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] 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
