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á.

AWS Padrão básico de melhores práticas de segurança no Security Hub CSPM

Desenvolvido por profissionais do setor AWS e por profissionais do setor, o padrão AWS Foundational Security Best Practices (FSBP) é uma compilação das melhores práticas de segurança para organizações, independentemente do setor ou tamanho da organização. Ele fornece um conjunto de controles que detectam quando Contas da AWS e os recursos se desviam das melhores práticas de segurança. Ele também fornece orientações prescritivas sobre como aprimorar e manter a postura de segurança da sua organização.

No AWS Security Hub CSPM, o padrão AWS Foundational Security Best Practices inclui controles que avaliam continuamente suas cargas de trabalho Contas da AWS e ajudam você a identificar áreas que se desviam das melhores práticas de segurança. Os controles incluem as melhores práticas de segurança para recursos de vários Serviços da AWS. Cada controle recebe uma categoria que reflete a função de segurança à qual ele se aplica. Para obter uma lista de categorias e detalhes adicionais, consulte Categorias de controle.

Controles que se aplicam ao padrão

A lista a seguir especifica quais controles CSPM do AWS Security Hub se aplicam ao padrão AWS Foundational Security Best Practices (v1.0.0). Para revisar os detalhes de um controle, escolha o controle.

[Account.1] As informações de contato de segurança devem ser fornecidas para umConta da AWS

[ACM.1] Importado e ACM-issued os certificados devem ser renovados após um período de tempo especificado

[ACM.2] Os certificados RSA gerenciados pelo ACM devem usar um comprimento de chave de pelo menos 2.048 bits

[APIGateway.1] O REST do API Gateway e o registro de execução WebSocket da API devem estar habilitados

[APIGateway.2] Os estágios da API Gateway REST da API devem ser configurados para usar certificados SSL para autenticação de back-end

[APIGateway.3] Os estágios da API Gateway REST da API devem terAWS X-Rayrastreamento ativado

[APIGateway.4] O API Gateway deve ser associado a uma WAF Web ACL

[APIGateway.5] API Gateway REST Os dados do cache da API devem ser criptografados em repouso

[APIGateway.8] As rotas do API Gateway devem especificar um tipo de autorização

[APIGateway.9] O registro de acesso deve ser configurado para os estágios do API Gateway V2

[APIGateway.10] As integrações do API Gateway V2 devem usar HTTPS para conexões privadas

[APIGateway.11] Os nomes de domínio do API Gateway devem usar as políticas de segurança recomendadas

[AppSync.1]AWS AppSyncOs caches de API devem ser criptografados em repouso

[AppSync.2]AWS AppSyncdeve ter o registro em nível de campo ativado

[AppSync.5]AWS AppSyncAs APIs do GraphQL não devem ser autenticadas com chaves de API

[AppSync.6]AWS AppSyncOs caches de API devem ser criptografados em trânsito

[Athena.4] Os grupos de trabalho do Athena devem ter o registro ativado

[AutoScaling.1] Grupos de Auto Scaling associados a um balanceador de carga devem usar verificações de integridade do ELB

[AutoScaling.2] O grupo Amazon EC2 Auto Scaling deve abranger várias zonas de disponibilidade

[AutoScaling.3] As configurações de lançamento de grupos do Auto Scaling devem configurar as instâncias do EC2 para exigir o Instance Metadata Service Version 2 (IMDSv2)

[Autoscaling.5] As instâncias do Amazon EC2 lançadas usando as configurações de execução em grupo do Auto Scaling não devem ter endereços IP públicos

[AutoScaling.6] Os grupos de Auto Scaling devem usar vários tipos de instância em várias zonas de disponibilidade

[AutoScaling.9] Os grupos do Amazon EC2 Auto Scaling devem usar os modelos de lançamento do Amazon EC2

[Backup.1]AWS Backupos pontos de recuperação devem ser criptografados em repouso

[BedrockAgentCore.1] Os AgentCore tempos de execução do Bedrock devem ser configurados com o modo de rede VPC

[BedrockAgentCore.2] Os Bedrock AgentCore Gateways devem exigir autorização para solicitações de entrada

[BedrockAgentCore.5] Os navegadores AgentCore personalizados Bedrock não devem usar o modo de rede pública

[BedrockAgentCore.6] Os navegadores AgentCore personalizados do Bedrock devem ter a gravação de sessão ativada

[CloudFormation.3] CloudFormation as pilhas devem ter a proteção de encerramento ativada

[CloudFormation.4] CloudFormation as pilhas devem ter funções de serviço associadas

[CloudFront.1] CloudFront as distribuições devem ter um objeto raiz padrão configurado

[CloudFront.3] CloudFront as distribuições devem exigir criptografia em trânsito

[CloudFront.4] CloudFront as distribuições devem ter o failover de origem configurado

[CloudFront.5] CloudFront as distribuições devem ter o registro ativado

[CloudFront.6] CloudFront as distribuições devem ter o WAF ativado

[CloudFront.7] CloudFront as distribuições devem usar certificados personalizados SSL/TLS

[CloudFront.8] CloudFront as distribuições devem usar o SNI para atender às solicitações HTTPS

[CloudFront.9] CloudFront as distribuições devem criptografar o tráfego para origens personalizadas

[CloudFront.10] CloudFront as distribuições não devem usar protocolos SSL obsoletos entre pontos de presença e origens personalizadas

[CloudFront.12] CloudFront as distribuições não devem apontar para origens inexistentes do S3

[CloudFront.13] CloudFront as distribuições devem usar o controle de acesso de origem

[CloudFront.15] CloudFront as distribuições devem usar a política de segurança TLS recomendada

[CloudFront.16] CloudFront as distribuições devem usar o controle de acesso de origem para origens de URL da função Lambda

[CloudFront.17] CloudFront as distribuições devem usar grupos de chaves confiáveis para URLs e cookies assinados

[CloudTrail.1] CloudTrail deve ser ativado e configurado com pelo menos uma trilha multirregional que inclua eventos de gerenciamento de leitura e gravação

[CloudTrail.2] CloudTrail deve ter a criptografia em repouso ativada

[CloudTrail.4] a validação do arquivo de CloudTrail log deve estar ativada

[CloudTrail.5] CloudTrail trilhas devem ser integradas com o Amazon CloudWatch Logs

[CodeBuild.1] Os URLs do repositório CodeBuild de origem do Bitbucket não devem conter credenciais confidenciais

[CodeBuild.2] as variáveis de ambiente CodeBuild do projeto não devem conter credenciais de texto não criptografado

[CodeBuild.3] CodeBuild Os registros do S3 devem ser criptografados

[CodeBuild.4] os ambientes CodeBuild do projeto devem ter um registroAWS Configduração

[CodeBuild.7] as exportações CodeBuild do grupo de relatórios devem ser criptografadas em repouso

[Cognito.2] Os grupos de identidades do Cognito não devem permitir identidades não autenticadas

[Cognito.3] As políticas de senha para grupos de usuários do Cognito devem ter configurações fortes

[Cognito.4] Os grupos de usuários do Cognito devem ter a proteção contra ameaças ativada com o modo de fiscalização de funções completas para autenticação personalizada

[Cognito.5] O MFA deve ser habilitado para grupos de usuários do Cognito

[Cognito.6] Os grupos de usuários do Cognito devem ter a proteção de exclusão ativada

[Config.1] AWS Config deve ser habilitado e usar a função vinculada ao serviço para registro de recursos

[Connect.2] As instâncias do Connect Customer devem ter o CloudWatch registro ativado

[DataFirehose.1] Os fluxos de entrega do Firehose devem ser criptografados em repouso

[DataSync.1] DataSync as tarefas devem ter o registro ativado

[DMS.1] As instâncias de replicação do Database Migration Service não devem ser públicas

[DMS.6] As instâncias de replicação do DMS devem ter a atualização automática de versões secundárias ativada

[DMS.7] As tarefas de replicação do DMS para o banco de dados de destino devem ter o registro ativado

[DMS.8] As tarefas de replicação do DMS para o banco de dados de origem devem ter o registro ativado

[DMS.9] Os endpoints do DMS devem usar SSL

[DMS.10] Os endpoints do DMS para bancos de dados Neptune devem ter a autorização do IAM habilitada

[DMS.11] Os endpoints DMS para MongoDB devem ter um mecanismo de autenticação habilitado

[DMS.12] Os endpoints DMS para Redis OSS devem ter o TLS habilitado

[DMS.13] As instâncias de replicação do DMS devem ser configuradas para usar várias zonas de disponibilidade

[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 snapshots manuais do cluster do Amazon DocumentDB não devem ser públicos

[DocumentDB.4] Os clusters do Amazon DocumentDB devem publicar registros de auditoria no Logs CloudWatch

[DocumentDB.5] Os clusters do Amazon DocumentDB devem ter a proteção contra exclusão ativada

[DocumentDB.6] Os clusters do Amazon DocumentDB devem ser criptografados em trânsito

[DynamoDB.1] As tabelas do DynamoDB devem escalar automaticamente a capacidade de acordo com a demanda

[DynamoDB.2] As tabelas do DynamoDB devem ter a recuperação pontual ativada

[DynamoDB.3] Os clusters do DynamoDB Accelerator (DAX) devem ser criptografados em repouso

[DynamoDB.6] As tabelas do DynamoDB devem ter a proteção de exclusão ativada

[DynamoDB.7] Os clusters do DynamoDB Accelerator devem ser criptografados em trânsito

[EC2.1] Os snapshots do Amazon EBS não devem ser configurados para serem restauráveis publicamente

[EC2.2] Os grupos de segurança padrão da VPC não devem permitir tráfego de entrada ou saída

[EC2.3] Os volumes anexados do Amazon EBS devem ser criptografados em repouso

[EC2.4] As instâncias EC2 interrompidas devem ser removidas após um período de tempo especificado

[EC2.6] O registro de fluxo de VPC deve ser ativado em todas as VPCs

[EC2.7] A criptografia padrão do EBS deve estar ativada

[EC2.8] As instâncias do EC2 devem usar o Instance Metadata Service Version 2 (IMDSv2)

[EC2.9] As instâncias do Amazon EC2 não devem ter um endereço IPv4 público

[EC2.10] O Amazon EC2 deve ser configurado para usar endpoints VPC criados para o serviço Amazon EC2

[EC2.15] As sub-redes do Amazon EC2 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] As instâncias do Amazon EC2 não devem usar vários ENIs

[EC2.18] Os grupos de segurança só devem permitir tráfego de entrada irrestrito para portas autorizadas

[EC2.19] Grupos de segurança não devem permitir acesso irrestrito a portas com alto risco

[EC2.20] Ambos os túneis VPN para um AWS Site-to-Site A conexão VPN deve estar ativa

[EC2.21] As ACLs de rede não devem permitir a entrada a partir de 0.0.0. 0/0 para a porta 22 ou porta 3389

[EC2.23] Os Amazon EC2 Transit Gateways não devem aceitar automaticamente solicitações de anexos de VPC

[EC2.24] Os tipos de instância paravirtual do Amazon EC2 não devem ser usados

[EC2.25] Os modelos de lançamento do Amazon EC2 não devem atribuir IPs públicos às interfaces de rede

[EC2.51] Os endpoints do EC2 Client VPN devem ter o registro de conexão do cliente ativado

[EC2.55] As VPCs devem ser configuradas com um endpoint de interface para a API ECR

[EC2.56] As VPCs devem ser configuradas com um endpoint de interface para o Docker Registry

[EC2.57] As VPCs devem ser configuradas com um endpoint de interface para Systems Manager

[EC2.58] As VPCs devem ser configuradas com um endpoint de interface para os contatos do Systems Manager Incident Manager

[EC2.60] As VPCs devem ser configuradas com um endpoint de interface para o Systems Manager Incident Manager

[EC2.170] Os modelos de lançamento do EC2 devem usar o Instance Metadata Service Version 2 (IMDSv2)

[EC2.171] As conexões EC2 VPN devem ter o registro ativado

[EC2.172] As configurações do EC2 VPC Block Public Access devem bloquear o tráfego do gateway de internet

[EC2.173] Solicitações do EC2 Spot Fleet com parâmetros de inicialização devem habilitar a criptografia para volumes anexados do EBS

[EC2.180] As interfaces de rede EC2 devem ter a source/destination verificação ativada

[EC2.181] Os modelos de lançamento do EC2 devem permitir a criptografia para volumes anexados do EBS

[EC2.182] As configurações de bloqueio de acesso público devem ser habilitadas para snapshots do Amazon EBS

[EC2.183] As conexões VPN EC2 devem usar o protocolo IKEv2

[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.5] As definições de tarefas do ECS devem configurar os contêineres para serem limitados ao acesso somente de leitura aos sistemas de arquivos raiz

[ECS.8] Os segredos não devem ser passados como variáveis de ambiente do contêiner

[ECS.9] As definições de tarefas do ECS devem ter uma configuração de registro

[ECS.10] Os serviços ECS Fargate devem ser executados na versão mais recente da plataforma Fargate

[ECS.12] Os clusters do ECS devem usar o Container Insights

[ECS.16] Os conjuntos de tarefas do ECS não devem atribuir automaticamente endereços IP públicos

[ECS.18] As definições de tarefas do ECS devem usar criptografia em trânsito para volumes EFS

[ECS.19] Os provedores de capacidade do ECS devem ter a proteção gerenciada de terminação ativada

[ECS.20] As definições de tarefas do ECS devem configurar usuários não raiz nas definições de contêiner Linux

[ECS.21] As definições de tarefas do ECS devem configurar usuários não administradores nas definições de contêiner do Windows

[EFS.1] O Elastic File System deve ser configurado para criptografar dados de arquivos em repouso usandoAWS KMS

[EFS.2] Os volumes do Amazon EFS devem estar em planos de backup

[EFS.3] Os pontos de acesso do EFS devem impor um diretório raiz

[EFS.4] Os pontos de acesso do EFS devem impor uma identidade de usuário

[EFS.6] Os destinos de montagem do EFS não devem ser associados a sub-redes que atribuem endereços IP públicos na inicialização

[EFS.7] Os sistemas de arquivos EFS devem ter backups automáticos habilitados

[EFS.8] Os sistemas de arquivos EFS devem ser criptografados em repouso

[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

[EKS.3] Os clusters EKS devem usar segredos criptografados do Kubernetes

[EKS.8] Os clusters EKS devem ter o registro de auditoria ativado

[EKS.9] Os grupos de nós do EKS devem ser executados em uma versão compatível do Kubernetes

[ElastiCache.1] Os clusters ElastiCache (Redis OSS) devem ter backups automáticos habilitados

[ElastiCache.2] ElastiCache os clusters devem ter atualizações automáticas de versões secundárias habilitadas

[ElastiCache.3] os grupos ElastiCache de replicação devem ter o failover automático ativado

[ElastiCache.4] os grupos ElastiCache de replicação devem ser criptografados em repouso

[ElastiCache.5] os grupos ElastiCache de replicação devem ser criptografados em trânsito

[ElastiCache.6] ElastiCache (Redis OSS) grupos de replicação de versões anteriores devem ter o Redis OSS AUTH ativado

[ElastiCache.7] ElastiCache os clusters não devem usar o grupo de sub-rede padrão

[ElasticBeanstalk.1] Os ambientes do Elastic Beanstalk devem ter os relatórios de saúde aprimorados habilitados

[ElasticBeanstalk.2] As atualizações da plataforma gerenciada do Elastic Beanstalk devem estar habilitadas

[ElasticBeanstalk.3] O Elastic Beanstalk deve transmitir registros para CloudWatch

[ELB.1] O Application Load Balancer deve ser configurado para redirecionar todas as solicitações HTTP para HTTPS

[ELB.2] Os balanceadores de carga clássicos com SSL/HTTPS ouvintes devem usar um certificado fornecido porGerenciador de certificados da AWS

[ELB.3] Os ouvintes do Classic Load Balancer devem ser configurados com terminação HTTPS ou TLS

[ELB.4] O Application Load Balancer deve ser configurado para eliminar cabeçalhos http inválidos

[ELB.5] O registro de aplicativos e balanceadores de carga clássicos deve estar ativado

[ELB.6] Os balanceadores de carga de aplicativos, gateways e redes devem ter a proteção contra exclusão ativada

[ELB.7] Os balanceadores de carga clássicos devem ter a drenagem de conexão ativada

[ELB.8] Os balanceadores de carga clássicos com ouvintes SSL devem usar uma política de segurança predefinida que seja forteAWS Configduração

[ELB.9] Os balanceadores de carga clássicos devem ter o balanceamento de carga entre zonas ativado

[ELB.10] O Classic Load Balancer deve abranger várias zonas de disponibilidade

[ELB.12] O Application Load Balancer deve ser configurado com o modo de mitigação de dessincronização defensivo ou mais rigoroso

[ELB.13] Os balanceadores de carga de aplicativos, redes e gateways devem abranger várias zonas de disponibilidade

[ELB.14] O Classic Load Balancer deve ser configurado com o modo de mitigação de dessincronização defensivo ou mais rigoroso

[ELB.17] Os balanceadores de carga de aplicativos e redes com ouvintes devem usar as políticas de segurança recomendadas

[ELB.18] Os ouvintes do Application and Network Load Balancer devem usar protocolos seguros para criptografar dados em trânsito

[ELB.21] Os grupos-alvo do Application and Network Load Balancer devem usar protocolos de verificação de integridade criptografados

[ELB.22] Os grupos-alvo do ELB devem usar protocolos de transporte criptografados

[EMR.1] Os nós primários do cluster Amazon EMR não devem ter endereços IP públicos

[EMR.2] A configuração de bloqueio de acesso público do Amazon EMR deve estar ativada

[EMR.3] As configurações de segurança do Amazon EMR devem ser criptografadas em repouso

[EMR.4] As configurações de segurança do Amazon EMR devem ser criptografadas em trânsito

[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 acessíveis ao público

[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 CloudWatch nos registros deve estar ativado

[ES.5] Os domínios do Elasticsearch devem ter o registro de auditoria ativado

[ES.6] Os domínios do Elasticsearch devem ter pelo menos três nós de dados

[ES.7] Os domínios do Elasticsearch devem ser configurados com pelo menos três nós principais dedicados

[ES.8] As conexões com os domínios do Elasticsearch devem ser criptografadas usando a política de segurança TLS mais recente

[EventBridge.3] os ônibus de eventos EventBridge personalizados devem ter uma política baseada em recursos anexada

[FSx.1] O FSx para sistemas de arquivos OpenZFS deve ser configurado para copiar tags para backups e volumes

[FSx.2] Os sistemas de arquivos FSx for Lustre devem ser configurados para copiar tags para backups

[FSx.3] FSx para sistemas de arquivos OpenZFS devem ser configurados para implantação Multi-AZ

[FSx.4] O FSx para sistemas de arquivos NetApp ONTAP deve ser configurado para implantação Multi-AZ

[FSx.5] Os sistemas de arquivos FSx for Windows File Server devem ser configurados Multi-AZ para implantação

[Glue.3]AWS Glueas transformações de aprendizado de máquina devem ser criptografadas em repouso

[Glue.4]AWS GlueOs trabalhos do Spark devem ser executados em versões compatíveis doAWS Glue

[GuardDuty.1] GuardDuty deve ser habilitado

[GuardDuty.5] O monitoramento do registro de auditoria do GuardDuty EKS deve estar ativado

[GuardDuty.6] A Proteção GuardDuty Lambda deve estar ativada

[GuardDuty.7] O monitoramento de tempo de execução do GuardDuty EKS deve estar ativado

[GuardDuty.8] A proteção contra GuardDuty malware para EC2 deve estar ativada

[GuardDuty.9] A proteção GuardDuty do RDS deve estar ativada

[GuardDuty.10] A proteção GuardDuty S3 deve estar ativada

[GuardDuty.11] O monitoramento GuardDuty do tempo de execução deve estar ativado

[GuardDuty.12] O monitoramento de tempo GuardDuty de execução do ECS deve estar ativado

[GuardDuty.13] O monitoramento de tempo de execução do GuardDuty EC2 deve estar ativado

[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 trocadas a cada 90 dias ou menos

[IAM.4] A chave de acesso do usuário raiz do IAM não deve existir

[IAM.5] O MFA deve ser habilitado para todos os usuários do IAM que tenham uma senha de console

[IAM.6] O MFA de hardware deve estar habilitado para o usuário root

[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

[IAM.21] As políticas gerenciadas pelo cliente do IAM que você cria não devem permitir ações curinga para serviços

[Inspector.1] A digitalização do Amazon Inspector EC2 deve estar ativada

[Inspector.2] O escaneamento ECR do Amazon Inspector deve estar ativado

[Inspector.3] A digitalização de código do Amazon Inspector Lambda deve estar ativada

[Inspector.4] O escaneamento padrão do Amazon Inspector Lambda deve estar ativado

[Kinesis.1] Os streams do Kinesis devem ser criptografados em repouso

[Kinesis.3] Os Kinesis Streams devem ter um período de retenção de dados adequado

[KMS.1] As políticas gerenciadas pelo cliente do IAM não devem permitir ações de descriptografia em todas as chaves do KMS

[KMS.2] Os diretores do IAM não devem ter políticas embutidas do IAM que permitam ações de descriptografia em todas as chaves do KMS

[KMS.3]AWS KMS keysnão deve ser excluído acidentalmente

[KMS.5] As chaves KMS não devem estar acessíveis ao público

[Lambda.1] As políticas da função Lambda devem proibir o acesso público

[Lambda.2] As funções Lambda devem usar tempos de execução compatíveis

[Lambda.5] As funções VPC Lambda devem operar em várias zonas de disponibilidade

[Macie.1] O Amazon Macie deve estar ativado

[Macie.2] A descoberta automatizada de dados confidenciais do Macie deve ser ativada

[MQ.2] Os corretores do ActiveMQ devem transmitir os registros de auditoria para CloudWatch

[MSK.1] Os clusters MSK devem ser criptografados em trânsito entre os nós do broker

[MSK.3] Os conectores MSK Connect devem ser criptografados em trânsito

[MSK.4] Os clusters MSK devem ter o acesso público desativado

[MSK.5] Os conectores MSK devem ter o registro ativado

[MSK.6] Os clusters MSK devem desativar o acesso não autenticado

[Neptune.1] Os clusters de banco de dados Neptune devem ser criptografados em repouso

[Neptune.2] Os clusters de banco de dados Neptune devem publicar registros de auditoria no Logs CloudWatch

[Neptune.3] Os instantâneos do cluster de banco de dados 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 Neptune devem ter backups automatizados habilitados

[Neptune.6] Os instantâneos do cluster de banco de dados Neptune devem ser criptografados em repouso

[Neptune.7] Os clusters de banco de dados Neptune devem ter a autenticação de banco de dados do IAM habilitada

[Neptune.8] Os clusters de banco de dados Neptune devem ser configurados para copiar tags para instantâneos

[NetworkFirewall.2] O registro do Firewall de Rede deve estar ativado

[NetworkFirewall.3] As políticas de Firewall de Rede devem ter pelo menos um grupo de regras associado

[NetworkFirewall.4] A ação sem estado padrão para políticas de Firewall de Rede deve ser descartar ou encaminhar pacotes completos

[NetworkFirewall.5] A ação sem estado padrão para políticas de Firewall de Rede deve ser descartar ou encaminhar para pacotes fragmentados

[NetworkFirewall.6] O grupo de regras do Stateless Network Firewall não deve estar vazio

[NetworkFirewall.9] Os firewalls do Network Firewall devem ter a proteção contra exclusão ativada

[NetworkFirewall.10] Os firewalls do Firewall de Rede devem ter a proteção contra alterações de sub-rede ativada

[Opensearch.1] os OpenSearch domínios devem ter a criptografia em repouso ativada

[Opensearch.2] os OpenSearch domínios não devem ser acessíveis ao público

[Opensearch.3] os OpenSearch domínios devem criptografar os dados enviados entre os nós

[Opensearch.4] OpenSearch o registro de erros de domínio CloudWatch nos registros deve estar ativado

[Opensearch.5] os OpenSearch domínios devem ter o registro de auditoria ativado

[Opensearch.6] os OpenSearch domínios devem ter pelo menos três nós de dados

[Opensearch.7] os OpenSearch domínios devem ter um controle de acesso refinado ativado

[Opensearch.8] As conexões com OpenSearch domínios devem ser criptografadas usando a política de segurança TLS mais recente

[Opensearch.10] os OpenSearch domínios devem ter a atualização de software mais recente instalada

[PCA.1]CA privada da AWSa autoridade de certificação raiz deve ser desativada

[Route53.2] As zonas hospedadas públicas do Route 53 devem registrar consultas de DNS

[RDS.1] O instantâneo do RDS deve ser privado

[RDS.2] As instâncias de banco de dados do RDS devem proibir o acesso público, conforme determinado pela configuração PubliclyAccessible

[RDS.3] As instâncias de banco de dados do RDS devem ter a criptografia em repouso ativada

[RDS.4] Os instantâneos do cluster do RDS e os instantâneos do banco de dados devem ser criptografados em repouso

[RDS.5] As instâncias de banco de dados do RDS devem ser configuradas com várias zonas de disponibilidade

[RDS.6] O monitoramento aprimorado deve ser configurado para instâncias de banco de dados do RDS

[RDS.7] Os clusters do RDS devem ter a proteção contra exclusão ativada

[RDS.8] As instâncias de banco de dados do RDS devem ter a proteção de exclusão ativada

[RDS.9] As instâncias de banco de dados do RDS devem publicar registros em 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 RDS

[RDS.13] As atualizações automáticas de versões secundárias do RDS devem ser ativadas

[RDS.14] Os clusters do Amazon Aurora devem ter o retrocesso ativado

[RDS.15] Os clusters de banco de dados do RDS devem ser configurados para várias zonas de disponibilidade

[RDS.16] Os clusters de banco de dados Aurora devem ser configurados para copiar tags para DB snapshots

[RDS.17] As instâncias de banco de dados do RDS devem ser configuradas para copiar tags para instantâneos

[RDS.19] As assinaturas existentes de notificação de eventos do RDS devem ser configuradas para eventos críticos de cluster

[RDS.20] As assinaturas existentes de notificação de eventos do RDS devem ser configuradas para eventos críticos de instância de banco de dados

[RDS.21] Uma assinatura de notificações de eventos do RDS deve ser configurada para eventos críticos do grupo de parâmetros do banco de dados

[RDS.22] Uma assinatura de notificações de eventos do RDS deve ser configurada para eventos críticos do grupo de segurança do banco de dados

[RDS.23] As instâncias do RDS não devem usar uma porta padrão do mecanismo de banco de dados

[RDS.24] Os clusters de banco de dados do RDS devem usar um nome de usuário de administrador personalizado

[RDS.25] As instâncias do banco de dados do RDS devem usar um nome de usuário de administrador personalizado

[RDS.27] Os clusters de banco de dados do RDS devem ser criptografados em repouso

[RDS.34] Os clusters de banco de dados Aurora MySQL devem publicar registros de auditoria no Logs CloudWatch

[RDS.35] Os clusters de banco de dados do RDS devem ter a atualização automática de versões secundárias habilitada

[RDS.36] O RDS para instâncias de banco de dados PostgreSQL deve publicar registros em Logs CloudWatch

[RDS.37] Os clusters de banco de dados Aurora PostgreSQL devem publicar registros em Logs CloudWatch

[RDS.40] O RDS para instâncias de banco de dados SQL Server deve publicar registros em Logs CloudWatch

[RDS.41] O RDS para instâncias de banco de dados SQL Server deve ser criptografado em trânsito

[RDS.42] O RDS para instâncias de banco de dados MariaDB deve publicar registros em Logs CloudWatch

[RDS.43] Os proxies de banco de dados do RDS devem exigir criptografia TLS para conexões

[RDS.44] O RDS para instâncias de banco de dados MariaDB deve ser criptografado em trânsito

[RDS.45] Os clusters de banco de dados Aurora MySQL devem ter o registro de auditoria ativado

[RDS.46] As instâncias de banco de dados do RDS não devem ser implantadas em sub-redes públicas com rotas para gateways de internet

[RDS.47] O RDS para clusters de banco de dados PostgreSQL deve ser configurado para copiar tags para DB snapshots

[RDS.48] O RDS para clusters de banco de dados MySQL deve ser configurado para copiar tags para DB snapshots

[RDS.50] Os clusters de banco de dados do RDS devem ter um período de retenção de backup suficiente definido

[RDS.51] Os clusters globais do RDS devem ser executados em uma versão compatível do Aurora MySQL

[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.3] Os clusters do Amazon Redshift devem ter snapshots automáticos habilitados

[Redshift.4] Os clusters do Amazon Redshift devem ter o registro de auditoria ativado

[Redshift.6] O Amazon Redshift deve ter as atualizações automáticas para as versões principais habilitadas

[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.10] Os clusters do Redshift devem ser criptografados em repouso

[Redshift.15] Os grupos de segurança do Redshift devem permitir a entrada na porta do cluster somente de origens restritas

[Redshift.18] Os clusters do Redshift devem ter Multi-AZ implantações habilitadas

[RedshiftServerless.1] Os grupos de trabalho sem servidor do Amazon Redshift devem usar o roteamento de VPC aprimorado

[RedshiftServerless.2] Conexões com grupos de trabalho sem servidor do Redshift devem ser obrigatórias para usar SSL

[RedshiftServerless.3] Os grupos de trabalho sem servidor do Redshift devem proibir o acesso público

[RedshiftServerless.5] Os namespaces Redshift Serverless não devem usar o nome de usuário de administrador padrão

[RedshiftServerless.6] Os namespaces sem servidor do Redshift devem exportar registros para Logs CloudWatch

[S3.1] Os buckets de uso geral do S3 devem ter as configurações de bloqueio de acesso público ativadas

[S3.2] Os buckets de uso geral do S3 devem bloquear o acesso público de leitura

[S3.3] Os buckets de uso geral do S3 devem bloquear o acesso público de gravação

[S3.5] Os buckets de uso geral do S3 devem exigir solicitações para usar SSL

[S3.6] As políticas de bucket de uso geral do S3 devem restringir o acesso a outrosContas 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 de acesso ao servidor ativado

[S3.12] As ACLs não devem ser usadas 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.19] Os pontos de acesso S3 devem ter as configurações de bloqueio de acesso público ativadas

[S3.24] Os pontos de Multi-Region acesso S3 devem ter as configurações de bloqueio de acesso público ativadas

[S3.25] Os buckets de diretório S3 devem ter configurações de ciclo de vida

[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

[SageMaker.4] as variantes de produção de SageMaker endpoints devem ter uma contagem inicial de instâncias maior que 1

[SageMaker.5] SageMaker os modelos devem ter o isolamento de rede ativado

[SageMaker.8] as instâncias do SageMaker notebook devem ser executadas em plataformas compatíveis

[SageMaker.9] as definições de tarefas de qualidade de SageMaker dados devem ter a criptografia de tráfego entre contêineres ativada

[SageMaker.10] as definições de tarefas de explicabilidade do SageMaker modelo devem ter a criptografia de tráfego entre contêineres ativada

[SageMaker.11] as definições de tarefas de qualidade de SageMaker dados devem ter o isolamento de rede ativado

[SageMaker.12] as definições de tarefas de viés de SageMaker modelo devem ter o isolamento de rede ativado

[SageMaker.13] as definições de trabalho de qualidade do SageMaker modelo devem ter a criptografia de tráfego entre contêineres ativada

[SageMaker.14] os cronogramas de SageMaker monitoramento devem ter o isolamento de rede ativado

[SageMaker.15] as definições de tarefas de viés de SageMaker modelo devem ter a criptografia de tráfego entre contêineres ativada

[SageMaker.16] SageMaker os modelos devem usar registro privado em VPC para contêineres primários

[SageMaker.17] SageMaker As lojas off-line do grupo de recursos devem ser criptografadas comAWS KMSkeys

[SageMaker.19] SageMaker os modelos devem usar registro privado na VPC para pipelines de inferência de vários contêineres

[SecretsManager.1] Os segredos do Secrets Manager devem ter a rotação automática ativada

[SecretsManager.2] Os segredos do Secrets Manager configurados com rotação automática devem girar com sucesso

[SecretsManager.3] Remover segredos não utilizados do Secrets Manager

[SecretsManager.4] Os segredos do Secrets Manager devem ser alternados dentro de um determinado número de dias

[ServiceCatalog.1] Os portfólios do Service Catalog devem ser compartilhados em umAWSsomente organização

[SES.3] Os conjuntos de configuração do SES devem ter o TLS ativado para envio de e-mails

[SNS.4] As políticas de acesso a tópicos do SNS não devem permitir o acesso público

[SQS.1] As filas do Amazon SQS devem ser criptografadas em repouso

[SQS.3] As políticas de acesso à fila do SQS não devem permitir acesso público

[SSM.1] As instâncias do Amazon EC2 devem ser gerenciadas porAWS Systems Manager

[SSM.2] As instâncias do Amazon EC2 gerenciadas pelo Systems Manager devem ter um status de conformidade de patch de COMPATÍVEL após a instalação de um patch

[SSM.3] As instâncias do Amazon EC2 gerenciadas pelo Systems Manager devem ter um status de conformidade de associação de COMPATÍVEL

[SSM.4] Os documentos SSM não devem ser públicos

[SSM.6] A automação SSM deve ter o CloudWatch registro ativado

[SSM.7] Os documentos SSM devem ter a configuração de bloqueio de compartilhamento público habilitada

[StepFunctions.1] As máquinas de estado do Step Functions devem ter o registro ativado

[Transfer.2] Os servidores Transfer Family não devem usar o protocolo FTP para conexão de endpoints

[Transfer.3] Os conectores Transfer Family devem ter o registro ativado

[WAF.1]AWS WAFO registro clássico do Global Web ACL deve estar ativado

[WAF.2]AWS WAFAs regras regionais clássicas devem ter pelo menos uma condição

[WAF.3]AWS WAFOs grupos de regras regionais clássicos devem ter pelo menos uma regra

[WAF.4]AWS WAFAs ACLs regionais clássicas da web devem ter pelo menos uma regra ou grupo de regras

[WAF.6]AWS WAFAs regras globais clássicas devem ter pelo menos uma condição

[WAF.7]AWS WAFOs grupos de regras globais clássicos devem ter pelo menos uma regra

[WAF.8]AWS WAFAs ACLs web globais clássicas devem ter pelo menos uma regra ou grupo de regras

[WAF.10]AWS WAFas ACLs da web devem ter pelo menos uma regra ou grupo de regras

[WAF.12]AWS WAFas regras devem ter CloudWatch métricas ativadas

[WorkSpaces.1] os volumes WorkSpaces do usuário devem ser criptografados em repouso

[WorkSpaces.2] os volumes WorkSpaces raiz devem ser criptografados em repouso