5. Manage và Secure
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).
- 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.
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
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ý…
