Restricción de la exposición del código fuente

0

Supongamos que no confía en los técnicos (o en la administración) del centro de datos, pero no tiene otra opción que alojar su aplicación web con ellos.

Además, supongamos que desea mantener ciertos archivos inaccesibles para las personas que sí tienen acceso al servidor con capacidad en rack (en vivo) y en rack (apagado).

Pregunta
¿Qué tan efectiva sería la siguiente configuración para proteger el código fuente y otros archivos confidenciales?

Método de protección:

Supongamos que la aplicación utiliza la siguiente pila: LEMP + Redis + Node (Websocket)

A. Configuración de una sola vez

  1. Deshabilitar el inicio automático de Nginx, Redis y MySQL
  2. Cree un directorio raíz para una partición RAMDISK: %código%
  3. Cambiar el directorio de datos de MySQL a mkdir -p /media/private

B. Después de cada reinicio

  1. Crea y monta una partición RAMDISK:
    /media/private/mysql
  2. Crear subdirectorios requeridos bajo mount -t tmpfs -o size=2048M tmpfs /media/private/
  3. Cargue los archivos de datos MySQL, el archivo de configuración Nginx, los archivos de certificado SSL, el archivo de configuración de Redis, los archivos fuente de PHP y los archivos de la aplicación del nodo en el directorio correspondiente debajo de /media/private
  4. Inicie el servidor de Redis con una configuración personalizada
  5. Iniciar el servidor MySQL
  6. Inicie Nginx con una configuración personalizada
pregunta Majid Fouladpour 26.07.2018 - 19:01
fuente

2 respuestas

0

[Sigo pensando que mi respuesta de desafío de marco se mantiene, así que estoy publicando una segunda respuesta abordar la aclaración en los comentarios]

Si estoy entendiendo tu pregunta correctamente;

Objetivo de seguridad: evita que alguien con acceso físico al servidor (ya sea durante la ejecución o apagado) acceda a cualquier archivo dentro del sistema operativo.

Solución propuesta: No almacene nada en el disco. En el arranque, cree un disco RAM y cargue todos los archivos confidenciales directamente en el disco RAM.

(¿correcto hasta ahora?)

En primer lugar, está introduciendo un punto único de error masivo en esa carga masiva después del reinicio. ¿Cómo se asegura eso? ¿De dónde vienen los archivos? ¿Qué endurecimiento de seguridad y prácticas hay en esa máquina? ¿Puede un atacante bloquear la carga a DoS de su servidor? etc. etc.

A continuación, su solución puede proteger contra su información confidencial que termina en imágenes de disco, pero ¿por qué utilizar su propia solución en lugar de usar soluciones estándar para este problema, como el cifrado de disco completo? Su proveedor de la nube ofrecerá un cifrado en reposo que interactúa con su sistema de administración de claves ( AWS por ejemplo ), y / o habilitar el cifrado de disco en el nivel del kernel de Linux requiere una contraseña en el arranque.

Finalmente, su solución no protege contra los volcados de memoria (tal vez a través del acceso físico como ataque de arranque en frío , tomando una instantánea en vivo / volcado de memoria a través del hipervisor, otros?). Nuevamente, no hagas tu propio rollo, ¿pero quizás busques en el cifrado de la memoria?

respondido por el Mike Ounsworth 26.07.2018 - 21:49
fuente
0

Creo que estás haciendo esto al revés; está definiendo una solución y preguntando si es segura para las personas "con acceso al servidor", pero no nos ha dicho a qué nivel de "seguridad" apunta.

Vamos a desenrollar eso; seguro contra qué? ¿Qué niveles de acceso intenta bloquear y en qué momento está dispuesto a dejarlo pasar?

  • ¿Seguro contra los administradores de red que llegan a los puertos de su máquina virtual? Probablemente ya tenías eso.
  • ¿Seguro contra administradores de sistemas que pueden acceder a la imagen de disco de su máquina virtual? Esto puede ayudar, aunque puede haber más soluciones disponibles, como proporcionar una contraseña de cifrado de disco completo en el arranque.
  • ¿Seguro contra administradores de sistemas que pueden obtener claves ssh para su máquina virtual? Esto probablemente no ayuda.
  • ¿Seguro contra administradores de sistemas que pueden tomar volcados de memoria directos de su máquina virtual en ejecución? Es probable que esto no sea de ayuda, aunque puede considerar el cifrado de la memoria.
  • Protéjase contra los empleados del centro de datos que pueden arrancar las unidades de memoria RAM de la máquina y sumergirlas en nitrógeno líquido en un ataque de arranque en frío ? Es probable que esto no sea de ayuda, aunque puede considerar el cifrado de la memoria.

Por lo tanto, te sugiero que lo hagas de otra manera: define el nivel de seguridad que deseas y luego diseña una solución que lo alcance.

[disculpa por dar una no-respuesta, pero siento que esto necesita un frame-challenge ]

    
respondido por el Mike Ounsworth 26.07.2018 - 20:37
fuente

Lea otras preguntas en las etiquetas