Las Bases de Datos y el RGPD…¡Vamos a Cifrar! (3/3)

Carlos Rodríguez  28 diciembre, 2018
Las Bases de Datos y el RGPD...¡Vamos a Cifrar! (3/3) imagen

Antes de hablar de los algoritmos de cifrados recomendados, por ejemplo, para SQL y Oracle, y los que están en desuso, vamos a explicar los algoritmos de cifrado a utilizar, incidiendo en los tipos de algoritmos simétricos y asimétricos, ya que por ejemplo Oracle soporta los dos tipos.

Como veremos mas adelante, el simétrico usa la misma clave para encriptar y desencriptar y ambas están disponibles. El asimétrico, en cambio, usa dos claves, una publica para encriptar y una privada para desencriptar, tanto al hacer login en la BBDD como en la comunicación entre la misma BBDD servidor y cliente.
Como hemos dicho, es necesario seleccionar el algoritmo de cifrado adecuado para el caso de uso, como el cifrado, la firma y la validación, utilizando el esquema adecuado.
  • Cifrado simétrico: se utiliza para garantizar la confidencialidad. Los socios de comunicación deben mantener la misma clave para cifrar o descifrar un mensaje. Ejemplos: 3DES y AES.
  • Cifrado asimétrico (o clave pública): se utiliza para garantizar la confidencialidad. En el caso de la transmisión de mensajes, un remitente utiliza la clave pública del destinatario para cifrar el mensaje, mientras que el destinatario utiliza la clave privada correspondiente para el descifrado. El remitente puede acceder a la clave pública del destinatario a través de un directorio de claves de confianza. Ejemplos: RSA y ECIES.
  • MAC (Código de autenticación de mensajes): se utiliza para garantizar la autenticidad y la integridad de los mensajes. Los compañeros de comunicación deben mantener la misma clave. Ejemplos: HMAC y CMAC.
  • Firmas: Para firmar un mensaje, generalmente se asigna una función hash criptográfica para obtener un resumen breve del mismo. El resumen se transforma con la clave privada del firmante para obtener una firma. Cualquier titular de la clave pública del firmante puede verificar si una firma autentica un mensaje bajo la clave privada correspondiente, pero los titulares de la clave pública no pueden generar firmas por sí mismos. Como tal, la firma autentica de forma única el mensaje como originado por el firmante, lo que permite servicios de no repudio. Ejemplos: RSA, y ECDSA.
Además, uno debe considerar el tamaño de clave relevante de acuerdo con el modelo de amenaza exacto. Tanto Oracle como SQL recomiendan el uso de AES 128, AES 192 y AES 256, y en desuso, aunque disponibles estarían DES (Data Encryption Estándar), 3DES, 3DES 3KEY, DESX, RC2, RC4, RC4 128…
Llegados a este punto, tenemos que hablar de dónde ubicar las claves y cómo protegerlas y administrarlas. Esto daría para otro articulo completo, por lo que vamos a resumir los métodos típicos de administración de claves de cifrado mas utilizados:
  • Cifrado de disco completo
  • Cifrado del sistema de archivos
  • Cifrado de base de datos: Las soluciones para el cifrado de base de datos difieren en la ubicación de las claves de cifrado:
    • HSM
    • Vault
    • CSP KMS
    • Dentro de la base de datos
  • Cifrado a nivel de aplicación:
    • Los desarrolladores de aplicaciones implementan varias metodologías de seguridad, como los HSM; las claves de cifrado rara vez se almacenan dentro de la propia aplicación.
Conclusión
Los estándares regulatorios actuales, tanto dentro como fuera de la UE, abogan por la encriptación de los datos como método para proteger los mismos y evitar sanciones regulatorias. En este sentido, la recomendación es migrar aplicaciones y BBDD a entornos seguros, tanto de programación como de BBDD (Oracle, Microsoft SQL, etc.), actualizados a las ultimas versiones y con las configuraciones de seguridad correspondientes. Como ya hemos visto, hay muchas maneras de hacerlo con las capas de seguridad apropiadas.
Es cierto que en ocasiones el desarrollo ha primado la funcionalidad sobre la seguridad, y este tópico es uno de los que hay que combatir, aunque, por ejemplo, si hablamos de antiguas aplicaciones en 32 bits (que aun corren muchas por ahí), cuantas más capas de seguridad, menos funcionalidad tenían, pero como decía, están o deben estar en desuso, ya que la propia tecnología y el cumplimiento normativo las está dejando fuera.
Para visualizarlo mejor, imaginemos un entorno donde nuestra aplicación de gestión corriera en un lenguaje de programación descatalogada por el fabricante y nuestra base de datos se pudiera abrir con un editor de texto cualquiera. Por mucho que cifráramos discos duros y todos nuestros datos, deberíamos dejar fuera la BBDD de dicha encriptación, poniendo en peligro la seguridad de los datos  y, por consiguiente, el cumplimiento normativo, exponiendo nuestra organización a duras sanciones, perdida de reputación, etc.
Los usuarios de aplicaciones y Bases de Datos obsoletas tienen que estar atento, seguramente no cumplan la norma y sus datos y los de sus clientes pueden estar en peligro. Encriptar, por favor.
 

También te puede interesar:
» Las Bases de Datos y el RGPD…¡Vamos a Cifrar! (1/3)
» Las Bases de Datos y el RGPD…¡Vamos a Cifrar! (2/3)

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *