114
4.3.1.5 Bàn luận về giải pháp
Có thể thấy, cho đến nay vẫn chưa có giải pháp nào cho phép gọi các dịch vụ lưới sử dụng ODE engine. Luận án chỉ dừng lại so sánh giải pháp được đề xuất với các giải pháp mà sử dụng các BPEL engine khác.
- So sánh với giải pháp trong [95] mở rộng BPEL chuẩn bằng việc bổ sung các hoạt động mới, giải pháp được đưa ra trong luận án đơn giản hơn nhiều, nó thể hiện ở hai điểm. Thứ nhất, với giải pháp trong [95], người dùng không những phải học thêm các hoạt động mới thêm vào, cũng phải xác định xem một dịch vụ là dịch vụ lưới hay dịch vụ Web khi gọi dịch vụ đó. Còn với giải pháp trong luận án, việc gọi dịch vụ lưới hoàn toàn giống như gọi dịch vụ Web thông thường. Thứ hai, giải pháp mở rộng BPEL cũng đòi hỏi nhiều thay đổi, từ modul biên dịch tiến trình BPEL cho đến modul chạy tiến trình đã được dịch. Trái lại, giải pháp trong luận án không làm thay đổi đến các modul này. Nó chỉ bổ sung một số handler độc lập (mỗi cái là một Java class) và thực hiện một số thay đổi cần thiết chỉ trong tệp cấu hình để đăng ký các handler mới.
- Giải pháp được đề xuất trong [71] tương tự như của luận án, nhưng cho ActiveBPEL engine, chứ không phải cho ODE engine. Tương tự như ODE engine, BPEL engine này cũng không hỗ trợ việc gọi các dịch vụ lưới, mà chỉ gọi được các dịch vụ Web. Tuy nhiên, giải pháp này không đề cập đến vấn đề như đã đề cập ở trên đối với ActiveBPEL engine. Nếu chỉ sử dụng các mẹo trong tiến trình BPEL sẽ không giải quyết được vấn đề này của BPEL engine, dường như rất khó gọi thành công các dịch vụ lưới từ trong một tiến trình.
Tóm lại, giải pháp được đưa ra trong luận án là giải pháp hợp lý cho phép ODE BPEL engine gọi các dịch vụ lưới. Giải pháp này không những đơn giản, không đòi hỏi phải chỉnh sửa BPEL engine, mà còn yêu cầu rất ít nỗ lực của những người phát triển tiến trình BPEL.
4.3.1.6 Kết luận về cài đặt G-ODE
Qua khảo sát kỹ lưỡng vấn đề đối với ODE BPEL engine, nguyên nhân không thể gọi các dịch vụ lưới có thông tin trạng thái đã được phát hiện. Từ đó, luận án đã đề xuất một giải pháp đơn giản vàcó tính thực tế. Đồng thời, việc cài đặt thành công giải pháp qua G- ODE đã chứng tỏ sự đúng đắn và khả thi của giải pháp.
Ý nghĩa của giải pháp là cho phép các dịch vụ lưới khác nhau có thể được kết hợp trong Grid/Workflows có cấu trúc sử dụng BPEL và được gọi thông qua cơ sở hạ tầng lưới (Grid infrastructure) nằm bên dưới. Điều đó ngầm chứa khả năng cho phép dãy các công việc phức tạp (complex sequences of tasks) có thể được kết hợp và thực thi tự động trên môi trường Tính toán lưới, thay vì chỉ thực hiện các yêu cầu tính toán lưới đơn giản.
Tuy nhiên, giải pháp còn có hạn chế là nó mới chỉ gọi được các dịch vụ lưới không an toàn (unsecured grid services), chưa gọi được các dịch vụ lưới an toàn (secured grid services). Vấn đề này sẽ được giải quyết bằng giải pháp đưa ra một mô hình điều khiển truy nhập phù hợp, sẽ được trình bày ở phần tiếp theo.
115
4.3.2 Mở rộng mô hình điều khiển truy nhập dựa trên thuộc tính cho các hệ thống luồng công việc cho môi trường lưới cho các hệ thống luồng công việc cho môi trường lưới
Ở phần trên, vấn đề gọi dịch vụ lưới từ ODE engine đã được phân tích kỹ càng, từ đó giải pháp G-ODE của luận án đã được đề xuất và cài đặt thành công. Tuy nhiên, engine này vẫn còn thiếu một cơ chế điều khiển truy nhập phù hợp, rất cần thiết trong môi trường lưới, giải quyết hai vấn đề còn tồn tại với G-ODE:
- Thứ nhất: dịch vụ lưới an toàn vẫn chưa thể gọi được, mới chỉ có các dịch vụ không an toàn (các môi trường lưới thông thường hỗ trợ cả hai cách gọi này). Tuy nhiên, việc gọi các dịch vụ không an toàn chỉ dùng trong môi trường mạng cục bộ và có tính thử nghiệm. Còn trong môi trường lưới thực sự, thường chỉ chấp nhận cách gọi các dịch vụ an toàn. Lý do là để gọi được các dịch vụ lưới an toàn, đòi hỏi phải có cơ chế quản lý các chứng chỉ số hợp lệ (valid digital certificates ) của đối tượng gọi dịch vụ (ở đây là G-ODE engine). Tuy nhiên, đây là điều còn thiếu trong engine trong luận án.
- Thứ hai: G-ODE hiện nay và cả ODE đều chưa có sự hỗ trợ trong việc biểu diễn và quản lý các ràng buộc về luồng công việc (workflow constraints) như: gán vai trò cho người dùng (role assignment - ai có thể có quyền truy nhập và truy nhập vào hoạt động nào trong luồng công việc), phân chia công việc (seperation of duty - có thể hai công việc khác nhau trong cùng một luồng công việc cần phải được thực hiện bởi hai người khác nhau), công việc liên quan (binding of duty) một người đã thực hiện hoạt động này, cũng phải thực hiện nốt công việc kia, chứ không được giao cho người khác, các ràng buộc tĩnh (static constraints - là ràng buộc áp dụng chung cho tất cả các thể hiện của luồng công việc) và các ràng buộc động (dynamic constraints - là loại ràng buộc áp dụng riêng cho từng thể hiện của luồng công việc) [8], v.v Các loại ràng buộc này rất cần thiết trong các ứng dụng luồng công việc trong thực tế.
Để giải quyết các vấn đề trên, luận án đã đề xuất một mô hình điều khiển mới, mở rộng từ mô hình điều khiển dựa trên thuộc tính. Phần này trình bày cấu tạo của mô hình, cách áp dụng để biểu diễn các loại ràng buộc trong lưới và trong luồng công việc.
Điều khiển truy nhập
Điều khiển truy nhập là quá trình kiểm soát mọi truy nhập vào hệ thống và các tài nguyên hệ thống, nhằm đảm bảo rằng chỉ có những truy nhập hợp lệ và đã được cấp đủ quyền, mới được phép thực hiện truy nhập [84]. Do đó, vai trò của một hệ thống điều khiển truy nhập bao gồm:
- Hỗ trợ những người dùng quan trọng (thường là nhà quản trị hoặc có vai trò quản trị) xây dựng các metadata điều khiển truy nhập cần thiết (như các thông tin về người dùng, quy tắc truy nhập, vai trò và quyền của người, tình trạng các tài nguyên, v.v).
- Tiếp nhận các yêu cầu truy nhập từ người dùng hoặc từ các tiến trình ứng dụng muốn truy nhập vào các tài nguyên của hệ thống.
116
- Kiểm tra các yêu cầu để từ đó sẽ đưa ra quyết định: chấp nhận (toàn bộ hay một phần) hoặc từ chối yêu cầu.
- Nếu yêu cầu được chấp nhận, cần phải cấp cho đối tượng có yêu cầu đủ các quyền cần thiết để truy nhập vào tài nguyên được yêu cầu.
- Giám sát quá trình truy nhập của đối tượng truy nhập nhằm phát hiện và xử lý kịp thời các vấn đề có thể phát sinh trong quá trình truy nhập này (như truy nhập không đúng quyền hạn, tài nguyên không đủ đáp ứng theo yêu cầu, v.v).
Để hoàn thành được các vai trò như trên, hệ thống điều khiển truy nhập phải giải quyết thỏa đáng các vấn đề sau:
- Sự bí mật (Secrecy): Tiết lộ các thông tin cần giữ bí mật.
- Sự toàn vẹn (Integrity): Các thay đổi không được phép hoặc không phù hợp.
- Không có từ chối truy nhập (No denials-of-service): Đảm bảo tính sẵn sàng của các tài nguyên cho những người dùng hợp lệ và đủ quyền.
Quá trình phát triển của một hệ thống điều khiển truy nhập dựa trên ba khái niệm: - Chính sách an ninh (Security policy): quy định các quy tắc truy nhập ở mức cao. Ví
dụ như: chỉ có người chủ của một tệp mới có thể thay đổi nó; chỉ có nhân viên làm việc toàn thời gian mới được phép soạn thảo loại tài liệu nào đó, trong khi các nhân viên làm việc bán thời gian chỉ được xem nội dung của tài liệu.
- Mô hình an ninh (Security model): biểu diễn hình thức của chính sách an ninh, nhằm chứng minh được các tính chất mong muốn (an toàn) của hệ thống đang được thiết kế và triển khai.
- Cơ chế an ninh (Security mechanism): là các chức năng ở mức thấp, được cài đặt
để thực thi các chính sách và mô hình an ninh ở trên.
4.3.2.1 Các mô hình điều khiển truy nhập liên quan
Các chính sách điều khiển truy nhập (ĐKTN) có thể rơi vào một trong hai loại [104]: - Điều khiển truy nhập tùy ý (Discretionary Access Control (DAC)): là cách hạn chế
truy nhập đến các tài nguyên dựa trên định danh và nhu cầu cần biết của người dùng, tiến trình ứng dụng hoặc nhóm người dùng có sở hữu tài nguyên đó. Sự điều khiển được gọi là tùy ý (discretion) theo nghĩa là một chủ thể đã có một số quyền truy nhập nào đó thì có thể chuyển quyền đó (một cách trực tiếp hay gián tiếp) cho bất kỳ chủ thể khác.
- Điều khiển truy nhập bắt buộc (Mandatory Access Control (MAC)): là cách hạn chế
truy nhập đến các tài nguyên dựa trên các thuộc tính hay nhãn an ninh cố định, được gán cho người dùng cũng như cho các tài nguyên. Sự điều khiển được gọi là bắt buộc (mandatory) với nghĩa là các quyền truy nhập đã bị quy định cứng bởi hệ thống và nó không thể bị thay đổi bởi người dùng hoặc bởi chương trình của người dùng. Các mô hình an ninh tiêu biểu được dùng để cài đặt cho các chính sách DAC và MAC ở trên sẽ được giới thiệu ngay sau đây.
117
- Mô hình ĐKTN dựa trên định danh (Identity Based Access Control (IBAC)): Trong mô hình này, quyền truy nhập vào tài nguyên liên kết trực tiếp với định dạng của chủ thể (ví dụ như định danh tên người dùng). Việc truy nhập vào một tài nguyên chỉ được cho phép khi tồn tại liên kết đó. Một ví dụ về mô hình IBAC là việc sử dụng Access Control Lists (ACL - Danh sách điều khiển truy nhập). Một ACL chứa một danh sách những người dùng và các quyền truy nhập của họ như đọc, ghi, chạy, v.v. Mặc dù, có ưu điểm là tương đối dễ cài đặt, nhưng mô hình IBAC sử dụng ACL có nhược điểm: khi số lượng định danh trong ACL tăng lên sẽ dẫn đến việc duy trì và xử lý các yêu cầu truy nhập khó khăn và kém hiệu quả hơn. Điều này làm cho khả năng mở rộng (scale up) của cách tiếp cận này rất hạn chế. Hơn nữa, các quyết định truy nhập lại chỉ dựa trên định danh của người dùng, chứ không dựa trên vai trò, vị trí công việc và các đặc tính của họ. Cách tiếp cận này không phù hợp lắm trong các môi trường doanh nghiệp. Mô hình ĐKTN dựa trên vai trò (RBAC) được trình bày sau đây chính là nhằm khắc phục hạn chế của mô hình này.
- Mô hình ĐKTN dựa trên vai trò (Role Based Access Control (RBAC)): Mô hình này quy định quyền truy nhập vào tài nguyên dựa trên chức năng nghiệp vụ hay vai trò được chủ thể đang thực hiện. Quyền truy nhập được gán cho các vai trò thích hợp, thay vì gán trực tiếp cho định danh như trong mô hình IBAC. So với mô hình IBAC, mô hình RBAC thêm một mức gián tiếp giữa các định danh và các tài nguyên cần truy nhập. Do quyền truy nhập không còn được gán trùng lặp cho từng cá nhân người dùng, mô hình RBAC có khả năng mở rộng tốt hơn và các chi phí quản trị giảm đáng kể. Hơn nữa, mô hình RBAC cũng ánh xạ đến chức năng nghiệp vụ và trách nhiệm của người dùng một cách trực quan hơn là mô hình IBAC, nên nó cũng giúp người dùng dễ hiểu và dễ sử dụng hơn.
- Mô hình ĐKTN dựa trên thuộc tính (Attribute Based Access Control (ABAC)): là một mô hình ĐKTN tổng quát hơn mô hình RBAC, mô hình ABAC này có thể định nghĩa các quyền truy nhập dựa trên các đặc tính liên quan đến an ninh, hay còn được gọi là các thuộc tính mà có thể được phân chia thành ba nhóm:
Các thuộc tính của chủ thể (Subject Attributes): một chủ thể là một đối tượng thực hiện một hành động trên một tài nguyên nào đó. Mỗi chủ thể sẽ có các thuộc tính liên quan giúp xác định định danh và các đặc tính của chủ thể, ví như: mã số cá nhân, họ tên, nơi công tác, ví trị công tác, v.v. Do vậy, vai trò của một chủ thể cũng có thể được coi như một thuộc tính của chủ thể đó.
Các thuộc tính của tài nguyên (Resource Attributes): một tài nguyên là một thực thể (ví dụ như một web service, một cấu trúc dữ liệu, một cơ sở dữ liệu,v.v) được sử dụng bởi một chủ thể. Tương tự như một chủ thể, một tài nguyên cũng có các thuộc tính nhằm bổ sung thêm thông tin cần thiết cho quá trình kiểm tra và đưa ra các quyết định về truy nhập.
Các thuộc tính của môi trường (Environment Attributes): giúp mô tả các khía cạnh cần thiết của môi trường hoạt động hay ngữ cảnh mà trong đó các
118
yêu cầu truy nhập xuất hiện. Các khía cạnh này có thể rất đa dạng như: vận hành, kỹ thuật, thời gian, địa điểm, v.v.
- Attribute Based Multipolicy Access Control: Mô hình ABMAC [55] là sự mở rộng của mô hình ABAC, nhằm đề xuất một mô hình điều khiển truy nhập có khả năng mở rộng để có thể dễ dàng hỗ trợ nhiều chính sách an ninh không đồng nhất. Mô hình này định nghĩa một số thực thể điều khiển truy nhập mới như sau:
Requestor: Thực thể sẽ gửi yêu cầu truy nhập đến các dịch vụ lưới và gọi các thao tác (operations) trong các dịch vụ đó. Thực thể này có vai trò tương tự như thực thể Subject trong mô hình ABAC.
Service: Dịch vụ lưới được các Requestor yêu cầu. Nó tương tự như thực thể Resource trong ABAC.
Resource: Thực thể cung cấp tài nguyên cho các hoạt động của các dịch vụ lưới. Một điểm thú vị của thực thể này trong môi trường lưới là nó có lưu tồn trạng thái (statefulness); có nghĩa là mỗi Resource có một tập các dữ liệu trạng thái được biểu diễn bằng một tài liệu XML và có chu kỳ sống xác định.
Action: Thao tác của dịch vụ lưới, có thể được gọi bởi các Requestor. Environment: Các thông tin ngữ cảnh liên quan đến việc gọi dịch vụ lưới. Hiện nay, vẫn còn một hạn chế trong đa số các mô hình điều khiển truy nhập ABAC và dựa trên ABAC. Đó là chỉ coi các thuộc tính của các thực thể như các giá trị đơn (atomic value). Điều này có nghĩa là một thuộc tính không thể chứa các thuộc tính khác. Tuy nhiên, trong thực tế, nhiều khi các thuộc tính của các thực thể lại có tính phức hợp (compound), tức là chúng lại chứa các thuộc tính khác (xem ví dụ 4-1). Hạn chế này không những làm giảm khả năng biểu diễn của mô hình, mà còn gây ra nhiều khó khăn trong việc biểu diễn các quy tắc và chính sách an ninh. Mô hình được đề xuất trong luận án khắc phục hạn chế đó bằng khả năng hỗ trợ thuộc tính phức hợp.
Ví dụ 4-2: Mỗi thực thể người dùng trong môi trường lưới thường có các thuộc tính như: name, certificates, roles. Thuộc tính certificates, nếu theo chuẩn X.509, lại có các thuộc tính như: subject-name, (distinguished name), issuer-name.
4.3.2.2 Mô hình điều khiển truy nhập mở rộng
Phần này sẽ giới thiệu về mô hình mở rộng được đề xuất trong luận án có tên gọi:
“compound attributed based access control model” (CABAC).
Trong phần sau sẽ đưa ra định nghĩa cho các thành phần của mô hình. Sau đó, vấn đề áp dụng mô hình vào việc biểu diễn các quy tắc và chính sách phân quyền (authorization rules and policies).
Định nghĩa mô hình CABAC:
Một mô hình CABAC M là một bộ gồm các thành phần {S, R, E, AS, AR, AE, F, P}, ký hiệu M = {S, R, E, AS, AR, AE, F, P }, với các ý nghĩa như sau:
119
- S, R, E: tương ứng là tập các chủ thể (subjects), tập các tài nguyên (resources) và tập các yếu tố môi trường (environments).
S = {s1, s2,..., sn} R = {r1, r2,..., rp} E = {e1, e2,..., eq}
AS, AR, AE: tương ứng là các tập các thuộc tính của các chủ thể, của các tài nguyên và của các yếu tố môi trường. Mỗi thuộc tính của các thực thể này có