Luận văn Tốt nghiệp công nghệ .net remoting - Ứng dụng quản lý khách hàng

Webservice, có thể sử dụng cùng kỹ thuật sử dụng với các trang ASP.NET (sử dụng kho thuộc tính Phiên (session) và kho thuộc tính Ứng dụng (application)), hoặc tùy biến một quá trình thích hợp. .NET Remoting hỗ trợ nhiều lựa chọn về quản lý trạng thái. Các đối tượng được chứa trong tiến trình chủ được phân thành 3 loại: Các đối tượng SingleCall không lưu thông tin trạng thái – chúng giống với các đối tượng được sử dụng bởi Webservice. Mỗi khi một tiến trình khách thực hiện gọi hàm, tiến trình chủ lại tạo ra một đối tượng SingleCall để đáp ứng lời gọi hàm đó. Đối tượng này bị hủy khi quá trình gọi hàm kết thúc. Các đối tượng Singleton được tạo ra 1 lần bởi tiến trình chủ và dùng chung cho mọi tiến trình khách. Đối tượng Singleton sẽ lưu lại trạng thái chung cho tất cả các tiến trình khách (tiến trình khách nào khi truy cập vào đối tượng loại này đều có thể sửa các thông tin thuộc tính mà một tiến trình trước đã lưu lại). Cuối cùng là các đối tượng có thể được khởi tạo bởi tiến trình khách. Đối với các đối tượng này, chu trình sống được quản lý bởi tiến trình khách, mặc dù chúng “sống” trong tiến trình chủ. Mỗi tiến trình khách có thể tạo ra một đối tượng kiểu này trên tiến trình chủ, lưu lại các trạng thái giữa các lời gọi hàm tới đối tượng đó qua các thuộc tính và chủ động hủy đối tượng khi không cần sử dụng nữa. Hiệu suất hoạt động Trong các cấu hình kết nối, .NET Remoting cho tốc độ kết nối cao nhất khi sử dụng khuôn dạng nhị phân truyền trên kênh TCP. Tuy nhiên, khi sử dụng khuôn dạng SOAP cho các bản tin, .NET Remoting tỏ ra thua kém ASP.NET Webservice về tốc độ, dù sử dụng kênh TCP hay HTTP. Khi sử dụng khuôn dạng nhị phân trên kênh HTTP, .NET Remoting cho hiệu suất tương đương với ASP.NET Webservice. Bảng 31 tổng hợp các khác biệt giữa .NET Remoting và Webservice. .NET Remoting Webservice Có thể duy trì hoặc không duy trì trạng thái của đối tượng giữa các lời gọi hàm. Tất cả các lời gọi hàm đều không duy trì trạng thái Không cần IIS (có thể dùng IIS với kênh HTTP để sử dụng các tính năng an toàn) Phải có IIS cài đặt trên máy chủ. Hỗ trợ tất cả các kiểu biến Chỉ hỗ trợ một số kiểu cơ bản Có thể truyền tham số là đối tượng theo kiểu tham biến hoặc tham trị Không hỗ trợ truyền tham số là đối tượng Hỗ trợ một kiến trúc truyền dẫn có thể mở rộng được Chỉ có thể truyền sử dụng XML trên giao thức HTTP Có thể thêm vào các lớp để tùy biến các bản tin gửi đi Không thể tùy biến các bản tin Giao thức SOAP bị giới hạn và chỉ có thể dùng kiểu mã hóa RPC Giao thức SOAP có thể sử dụng kiểu mã hóa kiểu RPC hoặc văn bản. Phụ thuộc chặt chẽ về kiến trúc giữa hệ thống khách và chủ Phụ thuộc lỏng về kiến trúc giữa hệ thống khách và chủ Bảng 31 : So sánh .NET Remoting và Webservice Khuyến nghị sử dụng Khi xây dựng ứng dụng phân tán trên nền .NET, có thể sử dụng các nguyên tắc sau đây để lựa chọn phương thức giao tiếp giữa các thành phần phân tán. Thứ nhất, ASP.NET Webservice là lựa chọn đầu tiên. Các webservice có thể sử dụng và triển khai một cách dễ dàng. Khi một dịch vụ được cung cấp dưới dạng Webservice, khả năng kết nối từ các máy trạm sử dụng các nền khác nhau là lớn nhất. Nếu cần xây dựng một mô hình phân tán với các tính năng lập trình mạnh hơn, đồng thời không cần tính đến giao tiếp với các ứng dụng trên nền khác Windows, .NET Remoting là một lựa chọn thích hợp. Nếu sử dụng .NET Remoting, cấu trúc giao tiếp ưu tiên số 1 là kênh HTTP (HTTP Channel – xem thêm phần 3.4 : .NET Remoting) tích hợp với IIS và ASP.NET. Nếu không dùng phương án này, cần phát triển một kiến trúc bảo mật riêng cho chương trình. Do cả máy trạm và máy chủ đều sử dụng .NET, nên sử dụng khuôn dạng nhị phân (binary formatter – xem thêm phần 3.4 : .NET Remoting) thay cho khuôn dạng SOAP. Khi đó hiệu suất sẽ tăng lên đáng kể. Nếu như hệ thống đòi hỏi yêu cầu cao về hiệu năng, có thể sử dụng .NET Remoting với kênh TCP. Sự kết hợp này cho hiệu quả tốt nhất về mặt tốc độ. Tuy nhiên, như đã đề cập ở trên, với phương án này cần phát triển một kiến trúc bảo mật riêng cho chương trình. Trong phần Phụ lục 1 : Xây dựng kênh truyền an toàn cho giao tiếp .NET Remoting sẽ đề cập tới việc xây dựng một kênh truyền bảo mật giữa máy chủ và máy trạm trong một kết nối .NET Remoting. .NET Remoting Trong cấu trúc giao tiếp của .NET Remoting, tiến trình trạm không giao tiếp trực tiếp với đối tượng trên tiến trình chủ mà giao tiếp với một đối tượng đại diện (để đơn giản, thuật ngữ proxy sẽ được sử dụng để đề cập tới đối tượng đại diện). Proxy là một đối tượng, được kích hoạt và chạy trên tiến trình khách, có giao diện giống hệt với giao diện của đối tượng thực trên tiến trình chủ mà nó đại diện. Khi cần gọi các hàm trên đối tượng thực sự trên tiến trình chủ, tiến trình khách sẽ thực hiện gọi tới đối tượng proxy. Proxy sẽ có nhiệm vụ chuyển các lời gọi đó tới đối tượng thực sự chứa trên tiến trình chủ, sau đó trả về các kết quả cho tiến trình khách. Như biểu diễn trên Hình 35, lời gọi hàm từ tiến trình khách sẽ được truyền từ Proxy qua kênh giao tiếp trước khi đến được đối tượng trên tiến trình chủ. Trong kênh giao tiếp, lời gọi hàm sẽ được truyền qua nhiều lớp. Các lớp này có thể được nhìn nhận như là các lớp trong mô hình phân lớp OSI. Mỗi lớp truyền đi các bản tin cho lớp tương ứng ở đầu bên kia bằng cách ghi vào luồng dữ liệu truyền qua nó. Một ví dụ là quá trình mã hóa và giải mã dữ liệu. Nếu đặt mô hình này vào trong mô hình phân lớp OSI, có thể thấy rằng toàn bộ kênh giao tiếp sẽ nằm từ tầng thứ 4 - tầng giao vận trở lên trên. Chú ý rằng các thuật ngữ sử dụng cho mỗi lớp, cũng như chức năng của mỗi lớp ở đây và trong mô hình OSI không hoàn toàn giống nhau. Điểm quan trọng mà mô hình OSI đưa ra là sự phân lớp và giao tiếp giữa các lớp cùng mức, chứ không phải là ở quy định về chức năng cụ thể cũng như tên gọi của mỗi lớp. Chính vì vậy mà các mô hình phân lớp mà các nhà sản xuất khác nhau đưa ra không hoàn toàn giống nhau về số lớp, tên gọi lớp hay chức năng mà mỗi lớp thực hiện. Kênh giao tiếp và giao thức: Trên Hình 35, kênh giao tiếp bao gồm toàn bộ các lớp bên dưới, phục vụ cho quá trình giao tiếp giữa các thành phần ứng dụng. Khái niệm kênh giao tiếp như vậy bao gồm cả các lớp thực hiện định dạng bản tin, các lớp tùy biến do người dùng tự phát triển và giao thức sử dụng. Người dùng có thể thực hiện tùy biến đối với kênh giao tiếp thông qua các lớp tùy biến, chứ không thể thực hiện tùy biến đối với giao thức. .NET Remoting hỗ trợ 1 trong các loại kênh giao tiếp: TcpChannel HttpChannel Kênh giao tiếp TcpChannel sử dụng lớp định dạng nhị phân hoặc định dạng SOAP để định dạng các bản tin trước khi truyền tới đích sử dụng giao thức TCP. Kênh giao tiếp TcpChannel thực hiện các chức năng sau: Thực hiện giao tiếp giữa bên gửi và bên nhận sử dụng các socket TCP. Thực hiện định dạng nhị phân hoặc SOAP đối với các bản tin. Kênh giao tiếp HttpChannel sử dụng lớp định dạng nhị phân hoặc định dạng SOAP để định dạng các bản tin trước khi truyền tới đích sử dụng giao thức HTTP. Đối với định dạng SOAP, các bản tin được chuyển thành XML, thêm vào một số các header của giao thức SOAP trước khi truyền đi. Kênh giao tiếp HttpChannel thực hiện các chức năng sau: Thực hiện giao tiếp giữa bên gửi và bên nhận sử dụng các yêu cầu (request) và đáp ứng (response) HTTP. Thực hiện định dạng nhị phân hoặc SOAP đối với các bản tin. Có thể nhận thấy rằng tổ hợp định dạng nhị phân và giao thức truyền TCP tạo nên một kênh giao tiếp cho hiệu suất tốc độ cao nhất. Tiến trình chủ Kênh giao tiếp Khách Proxy Lớp định dạng Lớp tùy biến Lớp giao vận Đối tượng Lớp định dạng Lớp tùy biến Lớp giao vận TCP, HTTP Hình 35: Cấu trúc giao tiếp giữa tiến trình khách và tiến trình chủ trong .NET Remoting Lớp giao vận (Transport Sink) Lớp này được gắn vào giao thức truyền dữ liệu cụ thể và không thể thực hiện tùy biến. Chẳng hạn, khi sử dụng giao thức HTTP, lớp giao vận sử dụng sẽ là lớp giao vận tương ứng với HTTP. Người lập trình không thể thực hiện tùy biến đối với lớp giao vận. Lớp định dạng (Formatter Sink) Quyết định khuôn dạng của các bản tin truyền đi. Binary Formatter :Truyền trực tiếp các lời gọi hàm mà không qua biến đổi nào. Phương thức này cho hiệu quả tốc độ tốt nhất. SOAP Formatter: Chuyển các lời gọi hàm và các giá trị trả về thành các tin nhắn SOAP dưới dạng XML. Các lớp tùy biến (Custom sinks) Người lập trình có thể tự phát triển các lớp tùy biến để thực hiện một công việc nào đó, chẳng hạn như mã hóa – giải mã. Trong ứng dụng Quản lý yêu cầu khách hàng, chúng ta sẽ thực hiện 2 lớp như vậy. Lớp thứ nhất thực hiện đồng bộ thông tin người dùng hiện tại giữa tiến trình khách và tiến trình chủ. Lớp thứ hai, ở mức thấp hơn, thực hiện việc mã hóa và giải mã luồng dữ liệu truyền trên kênh nhằm mục đích bảo mật. Web service Một web service là một thực thể cung cấp một dịch vụ, ví dụ như xử lý logic. Webservice có thể được truy cập bởi các hệ thống khác nhau sử dụng các chuẩn Internet như XML và HTTP. Webservice có thể được sử dụng nội bộ trong một ứng dụng hoặc cung cấp ra bên ngoài qua Internet. Webservice cung cấp giải pháp cho phép tích hợp ứng dụng và dữ liệu. Nó sử dụng cơ chế trao đổi tin nhắn dựa trên XML, nhờ vậy cho phép kết nối các hệ thống trên các hệ điều hành khác nhau, với các ngôn ngữ lập trình khác nhau. Cơ chế trao đổi tin nhắn này cũng cho phép cả 2 đầu sử dụng và cung cấp webservice không cần biết thông tin nào khác về đối tác ngoài các thông tin về đầu vào, đầu ra và địa chỉ của webservice. Các ứng dụng của Webservice Cung cấp dịch vụ Trường hợp phổ biến nhất là webservice cung cấp một tính năng cho các đầu cuối. Ví dụ, việc tính chi phí vận chuyển là một chức năng phổ biến trong một ứng dụng thương mại điện tử. Một chức năng như vậy thường cần thông tin chi phí cập nhật thường xuyên từ các nhà cung cấp dịch vụ vận chuyển để sử dụng trong phép tính. Thay vào đó, nếu nhà cung cấp dịch vụ sử dụng Webservice, ứng dụng chỉ cần gửi một bản tin XML qua Internet tới Webservice đó. Tin nhắn này cung cấp khối lượng và kích thước của gói hàng, địa chỉ gửi – nhận và các thông số khác (như loại hàng). Webservice sẽ tính toán chi phí chuyển hàng sử dụng thông tin cước phí của họ, và trả về thông tin này trong một bản tin trả lời tới cho ứng dụng. Tích hợp ứng dụng Webservice có thể sử dụng để tích hợp các ứng dụng có các đặc điểm rất khác biệt với nhau. Trong môi trường các doanh nghiệp lớn, thường có rất nhiều các ứng dụng triển khai ở hầu khắp các phòng ban. Các ứng dụng này thường bị ngăn cách với nhau cả về mặt dữ liệu và logic. Sử dụng Webservice, mỗi ứng dụng như vậy có thể cung cấp các giao diện cho các ứng dụng khác trên các plattform khác sử dụng. Giải pháp cho thương mại điện tử Webservice là nền tảng cho một cơ cấu cho phép các ứng dụng có thể tích hợp với nhau, trở thành các giải pháp tổng thể cho các giao dịch thương mại điện tử. Cơ sở hạ tầng của Webservice Các đặc điểm của Webservice Không tạo ràng buộc chặt chẽ giữa các hệ thống. Hai hệ thống tích hợp qua Webservice chỉ có ràng buộc duy nhất là hiểu được các bản tin XML. Các phương thức tích hợp khác đòi hỏi trao đổi một khối lượng thông tin lớn hơn, cũng như đòi hỏi hệ thống này phải có những thông tin nhất định về hệ thống kia. Phổ dụng. Các hệ điều hành đã, đang và sẽ đều phải có khả năng kết nối với Internet. Webservice cung cấp khả năng kết nối hầu như tất cả các hệ thống có kết nối qua Internet. Khuôn dạng chuẩn hóa. Webservice sử dụng các tiêu chuẩn phổ biến và mở, nhờ vậy bất kỳ hệ thống nào có hỗ trợ các chuẩn này đều có thể hiểu được Webservice. Cơ sở hạ tầng của Webservice được biểu diễn trên Hình 36. Trả về kết quả Webservice Máy trạm gọi Webservice Trả về tài liệu mô tả Webservice Máy trạm yêu cầu mô tả Webservice Trả về tài liệu khám phá Webservice Máy trạm yêu cầu tài liệu khám phá Webservice Trả về URL tới tài liệu khám phá Webservice Máy trạm tìm kiếm vị trí của Webservice Sử dụng Webservice UDDI Webservice Thư mục Khám phá Mô tả Giao tiếp Hình 36 : Kiến trúc hạ tầng của Webservice Trên Hình 36, kiến trúc thành phần của Webservice bao gồm 4 thành phần Các thư mục Webservice Cũng giống như các tài nguyên khác trên Internet, Webservice cũng cần có một cơ chế để cho phép thực hiện tìm kiếm đối với chúng. Các thư mục Webservice cung cấp một nơi tập trung thông tin về các Webservice cung cấp bởi các tổ chức hoặc doanh nghiệp. Một thư mục như vậy cũng có thể là một Webservice, có thể được truy cập và cung cấp kết quả tìm kiếm cho các yêu cầu từ các khách hàng. UDDI (Universal Description, Discovery, and Integration) là một tiêu chuẩn định nghĩa cách thức công bố và khai thác thông tin về Webservice. Một máy trạm sử dụng Webservice có thể cần hoặc không cần tới một thư mục webservice. Khám phá Webservice Đây là quá trình định vị các tài liệu mô tả một Webservice sử dụng ngôn ngữ mô tả Webservice (WSDL - Web Services Description Language). Nếu một khách hàng của Webservice đã biết vị trí của các tài liệu này, nó có thể bỏ qua quá trình này. Mô tả Webservice Để biết cách giao tiếp với một Webservice cụ thể, khách hàng cần đến một mô tả trong đó định nghĩa các giao tiếp mà Webservice đó hỗ trợ. Các khuôn dạng sử dụng trong giao tiếp Để có thể thực hiện giao tiếp rộng rãi, Webservice sử dụng các khuôn dạng mở. Đây là những giao thức có thể hiểu được bởi bất kỳ hệ thống nào hỗ trợ các tiêu chuẩn Web chuẩn. SOAP là một giao thức đóng vai trò quan trọng trong giao tiếp Webservice. Hoạt động của Webservice Quá trình gọi một Webservice tương tự như quá trình gọi một hàm bình thường. Sự khác biệt cơ bản là thay vì gọi một hàm nằm trong bản thân ứng dụng, lời gọi Webservice sẽ tạo ra một bản tin yêu cầu dựa trên một giao thức nào đó, chẳng hạn HTTP. Webservice có thể nằm trên một máy khác với máy đang thực hiện gọi, vì vậy thông tin mà Webservice cần để xử lý bản tin yêu cầu này cũng được truyền qua mạng tới máy chủ chạy Webservice. Webservice sau đó xử lý các thông tin và gửi kết quả trở về qua mạng tới ứng dụng khách đã yêu cầu Webservice. Hình 37 : Một chu trình hoạt động của Webservice Thứ tự các sự kiện xảy ra khi một Webservice được gọi bao gồm: Ứng dụng khách tạo ra một đối tượng proxy của Webservice tương ứng. Đối tượng này nằm trên cùng một máy với ứng dụng khách. Ứng dụng khách gọi một hàm của đối tượng proxy, truyền vào các tham số cần thiết cho Webservice. Hàm này sẽ tương ứng với một hàm trên Webservice. Hệ thống cơ sở hạ tầng của Webservice (mô tả trong phần 3.5.2) sẽ thực hiện chuyển các tham số tới Webservice vào trong một bản tin SOAP và gửi bản tin này qua mạng tới Webservice. Ở đầu bên kia (máy chủ Webservice), hệ thống hạ tầng Webservice sẽ thực hiện lấy ra các thông tin về lời gọi hàm từ bản tin SOAP, sau đó tạo ra một đối tượng Webservice và gọi hàm của Webservice, truyền vào các tham số đã lấy ra từ bản tin SOAP. Webservice chạy hàm của nó, trả về kết quả. Hệ thống hạ tầng Webservice trên máy chủ chuyển các kết quả trả về và các tham số đầu ra vào trong một bản tin SOAP và gửi trả về ứng dụng khách. Hệ thống hạ tầng trên ứng dụng khách nhận bản tin SOAP, lấy ra các kết quả trả về và truyền cho đối tượng proxy. Ứng dụng khách nhận được các kết quả trả về. An toàn hệ thống Kiến trúc phân tán mang lại nhiều ưu điểm. Tuy nhiên, kiến trúc này cũng làm nảy sinh nhiều vấn đề cần giải quyết. An toàn hệ thống vốn là một vấn đề rất quan trọng trong các hệ thống công nghệ thông tin. Đối với kiến trúc phân tán, khi các thành phần ứng dụng có thể ở cách xa nhau và kết nối với nhau qua môi trường mạng, vấn đề này lại càng cần được quan tâm. Phần này sẽ đề cập đến các vấn đề liên quan đến việc bảo đảm an toàn hệ thống ứng dụng phân tán sử dụng .NET. Các nguy cơ gây mất an toàn cho hệ thống Các nguy cơ gây mất an toàn cho hệ thống phổ biến bao gồm: Giả mạo người dùng: Xảy ra khi một kẻ tấn công lấy được các thông tin nhận thực và giả mạo một người dùng hợp lệ. Ví dụ, mật khẩu được truyền đi mà không sử dụng phương thức mã hóa thích hợp có thể bị lấy trộm bởi hacker, sau đó bị sử dụng để đăng nhập vào hệ thống. Phá hoại dữ liệu trên đường truyền: Nguy cơ này xảy ra với các ứng dụng phân tán, khi có dữ liệu truyền trên đường truyền giữa các thành phần của ứng dụng. Một cuộc tấn công như vậy sẽ làm thay đổi hoặc phá hoại dữ liệu trên đường truyền. Chối bỏ trách nhiệm: Khả năng người dùng có thể chối bỏ trách nhiệm sau khi đã thực hiện một hành vi nào đó với hệ thống. Lộ thông tin: Dữ liệu nhạy cảm bị lộ cho những người dùng hoặc thiết bị không có quyền truy cập. Tấn công từ chối dịch vụ: Sự phá hoại khiến cho hệ thống không hoạt động được. Tấn công từ chối dịch vụ xảy ra khi hệ thống bị ngập trong việc xử lý các yêu cầu phá hoại gửi tới và tới mức không thể xử lý được các yêu cầu từ các người dùng hợp lệ. Kiểu tấn công từ chối dịch vụ cơ bản nhất là tấn công vào máy chủ đang sử dụng để chạy ứng dụng. Như vậy, việc chống tấn công từ chối dịch vụ phải được thực hiện ở mức hệ thống, chứ không phải từ mức ứng dụng. Nâng quyền sử dụng: một người dùng tìm cách lấy được các quyền cao hơn mức cho phép dành cho mình. Chẳng hạn một người dùng bình thường tìm cách lấy được quyền quản trị hệ thống một cách bất hợp pháp. Các kỹ thuật sau đây thường được sử dụng để giảm thiểu các nguy cơ mất an toàn hệ thống: Nhận thực: quá trình nhận thực sẽ giúp giảm thiểu nguy cơ giả mạo người dùng. Khi đăng nhập vào chương trình, người sử dụng nhập vào tên người dùng và mật khẩu. Các thông tin nhận thực này cần phải được mã hóa trước khi kiểm tra đối chiếu với thông tin đã lưu trữ. Kiểm tra quyền: Nếu như quá trình nhận thực thường chỉ xảy ra 1 lần khi người dùng đăng nhập vào hệ thống, quá trình kiểm tra quyền lại được tiến hành với mọi hoạt động của người sử dụng. Quá trình này giúp ngăn chặn nguy cơ lộ thông tin nhạy cảm. Ghi nhật ký: Ghi lại các thông tin về các hành động của người sử dụng sẽ giúp giảm thiểu việc chối bỏ trách nhiệm. Trong trường hợp này cần lựa chọn các thao tác quan trọng. Cắt giảm tốc độ truy cập vào hệ thống là một trong các phương pháp làm giảm nguy cơ tấn công từ chối dịch vụ. Phương pháp này thường được sử dụng với các website. Một phương pháp khác được thực hiện là sử dụng tường lửa để lọc các gói tin phá hoại. Mã hóa bảo mật thông tin trên đường truyền: Mã hóa thông tin truyền đi sẽ giúp chống lại được các nguy cơ: giả mạo người dùng (để lộ thông tin nhận thực), xem trộm hoặc phá hoại dữ liệu. Có thể thấy rằng ở mức ứng dụng, an toàn hệ thống phụ thuộc rất nhiều vào cơ chế nhận thực, kiểm tra quyền và việc mã hóa dữ liệu trên đường truyền. Trong phần sau trình bày chi tiết hơn về các biện pháp này. Nhận thực Quá trình nhận thực bao gồm các quá trình sau Chương trình thu thập các thông tin nhận thực của người dùng (tên người dùng, mật khẩu). Chương trình đối chiếu thông tin nhận thực với thông tin lưu trong cơ sở dữ liệu. Nếu thông tin hợp lệ, chương trình xác định tất cả các quyền của người dùng. Các thông tin về quyền này sẽ được sử dụng trong quá trình kiểm tra quyền – tiến hành suốt trong quá trình người sử dụng thực hiện các thao tác với chương trình. Nói cách khác, mã chương trình sẽ được thực hiện dưới ngữ cảnh an ninh tương ứng với người dùng đã đăng nhập. Ngữ cảnh an ninh: Tất cả các đoạn mã chương trình đều được chạy với một tập các thông tin về quyền. Tổng hợp các thông tin về quyền này tạo thành ngữ cảnh an ninh của chương trình. Một trong các thông tin về quyền này là các thông tin về danh sách các vai trò (role) của người dùng hiện tại. Các vai trò này sẽ quyết định việc người dùng có được chạy một đoạn mã nào đó trong chương trình hay không. Có thể thấy rằng quá trình nhận thực tương đối đơn giản. Điểm cần lưu ý nằm ở bước 2 của quá trình nhận thực. Ở bước này, thông tin nhận thực của người dùng chỉ được phép truyền đi sau khi đã được mã hóa để đảm bảo an toàn. Kiểm tra quyền Bước thứ 3 của quá trình nhận thực sẽ xây dựng ngữ cảnh an ninh của chương trình. Toàn bộ quá trình kiểm tra quyền sẽ được thực hiện dựa trên ngữ cảnh an ninh này. Các đặc điểm của việc kiểm tra quyền trên môi trường ứng dụng phân tán Khác biệt lớn nhất của ứng dụng phân tán so với ứng dụng tập trung là logic của chương trình được chạy ở nhiều nơi: Phần điều khiển giao diện chạy trên máy trạm. Mỗi máy trạm do một người dùng sử dụng với các quyền truy cập khác nhau. Phần xử lý nghiệp vụ- phần lớn logic của chương trình chạy trên một hoặc thậm chí nhiều máy chủ, phục vụ cho tất cả các máy trạm. Phần kiểm tra quyền truy cập nói chung phải thực hiện trên tất cả các phần của ứng dụng. Sau khi thực hiện đăng nhập, ngữ cảnh an ninh được xây dựng cho phần điều khiển giao diện trên mỗi máy trạm (vì mỗi máy trạm này tương ứng với một người sử dụng). Như vậy khi được gọi từ phần điều khiển giao diện, phần xử lý nghiệp vụ sẽ phải có được thông tin về ngữ cảnh an ninh của phần giao diện.. Giải pháp cho vấn đề kiểm tra quyền trong môi trường phân tán Có một số giải pháp cho vấn đề này: Truyền thông tin nhận thực của người sử dụng trong mỗi lời gọi hàm. Truyền thông tin về ngữ cảnh an ninh của người sử dụng trong mỗi lời gọi hàm. Đồng bộ ngữ cảnh an ninh của tiến trình chủ và khách trong mỗi lời gọi hàm. Quá trình này cần trong suốt đối với lời gọi hàm. Giải pháp thứ nhất khá phức tạp trong cả việc thực hiện và bảo dưỡng. Trong giải pháp này, thực chất, quá trình nhận thực sẽ được thực hiện lại bởi phần xử lý nghiệp vụ trong mỗi lần gọi hàm. Đối với các trường hợp mà việc nhận thực gây ra các chi phí về tốc độ và tài nguyên, phương pháp này là không phù hợp. Phương pháp thứ hai không thực hiện lại quá trình nhận thực. Thay vào đó, thông tin về ngữ cảnh an ninh sau khi đã được xây dựng ở phần giao diện, sẽ được truyền cho phần xử lý nghiệp vụ. Tuy nhiên, việc thêm thông tin này vào các tham số của các hàm sẽ khiến cho việc phát triển và bảo trì chương trình trở nên phức tạp. Với cách thứ ba, ngữ cảnh an ninh được đồng bộ giữa phần xử lý giao diện và phần xử lý nghiệp vụ mà không ảnh hưởng tới các lời gọi hàm. Với phương pháp này, các lời gọi hàm không phải thay đổi để truyền thêm thông tin an ninh. Giải pháp này là một phần trong quá trình xây dựng kênh truyền an toàn, được trình bày trong Phụ lục 1 : Xây dựng kênh truyền an toàn cho giao tiếp .NET Remoting. Mã hóa dữ liệu trên kênh truyền Các biện pháp bảo đảm an toàn với .NET Remoting Tiến trình chủ Kênh giao tiếp Khách Proxy Lớp định dạng Lớp tùy biến Lớp giao vận Đối tượng Lớp định dạng Lớp tùy biến Lớp giao vận TCP, HTTP Hình trên là bản sao của Hình 35: Cấu trúc giao tiếp giữa tiến trình khách và tiến trình chủ trong .NET Remoting. Tiến trình khách kết nối với một đối tượng proxy. Các thông tin nhận thực (tên người dùng, mật khẩu…) có thể được thiết lập thông qua đối tượng proxy này. Lời gọi hàm được truyền từ đối tượng proxy, qua một chuỗi các lớp tới máy chủ. Tại máy chủ, quá trình diễn ra ngược lại. Chi tiết về khái niệm lớp cũng như kênh truyền được trình bày tại mục 3.4. Khả năng hỗ trợ quá trình nhận thực, kiểm tra quyền và mã hóa kênh truyền khác nhau đối với mỗi loại kênh truyền. Bảng sau tổng hợp so sánh khả năng hỗ trợ các biện pháp an toàn mà mỗi kênh truyền cung cấp: Tính năng Kênh TCP Kênh HTTP Nhận thực Không Có Kiểm tra quyền Không Có Mã hóa bảo mật Có Có Bảng 32 : So sánh kênh TCP và kênh HTTP Kênh HTTP sử dụng các tính năng nhận thực và kiểm tra quyền cung cấp bởi IIS và ASP.NET. Trong khi đó kênh TCP không cung cấp bất kỳ tính năng hỗ trợ nhận thực hay kiểm tra quyền nào. Về mặt mã hóa kênh truyền, với kênh TCP có thể sử dụng IPSec. Với kênh HTTP, ngoài IPSec có thể sử dụng SSL. Như vậy, với các ưu thế về tốc độ, hỗ trợ về các tính năng đảm bảo an toàn của kênh TCP hầu như không có gì. Một giải pháp cho phép sử dụng được ưu thế về tốc độ của kênh TCP, đồng thời cung cấp khả năng nhận thực, kiểm tra quyền và mã hóa, đó là xây dựng một kênh truyền an toàn. Client Proxy Object Client App Domain Server App Domain Kênh truyền an toàn Hình 38 : Kênh truyền an toàn cho .NET Remoting Chi tiết về kênh truyền an toàn được trình bày trong Phụ lục 1 : Xây dựng kênh truyền an toàn cho giao tiếp .NET Remoting. Giải pháp này có thể sử dụng với bất kỳ giải pháp .NET Remoting, dù sử dụng kênh HTTP, TCP hay loại kênh truyền nào khác. Các biện pháp bảo đảm an toàn với Webservice Các phương pháp bảo đảm an toàn với Webservice có thể thực hiện ở một trong 3 mức Mức giao vận (điểm tới điểm) Mức ứng dụng Mức bản tin (trong từng bản tin truyền đi) Mỗi phương pháp tiếp cận có ưu điểm và nhược điểm riêng. Chi tiết về các phương pháp và khuyến nghị sử dụng cho mỗi phương pháp được trình bày ở phần sau. An toàn mức giao vận (điểm - điểm) Tầng giao vận giữa trình khách của Webservice và Webservice có thể là nơi áp dụng các biện pháp bảo đảm an toàn mức điểm – điểm. Giao vận Khách Giao vận Webservice XML Kênh an toàn XML Khi máy khách yêu cầu một Webservice, các sự kiện sau lần lượt xảy ra Máy chủ nhận được yêu cầu dưới dạng một bản tin SOAP. IIS thực hiện nhận thực cho máy khách sử dụng các phương pháp nhận thực hỗ trợ bởi IIS. IIS cũng có thể được cấu hình để chỉ nhận các yêu cầu từ các máy có địa chỉ IP định trước. IIS truyền thẻ truy cập của máy khách cho ASP.NET. ASP.NET nhận thực máy khách. ASP.NET thực hiện kiểm tra quyền truy cập tới Webservice (file .asmx) dựa trên URL hoặc dựa tren quyền NTFS (kiểm tra quyền truy nhập file dựa trên NTFS chỉ hỗ trợ trong môi trường Windows). Mã trong Webservice có thể truy cập các tài nguyên. Mô hình này khá đơn giản, dễ hiểu, có thể áp dụng cho các ứng dụng chạy trên mạng LAN. Một số nhược điểm của mô hình này: Cơ chế bảo mật bị phụ thuộc chặt chẽ vào nền Windows. Cơ chế bảo mật được áp dụng trên cơ sở kết nối điểm – điểm, không thích hợp khi truyền qua nhiều chặng. An toàn mức ứng dụng Trong cách tiếp cận này, chương trình sẽ tự đảm nhận các tính năng bảo đảm an toàn. Ví dụ: Sử dụng header trong bản tin SOAP để truyền thông tin xác nhận người dùng để thực hiện nhận thực trong mỗi yêu cầu tới Webservice. Ứng dụng tự tạo ra một đối tượng IPrincipal để thực hiện phân quyền theo role. Ứng dụng có thể thực hiện mã hóa các thông tin cần thiết. Một kỹ thuật khác có thể sử dụng là sử dụng SSL để mã hóa dữ liệu, kết hợp với sử dụng SOAP header để truyền thông tin nhận thực. Sử dụng cách tiếp cận này khi: Cần dùng một cơ sở dữ liệu lưu thông tin về người dùng và quyền. Cần mã hóa một phần của các bản tin truyền đi, thay vì toàn bộ luông dữ liệu truyền đi. An toàn ở mức bản tin Đây là cách tiếp cận mềm dẻo và cho khả năng bảo vệ mạnh nhất: Quá trình nhận thực được thực hiện nhờ các thẻ nhận thực, truyền trong các header của các bản tin SOAP. Chữ ký điện tử được sử dụng để đảm bảo rằng bản tin đã không bị thay đổi và mã hóa XML được sử dụng để mã hóa bảo mật bản tin. Phương pháp này phù hợp để xây dựng một kiến trúc cho phép trao đổi các bản tin trong môi trường nhiều plattform. Các ưu điểm của phương pháp này bao gồm: Không phụ thuộc vào phương thức truyền sử dụng bởi tầng giao vận. Cho phép xây dựng kiến trúc bảo mật trong môi trường nhiều plattform. Cho phép truyền bản tin qua nhiều nút. Hỗ trợ các kỹ thuật mã hóa khác nhau. Áp dụng kết quả Hệ thống quản lý yêu cầu khách hàng tại Bưu điện Hà Nội Giới thiệu Bưu điện Hà Nội là một bưu điện lớn với nhiều điểm giao dịch. Trong vài năm trở lại đây, số lượng khách hàng sử dụng các dịch vụ viễn thông ngày càng tăng, các loại hình dịch vụ viễn thông cũng không ngừng phát triển. Bên cạnh đó, cạnh tranh trên thị trường cũng đòi hỏi không ngừng nâng cao chất lượng phục vụ khách hàng. Trong hoàn cảnh đó, việc áp dụng các ứng dụng công nghệ thông tin nhằm quản lý và tự động hóa quá trình tiếp nhận và xử lý yêu cầu khách hàng là rất cần thiết. Hệ thống Quản lý yêu cầu khách hàng hiện tại của Bưu điện Hà Nội được viết bằng Foxpro for DOS. Hiện chương trình vẫn đáp ứng được các yêu cầu của việc quản lý tiếp nhận và xử lý yêu cầu. Tuy nhiên, trong tương lai, khi các kênh thông tin tiếp nhận xử lý yêu cầu khách hàng được mở rộng qua các môi trường Web, CallCenter, hệ thống hiện tại có một số khó khăn: Không có khả năng tích hợp mức ứng dụng: Ứng dụng hiện tại dựa trên mô hình file server, vì vậy việc tích hợp với các ứng dụng khác chỉ có thể thực hiện qua việc chia sẻ file, tức là ở mức cơ sở dữ liệu. Không có khả năng mở rộng: Việc phát triển thêm các module phục vụ chăm sóc khách hàng qua CallCenter hoặc qua Web gặp rất nhiều khó khăn khi không sử dụng lại được các mã của chương trình quản lý giao dịch trực tiếp. Giao diện DOS không thân thiện. Không hỗ trợ Unicode. Để giải quyết dứt điểm các vấn đề còn tồn tại kể trên, một hệ thống mới cần được phát triển. Công nghệ nền .NET được lựa chọn vì đáp ứng được các tiêu chí sau: Hỗ trợ hệ điều hành Windows, vốn là môi trường sử dụng quen thuộc của đa số các nhân viên Bưu điện Tỉnh. Bộ công cụ phát triển VisualStudio.NET với tính năng mạnh, cho phép phát triển ứng dụng trong thời gian ngắn. Hỗ trợ hoàn toàn Unicode. Cung cấp khả năng tích hợp và mở rộng ứng dụng mạnh mẽ với Webservice và .NET Remoting. Khả năng kết hợp linh hoạt giữa các kiến trúc Web, kiến trúc Smart Client với các ứng dụng COM truyền thống. Kiến trúc hệ thống Để xây dựng kiến trúc hệ thống, cần nắm rõ các thành phần của hệ thống và chức năng của mỗi thành phần, cũng như vị trí của hệ thống Quản lý yêu cầu khách hàng trong toàn bộ các chương trình hỗ trợ điều hành sản xuất kinh doanh của Bưu điện Tỉnh. Trong toàn bộ các chương trình hỗ trợ điều hành sản xuất kinh doanh của Bưu điện Tỉnh, hệ thống Quản lý yêu cầu khách hàng đóng vai trò đầu vào, là giao diện trực tiếp giữa Bưu điện và khách hàng. Vì vậy, đây cũng là một thành phần quan trọng của một hệ thống CRM cho Bưu điện Tỉnh. Như vậy hệ thống cần có 2 phần chính: Phần back-end: chương trình quản lý, nhập liệu sử dụng trực tiếp bởi các nhân viên giao dịch. Căn cứ vào các đặc điểm giao dịch khách hàng, có thể thấy phần này cần có giao diện thân thiện, dễ sử dụng và có tốc độ nhanh. Phần front-end: ứng dụng Web cung cấp các dịch vụ tự chăm sóc cho khách hàng. Phần này cần được mở rộng để trong tương lai có thể cho phép đăng ký dịch vụ qua mạng, thay vì giao dịch trực tiếp như hiện nay. Ngoài ra hệ thống cần có các giao tiếp với các chương trình khác như Chương trình quản lý mạng cáp, hệ thống CallCenter… Trên cơ sở đó, kiến trúc của hệ thống được xây dựng như trên Hình 41. Hệ thống QLYC Các hệ thống khác .NET Remoting Web services 1 2 3 Người dùng Web (browser) Nhân viên (Thick clients) Hình 41 : Kiến trúc hệ thống Quản lý yêu cầu khách hàng Các giao tiếp trên Hình 41 bao gồm: Giao tiếp .NET Remoting sử dụng kênh truyền an toàn, cho phép thực thiện giao tiếp tốc độ cao giữa phần giao diện người sử dụng back-end với máy chủ ứng dụng. Chi tiết về xây dựng kênh truyền an toàn có thể tham khảo trong Phụ lục 1 : Xây dựng kênh truyền an toàn cho giao tiếp .NET Remoting. Giao tiếp Webservice cho phép Tích hợp hệ thống với các hệ thống khác qua Internet hoặc mạng LAN. Mở rộng hệ thống thêm các module Web, triển khai trên các Web server, cho phép người dùng cuối (khách hàng) có thể tự chăm sóc và tiến tới đăng ký dịch vụ qua Web. Giao tiếp ODP.NET cho phép kết nối cơ sở dữ liệu Oracle. Trong trường hợp sử dụng hệ quản trị cơ sở dữ liệu khác, đây sẽ là kết nối tương ứng. Đánh giá Với tư cách là một hệ thống kiểm nghiệm cho các kết quả nghiên cứu plattform .NET Framework, quá trình phát triển hệ thống đã thể hiện các đặc điểm sau: Phần ứng dụng back-end (dùng cho nhân viên giao dịch) sử dụng .NET Remoting cho tốc độ hoạt động tốt. Triển khai chương trình dễ dàng, chỉ cần copy thư mục. Khả năng tích hợp tốt, thể hiện qua việc tích hợp với hệ thống báo cáo. Tốc độ phát triển nhanh và dễ dàng, nhờ khả năng hỗ trợ nhiều ngôn ngữ lập trình và bộ công cụ VisualStudio.NET. Hệ thống báo cáo từ xa Báo cáo là phần không thể thiếu trong các hệ thống hỗ trợ điều hành sản xuất kinh doanh. Mô hình truyền thống Mô hình truyền thống của hệ thống báo cáo được trình bày trên Hình 42. Trong mô hình này, một báo cáo được tạo ra từ thông tin định dạng báo cáo (chứa trong file định dạng) kết hợp với dữ liệu (từ cơ sở dữ liệu). Sự kết hợp và tạo ra báo cáo này được thực hiện bởi engine báo cáo. Đây là mô hình hoạt động phổ biến nhất của các giải pháp báo cáo hiện nay. Máy trạm CSDL Engine báo cáo Cấu trúc báo cáo Báo cáo Giao diện xem báo cáo Hình 42 : Mô hình báo cáo truyền thống Đặc điểm của mô hình này là engine báo cáo, nơi phụ trách việc lấy dữ liệu, trình bày dữ liệu và xuất ra báo cáo được triển khai ở máy trạm. Đây có thể coi là mô hình 2 lớp của báo cáo. Điều này dẫn tới một số nhược điểm tương tự với các nhược điểm của mô hình 2 lớp: Đòi hỏi cấu hình máy trạm cao. Phức tạp khi triển khai, do phải triển khai engine báo cáo tới từng máy trạm. Khả năng mở rộng hệ thống thấp. Engine báo cáo nằm ở máy trạm, cũng là điểm xem báo cáo của người dùng cuối. Đòi hỏi kết nối trực tiếp tới cơ sở dữ liệu khiến báo cáo thông thường không thể được mở rộng ra bên ngoài môi trường mạng LAN. Mô hình báo cáo từ xa sử dụng Webservice Mô hình báo cáo từ xa sử dụng Webservice được trình bày trên Hình 43. Trong mô hình này, engine báo cáo được chuyển lên máy chủ, và được máy chủ cung cấp giao diện ra bên ngoài thông qua Webservice. Hệ thốngkhác Máy chủ báo cáo Engine báo cáo Máy trạm Engine báo cáo Engine báo cáo Web service Máy chủ web Browser Window Form Web viewer Hình 43 : Mô hình báo cáo từ xa sử dụng Webservice Việc chuyển engine báo cáo lên máy chủ sẽ giải quyết các nhược điểm của mô hình truyền thống. Trong khi đó, việc sử dụng Webservice mở ra các khả năng: Sử dụng thống nhất báo cáo cho ứng dụng web và ứng dụng Smart Client. Ứng dụng Smart Client, cũng như máy chủ web có thể trực tiếp kết nối đến Webservice báo cáo để hiển thị báo cáo trên các form của ứng dụng Smart Client hoặc browser của ứng dụng web. Tích hợp dễ dàng hệ thống báo cáo tới các hệ thống khác thông qua môi trường Internet hoặc mạng LAN. Đánh giá Với tư cách là một hệ thống kiểm nghiệm cho các kết quả nghiên cứu plattform .NET Framework, quá trình nghiên cứu phát triển hệ thống báo cáo từ xa đã cho thấy: Khả năng tích hợp tốt, thể hiện qua việc tích hợp với hệ thống Quản lý yêu cầu khách hàng sử dụng giao diện Webservice. Tốc độ phát triển nhanh và dễ dàng, nhờ khả năng hỗ trợ nhiều ngôn ngữ lập trình và bộ công cụ VisualStudio.NET. Kết luận Trong vài năm trở lại đây, các ứng dụng công nghệ thông tin đã nhanh chóng phát triển để đáp ứng cho các nhu cầu quản lý của doanh nghiệp. Khái niệm về hệ thống quản trị nguồn lực doanh nghiệp (Enterprise Resource Planning - ERP) và hệ thống quản lý quan hệ khách hàng (Customer Relationship Management - CRM) đã trở thành những khái niệm quen thuộc. Các hệ thống ERP/CRM là các giải pháp tổng thể, hỗ trợ điều hành quản lý trên nhiều lĩnh vực của doanh nghiệp, giúp cho doanh nghiệp có thể phối hợp, tối ưu hóa mọi hoạt động của mình nhằm đem lại hiệu quả cao nhất. Những hệ thống có quy mô lớn như vậy đòi hỏi các giải pháp tích hợp ứng dụng ở mức cao, giữa nhiều công nghệ nền khác nhau. Đề tài này đã nghiên cứu và đưa ra các khuyến nghị cho việc xây dựng và tích hợp ứng dụng trên nền .NET, cung cấp nền tảng cho việc phát triển, tích hợp các module CRM/ERP trên Windows. Kết quả của đề tài đã được áp dụng thử nghiệm và hệ thống Quản lý yêu cầu khách hàng và hệ thống báo cáo từ xa cho kết quả tốt. Hai hệ thống này chính là bước khởi đầu cho việc xây dựng hệ thống CRM, tích hợp vào trong hệ thống Tính cước và chăm sóc khách hàng, vốn là một trong các nhiệm vụ quan trọng của Trung tâm công nghệ thông tin. Trong giai đoạn tiếp theo, nhóm nghiên cứu sẽ tiếp tục sử dụng kết quả của đề tài để làm tiền đề phát triển các module của hệ thống CRM như CRM Call Center, hệ thống quản lý chiến lược Campaign Management…. Dù nhóm nghiên cứu đã có nhiều cố gắng và đạt được một số kết quả bước đầu, tuy nhiên chắc chắn sẽ không thể tránh khỏi những điểm chưa thật hợp lý. Chúng tôi rất mong nhận được những ý kiến đóng góp để có thể tiếp tục hoàn thiện đề tài đạt kết quả cao nhất. Xin trân trọng cảm ơn. Tài liệu tham khảo Hà Thái Bảo, Trung tâm Công nghệ Thông tin, Học viện Bưu chính Viễn thông (2002), Áp dụng các công nghệ mới để xây dựng hệ thống tính cước và chăm sóc khách hàng theo mô hình nhiều lớp (Multi-layer), Hà Nội. Trung tâm dịch vụ khách hàng, Bưu điện Thành phố Hà Nội (2004), Tài liệu Khóa bồi dưỡng các dịch vụ viễn thông. Autoscribe Ltd (2004), Microsoft .NET and J2EE (an Autoscribe whitepaper, March 2004) Genetic Computer School (2002), System Analysis and Design – Trainee’s material, Singapore. J.D. Meier, Alex Mackman, Michael Dunner, and Srinath Vasireddy, Microsoft Corporation (2002), .NET Remoting Security. Stephen Toub (2002), “Secure Your .NET Remoting Traffic by Writing an Asymmetric Encryption Channel Sink”, MSDN Magazine. Phụ lục 1 : Xây dựng kênh truyền an toàn cho giao tiếp .NET Remoting Phụ lục này trình bày phương pháp xây dựng một kênh truyền an toàn sử dụng trong các ứng dụng .NET. Mặc dù định hướng sử dụng cho cấu trúc .NET Remoting sử dụng kênh TCP, kênh truyền này có thể sử dụng cho các kiến trúc giao tiếp khác trên nền .NET. Client Proxy Object Client App Domain Server App Domain Kênh truyền an toàn Hình 01 : Kênh truyền an toàn Kênh truyền an toàn (secured channel) thực hiện 2 chức năng chính: Đồng bộ ngữ cảnh an ninh giữa tiến trình khách và tiến trình chủ. Khi đó, lời gọi hàm trên máy chủ được thực hiện với tư cách của tiến trình khách, với các quyền và vai trò của tiến trình khách. Quá trình này giúp cho việc kiểm tra quyền và ghi lại các thao tác của người dùng trên máy chủ. Mã hóa dữ liệu trên đường truyền. Việc mã hóa sẽ giúp loại bỏ được nhiều nguy cơ mất an toàn hệ thống. Quá trình mã hóa được thực hiện dựa trên 2 tiêu chí: an toàn và nhanh. Một tiêu chí quan trọng đối với hai chức năng là trong suốt đối với mức ứng dụng, có nghĩa là người lập trình ở các lớp trên hoàn toàn không cần thực hiện thay đổi gì tới việc phát triển các hàm của mình. Để đáp ứng được yêu cầu này, một kiến trúc phân lớp tương tự với mô hình OSI được áp dụng. Đồng bộ ngữ cảnh an ninh của tiến trình chủ với tiến trình khách Bảng 01 mô tả các bước cơ bản được tiến hành tại máy trạm và máy chủ trong quá trình nhận thực và kiểm tra quyền. Bảng 01: Quá trình kiểm tra quyền trong hệ thống khách – chủ Client Server Người sử dụng đăng nhập qua form đăng nhập Thông tin về người sử dụng (tên người sử dụng và mật khẩu) sau khi mã hóa được truyền tới dịch vụ nhận thực trên tiến trình chủ thông qua lời gọi hàm Kiểm tra các thông tin người sử dụng với dữ liệu người sử dụng lưu trữ trong CSDL và trả kết quả về cho tiến trình khách. Trong trường hợp người dùng hợp lệ, thông tin về các vai trò của người dùng cũng sẽ được trả về Nếu tiến trình chủ xác nhận người sử dụng được phép đăng nhập, tiến trình khách sẽ xây dựng ngữ cảnh an ninh (tạo ra đối tượng Principal và lưu vào Thread.CurrentPrincipal). ... ... Các giao tiếp gọi hàm giữa tiến trình khách và chủ được thực hiện. Trong quá trình này, ngữ cảnh an ninh (Thread.CurrentPrincipal) của tiến trình chủ được đồng bộ với ngữ cảnh an ninh của tiến trình khách. Nhờ vậy quá trình kiểm tra quyền tại tiến trình chủ có thể thực hiện được sử dụng Cơ chế kiểm tra quyền theo vai trò của .NET (đã đề cập ở trên). Chú ý rằng việc đồng bộ này được thực hiện trong mỗi lời gọi từ tiến trình khách tới đối tượng trong tiến trình khách. ... ... Người sử dụng đăng xuất. Tiến trình khách hủy ngữ cảnh an ninh (hủy thông tin về người dùng hiện tại chứa trong Thread.CurrentPrincipal). Một lớp sẽ được chèn vào Cấu trúc giao tiếp khách - chủ của .NET Remoting (xin xem thêm phần 3.4 : .NET Remoting) để thực hiện đồng bộ ngữ cảnh an ninh giữa máy trạm và máy chủ. Client Proxy Object IdentityClientSink BinaryFormatterSink IdentityServerSink BinaryFormatterSink TransportSink TransportSink Các lớp khác Các lớp khác Client App Domain Server App Domain Kênh truyền (Tcp, Http...) Hình 02: Vị trí của lớp đồng bộ thông tin người dùng trong Cấu trúc giao tiếp khách - chủ của .NET Remoting Máy trạm Lớp thực hiện đồng bộ thông tin người dùng ở phía máy trạm bao gồm: Đối tượng provider: CMISE.SystemFrameworks.Security.IdentityClientSinkProvider Đối tượng lớp: CMISE.SystemFrameworks.Security.IdentityClientSink Nhiệm vụ của lớp này là đọc thông tin về ngữ cảnh an ninh ở máy trạm, sau đó ghi vào trong một header của bản tin. Như vậy bất kỳ lời gọi hàm nào từ máy trạm tới máy chủ đều được ghi kèm theo thông tin về ngữ cảnh an ninh. Việc ghi thêm thông tin này hoàn toàn không liên quan tới việc viết các hàm. Đó là vì cú pháp của các hàm được xây dựng ở lớp ứng dụng, trong khi việc ghi kèm thông tin này xảy ra ở lớp thấp hơn. Máy chủ Lớp thực hiện đồng bộ thông tin người dùng ở phía máy chủ bao gồm: Đối tượng provider: CMISE.SystemFrameworks.Security.IdentityServerSinkProvider Đối tượng lớp: CMISE.SystemFrameworks.Security.IdentityServerSink Nhiệm vụ của lớp đồng bộ tại máy chủ là đọc thông tin về ngữ cảnh an ninh do máy trạm truyền tới, dựa vào đó khởi tạo ngữ cảnh an ninh tại máy chủ giống như máy trạm. Sau khi ngữ cảnh an ninh đã được thiết lập ở máy chủ, việc kiểm tra quyền ở các lời gọi hàm tiếp theo có thể được thực hiện. Phần sau đây trình bày về quá trình mã hóa dữ liệu truyền trên kênh TCP nhằm xây dựng một kênh truyền được mã hóa an toàn giữa các thành phần phân tán của ứng dụng. Mã hóa dữ liệu trên kênh truyền Kênh truyền Tcp và Http mặc định sẽ truyền dữ liệu mà không thực hiện quá trình mã hóa có tính bảo mật nào (các phương thức mã hóa như SOAP, Base64 chỉ phục vụ cho quá trình truyền mà không có tính bảo mật). Điều này dẫn tới một số nguy cơ : Thông tin về quyền bị đánh cắp. Từ việc lộ thông tin về quyền sẽ dẫn tới 2 nguy cơ : Yêu cầu dịch vụ được tạo ra từ một máy khách không hợp lệ Giả mạo quyền từ một máy khách hợp lệ. Các thông tin yêu cầu dịch vụ bị đánh cắp. Kẻ tấn công có thể thực hiện các thông tin yêu cầu dịch vụ giả mạo để yêu cầu hệ thống thực hiện các công việc không được phép. Các thông tin về dữ liệu nhạy cảm bị đánh cắp. Ứng dụng quản lý yêu cầu khách hàng sẽ được triển khai tại các điểm giao dịch của Bưu điện Tỉnh. Các bưu cục ở xa (chẳng hạn triển khai tại các Bưu điện Huyện) có thể phải thường xuyên sử dụng dial up để kết nối tới nơi đặt máy chủ của hệ thống. Tín hiệu truyền trên các thiết bị truyền dẫn không bảo mật như đường điện thoại có thể sẽ là nguồn để thực hiện các cuộc tấn công vào hệ thống. Như vậy cần nhận thức rất rõ rằng việc xây dựng ứng dụng phân tán trên .NET Remoting sử dụng kênh Http hoặc Tcp phải đi kèm với việc mã hóa dữ liệu truyền đi. Để thực hiện mã hóa, có thể sử dụng 1 trong 2 cách sau: Tự phát triển chức năng mã hóa / giải mã. Dựa vào một phương thức mã hóa ở mức hệ thống. Các giải pháp bao gồm: Trên hệ điều hành Windows, có thể dùng ipsec để đảm bảo an toàn. Khi này, IPSec chịu trách nhiệm hoàn toàn trong việc mã hóa dữ liệu đường truyền. Sử dụng kênh truyền HTTP kết hợp với SSL để mã hóa đường truyền. Phương pháp thứ hai có một số nhược điểm: Không phải mọi phiên bản hệ điều hành Windows đều hỗ trợ IPSec. Việc cấu hình IPSec tại tất cả các máy trạm và máy chủ là một công việc tương đối phức tạp đòi hỏi kiến thức về mạng LAN. SSL chỉ áp dụng được với kênh truyền Http. Kênh Http lại không có ưu việt về tốc độ. Ứng dụng Quản lý yêu cầu khách hàng sử dụng phương pháp thứ nhất. Một trong các yêu cầu của chức năng mã hóa/giải mã là trong suốt đối với mã chương trình ở mức ứng dụng. Để thực hiện yêu cầu này, một lớp thực hiện việc mã hóa / giải mã sẽ được chèn vào Cấu trúc giao tiếp khách - chủ của .NET Remoting. Cấu trúc của các lớp này được thể hiện trên Hình 03. Kênh truyền (Tcp, Http...) Client Proxy Object IdentityClientSink BinaryFormatterSink IdentityServerSink BinaryFormatterSink TransportSink TransportSink SecureClient_ChannelSink SecureServer_ChannelSink Client App Domain Server App Domain Hình 03: Vị trí của lớp bảo mật trong Cấu trúc giao tiếp khách - chủ của .NET Remoting Lớp bảo mật ở phía máy trạm được thực hiện bởi đối tượng SecureClient_ChannelSink. Lớp bảo mật ở phía máy chủ được thực hiện bởi đối tượng SecureServer_ChannelSink. Hai đối tượng này có nhiệm vụ trao đổi các thông tin cần thiết trong quá trình mã hóa và thực hiện mã hóa mọi bản tin truyền giữa máy trạm và máy chủ. Để nắm được quá trình mã hóa, chúng ta xem xét một số vấn đề cơ bản của các thuật toán mã hóa. Cơ bản về các thuật toán mã hóa Các phương pháp mã hóa phổ biến đều được thực hiện theo các bước được mô tả như sau: Dữ liệu gốc Khóa Dữ liệu đã được mã hóa Mã hóa Kênh truyền Kênh truyền Dữ liệu đã được mã hóa Dữ liệu gốc Khóa Giải mã Hình 04 : Quá trình mã hóa và giải mã Việc mã hóa được thực hiện bằng việc tác động một khóa lên dữ liệu gốc thông qua một thuật toán mã hóa. Kết quả đầu ra là dữ liệu đã được mã hóa. Đối với các phương pháp mã hóa 1 chiều, chỉ có bước mã hóa mà không có bước giải mã. Các phương pháp này thường được sử dụng để mã hóa các thông tin để so sánh (như mật khẩu) trước khi lưu thông tin. Khi đó, chẳng hạn để so sánh mật khẩu, chỉ cần áp dụng phương pháp tương tự với mật khẩu của người dùng và so sánh kết quả với dữ liệu đã được lưu để đưa ra kết luận là có đúng mật khẩu hay không. Mật khẩu sẽ không bị lộ ngay cả khi kẻ tấn công có thể truy xuất vào nơi lưu giữ mật khẩu. Phương pháp mã hóa một chiều hiện nay được sử dụng rộng rãi nhất là MD5. Thông tin truyền trên đường truyền khi kết nối giữa các thành phần cần phải được khôi phục trước khi bên nhận có thể hiểu được. Vì vậy, phương pháp mã hóa được sử dụng phải là mã hóa 2 chiều, có đầy đủ các bước mã hóa ở phía gửi và giải mã ở phía nhận. Căn cứ vào các đặc điểm của các khóa sử dụng trong quá trình mã hóa và giải mã, các thuật toán mã hóa 2 chiều được chia thành 2 loại: đối xứng và bất đối xứng. Mã hóa đối xứng Trong phương pháp mã hóa đối xứng, việc mã hóa và giải mã cùng sử dụng một khóa bí mật. Sở dĩ có tên gọi như vậy là vì khóa bí mật cần phải được trao đổi giữa người mã hóa và giải mã, nhưng không được lộ cho bên thứ ba biết. Thuật toán mã hóa đối xứng thông dụng nhất là DES (Data Encryption Standard) được phát triển bởi IBM vào thập kỷ 70. Mã hóa bất đối xứng Trong phương pháp mã hóa bất đối xứng, việc mã hóa sử dụng một khóa (khóa chung), việc giải mã lại sử dụng một khóa khác (khóa riêng). Mỗi bên tham gia quá trình gửi nhận thông tin mã hóa sẽ có một khóa chung và một khóa riêng. Khóa chung có thể gửi cho đối tác để thực hiện mã hóa dữ liệu. Việc lộ khóa chung không gây nguy hiểm, vì nó không sử dụng để giải mã. Như vậy, khóa chung có thể gửi đi dưới dạng nguyên bản (cleartext). Thuật toán mã hóa bất đối xứng thông dụng nhất là RSA (Rivest, Shamir, and Adleman – tên của 3 người tham gia trong việc phát minh ra thuật toán này). Ưu điểm của phương pháp mã hóa đối xứng là việc mã hóa, giải mã có thể thực hiện với tốc độ rất nhanh. Tuy nhiên khóa bí mật sử dụng cần phải được trao đổi giữa bên gửi và bên nhận theo một phương pháp nào đó trước đi quá trình gửi nhận có thể thực hiện. Phương pháp mã hóa bất đối xứng có tốc độ thấp, quá trình trao đổi phải thực hiện qua nhiều bước. Một giải pháp mã hóa – giải mã hiệu quả là giải pháp áp dụng cả 2 phương pháp trên. Đầu tiên, phương pháp mã hóa bất đối xứng được sử dụng để trao đổi khóa bí mật giữa hai phía gửi nhận thông tin. Sau khi 2 phía đã thống nhất được khóa bí mật, việc mã hóa – giải mã sẽ được thực hiện sử dụng phương pháp mã hóa đối xứng. Cơ chế trao đổi thông tin mã hóa trong chương trình Client và server sẽ sử dụng phương pháp mã hóa đối xứng để trao đổi thông tin. Khóa bí mật sử dụng sẽ được trao đổi giữa client và server sử dụng cặp mã không đối xứng. Bảng 02 mô tả một phiên giao dịch giữa máy trạm và máy chủ sử dụng phương pháp mã hóa kể trên. Khóa bí mật sử dụng để trao đổi thông tin sẽ được gọi là SK1, cặp khóa dùng cho việc trao đổi khóa bí mật SK1 này là PK2 (khóa chung) và MK2 (khóa riêng). Bảng 02: Một phiên giao dịch giữa máy trạm và máy chủ có mã hóa bảo mật Client Server Gửi yêu cầu thông tin về khóa bí mật SK1. Yêu cầu này phải kèm theo một khóa chung PK2 để server có thể sử dụng để mã hóa SK1 trả lại cho client. Tạo ra SK1 dành riêng cho client này. Khóa này sẽ được sử dụng để trao đổi thông tin giữa client và server. Mã hóa SK1 bằng PK2 mà client gửi tới, sau đó gửi kết quả mã hóa về cho client. Giải mã khóa SK1 sử dụng khóa riêng MK2. ... ... Quá trình mã hóa/ giải mã giữa client và server được thực hiện sử dụng khóa bí mật SK1. Thông tin được mã hóa/ giải mã sẽ bao gồm: Lời gọi hàm cùng với các tham số. Kết quả trả về của hàm. ... ... Sau khi đã đồng bộ được khóa bí mật SK1, máy chủ sẽ lưu lại khóa này trong vùng đệm để thực hiện các giao dịch tiếp theo với máy trạm. Vì có nhiều máy trạm giao tiếp với máy chủ nên vùng đệm này sẽ là một danh sách các khóa, mỗi khóa tương ứng với một máy trạm. Để đảm bảo an toàn, sau một thời gian nhất định không thấy có giao dịch nào từ máy trạm, máy chủ sẽ hủy khóa bí mật tương ứng. Nếu máy trạm sau đó tiếp tục thực hiện giao dịch, quá trình trao đổi khóa bí mật sẽ bắt đầu lại từ đầu. Phụ lục 2 : Các giao diện của chương trình Quản lý yêu cầu Giao diện máy chủ Cửa sổ đăng nhập Giao diện chính Chức năng Tiếp nhận yêu cầu – Lắp đặt mới Chức năng Tiếp nhận yêu cầu – Di chuyển Chức năng Tiếp nhận yêu cầu – Chuyển quyền Chức năng Tiếp nhận yêu cầu – Tách nhập mã thanh toán Giao diện Tiếp nhận yêu cầu – Dịch vụ gia tăng. Giao diện đăng ký và hủy bỏ dịch vụ Giá trị gia tăng Giao diện Tiếp nhận yêu cầu – Đổi số Giao diện Tiếp nhận yêu cầu – Đổi SIM. Giao diện thu phí hợp đồng. Giao diện quản lý Séc. Chức năng cập nhật danh bạ thuê bao Giao diện Phát triển thuê bao – Phân đơn vị thi công Báo cáo công việc của các đơn vị thi công. Báo cáo tổng hợp thuê bao. Báo cáo khách hàng theo đơn vị quản lý