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.

Directrices para el cliente de cifrado de C3R

El cliente de cifrado de C3R es una herramienta que permite a las organizaciones recopilar datos confidenciales para obtener nueva información procesable a partir del análisis de datos. La herramienta limita criptográficamente lo que puede aprender cualquiera de las partes y durante el proceso. AWS Si bien esto es de vital importancia, el proceso de protección criptográfica de los datos puede suponer una sobrecarga considerable, tanto en términos de recursos de computación como de almacenamiento. Por lo tanto, es importante entender las ventajas y desventajas de usar cada ajuste y saber cómo optimizar la configuración sin dejar de mantener las garantías criptográficas deseadas. Este tema se centra en las implicaciones para el rendimiento de las diferentes configuraciones del cliente de cifrado de C3R y los esquemas.

Todas las configuraciones de cifrado del cliente de cifrado de C3R ofrecen diferentes garantías criptográficas. De forma predeterminada, los ajustes más seguros son aquellos en el nivel de la colaboración. Al habilitar funciones adicionales al crear una colaboración, se debilitan las garantías de privacidad, ya que se permite realizar actividades como análisis de frecuencia en el texto cifrado. Para obtener más información sobre cómo se utilizan estas configuraciones y cuáles son sus implicaciones, consulte Computación criptográfica para Clean Rooms.

Implicaciones en el rendimiento de los tipos de columnas

C3R utiliza tres tipos de columnas: cleartext, fingerprint y sealed. Cada uno de estos tipos de columnas proporciona diferentes garantías criptográficas y tiene distintos usos previstos. En las siguientes secciones se analizan las implicaciones de rendimiento del tipo de columna y el impacto de cada ajuste en el rendimiento.

Columnas Cleartext

Las columnas Cleartext no se modifican con respecto a su formato original ni se procesan criptográficamente en modo alguno. Este tipo de columna no se puede configurar y no afecta al rendimiento en términos de almacenamiento o de computación.

Columnas Fingerprint

Las columnas Fingerprint están previstas para utilizarse para combinar datos de varias tablas. Para ello, el tamaño del texto cifrado resultante debe ser siempre el mismo. Sin embargo, estas columnas se ven afectadas por los ajustes en el nivel de la colaboración. Las columnas Fingerprint pueden incidir en distinto grado en el tamaño del archivo de salida en función del cleartext contenido en la entrada.

Sobrecarga de base para las columnas fingerprint

Existe una sobrecarga de base para las columnas fingerprint. Esta sobrecarga es constante y sustituye al tamaño de los bytes de cleartext.

Los datos de las columnas fingerprint se procesan criptográficamente mediante una función de código de autenticación de mensajes basado en hash (HMAC), que convierte los datos en un código de autenticación de mensajes (MAC) de 32 bytes. A continuación, estos datos se procesan a través de un codificador base64, lo que aumenta el tamaño del byte aproximadamente un 33 por ciento. Va precedido de una designación C3R de 8 bytes para designar el tipo de columna a la que pertenecen los datos y la versión de cliente que los generó. El resultado final es de 52 bytes. Este resultado se multiplica entonces por el número de filas para obtener la sobrecarga de base total (utilice el número total de valores distintos de null si preserveNulls se establece en true).

En la siguiente imagen se muestra cómo BASE_OVERHEAD = C3R_DESIGNATION + (MAC * 1.33)

El texto cifrado de salida de las columnas fingerprint siempre será de 52 bytes. Esto puede suponer una disminución significativa del almacenamiento si el promedio de los datos de cleartext de entrada es superior a 52 bytes (por ejemplo, las direcciones postales completas). Esto puede suponer un aumento significativo del almacenamiento si el promedio de los datos de cleartext de entrada es inferior a 52 bytes (por ejemplo, las edades de los clientes).

Ajustes de colaboración para las columnas fingerprint

Ajuste preserveNulls

Cuando el ajuste de nivel de la colaboración preserveNulls es false (predeterminado), cada valor null se sustituye por 32 bytes únicos y aleatorios y se procesa como si no fuera null. El resultado es que cada valor null tiene ahora 52 bytes. Esto puede añadir requisitos de almacenamiento importantes para las tablas que contienen datos muy dispersos en comparación con cuando este ajuste es true y los valores null se transfieren como null.

Si no necesita las garantías de privacidad de este ajuste y prefiere retener los valores null de sus conjuntos de datos, habilite el ajuste preserveNulls en el momento de crear la colaboración. El ajuste preserveNulls no se puede cambiar una vez creada la colaboración.

Datos de ejemplo para una columna fingerprint

El siguiente es un ejemplo de conjunto de datos de entrada y salida para una columna fingerprint con los ajustes de configuración que se deben reproducir. Otros ajustes a nivel de la colaboración, como allowCleartext y allowDuplicates, no afectan a los resultados y se pueden configurar como true o false si se intenta reproducirlos localmente.

Secreto compartido de ejemplo: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

ID de colaboración de ejemplo: a1b2c3d4-5678-90ab-cdef-EXAMPLE11111

allowJoinsOnColumnsWithDifferentNames: True Este ajuste no afecta al rendimiento ni a los requisitos de almacenamiento. Sin embargo, este ajuste hace que la elección del nombre de la columna sea irrelevante al reproducir los valores que se muestran en las siguientes tablas.

Solución de problemas con columnas fingerprint

¿Por qué el texto cifrado de mis columnas fingerprint es varias veces mayor que el tamaño del cleartext que figuraba en ellas?

El texto cifrado de una columna de fingerprint tiene siempre una longitud de 52 bytes. Si los datos de entrada eran pequeños (por ejemplo, las edades de los clientes), mostrarán un aumento considerable de tamaño. Esto también puede ocurrir si el ajuste preserveNulls se define como false.

¿Por qué el texto cifrado de mis columnas de fingerprint es varias veces más pequeño que el cleartext que contiene?

El texto cifrado de una columna de fingerprint tiene siempre una longitud de 52 bytes. Si los datos de entrada eran grandes (por ejemplo, las direcciones completas de los clientes), su tamaño se reducirá considerablemente.

¿Cómo sé si necesito las garantías criptográficas que ofrece preserveNulls?

Lamentablemente, la respuesta es que depende. Como mínimo, se deben revisar los Parámetros de computación criptográfica en cuanto a la forma en que el ajuste preserveNulls protege sus datos. No obstante, le recomendamos que consulte los requisitos de manejo de datos de su organización y cualquier contrato aplicable a la colaboración correspondiente.

¿Por qué tengo que incurrir en la sobrecarga de base64?

Para permitir la compatibilidad con los formatos de archivo tabulares como CSV, es necesaria la codificación base64. Si bien algunos formatos de archivo como Parquet podrían admitir representaciones binarias de datos, es importante que todos los participantes en una colaboración representen los datos de la misma manera para garantizar que los resultados de las consultas sean correctos.

Columnas Sealed

Las columnas Sealed están diseñadas para utilizarse para transferir datos entre los miembros de una colaboración. El texto cifrado de estas columnas no es determinista y tiene un impacto significativo tanto en el rendimiento como en el almacenamiento en función de cómo se configuren las columnas. Estas columnas se pueden configurar de forma individual y, a menudo, son las que más influyen en el rendimiento del cliente de cifrado de C3R y en el tamaño del archivo de salida resultante.

Sobrecarga de base para las columnas sealed

Existe una sobrecarga de base para las columnas sealed. Esta sobrecarga es constante y se suma al tamaño de los bytes de cleartext y de relleno (si los hubiera).

Antes de cualquier cifrado, a los datos de las columnas sealed se les añade como prefijo un carácter de 1 byte que designa el tipo de datos que contienen. Si se selecciona el relleno, los datos se rellenan y se añaden 2 bytes que indican el tamaño del relleno. Tras añadir estos bytes, los datos se procesan criptográficamente mediante AES-GCM y se almacenan con IV (12 bytes), nonce (32 bytes) y Auth Tag (16 bytes). A continuación, estos datos se procesan a través de un codificador base64, lo que aumenta el tamaño del byte aproximadamente un 33 por ciento. Los datos van precedidos de una designación C3R de 7 bytes para indicar el tipo de columna a la que pertenecen los datos y la versión de cliente utilizada para generarlos. El resultado es una sobrecarga de base final de 91 bytes. A continuación, este resultado se puede multiplicar por el número de filas para obtener la sobrecarga de base total (utilice el número total de valores no nulos si preserveNulls está definido como true).

En la siguiente imagen se muestra cómo BASE_OVERHEAD = C3R_DESIGNATION + ((NONCE + IV + DATA_TYPE + PAD_SIZE + AUTH_TAG) * 1.33)

Ajustes de colaboración para las columnas sealed

Ajuste preserveNulls

Cuando el ajuste en el nivel de la colaboración preserveNulls es false (predeterminado), cada valor null es único, aleatorio de 32 bytes, y se procesa como si no fuera null. El resultado es que cada valor null tiene ahora 91 bytes (más si se rellena). Esto puede añadir requisitos de almacenamiento importantes para las tablas que contienen datos muy dispersos en comparación con cuando este ajuste es true y los valores null se transfieren como null.

Si no necesita las garantías de privacidad de este ajuste y prefiere retener los valores null de sus conjuntos de datos, habilite el ajuste preserveNulls en el momento de crear la colaboración. El ajuste preserveNulls no se puede cambiar una vez creada la colaboración.

Columnas sealed de configuración de esquema: tipos de relleno

Tipo de relleno none

Seleccionar el tipo de relleno none no añade ningún relleno al cleartext ni añade ninguna sobrecarga adicional a la sobrecarga de base descrita anteriormente. La ausencia de relleno se traduce en el tamaño de salida más eficiente en términos de espacio. Sin embargo, no proporciona las mismas garantías de privacidad que los tipos de relleno fixed y max. Esto se debe a que el tamaño del cleartext subyacente es discernible a partir del tamaño del texto cifrado.

Tipo de relleno fixed

Seleccionar un tipo de relleno fixed es una medida que salvaguarda la privacidad para ocultar la longitud de los datos contenidos en una columna. Esto se hace rellenando todo el cleartext hasta la pad_length antes del cifrado. Cualquier dato que supere ese tamaño provoca un fallo del cliente de cifrado de C3R.

Dado que el relleno se añade al cleartext antes de cifrarlo, AES-GCM utiliza un mapeo 1 a 1 de cleartext a texto cifrado en bytes. La codificación base64 añadirá un 33 por ciento. La sobrecarga de almacenamiento adicional del relleno se puede calcular restando la longitud media del cleartext del valor de pad_length y multiplicándola por 1,33. El resultado es la sobrecarga promedio de relleno por registro. Este resultado puede entonces multiplicarse por el número de filas para obtener la sobrecarga de relleno total (utilice el número total de valores no null si preserveNulls está definido como true).

PADDING_OVERHEAD = (PAD_LENGTH - AVG_CLEARTEXT_LENGTH) * 1.33 * ROW_COUNT

Se recomienda seleccionar la pad_length mínima que abarque el mayor valor de columna. Por ejemplo, si el mayor valor es de 50 bytes, basta con una pad_length de 50. Un valor superior a ese solo añadirá sobrecarga de almacenamiento adicional.

El relleno fijo no añade ninguna sobrecarga de computación significativa.

Tipo de relleno max

Seleccionar un tipo de relleno max es una medida que salvaguarda la privacidad para ocultar la longitud de los datos contenidos en una columna. Esto se hace rellenando todos los cleartext hasta el valor más alto de la columna, más la pad_length adicional, antes de cifrarla. Por lo general, el relleno max proporciona las mismas garantías que el relleno fixed para un único conjunto de datos, al tiempo que permite no conocer el valor de cleartext más alto de la columna. Sin embargo, es posible que el relleno max no ofrezca las mismas garantías de privacidad que el relleno fixed en todas las actualizaciones, ya que el valor más alto de cada conjuntos de datos podría variar.

Se recomienda seleccionar una pad_length adicional de 0 al usar el relleno max. Esta longitud rellena todos los valores para que tengan el mismo tamaño que el mayor valor de la columna. Un valor superior a ese solo añadirá sobrecarga de almacenamiento adicional.

Si conoce el valor de cleartext más alto de una columna determinada, le recomendamos que utilice el tipo de relleno fixed en su lugar. El uso del relleno fixed crea coherencia entre los conjuntos de datos actualizados. El uso del relleno max hace que cada subconjunto de datos se rellene hasta el mayor valor presente en el subconjunto.

Datos de ejemplo para una columna sealed

El siguiente es un ejemplo de conjunto de datos de entrada y salida para una columna sealed con los ajustes de configuración que se deben reproducir. Otros ajustes en el nivel de la colaboración, allowCleartext, allowJoinsOnColumnsWithDifferentNames y allowDuplicates, no afectan a los resultados y se pueden definir como true o false si se intentan reproducir localmente. Aunque estos son los ajustes básicos que se deben reproducir, la columna sealed no es determinista y los valores cambiarán de una vez a otra. El objetivo es mostrar los bytes de entrada en comparación con los bytes de salida. Los valores pad_length de ejemplo se han elegido de forma intencionada. Muestran que el relleno fixed da como resultado los mismos valores que el relleno max con los ajustes de pad_length mínima recomendada o cuando se desea un relleno adicional.

Secreto compartido de ejemplo: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

ID de colaboración de ejemplo: a1b2c3d4-5678-90ab-cdef-EXAMPLE11111

Tipo de relleno none

Tipo de relleno fixed (ejemplo 1)

En este ejemplo, pad_length es 62 y la mayor entrada es de 62 bytes.

Tipo de relleno fixed (ejemplo 2)

En este ejemplo, pad_length es 162 y la mayor entrada es de 62 bytes.

Tipo de relleno max (ejemplo 1)

En este ejemplo, pad_length es 0 y la mayor entrada es de 62 bytes.

Tipo de relleno max (ejemplo 2)

En este ejemplo, pad_length es 100 y la mayor entrada es de 62 bytes.

Solución de problemas con columnas sealed

¿Por qué el texto cifrado de mis columnas sealed es varias veces mayor que el tamaño del cleartext que figuraba en ellas?

Esto depende de varios factores. Por un lado, el texto cifrado de una columna Cleartext siempre tiene una longitud mínima de 91 bytes. Si los datos de entrada eran pequeños (por ejemplo, las edades de los clientes), mostrarán un aumento considerable de tamaño. En segundo lugar, si preserveNulls se hubiera definido como false y los datos de entrada contuvieran un gran número de valores null, cada uno de esos valores null se habrá convertido en 91 bytes de texto cifrado. Por último, si se utiliza el relleno, por definición, se añaden bytes a los datos de cleartext antes de cifrarlos.

La mayoría de los datos de una columna sealed son muy pequeños y necesito utilizar relleno. ¿Puedo simplemente eliminar los valores grandes y procesarlos por separado para ahorrar espacio?

No le recomendamos que elimine los valores grandes y los procese por separado. Al hacerlo, se modifican las garantías de privacidad que ofrece el cliente de cifrado de C3R. Como modelo de amenaza, presuponga que un observador puede ver ambos conjuntos de datos cifrados. Si el observador ve que un subconjunto de datos tiene una columna considerablemente más o menos rellena que otro subconjunto, puede hacer inferencias sobre el tamaño de los datos de cada subconjunto. Por ejemplo, imaginemos que una columna fullName se rellena hasta un total de 40 bytes en un archivo y se rellena hasta 800 bytes en otro archivo. Un observador podría deducir que un conjunto de datos contiene el nombre más largo del mundo (747 bytes).

¿Debo proporcionar un relleno adicional al usar el tipo de relleno max?

No. Al utilizar el relleno max, se recomienda establecer en 0 la pad_length (también conocida como relleno adicional complementario al mayor valor de la columna).

¿Puedo elegir una pad_length grande al usar el relleno fixed para evitar tener que preocuparme de que quepa el valor más grande?

Sí, pero la gran longitud de relleno es ineficiente y utiliza más almacenamiento del necesario. Le recomendamos que compruebe el tamaño del mayor valor y que defina la pad_length con ese valor.

¿Cómo sé si necesito las garantías criptográficas que ofrece preserveNulls?

Lamentablemente, la respuesta es que depende. Como mínimo, se deben revisar los Computación criptográfica para Clean Rooms en cuanto a la forma en que el ajuste preserveNulls protege sus datos. No obstante, le recomendamos que consulte los requisitos de manejo de datos de su organización y cualquier contrato aplicable a la colaboración correspondiente.

¿Por qué tengo que incurrir en la sobrecarga de base64?

Para permitir la compatibilidad con los formatos de archivo tabulares, como CSV, es necesaria la codificación base64. Si bien algunos formatos de archivo como Parquet podrían admitir representaciones binarias de datos, es importante que todos los participantes en una colaboración representen los datos de la misma manera para garantizar que los resultados de las consultas sean correctos.

Solución de problemas relacionados con el aumento imprevisto de tamaño del texto cifrado

Supongamos que ha cifrado los datos y que el tamaño de los datos resultantes es sorprendentemente grande. Los siguientes pasos pueden ayudarle a identificar dónde se produjo el aumento de tamaño y qué medidas puede adoptar, si las hubiera.

Identificar dónde se produjo el aumento de tamaño

Antes de poder averiguar por qué los datos cifrados son significativamente más grandes que los datos de cleartext, primero debe identificar dónde reside el aumento de tamaño. Las columnas de Cleartext se pueden ignorar con total seguridad porque permanecen inalteradas. Observe las columnas fingerprint y sealed restantes, y elija una que parezca significativa.

Identificar el motivo por el que se produjo el aumento de tamaño

Una columna de fingerprint o una columna sealed pueden contribuir al aumento de tamaño.

¿Procede el aumento de tamaño de una columna fingerprint?

Si la columna que más contribuye al aumento del almacenamiento es una columna fingerprint, es probable que se deba a que los datos de cleartext son pequeños (por ejemplo, la edad de los clientes). Cada texto cifrado de fingerprint resultante tiene una longitud de 52 bytes. Lamentablemente, no se puede hacer nada al respecto sobre una column-by-column base sólida. Para obtener más información, consulte Sobrecarga de base para las columnas fingerprint para conocer los detalles de esta columna, incluida su incidencia en los requisitos de almacenamiento.

La otra causa posible del aumento de tamaño de una columna fingerprint es el ajuste de la colaboración preserveNulls. Si el ajuste de la colaboración para preserveNulls está deshabilitado (ajuste predeterminado), todos los valores null de las columnas fingerprint se convertirán en 52 bytes de texto cifrado. No hay nada que se pueda hacer al respecto en la colaboración actual. El ajuste preserveNulls se define en el momento en que se crea la colaboración, y todos los colaboradores deben usar el mismo ajuste para garantizar que los resultados de la consulta sean correctos. Para obtener más información sobre el ajuste preserveNulls y sobre cómo su habilitación afecta a las garantías de privacidad de los datos, consulte Computación criptográfica para Clean Rooms.

¿Procede el aumento de tamaño de una columna sealed?

Si la columna que más contribuye al aumento del almacenamiento es una columna sealed, hay algunos detalles que podrían contribuir al aumento de tamaño.

Si los datos de cleartext son pequeños (por ejemplo, las edades de los clientes), cada texto cifrado sealed resultante tiene una longitud mínima de 91 bytes. Lamentablemente, no se puede hacer nada al respecto. Para obtener más información, consulte Sobrecarga de base para las columnas sealed para conocer los detalles de esta columna, incluida su incidencia en los requisitos de almacenamiento.

La segunda causa principal del aumento del almacenamiento en columnas sealed es el relleno. El relleno añade bytes adicionales al cleartext antes del cifrado para ocultar el tamaño de los valores individuales de un conjunto de datos. Se recomienda establecer el relleno en el valor mínimo posible para el conjunto de datos. Como mínimo, se debe definir pad_length para el relleno fixed de manera que abarque el mayor valor posible de la columna. Todo ajuste superior a ese no aportará garantías de privacidad adicionales. Por ejemplo, si sabe que el mayor valor posible de una columna puede ser de 50 bytes, le recomendamos que defina la pad_length en 50 bytes. Sin embargo, si la columna sealed utiliza el relleno max, le recomendamos que lo defina la pad_length en 0 bytes. Esto se debe a que el relleno max se refiere al relleno adicional que se suma al mayor valor de la columna.

La última causa posible del aumento de tamaño de una columna sealed es el ajuste de la colaboración preserveNulls. Si el ajuste de la colaboración para preserveNulls está deshabilitado (ajuste predeterminado), todos los valores null de las columnas sealed se convertirán en 91 bytes de texto cifrado. No hay nada que se pueda hacer al respecto en la colaboración actual. El ajuste preserveNulls se define en el momento en que se crea la colaboración, y todos los colaboradores deben usar el mismo ajuste para garantizar que los resultados de la consulta sean correctos. Para obtener más información sobre los efectos de esta configuración y sobre cómo su activación afecta a las garantías de privacidad de sus datos, consulte Computación criptográfica para Clean Rooms.