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




web-services (8)

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

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

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

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

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

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

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


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


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


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

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

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

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


См. Статью wiki :

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

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

То есть:

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

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

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

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

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


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

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





soap