Cifrado para búsquedas

Se cambió el nombre de nuestra biblioteca de cifrado del lado del cliente por el de SDK de cifrado de AWS bases de datos. 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 AWS de cifrado de bases de datos almacena la baliza en un campo nuevo que se añade 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 con capacidad de búsqueda del SDK AWS de cifrado de bases de datos difiere del cifrado simétrico con capacidad de búsqueda definido en la investigación académica, como el cifrado simétrico con capacidad de búsqueda.

Una baliza es una etiqueta de código de autenticación de Hash-Based mensajes (HMAC) truncada que asigna un valor de campo de texto simple a un identificador cifrado que permite realizar búsquedas. Al escribir un valor en un campo cifrado configurado para el cifrado con capacidad de búsqueda, el SDK de cifrado de AWS bases de datos calcula un HMAC a partir del valor del texto sin formato. Esta salida del HMAC coincide uno a uno (1:1) con el valor de texto no cifrado de ese campo. El SDK trunca intencionadamente la salida del HMAC para que varios valores distintos de texto plano colisionen en la misma baliza. Estas colisiones (falsos positivos) limitan la capacidad de un usuario no autorizado de deducir información confidencial a partir de los patrones de frecuencia. Al consultar una baliza, el SDK de cifrado AWS de bases de datos filtra automáticamente estos falsos positivos y devuelve el resultado de la consulta en texto plano. Para abordar aún más este problema de la fuga de frecuencia, las balizas se dividen, lo que permite que valores idénticos de texto plano generen valores de baliza diferentes en las particiones. Cuando la tabla usa solo una partición, este comportamiento coincide naturalmente con las balizas tradicionales no particionadas.

El número medio de falsos positivos de cada baliza depende de la longitud restante de la baliza tras el truncamiento y del número de particiones. 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 AWS bases de datos, el valor de texto sin formato 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 configuración adecuada de las balizas es esencial para mitigar estos riesgos. La selección de un esquema de longitud y partición de las balizas adecuados preserva la confidencialidad, ya que garantiza que haya suficientes colisiones y mitiga los ataques basados en la frecuencia al limitar la concentración de valores en una sola baliza.

Seguridad en comparación con rendimiento

• Las longitudes de baliza más cortas y el mayor número de particiones mejoran la seguridad al aumentar las colisiones y reducir las fugas de frecuencia.

• Las longitudes de baliza más largas y el menor número de particiones mejoran el rendimiento al reducir los falsos positivos y la dispersión de consultas.

En muchos escenarios prácticos, una configuración bien elegida puede equilibrar estos objetivos contrapuestos. Sin embargo, es posible que el cifrado con capacidad de búsqueda no pueda ofrecer los niveles deseados de seguridad y rendimiento para todos los conjuntos de datos.

Antes de configurar cualquier baliza, revise detenidamente su modelo de amenazas, sus requisitos de seguridad y sus necesidades de rendimiento, y tenga en cuenta las características únicas de su conjunto de datos para determinar si el cifrado con capacidad de búsqueda es una opción adecuada.

Distribución

Las propiedades de seguridad de una baliza dependen tanto de la distribución de los datos subyacentes como de la configuración de la baliza, incluida la cantidad de particiones que se utilizan. Al configurar un campo cifrado para un cifrado que permita realizar búsquedas, el SDK de cifrado de AWS bases de datos calcula un HMAC sobre cada valor de texto sin formato escrito en ese campo y obtiene la baliza mediante una clave criptográfica. Las balizas se calculan en el contexto de una partición, lo que permite que valores de texto sin formato idénticos generen valores de baliza diferentes en las particiones. Cuando la tabla usa solo una partición, los valores de texto plano idénticos siempre se asignan a la misma etiqueta HMAC truncada, lo que puede preservar los patrones de frecuencia del conjunto de datos original.

Los campos con distribuciones muy asimétricas requieren un cuidado especial. Por ejemplo, considere una base de datos que almacene la ciudad de residencia de todos los residentes de Illinois. Si crea una baliza a partir del City campo cifrado, el valor «Chicago» aparecerá con mucha más frecuencia que en otras ciudades. Incluso si un usuario no autorizado solo puede acceder a los elementos cifrados y a los valores de las balizas, este desequilibrio puede permitirles deducir qué registros corresponden a los residentes de Chicago al observar las balizas sobrerrepresentadas. Truncar la baliza puede reducir estas fugas al provocar más colisiones, pero la longitud de la baliza necesaria para ocultar suficientemente una desviación grave puede suponer una sobrecarga de rendimiento significativa debido al aumento de los falsos positivos.

Para configurar las balizas de forma segura, debe analizar la distribución de frecuencias de los datos y comprender cómo interactúan el truncamiento y la partición. La cantidad de bits retenidos en una baliza determina la cantidad de información estadística que queda expuesta, mientras que la cantidad de particiones limita la concentración de un solo valor de baliza. Las longitudes de baliza más cortas y el mayor número de particiones reducen la pérdida de frecuencia, pero aumentan los falsos positivos y la dispersión de consultas. Las longitudes de baliza más largas y el menor número de particiones mejoran la eficiencia de las consultas, pero exponen más información sobre la distribución subyacente.

En algunos casos extremos, las cargas de trabajo no son viables cuando la tabla usa solo una partición. Los atributos con poblaciones muy pequeñas o resultados binarios muy desequilibrados, como los resultados de pruebas médicas en los que predominan los valores NEGATIVOS, no se pueden proteger únicamente mediante el truncamiento. Con una partición, una baliza lo suficientemente corta como para ocultar la distribución agrupa todos los valores en una sola etiqueta, mientras que una baliza más larga facilita la identificación de los valores poco comunes. En estos casos, se necesitan balizas particionadas para posibilitar el cifrado con capacidad de búsqueda. Al distribuir los valores sobrerrepresentados en varias particiones, este enfoque reduce el tamaño de las clases de equivalencia y limita la fuga de frecuencia de formas que no son posibles cuando se utiliza una sola partición.

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 AWS de bases de datos 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.

Evalúe detenidamente la distribución de los campos que desee balizar y determine cuánto truncamiento es necesario para cumplir sus requisitos de seguridad. En los temas siguientes de este capítulo se parte del supuesto de que, dentro de cada partición, los valores de las balizas se distribuyen de manera uniforme y que los datos subyacentes no introducen correlaciones que puedan debilitar estas suposiciones.

Situación de cifrado para búsquedas

El siguiente ejemplo muestra una solución de cifrado que permite realizar búsquedas e ilustra los conceptos principales que se analizan en este capítulo. En este escenario, algunos valores de campo aparecen con mucha frecuencia, lo que daría lugar a clases de equivalencia más numerosas y a una mayor pérdida de frecuencia si se utilizara una sola partición. Para solucionar este problema, la configuración utiliza varias particiones para que los valores más frecuentes se distribuyan de manera más uniforme, lo que reduce las fugas y, al mismo tiempo, conserva la capacidad de realizar búsquedas de igualdad eficientes.

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 una baliza estándar con un nombre LastNameque asigne los valores de texto sin formato 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

En un conjunto de datos con muchos empleados, algunos apellidos, como Jones, Smith o Johnson, pueden aparecer con mucha más frecuencia que otros. Para reducir la pérdida de frecuencia y limitar el tamaño de las clases de equivalencia de balizas, debe configurar la LastNamebaliza para que utilice más de una partición.

Cuando las particiones están habilitadas, cada elemento se asigna a una partición en el momento de la escritura y el número de partición se incorpora a la derivación de balizas. Como resultado, los empleados con el mismo apellido pueden asignarse a diferentes valores de baliza en las particiones. Esto distribuye los nombres muy frecuentes entre varias particiones, lo que reduce la sobrerrepresentación de cualquier valor de baliza individual.

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

LastName = Jones

Al buscar un apellido específico de alta frecuencia, como Jones, la aplicación debería emitir una consulta por partición utilizando la LastNamebaliza. A continuación, el SDK de cifrado de AWS bases de datos descifra los resultados y filtra automáticamente los falsos positivos y devuelve los registros de texto sin formato correctos.