Estándar de gestión de servicios: AWS Control Tower

Esta sección proporciona información sobre Service-Managed Standard:. AWS Control Tower

¿Qué es Service-Managed Standard:? AWS Control Tower

Este estándar está diseñado para los usuarios de AWS Security Hub yAWS Control Tower. Le permite configurar los controles proactivos AWS Control Tower junto con los controles de detección de Security Hub en el AWS Control Tower servicio.

Los controles proactivos ayudan a garantizar el Cuentas de AWS cumplimiento, ya que detectan las acciones que pueden provocar infracciones de las políticas o errores de configuración. Los controles de detección detectan el incumplimiento de los recursos (por ejemplo, configuraciones incorrectas) dentro de su. Cuentas de AWS Al habilitar controles proactivos y de detección para su AWS entorno, puede mejorar su postura de seguridad en las diferentes etapas de desarrollo.

sugerencia

Los estándares de administración de servicios difieren de los estándares que administra AWS Security Hub. Por ejemplo, debe crear y eliminar un estándar administrado por servicios en el servicio de administración. Para obtener más información, consulte Estándares gestionados por servicios.

En la consola y la API de Security Hub, puede ver Service-Managed Standard, AWS Control Tower junto con otros estándares de Security Hub.

Creación del estándar

Esta norma solo está disponible si se crea la norma enAWS Control Tower. AWS Control Towercrea el estándar cuando se habilita por primera vez un control aplicable mediante uno de los métodos siguientes:

• Consola de AWS Control Tower

• AWS Control TowerAPI (llame a la EnableControlAPI)

• AWS CLI(ejecuta el enable-controlcomando)

Los controles de Security Hub se identifican en la AWS Control Tower consola como SH. ControlID (por ejemplo, SH. CodeBuild.1).

Al crear el estándar, si aún no ha activado Security Hub, AWS Control Tower también habilitará Security Hub por usted.

Si no lo ha configuradoAWS Control Tower, no podrá ver ni acceder a este estándar en la consola de Security Hub, la API de Security Hub niAWS CLI. Incluso si lo ha configuradoAWS Control Tower, no podrá ver ni acceder a este estándar en Security Hub sin crearlo primero AWS Control Tower mediante uno de los métodos anteriores.

Esta norma solo está disponible en los lugares Regiones de AWSdonde AWS Control Tower está disponible, inclusoAWS GovCloud (US).

Activación y desactivación de los controles en el estándar

Una vez que haya creado el estándar en la AWS Control Tower consola, podrá ver el estándar y sus controles disponibles en ambos servicios.

Después de crear el estándar por primera vez, no tiene ningún control que se active automáticamente. Además, cuando Security Hub agrega nuevos controles, no se habilitan automáticamente para Service-Managed Standard:. AWS Control Tower Debe habilitar y deshabilitar los controles del estándar en AWS Control Tower mediante uno de los siguientes métodos:

• Consola de AWS Control Tower

• AWS Control TowerAPI (llame a las DisableControlAPI EnableControly)

• AWS CLI(ejecuta los disable-controlcomandos enable-controland)

Al cambiar el estado de activación de un control enAWS Control Tower, el cambio también se refleja en Security Hub.

Sin embargo, si se desactiva un control en Security Hub que está activado, se AWS Control Tower produce una desviación del control. El estado del control en AWS Control Tower se muestra comoDrifted. Puede resolver este problema seleccionando Volver a registrar la unidad organizativa en la AWS Control Tower consola o deshabilitando y volviendo a habilitar el control AWS Control Tower mediante uno de los métodos anteriores.

Completar las acciones de activación y desactivación en AWS Control Tower ayuda a evitar la desviación del control.

Al habilitar o deshabilitar los controles enAWS Control Tower, la acción se aplica a todas las cuentas y regiones. Si habilita y deshabilita los controles en Security Hub (no se recomienda para esta norma), la acción solo se aplica a la cuenta y la región actuales.

Visualización del estado de activación y el estado de control

Puede ver el estado de activación de un control mediante uno de los métodos siguientes:

• Consola de Security Hub, API de Security Hub o AWS CLI

• Consola de AWS Control Tower

• AWS Control TowerAPI para ver una lista de los controles habilitados (llame a la ListEnabledControlsAPI)

• AWS CLIpara ver una lista de los controles habilitados (ejecute el list-enabled-controlscomando)

Un control que se deshabilita AWS Control Tower tiene un estado de activación de Disabled Security Hub, a menos que lo habilite explícitamente en Security Hub.

Security Hub calcula el estado del control en función del estado del flujo de trabajo y el estado de cumplimiento de los hallazgos del control. Para obtener más información sobre el estado de activación y el estado de control, consulte. Visualización de los detalles de un control

En función de los estados de control, Security Hub calcula una puntuación de seguridad para Service-Managed Standard:. AWS Control Tower Esta puntuación solo está disponible en Security Hub. Además, solo puede ver los hallazgos de los controles en Security Hub. La puntuación de seguridad estándar y los hallazgos de control no están disponibles enAWS Control Tower.

nota

Al habilitar los controles de Service-Managed Standard:AWS Control Tower, Security Hub puede tardar hasta 18 horas en generar los hallazgos de los controles que utilizan una regla vinculada a un AWS Config servicio existente. Es posible que ya tenga reglas vinculadas a servicios si ha activado otros estándares y controles en Security Hub. Para obtener más información, consulte Programación para ejecutar comprobaciones de seguridad.

Eliminar la norma

Puede eliminar esta norma AWS Control Tower desactivando todos los controles aplicables mediante uno de los siguientes métodos:

• Consola de AWS Control Tower

• AWS Control TowerAPI (llame a la DisableControlAPI)

• AWS CLI(ejecuta el disable-controlcomando)

Al deshabilitar todos los controles, se elimina el estándar en todas las cuentas administradas y regiones gobernadas de. AWS Control Tower Al eliminar el estándar en, se AWS Control Tower elimina de la página de estándares de la consola de Security Hub y ya no podrá acceder a él mediante la API de Security Hub oAWS CLI.

nota

Al deshabilitar todos los controles del estándar en Security Hub, no se deshabilita ni elimina el estándar.

Al deshabilitar el servicio Security Hub, se elimina el estándar administrado por el servicio AWS Control Tower y cualquier otro estándar que haya habilitado.

Encontrando el formato de campo para Service-Managed Standard: AWS Control Tower

Cuando cree Service-Managed Standard AWS Control Tower y habilite sus controles, empezará a recibir los hallazgos de los controles en Security Hub. Security Hub informa de los hallazgos de control enFormato de los hallazgos de seguridad de AWS (ASFF). Estos son los valores ASFF para el nombre de recurso de Amazon (ARN) de esta norma yGeneratorId:

• ARN estándar — arn:aws:us-east-1:securityhub:::standards/service-managed-aws-control-tower/v/1.0.0

• GeneratorId – service-managed-aws-control-tower/v/1.0.0/CodeBuild.1

Para ver un ejemplo de búsqueda de Service-Managed Standard:AWS Control Tower, consulte. Hallazgos del control de muestras

Controles que se aplican a Service-Managed Standard: AWS Control Tower

Estándar gestionado por servicios: AWS Control Tower admite un subconjunto de controles que forman parte del estándar AWS básico de mejores prácticas de seguridad (FSBP). Elija un control de la siguiente tabla para ver información sobre él, incluidos los pasos de corrección en caso de hallazgos fallidos.

La siguiente lista muestra los controles disponibles para Service-Managed Standard:. AWS Control Tower Los límites regionales de los controles coinciden con los límites regionales de los controles corolarios de la norma FSBP. Esta lista muestra los identificadores de control de seguridad independientes de los estándares. En la AWS Control Tower consola, los identificadores de control tienen el formato SH. ControlID (por ejemplo, SH. CodeBuild.1). En Security Hub, si las comprobaciones de control consolidadas están desactivadas en su cuenta, el ProductFields.ControlId campo utiliza el identificador de control basado en estándares. El identificador de control basado en estándares tiene el formato CT. ControlId(por ejemplo, CT. CodeBuild.1).

• [Cuenta.1] Se debe proporcionar la información de contacto de seguridad de un. Cuenta de AWS

• [ACM.1] Los certificados importados y emitidos por ACM deben renovarse después de un período de tiempo específico

• [ApiGateway.1] El REST de API Gateway.1 y el registro de ejecución de la WebSocket API deben estar habilitados

• [ApiGateway.2] Las etapas de la API REST de API Gateway deben configurarse para usar certificados SSL para la autenticación de fondo

• [ApiGateway.3] Las etapas de la API REST de API Gateway deben tener el rastreo activado AWS X-Ray

• [ApiGateway.4] La puerta de enlace de API debe estar asociada a una ACL web de WAF

• [ApiGateway.5] Los datos de caché de la API REST de API de API Gateway deben cifrarse en reposo

• [ApiGateway.8] Las rutas de API Gateway deben especificar un tipo de autorización

• [ApiGateway.9] El registro de acceso debe configurarse para las etapas V2 de API Gateway

• [AutoScaling.1] Los grupos de escalado automático asociados a un balanceador de carga clásico deben utilizar las comprobaciones de estado del balanceador de cargas

• [AutoScaling.2] El grupo Amazon EC2 Auto Scaling debe abarcar varias zonas de disponibilidad

• [AutoScaling.3] Las configuraciones de lanzamiento de grupos de Auto Scaling deberían configurar las instancias de EC2 para que requieran la versión 2 del servicio de metadatos de instancias (IMDSv2)

• [AutoScaling.4] La configuración de inicio de grupos de Auto Scaling no debe tener un límite de saltos de respuesta de metadatos superior a 1

• [Autoscaling.5] Las instancias de Amazon EC2 lanzadas mediante configuraciones de lanzamiento de grupos de Auto Scaling no deben tener direcciones IP públicas

• [AutoScaling.6] Los grupos de Auto Scaling deben usar varios tipos de instancias en varias zonas de disponibilidad

• [AutoScaling.9] Los grupos de Amazon EC2 Auto Scaling deben utilizar plantillas de lanzamiento de Amazon EC2

• [CloudTrail.1] CloudTrail debe habilitarse y configurarse con al menos una ruta multirregional que incluya eventos de administración de lectura y escritura

• [CloudTrail.2] CloudTrail debe tener habilitado el cifrado en reposo

• [CloudTrail.4] La validación del archivo de CloudTrail registro debe estar habilitada

• [CloudTrail.5] CloudTrail las rutas deben integrarse con Amazon Logs CloudWatch

• [CodeBuild.1] CodeBuild GitHub o las URL del repositorio fuente de Bitbucket deben usar OAuth

• [CodeBuild.2] las variables de entorno CodeBuild del proyecto no deben contener credenciales de texto claro

• [CodeBuild.3] Los registros de CodeBuild S3 deben estar cifrados

• [CodeBuild.4] Los entornos CodeBuild del proyecto deben tener una duración de registro AWS Config

• [CodeBuild.5] los entornos CodeBuild del proyecto no deberían tener activado el modo privilegiado

• [DMS.1] Las instancias de replicación del Servicio de migración de bases de datos no deben ser públicas

• [DynamoDB.1] Las tablas de DynamoDB deberían escalar automáticamente la capacidad en función de la demanda

• [DynamoDB.2] Las tablas de DynamoDB deben tener habilitada la recuperación point-in-time

• [EC2.1] Las instantáneas de Amazon EBS no deberían poder restaurarse públicamente

• [EC2.2] El grupo de seguridad predeterminado de VPC no debe permitir el tráfico entrante ni saliente

• [EC2.3] Los volúmenes de Amazon EBS adjuntos deben cifrarse en reposo

• [EC2.4] Las instancias de Amazon EC2 detenidas deben eliminarse después de un período de tiempo específico

• [EC2.6] El registro de flujo de VPC debe estar habilitado en todas las VPC

• [EC2.7] El cifrado predeterminado de EBS debe estar activado

• [EC2.8] Las instancias de EC2 deben usar la versión 2 del servicio de metadatos de instancias (IMDSv2)

• [EC2.9] Las instancias de Amazon EC2 no deben tener una dirección IPv4 pública

• [EC2.10] Amazon EC2 debe configurarse para utilizar puntos de enlace de VPC creados para el servicio Amazon EC2

• [EC2.15] Las subredes de Amazon EC2 no deben asignar automáticamente direcciones IP públicas

• [EC2.16] Deben eliminarse las listas de control de acceso a la red no utilizadas

• [EC2.17] Las instancias de Amazon EC2 no deben utilizar varios ENI

• [EC2.18] Los grupos de seguridad solo deben permitir el tráfico entrante sin restricciones a los puertos autorizados

• [EC2.19] Los grupos de seguridad no deberían permitir el acceso sin restricciones a los puertos de alto riesgo

• [EC2.20] Ambos túneles VPN para una conexión VPN de AWS sitio a sitio deberían estar activos

• [EC2.21] Las ACL de red no deberían permitir la entrada de 0.0.0.0/0 al puerto 22 o al puerto 3389

• [EC2.22] Los grupos de seguridad de Amazon EC2 no utilizados deben eliminarse

• [EC2.25] Las plantillas de lanzamiento de Amazon EC2 no deben asignar IP públicas a las interfaces de red

• [ECR.1] Los repositorios privados de ECR deben tener configurado el escaneo de imágenes

• [ECR.2] Los repositorios privados de ECR deben tener configurada la inmutabilidad de etiquetas

• [ECR.3] Los repositorios de ECR deben tener configurada al menos una política de ciclo de vida

• [ECS.1] Las definiciones de tareas de Amazon ECS deben tener modos de red y definiciones de usuario seguros.

• [ECS.2] Los servicios de ECS no deberían tener direcciones IP públicas asignadas automáticamente

• [ECS.3] Las definiciones de tareas de ECS no deben compartir el espacio de nombres del proceso del host

• [ECS.4] Los contenedores ECS deben ejecutarse como contenedores sin privilegios

• [ECS.5] Los contenedores ECS deben limitarse al acceso de solo lectura a los sistemas de archivos raíz

• [ECS.8] Los secretos no deben pasarse como variables de entorno de contenedor

• [ECS.10] Los servicios de ECS Fargate deben ejecutarse en la versión más reciente de la plataforma Fargate

• [ECS.12] Los clústeres de ECS deben usar Container Insights

• [EFS.1] El Elastic File System debe configurarse para cifrar los datos de archivos en reposo mediante AWS KMS

• [EFS.2] Los volúmenes de Amazon EFS deben incluirse en los planes de backup

• [EFS.3] Los puntos de acceso EFS deben aplicar un directorio raíz

• [EFS.4] Los puntos de acceso EFS deben reforzar la identidad de un usuario

• [EKS.2] Los clústeres de EKS deben ejecutarse en una versión compatible de Kubernetes

• [ELB.1] El balanceador de carga de aplicaciones debe configurarse para redirigir todas las solicitudes HTTP a HTTPS

• [ELB.2] Los balanceadores de carga clásicos con oyentes SSL/HTTPS deben usar un certificado proporcionado por AWS Certificate Manager

• [ELB.3] Los oyentes de Classic Load Balancer deben configurarse con una terminación HTTPS o TLS

• [ELB.4] El balanceador de carga de aplicaciones debe configurarse para eliminar los encabezados http

• [ELB.5] Se debe habilitar el registro de aplicaciones y balanceadores de carga clásicos

• [ELB.6] La protección de eliminación del balanceador de carga de aplicaciones debe estar habilitada

• [ELB.7] Los balanceadores de carga clásicos deben tener activado el drenaje de conexiones

• [ELB.8] Los balanceadores de carga clásicos con detectores SSL deben utilizar una política de seguridad predefinida que tenga una duración sólida AWS Config

• [ELB.9] Los balanceadores de carga clásicos deben tener activado el balanceo de cargas entre zonas

• [ELB.10] El balanceador de carga clásico debe abarcar varias zonas de disponibilidad

• [ELB.12] El balanceador de carga de aplicaciones debe configurarse con el modo defensivo o de mitigación de la desincronización más estricto

• [ELB.13] Los balanceadores de cargas de aplicaciones, redes y puertas de enlace deben abarcar varias zonas de disponibilidad

• [ELB.14] El balanceador de carga clásico debe configurarse con el modo defensivo o de mitigación de la desincronización más estricto

• [EMR.1] Los nodos maestros del MapReduce clúster de Amazon Elastic no deben tener direcciones IP públicas

• [ES.1] Los dominios de Elasticsearch deben tener habilitado el cifrado en reposo

• [ES.2] Los dominios de Elasticsearch deben estar en una VPC

• [ES.3] Los dominios de Elasticsearch deben cifrar los datos enviados entre nodos

• [ES.4] Se debe habilitar el registro de errores del dominio de Elasticsearch en CloudWatch Logs

• [ES.5] Los dominios de Elasticsearch deben tener habilitado el registro de auditoría

• [ES.6] Los dominios de Elasticsearch deben tener al menos tres nodos de datos

• [ES.7] Los dominios de Elasticsearch deben configurarse con al menos tres nodos maestros dedicados

• [ES.8] Las conexiones a los dominios de Elasticsearch deben cifrarse mediante TLS 1.2

• [ElasticBeanstalk.1] Los entornos de Elastic Beanstalk deberían tener habilitados los informes de estado mejorados

• [ElasticBeanstalk.2] Las actualizaciones de la plataforma gestionada de Elastic Beanstalk deben estar habilitadas

• [GuardDuty.1] GuardDuty debe estar activado

• [IAM.1] Las políticas de IAM no deberían permitir todos los privilegios administrativos de tipo «*»

• [IAM.2] Los usuarios de IAM no deberían tener políticas de IAM adjuntas

• [IAM.3] Las claves de acceso de los usuarios de IAM deben rotarse cada 90 días o menos

• [IAM.4] La clave de acceso de usuario raíz de IAM no debería existir

• [IAM.5] MFA debe estar habilitado para todos los usuarios de IAM que tengan una contraseña de consola

• [PCI.IAM.6] La MFA de hardware debe estar habilitada para el usuario raíz

• [IAM.7] Las políticas de contraseñas para los usuarios de IAM deben tener una duración sólida AWS Config

• [IAM.8] Se deben eliminar las credenciales de usuario de IAM no utilizadas

• [IAM.21] Las políticas gestionadas por clientes de IAM que cree no deberían permitir acciones comodín para los servicios

• [Kinesis.1] Las transmisiones de Kinesis deben cifrarse en reposo

• [KMS.1] Las políticas gestionadas por el cliente de IAM no deberían permitir acciones de descifrado en todas las claves de KMS

• [KMS.2] Los directores de IAM no deberían tener políticas de IAM en línea que permitan acciones de descifrado en todas las claves de KMS

• [KMS.3] no AWS KMS keys debe eliminarse involuntariamente

• [Lambda.1] Las políticas de funciones lambda deberían prohibir el acceso público

• [Lambda.2] Las funciones de Lambda deben utilizar tiempos de ejecución compatibles

• [Lambda.5] Las funciones Lambda de VPC deben funcionar en más de una zona de disponibilidad

• [NetworkFirewall.3] Las políticas de firewall de red deben tener asociado al menos un grupo de reglas

• [NetworkFirewall.4] La acción sin estado predeterminada para las políticas de firewall de red debe ser eliminar o reenviar paquetes completos

• [NetworkFirewall.5] La acción sin estado predeterminada para las políticas de firewall de red debe ser eliminar o reenviar paquetes fragmentados

• [NetworkFirewall.6] El grupo de reglas de firewall de red sin estado no debe estar vacío

• OpenSearchLos dominios [Opensearch.1] deben tener habilitado el cifrado en reposo

• OpenSearchLos dominios de [Opensearch.2] deben estar en una VPC

• OpenSearchLos dominios [Opensearch.3] deben cifrar los datos enviados entre nodos

• [Opensearch.4] OpenSearch El registro de errores de dominio en CloudWatch Logs debe estar activado

• OpenSearchLos dominios [Opensearch.5] deben tener activado el registro de auditoría

• OpenSearchLos dominios [Opensearch.6] deben tener al menos tres nodos de datos

• OpenSearchLos dominios [Opensearch.7] deben tener activado el control de acceso detallado

• [Opensearch.8] Las conexiones a los OpenSearch dominios deben cifrarse mediante TLS 1.2

• [RDS.1] La instantánea de RDS debe ser privada

• [RDS.2] Las instancias de base de datos de RDS deben prohibir el acceso público, según lo determine la duración PubliclyAccessible AWS Config

• [RDS.3] Las instancias de base de datos de RDS deben tener habilitado el cifrado en reposo

• [RDS.4] Las instantáneas del clúster de RDS y las instantáneas de bases de datos deben cifrarse en reposo

• [RDS.5] Las instancias de base de datos de RDS deben configurarse con varias zonas de disponibilidad

• [RDS.6] Se debe configurar una monitorización mejorada para las instancias de base de datos de RDS

• [RDS.8] Las instancias de base de datos de RDS deben tener habilitada la protección de eliminación

• [RDS.9] El registro de bases de datos debe estar activado

• [RDS.10] La autenticación de IAM debe configurarse para las instancias de RDS

• [RDS.11] Las instancias de RDS deben tener habilitadas las copias de seguridad automáticas

• [RDS.13] Las actualizaciones automáticas de versiones secundarias de RDS deben estar habilitadas

• [RDS.17] Las instancias de base de datos de RDS deben configurarse para copiar las etiquetas a las instantáneas

• [RDS.18] Las instancias de RDS deben implementarse en una VPC

• [RDS.19] Se debe configurar una suscripción de notificaciones de eventos de RDS para eventos de clúster críticos

• [RDS.20] Se debe configurar una suscripción de notificaciones de eventos de RDS para eventos críticos de instancias de bases de datos

• [RDS.21] Se debe configurar una suscripción de notificaciones de eventos de RDS para eventos críticos del grupo de parámetros de bases de datos

• [RDS.22] Se debe configurar una suscripción de notificaciones de eventos de RDS para eventos críticos del grupo de seguridad de bases de datos

• [RDS.23] Las instancias de RDS no deben usar un puerto predeterminado del motor de base de datos

• [RDS.25] Las instancias de bases de datos de RDS deben usar un nombre de usuario de administrador personalizado

• [Redshift.1] Los clústeres de Amazon Redshift deberían prohibir el acceso público

• [Redshift.2] Las conexiones a los clústeres de Amazon Redshift deben cifrarse durante el tránsito

• [Redshift.4] Los clústeres de Amazon Redshift deben tener activado el registro de auditoría

• [Redshift.6] Amazon Redshift debería tener habilitadas las actualizaciones automáticas a las versiones principales

• [Redshift.7] Los clústeres de Redshift deben utilizar un enrutamiento de VPC mejorado

• [Redshift.8] Los clústeres de Amazon Redshift no deben usar el nombre de usuario de administrador predeterminado

• [Redshift.9] Los clústeres de Redshift no deben usar el nombre de base de datos predeterminado

• [Redshift.10] Los clústeres de Redshift deben cifrarse en reposo

• [S3.1] La configuración de S3 Block Public Access debe estar habilitada

• [S3.2] Los buckets de S3 deberían prohibir el acceso de lectura público

• [S3.3] Los buckets de S3 deberían prohibir el acceso de escritura público

• [S3.4] Los buckets de S3 deben tener habilitado el cifrado del lado del servidor

• [S3.5] Los buckets de S3 deberían requerir que las solicitudes usen Secure Socket Layer

• [S3.6] Los permisos de S3 concedidos a otras políticas Cuentas de AWS de bucket deben restringirse

• [S3.8] La configuración de acceso público en bloque de S3 debe estar habilitada a nivel de bucket

• [S3.9] Se debe habilitar el registro de acceso al servidor de bucket S3

• [S3.10] Los buckets de S3 con el control de versiones habilitado deben tener configuradas las políticas de ciclo de vida

• [S3.11] Los buckets de S3 deben tener habilitadas las notificaciones de eventos

• [S3.12] Las listas de control de acceso (ACL) de S3 no deben usarse para administrar el acceso de los usuarios a los buckets

• [S3.13] Los buckets de S3 deben tener configuradas las políticas de ciclo de vida

• [SageMaker.1] Las instancias de Amazon SageMaker Notebook no deben tener acceso directo a Internet

• [SageMaker.2] las instancias de SageMaker notebook deben lanzarse en una VPC personalizada

• [SageMaker.3] Los usuarios no deberían tener acceso root a las instancias del SageMaker bloc de notas

• [SecretsManager.1] Los secretos de Secrets Manager deben tener habilitada la rotación automática

• [SecretsManager.2] Los secretos de Secrets Manager configurados con rotación automática deberían rotar correctamente

• [SecretsManager.3] Eliminar los secretos no utilizados de Secrets Manager

• [SecretsManager.4] Los secretos de Secrets Manager deben rotarse en un número específico de días

• [SNS.1] Los temas de SNS deben cifrarse en reposo mediante AWS KMS

• [SNS.2] Se debe habilitar el registro del estado de entrega para los mensajes de notificación enviados a un tema

• [SQS.1] Las colas de Amazon SQS deben cifrarse en reposo

• [SSM.1] Las instancias de Amazon EC2 deben gestionarse mediante AWS Systems Manager

• [SSM.2] Tras la instalación del parche, las instancias de Amazon EC2 gestionadas por Systems Manager deberían tener un estado de conformidad con los parches

• [SSM.3] Las instancias de Amazon EC2 gestionadas por Systems Manager deben tener un estado de cumplimiento de asociación de CUMPLIMENTABLE

• [SSM.4] Los documentos SSM no deben ser públicos

• [WAF.2] Una regla regional de la WAF debe tener al menos una condición

• [WAF.3] Un grupo de reglas regionales de WAF debe tener al menos una regla

• [WAF.4] Una ACL web regional de WAF debe tener al menos una regla o grupo de reglas

• [WAF.10] Una ACL web de WAFv2 debe tener al menos una regla o grupo de reglas

Para obtener más información sobre esta norma, consulte los controles de Security Hub en la Guía del AWS Control Tower usuario.