Comunicación de API segura RESTful entre múltiples servidores

Navega tus respuestas
3

Actualmente tengo el siguiente diseño:

  • Servidor alojado en la nube central con una API REST
  • Múltiples servidores remotos, cada uno con una API REST

Los datos se envían desde los servidores remotos al servidor central a intervalos regulares.

Los comandos se envían desde el servidor central a servidores remotos individuales en forma de POST a la API REST que se ejecuta en el servidor remoto.

Estoy preocupado por la seguridad. Lo más importante es evitar que se emitan comandos no autorizados a los servidores remotos.

Actualmente estoy usando autenticación basada en token. Cada servidor remoto tiene un token sin vencimiento emitido por el servidor central que se almacena en un archivo de configuración en el sistema de archivos del servidor remoto. Este token se pasa en el encabezado de Autorización de las solicitudes POST que se originan en el servidor remoto.

La otra dirección de comunicación funciona de manera similar. Cada servidor remoto genera un token para el servidor central que se almacena en una base de datos relacional en la misma red que el servidor de la nube central.

Mis problemas con este diseño:

  • Si la base de datos está en peligro, el atacante puede emitir comandos a los dispositivos remotos: esencialmente estoy almacenando contraseñas en texto sin formato en la base de datos
  • Si el sistema de archivos de un dispositivo remoto está comprometido, el atacante obtiene acceso al token

¿En qué formas puedo mejorar este diseño? La comunicación desde el servidor de la nube central al dispositivo remoto no tiene por qué ser una API REST. Parece que lo que necesito es una especie de apretón de manos bidireccional entre los dos servidores. ¿Cómo se puede lograr eso con una API REST?

Algunas notas:

  • Ambos apis de descanso se sirven a través de HTTPS
  • Los dispositivos remotos a menudo pierden la conectividad a Internet por períodos de tiempo
  • Los dispositivos remotos corren el riesgo de ser robados físicamente

Algunas cosas que he considerado:

  • Podría conectar todos los servidores a la base de datos alojada central y usar eso para la comunicación. Esto no parece ideal porque parece un riesgo de seguridad al tener estos dispositivos remotos conectados directamente a la base de datos. Además, los servidores remotos a menudo pierden conectividad.
  • Restrinja el acceso a los servidores remotos a una lista blanca de direcciones IP, incluido el servidor remoto central
pregunta Water Malone 06.02.2018 - 23:18
fuente

1 respuesta

2

Debido a que le preocupa principalmente la seguridad de su programa (es decir, evitar que alguien emita comandos a sus clientes), también tiene que identificar su modelo de amenaza. Por ejemplo, si está enviando comandos a un programa para desbloquear la puerta principal, su enfoque al diseñar la aplicación se vuelve muy diferente a si solo está enviando datos sin sentido, como "¡Hola mundo!".

Una vez que haya definido eso, puede tomar la decisión de si debe marcar una contraseña en su base de datos y bloquear la clave en una contraseña segura o de texto simple que podría funcionar para datos insignificantes. Trataré de hablar con tu aplicación sin conocer cada detalle.

Ya estás usando SSL / TLS, así que es un gran comienzo. Ha implementado una forma de autenticación, una forma en que los clientes pueden demostrar al servidor que son legítimos. Usted tiene control físico sobre los hosts, así que asumo que nadie puede obtener acceso físico. Si tiene IP estáticas, seguro, agregue una lista blanca y un posible servidor de seguridad para restringir ciertos métodos http (GET, POST). Puede considerar un proxy de front-end como Nginx para hacer todo esto en el servidor. Le sugeriría encarecidamente que no permita que los clientes se conecten a la base de datos. Solo permita que el servidor realice conexiones a la base de datos. Mencionas que estás almacenando contraseñas en la base de datos, ¿por qué no las hash / salt? De nuevo, depende de tu modelo de amenaza.

Usted menciona que las máquinas cliente están bajo su acceso físico pero podrían ser robadas. Si un atacante tiene acceso físico a un cuadro, todas las apuestas están desactivadas. Su mejor apuesta aquí sería identificar lo más rápido posible que un cliente esté comprometido. Ya estás utilizando tokens, ¿por qué no tienes un tiempo de caducidad?

Por último, cualquier dato enviado desde los clientes a su servidor debe, debe y debe ser limpiado y verificado. Si tiene una idea de cómo se ven los datos, configure una plantilla y los datos recibidos que no coincidan con ellos, rechácelos

    
respondido por el pm1391 07.02.2018 - 03:08
fuente

Lea otras preguntas en las etiquetas

¿Es peligroso instalar el certificado 802.1x de mi trabajo? [duplicar] Almacenamiento de claves de cifrado [cerrado]