Безопасные веб-сервисы: REST через HTTPS против SOAP + WS-Security. Что лучше? [закрыто]

Я ни в коем случае не эксперт по безопасности, но я предпочитаю создавать веб-сервисы в стиле REST.

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

У меня сложилось впечатление, что мы можем использовать HTTPS для всех вызовов веб-служб, и этот подход будет безопасным. Я смотрю на это так: «Если HTTPS достаточно хорош для банковских и финансовых веб-сайтов, для меня это достаточно». Опять же, я не эксперт в этой области, но я думаю, что эти люди очень серьезно подумали об этой проблеме и чувствуют себя комфортно с HTTPS.

Коллега не согласен и говорит, что SOAP и WS-Security - единственный путь.

Похоже, что на этом веб-страница повсюду.

Может быть, сообщество могло бы взвесить все за и против каждого? Спасибо!

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, Дикие идеи

Предоставлено: http://blogs.msdn.com/b/vbertocci/archive/2005/04/25/end-to-end-security-or-why-you-shouldn-t-drive-your-motorcycle-naked. ASPX

Я работаю в этом пространстве каждый день, поэтому хочу обобщить хорошие комментарии по этому вопросу, чтобы завершить это:

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-сообщения туда и обратно, встроенные в текстовое тело HTTP-запроса, вы должны иметь все преимущества WS-Security, такие как шифрование XML, сертификаты и т. Д. В ваших XML-сообщениях, используя любые функции безопасности. доступны из http, такие как шифрование SSL / TLS.