1. Серія контенту:
2. Цей контент є частиною серії: Поради та рекомендації по web-сервісів, частина 11
3. тріада безпеки
4. Загальна модель WS-Security
5. Малюнок 1. системного середовища
6. Інформація про XML-шифруванні WS-Security
7. Реальний сценарій WS-Security
8. Малюнок 2. Обробка запиту додатком-споживачем за допомогою WS-Security
9. Малюнок 3. Обробка запиту постачальником сервісів за допомогою WS-Security
10. Малюнок 4. Обробка відповіді постачальником сервісів за допомогою WS-Security
11. Малюнок 5. Обробка відповіді додатком-споживачем за допомогою WS-Security
12. Ресурси для скачування

Поради та рекомендації по web-сервісів, частина 11

Специфікація WS-Security

Серія контенту:

Цей контент є частиною # з серії # статей: Поради та рекомендації по web-сервісів, частина 11

https://www.ibm.com/developerworks/ru/library/?series_title_by=**auto**

Слідкуйте за виходом нових статей цієї серії.

Цей контент є частиною серії: Поради та рекомендації по web-сервісів, частина 11

Слідкуйте за виходом нових статей цієї серії.

Ця стаття розбита на дві частини. Перша присвячена функціям WS-Security, взаємозв'язку між бізнес-учасниками і механізмів реалізації можливостей WS-Security. У другій будуть описані підтримка WS-Security сервером IBM® WebSphere® Application Server, бізнес-вимоги замовників і їх досвід використання WS-Security і інших технологій безпеки.

Вибір і реалізація проектних рішень, що передбачають використання технологій безпеки, часто негативно позначаються на продуктивності рішення. Це не означає, що всі технології безпеки, які використовуються в рішеннях, призводять до зниження продуктивності. Швидше, необхідно усвідомлювати, що рішення web-сервісів, що вимагають аутентифікації бізнес-учасників, цифрових підписів для вмісту повідомлень і шифрування XML-даних, можуть мати істотно відрізняються наведені цифри щодо залежно від технології і застосовуваного способу захисту відкритих у вигляді сервісів бізнес-функцій і даних.

У даній статті розглядається тріада безпеки, що включає: (а) аутентифікацію, (б) цілісність даних і (в) конфіденційність даних. Перш ніж заглибитися в деталі механізмів реалізації вимог до безпеки, я зроблю короткий огляд цих можливостей для неспеціалістів.

тріада безпеки

Аутентифікація покликана гарантувати, що сторони бізнес-транзакції є тими, ким вони себе оголошують, тобто довести справжність сторін. Таке доказ може бути затребувано різними способами. Простий варіант - надання ідентифікатора користувача і пароля. Більш складний варіант - використання сертифіката X.509, виданого довіреною центром сертифікації (наприклад, Verisign). Сертифікат містить ідентифікаційні облікові дані і асоційовану з ними пару з закритого і відкритого ключів. Доказ автентичності, що надається стороною, включає в себе сам сертифікат і окрему порцію інформації, яка містить цифровий підпис з використанням закритого ключа сертифіката. Перевіривши підписану інформацію за допомогою відкритого ключа, асоційованого з сертифікатом іншого боку, приймаюча сторона може аутентифицировать відправника як власника сертифіката, таким чином переконавшись в його справжності. Аутентифікація сторонами один одного називається взаємною аутентифікацією; така аутентифікація часто виконується між споживачем і постачальником web-сервісу.

Щоб забезпечити цілісність бізнес-інформації (якої сторони обмінюються в транзакції) і гарантувати, що вміст не було буде змінено або пошкоджено під час його передачі через Інтернет, дані підписують цифровим підписом з використанням ключів безпеки. Це друга вимога тріади безпеки. Загальноприйнятою практикою є використання закритого ключа сертифіката X.509 відправника для підписання цифровим підписом SOAP-тіла запиту web-сервісу. Аналогічним чином можна підписувати блоки SOAP-заголовка запиту, щоб гарантувати цілісність переданої в транзакції інформації, що виходить за рамки актуального бізнес-контексту (наприклад, ідентифікатори повідомлення, маркери доступу). Крім того, для забезпечення цілісності даних цифровим підписом можна підписувати відповіді web-сервісів.

Третьою вимогою тріади безпеки є конфіденційність. Щоб зробити обмін інформацією в запитах і відповідях web-сервісів нечитабельним для сторонніх, використовується технологія шифрування. Мета - гарантувати, що будь-яка спроба звернутися до даних при передачі, в пам'яті або після збереження потребують відповідних алгоритмів і ключів безпеки для дешифрування даних, без якого неможливо отримати доступ до актуальної інформації.

В даний час всі ці заходи безпеки можна реалізувати за допомогою різних механізмів. Залежно від конкретних потреб і бізнес-середовища можна вибрати або транспортно-залежні, або специфічні для обміну SOAP-повідомленнями механізми.

Ця стаття, що входить в серію "Поради та рекомендації по web-сервісів", в основному присвячена різним способам використання WS-Security в ваших рішеннях і їх очікуваного впливу на продуктивність.

Загальна модель WS-Security

Специфікація WS-Security знаходиться на завершальній стадії затвердження в якості стандарту OASIS і надає механізми для виконання всіх трьох вимог тріади безпеки між кінцевими точками програми. За допомогою WS-Security можна вибірково виконувати кожне з вимог тріади безпеки, реалізуючи їх у вирішенні порізно або разом.

У даній статті додаток, що використовує сервіси іншої програми, називається додатком-споживачем (Consuming Application). Додаток, що надає послуги, називається постачальником сервісів (Service Provider) Малюнок 1 ілюструє цей зв'язок і є основою для значної частини подальшого обговорення.

Малюнок 1. системного середовища

В описаному і проілюстрованому в наступних розділах сценарії до виклику сервісів постачальника необхідно обмінятися з клієнтом відкритим ключем сертифікату X.509 і налаштувати його використання в середовищі виконання клієнта. Як додаток-споживач, так і постачальник сервісів повинні імпортувати в локальні сховища кореневий сертифікат центру сертифікації (наприклад, Verisign), який видав сертифікати сторонам. Додаток-споживач матиме в сховище ключів кореневий сертифікат сертифіката постачальника сервісів. У свою чергу, сховище ключів постачальника сервісів буде мати кореневий сертифікат сертифіката додатки-споживача. Це обов'язкова умова, що дозволяє перевірити цифрові підписи індивідуальних сертифікатів, які передаються у вигляді довічних маркерів доступу в SOAP-повідомленнях.

У повну реалізацію всіх трьох вимог безпеки входять:

• Відправники запитів або відповідей web-сервісів:
  • підписують повідомлення, використовуючи закритий ключ своїх сертифікатів X.509;
  • шифрують повідомлення, використовуючи відкритий ключ сертифіката X.509 одержувачів, що гарантує доступ до перегляду повідомлення тільки їм.
• Одержувачі запитів або відповідей web-сервісів:
  • перевіряють підпис повідомлення, використовуючи відкритий ключ відправника, для аутентифікації відправника та перевірки цілісності повідомлення;
  • дешифрують повідомлення, використовуючи закритий ключ своїх сертифікатів X.509.

Інформація про XML-шифруванні WS-Security

Шифрування даних на основі специфікації WS-Security і специфікації XML-шифрування включає в себе:

• Двофазний процес, який використовує як симетричні, так і асиметричні алгоритми.
• Загальний ключ, який використовується для шифрування / дешифрування даних повідомлення за допомогою симетричного алгоритму, наприклад Triple DES. Симетричні алгоритми дуже ефективні і працюють з єдиним ключем для шифрування і дешифрування. У реалізаціях WS-Security використовується ключ, що генерується випадковим чином. Після шифрування даних повідомлення ключ вставляється в повідомлення. Зверніть увагу, що ключ також шифрується, як описано нижче.
• Передачу в SOAP-повідомленні загального ключа, що шифрується і дешіфруемого за допомогою асиметричних алгоритмів, наприклад RSA-V1.5. Шифрування загального ключа здійснюється інакше, ніж шифрування даних повідомлення: за допомогою алгоритму, який використовує пару ключів - закритий і відкритий. Сертифікат X.509 має два ключі: один є особистим (закритим) ключем власника сертифіката, а другий використовується спільно з іншими учасниками бізнесу. Симетричні алгоритми більш ефективні, ніж асиметричні, однак вони вимагають від сторін вмілого поводження з загальними ключами, а також мають внутрішні ризики безпеки, зумовлені можливістю їх потрапляння в руки осіб, що не відносяться до вашої організації або до партнерів по бізнесу. Таким чином, використовуючи тільки асиметричні алгоритми для випадкового ключа, WS-Security забезпечує відносно ефективне і просте в управлінні рішення. У другій частині статті я розповім, чому я зробив застереження щодо.

Додаткова інформація по XML-шифрування приведена в розділі ресурси .

Реальний сценарій WS-Security

Описаний нижче сценарій є одним з багатьох, які можна реалізувати за допомогою WS-Security. Він використовує сертифікати X.509, що є поширеною практикою в рішеннях замовників, які я опишу в другій частині статті.

Як правило, додаток-споживач має проксі-сервіс або компонент-заглушку JAX-RPC, створювані в інтегрованому середовищі розробки (наприклад, WebSphere Studio Application Developer) з використанням WSDL постачальника сервісу. Після виклику web-сервісу перед відправкою запиту проксі або середовище виконання SOAP на клієнтській системі виконують функції WS-Security.

Спочатку SOAP-повідомлення підписується цифровим підписом. Середовище виконання SOAP звертається до сховища ключів і в міру необхідності витягує ключі захисту і сертифікати. Залежно від наданої вашої середовищем підтримки WS-Security можна підписувати тільки тіло SOAP-повідомлення або окремі його елементи. Крім того, можна підписувати блоки SOAP-заголовка. Підписання виконується з використанням закритого ключа сертифіката X.509 додатки-споживача. Після підписання повідомлення сертифікат X.509 включається в SOAP-заголовок у вигляді довічного маркера доступу. Повідомлення шифрується за допомогою симетричного алгоритму із загальним ключем. Ключ, використовуваний для шифрування даних, шифрується за допомогою асиметричного алгоритму з відкритим ключем, асоційованим з сертифікатом X.509 постачальника сервісу. Після шифрування повідомлення і загального ключа в SOAP-заголовок включається посилання на сертифікат X.509 постачальника сервісу, яких направлено запит. Це робиться у зв'язку з тим, що постачальник сервісу може використовувати кілька сертифікатів.

Малюнок 2. Обробка запиту додатком-споживачем за допомогою WS-Security

Обробка запиту web-сервісу постачальником сервісів

Після отримання постачальником сервісів запиту web-сервісу цей запит направляється в механізм обробки SOAP (середа виконання SOAP) на основі URL запиту (опублікована точка доступу до сервісу). Дані повідомлення та загальний ключ передаються в запиті в зашифрованому вигляді, тому першим кроком є ​​ідентифікація сертифіката X.509, зазначеного в заголовку SOAP, і витяг його закритого ключа зі сховища ключів. Після отримання закритого ключа за допомогою асиметричного алгоритму дешифрується загальний ключ. Після дешифрування загального ключа дані повідомлення дешифруються за допомогою симетричного алгоритму. Тепер, коли все повідомлення дешифровано, витягується відкритий ключ сертифіката X.509, переданого в SOAP-заголовку. Цифровий підпис повідомлення виконана з використанням відкритого ключа додатки-споживача. Якщо перевірка підпису проходить успішно, середовище виконання SOAP постачальника сервісів підтверджує цілісність повідомлення та гарантує, що повідомлення дійсно підписано додатком-споживачем. Цей процес також аутентифікує джерело (відправника) повідомлення, так як тільки відправник, будучи власником сертифікату, має доступ до закритого ключа, що використовується при підписанні повідомлення. Після дешифрування повідомлення і перевірки підпису середовище виконання SOAP викликає реалізацію web-сервісу.

Малюнок 3. Обробка запиту постачальником сервісів за допомогою WS-Security

Обробка відповіді web-сервісу постачальником сервісів

Після виконання бізнес-логіки реалізації сервісу та отримання відповіді ті ж операції WS-Security виконуються для відповідного повідомлення web-сервісу. Однак ролі пар ключів X.509 для цифрового підпису та шифрування міняються місцями. Середовище виконання SOAP постачальника сервісів підписує повідомлення цифровим підписом з використанням закритого ключа свого сертифіката X.509. Сертифікат включається в SOAP-повідомлення, а повідомлення шифрується з використанням загального ключа. Ключем, використовуваним для шифрування даних, може бути той же ключ, який передається в первісному запиті, або інший, згенерований випадковим чином ключ, що більш типово. Шифрування загального ключа здійснюється з використанням відкритого ключа сертифіката, який був переданий у запиті; таким чином, тільки відправник запиту, який має доступ до закритого ключа сертифіката, може дешифрувати повідомлення. Після підписання та шифрування повідомлення середовище виконання SOAP постачальника сервісів відправляє відповідь з додатком-споживачеві.

Малюнок 4. Обробка відповіді постачальником сервісів за допомогою WS-Security

Обробка додатком-споживачем WS-Security відповіді web-сервісу дуже схожа на обробку запиту постачальником сервісів.

Додаток-споживач отримує відповідь web-сервісу з відповіддю, спрямованим в механізм обробки SOAP (середа виконання SOAP) з урахуванням початкового HTTP-сеансу. Дані повідомлення та загальний ключ передаються у відповідь в зашифрованому вигляді. Таким чином, першим кроком є ​​отримання закритого ключа сертифіката, асоційованого з відповідним запитом, для дешифрування ключа з використанням асиметричного алгоритму. Після дешифрування загального ключа дані повідомлення дешифруються за допомогою симетричного алгоритму. Після дешифрування всього повідомлення сертифікат X.509, переданий в SOAP-заголовку, використовується для вилучення його відкритого ключа. Цифровий підпис повідомлення відповіді створюється з використанням відкритого ключа постачальника сервісів. Якщо перевірка підпису проходить успішно, середовище виконання SOAP додатки-споживача підтверджує цілісність повідомлення та гарантує, що повідомлення дійсно підписано постачальником сервісів. Цей процес також аутентифікує джерело (відправника) повідомлення, так як тільки відправник, будучи власником сертифікату, має доступ до закритого ключа, що використовується при підписанні повідомлення. Після дешифрування повідомлення і перевірки підпису середовище виконання SOAP передає відповідь з додатком-споживачеві.

Малюнок 5. Обробка відповіді додатком-споживачем за допомогою WS-Security

висновок

Специфікація WS-Security дуже складна за внутрішньою будовою і може використовуватися в самих різних сценаріях. Приклад, описаний вище, відображає багато аспектів проектів, уже реалізованих замовниками. Цей сценарій, повністю або частково, реалізовувався у замовників на платформі WebSphere Application Server з урахуванням політик безпеки, інфраструктури безпеки і бізнес-вимог. Це питання буде обговорюватися в другій частині статті.

Важливо відзначити, що WebSphere Application Server підтримує WS-Security в рамках декларативної моделі. Це дозволяє легко реалізувати можливості WS-Security з уже розробленими і протестованими web-сервісами на етапі розгортання. В результаті ІТ-архітекторам і ІТ-фахівцям не доводиться думати про складнощі цифрових підписів або шифрування XML.

Ресурси для скачування

Схожі теми

Підпишіть мене на повідомлення до коментарів