Seguridad de extremo a extremo para los servicios REST, ¿algún estándar emergente?

Navega tus respuestas
6

Trabajo con la integración en el sector de la salud, donde la seguridad de extremo a extremo es importante. Nos integramos con numerosos servicios SOAP y utilizamos las funciones de seguridad de WS para cifrar y firmar solicitudes y respuestas.

Las solicitudes y respuestas pasan por varios niveles intermedios en nuestro escenario de integración. Por lo tanto, es importante que los datos en sí estén cifrados (seguridad del mensaje). El uso de HTTPS (seguridad de transporte) solo protege el mensaje hasta la terminación SSL.

También nos integramos con servicios estilo REST. AFAIK, no existe un enfoque estándar (como WS-security) para asegurar las cargas útiles REST.

¿Existen estándares emergentes para firmar y cifrar las cargas útiles REST?

EDIT

pregunta codeape 12.10.2015 - 15:14
fuente

3 respuestas

2

Creo que estás preguntando acerca de la propagación de identidad a través de una pila RESTful. En otras palabras, desea vincular la solicitud al usuario original para que los sistemas posteriores puedan validar la autorización por usuario. También he estado investigando este problema recientemente.

En el fondo, no, no hay un estándar definido para la propagación de identidad para los servicios REST. REST en sí no es un estándar, sino un patrón arquitectónico.

Algunas bibliotecas proporcionan integración con estándares existentes, como Kerberos (como JAX-RS ) o SAML a través de enlaces HTTP .

Varios enfoques que utilizan JSON Web Tokens (JWT) se están volviendo populares, pero se trata más bien de un enfoque "roll-your-own", que ofrece flexibilidad pero a costa de los riesgos de implementación. Esto es un poco sangrante. El RFC para JWT solo se aprobó en abril de 2015.

    
respondido por el JaimeCastells 12.10.2015 - 18:49
fuente
0

Si la seguridad de extremo a extremo es un factor crítico, el mejor enfoque para adoptar no es confiar en nada en el medio. Entonces, se vuelve irrelevante qué protocolos o API se usan entre ellos ya que pueden o no ser seguros. En mi opinión, este es un supuesto razonable: en cualquier sistema razonablemente complejo con múltiples niveles intermedios, no hay garantía de que sus canales de comunicación estén protegidos adecuadamente. O que no almacenen datos en caché inadvertidamente más tiempo del que necesitan y, como consecuencia, abren una ventana donde se pueden revelar datos confidenciales.

Sugerencia:

  • El servidor de destino genera un par de claves (claves públicas + privadas). P.ej. RSA con 4096 bits.
  • Distribuir la clave pública al cliente. P.ej. Los clientes móviles podrían tener la clave pública ya empaquetada en la aplicación.
  • El cliente cifra los datos confidenciales con la clave pública y envía el texto cifrado. Solo el servidor de destino puede descifrar el texto cifrado.
respondido por el HTLee 16.10.2015 - 00:18
fuente
0

JWT es principalmente para autenticación, aunque puede personalizar el token para incluir roles y usarlo para autorización.

Para firmar y cifrar mensajes http, puede consultar JSON Web Signature (JWS) y JSON Web Encryption (JWE). Ambos son RFC que forman parte del marco de JSON de firma y cifrado de objetos (JOSE).

    
respondido por el Paulo Merson 12.08.2018 - 03:29
fuente

Lea otras preguntas en las etiquetas

Qué usar como 'estado' en el flujo de trabajo OAuth2 Authorization Code Grant ¿Por qué no hay un exploit de arranque en frío similar a FROST para iOS?