Cifrado para búsquedas

Nuestra biblioteca de cifrado del cliente pasó a llamarse SDK de cifrado de bases de datos de AWS. En esta guía para desarrolladores, se sigue proporcionando información sobre el cliente de cifrado de DynamoDB.

El cifrado para búsquedas le permite buscar registros cifrados sin tener que descifrar toda la base de datos. Esto se logra mediante balizas, que crean un mapa entre el valor de texto no cifrado escrito en un campo y el valor cifrado que realmente está almacenado en la base de datos. El SDK de cifrado de bases de datos de AWS almacena la baliza en un campo nuevo que se agrega al registro. Según el tipo de baliza que utilice, puede realizar búsquedas de coincidencias exactas o consultas complejas más personalizadas en sus datos cifrados.

nota

El cifrado para búsquedas del SDK de cifrado de bases de datos de AWS difiere del cifrado simétrico para búsquedas definido en la investigación académica, como el cifrado simétrico para búsquedas.

Una baliza es una etiqueta de código de autenticación de mensajes basado en hash (HMAC) truncada que crea un mapa entre el texto no cifrado y los valores cifrados de un campo. Al escribir un valor nuevo en un campo cifrado que está configurado para el cifrado para búsquedas, el SDK de cifrado de bases de datos de AWS calcula un HMAC sobre el valor del texto no cifrado. Esta salida del HMAC coincide uno a uno (1:1) con el valor de texto no cifrado de ese campo. La salida del HMAC se trunca para que varios valores de texto no cifrado distintos se asignen a la misma etiqueta HMAC truncada. Estos falsos positivos limitan la capacidad de un usuario no autorizado para identificar información distintiva sobre el valor del texto no cifrado. Al consultar una baliza, el SDK de cifrado de bases de datos de AWS filtra automáticamente estos falsos positivos y devuelve el resultado de la consulta en texto no cifrado.

El número medio de falsos positivos generados por cada baliza viene determinado por la longitud de la baliza restante tras el truncamiento. Si necesita ayuda para determinar la longitud de la baliza adecuada para su implementación, consulte Determinar la longitud de la baliza.

nota

El cifrado para búsquedas está diseñado para implementarse en bases de datos nuevas y despobladas. Cualquier baliza configurada en una base de datos existente solo mapeará los nuevos registros cargados en la base de datos; no hay forma de que una baliza mapee los datos ya existentes.

Temas

• ¿Las balizas son adecuadas para mi conjunto de datos?

• Situación de cifrado para búsquedas

¿Las balizas son adecuadas para mi conjunto de datos?

El uso de balizas para realizar consultas sobre datos cifrados reduce los costos de rendimiento asociados a las bases de datos cifradas del cliente. Cuando se utilizan balizas, existe un equilibrio inherente entre la eficacia de las consultas y la cantidad de información que se revela sobre la distribución de los datos. La baliza no altera el estado cifrado del campo. Al cifrar y firmar un campo con el SDK de cifrado de bases de datos de AWS, el valor de texto no cifrado del campo nunca se expone a la base de datos. La base de datos almacena el valor cifrado y la asignación al azar del campo.

Las balizas se almacenan junto a los campos cifrados a partir de los cuales se calculan. Esto significa que, incluso si un usuario no autorizado no puede ver los valores de texto no cifrado de un campo cifrado, podría realizar un análisis estadístico de las balizas para obtener más información sobre la distribución del conjunto de datos y, en casos extremos, identificar los valores de texto no cifrado a los que se asigna una baliza. La forma en que configura su baliza puede mitigar estos riesgos. En particular, elegir la longitud de baliza correcta puede ayudarle a preservar la confidencialidad de su conjunto de datos.

Seguridad en comparación con rendimiento

• Cuanto menor sea la longitud de la baliza, más seguridad se preservará.

• Cuanto mayor sea la longitud de la baliza, más rendimiento se preservará.

Es posible que el cifrado para búsquedas no proporcione los niveles deseados de rendimiento y seguridad para todos los conjunto de datos. Revise su modelo de amenazas, sus requisitos de seguridad y sus necesidades de rendimiento antes de configurar cualquier baliza.

Tenga en cuenta los siguientes requisitos de exclusividad del conjunto de datos al determinar si el cifrado para búsquedas es adecuado para su conjunto de datos.

Distribución

El grado de seguridad que conserva una baliza depende de la distribución del conjunto de datos. Al configurar un campo cifrado para un cifrado que permita realizar búsquedas, el SDK de cifrado de bases de datos de AWS calcula un HMAC a partir de los valores de texto no cifrado escritos en ese campo. Todas las balizas calculadas para un campo determinado se calculan con la misma clave, con la excepción de las bases de datos de multitenencia, que utilizan una clave distinta para cada inquilino. Esto significa que si se escribe el mismo valor de texto no cifrado en el campo varias veces, se crea la misma etiqueta HMAC para cada instancia de ese valor de texto no cifrado.

Debe evitar crear balizas a partir de campos que contengan valores muy comunes. Por ejemplo, considere una base de datos que almacene la dirección de todos los residentes del estado de Illinois. Si crea una baliza a partir del campo City cifrado, la baliza calculada sobre «Chicago» estará sobrerrepresentada debido al porcentaje alto de la población de Illinois que vive en Chicago. Incluso si un usuario no autorizado solo puede leer los valores cifrados y los valores de la baliza, podría identificar qué registros contienen datos de los residentes de Chicago si la baliza conserva esta distribución. Para minimizar la cantidad de información distintiva revelada sobre su distribución, debe truncar suficientemente la baliza. La longitud de baliza necesaria para ocultar esta distribución desigual supone unos costos de rendimiento significativos que podrían no satisfacer las necesidades de la aplicación.

Debe analizar detenidamente la distribución del conjunto de datos para determinar en qué medida es necesario truncar las balizas. La longitud de la baliza que queda después del truncamiento se correlaciona directamente con la cantidad de información estadística que se puede identificar sobre su distribución. Es posible que tengas que elegir longitudes de baliza más cortas para minimizar suficientemente la cantidad de información distintiva que se revela sobre tu conjunto de datos.

En casos extremos, no se puede calcular la longitud de una baliza para un conjunto de datos distribuido de forma desigual que equilibre eficazmente el rendimiento y la seguridad. Por ejemplo, no debe construir una baliza a partir de un campo que almacene el resultado de un examen médico para detectar una enfermedad rara. Como NEGATIVE se espera que los resultados sean significativamente más frecuentes en el conjunto de datos, POSITIVE los resultados se pueden identificar fácilmente por su poca frecuencia. Es muy difícil ocultar la distribución cuando el campo solo tiene dos valores posibles. Si utiliza una longitud de baliza lo suficientemente corta como para ocultar la distribución, todos los valores de texto no cifrado se asignan a la misma etiqueta HMAC. Si utiliza una longitud de baliza más larga, es obvio qué balizas se asignan a valores POSITIVE de texto no cifrado.

Correlación

Le recomendamos encarecidamente que evite construir balizas distintas a partir de campos con valores relacionados entre sí. Las balizas construidas a partir de campos relacionados entre sí requieren longitudes de baliza más cortas para minimizar suficientemente la cantidad de información revelada sobre la distribución de cada conjunto de datos a un usuario no autorizado. Debe analizar detenidamente el conjunto de datos, incluida su entropía y la distribución conjunta de los valores relacionados entre sí, para determinar en qué medida deben truncarse las balizas. Si la longitud de baliza resultante no satisface sus necesidades de rendimiento, es posible que las balizas no sean adecuadas para su conjunto de datos.

Por ejemplo, no debe construir dos balizas independientes a partir de los campos City y ZIPCode, ya que es probable que el código postal esté asociado a una sola ciudad. Por lo general, los falsos positivos que genera una baliza limitan la capacidad de un usuario no autorizado de identificar información distintiva sobre su conjunto de datos. Sin embargo, la correlación entre los campos City y ZIPCode significa que un usuario no autorizado puede identificar fácilmente qué resultados son falsos positivos y distinguir los distintos códigos postales.

También debe evitar crear balizas a partir de campos que contengan los mismos valores de texto no cifrado. Por ejemplo, no debe crear una baliza a partir de los campos mobilePhone y preferredPhone porque es probable que contengan los mismos valores. Si crea balizas distintas a partir de ambos campos, el SDK de cifrado de bases de datos de AWS crea las balizas para cada campo con claves diferentes. Esto da como resultado dos etiquetas HMAC diferentes para el mismo valor de texto no cifrado. Es poco probable que las dos balizas distintas tengan los mismos falsos positivos y un usuario no autorizado podría distinguir números de teléfono diferentes.

Incluso si su conjunto de datos contiene campos relacionados entre sí o tiene una distribución desigual, es posible que pueda construir balizas que preserven la confidencialidad del conjunto de datos mediante longitudes de baliza más cortas. Sin embargo, la longitud de la baliza no garantiza que cada valor único del conjunto de datos produzca una serie de falsos positivos que minimicen de forma efectiva la cantidad de información distintiva que se revela sobre el conjunto de datos. La longitud de la baliza solo estima el número medio de falsos positivos producidos. Cuanto más desigualmente esté distribuido el conjunto de datos, menos eficaz será la longitud de la baliza para determinar el número medio de falsos positivos producidos.

Considere detenidamente la distribución de los campos a partir de los cuales construye las balizas y considere cuánto necesitará truncar la longitud de la baliza para cumplir con sus requisitos de seguridad. En los siguientes temas de este capítulo, se parte del supuesto de que las balizas están distribuidas uniformemente y no contienen datos relacionados entre sí.

Situación de cifrado para búsquedas

En el ejemplo siguiente, se muestra una solución de cifrado sencilla para búsquedas. En la aplicación, es posible que los campos de ejemplo utilizados en este ejemplo no cumplan con las recomendaciones de unicidad de distribución y correlación para las balizas. Puede utilizar este ejemplo como referencia mientras lee en este capítulo acerca de los conceptos de cifrado para búsquedas.

Considere una base de datos denominada Employees que rastrea los datos de los empleados de una empresa. Cada registro de la base de datos contiene campos denominados EmployeeID, LastName, FirstName y Address. Cada campo de la Employees base de datos se identifica mediante la clave principal EmployeeID.

A continuación, se muestra un ejemplo de un registro de texto no cifrado de la base de datos.

{
    "EmployeeID": 101,
    "LastName": "Jones",
    "FirstName": "Mary",
    "Address": {
                "Street": "123 Main",
                "City": "Anytown",
                "State": "OH",
                "ZIPCode": 12345
    }
}

Si marcó los campos LastName y FirstName como ENCRYPT_AND_SIGN en sus acciones criptográficas, los valores de estos campos se cifrarán localmente antes de cargarlos en la base de datos. Los datos cifrados que se cargan son completamente asignados al azar y la base de datos no los reconoce como protegidos. Simplemente detecta las entradas de datos típicas. Esto significa que el registro que está realmente almacenado en la base de datos podría tener el siguiente aspecto.

{
    "PersonID": 101,
    "LastName": "1d76e94a2063578637d51371b363c9682bad926cbd",
    "FirstName": "21d6d54b0aaabc411e9f9b34b6d53aa4ef3b0a35",
    "Address": {
                "Street": "123 Main",
                "City": "Anytown",
                "State": "OH",
                "ZIPCode": 12345
    }
}

Si necesita consultar en la base de datos las coincidencias exactas en el LastName campo, configure un indicador estándar denominado LastName para asignar los valores de texto no cifrado escritos en el LastName campo a los valores cifrados almacenados en la base de datos.

Esta baliza calcula los HMAC a partir de los valores de texto no cifrado del campo LastName. Cada salida del HMAC se trunca para que ya no coincida exactamente con el valor del texto no cifrado. Por ejemplo, el hash completo y el hash truncado Jones pueden tener el siguiente aspecto.

Hash completo

2aa4e9b404c68182562b6ec761fcca5306de527826a69468885e59dc36d0c3f824bdd44cab45526f70a2a18322000264f5451acf75f9f817e2b35099d408c833

Hash truncado

b35099d408c833

Una vez configurada la baliza estándar, puede realizar búsquedas de igualdad en el campo LastName. Por ejemplo, si desea buscar a Jones, utilice la baliza LastName para realizar la siguiente consulta.

LastName = Jones

El SDK de cifrado de bases de datos de AWS filtra automáticamente los falsos positivos y devuelve el resultado de la consulta en texto no cifrado.