National Institute of Standards and Technology (NIST) SP 800-53 Rev. 5

O NIST SP 800-53 Rev. 5 é uma estrutura de segurança cibernética e conformidade desenvolvida pelo National Institute of Standards and Technology (NIST), uma agência que faz parte do Departamento de Comércio dos EUA. Essa estrutura de conformidade ajuda você a proteger a disponibilidade, a confidencialidade e a integridade de seus sistemas de informações e recursos essenciais. Agências e prestadores de serviços do governo federal dos EUA devem estar em conformidade com o NIST SP 800-53 para proteger seus sistemas, mas empresas privadas podem usá-la voluntariamente como uma estrutura orientadora para reduzir o risco de segurança cibernética.

O Security Hub fornece controles que suportam determinados requisitos do NIST SP 800-53. Esses controles são avaliados por meio de verificações de segurança automatizadas. Os controles do Security Hub não suportam os requisitos do NIST SP 800-53 que exigem verificações manuais. Além disso, os controles do Security Hub suportam apenas os requisitos automatizados do NIST SP 800-53, listados como requisitos relacionados nos detalhes de cada controle. Escolha um controle da lista a seguir para ver seus detalhes. No momento, os requisitos relacionados não mencionados nos detalhes do controle não são suportados pelo Security Hub.

Ao contrário de outras estruturas, o NIST SP 800-53 não é prescritivo sobre como seus requisitos devem ser avaliados. Em vez disso, a estrutura fornece diretrizes, e os controles NIST SP 800-53 do Security Hub representam a compreensão do serviço sobre elas.

Se você usar a integração do Security Hub AWS Organizations para gerenciar centralmente várias contas e quiser habilitar em lote o NIST SP 800-53 em todas elas, poderá executar um script de várias contas do Security Hub a partir da conta do administrador.

Para obter mais informações sobre o NIST SP 800-53 Rev. 5, consulte o NIST Computer Security Resource Center.

Controles que se aplicam ao NIST SP 800-53 Rev. 5

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

[A conta.2] Contas da AWS deve fazer parte de uma organização AWS Organizations

[ACM.1] Os certificados importados e emitidos pelo ACM devem ser renovados após um período de tempo especificado

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

[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.5] As APIs AWS AppSync do GraphQL não devem ser autenticadas com chaves de API

[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] os pontos de AWS Backup recuperação devem ser criptografados em repouso

[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] as CloudFront distribuições devem ter o WAF ativado

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

[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

[CloudTrail.1] CloudTrail deve ser habilitado 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 ao Amazon CloudWatch Logs

[CloudWatch.15] CloudWatch os alarmes devem ter ações especificadas configuradas

[CloudWatch.16] os grupos de CloudWatch registros devem ser mantidos por um período de tempo especificado

[CloudWatch.17] ações de CloudWatch alarme devem ser ativadas

[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] Os registros do CodeBuild S3 devem ser criptografados

[CodeBuild.4] ambientes de CodeBuild projeto devem ter uma duração de registro AWS Config

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

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

[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 DMS para MongoDB devem ter um mecanismo de autenticação habilitado

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

[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

[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

[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 ativada point-in-time

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

[DynamoDB.4] As tabelas do DynamoDB devem estar presentes em um plano de backup

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

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

[PCI.EC2.1] Os instantâneos 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

[EC2.12] Os EIPs do Amazon EC2 não utilizados devem ser removidos

[EC2.13] Os grupos de segurança não devem permitir a entrada de 0.0.0.0/0 ou ::/0 na porta 22

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-to-Site devem estar ativos AWS

[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.28] Os volumes do EBS devem ser cobertos por um plano de backup

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

[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

[EFS.1] O Elastic File System deve ser configurado para criptografar dados de arquivos em repouso usando 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 uma sub-rede pública

[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 do EKS devem ter o registro em log de auditoria habilitado

[ElastiCache.1] Os clusters ElastiCache Redis devem ter o backup automático ativado

[ElastiCache.2] ElastiCache para clusters de cache Redis deve ter a atualização automática de versão secundária habilitada

[ElastiCache.3] ElastiCache para grupos de replicação do Redis, o failover automático deve estar ativado

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

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

[ElastiCache.6] ElastiCache para grupos de replicação do Redis antes da versão 6.0 deve usar o Redis AUTH

[ElastiCache.7] os ElastiCache 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

[ELBv2.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 ouvintes 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 eliminar cabeçalhos http

[ELB.5] O registro em log do Classic Load Balancer e Application Load Balancer 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 Classic Load Balancers devem ter a drenagem da conexão ativada

[ELB.8] Os balanceadores de carga clássicos com ouvintes SSL devem usar uma política de segurança predefinida que tenha uma duração forte AWS Config

[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.16] Os balanceadores de carga de aplicativos devem ser associados a uma ACL da web AWS WAF

[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

[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

[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

[EventBridge.4] endpoints EventBridge globais devem ter a replicação de eventos ativada

[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 for Lustre devem ser configurados para copiar tags para backups

[GuardDuty.1] GuardDuty deve ser 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 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.9] A MFA deve estar habilitada para o usuário raiz

[IAM.19] A MFA deve estar habilitada para todos os usuários do IAM

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

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

[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] não AWS KMS keys deve ser excluído acidentalmente

A rotação de AWS KMS teclas [KMS.4] deve estar ativada

[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.3] As funções do Lambda devem estar em uma VPC

[Lambda.5] As funções do Lambda da VPC 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

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

[MSK.2] Os clusters do MSK devem ter monitoramento aprimorado configurado

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

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

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

[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 instantâneos

[Neptune.9] Os clusters de banco de dados do Neptune devem ser implantados em várias zonas de disponibilidade

[NetworkFirewall.1] Os firewalls do Network Firewall devem ser implantados em várias zonas de disponibilidade

[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 Firewall de Rede devem ter a proteção contra exclusão ativada

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

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

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

Os OpenSearch domínios [Opensearch.11] devem ter pelo menos três nós primários dedicados

[PCA.1] a autoridade de certificação AWS Private CA raiz deve ser desativada

[RDS.1] Os instantâneos 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 duração PubliclyAccessible AWS Config

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

[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 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 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.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 RDS devem ser configurados para copiar tags para instantâneos

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

[RDS.18] As instâncias do RDS devem ser implantadas em uma VPC

[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.26] As instâncias de banco de dados do RDS devem ser protegidas por um plano de backup

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

[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 instantâneos 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.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

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

[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 de uso de SSL

[S3.6] As políticas de bucket de uso geral do S3 devem restringir o acesso a outros Contas da AWS

[S3.7] Os buckets de uso geral do S3 devem usar a replicação entre regiões

[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.10] Os buckets de uso geral do S3 com controle de versão ativado devem ter configurações de ciclo de vida

[S3.11] Os buckets de uso geral do S3 devem ter as notificações de eventos ativadas

[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.14] Os buckets de uso geral do S3 devem ter o controle de versão ativado

[S3.15] Os buckets de uso geral do S3 devem ter o Object Lock ativado

[S3.17] Os buckets de uso geral do S3 devem ser criptografados em repouso com AWS KMS keys

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

[S3.20] Os buckets de uso geral do S3 devem ter a exclusão de MFA habilitada

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

[SageMaker.2] instâncias de 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

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

[SNS.1] Os tópicos do SNS devem ser criptografados em repouso usando AWS KMS

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

[SSM.1] As instâncias do Amazon EC2 devem ser gerenciadas por 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

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

[WAF.1] O registro AWS WAF clássico de ACL da Web global deve estar ativado

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

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

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

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

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

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

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

[WAF.11] O registro de ACL AWS WAF da web deve estar ativado

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