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

Artigo
09/06/2024

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

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 for Cloud.

Gorjeta

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

Por exemplo, a recomendação Falhas de integridade do endpoint protection devem ser corrigidas baseia-se na recomendação de que verifica se uma solução de endpoint protection está instalada (a solução Endpoint protection deve ser instalada). A recomendação subjacente tem uma política. Limitar as políticas apenas a recomendações fundamentais simplifica o gerenciamento de políticas.

Recomendações de identidade e acesso do Azure

Devem ser designados um máximo de 3 proprietários para subscrições

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

Gravidade: Alta

As contas do Azure Cosmos DB devem usar o Azure Ative 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 suporta a capacidade de revogar permissões como um método eficaz de resposta quando comprometido. Você pode configurar sua conta do Azure Cosmos DB para impor o RBAC como o único método de autenticação. Quando a imposição é configurada, todos os outros métodos de acesso serão negados (chaves primárias/secundárias e tokens de acesso). (Nenhuma política relacionada)

Gravidade: Média

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

Descrição: as contas que foram bloqueadas para iniciar sessão no Ative Directory devem ser removidas dos seus recursos do Azure. Essas contas podem ser alvos de invasores que procuram encontrar maneiras de acessar seus dados sem serem notados. (Nenhuma política relacionada)

Gravidade: Alta

Contas bloqueadas com permissões de leitura e gravação em recursos do Azure devem ser removidas

Gravidade: Alta

Contas preteridas devem ser removidas de assinaturas

Descrição: As contas de utilizador que foram bloqueadas para iniciar sessão devem ser removidas das suas subscrições. Essas contas podem ser alvos de invasores que procuram encontrar maneiras de acessar seus dados sem serem notados. (Política relacionada: As contas preteridas devem ser removidas da sua subscrição).

Gravidade: Alta

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

Descrição: As contas de utilizador que foram bloqueadas para iniciar sessão devem ser removidas das suas subscrições. Essas contas podem ser alvos de invasores que procuram encontrar maneiras de acessar seus dados sem serem notados. (Política relacionada: Contas preteridas com permissões de proprietário devem ser removidas da sua assinatura).

Gravidade: Alta

Os logs de diagnóstico no Cofre da Chave devem ser habilitados

Descrição: habilite os logs e mantenha-os por até um ano. Isso permite que você recrie trilhas de atividade para fins de investigação quando ocorre um incidente de segurança ou sua rede é comprometida. (Política relacionada: Os logs de diagnóstico no Cofre da Chave devem ser habilitados).

Gravidade: Baixa

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 subscrição. Isso evita o acesso não monitorado. Essas contas podem ser alvos de invasores que procuram encontrar maneiras de acessar seus dados sem serem notados. (Política relacionada: As contas externas com permissões de proprietário devem ser removidas da sua subscrição).

Gravidade: Alta

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

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

Gravidade: Alta

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

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

Gravidade: Alta

O firewall deve ser ativado no Cofre da Chave

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 apenas o tráfego de redes permitidas possa acessar seu cofre de chaves. (Política relacionada: O firewall deve ser ativado no Cofre da Chave).

Gravidade: Média

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 Ative 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 notados. (Nenhuma política relacionada)

Gravidade: Alta

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 Ative 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 notados. (Nenhuma política relacionada)

Gravidade: Alta

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

Descrição: Contas com permissões de gravação que foram provisionadas fora do locatário do Azure Ative 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 notados. (Nenhuma política relacionada)

Gravidade: Alta

As chaves do Cofre da Chave devem ter uma data de expiração

Descrição: As chaves criptográficas devem ter uma data de validade definida e não ser permanentes. As chaves que são válidas para sempre fornecem a um atacante em 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 Cofre da Chave devem ter uma data de validade).

Gravidade: Alta

Os segredos do Cofre de Chaves devem ter uma data de validade

Descrição: Os segredos devem ter uma data de validade definida e não ser permanentes. Segredos que são válidos para sempre fornecem a um atacante em potencial mais tempo para comprometê-los. É uma prática de segurança recomendada definir datas de validade em segredos. (Política relacionada: Os segredos do Cofre de Chaves devem ter uma data de validade).

Gravidade: Alta

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

Descrição: A exclusão maliciosa de um cofre de chaves pode levar à perda permanente de dados. Um insider mal-intencionado em sua organização pode potencialmente excluir e limpar cofres de chaves. A proteção contra limpeza protege você contra ataques internos, impondo um período de retenção obrigatório para cofres de chaves excluídos por software. Ninguém dentro da sua organização ou da Microsoft poderá limpar seus cofres de chaves durante o período de retenção de exclusão suave. (Política relacionada: Os cofres de chaves devem ter a proteção contra limpeza ativada).

Gravidade: Média

Os cofres de chaves devem ter a exclusão suave ativada

Descrição: A exclusão de um cofre de chaves sem a exclusão automática 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 suave permite que você recupere 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 suave ativada).

Gravidade: Alta

O Microsoft Defender for Key Vault deve estar habilitado

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

As proteções deste plano são cobradas conforme mostrado na página de planos do Defender. Se não tiver cofres de chaves nesta subscrição, não lhe será cobrado. Se, mais tarde, criar cofres de chaves nesta subscrição, estes serão automaticamente protegidos e as cobranças começarão. Saiba mais sobre os detalhes de preços por região. Saiba mais em Introdução ao Microsoft Defender for Key Vault. (Política relacionada: O Azure Defender for 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 for Cloud descobriu uma identidade que não executou nenhuma ação em nenhum recurso dentro da 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

Ponto de extremidade privado deve ser configurado para o Cofre da Chave

Descrição: O link privado fornece uma maneira de conectar o Cofre da Chave aos seus recursos do Azure sem enviar tráfego pela Internet pública. O link privado fornece proteção de defesa em profundidade contra a exfiltração de dados. (Política relacionada: O ponto de extremidade privado deve ser configurado para o Cofre da Chave).

Gravidade: Média

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

Descrição: o acesso público de leitura anónimo a contentores e blobs no Armazenamento do Azure é uma forma conveniente de partilhar 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 seu cenário exija. (Política relacionada: O acesso público da conta de armazenamento deve ser proibido).

Gravidade: Média

Deve haver mais de um proprietário atribuído a 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 os seus certificados não têm um período de validade superior a 12 meses. (Política relacionada: Os certificados devem ter o período de validade máximo especificado).

Gravidade: Média

As identidades superprovisionadas do Azure devem ter apenas as permissões necessárias (Visualização)

Descrição: Identidades superprovisionadas, ou sobre identidades permitidas, não usam muitas das permissões concedidas. Regularmente permissões de tamanho correto dessas identidades para reduzir o risco de uso indevido de permissões, acidentais ou mal-intencionadas. Esta ação diminui o raio de explosão potencial durante um incidente de segurança.

Gravidade: Média

As funções privilegiadas não devem ter acesso permanente ao nível da subscrição e do grupo de recursos

Descrição: o Microsoft Defender for Cloud descobriu uma identidade que não executou nenhuma ação em nenhum recurso dentro da 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 ao nível da subscrição e do grupo de recursos

Descrição: o Defender for Cloud 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 de Usuário. As entidades de serviço desempenham um papel crucial na gestão dos 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 uma determinada entidade de serviço possa desempenhar as suas funções. Os administradores e o acesso privilegiado são o principal alvo dos hackers. Para obter as práticas recomendadas ao usar atribuições de função de administrador privilegiado, consulte Práticas recomendadas para o Azure RBAC. Práticas recomendadas para o Azure RBAC. 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 ponto de extremidade 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 da AWS em 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 do S3 permitir o acesso de contas externas, isso poderá resultar na exfiltração de dados por uma ameaça interna ou um invasor. O parâmetro 'blacklistedactionpatterns' permite uma avaliação bem-sucedida da regra para buckets do S3. O parâmetro concede acesso a contas externas para padrões de ação que não estão incluídos na lista 'blacklistedactionpatterns'.

Gravidade: Alta

Evite o uso da conta "root"

Descrição: a conta "root" tem acesso irrestrito a todos os recursos da conta da AWS. É altamente recomendável que o uso desta conta seja evitado. A conta "raiz" é a conta mais privilegiada da AWS. Minimizar o uso dessa conta e adotar o princípio de menor privilégio 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 involuntariamente

Descrição: esse controle verifica se as chaves KMS estão agendadas para exclusão. O controle falhará se uma chave KMS estiver agendada para exclusão. As chaves KMS não podem ser recuperadas depois de excluídas. Os dados criptografados sob uma chave KMS também serão irrecuperáveis permanentemente se a chave KMS for excluída. Se dados significativos tiverem sido criptografados sob uma chave KMS agendada para exclusão, considere descriptografar os dados ou criptografar novamente os dados sob uma nova chave KMS, a menos que você esteja intencionalmente executando uma eliminação criptográfica. Quando uma chave KMS é agendada para exclusão, um período de espera obrigatório é imposto para permitir tempo para reverter a exclusão, se ela foi agendada por erro. O período de espera padrão é de 30 dias, mas pode ser reduzido para apenas sete dias quando a chave KMS estiver agendada para exclusão. Durante o período de espera, a exclusão agendada pode ser cancelada e a chave KMS não será excluída. Para obter mais informações sobre como excluir chaves KMS, consulte Excluir chaves KMS no AWS Key Management Service Developer Guide.

Gravidade: Alta

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

Descrição: uma identidade ativa provisionada em excesso é uma identidade que tem acesso a privilégios que não foram usados. Identidades ativas provisionadas em excesso, 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 registro global da ACL da web do AWS WAF Classic deve ser 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, disponibilidade e desempenho do AWS WAF globalmente. É um requisito de negócios e conformidade em muitas organizações e permite solucionar 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 ajudá-lo a evitar a exposição do conteúdo da sua 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 Amazon S3 Origin tem o Origin Access Identity (OAI) configurado. O controle falhará se o OAI não estiver configurado. O OAI do CloudFront impede que os usuários acessem o conteúdo do bucket do S3 diretamente. Quando os usuários acessam um bucket do S3 diretamente, eles efetivamente ignoram a distribuição do CloudFront e quaisquer permissões aplicadas ao conteúdo subjacente do bucket do S3.

Gravidade: Média

A validação do arquivo de log do CloudTrail deve ser ativada

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

Gravidade: Baixa

CloudTrail deve ser ativado

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 quaisquer trilhas de auditoria adicionais além do CloudTrail e revisar a documentação de cada serviço em Serviços e integrações suportados pelo CloudTrail.

Gravidade: Alta

As trilhas do CloudTrail devem ser integradas ao CloudWatch Logs

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

Gravidade: Baixa

O log do banco de dados deve ser habilitado

Descrição: esse controle verifica se os seguintes logs do Amazon RDS estão habilitados e são 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, Upgrade). Os bancos de dados RDS devem ter logs relevantes habilitados. O log do banco de dados fornece registros detalhados das solicitações feitas ao RDS. Os logs de banco de dados podem ajudar com auditorias de segurança e acesso e podem ajudar a diagnosticar problemas de disponibilidade.

Gravidade: Média

Desative o acesso direto à Internet para instâncias de notebook do Amazon Sage Maker

Descrição: O acesso direto à Internet deve ser desativado para uma instância de notebook do Sage Maker. Isso verifica se o campo 'DirectInternetAccess' está desabilitado para a instância do bloco de anotações. Sua instância deve ser configurada com uma VPC e a configuração padrão deve ser Desativar - Acessar a Internet por meio de uma VPC. Para habilitar o acesso à Internet para treinar ou hospedar modelos a partir de um notebook, verifique se a VPC tem um gateway NAT e se o security group 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 configure chaves de acesso durante a configuração inicial do usuário para todos os usuários do IAM que tenham uma senha de console

Descrição: o console da AWS padroniza a caixa de seleção para criar chaves de acesso para habilitado. Isso resulta em muitas chaves de acesso sendo geradas desnecessariamente. Além de credenciais desnecessárias, também gera um trabalho de gerenciamento desnecessário na auditoria e rotação dessas chaves. Exigir que etapas adicionais sejam tomadas pelo usuário após sua criação de perfil dará uma indicação mais forte de 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 que as chaves podem estar em uso em algum lugar da organização.

Gravidade: Média

Garantir que uma função de suporte tenha sido criada para gerenciar incidentes com o AWS Support

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 serviços ao cliente. Crie uma função do IAM para permitir que usuários autorizados gerenciem incidentes com o AWS Support. Quando você implementa o menor privilégio para controle de acesso, uma função do IAM requer uma política apropriada do IAM para permitir o acesso ao centro de suporte para gerenciar incidentes com o AWS Support.

Gravidade: Baixa

Certifique-se de que as chaves de acesso são alternadas 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 da AWS precisam de suas próprias chaves de acesso para fazer chamadas programáticas para a AWS a partir da AWS Command Line Interface (AWS CLI), Tools for Windows PowerShell, AWS SDKs ou chamadas HTTP diretas usando as APIs para serviços individuais da AWS. Recomenda-se que todas as teclas de acesso sejam alternadas regularmente. A rotação de chaves de acesso reduz a janela de oportunidade para a utilização de uma chave de acesso associada a uma conta comprometida ou encerrada. As chaves de acesso devem ser alternadas 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

Verifique 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 suportados em sua conta e entrega arquivos de log para você. As informações registradas incluem o item de configuração (recurso da AWS), relações entre itens de configuração (recursos da AWS), quaisquer alterações de configuração entre recursos. É recomendável habilitar o AWS Config em todas as regiões.

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

Gravidade: Média

Verifique se o CloudTrail está ativado 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 registradas incluem a identidade do chamador da API, a hora da chamada da API, o endereço IP de origem do chamador da API, os parâmetros da solicitação e os elementos de resposta retornados pelo serviço da AWS. O CloudTrail fornece um histórico de chamadas de API da AWS para uma conta, incluindo chamadas de API feitas por meio do Console de Gerenciamento, SDKs, ferramentas de linha de comando e serviços de nível superior da AWS (como o CloudFormation). O histórico de chamadas da API da AWS produzido pelo CloudTrail permite análise de segurança, rastreamento de alterações de recursos e auditoria de conformidade. Além disso:

A verificação da existência de uma trilha de várias regiões garante que atividades inesperadas que ocorram em regiões não utilizadas sejam detetadas.
A verificação da existência de uma trilha em 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 de uma conta da AWS.

Gravidade: Alta

Verifique se as credenciais não usadas por 90 dias ou mais estão desativadas

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. A desativação ou remoção de credenciais desnecessárias reduz a janela de oportunidade para que as credenciais associadas a uma conta comprometida ou abandonada sejam usadas.

Gravidade: Média

Verifique se a política de senhas do IAM expira as senhas dentro 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 contra tentativas de login de força bruta. Além disso, exigir alterações regulares de senha ajuda nos seguintes cenários:

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

Gravidade: Baixa

Verifique se a política de senha do IAM impede a reutilização da senha

Descrição: as políticas de senha do IAM podem impedir a reutilização de uma determinada senha pelo mesmo usuário. Recomenda-se que a política de senhas impeça a reutilização de senhas. Impedir a reutilização de senhas aumenta a resiliência da conta contra tentativas de login de força bruta.

Gravidade: Baixa

Verifique se a política de senha do IAM requer 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 a senha seja composta 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 contra tentativas de login de força bruta.

Gravidade: Média

Verifique se a política de senha do IAM requer 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 a senha seja composta 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 contra tentativas de login de força bruta.

Gravidade: Média

Verifique se a política de senha do IAM requer 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 a senha seja composta 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 contra tentativas de login de força bruta.

Gravidade: Média

Verifique se a política de senha do IAM requer 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 a senha seja composta 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 contra tentativas de login de força bruta.

Gravidade: Média

Verifique se a política de senha do IAM requer um comprimento mínimo igual ou superior a 14

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 determinado comprimento. Recomenda-se 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 contra tentativas de login de força bruta.

Gravidade: Média

Verifique se a autenticação multifator (MFA) está habilitada para todos os usuários do IAM que têm uma senha de console

Descrição: A autenticação multifator (MFA) adiciona uma camada extra de proteção sobre 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 o MFA seja habilitado para todas as contas que tenham uma senha de console. A habilitação do MFA oferece maior segurança para o acesso ao console, pois exige que a entidade de autenticação possua um dispositivo que emita uma chave sensível ao tempo e tenha conhecimento de uma credencial.

Gravidade: Média

O GuardDuty deve ser ativado

Descrição: para fornecer proteção adicional contra invasões, o GuardDuty deve ser ativado 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

O MFA de hardware deve ser ativado para a conta "raiz"

Descrição: A conta root é o usuário mais privilegiado em uma conta. MFA adiciona uma camada extra de proteção em cima de um nome de usuário e senha. Com a MFA habilitada, quando um usuário faz login em um site da AWS, ele é solicitado a fornecer seu nome de usuário e senha e um código de autenticação de seu dispositivo AWS MFA. Para o Nível 2, é recomendável que você proteja a conta raiz com um MFA de hardware. Uma MFA de hardware tem uma superfície de ataque menor do que uma MFA virtual. Por exemplo, um MFA de hardware não sofre a superfície de ataque introduzida pelo smartphone móvel em que reside um MFA virtual. Quando você usa hardware para MFA para muitas e muitas contas, isso pode criar um problema de gerenciamento de dispositivo logístico. Se isso ocorrer, considere implementar essa recomendação de Nível 2 seletivamente para as contas de segurança mais altas. 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 RDS

Descrição: esse controle verifica se um cluster de banco de dados RDS tem a autenticação de banco de dados do IAM habilitada. A autenticação de banco de dados do IAM permite a autenticação sem senha para instâncias de banco de dados. A autenticação usa um token de autenticação. O tráfego de rede de e para o banco de dados é criptografado usando SSL. Para obter mais informações, consulte Autenticação de 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 RDS

Descrição: esse controle verifica se uma instância de banco de dados RDS tem a autenticação de banco de dados do IAM habilitada. A autenticação de banco de dados do IAM permite a autenticação em instâncias de banco de dados com um token de autenticação em vez de uma senha. O tráfego de rede de e para o banco de dados é criptografado usando SSL. Para obter mais informações, consulte Autenticação de 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 KMS

Descrição: verifica se a versão padrão das políticas gerenciadas pelo cliente do IAM permite que as entidades 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 nas contas da AWS. Esse controle falhará se as ações "kms: Decrypt" ou "kms: ReEncryptFrom" forem permitidas em todas as chaves KMS. O controle avalia as políticas gerenciadas pelo cliente anexadas e não anexadas. Ele não verifica políticas inline ou políticas gerenciadas pela AWS. Com o AWS KMS, você controla quem pode usar suas chaves KMS e obter acesso aos seus 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 práticas recomendadas de segurança, a 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 pode 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 de que os usuários precisam para acessar dados criptografados. Em seguida, crie políticas que permitam que os usuários usem apenas essas chaves. Por exemplo, não permita a permissão "kms: Desencriptar" em todas as chaves KMS. Em vez disso, permita "kms: Desencriptar" apenas nas chaves de uma região específica para a sua conta. Ao adotar o princípio do menor privilégio, pode reduzir o risco de divulgação não intencional dos seus dados.

Gravidade: Média

As políticas gerenciadas pelo cliente do IAM que você cria não devem permitir ações 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 'Efeito': 'Permitir' com 'Ação': 'Serviço:*'. Por exemplo, a instrução a seguir em uma política resulta em uma descoberta 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 às políticas do IAM gerenciadas pelo cliente. Ele não se aplica a políticas do IAM gerenciadas pela AWS. Ao atribuir 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 forem anexadas a uma entidade 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 passa se você usar uma ação prefixada do IAM com um curinga sufixo. Por exemplo, a seguinte instrução em uma política resulta em uma descoberta aprovada.

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

Ao agrupar ações relacionadas do IAM dessa maneira, 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 apenas a grupos ou funções

Descrição: por padrão, usuários, grupos e funções do IAM não têm acesso aos recursos da AWS. As políticas do IAM são o meio pelo qual 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. A atribuição de privilégios no nível de grupo ou função reduz a complexidade do gerenciamento de acesso à medida que o número de usuários cresce. A redução da complexidade do gerenciamento de acesso também pode reduzir a oportunidade de uma entidade de segurança receber ou reter inadvertidamente privilégios excessivos.

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 o meio pelo qual os privilégios são concedidos a usuários, grupos ou funções. É recomendado e considerado um conselho de segurança padrão conceder 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 para eles que permitam que os usuários 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 brandas e depois tentar apertá-las mais tarde. Fornecer privilégios administrativos completos em vez de restringir ao conjunto mínimo de permissões que o usuário é obrigado a fazer expõe os recursos a ações potencialmente indesejadas. As políticas do IAM que têm uma instrução com "Efeito": "Permitir" com "Ação": "" sobre "Recurso": "" devem ser removidas.

Gravidade: Alta

Os principais do IAM não devem ter políticas inline do IAM que permitam ações de descriptografia em todas as chaves KMS

Descrição: verifica se as políticas embutidas em suas identidades do IAM (função, usuário ou grupo) permitem as ações de descriptografia do AWS KMS em todas as chaves 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 nas contas da AWS. Esse controle falhará se kms:Decrypt ou kms:ReEncryptFrom as ações forem permitidas em todas as chaves KMS em uma política embutida. Com o AWS KMS, você controla quem pode usar suas chaves KMS e obter acesso aos seus 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 práticas recomendadas de segurança, a AWS recomenda que você permita privilégios mínimos. Em outras palavras, você deve conceder às identidades apenas as permissões de que elas precisam e apenas para as chaves necessárias para executar uma tarefa. Caso contrário, o usuário pode 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 de que os usuários precisam para acessar dados criptografados. Em seguida, crie políticas que permitam que os usuários usem apenas essas chaves. Por exemplo, não permita kms:Decrypt permissão em todas as chaves KMS. Em vez disso, permita-os apenas nas chaves de uma região específica para a sua conta. Ao adotar o princípio do menor privilégio, pode reduzir o risco de divulgação não intencional dos seus dados.

Gravidade: Média

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

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

Gravidade: Alta

MFA deve ser habilitado para todos os usuários do IAM

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

Gravidade: Média

MFA deve ser habilitado para a conta "root"

Descrição: A conta root é o usuário mais privilegiado em uma conta. MFA adiciona uma camada extra de proteção em cima de um nome de usuário e senha. Com a MFA habilitada, quando um usuário faz login em um site da AWS, ele é solicitado a fornecer seu nome de usuário e senha e um código de autenticação de seu dispositivo 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ê consegue manter carregado e seguro independentemente de quaisquer dispositivos pessoais individuais. Isso diminui os riscos de perder o acesso ao MFA devido à perda do dispositivo, troca de dispositivo ou se o indivíduo que possui o dispositivo não estiver mais empregado na 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 de conta para usuários do IAM usa as seguintes configurações mínimas.

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- Exija 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 palavras-passe 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 for Cloud 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 root não deve existir

Descrição: a conta root é o usuário mais privilegiado em uma conta da AWS. As chaves de acesso da AWS fornecem acesso programático a uma determinada conta da AWS. Recomenda-se que todas as chaves de acesso associadas à conta root sejam removidas. A remoção das chaves de acesso associadas à conta root 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ção que são menos privilegiadas.

Gravidade: Alta

A configuração de Bloquear Acesso Público do S3 deve ser ativada

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

Gravidade: Média

A configuração de Acesso Público de Bloco do S3 deve ser 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 estiver definida como false:

ignorarPublicAcls
blockPublicPolicy
blockPublicAcls
restrictPublicBuckets Bloquear o 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 listas de controle de acesso (ACLs), políticas de bucket ou ambos. A menos que você pretenda ter seus buckets do S3 acessíveis publicamente, configure o recurso de acesso público de bloco do Amazon S3 no nível do bucket.

Gravidade: Alta

O acesso público de leitura dos buckets do 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 do S3 deve ser removido

Descrição: Permitir o acesso público de gravação ao seu 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 Gestor de Segredos devem ter a rotação automática ativada

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

Gravidade: Média

As instâncias do EC2 interrompidas devem ser removidas após um período de tempo 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 de tempo máximo permitido, que por padrão é de 30 dias. Uma descoberta com falha indica que uma instância do EC2 não foi executada por um período de tempo 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 com segurança uma instância do EC2 ao longo do tempo em um estado não em execução, inicie-a periodicamente para manutenção e, em seguida, interrompa-a após a manutenção. O ideal é que este seja um processo automatizado.

Gravidade: Média

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

Descrição: As 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 deteção e a resposta proativas a identidades não utilizadas ajudam a impedir que entidades não autorizadas tenham acesso aos 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 utilizadores

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

Gravidade: Média

Garantir que as chaves de API não sejam criadas para um projeto

Descrição: As chaves são inseguras porque podem ser visualizadas publicamente, por exemplo, a partir de um navegador, ou podem ser acedidas num dispositivo onde a chave reside. Em vez disso, recomenda-se 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 cadeias de caracteres 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 são normalmente 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

Verifique se as chaves de API estão restritas apenas às APIs que o aplicativo precisa acessar

Descrição: As chaves de API são inseguras porque podem ser visualizadas publicamente, como a partir de um navegador, ou podem ser acedidas num dispositivo onde 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 estão abaixo:

As chaves de API são cadeias de caracteres 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 são normalmente acessíveis aos clientes, facilitando a descoberta e o roubo de uma chave de API

À luz desses riscos potenciais, o Google recomenda o uso do 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 móvel que precise usar a API do Google Cloud Translation, mas não precise de um servidor de back-end, as chaves de API serão a maneira mais simples de autenticar essa API.

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

Gravidade: Alta

Certifique-se de que as chaves de API são restritas ao uso apenas por 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 onde 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 cadeias de caracteres 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 são normalmente 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

Garantir que as chaves de API sejam alternadas a cada 90 dias

Descrição: Recomenda-se girar 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 cadeias de caracteres 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 são normalmente acessíveis aos clientes, facilitando a descoberta e o roubo de uma chave de API

Devido a esses riscos potenciais, o Google recomenda o uso do 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 móvel que precise usar a API do Google Cloud Translation, mas não precise de um servidor de back-end, as chaves de API serão a maneira mais simples de autenticar essa API.

Uma vez que uma chave é roubada, ela não tem validade, 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 de 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 alternadas para garantir que os dados não possam ser acessados com uma chave antiga que possa ter sido perdida, quebrada ou roubada.

Gravidade: Alta

Verifique se as chaves de criptografia KMS são alternadas dentro de um período de 90 dias

Descrição: O Google Cloud Key Management Service armazena chaves criptográficas numa estrutura hierárquica concebida para uma gestão de controlo de acesso útil e elegante. O formato da agenda de rotação depende da biblioteca de cliente 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 ser na forma "INTEGER[UNIT]", onde as unidades podem ser um de segundos (s), minutos (m), horas (h) ou dias (d). Defina um período de rotação de chaves e uma hora de início. Uma chave pode ser criada com um "período de rotação" especificado, que é o tempo entre quando novas versões de chave são geradas automaticamente. Uma chave também pode ser criada com um próximo tempo de rotação especificado. 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 ao longo do tempo à medida que novas versões de chave são criadas. Uma chave é usada para proteger alguns "corpus de dados". Uma coleção de ficheiros pode ser encriptada com a mesma chave e as pessoas com permissões de "desencriptação" nessa chave seriam capazes de desencriptar esses ficheiros. Portanto, é necessário certificar-se de que o "período de rotação" está definido para um horário específico.

Gravidade: Média

Garantir a existência de métrica de log, filtro e alertas para atribuições/alterações de propriedade do projeto

Descrição: A fim de evitar atribuições desnecessárias de propriedade do projeto a usuários/contas de serviço e novos usos indevidos de projetos e recursos, todas as atribuições de "funções/proprietário" devem ser monitoradas. 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 ao qual a função pertence. Estes são resumidos abaixo:

Todas as permissões de visualizador em todos os Serviços GCP dentro do projeto
Permissões para ações que modificam o estado de todos os serviços GCP dentro do projeto
Gerenciar funções e permissões para um projeto e todos os recursos dentro do projeto
Configurar a cobrança 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 de Gerenciamento de Identidade e Acesso (IAM). Portanto, conceda a função de proprietário somente se o membro tiver um propósito legítimo para gerenciar a política do IAM. Isso ocorre porque a política do 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 mais alto nível de privilégios em um projeto. Para evitar uma utilização abusiva dos recursos do projeto, as ações de atribuição/alteração da propriedade do projeto acima mencionadas devem ser monitorizadas e alertadas para os destinatários em causa.
Envio de convites de propriedade do projeto
Aceitação/Rejeição do convite de propriedade do projeto pelo usuário
Adicionar role\Owner a uma conta de utilizador/serviço
Remover uma conta de utilizador/Serviço de role\Owner

Gravidade: Baixa

Verifique se o oslogin está habilitado para um projeto

Descrição: Habilitar o login do sistema operacional vincula certificados SSH aos usuários do IAM e facilita o gerenciamento eficaz de certificados SSH. A ativação do osLogin garante que as chaves SSH usadas para se conectar às instâncias sejam mapeadas com os 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/de terceiros/fornecedores. Para descobrir qual instância faz com que o projeto não esteja íntegro, consulte a recomendação "Verifique se o oslogin está habilitado para todas as instâncias".

Gravidade: Média

Verifique se o oslogin está ativado para todas as instâncias

Gravidade: Média

Certifique-se de que o Cloud Audit Logging esteja configurado corretamente em todos os serviços e em todos os usuários de um projeto

Descrição: Recomenda-se que o Cloud Audit Logging esteja configurado para controlar todas as atividades administrativas e ler e gravar o acesso aos dados do usuário.

O Cloud Audit Logging mantém dois logs de auditoria para cada projeto, pasta e organização: Atividade do administrador e Acesso a dados.

Os logs de atividade do administrador contêm entradas de log para chamadas de API ou outras ações administrativas que modificam a configuração ou os 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 de API que criam, modificam ou leem dados fornecidos pelo usuário. Eles são desativados 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 metadados ou informações de configuração. Os registros de auditoria de atividade do administrador registram gravações de metadados e informações de configuração que não podem ser desabilitadas.
Dados lidos: registra operações que leem dados fornecidos pelo usuário.
Gravação de dados: registra operações que gravam dados fornecidos pelo usuário.

Recomenda-se ter uma configuração de auditoria padrão eficaz configurada de tal 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ções nos dados do usuário).
A configuração de auditoria está habilitada para todos os serviços suportados pelo 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 contradiga o requisito.

Gravidade: Média

Certifique-se de que as chaves de criptografia do Cloud KMS não sejam anônimas ou acessíveis publicamente

Descrição: é recomendável que a política do IAM em chaves de criptografia Cloud KMS restrinja o acesso anônimo e/ou público. Conceder permissões a "allUsers" ou "allAuthenticatedUsers" permite que qualquer pessoa acesse o conjunto de dados. Esse acesso pode não ser desejável se dados sensíveis forem armazenados no local. Nesse caso, certifique-se de que o acesso anônimo e/ou público a uma chave de criptografia do Cloud KMS não seja 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, a auditoria e o controle de acesso aos recursos da Cloud Platform. As contas do Gmail baseadas fora da organização do utilizador, como contas pessoais, não devem ser utilizadas para fins comerciais.

Gravidade: Alta

Certifique-se de que os usuários do IAM não recebam as funções de Usuário da Conta de Serviço ou Criador de Token de Conta de Serviço no nível do projeto

Descrição: é recomendável atribuir as funções "Usuário da Conta de Serviço (iam.serviceAccountUser)" e "Criador de Token de 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 máquina virtual (VM), em vez de a um usuário final individual. Application/VM-Instance usa a conta de serviço para chamar a API do Google do serviço para que os usuários não estejam diretamente envolvidos. Além de ser uma identidade, uma conta de serviço é um recurso que tem políticas do IAM anexadas a ela. Essas políticas determinam quem pode usar a conta de serviço. Os usuários com funções do IAM para atualizar as instâncias do App Engine e do Compute Engine (como o App Engine Deployer ou o Compute Instance Admin) podem executar efetivamente o código como as contas de serviço usadas para executar essas instâncias e, indiretamente, obter acesso a todos os recursos aos 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 conta de instância/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 correspondentes "instâncias do Compute Engine". 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. O "Usuário da Conta de Serviço" permite que um usuário vincule 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 afirme) a identidade de uma conta de serviço.

Gravidade: Média

Descrição: Recomenda-se que o princípio de "Separação de Funções" seja aplicado ao atribuir funções relacionadas ao KMS aos usuários. A função integrada do IAM "Cloud KMS Admin" permite que o usuário/identidade crie, exclua e gerencie contas(ões) 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 integrada / predefinida do IAM permite que o usuário/identidade (com privilégios adequados nos recursos envolvidos) descriptografe dados em repouso usando uma chave de criptografia. Separação de funções é o conceito de garantir que um indivíduo não tenha todas as permissões necessárias para ser capaz de 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 funções é um controle de negócios normalmente usado em organizações maiores, destinado a ajudar a evitar incidentes e erros de segurança ou privacidade. É considerada a melhor prática. Nenhum usuário deve ter Cloud KMS Admin e qualquer uma Cloud KMS CryptoKey Encrypter/Decrypterdas funções , Cloud KMS CryptoKey Encrypter, Cloud KMS CryptoKey Decrypter atribuídas ao mesmo tempo.

Gravidade: Alta

Descrição: recomenda-se que o princípio de "Separação de Funções" seja aplicado ao atribuir funções relacionadas à conta de serviço aos usuários. A função integrada / predefinida do IAM "Administrador da conta de serviço" permite que o usuário/identidade crie, exclua e gerencie a(s) conta(s) de serviço. A função integrada / predefinida do IAM "Usuário da conta de serviço" permite que o usuário/identidade (com privilégios adequados no Compute e no App Engine) atribua conta(s) de serviço a Apps/Compute Instances. Separação de funções é o conceito de garantir que um indivíduo não tenha todas as permissões necessárias para ser capaz de 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 funções é um controle de negócios normalmente usado em organizações maiores, destinado a ajudar a evitar incidentes e erros de segurança ou privacidade. É considerada a melhor prática. Nenhum usuário deve ter as funções "Administrador da Conta de Serviço" e "Usuário da Conta de Serviço" atribuídas ao mesmo tempo.

Gravidade: Média

Verifique se a Conta de Serviço não tem privilégios de administrador

Descrição: uma conta de serviço é uma Conta do Google especial 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 estejam diretamente envolvidos. É recomendável não usar o acesso de administrador para ServiceAccount. As contas de serviço representam a segurança de nível de serviço dos Recursos (aplicativo ou VM), que pode ser determinada pelas funções atribuídas a ele. Registrar ServiceAccount com direitos de administrador dá acesso total a um aplicativo atribuído ou a uma VM. Um titular de acesso ServiceAccount pode executar ações críticas, como excluir, atualizar configurações de alteração, etc., sem a 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

Verifique se os coletores estão 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 Informações e Eventos de Segurança). As entradas de log são mantidas no Stackdriver Logging. Para agregar logs, exporte-os para um SIEM. Para mantê-los por mais tempo, é recomendável configurar um coletor de log. A exportação envolve escrever um filtro que seleciona as entradas de log a serem exportadas e escolher um destino no Cloud Storage, BigQuery ou Cloud Pub/Sub. 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

Verifique se a métrica de log, o filtro e os alertas existem para alterações na Configuração de Auditoria

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

Gravidade: Baixa

Verifique se a métrica de log, o filtro e os alertas existem para alterações de função personalizada

Descrição: é recomendável estabelecer um filtro métrico e um alarme para alterações nas atividades de criação, exclusão e atualização de funções do Gerenciamento de Identidade e Acesso (IAM). O Google Cloud IAM fornece 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 Cloud IAM também oferece a capacidade de criar funções personalizadas. Os proprietários e administradores de projetos com a função de Administrador de Função da Organização ou a função de Administrador de Função do IAM podem criar funções personalizadas. O acompanhamento das atividades de criação, supressão e atualização de funções ajudará a identificar qualquer papel sobreprivilegiado nas fases iniciais.

Gravidade: Baixa

Garantir que as chaves gerenciadas pelo usuário/externas para 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 usadas para assinar solicitações programáticas que os usuários fazem aos serviços de nuvem do Google acessíveis a essa conta de serviço específica. Recomenda-se que todas as chaves da Conta de Serviço sejam alternadas regularmente. A rotação das chaves da 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 alternadas 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 está associada a um par de chaves gerido pelo Google Cloud Platform (GCP). Ele é usado para autenticação de serviço a serviço dentro do GCP. O Google gira as teclas 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 fora do GCP (por exemplo, para uso com credenciais padrão do aplicativo). Quando um novo par de chaves é criado, o usuário é obrigado a 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 a 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 Contas de serviço no Console do Google Cloud Platform.

O GCP facilita até 10 chaves de conta de serviço externas por conta de serviço para facilitar a rotação de chaves.

Gravidade: Média

As identidades superprovisionadas do GCP devem ter apenas as permissões necessárias (Visualização)

Descrição: uma identidade ativa provisionada em excesso é uma identidade que tem acesso a privilégios que não foram usados. Identidades ativas provisionadas em excesso, 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 menor privilégio 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 concedendo a um invasor acesso a uma ampla gama de recursos.

O painel da web GKE deve ser desativado

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

Gravidade: Alta

A autorização herdada deve ser desativada em clusters GKE

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

Gravidade: Alta

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

Descrição: O Microsoft Defender for Cloud descobriu uma identidade que não executou nenhuma ação em nenhum recurso dentro do seu projeto 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

Partilhar 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údos relacionados

Comentários

Recursos adicionais