Tải bản đầy đủ - 0 (trang)
CHƯƠNG 1. KIẾN THỨC NỀN TẢNG

CHƯƠNG 1. KIẾN THỨC NỀN TẢNG

Tải bản đầy đủ - 0trang

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ữ chun 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 chun biệt miền

Ngơn ngữ chun 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 chun gian miền. Trong mơ hình hóa chun 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 hồ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 ln 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 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ụ hồn tồ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

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, ngồi ra, áp đặt các 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à chun 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 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.



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

CHƯƠNG 1. KIẾN THỨC NỀN TẢNG

Tải bản đầy đủ ngay(0 tr)

×