Cómo el cifrado AES-256 ayuda al cumplimiento de CMMC

Los contratistas de defensa que buscan la Certificación del Modelo de Madurez de Ciberseguridad (CMMC) 2.0 enfrentan un requisito fundamental: proteger la información no clasificada controlada (CUI) con cifrado que cumpla los estándares criptográficos federales. El cifrado AES-256 cumple este requisito cuando se implementa mediante módulos criptográficos validados por FIPS, pero el algoritmo de cifrado por sí solo no garantiza el cumplimiento. Los evaluadores de CMMC revisan no solo si existe cifrado, sino si está correctamente implementado, validado de manera adecuada y respaldado por buenas prácticas de gestión de claves.

La mayoría de las organizaciones en la Base Industrial de Defensa (DIB) buscarán la certificación CMMC nivel 2, que incorpora los 110 controles de seguridad de NIST SP 800-171. Varios de estos controles exigen explícitamente protección criptográfica para la CUI en reposo y en tránsito. Comprender cómo el cifrado AES-256 se relaciona con estos requisitos específicos —y dónde suelen aparecer brechas en la implementación— es esencial para lograr y mantener la certificación.

Esta guía analiza los requisitos de cifrado dentro del CMMC nivel 2, explica por qué el AES-256 cumple los estándares federales cuando se implementa correctamente y aborda la cuestión crítica de la gestión de claves de cifrado cuando la CUI reside en infraestructura en la nube.

Puntos clave

1. CMMC nivel 2 exige cifrado validado por FIPS para proteger la CUI en reposo y en tránsito, con requisitos específicos definidos en los controles NIST SP 800-171 SC.L2-3.13.8 y SC.L2-3.13.16.
2. Los contratistas de defensa deben usar módulos criptográficos validados por FIPS, no solo algoritmos aprobados por FIPS; la validación FIPS 140-3 es el estándar actual y demuestra cumplimiento con visión de futuro.
3. El cifrado AES-256 cumple los requisitos criptográficos de CMMC cuando se implementa dentro de un módulo validado y se aplica de forma coherente en todos los sistemas y canales de comunicación donde reside la CUI.
4. Cuando la CUI está en infraestructura en la nube autorizada por FedRAMP, la propiedad de las claves de cifrado impacta directamente en el cumplimiento de CMMC: las claves propiedad del cliente (donde solo tú puedes acceder a las claves) establecen límites de control claros frente a las claves gestionadas por el cliente (donde el proveedor de la nube mantiene acceso).
5. Las prácticas de gestión de claves de cifrado reciben un escrutinio significativo durante las evaluaciones CMMC, incluida la documentación de los procedimientos de generación, almacenamiento, rotación y destrucción de claves en el Plan de Seguridad del Sistema.

Requisitos de cifrado CMMC por nivel de certificación

CMMC 2.0 establece tres niveles de certificación, cada uno con requisitos distintos según la sensibilidad de la información protegida. El nivel 2 aplica a organizaciones que manejan CUI y representa el nivel de certificación que la mayoría de los contratistas DIB buscarán.

CMMC nivel 1 está dirigido a organizaciones que solo manejan información sobre contratos federales (FCI) e incluye 17 prácticas básicas de protección. Estos controles fundamentales no incluyen requisitos explícitos de cifrado, aunque el cifrado sigue siendo una práctica recomendada para proteger cualquier dato sensible.

CMMC nivel 2 incorpora los 110 controles de NIST SP 800-171 Revisión 2, incluidos requisitos específicos para protección criptográfica. La familia de controles de Protección de Sistemas y Comunicaciones (SC) contiene los principales mandatos de cifrado. El control SC.L2-3.13.8 exige mecanismos criptográficos para proteger la CUI durante la transmisión, mientras que SC.L2-3.13.16 exige protección de la CUI en reposo. Estos controles no especifican AES-256 por nombre, pero requieren implementaciones de cifrado que utilicen módulos criptográficos validados por FIPS.

CMMC nivel 3 aplica a organizaciones que manejan la CUI más sensible y añade controles de NIST SP 800-172. Estos requisitos mejorados pueden incluir procedimientos de gestión de claves más estrictos, evaluaciones criptográficas más frecuentes y protecciones adicionales contra amenazas persistentes avanzadas. Las organizaciones que buscan el nivel 3 deben anticipar un escrutinio más riguroso de su arquitectura de cifrado y prácticas de gestión de claves.

Por qué AES-256 cumple los estándares de CMMC nivel 2

El Estándar de Cifrado Avanzado con claves de 256 bits (AES-256) está aprobado por el Instituto Nacional de Estándares y Tecnología (NIST) para proteger información federal clasificada y no clasificada. Esta aprobación convierte a AES-256 en la opción adecuada para el cumplimiento CMMC, pero existe una distinción clave que determina si tu implementación realmente satisface los requisitos de evaluación.

Los evaluadores de CMMC verifican que el cifrado se implemente mediante módulos criptográficos validados por FIPS, no solo que se utilice un algoritmo aprobado por FIPS. Una organización podría implementar cifrado AES-256 usando bibliotecas de software no validadas y fallar la evaluación CMMC a pesar de usar el algoritmo correcto. El módulo criptográfico en sí —ya sea software, firmware o hardware— debe contar con un certificado FIPS 140 válido.

El gobierno federal está migrando de FIPS 140-2 a FIPS 140-3 como estándar de validación para módulos criptográficos. Los certificados FIPS 140-2 siguen siendo válidos hasta su fecha de expiración, pero las nuevas validaciones se emiten bajo FIPS 140-3. Las organizaciones que seleccionan soluciones de cifrado deben priorizar productos validados por FIPS 140-3, lo que demuestra alineación con los requisitos criptográficos federales actuales y evita el riesgo de depender de certificados FIPS 140-2 que puedan expirar durante un periodo contractual.

La longitud de clave de 256 bits proporciona el margen de seguridad adecuado para proteger la CUI. Aunque AES-128 también cuenta con aprobación NIST, AES-256 ofrece mayor resistencia ante futuros avances en criptoanálisis y se alinea con las preferencias del DoD para proteger información de defensa sensible.

Cifrado de CUI en reposo para cumplimiento CMMC

El control NIST SP 800-171 SC.L2-3.13.16 exige que las organizaciones protejan la confidencialidad de la CUI en reposo. Este requisito aplica dondequiera que se almacene la CUI: servidores de archivos, bases de datos, endpoints, sistemas de respaldo, archivos de correo electrónico y almacenamiento en la nube.

Los contratistas de defensa deben identificar todas las ubicaciones donde reside la CUI y verificar que el cifrado proteja cada repositorio. Escenarios comunes de almacenamiento que requieren cifrado incluyen planos de ingeniería y especificaciones técnicas almacenados en recursos compartidos de archivos, documentos contractuales y correspondencia en sistemas de gestión documental, archivos de correo electrónico con CUI intercambiada con agencias gubernamentales o subcontratistas, registros de bases de datos con información técnica controlada, cintas de respaldo y sistemas de recuperación ante desastres, y dispositivos endpoint como laptops usados por empleados con acceso a CUI.

El cifrado en reposo puede implementarse en varios niveles. El cifrado de disco completo protege volúmenes de almacenamiento enteros, mientras que el cifrado a nivel de archivo protege archivos individuales sin importar dónde se almacenen o muevan. El cifrado de bases de datos protege datos estructurados dentro de sistemas de gestión de bases de datos. Muchas organizaciones implementan cifrado en capas, combinando protección a nivel de volumen y de archivo para una defensa en profundidad.

La implementación de cifrado debe usar un módulo validado por FIPS. Las unidades de autocifrado, las funciones de cifrado del sistema operativo y las soluciones de cifrado de terceros requieren validación FIPS 140 para cumplir los requisitos CMMC. Las organizaciones deben mantener documentación de los números de certificado FIPS de cada producto de cifrado implementado en su entorno.

Cifrado de CUI en tránsito para cumplimiento CMMC

El control NIST SP 800-171 SC.L2-3.13.8 exige mecanismos criptográficos para prevenir la divulgación no autorizada de CUI durante la transmisión. Este requisito cubre todos los canales de comunicación usados para transmitir CUI: conexiones de red, correo electrónico, transferencias de archivos y comunicaciones API.

La seguridad de la capa de transporte (TLS) es la base para la mayoría del cifrado en transmisión. TLS 1.2 y TLS 1.3 admiten suites de cifrado que usan AES-256 para el cifrado masivo, cumpliendo los requisitos de fortaleza criptográfica para proteger la CUI. Las organizaciones deben configurar sus sistemas para requerir TLS 1.2 o superior y deshabilitar versiones anteriores del protocolo que tengan vulnerabilidades conocidas. TLS 1.3 ofrece mayor seguridad y rendimiento que TLS 1.2 y representa la mejor práctica actual para proteger la CUI en tránsito.

El correo electrónico representa un desafío particular para los contratistas de defensa. La transmisión estándar de correo electrónico no cifra el contenido de los mensajes de extremo a extremo, dejando la CUI expuesta mientras los mensajes atraviesan servidores de correo. Las soluciones de correo electrónico seguro que aplican cifrado AES-256 al contenido del mensaje —no solo al canal de transmisión— proporcionan la protección que CMMC exige para correos electrónicos con CUI.

Las operaciones de transferencia de archivos requieren atención similar. Secure File Transfer Protocol (SFTP) y FTPS admiten transmisión cifrada, pero las organizaciones deben verificar que sus implementaciones utilicen módulos criptográficos validados por FIPS. Las transferencias de archivos grandes entre contratistas de defensa, subcontratistas y agencias gubernamentales suelen contener CUI y requieren protección cifrada constante.

Las comunicaciones API entre sistemas también están sujetas a los requisitos de cifrado en transmisión. Las organizaciones que se integran con sistemas gubernamentales o intercambian CUI mediante interfaces automatizadas deben asegurar que estas conexiones utilicen canales cifrados adecuados.

Gestión de claves de cifrado en infraestructura autorizada por FedRAMP

Muchos contratistas de defensa aprovechan servicios en la nube autorizados por FedRAMP para almacenar y procesar CUI. Aunque la autorización FedRAMP confirma que un proveedor de servicios en la nube cumple los requisitos federales de seguridad, no satisface automáticamente las obligaciones de CMMC del contratista. El contratista sigue siendo responsable de su propio cumplimiento, incluyendo demostrar control adecuado sobre el acceso a la CUI.

La gestión de claves de cifrado determina quién puede realmente acceder a la CUI cifrada, sin importar dónde se almacene. Existen tres modelos de gestión de claves para datos alojados en la nube, cada uno con diferentes implicaciones para el cumplimiento CMMC.

Las claves gestionadas por el proveedor representan la implementación más simple: el proveedor de la nube genera, almacena y controla las claves de cifrado. Aunque los datos están cifrados, el proveedor mantiene la capacidad técnica de descifrarlos. Este modelo plantea dudas importantes durante la evaluación CMMC sobre si el contratista mantiene control suficiente sobre el acceso a la CUI.

Las claves gestionadas por el cliente (a menudo llamadas Bring Your Own Key o BYOK) otorgan al contratista control sobre la generación y el ciclo de vida de las claves, pero estas se cargan y almacenan dentro del servicio de gestión de claves del proveedor de la nube. El proveedor mantiene acceso técnico a estas claves y puede verse obligado a descifrar datos bajo la Ley CLOUD u otros procesos legales —a menudo sin notificar al cliente. Para CMMC, este modelo crea ambigüedad sobre quién controla realmente el acceso a la CUI.

Las claves propiedad del cliente (Hold Your Own Key o HYOK) ofrecen una separación real. El contratista mantiene las claves de cifrado exclusivamente en su propio sistema de gestión de claves o módulo de seguridad de hardware (HSM), y el proveedor de la nube nunca posee las claves. Incluso si el proveedor recibe una orden judicial, no puede descifrar la CUI porque no tiene las claves necesarias. Este modelo establece límites de control claros que satisfacen el escrutinio de los evaluadores CMMC.

El estatus de FedRAMP autorizado aborda la postura de seguridad del proveedor de la nube, pero no determina el enfoque de gestión de claves del contratista. Los evaluadores de CMMC examinarán cómo el contratista controla el acceso a la CUI. Las claves de cifrado propiedad del cliente —donde el contratista es el único capaz de descifrar la CUI— proporcionan evidencia definitiva de ese control. Las claves gestionadas por el cliente, a pesar de la terminología tranquilizadora, dejan a los proveedores de la nube con acceso técnico que complica la narrativa de cumplimiento.

Deficiencias comunes de cifrado en CMMC

Las evaluaciones CMMC identifican con frecuencia deficiencias relacionadas con el cifrado que impiden la certificación. Comprender estas brechas comunes ayuda a las organizaciones a prepararse de manera más efectiva.

El uso de módulos de cifrado no validados sigue siendo un hallazgo frecuente. Las organizaciones pueden implementar cifrado AES-256 mediante bibliotecas o productos que no cuentan con validación FIPS 140, sin cumplir el requisito de módulo validado aunque el algoritmo sea correcto.

La cobertura de cifrado incompleta genera brechas cuando la CUI no está cifrada en todas las ubicaciones donde reside. Los sistemas de correo electrónico, plataformas de colaboración y dispositivos endpoint suelen carecer de cifrado incluso cuando el almacenamiento principal de archivos está protegido.

La documentación insuficiente en el Plan de Seguridad del Sistema (SSP) genera hallazgos en la evaluación incluso cuando los controles técnicos están correctamente implementados. El SSP debe documentar los métodos de cifrado, números de certificado FIPS, procedimientos de gestión de claves y los sistemas cubiertos por los controles de cifrado.

Depender del cifrado del proveedor de la nube sin comprender las implicaciones de la gestión de claves puede crear ambigüedad sobre el control de acceso a la CUI. Los evaluadores examinarán si el contratista o el proveedor de la nube controla finalmente el acceso a la CUI cifrada.

Los certificados de validación FIPS desactualizados presentan riesgos de cumplimiento si expiran durante un periodo contractual. Las organizaciones deben monitorear las fechas de expiración de los certificados de todos los productos de cifrado en su entorno.

Las brechas en la cobertura de cifrado durante el movimiento de datos ocurren cuando la CUI está protegida en reposo y durante la transmisión externa, pero se mueve sin cifrar entre sistemas internos. Los evaluadores examinan el flujo de datos completo, no solo el almacenamiento y las comunicaciones externas.

Protege la CUI con las sólidas capacidades de cifrado de Kiteworks

La certificación CMMC nivel 2 exige que los contratistas de defensa demuestren que la CUI está protegida por cifrado validado por FIPS en reposo y en tránsito, respaldado por prácticas documentadas de gestión de claves. El cifrado AES-256 cumple los requisitos criptográficos cuando se implementa mediante módulos debidamente validados y se aplica de forma coherente en todos los sistemas que manejan CUI.

La elección del modelo de propiedad de las claves impacta significativamente la postura de cumplimiento CMMC, especialmente cuando la CUI reside en infraestructura en la nube. Las claves de cifrado propiedad del cliente —donde solo tú posees las claves y ni siquiera tu proveedor de la nube puede acceder a ellas— establecen límites de control definitivos que satisfacen el escrutinio de los evaluadores y eliminan cualquier ambigüedad sobre el acceso a la CUI.

Kiteworks cumple con casi el 90% de los requisitos de CMMC nivel 2 desde el primer momento. Esto incluye cifrado validado por FIPS 140-3 —el estándar federal de validación actual, no el antiguo FIPS 140-2— para proteger la CUI en reposo y en tránsito. La plataforma, una Red de datos privados, asegura los datos en movimiento con cifrado TLS 1.3, el protocolo de capa de transporte más robusto disponible, en correo electrónico, uso compartido de archivos, transferencia de archivos gestionada y formularios web.

Para las comunicaciones por correo electrónico que contienen CUI, la puerta de enlace de protección de correo electrónico de Kiteworks aplica automáticamente cifrado AES-256 a los mensajes salientes, eliminando la dependencia de los usuarios finales para tomar decisiones de cifrado y asegurando protección constante en toda la cadena de suministro de defensa.

Kiteworks cuenta con una arquitectura de claves propiedad del cliente que garantiza que los contratistas de defensa mantengan la propiedad exclusiva de sus claves de cifrado, incluso cuando se implementa en infraestructura autorizada por FedRAMP. Tu proveedor de la nube no puede acceder a tu CUI porque nunca posee las claves necesarias para descifrarla, lo que proporciona evidencia clara de control de acceso a la CUI para los evaluadores de CMMC.

Las organizaciones que requieren el máximo nivel de protección de claves pueden integrar Kiteworks con módulos de seguridad de hardware (HSM) para almacenamiento de claves resistente a manipulaciones que cumple los requisitos de validación FIPS 140-3.

Para descubrir cómo Kiteworks ayuda a cumplir con CMMC 2.0 mediante claves de cifrado validadas por FIPS 140-3 y propiedad del cliente, agenda una demostración personalizada adaptada a tu entorno de contratación de defensa.