Service
Bảo mật là một vấn đề quan trọng và cần phải đƣợc tính đến khi triển khai các dịch vụ Web. Năm 2005, Web Services-Interoperability Organisation (WS-I) đã công bố một số nguy cơ về an toàn bảo mật chính mà dịch vụ Web phải đối mặt, bao gồm: 1/ Thông điệp bị sửa đổi; 2/ Lộ lọt thông tin; 3/ Tấn công ở giữa (Man in the middle attack); 4/ Gửi lại một phần thông báo (Relay of message parts); 5/ Tấn công lặp lại; 6/ Từ chối dịch vụ.
Về cơ bản, các nguy cơ chủ yếu nhằm khai thác các điểm yếu trong bảo mật, toàn vẹn, xác thực thông tin và khả năng tự bảo vệ của hệ thống CNTT. Để chống lại các nguy cơ trên, một số chuẩn về về bảo mật Web Service đƣợc đề xuất nhƣ sau:
1. W3C XML Encryption đƣợc sử dụng để mã hóa và giải mã nội dung. Với tiêu
chuẩn này, một tài liệu XML có thể đƣợc mã hóa từng phần và cho phép trong tài liệu có nhiều phần khác nhau đƣợc mã hóa bởi các khóa khác nhau để gửi đồng thời cho nhiều ngƣời nhận cùng một lúc. Khi sử dụng chuẩn này, tính bảo mật của thông báo đƣợc đảm bảo.
2. W3C XML Signature đƣợc sử dụng để cung cấp dịch vụ đảm bảo tính toàn vẹn,
chữ ký số. XML Signature đƣợc sử dụng để đảm bảo rằng nội dung của một tài liệu XML không bị thay đổi.
3. WS-Security Tokens: đƣợc sử dụng để giúp ngƣời nhận định danh đƣợc ngƣời
gửi thông báo. Một số kiểu security tokens có thể áp dụng nhƣ:
- Username Tokens: xác định thông qua tên ngƣời dung, có thể sử dụng thêm mật
khẩu.
- X.509 Tokens: sử dụng một chứng chỉ số X.509 để xác htực một thông báo SOAP hoặc để định danh khóa công khai của một thông báo SOAP đã đƣợc mã hóa.
- SAML (Security Assertion Markup Language) Tokens: đƣợc sử dụng để bảo
mật thông báo SOAP và quá trình trao đổi thông báo SOAP với sự trợ giứp của xác nhận SAML.
- Keberos Tokens: đƣợc sử dụng để cho phép một dịch vụ xác thực bằng một thẻ
Kerberos.
- Rights Expresstion Language (REL) Tokens.
4. W3C WS-Addressing: đƣợc sử dụng để chống lại tấn công lặp lại. Một định danh đƣợc gắn với mỗi thông báo để chống tấn công lặp lại, định danh này có thể bao gồm một số thông tin về nhãn thời gian (timestamp) nhằm nâng cao khả năng chống tấn công lặp lại.
5. Một số chuẩn bảo mật truyền thống trên Web khác cũng đƣợc áp dụng bao gồm
IETF SSL/TSL, SSL/TSL có xác thực máy trạm và IETF HTTP authentication method cũng giúp giảm thiểu các điểm yếu về xác thực và bảo mật.
Ngoài ra, còn có một số đặc tả hoặc chuẩn đƣợc thiết kế để hỗ trợ các dịch vụ ở trên. Ví dụ nhƣ W3C XML Key Management Specìication (XKMS) đƣợc định nghĩ là giao thức phục vụ cho việc quản lý khóa công khai. Nó định nghĩ cách để phân phối và đăng ký các khóa công khai đƣợc sử dụng bởi XML Signature và XML Encryption. XKMS bao gồm 2 giao thức thành phần: XML Key Registration Service Specification (X-KRSS) và XML Key Information Service Specification (X-KISS). X-KRSS đƣợc
sử dụng để đăng ký khóa công khai và X-KISS đƣợc sử dụng xác định các khóa đƣợc cung cấp trong một XML Signature.
Extensible Acces Control Markup Language (XACML) là một đặc tả khác đƣợc xây dựng nhằm tăng cƣờng khả năng khiểm soát truy nhập của Web Services.
Một số nguyên tắc trong triển khai:
Các tiêu chuẩn về bảm mật đƣợc mô tả ở trên đƣợc xuất phát từ bảo mật thông bao SOAP. Tất cả các bên tham gia quá trình trao đổi thông báo có thể sử dụng công nghệ này theo cách thức nhƣ sau:
1. Bên gửi phải mô tả rõ rang các quá trình xử lý trung gian trong phần Header của thông báo SOAP.
2. Ngƣời gửi có thể mã hóa và ký phần Headers bằng cách sử dụng XML
Signature.
3. Mỗi phần của thông báo SOAP có thể đƣợc đƣợc cung cấp một chữ ký khác nhau tùy thuộc vào mục đích của bên gửi.
4. Ngƣời gửi có thể sử dụng XKMS để phân phối và đăng ký các khóa công khai
cho mỗi quá trình xử lý trung gian.
5. Tùy thuộc vào thông báo nhận đƣợc, mỗi một bƣớc trung gian đƣợc ký trong phần Header của thông báo SOAP bởi một khóa công khai XKMS phải đƣợc tiến hành xác thực chữ ký.
6. Sau khi khẳng định chữ ký hợp lệ, mỗi quá trình trung gian có thể sủng dụng
XML encryption để giải mã phần Headers của thông báo SOAP tƣơng ứng với phần nội dung.
Quá trình này có thể lặp lại cho đến khi hoàn thành toàn bộ quá trình. Hơn nữa, mỗi bƣớc trung gian có thể thực hiện việc mã hóa và ký một Headers của thông báo SOAP hoặc thành phần của thông báo (message components) mà phần nội dung này sẽ đƣợc yêu cầu ở trong một bƣớc sau đó của quá trình.
Do thông báo SOAP đƣợc vận chuyển thông qua giao thức HTTP, các thiết bị tƣờng lửa truyền thống thƣờng cho phép tất các lƣu lƣợng XML đi qua mà không có bất cứ sự kiểm tra nào. Vì thế, thiết bị tƣờng lửa không làm tăng khả năng bảo vệ cho một thông báo SOAP. Một lời khuyên rằng, nếu triển khai dịch vụ Web mà không có sự hỗ trợ của WS-Security, cần triển khai một XML gateways hoặc thiết bị tƣờng lửa có khả năng kiểm tra XML.
Ngoài ra, đối với một ứng dụng bình thƣờng, nhật ký (security audit log) của tất cả các thông báo gửi đi và nhận về cần đƣợc lƣu giữ. Nhật ký có thể sẽ cung cấp cho nhƣng thông tin hữu ích giúp cho việc đánh giá một cách toàn diện và hiệu quả vê khả năng đảm bảo an toàn bảo mật của hệ thống.