Cifrado y protección de datos

El mismo archivo, 2 riesgos distintos

Un ingeniero de soporte que está depurando un problema captura el tráfico de red entre una app y su base de datos mientras está sentado en una cafetería. Si esa conexión no está cifrada, el ingeniero, o cualquier otra persona en el mismo wifi corriendo la misma captura, puede leer cada contraseña y cada campo que viaje por ahí, en texto plano, en el momento en que ocurre.

Ahora imagina un momento totalmente distinto: meses después, un disco de respaldo dado de baja de esa misma base de datos se vende o se descarta sin borrarlo bien, y alguien lo conecta. Si los datos ahí nunca se cifraron, puede leerlos directo del disco, sin necesidad de ninguna captura de red.

Los mismos datos, 2 puntos de ataque completamente distintos, meses aparte. Protegerse de uno no hace nada para protegerse del otro, y por eso las plataformas de nube tratan estos 2 casos como controles separados: cifrado en tránsito para los datos en movimiento, y cifrado en reposo para los datos quietos.

Cifrado en reposo: AES-256 y cifrado del lado del servidor

El cifrado en reposo protege los datos escritos en almacenamiento (discos, respaldos, archivos de base de datos) para que cualquiera que consiga acceso al medio de almacenamiento físico o lógico sin autorización solo vea texto cifrado ilegible. El mecanismo estándar en cualquier proveedor de nube grande es AES-256, el cifrado por bloques Advanced Encryption Standard de 256 bits, aplicado de forma automática o bajo pedido a los datos mientras se escriben.

AWS le llama a su enfoque por defecto cifrado del lado del servidor: el propio servicio de almacenamiento cifra los datos antes de escribirlos y los descifra al momento de devolverlos, todo adentro del servicio, usando llaves administradas mediante un sistema de gestión de llaves. Un cliente normalmente no toca el cifrado directamente; elige una opción de gestión de llaves y el servicio de almacenamiento se encarga del resto.

Cifrado en tránsito: TLS

El cifrado en tránsito protege los datos mientras se mueven entre 2 puntos de una red (una app móvil y un servidor, un load balancer y una instancia de aplicación, un microservicio y otro). El mecanismo estándar es TLS, Transport Layer Security, que envuelve una conexión para que cualquiera que capture el tráfico de red crudo solo vea texto cifrado, no la solicitud ni la respuesta en sí.

Desde mediados de 2024, todo endpoint de la API de AWS exige al menos TLS 1.2 y soporta TLS 1.3, la versión más nueva y rápida del protocolo. Esa base mínima refleja un patrón de toda la industria: las versiones viejas de TLS y su predecesor, SSL, se van retirando a medida que se acumulan debilidades criptográficas, y la guía actual sigue empujando ese mínimo aceptado hacia adelante.

El vacío del medio: los datos en uso

Fíjate en lo que ninguna de las 2 protecciones cubre. Apenas una solicitud llega al servidor de aplicación, los datos se tienen que descifrar en memoria, aunque sea brevemente, para que la aplicación pueda hacer algo con ellos: correr un cálculo, mostrar una página, revisar una condición. Ese estado en memoria a veces se llama datos en uso, y queda fuera de lo que alcanzan el cifrado en reposo y en tránsito estándar. Es un problema más angosto y especializado, y es la razón por la que "todo está cifrado" es una simplificación: el cifrado en reposo y en tránsito cubren la enorme mayoría del recorrido de una solicitud, pero no el instante en que la aplicación está trabajando de forma activa con el texto plano.

Gestión de llaves: separar quién puede descifrar de quién tiene la llave

Cifrar los datos es solo la mitad del problema; controlar quién puede descifrarlos es la otra mitad, y eso es justo lo que hace un servicio de gestión de llaves. AWS KMS corre dentro de módulos de seguridad de hardware construidos para que las llaves en texto plano nunca salgan del módulo, ni siquiera para el propio personal de AWS. Una solicitud para cifrar o descifrar algo se autoriza de forma independiente mediante los mismos permisos de IAM que viste en la lección anterior, lo que significa que el acceso a los datos y el acceso a la llave que los desbloquea son 2 capas controladas por separado. Comprometer una no entrega la otra de forma automática, y cada uso de una llave queda registrado, dejando un rastro auditable de exactamente cuándo y por quién se descifró un dato.

El límite: servicio de llaves administrado frente a hardware dedicado

La mayoría de las cargas de trabajo usan un servicio de llaves administrado como AWS KMS: hardware compartido, multiusuario, detrás de una API sencilla, con AWS encargándose del aprovisionamiento, los parches y la disponibilidad. Algunas cargas de trabajo, casi siempre por un requisito regulatorio específico, necesitan en cambio un módulo de seguridad de hardware dedicado, como AWS CloudHSM, que le da al cliente control administrativo directo sobre hardware exclusivo suyo que administra solo. La regla de decisión es angosta: por defecto usa el servicio administrado, y recurre al hardware dedicado solo cuando un requisito de cumplimiento exige de forma específica control de un solo cliente, porque esa opción cambia comodidad por una carga de escalamiento y administración que ahora es del cliente.

Error de concepto: el cifrado reemplaza el control de acceso

Es tentador tratar "todo está cifrado" como el final de la conversación de seguridad. No lo es. El cifrado protege los datos contra alguien que roba el medio de almacenamiento o intercepta el tráfico de red sin autorización. No hace nada para frenar a alguien que ya tiene credenciales válidas y autorizadas, sea un empleado legítimo o un atacante que hizo phishing de una, de leer datos a los que tiene permiso de acceder, porque todo el sentido del cifrado es que el acceso autorizado lo descifra de forma correcta. Ese es exactamente el vacío que los controles de IAM de la lección anterior existen para cerrar, y las 2 protecciones están pensadas para trabajar juntas, no para reemplazarse.

Pistas de examen: en reposo o en tránsito

Dónde te deja esto

El cifrado en reposo y el cifrado en tránsito protegen los mismos datos en 2 puntos distintos de su recorrido, y un diseño completo necesita los 2, porque cubrir solo uno deja el otro completamente abierto. Ninguno de los 2, sin embargo, decide quién tiene permiso de pedir esos datos en primer lugar; ese trabajo se quedó con la gestión de identidad y acceso de la lección anterior. Juntos, los 2 controles responden "quién puede actuar" y "qué pasa si roban un disco o comprometen una red de todos modos". La siguiente lección aborda una pregunta relacionada: cómo demuestra un equipo, ante un auditor o un regulador, que los 2 controles de verdad están en su lugar.