Estándar de gestión de servicios: AWS Control Tower
En esta sección, se proporciona información sobre el estándar de administración de servicios: AWS Control Tower.
¿Qué es el estándar de administración de servicios:? AWS Control Tower
Este estándar está diseñado para usuarios del CSPM de AWS Security Hub y AWS Control Tower. Permite configurar los controles proactivos de AWS Control Tower junto con los controles de detección del CSPM de Security Hub en el servicio AWS Control Tower.
Los controles proactivos ayudan a garantizar el cumplimiento de las normas de Cuentas de AWS, 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 entorno de AWS, puede mejorar su postura de seguridad en las diferentes etapas de desarrollo.
sugerencia
Los estándares administrados por el servicio difieren de los estándares que administra el CSPM de 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 el servicio en el CSPM de Security Hub.
En la consola y la API del CSPM de Security Hub, puede ver el estándar administrado por el servicio: AWS Control Tower, junto con otros estándares del CSPM de Security Hub.
Creación del estándar
Esta norma solo está disponible si se crea el estándar 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 TowerConsola de
-
API de AWS Control Tower (llame a la API de
EnableControl) -
AWS CLI (ejecutar el comando
enable-control)
Los controles del CSPM de Security Hub se identifican en la consola de AWS Control Tower como SH.ControlId (por ejemplo, SH.CodeBuild.1).
Cuando crea el estándar, si aún no ha habilitado el CSPM de Security Hub, AWS Control Tower también habilita automáticamente el CSPM de Security Hub en su nombre.
Si no ha configurado AWS Control Tower, no podrá ver el estándar ni acceder a este en la consola, la API o la AWS CLI del CSPM de Security Hub. Incluso si ya configuró AWS Control Tower, no podrá ver el estándar ni acceder a este sin crear antes el estándar en AWS Control Tower mediante uno de los métodos indicados.
Este estándar solo está disponible en los Regiones de AWS en los que 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 consola de AWS Control Tower, 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 el CSPM de Security Hub agrega nuevos controles, estos no se habilitan automáticamente para el estándar administrado por el servicio: AWS Control Tower. Debe habilitar y deshabilitar los controles de la entrada estándar de AWS Control Tower mediante uno de los métodos siguientes:
-
AWS Control TowerConsola de
-
API de AWS Control Tower (llame a las API de
EnableControlyDisableControl) -
AWS CLI (ejecute los comandos
enable-controlydisable-control)
Cuando cambie el estado de habilitación de un control en AWS Control Tower, el cambio también se refleja en el CSPM de Security Hub.
Sin embargo, desactivar un control del CSPM de Security Hub que está habilitado en AWS Control Tower provoca desviación de configuración. El estado del control en AWS Control Tower se muestra como Drifted. Para resolver este problema, seleccione Volver a registrar la unidad organizativa en la consola de AWS Control Tower o deshabilite y vuelva a activar el control en AWS Control Tower mediante uno de los métodos anteriores.
Si completa las acciones de activación y desactivación en AWS Control Tower evitará que el control se desvíe.
Al activar o desactivar los controles en AWS Control Tower, la acción se aplica a todas las cuentas y regiones. Si habilita y desactiva controles en el CSPM de Security Hub (no recomendado para este estándar), la acción se aplica únicamente a la cuenta y región actuales.
nota
La configuración centralizada no se puede utilizar para administrar el estándar administrado por servicios: AWS Control Tower. Si usa la configuración centralizada, solo puede usar el servicio de AWS Control Tower 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 del CSPM de Security Hub, API del CSPM de Security Hub o AWS CLI
-
AWS Control TowerConsola de
-
API de AWS Control Tower para ver una lista de los controles habilitados (llame a la API de
ListEnabledControls) -
AWS CLI para ver una lista de los controles habilitados (ejecuta el comando
list-enabled-controls)
Un control que desactive en AWS Control Tower conserva un estado de habilitación Disabled en el CSPM de Security Hub, a menos que habilite explícitamente ese control en el CSPM de Security Hub.
El CSPM de Security Hub calcula el estado del control según el estado del flujo de trabajo y el estado de cumplimiento de los resultados del control. Para obtener más información sobre el estado de activación y el estado de control, consulte Cómo revisar los detalles de los controles en el CSPM de Security Hub.
Con base en los estados de los controles, el CSPM de Security Hub calcula un puntaje de seguridad para el estándar administrado por el servicio: AWS Control Tower. Este puntaje solo está disponible en el CSPM de Security Hub. Además, solo puede ver los resultados de control en el CSPM de Security Hub. La puntuación de seguridad y los resultados de control estándar no están disponibles en AWS Control Tower.
nota
Cuando habilite controles para el estándar administrado por el servicio: AWS Control Tower, el CSPM de Security Hub puede tardar hasta 18 horas en generar resultados para los controles que utilizan una regla vinculada al servicio de AWS Config ya existente. Si ha habilitado otros estándares y controles en el CSPM de Security Hub, es posible que ya cuente con reglas vinculadas al servicio. Para obtener más información, consulte Programación para ejecutar comprobaciones de seguridad.
Eliminación de la norma
Para eliminar este estándar en AWS Control Tower desactive todos los controles aplicables mediante uno de los métodos siguientes:
-
AWS Control TowerConsola de
-
API de AWS Control Tower (llame a la API de
DisableControl) -
AWS CLI (ejecutar el comando
disable-control)
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 AWS Control Tower, lo elimina de la página Estándares de la consola del CSPM de Security Hub, y ya no podrá acceder a este mediante la API o la AWS CLI del CSPM de Security Hub.
nota
La desactivación de todos los controles del estándar en el CSPM de Security Hub no desactiva ni elimina el estándar.
Al desactivar el servicio CSPM de Security Hub, se elimina el Estándar administrado por el servicio: AWS Control Tower, y cualquier otro estándar que haya habilitado.
Formato de campo de resultados para Estándar de gestión de servicios: AWS Control Tower
Cuando crea el estándar administrado por el servicio: AWS Control Tower, y habilita sus controles correspondientes, empezará a recibir los resultados de control en el CSPM de Security Hub. El CSPM de Security Hub informa de los resultados de control en el Formato de resultados de seguridad de AWS (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 resultado de el estándar administrado por servicios: AWS Control Tower, consulte Ejemplos de resultados de controles
Controles que se aplican a Estándar de gestión de servicios: AWS Control Tower
Estándar gestionado por el servicio: AWS Control Tower admite un subconjunto de controles que forman parte del estándar AWS Foundational Security Best Practices (FSBP). Elija un control para ver información al respecto, incluidos los pasos para remediar los resultados fallidos.
La siguiente lista muestra los controles disponibles para Estándar de gestión de servicios: 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 consola de AWS Control Tower, los identificadores de control tienen el formato SH. SH.ControlID (por ejemplo, SH.CodeBuild.1). En el CSPM de Security Hub, si los resultados de control consolidados están desactivados en la cuenta, el campo ProductFields.ControlId utiliza el identificador de control basado en estándares. El ID de control basado en estándares 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.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
-
[AutoScaling.2] El grupo Amazon EC2 Auto Scaling debe cubrir varias zonas de disponibilidad
-
[CloudTrail.2] CloudTrail debe tener habilitado el cifrado en reposo
-
[CloudTrail.4] La validación de archivo de registro de CloudTrail debe estar habilitada
-
[CloudTrail.5] Las rutas de CloudTrail deben integrarse con Registros de Amazon CloudWatch
-
[CodeBuild.3] Los registros de CodeBuild S3 deben estar cifrados
-
[CodeBuild.4] Los entornos del proyecto CodeBuild deben tener una duración de registro de AWS Config
-
[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.3] Los clústeres de DynamoDB Accelerator (DAX) deben cifrarse en reposo
-
[EC2.1] Las instantáneas de Amazon EBS no se deben poder restaurar públicamente
-
[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.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.19] Los grupos de seguridad no deben permitir el acceso ilimitado a los puertos de alto riesgo
-
[EC2.20] Ambos túneles de VPN de una conexión de AWS Site-to-Site VPN deben 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
-
[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.2] Los servicios de ECS no deberían tener direcciones IP públicas asignadas automáticamente
-
[ECS.4] Los contenedores de ECS deben ejecutarse sin privilegios
-
[ECS.8] Los secretos no deben pasarse como variables de entorno del contenedor
-
[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.4] Los grupos de replicación de ElastiCache deben cifrarse en reposo
-
[ElastiCache.5] Los grupos de replicación de ElastiCache (Redis OSS) deben cifrarse en tránsito
-
[ELB.7] Los equilibradores de carga clásicos deberían tener habilitado el drenaje de conexiones
-
[ELB.10] Equilibrador de carga clásico 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.4] Debe estar habilitado 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
-
[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
-
[KMS.3] AWS KMS keys no debe eliminarse de forma involuntaria
-
[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 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.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
-
[Opensearch.1] Los dominios de OpenSearch deben tener activado el cifrado en reposo
-
[Opensearch.2] Los dominios de OpenSearch no deben ser de acceso público
-
Los dominios de OpenSearch [Opensearch.3] deben cifrar los datos enviados entre nodos
-
Los dominios de OpenSearch [Opensearch.5] deben tener habilitado el registro de auditoría
-
Los dominios de OpenSearch [Opensearch.6] deben tener al menos tres nodos de datos
-
Los dominios de OpenSearch [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]
-
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
-
Los clústeres de Redshift [Redshift.7] deberían utilizar un enrutamiento de VPC mejorado
-
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] En las solicitudes de los buckets de uso general de S3, se debe pedir el uso de 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 buckets de uso general de S3 deben cifrarse en reposo con AWS KMS keys
-
Las instancias de cuaderno de SageMaker [SageMaker.2] deben lanzarse en una VPC personalizada
-
Los usuarios [SageMaker.3] no deberían tener acceso raíz a las instancias del cuaderno de SageMaker
-
[SecretsManager.3] Eliminar los secretos de Secrets Manager no utilizados
-
Los secretos de Secrets Manager [SecretsManager.4] deben renovarse en un número específico de días
-
[SSM.1] Las instancias de Amazon EC2 deben administrarse mediante AWS Systems Manager
-
Las reglas de AWS WAF [WAF.2] Regionales clásicas deben tener al menos una condición
-
Los grupos de reglas de AWS WAF [WAF.3] Regionales clásicos deben tener al menos una regla
-
Las ACL web de AWS WAF [WAF.4] Regionales clásicas deben tener al menos una regla o grupo de reglas
-
Las ACL web de AWS WAF [WAF.10] deben tener al menos una regla o grupo de reglas
Para obtener más información sobre este estándar, consulte Controles del CSPM de Security Hub en la Guía del usuario de AWS Control Tower.