Cifrando datos sin sacrificar el rendimiento de la consulta

5

Estamos creando una aplicación web en la nube respaldada por una base de datos de múltiples inquilinos. Para maximizar la seguridad, planeamos encriptar los datos de cada cliente con una clave separada. El problema es la consulta. Supongamos que están en el redactor de informes y desean ordenar su tabla de 1,000,000 de clientes por Apellido. ¡Eso se llevaría a cabo horriblemente porque todas las filas de 1M tendrían que estar sin cifrar y luego ordenarse en cada consulta!

Aquí están las únicas opciones que podría encontrar. ¿Qué harías? ¿Hay otras opciones?

  1. Solo cifre las columnas NPI en la base de datos y nunca les permita ordenar o filtrar por valores NPI.

    PRO : protege los datos confidenciales al tiempo que proporciona un excelente rendimiento de consulta en columnas que no son NPI

    CON : no es un gran UX para nuestros usuarios

  2. Igual que el # 1, pero mantiene un caché sin cifrar de columnas NPI en la RAM

    PRO : Mejor UX

    CON : ahora DataInUse no está encriptado (¿es eso mejor que DataAtRest no encriptado?). Además, los filtros con columnas NPI y no NPI serían muy difíciles de codificar. Por ejemplo, si el filtro fue SELECCIONAR TODOS LOS CLIENTES DONDE EL ÚLTIMO NOMBRE DE "S%" Y BIZTYPE="MÉDICO", las ID de los registros del último nombre primero deben provenir de la caché y luego enviarse a la base de datos para limitar aún más los registros por biztype. / p>

  3. Renuncie y mantenga todos los datos sin cifrar en la base de datos y aplique el cifrado db (SQLServer TDE) o el cifrado de disco.

    PRO : excelente experiencia de usuario y rendimiento

    CON : el rendimiento se vería afectado. Además, si la clave estuviera comprometida, todos los datos de nuestros clientes serían expuestos y estaríamos en la portada del Wall Street Journal.

pregunta sisdog 11.07.2015 - 02:48
fuente

3 respuestas

1

El problema es tu solución:

"Para maximizar la seguridad, planeamos cifrar los datos de cada cliente con una clave separada".

Deja de hacer eso. Utilice una clave separada para cada cliente no escala. Utilice una sola clave para toda la base de datos.

    
respondido por el Khürt Williams 29.09.2015 - 14:18
fuente
0

Una sugerencia de variante: 1. Cree un nuevo registro de ID para cada nuevo cliente cargado 2. Encripta el SSN 3. Trabajar solo con la nueva ID para seleccionar / recuperar

PRO: rendimiento mantenido, SSN encriptado CON: una nueva identificación para memorizar para los usuarios

    
respondido por el Philippe Bellamit 11.07.2015 - 08:43
fuente
0

¿Ha considerado el hashing de los datos que desea indexar?

La idea es simple. Usted agrega una columna donde almacena el hash salted / peppered del Apellido, al lado de la columna Apellido. Cuando el servidor necesita buscar al Sr. Smith, simplemente hash el nombre Smith y luego busca ese valor de hash.

El problema de este enfoque es que es posible obtener información en la base de datos de los hashes.

    
respondido por el Aron 13.07.2015 - 20:24
fuente

Lea otras preguntas en las etiquetas