Đăng ký Đăng nhập
Trang chủ Giáo dục - Đào tạo Cao đẳng - Đại học Công nghệ thông tin Luận văn cntt mở rộng công cụ activiti cho đặc tả và cài đặt chính sách an ninh...

Tài liệu Luận văn cntt mở rộng công cụ activiti cho đặc tả và cài đặt chính sách an ninh

.DOCX
61
154
128

Mô tả:

ĐẠ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 LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN NGƯỜI HƯỚNG DẪN KHOA HỌC: TS. ĐẶNG ĐỨC HẠNH Hà Nội – 2018 L LỜI CAM ĐOAN Tôi xin cam đoan luận văn thạc sĩ “Mở rộng công cụ Activiti cho đặc tả và cài đặt chính sách an ninh” là công trình nghiên cứu của riêng tôi và được sự hướng dẫn của TS. Đặng Đức Hạnh. Các nội dung nghiên cứu và kết quả trong đề tài là trung thực và chưa từng được ai công bố trong bất kỳ công trình nào khác. Những phân tích, đánh giá được tác giả thu thập từ các nguồn khác nhau có ghi rõ trong tài liệu tham khảo. Học viên thực hiện Đỗ Anh Việt LỜI CẢM ƠN i Để hoàn thành được luận văn thạc sĩ, bên cạnh sự nỗ lực của bản thân còn có sự hướng dẫn nhiệt tình của quý Thầy Cô, cũng như sự động viên ủng hộ của gia đình và bạn bè trong suốt quá trình nghiên cứu và thực hiện luận văn. Tôi xin chân thành bày tỏ lòng biết ơn sâu sắc đến Thầy TS. Đặng Đức Hạnh, người đã tận tình hướng dẫn và tạo mọi điều kiện tốt nhất cho tôi hoàn thành luận văn này. Xin chân thành cảm ơn các thầy cô khoa Công nghệ thông tin, Trường đại học Công Nghệ đã truyền đạt những kiến thức quý báu cũng như giúp đỡ tôi trong quá trình học tập nghiên cứu tại trường. Xin chân thành cảm ơn Trung tâm Tư vấn Thiết kế Mobifone đã cho phép và tạo điều kiện để triển khai kết quả nghiên cứu của luận văn. Cuối cùng, xin gửi lời cảm ơn đến gia đình, bạn bè, đồng nghiệp, những người đã hỗ trợ tôi trong suốt quá trình học tập, nghiên cứu và thực hiện luận văn. Học viên thực hiện Đỗ Anh Việt MỤC LỤC ii Trang LỜI CAM ĐOAN............................................................................................................................i LỜI CẢM ƠN..................................................................................................................................ii MỤC LỤC.......................................................................................................................................iii DANH SÁCH CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT.....................................................v DANH SÁCH CÁC HÌNH VẼ................................................................................................vi MỞ ĐẦU...........................................................................................................................................1 CHƯƠNG 1. KIẾN THỨC NỀN TẢNG..............................................................................3 1.1. Giới thiệu chương.............................................................................................3 1.2. Mô hình hóa chuyên biệt miền............................................................................3 1.2.1. Khái niệm......................................................................................................3 1.2.2. Ngôn ngữ mô hình hóa chuyên biệt miền......................................................6 1.3. Mô hình hóa đặc tả chính sách truy nhập RBAC.................................................8 1.3.1. RBAC và các ràng buộc phân quyền.............................................................8 1.3.2. MetaModel cho RBAC................................................................................10 1.4. Mô hình hóa và thực thi quy trình nghiệp vụ với Activiti..................................11 1.4.1. Mô hình hóa quy trình nghiệp vụ................................................................12 1.4.2. Công cụ Activiti..........................................................................................17 1.5. Kết luận chương................................................................................................20 CHƯƠNG 2. TÍCH HỢP MÔ ĐUN CHÍNH SÁCH TRUY CẬP RBAC VỚI ACTIVITI........................................................................................................................................21 2.1. Giới thiệu chương..............................................................................................21 2.2. Phương pháp tích hợp RBAC vào BPM............................................................21 2.3. Tích hợp RBAC vào Activiti BPM....................................................................23 2.3.1. Một số khái niệm.........................................................................................24 2.3.2. Mô hình hóa các chính sách truy nhập RBAC.............................................25 2.4.3. Thực thi các chính sách truy nhập RBAC...................................................35 2.4. Tổng kết chương................................................................................................37 CHƯƠNG 3. CÀI ĐẶT VÀ THỰC NGHIỆM.................................................................38 3.1. Giới thiệu chương..............................................................................................38 iii 3.2. Bài toán vận tải..................................................................................................38 3.3. Cài đặt trên Activiti...........................................................................................39 3.3.1. Cài đặt Activiti BPM...................................................................................39 3.3.2. Mô hình hóa quy trình trên Activiti Designer..............................................41 3.3.3. Triển khai quy trình trên Activiti Explorer..................................................47 3.4. Kết quả thực nghiệm..........................................................................................48 3.5. Tổng kết chương................................................................................................52 KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN..........................................................................53 TÀI LIỆU THAM KHẢO.........................................................................................................54 DANH SÁCH CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT iv Từ viết tắt API Ý nghĩa Thuật ngữ Application Programming Interface BoD Binding Of Duty BPM Business Process Management BPMN Business Process Model and Notation DSM Domain-Specific Modeling DSML Domain-Specific Modeling Language EMF PEP SoA SLA SoD Eclipse Model Framework Policy Enforcement Point Service Oriented Architecture Service-level agreement Separation Of Duty Giao diện lập trình ứng dụng Ràng buộc các nhiệm vụ được thực hiện bởi một người Quản lý quy trình nghiệp vụ Tiêu chuẩn và mô hình quy trình nghiệp vụ Mô hình hóa chuyên biệt miền Ngôn ngữ mô hình hóa chuyên biệt miền Nền tảng mô hình hóa Eclipse Điểm thực thi chính sách Kiến trúc hướng dịch vụ Cam kết chất lượng dịch vụ Tách biệt nhiệm vụ Điều khiển truy cập dựa theo vai trò RBAC Role-Based Access Control REST REpresentational State Transfer Web Services Business Process Ngôn ngữ thực thi quy trình Execution Language nghiệp vụ bằng Web services eXtensible Access Control Markup Language WSBPEL XACML DANH SÁCH CÁC HÌNH VẼ 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ủa chúng Hình 1.2: Kiến trúc cơ bản của DSM v Hình 1.3: Core RBAC Hình 1.4: MetaModel của RBAC Hình 1.5: MetaModel 2 của RBAC Hình 1.6: Quy trình nghiệp vụ Hình 1.7: Vòng đời BPM Hình 1.8: Metamodel của BPMN Hình 1.9: Các thành phần của Activiti Hình 1.10: Các thành phần của Activiti Engine Hình 2.1: Yêu cầu an ninh kết hợp với ký hiệu Hình 2.2: Metamodel của BPMN tích hợp với một số chính sách an ninh Hình 2.3: Ecore Diagram của RBAC trong Eclipse Hình 2.4: Mô hình Ecore của RBAC thu được từ EcoreDiagram Hình 2.5: Lớp JAVA được sinh ra từ mô hình Hình 2.6: Tab Security trong Patelle Hình 2.7: Tab Security trong Properties Hình 3.1: Cơ cấu tổ chức trung tâm Tư vấn Thiết kế Hình 3.2: Màn hình đăng nhập Activiti Designer Hình 3.3: Màn hình quản lý Task trên Activiti Designer Hình 3.4: Màn hình quản lý Process trên Activiti Designer Hình 3.5: Màn hình quản lý cấu hình trên Activiti Designer Hình 3.6: Tạo dự án Activti BPM trên Eclipse Hình 3.7: Tạo sơ đồ Activiti Diagram trên Eclipse Hình 3.8: Visual Editor của Activiti Hình 3.9: Quy trình điều xe trên Activiti Designer Hình 3.10: Khai báo các data objects của quy trình điều xe Hình 3.11: Cấu hình rẽ nhánh cho Gateway Hình 3.12: Cấu hình kết quả phê duyệt của Manager Approval Hình 3.13: Cấu hình Security cho Manager Approval Hình 3.14: Cấu hình SeparationOfDuty vi Hình 3.15: Cấu hình Form thông tin của CarSupervisor Approval Hình 3.16: Cấu hình MailTask Hình 3.17: Tạo nhóm người dùng trên Activiti Explorer Hình 3.18: Tạo người dùng trên Activiti Explorer Hình 3.19: Triển khai quy trình trên Activit Explorer Hình 3.20: Biểu mẫu thông tin yêu cầu Hình 3.21: Màn hình Task Manager Approval Hình 3.22: Thông báo vi phạm chính sách RBAC Hình 3.23: Chọn người thực hiện Task Hình 3.24: Thực hiện phê duyệt yêu cầu Hình 3.25: Mail thông báo kết quả phê duyệt Hình 3.26: Thống kê số lần quy trình được thực hiện theo tháng vii 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 Để có thể triển khai thì trước tiên quy trình nghiệp vụ phải được mô hình hóa. Mô hình hóa quy trình nghiệp vụ không những được sử dụng trong việc trao đổi các yêu cầu giữa chuyên gia nghiệp vụ và chuyên gia hệ thống mà còn được sử dụng để cài đặt hệ thống thực tế. Các quy trình nghiệp vụ hiện đại thường kết hợp các tác vụ của con người với các tác vụ tự động (ví dụ, được cài đặt bởi webservice), nên ngôn ngữ mô hình hóa quy trình nghiệp vụ cần phải thu hẹp khoảng cách giữa giữa chuyên gia nghiệp vụ và chuyên gia hệ thống [2]. 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ụ [2]. 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 [3,4]. 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 tích hợp đầy đủ điều khiển truy cập theo vai trò RBAC [5]. Chính vì vậy, tôi 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”. Trong luận văn, tôi đã trình bày một phương pháp tích hợp chính sách an ninh RBAC vào quy trình nghiệp vụ BPM bằng cách mở rộng tiêu chuẩn BPMN cho đặc tả các chính sách an ninh [2], đồng thời ứng dụng của phương pháp này vào việc mở rộng công cụ Activiti BPM cho đặc tả và cài đặt RBAC dựa vào [5]. Kết quả cụ thể đạt được: thứ nhất, tích hợp các chính sách RBAC vào pha mô hình hóa để các yêu cầu an ninh có thể được xem xét ngay từ đầu. Thứ hai, đã kiểm tra các chính sách đó tại pha thực thi để đảm bảo an toàn an ninh cho hệ thống. 1 Về phần bố cục, luận văn được chia thành 3 chương chính như sau: Chương 1. Kiến thức nền tảng : Trình bày cơ sở lý thuyết và các công nghệ chính được sử dụng trong luận văn. Bao gồm: Mô hình hóa chuyên biệt miền, mô hình hóa đặc tả chính sách truy cập RBAC, mô hình hóa quy trình nghiệp vụ và cuối cùng, giới thiệu về công cụ mã nguồn mở Activiti BPM Chương 2. Tích hợp mô đun chính sách truy cập RBAC với Activiti : Trình bày phương pháp tích hợp chính sách an ninh vào quy trình nghiệp vụ và ứng dụng của phương pháp vào việc tích hợp chính sách truy cập RBAC vào Activiti BPM Chương 3. Cài đặt và thực nghiệm : Trình bày bài toán vận tải hiện đang được triển khai tại Trung tâm Tư vấn Thiết kế Mobifone, ứng dụng kết quả của luận văn để giải quyết bài toán và cài đặt trên Activiti BPM. Cuối cùng là các kết quả đạt được. 2 CHƯƠNG 1. KIẾN THỨC NỀN TẢNG 1.1. Giới thiệu chương Chương này sẽ trình bày cơ sở lý thuyết và các công nghệ chính được sử dụng trong luận văn. Bao gồm ba nội dung chính là:  Mô hình hóa chuyên biệt miền: các khái niệm và kiến trúc của DSM; cú pháp và ngữ nghĩa của một ngôn ngữ mô hình hóa chuyên biệt miền DMSL.  Mô hình hóa và đặc tả chính sách truy cập RBAC: các khái niệm cơ bản về Core RBAC và ràng buộc phân quyền. Từ đó, xây dựng mô hình metamodel cho RBAC.  Mô hình hóa và thực thi quy trình nghiệp vụ với Activiti BPM: khái niệm, thành phần, vòng đời và tiêu chuẩn ký hiệu BPMN của quy trình nghiệp vụ. Cuối cùng, giới thiệu công cụ mã nguồn mở Activti BPM cho việc mô hình hóa và thực thi quy trình nghiệp vụ một cách tự động. 1.2. 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. Do đó, 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 [6]. 1.2.1. Khái niệm DSM chủ yếu tập trung vào hai vấn đề. Đầu tiên, nâng cao mức độ trừu tượng trên cả lập trình bằng cách xác định một ngôn ngữ trực tiếp sử dụng các khái niệm và các luật từ miền vấn đề cụ thể. Thứ hai, tạo ra sản phẩm cuối cùng trong một ngôn ngữ lập trình đã chọn hoặc một hình thức khác từ các đặc tả mức cao đó. Thông thường, bộ sinh code tiếp tục được hỗ trợ bởi một số nền tảng (framework). Tự động hóa phát triển phần mềm có thể trở nên phổ biến bởi vì ngôn ngữ mô hình hóa, bộ sinh code và code của framework đã phù hợp với các yêu cầu của miền ứng dụng. Nói cách khác chúng là chuyên biệt miền và chúng hoàn toàn được kiểm soát bởi người dùng. Các mức độ trừu tượng cao Sự trừu tượng rất quan trọng trong phát triển phần mềm. Trong suốt lịch sử phát triển phần mềm, nâng cao mức độ trừu tượng là nguyên nhân của các bước nhảy vọt trong hiệu suất của nhà phát triển. Nếu nâng cao mức độ trừu tượng làm giảm tính phức tạp thì làm sao để tiếp tục nâng cao nó. Hình 1.1 thể hiện, các nhà phát triển tại 3 các thời điểm khác nhau đã thu hẹp khoảng cách trừu tượng giữa ý tưởng trong miền và cài đặt của chúng. 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ủa chúng Bước đầu tiên trong phát triển bất kỳ phần mềm nào luôn là nghĩ về giải pháp liên quan đến miền vấn đề - một giải pháp ở mức độ trừu tượng cao nhất (bước 1). Ví dụ, quyết định nên hỏi tên người trước hay hỏi phương thức thanh toán trước trong khi đăng ký một hội thảo. Sau khi tìm ra giải pháp sẽ ánh xạ sang đặc tả của một số ngôn ngữ (bước 2). Trong lập trình truyền thống, bước này các nhà phát triển ánh xạ các khái niệm miền vào việc code các khái niệm. Trong UML hoặc các ngôn ngữ mô hình hóa mục đích chung khác, các nhà phát triển ánh xạ giải pháp miền vấn đề vào đặc tả trong ngôn ngữ mô hình hóa. Bước 3, cài đặt đầy đủ giải pháp: đưa ra các điều kiện đúng và nội dung code cho các vòng lặp. Tuy nhiên, nếu sử dụng các ngôn ngữ mô hình hóa mục đích chung, thì cần ánh xạ bổ sung từ mô hình sang code. Điều đáng chú nhất ở đây là các nhà phát triển vẫn phải thực hiện từ bước 1 mà không có bất kì công cụ nào hỗ trợ, đặc biệt để giải quyết các lỗi phát sinh trong giai đoạn phát triển thường tốn nhiều chi phí nhất. Tự động sinh code Trong bước 3, việc sinh code tự động từ thiết kế UML là không thể. Thay vì yêu cầu nhà phát triển nắm vững cả miền vấn đề và lập trình, một giải pháp tốt hơn cho phép các nhà phát triển đặc tả ứng dụng dưới dạng đã từng biết và sử dụng, sau đó có các bộ sinh code sử dụng các đặc tả đó và tạo ra cùng loại code giống như họ viết bằng tay. Điều này sẽ làm tăng mức độ trừu tượng đáng kể; từ việc lập trình với byte/bit, thuộc tính và kết quả trả về; lên đến các khái niệm và luật lệ của miền vấn đề mà các nhà phát triển đang làm việc với. Sau đó, ngôn ngữ lập trình mới này hợp nhất với bước 1 và bước 2 và tự động hóa hoàn toàn ở bước 3. Mức độ trừu tượng được nâng lên gắn liền với code được sinh tự động là mục đích của DSM. 4 DSM không kỳ vọng rằng tất cả code có thể được sinh ra từ các mô hình nhưng bất cứ gì mô hình hóa được từ quan điểm của người mô hình hóa thì đều sinh ra code hoàn chỉnh. Trong DSM, code được sinh ra dễ đọc và hiệu quả - lý tưởng là giống như code được viết bởi những nhà phát triển giàu kinh nghiệm, những người định nghĩa ra bộ sinh code. Code được sinh ra thường được hỗ trợ bởi framework với mục đích nhất định cũng như bởi các nền tảng, thư viện, thành phần và các code kế thừa khác. Bộ sinh code không chỉ giới hạn bất kì ngôn ngữ hay kiểu lập trình nào. Ví dụ kết quả của bộ sinh code có thể là ngôn ngữ lập trình hướng đối tượng hoặc ngôn ngữ lập trình cấu trúc hay chức năng, nó có thể là ngôn ngữ lập trình truyền thống, một ngôn ngữ kịch bản, các định nghĩa dữ liệu hoặc một file cấu hình. Tóm lại, 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ế (thường là các sản phẩm trong một công ty). 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 đó. Kiến trúc của DSM gồm 3 thành phần chính là ngôn ngữ, bộ sinh code và framework miền như hình 1.2 : 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ữ 5 lập trình nhất định. Nhìn chung, các khái niệm miền chính ánh xạ lên các đối tượng của ngôn ngữ mô hình hóa, trong khi các khái niệm miền khác sẽ được coi như thuộc tính đối tượng, các kết nối, các mô hình con hoặc các đường dẫn đến mô hình. Bởi vậy, ngôn ngữ này cho phép nhà phát triển làm việc trực tiếp với các khái niệm miền. Ngôn ngữ này được định nghĩa như một metamodel với các ký hiệu và công cụ hỗ trợ. 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ố. Bộ sinh code cũng có thể tạo ra các code khác nhau phụ thuộc vào các giá trị trong symbol, các mối quan hệ nó có với các symbol khác, hoặc thông tin khác trong mô hình. Code này sẽ được liên kết với framework và được biên dịch thành mã thực thi hoàn chỉnh. Trong giải pháp DSM, mục tiêu chính là sau khi sinh code không cần bổ sung code bằng tay để thay đổi và mở rộng code đã sinh. Bởi vậy, code đã sinh chỉ đơn giản là một sản phẩm trung gian trên con đường đưa ra sản phẩm cuối cùng. 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. Trong một số trường hợp, không cần thêm code của framework: code sinh ra có thể trực tiếp gọi các thành phần nền tảng nếu nó có đủ các dịch vụ. Mặc dù vậy, việc định nghĩa code hoặc thành phần tiện ích bổ sung giúp code sinh ra dễ dàng hơn. 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. Điều này được sử dụng bất kể việc cài đặt được thực hiện như thế nào, bằng tay hay sử dụng các bộ sinh. Sản phẩm đã phát triển có thể sử dụng một phần của một nền tảng lớn (như J2EE), toàn bộ nền tảng (như Tomcat server) hay một số nền tảng khác. 1.2.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 gia 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. Còn ngữ nghĩa biểu diễn ý nghĩa của các cụm từ và câu mà chuyên gia miền muốn diễn đạt. Để tăng sự trừu tượng thiết kế, cần mở rộng cả cú pháp và ngữ nghĩa. 6 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. Tuy nhiên, tự nó không liên quan đến cấu trúc có ý nghĩa gì. 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ủa một ngôn ngữ chuyên biệt miền có ý nghĩa không chỉ là các từ dành riêng mà thường được xem như các quy tắc (rule) ngữ pháp cần được tuân theo trong khi xác định mô hình. Các quy tắc này bắt nguồn từ miền và chúng ràng buộc việc mô hình được tạo ra như thế nào: định nghĩa các giá trị, các mối quan hệ giữa các khái niệm và các khái niệm nhất định được sử dụng như thế nào. Một khi các quy tắc được định nghĩa, ngôn ngữ mô hình hóa của công cụ hỗ trợ sẽ đảm bảo tất cả các nhà phát triển tuân theo cùng các quy tắc đó trong miền. Việc có các quy tắc sẽ giảm đáng kể không gian thiết kế, giúp cho cài đặt của bộ sinh trở nên dễ dàng hơn do các bộ sinh không cần bắt đầu bằng việc kiểm tra lại tính chính xác của mô hình. Trong DSM, các quy tắc được kiểm tra sớm nhất có thể bởi vì việc phát hiện và ngăn nữa lỗi ở mô hình sẽ đơn giản và hiệu quả chi phí hơn việc tìm lỗi trong code đã sinh. Ngôn ngữ metamodel được sử dụng để xác định cú pháp trừu tượng của ngôn ngữ mô hình hóa. Một metamodel là một mô hình của ngôn ngữ mô hình hóa chứa tất cả các thuộc tính và tính năng cần thiết bao gồm các khái niệm ngôn ngữ mà nó hỗ trợ, cú pháp và ngữ nghĩa. Cú pháp cụ thể: Cú pháp và ngữ nghĩa thuần không đủ cho việc định nghĩa ngôn ngữ: mô hình phải được truy cập thông qua một vài dạng trực quan. 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. Mỗi ngôn ngữ mô hình hóa tuân theo một số dạng biểu diễn cũng với một ký hiệu. Dạng biểu diễn của hầu hết các ngôn ngữ mô hình hóa là đồ họa kết hợp với text. Các ngôn ngữ mô hình hóa cũng có thể dựa trên các dạng khác như ma trận, bảng biểu và các biểu mẫu hoặc là văn bản thuần túy. Lựa chọn ký hiệu cho ngôn ngữ DSM nên gắn liền với biểu diễn thực tế của các khái niệm miền, ví dụ nút điều khiển trong hệ thống giải trí xe nên giống với nút điều khiển trong ngôn ngữ mô hình hóa. Một cách lý tưởng, mỗi khái niệm trong ngôn ngữ mô hình hóa nên có ký hiệu biểu diễn chính xác nó. Nguyên tắc này tối thiểu hóa sự quá tải các ký tự và đảm bảo rằng tất cả các khái niệm có thể được biểu diễn trong ngôn ngữ. 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 đề. Ví dụ, 7 nếu phát triển một hệ thống giải trí cho xe, các khái niệm mô hình hóa như “menu”, “event”,..đã có ý nghĩa rõ ràng trong miền ứng dụng. Sử dụng ngữ nghĩa miền trong ngôn ngữ không chỉ giới hạn là các khái niệm miền mà còn bao gồm các kết nối giữa kiến trúc mô hình hóa cũng như các quy tắc liên quan. Ví dụ, ở hệ thống giải trí cho xe ở trên, một “menu” có thể kích hoạt một hành động hoặc mở ra một submenu thì trong ngôn ngữ mô hình chuyên biệt miền một menu có thể kết nối đến một hành động hoặc một menu khác. Ngữ nghĩa của miền vấn đề không phải là nguồn duy nhất cho ngữ nghĩa DSM. Giống như sinh code đích cho tất cả ngôn ngữ mô hình hóa, nhất thiết phải nhận ra ngữ nghĩa của phía cài đăt; làm sao các kiến trúc mô hình được ánh xạ lên miền vấn đề. Sự ánh xạ này được thực hiện không chỉ trên miền vấn đề mà còn trên các ngôn ngữ lập trình khác. Sau đó, ngôn ngữ mô hình hóa sẽ thực sự được ánh xạ 1-1 lên ngôn ngữ lập trình được sinh ra. Sự trừu tượng là giống nhau và code sinh ra là tối thiểu. Một ví dụ điển hình là việc ánh xạ một lớp trong sơ đồ sang một lớp trong code. Nhà phát triển người mà tạo ra mô hình đã nghĩ về các khái niệm và ngữ nghĩa của code. Nếu muốn tăng mức độ trừu tượng và cải thiện hiệu suất, ngữ nghĩa của miền vấn đề có quan hệ nhiều hơn ngữ nghĩa của miền giải pháp. 1.3. Mô hình hóa đặc tả chính sách truy nhập RBAC Việc sử dụng các cơ chế kiểm soát truy nhập trong các tổ chức có quy mô từ trung bình đến lớn luôn là một vấn đề rất quan trọng. Nghiên cứu [3,4] cho thấy điều khiển truy nhập dựa trên vai trò RBAC là một mô hình hiệu quả và linh hoạt cho việc kiểm soát truy nhập vào các nguồn tài cần được bảo vệ và việc thực thi chính sách các chính sách an ninh của tổ chức. 1.3.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. Core RBAC được yêu cầu trong bất kì hệ thống RBAC nào nhưng các thành phần khác độc lập với nhau và có thể được cài đặt riêng rẽ. Các tập phần tử và các mối quan hệ của mô hình Core RBAC được thể hiện trong hình 3. 8 Hình 1.3: Core RBAC Core RBAC bao gồm các tập của 5 phần tử dữ liệu cơ bản được gọi là user (USERS), roles (ROLES), objects (OBS), operations (OPS) và permissions (PRMS).  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. Trong hệ thống cài đặt RBAC, đối tượng có thể là 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. Tổng thể mô hình RBAC được định nghĩa dưới dạng từng USERS được gán cho ROLES và PRMS được gán cho ROLES. Như vậy, ROLES là phương tiện để đặt tên cho các quan hệ nhiều – nhiều giữa USERS và PRMS. Ngoài ra, mô hình Core RBAC còn bao gồm 1 tập các phiên làm việc (SESSIONS) mà mỗi phiên là một sự ánh xạ giữa USER và một tập các ROLE con đã kích hoạt được gán cho USER. 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. Tượng tự, 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 9 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, ví dụ vai trò của bác sĩ trưởng khoa kế thừa tất cả các quyền từ vai trò của bác sĩ . Authorizaiton Constraints là một khía cạnh quan trọng của RBAC và thỉnh thoảng được xem như là động lực chính đằng sau RBAC[7]. 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. Trong đó, SoD (tách biệt nhiệm vụ) là nguyên tắc cơ bản trong các hệ thống an ninh, các hành động bắt buộc được chia cho hai hoặc nhiều người khác nhau thực hiện để không có cá nhân nào có thể tự thỏa hiệp an ninh. Ví dụ, trong một tổ chức yêu cầu không có người dùng nào được gán 3 trong 4 vai trò cho chức năng mua hàng tức là vừa đăng ký yêu cầu mua hàng và vừa phê duyệt yêu cầu. Các ràng buộc SoD được sử dụng để thực thi các chính sách mâu thuẫn với lợi ích. Một phương tiện để ngăn chặn mâu thuẫn lợi ích thông qua SoD tĩnh, nghĩa là thực thi các ràng buộc về gán USERS cho ROLES. Mặt khác, các ràng buộc SoD động giới hạn PRMS có sẵn cho một USER bằng cách đặt các ràng buộc trên các ROLES được kích hoạt trong phiên làm việc của USER. 1.3.2. MetaModel cho RBAC Metamodel là một mô hình của ngôn ngữ mô hình hóa. Một metamodel của RBAC với các khái niệm tương ứng : Subject (mở rộng khái niệm User thành các đối tượng cùng vai trò có thể là User hoặc nhóm User được gọi là Group), Role, Permission, Action, Authorization, Resource và mối quan hệ giữa các khái niệm gọi là references. Ví dụ, một User có nhiều vai trò, tương ứng với reference là asignRole. Hình 1.4: MetaModel của RBAC 10 Một Permission là một đối tượng kết nối một Role tới một tập Action được thực hiện trên một Resource của hệ thống. Ngữ nghĩa của Permission được xác định bởi thành phần Action. Mỗi Action đại diện cho mỗi kiểu hành động an ninh thích hợp trên tài nguyên được bảo vệ, ví dụ như việc thực thi phê duyệt quy trình. Action cũng có thể đại diện cho nhiều lớp khái niệm của các hoạt động ở mức trừu tượng cao. Mỗi lớp có thể có nhiều phương thức và thuộc tính. Lớp này được gán cho Permission cho phép Permission có quyền gọi tất cả các phương thức và đọc các giá trị của tất cả các thuộc tính của lớp. Ví dụ, trong quy trình quản lý nghiệp vụ, Action là lớp cha đại diện cho nhiều lớp Action như ActivityAction, ProcessAction, mỗi lớp Action con chứa các phương thức và thuộc tính đại diện cho các hành động trên tài nguyên của quy trình. AuthorizationContraint là một phần của chính sách kiểm soát truy cập thể hiện điều kiện tiên quyết đối với mọi lời gọi thực hiện hành động của tài nguyên cụ thể thông qua việc gán nó cho các Permission. Ví dụ, SoD được gán cho một Permission A và Permission B để ràng buộc người thực hiện hai permission này phải khác nhau; ngược lại nếu BoD được gán cho hai permission này thì bắt buộc người thực hiện permision A cũng phải thực hiện luôn permission B. Các khái niệm RBAC được đại diện trực tiếp như các kiểu metamodel. Để xây dựng mô hình, cần phải thêm vào trong miền các khái niệm đại diện cho mô hình và các thuộc tính, kiểu thuộc tính, cuối cùng là các khái niệm trừu tượng của miền [1]. Kết quả thu được là MetaModel 2 của RBAC như sau: Hình 1.5: MetaModel 2 của RBAC 1.4. Mô hình hóa và thực thi quy trình nghiệp vụ với Activiti Môi trường kinh doanh hiện nay ngày càng trở nên gay gắt, doanh nghiệp luôn phải thay đổi để thích nghi và thỏa mãn nhu cầu của khách hàng. Nhằm xây dựng và duy trì lợi thế cạnh tranh của mình, doanh nghiệp cũng cần liên tục cải tiến các quy trình nghiệp vụ và BPM là một công cụ đắc lực hỗ trợ việc tối ưu các quy trình trong bộ máy vận hành của doanh nghiệp. 11
- Xem thêm -

Tài liệu liên quan