Diseño de base de datos cifrada segura

Question

Tengo un sistema de CRM basado en la web (perl/MySQL), y necesito una sección para Recursos Humanos para agregar detalles sobre las acciones disciplinarias y el salario.

Toda esta información que almacenamos en la base de datos debe ser encriptada para que los desarrolladores no podamos verla.

Estaba pensando en utilizar el cifrado AES, pero ¿qué uso debo usar como clave? Si utilizo la contraseña del Administrador de Recursos Humanos, si olvida su contraseña, perdemos toda la información de Recursos Humanos. Si ella cambia su contraseña, entonces tenemos que descifrar toda la información y volver a encriptar con la nueva contraseña, que parece ineficaz y peligrosa, y podría salir terriblemente mal si hay un error a la mitad del proceso.

Tuve la idea de que podría tener una clave de encriptación que encripta toda la información y usar la contraseña del administrador de recursos humanos para encriptar la clave. Luego puede cambiar su contraseña todo lo que quiera y solo necesitaremos volver a encriptar la clave. (Y sin la contraseña del administrador de recursos humanos, los datos son seguros)

Pero aún existe el problema del acceso multiusuario a los datos encriptados.

Podría conservar una copia sin formato de la clave del sitio y encriptarla con la contraseña de cada nuevo miembro del personal de recursos humanos. Pero luego conozco la llave maestra, que no parece ideal.

¿Alguien ha intentado esto antes, y ha tenido éxito?

Answer 1

GnuPG permite que los documentos se cifren utilizando varias claves públicas y se descifran utilizando cualquiera de las claves privadas correspondientes. De esta forma, puede permitir que los datos se cifren utilizando las claves públicas de todos en el departamento de recursos humanos.El descifrado podría ser realizado por cualquiera que tenga una de las claves privadas. El descifrado requeriría que el sistema conozca tanto la clave privada como la contraseña que protege la clave. Las claves privadas pueden mantenerse dentro del sistema y la frase de contraseña solicitada al usuario.

Los datos probablemente se abotargarían bastante con GnuPG usando muchas claves: tiene que crear una clave de sesión para la carga útil y luego encriptar esa clave usando cada una de las claves públicas. Las claves cifradas se almacenan junto con los datos.

Las partes débiles del sistema son que las claves privadas deben estar disponibles para el sistema (es decir, no bajo el control del usuario), y la frase de paso debe pasar por el sistema, por lo que podría verse comprometida (es decir, registrado, robado) por código dudoso. En última instancia, los datos brutos también pasan por el sistema, por lo que un código poco confiable podría comprometerlo sin preocuparse por las claves. La buena revisión del código y el control de liberación serán esenciales para mantener la seguridad.

Lo mejor es evitar el uso de las funciones de cifrado integradas de MySQL: estas se registran en los registros de replicación, lentos o de consulta y pueden ser visibles en la lista de procesos para que cualquiera que tenga acceso a los registros y la lista de datos.

Answer 2

¿Por qué no limitar el acceso a la base de datos o la tabla en general? Eso parece mucho más fácil. Si el desarrollador tiene acceso para consultar la producción, no hay manera de evitar que vean los datos b/c al final del día, la UI tiene que descifrar/mostrar los datos en cualquier momento.

En la experiencia que he tenido, la cantidad de trabajo que se necesita para lograr que los "desarrolladores no puedan ver datos de producción en absoluto" es inmensa y casi imposible. Al final del día, si los desarrolladores tienen que apoyar el sistema, será difícil de lograr. Si tiene que depurar un problema de producción, es imposible no dar acceso a los desarrolladores a los datos de producción. La alternativa es crear una gran cantidad de niveles y grupos de soporte, copias de seguridad, datos de prueba, etc.

Puede funcionar, pero no es tan fácil como los dueños de negocios pueden pensar.

Answer 3

Estoy pensando en voz alta.

Esto parece requerir un mecanismo de clave pública/privada. La información se almacenará encriptada con la clave pública de recursos humanos y solo podrá verla alguien que tenga la clave privada asociada.

Esto, para mí, parece descartar una interfaz basada en web para ver estos datos confidenciales (es ciertamente posible ingresarlos a través de la interfaz web).

Dado que los individuos van y vienen, atar las llaves a la cuenta de una persona específica parece inviable. En cambio, uno debe manejar la distribución de claves por separado y tener un mecanismo para que alguien cambie el par de claves utilizado (y volver a encriptar la base de datos — sin el uso de una interfaz web) en caso de que el actual gerente de recursos humanos sea reemplazado por otra persona. Por supuesto, nada evitaría que el gerente de RR. HH. Descargue todos los datos antes de irse antes de que se reemplacen las claves.

Answer 4

Otro enfoque es utilizar una sola clave de todo el sistema almacenada en la base de datos, quizás con una identificación única para que las nuevas claves puedan agregarse periódicamente. Usando el modo contador, el cifrado AES estándar de MySQL se puede utilizar sin exponer directamente el texto sin formato a la base de datos, y el tamaño de los datos cifrados será exactamente el mismo que el tamaño del texto sin formato. Un boceto del algoritmo:

1. La aplicación genera un valor de contador inicial único para el registro. Esto podría basarse en algún atributo único del registro, o podría generar y almacenar un valor único para este propósito.
2. La aplicación genera una secuencia de bloques de contador para el registro en función del valor del contador inicial. La secuencia de contador debe tener el mismo tamaño o hasta 1 bloque más grande que el texto sin formato.
3. La aplicación determina qué tecla usar. Si las teclas se rotan periódicamente, se debe usar la más reciente.

4. La corriente contador se envía a la base de datos a ser cifrados: algo como

   seleccione AES_ENCRYPT ('counter', clave) a partir de hrkeys donde id_clave = 'id';

5. El valor del contador cifrado resultante se recorta a la longitud del texto sin formato, y XORed con el texto claro para producir el texto encriptado.

6. El texto cifrado se almacena.
7. El descifrado es exactamente el mismo proceso aplicado al texto cifrado.

Las ventajas son que el texto claro nunca va a ninguna parte cerca de la base de datos, por lo que los administradores no pueden ver los datos confidenciales. Sin embargo, se queda con el problema de evitar que sus administradores accedan a los valores del contador cifrado o las claves. El primero se puede lograr mediante el uso de conexiones SSL entre su aplicación y la base de datos para las operaciones de cifrado. El segundo puede mitigarse con control de acceso, asegurando que las claves nunca aparezcan en los volcados de la base de datos, almacenando las claves en tablas en memoria para que el control de acceso no se pueda subvertir reiniciando la base de datos con "skip-grants". En última instancia, la única forma de eliminar esta amenaza es usar un dispositivo a prueba de manipulaciones (HSM) para realizar el cifrado. Cuanto mayor sea la seguridad que necesita, es menos probable que pueda almacenar las claves en la base de datos.

Ver Wikipedia - Counter Mode

Answer 5

No estoy seguro de qué tan factible esto es en la actualidad, o lo que los sistemas de base de datos estable actual tiene soporte para esto, pero los mecanismos de autenticación alternativos a nivel de base de datos puede ayudar. Por ejemplo, Drizzle, una refactorización de la base de código MySQL, admite (o tiene como objetivo?) Autenticación completamente conectable, que no permite auth, autho o auth alojado en el servidor a través de PAM o algún otro mecanismo, lo que significa que puede usar LDAP.

Si tenía diferentes niveles de acceso basados ​​en la conexión de la base de datos y el inicio de sesión de la aplicación también especificaba a qué podía acceder realmente en la base de datos, en teoría podría construir un sistema donde no fuera posible acceder a menos que se use una cuenta con derechos de acceso específicos, independientemente de los intentos de escalamiento de privilegios en la aplicación misma.

Siempre que las personas que configuran los derechos de acceso a la cuenta de usuario sean confiables o que ellos mismos puedan ver la información confidencial, esto debería ser bastante seguro.

P.S. Puede ser útil utilizar una conexión de base de datos genérica para la información de la aplicación "normal", pero cuando se intenta acceder a información confidencial, se intenta la conexión de base de datos específica. Esto permite que algunas conexiones de BD manejen la mayoría de las solicitudes, suponiendo que la mayoría de los usuarios no ve información confidencial. De lo contrario, una conexión DB separada por usuario puede ser una carga para el DB.