Khóa luận Nghiên cứu bảo mật web services

[1] ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Nguyễn Thị Thanh Thủy NGHIÊN CỨU BẢO MẬT WEB SERVICES KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY Ngành: Công nghệ thông tin HÀ NỘI - 2010 [2] ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Nguyễn Thị Thanh Thủy NGHIÊN CỨU BẢO MẬT WEB SERVICES KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY Ngành: Công nghệ thông tin Cán bộ hướng dẫn: Tiến Sỹ Trương Ninh Thuận [3] Lời cám ơn Trước tiên, em xin gửi lời cảm ơn và biết ơn sâu sắc đến TS. Trương Ninh Thuận – Giảng viên bộ môn CNPM – khoa CNTT – ĐH Công Nghệ - ĐHQGHN, người đã tận tình hướng dẫn, chỉ bảo, giúp đỡ em trong suốt thời gian em nghiên cứu khóa luận. Và cũng là người đưa ra những ý tưởng, kiểm tra sự phù hợp của luận văn. Em cũng xin gửi lời cảm ơn đến toàn thể các thầy cô trường ĐH Công Nghệ - DHQGHN đã giảng dạy, và tạo điều kiện cho em trong quá trình học tập và nghiên cứu tại trường. Những kiến thức mà chúng em nhận được sẽ là hành trang giúp chúng em vững bước trong tương lai. Cuối cùng, em xin cảm ơn gia đình, bạn bè, người thân đã luôn ở bên để động viên và là nguồn cổ vũ lớn lao, là động lực giúp em hoàn thành luận văn này. Mặc dù đã cố gắng hoàn thành luận văn trong phạm vi và khả năng có thể. Tuy nhiên sẽ không tránh khỏi những thiếu sót. Em rất mong nhận được sự cảm thông và tận tình chỉ bảo của quí thầy cô và toàn thể các bạn. Hà Nội, tháng 5 năm 2010 Sinh viên Nguyễn Thị Thanh Thu ỷ Tóm tắt nội dung Ngày nay công nghệ thông tin đang là nền công nghệ mũi nhọn trong chiến lược phát triển kinh tế, xây dựng đất nước của hầu hết các quốc gia. Các sản phẩm công nghệ thông tin đã và đang [4] được ứng dụng rộng rãi trong mọi lĩnh vực của đời sống kinh tế, xã hội và hầu hết đều đem đến những giá trị thiết thực. Đối tượng phục vụ chủ yếu của ngành công nghệ thông tin hiện nay chính là các tổ chức, câc cơ sở doanh nghiệp… Bảo mật luôn luôn là một vấn đề hàng đầu cho tất cả các loại ứng dụng, đặc biệt là các ứng dụng web. Từ những ngày đầu của Internet người ta đã quan tâm đến tính an toàn trong trao đổi thông tin. Tuy không có sự an toàn tuyệt đối nhưng những phát triển trong lĩnh vực này thì rất nhanh và mang lại nhiều thành quả vì đây là vấn đề cấp bách của nhiều doanh nghiệp. Không có một mức an toàn thích hợp, sự khai thác thương mại của Internet thì không hoàn toàn an toàn. Do đó những giải thuật để kiểm chứng, sự mã hóa khóa thông tin, và chữ ký số hóa có thể là những giải pháp cung cấp một mức đủ an toàn. Chính vì thế sự an toàn của web service trên mạng cũng không thể nằm ngoài vấn đề này. Có thể nói ngày nay ngoài việc nghiên cứu làm sao để tạo ra một web services tốt mang lại nhiều lợi ích thì việc nghiên cứu để làm sao mang lại sự an toàn cho web services cũng là một trong những vấn đề quan trọng nhất. Thật khó tin tưởng để sử dụng một business service như- mua chứng khoán hay chuyển tiền trực tuyến mà lại không có một sự an toàn cần thiết. Luận văn tập trung đi sâu vào nghiên cứu, tìm hiểu về công nghệ web services và các vấn đề bảo mật liên quan và sử dụng chúng để giải quyết bài toán “Kết nối ngân hàng với công ty chứng khoán” một cách an toàn, hiệu quả, nhằm tạo điều kiện thuận lợi cho việc giao dịch chứng khoán và giúp cho các thông tin được minh bạch. Danh mục ký hiệu, từ viết tắt Tên viết tắt Mô tả HTTP Hypertext Transfer Protocol [5] HTML HyperText Markup Language SOAP Simple Object Access Protocol UDDI Universal Description, Discovery, and Integration WSDL Web Service Description Language WS Web services WSS Web Service Security XML eXtensible Markup Language SOA Service Oriented Architecture SSL Security Sockets Layer TCP/IP Transmission Control Protocol/ Internet Protocol FTP File Transfer Protocol W3C World Wide Web Consortium Danh mục bảng và hình vẽ Tên Hình Mô tả Trang Hình 2.1 Sơ đồ cộng tác SOA 17 [6] Hình 3.1 Mô hình Web Service 23 Hình 3.2 Kiến trúc của Web Serice 24 Hình 3.3 Web service protocol stack 25 Hình 3.4 Tương tác giữa các thành phần web service 26 Hình 3.5 Các thành phần web service 27 Hình 3.6 Cấu trúc WSDL 28 Hình 3.7 Trao đổi thông điệp SOAP 31 Hình 3.8 Cấu trúc của thông điệp SOAP 33 Hình 3.9 Mô hình tương tác giữa các thành phần 34 Hình 3.10 Sơ đồ sử dụng web service 35 Hình3.11 Cấu trúc của một tài liệu được mô tả bởi XML 35 Hình 3.12 Cấu trúc và hoạt động của một web service đơn giản 40 Hình 4.1 Cấu trúc của giao thức bảo mật SSL 40 Hình 4.5 Các bước SSL Record Protocol 56 Hình 4.3 Xác nhận số một thông điệp 56 Hình 4.4 Mã hóa một thông điệp 61 Hình 4. 5 Điều phối thông điệp SOAP 62 Hình 4.6 Cơ chế dùng bộ lọc của wse 63 Hình 5.1 Biểu đồ hoạt động của hệ thống 63 Bảng 4.1 Các số cổng được gán cho các giao thức ứng dụng chạy trên TLS/SSL 43 [7] Bảng 4.2 Các thành phần thông tin trạng thái Session SSL 44 Bảng 4.3 Các thành phần thông tin trạng thái nối kết SSL 44 Mục lục Lời cám ơn..................................................................................................................................3 Tóm tắt nội dung.........................................................................................................................3 Danh mục ký hiệu, từ viết tắt.......................................................................................................4 Danh mục bảng và hình vẽ ..........................................................................................................5 Mục lục.......................................................................................................................................7 [8] CHƯƠNG 1: Mở đầu................................................................................................................11 1.1. Đặt vấn đề...................................................................................................................11 1.2. Nội dung bài toán........................................................................................................12 1.3. Kết quả đạt được.........................................................................................................13 1.4. Cấu trúc khóa luận ......................................................................................................13 CHƯƠNG 2 :Kiến trúc dịch vụ hướng đối tượng SOA..............................................................14 1. Định nghĩa kiến trúc hướng dịch vụ SOA...........................................................................15 2. Tính chất của một hệ thống sử dụng SOA ..........................................................................17 2.2. Tính sử dụng lại dịch vụ ..............................................................................................17 2.3. Sử dụng dịch vụ bất đồng bộ .......................................................................................17 2.4. Quản lý các chính sách................................................................................................18 2.5. Khả năng cộng tác.......................................................................................................18 2.6. Tự động dò tìm và ràng buộc động..............................................................................18 2.7. Tự phục hồi.................................................................................................................18 3. Lợi ích khi sử dụng SOA....................................................................................................18 4. Kết luận .............................................................................................................................19 CHƯƠNG 3 : Web Service .......................................................................................................20 3.1. Service ...........................................................................................................................20 3.1.1. Định nghĩa...............................................................................................................20 3.1.2. Đặc điểm service .....................................................................................................21 3.2. Web service....................................................................................................................22 [9] 3.2.1. Định nghĩa...............................................................................................................22 3.2.2. Cấu trúc web service ...............................................................................................24 3.2.3. Các đặc điểm của web service .................................................................................25 3.2.4. Các thành phần của web service ..............................................................................26 3.2.4.1. WSDL (Web Services Description Language) ..................................................26 3.2.4.2. UDDI (Universal Description, Discovery and Integration)................................29 3.2.4.3. SOAP (Simple Object Access Protocol) ...........................................................29 3.2.4.4. XML (eXtensible Markup language) ................................................................33 3.2.5. Hoạt động của Web services....................................................................................34 3.3. SOA và dịch vụ web.......................................................................................................35 CHƯƠNG 4 : Các kỹ thuật đảm bảo an ninh dịch vụ web .........................................................37 4.1. Các vấn đề bảo mật cần quan tâm ...................................................................................37 4.1.1. Những hạn chế của tường lửa ..................................................................................37 4.1.2. Cơ chế bảo mật chưa được định nghĩa một các đầy đủ .............................................37 4.1.4. Bảo mật trong qui trình phối hợp hoạt động của các WS..........................................38 4.2. Giao thức bảo mật SSL...................................................................................................38 4.2.1. Cấu trúc giao thức bảo mật SSL...............................................................................38 4.2.2. SSL Record Protocol ...............................................................................................45 4.2.3. SSL Handshake Protocol .........................................................................................47 4.3. Khai thác tính năng bảo mật của bộ thư viện Web Service Enhancement (WSE) ............53 4.3.1. Những tính năng bảo mật web service của wse ........................................................54 [10] 4.3.2. Thư viện WSE...........................................................Error! Bookmark not defined. a. UsernameToken Authentication: ...................................Error! Bookmark not defined. b. Chứng nhận X.509 ........................................................Error! Bookmark not defined. 4.3.3. Hô trợ policy................................................................................................................55 4.3.4. Kiến trúc của wse ......................................................Error! Bookmark not defined. CHƯƠNG 5 : Xây dựng chương trình và đánh giá kết quả .......................................................56 5.1. Mô tả hệ thống cần xây dựng..........................................................................................57 5.2. Triển khai hệ thống.........................................................................................................57 5.2.1. Lựa chọn ngôn ngữ lập trình....................................................................................57 5.2.2. Hoạt động của hệ thống ...........................................................................................58 5.2.2.2. Đăng nhập............................................................................................................58 5.2.2.3. Đăng ký tài khoản mới .........................................................................................59 5.2.3.4. Thực hiện giao dịch .............................................................................................60 5.3. Tích hợp các thẻ bảo mật cho chương trình với công cụ WSE.........................................61 5.3.1. Sử dụng công cụ WSE từ bên trong Visual Studio 2005 Error! Bookmark not defined. 5.3.2. Sử dụng công cụ WSE từ menu start .............................Error! Bookmark not defined. CHƯƠNG 6 : Kết luận..............................................................................................................77 Tài liệu tham khảo.....................................................................................................................80 [11] CHƯƠNG 1 Mở Đầu 1.1. Đặt vấn đề Kinh doanh chứng khoán là một hoạt động diễn ra khá phổ biến hiện nay, trong một bộ phận xã hội không nhỏ, nhưng công việc giao dịch hiện nay vẫn chủ yếu bằng tiền mặt. Người mua chứng khoán vẫn phải trực tiếp đến các công ty chứng khoán giao dịch và công ty chứng khoán [12] vẫn giữ toàn bộ số tiền của nhà đầu tư. Công việc này làm mất nhiều thời gian công sức, không đảm bảo sự an toàn cho nhà đầu tư và không mang tính chuyên nghiệp. Các doanh nghiệp đang hướng tới một hoạt động kinh doanh chứng khoán mà trong đó tất cả các hoạt động của nhà đầu tư, doanh nghiệp, ngân hàng đều được thực hiện thông qua Internet. Và cũng hiện nay cũng đã có một số hệ thống phần mềm kinh doanh chứng khoán. Tuy hoạt động chưa hiệu quả và vẫn còn gặp phải nhiều khó khăn nhưng điều đó cũng nói nên một nền tài chính không tiền mặt. Những người sử dụng có thể tiết kiệm thời gian, công sức mà vẫn đảm bảo lợi ích về lãi suất, khả năng thanh toán… Tuy nhiên hệ thống thông tin của các công ty chứng khoán và ngân hàng còn quá nhiều khác biệt và chưa kết nối được với nhau. Vấn đề này gây ra nhiều khó khăn và có thể dẫn đến bỏ lỡ cơ hội của nhà đầu tư. Mặt khác công ty chứng khoán phải đảm bảo kết nối với nhiều ngân hàng cùng một lúc vì mỗi nhà đầu tư chọn cho mình một ngân hàng khác nhau. Tương tự ngân hàng cũng muốn kết nối với nhiều công ty chứng khoán để mở rộng mạng lưới của mình. Khi đưa mọi hoạt động giao dịch lên mạng internet, một điều lo ngại đối với nhà đầu tư, công ty chứng khoán hay ngân hàng là các thông tin cá nhân của họ có được bảo mật một cách chặt chẽ và có chắc chắn rằng chúng sẽ không bị tấn công bởi cách hacker… Khi nhà đầu tư mở một tài khoản chứng khoán hoặc tài khoản ngân hàng họ sẽ được cung cấp username/password hay mã chứng khoán, mã ngân hàng. Vấn đề bài toán đặt ra là làm thế nào để nhứng thông tin đó được trao đổi giữa 2 bên một cách an toàn mà không bị tấn công. Bài toán đặt ra là đưa ra một giải pháp kết nối giữa nhà đầu tư – công ty chứng khoán – ngân hàng. Các giao dịch được thực hiện trực tiếp trên mạng mà vẫn đảm bảo an toàn cho các bên? 1.2. Nội dung bài toán Để làm giảm độ phức tạp do những khó khăn trên bài toán được giải quyết, tôi chọn một hệ thống đơn giản chỉ cung cấp những thông tin đơn giản như thông tin cổ phiếu, thông tin tài khoản của nhà đầu tư, số dư trong tài khoản ngân hàng… Khi một nhà đầu tư mở tài khoản chứng khoán có thể được cung cấp luôn tài khoản ngân hàng. Dịch vụ của công ty chứng khoán sẽ cung cấp thông tin về tài khoản của nhà đầu tư. Sau khi submit để hoàn thành việc đăng ký, username và password của nhà đầu tư sẽ được gửi đến email đăng ký. Thông tin về tài khoản ngân hàng của nhà đầu tư số dư trong tài khoản cũng được hiển thị. [13] Khi khách hàng muốn thực hiện một giao dịch, trước tiên cần đăng nhập vào hệ thống. Khách hàng sẽ nhập username/password và submit để gửi đến hệ thống của công ty chứng khoán. Sau khi đăng nhập khách hàng có thể thực hiện giao dịch mua/bán bằng tài khoản chứng khoán và tài khoản ngân hàng của mình, các thông điệp giữa khách hàng – công ty chứng khoán và nhà đầu tư được trao đổi qua lại. Nếu không có phương pháp bảo mật an toàn, các thông điệp này có thể dễ dàng bị đánh cắp bởi những phương pháp tấn công và dẫn đến thiệt hại cho các bên giao dịch. Để đáp ứng được các yêu cầu của bài toán đặt ra, đặc biệt là toàn bộ các giao dịch đều được đảm bảo chính xác, an toàn cho các bên tham gia sẽ không thể không sử dụng tới các kiến thức trong lĩnh vực Công nghệ thông tin. Có rất nhiều công cụ bảo mật cho web service như công nghệ bảo mật SSL và các thành phần của nó, giao thức HTTP, các chứng chỉ số… Trong luận văn này, tôi tập trung đi sâu vào nghiên cứu bảo mật web service theo công nghệ SSL, giao thức HTTP và đặc biệt là sử dụng bộ thư viện Web Service Enhencement (WSE) của .NET Framework Microsoft. Web services giao tiếp thông qua các message SOAP. WSE cung cấp những mở rộng của giao thức SOAP và cho phép người dùng tự định nghĩa bảo mật, truyền message đáng tin cậy, chính sách... Các nhà phát triển có thể thêm vào những kỹ thuật này trong quá trình xây dựng (dùng code) hoặc trong quá trình triển khai (policy file). 1.3. Kết quả đạt được - Nghiên cứu về các vấn đề: công nghệ web services, kiến trúc hướng dịch vụ SOA, các kỹ thuật đảm bảo an ninh web services đặc biệt là cấu trúc giao thức SSL, HTTP, bộ thư viện WSE và các đặc điểm của nó. - Phát triển chương trình “giao dịch chứng khoán thông qua tài khoản ngân hàng”. Triển khai hệ thống và tích hợp các kỹ thuật đảm bảo an toàn cho hệ thống. 1.4. Cấu trúc khóa luận Nội dung luận văn bao gồm các chương sau: Chương 1: Giới thiệu Mô tả chung về bài toán, hướng giải quyết và các kết quả đạt được sau một thời gian nghiên cứu. Chương 2: Kiến trúc hướng dịch vụ SOA Giới thiệu về kiến trúc SOA một phương pháp tiếp cận công nghệ thông tin khá phổ biến. Trong chương này tôi đưa ra những kiến thức cơ bản về mô hình kiến trúc hướng dịch vụ. Các định [14] nghĩa, cấu trúc của kiến trúc hướng dịch vụ, những đặc điểm và lợi ích của nó trong việc xây dựng một web service và kết hợp chúng theo chuẩn. Chương 3: Web services Chương này sẽ đi sâu vào tìm hiểu chi tiết về web service, các đặc điểm cũng như đặc tả các thành phần của nó như WSDL, SOAP, XML, UDDI … và phần cuối chương là mối quan hệ giữa kiến trúc hướng dịch vụ SOA và Web service. Chương 4: Các kỹ thuật đảm bảo an ninh Web Service. Trong chương này đưa ra tình trạng an ninh của web service hiện nay. Tiếp theo cũng trình bày về các kỹ thuật đảm bảo an ninh như công nghệ bảo mật SSL và đặc biệt là khai thác tính năng của bộ thư viện Web Service Enhancement (WSE) của .NET Framework. Chương 5: Xây dựng, triển khai hệ thống và đánh giá kết quả Chạy demo chương trình chứng khoán giải quyết vấn đề “kết nối chứng khoán với ngân hàng”. Phần trọng tâm trong chương này là kết hợp các thẻ security của bộ thư viện WSE vào Web Service. Chương 6: Kết luận và hướng phát triển trong tương lai. CHƯƠNG 2 Kiến trúc hướng dịch vụ SOA (Service-Oriented-Architecture) Phần mềm ngày nay đang trở lên phức tạp và dường như vượt khỏi tầm kiểm soát của các mô hình phát triển phần mềm hiện có. Nhiều phần mềm lại được xây dựng với hệ thống quá phức tạp, chi phí phát triển cao mà lại khó bảo trì. Nhiều năm qua, nhiều kiến trúc phần mềm dã được [15] xây dựng và triển khai nhằm giải quyết vấn đề này. Tuy nhiên độ phức tạp vẫn tiếp tục tăng và càng khó khăn hơn khi vấn đề lập trình dư thừa và không thể tái sử dụng. Tích hợp các phần mềm lại với nhau là nhu cầu thiết yếu cho tình trạng phát triển phần mềm hiện nay, và làm thế nào để tạo ra được một phần mềm với chi phí thấp, chất lượng tốt, dễ sử dụng và dễ bảo trì là một vấn đề mà nhiều nhà phát triển đã và đang hướng tới. Các kiến trúc hiện đang được áp dụng vào phát triển phần mềm vẫn còn nhiều khó khăn như không linh hoạt, không bền vững, phức tạp…vì vậy các doanh nghiệp cần có một phương pháp tiếp cận mớ với kiến trúc hướng dịch vụ và những công nghệ mới như SOAP, HTTP, và XML sẽ giải quyết được những khó khăn mà hiện các doanh nghiệp đang vấp phải. Trong chương này tôi sẽ giới thiệu một cách tiếp cận khá toàn diện đó là kiến trúc hướng dịch vụ SOA. Giải pháp này bước đầu đã được ứng dụng trong một số dự án và đều đem lại những kết quả khả quan. Và người ta tin rằng SOA có thể sẽ là “xu thế trong tương lai”. Và sau đây chúng ta sẽ đi vào nghiên cứu chi tiết. 1. Định nghĩa kiến trúc hướng dịch vụ SOA SOA viết tắt của cụm từ Service Oriented Architecture là cấu trúc hướng dịch vụ. Theo định nghĩa của IBM: “SOA is an architectural style for creating an Enterprise IT Architecture that exploits the principle of server orientation to achieve a tiglter relationship between the business and the information systems that support the business…”[1]. Theo đó SOA là phong cách kiến trúc để tạo ra một công trình kiến trúc IT, kiến trúc đó khai thác các nguyên tắc của hướng dịch vụ để đạt được các mối quan hệ chặt chẽ giữa doanh nghiệp và hệ thống thông tin nhằm hỗ trợ cho các doanh nghiệp. Theo một định nghĩa khác: “SOA is an approach to IT that builds business processes from reusable component modules or “services” that are independent of applications and the computing platforms on which they run.”[2]. SOA là phương pháp tiếp cận công nghệ thông tin nhằm xây dựng các tiến trình nghiệp vụ từ những thành phần mô hình có sẵn hoặc các dịch vụ mà đối lập với các ứng dụng và các thành phần nền của máy tính như phần cứng hay môi trường lập trình mà nó chạy. [16] Một hệ thống được xây dựng theo mô hình SOA bao gồm các service thỏa mãn các tính chất của service. Mỗi service trong hệ thống có thể được sửa đổi một cách độc lập với các service khác nhằm mục đích đáp ứng một yêu cầu mới từ thực tế. SOA có 3 đối tượng chính - Service Provider: Cung cấp thông tin về dịch vụ cho một nhu cầu nào đó. Người sử dụng không cần quan tâm đến vị trí thực sự mà service họ cần sử dụng đang hoạt động. Nhà cung cấp dịch vụ ở đây là một dịch vụ chấp nhận và xử lý những yêu cầu từ người sử dụng dịch vụ. Nó có thể là một hệ thống mainframe. Một thành phần hoặc các dạng phần mềm khác xử lý yêu cầu dịch vụ. Nhà cung cấp gửi hợp đồng lên service registry để những người sử dụng dịch vụ có thể truy cập đến nó. - Service Consumer: Người sử dụng service được cung cấp bởi Service Provider. Có thể là một ứng dụng, một dịch vụ hoặc là các module phần mềm khác yêu cầu sử dụng dịch vụ. Đây là thực thể thực thi quá trình dịch vụ thông qua service registry, liên kết với dịch vụ và thực thi các chức năng của dịch vụ. Người sử dụng dịch vụ thực thi chức năng dịch vụ bằng cách gửi một yêu cầu đúng định dạng mô tả trong hợp đồng. - Service Regiestry: Nơi lưu trữ thông tin về các service của các service Provider khác nhau. Service registry chấp nhận và lưu trữ các hợp đồng không gửi đến từ nhà cung cấp dịch vụ và cung cấp hợp đồng tùy theo yêu cầu của người sử dụng. Service Consumer dựa trên những thông tin này để tìm kiếm và lựa chọn Service Provider phù hợp. [17] Hình 2.1: Sơ đồ cộng tác SOA Service Provider sẽ đăng ký thông tin về service mà mình có thể cung cấp (các chức năng có thể cung cấp, khả năng của hệ thống như resource, performance, giá cả dịch vụ…) vào Service Registry. Service Consumer khi có nhu cầu về một service nào đó sẽ tìm kiếm thông tin trên service registry. Ngoài chức năng hỗ trợ tìm kiếm, Service Registry còn có thể xếp hạng các Service Provider dựa trên các tiêu chí về chất lượng dịch vụ, bầu chọn từ các khách hàng đã sử dụng service, … Những thông tin này sẽ hỗ trợ thêm cho quá trình tìm kiếm của Service Consumer. Khi đã xác định được Service Provider mong muốn, Service Consumer thiết lập kênh giao tiếp trực tiếp với Service Provider nhằm sử dụng service hoặc tiến hành thương lượng thêm (về mặt giá cả, resource sử dụng…). 2. Tính chất của một hệ thống sử dụng SOA 2.1. Tính loose coupling1 SOA hỗ trợ tính loose coupling thông qua việc sử dụng hợp đồng và liên kết. Một người dùng truy vẫn đến nơi lưu trữ và cung cấp thông tin dịch vụ để lấy thông tin về loại dịch vụ cần sử dụng. Registry sẽ trả về tất cả những dịch vụ theo tiêu chuẩn tìm kiếm. Theo đó, người sử dụng chỉ việc chọn dịch vụ mà mình cần, và thực thi phương thức trên đó theo mô tả dịch vụ nhận được từ registry. Bên sử dụng dịch vụ không cần phụ thuộc trực tiếp vào cài đặt của dịch vụ mà chỉ dựa trên hợp đồng mà dịch vụ đó hỗ trợ. 2.2. Tính sử dụng lại dịch vụ Vì các dịch vụ được cung cấp lên trên mạng và được đăng ký ở một nơi nhất định nên chúng dễ dàng được tìm thấy và tái sử dụng. Nếu một dịch vụ không có khả năng tái sử dụng, nó cũng không cần đến interface mô tả. Các dịch vụ có thể được tái sử dụng lại bằng cách kết hợp lại với nhau theo nhiều mục đích khác nhau. Tái sử dụng lại các dịch vụ còn giúp loại bỏ những thành phần trùng lặp và tăng độ vững chắc trong cài đặt, nó còn giúp đơn giản hóa việc quản trị. Thực ra tái sử dụng dịch vụ lại dễ dàng hơn tái sử dụng thành tố hay lớp. Những dịch vụ dùng chung bởi tất cả các ứng dụng của một hệ thống SOA gọi là những share infrastructure service. 2.3. Sử dụng dịch vụ bất đồng bộ Trên lý thuyết một hệ thống SOA có thể hỗ trợ gửi và nhận cả thông điệp đồng bộ và bất đồng bộ. [18] 2.4. Quản lý các chính sách Khi sử dụng các dịch vụ chia sẻ trên mạng, tùy theo mỗi ứng dụng sẽ có một luật kết hợp riêng gọi là các policy. Các policy cần được quản lý các áp dụng cho mỗi dịch vụ cả khi thiết kế lẫn khi trong thời gian thực thi. 2.5. Khả năng cộng tác Kiến trúc hướng dịch vụ nhấn mạnh đến khả năng cộng tác, khả năng mà hệ thống có thể giao tiếp với nhau trên nhiều nền tảng và ngôn ngữ khác nhau. Mỗi dịch vụ cung cấp một interface có thể được triệu gọi thông qua một dạng kết nối. Một kết nối được gọi là một interoperable chứa bên trong nó một giao thức và một định dạng dữ liệu mà mỗi client kết nối đến nó đều hiểu. 2.6. Tự động dò tìm và ràng buộc động Với tính chất này khi sử dụng kiến trúc SOA một người sử dụng cần đến một dịch vụ nào đó có thể tìm kiếm dịch vụ dựa trên một số tiêu chuẩn khi cần. Người sử dụng chỉ cần hỏi một registry về dịch vụ nào thỏa mãn yêu cầu tìm kiếm. 2.7. Tự phục hồi Một hệ thống tự phục hồi là hệ thống có khả năng tự phục hồi sau khi bị lỗi mà không cần sự can thiệp của con người. Trong kiến trúc hướng dịch vụ, các dịch vụ luôn có thể hoạt động hay ngừng bất kỳ lúc nào, nhất là đối với những ứng dụng tổng hợp từ nhiều dịch vụ của nhiều tổ chức khác nhau. Độ tin cậy của hệ thống phụ thuộc vào khả năng phục hồi của phần cứng sau khi bị lỗi. 3. Lợi ích khi sử dụng SOA Nói đến SOA là nói đến “tiết kiệm” – cả tiết kiệm chi phí lẫn thu được giá trị nhiều hơn từ các hệ thống có sẵn. Sử dụng mô hình SOA trong việc thiết kế hệ thống mang lại lợi ích về mặt kinh tế cũng như kỹ thuật. - Lợi ích từ việc tái sử dụng. Một trong những lợi ích rõ ràng nhất của SOA là nó giúp các công ty thu được giá trị bằng việc tái sử dụng lại những tài nguyên có sẵn. Thông qua việc tái sử dụng này có thể tiết kiệm chi phí cho phần kiến trúc và tích hợp, không những thế nó còn giảm chi phí mua phần mềm mới. Thời gian viết chương trình lấy dữ liệu từ máy chỉ cũng giảm rất nhiều.Thông thường những nhóm [19] phần mềm được phát triển trên nhiều nền tảng khác nhau, sử dụng nhiều ngôn ngữ lập trình khác nhau và thường có nhiều tính năng lặp lại giữa chúng. Sử dụng hệ thống SOA cho phép các công ty tránh khỏi tình trạng lặp dư thừa, tạo ra những đơn thể dịch vụ chia sẻ giữa các ứng dụng. Trong một hệ thống SOA, chỉ cần thay đổi duy nhất một phiên bản của dịch vụ cần được thay đổi và chỉ cần kiểm thử một lần, sử dụng những kỹ năng tương ứng với những ký năng đã dùng để phát triển dịch vụ -> giảm chi phí bảo trì phần mềm. Ngoài ra còn giúp doanh nghiệp chịu trách nhiệm nhiều hơn với những thay đổi về mặt nghiệp vụ và cho phép doanh nghiệp cập nhật những tính năng của nó nhanh hơn. Ngoài ra sử dụng những thành phần có sẵn trước đó mỗi khi có thể thì mỗi khi có lỗi xảy ra ta có thể giới hạn vào khu vực có những thành phần đang được phát triển. Nhờ đó rủi ro về lỗi phần mềm giảm đi và tăng chất lượng dịch vụ. - Lợi ích kinh tế: Doanh nghiệp có điều kiện tập trung thời gian để tìm kiếm các giải pháp cho các bài toán liên quan đến kinh tế. Thúc đẩy sự phát triển của hệ thống hiện có cũng như cung cấp khả năng mở rộng hệ thống trong tương lai. - Lợi ích kỹ thuật: Hệ thống xây dựng theo mô hình SOA đảm bảo các service trong hệ thống có tính độc lập cao (độ kết dính thấp). Trên phương diện người sử dụng, vị trí các service có tính trong suốt (transparency), việc di dời các service đến một máy tính khác không ảnh hưởng khả năng phục vụ yêu cầu khách hàng. Hoạt động của các service có tính động, hành vi của các service tùy thời điểm, tùy yêu cầu cần xử lý mà có sự khác nhau. Thích ứng với những thay đổi trong tương lai. Ngoài ra kiến trúc hướng dịch vụ còn hỗ trợ đa thiết bị như pager, điện thoại di động và hỗ trợ đa nền tảng. 4. Kết luận [20] Chương này trình cơ sở lý thuyết của mô hình SOA, bao gồm: khái niệm, cấu trúc, các tính năng và lợi ích của nó trong việc xây dựng một web service và kết hợp theo chuẩn. Ứng dụng khi xây dựng kiến trúc bảo mật hướng dịch vụ. Thông qua đây chúng ta cũng biết được kiên trúc hướng dịch vụ thật sự đem lại những lợi ích to lớn. Và cung cấp những kiến thức cơ bản về SOA để phục vụ cho phần sau SOA và Web Service giải quyết vấn đề tích hợp như thế nào. CHƯƠNG 3 Web Service 3.1. Service 3.1.1. Định nghĩa Theo định nghĩa IBM “service is a repeatable task within a business process…”[3]. Service là một ứng dụng với user, một thao tác được thực hiện một hoặc nhiều lần trong một tiến trình nghiệp vụ được thực hiện bởi một người hoặc một nhóm người. Service là một hệ thống có khả năng nhận một hay nhiều yêu cầu xử lý và sau đó đáp ứng lại bằng cách trả về một hay nhiều kết quả. Quá trình nhận yêu cầu và trả kết quả được thực hiện [21] thông qua các interface đã được định nghĩa trước đó. Thông thường, việc giao tiếp này được thực hiện trên các interface đã được chuẩn hóa và sử dụng rộng rãi. Một tiến trình gồm nhiều services và nhiều tiến trình hợp lại thành một service hay cũng có thể nói một service có thể bao gốm nhiều services khác. Ví dụ: Thư điện tử là một service. Có nhiều loại dịch vụ khác nhau, có những dịch vụ chỉ mang tính chất công cộng cho phép người ở xa truy nhập thông tin qua mạng, cũng có loại dịch vụ mang tính chất local và giới hạn người sử dụng. Ví dụ đơn giản về một service chính là hoạt động của một nhà hàng. Khi khách hàng vào nhà hàng và gọi thức ăn, khách hàng đang tiền hành gởi các yêu cầu của khách hàng, nếu món ăn khách hàng yêu cầu nhà hàng không có hoặc đã hết, nhân viên nhà hàng sẽ từ chối hoặc đề nghị khách hàng gọi món khác. Nếu nhà hàng có thể đáp ứng được yêu cầu của khách, món ăn sẽ được chế biến và mang ra cho khách hàng muốn thưởng thức, còn kết quả trả về của service phục vụ nhà hàng chính là từ chối hay là món ăn mà khách hàng không cần [4]. 3.1.2. Đặc điểm service  Có ranh giới rõ ràng: Mỗi service được xây dựng dựa trên các interface chuẩn hòa đã được sử dụng rộng rãi. Chi tiết thực hiện của mỗi service sẽ không được thể hiện ra bên ngoài. Mỗi service chỉ công bố một số các interface của nó cho user có thể dùng để gởi các yêu cầu và nhận kết quả trả về.  Tính tự trị (autonomous): Mỗi service có tính độc lập cao, có thể được xây dựng và đưa vào sử dụng mà không phụ thuộc vào các service khác.  Về mặt trao đổi dữ liệu, các service không truyền các class và type. Thay vào đó, các class và type sẽ được đặc tả hình thức  Sự tương thích giữa các service được căn cứ vào các policy. Tương thích về mặt cấu trúc dựa trên các đặc tả hình thức bao gồm contract dựa trên WSDL hoặc Businesss Process Execution Language for Web Services. [22] 3.2. Web service 3.2.1. Định nghĩa Là một hệ thống phần mềm được thiết kế nhằm hỗ trợ khả năng tương tác giữa các máy tính hoặc với các thiết bị khác thông qua mạng. Một WS được xác định bằng địa chỉ URL(Uniform Resource Locator) thực hiện các chức năng và đưa ra thông tin người dùng yêu cầu. Nó có thể cung cấp các chức năng khác nhau từ cơ bản nhất đến những nghiệp vụ phức tạp hay những qui trình khoa học... Hình 3.1: Mô hình Web Service WS sử dụng nền tảng là ngôn ngữ XML(extensible makup language) cho việc trao đổi dữ liệu. Các hệ thống tương tác với WS theo một phương pháp qui định bằng cách sử dụng các thông điệp SOAP(Simple Object Acess Protocol) sử dụng giao thức HTTP. Và mô hình đặc thù của WS là mô hình client-server. WS được đặc tả sử dụng các chuẩn WSDL, UDDI, SOAP, W3C... [23] Giao diện của nó được mô tả trong một khuân mẫu khả năng xử lý máy (tiêu biểu là WSDL). Giao diện này được gọi là giao diện “dịch vụ”. Nó giúp WS có thể được gọi bởi bất kì một ứng dụng nào hay bởi 1 WS nào khác. Hình 3.2: Kiến trúc của Web Serice [24] 3.2.2. Cấu trúc web service Hình 3.3: Web service protocol stack Hình 3.3 mô tả các layer hình thành nên Web Service. Trong đó: Service Provider: Dùng WSDL để mô tả dịch vụ mà mình có thể cung cấp cho Service Broker (tương tự Service Registry trong SOA) Service Broker: Lưu trữ thông tin về các service được cung cấp bởi các Service Provider. Cung cấp chức năng tìm kiếm hỗ trợ Service Requester (Service Consumer trong SOA) trong việc xác định Service Provider phù hợp. Thành phần chính của Service Broker là UDDI. Service Requester: Dùng WSDL để đặc tả nhu cầu sử dụng(loại service, thời gian sử dụng, resource cần thiết, mức giá…) và gởi cho Service Broker. Bằng việc sử dụng UDDI và chức năng tìm kiếm của Service Broker, Service Requester có thể tìm thấy Service Provider thích hợp. Ngay sau đó, giữa Service Requester và Service Provider thiết lập kênh giao tiếp sử dụng SOAP để thương lượng giá cả và các yếu tố khác trong việc sử dụng service. [25] Hình 3.4: Tương tác giữa các thành phần web service 3.2.3. Các đặc điểm của web service  Web services được truy xuất thông qua Web bằng cách dùng địa chỉ URL  Web services liên lạc với thế giới bên ngoài dùng thông điệp XML được gửi trực tiếp qua Web protocols. Giao tiếp với người dung bằng những phương thức mở.  Web services được đăng kí tại nơi chung và được đặc tả tất cả các chức năng  Có độ an toàn riêng tư  Web Service cho phép client tương tác với server ngay cả trong những môi trường khác nhau. Và nó cũng đóng vai trò như là một thiết bị có thể “giao tiếp” với các Web service khác mà không cần quan tâm đến các yêu cầu bên trong. Ví dụ, đặt web server trên một máy chủ chạy hệ điều hành Linux trong khi người sử dụng để máy tính chạy hệ điều hành windows, ứng dụng vẫn có thể chạy và xử lý bình thường mà không cần thêm yêu cầu đặc biệt để tương thích giữa hai hệ điều hành.  Phần lớn các web services được xây dựng dựa trên mã nguồn mở và được phát triển từ các chuẩn được công nhận, ví dụ như XML. [26]  Một WS bao gồm nhiều module và có thể công bố trên mạng Internet 3.2.4. Các thành phần của web service Web service là một tập các chuẩn đặc tả mở rộng khả năng của các chuẩn có sẵn như XML, URL, HTTP, nhằm cung cấp chuẩn truyền thông giữa các hệ thống với nhau. Web services là những thành phần thực thi một số xử lý nghiệp vụ thông qua những dịch vụ và cung cấp những dịch vụ qua mạng, những dịch vụ này có thể được triệu gọi bởi các dịch vụ client bằng cách sử dụng giao thức SOAP trên HTTP. Web service độc lập về ngôn ngữ và độc lập về nền tảng bởi vì nó tách biệt đặc tả ra khỏi cài đặt; nó còn hỗ trợ tích hợp loose coupling giữa các ứng dụng với nhau qua trao đổi các thông điệp đồng bộ và bất đồng bộ thông. Web services dựa trên kiến trúc phân tán trong đó không có bất kì dịch vụ xử lý trung tâm nào và tất cả dạng truyền thông đều sử dụng các giao thức chuẩn. Các giao thức không được có bất kỳ ý nghĩa ngầm định nào bên trong mà phải được mô tả rõ ràng. Hình 3.5: Các thành phần web service 3.2.4.1. WSDL (Web Services Description Language) Ngôn ngữ đặc tả dịch Web Service, . Ngôn ngữ này cơ bản dựa trên XML, khi tương tác các dịch vụ với nhau ta tương tác file WSDL của chúng. Một client có thể đọc WSDL để xác định những chức năng có sẵn trên server, sau đó client có thể sử dụng SOAP để lấy ra những chức năng chính xác có trong WSDL. Cấu trúc chính của một tài liệu WSDL như sau: [27] Hình 3.6: Cấu trúc WSDL - Service: Chứa các method có thể được sử dụng thông qua các web protocol. - Ports: Địa chỉ dùng để kết nối đến WS. Thông thường, ports được mô tả bằng một HTTP URL. - : xác định kiểu dữ liệu mà được sử dụng đặc tả WS * - : mô tả thông điệp truyền đi giữa client và server. Mỗi một thông điệp có một tên duy nhất và tương ứng với một operation và chứa các thông tin cần thiết để thực thi operation đó. Mỗi message có thể bao gồm một hoặc nhiều phần. Mỗi phần có thể được so sánh với thông số của một chức năng gọi trong ngôn ngữ lập trình truyền thống. Các thực thi và những message được mô hình riêng rẽ để hỗ trợ tính linh hoạt và đơn giản hóa việc tái sử dụng lại. Chẳng hạn, hai thao tác với cùng tham số có thể chia sẻ một định nghĩa message. * * [28] - : Định nghĩa một web service, các tác vụ mà service cung cấp và định dạng các thông điệp được sử dụng để khởi động các tác vụ này. * - Operations: Mỗi operation có thể được xem như một method hay một lời gọi hàm trong các ngôn ngữ lập trình cổ điển. - Binding: Chỉ định port type, các operation và chứa các thông tin cần thiết để thực thi operation đó. Mỗi message có một tên duy nhất và một hay nhiều thành phần được phân biệt với nhau qua tên và có thể lưu trữ các tham số cần cho operation. - Element: Được định nghĩa trong Types. Mỗi element có một tên duy nhất và kiểu dữ liệu. Element được dùng để đặc tả dữ liệu dùng trong message. Element có thể đặc tả các dữ liệu đơn giản như string, integer hay phức tạp hơn như array, truct… - XSD file: Các element thường được định nghĩa trong các XML Schema Definition. XSD file có thể ở trong cùng file WSDL hoặc ở file riêng biệt. Mô tả cách nhận và gửi thông điệp, là một phần tử quan trọng trong WSDL. Phần tử có thể được so sánh như chức năng thư viện(hay một module, class) trong các ngôn ngữ lập trình. WSDL định nghĩa 4 kiểu thao tác mà một cổng có thể hỗ trợ: - One-way: cổng nhận một message, message đó là message nhập - Request – response: cổng nhận một message và gửi một message phản hồi - Solicit-response: Cổng gửi một message và gửi về một message - Notification: Cổng gửi một message, message đó là message xuất. Mỗi kiểu thao tác có cú pháp biến đổi tùy theo thứ tự của các message nhập, xuất và lỗi. [29] 3.2.4.2. UDDI (Universal Description, Discovery and Integration) Làm thế nào để một client sử dụng được một web service? Để có thể sử dụng được các dịch vụ, trước tiên client phải tìm dịch vụ, ghi nhận thông tin về cách sử dụng và biết được đối tượng nào cung cấp dịch vụ. UDDI định nghĩa một số thành phần cho biết các thông tin này, cho phép các client truy tìm và nhận những thông tin được yêu cầu khi sử dụng Web Service. Nhiệm vụ chính của nó chính là tìm đúng dịch vụ đang cần và định nghĩa các kích hoạt dịch vụ. Các client sẽ tìm kiếm, ghi nhận thông tin thông qua việc truy cập đến UDDI. UDDI giao tiếp thông qua SOAP và được xây dựng trên nền Microsoft.NET UDDI sử dụng W3C (World Wide Web Consortium) và IETF (Internet Engineering Task Force) sử dụng các chuẩn Internet như XML, HTTP, và phương thức DNS. UDDI sử dụng WSDL để mô tả giao diện đến web services. Trước UDDI chưa có chuẩn Internet nào cho các nhà doanh nghiệp tiếp cận khách hàng của họ với các thông tin về sản phẩm và dịch vụ của họ và cũng chưa có phương thức nào tích hợp các hệ thống khác nhau vào. UDDI giải quyết một số vấn đề như: Tìm kiếm ra hàng triệu người hiện đang online (có thể giúp một doanh nghiệp phát triển tốt), xác định hướng phát triển khi một tính năng thương mại được phát hiện, tiếp cận khách hàng mới và tăng lượng khách hàng hiện tại. Mở rộng thị trường. 3.2.4.3. SOAP (Simple Object Access Protocol) Là giao thức triệu gọi các đối tượng dựa trên nền giao thức HTTP và ngôn ngữ XML. Các đối tượng được cài đặt và chạy trên một web service nào đó trên Internet. Chúng ta lập trình và gọi phương thức, thuộc tính của nó trên chương trình và máy tính của chúng ta. Có khả năng tích hợp các chương trình trên Internet. SOAP định nghĩa cơ chế giao tiếp giữa các đối tượng thông qua 2 bước: SOAP request và SOAP response. SOAP = XML + Một giao thức có thể hoạt động trên Internet (HTTP, FTP, SMTP) trong đó HTTP phổ biến hơn cả. [30] Hình 3.7: Trao đổi thông điệp SOAP Thông điệp theo định dạng XML bình thường gồm các phần như hình sau: Hình 3.8: Cấu trúc của thông điệp SOAP - SOAP envelope: Phần tử gốc bao trùm nội dung thông điệp, khai báo văn bản XML như một thông điệp SOAP. <soap:Envelope xmlns:soap="" soap:encodingStyle=""> ... Message information goes here ... SOAP envelope – Phần tử gốc header Body fault [31] - Xmlns: soap namespace. Thường có giá trị “url/soap-envelope”. Không gian tên xác định Envelope như là một SOAP Envelope. Nếu một không gian tên khác nhau được sử dụng, ứng dụng sẽ phát sinh ra lỗi và loại bỏ thông điệp. Encoding Style là thuộc tính được sử dụng để xác định kiểu dữ liệu được sử dụng trong văn bản. Thuộc tính này có thể được xuất hiện trong bất kì phần nào của thông điệp. Cú pháp chuẩn : soap:encodingStyle=”URL”. - Header: Phần tử đầu trang, chứa các tiêu đề cho trang. Nó có thể được khai báo hoặc không được khai báo và có thể mang những chữ kí số, thông tin mã hóa hay cài đặt cho giao dịch khác. Nếu khai báo phần Header trong thông điệp, nó phải là phần tử con đầu tiên của phần tử Envelope. <soap:Envelope xmlns:soap="" soap:encodingStyle=""> <m:Trans xmlns:m="" soap:mustUnderstand="1">234 ... ... Thuộc tính mustUnderstand có thể được sử đụng để đưa ra để đưa ra nơi mà toàn bộ phần header là . Nếu mustUnderstand=”1”. Nó sẽ chỉ ra rằng những người nhận xử lý Header phải nhận các phần tử. Nếu người nhận thông điệp không nhận phần tử nó sẽ lỗi khi xử lý phần Header. - Body: Chứa các thông tin yêu cầu và thông tin phản hồi. [32] - Fault: Đưa ra thông tin về các lỗi xảy ra trong quá trình truyền thông điệp. Nếu có một lỗi xảy ra, nó phải nằm trong phần Body. Một lỗi có thể chỉ xuất hiện một lần trong thông điệp SOAP. Một SOAP đơn giản trong body sẽ lưu thông tin về các thông điệp, tham chiếu tới một thể hiện của dịch vụ, một hoặc nhiều tham số. Có 3 kiểu thông báo sẽ được đư ra khi truyền tin: request message (tham số gọi thực thi một thông điệp), response message (tham số trả về, được sử dụng khi yêu cầu được đáp ứng) và cuối cùng là fault message (thông báo tình trạng lỗi). Một số đặc điểm của SOAP: - Khả năng mở rộng (extensible): Cung cấp khả năng mở rộng phục vụ cho nhu cầu đặc thù của ứng dụng và nhà cung cấp. Các chức năng về bảo mậ, tăng độ tin cậy có thể đưa vào phần mở rộng của SOAP. Các nhà cung cấp dịch vụ khác nhau, tùy vào đặc điểm hệ thống của mình có thể định nghĩa them các chức năng mở rộng nhằm tăng thêm lợi thế cạnh tranh cũng như cung cấp thêm tiện ích cho người sử dụng. - Có thể hoạt động dựa trên các network protocol đã được chuẩn hóa (HTTP, SMTP, FTP, TCP,…) - Độc lập với platform, ngôn ngữ lập trình hay programming model được sử dụng. Hình 3.9: Mô hình tương tác giữa các thành phần Tóm lại SOAP, WSDL, UDDI có thể kết hợp với nhau theo sơ đồ sử dụng sau: [33] Hình 3.10: Sơ đồ sử dụng web service o Nhà cung cấp Web Service mô tả Web Service trong một tài liệu WSDL và đăng ký nó lên một UDDI bằng cách Publisher’s API o Một người sử dụng UDDI Inquiry API để tìm thông tin về nhà cung cấp dịch vụ thích hợp. Nếu có, nó sẽ tìm kiếm tiếp tModel rồi từ đó lấy ra tài liệu mô tả WSDL. o Một yêu cầu dạng SOAP được tạo ra dựa trên tài liệu mô tả WSDL o Yêu cầu SOAP trên sẽ được gửi đến nhà cung cấp dịch vụ và được xử lý. 3.2.4.4. XML (eXtensible Markup language) XML là viết tắt của cụm từ eXtensible Markup Language – là một chuẩn mở do W3C đưa ra cho cách thức mô tả dữ liệu, nó được sử dụng để định nghĩa các thành phần dữ liệu trên trang web và cho những tài liệu doanh nghiệp với doanh nghiệp. Về hình thức XML hoàn toàn có cấu trúc thẻ giống như ngôn ngữ HTML nhưng HTML định nghĩa thành phần được hiển thị như thế nào còn XML lại định nghĩa thành phần trong dữ liệu gồm những gì. Với XML, các thẻ có thể được lập trình viên tự tạo ra trên mỗi trang web và được chọn là định dạng thông điệp chuẩn bởi tính phổ biến và hiệu quả của mã nguồn mở. Do dịch vụ Web là sự kết hợp của nhiều thành phần khác nhau nên nó sử dụng các tính năng và đặc trưng của các thành phần đó để giao tiếp. XML là công cụ chính để giải quyết vấn đề này và là kiến trúc nền tảng cho việc xây dựng một dịch vụ Web, tất cả dữ liệu sẽ được chuyển sang [34] định dạng thẻ XML. Khi đó, các thông tin mã hóa sẽ hoàn toàn phù hợp với các thông tin theo chuẩn của SOAP hoặc XML – RPC và có thể tương tác với nhau trong một thể thống nhất. Một số đặc điểm của XML - XML được thiết kế để chứa dữ liệu không phải để hiển thị dữ liệu - Các thẻ XML không được định nghĩa trước mà do người lập trình tự định nghĩa. - Mỗi thẻ trong file XML không chỉ chữa dữ liệu mà còn cho biết dữ liệu đó là gì. Điều này rất có lợi cho công việc tìm kiếm Ví dụ về cấu trúc của một tài liệu được mô tả bởi XML. Hình3.11 : cấu trúc của một tài liệu được mô tả bởi XML 3.2.5. Hoạt động của Web services Hình 3.12: Cấu trúc và hoạt động của một web service đơn giản [35] - Web service developer (provider): Người xây dựng và triển khai Web Service. Có thể là một người hay một tổ chức mà cung cấp một phương thức phù hợp để thực thi một dịch vụ cụ thể. Đăng ký và phân loại web service - Web service consumer: Người yêu cầu Provider thực hiện các dịch vụ. Truy vấn và tìm kiếm Web Services. Xác định và tìm ra web service thích hợp nhất - Web service developer: Xây dựng ứng dụng tiêu thụ Web Service [5]. 3.3. SOA và dịch vụ web Trong chương trước chung ta đã nghiên cứu về cấu trúc SOA, những lợi ích của một hệ thống SOA đã quá rõ ràng nhưng việc triển khai một hệ thống SOA và tích hợp chúng với Web Service là điều không hề dễ. Trước đây, khi người dùng muốn sử dụng các chức năng của hệ thống thì họ phải ngồi tại các thiết bị đầu cuối gắn liền với hệ thống mạng để truy cập. Ngày nay điều này không còn cần thiết nữa vì trong một hệ thống SOA, các chức năng này đã được “dịch vụ hóa” và cung cấp ra cho các đối tượng bên ngoài truy cập thông qua các nghi thức chuẩn của web service. Đặc điểm chính của SOA là tách rời phần giao tiếp với phần thực hiện dịch vụ. Điều này có thể làm bạn liên tưởng đến một công nghệ được đề cập nhiều gần đây: Dịch vụ web. Dịch vụ web cho phép truy cập thông qua định nghĩa giao thức-và-giao tiếp. SOA và dịch vụ web thoạt trông có vẻ giống nhau nhưng chúng không phải là một. Về cơ bản, SOA là kiến trúc phần mềm phát xuất từ định nghĩa giao tiếp và xây dựng toàn bộ mô hình ứng dụng như là mô hình các giao tiếp, hiện thực giao tiếp và phương thức gọi giao tiếp. Giao tiếp là trung tâm của toàn bộ triết lý kiến trúc này; thực ra, tên gọi ‘kiến trúc định hướng giao tiếp’ thích hợp hơn cho SOA. Dịch vụ và module phần mềm nghiệp vụ được truy cập thông qua giao tiếp, thường theo cách thức yêu cầu - đáp trả. Ngay cả với yêu cầu dịch vụ 1 chiều thì nó vẫn là yêu cầu trực tiếp có chủ đích từ một phần mềm này đến một phần mềm khác. Một tương tác định hướng dịch vụ luôn bao hàm một cặp đối tác: nguồn cung cấp dịch vụ và khách hàng sử dụng dịch vụ. [36] Định nghĩa cơ bản của dịch vụ web dựa trên một nền tảng khác: Tập hợp các công nghệ WSDL (Web Services Description Language), SOAP (Simple Object Access Protocol) và UDDI (Universal Description, Discovery ang Integration) [21], cho phép xây dựng các giải pháp lập trình cho vấn đề tích hợp ứng dụng và truyền thông điệp. Theo thời gian, các công nghệ này có thể hoàn thiện hay có thể được thay bằng công nghệ khác tốt hơn, hiệu quả hơn hay ổn định hơn. Rõ ràng, theo định nghĩa thì dịch vụ web là đặc tả công nghệ còn SOA là triết lý thiết kế phần mềm. Dịch vụ web đưa ra giải pháp kỹ thuật để thực hiện SOA, nhưng SOA cũng có thể thực hiện với các giải pháp kỹ thuật khác không phải dịch vụ web (và không phải tất cả dịch vụ web đều có kiến trúc SOA). Tuy vậy, SOA và dịch vụ web có mối quan hệ tương hỗ: sự phổ biến của dịch vụ web giúp thúc đẩy sự phát triển của SOA, và kiến trúc tốt của SOA sẽ giúp dịch vụ web thành công. SOA là một phương pháp thiết kế, trong khi dịch vụ Web chỉ là một công nghệ. SOA có thể được thực hiện qua công nghệ dịch vụ Web nhưng cũng có thể thực hiện thông qua các công nghệ khác. Kiến trúc SOA sử dụng dịch vụ Web như là một giải pháp chính để giải quyết vấn đề tích hợp nghiệp vụ giữa các hệ thống (bên cạnh giải pháp dùng công nghệ thông báo). Và đặc biêt trong quá trình internet hóa mọi dịch vụ hiên nay, thì triển khai dịch vụ bằng dịch vụ Web là điều “tất nhiên”. 3.4. Kết luận Công nghệ Web Service đã và đang được triển khai, ứng dụng trong rất nhiều lĩnh vực khác nhau bao gồm cả những lĩnh vực nhạy cảm, đòi hỏi tính an toàn cao như tài chính, ngân hàng, quân sự…và nó đã mang lại nhiều thành quả to lớn cho các tổ chức, doanh nghiệp, tập thể. Trong chương này, tôi đã đưa ra những kiến thức cơ bản về Web Service, các thành phần cấu thành nên một web service. Các đặc điểm của web service và mối quan hệ giữa kiến trúc hướng dịch vụ vào xây dựng web service. [37] CHƯƠNG 4 Các kỹ thuật đảm bảo an ninh Web Service Cùng với sự phát triển không ngừng của Web Service tạo nên những ảnh hưởng nhất định trong việc xây dựng các mô hình phân tán. Các công nghệ kiến trúc hướng đối tượng như DOA hay Java RMIT đang dần chuyển sang các kiến trúc hướng dịch vụ SOA với những công nghệ như SOAP, HTTP và XML. 4.1. Các vấn đề bảo mật cần quan tâm 4.1.1. Những hạn chế của tường lửa Các hệ thống tưởng lửa đều không giám sát chặt chẽ các gói tin được truyền tải dựa trên giao thức HTTP, nghĩa là, các yêu cầu truy cập đến Web Service thông qua nghi thức HTTP đều được các hệ thống tường lửa cho phép qua. Sự thiếu sót này có thể khiến cho máy chủ có nguy cơ bị những cuộc tấn công mà không thể biết trước. Trong thực tế, đã có những cuộc tấn công bằng cách thiết kế các gói tin SOAP qua mặt được hệ thống tường lửa và máy chủ để gây nên lỗi “Tràn vùng đệm” cho các ứng dụng bên trong. Thời gian gần đây, rất nhiều những sản phẩm tường lửa giám sát những gói tin chứa những dữ liệu dạn XML được xây dựng nhằm bảo vệ các web service trong việc kiểm soát các yêu cầu dạng SOAP. Tuy nhiên, tính hiệu quả của những sản phẩm này chưa đủ sức thuyết phục để các nhà quản trị chấp nhận sử dụng nó như một phần của thiết kế an ninh hệ thống. 4.1.2. Cơ chế bảo mật chưa được định nghĩa một các đầy đủ Hầu hết những chuẩn về bảo mật hiện nay đều chỉ tập trung vào việc đưa ra các định dạng bảo vệ dữ liệu trong quá trình trao đổi, mà không quan tâm đến việc xác định các nghi thức mà các bên cần thực hiện khi tương tác, như là việc chứng thực và kiểm tra quyền. 4.1.3. Các giải pháp bảo mật khó tích hợp với nhau Vì thiếu những chuẩn chung về việc chỉ ra nghi thức giao tiếp giữa những web service khiến cho các sản phẩm hỗ trợ cho vấn đề bảo mật của web service trên thị trường ngày nay không thể [38] hoàn toàn tích hợp với nhau, mặc dù các sản phẩm này đều được thiết kế dựa trên các chuẩn về bảo mật cho web service. 4.1.4. Bảo mật trong qui trình phối hợp hoạt động của các WS Khi số lượng các web ngày càng gia tăng, nhu cầu tái sử dụng lại các dịch vụ này, kết hợp chúng theo những qui trình xử lý khác nhau để đạt được những kết quả khác nhau đang giành được rất nhiều sự quan tâm. Và lúc này, rõ rang là ta phải giải quyết được vấn đề bảo mật trong mối quan hệ tương tác giữa các web service. 4.1.5. Bảo mật và vấn đề hiệu suất hoạt động Một hệ thống sử dụng cơ chế bảo mật khóa công cộng đòi hỏi phải thực hiện rất nhiều phép tính như là chứng nhận thông điệp, mã hóa và kiểm tra các giấy chứng nhận. Việc truyền gửi một thông điệp đã được chứng nhận sẽ chậm hơn rất nhiều lần so với việc truyền gửi một thông điệp thông thường. Và chắc chắn rằng, sẽ luôn luôn có một sự ràng buộc giữa mức độ bảo mật và hiệu suất hoạt động của hệ thống. Vấn đề đặt ra đó 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 những công nghệ tối ưu về hiệu quả nhằm đảm bảo rằng hệ thống SOA được an toàn, trong khi vẫn có hiệu suất hoạt động ở mức chấp nhận được. 4.2. Giao thức bảo mật SSL 4.2.1. Cấu trúc giao thức bảo mật SSL SSL là giao thức đa mục đích được thiết kế để tạo ra các giao tiếp giữa hai chương trình ứng dụng trên một cổng định trước (thông thường là socket 443) nhằm mã hoá toàn bộ thông tin đi/đến, mà ngày nay được sử dụng rộng rãi cho giao dịch điện tử như truyền số hiệu thẻ tín dụng, mật khẩu, số bí mật cá nhân (PIN) trên Internet. Giao thức SSL được hình thành và phát triển đầu tiên năm 1994 bởi nhóm nghiên cứu Netscape dẫn dắt bởi Elgammal và ngày nay đã trở thành chuẩn bảo mật thực hành trên mạng Internet. Phiên bản SSL hiện nay là 3.0 và vẫn đang tiếp tục được bổ sung và hoàn thiện. Chức năng chính là bảo vệ bằng mật mã lưu lượng dữ liệu HTTP. Giao thức SSL dựa trên hai nhóm con giao thức là giao thức “bắt tay” (handshake protocol) và giao thức “bản ghi” (record protocol). Giao thức bắt tay xác định các tham số giao dịch giữa hai [39] đối tượng có nhu cầu trao đổi thông tin hoặc dữ liệu, còn giao thức bản ghi xác định khuôn dạng cho tiến hành mã hoá và truyền tin hai chiều giữa hai đối tượng đó. Khi hai ứng dụng máy tính, thí dụ giữa một trình duyệt web và máy chủ web, làm việc với nhau, máy chủ và máy khách sẽ trao đổi “lời chào” (hellos) dưới dạng các thông điệp cho nhau với xuất phát đầu tiên chủ động từ máy chủ, đồng thời xác định các chuẩn về thuật toán mã hoá và nén số liệu có thể được áp dụng giữa hai ứng dụng. Ngoài ra, các ứng dụng còn trao đổi “số nhận dạng/khoá theo phiên” (session ID, session key) duy nhất cho lần làm việc đó. Sau đó ứng dụng khách (trình duyệt) yêu cầu có chứng thực điện tử (digital certificate) xác thực của ứng dụng chủ (web server). Cấu trúc của một giao thức bảo mật SSL như hình sau: Hình 4.1: Cấu trúc của giao thức bảo mật SSL Hình trên mô tả giao thức bảo mật SSL. Trong đó, SSL chỉ một lớp bảo mật trung gian giữa tầng transport và tầng application. SSL được xếp lớn lên trên một dịch vụ vận chuyển định hướng kết nổi và đáng tin cậy. Chẳng hạn như được cung cấp bở TCP. Về khả năng, nó có thể cung cấp các dịch vụ bảo mật cho các giao thức ứng dụng tùy ý dựa vào TCP chứ không chỉ HTTP. Thực tế, một ưu điểm chính của các giao thức bảo mật tầng vận chuyển (transport layer) nói chung và giao thức SSL nói riêng là chúng độc lập với ứng dụng theo nghĩa là chúng có thể được sử dụng [40] để bảo vệ bất kỳ giao thức ứng dụng được xếp lớp lên trên TCP một cách trong suốt. Hình minh họa một số giao thức ứng dụng điển hình bao gồm NSIIOP, HTTP, FTP, Telnet, IMAP, IRC, và POP3. Tất cả chúng có thể được bảo vệ bằng cách xếp lớn chúng lên trên SSL (mẫu tự S được thêm vào trong các từ ghép giao thức tương ứng chỉ định việc sử dụng SSL). Tuy nhiên, chú ý rằng SSL có một định hướng client-server mạnh mẽ và thật sự không đáp ứng các yêu cầu của các giao thức ứng dụng ngang hàng. Tóm lại, giao thức SSL cung cấp sự bảo mật truyền thông vốn có ba đặc tính cơ bản: 1. Các bên giao tiếp (nghĩa là client và server) có thể xác thực nhau bằng cách sử dụng mật mã khóa chung. 2. Sự bí mật của lưu lượng dữ liệu được bảo vệ vì nối kết được mã hóa trong suốt sau khi một sự thiết lập quan hệ ban đầu và sự thương lượng khóa session đã xảy ra. 3. Tính xác thực và tính toàn vẹn của lưu lượng dữ liệu cũng được bảo vệ vì các thông báo được xác thực và được kiểm tra tính toàn vẹn một cách trong suốt bằng cách sử dụng MAC. Tuy nhiên, điều quan trọng cần lưu ý là SSL không ngăn các cuộc tấn công phân tích lưu lượng. Ví dụ, bằng cách xem xét các địa chỉ IP nguồn và đích không được mã hóa và các sô cổng TCP, hoặc xem xét lượng dữ liệu được truyền, một người phân tích lưu lượng vẫn có thể xác định các bên nào đang tương tác, các loại dịch vụ đang được sử dụng, và đôi khi ngay cả dành được thông tin về các mối quan hệ doanh nghiệp hoặc cá nhân. Hơn nữa, SSL không ngăn các cuộc tấn công có định hướng dựa vào phần thực thi TCP, chẳng hạn như các cuộc tấn công làm tràn ngập TCP SYN hoặc cưỡng đoạt session. Để sử dụng sự bảo vệ SSL, cả client lẫn server phải biết rằng phía bên kia đang sử dụng SSL. Nói chung, có ba khả năng để giải quyết vấn đề này: 1. Sử dụng các số cổng chuyên dụng được dành riêng bởi Internet Asigned Numbers Authority (IANA). Trong trường hợp này, một số cổng riêng biệt phải được gán cho mọi giao thức ứng dụng vốn sử dụng SSL. 2. Sử dụng số cổng chuẩn cho mọi giao thức ứng dụng và để thương lượng các tùy chọn bảo mật như là một phần của giao thức ứng dụng (bây giờ được chỉnh sửa đôi chút). [41] 3. Sử dụng một tùy chọn TCP để thương lượng việc sử dụng một giao thức bảo mật, chẳng hạn như SSL trong suốt giai đoạn thiết lập nối kết TCP thông thường. Sự thương lượng dành riêng cho ứng dụng của các tùy chọn bảo mật (nghĩa là khả năng thứ hai) có khuyết điểm là đòi hỏi mọi giao thức ứng dụng được chỉnh sửa để hiểu tiến trình thương lượng. Ngoài ra, việc xác định một tùy chọn TCP (nghĩa là khả năng thứ ba) là một giải pháp tốt, nhưng đó không được thảo luận nghiêm túc cho đến bây giờ. Thực tế, các số cổng riêng biệt đã được dành riêng và được gán bởi IANA cho mọi giao thức ứng dụng vốn có thể chạy trên SSL hoặc TLS (nghĩa là khả năng thứ nhất). Tuy nhiên, hãy chú ý việc sử dụng các số cổng riêng biệt cũng có khuyết điểm là đòi hỏi hai nối kết TCP nếu client không biết những gì mà server hỗ trợ. Trước tiên, client phải nối kết với cổng an toàn và sau đó với cổng không an toàn hay ngược lại. Rất có thể các giao thức sau này sẽ hủy bỏ phương pháp này và tìm khả năng thứ hai. Ví dụ, SALS (Simple Authentication và Security Layer) xác định một phù hợp để thêm sự hỗ trợ xác thực vào các giao thức ứng dụng dựa vào kết nối. Theo thông số kỹ thuật SALS, việc sử dụng các cơ chế xác thực có thể thương lượng giữa client và server của một giao thức ứng dụng đã cho. Các số cổng được gán bởi IANA cho các giao thức ứng dụng vốn chạy trên SSL/TLS được tóm tắt trong bảng 1.2 và được minh họa một phần trong hình 1.1. Ngày nay, "S" chỉ định việc sử dụng SSL được thêm (hậu tố) nhất quán vào các từ ghép của các giao thức ứng dụng tương ứng (trong một số thuật ngữ ban đầu, S được sử dụng và được thêm tiền tố một cách không nhất quán và một số từ ghép). Bảng 4.1: Các số cổng được gán cho các giao thức ứng dụng chạy trên TLS/SSL. Từ khóa Cổng Mô tả Nsiiop 261 Dịch vụ tên IIOP trên TLS/SSL https 443 HTTP trên TLS/SSl Smtps 465 SMTP trên TLS/SSL [42] Nntps 563 NNTP trên TLS/SSL Ldaps 636 LDAP trên TLS/SSL Ftps-data 989 FTP (dữ liệu) trên TLS/SSL Ftps 990 FTP (Điều khiển) trên TLS/SSL Tenets 992 TELNET trên TLS/SSL Imaps 994 IRC trên TLS/SSL Pop3s 995 POP3 trên TLS/SSL Nói chung, một session SSL có trạng thái và giao thức SSL phải khởi tạo và duy trì thông tin trạng thái ở một trong hai phía của session. Các phần tử thông tin trạng thái session tương ứng bao gồm một session ID, một chứng nhận ngang hàng, một phương pháp nén, một thông số mật mã, một khóa mật chính và một cờ vốn chỉ định việc session có thể tiếp tục lại hay không, được tóm tắt trong bảng 1.3. Một session SSL có thể được sử dụng trong một số kết nối và các thành phần thông tin trạng thái nối kết tương ứng được tóm tắt trong bảng 1.4. Chúng bao gồm các tham số mật mã, chẳng hạn như các chuỗi byte ngẫu nhiên server và client, các khóa mật MAC ghi server và client, các khóa ghi server và client, một vector khởi tạo và một số chuỗi. Ở trong hai trường hợp, điều quan trọng cần lưu ý là các phía giao tiếp phải sử dụng nhiều session SSL đồng thời và các session có nhiều nối kết đồng thời. Bảng 4.2. Các thành phần thông tin trạng thái Session SSL Thành Phần Mô tả Session ID Định danh được chọn bởi server để nhận dạng một trạng thái session hoạt động hoặc có thể tiếp tục lại. [43] Peer certificate Chứng nhân X.509 phiên bản 3 của thực thể ngang hàng. Compression method Thuật toán dừng để nén dữ liệu trước khi mã hóa Cipher spec Thông số của các thuật toán mã hóa dữ liệu và MAC Master secret Khóa mật 48-byte được chia sẻ giữa client và server. Is resumable Cờ vốn biểu thị session có thể được sử dụng để bắt đầu các nối kết mới hay không. Bảng 4.3. Các thành phần thông tin trạng thái nối kết SSL Thành Phần Mô tả Ngẫu nhiên server và client Các chuỗi byte được chọn bởi server và client cho mỗi nối kết. Khóa mật MAC ghi server Khóa mật được sử dụng cho các hoạt động MAC trên dữ liệu được ghi bởi server. Khóa mật MAC ghi client Khóa mật được sử dụng cho các hoạt động MAC trên dữ liệu được ghi bởi client. Khóa ghi server Khóa được sử dụng cho việc mã hóa dữ liệu bởi server và giải mã bởi client [44] Khóa ghi client Khóa được sử dụng để mã khóa dữ liệu bởi client và giải mã bởi server. Initialization vector Trạng thái khởi tạo cho một mật mã khối trong chế độ CBC. Trường này được khởi tạo đầu tiên bởi SSL Handshake Player. Sau đó, khối text mật mã sau cùng từ mỗi bản ghi được dành riêng để sử dụng vởi bản ghi sau đó. Số chuỗi Mỗi phía duy trì các số chuỗi riêng biệt cho các thông báo được truyền và được nhận cho mỗi nối kết. Như được minh họa trong hình 1.1, giao thức SSL gồm hai phần chính, SSL Record Protocol và một số giao thức con SSL được xếp lớp trên nó: - Record OK được xếp lớp trên một dịch vụ lớp vận chuyển định hướng nối kết và đáng tin cậy, chẳng hạn như được cung cấp bởi TCP và cung cấp sự xác thực nguồn gốc thông báo, sự bí mật dữ liệu và dữ liệu. - Các dịch vụ toàn vẹn (bao gồm nhưng thứ như chống xem lại). - Các giao thức con SSL được xếp lớp trên SSL Record Protocol để cung cấp sự hỗ trợ cho việc quản lý session SSL và thiết lập nối kết. - Giao thức con SSL quan trọng nhất là SSL Handshake Protocol. Lần lượt giao thức này là một giao thức xác thực và trao đổi khóa vốn có thể được sử dụng để thương lượng, khởi tạo và đồng bộ hóa các tham số bảo mật và thông tin trạng thái tương ứng được đặt ở một trong hai điểm cuối của một session hoặc nối kết SSL. - Sau khi SSL Handshake Protocol đa hoàn tất, dữ liệu ứng dụng có thể được gửi và được nhận bằng cách sử dụng SSL Record Protocol và các tham số bảo mật được thương lượng và các thành phần thông tin trạng thái. SSL Record và Handshake Protocol được trình bày tổng quan ở phần tiếp theo. [45] 4.2.2. SSL Record Protocol SSL Record Protocol nhận dữ liệu từ các giao thức con SSL lớp cao hơn và xử lý việc phân đoạn, nén, xác thực và mã hóa dữ liệu. Chính xác hơn, giao thức này lấy một khối dữ liệu có kích cỡ tùy ý làm dữ liệu nhập và tọa một loạt các đoạn dữ liệu SSL làm dữ liệu xuất (hoặc còn được gọi là các bản ghi) nhỏ hơn hoặc bằng 16,383 byte. hình 4.2: Các bước SSL Record Protocol. Các bước khác nhau của SSL Record Protocol vốn đi từ một đoạn dữ liệu thô đến một bản ghi SSL Plaintext (bước phân đoạn), SSL Compressed (bước nén) và SSL Ciphertext (bước mã hóa) được minh họa trong hình 1.5. Sau cùng, mỗi bản ghi SSL chứa các trường thông tin sau đây: - Loại nội dung; - Số phiên bản của giao thức; - Chiều dài; - Tải trọng dữ liệu (được nén và được mã hóa tùy ý); - MAC. [46] Loại nội dung xác định giao thức lớp cao hơn vốn phải được sử dụng để sau đó xử lý tải trọng dữ liệu bản ghi SSL (sau khi giải nén và giải mã hóa thích hợp). Số phiên bản của giao thức xác định phiên bản SSL đang sử dụng (thường là version 3.0) Mỗi tải trọng dữ liệu bản ghi SSL được nén và được mã hóa theo phương thức nén hiện hành và thông số mật mã được xác định cho session SSL. Lúc bắt đầu mỗi session SSL, phương pháp nén và thông số mật mã thường được xác định là rỗng. Cả hai được xác lập trong suốt quá trình thực thi ban đầu SSL Handshake Protocol. Sau cùng, MAC được thêm vào mỗi bản ghi SSL. Nó cung cấp các dịch vụ xác thực nguồn gốc thông báo và tính toàn vẹn dữ liệu. Tương tự như thuật toán mã hóa, thuật toán vốn được sử dụng để tính và xác nhận MAC được xác định trong thông số mật mã của trạng thái session hiện hành. Theo mặc định, SSL Record Protocol sử dụng một cấu trúc MAC vốn tương tự nhưng vẫn khác với cấu trúc HMAC hơn. Có ba điểm khác biệt chính giữa cấu trúc SSL MAC và cấu trúc HMAC: 1. Cấu trúc SSL MAC có một số chuỗi trong thông báo trước khi hash để ngăn các hình thức tấn công xem lại riêng biệt. 2. Cấu trúc SSL MAC có chiều dài bản ghi. 3. Cấu trúc SSL MAC sử dụng các toán tử ghép, trong khi cấu trúc MAC sử dụng moduloe cộng Tất cả những điểm khác biệt này hiện hữu chủ yếu vì cấu trúc SSL MAC được sử dụng trước cấu trúc HMAC trong hầu như tất cả thông số kỹ thuật giao thức bảo mật Internet. Cấu trúc HMAC cũng được sử dụng cho thông số kỹ thuật giao thức TLS gần đây hơn. Như được minh họa trong hình 1.5, một số giao thức con SSL được xếp lớp trên SSL Record Protocol. Mỗi giao thức con có thể tham chiếu đến các loại thông báo cụ thể vốn được gửi bằng cách sử dụng SSL Record Protocol. Thông số kỹ thuật SSL 3.0 xác định ba giao thức SSL sau đây: Alert Protocol; - Handshake Protocol; - ChangeCipherSpec Protocol; Tóm lại, SSL Alert Protocol được sử dụng để chuyển các cảnh báo thông qua SSL Record Protocol. Mỗi cảnh báo gồm 2 phần, một mức cảnh báo và một mô tả cảnh báo. SSL Handshake Protocol là giao thức con SSL chính được sử dụng để hỗ trợ xác thực client và server và để trao đổi một khóa session. Do đó SSL Handshake Protocol trình bày tổng quan và [47] được thảo luận trong phần tiếp theo. Sau cùng, SSL ChangeCipherSpec Protocol được sử dụng để thay đổi giữa một thông số mật mã này và một thông số mật mã khác. Mặc dù thông số mật mã thường được thay đổi ở cuối một sự thiết lập quan hệ SSL, nhưng nó cũng có thể được thay đổi vào bất kỳ thời điểm sau đó. Ngoài những giao thức con SSL này, một SSL Application Data Protocol được sử dụng để chuyển trực tiếp dữ liệu ứng dụng đến SSL Record Protocol. 4.2.3. SSL Handshake Protocol SSL Handshake Protocol [8, 20] là giao thức con SSL chính được xếp lớp trên SSL Record Protocol. Kết quả, các thông báo thiết lập quan hệ SSL được cung cấp cho lớp bản ghi SSL nơi chúng được bao bọc trong một hoặc nhiều bản ghi SSL được xử lý và được chuyển như được xác định bởi phương pháp nén và thông số mật mã của session SSL hiện hành và các khóa mật mã của kết nối SSL tương ứng. Mục đích của SSL Handshake Protocol là yêu cầu một client và server thiết lập và duy trì thông tin trạng thái được sử dụng để bảo vệ các cuộc liên lạc. Cụ thể hơn, giao thức phải yêu cầu client và server chấp thuận một phiên bản giao thức SSL chung, chọn phương thức nén và thông số mật mã, tùy ý xác thực nhau và tạo một khóa mật chính mà từ đó các khóa session khác nhau dành cho việc xác thực và mã hóa thông báo có thể được dẫn xuất từ đó. Tóm lại, việc thực thi SSL Handshake Protocol giữa một client C và một server S có thể được tóm tắt như sau (các thông báo được đặt trong các dấu ngoặc vuông thì tùy chọn): 1: C -> S: CLIENTHELLO 2: S -> C: SERVERHELLO [CERTIFICATE] [SERVERKEYEXCHANGE] [CERTIFICATEREQUEST] SERVERHELLODONE 3: C -> [CERTIFICATE] [48] CLIENTKEYEXCHANGE [CERTIFICATEVERIFY] CHANGECIPHERSPEC FINISHED 4: S -> C: CHANGECIPHERSPEC FINISHED Khi Client C muốn kết nối với Server S, nó thiết lập một kết nối TCP với cổng HTTPS (không được đưa vào phần mô tả giao thức) và gửi một thông báo CLIENTHELLO đến server ở bước 1 của sự thực thi SSL Handshake Protocol. Client cũng có thể gởi một thông báo CLIENTHELLO nhằm phản hồi lại một thông báo HELLOREQUEST hoặc chủ động thương lượng lại các tham số bảo mật của một kết nối hiện có. Thông báo CLIENTHELLO bao gồm các trường sau đây: – Số của phiên bản SSL cao nhất được biểu hiện bởi client (thường là 3.0). – Một cấu trúc ngẫu nhiên do client tạo ra gồm một tem thời gian 32 bit có dạng UNIX chuẩn và một giá trị 28 byte được tạo ra bởi một bộ tạo số giả ngẫu nhiên. – Một định danh session mà client muốn sử dụng cho kết nối này. – Một danh sách các bộ mật mã client hỗ trợ. – Một danh sách các phương pháp nén mà client hỗ trợ. Chú ý rằng trường session identity (định danh session) nên rỗng nếu session SSL hiện không tồn tại hoặc nếu client muốn tạo các tham số bảo mật mới. Ở một trong hai trường hợp, một trường session identity không rỗng là xác định một session SSL hiện có giữa client và server (nghĩa là một session có các tham số bảo mật mà client muốn sử dụng lại). Định danh session có thể bắt nguồn từ một kết nối trước đó, kết nối này hoặc một kết nối đang hoạt động. Cũng chú ý rằng danh sách các bộ mật mã được hỗ trợ, được chuyển từ client đến server trong thông báo CLIENTHELLO, chứa các tổ hợp thuật toán mật mã được hỗ trợ bởi client theo thứ tự ưu tiên. Mỗi bộ mật mã xác định một thuật toán trao đổi khóa và một thông báo mật mã. Server sẽ chọn [49] một bộ mật mã hoặc nếu các lựa chọn có thể chấp nhận được không được trình bầy, trả về một thông báo lỗi và đóng kết nối một cách phù hợp. Sau khi đa gởi thông báo CLIENTHELLO, client đợi một thông báo SERVERHELLO. Bất kỳ thông báo khác được trả về bởi server ngoại trừ một thông báo HELLOREQUEST được xem như là một lỗi vào thời điểm này. Ở bước 2, server xử lý thông báo CLIENTHELLO và đáp ứng bằng một thông báo lỗi hoặc thông báo SERVERHELLO. Tương tự như thông báo CLIENTHELLO, thông báo SERVERHELLO có các trường sau đây: – Một số phiên bản server chứa phiên bản thấp hơn của phiên bản được đề nghị bởi client trong thông báo CLIENTHELLO và được hỗ trợ cao nhất bởi Server. – Một cấu trúc ngẫu nhiên do server tạo ra cũng gồm một tem thời gian 32bit có dạng UNIX chuẩn và một giá trị 28bit được tạo ra bởi một bộ tạo số ngẫu nhiên. – Một định danh session tương ứng với kết nối này. – Một bộ mật mã được chọn bởi server từ danh sách các bộ mật mã được hỗ trợ bởi client. – Một phương pháp nén được chọn bởi server từ danh sách các thuật toán nén được hỗ trợ bởi client. Nếu định danh session trong thông báo CLIENTHELLO không rỗng, server tìm trong cache session của nó nhằm tìm ra một mục tương hợp. Nếu mục tương hợp được tìm thấy và server muốn thiết lập kết nối mới bằng cách sử dụng trạng thái session tương ứng, server đáp ứng bằng cùng một giá trị như được cung cấp bởi client. Chỉ định này là một session được tiếp tục lại và xác định rằng cả hai phía phải tiến hành trực tiếp với các thông báo CHANGECIPHERSPEC và FINISHED được trình bày thêm bên dưới. Nếu không, trường này chứa một giá trị khác nhận biết một session mới. Server cũng có thể trả về một trường định danh session rỗng để biểu thị rằng session sẽ không được lưu trữ và do đó không thể được tiếp tục sau đó. Cũng chú ý rằng trong thông báo SERVERHELLO, server chọn một bộ mật mã và một phương pháp nén từ các danh sách được cung cấp bởi client trong thông báo CLIENTHELLO. Các thuật toán trao đổi khóa, xác thực, mã hóa và xác thực thông báo được xác định bởi bộ mã hoá được chọn bởi server và được gửi trong thông báo SERVERHELLO. [50] Các bộ mã hoá đã được xác định trong giao thức SSL về cơ bản giống như bộ mã hoá đã xác định cho TLS. Ngoài thông báo SERVERHELLO, server cũng phải gửi các thông báo khác đến client. Ví dụ, nếu server sử dụng sự xác thức dựa vào chứng chỉ số, server gửi chứng chỉ số site của nó đến client trong một thông báo CERTIFICATE tương ứng. Chứng chỉ số phải thích hợp cho thuật toán trao đổi khóa của bộ mã hoá được chọn và thường là một chứng chỉ số X.509v3. Cùng loại thông báo sẽ được sử dụng sau đó cho sự đáp ứng của client đối với thông báo sẽ được sử dụng sau đó cho sự đáp ứng của client đối với thông báo CERTIFICATERequest của server. Trong trường hợp của các chứng nhận X.509v3, một chứng chỉ số có thể thực sự tham chiếu đến toàn bộ một chuỗi các chứng chỉ số, được sắp xếp theo thứ tự với chứng chỉ số của đối tượng gửi trước tiên theo sau là bất kỳ chứng chỉ số CA tiến hành theo trình tự hướng đến một CA gốc (sẽ được chấp nhận bởi client). Tiếp theo, server có thể gửi một thông báo SERVERKEYEXCHANGE đến client nếu nó không có chứng chỉ số, một chứng chỉ số có thể được sử dụng chỉ để xác nhận các chữ ký kỹ số hoặc sử dụng thuật toán trao đổi khóa dựa vào token FORITEZZA (KEA). Rõ ràng, thông báo này không được yêu cầu nếu chứng chỉ số site gồm một khóa chung RSA có thể được sử dụng trong việc mã hóa. Ngoài ra, một server không nặc danh có thể tùy ý yêu cầu một chứng chỉ số cá nhân để xác thực client. Do đó, nó gửi một thông báo CERTIFICATERequest đến client. Thông báo này chứa một danh sách các loại chứng chỉ số được yêu cầu, được phân loại theo thứ tự ưu tiên của server cũng như một danh sách các tên được phân biệt cho các CA có thể chấp nhận. Ở cuối bước 2, server gửi một thông báo SERVERHELLODone đến client để chỉ định sự kết thúc SERVERHELLO và các thông báo đi kèm. Sau khi nhận SERVERHELLO và các thông báo đi kèm, client xác nhận rằng chứng chỉ số site server (nếu được cung cấp) là hợp lệ và kiểm tra nhằm bảo đảm rằng các thông số bảo mật được cung cấp trong thông báo SERVERHELLO có thể được chấp nhận. Nếu server yêu cầu sự xác thực client, client gửi một thông báo CERTIFICATE chứa một chứng chỉ số cá nhân cho khóa chung của người dùng đến server ở bước 3. Tiếp theo, client gửi một thông báo CLIENTKEYEXCHANGE có dạng phụ thuộc vào thuật toán cho mỗi khóa được chọn bởi server: [51] – Nếu RSA được sử dụng cho việc xác thực server và trao đổi khóa, client tạo một khóa mật premaster 48 byte, mã hóa nó bằng khóa chung được tìm thấy trong chứng chỉ số site hoặc khóa RSA tạm thời từ thông báo SERVERKEYEXCHANGE và gửi kết quả trở về server trong thông báo CLIENTKEYEXCHANGE. Lần lượt server sử dụng khóa riêng tương ứng để giải mã khóa mật chính. – Nếu các token FORTEZZA được sử dụng để trao đổi khóa, client dẫn xuất một khóa mã hóa token (TEK) bằng cách sử dụng KEA. Phép tình KEA cảu client sử dụng khóa chung từ chứng chỉ số server cùng với một số tham số riêng trong token của client. Client gửi các tham số chung cần thiết cho server để cũng tạo TEK, sử dụng các tham sô riêng của nó. Nó tạo một khóa mật master, bao bọc nó bằng cách sử dụng TEK và gửi kết quả cùng với một số vector khởi tạo đến server như là một phần của thông báo CLIENTKEYEXCHANGE. Lần lượt, server có thể giải mã khóa mật master một cách thích hợp. Thuật toán trao đổi khóa này không được sử dụng rộng rãi. Nếu sự xác thực client được yêu cầu, client cũng gửi một thông báo CERTIFICATEVERIFY đến server. Thông báo này được sử dụng để cung cấp sự xác thực rõ ràng định danh của người dùng dựa vào chứng chỉ số cá nhân. Nó chỉ được gửi theo sau một chứng chỉ client có khả năng tạo chữ ký (tất cả chứng nhận ngoại trừ các chứng chỉ số chứa các tham số Diffie - Hellman cố định). Sau cùng, client hoàn tất bước 3 bằng cách gửi một thông báo CHANGECIPHERSPEC và một thông báo FINISHED tương ứng đến server. Thông báo FINISHED luôn được gửi ngay lập tức sau thông báo CHANGECIPERSPEC để xác nhận rằng các tiến trình trao đổi khóa và xác thực đa thành công. Thực tế, thông báo FINISHED là thông báo đầu tiên được bảo vệ bằng các thuật toán mới được thoả thuận và các khóa session. Nó chỉ có thể được tạo và được xác nhận nếu những khóa này được cài đặt một cách phù hợp ở cả hai phía. Không đoi hỏi sự xác nhận thông báo FINISHED; các phía có thể bắt đầu gửi dữ liệu được mã hóa ngay lập tức sau khi đa gửi thông báo FINISHED. Việc thực thi SSL Handshake Protocol hoàn tất bằng việc server gửi một thông báo CHANGECIPHERSPEC và một thông báo FINISHED tương ứng đến client ở bước 4. Sau khi sự thiết lập SSL hoàn tất, một kết nối an toàn được thiết lập giữa client và server. Kết nối này bây giờ có thể được sử dụng để gửi dữ liệu ứng dụng. Chính xác hơn, dữ liệu ứng dụng có [52] thể được phân đoạn, được nén, hoặc được mã hóa và được xác thực theo SSL Record Protocol cũng như thông tin trạng thái session và kết nối bây giờ được thiết lập (tùy thuộc việc thực thi SSL Handshake Protocol). SSL Handshake Protocol có thể được rút ngắn nếu client và server quyết định tiếp tục lại một session SSL được thiết lập trước đó (và vẫn được lưu trữ) hoặc lặp lại một session SSL hiện có. Trong trường hợp này, chỉ ba dòng thông báo và tổng cộng sáu thông báo được yêu cầu. Các dòng thông báo tương ứng có thể được tóm tắt như sau: 1: C -> S: CLIENTHELLO 2: S -> C: SERVERHELLO CHANECIPHERSPEC FINISHED 3: S ->C: CHANGECIPHERSPEC FINISHED Ở bước 1, client gửi một thông báo CLIENTHELLO đến server có một định danh session cần được tiếp tục lại. Lần lượt server kiểm tra cache session của nó để tìm một mục tương hợp. Nếu một mục tương hợp được tìm thấy, server muốn tiếp tục lại kết nối bên dưới trạng thái session đã xác định, nó trả về một thông báo SERVERHELLO với cùng một định danh session ở bước 2. Vào thời điểm này, cả client lẫn server phải gởi các thông báo CHANGECIPHERSPEC và FINISHED đến nhau ở bước 2 và 3. Một khi việc tái thiết lập session hoàn tất, client và server có thể bắt đầu trao đổi dữ liệu ứng dụng. Các thuật toán mã hoá và xác thực của SSL được sử dụng bao gồm (phiên bản 3.0):  DES: chuẩn mã hoá dữ liệu (ra đời năm 1977), phát minh và sử dụng của chính phủ Mỹ.  DSA: thuật toán chữ ký điện tử, chuẩn xác thực điện tử, phát minh và sử dụng của chính phủ Mỹ.  KEA: thuật toán trao đổi khoá, phát minh và sử dụng của chính phủ Mỹ. [53]  MD5: thuật toán tạo giá trị “băm” (message digest), phát minh bởi Rivest.  RC2, RC4: mã hoá Rivest, phát triển bởi công ty RSA Data Security.  RSA: thuật toán khoá công khai, cho mã hoá và xác thực, phát triển bởi Rivest, Shamir và Adleman.  RSA key exchange: thuật toán trao đổi khoá cho SSL dựa trên thuật toán RSA.  SHA-1: thuật toán hàm băm an toàn, phát triển và sử dụng bởi chính phủ Mỹ.  SKIPJACK: thuật toán khoá đối xứng phân loại được thực hiện trong phần cứng Fortezza, sử dụng bởi chính phủ Mỹ.  Triple-DES: mã hoá DES ba lần. Cơ sở lý thuyết và cơ chế hoạt động của các thuật toán sử dụng về bảo mật trên hiện nay là phổ biến rộng rãi và công khai, trừ các giải pháp thực hiện trong ứng dụng thực hành vào trong các sản phẩm bảo mật (phần cứng, phần mềm). Đã có những kết luận cho rằng SSL cung cấp sự bảo mật hoàn hảo ngăn việc nghe lén và những cuộc tấn công thụ động khác, và người thực thi giao thức này sẽ ý thức đến một số cuộc tấn công chủ động tinh vi. 4.3. Khai thác tính năng bảo mật của bộ thư viện Web Service Enhancement (WSE) Có rất nhiều lựa chọn khác nhau có sẵn để giúp an ninh các dịch vụ web và các tổ chức khác nhau có các tiêu chí khác nhau giải quyết vấn đề an ninh của họ. Và trong luận văn này, tôi lựa chọn nghiên cứu về WSE. Wse là bộ thư viện lập trình trên nền .NET, hỗ trợ trong việc xây dựng các web service theo những chuẩn mới nhất như WS-Security, WS-SecureConversation, WS-Trust, WS-Policy, WS- securityPolicy, WS-Addressing, WS-Messageing và WS-Attachments. Với bộ thư viện này, ta có thể đưa ra các tính năng liên quan đến bảo mật này vào web service trong lúc thiết kế bằng cách sử dụng mã lệnh hay vào thời điểm triển khai thông qua việc sử dụng các tập tin policy. [54] 4.3.1. Những tính năng bảo mật web service của wse Wse sử dụng các cơ chế được định nghĩa trong ws-security để đặt các ủy quyền chứng thực (security credential) như security token vào trong các thông điệp SOAP. Wse sau đó sẽ thực hiện kiểm tra tính hợp lệ của những security credentials trước khi chuyển quyền thực thi cho các web service. Wse 2.0 hỗ trợ các loại security token sau: username/password, X.509 Certificate, Kerberos ticket, Security Context token và các loại security token do người dùng định nghĩa. Chúng ta sẽ tìm hiểu phần này ngay sau đây. Wse còn cho phép các nhà phát triển xây dựng riêng cho mình các dịch vụ security token. Các dịch vụ này có thể tạo ra các loại security token khác mà có thể dụng trong quá trình tương tác với các web service nào tin tưởng vào dịch vụ này. Thông qua việc hỗ trợ xác nhận số hay mã hóa các thông điệp SOAP sẽ tăng cường khả năng an toàn cho các web service. - Xác nhận một số thông điệp SOAP sẽ giúp cho đối tượng nhận thông điệp kiểm tra được thông điệp có bị thay đổi hay không. Hình 4.3: Xác nhận số một thông điệp - Mã hóa một thông điệp SOAP sẽ đảm bảo cho chỉ những web service mong muốn mới có thể đọc được nội dung của thông điệp đó. Hình 4.4: Mã hóa một thông điệp [55] 4.3.3. Hô trợ policy Wse hỗ trợ các nhà phát triển đưa ra các yêu cầu về quá trình gửi và nhận thông điệp bằng cách dùng các tập tin câu hình. Trước đây, một đối tượng khi nhận được một thông điệp SOAP phải dùng mã lệnh để kiểm tra các thông tin về thông điệp nhận được như là có được xác nhận số hay mã hóa chưa? Và cũng tương tự như thế, phía gửi cũng phải viết mã lệnh để lấy được các yêu cầu này từ phía nhà cung cấp. Nay thì các yêu cầu này có thể được cung cấp thông qua các tập tin cấu hình. Khi các cơ chế xác nhận policy được chỉ định: - Các thông điệp SOAP khi được gửi đi sẽ qua quá trình kiểm tra để đảm bảo chúng thỏa mãn các policy assertion của phía gửi. Nếu không thỏa mãn, wse sẽ đưa ra một ngoại lệ. - Các thông điệp SOAP trước khi được nhận vào sẽ phải được kiểm tra xem có đáp ứng được các policy assertion của phía nhận hay không? Nếu không, thông điệp đó sẽ được gửi trả về hay một ngoại lệ sẽ được đưa ra. Wse đã hỗ trợ sẵn một vài cơ chế xác nhận policy (ví dụ như: yêu cầu phần body của thông điệp phải được xác nhận-signed bởi một X.509 certificate). Ngoài ra, hệ thống policy còn cho phép thêm những cơ chế xác nhận policy khác do người dùng định nghĩa. a. SOAP messaging Đây là một tính năng nổi trội của wse.SOAP messaging hỗ trợ nhiều nghi thức ở tầng vận chuyển như HTTP, TCP, với giao diện bất đồng bộ hay đồng bộ. Đặc biệt, khi thực hiện việc gửi và nhận các thông điệp theo nghi thức TCP thì ta không cần phải có một Web Server. b. Điều phối các thông điệp SOAP Ta có thể sử dụng wse để xây dựng các ứng dụng phân tán mà kiến trúc phân tán của nó là trong suốt đối với người dùng. Ta sử dụng một máy tính trung gian và cấu hình nó chạy WSE router. Người dùng sẽ gửi yêu cầu đến WSE router thay vì trực tiếp đến web service. WSE router sau đó sẽ chuyển thông điệp SOAP đến máy đang chạy web service dựa trên thông tin cấu hình của router. Giải pháp này giúp hệ thống ta linh hoạt hơn, bền vững hơn, vì ta có thể thay đổi thông tin về các máy đích khi có sự cố xảy ra. [56] Hình 4.5: Điều phối thông điệp SOAP [7] c. Gửi những đối tượng kèm theo các thông điệp SOAP Wse hỗ trợ nghi thức DIME (Direct Internet Message Encapsulation). Nghi thức này định nghĩa cơ chế để đính kèm những đối tượng khác trong các thông điệp SOAP. Điều này cần thiết cho những web service nào có nhu cầu muốn gửi những thông tin có kích thước lớn (dạng text hay binary) như tập tin dạng ảnh hay âm thanh. Theo mặc định thì các thông điệp SOAP không thích hợp để gửi đính kèm các tập tin lớn. Vì định dạng của một thông điệp SOAP là theo XML, khi thêm một tập tin vào thông điệp SOAP thì đòi hỏi tập tin đó phải được chuyển đồi thành dạng XML. Điều này có thể làm tăng kích thước của tập tin lên đáng kể so với kích thước thật của nó. Nghi thức DIME giải quyết vấn đề này bằng cách định nghĩa một cơ chế để đặt toàn bộ nội dung tập tin gốc nằm ở bên ngoài thông điệp SOAP, như vậy sẽ loại bỏ được việc phải chuyển đổi nội dung tập tin sang dạng XML. CHƯƠNG 5 Xây dựng chương trình và đánh giá kết quả Từ các kiến thức về SOA và dịch vụ Web ở chương 2 và đặc biệt là kỹ thuật đảm bảo an ninh dịch vụ web ở chương 4. Tiếp theo, trong chương này sẽ đề xuất giải pháp để thực hiện bài toán, triển khai và xây dựng hệ thống. [57] 5.1. Mô tả hệ thống cần xây dựng Hệ thống nghiên cứu và xây dựng bao gồm các chức năng chính: đăng nhập, đăng kí tài khoản, mua cổ phiếu, bán cổ phiếu. Dưới đây là biểu đồ hoạt động của hệ thống. Hình 5.1 Biểu đồ hoạt động của hệ thống 5.2. Triển khai hệ thống 5.2.1. Lựa chọn ngôn ngữ lập trình Để xây dựng xây dựng một hệ thống hoàn chỉnh thực hiện đầy đủ các chức năng yêu cầu đặt ra đòi hỏi phải có một thời gian dài. Trong thời gian qua tôi đã tiến hành nghiên cứu và sử dụng lại hệ thống chứng khoán đã bước đầu đạt được những kết quả và xây dựng xong một số chức năng cơ bản mà hệ thống đặt ra và chạy thử. [58] Ngôn ngữ mà tôi sử dụng để xây dựng hệ thống là ASP.NET của bộ Visual Studio.NET. Với những tính năng nổi bật của ngôn ngữ này và nhận thấy phù hợp với sự phát triển của hệ thống cần xây dựng. 5.2.2. Hoạt động của hệ thống 5.2.2.1. Hiển thị thông tin trang chủ Hiển thị bảng giá chứng khoán, khi chưa đăng nhập cho phép xem thông tin bảng giá và chuyển sang giao diện đăng nhập hoặc đăng ký. 5.2.2.2. Đăng nhập Thời điểm: Trước khi giao dịch Mô tả: Trước khi thực hiện giao dịch nhà đầu tư cần đăng nhập vào tài khoản của mình (nếu nhà đầu tư chưa có một tài khoản có thể đăng ký một tài khoản mới theo phần đăng ký) để xác thực thông tin, sau khi đăng nhập các thông tin chi tiết của nhà đầu tư sẽ được hiển thị. [59] 5.2.2.3. Đăng ký tài khoản mới Thời điểm: Trước khi giao dịch Mô tả: Để có thể thực hiện giao dịch trước tiên nhà đầu tư phải đăng kí tài khoản chứng khoán và tài khoản ngân hàng nhà đầu tư cung cấp các thông tin cá nhân cần thiết cho công ty chứng khoán để tạo tài khoản. Nếu thông tin đầy đủ và chính xác thì hệ thống sẽ thông báo đăng ký tài khoản thành công, ngược lại sẽ báo lỗi tương ứng. Sau khi đăng ký tài khoản người dùng có thể đăng nhập và thực hiện giao dịch cổ phiếu bằng cách cung cấp các thông tin cá nhân. [60] 5.2.3.4. Thực hiện giao dịch Thời điểm: Sau khi đăng nhập Mô tả: Sau khi đăng nhập, nhà đầu tư có thể thực hiện việc mua bán bằng tài khoản của mình thông qua website.  Bán: nhà đầu tư chỉ có thể thực hiện lệnh bán đối với những cổ phiếu có trong tài khoản, số lượng cổ phiếu bán ra không được vượt quá số lượng cổ phiếu đó có trong tài khoản. Số tiền có được khi bán cổ phiếu sẽ được đưa vào tài khoản ngân hàng tương ứng của nhà đầu tư. [61]  Mua: nếu cổ phiếu mà nhà đầu tư mua đã có trong tài khoản thì cổ phiếu đó sẽ được cập nhật lại, nếu chưa có thì cổ phiếu đó sẽ được thêm vào tài khoản của nhà đầu tư. Số tiền dùng để mua cổ phiếu sẽ được trừ vào tài khoản trong ngân hàng tương ứng của nhà đầu tư. Nếu tổng giá trị của số lượng cổ phiếu mà nhà đầu tư thực hiện mua vượt quá số dư của tài khoản ngân hàng thì giao dịch sẽ không được thực hiện. 5.3. Tích hợp các thẻ bảo mật cho chương trình với công cụ WSE Thực thi WS với công cụ WSE phải chắc chắn rằng máy tính của chúng ta đã được cài đặt visual studio.NET. Sau đó thực hiện các bước sau:  Chuột phải vào tên project trong Solution Explorer và chọn WSE Settings 3.0 [62] Giao diện file config như sau: [63] Trước hết, để hệ thống hoạt động cần đánh dấu vào 2 ô “enable this project for Web Services Enhancements” và “enable Microsoft Web Services Enhancement Soap Protocol Factory”. Sau đó chúng ta thêm các thẻ secrutiy X509, Kerberos: [64] Trong tab policy phải enable Policy và dẫn đến file wse3policyCache.config. Trước khi thêm các thẻ cần phải thêm đoạn secsion để config trong file Web.config <section name="microsoft.web.services3" type="Microsoft.Web.Services3.Configuration.WebServicesConfiguration, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> [65] Sau khi thêm các thẻ trong bộ thư viện WSE, chương trình đã được bảo mật. Những thông tin trong thông điệp request bên client gửi đến cho server cũng được mã hóa, và bảo đảm. Các thông tin về username, password, các thông tin về tài khoản ngân hàng, tài khoản chứng khoán,… 5.4. Đánh giá kết quả chạy thử nghiệm chương trình Qua thời gian chạy thử nghiệm cho thấy chương trình thực hiện được các chức năng cơ bản như đăng ký, đăng nhập, mua/bán cổ phiếu đã đặt ra và đảm bảo được một số vấn đề an toàn khi cần thiết giao dịch. Sau đây chúng ta sẽ đi thử nghiệm vào các kịch bản cụ thể : - Kịch bản 1: tấn công bằng cách đăng nhập hệ thống để thành người dùng hợp pháp. Khi đăng nhập, hệ thống yêu cầu người dùng phải xác thực bằng cách nhập tài khoản và mật khẩu, mật khẩu được lưu trong biến session và được giải phóng sau khi người dùng đăng xuất để tránh kiểu tấn công. o Ấn định phiên làm việc (Session Fixation): Là kĩ thuật tấn công cho phép hacker mạo danh người dùng hợp lệ bằng cách gửi một session ID hợp lệ đến người dùng, sau khi người dùng đăng nhập vào hệ thống thành công, hacker sẽ dùng lại session ID đó và nghiễm nhiên trở thành người dùng hợp lệ. o Đánh cắp phiên làm việc (Session Hijacking): Là kĩ thuật tấn công cho phép hacker mạo danh người dùng hợp lệ sau khi nạn nhân đã đăng nhập vào hệ thống bằng cách giải mã session ID của họ được lưu trữ trong cookie hay tham số URL, biến ẩn của form. Người dùng bình thường khác sẽ không đăng nhập trái phép được vì không có tài khoản và mật khẩu Với người quản trị hệ thống (người nắm giữ cơ sở dữ liệu của người dùng) cũng không thể đăng nhập được vào hệ thống bởi kết quả lưu trong cơ sở dữ liệu không phải là mật khẩu “thô” mà là kết quả băm. Hàm băm lại là hàm một chiều nên dù biết kết quả băm cũng “khó” có thể tìm ra được văn bản gốc (mật khẩu gốc) để đăng nhập. - Kịch bản 2: tấn công vào dữ liệu trên đường truyền từ nhà đầu tư (client) đến công ty chứng khoán (server). [66] Các phương pháp mà attacker có thể sử dụng để tấn công dữ liệu trên đường truyền là: Sniffing, Man In The Middle,.. để từ đó, Hacker thu thập thông tin trên đường truyền, tập hợp lại để phân tích tìm thông tin cần thiết cho việc tấn công, hoặc ở mức độ cao hơn là sửa đổi thông tin của client gửi đến server hay mạo danh client gửi yêu cầu đến server. o Sniffing là một chương trình nghe trộm gói tin (còn gọi là chương trình phân tích mạng, chương trình phân tích giao thức hay chương trình nghe trộm). Nó là một phần mềm máy tính có khả năng chặn và ghi lại giao thông dữ liệu qua một mạng viễn thông số hoặc một phần của một mạng. Khi các dòng dữ liệu di chuyển qua lại một mạng, chương trình nghe trộm bắt lấy từng gói tin rồi giải mã và phân tích nội dung của nó. Tùy theo cấu trúc mạng (hub hay chuyển mạch), người ta có thể nghe trộm tất cả hoặc chỉ một phần của giao thông dữ liệu từ một máy trong mạng [7]. Giả danh địa chỉ MAC của card mạng máy tính bị tấn công, thay vì gói tin được truyền đến máy tính cần đến thì nó lại được chuyển đến máy tính có cài đặt ettercap trước rồi sau đó mới truyền đến máy tính đích. Đây là một dạng tấn công rất nguy hiểm được gọi là Man In The Middle, trong trường hợp này phiên làm việc giữa máy gửi và máy nhận vẫn diễn ra bình thường nên người sử dụng không hề hay biết mình đang bị tấn công. Hệ thống được cài đặt SSL cho máy chủ Web nên đảm bảo: o Các bên giao tiếp xác thực nhau tránh bị giả mạo. o Dữ liệu trên đường truyền được mã hoá đảm bảo sự bí mật. o Kiểm tra tính toàn vẹn dữ liệu. - Kịch bản 3: tấn công Web services bằng cách thực hiện các dịch vụ của nó khi không giao dịch hay không phải nhà đầu tư hợp pháp. Các khả năng tấn công xảy ra: o Hacker sửa dữ liệu của người dùng hợp pháp như số tiền tăng/giảm của nhà đầu tư, làm sai lệch thông tin đến Web services. [67] o Hacker sẽ tìm cách để thực hiện các dịch vụ trái phép như tăng/giảm số lượng tiền trong ngân hàng mà không phải thông qua giao dịch mua bán cổ phiếu của công ty chứng khoán. Web service sử dụng công cụ WSE3.0 và giao dịch được hệ thống xác nhận qua hai lần mật khẩu (mật khẩu tài khoản chứng khoán, mật khẩu tài khoản ngân hàng), xác thực người dung nên đảm bảo chỉ đúng nhà đầu tư mới thực hiện được giao dịch. [68] CHƯƠNG 6 Kết Luận 1. Tổng kết Web Service đã và đang được triển khai và áp dụng trong nhiều lĩnh vực đời sống như ngân hàng, chứng khoán…và ngày càng trở lên phổ biến. Cùng với sự phát triển của nó là những đòi hỏi về tính an toàn, khả năng bảo mật…Bằng việc sử dụng các kỹ thuật đảm bảo an ninh web service sẽ giúp cho người sử dụng dịch vụ Web trở nên an tâm hơn. Việc chọn cơ chế an toàn cho dịch vụ Web phải đòi hỏi sao cho người dùng không cảm thấy quá phức tạp hay gò bó mà phải tạo nên sự trong suốt với người dùng. Do đó, chọn cơ chế an toàn nào trong dịch vụ Web phụ thuộc nhiều vào loại dịch vụ và những tính năng mà dịch vụ này cung cấp. Bên cạnh đó còn một điểm cần quan tâm đó là sự an toàn không chỉ phụ thuộc vào những giải thuật, những tiêu chuẩn, và những cơ chế an ninh dịch vụ Web mang lại, mà nó còn tùy vào thái độ của các công ty có hiểu rõ tầm quan trọng của an toàn thông tin khi triển khai các ứng dụng, giao dịch trên mạng hay không cũng rất cần thiết. 2. Kết quả đạt được của luận văn Sau thời gian nghiên cứu tài liệu, tìm hiểu các chương trình mã nguồn mở, tôi đã hoàn thành luận văn với bài toán ban đầu đặt ra là “nghiên cứu an ninh dịch vụ web”. Với việc lựa chọn chương trình dịch vụ chứng khoán và kết hợp để đảm bảo an ninh cho các hoạt động được thực thi trên đó. Cho đến thời điểm hiện tại, luận văn đã đạt được một số kết quả sau: - Phân tích bài toán và tính cấp thiết của việc đảm bảo an toàn cho các web service. Đưa ra hướng phát triển cho bài toán. - Nghiên cứu về kiến trúc hướng dịch vụ SOA, Web Service và các thành phần của nó. Mối quan hệ ứng dụng kiến trúc SOA vào xây dựng web service và tích hợp chúng theo chuẩn. [69] - Tìm hiểu thực trạng bảo mật web service hiện nay, các công nghệ đảm bảo an ninh dịch vụ web như công nghệ bảo mật SSL và bộ thư viện WSE. - Cuối cùng, tập trung vào chạy chương trình chứng khoán, tích hợp các thẻ security trong bộ thư viện WSE vào để bảo mật thông tin cho các bên sử dụng. 3. Những hạn chế Để xây dựng được một hệ thống hoàn chỉnh có đầy đủ các chức năng và đảm bảo những yêu cầu đặt ra, cần rất nhiều thời gian. Trong thời gian nghiên cứu luận văn, cũng đã đạt được những kết quả nhất định, tuy nhiên vẫn còn nhiều hạn chế: - Chương trình khá đơn giản, với các chức năng đơn giản như đăng ký, đăng nhập, mua bán, hiển thị… - Không được đưa ra áp dụng thực tế nên sẽ có khả năng có nhiều bug mà người nghiên cứu không thể phát hiện ra. - Việc thiết kế cơ sở dữ liệu chưa thực sự tốt, vì luận văn chủ yếu tập trung vào vấn đề bảo mật cho web service. - Về bảo mật, chưa tìm hiểu hết được các loại thẻ security như WS-trust… mới chỉ dừng lại ở web service secrutiy policy. Và tích hợp với công cụ Web service enhancement. Nếu có điều kiện, trong tương lai tôi sẽ cố gắng tìm hiểu thêm về những mặt hạn chế của luận văn và cố gắng khắc phục để tạo ra một chương trình hoàn chỉnh và có thể áp dụng vào thực trạng ngành kinh doanh chứng khoán hiện nay. [70] Phụ lục Loose couping Tài liệu tham khảo Tiếng việt: 1. Bộ tài chính (2007), Quyết định 27/2007/QĐ-BTC về việc ban hành Quy chế tổ chức và hoạt động công ty chứng khoán. [7] 2. Vũ Đình Cường (2008), Tìm Hiểu Các Kiểu Tấn Công Cơ Bản & Phương Pháp Phòng Chống, Nhà xuất bản Lao động - Xã hội [7]. [8] 3. Thái Hồng Nhị, Phạm Minh Việt (2004), An toàn thông tin, Nhà xuất bản Khoa học và Kỹ thuật. [8] Tiếng anh 1. Microsoft (2008), Web Service Security Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0, Microsoft Hill. 2. July 2005 (Version 1.1), ws-securitypolicy. 3. Microsoft , Web Service Security, Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0 4. WS-Security 2004, Web Services Security, SOAP Message Security 1.0 5. OASIS Standard Specification, 1 February 2006, Web Services Security Kerberos Token Profile.