Защищенные веб-службы: REST через HTTPS и SOAP + WS-Security. Что лучше?

Ответ 1

HTTPS обеспечивает передачу сообщения по сети и обеспечивает некоторую уверенность клиента в идентификации сервера. Это то, что важно для вашего банка или онлайн-брокера. Их заинтересованность в аутентификации клиента не в том, что касается компьютера, а в вашей личности. Поэтому для аутентификации вас используются номера карт, имена пользователей, пароли и т.д. Затем обычно принимаются некоторые меры предосторожности, чтобы гарантировать, что представления не были подделаны, но в целом все, что происходит на сессии, считается инициированным вами.

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

Здесь есть забавное объяснение с участием голых мотоциклистов:

http://blogs.msdn.com/vbertocci/archive/2005/04/25/end-to-end-security-or-why-you-shouldn-t-drive-your-motorcycle-naked.aspx

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

Ответ 2

Безопасность REST зависит от транспорта, в то время как безопасность SOAP отсутствует.

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

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

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

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

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

По производительности SSL значительно быстрее WS-Security.

Спасибо...

Ответ 3

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

HTTPS предупреждает злоумышленников из eavesdropping об обмене данными между двумя системами. Он также проверяет, что хост-система (сервер) - это фактически хост-система, к которой пользователь хочет получить доступ.

WS-Security предотвращает доступ неавторизованных приложений (пользователей) к системе.

Если система RESTful имеет способ аутентификации пользователей, а SOAP-приложение с WS-Security использует HTTPS, то действительно обе оба являются безопасными. Это просто другой способ представления и доступа к данным.

Ответ 4

См. статью wiki:

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

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

То есть:

• HTTPS - это механизм безопасности транспортного уровня (точка-точка).
• WS-Security - это механизм безопасности на уровне приложений (сквозной).

Ответ 5

Как вы говорите, REST достаточно хорош для банков, поэтому должно быть достаточно для вас.

Существует два основных аспекта безопасности: 1) шифрование и 2) идентификация.

Передача в SSL/HTTPS обеспечивает шифрование по кабелю. Но вам также необходимо убедиться, что оба сервера могут подтвердить, что они знают, с кем они разговаривают. Это может быть через SSL-клиентские сертификаты, разделять секреты и т.д.

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

Ответ 6

У меня еще нет ответа, чтобы добавить комментарий, или я бы просто добавил это к ответу Белла. Я думаю, что Белл очень хорошо подвел итог плюсам и минусам этих двух подходов. Еще несколько факторов, которые вы можете рассмотреть:

1) Должны ли запросы между вашими клиентами и вашим сервисом проходить через посредников, которым нужен доступ к полезной нагрузке? Если это так, то WS-Security может быть лучше.

2) Фактически можно использовать SSL, чтобы обеспечить серверу уверенность в идентификации клиентов с помощью функции, называемой взаимной аутентификацией. Тем не менее, это не очень удобно использовать за пределами некоторых очень специализированных сценариев из-за сложности его настройки. Итак, Белл прав, что WS-Sec намного лучше подходит.

3) SSL вообще может быть немного медведем для настройки и поддержки (даже в более простой конфигурации), в основном из-за проблем с управлением сертификатами. Наличие того, кто знает, как это сделать для вашей платформы, будет большим плюсом.

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

5) Получение всех решений WS-Security в правильные места на стороне клиента может быть больнее, чем вы думаете.

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

Ответ 7

Brace yourself, here there another coming :-)

Сегодня мне пришлось объяснить моей девушке разницу между выразительной силой WS-Security, а не HTTPS. Она компьютерный ученый, поэтому, даже если она не знает все XML mumbo jumbo, она понимает (может быть, лучше меня), что такое шифрование или подпись. Однако я хотел получить сильное изображение, которое могло бы заставить ее понять, для чего полезны, а не как они реализованы (это произошло немного позже, она не избежала этого:)).

Так оно и происходит. Предположим, что вы голые, и вам нужно управлять своим мотоциклом в определенном месте. В случае (A) вы проходите через прозрачный туннель: ваша единственная надежда не быть арестованным за непристойное поведение - это то, что никто не смотрит. Это не самая безопасная стратегия, с которой вы можете выйти... (обратите внимание на пот-каплю с парня на лоб:-)). Это эквивалентно POST в ясном виде, и когда я говорю "эквивалент", я имею в виду. В случае (B) вы находитесь в лучшей ситуации. Туннель непрозрачен, поэтому пока вы путешествуете в него, ваш общедоступный отчет безопасен. Однако это все еще не лучшая ситуация. Вам все равно придется уйти из дома и добраться до входа в туннель, а когда-то за туннелем, вероятно, вам придется выйти и погулять где-нибудь... и это идет на HTTPS. Правда, ваше сообщение безопасно, когда оно пересекает самую большую пропасть: но как только вы доставили его с другой стороны, вы действительно не знаете, сколько этапов придется пройти до достижения реальной точки, где будут обрабатываться данные. И, конечно, все эти этапы могут использовать нечто иное, чем HTTP: классический MSMQ, который буферизует запросы, которые не могут быть сразу поданы, например. Что произойдет, если кто-то задержит ваши данные, пока они находятся в этой предварительной обработке? Гектометр (прочитайте это "hm", как тот, который произнес Морфеус в конце фразы: "Как вы думаете, это воздух, которым вы дышите?" ). Полное решение (c) в этой метафоре мучительно тривиально: возьмите на себя какую-нибудь штопальную одежду, и особенно шлем на мотоцикле!!! Таким образом, вы можете спокойно обойтись, не полагаясь на непрозрачность окружения. Метафора, как мы надеемся, понятна: одежда приходит с вами, независимо от средней или окружающей инфраструктуры, как это делает безопасность на уровне беспорядка. Кроме того, вы можете решить покрыть одну часть, но раскрыть другую (и вы можете сделать это на личной основе: безопасность в аэропорту может снять куртку и обувь, а ваш врач может иметь более высокий уровень доступа), но помните, что рубашки с короткими рукавами плохая практика, даже если вы гордитесь своими бицепсами:-) (лучше поло или футболка).

Я рад сказать, что она поняла! Я должен сказать, что метафора одежды очень сильная: у меня возникло соблазн использовать ее для введения концепции политики (диско-клубы не позволят вам заниматься спортивной обувью, вы не можете забирать деньги в банке в нижнем белье, в то время как это вполне приемлемый взгляд, балансируя себя на прибое и т.д.), но я думал, что на один день этого было достаточно; -)

Архитектура - 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

Ответ 8

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

SSL (HTTP/s) - это только один уровень, обеспечивающий:

• Подключенный сервер представляет сертификат, подтверждающий его (хотя это может быть подделано через DNS-отравление).
• Уровень связи зашифрован (без подслушивания).

WS-Security и соответствующие стандарты/реализации используют PKI, которые:

• Докажите личность клиента.
• Доказать, что сообщение не было изменено в пути (MITM).
• Позволяет серверу аутентифицировать/разрешить клиент.

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

Ответ 9

Ответ на самом деле зависит от ваших конкретных требований.

Например, вам нужно защитить свои веб-сообщения, или конфиденциальность не требуется, и все, что вам нужно, - это аутентифицировать конечные стороны и обеспечить целостность сообщений? Если это так - и часто это связано с веб-сервисами - HTTPS, вероятно, является неправильным молотом.

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

Удачи.

Ответ 10

Если ваш вызов RESTFul отправляет XML-сообщения туда и обратно, встроенные в тело HTML-запроса HTTP, вы должны иметь все преимущества WS-Security, такие как шифрование XML, сертификаты и т.д. в ваших XML-сообщениях при использовании любые функции безопасности доступны из http, такие как шифрование SSL/TLS.

Ответ 11

REST Over HTTPS Должен быть безопасным методом, если поставщик API реализует авторизацию на сервере. В случае с веб-приложением также мы получаем доступ к веб-приложению через HTTPS и некоторую аутентификацию/авторизацию, традиционно веб-приложения не имеют проблем с безопасностью, тогда Restful API также будет противостоять проблемам безопасности без проблем!