Lo que realmente exige la protección de CUI en cuanto a la custodia de claves

Cada proveedor de plataformas que trabaja con contratistas de defensa afirma que CUI está cifrada. Esa afirmación oculta el detalle que realmente determina la protección: quién tiene la clave. Si la clave la tiene el proveedor, el cifrado protege los datos controlados de terceros, pero no hace nada para protegerlos del propio proveedor ni de quienes puedan obligar legalmente a ese proveedor a descifrar.

No es una preocupación hipotética para un contratista que mueve datos técnicos sujetos a control de exportaciones a través de plataformas de terceros. Un armario cerrado no sirve de nada si el proveedor guarda una copia de la llave y la entrega en cuanto una autoridad extranjera la solicita. Este artículo analiza cómo la custodia de claves cambia realmente la situación para los contratistas de defensa, por qué es el detalle que la mayoría de las revisiones de seguridad pasan por alto y qué implica en la práctica una gestión de claves realmente controlada por el cliente, hasta quién puede rotar la clave y en qué plazos.

Resumen ejecutivo

Las revisiones de seguridad de plataformas que gestionan CUI suelen detenerse en el algoritmo de cifrado y la longitud de la clave, como si AES-256 cumpliera automáticamente las expectativas de control de exportaciones. No es así. La pregunta que realmente determina la protección es quién controla la clave, porque quien controla la clave controla los datos, haya cifrado o no. Cuando un proveedor genera, almacena y administra la clave en nombre del contratista, ese proveedor conserva la capacidad técnica de leer datos técnicos controlados en cualquier momento y por cualquier motivo, incluso por razones que el contratista nunca aceptó y puede no conocer hasta mucho después. La gestión de claves propiedad del cliente, respaldada por hardware, elimina por completo esa capacidad. Para los responsables de seguridad de programas, esto redefine el cifrado: deja de ser un simple requisito documental y pasa a ser un hecho arquitectónico concreto y comprobable que un evaluador puede verificar directamente durante una revisión de CMMC o de control de exportaciones.

Puntos clave

1. El cifrado solo protege los datos de quienes no tienen la clave. Si la clave la tiene el proveedor, la protección de CUI depende de la voluntad del proveedor, no del cifrado en sí.
2. Los modelos de trae-tu-propia-clave eliminan por completo la capacidad del proveedor de descifrar, apoyando directamente los requisitos de control de exportaciones. Una clave gestionada por el proveedor deja esa capacidad totalmente intacta, sin importar el algoritmo utilizado ni cómo se describa en una propuesta.
3. Un módulo de seguridad hardware convierte la propiedad de la clave en un hecho físico, no en una política. Una clave generada y almacenada en un HSM controlado por el contratista no puede ser extraída por la plataforma que aloja los datos, ni siquiera con acceso administrativo.
4. La rotación de claves bajo demanda es parte de la verdadera propiedad. Si el contratista no puede rotar la clave según sus propios plazos, no tiene control operativo total sobre los datos técnicos controlados.
5. La fortaleza del cifrado es irrelevante si la clave la tiene la parte equivocada. La pregunta importante para CUI es quién puede descifrar, no cuán fuerte es el cifrado.

Por qué la fortaleza del cifrado no es la pregunta correcta para CUI

Las revisiones de seguridad preguntan constantemente por el cifrado, y las respuestas casi siempre describen el algoritmo: AES-256 en reposo, TLS 1.3 en tránsito. Son respuestas correctas, pero en gran medida irrelevantes.

Los datos cifrados siempre tienen un propietario de la clave

Cada archivo CUI cifrado tiene exactamente una cosa que lo separa de una lectura en texto claro: la clave. Quien tiene esa clave puede leer los datos, descifrarlos para otra persona o verse obligado a descifrarlos por un proceso legal. Un archivo cifrado con un algoritmo robusto y una clave en manos del proveedor no está realmente más protegido del proveedor que un archivo con cifrado más débil, porque el factor limitante en ambos casos es el mismo: el proveedor puede leerlo si quiere o si se lo ordenan.

Por qué los proveedores rara vez destacan esta diferencia

La documentación de los proveedores suele describir el cifrado en términos que suenan completos: «cifrado en reposo y en tránsito usando algoritmos estándar de la industria». Es correcto pero incompleto. No dice nada sobre quién generó la clave, dónde se almacena o si la propia infraestructura del proveedor puede acceder a ella, que es precisamente la brecha que una revisión de control de exportaciones busca cerrar.

Qué implica realmente la gestión de claves propiedad del cliente

Ser propietario de una clave no es una sola función, sino una cadena de condiciones que deben cumplirse todas. Si se rompe cualquier eslabón, el control del contratista sobre la clave pasa a ser teórico en vez de operativo.

Trae tu propia clave frente a clave gestionada por el proveedor

En un modelo de clave gestionada por el proveedor, la plataforma genera y almacena la clave de cifrado como parte de su propia infraestructura, y el contratista puede que nunca vea la clave. En un modelo de clave propiedad del cliente, el contratista controla la generación y almacenamiento de la clave, normalmente a través de un módulo de seguridad hardware que administra o al que tiene acceso dedicado. La diferencia es la diferencia entre un proveedor que puede técnicamente descifrar CUI y uno que no puede, sin importar lo que diga el material de marketing de ambos sobre la fortaleza del cifrado.

Por qué los módulos de seguridad hardware son más importantes de lo que parece

Un módulo de seguridad hardware es un dispositivo físico dedicado a generar, almacenar y gestionar claves criptográficas de forma que resiste la extracción, incluso por alguien con acceso administrativo al sistema que lo rodea. Integrar la gestión de claves con un HSM, en vez de almacenar las claves en software junto a la aplicación, convierte la propiedad de la clave en una restricción física. Una afirmación basada solo en software sobre la propiedad de la clave por parte del cliente puede, en principio, ser revertida silenciosamente por un proveedor con suficiente acceso a su propia infraestructura. Un HSM correctamente integrado elimina esa posibilidad por diseño, no por política.

Por qué la rotación y el control de cifrado determinan si la propiedad es real

Tener la clave una vez no es lo mismo que controlarla de forma continua. Dos detalles operativos separan la verdadera propiedad de la clave de una afirmación que parece correcta en una ficha técnica pero se desmorona ante las preguntas de un evaluador.

Rotación de claves bajo demanda

Si un contratista sospecha que una clave puede haber sido expuesta, ya sea por una credencial comprometida, la salida de un empleado o una posible brecha, la capacidad de rotar esa clave de inmediato, sin esperar al calendario de lanzamientos del proveedor ni a la cola de soporte, es lo que da sentido operativo a la propiedad de la clave para datos controlados.

Control granular de cifrados y protocolos

Poder habilitar o deshabilitar conjuntos de cifrado específicos y controlar qué versiones de TLS se permiten es una forma de control relacionada pero distinta, que el contratista debe poder ejercer según sus propios plazos y no los del proveedor, especialmente al retirar un cifrado obsoleto antes de una evaluación.

Cómo integrar la custodia de claves en la evaluación de proveedores

Para un equipo de seguridad de programas que evalúa a un proveedor, el cambio práctico es fácil de describir y sencillo de pasar por alto por la presión del tiempo: pregunta quién genera la clave, dónde se almacena, si hay un HSM involucrado y quién puede rotarla y en qué plazos. Un proveedor que responde claramente a las cuatro, con el contratista controlando cada paso, tiene un modelo de custodia de claves defendible. Un proveedor que solo responde a la primera pregunta, sobre algoritmo y longitud de clave, no le ha dicho nada al contratista sobre quién controla realmente la CUI una vez cifrada.

Cómo un Data Control Plane convierte la propiedad de la clave en una garantía arquitectónica

La gestión de claves propiedad del cliente solo cumple su promesa cuando está integrada en la arquitectura de la plataforma y no ofrecida como un complemento que la mayoría de las implementaciones omiten. Un Data Control Plane que trata la custodia de claves como una propiedad fundamental garantiza que la incapacidad técnica del proveedor para descifrar CUI se mantenga en todos los canales por los que circulan los datos, incluyendo correo electrónico, uso compartido de archivos, APIs y agentes de IA.

El Data Control Plane de Kiteworks integra claves de cifrado propiedad del cliente a través de un módulo de seguridad hardware, incluyendo soporte para los proveedores de HSM más utilizados, de modo que la generación y almacenamiento de claves quedan fuera del alcance de Kiteworks. Los contratistas conservan la capacidad de rotar claves bajo demanda, controlar qué cifrados y versiones de TLS están habilitados y operar en una arquitectura de tenencia única donde esa custodia de claves no se comparte con el entorno de ningún otro cliente. Sobre esa base, controles de confianza cero y con conocimiento del dato gobiernan cada envío, uso compartido y acceso en todos los canales, y cada acción queda registrada en un registro de auditoría inalterable y sin limitaciones que se integra directamente con herramientas SIEM, de modo que la custodia de claves está respaldada por un historial de cumplimiento y no solo por una línea en una propuesta.

Los contratistas que quieran comparar el modelo de custodia de claves de su proveedor actual con este estándar pueden solicitar una demo personalizada para ver cómo la integración de HSM controlada por el cliente se aplica a su propia CUI y a los requisitos de control de exportaciones.