Giới thiệu kiến trúc bảo mật hướng dịch vụ

Một phần của tài liệu Nghiên cứu kiến trúc hướng dịch vụ (Service - oriented architecture) và giải phá của Oracle (Trang 26 - 34)

5. Manage và Secure

1.4.2. Giới thiệu kiến trúc bảo mật hướng dịch vụ

Mt s yêu cu đặt ra ca kiến trúc

Chng thc

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

Phân quyn

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 số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 tồ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 cy

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.

Tồn vn d liu

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ĩ mt cơ chế qun 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 nhn

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ý bo mt liên min

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 tồ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ở.

Kim sốt được nhng thay đổi v yêu cu bo mt

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 nim kiến trúc bo mt hướng dch v

Mơ hình SOSA khơng hướng đến việc thay thế hồn tồ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 ca nhng du hiu mt 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 li, 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 bo mt hướng dch 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 ngồ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: Cu trúc phân tng ca Standard-based Security Info Exchange Platform

Tng 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 tồ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 tốn mã hố.

- 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ã hố…) 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.

Tng 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ề tồ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

Tng 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ã hố 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ĩ cp phát tt c các loi token (v quyn, vai trị,…) ch khơng ch là token dùng đểđịnh danh.

STS khơng chỉđơn gin là cp phát và chng thc các token mà cịn cĩ kh năng thc hin vic chuyn đổi các token vi 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ý…

Một phần của tài liệu Nghiên cứu kiến trúc hướng dịch vụ (Service - oriented architecture) và giải phá của Oracle (Trang 26 - 34)

Tải bản đầy đủ (PDF)

(41 trang)