Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
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 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ándares administrados por servicios en Security Hub.
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 al habilitar por primera vez un control aplicable mediante uno de los métodos siguientes:
-
AWS Control Tower consola
-
AWS Control Tower API (llame a la
EnableControl
API) -
AWS CLI (ejecuta el
enable-control
comando)
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
EnableControl
andDisableControl
APIs) -
AWS CLI (ejecuta los
disable-control
comandos enable-control
y)
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, el AWS Control Tower control se desvía. El estado del control se AWS Control Tower muestra comoDrifted
. Puede resolver este problema seleccionando Volver a registrar la unidad organizativa en la AWS Control Tower consola o desactivando y volviendo 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
ListEnabledControls
API) -
AWS CLI para ver una lista de los controles habilitados (ejecuta el
list-enabled-controls
comando)
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 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 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
DisableControl
API) -
AWS CLI (ejecuta el
disable-control
comando)
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 en Security Hub
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 el control de seguridad independiente del estándar. IDs En la AWS Control Tower consola, los controles IDs 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).
-
[Account.1] La información de contacto de seguridad debe proporcionarse para una Cuenta de AWS
-
[APIGateway.3] REST API Las etapas de API Gateway deben tener habilitado el AWS X-Ray rastreo
-
[APIGateway.4] La API puerta de enlace debe estar asociada a una web WAF ACL
-
[APIGateway.5] Los datos de la REST API caché 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 de API Gateway V2
-
[AppSync.5] AWS AppSync APIs GraphQL no debe autenticarse con claves API
-
[AutoScaling.2] El grupo Amazon EC2 Auto Scaling debe cubrir varias zonas de disponibilidad
-
[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 estar integrados con Amazon Logs CloudWatch
-
[CodeBuild.3] Los registros de CodeBuild S3 deben estar cifrados
-
[DMS.1] Las instancias de replicación de Database Migration Service no deben ser públicas
-
[DocumentDB.1] Los clústeres de Amazon DocumentDB deben cifrarse en reposo
-
[DocumentDb.3] Las instantáneas de clústeres manuales de Amazon DocumentDB no deben ser públicas
-
[DynamoDB.2] Las tablas de DynamoDB deben tener habilitada la recuperación point-in-time
-
[DynamoDB.3] Los clústeres de DynamoDB Accelerator () deben cifrarse en reposo DAX
-
[EC2.1] Las instantáneas de Amazon EBS no deberían poder restaurarse públicamente
-
[EC2.3] Los volúmenes adjuntos de Amazon EBS deben cifrarse en reposo
-
[EC2.4] EC2 Las instancias 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 VPCs
-
[EC2.7] El cifrado predeterminado de EBS debe estar activado
-
[EC2.8] EC2 las instancias deben usar la versión 2 del servicio de metadatos de instancias IMDSv2
-
[EC2.9] EC2 Las instancias de Amazon no deben tener una dirección pública IPv4
-
[EC2.15] EC2 Las subredes de Amazon no deberían asignar automáticamente direcciones IP públicas
-
[EC2.16] Deben eliminarse las listas de control de acceso a la red no utilizadas
-
[EC2.17] EC2 Las instancias de Amazon no deberían usar múltiples ENIs
-
[EC2.20] Los dos túneles VPN de una conexión AWS Site-to-Site VPN deben estar activos
-
[EC2.21] La red no ACLs debe permitir la entrada desde el 0.0.0.0/0 al puerto 22 o al puerto 3389
-
[EC2.22] Los grupos de EC2 seguridad de Amazon no utilizados deberían eliminarse
-
[ECR.1] Los repositorios ECR privados deben tener configurado el escaneo de imágenes
-
[ECR.2] Los repositorios ECR privados deben tener configurada la inmutabilidad de las etiquetas
-
[ECR.3] ECR Los repositorios deben tener configurada al menos una política de ciclo de vida
-
[ECS.2] ECS los servicios no deberían tener direcciones IP públicas asignadas automáticamente
-
[ECS.3] las definiciones de ECS tareas no deben compartir el espacio de nombres del proceso del host
-
[ECS.4] los ECS contenedores deberían ejecutarse sin privilegios
-
[ECS.8] Los secretos no deben pasarse como variables de entorno del contenedor
-
[EFS.2] EFS Los volúmenes de Amazon deberían estar en los planes de respaldo
-
[EFS.3] los puntos de EFS acceso deben establecer un directorio raíz
-
[EFS.4] los puntos de EFS acceso deben imponer la identidad de un usuario
-
[EKS.1] Los puntos finales de los EKS clústeres no deben ser de acceso público
-
[EKS.2] EKS los clústeres deberían ejecutarse en una versión compatible de Kubernetes
-
[ElastiCache.4] los grupos de ElastiCache replicación deben estar cifrados en reposo
-
[ElastiCache.5] los grupos de ElastiCache replicación deben cifrarse en tránsito
-
[ELB.3] Los oyentes de Classic Load Balancer deben configurarse con o con terminación HTTPS TLS
-
[ELB.4] Application Load Balancer debe configurarse para eliminar los encabezados http no válidos
-
[ELB.5] El registro de aplicaciones y balanceadores de carga clásicos debe estar habilitado
-
[ELB.7] Los balanceadores de carga clásicos deberían tener habilitado el drenaje de conexiones
-
[ELB.10] Classic Load Balancer debe abarcar varias zonas de disponibilidad
-
[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.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
-
[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
-
[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
-
[Kinesis.1] Las transmisiones de Kinesis deben cifrarse en reposo
-
[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.5] Las funciones VPC Lambda deben funcionar en varias zonas de disponibilidad
-
[MSK.1] MSK Los clústeres 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.3] Las instantáneas del clúster de base de datos de Neptune no deben ser públicas
-
[Neptune.6] Las instantáneas del clúster de base de datos de Neptune deben cifrarse en reposo
-
El grupo de reglas de Stateless Network Firewall [NetworkFirewall.6] 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
-
[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]
-
[RDS.9] Las instancias de base de datos de RDS deben publicar los registros en Logs CloudWatch
-
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
-
Las instancias de RDS [RDS.18] deben implementarse en una VPC
-
Las instancias RDS [RDS.23] no deben usar el puerto predeterminado de un motor de base de datos
-
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
-
[Redshift.7] Los clústeres de Redshift deberían utilizar un enrutamiento mejorado VPC
-
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 buckets de uso general de S3 deben tener habilitado el bloqueo de acceso público
-
[S3.2] Los buckets de uso general de S3 deben bloquear el acceso público de lectura
-
[S3.3] Los buckets de uso general de S3 deben bloquear el acceso público de escritura
-
[S3.5] Los depósitos de uso general de S3 deberían requerir solicitudes de uso SSL
-
[S3.8] Los buckets de uso general de S3 deben bloquear el acceso público
-
[S3.9] Los buckets de uso general de S3 deben tener habilitado el registro de acceso al servidor
-
[S3.13] Los buckets 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.2] Las instancias de SageMaker AI notebook deben lanzarse en una VPC personalizada
-
[SageMaker.3] Los usuarios no deberían tener acceso root a las instancias de SageMaker AI Notebook
-
[SecretsManager.1] Los secretos de Secrets Manager deberían tener habilitada la rotación automática
-
[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
-
[SSM.1] EC2 Las instancias de Amazon deben gestionarse mediante AWS Systems Manager
-
[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] La web regional AWS WAF clásica ACLs debe tener al menos una regla o grupo de reglas
-
[WAF.10] la AWS WAF web ACLs debe 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 .