El cifrado y la tokenización no son suficientes

Tras los desafíos que afrontaron las empresas con la aplicación del GDPR, ahora La ‘Ley CLOUD’ también plantea una serie de retos para las organizaciones europeas.

Las autoridades de EE.UU. pueden acceder a los datos que se encuentran físicamente en Europa si han sido procesados o almacenados por proveedores de hosting o cloud de EE.UU., o sus sucursales en otros países. Además de los propios proveedores, el Reglamento General de Protección de Datos también señala que la información personal debe estar encriptada o bajo seudónimos. Ambas opciones plantean un reto para el almacenamiento en la nube.

Cifrado: ¿dónde está la clave?

Al cifrar o descifrar datos, siempre se debe tener a mano una clave, y ésta debe mantenerse en secreto. Esto plantea la pregunta de cómo se puede transferir una clave de este tipo de forma segura a la nube o gestionarse de forma discreta. En este sentido hay dos enfoques que compiten entre sí.

Trae tu propia clave

BYOK, o ‘Bring Your Own Key’, es la idea de que un cliente almacena datos cifrados en la plataforma de un proveedor de cloud computing y genera la clave él mismo. Lo ideal es que sólo el propio cliente pueda acceder a la clave. Sin embargo, una solución BYOK pura tiene sus puntos débiles porque el proveedor de la nube tiene el software de encriptación, y por lo tanto la posibilidad de generar una clave maestra propia. Esto permite al proveedor descifrar datos cifrados. El proveedor puede incluso tener que conceder a las autoridades del país en el que tienen su sede el acceso a la encriptación.

La Ley CLOUD no exige explícitamente a los proveedores de cloud computing que descifren los datos, pero tampoco lo prohíbe específicamente. De lo contrario, la finalidad protectora de esta norma sería ineficaz. Es por eso por lo que los proveedores pueden participar en el descifrado de datos sin violar la ley CLOUD.

El proveedor de servicios cloud también tiene el hardware del servidor utilizado para el almacenamiento. En el momento en el que los datos son desencriptados en la nube, tanto la clave como los datos a procesar deben ser transferidos a la memoria principal del servidor. Cualquier persona con acceso físico o virtual al servidor o al sistema operativo puede copiar la memoria principal, extraer datos descifrados o extraer la clave.

Trae tu propio cifrado

BYOE, o ‘Bring Your Own Encryption’, va un paso más allá. Aquí los clientes no sólo generan la clave. También obtienen y gestionan un criptoalgoritmo. La encriptación ya no es responsabilidad del proveedor de la nube. Sin embargo, las herramientas de encriptación comercial también tienen un inconveniente; su código fuente no suele ser divulgado. Como tal, nadie sabe si hay puertas traseras incorporadas en estas soluciones comerciales.

Si se utiliza código abierto para el cifrado, los clientes encontrarán al menos código limpio. Sin embargo, debe tenerse en cuenta que las herramientas de código abierto para la encriptación normalmente ofrecen soluciones para un solo usuario. No permiten grupos o administración de diferentes claves. Además, no suelen estar tan bien integrados para usarlos tal y como prescribe el RGPD para la “Privacidad desde el diseño”.

Por lo tanto, en la práctica no existe actualmente una solución perfecta para todos los requisitos de cifrado en la nube. Además, algunos reguladores clasifican la encriptación en la nube como inaceptable porque es matemáticamente reversible y puede ser interceptada en la nube.

Tokenización

Comparado con la encriptación, la tokenización es un enfoque fundamentalmente diferente de la pseudonimización. Aquí, los valores seudónimos se asignan aleatoriamente a los valores originales y sólo estos datos modificados se transfieren a la nube en lugar de al original. Por lo tanto, el riesgo de descifrado es menor, sobre todo porque no existe una relación matemática entre el original y el valor de cifrado. Los datos reales, así como la tabla de asignación de fichas, se almacenan normalmente en el área de control físico de la empresa con necesidad de confidencialidad.

Sin embargo, tras revisarlo, este procedimiento también ha resultado tener un inconveniente. Sin una tabla de asignación de tokens, los tokens nunca pueden utilizarse para asignar datos originales y seudónimos. Cualquiera que secuestre esta tabla de asignación de tokens puede manipular los datos por sí mismo para cambiar la asignación o el enlace.

La codificación de la tabla de asignación de tokens aumenta su seguridad relativa. Como consecuencia, la velocidad del procesamiento de datos se verá afectada. Las aplicaciones SaaS o IoT difícilmente pueden ser operadas de esta manera. Y ya sea que estén encriptados u ocultos mediante tokens, los metadatos generados en torno al procesamiento de datos son siempre legibles.

Solución: el proveedor de cloud adecuado

Ni la encriptación ni la tokenización ofrecen seguridad absoluta. La combinación de ambas tecnologías, es decir, la correcta manipulación de las claves junto con el uso de fichas, ya ofrece un nivel aceptable de protección. Sin embargo, también debe cumplirse un requisito previo: el cliente debe elegir un proveedor de alojamiento o de servicios en la nube que no pueda ser obligado legalmente a hacer que los datos seudónimos sean legibles. Por ejemplo, la US CLOUD Act no prohíbe a los proveedores de cloud computing de EE.UU. descifrar los datos, independientemente de las condiciones. El actual caso Huawei muestra que las autoridades estadounidenses no tienen miedo de bloquear el software y el hardware extranjero. Los proveedores alemanes y europeos, como 1&1 IONOS, tienen que actuar de forma notable en interés del cliente. Y el GDPR como única regulación legal obliga a todas las empresas de procesamiento de datos a ejercer el mayor cuidado posible en el interés del cliente.