sẽ bật các listener có thể cần đến.
Khi triển khai phải chắc chắn rằng cơ sở hạ tầng truyền thông cần thiết giữa client và server được cấu hình chính xác. Khi sử dụng Websphere MQ để truyền tải SOAP, việc triển khai cũng liên quan đến việc cấu hình Websphere MQ queue manager và client hoặc server connections cho chúng. Websphere MQ cũng bao gồm tiện ích triển khai được cài đặt như một phần của SOAP.
2.3. An toàn bảo mật thông tin qua SSL với Websphere MQ và Web Service Service
2.3.1. Vấn đề an toàn bảo mật thông tin qua SSL với Web service
Để đảm bảo an toàn cho đường đi của dữ liệu và có thể kiểm soát được liệu có ai đó thâm nhập vào thông tin trên đường truyền khi sử dụng web service, ta có thể kết hợp web service với SSL (Secure Socket Layer)[3] để thiết lập được một giao dịch an toàn.
SSL không phải là một giao thức đơn lẻ, mà là một tập các thủ tục đã được chuẩn hoá để thực hiện các nhiệm vụ bảo mật sau:
- Xác thực server: Cho phép người sử dụng xác thực được server muốn kết nối.
- Xác thực Client: Cho phép phía server xác thực được người sử dụng muốn kết nối.
- Mã hoá kết nối: Tất cả các thông tin trao đổi giữa client và server được mã hoá trên đường truyền nhằm nâng cao khả năng bảo mật.
Giao thức SSL bao gồm 2 giao thức con: giao thức SSL record[3] và giao thức SSL handshake[3]. Giao thức SSL record xác định các định dạng dùng để truyền dữ liệu. Giao thức SSL handshake (gọi là giao thức bắt tay) sẽ sử dụng giao thức SSL record để trao đổi một số thông tin giữa server và client vào lần đầu tiên thiết lập kết nối SSL.
Giao thức SSL hỗ trợ rất nhiều các thuật toán mã hoá, được sử dụng để thực hiện các công việc trong quá trình xác thực server và client, truyền tải các chứng thực số (certificates) và thiết lập các khoá của từng phiên giao dịch (sesion key).
2.3.2 SSL và Websphere MQ
Các message channel và Message Queue Interface (MQI) channel có thể sử dụng giao thức SSL để quy định sự an toàn bảo mật mức liên kết. Websphere MQ
hỗ trợ phiên bản 3.0 của giao thức SSL và phiên bản 1.0 của giao thức TLS (Transport Layer Security)[3]. Việc ánh xạ ý tưởng của một SSL client và SSL server vào các loại channel khác nhau đã cung cấp trong Websphere MQ là rất quan trọng. Với mỗi cặp channel, bộ khởi tạo giao tiếp được hướng đến SSL client trong khi đầu cuối của channel khác trở thành SSL server.
Việc chỉ ra các thuật toán mã hóa sử dụng cho giao thức SSL được cung cấp bởi thông số mã hóa và xác thực (CipherSpec)[3] như một phần của định nghĩa channel. CipherSpec là một hàm băm và thuật toán mã hoá đặc biệt. Các CipherSpec đều được chỉ ra trên nền per-channel và sử dụng một tham số trong định nghĩa channel gọi là SSLCipherSpec (SSLCIPH)[3]. Khi một channel an toàn đã được thiết lập, cả hai đầu phải có cùng CipherSpec. Tất cả các loại channel trong Websphere MQ đều có thuộc tính SSLCIPH. Đây cũng là thuộc tính nơi CipherSpec được thiết lập.
Encryption + Hash Function=CipherSpec (thông số mã hóa và xác thực)[3] CipherSpec + Authentication/Key Exchange=CipherSuite (bộ mật mã)[3] Để chỉ ra nơi channel đáp ứng sẵn sàng chấp nhận các kết nối, ta sử dụng tham số SSLClientAuthentication (SSLCAUTH) trong định nghĩa channel (có thể được đặt 1 trong 2 giá trị REQUIRED hoặc OPTIONAL)[3]. Trong quá trình SSL handshake, MCA (Message Channel Agent) gửi chứng thực số của Queue manager cho các cộng sự MCA của nó tại cuối các channel khác để xác thực. Tại client cuối của MQI channel, mã Websphere MQ client đảm nhiệm việc gửi chứng thực số, cùng với vai trò trình cung cấp dịch vụ an toàn bảo mật. Trong trường hợp này, mã Websphere MQ client đóng vai trò user của ứng dụng client. Các Queue manager và các user Websphere MQ client không cần các chứng thực số cá nhân kết hợp với chúng khi chúng đóng vai trò SSL client, trừ khi SSLCAUTH được chỉ rõ tại phía server của channel[3].
SSL có thể cho phép nhiều CipherSpecs được chuyển qua một client trong quá trình SSL handshake và server sẽ chọn một trong số những cái mà nó hỗ trợ. WebSphere MQ sẽ áp đặt hạn chế rằng chỉ một CipherSpec có thể được cung cấp trong định nghĩa channel và nó phải phù hợp với cả hai đầu[3].
Để sử dụng SSL cần phải có một giấy chứng thực cho mỗi bên khi muốn kết nối một cách an toàn. Đối với WebSphere MQ, điều này có nghĩa là cần một giấy chứng thực cho mỗi queue manager khi sử dụng MCA channel và mỗi giấy chứng thực cho một mã người sử dụng (user ID) truy cập vào hệ thống khi sử dụng MQI channel[3]. Các chứng thực số sẽ sử dụng trong WebSphere MQ được lưu trữ trong một key repository, được biết đến như một key database[3]. File repository có phần mở rộng là „.kdb‟. Tất cả các chứng thực, kể cả user và CA, đều được lưu trữ trong database này. Database được sử dụng bởi queue manager để quyết định
cái gì cho phép SSL bảo mật kết nối tới. Thuộc tính queue manager SSLKeyRepository[3] giữ vị trí của database trong file hệ thống không có phần mở rộng kdb, nó chỉ ra vị trí của repository giữ chứng thực số của queue manager. Các WebSphere MQ client cũng sử dụng SSLKeyRepository của chúng như một kho chứng thực số để quyết định queue manager server nào chúng tin cậy để giao tiếp một cách an toàn.
SSL được sử dụng trong Websphere MQ để xác thực từ Queue manager đến Queue manager và mã hóa mức liên kết, tức thông điệp được mã hóa khi chúng được chuyển qua mạng nhưng không được mã hóa khi lưu trữ trong queue. Nếu sự thiết lập chế độ an toàn đủ để bảo vệ các queue thì có thể chỉ cần yêu cầu thêm sự an toàn mức liên kết. Nếu hệ thống đã sẵn sàng xác thực các ứng dụng và mã hoá các message vào lúc MQPUT và giải mã chúng vào lúc MQGET thì các message đã được mã hoá ngay khi chúng còn lưu trữ trong queue, chúng có thể không cần mã hoá thêm khi được truyền qua mạng. Trong hoàn cảnh này, an toàn mức liên kết là không cần đến, hoặc chỉ cần đến cho xác thực queue manager đến queue manager ở mức nhỏ nhất.[3]
Để thiết đặt các message channel bảo mật và các MQI channel bảo mật có thể tiến hành qua các bước sau:
- Tạo key repository
- Tạo các chứng thực cho WebSphere MQ queue manager và client
- Bổ sung các chứng thực số vào key repository
- Chỉ rõ các thuộc tính SSL trong URI (Universal Resource Indicator) khi sử dụng WebSphere MQ truyền tải qua SOAP.
Cấu hình SSL cho WebSphere MQ truyền tải qua SOAP được cung cấp thông qua một số lựa chọn trong URI, các lựa chọn này phụ thuộc vào môi trường sử dụng chúng. Trong môi trường .NET, các lựa chọn sau được chỉ ra cho cấu hình SSL:
sslKeyRepository: Đây là lựa chọn chỉ ra vị trí của file SSL key repository (file .kdb)
sslCipherSpec: Lựa chọn này có thể nhận giá trị bất kỳ được chỉ ra trong giá trị SSLCIPH trong bất kỳ channel nào.
Công cụ được sử dụng để biểu thị key repository và quản lý chứng thực là IBM Global Kit (GSKit) được cung cấp cùng với bộ cài của WebSphere MQ.[3]
CHƢƠNG 3: XÂY DỰNG HỆ THỐNG KẾT NỐI THANH TOÁN GIỮA NGÂN HÀNG VÀ CÁC CÔNG TY CHỨNG KHOÁN 3.1. Mô tả hoạt động nghiệp vụ
3.1.1 Một số khái niệm
- Hệ thống kết nối thanh toán giữa Ngân hàng và các CTCK: là hệ thống quản lý thông tin các CTCK và nhà đầu tư, có cơ sở dữ liệu tập trung đặt tại máy chủ Bank Gateway của Ngân hàng. Thông qua hệ thống, các CTCK có thể quản lý tiền gửi giao dịch chứng khoán của khách hàng và liên kết để kiểm tra điều kiện, thực hiện các giao dịch mua bán chứng khoán của khách hàng, thực hiện các giao dịch chuyển tiền ứng với nghiệp vụ chi trả cổ tức cho khách hàng…Đồng thời cả hai bên, CTCK và Ngân hàng, đều có thể giám sát và đối chiếu các giao dịch đã thực hiện thông qua các báo cáo đối chiếu của hệ thống.
- Hệ thống CoreBanking: Là hệ thống lõi của Ngân hàng, trong đó có phần quản lý các tài khoản tiền gửi của nhà đầu tư và CTCK, thực hiện các lệnh mở, đóng tài khoản tiền gửi, nộp, rút tiền thông qua giao diện của CoreBanking…và thực hiện các lệnh vấn tin, phong toả, giải phong toả, chuyển khoản…từ hệ thống kết nối thanh toán gửi đến.
- Tài khoản mua bán chứng khoán: Là tài khoản dùng để thực hiện giao dịch chứng khoán của nhà đầu tư mở tại CTCK.
- Tài khoản CA (Current Account): Là tài khoản tiền gửi tại Ngân hàng.
- Tài khoản TA (Trading Account): là tài khoản CA chuyên dùng của nhà đầu tư hoặc CTCK mở tại Ngân hàng dùng để giao dịch chứng khoán. Tài khoản TA có đầy đủ tính chất của một tài khoản tiền gửi không kỳ hạn tại Ngân hàng nên hoàn toàn có thể sử dụng các chức năng như gửi tiền, rút tiền (nếu số tiền rút hợp lệ), vấn tin tài khoản…thông qua hệ thống CoreBanking của Ngân hàng. - Thanh toán chứng khoán: Là giao dịch thanh toán giữa tài khoản tiền gửi thanh
toán của các CTCK và tài khoản Trading Account (TA) của nhà đầu tư chứng khoán tại Ngân hàng, được thực hiện với sự hỗ trợ của hệ thống kết nối thanh toán chứng khoán.
- Số dư khả dụng của tài khoản TA: Là số dư không bị phong toả của tài khoản (bằng số dư tài khoản trừ đi số tiền đang bị phong toả) mà chủ tài khoản có thể dùng để thực hiện các giao dịch như rút tiền, mua chứng khoán, chuyển tiền…
3.1.2 Mô tả nghiệp vụ:
Mỗi CTCK có liên kết với Ngân hàng để thực hiện thanh toán chứng khoán sẽ có hai tài khoản tiền gửi tại một chi nhánh nào đó của Ngân hàng:
- Một tài khoản CA dùng để quản lý và hạch toán các giao dịch mua/bán chứng khoán của các Nhà đầu tư tại CTCK.
- Một tài khoản TA dùng để quản lý và hạch toán các giao dịch mua/bán chứng khoán của CTCK trong hoạt động kinh doanh và các giao dịch liên quan khác của chính CTCK (Tài khoản tự doanh).
Tài khoản thứ nhất sẽ được sẽ được khai báo cùng với thông tin về CTCK trên hệ thống kết nối thanh toán, tài khoản thứ hai cũng sẽ được khai báo nhưng với tính chất như tài khoản của nhà đầu tư thông thường.
Vì Ngân hàng sẽ quản lý tiền đầu tư chứng khoán của các nhà đầu tư nên mỗi nhà đầu tư phải được mở một tài khoản tiền gửi tại một chi nhánh nào đó của ngân hàng. Tài khoản này cũng là tài khoản Trading Account và sẽ được gắn kết với tài khoản hoạt động chứng khoán của nhà đầu tư tại CTCK thông qua hệ thống kết nối thanh toán.
Sau khi nhà đầu tư đã có TK tiền gửi tại Ngân hàng, Ngân hàng sẽ phải khai báo tài khoản này cùng với tài khoản mua bán chứng khoán trên hệ thống kết nối thanh toán. Với các nhà đầu tư đang có số dư trong tài khoản hoạt động chứng khoán thì số tiền đó sẽ được chuyển sang tài khoản TA tại Ngân hàng thông qua lệnh chuyển tiền từ tài khoản CA của CTCK sang tài khoản TA của nhà đầu tư và lệnh này được thực hiện thông qua hệ thống CoreBanking của Ngân hàng.
Khi một nhà đầu tư đặt lệnh mua chứng khoán, CTCK sẽ phải gửi lệnh vấn tin tài khoản TA của nhà đầu tư tới hệ thống kết nối thanh toán để xem số dư khả dụng của tài khoản có đủ để thực hiện giao dịch không. Nếu số dư đủ để thực hiện giao dịch, CTCK sẽ tiếp tục gửi lệnh phong toả tài khoản TA của nhà đầu tư với số tiền bằng số tiền mua chứng khoán cộng phí giao dịch. Sau khi có kết quả khớp lệnh, nếu lệnh mua của nhà đầu tư không được khớp, CTCK sẽ gửi lệnh giải phong toả số tiền đã phong toả tài khoản TA của khách hàng trước đó sang hệ thống kết nối. Trường hợp toàn bộ lệnh bán của nhà đầu tư được khớp, CTCK sẽ gửi lệnh tới hệ thống kết nối để chuyển toàn bộ số tiền đã phong toả trước đó sang tài khoản CA hạch toán các giao dịch mua bán chứng khoán của CTCK. Nếu chỉ khớp lệnh một phần, CTCK sẽ gửi lệnh chuyển một phần số tiền đã phong toả trước đó sang tài khoản CA của CTCK, số tiền này bằng tổng số tiền mua lượng chứng khoán được khớp và phí tương ứng, số tiền còn lại trong tổng số tiền đã phong toả sẽ được giải phong toả.
Khi nhà đầu tư đặt lệnh bán chứng khoán, đến khi có kết quả khớp lệnh, vào ngày T+3, CTCK sẽ gửi lệnh chuyển tiền (với số tiền bằng số tiền bán chứng khoán khớp được cộng số tiền phí giao dịch) từ tài khoản CA của CTCK sang tài khoản TA của nhà đầu tư.
nhà đầu tư phải được CTCK chấp thuận, sau đó CTCK sẽ gửi tới hệ thống kết nối thanh toán lệnh chuyển tiền từ tài khoản CA của CTCK sang tài khoản TA của nhà đầu tư, sau đó nhà đầu tư sẽ rút tiền tại Ngân hàng thông qua hệ thống CoreBanking.
Cuối mỗi ngày giao dịch, sau khi hệ thống đã thực hiện hết các giao dịch phát sinh trong ngày về hoạt động thanh toán chứng khoán, CTCK và chi nhánh Ngân hàng sẽ gửi lệnh tới hệ thống kết nối để lấy về các bảng liệt kê giao dịch mua bán chứng khoán hoặc lấy về các sao kê chi tiết tài khoản CA của Công ty chứng khoán, tài khoản chuyên dùng (TA) của nhà đầu tư nhằm đối chiếu với các chứng từ giao dịch trong ngày.
3.1.3 Các yêu cầu của hệ thống
Hệ thống kết nối thanh toán giữa Ngân hàng và CTCK giúp các CTCK quản lý tiền gửi giao dịch chứng khoán của khách hàng và liên kết để kiểm tra điều kiện, thực hiện các giao dịch mua bán chứng khoán của khách hàng. Hệ thống kết nối thanh toán này cần có cơ chế truyền nhận message thực hiện các chức năng giao dịch giữa ngân hàng và CTCK, đảm bảo vấn đề ổn định, bảo mật và an toàn dữ liệu v.v..
Hệ thống có các chức năng:
- Quản lý các CTCK có khách hàng mở TK tiền gửi giao dịch chứng khoán tại ngân hàng.
- Quản lý người sử dụng của các CTCK (người gửi lệnh giao dịch với TK tiền gửi của nhà đầu tư tại ngân hàng).
- Thực hiện gắn kết TK tiền gửi tại ngân hàng với TK giao dịch chứng khoán và CTCK, nơi nhà đầu tư mở TK giao dịch chứng khoán (bao gồm cả việc chuyển số tiền hiện có trong TK của nhà đầu tư từ CTCK sang TK tại ngân hàng).
- Người sử dụng của CTCK có thể vấn tin trực tuyến TK tiền gửi thanh toán giao dịch chứng khoán của nhà đầu tư.
- Phong toả trực tuyến TK tiền gửi của nhà đầu tư tại ngân hàng ngay khi nhân viên môi giới của CTCK thực hiện gửi lệnh mua chứng khoán.
- Giải toả trực tuyến TK tiền gửi của nhà đầu tư tại ngân hàng ngay khi nhân viên của CTCK thực hiện huỷ lệnh mua chứng khoán hoặc khi có kết quả khớp lệnh mua chứng khoán.
- Thực hiện chuyển tiền (theo yêu cầu từ CTCK) từ tài khoản của CTCK mở tại ngân hàng đến tài khoản của nhà đầu tư khi sau khi khớp lệnh bán chứng khoán sau khi trừ đi số tiền phí giao dịch tương ứng.
- Thực hiện chuyển tiền (theo yêu cầu từ CTCK) từ tài khoản nhà đầu tư tại ngân hàng đến tài khoản của CTCK tại ngân hàng sau khi có kết quả khớp lệnh mua chứng khoán của nhà để thanh toán tiền mua chứng khoán và mức phí tương ứng.
- Thực hiện chuyển tiền cổ tức (theo yêu cầu từ CTCK) từ tài khoản CTCK mở tại ngân hàng vào tài khoản tại Ngân hàng của nhà đầu tư khi có phát sinh nghiệp vụ chia cổ tức.
- Ghi log lại toàn bộ quá trình giao dịch giữa ngân hàng và CTCK để phục vụ chức năng lập các bảng kê phục vụ cho công tác quản lý, đối chiếu giữa ngân hàng và CTCK.
3.2. Xây dựng mô hình hệ thống
3.2.1 Mô hình kết nối
Hệ thống được xây dựng dựa trên nền web service và thông tin trao đổi giữa