Corrigir as conclusões da análise do estado de funcionamento da segurança

Níveis de serviço Standard, Premium e Enterprise

Esta página fornece uma lista de guias de referência e técnicas para corrigir as conclusões do Security Health Analytics através do Security Command Center.

Precisa de funções de gestão de identidade e de acesso (IAM) adequadas para ver ou editar descobertas e para aceder ou modificar Google Cloud recursos. Se encontrar erros de autorizações ao aceder ao Security Command Center naGoogle Cloud consola, peça ajuda ao seu administrador e, para saber mais sobre as funções, consulte o artigo Controlo de acesso. Para resolver erros de recursos, leia a documentação dos produtos afetados.

Nota: se for cliente do nível Premium e planear mudar para o nível Standard, recomendamos que resolva todas as conclusões antes de alterar o seu nível. Não é possível resolver automaticamente as conclusões comunicadas pelos detetores Premium no nível Standard. Para mais informações, consulte o artigo Mudar de nível.

Remediação da análise do estado de segurança

Esta secção inclui instruções de remediação para todas as conclusões do Security Health Analytics.

Para encontrar tipos mapeados para as referências do CIS, as orientações de remediação provêm do Center for Internet Security (CIS), exceto indicação em contrário. Para mais informações, consulte o artigo Detetores e conformidade.

Aviso: se forem feitas incorretamente, as alterações à configuração dos seus recursos podem afetar negativamente o ambiente de produção. Além disso, a ativação de alguns serviços Google Cloud sugeridos pode aumentar os seus custos na nuvem. Compreenda o impacto de todos os passos de remediação antes de fazer alterações.

Desativação automática das descobertas

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 procurar a descoberta. A desativação de um detetor no Security Health Analytics também define o estado de todas as conclusões geradas por esse detetor como INACTIVE. O tempo que o Security Health Analytics demora a definir uma descoberta corrigida como INACTIVE depende do momento em que a descoberta é corrigida e da programação da análise que deteta a descoberta.

O Security Health Analytics também define o estado de uma conclusão como INACTIVE quando uma análise deteta que o recurso afetado pela conclusão foi eliminado. Se quiser remover uma descoberta de um recurso eliminado do seu ecrã enquanto aguarda que o Security Health Analytics detete que o recurso foi eliminado, pode desativar o som da descoberta. Para desativar o som de uma deteção, consulte o artigo Desative o som de deteções no Security Command Center.

Não use a opção Ignorar para ocultar as conclusões corrigidas para recursos existentes. Se o problema ocorrer novamente e o Security Health Analytics restaurar o estado da descoberta, pode não ver a descoberta reativada, porque as descobertas ignoradas são excluídas de qualquer consulta de descoberta que especifique NOT mute="MUTED", como a consulta de descoberta predefinida.ACTIVE

Para obter informações sobre os intervalos de análise, consulte o artigo Tipos de análise do Security Health Analytics.

Access Transparency disabled

Nome da categoria na API: ACCESS_TRANSPARENCY_DISABLED

Registar a Transparência de acesso quando os Google Cloud funcionários acedem aos projetos na sua organização para fornecer apoio técnico. Ative a Transparência de acesso para registar quem da Google Cloud está a aceder às suas informações, quando e porquê. Para mais informações, consulte o artigo Transparência de acesso.

Para ativar a Transparência de acesso num projeto, o projeto tem de estar associado a uma conta de faturação.

Funções necessárias

Para receber as autorizações de que precisa para realizar esta tarefa, peça ao seu administrador para lhe conceder a função do IAM Administrador da Transparência de acesso (roles/axt.admin) ao nível da organização. Para mais informações sobre como atribuir funções, consulte o artigo Faça a gestão do acesso.

Esta função predefinida contém as autorizações axt.labels.get e axt.labels.set, que são necessárias para realizar esta tarefa. Também pode conseguir estas autorizações com uma função personalizada ou outras funções predefinidas.

Passos de remediação

Para corrigir esta descoberta, conclua os seguintes passos:

1. Verifique as autorizações ao nível da organização:

   1. Aceda à página Identity and Access Management na Google Cloud consola.

      Aceda à Gestão de identidade e acesso

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

2. Selecione qualquer Google Cloud projeto na organização através do menu do seletor.

   A Transparência de acesso está configurada numa página de Google Cloud projeto, mas está ativada para toda a organização.

3. Aceda à página IAM e administrador > Definições.

4. Clique em Ativar transparência de acesso.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 cópias de segurança automáticas ativadas.

Para ajudar a evitar a perda de dados, ative as cópias de segurança automáticas para o seu cluster. Para mais informações, consulte o artigo Configure cópias de segurança automáticas adicionais.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página de clusters do AlloyDB for PostgreSQL na Google Cloud consola.

   Aceda aos clusters do AlloyDB para PostgreSQL

2. Clique num cluster na coluna Nome do recurso.

3. Clique em Proteção de dados.

4. Na secção Política de cópia de segurança automática, clique em Editar na linha Cópias de segurança automáticas.

5. Selecione a caixa de verificação Automatizar cópias de segurança.

6. Clique em Atualizar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

AlloyDB backups disabled

Nome da categoria na API: ALLOYDB_BACKUPS_DISABLED

Um cluster do AlloyDB for PostgreSQL não tem cópias de segurança automáticas nem contínuas ativadas.

Para ajudar a evitar a perda de dados, ative as cópias de segurança automáticas ou contínuas para o cluster. Para mais informações, consulte o artigo Configure cópias de segurança adicionais.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página de clusters do AlloyDB for PostgreSQL na Google Cloud consola.

   Aceda aos clusters do AlloyDB para PostgreSQL

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

3. Clique em Proteção de dados.

4. Configure uma política de cópia de segurança.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

AlloyDB CMEK disabled

Nome da categoria na API: ALLOYDB_CMEK_DISABLED

Um cluster do AlloyDB não está a usar chaves de encriptação geridas pelo cliente (CMEK).

Com as CMEK, as chaves que cria e gere no Cloud KMS envolvem as chaves que a Google usa para encriptar os seus dados, o que lhe dá mais controlo sobre o acesso aos seus dados. Para mais informações, consulte o artigo Acerca das CMEK. A CMEK incorre em custos adicionais relacionados com o Cloud KMS.

Atenção: estes passos de remediação podem interromper o seu ambiente de produção. Se for necessário, transfira cargas de trabalho, dados ou autorizações para novos recursos antes de eliminar recursos existentes.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página de clusters do AlloyDB for PostgreSQL na Google Cloud consola.

   Aceda aos clusters do AlloyDB para PostgreSQL

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

3. Clique em Criar cópia de segurança. Defina um ID alternativo.

4. Clique em Criar.

5. Na secção Cópia de segurança/restauro, clique em Restaurar junto à entrada do ID da cópia de segurança que escolheu.

6. Definir um novo ID do cluster e rede.

7. Clique em Opções de encriptação avançadas. Selecione a CMEK com a qual quer encriptar o novo cluster.

8. Clique em Restaurar.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 log_min_error_statementdatabase definida como error ou outro valor recomendado.

A flag log_min_error_statement controla se as declarações SQL que causam condições de erro são registadas nos registos do servidor. As declarações SQL da gravidade especificada ou superior são registadas. Quanto maior for a gravidade, menor é o número de mensagens registadas. Se for definido para um nível de gravidade demasiado elevado, as mensagens de erro podem não ser registadas.

Para mais informações, consulte o artigo Configurar flags de base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página de clusters do AlloyDB for PostgreSQL na Google Cloud consola.

   Aceda aos clusters do AlloyDB para PostgreSQL

2. Clique no cluster na coluna Nome do recurso.

3. Na secção Instâncias no cluster, clique em Editar para a instância.

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

5. Na secção Flags, defina a flag da base de dados log_min_error_statement com um dos seguintes valores recomendados, de acordo com a política de registo da sua organização.

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

6. Clique em Atualizar instância.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 base de dados definida, no mínimo, como warning.log_min_messages

A flag log_min_messages controla os níveis de mensagens que são registados nos registos do servidor. Quanto maior for a gravidade, menor é o número de mensagens registadas. Se definir o limite demasiado baixo, pode aumentar o tamanho e a duração do armazenamento de registos, o que dificulta a localização de erros reais.

Para mais informações, consulte o artigo Configurar flags de base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página de clusters do AlloyDB for PostgreSQL na Google Cloud consola.

   Aceda aos clusters do AlloyDB para PostgreSQL

2. Clique no cluster na coluna Nome do recurso.

3. Na secção Instâncias no cluster, clique em Editar para a instância.

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

5. Na secção Flags, defina a flag da base de dados log_min_messages com um dos seguintes valores recomendados, de acordo com a política de registo da sua organização.

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

6. Clique em Atualizar instância.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 base de dados log_error_verbosity definida como default ou outro valor menos restritivo.

A flag log_error_verbosity controla o nível de detalhe nas mensagens registadas. Quanto maior for a verbosidade, mais detalhes são registados nas mensagens. Recomendamos que defina esta flag como default ou outro valor menos restritivo.

Para mais informações, consulte o artigo Configurar flags de base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página de clusters do AlloyDB for PostgreSQL na Google Cloud consola.

   Aceda aos clusters do AlloyDB para PostgreSQL

2. Clique no cluster na coluna Nome do recurso.

3. Na secção Instâncias no cluster, clique em Editar para a instância.

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

5. Na secção Flags, defina a flag da base de dados log_error_verbosity com um dos seguintes valores recomendados, de acordo com a política de registo da sua organização.

   • default
   • verbose

6. Clique em Atualizar instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

AlloyDB Public IP

Nome da categoria na API: ALLOYDB_PUBLIC_IP

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

Para reduzir a superfície de ataque da sua organização, use endereços IP privados em vez de públicos. Os endereços IP privados oferecem uma segurança de rede melhorada e uma latência inferior para a sua aplicação.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página de clusters do AlloyDB for PostgreSQL na Google Cloud consola.

   Aceda aos clusters do AlloyDB para PostgreSQL

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

3. Na secção Instâncias no cluster, clique em Editar para a instância.

4. Na secção Conetividade, desmarque a caixa Ativar IP público.

5. Clique em Atualizar instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

AlloyDB SSL not enforced

Nome da categoria na API: ALLOYDB_SSL_NOT_ENFORCED

Uma instância de base de dados do AlloyDB para PostgreSQL não requer que todas as ligações recebidas usem SSL.

Para evitar a divulgação de dados confidenciais em trânsito através de comunicações não encriptadas, todas as ligações recebidas à instância da base de dados do AlloyDB devem usar SSL. Saiba mais sobre a configuração do SSL/TLS.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página de clusters do AlloyDB for PostgreSQL na Google Cloud consola.

   Aceda aos clusters do AlloyDB para PostgreSQL

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

3. Na secção Instâncias no cluster, clique em Editar para a instância.

4. Na secção Segurança de rede, clique na caixa para Exigir encriptação SSL.

5. Clique em Atualizar instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Admin service account

Nome da categoria na API: ADMIN_SERVICE_ACCOUNT

Uma conta de serviço na sua organização ou projeto tem privilégios de administrador, proprietário ou editor atribuídos. Estas funções têm autorizações amplas e não devem ser atribuídas a contas de serviço. Para saber mais sobre as contas de serviço e as funções disponíveis para as mesmas, consulte o artigo Contas de serviço.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página da política IAM na Google Cloud consola.

   Aceder à política IAM

2. Para cada principal identificado na descoberta:

   1. Clique em Editar principal junto ao principal.
   2. Para remover autorizações, clique em Eliminar função junto à função.
   3. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Alpha cluster enabled

Nome da categoria na API: ALPHA_CLUSTER_ENABLED

As funcionalidades do cluster alfa estão ativadas para um cluster do Google Kubernetes Engine (GKE).

Os clusters alfa permitem que os primeiros utilizadores experimentem cargas de trabalho que usam novas funcionalidades antes de serem lançadas para o público em geral. Os clusters alfa têm todas as funcionalidades da API GKE ativadas, mas não estão cobertos pelo ANS do GKE, não recebem atualizações de segurança, têm a atualização automática de nós e a reparação automática de nós desativadas e não podem ser atualizados. Também são eliminados automaticamente após 30 dias.

Atenção: estes passos de remediação podem interromper o seu ambiente de produção. Se for necessário, transfira cargas de trabalho, dados ou autorizações para novos recursos antes de eliminar recursos existentes.

Para corrigir esta descoberta, conclua os seguintes passos:

Não é possível desativar os clusters alfa. Tem de criar um novo cluster com as funcionalidades alfa desativadas.

1. Aceda à página Clusters do Kubernetes na Google Cloud consola.

   Aceda aos clusters do Kubernetes

2. Clique em Criar.

3. Selecione Configurar junto ao tipo de cluster que quer criar.

4. No separador Features, certifique-se de que a opção Enable Kubernetes alpha features in this cluster está desativada.

   Nota: se selecionou o GKE Autopilot, não verá esta opção porque os clusters alfa não são suportados.

5. Clique em Criar.

6. Para mover cargas de trabalho para o novo cluster, consulte o artigo Migrar cargas de trabalho para diferentes tipos de máquinas.

7. Para eliminar o cluster original, consulte a secção Eliminar um cluster.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

API key APIs unrestricted

Nome da categoria na API: API_KEY_APIS_UNRESTRICTED

As chaves da API estão a ser usadas de forma demasiado ampla.

As chaves da API não restritas são inseguras porque podem ser obtidas a partir de dispositivos nos quais a chave está armazenada ou podem ser vistas publicamente, por exemplo, a partir de um navegador. De acordo com o princípio do menor privilégio, configure as chaves da API para chamar apenas as APIs necessárias pela aplicação. Para mais informações, consulte o artigo Aplique restrições de chaves da API.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Chaves de API na Google Cloud consola.

   Aceda a Chaves da API

2. Para cada chave da API:

   1. Na secção Chaves da API, na linha de cada chave da API para a qual tem de restringir APIs, clique em Ações.
   2. No menu Ações, clique em Editar chave da API. É apresentada a página Editar chave da API.
   3. Na secção Restrições de API, selecione Restringir APIs. É apresentado o menu pendente Selecionar APIs.
   4. Na lista pendente Selecionar APIs, selecione as APIs a permitir.
      Aviso: não defina restrições de API para as APIs Google Cloud, uma vez que permite o acesso a todos os serviços oferecidos pela Google Cloud.
   5. Clique em Guardar. As definições podem demorar até cinco minutos a entrar em vigor.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

API key apps unrestricted

Nome da categoria na API: API_KEY_APPS_UNRESTRICTED

Estão a ser usadas chaves da API de forma não restrita, o que permite a utilização por qualquer app não fidedigna.

As chaves da API não restritas são inseguras porque podem ser obtidas em dispositivos nos quais a chave está armazenada ou podem ser vistas publicamente, por exemplo, a partir de um navegador. De acordo com o princípio do menor privilégio, restrinja a utilização de chaves da API a anfitriões, referenciadores HTTP e apps fidedignos. Para mais informações, consulte o artigo Aplique restrições de chaves da API.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Chaves de API na Google Cloud consola.

   Aceda a Chaves da API

2. Para cada chave da API:

   1. Na secção Chaves da API, na linha de cada chave da API para a qual precisa de restringir aplicações, clique em Ações.
   2. No menu Ações, clique em Editar chave da API. É apresentada a página Editar chave da API.
   3. Na página Editar chave da API, em Restrições de aplicações, selecione uma categoria de restrição. Pode definir uma restrição de aplicação por chave.
   4. No campo Adicionar um item apresentado quando seleciona uma restrição, clique em Adicionar um item para adicionar restrições com base nas necessidades da sua aplicação.
   5. Quando terminar de adicionar itens, clique em Concluído.
      Aviso: não defina referenciadores HTTP para carateres universais que permitam o acesso a quaisquer/vários referenciadores HTTP, por exemplo, *, *.[TLD] ou .[TLD]/*). Não defina endereços IP nem referenciadores para permitir qualquer anfitrião (0.0.0.0, ::0 ou 0.0.0.0/0).
   6. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

API key exists

Nome da categoria na API: API_KEY_EXISTS

Um projeto está a usar chaves da API em vez da autenticação padrão.

As chaves da API são menos seguras do que outros métodos de autenticação porque são strings encriptadas simples e fáceis de descobrir e usar por outras pessoas. Podem ser obtidas em dispositivos nos quais a chave está armazenada ou podem ser vistas publicamente, por exemplo, a partir de um navegador. Além disso, as chaves de API não identificam de forma exclusiva os utilizadores nem as aplicações que fazem pedidos. Em alternativa, pode usar um fluxo de autenticação padrão com contas de serviço ou contas de utilizador.

Atenção: estes passos de remediação podem interromper o seu ambiente de produção. Se for necessário, transfira cargas de trabalho, dados ou autorizações para novos recursos antes de eliminar recursos existentes.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Certifique-se de que as suas aplicações estão configuradas com uma forma alternativa de autenticação.

2. Aceda à página Credenciais da API na Google Cloud consola.

   Aceda às credenciais da API

3. Na secção Chaves da API, na linha de cada chave da API que tem de eliminar, clique em Ações.

4. No menu Ações, clique em Eliminar chave da API.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

API key not rotated

Nome da categoria na API: API_KEY_NOT_ROTATED

Uma chave da API não é alterada há mais de 90 dias.

As chaves de API não expiram. Por isso, se uma for roubada, pode ser usada indefinidamente, a menos que o proprietário do projeto revogue ou altere a chave. A rotação frequente das chaves da API reduz o tempo durante o qual uma chave da API roubada pode ser usada para aceder a dados numa conta comprometida ou terminada. Alterne as chaves da API, pelo menos, a cada 90 dias. Para mais informações, consulte o artigo Práticas recomendadas para gerir chaves da API.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Chaves de API na Google Cloud consola.

   Aceda a Chaves da API

2. Para cada chave da API:

   1. Na secção Chaves da API, na linha de cada chave da API que precisa de rodar, clique em Ações.
   2. No menu Ações, clique em Editar chave da API. É apresentada a página Editar chave da API.
   3. Na página Editar chave da API, se a data no campo Data de criação for anterior a 90 dias, clique em Rodar chave. É gerada uma nova chave.
   4. Opcionalmente, altere o nome da chave API.
   5. Clique em Criar.
   6. Atualize as suas aplicações para usar a nova chave.
   7. Depois de atualizar as suas aplicações, regresse à página Editar chave da API e clique em Eliminar chave anterior para eliminar a chave antiga. A chave antiga não é eliminada automaticamente.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Audit config not monitored

Nome da categoria na API: AUDIT_CONFIG_NOT_MONITORED

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

O Cloud Logging produz registos de atividade do administrador e de acesso aos dados que permitem a análise de segurança, a monitorização de alterações aos recursos e a auditoria de conformidade. Ao monitorizar as alterações à configuração de auditoria, garante que todas as atividades no seu projeto podem ser auditadas em qualquer altura. Para mais informações, consulte o artigo Vista geral das métricas baseadas em registos.

Consoante a quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para compreender a sua utilização do serviço e os respetivos custos, consulte os preços da observabilidade do Google Cloud.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

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

Crie uma métrica

1. Aceda à página Métricas baseadas em registos na Google Cloud consola.

   Aceda a Métricas baseadas em registos

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 registo.
   2. Adicione uma descrição.
   3. Defina Unidades como 1.

5. Em Seleção de filtros, copie e cole o seguinte texto 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. É apresentada uma confirmação.

Crie uma política de alerta

1. Na Google Cloud consola, aceda à página Métricas baseadas em registos:

   Aceda a Métricas baseadas em registos

   Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cuja legenda é Registo.

2. Na secção Métricas definidas pelo utilizador, selecione a métrica que criou na secção anterior.

3. Clique em Mais e, de seguida, clique em Criar alerta a partir da métrica.

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

4. Clicar em Seguinte.
   1. Reveja as definições pré-preenchidas. É recomendável modificar o Valor do limite.
   2. Clique em Nome da condição e introduza um nome para a condição.
5. Clicar em Seguinte.

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, de seguida, clique em OK.

   Para receber uma notificação quando os incidentes são abertos e fechados, selecione a opção Notificar no encerramento do incidente. Por predefinição, as notificações são enviadas apenas quando são abertos incidentes.

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

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Audit logging disabled

Nome da categoria na API: AUDIT_LOGGING_DISABLED

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

O registo de auditoria está desativado para um ou mais Google Cloud serviços ou um ou mais principais estão isentos do registo de auditoria de acesso aos dados.

Ative o Cloud Logging para todos os serviços para acompanhar todas as atividades de administração, o acesso de leitura e o acesso de escrita aos dados do utilizador. Consoante a quantidade de informações, os custos do Cloud Logging podem ser significativos. Para compreender a sua utilização do serviço e o respetivo custo, consulte os preços do Google Cloud Observability.

Se algum principal estiver isento do registo de auditoria de acesso aos dados na configuração de registo de auditoria de acesso aos dados predefinida ou nas configurações de registo de quaisquer serviços individuais, remova a isenção.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Configuração predefinida dos registos de auditoria de acesso aos dados na Google Cloud consola.

   Aceda à configuração predefinida

2. No separador Tipos de registos, ative o registo de auditoria de acesso a dados na configuração predefinida:

   1. Selecione Leitura de administrador, Leitura de dados e Escrita de dados.
   2. Clique em Guardar.

3. No separador Principais isentos, remova todos os utilizadores isentos da configuração predefinida:

   1. Remova cada principal listado clicando em Eliminar junto a cada nome.
   2. Clique em Guardar.

4. Aceda à página Registos de auditoria.

   Aceder aos registos de auditoria

5. Remova todos os responsáveis isentos das configurações do registo de auditoria de acesso a dados de serviços individuais.

   1. Em Configuração dos registos de auditoria de acesso a dados, para cada serviço que mostre um principal isento, clique no serviço. É aberto um painel de configuração do registo de auditoria para o serviço.
   2. No separador Diretores isentos, remova todos os diretores isentos clicando em Eliminar junto a cada nome.
   3. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Auto backup disabled

Nome da categoria na API: AUTO_BACKUP_DISABLED

Uma base de dados do Cloud SQL não tem as cópias de segurança automáticas ativadas.

Para evitar a perda de dados, ative as cópias de segurança automáticas para as suas instâncias SQL. Para mais informações, consulte o artigo Criar e gerir cópias de segurança automáticas e a pedido.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Na Google Cloud consola, aceda à página Instâncias do Cloud SQL.

   Aceda a Instâncias

2. Clique no nome da instância.

3. Clique em Cópias de segurança.

4. Junto a Definições, clique em Editar.

5. Selecione a caixa de verificação Cópias de segurança diárias automáticas.

6. Opcional: na caixa Número de dias, introduza o número de dias de cópias de segurança que quer reter.

7. Opcional: na lista Período de cópia de segurança, selecione o período em que quer fazer cópias de segurança.

8. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Auto repair disabled

Nome da categoria na API: AUTO_REPAIR_DISABLED

A funcionalidade de autorreparação de um cluster do Google Kubernetes Engine (GKE), que mantém os nós num estado de funcionamento saudável, está desativada.

Quando ativado, o GKE faz verificações periódicas do estado de funcionamento de cada nó no seu cluster. Se um nó falhar verificações de estado consecutivas durante um período prolongado, o GKE inicia um processo de reparação para esse nó. Para mais informações, consulte o artigo Nós de autorreparação.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Clusters do Kubernetes na Google Cloud consola.

   Aceda aos clusters do Kubernetes

2. Clique no separador Nós.

3. Para cada conjunto de nós:

   1. Clique no nome do conjunto de nós para aceder à respetiva página de detalhes.
   2. Clique em Editar.
   3. Em Gestão, selecione Ativar reparação automática.
   4. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Auto upgrade disabled

Nome da categoria na API: AUTO_UPGRADE_DISABLED

A funcionalidade de atualização automática de um cluster do GKE, que mantém os clusters e os node pools na versão estável mais recente do Kubernetes, está desativada.

Para mais informações, consulte o artigo Atualizar nós automaticamente.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Clusters do Kubernetes na Google Cloud consola.

   Aceda aos clusters do Kubernetes

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

3. Clique no separador Nós.

4. Para cada conjunto de nós:

   1. Clique no nome do conjunto de nós para aceder à respetiva página de detalhes.
   2. Clique em Editar.
   3. Em Gestão, selecione Ativar atualização automática.
   4. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 encriptação gerida pelo cliente (CMEK).

Com as CMEK, as chaves que cria e gere no Cloud KMS envolvem as chaves que o Google Cloud usa para encriptar os seus dados, o que lhe dá mais controlo sobre o acesso aos seus dados. Google Cloud Para mais informações, consulte o artigo Proteger dados com chaves do Cloud KMS.

Aviso: estes passos de remediação podem interromper o seu ambiente de produção. Se for necessário, transfira cargas de trabalho, dados ou autorizações para novos recursos antes de eliminar recursos existentes.

Para corrigir esta descoberta, conclua os seguintes passos:

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

Para definir uma chave CMEK predefinida que encripta todas as novas tabelas num conjunto de dados, consulte o artigo Defina uma chave predefinida do conjunto de dados.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Binary authorization disabled

Nome da categoria na API: BINARY_AUTHORIZATION_DISABLED

A Autorização binária está desativada num cluster do GKE.

A autorização binária inclui uma funcionalidade opcional que protege a segurança da cadeia de fornecimento, permitindo apenas que as imagens de contentores assinadas por autoridades fidedignas durante o processo de desenvolvimento sejam implementadas no cluster. Ao aplicar a implementação baseada em assinaturas, obtém um controlo mais rigoroso sobre o ambiente do contentor, garantindo que apenas as imagens validadas podem ser implementadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Clusters do Kubernetes na Google Cloud consola.

   Aceda aos clusters do Kubernetes

2. Na secçã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 pode estar desativado. Se não conseguir editar as definições do cluster, aguarde alguns minutos e tente novamente.

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

4. Clique em Guardar alterações.

5. Aceda à página de configuração da autorização binária.

   Aceda à Autorização binária

6. Certifique-se de que está configurada uma política que requer atestadores e que a regra predefinida do projeto não está configurada como Permitir todas as imagens. Para mais informações, consulte o artigo Configure para o GKE.

   Para garantir que as imagens que violam a política podem ser implementadas e que as violações são registadas nos registos de auditoria da nuvem, pode ativar o modo de teste.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Bucket CMEK disabled

Nome da categoria na API: BUCKET_CMEK_DISABLED

Um contentor não está encriptado com chaves de encriptação geridas pelo cliente (CMEK).

A definição de uma CMEK predefinida num contentor dá-lhe mais controlo sobre o acesso aos seus dados. Para mais informações, consulte o artigo Chaves de encriptação geridas pelo cliente.

Para corrigir esta descoberta, use as CMEK com um contentor seguindo as instruções em Usar chaves de encriptação geridas pelo cliente. A CMEK incorre em custos adicionais relacionados com o Cloud KMS.

Nota: a definição de uma chave predefinida não volta a encriptar retroativamente os objetos atualmente no contentor com uma nova chave.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Bucket IAM not monitored

Nome da categoria na API: BUCKET_IAM_NOT_MONITORED

As métricas e os alertas de registo não estão configurados para monitorizar as alterações de autorizações da IAM do Cloud Storage.

A monitorização das alterações às autorizações dos contentores do Cloud Storage ajuda a identificar utilizadores com privilégios excessivos ou atividade suspeita. Para mais informações, consulte o artigo Vista geral das métricas baseadas em registos.

Consoante a quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para compreender a sua utilização do serviço e os respetivos custos, consulte os preços da observabilidade do Google Cloud.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta descoberta, conclua os seguintes passos:

Crie uma métrica

1. Aceda à página Métricas baseadas em registos na Google Cloud consola.

   Aceda a Métricas baseadas em registos

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 registo.
   2. Adicione uma descrição.
   3. Defina Unidades como 1.

5. Em Seleção de filtros, copie e cole o seguinte texto 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. É apresentada uma confirmação.

Crie uma política de alerta

1. Na Google Cloud consola, aceda à página Métricas baseadas em registos:

   Aceda a Métricas baseadas em registos

   Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cuja legenda é Registo.

2. Na secção Métricas definidas pelo utilizador, selecione a métrica que criou na secção anterior.

3. Clique em Mais e, de seguida, clique em Criar alerta a partir da métrica.

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

4. Clicar em Seguinte.
   1. Reveja as definições pré-preenchidas. É recomendável modificar o Valor do limite.
   2. Clique em Nome da condição e introduza um nome para a condição.
5. Clicar em Seguinte.

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, de seguida, clique em OK.

   Para receber uma notificação quando os incidentes são abertos e fechados, selecione a opção Notificar no encerramento do incidente. Por predefinição, as notificações são enviadas apenas quando são abertos incidentes.

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

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Bucket logging disabled

Nome da categoria na API: BUCKET_LOGGING_DISABLED

Existe um contentor de armazenamento sem o registo ativado.

Para ajudar a investigar problemas de segurança e monitorizar o consumo de armazenamento, ative os registos de acesso e as informações de armazenamento para os seus contentores do Cloud Storage. Os registos de acesso fornecem informações para todos os pedidos feitos num contentor especificado e os registos de armazenamento fornecem informações sobre o consumo de armazenamento desse contentor.

Para corrigir esta descoberta, configure o registo para o contentor indicado pela descoberta do Security Health Analytics, concluindo o guia Registos de utilização e registos de armazenamento.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Bucket policy only disabled

Nome da categoria na API: BUCKET_POLICY_ONLY_DISABLED

O acesso uniforme ao nível do contentor, anteriormente denominado apenas política do contentor, não está configurado.

O acesso uniforme ao nível do contentor simplifica o controlo de acesso ao contentor desativando as autorizações ao nível do objeto (ACLs). Quando ativadas, apenas as autorizações de IAM ao nível do contentor concedem acesso ao contentor e aos objetos que contém. Para mais informações, consulte o artigo Acesso uniforme ao nível do contentor.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página do navegador do Cloud Storage na Google Cloud consola.

   Aceda ao navegador do Cloud Storage

2. Na lista de contentores, clique no nome do contentor pretendido.

3. Clique no separador Configuração.

4. Em Autorizações, na linha de Controlo de acesso, clique em Editar modelo de controlo de acesso.

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

6. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Cloud Asset API disabled

Nome da categoria na API: CLOUD_ASSET_API_DISABLED

O serviço Cloud Asset Inventory não está ativado para o projeto.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Biblioteca de APIs na Google Cloud consola.

   Aceder à biblioteca de APIs

2. Pesquise Cloud Asset Inventory.

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

4. Certifique-se de que a opção API ativada é apresentada.

Cluster logging disabled

Nome da categoria na API: CLUSTER_LOGGING_DISABLED

O registo não está ativado para um cluster do GKE.

Para ajudar a investigar problemas de segurança e monitorizar a utilização, ative o Cloud Logging nos seus clusters.

Consoante a quantidade de informações, os custos do Cloud Logging podem ser significativos. Para compreender a sua utilização do serviço e o respetivo custo, consulte os preços do Google Cloud Observability.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Clusters do Kubernetes na Google Cloud consola.

   Aceda aos clusters do Kubernetes

2. Selecione o cluster indicado 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 pode estar desativado. Se não conseguir editar as definições do cluster, aguarde alguns minutos e tente novamente.

4. Na lista pendente Registo do Stackdriver antigo ou Monitorização do Stackdriver Kubernetes Engine, selecione Ativado.

   Estas opções não são compatíveis. Certifique-se de que usa apenas o Stackdriver Kubernetes Engine Monitoring ou o Legacy Stackdriver Logging com o Legacy Stackdriver Monitoring.

5. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Cluster monitoring disabled

Nome da categoria na API: CLUSTER_MONITORING_DISABLED

A monitorização está desativada nos clusters do GKE.

Para ajudar a investigar problemas de segurança e monitorizar a utilização, ative o Cloud Monitoring nos seus clusters.

Consoante a quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para compreender a sua utilização do serviço e os respetivos custos, consulte os preços da observabilidade do Google Cloud.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Clusters do Kubernetes na Google Cloud consola.

   Aceda aos clusters do Kubernetes

2. Selecione o cluster indicado 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 pode estar desativado. Se não conseguir editar as definições do cluster, aguarde alguns minutos e tente novamente.

4. Na lista pendente Legacy Stackdriver Monitoring ou Stackdriver Kubernetes Engine Monitoring, selecione Ativado.

   Estas opções não são compatíveis. Certifique-se de que usa apenas o Stackdriver Kubernetes Engine Monitoring ou o Legacy Stackdriver Monitoring com o Legacy Stackdriver Logging.

5. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Cluster private Google access disabled

Nome da categoria na API: CLUSTER_PRIVATE_GOOGLE_ACCESS_DISABLED

Os anfitriões de cluster não estão configurados para usar apenas endereços IP privados e internos para aceder às APIs Google.

O acesso privado à Google permite que as instâncias de máquinas virtuais (VM) com apenas endereços IP privados e internos alcancem os endereços IP públicos das APIs e dos serviços Google. Para mais informações, consulte o artigo Configurar o acesso privado da Google.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Redes de nuvem privada virtual na Google Cloud consola.

   Aceda a Redes de VPC

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

3. Na página Detalhes da rede VPC, clique no separador Sub-redes.

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

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

6. Em Acesso privado à Google, selecione Ativado.

7. Clique em Guardar.

8. Para remover IPs públicos (externos) de instâncias de VM cujo único tráfego externo se destina às APIs Google, consulte o artigo Desatribuir um endereço IP externo estático.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Cluster secrets encryption disabled

Nome da categoria na API: CLUSTER_SECRETS_ENCRYPTION_DISABLED

A encriptação de segredos da camada de aplicação está desativada num cluster do GKE.

A encriptação de Secrets na camada de aplicação garante que os Secrets do GKE são encriptados com chaves do Cloud KMS. A funcionalidade oferece uma camada de segurança adicional para dados confidenciais, como segredos definidos pelo utilizador e segredos necessários para o funcionamento do cluster, como chaves de contas de serviço, que são todos armazenados no etcd.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Chaves do Cloud KMS na Google Cloud consola.

   Aceda às chaves do Cloud KMS

2. Reveja as chaves da aplicação ou crie uma chave de encriptação de base de dados (DEK). Para mais informações, consulte o artigo Criar uma chave do Cloud KMS.

3. Aceda à página Clusters do Kubernetes.

   Aceda aos clusters do Kubernetes

4. Selecione o cluster na descoberta.

5. Em Segurança, no campo Encriptação de segredos da camada de aplicação, clique em Editar encriptação de segredos da camada de aplicação.

6. Selecione a caixa de verificação Ativar encriptação de segredos da camada de aplicação e, de seguida, escolha a DEK que criou.

7. Clique em Guardar alterações.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Cluster shielded nodes disabled

Nome da categoria na API: CLUSTER_SHIELDED_NODES_DISABLED

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

Sem os nós do GKE protegidos, os atacantes podem explorar uma vulnerabilidade num pod para roubar credenciais de arranque e roubar a identidade de nós no seu cluster. A vulnerabilidade pode dar aos atacantes acesso a segredos do cluster.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Clusters do Kubernetes na Google Cloud consola.

   Aceda aos clusters do Kubernetes

2. Selecione o cluster na descoberta.

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

4. Selecione a caixa de verificação Ativar nós do GKE protegidos.

5. Clique em Guardar alterações.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Compute project wide SSH keys allowed

Nome da categoria na API: COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED

São usadas chaves SSH ao nível do projeto, o que permite iniciar sessão em todas as instâncias do projeto.

A utilização de chaves SSH ao nível do projeto facilita a gestão de chaves SSH, mas, se forem comprometidas, representa um risco de segurança que pode afetar todas as instâncias num projeto. Deve usar chaves SSH específicas da instância, que limitam a superfície de ataque se as chaves SSH forem comprometidas. Para mais informações, consulte o artigo Faça a gestão de chaves SSH nos metadados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias de VM na Google Cloud consola.

   Aceder às 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.

   Nota: não pode editar instâncias criadas com modelos de instâncias. Para fazer alterações à configuração de um modelo de instância, consulte Como atualizar modelos de instância.

4. Em Chaves SSH, selecione Bloquear chaves SSH ao nível do projeto.

5. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Compute Secure Boot disabled

Nome da categoria na API: COMPUTE_SECURE_BOOT_DISABLED

Uma VM protegida não tem o arranque seguro ativado.

A utilização do Arranque seguro ajuda a proteger as suas máquinas virtuais contra rootkits e bootkits. O Compute Engine não ativa o arranque seguro por predefinição porque alguns controladores não assinados e software de baixo nível não são compatíveis. Se a sua MV não usar software incompatível e for iniciada com o Arranque seguro ativado, a Google recomenda a utilização do Arranque seguro. Se estiver a usar módulos de terceiros com controladores Nvidia, certifique-se de que são compatíveis com o arranque seguro antes de o ativar.

Para mais informações, consulte o artigo Arranque seguro.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias de VM na Google Cloud consola.

   Aceder às 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 Parar.

4. Depois de a instância parar, clique em Editar.

5. Em VM protegida, selecione Ativar arranque seguro.

6. Clique em Guardar.

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

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Compute serial ports enabled

Nome da categoria na API: COMPUTE_SERIAL_PORTS_ENABLED

As portas de série estão ativadas para uma instância, o que permite ligações à consola de série da instância.

Se ativar a consola série interativa numa instância, os clientes podem tentar estabelecer ligação a essa instância a partir de qualquer endereço IP. Por conseguinte, o suporte da consola série interativa deve ser desativado. Para mais informações, consulte o artigo Ativar o acesso para um projeto.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias de VM na Google Cloud consola.

   Aceder às 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 a opção Ativar ligação a portas de série.

5. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Confidential Computing disabled

Nome da categoria na API: CONFIDENTIAL_COMPUTING_DISABLED

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

A computação confidencial adiciona um terceiro pilar à história da encriptação ponto a ponto, encriptando os dados durante a utilização. Com os ambientes de execução confidenciais fornecidos pela computação confidencial e pela virtualização encriptada segura da AMD (SEV), Google Cloud mantém o código sensível e outros dados encriptados na memória durante o processamento.

A computação confidencial só pode ser ativada quando uma instância é criada. Assim, tem de eliminar a instância atual e criar uma nova.

Para mais informações, consulte o artigo Máquina virtual confidencial e Compute Engine.

Nota: a computação confidencial só é suportada em tipos de máquinas N2D.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias de VM na Google Cloud consola.

   Aceder às 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 Eliminar.

4. Crie uma VM confidencial através da Google Cloud consola.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

COS not used

Nome da categoria na API: COS_NOT_USED

As VMs do Compute Engine não estão a usar o SO otimizado para contentores, que foi concebido para executar contentores Docker de forma Google Cloud segura.

O SO otimizado para contentores é o SO recomendado pela Google para alojar e executar contentores no Google Cloud. A sua pequena dimensão do SO minimiza a exposição à segurança, enquanto as atualizações automáticas corrigem as vulnerabilidades de segurança atempadamente. Para mais informações, consulte o artigo Vista geral do SO otimizado para contentores.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Clusters do Kubernetes na Google Cloud consola.

   Aceda aos clusters do Kubernetes

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

3. Clique no separador Nós.

4. Para cada conjunto de nós:

   1. Clique no nome do conjunto de nós para aceder à respetiva página de detalhes.
   2. Clique em Editar .
   3. Em Nodes -> Image type, clique em Change.
   4. Selecione Container-Optimized OS e, de seguida, clique em Alterar.
   5. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Custom role not monitored

Nome da categoria na API: CUSTOM_ROLE_NOT_MONITORED

As métricas e os alertas de registo não estão configurados para monitorizar alterações de funções personalizadas.

O IAM fornece funções predefinidas e personalizadas que concedem acesso a recursos Google Cloud específicos. Ao monitorizar as atividades de criação, eliminação e atualização de funções, pode identificar funções com privilégios excessivos em fases iniciais. Para mais informações, consulte o artigo Vista geral das métricas baseadas em registos.

Consoante a quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para compreender a sua utilização do serviço e os respetivos custos, consulte os preços da observabilidade do Google Cloud.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta descoberta, conclua os seguintes passos:

Crie uma métrica

1. Aceda à página Métricas baseadas em registos na Google Cloud consola.

   Aceda a Métricas baseadas em registos

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 registo.
   2. Adicione uma descrição.
   3. Defina Unidades como 1.

5. Em Seleção de filtros, copie e cole o seguinte texto 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. É apresentada uma confirmação.

Crie uma política de alerta

1. Na Google Cloud consola, aceda à página Métricas baseadas em registos:

   Aceda a Métricas baseadas em registos

   Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cuja legenda é Registo.

2. Na secção Métricas definidas pelo utilizador, selecione a métrica que criou na secção anterior.

3. Clique em Mais e, de seguida, clique em Criar alerta a partir da métrica.

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

4. Clicar em Seguinte.
   1. Reveja as definições pré-preenchidas. É recomendável modificar o Valor do limite.
   2. Clique em Nome da condição e introduza um nome para a condição.
5. Clicar em Seguinte.

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, de seguida, clique em OK.

   Para receber uma notificação quando os incidentes são abertos e fechados, selecione a opção Notificar no encerramento do incidente. Por predefinição, as notificações são enviadas apenas quando são abertos incidentes.

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

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Dataproc CMEK disabled

Nome da categoria na API: DATAPROC_CMEK_DISABLED

Foi criado um cluster do Dataproc sem uma configuração de encriptação CMEK. Com as CMEK, as chaves que cria e gere no Cloud Key Management Service envolvem as chaves que o Google Cloud usa para encriptar os seus dados, o que lhe dá mais controlo sobre o acesso aos seus dados.

Atenção: estes passos de remediação podem interromper o seu ambiente de produção. Se for necessário, transfira cargas de trabalho, dados ou autorizações para novos recursos antes de eliminar recursos existentes.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Cluster do Dataproc na Google Cloud consola.

   Aceda aos clusters do Dataproc

2. Selecione o seu projeto e clique em Criar cluster.

3. Na secção Gerir segurança, clique em Encriptação e selecione Chave gerida pelo cliente.

4. Selecione uma chave gerida pelo cliente na lista.

   Se não tiver uma chave gerida pelo cliente, tem de criar uma para usar. Para mais informações, consulte o artigo Chaves de encriptação geridas pelo cliente.

5. Certifique-se de que a chave do KMS selecionada tem a função de encriptar/desencriptar do CryptoKey do Cloud KMS atribuída à conta de serviço do cluster do Dataproc ("serviceAccount:[e-mail]").

6. Após a criação do cluster, migre todas as cargas de trabalho do cluster mais antigo para o novo cluster.

7. Aceda aos clusters do Dataproc e selecione o seu projeto.

8. Selecione o grupo antigo e clique em Eliminar grupo.

9. Repita todos os passos acima para outros clusters do Dataproc disponíveis no projeto selecionado.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Dataproc image outdated

Nome da categoria na API: DATAPROC_IMAGE_OUTDATED

Foi criado um cluster do Dataproc com uma versão de imagem do Dataproc afetada por vulnerabilidades de segurança na utilidade Apache Log4j 2 (CVE-2021-44228 e CVE-2021-45046).

Este detetor encontra vulnerabilidades verificando se o campo softwareConfig.imageVersion na propriedade config de um Cluster tem alguma das seguintes versões afetadas:

• Versões de imagens anteriores a 1.3.95.
• Versões de imagens secundárias anteriores a 1.4.77, 1.5.53 e 2.0.27.

O número da versão de uma imagem personalizada do Dataproc pode ser substituído manualmente. Considere os seguintes cenários:

• Uma pessoa pode modificar a versão de uma imagem personalizada afetada para que pareça não estar afetada. Neste caso, este detetor não emite uma descoberta.
• É possível substituir a versão de uma imagem personalizada não afetada por uma que se saiba ter a vulnerabilidade. Neste caso, este detetor emite uma deteção falsa positiva. Para suprimir estes resultados falsos positivos, pode desativá-los.

Aviso: estes passos de correção podem interromper o seu ambiente de produção. Se for necessário, transfira cargas de trabalho, dados ou autorizações para novos recursos antes de eliminar recursos existentes.

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

Saiba mais sobre os recursos suportados e as definições de análise deste 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 encriptação gerida pelo cliente (CMEK) predefinida.

Com as CMEK, as chaves que cria e gere no Cloud KMS envolvem as chaves que o Google Cloud usa para encriptar os seus dados, o que lhe dá mais controlo sobre o acesso aos seus dados. Google Cloud Para mais informações, consulte o artigo Proteger dados com chaves do Cloud KMS.

Atenção: estes passos de remediação podem interromper o seu ambiente de produção. Se for necessário, transfira cargas de trabalho, dados ou autorizações para novos recursos antes de eliminar recursos existentes.

Para corrigir esta descoberta, conclua os seguintes passos:

Não pode alternar uma tabela no local entre as encriptações predefinidas e a encriptação CMEK. Para definir uma chave CMEK predefinida com a qual encriptar todas as novas tabelas no conjunto de dados, siga as instruções para Definir uma chave predefinida do conjunto de dados.

A definição de uma chave predefinida não volta a encriptar retroativamente as tabelas atualmente no conjunto de dados com uma nova chave. Para usar as CMEK para dados existentes, faça o seguinte:

1. Crie um novo conjunto de dados.
2. Defina uma chave CMEK predefinida no conjunto de dados que criou.
3. Para copiar tabelas para o seu conjunto de dados com CMEK ativadas, siga as instruções para Copiar uma tabela.
4. Depois de copiar os dados com êxito, elimine os conjuntos de dados originais.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Default network

Nome da categoria na API: DEFAULT_NETWORK

A rede predefinida existe num projeto.

As redes predefinidas têm regras de firewall e configurações de rede criadas automaticamente que podem não ser seguras. Para mais informações, consulte o artigo Rede predefinida.

Atenção: estes passos de remediação podem interromper o seu ambiente de produção. Se for necessário, transfira cargas de trabalho, dados ou autorizações para novos recursos antes de eliminar recursos existentes.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Redes VPC na Google Cloud consola.

   Aceda a redes de VPC

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

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

4. Para criar uma nova rede com regras de firewall personalizadas, consulte o artigo Criar redes.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 predefinida.

A conta de serviço predefinida do Compute Engine tem a função de editor no projeto, o que permite o acesso de leitura e escrita à maioria dos Google Cloud serviços. Para se defender contra escalamentos de privilégios e acesso não autorizado, não use a conta de serviço do Compute Engine predefinida. Em alternativa, crie uma nova conta de serviço e atribua apenas as autorizações necessárias à sua instância. Leia o artigo Controlo de acesso para ver informações sobre funções e autorizações.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias de VM na Google Cloud consola.

   Aceder às instâncias de VM

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

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

4. Depois de a instância parar, clique em Editar.

5. Na secção Conta de serviço, selecione uma conta de serviço diferente da conta de serviço do Compute Engine predefinida. Pode ter de criar primeiro uma nova conta de serviço. Leia o artigo Controlo de acesso para ver informações sobre as funções e as autorizações do IAM.

6. Clique em Guardar. A nova configuração é apresentada na página Detalhes da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Disk CMEK disabled

Nome da categoria na API: DISK_CMEK_DISABLED

Os discos nesta VM não estão encriptados com chaves de encriptação geridas pelo cliente (CMEK).

Com as CMEK, as chaves que cria e gere no Cloud KMS envolvem as chaves que o Google Cloud usa para encriptar os seus dados, o que lhe dá mais controlo sobre o acesso aos seus dados. Google Cloud Para mais informações, consulte o artigo Proteger recursos com chaves do Cloud KMS.

Atenção: estes passos de remediação podem interromper o seu ambiente de produção. Se for necessário, transfira cargas de trabalho, dados ou autorizações para novos recursos antes de eliminar recursos existentes.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Discos do Compute Engine na Google Cloud consola.

   Aceda aos discos do Compute Engine

2. Na lista de discos, clique no nome do disco indicado na deteção.

3. Na página Gerir disco, clique em Eliminar.

4. Para criar um novo disco com a CMEK ativada, consulte o artigo Encriptar um novo disco persistente com as suas próprias chaves. A CMEK incorre em custos adicionais relacionados com o Cloud KMS.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Disk CSEK disabled

Nome da categoria na API: DISK_CSEK_DISABLED

Os discos nesta VM não estão encriptados com chaves de encriptação fornecidas pelos clientes (CSEK). Os discos das VMs críticas devem ser encriptados com CSEK.

Se fornecer as suas próprias chaves de encriptação, o Compute Engine usa a sua chave para proteger as chaves geradas pela Google usadas para encriptar e desencriptar os seus dados. Para mais informações, consulte o artigo Chaves de encriptação fornecidas pelos clientes. As CSEKs incorrem em custos adicionais relacionados com o Cloud KMS.

Atenção: estes passos de remediação podem interromper o seu ambiente de produção. Se for necessário, transfira cargas de trabalho, dados ou autorizações para novos recursos antes de eliminar recursos existentes.

Para corrigir esta descoberta, conclua os seguintes passos:

Elimine e crie um disco

Só pode encriptar novos discos persistentes com a sua própria chave. Não pode encriptar discos persistentes existentes com a sua própria chave.

1. Aceda à página Discos do Compute Engine na Google Cloud consola.

   Aceda aos discos do Compute Engine

2. Na lista de discos, clique no nome do disco indicado na deteção.

3. Na página Gerir disco, clique em Eliminar.

4. Para criar um novo disco com a CSEK ativada, consulte o artigo Encriptar discos com chaves de encriptação fornecidas pelo cliente.

5. Conclua os passos restantes para ativar o detetor.

Ative o detetor

1. Aceda à página Recursos do Security Command Center na Google Cloud consola.

   Aceda a Recursos

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

   Se não vir compute.Disk, clique em Ver mais, introduza Disk no campo de pesquisa e, de seguida, clique em Aplicar.

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

3. Na coluna Nome a apresentar, selecione a caixa junto ao nome do disco que quer usar com a CSEK e, de seguida, clique em Definir marcas de segurança.

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

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

6. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

DNS logging disabled

Nome da categoria na API: DNS_LOGGING_DISABLED

A monitorização dos registos do Cloud DNS oferece visibilidade dos nomes DNS pedidos pelos clientes na rede VPC. Estes registos podem ser monitorizados para verificar a existência de nomes de domínio anómalos e avaliados em função das informações sobre ameaças. Recomendamos que ative o registo de DNS para redes de VPC.

Consoante a quantidade de informações, os custos do registo do Cloud DNS podem ser significativos. Para compreender a sua utilização do serviço e o respetivo custo, consulte o artigo Preços do Google Cloud Observability: Cloud Logging.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Redes VPC na Google Cloud consola.

   Aceda a redes de VPC

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

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

   • Se a rede não tiver uma política de servidor DNS, conclua os seguintes passos:

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

   • Se a rede tiver uma política de servidor DNS, conclua os seguintes passos:

     1. No campo Política do servidor DNS, clique no nome da política de DNS.
     2. Clique em Editar política.
     3. Defina Registos como Ativado.
     4. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

DNSSEC disabled

Nome da categoria na API: DNSSEC_DISABLED

As Extensões de Segurança do Sistema de Nomes de Domínio (DNSSEC) estão desativadas para as zonas do Cloud DNS.

As DNSSEC validam as respostas DNS e mitigam riscos, como o roubo de DNS e os ataques de interposição, através da assinatura criptográfica de registos DNS. Deve ativar as DNSSEC. Para mais informações, consulte a vista geral das extensões de segurança do DNS (DNSSEC).

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Cloud DNS na Google Cloud consola.

   Aceda às redes do Cloud DNS

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

3. Clique na definição de DNSSEC na linha e, de seguida, em DNSSEC, selecione Ativado.

4. Leia a caixa de diálogo apresentada. Se estiver satisfeito, clique em Ativar.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 associação RBAC que faz referência a um dos seguintes utilizadores ou grupos:

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

Estes utilizadores e grupos são efetivamente anónimos e não devem ser usados em RoleBindings nem ClusterRoleBindings. Para ver detalhes, consulte a secção Evite funções e grupos predefinidos.

Para corrigir esta descoberta, aplique os seguintes passos aos 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

• Quaisquer grupos, utilizadores ou contas de serviço que não incluam system:anonymous, system:authenticated ou system:unauthenticated.

Egress deny rule not set

Nome da categoria na API: EGRESS_DENY_RULE_NOT_SET

Não está definida uma regra de recusa de saída numa firewall.

Uma firewall que nega todo o tráfego de rede de saída impede quaisquer ligações de rede de saída indesejadas, exceto as ligações que outras firewalls autorizam explicitamente. Para mais informações, consulte o artigo Casos de saída.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Firewall na Google Cloud consola.

   Aceda a Firewall

2. Clique em Criar regra de firewall.

3. Atribua um nome e, opcionalmente, uma descrição à firewall.

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

5. Em Ação em caso de correspondência, selecione Recusar.

6. No menu pendente Alvos, selecione Todas as instâncias na rede.

7. No menu pendente Filtro de destino, selecione Intervalos de IP e, de seguida, escreva 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, de seguida, em Aplicação, selecione Ativada.

10. Clique em Criar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Essential contacts not configured

Nome da categoria na API: ESSENTIAL_CONTACTS_NOT_CONFIGURED

A sua organização não designou uma pessoa ou um grupo para receber notificações de Google Cloud acerca de eventos importantes, como ataques, vulnerabilidades e incidentes de dados na sua Google Cloud organização. Recomendamos que designe como contacto essencial uma ou mais pessoas ou grupos na organização empresarial.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Contactos essenciais na Google Cloud consola.

   Aceder a Contactos essenciais

2. Certifique-se de que a organização aparece no seletor de recursos na parte superior da página. O seletor de recursos indica o projeto, a pasta ou a organização para os quais está atualmente a gerir contactos.

3. Clique em + Adicionar contacto. É aberto o painel Adicionar um contacto.

4. Nos campos Email e Confirmar email, introduza o endereço de email do contacto.

5. Na secção Categorias de notificações, selecione as categorias de notificações sobre as quais quer que o contacto receba comunicações. Certifique-se de que estão configurados endereços de email adequados para cada uma das seguintes categorias de notificação:

   1. Legal
   2. Segurança
   3. Suspensão
   4. Técnico

6. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Firewall not monitored

Nome da categoria na API: FIREWALL_NOT_MONITORED

Nota: o filtro de métricas baseadas em registos para este detetor foi alterado a 27 de outubro de 2021.

As métricas e os alertas de registo não estão configurados para monitorizar as alterações às regras de firewall da rede VPC.

A monitorização dos eventos de criação e atualização de regras de firewall dá-lhe informações sobre as alterações de acesso à rede e pode ajudar a detetar rapidamente atividade suspeita. Para mais informações, consulte o artigo Vista geral das métricas baseadas em registos.

Consoante a quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para compreender a sua utilização do serviço e os respetivos custos, consulte os preços da observabilidade do Google Cloud.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta descoberta, conclua os seguintes passos:

Crie uma métrica

1. Aceda à página Métricas baseadas em registos na Google Cloud consola.

   Aceda a Métricas baseadas em registos

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 registo.
   2. Adicione uma descrição.
   3. Defina Unidades como 1.

5. Em Seleção de filtros, copie e cole o seguinte texto 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. É apresentada uma confirmação.

Crie uma política de alerta

1. Na Google Cloud consola, aceda à página Métricas baseadas em registos:

   Aceda a Métricas baseadas em registos

   Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cuja legenda é Registo.

2. Na secção Métricas definidas pelo utilizador, selecione a métrica que criou na secção anterior.

3. Clique em Mais e, de seguida, clique em Criar alerta a partir da métrica.

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

4. Clicar em Seguinte.
   1. Reveja as definições pré-preenchidas. É recomendável modificar o Valor do limite.
   2. Clique em Nome da condição e introduza um nome para a condição.
5. Clicar em Seguinte.

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, de seguida, clique em OK.

   Para receber uma notificação quando os incidentes são abertos e fechados, selecione a opção Notificar no encerramento do incidente. Por predefinição, as notificações são enviadas apenas quando são abertos incidentes.

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

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Firewall rule logging disabled

Nome da categoria na API: FIREWALL_RULE_LOGGING_DISABLED

O registo de regras de firewall está desativado.

O registo de regras de firewall permite-lhe auditar, validar e analisar os efeitos das suas regras de firewall. Pode ser útil para auditar o acesso à rede ou fornecer um aviso antecipado de que a rede está a ser usada de forma não aprovada. O custo dos registos pode ser significativo. Para mais informações sobre o registo das regras da firewall e o respetivo custo, consulte o artigo Usar o registo das regras da firewall.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Firewall na Google Cloud consola.

   Aceda à firewall

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

3. Clique em Editar.

4. Em Registos, selecione Ativar.

5. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Flow logs disabled

Nome da categoria na API: FLOW_LOGS_DISABLED

Existe uma sub-rede da VPC com os registos de fluxo desativados.

Os registos de fluxo da VPC registam uma amostra de fluxos de rede enviados e recebidos por instâncias de VM. Estes registos podem ser usados para monitorização de rede, análise forense, análise de segurança em tempo real e otimização de despesas. Para mais informações acerca dos registos de fluxo e do respetivo custo, consulte o artigo Usar registos de fluxo da VPC.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Redes VPC na Google Cloud consola.

   Aceda a redes de VPC

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

3. Na página Detalhes da rede VPC, clique no separador Sub-redes.

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

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

6. Em Registos de fluxo, selecione Ativado.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 numa rede VPC, o serviço VPC Flow Logs está desativado ou não está configurado de acordo com as recomendações da CIS Benchmark 1.3. Os registos de fluxo de VPC registam uma amostra de fluxos de rede enviados e recebidos por instâncias de VMs que podem ser usados para detetar ameaças.

Nota: os registos de fluxo de VPC podem incorrer em custos e as recomendações da norma de referência do CIS não estão otimizadas para poupanças de custos. Para reduzir os custos, use um intervalo de agregação de 15 minutos e uma taxa de amostragem entre 5% e 10%, o que oferece um bom equilíbrio entre o custo e a deteção de ameaças. No entanto, se usar estas definições equilibradas, vai continuar a receber esta descoberta, porque as definições equilibradas não correspondem às recomendações atuais da CIS Benchmark.

Para mais informações acerca dos registos de fluxo da VPC e do respetivo custo, consulte o artigo Usar registos de fluxo da VPC.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Redes VPC na Google Cloud consola.

   Aceda a redes de VPC

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

3. Na página Detalhes da rede VPC, clique no separador Sub-redes.

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

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

6. Em Registos de fluxo, selecione Ativado.

   1. Opcionalmente, modifique a configuração dos registos clicando no botão Configurar registos para expandir o separador. As referências da CIS recomendam as seguintes definições:
      1. Defina o Intervalo de agregação como 5 SEG.
      2. Na caixa de verificação Campos adicionais, selecione a opção Incluir metadados.
      3. Defina a Taxa de amostragem como 100%.
      4. Clique no botão GUARDAR.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 predefinida com acesso total a todas as Google Cloud APIs.

Uma instância configurada com a conta de serviço predefinida e o âmbito de acesso à API definido como Permitir acesso total a todas as APIs Cloud pode permitir que os utilizadores realizem operações ou chamadas de API para as quais não têm autorizações do IAM. Para mais informações, consulte o artigo Conta de serviço predefinida do Compute Engine.

Importante: o procedimento seguinte altera as APIs às quais a conta de serviço predefinida tem acesso. Os processos ou as cargas de trabalho da VM que usam a conta de serviço predefinida podem ser afetados. A inteligência de políticas pode ajudar a compreender como a conta de serviço predefinida está a ser usada. Para mais informações, consulte o artigo Ferramentas para compreender a utilização da conta de serviço.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias de VM na Google Cloud consola.

   Aceder às 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 estiver parada, clique em Editar.

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

6. Em Âmbitos de acesso, selecione Permitir acesso predefinido ou Definir acesso para cada API. Isto limita as APIs a que qualquer processo ou carga de trabalho que use a conta de serviço da VM predefinida pode aceder.

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

   • Desative a Cloud Platform definindo-a como Nenhuma.
   • Ative as APIs específicas às quais a conta de serviço da VM predefinida requer acesso.

8. Clique em Guardar.

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

Saiba mais sobre os recursos suportados e as definições de análise deste 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 seus dados e impedir que os intrusos adulterem as suas comunicações, configure os balanceadores de carga HTTP(S) para permitirem apenas tráfego HTTPS. Para mais informações, consulte o artigo Vista geral do balanceamento de carga HTTP(S) externo.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Proxies de destino na Google Cloud consola.

   Aceda a Proxies de destino

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

3. Clique no link abaixo do Mapa de URLs.

4. Clique em Editar.

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

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

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Instance OS login disabled

Nome da categoria na API: INSTANCE_OS_LOGIN_DISABLED

O Início de sessão do SO está desativado nesta instância do Compute Engine.

O Início de sessão do SO permite a gestão centralizada de chaves SSH com o IAM e desativa a configuração de chaves SSH baseada em metadados em todas as instâncias de um projeto. Saiba como configurar o início de sessão no SO.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias de VM na Google Cloud consola.

   Aceder às 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 Parar.

4. Depois de a instância parar, clique em Editar.

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

6. Clique em Guardar.

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

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Integrity monitoring disabled

Nome da categoria na API: INTEGRITY_MONITORING_DISABLED

A monitorização da integridade está desativada num cluster do GKE.

A monitorização da integridade permite-lhe monitorizar e validar a integridade do arranque em tempo de execução dos seus nós protegidos através da monitorização. Isto permite-lhe responder a falhas de integridade e impedir a implementação de nós comprometidos no cluster.

Atenção: estes passos de remediação podem interromper o seu ambiente de produção. Se for necessário, transfira cargas de trabalho, dados ou autorizações para novos recursos antes de eliminar recursos existentes.

Para corrigir esta descoberta, conclua os seguintes passos:

Depois de um nó ser aprovisionado, não é possível atualizá-lo para ativar a monitorização da integridade. Tem de criar um novo conjunto de nós com a monitorização da integridade ativada.

1. Aceda à página Clusters do Kubernetes na Google Cloud consola.

   Aceda aos clusters do Kubernetes

2. Clique no nome do cluster na descoberta.

3. Clique em Adicionar conjunto de nós.

4. No separador Segurança, certifique-se de que a opção Ativar monitorização da integridade está ativada.

5. Clique em Criar.

6. Para migrar as suas cargas de trabalho dos conjuntos de nós não conformes existentes para os novos conjuntos de nós, consulte o artigo Migrar cargas de trabalho para diferentes tipos de máquinas.

7. Depois de mover as cargas de trabalho, elimine o conjunto de nós original não conforme.

   1. Na página Kubernetes cluster, no menu Node pools, clique no nome do conjunto de nós que quer eliminar.
   2. Clique em Remover conjunto de nós.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Intranode visibility disabled

Nome da categoria na API: INTRANODE_VISIBILITY_DISABLED

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

A ativação da visibilidade intranodal torna o tráfego de Pod para Pod intranodal visível para a estrutura de rede. Com esta funcionalidade, pode usar o registo de fluxos da VPC ou outras funcionalidades da VPC para monitorizar ou controlar o tráfego intranodal. Para obter registos, tem de ativar os registos de fluxo da VPC na sub-rede selecionada. Para mais informações, consulte o artigo Usar registos de fluxo de VPC.

Atenção: estes passos de remediação podem interromper o seu ambiente de produção. Se for necessário, transfira cargas de trabalho, dados ou autorizações para novos recursos antes de eliminar recursos existentes.

Para corrigir esta descoberta, conclua os seguintes passos:

Depois de um nó ser aprovisionado, não é possível atualizá-lo para ativar a monitorização da integridade. Tem de criar um novo conjunto de nós com a monitorização da integridade ativada.

1. Aceda à página Clusters do Kubernetes na Google Cloud consola.

   Aceda aos clusters do Kubernetes

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

   Se a configuração do cluster tiver sido alterada recentemente, o botão de edição pode estar desativado. Se não conseguir editar as definições do cluster, aguarde alguns minutos e tente novamente.

3. Na caixa de diálogo, selecione Ativar visibilidade intranodal.

4. Clique em Guardar alterações.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

IP alias disabled

Nome da categoria na API: IP_ALIAS_DISABLED

Foi criado um cluster do GKE com intervalos de IP de alias desativados.

Quando ativa os intervalos de IPs de alias, os clusters do GKE atribuem endereços IP a partir de um bloco CIDR conhecido, pelo que o seu cluster é escalável e interage melhor com Google Cloud produtos e entidades. Para mais informações, consulte o artigo Vista geral dos intervalos de IPs de alias.

Para corrigir esta descoberta, conclua os seguintes passos:

Não pode migrar um cluster existente para usar IPs de alias. Para criar um novo cluster com IPs de alias ativados, faça o seguinte:

1. Aceda à página Clusters do Kubernetes na Google Cloud consola.

   Aceda aos clusters do Kubernetes

2. Clique em Criar.

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

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

5. Clique em Criar.

   Nota: não é possível modificar um cluster enquanto este se está a reconfigurar.

Saiba mais sobre os recursos suportados e as definições de análise deste 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.

Impeça a perda de dados ou a divulgação de informações desativando o encaminhamento de IP de pacotes de dados para as suas VMs.

Atenção: estes passos de remediação podem interromper o seu ambiente de produção. Se for necessário, transfira cargas de trabalho, dados ou autorizações para novos recursos antes de eliminar recursos existentes.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias de VM na Google Cloud consola.

   Aceder às instâncias de VM

2. Na lista de instâncias, selecione a caixa junto ao nome da instância na descoberta.

3. Clique em Eliminar.

4. Selecione Criar instância para criar uma nova instância para substituir a que eliminou.

5. Para garantir que o encaminhamento de IP está desativado, clique em Gestão, discos, trabalhar em rede, chaves SSH e, de seguida, clique em Trabalhar em rede.

6. Em Interfaces de rede, clique em Editar.

7. Em Encaminhamento de IP, no menu pendente, certifique-se de que a opção Desativado está selecionada.

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

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

KMS key not rotated

Nome da categoria na API: KMS_KEY_NOT_ROTATED

A rotação não está configurada numa chave de encriptação do Cloud KMS.

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

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Chaves do Cloud KMS na Google Cloud consola.

   Aceda às chaves do Cloud KMS

2. Clique no nome do conjunto de chaves indicado na descoberta.

3. Clique no nome da chave indicado na descoberta.

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

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

6. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

KMS project has owner

Nome da categoria na API: KMS_PROJECT_HAS_OWNER

Um utilizador tem autorizações roles/Owner num projeto com chaves criptográficas. Para mais informações, consulte o artigo Autorizações e funções.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página IAM na Google Cloud consola.

   Aceda à página do IAM

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

3. Para cada principal ao qual foi atribuída a função Proprietário:

   1. Clique em Editar.
   2. No painel Editar autorizações, junto à função Proprietário, clique em Eliminar.
   3. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

KMS public key

Nome da categoria na API: KMS_PUBLIC_KEY

Uma Cryptokey do Cloud KMS ou um conjunto de chaves do Cloud KMS é público e acessível a qualquer pessoa na Internet. Para mais informações, consulte o artigo Usar o IAM com o Cloud KMS.

Para corrigir esta descoberta, se estiver relacionada com uma chave criptográfica:

1. Aceda à página Chaves criptográficas na Google Cloud consola.

   Chaves criptográficas

2. Em Nome, selecione o conjunto de chaves que contém a chave criptográfica relacionada com a descoberta do Security Health Analytics.

3. Na página Detalhes do conjunto de chaves carregada, selecione a caixa de verificação junto à chave criptográfica.

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

5. Use a caixa de filtro antes de Função / principal para pesquisar principais para allUsers e allAuthenticatedUsers e clique em Eliminar para remover o acesso para estes principais.

Para corrigir esta descoberta, se estiver relacionada com um Key Ring:

1. Aceda à página Chaves criptográficas na Google Cloud consola.

   Chaves criptográficas

2. Encontre a linha com o porta-chaves na localização e selecione a caixa de verificação.

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

4. Use a caixa de filtro antes de Função / principal para pesquisar principais para allUsers e allAuthenticatedUsers e clique em Eliminar para remover o acesso para estes principais.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

KMS role separation

Nome da categoria na API: KMS_ROLE_SEPARATION

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

Um ou mais responsáveis têm várias autorizações do Cloud KMS atribuídas. Recomendamos que nenhuma conta tenha simultaneamente a função Administrador do Cloud KMS, juntamente com outras autorizações do Cloud KMS. Para mais informações, consulte o artigo Autorizações e funções.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página IAM na Google Cloud consola.

   Aceda ao IAM

2. Para cada principal indicado na descoberta, faça o seguinte:

   1. Verifique se a função foi herdada de uma pasta ou de um recurso da organização consultando a coluna Herança. Se a coluna contiver um link para um recurso principal, clique no link para aceder à página IAM do recurso principal.
   2. Clique em Editar junto a um principal.
   3. Para remover autorizações, clique em Eliminar junto a Administrador do Cloud KMS. Se quiser remover todas as autorizações para o principal, clique em Eliminar junto a todas as outras autorizações.

3. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Legacy authorization enabled

Nome da categoria na API: LEGACY_AUTHORIZATION_ENABLED

A autorização antiga está ativada nos clusters do GKE.

No Kubernetes, o controlo de acesso baseado em funções (CABF) permite-lhe definir funções com regras que contêm um conjunto de autorizações e conceder autorizações ao nível do cluster e do espaço de nomes. Esta funcionalidade oferece uma melhor segurança, garantindo que os utilizadores só têm acesso a recursos específicos. Pondere desativar o controlo de acesso baseado em atributos (CABF) antigo.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Clusters do Kubernetes na Google Cloud consola.

   Aceda aos clusters do Kubernetes

2. Selecione o cluster indicado 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 pode estar desativado. Se não conseguir editar as definições do cluster, aguarde alguns minutos e tente novamente.

4. Na lista pendente Autorização antiga, selecione Desativada.

5. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Legacy metadata enabled

Nome da categoria na API: LEGACY_METADATA_ENABLED

Os metadados antigos estão ativados nos clusters do GKE.

O servidor de metadados de instâncias do Compute Engine expõe pontos finais /0.1/ e /v1beta1/ antigos, que não aplicam cabeçalhos de consulta de metadados. Esta é uma funcionalidade nas APIs /v1/ que torna mais difícil para um potencial atacante obter metadados de instâncias. A menos que seja necessário, recomendamos que desative estas APIs /0.1/ e /v1beta1/ antigas.

Para mais informações, consulte o artigo Desativar e fazer a transição das APIs de metadados antigas.

Para corrigir esta descoberta, conclua os seguintes passos:

Só pode desativar as APIs de metadados antigas quando criar um novo cluster ou quando adicionar um novo conjunto de nós a um cluster existente. Para atualizar um cluster existente e desativar as APIs de metadados antigas, consulte o artigo Migrar cargas de trabalho para diferentes tipos de máquinas.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Legacy network

Nome da categoria na API: LEGACY_NETWORK

Existe uma rede antiga num projeto.

As redes antigas não são recomendadas porque muitas novas funcionalidades de Google Cloud segurança não são suportadas nas redes antigas. Em alternativa, use redes VPC. Para mais informações, consulte o artigo Redes antigas.

Atenção: estes passos de remediação podem interromper o seu ambiente de produção. Se for necessário, transfira cargas de trabalho, dados ou autorizações para novos recursos antes de eliminar recursos existentes.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Redes VPC na Google Cloud consola.

   Aceda a redes de VPC

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

3. Regresse à página Redes VPC.

4. Na lista de redes, clique em legacy_network.

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

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Load balancer logging disabled

Nome da categoria na API: LOAD_BALANCER_LOGGING_DISABLED

O registo está desativado para o serviço de back-end num balanceador de carga.

A ativação do registo para um balanceador de carga permite-lhe ver o tráfego de rede HTTP(S) para as suas aplicações Web. Para mais informações, consulte o artigo Equilibrador de carga.

Aviso: uma taxa de amostragem elevada pode resultar em custos de armazenamento mais elevados para o ficheiro de registo. Tem de encontrar um equilíbrio entre a taxa de amostragem e os potenciais custos de armazenamento adequados para a sua empresa.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Cloud Load Balancing na Google Cloud consola.

   Aceda ao 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 secção Registo, selecione Ativar registo e escolha a melhor taxa de amostragem para o seu projeto.

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

8. Para terminar a edição do equilibrador de carga, clique em Atualizar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Locked retention policy not set

Nome da categoria na API: LOCKED_RETENTION_POLICY_NOT_SET

Não está definida uma política de retenção bloqueada para os registos.

Uma política de retenção bloqueada impede a substituição dos registos e a eliminação do contentor de registos. Para mais informações, consulte o artigo Bucket Lock.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Explorador de armazenamento na Google Cloud consola.

   Aceda ao navegador de armazenamento

2. Selecione o contentor indicado na descoberta do Security Health Analytics.

3. Na página Detalhes do contentor, clique no separador Retenção.

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

5. Introduza um período de retenção.

6. Clique em Guardar. A política de retenção é apresentada no separador Retenção.

7. Clique em Bloquear para garantir que o período de retenção não é reduzido nem removido.

   Aviso: o bloqueio de uma política de retenção é um ato irreversível e só pode ser anulado através da eliminação do contentor completo. Para mais informações, consulte o artigo Bloqueio de contentores.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Log not exported

Nome da categoria na API: LOG_NOT_EXPORTED

Um recurso não tem um destino de registo adequado configurado.

O Cloud Logging ajuda a encontrar rapidamente a causa principal dos problemas no seu sistema e aplicações. No entanto, a maioria dos registos só é retida durante 30 dias por predefinição. Exporte cópias de todas as entradas do registo para prolongar o período de armazenamento. Para mais informações, consulte o artigo Vista geral das exportações de registos.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Log Router na Google Cloud consola.

   Aceder ao registo do router

2. Clique em Criar destino.

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

4. Clique em Criar destino.

   Nota: estas instruções criam um destino ao nível do projeto. Também é possível criar destinos ao nível da pasta ou da organização. Para mais informações, consulte o artigo Exportar registos com a Google Cloud consola.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Master authorized networks disabled

Nome da categoria na API: MASTER_AUTHORIZED_NETWORKS_DISABLED

As redes autorizadas do plano de controlo não estão ativadas em clusters do GKE.

As redes autorizadas do plano de controlo melhoram a segurança do seu cluster de contentores ao bloquear o acesso de endereços IP especificados ao plano de controlo do cluster. Para mais informações, consulte o artigo Adicionar redes autorizadas para acesso ao plano de controlo.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Clusters do Kubernetes na Google Cloud consola.

   Aceda aos clusters do Kubernetes

2. Selecione o cluster indicado 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 pode estar desativado. Se não conseguir editar as definições do cluster, aguarde alguns minutos e tente novamente.

4. Na lista pendente Redes autorizadas do plano de controlo, selecione Ativado.

5. Clique em Adicionar rede autorizada.

6. Especifique as redes autorizadas que quer usar.

7. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

MFA not enforced

Nome da categoria na API: MFA_NOT_ENFORCED

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

A autenticação multifator, especificamente a validação em dois passos, está desativada para alguns utilizadores na sua organização.

A autenticação multifator é usada para proteger as contas contra acesso não autorizado e é a ferramenta mais importante para proteger a sua organização contra credenciais de início de sessão comprometidas. Para mais informações, consulte o artigo Proteja a sua empresa com a validação em dois passos.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página da consola do administrador na Google Cloud consola.

   Aceda à consola do administrador

2. Aplique a validação em dois passos a todas as unidades organizacionais.

Suprima as descobertas deste tipo

Para suprimir a deteção deste tipo, defina uma regra de desativação do som que desative automaticamente o som de deteções futuras deste tipo. Para mais informações, consulte o artigo Desative as conclusões no Security Command Center.

Embora não seja uma forma recomendada de suprimir as conclusões, também pode adicionar marcas de segurança dedicadas aos recursos para que os detetores do Security Health Analytics não criem conclusões de segurança para esses recursos.

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

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Network not monitored

Nome da categoria na API: NETWORK_NOT_MONITORED

Nota: o filtro de métricas baseadas em registos para este detetor foi alterado a 27 de outubro de 2021.

As métricas e os alertas de registo não estão configurados para monitorizar as alterações da rede VPC.

Para detetar alterações incorretas ou não autorizadas à configuração da sua rede, monitorize as alterações da rede VPC. Para mais informações, consulte o artigo Vista geral das métricas baseadas em registos.

Consoante a quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para compreender a sua utilização do serviço e os respetivos custos, consulte os preços da observabilidade do Google Cloud.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta descoberta, conclua os seguintes passos:

Crie uma métrica

1. Aceda à página Métricas baseadas em registos na Google Cloud consola.

   Aceda a Métricas baseadas em registos

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 registo.
   2. Adicione uma descrição.
   3. Defina Unidades como 1.

5. Em Seleção de filtros, copie e cole o seguinte texto 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. É apresentada uma confirmação.

Crie uma política de alerta

1. Na Google Cloud consola, aceda à página Métricas baseadas em registos:

   Aceda a Métricas baseadas em registos

   Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cuja legenda é Registo.

2. Na secção Métricas definidas pelo utilizador, selecione a métrica que criou na secção anterior.

3. Clique em Mais e, de seguida, clique em Criar alerta a partir da métrica.

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

4. Clicar em Seguinte.
   1. Reveja as definições pré-preenchidas. É recomendável modificar o Valor do limite.
   2. Clique em Nome da condição e introduza um nome para a condição.
5. Clicar em Seguinte.

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, de seguida, clique em OK.

   Para receber uma notificação quando os incidentes são abertos e fechados, selecione a opção Notificar no encerramento do incidente. Por predefinição, as notificações são enviadas apenas quando são abertos incidentes.

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

Saiba mais sobre os recursos suportados e as definições de análise deste 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 predefinição, a comunicação entre pods está aberta. A comunicação aberta permite que os pods se liguem diretamente entre nós, com ou sem tradução de endereços de rede. Um recurso NetworkPolicy é como uma firewall ao nível do pod que restringe as ligações entre pods, a menos que o recurso NetworkPolicy permita explicitamente a ligação. Saiba como definir uma política de rede.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Clusters do Kubernetes na Google Cloud consola.

   Aceda aos clusters do Kubernetes

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

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

   Se a configuração do cluster tiver sido alterada recentemente, o botão de edição pode estar desativado. Se não conseguir editar as definições do cluster, aguarde alguns minutos e tente novamente.

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

5. Clique em Guardar alterações.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Nodepool boot CMEK disabled

Nome da categoria na API: NODEPOOL_BOOT_CMEK_DISABLED

Os discos de arranque neste conjunto de nós não estão encriptados com chaves de encriptação geridas pelo cliente (CMEK). As CMEK permitem que o utilizador configure as chaves de encriptação predefinidas para discos de arranque num conjunto de nós.

Atenção: estes passos de remediação podem interromper o seu ambiente de produção. Se for necessário, transfira cargas de trabalho, dados ou autorizações para novos recursos antes de eliminar recursos existentes.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Clusters do Kubernetes na Google Cloud consola.

   Aceda aos clusters do Kubernetes

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

3. Clique no separador Nós.

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

5. Quando lhe for pedido que confirme, clique em Eliminar.

6. Para criar novos node pools com CMEK, consulte o artigo Usar chaves de encriptação geridas pelo cliente (CMEK). A CMEK incorre em custos adicionais relacionados com o Cloud KMS.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Nodepool secure boot disabled

Nome da categoria na API: NODEPOOL_SECURE_BOOT_DISABLED

O arranque seguro está desativado para um cluster do GKE.

Ative o arranque seguro para nós do GKE protegidos para validar as assinaturas digitais dos componentes de arranque do nó. Para mais informações, consulte o artigo Arranque seguro.

Atenção: estes passos de remediação podem interromper o seu ambiente de produção. Se for necessário, transfira cargas de trabalho, dados ou autorizações para novos recursos antes de eliminar recursos existentes.

Para corrigir esta descoberta, conclua os seguintes passos:

Depois de um conjunto de nós ser aprovisionado, não é possível atualizá-lo para ativar o arranque seguro. Tem de criar um novo conjunto de nós com o arranque seguro ativado.

1. Aceda à página Clusters do Kubernetes na Google Cloud consola.

   Aceda aos clusters do Kubernetes

2. Clique no nome do cluster na descoberta.

3. Clique em Adicionar conjunto de nós.

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

   1. Clique no nome do novo conjunto de nós para expandir o separador.
   2. Selecione Segurança e, de seguida, em Opções protegidas, selecione Ativar arranque seguro.
   3. Clique em Criar.
   4. Para migrar as suas cargas de trabalho dos conjuntos de nós não conformes existentes para os novos conjuntos de nós, consulte o artigo Migrar cargas de trabalho para diferentes tipos de máquinas.
   5. Depois de mover as cargas de trabalho, elimine o conjunto de nós original não conforme.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Non org IAM member

Nome da categoria na API: NON_ORG_IAM_MEMBER

Um utilizador fora da sua organização ou projeto tem autorizações do IAM num projeto ou numa organização. Saiba mais acerca das autorizações de IAM.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página IAM na Google Cloud consola.

   Aceda ao IAM

2. Selecione a caixa de verificação junto aos utilizadores fora da sua organização ou projeto.

3. Clique em Remover.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Object versioning disabled

Nome da categoria na API: OBJECT_VERSIONING_DISABLED

O controlo de versões de objetos não está ativado num contentor de armazenamento onde os destinos estão configurados.

Para suportar a obtenção de objetos eliminados ou substituídos, o Cloud Storage oferece a funcionalidade de controlo de versões de objetos. Ative o controlo de versões de objetos para proteger os seus dados do Cloud Storage contra a substituição ou a eliminação acidental. Saiba como ativar o controlo de versões de objetos.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta deteção, use a flag --versioning num comando gcloud storage buckets update com o valor adequado:

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

Substitua finding.assetDisplayName pelo nome do contentor relevante.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Open Cassandra port

Nome da categoria na API: OPEN_CASSANDRA_PORT

As regras de firewall que permitem que qualquer endereço IP se ligue a portas Cassandra podem expor os seus serviços Cassandra a atacantes. Para mais informações, consulte o artigo Vista geral das regras da firewall da VPC.

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

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

Esta descoberta é gerada para regras de firewall vulneráveis, mesmo que desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam para configurações não seguras que permitem tráfego indesejável se estiverem ativadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Firewall na Google Cloud consola.

   Aceda à 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, elimine 0.0.0.0/0.

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

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

7. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Open ciscosecure websm port

Nome da categoria na API: OPEN_CISCOSECURE_WEBSM_PORT

As regras de firewall que permitem que qualquer endereço IP se ligue às portas CiscoSecure/WebSM podem expor os seus serviços CiscoSecure/WebSM a atacantes. Para mais informações, consulte o artigo Vista geral das regras da firewall da VPC.

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

• TCP - 9090

Esta descoberta é gerada para regras de firewall vulneráveis, mesmo que desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam para configurações não seguras que permitem tráfego indesejável se estiverem ativadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Firewall na Google Cloud consola.

   Aceda à 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, elimine 0.0.0.0/0.

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

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

7. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Open directory services port

Nome da categoria na API: OPEN_DIRECTORY_SERVICES_PORT

As regras de firewall que permitem que qualquer endereço IP se ligue às portas do diretório podem expor os seus serviços de diretório a atacantes. Para mais informações, consulte o artigo Vista geral das regras da firewall da VPC.

As portas do serviço de diretório são:

• TCP - 445
• UDP - 445

Esta descoberta é gerada para regras de firewall vulneráveis, mesmo que desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam para configurações não seguras que permitem tráfego indesejável se estiverem ativadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Firewall na Google Cloud consola.

   Aceda à 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, elimine 0.0.0.0/0.

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

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

7. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Open DNS port

Nome da categoria na API: OPEN_DNS_PORT

As regras de firewall que permitem que qualquer endereço IP se ligue a portas DNS podem expor os seus serviços DNS a atacantes. Para mais informações, consulte o artigo Vista geral das regras de firewall da VPC.

As portas do serviço DNS são:

• TCP - 53
• UDP - 53

Esta descoberta é gerada para regras de firewall vulneráveis, mesmo que desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam para configurações não seguras que permitem tráfego indesejável se estiverem ativadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Firewall na Google Cloud consola.

   Aceda à 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, elimine 0.0.0.0/0.

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

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

7. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Open Elasticsearch port

Nome da categoria na API: OPEN_ELASTICSEARCH_PORT

As regras de firewall que permitem que qualquer endereço IP se ligue às portas do Elasticsearch podem expor os seus serviços do Elasticsearch a atacantes. Para mais informações, consulte o artigo Vista geral das regras da firewall da VPC.

As portas do serviço Elasticsearch são:

• TCP - 9200, 9300

Esta descoberta é gerada para regras de firewall vulneráveis, mesmo que desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam para configurações não seguras que permitem tráfego indesejável se estiverem ativadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Firewall na Google Cloud consola.

   Aceda à 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, elimine 0.0.0.0/0.

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

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

7. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Open firewall

Nome da categoria na API: OPEN_FIREWALL

As regras de firewall que permitem ligações de todos os endereços IP, como 0.0.0.0/0, ou de todas as portas podem expor desnecessariamente recursos a ataques de origens não intencionais. Estas regras devem ser removidas ou definidas explicitamente para os intervalos de portas ou IPs de origem pretendidos. Por exemplo, em aplicações destinadas a ser públicas, considere restringir as portas permitidas às necessárias para a aplicação, como 80 e 443. Se a sua aplicação precisar de permitir ligações de todas as portas ou endereços IP, considere adicionar o recurso a uma lista de autorizações. Saiba mais sobre como atualizar regras de firewall.

Esta descoberta é gerada para regras de firewall vulneráveis, mesmo que desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam para configurações não seguras que permitem tráfego indesejável se estiverem ativadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Regras da firewall na Google Cloud consola.

   Aceda às regras de firewall

2. Clique na regra de firewall apresentada na descoberta do Security Health Analytics e, de seguida, clique em Editar.

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

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

5. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Open FTP port

Nome da categoria na API: OPEN_FTP_PORT

As regras de firewall que permitem que qualquer endereço IP se ligue a portas FTP podem expor os seus serviços FTP a atacantes. Para mais informações, consulte o artigo Vista geral das regras de firewall da VPC.

As portas do serviço FTP são:

• TCP - 21

Esta descoberta é gerada para regras de firewall vulneráveis, mesmo que desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam para configurações não seguras que permitem tráfego indesejável se estiverem ativadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Firewall na Google Cloud consola.

   Aceda à 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, elimine 0.0.0.0/0.

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

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

7. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Open group IAM member

Nome da categoria na API: OPEN_GROUP_IAM_MEMBER

Um ou mais responsáveis que têm acesso a uma organização, um projeto ou uma pasta são contas de grupos Google que podem ser associadas sem aprovação.

Google Cloud Os clientes podem usar os Grupos Google para gerir funções e autorizações para membros nas respetivas organizações ou aplicar políticas de acesso a coleções de utilizadores. Em vez de conceder funções diretamente aos membros, os administradores podem conceder funções e autorizações aos Grupos Google e, em seguida, adicionar membros a grupos específicos. Os membros do grupo herdam todas as funções e autorizações de um grupo, o que permite aos membros aceder a recursos e serviços específicos.

Se uma conta do Google Groups aberta for usada como principal numa associação do IAM, qualquer pessoa pode herdar a função associada apenas aderindo ao grupo diretamente ou indiretamente (através de um subgrupo). Recomendamos que revogue as funções dos grupos abertos ou restrinja o acesso a esses grupos.

Para corrigir esta descoberta, siga um dos seguintes procedimentos.

Remova o grupo da política IAM

Atenção: estes passos de remediação podem interromper o seu ambiente de produção. Se for necessário, transfira cargas de trabalho, dados ou autorizações para novos recursos antes de eliminar recursos existentes.

1. Aceda à página IAM na Google Cloud consola.

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

Restrinja o acesso aos grupos abertos

1. Inicie sessão nos Grupos Google.
2. Atualize as definições de cada grupo aberto e dos respetivos subgrupos para especificar quem pode aderir ao grupo e quem tem de aprovar a adesão.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Open HTTP port

Nome da categoria na API: OPEN_HTTP_PORT

As regras de firewall que permitem que qualquer endereço IP se ligue a portas HTTP podem expor os seus serviços HTTP a atacantes. Para mais informações, consulte o artigo Vista geral das regras de firewall da VPC.

As portas de serviço HTTP são:

• TCP - 80

Esta descoberta é gerada para regras de firewall vulneráveis, mesmo que desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam para configurações não seguras que permitem tráfego indesejável se estiverem ativadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Firewall na Google Cloud consola.

   Aceda à 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, elimine 0.0.0.0/0.

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

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

7. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Open LDAP port

Nome da categoria na API: OPEN_LDAP_PORT

As regras de firewall que permitem que qualquer endereço IP se ligue a portas LDAP podem expor os seus serviços LDAP a atacantes. Para mais informações, consulte o artigo Vista geral das regras de firewall da VPC.

As portas do serviço LDAP são:

• TCP - 389, 636
• UDP - 389

Esta descoberta é gerada para regras de firewall vulneráveis, mesmo que desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam para configurações não seguras que permitem tráfego indesejável se estiverem ativadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Firewall na Google Cloud consola.

   Aceda à 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, elimine 0.0.0.0/0.

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

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

7. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Open Memcached port

Nome da categoria na API: OPEN_MEMCACHED_PORT

As regras de firewall que permitem que qualquer endereço IP se ligue a portas Memcached podem expor os seus serviços Memcached a atacantes. Para mais informações, consulte o artigo Vista geral das regras da firewall da VPC.

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

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

Esta descoberta é gerada para regras de firewall vulneráveis, mesmo que desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam para configurações não seguras que permitem tráfego indesejável se estiverem ativadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Firewall na Google Cloud consola.

   Aceda à 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, elimine 0.0.0.0/0.

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

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

7. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Open MongoDB port

Nome da categoria na API: OPEN_MONGODB_PORT

As regras de firewall que permitem que qualquer endereço IP se ligue às portas do MongoDB podem expor os seus serviços do MongoDB a atacantes. Para mais informações, consulte o artigo Vista geral das regras da firewall da VPC.

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

• TCP - 27017, 27018, 27019

Esta descoberta é gerada para regras de firewall vulneráveis, mesmo que desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam para configurações não seguras que permitem tráfego indesejável se estiverem ativadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Firewall na Google Cloud consola.

   Aceda à 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, elimine 0.0.0.0/0.

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

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

7. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Open MySQL port

Nome da categoria na API: OPEN_MYSQL_PORT

As regras de firewall que permitem que qualquer endereço IP se ligue a portas MySQL podem expor os seus serviços MySQL a atacantes. Para mais informações, consulte o artigo Vista geral das regras de firewall da VPC.

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

• TCP - 3306

Esta descoberta é gerada para regras de firewall vulneráveis, mesmo que desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam para configurações não seguras que permitem tráfego indesejável se estiverem ativadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Firewall na Google Cloud consola.

   Aceda à 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, elimine 0.0.0.0/0.

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

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

7. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Open NetBIOS port

Nome da categoria na API: `OPEN_NETBIOS_PORT`

As regras de firewall que permitem que qualquer endereço IP se ligue a portas NetBIOS podem expor os seus serviços NetBIOS a atacantes. Para mais informações, consulte o artigo Vista geral das regras da firewall da VPC.

As portas de serviço NetBIOS são:

• TCP - 137, 138, 139
• UDP - 137, 138, 139

Esta descoberta é gerada para regras de firewall vulneráveis, mesmo que desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam para configurações não seguras que permitem tráfego indesejável se estiverem ativadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Firewall na Google Cloud consola.

   Aceda à 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, elimine 0.0.0.0/0.

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

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

7. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Open OracleDB port

Nome da categoria na API: OPEN_ORACLEDB_PORT

As regras de firewall que permitem que qualquer endereço IP se ligue a portas OracleDB podem expor os seus serviços OracleDB a atacantes. Para mais informações, consulte o artigo Vista geral das regras da firewall da VPC.

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

• TCP - 1521, 2483, 2484
• UDP - 2483, 2484

Esta descoberta é gerada para regras de firewall vulneráveis, mesmo que desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam para configurações não seguras que permitem tráfego indesejável se estiverem ativadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Firewall na Google Cloud consola.

   Aceda à 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, elimine 0.0.0.0/0.

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

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

7. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Open POP3 port

Nome da categoria na API: OPEN_POP3_PORT

As regras de firewall que permitem que qualquer endereço IP se ligue a portas POP3 podem expor os seus serviços POP3 a atacantes. Para mais informações, consulte o artigo Vista geral das regras de firewall da VPC.

As portas do serviço POP3 são:

• TCP - 110

Esta descoberta é gerada para regras de firewall vulneráveis, mesmo que desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam para configurações não seguras que permitem tráfego indesejável se estiverem ativadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Firewall na Google Cloud consola.

   Aceda à 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, elimine 0.0.0.0/0.

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

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

7. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Open PostgreSQL port

Nome da categoria na API: OPEN_POSTGRESQL_PORT

As regras de firewall que permitem que qualquer endereço IP se ligue a portas PostgreSQL podem expor os seus serviços PostgreSQL a atacantes. Para mais informações, consulte o artigo Vista geral das regras da firewall da VPC.

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

• TCP - 5432
• UDP - 5432

Esta descoberta é gerada para regras de firewall vulneráveis, mesmo que desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam para configurações não seguras que permitem tráfego indesejável se estiverem ativadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Firewall na Google Cloud consola.

   Aceda à 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, elimine 0.0.0.0/0.

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

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

7. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Open RDP port

Nome da categoria na API: OPEN_RDP_PORT

As regras de firewall que permitem que qualquer endereço IP se ligue a portas RDP podem expor os seus serviços RDP a atacantes. Para mais informações, consulte o artigo Vista geral das regras de firewall da VPC.

As portas de serviço de PDR são:

• TCP - 3389
• UDP - 3389

Esta descoberta é gerada para regras de firewall vulneráveis, mesmo que desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam para configurações não seguras que permitem tráfego indesejável se estiverem ativadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Firewall na Google Cloud consola.

   Aceda à 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, elimine 0.0.0.0/0.

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

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

7. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Open Redis port

Nome da categoria na API: OPEN_REDIS_PORT

As regras de firewall que permitem que qualquer endereço IP se ligue a portas Redis podem expor os seus serviços Redis a atacantes. Para mais informações, consulte o artigo Vista geral das regras de firewall da VPC.

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

• TCP - 6379

Esta descoberta é gerada para regras de firewall vulneráveis, mesmo que desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam para configurações não seguras que permitem tráfego indesejável se estiverem ativadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Firewall na Google Cloud consola.

   Aceda à 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, elimine 0.0.0.0/0.

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

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

7. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Open SMTP port

Nome da categoria na API: OPEN_SMTP_PORT

As regras de firewall que permitem que qualquer endereço IP se ligue a portas SMTP podem expor os seus serviços SMTP a atacantes. Para mais informações, consulte o artigo Vista geral das regras de firewall da VPC.

As portas do serviço SMTP são:

• TCP - 25

Esta descoberta é gerada para regras de firewall vulneráveis, mesmo que desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam para configurações não seguras que permitem tráfego indesejável se estiverem ativadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Firewall na Google Cloud consola.

   Aceda à 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, elimine 0.0.0.0/0.

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

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

7. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Open SSH port

Nome da categoria na API: OPEN_SSH_PORT

As regras de firewall que permitem que qualquer endereço IP se ligue a portas SSH podem expor os seus serviços SSH a atacantes. Para mais informações, consulte o artigo Vista geral das regras de firewall da VPC.

As portas de serviço SSH são:

• SCTP - 22
• TCP - 22

Esta descoberta é gerada para regras de firewall vulneráveis, mesmo que desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam para configurações não seguras que permitem tráfego indesejável se estiverem ativadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Firewall na Google Cloud consola.

   Aceda à 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, elimine 0.0.0.0/0.

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

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

7. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Open Telnet port

Nome da categoria na API: OPEN_TELNET_PORT

As regras de firewall que permitem que qualquer endereço IP se ligue a portas Telnet podem expor os seus serviços Telnet a atacantes. Para mais informações, consulte o artigo Vista geral das regras de firewall da VPC.

As portas de serviço Telnet são:

• TCP - 23

Esta descoberta é gerada para regras de firewall vulneráveis, mesmo que desative as regras intencionalmente. As descobertas ativas para regras de firewall desativadas alertam para configurações não seguras que permitem tráfego indesejável se estiverem ativadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Firewall na Google Cloud consola.

   Aceda à 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, elimine 0.0.0.0/0.

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

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

7. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 acerca desta restrição da política da organização, consulte o artigo Aplicação de restrições da política da organização.

A sua organização requer que esta VM tenha o serviço de VM confidencial ativado. As VMs que não têm este serviço ativado não usam a encriptação da memória de tempo de execução, o que as expõe a ataques de memória de tempo de execução.

Nota: a VM confidencial incorre em custos adicionais além dos preços do Compute Engine. Para mais informações, consulte a secção Preços.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias de VM na Google Cloud consola.

   Aceder às instâncias de VM

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

3. Se a VM não precisar do serviço de VM confidencial, mova-a para uma nova pasta ou projeto.

4. Se a VM exigir uma VM confidencial, clique em Eliminar.

5. Para criar uma nova instância com a Confidential VM ativada, consulte o artigo Início rápido: criar uma instância de Confidential VM.

Saiba mais sobre os recursos suportados e as definições de análise deste 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-lhe restringir a criação de novos recursos às regiões da nuvem que selecionar. Para mais informações, consulte o artigo Restringir localizações de recursos.

Nota: as restrições de localização de recursos não são aplicadas retroativamente. Por isso, se os valores das restrições mudarem, os recursos existentes não são alterados. Podem ser gerados resultados de ORG_POLICY_LOCATION_RESTRICTION se as localizações de recursos existentes violarem novas restrições.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta descoberta, conclua os seguintes passos:

O detetor 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 localização inclui o seguinte:

1. Copie, mova ou faça uma cópia de segurança do recurso fora da região ou dos respetivos dados para um recurso que esteja na região. Leia a documentação dos serviços individuais para receber instruções sobre como mover recursos.
2. Elimine o recurso original fora da região ou os respetivos dados.

Esta abordagem não é possível para todos os tipos de recursos. Para receber orientações, consulte as recomendações personalizadas fornecidas na descoberta.

Considerações adicionais

Ao corrigir esta descoberta, considere o seguinte.

Recursos geridos

Por vezes, os ciclos de vida dos recursos são geridos e controlados por outros recursos. Por exemplo, um grupo de instâncias gerido do Compute Engine cria e destrói instâncias do Compute Engine de acordo com a política de escala automática do grupo de instâncias. Se os recursos geridos e de gestão estiverem no âmbito da aplicação de restrições de localização, ambos podem ser sinalizados como a violar a política da organização. A correção das conclusões para recursos geridos deve ser feita no recurso de gestão para garantir a estabilidade operacional.

Recursos em utilização

Determinados recursos são usados por outros recursos. Por exemplo, um disco do Compute Engine associado a uma instância do Compute Engine em execução é considerado em utilização pela instância. Se o recurso em utilização violar a política da organização de localização, tem de garantir que o recurso não está em utilização antes de resolver a violação de localização.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

OS login disabled

Nome da categoria na API: OS_LOGIN_DISABLED

O Início de sessão do SO está desativado nas instâncias do Compute Engine neste projeto.

O Início de sessão do SO permite a gestão centralizada de chaves SSH com o IAM e desativa a configuração de chaves SSH baseada em metadados em todas as instâncias de um projeto. Saiba como configurar o início de sessão no SO.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Metadados na Google Cloud consola.

   Aceda aos metadados

2. Clique em Editar e, de seguida, em Adicionar item.

3. Adicione um item com a chave enable-oslogin e o valor TRUE.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Over privileged account

Nome da categoria na API: OVER_PRIVILEGED_ACCOUNT

Um nó do GKE está a usar o nó de serviço predefinido do Compute Engine, que tem um acesso amplo por predefinição e pode ter privilégios excessivos para executar o seu cluster do GKE.

Para corrigir esta descoberta, conclua os seguintes passos:

Siga as instruções para usar contas de serviço Google com o menor número possível de privilégios.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Over privileged scopes

Nome da categoria na API: OVER_PRIVILEGED_SCOPES

Uma conta de serviço de nó tem âmbitos de acesso amplos.

Os âmbitos de acesso são o método antigo de especificar autorizações para a sua instância. Para reduzir a possibilidade de uma escalada de privilégios num ataque, crie e use uma conta de serviço com privilégios mínimos para executar o seu cluster do GKE.

Para corrigir esta descoberta, siga as instruções para usar contas de serviço Google com o menor número possível de privilégios.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Over privileged service account user

Nome da categoria na API: OVER_PRIVILEGED_SERVICE_ACCOUNT_USER

Um utilizador tem as funções iam.serviceAccountUser ou iam.serviceAccountTokenCreator ao nível do projeto, da pasta ou da organização, em vez de para uma conta de serviço específica.

A atribuição dessas funções a um utilizador para um projeto, uma pasta ou uma organização dá ao utilizador acesso a todas as contas de serviço existentes e futuras nesse âmbito. Esta situação pode resultar num escalamento não intencional de privilégios. Para mais informações, consulte o artigo Autorizações da conta de serviço.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página IAM na Google Cloud consola.

   Aceda à página do IAM

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

3. Para cada principal atribuído roles/iam.serviceAccountUser ou roles/iam.serviceAccountTokenCreator, faça o seguinte:

   1. Clique em Editar.
   2. No painel Editar autorizações, junto às funções, clique em Eliminar.
   3. Clique em Guardar.

4. Siga este guia para conceder a utilizadores individuais autorização para se fazerem passar por uma única conta de serviço. Tem de seguir o guia para cada conta de serviço que quer permitir que os utilizadores escolhidos representem.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Owner not monitored

Nome da categoria na API: OWNER_NOT_MONITORED

As métricas e os alertas de registo não estão configurados para monitorizar as atribuições ou as alterações de propriedade do projeto.

A função de IAM proprietário tem o nível de privilégio mais elevado num projeto. Para proteger os seus recursos, configure alertas para receber notificações quando novos proprietários são adicionados ou removidos. Para mais informações, consulte o artigo Vista geral das métricas baseadas em registos.

Consoante a quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para compreender a sua utilização do serviço e os respetivos custos, consulte os preços da observabilidade do Google Cloud.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta descoberta, conclua os seguintes passos:

Crie uma métrica

1. Aceda à página Métricas baseadas em registos na Google Cloud consola.

   Aceda a Métricas baseadas em registos

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 registo.
   2. Adicione uma descrição.
   3. Defina Unidades como 1.

5. Em Seleção de filtros, copie e cole o seguinte texto 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. É apresentada uma confirmação.

Crie uma política de alerta

1. Na Google Cloud consola, aceda à página Métricas baseadas em registos:

   Aceda a Métricas baseadas em registos

   Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cuja legenda é Registo.

2. Na secção Métricas definidas pelo utilizador, selecione a métrica que criou na secção anterior.

3. Clique em Mais e, de seguida, clique em Criar alerta a partir da métrica.

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

4. Clicar em Seguinte.
   1. Reveja as definições pré-preenchidas. É recomendável modificar o Valor do limite.
   2. Clique em Nome da condição e introduza um nome para a condição.
5. Clicar em Seguinte.

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, de seguida, clique em OK.

   Para receber uma notificação quando os incidentes são abertos e fechados, selecione a opção Notificar no encerramento do incidente. Por predefinição, as notificações são enviadas apenas quando são abertos incidentes.

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

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Pod security policy disabled

Nome da categoria na API: POD_SECURITY_POLICY_DISABLED

O PodSecurityPolicy está desativado num cluster do GKE.

Um PodSecurityPolicy é um recurso de controlador de admissão que valida pedidos para criar e atualizar pods num cluster. Os clusters não aceitam pods que não cumpram as condições definidas no PodSecurityPolicy.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta descoberta, defina e autorize PodSecurityPolicies e ative o controlador PodSecurityPolicy. Para ver instruções, consulte a secção Usar o PodSecurityPolicies.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Primitive roles used

Nome da categoria na API: PRIMITIVE_ROLES_USED

Um utilizador tem uma das seguintes funções básicas de IAM: roles/owner, roles/editor ou roles/viewer. Estas funções são demasiado permissivas e não devem ser usadas. Em alternativa, devem ser atribuídos apenas por projeto.

Para mais informações, consulte o artigo Compreender as funções.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página da política IAM na Google Cloud consola.

   Aceder à política IAM

2. Para cada utilizador ao qual foi atribuída uma função primitiva, considere usar funções mais detalhadas em alternativa.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Private cluster disabled

Nome da categoria na API: PRIVATE_CLUSTER_DISABLED

Um cluster do GKE tem um cluster privado desativado.

Os clusters privados permitem que os nós tenham apenas endereços IP privados. Esta funcionalidade limita o acesso à Internet de saída para os nós. Se um nó do cluster não tiver um endereço IP público, não é detetável nem exposto à Internet pública. Ainda pode encaminhar tráfego para um nó através de um balanceador de carga interno. Para mais informações, consulte o artigo Clusters privados.

Não pode tornar um cluster existente privado. Para corrigir esta descoberta, crie um novo cluster privado:

1. Aceda à página Clusters do Kubernetes na Google Cloud consola.

   Aceda aos 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 privado.

5. Em Opções de redes avançadas, selecione a caixa de verificação Ativar encaminhamento de tráfego nativo da VPC (usa o IP de alias).

6. Clique em Criar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Private Google access disabled

Nome da categoria na API: PRIVATE_GOOGLE_ACCESS_DISABLED

Existem sub-redes privadas sem acesso às APIs públicas da Google.

O acesso privado à Google permite que as instâncias de VM com apenas endereços IP internos (privados) alcancem os endereços IP públicos das APIs e dos serviços Google.

Para mais informações, consulte o artigo Configurar o acesso privado da Google.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Redes VPC na Google Cloud consola.

   Aceda a redes de VPC

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

3. Na página Detalhes da rede VPC, clique no separador Sub-redes.

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

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

6. Em Acesso privado à Google, selecione Ativado.

7. Clique em Guardar.

8. Para remover IPs públicos (externos) de instâncias de VM cujo único tráfego externo se destina às APIs Google, consulte o artigo Desatribuir um endereço IP externo estático.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Public bucket ACL

Nome da categoria na API: PUBLIC_BUCKET_ACL

Um contentor é público e qualquer pessoa na Internet pode aceder ao mesmo.

Para mais informações, consulte o artigo Vista geral do controlo de acesso.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Explorador de armazenamento na Google Cloud consola.

   Aceda ao navegador de armazenamento

2. Selecione o contentor indicado na descoberta do Security Health Analytics.

3. Na página Detalhes do contentor, clique no separador Autorizações.

4. Junto a Vista por, clique em Funções.

5. Na caixa Filtro, pesquise allUsers e allAuthenticatedUsers.

6. Clique em Eliminar para remover todas as autorizações da IAM concedidas a allUsers e allAuthenticatedUsers.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 aceder à mesma. allUsers representa qualquer pessoa na Internet e allAuthenticatedUsers representa qualquer pessoa autenticada com uma Conta Google. Nenhuma das opções está restrita a utilizadores na sua organização.

As imagens do Compute Engine podem conter informações confidenciais, como chaves de encriptação ou software licenciado. Estas informações confidenciais não devem estar acessíveis publicamente. Se pretendia tornar esta imagem do Compute Engine pública, certifique-se de que não contém informações confidenciais.

Para mais informações, consulte a vista geral do controlo de acesso.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página de imagens do Compute Engine na Google Cloud consola.

   Aceda às imagens do Compute Engine

2. Selecione a caixa junto à imagem public-image e, de seguida, clique em Mostrar painel de informações.

3. Na caixa Filtro, pesquise os responsáveis por allUsers e allAuthenticatedUsers.

4. Expanda a função para a qual quer remover utilizadores.

5. Clique em Eliminar para remover um utilizador dessa função.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 principal da IAM allUsers representa qualquer pessoa na Internet e allAuthenticatedUsers representa qualquer pessoa com sessão iniciada num serviço Google. Nenhum dos dois está restrito a utilizadores na sua organização.

Para mais informações, consulte o artigo Controlar o acesso a conjuntos de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Explorador do BigQuery na Google Cloud consola.

   Aceda ao conjunto de dados do BigQuery

2. Na lista de conjuntos de dados, clique no nome do conjunto de dados que é identificado na descoberta. É aberto o painel Informações do conjunto de dados.

3. Junto à parte superior do painel Informações do conjunto de dados, clique em PARTILHAR.

4. No menu pendente, clique em Autorizações.

5. No painel Autorizações do conjunto de dados, introduza allUsers e allAuthenticatedUsers e remova o acesso para estes principais.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 suas organizações, evite atribuir endereços IP públicos às suas VMs. As instâncias paradas podem continuar a ser denunciadas com uma descoberta de IP público, por exemplo, se as interfaces de rede estiverem configuradas para atribuir um IP público efémero no início. Certifique-se de que as configurações de rede para instâncias paradas não incluem acesso externo.

Para mais informações, consulte o artigo Estabelecer ligação segura a instâncias de VM.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias de VM na Google Cloud consola.

   Aceda a Instâncias de VM

2. Na lista de instâncias, selecione a caixa junto ao 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, de seguida, clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Public log bucket

Nome da categoria na API: PUBLIC_LOG_BUCKET

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

Um contentor de armazenamento é público e usado como um destino de registo, o que significa que qualquer pessoa na Internet pode aceder aos registos armazenados neste contentor. allUsers representa qualquer pessoa na Internet e allAuthenticatedUsers representa qualquer pessoa que tenha sessão iniciada num serviço Google. Nenhum dos dois está restrito a utilizadores na sua organização.

Para mais informações, consulte o artigo Vista geral do controlo de acesso.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página do navegador do Cloud Storage na Google Cloud consola.

   Aceda ao navegador do Cloud Storage

2. Na lista de contentores, clique no nome do contentor indicado na descoberta.

3. Clique no separador Autorizações.

4. Remova allUsers e allAuthenticatedUsers da lista de diretores.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Public SQL instance

Nome da categoria na API: PUBLIC_SQL_INSTANCE

A sua instância do SQL tem 0.0.0.0/0 como uma rede permitida. Esta ocorrência significa que qualquer cliente IPv4 pode passar a firewall de rede e fazer tentativas de início de sessão na sua instância, incluindo clientes que pode não ter tido intenção de permitir. Os clientes continuam a precisar de credenciais válidas para iniciar sessão com êxito na sua instância.

Para mais informações, consulte o artigo Autorizar com redes autorizadas.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. No painel de navegação, clique em Ligações.

5. Em Redes autorizadas, elimine 0.0.0.0/0 e adicione endereços IP específicos ou intervalos de IP que quer permitir que se liguem à sua instância.

6. Clique em Concluído e, de seguida, clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Pubsub CMEK disabled

Nome da categoria na API: PUBSUB_CMEK_DISABLED

Um tópico do Pub/Sub não está encriptado com chaves de encriptação geridas pelo cliente (CMEK).

Com as CMEK, as chaves que cria e gere no Cloud KMS envolvem as chaves que a Google usa para encriptar os seus dados, o que lhe dá mais controlo sobre o acesso aos seus dados.

Atenção: estes passos de remediação podem interromper o seu ambiente de produção. Se for necessário, transfira cargas de trabalho, dados ou autorizações para novos recursos antes de eliminar recursos existentes.

Para corrigir esta descoberta, elimine o tópico existente e crie um novo:

1. Aceda à página Tópicos do Pub/Sub na Google Cloud consola.

   Aceda a Tópicos

2. Se necessário, selecione o projeto que contém o tópico do Pub/Sub.

3. Selecione a caixa de verificação junto ao tópico indicado na descoberta e, de seguida, clique em Eliminar.

4. Para criar um novo tópico do Pub/Sub com as CMEK ativadas, consulte o artigo Usar chaves de encriptação geridas pelo cliente. A CMEK incorre em custos adicionais relacionados com o Cloud KMS.

5. Publicar resultados ou outros dados no tópico do Pub/Sub ativado com CMEK.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Route not monitored

Nome da categoria na API: ROUTE_NOT_MONITORED

Nota: o filtro de métricas baseadas em registos para este detetor foi alterado a 27 de outubro de 2021.

As métricas e os alertas de registo não estão configurados para monitorizar as alterações de rotas da rede VPC.

Google Cloud As rotas são destinos e saltos que definem o caminho que o tráfego de rede percorre a partir de uma instância de VM para um IP de destino. Ao monitorizar as alterações às tabelas de rotas, pode ajudar a garantir que todo o tráfego da VPC flui através de um caminho esperado.

Para mais informações, consulte o artigo Vista geral das métricas baseadas em registos.

Consoante a quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para compreender a sua utilização do serviço e os respetivos custos, consulte os preços da observabilidade do Google Cloud.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta descoberta, conclua os seguintes passos:

Crie uma métrica

1. Aceda à página Métricas baseadas em registos na Google Cloud consola.

   Aceda a Métricas baseadas em registos

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 registo.
   2. Adicione uma descrição.
   3. Defina Unidades como 1.

5. Em Seleção de filtros, copie e cole o seguinte texto 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. É apresentada uma confirmação.

Crie uma política de alerta

1. Na Google Cloud consola, aceda à página Métricas baseadas em registos:

   Aceda a Métricas baseadas em registos

   Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cuja legenda é Registo.

2. Na secção Métricas definidas pelo utilizador, selecione a métrica que criou na secção anterior.

3. Clique em Mais e, de seguida, clique em Criar alerta a partir da métrica.

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

4. Clicar em Seguinte.
   1. Reveja as definições pré-preenchidas. É recomendável modificar o Valor do limite.
   2. Clique em Nome da condição e introduza um nome para a condição.
5. Clicar em Seguinte.

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, de seguida, clique em OK.

   Para receber uma notificação quando os incidentes são abertos e fechados, selecione a opção Notificar no encerramento do incidente. Por predefinição, as notificações são enviadas apenas quando são abertos incidentes.

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

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Redis role used on org

Nome da categoria na API: REDIS_ROLE_USED_ON_ORG

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

É atribuída uma função do IAM do Redis ao nível da organização ou da pasta.

As seguintes funções do IAM do Redis devem ser atribuídas apenas por projeto e não ao nível da organização ou da pasta:

• roles/redis.admin
• roles/redis.viewer
• roles/redis.editor

Para mais informações, consulte o artigo Controlo de acesso e autorizações.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página da política IAM na Google Cloud consola.

   Aceder à política IAM

2. Remova as funções do IAM do Redis indicadas na descoberta e adicione-as nos projetos individuais.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Release channel disabled

Nome da categoria na API: RELEASE_CHANNEL_DISABLED

Um cluster do GKE não está subscrito num canal de lançamento.

Subscreva um canal de lançamento para automatizar as atualizações de versões para o cluster do GKE. As funcionalidades também reduzem a complexidade da gestão de versões ao número de funcionalidades e ao nível de estabilidade necessários. Para mais informações, consulte o artigo Canais de lançamento.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Clusters do Kubernetes na Google Cloud consola.

   Aceda aos clusters do Kubernetes

2. Na secção Noções básicas do cluster, clique em Atualizar versão principal do cluster na linha Canal de lançamento.

   Se a configuração do cluster tiver sido alterada recentemente, o botão de edição pode estar desativado. Se não conseguir editar as definições do cluster, aguarde alguns minutos e tente novamente.

3. Na caixa de diálogo, selecione Canal de lançamento e, de seguida, escolha o canal de lançamento ao qual quer subscrever.

   Se a versão do painel de controlo do seu cluster não for atualizável para um canal de lançamento, esse canal pode ser desativado como opção.

4. Clique em Guardar alterações.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

RSASHA1 for signing

Nome da categoria na API: RSASHA1_FOR_SIGNING

O RSASHA1 é usado para a assinatura de chaves em zonas do Cloud DNS. O algoritmo usado para a assinatura de chaves não deve ser fraco.

Para corrigir esta descoberta, substitua o algoritmo por um recomendado seguindo o guia Usar opções de assinatura avançadas.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Service account key not rotated

Nome da categoria na API: SERVICE_ACCOUNT_KEY_NOT_ROTATED

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

Uma chave de conta de serviço gerida pelo utilizador não é alterada há mais de 90 dias.

Em geral, as chaves de contas de serviço geridas pelo utilizador devem ser alteradas, pelo menos, a cada 90 dias, para garantir que não é possível aceder aos dados com uma chave antiga que possa ter sido perdida, comprometida ou roubada. Para mais informações, consulte o artigo Rode as chaves da conta de serviço para reduzir o risco de segurança causado por chaves roubadas.

Se gerou o par de chaves públicas/privadas, armazenou a chave privada num módulo de segurança de hardware (HSM) e carregou a chave pública para a Google, pode não precisar de rodar a chave a cada 90 dias. Em alternativa, pode alternar para uma chave se considerar que esta pode ter sido comprometida.

Atenção: estes passos de remediação podem interromper o seu ambiente de produção.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Contas de serviço na Google Cloud consola.

   Aceda a Contas de serviço

2. Se necessário, selecione o projeto indicado na deteção.

3. Na lista de contas de serviço, encontre a conta de serviço apresentada na constatação.

4. Clique no separador Chaves e, em seguida, identifique a chave que quer desativar.

5. Para desativar a chave, siga as instruções em Desative uma chave de conta de serviço.

6. Opcional: depois de se certificar de que a chave já não está a ser usada, elimine a chave da conta de serviço.

   Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Service account role separation

Nome da categoria na API: SERVICE_ACCOUNT_ROLE_SEPARATION

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

Um ou mais responsáveis na sua organização têm várias autorizações de conta de serviço atribuídas. Nenhuma conta deve ter simultaneamente a função de administrador da conta de serviço juntamente com outras autorizações da conta de serviço. Para saber mais sobre as contas de serviço e as funções disponíveis para as mesmas, consulte o artigo Contas de serviço.

Atenção: estes passos de remediação podem interromper o seu ambiente de produção. Se for necessário, transfira cargas de trabalho, dados ou autorizações para novos recursos antes de eliminar recursos existentes.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página IAM na Google Cloud consola.

   Aceda ao IAM

2. Para cada principal indicado na descoberta, faça o seguinte:

   1. Verifique se a função foi herdada de uma pasta ou de um recurso da organização consultando a coluna Herança. Se a coluna contiver um link para um recurso principal, clique no link para aceder à página IAM do recurso principal.
   2. Clique em Editar junto a um principal.
   3. Para remover autorizações, clique em Eliminar junto a Administrador da conta de serviço. Se quiser remover todas as autorizações da conta de serviço, clique em Eliminar junto a todas as outras autorizações.

3. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 Google Cloud Platform reforçadas por um conjunto de controlos de segurança que ajudam a defender contra rootkits e bootkits. As VMs protegidas ajudam a garantir que o carregador de arranque e o firmware estão assinados e validados. Saiba mais sobre a VM protegida.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias de VM na Google Cloud consola.

   Aceder às instâncias de VM

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

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

4. Depois de a instância parar, clique em Editar.

5. Na secção VM protegida, ative as opções Ativar vTPM e Ativar monitorização da integridade para ativar a VM protegida.

6. Opcionalmente, se não usar controladores personalizados ou não assinados, ative também o Arranque seguro.

7. Clique em Guardar. A nova configuração é apresentada na página Detalhes da instância.

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

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL CMEK disabled

Nome da categoria na API: SQL_CMEK_DISABLED

Uma instância da base de dados SQL não está a usar chaves de encriptação geridas pelo cliente (CMEK).

Com as CMEK, as chaves que cria e gere no Cloud KMS envolvem as chaves que a Google usa para encriptar os seus dados, o que lhe dá mais controlo sobre o acesso aos seus dados. Para mais informações, consulte as vistas gerais da CMEK para o seu produto: Cloud SQL para MySQL, Cloud SQL para PostgreSQL ou Cloud SQL para SQL Server. A CMEK incorre em custos adicionais relacionados com o Cloud KMS.

Atenção: estes passos de remediação podem interromper o seu ambiente de produção. Se for necessário, transfira cargas de trabalho, dados ou autorizações para novos recursos antes de eliminar recursos existentes.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Eliminar.

4. Para criar uma nova instância com as CMEK ativadas, siga as instruções para configurar as CMEK para o seu produto:

   1. Cloud SQL para MySQL
   2. Cloud SQL para PostgreSQL
   3. Cloud SQL para SQL Server

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL contained database authentication

Nome da categoria na API: SQL_CONTAINED_DATABASE_AUTHENTICATION

Uma instância de base de dados do Cloud SQL para SQL Server não tem a flag de base de dados contained database authentication definida como Off.

A flag contained database authentication controla se pode criar ou anexar bases de dados contidas ao motor de base de dados. Uma base de dados autónoma inclui todas as definições e metadados da base de dados necessários para definir a base de dados e não tem dependências de configuração na instância do motor de base de dados onde a base de dados está instalada.

Não é recomendável ativar esta flag pelos seguintes motivos:

• Os utilizadores podem ligar-se à base de dados sem autenticação ao nível do motor da base de dados.
• Isolar a base de dados do motor de base de dados permite mover a base de dados para outra instância do SQL Server.

As bases de dados autónomas enfrentam ameaças únicas que devem ser compreendidas e mitigadas pelos administradores do motor de base de dados do SQL Server. A maioria das ameaças resulta do processo de autenticação de UTILIZADOR COM PALAVRA-PASSE, que move o limite de autenticação do nível do motor de base de dados para o nível da base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Database flags, defina o flag da base de dados contained database authentication com o valor Off.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL cross DB ownership chaining

Nome da categoria na API: SQL_CROSS_DB_OWNERSHIP_CHAINING

Uma instância da base de dados do Cloud SQL para SQL Server não tem a flag da base de dados cross db ownership chaining definida como Off.

A flag cross db ownership chaining permite-lhe controlar a união de proprietários entre bases de dados ao nível da base de dados ou permitir a união de proprietários entre bases de dados para todas as declarações de bases de dados.

Não é recomendável ativar esta flag, a menos que todas as bases de dados alojadas pela instância do SQL Server participem na encadeamento de propriedade entre bases de dados e tenha conhecimento das implicações de segurança desta definição.

Para mais informações, consulte o artigo Configurar flags da base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Flags da base de dados, defina o flag da base de dados cross db ownership chaining com o valor Desativado.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL external scripts enabled

Nome da categoria na API: SQL_EXTERNAL_SCRIPTS_ENABLED

Uma instância de base de dados do Cloud SQL para SQL Server não tem a flag de base de dados external scripts enabled definida como Off.

Quando ativada, esta definição permite a execução de scripts com determinadas extensões de linguagem remotas. Uma vez que esta funcionalidade pode afetar negativamente a segurança do sistema, recomendamos que a desative.

Para mais informações, consulte o artigo Configurar flags de base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Flags da base de dados, defina a flag da base de dados external scripts enabled com o valor Desativado.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL instance not monitored

Nome da categoria na API: SQL_INSTANCE_NOT_MONITORED

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

As métricas e os alertas de registo não estão configurados para monitorizar as alterações de configuração da instância do Cloud SQL.

A configuração incorreta das opções da instância do SQL pode causar riscos de segurança. A desativação das opções de cópia de segurança automática e de alta disponibilidade pode afetar a continuidade da empresa e a não restrição das redes autorizadas pode aumentar a exposição a redes não fidedignas. A monitorização das alterações à configuração da instância SQL ajuda a reduzir o tempo necessário para detetar e corrigir configurações incorretas.

Para mais informações, consulte o artigo Vista geral das métricas baseadas em registos.

Consoante a quantidade de informações, os custos do Cloud Monitoring podem ser significativos. Para compreender a sua utilização do serviço e os respetivos custos, consulte os preços da observabilidade do Google Cloud.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta descoberta, conclua os seguintes passos:

Crie uma métrica

1. Aceda à página Métricas baseadas em registos na Google Cloud consola.

   Aceda a Métricas baseadas em registos

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 registo.
   2. Adicione uma descrição.
   3. Defina Unidades como 1.

5. Em Seleção de filtros, copie e cole o seguinte texto 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. É apresentada uma confirmação.

Crie uma política de alerta

1. Na Google Cloud consola, aceda à página Métricas baseadas em registos:

   Aceda a Métricas baseadas em registos

   Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cuja legenda é Registo.

2. Na secção Métricas definidas pelo utilizador, selecione a métrica que criou na secção anterior.

3. Clique em Mais e, de seguida, clique em Criar alerta a partir da métrica.

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

4. Clicar em Seguinte.
   1. Reveja as definições pré-preenchidas. É recomendável modificar o Valor do limite.
   2. Clique em Nome da condição e introduza um nome para a condição.
5. Clicar em Seguinte.

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, de seguida, clique em OK.

   Para receber uma notificação quando os incidentes são abertos e fechados, selecione a opção Notificar no encerramento do incidente. Por predefinição, as notificações são enviadas apenas quando são abertos incidentes.

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

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL local infile

Nome da categoria na API: SQL_LOCAL_INFILE

Uma instância da base de dados do Cloud SQL para MySQL não tem a flag da base de dados local_infile definida como Desativada. Devido a problemas de segurança associados à flag local_infile, esta deve ser desativada. Para mais informações, consulte o artigo Configurar flags da base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Sinalizadores da base de dados, defina o sinalizador da base de dados local_infile com o valor Desativado.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL log checkpoints disabled

Nome da categoria na API: SQL_LOG_CHECKPOINTS_DISABLED

Uma instância da base de dados do Cloud SQL para PostgreSQL não tem a flag da base de dados log_checkpoints definida como On.

A ativação de log_checkpoints faz com que os controlos de segurança e os pontos de reinício sejam registados no registo do servidor. Algumas estatísticas estão incluídas nas mensagens de registo, incluindo o número de buffers escritos e o tempo gasto a escrevê-los.

Para mais informações, consulte o artigo Configurar flags da base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Sinalizadores da base de dados, defina o sinalizador da base de dados log_checkpoints com o valor Ativado.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL log connections disabled

Nome da categoria na API: SQL_LOG_CONNECTIONS_DISABLED

Uma instância da base de dados do Cloud SQL para PostgreSQL não tem a flag da base de dados log_connections definida como On.

A ativação da definição log_connections faz com que as tentativas de ligação ao servidor sejam registadas, juntamente com a conclusão bem-sucedida da autenticação do cliente. Os registos podem ser úteis na resolução de problemas e na confirmação de tentativas de ligação invulgares ao servidor.

Para mais informações, consulte o artigo Configurar flags da base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Sinalizadores da base de dados, defina o sinalizador da base de dados log_connections com o valor Ativado.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL log disconnections disabled

Nome da categoria na API: SQL_LOG_DISCONNECTIONS_DISABLED

Uma instância da base de dados do Cloud SQL para PostgreSQL não tem a flag da base de dados log_disconnections definida como On.

A ativação da definição log_disconnections cria entradas de registo no final de cada sessão. Os registos são úteis para resolver problemas e confirmar atividade invulgar durante um período. Para mais informações, consulte o artigo Configurar flags de base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Sinalizadores da base de dados, defina o sinalizador da base de dados log_disconnections com o valor Ativado.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL log duration disabled

Nome da categoria na API: SQL_LOG_DURATION_DISABLED

Uma instância da base de dados do Cloud SQL para PostgreSQL não tem a flag da base de dados log_duration definida como On.

Quando log_duration está ativado, esta definição faz com que o tempo de execução e a duração de cada declaração concluída sejam registados. A monitorização da quantidade de tempo necessária para executar consultas pode ser crucial na identificação de consultas lentas e na resolução de problemas da base de dados.

Para mais informações, consulte o artigo Configurar flags da base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Flags da base de dados, defina a flag da base de dados log_duration como Ativada.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL log error verbosity

Nome da categoria na API: SQL_LOG_ERROR_VERBOSITY

Uma instância da base de dados do Cloud SQL para PostgreSQL não tem a flag da base de dados log_error_verbosity definida como predefinição ou detalhada.

A flag log_error_verbosity controla a quantidade de detalhes nas mensagens registadas. Quanto maior for a verbosidade, mais detalhes são registados nas mensagens. Recomendamos que defina esta flag como default ou verbose.

Para mais informações, consulte o artigo Configurar flags da base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Flags da base de dados, defina a flag da base de dados log_error_verbosity como default ou verbose.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL log lock waits disabled

Nome da categoria na API: SQL_LOG_LOCK_WAITS_DISABLED

Uma instância de base de dados do Cloud SQL para PostgreSQL não tem a flag de base de dados log_lock_waits definida como On.

A ativação da definição log_lock_waits cria entradas de registo quando as esperas de sessão demoram mais tempo do que o tempo deadlock_timeout para adquirir um bloqueio. Os registos são úteis para determinar se os tempos de espera de bloqueio estão a causar um fraco desempenho.

Para mais informações, consulte o artigo Configurar flags da base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Sinalizadores da base de dados, defina o sinalizador da base de dados log_lock_waits com o valor Ativado.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL log min duration statement enabled

Nome da categoria na API: SQL_LOG_MIN_DURATION_STATEMENT_ENABLED

Uma instância de base de dados do Cloud SQL para PostgreSQL não tem a flag de base de dados log_min_duration_statement definida como -1.

A flag log_min_duration_statement faz com que as declarações SQL cuja execução demore mais do que um tempo especificado sejam registadas. Considere desativar esta definição, uma vez que as declarações SQL podem conter informações confidenciais que não devem ser registadas. Para mais informações, consulte o artigo Configurar flags de base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Sinalizadores da base de dados, defina o sinalizador da base de dados log_min_duration_statement com o valor -1.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL log min error statement

Nome da categoria na API: SQL_LOG_MIN_ERROR_STATEMENT

Uma instância da base de dados do Cloud SQL para PostgreSQL não tem a flag da base de dados log_min_error_statement definida corretamente.

A flag log_min_error_statement controla se as declarações SQL que causam condições de erro são registadas nos registos do servidor. As declarações SQL da gravidade especificada ou superior são registadas com mensagens para as declarações de erro. Quanto maior for a gravidade, menor é o número de mensagens gravadas.

Se log_min_error_statement não estiver definido com o valor correto, as mensagens podem não ser classificadas como mensagens de erro. Uma gravidade definida demasiado baixa pode aumentar o número de mensagens e dificultar a localização de erros reais. Uma gravidade definida como demasiado alta pode fazer com que as mensagens de erro para erros reais não sejam registadas.

Para mais informações, consulte o artigo Configurar flags da base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Sinalizadores da base de dados, defina o sinalizador da base de dados log_min_error_statement com um dos seguintes valores recomendados, de acordo com a política de registo da sua organização.

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

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL log min error statement severity

Nome da categoria na API: SQL_LOG_MIN_ERROR_STATEMENT_SEVERITY

Uma instância da base de dados do Cloud SQL para PostgreSQL não tem a flag da base de dados log_min_error_statement definida corretamente.

A flag log_min_error_statement controla se as declarações SQL que causam condições de erro são registadas nos registos do servidor. As declarações SQL da gravidade especificada ou mais rigorosas são registadas com mensagens para as declarações de erro. Quanto mais rigorosa for a gravidade, menos mensagens são registadas.

Se log_min_error_statement não estiver definido com o valor correto, as mensagens podem não ser classificadas como mensagens de erro. Uma gravidade definida demasiado baixa aumentaria o número de mensagens e dificultaria a localização de erros reais. Um nível de gravidade demasiado elevado (demasiado rigoroso) pode fazer com que as mensagens de erro de erros reais não sejam registadas.

Recomendamos que defina esta flag como error ou mais rigorosa.

Para mais informações, consulte o artigo Configurar flags da base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Sinalizadores da base de dados, defina o sinalizador da base de dados log_min_error_statement com um dos seguintes valores recomendados, de acordo com a política de registo da sua organização.

   • error
   • log
   • fatal
   • panic

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL log min messages

Nome da categoria na API: SQL_LOG_MIN_MESSAGES

Uma instância da base de dados do Cloud SQL para PostgreSQL não tem a flag da base de dados log_min_messages definida, no mínimo, como aviso.

A flag log_min_messages controla os níveis de mensagens que são registados nos registos do servidor. Quanto maior for a gravidade, menor é o número de mensagens registadas. Se definir o limite demasiado baixo, pode aumentar o tamanho e a duração do armazenamento de registos, o que dificulta a localização de erros reais.

Para mais informações, consulte o artigo Configurar flags de base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Sinalizadores da base de dados, defina o sinalizador da base de dados log_min_messages com um dos seguintes valores recomendados, de acordo com a política de registo da sua organização.

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

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL log executor stats enabled

Nome da categoria na API: SQL_LOG_EXECUTOR_STATS_ENABLED

Uma instância da base de dados do Cloud SQL para PostgreSQL não tem a flag da base de dados log_executor_stats definida como Off.

Quando a flag log_executor_stats está ativada, as estatísticas de desempenho do executor são incluídas nos registos do PostgreSQL para cada consulta. Esta definição pode ser útil para resolver problemas, mas pode aumentar significativamente o número de registos e a sobrecarga de desempenho.

Para mais informações, consulte o artigo Configurar flags da base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Sinalizadores da base de dados, defina o sinalizador da base de dados log_executor_stats como Desativado.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL log hostname enabled

Nome da categoria na API: `SQL_LOG_HOSTNAME_ENABLED

Uma instância da base de dados do Cloud SQL para PostgreSQL não tem a flag da base de dados log_hostname definida como Desativada.

Quando a flag log_hostname está ativada, o nome do anfitrião do anfitrião que está a estabelecer ligação é registado. Por predefinição, as mensagens do registo de ligações mostram apenas o endereço IP. Esta definição pode ser útil para a resolução de problemas. No entanto, pode incorrer em sobrecarga no desempenho do servidor, porque, para cada declaração registada, é necessária a resolução de DNS para converter um endereço IP num nome de anfitrião.

Para mais informações, consulte o artigo Configurar flags da base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Flags da base de dados, defina a flag da base de dados log_hostname como Desativado.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL log parser stats enabled

Nome da categoria na API: SQL_LOG_PARSER_STATS_ENABLED

Uma instância da base de dados do Cloud SQL para PostgreSQL não tem a flag da base de dados log_parser_stats definida como Desativado.

Quando a flag log_parser_stats está ativada, as estatísticas de desempenho do analisador são incluídas nos registos do PostgreSQL para cada consulta. Isto pode ser útil para a resolução de problemas, mas pode aumentar significativamente o número de registos e a sobrecarga de desempenho.

Para mais informações, consulte o artigo Configurar flags da base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Flags da base de dados, defina a flag da base de dados log_parser_stats como Desativado.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL log planner stats enabled

Nome da categoria na API: SQL_LOG_PLANNER_STATS_ENABLED

Uma instância da base de dados do Cloud SQL para PostgreSQL não tem a flag da base de dados log_planner_stats definida como Desativada.

Quando a flag log_planner_stats está ativada, é usado um método de criação de perfis simples para registar estatísticas de desempenho do planeador do PostgreSQL. Isto pode ser útil para a resolução de problemas, mas pode aumentar significativamente o número de registos e a sobrecarga de desempenho.

Para mais informações, consulte o artigo Configurar flags da base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Flags da base de dados, defina a flag da base de dados log_planner_stats como Desativado.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL log statement

Nome da categoria na API: SQL_LOG_STATEMENT

Uma instância da base de dados do Cloud SQL para PostgreSQL não tem a flag da base de dados log_statement definida como ddl.

O valor desta flag controla que declarações SQL são registadas. O registo ajuda a resolver problemas operacionais e permite a análise forense. Se esta flag não estiver definida com o valor correto, as informações relevantes podem ser ignoradas ou podem ser ocultadas em demasiadas mensagens. Recomendamos um valor de ddl (todas as declarações de definição de dados), a menos que a política de registo da sua organização indique o contrário.

Para mais informações, consulte o artigo Configurar flags da base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Flags da base de dados, defina a flag da base de dados log_statement como ddl.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL log statement stats enabled

Nome da categoria na API: SQL_LOG_STATEMENT_STATS_ENABLED

Uma instância da base de dados do Cloud SQL para PostgreSQL não tem a flag da base de dados log_statement_stats definida como Desativada.

Quando a flag log_statement_stats é ativada, as estatísticas de desempenho de ponta a ponta são incluídas nos registos do PostgreSQL para cada consulta. Esta definição pode ser útil para resolver problemas, mas pode aumentar significativamente o número de registos e a sobrecarga de desempenho.

Para mais informações, consulte o artigo Configurar flags da base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Flags da base de dados, defina a flag da base de dados log_statement_stats como Desativado.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL log temp files

Nome da categoria na API: SQL_LOG_TEMP_FILES

Uma instância da base de dados do Cloud SQL para PostgreSQL não tem a flag da base de dados log_temp_files definida como 0.

É possível criar ficheiros temporários para ordenações, hashes e resultados de consultas temporários. Definir a flag log_temp_files como 0 faz com que todas as informações dos ficheiros temporários sejam registadas. O registo de todos os ficheiros temporários é útil para identificar potenciais problemas de desempenho. Para mais informações, consulte o artigo Configurar flags da base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Sinalizadores da base de dados, defina o sinalizador da base de dados log_temp_files com o valor 0.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL no root password

Nome da categoria na API: SQL_NO_ROOT_PASSWORD

Uma instância da base de dados MySQL não tem uma palavra-passe definida para a conta raiz. Deve adicionar uma palavra-passe à instância da base de dados MySQL. Para mais informações, consulte o artigo Utilizadores do MySQL.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Na página Detalhes da instância carregada, selecione o separador Utilizadores.

4. Junto ao utilizador root, clique em Mais , e, de seguida, selecione Alterar palavra-passe.

5. Introduza uma nova palavra-passe forte e, de seguida, clique em OK.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL public IP

Nome da categoria na API: SQL_PUBLIC_IP

Uma base de dados do Cloud SQL tem um endereço IP público.

Para reduzir a superfície de ataque da sua organização, as bases de dados do Cloud SQL não devem ter endereços IP públicos. As endereços IP privados oferecem uma melhor segurança de rede e uma menor latência para a sua aplicação.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. No menu do lado esquerdo, clique em Ligações.

4. Clique no separador Rede e desmarque a caixa de verificação IP público.

5. Se a instância ainda não estiver configurada para usar um IP privado, consulte o artigo Configurar o IP privado para uma instância existente.

6. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL remote access enabled

Nome da categoria na API: SQL_REMOTE_ACCESS_ENABLED

Uma instância de base de dados do Cloud SQL para SQL Server não tem a flag de base de dados de acesso remoto definida como Desativado.

Quando ativada, esta definição concede autorização para executar procedimentos armazenados locais a partir de servidores remotos ou procedimentos armazenados remotos a partir do servidor local. Esta funcionalidade pode ser usada de forma abusiva para iniciar um ataque de negação de serviço (DoS) em servidores remotos, transferindo o processamento de consultas para um alvo. Para evitar o abuso, recomendamos que desative esta definição.

Para mais informações, consulte o artigo Configurar flags de base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Flags, defina o acesso remoto como Desativado.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL skip show database disabled

Nome da categoria na API: SQL_SKIP_SHOW_DATABASE_DISABLED

Uma instância de base de dados do Cloud SQL para MySQL não tem a flag de base de dados skip_show_database definida como On.

Quando ativada, esta flag impede que os utilizadores usem a declaração SHOW DATABASES se não tiverem o privilégio SHOW DATABASES. Com esta definição, os utilizadores sem autorização explícita não podem ver bases de dados que pertencem a outros utilizadores. Recomendamos que ative esta flag.

Para mais informações, consulte o artigo Configurar flags da base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Flags, defina skip_show_database como On.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL trace flag 3625

Nome da categoria na API: SQL_TRACE_FLAG_3625

Uma instância de base de dados do Cloud SQL para SQL Server não tem a flag de base de dados 3625 (trace flag) definida como Ativada.

Esta flag limita a quantidade de informações devolvidas aos utilizadores que não são membros da função de servidor fixa sysadmin, ao ocultar os parâmetros de algumas mensagens de erro com asteriscos (******). Para ajudar a evitar a divulgação de informações confidenciais, recomendamos que ative esta flag.

Nota: determinadas versões da norma de referência do CIS aconselham incorretamente a definição de 3625 (indicador de rastreio) como Desativado. A definição mais segura é Ativado. Para mais informações, consulte a proposta de alteração da CIS Certifique-se de que a flag da base de dados "3625 (trace flag)" para todas as instâncias do Cloud SQL Server está definida como "on" (registo obrigatório).

Para mais informações, consulte o artigo Configurar flags de base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Sinalizações da base de dados, defina 3625 como Ativado.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL user connections configured

Nome da categoria na API: SQL_USER_CONNECTIONS_CONFIGURED

Uma instância de base de dados do Cloud SQL para SQL Server tem a flag de base de dados user connections configurada.

A opção Ligações de utilizadores especifica o número máximo de ligações de utilizadores simultâneas permitidas numa instância do SQL Server. Uma vez que é uma opção dinâmica (de configuração automática), o SQL Server ajusta o número máximo de ligações de utilizadores automaticamente, conforme necessário, até ao valor máximo permitido. O valor predefinido é 0, o que significa que são permitidas até 32 767 ligações de utilizadores. Por este motivo, não recomendamos a configuração da flag da base de dados user connections.

Para mais informações, consulte o artigo Configurar flags de base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Indicadores da base de dados, junto a Ligações de utilizadores, clique em Eliminar.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL user options configured

Nome da categoria na API: SQL_USER_OPTIONS_CONFIGURED

Uma instância de base de dados do Cloud SQL para SQL Server tem a flag de base de dados user options configurada.

Esta definição substitui os valores predefinidos globais das opções SET para todos os utilizadores. Uma vez que os utilizadores e as aplicações podem assumir que as opções SET da base de dados predefinidas estão a ser usadas, a definição das opções do utilizador pode causar resultados inesperados. Por este motivo, não recomendamos que configure a flag da base de dados user options.

Para mais informações, consulte o artigo Configurar flags de base de dados.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Clique em Editar.

4. Na secção Flags da base de dados, junto a opções do utilizador, clique em Eliminar.

5. Clique em Guardar. A nova configuração é apresentada na página Vista geral da instância.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SQL weak root password

Nome da categoria na API: SQL_WEAK_ROOT_PASSWORD

Uma instância da base de dados MySQL tem uma palavra-passe fraca definida para a conta root. Deve definir uma palavra-passe forte para a instância. Para mais informações, consulte o artigo Utilizadores do MySQL.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. Na página Detalhes da instância carregada, selecione o separador Utilizadores.

4. Junto ao utilizador root, clique em Mais , e, de seguida, selecione Alterar palavra-passe.

5. Introduza uma nova palavra-passe forte e, de seguida, clique em OK.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

SSL not enforced

Nome da categoria na API: SSL_NOT_ENFORCED

Uma instância de base de dados do Cloud SQL não requer que todas as ligações recebidas usem SSL.

Para evitar a fuga de dados confidenciais em trânsito através de comunicações não encriptadas, todas as ligações recebidas à instância da base de dados SQL devem usar SSL. Saiba mais sobre a configuração do SSL/TLS.

Para corrigir esta descoberta, permita apenas ligações SSL para as suas instâncias SQL:

1. Aceda à página Instâncias do Cloud SQL na Google Cloud consola.

   Aceda a Instâncias do Cloud SQL

2. Selecione a instância apresentada na descoberta do Security Health Analytics.

3. No separador Ligações, clique em Permitir apenas ligações SSL ou Exigir certificados de cliente fidedignos. Para mais informações, consulte o artigo Aplique a encriptação SSL/TLS.

4. Se escolheu Exigir certificados de cliente fidedignos, crie um novo certificado de cliente. Para mais informações, consulte o artigo Crie um novo certificado de cliente.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Too many KMS users

Nome da categoria na API: TOO_MANY_KMS_USERS

Limite a três o número de utilizadores principais que podem usar chaves criptográficas. As seguintes funções predefinidas concedem autorizações para encriptar, desencriptar ou assinar dados através de 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 o artigo Autorizações e funções.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Chaves do Cloud KMS na Google Cloud consola.

   Aceda às chaves do Cloud KMS

2. Clique no nome do conjunto de chaves indicado na descoberta.

3. Clique no nome da chave indicado na descoberta.

4. Selecione a caixa junto à versão principal e, de seguida, clique em Mostrar painel de informações.

5. Reduza o número de responsáveis com autorizações para encriptar, desencriptar ou assinar dados para três ou menos. Para revogar autorizações, clique em Eliminar junto a cada principal.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Unconfirmed AppArmor profile

Nome da categoria na API: GKE_APP_ARMOR

Um contentor pode ser configurado explicitamente para não ter restrições do AppArmor. Isto garante que não é aplicado nenhum perfil do AppArmor ao contentor e, por isso, não está restrito por um perfil. O controlo de segurança preventivo desativado aumenta o risco de fuga do contentor.

Para corrigir esta descoberta, aplique os seguintes passos às 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 utilizador gere uma chave de conta de serviço. As chaves das contas de serviço representam um risco de segurança se não forem geridas corretamente. Deve escolher uma alternativa mais segura às chaves de contas de serviço sempre que possível. Se tiver de fazer a autenticação com uma chave de conta de serviço, é responsável pela segurança da chave privada e por outras operações descritas nas Práticas recomendadas de gestão de chaves de contas de serviço. Se não conseguir criar uma chave de conta de serviço, a criação de chaves de contas de serviço pode estar desativada para a sua organização. Para mais informações, consulte o artigo Gerir recursos da organização seguros por predefinição.

Se adquiriu a chave da conta de serviço a partir de uma fonte externa, tem de a validar antes de a usar. Para mais informações, consulte os Requisitos de segurança para credenciais de origem externa.

Atenção: estes passos de remediação podem interromper o seu ambiente de produção. Se for necessário, transfira cargas de trabalho, dados ou autorizações para novos recursos antes de eliminar recursos existentes.

Para corrigir esta descoberta, conclua os seguintes passos:

1. Aceda à página Contas de serviço na Google Cloud consola.

   Aceda a Contas de serviço

2. Se necessário, selecione o projeto indicado na deteção.

3. Elimine as chaves de contas de serviço geridas pelo utilizador indicadas na descoberta, se não forem usadas por nenhuma aplicação.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Weak SSL policy

Nome da categoria na API: WEAK_SSL_POLICY

Uma instância do Compute Engine tem uma política SSL fraca ou usa a política SSL predefinida com uma versão TLS inferior a 1.2. Google Cloud

Os balanceadores de carga de proxy HTTPS e SSL usam políticas SSL para determinar o protocolo e os conjuntos de cifras usados nas ligações TLS estabelecidas entre os utilizadores e a Internet. Estas ligações encriptam dados confidenciais para impedir que intrusos maliciosos acedam aos mesmos. Uma política de SSL fraca permite que os clientes que usam versões desatualizadas do TLS se liguem com um conjunto de cifras ou um protocolo menos seguro. Para ver uma lista de conjuntos de cifras recomendados e desatualizados, visite a página de parâmetros TLS da iana.org.

Nota: a atualização de uma política SSL pode reduzir a compatibilidade para os utilizadores com versões desatualizadas do TLS.

Para ativações ao nível do projeto do nível Security Command Center Premium, esta descoberta só está disponível se o nível Standard estiver ativado na organização principal.

Os passos de remediação para esta descoberta diferem consoante esta descoberta tenha sido acionada pela utilização de uma política de SSL Google Cloud predefinida ou uma política de SSL que permita um conjunto de cifras fraco ou uma versão mínima do TLS inferior a 1.2. Siga o procedimento abaixo correspondente ao acionador da descoberta.

Remediação da política de SSL Google Cloud predefinida

1. Aceda à página Proxies de destino na Google Cloud consola.

   Aceda a Proxies de destino

2. Encontre o proxy de destino indicado na descoberta e tome nota das regras de encaminhamento na coluna Em utilização por.

3. Para criar uma nova política SSL, consulte o artigo Usar políticas SSL. A política deve ter uma versão mínima do TLS de 1.2 e um perfil moderno ou restrito.

4. Para usar um perfil personalizado , certifique-se de que os seguintes conjuntos de cifras 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 anotou anteriormente.

Remediação permitida para conjunto de cifras fraco ou versão de TLS de nível inferior

1. Na Google Cloud consola, aceda à página Políticas de SSL .

   Aceda às políticas de SSL

2. Encontre o equilibrador de carga indicado na coluna Em utilização por.

3. Clique abaixo do nome da política.

4. Clique em Editar.

5. Altere a versão mínima do TLS para TLS 1.2 e o perfil para Modern ou Restricted.

6. Para usar um perfil Personalizado, certifique-se de que os seguintes conjuntos de cifras 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 Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Web UI enabled

Nome da categoria na API: WEB_UI_ENABLED

A IU Web do GKE (painel de controlo) está ativada.

As contas de serviço do Kubernetes altamente privilegiadas suportam a interface Web do Kubernetes. Se estiver comprometida, a conta de serviço pode ser usada indevidamente. Se já estiver a usar a consola, a interface Web do Kubernetes expande desnecessariamente a sua superfície de ataque. Google Cloud Saiba como desativar a interface Web do Kubernetes.

Para corrigir esta descoberta, desative a interface Web do Kubernetes:

1. Aceda à página Clusters do Kubernetes na Google Cloud consola.

   Aceda aos clusters do Kubernetes

2. Clique no nome do cluster apresentado 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 pode estar desativado. Se não conseguir editar as definições do cluster, aguarde alguns minutos e tente novamente.

4. Clique em Suplementos. A secção é expandida para apresentar os suplementos disponíveis.

5. Na lista pendente Painel de controlo do Kubernetes, selecione Desativado.

6. Clique em Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Workload Identity disabled

Nome da categoria na API: WORKLOAD_IDENTITY_DISABLED

O Workload Identity está desativado num cluster do GKE.

A Workload Identity é a forma recomendada de aceder aos Google Cloud serviços a partir do GKE, uma vez que oferece propriedades de segurança e capacidade de gestão melhoradas. A ativação desta opção protege alguns metadados do sistema potencialmente confidenciais de cargas de trabalho do utilizador em execução no seu cluster. Saiba mais sobre a ocultação de metadados.

Para corrigir esta descoberta, siga o guia para ativar a identidade de workload num cluster.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Corrija as configurações incorretas do AWS

Apenas ao nível empresarial: esta funcionalidade só está disponível com o nível empresarial do Security Command Center.

AWS Cloud Shell Full Access Restricted

Nome da categoria na API: ACCESS_AWSCLOUDSHELLFULLACCESS_RESTRICTED

O AWS CloudShell é uma forma conveniente de executar comandos da CLI em relação aos serviços AWS. Uma política de IAM gerida ("AWSCloudShellFullAccess") fornece acesso total ao CloudShell, o que permite a capacidade de carregamento e transferência de ficheiros entre o sistema local de um utilizador e o ambiente do CloudShell. No ambiente do Cloud Shell, um utilizador tem autorizações sudo e pode aceder à Internet. Por isso, é possível instalar software de transferência de ficheiros (por exemplo) e mover dados do Cloud Shell para servidores de Internet externos.

Recomendação: certifique-se de que o acesso a AWSCloudShellFullAccess está restrito

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

1. Abra a consola do IAM em https://console.aws.amazon.com/iam/
2. No painel esquerdo, selecione Políticas
3. Pesquise e selecione AWSCloudShellFullAccess
4. No separador Entidades anexadas, para cada item, selecione a caixa de verificação e selecione Desanexar

Saiba mais sobre os recursos suportados e as definições de análise deste 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 num ID da chave de acesso e numa chave de acesso secreta, que são usados para assinar pedidos programáticos que faz à AWS. Os utilizadores da AWS precisam das suas próprias chaves de acesso para fazer chamadas programáticas para a AWS a partir da interface de linhas de comando da AWS (CLI da AWS), das ferramentas para o Windows PowerShell, dos SDKs da AWS ou de chamadas HTTP diretas através das APIs para serviços individuais da AWS. Recomendamos que todas as chaves de acesso sejam alteradas regularmente.

Recomendação: certifique-se de que as chaves de acesso são rodadas a cada 90 dias ou menos

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

1. Aceda à consola de gestão (https://console.aws.amazon.com/iam)
2. Clique em Users
3. Clique em Security Credentials
4. Como administrador
   - Clique em Make Inactive para ver as chaves que não foram rodadas nos últimos 90 dias
5. Como utilizador do IAM
   - Clique em Make Inactive ou Delete para ver as chaves que não foram rodadas nem usadas nos últimos 90 dias
6. Clique em Create Access Key
7. Atualize a chamada programática com novas credenciais da chave de acesso

AWS CLI

1. Enquanto a primeira chave de acesso ainda estiver ativa, crie uma segunda chave de acesso, que está ativa por predefinição. Execute o seguinte comando:

aws iam create-access-key

Neste ponto, o utilizador tem duas chaves de acesso ativas.

2. Atualize todas as aplicações e ferramentas para usar a nova chave de acesso.
3. Determine se a primeira chave de acesso ainda está a ser usada através deste comando:

aws iam get-access-key-last-used

4. Uma abordagem consiste em aguardar vários dias e, em seguida, verificar se a chave de acesso antiga foi usada antes de continuar.

Mesmo que o passo 3 indique que não há utilização da chave antiga, recomendamos que não elimine imediatamente a primeira chave de acesso. Em alternativa, altere o estado da primeira chave de acesso para Inativa através deste comando:

aws iam update-access-key

5. Use apenas a nova chave de acesso para confirmar que as suas aplicações estão a funcionar. Todas as aplicações e ferramentas que ainda usam a chave de acesso original vão deixar de funcionar neste momento porque já não têm acesso aos recursos da AWS. Se encontrar uma aplicação ou uma ferramenta deste tipo, pode alterar o respetivo estado novamente para Ativo para reativar a primeira chave de acesso. Em seguida, regresse ao passo 2 e atualize esta aplicação para usar a nova chave.

6. Depois de aguardar algum tempo para garantir que todas as aplicações e ferramentas foram atualizadas, pode eliminar a primeira chave de acesso com este comando:

aws iam delete-access-key

Saiba mais sobre os recursos suportados e as definições de análise deste 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 ligações HTTPS ao seu Website ou aplicação na AWS, precisa de um certificado de servidor SSL/TLS. Pode usar o ACM ou o IAM para armazenar e implementar certificados de servidor.
Use o IAM como gestor de certificados apenas quando tiver de suportar ligações HTTPS numa região que não seja suportada pelo ACM. O IAM encripta de forma segura as suas chaves privadas e armazena a versão encriptada no armazenamento de certificados SSL do IAM. O IAM suporta a implementação de certificados de servidor em todas as regiões, mas tem de obter o certificado de um fornecedor externo para utilização com a AWS. Não pode carregar um certificado da ACM para o IAM. Além disso, não pode gerir os seus certificados a partir da consola do IAM.

Recomendação: certifique-se de que todos os certificados SSL/TLS expirados armazenados no AWS IAM são removidos

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

Atualmente, não é possível remover certificados expirados através da AWS Management Console. Para eliminar certificados SSL/TLS armazenados no IAM através da API AWS, use a interface de linhas de comando (CLI).

AWS CLI

Para eliminar o certificado expirado, execute o seguinte comando substituindo CERTIFICATE_NAME pelo nome do certificado a eliminar:

aws iam delete-server-certificate --server-certificate-name <CERTIFICATE_NAME>

Quando o comando anterior é bem-sucedido, não devolve qualquer resultado.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Autoscaling Group Elb Healthcheck Required

Nome da categoria na API: AUTOSCALING_GROUP_ELB_HEALTHCHECK_REQUIRED

Esta verificação determina se os seus grupos de dimensionamento automático associados a um equilibrador de carga estão a usar verificações de estado do Elastic Load Balancing.

Isto garante que o grupo pode determinar o estado de funcionamento de uma instância com base em testes adicionais fornecidos pelo balanceador de carga. A utilização de verificações de estado de funcionamento do Elastic Load Balancing pode ajudar a suportar a disponibilidade de aplicações que usam grupos de escalamento automático do EC2.

Recomendação: verifica se todos os grupos de dimensionamento automático associados a um balanceador de carga usam verificações de estado

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

Para ativar as verificações de funcionamento do Elastic Load Balancing

1. Abra a consola do Amazon EC2 em https://console.aws.amazon.com/ec2/.
2. No painel de navegação, em Auto Scaling, escolha Auto Scaling Groups.
3. Selecione a caixa de verificação do seu grupo.
4. Escolha Editar.
5. Em Verificações de funcionamento, para Tipo de verificação de funcionamento, escolha ELB.
6. Para o período de tolerância da verificação de funcionamento, introduza 300.
7. Na parte inferior da página, escolha Atualizar.

Para mais informações sobre a utilização de um equilibrador de carga com um grupo de dimensionamento automático, consulte o guia do utilizador do AWS Auto Scaling.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Auto Minor Version Upgrade Feature Enabled Rds Instances

Nome da categoria na API: AUTO_MINOR_VERSION_UPGRADE_FEATURE_ENABLED_RDS_INSTANCES

Certifique-se de que as instâncias da base de dados do RDS têm a flag de atualização automática da versão secundária ativada para receber atualizações automáticas do motor durante o período de manutenção especificado. Assim, as instâncias do RDS podem receber as novas funcionalidades, as correções de erros e os patches de segurança para os respetivos motores de base de dados.

Recomendação: certifique-se de que a funcionalidade de atualização automática da versão secundária está ativada para instâncias do RDS

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

1. Inicie sessão na consola de gestão da AWS e navegue para o painel de controlo do RDS em https://console.aws.amazon.com/rds/.
2. No painel de navegação do lado esquerdo, clique em Databases.
3. Selecione a instância do RDS que quer atualizar.
4. Clique no botão Modify situado na parte superior direita.
5. Na página Modify DB Instance: <instance identifier>, na secção Maintenance, selecione Auto minor version upgrade e clique no botão de opção Yes.
6. Na parte inferior da página, clique em Continue, selecione Aplicar imediatamente para aplicar as alterações imediatamente ou selecione Apply during the next scheduled maintenance window para evitar qualquer tempo de inatividade.
7. Reveja as alterações e clique em Modify DB Instance. O estado da instância deve mudar de disponível para a modificação e voltar a disponível. Assim que a funcionalidade estiver ativada, o estado de Auto Minor Version Upgrade deve mudar para Yes.

AWS CLI

1. Execute o comando describe-db-instances para listar todos os nomes de instâncias da base de dados do RDS, disponíveis na região da AWS selecionada:

aws rds describe-db-instances --region <regionName> --query 'DBInstances[*].DBInstanceIdentifier'

2. O resultado do comando deve devolver o identificador de cada instância da base de dados.
3. Execute o comando modify-db-instance para modificar a configuração da instância do RDS selecionada. Este comando aplica as alterações imediatamente. Remova --apply-immediately para aplicar as alterações durante a próxima janela de manutenção agendada e evitar qualquer tempo de inatividade:

aws rds modify-db-instance --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --auto-minor-version-upgrade --apply-immediately

4. O resultado do comando deve 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 a funcionalidade de atualização automática da versão secundária foi ativada com êxito:

aws rds describe-db-instances --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --query 'DBInstances[*].AutoMinorVersionUpgrade'

6. O resultado do comando deve devolver o estado atual da funcionalidade definido como true, a funcionalidade está enabled e as atualizações secundárias do motor vão ser aplicadas à instância do RDS selecionada.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Aws Config Enabled All Regions

Nome da categoria na API: AWS_CONFIG_ENABLED_ALL_REGIONS

O AWS Config é um serviço Web que realiza a gestão da configuração dos recursos da AWS suportados na sua conta e envia-lhe ficheiros de registo. As informações registadas incluem o item de configuração (recurso da AWS), as relações entre itens de configuração (recursos da AWS) e quaisquer alterações de configuração entre recursos. Recomendamos que o AWS Config esteja ativado em todas as regiões.

Recomendação: certifique-se de que o AWS Config está ativado em todas as regiões

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

1. Selecione a região na qual quer focar-se na parte superior direita da consola
2. Clique em Serviços
3. Clique em Configuração
4. Se um registador de configuração estiver ativado nesta região, deve navegar para a página Definições a partir do menu de navegação no lado esquerdo. Se um registador de configuração ainda não estiver ativado nesta região, deve selecionar "Começar".
5. Selecione "Registar todos os recursos suportados nesta região"
6. Opte por incluir recursos globais (recursos da IAM)
7. Especifique um contentor do S3 na mesma conta ou noutra conta da AWS gerida
8. Crie um tópico do SNS a partir da mesma conta da AWS ou de outra conta da AWS gerida

AWS CLI

1. Certifique-se de que existe um contentor do S3, um tópico do SNS e uma função do IAM adequados, de acordo com os pré-requisitos do serviço AWS Config.
2. Execute este comando para criar um novo registador 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 ficheiro de configuração do canal de envio localmente que especifique os atributos do canal, preenchidos a partir dos 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, fazendo referência ao ficheiro de configuração JSON criado no passo anterior:

aws configservice put-delivery-channel --delivery-channel file://deliveryChannel.json

5. Inicie o registador de configuração executando o seguinte comando:

aws configservice start-configuration-recorder --configuration-recorder-name default

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Aws Security Hub Enabled

Nome da categoria na API: AWS_SECURITY_HUB_ENABLED

O Security Hub recolhe dados de segurança de todas as contas, serviços e produtos de parceiros de terceiros suportados da AWS, e ajuda a analisar as tendências de segurança e a identificar os problemas de segurança de maior prioridade. Quando ativa o Security Hub, este começa a consumir, agregar, organizar e priorizar as conclusões dos serviços AWS que ativou, como o Amazon GuardDuty, o Amazon Inspector e o Amazon Macie. Também pode ativar integrações com produtos de segurança de parceiros da AWS.

Recomendação: certifique-se de que o AWS Security Hub está ativado

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

1. Use as credenciais da identidade do IAM para iniciar sessão na consola do Security Hub.
2. Quando abrir a consola do Security Hub pela primeira vez, escolha Ativar AWS Security Hub.
3. Na página de boas-vindas, a lista de normas de segurança apresenta as normas de segurança suportadas pelo Security Hub.
4. Escolha Ativar o Centro de segurança.

AWS CLI

1. Execute o comando enable-security-hub. Para ativar as normas predefinidas, inclua --enable-default-standards.

aws securityhub enable-security-hub --enable-default-standards

2. Para ativar o centro de segurança sem as normas predefinidas, inclua --no-enable-default-standards.

aws securityhub enable-security-hub --no-enable-default-standards

Saiba mais sobre os recursos suportados e as definições de análise deste 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 Web que regista chamadas de API AWS para uma conta e disponibiliza esses registos aos utilizadores e recursos de acordo com as políticas de IAM. O AWS Key Management Service (KMS) é um serviço gerido que ajuda a criar e controlar as chaves de encriptação usadas para encriptar os dados da conta e usa módulos de segurança de hardware (HSMs) para proteger a segurança das chaves de encriptação. Os registos do CloudTrail podem ser configurados para tirar partido da encriptação do lado do servidor (SSE) e das chaves mestras criadas pelo cliente (CMK) do KMS para proteger ainda mais os registos do CloudTrail. Recomendamos que o CloudTrail seja configurado para usar o SSE-KMS.

Recomendação: certifique-se de que os registos do CloudTrail estão encriptados em repouso com CMKs do KMS

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

1. Inicie sessão na AWS Management Console e abra a consola do CloudTrail em https://console.aws.amazon.com/cloudtrail
2. No painel de navegação do lado esquerdo, escolha Trails .
3. Clique num trilho
4. Na secção S3, clique no botão de edição (ícone de lápis)
5. Clique em Advanced
6. Selecione uma CMK existente no menu pendente KMS key Id
   - Nota: certifique-se de que a CMK está localizada na mesma região que o contentor S3
   - Nota: tem de aplicar uma política de chaves do KMS na CMK selecionada para que o CloudTrail como serviço possa encriptar e desencriptar ficheiros de registo através da CMK fornecida. Os passos para editar a política de chaves CMK selecionada são fornecidos aqui
7. Clique em Save
8. É apresentada uma mensagem de notificação a indicar que tem de ter autorizações de desencriptação na chave do KMS especificada para desencriptar ficheiros de registo.
9. Clique em Yes

AWS CLI

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 suportados e as definições de análise deste tipo de descoberta.

Cloudtrail Log File Validation Enabled

Nome da categoria na API: CLOUDTRAIL_LOG_FILE_VALIDATION_ENABLED

A validação de ficheiros de registo do CloudTrail cria um ficheiro de resumo assinado digitalmente que contém um hash de cada registo que o CloudTrail escreve no S3. Estes ficheiros de resumo podem ser usados para determinar se um ficheiro de registo foi alterado, eliminado ou permaneceu inalterado depois de o CloudTrail ter entregue o registo. Recomendamos que a validação de ficheiros seja ativada em todos os CloudTrails.

Recomendação: certifique-se de que a validação de ficheiros de registo do CloudTrail está ativada

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

1. Inicie sessão na AWS Management Console e abra a consola IAM em https://console.aws.amazon.com/cloudtrail
2. Clique em Trails no painel de navegação do lado esquerdo
3. Clique no rasto do alvo
4. Na secção General details, clique em edit
5. Na secção Advanced settings
6. Selecione a caixa de ativação em Log file validation
7. Clique em Save changes

AWS CLI

aws cloudtrail update-trail --name <trail_name> --enable-log-file-validation

Tenha em atenção que a validação periódica dos registos através destes 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 suportados e as definições de análise deste tipo de descoberta.

Cloudtrail Trails Integrated Cloudwatch Logs

Nome da categoria na API: CLOUDTRAIL_TRAILS_INTEGRATED_CLOUDWATCH_LOGS

O AWS CloudTrail é um serviço Web que regista chamadas de API AWS feitas numa determinada conta AWS. As informações registadas incluem a identidade do autor da chamada da API, a hora da chamada da API, o endereço IP de origem do autor da chamada da API, os parâmetros do pedido e os elementos de resposta devolvidos pelo serviço AWS. O CloudTrail usa o Amazon S3 para o armazenamento e a entrega de ficheiros de registo, pelo que os ficheiros de registo são armazenados de forma duradoura. Além de capturar registos do CloudTrail num contentor do S3 especificado para análise a longo prazo, pode configurar o CloudTrail para enviar registos para os registos do CloudWatch e realizar uma análise em tempo real. Para uma trilha ativada em todas as regiões numa conta, o CloudTrail envia ficheiros de registo de todas essas regiões para um grupo de registos do CloudWatch Logs. Recomendamos que os registos do CloudTrail sejam enviados para os registos do CloudWatch.

Nota: o objetivo desta recomendação é garantir que a atividade da conta da AWS está a ser captada, monitorizada e que são gerados alertas adequados. O CloudWatch Logs é uma forma nativa de o fazer através dos serviços da AWS, mas não impede a utilização de uma solução alternativa.

Recomendação: certifique-se de que os trilhos do CloudTrail estão integrados com os registos do CloudWatch

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

1. Inicie sessão na consola do CloudTrail em https://console.aws.amazon.com/cloudtrail/
2. Selecione o Trail que tem de ser atualizado.
3. Desloque a página 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 registos existente
7. Edite o Log group name para corresponder ao CloudTrail ou escolha o grupo do CloudWatch existente.
8. Em IAM Role, escolha uma nova ou selecione uma existente.
9. Edite o Role name para corresponder ao CloudTrail ou escolha a função do IAM existente.
10. Clique em `Guardar alterações.

AWS CLI

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 suportados e as definições de análise deste tipo de descoberta.

Cloudwatch Alarm Action Check

Nome da categoria na API: CLOUDWATCH_ALARM_ACTION_CHECK

Esta verificação determina se o Amazon Cloudwatch tem ações definidas quando um alarme transita entre os estados "OK", "ALARM" e "INSUFFICIENT_DATA".

A configuração de ações para o estado ALARM nos alarmes do Amazon CloudWatch é muito importante para acionar uma resposta imediata quando as métricas monitorizadas excedem os limites.
Garante uma resolução rápida dos problemas, reduz o tempo de inatividade e permite a correção automática, mantendo o bom funcionamento do sistema e evitando interrupções.

Os alarmes têm, pelo menos, uma ação.
Os alertas têm, pelo menos, uma ação quando a transição do alerta para o estado "INSUFFICIENT_DATA" ocorre a partir de qualquer outro estado.
(Opcional) Os alarmes têm, pelo menos, uma ação quando a transição do alarme é para um estado "OK" a partir de qualquer outro estado.

Recomendação: verifica 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 esta deteção, conclua os seguintes passos:

Consola AWS

Para configurar ações de ALARME para os seus alarmes do Amazon CloudWatch, faça o seguinte.

1. Abra a consola 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 quer modificar, escolha "Ações" e selecione "Editar".
4. No lado esquerdo, escolha "Passo 2: opcional. Configure ações"
5. Para o "Acionador 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 "Terminais de email que vão receber a notificação…", especifique um ou mais endereços de email.
9. Em seguida, selecione "Criar tópico" para criar o tópico do Amazon SNS necessário.
10. Na parte inferior direita, selecione "Seguinte", "Seguinte" e escolha "Atualizar alarme" para aplicar as alterações.
11. Abra o seu cliente de email e, no email das notificações da AWS, clique no link para confirmar a sua subscrição do tópico do SNS em questão.
12. Repita os passos 4 a 11 e, durante o passo 5, escolha "OK" e "Dados insuficientes" para o "Acionador de estado de alarme" para configurar 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 suportados e as definições de análise deste tipo de descoberta.

Cloudwatch Log Group Encrypted

Nome da categoria na API: CLOUDWATCH_LOG_GROUP_ENCRYPTED

Esta verificação garante que os registos do CloudWatch estão configurados com o KMS.

Os dados do grupo de registos são sempre encriptados nos registos do CloudWatch. Por predefinição, o CloudWatch Logs usa a encriptação do lado do servidor para os dados de registo em repouso. Em alternativa, pode usar o AWS Key Management Service para esta encriptação. Se o fizer, a encriptação é feita através de uma chave do AWS KMS. A encriptação com o AWS KMS é ativada ao nível do grupo de registos, associando uma chave do KMS a um grupo de registos, quer quando cria o grupo de registos, quer depois de este existir.

Recomendação: verifica se todos os grupos de registos no Amazon CloudWatch Logs estão encriptados com o KMS

Para mais informações, consulte o artigo Encriptar dados de registo nos registos do CloudWatch com o serviço de gestão de chaves da AWS no guia do utilizador do Amazon CloudWatch.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

CloudTrail CloudWatch Logs Enabled

Nome da categoria na API: CLOUD_TRAIL_CLOUD_WATCH_LOGS_ENABLED

Este controlo verifica se os rastos do CloudTrail estão configurados para enviar registos para o CloudWatch Logs. O controlo falha se a propriedade CloudWatchLogsLogGroupArn da trilha estiver vazia.

O CloudTrail regista as chamadas API da AWS feitas numa determinada conta. As informações registadas incluem o seguinte:

• A identidade do autor da chamada API
• A hora da chamada API
• O endereço IP de origem do autor da chamada da API
• Os parâmetros do pedido
• Os elementos de resposta devolvidos pelo serviço AWS

O CloudTrail usa o Amazon S3 para o armazenamento e a entrega de ficheiros de registo. Pode capturar registos do CloudTrail num contentor do S3 especificado para análise a longo prazo. Para realizar a análise em tempo real, pode configurar o CloudTrail para enviar registos para o CloudWatch Logs.

Para uma trilha ativada em todas as regiões numa conta, o CloudTrail envia ficheiros de registo de todas essas regiões para um grupo de registos do CloudWatch Logs.

O Security Hub recomenda que envie registos do CloudTrail para os registos do CloudWatch. Tenha em atenção que esta recomendação se destina a garantir que a atividade da conta é captada, monitorizada e que são gerados alertas adequados. Pode usar os registos do CloudWatch para configurar esta opção com os seus serviços AWS. Esta recomendação não impede a utilização de uma solução diferente.

O envio de registos do CloudTrail para os registos do CloudWatch facilita o registo de atividade em tempo real e histórico com base no utilizador, na API, no recurso e no endereço IP. Pode usar esta abordagem para estabelecer alarmes e notificações para atividade anómala ou sensível da conta.

Recomendação: verifica se todos os rastos do CloudTrail estão configurados para enviar registos para o AWS CloudWatch

Para integrar o CloudTrail com os registos do CloudWatch, consulte o artigo Enviar eventos para os registos do CloudWatch no manual do utilizador do AWS CloudTrail.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

No AWS Credentials in CodeBuild Project Environment Variables

Nome da categoria na API: CODEBUILD_PROJECT_ENVVAR_AWSCRED_CHECK

Esta verificação determina 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, uma vez que tal pode levar à exposição não intencional de dados e ao acesso não autorizado.

Recomendação: verifica se todos os projetos que contêm as 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 o artigo Alterar as definições de um projeto de compilação no AWS CodeBuild no guia do utilizador do AWS CodeBuild. Certifique-se de que não tem nada selecionado para as variáveis de ambiente.

Pode armazenar variáveis de ambiente com valores confidenciais no AWS Systems Manager Parameter Store ou no AWS Secrets Manager e, em seguida, recuperá-los da especificação de compilação. Para obter instruções, consulte a caixa com a etiqueta Importante na secção Ambiente no guia do utilizador do AWS CodeBuild.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Codebuild Project Source Repo Url Check

Nome da categoria na API: CODEBUILD_PROJECT_SOURCE_REPO_URL_CHECK

Esta verificação determina se um URL do repositório de origem do Bitbucket de um projeto do AWS CodeBuild contém tokens de acesso pessoal ou um nome de utilizador e uma palavra-passe. O controlo falha se o URL do repositório de origem do Bitbucket contiver tokens de acesso pessoal ou um nome de utilizador e uma palavra-passe.

As credenciais de início de sessão não devem ser armazenadas nem transmitidas em texto simples, nem aparecer no URL do repositório de origem. Em vez de tokens de acesso pessoal ou credenciais de início de sessão, deve aceder ao seu fornecedor de origem no CodeBuild e alterar o URL do repositório de origem para conter apenas o caminho para a localização do repositório do Bitbucket. A utilização de tokens de acesso pessoal ou credenciais de início de sessão pode resultar na exposição não intencional de dados ou no acesso não autorizado.

Recomendação: verifica se todos os projetos que usam o GitHub ou o Bitbucket como origem usam o OAuth

Pode atualizar o seu projeto do CodeBuild para usar o OAuth.

Para remover a autenticação básica/a chave de acesso pessoal (GitHub) da origem do projeto do CodeBuild

1. Abra a consola do CodeBuild em https://console.aws.amazon.com/codebuild/.
2. Escolha o projeto de compilação que contém tokens de acesso pessoal ou um nome de utilizador e uma palavra-passe.
3. Em Editar, escolha Origem.
4. Escolha Desligar do GitHub / Bitbucket.
5. Escolha Associar através do OAuth e, de seguida, escolha Associar ao GitHub / Bitbucket.
6. Quando lhe for pedido, escolha autorizar, conforme adequado.
7. Reconfigure o URL do repositório e as definições de configuração adicionais, conforme necessário.
8. Escolha Atualizar origem.

Para mais informações, consulte os exemplos baseados em exemplos de utilização do CodeBuild no guia do utilizador do AWS CodeBuild.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Credentials Unused 45 Days Greater Disabled

Nome da categoria na API: CREDENTIALS_UNUSED_45_DAYS_GREATER_DISABLED

Os utilizadores do IAM da AWS podem aceder aos recursos da AWS através de diferentes tipos de credenciais, como palavras-passe ou chaves de acesso. Recomendamos que todas as credenciais que não tenham sido usadas durante 45 ou mais dias sejam desativadas ou removidas.

Recomendação: certifique-se de que as credenciais não usadas durante 45 dias ou mais estão desativadas

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

Faça o seguinte para gerir a palavra-passe não utilizada (acesso à consola do utilizador do IAM)

1. Inicie sessão na AWS Management Console:
2. Clique em Services
3. Clique em IAM
4. Clique em Users
5. Clique em Security Credentials
6. Selecione o utilizador cujo Console last sign-in seja superior a 45 dias
7. Clique em Security credentials
8. Na secção Sign-in credentials, Console password clique em Manage
9. Em Acesso à consola, selecione Disable
   10.Clique em Apply

Faça o seguinte para desativar as chaves de acesso:

1. Inicie sessão na AWS Management Console:
2. Clique em Services
3. Clique em IAM
4. Clique em Users
5. Clique em Security Credentials
6. Selecione todas as chaves de acesso com mais de 45 dias e que tenham sido usadas e
   - Clique em Make Inactive
7. Selecione as chaves de acesso com mais de 45 dias e que não foram usadas e
   - Clique no X para Delete

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Default Security Group Vpc Restricts All Traffic

Nome da categoria na API: DEFAULT_SECURITY_GROUP_VPC_RESTRICTS_ALL_TRAFFIC

Uma VPC inclui um grupo de segurança predefinido cujas definições iniciais negam todo o tráfego de entrada, permitem todo o tráfego de saída e permitem todo o tráfego entre instâncias atribuídas ao grupo de segurança. Se não especificar um grupo de segurança quando inicia uma instância, esta é automaticamente atribuída a este grupo de segurança predefinido. Os grupos de segurança oferecem filtragem com estado do tráfego de rede de entrada/saída para recursos da AWS. Recomendamos que o grupo de segurança predefinido restrinja todo o tráfego.

A VPC predefinida em todas as regiões deve ter o respetivo grupo de segurança predefinido atualizado para estar em conformidade. Todas as VPCs criadas recentemente contêm automaticamente um grupo de segurança predefinido que requer correção para estar em conformidade com esta recomendação.

NOTA: quando implementar esta recomendação, o registo de fluxo de VPC é inestimável para determinar o acesso à porta com privilégios mínimos exigido pelos sistemas para funcionar corretamente, uma vez que pode registar todas as aceitações e rejeições de pacotes que ocorrem nos grupos de segurança atuais. Isto reduz drasticamente a principal barreira à engenharia de privilégios mínimos: descobrir as portas mínimas necessárias pelos sistemas no ambiente. Mesmo que a recomendação de registo de fluxo da VPC nesta referência não seja adotada como uma medida de segurança permanente, deve ser usada durante qualquer período de deteção e engenharia para grupos de segurança com privilégios mínimos.

Recomendação: certifique-se de que o grupo de segurança predefinido de cada VPC restringe todo o tráfego

Membros do grupo de segurança

Faça o seguinte para implementar o estado prescrito:

1. Identificar os recursos da AWS que existem no grupo de segurança predefinido
2. Crie um conjunto de grupos de segurança com privilégios mínimos para esses recursos
3. Coloque os recursos nesses grupos de segurança
4. Remova os recursos indicados no passo 1 do grupo de segurança predefinido

Estado do grupo de segurança

1. Inicie sessão na AWS Management Console em https://console.aws.amazon.com/vpc/home
2. Repita os passos seguintes para todas as VPCs, incluindo a VPC predefinida em cada região da AWS:
3. No painel esquerdo, clique em Security Groups
4. Para cada grupo de segurança predefinido, faça o seguinte:
5. Selecione o grupo de segurança default
6. Clique no separador Inbound Rules
7. Remova todas as regras de entrada
8. Clique no separador Outbound Rules
9. Remova todas as regras de saída

Recomendado:

Os grupos do IAM permitem-lhe editar o campo "nome". Depois de corrigir as regras de grupos predefinidos para todas as VPCs em todas as regiões, edite este campo para adicionar texto semelhante a "NÃO USAR. DO NOT ADD RULES"

Saiba mais sobre os recursos suportados e as definições de análise deste 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 tal, examina o valor do campo PubliclyAccessible.

Uma instância de replicação privada tem um endereço IP privado ao qual não pode aceder fora da rede de replicação. Uma instância de replicação deve ter um endereço IP privado quando as bases de dados de origem e de destino estão na mesma rede. A rede também tem de estar ligada à VPC da instância de replicação através de uma VPN, do AWS Direct Connect ou do peering de VPC. Para saber mais sobre instâncias de replicação públicas e privadas, consulte o artigo Instâncias de replicação públicas e privadas no guia do utilizador do AWS Database Migration Service.

Também deve garantir que o acesso à configuração da instância do AWS DMS está limitado apenas a utilizadores autorizados. Para tal, restrinja as autorizações de IAM dos utilizadores para modificar as definições e os recursos do AWS DMS.

Recomendação: verifica se as instâncias de replicação do AWS Database Migration Service são públicas

Não é possível alterar a definição de acesso público de uma instância de replicação do DMS depois de a criar. Para alterar a definição de acesso público, elimine a instância atual e, em seguida, recrie-a. Não selecione a opção Acessível publicamente.

Saiba mais sobre os recursos suportados e as definições de análise deste 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

Por predefinição, a consola da AWS não tem caixas de verificação selecionadas quando cria um novo utilizador do IAM. Ao criar as credenciais de utilizador do IAM, tem de determinar o tipo de acesso de que precisam.

Acesso programático: o utilizador do IAM pode ter de fazer chamadas de API, usar a CLI da AWS ou usar as ferramentas para o Windows PowerShell. Nesse caso, crie uma chave de acesso (ID da chave de acesso e uma chave de acesso secreta) para esse utilizador.

Acesso à AWS Management Console: se o utilizador precisar de aceder à AWS Management Console, crie uma palavra-passe para o utilizador.

Recomendação: não configure chaves de acesso durante a configuração inicial do utilizador para todos os utilizadores do IAM que tenham uma palavra-passe da consola

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

1. Inicie sessão na AWS Management Console:
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 utilizador, mas não foram usadas.
7. Como utilizador do IAM
   - Clique no X (Delete) para chaves que foram criadas ao mesmo tempo que o perfil do utilizador, mas que não foram usadas.

AWS CLI

aws iam delete-access-key --access-key-id <access-key-id-listed> --user-name <users-name>

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Dynamodb Autoscaling Enabled

Nome da categoria na API: DYNAMODB_AUTOSCALING_ENABLED

Esta verificação determina se uma tabela do Amazon DynamoDB consegue dimensionar a respetiva capacidade de leitura e escrita conforme necessário. Este controlo é aprovado se a tabela usar o modo de capacidade a pedido ou o modo aprovisionado com o dimensionamento automático configurado. Aumentar a capacidade com a procura evita exceções de limitação de pedidos, o que ajuda a manter a disponibilidade das suas aplicações.

As tabelas do DynamoDB no modo de capacidade a pedido só estão limitadas pelas quotas de tabelas predefinidas de débito do DynamoDB. Para aumentar estas quotas, pode registar um pedido de apoio técnico através do apoio técnico da AWS.

As tabelas do DynamoDB no modo aprovisionado com o dimensionamento automático ajustam a capacidade de débito aprovisionada dinamicamente em resposta aos padrões de tráfego. Para mais informações sobre a limitação de pedidos do DynamoDB, consulte o artigo Limitação de pedidos e capacidade de picos no guia para programadores do Amazon DynamoDB.

Recomendação: as tabelas do DynamoDB devem ajustar automaticamente a capacidade de acordo com a procura

Para obter instruções detalhadas sobre como ativar o dimensionamento automático do DynamoDB em tabelas existentes no modo de capacidade, consulte o artigo Ativar o dimensionamento automático do DynamoDB em tabelas existentes no guia do programador do Amazon DynamoDB.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Dynamodb In Backup Plan

Nome da categoria na API: DYNAMODB_IN_BACKUP_PLAN

Este controlo avalia se uma tabela do DynamoDB está abrangida por um plano de cópia de segurança. O controlo falha se uma tabela do DynamoDB não estiver abrangida por um plano de cópia de segurança. Este controlo apenas avalia tabelas do DynamoDB que estão no estado ACTIVE.

As cópias de segurança ajudam a recuperar mais rapidamente de um incidente de segurança. Também reforçam a resiliência dos seus sistemas. A inclusão de tabelas do DynamoDB num plano de cópia de segurança ajuda a proteger os seus dados contra perdas ou eliminações não intencionais.

Recomendação: as tabelas do DynamoDB devem ser abrangidas por um plano de cópia de segurança

Para adicionar uma tabela do DynamoDB a um plano de cópia de segurança do AWS Backup, consulte o artigo Atribuir recursos a um plano de cópia de segurança no guia para programadores do AWS Backup.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 uma cópia de segurança de tabelas do DynamoDB.

Uma cópia de segurança num determinado momento é mantida durante 35 dias. Caso a sua necessidade seja uma retenção mais longa, consulte o artigo Configure cópias de segurança agendadas para o Amazon DynamoDB com o AWS Backup na documentação da AWS.

Recomendação: verifica se a recuperação num ponto específico no tempo (PITR) está ativada para todas as tabelas do AWS DynamoDB

Para corrigir esta deteção, conclua os seguintes passos:

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
  }
}

Consola AWS

Para ativar a recuperação pontual do DynamoDB para uma tabela existente

1. Abra a consola do DynamoDB em https://console.aws.amazon.com/dynamodb/.
2. Escolha a tabela com a qual quer trabalhar e, de seguida, escolha Cópias de segurança.
3. Na secção Recuperação num ponto específico no tempo, em Estado, escolha Ativar.
4. Escolha Ativar novamente para confirmar a alteração.

AWS CLI

aws dynamodb update-continuous-backups \
  --table-name "GameScoresOnDemand" \
  --point-in-time-recovery-specification "PointInTimeRecoveryEnabled=true"

Saiba mais sobre os recursos suportados e as definições de análise deste 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 encriptadas com uma chave do KMS gerida pelo cliente (não predefinida).

Recomendação: verifica se todas as tabelas do DynamoDB estão encriptadas com o AWS Key Management Service (KMS)

Para corrigir esta deteção, conclua os seguintes passos:

Terraform

Para corrigir este controlo, crie uma chave do AWS KMS e use-a para encriptar o recurso do DynamoDB 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
  }
}

Consola AWS

Partindo do princípio de que existe uma chave do AWS KMS disponível para encriptar o DynamoDB.

Para alterar a encriptação de uma tabela do DynamoDB para uma chave do KMS gerida e detida pelo cliente.

1. Abra a consola do DynamoDB em https://console.aws.amazon.com/dynamodb/.
2. Escolha a tabela com a qual quer trabalhar e, em seguida, escolha Definições adicionais.
3. Em Encriptação, escolha Gerir encriptação.
4. Para a encriptação em repouso, escolha Armazenado na sua conta, e detido e gerido por si.
5. Selecione a chave da AWS a usar. Guarde as alterações.

AWS CLI

aws dynamodb update-table \
  --table-name <value> \
  --sse-specification "Enabled=true,SSEType=KMS,KMSMasterKeyId=<kms_key_arn>"

Saiba mais sobre os recursos suportados e as definições de análise deste 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 suas instâncias do EC2 que podem ser otimizadas para o EBS

Recomendação: verifica se a otimização de EBS está ativada para todas as instâncias que suportam a otimização de EBS

Para configurar as definições de instâncias otimizadas para EBS, consulte o artigo Instâncias otimizadas para Amazon EBS no guia do utilizador do Amazon EC2.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Ebs Snapshot Public Restorable Check

Nome da categoria na API: EBS_SNAPSHOT_PUBLIC_RESTORABLE_CHECK

Verifica se as imagens instantâneas do Amazon Elastic Block Store não são públicas. O controlo falha se as cópias instantâneas do Amazon EBS puderem ser restauradas por qualquer pessoa.

Os instantâneos do EBS são usados para fazer uma cópia de segurança dos dados nos seus volumes do EBS para o Amazon S3 num momento específico. Pode usar os resumos para restaurar estados anteriores dos volumes EBS. Raramente é aceitável partilhar uma captura de ecrã com o público. Normalmente, a decisão de partilhar uma captura de ecrã publicamente foi tomada por engano ou sem uma compreensão completa das implicações. Esta verificação ajuda a garantir que toda a partilha foi totalmente planeada e intencional.

Recomendação: os instantâneos do Amazon EBS não devem ser restauráveis publicamente

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

Para corrigir este problema, atualize a sua captura instantânea do EBS para a tornar privada em vez de pública.

Para tornar uma captura de ecrã pública do EBS privada:

1. Abra a consola 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, de seguida, escolha a sua captura instantânea pública.
3. Em Ações, escolha Modificar autorizações.
4. Escolha Privado.
5. (Opcional) Adicione os números de conta da AWS das contas autorizadas com as quais quer partilhar a sua imagem instantânea e escolha Adicionar autorização.
6. Selecione Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste 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) suporta a encriptação em repouso quando usa o serviço Elastic Block Store (EBS). Embora esteja desativada por predefinição, a imposição da encriptação na criação de volumes do EBS é suportada.

Recomendação: certifique-se de que a encriptação de volumes do EBS está ativada em todas as regiões

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

1. Inicie sessão na consola de gestão da AWS e abra a consola do Amazon EC2 através de https://console.aws.amazon.com/ec2/
2. Na secção Account attributes, clique em EBS encryption.
3. Clique em Manage.
4. Clique na caixa de verificação Enable.
5. Clique em Update EBS encryption
6. Repita o procedimento para cada região que requer a alteração.

Nota: a encriptação de volumes do EBS é configurada por região.

AWS CLI

1. Execução

aws --region <region> ec2 enable-ebs-encryption-by-default

2. Verifique se "EbsEncryptionByDefault": true é apresentado.
3. Repita o procedimento para cada região que requer a alteração.

Nota: a encriptação de volumes do EBS é configurada por região.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Ec2 Instances In Vpc

Nome da categoria na API: EC2_INSTANCES_IN_VPC

A Amazon VPC oferece mais funcionalidades de segurança do que o EC2 Classic. Recomendamos que todos os nós pertençam a uma Amazon VPC.

Recomendação: garante que todas as instâncias pertencem a uma VPC

Para corrigir esta deteção, conclua os seguintes passos:

Terraform

Se tiver instâncias do EC2 Classic definidas no Terraform, pode modificar os seus recursos para fazerem parte de uma VPC. Esta migração depende de uma arquitetura que se adeque melhor às suas necessidades. Segue-se um exemplo simples do Terraform que ilustra uma EC2 exposta publicamente numa 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"
    }
  }

Consola AWS

Para migrar o EC2 Classic para a VPC, consulte o artigo Migre do EC2-Classic para uma VPC

AWS CLI

Este exemplo da CLI da AWS ilustra a mesma infraestrutura definida com o Terraform. É um exemplo simples de uma instância do EC2 exposta publicamente numa VPC

Crie uma VPC

  aws ec2 create-vpc \
  --cidr-block 10.0.0.0/16

Crie uma 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>

Crie um gateway de Internet

  aws ec2 create-internet-gateway

Anexe 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: esta ação guarda a 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

Crie um grupo de segurança

  aws ec2 create-security-group \
  --group-name "http and ssh" \
  --vpc-id <id_from_create-vpc_command>

Crie regras de grupos 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

Crie uma instância do 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 suportados e as definições de análise deste 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 correm um risco maior de serem comprometidas. 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 tem um IP público

Para corrigir esta deteção, conclua os seguintes passos:

Terraform

Use o argumento associate_public_ip_address = false com o recurso aws_instance para garantir que as instâncias do EC2 são aprovisionadas sem um endereço IP público

resource "aws_instance" "no_public_ip" {
  ...
  associate_public_ip_address = false
}

Consola AWS

Por predefinição, as sub-redes não predefinidas têm o atributo de endereçamento público IPv4 definido como falso e as sub-redes predefinidas têm este atributo definido como verdadeiro. Uma exceção é uma sub-rede não predefinida criada pelo assistente de instância de lançamento do Amazon EC2. O assistente define o atributo como true. Pode modificar este atributo através da consola da Amazon VPC.

Para modificar o comportamento de endereçamento IPv4 público da sua sub-rede

1. Abra a consola do Amazon VPC em https://console.aws.amazon.com/vpc/.
2. No painel de navegação, escolha Sub-redes.
3. Selecione a sua sub-rede e escolha Ações, Editar definições da sub-rede.
4. Se estiver selecionada, a caixa de verificação Ativar atribuição automática de endereço IPv4 público pede um endereço IPv4 público para todas as instâncias iniciadas na sub-rede selecionada. Selecione ou desmarque a caixa de verificação conforme necessário e, de seguida, escolha Guardar.

AWS CLI

O comando seguinte executa uma instância do EC2 numa sub-rede predefinida sem lhe associar um endereço IP público.

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 suportados e as definições de análise deste 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 geridas. A configuração define o estado que quer manter nas suas instâncias. Por exemplo, uma associação pode especificar que o software antivírus tem de estar instalado e em execução nas suas instâncias ou que determinadas portas têm de estar fechadas. As instâncias do EC2 que têm uma associação com o AWS Systems Manager estão sob a gestão 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: verifica o estado de conformidade da associação do gestor de sistemas da AWS

Para corrigir esta deteção, conclua os seguintes passos:

Terraform

O exemplo seguinte demonstra como criar uma instância do EC2 simples, um documento do AWS Systems Manager (SSM) e uma associação entre o SSM e a instância do EC2. Os documentos suportados 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]
  }
}

Consola AWS

Para obter informações sobre a configuração de associações com o AWS Systems Manager através da consola, consulte o artigo Criar associações na documentação do AWS Systems Manager.

AWS CLI

Crie um documento do SSM

aws ssm create-document \
--name <document_name> \
--content  file://path/to-file/document.json \
--document-type "Command"

Crie 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 suportados e as definições de análise deste tipo de descoberta.

Ec2 Managedinstance Patch Compliance Status Check

Nome da categoria na API: EC2_MANAGEDINSTANCE_PATCH_COMPLIANCE_STATUS_CHECK

Este controlo verifica se o estado da conformidade da associação do AWS Systems Manager é COMPLIANT ou NON_COMPLIANT após a execução da associação numa instância. O controlo falha se o estado de conformidade da associação for NON_COMPLIANT.

Uma associação do State Manager é uma configuração atribuída às suas instâncias geridas. A configuração define o estado que quer manter nas suas instâncias. Por exemplo, uma associação pode especificar que o software antivírus tem de estar instalado e em execução nas suas instâncias ou que determinadas portas têm de estar fechadas.

Depois de criar uma ou mais associações do State Manager, as informações do estado de conformidade ficam imediatamente disponíveis. Pode ver o estado de conformidade na consola ou em resposta a comandos da CLI da AWS ou a ações da API Systems Manager correspondentes. Para associações, a conformidade da configuração mostra o estado de conformidade (Em conformidade ou Não em conformidade). Também mostra o nível de gravidade atribuído à associação, como Crítico ou Médio.

Para saber mais acerca da conformidade com a associação do State Manager, consulte o artigo Acerca da conformidade com a associação do State Manager no manual do utilizador do AWS Systems Manager.

Recomendação: verifica o estado da conformidade das correções do AWS Systems Manager

Uma associação falhada pode estar relacionada com diferentes aspetos, incluindo alvos e nomes de documentos SSM. Para corrigir este problema, tem de identificar e investigar primeiro a associação através da visualização do histórico de associações. Para ver instruções sobre como ver o histórico de associações, consulte o artigo Ver históricos de associações no manual do utilizador do AWS Systems Manager.

Após a investigação, pode editar a associação para corrigir o problema identificado. Pode editar uma associação para especificar um novo nome, agendamento, nível de gravidade ou segmentações. Depois de editar uma associação, o AWS Systems Manager cria uma nova versão. Para obter instruções sobre como editar uma associação, consulte o artigo Editar e criar uma nova versão de uma associação no manual do utilizador do AWS Systems Manager.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Ec2 Metadata Service Allows Imdsv2

Nome da categoria na API: EC2_METADATA_SERVICE_ALLOWS_IMDSV2

Quando ativam o serviço de metadados em instâncias do AWS EC2, os utilizadores têm a opção de usar a versão 1 do serviço de metadados de instâncias (IMDSv1; um método de pedido/resposta) ou a versão 2 do serviço de metadados de instâncias (IMDSv2; um método orientado para a sessão).

Recomendação: certifique-se de que o serviço de metadados do EC2 só permite o IMDSv2

Na consola:
1. Inicie sessão na consola de gestão da AWS e abra a consola do Amazon EC2 através de https://console.aws.amazon.com/ec2/
2. No menu Instâncias, selecione Instâncias.
3. Para cada instância, selecione a instância e, em seguida, escolha Ações > Modificar opções de metadados da instância.
4. Se o serviço de metadados de instâncias estiver ativado, defina o IMDSv2 como Obrigatório.

Na linha de comandos:

aws ec2 modify-instance-metadata-options --instance-id <instance_id> --http-tokens required

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Ec2 Volume Inuse Check

Nome da categoria na API: EC2_VOLUME_INUSE_CHECK

Identificar e remover volumes do Elastic Block Store (EBS) não associados (não usados) na sua conta da AWS para reduzir o custo da fatura mensal da AWS. A eliminação de volumes EBS não utilizados também reduz o risco de dados confidenciais/sensíveis saírem das suas instalações. Além disso, este controlo também verifica se as instâncias do EC2 arquivadas estão configuradas para eliminar volumes no encerramento.

Por predefinição, as instâncias do EC2 estão configuradas para eliminar os dados em todos os volumes do EBS associados à instância e para eliminar o volume do EBS raiz da instância. No entanto, todos os volumes EBS não raiz anexados à instância, no lançamento ou durante a execução, são mantidos após a rescisão por predefinição.

Recomendação: verifica se os volumes do EBS estão associados a instâncias do EC2 e configurados para eliminação no encerramento da instância

Para corrigir esta deteção, conclua os seguintes passos:

Terraform

Para evitar este cenário com o Terraform, crie instâncias do EC2 com blocos EBS incorporados. Isto garante que todos os blocos EBS associados à instância (não apenas a raiz) são eliminados no encerramento da instância, uma vez que o atributo ebs_block_device.delete_on_termination tem o valor predefinido true.

resource "aws_instance" "web" {
    ami                    = <ami_id>
    instance_type          = <instance_flavor>
    ebs_block_device {
      delete_on_termination = true # Default
      device_name           = "/dev/sdh"
    }

Consola AWS

Para eliminar um volume do EBS através da consola

1. Abra a consola do Amazon EC2 em https://console.aws.amazon.com/ec2/.
2. No painel de navegação, escolha Volumes.
3. Selecione o volume a eliminar e escolha Ações, Eliminar volume.
4. Nota: se a opção Eliminar volume estiver esbatida, o volume está associado a uma instância. Tem de desassociar o volume da instância antes de o poder eliminar.
5. Na caixa de diálogo de confirmação, escolha Eliminar.

AWS CLI

Este comando de exemplo elimina um volume disponível com o ID do volume vol-049df61146c4d7901. Se o comando for bem-sucedido, não é devolvido nenhum resultado.

aws ec2 delete-volume --volume-id vol-049df61146c4d7901

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Efs Encrypted Check

Nome da categoria na API: EFS_ENCRYPTED_CHECK

O Amazon EFS suporta duas formas de encriptação para sistemas de ficheiros: encriptação de dados em trânsito e encriptação em repouso. Esta verificação garante que todos os sistemas de ficheiros EFS estão configurados com encriptação em repouso em todas as regiões ativadas na conta.

Recomendação: verifica se o EFS está configurado para encriptar dados de ficheiros através do KMS

Para corrigir esta deteção, conclua os seguintes passos:

Terraform

O seguinte fragmento do código pode ser usado para criar um EFS encriptado pelo KMS (nota: o atributo kms_key_id é opcional e é criada uma chave se não for transmitido nenhum ID da chave do KMS)

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"
  }
}

Consola AWS

Para configurar o EFS com encriptação através da consola da AWS, consulte o artigo Encriptar um sistema de ficheiros em repouso através da consola.

AWS CLI

É importante notar que, embora a criação de EFS a partir da consola ative a encriptação em repouso por predefinição, isso não se aplica ao EFS criado através da CLI, da API ou do SDK. O exemplo seguinte permite-lhe criar um sistema de ficheiros encriptado na sua infraestrutura.

aws efs create-file-system \
--backup \
--encrypted \
--region us-east-1 \

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Efs In Backup Plan

Nome da categoria na API: EFS_IN_BACKUP_PLAN

As práticas recomendadas da Amazon sugerem a configuração de cópias de segurança para os seus sistemas de ficheiros elásticos (EFS). Esta ação verifica todos os EFS em todas as regiões ativadas na sua conta da AWS para ver se existem cópias de segurança ativadas.

Recomendação: verifica se os sistemas de ficheiros EFS estão incluídos nos planos do AWS Backup

Para corrigir esta deteção, conclua os seguintes passos:

Terraform

Use o recurso aws_efs_backup_policy para configurar uma política de cópia de segurança para sistemas de ficheiros 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"
  }
}

Consola AWS

Existem duas opções para fazer uma cópia de segurança do EFS: o serviço AWS Backup e a solução de cópia de segurança do EFS para o EFS. Para corrigir o EFS sem cópia de segurança através da consola, consulte:

1. Usar o AWS Backup para fazer uma cópia de segurança e restaurar sistemas de ficheiros do Amazon EFS
2. Cópia de segurança de EFS para EFS

AWS CLI

Existem algumas opções para criar sistemas de ficheiros EFS em conformidade através da CLI:

1. Crie um EFS com a cópia de segurança automática ativada (predefinição para o armazenamento de uma zona e condicional à disponibilidade da cópia de segurança na região da AWS)
2. Crie um EFS e coloque uma política de cópia de segurança

No entanto, partindo do princípio de que a correção tem de ocorrer no EFS existente, a melhor opção é criar uma política de cópia de segurança e associá-la ao EFS em conformidade. Precisa 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 suportados e as definições de análise deste tipo de descoberta.

Elb Acm Certificate Required

Nome da categoria na API: ELB_ACM_CERTIFICATE_REQUIRED

Verifica se o Classic Load Balancer usa certificados HTTPS/SSL fornecidos pelo AWS Certificate Manager (ACM). O controlo falha se o Classic Load Balancer configurado com o ouvinte HTTPS/SSL não usar um certificado fornecido pelo ACM.

Para criar um certificado, pode usar o ACM ou uma ferramenta que suporte os protocolos SSL e TLS, como o OpenSSL. O Security Hub recomenda que use o ACM para criar ou importar certificados para o seu equilibrador de carga.

O ACM integra-se com os balanceadores de carga clássicos para que possa implementar o certificado no seu balanceador de carga. Também deve renovar automaticamente estes certificados.

Recomendação: verifica se todos os equilibradores de carga clássicos usam certificados SSL fornecidos pelo AWS Certificate Manager

Para obter informações sobre como associar um certificado SSL/TLS do ACM a um Classic Load Balancer, consulte o artigo do centro de conhecimentos da AWS Como posso associar um certificado SSL/TLS do ACM a um Classic, Application ou Network Load Balancer?

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Elb Deletion Protection Enabled

Nome da categoria na API: ELB_DELETION_PROTECTION_ENABLED

Verifica se um Application Load Balancer tem a proteção contra eliminação ativada. O controlo falha se a proteção contra eliminação não estiver configurada.

Ative a proteção contra eliminação para proteger o seu Application Load Balancer contra eliminação.

Recomendação: a proteção contra eliminação do balanceador de carga de aplicações deve estar ativada

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

Para evitar que o balanceador de carga seja eliminado acidentalmente, pode ativar a proteção contra eliminação. Por predefinição, a proteção contra eliminação está desativada para o seu equilibrador de carga.

Se ativar a proteção contra eliminação para o equilibrador de carga, tem de desativar a proteção contra eliminação antes de poder eliminar o equilibrador de carga.

Para ativar a proteção contra eliminação a partir da consola.

1. Abra a consola do Amazon EC2 em https://console.aws.amazon.com/ec2/.
2. No painel de navegação, em EQUILÍBRIO DE CARGA, escolha Equilibradores de carga.
3. Escolha o balanceador de carga.
4. No separador Descrição, escolha Editar atributos.
5. Na página Editar atributos do equilibrador de carga, selecione Ativar para proteção contra eliminação e, de seguida, escolha Guardar.
6. Selecione Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Elb Logging Enabled

Nome da categoria na API: ELB_LOGGING_ENABLED

Esta verificação determina se o Application Load Balancer e o Classic Load Balancer têm o registo ativado. O controlo falha se access_logs.s3.enabled for falso.

O Elastic Load Balancing fornece registos de acesso que capturam informações detalhadas sobre os pedidos enviados para o seu equilibrador de carga. Cada registo contém informações como a hora em que o pedido foi recebido, o endereço IP do cliente, as latências, os caminhos dos pedidos e as respostas do servidor. Pode usar estes registos de acesso para analisar padrões de tráfego e resolver problemas.

Para saber mais, consulte o artigo Registos de acesso para o seu balanceador de carga clássico no guia do utilizador para balanceadores de carga clássicos.

Recomendação: verifica se os balanceadores de carga clássicos e de aplicações têm o registo ativado

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

Para corrigir este problema, atualize os balanceadores de carga para ativar o registo.

Para ativar os registos de acesso

1. Abra a consola do Amazon EC2 em https://console.aws.amazon.com/ec2/.
2. No painel de navegação, escolha Equilibradores de carga.
3. Escolha um balanceador de carga de aplicações ou um balanceador de carga clássico.
4. Em Ações, escolha Editar atributos.
5. Em Registos de acesso, escolha Ativar.
6. Introduza a sua localização do S3. Esta localização pode existir ou ser criada para si. Se não especificar um prefixo, os registos de acesso são armazenados na raiz do contentor do S3.
7. Selecione Guardar.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Elb Tls Https Listeners Only

Nome da categoria na API: ELB_TLS_HTTPS_LISTENERS_ONLY

Esta verificação garante que todos os equilibradores de carga clássicos estão configurados para usar a comunicação segura.

Um ouvinte é um processo que verifica os pedidos de ligação. Está configurado com um protocolo e uma porta para ligações de front-end (cliente para balanceador de carga) e um protocolo e uma porta para ligações de back-end (balanceador de carga para instância). Para obter informações sobre as portas, os protocolos e as configurações de escuta suportados pelo Elastic Load Balancing, consulte o artigo Ouvintes para o seu Classic Load Balancer.

Recomendação: verifica se todos os balanceadores de carga clássicos estão configurados com ouvintes SSL ou HTTPS

Para configurar o SSL ou o TLS para balanceadores de carga clássicos, consulte o artigo Crie um balanceador de carga HTTPS/SSL com a AWS Management Console.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Encrypted Volumes

Nome da categoria na API: ENCRYPTED_VOLUMES

Verifica se os volumes EBS que estão num estado anexado estão encriptados. Para passar esta verificação, os volumes do EBS têm de estar em utilização e encriptados. Se o volume do EBS não estiver anexado, não está sujeito a esta verificação.

Para uma camada adicional de segurança dos seus dados confidenciais em volumes EBS, deve ativar a encriptação EBS em repouso. A encriptação do Amazon EBS oferece uma solução de encriptação simples para os seus recursos do EBS que não requer que crie, mantenha e proteja a sua própria infraestrutura de gestão de chaves. Usa chaves do KMS quando cria volumes e capturas de ecrã encriptados.

Para saber mais sobre a encriptação do Amazon EBS, consulte a encriptação do Amazon EBS no manual do utilizador do Amazon EC2 para instâncias do Linux.

Recomendação: os volumes do Amazon EBS anexados devem ser encriptados em repouso

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

Não existe uma forma direta de encriptar um volume ou uma captura de ecrã não encriptados existentes. Só pode encriptar um novo volume ou uma nova captura de ecrã quando os cria.

Se ativou a encriptação por predefinição, o Amazon EBS encripta o novo volume ou a nova captura de ecrã resultante com a sua chave predefinida para a encriptação do Amazon EBS. Mesmo que não tenha ativado a encriptação por predefinição, pode ativá-la quando cria um volume ou uma captura de ecrã individual. Em ambos os casos, pode substituir a chave predefinida para a encriptação do Amazon EBS e escolher uma chave gerida pelo cliente simétrica.

Para mais informações, consulte os artigos Criar um volume do Amazon EBS e Copiar uma captura instantânea do Amazon EBS no manual do utilizador do Amazon EC2 para instâncias do Linux.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Encryption At Rest Enabled Rds Instances

Nome da categoria na API: ENCRYPTION_AT_REST_ENABLED_RDS_INSTANCES

As instâncias de BD encriptadas do Amazon RDS usam o algoritmo de encriptação AES-256, a norma da indústria, para encriptar os seus dados no servidor que aloja as instâncias de BD do Amazon RDS. Depois de os dados serem encriptados, o Amazon RDS processa a autenticação do acesso e a desencriptação dos dados de forma transparente com um impacto mínimo no desempenho.

Recomendação: certifique-se de que a encriptação em repouso está ativada para instâncias do RDS

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

1. Inicie sessão na AWS Management Console e abra o painel de controlo do RDS em https://console.aws.amazon.com/rds/.
2. No painel de navegação do lado esquerdo, clique em Databases
3. Selecione a instância da base de dados que precisa de ser encriptada.
4. Clique no botão Actions situado na parte superior direita e selecione Take Snapshot.
5. Na página Tirar instantâneo, introduza um nome da base de dados da qual quer tirar um instantâneo no campo Snapshot Name e clique em Take Snapshot.
6. Selecione a captura de ecrã recém-criada, clique no botão Action na parte superior direita e selecione Copy snapshot no menu Ações.
7. Na página Make Copy of DB Snapshot (Criar cópia da captura instantânea da base de dados), faça o seguinte:

• No campo Novo identificador de instantâneo da BD, introduza um nome para o new snapshot.
• Marque Copy Tags. O novo instantâneo tem de ter as mesmas etiquetas que o instantâneo de origem.
• Selecione Yes na lista pendente Enable Encryption para ativar a encriptação. Pode optar por usar a chave de encriptação predefinida da AWS ou uma chave personalizada na lista pendente de chaves principais.

8. Clique em Copy Snapshot para criar uma cópia encriptada do resumo da instância selecionada.
9. Selecione a nova cópia encriptada da imagem instantânea, clique no botão Action no canto superior direito e selecione o botão Restore Snapshot no menu Ação. Esta ação restaura a imagem instantânea encriptada para uma nova instância da base de dados.
10. Na página Restore DB Instance (Restaurar instância de base de dados), introduza um nome exclusivo para a nova instância de base de dados no campo DB Instance Identifier (Identificador da instância de base de dados).
11. Reveja os detalhes de configuração da instância e clique em Restore DB Instance.
12. À medida que o processo de aprovisionamento da nova instância é concluído, pode atualizar a configuração da aplicação para fazer referência ao ponto final da nova instância da base de dados encriptada. Assim que o ponto final da base de dados for alterado ao nível da aplicação, pode remover a instância não encriptada.

AWS CLI

1. Execute o comando describe-db-instances para listar todos os nomes de bases de dados RDS disponíveis na região da AWS selecionada. O resultado do comando deve devolver o identificador da instância da base de dados.

aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'

2. Execute o comando create-db-snapshot para criar um instantâneo para a instância da base de dados selecionada. O resultado do comando devolve 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 alias das chaves do KMS disponíveis numa região especificada. O resultado do comando deve devolver cada key alias currently available. Para o nosso processo de ativação da encriptação RDS, localize o ID da chave KMS predefinida da AWS.

aws kms list-aliases --region <region-name>

4. Execute o comando copy-db-snapshot com o ID da chave do KMS predefinido para as instâncias do RDS devolvidas anteriormente para criar uma cópia encriptada do instantâneo da instância da base de dados. O resultado do comando devolve 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 a imagem instantânea encriptada criada no passo anterior para uma nova instância da base de dados. Se for bem-sucedido, o resultado do comando deve devolver a nova configuração da instância da base de dados encriptada.

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 bases de dados do RDS, disponíveis na região da AWS selecionada. O resultado devolve o nome do identificador da instância da base de dados. Selecione o nome da base de dados encriptada que acabámos de criar, DB-Name-Encrypted.

aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'

7. Execute novamente o comando describe-db-instances com o identificador da instância do RDS devolvido anteriormente para determinar se a instância da base de dados selecionada está encriptada. O resultado do comando deve devolver o estado de encriptação True.

aws rds describe-db-instances --region <region-name> --db-instance-identifier <DB-Name-Encrypted> --query 'DBInstances[*].StorageEncrypted'

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Encryption Enabled Efs File Systems

Nome da categoria na API: ENCRYPTION_ENABLED_EFS_FILE_SYSTEMS

Os dados do EFS devem ser encriptados em repouso através do AWS KMS (Key Management Service).

Recomendação: certifique-se de que a encriptação está ativada para sistemas de ficheiros EFS

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

1. Inicie sessão na AWS Management Console e navegue para o painel de controlo Elastic File System (EFS).
2. Selecione File Systems no painel de navegação do lado esquerdo.
3. Clique no botão Create File System no menu superior do painel de controlo para iniciar o processo de configuração do sistema de ficheiros.

4. Na página de configuração Configure file system access, execute as seguintes ações.
   - Escolha a VPC certa na lista pendente de VPCs.
   - Na secção Criar destinos de montagem, selecione as caixas de verificação de todas as zonas de disponibilidade (AZs) na VPC selecionada. Estes serão os seus alvos de montagem.
   - Clique em Next step para continuar.

5. Faça o seguinte na página Configure optional settings.
   - Crie tags para descrever o seu novo sistema de ficheiros.
   - Escolha performance mode com base nos seus requisitos.
   - Selecione a caixa de verificação Enable encryption e escolha aws/elasticfilesystem na lista pendente Selecionar chave principal do KMS para ativar a encriptação do novo sistema de ficheiros através da chave principal predefinida fornecida e gerida pelo AWS KMS.
   - Clique em Next step para continuar.

6. Reveja os detalhes da configuração do sistema de ficheiros na página review and create e, de seguida, clique em Create File System para criar o novo sistema de ficheiros do AWS EFS.

7. Copie os dados do sistema de ficheiros EFS não encriptado antigo para o sistema de ficheiros encriptado recém-criado.
8. Remova o sistema de ficheiros não encriptado assim que a migração de dados para o sistema de ficheiros encriptado recém-criado estiver concluída.
9. Altere a região da AWS na barra de navegação e repita todo o processo para outras regiões da AWS.

A partir da CLI:
1. Execute o comando describe-file-systems para descrever as informações de configuração disponíveis para o sistema de ficheiros selecionado (não encriptado) (consulte a secção Auditoria para identificar o recurso certo):

aws efs describe-file-systems --region <region> --file-system-id <file-system-id from audit section step 2 output>

2. O resultado do comando deve devolver as informações de configuração pedidas.
3. Para aprovisionar um novo sistema de ficheiros AWS EFS, tem de gerar um identificador universalmente único (UUID) para criar o token necessário para o comando create-file-system. Para criar o token necessário, pode usar um UUID gerado aleatoriamente a partir de "https://www.uuidgenerator.net".
4. Execute o comando create-file-system com o token único criado no passo anterior.

aws efs create-file-system --region <region> --creation-token <Token (randomly generated UUID from step 3)> --performance-mode generalPurpose --encrypted

5. O resultado do comando deve devolver os metadados de configuração do novo sistema de ficheiros.
6. Execute o comando create-mount-target com o ID do sistema de ficheiros EFS recém-criado devolvido no passo 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. O resultado do comando deve devolver os novos metadados do destino de montagem.
8. Agora, pode montar o seu sistema de ficheiros a partir de uma instância do EC2.
9. Copie os dados do sistema de ficheiros EFS não encriptado antigo para o sistema de ficheiros encriptado recém-criado.
10. Remova o sistema de ficheiros não encriptado assim que a migração de dados para o sistema de ficheiros encriptado recém-criado estiver concluída.

aws efs delete-file-system --region <region> --file-system-id <unencrypted-file-system-id>

11. Altere a região da AWS atualizando o parâmetro --region e repita todo o processo para outras regiões da AWS.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Iam Password Policy

Nome da categoria na API: IAM_PASSWORD_POLICY

A AWS permite políticas de palavras-passe personalizadas na sua conta da AWS para especificar requisitos de complexidade e períodos de rotação obrigatórios para as palavras-passe dos seus utilizadores do IAM. Se não definir uma política de palavras-passe personalizada, as palavras-passe de utilizadores do IAM têm de cumprir a política de palavras-passe predefinida da AWS. As práticas recomendadas de segurança da AWS recomendam os seguintes requisitos de complexidade da palavra-passe:

• Exigir, pelo menos, um caráter em maiúsculas na palavra-passe.
• Exigir, pelo menos, um caráter em minúsculas nas palavras-passe.
• Exigir, pelo menos, um símbolo nas palavras-passe.
• Exigir, pelo menos, um número nas palavras-passe.
• Exija um comprimento mínimo da palavra-passe de, pelo menos, 14 carateres.
• Exigir, pelo menos, 24 palavras-passe antes de permitir a reutilização.
• Exigir, pelo menos, 90 dias antes do vencimento da palavra-passe

Este controlo verifica todos os requisitos da política de palavras-passe especificados.

Recomendação: verifica se a política de palavras-passe da conta para utilizadores do IAM cumpre os requisitos especificados

Para corrigir esta deteção, conclua os seguintes passos:

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
}

Consola AWS

Para criar uma política de palavras-passe personalizada

1. Inicie sessão na AWS Management Console e abra a consola do IAM em https://console.aws.amazon.com/iam/.
2. No painel de navegação, escolha Definições da conta.
3. Na secção Política de palavras-passe, escolha Alterar política de palavras-passe.
4. Selecione as opções que quer aplicar à sua política de palavras-passe e escolha Guardar alterações.

Para alterar uma política de palavras-passe personalizada

1. Inicie sessão na AWS Management Console e abra a consola do IAM em https://console.aws.amazon.com/iam/.
2. No painel de navegação, escolha Definições da conta.
3. Na secção Política de palavras-passe, escolha Alterar.
4. Selecione as opções que quer aplicar à sua política de palavras-passe e escolha Guardar alterações.

AWS CLI

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 suportados e as definições de análise deste tipo de descoberta.

Iam Password Policy Prevents Password Reuse

Nome da categoria na API: IAM_PASSWORD_POLICY_PREVENTS_PASSWORD_REUSE

As políticas de palavras-passe da IAM podem impedir a reutilização de uma determinada palavra-passe pelo mesmo utilizador. Recomendamos que a política de palavras-passe impeça a reutilização de palavras-passe.

Recomendação: certifique-se de que a política de palavras-passe do IAM impede a reutilização de palavras-passe

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

1. Inicie sessão na consola da AWS (com as autorizações adequadas para ver as definições da conta de gestão de identidade e acesso)
2. Aceda ao serviço IAM na consola da AWS
3. Clique em Definições da conta no painel do lado esquerdo
4. Selecione "Impedir a reutilização de palavras-passe"
5. A opção "Número de palavras-passe a memorizar" está definida como 24

AWS CLI

 aws iam update-account-password-policy --password-reuse-prevention 24

Nota: todos os comandos que começam por "aws iam update-account-password-policy" podem ser combinados num único comando.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 palavras-passe são usadas, em parte, para aplicar os requisitos de complexidade de palavras-passe. As políticas de palavras-passe da IAM podem ser usadas para garantir que as palavras-passe têm, pelo menos, um determinado comprimento. Recomendamos que a política de palavras-passe exija um comprimento mínimo de 14 carateres.

Recomendação: certifique-se de que a política de palavras-passe da IAM requer um comprimento mínimo de 14 ou mais

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

1. Inicie sessão na consola da AWS (com as autorizações adequadas para ver as definições da conta de gestão de identidade e acesso)
2. Aceda ao serviço IAM na consola da AWS
3. Clique em Definições da conta no painel do lado esquerdo
4. Defina "Comprimento mínimo da palavra-passe" como 14 ou superior.
5. Clique em "Aplicar política de palavras-passe"

AWS CLI

 aws iam update-account-password-policy --minimum-password-length 14

Nota: todos os comandos que começam por "aws iam update-account-password-policy" podem ser combinados num único comando.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 de IAM são o meio através do qual os privilégios são concedidos a utilizadores, 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 autorizações necessárias para realizar uma tarefa. Determine o que os utilizadores precisam de fazer e, em seguida, crie políticas para eles que lhes permitam realizar apenas essas tarefas, em vez de permitir privilégios administrativos completos.

Recomendação: certifique-se de que não estão anexadas políticas de IAM que permitam privilégios administrativos "*:*" completos

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

Faça o seguinte para desassociar a política que tem privilégios administrativos completos:

1. Inicie sessão na AWS Management Console e abra a consola do IAM em https://console.aws.amazon.com/iam/.
2. No painel de navegação, clique em Políticas e, de seguida, pesquise o nome da política encontrado no passo de auditoria.
3. Selecione a política que tem de ser eliminada.
4. No menu de ações da política, selecione primeiro Detach
5. Selecione todos os utilizadores, grupos e funções aos quais esta política está anexada
6. Clique em Detach Policy
7. No menu de ações da política, selecione Detach

AWS CLI

Execute o seguinte para desanexar a política que tem privilégios administrativos completos, conforme encontrado no passo de auditoria:

1. Apresenta todos os utilizadores, grupos e funções do IAM aos quais a política gerida especificada está anexada.

 aws iam list-entities-for-policy --policy-arn <policy_arn>

2. Desassocie a política de todos os utilizadores do IAM:

 aws iam detach-user-policy --user-name <iam_user> --policy-arn <policy_arn>

3. Desassocie a política de todos os grupos de IAM:

 aws iam detach-group-policy --group-name <iam_group> --policy-arn <policy_arn>

4. Desassocie a política de todas as funções de IAM:

 aws iam detach-role-policy --role-name <iam_role> --policy-arn <policy_arn>

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Iam Users Receive Permissions Groups

Nome da categoria na API: IAM_USERS_RECEIVE_PERMISSIONS_GROUPS

Os utilizadores do IAM recebem acesso a serviços, funções e dados através de políticas do IAM. Existem quatro formas de definir políticas para um utilizador: 1) editar a política do utilizador diretamente, também conhecida como política inline ou do utilizador; 2) anexar uma política diretamente a um utilizador; 3) adicionar o utilizador a um grupo do IAM que tenha uma política anexada; 4) adicionar o utilizador a um grupo do IAM que tenha uma política inline.

Recomendamos apenas a terceira implementação.

Recomendação: certifique-se de que os utilizadores do IAM só recebem autorizações através de grupos

Faça o seguinte para criar um grupo do IAM e atribuir-lhe uma política:

1. Inicie sessão na AWS Management Console e abra a consola do IAM em https://console.aws.amazon.com/iam/.
2. No painel de navegação, clique em Groups e, de seguida, em Create New Group .
3. Na caixa Group Name, escreva o nome do grupo e, de seguida, clique em Next Step .
4. Na lista de políticas, selecione a caixa de verificação de cada política que quer aplicar a todos os membros do grupo. Em seguida, clique em Next Step .
5. Clique em Create Group

Faça o seguinte para adicionar um utilizador a um determinado grupo:

1. Inicie sessão na AWS Management Console e abra a consola do IAM em https://console.aws.amazon.com/iam/.
2. No painel de navegação, clique em Groups
3. Selecione o grupo ao qual quer adicionar um utilizador
4. Clique em Add Users To Group
5. Selecione os utilizadores a adicionar ao grupo
6. Clique em Add Users

Faça o seguinte para remover uma associação direta entre um utilizador e uma política:

1. Inicie sessão na AWS Management Console e abra a consola do IAM em https://console.aws.amazon.com/iam/.
2. No painel de navegação do lado esquerdo, clique em Utilizadores
3. Para cada utilizador:
   - Selecione o utilizador
   - Clique no separador Permissions
   - Expanda Permissions policies
   - Clique em X para cada política e, de seguida, clique em Desanexar ou Remover (consoante o tipo de política)

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Iam User Group Membership Check

Nome da categoria na API: IAM_USER_GROUP_MEMBERSHIP_CHECK

Os utilizadores do IAM devem fazer sempre parte de um grupo do IAM para aderirem às práticas recomendadas de segurança do IAM.

Ao adicionar utilizadores a um grupo, é possível partilhar políticas entre tipos de utilizadores.

Recomendação: verifica se os utilizadores do IAM são membros de, pelo menos, um grupo do IAM

Para corrigir esta deteção, conclua os seguintes passos:

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]
}

Consola AWS

Quando usa a AWS Management Console para eliminar um utilizador do IAM, o IAM elimina automaticamente as seguintes informações:

1. O utilizador
2. Todas as associações a grupos de utilizadores, ou seja, o utilizador é removido de todos os grupos de utilizadores do IAM dos quais era membro
3. Qualquer palavra-passe associada ao utilizador
4. Todas as chaves de acesso pertencentes ao utilizador
5. Todas as políticas incorporadas no utilizador (as políticas aplicadas a um utilizador através das autorizações do grupo de utilizadores não são afetadas)

Para eliminar um utilizador do IAM:

1. Inicie sessão na AWS Management Console e abra a consola do IAM em https://console.aws.amazon.com/iam/.
2. No painel de navegação, escolha Utilizadores e, de seguida, selecione a caixa de verificação junto ao nome do utilizador que quer eliminar.
3. Na parte superior da página, escolha Eliminar.
4. Na caixa de diálogo de confirmação, introduza o nome de utilizador no campo de introdução de texto para confirmar a eliminação do utilizador.
5. Escolha Eliminar.

Para adicionar um utilizador a um grupo de utilizadores do IAM:

1. Inicie sessão na AWS Management Console e abra a consola do IAM em https://console.aws.amazon.com/iam/.
2. No painel de navegação, escolha Grupos de utilizadores e, em seguida, escolha o nome do grupo.
3. Escolha o separador Utilizadores e, de seguida, escolha Adicionar utilizadores. Selecione a caixa de verificação junto aos utilizadores que quer adicionar.
4. Escolha Adicionar utilizadores.

AWS CLI

Ao contrário da Amazon Web Services Management Console, quando elimina um utilizador através de programação, tem de eliminar manualmente os itens anexados ao utilizador. Caso contrário, a eliminação falha.

Antes de tentar eliminar um utilizador, remova os seguintes itens:

1. Palavra-passe ( DeleteLoginProfile )
2. Chaves de acesso ( DeleteAccessKey )
3. Certificado de assinatura ( DeleteSigningCertificate )
4. Chave pública de SSH ( DeleteSSHPublicKey )
5. Credenciais do Git ( DeleteServiceSpecificCredential )
6. Dispositivo de autenticação multifator (MFA) ( DeactivateMFADevice , DeleteVirtualMFADevice )
7. Políticas inline ( DeleteUserPolicy )
8. Políticas geridas anexadas ( DetachUserPolicy )
9. Subscrições do grupo ( RemoveUserFromGroup )

Para eliminar um utilizador, depois de eliminar todos os itens anexados ao utilizador:

aws iam delete-user \
  --user-name "test-user"

Para adicionar um utilizador 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 suportados e as definições de análise deste 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 adicional de proteção além dos nomes de utilizador e das palavras-passe. Com a MFA, quando um utilizador inicia sessão na AWS Management Console, tem de fornecer um código de autenticação sensível ao tempo, fornecido por um dispositivo virtual ou físico registado.

Recomendação: verifica se os utilizadores do AWS IAM têm a autenticação multifator (MFA) ativada

Para corrigir esta deteção, conclua os seguintes passos:

Terraform

No que diz respeito ao Terraform, existem algumas opções para corrigir a ausência de dispositivos de MFA. Provavelmente, já tem uma estrutura sensata para organizar os seus utilizadores em grupos e políticas restritivas.

O exemplo seguinte mostra como:

1. Crie utilizadores.
2. Crie perfis de início de sessão de utilizadores com uma chave pública PGP.
3. Crie um grupo e uma política de grupo que permitam a autogestão do perfil do IAM.
4. Associe utilizadores ao grupo.
5. Crie dispositivos MFA virtuais para os utilizadores.
6. Forneça a cada utilizador o código QR de saída e a palavra-passe.

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 }
}

Consola AWS

Para ativar a MFA para quaisquer contas de utilizador com acesso à consola AWS, consulte o artigo Ativar um dispositivo de autenticação multifator (MFA) virtual (consola) na documentação da AWS.

AWS CLI

Crie um dispositivo MFA

aws iam create-virtual-mfa-device \
  --virtual-mfa-device-name "[e-mail]" \
  --outfile ./QRCode.png \
  --bootstrap-method QRCodePNG

Ative o dispositivo MFA para um utilizador existente

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 suportados e as definições de análise deste tipo de descoberta.

Iam User Unused Credentials Check

Nome da categoria na API: IAM_USER_UNUSED_CREDENTIALS_CHECK

Esta verificação procura palavras-passe da IAM ou chaves de acesso ativas que não foram usadas nos últimos 90 dias.

As práticas recomendadas sugerem que remova, desative ou altere todas as credenciais não usadas durante 90 dias ou mais. Isto reduz a janela de oportunidade para a utilização de credenciais associadas a uma conta comprometida ou abandonada.

Recomendação: verifica se todos os utilizadores do AWS IAM têm palavras-passe ou chaves de acesso ativas que não foram usadas durante um máximo de dias de maxCredentialUsageAge (90 por predefinição)

Para corrigir esta deteção, conclua os seguintes passos:

Terraform

Para remover chaves de acesso expiradas criadas através do Terraform, remova o recurso aws_iam_access_key do seu módulo e aplique a alteração.

Para repor a palavra-passe de início de sessão de um utilizador do IAM, use -replace quando executar terraform apply.

Supondo o seguinte perfil de início de sessão do utilizador

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 seguinte comando para repor a palavra-passe do perfil de início de sessão do utilizador

terraform apply -replace="aws_iam_user_login_profile.example"

Consola AWS

Para desativar credenciais de contas inativas:

1. Abra a consola do IAM em https://console.aws.amazon.com/iam/.
2. Escolha Utilizadores.
3. Escolha o nome do utilizador cujas credenciais têm mais de 90 dias ou foram usadas pela última vez há mais de 90 dias.
4. Escolha Credenciais de segurança.
5. Para cada credencial de início de sessão e chave de acesso que não tenha sido usada durante, pelo menos, 90 dias, escolha Tornar inativa.

Para exigir uma nova palavra-passe aos utilizadores da consola no início de sessão seguinte:

1. Abra a consola do IAM em https://console.aws.amazon.com/iam/.
2. Escolha Utilizadores.
3. Escolha o nome do utilizador cujas credenciais têm mais de 90 dias ou foram usadas pela última vez há mais de 90 dias.
4. Escolha Credenciais de segurança.
5. Em Credenciais de início de sessão e palavra-passe da consola, escolha Gerir.
6. Definir uma nova palavra-passe (gerada automaticamente ou personalizada).
7. Selecione a caixa para exigir a reposição da palavra-passe.
8. Escolha Aplicar.

AWS CLI

Para tornar as chaves de acesso inativas

aws iam update-access-key \
  --access-key-id <value> \
  --status "Inactive"

Para eliminar chaves de acesso

aws iam delete-access-key \
  --access-key-id <value>

Para repor a palavra-passe de um perfil de início de sessão de utilizador

aws iam update-login-profile \
  --user-name "[e-mail]" \
  --password <temporary_password> \
  --password-reset-required

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Kms Cmk Not Scheduled For Deletion

Nome da categoria na API: KMS_CMK_NOT_SCHEDULED_FOR_DELETION

Este controlo verifica se as chaves do KMS estão agendadas para eliminação. O controlo falha se uma chave do KMS estiver agendada para eliminação.

Não é possível recuperar as chaves do KMS depois de eliminadas. Os dados encriptados com uma chave do KMS também são permanentemente irrecuperáveis se a chave do KMS for eliminada. Se dados significativos tiverem sido encriptados com uma chave do KMS agendada para eliminação, considere desencriptar os dados ou reencriptá-los com uma nova chave do KMS, a menos que esteja a realizar intencionalmente uma eliminação criptográfica.

Quando uma chave do KMS é agendada para eliminação, é aplicado um período de espera obrigatório para permitir a reversão da eliminação, caso tenha sido agendada por engano. O período de espera predefinido é de 30 dias, mas pode ser reduzido para um mínimo de 7 dias quando a chave do KMS está agendada para eliminação. Durante o período de espera, é possível cancelar a eliminação agendada e a chave do KMS não é eliminada.

Para mais informações sobre a eliminação de chaves do KMS, consulte o artigo Eliminar chaves do KMS no guia do programador do AWS Key Management Service.

Recomendação: verifica se todas as CMKs não estão agendadas para eliminação

Para cancelar uma eliminação de chave do KMS agendada, consulte o artigo Para cancelar a eliminação de chaves em Agendamento e cancelamento da eliminação de chaves (consola) no guia do programador do AWS Key Management Service.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Lambda Concurrency Check

Nome da categoria na API: LAMBDA_CONCURRENCY_CHECK

Verifica se a função Lambda está configurada com um limite de execução concorrente ao nível da função. A regra é NON_COMPLIANT se a função Lambda não estiver configurada com um limite de execução concorrente ao nível da função.

Recomendação: verifica se as funções Lambda estão configuradas com um limite de execução concorrente ao nível da função

Para configurar um limite de execução simultânea ao nível da função, consulte o artigo Configurar a simultaneidade reservada na documentação do AWS Lambda.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Lambda Dlq Check

Nome da categoria na API: LAMBDA_DLQ_CHECK

Verifica se uma função Lambda está configurada com uma fila de mensagens rejeitadas. A regra é NON_COMPLIANT se a função Lambda não estiver configurada com uma fila de mensagens rejeitadas.

Recomendação: verifica se as funções Lambda estão configuradas com uma fila de mensagens rejeitadas

Para atualizar as funções Lambda de modo a usar DLQs, consulte o artigo Filas de mensagens rejeitadas na documentação da AWS.

Saiba mais sobre os recursos suportados e as definições de análise deste 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. Esta política verifica todas as funções Lambda implementadas em todas as regiões ativadas na sua conta e falha se estiverem configuradas para permitir o acesso público.

Recomendação: verifica se a política anexada à função Lambda proíbe o acesso público

Para corrigir esta deteção, conclua os seguintes passos:

Terraform

O exemplo seguinte fornece um exemplo de utilização do Terraform para aprovisionar uma função do IAM que restringe o acesso a uma função Lambda e anexar essa função à função Lambda

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"

}

Consola AWS

Se uma função Lambda falhar neste controlo, 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, tem de atualizar a política para remover as autorizações ou adicionar a condição AWS:SourceAccount. Só pode atualizar a política baseada em recursos a partir da API Lambda.

As instruções seguintes usam a consola para rever a política e a interface de linha de comandos da AWS para remover as autorizações.

Para ver a política baseada em recursos de uma função Lambda

1. Abra a consola do 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 Autorizações. A política baseada em recursos mostra as autorizações que são aplicadas quando outra conta ou serviço da AWS tenta aceder à função.
5. Examine a política baseada em recursos.
6. Identifique a declaração de política que tem valores do campo Principal que tornam a política pública. Por exemplo, permitir "*" ou { "AWS": "*" }.

Não pode editar a política a partir da consola. Para remover autorizações da função, use o comando remove-permission da CLI da AWS.

Tome nota do valor do ID da declaração (Sid) da declaração que quer remover.

AWS CLI

Para usar a CLI para remover autorizações de uma função Lambda, execute o comando remove-permission da seguinte forma.

aws lambda remove-permission \
--function-name <value> \
--statement-id <value>

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Lambda Inside Vpc

Nome da categoria na API: LAMBDA_INSIDE_VPC

Verifica se uma função Lambda está numa VPC. Pode ver resultados com falhas para recursos do Lambda@Edge.

Não avalia a configuração de encaminhamento da sub-rede da VPC para determinar a acessibilidade pública.

Recomendação: verifica se as funções Lambda existem numa VPC

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

Para configurar uma função para se ligar a sub-redes privadas numa nuvem privada virtual (VPC) na sua conta:

1. Abra a consola do AWS Lambda em https://console.aws.amazon.com/lambda/.
2. Navegue para Functions e, de seguida, selecione a sua função Lambda.
3. Desloque a página até Rede e, em seguida, selecione uma VPC com os requisitos de conetividade da função.
4. Para executar as suas funções no modo de alta disponibilidade, o Security Hub recomenda que escolha, pelo menos, duas sub-redes.
5. Escolha, pelo menos, um grupo de segurança que tenha os requisitos de conetividade da função.
6. Selecione Guardar.

Para mais informações, consulte a secção sobre a configuração de uma função Lambda para aceder a recursos numa VPC no guia para programadores do AWS Lambda.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Mfa Delete Enabled S3 Buckets

Nome da categoria na API: MFA_DELETE_ENABLED_S3_BUCKETS

Assim que a eliminação com MFA estiver ativada no seu bucket do S3 sensível e classificado, o utilizador tem de ter duas formas de autenticação.

Recomendação: certifique-se de que a eliminação com MFA está ativada nos contentores do S3

Execute os passos abaixo para ativar a eliminação com MFA num contentor do S3.

Nota:
- Não pode ativar a eliminação com MFA através da AWS Management Console. Tem de usar a CLI ou a API da AWS.
- Tem de usar a sua conta "raiz" para ativar a eliminação com MFA em contentores S3.

Na linha de comandos:

1. Execute o comando s3api put-bucket-versioning

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 suportados e as definições de análise deste tipo de descoberta.

Mfa Enabled Root User Account

Nome da categoria na API: MFA_ENABLED_ROOT_USER_ACCOUNT

A conta de utilizador "raiz" é o utilizador com mais privilégios numa conta da AWS. A autenticação multifator (MFA) adiciona uma camada adicional de proteção além de um nome de utilizador e uma palavra-passe. Com a MFA ativada, quando um utilizador inicia sessão num Website da AWS, é-lhe pedido o nome de utilizador e a palavra-passe, bem como um código de autenticação do respetivo dispositivo MFA da AWS.

Nota: quando a MFA virtual é usada para contas "raiz", recomenda-se que o dispositivo usado NÃO seja um dispositivo pessoal, mas sim um dispositivo móvel dedicado (tablet ou telemóvel) que é gerido para ser mantido carregado e seguro independentemente de quaisquer dispositivos pessoais individuais. ("MFA virtual não pessoal") Isto reduz os riscos de perder o acesso à MFA devido à perda do dispositivo, à retoma do dispositivo ou se o indivíduo proprietário do dispositivo já não trabalhar na empresa.

Recomendação: certifique-se de que a MFA está ativada para a conta de utilizador "raiz"

Faça o seguinte para estabelecer a AFA para a conta de utilizador "raiz":

1. Inicie sessão na AWS Management Console e abra a consola do IAM em https://console.aws.amazon.com/iam/.

Nota: para gerir dispositivos de AVM para a conta da AWS "raiz", tem de usar as credenciais da conta "raiz" para iniciar sessão na AWS. Não pode gerir dispositivos de AFS para a conta "principal" com outras credenciais.

2. Escolha Dashboard e , em Security Status , expanda Activate MFA na sua conta principal.
3. Escolha Activate MFA
4. No assistente, escolha o dispositivo A virtual MFA e, de seguida, escolha Next Step .
5. O IAM gera e apresenta informações de configuração para o dispositivo MFA virtual, incluindo um gráfico de código QR. O gráfico é uma representação da "chave de configuração secreta" que está disponível para introdução manual em dispositivos que não suportam códigos QR.
6. Abra a sua aplicação de MFA virtual. (Para ver uma lista de apps que pode usar para alojar dispositivos MFA virtuais, consulte o artigo Aplicações MFA virtuais.) Se a aplicação de MFA virtual suportar 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 a app de MFA suporta códigos QR e, em seguida, faça uma das seguintes ações:

• Use a app para ler o código QR. Por exemplo, pode escolher o ícone da câmara ou uma opção semelhante a Ler código e, em seguida, usar a câmara do dispositivo para ler o código.
• No assistente Gerir dispositivo de AVM, escolha Mostrar chave secreta para configuração manual e, em seguida, introduza a chave de configuração secreta na sua aplicação de AVM.

Quando terminar, o dispositivo MFA virtual começa a gerar palavras-passe únicas.

No assistente Gerir dispositivo MFA, na caixa Código de autenticação 1, introduza a palavra-passe única que aparece atualmente no dispositivo MFA virtual. Aguarde até 30 segundos para que o dispositivo gere uma nova palavra-passe única. Em seguida, introduza a segunda palavra-passe única na caixa Código de autenticação 2. Escolha Atribuir MFA virtual.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 adicional de garantia de autenticação além das credenciais tradicionais. Com a MFA ativada, quando um utilizador inicia sessão na consola da AWS, é-lhe pedido o nome de utilizador e a palavra-passe, bem como um código de autenticação do respetivo token de MFA físico ou virtual. Recomendamos que a MFA seja ativada para todas as contas que tenham uma palavra-passe da consola.

Recomendação: certifique-se de que a autenticação multifator (MFA) está ativada para todos os utilizadores do IAM que tenham uma palavra-passe da consola

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

1. Inicie sessão na consola de gestão da AWS e abra a consola do IAM em "https://console.aws.amazon.com/iam/"
2. No painel esquerdo, selecione Users.
3. Na lista User Name, escolha o nome do utilizador da MFA pretendido.
4. Escolha o separador Security Credentials e, de seguida, escolha Manage MFA Device.
5. No Manage MFA Device wizard, escolha o dispositivo Virtual MFA e, de seguida, escolha Continue.

O IAM gera e apresenta informações de configuração para o dispositivo MFA virtual, incluindo um gráfico de código QR. O gráfico é uma representação da "chave de configuração secreta" que está disponível para introdução manual em dispositivos que não suportam códigos QR.

6. Abra a sua aplicação de MFA virtual. (Para ver uma lista de apps que pode usar para alojar dispositivos MFA virtuais, consulte Aplicações MFA virtuais em https://aws.amazon.com/iam/details/mfa/#Virtual_MFA_Applications). Se a aplicação de MFA virtual suportar 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 a app de MFA suporta códigos QR e, em seguida, faça uma das seguintes ações:

• Use a app para ler o código QR. Por exemplo, pode escolher o ícone da câmara ou uma opção semelhante a Ler código e, em seguida, usar a câmara do dispositivo para ler o código.
• No assistente Gerir dispositivo de AVM, escolha Mostrar chave secreta para configuração manual e, em seguida, introduza a chave de configuração secreta na sua aplicação de AVM.

Quando terminar, o dispositivo MFA virtual começa a gerar palavras-passe únicas.

8. No Manage MFA Device wizard, no MFA Code 1 box, introduza o one-time password que aparece atualmente no dispositivo MFA virtual. Aguarde até 30 segundos para que o dispositivo gere uma nova palavra-passe única. Em seguida, escreva o segundo one-time password no MFA Code 2 box.

9. Clique em Assign MFA.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 controlo de acesso à rede (NACL) oferece filtragem sem estado do tráfego de rede de entrada e saída para recursos da AWS. Recomendamos que nenhuma NACL permita o acesso de entrada sem restrições a portas de administração de servidores remotos, como SSH à porta 22 e RDP à porta 3389, através dos protocolos TDP (6), UDP (17) ou ALL (-1)

Recomendação: certifique-se de que nenhuma LCA de rede permite a entrada de 0.0.0.0/0 para portas de administração do servidor remoto

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

Faça o seguinte:
1. Inicie sessão na AWS Management Console em https://console.aws.amazon.com/vpc/home
2. No painel esquerdo, clique em Network ACLs
3. Para cada ACL de rede a corrigir, faça o seguinte:
- Selecione a ACL de rede
- Clique no separador Inbound Rules
- Clique em Edit inbound rules
- Em alternativa, 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 ofensiva
- Clique em Save

Saiba mais sobre os recursos suportados e as definições de análise deste 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 utilizador "raiz" é o utilizador com mais privilégios numa conta da AWS. As chaves de acesso da AWS fornecem acesso programático a uma determinada conta da AWS. Recomendamos que elimine todas as chaves de acesso associadas à conta de utilizador "root".

Recomendação: certifique-se de que não existe nenhuma chave de acesso da conta de utilizador "root"

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

1. Inicie sessão na consola de gestão da AWS como "root" e abra a consola do IAM em https://console.aws.amazon.com/iam/.
2. Clique em <root_account> na parte superior direita e selecione My Security Credentials na lista pendente.
3. No ecrã de separação, 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 existirem chaves ativas).
6. Clique em Delete (nota: não é possível recuperar chaves eliminadas).

Nota: embora seja possível tornar uma chave inativa, esta chave inativa continua a ser apresentada no comando da CLI do procedimento de auditoria e pode levar a que uma chave seja falsamente denunciada como não estando em conformidade.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 oferecem filtragem com estado do tráfego de rede de entrada e saída para recursos da AWS. Recomendamos que nenhum grupo de segurança permita o acesso de entrada sem restrições a portas de administração de servidores remotos, como SSH à porta 22 e RDP à porta 3389, através dos protocolos TDP (6), UDP (17) ou ALL (-1)

Recomendação: certifique-se de que nenhum grupo de segurança permite a entrada de 0.0.0.0/0 para portas de administração do servidor remoto

Faça o seguinte para implementar o estado prescrito:

1. Inicie sessão na AWS Management Console em https://console.aws.amazon.com/vpc/home
2. No painel esquerdo, clique em Security Groups
3. Para cada grupo de segurança, faça o seguinte:
4. Selecione o grupo de segurança
5. Clique no separador Inbound Rules
6. Clique no botão Edit inbound rules
7. Identifique as regras a editar ou remover
8. A) Atualize o campo de origem para um intervalo diferente de 0.0.0.0/0 ou B) clique em Delete para remover a regra de entrada ofensiva
9. Clique em Save rules

Saiba mais sobre os recursos suportados e as definições de análise deste 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 oferecem filtragem com estado do tráfego de rede de entrada e saída para recursos da AWS. Recomendamos que nenhum grupo de segurança permita o acesso de entrada sem restrições a portas de administração de servidores remotos, como SSH à porta 22 e RDP à porta 3389.

Recomendação: certifique-se de que nenhum grupo de segurança permite a entrada de ::/0 para portas de administração do servidor remoto

Faça o seguinte para implementar o estado prescrito:

1. Inicie sessão na AWS Management Console em https://console.aws.amazon.com/vpc/home
2. No painel esquerdo, clique em Security Groups
3. Para cada grupo de segurança, faça o seguinte:
4. Selecione o grupo de segurança
5. Clique no separador Inbound Rules
6. Clique no botão Edit inbound rules
7. Identifique as regras a editar ou remover
8. A) Atualize o campo de origem para um intervalo diferente de ::/0 ou B) clique em Delete para remover a regra de entrada ofensiva
9. Clique em Save rules

Saiba mais sobre os recursos suportados e as definições de análise deste 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 utilizador do IAM ou o utilizador "root" da conta da AWS. Pode usar chaves de acesso para assinar pedidos programáticos para a CLI da AWS ou a API AWS (diretamente ou através do SDK da AWS)

Recomendação: certifique-se de que existe apenas uma chave de acesso ativa disponível para qualquer utilizador do IAM

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

1. Inicie sessão na AWS Management Console e navegue para o painel de controlo do IAM em https://console.aws.amazon.com/iam/.
2. No painel de navegação do lado esquerdo, escolha Users.
3. Clique no nome do utilizador do IAM que quer examinar.
4. Na página de configuração do utilizador do IAM, selecione o separador Security Credentials.
5. Na secção Access Keys, escolha uma chave de acesso com menos de 90 dias. Esta deve ser a única chave ativa usada por este utilizador do IAM para aceder aos recursos da AWS por programação. Teste as suas aplicações para se certificar de que a chave de acesso escolhida está a funcionar.
6. Na mesma secção Access Keys, identifique as chaves de acesso não operacionais (exceto a escolhida) e desative-as clicando no link Make Inactive.
7. Se receber a caixa de confirmação Change Key Status, clique em Deactivate para desativar a chave selecionada.
8. Repita os passos n. º 3 a 7 para cada utilizador do IAM na sua conta da AWS.

AWS CLI

1. Com as informações do utilizador e da chave de acesso do IAM fornecidas no Audit CLI, escolha uma chave de acesso com menos de 90 dias. Esta deve ser a única chave ativa usada por este utilizador do IAM para aceder aos recursos da AWS por programação. Teste as suas aplicações para se certificar de que a chave de acesso escolhida está a funcionar.

2. Execute o comando update-access-key abaixo com o nome de utilizador do IAM e os IDs das chaves de acesso não operacionais para desativar as chaves desnecessárias. Consulte a secção Auditoria para identificar o ID da chave de acesso desnecessário para o utilizador do IAM selecionado

Nota: o comando não devolve qualquer resultado:

aws iam update-access-key --access-key-id <access-key-id> --status Inactive --user-name <user-name>

3. Para confirmar que o par de chaves de acesso selecionado foi executado com êxito, deactivated execute novamente o comando de auditoria list-access-keys para esse utilizador do IAM:

aws iam list-access-keys --user-name <user-name>

• O resultado do comando deve expor os metadados de cada chave de acesso associada ao utilizador do IAM. Se os pares de chaves não operacionais Status estiverem definidos como Inactive, a chave foi desativada com êxito e a configuração de acesso do utilizador do IAM cumpre agora esta recomendação.

4. Repita os passos n. º 1 a 3 para cada utilizador do IAM na sua conta da AWS.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Public Access Given Rds Instance

Nome da categoria na API: PUBLIC_ACCESS_GIVEN_RDS_INSTANCE

Certifique-se e verifique se as instâncias da base de dados RDS aprovisionadas 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 base de dados do RDS acessível publicamente, tem de desativar a flag Publicly Accessible da base de dados e atualizar o grupo de segurança da VPC associado à instância.

Recomendação: certifique-se de que não é concedido acesso público à instância do RDS

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

1. Inicie sessão na consola de gestão da AWS e navegue para o painel de controlo do RDS em https://console.aws.amazon.com/rds/.
2. No painel de navegação, no painel de controlo do RDS, clique em Databases.
3. Selecione a instância do RDS que quer atualizar.
4. Clique em Modify no menu superior do painel de controlo.
5. No painel Modify DB Instance (Modificar instância de BD), na secção Connectivity, clique em Additional connectivity configuration e atualize o valor de Publicly Accessible para Not publicly accessible (Não acessível publicamente) para restringir o acesso público. Siga os passos abaixo para atualizar as configurações da sub-rede:
   - Selecione o separador Connectivity and security e clique no valor do atributo de VPC na secção Networking.
   - Selecione o separador Details no painel inferior do painel de controlo 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 o separador Rotas no painel inferior do painel de controlo e clique em Edit routes.
   - Na página Editar trajetos, atualize o Destino do alvo, que está definido como igw-xxxxx, e clique em Save trajetos.
6. No painel Modify DB Instance (Modificar instância de base de dados), clique em Continue e, na secção Scheduling of modifications (Programação de modificações), execute uma das seguintes ações com base nos seus requisitos:
   - Selecione Apply during the next scheduled maintenance window (Aplicar durante a próxima janela de manutenção agendada) para aplicar as alterações automaticamente durante a próxima janela de manutenção agendada.
   - Selecione Aplicar imediatamente para aplicar as alterações de imediato. Com esta opção, todas as modificações pendentes são aplicadas de forma assíncrona assim que possível, independentemente da definição do período de manutenção para esta instância da base de dados do RDS. Tenha em atenção que as alterações disponíveis na fila de modificações pendentes também são aplicadas. Se alguma das modificações pendentes exigir tempo de inatividade, a escolha desta opção pode causar um tempo de inatividade inesperado para a aplicação.
7. Repita os passos 3 a 6 para cada instância do RDS disponível na região atual.
8. Altere a região da AWS na barra de navegação para repetir o processo para outras regiões.

AWS CLI

1. Execute o comando describe-db-instances para listar todos os identificadores de nomes de bases de dados do RDS disponíveis na região da AWS selecionada:

aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'

2. O resultado do comando deve devolver o identificador de cada instância da base de dados.
3. Execute o comando modify-db-instance para modificar a configuração da instância do RDS selecionada. Em seguida, use o seguinte comando para desativar a flag Publicly Accessible para as instâncias do RDS selecionadas. Este comando usa a flag apply-immediately. Se 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. O resultado do comando deve revelar a configuração PubliclyAccessible nos valores pendentes e deve ser aplicado na hora especificada.
5. A atualização do destino do gateway de Internet através da CLI da AWS não é suportada atualmente. Para atualizar as informações sobre o gateway de Internet, use o procedimento da consola da AWS.
6. Repita os passos 1 a 5 para cada instância do RDS aprovisionada na região atual.
7. Altere a região da AWS usando o filtro --region para repetir o processo para outras regiões.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Rds Enhanced Monitoring Enabled

Nome da categoria na API: RDS_ENHANCED_MONITORING_ENABLED

A monitorização melhorada fornece métricas em tempo real sobre o sistema operativo no qual a instância do RDS é executada, através de um agente instalado na instância.

Para mais detalhes, consulte o artigo Monitorização de métricas do SO com a monitorização melhorada.

Recomendação: verifica se a monitorização melhorada está ativada para todas as instâncias de base de dados do RDS

Para corrigir esta deteção, conclua os seguintes passos:

Terraform

Para corrigir este controlo, ative a monitorização melhorada nas suas instâncias do RDS da seguinte forma:

Crie uma função 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"
        }
      },
    ]
  })
}

Obtenha a política gerida da AWS para a monitorização melhorada do RDS:

data "aws_iam_policy" "rds_logging" {
  name = "AmazonRDSEnhancedMonitoringRole"
}

Anexe a política à função:

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 monitorização e um ARN de função de monitorização para a instância do RDS em violação para ativar a monitorização melhorada:

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
}

Consola AWS

Pode ativar a monitorização melhorada quando cria uma instância de base de dados, um cluster de base de dados multi-AZ ou uma réplica de leitura, ou quando modifica uma instância de base de dados ou um cluster de base de dados multi-AZ. Se modificar uma instância de base de dados para ativar a monitorização melhorada, não tem de reiniciar a instância de base de dados para que a alteração seja aplicada.

Pode ativar a monitorização melhorada na consola do RDS quando realizar uma das seguintes ações na página Bases de dados:

• Crie uma instância de BD ou um cluster de BD multi-AZ: escolha Criar base de dados.
• Crie uma réplica de leitura: escolha Ações e, de seguida, Criar réplica de leitura.
• Modificar uma instância de base de dados ou um cluster de base de dados multi-AZ: escolha Modificar.

Para ativar ou desativar a monitorização melhorada na consola do RDS

1. Desloque a página até Configuração adicional.
2. Em Monitorização, escolha Ativar monitorização melhorada para a sua instância de base de dados ou réplica de leitura. Para desativar a monitorização melhorada, escolha Desativar monitorização melhorada.
3. Defina a propriedade Monitoring Role para a função do IAM que criou para permitir que o Amazon RDS comunique com o Amazon CloudWatch Logs por si ou escolha Default para que o RDS crie uma função para si denominada rds-monitoring-role.
4. Defina a propriedade Granularity para o intervalo, em segundos, entre pontos quando as métricas são recolhidas para a sua instância de base de dados ou réplica de leitura. A propriedade Granularity pode ser definida para um dos seguintes valores: 1, 5, 10, 15, 30 ou 60. A velocidade de atualização mais rápida da consola do RDS é de 5 segundos. Se definir a granularidade para 1 segundo na consola do RDS, continua a ver as métricas atualizadas apenas a cada 5 segundos. Pode obter atualizações de métricas de 1 segundo através dos registos do CloudWatch.

AWS CLI

Crie a função IAM do RDS:

aws iam create-role \
  --role-name "CustomRoleForRDSMonitoring" \
  --assume-role-policy-document file://rds-assume-role.json

Anexe a política AmazonRDSEnhancedMonitoringRole à função:

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 a monitorização melhorada, 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 suportados e as definições de análise deste tipo de descoberta.

Rds Instance Deletion Protection Enabled

Nome da categoria na API: RDS_INSTANCE_DELETION_PROTECTION_ENABLED

A ativação da proteção contra eliminação de instâncias é uma camada adicional de proteção contra a eliminação acidental de bases de dados ou a eliminação por uma entidade não autorizada.

Quando a proteção contra eliminação está ativada, não é possível eliminar uma instância de base de dados do RDS. Antes de um pedido de eliminação ser bem-sucedido, a proteção contra eliminação tem de ser desativada.

Recomendação: verifica se todas as instâncias do RDS têm a proteção contra eliminação ativada

Para corrigir esta deteção, conclua os seguintes passos:

Terraform

Para corrigir este controlo, defina deletion_protection como true no recurso aws_db_instance.

resource "aws_db_instance" "example" {
  # ... other configuration ...
  deletion_protection = true
}

Consola AWS

Para ativar a proteção contra eliminação para uma instância de base de dados do RDS

1. Abra a consola do Amazon RDS em https://console.aws.amazon.com/rds/.
2. No painel de navegação, escolha Bases de dados e, de seguida, escolha a instância de BD que quer modificar.
3. Escolha Modificar.
4. Em Proteção contra eliminação, escolha Ativar proteção contra eliminação.
5. Escolha Continuar.
6. Em Agendamento de modificações, escolha quando aplicar as modificações. As opções são Aplicar durante o próximo período de manutenção agendado ou Aplicar imediatamente.
7. Escolha Modify DB Instance (Modificar instância de base de dados).

AWS CLI

O mesmo se aplica à CLI da AWS. Defina --deletion-protection como abaixo.

aws rds modify-db-instance \
  --db-instance-identifier = "test-rds" \
  --deletion-protection

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Rds In Backup Plan

Nome da categoria na API: RDS_IN_BACKUP_PLAN

Esta verificação avalia se as instâncias de base de dados do Amazon RDS estão abrangidas por um plano de cópia de segurança. Este controlo falha se uma instância de base de dados do RDS não estiver coberta por um plano de cópia de segurança.

O AWS Backup é um serviço de cópia de segurança totalmente gerido que centraliza e automatiza a criação de cópias de segurança de dados nos serviços AWS. Com o AWS Backup, pode criar políticas de cópia de segurança denominadas planos de cópia de segurança. Pode usar estes planos para definir os seus requisitos de cópia de segurança, como a frequência com que quer fazer uma cópia de segurança dos seus dados e durante quanto tempo quer reter essas cópias de segurança. A inclusão de instâncias de base de dados do RDS num plano de cópia de segurança ajuda a proteger os seus dados contra perdas ou eliminações não intencionais.

Recomendação: as instâncias de base de dados do RDS devem ser abrangidas por um plano de cópia de segurança

Para corrigir esta deteção, conclua os seguintes passos:

Terraform

Para corrigir este controlo, defina o backup_retention_period para um valor superior a 7 no recurso aws_db_instance.

resource "aws_db_instance" "example" {
  # ... other Configuration ...
  backup_retention_period = 7
}

Consola AWS

Para ativar as cópias de segurança automáticas imediatamente

1. Abra a consola do Amazon RDS em https://console.aws.amazon.com/rds/.
2. No painel de navegação, escolha Bases de dados e, de seguida, escolha a instância de BD que quer modificar.
3. Escolha Modify para abrir a página Modify DB Instance.
4. Em Período de retenção da cópia de segurança, escolha um valor positivo diferente de zero, por exemplo, 30 dias, e, de seguida, escolha Continuar.
5. Selecione a secção Agendamento de modificações e escolha quando aplicar as modificações: pode optar por Aplicar durante o próximo período de manutenção agendado ou Aplicar imediatamente.
6. Em seguida, na página de confirmação, escolha Modificar instância de BD para guardar as alterações e ativar as cópias de segurança automáticas.

AWS CLI

O mesmo se aplica à CLI da AWS. Para ativar as cópias de segurança automáticas, altere o valor de backup-retention-period para um valor superior a 0 (predefinição).

aws rds modify-db-instance --db-instance-identifier "test-rds" --backup-retention-period 7

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Rds Logging Enabled

Nome da categoria na API: RDS_LOGGING_ENABLED

Esta verificação determina se os seguintes registos do Amazon RDS estão ativados e são enviados para o CloudWatch.

As bases de dados RDS devem ter os registos relevantes ativados. O registo da base de dados fornece registos detalhados dos pedidos feitos ao RDS. Os registos da base de dados podem ajudar nas auditorias de segurança e acesso, bem como no diagnóstico de problemas de disponibilidade.

Recomendação: verifica se os registos exportados estão ativados para todas as instâncias de base de dados do RDS

Para corrigir esta deteção, conclua os seguintes passos:

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"
  }
}

Para o MariaDB, crie também 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"
    }
  }
}

Consola AWS

Para criar um grupo de parâmetros de BD personalizado

1. Abra a consola 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 de famílias de grupos de parâmetros, escolha uma família de grupos de parâmetros de BD.
5. Na lista de tipos, escolha Grupo de parâmetros de BD.
6. Em Nome do grupo, introduza o nome do novo grupo de parâmetros da base de dados.
7. Em Descrição, introduza uma descrição para o novo grupo de parâmetros da base de dados.
8. Escolha Criar.

Para criar um novo grupo de opções para o registo do MariaDB através da consola

1. Abra a consola 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 do grupo de opções de criação, indique o seguinte:
   * Nome: tem de ser exclusivo na sua conta da AWS. Apenas letras, dígitos e hífenes.
   * Descrição: usado apenas para fins de apresentação.
   * Motor: selecione o motor de BD.
   * Versão principal do motor: selecione a versão principal do seu motor de BD.
5. Escolha Criar.
6. Escolha o nome do grupo de opções que 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 e QUERY_DCL.
10. Escolha a opção Adicionar.

Para publicar registos de SQL Server DB, Oracle DB ou PostgreSQL no CloudWatch Logs a partir da AWS Management Console

1. Abra a consola do Amazon RDS em https://console.aws.amazon.com/rds/.
2. No painel de navegação, escolha Bases de dados.
3. Escolha a instância de BD que quer modificar.
4. Escolha Modificar.
5. Em Exportações de registos, escolha todos os ficheiros de registo para começar a publicar no CloudWatch Logs.
6. A exportação de registos só está disponível para versões do motor de base de dados que suportam a publicação nos registos do CloudWatch.
7. Escolha Continuar. Em seguida, na página de resumo, escolha Modificar instância de BD.

Para aplicar um novo grupo de parâmetros de BD ou um grupo de opções de BD a uma instância de BD do RDS

1. Abra a consola do Amazon RDS em https://console.aws.amazon.com/rds/.
2. No painel de navegação, escolha Bases de dados.
3. Escolha a instância de BD que quer modificar.
4. Escolha Modificar.
5. Em Opções da base de dados, altere o grupo de parâmetros da base de dados e o grupo de opções da base de dados, conforme necessário.
6. Quando terminar as alterações, escolha Continuar. Verifique o resumo das modificações.
7. Escolha Modify DB Instance para guardar as alterações.

AWS CLI

Recupere as famílias de motores e escolha a que corresponde ao motor e à versão da instância da base de dados.

aws rds describe-db-engine-versions \
  --query "DBEngineVersions[].DBParameterGroupFamily" \
  --engine "mysql"

Crie um grupo de parâmetros de acordo com o motor 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 ficheiro rds-parameters.json com os parâmetros necessários de acordo com o motor de BD. Este exemplo usa 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 motor de BD. 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 da base 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 forma.

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 ficheiro rds-mariadb-options.json da seguinte forma.

{
  "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 de opções.

aws rds add-option-to-option-group \
  --option-group-name "rds-mariadb-option-group" \
  --options file://rds-mariadb-options.json

Associe o grupo de opções à instância de BD modificando a instância do MariaDB.

aws rds modify-db-instance \
  --db-instance-identifier "rds-test-mariadb" \
  --option-group-name "rds-mariadb-option-group"

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Rds Multi Az Support

Nome da categoria na API: RDS_MULTI_AZ_SUPPORT

As instâncias de base de dados do RDS devem ser configuradas para várias zonas de disponibilidade (AZs). Isto garante a disponibilidade dos dados armazenados. As implementações multi-AZ permitem a comutação por falha automática 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 está ativada para todas as instâncias de base de dados do RDS

Para corrigir esta deteção, conclua os seguintes passos:

Terraform

Para corrigir este controlo, defina multi_az como verdadeiro no recurso aws_db_instance.

resource "aws_db_instance" "example" {
  # ... other configuration ...
  multi_az                = true
}

Consola AWS

Para ativar várias zonas de disponibilidade para uma instância de base de dados

1. Abra a consola do Amazon RDS em https://console.aws.amazon.com/rds/.
2. No painel de navegação, escolha Bases de dados e, de seguida, escolha a instância de BD que quer modificar.
3. Escolha Modificar. É apresentada a página Modificar instância de BD.
4. Em Instance Specifications, defina Multi-AZ deployment como Yes.
5. Escolha Continuar e, em seguida, verifique o resumo das modificações.
6. (Opcional) Escolha Aplicar imediatamente para aplicar as alterações imediatamente. A escolha desta opção pode causar uma indisponibilidade em alguns casos. Para mais informações, consulte o artigo Usar a definição Aplicar imediatamente no guia do utilizador do Amazon RDS.
7. Na página de confirmação, reveja as alterações. Se estiverem corretas, escolha Modify DB Instance para guardar as alterações.

AWS CLI

O mesmo se aplica à CLI da AWS. Ative o suporte de várias AZs fornecendo a opção --multi-az.

modify-db-instance
  --db-instance-identifier "test-rds" \
  --multi-az

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Redshift Cluster Configuration Check

Nome da categoria na API: REDSHIFT_CLUSTER_CONFIGURATION_CHECK

Esta verificação procura elementos essenciais de um cluster do Redshift: encriptação em repouso, registo e tipo de nó.

Estes itens de configuração são importantes na manutenção de um cluster do Redshift seguro e observável.

Recomendação: verifica se todos os clusters do Redshift têm encriptação em repouso, registo e tipo de nó.

Para corrigir esta deteção, conclua os seguintes passos:

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"]
  }
}

Consola AWS

Para ativar o registo de auditoria do cluster

1. Abra a consola do Amazon Redshift em https://console.aws.amazon.com/redshift/.
2. No menu de navegação, escolha Clusters e, de seguida, o nome do cluster a modificar.
3. Escolha Propriedades.
4. Escolha Editar e Editar registo de auditoria.
5. Defina a opção Configurar registo de auditoria como Ativar, defina o tipo de exportação de registos como CloudWatch (recomendado) e escolha os registos a exportar.

Para usar o AWS S3 para gerir os registos de auditoria do Redshift, consulte o artigo Redshift – Registo de auditoria da base de dados na documentação da AWS.

6. Escolha Guardar alterações.

Para modificar a encriptação da base de dados num cluster

1. Inicie sessão na AWS Management Console e abra a consola do Amazon Redshift em https://console.aws.amazon.com/redshift/.
2. No menu de navegação, escolha Clusters e, de seguida, escolha o cluster para o qual quer modificar a encriptação.
3. Escolha Propriedades.
4. Escolha Editar e Editar encriptação.
5. Escolha a encriptação a usar (KMS ou HSM) e indique:

• Para o KMS: chave a usar
• Para HSM: certificado de cliente e ligação

AWS CLI

1. Crie uma chave do KMS e obtenha o ID da chave

aws kms create-key \
  --description "Key to encrypt Redshift Clusters"

2. Modifique o cluster

aws redshift modify-cluster \
  --cluster-identifiers "test-redshift-cluster" \
  --encrypted \
  --kms-key-id <value>

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Redshift Cluster Maintenancesettings Check

Nome da categoria na API: REDSHIFT_CLUSTER_MAINTENANCESETTINGS_CHECK

As atualizações automáticas de versões principais ocorrem de acordo com o período de manutenção

Recomendação: verifica se todos os clusters do Redshift têm allowVersionUpgrade ativado e preferredMaintenanceWindow e automatedSnapshotRetentionPeriod definidos

Para corrigir esta deteção, conclua os seguintes passos:

Terraform

Esta verificação está em conformidade com todos os valores predefinidos fornecidos pelo Terraform. No caso de um cluster do Redshift com falhas, reveja os requisitos e remova as substituições predefinidas 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
}

Consola AWS

Quando cria um cluster do Redshift através da consola da AWS, os valores predefinidos já estão em conformidade com este controlo.

Para mais informações, consulte o artigo Gerir clusters através da consola

AWS CLI

Para corrigir este controlo através da CLI da AWS, faça o seguinte:

aws redshift modify-cluster \
  --cluster-identifier "test-redshift-cluster" \
  --allow-version-upgrade

Saiba mais sobre os recursos suportados e as definições de análise deste 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 está configurado com PubliclyAccessible definido como verdadeiro, é uma instância virada para a Internet que tem um nome DNS resolvível publicamente, que é resolvido para um endereço IP público.

Quando o cluster não está acessível publicamente, é uma instância interna com um nome DNS que é resolvido para um endereço IP privado. A menos que pretenda que o cluster esteja acessível publicamente, não deve configurá-lo com PubliclyAccessible definido como verdadeiro.

Recomendação: verifica se os clusters do Redshift são acessíveis publicamente

Para corrigir esta deteção, conclua os seguintes passos:

Terraform

Para corrigir este controlo, é necessário modificar o recurso do cluster do Redshift e definir publicly_accessible como false. O valor predefinido é true.

resource "aws_redshift_cluster" "example" {
  # ... other configuration ...
  publicly_accessible = false
}

Consola AWS

Para desativar o acesso público a um cluster do Amazon Redshift

1. Abra a consola do Amazon Redshift em https://console.aws.amazon.com/redshift/.
2. No menu de navegação, escolha Clusters e, de seguida, o nome do cluster com o grupo de segurança a modificar.
3. Escolha Ações e, de seguida, Modificar definição acessível publicamente.
4. Em Permitir que instâncias e dispositivos fora da VPC se liguem à sua base de dados através do ponto final do cluster, escolha Não.
5. Escolha Confirmar.

AWS CLI

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 suportados e as definições de análise deste tipo de descoberta.

Restricted Common Ports

Nome da categoria na API: RESTRICTED_COMMON_PORTS

Esta verificação determina se o tráfego de entrada não restrito para os grupos de segurança está acessível às portas especificadas que têm o risco mais elevado. Este controlo falha se alguma das regras num grupo de segurança permitir tráfego de entrada de "0.0.0.0/0" ou "::/0" para essas portas.

O acesso sem restrições (0.0.0.0/0) aumenta as oportunidades de atividade maliciosa, como pirataria, ataques de negação de serviço e perda de dados.

Os grupos de segurança oferecem filtragem com estado do tráfego de rede de entrada e saída para recursos da AWS. Nenhum grupo de segurança deve permitir o acesso de entrada sem restrições às seguintes portas:

• 20 e 21 (FTP)
• 22 (SSH)
• 23 (Telnet)
• 25 (SMTP)
• 110 (POP3)
• 135 (RPC)
• 143 (IMAP)
• 445 (CIFS)
• 1433, 1434 (MSSQL)
• 3000 (estruturas de desenvolvimento Web Go, Node.js e Ruby)
• 3306 (mySQL)
• 3389 (RDP)
• 4333 (ahsp)
• 5000 (estruturas de desenvolvimento Web Python)
• 5432 (postgresql)
• 5500 (fcp-addr-srvr1)
• 5601 (OpenSearch Dashboards)
• 8080 (proxy)
• 8088 (porta HTTP antiga)
• 8888 (porta HTTP alternativa)
• 9200 ou 9300 (OpenSearch)

Recomendação: os grupos de segurança não devem permitir o acesso sem restrições a portas com alto risco

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

Para eliminar uma regra de grupo de segurança:

1. Abra a consola 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 atualizar, escolha Ações e, de seguida, escolha Editar regras de entrada para remover uma regra de entrada ou Editar regras de saída para remover uma regra de saída.
4. Escolha o botão Eliminar à direita da regra que quer eliminar.
5. Escolha Pré-visualizar alterações, Confirmar.

Para ver informações sobre como eliminar regras de um grupo de segurança, consulte o artigo Configure regras de grupos de segurança no guia do utilizador do Amazon EC2.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Restricted Ssh

Nome da categoria na API: RESTRICTED_SSH

Os grupos de segurança oferecem filtragem com estado do tráfego de rede de entrada e saída para recursos da AWS.

O CIS recomenda que nenhum grupo de segurança permita o acesso de entrada sem restrições à porta 22. A remoção da conetividade sem restrições aos serviços de consola remota, como o SSH, reduz a exposição de um servidor ao risco.

Recomendação: os grupos de segurança não devem permitir a entrada de 0.0.0.0/0 na porta 22

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

Execute os seguintes passos para cada grupo de segurança associado a uma VPC.

Abra a consola do Amazon VPC em https://console.aws.amazon.com/vpc/.

1. No painel esquerdo, escolha Grupos de segurança.
2. Selecione um grupo de segurança.
3. Na secção inferior da página, escolha o separador Regras de entrada.
4. Escolha Editar regras.
5. Identifique a regra que permite o acesso através da porta 22 e, de seguida, escolha o X para a remover.
6. Escolha Guardar regras.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 da chave do AWS KMS criada pelo cliente. A regra é NON_COMPLIANT se a função do registador do AWS Config para um recurso não tiver a autorização kms:DescribeKey.

Recomendação: certifique-se de que a rotação das CMKs criadas pelo cliente está ativada

Para ativar a rotação automática de chaves para o AWS KMS, consulte o artigo Rotação de chaves do AWS KMS na documentação da AWS.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 alternem a chave de apoio, que é o material da chave armazenado no KMS associado ao ID da chave principal do cliente (CMK) criada pelo cliente. É a chave de apoio usada para realizar operações criptográficas, como encriptação e desencriptação. Atualmente, a rotação automática de chaves retém todas as chaves de apoio anteriores para que a desencriptação dos dados encriptados possa ocorrer de forma transparente. Recomendamos que a rotação de chaves CMK esteja ativada para chaves simétricas. Não é possível ativar a rotação de chaves para nenhuma CMK assimétrica.

Recomendação: certifique-se de que a rotação das CMKs simétricas criadas pelo cliente está ativada

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

1. Inicie sessão na consola de gestão da AWS e abra a consola do IAM em https://console.aws.amazon.com/iam.
2. No painel de navegação do lado esquerdo, escolha Customer managed keys .
3. Selecione uma CMK gerida pelo cliente onde Key spec = SYMMETRIC_DEFAULT
4. Abaixo do painel "Configuração geral", abra o separador "Rotação de chaves"
5. Selecione a caixa de verificação "Alternar automaticamente esta chave do KMS todos os anos".

AWS CLI

1. Execute o seguinte comando para ativar a rotação de chaves:

 aws kms enable-key-rotation --key-id <kms_key_id>

Saiba mais sobre os recursos suportados e as definições de análise deste 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 rotas para a interligação de VPCs estão configuradas com o princípio do menor privilégio.

Recomendação: certifique-se de que as tabelas de encaminhamento para a interligação de VPCs são de "acesso mínimo"

Para atualizar as tabelas de rotas para a interligação de VPCs, consulte o artigo Atualize as tabelas de rotas para uma ligação de interligação de VPCs no manual do utilizador da VPC da AWS.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

S3 Account Level Public Access Blocks

Nome da categoria na API: S3_ACCOUNT_LEVEL_PUBLIC_ACCESS_BLOCKS

O Bloqueio de acesso público do Amazon S3 oferece definições para pontos de acesso, contentores e contas para ajudar a gerir o acesso público aos recursos do Amazon S3. Por predefinição, os novos contentores, pontos de acesso e objetos não permitem o acesso público.

Recomendação: verifica se as definições de bloqueio de acesso público do S3 necessárias estão configuradas ao nível da conta

Para corrigir esta deteção, conclua os seguintes passos:

Terraform

O seguinte recurso do Terraform configura o acesso ao nível da conta ao S3.

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
}

Consola AWS

Para editar as definições de acesso público de bloqueio de todos os contentores S3 numa conta da AWS.

1. Inicie sessão na AWS Management Console e abra a consola do Amazon S3 em https://console.aws.amazon.com/s3/.
2. Escolha as definições de acesso público bloqueado para esta conta.
3. Escolha Editar para alterar as definições de bloqueio do acesso público para todos os contentores na sua conta da AWS.
4. Escolha as definições que quer alterar e, de seguida, escolha Guardar alterações.
5. Quando lhe for pedida uma confirmação, introduza confirm. Em seguida, escolha Confirmar para guardar as alterações.

AWS CLI

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 suportados e as definições de análise deste 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 fornece Block public access (bucket settings) e Block public access (account settings) para ajudar a gerir o acesso público aos recursos do Amazon S3. Por predefinição, os contentores e os objetos do S3 são criados com o acesso público desativado. No entanto, um principal do IAM da AWS com autorizações do S3 suficientes pode ativar o acesso público ao nível do contentor ou do objeto. Quando ativado, o Block public access (bucket settings) impede que um contentor individual e os respetivos objetos contidos se tornem acessíveis publicamente. Da mesma forma, Block public access (account settings) impede que todos os contentores e objetos contidos se tornem acessíveis publicamente em toda a conta.

Recomendação:

Certifique-se de que os contentores do S3 estão configurados com Block public access (bucket settings).

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

Se o resultado for verdadeiro para as definições de configuração separadas, significa que estão definidas na conta.

1. Inicie sessão na consola de gestão da AWS e abra a consola do Amazon S3 através de https://console.aws.amazon.com/s3/
2. Escolha Bloquear acesso público (definições da conta)
3. Escolha Editar para alterar as definições de acesso público de todos os contentores na sua conta da AWS
4. Escolha as definições que quer alterar e, de seguida, escolha Guardar. Para ver detalhes sobre cada definição, pause o cursor do rato sobre os ícones i.
5. Quando lhe for pedida a confirmação, introduza confirmar. Em seguida, clique em Confirmar para guardar as alterações.

AWS CLI

Para definir as definições de acesso público de bloqueio para esta 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 suportados e as definições de análise deste tipo de descoberta.

S3 Bucket Access Logging Enabled Cloudtrail S3 Bucket

Nome da categoria na API: S3_BUCKET_ACCESS_LOGGING_ENABLED_CLOUDTRAIL_S3_BUCKET

O registo de acesso ao contentor do S3 gera um registo que contém registos de acesso para cada pedido feito ao seu contentor do S3. Um registo do registo de acesso contém detalhes sobre o pedido, como o tipo de pedido, os recursos especificados no pedido que funcionaram e a hora e a data em que o pedido foi processado. Recomendamos que o registo de acesso ao contentor esteja ativado no contentor do S3 do CloudTrail.

Recomendação:

Certifique-se de que o registo de acesso ao contentor do S3 está ativado no contentor do S3 do CloudTrail

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

1. Inicie sessão na AWS Management Console e abra a consola do S3 em https://console.aws.amazon.com/s3.
2. Em Todos os contentores, clique no contentor S3 de destino
3. Clique em Propriedades na parte superior direita da consola
4. Em Bucket: <s3\_bucket\_for\_cloudtrail>, clique em Logging</s3\_bucket\_for\_cloudtrail>
5. Configurar o registo de contentores
   - Clique na caixa de verificação Ativado
   - Selecione o contentor de destino na lista
   - Introduza um prefixo de destino
6. Clique em Guardar.

AWS CLI

1. Obtenha o nome do contentor do S3 para o qual o CloudTrail está a registar:

aws cloudtrail describe-trails --region <region-name> --query trailList[*].S3BucketName

2. Copie e adicione o nome do contentor de destino em , o prefixo do ficheiro de registo em e, opcionalmente, adicione um endereço de email no seguinte modelo e guarde-o 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 contentor 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 suportados e as definições de análise deste tipo de descoberta.

S3 Bucket Logging Enabled

Nome da categoria na API: S3_BUCKET_LOGGING_ENABLED

A funcionalidade de registo de acesso ao servidor do AWS S3 regista pedidos de acesso a contentores de armazenamento, o que é útil para auditorias de segurança. Por predefinição, o registo de acesso ao servidor não está ativado para os contentores S3.

Recomendação: verifica se o registo está ativado em todos os contentores do S3

Para corrigir esta deteção, conclua os seguintes passos:

Terraform

O exemplo seguinte demonstra como criar 2 contentores:

1. Um contentor de registo
2. Um contentor 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"
    }
  }
}

Consola AWS

Para obter informações sobre como ativar o registo de acesso do S3 através da consola da AWS, consulte o artigo Ativar o registo de acesso do servidor do Amazon S3 na documentação da AWS.

AWS CLI

O exemplo seguinte demonstra como:

1. Crie uma política de contentor para conceder ao principal do serviço de registo autorização para PutObject no seu contentor de registo.

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. Aplique a política ao seu contentor de registo

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 suportados e as definições de análise deste tipo de descoberta.

S3 Bucket Policy Set Deny Http Requests

Nome da categoria na API: S3_BUCKET_POLICY_SET_DENY_HTTP_REQUESTS

Ao nível do contentor do Amazon S3, pode configurar autorizações através de uma política de contentor que torna os objetos acessíveis apenas através de HTTPS.

Recomendação: certifique-se de que a política do contentor do S3 está definida para recusar pedidos HTTP

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

Usando o gerador de políticas da AWS:

1. Repita os passos 1 a 4 acima.
2. Clique em Policy Generator na parte inferior do editor de políticas de contentores
3. Selecione o tipo de política
   S3 Bucket Policy
4. Adicione declarações
   - Effect = Deny
   - Principal = *
   - AWS Service = Amazon S3
   - Actions = *
   - Amazon Resource Name =
5. Gerar política
6. Copie o texto e adicione-o à política de contentores.

AWS CLI

1. Exporte a política do contentor para um ficheiro JSON.

aws s3api get-bucket-policy --bucket <bucket_name> --query Policy --output text > policy.json

2. Modifique o ficheiro policy.json adicionando esta declaraçã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 novamente ao contentor do S3:

aws s3api put-bucket-policy --bucket <bucket_name> --policy file://policy.json

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

S3 Bucket Replication Enabled

Nome da categoria na API: S3_BUCKET_REPLICATION_ENABLED

Este controlo verifica se um contentor do Amazon S3 tem a replicação entre regiões ativada. O controlo falha se o contentor 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 contentores nas regiões da AWS iguais ou diferentes. A replicação copia objetos recém-criados e atualizações de objetos de um contentor de origem para um ou mais contentores de destino. As práticas recomendadas da AWS recomendam a replicação para contentores de origem e destino que sejam propriedade da mesma conta da AWS. Além da disponibilidade, deve considerar outras definições de reforço de sistemas.

Recomendação: verifica se os contentores do S3 têm a replicação entre regiões ativada

Para ativar a replicação entre regiões num contentor do S3, consulte o artigo Configurar a replicação para contentores de origem e de destino pertencentes à mesma conta no guia do utilizador do Amazon Simple Storage Service. Para o contentor de origem, escolha Aplicar a todos os objetos no contentor.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

S3 Bucket Server Side Encryption Enabled

Nome da categoria na API: S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED

Esta verificação garante que o seu contentor do S3 tem a encriptação predefinida do Amazon S3 ativada ou que a política do contentor do S3 nega explicitamente os pedidos put-object sem encriptação do lado do servidor.

Recomendação: certifique-se de que todos os contentores S3 usam a encriptação em repouso

Para corrigir esta deteção, conclua os seguintes passos:

Terraform

resource "aws_s3_bucket_server_side_encryption_configuration" "enable" {
  bucket = "my-bucket"

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

Consola AWS

Para ativar a encriptação predefinida num contentor do S3

1. Abra a consola do Amazon S3 em https://console.aws.amazon.com/s3/.
2. No painel de navegação do lado esquerdo, escolha Contentores.
3. Escolha o contentor do S3 na lista.
4. Escolha Propriedades.
5. Escolha Encriptação predefinida.
6. Para a encriptação, escolha AES-256 ou AWS-KMS.
7. Escolha AES-256 para usar chaves geridas pelo Amazon S3 para a encriptação predefinida. Para mais informações sobre a utilização da encriptação do lado do servidor do Amazon S3 para encriptar os seus dados, consulte o guia do utilizador do Amazon Simple Storage Service.
8. Escolha AWS-KMS para usar chaves geridas pelo AWS KMS para a encriptação predefinida. Em seguida, escolha uma chave principal na lista de chaves principais do AWS KMS que criou.
9. Introduza o nome de recurso da Amazon (ARN) da chave do AWS KMS a usar. Pode encontrar o ARN da sua chave do AWS KMS na consola do IAM, em Chaves de encriptação. Em alternativa, pode escolher um nome de chave na lista pendente.
10. Importante: se usar a opção do AWS KMS para a configuração de encriptação predefinida, está sujeito às quotas de RPS (pedidos por segundo) do AWS KMS. Para mais informações sobre as quotas do AWS KMS e como pedir um aumento da quota, consulte o guia para programadores do AWS Key Management Service.
11. Selecione Guardar.

Para mais informações sobre como criar uma chave do AWS KMS, consulte o guia para programadores do AWS Key Management Service.

Para mais informações sobre a utilização do AWS KMS com o Amazon S3, consulte o guia do utilizador do Amazon Simple Storage Service.

Quando ativa a encriptação predefinida, pode ter de atualizar a política do contentor. Para mais informações sobre a mudança das políticas de contentores para a encriptação predefinida, consulte o guia do utilizador do Amazon Simple Storage Service.

AWS CLI

aws s3api put-bucket-encryption \
  --bucket my-bucket \
  --server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "AES256"}}]}'

Saiba mais sobre os recursos suportados e as definições de análise deste 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 contentor e pode ajudar a recuperar mais facilmente de ações não intencionais do utilizador e falhas da aplicação.

Recomendação: verifica se o controlo de versões está ativado para todos os contentores do S3

Para corrigir esta deteção, conclua os seguintes passos:

Terraform

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-bucket"

  versioning {
    enabled = true
  }
}

Consola AWS

Para ativar ou desativar o controlo de versões num contentor do S3

1. Inicie sessão na AWS Management Console e abra a consola do Amazon S3 em https://console.aws.amazon.com/s3/.
2. Na lista Buckets, escolha o nome do contentor para o qual quer ativar o controlo de versões.
3. Escolha Propriedades.
4. Em Controlo de versões do contentor, escolha Editar.
5. Escolha Suspender ou Ativar e, de seguida, escolha Guardar alterações.

AWS CLI

aws s3control put-bucket-versioning \
--bucket <bucket_name> \
--versioning-configuration Status=Enabled

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

S3 Default Encryption Kms

Nome da categoria na API: S3_DEFAULT_ENCRYPTION_KMS

Verifica se os contentores do Amazon S3 estão encriptados com o AWS Key Management Service (AWS KMS)

Recomendação: verifica se todos os contentores estão encriptados com o KMS

Para corrigir esta deteção, conclua os seguintes passos:

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"
    }
  }
}

Consola AWS

Para ativar a encriptação predefinida num contentor do S3

1. Abra a consola do Amazon S3 em https://console.aws.amazon.com/s3/.
2. No painel de navegação do lado esquerdo, escolha Contentores.
3. Escolha o contentor do S3 na lista.
4. Escolha Propriedades.
5. Escolha Encriptação predefinida.
6. Para a encriptação, escolha AWS-KMS.
7. Escolha AWS-KMS para usar chaves geridas pelo AWS KMS para a encriptação predefinida. Em seguida, escolha uma chave principal na lista de chaves principais do AWS KMS que criou. Para mais informações sobre como criar chaves do KMS, consulte a documentação da AWS – Criar chaves
8. Introduza o nome de recurso da Amazon (ARN) da chave do AWS KMS a usar. Pode encontrar o ARN da sua chave do AWS KMS na consola do IAM, em Chaves de encriptação. Em alternativa, pode escolher um nome de chave na lista pendente.
9. Importante: esta solução está sujeita às quotas de RPS (pedidos por segundo) do AWS KMS. Para mais informações sobre as quotas do AWS KMS e como pedir um aumento da quota, consulte o guia para programadores do AWS Key Management Service.
10. Selecione Guardar.

Para mais informações sobre a utilização do AWS KMS com o Amazon S3, consulte o guia do utilizador do Amazon Simple Storage Service.

Quando ativa a encriptação predefinida, pode ter de atualizar a política do contentor. Para mais informações sobre a mudança das políticas de contentores para a encriptação predefinida, consulte o guia do utilizador do Amazon Simple Storage Service.

AWS CLI

Crie uma chave do KMS

aws kms create-key \
  --description "Key to encrypt S3 buckets"

Ative a rotação de chaves

aws kms enable-key-rotation \
  --key-id <key_id_from_previous_command>

Atualizar contentor

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 suportados e as definições de análise deste 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 AWS Key Management Service (AWS KMS) está configurada para uma instância do bloco de notas do Amazon SageMaker. A regra é NON_COMPLIANT se "KmsKeyId" não for especificado para a instância do bloco de notas do SageMaker.

Recomendação: verifica se todas as instâncias de blocos de notas do SageMaker estão configuradas para usar o KMS

Para configurar o KMS para o SageMaker, consulte o artigo Gestão de chaves na documentação do Amazon SageMaker.

Saiba mais sobre os recursos suportados e as definições de análise deste 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 do bloco de notas do SageMaker. Para tal, verifica se o campo DirectInternetAccess está desativado para a instância do bloco de notas.

Se configurar a sua instância do SageMaker sem uma VPC, o acesso direto à Internet é ativado por predefinição na sua instância. Deve configurar a sua instância com uma VPC e alterar a predefinição para Desativar: aceda à Internet através de uma VPC.

Para preparar ou alojar modelos a partir de um notebook, precisa de acesso à Internet. Para ativar o acesso à Internet, certifique-se de que a sua VPC tem um gateway NAT e que o seu grupo de segurança permite ligações de saída. Para saber como associar uma instância de bloco de notas a recursos numa VPC, consulte o artigo Associar uma instância de bloco de notas a recursos numa VPC no guia do programador do Amazon SageMaker.

Também deve garantir que o acesso à configuração do SageMaker está limitado apenas a utilizadores autorizados. Restrinja as autorizações IAM dos utilizadores para modificar as definições e os recursos do SageMaker.

Recomendação: verifica se o acesso direto à Internet está desativado para todas as instâncias de blocos de notas do Amazon SageMaker

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

Tenha em atenção que não pode alterar a definição de acesso à Internet depois de criar uma instância do bloco de notas. Tem de ser parado, eliminado e recriado.

Para configurar uma instância de bloco de notas do SageMaker para recusar o acesso direto à Internet:

1. Abra a consola do SageMaker em https://console.aws.amazon.com/sagemaker/
2. Navegue para Instâncias de blocos de notas.
3. Elimine a instância que tem o acesso direto à Internet ativado. Escolha a instância, escolha Ações e, de seguida, escolha Parar.
4. Depois de parar a instância, escolha Ações e, em seguida, Eliminar.
5. Escolha Criar instância de notebook. Indique os detalhes da configuração.
6. Expanda a secção de rede e, de seguida, escolha uma VPC, uma sub-rede e um grupo de segurança. Em Acesso direto à Internet, escolha Desativar: aceda à Internet através de uma VPC.
7. Escolha Criar instância de notebook.

Para mais informações, consulte o artigo Ligue uma instância de bloco de notas a recursos numa VPC no guia do programador do Amazon SageMaker.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Secretsmanager Rotation Enabled Check

Nome da categoria na API: SECRETSMANAGER_ROTATION_ENABLED_CHECK

Verifica se um segredo armazenado no AWS Secrets Manager está configurado com rotação automática. O controlo falha se o segredo não estiver configurado com a rotação automática. Se fornecer um valor personalizado para o parâmetro maximumAllowedRotationFrequency, o controlo só é aprovado se o segredo for rodado automaticamente dentro do período especificado.

O Secrets Manager ajuda a melhorar a postura de segurança da sua organização. Os segredos incluem credenciais de bases de dados, palavras-passe e chaves de API de terceiros. Pode usar o Secrets Manager para armazenar secrets de forma centralizada, encriptar secrets automaticamente, controlar o acesso a secrets e rodar secrets de forma segura e automática.

O Secrets Manager pode rodar segredos. Pode usar a rotação para substituir segredos de longo prazo por segredos de curto prazo. A rotação dos seus segredos limita o tempo durante o qual um utilizador não autorizado pode usar um segredo comprometido. Por este motivo, deve rodar os seus segredos com frequência. Para saber mais sobre a rotação, consulte o artigo Rotação dos seus segredos do AWS Secrets Manager no guia do utilizador do AWS Secrets Manager.

Recomendação: verifica se todos os segredos do AWS Secrets Manager têm a rotação ativada

Para ativar a rotação automática para segredos do Secrets Manager, consulte o artigo Configure a rotação automática para segredos do AWS Secrets Manager através da consola no guia do utilizador do AWS Secrets Manager. Tem de escolher e configurar uma função do AWS Lambda para a rotação.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Sns Encrypted Kms

Nome da categoria na API: SNS_ENCRYPTED_KMS

Verifica se um tópico do SNS está encriptado em repouso através do AWS KMS. Os controlos falham se um tópico do SNS não usar uma chave do KMS para a encriptação do lado do servidor (SSE).

A encriptação de dados em repouso reduz o risco de um utilizador não autenticado na AWS aceder aos dados armazenados no disco. Também adiciona outro conjunto de controlos de acesso para limitar a capacidade de utilizadores não autorizados acederem aos dados. Por exemplo, são necessárias autorizações da API para desencriptar os dados antes de poderem ser lidos. Os tópicos do SNS devem ser encriptados em repouso para uma camada adicional de segurança.

Recomendação: verifica se todos os tópicos do SNS estão encriptados com o KMS

Para ativar a SSE para um tópico do SNS, consulte o artigo Ativar a encriptação do lado do servidor (SSE) para um tópico do Amazon SNS no guia do programador do Amazon Simple Notification Service. Antes de poder usar a SSE, também tem de configurar as políticas de chaves do AWS KMS para permitir a encriptação de tópicos e a encriptação e desencriptação de mensagens. Para mais informações, consulte o artigo Configurar autorizações do AWS KMS no guia do programador do Amazon Simple Notification Service.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Vpc Default Security Group Closed

Nome da categoria na API: VPC_DEFAULT_SECURITY_GROUP_CLOSED

Este controlo verifica se o grupo de segurança predefinido de uma VPC permite tráfego de entrada ou saída. O controlo falha se o grupo de segurança permitir tráfego de entrada ou saída.

As regras do grupo de segurança predefinido permitem todo o tráfego de saída e de entrada das interfaces de rede (e das respetivas instâncias) atribuídas ao mesmo grupo de segurança. Recomendamos que não use o grupo de segurança predefinido. Uma vez que não é possível eliminar o grupo de segurança predefinido, deve alterar a definição das regras do grupo de segurança predefinido para restringir o tráfego de entrada e saída. Isto impede o tráfego não intencional se o grupo de segurança predefinido for configurado acidentalmente para recursos como instâncias do EC2.

Recomendação: certifique-se de que o grupo de segurança predefinido de cada VPC restringe todo o tráfego

Para corrigir este problema, comece por criar novos grupos de segurança com privilégios mínimos. Para obter instruções, consulte o artigo Crie um grupo de segurança no manual do utilizador da Amazon VPC. Em seguida, atribua os novos grupos de segurança às suas instâncias do EC2. Para obter instruções, consulte o artigo Alterar o grupo de segurança de uma instância no guia do utilizador do Amazon EC2 para instâncias 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 predefinidos. Para ver instruções, consulte o guia do utilizador da Amazon VPC.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Vpc Flow Logging Enabled All Vpcs

Nome da categoria na API: VPC_FLOW_LOGGING_ENABLED_ALL_VPCS

Os registos de fluxo da VPC são uma funcionalidade que lhe permite capturar informações sobre o tráfego IP que entra e sai das interfaces de rede na sua VPC. Depois de criar um registo de fluxo, pode ver e obter os respetivos dados nos registos do Amazon CloudWatch. Recomendamos que os registos de fluxo da VPC sejam ativados para "Rejeições" de pacotes para VPCs.

Recomendação: certifique-se de que o registo de fluxos da VPC está ativado em todas as VPCs

Para corrigir esta deteção, conclua os seguintes passos:

Consola AWS

1. Inicie sessão na consola de gestão
2. Selecione Services e, de seguida, VPC
3. No painel de navegação do lado esquerdo, selecione Your VPCs
4. Selecione uma VPC
5. No painel do lado direito, selecione o separador Flow Logs.
6. Se não existir nenhum registo de fluxo, clique em Create Flow Log
7. Para Filtro, selecione Reject
8. Introduza um Role e um Destination Log Group
9. Clique em Create Log Flow
10. Clique em CloudWatch Logs Group

Nota: se definir o filtro como "Rejeitar", reduz drasticamente a acumulação de dados de registo para esta recomendação e fornece informações suficientes para fins de deteção de violações, investigação e remediação. No entanto, durante os períodos de engenharia de grupos de segurança com privilégios mínimos, definir este filtro como "Todos" pode ser muito útil para descobrir os fluxos de tráfego existentes necessários para o funcionamento adequado de um ambiente já em execução.

AWS CLI

1. Crie um documento de política e atribua-lhe o nome 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 atribua-lhe o nome iam_policy.json. Em seguida, 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 uma função 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 com o ARN da política de IAM devolvido no passo anterior para anexar a política à função de IAM (se o comando for bem-sucedido, não é devolvida nenhuma saída):

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 obter o VpcId disponível na região selecionada:

aws ec2 describe-vpcs --region <region>

7. O resultado do comando deve devolver o ID da VPC disponível na região selecionada.
8. Execute create-flow-logs para criar um registo 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 o passo 8 para outras VPCs disponíveis na região selecionada.
10. Altere a região atualizando --region e repita o procedimento de correção para outras VPCs.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Vpc Sg Open Only To Authorized Ports

Nome da categoria na API: VPC_SG_OPEN_ONLY_TO_AUTHORIZED_PORTS

Este controlo verifica se um grupo de segurança do Amazon EC2 permite tráfego de entrada sem restrições de portas não autorizadas. O estado do controlo é determinado da seguinte forma:

Se usar o valor predefinido para authorizedTcpPorts, o controlo falha se o grupo de segurança permitir tráfego de entrada não restrito de qualquer porta que não seja a porta 80 e 443.

Se fornecer valores personalizados para authorizedTcpPorts ou authorizedUdpPorts, o controlo falha se o grupo de segurança permitir tráfego de entrada sem restrições de qualquer porta não listada.

Se não for usado nenhum parâmetro, o controlo falha para qualquer grupo de segurança que tenha uma regra de tráfego de entrada não restrita.

Os grupos de segurança oferecem filtragem com estado do tráfego de rede de entrada e saída para a AWS. As regras do grupo de segurança devem seguir o princípio do acesso com o menor privilégio. O acesso não restrito (endereço IP com um sufixo /0) aumenta a oportunidade de atividade maliciosa, como pirataria, ataques de negação de serviço e perda de dados. A menos que uma porta seja especificamente permitida, a porta deve negar o acesso sem restrições.

Recomendação: verifica se qualquer grupo de segurança com 0.0.0.0/0 de qualquer VPC permite apenas tráfego TCP/UDP de entrada específico

Para modificar um grupo de segurança, consulte o artigo Trabalhar com grupos de segurança no guia do utilizador da Amazon VPC.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.

Both VPC VPN Tunnels Up

Nome da categoria na API: VPC_VPN_2_TUNNELS_UP

Um túnel VPN é um link encriptado onde os dados podem passar da rede do cliente para a AWS ou vice-versa numa ligação VPN site a site da AWS. Cada ligação VPN inclui dois túneis VPN que pode usar em simultâneo para alta disponibilidade. Garantir que ambos os túneis VPN estão ativos para uma ligação VPN é importante para confirmar uma ligação segura e altamente disponível entre uma VPC da AWS e a sua rede remota.

Este controlo verifica se ambos os túneis VPN fornecidos pela VPN site a site da AWS estão no estado UP. O controlo falha se um ou ambos os túneis estiverem no estado DOWN.

Recomendação: verifica se ambos os túneis VPN da AWS fornecidos pela AWS site-to-site estão no estado UP

Para modificar as opções do túnel de VPN, consulte o artigo Modificar as opções do túnel de VPN site a site no guia do utilizador da VPN site a site da AWS.

Saiba mais sobre os recursos suportados e as definições de análise deste tipo de descoberta.