Sự thỏa thuận với bảo mật là không có gì mới. Đối với tất cả các khía cạnh đà đề cập ở trên về tính bảo mật, SOA sử dụng các phương pháp tiếp cận tương tự được sứ dụng với các hệ thống phân tán:
- Đối với sự xác thực và ủy quyền, thường cần thông tin về mã người dùng và mật khẩu (mặc dù có những chuẩn xác thực khác, như Kerberos, certificates, hardware
tokens,...). Đối với mã người dùng, đặc trưng ở đây là một vài dạng của hành động gián tiếp bởi vậy những người dùng có thể được gán các quyền; các quyền như là kha năng đề gọi một dịch vụ hoặc khả năng để thấy một kết quả đã được kết hợp với các quvên khác. Neu có một dịch vụ trung tâm để quán lý các người dùng và các thông tin cơ bán của người dùng, điều này thường được gọi là một sự cung cấp nhận dạng.
- Đôi với sự tin cân và tính toàn vẹn, các nội dung thông thường như sự mã hóa và chù ký điện tử đã được sử dụng.
Đối với các nội dung này, bảo mật SOA là không khác bảo mật trong một vài dạng khác của sự sử dụng máy tính phân tán. Tuy nhiên, có một vài khía cạnh đặc biệt của SOA dưới đây.
□ Khá năng cộng tác đối vói bảo mật
Một khái niệm quan trọng của SOA là khả năng cộng tác cao. Đối với các khái niệm của tích hợp ứng dụng doanh nghiệp (EAI), nó nên được dễ dàng để kết nối tới các hệ thống khác. Trong SOA, ý tưởng là để thay thế các giải pháp kết nối cá nhân cho mồi cặp của hệ thống với một ESB chung, bởi vậy một vài hệ thống đã được kết nối tới ESB này để được kết nối tới mồi hệ thống khác mà cũng được kết nối tới nó.
Như một hệ quả của phương pháp tiếp cận này, các bức tường lửa tự nhiên đã được tạo ra bằng cách sử dụng những kênh truyền thông khác nhau và các giao thức khác nhau là không sẵn dùng. Khi được kết nối tới một ESB, bởi mặc định hệ thống là mở. Do đó, để bảo vệ dữ liệu dễ hỏng, ta phải hạn chế các khả năng của người tiêu dùng đế gợi tất cả các dịch vụ và xem tất cả các kết quả trả về. Điều này thường là một sự thúc đây cho khái niệm bảo mật bên trong một ESB.
□ Tính không đồng nhất và bảo mật
SOA là một khái niệm cho sự thỏa thuận với các quy trình nghiệp vụ đã được phân tán trên các hệ thống không đồng nhất khác nhau. Các công nghệ bảo mật hiện có và các chính sách cho các hệ thống này là có khả năng khác nhau. Do đó, ta đương đầu với thách thức của sự giới thiệu một khái niệm bảo mật chung trên nhiều khái niệm bảo mật khác nhau hiện có. Quy trình này bắt đầu với sự khác nhau của mà người dùng và trả về kết quả trong sự trừu tượng khác nhau và các quy trình để giới thiệu các quyền và các thông tin cơ bản người dùng.
□ Các quy trình phân tán và nhiều tầng của sự trừ u tượng
Vấn đề quan trọng nhất là SOA dẫn tới nhiều tầng khác nhau của sự trừu tượng. Khi mồi dịch vụ trừu tượng chức năng nghiệp vụ của một tầng thấp hơn, nó cũng phái trừu tượng danh tính người dùng từ ứng dụng bên dưới.
Kết hợp với nội dung bảo mật không đồng nhất của các backend riêng lẻ, điều này dẫn tới một thực tế rằng đó là một chặng đường dài từ yêu cầu ban đầu cho một quy trình nghiệp vụ tới các hệ thống để thỏa thuận với yêu cầu này.
Hình dưới đây chỉ ra một ví dụ có thể: một khách hàng phải bắt đầu một tiến trình sử dụng một cổng dịch vụ, tiến trình đó phải chạy trên các tầng khác nhau (các dịch vụ
32
tiến trình, các dịch vụ tông hợp, các dịch vụ cơ bán) và các backend khác nhau; ngoài ra một trung tâm cuộc gọi hoặc tác tử văn phòng phía sau phải được liên quan trong sự thực hiện một vài bước của tiến trình này.
o r s u r r e r Forte! Server * P'Ciess L ĩ Ẹ ụ ắ ________û—1 / ______ S ê' V I l e / 5c ' VI Lê ....ê l — ... ~
B asi; B a il; Basic
S ê ' v K r 1 î c f \ ' K t S c ' v K c !! 1e r te r A g e rt P-iêSS «'vKe g --- S c ' v l l ê B a il; 5 c ' v i l e ”7 --- B asil S6'vll€ "X" T Basil ^ jr
Backend Backend B a;*e n d
13Hình 1.9: Nhiều bước nhảy ngan giữa người dùng cuối và các hệ thống backend
Có nhiều tầng dẫn tới hai thành phần quan trọng:
- Nó là không rõ ràng cái nào hệ thống xác thực và ủy quyền một người dùng.
- Sự tin cẩn phải được chắc chắn qua không chỉ một mà nhiều kết nối và các nút bôn trong.
Thảo luận đầu tiên là tại sao nó không rõ ràng cái nào hệ thống xác thực một người dùng và ủy quyền các hành động. Trách nhiệm này là của hệ thống backend, írontend, hoặc cả hai? Một mặt, nó là tầm quan trọng của hệ thống backend để quyết định người dùng nào đã được cho phép để thực hiện các chức năng và truy vấn dữ liệu. Lý do là mỗi backend chịu trách nhiệm cho dữ liệu của nó, và thường thường không phải tất cả các người dùng đã được cho phép để thực hiện tất cả các chỉnh sửa hoặc đế xem tất ca dữ liệu. Mặt khác nó là tầm quan trọng của hệ thống ííontend để ủy quyền các chức năng của người dùng, cung cấp hoàn toàn tính nhất quán và tránh những người dùng không được cho phép để gọi.
Đe có thể bao phủ cả hai tầm quan trọng, ý tưởng là cả hệ thống frontend và backend phải chia sẻ các sự nhận dạng tương tự (như mã người dùng) và những thông tin cơ bán được kết hợp của chúng và các quyền. Điều này hàm ý rằng những nhận dạng và những thông tin cơ bản phải được vượt qua tới hệ thống backend.
Bây giờ chúng ta đến vấn đề thứ hai, vấn đề phải làm với sự tin cẩn và tính toàn vẹn. Neu nhiều hệ thống đã được liên quan giữa hệ thống frontend và backend, nó là không đủ đế tạo kết nối vật lý giữa hai hệ thống bảo mật. Khi có nhiều kết nối với các nút liên quan, ta cần để đảm bảo sự bảo mật “end-to-end” của dừ liệu cụ thể. Ví dụ, nếu truyền dừ liệu như mật khẩu, số thẻ tín dụng, hoặc các chi tiết tài khoản, thường chi hệ thống frontend và backend nên được cho phép để xem thông tin này. Một vài quy trình thỏa thuận với dữ liệu này có thể băng qua nó nhưng không nên thực sự xem nó. Vì lý do này, các kỹ thuật bảo mật thỏa thuận với tầng truyền vận là thường không đu. Thực tế, phương pháp tiếp cận internet thông thường như tầng bảo mật socket (Secure Sockets Layer) cho web service là không đủ.
□ Thỏa thuận về tính tin cậy và tính toàn vẹn
Trong thực tế có thể thỏa thuận với tính tin cậy và tính toàn vẹn của dừ liệu truyền thông bởi các dịch vụ dựa trên tầng truyền vận hoặc tầng thông điệp
Bảo mật ở tầng truyền vận
Một ví dụ điển hình là mã hóa các cuộc gọi web service thông qua SSL (sử dụng giao thức https thay vì http). Cách tiếp cận này là dễ dàng và rẻ, tuy nhiên nó chỉ trợ giúp khi dữ liệu nhận được truyền thông từ hệ thống tới hệ thống. Đây là một mã hóa điếm tới điểm thay vì một mã hóa từ điểm đầu tới điểm cuối. Bên trong các nút và giữa các tầng khác nhau, dữ liệu là vẫn dễ đọc.
Bảo mật tầng thông điệp
Bảo mật tầng thông điệp là bảo mật bên trong những thông điệp thực sự đang được gửi. Điều đó là, ta sử dụng giao thức của cơ sở hạ tầng trong một cách mà không ai cỏ thể đọc được thông điệp hoặc chỉnh sửa chúng mà không bị phát hiện. Với phương pháp tiếp cận này, ta phải định nghĩa một vài ràng buộc đặc biệt trong định dạng thông điệp của ta bởi vậy tất cả các endpoint đó có thể truyền thông với mỗi cái khác. Trong khi gửi thông điệp phải được mã hóa hoặc chứng thực tất cả dừ liệu hoặc các phần cua nó, bên nhận giải mã thông điệp và kiểm tra lại chứng chỉ. Một ví dụ điến hình là mã hóa của web service với các thuộc tính thêm vào đã được định nghĩa bởi các chuấn như WS-Security.
Chú ý rằng ta vẫn có thể gửi thông điệp theo nhiều hướng. Vì lý do này, ta thường mã hóa chỉ dừ liệu nghiệp vụ của thông điệp. Một vài thông tin để làm với việc gưi dừ liệu bên trong cơ sở hạ tầng đã được viện dẫn như một cách rằng nó có thế được xứ lý phân biệt từ một trọng tải. Các thông tin được định vị trong phần đầu của thông điệp. Như thảo luận dễ dàng hơn, bảo mật tầng thông điệp thường thích hợp hơn bởi vì I1Ó dẫn tới bảo mật từ điểm cuối tới điểm cuối (end-to-end), trong khi báo mật tầng truyền
34
vận chỉ dần tới sự bảo mật điểm tới điêm. Tuy nhiên, tầng truyền vận thường hồ trợ tối hơn và có hiệu năng tốt hơn. Ngoài ra, sự duy trì, sự phân tán, và ký giấy chứng nhận có thề trở thành một thách thức.
Một điều chú ý nữa là có thế không cung cấp bất kỳ sự bảo mật bên trong ESB, hoặc trên tầng truyền vận hoặc trên tầng thông điệp. Bảo mật sau đó trở thành một vấn đề của tâng nghiệp vụ. Điều đó có nghĩa là những nhà cung câp và những người tiêu dùng phải thỏa thuận với các khía cạnh bảo mật bên trong các API nghiệp vụ. Ta định nghĩa tham số dịch vụ để trao đổi các dấu hiệu hoặc mã hóa dữ liệu (tất nhiên, định dạng chính xác phải được chỉ rõ trong họp đồng dịch vụ), v ẩn đề với phương pháp tiếp cận này là nhiều thành phần phải nỗ lực lớn để thực hiện các yêu cầu tương tự. Trong một vài trường họp, nó nên được rõ ràng tới tất cả các dịch vụ tham gia như thế nào đề thỏa thuận với sự bảo mật. Điều này là một ví dụ tốt của thực tế rằng cơ sớ hạ tầng và kiến trúc của SOA phải khớp với nhau. Chỉ cung cấp cơ sở hạ tầng, mà có thế
tham gia m ột mình với các câu hỏi bảo mật, là m ột phương pháp rất kém và nguy
hiểm.