Безопасные веб-сервисы: REST через HTTPS против SOAP + WS-Security. Что лучше?
Я ни в коем случае не эксперт по безопасности, но я предпочитаю создавать веб-сервисы в стиле REST.
При создании нового сервиса, для которого необходимо, чтобы данные передавались безопасно. Мы вступили в дискуссию о том, какой подход является более безопасным - REST с HTTPS или SOAP WS с WS-Security.
У меня сложилось впечатление, что мы могли бы использовать HTTPS для всех вызовов веб-служб, и этот подход был бы безопасным. Я смотрю на это так: "Если HTTPS достаточно хорош для банковских и финансовых веб-сайтов, мне достаточно". Опять же, я не эксперт в этой области, но я думаю, что эти люди очень серьезно подумали об этой проблеме и чувствуют себя комфортно с HTTPS.
Коллега не согласен и говорит, что SOAP и WS-Security - единственный путь.
Похоже, что на этом веб-страница повсюду.
Может быть, сообщество могло бы взвесить все за и против каждого? Спасибо!
11 ответов
HTTPS защищает передачу сообщения по сети и обеспечивает некоторую гарантию клиенту об идентификации сервера. Это то, что важно для вашего банка или онлайн-брокера. Их заинтересованность в аутентификации клиента заключается не в личности компьютера, а в вашей личности. Таким образом, номера карт, имена пользователей, пароли и т. Д. Используются для аутентификации вас. Затем обычно принимаются некоторые меры предосторожности, чтобы гарантировать, что материалы не были подделаны, но в целом все, что происходит во время сеанса, рассматривается как инициированное вами.
WS-Security предлагает конфиденциальность и защиту целостности от создания сообщения до его потребления. Таким образом, вместо того, чтобы гарантировать, что содержимое сообщений может быть прочитано только правильным сервером, оно гарантирует, что оно может быть прочитано только правильным процессом на сервере. Вместо того, чтобы предполагать, что все сообщения в безопасно инициированном сеансе принадлежат аутентифицированному пользователю, каждый из них должен быть подписан.
Здесь есть забавное объяснение с участием голых мотоциклистов:
Таким образом, 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) - это только один уровень, обеспечивающий:
- Сервер, к которому подключен, представляет сертификат, удостоверяющий его личность (хотя это может быть подделано посредством отравления DNS).
- Уровень связи зашифрован (без прослушивания).
WS-Security и соответствующие стандарты / реализации используют PKI, который:
- Докажите личность клиента.
- Докажите, что сообщение не было изменено в пути (MITM).
- Позволяет серверу аутентифицировать / авторизовать клиента.
Последний пункт важен для запросов на обслуживание, когда личность клиента (вызывающего абонента) имеет первостепенное значение, если они знают, должны ли они быть авторизованы для получения таких данных от службы. Стандартный SSL является односторонней (серверной) аутентификацией и ничего не делает для идентификации клиента.
REST over HTTPS Должен быть безопасным методом, если поставщик API реализует авторизацию на стороне сервера. В случае с веб-приложением мы также обращаемся к веб-приложению по протоколу HTTPS и выполняем некоторую аутентификацию / авторизацию. Традиционно у веб-приложений не было проблем с безопасностью, тогда Restful API также без проблем решал бы проблемы безопасности!
Ответ на самом деле зависит от ваших конкретных требований.
Например, нужно ли вам защищать свои веб-сообщения или не требуется конфиденциальность, и все, что вам нужно, - это аутентифицировать конечные стороны и обеспечивать целостность сообщений? Если это так - и часто это происходит с веб-сервисами - HTTPS, вероятно, не тот молоток.
Однако - из моего опыта - не забывайте о сложности системы, которую вы строите. Не только HTTPS проще для правильного развертывания, но и приложение, которое опирается на безопасность транспортного уровня, легче отлаживать (по обычному HTTP).
Удачи.
Если ваш вызов RESTFul отправляет сообщения XML назад и вперед, встроенные в текстовое тело HTTP-запроса, вы должны иметь возможность использовать все преимущества WS-Security, такие как шифрование XML, сертификаты и т. Д. В сообщениях XML, используя любые функции безопасности. доступны из http, такие как шифрование SSL / TLS.