Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Consideraciones al utilizar la computación criptográfica para Clean Rooms
La computación criptográfica para Clean Rooms (C3R) busca maximizar la protección de los datos. Sin embargo, algunos casos de uso pueden beneficiarse de niveles más bajos de protección de datos a cambio de funcionalidades adicionales. Puede hacer estas concesiones específicas modificando C3R a partir de su configuración más segura. Como cliente, debe conocer estas ventajas y desventajas, y determinar si son apropiadas para su caso de uso. Entre las ventajas que debe considerar se incluyen las siguientes:
Temas
Para obtener más información sobre cómo establecer parámetros para estos escenarios, consulte Parámetros de computación criptográfica.
Permitir cleartext mixto y datos cifrados en sus tablas
Hacer que todos los datos se cifren en el cliente proporciona la máxima protección de datos. Sin embargo, esto limita ciertos tipos de consultas (por ejemplo, la función de agregación SUM). El riesgo de permitir datos de cleartext es que es factible que cualquier persona con acceso a las tablas cifradas pueda inferir cierta información sobre los valores cifrados. Esto podría hacerse realizando un análisis estadístico de los datos de cleartext y de los datos relacionados.
Por ejemplo, supongamos que tiene las columnas de City y State. La columna City es cleartext y la columna State está cifrada. Cuando ve el valor Chicago en la columna City, esto le ayuda a determinar con una alta probabilidad que el State es Illinois. Por el contrario, si una columna es City y la otra columna es EmailAddress, es poco probable que un cleartext City revele algo sobre una EmailAddress cifrada.
Para obtener más información acerca del parámetro para este escenario, consulte Parámetro Permitir columnas cleartext.
Permitir valores repetidos en columnas fingerprint
Para optar por un método más seguro, presuponemos que cualquier columna fingerprint contiene exactamente una instancia de una variable. En una columna fingerprint no se puede repetir ningún elemento. El cliente de cifrado de C3R asigna estos valores cleartext a valores únicos que son indistinguibles de los valores aleatorios. Por lo tanto, es imposible inferir información acerca del cleartext a partir de estos valores aleatorios.
El riesgo de los valores repetidos en una columna fingerprint es que estos valores repetidos resulten en valores repetidos que parezcan aleatorios. Por lo tanto, cualquier persona que tenga acceso a las tablas cifradas podría, en teoría, realizar un análisis estadístico de las columnas fingerprint que podría revelar información sobre los valores cleartext.
De nuevo, presupongamos que la columna fingerprint es State, y que cada fila de la tabla corresponde a un hogar estadounidense. Un análisis de frecuencia permitiría inferir qué estado es California y cuál es Wyoming con una alta probabilidad. Esta inferencia es posible porque California tiene muchos más residentes que Wyoming. Por el contrario, presupongamos que la columna fingerprint está en un identificador de hogar y que cada hogar aparece en la base de datos entre 1 y 4 veces en una base de datos de millones de entradas. Es poco probable que un análisis de frecuencia revele información útil.
Para obtener más información acerca del parámetro para este escenario, consulte Parámetro Permitir duplicados.
Disminuir las restricciones de nomenclatura de las columnas fingerprint
De forma predeterminada, presuponemos que, cuando se combinan dos tablas utilizando columnas fingerprint cifradas, dichas columnas tienen el mismo nombre en cada tabla. El motivo técnico de este resultado es que, de forma predeterminada, deducimos una clave criptográfica diferente para cifrar cada columna fingerprint. Esa clave se deriva de una combinación de la clave secreta compartida de la colaboración y el nombre de la columna. Si intentamos combinar dos columnas con nombres de columna diferentes, obtenemos claves diferentes y no podemos procesar una combinación válida.
Para solucionar este problema, puede desactivar la característica que deriva las claves a partir de cada nombre de columna. A continuación, el cliente de cifrado de C3R utiliza una única clave derivada para todas las columnas fingerprint. El riesgo reside en que se pueda realizar otro tipo de análisis de frecuencia que pueda revelar información.
Volvamos al ejemplo de City y State. Si derivamos los mismos valores aleatorios para cada columna fingerprint (al no incorporar el nombre de columna), New York tiene el mismo valor aleatorio en las columnas City y State. Nueva York es una de las pocas ciudades de EE. UU. donde el nombre de City coincide con el nombre del State nombre. Por el contrario, si su conjunto de datos tiene valores completamente diferentes en cada columna, no se filtra información.
Para obtener más información acerca del parámetro para este escenario, consulte Parámetro Permitir JOIN de columnas con nombres diferentes.
Determinar cómo se representan los valores NULL
La opción que tiene a su disposición consiste en procesar criptográficamente los valores NULL (cifrado y HMAC) como cualquier otro valor. Si no procesa los valores NULL como cualquier otro valor, es posible que se revele información.
Por ejemplo, supongamos que NULL en la columna Middle Name de cleartext señala a las personas sin segundo nombre. Si no cifra esos valores, filtrará qué filas de la tabla cifrada se utilizan para personas sin segundo nombre. Esa información podría ser una señal de identificación para algunas personas de ciertas poblaciones. Sin embargo, si procesa los valores NULL criptográficamente, algunas consultas SQL actúan de forma diferente. Por ejemplo, las cláusulas GROUP BY no agruparán los valores fingerprint NULL en columnas fingerprint.
Para obtener más información acerca del parámetro para este escenario, consulte Parámetro Conservar valores NULL.
