Almacenar la configuración de forma segura en un entorno de alojamiento compartido semi confiable

5

Estoy buscando un patrón para almacenar un archivo de configuración que contenga información confidencial en un entorno de alojamiento semi confiable. Confío en este caso, lo que significa que confío en ellos en general, pero no con esta información (contraseñas).

En este caso, estoy escribiendo un demonio simple para ver los cambios en una carpeta y enviar esos cambios a una base de datos alojada en otro lugar. Preferiría no almacenar los detalles de esa base de datos en texto sin formato en este entorno semi confiable, ya que no estoy seguro de si los administradores mismos lo usarían maliciosamente.

Mi plan original era configurar los scripts de informes necesarios en mi entorno no confiable y luego ejecutarlos de forma remota desde una ubicación confiable, enviando configuraciones de configuración en cada ejecución. Sin embargo, parece que registran todos los comandos ejecutados en sus servidores, por lo que esto es un no ir ya que simplemente podrían revisar esos registros.

Alternativamente, podría tener una segunda base de datos de capa, cuyas credenciales almaceno en su servidor. Esta base de datos actuaría como un intermediario, permitiendo que un conjunto de scripts en un entorno no confiable empuje datos hacia él, y otro conjunto de scripts en un entorno confiable para extraer datos de él y moverlos a su destino final. Estoy menos preocupado por la corrupción maliciosa de los datos, y si acceden a esta base de datos, no es un gran problema, ya que está completamente separado de mi principal almacén de datos.

Este método es bastante engorroso y no es exactamente seguro, por lo que preferiría evitarlo si puedo.

Desafortunadamente, alejarse de este entorno no confiable no es una opción.

    
pregunta William King 22.05.2013 - 04:32
fuente

3 respuestas

4

Si le preocupa que los administradores indagan activamente en su aplicación, no hay nada que pueda hacer, excepto nunca usar su sistema con datos confidenciales. Independientemente de lo que haga su programa para descifrar o recuperar credenciales, también pueden hacerlo. Por el mismo motivo, debe confiar en que no permitirán el acceso administrativo a su sistema a ningún tercero no confiable.

Un área donde hay un margen para mitigar los riesgos es el tiempo de reacción en caso de una infracción. Es difícil dar consejos generales allí porque se trata de un compromiso entre la disponibilidad y la confidencialidad. Si ocurre algo “extraño”, ¿desea eliminar el sistema lo más rápido posible (y avisarle para que venga y ordene todo el lío antes del servicio?) puede ser restaurado), o desea seguir corriendo el mayor tiempo posible y notificarle que algo puede estar mal? Tenga en cuenta que, incluso con el mejor esfuerzo, nunca puede estar seguro de que no se detectará una infracción.

Puede reducir ligeramente el riesgo almacenando las credenciales de forma remota y recuperándolas en cada conexión o en intervalos cortos. Para obtener mejores resultados, use una contraseña que cambie automáticamente cada pocos minutos. De esa manera, si el servidor está comprometido pero el atacante no estuvo inicialmente después de su aplicación, es posible que tenga un poco de tiempo de reacción para decidir si apagar el servicio; simplemente desactive el acceso a las credenciales. Esto no es infalible; Si el atacante está detrás de su aplicación, comenzará a usar las credenciales antes de que pueda reaccionar. En cualquier caso, asegúrese de que puede cambiar las credenciales rápidamente antes de romper cualquier otra cosa (por lo que no es necesario cambiar la contraseña en 20 lugares diferentes).

Otra forma de mitigar el riesgo es otorgar a este sistema semi-confiable tan pocos privilegios como sea posible. En su situación, el sistema semi-confiable solo necesita introducir cambios en una base de datos en otro lugar, así que no le dé ninguna credencial al sistema semi-confiable que le permita acceder a la base de datos directamente. Solo dale permiso para agregar registros a una tabla, o algo así. Utilice una aplicación proxy (que se ejecute en un entorno de plena confianza) en lugar del acceso directo a la base de datos para realizar esta verificación de autorización y haga que registre todo lo que hace. De esa manera, si el sistema de confianza parcial se ve comprometido, puede terminar con registros falsos (junto con una marca de tiempo y tal vez otra información que pueda permitirle clasificar los registros buenos de los falsos) pero cualquier cosa que no se derive de estos los registros seguirán siendo seguros.

    
respondido por el Gilles 26.05.2013 - 13:34
fuente
1

No pierdas tu tiempo en esto. No hay nada que puedas hacer. Está colocando sus datos en un servidor que no es suyo, y las personas que administran este servidor pueden tener acceso a sus datos.

Digamos que encontró la mejor manera de almacenar las credenciales de la base de datos de forma segura. El administrador de su servidor tiene una cuenta DBA que puede acceder a su base de datos de todos modos. Nada de lo que hagas resolverá esto, ni siquiera un VPS (Virtual Private Server). Así que aquí están tus opciones:

  • Obtenga una conexión de alta velocidad y hardware de nivel de servidor, y construya su propio servidor en el hogar, la oficina o cualquier ubicación de confianza.

  • Regístrese con un servidor web confiable y bien evaluado.

respondido por el Adi 22.05.2013 - 08:46
fuente
0

Si el sitio puede acceder a él, los administradores pueden acceder a él. Si quisieran, simplemente podrían modificar su sitio web para mostrar la información de configuración. No hay forma de protegerlo si el sitio necesita acceder a él. La única alternativa es pasar a un entorno de confianza. Los servidores privados virtuales son bastante baratos en estos días.

    
respondido por el AJ Henderson 22.05.2013 - 05:55
fuente

Lea otras preguntas en las etiquetas