Mô hình lập trình SOA để triển khai thực hiện các dịch vụ Web, Phần 7: Bảo đảm an ninh các ứng dụng hướng dịch vụ

Việc bảo đảm an ninh các ứng dụng trong một kiến trúc hướng dịch vụ (SOA) là một thách thức, bởi vì việc ghép lỏng (loose coupling), là đặc trưng của SOA, có thể bộc lộ ra các điểm yếu của các triển khai thực hiện bảo đảm an ninh hiện có. Các giải pháp sau đây bao gồm các mô hình tin cậy được định nghĩa đúng đắn, dựa trên các dạng kiểm chứng chấp nhận được cũng như sự tin tưởng vào các chính sách an ninh các dịch vụ web và các thông lệ thực hành tốt nhất về kỹ thuật bảo mật.

Anthony Nadalin, Kiến trúc sư trưởng về an ninh, IBM

Ông Nadalin là kiến trúc sư trưởng về bảo đảm an ninh của Tập đoàn phần mềm IBM. Với tư cách là một kỹ sư xuất sắc, ông chịu trách nhiệm về việc thiết kế và phát triển cơ sở hạ tầng bảo đảm an ninh. Ông giữ vai trò liên lạc chính về bảo đảm an ninh với bộ phận JavaSoft của Sun Microsystems để hợp tác phát triển và thiết kế bảo đảm an ninh Java. Trong sự nghiệp hoạt động 24-năm của mình với IBM, ông đã giữ các vị trí sau đây: Kiến trúc sư lãnh đạo an ninh cho VM/SP của IBM, kiến trúc sư an ninh cho AS/400 và kiến trúc sư an ninh cho OS/2 của IBM. Ông cũng là tác giả và là đồng tác giả của hơn 40 bài viết trong tạp chí kỹ thuật và các báo cáo tại hội nghị và đã xuất bản một số cuốn sách về bảo đảm an ninh Java và Internet. Ông là tác giả và biên tập viên của nhiều đặc tả kỹ thuật bảo đảm an ninh dịch vụ Web.



Nataraj Nagaratnam, Kiến trúc sư về An ninh, IBM

Tiến sĩ Nagaratnam là kiến trúc sư trưởng của quản lý nhân dạng và kiến trúc sư bảo mật hàng đầu của Chiến lược Kỹ thuật và Cơ sở hạ tầng bảo đảm an ninh theo yêu cầu. Với tư cách là một thành viên ban lãnh đạo kỹ thuật cao cấp, ông chỉ đạo các hoạt động thiết kế và kiến trúc bảo đảm an ninh trên toàn bộ các sản phẩm và các nền tảng của IBM. Trong sự nghiệp của mình tại IBM, ông đã là kiến trúc sư an ninh hàng đầu về Máy chủ ứng dụng WebSphere® của IBM và kiến trúc sư an ninh hàng đầu của nền tảng WebSphere của IBM. Ông đã lãnh đạo và tham gia các hoạt động về chuẩn mở khác nhau trong các tổ chức ban hành chuẩn bao gồm JCP, OASIS, WS-I và GGF. Ông là tác giả và đồng tác giả của nhiều bài viết trên tạp chí, các báo, các cuốn sách, và các đặc tả kỹ thuật bảo đảm an ninh, bao gồm cuốn sách Bảo đảm an ninh Java cho doanh nghiệp



Maryann Hondo, Lãnh đạo nhóm An ninh, IBM

Bà Hondo là người lãnh đạo các tiêu chuẩn bảo đảm an ninh dịch vụ Web trong nhóm Công nghệ nổi dần (Emerging Technology) của Tập đoàn phần mềm IBM. Bà đã tham gia vào Lotus® của IBM năm 1996 với tư cách là kiến trúc sư an ninh cho Lotus E-Suite, tham gia vào việc phát triển JAAS. Quá trình công tác của bà bao gồm làm việc cho Hewlett Packard về DCE và đăng nhập một lần (single signon) dựa trên thẻ thông minh PKI; làm việc cho Công ty Thiết bị kỹ thuật số (Digital Equipment Corporation – DEC) về hệ điều hành B1/CMW; và làm việc cho AT & T Bell Labs về B2 UNIX. Bà là một đồng tác giả của các đặc tả kỹ thuật Đàm thoại bảo đảm an ninh, tin cậy, chinh sách, an ninh –WS, đã được IBM và các đối tác kinh doanh khác công bố trong các năm 2002-2004



31 07 2009

Mở đầu

Việc bảo mật truy cập tới các thông tin là điều cơ bản cho bất kỳ ứng dụng nào. Bảo đảm an ninh thậm chí còn trở nên trọng yếu hơn nữa cho các triển khai thực hiện áp dụng các nguyên tắc SOA bởi vì sự ghép lỏng các dịch vụ và vì các ứng dụng và hoạt động của ứng dụng vượt qua các ranh giới tổ chức. Một môi trường như thế thường bộc lộ các hạn chế hay sự mong manh của các triển khai thực hiện bảo đảm an ninh hiện có.

Bất kể các hiệu quả mà việc phát triển dựa theo mô hình và việc quản lý dịch vụ dựa trên SOA mang lại, các ứng dụng kinh doanh vẫn phải tiếp tục việc bảo đảm an ninh thông tin. Chỉ riêng việc bảo đảm an ninh vòng ngoài thôi (chẳng hạn như tường lửa và định tuyến) là không đủ, bởi vì một hoạt động kinh doanh theo yêu cầu cần phải có khả năng thiết lập và tước bỏ các mối quan hệ tin cậy luôn biến động khi mà các mối quan hệ giữa các đối tác, các khách hàng, các nhân viên luôn tiến triển. Vì thế, một hoạt động kinh doanh theo yêu cầu an toàn cần một cơ sở hạ tầng linh hoạt, tùy chỉnh được để nó có thể thích ứng với các yêu cầu và các quy định mới. Để cung cấp tính linh hoạt như thế, không nên buộc cố định các chính sách vào cơ sở hạ tầng; cần triển khai thực hiện các yêu cầu của mô hình an ninh thông qua một cơ sở hạ tầng dựa theo chính sách -- đây không phải là nhiệm vụ đơn giản.

Bài viết này giải thích cách làm thế nào để các ứng dụng kinh doanh có thể sử dụng các khả năng bảo đảm an ninh của một cơ sở hạ tầng bảo đảm an ninh theo yêu cầu và các nguyên lý thiết kế cho ra đời một mô hình lập trình để bảo đảm an ninh các ứng dụng hướng dịch vụ.


Các ứng dụng kinh doanh và cơ sở hạ tầng bảo đảm an ninh

Đảm bảo an ninh cho việc tích hợp và truy cập các ứng dụng kinh doanh và thông tin kinh doanh thường đạt được thông qua việc xác thực, cấp quyền hạn và quy trách nhiệm. Một doanh nghiệp tiếp cận việc quản lý xác thực, cấp quyền hạn và quy trách nhiệm như thế nào được quyết định chủ yếu bởi quan điểm của doanh nghiệp về các mối quan hệ tin cậy đang có giữa các khách hàng, các nhân viên và các đối tác; ảnh hưởng của các mối quan hệ ấy với việc đảm bảo an toàn cho các ứng dụng kinh doanh; và tầm quan trọng tương quan và việc bảo đảm an toàn của các ứng dụng này.

Khi thông tin nhạy cảm được trao đổi giữa các đối tác kinh doanh, nó phải được bảo đảm an toàn. Nó cũng có thể cần phải được lưu giữ bền vững một cách an toàn. Tính nguyên vẹn của nguyên bản thông báo cần phải được bảo đảm (ví dụ, thông qua các dịch vụ công chứng) để khi cần thiết cho phép xác nhận hiệu lực, kiểm định và chống chối bỏ. Thông tin nhạy cảm có thể cần phải được mật mã hóa để bảo mật hay áp chữ ký số hóa để bảo đảm tính nguyên vẹn. (Các chữ ký số hóa cũng đóng một vai trò trong việc chống chối bỏ). Một thiết kế bảo đảm an ninh SOA đầy đủ phải giải quyết không chỉ việc bảo mật mức truyền dẫn và mức thông báo, mà còn phải bảo đảm an ninh cho các nội dung lưu giữ lâu dài, tuân thủ các quy định của chính phủ và các thông lệ của ngành công nghiệp.

Về cơ bản, các mối quan hệ tin cậy giữa một doanh nghiệp và các nhân viên, các khách hàng và các đối tác của nó chi phối việc xác định và buộc thực thi các chính sách an ninh và mức độ bảo mật phải được tuân theo. Các công nghệ có liên quan, như là các chứng thực và các khóa mật mã, có thể được sử dụng để phản ánh và quản lý các mối quan hệ tin cậy này. Các công cụ có thể được dùng để mô hình hóa và xác định rõ các mối quan hệ tin cậy giữa các đối tác kinh doanh, giữa những người tiêu dùng và doanh nghiệp, v.v và có thể chuyển các định nghĩa quan hệ tin cậy thành các công nghệ phù hợp với môi trường CNTT.


Mô hình bảo đảm an ninh SOA

Mô hình bảo đảm an ninh SOA dựa trên một quá trình mà trong đó một dịch vụ web có thể đòi hỏi gửi một thông báo đến để kiểm chứng một tập hợp các lời tự khai nhận. Ví dụ về các lời tự khai nhận gồm tên, khóa, giấy phép và năng lực. Dựa trên những chứng cớ đã được cung cấp, các mô hình tin cậy thích hợp được áp dụng giữa các bên yêu cầu, điểm cuối dịch vụ và một tập hợp những phương tiện trung gian có thể có.

Một thông báo có thể đi ngang qua một số phương tiện trung gian nằm giữa bên yêu cầu và một dịch vụ đích. Việc quản lý bảo đảm an ninh xuyên suốt đầu này đến đầu kia phải xem xét đến các mô hình tin cậy giữa bên yêu cầu, các phương tiện trung gian và dịch vụ đầu cuối (bên cung cấp dịch vụ), như minh họa trong Hình 1.

Hình 1. Các mô hình tin cậy từ bên yêu cầu đến nhà cung cấp dịch vụ thông qua các phương tiện trung gian
Các mô hình tin cậy

Các phương tiện trung gian truyền dẫn và mạng máy tính (ví dụ, các tường lửa, các bộ định tuyến, và các máy chủ ủy quyền (proxy)) nói chung là không đáng tin cậy đối với việc xử lý thông báo. Tất cả các thông báo đang truyền dẫn cần được bảo vệ khỏi sự can thiệp của các phương tiện trung gian không tin cậy.

Đặc tả Bảo đảm an ninh các dịch vụ Web (WSS) của OASIS cung cấp sự bảo vệ cho các thông báo theo Giao thức truy cập đối tượng đơn giản (Simple Object Access Protocol-SOAP) đang truyền dẫn. Bạn có thể sử dụng WSS để bảo vệ tính xác thực, tính nguyên vẹn và tính bí mật của các thông báo khỏi các phương tiện trung gian truyền dẫn và mạng không tin cậy.

Hình 2. Liên hiệp và quan hệ tin cậy của các bên môi giới trung gian thông báo
các bên môi giới trung gian thông báo

Không phải tất cả các phương tiện trung gian là không tin cậy. Cổng các dịch vụ web và dịch vụ hòa giải của kênh dịch vụ doanh nghiệp là những ví dụ về các bên trung gian chuyển đổi thông báo mà chức năng của chúng trong SOA dính líu đến việc rà soát kỹ và, trong một số trường hợp, sửa đổi các nội dung thông báo [xem Phần 4 trong loạt bài này, "Giới thiệu về Kênh Dịch vụ Doanh nghiệp của IBM" (developerworks, 2005)]. Khi thiết kế cơ sở hạ tầng bảo đảm an ninh SOA của bạn, hãy xem xét việc lập kế hoạch để cho phép một số các phương tiện trung gian được tin cậy.

Một phương tiện trung gian đáng tin cậy khác có thể là một trình môi giới thông báo, xử lý các mối quan hệ tin cậy giữa các bên yêu cầu và một máy chủ dịch vụ ứng dụng. Trong thiết kế này, các trách nhiệm bảo đảm an ninh được phân chia giữa trình môi giới và các điểm cuối dịch vụ. Như được hiển thị trong Hình2, phương tiện trung gian thông báo sẽ chịu trách nhiệm về bảo mật mức-thông báo, liên hiệp các nhân dạng giữa các môi trường của bên yêu cầu và bên cung cấp dịch vụ và quản lý các mối quan hệ tin cậy giữa bên yêu cầu và nhà cung cấp dịch vụ. Dịch vụ sẽ chỉ giữ trách nhiệm đáp ứng các yêu cầu an ninh đặc thù của dịch vụ, ví dụ như thiết lập (ánh xạ tương ứng, liên hiệp bởi phương tiện trung gian) nhân dạng để truy cập vào dịch vụ, thiết lập tính nguyên vẹn và tính bí mật của các dữ liệu đặc thù của ứng dụng trong nội dung thông báo. Bằng cách phân tách mã cơ sở hạ tầng mong manh hoặc phức tạp ra khỏi các ứng dụng kinh doanh và ủy quyền cho thùng chứa (container) làm việc này, một cách tiếp cận dựa trên SOA tới việc bảo đảm an ninh có thể cải thiện tính linh hoạt và làm giảm khả năng xảy ra các rủi ro.


Bảo đảm an ninh thông báo

Đặc tả kỹ thuật WSS cũng cung cấp một tập hợp các cơ chế cơ sở mức thông báo dành cho tính nguyên vẹn, tính bí mật và việc xác thực để có thể giúp các nhà phát triển dịch vụ Web bảo đảm an toàn cho các trao đổi qua SOAP. Những cơ chế này có thể được kết hợp theo nhiều cách khác nhau để xây dựng một loạt các các mô hình an ninh rộng lớn khi sử dụng một loạt các công nghệ mật mã hóa.

WSS cũng cung cấp một cơ chế mở rộng được để kết hợp các thẻ bài (token) an ninh kèm các thông báo; chúng thích ứng với một loạt các cơ chế và khuôn dạng xác thực và cấp quyền khác nhau. Ví dụ, khách hàng có thể cung cấp bằng chứng về nhân dạng của mình và một bản xác nhận đã ký khẳng định rằng họ có một chứng nhận kinh doanh cụ thể nào đó. Một dịch vụ web nhận được một thông báo như vậy sau đó có thể xác định xem nó tin tưởng vào tự khai nhận của khách hàng hay không và tin tới mức độ nào.

Các lời tự khai nhận của thẻ bài an ninh có thể được chứng thực bởi một người có thẩm quyền hoặc bỏ qua không được chứng thực. Một tập hợp các lời tự khai nhận được chứng thực thường được biểu diễn như là một thẻ bài an ninh , được áp chữ ký số hoặc được bảo vệ bằng mật mã bởi người có thẩm quyền. Một ví dụ quen thuộc về thẻ bài an ninh có chữ ký là giấy chứng nhận X.509; nó xác nhận một kết buộc giữa nhân dạng của một người nào đó với một khóa công khai. Các thẻ bài an ninh có thể được "đẩy", hay là được mang theo, trong một thông báo hoặc được biểu diễn bằng một tham chiếu sao cho người nhận có thể "rút" các lời xác nhận từ người có thẩm quyền.

Vì thẻ bài an ninh rất có ích trong một miền tin cậy, cần phải có cách để khớp lại với phạm vi của một miền tin cậy. Nó có thể được khớp lại bằng tay, theo một thỏa thuận hoặc bằng cách triển khai thực hiện một bộ các quy tắc buộc tuân theo các chính sách tin cậy. Vì thế một lời tự khai nhận không được chứng thực có thể được tin cậy nếu có bất kỳ mối quan hệ tin cậy được thiết lập nào giữa người gửi và người nhận. Ví dụ, một yêu sách không được chứng thực mà người gửi là Bob là đủ cho một người nhận nào đó tin tưởng rằng người gửi thực sự là Bob nếu người gửi và người nhận sử dụng một kết nối được tin cậy, mà họ đã thiết lập kết nối đó thông qua một mối quan hệ tin cậy ở bên ngoài. Trong ví dụ này, sự tồn tại của kết nối tin cậy này có thể là bằng chứng đầy đủ.

Việc bảo vệ nội dung thông báo trước các truy cập bất hợp pháp (tính bí mật) hoặc các sửa đổi bất hợp pháp (tính nguyên vẹn) là các mối quan tâm an ninh hàng đầu. Đặc tả kỹ thuật WSS cung cấp một phương tiện để bảo vệ một thông báo bằng cách mật mã hóa và/hoặc áp chữ ký số cho phần thân, cho phần đầu, cho phần đính kèm hoặc bất kỳ tổ hợp nào của các phần ấy.

Việc xác thực các yêu cầu được dựa trên sự kết hợp của các tùy chọn đảm bảo an ninh được cung cấp bởi hệ thống mạng và đường truyền dẫn và thông tin (các lời tự khai nhận) đã được chứng minh trong thông báo, một kỹ thuật được biết đến nhiều hơn dưới cái tên xác thực nguồn gốc của thông báo. Các bên yêu cầu có thể xác thực những người nhận bằng cách sử dụng đảm bảo an ninh được cung cấp bởi hệ thống mạng và đường truyền dẫn, các lời tự khai nhận đã được chứng minh trong các thông báo và việc mật mã các yêu cầu, sử dụng một khóa mà người nhận đã biết.


Mô hình tin cậy

Một cách để biểu thị việc sử dụng một thẻ bài an ninh đúng quyền hạn là áp thêm chữ ký số, sử dụng khóa bí mật đi kèm (từ một thẻ bài chứng minh có quyền sở hữu). Điều này cho phép bên yêu cầu chứng minh một tập hợp các lời tự khai nhận cần thiết bằng các thẻ bài an ninh đi kèm -- ví dụ như Cơ sở hạ tầng khóa công khai dành cho các giấy chứng nhận X.509 (PKIX) hoặc các giấy chứng nhận X.509 -- với các thông báo này.

Nếu bên yêu cầu không có (các) thẻ bài cần thiết để chứng minh các lời tự khai nhận đòi hỏi phải có đối với một dịch vụ, nó có thể liên lạc với những người có thẩm quyền thích hợp (mà chúng tôi sẽ gọi là các dịch vụ thẻ bài an ninh ) và yêu cầu các thẻ bài cần thiết với các lời tự khai nhận phù hợp. Các dịch vụ thẻ bài an ninh làm nên một cơ sở tin cậy bằng cách phát hành một loạt các thẻ bài an ninh có thể được sử dụng để môi giới các mối quan hệ tin cậy giữa các miền tin cậy khác nhau.

Một cơ chế có thể sẽ là sử dụng một giao thức thách thức-đáp ứng như được định nghĩa trong WS-Trust (xem Tài nguyên để biết thêm thông tin về đặc tả kỹ thuật của WS-Trust). Một dịch vụ Web sử dụng giao thức này dành cho các thách thức bổ sung thêm đối với bên yêu cầu để đảm bảo sự tươi mới của thông báo và kiểm tra xem nó có được quyền sử dụng thẻ bài an ninh hay không. Mô hình này được minh họa trong Hình 3, cho thấy rằng bất kỳ bên yêu cầu nào cũng có thể là một dịch vụ và rằng bên yêu cầu và dịch vụ đích có thể sử dụng dịch vụ thẻ bài an ninh của bên thứ ba được tin cậy, trợ giúp xác thực các thẻ bài an ninh cần thiết ứng với mỗi chính sách của dịch vụ đích.

Hình 3. Dịch vụ thẻ bài an ninh
Dịch vụ thẻ bài an ninh

Mô hình bảo đảm an ninh SOA này -- các lời tự khai nhận, các chính sách và các thẻ bài an ninh -- gộp lại và hỗ trợ một số mô hình cụ thể hơn, ví dụ như cấp quyền hạn dựa trên nhân dạng, các danh sách kiểm soát truy cập và cấp quyền hạn dựa trên khả năng. Nó cho phép sử dụng các công nghệ hiện có, ví dụ như giấy chứng nhận khóa công khai X.509, các thẻ bài dựa trên XML, các vé chia sẻ bảo mật Kerberos và thậm chí cả các danh sách mật khẩu. Mô hình an ninh SOA, phối hợp với các thành phần gốc của Ngôn ngữ đàm thoại bảo đảm an ninh dịch vụ Web (Web Services Secure Conversation Language -WSSC) và các nguyên mẫu (primitives) của Khung công tác chính sách các dịch vụ Web (Web Services Policy Framework), là đủ để xây dựng việc trao đổi khóa mức cao hơn, việc xác thực, việc kiểm soát truy cập dựa trên chính sách, việc kiểm định và các mối quan hệ tin cậy phức tạp.

Một dịch vụ Web có một chính sách được áp dụng cho nó, sẽ nhận một thông báo từ bên yêu cầu, có thể bao gồm các thẻ bài an ninh và có thể có một số biện pháp bảo vệ được áp dụng cho nó, sử dụng các cơ chế WSSC. Dưới đây là những bước chính được thực hiện bởi máy (engine) tin cậy của một dịch vụ web:

  • Kiểm tra xem các lời tự khai nhận trong thẻ bài đã đủ tuân thủ chính sách chưa và thông báo đó có phù hợp với chính sách không.
  • Kiểm tra xem các thuộc tính của bên tự khai nhận có được chứng minh bằng các chữ ký không. Trong các mô hình tin cậy có môi giới, chữ ký có thể không kiểm tra xác nhận nhân dạng của bên tự khai nhận; nó có thể kiểm tra nhân dạng của phương tiện trung gian mà phương tiện trung gian này có thể chỉ đơn giản khẳng định nhân dạng của bên tự khai nhận. Các lời tự khai nhận được chứng minh hoặc không được chứng minh dựa trên chính sách.
  • Kiểm tra xem những người phát hành (issuer) thẻ bài an ninh (bao gồm tất cả các thẻ bài an ninh có liên quan và được phát hành) là đáng tin cậy để đưa ra các lời tự khai nhận mà họ đã tuyên bố. Máy tin cậy có thể cần phải kiểm tra hay môi giới bên ngoài các thẻ bài (có nghĩa là, gửi các thẻ bài tới một dịch vụ thẻ bài an ninh để trao đổi chúng lấy các thẻ bài an ninh khác mà nó có thể sử dụng trực tiếp chúng trong các đánh giá).

Nếu các điều kiện này được đáp ứng và bên yêu cầu được cấp quyền thực hiện hoạt động ấy, thì các dịch vụ có thể xử lý yêu cầu dịch vụ.

Các cơ chế bảo vệ của hệ thống mạng và truyền dẫn , ví dụ như bảo mật IP (IPSec) hoặc Bảo mật tầng truyền dẫn/ Tầng các đầu cắm bảo mật (TLS / SSL), có thể được sử dụng cùng với các mô hình an ninh SOA này để hỗ trợ các yêu cầu và các kịch bản bảo đảm an ninh khác nhau. Như là một mức bảo đảm an ninh bổ sung thêm, các bên yêu cầu cần cân nhắc việc sử dụng một cơ chế bảo vệ của hệ thống mạng và truyền dẫn, nếu có, để xác thực trước người nhận khi phát hành, kiểm tra hợp lệ, hoặc đổi mới các thẻ bài an ninh.


Các nguyên lý thiết kế mô hình lập trình

Từ quan điểm an ninh, mô hình lập trình bao gồm việc quyết định ai là người có trách nhiệm trong việc buộc tuân thủ các chính sách bảo đảm an ninh (ví dụ như cơ sở hạ tầng hoặc ứng dụng) và những thông tin nào cần phải cung cấp sẵn cho các bên yêu cầu. Ngoài những khía cạnh vận hành, một số chính sách trong thời gian thiết kế (ví dụ những chính sách được phản ánh trong các bộ mô tả triển khai J2EE) có thể trợ giúp quản lý ứng dụng. Một trong các quyết định triển khai thực hiện then chốt là các yêu cầu nghiệp vụ sẽ được đáp ứng tốt nhất bằng cách tạo điều kiện cho cơ sở hạ tầng triển khai thực hiện mô hình an ninh hay bằng cách thể hiện việc buộc tuân thủ an ninh bằng mã lệnh trong mỗi ứng dụng. Một chiều hướng khác cần xem xét là việc gọi dịch vụ biến đổi như thế nào. Những người sử dụng dịch vụ có được cho phép có những linh hoạt thông qua các lựa chọn mà họ có thể tuỳ chỉnh trong quá trình đăng ký không? Cuối cùng, khi triển khai thực hiện bất kỳ giải pháp an ninh nào, cần xem xét kỹ nghệ bảo đảm an ninh - một phương pháp luận kỹ thuật để xây dựng các ứng dụng an ninh.


Bảo đảm an ninh do cơ sở hạ tầng quản lý so với bảo đảm an ninh do ứng dụng quản lý

Mỗi tổ chức thường trao cho một số người nhất định trách nhiệm nhận biết và áp đặt các chính sách an ninh của nó. Trong nhiều trường hợp quá trình này là thủ công, làm cho tổ chức đó phải dành một lượng tài nguyên đáng kể để điều phối truy cập trên khắp các thực thể và các ứng dụng khác nhau.

Chúng tôi khuyến nghị các tổ chức phức tạp nên tập trung vào cơ sở hạ tầng khi áp đặt các chính sách an ninh đi kèm với một giải pháp -- đó là, xác nhận hợp lệ thách thức với người sử dụng (ví dụ, mã nhận dạng ID/mật khẩu của người dùng), kiểm soát truy cập vào các ứng dụng (ví dụ như phương thức reserve() của travelService), và chuyển giao nhân dạng (ví dụ như, run-as travelAgency id) để đảm bảo một cách tiếp cận nhất quán. Các chính sách an ninh ứng dụng ban đầu có thể được định nghĩa trong một số tạo phẩm triển khai (ví dụ như, các bộ mô tả triển khai cho các ứng dụng J2EE). Sau khi phát triển, khi logic ứng dụng được biết khá rõ ràng, thông tin chính sách có thể được cung cấp sẵn cho môi trường triển khai. Các khai báo chính sách có thể được trừu tượng hóa thành các yêu cầu chính sách mức cao hơn để sau đó tinh chỉnh lại như là các ràng buộc triển khai thực hiện sẽ được xem xét trong giai đoạn triển khai.

Thiết kế ứng dụng đặt ra việc thực hiện các quyết định về bảo đảm an ninh do cơ sở hạ tầng quản lý so với bảo đảm an ninh do ứng dụng quản lý. Các ràng buộc và các điều kiện an ninh được gắn vào các tạo phẩm triển khai thực hiện. Thời điểm để quyết định có hay không cho phép cơ sở hạ tầng xử lý bảo đảm an ninh hay thực hiện bảo đảm an ninh bằng mã lệnh trong ứng dụng là trong giai đoạn triển khai, khi thông tin về nền tảng ứng dụng -- như Java™ 2 Platform, Enterprise Edition (J2EE) và Microsoft® .NET -- thường đã rõ ràng.

Chúng tôi khuyến nghị rằng các ứng dụng tập trung vào logic nghiệp vụ và để lùi lại sau việc bảo đảm an ninh truy cập dịch vụ và các thông báo, dành cho cơ sở hạ tầng (thùng chứa môi trường chạy, chủ chứa ứng dụng). Trong cách tiếp cận bảo mật do cơ sở hạ tầng quản lý, các chính sách bảo mật được gắn kèm với các tạo phẩm thiết kế được chuyển đổi thành các chính sách đặc thù của nền tảng đó (ví dụ, các yêu cầu được biểu diễn qua một mô hình của Ngôn ngữ mô hình hóa thống nhất (Unified Modeling Language-UML) được chuyển đổi thành các bộ mô tả triển khai J2EE).

Trong cách tiếp cận bảo đảm an ninh do ứng dụng quản lý, việc buộc tuân thủ an ninh được thực hiện trong ứng dụng và lời gọi thủ tục bảo đảm an ninh thích hợp phải được triển khai thực hiện. Thậm chí việc bảo đảm an ninh do ứng dụng quản lý phải chuyển các lời gọi bảo đảm an ninh của nó (ví dụ như authenticate()) thành các hàm đặc thù của nền tảng đó [ví dụ như loginContext.login() sử dụng Dịch vụ xác thực và cấp quyền hạn của Java (Java Authentication and Authorization Service-JAAS)].

Việc cấp quyền hạn và kiểm soát truy cập có thể thay đổi mức độ chi tiết, từ mức thô hơn đến mức chi tiết ngày càng mịn hơn. Sự lựa chọn truy cập ở mức độ chi tiết thô (vào chính giải pháp) so với truy cập ở mức độ chi tiết mịn hơn (vào một trong các hoạt động của nó) thường do các mối quan tâm về nghiệp vụ và kỹ thuật chi phối. Mức độ chi tiết cũng bị ảnh hưởng của các nhân tố, bao gồm cá thể của thực thể thông tin (ví dụ, hiện trạng của tài khoản tín dụng với một người đi du lịch cụ thể), thông tin theo bối cảnh, ví dụ như các thuộc tính của người sử dụng (ví dụ, đại lý du lịch), các ràng buộc về thời gian (ví dụ, 9-5 giờ chiều), mục đích của việc truy cập (ví dụ như với mục đích để thực hiện đặt trước một chuyến đi), đường dẫn truy cập (ví dụ, trong mạng nội bộ hay yêu cầu từ bên ngoài) và nhiều điều khác nữa.

Chính sách liên quan đến việc cấp quyền hạn có thể được trừu tượng hóa bằng cách định nghĩa các vai trò ứng dụng, ở đó một vai trò là một tập hợp các sự cho phép những hành động nào đó trên các tài nguyên ứng dụng đã cho. Ví dụ, một ứng dụng đi du lịch có thể khai báo rằng các phương thức view() hoặc change() tình trạng đặt chỗ thuộc ReservationBean có thể được truy cập thông qua vai trò của Đại lý du lịch (TravelAgent). Nói cách khác, TravelAgent là một vai trò được định nghĩa khi triển khai để xác định rõ những gì có thể được "đại lý du lịch" thực hiện dưới dạng một tập hợp các sự cho phép gọi các phương thức cụ thể của các JavaBeans cho doanh nghiệp (EJB) tương ứng. Cái không được định nghĩa trong giai đoạn triển khai thực hiện là ai là người có đặc quyền của một TravelAgent. Việc phân bổ người sử dụng theo vai trò thường được khởi tạo lúc triển khai và được quản lý sau đó trong suốt cả cuộc đời của ứng dụng. Liệt kê 1 hiển thị một ví dụ về mã định nghĩa một số sự cho phép theo phương thức dựa trên vai trò.

Liệt kê 1. Mã định nghĩa một số sự cho phép của phương thức dựa trên vai trò
<method-permission>
<role-name>TravelAgent</role-name>
<method>
   <ejb-name>ReservationBean</ejb-name>
<method-permission>
<role-name>TravelAgent</role-name>
<method>
   <ejb-name>ReservationBean</ejb-name>
   <method-name> view</method-name>
   <method-name> change</method-name>
</method>
</method-permission>

Các ứng dụng yêu cầu thông tin nhân dạng được xác thực trước khi thực hiện một số logic nghiệp vụ phải nhận được thông tin đó từ cơ sở hạ tầng. Ví dụ, trong một môi trường J2EE, môi trường chạy thiết lập nhân dạng của người dùng sau khi xác thực, ứng dụng có thể lấy thông tin này bằng một API, như getCallerPrincipal().


Tính linh hoạt của sự lựa chọn

Đôi khi một số yêu cầu hay ràng buộc nào đó về việc truy cập vào bản thân dịch vụ -- bao gồm các yêu cầu về xác thực, về tính nguyên vẹn và về tính bí mật -- là cần thiết đối với một môi trường chạy phía khách. Và người ta có thể mong muốn hỗ trợ nhiều loại môi trường chạy phía khách (ví dụ như các phía khách là trình duyệt, các phía khách không phải là trình duyệt, và các trình khách nhẹ kiểu PDA). Để đạt được điều này, bạn công bố các chính sách để khẳng định rằng môi trường chạy phía khách phải đảm bảo tính bí mật của thông báo và phải cung cấp bằng chứng về nhân dạng của người dùng (mã nhận dạng ID/mật khẩu của người dùng hoặc giấy chứng nhận). Sự trừu tượng hóa chính sách xác thực có thể liệt kê các lựa chọn thay thế nhau, ví dụ như các kiểu ủy quyền nào có thể chấp nhận được hoặc các thực thể ban hành giấy ủy quyền nào là đáng tin cậy.

Ví dụ, một dịch vụ Web TravelService có thể khai báo mục đích của nó để yêu cầu một số kiểu thẻ bài an ninh và các đòi hỏi bí mật nhất định. Việc triển khai thực hiện có thể hỗ trợ khai báo mục đích thông qua các bộ mô tả. Đến lượt mình, các công cụ có thể tạo ra các chi tiết cần thiết ở mức máy tính (ví dụ như biểu thức Chính sách an ninh WS), như minh họa trong Liệt kê 2.

Liệt kê 2. Ví dụ về mô tả Chính sách an ninh WS
<wsp:Policy>
  <sp:SymmetricBinding>
    <wsp:Policy>
      <sp:ProtectionToken>
        <wsp:Policy>
          <sp:KerberosV5APREQToken
              sp:IncludeToken=".../IncludeToken/Once" />
        </wsp:Policy>
      </sp:ProtectionToken>
      <sp:SignBeforeEncrypting />
      <sp:EncryptSignature />
    </wsp:Policy>
  </sp:SymmetricBinding>
  <sp:SignedParts>
    <sp:Body/>
    <sp:Header
       Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
    />
  </sp:SignedParts>
  <sp:EncryptedParts>
    <sp:Body/>
  </sp:EncryptedParts>
</wsp:Policy>

Kỹ thuật bảo đảm an ninh

Trong phát triển các giải pháp an ninh, một trong những thông lệ thực tế tốt nhất là kỹ thuật bảo đảm an ninh -- tuân theo các mẫu được định nghĩa rõ ràng, sao cho ứng dụng, dịch vụ hoặc thành phần của bạn sẽ thực hiện chính xác những gì mà các nhà thiết kế và những người dùng mong đợi. Bạn nên đánh giá những rủi ro vốn có trong mỗi tạo phẩm triển khai thực hiện, thiết kế và triển khai thực hiện nó, tránh bỏ ngỏ các điểm dễ tổn thương (ví dụ, quản lý bộ nhớ hiệu quả và tránh các kênh ngầm). Các công cụ hỗ trợ và các việc xem xét lại mã cũng có thể giúp giảm thiểu (hoặc loại bỏ) sự thiệt hại đến môi trường trong đó có giải pháp của bạn được triển khai.


Tóm tắt

Một mô hình lập trình SOA phải đảm bảo rằng mỗi lời gọi dịch vụ phải tuân thủ các chính sách an ninh hợp lệ cho cả hai, bên yêu cầu dịch vụ và điểm cuối dịch vụ. Cơ sở hạ tầng bảo đảm an ninh -- bao gồm khả năng để xác thực các bên yêu cầu và cấp quyền cho chúng truy cập các dịch vụ, lan truyền bối cảnh bảo đảm an ninh xuyên suốt tất cả các yêu cầu dịch vụ web dựa trên một mô hình tin cậy nền tảng bên dưới, kiểm định các sự kiện quan trọng và bảo vệ có hiệu quả các dữ liệu và nội dung -- tạo nên một cơ cấu của môi trường SOA để giúp bảo đảm an ninh các thành phần và các dịch vụ. Cốt lõi của mọi việc bảo đảm an ninh SOA là một cơ sở hạ tầng dựa trên chính sách và quản lý các chính sách. Trong các trường hợp lý tưởng, ứng dụng SOA sẽ tập trung vào logic nghiệp vụ, chuyển giao việc áp đặt thực thi các chính sách an ninh và xử lý các mối quan hệ tin cậy cho cơ sở hạ tầng. Mô hình bảo đảm an ninh dịch vụ Web và các cách tiếp cận dựa trên các đặc tả bảo đảm an ninh của dịch vụ Web giúp đáp ứng các thách thức về bảo đảm an toàn các ứng dụng hướng dịch vụ.

Tài nguyên

Học tập

Thảo luận

  • • Hãy dành tâm trí cho cộng đồng developerWorks bằng cách tham gia vào các developerWorks blogs.

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=SOA và dịch vụ Web
ArticleID=416863
ArticleTitle=Mô hình lập trình SOA để triển khai thực hiện các dịch vụ Web, Phần 7: Bảo đảm an ninh các ứng dụng hướng dịch vụ
publish-date=07312009