Si debo almacenar diferentes tipos de datos confidenciales, digamos: campo1 en la Tabla A y campo2 en la Tabla B y los datos no están relacionados, ¿debo usar una clave diferente para cada campo?
Añadir información 1: El cifrado / descifrado tendrá lugar en el código de la aplicación y la base de datos solo almacenará los datos cifrados.
Añadir información 2: En este momento, estoy planeando usar AES-256-CBC y la base de datos es MongoDB.
Según la información proporcionada en la actualización, sugeriría usar la misma clave para cada campo. Diferentes claves serían una exageración, ya que es posible que también desee cifrar otros campos y también sería complicado asignar los campos con diferentes claves.
Los siguientes puntos pueden considerarse con este enfoque:
Edición 1:
Depende.
En general, la razón principal para usar diferentes claves es: es posible que desee suministrar diferentes partes de los datos a diferentes subsistemas. Si hay algunas columnas procesadas por un sistema A y algunas columnas procesadas por un sistema B, es posible que desee utilizar claves diferentes para estos grupos de columnas. (Esta consideración también puede aplicarse si un subsistema necesita acceso a todas las columnas y otro solo a algunas).
Sin embargo, si todo el procesamiento ocurre dentro de un solo subsistema, es decir, todas las claves se distribuyen juntas y todas las partes de los datos siempre se descifran juntas, la gestión de claves separadas no será muy beneficiosa en términos generales del mantenimiento de la confidencialidad, y los beneficios de casi cero probablemente serán superados por los costos de complejidad adicional.
Entonces, este es el eje espacial. Sin embargo, dependiendo de su contexto, es posible que también deba considerar el eje del tiempo, por lo que las claves de cifrado pueden cambiar con el tiempo, y es posible que los datos cifrados con claves diferentes se mantengan en las mismas columnas . Por ejemplo, una combinación de una política de cambio regular de la clave de cifrado y los costos de descifrar y volver a cifrar un gran conjunto de datos puede requerir la protección del aspecto accesibility de la seguridad de los datos al realizar el nuevo cifrado. procese en pequeños pasos, lo que significa que durante el cambio, su sistema puede encontrar tanto datos encriptados con la clave antigua que caducará pronto como los datos encriptados con la nueva recientemente emitida.
Volviendo a lo que pidió, es bastante inusual que no se pueda confiar en que una base de datos tenga acceso a los datos que contiene, por lo que no hay mejores prácticas establecidas para este tipo de situaciones. Es más común ejecutar la base de datos completa en un almacenamiento de datos encriptados, generalmente en forma de un sistema de archivos de algún tipo, o tratar a la base de datos como un tipo de dispositivo de bloque, que solo sirve blobs encriptados opacos cuyo significado completo será luego determinado en la parte del sistema en la que confía lo suficiente como para tener las claves criptográficas. Analice, por ejemplo, contra qué tipo de ataques potenciales quiere proteger su sistema. Si le preocupa que un atacante pueda leer datos de su base de datos, también le debería preocupar que el atacante pueda insertar datos falsos, posiblemente datos que no comprenda, en su base de datos, o reemplazar datos buenos con ¿Malos datos o basura?
Lea otras preguntas en las etiquetas encryption databases