Padrão Práticas Recomendadas de Segurança Básica da AWS no CSPM do Security Hub

Desenvolvidas pela AWS e por profissionais do setor, o padrão Práticas Recomendadas de Segurança Básica (FSBP) da AWS é uma compilação das práticas recomendadas de segurança para organizações, de qualquer setor e tamanho. Ele fornece um conjunto de controles que detectam quando suas Contas da AWS e recursos implantados se desviam das práticas recomendadas 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 CSPM do AWS Security Hub, o padrão Práticas Recomendadas de Segurança Básica da AWS inclui controles que avaliam continuamente suas Contas da AWS e workloads e ajudam você a identificar áreas que se desviem das práticas recomendadas 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 do CSPM do AWS Security Hub se aplicam ao padrão Práticas Recomendadas de Segurança Básica da AWS (v1.0.0). Para revisar os detalhes de um controle, escolha o controle.

[Account.1] Informações de contato de segurança devem ser fornecidas para uma Conta da AWS

[ACM.1] Os certificados importados e emitidos pelo ACM 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 registro de execução da API de Gateway, REST e API de WebSocket deve estar ativado

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

[APIGateway.3] Os estágios da API REST de Gateway devem ter o rastreamento AWS X-Ray habilitado

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

[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 de Gateway

[AppSync.1] Os caches da API do AWS AppSync devem ser criptografados em repouso

[AppSync.2] AWS AppSync deve ter o registro em log em nível de campo habilitado

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

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

[Athena.4] Os grupos de trabalho do Athena devem ter o registro em log habilitado

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

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

[AutoScaling.3] As configurações de lançamento em grupo do Auto Scaling devem configurar as instâncias do EC2 para que exijam o Instance Metadata Service versão 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 do Auto Scaling devem usar vários tipos de instância em várias zonas de disponibilidade

Os grupos do Amazon EC2 Auto Scaling devem usar modelos de lançamento do Amazon EC2

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

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

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

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

[CloudFront.5] As distribuições do CloudFront devem ter o registro de log ativado

[CloudFront.6] As distribuições do CloudFront devem ter a WAF ativada

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

[CloudFront.8] As distribuições do CloudFront devem usar a SNI para atender às solicitações HTTPS

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

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

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

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

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

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

[CloudTrail.1] O CloudTrail deve ser habilitado e configurado com pelo menos uma trilha multirregional que inclui eventos de gerenciamento de leitura e salvamento

[CloudTrail.2] O CloudTrail deve ter a criptografia em repouso habilitada

[CloudTrail.4] A validação do arquivo de log do CloudTrail deve estar habilitada

[CloudTrail.5] As trilhas do CloudTrail devem ser integradas ao Amazon CloudWatch Logs

[CodeBuild.1] Os URLs dos repositórios Bitbucket de fontes do CodeBuild não devem conter credenciais confidenciais

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

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

[CodeBuild.4] Os ambientes do projeto CodeBuild devem ter uma configuração de registro em log AWS Config

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

[Cognito.2] Os bancos 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

[Config.1] O AWS Config deve estar habilitado e usar o perfil vinculado ao serviço para gravação de recursos

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

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

[DataSync.1] As tarefas do DataSync devem ter o registro em log habitado

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

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

[DMS.8] As tarefas de replicação do DMS para o banco de dados de origem devem ter o registro em log 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 do DMS para o MongoDB devem ter um mecanismo de autenticação habilitado

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

[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 logs de auditoria no CloudWatch Logs

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

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

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

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

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

[EC2.2] 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.

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

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 da VPC criados para o serviço Amazon EC2

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

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 uma conexão VPN site a site da AWS devem estar ativos

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

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

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

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

[EC2.51] Os endpoints da Client VPN do EC2 devem ter o registro em log de conexão do cliente habilitado

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

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

[EC2.57] As VPCs devem ser configuradas com um endpoint de interface para o 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 inicialização do EC2 devem usar o Instance Metadata Service versão 2 (IMDSv2)

[EC2.171] As conexões de VPN do EC2 devem ter o registro em log habilitado

[EC2.172] As configurações de bloqueio de acesso público à VPC do EC2 devem bloquear o tráfego do gateway da Internet

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

[EC2.180] As interfaces de rede do EC2 devem ter a verificação de origem/destino habilitada

[EC2.181] Os modelos de execução do EC2 devem habilitar a criptografia para volumes anexados do EBS

[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.1] As definições de tarefas do Amazon ECS devem ter modos de rede seguros e definições de usuário

[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] Os contêineres do ECS devem ser limitados ao acesso somente 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 em log

[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 Container Insights

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

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

[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

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

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

[EFS.8] Os sistemas de arquivos do 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 do EKS devem usar segredos criptografados do Kubernetes

[EKS.8] Os clusters do EKS devem ter o registro em log de auditoria habilitado

[ElastiCache.1] Os clusters do ElastiCache (Redis OSS) devem ter o backup automático habilitado

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

[ElastiCache.3] Os grupos de replicação do ElastiCache devem ter o failover automático habilitado

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

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

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

[ElastiCache.7] Os clusters do ElastiCache não devem usar o grupo de sub-redes 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 logs para o CloudWatch

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

[ELB.2] Os Classic Load Balancers com receptores SSL/HTTPS devem usar um certificado fornecido pelo AWS Certificate Manager

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.6] A proteção contra exclusão dos balanceadores de carga de aplicações, gateways e redes deve estar habilitada

[ELB.7] Os Classic Load Balancers devem ter a drenagem da conexão ativada

[ELB.8] Os Classic Load Balancers com receptores SSL devem usar uma política de segurança predefinida que tenha uma configuração AWS Config forte

[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

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

[ELB.13] Balanceadores de carga de aplicações, redes e gateways devem abranger várias zonas de disponibilidade

O Classic Load Balancer deve ser configurado com o modo defensivo ou com o modo de mitigação de dessincronização mais rigoroso

[ELB.17] Application Load Balancers e Network Load Balancers com receptores devem usar as políticas de segurança recomendadas

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

[EMR.1] Os nós primários do cluster do 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 habilitada

[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 publicamente acessíveis

[ES.3] Os domínios do Elasticsearch devem criptografar os dados enviados entre os nós

[ES.4] O registro em log de erros do domínio Elasticsearch no CloudWatch Logs deve ser 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

[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 barramentos de eventos personalizados do EventBridge devem ter uma política baseada em recursos anexada

[FSx.1] Os sistemas de arquivos do Amazon FSx para OpenZFS devem estar configurados para copiar tags para backups e volumes.

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

[FSx.3] Os sistemas de arquivos FSx para OpenZFS devem estar configurados para implantação multi-AZ

[FSx.4] Os sistemas de arquivos NetApp ONTAP devem estar configurados para implantação multi-AZ

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

[Glue.3] As transformações de machine learning do AWS Glue devem ser criptografadas em repouso

[Glue.4] Os trabalhos do AWS Glue Spark devem ser executados em versões com suporte do AWS Glue

[GuardDuty.1] O GuardDuty deve estar habilitado

[GuardDuty.5] O Monitoramento de Logs de Auditoria do EKS do GuardDuty deve estar habilitado

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

[GuardDuty.7] O Monitoramento de Runtime do EKS do GuardDuty deve estar habilitado

[GuardDuty.8] A Proteção contra Malware para EC2 do GuardDuty deve estar habilitada

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

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

[GuardDuty.11] O Monitoramento de Runtime do GuardDuty deve estar habilitado

[GuardDuty.12] O monitoramento de runtime do ECS do GuardDuty deve estar habilitado

[GuardDuty.13] O monitoramento de runtime do EC2 do GuardDuty deve estar habilitado

[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

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

[Inspector.1] A varredura do EC2 do Amazon Inspector deve estar habilitada

[Inspector.2] A varredura do ECR do Amazon Inspector deve estar habilitada

[Inspector.3] A varredura de código do Lambda do Amazon Inspector deve estar habilitada

[Inspector.4] A varredura padrão do Lambda do Amazon Inspector deve estar habilitada

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

[Kinesis.3] Os fluxos do Kinesis 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] As entidades principais do IAM não devem ter políticas incorporadas do IAM que permitam ações de descriptografia em todas as chaves do KMS

[KMS.3] O AWS KMS keys não deve ser excluído acidentalmente

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

[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

[Macie.1] O Amazon Macie deve estar habilitado

[Macie.2] A descoberta automatizada de dados confidenciais do Macie deve estar habilitada

[MQ.2] Os agentes do ActiveMQ devem transmitir os logs de auditoria para o CloudWatch

[MQ.3] Os agentes do Amazon MQ devem ter a atualização automática de versões secundárias habilitada

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

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

[MSK.4] Os clusters do MSK devem ter acesso público desabilitado

[MSK.5] Os conectores do MSK devem ter o registro em log habilitado

[MSK.6] Os clusters do MSK devem desabilitar 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 do Neptune devem publicar logs de auditoria no CloudWatch Logs

[Neptune.3] Os snapshots 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 snapshots 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 do Neptune devem ser configurados para copiar tags para snapshots

[NetworkFirewall.2] O registro em log do Network Firewall deve ser habilitado

[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 pacotes fragmentados.

[NetworkFirewall.6] O grupo de regras de firewall de rede sem estado não deve estar vazio

[NetworkFirewall.9] Os firewalls do firewall de rede devem ter a proteção contra exclusão ativada

[NetworkFirewall.10] Os firewalls do Network Firewall devem ter a proteção contra alteração de sub-rede habilitada

[Opensearch.1] Os domínios do OpenSearch devem ter a criptografia em repouso habilitada

[Opensearch.2] Os domínios do OpenSearch não devem ser publicamente acessíveis

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

[Opensearch.4] O registro em log de erros de domínio do OpenSearch no CloudWatch Logs deve estar ativado

[Opensearch.5] Os domínios do OpenSearch devem ter o registro em log de auditoria ativado

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

[Opensearch.7] Os domínios do OpenSearch devem ter um controle de acesso refinado habilitado

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

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

[PCA.1] a autoridade de certificação raiz CA Privada da AWS deve ser desabilitada

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

[RDS.1] Os snapshots do RDS devem ser privados

[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 habilitada.

[RDS.4] Os snapshots do cluster do RDS e os snapshots 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 RDS devem ter a proteção contra exclusão ativada

[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 logs no CloudWatch Logs

[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.14] Os clusters do Amazon Aurora devem ter o backtracking 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 do Aurora devem ser configurados para copiar tags para snapshots de bancos de dados

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

[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âncias de bancos 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 de 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 do MySQL devem publicar logs de auditoria no CloudWatch Logs

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

[RDS.36] As instâncias de banco de dados do Amazon RDS para PostgreSQL devem publicar logs no CloudWatch Logs

[RDS.37] Os clusters de banco de dados PostgreSQL do Aurora devem publicar logs de auditoria no CloudWatch Logs

[RDS.40] As instâncias de bancos de dados do RDS para SQL Server devem publicar logs no CloudWatch Logs

[RDS.41] As instâncias de banco de dados do RDS para SQL Server devem ser criptografadas em trânsito

[RDS.42] As instâncias de bancos de dados do RDS para MariaDB devem publicar logs no CloudWatch Logs

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

[RDS.44] As instâncias de banco de dados do RDS para MariaDB devem ser criptografadas em trânsito

[RDS.45] Os clusters de banco de dados do Aurora MySQL devem ter o registro em log de auditoria habilitado

[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 da Internet

[RDS.47] Os clusters de banco de dados do RDS para PostgreSQL devem ser configurados para copiar tags para snapshots

[RDS.48] Os clusters de banco de dados do RDS para MySQL devem ser configurados para copiar tags para snapshots

[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.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 somente na porta do cluster de origens restritas

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

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

[RedshiftServerless.2] Conexões com grupos de trabalho do Redshift sem servidor devem ter uso de SSL obrigatório

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

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

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

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

[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 outras 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] As ACLs não devem ser usadas para gerenciar o acesso de usuários a 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 do S3 devem ter configurações de bloqueio do acesso público habilitadas

[S3.24] Os pontos de acesso multirregionais do S3 devem ter as configurações de bloqueio do acesso público habilitadas

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

[SageMaker.1] As instâncias de caderno do Amazon SageMaker não devem ter acesso direto à Internet

[SageMaker.2] As instâncias do notebook SageMaker devem ser iniciadas em uma VPC personalizada

[SageMaker.3] Os usuários não devem ter acesso raiz às instâncias do notebook do SageMaker

[SageMaker.4] As variantes de produção de endpoints do SageMaker devem ter um número inicial de instâncias maior do que 1

[SageMaker.5] Os modelos do SageMaker devem ter o isolamento de rede habilitado

[SageMaker.8] As instâncias de notebook do SageMaker devem ser executadas em plataformas com suporte

Os segredos do Secrets Manager devem ter a alternância automática ativada

Os segredos do Secrets Manager configurados com alternância automática devem girar com sucesso

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

[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 somente dentro de uma organização da AWS

[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 a filas do SQS não devem permitir o acesso público

PCI.SSM.3 As instâncias do Amazon EC2 devem ser gerenciadas pelo AWS Systems Manager

[PCI.SSM.1] As instâncias do Amazon EC2 gerenciadas pelo devem ter um status de conformidade de patch de COMPLIANT (Em conformidade) após a instalação do patch

PCI.SSM.2 As instâncias de 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] O SSM Automation deve ter o registro em log do CloudWatch habilitado

[SSM.7] Os documentos do 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 do Transfer Family não devem usar o protocolo FTP para conexão de endpoints

[Transfer.3] Os conectores do Transfer Family devem ter o registro em log habilitado

[WAF.1]O registro em log AWS WAF Classic Global Web ACL deve estar ativado

[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] As AWS WAF Classic Regional web ACLs devem ter pelo menos uma regra ou grupo de regras

[WAF.6] As regras AWS WAF Classic Regional devem ter pelo menos uma condição

[WAF.7] Os grupos de regras AWS WAF Classic global devem ter pelo menos uma regra

[WAF.8] As web ACLs AWS WAF Classic global devem ter pelo menos uma regra ou grupo de regras

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

[WAF.12] As regras do AWS WAF devem ter as métricas do CloudWatch habilitadas

[WorkSpaces.1] Os volumes de usuários do WorkSpaces devem ser criptografados em repouso

[WorkSpaces. 2] Os volumes-raiz do WorkSpaces devem ser criptografados em repouso