Защищенные веб-сервис: REST по HTTPS по сравнению с SOAP + безопасность WS. Который лучше? [закрытый]
Вы можете попытаться использовать представление vDimWorkItemTreeOverlay в качестве источника данных. Это пример запроса с одним уровнем иерархии:
SELECT Parent.[WorkItem]
,Parent.[System_Id]
,Parent.[System_Title]
,Parent.[System_State]
,Parent.[System_WorkItemType]
,Parent.[Microsoft_VSTS_Scheduling_TargetDate]
,Child.[WorkItem]
,Child.[System_Id]
,Child.[System_Title]
,Child.[System_State]
,Child.[System_Reason]
,Child.[System_WorkItemType]
,Child.[Microsoft_VSTS_Scheduling_StartDate]
,Child.[Microsoft_VSTS_Scheduling_FinishDate]
FROM [Tfs_Warehouse].[dbo].[vDimWorkItemTreeOverlay] Parent
LEFT JOIN [Tfs_Warehouse].[dbo].[vDimWorkItemTreeOverlay] Child ON Child.ParentWorkItemTreeSK = Parent.WorkItemTreeSK
WHERE Parent.AreaTeamProject = 'DEV' AND Parent.System_IsDeleted = 0 AND Parent.System_WorkItemType in ('Bug', 'Product Backlog Item', 'Requirement') AND Child.System_WorkItemType = 'Task'
AND Parent.WorkItemTreeSK = Parent.ParentWorkItemTreeSK AND Child.System_IsDeleted = 0
Это мой результат: 
6 ответов
HTTPS защищает передачу сообщения по сети и дает клиенту некоторую уверенность в идентификации сервера. Это то, что важно для вашего банка или онлайн-биржевого брокера. Их интерес в аутентификации клиента заключается не в личности компьютера, а в вашей личности. Таким образом, номера карт, имена пользователей, пароли и т. Д. Используются для вашей аутентификации. Затем обычно принимаются некоторые меры предосторожности, чтобы гарантировать, что представления не были подделаны, но в целом все, что происходит в сеансе, считается инициированным вами.
WS-Security предлагает защиту конфиденциальности и целостности с момента создания сообщения к его потреблению. Таким образом, вместо того, чтобы гарантировать, что содержимое сообщений может быть прочитано только правильным сервером, оно гарантирует, что оно может быть прочитано только правильным процессом на сервере. Вместо того чтобы предполагать, что все сообщения в безопасном инициированном сеансе исходят от аутентифицированного пользователя, каждый из них должен быть подписан.
Здесь есть забавное объяснение с участием голых мотоциклистов:
Итак, WS-Security предлагает больше защиты, чем HTTPS, а SOAP предлагает более богатый API, чем REST. Я считаю, что если вам действительно не нужны дополнительные функции или защита, вам следует отказаться от использования SOAP и WS-Security. Я знаю это'
Технически, как вы это сформулировали, ни то, ни другое не является правильным, потому что связь метода SOAP небезопасна, а метод REST ничего не говорит об аутентификации законных пользователей.
HTTPS не позволяет злоумышленникам перехватить обмен данными между двумя системами. Он также проверяет, что хост-система (сервер) на самом деле является хост-системой, к которой пользователь намеревается получить доступ.
WS-Security предотвращает доступ к системе неавторизованных приложений (пользователей).
Если в системе RESTful есть способ аутентификации пользователей, а приложение SOAP с WS-Security использует HTTPS, то оба они действительно безопасны. Это просто другой способ представления данных и доступа к ним.
См. Статью wiki :
В двухточечных ситуациях конфиденциальность и целостность данных также могут быть обеспечены в веб-сервисах с помощью безопасности транспортного уровня ( TLS), например, отправив сообщения по https.
WS-Security, однако, решает более широкую проблему поддержания целостности и конфиденциальности сообщений до тех пор, пока сообщение не было отправлено с исходного узла, обеспечивая так называемую сквозную безопасность.
То есть:
- HTTPS - это транспорт механизм безопасности уровня (точка-точка)
- WS-Security - это механизм безопасности уровня приложения (сквозной).
I don't yet have the rep needed to add a comment or I would have just added this to Bell's answer. I think Bell did a very good job of summing up the top level pros and cons of the two approaches. Just a few other factors that you might want to consider:
1) Do the requests between your clients and your service need to go through intermediaries that require access to the payload? If so then WS-Security might be a better fit.
2) It is actually possible to use SSL to provide the server with assurance as to the clients identity using a feature called mutual authentication. However, this doesn't get much use outside of some very specialized scenarios due to the complexity of configuring it. So Bell is right that WS-Sec is a much better fit here.
3) SSL in general can be a bit of a bear to setup and maintain (even in the simpler configuration) due largely to certificate management issues. Having someone who knows how to do this for your platform will be a big plus.
4) If you might need to do some form of credential mapping or identity federation then WS-Sec might be worth the overhead. Not that you can't do this with REST, you just have less structure to help you.
5) Getting all the WS-Security goop into the right places on the client side of things can be more of a pain than you would think it should.
In the end though it really does depend on a lot of things we're not likely to know. For most situations I would say that either approach will be "secure enough" and so that shouldn't be the main deciding factor.
Ответ на самом деле зависит от ваших конкретных требований.
Например, нужно ли вам защищать свои веб-сообщения, или конфиденциальность не требуется, и все, что вам нужно, это аутентифицировать конечные стороны и гарантировать сообщение целостность? В этом случае - а это часто случается с веб-службами - HTTPS, вероятно, не тот молот.
Однако, исходя из моего опыта, не упускайте из виду сложность создаваемой системы. Не только HTTPS легче правильно развернуть, но и приложение, которое полагается на безопасность транспортного уровня, легче отлаживать (через простой HTTP).
Удачи.
Как вы говорите, REST достаточно хорош для банков, поэтому должен быть достаточно хорош для вас.
Есть два основных аспекта безопасности: 1) шифрование и 2) идентификация.
Передача в SSL / HTTPS обеспечивает шифрование по сети. Но вам также необходимо убедиться, что оба сервера могут подтвердить, что знают, с кем разговаривают. Это может быть через сертификаты клиента SSL, общие секреты и т. Д.
Я уверен, что можно утверждать, что протокол SOAP «более безопасен», но, вероятно, не в значительной степени. Аналогия с обнаженным мотоциклистом хороша, но если быть точной, это будет означать, что весь Интернет небезопасен.