Безпечні веб-сервіси: REST через HTTPS проти SOAP + WS-Security. Який краще? [зачинено]

Я жодним чином не є експертом з безпеки, але віддаю перевагу створенню веб-служб у стилі REST.

Створюючи нову послугу, яка повинна мати захищені дані. Ми вступили в дискусію з приводу того, який підхід є більш безпечним - REST з HTTPS або SOAP WS з WS-Security.

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

Співробітник не погоджується і каже, що SOAP та WS-безпека - єдиний шлях.

Веб-версія про це здається в усьому світі.

Може, громада тут може зважити на плюси та мінуси кожного? Дякую!

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

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

Тут є кумедне пояснення щодо участі голих мотоциклістів:

https://docs.microsoft.com/archive/blogs/vbertocci/end-to-end-security-or-why-you-shouldnt-drive-your-motorcycle-naked

Таким чином, WS-Security пропонує більший захист, ніж HTTPS, а SOAP пропонує багатший API, ніж REST. На мою думку, якщо вам справді не потрібні додаткові функції чи захист, вам слід пропустити накладні витрати SOAP та WS-Security. Я знаю, що це трохи коп, але рішення про те, наскільки захист насправді виправданий (не тільки те, що було б круто будувати), повинні приймати ті, хто добре знає проблему.

Безпека REST залежить від транспорту, тоді як безпека SOAP не є.

REST успадковує заходи безпеки від базового транспорту, тоді як SOAP визначає свої власні через WS-Security.

Коли ми говоримо про REST, то над HTTP - усі заходи безпеки, що застосовуються HTTP, успадковуються, і це називається безпекою транспортного рівня.

Безпека транспортного рівня захищає ваше повідомлення лише тоді, коли воно знаходиться на дроті - як тільки воно покине провід, повідомлення більше не захищене.

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

WS-Security має заходи щодо аутентифікації, цілісності, конфіденційності та неприйняття, в той час як SSL не підтримує відмову [з двома ногами OAuth це робить].

У продуктивності SSL дуже швидше, ніж WS-Security.

Дякую...

Технічно, те, як ви сказали, жодне з них не є правильним, оскільки комунікація методу SOAP не є безпечною, а метод REST нічого не говорить про автентифікацію законних користувачів.

HTTPS заважає зловмисникам підслуховувати зв'язок між двома системами. Він також перевіряє, що хост-система (сервер) - це фактично хост-система, до якої користувач має намір отримати доступ.

WS-Security запобігає доступу до системи несанкціонованим програмам (користувачам).

Якщо система RESTful має автентифікацію користувачів, а програма SOAP з WS-Security використовує HTTPS, то обоє справді захищені. Це просто інший спосіб подання та доступу до даних.

Дивіться статтю у вікі :

У ситуаціях "точка-точка" конфіденційність та цілісність даних також можуть бути забезпечені на веб-службах через використання безпеки транспортного рівня (TLS), наприклад, шляхом надсилання повідомлень через https.

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

Це є:

• HTTPS - механізм захисту транспортного рівня (точка-точка)
• WS-Security - це механізм захисту рівня (в кінці).

Як ви кажете, REST досить хороший для банків, тому повинен бути достатньо хорошим для вас.

Є два основні аспекти безпеки: 1) шифрування та 2) особистість.

Передача в SSL / HTTPS забезпечує шифрування по дроту. Але вам також потрібно переконатися, що обидва сервери можуть підтвердити, що вони знають, з ким говорять. Це може бути через сертифікати клієнта SSL, секрети спільного використання тощо.

Я впевнений, що можна зробити так, що SOAP є "більш захищеним", але, мабуть, не будь-яким значним чином. Аналогія оголеного мотоцикліста - це мило, але якщо точно, це означає, що весь Інтернет не є безпечним.

У мене ще немає представника, необхідного для коментаря, або я б просто додав це до відповіді Белла. Я думаю, Белл зробив дуже гарну роботу, підбивши підсумки плюсів і мінусів двох підходів. Лише кілька інших факторів, які ви можете врахувати:

1) Чи повинні запити між вашими клієнтами та вашою службою проходити через посередників, які потребують доступу до корисного навантаження? Якщо так, то WS-Security може бути кращим.

2) Насправді можна використовувати SSL, щоб забезпечити сервер впевненості в ідентичності клієнтів за допомогою функції, що називається взаємною автентифікацією. Однак це не отримує особливої ​​користі поза деякими дуже спеціалізованими сценаріями через складність його налаштування. Тож Белл має рацію, що WS-Sec тут набагато краще підходить.

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

4) Якщо вам може знадобитися виконати якусь форму відображення облікових даних або федерацію ідентичності, то WS-Sec може стояти накладні витрати. Не те, що ви не можете зробити це з REST, у вас просто менше структури, щоб допомогти вам.

5) Переміщення всього кола WS-Security у потрібні місця на стороні клієнта може спричинити біль, ніж ви думаєте, що слід.

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

Brace yourself, here there's another coming :-)

Сьогодні мені довелося пояснити своїй дівчині різницю між виразною силою WS-Security на відміну від HTTPS. Вона є вченим-комп’ютером, тож навіть якщо вона не знає всіх XML мамбо-джамбо, вона розуміє (можливо, краще за мене), що означає шифрування чи підпис. Однак я хотів міцного іміджу, який міг би змусити її реально зрозуміти, для чого корисні речі, а не як вони реалізуються (що з’явилося трохи пізніше, вона не уникнула цього :-)).

Тож іде так. Припустимо, ви голі, і вам доведеться їхати на мотоциклі до певного пункту призначення. У випадку (A) ви проходите через прозорий тунель: ваша єдина надія не бути арештованою за нецензурну поведінку - це те, що ніхто не шукає. Це не зовсім найбезпечніша стратегія, з якою ви можете вийти ... (зауважте, крапля поту з лоба хлопця :-)). Це явно рівнозначно POST, і коли я кажу "еквівалент", я маю на увазі це. У випадку (B) ви перебуваєте в кращій ситуації. Тунель непрозорий, тому, поки ви їдете в нього, ваш публічний запис є безпечним. Однак це все-таки не найкраща ситуація. Вам все одно доведеться виїхати з дому і дійти до входу в тунель, а одного разу поза тунелем, ймовірно, вам доведеться вийти і кудись піти ... і це стосується HTTPS. Правда, ваше повідомлення є безпечним, коли воно перетинає найбільшу прірву: але, як тільки ви доставите його з іншого боку, ви насправді не знаєте, скільки етапів доведеться пройти, перш ніж дійти до реальної точки, де дані будуть оброблятися. І звичайно, всі ці етапи можуть використовувати щось інше, ніж HTTP: класичний MSMQ, який буферизує запити, які неможливо подати, наприклад. Що станеться, якщо хтось приховує ваші дані, коли вони перебувають у цій попередній обробці? Гм. (читайте цей "хм", як той, який вимовляв Морфей в кінці речення "ви думаєте, що це повітря, яким ви дихаєте?"). Повне рішення (с) у цій метафорі болісно тривіальне: набудьте собі якийсь проклятий одяг, а особливо шолом, перебуваючи на мотоциклі !!! Таким чином, ви можете сміливо ходити, не покладаючись на непрозорість середовища. Метафора, сподіваємось, зрозуміла: одяг приходить із собою незалежно від середнього рівня та оточуючої інфраструктури, як це робить безпека рівня повідомлень. Крім того, ви можете вирішити накрити одну частину, але розкрити іншу (і це можна зробити на особистій основі: безпека аеропорту може зняти куртку та взуття, тоді як у лікаря може бути вищий рівень доступу), але пам’ятайте, що сорочки з короткими рукавами є погана практика, навіть якщо ви пишаєтесь своїми біцепсами :-) (краще поло або футболку).

Я радий сказати, що вона зрозуміла! Треба сказати, що метафора одягу дуже потужна: я спокусився використати її для введення концепції політики (диско-клуби не дозволять тобі в спортивному взутті; ти не можеш піти знімати гроші в банку в нижній білизні , в той час як це цілком прийнятний вигляд, врівноважуючи себе на прибої;

Архітектура - WS, Wild Ideas

Люб’язно: http://blogs.msdn.com/b/vbertocci/archive/2005/04/25/end-to-end-security-or-why-you-shouldn-t-drive-your-motorcycle-naked. асп

Я працюю в цьому просторі щодня, тому хочу підсумувати хороші коментарі щодо цього, намагаючись закрити це:

SSL (HTTP / s) - це лише один рівень, що забезпечує:

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

WS-Security та пов'язані з ними стандарти / реалізації використовують PKI, які:

1. Доведіть особу клієнта.
2. Доведіть, що повідомлення не було змінено під час транзиту (MITM).
3. Дозволяє серверу аутентифікувати / авторизувати клієнта.

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

Відповідь насправді залежить від ваших конкретних вимог.

Наприклад, чи потрібно захищати ваші веб-повідомлення чи конфіденційність не потрібна, і все, що вам потрібно, це автентифікація кінцевих сторін та забезпечення цілісності повідомлення? Якщо це так - і це часто буває з веб-сервісами - HTTPS, мабуть, невірний молоток.

Однак - з мого досвіду - не забувайте про складність системи, яку ви будуєте. Не тільки HTTPS легше правильно розгортати, але і додаток, який спирається на безпеку транспортного рівня, простіше налагоджувати (через звичайний HTTP).

Удачі.

REST Over HTTPS Повинен бути захищеним методом до тих пір, поки постачальник API реалізує авторизацію на сервері. У випадку з веб-додатками, а також, що ми робимо - це доступ до веб-програми через HTTPS та деяку автентифікацію / авторизацію, традиційно у веб-додатків не виникало проблем із безпекою, тоді Restful API також без проблем може вирішити проблеми із безпекою!

Якщо ваш виклик RESTFul надсилає повідомлення XML назад і назад, вбудовані в тіло Html запиту HTTP, ви повинні мати можливість використовувати всі переваги WS-безпеки, такі як шифрування XML, сертифікати тощо, у своїх повідомленнях XML, використовуючи будь-які функції захисту доступні за допомогою http, наприклад, шифрування SSL / TLS.