Una empresa almacena contratos, datos de clientes y registros financieros en un servicio de almacenamiento en la nube. El proveedor cifra los datos en reposo. Todo parece en orden. Lo que nadie notó: el proveedor también gestiona las claves de cifrado. Un empleado del proveedor con acceso a esas claves —o un atacante que las compromete— puede acceder a los datos aunque estén técnicamente cifrados.
Cifrado sí. Pero las llaves están en el cajón equivocado.
Cifrado en reposo, en tránsito y en uso: tres estados, tres problemas distintos
El cifrado en reposo protege los datos cuando están almacenados —en un disco, en una base de datos, en un objeto de almacenamiento. Es el más común y el que los proveedores de nube habilitan por defecto con mayor frecuencia. El problema, como ilustra el escenario de apertura, está en quién controla las claves.
El cifrado en tránsito protege los datos mientras se mueven de un punto a otro: entre el cliente y el servidor, entre servicios, entre regiones. TLS es el mecanismo estándar. Su implementación correcta —versión actualizada, certificados válidos, configuración que no permita protocolos obsoletos— requiere verificación activa. No basta con haber habilitado HTTPS alguna vez.
El cifrado en uso es el más reciente y el menos implementado. Protege los datos mientras están siendo procesados, incluso en memoria. Su adopción está creciendo en sectores con datos altamente sensibles, pero todavía no es el estándar en la mayoría de los entornos empresariales. Para la mayoría de las organizaciones, el foco debe estar en tener bien implementados los dos primeros antes de preocuparse por el tercero.
La pregunta que más se ignora: ¿quién controla las claves?
El cifrado es tan seguro como el control que se tiene sobre las claves. Cuando el proveedor de nube gestiona las claves, el cifrado protege contra accesos no autorizados externos —un atacante que accede al disco físico del datacenter, por ejemplo— pero no necesariamente contra el propio proveedor, contra una brecha en la infraestructura del proveedor o contra una orden legal que obligue al proveedor a entregar los datos.
Cuando la organización gestiona sus propias claves —usando un sistema de gestión de claves externo al proveedor de nube o usando hardware especializado— el nivel de control aumenta significativamente. El proveedor puede tener acceso al dato cifrado, pero no a la clave para descifrarlo. Para datos sujetos a regulaciones de privacidad como la LFPDPPP o para información cuya confidencialidad es crítica para el negocio, esa distinción no es técnica: es estratégica.
Los errores más comunes en implementaciones de cifrado cloud
El primero es cifrar todo igual sin clasificar primero. No todos los datos tienen el mismo valor ni el mismo riesgo. Cifrar con el mismo esquema un archivo de presentaciones internas y una base de datos de tarjetas de pago es un uso ineficiente de recursos y genera una falsa sensación de cobertura uniforme. La clasificación de datos debe preceder a la estrategia de cifrado.
El segundo es no rotar las claves. Una clave de cifrado que nunca cambia es una superficie de compromiso que crece con el tiempo. Si la clave fue expuesta en algún momento —por error de configuración, por acceso no autorizado, por un empleado que ya no está en la organización— todos los datos cifrados con ella quedan en riesgo de forma retroactiva. La rotación periódica de claves es un control básico que muchas organizaciones tienen documentado y pocas ejecutan con consistencia.
El tercero es no verificar que el cifrado en tránsito está activo en todas las conexiones. Es frecuente encontrar entornos donde el tráfico entre servicios internos no está cifrado bajo el supuesto de que "ya están dentro de la red privada". En arquitecturas cloud modernas, ese supuesto es incorrecto. El tráfico interno entre servicios es un vector de intercepción real.
¿Qué hacer al respecto?
El primer paso es clasificar los datos antes de diseñar la estrategia de cifrado. No todos los datos necesitan el mismo nivel de protección. Los que contienen información personal regulada, secretos comerciales o datos financieros críticos merecen una estrategia de cifrado con gestión de claves propia. El resto puede funcionar adecuadamente con el cifrado estándar del proveedor, bien configurado.
El segundo paso es verificar activamente el estado del cifrado, no asumirlo. Confirmar que el cifrado en reposo está habilitado para cada servicio y cada tipo de almacenamiento que se usa, que el cifrado en tránsito está activo en todas las conexiones —incluidas las internas— y que las versiones de protocolo están actualizadas. Ese inventario de estado real suele revelar brechas que nadie sabía que existían.
El tercer paso es implementar un proceso de gestión de claves. Quién puede crear claves, quién puede usarlas, con qué frecuencia se rotan, cómo se almacenan y qué pasa si una clave se pierde o se compromete. Sin ese proceso documentado y operativo, el cifrado es un control técnico sin gobierno.
¿Sabes hoy quién tiene acceso a las claves de cifrado de tus datos más sensibles en la nube, y si alguna de esas claves ha sido rotada en los últimos doce meses?
Acciones inmediatas
- Verifica que el cifrado en reposo está habilitado para todos los servicios de almacenamiento que tu organización usa en la nube. Bases de datos, objetos de almacenamiento, discos de instancias, servicios de mensajería. Cada uno puede tener su configuración de cifrado independiente y no todos están habilitados por defecto en todos los proveedores.
- Identifica qué datos sensibles están cifrados con claves gestionadas por el proveedor y evalúa si eso es aceptable para tu perfil de riesgo y tus obligaciones regulatorias. Para datos personales bajo LFPDPPP o información financiera crítica, la gestión de claves propia puede ser un requerimiento implícito, no una opción de confort técnico.
- Revisa si el tráfico entre servicios internos en tu entorno cloud está cifrado o circula en texto claro. El supuesto de que la red privada del proveedor es segura no es suficiente en arquitecturas distribuidas modernas. Una revisión de la configuración de TLS entre servicios suele revelar conexiones internas sin cifrar que nadie había identificado como riesgo.
- Establece un calendario de rotación de claves para los datos más sensibles y asigna un responsable de ejecutarlo. Sin fecha y sin responsable, la rotación de claves es una intención, no un control. La primera rotación siempre es la más difícil; una vez establecida la práctica, el proceso se vuelve rutinario.
- Documenta quién tiene acceso a las claves de cifrado de sistemas críticos y revisa si ese acceso sigue siendo necesario. El principio de mínimo privilegio aplica también a las claves. Una clave de cifrado accesible para diez personas cuando solo tres la necesitan es una superficie de compromiso más amplia de la que el dato en sí requiere.
Si tu organización quiere evaluar su estrategia de cifrado en la nube e implementar gestión de claves con el nivel de control adecuado a su perfil de riesgo, contáctanos en https://tbsek.mx/contacto/.
