Serviços Web seguros: REST sobre HTTPS vs SOAP + WS-Security. Qual é melhor? [fechadas]

Não sou especialista em segurança, mas sou a favor da criação de serviços Web no estilo REST.

Ao criar um novo serviço que precisa ter os dados que ele transmite em segurança. Entramos em um debate sobre qual abordagem é mais segura - REST com HTTPS ou um SOAP WS com WS-Security.

Tenho a impressão de que poderíamos usar HTTPS para todas as chamadas de serviço da Web e essa abordagem seria segura. A maneira como vejo é: "se o HTTPS é bom o suficiente para sites bancários e financeiros, é bom o suficiente para mim". Mais uma vez, não sou especialista neste espaço, mas acho que essas pessoas pensaram bastante sobre esse problema e se sentem confortáveis ​​com o HTTPS.

Um colega de trabalho discorda e diz que SOAP e WS-Security são o único caminho a percorrer.

A web parece estar por toda parte nisso.

Talvez a comunidade daqui possa pesar nos prós e contras de cada um? Obrigado!

O HTTPS protege a transmissão da mensagem pela rede e fornece alguma garantia ao cliente sobre a identidade do servidor. Isso é importante para o seu banco ou corretor da bolsa online. O interesse deles em autenticar o cliente não está na identidade do computador, mas na sua identidade. Assim, números de cartão, nomes de usuário, senhas etc. são usados ​​para autenticar você. Geralmente, são tomadas algumas precauções para garantir que as submissões não tenham sido adulteradas, mas, no geral, o que quer que aconteça na sessão é considerado iniciado por você.

O WS-Security oferece proteção de confidencialidade e integridade desde a criação da mensagem até seu consumo. Portanto, em vez de garantir que o conteúdo das comunicações possa ser lido apenas pelo servidor certo, ele garante que ele possa ser lido apenas pelo processo correto no servidor. Em vez de assumir que todas as comunicações na sessão iniciada com segurança são do usuário autenticado, cada uma deve ser assinada.

Há uma explicação divertida envolvendo motociclistas nus aqui:

https://docs.microsoft.com/archive/blogs/vbertocci/end-to-end-security-or-why-you-shouldnt-drive-your-motorcycle-naked

Portanto, o WS-Security oferece mais proteção que o HTTPS e o SOAP oferece uma API mais rica que o REST. Minha opinião é que, a menos que você realmente precise dos recursos ou proteção adicionais, você deve pular a sobrecarga do SOAP e do WS-Security. Eu sei que é um pouco difícil, mas as decisões sobre quanta proteção é realmente justificada (não apenas o que seria legal de construir) precisam ser tomadas por quem conhece o problema intimamente.

A segurança REST depende do transporte, enquanto a segurança SOAP não.

O REST herda medidas de segurança do transporte subjacente, enquanto o SOAP define seu próprio via WS-Security.

Quando falamos sobre REST, sobre HTTP - todas as medidas de segurança aplicadas HTTP são herdadas e isso é conhecido como segurança no nível de transporte.

Segurança no nível de transporte, protege sua mensagem apenas enquanto está ligada - assim que sai, a mensagem não é mais segura.

Mas, com o WS-Security, seu nível de segurança é a mensagem - mesmo que a mensagem saia do canal de transporte, ela ainda estará protegida. Além disso - com segurança no nível da mensagem, você pode criptografar parcialmente a mensagem [não a mensagem inteira, mas apenas as partes desejadas] - mas com a segurança no nível do transporte, você não pode fazê-lo.

O WS-Security possui medidas para autenticação, integridade, confidencialidade e não repúdio, enquanto o SSL não suporta o não repúdio [com o OAuth de duas pernas].

Em termos de desempenho, o SSL é muito mais rápido que o WS-Security.

Obrigado...

Tecnicamente, a maneira como você o escreveu, também não está correta, porque a comunicação do método SOAP não é segura e o método REST não disse nada sobre a autenticação de usuários legítimos.

O HTTPS impede que os invasores interceptem a comunicação entre dois sistemas. Ele também verifica se o sistema host (servidor) é realmente o sistema host que o usuário pretende acessar.

O WS-Security impede que aplicativos (usuários) não autorizados acessem o sistema.

Se um sistema RESTful tem uma maneira de autenticar usuários e um aplicativo SOAP com WS-Security está usando HTTPS, então, na verdade, ambos são seguros. É apenas uma maneira diferente de apresentar e acessar dados.

Veja o artigo wiki :

Em situações ponto a ponto, a confidencialidade e a integridade dos dados também podem ser impostas nos serviços da Web por meio do uso do Transport Layer Security (TLS), por exemplo, enviando mensagens por https.

O WS-Security, no entanto, resolve o problema mais amplo de manter a integridade e a confidencialidade das mensagens até que uma mensagem seja enviada do nó de origem, fornecendo a chamada segurança de ponta a ponta.

Isso é:

• HTTPS é um mecanismo de segurança da camada de transporte (ponto a ponto)
• O WS-Security é um mecanismo de segurança da camada de aplicativos (ponta a ponta).

Como você diz, o REST é bom o suficiente para os bancos, portanto deve ser bom o suficiente para você.

Existem dois aspectos principais na segurança: 1) criptografia e 2) identidade.

A transmissão em SSL / HTTPS fornece criptografia por fio. Mas você também precisará garantir que os dois servidores possam confirmar que sabem com quem estão falando. Isso pode ser via certificados de cliente SSL, compartilha segredos etc.

Tenho certeza de que alguém poderia argumentar que o SOAP é "mais seguro", mas provavelmente não de maneira significativa. A analogia do motociclista nu é atraente, mas, se exata, implicaria que toda a internet é insegura.

Ainda não tenho o representante necessário para adicionar um comentário ou apenas o adicionaria à resposta de Bell. Acho que Bell fez um bom trabalho ao resumir os prós e contras de alto nível das duas abordagens. Apenas alguns outros fatores que você pode querer considerar:

1) As solicitações entre seus clientes e seu serviço precisam passar por intermediários que exigem acesso à carga útil? Nesse caso, o WS-Security pode ser um ajuste melhor.

2) Na verdade, é possível usar o SSL para fornecer ao servidor segurança quanto à identidade do cliente usando um recurso chamado autenticação mútua. No entanto, isso não é muito útil fora de alguns cenários muito especializados devido à complexidade de configurá-lo. Portanto, Bell está certo de que o WS-Sec é um ajuste muito melhor aqui.

3) O SSL em geral pode ser um pouco difícil de configurar e manter (mesmo na configuração mais simples) devido, em grande parte, a problemas de gerenciamento de certificados. Ter alguém que sabe fazer isso para sua plataforma será uma grande vantagem.

4) Se você precisar fazer algum tipo de mapeamento de credencial ou federação de identidades, o WS-Sec poderá valer a pena. Não que você não possa fazer isso com o REST, você apenas possui menos estrutura para ajudá-lo.

5) Colocar todo o conteúdo da WS-Security nos lugares certos no lado do cliente pode ser mais difícil do que você imagina.

No final, apesar de realmente depender de muitas coisas que provavelmente não saberemos. Na maioria das situações, eu diria que qualquer uma das abordagens será "suficientemente segura" e, portanto, esse não deve ser o principal fator decisivo.

Brace yourself, here there's another coming :-)

Hoje tive que explicar à minha namorada a diferença entre o poder expressivo do WS-Security em oposição ao HTTPS. Ela é uma cientista da computação, portanto, mesmo que ela não conheça todo o XML Mumbo Jumbo que entende (talvez melhor que eu) o que significa criptografia ou assinatura. No entanto, eu queria uma imagem forte, que pudesse fazê-la realmente entender para que as coisas são úteis, e não como elas são implementadas (que vieram um pouco mais tarde, ela não escapou :-)).

Então é assim. Suponha que você esteja nu e precise dirigir sua motocicleta para um determinado destino. No caso (A), você passa por um túnel transparente: sua única esperança de não ser preso por comportamento obsceno é que ninguém esteja olhando. Essa não é exatamente a estratégia mais segura com a qual você pode sair ... (observe a gota de suor na testa do cara :-)). Isso é equivalente a um POST em claro, e quando digo "equivalente", quero dizer isso. No caso (B), você está em uma situação melhor. O túnel é opaco, portanto, desde que você entre nele, seu registro público estará seguro. No entanto, essa ainda não é a melhor situação. Você ainda precisa sair de casa e chegar à entrada do túnel e, uma vez fora do túnel, provavelmente terá que descer e caminhar para algum lugar ... e isso vale para HTTPS. Verdade, sua mensagem é segura enquanto atravessa o maior abismo: mas depois que você a entrega do outro lado, você não sabe realmente quantos estágios serão necessários antes de chegar ao ponto real em que os dados serão processados. E é claro que todos esses estágios poderiam usar algo diferente do HTTP: um MSMQ clássico que armazena em buffer solicitações que não podem ser atendidas imediatamente, por exemplo. O que acontece se alguém espreita seus dados enquanto eles estão naquele limbo de pré-processamento? Hum. (leia este "hm" como o pronunciado por Morfeu no final da frase "você acha que é o ar que está respirando?"). A solução completa (c) nesta metáfora é dolorosamente trivial: use roupas danadas em si mesmo e especialmente no capacete enquanto estiver na motocicleta !!! Assim, você pode circular com segurança sem precisar confiar na opacidade dos ambientes. A metáfora é esperançosamente clara: as roupas acompanham você, independentemente da média ou da infraestrutura circundante, como a segurança no nível de mensagens. Além disso, você pode optar por cobrir uma parte, mas revelar outra (e pode fazer isso pessoalmente: a segurança do aeroporto pode tirar sua jaqueta e sapatos, enquanto o médico pode ter um nível de acesso mais alto), mas lembre-se de que camisas de mangas curtas são má prática, mesmo que você tenha orgulho do seu bíceps :-) (melhor uma polo ou uma camiseta).

Fico feliz em dizer que ela entendeu! Devo dizer que a metáfora da roupa é muito poderosa: fiquei tentada a usá-la para introduzir o conceito de política (os clubes de discoteca não deixam você usar calçados esportivos; você não pode sacar dinheiro em um banco de cueca , embora isso seja perfeitamente aceitável ao se equilibrar em um surf; e assim por diante), mas achei que por uma tarde era o suficiente ;-)

Arquitetura - WS, idéias selvagens

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

Eu trabalho neste espaço todos os dias, então quero resumir os bons comentários sobre isso em um esforço para encerrar isso:

O SSL (HTTP / s) é apenas uma camada, garantindo:

1. O servidor ao qual está conectado apresenta um certificado que comprova sua identidade (embora isso possa ser falsificado por envenenamento de DNS).
2. A camada de comunicação é criptografada (sem escuta).

O WS-Security e os padrões / implementações relacionados usam PKI que:

1. Prove a identidade do cliente.
2. Prove que a mensagem não foi modificada em trânsito (MITM).
3. Permite que o servidor autentique / autorize o cliente.

O último ponto é importante para solicitações de serviço quando a identidade do cliente (responsável pela chamada) é fundamental para saber se eles devem estar autorizados a receber esses dados do serviço. SSL padrão é autenticação unidirecional (servidor) e não faz nada para identificar o cliente.

A resposta realmente depende de seus requisitos específicos.

Por exemplo, você precisa proteger suas mensagens da Web ou a confidencialidade não é necessária e tudo o que você precisa é autenticar terceiros e garantir a integridade das mensagens? Se for esse o caso - e geralmente ocorre com serviços da web -, o HTTPS provavelmente é o martelo errado.

No entanto - pela minha experiência - não negligencie a complexidade do sistema que você está construindo. Não apenas o HTTPS é mais fácil de implantar corretamente, mas um aplicativo que depende da segurança da camada de transporte é mais fácil de depurar (por HTTP simples).

Boa sorte.

REST sobre HTTPS Deve ser um método seguro, desde que o provedor da API implemente a autorização no final do servidor. Em um caso de aplicativo da Web, o que fazemos é acessar um aplicativo da Web via HTTPS e alguma autenticação / autorização; tradicionalmente, os aplicativos da Web não tinham problemas de segurança; a API Restful também combatia os problemas de segurança sem problemas!

Se sua chamada RESTFul enviar mensagens XML para frente e para trás incorporadas no corpo Html da solicitação HTTP, você poderá ter todos os benefícios do WS-Security, como criptografia XML, certificados etc. nas suas mensagens XML, enquanto estiver usando os recursos de segurança estão disponíveis em http, como criptografia SSL / TLS.