Como corrigir as descobertas da análise de integridade de segurança

Esta página fornece uma lista de guias de referência e técnicas para corrigir descobertas do Security Health Analytics usando o Security Command Center.

Você precisa de papéis adequados de gerenciamento de identidade e acesso (IAM, na sigla em inglês) para visualizar ou editar as descobertas e acessar ou modificar recursos do Google Cloud. Se você encontrar erros de permissão ao acessar o Security Command Center no console do Google Cloud, peça ajuda ao administrador e, para saber mais sobre papéis, consulte Controle de acesso. Para resolver erros de recursos, leia a documentação dos produtos afetados.

Observação: se você for um cliente Premium e planeja mudar para o nível Standard, recomendamos resolver todas as descobertas antes de alterar seu nível. As descobertas relatadas pelos detectores Premium não podem ser resolvidas automaticamente no nível Standard. Para mais informações, consulte Como alternar entre os níveis.

Reversão do Security Health Analytics

Esta seção inclui instruções de correção para todas as descobertas do Security Health Analytics.

Para tipos de descoberta mapeados para comparativos de mercado do CIS, a orientação de correção vem do Center for Internet Security (CIS, na sigla em inglês), a menos que indicado de outra forma. Para mais informações, consulte Detectores e compliance.

Cuidado: alterar as configurações dos recursos incorretamente pode afetar negativamente o ambiente de produção. Além disso, ativar alguns serviços sugeridos do Google Cloud pode aumentar os custos com a nuvem. Entenda o impacto de todas as etapas de correção antes de fazer alterações.

Desativação das descobertas após a correção

Depois de corrigir uma vulnerabilidade ou uma configuração incorreta, o Security Health Analytics define automaticamente o estado da descoberta como INACTIVE na próxima vez que ela for verificada. O tempo que o Security Health Analytics leva para definir uma descoberta corrigida como INACTIVE depende quando a descoberta é corrigida e a programação da verificação que detecta a descoberta.

O Security Health Analytics também define o estado de uma descoberta como INACTIVE quando uma verificação detecta que o recurso afetado pela descoberta é excluído. Se você quiser remover uma descoberta de um recurso excluído da sua exibição enquanto aguarda a Análise de Integridade de Segurança detectar que o recurso foi excluído, desative a descoberta. Para desativar o som de uma descoberta, consulte Desativar som de descobertas no Security Command Center.

Não use o silenciamento para ocultar as descobertas corrigidas de recursos atuais. Se o problema ocorrer novamente e o Security Health Analytics restaurar o estado ACTIVE da descoberta, talvez ela não seja reativada, porque as descobertas silenciadas são excluídas de qualquer consulta de descoberta que especifique NOT mute="MUTED", como a consulta de descoberta padrão.

Para informações sobre intervalos de verificação, consulte Tipos de verificação do Security Health Analytics.

Access Transparency disabled

Nome da categoria na API: ACCESS_TRANSPARENCY_DISABLED

Registros de Transparência no acesso quando funcionários do Google Cloud acessam os projetos da sua organização para fornecer suporte. Ative a Transparência no acesso para registrar quem do Google Cloud está acessando suas informações, quando e por quê. Para mais informações, consulte Transparência no acesso.

Para ativar a Transparência no acesso em um projeto, ele precisa estar associado a uma conta de faturamento.

Funções exigidas

Para receber as permissões necessárias para executar essa tarefa, peça ao administrador para conceder a você o papel do IAM Administrador da Transparência no acesso (roles/axt.admin) no nível da organização. Para mais informações sobre como conceder papéis, consulte Gerenciar acesso.

Esse papel predefinido contém as permissões axt.labels.get e axt.labels.set, que são necessárias para executar essa tarefa. Também é possível conseguir essas permissões com um papel personalizado ou outros papéis predefinidos.

Etapas de correção

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Verifique suas permissões no nível da organização:

   1. Acesse a página Identity and Access Management no console do Google Cloud.

      Acessar o Identity and Access Management

   2. Se for solicitado, selecione a organização do Google Cloud no menu seletor.

2. Selecione qualquer projeto do Google Cloud na organização usando o menu seletor.

   A transparência no acesso é configurada em uma página de projeto do Google Cloud, mas a transparência está ativada para toda a organização.

3. Acesse a página IAM e Administrador > Configurações.

4. Clique em Ativar Transparência no acesso.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

AlloyDB auto backup disabled

Nome da categoria na API: ALLOYDB_AUTO_BACKUP_DISABLED

Um cluster do AlloyDB para PostgreSQL não tem backups automáticos ativados.

Para ajudar a evitar a perda de dados, ative os backups automáticos do cluster. Para mais informações, consulte Configurar backups automáticos adicionais.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página de clusters do AlloyDB para PostgreSQL no console do Google Cloud.

   Acesse os clusters do AlloyDB para PostgreSQL

2. Clique em um cluster na coluna Nome do recurso.

3. Clique em Proteção de dados.

4. Na seção Política de backup automatizada, clique em Editar na linha Backups automatizados.

5. Marque a caixa de seleção Backups automáticos.

6. Clique em Atualizar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

AlloyDB backups disabled

Nome da categoria na API: ALLOYDB_BACKUPS_DISABLED

Um cluster do AlloyDB para PostgreSQL não tem backups automáticos nem contínuos ativados.

Para ajudar a evitar a perda de dados, ative os backups automáticos ou contínuos do cluster. Para mais informações, consulte Configurar outros backups.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página de clusters do AlloyDB para PostgreSQL no console do Google Cloud.

   Acesse os clusters do AlloyDB para PostgreSQL

2. Na coluna Nome do recurso, clique no nome do cluster identificado na descoberta.

3. Clique em Proteção de dados.

4. Configure uma política de backup.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

AlloyDB CMEK disabled

Nome da categoria na API: ALLOYDB_CMEK_DISABLED

Um cluster do AlloyDB não está usando chaves de criptografia gerenciadas pelo cliente (CMEK).

Com a CMEK, as chaves que você cria e gerencia no Cloud KMS encapsulam as chaves que o Google usa para criptografar seus dados, oferecendo mais controle sobre o acesso a eles. Para mais informações, consulte Sobre a CMEK. A CMEK gera custos adicionais relacionados ao Cloud KMS.

Atenção: estas etapas de correção podem interromper o ambiente de produção. Se necessário, passe cargas de trabalho, dados ou permissões para novos recursos antes de excluir recursos existentes.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página de clusters do AlloyDB para PostgreSQL no console do Google Cloud.

   Acesse os clusters do AlloyDB para PostgreSQL

2. Na coluna Nome do recurso, clique no nome do cluster identificado na descoberta.

3. Clique em Criar backup. Defina um ID de backup.

4. Clique em Criar.

5. Na seção Backup/Restaurar, clique em Restaurar ao lado da entrada ID do backup escolhida.

6. Defina um novo ID e uma nova rede do cluster.

7. Clique em Opções de criptografia avançadas. Selecione a CMEK que você quer usar para criptografar o novo cluster.

8. Clique em Restaurar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

AlloyDB log min error statement severity

Nome da categoria na API: ALLOYDB_LOG_MIN_ERROR_STATEMENT_SEVERITY

Uma instância do AlloyDB para PostgreSQL não tem a flag de banco de dados log_min_error_statement definida como error ou outro valor recomendado.

A flag log_min_error_statement controla se as instruções SQL que causam condições de erro são registradas nos registros do servidor. As instruções SQL da gravidade especificada ou superior são registradas. Quanto maior a gravidade, menos mensagens são registradas. Se definido como um nível de gravidade muito alto, as mensagens de erro podem não ser registradas.

Para mais informações, consulte Como configurar sinalizações de banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página de clusters do AlloyDB para PostgreSQL no console do Google Cloud.

   Acesse os clusters do AlloyDB para PostgreSQL

2. Clique no cluster na coluna Nome do recurso.

3. Na seção Instâncias no cluster, clique em Editar na instância.

4. Clique em Opções de configuração avançadas.

5. Na seção Flags, defina a flag do banco de dados log_min_error_statement com um dos valores recomendados a seguir, de acordo com a política de geração de registros da organização.

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning
   • error

6. Clique em Atualizar instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

AlloyDB log min messages

Nome da categoria na API: ALLOYDB_LOG_MIN_MESSAGES

Uma instância do AlloyDB para PostgreSQL não tem a flag de banco de dados log_min_messages definida como o mínimo de warning.

A flag log_min_messages controla quais níveis de mensagem são gravados nos registros do servidor. Quanto maior a gravidade, menos mensagens são registradas. Definir o limite muito baixo pode resultar em aumento do tamanho e do comprimento do armazenamento de registros, dificultando a localização de erros reais.

Para mais informações, consulte Como configurar sinalizações de banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página de clusters do AlloyDB para PostgreSQL no console do Google Cloud.

   Acesse os clusters do AlloyDB para PostgreSQL

2. Clique no cluster na coluna Nome do recurso.

3. Na seção Instâncias no cluster, clique em Editar na instância.

4. Clique em Opções de configuração avançadas.

5. Na seção Flags, defina a flag do banco de dados log_min_messages com um dos valores recomendados a seguir, de acordo com a política de geração de registros da organização.

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning

6. Clique em Atualizar instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

AlloyDB log error verbosity

Nome da categoria na API: ALLOYDB_LOG_ERROR_VERBOSITY

Uma instância do AlloyDB para PostgreSQL não tem a flag de banco de dados log_error_verbosity definida como default ou outro valor menos restritivo.

A flag log_error_verbosity controla a quantidade de detalhes nas mensagens registradas. Quanto maior o nível de detalhes, mais informações são gravadas nas mensagens. Recomendamos definir essa flag como default ou outro valor menos restritivo.

Para mais informações, consulte Como configurar sinalizações de banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página de clusters do AlloyDB para PostgreSQL no console do Google Cloud.

   Acesse os clusters do AlloyDB para PostgreSQL

2. Clique no cluster na coluna Nome do recurso.

3. Na seção Instâncias no cluster, clique em Editar na instância.

4. Clique em Opções de configuração avançadas.

5. Na seção Flags, defina a flag do banco de dados log_error_verbosity com um dos valores recomendados a seguir, de acordo com a política de geração de registros da organização.

   • default
   • verbose

6. Clique em Atualizar instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

AlloyDB Public IP

Nome da categoria na API: ALLOYDB_PUBLIC_IP

Uma instância do banco de dados do AlloyDB para PostgreSQL tem um endereço IP público.

Para reduzir a superfície de ataque da organização, use endereços IP particulares em vez de públicos. Endereços IP particulares oferecem maior segurança de rede e menor latência para o aplicativo.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página de clusters do AlloyDB para PostgreSQL no console do Google Cloud.

   Acesse os clusters do AlloyDB para PostgreSQL

2. Na coluna Nome do recurso, clique no nome do cluster identificado na descoberta.

3. Na seção Instâncias no cluster, clique em Editar na instância.

4. Na seção Conectividade, desmarque a caixa Ativar IP público.

5. Clique em Atualizar instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

AlloyDB SSL not enforced

Nome da categoria na API: ALLOYDB_SSL_NOT_ENFORCED

Uma instância de banco de dados do AlloyDB para PostgreSQL não exige que todas as conexões de entrada usem SSL.

Para evitar o vazamento de dados sensíveis em trânsito durante comunicações não criptografadas, todas as conexões de entrada com sua instância do banco de dados do AlloyDB precisam usar o SSL. Saiba mais sobre Como configurar SSL/TLS.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página de clusters do AlloyDB para PostgreSQL no console do Google Cloud.

   Acesse os clusters do AlloyDB para PostgreSQL

2. Na coluna Nome do recurso, clique no nome do cluster identificado na descoberta.

3. Na seção Instâncias no cluster, clique em Editar na instância.

4. Na seção Segurança de rede, clique na caixa Exigir criptografia SSL.

5. Clique em Atualizar instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Admin service account

Nome da categoria na API: ADMIN_SERVICE_ACCOUNT

Uma conta de serviço da organização ou projeto tem privilégios de administrador, proprietário ou editor. Esses papéis têm várias permissões e não devem ser atribuídos a contas de serviço. Para saber mais sobre contas de serviço e os papéis disponíveis, consulte Contas de serviço.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página de políticas do IAM no console do Google Cloud.

   Acesse a política de IAM

2. Para cada membro identificado na descoberta:

   1. Clique em Editar participante ao lado do participante.
   2. Para remover permissões, clique em Excluir papel ao lado do papel.
   3. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Alpha cluster enabled

Nome da categoria na API: ALPHA_CLUSTER_ENABLED

Os recursos do cluster Alfa estão ativados para um cluster do Google Kubernetes Engine (GKE).

Com os clusters Alfa, os usuários iniciais testam cargas de trabalho que usam novos recursos antes de serem lançados para o público em geral. Os clusters Alfa têm todos os recursos da API do GKE ativados, mas não são cobertos peloSLA do GKE. Eles não recebem atualizações de segurança, têm reparação e upgrade automáticos de nós desativados e não podem receber upgrades. Eles também são excluídos automaticamente após 30 dias.

Atenção: estas etapas de correção podem interromper o ambiente de produção. Se necessário, passe cargas de trabalho, dados ou permissões para novos recursos antes de excluir recursos existentes.

Para corrigir essa descoberta, conclua as etapas a seguir:

Não é possível desativar clusters Alfa. É preciso criar um novo cluster com os recursos Alfa desativados.

1. Acesse a página Clusters do Kubernetes no console do Google Cloud.

   Acessar clusters do Kubernetes

2. Clique em Criar.

3. Selecione Configurar ao lado do tipo de cluster que você quer criar.

4. Na guia Recursos, verifique se a opção Ativar recursos Alfa do Kubernetes neste cluster está desativada.

   Observação: Se você selecionou Autopilot do GKE, você não verá essa opção porque os clusters Alfa não são compatíveis.

5. Clique em Criar.

6. Para mover cargas de trabalho para o novo cluster, consulte Como migrar cargas de trabalho para diferentes tipos de máquina.

7. Para excluir o cluster original, consulte Como excluir um cluster.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

API key APIs unrestricted

Nome da categoria na API: API_KEY_APIS_UNRESTRICTED

Há chaves de API muito usadas.

As chaves de API irrestritas são inseguras porque é possível recuperá-las nos dispositivos em que a chave está armazenada ou vê-las publicamente, por exemplo, em um navegador. De acordo com o princípio de privilégio mínimo, configure chaves de API para chamar apenas as APIs exigidas pelo aplicativo. Para mais informações, consulte Aplicar restrições de chave de API.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Chaves de API no console do Google Cloud.

   Acesse as chaves de API

2. Em cada chave de API:

   1. Na seção Chaves de API, na linha de cada chave de API em que você precisa restringir APIs, clique em Ações.
   2. No menu Ações, clique em Excluir chave de API. A página Editar chave de API é aberta.
   3. Na seção Restrições de API, selecione Restringir APIs. O menu suspenso Selecionar APIs será exibido.
   4. Na lista suspensa Selecionar APIs, escolha as APIs que terão permissão.
      Aviso:não defina restrições de API como APIs do Google Cloud, porque isso permite acesso a todos os serviços oferecidos pelo Google Cloud.
   5. Clique em Salvar. Pode levar até cinco minutos para que as configurações entrem em vigor.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

API key apps unrestricted

Nome da categoria na API: API_KEY_APPS_UNRESTRICTED

Há chaves de API sendo usadas de maneira irrestrita, permitindo o uso por qualquer aplicativo não confiável.

Chaves de API irrestritas são inseguras porque é possível recuperá-las nos dispositivos em que a chave está armazenada ou vê-las publicamente, como de dentro de um navegador, por exemplo. De acordo com o princípio de privilégio mínimo, restrinja o uso da chave de API a hosts confiáveis, referenciadores HTTP e aplicativos. Para mais informações, consulte Aplicar restrições de chave de API.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Chaves de API no console do Google Cloud.

   Acesse as chaves de API

2. Em cada chave de API:

   1. Na seção Chaves de API, na linha de cada chave de API para a qual você precisa restringir aplicativos, clique em Ações.
   2. No menu Ações, clique em Excluir chave de API. A página Editar chave de API é aberta.
   3. Na página Editar chave de API, em Restrições de aplicativo, selecione uma categoria de restrição. É possível definir apenas uma restrição de aplicativo por chave.
   4. No campo Adicionar um item que é exibido quando você seleciona uma restrição, clique em Adicionar um item para adicionar restrições com base nas necessidades do aplicativo.
   5. Quando terminar de adicionar itens, clique em Concluído.
      Aviso:não defina referenciadores HTTP para caracteres curinga que permitam acesso a qualquer referenciador HTTP, por exemplo, *, *.[TLD] ou .[TLD]/*. Não defina endereços IP e referenciadores para permitir qualquer host (0.0.0.0, ::0 ou 0.0.0.0/0).
   6. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

API key exists

Nome da categoria na API: API_KEY_EXISTS

Um projeto está usando chaves de API em vez da autenticação padrão.

As chaves de API são menos seguras do que outros métodos de autenticação, porque são strings criptografadas simples e fáceis de descobrir e usar. É possível recuperá-las nos dispositivos em que a chave está armazenada ou vê-las publicamente, como de dentro de um navegador. Além disso, as chaves de API não identificam exclusivamente os usuários ou aplicativos que fazem solicitações. Como alternativa, é possível usar um fluxo de autenticação padrão com contas de serviço ou contas de usuário.

Atenção: estas etapas de correção podem interromper o ambiente de produção. Se necessário, passe cargas de trabalho, dados ou permissões para novos recursos antes de excluir recursos existentes.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Certifique-se de que os aplicativos estejam configurados com uma forma alternativa de autenticação.

2. Acesse a página Credenciais da API no console do Google Cloud.

   Acesse as credenciais da API

3. Na seção Chaves de API da linha de cada chave que precisa ser excluída, clique em Ações.

4. No menu Ações, clique em Excluir chave de API.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

API key not rotated

Nome da categoria na API: API_KEY_NOT_ROTATED

A chave de API não é rotacionada há mais de 90 dias.

As chaves de API não expiram. Portanto, se uma for roubada, é possível que seja usada indefinidamente a menos que o proprietário do projeto a revogue ou a rotacione. Regenerar chaves de API com frequência reduz por quanto tempo uma chave de API roubada poderá ser usada para acessar dados em uma conta comprometida ou encerrada. Faça a rotação das chaves de API pelo menos a cada 90 dias. Para mais informações, consulte Práticas recomendadas para gerenciar chaves de API.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Chaves de API no console do Google Cloud.

   Acesse as chaves de API

2. Em cada chave de API:

   1. Na seção Chaves de API, na linha de cada chave que precisa ser excluída, clique em Ações.
   2. No menu Ações, clique em Excluir chave de API. A página Editar chave de API é aberta.
   3. Na página Editar chave de API, se a data no campo Data de criação for anterior a 90 dias, clique em Gerar chave novamente. Uma nova chave é gerada.
   4. Clique em Salvar.
   5. Para garantir que os aplicativos continuem funcionando sem interrupções, atualize-os para usar a nova chave de API. A chave de API antiga funciona por 24 horas antes de ser desativada permanentemente.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Audit config not monitored

Nome da categoria na API: AUDIT_CONFIG_NOT_MONITORED

As métricas e os alertas de registros não estão configurados para monitorar as alterações de configuração de auditoria.

O Cloud Audit Logging produz registros de atividades do administrador e de acesso a dados que permitem a análise de segurança, o rastreamento de alterações de recursos e a auditoria de conformidade. Ao monitorar as alterações na configuração de auditoria, você garante que todas as atividades no projeto possam ser auditadas a qualquer momento. Para mais informações, consulte Visão geral das métricas com base em registros.

Dependendo da quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para entender o uso do serviço e os custos dele, consulte Preços da Observabilidade do Google Cloud.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, crie métricas, se necessário, e políticas de alerta:

Criar métrica

1. Acesse a página Métricas com base em registros no console do Google Cloud.

   Acessar métricas com base em registros

2. Clique em Criar métrica.

3. Em Tipo de Métrica, selecione Contador.

4. Em Detalhes:

   1. Defina um Nome da métrica de registro.
   2. Adicione uma descrição.
   3. Definir Unidades para 1.

5. Em Seleção de filtros, copie e cole o texto a seguir na caixa Criar filtro, substituindo o texto existente, se necessário:

     protoPayload.methodName="SetIamPolicy"
     AND protoPayload.serviceData.policyDelta.auditConfigDeltas:*

6. Clique em Criar métrica. Você verá uma confirmação.

Criar política de alertas

1. No console do Google Cloud, acesse a página Métricas com base em registros.

   Acessar Métricas com base em registros

   Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Logging.

2. Na seção Métricas definidas pelo usuário, selecione a métrica que você criou na seção anterior.

3. Clique em Mais e depois em Criar alerta com base na métrica.

   A caixa de diálogo Nova condição é aberta com as opções de transformação de dados e métricas pré-preenchidas.

4. Clique em Próxima.
   1. Revise as configurações pré-preenchidas. Convém modificar o Valor do limite.
   2. Clique em Nome da condição e digite um nome para ela.
5. Clique em Next.

6. Para adicionar notificações à sua política de alertas, clique em Canais de notificação. Na caixa de diálogo, selecione um ou mais canais de notificação no menu e clique em OK.

   Para receber uma notificação quando os incidentes forem abertos ou fechados, marque Notificar sobre o fechamento de incidentes. Por padrão, as notificações são enviadas apenas quando incidentes são abertos.

7. Opcional: Atualize a Duração do fechamento automático do incidente. Este campo determina quando o Monitoring fecha incidentes na ausência de dados de métrica.
8. Opcional: clique em Documentação e adicione as informações que quer incluir em uma mensagem de notificação.
9. Clique em Nome e digite um nome para a política de alertas.
10. Clique em Criar política.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Audit logging disabled

Nome da categoria na API: AUDIT_LOGGING_DISABLED

Essa descoberta não está disponível para ativações no nível do projeto.

A geração de registros de auditoria está desativada para um ou mais serviços do Google Cloud ou um ou mais principais estão isentos da geração de registros de auditoria de acesso a dados.

Ative o Cloud Logging para todos os serviços para rastrear todas as atividades administrativas, o acesso de leitura e o acesso de gravação aos dados dos usuários. Dependendo da quantidade de informações, os custos do Cloud Logging podem ser significativos. Para entender o uso do serviço e o custo dele, consulte Preços da Observabilidade do Google Cloud.

Se os principais estiverem isentos da geração de registros de auditoria de acesso a dados na configuração padrão ou de qualquer serviço individual, remova a isenção.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Configuração padrão dos registros de auditoria de acesso a dados no Console do Google Cloud.

   Acessar a configuração padrão

2. Na guia Tipos de registro, ative a geração de registros de auditoria de acesso a dados na configuração padrão:

   1. Selecione Leitura de administradores, Leitura de dados e Gravação de dados.
   2. Clique em Save.

3. Na guia Participantes isentos, remova todos os usuários isentos da configuração padrão:

   1. Remova cada principal listado clicando em Excluir ao lado de cada nome.
   2. Clique em Salvar.

4. Acesse a página Registros de auditoria.

   Ir para Registros de auditoria

5. Remova os principais isentos das configurações do registro de auditoria de acesso a dados de serviços individuais.

   1. Em Configuração dos registros de auditoria de acesso a dados, clique no serviço nos serviços que mostram um principal isento. Um painel de configuração de registro de auditoria será aberto para o serviço.
   2. Na guia Participantes isentos, remova todos os participantes isentos clicando em Excluir ao lado de cada nome.
   3. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Auto backup disabled

Nome da categoria na API: AUTO_BACKUP_DISABLED

Um banco de dados do Cloud SQL não tem backups automáticos ativados.

Para evitar a perda de dados, ative os backups automatizados para as instâncias do SQL. Para mais informações, consulte Como criar e gerenciar backups automáticos e sob demanda.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. No console do Google Cloud, acesse a página Instâncias do Cloud SQL.

   Acesse "Instâncias"

2. Clique no nome da instância.

3. Clique em Backups.

4. Ao lado de Configurações, clique em Editar.

5. Marque a caixa de seleção Backups diários automatizados.

6. Opcional: na caixa Número de dias, insira quantos dias de backups você quer manter.

7. Opcional: na lista Janela de backup, selecione o período em que os backups serão feitos.

8. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Auto repair disabled

Nome da categoria na API: AUTO_REPAIR_DISABLED

O recurso de reparo automático de um cluster do Google Kubernetes Engine (GKE), que mantém os nós em um estado íntegro e em execução, está desativado.

Quando ativado, o GKE verifica periodicamente o estado de integridade de cada nó no cluster. Se um nó falhar em verificações de integridade consecutivas durante um período prolongado, o GKE iniciará um processo de reparo para esse nó. Para mais informações, consulte Como fazer o reparo automático de nós.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Clusters do Kubernetes no console do Google Cloud.

   Acessar clusters do Kubernetes

2. Clique na guia Nós.

3. Para cada pool de nós:

   1. Clique no nome do pool de nós para acessar a página de detalhes.
   2. Clique em Editar.
   3. Em Gerenciamento, selecione Ativar reparo automático.
   4. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Auto upgrade disabled

Nome da categoria na API: AUTO_UPGRADE_DISABLED

O recurso de upgrade automático de um cluster do GKE, que mantém clusters e o pools de nós na versão estável mais recente do Kubernetes, está desativado.

Para mais informações, consulte Como fazer o upgrade automático de nós.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Clusters do Kubernetes no console do Google Cloud.

   Acessar clusters do Kubernetes

2. Na lista de clusters, clique no nome do cluster.

3. Clique na guia Nós.

4. Para cada pool de nós:

   1. Clique no nome do pool de nós para acessar a página de detalhes.
   2. Clique em Editar.
   3. Em Gerenciamento, selecione Ativar upgrade automático.
   4. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

BigQuery table CMEK disabled

Nome da categoria na API: BIGQUERY_TABLE_CMEK_DISABLED

Uma tabela do BigQuery não está configurada para usar uma chave de criptografia gerenciada pelo cliente (CMEK).

Com a CMEK, as chaves que você cria e gerencia no Cloud KMS encapsulam as chaves que o Google Cloud usa para criptografar seus dados, oferecendo mais controle sobre o acesso a eles. Para mais informações, consulte Como proteger dados com chaves do Cloud KMS.

Atenção: estas etapas de correção podem interromper o ambiente de produção. Se necessário, passe cargas de trabalho, dados ou permissões para novos recursos antes de excluir recursos existentes.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Crie uma tabela protegida pelo Cloud Key Management Service.
2. Copie sua tabela para a nova tabela ativada para CMEK.
3. Exclua a tabela original.

Para definir uma chave CMEK padrão que criptografa todas as novas tabelas em um conjunto de dados, consulte Definir uma chave padrão do conjunto de dados.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Binary authorization disabled

Nome da categoria na API: BINARY_AUTHORIZATION_DISABLED

A autorização binária está desativada em um cluster do GKE.

A autorização binária inclui um recurso opcional que protege a segurança da cadeia de suprimentos, permitindo que apenas imagens de contêiner assinadas por autoridades confiáveis durante o processo de desenvolvimento sejam implantadas no cluster. Ao aplicar a implantação baseada em assinatura, você tem mais controle do ambiente do contêiner e garante que apenas imagens verificadas tenham permissão para serem implantadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Clusters do Kubernetes no console do Google Cloud.

   Acessar clusters do Kubernetes

2. Na seção Segurança, clique em Editar na linha Autorização binária.

   Se a configuração do cluster tiver sido alterada recentemente, o botão de edição poderá ser desativado. Se você não conseguir editar as configurações do cluster, aguarde alguns minutos e tente novamente.

3. Na caixa de diálogo, selecione Ativar autorização binária.

4. Clique em Save changes.

5. Acesse a página de configuração da autorização binária.

   Acessar a autorização binária

6. Verifique se uma política que exige atestadores está configurada e se a regra padrão do projeto não está configurada para Permitir todas as imagens. Para mais informações, consulte Configurar para o GKE.

   Para garantir que as imagens que violam a política tenham permissão para serem implantadas e as violações sejam registradas nos registros de auditoria do Cloud, ative o modo de teste.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Bucket CMEK disabled

Nome da categoria na API: BUCKET_CMEK_DISABLED

Um bucket não é criptografado com chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês).

Definir uma CMEK padrão em um bucket oferece mais controle sobre o acesso aos dados. Para mais informações, consulte Chaves de criptografia gerenciadas pelo cliente.

Para corrigir essa descoberta, use a CMEK com um bucket seguindo Como usar chaves de criptografia gerenciadas pelo cliente. A CMEK gera custos adicionais relacionados ao Cloud KMS.

Observação: definir uma chave padrão não recriptografará retroativamente com uma nova chave os objetos que já estão no bucket.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Bucket IAM not monitored

Nome da categoria na API: BUCKET_IAM_NOT_MONITORED

As métricas e os alertas de registros não estão configurados para monitorar as alterações de permissão do IAM do Cloud Storage.

Monitorar alterações nas permissões de bucket do Cloud Storage ajuda a identificar usuários com privilégios em excesso ou atividades suspeitas. Para mais informações, consulte Visão geral das métricas com base em registros.

Dependendo da quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para entender o uso do serviço e os custos dele, consulte Preços da Observabilidade do Google Cloud.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, conclua as etapas a seguir:

Criar métrica

1. Acesse a página Métricas com base em registros no console do Google Cloud.

   Acessar métricas com base em registros

2. Clique em Criar métrica.

3. Em Tipo de Métrica, selecione Contador.

4. Em Detalhes:

   1. Defina um Nome da métrica de registro.
   2. Adicione uma descrição.
   3. Definir Unidades para 1.

5. Em Seleção de filtros, copie e cole o texto a seguir na caixa Criar filtro, substituindo o texto existente, se necessário:

     resource.type=gcs_bucket
     AND protoPayload.methodName="storage.setIamPermissions"

6. Clique em Criar métrica. Você verá uma confirmação.

Criar política de alertas

1. No console do Google Cloud, acesse a página Métricas com base em registros.

   Acessar Métricas com base em registros

   Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Logging.

2. Na seção Métricas definidas pelo usuário, selecione a métrica que você criou na seção anterior.

3. Clique em Mais e depois em Criar alerta com base na métrica.

   A caixa de diálogo Nova condição é aberta com as opções de transformação de dados e métricas pré-preenchidas.

4. Clique em Próxima.
   1. Revise as configurações pré-preenchidas. Convém modificar o Valor do limite.
   2. Clique em Nome da condição e digite um nome para ela.
5. Clique em Next.

6. Para adicionar notificações à sua política de alertas, clique em Canais de notificação. Na caixa de diálogo, selecione um ou mais canais de notificação no menu e clique em OK.

   Para receber uma notificação quando os incidentes forem abertos ou fechados, marque Notificar sobre o fechamento de incidentes. Por padrão, as notificações são enviadas apenas quando incidentes são abertos.

7. Opcional: Atualize a Duração do fechamento automático do incidente. Este campo determina quando o Monitoring fecha incidentes na ausência de dados de métrica.
8. Opcional: clique em Documentação e adicione as informações que quer incluir em uma mensagem de notificação.
9. Clique em Nome e digite um nome para a política de alertas.
10. Clique em Criar política.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Bucket logging disabled

Nome da categoria na API: BUCKET_LOGGING_DISABLED

Há um bucket de armazenamento sem a geração de registros ativada.

Para ajudar a investigar problemas de segurança e monitorar o consumo de armazenamento, ative os registros de acesso e informação de armazenamento nos seus buckets do Cloud Storage. Os registros de acesso fornecem informações sobre todas as solicitações feitas em um bucket específico, e os registros de armazenamento fornecem informações sobre o consumo de armazenamento desse bucket.

Para corrigir essa descoberta, configure o registro para o bucket indicado pela descoberta do Security Health Analytics completando o guia de registros de uso e de armazenamento.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Bucket policy only disabled

Nome da categoria na API: BUCKET_POLICY_ONLY_DISABLED

O acesso uniforme no nível do bucket, anteriormente chamado de Somente política do bucket, não está configurado.

O acesso uniforme no nível do bucket simplifica o controle de acesso do bucket ao desativar permissões no nível do objeto (ACLs, na sigla em inglês). Quando ativadas, somente as permissões do IAM no nível do bucket concederão acesso ao bucket e aos objetos contidos nele. Para mais informações, consulte Acesso uniforme no nível do bucket.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página do navegador do Cloud Storageno console do Google Cloud.

   Ir para o Navegador do Cloud Storage

2. Na lista de buckets, clique no nome do bucket pretendido.

3. Clique na guia Configuração.

4. Em Permissões, na linha Controle de acesso, clique em Editar modelo de controle de acesso.

5. Na caixa de diálogo, selecione Uniforme.

6. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Cloud Asset API disabled

Nome da categoria na API: CLOUD_ASSET_API_DISABLED

O serviço de Inventário de recursos do Cloud não está ativado no projeto.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Biblioteca de APIs no console do Google Cloud.

   Acessar a biblioteca de APIs

2. Pesquise Cloud Asset Inventory.

3. Selecione o resultado do serviço API Cloud Asset.

4. Verifique se está exibindo API ativada.

Cluster logging disabled

Nome da categoria na API: CLUSTER_LOGGING_DISABLED

A geração de registros não está ativada para um cluster do GKE.

Para ajudar a investigar problemas de segurança e monitorar o uso, ative o Cloud Logging nos clusters.

Dependendo da quantidade de informações, os custos do Cloud Logging podem ser significativos. Para entender o uso e o custo do serviço, consulte Preços da Observabilidade do Google Cloud.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Clusters do Kubernetes no console do Google Cloud.

   Acessar os clusters do Kubernetes

2. Selecione o cluster listado na descoberta do Security Health Analytics.

3. Clique em Editar.

   Se a configuração do cluster tiver sido alterada recentemente, o botão de edição poderá ser desativado. Se você não conseguir editar as configurações do cluster, aguarde alguns minutos e tente novamente.

4. Na lista suspensa do Stackdriver Logging legado ou do Stackdriver Kubernetes Engine Monitoring, selecione Ativado.

   Essas opções não são compatíveis. Assegure-se de usar o Stackdriver Kubernetes Engine Monitoring apenas, ou Stackdriver Logging legado com Stackdriver Monitoring legado.

5. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Cluster monitoring disabled

Nome da categoria na API: CLUSTER_MONITORING_DISABLED

O monitoramento está desativado nos clusters do GKE.

Para ajudar a investigar problemas de segurança e monitorar o uso, ative o Cloud Monitoring nos clusters.

Dependendo da quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para entender o uso do serviço e os custos dele, consulte Preços da Observabilidade do Google Cloud.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Clusters do Kubernetes no console do Google Cloud.

   Acessar os clusters do Kubernetes

2. Selecione o cluster listado na descoberta do Security Health Analytics.

3. Clique em Editar.

   Se a configuração do cluster tiver sido alterada recentemente, o botão de edição poderá ser desativado. Se você não conseguir editar as configurações do cluster, aguarde alguns minutos e tente novamente.

4. Na lista suspensa do Stackdriver Monitoring legado ou do Stackdriver Kubernetes Engine Monitoring, selecione Ativado.

   Essas opções não são compatíveis. Assegure-se de usar o Stackdriver Kubernetes Engine Monitoring apenas, ou Stackdriver Monitoring legado com o Stackdriver Logging legado.

5. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Cluster private Google access disabled

Nome da categoria na API: CLUSTER_PRIVATE_GOOGLE_ACCESS_DISABLED

Os hosts de cluster não estão configurados para usar apenas endereços IP internos particulares para acessar as APIs do Google.

O Acesso privado do Google permite que instâncias de máquina virtual (VM, na sigla em inglês) com apenas endereços IP internos privados acessem os endereços IP públicos das APIs e serviços do Google. Para mais informações, consulte Como configurar o Acesso privado do Google.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Redes de nuvem privada virtual no console do Google Cloud.

   Acessar Redes VPC

2. Na lista de redes, clique no nome da rede desejada.

3. Na página Detalhes da rede VPC, clique na guia Sub-redes.

4. Na lista de sub-redes, clique no nome da sub-rede associada ao cluster do Kubernetes na descoberta.

5. Na página Detalhes da sub-rede, clique em Editar.

6. Em Acesso privado do Google, selecione Ativado.

7. Clique em Save.

8. Para remover IPs públicos (externos) das instâncias de VM cujo tráfego externo é apenas para APIs do Google, consulte Como cancelar a atribuição de um endereço IP externo estático.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Cluster secrets encryption disabled

Nome da categoria na API: CLUSTER_SECRETS_ENCRYPTION_DISABLED

A criptografia de secrets da camada de aplicativo está desativada em um cluster do GKE.

A criptografia de secrets da camada de aplicativo garante que os secrets do GKE sejam criptografados usando chaves do Cloud KMS. O recurso fornece uma camada extra de segurança para dados confidenciais, como secrets definidos pelo usuário e secrets necessários para a operação do cluster, como chaves de conta de serviço, armazenadas em etcd.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Chaves do Cloud KMS no console do Google Cloud.

   Acesse as chaves do Cloud KMS

2. Revise as chaves do aplicativo ou crie uma chave de criptografia de banco de dados (DEK). Para mais informações, consulte Como criar uma chave do Cloud KMS.

3. Acesse a página Clusters do Kubernetes.

   Acessar clusters do Kubernetes

4. Selecione o cluster na descoberta.

5. Em Segurança, no campo Criptografia de secrets da camada de aplicativos, clique em Editar criptografia de secrets da camada de aplicativos.

6. Marque a caixa de seleção Ativar a criptografia de secrets da camada de aplicativos e então escolha a DEK que você criou.

7. Clique em Salvar alterações.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Cluster shielded nodes disabled

Nome da categoria na API: CLUSTER_SHIELDED_NODES_DISABLED

Os nós protegidos do GKE não estão ativados em um cluster.

Sem os nós protegidos do GKE, invasores podem se aproveitar de uma vulnerabilidade em um pod para roubar credenciais de bootstrap e falsificar nós no cluster. A vulnerabilidade pode permitir que invasores acessem secrets do cluster.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Clusters do Kubernetes no console do Google Cloud.

   Acessar clusters do Kubernetes

2. Selecione o cluster na descoberta.

3. Em Segurança, no campo Nós protegidos do GKE, clique em Editar nós protegidos do GKE.

4. Marque a caixa de seleção Ativar os nós protegidos do GKE.

5. Clique em Salvar alterações.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Compute project wide SSH keys allowed

Nome da categoria na API: COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED

As chaves SSH do projeto são usadas, o que permite o login em todas as instâncias no projeto.

O uso de chaves SSH em todo o projeto facilita o gerenciamento de chaves SSH, mas, se comprometidas, representam um risco de segurança que pode afetar todas as instâncias de um projeto. Use chaves SSH específicas à instância, que limitam a superfície de ataque se as chaves SSH estiverem comprometidas. Para mais informações, consulte Como gerenciar chaves SSH em metadados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias de VMs no Console do Google Cloud.

   Acessar instâncias de VM

2. Na lista de instâncias, clique no nome da instância na descoberta.

3. Na página Detalhes da instância de VM, clique em Editar.

   Observação: não é possível editar instâncias criadas com modelos de instância. Para fazer alterações na configuração de um modelo de instância, consulte Como atualizar modelos de instância.

4. Em Chaves SSH, selecione Bloquear chaves SSH do projeto.

5. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Compute Secure Boot disabled

Nome da categoria na API: COMPUTE_SECURE_BOOT_DISABLED

Uma VM protegida não tem está com a Inicialização segura ativada.

O uso da Inicialização segura ajuda a proteger as máquinas virtuais contra rootkits e bootkits. O Compute Engine não ativa a Inicialização segura por padrão porque alguns drivers não assinados e softwares de baixo nível não são compatíveis. Se a VM não usa um software incompatível e é inicializada com a Inicialização segura ativada, o Google recomenda o uso da Inicialização segura. Se você estiver usando módulos de terceiros com drivers NVIDIA, verifique se eles são compatíveis com a Inicialização segura antes de ativá-la.

Para mais informações, consulte Inicialização segura.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias de VMs no Console do Google Cloud.

   Acessar instâncias de VM

2. Na lista de instâncias, clique no nome da instância na descoberta.

3. Na página Detalhes da instância de VM, clique em Interromper.

4. Depois que a instância for interrompida, clique em Editar.

5. Em VM protegida, selecione Ativar a Inicialização segura.

6. Clique em Save.

7. Clique em Iniciar para iniciar a instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Compute serial ports enabled

Nome da categoria na API: COMPUTE_SERIAL_PORTS_ENABLED

As portas seriais de uma instância estão ativadas, o que permite conexões com o console serial da instância.

Se você ativar o console serial interativo em uma instância, os clientes poderão tentar se conectar a essa instância de qualquer endereço IP. Por isso, o suporte ao console serial interativo precisa estar desativado. Para mais informações, consulte Como ativar o acesso de um projeto.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias de VMs no Console do Google Cloud.

   Acessar instâncias de VM

2. Na lista de instâncias, clique no nome da instância na descoberta.

3. Na página Detalhes da instância de VM, clique em Editar.

4. Em Acesso remoto, desmarque Ativar a conexão com as portas seriais.

5. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Confidential Computing disabled

Nome da categoria na API: CONFIDENTIAL_COMPUTING_DISABLED

Uma instância do Compute Engine não tem Computação confidencial ativada.

A Computação confidencial adiciona um terceiro pilar à história de criptografia de ponta a ponta ao criptografar dados durante o uso. Com os ambientes de execução confidenciais fornecidos pela Computação confidencial e a virtualização criptografada segura (SEV, na sigla em inglês) da AMD, o Google Cloud mantém códigos confidenciais e outros dados criptografados na memória durante o processamento.

A Computação confidencial só pode ser ativada quando uma instância é criada. Por isso, você precisa excluir a instância atual e criar uma nova.

Para mais informações, consulte VM confidencial e o Compute Engine.

Observação: a Computação confidencial é compatível apenas com os tipos de máquina N2D.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias de VMs no Console do Google Cloud.

   Acessar instâncias de VM

2. Na lista de instâncias, clique no nome da instância na descoberta.

3. Na página Detalhes da instância de VM, clique em Excluir.

4. Crie uma VM confidencial usando o console do Google Cloud.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

COS not used

Nome da categoria na API: COS_NOT_USED

As VMs do Compute Engine não estão usando o sistema operacional Container-Optimized, que foi projetado para executar contêineres do Docker no Google Cloud com segurança.

O Google recomenda o sistema operacional Container-Optimized para hospedar e executar contêineres no Google Cloud. A pouca ocupação de espaço do sistema operacional diminui a exposição de segurança, enquanto as atualizações automáticas corrigem as vulnerabilidades de segurança no momento certo. Para mais informações, consulte Visão geral do sistema operacional Container-Optimized.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Clusters do Kubernetes no console do Google Cloud.

   Acessar clusters do Kubernetes

2. Na lista de clusters, clique no nome do cluster na descoberta.

3. Clique na guia Nós.

4. Para cada pool de nós:

   1. Clique no nome do pool de nós para acessar a página de detalhes.
   2. Clique em Editar .
   3. Em Nós -> Tipo de imagem, clique em Alterar.
   4. Selecione Container-Optimized OS e clique em Alterar.
   5. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Custom role not monitored

Nome da categoria na API: CUSTOM_ROLE_NOT_MONITORED

As métricas e os alertas de registro não estão configurados para monitorar as alterações de papéis personalizados.

O IAM fornece papéis predefinidos e personalizados que concedem acesso a recursos específicos do Google Cloud. Ao monitorar as atividades de criação, exclusão e atualização de papéis, é possível identificar papéis com privilégios em excesso nos estágios iniciais. Para mais informações, consulte Visão geral de métricas com base em registros.

Dependendo da quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para entender o uso do serviço e os custos dele, consulte Preços da Observabilidade do Google Cloud.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, conclua as etapas a seguir:

Criar métrica

1. Acesse a página Métricas com base em registros no console do Google Cloud.

   Acessar métricas com base em registros

2. Clique em Criar métrica.

3. Em Tipo de Métrica, selecione Contador.

4. Em Detalhes:

   1. Defina um Nome da métrica de registro.
   2. Adicione uma descrição.
   3. Definir Unidades para 1.

5. Em Seleção de filtros, copie e cole o texto a seguir na caixa Criar filtro, substituindo o texto existente, se necessário:

     resource.type="iam_role"
     AND (protoPayload.methodName="google.iam.admin.v1.CreateRole"
     OR protoPayload.methodName="google.iam.admin.v1.DeleteRole"
     OR protoPayload.methodName="google.iam.admin.v1.UpdateRole")

6. Clique em Criar métrica. Você verá uma confirmação.

Criar política de alertas

1. No console do Google Cloud, acesse a página Métricas com base em registros.

   Acessar Métricas com base em registros

   Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Logging.

2. Na seção Métricas definidas pelo usuário, selecione a métrica que você criou na seção anterior.

3. Clique em Mais e depois em Criar alerta com base na métrica.

   A caixa de diálogo Nova condição é aberta com as opções de transformação de dados e métricas pré-preenchidas.

4. Clique em Próxima.
   1. Revise as configurações pré-preenchidas. Convém modificar o Valor do limite.
   2. Clique em Nome da condição e digite um nome para ela.
5. Clique em Next.

6. Para adicionar notificações à sua política de alertas, clique em Canais de notificação. Na caixa de diálogo, selecione um ou mais canais de notificação no menu e clique em OK.

   Para receber uma notificação quando os incidentes forem abertos ou fechados, marque Notificar sobre o fechamento de incidentes. Por padrão, as notificações são enviadas apenas quando incidentes são abertos.

7. Opcional: Atualize a Duração do fechamento automático do incidente. Este campo determina quando o Monitoring fecha incidentes na ausência de dados de métrica.
8. Opcional: clique em Documentação e adicione as informações que quer incluir em uma mensagem de notificação.
9. Clique em Nome e digite um nome para a política de alertas.
10. Clique em Criar política.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Dataproc CMEK disabled

Nome da categoria na API: DATAPROC_CMEK_DISABLED

Um cluster do Dataproc foi criado sem uma CMEK de configuração de criptografia. Com a CMEK, as chaves que você cria e gerencia no Cloud Key Management Service encapsulam as chaves que o Google Cloud usa para criptografar seus dados, oferecendo mais controle sobre o acesso a eles.

Atenção: estas etapas de correção podem interromper o ambiente de produção. Se necessário, passe cargas de trabalho, dados ou permissões para novos recursos antes de excluir recursos existentes.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Cluster do Dataproc no console do Google Cloud.

   Acessar clusters do Dataproc

2. Selecione o projeto e clique em Criar cluster.

3. Na seção Gerenciar segurança, clique em Criptografia e selecione Chave gerenciada pelo cliente.

4. Selecione uma chave gerenciada pelo cliente na lista.

   Se você não tiver uma chave gerenciada pelo cliente para usar, crie uma. Para mais informações, consulte Chaves de criptografia gerenciadas pelo cliente.

5. Verifique se a chave KMS selecionada tem o papel de criptografia/descriptografia do CryptoKey do Cloud KMS atribuído à conta de serviço do cluster do Dataproc ("serviceAccount:[e-mail]").

6. Depois de criar o cluster, migre todas as cargas de trabalho do antigo para o novo cluster.

7. Acesse os clusters do Dataproc e selecione seu projeto.

8. Selecione o cluster antigo e clique em Excluir cluster.

9. Repita todas as etapas acima para outros clusters do Dataproc disponíveis no projeto selecionado.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Dataproc image outdated

Nome da categoria na API: DATAPROC_IMAGE_OUTDATED

Um cluster do Dataproc foi criado usando uma versão da imagem do Dataproc afetada pelas vulnerabilidades de segurança no utilitário do Apache Log4j 2 (CVE-2021-44228 e CVE-). 2021 a 45046).

Esse detector encontra vulnerabilidades verificando se o campo softwareConfig.imageVersion na propriedade config de um Cluster tem uma das seguintes versões afetadas:

• Versões de imagem anteriores à 1.3.95.
• Versões de imagem menores que 1.4.77, 1.5.53 e 2.0.27.

O número da versão de uma imagem personalizada do Dataproc pode ser modificado manualmente. Considere os cenários a seguir.

• É possível modificar a versão de uma imagem personalizada afetada para que ela não seja afetada. Nesse caso, esse detector não emite uma descoberta.
• É possível substituir a versão de uma imagem personalizada não afetada por uma que tenha a vulnerabilidade conhecida. Nesse caso, esse detector emite uma descoberta falsa positiva. Para suprimir essas descobertas de falsos positivos, você pode ignorá-las.

Atenção: estas etapas de correção podem interromper o ambiente de produção. Se necessário, passe cargas de trabalho, dados ou permissões para novos recursos antes de excluir recursos existentes.

Para corrigir essa descoberta, recrie e atualize o cluster afetado.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Dataset CMEK disabled

Nome da categoria na API: DATASET_CMEK_DISABLED

Um conjunto de dados do BigQuery não está configurado para usar uma chave de criptografia gerenciada pelo cliente (CMEK, na sigla em inglês) padrão.

Com a CMEK, as chaves que você cria e gerencia no Cloud KMS encapsulam as chaves que o Google Cloud usa para criptografar seus dados, oferecendo mais controle sobre o acesso a eles. Para mais informações, consulte Como proteger dados com chaves do Cloud KMS.

Atenção: estas etapas de correção podem interromper o ambiente de produção. Se necessário, passe cargas de trabalho, dados ou permissões para novos recursos antes de excluir recursos existentes.

Para corrigir essa descoberta, conclua as etapas a seguir:

Não é possível alternar uma tabela no local entre as criptografias padrão e a criptografia CMEK. Para definir uma chave padrão de CMEK com a qual criptografar todas as novas tabelas no conjunto de dados, siga as instruções para Definir uma chave padrão de conjunto de dados.

Definir uma chave padrão não recriptografará retroativamente tabelas atualmente no conjunto de dados com uma nova chave. Para usar a CMEK para dados atuais:

1. Crie um novo conjunto de dados.
2. Defina uma chave de CMEK padrão no conjunto de dados que você criou.
3. Para copiar tabelas para o conjunto de dados ativado da CMEK, siga as instruções em Como copiar uma tabela.
4. Depois de copiar os dados, exclua os conjuntos de dados originais.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Default network

Nome da categoria na API: DEFAULT_NETWORK

A rede padrão existe em um projeto.

As redes padrão criaram automaticamente regras de firewall e configurações de rede que talvez não sejam seguras. Para mais informações, consulte Rede padrão.

Atenção: estas etapas de correção podem interromper o ambiente de produção. Se necessário, passe cargas de trabalho, dados ou permissões para novos recursos antes de excluir recursos existentes.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Redes VPC no Console do Google Cloud.

   Acessar redes VPC

2. Na lista de redes, clique no nome da rede padrão.

3. Na página Detalhes da rede VPC, clique em Excluir rede VPC.

4. Para criar uma nova rede com regras de firewall personalizadas, consulte Como criar redes.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Default service account used

Nome da categoria na API: DEFAULT_SERVICE_ACCOUNT_USED

Uma instância do Compute Engine está configurada para usar a conta de serviço padrão.

A conta de serviço padrão do Compute Engine tem o papel Editor no projeto, o que permite acesso de leitura e gravação à maioria dos serviços do Google Cloud. Para se proteger contra escalonamentos de privilégios e acesso não autorizado, não use a conta de serviço padrão do Compute Engine. Em vez disso, crie uma nova conta de serviço e atribua apenas as permissões necessárias à instância. Leia Controle de acesso para mais informações sobre papéis e permissões.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias de VMs no Console do Google Cloud.

   Acessar instâncias de VM

2. Selecione a instância relacionada à descoberta do Security Health Analytics.

3. Na página Detalhes da instância carregada, clique em Interromper.

4. Depois que a instância for interrompida, clique em Editar.

5. Na seção Conta de serviço, selecione uma conta de serviço que não seja a padrão do Compute Engine. Talvez seja necessário criar primeiro uma conta de serviço. Leia Controle de acessopara ver informações sobre papéis e permissões do IAM.

6. Clique em Save. A nova configuração aparecerá na página Detalhes da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Disk CMEK disabled

Nome da categoria na API: DISK_CMEK_DISABLED

Os discos nesta VM não são criptografados com chaves de criptografia gerenciadas pelo cliente.

Com a CMEK, as chaves que você cria e gerencia no Cloud KMS encapsulam as chaves que o Google Cloud usa para criptografar seus dados, oferecendo mais controle sobre o acesso a eles. Para mais informações, consulte Como proteger recursos com as chaves do Cloud KMS.

Atenção: estas etapas de correção podem interromper o ambiente de produção. Se necessário, passe cargas de trabalho, dados ou permissões para novos recursos antes de excluir recursos existentes.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Discos do Compute Engine no console do Google Cloud.

   Acesse discos do Compute Engine

2. Na lista de discos, clique no nome do disco indicado na descoberta.

3. Na página Gerenciar disco, clique em Excluir.

4. Para criar um novo disco com a CMEK ativada, consulte Criptografar um novo disco permanente com suas próprias chaves. As CMEK geram custos adicionais relacionados ao Cloud KMS.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Disk CSEK disabled

Nome da categoria na API: DISK_CSEK_DISABLED

Os discos nesta VM não são criptografados com chaves de criptografia fornecidas pelo cliente (CSEK, na sigla em inglês). Os discos de VMs essenciais devem ser criptografados com CSEK.

Se você fornecer as próprias chaves de criptografia que você tem, o Compute Engine as usará para proteger aquelas geradas pelo Google e usadas para criptografar e descriptografar os dados. Para mais informações, consulte Chaves de criptografia fornecidas pelo cliente. A CSEK gera custos adicionais relacionados ao Cloud KMS.

Atenção: estas etapas de correção podem interromper o ambiente de produção. Se necessário, passe cargas de trabalho, dados ou permissões para novos recursos antes de excluir recursos existentes.

Para corrigir essa descoberta, conclua as etapas a seguir:

Excluir e criar disco

Você só pode criptografar novos discos permanentes com sua própria chave. Não é possível criptografar os discos permanentes atuais com ela.

1. Acesse a página Discos do Compute Engine no console do Google Cloud.

   Acesse discos do Compute Engine

2. Na lista de discos, clique no nome do disco indicado na descoberta.

3. Na página Gerenciar disco, clique em Excluir.

4. Para criar um novo disco com a CSEK ativada, consulte Criptografar discos com chaves de criptografia fornecidas pelo cliente.

5. Conclua as etapas restantes para ativar o detector.

Ativar o detector

1. Acesse a página Recursos do Security Command Center no Console do Google Cloud.

   Acesse Recursos

2. Na seção Tipo de recurso do painel Filtros rápidos, selecione compute.Disk.

   Se você não encontrar compute.Disk, clique em Ver mais, digite Disk no campo de pesquisa e clique em Aplicar.

   O painel Results é atualizado para mostrar apenas instâncias do tipo de recurso compute.Disk.

3. Na coluna Nome de exibição, selecione a caixa ao lado do nome do disco que você quer usar com a CSEK e clique em Definir marcações de segurança.

4. Na caixa de diálogo, clique em Adicionar marcação.

5. No campo chave, digite enforce_customer_supplied_disk_encryption_keys e, no campo valor, digite true.

6. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

DNS logging disabled

Nome da categoria na API: DNS_LOGGING_DISABLED

O monitoramento de registros do Cloud DNS fornece nomes de DNS solicitados pelos clientes na rede VPC. Nesses registros, podem ser monitorados nomes de domínios anômalos e avaliados em relação à inteligência contra ameaças. Recomendamos ativar a geração de registros de DNS para redes VPC.

Dependendo da quantidade de informações, os custos do Cloud DNS Logging podem ser significativos. Para entender o uso e o custo do serviço, consulte Preços da Observabilidade do Google Cloud: Cloud Logging.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Redes VPC no console do Google Cloud.

   Acessar redes VPC

2. Na lista de redes, clique no nome da rede VPC.

3. Crie uma nova política de servidor (se não houver uma) ou edite uma política atual:

   • Se a rede não tiver uma política de servidor DNS, siga estas etapas:

     1. Clique em Editar.
     2. No campo Política de servidor DNS, clique em Criar uma nova política de servidor.
     3. Digite um nome para a nova política de servidor.
     4. Defina Registros como Ativado.
     5. Clique em Save.

   • Se a rede tiver uma política de servidor DNS, siga estas etapas:

     1. No campo DNS server policy, clique no nome da política DNS.
     2. Clique em Editar política.
     3. Defina Registros como Ativado.
     4. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

DNSSEC disabled

Nome da categoria na API: DNSSEC_DISABLED

As extensões de segurança do Sistema de Nome de Domínio (DNSSEC, na sigla em inglês) estão desativadas para zonas do Cloud DNS.

As DNSSEC validam as respostas de DNS e reduzem os riscos, como de invasão de DNS e ataques de person-in-the-middle assinando criptograficamente os registros de DNS. Ative as DNSSEC. Para mais informações, consulte a Visão geral das extensões de segurança do DNS (DNSSEC).

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Vá para a página Cloud DNS no console do Google Cloud.

   Acesse as redes do Cloud DNS

2. Localize a linha com a zona DNS indicada na descoberta.

3. Clique na configuração de DNSSEC na linha e, em DNSSEC, selecione Ativar.

4. Leia a caixa de diálogo que aparece. Se estiver tudo certo, clique em Ativar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Effectively Anonymous Users Granted GKE Cluster Access

Nome da categoria na API: GKE_PRIVILEGE_ESCALATION_DEFAULT_USERS_GROUPS

Alguém criou uma vinculação do RBAC que faz referência a um dos seguintes usuários ou grupos:

• system:anonymous
• system:authenticated
• system:unauthenticated

Esses usuários e grupos são efetivamente anônimos e não devem ser usados em RoleBindings ou ClusterRoleBindings. Para mais detalhes, consulte Evitar grupos e funções padrão.

Para corrigir essa descoberta, siga as etapas abaixo nos recursos afetados:

1. Abra o manifesto de cada ClusterRoleBinding ou RoleBinding afetado.
2. Defina os seguintes campos restritos para um dos valores permitidos.

Campos restritos

• subjects[*].name

Valores permitidos

• Qualquer grupo, usuário ou conta de serviço que não inclua system:anonymous, system:authenticated ou system:unauthenticated.

Egress deny rule not set

Nome da categoria na API: EGRESS_DENY_RULE_NOT_SET

Uma regra de negação de saída não é definida em um firewall.

Um firewall que nega todo o tráfego de rede de saída impede conexões de rede de saída indesejadas, exceto as conexões explicitamente autorizadas por outros firewalls. Para mais informações, consulte Casos de saída.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Firewall no Console do Google Cloud.

   Ir até o Firewall

2. Clique em Criar regra de firewall.

3. Dê um nome ao firewall e, opcionalmente, adicione uma descrição.

4. Em Direção do tráfego, selecione Saída.

5. Em Ação se houver correspondência, selecione Negar.

6. No menu suspenso Objetivos, selecione Todas as instâncias na rede.

7. No menu suspenso Filtro de destino, selecione Intervalos de IP e digite 0.0.0.0/0 na caixa Intervalos de IP de destino.

8. Em Protocolos e portas, selecione Negar tudo.

9. Clique em Desativar regra e, em Aplicação, selecione Ativado.

10. Clique em Criar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Essential contacts not configured

Nome da categoria na API: ESSENTIAL_CONTACTS_NOT_CONFIGURED

Sua organização não designou uma pessoa ou um grupo para receber notificações do Google Cloud sobre eventos importantes, como ataques, vulnerabilidades e incidentes de dados na organização do Google Cloud. Recomendamos designar como contato essencial uma ou mais pessoas ou grupos na sua organização de negócios.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Contatos essenciais no console do Google Cloud.

   Acessar Contatos essenciais.

2. Verifique se a organização aparece no seletor de recursos na parte de cima da página. O seletor de recursos informa de qual projeto, pasta ou organização você está gerenciando contatos no momento.

3. Clique em +Adicionar contato. O painel Adicionar um contato é aberto.

4. Nos campos E-mail e Confirmar e-mail, insira o endereço de e-mail do contato.

5. Na seção Categorias de notificação, selecione as categorias de notificação sobre as quais você quer que o contato receba comunicações. Verifique se os endereços de e-mail apropriados estão configurados para cada uma das categorias de notificação a seguir:

   1. Ofício
   2. Segurança
   3. Suspensão
   4. Benefícios técnicos

6. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Firewall not monitored

Nome da categoria na API: FIREWALL_NOT_MONITORED

Observação: o filtro de métricas com base em registros para este detector foi alterado em 27 de outubro de 2021.

As métricas e os alertas de registro não estão configurados para monitorar alterações de regras do Firewall da rede VPC.

O monitoramento de eventos de criação e atualização de regras de firewall oferece insights sobre alterações no acesso à rede, além de ajudar a detectar rapidamente atividades suspeitas. Para mais informações, consulte Visão geral de métricas com base em registros.

Dependendo da quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para entender o uso do serviço e os custos dele, consulte Preços da Observabilidade do Google Cloud.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, conclua as etapas a seguir:

Criar métrica

1. Acesse a página Métricas com base em registros no console do Google Cloud.

   Acessar métricas com base em registros

2. Clique em Criar métrica.

3. Em Tipo de Métrica, selecione Contador.

4. Em Detalhes:

   1. Defina um Nome da métrica de registro.
   2. Adicione uma descrição.
   3. Definir Unidades para 1.

5. Em Seleção de filtros, copie e cole o texto a seguir na caixa Criar filtro, substituindo o texto existente, se necessário:

     resource.type="gce_firewall_rule"
     AND (protoPayload.methodName:"compute.firewalls.insert"
     OR protoPayload.methodName:"compute.firewalls.patch"
     OR protoPayload.methodName:"compute.firewalls.delete")

6. Clique em Criar métrica. Você verá uma confirmação.

Criar política de alertas

1. No console do Google Cloud, acesse a página Métricas com base em registros.

   Acessar Métricas com base em registros

   Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Logging.

2. Na seção Métricas definidas pelo usuário, selecione a métrica que você criou na seção anterior.

3. Clique em Mais e depois em Criar alerta com base na métrica.

   A caixa de diálogo Nova condição é aberta com as opções de transformação de dados e métricas pré-preenchidas.

4. Clique em Próxima.
   1. Revise as configurações pré-preenchidas. Convém modificar o Valor do limite.
   2. Clique em Nome da condição e digite um nome para ela.
5. Clique em Next.

6. Para adicionar notificações à sua política de alertas, clique em Canais de notificação. Na caixa de diálogo, selecione um ou mais canais de notificação no menu e clique em OK.

   Para receber uma notificação quando os incidentes forem abertos ou fechados, marque Notificar sobre o fechamento de incidentes. Por padrão, as notificações são enviadas apenas quando incidentes são abertos.

7. Opcional: Atualize a Duração do fechamento automático do incidente. Este campo determina quando o Monitoring fecha incidentes na ausência de dados de métrica.
8. Opcional: clique em Documentação e adicione as informações que quer incluir em uma mensagem de notificação.
9. Clique em Nome e digite um nome para a política de alertas.
10. Clique em Criar política.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Firewall rule logging disabled

Nome da categoria na API: FIREWALL_RULE_LOGGING_DISABLED

A geração de registros de regras de firewall está desativada.

A geração de registros de regras de firewall permite auditar, verificar e analisar os efeitos das regras de firewall. Isso pode ser útil para auditar o acesso à rede ou fornecer aviso antecipado de que a rede está sendo usada de maneira não aprovada. O custo dos registros pode ser significativo. Para mais informações sobre a geração de registros de regras de firewall e o respectivo custo, consulte Como usar o registro de regras de firewall.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Firewall no Console do Google Cloud.

   Acessar o Firewall

2. Na lista de regras de firewall, clique no nome da regra desejada.

3. Clique em Editar.

4. Em Registros, selecione Ativado.

5. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Flow logs disabled

Nome da categoria na API: FLOW_LOGS_DISABLED

Há uma sub-rede VPC com registros de fluxo desativados.

Os registros de fluxo de VPC registram uma amostra de fluxos de rede enviados e recebidos por instâncias de VM. Esses registros podem ser usados para monitoramento de rede, perícia forense, análise de segurança em tempo real e otimização de despesas. Para mais informações sobre registros de fluxo e o custo deles, consulte Como usar registros de fluxo da VPC.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Redes VPC no Console do Google Cloud.

   Acessar redes VPC

2. Na lista de redes, clique no nome da rede desejada.

3. Na página Detalhes da rede VPC, clique na guia Sub-redes.

4. Na lista de sub-redes, clique no nome da sub-rede indicada na descoberta.

5. Na página Detalhes da sub-rede, clique em Editar.

6. Em Registros de fluxo, selecione Ativado.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Flow logs settings not recommended

Nome da categoria na API: VPC_FLOW_LOGS_SETTINGS_NOT_RECOMMENDED

Na configuração de uma sub-rede em uma rede VPC, o serviço de registros de fluxo de VPC está desativado ou não está configurado de acordo com as recomendações do CIS Benchmark 1.3. Os registros de fluxo de VPC salvam uma amostra dos fluxos de rede enviados e recebidos por instâncias de VM que pode ser usada para detectar ameaças.

Observação: os registros de fluxo de VPC podem gerar custos, e as recomendações do CIS Benchmark não são otimizadas para economia de custos. Para reduzir custos, use um intervalo de agregação de 15 minutos e uma taxa de amostragem entre 5% e 10%, que proporciona um bom equilíbrio entre custos e detecção de ameaças. No entanto, se você usar essas configurações equilibradas, continuará recebendo essa descoberta, porque as configurações equilibradas não correspondem às recomendações atuais do CIS Benchmark.

Para mais informações sobre registros de fluxo de VPC e seu custo, consulte Como usar registros de fluxo de VPC.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Redes VPC no Console do Google Cloud.

   Acessar redes VPC

2. Na lista de redes, clique no nome da rede.

3. Na página Detalhes da rede VPC, clique na guia Sub-redes.

4. Na lista de sub-redes, clique no nome da sub-rede indicada na descoberta.

5. Na página Detalhes da sub-rede, clique em Editar.

6. Em Registros de fluxo, selecione Ativar.

   1. É possível modificar a configuração dos registros clicando no botão Configurar registros para expandir a guia. O CIS Benchmarks recomenda as seguintes configurações:
      1. Defina o Intervalo de agregação como 5 SEG.
      2. Na caixa de seleção Outros campos, selecione a opção Incluir metadados.
      3. Defina a Taxa de amostragem para 100%.
      4. Clique no botão SALVAR.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Full API access

Nome da categoria na API: FULL_API_ACCESS

Uma instância do Compute Engine está configurada para usar a conta de serviço padrão com acesso total a todas as APIs do Google Cloud.

Uma instância configurada com a conta de serviço padrão e o escopo de acesso à API definido como Permitir acesso total a todas as APIs do Cloud pode permitir que os usuários executem operações ou chamadas de API para as quais eles não têm permissões do IAM. Para mais informações, consulte Conta do serviço padrão do Compute Engine.

Importante: o procedimento a seguir muda as APIs a que a conta de serviço padrão tem acesso. Os processos ou workloads da VM que usam a conta de serviço padrão podem ser afetados. O Policy Intelligence pode ajudar você a entender como a conta de serviço padrão está sendo usada. Para mais informações, consulte Ferramentas para entender o uso da conta de serviço.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias de VMs no Console do Google Cloud.

   Acessar instâncias de VM

2. Na lista de instâncias, clique no nome da instância na descoberta.

3. Se a instância estiver em execução, clique em Parar.

4. Quando a instância for interrompida, clique em Editar.

5. Na seção Segurança e acesso, em Contas de serviço, selecione Conta de serviço padrão do Compute Engine.

6. Em Escopos de acesso, selecione Permitir acesso padrão ou Definir acesso para cada API. Isso limita as APIs que qualquer processo ou carga de trabalho que usa a conta de serviço da VM padrão pode acessar.

7. Se você selecionou Definir acesso para cada API, faça o seguinte:

   • Desative o Cloud Platform definindo-o como Nenhum.
   • Ative as APIs específicas que a conta de serviço da VM padrão precisa acessar.

8. Clique em Salvar.

9. Clique em Iniciar para iniciar a instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

HTTP load balancer

Nome da categoria na API: HTTP_LOAD_BALANCER

Uma instância do Compute Engine usa um balanceador de carga configurado para usar um proxy HTTP de destino em vez de um proxy HTTPS de destino.

Para proteger a integridade dos dados e impedir que invasores adulterem as comunicações, configure os balanceadores de carga HTTP(S) para permitir somente tráfego HTTPS. Para mais informações, consulte Visão geral do balanceamento de carga HTTP(S) externo.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Proxies de destino no console do Google Cloud.

   Acesse proxies de destino

2. Na lista de proxies de destino, clique no nome do proxy de destino na descoberta.

3. Clique no link em Mapa de URL.

4. Clique em Editar.

5. Clique em Configuração de front-end.

6. Exclua todas as configurações de IP de front-end e de porta que permitem o tráfego HTTP e crie novas configurações que permitam tráfego HTTPS.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Instance OS login disabled

Nome da categoria na API: INSTANCE_OS_LOGIN_DISABLED

O login do SO está desativado nesta instância do Compute Engine.

O login de SO ativa o gerenciamento centralizado de chave SSH com IAM e desativa a configuração de chave SSH baseada em metadados em todas as instâncias de um projeto. Saiba como instalar e configurar o login do SO.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias de VMs no Console do Google Cloud.

   Acessar instâncias de VM

2. Na lista de instâncias, clique no nome da instância na descoberta.

3. Na página Detalhes da instância carregada, clique em Interromper.

4. Depois que a instância for interrompida, clique em Editar.

5. Na seção Metadados personalizados, verifique se o item com a chave enable-oslogin tem o valor TRUE.

6. Clique em Salvar.

7. Clique em Iniciar para iniciar a instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Integrity monitoring disabled

Nome da categoria na API: INTEGRITY_MONITORING_DISABLED

O monitoramento de integridade está desativado em um cluster do GKE.

O Monitoramento de integridade permite monitorar e verificar a integridade da inicialização do ambiente de execução dos seus nós protegidos usando o Monitoring. Isso permite que você responda a falhas de integridade e impeça a implantação de nós comprometidos no cluster.

Atenção: estas etapas de correção podem interromper o ambiente de produção. Se necessário, passe cargas de trabalho, dados ou permissões para novos recursos antes de excluir recursos existentes.

Para corrigir essa descoberta, conclua as etapas a seguir:

Depois que um nó é provisionado, não é possível atualizá-lo para ativar o monitoramento de integridade. Crie um novo pool de nós com o monitoramento de integridade ativado.

1. Acesse a página Clusters do Kubernetes no console do Google Cloud.

   Acessar clusters do Kubernetes

2. Clique no nome do cluster na descoberta.

3. Clique em Adicionar pool de nós.

4. Na guia Segurança, verifique se Ativar monitoramento de integridade está ativado.

5. Clique em Criar.

6. Para migrar as cargas de trabalho dos pools de nós não compatíveis existentes para os novos pools de nós, consulte Como migrar cargas de trabalho para diferentes tipos de máquina.

7. Depois que suas cargas de trabalho forem movidas, exclua o pool de nós original não conforme.

   1. Na página de Clusters do Kubernetes, no menu Pools de nós, clique no nome do pool de nós que você quer excluir.
   2. Clique em Remover pool de nós.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Intranode visibility disabled

Nome da categoria na API: INTRANODE_VISIBILITY_DISABLED

A visibilidade intranós é desativada para um cluster do GKE.

Ativar a visibilidade intranós torna o tráfego intranós entre pods visível para os recursos de infraestrutura da rede. Com esse recurso, é possível usar a geração de registros de fluxo ou outros recursos da VPC para monitorar ou controlar o tráfego intranós. Para acessar registros, você precisa ativar os registros de fluxo de VPC na sub-rede selecionada. Para ver mais informações, consulte como usar registros de fluxo de VPC.

Atenção: estas etapas de correção podem interromper o ambiente de produção. Se necessário, passe cargas de trabalho, dados ou permissões para novos recursos antes de excluir recursos existentes.

Para corrigir essa descoberta, conclua as etapas a seguir:

Depois que um nó é provisionado, não é possível atualizá-lo para ativar o monitoramento de integridade. Crie um novo pool de nós com o monitoramento de integridade ativado.

1. Acesse a página Clusters do Kubernetes no console do Google Cloud.

   Acessar clusters do Kubernetes

2. Na seção Rede, clique em Editar visibilidade intranós na linha Visibilidade intranós.

   Se a configuração do cluster tiver sido alterada recentemente, o botão de edição poderá ser desativado. Se você não conseguir editar as configurações do cluster, aguarde alguns minutos e tente novamente.

3. Na caixa de diálogo, selecione Ativar visibilidade intranós.

4. Clique em Salvar alterações.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

IP alias disabled

Nome da categoria na API: IP_ALIAS_DISABLED

Um cluster do GKE foi criado com intervalos de IP de alias desativados.

Quando você ativa intervalos de IP de alias, os clusters do GKE alocam endereços IP de um bloco CIDR conhecido. Assim, o cluster é escalonável e interage melhor com produtos e entidades do Google Cloud. Para mais informações, consulte Visão geral sobre intervalos de IP de alias.

Para corrigir essa descoberta, conclua as etapas a seguir:

Não é possível migrar um cluster para usar IPs de alias. Para criar um novo cluster com IPs de alias ativados, faça o seguinte:

1. Acesse a página Clusters do Kubernetes no console do Google Cloud.

   Acessar clusters do Kubernetes

2. Clique em Criar.

3. No painel de navegação, em Cluster, clique em Rede.

4. Em Opções avançadas de rede, selecione Ativar roteamento de tráfego nativo de VPC (usa IP do alias).

5. Clique em Criar.

   Observação: não é possível modificar um cluster enquanto ele estiver se reconfigurando
   .

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

IP forwarding enabled

Nome da categoria na API: IP_FORWARDING_ENABLED

O encaminhamento de IP está ativado nas instâncias do Compute Engine.

Evite a perda de dados e a divulgação de informações desativando o encaminhamento do IP de pacotes de dados das VMs.

Atenção: estas etapas de correção podem interromper o ambiente de produção. Se necessário, passe cargas de trabalho, dados ou permissões para novos recursos antes de excluir recursos existentes.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias de VMs no Console do Google Cloud.

   Acessar instâncias de VM

2. Na lista de instâncias, marque a caixa ao lado do nome da instância na descoberta.

3. Clique em Excluir

4. Selecione Criar instância para criar uma nova instância e substituir a que você excluiu.

5. Para garantir que o encaminhamento de IP esteja desativado, clique em Gerenciamento, discos, rede, chaves SSH e depois em Rede.

6. Em Interfaces de rede, clique em Editar.

7. Em Encaminhamento de IP, no menu suspenso, verifique se Desativado está selecionado.

8. Especifique quaisquer outros parâmetros da instância e clique em Criar. Para mais informações, consulte Como criar e iniciar uma instância de VM.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

KMS key not rotated

Nome da categoria na API: KMS_KEY_NOT_ROTATED

A rotação não está configurada em uma chave de criptografia do Cloud KMS.

A rotação regular das chaves de criptografia oferece proteção caso uma chave fique comprometida e limita o número de mensagens criptografadas disponíveis para criptoanálise de uma versão de chave específica. Para mais informações, consulte Rotação de chaves.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Chaves do Cloud KMS no console do Google Cloud.

   Acesse as chaves do Cloud KMS

2. Clique no nome do keyring indicado na descoberta.

3. Clique no nome da chave indicada na descoberta.

4. Clique em Editar período de rotação.

5. Defina o período de rotação até o máximo de 90 dias.

6. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

KMS project has owner

Nome da categoria na API: KMS_PROJECT_HAS_OWNER

Um usuário tem permissões roles/Owner em um projeto que tem chaves criptográficas. Para mais informações, consulte Permissões e papéis.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página "IAM" no Console do Google Cloud.

   Acesse a página do IAM

2. Se necessário, selecione o projeto na descoberta.

3. Para cada membro atribuído ao papel de Proprietário:

   1. Clique em Editar.
   2. No painel Editar permissões, ao lado do papel Proprietário, clique em Excluir.
   3. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

KMS public key

Nome da categoria na API: KMS_PUBLIC_KEY

Uma cryptokey ou um keyring do Cloud KMS são públicos e acessíveis a qualquer pessoa na Internet. Para mais informações, consulte Como usar o IAM com o Cloud KMS.

Para corrigir essa descoberta, se ela estiver relacionada a uma cryptokey:

1. Acesse a página Chaves criptográficas no console do Google Cloud.

   Chaves criptográficas

2. Em Nome, selecione o keyring que contém a chave criptográfica relacionada à descoberta do Security Health Analytics.

3. Na página Detalhes do keyring carregada, marque a caixa de seleção ao lado da chave criptográfica.

4. Se o PAINEL DE INFORMAÇÕES não for exibido, clique no botão MOSTRAR PAINEL DE INFORMAÇÕES.

5. Use a caixa de filtro anterior a Papel / Membro para pesquisar membros de allUsers e allAuthenticatedUsers e clique em Excluir para remover o acesso desses membros.

Para corrigir essa descoberta, se ela estiver relacionada a um keyring:

1. Acesse a página Chaves criptográficas no console do Google Cloud.

   Chaves criptográficas

2. Encontre a linha com o keyring na descoberta e marque a caixa de seleção.

3. Se o PAINEL DE INFORMAÇÕES não for exibido, clique no botão MOSTRAR PAINEL DE INFORMAÇÕES.

4. Use a caixa de filtro anterior a Papel / Membro para pesquisar membros de allUsers e allAuthenticatedUsers e clique em Excluir para remover o acesso desses membros.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

KMS role separation

Nome da categoria na API: KMS_ROLE_SEPARATION

Essa descoberta não está disponível para ativações no nível do projeto.

Um ou mais principais têm várias permissões do Cloud KMS atribuídas. É recomendável que nenhuma conta tenha o administrador do Cloud KMS simultaneamente com outras permissões do Cloud KMS. Para mais informações, consulte Permissões e papéis.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página "IAM" no Console do Google Cloud.

   Acessar IAM

2. Para cada membro listado na descoberta, faça o seguinte:

   1. Verifique se o papel foi herdado de um recurso ou pasta da organização checando a coluna Herança. Se a coluna contiver um link para um recurso pai, clique no link para acessar a página do IAM do recurso pai.
   2. Clique em Editar ao lado de um titular.
   3. Para remover as permissões, clique em Excluir ao lado de Administrador do Cloud KMS. Se você quiser remover todas as permissões do principal, clique em Excluir ao lado de todas as outras permissões.

3. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Legacy authorization enabled

Nome da categoria na API: LEGACY_AUTHORIZATION_ENABLED

A autorização legada está ativada em clusters do GKE.

No Kubernetes, o controle de acesso baseado no papel (RBAC, na sigla em inglês) permite definir papéis com regras que contêm um conjunto de permissões e conceder permissões nos níveis do cluster e do namespace. Isso oferece maior segurança ao garantir que os usuários tenham acesso somente a recursos específicos. Considere desativar o controle de acesso baseado em atributo (ABAC, na sigla em inglês) legado.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Clusters do Kubernetes no console do Google Cloud.

   Acessar os clusters do Kubernetes

2. Selecione o cluster listado na descoberta do Security Health Analytics.

3. Clique em Editar.

   Se a configuração do cluster tiver sido alterada recentemente, o botão de edição poderá ser desativado. Se você não conseguir editar as configurações do cluster, aguarde alguns minutos e tente novamente.

4. Na lista suspensa Autorização herdada, selecione Desativada.

5. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Legacy metadata enabled

Nome da categoria na API: LEGACY_METADATA_ENABLED

Os metadados legados são ativados nos clusters do GKE.

O servidor de metadados da instância do Compute Engine expõe endpoints /0.1/ e /v1beta1/ herdados, que não impõem cabeçalhos de consulta de metadados. Esse é um recurso nas APIs /v1/ que dificulta que um invasor em potencial recupere metadados de instância. A menos que seja necessário, recomendamos desativar as APIs legadas /0.1/ e /v1beta1/.

Para mais informações, consulte Como desativar e fazer a transição a partir de APIs de metadados legados.

Para corrigir essa descoberta, conclua as etapas a seguir:

Só é possível desativar as APIs de metadados legados ao criar um novo cluster ou ao adicionar um novo pool de nós a um cluster existente. Para atualizar um cluster atual e desativar as APIs de metadados legados, consulte Como migrar cargas de trabalho para diferentes tipos de máquina.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Legacy network

Nome da categoria na API: LEGACY_NETWORK

Existe uma rede legada em um projeto.

As redes legadas não são recomendadas porque muitos dos novos recursos de segurança do Google Cloud não são compatíveis com elas. Use redes VPC. Para mais informações, consulte Redes legadas.

Atenção: estas etapas de correção podem interromper o ambiente de produção. Se necessário, passe cargas de trabalho, dados ou permissões para novos recursos antes de excluir recursos existentes.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Redes VPC no Console do Google Cloud.

   Acessar redes VPC

2. Para criar uma nova rede não legada, clique em Criar rede.

3. Volte para a página Redes VPC.

4. Na lista de redes, clique em legacy_network.

5. Na página Detalhes da rede VPC, clique em Excluir rede VPC.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Load balancer logging disabled

Nome da categoria na API: LOAD_BALANCER_LOGGING_DISABLED

A geração de registros está desativada para o serviço de back-end em um balanceador de carga.

Ativar a geração de registros para um balanceador de carga permite que você confira o tráfego de rede HTTP(S) dos seus aplicativos da Web. Saiba mais em Balanceador de carga.

Cuidado: uma taxa de amostragem alta pode resultar em custos de armazenamento mais altos para o arquivo de registros. É preciso encontrar um equilíbrio entre a taxa de amostragem e os possíveis custos de armazenamento certos para seu negócio.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Balanceamento de carga do Cloud no Console do Google Cloud.

   Acessar o Cloud Load Balancing

2. Clique no nome do balanceador de carga.

3. Clique em Editar.

4. Clique em Configuração de back-end.

5. Na página Configuração de back-end, clique em Editar.

6. Na seção Logging, selecione Ativar geração de registros e escolha a melhor taxa de amostragem para seu projeto.

7. Para concluir a edição do serviço de back-end, clique em Atualizar.

8. Para concluir a edição do balanceador de carga, clique em Atualizar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Locked retention policy not set

Nome da categoria na API: LOCKED_RETENTION_POLICY_NOT_SET

Uma política de retenção bloqueada não está definida para os registros.

Uma política de retenção bloqueada impede que os registros sejam substituídos e que o bucket de registros seja excluído. Para mais informações, consulte Bloqueio de bucket.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Navegador do Storage no console do Google Cloud.

   Acessar navegador do Storage

2. Selecione o bucket listado na descoberta do Security Health Analytics.

3. Na página Detalhes do bucket, clique na guia Retenção.

4. Se uma política de retenção não tiver sido definida, clique em Definir política de retenção.

5. Insira um período de armazenamento.

6. Clique em Save. A política de retenção é mostrada na guia Retenção.

7. Clique em Bloquear para garantir que o período de retenção não seja encurtado ou removido.

   Cuidado:bloquear uma política de retenção é um ato irreversível e só pode ser desfeito ao excluir todo o bucket. Para mais informações, consulte Bloqueio de bucket.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Log not exported

Nome da categoria na API: LOG_NOT_EXPORTED

Há um recurso que não tem um coletor de registros apropriado configurado.

O Cloud Logging ajuda você a encontrar rapidamente a causa de problemas no sistema e nos aplicativos. No entanto, por padrão, a maioria dos registros é mantida por 30 dias. Exporte cópias de todas as entradas de registro para estender o período de armazenamento. Para mais informações, consulte Visão geral das exportações de registros.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Roteador de registros no console do Google Cloud.

   Acessar o roteador de registros

2. Clique em Criar coletor.

3. Para garantir que todos os registros sejam exportados, deixe os filtros de inclusão e exclusão vazios.

4. Clique em Criar coletor.

   Observação:essas instruções criam um coletor no nível do projeto. Os coletores também podem ser criados no nível da pasta ou da organização. Para mais informações, consulte Como exportar registros com o console do Google Cloud.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Master authorized networks disabled

Nome da categoria na API: MASTER_AUTHORIZED_NETWORKS_DISABLED

As redes autorizadas do plano de controle não estão ativadas nos clusters do GKE.

Redes autorizadas do plano de controle melhoram a segurança do cluster de contêiner bloqueando o acesso de endereços IP especificados ao plano de controle do cluster. Para mais informações, consulte Como adicionar redes autorizadas para acesso ao plano de controle.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Clusters do Kubernetes no console do Google Cloud.

   Acessar os clusters do Kubernetes

2. Selecione o cluster listado na descoberta do Security Health Analytics.

3. Clique em Editar.

   Se a configuração do cluster tiver sido alterada recentemente, o botão de edição poderá ser desativado. Se você não conseguir editar as configurações do cluster, aguarde alguns minutos e tente novamente.

4. Na lista suspensa Redes autorizadas do plano de controle, selecione Ativada.

5. Clique em Adicionar rede autorizada.

6. Especifique as redes autorizadas que você quer usar.

7. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

MFA not enforced

Nome da categoria na API: MFA_NOT_ENFORCED

Essa descoberta não está disponível para ativações no nível do projeto.

A autenticação multifator, especificamente a verificação em duas etapas (2SV), está desativada para alguns usuários na organização.

A autenticação multifator pode ser usada para evitar acessos não autorizados a contas e é a ferramenta mais importante para proteger a organização contra credenciais de login comprometidas. Para mais informações, consulte Proteger a empresa com a verificação em duas etapas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Admin Console no console do Google Cloud.

   Acessar o Admin Console

2. Aplique a verificação em duas etapas em todas as unidades organizacionais.

Suprimir descobertas deste tipo

Para suprimir descobertas desse tipo, defina uma regra de desativação de som que silencia automaticamente descobertas futuras desse tipo. Para mais informações, consulte Desativar descobertas no Security Command Center.

Embora não seja uma maneira recomendada de suprimir descobertas, também é possível adicionar marcações de segurança dedicadas aos recursos para que os detectores da Análise de integridade da segurança não criem descobertas de segurança para esses recursos.

• Para evitar que essa descoberta seja ativada novamente, adicione a marcação de segurança allow_mfa_not_enforced com um valor de true ao recurso.
• Para ignorar possíveis violações em unidades organizacionais específicas, adicione a marcação de segurança excluded_orgunits ao recurso com uma lista separada por vírgulas de caminhos de unidades organizacionais no campo valor. Por exemplo, excluded_orgunits:/people/vendors/vendorA,/people/contractors/contractorA.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Network not monitored

Nome da categoria na API: NETWORK_NOT_MONITORED

Observação: o filtro de métricas com base em registros para este detector foi alterado em 27 de outubro de 2021.

As métricas e os alertas de registro não estão configurados para monitorar alterações de rede VPC.

Para detectar alterações incorretas ou não autorizadas na configuração de rede, monitore as alterações da rede VPC. Para mais informações, consulte Visão geral de métricas com base em registros.

Dependendo da quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para entender o uso do serviço e os custos dele, consulte Preços da Observabilidade do Google Cloud.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, conclua as etapas a seguir:

Criar métrica

1. Acesse a página Métricas com base em registros no console do Google Cloud.

   Acessar métricas com base em registros

2. Clique em Criar métrica.

3. Em Tipo de Métrica, selecione Contador.

4. Em Detalhes:

   1. Defina um Nome da métrica de registro.
   2. Adicione uma descrição.
   3. Definir Unidades para 1.

5. Em Seleção de filtros, copie e cole o texto a seguir na caixa Criar filtro, substituindo o texto existente, se necessário:

     resource.type="gce_network"
     AND (protoPayload.methodName:"compute.networks.insert"
     OR protoPayload.methodName:"compute.networks.patch"
     OR protoPayload.methodName:"compute.networks.delete"
     OR protoPayload.methodName:"compute.networks.removePeering"
     OR protoPayload.methodName:"compute.networks.addPeering")

6. Clique em Criar métrica. Você verá uma confirmação.

Criar política de alertas

1. No console do Google Cloud, acesse a página Métricas com base em registros.

   Acessar Métricas com base em registros

   Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Logging.

2. Na seção Métricas definidas pelo usuário, selecione a métrica que você criou na seção anterior.

3. Clique em Mais e depois em Criar alerta com base na métrica.

   A caixa de diálogo Nova condição é aberta com as opções de transformação de dados e métricas pré-preenchidas.

4. Clique em Próxima.
   1. Revise as configurações pré-preenchidas. Convém modificar o Valor do limite.
   2. Clique em Nome da condição e digite um nome para ela.
5. Clique em Next.

6. Para adicionar notificações à sua política de alertas, clique em Canais de notificação. Na caixa de diálogo, selecione um ou mais canais de notificação no menu e clique em OK.

   Para receber uma notificação quando os incidentes forem abertos ou fechados, marque Notificar sobre o fechamento de incidentes. Por padrão, as notificações são enviadas apenas quando incidentes são abertos.

7. Opcional: Atualize a Duração do fechamento automático do incidente. Este campo determina quando o Monitoring fecha incidentes na ausência de dados de métrica.
8. Opcional: clique em Documentação e adicione as informações que quer incluir em uma mensagem de notificação.
9. Clique em Nome e digite um nome para a política de alertas.
10. Clique em Criar política.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Network policy disabled

Nome da categoria na API: NETWORK_POLICY_DISABLED

A política de rede está desativada nos clusters do GKE.

Por padrão, a comunicação entre pods fica aberta. A comunicação aberta permite que os pods se conectem diretamente nos nós, com ou sem conversão de endereços de rede. Um recurso NetworkPolicy é como um firewall no nível do pod que restringe as conexões entre os pods, a menos que o recurso NetworkPolicy permita explicitamente a conexão. Aprenda a definir uma política de rede.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Clusters do Kubernetes no console do Google Cloud.

   Acessar os clusters do Kubernetes

2. Clique no nome do cluster listado na descoberta do Security Health Analytics.

3. Em Rede, na linha da política de rede do Calico Kubernetes, clique em Editar.

   Se a configuração do cluster tiver sido alterada recentemente, o botão de edição poderá ser desativado. Se você não conseguir editar as configurações do cluster, aguarde alguns minutos e tente novamente.

4. Na caixa de diálogo, selecione Ativar a política de rede do Kubernetes no Kubernetes para o plano de controle e Ativar a política de rede do Kubernetes no Calico para nós.

5. Clique em Salvar alterações.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Nodepool boot CMEK disabled

Nome da categoria na API: NODEPOOL_BOOT_CMEK_DISABLED

Os discos de inicialização nesse pool de nós não são criptografados com chaves de criptografia gerenciadas pelo cliente. As CMEK permitem que o usuário configure as chaves de criptografia padrão para discos de inicialização em um pool de nós.

Atenção: estas etapas de correção podem interromper o ambiente de produção. Se necessário, passe cargas de trabalho, dados ou permissões para novos recursos antes de excluir recursos existentes.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Clusters do Kubernetes no console do Google Cloud.

   Acessar clusters do Kubernetes

2. Na lista de clusters, clique no nome do cluster na descoberta.

3. Clique na guia Nós.

4. Para cada pool de nós default-pool, clique em Excluir.

5. Quando solicitado a confirmar, clique em Excluir.

6. Para criar novos pools de nós usando CMEK, consulte Como usar chaves de criptografia gerenciadas pelo cliente (CMEK). As CMEK geram custos adicionais relacionados ao Cloud KMS.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Nodepool secure boot disabled

Nome da categoria na API: NODEPOOL_SECURE_BOOT_DISABLED

A Inicialização segura está desativada para um cluster do GKE.

Ative a inicialização segura para os nós do GKE protegidos para verificar as assinaturas digitais dos componentes de inicialização do nó. Para mais informações, consulte Inicialização segura.

Atenção: estas etapas de correção podem interromper o ambiente de produção. Se necessário, passe cargas de trabalho, dados ou permissões para novos recursos antes de excluir recursos existentes.

Para corrigir essa descoberta, conclua as etapas a seguir:

Depois que o pool de nós é provisionado, não é possível atualizá-lo para ativar a inicialização segura. Crie um novo pool de nós com a inicialização segura ativada.

1. Acesse a página Clusters do Kubernetes no console do Google Cloud.

   Acessar clusters do Kubernetes

2. Clique no nome do cluster na descoberta.

3. Clique em Adicionar pool de nós.

4. No menu Pools de nós, faça o seguinte:

   1. Clique no nome do novo pool de nós para expandir a guia.
   2. Selecione Segurança e, em Opções protegidas, selecione Ativar inicialização segura.
   3. Clique em Criar.
   4. Para migrar as cargas de trabalho dos pools de nós não compatíveis existentes para os novos pools de nós, consulte Como migrar cargas de trabalho para diferentes tipos de máquina.
   5. Depois que suas cargas de trabalho forem movidas, exclua o pool de nós original não conforme.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Non org IAM member

Nome da categoria na API: NON_ORG_IAM_MEMBER

Um usuário de fora da organização ou do projeto tem permissões de IAM em um projeto ou organização. Saiba mais sobre as permissões do IAM.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página "IAM" no Console do Google Cloud.

   Acessar IAM

2. Marque a caixa de seleção ao lado dos usuários de fora da organização ou do projeto.

3. Clique em Remover.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Object versioning disabled

Nome da categoria na API: OBJECT_VERSIONING_DISABLED

O controle de versão de objeto não está ativado em um bucket de armazenamento em que os coletores são configurados.

O Cloud Storage oferece o recurso de controle de versões de objetos para recuperar objetos que são excluídos ou substituídos. Ative o controle de versão de objetos para evitar que os dados do Cloud Storage sejam substituídos ou excluídos acidentalmente. Saiba como ativar o controle de versão de objetos.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, use a flag --versioning em um comando gcloud storage buckets update com o valor apropriado:

    gcloud storage buckets update gs://finding.assetDisplayName --versioning

Substitua finding.assetDisplayName pelo nome do bucket relevante.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Open Cassandra port

Nome da categoria na API: OPEN_CASSANDRA_PORT

Regras de firewall que permitem que qualquer endereço IP se conecte às portas do Cassandra podem expor os serviços do Cassandra a invasores. Para mais informações, consulte Visão geral das regras de firewall da VPC.

As portas de serviço do Cassandra são:

• TCP - 7000, 7001, 7199, 8888, 9042, 9160, 61620, 61621

Essa descoberta é gerada para regras de firewall vulneráveis, mesmo que você desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam você sobre configurações não seguras que permitirão tráfego indesejado se ativadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Firewall no Console do Google Cloud.

   Acessar o Firewall

2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.

3. Clique em Editar.

4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.

5. Adicione endereços ou intervalos de IP específicos que você quer permitir que se conectem à instância.

6. Adicione protocolos e portas específicos que você quer abrir na instância.

7. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Open ciscosecure websm port

Nome da categoria na API: OPEN_CISCOSECURE_WEBSM_PORT

Regras de firewall que permitem que qualquer endereço IP se conecte às portas CiscoSecure/WebSM podem expor os serviços CiscoSecure/WebSM a invasores. Para mais informações, consulte Visão geral das regras de firewall da VPC.

As portas de serviço CiscoSecure/WebSM são:

• TCP - 9090

Essa descoberta é gerada para regras de firewall vulneráveis, mesmo que você desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam você sobre configurações não seguras que permitirão tráfego indesejado se ativadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Firewall no Console do Google Cloud.

   Acessar o Firewall

2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.

3. Clique em Editar.

4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.

5. Adicione endereços ou intervalos de IP específicos que você quer permitir que se conectem à instância.

6. Adicione protocolos e portas específicos que você quer abrir na instância.

7. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Open directory services port

Nome da categoria na API: OPEN_DIRECTORY_SERVICES_PORT

Regras de firewall que permitem que qualquer endereço IP se conecte a portas do Directory podem expor os serviços do Directory a invasores. Para mais informações, consulte Visão geral das regras de firewall da VPC.

As portas de serviço do Directory são:

• TCP - 445
• UDP - 445

Essa descoberta é gerada para regras de firewall vulneráveis, mesmo que você desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam você sobre configurações não seguras que permitirão tráfego indesejado se ativadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Firewall no Console do Google Cloud.

   Acessar o Firewall

2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.

3. Clique em Editar.

4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.

5. Adicione endereços ou intervalos de IP específicos que você quer permitir que se conectem à instância.

6. Adicione protocolos e portas específicos que você quer abrir na instância.

7. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Open DNS port

Nome da categoria na API: OPEN_DNS_PORT

Regras de firewall que permitem que qualquer endereço IP se conecte a portas DNS podem expor os serviços DNS a invasores. Para mais informações, consulte Visão geral das regras de firewall da VPC.

As portas de serviço DNS são:

• TCP - 53
• UDP - 53

Essa descoberta é gerada para regras de firewall vulneráveis, mesmo que você desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam você sobre configurações não seguras que permitirão tráfego indesejado se ativadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Firewall no Console do Google Cloud.

   Acessar o Firewall

2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.

3. Clique em Editar.

4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.

5. Adicione endereços ou intervalos de IP específicos que você quer permitir que se conectem à instância.

6. Adicione protocolos e portas específicos que você quer abrir na instância.

7. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Open Elasticsearch port

Nome da categoria na API: OPEN_ELASTICSEARCH_PORT

Regras de firewall que permitem que qualquer endereço IP se conecte a portas do Elasticsearch podem expor os serviços do Elasticsearch a invasores. Para mais informações, consulte Visão geral das regras de firewall da VPC.

As portas de serviço do Elasticsearch são:

• TCP - 9200, 9300

Essa descoberta é gerada para regras de firewall vulneráveis, mesmo que você desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam você sobre configurações não seguras que permitirão tráfego indesejado se ativadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Firewall no Console do Google Cloud.

   Acessar o Firewall

2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.

3. Clique em Editar.

4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.

5. Adicione endereços ou intervalos de IP específicos que você quer permitir que se conectem à instância.

6. Adicione protocolos e portas específicos que você quer abrir na instância.

7. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Open firewall

Nome da categoria na API: OPEN_FIREWALL

Regras de firewall que permitem conexões de todos os endereços IP, como 0.0.0.0/0, ou de todas as portas podem expor os recursos a ataques de fontes indesejadas desnecessariamente. Remova essas regras ou determine explicitamente o escopo delas para os intervalos ou portas de IP de origem pretendidos. Por exemplo, em aplicativos destinados a ser públicos, considere restringir as portas permitidas às necessárias para o aplicativo, como a 80 e 443. Caso o aplicativo precise permitir conexões de todos os endereços IP ou portas, considere adicionar o recurso a uma lista de permissões. Saiba mais sobre Como atualizar regras de firewall.

Essa descoberta é gerada para regras de firewall vulneráveis, mesmo que você desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam você sobre configurações não seguras que permitirão tráfego indesejado se ativadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Regras de firewall no console do Google Cloud.

   Acessar as regras de firewall

2. Clique na regra de firewall listada na descoberta do Security Health Analytics e depois em Editar.

3. Em Intervalos de IP de origem, edite os valores de IP para restringir o intervalo de IPs permitido.

4. Em Protocolos e portas, selecione Protocolos e portas especificados, selecione os protocolos permitidos e insira as portas permitidas.

5. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Open FTP port

Nome da categoria na API: OPEN_FTP_PORT

Regras de firewall que permitem que qualquer endereço IP se conecte a portas do FTP podem expor os serviços do FTP a invasores. Para mais informações, consulte Visão geral das regras de firewall da VPC.

As portas de serviço do FTP são:

• TCP - 21

Essa descoberta é gerada para regras de firewall vulneráveis, mesmo que você desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam você sobre configurações não seguras que permitirão tráfego indesejado se ativadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Firewall no Console do Google Cloud.

   Acessar o Firewall

2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.

3. Clique em Editar.

4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.

5. Adicione endereços ou intervalos de IP específicos que você quer permitir que se conectem à instância.

6. Adicione protocolos e portas específicos que você quer abrir na instância.

7. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Open group IAM member

Nome da categoria na API: OPEN_GROUP_IAM_MEMBER

Um ou mais principais que têm acesso a uma organização, projeto ou pasta são contas do Grupos do Google que podem ser mescladas sem aprovação.

Os clientes do Google Cloud podem usar os Grupos do Google para gerenciar papéis e permissões para membros das organizações ou aplicar políticas de acesso a coleções de usuários. Em vez de conceder papéis diretamente aos membros, os administradores podem conceder papéis e permissões aos Grupos do Google e, em seguida, adicionar membros a grupos específicos. Os membros do grupo herdam todos os papéis e permissões de um grupo, o que permite que os membros acessem recursos e serviços específicos.

Se uma conta aberta do Grupos do Google for usada como principal em uma vinculação do IAM, qualquer pessoa poderá herdar o papel associado apenas participando do grupo direta ou indiretamente (por meio de um subgrupo). Recomendamos revogar as funções dos grupos abertos ou restringir o acesso a eles.

Para corrigir essa descoberta, execute um dos procedimentos a seguir.

Remover o grupo da política do IAM

Atenção: estas etapas de correção podem interromper o ambiente de produção. Se necessário, passe cargas de trabalho, dados ou permissões para novos recursos antes de excluir recursos existentes.

1. Acesse a página "IAM" no Console do Google Cloud.

   Acesse o IAM

2. Se necessário, selecione o projeto, a pasta ou a organização na descoberta.

3. Revogue a função de cada grupo aberto identificado na descoberta.

Restringir o acesso aos grupos abertos

1. Faça login no Grupos do Google.
2. Atualize as configurações de cada grupo aberto e dos respectivos subgrupos para especificar quem pode participar do grupo e quem precisa aprová-lo.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Open HTTP port

Nome da categoria na API: OPEN_HTTP_PORT

Regras de firewall que permitem que qualquer endereço IP se conecte a portas HTTP podem expor os serviços HTTP a invasores. Para mais informações, consulte Visão geral das regras de firewall da VPC.

As portas de serviço HTTP são:

• TCP - 80

Essa descoberta é gerada para regras de firewall vulneráveis, mesmo que você desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam você sobre configurações não seguras que permitirão tráfego indesejado se ativadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Firewall no Console do Google Cloud.

   Acessar o Firewall

2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.

3. Clique em Editar.

4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.

5. Adicione endereços ou intervalos de IP específicos que você quer permitir que se conectem à instância.

6. Adicione protocolos e portas específicos que você quer abrir na instância.

7. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Open LDAP port

Nome da categoria na API: OPEN_LDAP_PORT

Regras de firewall que permitem que qualquer endereço IP se conecte a portas LDAP podem expor os serviços LDAP a invasores. Para mais informações, consulte Visão geral das regras de firewall da VPC.

As portas de serviço LDAP são:

• TCP - 389, 636
• UDP - 389

Essa descoberta é gerada para regras de firewall vulneráveis, mesmo que você desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam você sobre configurações não seguras que permitirão tráfego indesejado se ativadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Firewall no Console do Google Cloud.

   Acessar o Firewall

2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.

3. Clique em Editar.

4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.

5. Adicione endereços ou intervalos de IP específicos que você quer permitir que se conectem à instância.

6. Adicione protocolos e portas específicos que você quer abrir na instância.

7. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Open Memcached port

Nome da categoria na API: OPEN_MEMCACHED_PORT

Regras de firewall que permitem que qualquer endereço IP se conecte a portas do Memcached podem expor os serviços do Memcached a invasores. Para mais informações, consulte Visão geral das regras de firewall da VPC.

As portas de serviço do Memcached são:

• TCP - 11211, 11214, 11215
• UDP - 11211, 11214, 11215

Essa descoberta é gerada para regras de firewall vulneráveis, mesmo que você desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam você sobre configurações não seguras que permitirão tráfego indesejado se ativadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Firewall no Console do Google Cloud.

   Acessar o Firewall

2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.

3. Clique em Editar.

4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.

5. Adicione endereços ou intervalos de IP específicos que você quer permitir que se conectem à instância.

6. Adicione protocolos e portas específicos que você quer abrir na instância.

7. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Open MongoDB port

Nome da categoria na API: OPEN_MONGODB_PORT

Regras de firewall que permitem que qualquer endereço IP se conecte a portas do MongoDB podem expor os serviços do MongoDB a invasores. Para mais informações, consulte Visão geral das regras de firewall da VPC.

As portas de serviço do MongoDB são:

• TCP - 27017, 27018, 27019

Essa descoberta é gerada para regras de firewall vulneráveis, mesmo que você desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam você sobre configurações não seguras que permitirão tráfego indesejado se ativadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Firewall no Console do Google Cloud.

   Acessar o Firewall

2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.

3. Clique em Editar.

4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.

5. Adicione endereços ou intervalos de IP específicos que você quer permitir que se conectem à instância.

6. Adicione protocolos e portas específicos que você quer abrir na instância.

7. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Open MySQL port

Nome da categoria na API: OPEN_MYSQL_PORT

Regras de firewall que permitem que qualquer endereço IP se conecte a portas do MySQL podem expor os serviços do MySQL a invasores. Para mais informações, consulte Visão geral das regras de firewall da VPC.

As portas de serviço do MySQL são:

• TCP - 3306

Essa descoberta é gerada para regras de firewall vulneráveis, mesmo que você desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam você sobre configurações não seguras que permitirão tráfego indesejado se ativadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Firewall no Console do Google Cloud.

   Acessar o Firewall

2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.

3. Clique em Editar.

4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.

5. Adicione endereços ou intervalos de IP específicos que você quer permitir que se conectem à instância.

6. Adicione protocolos e portas específicos que você quer abrir na instância.

7. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Open NetBIOS port

Nome da categoria na API: `OPEN_NETBIOS_PORT

Regras de firewall que permitem que qualquer endereço IP se conecte a portas do NetBIOS podem expor os serviços do NetBIOS a invasores. Para mais informações, consulte Visão geral das regras de firewall da VPC.

As portas de serviço do NetBIOS são:

• TCP - 137, 138, 139
• UDP - 137, 138, 139

Essa descoberta é gerada para regras de firewall vulneráveis, mesmo que você desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam você sobre configurações não seguras que permitirão tráfego indesejado se ativadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Firewall no Console do Google Cloud.

   Acessar o Firewall

2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.

3. Clique em Editar.

4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.

5. Adicione endereços ou intervalos de IP específicos que você quer permitir que se conectem à instância.

6. Adicione protocolos e portas específicos que você quer abrir na instância.

7. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Open OracleDB port

Nome da categoria na API: OPEN_ORACLEDB_PORT

Regras de firewall que permitem que qualquer endereço IP se conecte a portas do OracleDB podem expor os serviços do OracleDB a invasores. Para mais informações, consulte Visão geral das regras de firewall da VPC.

As portas de serviço do OracleDB são:

• TCP - 1521, 2483, 2484
• UDP - 2483, 2484

Essa descoberta é gerada para regras de firewall vulneráveis, mesmo que você desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam você sobre configurações não seguras que permitirão tráfego indesejado se ativadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Firewall no Console do Google Cloud.

   Acessar o Firewall

2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.

3. Clique em Editar.

4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.

5. Adicione endereços ou intervalos de IP específicos que você quer permitir que se conectem à instância.

6. Adicione protocolos e portas específicos que você quer abrir na instância.

7. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Open POP3 port

Nome da categoria na API: OPEN_POP3_PORT

Regras de firewall que permitem que qualquer endereço IP se conecte a portas POP3 podem expor os serviços POP3 a invasores. Para mais informações, consulte Visão geral das regras de firewall da VPC.

As portas de serviço POP3 são:

• TCP - 110

Essa descoberta é gerada para regras de firewall vulneráveis, mesmo que você desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam você sobre configurações não seguras que permitirão tráfego indesejado se ativadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Firewall no Console do Google Cloud.

   Acessar o Firewall

2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.

3. Clique em Editar.

4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.

5. Adicione endereços ou intervalos de IP específicos que você quer permitir que se conectem à instância.

6. Adicione protocolos e portas específicos que você quer abrir na instância.

7. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Open PostgreSQL port

Nome da categoria na API: OPEN_POSTGRESQL_PORT

Regras de firewall que permitem que qualquer endereço IP se conecte a portas do PostgreSQL podem expor os serviços do PostgreSQL a invasores. Para mais informações, consulte Visão geral das regras de firewall da VPC.

As portas de serviço do PostgreSQL são:

• TCP - 5432
• UDP - 5432

Essa descoberta é gerada para regras de firewall vulneráveis, mesmo que você desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam você sobre configurações não seguras que permitirão tráfego indesejado se ativadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Firewall no Console do Google Cloud.

   Acessar o Firewall

2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.

3. Clique em Editar.

4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.

5. Adicione endereços ou intervalos de IP específicos que você quer permitir que se conectem à instância.

6. Adicione protocolos e portas específicos que você quer abrir na instância.

7. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Open RDP port

Nome da categoria na API: OPEN_RDP_PORT

Regras de firewall que permitem que qualquer endereço IP se conecte a portas RDP podem expor os serviços RDP a invasores. Para mais informações, consulte Visão geral das regras de firewall da VPC.

As portas de serviço RDP são:

• TCP - 3389
• UDP - 3389

Essa descoberta é gerada para regras de firewall vulneráveis, mesmo que você desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam você sobre configurações não seguras que permitirão tráfego indesejado se ativadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Firewall no Console do Google Cloud.

   Acessar o Firewall

2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.

3. Clique em Editar.

4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.

5. Adicione endereços ou intervalos de IP específicos que você quer permitir que se conectem à instância.

6. Adicione protocolos e portas específicos que você quer abrir na instância.

7. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Open Redis port

Nome da categoria na API: OPEN_REDIS_PORT

Regras de firewall que permitem que qualquer endereço IP se conecte a portas do Redis podem expor os serviços do Redis a invasores. Para mais informações, consulte Visão geral das regras de firewall da VPC.

As portas de serviço do Redis são:

• TCP - 6379

Essa descoberta é gerada para regras de firewall vulneráveis, mesmo que você desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam você sobre configurações não seguras que permitirão tráfego indesejado se ativadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Firewall no Console do Google Cloud.

   Acessar o Firewall

2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.

3. Clique em Editar.

4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.

5. Adicione endereços ou intervalos de IP específicos que você quer permitir que se conectem à instância.

6. Adicione protocolos e portas específicos que você quer abrir na instância.

7. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Open SMTP port

Nome da categoria na API: OPEN_SMTP_PORT

Regras de firewall que permitem que qualquer endereço IP se conecte a portas SMTP podem expor os serviços SMTP a invasores. Para mais informações, consulte Visão geral das regras de firewall da VPC.

As portas de serviço SMTP são:

• TCP - 25

Essa descoberta é gerada para regras de firewall vulneráveis, mesmo que você desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam você sobre configurações não seguras que permitirão tráfego indesejado se ativadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Firewall no Console do Google Cloud.

   Acessar o Firewall

2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.

3. Clique em Editar.

4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.

5. Adicione endereços ou intervalos de IP específicos que você quer permitir que se conectem à instância.

6. Adicione protocolos e portas específicos que você quer abrir na instância.

7. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Open SSH port

Nome da categoria na API: OPEN_SSH_PORT

Regras de firewall que permitem que qualquer endereço IP se conecte a portas SSH podem expor os serviços SSH a invasores. Para mais informações, consulte Visão geral das regras de firewall da VPC.

As portas de serviço SSH são:

• SCTP - 22
• TCP - 22

Essa descoberta é gerada para regras de firewall vulneráveis, mesmo que você desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam você sobre configurações não seguras que permitirão tráfego indesejado se ativadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Firewall no Console do Google Cloud.

   Acessar o Firewall

2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.

3. Clique em Editar.

4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.

5. Adicione endereços ou intervalos de IP específicos que você quer permitir que se conectem à instância.

6. Adicione protocolos e portas específicos que você quer abrir na instância.

7. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Open Telnet port

Nome da categoria na API: OPEN_TELNET_PORT

Regras de firewall que permitem que qualquer endereço IP se conecte a portas Telnet podem expor os serviços Telnet a invasores. Para mais informações, consulte Visão geral das regras de firewall da VPC.

As portas de serviço Telnet são:

• TCP - 23

Essa descoberta é gerada para regras de firewall vulneráveis, mesmo que você desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam você sobre configurações não seguras que permitirão tráfego indesejado se ativadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Firewall no Console do Google Cloud.

   Acessar o Firewall

2. Na lista de regras de firewall, clique no nome da regra de firewall na descoberta.

3. Clique em Editar.

4. Em Intervalos de IP de origem, exclua 0.0.0.0/0.

5. Adicione endereços ou intervalos de IP específicos que você quer permitir que se conectem à instância.

6. Adicione protocolos e portas específicos que você quer abrir na instância.

7. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Org policy Confidential VM policy

Nome da categoria na API: ORG_POLICY_CONFIDENTIAL_VM_POLICY

Um recurso do Compute Engine não está em conformidade com a política da organização constraints/compute.restrictNonConfidentialComputing. Para mais informações sobre essa restrição da política da organização, consulte Como aplicar restrições de política da organização.

A organização exige que o serviço de VM confidencial da VM esteja ativado. As VMs que não têm esse serviço ativado não usarão criptografia de memória em tempo de execução, expondo-as a ataques de memória durante o tempo de execução.

Observação: a VM confidencial incorre em custos adicionais no preço do Compute Engine. Para saber mais informações, consulte Preços.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias de VMs no Console do Google Cloud.

   Acessar instâncias de VM

2. Na lista de instâncias, clique no nome da instância na descoberta.

3. Se a VM não exigir o serviço de VM confidencial, mova-a para uma nova pasta ou projeto.

4. Se a VM exigir a VM confidencial, clique em Excluir.

5. Para criar uma nova instância com a VM confidencial ativada, consulte Guia de início rápido: como criar uma instância de VM confidencial.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Org policy location restriction

Nome da categoria na API: ORG_POLICY_LOCATION_RESTRICTION

A restrição da Política da Organização gcp.resourceLocations permite restringir a criação de novos recursos às Regiões do Cloud selecionadas. Para mais informações, consulte Como restringir locais de recursos.

Observação: as restrições de local de recursos não são aplicadas retroativamente. Portanto, se os valores de restrição mudarem, os recursos existentes não serão alterados. As descobertas de ORG_POLICY_LOCATION_RESTRICTION poderão ser geradas se os locais dos recursos atuais violarem novas restrições.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, conclua as etapas a seguir:

O detector ORG_POLICY_LOCATION_RESTRICTION abrange muitos tipos de recursos, e as instruções de correção são diferentes para cada recurso. A abordagem geral para corrigir violações de local inclui o seguinte:

1. Copiar, migrar ou fazer backup do recurso fora da região ou os dados dele em um recurso que está na região. Leia a documentação de serviços individuais para receber instruções sobre como migrar recursos.
2. Excluir o recurso original fora da região ou dados dele.

Essa abordagem não é possível para todos os tipos de recursos. Para orientação, consulte as recomendações personalizadas fornecidas na descoberta.

Outras considerações

Ao corrigir essa descoberta, considere o seguinte.

Recursos gerenciados

Às vezes, os ciclos de vida dos recursos são gerenciados e controlados por outros recursos. Por exemplo, um grupo gerenciado de instâncias do Compute Engine cria e destrói instâncias do Compute Engine de acordo com a política de escalonamento automático do grupo de instâncias. Se os recursos gerenciados e de gerenciamento estiverem no escopo da aplicação do local, ambos poderão ser sinalizados como violações da Política da organização. A correção das descobertas dos recursos gerenciados deve ser feita no recurso de gerenciamento para garantir a estabilidade operacional.

Recursos em uso

Alguns recursos são usados por outros recursos. Por exemplo, um disco do Compute Engine anexado a uma instância do Compute Engine em execução é considerado em uso pela instância. Se o recurso em uso violar a Política de organização do local, você precisará garantir que ele não esteja em uso antes de resolver a violação do local.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

OS login disabled

Nome da categoria na API: OS_LOGIN_DISABLED

O login do SO está desativado nesta instância do Compute Engine.

O login de SO ativa o gerenciamento centralizado de chave SSH com IAM e desativa a configuração de chave SSH baseada em metadados em todas as instâncias de um projeto. Saiba como instalar e configurar o login do SO.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Metadados no console do Google Cloud.

   Acessar a página "Metadados"

2. Clique em Editar e depois clique em Adicionar item.

3. Adicione um item com a chave enable-oslogin e o valor TRUE.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Over privileged account

Nome da categoria na API: OVER_PRIVILEGED_ACCOUNT

Um nó do GKE está usando o nó de serviço padrão do Compute Engine, que tem acesso amplo por padrão e pode ter privilégios em excesso para executar o cluster do GKE.

Para corrigir essa descoberta, conclua as etapas a seguir:

Siga as instruções para Usar contas de serviço do Google com privilégios mínimos.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Over privileged scopes

Nome da categoria na API: OVER_PRIVILEGED_SCOPES

Uma conta de serviço do nó tem escopos de acesso amplos.

Escopos de acesso são o método legado de especificação das permissões da sua instância. Para reduzir a possibilidade de um escalonamento de privilégios em um ataque, crie e use uma conta de serviço com privilégios mínimos para executar o cluster do GKE.

Para corrigir essa descoberta, siga as instruções em Usar contas de serviço do Google com privilégio mínimo.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Over privileged service account user

Nome da categoria na API: OVER_PRIVILEGED_SERVICE_ACCOUNT_USER

Um usuário tem os papéis iam.serviceAccountUser ou iam.serviceAccountTokenCreator no nível do projeto, da pasta ou da organização, e não para uma conta de serviço específica.

Conceder esses papéis a um usuário de um projeto, uma pasta ou uma organização fornece a ele acesso a todas as contas de serviço atuais e futuras nesse escopo. Isso pode resultar em escalonamento não intencional de privilégios. Para mais informações, consulte Permissões de contas de serviço.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página "IAM" no Console do Google Cloud.

   Acesse a página do IAM

2. Se necessário, selecione o projeto, a pasta ou a organização na descoberta.

3. Para cada membro atribuído roles/iam.serviceAccountUser ou roles/iam.serviceAccountTokenCreator, faça o seguinte:

   1. Clique em Editar.
   2. No painel Editar permissões, ao lado dos papéis, clique em Excluir.
   3. Clique em Salvar.

4. Siga este guia para conceder a usuários individuais permissão para personificar uma única conta de serviço. Você precisará seguir o guia para cada conta de serviço à qual pretende conceder a permissão de personificação.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Owner not monitored

Nome da categoria na API: OWNER_NOT_MONITORED

Métricas e alertas de registros não são configurados para monitorar atribuições ou alterações de propriedade do projeto.

O papel de Proprietário do IAM tem o nível mais alto de privilégio em um projeto. Para proteger seus recursos, configure alertas para receber notificações quando novos proprietários forem adicionados ou removidos. Para mais informações, consulte Visão geral de métricas com base em registros.

Dependendo da quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para entender o uso do serviço e os custos dele, consulte Preços da Observabilidade do Google Cloud.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, conclua as etapas a seguir:

Criar métrica

1. Acesse a página Métricas com base em registros no console do Google Cloud.

   Acessar métricas com base em registros

2. Clique em Criar métrica.

3. Em Tipo de Métrica, selecione Contador.

4. Em Detalhes:

   1. Defina um Nome da métrica de registro.
   2. Adicione uma descrição.
   3. Definir Unidades para 1.

5. Em Seleção de filtros, copie e cole o texto a seguir na caixa Criar filtro, substituindo o texto existente, se necessário:

     (protoPayload.serviceName="cloudresourcemanager.googleapis.com")
     AND (ProjectOwnership OR projectOwnerInvitee)
     OR (protoPayload.serviceData.policyDelta.bindingDeltas.action="REMOVE"
     AND protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner")
     OR (protoPayload.serviceData.policyDelta.bindingDeltas.action="ADD"
     AND protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner")

6. Clique em Criar métrica. Você verá uma confirmação.

Criar política de alertas

1. No console do Google Cloud, acesse a página Métricas com base em registros.

   Acessar Métricas com base em registros

   Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Logging.

2. Na seção Métricas definidas pelo usuário, selecione a métrica que você criou na seção anterior.

3. Clique em Mais e depois em Criar alerta com base na métrica.

   A caixa de diálogo Nova condição é aberta com as opções de transformação de dados e métricas pré-preenchidas.

4. Clique em Próxima.
   1. Revise as configurações pré-preenchidas. Convém modificar o Valor do limite.
   2. Clique em Nome da condição e digite um nome para ela.
5. Clique em Next.

6. Para adicionar notificações à sua política de alertas, clique em Canais de notificação. Na caixa de diálogo, selecione um ou mais canais de notificação no menu e clique em OK.

   Para receber uma notificação quando os incidentes forem abertos ou fechados, marque Notificar sobre o fechamento de incidentes. Por padrão, as notificações são enviadas apenas quando incidentes são abertos.

7. Opcional: Atualize a Duração do fechamento automático do incidente. Este campo determina quando o Monitoring fecha incidentes na ausência de dados de métrica.
8. Opcional: clique em Documentação e adicione as informações que quer incluir em uma mensagem de notificação.
9. Clique em Nome e digite um nome para a política de alertas.
10. Clique em Criar política.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Pod security policy disabled

Nome da categoria na API: POD_SECURITY_POLICY_DISABLED

Este PodSecurityPolicy está desativado em um cluster do GKE.

Um PodSecurityPolicy é um recurso controlador de admissão que valida solicitações para criar e atualizar pods em um cluster. Os clusters não aceitarão pods que não atenderem às condições definidas no PodSecurityPolicy.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, defina e autorize PodSecurityPolicies e ative o controlador PodSecurityPolicy. Para instruções, consulte Como usar PodSecurityPolicies.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Primitive roles used

Nome da categoria na API: PRIMITIVE_ROLES_USED

Um usuário tem um dos seguintes papéis básicos do IAM: roles/owner, roles/editor ou roles/viewer. Esses papéis são muito permissivos e não devem ser usados. Eles devem ser atribuídos somente por projeto.

Saiba mais em Noções básicas sobre papéis.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página de políticas do IAM no console do Google Cloud.

   Acesse a política de IAM

2. Para cada usuário com um papel primário, considere usar papéis mais granulares.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Private cluster disabled

Nome da categoria na API: PRIVATE_CLUSTER_DISABLED

Um cluster do GKE tem um cluster particular desativado.

Clusters particulares só permitem que os nós tenham endereços IP internos. Esse recurso limita o acesso à Internet de saída para nós. Se um nó de cluster não tiver um endereço IP público, ele não poderá ser descoberto nem exposto à Internet pública. Ainda é possível rotear o tráfego para um nó usando um balanceador de carga interno. Para mais informações, consulte Clusters particulares.

Não é possível tornar privado um cluster atual. Para corrigir essa descoberta, crie um novo cluster privado:

1. Acesse a página Clusters do Kubernetes no console do Google Cloud.

   Acessar os clusters do Kubernetes

2. Clique em Criar cluster.

3. No menu de navegação, em Cluster, selecione Rede.

4. Selecione o botão de opção Cluster particular.

5. Em Opções de rede avançadas, marque a caixa de seleção Ativar roteamento de tráfego nativo de VPC (usa IP do alias).

6. Clique em Criar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Private Google access disabled

Nome da categoria na API: PRIVATE_GOOGLE_ACCESS_DISABLED

Há sub-redes privadas sem acesso às APIs públicas do Google.

O acesso privado do Google permite que instâncias de VM apenas com endereços IP internos (particulares) acessem os endereços IP públicos das APIs e dos serviços do Google.

Para mais informações, consulte Como configurar o Acesso privado do Google.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Redes VPC no Console do Google Cloud.

   Acessar redes VPC

2. Na lista de redes, clique no nome da rede desejada.

3. Na página Detalhes da rede VPC, clique na guia Sub-redes.

4. Na lista de sub-redes, clique no nome da sub-rede associada ao cluster do Kubernetes na descoberta.

5. Na página Detalhes da sub-rede, clique em Editar.

6. Em Acesso privado do Google, selecione Ativado.

7. Clique em Save.

8. Para remover IPs públicos (externos) das instâncias de VM cujo tráfego externo é apenas para APIs do Google, consulte Como cancelar a atribuição de um endereço IP externo estático.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Public bucket ACL

Nome da categoria na API: PUBLIC_BUCKET_ACL

Um bucket é público e qualquer pessoa na Internet pode acessá-lo.

Para mais informações, consulte Visão geral do controle de acesso.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Navegador do Storage no console do Google Cloud.

   Acessar navegador do Storage

2. Selecione o bucket listado na descoberta do Security Health Analytics.

3. Na página Detalhes do bucket, clique na guia Permissões.

4. Ao lado de Visualizar por, clique em Papéis.

5. Na caixa Filtro, pesquise allUsers e allAuthenticatedUsers.

6. Clique em Excluir para remover todas as permissões do IAM concedidas a allUsers e allAuthenticatedUsers.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Public Compute image

Nome da categoria na API: PUBLIC_COMPUTE_IMAGE

Uma imagem do Compute Engine é pública e qualquer pessoa na Internet pode acessá-la. allUsers representa qualquer pessoa na Internet e allAuthenticatedUsers representa qualquer pessoa com a autenticação da conta do Google; nenhum deles está restrito aos usuários dentro da organização.

As imagens do Compute Engine podem conter informações confidenciais, como chaves de criptografia ou software licenciado. Essas informações não devem ser acessadas publicamente. Se você pretende tornar pública esta imagem do Compute, verifique se ela não contém informações confidenciais.

Para mais informações, consulte Visão geral do controle de acesso.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página de imagens do Compute Engine no console do Google Cloud.

   Acesse imagens do Compute Engine

2. Selecione a caixa ao lado da imagem public-image e clique em Mostrar painel de informações.

3. Na caixa Filtro, pesquise os membros de allUsers e allAuthenticatedUsers.

4. Expanda o papel de que você quer remover usuários.

5. Clique em Excluir para remover um usuário desse papel.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Public dataset

Nome da categoria na API: PUBLIC_DATASET

Um conjunto de dados do BigQuery é público e acessível a qualquer pessoa na Internet. O membro do IAM allUsers representa qualquer pessoa na Internet, e allAuthenticatedUsers representa qualquer pessoa conectada a um serviço do Google. Nenhum deles se limita a usuários dentro da organização.

Para mais informações, consulte Como controlar o acesso a conjuntos de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Conjunto de dados do BigQuery no console do Google Cloud.

   Ir para o conjunto de dados do BigQuery

2. Na lista de conjuntos de dados, clique no nome do conjunto de dados identificado na descoberta. O painel Informações do conjunto de dados é aberto.

3. Próximo à parte superior do painel Informações do conjunto de dados, clique em COMPARTILHAMENTO.

4. No menu suspenso, clique em Permissões.

5. No painel Permissões do conjunto de dados, insira allUsers e allAuthenticatedUsers e remova o acesso desses participantes.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Public IP address

Nome da categoria na API: PUBLIC_IP_ADDRESS

Uma instância do Compute Engine tem um endereço IP público.

Para reduzir a superfície de ataque das organizações, evite atribuir endereços IP públicos às VMs. As instâncias interrompidas ainda podem ser sinalizadas com uma descoberta de IP público, por exemplo, se as interfaces de rede estiverem configuradas para atribuir um IP público temporário no início. Certifique-se de que as configurações de rede de instâncias interrompidas não incluem acesso externo.

Para mais informações, consulte Como conectar-se de maneira segura às instâncias de VM.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias de VMs no Console do Google Cloud.

   Acessar Instâncias de VM

2. Na lista de instâncias, marque a caixa ao lado do nome da instância na descoberta.

3. Clique em Editar.

4. Para cada interface em Interfaces de rede, clique em Editar e defina IP externo como Nenhum.

5. Clique em Concluído e depois em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Public log bucket

Nome da categoria na API: PUBLIC_LOG_BUCKET

Essa descoberta não está disponível para ativações no nível do projeto.

Um bucket de armazenamento é público e usado como um coletor de registros, o que significa que qualquer pessoa na Internet pode acessar os registros armazenados nesse bucket. allUsers representa qualquer pessoa na Internet, e allAuthenticatedUsers representa qualquer pessoa que esteja conectada em um serviço do Google. Nenhum deles se limita a usuários dentro da organização.

Para mais informações, consulte Visão geral do controle de acesso.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página do navegador do Cloud Storageno console do Google Cloud.

   Ir para o Navegador do Cloud Storage

2. Na lista de buckets, clique no nome do bucket indicado na descoberta.

3. Clique na guia Permissões..

4. Remova allUsers e allAuthenticatedUsers da lista de membros.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Public SQL instance

Nome da categoria na API: PUBLIC_SQL_INSTANCE

A instância do SQL tem 0.0.0.0/0 como uma rede permitida. Isso significa que qualquer cliente IPv4 é capaz de passar pelo firewall de rede e tentar fazer login na instância, inclusive clientes que você não queria permitir. Os clientes ainda precisarão de credenciais válidas para fazerem login na instância.

Para mais informações, consulte Como autorizar com redes autorizadas.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. No painel de navegação, clique em Conexões.

5. Em Redes autorizadas, exclua 0.0.0.0/0 e adicione endereços ou intervalos de IP específicos que você quer permitir que se conectem à instância.

6. Clique em Concluído e depois em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Pubsub CMEK disabled

Nome da categoria na API: PUBSUB_CMEK_DISABLED

Um tópico do Pub/Sub não está criptografado com chaves de criptografia gerenciadas pelo cliente (CMEK).

Com a CMEK, as chaves que você cria e gerencia no Cloud KMS encapsulam as chaves que o Google usa para criptografar seus dados, oferecendo mais controle sobre o acesso a eles.

Atenção: estas etapas de correção podem interromper o ambiente de produção. Se necessário, passe cargas de trabalho, dados ou permissões para novos recursos antes de excluir recursos existentes.

Para corrigir essa descoberta, exclua o tópico existente e crie um novo:

1. Acesse a página Tópicos do Pub/Sub no console do Google Cloud.

   Acesse Tópicos

2. Se necessário, selecione o projeto que contém o tópico do Pub/Sub.

3. Marque a caixa de seleção ao lado do tópico listado na descoberta e clique em Excluir.

4. Para criar um novo tópico do Pub/Sub com a CMEK ativada, consulte Como usar chaves de criptografia gerenciadas pelo cliente. As CMEK geram custos adicionais relacionados ao Cloud KMS.

5. Publique descobertas ou outros dados no tópico do Pub/Sub ativado para CMEK.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Route not monitored

Nome da categoria na API: ROUTE_NOT_MONITORED

Observação: o filtro de métricas com base em registros para este detector foi alterado em 27 de outubro de 2021.

As métricas e os alertas de registros não estão configurados para monitorar as alterações na rota da rede VPC.

As rotas do Google Cloud são destinos e saltos que definem o caminho que o tráfego de rede percorre de uma instância de VM a um IP de destino. Ao monitorar alterações nas tabelas de rotas, você ajuda a garantir que todo o tráfego VPC passe por um caminho esperado.

Para mais informações, consulte Visão geral de métricas com base em registros.

Dependendo da quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para entender o uso do serviço e os custos dele, consulte Preços da Observabilidade do Google Cloud.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, conclua as etapas a seguir:

Criar métrica

1. Acesse a página Métricas com base em registros no console do Google Cloud.

   Acessar métricas com base em registros

2. Clique em Criar métrica.

3. Em Tipo de Métrica, selecione Contador.

4. Em Detalhes:

   1. Defina um Nome da métrica de registro.
   2. Adicione uma descrição.
   3. Definir Unidades para 1.

5. Em Seleção de filtros, copie e cole o texto a seguir na caixa Criar filtro, substituindo o texto existente, se necessário:

     resource.type="gce_route"
     AND (protoPayload.methodName:"compute.routes.delete"
     OR protoPayload.methodName:"compute.routes.insert")

6. Clique em Criar métrica. Você verá uma confirmação.

Criar política de alertas

1. No console do Google Cloud, acesse a página Métricas com base em registros.

   Acessar Métricas com base em registros

   Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Logging.

2. Na seção Métricas definidas pelo usuário, selecione a métrica que você criou na seção anterior.

3. Clique em Mais e depois em Criar alerta com base na métrica.

   A caixa de diálogo Nova condição é aberta com as opções de transformação de dados e métricas pré-preenchidas.

4. Clique em Próxima.
   1. Revise as configurações pré-preenchidas. Convém modificar o Valor do limite.
   2. Clique em Nome da condição e digite um nome para ela.
5. Clique em Next.

6. Para adicionar notificações à sua política de alertas, clique em Canais de notificação. Na caixa de diálogo, selecione um ou mais canais de notificação no menu e clique em OK.

   Para receber uma notificação quando os incidentes forem abertos ou fechados, marque Notificar sobre o fechamento de incidentes. Por padrão, as notificações são enviadas apenas quando incidentes são abertos.

7. Opcional: Atualize a Duração do fechamento automático do incidente. Este campo determina quando o Monitoring fecha incidentes na ausência de dados de métrica.
8. Opcional: clique em Documentação e adicione as informações que quer incluir em uma mensagem de notificação.
9. Clique em Nome e digite um nome para a política de alertas.
10. Clique em Criar política.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Redis role used on org

Nome da categoria na API: REDIS_ROLE_USED_ON_ORG

Essa descoberta não está disponível para ativações no nível do projeto.

Um papel do Redis IAM é atribuído no nível da organização ou da pasta.

Os papéis do Redis IAM a seguir podem ser atribuídos apenas por projeto, não nos níveis da organização da pasta:

• roles/redis.admin
• roles/redis.viewer
• roles/redis.editor

Para mais informações, consulte Controle de acesso e permissões.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página de políticas do IAM no console do Google Cloud.

   Acesse a política de IAM

2. Remova os papéis do Redis IAM indicados na descoberta e adicione-os aos projetos individuais.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Release channel disabled

Nome da categoria na API: RELEASE_CHANNEL_DISABLED

Um cluster do GKE não está inscrito em um canal de lançamento.

Inscreva-se em um canal de lançamento para automatizar os upgrades de versão do cluster do GKE. Eles também reduzem a complexidade do gerenciador de versões ao número de recursos e ao nível de estabilidade necessários. Para mais informações, consulte Canais de lançamento.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Clusters do Kubernetes no console do Google Cloud.

   Acessar clusters do Kubernetes

2. Na seção Princípios básicos do cluster, clique em Fazer upgrade da versão mestre do cluster na linha Canal de lançamento.

   Se a configuração do cluster tiver sido alterada recentemente, o botão de edição poderá ser desativado. Se você não conseguir editar as configurações do cluster, aguarde alguns minutos e tente novamente.

3. Na caixa de diálogo, selecione Canal de lançamento e escolha o canal de lançamento que você quer inscrever-se.

   Se a versão do plano de controle do cluster não puder ser atualizada para um canal de lançamento, esse canal poderá ser desativado como opção.

4. Clique em Salvar alterações.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

RSASHA1 for signing

Nome da categoria na API: RSASHA1_FOR_SIGNING

RSASHA1 é usado para assinatura de chaves em zonas do Cloud DNS. O algoritmo usado para a assinatura de chaves não pode ser fraco.

Para corrigir essa descoberta, substitua o algoritmo por um recomendado seguindo o guia Como usar opções avançadas de assinatura.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Service account key not rotated

Nome da categoria na API: SERVICE_ACCOUNT_KEY_NOT_ROTATED

Essa descoberta não está disponível para ativações no nível do projeto.

Uma chave de conta de serviço gerenciada pelo usuário não é rotacionada há mais de 90 dias.

Em geral, as chaves de conta de serviço gerenciadas pelo usuário precisam ser trocadas pelo menos a cada 90 dias para garantir que os dados não possam ser acessados com uma chave antiga que pode ter sido perdida, comprometida ou roubada. Para saber mais, consulte Girar chaves de conta de serviço para reduzir o risco de segurança causado por vazamentos de chaves.

Se você gerou o par de chaves pública/privada, armazenou a chave privada em um módulo de segurança de hardware (HSM) e fez o upload da chave pública para o Google, talvez não seja necessário. de alternar a chave a cada 90 dias. Em vez disso, você pode girar a chave se acreditar que ela pode ter sido comprometida.

Atenção: estas etapas de correção podem interromper o ambiente de produção. Se necessário, passe cargas de trabalho, dados ou permissões para novos recursos antes de excluir recursos existentes.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Contas de serviço no console do Google Cloud.

   Acessar a página "Contas de serviço"

2. Se necessário, selecione o projeto indicado na descoberta.

3. Na lista de contas de serviço, encontre a conta de serviço listada na descoberta e clique em Excluir. Antes de continuar, considere o impacto que a exclusão de uma conta de serviço pode ter nos recursos de produção.

4. Crie uma nova chave de conta de serviço para substituir a antiga. Para mais informações, consulte Como criar chaves de conta de serviço.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Service account role separation

Nome da categoria na API: SERVICE_ACCOUNT_ROLE_SEPARATION

Essa descoberta não está disponível para ativações no nível do projeto.

Um ou mais membros de sua organização têm múltiplas permissões de conta de serviço atribuídas. Nenhuma conta deve ter permissão de Administrador da conta de serviço simultaneamente com outras permissões da conta de serviço. Para saber mais sobre contas de serviço e os papéis disponíveis, consulte Contas de serviço.

Atenção: estas etapas de correção podem interromper o ambiente de produção. Se necessário, passe cargas de trabalho, dados ou permissões para novos recursos antes de excluir recursos existentes.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página IAM no Console do Google Cloud.

   Acessar IAM

2. Para cada membro listado na descoberta, faça o seguinte:

   1. Verifique se o papel foi herdado de um recurso ou pasta da organização checando a coluna Herança. Se a coluna contiver um link para um recurso pai, clique no link para acessar a página do IAM do recurso pai.
   2. Clique em Editar ao lado de um titular.
   3. Para remover permissões, clique em Excluir ao lado de Administrador da conta de serviço. Se você quiser remover todas as permissões da conta de serviço, clique em Excluir ao lado de todas as outras permissões.

3. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Shielded VM disabled

Nome da categoria na API: SHIELDED_VM_DISABLED

A VM protegida está desativada nesta instância do Compute Engine.

As VMs protegidas são máquinas virtuais (VMs) no Google Cloud que têm a proteção aumentada por um conjunto de controles de segurança que ajudam a proteger contra rootkits e bootkits. As VMs protegidas ajudam a garantir que o carregador de inicialização e o firmware sejam assinados e verificados. Saiba mais sobre VM protegida.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias de VMs no Console do Google Cloud.

   Acessar instâncias de VM

2. Selecione a instância relacionada à descoberta do Security Health Analytics.

3. Na página Detalhes da instância carregada, clique em Interromper.

4. Depois que a instância for interrompida, clique em Editar.

5. Na seção VM protegida, alterne entre Ativar vTPM e Ativar o monitoramento de integridade para ativar a VM protegida.

6. Como opção, se você não usar drivers personalizados ou não assinados, ative também a Inicialização segura.

7. Clique em Save. A nova configuração aparecerá na página Detalhes da instância.

8. Clique em Iniciar para iniciar a instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL CMEK disabled

Nome da categoria na API: SQL_CMEK_DISABLED

Uma instância de banco de dados SQL não está usando chaves de criptografia gerenciadas pelo cliente (CMEK).

Com a CMEK, as chaves que você cria e gerencia no Cloud KMS encapsulam as chaves que o Google usa para criptografar seus dados, oferecendo mais controle sobre o acesso a eles. Para mais informações, consulte as visões gerais da CMEK para o produto: Cloud SQL para MySQL, Cloud SQL para PostgreSQL ou Cloud SQL para SQL Server. As CMEK geram custos adicionais relacionados ao Cloud KMS.

Atenção: estas etapas de correção podem interromper o ambiente de produção. Se necessário, passe cargas de trabalho, dados ou permissões para novos recursos antes de excluir recursos existentes.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Excluir

4. Para criar uma nova instância com a CMEK ativada, siga as instruções para configurar a CMEK para o produto:

   1. Cloud SQL para MySQL
   2. Cloud SQL para PostgreSQL
   3. Cloud SQL para SQL Server

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL contained database authentication

Nome da categoria na API: SQL_CONTAINED_DATABASE_AUTHENTICATION

Uma instância de banco de dados Cloud SQL para SQL Server não tem a sinalização de banco de dados autenticação de banco de dados contido definida como Desativada.

A sinalização de autenticação de banco de dados contidos controla se é possível criar ou anexar bancos de dados contidos ao Database Engine. Um banco de dados contido inclui todas as configurações e metadados de banco de dados necessários para definir o banco de dados. Ele não tem dependências de configuração na instância do Database Engine em que o banco de dados está instalado.

Não é recomendável ativar essa sinalização porque:

• Os usuários podem se conectar ao banco de dados sem autenticação no nível do mecanismo de banco de dados.
• Isolar o banco de dados do Database Engine possibilita migrar o banco de dados para outra instância do SQL Server.

Os bancos de dados contidos enfrentam ameaças únicas que precisam ser compreendidas e atenuadas pelos administradores do SQL Server Database Engine. A maioria das ameaças é decorrente do processo de autenticação USUÁRIO COM SENHA, que transfere o limite de autenticação do nível do Database Engine para o nível do banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações do Database, defina a sinalização de autenticação do banco de dados contidocom o valor Desativado.

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL cross DB ownership chaining

Nome da categoria na API: SQL_CROSS_DB_OWNERSHIP_CHAINING

Uma instância de banco de dados do Cloud SQL para SQL Server não tem a sinalização de banco de dados encadeamento de propriedade entre bancos de dados definida como Desativado.

A sinalização de encadeamento de propriedade entre bancos de dados permite controlar o encadeamento de propriedade entre bancos de dados no nível do banco de dados ou permite o encadeamento de propriedades de bancos de dados de todas as instruções do banco de dados.

A ativação dessa sinalização não é recomendada, a menos que todos os bancos de dados hospedados pela instância do SQL Server participem do encadeamento de propriedade entre bancos de dados e você esteja ciente das implicações de segurança dessa configuração.

Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações do banco de dados, defina a sinalização da cadeia de propriedade entre bancos de dados com o valor Desativado.

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL external scripts enabled

Nome da categoria na API: SQL_EXTERNAL_SCRIPTS_ENABLED

Uma instância de banco de dados do Cloud SQL para SQL Server não tem a sinalização do banco de dados scripts externos ativados definida como Desativada.

Quando ativada, essa configuração permite a execução de scripts com determinadas extensões de linguagem remota. Como esse recurso pode afetar negativamente a segurança do sistema, recomendamos desativá-lo.

Para mais informações, consulte Como configurar sinalizações de banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações do banco de dados, defina a sinalização dos scripts externos ativados com o valor Desativado.

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL instance not monitored

Nome da categoria na API: SQL_INSTANCE_NOT_MONITORED

Essa descoberta não está disponível para ativações no nível do projeto.

As métricas e os alertas de registro não estão configurados para monitorar alterações na configuração da instância do Cloud SQL.

A configuração incorreta das opções de instâncias do SQL pode causar riscos de segurança. Desativar as opções de backup automático e alta disponibilidade pode afetar a continuidade dos negócios e deixar de restringir as redes autorizadas pode aumentar a exposição a redes não confiáveis. O monitoramento de alterações na configuração da instância do SQL ajuda a reduzir o tempo necessário para detectar e corrigir configurações incorretas.

Para mais informações, consulte Visão geral de métricas com base em registros.

Dependendo da quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para entender o uso do serviço e os custos dele, consulte Preços da Observabilidade do Google Cloud.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, conclua as etapas a seguir:

Criar métrica

1. Acesse a página Métricas com base em registros no console do Google Cloud.

   Acessar métricas com base em registros

2. Clique em Criar métrica.

3. Em Tipo de Métrica, selecione Contador.

4. Em Detalhes:

   1. Defina um Nome da métrica de registro.
   2. Adicione uma descrição.
   3. Definir Unidades para 1.

5. Em Seleção de filtros, copie e cole o texto a seguir na caixa Criar filtro, substituindo o texto existente, se necessário:

     protoPayload.methodName="cloudsql.instances.update"
     OR protoPayload.methodName="cloudsql.instances.create"
     OR protoPayload.methodName="cloudsql.instances.delete"

6. Clique em Criar métrica. Você verá uma confirmação.

Criar política de alertas

1. No console do Google Cloud, acesse a página Métricas com base em registros.

   Acessar Métricas com base em registros

   Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Logging.

2. Na seção Métricas definidas pelo usuário, selecione a métrica que você criou na seção anterior.

3. Clique em Mais e depois em Criar alerta com base na métrica.

   A caixa de diálogo Nova condição é aberta com as opções de transformação de dados e métricas pré-preenchidas.

4. Clique em Próxima.
   1. Revise as configurações pré-preenchidas. Convém modificar o Valor do limite.
   2. Clique em Nome da condição e digite um nome para ela.
5. Clique em Next.

6. Para adicionar notificações à sua política de alertas, clique em Canais de notificação. Na caixa de diálogo, selecione um ou mais canais de notificação no menu e clique em OK.

   Para receber uma notificação quando os incidentes forem abertos ou fechados, marque Notificar sobre o fechamento de incidentes. Por padrão, as notificações são enviadas apenas quando incidentes são abertos.

7. Opcional: Atualize a Duração do fechamento automático do incidente. Este campo determina quando o Monitoring fecha incidentes na ausência de dados de métrica.
8. Opcional: clique em Documentação e adicione as informações que quer incluir em uma mensagem de notificação.
9. Clique em Nome e digite um nome para a política de alertas.
10. Clique em Criar política.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL local infile

Nome da categoria na API: SQL_LOCAL_INFILE

Uma instância de banco de dados do Cloud SQL para MySQL não tem a sinalização de banco de dados local_infile definida como Desativada. Devido a problemas de segurança associados à sinalização local_infile, ela precisa ser desativada. Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações do banco de dados, defina a sinalização do banco de dados local_infile com o valor Desativado.

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL log checkpoints disabled

Nome da categoria na API: SQL_LOG_CHECKPOINTS_DISABLED

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a sinalização de banco de dados log_checkpoints definida como Ativada.

A ativação de log_checkpoints faz com que os pontos de verificação e os pontos de reinicialização sejam registrados no registro do servidor. Algumas estatísticas são incluídas nas mensagens de registro, incluindo o número de buffers gravados e o tempo gasto para gravá-los.

Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações do banco de dados, defina a sinalização do banco de dados log_checkpoints database flag com o valor Ativado.

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL log connections disabled

Nome da categoria na API: SQL_LOG_CONNECTIONS_DISABLED

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a sinalização de banco de dados log_connections definida como Ativada.

A ativação da configuração log_connections faz com que as tentativas de conexão ao servidor sejam registradas, com a conclusão bem-sucedida da autenticação do cliente. Os registros podem ser úteis para solucionar problemas e confirmar tentativas de conexão incomuns no servidor.

Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações do banco de dados, defina a sinalização do banco de dados log_connections com o valor Ativado.

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL log disconnections disabled

Nome da categoria na API: SQL_LOG_DISCONNECTIONS_DISABLED

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a sinalização de banco de dados log_disconnections definida como Ativado.

Ativar a configuração log_disconnections cria entradas de registro no final de cada sessão. Os registros são úteis para solucionar problemas e confirmar atividades incomuns em um período. Para mais informações, consulte Como configurar sinalizações de banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações do Database, defina a sinalização do banco de dados log_disconnections com o valor Ativado.

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL log duration disabled

Nome da categoria na API: SQL_LOG_DURATION_DISABLED

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a sinalização de banco de dados log_duration definida como Ativado.

Quando log_duration está ativada, essa configuração faz com que o ambiente de execução e a duração de cada instrução concluída sejam registrados. Monitorar o tempo necessário para executar consultas pode ser essencial para identificar consultas lentas e resolver problemas no banco de dados.

Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações do banco de dados, defina a sinalização do banco de dados log_duration como Ativada.

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL log error verbosity

Nome da categoria na API: SQL_LOG_ERROR_VERBOSITY

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a flag de banco de dados log_error_verbosity definida como padrão ou detalhada.

A flag log_error_verbosity controla a quantidade de detalhes nas mensagens registradas. Quanto maior o nível de detalhes, mais informações são gravadas nas mensagens. Recomendamos definir essa flag como default ou verbose.

Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Flags do banco de dados, defina a flag log_error_verbosity do banco de dados como default ou verbose.

5. Clique em Salvar. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL log lock waits disabled

Nome da categoria na API: SQL_LOG_LOCK_WAITS_DISABLED

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a sinalização de banco de dados log_lock_waits definida como Ativado.

A ativação da configuração log_lock_waits cria entradas de registro quando as sessões aguardam mais do que o tempo deadlock_timeout para adquirir um bloqueio. Os registros são úteis para determinar se as esperas de bloqueio estão causando um desempenho ruim.

Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações do Database, defina a sinalização log_lock_waits do banco de dados com o valor Ativado.

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL log min duration statement enabled

Nome da categoria na API: SQL_LOG_MIN_DURATION_STATEMENT_ENABLED

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a sinalização log_min_duration_statement do banco de dados definida como -1.

A sinalização log_min_duration_statement faz com que as instruções SQL executadas por mais de um tempo especificado sejam registradas. Considere desativar essa configuração porque as instruções SQL podem conter informações confidenciais que não devem ser registradas. Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações do banco de dados, defina a sinalização do banco de dados log_min_duration_statement com o valor -1.

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL log min error statement

Nome da categoria na API: SQL_LOG_MIN_ERROR_STATEMENT

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a sinalização log_min_error_statement do banco de dados definida corretamente.

A sinalização log_min_error_statement controla se as instruções SQL que causam condições de erro são registradas nos registros do servidor. As instruções SQL da gravidade especificada ou superior são registradas com mensagens para as instruções de erro. Quanto maior a gravidade, menos mensagens são registradas.

Se log_min_error_statement não estiver definido como o valor pretendido, talvez as mensagens não sejam classificadas como mensagens de erro. Uma gravidade definida como baixa demais aumenta o número de mensagens e dificulta a localização de erros reais. Uma gravidade definida como muito alta pode fazer com que mensagens de erro reais não sejam registradas.

Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações do banco de dados, defina a sinalização do banco de dados log_min_error_statement com um dos valores recomendados a seguir, de acordo com a política de geração de registros da organização.

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning
   • error

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL log min error statement severity

Nome da categoria na API: SQL_LOG_MIN_ERROR_STATEMENT_SEVERITY

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a sinalização log_min_error_statement do banco de dados definida corretamente.

A sinalização log_min_error_statement controla se as instruções SQL que causam condições de erro são registradas nos registros do servidor. As instruções SQL sobre a gravidade especificada ou superior são registradas com mensagens para as instruções de erro. Quanto mais rigorosa a gravidade, menos mensagens são registradas.

Se log_min_error_statement não estiver definido como o valor pretendido, talvez as mensagens não sejam classificadas como mensagens de erro. Um conjunto de gravidade muito baixa poderia aumentar o número de mensagens e dificultar a localização de erros reais. Um nível de gravidade muito alto (muito rígido) pode fazer com que as mensagens de erro reais não sejam registradas.

Recomendamos que você defina essa sinalização como error ou uma opção mais rigorosa.

Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações do banco de dados, defina a sinalização do banco de dados log_min_error_statement com um dos valores recomendados a seguir, de acordo com a política de geração de registros da sua organização.

   • error
   • log
   • fatal
   • panic

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL log min messages

Nome da categoria na API: SQL_LOG_MIN_MESSAGES

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a sinalização de banco de dados log_min_messages definida como o mínimo de warning.

A sinalização log_min_messages controla quais níveis de mensagem são gravados nos registros do servidor. Quanto maior a gravidade, menos mensagens são registradas. Definir o limite muito baixo pode resultar em aumento do tamanho e do comprimento do armazenamento de registros, dificultando a localização de erros reais.

Para mais informações, consulte Como configurar sinalizações de banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Flags do banco de dados, defina a flag log_min_messages com um dos valores recomendados a seguir, de acordo com a política de geração de registros da organização.

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL log executor stats enabled

Nome da categoria na API: SQL_LOG_EXECUTOR_STATS_ENABLED

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a flag de banco de dados log_executor_stats definida como Desativada.

Quando a flag log_executor_stats é ativada, as estatísticas de desempenho do executor são incluídas nos registros do PostgreSQL para cada consulta. Essa configuração pode ser útil para solucionar problemas, mas também pode aumentar significativamente a quantidade de registros e a sobrecarga de desempenho.

Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações do banco de dados, defina a flag do banco de dados log_executor_stats como Desativada.

5. Clique em Salvar. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL log hostname enabled

Nome da categoria na API: SQL_LOG_HOSTNAME_ENABLED

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a sinalização de banco de dados log_hostname definida como Desativada.

Quando a sinalização log_hostname está ativada, o nome do host de conexão é registrado. Por padrão, as mensagens do registro de conexão mostram apenas o endereço IP. Essa configuração pode ser útil para resolver problemas. No entanto, isso pode gerar sobrecarga no desempenho do servidor, porque, para cada instrução registrada, a resolução DNS é necessária para converter um endereço IP em um nome de host.

Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações do banco de dados, defina a sinalização do banco de dados log_hostname como Desativado.

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL log parser stats enabled

Nome da categoria na API: SQL_LOG_PARSER_STATS_ENABLED

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a sinalização de banco de dados log_debugger_stats definida como Desativado.

Quando a sinalização log_debugger_stats é ativada, as estatísticas de desempenho do analisador são incluídas nos registros do PostgreSQL para cada consulta. Isso pode ser útil para solucionar problemas, mas também pode aumentar significativamente o número de registros e a sobrecarga de desempenho.

Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações do banco de dados, defina a sinalização do banco de dados log_parser_stats como Desativada.

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL log planner stats enabled

Nome da categoria na API: SQL_LOG_PLANNER_STATS_ENABLED

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a sinalização de banco de dados log_planner_stats definida como Desativada.

Quando a sinalização log_planner_stats é ativada, é usado um método bruto de criação de perfil para registrar as estatísticas de desempenho do planejador do PostgreSQL. Isso pode ser útil para solucionar problemas, mas também pode aumentar significativamente o número de registros e a sobrecarga de desempenho.

Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações do banco de dados, defina a sinalização do banco de dados log_planner_stats como Desativada.

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL log statement

Nome da categoria na API: SQL_LOG_STATEMENT

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a flag de banco de dados log_statement definida como ddl.

O valor dessa sinalização controla quais instruções SQL são registradas. A geração de registros ajuda a solucionar problemas operacionais e permite a análise forense. Se essa sinalização não estiver definida com o valor correto, as informações relevantes poderão ser ignoradas ou estar ocultas em muitas mensagens. Recomenda-se um valor de ddl (todas as instruções de definição de dados), a menos que você receba outras orientações da política de geração de registros da organização.

Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Flags de banco de dados, defina a flag de banco de dados log_statement como ddl.

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL log statement stats enabled

Nome da categoria na API: SQL_LOG_STATEMENT_STATS_ENABLED

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a sinalização de banco de dados log_statement_stats definida como Desativada.

Quando a sinalização log_statement_stats é ativada, as estatísticas de desempenho completas são incluídas nos registros do PostgreSQL para cada consulta. Essa configuração pode ser útil para solucionar problemas, mas também pode aumentar significativamente a quantidade de registros e a sobrecarga de desempenho.

Para mais informações, consulte Como configurar sinalizações do banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações do banco de dados, defina a sinalização do banco de dados log_statement_stats como Desativada.

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL log temp files

Nome da categoria na API: SQL_LOG_TEMP_FILES

Uma instância de banco de dados do Cloud SQL para PostgreSQL não tem a sinalização de banco de dados log_temp_files definida como 0.

É possível criar arquivos temporários para classificações, hashes e resultados de consulta temporários. Definir a sinalização log_temp_files como 0 faz com que todas as informações dos arquivos temporários sejam registradas. Essa ação é útil para identificar possíveis problemas de desempenho. Para mais informações, consulte Como configurar sinalizações de banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações do banco de dados, defina a sinalização log_temp_files com o valor 0.

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL no root password

Nome da categoria na API: SQL_NO_ROOT_PASSWORD

Uma instância de banco de dados MySQL não tem uma senha definida para a conta raiz. Você precisa adicionar uma senha à instância do banco de dados MySQL. Para mais informações, consulte Usuários do MySQL.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Na página Detalhes da instância carregada, selecione a guia Usuários.

4. Ao lado do usuário root, clique em Mais e depois selecione Alterar senha.

5. Insira uma senha nova e forte e clique em OK.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL public IP

Nome da categoria na API: SQL_PUBLIC_IP

Um banco de dados do Cloud SQL tem um endereço IP público.

Para reduzir a superfície de ataque da organização, os bancos de dados do Cloud SQL não podem ter endereços IP públicos. Endereços IP privados oferecem maior segurança de rede e menor latência para o aplicativo.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. No menu à esquerda, clique em Conexões.

4. Clique na guia Rede e desmarque a caixa de seleção IP público.

5. Se a instância ainda não estiver configurada para usar um IP particular, consulte Como configurar o IP particular de uma instância atual.

6. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL remote access enabled

Nome da categoria na API: SQL_REMOTE_ACCESS_ENABLED

Uma instância de banco de dados do Cloud SQL para SQL Server não tem a sinalização de banco de dados de acesso remoto definida como Desativada.

Quando ativada, essa configuração concede permissão para executar procedimentos armazenados no local a partir de servidores remotos ou procedimentos armazenados remotamente a partir do servidor local. Essa funcionalidade pode ser violada para lançar um ataque de negação de serviço (DoS) em servidores remotos ao descarregar o processamento de consultas em um destino. Para evitar abusos, recomendamos desativar essa configuração.

Para mais informações, consulte Como configurar sinalizações de banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações, defina acesso remoto como Desativado.

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL skip show database disabled

Nome da categoria na API: SQL_SKIP_SHOW_DATABASE_DISABLED

Uma instância de banco de dados do Cloud SQL para MySQL não tem a sinalização de banco de dados skip_show_database definida como Ativada.

Quando ativada, essa sinalização impede que os usuários usem a instrução SHOW DATABASES se não tiverem o privilégio SHOW DATABASES. Com essa configuração, os usuários sem permissão explícita não podem ver bancos de dados que pertencem a outros usuários. Recomendamos ativar essa sinalização.

Para mais informações, consulte Como configurar sinalizações de banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações, defina skip_show_database como Ativado.

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL trace flag 3625

Nome da categoria na API: SQL_TRACE_FLAG_3625

Uma instância de banco de dados do Cloud SQL para SQL Server não tem a sinalização do banco de dados 3625 (sinalizador de rastreamento) definida como Ativada.

Essa sinalização limita a quantidade de informações retornadas a usuários que não são membros do papel de servidor fixo do administrador, mascarando os parâmetros de algumas mensagens de erro usando asteriscos (******). Para ajudar a evitar a divulgação de informações confidenciais, recomendamos ativar essa sinalização.

Observação: algumas versões da comparação do CIS recomendam incorretamente a configuração do 3625 (sinalizador de rastreamento) como Desativado. A configuração mais segura é Ativada. Para mais informações, consulte a sinalização de banco de dados Proposta 3625 (sinalizador de rastreamento) da CIS para todas as instâncias do Cloud SQL Server definida como "on" (registro necessário).

Para mais informações, consulte Como configurar sinalizações de banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações do banco de dados, defina 3625 como Ativado.

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL user connections configured

Nome da categoria na API: SQL_USER_CONNECTIONS_CONFIGURED

Uma instância de banco de dados do Cloud SQL para SQL Server tem a sinalização do banco de dados conexões do usuário configurada.

A opção conexões do usuário especifica o número máximo de conexões simultâneas do usuário que são permitidas em uma instância do SQL Server. Como é uma opção dinâmica (de autoconfiguração), o SQL Server ajusta o número máximo de conexões de usuário automaticamente conforme necessário, até o valor máximo permitido. O valor padrão é 0, o que significa que até 32.767 conexões de usuários são permitidas. Por esse motivo, não recomendamos configurar a sinalização do banco de dados conexões do usuário.

Para mais informações, consulte Como configurar sinalizações de banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações do banco de dados, ao lado de Conexões do usuário, clique em Excluir.

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL user options configured

Nome da categoria na API: SQL_USER_OPTIONS_CONFIGURED

Uma instância de banco de dados do Cloud SQL para SQL Server tem a sinalização de banco de dados opções do usuário configurada.

Essa configuração substitui os valores padrão globais das opções SET para todos os usuários. Como os usuários e os aplicativos podem presumir que as opções SET do banco de dados padrão estão em uso, definir as opções do usuário pode causar resultados inesperados. Por esse motivo, não recomendamos configurar a sinalização do banco de dados opções do usuário.

Para mais informações, consulte Como configurar sinalizações de banco de dados.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na seção Sinalizações do banco de dados, ao lado de Opções do usuário, clique em Excluir.

5. Clique em Save. A nova configuração aparecerá na página Visão geral da instância.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SQL weak root password

Nome da categoria na API: SQL_WEAK_ROOT_PASSWORD

Uma instância de banco de dados MySQL tem uma senha fraca definida para a conta raiz. Você precisa definir uma senha forte para a instância. Para mais informações, consulte Usuários do MySQL.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Na página Detalhes da instância carregada, selecione a guia Usuários.

4. Ao lado do usuário root, clique em Mais e depois selecione Alterar senha.

5. Insira uma senha nova e forte e clique em OK.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

SSL not enforced

Nome da categoria na API: SSL_NOT_ENFORCED

Uma instância de banco de dados do Cloud SQL não requer que todas as conexões de entrada usem SSL.

Para evitar o vazamento de dados confidenciais em trânsito durante comunicações não criptografadas, todas as conexões de entrada com sua instância do banco de dados do SQL precisam usar o SSL. Saiba mais sobre Como configurar SSL/TLS.

Para remediar essa descoberta, permita apenas conexões SSL para suas instâncias SQL:

1. Acesse a página Instâncias do Cloud SQL no console do Google Cloud.

   Acesse "Instâncias do Cloud SQL"

2. Selecione a instância listada na descoberta do Security Health Analytics.

3. Na guia Conexões, clique em Permitir apenas conexões SSL ou Exigir certificados do cliente confiáveis. Para mais informações, consulte Aplicar criptografia SSL/TLS.

4. Se você escolheu Exigir certificados do cliente confiáveis, crie um novo certificado do cliente. Para mais informações, consulte Criar um novo certificado do cliente.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Too many KMS users

Nome da categoria na API: TOO_MANY_KMS_USERS

Limite o número de usuários principais que podem usar chaves criptográficas a três. Os papéis predefinidos a seguir concedem permissões para criptografar, descriptografar ou assinar dados usando chaves criptográficas:

• roles/owner
• roles/cloudkms.cryptoKeyEncrypterDecrypter
• roles/cloudkms.cryptoKeyEncrypter
• roles/cloudkms.cryptoKeyDecrypter
• roles/cloudkms.signer
• roles/cloudkms.signerVerifier

Para mais informações, consulte Permissões e papéis.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Chaves do Cloud KMS no console do Google Cloud.

   Acesse Chaves do Cloud KMS

2. Clique no nome do keyring indicado na descoberta.

3. Clique no nome da chave indicada na descoberta.

4. Selecione a caixa ao lado da versão principal e clique em Mostrar painel de informações.

5. Reduza o número de principais com permissões para criptografar, descriptografar ou assinar dados para três ou menos. Para revogar permissões, clique em Excluir ao lado de cada membro.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Unconfirmed AppArmor profile

Nome da categoria na API: GKE_APP_ARMOR

Um contêiner pode ser explicitamente configurado para não ser confinado pelo AppArmor. Isso garante que nenhum perfil do AppArmor seja aplicado ao contêiner e, portanto, não seja restringido por um perfil. O controle de segurança preventivo desativado aumenta o risco de escape do contêiner.

Para corrigir essa descoberta, siga as etapas abaixo nas cargas de trabalho afetadas:

1. Abra o manifesto de cada carga de trabalho afetada.
2. Defina os seguintes campos restritos para um dos valores permitidos.

Campos restritos

• metadata.annotations["container.apparmor.security.beta.kubernetes.io/*"]

Valores permitidos

• falso

User managed service account key

Nome da categoria na API: USER_MANAGED_SERVICE_ACCOUNT_KEY

Um usuário gerencia uma chave de conta de serviço. As chaves da conta de serviço são um risco de segurança quando não são gerenciadas corretamente. Sempre que possível, escolha uma alternativa mais segura para as chaves de conta de serviço. Caso seja necessário autenticar com uma chave de conta de serviço, você será responsável pela segurança da chave privada e por outras operações descritas em Práticas recomendadas para gerenciar chaves de contas de serviço. Se não for possível criar uma chave de conta de serviço, a criação pode ser desativada para sua organização. Para mais informações, consulte Gerenciar recursos da organização com segurança por padrão.

Atenção: estas etapas de correção podem interromper o ambiente de produção. Se necessário, passe cargas de trabalho, dados ou permissões para novos recursos antes de excluir recursos existentes.

Para corrigir essa descoberta, conclua as etapas a seguir:

1. Acesse a página Contas de serviço no console do Google Cloud.

   Acessar a página "Contas de serviço"

2. Se necessário, selecione o projeto indicado na descoberta.

3. Exclua as chaves da conta de serviço gerenciadas pelo usuário indicadas na descoberta se elas não forem usadas por nenhum aplicativo.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Weak SSL policy

Nome da categoria na API: WEAK_SSL_POLICY

Uma instância do Compute Engine tem uma política de SSL fraca ou usa a política de SSL padrão do Google Cloud com TLS versão inferior a 1.2.

Os balanceadores de carga HTTPS e de proxy SSL usam políticas de SSL para determinar o protocolo e os pacotes de criptografia usados nas conexões TLS estabelecidas entre os usuários e a Internet. Essas conexões criptografam dados confidenciais para impedir que invasores mal-intencionados acessem esses dados. Com uma política de SSL fraca, os clientes que usam versões desatualizadas do TLS podem se conectar a um pacote ou protocolo de criptografia menos seguro. Para ver uma lista de pacotes de criptografia recomendados e desatualizados, acesse a página de parâmetros TLS do iana.org.

Observação: a atualização de uma política de SSL pode reduzir a compatibilidade de usuários com versões desatualizadas do TLS.

Para ativações no nível do projeto do nível Premium do Security Command Center, essa descoberta só estará disponível se o nível Standard estiver ativado na organização pai.

As etapas de correção para essa descoberta variam dependendo se essa descoberta foi acionada pelo uso de uma política de SSL padrão do Google Cloud ou de uma política de SSL que permite um pacote de criptografia fraco ou uma versão de TLS mínima inferior a 1.2. Siga o procedimento abaixo que corresponde ao gatilho da descoberta.

Correção da política de SSL padrão do Google Cloud

1. Acesse a página Proxies de destino no console do Google Cloud.

   Acesse proxies de destino

2. Encontre o proxy de destino indicado na descoberta e anote as regras de encaminhamento na coluna Em uso por.

3. Para criar uma nova política de SSL, consulte Como usar políticas de SSL. A política precisa ter uma versão mínima de TLS de 1.2 e um perfil moderno ou restrito.

4. Para usar um perfil Personalizado, verifique se os seguintes pacotes de criptografia estão desativados:

   • TLS_RSA_WITH_AES_128_GCM_SHA256
   • TLS_RSA_WITH_AES_256_GCM_SHA384
   • TLS_RSA_WITH_AES_128_CBC_SHA
   • TLS_RSA_WITH_AES_256_CBC_SHA
   • TLS_RSA_WITH_3DES_EDE_CBC_SHA

5. Aplique a política de SSL a cada regra de encaminhamento que você anotou.

Correção do pacote de criptografia fraco ou versão TLS de nível inferior

1. No console do Google Cloud, acesse a página Políticas de SSL.

   Acessar políticas de SSL

2. Encontre o balanceador de carga indicado na coluna Em uso por.

3. Clique no nome da política.

4. Clique em Editar.

5. Altere a Versão mínima do TLS para TLS 1.2 e Perfil para Moderno ou restrito.

6. Para usar um perfil Personalizado, verifique se os seguintes pacotes de criptografia estão desativados:

   • TLS_RSA_WITH_AES_128_GCM_SHA256
   • TLS_RSA_WITH_AES_256_GCM_SHA384
   • TLS_RSA_WITH_AES_128_CBC_SHA
   • TLS_RSA_WITH_AES_256_CBC_SHA
   • TLS_RSA_WITH_3DES_EDE_CBC_SHA

7. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Web UI enabled

Nome da categoria na API: WEB_UI_ENABLED

A IU da Web do GKE (painel) está ativada.

As contas de serviço do Kubernetes altamente privilegiadas apoiam a interface da Web do Kubernetes. Caso ela seja comprometida, a conta de serviço pode ser violada. Se você já estiver usando o console do Google Cloud, a interface da Web do Kubernetes estende a superfície de ataque desnecessariamente. Saiba mais sobre Como desativar a interface da Web do Kubernetes.

Para corrigir essa descoberta, desative a interface da Web do Kubernetes:

1. Acesse a página Clusters do Kubernetes no console do Google Cloud.

   Acessar os clusters do Kubernetes

2. Clique no nome do cluster listado na descoberta do Security Health Analytics.

3. Clique em Editar.

   Se a configuração do cluster tiver sido alterada recentemente, o botão de edição poderá ser desativado. Se você não conseguir editar as configurações do cluster, aguarde alguns minutos e tente novamente.

4. Clique em Complementos. A seção se expande para exibir os complementos disponíveis.

5. Na lista suspensa Painel do Kubernetes, selecione Desativado.

6. Clique em Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Workload Identity disabled

Nome da categoria na API: WORKLOAD_IDENTITY_DISABLED

A Identidade da carga de trabalho está desativada em um cluster do GKE.

A identidade de carga de trabalho é a maneira recomendada de acessar os serviços do Google Cloud a partir do GKE porque oferece melhores propriedades de segurança e capacidade de gerenciamento. Sua ativação evita que metadados de sistema potencialmente confidenciais das cargas de trabalho do usuário sejam executados no seu cluster. Saiba mais sobre ocultação de metadados.

Para corrigir essa descoberta, siga o guia para Ativar a identidade da carga de trabalho em um cluster.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Corrigir as configurações incorretas da AWS

Somente nível Enterprise:esse recurso está disponível apenas com o nível Enterprise do Security Command Center.

AWS Cloud Shell Full Access Restricted

Nome da categoria na API: ACCESS_AWSCLOUDSHELLFULLACCESS_RESTRICTED

O AWS CloudShell é uma maneira conveniente de executar comandos da CLI nos serviços da AWS. Uma política gerenciada do IAM ("AWSCloudShellFullAccess") oferece acesso total ao CloudShell, o que permite fazer upload e download de arquivos entre o sistema local de um usuário e o ambiente do CloudShell. No ambiente do CloudShell, um usuário tem permissões sudo e pode acessar a Internet. Portanto, é possível instalar um software de transferência de arquivos (por exemplo) e mover dados do CloudShell para servidores externos da Internet.

Recomendação: restringir o acesso ao AWSCloudShellFullAccess

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

1. Abra o console do IAM em https://console.aws.amazon.com/iam/.
2. No painel à esquerda, selecione Políticas.
3. Pesquise e selecione AWSCloudShellFullAccess
4. Na guia "Entidades anexadas", marque a caixa e selecione "Deletar" para cada item.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Access Keys Rotated Every 90 Days or Less

Nome da categoria na API: ACCESS_KEYS_ROTATED_90_DAYS_LESS

As chaves de acesso consistem em um ID e uma chave secreta, que são usadas para assinar solicitações programáticas feitas à AWS. Os usuários da AWS precisam de chaves de acesso próprias para fazer chamadas programáticas para a AWS na interface de linha de comando da AWS (AWS CLI), nas ferramentas para Windows PowerShell, nos SDKs da AWS ou em chamadas HTTP diretas usando as APIs de serviços individuais da AWS. É recomendável que todas as chaves de acesso sejam trocadas regularmente.

Recomendação: verifique se as chaves de acesso são alternadas, no máximo, a cada 90 dias

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

1. Acesse o console de gerenciamento (https://console.aws.amazon.com/iam).
2. Clique em Users
3. Clique em Security Credentials
4. Como administrador
   - Clique em Make Inactive para chaves que não foram alternadas em 90 dias
5. Como usuário do IAM
   - Clique em Make Inactive ou Delete para chaves que não foram trocadas ou usadas em 90 dias
6. Clique em Create Access Key
7. Atualizar a chamada programática com novas credenciais da chave de acesso

CLI da AWS

1. Enquanto a primeira chave de acesso ainda estiver ativa, crie uma segunda chave de acesso, que será ativada por padrão. Execute este comando:

aws iam create-access-key

Nesse ponto, o usuário tem duas chaves de acesso ativas.

2. Atualize todos os aplicativos e ferramentas para usar a nova chave de acesso.
3. Para determinar se a primeira chave de acesso ainda está em uso, use este comando:

aws iam get-access-key-last-used

4. Uma abordagem é esperar vários dias e verificar se a chave de acesso antiga foi usada antes de prosseguir.

Mesmo que a etapa 3 indique que a chave antiga não está sendo usada, é recomendável não excluir a primeira chave de acesso imediatamente. Em vez disso, mude o estado da primeira chave de acesso para "Inativo" usando este comando:

aws iam update-access-key

5. Use apenas a nova chave de acesso para confirmar se os apps estão funcionando. Todos os aplicativos e ferramentas que ainda usam a chave de acesso original vão deixar de funcionar, porque não terão mais acesso aos recursos da AWS. Se você encontrar um aplicativo ou ferramenta desse tipo, mude o estado dela para "Ativa" para reativar a primeira chave de acesso. Em seguida, volte à etapa 2 e atualize o aplicativo para usar a nova chave.

6. Depois de aguardar um período para garantir que todos os aplicativos e ferramentas foram atualizados, você pode excluir a primeira chave de acesso com este comando:

aws iam delete-access-key

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

All Expired Ssl Tls Certificates Stored Aws Iam Removed

Nome da categoria na API: ALL_EXPIRED_SSL_TLS_CERTIFICATES_STORED_AWS_IAM_REMOVED

Para ativar as conexões HTTPS no seu site ou aplicativo na AWS, você precisa de um certificado de servidor SSL/TLS. É possível usar o ACM ou o IAM para armazenar e implantar certificados do servidor.
Use o IAM como um gerenciador de certificados somente quando precisar oferecer suporte a conexões HTTPS em uma região que não tem suporte do ACM. O IAM criptografa suas chaves privadas e armazena a versão criptografada no armazenamento de certificados SSL do IAM. O IAM oferece suporte à implantação de certificados de servidor em todas as regiões, mas você precisa receber o certificado de um provedor externo para usar com a AWS. Não é possível fazer upload de um certificado do ACM para o IAM. Além disso, não é possível gerenciar seus certificados no IAM Console.

Recomendação: verifique se todos os certificados SSL/TLS expirados armazenados no AWS IAM foram removidos

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

No momento, não é possível remover certificados expirados pelo AWS Management Console. Para excluir certificados SSL/TLS armazenados no IAM pela API da AWS, use a interface de linha de comando (CLI).

CLI da AWS

Para excluir um certificado expirado, execute o seguinte comando substituindo CERTIFICATE_NAME pelo nome do certificado a ser excluído:

aws iam delete-server-certificate --server-certificate-name <CERTIFICATE_NAME>

Quando o comando anterior é bem-sucedido, ele não retorna nenhuma saída.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Autoscaling Group Elb Healthcheck Required

Nome da categoria na API: AUTOSCALING_GROUP_ELB_HEALTHCHECK_REQUIRED

Essa opção verifica se os grupos de escalonamento automático associados a um balanceador de carga estão usando as verificações de integridade do Elastic Load Balancing.

Isso garante que o grupo possa determinar a integridade de uma instância com base em outros testes fornecidos pelo balanceador de carga. O uso de verificações de integridade do Elastic Load Balancing pode ajudar a garantir a disponibilidade de aplicativos que usam grupos de escalonamento automático do EC2.

Recomendação: verifique se todos os grupos de escalonamento automático associados a um balanceador de carga usam verificações de integridade

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

Para ativar as verificações de integridade do Elastic Load Balancing

1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.
2. No painel de navegação, em "Autoscaling", escolha "Grupos de Autoscaling".
3. Marque a caixa de seleção do seu grupo.
4. Escolha "Editar".
5. Em "Verificações de integridade", escolha ELB como tipo de verificação.
6. Para o período de carência da verificação de integridade, insira 300.
7. Na parte de baixo da página, escolha "Atualizar".

Para mais informações sobre como usar um balanceador de carga com um grupo de escalonamento automático, consulte o Guia do usuário do AWS Auto Scaling.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Auto Minor Version Upgrade Feature Enabled Rds Instances

Nome da categoria na API: AUTO_MINOR_VERSION_UPGRADE_FEATURE_ENABLED_RDS_INSTANCES

Verifique se as instâncias de banco de dados do RDS têm a flag de upgrade automático da versão secundária ativada para receber upgrades automáticos de versão secundária do mecanismo durante a janela de manutenção especificada. Assim, as instâncias do RDS podem receber novos recursos, correções de bugs e patches de segurança para os mecanismos de banco de dados.

Recomendação: verifique se o recurso de upgrade automático da versão secundária está ativado para as instâncias do RDS

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

1. Faça login no console de gerenciamento da AWS e acesse o painel do RDS em https://console.aws.amazon.com/rds/.
2. No painel de navegação à esquerda, clique em Databases.
3. Selecione a instância do RDS que você quer atualizar.
4. Clique no botão Modify no canto superior direito.
5. Na página Modify DB Instance: <instance identifier>, na seção Maintenance, selecione Auto minor version upgrade e clique no botão de opção Yes.
6. Na parte de baixo da página, clique em Continue, marque a opção "Aplicar imediatamente" para aplicar as mudanças ou selecione Apply during the next scheduled maintenance window para evitar inatividade.
7. Analise as mudanças e clique em Modify DB Instance. O status da instância muda de "Disponível" para "Modificando" e volta para "Disponível". Depois que o recurso for ativado, o status Auto Minor Version Upgrade será alterado para Yes.

CLI da AWS

1. Execute o comando describe-db-instances para listar todos os nomes de instâncias de banco de dados do RDS disponíveis na região da AWS selecionada:

aws rds describe-db-instances --region <regionName> --query 'DBInstances[*].DBInstanceIdentifier'

2. A resposta ao comando vai retornar cada identificador de instância do banco de dados.
3. Execute o comando modify-db-instance para modificar a configuração da instância do RDS selecionada. Esse comando vai aplicar as mudanças imediatamente. Remova --apply-immediately para aplicar as mudanças durante a próxima janela de manutenção programada e evitar inatividade:

aws rds modify-db-instance --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --auto-minor-version-upgrade --apply-immediately

4. A resposta ao comando vai revelar os novos metadados de configuração da instância do RDS e verificar o valor do parâmetro AutoMinorVersionUpgrade.
5. Execute o comando describe-db-instances para verificar se o recurso de upgrade automático de versão secundária foi ativado:

aws rds describe-db-instances --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --query 'DBInstances[*].AutoMinorVersionUpgrade'

6. A resposta ao comando precisa retornar o status atual do recurso definido como true, o recurso é enabled e os upgrades de motor secundários serão aplicados à instância do RDS selecionada.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Aws Config Enabled All Regions

Nome da categoria na API: AWS_CONFIG_ENABLED_ALL_REGIONS

O AWS Config é um serviço da Web que realiza o gerenciamento de configuração dos recursos da AWS com suporte na sua conta e envia arquivos de registro para você. As informações gravadas incluem o item de configuração (recurso da AWS), as relações entre os itens de configuração (recursos da AWS) e as mudanças de configuração entre os recursos. É recomendável ativar o AWS Config em todas as regiões.

Recomendação: verifique se o AWS Config está ativado em todas as regiões

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

1. Selecione a região em que você quer focar no canto superior direito do console.
2. Clique em "Serviços".
3. Clique em "Configuração".
4. Se um gravador de configuração estiver ativado nessa região, acesse a página "Configurações" no menu de navegação à esquerda. Se um gravador de configuração ainda não estiver ativado nessa região, selecione "Começar".
5. Selecione "Gravar todos os recursos compatíveis com esta região"
6. Incluir recursos globais (recursos do IAM)
7. Especifique um bucket do S3 na mesma conta ou em outra conta da AWS gerenciada
8. Crie um tópico do SNS na mesma conta da AWS ou em outra conta gerenciada da AWS.

CLI da AWS

1. Verifique se há um bucket do S3, um tópico do SNS e um papel do IAM adequados de acordo com os pré-requisitos do serviço do AWS Config.
2. Execute este comando para criar um novo gravador de configuração:

aws configservice put-configuration-recorder --configuration-recorder name=default,roleARN=arn:aws:iam::012345678912:role/myConfigRole --recording-group allSupported=true,includeGlobalResourceTypes=true

3. Crie um arquivo de configuração do canal de entrega localmente que especifique os atributos do canal, preenchido com os pré-requisitos configurados anteriormente:

{
 "name": "default",
 "s3BucketName": "my-config-bucket",
 "snsTopicARN": "arn:aws:sns:us-east-1:012345678912:my-config-notice",
 "configSnapshotDeliveryProperties": {
 "deliveryFrequency": "Twelve_Hours"
 }
}

4. Execute este comando para criar um novo canal de entrega, referenciando o arquivo de configuração JSON criado na etapa anterior:

aws configservice put-delivery-channel --delivery-channel file://deliveryChannel.json

5. Inicie o gravador de configuração executando o seguinte comando:

aws configservice start-configuration-recorder --configuration-recorder-name default

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Aws Security Hub Enabled

Nome da categoria na API: AWS_SECURITY_HUB_ENABLED

O Security Hub coleta dados de segurança de contas, serviços e produtos de parceiros de terceiros com suporte da AWS. Ele ajuda você a analisar tendências de segurança e identificar os problemas de segurança de maior prioridade. Quando você ativa o Security Hub, ele começa a consumir, agregar, organizar e priorizar as descobertas dos serviços da AWS que você ativou, como Amazon GuardDuty, Amazon Inspector e Amazon Macie. Também é possível ativar integrações com produtos de segurança de parceiros da AWS.

Recomendação: verifique se a Central de Segurança da AWS está ativada

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

1. Use as credenciais da identidade do IAM para fazer login no console do Security Hub.
2. Quando você abrir o console do Security Hub pela primeira vez, escolha "Ativar a Central de Segurança da AWS".
3. Na página de boas-vindas, os padrões de segurança listam os padrões de segurança compatíveis com o Security Hub.
4. Escolha "Ativar a Central de Segurança".

CLI da AWS

1. Execute o comando enable-security-hub. Para ativar os padrões padrão, inclua --enable-default-standards.

aws securityhub enable-security-hub --enable-default-standards

2. Para ativar o hub de segurança sem os padrões padrão, inclua --no-enable-default-standards.

aws securityhub enable-security-hub --no-enable-default-standards

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Cloudtrail Logs Encrypted Rest Using Kms Cmks

Nome da categoria na API: CLOUDTRAIL_LOGS_ENCRYPTED_REST_USING_KMS_CMKS

O AWS CloudTrail é um serviço da Web que registra chamadas de API da AWS para uma conta e disponibiliza esses registros para usuários e recursos de acordo com as políticas do IAM. O AWS Key Management Service (KMS) é um serviço gerenciado que ajuda a criar e controlar as chaves de criptografia usadas para criptografar os dados da conta e usa módulos de segurança de hardware (HSMs) para proteger a segurança das chaves de criptografia. Os registros do CloudTrail podem ser configurados para aproveitar a criptografia do lado do servidor (SSE) e as chaves mestras criadas pelo cliente (CMK) do KMS para proteger ainda mais os registros do CloudTrail. É recomendável que o CloudTrail seja configurado para usar o SSE-KMS.

Recomendação: verifique se os registros do CloudTrail são criptografados em repouso usando CMKs do KMS

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

1. Faça login no console de gerenciamento da AWS e abra o console do CloudTrail em https://console.aws.amazon.com/cloudtrail.
2. No painel de navegação à esquerda, escolha Trails .
3. Clique em uma trilha
4. Na seção S3, clique no botão de edição (ícone de lápis).
5. Clique em Advanced.
6. Selecione uma CMK no menu suspenso KMS key Id
   . - Observação: verifique se a CMK está localizada na mesma região do bucket do S3.
   - Observação: será necessário aplicar uma política de chaves do KMS na CMK selecionada para que o CloudTrail seja um serviço que criptografa e descriptografa arquivos de registro usando a CMK fornecida. Confira aqui as etapas para editar a política de chaves CMK selecionada.
7. Clique em Save.
8. Uma mensagem de notificação vai aparecer informando que você precisa ter permissões de descriptografia na chave KMS especificada para descriptografar os arquivos de registro.
9. Clique em Yes.

CLI da AWS

aws cloudtrail update-trail --name <trail_name> --kms-id <cloudtrail_kms_key>
aws kms put-key-policy --key-id <cloudtrail_kms_key> --policy <cloudtrail_kms_key_policy>

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Cloudtrail Log File Validation Enabled

Nome da categoria na API: CLOUDTRAIL_LOG_FILE_VALIDATION_ENABLED

A validação de arquivos de registro do CloudTrail cria um arquivo de resumo assinado digitalmente que contém um hash de cada registro gravado pelo CloudTrail no S3. Esses arquivos de resumo podem ser usados para determinar se um arquivo de registro foi alterado, excluído ou não alterado depois que o CloudTrail entregou o registro. É recomendável ativar a validação de arquivos em todos os CloudTrails.

Recomendação: verifique se a validação do arquivo de registros do CloudTrail está ativada

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

1. Faça login no console de gerenciamento da AWS e abra o console do IAM em https://console.aws.amazon.com/cloudtrail.
2. Clique em Trails no painel de navegação à esquerda.
3. Clique na trilha desejada.
4. Na seção General details, clique em edit.
5. Na seção Advanced settings
6. Marque a caixa de ativação em Log file validation.
7. Clique em Save changes.

CLI da AWS

aws cloudtrail update-trail --name <trail_name> --enable-log-file-validation

A validação periódica de registros usando esses resumos pode ser realizada executando o seguinte comando:

aws cloudtrail validate-logs --trail-arn <trail_arn> --start-time <start_time> --end-time <end_time>

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Cloudtrail Trails Integrated Cloudwatch Logs

Nome da categoria na API: CLOUDTRAIL_TRAILS_INTEGRATED_CLOUDWATCH_LOGS

O AWS CloudTrail é um serviço da Web que registra chamadas da API da AWS feitas em uma determinada conta da AWS. As informações gravadas incluem a identidade do autor da chamada da API, o horário da chamada, o endereço IP de origem do autor da chamada, os parâmetros de solicitação e os elementos de resposta retornados pelo serviço da AWS. O CloudTrail usa o Amazon S3 para armazenamento e envio de arquivos de registro. Além de capturar registros do CloudTrail em um bucket do S3 especificado para análise de longo prazo, é possível realizar análises em tempo real configurando o CloudTrail para enviar registros aos Logs do CloudWatch. Para um rastro ativado em todas as regiões de uma conta, o CloudTrail envia arquivos de registro de todas elas para um grupo de registros do CloudWatch Logs. Recomendamos que os registros do CloudTrail sejam enviados para os registros do CloudWatch.

Observação: a intenção desta recomendação é garantir que a atividade da conta da AWS seja capturada, monitorada e alarme adequadamente. Os registros do CloudWatch são uma maneira nativa de fazer isso usando os serviços da AWS, mas não impedem o uso de uma solução alternativa.

Recomendação: verifique se as trilhas do CloudTrail estão integradas aos registros do CloudWatch

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

1. Faça login no console do CloudTrail em https://console.aws.amazon.com/cloudtrail/
2. Selecione o Trail que precisa ser atualizado.
3. Role para baixo até CloudWatch Logs
4. Clique em Edit.
5. Em CloudWatch Logs, clique na caixa Enabled.
6. Em Log Group, escolha "Novo" ou selecione um grupo de registros existente.
7. Edite o Log group name para que ele corresponda ao CloudTrail ou escolha o grupo do CloudWatch atual.
8. Em IAM Role, escolha "Novo" ou selecione um existente.
9. Edite o Role name para corresponder ao CloudTrail ou escolha o papel do IAM.
10. Clique em "Salvar alterações".

CLI da AWS

aws cloudtrail update-trail --name <trail_name> --cloudwatch-logs-log-group-arn <cloudtrail_log_group_arn> --cloudwatch-logs-role-arn <cloudtrail_cloudwatchLogs_role_arn>

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Cloudwatch Alarm Action Check

Nome da categoria na API: CLOUDWATCH_ALARM_ACTION_CHECK

Isso verifica se o Amazon Cloudwatch tem ações definidas quando um alarme transita entre os estados "OK", "ALARM" e "INSUFFICIENT_DATA".

Configurar ações para o estado ALARM nos alarmes do Amazon CloudWatch é muito importante para acionar uma resposta imediata quando as métricas monitoradas ultrapassarem os limites.
Ele garante a resolução rápida de problemas, reduz o tempo de inatividade e permite a correção automática, mantendo a integridade do sistema e evitando falhas.

Os alarmes têm pelo menos uma ação.
Os alarmes têm pelo menos uma ação quando passam do estado "INSUFFICIENT_DATA" para qualquer outro estado.
(Opcional) Os alarmes têm pelo menos uma ação quando transitam para um estado "OK" a partir de qualquer outro estado.

Recomendação: verifique se os alarmes do CloudWatch têm pelo menos uma ação de alarme, uma ação INSUFFICIENT_DATA ou uma ação OK ativada.

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

Para configurar ações ALARM para seus alarmes do Amazon CloudWatch, faça o seguinte.

1. Abra o console do Amazon CloudWatch em https://console.aws.amazon.com/cloudwatch/.
2. No painel de navegação, em "Alarmes", selecione "Todos os alarmes".
3. Escolha o alarme do Amazon CloudWatch que você quer modificar, escolha "Ações" e selecione "Editar".
4. À esquerda, escolha "Etapa 2: configurar ações opcionais".
5. Para o gatilho de estado do alarme, selecione a opção "Em alarme" para configurar uma ação baseada em ALARME.
6. Para enviar uma notificação para um tópico do SNS recém-criado, selecione "Criar novo tópico".
7. Na caixa "Criar novo tópico...", especifique um nome de tópico do SNS exclusivo.
8. Na caixa "Pontos de extremidade de e-mail que vão receber a notificação…", especifique um ou mais endereços de e-mail.
9. Em seguida, selecione "Criar tópico" para criar o tópico do Amazon SNS necessário.
10. No canto inferior direito, selecione "Próxima", "Próxima" e escolha "Atualizar alarme" para aplicar as mudanças.
11. Abra seu cliente de e-mail e, na mensagem das notificações da AWS, clique no link para confirmar sua inscrição no tópico do SNS em questão.
12. Repita as etapas 4 a 11 e, na etapa 5, escolha "OK" e "Dados insuficientes" para o gatilho de estado de alarme e configure ações para esses dois estados.
13. Repita o processo para todos os outros alarmes do CloudWatch na mesma região da AWS.
14. Repita o processo para todos os outros alarmes do CloudWatch em todas as outras regiões da AWS.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Cloudwatch Log Group Encrypted

Nome da categoria na API: CLOUDWATCH_LOG_GROUP_ENCRYPTED

Essa verificação garante que os registros do CloudWatch sejam configurados com o KMS.

Os dados do grupo de registros são sempre criptografados nos Logs do CloudWatch. Por padrão, os CloudWatch Logs usam a criptografia do lado do servidor para os dados de registro em repouso. Como alternativa, você pode usar o AWS Key Management Service para essa criptografia. Nesse caso, a criptografia é feita usando uma chave do AWS KMS. A criptografia usando o AWS KMS é ativada no nível do grupo de registros, associando uma chave do KMS a um grupo de registros, seja ao criar o grupo de registros ou depois que ele existir.

Recomendação: verifica se todos os grupos de registro dos Registros do Amazon CloudWatch estão criptografados com o KMS

Para mais informações, consulte Criptografar dados de registro no CloudWatch Logs usando o AWS Key Management Service no guia do usuário do Amazon CloudWatch.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

CloudTrail CloudWatch Logs Enabled

Nome da categoria na API: CLOUD_TRAIL_CLOUD_WATCH_LOGS_ENABLED

Esse controle verifica se as trilhas do CloudTrail estão configuradas para enviar registros aos registros do CloudWatch. O controle falha se a propriedade CloudWatchLogsLogGroupArn do rastro estiver vazia.

O CloudTrail registra chamadas da API da AWS feitas em uma determinada conta. As informações gravadas incluem o seguinte:

• A identidade do autor da chamada da API
• O horário da chamada de API
• O endereço IP de origem do autor da chamada da API
• Os parâmetros de solicitação
• Os elementos de resposta retornados pelo serviço da AWS

O CloudTrail usa o Amazon S3 para armazenamento e envio de arquivos de registro. É possível capturar registros do CloudTrail em um bucket do S3 especificado para análise de longo prazo. Para realizar análises em tempo real, configure o CloudTrail para enviar registros aos Logs do CloudWatch.

Para um rastro ativado em todas as regiões de uma conta, o CloudTrail envia arquivos de registro de todas elas para um grupo de registros do CloudWatch Logs.

O Security Hub recomenda que você envie os registros do CloudTrail para os registros do CloudWatch. Essa recomendação tem o objetivo de garantir que a atividade da conta seja capturada, monitorada e alarme adequadamente. Você pode usar os registros do CloudWatch para configurar isso com seus serviços da AWS. Essa recomendação não impede o uso de uma solução diferente.

O envio de registros do CloudTrail para os registros do CloudWatch facilita o registro de atividades em tempo real e histórico com base no usuário, na API, no recurso e no endereço IP. Você pode usar essa abordagem para estabelecer alarmes e notificações para atividades anormais ou sensíveis da conta.

Recomendação: verifica se todas as trilhas do CloudTrail estão configuradas para enviar registros ao AWS CloudWatch

Para integrar o CloudTrail aos registros do CloudWatch, consulte Enviar eventos para os registros do CloudWatch no guia do usuário do AWS CloudTrail.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

No AWS Credentials in CodeBuild Project Environment Variables

Nome da categoria na API: CODEBUILD_PROJECT_ENVVAR_AWSCRED_CHECK

Isso verifica se o projeto contém as variáveis de ambiente AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY.

As credenciais de autenticação AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY nunca devem ser armazenadas em texto simples, porque isso pode levar à exposição não intencional de dados e ao acesso não autorizado.

Recomendação: verifique se todos os projetos que contêm variáveis de ambiente AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY não estão em texto simples

Para remover variáveis de ambiente de um projeto do CodeBuild, consulte Mudar as configurações de um projeto de build no AWS CodeBuild no guia do usuário do AWS CodeBuild. Verifique se nada está selecionado para as variáveis de ambiente.

É possível armazenar variáveis de ambiente com valores sensíveis no AWS Systems Manager Parameter Store ou no AWS Secrets Manager e, em seguida, extraí-los da especificação de build. Para instruções, consulte a caixa "Importante" na seção "Ambiente" do Guia do usuário do AWS CodeBuild.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Codebuild Project Source Repo Url Check

Nome da categoria na API: CODEBUILD_PROJECT_SOURCE_REPO_URL_CHECK

Verifica se o URL do repositório de origem do Bitbucket de um projeto do AWS CodeBuild contém tokens de acesso pessoal ou um nome de usuário e uma senha. O controle falha se o URL do repositório de origem do Bitbucket contiver tokens de acesso pessoal ou um nome de usuário e uma senha.

As credenciais de login não podem ser armazenadas ou transmitidas em texto simples nem aparecer no URL do repositório de origem. Em vez de tokens de acesso pessoais ou credenciais de login, acesse o provedor de origem no CodeBuild e mude o URL do repositório de origem para conter apenas o caminho para o local do repositório do Bitbucket. O uso de tokens de acesso pessoal ou de credenciais de login pode resultar em exposição não intencional de dados ou acesso não autorizado.

Recomendação: verifica se todos os projetos que usam o github ou bitbucket como fonte usam o oauth

Você pode atualizar seu projeto do CodeBuild para usar o OAuth.

Para remover a autenticação básica / token de acesso pessoal (GitHub) da origem do projeto do CodeBuild

1. Abra o console do CodeBuild em https://console.aws.amazon.com/codebuild/.
2. Escolha o projeto de build que contém tokens de acesso pessoal ou um nome de usuário e uma senha.
3. Em "Editar", escolha "Origem".
4. Escolha "Desconectar do GitHub / Bitbucket".
5. Escolha "Conectar usando OAuth" e, em seguida, "Conectar ao GitHub / Bitbucket".
6. Quando solicitado, escolha "Autorizar" conforme apropriado.
7. Reconfigure o URL do repositório e outras configurações, conforme necessário.
8. Escolha "Atualizar origem".

Para mais informações, consulte Exemplos de casos de uso do CodeBuild no Guia do usuário do AWS CodeBuild.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Credentials Unused 45 Days Greater Disabled

Nome da categoria na API: CREDENTIALS_UNUSED_45_DAYS_GREATER_DISABLED

Os usuários do AWS IAM podem acessar os recursos da AWS usando diferentes tipos de credenciais, como senhas ou chaves de acesso. Recomendamos que todas as credenciais que não foram usadas em 45 dias ou mais sejam desativadas ou removidas.

Recomendação: verifique se as credenciais não usadas há 45 dias ou mais estão desativadas

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

Siga estas etapas para gerenciar a senha não utilizada (acesso do usuário do IAM ao console)

1. Faça login no console de Gerenciamento da AWS:
2. Clique em Services.
3. Clique em IAM.
4. Clique em Users
5. Clique em Security Credentials
6. Selecione o usuário com Console last sign-in maior que 45 dias
7. Clique em Security credentials.
8. Na seção Sign-in credentials, Console password clique em Manage
9. Em "Acesso ao console", selecione Disable
   10.Clique em Apply

Siga estas etapas para desativar as chaves de acesso:

1. Faça login no console de Gerenciamento da AWS:
2. Clique em Services.
3. Clique em IAM.
4. Clique em Users
5. Clique em Security Credentials
6. Selecione as chaves de acesso com mais de 45 dias de uso e
   - Clique em Make Inactive
7. Selecione as chaves de acesso com mais de 45 dias que não foram usadas e
   - Clique no X para Delete

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Default Security Group Vpc Restricts All Traffic

Nome da categoria na API: DEFAULT_SECURITY_GROUP_VPC_RESTRICTS_ALL_TRAFFIC

Uma VPC vem com um grupo de segurança padrão cujas configurações iniciais negam todo o tráfego de entrada, permitem todo o tráfego de saída e permitem todo o tráfego entre as instâncias atribuídas ao grupo de segurança. Se você não especificar um grupo de segurança ao iniciar uma instância, ela será atribuída automaticamente a esse grupo de segurança padrão. Os grupos de segurança fornecem filtragem stateful do tráfego de entrada/saída da rede para os recursos da AWS. É recomendável que o grupo de segurança padrão restrinja todo o tráfego.

O grupo de segurança padrão da VPC padrão em cada região precisa ser atualizado para obedecer à regra. As VPCs recém-criadas vão conter automaticamente um grupo de segurança padrão que precisará ser remediado para obedecer a essa recomendação.

OBSERVAÇÃO:ao implementar essa recomendação, a geração de registros de fluxo da VPC é inestimável para determinar o acesso de porta de privilégio mínimo exigido pelos sistemas para funcionar corretamente, porque ela pode registrar todas as aceitações e rejeições de pacotes que ocorrem nos grupos de segurança atuais. Isso reduz drasticamente a principal barreira para a engenharia de privilégio mínimo, descobrindo as portas mínimas exigidas pelos sistemas no ambiente. Mesmo que a recomendação de registro de fluxo de VPC neste comparativo não seja adotada como uma medida de segurança permanente, ela precisa ser usada durante qualquer período de descoberta e engenharia para grupos de segurança com menos privilégios.

Recomendação: verifique se o grupo de segurança padrão de cada VPC restringe todo o tráfego

Participantes do grupo de segurança

Siga estas etapas para implementar o estado prescrito:

1. Identifique os recursos da AWS que existem no grupo de segurança padrão
2. Crie um conjunto de grupos de segurança de privilégio mínimo para esses recursos
3. Coloque os recursos nesses grupos de segurança
4. Remova os recursos indicados em 1 do grupo de segurança padrão

Estado do grupo de segurança

1. Faça login no console de gerenciamento da AWS em https://console.aws.amazon.com/vpc/home.
2. Repita as próximas etapas para todas as VPCs, incluindo a VPC padrão em cada região da AWS:
3. No painel à esquerda, clique em Security Groups
4. Para cada grupo de segurança padrão, faça o seguinte:
5. Selecione o grupo de segurança default
6. Clique na guia Inbound Rules.
7. Remover todas as regras de entrada
8. Clique na guia Outbound Rules.
9. Remover todas as regras de saída

Recomendado:

Os grupos do IAM permitem que você edite o campo "name". Depois de remediar as regras de grupos padrão para todas as VPCs em todas as regiões, edite este campo para adicionar um texto semelhante a "NÃO USE. NÃO ADICIONAR REGRAS

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Dms Replication Not Public

Nome da categoria na API: DMS_REPLICATION_NOT_PUBLIC

Verifica se as instâncias de replicação do AWS DMS são públicas. Para isso, ele examina o valor do campo PubliclyAccessible.

Uma instância de replicação particular tem um endereço IP particular que não pode ser acessado fora da rede de replicação. Uma instância de replicação precisa ter um endereço IP particular quando os bancos de dados de origem e de destino estão na mesma rede. A rede também precisa estar conectada à VPC da instância de replicação usando uma VPN, o AWS Direct Connect ou o peering de VPC. Para saber mais sobre instâncias de replicação públicas e privadas, consulte Instâncias de replicação públicas e privadas no guia do usuário do AWS Database Migration Service.

Também é necessário garantir que o acesso à configuração da instância do AWS DMS seja limitado apenas a usuários autorizados. Para isso, restrinja as permissões do IAM dos usuários para modificar as configurações e os recursos do AWS DMS.

Recomendação: verifique se as instâncias de replicação do AWS Database Migration Service são públicas

Não é possível mudar a configuração de acesso público de uma instância de replicação do DMS depois de criá-la. Para mudar a configuração de acesso público, exclua e recrie a instância atual. Não selecione a opção "Acessível publicamente".

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Do Setup Access Keys During Initial User Setup All Iam Users Console

Nome da categoria na API: DO_SETUP_ACCESS_KEYS_DURING_INITIAL_USER_SETUP_ALL_IAM_USERS_CONSOLE

O console da AWS não tem caixas de seleção selecionadas por padrão ao criar um novo usuário do IAM. Ao criar as credenciais do usuário do IAM, você precisa determinar o tipo de acesso necessário.

Acesso programático: o usuário do IAM pode precisar fazer chamadas de API, usar a AWS CLI ou as ferramentas do PowerShell para Windows. Nesse caso, crie uma chave de acesso (ID da chave de acesso e uma chave de acesso secreta) para esse usuário.

Acesso ao AWS Management Console: se o usuário precisar acessar o AWS Management Console, crie uma senha para ele.

Recomendação: não configure chaves de acesso durante a configuração inicial de usuário para todos os usuários do IAM que têm uma senha para o console

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

1. Faça login no console de gerenciamento da AWS:
2. Clique em Services.
3. Clique em IAM.
4. Clique em Users
5. Clique em Security Credentials
6. Como administrador
   - Clique no X (Delete) para chaves que foram criadas ao mesmo tempo que o perfil do usuário, mas não foram usadas.
7. Como usuário do IAM
   - Clique no X (Delete) para chaves que foram criadas ao mesmo tempo que o perfil do usuário, mas não foram usadas.

CLI da AWS

aws iam delete-access-key --access-key-id <access-key-id-listed> --user-name <users-name>

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Dynamodb Autoscaling Enabled

Nome da categoria na API: DYNAMODB_AUTOSCALING_ENABLED

Isso verifica se uma tabela do Amazon DynamoDB pode dimensionar a capacidade de leitura e gravação conforme necessário. Esse controle é transmitido se a tabela usar o modo de capacidade sob demanda ou o modo provisionado com o escalonamento automático configurado. O escalonamento da capacidade com a demanda evita exceções de limitação, o que ajuda a manter a disponibilidade dos seus aplicativos.

As tabelas do DynamoDB no modo de capacidade sob demanda são limitadas apenas pelas cotas de tabela padrão de throughput do DynamoDB. Para aumentar essas cotas, registre um tíquete de suporte na AWS Support.

As tabelas do DynamoDB no modo provisionado com escalonamento automático ajustam a capacidade de throughput provisionada de forma dinâmica em resposta aos padrões de tráfego. Para mais informações sobre o controle de solicitação do DynamoDB, consulte Controle de solicitação e capacidade de pico no Guia para Desenvolvedores do Amazon DynamoDB.

Recomendação: as tabelas DynamoDB precisam escalonar a capacidade automaticamente conforme a demanda

Para instruções detalhadas sobre como ativar o escalonamento automático do DynamoDB em tabelas atuais no modo de capacidade, consulte Ativar o escalonamento automático do DynamoDB em tabelas atuais no Guia para desenvolvedores do Amazon DynamoDB.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Dynamodb In Backup Plan

Nome da categoria na API: DYNAMODB_IN_BACKUP_PLAN

Esse controle avalia se uma tabela do DynamoDB está coberta por um plano de backup. O controle falha se uma tabela do DynamoDB não estiver coberta por um plano de backup. Esse controle avalia apenas as tabelas do DynamoDB que estão no estado ACTIVE.

Os backups ajudam você a se recuperar mais rapidamente de um incidente de segurança. Eles também fortalecem a resiliência dos seus sistemas. Incluir tabelas do DynamoDB em um plano de backup ajuda a proteger seus dados contra perda ou exclusão acidental.

Recomendação: as tabelas do DynamoDB precisam estar cobertas por um plano de backup

Para adicionar uma tabela do DynamoDB a um plano de backup do AWS Backup, consulte Como atribuir recursos a um plano de backup no guia para desenvolvedores do AWS Backup.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Dynamodb Pitr Enabled

Nome da categoria na API: DYNAMODB_PITR_ENABLED

A recuperação pontual (PITR) é um dos mecanismos disponíveis para fazer backup de tabelas do DynamoDB.

Um backup de ponto no tempo é mantido por 35 dias. Caso sua exigência seja de retenção mais longa, consulte Configurar backups programados do Amazon DynamoDB usando o AWS Backup na documentação da AWS.

Recomendação: verifica se a recuperação pontual (PITR) está ativada para todas as tabelas do AWS DynamoDB

Para corrigir essa descoberta, siga estas etapas:

Terraform

Para definir a PITR para tabelas do DynamoDB, defina o bloco point_in_time_recovery:

resource "aws_dynamodb_table" "example" {
  # ... other configuration ...
  point_in_time_recovery {
    enabled = true
  }
}

Console da AWS

Para ativar a recuperação pontual do DynamoDB em uma tabela

1. Abra o console do DynamoDB em https://console.aws.amazon.com/dynamodb/.
2. Escolha a tabela com que você quer trabalhar e selecione "Backups".
3. Na seção "Recuperação pontual", em "Status", escolha "Ativar".
4. Escolha "Ativar" novamente para confirmar a mudança.

CLI da AWS

aws dynamodb update-continuous-backups \
  --table-name "GameScoresOnDemand" \
  --point-in-time-recovery-specification "PointInTimeRecoveryEnabled=true"

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Dynamodb Table Encrypted Kms

Nome da categoria na API: DYNAMODB_TABLE_ENCRYPTED_KMS

Verifica se todas as tabelas do DynamoDB estão criptografadas com uma chave KMS gerenciada pelo cliente (não padrão).

Recomendação: verifica se todas as tabelas do DynamoDB foram criptografadas com o AWS Key Management Service (KMS)

Para corrigir essa descoberta, siga estas etapas:

Terraform

Para corrigir esse controle, crie uma chave do AWS KMS e use-a para criptografar o recurso do DynamoDB que está em violação.

resource "aws_kms_key" "dynamodb_encryption" {
  description         = "Used for DynamoDB encryption configuration"
  enable_key_rotation = true
}

resource "aws_dynamodb_table" "example" {
  # ... other configuration ...
  server_side_encryption {
    enabled     = true
    kms_key_arn = aws_kms_key.dynamodb_encryption.arn
  }
}

Console da AWS

Supondo que haja uma chave AWS KMS disponível para criptografar o DynamoDB.

Para mudar a criptografia de uma tabela do DynamoDB para uma chave KMS gerenciada e pertencente ao cliente.

1. Abra o console do DynamoDB em https://console.aws.amazon.com/dynamodb/.
2. Escolha a tabela com que você quer trabalhar e clique em "Configurações adicionais".
3. Em "Criptografia", escolha "Gerenciar criptografia".
4. Para "Criptografia em repouso", escolha "Armazenado na sua conta e de sua propriedade e gerenciamento".
5. Selecione a chave da AWS a ser usada. Salve as alterações.

CLI da AWS

aws dynamodb update-table \
  --table-name <value> \
  --sse-specification "Enabled=true,SSEType=KMS,KMSMasterKeyId=<kms_key_arn>"

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Ebs Optimized Instance

Nome da categoria na API: EBS_OPTIMIZED_INSTANCE

Verifica se a otimização do EBS está ativada para as instâncias do EC2 que podem ser otimizadas para EBS

Recomendação: verifica se a otimização do EBS está ativada em todas as instâncias em que a otimização do EBS é aceita

Para configurar as configurações de instâncias otimizadas para EBS, consulte Instâncias otimizadas para Amazon EBS no guia do usuário do Amazon EC2.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Ebs Snapshot Public Restorable Check

Nome da categoria na API: EBS_SNAPSHOT_PUBLIC_RESTORABLE_CHECK

Verifica se os snapshots do Amazon Elastic Block Store não são públicos. O controle falha se os snapshots do Amazon EBS puderem ser restaurados por qualquer pessoa.

Os snapshots do EBS são usados para fazer backup dos dados dos seus volumes do EBS no Amazon S3 em um determinado momento. Você pode usar os snapshots para restaurar estados anteriores dos volumes EBS. É raro que seja aceitável compartilhar um snapshot com o público. Normalmente, a decisão de compartilhar um snapshot publicamente foi tomada por engano ou sem um entendimento completo das implicações. Essa verificação ajuda a garantir que todo esse compartilhamento foi totalmente planejado e intencional.

Recomendação: os snapshots do Amazon EBS não devem ser publicamente restauráveis

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

Para corrigir esse problema, atualize o snapshot do EBS para torná-lo privado em vez de público.

Para tornar um snapshot público do EBS privado:

1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.
2. No painel de navegação, em "Elastic Block Store", escolha o menu "Snapshots" e selecione o snapshot público.
3. Em "Ações", escolha "Modificar permissões".
4. Escolha "Particular".
5. (Opcional) Adicione os números de conta da AWS das contas autorizadas para compartilhar seu snapshot e escolha "Adicionar permissão".
6. Selecione "Salvar".

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Ebs Volume Encryption Enabled All Regions

Nome da categoria na API: EBS_VOLUME_ENCRYPTION_ENABLED_ALL_REGIONS

O Elastic Compute Cloud (EC2) oferece suporte à criptografia em repouso ao usar o serviço Elastic Block Store (EBS). Embora desativado por padrão, é possível forçar a criptografia na criação de volumes do EBS.

Recomendação: verifique se a criptografia de volume do EBS está ativada em todas as regiões

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

1. Faça login no console de gerenciamento da AWS e abra o console do Amazon EC2 usando https://console.aws.amazon.com/ec2/
2. Em Account attributes, clique em EBS encryption.
3. Clique em Manage.
4. Clique na caixa de seleção Enable.
5. Clique em Update EBS encryption.
6. Repita para cada região que exigir a mudança.

Observação:a criptografia de volume do EBS é configurada por região.

CLI da AWS

1. Executar

aws --region <region> ec2 enable-ebs-encryption-by-default

2. Verifique se "EbsEncryptionByDefault": true aparece.
3. Repita o processo para cada região que precisa da mudança.

Observação:a criptografia de volume do EBS é configurada por região.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Ec2 Instances In Vpc

Nome da categoria na API: EC2_INSTANCES_IN_VPC

A Amazon VPC oferece mais recursos de segurança do que o EC2 Classic. É recomendável que todos os nós pertençam a uma VPC da Amazon.

Recomendação: verifique se todas as instâncias pertencem a uma VPC

Para corrigir essa descoberta, siga estas etapas:

Terraform

Se você tiver instâncias clássicas do EC2 definidas no Terraform, poderá modificar seus recursos para que façam parte de uma VPC. Essa migração depende de uma arquitetura que atenda melhor às suas necessidades. Confira a seguir um exemplo simples do Terraform que ilustra um EC2 exposto publicamente em uma VPC.

  resource "aws_vpc" "example_vpc" {
    cidr_block = "10.0.0.0/16"
  }

  resource "aws_subnet" "example_public_subnet" {
    vpc_id            = aws_vpc.example_vpc.id
    cidr_block        = "10.0.1.0/24"
    availability_zone = "1a"
  }

  resource "aws_internet_gateway" "example_igw" {
    vpc_id = aws_vpc.example_vpc.id
  }

  resource "aws_key_pair" "example_key" {
    key_name   = "web-instance-key"
    public_key = "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD3F6tyPEFEzV0LX3X8BsXdMsQz1x2cEikKDEY0aIj41qgxMCP/iteneqXSIFZBp5vizPvaoIR3Um9xK7PGoW8giupGn+EPuxIA4cDM4vzOqOkiMPhz5XK0whEjkVzTo4+S0puvDZuwIsdiW9mxhJc7tgBNL0cYlWSYVkz4G/fslNfRPW5mYAM49f4fhtxPb5ok4Q2Lg9dPKVHO/Bgeu5woMc7RY0p1ej6D4CKFE6lymSDJpW0YHX/wqE9+cfEauh7xZcG0q9t2ta6F6fmX0agvpFyZo8aFbXeUBr7osSCJNgvavWbM/06niWrOvYX2xwWdhXmXSrbX8ZbabVohBK41 [e-mail]"
  }

  resource "aws_security_group" "web_sg" {
    name   = "http and ssh"
    vpc_id = aws_vpc.some_custom_vpc.id

    ingress {
      from_port   = 80
      to_port     = 80
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }

    ingress {
      from_port   = 22
      to_port     = 22
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }

    egress {
      from_port   = 0
      to_port     = 0
      protocol    = -1
      cidr_blocks = ["0.0.0.0/0"]
    }
  }

  resource "aws_instance" "web" {
    ami                    = <ami_id>
    instance_type          = <instance_flavor>
    key_name               = aws_key_pair.example_key.name
    monitoring             = true
    subnet_id              = aws_subnet.example_public_subnet.id
    vpc_security_group_ids = [aws_security_group.web_sg.id]
    metadata_options {
      http_tokens = "required"
    }
  }

Console da AWS

Para migrar do EC2 Classic para a VPC, consulte Migrar do EC2-Classic para uma VPC.

CLI da AWS

Este exemplo da AWS CLI ilustra a mesma infraestrutura definida com o Terraform. É um exemplo simples de uma instância do EC2 exposta publicamente em uma VPC.

Criar VPC

  aws ec2 create-vpc \
  --cidr-block 10.0.0.0/16

Criar sub-rede pública

  aws ec2 create-subnet \
  --availability-zone 1a \
  --cidr-block 10.0.1.0/24 \
  --vpc-id <id_from_create-vpc_command>

Criar gateway da Internet

  aws ec2 create-internet-gateway

Anexar o gateway de Internet à VPC

  aws ec2 attach-internet-gateway \
  --internet-gateway-id <id_from_create-internet-gateway_command> \
  --vpc-id <id_from_create-vpc_command>

Criar par de chaves: isso vai salvar sua chave privada em /.ssh/web-instance-key.pem.

  aws ec2 create-key-pair \
  --key-name web-instance-key \
  --query "KeyMaterial" \
  --output text > ~/.ssh/web-instance-key.pem && \
  chmod 400 ~/.ssh/web-instance-key.pem

Criar grupo de segurança

  aws ec2 create-security-group \
  --group-name "http and ssh" \
  --vpc-id <id_from_create-vpc_command>

Criar regras de grupo de segurança: para um acesso mais restrito, defina um CIDR mais restrito para SSH na porta 22.

  aws ec2 authorize-security-group-ingress \
  --group-id <id_from_create-security-group_command>
  --protocol tcp \
  --port 80 \
  --cidr 0.0.0.0/0

  aws ec2 authorize-security-group-ingress \
  --group-id <id_from_create-security-group_command>
  --protocol tcp \
  --port 22 \
  --cidr 0.0.0.0/0

  aws ec2 authorize-security-group-egress \
  --group-id <id_from_create-security-group_command>
  --protocol -1 \
  --port 0 \
  --cidr 0.0.0.0/0

Criar uma instância EC2

  aws ec2 run-instances \
  --image-id <ami_id> \
  --instance-type <instance_flavor> \
  --metadata-options "HttpEndpoint=enabled,HttpTokens=required" \
  --monitoring true \
  --key-name web-instance-key \
  --subnet-id <id_from_create-subnet_command> \
  --security-group-ids <id_from_create-security-group_command>

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Ec2 Instance No Public Ip

Nome da categoria na API: EC2_INSTANCE_NO_PUBLIC_IP

As instâncias do EC2 que têm um endereço IP público estão em maior risco de comprometimento. Recomendamos que as instâncias do EC2 não sejam configuradas com um endereço IP público.

Recomendação: garante que nenhuma instância tenha um IP público

Para corrigir essa descoberta, siga estas etapas:

Terraform

Use o argumento associate_public_ip_address = false com o recurso aws_instance para garantir que as instâncias do EC2 sejam provisionadas sem um endereço IP público

resource "aws_instance" "no_public_ip" {
  ...
  associate_public_ip_address = false
}

Console da AWS

Por padrão, as sub-redes não padrão têm o atributo de endereço público IPv4 definido como falso, e as sub-redes padrão têm esse atributo definido como verdadeiro. Uma exceção é uma sub-rede não padrão criada pelo assistente de lançamento de instâncias do Amazon EC2. O assistente define o atributo como "true". É possível modificar esse atributo usando o console da Amazon VPC.

Para modificar o comportamento de endereçamento IPv4 público da sub-rede

1. Abra o console da Amazon VPC em https://console.aws.amazon.com/vpc/.
2. No painel de navegação, escolha Sub-redes.
3. Selecione a sub-rede e escolha Ações, Editar configurações da sub-rede.
4. A caixa de seleção Ativar a atribuição automática de endereço IPv4 público, se selecionada, solicita um endereço IPv4 público para todas as instâncias lançadas na sub-rede selecionada. Marque ou desmarque a caixa de seleção conforme necessário e clique em Salvar.

CLI da AWS

O comando a seguir executa uma instância do EC2 em uma sub-rede padrão sem associar um endereço IP público a ela.

aws ec2 run-instances \
--image-id <ami_id> \
--instance-type <instance_flavor> \
--no-associate-public-ip-address \
--key-name MyKeyPair

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Ec2 Managedinstance Association Compliance Status Check

Nome da categoria na API: EC2_MANAGEDINSTANCE_ASSOCIATION_COMPLIANCE_STATUS_CHECK

Uma associação do State Manager é uma configuração atribuída às suas instâncias gerenciadas. A configuração define o estado que você quer manter nas instâncias. Por exemplo, uma associação pode especificar que o software antivírus precisa estar instalado e em execução nas suas instâncias ou que determinadas portas precisam ser fechadas. As instâncias do EC2 que têm uma associação com o AWS Systems Manager estão sob o gerenciamento do Systems Manager, o que facilita a aplicação de patches, a correção de configurações incorretas e a resposta a eventos de segurança.

Recomendação: verifique o status de compliance da associação do AWS Systems Manager

Para corrigir essa descoberta, siga estas etapas:

Terraform

O exemplo a seguir demonstra como criar uma instância EC2 simples, um documento do AWS Systems Manager (SSM) e uma associação entre o SSM e a instância EC2. Os documentos aceitos são do tipo Command e Policy.

resource "aws_instance" "web" {
  ami           = "<iam_id>"
  instance_type = "<instance_flavor>"
}

resource "aws_ssm_document" "check_ip" {
  name          = "check-ip-config"
  document_type = "Command"

  content = <<DOC
  {
    "schemaVersion": "1.2",
    "description": "Check ip configuration of a Linux instance.",
    "parameters": {

    },
    "runtimeConfig": {
      "aws:runShellScript": {
        "properties": [
          {
            "id": "0.aws:runShellScript",
            "runCommand": ["ifconfig"]
          }
        ]
      }
    }
  }
DOC
}

resource "aws_ssm_association" "check_ip_association" {
  name = aws_ssm_document.check_ip.name

  targets {
    key    = "InstanceIds"
    values = [aws_instance.web.id]
  }
}

Console da AWS

Para saber como configurar associações com o AWS Systems Manager usando o console, consulte Como criar associações na documentação do AWS Systems Manager.

CLI da AWS

Criar um documento de SSM

aws ssm create-document \
--name <document_name> \
--content  file://path/to-file/document.json \
--document-type "Command"

Criar uma associação do SSM

aws ssm create-association \
--name <association_name> \
--targets "Key=InstanceIds,Values=<instance-id-1>,<instance-id-2>"

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Ec2 Managedinstance Patch Compliance Status Check

Nome da categoria na API: EC2_MANAGEDINSTANCE_PATCH_COMPLIANCE_STATUS_CHECK

Esse controle verifica se o status de compliance da associação do AWS Systems Manager é COMPLIANT ou NON_COMPLIANT depois que a associação é executada em uma instância. O controle falhará se o status de compliance da associação for NON_COMPLIANT.

Uma associação do State Manager é uma configuração atribuída às suas instâncias gerenciadas. A configuração define o estado que você quer manter nas instâncias. Por exemplo, uma associação pode especificar que o software antivírus precisa estar instalado e em execução nas suas instâncias ou que determinadas portas precisam ser fechadas.

Depois de criar uma ou mais associações ao Gerenciador de estado, as informações sobre o status de compliance ficam disponíveis imediatamente. É possível conferir o status de compliance no console ou em resposta a comandos da AWS CLI ou ações correspondentes da API Systems Manager. Para associações, a conformidade de configuração mostra o status de compliance (em conformidade ou não em conformidade). Ele também mostra o nível de gravidade atribuído à associação, como "Crítica" ou "Média".

Para saber mais sobre a conformidade da associação do State Manager, consulte Sobre a conformidade da associação do State Manager no Guia do usuário do AWS Systems Manager.

Recomendação: verifique o status do compliance do patch do AWS Systems Manager

Uma associação com falha pode estar relacionada a diferentes coisas, incluindo destinos e nomes de documentos do SSM. Para corrigir esse problema, primeiro identifique e investigue a associação, conferindo o histórico de associações. Para ver instruções sobre como consultar o histórico de associação, consulte Consultar históricos de associação no guia do usuário do AWS Systems Manager.

Depois de investigar, você pode editar a associação para corrigir o problema identificado. É possível editar uma associação para especificar um novo nome, programação, nível de gravidade ou destinos. Depois que você edita uma associação, o AWS Systems Manager cria uma nova versão. Para instruções sobre como editar uma associação, consulte Como editar e criar uma nova versão de uma associação no Guia do usuário do AWS Systems Manager.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Ec2 Metadata Service Allows Imdsv2

Nome da categoria na API: EC2_METADATA_SERVICE_ALLOWS_IMDSV2

Ao ativar o serviço de metadados em instâncias do AWS EC2, os usuários têm a opção de usar a versão 1 do serviço de metadados de instância (IMDSv1, um método de solicitação/resposta) ou a versão 2 do serviço de metadados de instância (IMDSv2, um método orientado a sessões).

Recomendação: verifique se o serviço de metadados do EC2 permite apenas IMDSv2

No console:
1. Faça login no console de gerenciamento da AWS e abra o console do Amazon EC2 usando https://console.aws.amazon.com/ec2/
2. No menu "Instâncias", selecione "Instâncias".
3. Selecione cada instância e escolha "Ações" > "Modificar opções de metadados da instância".
4. Se o serviço de metadados da instância estiver ativado, defina IMDSv2 como "Obrigatório".

Na linha de comando:

aws ec2 modify-instance-metadata-options --instance-id <instance_id> --http-tokens required

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Ec2 Volume Inuse Check

Nome da categoria na API: EC2_VOLUME_INUSE_CHECK

Identifique e remova volumes do Elastic Block Store (EBS) não anexados (não usados) na sua conta da AWS para reduzir o custo da sua fatura mensal da AWS. A exclusão de volumes EBS não utilizados também reduz o risco de dados confidenciais/sensíveis saírem da sua empresa. Além disso, esse controle também verifica se as instâncias do EC2 arquivadas foram configuradas para excluir volumes no encerramento.

Por padrão, as instâncias do EC2 são configuradas para excluir os dados em todos os volumes do EBS associados à instância e para excluir o volume raiz do EBS da instância. No entanto, por padrão, todos os volumes do EBS não raiz anexados à instância, na inicialização ou durante a execução, são mantidos após a interrupção.

Recomendação: verifica se os volumes do EBS estão anexados às instâncias do EC2 e configurados para exclusão no encerramento da instância

Para corrigir essa descoberta, siga estas etapas:

Terraform

Para evitar esse cenário usando o Terraform, crie instâncias do EC2 com blocos EBS incorporados. Isso garante que todos os blocos EBS associados à instância (não apenas à raiz) sejam excluídos no encerramento da instância, com o atributo ebs_block_device.delete_on_termination definido como true.

resource "aws_instance" "web" {
    ami                    = <ami_id>
    instance_type          = <instance_flavor>
    ebs_block_device {
      delete_on_termination = true # Default
      device_name           = "/dev/sdh"
    }

Console da AWS

Para excluir um volume do EBS usando o console

1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.
2. No painel de navegação, escolha Volumes.
3. Selecione o volume a ser excluído e escolha Ações, Excluir volume.
4. Observação: se a opção "Excluir volume" estiver esmaecida, o volume estará anexado a uma instância. É necessário desconectar o volume da instância antes de excluí-lo.
5. Na caixa de diálogo de confirmação, escolha Excluir.

CLI da AWS

Este comando de exemplo exclui um volume disponível com o ID vol-049df61146c4d7901. Se o comando for bem-sucedido, nenhuma saída será retornada.

aws ec2 delete-volume --volume-id vol-049df61146c4d7901

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Efs Encrypted Check

Nome da categoria na API: EFS_ENCRYPTED_CHECK

O Amazon EFS oferece suporte a duas formas de criptografia para sistemas de arquivos: criptografia de dados em trânsito e criptografia em repouso. Isso verifica se todos os sistemas de arquivos EFS estão configurados com criptografia em repouso em todas as regiões ativadas na conta.

Recomendação: verifica se o EFS está configurado para criptografar dados de arquivos usando o KMS

Para corrigir essa descoberta, siga estas etapas:

Terraform

O snippet de código a seguir pode ser usado para criar um EFS criptografado pelo KMS. Observação: o atributo kms_key_id é opcional, e uma chave será criada se nenhum ID de chave do KMS for transmitido.

resource "aws_efs_file_system" "encrypted-efs" {
  creation_token = "my-kms-encrypted-efs"
  encrypted      = true
  kms_key_id     = "arn:aws:kms:us-west-2:12344375555:key/16393ebd-3348-483f-b162-99b6648azz23"

  tags = {
    Name = "MyProduct"
  }
}

Console da AWS

Para configurar o EFS com criptografia usando o console da AWS, consulte Como criptografar um sistema de arquivos em repouso usando o console.

CLI da AWS

É importante notar que, embora a criação de EFS no console ative a criptografia em repouso por padrão, isso não é verdade para EFS criados usando a CLI, a API ou o SDK. O exemplo a seguir permite criar um sistema de arquivos criptografado na sua infraestrutura.

aws efs create-file-system \
--backup \
--encrypted \
--region us-east-1 \

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Efs In Backup Plan

Nome da categoria na API: EFS_IN_BACKUP_PLAN

As práticas recomendadas da Amazon recomendam configurar backups para os sistemas de arquivos elástica (EFS, na sigla em inglês). Isso verifica todos os EFS em todas as regiões ativadas na sua conta da AWS para backups ativados.

Recomendação: verifica se os sistemas de arquivos EFS estão incluídos nos planos de backup do AWS

Para corrigir essa descoberta, siga estas etapas:

Terraform

Use o recurso aws_efs_backup_policy para configurar uma política de backup para sistemas de arquivos EFS.

resource "aws_efs_file_system" "encrypted-efs" {
  creation_token = "my-encrypted-efs"
  encrypted      = true

  tags = merge({
    Name = "${local.resource_prefix.value}-efs"
    }, {
    git_file             = "terraform/aws/efs.tf"
    git_org              = "your_git_org"
    git_repo             = "your_git_repo"
  })
}

resource "aws_efs_backup_policy" "policy" {
  file_system_id = aws_efs_file_system.encrypted-efs.id

  backup_policy {
    status = "ENABLED"
  }
}

Console da AWS

Há duas opções para fazer backup do EFS: o serviço AWS Backup e a solução de backup EFS-to-EFS. Para corrigir o EFS sem backup usando o console, consulte:

1. Como usar o AWS Backup para fazer backup e restaurar sistemas de arquivos Amazon EFS
2. Backup de EFS para EFS

CLI da AWS

Há algumas opções para criar sistemas de arquivos EFS compatíveis usando a CLI:

1. Crie um EFS com backup automático ativado (padrão para armazenamento de uma zona e condicional para disponibilidade de backup na região da AWS)
2. Criar um EFS e definir uma política de backup

No entanto, supondo que a correção precise acontecer no EFS atual, a melhor opção é criar uma política de backup e associá-la ao EFS não compatível. Você vai precisar de um comando para cada EFS na sua infraestrutura.

arr=( $(aws efs describe-file-systems | jq -r '.FileSystems[].FileSystemId') )
for efs in "${arr[@]}"
do
  aws efs put-backup-policy \
  --file-system-id "${efs}" \
  --backup-policy "Status=ENABLED"
done

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Elb Acm Certificate Required

Nome da categoria na API: ELB_ACM_CERTIFICATE_REQUIRED

Verifica se o balanceador de carga clássico usa certificados HTTPS/SSL fornecidos pelo AWS Certificate Manager (ACM). O controle falha se o balanceador de carga clássico configurado com o listener HTTPS/SSL não usar um certificado fornecido pelo ACM.

Para criar um certificado, use o ACM ou uma ferramenta compatível com os protocolos SSL e TLS, como o OpenSSL. O Security Hub recomenda usar o ACM para criar ou importar certificados para o balanceador de carga.

O ACM se integra aos balanceadores de carga clássicos para que você possa implantar o certificado no balanceador. Você também precisa renovar esses certificados automaticamente.

Recomendação: verifica se todos os balanceadores de carga clássicos usam os certificados SSL fornecidos pelo AWS Certificate Manager

Para informações sobre como associar um certificado SSL/TLS do ACM a um balanceador de carga clássico, consulte o artigo da Central de Conhecimentos da AWS Como posso associar um certificado SSL/TLS do ACM a um balanceador de carga clássico, de aplicativo ou de rede?

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Elb Deletion Protection Enabled

Nome da categoria na API: ELB_DELETION_PROTECTION_ENABLED

Verifica se um balanceador de carga de aplicativo tem a proteção contra exclusão ativada. O controle falha se a proteção contra exclusão não estiver configurada.

Ative a proteção contra exclusão para proteger o Application Load Balancer contra exclusão.

Recomendação: a proteção contra exclusões do balanceador de carga de aplicativo precisa ser ativada

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

Para evitar que o balanceador de carga seja excluído acidentalmente, ative a proteção contra exclusão. Por padrão, a proteção contra exclusão está desativada no balanceador de carga.

Se você ativar a proteção contra exclusão para o balanceador de carga, será necessário desativar essa proteção antes de excluir o balanceador.

Para ativar a proteção contra exclusão no console.

1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.
2. No painel de navegação, em BALANCEAMENTO DE CARGA, escolha Balanceadores de carga.
3. Escolha o balanceador de carga.
4. Na guia Descrição, escolha Editar atributos.
5. Na página Editar atributos do balanceador de carga, selecione Ativar para proteção contra exclusão e escolha Salvar.
6. Escolha Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Elb Logging Enabled

Nome da categoria na API: ELB_LOGGING_ENABLED

Isso verifica se o balanceador de carga de aplicativo e o balanceador de carga clássico têm a geração de registros ativada. O controle falha se access_logs.s3.enabled for falso.

O Elastic Load Balancing fornece registros de acesso que capturam informações detalhadas sobre as solicitações enviadas ao balanceador de carga. Cada registro contém informações como o horário em que a solicitação foi recebida, o endereço IP do cliente, latências, caminhos de solicitação e respostas do servidor. É possível usar esses registros de acesso para analisar padrões de tráfego e resolver problemas.

Para saber mais, consulte Acesso aos registros do balanceador de carga clássico no guia do usuário para balanceadores de carga clássicos.

Recomendação: verifique se os balanceadores de carga de aplicativo e clássicos estão com a geração de registros ativada

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

Para resolver esse problema, atualize os balanceadores de carga para ativar a geração de registros.

Para ativar os registros de acesso

1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.
2. No painel de navegação, escolha Balanceadores de carga.
3. Escolha um balanceador de carga de aplicativo ou um balanceador de carga clássico.
4. Em Ações, escolha Editar atributos.
5. Em Registros de acesso, escolha Ativar.
6. Insira seu local do S3. Esse local pode existir ou ser criado para você. Se você não especificar um prefixo, os registros de acesso serão armazenados na raiz do bucket do S3.
7. Escolha Salvar.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Elb Tls Https Listeners Only

Nome da categoria na API: ELB_TLS_HTTPS_LISTENERS_ONLY

Essa verificação garante que todos os balanceadores de carga clássicos estejam configurados para usar comunicação segura.

Um listener é um processo que verifica solicitações de conexão. Ele é configurado com um protocolo e uma porta para conexões front-end (cliente para balanceador de carga) e um protocolo e uma porta para conexões back-end (balanceador de carga para instância). Para informações sobre as portas, os protocolos e as configurações de listener compatíveis com o Elastic Load Balancing, consulte Listeners para o balanceador de carga clássico.

Recomendação: verifica se todos os balanceadores de carga clássicos estão configurados com listeners SSL ou HTTPS

Para configurar o SSL ou o TLS para balanceadores de carga clássicos, consulte Criar um balanceador de carga HTTPS/SSL usando o AWS Management Console.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Encrypted Volumes

Nome da categoria na API: ENCRYPTED_VOLUMES

Verifica se os volumes EBS que estão em um estado anexado estão criptografados. Para passar nessa verificação, os volumes EBS precisam estar em uso e criptografados. Se o volume do EBS não estiver anexado, ele não estará sujeito a essa verificação.

Para adicionar uma camada extra de segurança aos seus dados confidenciais em volumes do EBS, ative a criptografia de dados em repouso do EBS. A criptografia do Amazon EBS oferece uma solução simples para seus recursos do EBS que não exige que você crie, mantenha e proteja sua própria infraestrutura de gerenciamento de chaves. Ele usa chaves do KMS ao criar volumes e snapshots criptografados.

Para saber mais sobre a criptografia do Amazon EBS, consulte Criptografia do Amazon EBS no Guia do usuário do Amazon EC2 para instâncias Linux.

Recomendação: os volumes anexados do Amazon EBS precisam estar criptografados em repouso

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

Não há uma maneira direta de criptografar um volume ou snapshot não criptografado. Só é possível criptografar um novo volume ou snapshot quando ele é criado.

Se você tiver ativado a criptografia por padrão, o Amazon EBS vai criptografar o novo volume ou snapshot resultante usando sua chave padrão para a criptografia do Amazon EBS. Mesmo que você não tenha ativado a criptografia por padrão, é possível ativá-la ao criar um volume ou snapshot individual. Em ambos os casos, é possível substituir a chave padrão para criptografia do Amazon EBS e escolher uma chave simétrica gerenciada pelo cliente.

Para mais informações, consulte Criar um volume do Amazon EBS e Copiar um snapshot do Amazon EBS no Guia do usuário do Amazon EC2 para instâncias do Linux.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Encryption At Rest Enabled Rds Instances

Nome da categoria na API: ENCRYPTION_AT_REST_ENABLED_RDS_INSTANCES

As instâncias de DB criptografadas do Amazon RDS usam o algoritmo de criptografia AES-256 padrão do setor para criptografar seus dados no servidor que hospeda as instâncias de DB do Amazon RDS. Depois que os dados são criptografados, o Amazon RDS processa a autenticação de acesso e a descriptografia dos dados de forma transparente, com um impacto mínimo no desempenho.

Recomendação: verifique se a criptografia em repouso está ativada para as instâncias do RDS

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

1. Faça login no console de gerenciamento da AWS e abra o painel do RDS em https://console.aws.amazon.com/rds/.
2. No painel de navegação à esquerda, clique em Databases.
3. Selecione a instância do banco de dados que precisa ser criptografada.
4. Clique no botão Actions no canto superior direito e selecione Take Snapshot.
5. Na página "Fazer snapshot", insira o nome de um banco de dados para o qual você quer fazer um snapshot no campo Snapshot Name e clique em Take Snapshot.
6. Selecione o snapshot recém-criado e clique no botão Action no canto superior direito e selecione Copy snapshot no menu "Ação".
7. Na página "Fazer cópia do snapshot do banco de dados", faça o seguinte:

• No campo Novo identificador de snapshot do banco de dados, insira um nome para o new snapshot.
• Verifique Copy Tags, o novo snapshot precisa ter as mesmas tags que o snapshot de origem.
• Selecione Yes na lista suspensa Enable Encryption para ativar a criptografia. Você pode usar a chave de criptografia padrão da AWS ou a chave personalizada na lista suspensa "Chave mestra".

8. Clique em Copy Snapshot para criar uma cópia criptografada do snapshot de instância selecionado.
9. Selecione a nova cópia criptografada do snapshot e clique no botão Action no canto superior direito. Em seguida, selecione o botão Restore Snapshot no menu "Ação". Isso vai restaurar o snapshot criptografado para uma nova instância do banco de dados.
10. Na página "Restaurar instância de banco de dados", insira um nome exclusivo para a nova instância de banco de dados no campo "Identificador da instância do banco de dados".
11. Revise os detalhes da configuração da instância e clique em Restore DB Instance.
12. Quando o processo de provisionamento da nova instância for concluído, será possível atualizar a configuração do aplicativo para se referir ao endpoint da nova instância de banco de dados criptografado. Quando o endpoint do banco de dados for alterado no nível do aplicativo, será possível remover a instância não criptografada.

CLI da AWS

1. Execute o comando describe-db-instances para listar todos os nomes de banco de dados do RDS disponíveis na região da AWS selecionada. A resposta ao comando vai retornar o identificador da instância do banco de dados.

aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'

2. Execute o comando create-db-snapshot para criar um snapshot da instância de banco de dados selecionada. A resposta ao comando vai retornar o new snapshot com o nome "DB Snapshot Name".

aws rds create-db-snapshot --region <region-name> --db-snapshot-identifier <DB-Snapshot-Name> --db-instance-identifier <DB-Name>

3. Agora, execute o comando list-aliases para listar os aliases de chaves do KMS disponíveis em uma região especificada. A resposta ao comando vai retornar cada key alias currently available. Para o processo de ativação da criptografia do RDS, localize o ID da chave KMS padrão da AWS.

aws kms list-aliases --region <region-name>

4. Execute o comando copy-db-snapshot usando o ID de chave KMS padrão para instâncias do RDS retornadas anteriormente para criar uma cópia criptografada do snapshot da instância do banco de dados. A resposta ao comando vai retornar o encrypted instance snapshot configuration.

aws rds copy-db-snapshot --region <region-name> --source-db-snapshot-identifier <DB-Snapshot-Name> --target-db-snapshot-identifier <DB-Snapshot-Name-Encrypted> --copy-tags --kms-key-id <KMS-ID-For-RDS>

5. Execute o comando restore-db-instance-from-db-snapshot para restaurar o snapshot criptografado criado na etapa anterior em uma nova instância de banco de dados. Se for bem-sucedido, a resposta ao comando vai retornar a nova configuração da instância de banco de dados criptografada.

aws rds restore-db-instance-from-db-snapshot --region <region-name> --db-instance-identifier <DB-Name-Encrypted> --db-snapshot-identifier <DB-Snapshot-Name-Encrypted>

6. Execute o comando describe-db-instances para listar todos os nomes de banco de dados do RDS disponíveis na região da AWS selecionada. A saída vai retornar o nome do identificador da instância do banco de dados. Selecione o nome do banco de dados criptografado que criamos, DB-Name-Encrypted.

aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'

7. Execute novamente o comando describe-db-instances usando o identificador de instância do RDS retornado anteriormente para determinar se a instância de banco de dados selecionada está criptografada. A resposta ao comando deve retornar o status de criptografia True.

aws rds describe-db-instances --region <region-name> --db-instance-identifier <DB-Name-Encrypted> --query 'DBInstances[*].StorageEncrypted'

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Encryption Enabled Efs File Systems

Nome da categoria na API: ENCRYPTION_ENABLED_EFS_FILE_SYSTEMS

Os dados do EFS precisam ser criptografados em repouso usando o AWS KMS (serviço de gerenciamento de chaves).

Recomendação: verifique se a criptografia está ativada nos sistemas de arquivos EFS

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

1. Faça login no console de gerenciamento da AWS e acesse o painel Elastic File System (EFS).
2. Selecione File Systems no painel de navegação à esquerda.
3. Clique no botão Create File System no menu superior do painel para iniciar o processo de configuração do sistema de arquivos.

4. Na página de configuração Configure file system access, realize as seguintes ações.
   - Escolha a VPC certa na lista suspensa.
   - Na seção "Criar destinos de montagem", marque as caixas de seleção de todas as Zonas de Disponibilidade (AZs) na VPC selecionada. Esses serão os destinos de montagem.
   - Clique em Next step para continuar.

5. Siga estas etapas na página Configure optional settings.
   - Crie tags para descrever o novo sistema de arquivos.
   - Escolha performance mode com base nos seus requisitos.
   - Marque a caixa de seleção Enable encryption e escolha aws/elasticfilesystem na lista suspensa "Selecionar chave mestra do KMS" para ativar a criptografia do novo sistema de arquivos usando a chave mestra padrão fornecida e gerenciada pelo AWS KMS.
   - Clique em Next step para continuar.

6. Revise os detalhes de configuração do sistema de arquivos na página review and create e clique em Create File System para criar um novo sistema de arquivos EFS da AWS.

7. Copie os dados do antigo sistema de arquivos EFS não criptografado para o novo sistema de arquivos criptografado.
8. Remova o sistema de arquivos não criptografado assim que a migração de dados para o sistema de arquivos criptografado recém-criado for concluída.
9. Mude a região da AWS na barra de navegação e repita o processo para outras regiões da AWS.

Na CLI:
1. Execute o comando "describe-file-systems" para descrever as informações de configuração disponíveis para o sistema de arquivos selecionado (não criptografado). Consulte a seção "Auditoria" para identificar o recurso correto:

aws efs describe-file-systems --region <region> --file-system-id <file-system-id from audit section step 2 output>

2. A resposta ao comando deve retornar as informações de configuração solicitadas.
3. Para provisionar um novo sistema de arquivos EFS da AWS, é necessário gerar um identificador universalmente exclusivo (UUID) para criar o token exigido pelo comando create-file-system. Para criar o token necessário, use um UUID gerado aleatoriamente em "https://www.uuidgenerator.net".
4. Execute o comando "create-file-system" usando o token exclusivo criado na etapa anterior.

aws efs create-file-system --region <region> --creation-token <Token (randomly generated UUID from step 3)> --performance-mode generalPurpose --encrypted

5. A resposta ao comando deve retornar os metadados de configuração do novo sistema de arquivos.
6. Execute o comando create-mount-target usando o ID do sistema de arquivos EFS recém-criado retornado na etapa anterior como identificador e o ID da zona de disponibilidade (AZ) que vai representar o destino de montagem:

aws efs create-mount-target --region <region> --file-system-id <file-system-id> --subnet-id <subnet-id>

7. A resposta ao comando vai retornar os metadados do novo destino de montagem.
8. Agora você pode montar seu sistema de arquivos em uma instância do EC2.
9. Copie os dados do antigo sistema de arquivos EFS não criptografado para o novo sistema de arquivos criptografado.
10. Remova o sistema de arquivos não criptografado assim que a migração de dados para o sistema de arquivos criptografado recém-criado for concluída.

aws efs delete-file-system --region <region> --file-system-id <unencrypted-file-system-id>

11. Para mudar a região da AWS, atualize o --region e repita o processo para outras regiões da AWS.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Iam Password Policy

Nome da categoria na API: IAM_PASSWORD_POLICY

A AWS permite políticas de senha personalizadas na sua conta para especificar requisitos de complexidade e períodos de rotação obrigatórios para as senhas dos usuários do IAM. Se você não definir uma política de senha personalizada, as senhas dos usuários do IAM precisarão atender à política de senha padrão da AWS. As práticas recomendadas de segurança da AWS recomendam os seguintes requisitos de complexidade de senha:

• Exija pelo menos um caractere maiúsculo na senha.
• Exija pelo menos um caractere minúsculo nas senhas.
• Exija pelo menos um símbolo nas senhas.
• Exija pelo menos um número nas senhas.
• Exija um comprimento mínimo de senha de pelo menos 14 caracteres.
• Exija pelo menos 24 senhas antes de permitir a reutilização.
• Exigir pelo menos 90 dias antes da expiração da senha

Esse controle verifica todos os requisitos especificados da política de senhas.

Recomendação: verifique se a política de senha da conta para usuários do IAM atende aos requisitos especificados

Para corrigir essa descoberta, siga estas etapas:

Terraform

resource "aws_iam_account_password_policy" "strict" {
  allow_users_to_change_password = true
  require_uppercase_characters   = true
  require_lowercase_characters   = true
  require_symbols                = true
  require_numbers                = true
  minimum_password_length        = 14
  password_reuse_prevention      = 24
  max_password_age               = 90
}

Console da AWS

Para criar uma política de senha personalizada

1. Faça login no console de gerenciamento do AWS e abra o console do IAM em https://console.aws.amazon.com/iam/.
2. No painel de navegação, escolha "Configurações da conta".
3. Na seção "Política de senha", escolha "Mudar política de senha".
4. Selecione as opções que você quer aplicar à sua política de senhas e escolha "Salvar alterações".

Para mudar uma política de senha personalizada

1. Faça login no console de gerenciamento do AWS e abra o console do IAM em https://console.aws.amazon.com/iam/.
2. No painel de navegação, escolha "Configurações da conta".
3. Na seção "Política de senha", escolha "Mudar".
4. Selecione as opções que você quer aplicar à sua política de senhas e escolha "Salvar alterações".

CLI da AWS

aws iam update-account-password-policy \
--allow-users-to-change-password \
--require-uppercase-characters \
--require-lowercase-characters \
--require-symbols \
--require-numbers \
--minimum-password-length 14 \
--password-reuse-prevention 24 \
--max-password-age 90

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Iam Password Policy Prevents Password Reuse

Nome da categoria na API: IAM_PASSWORD_POLICY_PREVENTS_PASSWORD_REUSE

As políticas de senha do IAM podem impedir que o mesmo usuário reutilize uma senha. Recomendamos que a política de senha impeça a reutilização de senhas.

Recomendação: verifique se a política de senha do IAM impede a reutilização de senhas

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

1. Faça login no AWS Console (com as permissões adequadas para visualizar as configurações da conta do Identity and Access Management).
2. Acesse o serviço IAM no console da AWS.
3. Clique em "Configurações da conta" no painel à esquerda.
4. Marque a opção "Impedir a reutilização da senha"
5. "Número de senhas a serem lembradas" está definido como 24

CLI da AWS

 aws iam update-account-password-policy --password-reuse-prevention 24

Observação: todos os comandos que começam com "aws iam update-account-password-policy" podem ser combinados em um único comando.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Iam Password Policy Requires Minimum Length 14 Greater

Nome da categoria na API: IAM_PASSWORD_POLICY_REQUIRES_MINIMUM_LENGTH_14_GREATER

As políticas de senha são usadas em parte para aplicar requisitos de complexidade de senha. As políticas de senha do IAM podem ser usadas para garantir que as senhas tenham pelo menos um determinado comprimento. É recomendável que a política de senha exija um comprimento mínimo de 14.

Recomendação: verifique se a política de senha do IAM exige um tamanho mínimo de 14 caracteres ou mais

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

1. Faça login no AWS Console (com as permissões adequadas para visualizar as configurações da conta do Identity and Access Management).
2. Acesse o serviço IAM no console da AWS.
3. Clique em "Configurações da conta" no painel à esquerda.
4. Defina "Tamanho mínimo da senha" como 14 ou mais.
5. Clique em "Aplicar política de senha".

CLI da AWS

 aws iam update-account-password-policy --minimum-password-length 14

Observação: todos os comandos que começam com "aws iam update-account-password-policy" podem ser combinados em um único comando.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Iam Policies Allow Full Administrative Privileges Attached

Nome da categoria na API: IAM_POLICIES_ALLOW_FULL_ADMINISTRATIVE_PRIVILEGES_ATTACHED

As políticas do IAM são o meio pelo qual os privilégios são concedidos a usuários, grupos ou funções. É recomendado e considerado um conselho de segurança padrão conceder o privilégio mínimo, ou seja, conceder apenas as permissões necessárias para realizar uma tarefa. Determine o que os usuários precisam fazer e crie políticas para que eles somente realizem essas tarefas, em vez de permitir privilégios administrativos completos.

Recomendação: verifique se as políticas do IAM que permitem privilégios de administrador "*:*" completos não estão anexadas

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

Siga estas etapas para desconectar a política que tem privilégios administrativos totais:

1. Faça login no console de gerenciamento da AWS e abra o console do IAM em https://console.aws.amazon.com/iam/.
2. No painel de navegação, clique em Políticas e pesquise o nome da política encontrado na etapa de auditoria.
3. Selecione a política que precisa ser excluída.
4. No menu de ação da política, selecione primeiro Detach
5. Selecionar todos os usuários, grupos e funções que têm esta política anexada
6. Clique em Detach Policy.
7. No menu de ação da política, selecione Detach.

CLI da AWS

Siga estas etapas para desconectar a política que tem privilégios administrativos totais, conforme encontrado na etapa de auditoria:

1. Lista todos os usuários, grupos e papéis do IAM aos quais a política gerenciada especificada está anexada.

 aws iam list-entities-for-policy --policy-arn <policy_arn>

2. Desanexe a política de todos os usuários do IAM:

 aws iam detach-user-policy --user-name <iam_user> --policy-arn <policy_arn>

3. Desanexe a política de todos os grupos do IAM:

 aws iam detach-group-policy --group-name <iam_group> --policy-arn <policy_arn>

4. Desanexe a política de todos os papéis do IAM:

 aws iam detach-role-policy --role-name <iam_role> --policy-arn <policy_arn>

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Iam Users Receive Permissions Groups

Nome da categoria na API: IAM_USERS_RECEIVE_PERMISSIONS_GROUPS

Os usuários do IAM recebem acesso a serviços, funções e dados por meio das políticas do IAM. Há quatro maneiras de definir políticas para um usuário: 1) editar a política do usuário diretamente, também conhecida como política inline ou do usuário; 2) anexar uma política diretamente a um usuário; 3) adicionar o usuário a um grupo do IAM com uma política anexada; 4) adicionar o usuário a um grupo do IAM com uma política inline.

Só a terceira implementação é recomendada.

Recomendação: verifique se os usuários do IAM recebem permissões somente pelos grupos

Siga estas etapas para criar um grupo do IAM e atribuir uma política a ele:

1. Faça login no console de gerenciamento da AWS e abra o console do IAM em https://console.aws.amazon.com/iam/.
2. No painel de navegação, clique em Groups e em Create New Group .
3. Na caixa Group Name, digite o nome do grupo e clique em Next Step .
4. Na lista de políticas, marque a caixa de seleção de cada política que você quer aplicar a todos os membros do grupo. Em seguida, clique em Next Step .
5. Clique em Create Group.

Siga estas etapas para adicionar um usuário a um grupo:

1. Faça login no console de gerenciamento da AWS e abra o console do IAM em https://console.aws.amazon.com/iam/.
2. No painel de navegação, clique em Groups.
3. Selecionar o grupo para adicionar um usuário
4. Clique em Add Users To Group.
5. Selecione os usuários que serão adicionados ao grupo
6. Clique em Add Users.

Siga estas etapas para remover uma associação direta entre um usuário e uma política:

1. Faça login no console de gerenciamento da AWS e abra o console do IAM em https://console.aws.amazon.com/iam/.
2. No painel de navegação à esquerda, clique em "Usuários".
3. Para cada usuário:
   - Selecione o usuário
   - Clique na guia Permissions
   - Expanda Permissions policies
   - Clique em X para cada política e, em seguida, em "Detach" ou "Remover" (dependendo do tipo de política).

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Iam User Group Membership Check

Nome da categoria na API: IAM_USER_GROUP_MEMBERSHIP_CHECK

Os usuários do IAM precisam fazer parte de um grupo do IAM para aderir às práticas recomendadas de segurança do IAM.

Ao adicionar usuários a um grupo, é possível compartilhar políticas entre tipos de usuários.

Recomendação: verifica se os usuários do IAM são membros de pelo menos um grupo do IAM

Para corrigir essa descoberta, siga estas etapas:

Terraform

resource "aws_iam_user" "example" {
  name = "test-iam-user"
  path = "/users/dev/"
}

resource "aws_iam_group" "example" {
  name = "Developers"
  path = "/users/dev/"
}

resource "aws_iam_user_group_membership" "example" {
  user   = aws_iam_user.example.name
  groups = [aws_iam_group.example.name]
}

Console da AWS

Quando você usa o AWS Management Console para excluir um usuário do IAM, o IAM exclui automaticamente as seguintes informações:

1. O usuário
2. Todos os grupos de usuários aos quais o usuário pertencia.
3. Qualquer senha associada ao usuário
4. Todas as chaves de acesso pertencentes ao usuário
5. Todas as políticas inline incorporadas ao usuário (as políticas aplicadas a um usuário pelas permissões do grupo de usuários não são afetadas)

Para excluir um usuário do IAM:

1. Faça login no console de gerenciamento do AWS e abra o console do IAM em https://console.aws.amazon.com/iam/.
2. No painel de navegação, escolha "Usuários" e marque a caixa de seleção ao lado do nome do usuário que você quer excluir.
3. Na parte de cima da página, escolha "Excluir".
4. Na caixa de diálogo de confirmação, insira o nome de usuário no campo de entrada de texto para confirmar a exclusão do usuário.
5. Escolha "Excluir".

Para adicionar um usuário a um grupo de usuários do IAM:

1. Faça login no console de gerenciamento do AWS e abra o console do IAM em https://console.aws.amazon.com/iam/.
2. No painel de navegação, escolha "Grupos de usuários" e o nome do grupo.
3. Escolha a guia "Usuários" e clique em "Adicionar usuários". Marque a caixa de seleção ao lado dos usuários que você quer adicionar.
4. Escolha "Adicionar usuários".

CLI da AWS

Ao contrário do Amazon Web Services Management Console, quando você exclui um usuário de maneira programática, é necessário excluir os itens anexados ao usuário manualmente. Caso contrário, a exclusão falha.

Antes de tentar excluir um usuário, remova os seguintes itens:

1. Senha ( DeleteLoginProfile )
2. Chaves de acesso ( DeleteAccessKey )
3. Certificado de assinatura ( DeleteSigningCertificate )
4. Chave pública SSH ( DeleteSSHPublicKey )
5. Credenciais do Git ( DeleteServiceSpecificCredential )
6. Dispositivo de autenticação multifator (MFA) ( DeactivateMFADevice , DeleteVirtualMFADevice )
7. Políticas inline ( DeleteUserPolicy )
8. Políticas gerenciadas anexadas ( DetachUserPolicy )
9. Associações a grupos ( RemoveUserFromGroup )

Para excluir um usuário, depois de excluir todos os itens associados a ele:

aws iam delete-user \
  --user-name "test-user"

Para adicionar um usuário do IAM a um grupo do IAM:

aws iam add-user-to-group \
  --group-name "test-group"
  --user-name "test-user"

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Iam User Mfa Enabled

Nome da categoria na API: IAM_USER_MFA_ENABLED

A autenticação multifator (MFA) é uma prática recomendada que adiciona uma camada extra de proteção aos nomes de usuário e senhas. Com a MFA, quando um usuário faz login no console de gerenciamento da AWS, ele precisa fornecer um código de autenticação com limite de tempo, fornecido por um dispositivo virtual ou físico registrado.

Recomendação: verifica se a autenticação multifator (MFA) está ativada para os usuários do AWS IAM

Para corrigir essa descoberta, siga estas etapas:

Terraform

No Terraform, há algumas opções para corrigir a ausência de dispositivos MFA. Você provavelmente já tem uma estrutura razoável para organizar seus usuários em grupos e políticas restritivas.

O exemplo a seguir mostra como:

1. Crie usuários.
2. Crie perfis de login de usuários com uma chave pública PGP.
3. Crie um grupo e uma política de grupo que permita o autogerenciamento do perfil do IAM.
4. Anexe usuários ao grupo.
5. Crie dispositivos de MFA virtual para os usuários.
6. Forneça o código QR e a senha de saída para cada usuário.

variable "users" {
  type = set(string)
  default = [
    "[e-mail]",
    "[e-mail]"
  ]
}

resource "aws_iam_user" "test_users" {
  for_each = toset(var.users)
  name     = each.key
}

resource "aws_iam_user_login_profile" "test_users_profile" {
  for_each                = var.users
  user                    = each.key
  # Key pair created using GnuPG, this is the public key
  pgp_key = file("path/to/gpg_pub_key_base64.pem")
  password_reset_required = true
  lifecycle {
    ignore_changes = [
      password_length,
      password_reset_required,
      pgp_key,
    ]
  }
}

resource "aws_iam_virtual_mfa_device" "test_mfa" {
  for_each                = toset(var.users)
  virtual_mfa_device_name = each.key
}

resource "aws_iam_group" "enforce_mfa_group" {
  name = "EnforceMFAGroup"
}

resource "aws_iam_group_membership" "enforce_mfa_group_membership" {
  name  = "EnforceMFAGroupMembership"
  group = aws_iam_group.enforce_mfa_group.name
  users = [for k in aws_iam_user.test_users : k.name]
}

resource "aws_iam_group_policy" "enforce_mfa_policy" {
  name   = "EnforceMFAGroupPolicy"
  group  = aws_iam_group.enforce_mfa_group.id
  policy = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
        "Sid": "AllowViewAccountInfo",
        "Effect": "Allow",
        "Action": [
            "iam:GetAccountPasswordPolicy",
            "iam:ListVirtualMFADevices"
        ],
        "Resource": "*"
    },
    {
        "Sid": "AllowManageOwnPasswords",
        "Effect": "Allow",
        "Action": [
            "iam:ChangePassword",
            "iam:GetUser"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnAccessKeys",
        "Effect": "Allow",
        "Action": [
            "iam:CreateAccessKey",
            "iam:DeleteAccessKey",
            "iam:ListAccessKeys",
            "iam:UpdateAccessKey"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnSigningCertificates",
        "Effect": "Allow",
        "Action": [
            "iam:DeleteSigningCertificate",
            "iam:ListSigningCertificates",
            "iam:UpdateSigningCertificate",
            "iam:UploadSigningCertificate"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnSSHPublicKeys",
        "Effect": "Allow",
        "Action": [
            "iam:DeleteSSHPublicKey",
            "iam:GetSSHPublicKey",
            "iam:ListSSHPublicKeys",
            "iam:UpdateSSHPublicKey",
            "iam:UploadSSHPublicKey"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnGitCredentials",
        "Effect": "Allow",
        "Action": [
            "iam:CreateServiceSpecificCredential",
            "iam:DeleteServiceSpecificCredential",
            "iam:ListServiceSpecificCredentials",
            "iam:ResetServiceSpecificCredential",
            "iam:UpdateServiceSpecificCredential"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnVirtualMFADevice",
        "Effect": "Allow",
        "Action": [
            "iam:CreateVirtualMFADevice",
            "iam:DeleteVirtualMFADevice"
        ],
        "Resource": "arn:aws:iam::*:mfa/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnUserMFA",
        "Effect": "Allow",
        "Action": [
            "iam:DeactivateMFADevice",
            "iam:EnableMFADevice",
            "iam:ListMFADevices",
            "iam:ResyncMFADevice"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "DenyAllExceptListedIfNoMFA",
        "Effect": "Deny",
        "NotAction": [
            "iam:CreateVirtualMFADevice",
            "iam:EnableMFADevice",
            "iam:GetUser",
            "iam:ListMFADevices",
            "iam:ListVirtualMFADevices",
            "iam:ResyncMFADevice",
            "sts:GetSessionToken"
        ],
        "Resource": "*",
        "Condition": {
            "BoolIfExists": {
                "aws:MultiFactorAuthPresent": "false"
            }
        }
    }
  ]
}
POLICY
}

output "user_password_map" {
  # Outputs a map in the format {"[e-mail]": <PGPEncryptedPassword>, "[e-mail]": <PGPEncryptedPassword>}
  value = { for k, v in aws_iam_user_login_profile.test_users_profile : k => v.password }
}

output "user_qr_map" {
  # Outputs a map in the format {"[e-mail]": <QRCode>, "[e-mail]": <QRCode>}
  value = { for k, v in aws_iam_virtual_mfa_device.test_mfa : k => v.qr_code_png }
}

Console da AWS

Para ativar a MFA em qualquer conta de usuário com acesso ao console da AWS, consulte Ativar um dispositivo virtual de autenticação multifator (MFA) (console) na documentação da AWS.

CLI da AWS

Criar um dispositivo de MFA

aws iam create-virtual-mfa-device \
  --virtual-mfa-device-name "[e-mail]" \
  --outfile ./QRCode.png \
  --bootstrap-method QRCodePNG

Ativar o dispositivo de MFA para um usuário

aws iam enable-mfa-device \
  --user-name "[e-mail]" \
  --serial-number "arn:aws:iam::123456976749:mfa/[e-mail]" \
  --authentication-code1 123456 \
  --authentication-code2 654321

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Iam User Unused Credentials Check

Nome da categoria na API: IAM_USER_UNUSED_CREDENTIALS_CHECK

Isso verifica se há senhas do IAM ou chaves de acesso ativas que não foram usadas nos últimos 90 dias.

As práticas recomendadas recomendam que você remova, desative ou faça a rotação de todas as credenciais que não foram usadas por 90 dias ou mais. Isso reduz a janela de oportunidade para que as credenciais associadas a uma conta comprometida ou abandonada sejam usadas.

Recomendação: verifica se todos os usuários do AWS IAM têm senhas ou chaves de acesso ativas que não tenham sido usadas em maxCredentialUsageAge dias (padrão 90)

Para corrigir essa descoberta, siga estas etapas:

Terraform

Para remover chaves de acesso vencidas criadas pelo Terraform, remova o recurso aws_iam_access_key do módulo e aplique a mudança.

Para redefinir a senha de login de um usuário do IAM, use -replace ao executar terraform apply.

Supondo o seguinte perfil de login do usuário

resource "aws_iam_user" "example" {
  name          = "[e-mail]"
  path          = "/users/"
  force_destroy = true
}

resource "aws_iam_user_login_profile" "example" {
  user    = aws_iam_user.example.name
  pgp_key = "keybase:some_person_that_exists"
}

Execute o comando a seguir para redefinir a senha do perfil de login do usuário.

terraform apply -replace="aws_iam_user_login_profile.example"

Console da AWS

Para desativar as credenciais de contas inativas:

1. Abra o console do IAM em https://console.aws.amazon.com/iam/.
2. Escolha "Usuários".
3. Escolha o nome do usuário que tem credenciais com mais de 90 dias/última vez usada.
4. Escolha Credenciais de segurança.
5. Para cada credencial de login e chave de acesso que não tenha sido usada há pelo menos 90 dias, escolha "Deixar inativo".

Para exigir uma nova senha dos usuários do console no próximo login:

1. Abra o console do IAM em https://console.aws.amazon.com/iam/.
2. Escolha "Usuários".
3. Escolha o nome do usuário que tem credenciais com mais de 90 dias/última vez usada.
4. Escolha Credenciais de segurança.
5. Em Credenciais de login e senha do console, escolha "Gerenciar".
6. Defina uma nova senha (gerada automaticamente ou personalizada).
7. Marque a caixa para exigir a redefinição de senha.
8. Selecione "Aplicar".

CLI da AWS

Para desativar as chaves de acesso

aws iam update-access-key \
  --access-key-id <value> \
  --status "Inactive"

Para excluir chaves de acesso

aws iam delete-access-key \
  --access-key-id <value>

Para redefinir a senha de um perfil de login de usuário

aws iam update-login-profile \
  --user-name "[e-mail]" \
  --password <temporary_password> \
  --password-reset-required

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Kms Cmk Not Scheduled For Deletion

Nome da categoria na API: KMS_CMK_NOT_SCHEDULED_FOR_DELETION

Esse controle verifica se as chaves do KMS estão programadas para exclusão. O controle falha se uma chave do KMS estiver programada para exclusão.

Não é possível recuperar chaves do KMS depois que elas são excluídas. Os dados criptografados com uma chave do KMS também não podem ser recuperados se a chave do KMS for excluída. Se dados importantes tiverem sido criptografados com uma chave do KMS programada para exclusão, descriptografe ou criptografe novamente com uma nova chave do KMS, a menos que você esteja realizando uma exclusão criptográfica intencionalmente.

Quando uma chave do KMS é programada para exclusão, um período de espera obrigatório é aplicado para permitir que a exclusão seja revertida, caso tenha sido programada por engano. O período de espera padrão é de 30 dias, mas pode ser reduzido para até 7 dias quando a chave do KMS é programada para exclusão. Durante o período de espera, a exclusão programada pode ser cancelada, e a chave do KMS não será excluída.

Para mais informações sobre a exclusão de chaves do KMS, consulte Excluir chaves do KMS no Guia do desenvolvedor do AWS Key Management Service.

Recomendação: verifica se todas as CMKs não estão programadas para exclusão

Para cancelar uma exclusão de chave do KMS programada, consulte Como cancelar a exclusão de chaves em "Programar e cancelar a exclusão de chaves (console)" no Guia do desenvolvedor do AWS Key Management Service.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Lambda Concurrency Check

Nome da categoria na API: LAMBDA_CONCURRENCY_CHECK

Verifica se a função do Lambda está configurada com um limite de execução simultânea no nível da função. A regra é NON_COMPLIANT se a função do Lambda não estiver configurada com um limite de execução simultânea no nível da função.

Recomendação: verifique se as funções do Lambda estão configuradas com limite de execução simultânea no nível da função

Para configurar um limite de execução simultânea no nível da função, consulte Como configurar a simultaneidade reservada na documentação do AWS Lambda.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Lambda Dlq Check

Nome da categoria na API: LAMBDA_DLQ_CHECK

Verifica se uma função do Lambda está configurada com uma fila de mensagens inativas. A regra é NON_COMPLIANT se a função Lambda não estiver configurada com uma fila de mensagens inativas.

Recomendação: verifique se as funções do Lambda estão configuradas com uma fila de mensagens inativas

Para atualizar as funções do Lambda para usar filas de mensagens inativas, consulte Filas de mensagens inativas na documentação da AWS.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Lambda Function Public Access Prohibited

Nome da categoria na API: LAMBDA_FUNCTION_PUBLIC_ACCESS_PROHIBITED

As práticas recomendadas da AWS recomendam que a função Lambda não seja exposta publicamente. Essa política verifica todas as funções do Lambda implantadas em todas as regiões ativadas na sua conta e falha se elas forem configuradas para permitir o acesso público.

Recomendação: verifica se a política anexada à função do Lambda proíbe o acesso público

Para corrigir essa descoberta, siga estas etapas:

Terraform

O exemplo a seguir mostra como usar o Terraform para provisionar um papel do IAM que restringe o acesso a uma função do Lambda e anexa essa função ao

resource "aws_iam_role" "iam_for_lambda" {
  name = "iam_for_lambda"

  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Effect": "Allow",
      "Sid": ""
    }
  ]
}
EOF
}

resource "aws_lambda_function" "test_lambda" {
  filename      = "lambda_function_payload.zip"
  function_name = "lambda_function_name"
  role          = aws_iam_role.iam_for_lambda.arn
  handler       = "index.test"

  source_code_hash = filebase64sha256("lambda_function_payload.zip")

  runtime = "nodejs12.x"

}

Console da AWS

Se uma função Lambda falhar nesse controle, isso indica que a declaração de política baseada em recursos para a função Lambda permite o acesso público.

Para corrigir o problema, atualize a política para remover as permissões ou adicionar a condição AWS:SourceAccount. Só é possível atualizar a política baseada em recursos pela API Lambda.

As instruções a seguir usam o console para analisar a política e a interface de linha de comando da AWS para remover as permissões.

Para conferir a política baseada em recursos de uma função Lambda

1. Abra o console da AWS Lambda em https://console.aws.amazon.com/lambda/.
2. No painel de navegação, escolha "Funções".
3. Escolha a função.
4. Escolha "Permissões". A política baseada em recursos mostra as permissões que são aplicadas quando outra conta ou serviço da AWS tenta acessar a função.
5. Analise a política baseada em recursos.
6. Identifique a declaração de política que tem valores de campo de principal que tornam a política pública. Por exemplo, permitir "*" ou { "AWS": "*" }.

Não é possível editar a política no console. Para remover permissões da função, use o comando remove-permission da AWS CLI.

Anote o valor do ID da instrução (Sid) que você quer remover.

CLI da AWS

Para usar a CLI para remover permissões de uma função do Lambda, emita o comando remove-permission da seguinte maneira.

aws lambda remove-permission \
--function-name <value> \
--statement-id <value>

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Lambda Inside Vpc

Nome da categoria na API: LAMBDA_INSIDE_VPC

Verifica se uma função do Lambda está em uma VPC. Talvez você encontre descobertas com falhas para recursos da Lambda@Edge.

Ele não avalia a configuração de roteamento da sub-rede da VPC para determinar a acessibilidade pública.

Recomendação: verifica se as funções do Lambda existem em uma VPC

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

Para configurar uma função para se conectar a sub-redes privadas em uma nuvem privada virtual (VPC) na sua conta:

1. Abra o console da AWS Lambda em https://console.aws.amazon.com/lambda/.
2. Acesse "Funções" e selecione sua função Lambda.
3. Role a tela até "Rede" e selecione uma VPC com os requisitos de conectividade da função.
4. Para executar as funções no modo de alta disponibilidade, o Security Hub recomenda escolher pelo menos duas sub-redes.
5. Escolha pelo menos um grupo de segurança que tenha os requisitos de conectividade da função.
6. Escolha "Salvar".

Para mais informações, consulte a seção sobre como configurar uma função do Lambda para acessar recursos em uma VPC no Guia para desenvolvedores do AWS Lambda.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Mfa Delete Enabled S3 Buckets

Nome da categoria na API: MFA_DELETE_ENABLED_S3_BUCKETS

Depois que a exclusão de MFA é ativada no bucket do S3 sensível e classificado, o usuário precisa ter duas formas de autenticação.

Recomendação: verifique se a exclusão de MFA está ativada nos buckets do S3

Siga as etapas abaixo para ativar a exclusão de MFA em um bucket do S3.

Observação:
- Não é possível ativar a exclusão de MFA usando o console de gerenciamento da AWS. Use a AWS CLI ou a API.
- Use sua conta "raiz" para ativar a exclusão de MFA nos buckets do S3.

Na linha de comando:

1. Execute o comando put-bucket-versioning do s3api.

aws s3api put-bucket-versioning --profile my-root-profile --bucket Bucket_Name --versioning-configuration Status=Enabled,MFADelete=Enabled --mfa “arn:aws:iam::aws_account_id:mfa/root-account-mfa-device passcode”

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Mfa Enabled Root User Account

Nome da categoria na API: MFA_ENABLED_ROOT_USER_ACCOUNT

A conta de usuário raiz é o usuário mais privilegiado em uma conta da AWS. A autenticação multifator (MFA) adiciona uma camada extra de proteção a um nome de usuário e uma senha. Com a MFA ativada, quando um usuário faz login em um site da AWS, ele precisa informar o nome de usuário e a senha, além de um código de autenticação do dispositivo da MFA da AWS.

Observação:quando a MFA virtual é usada para contas raiz, é recomendável que o dispositivo usado não seja pessoal, mas sim um dispositivo móvel dedicado (tablet ou smartphone) que seja mantido carregado e protegido independentemente de dispositivos pessoais individuais. (MFA virtual não pessoal) Isso diminui os riscos de perder o acesso ao MFA devido à perda ou troca do dispositivo ou se o indivíduo que possui o dispositivo não estiver mais empregado na empresa.

Recomendação: verifique se a MFA está ativada para a conta de usuário "raiz"

Siga estas etapas para estabelecer a MFA para a conta de usuário "raiz":

1. Faça login no console de gerenciamento da AWS e abra o console do IAM em https://console.aws.amazon.com/iam/.

Observação: para gerenciar dispositivos MFA para a conta raiz da AWS, use as credenciais da conta raiz para fazer login na AWS. Não é possível gerenciar dispositivos de MFA para a conta raiz usando outras credenciais.

2. Escolha Dashboard e , em Security Status , expanda Activate MFA na sua conta raiz.
3. Escolher Activate MFA
4. No assistente, escolha o dispositivo A virtual MFA e Next Step .
5. O IAM gera e exibe informações de configuração para o dispositivo de MFA virtual, incluindo um código QR gráfico. O gráfico é uma representação da "chave de configuração secreta" que está disponível para entrada manual em dispositivos que não oferecem suporte a códigos QR.
6. Abra o aplicativo de MFA virtual. Para conferir uma lista de apps que podem ser usados para hospedar dispositivos de MFA virtual, consulte Apps de MFA virtual. Se o aplicativo de MFA virtual oferecer suporte a várias contas (vários dispositivos de MFA virtual), escolha a opção para criar uma nova conta (um novo dispositivo de MFA virtual).
7. Determine se o app de MFA oferece suporte a códigos QR e faça uma das seguintes ações:

• Use o app para ler o código QR. Por exemplo, você pode escolher o ícone da câmera ou uma opção semelhante a "Ler código" e usar a câmera do dispositivo para ler o código.
• No assistente "Gerenciar dispositivo de MFA", escolha "Mostrar chave secreta para configuração manual" e digite a chave de configuração secreta no aplicativo de MFA.

Quando terminar, o dispositivo de MFA virtual vai começar a gerar senhas de uso único.

No assistente "Gerenciar dispositivo de MFA", na caixa "Código de autenticação 1", digite a senha única que aparece no dispositivo virtual de MFA. Aguarde até 30 segundos para que o dispositivo gere uma nova senha única. Em seguida, digite a segunda senha única na caixa "Código de autenticação 2". Escolha "Atribuir MFA virtual".

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Multi Factor Authentication Mfa Enabled All Iam Users Console

Nome da categoria na API: MULTI_FACTOR_AUTHENTICATION_MFA_ENABLED_ALL_IAM_USERS_CONSOLE

A autenticação multifator (MFA) adiciona uma camada extra de garantia de autenticação além das credenciais tradicionais. Quando a MFA está ativada, ao fazer login no AWS Console, o usuário precisa informar o nome de usuário e a senha, além de um código de autenticação do token de MFA físico ou virtual. É recomendável ativar a MFA para todas as contas que têm uma senha do console.

Recomendação: verifique se a autenticação multifator (MFA) está ativada para todos os usuários do IAM que têm uma senha do console

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

1. Faça login no console de gerenciamento da AWS e abra o console do IAM em "https://console.aws.amazon.com/iam/".
2. No painel à esquerda, selecione Users.
3. Na lista User Name, escolha o nome do usuário de MFA.
4. Selecione a guia Security Credentials e depois Manage MFA Device.
5. No Manage MFA Device wizard, escolha o dispositivo Virtual MFA e depois Continue.

O IAM gera e exibe informações de configuração para o dispositivo de MFA virtual, incluindo um código QR gráfico. O gráfico é uma representação da "chave de configuração secreta" que está disponível para entrada manual em dispositivos que não oferecem suporte a códigos QR.

6. Abra o aplicativo de MFA virtual. Para conferir uma lista de apps que podem ser usados para hospedar dispositivos de MFA virtual, consulte "Aplicativos de MFA virtual" em https://aws.amazon.com/iam/details/mfa/#Virtual_MFA_Applications. Se o aplicativo de MFA virtual oferecer suporte a várias contas (vários dispositivos de MFA virtual), escolha a opção para criar uma nova conta (um novo dispositivo de MFA virtual).
7. Determine se o app de MFA oferece suporte a códigos QR e faça uma das seguintes ações:

• Use o app para ler o código QR. Por exemplo, você pode escolher o ícone da câmera ou uma opção semelhante a "Ler código" e usar a câmera do dispositivo para ler o código.
• No assistente "Gerenciar dispositivo de MFA", escolha "Mostrar chave secreta para configuração manual" e digite a chave de configuração secreta no aplicativo de MFA.

Quando terminar, o dispositivo de MFA virtual vai começar a gerar senhas de uso único.

8. Na Manage MFA Device wizard, na MFA Code 1 box, digite o one-time password que aparece no dispositivo de MFA virtual. Aguarde até 30 segundos para que o dispositivo gere uma nova senha única. Em seguida, digite o segundo one-time password no MFA Code 2 box.

9. Clique em Assign MFA.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

No Network Acls Allow Ingress 0 0 0 0 Remote Server Administration

Nome da categoria na API: NO_NETWORK_ACLS_ALLOW_INGRESS_0_0_0_0_REMOTE_SERVER_ADMINISTRATION

A função de lista de controle de acesso à rede (NACL) fornece filtragem sem estado do tráfego de rede de entrada e saída para recursos da AWS. É recomendável que nenhuma NACL permita o acesso de entrada irrestrito a portas de administração de servidor remoto, como SSH para a porta 22 e RDP para a porta 3389, usando os protocolos TDP (6), UDP (17) ou ALL (-1).

Recomendação: verifique se nenhuma ACL de rede permite a entrada de 0.0.0.0/0 em portas de administração de servidor remoto

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

Faça o seguinte:
1. Faça login no console de gerenciamento da AWS em https://console.aws.amazon.com/vpc/home
2. No painel à esquerda, clique em Network ACLs
3. Para cada ACL de rede a ser remediada, faça o seguinte:
- Selecione a ACL de rede
- Clique na guia Inbound Rules
- Clique em Edit inbound rules
- A) Atualize o campo "Origem" para um intervalo diferente de 0.0.0.0/0 ou B) Clique em Delete para remover a regra de entrada incorreta
- Clique em Save

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

No Root User Account Access Key Exists

Nome da categoria na API: NO_ROOT_USER_ACCOUNT_ACCESS_KEY_EXISTS

A conta de usuário raiz é o usuário mais privilegiado em uma conta da AWS. As chaves de acesso da AWS fornecem acesso programático a uma determinada conta da AWS. É recomendável excluir todas as chaves de acesso associadas à conta de usuário "raiz".

Recomendação: verifique se não há uma chave de acesso da conta de usuário "raiz"

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

1. Faça login no console de gerenciamento da AWS como "root" e abra o console do IAM em https://console.aws.amazon.com/iam/.
2. Clique em <root_account> no canto superior direito e selecione My Security Credentials na lista suspensa.
3. Na tela pop-up, clique em Continue to Security Credentials.
4. Clique em Access Keys (ID da chave de acesso e chave de acesso secreta).
5. Na coluna Status (se houver chaves ativas).
6. Clique em Delete. Não é possível recuperar chaves excluídas.

Observação: embora uma chave possa ser inativada, ela ainda vai aparecer no comando da CLI do procedimento de auditoria e pode levar a uma chave ser sinalizada erroneamente como não em conformidade.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

No Security Groups Allow Ingress 0 0 0 0 Remote Server Administration

Nome da categoria na API: NO_SECURITY_GROUPS_ALLOW_INGRESS_0_0_0_0_REMOTE_SERVER_ADMINISTRATION

Os grupos de segurança fornecem filtragem stateful do tráfego de entrada e saída da rede para os recursos da AWS. É recomendável que nenhum grupo de segurança permita o acesso de entrada irrestrito a portas de administração remotas do servidor, como SSH para a porta 22 e RDP para a porta 3389, usando os protocolos TDP (6), UDP (17) ou ALL (-1).

Recomendação: verifique se nenhum grupo de segurança permite a entrada de 0.0.0.0/0 para portas de administração do servidor remoto

Siga estas etapas para implementar o estado prescrito:

1. Faça login no console de gerenciamento da AWS em https://console.aws.amazon.com/vpc/home.
2. No painel à esquerda, clique em Security Groups
3. Para cada grupo de segurança, faça o seguinte:
4. Selecione o grupo de segurança
5. Clique na guia Inbound Rules.
6. Clique no botão Edit inbound rules.
7. Identificar as regras que serão editadas ou removidas
8. A) Atualize o campo "Origem" para um intervalo diferente de 0.0.0.0/0 ou B) clique em Delete para remover a regra de entrada incorreta.
9. Clique em Save rules.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

No Security Groups Allow Ingress 0 Remote Server Administration

Nome da categoria na API: NO_SECURITY_GROUPS_ALLOW_INGRESS_0_REMOTE_SERVER_ADMINISTRATION

Os grupos de segurança fornecem filtragem stateful do tráfego de entrada e saída da rede para os recursos da AWS. É recomendável que nenhum grupo de segurança permita o acesso de entrada irrestrito a portas de administração remotas do servidor, como SSH para a porta 22 e RDP para a porta 3389.

Recomendação: verifique se nenhum grupo de segurança permite a entrada de ::/0 para as portas de administração do servidor remoto

Siga estas etapas para implementar o estado prescrito:

1. Faça login no console de gerenciamento da AWS em https://console.aws.amazon.com/vpc/home.
2. No painel à esquerda, clique em Security Groups
3. Para cada grupo de segurança, faça o seguinte:
4. Selecione o grupo de segurança
5. Clique na guia Inbound Rules.
6. Clique no botão Edit inbound rules.
7. Identificar as regras que serão editadas ou removidas
8. A) Atualize o campo "Origem" para um intervalo diferente de ::/0 ou B) clique em Delete para remover a regra de entrada incorreta.
9. Clique em Save rules.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

One Active Access Key Available Any Single Iam User

Nome da categoria na API: ONE_ACTIVE_ACCESS_KEY_AVAILABLE_ANY_SINGLE_IAM_USER

As chaves de acesso são credenciais de longo prazo para um usuário do IAM ou o usuário raiz da conta da AWS. É possível usar chaves de acesso para assinar solicitações programáticas para a AWS CLI ou a API AWS (diretamente ou usando o AWS SDK).

Recomendação: verifique se há apenas uma chave de acesso ativa disponível para cada usuário do IAM

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

1. Faça login no console de gerenciamento da AWS e acesse o painel do IAM em https://console.aws.amazon.com/iam/.
2. No painel de navegação à esquerda, escolha Users.
3. Clique no nome do usuário do IAM que você quer examinar.
4. Na página de configuração do usuário do IAM, selecione a guia Security Credentials.
5. Na seção Access Keys, escolha uma chave de acesso com menos de 90 dias. Essa é a única chave ativa usada pelo usuário do IAM para acessar os recursos da AWS de forma programática. Teste seus aplicativos para garantir que a chave de acesso escolhida esteja funcionando.
6. Na mesma seção Access Keys, identifique as chaves de acesso não operacionais (exceto a escolhida) e desative clicando no link Make Inactive.
7. Se você receber a caixa de confirmação Change Key Status, clique em Deactivate para desativar a chave selecionada.
8. Repita as etapas 3 a 7 para cada usuário do IAM na sua conta da AWS.

CLI da AWS

1. Usando as informações da chave de acesso e do usuário do IAM fornecidas no Audit CLI, escolha uma chave de acesso com menos de 90 dias. Essa é a única chave ativa usada pelo usuário do IAM para acessar os recursos da AWS de forma programática. Teste seus aplicativos para garantir que a chave de acesso escolhida esteja funcionando.

2. Execute o comando update-access-key abaixo usando o nome de usuário do IAM e os IDs de chaves de acesso não operacionais para desativar as chaves desnecessárias. Consulte a seção "Auditoria" para identificar o ID da chave de acesso desnecessária para o usuário do IAM selecionado.

Observação: o comando não retorna nenhuma saída:

aws iam update-access-key --access-key-id <access-key-id> --status Inactive --user-name <user-name>

3. Para confirmar que a chave de acesso selecionada foi deactivated, execute o comando de auditoria list-access-keys novamente para esse usuário do IAM:

aws iam list-access-keys --user-name <user-name>

• A resposta ao comando vai expor os metadados de cada chave de acesso associada ao usuário do IAM. Se os pares de chaves não operacionais Status estiverem definidos como Inactive, a chave será desativada e a configuração de acesso do usuário do IAM vai aderir a essa recomendação.

4. Repita as etapas 1 a 3 para cada usuário do IAM na sua conta da AWS.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Public Access Given Rds Instance

Nome da categoria na API: PUBLIC_ACCESS_GIVEN_RDS_INSTANCE

Verifique se as instâncias de banco de dados do RDS provisionadas na sua conta da AWS restringem o acesso não autorizado para minimizar os riscos de segurança. Para restringir o acesso a qualquer instância de banco de dados RDS acessível publicamente, desative a flag "Acessível publicamente" do banco de dados e atualize o grupo de segurança da VPC associado à instância.

Recomendação: verifique se o acesso público não foi concedido à instância do RDS

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

1. Faça login no console de gerenciamento da AWS e acesse o painel do RDS em https://console.aws.amazon.com/rds/.
2. No painel de navegação, em Painel do RDS, clique em Databases.
3. Selecione a instância do RDS que você quer atualizar.
4. Clique em Modify no menu superior do painel.
5. No painel "Modificar instância de banco de dados", na seção Connectivity, clique em Additional connectivity configuration e atualize o valor de Publicly Accessible para "Não acessível publicamente" para restringir o acesso público. Siga as etapas abaixo para atualizar as configurações da sub-rede:
   - Selecione a guia Connectivity and security e clique no valor do atributo VPC na seção Networking.
   - Selecione a guia Details no painel inferior do painel da VPC e clique no valor do atributo de configuração da tabela de rotas.
   - Na página de detalhes da tabela de rotas, selecione a guia "Rotas" no painel inferior do painel e clique em Edit routes.
   - Na página "Editar rotas", atualize o destino do alvo, que está definido como igw-xxxxx, e clique em rotas Save.
6. No painel "Modificar instância do banco de dados", clique em Continue e, na seção "Programação de modificações", realize uma das seguintes ações com base nos seus requisitos:
   - Selecione "Aplicar na próxima janela de manutenção programada" para aplicar as mudanças automaticamente na próxima janela de manutenção programada.
   - Selecione "Aplicar imediatamente" para aplicar as alterações imediatamente. Com essa opção, todas as modificações pendentes serão aplicadas de forma assíncrona assim que possível, independentemente da configuração da janela de manutenção para essa instância do banco de dados do RDS. Todas as mudanças disponíveis na fila de modificações pendentes também são aplicadas. Se alguma das modificações pendentes exigir inatividade, a escolha dessa opção pode causar inatividade inesperada no aplicativo.
7. Repita as etapas 3 a 6 para cada instância do RDS disponível na região atual.
8. Mude a região da AWS na barra de navegação para repetir o processo em outras regiões.

CLI da AWS

1. Execute o comando describe-db-instances para listar todos os identificadores de nomes de banco de dados do RDS disponíveis na região da AWS selecionada:

aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'

2. A resposta ao comando vai retornar cada identificador de instância do banco de dados.
3. Execute o comando modify-db-instance para modificar a configuração da instância do RDS selecionada. Em seguida, use o comando a seguir para desativar a flag Publicly Accessible das instâncias do RDS selecionadas. Esse comando usa a flag apply-immediately. Se você quiser to avoid any downtime --no-apply-immediately flag can be used:

aws rds modify-db-instance --region <region-name> --db-instance-identifier <db-name> --no-publicly-accessible --apply-immediately

4. A resposta ao comando vai revelar a configuração PubliclyAccessible nos valores pendentes e será aplicada no horário especificado.
5. No momento, não é possível atualizar o destino do Internet Gateway usando a AWS CLI. Para atualizar informações sobre o Internet Gateway, use o procedimento do console da AWS.
6. Repita as etapas de 1 a 5 para cada instância do RDS provisionada na região atual.
7. Mude a região da AWS usando o filtro --region para repetir o processo em outras regiões.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Rds Enhanced Monitoring Enabled

Nome da categoria na API: RDS_ENHANCED_MONITORING_ENABLED

O monitoramento avançado fornece métricas em tempo real sobre o sistema operacional em que a instância do RDS é executada por meio de um agente instalado na instância.

Para mais detalhes, consulte Como monitorar métricas do SO com o monitoramento avançado.

Recomendação: verifica se o monitoramento aprimorado foi ativado em todas as instâncias do RDS DB

Para corrigir essa descoberta, siga estas etapas:

Terraform

Para corrigir esse controle, ative o Monitoramento aprimorado nas suas instâncias do RDS da seguinte maneira:

Crie um papel do IAM para o RDS:

resource "aws_iam_role" "rds_logging" {
  name = "CustomRoleForRDSMonitoring"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Sid    = "CustomRoleForRDSLogging"
        Principal = {
          Service = "monitoring.rds.amazonaws.com"
        }
      },
    ]
  })
}

Extraia a política gerenciada da AWS para o monitoramento avançado do RDS:

data "aws_iam_policy" "rds_logging" {
  name = "AmazonRDSEnhancedMonitoringRole"
}

Anexe a política ao papel:

resource "aws_iam_policy_attachment" "rds_logging" {
  name       = "AttachRdsLogging"
  roles      = [aws_iam_role.rds_logging.name]
  policy_arn = data.aws_iam_policy.rds_logging.arn
}

Defina um intervalo de monitoramento e um ARN de função de monitoramento para a instância do RDS que está violando o limite para ativar o Monitoramento aprimorado:

resource "aws_db_instance" "default" {
  identifier           = "test-rds"
  allocated_storage    = 10
  engine               = "mysql"
  engine_version       = "5.7"
  instance_class       = "db.t3.micro"
  db_name              = "mydb"
  username             = "foo"
  password             = "foobarbaz"
  parameter_group_name = "default.mysql5.7"
  skip_final_snapshot  = true
  monitoring_interval  = 60
  monitoring_role_arn  = aws_iam_role.rds_logging.arn
}

Console da AWS

É possível ativar o monitoramento aprimorado ao criar uma instância de DB, um cluster de DB multi-AZ ou uma réplica de leitura ou ao modificar uma instância de DB ou um cluster de DB multi-AZ. Se você modificar uma instância do DB para ativar o monitoramento aprimorado, não será necessário reiniciar a instância do DB para que a mudança entre em vigor.

É possível ativar o monitoramento avançado no console do RDS ao realizar uma das seguintes ações na página "Bancos de dados":

• Crie uma instância de banco de dados ou um cluster de banco de dados Multi-AZ. Escolha "Criar banco de dados".
• Criar uma réplica de leitura: escolha "Ações" e "Criar réplica de leitura".
• Modificar uma instância do DB ou um cluster de DB multi-AZ: escolha "Modificar".

Para ativar ou desativar o monitoramento avançado no console do RDS

1. Role até "Configuração adicional".
2. Em "Monitoramento", escolha "Ativar o monitoramento aprimorado" para a instância do DB ou a réplica de leitura. Para desativar o Monitoramento aprimorado, escolha "Desativar o Monitoramento aprimorado".
3. Defina a propriedade "Papel de monitoramento" como o papel do IAM que você criou para permitir que o Amazon RDS se comunique com os registros do Amazon CloudWatch em seu nome ou escolha "Padrão" para que o RDS crie um papel chamado rds-monitoring-role.
4. Defina a propriedade "Granularity" como o intervalo, em segundos, entre os pontos em que as métricas são coletadas para a instância do DB ou a réplica de leitura. A propriedade "Granularity" pode ser definida como um dos seguintes valores: 1, 5, 10, 15, 30 ou 60. O console do RDS é atualizado a cada 5 segundos. Se você definir a granularidade como 1 segundo no console do RDS, ainda vai ver as métricas atualizadas apenas a cada 5 segundos. É possível extrair atualizações de métricas de 1 segundo usando os Logs do CloudWatch.

CLI da AWS

Crie o papel do IAM do RDS:

aws iam create-role \
  --role-name "CustomRoleForRDSMonitoring" \
  --assume-role-policy-document file://rds-assume-role.json

Anexe a política AmazonRDSEnhancedMonitoringRole ao papel:

aws iam attach-role-policy \
  --role-name "CustomRoleForRDSMonitoring"\
  --policy-arn "arn:aws:iam::aws:policy/service-role/AmazonRDSEnhancedMonitoringRole"

Modifique a instância do RDS para ativar o monitoramento aprimorado definindo --monitoring-interval e --monitoring-role-arn:

aws rds modify-db-instance \
  --db-instance-identifier "test-rds" \
  --monitoring-interval 30 \
  --monitoring-role-arn "arn:aws:iam::<account_id>:role/CustomRoleForRDSMonitoring"

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Rds Instance Deletion Protection Enabled

Nome da categoria na API: RDS_INSTANCE_DELETION_PROTECTION_ENABLED

Ativar a proteção contra exclusão de instâncias é uma camada extra de proteção contra exclusão acidental do banco de dados ou exclusão por uma entidade não autorizada.

Enquanto a proteção contra exclusão estiver ativada, não será possível excluir uma instância do DB do RDS. Antes que uma solicitação de exclusão seja bem-sucedida, a proteção contra exclusão precisa ser desativada.

Recomendação: verifica se a proteção contra exclusão está ativada em todas as instâncias do RDS

Para corrigir essa descoberta, siga estas etapas:

Terraform

Para corrigir esse controle, defina deletion_protection como true no recurso aws_db_instance.

resource "aws_db_instance" "example" {
  # ... other configuration ...
  deletion_protection = true
}

Console da AWS

Para ativar a proteção contra exclusão em uma instância do DB do RDS

1. Abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.
2. No painel de navegação, escolha "Bancos de dados" e, em seguida, a instância do banco de dados que você quer modificar.
3. Escolha "Modificar".
4. Em "Proteção contra exclusão", escolha "Ativar proteção contra exclusão".
5. Escolha "Continuar".
6. Em "Programação de modificações", escolha quando aplicar as modificações. As opções são "Aplicar durante a próxima janela de manutenção programada" ou "Aplicar imediatamente".
7. Escolha "Modificar instância do banco de dados".

CLI da AWS

O mesmo se aplica à AWS CLI. Defina --deletion-protection como mostrado abaixo.

aws rds modify-db-instance \
  --db-instance-identifier = "test-rds" \
  --deletion-protection

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Rds In Backup Plan

Nome da categoria na API: RDS_IN_BACKUP_PLAN

Essa verificação avalia se as instâncias do Amazon RDS DB estão cobertas por um plano de backup. Esse controle falha se uma instância do RDS DB não estiver coberta por um plano de backup.

O AWS Backup é um serviço de backup totalmente gerenciado que centraliza e automatiza o backup de dados em todos os serviços da AWS. Com o AWS Backup, é possível criar políticas de backup chamadas de planos de backup. Esses planos podem ser usados para definir seus requisitos de backup, como a frequência de backup dos dados e por quanto tempo manter esses backups. Incluir instâncias do RDS DB em um plano de backup ajuda a proteger seus dados contra perda ou exclusão acidental.

Recomendação: as instâncias do RDS DB precisam estar cobertas por um plano de backup

Para corrigir essa descoberta, siga estas etapas:

Terraform

Para corrigir esse controle, defina backup_retention_period como um valor maior que 7 no recurso aws_db_instance.

resource "aws_db_instance" "example" {
  # ... other Configuration ...
  backup_retention_period = 7
}

Console da AWS

Para ativar os backups automáticos imediatamente

1. Abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.
2. No painel de navegação, escolha "Bancos de dados" e, em seguida, a instância do banco de dados que você quer modificar.
3. Escolha "Modificar" para abrir a página "Modificar instância do banco de dados".
4. Em "Período de retenção de backup", escolha um valor positivo diferente de zero, por exemplo, 30 dias, e selecione "Continuar".
5. Selecione a seção "Programação de modificações" e escolha quando aplicar as modificações: você pode aplicar durante a próxima janela de manutenção programada ou aplicar imediatamente.
6. Em seguida, na página de confirmação, escolha "Modificar instância do DB" para salvar as alterações e ativar os backups automáticos.

CLI da AWS

O mesmo se aplica à AWS CLI. Para ativar os backups automáticos, mude o backup-retention-period para um valor maior que 0 (padrão).

aws rds modify-db-instance --db-instance-identifier "test-rds" --backup-retention-period 7

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Rds Logging Enabled

Nome da categoria na API: RDS_LOGGING_ENABLED

Isso verifica se os seguintes registros do Amazon RDS estão ativados e enviados para o CloudWatch.

Os bancos de dados do RDS precisam ter os registros relevantes ativados. O registro de banco de dados fornece registros detalhados das solicitações feitas ao RDS. Os registros de banco de dados podem ajudar nas auditorias de segurança e acesso e podem ajudar a diagnosticar problemas de disponibilidade.

Recomendação: verifica se os registros exportados foram ativados em todas as instâncias do RDS DB

Para corrigir essa descoberta, siga estas etapas:

Terraform

resource "aws_db_instance" "example" {
  # ... other configuration for MySQL ...
  enabled_cloudwatch_logs_exports = ["audit", "error", "general", "slowquery"]
  parameter_group_name            = aws_db_parameter_group.example.name
}

resource "aws_db_parameter_group" "example" {
  name   = "${aws_db_instance.example.dbInstanceIdentifier}-parameter-group"
  family = "mysql5.7"

  parameter {
    name  = "general_log"
    value = 1
  }

  parameter {
    name  = "slow_query_log"
    value = 1
  }

  parameter {
    name  = "log_output"
    value = "FILE"
  }
}

No MariaDB, crie um grupo de opções personalizado e defina option_group_name no recurso aws_db_instance.

resource "aws_db_instance" "example" {
  # ... other configuration for MariaDB ...
  enabled_cloudwatch_logs_exports = ["audit", "error", "general", "slowquery"]
  parameter_group_name            = aws_db_parameter_group.example.name
  option_group_name               = aws_db_option_group.example.name
}

resource "aws_db_option_group" "example" {
  name                     = "mariadb-option-group-for-logs"
  option_group_description = "MariaDB Option Group for Logs"
  engine_name              = "mariadb"
  option {
    option_name = "MARIADB_AUDIT_PLUGIN"
    option_settings {
      name  = "SERVER_AUDIT_EVENTS"
      value = "CONNECT,QUERY,TABLE,QUERY_DDL,QUERY_DML,QUERY_DCL"
    }
  }
}

Console da AWS

Para criar um grupo de parâmetros do banco de dados personalizado

1. Abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.
2. No painel de navegação, escolha "Grupos de parâmetros".
3. Escolha "Criar grupo de parâmetros".
4. Na lista "Família de grupos de parâmetros", escolha uma família de grupos de parâmetros do banco de dados.
5. Na lista "Tipo", escolha "Grupo de parâmetros do banco de dados".
6. Em "Nome do grupo", insira o nome do novo grupo de parâmetros do DB.
7. Em "Descrição", digite uma descrição para o novo grupo de parâmetros do DB.
8. Escolha "Criar".

Para criar um novo grupo de opções para o registro do MariaDB usando o console

1. Abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.
2. No painel de navegação, escolha "Grupos de opções".
3. Escolha "Criar grupo".
4. Na janela "Criar grupo de opções", informe o seguinte:
   * Nome: precisa ser exclusivo na sua conta da AWS. Somente letras, dígitos e hifens.
   * Descrição: usado apenas para fins de exibição.
   * Motor: selecione o mecanismo de DB.
   * Versão principal do mecanismo: selecione a versão principal do mecanismo do DB.
5. Escolha "Criar".
6. Escolha o nome do grupo de opções que você acabou de criar.
7. Escolha a opção "Adicionar".
8. Escolha MARIADB_AUDIT_PLUGIN na lista "Nome da opção".
9. Defina SERVER_AUDIT_EVENTS como CONNECT, QUERY, TABLE, QUERY_DDL, QUERY_DML, QUERY_DCL.
10. Escolha a opção "Adicionar".

Para publicar registros do SQL Server DB, Oracle DB ou PostgreSQL no CloudWatch Logs pelo console do AWS Management

1. Abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.
2. No painel de navegação, escolha "Bancos de dados".
3. Escolha a instância do DB que você quer modificar.
4. Escolha "Modificar".
5. Em "Exportações de registro", escolha todos os arquivos de registro para começar a publicar no CloudWatch Logs.
6. As exportações de registro estão disponíveis apenas para versões do mecanismo de banco de dados que oferecem suporte à publicação nos CloudWatch Logs.
7. Escolha "Continuar". Em seguida, na página de resumo, escolha "Modificar instância do DB".

Para aplicar um novo grupo de parâmetros ou de opções do banco de dados a uma instância do RDS DB

1. Abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.
2. No painel de navegação, escolha "Bancos de dados".
3. Escolha a instância do DB que você quer modificar.
4. Escolha "Modificar".
5. Em "Opções de banco de dados", mude o grupo de parâmetros e de opções do banco de dados conforme necessário.
6. Quando terminar as mudanças, escolha "Continuar". Confira o resumo das modificações.
7. Escolha "Modificar instância de banco de dados" para salvar as mudanças.

CLI da AWS

Extraia as famílias de mecanismos e escolha a que corresponde ao mecanismo e à versão da instância do banco de dados.

aws rds describe-db-engine-versions \
  --query "DBEngineVersions[].DBParameterGroupFamily" \
  --engine "mysql"

Crie um grupo de parâmetros de acordo com o mecanismo e a versão.

aws rds create-db-parameter-group \
  --db-parameter-group-name "rds-mysql-parameter-group" \
  --db-parameter-group-family "mysql5.7" \
  --description "Example parameter group for logs"

Crie um arquivo rds-parameters.json com os parâmetros necessários de acordo com o mecanismo de banco de dados. Neste exemplo, usamos o MySQL5.7.

[
  {
    "ParameterName": "general_log",
    "ParameterValue": "1",
    "ApplyMethod": "immediate"
  },
  {
    "ParameterName": "slow_query_log",
    "ParameterValue": "1",
    "ApplyMethod": "immediate"
  },
  {
    "ParameterName": "log_output",
    "ParameterValue": "FILE",
    "ApplyMethod": "immediate"
  }
]

Modifique o grupo de parâmetros para adicionar os parâmetros de acordo com o mecanismo do banco de dados. Este exemplo usa o MySQL 5.7

aws rds modify-db-parameter-group \
  --db-parameter-group-name "rds-mysql-parameter-group" \
  --parameters file://rds-parameters.json

Modifique a instância do banco de dados para associar o grupo de parâmetros.

aws rds modify-db-instance \
  --db-instance-identifier "test-rds" \
  --db-parameter-group-name "rds-mysql-parameter-group"

Além disso, para o MariaDB, crie um grupo de opções da seguinte maneira.

aws rds create-option-group \
  --option-group-name "rds-mariadb-option-group" \
  --engine-name "mariadb" \
  --major-engine-version "10.6" \
  --option-group-description "Option group for MariaDB logs"

Crie um arquivo rds-mariadb-options.json da seguinte maneira.

{
  "OptionName": "MARIADB_AUDIT_PLUGIN",
  "OptionSettings": [
    {
      "Name": "SERVER_AUDIT_EVENTS",
      "Value": "CONNECT,QUERY,TABLE,QUERY_DDL,QUERY_DML,QUERY_DCL"
    }
  ]
}

Adicione a opção ao grupo.

aws rds add-option-to-option-group \
  --option-group-name "rds-mariadb-option-group" \
  --options file://rds-mariadb-options.json

Modifique a instância do MariaDB para associar o grupo de opções à instância do DB.

aws rds modify-db-instance \
  --db-instance-identifier "rds-test-mariadb" \
  --option-group-name "rds-mariadb-option-group"

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Rds Multi Az Support

Nome da categoria na API: RDS_MULTI_AZ_SUPPORT

As instâncias do RDS DB precisam ser configuradas para várias Zonas de Disponibilidade (AZs). Isso garante a disponibilidade dos dados armazenados. As implantações em várias AZs permitem o failover automático se houver um problema com a disponibilidade da Zona de disponibilidade e durante a manutenção regular do RDS.

Recomendação: verifica se a alta disponibilidade foi ativada em todas as instâncias do RDS DB

Para corrigir essa descoberta, siga estas etapas:

Terraform

Para corrigir esse controle, defina multi_az como verdadeiro no recurso aws_db_instance.

resource "aws_db_instance" "example" {
  # ... other configuration ...
  multi_az                = true
}

Console da AWS

Para ativar várias Zonas de disponibilidade para uma instância de banco de dados

1. Abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.
2. No painel de navegação, escolha "Bancos de dados" e, em seguida, a instância do banco de dados que você quer modificar.
3. Escolha "Modificar". A página "Modificar instância de BD" aparece.
4. Em "Especificações da instância", defina a implantação Multi-AZ como "Sim".
5. Escolha "Continuar" e confira o resumo das modificações.
6. (Opcional) Escolha "Aplicar imediatamente" para aplicar as mudanças. Em alguns casos, essa opção pode causar uma interrupção. Para mais informações, consulte "Como usar a configuração "Aplicar imediatamente" no guia do usuário do Amazon RDS".
7. Na página de confirmação, revise as mudanças. Se estiverem corretas, escolha "Modificar instância de banco de dados" para salvar as mudanças.

CLI da AWS

O mesmo se aplica à AWS CLI. Ative o suporte a vários AZs fornecendo a opção --multi-az.

modify-db-instance
  --db-instance-identifier "test-rds" \
  --multi-az

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Redshift Cluster Configuration Check

Nome da categoria na API: REDSHIFT_CLUSTER_CONFIGURATION_CHECK

Isso verifica elementos essenciais de um cluster do Redshift: criptografia em repouso, geração de registros e tipo de nó.

Esses itens de configuração são importantes para manter um cluster do Redshift seguro e observável.

Recomendação: verifique se todos os clusters do Redshift têm criptografia em repouso, geração de registros e tipo de nó.

Para corrigir essa descoberta, siga estas etapas:

Terraform

resource "aws_kms_key" "redshift_encryption" {
  description         = "Used for Redshift encryption configuration"
  enable_key_rotation = true
}

resource "aws_redshift_cluster" "example" {
  # ... other configuration ...
  encrypted                           = true
  kms_key_id                          = aws_kms_key.redshift_encryption.id
  logging {
    enable               = true
    log_destination_type = "cloudwatch"
    log_exports          = ["connectionlog", "userlog", "useractivitylog"]
  }
}

Console da AWS

Para ativar o registro de auditoria do cluster

1. Abra o console do Amazon Redshift em https://console.aws.amazon.com/redshift/.
2. No menu de navegação, escolha "Clusters" e o nome do cluster que você quer modificar.
3. Escolha "Propriedades".
4. Escolha "Editar" e "Editar registro de auditoria".
5. Defina "Configurar geração de registros de auditoria" como "Ativar", defina o tipo de exportação de registros como "CloudWatch (recomendado)" e escolha os registros a serem exportados.

Para usar o AWS S3 e gerenciar os registros de auditoria do Redshift, consulte Amazon Redshift: geração de registros de auditoria do banco de dados na documentação da AWS.

6. Escolha "Salvar alterações".

Para modificar a criptografia do banco de dados em um cluster

1. Faça login no console de gerenciamento da AWS e abra o console do Amazon Redshift em https://console.aws.amazon.com/redshift/.
2. No menu de navegação, escolha "Clusters" e selecione o cluster em que você quer modificar a criptografia.
3. Escolha "Propriedades".
4. Escolha "Editar" e "Editar criptografia".
5. Escolha a criptografia a ser usada (KMS ou HSM) e forneça:

• Para o KMS: chave a ser usada
• Para HSM: conexão e certificado do cliente

CLI da AWS

1. Criar uma chave do KMS e extrair o ID da chave

aws kms create-key \
  --description "Key to encrypt Redshift Clusters"

2. Modificar o cluster

aws redshift modify-cluster \
  --cluster-identifiers "test-redshift-cluster" \
  --encrypted \
  --kms-key-id <value>

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Redshift Cluster Maintenancesettings Check

Nome da categoria na API: REDSHIFT_CLUSTER_MAINTENANCESETTINGS_CHECK

Os upgrades automáticos de versão principal acontecem de acordo com a janela de manutenção

Recomendação: verifique se todos os clusters do Redshift têm allowVersionUpgrade ativado e preferredMaintenanceWindow e automatedSnapshotRetentionPeriod definidos

Para corrigir essa descoberta, siga estas etapas:

Terraform

Essa verificação é compatível com todos os valores padrão fornecidos pelo Terraform. Em caso de falha de um cluster do Redshift, revise os requisitos e remova as substituições padrão para os seguintes atributos do recurso aws_redshift_cluster.

resource "aws_redshift_cluster" "example" {

  # ...other configuration ...

  # The following values are compliant and set by default if omitted.
  allow_version_upgrade               = true
  preferred_maintenance_window        = "sat:10:00-sat:10:30"
  automated_snapshot_retention_period = 1
}

Console da AWS

Ao criar um cluster do Redshift pelo console da AWS, os valores padrão já estão em conformidade com esse controle.

Para mais informações, consulte Gerenciar clusters usando o console.

CLI da AWS

Para corrigir esse controle usando a AWS CLI, faça o seguinte:

aws redshift modify-cluster \
  --cluster-identifier "test-redshift-cluster" \
  --allow-version-upgrade

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Redshift Cluster Public Access Check

Nome da categoria na API: REDSHIFT_CLUSTER_PUBLIC_ACCESS_CHECK

O atributo PubliclyAccessible da configuração do cluster do Amazon Redshift indica se o cluster é acessível publicamente. Quando o cluster é configurado com PubliclyAccessible definido como verdadeiro, ele é uma instância voltada para a Internet que tem um nome DNS publicamente solucionável, que é resolvido em um endereço IP público.

Quando o cluster não é acessível publicamente, ele é uma instância interna com um nome DNS que resolve para um endereço IP privado. A menos que você queira que o cluster seja acessível publicamente, ele não deve ser configurado com PubliclyAccessible definido como verdadeiro.

Recomendação: verifica se os clusters do Redshift são acessíveis publicamente

Para corrigir essa descoberta, siga estas etapas:

Terraform

Para corrigir esse controle, é necessário modificar o recurso de cluster do Redshift e definir publicly_accessible como false. O valor padrão é true.

resource "aws_redshift_cluster" "example" {
  # ... other configuration ...
  publicly_accessible = false
}

Console da AWS

Para desativar o acesso público a um cluster do Amazon Redshift

1. Abra o console do Amazon Redshift em https://console.aws.amazon.com/redshift/.
2. No menu de navegação, escolha "Clusters" e o nome do cluster com o grupo de segurança que você quer modificar.
3. Escolha "Ações" e "Modificar configuração de acesso público".
4. Em "Permitir que instâncias e dispositivos fora da VPC se conectem ao seu banco de dados pelo endpoint do cluster", escolha "Não".
5. Selecione "Confirmar".

CLI da AWS

Use o comando modify-cluster para definir --no-publicly-accessible.

aws redshift modify-cluster \
  --cluster-identifier "test-redshift-cluster" \
  --no-publicly-accessible

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Restricted Common Ports

Nome da categoria na API: RESTRICTED_COMMON_PORTS

Isso verifica se o tráfego de entrada irrestrito dos grupos de segurança é acessível às portas especificadas com o maior risco. Esse controle falha se alguma das regras em um grupo de segurança permitir o tráfego de entrada de "0.0.0.0/0" ou "::/0" para essas portas.

O acesso irrestrito (0.0.0.0/0) aumenta as oportunidades de atividades maliciosas, como invasões, ataques de negação de serviço e perda de dados.

Os grupos de segurança fornecem filtragem stateful do tráfego de entrada e saída da rede para os recursos da AWS. Nenhum grupo de segurança deve permitir acesso de entrada irrestrito às seguintes portas:

• 20, 21 (FTP)
• 22 (SSH)
• 23 (Telnet)
• 25 (SMTP)
• 110 (POP3)
• 135 (RPC)
• 143 (IMAP)
• 445 (CIFS)
• 1433, 1434 (MSSQL)
• 3000 (frameworks de desenvolvimento da Web Go, Node.js e Ruby)
• 3306 (mySQL)
• 3389 (RDP)
• 4333 (ahsp)
• 5000 (frameworks de desenvolvimento da Web em Python)
• 5432 (postgresql)
• 5500 (fcp-addr-srvr1)
• 5601 (painéis do OpenSearch)
• 8080 (proxy)
• 8088 (porta HTTP legada)
• 8888 (porta HTTP alternativa)
• 9200 ou 9300 (OpenSearch)

Recomendação: os grupos de segurança não devem permitir acesso irrestrito a portas de alto risco

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

Para excluir uma regra de grupo de segurança:

1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.
2. No painel de navegação, escolha "Grupos de segurança".
3. Selecione o grupo de segurança a ser atualizado, escolha "Ações" e "Editar regras de entrada" para remover uma regra de entrada ou "Editar regras de saída" para remover uma regra de saída.
4. Clique no botão "Excluir" à direita da regra que você quer excluir.
5. Escolha "Visualizar mudanças" e "Confirmar".

Para saber como excluir regras de um grupo de segurança, consulte Configurar regras de grupos de segurança no guia do usuário do Amazon EC2.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Restricted Ssh

Nome da categoria na API: RESTRICTED_SSH

Os grupos de segurança fornecem filtragem stateful do tráfego de entrada e saída da rede para os recursos da AWS.

O CIS recomenda que nenhum grupo de segurança permita o acesso de entrada irrestrito à porta 22. A remoção da conectividade irrestrita a serviços de console remoto, como o SSH, reduz a exposição de um servidor a riscos.

Recomendação: os grupos de segurança não devem permitir a entrada de 0.0.0.0/0 na porta 22

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

Siga as etapas abaixo para cada grupo de segurança associado a uma VPC.

Abra o console da Amazon VPC em https://console.aws.amazon.com/vpc/.

1. No painel à esquerda, escolha Grupos de segurança.
2. Selecione um grupo de segurança.
3. Na parte de baixo da página, escolha a guia Regras de entrada.
4. Escolha Editar regras.
5. Identifique a regra que permite o acesso pela porta 22 e escolha o X para removê-la.
6. Escolha Salvar regras.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Rotation Customer Created Cmks Enabled

Nome da categoria na API: ROTATION_CUSTOMER_CREATED_CMKS_ENABLED

Verifica se a rotação automática de chaves está ativada para cada chave e corresponde ao ID da chave KMS criada pelo cliente. A regra é NÃO_EM_CONFORMIDADE se a função de gravador do AWS Config de um recurso não tiver a permissão kms:DescribeKey.

Recomendação: verifique se a rotação das CMKs criadas pelo cliente está ativada

Para ativar a rotação automática de chaves do AWS KMS, consulte Como alternar chaves do AWS KMS na documentação da AWS.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Rotation Customer Created Symmetric Cmks Enabled

Nome da categoria na API: ROTATION_CUSTOMER_CREATED_SYMMETRIC_CMKS_ENABLED

O AWS Key Management Service (KMS) permite que os clientes façam a rotação da chave de suporte, que é o material de chave armazenado no KMS e vinculado ao ID da chave mestra do cliente (CMK) criada pelo cliente. É a chave de suporte usada para realizar operações criptográficas, como criptografia e descriptografia. Atualmente, a rotação automática de chaves retém todas as chaves de backup anteriores para que a descriptografia de dados criptografados possa ocorrer de forma transparente. É recomendável ativar a rotação de chaves CMK para chaves simétricas. A rotação de chaves não pode ser ativada para nenhuma CMK assimétrica.

Recomendação: verifique se a rotação das CMKs simétricas criadas pelo cliente está ativada

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

1. Faça login no console de gerenciamento da AWS e abra o console do IAM em https://console.aws.amazon.com/iam.
2. No painel de navegação à esquerda, escolha Customer managed keys .
3. Selecione uma CMK gerenciada pelo cliente em que Key spec = SYMMETRIC_DEFAULT
4. Abaixo do painel "Configuração geral", abra a guia "Rotação de tecla".
5. Marque a caixa de seleção "Girar automaticamente esta chave do KMS a cada ano".

CLI da AWS

1. Execute o comando a seguir para ativar a rotação de chaves:

 aws kms enable-key-rotation --key-id <kms_key_id>

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Routing Tables Vpc Peering Are Least Access

Nome da categoria na API: ROUTING_TABLES_VPC_PEERING_ARE_LEAST_ACCESS

Verifica se as tabelas de roteamento do peering de VPC estão configuradas com o principal de menos privilégio.

Recomendação: verifique se as tabelas de roteamento do peering de VPC são de "acesso mínimo"

Para atualizar as tabelas de rotas para o peering da VPC, consulte Atualizar as tabelas de rotas para uma conexão de peering da VPC no guia do usuário da AWS VPC.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

S3 Account Level Public Access Blocks

Nome da categoria na API: S3_ACCOUNT_LEVEL_PUBLIC_ACCESS_BLOCKS

O recurso "Bloquear acesso público" do Amazon S3 oferece configurações para pontos de acesso, buckets e contas para ajudar a gerenciar o acesso público aos recursos do Amazon S3. Por padrão, os novos buckets, pontos de acesso e objetos não permitem acesso público.

Recomendação: verifica se as configurações necessárias de bloqueio de acesso público do S3 estão definidas no nível da conta

Para corrigir essa descoberta, siga estas etapas:

Terraform

O recurso do Terraform a seguir configura o acesso ao S3 no nível da conta.

resource "aws_s3_account_public_access_block" "s3_control" {
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Console da AWS

Editar as configurações de bloqueio de acesso público para todos os buckets do S3 em uma conta da AWS.

1. Faça login no console de gerenciamento da AWS e abra o console do Amazon S3 em https://console.aws.amazon.com/s3/.
2. Escolha as configurações de "Bloquear acesso público" para esta conta.
3. Escolha "Editar" para mudar as configurações de bloqueio de acesso público para todos os buckets na sua conta da AWS.
4. Escolha as configurações que você quer mudar e clique em "Salvar alterações".
5. Quando a confirmação for solicitada, digite "confirmar". Em seguida, escolha "Confirmar" para salvar as mudanças.

CLI da AWS

aws s3control put-public-access-block \
--account-id <value> \
--public-access-block-configuration '{"BlockPublicAcls": true, "BlockPublicPolicy": true, "IgnorePublicAcls": true, "RestrictPublicBuckets": true}'

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

S3 Buckets Configured Block Public Access Bucket And Account Settings

Nome da categoria na API: S3_BUCKETS_CONFIGURED_BLOCK_PUBLIC_ACCESS_BUCKET_AND_ACCOUNT_SETTINGS

O Amazon S3 oferece Block public access (bucket settings) e Block public access (account settings) para ajudar você a gerenciar o acesso público aos recursos do Amazon S3. Por padrão, os buckets e objetos do S3 são criados com o acesso público desativado. No entanto, um principal do AWS IAM com permissões suficientes do S3 pode ativar o acesso público no nível do bucket ou do objeto. Quando ativada, a Block public access (bucket settings) impede que um bucket individual e os objetos contidos nele se tornem acessíveis publicamente. Da mesma forma, Block public access (account settings) impede que todos os buckets e objetos contidos sejam acessíveis publicamente em toda a conta.

Recomendação:

Verifique se os buckets do S3 estão configurados com Block public access (bucket settings).

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

Se a saída for true para as configurações de configuração separadas, ela será definida na conta.

1. Faça login no console de gerenciamento da AWS e abra o console do Amazon S3 usando https://console.aws.amazon.com/s3/
2. Escolha Bloquear o acesso público (configurações da conta).
3. Escolha Editar para mudar as configurações de bloqueio de acesso público para todos os buckets na sua conta da AWS.
4. Escolha as configurações que você quer mudar e clique em Salvar. Para detalhes sobre cada configuração, pause nos ícones i.
5. Quando a confirmação for solicitada, digite confirm. Em seguida, clique em Confirmar para salvar as alterações.

CLI da AWS

Para definir as configurações de bloqueio de acesso público para essa conta, execute o seguinte comando:

aws s3control put-public-access-block
--public-access-block-configuration BlockPublicAcls=true, IgnorePublicAcls=true, BlockPublicPolicy=true, RestrictPublicBuckets=true
--account-id <value>

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

S3 Bucket Access Logging Enabled Cloudtrail S3 Bucket

Nome da categoria na API: S3_BUCKET_ACCESS_LOGGING_ENABLED_CLOUDTRAIL_S3_BUCKET

A geração de registros de acesso ao bucket do S3 gera um registro que contém registros de acesso para cada solicitação feita ao bucket do S3. Um registro de registro de acesso contém detalhes sobre a solicitação, como o tipo, os recursos especificados na solicitação e a data e a hora em que ela foi processada. É recomendável ativar a geração de registros de acesso ao bucket no bucket do CloudTrail S3.

Recomendação:

Verifique se a geração de registros de acesso do bucket S3 está ativada no bucket do CloudTrail S3

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

1. Faça login no console de gerenciamento da AWS e abra o console do S3 em https://console.aws.amazon.com/s3.
2. Em Todos os buckets, clique no bucket do S3 de destino.
3. Clique em Propriedades no canto superior direito do console.
4. Em Bucket: <s3\_bucket\_for\_cloudtrail>, clique em Logging</s3\_bucket\_for\_cloudtrail>.
5. Configurar o registro de bucket
   - Clique na caixa de seleção Ativado
   - Selecione o bucket de destino na lista
   - Insira um prefixo de destino
6. Clique em Salvar.

CLI da AWS

1. Confira o nome do bucket do S3 em que o CloudTrail está gerando registros:

aws cloudtrail describe-trails --region <region-name> --query trailList[*].S3BucketName

2. Copie e adicione o nome do bucket de destino em , o prefixo para o arquivo de registro em e, opcionalmente, adicione um endereço de e-mail no modelo a seguir e salve como :

{
 "LoggingEnabled": {
 "TargetBucket": "<Logging_BucketName>",
 "TargetPrefix": "<LogFilePrefix>",
 "TargetGrants": [
 {
 "Grantee": {
 "Type": "AmazonCustomerByEmail",
 "EmailAddress": "<EmailID>"
 },
 "Permission": "FULL_CONTROL"
 }
 ]
 }
}

3. Execute o comando put-bucket-logging com o nome do bucket e como entrada. Para mais informações, consulte put-bucket-logging:

aws s3api put-bucket-logging --bucket <BucketName> --bucket-logging-status file://<FileName.Json>

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

S3 Bucket Logging Enabled

Nome da categoria na API: S3_BUCKET_LOGGING_ENABLED

O recurso de geração de registros de acesso ao servidor do AWS S3 registra solicitações de acesso a buckets de armazenamento, o que é útil para auditorias de segurança. Por padrão, a geração de registros de acesso ao servidor não está ativada para buckets do S3.

Recomendação: verifique se a geração de registros está ativada em todos os buckets do S3

Para corrigir essa descoberta, siga estas etapas:

Terraform

O exemplo a seguir demonstra como criar dois buckets:

1. Um bucket de registro
2. Um bucket em conformidade

variable "bucket_acl_map" {
  type = map(any)
  default = {
    "logging-bucket"   = "log-delivery-write"
    "compliant-bucket" = "private"
  }
}

resource "aws_s3_bucket" "all" {
  for_each            = var.bucket_acl_map
  bucket              = each.key
  object_lock_enabled = true
  tags = {
    "Pwd"    = "s3"
  }
}

resource "aws_s3_bucket_acl" "private" {
  for_each = var.bucket_acl_map
  bucket   = each.key
  acl      = each.value
}

resource "aws_s3_bucket_versioning" "enabled" {
  for_each = var.bucket_acl_map
  bucket   = each.key
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_logging" "enabled" {
  for_each      = var.bucket_acl_map
  bucket        = each.key
  target_bucket = aws_s3_bucket.all["logging-bucket"].id
  target_prefix = "log/"
}

resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
  for_each = var.bucket_acl_map
  bucket   = each.key

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
    }
  }
}

Console da AWS

Para saber como ativar o registro de acesso ao S3 pelo console da AWS, consulte Como ativar o registro de acesso ao servidor do Amazon S3 na documentação da AWS.

CLI da AWS

O exemplo a seguir demonstra como:

1. Crie uma política de bucket para conceder ao serviço de registro a permissão principal de PutObject no bucket de registro.

policy.json

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "S3ServerAccessLogsPolicy",
            "Effect": "Allow",
            "Principal": {"Service": "logging.s3.amazonaws.com"},
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::MyBucket/Logs/*",
            "Condition": {
                "ArnLike": {"aws:SourceARN": "arn:aws:s3:::SOURCE-BUCKET-NAME"},
                "StringEquals": {"aws:SourceAccount": "SOURCE-AWS-ACCOUNT-ID"}
            }
        }
    ]
}

aws s3api put-bucket-policy \
  --bucket my-bucket
  --policy file://policy.json

2. Aplicar a política ao bucket de registro

logging.json

{
    "LoggingEnabled": {
        "TargetBucket": "MyBucket",
        "TargetPrefix": "Logs/"
    }
}

aws s3api put-bucket-logging \
  --bucket MyBucket \
  --bucket-logging-status file://logging.json

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

S3 Bucket Policy Set Deny Http Requests

Nome da categoria na API: S3_BUCKET_POLICY_SET_DENY_HTTP_REQUESTS

No nível do bucket do Amazon S3, é possível configurar permissões usando uma política de bucket, o que torna os objetos acessíveis apenas por HTTPS.

Recomendação: verifique se a política de bucket do S3 foi definida para negar as solicitações HTTP

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

usando o AWS Policy Generator:

1. Repita as etapas 1 a 4 acima.
2. Clique em Policy Generator na parte de baixo do editor de políticas do bucket.
3. Selecionar o tipo de política
   S3 Bucket Policy
4. Adicionar instruções
   - Effect = Negar
   - Principal = *
   - AWS Service = Amazon S3
   - Actions = *
   - Amazon Resource Name =
5. Gerar política
6. Copie o texto e adicione à política do bucket.

CLI da AWS

1. Exporte a política do bucket para um arquivo JSON.

aws s3api get-bucket-policy --bucket <bucket_name> --query Policy --output text > policy.json

2. Modifique o arquivo policy.json adicionando esta instrução:

{
 "Sid": <optional>",
 "Effect": "Deny",
 "Principal": "*",
 "Action": "s3:*",
 "Resource": "arn:aws:s3:::<bucket_name>/*",
 "Condition": {
 "Bool": {
 "aws:SecureTransport": "false"
 }
 }
 }

3. Aplique esta política modificada ao bucket do S3:

aws s3api put-bucket-policy --bucket <bucket_name> --policy file://policy.json

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

S3 Bucket Replication Enabled

Nome da categoria na API: S3_BUCKET_REPLICATION_ENABLED

Esse controle verifica se um bucket do Amazon S3 tem a replicação entre regiões ativada. O controle falha se o bucket não tiver a replicação entre regiões ativada ou se a replicação na mesma região também estiver ativada.

A replicação é a cópia automática e assíncrona de objetos entre buckets na mesma região da AWS ou em regiões diferentes. A replicação copia objetos recém-criados e atualizações de objetos de um bucket de origem para um ou mais buckets de destino. As práticas recomendadas da AWS recomendam a replicação para buckets de origem e destino que pertencem à mesma conta da AWS. Além da disponibilidade, considere outras configurações de endurecimento de sistemas.

Recomendação: verifica se os buckets do S3 têm a replicação entre regiões ativada

Para ativar a replicação entre regiões em um bucket do S3, consulte Como configurar a replicação para buckets de origem e de destino pertencentes à mesma conta no guia do usuário do Amazon Simple Storage Service. Em "Bucket de origem", escolha "Aplicar a todos os objetos no bucket".

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

S3 Bucket Server Side Encryption Enabled

Nome da categoria na API: S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED

Isso verifica se o bucket do S3 tem a criptografia padrão do Amazon S3 ativada ou se a política do bucket do S3 nega explicitamente as solicitações de inserção de objetos sem criptografia do lado do servidor.

Recomendação: verifique se todos os buckets do S3 usam a criptografia em repouso

Para corrigir essa descoberta, siga estas etapas:

Terraform

resource "aws_s3_bucket_server_side_encryption_configuration" "enable" {
  bucket = "my-bucket"

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

Console da AWS

Para ativar a criptografia padrão em um bucket do S3

1. Abra o console do Amazon S3 em https://console.aws.amazon.com/s3/.
2. No painel de navegação à esquerda, escolha "Recipientes".
3. Escolha o bucket do S3 na lista.
4. Escolha "Propriedades".
5. Escolha "Criptografia padrão".
6. Para a criptografia, escolha AES-256 ou AWS-KMS.
7. Escolha AES-256 para usar chaves gerenciadas pelo Amazon S3 para criptografia padrão. Para mais informações sobre como usar a criptografia do lado do servidor do Amazon S3 para criptografar seus dados, consulte o Guia do usuário do Amazon Simple Storage Service.
8. Escolha AWS-KMS para usar chaves gerenciadas pelo AWS KMS para criptografia padrão. Em seguida, escolha uma chave mestra na lista de chaves mestras do AWS KMS que você criou.
9. Digite o nome de recurso da Amazon (ARN) da chave KMS da AWS a ser usada. Você pode encontrar o ARN da sua chave AWS KMS no console do IAM, em "Chaves de criptografia". Ou você pode escolher um nome de chave na lista suspensa.
10. Importante: se você usar a opção AWS KMS para a configuração de criptografia padrão, estará sujeito às cotas de RPS (solicitações por segundo) do AWS KMS. Para mais informações sobre as cotas do AWS KMS e como solicitar um aumento de cota, consulte o Guia para desenvolvedores do AWS Key Management Service.
11. Escolha "Salvar".

Para mais informações sobre como criar uma chave do AWS KMS, consulte o Guia para desenvolvedores do AWS Key Management Service.

Para mais informações sobre como usar o AWS KMS com o Amazon S3, consulte o Guia do usuário do Amazon Simple Storage Service (em inglês).

Ao ativar a criptografia padrão, talvez seja necessário atualizar a política do bucket. Para mais informações sobre como migrar das políticas de bucket para a criptografia padrão, consulte o Guia do usuário do Amazon Simple Storage Service.

CLI da AWS

aws s3api put-bucket-encryption \
  --bucket my-bucket \
  --server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "AES256"}}]}'

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

S3 Bucket Versioning Enabled

Nome da categoria na API: S3_BUCKET_VERSIONING_ENABLED

O Amazon S3 é uma forma de manter várias variantes de um objeto no mesmo bucket e pode ajudar você a se recuperar com mais facilidade de ações indesejadas do usuário e falhas do aplicativo.

Recomendação: verifica se o controle de versões está ativado em todos os buckets do S3

Para corrigir essa descoberta, siga estas etapas:

Terraform

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-bucket"

  versioning {
    enabled = true
  }
}

Console da AWS

Para ativar ou desativar o controle de versões em um bucket do S3

1. Faça login no console de gerenciamento da AWS e abra o console do Amazon S3 em https://console.aws.amazon.com/s3/.
2. Na lista "Buckets", escolha o nome do bucket para ativar o controle de versões.
3. Escolha "Propriedades".
4. Em "Gerenciamento de versões do bucket", escolha "Editar".
5. Escolha "Suspender" ou "Ativar" e depois "Salvar alterações".

CLI da AWS

aws s3control put-bucket-versioning \
--bucket <bucket_name> \
--versioning-configuration Status=Enabled

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

S3 Default Encryption Kms

Nome da categoria na API: S3_DEFAULT_ENCRYPTION_KMS

Verifica se os buckets do Amazon S3 são criptografados com o AWS Key Management Service (AWS KMS)

Recomendação: verifica se todos os buckets foram criptografados com o KMS

Para corrigir essa descoberta, siga estas etapas:

Terraform

resource "aws_kms_key" "s3_encryption" {
  description         = "Used for S3 Bucket encryption configuration"
  enable_key_rotation = true
}

resource "aws_s3_bucket_server_side_encryption_configuration" "enable" {
  bucket   = "my-bucket"

  rule {
    apply_server_side_encryption_by_default {
      kms_master_key_id = aws_kms_key.s3_encryption.arn
      sse_algorithm     = "aws:kms"
    }
  }
}

Console da AWS

Para ativar a criptografia padrão em um bucket do S3

1. Abra o console do Amazon S3 em https://console.aws.amazon.com/s3/.
2. No painel de navegação à esquerda, escolha "Recipientes".
3. Escolha o bucket do S3 na lista.
4. Escolha "Propriedades".
5. Escolha "Criptografia padrão".
6. Para a criptografia, escolha AWS-KMS.
7. Escolha AWS-KMS para usar chaves gerenciadas pelo AWS KMS para criptografia padrão. Em seguida, escolha uma chave mestra na lista de chaves mestras do AWS KMS que você criou. Para mais informações sobre como criar chaves do KMS, consulte a documentação da AWS: como criar chaves.
8. Digite o nome de recurso da Amazon (ARN) da chave KMS da AWS que você quer usar. Você pode encontrar o ARN da sua chave AWS KMS no console do IAM, em "Chaves de criptografia". Ou você pode escolher um nome de chave na lista suspensa.
9. Importante: essa solução está sujeita às cotas de RPS (solicitações por segundo) do AWS KMS. Para mais informações sobre as cotas do AWS KMS e como solicitar um aumento de cota, consulte o Guia para desenvolvedores do AWS Key Management Service.
10. Selecione "Salvar".

Para mais informações sobre como usar o AWS KMS com o Amazon S3, consulte o Guia do usuário do Amazon Simple Storage Service (em inglês).

Ao ativar a criptografia padrão, talvez seja necessário atualizar a política do bucket. Para mais informações sobre como migrar das políticas de bucket para a criptografia padrão, consulte o Guia do usuário do Amazon Simple Storage Service.

CLI da AWS

Criar uma chave do KMS

aws kms create-key \
  --description "Key to encrypt S3 buckets"

Ativar a rotação de chaves

aws kms enable-key-rotation \
  --key-id <key_id_from_previous_command>

Atualizar bucket

aws s3api put-bucket-encryption \
  --bucket my-bucket \
  --server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"KMSMasterKeyID": "<id_from_key>", "SSEAlgorithm": "AES256"}}]}'

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Sagemaker Notebook Instance Kms Key Configured

Nome da categoria na API: SAGEMAKER_NOTEBOOK_INSTANCE_KMS_KEY_CONFIGURED

Verifica se uma chave do serviço de gerenciamento de chaves (AWS KMS) da AWS está configurada para uma instância de notebook do Amazon SageMaker. A regra é NÃO_EM_CONFORMIDADE se KmsKeyId não for especificado para a instância do notebook do SageMaker.

Recomendação: verifica se todas as instâncias de notebook do SageMaker foram definidas para usar o KMS

Para configurar o KMS para o SageMaker, consulte Gerenciamento de chaves na documentação do Amazon SageMaker.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Sagemaker Notebook No Direct Internet Access

Nome da categoria na API: SAGEMAKER_NOTEBOOK_NO_DIRECT_INTERNET_ACCESS

Verifica se o acesso direto à Internet está desativado para uma instância de notebook do SageMaker. Para fazer isso, ele verifica se o campo DirectInternetAccess está desativado para a instância do notebook.

Se você configurar sua instância do SageMaker sem uma VPC, o acesso direto à Internet será ativado por padrão. Configure sua instância com uma VPC e mude a configuração padrão para "Desativar": "Acessar a Internet por uma VPC".

Para treinar ou hospedar modelos em um notebook, você precisa de acesso à Internet. Para ativar o acesso à Internet, verifique se a VPC tem um gateway NAT e se o grupo de segurança permite conexões de saída. Para saber como conectar uma instância de notebook a recursos em uma VPC, consulte Conectar uma instância de notebook a recursos em uma VPC no Guia para desenvolvedores do Amazon SageMaker.

Além disso, é necessário garantir que o acesso à configuração do SageMaker seja limitado apenas a usuários autorizados. Restringir as permissões do IAM dos usuários para modificar as configurações e os recursos do SageMaker.

Recomendação: verifique se o acesso direto à Internet está desativado para todas as instâncias de notebook do Amazon SageMaker

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

Não é possível mudar a configuração de acesso à Internet depois que uma instância de notebook é criada. Ele precisa ser interrompido, excluído e recriado.

Para configurar uma instância de notebook do SageMaker para negar o acesso direto à Internet:

1. Abra o console do SageMaker em https://console.aws.amazon.com/sagemaker/.
2. Acesse as instâncias do notebook.
3. Exclua a instância que tem o acesso direto à Internet ativado. Selecione a instância, escolha "Ações" e "Parar".
4. Depois que a instância for interrompida, escolha "Ações" e "Excluir".
5. Escolha "Criar instância de notebook". Informe os detalhes da configuração.
6. Abra a seção de rede e escolha uma VPC, sub-rede e grupo de segurança. Em "Acesso direto à Internet", escolha "Desativar": "Acessar a Internet por uma VPC".
7. Escolha "Criar instância de notebook".

Para mais informações, consulte Conectar uma instância de notebook a recursos em uma VPC no guia para desenvolvedores do Amazon SageMaker.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Secretsmanager Rotation Enabled Check

Nome da categoria na API: SECRETSMANAGER_ROTATION_ENABLED_CHECK

Verifica se um secret armazenado no AWS Secrets Manager está configurado com a rotação automática. O controle falha se o secret não estiver configurado com a rotação automática. Se você fornecer um valor personalizado para o parâmetro maximumAllowedRotationFrequency, o controle só será aprovado se o segredo for rotacionado automaticamente dentro do período especificado.

O Secrets Manager ajuda a melhorar a postura de segurança da sua organização. Os secrets incluem credenciais de banco de dados, senhas e chaves de API de terceiros. É possível usar o Secrets Manager para armazenar secrets de forma centralizada, criptografar automaticamente, controlar o acesso a eles e fazer a rotação de forma segura e automática.

O Secrets Manager pode fazer a rotação de secrets. Você pode usar a rotação para substituir segredos de longo prazo por segredos de curto prazo. A rotação de segredos limita o tempo que um usuário não autorizado pode usar um segredo comprometido. Por esse motivo, faça a rotação dos seus secrets com frequência. Para saber mais sobre a rotação, consulte "Como rotacionar os secrets do AWS Secrets Manager" no Guia do usuário do AWS Secrets Manager.

Recomendação: verifica se todos os secrets do AWS Secrets Manager têm a rotação ativada

Para ativar a rotação automática de segredos do Secrets Manager, consulte Configurar a rotação automática de segredos do AWS Secrets Manager usando o console no Guia do usuário do AWS Secrets Manager. Você precisa escolher e configurar uma função do AWS Lambda para a rotação.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Sns Encrypted Kms

Nome da categoria na API: SNS_ENCRYPTED_KMS

Verifica se um tópico do SNS está criptografado em repouso usando o AWS KMS. Os controles falham se um tópico do SNS não usar uma chave KMS para criptografia do lado do servidor (SSE).

A criptografia de dados em repouso reduz o risco de acesso a dados armazenados em disco por um usuário não autenticado na AWS. Ele também adiciona outro conjunto de controles de acesso para limitar a capacidade de usuários não autorizados de acessar os dados. Por exemplo, as permissões da API são necessárias para descriptografar os dados antes que eles possam ser lidos. Os tópicos do SNS precisam ser criptografados em repouso para aumentar a segurança.

Recomendação: verifica se todos os tópicos do SNS foram criptografados com o KMS

Para ativar a SSE em um tópico do SNS, consulte "Como ativar a criptografia do lado do servidor (SSE) em um tópico do Amazon SNS" no Guia para desenvolvedores do Amazon Simple Notification Service. Antes de usar a SSE, você também precisa configurar as políticas de chaves do AWS KMS para permitir a criptografia de tópicos e a criptografia e descriptografia de mensagens. Para mais informações, consulte "Como configurar as permissões do AWS KMS" no Guia do desenvolvedor do Amazon Simple Notification Service.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Vpc Default Security Group Closed

Nome da categoria na API: VPC_DEFAULT_SECURITY_GROUP_CLOSED

Esse controle verifica se o grupo de segurança padrão de uma VPC permite tráfego de entrada ou saída. O controle falha se o grupo de segurança permitir tráfego de entrada ou saída.

As regras do grupo de segurança padrão permitem todo o tráfego de entrada e saída de interfaces de rede (e instâncias associadas) atribuídas ao mesmo grupo. Recomendamos que você não use o grupo de segurança padrão. Como o grupo de segurança padrão não pode ser excluído, mude a configuração de regras do grupo de segurança padrão para restringir o tráfego de entrada e saída. Isso evita o tráfego não intencional se o grupo de segurança padrão for configurado acidentalmente para recursos como instâncias do EC2.

Recomendação: verifique se o grupo de segurança padrão de cada VPC restringe todo o tráfego

Para corrigir esse problema, comece criando novos grupos de segurança com privilégios mínimos. Para instruções, consulte Criar um grupo de segurança no guia do usuário da Amazon VPC. Em seguida, atribua os novos grupos de segurança às suas instâncias do EC2. Para ver instruções, consulte Alterar o grupo de segurança de uma instância no guia do usuário do Amazon EC2 para instâncias do Linux.

Depois de atribuir os novos grupos de segurança aos seus recursos, remova todas as regras de entrada e saída dos grupos de segurança padrão. Para instruções, consulte Excluir regras de grupos de segurança no guia do usuário da Amazon VPC.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Vpc Flow Logging Enabled All Vpcs

Nome da categoria na API: VPC_FLOW_LOGGING_ENABLED_ALL_VPCS

Os registros de fluxo da VPC são um recurso que permite capturar informações sobre o tráfego de IP de e para interfaces de rede na VPC. Depois de criar um registro de fluxo, você pode conferir e recuperar os dados dele nos Logs do Amazon CloudWatch. É recomendável ativar os registros de fluxo de VPC para "Rejeições" de pacotes de VPCs.

Recomendação: verifique se a geração de registros do fluxo de VPC está ativada em todas as VPCs

Para corrigir essa descoberta, siga estas etapas:

Console da AWS

1. Fazer login no console de gerenciamento
2. Selecione Services e VPC
3. No painel de navegação à esquerda, selecione Your VPCs.
4. Selecionar uma VPC
5. No painel à direita, selecione a guia Flow Logs.
6. Se não houver um registro de fluxo, clique em Create Flow Log.
7. Em "Filtro", selecione Reject.
8. Insira um Role e Destination Log Group
9. Clique em Create Log Flow.
10. Clique em CloudWatch Logs Group

Observação:definir o filtro como "Rejeitar" reduz drasticamente o acúmulo de dados de registro para essa recomendação e fornece informações suficientes para fins de detecção, investigação e correção de violações. No entanto, durante períodos de engenharia de grupo de segurança de privilégio mínimo, definir o filtro como "Todos" pode ser muito útil para descobrir fluxos de tráfego necessários para o funcionamento adequado de um ambiente já em execução.

CLI da AWS

1. Crie um documento de política e nomeie-o como role_policy_document.json. Em seguida, cole o seguinte conteúdo:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "test",
 "Effect": "Allow",
 "Principal": {
 "Service": "ec2.amazonaws.com"
 },
 "Action": "sts:AssumeRole"
 }
 ]
}

2. Crie outro documento de política e nomeie-o como iam_policy.json e cole o seguinte conteúdo:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action":[
 "logs:CreateLogGroup",
 "logs:CreateLogStream",
 "logs:DescribeLogGroups",
 "logs:DescribeLogStreams",
 "logs:PutLogEvents",
 "logs:GetLogEvents",
 "logs:FilterLogEvents"
 ],
 "Resource": "*"
 }
 ]
}

3. Execute o comando abaixo para criar um papel do IAM:

aws iam create-role --role-name <aws_support_iam_role> --assume-role-policy-document file://<file-path>role_policy_document.json

4. Execute o comando abaixo para criar uma política do IAM:

aws iam create-policy --policy-name <ami-policy-name> --policy-document file://<file-path>iam-policy.json

5. Execute o comando attach-group-policy usando o ARN da política do IAM retornado na etapa anterior para anexar a política ao papel do IAM. Se o comando for bem-sucedido, nenhuma saída será retornada:

aws iam attach-group-policy --policy-arn arn:aws:iam::<aws-account-id>:policy/<iam-policy-name> --group-name <group-name>

6. Execute describe-vpcs para disponibilizar o VpcId na região selecionada:

aws ec2 describe-vpcs --region <region>

7. A resposta ao comando vai retornar o ID da VPC disponível na região selecionada.
8. Execute create-flow-logs para criar um registro de fluxo para a VPC:

aws ec2 create-flow-logs --resource-type VPC --resource-ids <vpc-id> --traffic-type REJECT --log-group-name <log-group-name> --deliver-logs-permission-arn <iam-role-arn>

9. Repita a etapa 8 para outras VPCs disponíveis na região selecionada.
10. Mude a região atualizando --region e repita o procedimento de correção para outras VPCs.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Vpc Sg Open Only To Authorized Ports

Nome da categoria na API: VPC_SG_OPEN_ONLY_TO_AUTHORIZED_PORTS

Esse controle verifica se um grupo de segurança do Amazon EC2 permite tráfego de entrada irrestrito de portas não autorizadas. O status do controle é determinado da seguinte maneira:

Se você usar o valor padrão para authorizedTcpPorts, o controle vai falhar se o grupo de segurança permitir tráfego de entrada irrestrito de qualquer porta, exceto as portas 80 e 443.

Se você fornecer valores personalizados para authorizedTcpPorts ou authorizedUdpPorts, o controle vai falhar se o grupo de segurança permitir tráfego de entrada irrestrito de qualquer porta não listada.

Se nenhum parâmetro for usado, o controle vai falhar para qualquer grupo de segurança que tenha uma regra de tráfego de entrada irrestrita.

Os grupos de segurança fornecem filtragem stateful do tráfego de entrada e saída da rede para a AWS. As regras de grupo de segurança precisam seguir o princípio do menor privilégio. O acesso irrestrito (endereço IP com sufixo /0) aumenta a oportunidade de atividades maliciosas, como invasão, ataques de negação de serviço e perda de dados. A menos que uma porta seja especificamente permitida, ela precisa negar o acesso irrestrito.

Recomendação: verifica se os grupos de segurança com 0.0.0.0/0 de qualquer VPC permitem apenas o tráfego TCP/UDP de entrada

Para modificar um grupo de segurança, consulte Trabalhar com grupos de segurança no guia do usuário da Amazon VPC.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.

Both VPC VPN Tunnels Up

Nome da categoria na API: VPC_VPN_2_TUNNELS_UP

Um túnel de VPN é um link criptografado em que os dados podem passar da rede do cliente para a AWS ou vice-versa em uma conexão de VPN site a site da AWS. Cada conexão VPN inclui dois túneis VPN que podem ser usados simultaneamente para alta disponibilidade. É importante garantir que os dois túneis VPN estejam ativos para uma conexão VPN e confirmar uma conexão segura e altamente disponível entre uma VPC da AWS e sua rede remota.

Esse controle verifica se os dois túneis VPN fornecidos pela AWS Site-to-Site VPN estão no status UP. O controle falha se um ou ambos os túneis estiverem no status "DOWN".

Recomendação: verifica se ambos os túneis VPN da AWS fornecidos pela AWS site a site estão no status UP

Para modificar as opções de túnel de VPN, consulte Modificar as opções de túnel de VPN site a site no Guia do usuário da VPN site a site da AWS.

Saiba mais sobre os recursos e configurações de verificação compatíveis com esse tipo de descoberta.