Variables de entorno de Rails de texto sin formato y seguridad

3

Trabajo para una empresa de atención médica que hace hincapié en la seguridad, debido a la sensibilidad de los datos con los que trabajamos. Recientemente, hemos estado realizando muchas auditorías (internas y externas) de nuestra "pila" actual para garantizar que cumplimos con los diversos requisitos del cliente.

Un tema de discusión reciente es alrededor de las variables de entorno. Usamos la gema dotenv, por lo que almacenamos muchas de estas variables en un archivo .env (ignorado en git) en el servidor web. Estas variables incluyen las credenciales de nuestra base de datos, las credenciales SMTP y varias claves de API.

Cuando ciertos líderes se enteraron de que dichas credenciales se almacenaban en el servidor web en texto sin formato, expresaban preocupación. Esa preocupación ha provocado una discusión sobre el cifrado de esas variables. Veo los méritos del cifrado y sin duda sería valioso para proteger nuestras claves API y similares. Sin embargo, cuestiono el valor que ofrece para proteger los datos almacenados en nuestro servidor de bases de datos (que en última instancia es la mayor preocupación) ... de lo que estamos hablando es de un usuario malintencionado que obtiene acceso a nuestro servidor web. A menos que me falte algo, ese usuario todavía podría abrir una consola de rieles, que cargará la aplicación, manejará el descifrado de las credenciales y le permitirá consultar la base de datos utilizando nuestros modelos (por ejemplo, Patient.all). Me parece que si nuestro servidor web se ve comprometido, estamos controlados independientemente de si ciframos esas variables. Tengo razón en eso?

Suponiendo que lo soy, ¿cómo respondo a esta inquisición con algo más concreto que "bueno, así es como funciona Rails" (con respecto a la posibilidad de abrir una conexión al DB a través de los rieles c)?

    
pregunta RonMexico 12.01.2017 - 17:56
fuente

3 respuestas

1

Lo que importa aquí es una cuestión de amenazas y de líneas de defensa. Las amenazas que puedo imaginar son:

  • una vulnerabilidad en el servidor web permite a un atacante leer archivos de las carpetas de la aplicación web
  • una vulnerabilidad en el servidor web permite a un atacante leer las variables de entorno de la aplicación
  • una vulnerabilidad en el servidor web le permite a un atacante ejecutar comandos arbitrarios en nombre de la aplicación legítima
  • una vulnerabilidad en el servidor (independientemente de la aplicación web) le permite a un atacante obtener acceso al servidor

Luego, tienes 2 posibles líneas de defensa (lo ideal es que combines ambas)

  1. reducir el riesgo de exposición

    • asegúrese de que la pila de aplicaciones web esté parcheada consistentemente
    • asegúrese de que la aplicación web esté oculta detrás de un proxy inverso: esto puede ayudar a garantizar que solo las solicitudes HTTP a aceptables las URL puedan llegar al servidor; la reescritura de la URL del proxy puede asignar las URL entrantes a una ruta secundaria para garantizar que no se pueda recibir una URL en la raíz
    • asegúrese de que el centro de datos esté protegido correctamente detrás de un firewall y que todos los servidores sigan las reglas de mejores prácticas (accesos de administrador limitados, solo puertos necesarios abiertos, etc.)
  2. reducir las posibles consecuencias de un ataque exitoso

    • configurar el análisis de registro para detectar el acceso ilícito y reducir la ventana de tiempo de un ataque
    • Si el atacante podría leer la variable de entorno, pero no puede ejecutar ningún comando, asegúrese de que no se pueda acceder al servidor de la base de datos desde fuera del centro de datos.
    • si los datos son muy confidenciales, incluso puede proteger el acceso a la base de datos incluso si el servidor de aplicaciones web se vio comprometido mediante el uso de una API que requiere una autenticación previa del cliente y pasa el token del cliente a un servidor de aplicaciones de servicio que puede realizar controles de autorización . La defensa completa se convierte aquí:

      external_firewall - reverse_proxy - web_server - internal_firewal- application_server
      

El cifrado en el servidor solo puede ser una ofuscación, porque la clave de descifrado debe estar accesible en algún lugar. Solo puede endurecer la tarea para el atacante, pero no podrá bloquearlo.

    
respondido por el Serge Ballesta 12.06.2017 - 10:09
fuente
1

El problema que tienes es que las variables de entorno pueden filtrarse en algunas circunstancias que son menos serias que un atacante que obtiene acceso de shell interactivo a tu host (un buen artículo que describe algunos de los posibles riesgos es " Variables de entorno consideradas perjudiciales para sus secretos ". También almacenar secretos en texto sin formato puede presentar riesgos de que un atacante obtenga acceso a los no contados disco, desde copias de seguridad o similares.

Como ejemplo, supongo que haces una copia de seguridad del archivo .env de alguna manera, por lo que existe un riesgo de acceso no autorizado a esa copia de seguridad.

Una de las cosas que considera ver es una solución de "administración de secretos" para ayudar a administrar cosas como esta. Cosas como Hashicorp Vault o, si está usando Docker, puede usar Docker secrets

    
respondido por el Rоry McCune 12.06.2017 - 10:34
fuente
0

Tienes razón al considerar esos otros métodos de entrada en los datos sin cifrar. Sin embargo, a menudo los atacantes no obtienen acceso total a un servidor, sino solo parcial, y eso es la verdadera cosa contra la que protegería. Por ejemplo, podría haber una vulnerabilidad en su aplicación que le permita a un atacante ver un volcado de todas las variables de entorno disponibles para la aplicación (algo similar a un phpinfo() no protegido, pero para Rails); eso les daría acceso si las variables de entorno no están cifradas, pero si se cifran, coloca un obstáculo.

A través de varios escenarios para encontrar exactamente contra qué está protegiendo, es una excelente manera de evaluar cualquier característica de seguridad propuesta. Este tipo de "protección contra un atacante que solo puede hacer esto de una manera limitada, pero no esta otra cosa" puede ser útil a veces, pero a veces proporciona mucha complejidad para prácticamente ningún beneficio del mundo real; escribir sus suposiciones hace que sea un poco más claro y más fácil de evaluar si tiene sentido para su organización o no.

    
respondido por el Xiong Chiamiov 12.01.2017 - 19:33
fuente

Lea otras preguntas en las etiquetas