¿Es un índice de búsqueda de Lucene una puerta trasera para el cifrado a nivel de campo?

Navega tus respuestas
4

Para proteger la información de identificación personal (PII) en una base de datos SQL, hemos implementado el cifrado a nivel de campo. Sin embargo, debemos permitir la búsqueda de texto completo en algunos de esos datos.

Una idea que estaba considerando era crear un índice de búsqueda de Lucene de los valores no cifrados, pero asegurando que todos los campos que contienen PII estén indexados pero no almacenados.

El proceso funcionaría así:

  1. El usuario envía, por ejemplo, un número de identificación nacional parcial en un formulario de búsqueda en la aplicación.
  2. La aplicación envía la consulta a Lucene.
  3. Lucene devuelve una colección de documentos. Los documentos no contienen ninguna PII; más bien, cada documento contiene el valor PK del registro correspondiente en la base de datos SQL.
  4. La aplicación recupera los registros correspondientes de la base de datos y descifra los valores para mostrarlos al usuario.

Sin embargo, esto deja abierta la pregunta, si alguien tuviera acceso de lectura a los archivos de índice de Lucene, ¿podrían reconstruir los valores sin cifrar?

    
pregunta user5568265 19.01.2016 - 20:05
fuente

2 respuestas

2

Según un artículo de 2013 , la respuesta esta pregunta parece ser: "Sí, a menos que no te importe que tu índice de búsqueda sea básicamente inútil":

  

Los términos se almacenan en nuestra lista invertida clásica, para cada término hay una lista de documentos y, opcionalmente, la posición dentro de ese documento. Es bastante posible, aunque tedioso, reconstruir un documento a partir de la lista de términos en el índice. Puede que no sean fáciles de leer por un humano porque los términos han pasado por toda la cadena de análisis; piense en la derivación, la sustitución del sinónimo, cualquiera de las transformaciones, y más, enumeradas aquí . Si bien estos pueden ser difíciles de mirar y leer, el documento así reconstruido debe considerarse completo; La información sensible está disponible.

     

[...◆

     

Naturalmente ... surge la pregunta "¿no podemos cifrar [los archivos de índice] "? Seguro que podemos. Es solo que al hacerlo se obtienen algunos resultados sorprendentes, que a menudo hacen que el índice resultante sea casi inútil. He aquí por qué.

     

Un algoritmo de cifrado decente no producirá, digamos, la misma primera parte para dos tokens que comienzan con las mismas letras. Así que las búsquedas de comodines no funcionarán. Considere "corre", "corriendo", "corredor". Se esperaría que una búsqueda en "ejecutar *" coincida con las tres, pero no lo haría a menos que el cifrado fuera tan trivial como para ser inútil. Problemas similares surgen con la clasificación. "Más como este" sería poco fiable. Hay muchas otras características de un motor de búsqueda sólido que podrían verse afectadas, y un índice con términos encriptados sería útil solo para coincidencias exactas, lo que generalmente resulta en una experiencia de búsqueda deficiente.

    
respondido por el user5568265 20.01.2016 - 19:59
fuente
1

Como Lucene no dice estar segura contra tal ataque, no puedes asumir que lo es. Quizás esté seguro contra un ataque de este tipo en esta versión, pero dado que esto no se ve como parte de su conjunto de características, eso podría cambiar en cualquier parche menor. Así que debes asumir que no es seguro.

    
respondido por el Neil Smithline 20.01.2016 - 04:25
fuente

Lea otras preguntas en las etiquetas

¿Cómo se produce en realidad un ataque de Man In The Middle? ¿CVSS v3 evalúa el impacto de la vulnerabilidad en el host?