Guía

Una instancia EC2 potencialmente comprometida en un grupo de Auto Scaling requiere investigación con una interrupción mínima.

→Anular el registro del grupo objetivo de ELB, eliminar del grupo de Auto Scaling y aplicar un grupo de seguridad "forense" restrictivo que deniegue todo el tráfico excepto el acceso de la estación de trabajo forense.

Por qué: Esto aísla la instancia de la red mientras preserva su estado volátil (memoria, procesos en ejecución) para el análisis forense. La terminación inmediata destruye la evidencia.

Automatizar un flujo de trabajo de respuesta a incidentes de varios pasos (p. ej., instantánea, aislamiento, notificación) activado por un hallazgo de GuardDuty.

→Utilice una regla de EventBridge para capturar el hallazgo específico y activar una máquina de estados de AWS Step Functions. La máquina de estados orquesta la secuencia de acciones con manejo de errores y lógica de reintentos.

Por qué: Step Functions proporciona una orquestación robusta para flujos de trabajo de varios pasos, asegurando fiabilidad y gestión de estados, lo cual es superior a una única función Lambda monolítica.

Detectar amenazas en tiempo de ejecución (p. ej., criptominería, escalada de privilegios) dentro de contenedores ECS Fargate o EC2 en ejecución sin implementar agentes sidecar.

→Habilitar el monitoreo de tiempo de ejecución de Amazon GuardDuty ECS. Para EC2, implemente el agente de seguridad de GuardDuty como un DaemonSet. Para Fargate, utilice la configuración automática del agente.

Por qué: Esto proporciona detección de amenazas en tiempo de ejecución sin agente (para Fargate) o gestionada centralmente (para EC2), capturando el comportamiento dentro del contenedor sin modificar las tareas de la aplicación.

Referencia↗

Remediar automáticamente un hallazgo específico de AWS Security Hub, como un bucket de S3 accesible públicamente.

→Cree una regla de EventBridge que coincida con el tipo de hallazgo específico (p. ej., `S3.1`) y active una función Lambda o un documento de automatización de SSM para realizar la remediación.

Por qué: Este es el patrón nativo, basado en eventos, para la respuesta automatizada de Security Hub, proporcionando una remediación dirigida y casi en tiempo real.

Una clave de acceso de IAM ha sido expuesta públicamente. Contenga el incidente y evalúe el radio de explosión.

→1. Desactive la clave de acceso expuesta. 2. Adjunte una política en línea de denegación total al usuario/rol para invalidar las sesiones STS activas. 3. Revise los registros de CloudTrail para todas las llamadas a la API realizadas con la clave. 4. Erradique cualquier recurso no autorizado o principales de IAM creados por el atacante.

Por qué: La desactivación de la clave detiene su uso futuro. La política de denegación total es fundamental para revocar las sesiones activas creadas *antes* de que la clave fuera desactivada. CloudTrail proporciona el registro de auditoría para la evaluación de daños.

Mejorar la detección de amenazas de GuardDuty con fuentes de inteligencia de amenazas específicas de la empresa o de la industria.

→Cargue un archivo de texto plano de direcciones IP/CIDRs maliciosas en S3. Cree y active un nuevo conjunto de inteligencia de amenazas en GuardDuty, apuntando al archivo de S3.

Por qué: Esto le permite aumentar la inteligencia de amenazas gestionada de GuardDuty con IOCs personalizados, generando hallazgos cuando sus recursos se comunican con estas IPs especificadas.

Identifique instancias EC2 con rutas de red abiertas a Internet en puertos específicos, considerando todas las configuraciones de red.

→Habilite Amazon Inspector y revise sus hallazgos de accesibilidad de red.

Por qué: Inspector realiza un análisis completo de la ruta de red desde los IGW hasta las instancias, evaluando grupos de seguridad, NACLs y tablas de enrutamiento para determinar la accesibilidad real. Esto es más preciso que simplemente verificar reglas individuales de grupos de seguridad.

Investigar el alcance completo de un hallazgo de seguridad, visualizando todas las entidades relacionadas y el comportamiento histórico.

→Utilice Amazon Detective. Navegue al perfil de la entidad (p. ej., para una instancia EC2 o un rol de IAM) para ver el gráfico de comportamiento y la línea de tiempo de las llamadas a la API relacionadas, las conexiones de red y los hallazgos de GuardDuty.

Por qué: Detective correlaciona automáticamente los registros de CloudTrail, los registros de flujo de VPC y GuardDuty, proporcionando un análisis contextual que acelera significativamente la investigación de la causa raíz en comparación con la correlación manual de registros.

Almacenar registros de auditoría (p. ej., CloudTrail, VPC Flow Logs) para retención a largo plazo de manera inalterable y consultable para cumplir con la normativa.

→Entregue los registros a un bucket de S3 con S3 Object Lock en modo de cumplimiento habilitado. Utilice Amazon Athena para las consultas.

Por qué: Object Lock en modo de cumplimiento evita la eliminación o modificación por parte de cualquier persona, incluido el usuario root, garantizando la inmutabilidad del registro. Athena proporciona capacidades de consulta SQL ad-hoc en los registros almacenados.

Referencia↗

Recopilar centralmente todos los eventos de gestión y datos de una AWS Organization completa.

→En la cuenta de administración, cree un CloudTrail Organization Trail. Para capturar datos a nivel de objeto, utilice selectores de eventos avanzados para registrar tipos de eventos específicos (p. ej., S3 PutObject, Lambda Invoke) para recursos de alto valor.

Por qué: Una trail de organización registra automáticamente eventos para todas las cuentas miembro. Los selectores de eventos avanzados son críticos para registrar de forma rentable eventos de datos de alto volumen al dirigirse solo a los recursos necesarios.

Realizar análisis complejos basados en SQL sobre eventos de CloudTrail de toda la organización durante varios años.

→Habilite AWS CloudTrail Lake y cree un almacén de datos de eventos a nivel de organización con el período de retención requerido (hasta 7 años). Utilice el editor de consultas SQL incorporado para el análisis.

Por qué: CloudTrail Lake proporciona un almacén de datos gestionado e inmutable y un motor de consultas diseñado específicamente para eventos de CloudTrail, eliminando la necesidad de gestionar S3, Glue y Athena para el análisis de registros.

Monitorear todas las consultas DNS realizadas por los recursos dentro de una VPC para la búsqueda de amenazas o la resolución de problemas.

→Habilite el registro de consultas DNS de Route 53 Resolver y configúrelo para enviar registros a CloudWatch Logs, S3 o Kinesis Data Firehose.

Por qué: Esto proporciona visibilidad detallada de la actividad de resolución de DNS dentro de sus VPC, capturando el dominio consultado, la instancia de origen y la respuesta, lo cual es crucial para detectar amenazas basadas en DNS.

Centralizar y normalizar los registros de seguridad de varias fuentes de AWS y de terceros en un data lake utilizando un esquema estándar.

→Implemente Amazon Security Lake. Recopila y normaliza automáticamente los datos en el Open Cybersecurity Schema Framework (OCSF) y los almacena en formato Parquet en S3.

Por qué: Security Lake automatiza la creación y gestión de un data lake de seguridad, reduciendo la sobrecarga operativa de construir pipelines ETL personalizados para la normalización.

Automatizar la recopilación de pruebas para auditorías de cumplimiento contra marcos como SOC 2, PCI DSS o HIPAA.

→Utilice AWS Audit Manager. Seleccione un marco predefinido, que recopila automáticamente pruebas de los servicios de AWS (CloudTrail, Config, Security Hub) y las asigna a controles de cumplimiento específicos.

Por qué: Audit Manager automatiza y centraliza el proceso de recopilación de pruebas, reduciendo significativamente el esfuerzo manual requerido para prepararse y realizar auditorías de cumplimiento.

Descubrir y clasificar automáticamente datos sensibles (PII, PHI, financieros) en todos los buckets de S3.

→Habilite Amazon Macie y configure trabajos automatizados de descubrimiento de datos sensibles. Utilice identificadores de datos gestionados para tipos de datos comunes y cree identificadores de datos personalizados para formatos propietarios.

Por qué: Macie proporciona una solución gestionada y escalable para la clasificación de datos de S3. Para suprimir hallazgos de datos no sensibles conocidos (p. ej., datos de prueba), utilice las listas de permitidos de Macie.

Aplicar múltiples controles de seguridad en un bucket de S3, como requerir SSE-KMS con una clave específica y denegar solicitudes HTTP.

→Utilice una política de bucket con múltiples declaraciones `Deny` y claves de condición: `aws:SecureTransport: false`, `s3:x-amz-server-side-encryption: "aws:kms"`, y `s3:x-amz-server-side-encryption-aws-kms-key-id: "key-arn"`.

Por qué: Las políticas de bucket proporcionan un control granular a nivel de recurso. El uso de múltiples claves de condición en las declaraciones Deny es la forma estándar de aplicar una postura de seguridad en capas en un bucket.

Asegúrese de que todos los nuevos volúmenes EBS estén cifrados con una clave KMS gestionada por el cliente específica, en toda la organización.

→Habilite el cifrado de EBS por defecto en la configuración de la cuenta para cada Región, especificando la CMK. Aplique una SCP que deniegue `ec2:CreateVolume` si el parámetro `encrypted` es `false` como barrera preventiva.

Por qué: La configuración predeterminada proporciona conveniencia, mientras que la SCP proporciona una barrera de aplicación dura, creando un enfoque de defensa en profundidad para el cifrado de datos en reposo para EBS.

Cifrar objetos de datos grandes (> 4KB) utilizando AWS KMS.

→Utilice el cifrado de sobre. Llame a `KMS:GenerateDataKey` para obtener una clave de datos en texto claro y una clave de datos cifrada. Utilice la clave en texto claro para cifrar el objeto grande localmente. Almacene el objeto cifrado y la clave de datos cifrada juntos. Descarte la clave en texto claro.

Por qué: La API de cifrado de KMS tiene un límite de 4KB. El cifrado de sobre permite cifrar datos de cualquier tamaño mientras la pequeña clave de datos está protegida por KMS, lo que reduce el costo y la latencia en comparación con la transmisión de datos a través de KMS.

Referencia↗

Utilizar la misma clave de cifrado en varias regiones de AWS para la recuperación ante desastres o la coherencia de aplicaciones globales.

→Cree una clave principal de KMS multirregional en una región y cree claves de réplica en otras regiones. Los datos cifrados con una clave en una región se pueden descifrar con la réplica en otra.

Por qué: Las claves multirregionales comparten el mismo material de clave e ID de clave, lo que permite la portabilidad de datos entre regiones sin llamadas a la API entre regiones para el descifrado.

Almacenar de forma segura y rotar automáticamente las credenciales (p. ej., contraseñas de bases de datos, claves de API) utilizadas por las aplicaciones.

→Almacene las credenciales en AWS Secrets Manager. Configure la rotación automática utilizando una función de rotación Lambda personalizada o proporcionada por AWS. Las aplicaciones recuperan los secretos en tiempo de ejecución a través de un rol de IAM.

Por qué: Secrets Manager es un servicio diseñado específicamente para todo el ciclo de vida de los secretos, incluido el almacenamiento seguro, el control de acceso, la auditoría y la rotación automatizada, lo que reduce el riesgo de credenciales codificadas o obsoletas.

Administrar certificados TLS públicos para sitios web y certificados privados para la comunicación interna de microservicios (mTLS).

→Utilice AWS Certificate Manager (ACM) para certificados públicos gratuitos integrados con ELB/CloudFront. Cree una autoridad de certificación privada utilizando ACM Private CA para emitir y administrar certificados privados para servicios internos.

Por qué: Esto separa la PKI pública y privada, utilizando la herramienta adecuada para cada caso de uso. ACM gestiona el ciclo de vida del certificado público, mientras que ACM Private CA proporciona una jerarquía PKI privada completamente gestionada.

Almacenar datos inmutablemente durante un período de retención fijo, donde ni siquiera el usuario root puede eliminarlos.

→Habilite S3 Object Lock en el bucket. Coloque objetos bajo un período de retención con el Modo de Cumplimiento.

Por qué: El Modo de Cumplimiento es el control WORM (Write-Once-Read-Many) más fuerte, evitando la eliminación por parte de cualquier usuario. El Modo de Gobernanza puede ser eludido por principales autorizados.

Proteger las copias de seguridad de la eliminación (p. ej., debido a ransomware o credenciales comprometidas) durante un período de retención obligatorio.

→Habilite AWS Backup Vault Lock en modo de cumplimiento con un período de retención mínimo.

Por qué: Vault Lock en Modo de Cumplimiento hace que el almacén de copias de seguridad cumpla con WORM, evitando que cualquier usuario, incluido el root, elimine puntos de recuperación antes de que expire el período de retención.

Procesar datos altamente sensibles donde los datos nunca deben exponerse al SO, al hipervisor o a los operadores de AWS.

→Utilice AWS Nitro Enclaves para crear un entorno de computación criptográficamente aislado. Utilice la atestación de KMS para garantizar que solo los enclaves verificados puedan descifrar datos.

Por qué: Nitro Enclaves proporciona el nivel más fuerte de protección de datos en uso en AWS, utilizando la atestación a nivel de hardware para crear un entorno de ejecución confiable.

Utilizar servicios de AWS con claves de cifrado que se almacenan y gestionan físicamente en un HSM local, fuera de AWS.

→Configure un KMS External Key Store (XKS) que actúa como proxy para las operaciones criptográficas de KMS a un gestor de claves externo.

Por qué: XKS permite a los clientes mantener el control de su material de clave fuera de AWS para cumplir con los requisitos de soberanía o cumplimiento, mientras se sigue integrando con los servicios de AWS compatibles con KMS.

Aplicar una política estricta de "no buckets de S3 públicos" en toda una organización con controles preventivos y de detección.

→Habilite el bloqueo de acceso público de S3 a nivel de organización desde la cuenta de administración. Complemente con una SCP que deniegue acciones como `s3:PutBucketPolicy` si la política permite el acceso público. Utilice AWS Config para detectar desviaciones.

Por qué: Este enfoque en capas proporciona un bloqueo predeterminado (configuración de la organización), una barrera preventiva que detiene las configuraciones erróneas (SCP) y un control de detección para el monitoreo continuo (Config).

Inspeccionar todo el tráfico entre VPC e Internet utilizando un dispositivo de seguridad centralizado (p. ej., AWS Network Firewall).

→Cree una VPC de inspección dedicada. Utilice un Transit Gateway para conectar todas las VPC. Configure las tablas de enrutamiento de TGW para enviar todo el tráfico a través de la VPC de inspección. Habilite el modo de dispositivo en la adjunta de TGW para enrutamiento simétrico.

Por qué: Este es el modelo estándar de hub-and-spoke para la inspección de tráfico centralizada, proporcionando escalabilidad y aplicación consistente de políticas sin mallas complejas de emparejamiento de VPC.

Proteger una aplicación web (en CloudFront/ALB) contra los 10 principales riesgos de OWASP, bots y ataques de toma de control de cuentas.

→Adjunte AWS WAF con AWS Managed Rules (p. ej., `AWSManagedRulesCommonRuleSet`), el grupo de reglas gestionadas de Bot Control y el grupo de reglas gestionadas de Account Takeover Prevention (ATP).

Por qué: Este enfoque por capas utiliza múltiples grupos de reglas gestionadas para una protección amplia (Common), detección automatizada de tráfico (Bot Control) y seguridad especializada de puntos de entrada de inicio de sesión (ATP).

Proporcionar acceso seguro y privado a un servicio API SaaS desde las VPC de los clientes sin exponer el servicio a Internet.

→Cree un servicio de punto de conexión de AWS PrivateLink respaldado por un Network Load Balancer (NLB). Los clientes crean puntos de conexión de VPC de interfaz en sus VPC para acceder al servicio.

Por qué: PrivateLink mantiene el tráfico en la red privada de AWS, evitando la Internet pública y eliminando la necesidad de emparejamientos de VPC complejos, VPN o listas blancas de IP. Es el patrón estándar y escalable para la conectividad SaaS privada.

Restringir el acceso al bucket de S3 para que el contenido solo sea accesible a través de una distribución de CloudFront.

→Utilice CloudFront Origin Access Control (OAC). Actualice la política del bucket de S3 para permitir el acceso solo desde el principal de servicio de la distribución de CloudFront, condicionado al ARN de distribución específico.

Por qué: OAC es el método recomendado actual, superior al Origin Access Identity (OAI) heredado. Admite todas las características de S3, incluido SSE-KMS, y sigue las mejores prácticas de seguridad.

Proporcionar acceso de shell seguro y auditable a instancias EC2 en subredes privadas sin abrir puertos SSH/RDP ni gestionar hosts bastión.

→Instale el agente SSM en las instancias EC2. Utilice AWS Systems Manager Session Manager para el acceso. Las políticas de IAM controlan quién puede iniciar sesiones. La actividad de la sesión se puede registrar en CloudWatch Logs y S3.

Por qué: Session Manager proporciona acceso seguro, basado en navegador o CLI, a través de un túnel cifrado, eliminando la necesidad de puertos de entrada, hosts bastión y claves SSH, al tiempo que proporciona auditabilidad completa.

Implementar filtrado a nivel de DNS para evitar que los recursos de la VPC resuelvan dominios maliciosos conocidos.

→Configure Route 53 Resolver DNS Firewall con listas de dominios gestionadas (para malware, C2) y listas de bloqueo personalizadas. Asocie el grupo de reglas del firewall con las VPC.

Por qué: Esto proporciona un servicio de filtrado de DNS centralizado y gestionado a nivel de VPC, bloqueando la actividad maliciosa en el punto más temprano (resolución de DNS) sin requerir agentes basados en host.

Implementar controles de red de mínimo privilegio para una aplicación web de tres niveles.

→Cree grupos de seguridad separados para cada nivel. El SG de ALB permite la entrada 443 desde `0.0.0.0/0`. El SG de aplicación permite el tráfico de entrada solo desde el SG de ALB. El SG de DB permite el tráfico de entrada solo desde el SG de aplicación en el puerto de la base de datos.

Por qué: El uso de referencias de grupos de seguridad como fuentes proporciona microsegmentación dinámica e independiente de la IP, asegurando que cada nivel solo pueda ser accedido por su nivel adyacente y autorizado.

Otorgar permisos de AWS detallados a nivel de pod a aplicaciones que se ejecutan en EKS, evitando el uso de roles de IAM de nodo compartidos.

→Habilite IAM Roles para Service Accounts (IRSA) en el clúster de EKS. Cree un rol de IAM con permisos específicos para la aplicación. Anote la cuenta de servicio de Kubernetes de la aplicación con el ARN del rol de IAM.

Por qué: IRSA proporciona credenciales temporales directamente a los pods basándose en su cuenta de servicio, implementando el mínimo privilegio a nivel de pod y eliminando el riesgo de seguridad de roles de nodo excesivamente permisivos.

Proporcionar acceso sin VPN a aplicaciones web internas basado en la identidad del usuario y la postura de seguridad del dispositivo.

→Implemente AWS Verified Access. Integre con el IdP corporativo como proveedor de confianza de usuario y una solución de gestión de dispositivos como proveedor de confianza de dispositivo. Cree políticas de acceso por aplicación.

Por qué: Verified Access está diseñado específicamente para el acceso de confianza cero, evaluando cada solicitud frente a políticas que consideran tanto el contexto del usuario como el del dispositivo, eliminando la dependencia de la seguridad del perímetro de la red.

Permitir a los desarrolladores crear roles de IAM, pero evitar que creen roles que puedan escalar sus propios privilegios.

→Cree una política de límite de permisos que defina los permisos máximos permitidos. En la política de IAM de los desarrolladores, condicione el permiso `iam:CreateRole` para que requiera adjuntar este límite específico a través de la clave de condición `iam:PermissionsBoundary`.

Por qué: Los límites de permisos establecen los permisos máximos que puede tener una entidad de IAM. Esto evita la escalada de privilegios al garantizar que cualquier rol que cree un desarrollador esté limitado por el límite, independientemente de la política de identidad que adjunte.

Referencia↗

Evitar que cualquier usuario de cualquier cuenta miembro (incluidos los administradores) realice acciones de alto riesgo, como deshabilitar CloudTrail o eliminar un bucket de S3 común.

→Aplique una Política de Control de Servicio (SCP) a la raíz o a la OU relevante que tenga una declaración de `Deny` para las acciones restringidas (p. ej., `cloudtrail:StopLogging`, `s3:DeleteBucket`).

Por qué: Las SCP son la última barrera en AWS Organizations. Establecen los permisos máximos para todos los principales en una cuenta, y un Denegar explícito en una SCP no puede ser anulado por ninguna política de IAM dentro de la cuenta.

Proporcionar acceso seguro y auditable entre cuentas para una aplicación o usuario.

→En la cuenta de destino, cree un rol de IAM con una política de confianza que especifique el ARN principal de la cuenta de origen. En la cuenta de origen, otorgue al principal el permiso `sts:AssumeRole` en el rol de destino. La aplicación utiliza STS AssumeRole para obtener credenciales temporales.

Por qué: Este es el patrón estándar para el acceso entre cuentas. Utiliza credenciales temporales de corta duración y es completamente auditable en ambas cuentas a través de CloudTrail.

Integrar IAM Identity Center con un IdP externo (p. ej., Okta, Azure AD) y automatizar el aprovisionamiento de usuarios/grupos.

→Configure el IdP externo como fuente de identidad en IAM Identity Center. Habilite el aprovisionamiento automático a través de SCIM para sincronizar usuarios y grupos. Asigne conjuntos de permisos a los grupos sincronizados.

Por qué: SCIM (System for Cross-domain Identity Management) proporciona una sincronización automatizada y casi en tiempo real de identidades, eliminando la gestión manual de usuarios y asegurando que el acceso a AWS sea impulsado por el IdP.

Conceder acceso a recursos (p. ej., EC2) basado en etiquetas, donde los principales solo pueden administrar recursos etiquetados con el nombre de su propio equipo/departamento.

→Etiquete tanto a los principales de IAM (usuarios/roles) como a los recursos (instancias EC2) con una clave común (p. ej., `Team`). Cree una única política de IAM que permita acciones con una condición que compare `aws:PrincipalTag/Team` con `aws:ResourceTag/Team`.

Por qué: El Control de Acceso Basado en Atributos (ABAC) proporciona un modelo de permisos escalable que no requiere actualizaciones de políticas cuando se añaden nuevos recursos o equipos. Los permisos se determinan dinámicamente en función de las etiquetas.

Un principal en la Cuenta B necesita leer un objeto S3 en la Cuenta A que está cifrado con una clave KMS también en la Cuenta A.

→Se requieren tres permisos: 1) La política de bucket de S3 en la Cuenta A debe permitir al principal de la Cuenta B. 2) La política de clave KMS en la Cuenta A debe permitir al principal de la Cuenta B para `kms:Decrypt`. 3) El principal en la Cuenta B necesita una política de IAM que permita `s3:GetObject` y `kms:Decrypt`.

Por qué: El acceso a datos cifrados con KMS requiere permisos tanto del servicio de datos (S3) como del servicio de cifrado (KMS). La política de clave KMS es una política de recursos y es fundamental para otorgar acceso entre cuentas.

Comprender el resultado final del permiso cuando se aplican múltiples políticas (IAM, Recurso, SCP, Límite).

→La lógica de evaluación es: Una denegación explícita en cualquier política siempre anula cualquier permiso. Si no existe una denegación, un permiso explícito en cualquier política aplicable otorga acceso. Los permisos efectivos son la intersección de todas las políticas aplicables.

Por qué: Este es un concepto fundamental de IAM. Una denegación explícita es la declaración más poderosa y sirve como un "no" rotundo. Comprender esto es clave para solucionar problemas de acceso.

Evitar que un usuario o rol de IAM pase un rol altamente privilegiado a un servicio de AWS (p. ej., EC2), lo que escalaría sus privilegios.

→Limite el permiso `iam:PassRole` en la política de IAM del usuario/rol. Restrinja el elemento `Resource` solo a los ARN de rol específicos y de mínimo privilegio que la entidad está autorizada a pasar.

Por qué: `iam:PassRole` con un comodín (`"Resource": "*"`) es un riesgo importante de escalada de privilegios. Limitarlo a roles específicos y menos privilegiados es un control de seguridad crítico.

Desafiar a los usuarios con MFA solo cuando un intento de inicio de sesión se considera arriesgado (p. ej., nuevo dispositivo, ubicación inusual).

→Habilite las características de seguridad avanzada en el grupo de usuarios de Cognito y configure la autenticación adaptativa con aplicación de MFA basada en riesgos.

Por qué: Esto proporciona una mejor experiencia de usuario que requerir MFA para cada inicio de sesión, al tiempo que mejora la seguridad aplicando desafíos solo a intentos de inicio de sesión anómalos.

Permitir que los servidores locales que utilizan una PKI privada accedan a los servicios de AWS sin credenciales de AWS a largo plazo.

→Configure IAM Roles Anywhere. Cree un ancla de confianza utilizando el certificado de CA privado. Cree perfiles que mapeen certificados a roles de IAM. Los servidores utilizan sus certificados para obtener credenciales temporales de AWS.

Por qué: Esto extiende los roles de IAM a cargas de trabajo externas al aprovechar la PKI existente, eliminando la necesidad de administrar claves de acceso de AWS en las instalaciones.

Evitar el despliegue de recursos no conformes definidos en plantillas de CloudFormation *antes* de su aprovisionamiento.

→Habilite los controles proactivos de AWS Control Tower. Estos utilizan hooks de CloudFormation para validar las configuraciones de los recursos contra las políticas (escritas en cfn-guard) antes del aprovisionamiento.

Por qué: Este es un control de "desplazamiento a la izquierda" que previene configuraciones erróneas en la fuente, lo cual es más efectivo que detectarlas y remediarlas después de haber sido desplegadas.