Sobre que base crear claves de datos

Question

Para la PII, tenemos que cifrar algunas columnas en nuestra base de datos (toda nuestra infraestructura reside en nuestro propio DC, sin utilizar ningún proveedor de nube).

Ahora, aproximadamente, lo que estamos haciendo es

• Creó una CMK en AWS.
• Generar clave de datos usando CMK
• Almacene la clave cifrada en DB
• Para cada solicitud, desciframos la clave de datos cifrados a través de AWS y obtuvimos la clave de datos de texto sin formato (básicamente no lo hacemos para cada solicitud, la almacenamos en caché durante algún tiempo en la memoria debido a problemas de costo / rendimiento).
• Hemos creado nuestra propia biblioteca de cifrado (utilizando AES-256 con CBC con IV aleatorio / sal aleatoria para cada solicitud)
• Luego, usando la clave de datos de texto sin formato, llamamos a la biblioteca AES para encriptar / desencriptar.

Ahora tengo algunas preguntas

1. a) ¿Cuántas claves de datos diferentes necesitamos crear? Me refiero a si debería ser diferente para cada columna / diferente para cada servicio / equipo que llama.

2. ¿AES-256 con CBC (Random SALT / Random IV para cada solicitud) está bien para nuestro caso de uso o necesito usar AES con GCM?

3. ¿Necesito rotar las claves de datos?

Answer 1

No podemos conocer las respuestas. Depende completamente de su caso de uso, del cual ha explicado muy poco.

Algunas consideraciones:

1. ¿Cuántas claves de datos necesitas crear? Tantos como tengas diferentes permisos de acceso. Por ejemplo: si group1 tiene acceso a col1, col2, col3 y group2 tiene acceso a col1, col4, col5, necesitaría 3 claves de datos (una para col1, una para col2 / 3 y otra para col4 / 5). Si desea ser realmente flexible, por ejemplo, porque su organización se reorganiza con frecuencia, puede optar por utilizar más claves, por ejemplo, una por columna.

2. Optaría por GCM, por las siguientes razones:

• actuación
• CBC es menos seguro (ataques de relleno fe)
• Siempre me ha gustado Evariste Galois

1. Eso depende demasiado de tu aplicación. Para bases de datos muy grandes que contienen muchos años de datos históricos, la rotación de claves a menudo no es práctica. Para bases de datos pequeñas donde el valor de los datos es limitado en el tiempo, podría hacerlo.