As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Padrão gerenciado por serviços: AWS Control Tower
Esta seção fornece informações sobre o Service-Managed Standard:. AWS Control Tower
O que é o padrão gerenciado por serviços:? AWS Control Tower
Esse padrão foi desenvolvido para usuários do AWS Security Hub Cloud Security Posture Management (CSPM) e. AWS Control Tower Ele permite que você configure os controles proativos AWS Control Tower junto com os controles de detetive do Security Hub CSPM no serviço. AWS Control Tower
Os controles proativos ajudam a garantir que você Contas da AWS mantenha a conformidade, pois sinalizam ações que podem levar a violações de políticas ou configurações incorretas. Os controles de detetive detectam a não conformidade de recursos (por exemplo, configurações incorretas) em sua Contas da AWS. Ao habilitar controles proativos e detectivos para seu AWS ambiente, você pode aprimorar sua postura de segurança em diferentes estágios de desenvolvimento.
dica
Os padrões gerenciados por serviços diferem dos padrões gerenciados pelo AWS Security Hub Cloud Security Posture Management (CSPM). Por exemplo, você deve criar e excluir um padrão gerenciado por serviços no serviço de gerenciamento. Para obter mais informações, consulte Padrões gerenciados de serviços no Security Hub CSPM.
No console e na API do Security Hub CSPM, você pode ver o Service-Managed Standard: junto com outros padrões CSPM do AWS Control Tower Security Hub.
Criando o padrão
Esse padrão estará disponível somente se você criar o padrão em AWS Control Tower. AWS Control Tower cria o padrão quando você ativa pela primeira vez um controle aplicável usando um dos seguintes métodos:
-
AWS Control Tower console
-
AWS Control Tower API (chame a
EnableControl
API) -
AWS CLI (execute o
enable-control
comando)
Os controles CSPM do Security Hub são identificados no AWS Control Tower console como SH. ControlID
(por exemplo, SH. CodeBuild.1).
Ao criar o padrão, se você ainda não tiver habilitado o CSPM do Security Hub, AWS Control Tower também habilita o CSPM do Security Hub para você.
Se você não tiver configurado AWS Control Tower, não poderá visualizar ou acessar esse padrão no console CSPM do Security Hub, na API CSPM do Security Hub ou. AWS CLI Mesmo se você tiver configurado AWS Control Tower, não poderá visualizar ou acessar esse padrão no CSPM do Security Hub sem primeiro criar o padrão AWS Control Tower usando um dos métodos anteriores.
Esse padrão só está disponível Regiões da AWS onde AWS Control Tower está disponível, inclusive AWS GovCloud (US).
Ativando e desativando controles no padrão
Depois de criar o padrão no AWS Control Tower console, você pode ver o padrão e seus controles disponíveis nos dois serviços.
Depois de criar o padrão pela primeira vez, ele não tem nenhum controle ativado automaticamente. Além disso, quando o Security Hub CSPM adiciona novos controles, eles não são habilitados automaticamente para o Service-Managed Standard:. AWS Control Tower Você deve ativar e desativar os controles para o padrão in AWS Control Tower usando um dos seguintes métodos:
-
AWS Control Tower console
-
AWS Control Tower API (chame o
EnableControl
eDisableControl
APIs) -
AWS CLI (execute os
disable-control
comandosenable-control
e)
Quando você altera o status de habilitação de um controle em AWS Control Tower, a alteração também é refletida no CSPM do Security Hub.
No entanto, desabilitar um controle no CSPM do Security Hub que está ativado AWS Control Tower resulta em desvio de controle. O status do controle é AWS Control Tower exibido comoDrifted
. Você pode resolver esse desvio selecionando Registrar novamente a OU no AWS Control Tower console ou desativando e reativando o controle AWS Control Tower usando um dos métodos anteriores.
A conclusão das ações de ativação e desativação AWS Control Tower ajuda a evitar desvios de controle.
Quando você ativa ou desativa os controles em AWS Control Tower, a ação se aplica a todas as contas e regiões. Se você ativar e desativar os controles no CSPM do Security Hub (não recomendado para esse padrão), a ação se aplicará somente à conta atual e à região.
nota
A configuração central não pode ser usada para gerenciar o Service-Managed Standard:. AWS Control Tower Se você usar a configuração central, poderá usar somente o AWS Control Tower serviço para ativar e desativar os controles desse padrão para uma conta gerenciada centralmente.
Visualizando o status da habilitação e o status do controle
Você pode exibir o status de habilitação de um controle usando um dos métodos a seguir:
-
Console CSPM do Security Hub, API CSPM do Security Hub ou AWS CLI
-
AWS Control Tower console
-
AWS Control Tower API para ver uma lista de controles habilitados (chame a
ListEnabledControls
API) -
AWS CLI para ver uma lista de controles habilitados (execute o
list-enabled-controls
comando)
Um controle que você desabilita AWS Control Tower tem um status de habilitação no CSPM do Disabled
Security Hub, a menos que você habilite explicitamente esse controle no CSPM do Security Hub.
O Security Hub CSPM calcula o status do controle com base no status do fluxo de trabalho e no status de conformidade das descobertas do controle. Para obter mais informações sobre o status de habilitação e o status de controle, consulte Analisando os detalhes dos controles no Security Hub CSPM.
Com base nos status de controle, o Security Hub CSPM calcula uma pontuação de segurança para o Service-Managed Standard:. AWS Control Tower Essa pontuação só está disponível no CSPM do Security Hub. Além disso, você só pode visualizar as descobertas de controle no CSPM do Security Hub. A pontuação de segurança padrão e as descobertas de controle não estão disponíveis em AWS Control Tower.
nota
Quando você ativa controles para Service-Managed Standard: AWS Control Tower, o Security Hub CSPM pode levar até 18 horas para gerar descobertas para controles que usam uma regra vinculada ao serviço existente. AWS Config Você pode ter regras vinculadas a serviços existentes se tiver habilitado outros padrões e controles no CSPM do Security Hub. Para obter mais informações, consulte Programar a execução de verificações de segurança.
Excluindo o padrão
Você pode excluir esse padrão AWS Control Tower desativando todos os controles aplicáveis usando um dos seguintes métodos:
-
AWS Control Tower console
-
AWS Control Tower API (chame a
DisableControl
API) -
AWS CLI (execute o
disable-control
comando)
A desativação de todos os controles exclui o padrão em todas as contas gerenciadas e regiões governadas no AWS Control Tower. A exclusão do padrão em o AWS Control Tower remove da página Padrões do console CSPM do Security Hub, e você não pode mais acessá-lo usando a API CSPM do Security Hub ou. AWS CLI
nota
Desabilitar todos os controles do padrão no Security Hub CSPM não desativa nem exclui o padrão.
A desativação do serviço CSPM do Security Hub remove o Service-Managed Standard: AWS Control Tower e quaisquer outros padrões que você tenha habilitado.
Localizando o formato de campo para o Service-Managed Standard: AWS Control Tower
Ao criar o Service-Managed Standard: AWS Control Tower e habilitar controles para ele, você começará a receber descobertas de controle no Security Hub CSPM. O Security Hub CSPM relata as descobertas de controle no. AWS Formato de descoberta de segurança (ASFF) Esses são os valores ASFF para o nome do recurso da Amazon (ARN) desse padrão e GeneratorId
:
-
ARN padrão:
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 obter um exemplo de descoberta do Service-Managed Standard: AWS Control Tower, consulte. Amostras de resultados de controle
Controles que se aplicam ao padrão gerenciado por serviços: AWS Control Tower
Padrão gerenciado por serviços: AWS Control Tower suporta um subconjunto de controles que fazem parte do padrão AWS Foundational Security Best Practices (FSBP). Escolha um controle para visualizar informações sobre ele, incluindo etapas de remediação para descobertas malsucedidas.
A lista a seguir mostra os controles disponíveis para o Service-Managed Standard:. AWS Control Tower Os limites regionais dos controles correspondem aos limites regionais dos controles corolários no padrão FSBP. Essa lista mostra o controle de segurança independente do padrão. IDs No AWS Control Tower console, os controles IDs são formatados como SH. ControlID
(por exemplo, SH. CodeBuild.1). No Security Hub CSPM, se as descobertas de controle consolidadas estiverem desativadas em sua conta, o ProductFields.ControlId
campo usará o ID de controle baseado em padrão. O ID de controle baseado em padrões é formatado como CT. ControlId
(por exemplo, CT. CodeBuild.1).
-
[Conta.1] As informações de contato de segurança devem ser fornecidas para um Conta da AWS
-
[APIGateway.3] Os estágios da API REST de Gateway devem ter o AWS X-Ray rastreamento habilitado
-
[APIGateway.4] O API Gateway deve ser associado a uma ACL da web do WAF
-
[APIGateway.5] Os dados do cache da API REST de Gateway devem ser criptografados em repouso
-
[APIGateway.8] As rotas do API de Gateway devem especificar um tipo de autorização
-
[APIGateway.9] O registro de acesso deve ser configurado para os estágios V2 do API Gateway
-
[AppSync.5] O AWS AppSync APIs GraphQL não deve ser autenticado com chaves de API
-
[AutoScaling.2] O grupo Amazon EC2 Auto Scaling deve abranger várias zonas de disponibilidade
-
[CloudTrail.2] CloudTrail deve ter a criptografia em repouso habilitada
-
[CloudTrail.4] a validação do arquivo de CloudTrail log deve estar habilitada
-
[CloudTrail.5] CloudTrail trilhas devem ser integradas ao Amazon CloudWatch Logs
-
[CodeBuild.3] Os registros do CodeBuild S3 devem ser criptografados
-
[CodeBuild.4] ambientes de CodeBuild projeto devem ter uma duração de registro AWS Config
-
[DMS.1] As instâncias de replicação do Database Migration Service não devem ser públicas
-
[DocumentDB.1] Os clusters do Amazon DocumentDB devem ser criptografados em repouso
-
[DocumentDB.2] Os clusters do Amazon DocumentDB devem ter um período de retenção de backup adequado
-
[DocumentDB.3] Os instantâneos manuais do cluster do Amazon DocumentDB não devem ser públicos
-
[DynamoDB.2] As tabelas do DynamoDB devem ter a recuperação ativada point-in-time
-
[DynamoDB.3] Os clusters do DynamoDB Accelerator (DAX) devem ser criptografados em repouso
-
[EC2.1] Os snapshots do Amazon EBS não devem ser restauráveis publicamente
-
[EC22] Os grupos de segurança padrão da VPC não devem permitir o tráfego de entrada e saída
-
[EC2.3] Os volumes anexados do Amazon EBS devem ser criptografados em repouso.
-
[EC24] EC2 As instâncias interrompidas devem ser removidas após um período de tempo especificado
-
[EC2.6] O registro em log do fluxo de VPC deve ser ativado em todos VPCs
-
[EC2.8] as EC2 instâncias devem usar o Instance Metadata Service versão 2 () IMDSv2
-
[EC2.9] EC2 As instâncias da Amazon não devem ter um endereço público IPv4
-
[EC2.10] A Amazon EC2 deve ser configurada para usar endpoints VPC criados para o serviço Amazon EC2
-
[EC2.15] As EC2 sub-redes da Amazon não devem atribuir automaticamente endereços IP públicos
-
[EC2.16] As listas de controle de acesso à rede não utilizadas devem ser removidas
-
[EC2.17] EC2 As instâncias da Amazon não devem usar várias ENIs
-
[EC2.19] Os grupos de segurança não devem permitir acesso irrestrito a portas com alto risco
-
[EC2.20] Ambos os túneis VPN para uma conexão AWS Site-to-Site VPN devem estar ativos
-
[EC2.21] A rede não ACLs deve permitir a entrada de 0.0.0.0/0 para a porta 22 ou porta 3389
-
[EC2.22] Os grupos de EC2 segurança da Amazon não utilizados devem ser removidos
-
[ECR.1] Os repositórios privados do ECR devem ter a digitalização de imagens configurada
-
[ECR.2] Os repositórios privados do ECR devem ter a imutabilidade da tag configurada
-
[ECR.3] Os repositórios ECR devem ter pelo menos uma política de ciclo de vida configurada
-
[ECS.2] Os serviços do ECS não devem ter endereços IP públicos atribuídos a eles automaticamente
-
[ECS.3] As definições de tarefas do ECS não devem compartilhar o namespace do processo do host
-
[ECS.4] Os contêineres ECS devem ser executados sem privilégios
-
[ECS.8] Os segredos não devem ser passados como variáveis de ambiente do contêiner
-
[ECS.10] Os serviços ECS Fargate devem ser executados na versão mais recente da plataforma Fargate
-
[EFS.2] Os volumes do Amazon EFS devem estar em planos de backup
-
[EFS.3] Os pontos de acesso do EFS devem executar um diretório raiz
-
[EFS.4] Os pontos de acesso do EFS devem executar uma identidade de usuário
-
[EKS.1] Os endpoints do cluster EKS não devem ser acessíveis ao público
-
[EKS.2] Os clusters EKS devem ser executados em uma versão compatível do Kubernetes
-
[ElastiCache.3] os grupos de ElastiCache replicação devem ter o failover automático ativado
-
[ElastiCache.4] os grupos de ElastiCache replicação devem ser criptografados em repouso
-
[ElastiCache.5] os grupos de ElastiCache replicação devem ser criptografados em trânsito
-
Os receptores do Classic Load Balancer devem ser configurados com terminação HTTPS ou TLS
-
[ELB.4] O Application Load Balancer deve ser configurado para descartar cabeçalhos http inválidos
-
[ELB.5] O registro em log do Classic Load Balancer e Application Load Balancer deve estar ativado
-
[ELB.7] Os Classic Load Balancers devem ter a drenagem da conexão ativada
-
[ELB.9] Os Classic Load Balancers devem ter o balanceador de carga entre zonas habilitado
-
[ELB.10] O Classic Load Balancer deve abranger várias zonas de disponibilidade
-
[EMR.1] Os nós primários do cluster do Amazon EMR não devem ter endereços IP públicos
-
[ES.1] Os domínios do Elasticsearch devem ter a criptografia em repouso habilitada.
-
[ES.2] Os domínios do Elasticsearch não devem ser publicamente acessíveis
-
[ES.3] Os domínios do Elasticsearch devem criptografar os dados enviados entre os nós
-
[ES.4] O registro de erros do domínio Elasticsearch nos CloudWatch registros deve estar ativado
-
[ES.5] Os domínios do Elasticsearch devem ter o registro em log de auditoria ativado
-
[ES.6] Os domínios do Elasticsearch devem ter pelo menos três nós de dados
-
[IAM.1] As políticas do IAM não devem permitir privilégios administrativos completos "*"
-
[IAM.2] Os usuários do IAM não devem ter políticas do IAM anexadas
-
[IAM.3] As chaves de acesso dos usuários do IAM devem ser mudadas a cada 90 dias ou menos
-
[IAM.4] A chave de acesso do usuário raiz do IAM não deve existir
-
[IAM.5] A MFA deve estar habilitada para todos os usuários do IAM com uma senha do console
-
[IAM.6] A MFA de hardware deve estar habilitada para o usuário raiz
-
[IAM.7] As políticas de senha para usuários do IAM devem ter configurações fortes
-
[IAM.8] As credenciais de usuário do IAM não utilizadas devem ser removidas
-
[Kinesis.1] Os fluxos do Kinesis devem ser criptografados em repouso
-
[Lambda.1] As funções do Lambda.1 devem proibir o acesso público
-
[Lambda.2] As funções do Lambda devem usar os tempos de execução compatíveis
-
[Lambda.5] As funções do Lambda da VPC devem operar em várias zonas de disponibilidade
-
[MSK.1] Os clusters MSK devem ser criptografados em trânsito entre os nós do agente
-
[MQ.5] Os agentes do ActiveMQ devem usar o modo de implantação ativo/em espera
-
[MQ.6] Os agentes do RabbitMQ devem usar o modo de implantação de cluster
-
[Neptune.1] Os clusters de banco de dados Neptune devem ser criptografados em repouso
-
[Neptune.3] Os instantâneos do cluster de banco de dados do Neptune não devem ser públicos
-
[Neptune.4] Os clusters de banco de dados Neptune devem ter a proteção contra exclusão ativada
-
[Neptune.5] Os clusters de banco de dados do Neptune devem ter backups automatizados habilitados
-
[Neptune.6] Os instantâneos do cluster de banco de dados Neptune devem ser criptografados em repouso
-
[NetworkFirewall.6] O grupo de regras do Firewall de Rede sem estado não deve estar vazio
-
Os OpenSearch domínios [Opensearch.1] devem ter a criptografia em repouso ativada
-
Os OpenSearch domínios [Opensearch.2] não devem ser acessíveis ao público
-
Os OpenSearch domínios [Opensearch.3] devem criptografar os dados enviados entre os nós
-
O registro de erros de OpenSearch domínio [Opensearch.4] nos CloudWatch registros deve estar ativado
-
Os OpenSearch domínios [Opensearch.5] devem ter o registro de auditoria ativado
-
Os OpenSearch domínios [Opensearch.6] devem ter pelo menos três nós de dados
-
Os OpenSearch domínios [Opensearch.7] devem ter um controle de acesso refinado ativado
-
[RDS.3] As instâncias de banco de dados do RDS devem ter a criptografia em repouso habilitada.
-
[RDS.6] O monitoramento aprimorado deve ser configurado para instâncias de banco de dados do RDS
-
[RDS.8] As instâncias de banco de dados do RDS deve ter a proteção contra exclusão habilitada
-
[RDS.9] As instâncias de banco de dados do RDS devem publicar registros no Logs CloudWatch
-
[RDS.10] A autenticação do IAM deve ser configurada para instâncias do RDS
-
[RDS.11] As instâncias do RDS devem ter backups automáticos habilitados
-
[RDS.12] A autenticação do IAM deve ser configurada para clusters do RDS
-
[RDS.13] As atualizações automáticas de versões secundárias do RDS devem ser ativadas
-
[RDS.18] As instâncias do RDS devem ser implantadas em uma VPC
-
[RDS.23] As instâncias do RDS não devem usar uma porta padrão do mecanismo de banco de dados
-
[RDS.27] Os clusters de banco de dados do RDS devem ser criptografados em repouso
-
[PCI.Redshift.1] Os clusters do Amazon Redshift devem proibir o acesso público
-
[Redshift.2] As conexões com os clusters do Amazon Redshift devem ser criptografadas em trânsito
-
[Redshift.4] Os clusters do Amazon Redshift devem ter o registro de auditoria ativado
-
[Redshift.7] Os clusters do Redshift devem usar roteamento de VPC aprimorado
-
[Redshift.8] Os clusters do Amazon Redshift não devem usar o nome de usuário Admin padrão
-
[Redshift.9] Os clusters do Redshift não devem usar o nome do banco de dados padrão
-
[Redshift.10] Os clusters do Redshift devem ser criptografados em repouso
-
[S3.2] Os buckets de uso geral do S3 devem bloquear o acesso público para leitura
-
[S3.3] Os buckets de uso geral do S3 devem bloquear o acesso público para gravação
-
[S3.5] Os buckets de uso geral do S3 devem exigir que as solicitações usem SSL
-
[S3.6] As políticas de bucket de uso geral do S3 devem restringir o acesso a outros Contas da AWS
-
[S3.8] Os buckets de uso geral do S3 devem bloquear o acesso público
-
[S3.9] Os buckets de uso geral do S3 devem ter o registro em log de acesso ao servidor habilitado
-
[S3.12] não ACLs deve ser usado para gerenciar o acesso do usuário aos buckets de uso geral do S3
-
[S3.13] Os buckets de uso geral do S3 devem ter configurações de ciclo de vida
-
[S3.17] Os buckets de uso geral do S3 devem ser criptografados em repouso com AWS KMS keys
-
[SageMaker.1] As instâncias de SageMaker notebooks da Amazon não devem ter acesso direto à Internet
-
[SageMaker.2] as instâncias do SageMaker notebook devem ser iniciadas em uma VPC personalizada
-
[SageMaker.3] Os usuários não devem ter acesso root às instâncias do SageMaker notebook
-
[SecretsManager.1] Os segredos do Secrets Manager devem ter a rotação automática ativada
-
[SecretsManager.3] Remover segredos não utilizados do Secrets Manager
-
[SQS.1] As filas do Amazon SQS devem ser criptografadas em repouso
-
PCI.SSM.3 As EC2 instâncias da Amazon devem ser gerenciadas pelo AWS Systems Manager
-
[WAF.2] As regras AWS WAF Classic Regional devem ter pelo menos uma condição
-
[WAF.3] Os grupos de regras AWS WAF Classic Regional devem ter pelo menos uma regra
-
[WAF.4] A web do AWS WAF Classic Regional ACLs deve ter pelo menos uma regra ou grupo de regras
-
[WAF.10] A AWS WAF web ACLs deve ter pelo menos uma regra ou grupo de regras
Para obter mais informações sobre esse padrão, consulte Controles CSPM do Security Hub no Guia do AWS Control Tower Usuário.