Với việc phát triển không ngừng của công nghệ 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 tính toán phân tán. Các kiến trúc phân tán hướng đối tượng DOA (Distributed Object Architecture) sử dụng các công nghệ như là CORBA, DCOM, DCE và Java RMI đang nhanh chóng chuyển sang các kiến trúc hướng dịch vụ (SOA) với những công nghệ mới như SOAP, HTTP, XML.
Việc thay đổi kiến trúc hệ thống như thế đã dẫn đến những thay đổi nhất định trong việc đưa ra các giải pháp cho vấn đề bảo mật của hệ thống. Hầu hết các giải pháp bảo mật hiện nay đều dựa trên thực trạng là cả hệ thống máy khách và máy chủ đều đặt tại cùng một mạng vật lý (như LAN) hay mạng logic (như VPN). Những giải pháp này đảm bảo an toàn hệ thống hay thắt chặt an ninh thông qua việc giám sát tất cả mọi ngõ ngách ra vào của mạng. Tuy nhiên, với một hệ thống mở như SOA thì các giải pháp này không còn thích hợp nữa
1.4.2. Giới thiệu kiến trúc bảo mật hướng dịch vụ
• Một số yêu cầu đặt ra của kiến trúc
Chứng thực
Hầu hết các nhà cung cấp dịch vụ đều yêu cầu các bên sử dụng dịch vụ phải được chứng thực trước khi yêu cầu sử dụng dịch vụ được chấp nhận
Các đối tượng sử dụng dịch vụ cũng phải chứng thực nhà cung cấp dịch vụ khi nhận được các kết quả trả về
Hệ thống nên hỗ trợ nhiều cơ chế chứng thực và các cơ chế này phải đủ linh hoạt để có thể dễ dàng thay đổi theo các yêu cầu đặc trưng của dịch vụ
Phân quyền
Các đối tượng sử dụng phải có một quyền nhất định nào đó. Việc kiểm tra các quyền này thông qua các chính sách (ví dụ như đối tượng nào được quyền sử dụng các dịch vụ nào, và trong điều kiện gì…)
Nên sử dụng nhiều mô hình phân quyền khác nhau:
- Discretionary Access Control (DAC): mô hình này kiểm soát việc truy cập dựa trên ID của đối tượng muốn truy cập. ID có thế là mật khẩu, tên truy cập hay các dấu hiệu đặc trưng của phần mềm hay phần cứng…
- Mandatory Access Control (MAC): bảo vệ thông tin bằng cách gán cho mọi thông tin một giá trị “nhạy cảm” và sẽ so sánh giá trị này với giá trị
“nhạy cảm” của người truy cập. Đây sẽ là cơ sở để thực hiện việc cấp quyền truy cập thông tin. Mô hình này thích hợp cho các hệ thống đòi hỏi độ an toàn cao.
- Role - Base Access Control (RBAC): quyết định cho phép truy cập dựa trên vai trò của từng cá nhân và trách nhiệm trong tổ chức của cá nhân đó.
Độ tin cậy
Phải có cơ chế để bảo vệ môi trường truyền dữ liệu bên dưới cũng như các thông điệp và tài liệu được truyền trên môi trường đó sao cho chúng không bị truy cập bởi các đối tượng không có quyền.
Toàn vẹn dữ liệu
Bảo vệ dữ liệu không bị xâm hại trong suốt quá trình truyền
Cơ chế định danh
Nhằm đảm bảo các đối tượng tham gia trong quá trình tương tác không thể phủ nhận vai trò của mình (người gửi không thể phủ nhận những gì mình đã gửi và người nhận không thể chối bỏ những gì mình đã nhận).
Yêu cầu này đặc biệt quan trọng trong môi trường thương mại ngày nay khi mà các cuộc gặp gỡ không thể tận mặt được.
Có một cơ chế quản lý
Kiến trúc an ninh của hệ thống phải cung cấp các cơ chế để quản lý các tính năng ở trên bao gồm quản lý người dùng, quản lý các chính sách bảo mật…
Cơ chế ghi nhận
Thực hiện tất cả các ghi nhận liên quan đến tất cả các quá trình tương tác của đối tượng với hệ thống
Góp phần hỗ trợ cho yêu cầu về xây dựng cơ chế định danh
Xử lý bảo mật liên miền
Kiến trúc phải cung cấp mô hình tin cậy nhằm bảo vệ quá trình tương tác giữa các web service trong những miền khác nhau
Khả năng liên kết cao
Khả năng dễ mở rộng, liên kết và tích hợp với các hệ thống khác là một đặc trưng nổi bật trong hệ thống của SOA. Vì thế, yêu cầu kiến trúc bảo mật khi được tích hợp vào sẽ vẫn duy trì tốt nhất đặc trưng này trong SOA
Cho phép kiến trúc của ta có thể tích hợp với những giải pháp, sản phẩm về an toàn dữ liệu khác mà không phải bỏ ra chi phí quá cao.
Tại những vị trí quan trọng thì việc tích hợp, mở rộng hệ thống như giữa nhà cung cấp và các đối tượng sử dụng dịch vụ; giữa nhà cung cấp dịch vụ và cơ sở hạ tầng của kiến trúc bảo mật bên dưới; giữa những kiến trúc bảo mật của những miền khác nhau phải được thiết kế với các yêu cầu về tính ổn định, đồng nhất và hiệu quả dựa trên các chuẩn mở.
Kiểm soát được những thay đổi về yêu cầu bảo mật
Trong các giải pháp bảo mật trước đây, mọi tài nguyên, dịch vụ đều dùng chung một chính sách bảo vệ. Giải pháp dùng chung như thế có chi phí không
cao nhưng hệ thống sẽ quá lỏng lẻo, cứng nhắc, không thích hợp với đặc trưng về tính đa dạng của các tài nguyên và dịch vụ
Trong hệ thống SOA, các dịch vụ ở tầng khác nhau sẽ đòi hỏi chính sách bảo mật khác nhau. Ví dụ, một dịch vụ cần chứng thực theo tên, mật khẩu…
• Khái niệm kiến trúc bảo mật hướng dịch vụ
Mô hình SOSA không hướng đến việc thay thế hoàn toàn các kiến trúc bảo mật hiện có mà muốn đưa ra một giải pháp để liên kết các cơ sở hạ tầng sẵn có.
Nghĩa là chúng ta sẽ sử dụng lại các kỹ thuật, dịch vụ bảo mật hiện có dựa trên những nguyên tắc của SOA để tạo nên một kiến trúc bảo mật hướng dịch vụ mới.Mục tiêu là tạo ra một tầng liên kết bên trên các dịch vụ, công nghệ bảo mật đó.
Các nghi thức, nguyên tắc, cơ chế vận hành trong SOSA không nên lệ thuộc vào một môi trường thực thi cụ thể nào, thay vào đó nên dựa trên những chuẩn chung của “mô hình uỷ thác” (dựa trên độ tin cậy và sự uỷ quyền). Các nghi thức này bao gồm:
Cơ chế định danh một đối tượng, như là đối tượng sử dụng dịch vụ, dịch vụ, tài nguyên, chính sách, nhà cung cấp dịch vụ. Có thể dùng cơ chế định danh URIs (Uniform Resouce Identifier)
Định nghĩa của những dấu hiệu mật và chính sách
- Policy: là một tập hợp các cơ chế xác nhận Policy
- Cơ chế xác nhận (Policy Assertion): một Policy Assertion có thể xem như một quy tắc liên quan đến cách thức hoạt động của hệ thống. Ví dụ như loại security token nào cần được dùng, thông điệp trao đổi có cần được chứng thực, thời gian trao đổi thông điệp còn được bao lâu?...)
- Security Token: có thể là dạng binary (X.509, Kerberos ticket ) hay XML (SAML, XrML).
Nghi thức tạo, trao đổi các token và policy
- Việc phát sinh và phân phối các chính sách nên được thực hiện cùng một lúc với việc tạo ra và gửi thông tin định nghĩa về dịch vụ (WSDL, UDDI)
- Việc tạo và phân phối các security token - Đặt các token trong các thông điệp trao đổi
- Kiểm tra xem các token có phù hợp với yêu cầu.
Tóm lại, hệ thống SOA sẽ phải xây dựng được: các nghi thức chung dùng trong việc trao đổi các token của các đối tượng sử dụng dịch vụ và các nguyên tắc chung xử lý các token đó của phía nhà cung cấp.
• Kiến trúc bảo mật hướng dịch vụ (SOSA)
Đối tượng sử dụng dịch vụ và nhà cung cấp dịch vụ trao đổi các security token thông qua Standard-based Security Info Exchange Platform. Cơ sở hạ tầng bảo mật ở tầng dưới được cung cấp ra ngoài dưới dạng các web service. Các kiến trúc công nghệ giải pháp bảo mật hiện có được tái sử dụng lại thông qua tầng Integration backplane.
Cấu trúc phân tầng của Standard-based Security Info Exchange Platform
Hình 4: Cấu trúc phân tầng của Standard-based Security Info Exchange Platform
Tầng Trusted Communication
Tầng này được xây dựng dựa trên các đặc tả SOAP Foundation, WS – Security và WS – SecureConversation. WS – Security là thành phần chính hỗ trợ để xây dựng một tầng liên kết bền vững, đảm bảo các luồng thông tin được trao đổi một cách an toàn
- WS – Security được thiết kế một cách linh hoạt, được sử dụng như là nền tảng trong việc xây dựng nhiều mô hình bảo mật khác nhau, gồm Public Key Infrastructure, Kerberos và SSL. Đặc biệt, WS – Security còn cung cấp hỗ trợ cho nhiều dạng security tokens, nhiều vùng uỷ thác (trust domain), nhiều định dạng chứng thực và nhiều thuật toán mã hoá.
- WS – Security chỉ định nghĩa thêm cấu trúc mở rộng cho phần đầu của một thông điệp dạng SOAP nhằm mang thông tin bảo mật (chữ ký điện tử, security token, mã hoá…) trong quá trình trao đổi thông điệp với mục đích là phía nhận sẽ tin tưởng vào nội dung của thông điệp cũng như đối tượng gửi thông điệp
- Với WS – SecureConversation, hai bên đều có thể tái sử dụng được ngữ cảnh bảo mật (security context) trong những lần trao đổi thông điệp, tức là hai bên sẽ không cần thực hiện lại những thủ tục như trong lần trao đổi đầu tiên.
Tầng Trusted Service
Tầng này được thiết kế dựa trên các đặc tả WS-PolicyAssertion, WS-Security Policy, WS-Authorization, WS-Privacy, WS-PolicyAttachment, WS-Policy.
Tầng này cho phép xây dựng các cơ chế tạo ra các Policy mở rộng và gắn kèm các thông tin này vào phần mô tả thông tin của web service
- WS-Policy: định nghĩa các mô hình cơ bản của policy, policy satement và các cơ chế xác nhận policy
- WS-PolicyAssertion : định nghĩa một vài cơ chế xác nhận policy tổng quát
- WS-PolicyAttachment: định nghĩa cách gắn một policy vào một dịch vụ hoặc trực tiếp bằng cách nhúng vào thông tin trong WSDL, hay gián tiếp thông qua UDDI
- WS-Security Policy: định nghĩa các cơ chế xác nhận policy tương ứng cho các thuộc tính trong WS-Security, như là các yêu cầu về toàn vẹn thông điệp, yêu cầu về độ tin cậy của thông điệp, yêu cầu về loại security token…
Đối tượng sử dụng dịch vụ phải lấy được các thông tin này để đáp ứng được các yêu cầu về bảo mật mà dịch vụ đưa ra
Tầng Trusted Managerment Web
Tầng này được xây dựng dựa trên các đặc tả WS-Federation và WS-Trust. Hai tầng Trusted Communication và Trusted Service đảm bảo cho đối tượng sử dụng và cung cấp dịch vụ tương tác với nhau trong một môi trường bảo mật và tin cậy.
Tuy nhiên chúng cần phải có giả thiết rằng Cả hai phía đều sử dụng cùng một công nghệ, một kỹ thuật bảo mật; cả hai phía đều tin tưởng vào cùng một domain. Điều này có nghĩa là vấn đề sẽ phát sinh khi các bên tương tác thuộc
những domain khác nhau, sử dụng công nghệ mã hoá khác nhau. Giải quyết vấn đề này là nhiệm vụ của tầng Trusted Managerment Web
- WS – Trusted
o WS-Trusted đưa ra một khái nhiệm gọi là Security Token Service (STS). Nhiệm vụ của thành phần này là cấp phát, kiểm tra và chuyển đổi các loại security token khác nhau khi có các yêu cầu.
o Về cơ bản, vai trò của một STS rất giống với một tổ chức chứng thực PKI (PKI Certifycate Authority), tuy nhiên nó vượt trội hơn với hai đặc điểm nổi bật :
Nó cấp phát tất cả các loại token (về quyền, vai trò,…) chứ không chỉ là token dùng để định danh.
STS không chỉ đơn giản là cấp phát và chứng thực các token mà còn có khả năng thực hiện việc chuyển đổi các token với nhau (ví dụ như X.509 Certifate -> Kerberos). Đây chính là tính năng khiến nó có vai trò làm trung gian trong quy trình tương tác giữa các đối tượng
o Vai trò của STS là kết nối các hệ thống bảo mật đơn lẻ tạo thành một liên kết thống nhất với nhau.
o Các STS phải được thiết kế một cách trong suốt (transparent) với đối tượng cử dụng dịch vụ trong quá trình tương tác. Ta gọi mạng các STS này là Trusted Management Web. Trusted Managerment Web có thể được cấu thành bởi nhiều mạng các STS khác nhau. Mỗi mạng STS cung cấp một dịch vụ tin cậy khác nhau như là máy chủ chứng thực sẽ cung cấp khả năng chứng thực của một STS trong mạng các STS, hay máy chủ quản lý về quyền sẽ có nhiệm vụ kiểm tra về quyền của của nhiều STS
- WS – Federation
WS-Federation sẽ giải quyết các vấn đề liên quan đến việc quản trị các thành
o Nên chọn mô hình nào cho các mắt xích STSs?
o Việc quản lý chu kỳ hoạt động các thành phần của kiến trúc (STS, Policy, cơ chế bảo mật ở tầng dưới…)
o Quản lý thông tin trạng thái của các policy và token phân tán, cụ thể là cơ chế ghi nhớ lại một lượng thông tin nào đó. Từ đây sẽ phát sinh một vấn đề mới là vấn đề xử lý việc đồng nhất về thông tin. DNS có thể xem là mô hình cho việc giải quyết vấn đề này. Các DNS server sẽ lưu lại kết quả phân giải để khi xử lý yêu cầu tiếp theo, nếu yêu cầu cùng một kết quả thì nó sẽ đáp ứng ngay mà không phải tìm trong các root server.
o Hỗ trợ cho quá trình lưu lại các ghi chú về thông tin trạng thái, kết quả xử lý…
1.4.3. Giới thiệu một số chuẩn bảo mật trong XML
• WS-Security
Là chuẩn được đề xuất dưới sự hợp tác của hãng IBM, Microsoft và Verisign. Hiện chuẩn này đã được tổ chức OASIS thông qua và đang tiếp tục phát triển
WS-Security là một chuẩn an toàn bao trùm cho SOAP và cả những phần mở rộng của SOAP
- Sử dụng các sercurity token trong phần đầu của các thông điệp SOAP để hỗ trợ cho việc định danh và chứng thực
- Sử dụng XML-Encryption để đảm bảo độ tin cậy cho dữ liệu
- Sử dụng XML-Signatures đảm bảo tính toàn vẹn và xác thực của dữ liệu WS-Sercurity cũng bao gồm cả việc xác định xem chèn những dữ liệu nhị phân khác biệt và dấu hiệu của XML sercurity trong phần đầu WS – Sercurity cho mục đích xác thực về phân quyền.
- Username và password. : định nghĩa một khách hàng của WS có thể cung cấp một username khi có một phiên cần xác thực ; username có thể được gắn với password mảng băm
- X.509 Certificate: Một cấu trúc dữ liệu được đánh dấu thiết kế để gửi một khoá công cộng tới một địa điểm nhận.
- Kerberos ticket: phân quyền và xác nhận phiên làm việc - SAML (Sercurity Assertion Markup Language).
- REL (Right Expression Language) là ngôn ngữ được thêm vào header của WS-Sercurity để phân quyền
- XCBF: ngôn ngữ XML Common Biometric Format định nghĩa cho việc xác thực với WS – Sercurity.
• XML-Signature
Được chứng thực bởi tổ chức W3C. Chuẩn này quan tâm đến cú pháp và cách xử lý trong việc chứng thực một thành phần nào đó trong tài liệu XML bằng các công nghệ chứng thực khoá đồng bộ hay bất đồng bộ
• XML-Encryption
• Security Assertion Markup Language (SAML) Chuẩn này được đưa ra bởi OASIS.
SAML định nghĩa một nền tảng cho việc trao đổi các thông tin bảo mật dưới dạng XML. Những thông tin bảo mật này có thể là: thông tin chứng thực, các quyết định về phân quyền, hoặc là thuộc tính của các đối tượng được lưu trữ ở dạng XML và được cấp phát bởi nơi cung cấp chứng thực SAML
SAML cũng định nghĩa các giao thức, quy tắc trong quá trình vận chuyển các thông tin bảo mật