Recomendações de segurança de identidade e acesso

Artigo
09/06/2024

Este artigo lista todas as recomendações de segurança de identidade e acesso que você pode ver no Microsoft Defender para Nuvem.

As recomendações que aparecem em seu ambiente são baseadas nos recursos que você está protegendo e em sua configuração personalizada.

Para saber mais sobre as ações que você pode tomar em resposta a essas recomendações, consulte Corrigir recomendações no Defender para Nuvem.

Dica

Se uma descrição de recomendação disser Nenhuma política relacionada, geralmente é porque essa recomendação depende de uma recomendação diferente.

Por exemplo, a recomendação As falhas de integridade da proteção de ponto de extremidade devem ser corrigidas depende da recomendação que verifica se uma solução de proteção de ponto de extremidade está instalada (a solução de proteção de ponto de extremidade deve ser instalada). A recomendação subjacente tem uma política. Limitar as políticas apenas às recomendações fundamentais simplifica o gerenciamento de políticas.

Recomendações de identidade e acesso do Azure

Uma quantidade máxima de três proprietários deve ser designada para as assinaturas

Descrição: para reduzir o potencial de violações por contas de proprietários comprometidas, recomendamos limitar o número de contas de proprietários a um máximo de 3 (política relacionada: no máximo 3 proprietários devem ser designados para sua assinatura).

Gravidade: Alta

As contas do Azure Cosmos DB devem usar o Azure Active Directory como o único método de autenticação

Descrição: a melhor maneira de autenticar nos serviços do Azure é usando o RBAC (Controle de Acesso Baseado em Função). O RBAC permite manter o princípio de privilégio mínimo e dá suporte à capacidade de revogar permissões como um método efetivo de resposta quando há comprometimento. Você pode configurar a sua conta do Azure Cosmos DB para impor o RBAC como o único método de autenticação. Quando a imposição for configurada, todos os outros métodos de acesso serão negados (chaves primárias/secundárias e tokens de acesso). (Não há política relacionada)

Gravidade: Média

As contas bloqueadas com permissões de proprietário em recursos do Azure devem ser removidas

Descrição: as contas que foram impedidas de entrar no Active Directory devem ser removidas dos recursos do Azure. Essas contas podem ser alvos de invasores que procuram encontrar maneiras de acessar seus dados sem serem percebidos. (Não há política relacionada)

Gravidade: Alta

As contas bloqueadas com permissões de leitura e gravação nos recursos do Azure devem ser removidas

Gravidade: Alta

As contas preteridas devem ser removidas das assinaturas

Descrição: as contas de usuário que foram impedidas de entrar devem ser removidas de suas assinaturas. Essas contas podem ser alvos de invasores que procuram encontrar maneiras de acessar seus dados sem serem percebidos. (Política relacionada: As contas obsoletas devem ser removidas da sua assinatura).

Gravidade: Alta

As contas preteridas com permissões de proprietário devem ser removidas das assinaturas

Descrição: as contas de usuário que foram impedidas de entrar devem ser removidas de suas assinaturas. Essas contas podem ser alvos de invasores que procuram encontrar maneiras de acessar seus dados sem serem percebidos. (Política relacionada: Contas obsoletas com permissões de proprietário devem ser removidas de sua assinatura).

Gravidade: Alta

Os logs de diagnóstico no Key Vault devem estar habilitados

Descrição: ative os logs e mantenha-os por até um ano. Isso permite recriar trilhas de atividades para fins de investigação quando ocorre um incidente de segurança ou quando sua rede é comprometida. (Política relacionada: Os logs de diagnóstico no Key Vault devem ser habilitados).

Gravidade: Baixa

As contas externas com permissões de proprietário devem ser removidas das assinaturas

Descrição: as contas com permissões de proprietário com nomes de domínio diferentes (contas externas) devem ser removidas da sua assinatura. Isso impede acesso não monitorado. Essas contas podem ser alvos de invasores que procuram encontrar maneiras de acessar seus dados sem serem percebidos. (Política relacionada: Contas externas com permissões de proprietário devem ser removidas de sua assinatura).

Gravidade: Alta

As contas externas com permissões de leitura devem ser removidas das assinaturas

Descrição: contas com permissões de leitura com nomes de domínio diferentes (contas externas) devem ser removidas da sua assinatura. Isso impede acesso não monitorado. Essas contas podem ser alvos de invasores que procuram encontrar maneiras de acessar seus dados sem serem percebidos. (Política relacionada: Contas externas com permissões de leitura devem ser removidas de sua assinatura).

Gravidade: Alta

As contas externas com permissões de gravação devem ser removidas das assinaturas

Descrição: contas com permissões de gravação com nomes de domínio diferentes (contas externas) devem ser removidas da sua assinatura. Isso impede acesso não monitorado. Essas contas podem ser alvos de invasores que procuram encontrar maneiras de acessar seus dados sem serem percebidos. (Política relacionada: Contas externas com permissões de gravação devem ser removidas de sua assinatura).

Gravidade: Alta

O firewall deve ser habilitado no Key Vault

Descrição: o firewall do cofre de chaves impede que o tráfego não autorizado chegue ao cofre de chaves e fornece uma camada adicional de proteção para seus segredos. Habilite o firewall para garantir que somente o tráfego de redes permitidas possa acessar o seu cofre de chaves. (Política relacionada: O firewall deve ser habilitado no Key Vault).

Gravidade: Média

As contas de convidado com permissões de proprietário em recursos do Azure devem ser removidas

Descrição: as contas com permissões de proprietário que foram provisionadas fora do locatário do Azure Active Directory (nomes de domínio diferentes) devem ser removidas dos recursos do Azure. As contas de convidado não são gerenciadas com os mesmos padrões que as identidades de locatário corporativo. Essas contas podem ser alvos de invasores que procuram encontrar maneiras de acessar seus dados sem serem percebidos. (Não há política relacionada)

Gravidade: Alta

As contas de convidado com permissões de leitura em recursos do Azure devem ser removidas

Descrição: as contas com permissões de leitura que foram provisionadas fora do locatário do Azure Active Directory (nomes de domínio diferentes) devem ser removidas dos recursos do Azure. As contas de convidado não são gerenciadas com os mesmos padrões que as identidades de locatário corporativo. Essas contas podem ser alvos de invasores que procuram encontrar maneiras de acessar seus dados sem serem percebidos. (Não há política relacionada)

Gravidade: Alta

As contas de convidado com permissões de gravação em recursos do Azure devem ser removidas

Descrição: as contas com permissões de gravação que foram provisionadas fora do locatário do Azure Active Directory (nomes de domínio diferentes) devem ser removidas dos recursos do Azure. As contas de convidado não são gerenciadas com os mesmos padrões que as identidades de locatário corporativo. Essas contas podem ser alvos de invasores que procuram encontrar maneiras de acessar seus dados sem serem percebidos. (Não há política relacionada)

Gravidade: Alta

As chaves do Key Vault devem ter uma data de validade

Descrição: as chaves criptográficas devem ter uma data de expiração definida e não devem ser permanentes. As chaves válidas para sempre dão a um invasor potencial mais tempo para comprometer a chave. É uma prática de segurança recomendada definir datas de expiração em chaves criptográficas. (Política relacionada: As chaves do Key Vault devem ter uma data de validade).

Gravidade: Alta

Os segredos do Key Vault devem ter uma data de validade

Descrição: os segredos devem ter uma data de expiração definida e não devem ser permanentes. Os segredos são válidos para sempre dão a um invasor potencial mais tempo para comprometê-las. É uma prática de segurança recomendada definir datas de expiração em segredos. (Política relacionada: Os segredos do Key Vault devem ter uma data de validade).

Gravidade: Alta

Os cofres de chaves devem ter a proteção contra limpeza habilitada

Descrição: a exclusão mal-intencionada de um cofre de chaves pode levar à perda permanente de dados. Um funcionário mal-intencionado em sua organização pode potencialmente excluir e limpar os cofres de chaves. A proteção de limpeza protege você contra ataques de invasores impondo um período de retenção obrigatório para cofres de chaves de exclusão temporária. Ninguém dentro de sua organização nem a Microsoft poderá limpar os cofres de chaves durante o período de retenção de exclusão temporária. (Política relacionada: Os cofres de chaves devem ter a proteção contra limpeza habilitada).

Gravidade: Média

Os cofres de chaves devem ter a exclusão temporária habilitada

Descrição: a exclusão de um cofre de chaves sem a exclusão reversível habilitada exclui permanentemente todos os segredos, chaves e certificados armazenados no cofre de chaves. A exclusão acidental de um cofre de chaves pode levar à perda permanente de dados. A exclusão temporária permite recuperar um cofre de chaves excluído acidentalmente por um período de retenção configurável. (Política relacionada: Os cofres de chaves devem ter a exclusão reversível habilitada).

Gravidade: Alta

O Microsoft Defender para Key Vault deve estar habilitado

Descrição: o Microsoft Defender para Nuvem inclui o Microsoft Defender para Key Vault, fornecendo uma camada adicional de inteligência de segurança. O Microsoft Defender para Key Vault detecta tentativas incomuns e potencialmente prejudiciais de acessar ou explorar contas do Key Vault.

As proteções desse plano são cobradas conforme mostrado na página de planos do Defender. Se você não tiver cofres de chaves nessa assinatura, não será cobrado. Se você criar cofres de chaves nessa assinatura, eles serão protegidos automaticamente e os encargos serão iniciados. Saiba mais sobre os detalhes de preços por região. Saiba mais em Introdução ao Microsoft Defender para Key Vault. (Política relacionada: O Azure Defender para Key Vault deve estar habilitado).

Gravidade: Alta

As permissões de identidades inativas em sua assinatura do Azure devem ser revogadas

Descrição: o Microsoft Defender para Nuvem descobriu uma identidade que não executou nenhuma ação em nenhum recurso em sua assinatura do Azure nos últimos 45 dias. Recomenda-se revogar permissões de identidades inativas, a fim de reduzir a superfície de ataque do seu ambiente de nuvem.

Gravidade: Média

O ponto de extremidade privado deve ser configurado para Key Vault

Descrição: o link privado fornece uma maneira de conectar o Key Vault aos recursos do Azure sem enviar tráfego pela Internet pública. O link privado fornece uma proteção avançada contra exfiltração dos dados. (Política relacionada: O ponto de extremidade privado deve ser configurado para o Key Vault).

Gravidade: Média

O acesso público da conta de armazenamento não deve ser permitido

Descrição: o acesso de leitura público anônimo a contêineres e blobs no Armazenamento do Azure é uma maneira conveniente de compartilhar dados, mas pode apresentar riscos de segurança. Para evitar violações de dados causadas por acesso anônimo indesejado, a Microsoft recomenda impedir o acesso público a uma conta de armazenamento, a menos que o seu cenário exija isso. (Política relacionada: O acesso público da conta de armazenamento não deve ser permitido).

Gravidade: Média

Deve haver mais de um proprietário atribuído às assinaturas

Descrição: designe mais de um proprietário de assinatura para ter redundância de acesso de administrador. (Política relacionada: Deve haver mais de um proprietário atribuído à sua assinatura).

Gravidade: Alta

O período de validade dos certificados armazenados no Azure Key Vault não deve exceder 12 meses

Descrição: Certifique-se de que seus certificados não tenham um período de validade superior a 12 meses. (Política relacionada: Os certificados devem ter o período máximo de validade especificado).

Gravidade: Média

As identidades superprovisionadas do Azure devem ter apenas as permissões necessárias (versão prévia)

Descrição: identidades superprovisionadas ou identidades com permissão não usam muitas das permissões concedidas. Dimensione regularmente as permissões dessas identidades para reduzir o risco de uso indevido de permissões, acidentais ou mal-intencionadas. Essa ação diminui o possível raio de explosão durante um incidente de segurança.

Gravidade: Média

As funções com privilégios não devem ter acesso permanente no nível da assinatura e do grupo de recursos

Descrição: o Microsoft Defender para Nuvem descobriu uma identidade que não executou nenhuma ação em nenhum recurso em sua assinatura do Azure nos últimos 45 dias. Recomenda-se revogar permissões de identidades inativas, a fim de reduzir a superfície de ataque do seu ambiente de nuvem.

Gravidade: Alta

As Entidades de Serviço não devem ser atribuídas com funções administrativas no nível da assinatura e do grupo de recursos

Descrição: o Defender para Nuvem identificou entidades de serviço atribuídas com funções privilegiadas no nível do grupo de recursos ou da assinatura. As funções de administrador privilegiado são funções que podem executar operações confidenciais no recurso, como Proprietário, Colaborador ou Administrador de Acesso do Usuário. As entidades de serviço desempenham um papel crucial no gerenciamento de recursos do Azure de forma eficiente e segura, eliminando a necessidade de intervenção humana. É importante seguir o princípio do menor privilégio, conceder apenas o nível mínimo de acesso necessário para que um determinado responsável de serviço desempenhe suas funções. Administradores e acesso privilegiado são o principal alvo dos hackers. Para as melhores práticas ao usar atribuições de função de administrador com privilégios, consulte Melhores práticas para o RBAC do Azure. Práticas recomendadas para RBAC do Azure. Para obter uma lista de funções disponíveis no RBAC do Azure, consulte Funções internas do Azure.

Gravidade: Alta

Recomendações de identidade e acesso da AWS

Os domínios do Amazon Elasticsearch Service devem estar em uma VPC

Descrição: a VPC não pode conter domínios com um endpoint público. Isso não avalia a configuração de roteamento de sub-rede da VPC para determinar a acessibilidade pública.

Gravidade: Alta

As permissões do Amazon S3 concedidas a outras contas AWS nas políticas de bucket devem ser restritas

Descrição: a implementação do acesso com privilégios mínimos é fundamental para reduzir o risco de segurança e o impacto de erros ou intenções maliciosas. Se uma política de bucket S3 permitir acesso em contas externas, isso poderá resultar na exfiltração dos dados por meio de uma ameaça interna ou um invasor. O parâmetro 'blacklistedactionpatterns' permite uma avaliação bem-sucedida da regra para buckets S3. O parâmetro concede acesso a contas externas para padrões de ação que não estão incluídos na lista "padrões de ação na lista negra".

Gravidade: Alta

Evite o uso da conta "raiz"

Descrição: a conta "raiz" tem acesso irrestrito a todos os recursos na conta da AWS. É altamente recomendável que o uso dessa conta seja evitado. A conta "raiz" é a conta AWS com mais privilégios. Minimizar o uso dessa conta e adotar o princípio de privilégios mínimos para o gerenciamento de acesso reduzirá o risco de alterações acidentais e divulgação não intencional de credenciais altamente privilegiadas.

Gravidade: Alta

As chaves do AWS KMS não devem ser excluídas acidentalmente

Descrição: esse controle verifica se as chaves do KMS estão programadas para exclusão. O controle falhará se uma chave do KMS estiver agendada para exclusão. As chaves do KMS não podem ser recuperadas depois de excluídas. Os dados criptografados em uma chave do KMS também serão permanentemente irrecuperáveis, se a chave do KMS for excluída. Se dados significativos tiverem sido criptografados em uma chave do KMS programada para exclusão, considere descriptografar os dados ou criptografá-los novamente em uma nova chave do KMS, a menos que você esteja executando intencionalmente uma eliminação criptográfica. Quando uma chave do KMS está agendada para exclusão, um período de espera obrigatório é aplicado para dar tempo de inverter a exclusão, caso tenha sido agendada por engano. O período de espera padrão é de 30 dias, mas pode ser reduzido para apenas sete dias quando a chave do KMS está programada para exclusão. Durante o período de espera, a exclusão programada pode ser cancelada e a chave do KMS não será excluída. Para obter mais informações sobre a exclusão de chaves do KMS, consulte Excluir chaves do KMS no Guia do desenvolvedor do AWS Key Management Service.

Gravidade: Alta

As identidades superprovisionadas da AWS devem ter apenas as permissões necessárias (demonstração)

Descrição: uma identidade ativa superprovisionada é uma identidade que tem acesso a privilégios que não foram usados. Identidades ativas superprovisionadas, especialmente para contas não humanas que têm ações e responsabilidades definidas, podem aumentar o raio de explosão no caso de comprometimento de um usuário, chave ou recurso. Remova permissões desnecessárias e estabeleça processos de revisão para obter as permissões menos privilegiadas.

Gravidade: Média

O log de ACL Web global Clássica do WAF do ACL deve estar habilitado

Descrição: esse controle verifica se o registro em log está habilitado para uma ACL da Web global do AWS WAF. Esse controle falhará se o registro em log não estiver habilitado para a ACL da web. O registro em log é uma parte importante da manutenção da confiabilidade, da disponibilidade e do desempenho do AWS WAF globalmente. É um requisito comercial e de conformidade em muitas organizações e permite que você solucione problemas de comportamento do aplicativo. Ele também fornece informações detalhadas sobre o tráfego analisado pela ACL da Web anexada ao AWS WAF.

Gravidade: Média

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

Descrição: esse controle verifica se uma distribuição do Amazon CloudFront está configurada para retornar um objeto específico que é o objeto raiz padrão. O controle falhará se a distribuição do CloudFront não tiver um objeto raiz padrão configurado. Às vezes, um usuário pode solicitar a URL raiz das distribuições, em vez de um objeto na distribuição. Quando isso acontece, especificar um objeto raiz padrão pode ajudar a evitar a exposição do conteúdo da distribuição na Web.

Gravidade: Alta

As distribuições do CloudFront devem ter a identidade de acesso de origem habilitada

Descrição: esse controle verifica se uma distribuição do Amazon CloudFront com o tipo de origem do Amazon S3 tem a Identidade de acesso de origem (OAI) configurada. O controle falhará se a OAI não estiver configurada. A OAI do CloudFront impede que os usuários acessem o conteúdo do bucket S3 diretamente. Quando os usuários acessam um bucket S3 diretamente, ignoram efetivamente a distribuição do CloudFront e todas as permissões aplicadas ao conteúdo do bucket S3 subjacente.

Gravidade: Média

A validação do arquivo de log do CloudTrail deve estar habilitada

Descrição: para garantir a verificação de integridade adicional dos logs do CloudTrail, recomendamos habilitar a validação de arquivos em todos os CloudTrails.

Gravidade: Baixa

O CloudTrail deve estar habilitado

Descrição: o AWS CloudTrail é um serviço da web que registra chamadas de API da AWS para sua conta e entrega arquivos de log para você. Nem todos os serviços habilitam o registro em log por padrão para todas as APIs e eventos. Você deve implementar as trilhas de auditoria adicionais que não são do CloudTrail e examinar a documentação de cada serviço nos Serviços e Integrações com Suporte do CloudTrail.

Gravidade: Alta

As trilhas do CloudTrail devem ser integradas aos logs do CloudWatch

Descrição: além de capturar logs do CloudTrail em um bucket do S3 especificado para análise de longo prazo, a análise em tempo real pode ser realizada configurando o CloudTrail para enviar logs para o CloudWatch Logs. Para uma trilha habilitada em todas as regiões em uma conta, o CloudTrail envia arquivos de log de todas essas regiões para um grupo de logs dos Logs do CloudWatch. Recomendamos que os logs do CloudTrail sejam enviados aos logs do CloudWatch para garantir que a atividade da conta AWS esteja sendo capturada, monitorada e devidamente acionada. O envio dos logs do CloudTrail para os logs do CloudWatch facilita o registro em log de atividades históricas e em tempo real de acordo com o usuário, a API, o recurso e o endereço IP, além de proporcionar a oportunidade de estabelecer alarmes e notificações para atividades anormais ou confidenciais da conta.

Gravidade: Baixa

O log de banco de dados deve estar habilitado

Descrição: esse controle verifica se os seguintes logs do Amazon RDS estão habilitados e enviados para o CloudWatch Logs:

Oracle: (Alerta, Auditoria, Rastreamento, Ouvinte)
PostgreSQL: (Postgresql, Atualização)
MySQL: (Auditoria, Erro, Geral, SlowQuery)
MariaDB: (Auditoria, Erro, Geral, SlowQuery)
SQL Server: (Erro, Agente)
Aurora: (Auditoria, Erro, Geral, SlowQuery)
Aurora-MySQL: (Auditoria, Erro, Geral, SlowQuery)
Aurora-PostgreSQL: (Postgresql, atualização). Os bancos de dados do RDS devem ter os logs relevantes habilitados. O registro em log do banco de dados fornece registros detalhados das solicitações feitas ao RDS. Os logs do banco de dados podem auxiliar nas auditorias de segurança e acesso, bem como ajudar a diagnosticar problemas de disponibilidade.

Gravidade: Média

Desabilitar o acesso direto à Internet para instâncias de bloco de anotações do Amazon Sage Maker

Descrição: o acesso direto à Internet deve ser desativado para uma instância de bloco de anotações do Sage Maker. Isso verifica se o campo 'DirectInternetAccess' está desabilitado para a instância de notebook. A instância deve ser configurada com uma VPC e a configuração padrão deve estar desabilitada – Acesse a Internet por meio de uma VPC. Para habilitar o acesso à Internet para treinar ou hospedar modelos de um notebook, verifique se a VPC tem um gateway NAT e se o grupo de segurança permite conexões de saída. Certifique-se de que o acesso à configuração do Sage Maker seja limitado apenas a usuários autorizados e restrinja as permissões do IAM dos usuários para modificar as configurações e os recursos do Sage Maker.

Gravidade: Alta

Não configurar as chaves de acesso durante a configuração inicial do usuário para todos os usuários do IAM que têm uma senha de console

Descrição: o console da AWS padroniza a caixa de seleção para criar chaves de acesso como enabled. Isso gera muitas chaves de acesso desnecessariamente. Além das credenciais desnecessárias, também gera um trabalho de gerenciamento desnecessário ao auditar e girar essas chaves. Exigir que etapas adicionais sejam executadas pelo usuário após a criação de seu perfil dará uma indicação mais forte da intenção de que as chaves de acesso são [a] necessárias para seu trabalho e [b] uma vez que a chave de acesso é estabelecida em uma conta, as chaves podem estar em uso em algum lugar da organização.

Gravidade: Média

Verificar se uma função de suporte foi criada para gerenciar incidentes com o Suporte do AWS

Descrição: a AWS fornece um centro de suporte que pode ser usado para notificação e resposta a incidentes, bem como suporte técnico e atendimento ao cliente. Crie uma Função do IAM para permitir que usuários autorizados gerenciem os incidentes com o Suporte do AWS. Quando você implementa o privilégio mínimo para controle de acesso, uma função do IAM requer uma política do IAM apropriada para permitir o acesso ao centro de suporte para gerenciar incidentes com o AWS Support.

Gravidade: Baixa

Verificar se as chaves de acesso são giradas a cada 90 dias ou menos

Descrição: as chaves de acesso consistem em um ID de chave de acesso e uma chave de acesso secreta, que são usadas para assinar solicitações programáticas feitas na AWS. Os usuários do AWS precisam de suas próprias chaves de acesso para fazer chamadas programáticas para o AWS CLI (Interface de Linha de Comando do AWS), Ferramentas para Windows PowerShell, SDKs do AWS ou chamadas HTTP diretas usando as APIs para serviços individuais do AWS. É recomendável que todas as teclas de acesso sejam giradas regularmente. A rotação das chaves de acesso reduz a janela de oportunidade para que uma chave de acesso associada a uma conta comprometida ou encerrada seja usada. As chaves de acesso devem ser giradas para garantir que os dados não possam ser acessados com uma chave antiga, que pode ter sido perdida, quebrada ou roubada.

Gravidade: Média

Verificar se o AWS Config está habilitado em todas as regiões

Descrição: o AWS Config é um serviço da web que executa o gerenciamento de configuração de recursos da AWS compatíveis em sua conta e fornece arquivos de log para você. As informações registradas incluem o item de configuração (recurso do AWS), as relações entre os itens de configuração (recursos do AWS), as alterações de configuração entre os recursos. É recomendável habilitar o AWS Config em todas as regiões.

O histórico de itens de configuração do AWS capturado pelo AWS Config permite a análise de segurança, o controle de alterações dos recursos e a auditoria de conformidade.

Gravidade: Média

Verificar se o CloudTrail está habilitado em todas as regiões

Descrição: o AWS CloudTrail é um serviço da web que registra chamadas de API da AWS para sua conta e entrega arquivos de log para você. As informações gravadas incluem a identidade do autor da chamada à API, a hora da chamada à API, o endereço IP de origem do autor da chamada à API, os parâmetros de solicitação e os elementos de resposta retornados pelo serviço do AWS. O CloudTrail fornece um histórico de chamadas à API do AWS para uma conta, incluindo chamadas à API feitas por meio do console de gerenciamento, SDKs, ferramentas de linha de comando e serviços do AWS de nível superior (como CloudFormation). O histórico de chamadas à API do AWS gerado pelo CloudTrail permite a análise de segurança, o controle de alterações dos recursos e a auditoria de conformidade. Além disso:

Verificar se existe uma trilha de várias regiões garante que atividades inesperadas que ocorrem em regiões não utilizadas sejam detectadas.
Verificar se existe uma trilha de várias regiões garante que o "Global Service Logging" esteja habilitado para uma trilha por padrão para capturar a gravação de eventos gerados nos serviços globais da AWS.
Para uma trilha de várias regiões, verificar se os eventos de gerenciamento estão configurados para todos os tipos de leitura/gravação garante o registro das operações de gerenciamento executadas em todos os recursos em uma conta da AWS.

Gravidade: Alta

Verificar se as credenciais não utilizadas por 90 dias ou mais estão desabilitadas

Descrição: os usuários do AWS IAM podem acessar os recursos da AWS usando diferentes tipos de credenciais, como senhas ou chaves de acesso. É recomendável que todas as credenciais que não foram usadas em 90 dias ou mais sejam removidas ou desativadas. Desabilitar ou remover credenciais desnecessárias reduz a janela de oportunidade para que as credenciais associadas a uma conta comprometida ou abandonada sejam usadas.

Gravidade: Média

Verificar se a política de senha do IAM torna sem efeito as senhas no prazo de 90 dias ou menos

Descrição: as políticas de senha do IAM podem exigir que as senhas sejam alternadas ou expiradas após um determinado número de dias. É recomendável que a política de senha expire as senhas após 90 dias ou menos. Reduzir o tempo de vida da senha aumenta a resiliência da conta em relação às tentativas de logon de força bruta. Além disso, exigir alterações de senha regulares ajuda nos seguintes cenários:

As senhas podem ser roubadas ou comprometidas, às vezes sem o seu conhecimento. Isso pode ocorrer por meio de um comprometimento do sistema, uma vulnerabilidade de software ou uma ameaça interna.
Certos filtros da web corporativos e governamentais ou servidores proxy têm a capacidade de interceptar e registrar o tráfego, mesmo que esteja criptografado.
Muitas pessoas usam a mesma senha para muitos sistemas, como trabalho, e-mail e pessoal.
As estações de trabalho do usuário final comprometidas podem ter um registrador de pressionamento de tecla.

Gravidade: Baixa

Verificar se a política de senha do IAM impede a reutilização de senhas

Descrição: as políticas de senha do IAM podem impedir a reutilização de uma determinada senha pelo mesmo usuário. É recomendável que a política de senha impeça a reutilização de senhas. Evitar a reutilização de senhas aumenta a resiliência da conta em relação às tentativas de logon de força bruta.

Gravidade: Baixa

Verificar se a política de senha do IAM exige pelo menos uma letra minúscula

Descrição: as políticas de senha são, em parte, usadas para impor requisitos de complexidade de senha. As políticas de senha do IAM podem ser usadas para garantir que as senhas sejam compostas por diferentes conjuntos de caracteres. É recomendável que a política de senha exija pelo menos uma letra minúscula. Definir uma política de complexidade de senha aumenta a resiliência da conta em relação às tentativas de logon de força bruta.

Gravidade: Média

Verificar se a política de senha do IAM exige pelo menos um número

Descrição: as políticas de senha são, em parte, usadas para impor requisitos de complexidade de senha. As políticas de senha do IAM podem ser usadas para garantir que as senhas sejam compostas por diferentes conjuntos de caracteres. É recomendável que a política de senha exija pelo menos um número. Definir uma política de complexidade de senha aumenta a resiliência da conta em relação às tentativas de logon de força bruta.

Gravidade: Média

Verificar se a política de senha do IAM exige pelo menos um símbolo

Descrição: as políticas de senha são, em parte, usadas para impor requisitos de complexidade de senha. As políticas de senha do IAM podem ser usadas para garantir que as senhas sejam compostas por diferentes conjuntos de caracteres. É recomendável que a política de senha exija pelo menos um símbolo. Definir uma política de complexidade de senha aumenta a resiliência da conta em relação às tentativas de logon de força bruta.

Gravidade: Média

Verificar se a política de senha do IAM exige pelo menos uma letra maiúscula

Descrição: as políticas de senha são, em parte, usadas para impor requisitos de complexidade de senha. As políticas de senha do IAM podem ser usadas para garantir que as senhas sejam compostas por diferentes conjuntos de caracteres. É recomendável que a política de senha exija pelo menos uma letra maiúscula. Definir uma política de complexidade de senha aumenta a resiliência da conta em relação às tentativas de logon de força bruta.

Gravidade: Média

Verificar se a política de senha do IAM exige pelo menos 14 caracteres ou mais

Descrição: as políticas de senha são, em parte, usadas para impor requisitos de complexidade de senha. As políticas de senha do IAM podem ser usadas para garantir que a senha tenha pelo menos um tamanho determinado. É recomendável que a política de senha exija um comprimento mínimo de senha '14'. Definir uma política de complexidade de senha aumenta a resiliência da conta em relação às tentativas de logon de força bruta.

Gravidade: Média

Certifique-se de que a autenticação multifator (MFA) esteja habilitada para todos os usuários do IAM que tenham uma senha do console

Descrição: a autenticação multifator (MFA) adiciona uma camada extra de proteção além de um nome de usuário e senha. Com a MFA habilitada, quando um usuário faz login em um site da AWS, ele será solicitado a fornecer seu nome de usuário e senha, bem como um código de autenticação de seu dispositivo AWS MFA. É recomendável que a MFA seja habilitada para todas as contas que têm uma senha de console. Habilitar a MFA fornece maior segurança para o acesso do console, pois exige que a entidade de segurança de autenticação possua um dispositivo que emite uma chave sensível ao tempo e tenha conhecimento de uma credencial.

Gravidade: Média

O GuardDuty deve estar habilitado

Descrição: para fornecer proteção adicional contra invasões, o GuardDuty deve estar habilitado em sua conta e região da AWS.

O GuardDuty pode não ser uma solução completa para todos os ambientes.

Gravidade: Média

A MFA de hardware deve estar habilitada para a conta "raiz"

Descrição: a conta raiz é o usuário mais privilegiado em uma conta. A MFA proporciona uma camada adicional de proteção além de um nome de usuário e senha. Com a MFA habilitada, quando um usuário entrar em um site do AWS, ele será solicitado a fornecer o nome de usuário e a senha, bem como um código de autenticação do dispositivo do AWS MFA. Para o Nível 2, é recomendável proteger a conta raiz com uma MFA de hardware. Uma MFA de hardware tem uma superfície de ataque menor do que uma MFA virtual. Por exemplo, uma MFA de hardware não sofre o ataque que a superfície introduziu pelo smartphone móvel em que reside uma MFA virtual. Quando você usa hardware para MFA para muitas, muitas contas, isso pode criar um problema de gerenciamento de dispositivo logístico. Se isso ocorrer, implemente essa recomendação de Nível 2 seletivamente para as contas de maior segurança. Em seguida, você pode aplicar a recomendação de Nível 1 às contas restantes.

Gravidade: Baixa

A autenticação do IAM deve ser configurada para clusters do RDS

Descrição: esse controle verifica se um cluster de banco de dados do RDS tem a autenticação de banco de dados do IAM habilitada. A autenticação do banco de dados do IAM permite a autenticação sem senha para instâncias do banco de dados. A autenticação usa um token de autenticação. O tráfego de rede do banco de dados é criptografado usando SSL. Para obter mais informações, confira a autenticação do banco de dados do IAM no Guia do Usuário do Amazon Aurora.

Gravidade: Média

A autenticação do IAM deve ser configurada para instâncias do RDS

Descrição: esse controle verifica se uma instância de banco de dados do RDS tem a autenticação de banco de dados do IAM habilitada. A autenticação do banco de dados do IAM permite a autenticação em instâncias do banco de dados com um token de autenticação, em vez de uma senha. O tráfego de rede do banco de dados é criptografado usando SSL. Para obter mais informações, confira a autenticação do banco de dados do IAM no Guia do Usuário do Amazon Aurora.

Gravidade: Média

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

Descrição: verifica se a versão padrão das políticas gerenciadas pelo cliente do IAM permite que as entidades principais usem as ações de descriptografia do AWS KMS em todos os recursos. Esse controle usa o Zelkova, um mecanismo de raciocínio automatizado, para validar e avisar sobre políticas que podem conceder amplo acesso aos seus segredos em contas da AWS. Esse controle falhará se as ações "kms: Decrypt" ou "kms: ReEncryptFrom" forem permitidas em todas as chaves do KMS. O controle avalia as políticas gerenciadas pelo cliente anexadas e não anexadas. Ele não verifica políticas em linha ou políticas gerenciadas pela AWS. Com o AWS KMS, você controla quem pode usar as chaves do KMS e obter acesso aos dados criptografados. As políticas do IAM definem quais ações uma identidade (usuário, grupo ou função) pode executar em quais recursos. Seguindo as melhores práticas de segurança, o AWS recomenda que você permita privilégios mínimos. Em outras palavras, você deve conceder às identidades apenas as permissões "kms:Decrypt" ou "kms:ReEncryptFrom" e apenas para as chaves necessárias para executar uma tarefa. Caso contrário, o usuário poderá usar chaves que não são apropriadas para seus dados. Em vez de conceder permissões para todas as chaves, determine o conjunto mínimo de chaves que os usuários precisam para acessar os dados criptografados. Em seguida, crie políticas que permitam aos usuários usar apenas essas chaves. Por exemplo, não permita a permissão "kms: Decrypt" em todas as chaves do KMS. Em vez disso, permita "kms: Descriptografar" apenas em chaves em uma região específica para sua conta. Ao adotar o princípio de privilégios mínimos, você pode reduzir o risco de divulgação não intencional dos dados.

Gravidade: Média

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

Descrição: esse controle verifica se as políticas baseadas em identidade do IAM que você cria têm instruções Allow que usam o curinga * para conceder permissões para todas as ações em qualquer serviço. O controle falhará se qualquer instrução de política incluir 'Effect': 'Allow' com 'Action': 'Service:*'. Por exemplo, a instrução a seguir em uma política resulta em conclusões com falha.

'Statement': [
{
  'Sid': 'EC2-Wildcard',
  'Effect': 'Allow',
  'Action': 'ec2:*',
  'Resource': '*'
}

O controle também falhará se você usar 'Effect': 'Allow' com 'NotAction': 'service:'. Nesse caso, o elemento NotAction fornece acesso a todas as ações em um serviço da AWS, exceto as ações especificadas em NotAction. Esse controle só se aplica a políticas do IAM gerenciadas pelo cliente. Ele não se aplica a políticas do IAM gerenciadas pela AWS. Quando você atribui permissões aos serviços da AWS, é importante definir o escopo das ações permitidas do IAM em suas políticas do IAM. Você deve restringir as ações do IAM apenas às ações necessárias. Isso ajuda você a provisionar permissões de privilégios mínimos. Políticas excessivamente permissivas podem levar ao escalonamento de privilégios se as políticas estiverem anexadas a uma entidade principal do IAM que pode não exigir a permissão. Em alguns casos, talvez você queira permitir ações do IAM que tenham um prefixo semelhante, como DescribeFlowLogs e DescribeAvailabilityZones. Nesses casos autorizados, você pode adicionar um curinga sufixo ao prefixo comum. Por exemplo, ec2:Describe.

Esse controle será aprovado se você usar uma ação com prefixo do IAM com um curinga com sufixo. Por exemplo, a instrução a seguir em uma política resulta em conclusões aprovadas.

 'Statement': [
{
  'Sid': 'EC2-Wildcard',
  'Effect': 'Allow',
  'Action': 'ec2:Describe*',
  'Resource': '*'
}

Ao agrupar as ações do IAM relacionadas dessa forma, você também pode evitar exceder os limites de tamanho da política do IAM.

Gravidade: Baixa

As políticas do IAM devem ser anexadas somente a grupos ou funções

Descrição: por padrão, os usuários, grupos e funções do IAM não têm acesso aos recursos da AWS. As políticas do IAM são os meios pelos quais os privilégios são concedidos a usuários, grupos ou funções. É recomendável que as políticas do IAM sejam aplicadas diretamente a grupos e funções, mas não a usuários. Atribuir privilégios no nível do grupo ou da função reduz a complexidade do gerenciamento de acesso, à medida que o número de usuários aumenta. Reduzir a complexidade do gerenciamento de acesso também pode reduzir a oportunidade de uma entidade principal receber ou reter privilégios excessivos inadvertidamente.

Gravidade: Baixa

As políticas do IAM que permitem privilégios administrativos completos ":" não devem ser criadas

Descrição: as políticas do IAM são os meios pelos quais os privilégios são concedidos a usuários, grupos ou funções. É recomendado e considerado um conselho de segurança padrão para conceder privilégios mínimos, ou seja, conceder apenas as permissões necessárias para executar uma tarefa. Determine o que os usuários precisam fazer e, em seguida, crie políticas que permitam que eles executem apenas essas tarefas, em vez de permitir privilégios administrativos completos. É mais seguro começar com um conjunto mínimo de permissões e conceder permissões adicionais, conforme necessário, em vez de começar com permissões muito flexíveis e depois tentar restringi-las. Fornecer privilégios administrativos completos, em vez de restringir ao conjunto mínimo de permissões necessárias para o usuário, expõe os recursos a ações possivelmente indesejadas. As políticas do IAM que têm uma instrução com "Effect": "Allow" com "Action": "" sobre "Resource": "" devem ser removidas.

Gravidade: Alta

As entidades de segurança do IAM não devem ter políticas embutidas do IAM que permitam ações de descriptografia em todas as chaves do KMS

Descrição: verifica se as políticas em linha incorporadas às identidades do IAM (função, usuário ou grupo) permitem as ações de descriptografia do AWS KMS em todas as chaves do KMS. Esse controle usa o Zelkova, um mecanismo de raciocínio automatizado, para validar e avisar sobre políticas que podem conceder amplo acesso aos seus segredos em contas da AWS. Esse controle falhará se kms:Decrypt as ações forem kms:ReEncryptFrom permitidas em todas as chaves do KMS em uma política em linha. Com o AWS KMS, você controla quem pode usar as chaves do KMS e obter acesso aos dados criptografados. As políticas do IAM definem quais ações uma identidade (usuário, grupo ou função) pode executar em quais recursos. Seguindo as melhores práticas de segurança, o AWS recomenda que você permita privilégios mínimos. Em outras palavras, você deve conceder às identidades apenas as permissões necessárias e apenas para as chaves necessárias para executar uma tarefa. Caso contrário, o usuário poderá usar chaves que não são apropriadas para seus dados. Em vez de conceder permissão para todas as chaves, determine o conjunto mínimo de chaves que os usuários precisam para acessar os dados criptografados. Em seguida, crie políticas que permitam aos usuários usar apenas essas chaves. Por exemplo, não permita kms:Decrypt permissão em todas as chaves do KMS. Em vez disso, conceda a permissão somente nas chaves em uma região específica da conta. Ao adotar o princípio de privilégios mínimos, você pode reduzir o risco de divulgação não intencional dos dados.

Gravidade: Média

As funções Lambda devem restringir o acesso público

Descrição: a política baseada em recursos da função Lambda deve restringir o acesso público. Essa recomendação não verifica o acesso por entidades internas. Garanta que o acesso à função seja restrito somente a entidades de segurança autorizadas usando políticas baseadas em recursos com privilégios mínimos.

Gravidade: Alta

A MFA deve estar habilitada para todos os usuários do IAM

Descrição: todos os usuários do IAM devem ter a autenticação multifator (MFA) ativada.

Gravidade: Média

A MFA deve estar habilitada para a conta "raiz"

Descrição: a conta raiz é o usuário mais privilegiado em uma conta. A MFA proporciona uma camada adicional de proteção além de um nome de usuário e senha. Com a MFA habilitada, quando um usuário entrar em um site do AWS, ele será solicitado a fornecer o nome de usuário e a senha, bem como um código de autenticação do dispositivo do AWS MFA. Quando você usa MFA virtual para contas raiz, é recomendável que o dispositivo usado não seja um dispositivo pessoal. Em vez disso, use um dispositivo móvel dedicado (tablet ou telefone) que você consiga manter carregado e protegido, independentemente dos dispositivos pessoais individuais. Isso reduz os riscos de perder o acesso à MFA devido à perda de dispositivo, à troca de dispositivo ou se o indivíduo proprietário do dispositivo deixar de trabalhar para a empresa.

Gravidade: Baixa

As políticas de senha para usuários do IAM devem ter configurações fortes

Descrição: verifica se a política de senha da conta para usuários do IAM usa as configurações mínimas a seguir.

RequireUppercaseCharacters- Requer pelo menos um caractere maiúsculo na senha. (Padrão = true)
RequireLowercaseCharacters- Requer pelo menos um caractere minúsculo na senha. (Padrão = true)
RequireNumbers- Requer pelo menos um número na senha. (Padrão = true)
MinimumPasswordLength- Comprimento mínimo da senha. (Padrão = 7 ou mais)
PasswordReusePrevention- Número de senhas antes de permitir a reutilização. (Padrão =4)
MaxPasswordAge- Número de dias antes da expiração da senha. (Padrão = 90)

Gravidade: Média

As permissões de identidades inativas em sua conta da AWS devem ser revogadas

Descrição: o Microsoft Defender para Nuvem descobriu uma identidade que não executou nenhuma ação em nenhum recurso em sua conta da AWS nos últimos 45 dias. Recomenda-se revogar permissões de identidades inativas, a fim de reduzir a superfície de ataque do seu ambiente de nuvem.

Gravidade: Média

A chave de acesso da conta raiz não deve existir

Descrição: a conta raiz é o usuário mais privilegiado em uma conta da AWS. As Chaves de Acesso do AWS fornecem acesso programático a determinada conta AWS. É recomendável que todas as chaves de acesso associadas à conta raiz sejam removidas. Remover as chaves de acesso associadas à conta raiz limita os vetores pelos quais a conta pode ser comprometida. Além disso, a remoção das chaves de acesso raiz incentiva a criação e o uso de contas baseadas em funções com privilégios mínimos.

Gravidade: Alta

A configuração Bloquear Acesso Público do S3 deve estar habilitada

Descrição: habilitar a configuração Bloquear acesso público para o bucket do S3 pode ajudar a evitar vazamentos de dados confidenciais e proteger o bucket contra ações maliciosas.

Gravidade: Média

A configuração Bloquear Acesso Público do S3 deve estar habilitada no nível do bucket

Descrição: esse controle verifica se os buckets do S3 têm blocos de acesso público no nível do bucket aplicados. Esse controle falhará se qualquer uma das seguintes configurações for definida como false:

ignorePublicAcls
blockPublicPolicy
blockPublicAcls
restrictPublicBuckets Bloquear acesso público no nível do bucket do S3 fornece controles para garantir que os objetos nunca tenham acesso público. O acesso público é concedido a buckets e objetos por meio de ACLs (listas de controle de acesso), políticas de bucket ou ambos. A menos que você pretenda deixar os buckets S3 acessíveis publicamente, deve configurar o recurso Bloquear Acesso Público do Amazon S3 no nível do bucket.

Gravidade: Alta

O acesso público de leitura dos buckets S3 deve ser removido

Descrição: remover o acesso público de leitura ao bucket do S3 pode ajudar a proteger seus dados e evitar uma violação de dados.

Gravidade: Alta

O acesso público de gravação dos buckets S3 deve ser removido

Descrição: permitir o acesso público de gravação ao bucket do S3 pode deixá-lo vulnerável a ações maliciosas, como armazenar dados às suas custas, criptografar seus arquivos para resgate ou usar seu bucket para operar malware.

Gravidade: Alta

Os segredos do Secrets Manager devem ter a rotação automática habilitada

Descrição: esse controle verifica se um segredo armazenado no AWS Secrets Manager está configurado com alternância automática. O Secrets Manager ajuda você a melhorar a postura de segurança da organização. Os segredos incluem credenciais de banco de dados, senhas e chaves de API de terceiros. Você pode usar o Secrets Manager para armazenar segredos de forma centralizada, criptografar segredos automaticamente, controlar o acesso a segredos e girar segredos de forma segura e automática. O Secrets Manager pode girar os segredos. Você pode usar a rotação para substituir segredos de longo prazo por segredos de curto prazo. Girar os segredos limita o tempo em que um usuário não autorizado pode usar um segredo comprometido. Por esse motivo, você deve girar os segredos com frequência. Para saber mais sobre a rotação, confira Rotação dos segredos do AWS Secrets Manager no Guia do Usuário do AWS Secrets Manager.

Gravidade: Média

As instâncias interrompidas do EC2 devem ser removidas após um período especificado

Descrição: esse controle verifica se alguma instância do EC2 foi interrompida por mais do que o número permitido de dias. Uma instância do EC2 falhará nessa verificação se for interrompida por mais tempo do que o período máximo permitido, que, por padrão, é de 30 dias. As conclusões com falha indicam que uma instância do EC2 não foi executada por um período significativo. Isso cria um risco de segurança porque a instância do EC2 não está sendo mantida ativamente (analisada, corrigida, atualizada). Se for lançado posteriormente, a falta de manutenção adequada pode resultar em problemas inesperados em seu ambiente da AWS. Para manter uma instância do EC2 com segurança ao longo do tempo em um estado nonrunning, inicie-a periodicamente para manutenção e depois interrompa-a após a manutenção. O ideal é que esse seja um processo automático.

Gravidade: Média

As identidades não utilizadas em seu ambiente da AWS devem ser removidas (demonstração)

Descrição: identidades inativas são entidades humanas e não humanas que não realizaram nenhuma ação em nenhum recurso nos últimos 90 dias. Identidades inativas do IAM com permissões de alto risco em sua conta da AWS podem ser propensas a ataques se deixadas como estão e deixar as organizações abertas ao uso indevido ou exploração de credenciais. A detecção e a resposta proativas a identidades não utilizadas ajudam a impedir que entidades não autorizadas obtenham acesso aos seus recursos da AWS.

Gravidade: Média

Recomendações de identidade e acesso do GCP

As chaves criptográficas não devem ter mais de três usuários

Descrição: essa recomendação avalia as políticas do IAM para chaves, projetos e organizações e recupera entidades principais com papéis que permitem criptografar, descriptografar ou assinar dados usando chaves do Cloud KMS: roles/owner, roles/cloudkms.cryptoKeyEncrypterDecrypter, roles/cloudkms.cryptoKeyEncrypter, roles/cloudkms.cryptoKeyDecrypter, roles/cloudkms.signer e roles/cloudkms.signerVerifier.

Gravidade: Média

Certifique-se de que as chaves de API não tenham sido criadas para um determinado projeto

Descrição: as chaves não são seguras porque podem ser visualizadas publicamente, como em um navegador, ou podem ser acessadas em um dispositivo em que a chave reside. Em vez disso, é recomendável usar o fluxo de autenticação padrão.

Os riscos de segurança envolvidos no uso de chaves de API aparecem abaixo:

As chaves de API são strings criptografadas simples
As chaves de API não identificam o usuário ou o aplicativo que faz a solicitação de API
As chaves de API geralmente são acessíveis aos clientes, facilitando a descoberta e o roubo de uma chave de API

Para evitar o risco de segurança no uso de chaves de API, é recomendável usar o fluxo de autenticação padrão.

Gravidade: Alta

Certifique-se de que as chaves da API estejam restritas somente às APIs que o aplicativo precisa

Descrição: as chaves de API não são seguras porque podem ser visualizadas publicamente, como em um navegador, ou podem ser acessadas em um dispositivo em que a chave reside. É recomendável restringir as chaves de API para usar (chamar) apenas APIs exigidas por um aplicativo.

Os riscos de segurança envolvidos no uso de chaves de API seguem abaixo:

As chaves de API são strings criptografadas simples
As chaves de API não identificam o usuário ou o aplicativo que faz a solicitação de API
As chaves de API geralmente são acessíveis aos clientes, facilitando a descoberta e o roubo de uma chave de API

À luz desses riscos potenciais, o Google recomenda usar o fluxo de autenticação padrão em vez de chaves de API. No entanto, há casos limitados em que as chaves de API são mais apropriadas. Por exemplo, se houver um aplicativo para dispositivos móveis que precise usar a API Google Cloud Translation, mas não precise de um servidor de back-end, as chaves de API serão a maneira mais simples de se autenticar nessa API.

Para reduzir as superfícies de ataque fornecendo privilégios mínimos, as chaves de API pode ser restringidas a usar (chamar) somente APIs exigidas por um aplicativo.

Gravidade: Alta

Certifique-se de que as chaves de API estejam restritas a uso somente em hosts e aplicativos especificados

Descrição: as chaves irrestritas são inseguras porque podem ser visualizadas publicamente, como em um navegador, ou podem ser acessadas em um dispositivo em que a chave reside. É recomendável restringir o uso da chave de API a hosts confiáveis, referenciadores HTTP e aplicativos.

Os riscos de segurança envolvidos no uso de chaves de API aparecem abaixo:

As chaves de API são strings criptografadas simples
As chaves de API não identificam o usuário ou o aplicativo que faz a solicitação de API
As chaves de API geralmente são acessíveis aos clientes, facilitando a descoberta e o roubo de uma chave de API

Para reduzir os vetores de ataque, as chaves de API podem ser restritas apenas a hosts confiáveis, referenciadores HTTP e aplicativos.

Gravidade: Alta

Certifique-se de que a rotação das chaves de API seja realizada a cada 90 dias

Descrição: é recomendável alternar as chaves de API a cada 90 dias.

Os riscos de segurança envolvidos no uso de chaves de API estão listados abaixo:

As chaves de API são strings criptografadas simples
As chaves de API não identificam o usuário ou o aplicativo que faz a solicitação de API
As chaves de API geralmente são acessíveis aos clientes, facilitando a descoberta e o roubo de uma chave de API

Devido a esses riscos potenciais, o Google recomenda usar o fluxo de autenticação padrão em vez de chaves de API. No entanto, há casos limitados em que as chaves de API são mais apropriadas. Por exemplo, se houver um aplicativo para dispositivos móveis que precise usar a API Google Cloud Translation, mas não precise de um servidor de back-end, as chaves de API serão a maneira mais simples de se autenticar nessa API.

Depois que uma chave é roubada, ela não tem expiração, o que significa que pode ser usada indefinidamente, a menos que o proprietário do projeto revogue ou regenere a chave. A rotação de chaves API reduzirá a janela de oportunidade para que uma chave de acesso associada a uma conta comprometida ou encerrada seja usada.

As chaves de API devem ser giradas para garantir que os dados não possam ser acessados com uma chave antiga que possa ter sido perdida, quebrada ou roubada.

Gravidade: Alta

Certifique-se de que a rotação das chaves de criptografia do KMS seja realizada dentro de um período de 90 dias

Descrição: o serviço de gerenciamento de chaves do Google Cloud armazena chaves criptográficas em uma estrutura hierárquica projetada para um gerenciamento de controle de acesso útil e elegante. O formato do agendamento de rotação depende da biblioteca de clientes usada. Para a ferramenta de linha de comando gcloud, o próximo tempo de rotação deve estar no formato "ISO" ou "RFC3339", e o período de rotação deve estar no formato "INTEGER[UNIT]", onde as unidades podem ser uma de segundos (s), minutos (m), horas (h) ou dias (d). Defina uma hora de início e um período de rotação de chaves. Uma chave pode ser criada com um "período de rotação" especificado, que é o tempo entre o momento em que novas versões de chave são geradas automaticamente. Uma chave também pode ser criada com um tempo de rotação especificado na próxima rotação. Uma chave é um objeto nomeado que representa uma "chave criptográfica" usada para uma finalidade específica. O material da chave, os bits reais usados para "criptografia", pode mudar com o tempo à medida que novas versões de chave são criadas. Uma chave é usada para proteger algum "corpus de dados". Uma coleção de arquivos pode ser criptografada com a mesma chave e as pessoas com permissões de "descriptografia" nessa chave poderão descriptografar esses arquivos. Portanto, é necessário garantir que o "período de rotação" seja definido como um horário específico.

Gravidade: Média

Certifique-se de que haja um filtro de métrica de log e alertas para alterações/atribuições de propriedade do projeto

Descrição: para evitar atribuições desnecessárias de propriedade de projetos a usuários/contas de serviço e outros usos indevidos de projetos e recursos, todas as atribuições de "funções/proprietário" devem ser monitoradas. Os membros (usuários/contas de serviço) com uma atribuição de função para a função primitiva "funções/proprietário" são proprietários do projeto. O proprietário do projeto tem todos os privilégios no projeto aos quais a função pertence. Eles são resumidos abaixo:

Todas as permissões de visualizador em todos os serviços do GCP no projeto
Permissões para ações que modificam o estado de todos os serviços do GCP no projeto
Gerenciar funções e permissões para um projeto e todos os recursos dentro do projeto
Configurar o faturamento de um projeto Conceder a função de proprietário a um membro (usuário/conta de serviço) permitirá que esse membro modifique a política do Identity and Access Management (IAM). Portanto, conceda a função de proprietário somente se o membro tiver uma finalidade legítima para gerenciar a política de IAM. Isso ocorre porque a política de IAM do projeto contém dados confidenciais de controle de acesso. Ter um conjunto mínimo de usuários autorizados a gerenciar a política do IAM simplificará qualquer auditoria que possa ser necessária. A propriedade do projeto tem o nível mais alto de privilégios em um projeto. Para evitar o uso indevido de recursos do projeto, as ações de atribuição/alteração de propriedade do projeto mencionadas acima devem ser monitoradas e alertadas para os destinatários preocupados.
Envio de convites de propriedade do projeto
Aceitação/rejeição do convite de propriedade do projeto pelo usuário
Adicionando role\Owner a uma conta de usuário/serviço
Removendo uma conta de usuário/serviço de role\Owner

Gravidade: Baixa

Certifique-se de que osLogin esteja habilitado para um projeto

Descrição: a ativação do login do sistema operacional vincula certificados SSH a usuários do IAM e facilita o gerenciamento eficaz de certificados SSH. Habilitar o osLogin garante que as chaves SSH usadas para se conectar a instâncias sejam mapeadas com usuários do IAM. Revogar o acesso ao usuário do IAM revogará todas as chaves SSH associadas a esse usuário específico. Ele facilita o gerenciamento centralizado e automatizado de pares de chaves SSH, o que é útil para lidar com casos como resposta a pares de chaves SSH comprometidos e/ou revogação de usuários externos/terceiros/fornecedores. Para descobrir qual instância faz com que o projeto não esteja íntegro, consulte a recomendação "Garantir que o oslogin esteja habilitado para todas as instâncias".

Gravidade: Média

Certifique-se de que osLogin esteja habilitado para todas as instâncias

Gravidade: Média

Certifique-se de que o log de auditoria em nuvem esteja configurado corretamente em todos os serviços e todos os usuários de um projeto

Descrição: é recomendável que o Cloud Audit Logging esteja configurado para acompanhar todas as atividades do administrador e o acesso de leitura e gravação aos dados do usuário.

O log de auditoria em nuvem mantém dois logs de auditoria para cada projeto, pasta e organização: Atividade de administrador e Acesso a dados.

Os logs de Atividade de administrador contêm entradas de log para chamadas à API ou outras ações administrativas que modificam a configuração ou metadados dos recursos.
Os logs de auditoria de atividade do administrador estão habilitados para todos os serviços e não podem ser configurados.
Os logs de auditoria de Acesso a dados registram chamadas à API que criam, modificam ou leem dados fornecidos pelo usuário. Eles são desabilitados por padrão e devem ser habilitados.

Há três tipos de informações de log de auditoria de Acesso a dados:

Leitura do administrador: registra operações que leem informações de configuração ou metadados. Os logs de auditoria de atividade do administrador registram gravações de metadados e informações de configuração que não podem ser desabilitadas.
Leitura de dados: registra operações que leem dados fornecidos pelo usuário.
Gravação de dados: registra operações que gravam dados fornecidos pelo usuário.

É recomendável ter uma configuração de auditoria padrão efetiva configurada de forma que:

O tipo de log é definido como DATA_READ (para registrar o rastreamento de atividades do usuário) e DATA_WRITES (para registrar alterações/adulteração de dados do usuário).
A configuração de auditoria está habilitada para todos os serviços compatíveis com o recurso de logs de auditoria de acesso a dados.
Os logs devem ser capturados para todos os usuários, ou seja, não há usuários isentos em nenhuma das seções de configuração de auditoria. Isso garantirá que a substituição da configuração de auditoria não contrarie o requisito.

Gravidade: Média

Verifique se as chaves criptográficas do Cloud KMS não estão acessíveis de forma anônima ou pública

Descrição: é recomendável que a política do IAM em chaves de criptografia do Cloud KMS restrinja o acesso anônimo e/ou público. Conceder permissões para "allUsers" ou "allAuthenticatedUsers" permite que qualquer pessoa acesse o conjunto de dados. Esse acesso pode não ser desejável se dados confidenciais forem armazenados no local. Nesse caso, verifique se o acesso anônimo e/ou público a uma chave de criptografia do Cloud KMS não é permitido.

Gravidade: Alta

Descrição: use credenciais de login corporativo em vez de contas pessoais, como contas do Gmail. Recomenda-se que as contas corporativas do Google totalmente gerenciadas sejam usadas para aumentar a visibilidade, auditar e controlar o acesso aos recursos do Cloud Platform. As contas do Gmail baseadas fora da organização do usuário, como contas pessoais, não devem ser usadas para fins comerciais.

Gravidade: Alta

Certifique-se de que as funções de Criador de Token de Conta de Serviço ou Usuário de Conta de Serviço não sejam atribuídas a usuários de IAM no nível de projeto

Descrição: é recomendável atribuir as funções "Usuário da conta de serviço (iam.serviceAccountUser)" e "Criador de token da conta de serviço (iam.serviceAccountTokenCreator)" a um usuário para uma conta de serviço específica, em vez de atribuir a função a um usuário no nível do projeto. Uma conta de serviço é uma conta especial do Google que pertence a um aplicativo ou a uma VM (máquina virtual), em vez de a um usuário final individual. A instância de VM/aplicativo usa a conta de serviço para chamar a API do Google do serviço para que os usuários não se envolvam diretamente. Além de ser uma identidade, uma conta de serviço é um recurso que tem políticas de IAM anexadas a ele. Essas políticas determinam quem pode usar a conta de serviço. Os usuários com funções de IAM para atualizar as instâncias do Mecanismo de Aplicativo e do Mecanismo de Computação (como o implantador do Mecanismo de Aplicativo ou o administrador da Instância de Computação) podem efetivamente executar o código como as contas de serviço usadas para executar essas instâncias e obter indiretamente acesso a todos os recursos para os quais as contas de serviço têm acesso. Da mesma forma, o acesso SSH a uma instância do Compute Engine também pode fornecer a capacidade de executar código como essa instância/conta de serviço. Com base nas necessidades de negócios, pode haver várias contas de serviço gerenciadas pelo usuário configuradas para um projeto. Conceder as funções "iam.serviceAccountUser" ou "iam.serviceAserviceAccountTokenCreatorccountUser" a um usuário para um projeto dá ao usuário acesso a todas as contas de serviço no projeto, incluindo contas de serviço que podem ser criadas no futuro. Isso pode resultar na elevação de privilégios usando contas de serviço e "instâncias do Compute Engine" correspondentes. Para implementar as práticas recomendadas de "privilégios mínimos", os usuários do IAM não devem receber as funções "Usuário da conta de serviço" ou "Criador de token da conta de serviço" no nível do projeto. Em vez disso, essas funções devem ser atribuídas a um usuário para uma conta de serviço específica, dando a esse usuário acesso à conta de serviço. A função "Usuário de Conta de Serviço" permite que um usuário associe uma conta de serviço a um serviço de trabalho de longa execução, enquanto a função "Criador de Token de Conta de Serviço" permite que um usuário represente diretamente (ou declare) a identidade de uma conta de serviço.

Gravidade: Média

Descrição: é recomendável que o princípio de "Separação de tarefas" seja aplicado ao atribuir funções relacionadas ao KMS aos usuários. A função interna/predefinida do IAM "Administrador do KMS na Nuvem" permite que o usuário/identidade crie, exclua e gerencie contas de serviço. A função Cloud KMS CryptoKey Encrypter/Decrypter do IAM incorporada/predefinida permite que o usuário/identidade (com privilégios adequados nos recursos em questão) criptografe e descriptografe dados em repouso usando uma chave de criptografia. A função Cloud KMS CryptoKey Encrypter do IAM integrada/predefinida permite que o usuário/identidade (com privilégios adequados nos recursos em questão) criptografe dados em repouso usando uma chave de criptografia. A função Cloud KMS Crypto Key Decrypter do IAM integrada/predefinida permite que o usuário/identidade (com privilégios adequados nos recursos em questão) descriptografe dados em repouso usando uma chave de criptografia. A separação de tarefas é o conceito de garantir que um indivíduo não tenha todas as permissões necessárias para poder concluir uma ação maliciosa. No Cloud KMS, isso pode ser uma ação como usar uma chave para acessar e descriptografar dados aos quais um usuário normalmente não deveria ter acesso. A separação de tarefas é um controle empresarial normalmente usado em organizações maiores, destinado a ajudar a evitar erros e incidentes de segurança ou privacidade. É considerada uma prática recomendada. Nenhum usuário deve ter o administrador do Cloud KMS e qualquer um dos Cloud KMS CryptoKey Encrypter/Decrypterpapéis , Cloud KMS CryptoKey Encrypter, Cloud KMS CryptoKey Decrypter atribuídos ao mesmo tempo.

Gravidade: Alta

Descrição: é recomendável que o princípio de "Separação de Tarefas" seja aplicado ao atribuir funções relacionadas à conta de serviço aos usuários. A função interna/predefinida do IAM "Administrador de Conta de Serviço" permite que o usuário/identidade crie, exclua e gerencie contas de serviço. A função interna/predefinida do IAM "Usuário de Conta de Serviço" permite que o usuário/identidade (com privilégios adequados no Mecanismo de Computação e Aplicativo) atribua contas de serviço a Aplicativos/Instâncias de Computação. A separação de tarefas é o conceito de garantir que um indivíduo não tenha todas as permissões necessárias para poder concluir uma ação maliciosa. No Cloud IAM - contas de serviço, isso pode ser uma ação como usar uma conta de serviço para acessar recursos aos quais o usuário normalmente não deveria ter acesso. A separação de tarefas é um controle empresarial normalmente usado em organizações maiores, destinado a ajudar a evitar erros e incidentes de segurança ou privacidade. É considerada uma prática recomendada. Nenhum usuário deve ter as funções "Administrador de Conta de Serviço" e "Usuário de Conta de Serviço" atribuídas ao mesmo tempo.

Gravidade: Média

Certifique-se de que a conta de serviço não tenha privilégios de administrador

Descrição: uma conta de serviço é uma conta especial do Google que pertence a um aplicativo ou a uma VM, em vez de a um usuário final individual. O aplicativo usa a conta de serviço para chamar a API do Google do serviço para que os usuários não se envolvam diretamente. É recomendável não usar o acesso de administrador para ServiceAccount. As contas de serviço representam a segurança no nível de serviço dos recursos (aplicativo ou VM) que podem ser determinados pelas funções atribuídas a ele. Inscrever ServiceAccount com direitos de administrador dá acesso total a um aplicativo atribuído ou uma VM. Um titular de acesso à ServiceAccount pode executar ações críticas, como excluir, atualizar configurações de alteração, entre outras, sem intervenção do usuário. Por esse motivo, é recomendável que as contas de serviço não tenham direitos de administrador.

Gravidade: Média

Certifique-se de que os coletores estejam configurados para todas as entradas de log

Descrição: é recomendável criar um coletor que exportará cópias de todas as entradas de log. Isso pode ajudar a agregar logs de vários projetos e exportá-los para um SIEM (gerenciamento de eventos e informações de segurança). As entradas de log são mantidas no registro em log do Stackdriver. Para agregar logs, exporte-os para um SIEM. Para mantê-los por mais tempo, é recomendável configurar um coletor de logs. A exportação envolve a gravação de um filtro que seleciona as entradas de log a serem exportadas e a escolha de um destino no armazenamento em nuvem, no BigQuery ou no Pub/Sub do Cloud. O filtro e o destino são mantidos em um objeto chamado coletor. Para garantir que todas as entradas de log sejam exportadas para coletores, verifique se não há nenhum filtro configurado para um coletor. Os coletores podem ser criados em projetos, organizações, pastas e contas de cobrança.

Gravidade: Baixa

Certifique-se de que haja um filtro de métrica de log e alertas para alterações de Configuração de Auditoria

Descrição: os serviços do Google Cloud Platform (GCP) gravam entradas de registro de auditoria nos registros de atividade do administrador e de acesso a dados. As entradas ajudam a responder às perguntas "quem fez o quê, onde e quando?" nos projetos do GCP. As informações de registros de logs de auditoria de nuvem incluem a identidade do autor da chamada à API, a hora da chamada à API, o endereço IP de origem do autor da chamada à API, os parâmetros de solicitação e os elementos de resposta retornados pelo serviço do GCP. O log de auditoria de nuvem fornece um histórico de chamadas à API do GCP para uma conta, incluindo chamadas à API feitas por meio do console, SDKs, ferramentas de linha de comando e outros serviços do GCP. Os logs de atividade e acesso a dados do administrador produzidos pelo log de auditoria na nuvem permitem a análise de segurança, o rastreamento de alterações de recursos e a auditoria de conformidade. Configurar o filtro de métrica e os alertas para alterações de configuração de auditoria garante que o estado recomendado da configuração de auditoria seja mantido para que todas as atividades no projeto sejam auditadas a qualquer momento.

Gravidade: Baixa

Certifique-se de que haja um filtro de métrica de log e alertas para alterações a funções personalizadas

Descrição: é recomendável que um filtro de métrica e um alarme sejam estabelecidos para alterações nas atividades de criação, exclusão e atualização de funções do Identity and Access Management (IAM). O IAM do Google Cloud oferece funções predefinidas que dão acesso granular a recursos específicos do Google Cloud Platform e impedem o acesso indesejado a outros recursos. No entanto, para atender às necessidades específicas da organização, o IAM na Nuvem também oferece a capacidade de criar funções personalizadas. Os proprietários e administradores do projeto com a função Administrador de Funções da Organização ou a função Administrador de Funções do IAM podem criar funções personalizadas. Monitorar atividades de criação, exclusão e atualização de funções ajudará a identificar qualquer função com privilégios excessivos em estágios iniciais.

Gravidade: Baixa

Certifique-se de que as chaves externas/gerenciadas pelo usuário das contas de serviço sejam alternadas a cada 90 dias ou menos

Descrição: as chaves da conta de serviço consistem em um ID de chave (Private_key_Id) e uma chave privada, que são usados para assinar solicitações programáticas que os usuários fazem aos serviços do Google Cloud acessíveis a essa conta de serviço específica. É recomendável que todas as chaves da conta de serviço sejam giradas regularmente. A rotação de chaves de conta de serviço reduzirá a janela de oportunidade para que uma chave de acesso associada a uma conta comprometida ou encerrada seja usada. As chaves da Conta de Serviço devem ser giradas para garantir que os dados não possam ser acessados com uma chave antiga que possa ter sido perdida, quebrada ou roubada. Cada conta de serviço é associada a um par de chaves gerenciado pelo GCP (Google Cloud Platform). Ele é usado para autenticação de serviço a serviço no GCP. O Google gira as chaves diariamente. O GCP oferece a opção de criar um ou mais pares de chaves gerenciados pelo usuário (também chamados de pares de chaves externas) para uso de fora do GCP (por exemplo, para uso com credenciais padrão do aplicativo). Quando um novo par de chaves é criado, o usuário precisa fazer o download da chave privada (que não é retida pelo Google).

Com chaves externas, os usuários são responsáveis por manter a chave privada segura e outras operações de gerenciamento, como rotação de chaves. As chaves externas podem ser gerenciadas pela API do IAM, pela ferramenta de linha de comando gcloud ou pela página de contas de serviço no console do Google Cloud Platform.

O GCP facilita até 10 chaves de conta de serviço externa por conta de serviço para facilitar a alternância de chaves.

Gravidade: Média

As identidades superprovisionadas do GCP devem ter apenas as permissões necessárias (versão prévia)

Descrição: uma identidade ativa superprovisionada é uma identidade que tem acesso a privilégios que não foram usados. Identidades ativas superprovisionadas, especialmente para contas não humanas que têm ações e responsabilidades muito definidas, podem aumentar o raio de explosão no caso de comprometimento de um usuário, chave ou recurso O princípio do privilégio mínimo afirma que um recurso só deve ter acesso aos recursos exatos de que precisa para funcionar. Esse princípio foi desenvolvido para lidar com o risco de identidades comprometidas concederem a um invasor acesso a uma ampla variedade de recursos.

O painel de controle do GKE na web deve ser desabilitado

Descrição: essa recomendação avalia o campo kubernetesDashboard da propriedade addonsConfig para o par de valores-chave, 'disabled': false.

Gravidade: Alta

A Autorização Obsoleta deve ser desabilitada nos clusters do GKE

Descrição: essa recomendação avalia a propriedade legacyAbac de um cluster para o par chave-valor, 'enabled': true.

Gravidade: Alta

As permissões de identidades inativas no seu projeto do GCP devem ser revogadas

Descrição: o Microsoft Defender para Nuvem descobriu uma identidade que não executou nenhuma ação em nenhum recurso no projeto do GCP nos últimos 45 dias. Recomenda-se revogar permissões de identidades inativas, a fim de reduzir a superfície de ataque do seu ambiente de nuvem.

Gravidade: Média

Compartilhar via

Recomendações de segurança de identidade e acesso

Recomendações de identidade e acesso do Azure

Recomendações de identidade e acesso da AWS

Recomendações de identidade e acesso do GCP

Conteúdo relacionado

Comentários

Recursos adicionais