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

Esta sección proporciona información sobre el estándar gestionado por el servicio:. AWS Control Tower

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

Este estándar está diseñado para los usuarios de AWS Security Hub y AWS 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 cumplimiento de Cuentas de AWS las normas, ya que detectan las acciones que pueden dar lugar a infracciones de las políticas o a errores de configuración. Los controles de Detective detectan el incumplimiento de los recursos (por ejemplo, errores de configuración) 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 del 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 un servicio en el servicio de administración. Para obtener más información, consulte Estándar de gestión de 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

Este estándar solo está disponible si lo crea en. AWS Control Tower AWS Control Tower crea el estándar cuando se habilita por primera vez un control aplicable mediante uno de los métodos siguientes:

• AWS Control Tower consola

• AWS Control Tower API (llame a la EnableControlAPI)

• AWS CLI (ejecuta el enable-controlcomando)

Los controles del 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 habilita Security Hub por usted.

Si no lo has configurado AWS Control Tower, no podrás ver este estándar ni acceder a él en la consola de Security Hub, en la API de Security Hub o AWS CLI. Incluso si lo ha configurado AWS Control Tower, no podrá ver ni acceder a este estándar en Security Hub sin crear primero el estándar AWS Control Tower mediante uno de los métodos anteriores.

Este estándar solo está disponible en los Regiones de AWS lugares donde AWS Control Tower está disponible, incluidos AWS GovCloud (US).

Habilitación y deshabilitación de 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 los controles disponibles en ambos servicios.

Una vez que haya creado el estándar por primera vez, no tendrá 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 activar y desactivar los controles de la entrada estándar AWS Control Tower mediante uno de los siguientes métodos:

• AWS Control Tower consola

• AWS Control Tower API (llame a las DisableControlAPI EnableControly)

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

Al cambiar el estado de activación de un control en AWS 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 se AWS Control Tower muestra comoDrifted. Para resolver este problema, seleccione Volver a registrar la unidad organizativa en la AWS Control Tower consola o deshabilite y vuelva a activar el control AWS Control Tower mediante uno de los métodos anteriores.

Si completa las acciones de activación y desactivación, evitará que el control se desvíe. AWS Control Tower

Al activar o desactivar los controles AWS Control Tower, la acción se aplica a todas las cuentas y regiones. Si habilitas y deshabilitas los controles en Security Hub (no se recomienda para esta norma), la acción solo se aplica a la cuenta corriente y a la región.

nota

La configuración central no se puede utilizar para administrar Service-Managed Standard:. AWS Control Tower Si usa la configuración central, solo puede usar el AWS Control Tower servicio para habilitar y deshabilitar los controles de este estándar para una cuenta administrada centralmente.

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

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

• Consola Security Hub, API Security Hub o AWS CLI

• AWS Control Tower consola

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

• AWS CLI para ver una lista de los controles habilitados (ejecuta el list-enabled-controlscomando)

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

Security Hub calcula el estado del control en función del estado del flujo de trabajo y el estado de conformidad de los resultados del control. Para obtener más información sobre el estado de activación y el estado de control, consulte Visualización de 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 resultados de los controles en Security Hub. La puntuación de seguridad estándar y los resultados de control no están disponibles en. AWS Control Tower

nota

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

Eliminación de la norma

Puede eliminar este estándar deshabilitando todos los controles aplicables AWS Control Tower mediante uno de los siguientes métodos:

• AWS Control Tower consola

• AWS Control Tower API (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, se AWS Control Tower elimina de la página de estándares de la consola de Security Hub y ya no se puede acceder a él mediante la API de Security Hub o AWS CLI.

nota

La desactivación de todos los controles del estándar en Security Hub no desactiva ni elimina el estándar.

Al deshabilitar el servicio Security Hub, se elimina Service-Managed Standard: AWS Control Tower y cualquier otro estándar que haya activado.

Búsqueda del formato de campo para Service-Managed Standard: AWS Control Tower

Cuando cree Service-Managed Standard: AWS Control Tower y habilite los controles para él, empezará a recibir los resultados de control en Security Hub. Security Hub informa de los resultados de control en el AWS Formato de búsqueda de seguridad (ASFF). Estos son los valores ASFF del nombre de recurso de Amazon (ARN) de este estándar y GeneratorId:

• 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 los resultados de Service-Managed Standard:, consulte. AWS Control TowerEjemplos de resultados de control

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

Estándar gestionado por el servicio: AWS Control Tower admite un subconjunto de controles que forman parte del estándar de mejores prácticas de seguridad AWS fundamentales (FSBP). Elija un control de la siguiente tabla para ver información al respecto, incluidos los pasos para corregir los errores detectados.

La siguiente lista muestra los controles disponibles para el estándar gestionado por el servicio:. AWS Control Tower Los límites Regionales de los controles coinciden con los límites Regionales de los controles corolarios del estándar FSBP. Esta lista muestra los identificadores de control de seguridad independientes del estándar. En la AWS Control Tower consola, los ID de control tienen el formato SH. ControlID (por ejemplo, SH). CodeBuild.1). En Security Hub, si los resultados de control consolidados están desactivados en su cuenta, el campo ProductFields.ControlId usa el identificador de control basado en estándares. El ID de control estándar tiene el formato CT. ControlId(por ejemplo, CT. CodeBuild.1).

• [Cuenta.1] La información de contacto de seguridad debe proporcionarse para 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

• [ACM.2] Los certificados RSA administrados por ACM deben utilizar una longitud de clave de al menos 2048 bits

• [APIGateway.1] El registro de ejecución de API y REST de WebSocket API Gateway debe estar habilitado

• [APIGateway.2] Las etapas de la API de REST de API Gateway deben configurarse para usar certificados SSL para la autenticación de back-end

• [APIGateway.3] Las etapas de la API de REST de API Gateway deberían tener el rastreo habilitado de AWS X-Ray

• [APIGateway.4] La API Gateway debe estar asociada a una ACL web de WAF

• [APIGateway.5] Los datos de la caché de la API de REST 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

• [AppSync.5] Las API de AWS AppSync GraphQL no deben autenticarse con claves de API

• [Athena.1] Los grupos de trabajo de Athena deben estar cifrados en reposo

• [AutoScaling.1] Los grupos de Auto Scaling asociados a un Load Balancer clásico deben utilizar las comprobaciones de estado del balanceador de carga

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

• [AutoScaling.3] Las configuraciones de lanzamiento grupal de Auto Scaling deberían configurar las instancias EC2 para que requieran la versión 2 del Servicio de Metadatos de Instancia (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 grupo de escalado automático no deben tener direcciones IP públicas

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

• [AutoScaling.9] Los grupos de Auto Scaling de Amazon EC2 deberían utilizar las plantillas de lanzamiento de Amazon EC2

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

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

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

• [CloudTrail.5] CloudTrail Los senderos deben integrarse con Amazon Logs CloudWatch

• [CloudTrail.6] Asegúrese de que el depósito de S3 que se utiliza para almacenar CloudTrail los registros no sea de acceso público

• [CodeBuild.1] Las URL del repositorio fuente de CodeBuild Bitbucket no deben contener credenciales confidenciales

• [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 de los CodeBuild proyectos deben tener una duración de registro AWS Config

• [CodeBuild.5] Los entornos de CodeBuild proyectos no deberían tener habilitado el modo privilegiado

• [DMS.1] Las instancias de replicación de Database Migration Service no deben ser públicas

• [DMS.9] Los puntos finales del DMS deben usar SSL

• [DocumentDB.1] Los clústeres de Amazon DocumentDB deben cifrarse en reposo

• [DocumentDb.2] Los clústeres de Amazon DocumentDB deben tener un período de retención de copias de seguridad adecuado

• [DocumentDb.3] Las instantáneas de clústeres manuales de Amazon DocumentDB 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

• [DynamoDB.3] Los clústeres de DynamoDB Accelerator (DAX) deben cifrarse en reposo

• [EC2.1] Las instantáneas de EBS no se deben poder restaurar públicamente

• [EC2.2] Los grupos de seguridad predeterminados de VPC no deben permitir el tráfico entrante ni saliente

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

• [EC2.4] Las instancias 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 EC2 deben utilizar el servicio de metadatos de instancias versión 2 (IMDSv2)

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

• [EC2.10] Amazon EC2 debe configurarse para utilizar los puntos de enlace de VPC que se crean 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 usar varios ENI

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

• [EC2.19] Los grupos de seguridad no deben permitir el acceso ilimitado a los puertos de alto riesgo

• [EC2.20] Los dos túneles VPN de una conexión VPN de AWS Site-to-Site deberían estar activos

• [EC2.21] Las ACL de red no deben permitir la entrada desde 0.0.0.0.0/0 al puerto 22 o al puerto 3389

• [EC2.22] Los grupos de seguridad de Amazon EC2 que no se utilicen deben eliminarse

• [EC2.23] Amazon EC2 Transit Gateways no debe aceptar automáticamente las solicitudes de adjuntos de VPC

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

• [ECR.1] Los repositorios privados del 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 seguros y definiciones de usuario.

• [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 de los procesos del anfitrión

• [ECS.4] Los contenedores de ECS deben ejecutarse 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 del contenedor

• [ECS.10] Los servicios Fargate de ECS deberían ejecutarse en la última versión de la plataforma Fargate

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

• [EFS.1] El sistema de archivos elástico debe configurarse para cifrar los datos de los archivos en reposo mediante AWS KMS

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

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

• [EFS.4] Los puntos de acceso EFS deben imponer una identidad de usuario

• [EKS.1] Los puntos de enlace del clúster EKS no deben ser de acceso público

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

• [ElastiCache.3] en el caso ElastiCache de Redis, los grupos de replicación deberían tener habilitada la conmutación por error automática

• [ElastiCache.4] ElastiCache para Redis, los grupos de replicación deben estar cifrados en reposo

• [ElastiCache.5] ElastiCache para Redis, los grupos de replicación deben cifrarse en tránsito

• [ElastiCache.6] ElastiCache para los grupos de replicación de Redis anteriores a la versión 6.0, se debe usar Redis AUTH

• [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

• [ELB.1] El equilibrador de carga de aplicación debe configurarse para redirigir todas las solicitudes HTTP a HTTPS

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

• [ELB.3] Los oyentes de Equilibrador de carga clásico deben configurarse con una terminación HTTPS o TLS

• [ELB.4] Equilibrador de carga de aplicación debe configurarse para eliminar los encabezados http

• [ELB.5] El registro de las aplicaciones y de los equilibradores de carga clásicos debe estar habilitado

• [ELB.6] La protección contra la eliminación de Equilibrador de carga de aplicación debe estar habilitada

• [ELB.7] Los equilibradores de carga clásicos deberían tener habilitado el drenaje de conexiones

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

• [ELB.9] Los equilibradores de carga clásicos deberían tener habilitado el equilibrio de carga entre zonas

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

• [ELB.12] Equilibrador de carga de aplicación debe configurarse con el modo defensivo o de mitigación de desincronización más estricto

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

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

• [EMR.1] Los nodos maestros del clúster de Amazon EMR 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 no deben ser de acceso público

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

• [ES.4] Debe estar habilitado el registro de errores de dominio de Elasticsearch en los CloudWatch registros

• [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 con la política de seguridad TLS más reciente

• [EventBridge.3] Los buses de eventos EventBridge personalizados deben tener adjunta una política basada en los recursos

• [GuardDuty.1] GuardDuty debe estar activado

• [IAM.1] Las políticas de IAM no deben permitir privilegios administrativos completos “*”

• [IAM.2] Los usuarios de IAM no deben tener políticas de IAM asociadas

• [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 del 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 usuarios de IAM deben tener configuraciones seguras

• [IAM.8] Deben eliminarse las credenciales de usuario de IAM no utilizadas

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

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

• [KMS.1] Las políticas gestionadas por los clientes 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 integradas de IAM que permitan realizar acciones de descifrado en todas las claves de KMS

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

• La rotación de teclas [KMS.4] debe estar habilitada AWS KMS

• [Lambda.1] Las políticas de función de Lambda deberían prohibir el acceso público

• [Lambda.2] Las funciones de Lambda deben usar los tiempos de ejecución admitidos

• [Lambda.3] Las funciones de Lambda deben estar en una VPC

• [Lambda.5] Las funciones de Lambda de la VPC deben funcionar en varias zonas de disponibilidad

• [MSK.1] Los clústeres de MSK deben cifrarse en tránsito entre los nodos intermediarios

• [MQ.5] Los corredores ActiveMQ deben usar el modo de implementación activo/en espera

• [MQ.6] Los corredores de RabbitMQ deberían usar el modo de implementación de clústeres

• [Neptune.1] Los clústeres de bases de datos de Neptune deben cifrarse en reposo

• [Neptune.2] Los clústeres de bases de datos de Neptune deberían publicar los registros de auditoría en Logs CloudWatch

• [Neptune.4] Los clústeres de base de datos de Neptune deben tener habilitada la protección de eliminación

• [Neptune.4] Los clústeres de base de datos de Neptune deben tener habilitada la protección de eliminación

• [Neptune.5] Los clústeres de bases de datos de Neptune deberían tener habilitadas las copias de seguridad automáticas

• [Neptune.6] Las instantáneas del clúster de base de datos de Neptune deben cifrarse en reposo

• [Neptune.7] Los clústeres de base de datos de Neptune deben tener habilitada la autenticación de bases de datos de IAM

• [Neptune.8] Los clústeres de base de datos de Neptune deben configurarse para copiar etiquetas a las instantáneas

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

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

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

• [NetworkFirewall.6] El grupo de reglas de Stateless Network Firewall no debe estar vacío

• Los OpenSearch dominios [Opensearch.1] deben tener activado el cifrado en reposo

• Los OpenSearch dominios [Opensearch.2] no deben ser de acceso público

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

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

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

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

• Los OpenSearch dominios [Opensearch.7] deben tener habilitado un control de acceso detallado

• [Opensearch.8] Las conexiones a los OpenSearch dominios deben cifrarse según la política de seguridad TLS más reciente

• [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

• Las instantáneas de clústeres y bases de datos de RDS [RDS.4] deben cifrarse cuando están inactivas

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

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

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

• [RDS.9] Las instancias de base de datos de RDS deben publicar CloudWatch registros en Logs

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

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

• La autenticación de IAM [RDS.12] debe configurarse para los clústeres de RDS

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

• Los clústeres de bases de datos de RDS [RDS.15] deben configurarse para varias zonas de disponibilidad

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

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

• Las suscripciones de notificación de eventos de RDS [RDS.19] existentes deben configurarse para los eventos de clúster críticos

• Las suscripciones de notificación de eventos de RDS [RDS.20] existentes deben configurarse para eventos críticos de instancias de bases de datos

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

• Se debe configurar una suscripción a las notificaciones de eventos de RDS [RDS.22] para los eventos críticos de los grupos de seguridad de bases de datos

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

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

• Los clústeres de bases de datos de RDS [RDS.27] deben cifrarse en reposo

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

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

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

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

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

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

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

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

• [S3.1] Los depósitos de uso general de S3 deberían tener habilitada la configuración de bloqueo de acceso público

• [S3.2] Los depósitos de uso general de S3 deberían bloquear el acceso público de lectura

• [S3.3] Los cubos de uso general de S3 deberían bloquear el acceso público de escritura

• [S3.5] Los depósitos de uso general de S3 deberían requerir solicitudes para usar SSL

• [S3.6] Las políticas de compartimentos de uso general de S3 deberían restringir el acceso a otros Cuentas de AWS

• [S3.8] Los depósitos de uso general de S3 deberían bloquear el acceso público

• [S3.9] Los depósitos de uso general de S3 deberían tener habilitado el registro de acceso al servidor

• [S3.10] Los depósitos de uso general de S3 con el control de versiones habilitado deben tener configuraciones de ciclo de vida

• [S3.11] Los buckets de uso general de S3 deberían tener habilitadas las notificaciones de eventos

• [S3.12] Las ACL no deben usarse para administrar el acceso de los usuarios a los depósitos de uso general de S3

• [S3.13] Los depósitos de uso general de S3 deben tener configuraciones de ciclo de vida

• [S3.17] Los depósitos de uso general de S3 deben cifrarse en reposo con AWS KMS keys

• [SageMaker.1] Las instancias de Amazon SageMaker Notebook no deberían 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 de SageMaker notebook

• [SecretsManager.1] Los secretos de Secrets Manager deberían 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 de Secrets Manager no utilizados

• [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

• Debe habilitarse el registro del estado de la entrega [SNS.2] para los mensajes de notificación enviados a un tema

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

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

• [SSM.2] Las instancias EC2 de Amazon administradas por Systems Manager deben tener un estado de conformidad de parche de COMPLIANT después de la instalación de un parche

• [SSM.3] Las instancias Amazon EC2 administradas por Systems Manager deben tener el estado de conformidad de la asociación de COMPLIANT

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

• [WAF.2] Las reglas regionales AWS WAF clásicas deben tener al menos una condición

• [WAF.3] Los grupos de reglas regionales AWS WAF clásicos deben tener al menos una regla

• [WAF.4] Las ACL web regionales AWS WAF clásicas deben tener al menos una regla o grupo de reglas

• [WAF.10] Las ACL AWS WAF web deben tener al menos una regla o grupo de reglas

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