Bảng 4-4: Một số quy tắc truy nhập cho Ví dụ 4-4
Quy tắc Biểu thức
r1: luồng công việc yêu cầu có ít nhất bốn người dùng tham gia (một người nhận và kiểm tra bài báo, hai người phản biện, và một người nữa sẽ quyết định cuối cùng).
r1: cannot_access(_, r, _, _) ← type(r)='workflow', card(getRoles(r)) < 4 ;
r2: người dùng mà nhận bài (T1) cũng sẽ kiểm tra sơ bộ bài đó (T2).
r2: cannot_access(s, getCurrentTasks(r), {RUN},_) ← type(r)='workflow', not
isRun(s, r, T1), getTask-
Name(getCurrentTask(r)) = T2 r3: Hai tác giả phản biện các bài (T3 và T4)
phải là hai người khác nhau.
r3: cannot_access(s, getCurrentTasks(r), {RUN},_) ← type(r)='workflow',
isRun(s, r, T3), getTask-
Name(getCurrentTask(r)) = T4;
r3.2: cannot_access(s, getCurrentTasks(r), {RUN},_) ← type(r)='workflow', isRun(s, r, T4), getTask-Name(getCurrentTask(r)) = T3;
123
Thành phần chính trong thiết kế này là Security component, được thiết kế tuân theo kiến trúc tiêu chuẩn của các hệ thống ABAC (attributed-based access control) XACML (eXtensible Access Control Markup Language) [43], bao gồm ba module:
- PEP (Policy Enforcement Point): module thực hiện các điều khiển truy nhập, bao gồm các bước như sau: đầu tiên, nó tiếp nhận các lời gọi của các dịch vụ bên ngoài (data flow (1)) từ các tiến trình trong G-ODE engine. Sau đó, các lời gọi này sẽ được dịch thành các yêu cầu (requests) ở dạng chuẩn (well-defined forms) (luồng dữ liệu (2)). Các yêu cầu này sau đó sẽ được chuyển cho module PDP.
- PDP (Policy Decision Point): Sau khi tiếp nhận các yêu cầu từ PEP, module này sẽ đánh giá chúng dựa trên các chính sách an ninh (bao gồm tập các quy tắc truy nhập), để từ đó đưa ra quyết định trả về cho PEP (luồng dữ liệu (3)). Quyết định này thường là chấp nhận hoặc từ chối truy nhập.
- PIP (Policy Information Point): module này hoạt động như một nguồn giá trị cho các thuộc tính. Nó cũng chứa tập các hàm tiện ích của hệ thống.
Ý nghĩa của các luồng dữ liệu trao đổi giữa các module (từ (1) đến (6)) được tóm tắt trong Bảng 4-5.
Bảng 4-5: Ý nghĩa của các luồng dữ liệu trong Hình 4-8.
Luồng dữ liệu Ý nghĩa
(1) Từ một tiến trình trong G-ODE engine, tiến hành gọi một dịch vụ bên ngoài. Dịch vụ được gọi có thể là Web service hoặc Grid service.
(2) Yêu cầu gọi được dịch ra bởi PEP.
(3) Trả lời cho yêu cầu gọi do PDP trả về cho PEP. Đọc nội dung này, PEP sẽ biết được quyết định của PDP là chấp nhận hay từ chối yêu cầu gọi. Trong trường hợp chấp nhận, lời gọi sẽ được chuyển hướng đến địa chỉ thực gọi của nó (là một Web service hoặc Grid service) (nằm ở luồng dữ liệu số (4)). Trái lại, PEP sẽ thông báo cho G-ODE về sự từ chối truy nhập và lý do từ chối (nằm trong luồng dữ liệu số (6)).
(4) Chuyển hướng lời gọi được gửi bởi PEP.
(5) Trong trường hợp lời gọi là hướng đến Grid service, sẽ được kiểm tra thêm một lần nữa bởi Hạ tầng An ninh lưới (Grid Security Infrastructure - GSI) để xem có tuân theo các chính sách an ninh của lưới không. Nếu vi phạm, lỗi truy nhập sẽ được gửi lại cho PEP bởi luồng dữ liệu này. (6) Chứa thông tin từ chối từ PDP hoặc từ GSI.
4.3.2.4 Các nghiên cứu liên quan
Trong [8], mô hình RBAC mở rộng (extended role based access control - ERBAC) đã được đề xuất nhằm khắc phục hạn chế trong các mô hình RBAC trước: chưa thể biểu diễn
124
các ràng buộc trên các vai trò (roles). Các loại ràng buộc này, ví dụ như ràng buộc phân chia công việc (separation of duties), khá phổ biến trong các tiến trình nghiệp vụ trong thực tế. Để giải quyết vấn đề này, đầu tiên các tác giả trong [8] đã phân tích nhiều loại ràng buộc cấp quyền (authorization constraints), phân chia chúng thành ba nhóm: tĩnh (static), động (dynamic) và lai (hybric). Các ràng buộc tĩnh có thể được kiểm tra trước khi hoặc không cần sự hoạt động của workflow. Trong khi đó, việc kiểm tra các ràng buộc động đòi hỏi sự hoạt động của workflow, vì nó phụ thuộc vào lịch sử của hoạt động. Các ràng buộc lai là sự kết hợp của cả hai loại ràng buộc tĩnh và động. Từ những phân tích trên, một ngôn ngữ mới dựa trên chương trình logic (logic program) đã được giới thiệu, nhằm biểu diễn cho các loại ràng buộc. Tuy nhiên, các vấn đề ràng buộc liên quan đến môi trường lưới và dịch vụ lưới lại chưa được đề cập đến trong nghiên cứu này. Do đó, việc áp dụng ngôn ngữ này ra sao để giải quyết vấn đề trên dường như vẫn chưa rõ ràng. Nghiên cứu của luận án hướng đến giải quyết vấn đề này.
Trong [104], mô hình ABAC (attribute-based access control) cho các Web services đã được giới thiệu. Một giả thiết cho mô hình là tất cả các thuộc tính là đơn trị (giá trị nguyên tố). Giả thuyết này chỉ đúng và phù hợp với các hệ thống đơn giản. Còn với các hệ thống phức tạp hơn, như các hệ thống lưới và hệ thống luồng công việc với rất nhiều các thuộc tính phức hợp, giả thuyết này không còn áp dụng được nữa. Chính vì vậy, một trong những mục tiêu trong mô hình của luận án là loại bỏ giả thuyết này, cho phép các thuộc tính nhận cả kiểu phức hợp. Một hạn chế nữa trong mô hình ABAC [104] là cách biểu diễn các quy tắc truy nhập. Trong mô hình, mỗi quy tắc được biểu diễn bằng công thức:
can_access(s, r, e) ← f(Attr(s), Attr(r), Attr(e)) (4.2)
trong đó: s, r, e tương ứng biểu diễn chủ thể, tài nguyên và yếu tố môi trường; Attr(c) là quan hệ gán giá trị cho thuộc tính của thành phần c, với c có thể là s, r hoặc e; f() là hàm logic. Ý nghĩa của quy tắc (4.2) là nếu giá trị của vế phải là TRUE, thì s có thể truy nhập vào r trong điều kiện e.
Với cách biểu diễn này, nếu giá trị của f() là FALSE, vẫn chưa đảm bảo là s không thể truy nhập vào r. Điều này có nghĩa là quyết định cannot-access đòi hỏi phải kiểm tra toàn bộ các quy tắc trong hệ thống. Hơn nữa, quyết định can-access cũng đòi hỏi phải kiểm tra tất cả các quy tắc khác, chứ không chỉ kiểm tra một quy tắc. Do đó, cách biểu diễn quy tắc này, từ góc độ sử dụng, chưa được hiệu quả. Trong mô hình được đề xuất trong luận án, cách biểu diễn các quy tắc cũng đơn giản như mô hình trên, với chỉ một loại quy tắc. Luận án sử dụng loại quy tắc cannot-access(), thay vì loại quy tắc can-access() như mô hình trên. Cách biểu diễn này mặc dù nhìn qua tương tự như cách cũ, nhưng hiệu quả sử dụng tốt hơn nhiều. Với quyết định cannot-access, thì chỉ cần kiểm tra đúng một quy tắc. Còn quyết định
can-access, vẫn phải kiểm tra tất cả các quy tắc như cách tiếp cận trên.
Vấn đề về cách biểu diễn các quy tắc đã được bàn luận trong [83]. Các tác giả phát hiện có hai cách tiếp cận trong việc biểu diễn các quy tắc:
- Chính sách đóng (Closed policy) (hay còn gọi là cấp quyền tích cực (positive authorization)): cách tiếp cận này đặc tả các cho phép truy nhập (permissions for
125
an access). Một yêu cầu truy nhập được cho phép nếu tồn tại quy tắc cấp quyền tích cực cho nó. Còn trái lại thì nó sẽ bị từ chối.
- Chính sách mở (Open policy) (còn được gọi là cấp quyền thụ động (negative authorization)): cách tiếp cận này đặc tả các từ chối truy nhập (denials for an access). Một yêu cầu truy nhập sẽ bị từ chối nếu tồn tại một cấp quyền thụ động cho nó. Còn trái lại thì nó sẽ được cho phép.
Cách tiếp cận kết hợp của hai phương pháp trên cũng được xem xét như một biện pháp thuận tiện để biểu diễn các quy tắc. Tuy nhiên, cách tiếp cận này đưa đến hai vấn đề: thứ nhất là sự không đầy đủ của các quy tắc (incompleteness of rules) và thứ hai là sự không nhất quán giữa các quy tắc (inconsistency among rules). Trong khi vấn đề thứ nhất có thể được giải quyết dễ dàng bằng giải pháp chấp nhận các cấp quyền mặc định (default authorization), vấn đề thứ hai lại phức tạp hơn nhiều (xem thêm trong [83]). Đó là nguyên nhân theo đó giải pháp kết hợp không được lựa chọn trong mô hình được xem xét trong luận án.
Trong [55], các tác giả giới thiệu một mô hình ABAC mở rộng, được gọi là ABMAC (Attribute-Based Multipolicy Access Control). Tuy nhiên, sự phân biệt giữa hai thực thể
Service và Resource chưa được rõ. Trong khi ở phần 3.2, hai thực thể này dường như khác nhau, trong phần 3.3, Service lại trở thành một bộ phận của Resource. Hơn nữa, chưa có thuộc tính nào cho các thực thể này được định nghĩa. Ngoài ra, định nghĩa các chính sách với các khái niệm như combine_f, Policy_i, f_policy dường như cũng chưa được rõ ràng và đủ chi tiết.
Trong [47], một mô hình với tên gọi unified attribute-based access control (UABAC) đã được giới thiệu, nhằm thống nhất ba loại mô hình thông dụng: DAC, MAC and RBAC. Mặc dù mô hình này có hỗ trợ thuộc tính kiểu tập hợp, nhưng lại không hỗ trợ thuộc tính kiểu phức hợp. Với thuộc tính kiểu tập hợp, có thể chứa tập các giá trị, nhưng không chứa được tập các thuộc tính khác như kiểu phức hợp. Hơn nữa, mục đích sử dụng của mô hình này khác với mô hình được đề xuất. Trong khi mô hình này nhằm thống nhất các mô hình trước đó, mô hình trong luận án tập trung vào việc tích hợp các yêu cầu truy nhập của hệ thống workflow với hệ thống lưới. Thông thường không dễ để có được một mô hình "thống nhất" hoặc "đa dụng" thích hợp với mọi tình huống thực tế. Thông thường trong áp dụng, hệ thống thường bị mất đi phần nào tính đơn giản và hiệu quả hoạt động. Ví dụ trong mô hình UABAC, để giải quyết vấn đề biểu diễn các kiểu ràng buộc khác nhau trong các mô hình khác nhau, ba kiểu ràng buộc đã được đề xuất: ConstrSub đặc tả cho các ràng buộc trên thuộc tính của chủ thể; ConstrObj đặc tả cho các ràng buộc trên thuộc tính của đối tượng khi nó được tạo ra; và ConstrObjMod đặc tả cho các ràng buộc trên thuộc tính của đối tượng khi nó bị thay đổi. Cách phân loại này sẽ dẫn đến một vấn đề không đơn giản là làm thế nào biểu diễn được các ràng buộc kết hợp có các kiểu thuộc tính khác nhau, được sử dụng vào các thời điểm khác nhau. Trong khi đó, vấn đề này không tồn tại trong mô hình được đề xuất trong luận án, do chỉ chứa một kiểu quy tắc.
126
Bảng 4-6: So sánh các tính năng của mô hình CABAC và các mô hình khác.
Tính năng hỗ trợ
ERBAC [8] ABAC [104] ABMAC [55]
UABAC [47]
CABAC
Hỗ trợ lưới Không Không Có Không Có
Hỗ trợ luồng công việc
Có Không Không Không Có
Hỗ trợ thuộc tính đơn
Không Có Có Có Có
Hỗ trợ thuộc tính phức
Không Không Không Không Có
Kết quả so sánh giữa mô hình CABAC được đề xuất và các mô hình khác được trình bày trong Bảng 4-6. Nhìn vào bảng có thể thấy, mô hình cuaẩ luận án hỗ trợ cả bốn tính năng an ninh cần thiết cho khung cộng tác.
4.3.2.5 Kết luận về mô hình
Mô hình điều khiển truy nhập được đề xuất trong luận án đã khắc phục các hạn chế của các mô hình trước đó và đáp ứng tốt hơn các yêu cầu an ninh trong môi trường lưới. Đồng thời, giúp giải quyết được vấn đề gọi dịch vụ lưới an toàn từ tiến trình BPEL trong G-ODE, đã đề cập ở phần cài đặt G-ODE.
4.3.3 Giải pháp tự động hóa quá trình khai thác tiến trình BPEL
4.3.3.1 Thiết kế
Mục tiêu thiết kế
Như đã được trình bày ở phần 1.4 của chương 1, để hỗ trợ việc tự động hóa quá trình khai thác tiến trình BPEL trong ODE, luận án đã xây dựng một công cụ phần mềm với các tính năng sau:
- Tự động kiểm tra tính hợp lệ của tệp tiến trình BPEL và các tệp WSDL liên quan. Nếu tất cả các tệp này đều hợp lệ thì tệp deploy.xml cần thiết sẽ được tạo ra. - Tự động thu thập các tệp cần thiết vào trong thư mục khai thác của ODE và khởi
tạo quá trình biên dịch.
- Lọc và trả về chỉ các thông báo liên quan, hữu ích về các lỗi tiềm năng gắn với quá trình chuẩn bị và biên dịch.
- Đề xuất các giải pháp và các lý do có thể gây ra lỗi. - Hỗ trợ việc tích hợp với trình soạn thảo BPEL.
Nhiệm vụ chính công cụ là tiếp nhận ở đầu vào tệp tiến trình BPEL và các tệp WSDL liên quan (dùng để mô tả cho các dịch vụ Web được gọi), sau đó kiểm tra tính hợp lệ của các tệp này, và cuối cùng tạo ra ở đầu ra là tệp deploy.xml (nếu tất cả các tệp đều hợp lệ),
127
hoặc thông báo lỗi (nếu có tồn tại ít nhất một tệp không hợp lệ) (xem Hình 4-9 mô tả khái quát các chức năng này). Các tệp được coi là hợp lệ nếu chúng thỏa mãn các điều kiện sau:
- Tệp tiến trình BPEL chính tồn tại và nội dung của nó là hợp lệ. Để kiểm tra tính hợp lệ của nội dung này, công cụ được xây dựng trong luận án chỉ quan tâm đến phần khai báo và sử dụng các Partner Link. Còn việc kiểm tra và biên dịch nội dung của tệp BPEL là trách nhiệm của BPEL engine.
- Với mỗi activity <receive>, <invoke> hay <reply> sử dụng một Partner Link trong tệp BPEL, đòi hỏi một tệp WSDL tương ứng biểu diễn cho Partner Link đó. Do đó, tệp WSDL này cần phải tồn tại và có chứa Partner Link đó. Hơn nữa, nó phải chứa thông tin hợp lệ về tên của service và port (service name and port name).