web-services - servicios - tipos de web services
Servicios web seguros: REST sobre HTTPS frente a SOAP+WS-Security. ¿Cual es mejor? (11)
No soy un experto en seguridad de ninguna manera, pero prefiero crear servicios web de estilo REST.
Al crear un nuevo servicio que necesita tener los datos que transmite de forma segura. Hemos entrado en un debate sobre qué enfoque es más seguro: REST con HTTPS o SOAP WS con WS-Security.
Tengo la impresión de que podríamos usar HTTPS para todas las llamadas al servicio web y este enfoque sería seguro. La forma en que lo veo es, "si HTTPS es lo suficientemente bueno para los sitios web bancarios y financieros, es lo suficientemente bueno para mí". Una vez más, no soy experto en este espacio, pero creo que estas personas han pensado mucho sobre este problema y se sienten cómodas con HTTPS.
Un compañero de trabajo no está de acuerdo y dice que SOAP y WS-Security son el único camino a seguir.
La web parece en general en esto.
Tal vez la comunidad aquí podría opinar sobre los pros y los contras de cada uno? ¡Gracias!
Como dices, REST es lo suficientemente bueno para los bancos, por lo que debería ser lo suficientemente bueno para ti.
Hay dos aspectos principales de la seguridad: 1) cifrado y 2) identidad.
La transmisión en SSL / HTTPS proporciona cifrado a través del cable. Pero también deberá asegurarse de que ambos servidores puedan confirmar que saben con quién están hablando. Esto puede ser a través de certificados de cliente SSL, comparte secretos, etc.
Estoy seguro de que uno podría argumentar que SOAP es "más seguro", pero probablemente no de manera significativa. La analogía del motociclista desnudo es linda, pero si es precisa implicaría que todo Internet es inseguro.
HTTPS asegura la transmisión del mensaje a través de la red y proporciona cierta seguridad al cliente sobre la identidad del servidor. Esto es lo que es importante para su banco o agente de bolsa en línea. Su interés en autenticar al cliente no está en la identidad de la computadora, sino en su identidad. Así que los números de tarjeta, los nombres de usuario, las contraseñas, etc. se utilizan para autenticarte. Por lo general, se toman algunas precauciones para garantizar que no se manipulen las presentaciones, pero, en general, se considera que lo que sucede en la sesión ha sido iniciado por usted.
WS-Security ofrece confidencialidad y protección de integridad desde la creación del mensaje hasta su consumo. Por lo tanto, en lugar de garantizar que el contenido de las comunicaciones solo pueda leerlo el servidor correcto, se asegura de que solo pueda leerse mediante el proceso correcto en el servidor. En lugar de suponer que todas las comunicaciones en la sesión iniciada de forma segura son del usuario autenticado, cada una debe estar firmada.
Hay una explicación divertida que involucra a los motociclistas desnudos aquí:
Por lo tanto, WS-Security ofrece más protección que HTTPS y SOAP ofrece una API más completa que REST. Mi opinión es que, a menos que realmente necesite las características adicionales o la protección, debe omitir la sobrecarga de SOAP y WS-Security. Sé que es un poco difícil, pero las decisiones sobre cuánta protección está realmente justificada (no solo qué sería genial construir) deben tomarlas quienes conocen el problema íntimamente.
La respuesta en realidad depende de sus requisitos específicos.
Por ejemplo, ¿necesita proteger sus mensajes web o no se requiere confidencialidad y todo lo que necesita es autenticar a las partes finales y garantizar la integridad del mensaje? Si este es el caso, y a menudo es con servicios web, HTTPS es probablemente el martillo equivocado.
Sin embargo, según mi experiencia, no olvide la complejidad del sistema que está creando. No solo HTTPS es más fácil de implementar correctamente, sino que una aplicación que depende de la seguridad de la capa de transporte es más fácil de depurar (a través de HTTP simple).
Buena suerte.
La seguridad REST depende del transporte, mientras que la seguridad SOAP no.
REST hereda las medidas de seguridad del transporte subyacente, mientras que SOAP define las suyas a través de WS-Security.
Cuando hablamos de REST, a través de HTTP, todas las medidas de seguridad aplicadas a HTTP se heredan y esto se conoce como seguridad de nivel de transporte.
Seguridad de nivel de transporte, asegura su mensaje solo mientras está en el cable - tan pronto como deja el cable, el mensaje ya no está asegurado.
Pero, con WS-Security, su seguridad a nivel de mensaje: aunque el mensaje abandone el canal de transporte, seguirá estando protegido. Además, con la seguridad del nivel de mensaje puede encriptar parcialmente el mensaje [no el mensaje completo, pero solo las partes que desea], pero con la seguridad del nivel de transporte no puede hacerlo.
WS-Security tiene medidas de autenticación, integridad, confidencialidad y no rechazo, mientras que SSL no admite el no repudio [con OAuth de 2 patas].
En términos de rendimiento, SSL es mucho más rápido que WS-Security.
Gracias...
REST sobre HTTPS debe ser un método seguro siempre que el proveedor de la API implemente la autorización de un servidor. En un caso de aplicación web, lo que hacemos es acceder a una aplicación web a través de HTTPS y cierta autenticación / autorización, tradicionalmente las aplicaciones web no tenían problemas de seguridad, ¡Restful API también podía contrarrestar problemas de seguridad sin problemas!
Si su llamada a RESTFul envía mensajes XML de ida y vuelta incrustados en el cuerpo HTML de la solicitud HTTP, debe poder tener todos los beneficios de WS-Security tales como encriptación XML, certificados, etc. en sus mensajes XML al usar las funciones de seguridad están disponibles en http, como el cifrado SSL / TLS.
Técnicamente, la forma en que lo tienes redactado, ninguno es correcto, porque la comunicación del método SOAP no es segura, y el método REST no dice nada sobre la autenticación de usuarios legítimos.
HTTPS evita que los atacantes eavesdropping la comunicación entre dos sistemas. También verifica que el sistema host (servidor) es en realidad el sistema host al que el usuario tiene la intención de acceder.
WS-Security evita que las aplicaciones no autorizadas (usuarios) accedan al sistema.
Si un sistema RESTful tiene una forma de autenticar usuarios y una aplicación SOAP con WS-Security está utilizando HTTPS, entonces realmente ambos son seguros. Es solo una forma diferente de presentar y acceder a los datos.
Todavía no tengo el representante necesario para agregar un comentario o simplemente lo habría agregado a la respuesta de Bell. Creo que Bell hizo un muy buen trabajo al resumir los pros y contras de alto nivel de los dos enfoques. Solo algunos otros factores que quizás desee considerar:
1) ¿Las solicitudes entre sus clientes y su servicio deben pasar por intermediarios que requieren acceso a la carga útil? Si es así, WS-Security podría ser una mejor opción.
2) En realidad, es posible usar SSL para proporcionar seguridad al servidor con respecto a la identidad de los clientes utilizando una función llamada autenticación mutua. Sin embargo, esto no tiene mucho uso fuera de algunos escenarios muy especializados debido a la complejidad de configurarlo. Bell tiene razón en que WS-Sec encaja mucho mejor aquí.
3) SSL en general puede ser un poco difícil de configurar y mantener (incluso en la configuración más simple) debido principalmente a problemas de administración de certificados. Tener a alguien que sepa cómo hacer esto para su plataforma será una gran ventaja.
4) Si necesita hacer algún tipo de mapeo de credenciales o federación de identidades, entonces WS-Sec podría valer la pena. No es que no puedas hacer esto con REST, solo tienes menos estructura para ayudarte.
5) Poner todo el polvo de WS-Security en los lugares correctos del lado del cliente puede ser más doloroso de lo que crees que debería ser.
Al final, aunque realmente depende de muchas cosas que probablemente no sepamos. Para la mayoría de las situaciones, diría que cualquiera de los enfoques será "lo suficientemente seguro" y, por lo tanto, ese no debería ser el principal factor decisivo.
Trabajo en este espacio todos los días, así que quiero resumir los buenos comentarios sobre esto en un esfuerzo por cerrar esto:
SSL (HTTP / s) es solo una capa que garantiza:
- El servidor al que se está conectando presenta un certificado que acredita su identidad (aunque esto puede ser falso a través del envenenamiento de DNS).
- La capa de comunicaciones está encriptada (sin escuchas).
WS-Security y los estándares / implementaciones relacionados usan PKI que:
- Demuestre la identidad del cliente.
- Demuestre que el mensaje no se modificó en tránsito (MITM).
- Permite al servidor autenticar / autorizar al cliente.
El último punto es importante para las solicitudes de servicio cuando la identidad del cliente (llamante) es primordial para saber SI deben estar autorizados para recibir dichos datos del servicio. El estándar SSL es la autenticación de un solo sentido (servidor) y no hace nada para identificar al cliente.
Ver el artículo de la wiki :
En situaciones punto a punto, la confidencialidad y la integridad de los datos también se pueden aplicar a los servicios web mediante el uso de Transport Layer Security (TLS), por ejemplo, mediante el envío de mensajes a través de https.
Sin embargo, WS-Security aborda el problema más amplio de mantener la integridad y la confidencialidad de los mensajes hasta que se envía un mensaje desde el nodo de origen, proporcionando la llamada seguridad de extremo a extremo.
Es decir:
- HTTPS es un mecanismo de seguridad de la capa de transporte (punto a punto)
- WS-Security es un mecanismo de seguridad de capa de aplicación (extremo a extremo).
Brace yourself, here there''s another coming :-)
Hoy tuve que explicarle a mi novia la diferencia entre el poder expresivo de WS-Security y el de HTTPS. Es una científica informática, por lo que incluso si no conoce todo el vocabulario XML, entiende (quizás mejor que yo) qué significa cifrado o firma. Sin embargo, quería una imagen fuerte, que pudiera hacer que realmente entendiera para qué son útiles las cosas, en lugar de cómo se implementan (eso vino un poco más tarde, ella no escapó a eso :-)).
Entonces dice así. Supongamos que está desnudo y tiene que conducir su motocicleta a un determinado destino. En el caso (A) pasas por un túnel transparente: tu única esperanza de no ser arrestado por comportamiento obsceno es que nadie está mirando. Esa no es exactamente la estrategia más segura con la que puedes salir ... (fíjate en la gota de sudor de la frente del chico :-)). Eso es equivalente a un POST en claro, y cuando digo "equivalente" lo digo en serio. En el caso (B), estás en una mejor situación. El túnel es opaco, por lo que mientras viajas en él, tu registro público es seguro. Sin embargo, esta no es la mejor situación. Todavía tiene que salir de casa y llegar a la entrada del túnel, y una vez fuera del túnel, probablemente tendrá que bajarse y caminar a algún lugar ... y eso se aplica a HTTPS. Es cierto que su mensaje es seguro mientras cruza el abismo más grande: pero una vez que lo entregó del otro lado, realmente no sabe cuántas etapas tendrá que atravesar antes de llegar al punto real donde se procesarán los datos. Y, por supuesto, todas esas etapas podrían usar algo diferente a HTTP: un MSMQ clásico que almacena temporalmente las solicitudes que no pueden ser atendidas de inmediato, por ejemplo. ¿Qué sucede si alguien acecha sus datos mientras están en ese limbo de preprocesamiento? Hm. (Lea este "hm" como el que pronunció Morpheus al final de la oración "¿cree que está respirando el aire?"). La solución completa (c) en esta metáfora es dolorosamente trivial: ponte un poco de ropa, especialmente el casco mientras estás en la motocicleta. Para que pueda navegar sin tener que depender de la opacidad de los entornos. La metáfora es, con suerte, clara: la ropa viene contigo independientemente de la infraestructura media o circundante, como lo hace la seguridad de nivel de mensaje. Además, puede decidir cubrir una parte pero revelar otra (y puede hacerlo a título personal: la seguridad del aeropuerto puede quitarse la chaqueta y los zapatos, mientras que su médico puede tener un mayor nivel de acceso), pero recuerde que las camisas de manga corta son mala práctica, incluso si está orgulloso de su bíceps :-) (mejor un polo, o una camiseta).
Estoy feliz de decir que entendió el punto. Debo decir que la metáfora de la ropa es muy poderosa: estuve tentado de usarla para introducir el concepto de política (los clubes de discoteca no te permiten llevar calzado deportivo; no puedes ir a retirar dinero en un banco en tu ropa interior) , mientras que esta es una apariencia perfectamente aceptable mientras te balanceas en una ola, y así sucesivamente) pero pensé que por una tarde era suficiente ;-)
Arquitectura - WS, Ideas salvajes