Alineación con el Marco de Ciberseguridad del NIST en la nube de AWS

Alinearte con el Marco de Ciberseguridad del NIST en la nube de AWS implica mapear sistemáticamente los servicios nativos de AWS y tus propios controles a las seis funciones de CSF 2.0, decidir cuánto control de claves conservar y recopilar la evidencia que los auditores realmente requieren. Las organizaciones que lo hacen bien reducen el riesgo de filtraciones, simplifican las auditorías regulatorias y construyen una postura de seguridad en la nube que pueden defender. El punto de partida recomendado es usar AWS Organizations y Control Tower para operacionalizar la nueva función de Gobernanza, luego mapear cada función restante a los servicios de AWS en la tabla a continuación y decidir con anticipación si la administración de claves nativa de AWS KMS, BYOK o HYOK se ajusta a tus requisitos de soberanía y cumplimiento.

Respuesta rápida: ¿Cómo se alinea AWS con el marco CSF ​​2.0 del NIST?

NIST CSF 2.0 tiene seis funciones principales: Gobernar, Identificar, Proteger, Detectar, Responder y Recuperar. En AWS, se cumplen estas funciones mediante la implementación de los servicios nativos adecuados para cada una (AWS Organizations y Control Tower para Gobernar, AWS Config y Security Hub para Identificar, AWS KMS e IAM para Proteger, GuardDuty e Inspector para Detectar, CloudWatch y Lambda para Responder, AWS Backup y CloudFormation para Recuperar), la elección de un modelo de control de claves (KMS nativo, BYOK o HYOK) que se ajuste a sus requisitos de soberanía y cumplimiento, la habilitación de CloudTrail para un registro de auditoría completo y la documentación de un perfil CSF que mapee sus controles actuales con los resultados de las subcategorías del marco. AWS proporciona las herramientas; el cliente es propietario de la configuración, las decisiones de gestión de claves y la recopilación de evidencia de cumplimiento.

¿Qué es NIST CSF 2.0 y qué cambios introdujo con respecto a la versión 1?

El Marco de Ciberseguridad (CSF) del NIST es un marco voluntario basado en riesgos, publicado por el Instituto Nacional de Estándares y Tecnología (NIST) para ayudar a las organizaciones a gestionar y reducir el riesgo de ciberseguridad. Proporciona un lenguaje común, una taxonomía de resultados y referencias cruzadas a más de 50 estándares y directrices de ciberseguridad.

El NIST CSF 2.0 se publicó oficialmente el 26 de febrero de 2024. Introduce cuatro cambios significativos con respecto al CSF 1.1:

• Se ha añadido una nueva función de gobernanza: CSF 2.0 introduce una sexta función central, Gobernar, que se sitúa en el centro del marco y aborda el contexto organizacional, la estrategia de riesgos, las funciones, las políticas y la gestión de riesgos de la cadena de suministro. Esta función refleja el reconocimiento de que la gobernanza de la ciberseguridad es una condición previa para que las otras cinco funciones operen de manera coherente.
• Alcance más amplio: El CSF 1.1 se centraba principalmente en la infraestructura crítica. El CSF 2.0 se aplica explícitamente a organizaciones de cualquier tamaño y sector, desde grandes empresas hasta pequeñas organizaciones sin ánimo de lucro y centros educativos.
• Mayor énfasis en la cadena de suministro: CSF 2.0 añade subcategorías específicas dentro de las secciones "Gobernar e identificar" para la gestión de riesgos de la cadena de suministro, lo que refleja la realidad posterior a SolarWinds en cuanto a las amenazas a la cadena de suministro de software y proveedores.
• Recursos de implementación ampliados: El NIST publicó guías de inicio rápido, perfiles de la comunidad y un catálogo de referencias informativas con función de búsqueda junto con CSF 2.0, lo que facilita su puesta en marcha en entornos específicos, incluidas las implementaciones en la nube.

El marco sigue constando de tres secciones: el Núcleo (las seis funciones y sus categorías y subcategorías de resultados), los Niveles (que describen la madurez de las prácticas de gestión de riesgos de una organización, desde Parcial hasta Adaptativa) y los Perfiles (que capturan la postura de ciberseguridad actual y objetivo de una organización para un caso de uso o entorno específico).

Explicación de las seis funciones principales del NIST CSF 2.0

Cada función representa un área de resultados de ciberseguridad de alto nivel. En un entorno de AWS, cada función está asociada a servicios específicos, y la responsabilidad del cliente varía según la función.

Govern (GV) es la nueva función de CSF 2.0. Abarca el contexto organizacional, la estrategia de riesgos, las funciones y responsabilidades, las políticas, la supervisión y la ciberseguridad de la cadena de suministro. En AWS, esto se corresponde con AWS Organizations (jerarquía de cuentas y políticas de control de servicios), AWS Control Tower (zonas de aterrizaje y medidas de seguridad automatizadas), AWS Service Catalog (carteras de servicios aprobadas y seleccionadas), AWS Audit Manager (recopilación automatizada de evidencia de cumplimiento) y sus procesos internos de gobernanza para la aprobación de políticas en la nube y la evaluación de riesgos de proveedores. El cliente es prácticamente el único responsable de Govern.

Identify (ID) abarca la gestión de activos, la evaluación de riesgos, el análisis del entorno empresarial y la identificación de riesgos en la cadena de suministro. Los servicios de AWS que admiten Identify incluyen AWS Security Hub (resultados de seguridad agregados), AWS Config (inventario de configuración y detección de desviaciones de cumplimiento), AWS Systems Manager (inventario de instancias administradas), AWS Trusted Advisor (utilización de recursos y comprobaciones de seguridad) y Amazon Inspector (evaluación automatizada de vulnerabilidades para EC2 e imágenes de contenedores).

La función Protect (PR) abarca el control de acceso, la seguridad de los datos, la seguridad de la plataforma y la resiliencia. Esta es la función que tiene la correspondencia más directa con el cifrado y la gestión de claves. Los servicios de AWS incluyen AWS IAM (gestión de identidades y accesos), AWS KMS (gestión de claves de cifrado), AWS CloudHSM (HSM dedicados con certificación FIPS 140-2 Nivel 3), AWS Certificate Manager (aprovisionamiento de certificados TLS/SSL), AWS Shield (protección contra ataques DDoS), AWS WAF (firewall de aplicaciones web), AWS Macie (detección y clasificación de datos confidenciales), Amazon VPC (segmentación de red) y AWS Direct Connect (conectividad de red privada).

Detect (DE) abarca la monitorización continua, la detección de anomalías y la detección de eventos adversos. Los servicios de AWS incluyen Amazon GuardDuty (detección inteligente de amenazas mediante aprendizaje automático), Amazon Macie (detección de exposición de datos confidenciales en S3), Amazon Inspector (análisis de vulnerabilidades), AWS Security Hub (agregación centralizada de hallazgos de seguridad) y Amazon Detective (investigación de incidentes de seguridad y análisis de la causa raíz).

Respond (RS) abarca la planificación, comunicación, análisis, mitigación y mejoras en la respuesta a incidentes. Los servicios de AWS incluyen AWS CloudWatch (monitoreo y alertas), AWS Lambda (manuales de respuesta automatizados activados por eventos de seguridad), AWS Step Functions (orquestación de respuesta a incidentes en múltiples pasos), AWS Systems Manager (manuales de operaciones y automatización), AWS CloudTrail (registro de auditoría para la investigación) y Amazon Detective (correlación de hallazgos para la definición del alcance del incidente).

Recover (RC) abarca la planificación de la recuperación, las mejoras y la comunicación. Los servicios de AWS incluyen AWS Elastic Disaster Recovery (anteriormente CloudEndure), AWS Backup (gestión y políticas de copias de seguridad centralizadas), Amazon S3 Glacier (archivo de copias de seguridad a largo plazo), AWS CloudFormation (infraestructura como código para la reconstrucción del entorno) y AWS OpsWorks (gestión de la configuración).

Servicios de AWS mapeados a las funciones principales de NIST CSF 2.0

La siguiente tabla relaciona los servicios de AWS con las funciones principales del Marco de Responsabilidad del Cliente (CSF) 2.0 del NIST. AWS publica una matriz detallada de Servicios de AWS y Responsabilidad del Cliente para la alineación con el CSF en aws.amazon.com/compliance/nist/, donde se ofrece una asignación granular de subcategorías.

#	Regir	Identifica	Proteger	Detectar	Responder	Recuperar
1	Organizaciones	Centro de seguridad	AMI	Guardia	Vigilancia de la nube	Elastic DR
2	Torre de control	Config	KMS	macie	lambda	Copia de seguridad de AWS
3	Gerente de Auditoría	Asesor de confianza	NubeHSM	Inspector	Detective	Formación de nubes
4	Catálogo de servicios	Gerente de Sistemas	Administrador de certificados	Centro de seguridad	NubeTrail	Glaciar S3
5	Configuración (políticas)	Inspector	Escudo / WAF	N/A	Funciones de paso	Instantánea / Archivo
6	N/A	Registros de flujo de VPC	Macie, Direct Connect, Firewall Manager, IAM Identity Center	N/A	Gerente de Sistemas	OpsWorks

Gestión de claves nativa de AWS frente a gestión de claves externa: requisitos de la función CSF Protect

Las subcategorías de seguridad de datos de la función NIST CSF Protect exigen que los datos estén protegidos tanto en reposo como en tránsito, que las claves de cifrado se gestionen de forma coherente con la política y que las operaciones del ciclo de vida de las claves se registren y sean auditables. El cumplimiento de estos requisitos depende del modelo de control de claves que se elija. En entornos de AWS, existen tres opciones prácticas.

Opción 1: KMS nativo de AWS (claves administradas por AWS)

AWS crea, almacena y gestiona sus claves de cifrado íntegramente en AWS KMS. El servicio utiliza módulos de seguridad de hardware (HSM) con certificación FIPS 140-2 Nivel 2. El material de clave nunca sale de AWS KMS sin cifrar. La rotación se puede configurar en automático (anual para claves simétricas). Cada operación criptográfica genera una entrada en el registro de CloudTrail.

Este modelo es adecuado para la mayoría de las cargas de trabajo de AWS. Cumple con los requisitos de protección de datos y registro del Marco de Seguridad de Datos (CSF) del NIST de forma predeterminada y con una configuración mínima. La desventaja: AWS tiene acceso técnico al material clave como parte del servicio administrado, lo que podría no cumplir con los estrictos requisitos de soberanía de datos o con ciertos sectores regulados (defensa, información clasificada, algunos servicios financieros).

Opción 2: BYOK (Trae tu propia llave)

BYOK significa que usted genera su material de clave externamente (en un HSM local o un sistema de administración de claves externo), lo importa a AWS KMS como una clave administrada por el cliente con material de clave importado, y AWS utiliza ese material importado para las operaciones de cifrado. Usted conserva el material de clave original y puede eliminar la clave importada de AWS KMS si es necesario, lo que revoca efectivamente la capacidad de AWS para descifrar los datos protegidos por esa clave.

BYOK cumple con un requisito más estricto de separación de funciones: la organización que generó la clave conserva la propiedad del material de la clave. Sin embargo, durante su uso activo en AWS, el material de la clave en texto plano es accesible para AWS KMS para operaciones de cifrado y descifrado. BYOK no se rota automáticamente a través de AWS KMS; debe gestionar el ciclo de vida de la clave externamente y reimportar el material de la clave actualizado.

Opción 3: HYOK (Mantén tu propia llave)

HYOK significa que la clave de cifrado nunca ingresa a AWS. En cambio, las operaciones de cifrado de AWS se gestionan a través de su sistema de administración de claves externo. Los servicios de AWS que admiten almacenes de claves externos (como AWS KMS XKS, External Key Store, una función lanzada en 2022) envían solicitudes de clave a su proxy de administración de claves externo, que realiza la operación criptográfica utilizando su clave, la cual permanece en su HSM local o en la nube privada, y devuelve solo el resultado a AWS.

HYOK proporciona la forma más sólida de soberanía de claves: AWS no puede acceder a su clave en texto plano bajo ninguna circunstancia, ni siquiera por obligación legal. Las desventajas son reales: cada operación de cifrado de AWS añade la latencia de una llamada externa a su sistema de gestión de claves, su infraestructura de gestión de claves debe tener alta disponibilidad y tiempos de respuesta inferiores a 50 ms para evitar afectar el rendimiento de las aplicaciones, y la complejidad operativa es significativamente mayor.

Tabla de decisiones de control de claves

Dimensión	AWS KMS nativo	BYOK (Llave importada)	HYOK (Almacén de claves externas)
Ubicación del material clave	AWS KMS HSM (FIPS 140-2 L2)	Generado externamente, almacenado en AWS KMS.	Siempre en su HSM externo
Acceso de AWS a la clave en texto plano	Sí, para operaciones criptográficas	Sí, durante el uso activo	No
Nivel de validación FIPS	140-2 Nivel 2 (KMS) o Nivel 3 (CloudHSM)	Depende de dónde lo generes	Depende de su HSM externo.
Rotación automática	Sí (anual para claves simétricas)	No, la gestión es externa.	No, se gestiona completamente de forma externa.
Registro de CloudTrail	Registro de auditoría completo de la API de KMS	Registro de auditoría completo de la API de KMS	Parcial (el proxy XKS también debe registrar)
Revocar el acceso a los datos al instante	Eliminación de claves (periodo de espera de 7 a 30 días)	Eliminar material clave importado (inmediato)	Desconectar el proxy XKS (inmediato)
Complejidad operativa	Bajo	Media	Alto
Impacto de la latencia	Minimo	Minimo	Agrega el viaje de ida y vuelta al KMS externo.
Ideal para	La mayoría de las cargas de trabajo; prioridad en costos y eficiencia operativa.	Sectores regulados que necesitan una procedencia clave fuera de AWS	Mandatos de soberanía; clasificado; control de claves de confianza cero

Modelo IAM para NIST CSF Protect: Principio de mínimo privilegio en AWS

Las subcategorías de control de acceso (PR.AA) de la función NIST CSF Protect requieren que las identidades estén autenticadas, que los permisos de acceso reflejen el principio de mínimo privilegio y que el acceso se revise periódicamente. En AWS, esto significa diseñar su modelo IAM en torno a tres principios.

Separe las políticas de claves KMS de las políticas de IAM: Una política de claves KMS es el control de acceso principal para una clave KMS. Una política de IAM por sí sola es insuficiente a menos que la política de claves también otorgue acceso al usuario principal. Esta separación proporciona una capa adicional: incluso un administrador de IAM no puede acceder a una clave KMS a menos que se le permita explícitamente en la política de claves. Estructure las políticas de claves para separar a los administradores de claves (que pueden rotar y administrar la clave) de los usuarios de claves (que pueden cifrar y descifrar). Ninguna identidad debe tener ambas capacidades.

Uso de políticas de control de servicios en AWS Organizations: Las políticas de control de servicios (SCP) aplicadas a nivel de unidad organizativa pueden impedir que cualquier entidad principal de esas cuentas utilice operaciones de administración de claves no autorizadas, cree configuraciones de claves que no cumplan con las normas o deshabilite CloudTrail. Las SCP funcionan como medidas de seguridad que AWS evalúa antes que las políticas de IAM, lo que las convierte en un mecanismo eficaz para aplicar políticas de nivel de gobernanza en todas las cuentas.

Implemente el acceso multipartito para operaciones con claves confidenciales: Para la eliminación, importación y replicación entre regiones de claves KMS confidenciales, utilice un flujo de trabajo de aprobación que requiera una segunda identidad autorizada para confirmar la operación. AWS no implementa esta restricción de forma nativa para todas las operaciones, pero puede implementarse mediante claves de condición de IAM y flujos de trabajo de aprobación en AWS Step Functions o AWS Systems Manager Automation.

Rotación de claves y registro de auditoría para el cumplimiento del marco de seguridad de datos NIST

La norma NIST SP 800-57 Parte 1, a la que el CSF hace referencia de forma informativa para la gestión de claves criptográficas, establece que los criptoperíodos (el período durante el cual una clave está autorizada para su uso) deben limitarse y que las claves deben rotarse cuando expire el criptoperíodo o cuando se sospeche una vulneración de la seguridad.

En AWS KMS, la rotación automática está disponible para las claves simétricas administradas por el cliente. Cuando está habilitada, AWS genera nuevo material criptográfico anualmente, lo marca como la versión de clave activa y conserva todas las versiones anteriores para el descifrado de datos cifrados con versiones anteriores. Esto significa que nunca es necesario volver a cifrar los datos existentes para habilitar la rotación, y el ARN y el ID de la clave permanecen constantes, por lo que no se requieren cambios en la aplicación. El evento de rotación se registra en CloudTrail con el tipo de evento RotateKey.

Para las claves importadas mediante BYOK, la rotación automática no está disponible a través de AWS KMS. Su sistema externo de gestión de claves debe gestionar el calendario de rotación y usted debe importar manualmente el nuevo material de claves. Los servicios de consultoría en protección de datos en la nube y HSM como servicio de Encryption Consulting pueden ayudarle a diseñar y automatizar este flujo de trabajo para entornos regulados.

Cada llamada a la API de KMS genera un registro de CloudTrail que incluye el ID de la clave, la identidad del emisor, los parámetros de la solicitud y el estado de la respuesta. Para las funciones de detección y respuesta de NIST CSF, los registros de CloudTrail deben enviarse a Amazon CloudWatch Logs e integrarse en su SIEM. Configure alarmas de CloudWatch para patrones anómalos: solicitudes inesperadas de eliminación de claves, picos inusuales en el volumen de cifrado, llamadas de descifrado fallidas de entidades principales no reconocidas o eventos DisableKey.

Consideraciones de costos para la gestión de claves de AWS a gran escala

El precio de AWS KMS consta de dos componentes: un cargo mensual por clave administrada por el cliente (CMK) y un cargo por llamada a la API para operaciones criptográficas. A partir de 2025, AWS KMS cobra $1 por CMK al mes y $0.03 por cada 10 000 llamadas a la API. Las claves administradas por AWS (las que tienen el prefijo aws/) no tienen cargo por clave, pero sí se cobra por las llamadas a la API.

Para cargas de trabajo con operaciones de cifrado de alto volumen (cifrado del lado del servidor S3, cifrado RDS, cifrado de volumen EBS a gran escala), el costo por llamada puede acumularse. El cifrado de sobre, donde una clave de cifrado de datos (DEK) se cifra con una clave maestra de cliente (CMK) de KMS y se almacena en caché localmente por su aplicación, reduce significativamente la cantidad de llamadas a la API de KMS y, por lo tanto, el costo. Los servicios de AWS como S3, RDS y EBS gestionan el cifrado de sobre automáticamente.

AWS CloudHSM tiene un precio por instancia de HSM por hora (aproximadamente $1.45 por hora por HSM a partir de 2025), más los costos de transferencia de datos. Se requiere un mínimo de dos HSM en zonas de disponibilidad separadas para garantizar la alta disponibilidad, lo que resulta en un costo base de aproximadamente $2,100 por mes para un clúster de dos HSM. CloudHSM es adecuado para cargas de trabajo que requieren aislamiento de HSM de nivel 3 FIPS 140-2, administración por parte del cliente de credenciales de partición u operaciones criptográficas personalizadas no compatibles con KMS.

El uso de HYOK con el Almacén de Claves Externas (XKS) de AWS KMS no reduce los costos de la API de AWS KMS, sino que incrementa el costo de infraestructura de su sistema de administración de claves externo y sus requisitos de alta disponibilidad. La sobrecarga operativa es significativa; considere el tiempo de personal necesario para administrar el proxy XKS, su clúster HSM externo y la integración con los servicios de AWS.

Consideraciones sobre arquitecturas híbridas y multinube

Las organizaciones que operan en AWS junto con otros proveedores de nube (Azure, GCP) o en entornos híbridos locales se enfrentan a un desafío específico del Marco de Ciberseguridad (CSF) del NIST: los resultados del CSF se aplican a todo el entorno, no solo a la infraestructura de AWS. Esto genera un problema de coherencia en la gestión de claves. AWS KMS es específico de AWS; Azure Key Vault es específico de Azure; GCP Cloud KMS es específico de GCP. Sin una capa de gestión de claves que abarque varias nubes, se terminan con tres inventarios de claves, tres registros de auditoría y tres políticas de rotación independientes.

Existen tres patrones para abordar este problema:

• Federación nativa de la nube con CLM unificado: Mantenga los servicios de claves nativas por nube (AWS KMS, Azure Key Vault, GCP Cloud KMS), pero implemente una plataforma unificada de gestión del ciclo de vida de certificados y claves que agregue el inventario, aplique la política de rotación y proporcione un único registro de auditoría en todos los proveedores. Esto evita la latencia y la complejidad de HYOK, al tiempo que proporciona visibilidad de la gobernanza en todo el entorno multinube.
• Gestión centralizada de claves externas con BYOK en cada nube: Utilice un único sistema externo de gestión de claves como repositorio principal y exporte el material de claves BYOK al KMS de cada proveedor de nube. Esto centraliza la generación de claves y la política de ciclo de vida, al tiempo que aprovecha las capacidades de cifrado nativas de la nube para optimizar el rendimiento.
• HYOK con un HSM externo compartido: Para cumplir con los requisitos de soberanía más exigentes, utilice un único clúster HSM externo como almacén de claves autorizado y configure la integración del almacén de claves externo de cada nube para que llame a su HSM centralizado. Esta es la opción más compleja desde el punto de vista operativo y requiere un clúster HSM externo capaz de gestionar el volumen combinado de llamadas a la API de cifrado de todos los proveedores de nube.

Los servicios de asesoramiento en protección de datos en la nube y la oferta de HSM como servicio de Encryption Consulting pueden dar soporte a cada uno de estos patrones. Para las organizaciones que desarrollan una lista de materiales criptográficos (CBOM, por sus siglas en inglés) como parte de la implementación de la función de gobernanza e identificación del Marco de Ciberseguridad del NIST (NIST CSF), CBOM Secure proporciona detección e inventario automatizados de activos criptográficos en entornos híbridos y en la nube.

Marco de Adopción de la Nube de AWS y Alineación con el Marco de Ciencia de Datos (CSF) del NIST

Antes de crear una arquitectura de seguridad alineada con el Marco de Adopción de la Nube (CAF) de AWS, utilice el Marco de Adopción de la Nube de AWS (CAF) para identificar las deficiencias de capacidad. La Perspectiva de Seguridad del CAF de AWS abarca la gestión de identidades y accesos, los controles de detección, la seguridad de la infraestructura, la protección de datos y la respuesta a incidentes, todos los cuales se corresponden directamente con las funciones del Marco de Seguridad de la Nube (CSF) del NIST.

Las capacidades fundamentales de la perspectiva de seguridad de AWS CAF y la arquitectura de referencia de seguridad de AWS (SRA) ofrecen orientación sobre cómo estructurar las cuentas de AWS (mediante AWS Organizations), qué servicios de seguridad implementar en cada tipo de cuenta (una cuenta dedicada de herramientas de seguridad para GuardDuty, Security Hub y la agregación de CloudTrail) y cómo aplicar controles básicos en toda la organización. Revisar AWS CAF y SRA antes de implementar los controles de CSF previene errores de configuración comunes y alinea la arquitectura de AWS con los patrones de seguridad recomendados por AWS.

Responsabilidad compartida del NIST CSF: Propiedad del cliente frente a propiedad de AWS

AWS opera bajo un modelo de responsabilidad compartida que divide la responsabilidad de la seguridad entre AWS y el cliente. Para cumplir con el marco de seguridad CSF del NIST, esto significa que la recopilación de pruebas debe abarcar a ambas partes.

Las responsabilidades de AWS incluyen la seguridad física del centro de datos, la aplicación de parches al hipervisor y al sistema operativo del host para los servicios gestionados, la disponibilidad y durabilidad de los servicios gestionados (S3, RDS, KMS) y la validación FIPS del hardware de AWS KMS y CloudHSM. AWS proporciona documentación de auditoría que abarca estos controles a través de AWS Artifact (informes SOC, certificaciones PCI DSS, certificaciones ISO), que los clientes pueden descargar y utilizar como referencia en sus propios paquetes de evidencia de cumplimiento.

Las responsabilidades del cliente incluyen la configuración de IAM (quién puede acceder a qué recursos de AWS y bajo qué condiciones), la configuración de claves de cifrado (qué claves KMS protegen qué datos, qué permiten las políticas de claves), los controles de red (reglas de grupos de seguridad, configuración de registros de flujo de VPC, NACL), el endurecimiento de la carga de trabajo (parches del sistema operativo en las instancias EC2 que administra, seguridad de las imágenes de contenedores), la configuración de la monitorización (qué alarmas de CloudWatch están configuradas, qué hallazgos de GuardDuty se envían a la respuesta a incidentes) y los procedimientos de clasificación y manejo de datos.

AWS publica una matriz detallada de Servicios de AWS y Responsabilidad del Cliente para la alineación con el Marco de Seguridad de la Información (CSF) en aws.amazon.com/compliance/nist/ . Esta matriz relaciona cada una de las 108 actividades de seguridad basadas en resultados del CSF con si son propiedad de AWS, del cliente o compartidas, lo que proporciona a los equipos de seguridad y cumplimiento un punto de partida para evaluar las brechas con respecto a la implementación actual de los controles.

El diagrama de referencia de la arquitectura AWS NIST CSF ilustra la asignación de las seis funciones principales de CSF 2.0 a los servicios nativos de AWS y la división entre las responsabilidades del cliente y las de AWS. La asignación completa está disponible en el documento técnico de AWS «Alineación con el Marco de Ciberseguridad NIST en la nube de AWS» (actualizado en enero de 2025) y en la matriz descargable de Servicios de AWS y Responsabilidades del Cliente en aws.amazon.com/compliance/nist/.

Cómo implementar NIST CSF 2.0 en AWS: una secuencia de inicio estructurada

Para los equipos que comienzan o actualizan su alineación con el Marco de Ciberseguridad de NIST en AWS, una secuencia de implementación estructurada reduce el retrabajo y pone de manifiesto primero las deficiencias de mayor riesgo.

1. Establecer la fundación Govern: Configure AWS Organizations con una jerarquía de cuentas definida. Implemente AWS Control Tower para automatizar las medidas de seguridad básicas. Defina su perfil CSF para este entorno de AWS documentando qué subcategorías de CSF están incluidas, cuál es su estado actual y cuál es su estado objetivo. Asigne la propiedad de cada función a personas o equipos específicos.
2. Complete el inventario de activos y criptográficos (Identificar): Utilice AWS Config, Systems Manager y Security Hub para inventariar todos los recursos de AWS. CBOM seguro Descubrir y clasificar todos los activos criptográficos, incluidas las claves KMS, los certificados, las claves SSH y los secretos. Este inventario inicial sirve como base para la evaluación de riesgos y el estado actual del perfil NIST CSF.
3. Elija su modelo de control de claves (Protect): En función de sus requisitos normativos, la confidencialidad de los datos y la capacidad operativa, decida entre AWS KMS nativo, BYOK o HYOK para cada nivel de clasificación de datos. Documente esta decisión en su política de gestión de claves, que forma parte de los requisitos de política de la función CSF Govern.
4. Configurar controles de acceso (Proteger): Diseñe e implemente políticas de claves KMS, políticas IAM y SCP que implementen el acceso con privilegios mínimos. Aplique la autenticación multifactor (MFA) para operaciones de consola sensibles y acciones de administración de claves. Configure IAM Identity Center (anteriormente AWS SSO) para el acceso federado con su proveedor de identidad corporativa.
5. Habilitar la monitorización y detección (Detectar): Habilite AWS CloudTrail en todas las regiones con validación de archivos de registro y entrega a una cuenta dedicada de Security Tooling. Habilite GuardDuty en todas las cuentas y agregue los hallazgos en Security Hub. Configure alarmas de CloudWatch para anomalías de administración de claves. Habilite los registros de flujo de VPC para visibilidad a nivel de red.
6. Crear manuales de respuesta (Responder): Documente y automatice la respuesta a incidentes detectados por sus herramientas. Cree respuestas automatizadas basadas en Lambda o Step Functions para los hallazgos de GuardDuty con alta fiabilidad. Documente las rutas de escalamiento, las plantillas de comunicación y los requisitos de notificación externa (plazos de notificación de brechas, informes regulatorios).
7. Probar y validar la recuperación (Recuperar): Pruebe los procedimientos de restauración de AWS Backup, documente los objetivos de tiempo de recuperación (RTO) y los objetivos de punto de recuperación (RPO) para cada carga de trabajo crítica y confirme que los procedimientos de recuperación restablecen los servicios a la postura de seguridad previa al incidente, no solo a la disponibilidad operativa.
8. Evaluar según el perfil CSF y repetir: Compare los controles implementados con su perfil CSF objetivo. Documente la evidencia para cada subcategoría. Utilice AWS Audit Manager para automatizar la recopilación de evidencia para las subcategorías controlables por AWS. Identifique las brechas restantes y priorice la remediación según el impacto en el riesgo.

Cómo puede ayudar la consultoría de cifrado

Encryption Consulting es una empresa de criptografía aplicada y ciberseguridad con certificaciones ISO/IEC 27001:2022 y SOC 2. Ayudamos a las organizaciones a diseñar, evaluar y operar programas de cifrado y gestión de claves que cumplen con los requisitos de cumplimiento de NIST CSF, NIST SP 800-53, CMMC, FedRAMP, PCI DSS, HIPAA y otros en entornos AWS y multinube.

• Asesoramiento sobre protección de datos en la nube y gestión de claves: Evaluamos su modelo actual de control de claves de AWS, identificamos las brechas con respecto a los requisitos de NIST CSF Protect y diseñamos la arquitectura de gestión de claves adecuada para su entorno regulatorio y tolerancia al riesgo. Ya sea que necesite optimización nativa de KMS, automatización de importación de claves BYOK o diseño HYOK con AWS KMS XKS, creamos la arquitectura y la documentación de evidencia. Consulte nuestra servicios de asesoramiento.
• HSM como servicio: Para cargas de trabajo que requieren almacenamiento de claves HSM FIPS 140-2 Nivel 3 fuera de AWS KMS, Encryption Consulting HSM como servicio Proporciona una infraestructura HSM dedicada con operaciones gestionadas, facilitación de ceremonias de claves e integración con AWS CloudHSM y sistemas de gestión de claves de terceros.
• CBOM Seguro para Inventario Criptográfico: Las funciones de Gobernar e Identificar del NIST CSF 2.0 requieren saber qué activos criptográficos se poseen y dónde se encuentran. CBOM seguro Automatiza el descubrimiento y la clasificación de claves de cifrado, certificados, claves SSH, secretos y el uso de algoritmos criptográficos en todo su entorno AWS, y genera una lista de materiales criptográficos (CBOM) en formato CycloneDX para la elaboración de informes de cumplimiento.
• Aviso de cumplimiento (NIST CSF, CMMC, FedRAMP): Facilitamos talleres sobre el perfil CSF del NIST, mapeamos sus controles actuales de AWS a las subcategorías de CSF, identificamos brechas y creamos la hoja de ruta de remediación y el paquete de evidencia para su auditoría. Servicios de asesoramiento sobre cumplimiento Cubre los requisitos de NIST CSF 2.0, NIST SP 800-53 Rev. 5, CMMC Nivel 2 y Nivel 3, y FedRAMP.
• Preparación de PQC en AWS: El NIST finalizó los estándares de criptografía post-cuántica FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA) en agosto de 2024, y el NIST IR 8547 apunta a la descontinuación de RSA y ECC alrededor de 2030. Preparación para PQC Este servicio evalúa su postura criptográfica en AWS en función del cronograma de migración post-cuántica y diseña el plan de transición de algoritmos para sus configuraciones de claves KMS, perfiles de certificados y configuraciones TLS.

Para hablar sobre sus requisitos de alineación con el Marco de Ciberseguridad NIST (NIST CSF) en AWS, póngase en contacto con Encryption Consulting.

Conclusión

NIST CSF 2.0 representa una importante evolución del marco. La incorporación de la función de Gobernanza sitúa la responsabilidad organizacional y el riesgo de la cadena de suministro en el centro de la práctica de la ciberseguridad, en lugar de considerarlos aspectos secundarios. Para los entornos de AWS, esto significa que el trabajo de cumplimiento comienza antes de configurar un solo servicio de seguridad: es necesario definir la jerarquía de cuentas, asignar la propiedad y documentar la estrategia de riesgos antes de asignar los servicios a las cinco funciones restantes.

La decisión clave sobre el control, específicamente si usar AWS KMS nativo, BYOK o HYOK, es la elección técnica más importante para la función Protect. Afecta su capacidad para revocar el acceso instantáneamente, su complejidad operativa, sus registros de auditoría y su costo. Tome esta decisión con criterio, basándose en sus requisitos regulatorios reales y su capacidad operativa, y no partiendo de la premisa de que un mayor control siempre es mejor.

AWS ofrece un conjunto completo de servicios que se corresponden con todas las funciones de CSF 2.0. La tarea del cliente consiste en configurarlos correctamente, conectarlos a un flujo de trabajo de monitorización y respuesta coherente, y mantener el registro de evidencia que demuestre que los controles funcionan eficazmente a lo largo del tiempo. Este registro de evidencia, junto con el perfil CSF que usted documenta y mantiene, es lo que convierte una buena arquitectura de seguridad de AWS en una postura de cumplimiento sólida y preparada para auditorías.

Preguntas frecuentes

¿Qué es NIST CSF 2.0 y en qué se diferencia de CSF 1.0?

El Marco de Ciberseguridad 2.0 del NIST se publicó el 26 de febrero de 2024. Añade una sexta función principal, denominada Gobernar, a las cinco originales (Identificar, Proteger, Detectar, Responder y Recuperar), amplía su alcance de la infraestructura crítica a todas las organizaciones, refuerza la gestión de riesgos de la cadena de suministro e introduce guías de implementación complementarias y recursos de inicio rápido. La función Gobernar aborda el contexto organizacional, la estrategia de riesgos, las funciones, las políticas y la supervisión de la cadena de suministro.

¿Cuál es la diferencia entre BYOK y HYOK en AWS?

BYOK (Bring Your Own Key) implica generar la clave externamente e importarla a AWS KMS. AWS utiliza esa clave para las operaciones de cifrado, por lo que tiene acceso a ella durante su uso. HYOK (Hold Your Own Key) implica que la clave nunca ingresa a AWS; las operaciones de cifrado se gestionan a través de su HSM externo mediante el Almacén de Claves Externas (XKS) de AWS KMS. En HYOK, AWS nunca accede a la clave en texto plano, lo que proporciona la máxima seguridad de clave, aunque con una mayor complejidad operativa y una latencia adicional.

¿Qué servicios de AWS son compatibles con la función de gobernanza del marco CSF ​​2.0 de NIST?

AWS Organizations (jerarquía de cuentas y políticas de control de servicios), AWS Control Tower (barreras de seguridad y zonas de aterrizaje automatizadas), AWS Service Catalog (carteras de servicios aprobadas), AWS Config (reglas de cumplimiento de políticas como código) y AWS Audit Manager (recopilación automatizada de evidencia de cumplimiento) son los servicios principales que respaldan la función de gobernanza. El cliente conserva la propiedad total de los resultados de la gobernanza; AWS proporciona las herramientas para operacionalizarla a gran escala.

¿Cómo cumple AWS KMS con los requisitos de gestión de claves del marco NIST CSF?

AWS KMS proporciona almacenamiento de claves con respaldo HSM validado según FIPS 140-2 Nivel 2, rotación anual automática para claves simétricas administradas por el cliente, políticas de claves granulares y control de acceso basado en IAM, e integración con CloudTrail que registra cada operación criptográfica. Para los requisitos de FIPS 140-2 Nivel 3, AWS CloudHSM proporciona hardware HSM dedicado de un solo inquilino. Ambos servicios cumplen con las subcategorías de seguridad de datos y administración de claves de la función Protect del NIST CSF.

¿Cuál es el modelo de responsabilidad compartida para el cumplimiento del marco CSF ​​de NIST en AWS?

AWS garantiza la seguridad de la infraestructura física, el hipervisor y la disponibilidad de los servicios gestionados (seguridad en la nube). Los clientes son responsables de la configuración de IAM, la gestión de claves de cifrado, los controles de red, el endurecimiento de la carga de trabajo, la configuración de la monitorización, la clasificación de datos y la respuesta a incidentes (seguridad en la nube). AWS proporciona artefactos de auditoría a través de AWS Artifact; los clientes deben recopilar de forma independiente la evidencia correspondiente a su parte de los controles. La matriz de Responsabilidad del Cliente y Servicios de AWS para CSF, disponible en aws.amazon.com/compliance/nist/, detalla la responsabilidad de las 108 actividades basadas en resultados de CSF.

¿Cómo debo rotar las claves de cifrado en AWS para cumplir con los requisitos del Marco de Cifrado Científico (CSF) de NIST?

Habilite la rotación automática para las claves simétricas gestionadas por el cliente de AWS KMS. Esto rota el material de clave anualmente, conservando el ARN de la clave y todos los permisos existentes, cumpliendo con la guía de rotación NIST SP 800-57 sin necesidad de volver a cifrar los datos. Para las claves importadas con BYOK, gestione la rotación externamente y vuelva a importar el material de clave actualizado. Supervise los eventos de rotación en CloudTrail bajo el tipo de evento RotateKey y reciba alertas en caso de fallos en la rotación.

Referencias

1. Marco de Ciberseguridad 2.0 del NIST. Instituto Nacional de Estándares y Tecnología. Publicado el 26 de febrero de 2024. https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
2. Adaptación al Marco de Ciberseguridad del NIST en la nube de AWS (actualizado para CSF 2.0). Amazon Web Services. Enero de 2025. https://d1.awsstatic.com/whitepapers/compliance/NIST_Cybersecurity_Framework_CSF.pdf
3. Matriz de responsabilidad del cliente y de los servicios de AWS para la alineación con el Marco de Responsabilidad del Cliente (CSF). Amazon Web Services. https://aws.amazon.com/compliance/nist/
4. NIST SP 800-53 Rev. 5, Controles de seguridad y privacidad para sistemas y organizaciones de información. NIST. https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
5. NIST SP 800-57 Parte 1 Rev. 5, Recomendación para la gestión de claves. NIST. https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final
6. NIST IR 8547, Transición a los estándares de criptografía post-cuántica. NIST. https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf
7. ISO/IEC 27001:2022, Sistemas de gestión de la seguridad de la información. ISO. https://www.iso.org/standard/27001