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




(10)

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

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

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

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

На этом веб-сайт выглядит повсюду.

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


Answers

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

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

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

Удачи.


См. Статью wiki :

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

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

То есть:

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

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. Я знаю, что это небольшая ошибка, но решения о том, насколько защита на самом деле оправдана (а не только то, что было бы здорово придумать), должны быть сделаны теми, кто близко знает проблему.


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

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

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

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


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


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

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

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

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

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

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


Brace yourself, here there's 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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

Благодаря...


Слушайте этот подкаст, чтобы узнать. Если вы хотите узнать ответ без прослушивания, то ОК, его ОТДЫХ. Но я действительно рекомендую слушать.





web-services security rest soap