Depende de su caso de uso y de lo que quiere decir con arrendamiento múltiple. Veo 2 posibles “significados” e intentaré responder a ambos.
Tenga en cuenta que dado que estamos hablando de seguridad, también debe averiguar cuál es su modelo de amenaza. ¿Solo desea que los usuarios no puedan leer los datos de los demás? ¿Confías en tu DBA? ¿O no confía en su servidor / proveedor de DB por completo?
Multicliente: los datos del usuario están encriptados, pero no se necesita soporte para “consultas de texto sin formato” / consultas sobre texto cifrado.
- ¿Las compañías antivirus comparten datos con las agencias de inteligencia?
- ¿Cuáles son las principales prácticas de prueba de seguridad para una aplicación web?
- ¿Las compañías antivirus están detrás de virus y ransomware como WannaCry?
- Cómo averiguar quién hackeó mi cuenta de Facebook
- Cómo saber la contraseña del Wi-Fi al que está conectada mi PC
Bueno, este es un caso “clásico” / sencillo. Algunos DBMS tienen funciones que lo facilitarían.
Sin embargo, mis modelos de amenaza habituales no permitirían el uso de estas funciones (porque confiaría al servidor sus claves de cifrado, aparte del hecho de que el conjunto de funciones disponibles es muy limitado).
El “soporte” para esta “característica” debe estar en la aplicación cliente y no en el servidor DB. La aplicación cliente encripta sus datos (atributos) antes de la inserción / actualización. Luego, también debe cifrar los valores de los atributos en sus consultas (ya que se cifraron en la inserción)
Ejemplo: en lugar de ejecutar esta consulta para recuperar las transacciones emitidas por el usuario 12345
SELECT * FROM transacciones DONDE emitterId = 12345;
Debe encriptar “12345” (digamos que la representación hexadecimal de texto cifrado es “cd22131bdef8”) y luego usar su texto cifrado en su consulta. A saber:
SELECT * FROM transacciones DONDE emitterId = CONV (“cd22131bdef8”, 16,10);
Pero surgen múltiples desafíos con un esquema de ese tipo. Éstos son algunos de ellos :
- ¿Qué atributos de datos cifraría y cuáles dejaría en texto sin formato, sabiendo los riesgos que esto conllevaría?
- ¿Cómo ejecutar “consultas ordenadas” en datos cifrados? (Por ejemplo: ordenar por un atributo dado, cláusulas “WHERE” con desigualdades)
- Es una muy mala práctica usar el mismo IV varias veces. ¿Cómo debe almacenar las transacciones / filas para el usuario con “123”, sin revelar que es el mismo usuario y sin complicar el proceso de recuperación?
- ¿Cómo se realiza una búsqueda de texto completo en una cadena encriptada?
- Desea permitir que los usuarios almacenen sus datos en forma encriptada, de modo que nadie más pueda leerlos. Sin embargo, ¿qué haría si quisiera compartir algunas partes de los datos entre un pequeño subconjunto de usuarios, sin comprometer la seguridad?
- ¿Cómo se construye una estructura de tabla que no indica mucho sobre la estructura de datos? es decir: cómo oculta los nombres de las columnas, sin tener que usar los nombres “ocultos” en su consulta.
Muchos de estos problemas se resuelven (al menos en parte) en la solución que se sugiere a continuación.
Multicliente: los datos del usuario se cifran sobre la marcha, y puedo enviar “consultas de texto sin formato” y recibir “resultados de texto sin formato” (las consultas se realizan en el texto cifrado)
No hay un DBMS principal de código abierto que lo admita de forma inmediata. Sin embargo, ha habido un “intento académico” para construir dicho sistema, llamado CryptDB. Es un servidor proxy (entre su servidor DB y sus clientes DB) para MySQL que realiza las operaciones de “cifrado / descifrado”, utilizando claves derivadas de las contraseñas de los usuarios.
Debe leer el documento (disponible en su sitio web). Su modelo de amenaza es bastante exhaustivo, y su implementación es de código abierto. Tiene algunos bordes ásperos (es decir, para algunas operaciones, los resultados son correctos al 95%; faltan algunos datos). Sin embargo, aún no lo he usado, porque todavía no he trabajado en una aplicación que necesita multicliente con tal nivel de seguridad.
