Trang 34 3.2 Xây dựng hệ thống SOA 3.2.1 Giới thiệu toán Phần giới thiệu giai đoạn cần tiến hành để triển khai hệ thống SOA đạt hiệu cao Để trình bày vấn đề cách trực quan hơn, ta thực xây dựng giải pháp tổng thể cho toán “Bán hàng qua mạng” Mơ tả tốn: • Khách hàng (customer) truy cập vào website đại lý (retailer) để xem qua mặt hàng đặt hàng sản phẩm điện tử TV, đầu DVD video camera • Đại lý chuyển yêu cầu (order) đến cho phận thủ kho (warehouse) để xử lý • Nếu nguồn hàng kho mức cho phép yêu cầu bổ sung hàng (replenishment order) gửi đến nhà sản xuất (manufacturer) • Nhà sản xuất khơng giải yêu cầu bổ sung hàng, mà sau khoảng thời gian sản xuất đủ lượng hàng Trang 35 3.2.2 Một số khái niệm Phần giới thiệu phương pháp để xác định services theo phương pháp top-down (xuất phát từ yêu cầu nghiệp vụ) bottom-up (xuất phát từ thực trạng hệ thống có) Cụ thể hơn, trình bày số kỹ thuật mô tả bước cần tiến hành để xây dựng hay chuyển đối hệ thống sẵn có theo mơ hình SOA Phương pháp bao gồm bước thể Hình 3-1 Các bước không thiết phải thực cách tuyến tính, mà quy trình điều chỉnh cách định bước cần thực song song, ràng buộc bước tùy vào đặc trưng hệ thống cụ thể cần triển khai Hình 3-1 - Các bước cần thực triển khai hệ thống SOA Chúng ta theo qui trình từ xuống (theo Hình 3-1) Với bước mà song song thực tế tiến hành lúc Một số khái niệm cần quan tâm : Trang 36 • Miền nghiệp vụ (Business domain): Là miền hay môi trường diễn hoạt động tương tác (như trao đổi tài nguyên) tác nhân nghiệp vụ (economic agents), mua bán, sản xuất, dịch vụ • Tiến trình nghiệp vụ: Là hoạt động thực trình quản lý nghiệp vụ cách thủ cơng hay tự động Mọi tiến trình cần liệu đầu vào cho kết kết thúc Tùy thuộc vào độ phức tạp mà tiến trình tác vụ đơn giản thủ tục phức tạp • Tiến trình con: Là tiến trình thực phần tiến trình khác Tiến trình “trừu tượng hóa” để che dấu chi tiết bên “cụ thể hóa” để thể đầy đủ quy trình thực bên • Sơ đồ nghiệp vụ sử dụng: Tập trung vào mô tả qui trình xử lý, cịn vấn đề liên quan đến kỹ thuật, cách cài đặt… mô tả cách tổng quát, trừu tượng, nêu lên dự định (intentions) • Sơ đồ hệ thống: Trong sơ đồ hệ thống mô tả rõ ràng định (decisions) liên quan đến cài đặt, triển khai, kỹ thuật, ví dụ mơ tả sử dụng thuật ngữ system, report, screen ) • Hệ thống con: Một hệ thống chia thành nhiều hệ thống chịu trách nhiệm hay nhóm chức hệ thống Hệ thống xây dựng thành phần độc lập để sử dụng lại • Thành tố: Một hệ thống gồm nhiều thành phần, thành phần đảm nhiệm việc thực thi nhóm chức có liên quan hệ thống Một thành phần chứa nhiều dịch vụ cung cấp dịch vụ bên thành phần giao tiếp Trang 37 • Thành phần nghiệp vụ: Thành phần nghiệp vụ thành phần cài đặt chức hay qui trình nghiệp vụ Thành phần nghiệp vụ xây dựng thành đơn vị độc lập có khả tái sử dụng hệ thống Một vài ví dụ thành phần nghiệp vụ như: quản lý danh mục hàng hóa, quản lý tốn, quản lý đặt hàng tính thuế… • Thành phần kỹ thuật: thành phần kỹ thuật thực thi chức kỹ thuật sở hạ tầng hệ thống (như security component , scheduling component), độc lập với chức nghiệp vụ • Value-chain : Là khái niệm nhằm loại hoạt động nghiệp vụ thực với mục đích nâng cao lợi nhuận doanh nghiệp, bao gồm hoạt động thu thập nguyên vật liệu, sản xuất, phân phối sản phẩm, marketing, chăm sóc khách hàng • Vùng chức năng: Là khái niệm dùng để mô tả phận chịu trách nhiệm cho nhóm chức có liên quan khách hàng, sản xuất, phân phối sản phẩm, lưu trữ kho… • Top-down : xây dựng hệ thống SOA, phương pháp top-down phương pháp mà điểm xuất phát từ yêu cầu nghiệp vụ để xác định yêu cầu chức năng, tiến trình tiến trình con, trường hợp sử dụng (use cases) để tiến tới việc xác định thành phần hệ thống (components), dịch vụ… • Bottom-up : phương pháp dựa việc phân tích tình trạng, tài ngun hệ thống có tái sử dụng lại thành phần việc xây dựng dịch vụ Trang 38 3.2.3 Các bước xây dựng hệ thống SOA 3.2.3.1 Phân rã domain Ở giai đoạn ta sử dụng kỹ thuật top-down để phân rã domain (tồn qui trình nghiệp vụ) thành quy trình nghiệp vụ, tiến trình sơ đồ sử dụng Nếu xem xét khía cạnh nghiệp vụ domain bao gồm nhiều vùng chức Hình 3-2 – Phân rã domain thành dãy vùng chức liên quan Sau phân rã domain thành dãy vùng chức liên quan, ta tiếp tục phân tích vùng chứuc để xác định sơ đồ sử dụng • Mơ hình use case: ► UC1: Purchase Goods (khách hàng chọn mua hàng từ danh sách nhà bán lẻ cung cấp) ► UC2: Source Goods (nhà bán lẻ lấy hàng từ kho để giao cho khách hàng) ► UC3: Replenish Stock (yêu cầu bổ sung hàng lượng hàng kho mức sàn) ► UC4: Supply Finished Goods (xử lý yêu cầu bổ sung hàng) ► UC5: Manufacture Finishes Goods (sản xuất thêm hàng để đáp ứng yêu cầu lượng hàng có khơng đủ cung cấp) ► UC6: Configure and Run Demo (chạy demo ứng dụng) ► UC7: Log Events (theo dõi lưu lại hoạt động thực hệ thống) ► UC8: View Events (xem lại thông tin hoạt động lưu lại trước đó.) Trang 39 Hình 3-3 – Sơ đồ sử dụng hệ thống bán hàng • Các use case xác định “ứng cử viên” cho dịch vụ mà cuối cung cấp Web service thành phần hệ thống Điều giúp đạt mục tiêu “tiến trình nghiệp vụ tương ứng với hệ thống thơng tin” Hình 3-4 – Sơ đồ use case quy trình nghiệp vụ Trang 40 Phân tích use case để xác định use case nghiệp vụ quy trình nghiệp vụ: Với use case nghiệp vụ, ta cần xác định liệu vào Các thông tin liệu thời điểm cịn mức trừu tượng, ta đảm bảo tính đầy đủ thơng tin tinh chế giai đoạn sau thiết kế dịch vụ thành phần Chúng ta giai đoạn phân tích, chuyển sang giai đoạn thiết kế vùng chức ánh xạ thành hay nhiều hệ thống use case nghiệp vụ ánh xạ thành use case hệ thống 3.2.3.2 Xây dựng mơ hình Goal-service Trong giai đoạn phân rã domain ta xác định use case nghiệp vụ, sở để ta xác định dịch vụ Trong giai đoạn này, thiết kế mô hình goal-service để kiểm tra “các ứng cử viên” có thật tốt khơng? Thơng qua việc vấn đối tượng quản lý nghiệp vụ (business owners) ta hiểu mục tiêu công việc họ Ta xuất phát từ mục tiêu (goal) bước phân tích để xác định công việc cần làm để đạt mục tiêu (sub-goal) Q trình phân rã (goal thành sub-goal) thực ta thấy “mục tiêu thực dịch vụ đó” Như dịch vụ gắn liền với sub-goal mà cần thực thi mơ hình goal-service Điều làm cho dịch vụ truy vết tới business goal (mục tiêu chính) Đây đặc điểm quan trọng để đảm bảo tồn dịch vụ nghiệp vụ xác định thời gian sớm Có nhiều cách để thể mơ hình goal-service Ở đây, ta sử dụng cách đơn giản dùng danh sách phân cấp lồng để biểu diễn goal, sub-goal dịch vụ Dưới ví dụ mơ hình goal-service nghiệp vụ bán lẻ Trang 41 Hình 3-5 – Ví dụ mơ hình goal-service • Goal: thể font chữ bình thường • Dịch vụ: thể font chữ in nghiêng • Giá trị gia tăng (đây dịch vụ cần thiết, chưa xác định giai đoạn domain decomposition): thể font chữ in đậm • Giải thích ý nghĩa mơ hình: ► Bắt đầu với mục tiêu (business goal) increasing revenue (tăng doanh thu) Điều đạt ta increasing sales (tăng số lượng bán) Để tăng số lượng bán, ta cung cấp seft-service shopping (hỗ trợ bán hàng tự động), hai use case “Purchase Goods” “Source Goods” (đã xác định bước phân rã domain) xử lý yêu cầu ► Nếu xét kỹ goal seft-service shopping, ta thấy tốt ta có hỗ trợ tính tiện dụng thân thiện cho người dùng (provide user-friendly interaction experience) Để giải vấn đề này, ta cần cung cấp cho người dùng shopping catalog để xem qua sản phẩm, đồng thời hỗ trợ shopping card để thực tốn qua mạng • Trong q trình xây dựng mơ hình goal-service này, ta xác định thêm dịch vụ cần thiết Trang 42 3.2.3.3 Phân tích hệ thống Trong giai đoạn này, ta sâu việc thiết kế xây dựng kiến trúc hệ thống Các use case nghiệp vụ sở để thiết kế use case hệ thống Hệ thống bao gồm thành phần nghiệp vụ (như Customer, Order Product) thành phần kỹ thuật (như messaging, security logging) Trong suốt giai đoạn phân tích hệ thống con, thành phần nghiệp vụ thành phần kỹ thuật xác định sau: • Phân tích luồng xử lý bên hệ thống (thường chuỗi use case) để tìm “ứng cử viên” cho thành phần nghiệp vụ • Phân tích u cầu phi chức để tìm thành phần kỹ thuật • Xác định chức yêu cầu cho thành phần nghiệp vụ, nghĩa là, xác định use case hệ thống mà thành phần phải hỗ trợ Các use case nghiệp vụ xác định giai đoạn phân rã domain thường “ứng cử viên” tốt để đưa vào tầng giao tiếp (interface) thành phần hệ thống con, nhằm cung cấp dịch vụ bên thành phần Các use case nghiệp vụ kết hợp với để hỗ trợ cho quy trình nghiệp vụ Trong toán ta, bốn hệ thống Retailer, Warehouse, Manufacturer Logging Facility Mỗi hệ thống cung cấp tập service nghiệp vụ Hình 3-6 minh họa hệ thống Retailer Sau tạo mơ hình goal-service xong, ta phân tích use case nghiệp vụ “Purchase Goods” thành hai dịch vụ “Get Catalog” “Submit Order” Trang 43 Hình 3-6 – Các use case nghiệp vụ “gắn” hệ thống Mỗi use case nghiệp vụ tương ứng với tập use case hệ thống đóng gói hệ thống Hệ thống sử dụng thành phần nghiệp vụ thành phần kỹ thuật để thực thi use case hệ thống hỗ trợ cho dịch vụ nghiệp vụ cung cấp ngồi (như Submit Order) Mơ hình thể Hình 3-6 nhằm mục đích minh họa Trong thực tế, kỹ thuật mơ hình hóa sử dụng chuẩn UML sử dụng Sau kết thúc giai đoạn phân tích hệ thống con, ta có thành phần xây dựng dịch vụ • Retailer dịch vụ cung cấp chức truy cập vào danh sách hàng hóa đặt hàng • Warehouse dịch vụ hỗ trợ gửi hàng đặt cập nhật tồn kho xuất nhập hàng Mỗi lượng hàng tồn kho thấp mức sàn, gửi “Purchase Order” (PO) đến cho nhà sản xuất để xử lý • Warehouse Callback dịch vụ nhận thơng tin phản hồi từ phía nhà sản xuất kết xử lý PO có thành cơng hay khơng • Manufacturer: dịch vụ nhận PO bắt đầu q trình sản xuất • Loggin: dịch vụ theo dõi thông tin diễn biến hoạt động xảy hỗ trợ cho người dùng cuối xem lại thông tin Tại thời điểm này, dịch vụ kết hợp (orchestration) để tạo nên dịch vụ tổng hợp hỗ trợ quy trình nghiệp vụ Trang 46 Hình 3-9 – Chọn lựa giải pháp thực thi thích hợp Phần xử lý dịch vụ sử dụng lại hệ thống cũ với cách sau: • Bao bọc (wrapping) hệ thống cũ lại dịch vụ xử lý thông điệp theo hàng đợi hay Web service Nhưng giải pháp không thật hiệu phải thể tồn chức hệ thống ngịai Thành phần hóa phần hệ thống cũ để cung cấp chức cần thiết bên ngồi Q trình gọi chuyển đổi (transformation) Cần quan tâm đến vấn đề “giới hạn” (scope) thực trình này, tránh chuyển đổi phần khơng cần thiết 3.3 Triển khai SOA thực tế Hình 3-10 – Sơ đồ tổng quan thương mại điện tử theo yêu cầu Trang 47 Doanh nghiệp muốn tập trung vào hoạt động kinh doanh chính, giảm chi phí sử dụng lại thơng tin có sẵn theo cách mà khơng phải đại tu lại tồn kiến trúc có sẵn họ Ln có áp lực địi hỏi phải cân cầu tính linh hoạt, tiết kiệm chi phí hiệu Phần sau phân tích sơ lược đặc trưng kinh doanh cơng nghệ tảng Hình 2-10 minh họa thành phần “thương mại điện tử theo yêu cầu” (e-business on demand) 3.3.1 Các đặc trưng kinh doanh Ở góc nhìn doanh nghiệp, thương mại điện tử theo yêu cầu cung cấp cách thức cho công ty cân đối lại hoạt động kinh doanh môi trường công nghệ phù hợp với yêu cầu tái sử dụng lại chức nghiệp vụ Các đặc trưng thể tóm gọn ý sau : Tập trung Cho phép doanh nghiệp tập trung vào hoạt động kinh doanh chính, điều khiến họ thành công trội Các chiến lược cộng tác hình thành từ để nhằm huy động vốn từ nguồn Trách nhiệm Là khả ứng phó nhanh với yêu cầu từ phía khách hàng, mối hiểm nguy từ bên ngồi nắm bắt hội thị trường Đa dạng Nhằm đạt tính linh hoạt hoạt động quy trình nghiệp vụ Nhằm thích ứng với điều kiện giá khác nhau, tăng suất hoạt động Vững vàng Tính vững vàng giúp doanh nghiệp đáp ứng lại thay đổi kinh doanh lẫn môi trường cơng nghệ Điều cịn giúp quản lý thay đổi, quản lý rủi ro ước lượng doanh thu Trang 48 3.3.2 Các đặc trưng cơng nghệ Thương mại điện tử theo yêu cầu cần hỗ trợ kiến trúc công nghệ định nghĩa, mô tả chi tiết rõ ràng Các đặc trưng công nghệ mang lại khả linh hoạt, trách nhiệm hiệu mà doanh nghiệp cần có: • Tích hợp • Trừu tượng hóa • Tự động hố • Các chuẩn mở 3.3.2.1 Tích hợp Thành phần cấu trúc theo yêu cầu (on demand infrastructure) tích hợp Năm 2002, Sam Palmisano, Chief Executive Officer IBM định nghĩa on demand sau : “Một hoạt động kinh doanh theo yêu cầu (on demand business) tổ chức có quy trình nghiệp vụ, tích hợp với đối tác chính, nhà cung cấp khách hàng mà đáp ứng nhanh yêu cầu khách hàng, mối hiểm nguy từ bên nắm bắt hội thị trường” Q trình tích hợp diễn nhiều mức độ khác : Con người Quy trình Ứng dụng Hệ thống Dữ liệu Trang 49 3.3.2.2 Trừu tượng hóa Nhiều cơng nghệ đời sống thường ngày khai thác khái niệm trừu tượng hóa điện thoại di động, PDA, kết nối mạng khơng dây, máy in, vân vân… Các khía cạnh trừu tượng hóa cịn gây tác động ảnh hưởng sâu rộng đến quan niệm kiến trúc thiết kế phát triển hướng đối tượng, Web Service XML 3.3.2.3 Tự dộng hố Tính tốn tự động giúp giải nhu cầu tổ chức muốn giới hạn thời gian chi phí xuất phát từ nguyên nhân sau: • Chi phí cao cho ứng dụng nhân cơng chất lượng cao • Thời gian tiêu phí cho tảng cơng nghệ khác hẳn chí bên tổ chức • Ngân sách IT chi cho bảo trì khơng phải cho giải pháp giải vấn đề • Tính phức tạp hệ thống khơng đồng Vậy làm cách tổ chức xác định vấn đề liên quan sử dụng môi trường thực thi theo yêu cầu (on demand Operating Enviroment) ? Lúc lúc cần đến khả tính tốn động (autonomic computing) Khả tính tốn động tóm gọn ý : Tự hồi phục Là khả trì chức hoạt động hệ thống cách dị tìm, ngăn ngừa phục hồi sau bị lỗi mà cần can thiệp tối thiểu không cần can thiệp từ phía người Yêu cầu tỉ lệ với mối ràng buộc ngày nhiều với kiến trúc công nghệ Nhu cầu tự hồi phục tăng yêu cầu khả đáp ứng tổ chức tăng Tự cấu hình Khả thích ứng động với thay đổi môi trường, thêm bớt thành phần từ hệ thống thay đổi mơi trường để thích nghi với yêu cầu công việc khác Trang 50 Tự tối ưu hố Tự động chọn cấu hình đạt hiệu làm việc tối ưu bao gồm việc tối ưu tài nguyên quản lý công việc Điều giúp giảm bớt gánh nặng khan hiêm tài nguyên phục vụ cho yêu cầu thường xuyên Mục tiêu điều chỉnh hệ thống nhằm đáp ứng với thay đổi công việc Các hệ thống phải kiểm tra tự điều chỉnh liên tục để đáp ứng thay đổi phù hợp với môi trường xung quanh Tự bảo vệ Bảo mật yêu cầu cần quan tâm trước tổ chức chuẩn bị chia sẻ liệu bên Khả tự bảo vệ (self-protecting) yêu cầu hệ thống phải cung cấp cách thức an toàn để bảo thơng tin liệu Qua trình tự bảo vệ làm việc theo quy tắc dự đốn, dị tìm, nhận dạng bảo vệ hệ thống khỏi hiểm nguy từ bên lẫn bên 3.3.3 Các chuẩn mở Các chuẩn mở ảnh hưởng đến môi trường thực thi theo yêu cầu tầng khả tự động hố, tích hợp trừu tượng hóa Các chuẩn mở nhân tố quan trọng ảnh hưởng đến tính linh hoạt khả cộng tác hệ thống khơng đồng Tính phổ biến tồn cầu đặc tả chuẩn cho phép hệ thống tách biệt tương tác lẫn Các tảng bên khác hẳn độc lập với chuẩn mở cho phép xây dựng tiến trình khác biệt Các chuẩn mở cung cấp cho môi trường thực thi thương mại điện tử theo yêu cầu (ebusiness on demand Operating Enviroment) chế mở chuẩn để triệu gọi service hệ thống 3.3.4 Kiến trúc hướng dịch vụ Thương mại điện tử theo yêu cầu SOA định nghĩa cách tiếp cận việc định kiến trúc tích hợp dựa khái niệm dịch vụ Các chức nghiệp vụ kiến trúc cung cấp Trang 51 dạng dịch vụ Đây khái niệm tảng hệ thống SOA sử dụng Web Service tập chuẩn linh hoạt có khả cộng tác cho hệ thống phân tán Có bổ sung qua lại tự nhiên SOA Web Service, SOA nhấn mạnh đến thành phần thương mại điện tử theo yêu cầu theo cách sau : Các chuẩn mở • SOA cung cấp cách thức triệu gọi chuẩn đến Web Service cho tổ chức chia sẻ sử dụng qua mạng • Web Service sử dụng chuẩn mở cho phép kết nối đa doanh nghiệp qua mạng internet ► Giao thức thông điệp (SOAP) ► Giao thức truyền tải (HTTP, HTTPS, JMS) ► Xử lý bảo mật tầng truyền tải (HTTPS) lẫn tầng giao thức (WS-Security) • WSDL cho phép Web Service tự mơ tả Tích hợp • Cung cấp interface nhằm bao bọc điểm cuối dịch vụ hướng đến xây dựng kiến trúc độc lập hệ thống • SOA cung cấp tính truy tìm kết nối dịch vụ động (dynamic service discovery and binding), nghĩa tích hợp dịch vụ theo u cầu Virtualization • Một đặc tính quan trọng SOA dịch vụ triệu gọi mà không cần biết chi tiết cài đặt service kể địa chỉ, tảng service Tự động hố Cơng nghệ Grid áp dụng vào SOA để triển khai kiến trúc dịch vụ nhằm cung cấp cách tiếp cận mẻ tăng tính tự động hố Trong môi trường mở phân tán SOA, việc thiết lập mơi trường thật an tồn q trình tương tác dịch vụ thật khó khăn Vấn đề liên quan đến bảo mật an tồn hệ thống trình bày chương Trang 52 Chương SOA VÀ VẤN ĐỀ BẢO MẬT Chương trình bày khó khăn gặp phải việc bảo vệ hệ thống SOA Từ xem xét, phân tích giải pháp “kiến trúc bảo mật hướng dịch vụ” Chương giới thiệu số chuẩn bảo mật XML WS-Security, XML-Signature, XML-Encryption, XML Key Management Specification, SAML thư viện WSE (Web Services Enhancements) hỗ trợ lập trình bảo mật web services 4.1 Các thách thức bảo mật hệ thống SOA 4.1.1 Đặt vấn đề Với việc phát triển không ngừng công nghệ web service tạo nên ảnh hưởng định việc xây dựng mơ hình tính tốn phân tán Các kiến trúc phân tán hướng đối tượng DOA (Distributed Object Architecture) sử dụng công nghệ CORBA, DCOM, DCE, Java RMI nhanh chóng chuyển sang kiến trúc hướng dịch vụ (SOA) với công nghệ SOAP, HTTP XML Việc thay đổi kiến trúc hệ thống dẫn đến thay đổi định việc đưa giải pháp cho vấn đề bảo mật hệ thống Hầu hết giải pháp bảo mật sử dụng ngày dựa thực trạng hệ thống máy khách máy chủ đặt mạng vật lý (ví dụ LAN) hay mạng logic (như VPN) Những giải pháp đảm bảo an toàn cho hệ thống, thắt chặt vấn đề an ninh thông qua việc giám sát, điều khiển tất ngõ vào ngõ mạng Thế nhưng, hệ thống SOA với đặc tính mở nó, thật làm cho giải pháp khơng cịn thích hợp Trang 53 • Nếu trước người dùng muốn sử dụng chức hệ thống họ phải ngồi thiết bị đầu cuối gắn liền với hệ thống mạng để truy cập, điều khơng cịn cần thiết Vì hệ thống SOA, chức “dịch vụ hóa” cung cấp cho đối tượng bên truy cập thơng qua nghi thức chuẩn web service • Các dịch vụ chất không phụ thuộc vào vị trí Địa dịch vụ thay đổi số lý (nâng cấp hệ thống, hệ thống bị cố trình vận hành…) Điều khiến cho việc kiểm soát luồng tương tác hệ thống đối tượng bên ngồi trở nên khó khăn • Nhà cung cấp dịch vụ phía đối tượng sử dụng dịch vụ thuộc mạng vật lý khác tổ chức, hay chí tổ chức khác Thế dẫn đến khác biệt sách an ninh, bảo mật, q trình kiểm sốt gặp nhiều cản trở 4.1.2 Các vấn đề bảo mật liên quan cần quan tâm 4.1.2.1 Những hạn chế tường lửa Các hệ thống tường lửa thông thường không giám sát chặt chẽ gói tin truyền tải dựa giao thức HTTP, nghĩa là, yêu cầu truy cập đến web service thông qua nghi thức HTTP hệ thống tường lửa cho phép qua Sự thiếu sót khiến cho máy chủ có nguy bị công mà biết trước Trong thực tế, có cơng cách thiết kế gói tin SOAP qua mặt hệ thống tường lửa máy chủ để gây nên lỗi “tràn vùng đệm” cho ứng dụng bên Thời gian gần đây, nhiều sản phẩm tường lửa giám sát gói tin chứa liệu dạng XML xây dựng nhằm bảo vệ web service việc kiểm soát yêu cầu dạng SOAP Tuy nhiên, tính hiệu sản phẩm chưa đủ sức thuyết phục để nhà quản trị chấp nhận sử dụng phần kiến trúc an ninh hệ thống Trang 54 4.1.2.2 Cơ chế bảo mật chưa định nghĩa cách đầy đủ Hầu hết chuẩn bảo mật tập trung vào việc đưa định dạng bảo vệ liệu trình trao đổi, mà không quan tâm đến việc xác định nghi thức mà bên cần thực tương tác, việc chứng thực kiểm tra quyền… 4.1.2.3 Các giải pháp bảo mật khó tích hợp với Vì thiếu chuẩn chung việc nghi thức giao tiếp web service khiến cho sản phẩm hỗ trợ cho vấn đề bảo mật web service thị trường ngày hồn tồn tích hợp vào nhau, sản phẩm thiết kế dựa chuẩn bảo mật cho web service 4.1.2.4 Bảo mật qui trình phối hợp hoạt động web service Khi số lượng web ngày gia tăng, nhu cầu tái sử dụng lại dịch vụ này, kết hợp chúng theo qui trình xử lý khác để đạt kết khác giành nhiều quan tâm Và lúc này, rõ ràng ta phải giải vấn đề bảo mật mối quan hệ tương tác web service 4.1.2.5 Bảo mật vấn đề hiệu suất hoạt động Một hệ thống sử dụng chế bảo mật khóa cơng cộng địi hỏi phải thực nhiều phép tính chứng nhận thơng điệp, mã hóa kiểm tra giấy chứng nhận Việc truyền gửi thông điệp chứng nhận chậm nhiều lần so với việc truyền gửi thông điệp thông thường Và chắn rằng, ln ln có ràng buộc mức độ bảo mật hiệu suất hoạt động hệ thống.Vấn đề đặt là, cần phải lên phương án, hoạch định kế hoạch chi tiết, kỹ càng, thận trọng công nghệ tối ưu hiệu nhằm đảm bảo hệ thống SOA an toàn, có hiệu suất hoạt động mức chấp nhận Trang 55 4.2 Giới thiệu kiến trúc bảo mật hướng dịch vụ 4.2.1 Một số yêu cầu đặt kiến trúc • Chứng thực ► Hầu hết nhà cung cấp dịch vụ yêu cầu bên sử dụng dịch vụ phải chứng thực trước yêu cầu sử dụng dịch vụ chấp nhận ► Các đối tượng sử dụng dịch vụ sẻ phải chứng thực nhà cung cấp dịch vụ nhận kết trả ► Hệ thống nên hỗ trợ nhiều chế chứng thực, chế phải đủ linh hoạt để dễ dàng thay đổi theo yêu cầu đặc trưng dịch vụ • Phân quyền ► Ngồi việc phải thỏa mãn yêu cầu chứng thực đối tượng sử dụng dịch vụ cần phải có quyền định Việc kiểm tra quyền thơng qua sách (ví dụ như, đối tượng quyền sử dụng dịch vụ, điều kiện gì…) ► Nên sử dụng nhiều mơ hình phần quyền khác nhau: o Discretionary Access Control (DAC): mơ hình kiểm sốt việc truy cập dựa ID đối tượng muốn truy cập ID tên truy cập, mật khẩu, hay dấu hiệu đặc trưng phần mềm hay phần cứng… o Mandatory Access Control (MAC): mơ hình bảo vệ thơng tin cách gán cho thông tin giá trị “nhạy cảm” so sánh giá trị với giá trị “nhạy cảm” người muốn truy cập Đây sở để thực cấp quyền truy cập thơng tin Mơ hình thích hợp cho hệ thống địi hỏi cao độ an tồn Trang 56 o Role-Based Access Control (RBAC) : với mơ hình này, định cho phép truy cập dựa vai trò cá nhân trách nhiệm tổ chức cá nhân • Độ tin cậy ► Phải có chế để bảo vệ mơi trường truyền liệu bên thông điệp, tài liệu truyền môi trường cho chúng khơng bị truy cập đối tượng khơng có quyền • Tồn vẹn liệu ► Bảo vệ liệu không bị xâm hại suốt q trình truyền • Cơ chế định danh ► Nhằm đảm bảo đối tượng tham gia trình tương tác khơng thể phủ nhận vai trị (người gửi khơng thể phủ nhận gửi, người nhận chối bỏ nhận) ► Yêu cầu đặc biệt quan trọng môi trường thương mại ngày nay, mà gặp gỡ tận mặt nhiều khơng thể thực • Có chế quản lý ► Kiến trúc an ninh hệ thống phải cung cấp chế để quản lý tính trên, bao gồm: quản lý người dùng, quản lý sách bảo mật… • Cơ chế ghi nhận ► Thực tất ghi nhận liên quan đến trình tương tác đối tượng với hệ thống ► Tính góp phần hỗ trợ cho yêu cầu xây dựng chế định danh • Xử lý bảo mật liên miền ► Kiến trúc phải cung cấp mô hình đáng tin cậy nhằm bảo vệ trình tương tác web service miền khác Trang 57 • Khả liên kết cao ► Khả dễ mở rộng, liên kết tích hợp với hệ thống khác đặc trưng bật hệ thống SOA Vì thế, yêu cầu kiến trúc bảo mật tích hợp vào trì tốt đặc trưng SOA ► Khả liên kết cao thể việc cho phép kiến trúc ta tích hợp với giải pháp, sản phẩm an toàn liệu khác mà khơng phải bỏ chi phí q cao lẻ kiến trúc ta xây dựng không để thay hoàn toàn cho sở kiến trúc hạ tầng có ► Tại vị trí giao tiếp giữ vai trị quan trọng việc tích hợp, mở rộng hệ thống như: nhà cung cấp đối tượng sử dụng dịch vụ, nhà cung cấp dịch vụ sở hạ tầng kiến trúc bảo mật bên dưới, kiến trúc bảo mật miền khác phải thiết kế với yêu cầu tính ổn định, đồng hiệu dựa chuẩn mở • Kiểm soát thay đổi yêu cầu bảo mật ► Trong giải pháp bảo mật trước đây, tài nguyên dịch vụ dùng chung sách bảo vệ, an tồn Giải pháp dùng chung làm cho chi phí bỏ không cao, bù lại, hệ thống ta q lỏng lẻo q cứng nhắc, khơng thích hợp với đặc trưng tính đa dạng tài nguyên, liệu, dịch vụ, chức ► Trong hệ thống SOA, dịch vụ tầng khác đòi hỏi mức độ bảo vệ khác nhau, nói cách khác cần có sách bảo mật khác Ví dụ như, dịch vụ yêu cầu chứng thực dựa X.509 certificate, dịch vụ cần chứng thực theo tên/mật Vì thế, sách an toàn ta phải đầy đủ ngữ nghĩa, đủ linh hoạt để đáp ứng thay đổi Trang 58 4.2.2 Khái niệm kiến trúc bảo mật hướng dịch vụ SOSA (serviceoriented security architecture) Kiến trúc hướng dịch vụ (SOA) tập hợp qui tắc cho việc thiết kế dịch vụ có tính dễ mở rộng, khả kết hợp tương tác cao Các ngun tắc khơng áp dụng cho dịch vụ nghiệp vụ để hình thành hệ thống nghiệp vụ SOA (service-oriented business architecture), mà dùng cho dịch vụ bảo mật để tạo nên hệ thống bảo mật SOA (service-oriented security architecture) , cho dịch vụ quản lý để xây dựng hệ thống quản lý SOA (service-oriented management architecture)… Mơ hình SOSA khơng hướng đến việc thay hồn tồn kiến trúc bảo mật có, mà muốn đưa giải pháp để liên kết sở hạ tầng có sẵn Việc thay dịch vụ bảo mật hồn tịan địi hỏi nhiều chi phí Hiện khơng có nhu cầu cho vấn đề Thay vào đó, tái sử dụng lại (chứ thay mới) kỹ thuật, dịch vụ bảo mật có dựa nguyên tắc SOA để tạo nên kiến trúc bảo mật hướng dịch vụ Và điều thật muốn tạo tầng liên kết bên dịch vụ, công nghệ bảo mật Đây mục tiêu chuẩn mở XML web service mà phát triển: “không thay có, mà làm cho chúng liên kết với môi trường đồng nhất.” Yếu tố quan trọng mà ta cần phải quan tâm đến thiết kế tầng liên kết “thiết lập tin cậy” • Theo định nghĩa tổ chức OASIS (Organization for the Advancement of Structured Information Standards) “sự tin cậy” định nghĩa đặc điểm thực thể mà sở cho thực thể khác dựa để thực số hành động và/hay xác nhận đối tượng Để cho đối tượng sử dụng dịch vụ ủy quyền thực thi tiến trình cho phía cung cấp dịch vụ sách tin cậy phải thiết lập để làm sở cho ủy quyền Vì thế, mục tiêu cuối kiến trúc bảo mật hướng dịch vụ (SOSA) Trang 59 xây dựng tin cậy dịch vụ với cách thiết lập thi hành sách bảo mật Các sách xây dựng dựa “mơ hình ủy thác”, định nghĩa mối quan hệ tin tưởng lẫn dịch vụ) Các nghi thức, nguyên tắc, chế vận hành SOSA không nên lệ thuộc vào môi trường thực thi cụ thể nào, thay vào đó, nên dựa chuẩn chung “mơ hình ủy thác” Các nghi thức bao gồm: • Cơ chế định danh đối tượng, đối tượng sử dụng dịch vụ, dịch vụ, tài nguyên, sách, nhà cung cấp dịch vụ Có thể dùng chế định danh URIs (Uniform Resource Identifier) • Định nghĩa dấu hiệu mật sách ► Policy: tập hợp chế xác nhận policy ► Cơ chế xác nhận (Policy Assertion): policy assertion xem quy tắc mà liên quan đến cách thức hoạt động hệ thống (ví dụ như: loại security token cần dùng, thông điệp trao đổi có cần chứng thực, thời gian cịn hiệu lực thơng điệp bao lâu? ) ► Security Token: Security Token dạng binary (X.509, Kerberos ticket) hay XML (SAML, XrML) • Nghi thức tạo, trao đổi token policy: ► Việc phát sinh phân phối sách nên thực lúc với việc tạo gửi thông tin định nghĩa dịch vụ (WSDL, UDDI) ► Việc tạo phân phối security token ► Việc đặt token thông điệp trao đổi ► Việc kiểm tra xem token có phù hợp với yêu cầu Nói cách khác, hệ thống SOSA phải xây dựng được: o Các nghi thức chung dùng việc trao đổi token đối tượng sử dụng dịch vụ o Các nguyên tắc chung cách xử lý token phía cung cấp dịch vụ Trang 60 Nếu thiết lập chế quản lý mối liên kết đối tượng sử dụng dịch vụ nhà cung cấp dịch vụ hệ thống ta vận hành cách linh hoạt hơn, đặc biệt bối cảnh đối tượng phân tán tổ chức, miền, với chinh sách chế xử lý token đặc thù (ví dụ Public Key Infrastructure, Active Directory, Kerberos), cần trao đổi policy token phát sinh miền với 4.2.3 Kiến trúc bảo mật hướng dịch vụ SOSA 4.2.3.1 Các thành phần kiến trúc Hình 4-1 – Kiến trúc bảo mật hướng dịch vụ (SOSA) Đối tượng sử dụng dịch vụ cung cấp dịch vụ (ở phía bên trái Hình 4-1) trao đổi security token thơng qua Standard-based Security Info Exchange Platform Cơ sở hạ tầng bảo mật tầng cung cấp dạng web service (phần hình Hình 4-1 ) Các kiến trúc, công nghệ, giải pháp bảo mật có tái sử dụng lại thơng qua tầng liên kết Integration backplane ... Kiến trúc bảo mật hướng dịch vụ SOSA 4.2 .3. 1 Các thành phần kiến trúc Hình 4-1 – Kiến trúc bảo mật hướng dịch vụ (SOSA) Đối tượng sử dụng dịch vụ cung cấp dịch vụ (ở phía bên trái Hình 4-1 ) trao... service hệ thống 3. 3.4 Kiến trúc hướng dịch vụ Thương mại điện tử theo yêu cầu SOA định nghĩa cách tiếp cận việc định kiến trúc tích hợp dựa khái niệm dịch vụ Các chức nghiệp vụ kiến trúc cung cấp... thiệu kiến trúc bảo mật hướng dịch vụ 4.2.1 Một số yêu cầu đặt kiến trúc • Chứng thực ► Hầu hết nhà cung cấp dịch vụ yêu cầu bên sử dụng dịch vụ phải chứng thực trước yêu cầu sử dụng dịch vụ chấp