Recomendações de segurança de dados

Este artigo lista todas as recomendações de segurança de dados 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 dados do Azure

O Azure Cosmos DB deve desabilitar o acesso à rede pública

Descrição: desabilitar o acesso à rede pública melhora a segurança, garantindo que sua conta do Cosmos DB não seja exposta na Internet pública. A criação de pontos de extremidade privados pode limitar a exposição da conta do Cosmos DB. Saiba mais. (Política relacionada: o Azure Cosmos DB deve desabilitar o acesso à rede pública).

Gravidade: Média

(Ativar se necessário) As contas do Azure Cosmos DB devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso

Descrição: as recomendações para usar chaves gerenciadas pelo cliente para criptografia de dados em repouso não são avaliadas por padrão, mas estão disponíveis para habilitar em cenários aplicáveis. Os dados são criptografados automaticamente usando chaves gerenciadas pela plataforma, portanto, o uso de chaves gerenciadas pelo cliente só deve ser aplicado quando for obrigatório por conformidade ou requisitos de política restritivos. Para habilitar essa recomendação, navegue até a Política de segurança para o escopo aplicável e atualize o parâmetro de Efeito para a política correspondente para auditar ou exigir o uso de chaves gerenciadas pelo cliente. Saiba mais em Gerenciar políticas de segurança. Use chaves gerenciadas pelo cliente para gerenciar a criptografia em repouso do seu Azure Cosmos DB. Por padrão, os dados são criptografados em repouso com chaves gerenciadas pelo serviço, mas as CMK (chaves gerenciada pelo cliente) normalmente são necessárias para atender aos padrões de conformidade regulatória. CMKs permitem que os dados sejam criptografados com uma chave do Azure Key Vault criada por você e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo rotação e gerenciamento. Saiba mais sobre a criptografia CMK em https://aka.ms/cosmosdb-cmk. (Política relacionada: As contas do Azure Cosmos DB devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso).

Gravidade: Baixa

(Ativar se necessário) Os workspaces do Azure Machine Learning devem ser criptografados com uma CMK (chave gerenciada pelo cliente)

Descrição: as recomendações para usar chaves gerenciadas pelo cliente para criptografia de dados em repouso não são avaliadas por padrão, mas estão disponíveis para habilitar em cenários aplicáveis. Os dados são criptografados automaticamente usando chaves gerenciadas pela plataforma, portanto, o uso de chaves gerenciadas pelo cliente só deve ser aplicado quando for obrigatório por conformidade ou requisitos de política restritivos. Para habilitar essa recomendação, navegue até a Política de segurança para o escopo aplicável e atualize o parâmetro de Efeito para a política correspondente para auditar ou exigir o uso de chaves gerenciadas pelo cliente. Saiba mais em Gerenciar políticas de segurança. Gerencie a criptografia em repouso dos dados do seu workspace do Azure Machine Learning com CMK (chaves gerenciadas pelo cliente). Por padrão, os dados do cliente são criptografados com chaves gerenciadas pelo serviço, mas as CMK normalmente são necessárias para atender aos padrões de conformidade regulatória. CMKs permitem que os dados sejam criptografados com uma chave do Azure Key Vault criada por você e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo rotação e gerenciamento. Saiba mais sobre a criptografia CMK em https://aka.ms/azureml-workspaces-cmk. (Política relacionada: Os workspaces do Azure Machine Learning devem ser criptografados com uma CMK (chave gerenciada pelo cliente)).

Gravidade: Baixa

O Banco de Dados SQL do Azure deve estar executando o TLS versão 1.2 ou mais recente

Descrição: definir a versão do TLS como 1.2 ou mais recente melhora a segurança, garantindo que o Banco de Dados SQL do Azure só possa ser acessado de clientes que usam o TLS 1.2 ou mais recente. O uso de versões do TLS inferiores à 1.2 não é recomendado, pois elas têm vulnerabilidades de segurança bem documentadas. (Política relacionada: o Banco de Dados SQL do Azure deve executar o TLS versão 1.2 ou mais recente).

Gravidade: Média

As Instâncias Gerenciadas de SQL do Azure devem desabilitar o acesso à rede pública

Descrição: desabilitar o acesso à rede pública (ponto de extremidade público) em Instâncias Gerenciadas de SQL do Azure melhora a segurança, garantindo que elas só possam ser acessadas de dentro de suas redes virtuais ou por meio de Pontos de Extremidade Privados. Saiba mais sobre o acesso à rede pública. (Política relacionada: as Instâncias Gerenciadas de SQL do Azure devem desabilitar o acesso à rede pública).

Gravidade: Média

As contas do Cosmos DB devem usar um link privado

Descrição: o Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Quando os pontos de extremidade privados são mapeados para sua conta do Cosmos DB, os riscos de vazamento de dados são reduzidos. Saiba mais sobre os links privados. (Política relacionada: as contas do Cosmos DB devem usar um link privado).

Gravidade: Média

(Ativar se necessário) Os servidores MySQL devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso

Descrição: as recomendações para usar chaves gerenciadas pelo cliente para criptografia de dados em repouso não são avaliadas por padrão, mas estão disponíveis para habilitar em cenários aplicáveis. Os dados são criptografados automaticamente usando chaves gerenciadas pela plataforma, portanto, o uso de chaves gerenciadas pelo cliente só deve ser aplicado quando for obrigatório por conformidade ou requisitos de política restritivos. Para habilitar essa recomendação, navegue até a Política de segurança para o escopo aplicável e atualize o parâmetro de Efeito para a política correspondente para auditar ou exigir o uso de chaves gerenciadas pelo cliente. Saiba mais em Gerenciar políticas de segurança. Use chaves gerenciadas pelo cliente para gerenciar a criptografia em repouso de seus servidores MySQL. Por padrão, os dados são criptografados em repouso com chaves gerenciadas pelo serviço, mas as CMK (chaves gerenciada pelo cliente) normalmente são necessárias para atender aos padrões de conformidade regulatória. CMKs permitem que os dados sejam criptografados com uma chave do Azure Key Vault criada por você e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo rotação e gerenciamento. (Política relacionada: A proteção de dados Bring your own key deve ser habilitada para servidores MySQL).

Gravidade: Baixa

(Ativar se necessário) Os servidores PostgreSQL devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso

Descrição: as recomendações para usar chaves gerenciadas pelo cliente para criptografia de dados em repouso não são avaliadas por padrão, mas estão disponíveis para habilitar em cenários aplicáveis. Os dados são criptografados automaticamente usando chaves gerenciadas pela plataforma, portanto, o uso de chaves gerenciadas pelo cliente só deve ser aplicado quando for obrigatório por conformidade ou requisitos de política restritivos. Para habilitar essa recomendação, navegue até a Política de segurança para o escopo aplicável e atualize o parâmetro de Efeito para a política correspondente para auditar ou exigir o uso de chaves gerenciadas pelo cliente. Saiba mais em Gerenciar políticas de segurança. Use chaves gerenciadas pelo cliente para gerenciar a criptografia em repouso de seus servidores PostgreSQL. Por padrão, os dados são criptografados em repouso com chaves gerenciadas pelo serviço, mas as CMK (chaves gerenciada pelo cliente) normalmente são necessárias para atender aos padrões de conformidade regulatória. CMKs permitem que os dados sejam criptografados com uma chave do Azure Key Vault criada por você e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo rotação e gerenciamento. (Política relacionada: A proteção de dados Bring your own key deve ser habilitada para servidores PostgreSQL).

Gravidade: Baixa

(Ativar se necessário) As instâncias gerenciadas de SQL devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso

Descrição: as recomendações para usar chaves gerenciadas pelo cliente para criptografia de dados em repouso não são avaliadas por padrão, mas estão disponíveis para habilitar em cenários aplicáveis. Os dados são criptografados automaticamente usando chaves gerenciadas pela plataforma, portanto, o uso de chaves gerenciadas pelo cliente só deve ser aplicado quando for obrigatório por conformidade ou requisitos de política restritivos. Para habilitar essa recomendação, navegue até a Política de segurança para o escopo aplicável e atualize o parâmetro de Efeito para a política correspondente para auditar ou exigir o uso de chaves gerenciadas pelo cliente. Saiba mais em Gerenciar políticas de segurança. Implementar a TDE (Transparent Data Encryption) com chave própria proporciona maior transparência e controle sobre o protetor de TDE, mais segurança com um serviço externo com suporte a HSM e promoção de separação de tarefas. Essa recomendação se aplica a organizações com um requisito de conformidade relacionado. (Política relacionada: As instâncias gerenciadas de SQL devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso).

Gravidade: Baixa

(Ativar se necessário) Os servidores SQL devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso

Descrição: as recomendações para usar chaves gerenciadas pelo cliente para criptografia de dados em repouso não são avaliadas por padrão, mas estão disponíveis para habilitar em cenários aplicáveis. Os dados são criptografados automaticamente usando chaves gerenciadas pela plataforma, portanto, o uso de chaves gerenciadas pelo cliente só deve ser aplicado quando for obrigatório por conformidade ou requisitos de política restritivos. Para habilitar essa recomendação, navegue até a Política de segurança para o escopo aplicável e atualize o parâmetro de Efeito para a política correspondente para auditar ou exigir o uso de chaves gerenciadas pelo cliente. Saiba mais em Gerenciar políticas de segurança. Implementar a TDE (Transparent Data Encryption) com sua chave proporciona maior transparência e controle sobre o protetor de TDE, mais segurança com um serviço externo com suporte a HSM e promoção de separação de tarefas. Essa recomendação se aplica a organizações com um requisito de conformidade relacionado. (Política relacionada: Os servidores SQL devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso).

Gravidade: Baixa

(Ativar se necessário) As contas de armazenamento devem usar a CMK (chave gerenciada pelo cliente) para criptografia

Descrição: as recomendações para usar chaves gerenciadas pelo cliente para criptografia de dados em repouso não são avaliadas por padrão, mas estão disponíveis para habilitar em cenários aplicáveis. Os dados são criptografados automaticamente usando chaves gerenciadas pela plataforma, portanto, o uso de chaves gerenciadas pelo cliente só deve ser aplicado quando for obrigatório por conformidade ou requisitos de política restritivos. Para habilitar essa recomendação, navegue até a Política de segurança para o escopo aplicável e atualize o parâmetro de Efeito para a política correspondente para auditar ou exigir o uso de chaves gerenciadas pelo cliente. Saiba mais em Gerenciar políticas de segurança. Proteja sua conta de armazenamento com maior flexibilidade usando CMKs (chaves gerenciadas pelo cliente). Quando você especifica uma CMK, essa chave é usada para proteger e controlar o acesso à chave que criptografa os dados. Usar CMKs fornece funcionalidades adicionais para controlar a rotação da principal chave de criptografia ou para apagar dados criptograficamente. (Política relacionada: As contas de armazenamento devem usar a CMK (chave gerenciada pelo cliente) para criptografia).

Gravidade: Baixa

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

Todos os tipos de proteção avançada contra ameaças devem ser habilitados nas configurações de segurança de dados avançada da instância gerenciada do SQL

Descrição: é recomendável habilitar todos os tipos de proteção avançada contra ameaças em suas instâncias gerenciadas de SQL. Habilite todos os tipos de proteção para proteger contra injeção de SQL, vulnerabilidades de banco de dados e qualquer outra atividade anômala. (Não há política relacionada)

Gravidade: Média

Todos os tipos de proteção avançada contra ameaças devem ser habilitados nas configurações de segurança de dados avançada do SQL Server

Descrição: é recomendável habilitar todos os tipos avançados de proteção contra ameaças em seus servidores SQL. Habilite todos os tipos de proteção para proteger contra injeção de SQL, vulnerabilidades de banco de dados e qualquer outra atividade anômala. (Não há política relacionada)

Gravidade: Média

Os serviços do Gerenciamento de API devem usar uma rede virtual

Descrição: a implantação da Rede Virtual do Azure fornece segurança aprimorada, isolamento e permite que você coloque seu serviço de Gerenciamento de API em uma rede roteável que não seja da Internet à qual você controla o acesso. Essas redes podem ser conectadas às suas redes locais usando várias tecnologias de VPN, o que permite o acesso aos seus serviços de back-end na rede e/ou locais. O portal do desenvolvedor e o gateway de API podem ser configurados para serem acessados pela Internet ou somente na rede virtual. (Política relacionada: Os serviços de Gerenciamento de API devem usar uma rede virtual).

Gravidade: Média

A Configuração de Aplicativos deve usar um link privado

Descrição: o Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de link privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Mapeando seus pontos de extremidade privados para suas instâncias de configuração de aplicativos, em vez de todo o serviço, você também estará protegido contra riscos de vazamento de dados. Saiba mais em: https://aka.ms/appconfig/private-endpoint. (Política relacionada: A Configuração de Aplicativos deve usar link privado).

Gravidade: Média

A retenção de auditoria para servidores SQL deve ser definida em pelo menos 90 dias

Descrição: Audite servidores SQL configurados com um período de retenção de auditoria inferior a 90 dias. (Política relacionada: Servidores SQL devem ser configurados com 90 dias ou mais de retenção de auditoria.)

Gravidade: Baixa

A auditoria no SQL Server deve ser habilitada

Descrição: habilite a auditoria no SQL Server para acompanhar as atividades do banco de dados em todos os bancos de dados no servidor e salvá-las em um log de auditoria. (Política relacionada: A auditoria no SQL Server deve ser habilitada).

Gravidade: Baixa

O provisionamento automático do agente do Log Analytics deve ser habilitado em assinaturas

Descrição: para monitorar vulnerabilidades e ameaças de segurança, o Microsoft Defender para Nuvem coleta dados de suas máquinas virtuais do Azure. Os dados são coletados pelo agente do Log Analytics, anteriormente conhecido como MMA (Microsoft Monitoring Agent), que lê várias configurações e logs de eventos relacionados à segurança do computador e copia os dados para o seu workspace do Log Analytics para análise. É recomendável habilitar o provisionamento automático para implantar automaticamente o agente em todas as VMs do Azure com suporte e nas VMs que forem criadas. (Política relacionada: O provisionamento automático do agente do Log Analytics deve ser habilitado em sua assinatura).

Gravidade: Baixa

O Cache do Azure para Redis deve residir em uma rede virtual

Descrição: a implantação da VNet (Rede Virtual) do Azure fornece segurança e isolamento aprimorados para o Cache do Azure para Redis, bem como sub-redes, políticas de controle de acesso e outros recursos para restringir ainda mais o acesso. Quando uma instância do Cache do Azure para Redis é configurada com uma rede virtual, ela não é endereçável publicamente e somente pode ser acessada de máquinas virtuais e aplicativos dentro da rede virtual. (Política relacionada: O Cache do Azure para Redis deve residir em uma rede virtual).

Gravidade: Média

O Banco de Dados do Azure para MySQL deve ter um administrador do Azure Active Directory provisionado

Descrição: provisione um administrador do Azure AD para o Banco de Dados do Azure para MySQL para habilitar a autenticação do Azure AD. A autenticação do Azure AD permite o gerenciamento simplificado de permissões e o gerenciamento centralizado de identidades de usuários de banco de dados e outros serviços da Microsoft (Política relacionada: um administrador do Azure Active Directory deve ser provisionado para servidores MySQL).

Gravidade: Média

O Banco de Dados do Azure para PostgreSQL deve ter um administrador do Azure Active Directory provisionado

Descrição: provisione um administrador do Azure AD para o Banco de Dados do Azure para PostgreSQL para habilitar a autenticação do Azure AD. A autenticação do Microsoft Azure Active Directory permite o gerenciamento simplificado de permissões e o gerenciamento centralizado de identidades dos usuários de banco de dados e de outros serviços da Microsoft
(Política relacionada: Um administrador do Azure Active Directory deve ser provisionado para servidores PostgreSQL).

Gravidade: Média

O servidor flexível do Banco de Dados do Azure para deve ter a autenticação do Microsoft Entra habilitada somente

Descrição: desabilitar métodos de autenticação local e exigir a autenticação do Microsoft Entra melhora a segurança, garantindo que o servidor flexível do Banco de Dados do Azure para PostgreSQL possa ser acessado somente por identidades do Microsoft Entra (Política relacionada: o servidor flexível do Azure PostgreSQL deve ter a Autenticação Somente do Microsoft Entra habilitada).

Gravidade: Média

As contas do Azure Cosmos DB devem ter regras de firewall

Descrição: as regras de firewall devem ser definidas em suas contas do Azure Cosmos DB para impedir o tráfego de fontes não autorizadas. As contas que têm pelo menos uma regra de IP definida com o filtro de rede virtual habilitado são consideradas em conformidade. As contas que desabilitam o acesso público também são consideradas em conformidade. (Política relacionada: As contas do Azure Cosmos DB devem ter regras de firewall).

Gravidade: Média

Os domínios da Grade de Eventos do Azure devem usar um link privado

Descrição: o Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de link privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Por meio do mapeamento de pontos de extremidade privados para os seus domínios de Grade de Eventos em vez de todo o serviço, você também estará protegido contra riscos de vazamento de dados. Saiba mais em: https://aka.ms/privateendpoints. (Política relacionada: Os domínios da Grade de Eventos do Azure devem usar o link privado).

Gravidade: Média

Os tópicos da Grade de Eventos do Azure devem usar um link privado

Descrição: o Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de link privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Por meio do mapeamento de pontos de extremidade privados para seus tópicos, em vez de todo o serviço, você também estará protegido contra riscos de vazamento de dados. Saiba mais em: https://aka.ms/privateendpoints. (Política relacionada: Os tópicos da Grade de Eventos do Azure devem usar o link privado).

Gravidade: Média

Os workspaces do Azure Machine Learning devem usar um link privado

Descrição: o Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de link privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Por meio do mapeamento de pontos de extremidade privados para seus workspaces do Azure Machine Learning, em vez de todo o serviço, você também estará protegido contra riscos de vazamento de dados. Saiba mais em: https://aka.ms/azureml-workspaces-privatelink. (Política relacionada: Os workspaces do Azure Machine Learning devem usar o link privado).

Gravidade: Média

O Serviço do Azure SignalR deve usar o link privado

Descrição: o Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de link privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Por meio do mapeamento de pontos de extremidade privados para seus recursos do SignalR, em vez de todo o serviço, você também estará protegido contra riscos de vazamento de dados. Saiba mais em: https://aka.ms/asrs/privatelink. (Política relacionada: O Serviço do Azure SignalR deve usar o link privado).

Gravidade: Média

O Azure Spring Cloud deve usar injeção de rede

Descrição: as instâncias do Azure Spring Cloud devem usar a injeção de rede virtual para as seguintes finalidades: 1. Isole o Azure Spring Cloud da Internet. 2. Habilite a interação do Azure Spring Cloud com sistemas em data centers locais ou no serviço do Azure em outras redes virtuais. 3. Capacite os clientes a controlar comunicações de rede de entrada e saída para o Azure Spring Cloud. (Política relacionada: O Azure Spring Cloud deve usar injeção de rede).

Gravidade: Média

Os SQL Servers devem ter um administrador do Azure Active Directory provisionado

Descrição: provisione um administrador do Azure AD para o SQL Server habilitar a autenticação do Azure AD. A autenticação do Microsoft Azure Active Directory permite o gerenciamento simplificado de permissões e o gerenciamento centralizado de identidades dos usuários de banco de dados e de outros serviços da Microsoft. (Política relacionada: Um administrador do Azure Active Directory deve ser provisionado para servidores SQL).

Gravidade: Alta

O modo de autenticação de Workspace do Azure Synapse deve ser Somente do Azure Active Directory

Descrição: o modo de autenticação do workspace do Azure Synapse deve ser Somente Azure Active Directory Somente métodos de autenticação somente do Azure Active Directory melhora a segurança, garantindo que os workspaces do Synapse exijam exclusivamente identidades do Azure AD para autenticação. Saiba mais. (Política relacionada: Os workspaces do Synapse devem usar apenas identidades do Azure Active Directory para autenticação).

Gravidade: Média

As descobertas de verificação de código dos repositórios de código devem ser resolvidas

Descrição: o Defender para DevOps encontrou vulnerabilidades em repositórios de código. Para aprimorar a postura de segurança dos repositórios, é altamente recomendável corrigir essas vulnerabilidades. (Não há política relacionada)

Gravidade: Média

As descobertas de verificação de Dependabot dos repositórios de código devem ser resolvidas

Descrição: o Defender para DevOps encontrou vulnerabilidades em repositórios de código. Para aprimorar a postura de segurança dos repositórios, é altamente recomendável corrigir essas vulnerabilidades. (Não há política relacionada)

Gravidade: Média

As descobertas de verificação de infraestrutura como código dos repositórios de código devem ser resolvidas

Descrição: o Defender para DevOps encontrou problemas de configuração de segurança de infraestrutura como código em repositórios. Os problemas mostrados abaixo foram detectados em arquivos de modelo. Para aprimorar a postura de segurança dos recursos relacionados a nuvem, é altamente recomendável corrigir esses problemas. (Não há política relacionada)

Gravidade: Média

As descobertas de verificação de segredo dos repositórios de código devem ser resolvidas

Descrição: o Defender para DevOps encontrou um segredo em repositórios de código. Isso deve ser corrigido imediatamente para evitar uma violação de segurança. Os segredos encontrados nos repositórios podem ser vazados ou descobertos por adversários, levando a um comprometimento de um aplicativo ou um serviço. Para o Azure DevOps, a ferramenta CredScan do DevOps de Segurança da Microsoft verifica apenas builds nos quais ela foi configurada para ser executada. Portanto, os resultados podem não refletir o status completo dos segredos nos seus repositórios. (Não há política relacionada)

Gravidade: Alta

As contas dos Serviços Cognitivos devem habilitar a criptografia de dados

Descrição: essa política audita todas as contas dos Serviços Cognitivos que não estão usando criptografia de dados. Para cada conta com armazenamento, você deve habilitar a criptografia de dados com a chave gerenciada pelo cliente ou gerenciada pela Microsoft. (Política relacionada: As contas dos Serviços Cognitivos devem habilitar a criptografia de dados).

Gravidade: Baixa

As contas dos Serviços Cognitivos devem usar o armazenamento de propriedade do cliente ou habilitar a criptografia de dados

Descrição: essa política audita qualquer conta dos Serviços Cognitivos que não usa armazenamento de propriedade do cliente nem criptografia de dados. Para cada conta dos Serviços Cognitivos com armazenamento, use o armazenamento de propriedade do cliente ou habilite a criptografia de dados. Alinha-se com o Microsoft Cloud Security Benchmark. (Política relacionada: As contas dos Serviços Cognitivos devem usar o armazenamento de propriedade do cliente ou habilitar a criptografia de dados.)

Gravidade: Baixa

Os logs de diagnóstico no Azure Data Lake Storage devem ser 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 Azure Data Lake Store devem ser habilitados).

Gravidade: Baixa

Os logs de diagnóstico no Data Lake Analytics devem ser 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 Data Lake Analytics devem ser habilitados).

Gravidade: Baixa

A notificação por email para alertas de severidade alta deve ser habilitada

Descrição: para garantir que as pessoas relevantes em sua organização sejam notificadas quando houver uma possível violação de segurança em uma de suas assinaturas, habilite notificações por email para alertas de alta gravidade no Defender para Nuvem. (Política relacionada: A notificação por e-mail para alertas de alta gravidade deve ser ativada).

Gravidade: Baixa

A notificação por email para o proprietário da assinatura para alertas de severidade alta deve ser habilitada

Descrição: para garantir que os proprietários da assinatura sejam notificados quando houver uma possível violação de segurança em sua assinatura, defina notificações por email para proprietários de assinatura para alertas de alta gravidade no Defender para Nuvem. (Política relacionada: A notificação por e-mail ao proprietário da assinatura para alertas de alta gravidade deve ser habilitada).

Gravidade: Média

'Impor conexão SSL' deve ser habilitada para servidores de banco de dados MySQL

Descrição: o Banco de Dados do Azure para MySQL dá suporte à conexão do servidor do Banco de Dados do Azure para MySQL a aplicativos cliente usando SSL (Secure Sockets Layer). Impor conexões SSL entre seu servidor de banco de dados e os aplicativos cliente ajuda a proteger contra ataques de "intermediários" criptografando o fluxo de dados entre o servidor e seu aplicativo. Essa configuração impõe que o SSL sempre esteja habilitado para acessar seu servidor de banco de dados. (Política relacionada: Impor conexão SSL deve ser habilitado para servidores de banco de dados MySQL).

Gravidade: Média

'Impor conexão SSL' deve ser habilitada para servidores de banco de dados PostgreSQL

Descrição: o Banco de Dados do Azure para PostgreSQL dá suporte à conexão do servidor do Banco de Dados do Azure para PostgreSQL a aplicativos cliente usando SSL (Secure Sockets Layer). Impor conexões SSL entre seu servidor de banco de dados e os aplicativos cliente ajuda a proteger contra ataques de "intermediários" criptografando o fluxo de dados entre o servidor e seu aplicativo. Essa configuração impõe que o SSL sempre esteja habilitado para acessar seu servidor de banco de dados. (Política relacionada: Impor conexão SSL deve ser habilitado para servidores de banco de dados PostgreSQL).

Gravidade: Média

Os aplicativos de funções devem ter as descobertas de vulnerabilidade resolvidas

Descrição: a verificação de vulnerabilidades de tempo de execução para funções verifica seus aplicativos de funções em busca de vulnerabilidades de segurança e expõe descobertas detalhadas. Resolver as vulnerabilidades pode melhorar muito a postura de segurança dos seus aplicativos sem servidor e protegê-los contra ataques. (Não há política relacionada)

Gravidade: Alta

O backup com redundância geográfica deve ser habilitado para o Banco de Dados do Azure para MariaDB

Descrição: o Banco de Dados do Azure para MariaDB permite que você escolha a opção de redundância para o servidor de banco de dados. Ele pode ser definido como um armazenamento de backup com redundância geográfica no qual os dados não são armazenados apenas na região em que o servidor está hospedado, mas também são replicados para uma região emparelhada para dar opções de recuperação em caso de falha de região. A configuração do armazenamento com redundância geográfica para backup só é permitida ao criar um servidor. (Política relacionada: O backup com redundância geográfica deve ser habilitado para o Banco de Dados do Azure para MariaDB).

Gravidade: Baixa

O backup com redundância geográfica deve ser habilitado para o Banco de Dados do Azure para MySQL

Descrição: o Banco de Dados do Azure para MySQL permite que você escolha a opção de redundância para o servidor de banco de dados. Ele pode ser definido como um armazenamento de backup com redundância geográfica no qual os dados não são armazenados apenas na região em que o servidor está hospedado, mas também são replicados para uma região emparelhada para dar opções de recuperação em caso de falha de região. A configuração do armazenamento com redundância geográfica para backup só é permitida ao criar um servidor. (Política relacionada: O backup com redundância geográfica deve ser habilitado para o Banco de Dados do Azure para MySQL).

Gravidade: Baixa

O backup com redundância geográfica deve ser habilitado para o Banco de Dados do Azure para PostgreSQL

Descrição: o Banco de Dados do Azure para PostgreSQL permite que você escolha a opção de redundância para o servidor de banco de dados. Ele pode ser definido como um armazenamento de backup com redundância geográfica no qual os dados não são armazenados apenas na região em que o servidor está hospedado, mas também são replicados para uma região emparelhada para dar opções de recuperação em caso de falha de região. A configuração do armazenamento com redundância geográfica para backup só é permitida ao criar um servidor. (Política relacionada: O backup com redundância geográfica deve ser habilitado para o Banco de Dados do Azure para PostgreSQL).

Gravidade: Baixa

Os repositórios do GitHub devem ter a verificação de código habilitada

Descrição: o GitHub usa a varredura de código para analisar o código a fim de encontrar vulnerabilidades de segurança e erros no código. A verificação de código pode ser usada para localizar, fazer triagem e priorizar correções para problemas existentes no seu código. A verificação de código também pode impedir que os desenvolvedores introduzam novos problemas. As verificações podem ser programadas para dias e horários específicos ou podem ser acionadas quando ocorre um evento específico no repositório, como, um push. Se a verificação de código localiza uma possível vulnerabilidade ou um possível erro no código, o GitHub mostra um alerta no repositório. Uma vulnerabilidade é um problema no código de um projeto que pode ser explorado para corromper a confidencialidade, a integridade ou a disponibilidade do projeto. (Não há política relacionada)

Gravidade: Média

Os repositórios do GitHub devem ter a verificação do Dependabot habilitada

Descrição: o GitHub envia alertas do Dependabot quando detecta vulnerabilidades em dependências de código que afetam repositórios. Uma vulnerabilidade é um problema no código de um projeto que poderia ser explorada para corromper a confidencialidade, a integridade ou a disponibilidade do projeto ou de outros projetos que usam o código. As vulnerabilidades variam de tipo, gravidade e método de ataque. Quando o código depende de um pacote que tem uma vulnerabilidade de segurança, essa dependência vulnerável pode causar uma série de problemas. (Não há política relacionada)

Gravidade: Média

Os repositórios do GitHub devem ter a verificação de segredos habilitada

Descrição: o GitHub verifica repositórios em busca de tipos conhecidos de segredos, para evitar o uso fraudulento de segredos que foram acidentalmente confirmados em repositórios. A verificação de segredos examina automaticamente todo o histórico do Git em todos os branches presentes no seu repositório do GitHub em busca de segredos. Exemplos de segredos são tokens e chaves privadas que um provedor de serviços pode emitir para autenticação. Se um segredo é colocado em um repositório, qualquer pessoa que tenha acesso de leitura ao repositório pode usar o segredo para acessar o serviço externo com esses privilégios. Os segredos devem ser armazenados em um local dedicado e seguro fora do repositório do projeto. (Não há política relacionada)

Gravidade: Alta

O Microsoft Defender para servidores do Banco de Dados SQL do Azure deve estar habilitado

Descrição: Microsoft Defender para SQL é um pacote unificado que fornece recursos avançados de segurança do SQL. Ela inclui funcionalidades para identificar e atenuar vulnerabilidades potenciais de banco de dados, detectar atividades anormais que podem indicar uma ameaça ao banco de dados e descobrir e classificar dados confidenciais.

As proteções desse plano são cobradas conforme mostrado na página de planos do Defender. Se você não tiver servidores do Banco de Dados SQL do Azure nessa assinatura, não será cobrado. Se você criar servidores do Banco de Dados SQL do Azure 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 SQL. (Política relacionada: Os servidores do Azure Defender para Banco de Dados SQL do Azure devem estar habilitados).

Gravidade: Alta

O Microsoft Defender para DNS deve estar habilitado

Descrição: o Microsoft Defender para DNS fornece uma camada adicional de proteção para seus recursos de nuvem monitorando continuamente todas as consultas DNS de seus recursos do Azure. O Defender para DNS alertará você sobre atividades suspeitas na camada DNS. Saiba mais em Introdução ao Microsoft Defender para DNS. Habilitar este plano do Defender resultará em determinados encargos. Saiba mais sobre os detalhes de preços por região na página de preços do Defender para Nuvem: Preços do Defender para Nuvem. (Não há política relacionada)

Gravidade: Alta

O Microsoft Defender para bancos de dados relacionais de código aberto deve estar habilitado

Descrição: o Microsoft Defender para bancos de dados relacionais de software livre detecta atividades anômalas que indicam tentativas incomuns e potencialmente prejudiciais de acessar ou explorar bancos de dados. Saiba mais em Introdução ao Microsoft Defender para bancos de dados relacionais de código aberto.

A habilitação desse plano resultará em cobranças pela proteção de seus bancos de dados relacionais de software livre. Se você não tiver bancos de dados relacionais de código aberto nessa assinatura, os encargos não serão incorridos. Se você criar bancos de dados relacionais nessa assinatura no futuro, eles serão automaticamente protegidos e os encargos serão iniciados nesse momento. (Não há política relacionada)

Gravidade: Alta

O Microsoft Defender para o Resource Manager deve estar habilitado

Descrição: Microsoft Defender para Resource Manager monitora automaticamente as operações de gerenciamento de recursos em sua organização. O Defender para Nuvem detecta ameaças e emite alertas sobre atividades suspeitas. Saiba mais em Introdução ao Microsoft Defender para Resource Manager. Habilitar este plano do Defender resultará em determinados encargos. Saiba mais sobre os detalhes de preços por região na página de preços do Defender para Nuvem: Preços do Defender para Nuvem. (Não há política relacionada)

Gravidade: Alta

O Microsoft Defender para SQL em computadores deve estar habilitado nos workspaces

Descrição: o Microsoft Defender para servidores traz detecção de ameaças e defesas avançadas para seus computadores Windows e Linux. Com esse plano do Defender habilitado em suas assinaturas, mas não em seus workspaces, você está pagando pela capacidade total do Microsoft Defender para servidores, mas perdendo alguns dos benefícios. Quando você habilita o Microsoft Defender para servidores em um workspace, todos os computadores que fornecem relatórios a esse workspace serão cobrados quanto ao Microsoft Defender para servidores, mesmo que estejam em assinaturas sem os planos do Defender habilitados. A menos que você também habilite o Microsoft Defender para servidores na assinatura, esses computadores não poderão aproveitar o acesso JIT (just-in-time) à VM, os controles de aplicativos adaptáveis e as detecções de rede para recursos do Azure. Saiba mais em Introdução ao Microsoft Defender para servidores. (Não há política relacionada)

Gravidade: Média

O Microsoft Defender para servidores SQL em computadores deve estar habilitado

Descrição: Microsoft Defender para SQL é um pacote unificado que fornece recursos avançados de segurança do SQL. Ela inclui funcionalidades para identificar e atenuar vulnerabilidades potenciais de banco de dados, detectar atividades anormais que podem indicar uma ameaça ao banco de dados e descobrir e classificar dados confidenciais.

a correção dessa recomendação resultará em custos para proteger os SQL Servers nos computadores. Se você não tiver nenhum SQL Server nos computadores nessa assinatura, nenhum custo será gerado. Se você criar SQL Servers nos computadores nessa assinatura no futuro, eles serão automaticamente protegidos e os custos serão iniciados nesse momento. Saiba mais sobre o Microsoft Defender para SQL Servers em computadores. (Política relacionada: Azure Defender para SQL servidores em computadores devem estar habilitados).

Gravidade: Alta

O Microsoft Defender para SQL deve estar habilitado para servidores SQL do Azure desprotegidos

Descrição: Microsoft Defender para SQL é um pacote unificado que fornece recursos avançados de segurança do SQL. Ele revela e atenua possíveis vulnerabilidades do banco de dados, além de detectar atividades anômalas que podem indicar uma ameaça ao seu banco de dados. O Microsoft Defender para SQL é cobrado conforme mostrado nos detalhes de preços por região. (Política relacionada: A segurança avançada de dados deve ser habilitada em seus servidores SQL).

Gravidade: Alta

O Microsoft Defender para SQL deve ser habilitado para Instância Gerenciada de SQL não protegidas

Descrição: Microsoft Defender para SQL é um pacote unificado que fornece recursos avançados de segurança do SQL. Ele revela e atenua possíveis vulnerabilidades do banco de dados, além de detectar atividades anômalas que podem indicar uma ameaça ao seu banco de dados. O Microsoft Defender para SQL é cobrado conforme mostrado nos detalhes de preços por região. (Política relacionada: A segurança avançada de dados deve ser habilitada na Instância Gerenciada de SQL).

Gravidade: Alta

O Microsoft Defender para Armazenamento deve estar habilitado

Descrição: o Microsoft Defender para armazenamento detecta tentativas incomuns e potencialmente prejudiciais de acessar ou explorar contas de armazenamento.

As proteções desse plano são cobradas conforme mostrado na página de planos do Defender. Se você não tiver contas do Armazenamento do Azure nessa assinatura, não será cobrado. Se você criar contas de Armazenamento do Azure 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 Armazenamento. (Política relacionada: O Azure Defender para Armazenamento deve estar habilitado).

Gravidade: Alta

O Observador de Rede deve ser habilitado

Descrição: o Observador de Rede é um serviço regional que permite monitorar e diagnosticar condições em um nível de cenário de rede no, para e do Azure. O monitoramento de nível de cenário permite que você faça o diagnóstico de problemas em uma exibição de nível de rede de ponta a ponta. As ferramentas de diagnóstico e visualização da rede disponíveis com o Observador de Rede ajudam a entender, diagnosticar e ter informações para sua rede no Azure. (Política relacionada: O Observador de Rede deve estar habilitado).

Gravidade: Baixa

As conexões de ponto de extremidade privado nos Banco de Dados SQL do Azure devem ser habilitadas

Descrição: as conexões de ponto de extremidade privado impõem a comunicação segura habilitando a conectividade privada com o Banco de Dados SQL do Azure. (Política relacionada: As conexões de ponto de extremidade privado no Banco de Dados SQL do Azure devem ser habilitadas).

Gravidade: Média

O ponto de extremidade privado deve ser habilitado para servidores MariaDB

Descrição: as conexões de ponto de extremidade privado impõem a comunicação segura habilitando a conectividade privada com o Banco de Dados do Azure para MariaDB. Configure uma conexão de ponto de extremidade privado para habilitar o acesso ao tráfego proveniente somente de redes conhecidas e impedir o acesso de todos os outros endereços IP, incluindo no Azure. (Política relacionada: O ponto de extremidade privado deve ser habilitado para servidores MariaDB).

Gravidade: Média

O ponto de extremidade privado deve ser habilitado para servidores MySQL

Descrição: as conexões de ponto de extremidade privado impõem a comunicação segura habilitando a conectividade privada com o Banco de Dados do Azure para MySQL. Configure uma conexão de ponto de extremidade privado para habilitar o acesso ao tráfego proveniente somente de redes conhecidas e impedir o acesso de todos os outros endereços IP, incluindo no Azure. (Política relacionada: O ponto de extremidade privado deve ser habilitado para servidores MySQL).

Gravidade: Média

O ponto de extremidade privado deve ser habilitado para servidores PostgreSQL

Descrição: as conexões de ponto de extremidade privado impõem a comunicação segura habilitando a conectividade privada com o Banco de Dados do Azure para PostgreSQL. Configure uma conexão de ponto de extremidade privado para habilitar o acesso ao tráfego proveniente somente de redes conhecidas e impedir o acesso de todos os outros endereços IP, incluindo no Azure. (Política relacionada: O ponto de extremidade privado deve ser habilitado para servidores PostgreSQL).

Gravidade: Média

O acesso à rede pública no Banco de Dados SQL do Azure deve ser desabilitado

Descrição: desabilitar a propriedade de acesso à rede pública melhora a segurança, garantindo que o Banco de Dados SQL do Azure só possa ser acessado de um ponto de extremidade privado. Essa configuração nega todos os logons que correspondam às regras de firewall baseadas em rede virtual ou em IP. (Política relacionada: O acesso à rede pública no Banco de Dados SQL do Azure deve ser desabilitado).

Gravidade: Média

O acesso à rede pública deve ser desabilitado nas contas dos Serviços Cognitivos

Descrição: essa política audita qualquer conta dos Serviços Cognitivos em seu ambiente com acesso à rede pública habilitado. O acesso à rede pública deve ser desabilitado para que somente as conexões de pontos de extremidade privados sejam permitidas. (Política relacionada: O acesso à rede pública deve ser desabilitado para contas dos Serviços Cognitivos).

Gravidade: Média

O acesso à rede pública deve ser desabilitado para servidores MariaDB

Descrição: desabilite a propriedade de acesso à rede pública para melhorar a segurança e garantir que o Banco de Dados do Azure para MariaDB só possa ser acessado de um ponto de extremidade privado. Essa configuração desabilita estritamente o acesso de qualquer espaço de endereço público fora do intervalo de IP do Azure e nega todos os logons que correspondam a regras de firewall baseadas em IP ou em rede virtual. (Política relacionada: O acesso à rede pública deve ser desabilitado para servidores MariaDB).

Gravidade: Média

O acesso à rede pública deve ser desabilitado para servidores MySQL

Descrição: desabilite a propriedade de acesso à rede pública para melhorar a segurança e garantir que o Banco de Dados do Azure para MySQL só possa ser acessado de um ponto de extremidade privado. Essa configuração desabilita estritamente o acesso de qualquer espaço de endereço público fora do intervalo de IP do Azure e nega todos os logons que correspondam a regras de firewall baseadas em IP ou em rede virtual. (Política relacionada: O acesso à rede pública deve ser desabilitado para servidores MySQL).

Gravidade: Média

O acesso à rede pública deve ser desabilitado para servidores PostgreSQL

Descrição: desabilite a propriedade de acesso à rede pública para melhorar a segurança e garantir que o Banco de Dados do Azure para PostgreSQL só possa ser acessado de um ponto de extremidade privado. Essa configuração desabilita o acesso de qualquer espaço de endereço público fora do intervalo de IP do Azure e nega todos os logons que correspondam a regras de firewall baseadas em IP ou em rede virtual. (Política relacionada: O acesso à rede pública deve ser desabilitado para servidores PostgreSQL).

Gravidade: Média

O Cache Redis deve permitir o acesso somente por SSL

Descrição: habilite apenas conexões via SSL para o Cache Redis. O uso de conexões seguras garante a autenticação entre o servidor e o serviço e protege dados em trânsito de ataques de camada de rede, como ataques intermediários, interceptação e sequestro de sessão. (Política relacionada: Somente conexões seguras com o Cache do Azure para Redis devem ser habilitadas).

Gravidade: Alta

Os bancos de dados SQL devem ter as descobertas de vulnerabilidade resolvidas

Descrição: a avaliação de vulnerabilidades do SQL verifica seu banco de dados em busca de vulnerabilidades de segurança e expõe quaisquer desvios das práticas recomendadas, como configurações incorretas, permissões excessivas e dados confidenciais desprotegidos. Resolver as vulnerabilidades encontradas pode melhorar muito a postura de segurança de seu banco de dados. Saiba mais (Política relacionada: vulnerabilidades em seus bancos de dados SQL devem ser corrigidas).

Gravidade: Alta

As instâncias gerenciadas de SQL devem ter a avaliação de vulnerabilidade configurada

Descrição: a avaliação de vulnerabilidades pode descobrir, rastrear e ajudar a corrigir possíveis vulnerabilidades do banco de dados. (Política relacionada: A avaliação de vulnerabilidade deve ser habilitada na Instância Gerenciada de SQL).

Gravidade: Alta

Os servidores SQL em computadores devem ter as descobertas de vulnerabilidade resolvidas

Descrição: a avaliação de vulnerabilidades do SQL verifica seu banco de dados em busca de vulnerabilidades de segurança e expõe quaisquer desvios das práticas recomendadas, como configurações incorretas, permissões excessivas e dados confidenciais desprotegidos. Resolver as vulnerabilidades encontradas pode melhorar muito a postura de segurança de seu banco de dados. Saiba mais (Política relacionada: vulnerabilidades em seus servidores SQL no computador devem ser corrigidas).

Gravidade: Alta

Os SQL Servers devem ter um administrador do Azure Active Directory provisionado

Descrição: provisione um administrador do Azure AD para o SQL Server habilitar a autenticação do Azure AD. A autenticação do Microsoft Azure Active Directory permite o gerenciamento simplificado de permissões e o gerenciamento centralizado de identidades dos usuários de banco de dados e de outros serviços da Microsoft. (Política relacionada: Um administrador do Azure Active Directory deve ser provisionado para servidores SQL).

Gravidade: Alta

Os SQL Servers devem ter a avaliação de vulnerabilidade configurada

Descrição: a avaliação de vulnerabilidades pode descobrir, rastrear e ajudar a corrigir possíveis vulnerabilidades do banco de dados. (Política relacionada: A avaliação de vulnerabilidades deve ser habilitada em seus servidores SQL).

Gravidade: Alta

A conta de armazenamento deve usar uma conexão de link privado

Descrição: os links privados impõem a comunicação segura, fornecendo conectividade privada com a conta de armazenamento (política relacionada: a conta de armazenamento deve usar uma conexão de link privado).

Gravidade: Média

As contas de armazenamento devem ser migradas para os novos recursos do Azure Resource Manager

Descrição: para se beneficiar dos novos recursos do Azure Resource Manager, você pode migrar implantações existentes do modelo de implantação Clássico. O Resource Manager permite aprimoramentos de segurança, como: RBAC (controle de acesso) mais forte, melhor auditoria, implantação e governança baseadas em ARM, acesso a identidades gerenciadas, acesso ao cofre de chaves para segredos, autenticação baseada em Azure AD e suporte para marcas e grupos de recursos para facilitar o gerenciamento de segurança. Saiba mais (Política relacionada: as contas de armazenamento devem ser migradas para novos recursos do Azure Resource Manager).

Gravidade: Baixa

As contas de armazenamento devem impedir o acesso de chave compartilhada

Descrição: requisito de auditoria do Azure Active Directory (Azure AD) para autorizar solicitações para sua conta de armazenamento. Por padrão, as solicitações podem ser autorizadas com as credenciais do Azure Active Directory ou usando a chave de acesso da conta para a autorização de chave compartilhada. Desses dois tipos de autorização, o Azure AD fornece segurança superior e facilidade de uso em relação à chave compartilhada e é recomendado pela Microsoft. (Política relacionada: política)

Gravidade: Média

As contas de armazenamento devem restringir o acesso à rede usando regras de rede virtual

Descrição: proteja suas contas de armazenamento contra possíveis ameaças usando regras de rede virtual como método preferencial em vez de filtragem baseada em IP. Desabilitar filtragem baseada em IP impede que IPs públicos acessem suas contas de armazenamento. (Política relacionada: As contas de armazenamento devem restringir o acesso à rede usando regras de rede virtual).

Gravidade: Média

As assinaturas devem ter um endereço de email de contato para problemas de segurança

Descrição: para garantir que as pessoas relevantes em sua organização sejam notificadas quando houver uma possível violação de segurança em uma de suas assinaturas, defina um contato de segurança para receber notificações por email do Defender para Nuvem. (Política relacionada: as assinaturas devem ter um endereço de email de contato para problemas de segurança)

Gravidade: Baixa

A Transparent Data Encryption em bancos de dados SQL deve ser habilitada

Descrição: habilite a criptografia de dados transparente para proteger os dados em repouso e atender aos requisitos de conformidade (Política relacionada: a Transparent Data Encryption em bancos de dados SQL deve estar habilitada).

Gravidade: Baixa

Os modelos do Construtor de Imagens de VM devem usar o link privado

Descrição: Audite modelos do Construtor de Imagens de VM que não têm uma rede virtual configurada. Quando uma rede virtual não está configurada, um IP público é criado e usado, o que pode expor diretamente os recursos à Internet e aumentar a superfície de ataque potencial. (Política relacionada: Os modelos do Construtor de Imagens de VM devem usar link privado).

Gravidade: Média

O WAF (Firewall do Aplicativo Web) deve ser habilitado para o Gateway de Aplicativo

Descrição: implante o WAF (Firewall de Aplicativo Web) do Azure na frente de aplicativos Web voltados para o público para inspeção adicional do tráfego de entrada. O WAF (Firewall de Aplicativo Web) fornece proteção centralizada de seus aplicativos Web contra vulnerabilidades e explorações comuns como injeções de SQL, Cross-Site Scripting e execuções de arquivo locais e remotas. Você também pode restringir o acesso aos seus aplicativos Web por países/regiões, intervalos de endereços IP e outros parâmetros http(s) por meio de regras personalizadas. (Política relacionada: O WAF (Firewall de Aplicativo Web) deve ser habilitado para o Gateway de Aplicativo).

Gravidade: Baixa

O WAF (Firewall de Aplicativo Web) deve ser habilitado para o serviço do Azure Front Door Service

Descrição: implante o WAF (Firewall de Aplicativo Web) do Azure na frente de aplicativos Web voltados para o público para inspeção adicional do tráfego de entrada. O WAF (Firewall de Aplicativo Web) fornece proteção centralizada de seus aplicativos Web contra vulnerabilidades e explorações comuns como injeções de SQL, Cross-Site Scripting e execuções de arquivo locais e remotas. Você também pode restringir o acesso aos seus aplicativos Web por países/regiões, intervalos de endereços IP e outros parâmetros http(s) por meio de regras personalizadas. (Política relacionada: O WAF (Firewall de Aplicativo Web) deve ser habilitado para o Azure Front Door Service?)

Gravidade: Baixa

Recomendações de dados da AWS

Os clusters do Amazon Aurora devem ter o rastreamento inverso habilitado

Descrição: esse controle verifica se os clusters do Amazon Aurora têm o retrocesso habilitado. Os backups ajudam você a se recuperar mais rapidamente de um incidente de segurança. Também reforçam a resiliência dos sistemas. O rastreamento inverso do Aurora reduz o tempo de recuperação de um banco de dados para um período. Não é necessária uma restauração de banco de dados para fazer isso. Para obter mais informações sobre o rastreamento inverso no Aurora, confira Rastreamento inverso de um cluster do banco de dados do Aurora no Guia do Usuário do Amazon Aurora.

Gravidade: Média

Os instantâneos do Amazon EBS não devem ser restaurados publicamente

Descrição: os snapshots do Amazon EBS não devem ser restauráveis publicamente por todos, a menos que explicitamente permitido, para evitar a exposição acidental de dados. Além disso, a permissão para alterar as configurações do Amazon EBS deve ser restrita somente a contas AWS autorizadas.

Gravidade: Alta

As definições de tarefa do Amazon ECS devem ter modos de rede e definições de usuário seguros

Descrição: esse controle verifica se uma definição de tarefa ativa do Amazon ECS que tem o modo de rede do host também tem definições de contêiner privilegiadas ou de usuário. O controle falha para definições de tarefa que têm definições de contêiner e modo de rede de host, onde privileged=false ou está vazio e user=root ou está vazio. Se uma definição de tarefa tiver privilégios elevados, é porque o cliente optou especificamente por essa configuração. Esse controle verifica se há escalonamento de privilégios inesperado quando uma definição de tarefa tem a rede de host habilitada, mas o cliente não optou por privilégios elevados.

Gravidade: Alta

Os domínios do Amazon Elasticsearch Service devem criptografar dados enviados entre nós

Descrição: esse controle verifica se os domínios do Amazon ES têm a criptografia de nó para nó habilitada. O HTTPS (TLS) pode ser usado para ajudar a impedir que possíveis invasores espionem ou manipulem o tráfego de rede usando ataques person-in-the-middle ou ataques semelhantes. Somente conexões criptografadas por HTTPS (TLS) devem ser permitidas. Habilitar a criptografia de nó para nó para domínios do Amazon ES garante que as comunicações entre clusters sejam criptografadas em trânsito. Pode haver uma penalidade no desempenho associada a essa configuração. Você deve estar ciente e testar a compensação de desempenho, antes de habilitar essa opção.

Gravidade: Média

Os domínios do Amazon Elasticsearch Service devem ter a criptografia em repouso habilitada

Descrição: é importante habilitar criptografias de outros domínios do Amazon ES para proteger dados confidenciais

Gravidade: Média

O banco de dados do Amazon RDS deve ser criptografado usando a chave gerenciada pelo cliente

Descrição: essa verificação identifica bancos de dados do RDS criptografados com chaves do KMS padrão e não com chaves gerenciadas pelo cliente. Como prática principal, use chaves gerenciadas pelo cliente para criptografar os dados em seus bancos de dados do RDS e manter o controle de chaves e dados em cargas de trabalho confidenciais.

Gravidade: Média

A instância do Amazon RDS deve ser definida com configurações de backup automático

Descrição: essa verificação identifica instâncias do RDS, que não são definidas com a configuração de backup automático. Se o Backup Automático estiver definido, o RDS criará um instantâneo de volume de armazenamento da instância de BD, fazendo backup de toda a instância de BD e não apenas de bancos de dados individuais, que fornecem recuperação pontual. O backup automático ocorre durante o tempo de janela de backup especificado e mantém os backups por um período limitado, conforme definido no período de retenção. É recomendável definir backups automáticos para seus servidores RDS críticos que ajudam no processo de restauração de dados.

Gravidade: Média

Os clusters do Amazon Redshift devem ter o log de auditoria habilitado

Descrição: esse controle verifica se um cluster do Amazon Redshift tem o registro em log de auditoria habilitado. O log de auditoria do Amazon Redshift fornece informações adicionais sobre as conexões e atividades do usuário no cluster. Esses dados podem ser armazenados e protegidos no Amazon S3 e podem ser úteis em investigações e auditorias de segurança. Para obter mais informações, confira o log de auditoria de banco de dados no Guia de Gerenciamento de Clusters do Amazon Redshift.

Gravidade: Média

Os clusters do Amazon Redshift devem ter os instantâneos automáticos habilitados

Descrição: esse controle verifica se os clusters do Amazon Redshift têm snapshots automatizados habilitados. Também verifica se o período de retenção de instantâneo é maior ou igual a sete. Os backups ajudam você a se recuperar mais rapidamente de um incidente de segurança. Eles reforçam a resiliência dos sistemas. O Amazon Redshift tira instantâneos periódicos por padrão. Esse controle verifica se os instantâneos automáticos estão habilitados e são mantidos por pelo menos sete dias. Para obter mais informações sobre snapshots automatizados do Amazon Redshift, consulte Snapshots automatizados no Guia de gerenciamento de clusters do Amazon Redshift.

Gravidade: Média

Os clusters do Amazon Redshift devem proibir o acesso público

Descrição: recomendamos clusters do Amazon Redshift para evitar a acessibilidade pública avaliando o campo "publiclyAccessible" no item de configuração do cluster.

Gravidade: Alta

O Amazon Redshift deve ter as atualizações automáticas para as versões principais habilitadas

Descrição: esse controle verifica se as atualizações automáticas de versão principal estão habilitadas para o cluster do Amazon Redshift. Habilitar as atualizações automáticas da versão principal garante que as atualizações da versão principal mais recentes para os clusters do Amazon Redshift sejam instaladas durante a janela de manutenção. Essas atualizações podem incluir patches de segurança e correções de bugs. Manter-se atualizado com a instalação de patch é uma etapa importante na segurança de sistemas.

Gravidade: Média

As filas do Amazon SQS devem ser criptografadas em repouso

Descrição: esse controle verifica se as filas do Amazon SQS estão criptografadas em repouso. A SSE (criptografia do lado do servidor) permite que você transmita os dados confidenciais em filas criptografadas. Para proteger o conteúdo das mensagens em filas, a SSE usa chaves gerenciadas no AWS KMS. Para obter mais informações, confira Criptografia em repouso no Guia do Desenvolvedor do Amazon Simple Queue Service.

Gravidade: Média

Uma assinatura de notificações de eventos do RDS deve ser configurada para eventos críticos do cluster

Descrição: esse controle verifica se existe uma assinatura de evento do Amazon RDS que tenha notificações habilitadas para o seguinte tipo de origem: Pares de chave-valor de categoria de evento. DBCluster: [Manutenção e falha]. As notificações de eventos do RDS usam o Amazon SNS para informar você sobre as alterações na disponibilidade ou configuração dos recursos do RDS. Essas notificações permitem uma resposta rápida. Para obter mais informações sobre notificações de eventos do RDS, confira Como usar a notificação de eventos do Amazon RDS no Guia do Usuário do Amazon RDS.

Gravidade: Baixa

Uma assinatura de notificações de eventos do RDS deve ser configurada para eventos críticos da instância do banco de dados

Descrição: esse controle verifica se existe uma assinatura de evento do Amazon RDS com notificações habilitadas para o seguinte tipo de origem: pares de chave-valor de categoria de evento. DBInstance: [Manutenção, alteração de configuração e falha]. As notificações de eventos do RDS usam o Amazon SNS para informar você sobre as alterações na disponibilidade ou configuração dos recursos do RDS. Essas notificações permitem uma resposta rápida. Para obter mais informações sobre notificações de eventos do RDS, confira Como usar a notificação de eventos do Amazon RDS no Guia do Usuário do Amazon RDS.

Gravidade: Baixa

Uma assinatura de notificações de evento do RDS deve ser configurada para eventos críticos do grupo de parâmetros de banco de dados

Descrição: esse controle verifica se existe uma assinatura de evento do Amazon RDS com notificações habilitadas para o seguinte tipo de origem: pares de chave-valor de categoria de evento. DBParameterGroup: ["configuration","change"]. As notificações de eventos do RDS usam o Amazon SNS para informar você sobre as alterações na disponibilidade ou configuração dos recursos do RDS. Essas notificações permitem uma resposta rápida. Para obter mais informações sobre notificações de eventos do RDS, confira Como usar a notificação de eventos do Amazon RDS no Guia do Usuário do Amazon RDS.

Gravidade: Baixa

Uma assinatura de notificações de evento do RDS deve ser configurada para eventos críticos do grupo de segurança de banco de dados

Descrição: esse controle verifica se existe uma assinatura de evento do Amazon RDS com notificações habilitadas para o seguinte tipo de origem: pares de chave-valor de categoria de evento. DBSecurityGroup: [Configuração, alteração, falha]. As notificações de eventos do RDS usam o Amazon SNS para informar você sobre as alterações na disponibilidade ou configuração dos recursos do RDS. Essas notificações permitem uma resposta rápida. Para obter mais informações sobre notificações de eventos do RDS, confira Como usar a notificação de eventos do Amazon RDS no Guia do Usuário do Amazon RDS.

Gravidade: Baixa

O registro em log de API REST e WebSocket do Gateway de API deve estar habilitado

Descrição: esse controle verifica se todos os estágios de uma API REST ou WebSocket do Amazon API Gateway têm o registro em log habilitado. O controle falhará se o registro em log não estiver habilitado para todos os métodos de um estágio ou se o nível de registros em log não for ERROR nem INFO. Os estágios de API REST ou WebSocket do Gateway de API devem ter os logs relevantes habilitados. O registro em log de execução da API REST e WebSocket do Gateway de API fornece os registros detalhados das solicitações feitas para os estágios de API REST e WebSocket do Gateway de API. Os estágios incluem respostas de back-end de integração de API, respostas de autorizador Lambda e requestId para pontos de extremidade de integração do AWS.

Gravidade: Média

Os dados de cache da API REST do Gateway de API devem ser criptografados em repouso

Descrição: esse controle verifica se todos os métodos nos estágios da API REST do API Gateway que têm o cache ativado estão criptografados. O controle falhará se qualquer método em um estágio de API REST do Gateway de API estiver configurado para armazenar em cache e se o cache não estiver criptografado. A criptografia de dados inativos reduz o risco de que os dados armazenados em disco sejam acessados por um usuário não autenticado no AWS. Adiciona outro conjunto de controles de acesso para limitar a capacidade de usuários não autorizados de acessar os dados. Por exemplo, as permissões de API são necessárias para descriptografar os dados, antes que possam ser lidos. Os caches da API REST do Gateway de API devem ser criptografados em repouso para obter uma camada adicional de segurança.

Gravidade: Média

Os estágios da API REST do Gateway de API devem ser configurados para usar certificados SSL para autenticação de back-end

Descrição: esse controle verifica se os estágios da API REST do Amazon API Gateway têm certificados SSL configurados. Os sistemas de back-end usam esses certificados para autenticar que as solicitações de entrada são do Gateway de API. Os estágios de API REST do Gateway de API devem ser configurados com certificados SSL para permitir que os sistemas de back-end autentiquem que as solicitações foram originadas no Gateway de API.

Gravidade: Média

Os estágios da API REST do Gateway de API devem ter o rastreamento do AWS X-Ray habilitado

Descrição: esse controle verifica se o rastreamento ativo do AWS X-Ray está habilitado para os estágios da API REST do Amazon API Gateway. O rastreamento ativo do X-Ray permite uma resposta mais rápida às alterações no desempenho na infraestrutura subjacente. As alterações no desempenho podem resultar na falta de disponibilidade da API. O rastreamento ativo do X-Ray fornece as métricas em tempo real das solicitações de usuário que fluem por meio dos serviços conectados e das operações de API REST do Gateway de API.

Gravidade: Baixa

O Gateway de API deve ser associado a uma ACL Web do AWS WAF

Descrição: esse controle verifica se um estágio do API Gateway usa uma lista de controle de acesso à web (ACL) do AWS WAF. Esse controle falhará se uma ACL Web do AWS WAF não estiver anexada a um estágio do Gateway de API REST. O AWS WAF é um firewall do aplicativo Web que ajuda a proteger aplicativos Web e APIs contra ataques. Permite que você configure uma ACL, que é um conjunto de regras que permitem, bloqueiam ou contam solicitações Web de acordo com as regras de segurança Web personalizáveis e condições definidas por você. Verifique se o estágio do Gateway de API está associado a uma ACL Web do AWS WAF para ajudar a protegê-lo contra ataques mal-intencionados.

Gravidade: Média

O registro em log dos Balanceadores de Carga Clássicos e de Aplicativo deve estar habilitado

Descrição: esse controle verifica se o Application Load Balancer e o Classic Load Balancer têm o log habilitado. O controle falhará se access_logs.s3.enabled for false. O Balanceamento de Carga Elástico fornece logs de acesso que capturam informações detalhadas sobre as solicitações enviadas ao balanceador de carga. Cada log contém informações como a hora em que a solicitação foi recebida, o endereço IP do cliente, as latências, os caminhos de solicitação e as respostas do servidor. Você pode usar logs de acesso para analisar padrões de tráfego e solucionar problemas. Para saber mais, confira Logs de acesso para o Balanceador de Carga Clássico no Guia do Usuário para Balanceadores de Carga Clássicos.

Gravidade: Média

Os volumes anexados do EBS devem ser criptografados em repouso

Descrição: esse controle verifica se os volumes do EBS que estão em um estado anexado estão criptografados. Para serem aprovados nessa verificação, os volumes do EBS devem estar em uso e ser criptografados. Se o volume do EBS não estiver anexado, não estará sujeito a essa verificação. Para obter uma camada adicional de segurança dos dados confidenciais nos volumes do EBS, você deve habilitar a criptografia do EBS em repouso. A criptografia Amazon EBS oferece uma solução de criptografia simples para os recursos do EBS que não exigem que você crie, mantenha e proteja sua própria infraestrutura de gerenciamento de chaves. Ela usa a CMK (chave mestra do cliente) do AWS KMS ao criar volumes e instantâneos criptografados. Para saber mais sobre a criptografia do Amazon EBS, confira Criptografia do Amazon EBS no Guia do Usuário do Amazon EC2 para instâncias do Linux.

Gravidade: Média

As instâncias de replicação do Serviço de Migração de Banco de Dados do AWS não devem ser públicas

Descrição: para proteger suas instâncias replicadas contra ameaças. Uma instância de replicação privada deve ter um endereço IP privado que você não possa acessar fora da rede de replicação. Uma instância de replicação deve ter um endereço IP privado, quando os bancos de dados de origem e de destino estão na mesma rede e a rede está conectada à VPC da instância de replicação usando uma VPN, uma Conexão Direta com o AWS ou um emparelhamento com a VPC. Você também deve garantir que o acesso à configuração da instância do AWS DMS seja limitado somente a usuários autorizados. Para fazer isso, restrinja as permissões de IAM dos usuários para modificar as configurações e os recursos do AWS DMS.

Gravidade: Alta

Os ouvintes do Balanceador de Carga Clássico devem ser configurados com terminação HTTPS ou TLS

Descrição: esse controle verifica se os ouvintes do Classic Load Balancer estão configurados com o protocolo HTTPS ou TLS para conexões de front-end (cliente para balanceador de carga). O controle será aplicável se um Balanceador de Carga Clássico tiver ouvintes. Se o Balanceador de Carga Clássico não tiver um ouvinte configurado, o controle não relatará conclusões. O controle será aprovado se os ouvintes Balanceador de Carga Clássico forem configurados com TLS ou HTTPS para conexões de front-end. O controle falhará se o ouvinte não estiver configurado com TLS ou HTTPS para conexões de front-end. Antes de começar a usar um balanceador de carga, você deve adicionar um ou mais ouvintes. Um ouvinte é um processo que usa o protocolo configurado e a porta para verificar se há solicitações de conexão. Os ouvintes podem ser compatíveis com protocolos HTTP e HTTPS/TLS. Você sempre deve usar um ouvinte HTTPS ou TLS para que o balanceador de carga faça o trabalho de criptografia e descriptografia em trânsito.

Gravidade: Média

Os Balanceadores de Carga Clássicos devem ter o esvaziamento de conexões habilitado

Descrição: esse controle verifica se os Classic Load Balancers têm a drenagem de conexão habilitada. Habilitar a drenagem de conexão em Classic Load Balancers garante que o load balancer pare de enviar solicitações para instâncias que estão cancelando o registro ou não íntegras. Isso mantém as conexões existentes abertas. É útil para instâncias em grupos de Dimensionamento Automático, para garantir que as conexões não sejam interrompidas de forma muito repentina.

Gravidade: Média

As distribuições do CloudFront devem ter o AWS WAF habilitado

Descrição: esse controle verifica se as distribuições do CloudFront estão associadas às ACLs da web do AWS WAF ou do AWS WAFv2. O controle falhará se a distribuição não estiver associada a uma ACL Web. O AWS WAF é um firewall do aplicativo Web que ajuda a proteger aplicativos Web e APIs contra ataques. Ele permite que você configure um conjunto de regras, chamado de ACL Web (lista de controle de acesso Web), que permitem, bloqueiam ou contam as solicitações Web de acordo com as regras de segurança Web personalizáveis e as condições definidas por você. Verifique se a distribuição do CloudFront está associada a uma ACL Web do AWS WAF para ajudar a protegê-la contra ataques mal-intencionados.

Gravidade: Média

As distribuições do CloudFront devem ter o registra em log habilitado

Descrição: esse controle verifica se o registro em log de acesso ao servidor está habilitado nas distribuições do CloudFront. O controle falhará se o log de acesso não estiver habilitado para uma distribuição. Os logs de acesso do CloudFront fornecem informações detalhadas sobre cada solicitação de usuário recebida pelo CloudFront. Cada log contém informações, como a data e a hora em que a solicitação foi recebida, o endereço IP do visualizador que fez a solicitação, a origem da solicitação e o número da porta da solicitação do visualizador. Esses logs são úteis para aplicativos como auditorias de segurança e acesso e investigação forense. Para obter mais informações sobre como analisar logs de acesso, consulte Consultar logs do Amazon CloudFront no Guia do usuário do Amazon Athena.

Gravidade: Média

As distribuições do CloudFront devem exigir criptografia em trânsito

Descrição: esse controle verifica se uma distribuição do Amazon CloudFront exige que os visualizadores usem HTTPS diretamente ou se ela usa redirecionamento. O controle falhará se ViewerProtocolPolicy for definido como allow-all para defaultCacheBehavior ou para cacheBehaviors. O HTTPS (TLS) pode ser usado para ajudar a impedir que possíveis invasores usem ataques person-in-the-middle ou ataques semelhantes para espionar ou manipular o tráfego de rede. Somente conexões criptografadas por HTTPS (TLS) devem ser permitidas. Criptografar dados em trânsito pode afetar o desempenho. Você deve testar o aplicativo com esse recurso para entender o perfil de desempenho e o impacto do TLS.

Gravidade: Média

Os logs do CloudTrail devem ser criptografados em repouso usando os CMKs do KMS

Descrição: recomendamos configurar o CloudTrail para usar o SSE-KMS. A configuração do CloudTrail para usar o SSE-KMS fornece mais controles de confidencialidade nos dados de log, pois determinado usuário deve ter permissão de leitura S3 no bucket de log correspondente e deve receber permissão de descriptografia da política do CMK.

Gravidade: Média

As conexões com os clusters do Amazon Redshift devem ser criptografadas em trânsito

Descrição: esse controle verifica se as conexões com clusters do Amazon Redshift são necessárias para usar a criptografia em trânsito. A verificação falhará se o parâmetro de cluster do Amazon Redshift require_SSL não estiver definido como 1. O TLS pode ser usado para ajudar a impedir que possíveis invasores usem ataques person-in-the-middle ou ataques semelhantes para espionar ou manipular o tráfego de rede. Somente conexões criptografadas por TLS devem ser permitidas. Criptografar dados em trânsito pode afetar o desempenho. Você deve testar o aplicativo com esse recurso para entender o perfil de desempenho e o impacto do TLS.

Gravidade: Média

As conexões com os domínios do Elasticsearch devem ser criptografadas usando o TLS 1.2

Descrição: esse controle verifica se as conexões com domínios do Elasticsearch são necessárias para usar o TLS 1.2. A verificação falhará se o domínio do Elasticsearch TLSSecurityPolicy não for Policy-Min-TLS-1-2-2019-07. O HTTPS (TLS) pode ser usado para ajudar a impedir que possíveis invasores usem ataques person-in-the-middle ou ataques semelhantes para espionar ou manipular o tráfego de rede. Somente conexões criptografadas por HTTPS (TLS) devem ser permitidas. Criptografar dados em trânsito pode afetar o desempenho. Você deve testar o aplicativo com esse recurso para entender o perfil de desempenho e o impacto do TLS. O TLS 1.2 fornece vários aprimoramentos de segurança em relação a versões anteriores do TLS.

Gravidade: Média

As tabelas do DynamoDB devem ter a recuperação pontual habilitada

Descrição: esse controle verifica se a recuperação point-in-time (PITR) está habilitada para uma tabela do Amazon DynamoDB. Os backups ajudam você a se recuperar mais rapidamente de um incidente de segurança. Também reforçam a resiliência dos sistemas. A recuperação pontual do DynamoDB automatiza os backups das tabelas do DynamoDB. Ela reduz o tempo de recuperação das operações acidentais de exclusão ou gravação. As tabelas do DynamoDB que têm a PITR habilitada podem ser restauradas em qualquer período nos últimos 35 dias.

Gravidade: Média

A criptografia padrão do EBS deve estar habilitada

Descrição: esse controle verifica se a criptografia no nível da conta está habilitada por padrão para o Amazon Elastic Block Store (Amazon EBS). O controle falhará se a criptografia no nível da conta não estiver habilitada. Quando a criptografia está habilitada para a conta, os volumes e as cópias de instantâneo do Amazon EBS são criptografados em repouso. Isso adiciona outra camada de proteção para seus dados. Para obter mais informações, confira Criptografia por padrão no Guia do Usuário do Amazon EC2 para instâncias do Linux.

Os seguintes tipos de instância não oferecem suporte à criptografia: R1, C1 e M1.

Gravidade: Média

Os ambientes do Elastic Beanstalk devem ter os relatórios de saúde avançados habilitados

Descrição: esse controle verifica se os relatórios de integridade aprimorada estão habilitados para seus ambientes do AWS Elastic Beanstalk. O relatório avançado de integridade do Elastic Beanstalk permite uma resposta mais rápida a alterações na integridade da infraestrutura subjacente. Essas alterações podem resultar na falta de disponibilidade do aplicativo. O relatório avançado de integridade do Elastic Beanstalk fornece um descritor de status para medir a gravidade dos problemas identificados e identificar possíveis causas a serem investigadas. O agente de integridade do Elastic Beanstalk, incluído nas AMIs (Imagens de Computador da Amazon) com suporte, avalia os logs e as métricas das instâncias do EC2 do ambiente.

Gravidade: Baixa

As atualizações da plataforma gerenciada do Elastic Beanstalk devem estar habilitadas

Descrição: esse controle verifica se as atualizações de plataforma gerenciadas estão habilitadas para o ambiente do Elastic Beanstalk. Habilitar as atualizações da plataforma gerenciada garante que as correções, as atualizações e os recursos mais recentes disponíveis da plataforma para o ambiente sejam instalados. Manter-se atualizado com a instalação de patch é uma etapa importante na segurança de sistemas.

Gravidade: Alta

O Balanceador de Carga Elástico não deve ter o certificado ACM expirado ou expirando em 90 dias.

Descrição: essa verificação identifica os Elastic Load Balancers (ELB) que estão usando certificados do ACM expirados ou expirando em 90 dias. O ACM (Gerenciador de Certificados do AWS) é a ferramenta preferencial para provisionar, gerenciar e implantar seus certificados de servidor. Com o ACM. Você pode solicitar um certificado ou implantar um ACM existente ou um certificado externo nos recursos da AWS. Como melhor prática, é recomendável reimportar certificados que estão expirando/expirados, preservando as associações ELB do certificado original.

Gravidade: Alta

O log de erros de domínio do Elasticsearch para os Logs do CloudWatch devem estar habilitados

Descrição: esse controle verifica se os domínios do Elasticsearch estão configurados para enviar logs de erros ao CloudWatch Logs. Você deve habilitar os logs de erro para domínios do Elasticsearch e enviar esses logs para os Logs do CloudWatch para retenção e resposta. Os logs de erro de domínio podem auxiliar nas auditorias de segurança e acesso, bem como ajudar a diagnosticar problemas de disponibilidade.

Gravidade: Média

Os domínios do Elasticsearch devem ser configurados com pelo menos três nós mestres dedicados

Descrição: esse controle verifica se os domínios do Elasticsearch estão configurados com pelo menos três nós principais dedicados. Esse controle falhará se o domínio não usar nós mestres dedicados. Esse controle será aprovado se os domínios do Elasticsearch tiverem cinco nós mestres dedicados. No entanto, o uso de mais de três nós mestres pode ser desnecessário para reduzir o risco de disponibilidade e resultará em mais custos. Um domínio do Elasticsearch exige pelo menos três nós mestres dedicados para alta disponibilidade e tolerância a falhas. Os recursos do nó mestre dedicado podem ser sobrecarregados durante implantações azuis/verdes do nó de dados, pois há mais nós a serem gerenciados. Implantar um domínio do Elasticsearch com pelo menos três nós mestres dedicados garante a capacidade do recurso do nó mestre suficiente e as operações do cluster, caso um nó falhe.

Gravidade: Média

Os domínios do Elasticsearch devem ter pelo menos três nós de dados

Descrição: esse controle verifica se os domínios do Elasticsearch estão configurados com pelo menos três nós de dados e se zoneAwarenessEnabled é verdadeiro. Um domínio do Elasticsearch exige pelo menos três de dados para alta disponibilidade e tolerância a falhas. Implantar um domínio do Elasticsearch com pelo menos três nós de dados garante as operações do cluster, caso um nó falhe.

Gravidade: Média

Os domínios do Elasticsearch devem ter o log de auditoria habilitado

Descrição: esse controle verifica se os domínios do Elasticsearch têm o registro de auditoria ativado. Esse controle falhará se um domínio do Elasticsearch não tiver o log de auditoria habilitado. Os logs de auditoria são altamente personalizáveis. Eles permitem que você acompanhe a atividade do usuário nos clusters do Elasticsearch, incluindo êxitos e falhas de autenticação, solicitações para OpenSearch, alterações de índice e consultas de pesquisa de entrada.

Gravidade: Média

O monitoramento avançado deve ser configurado para clusters e instâncias do banco de dados do RDS

Descrição: esse controle verifica se o monitoramento avançado está habilitado para suas instâncias de banco de dados do RDS. No Amazon RDS, o Monitoramento Avançado permite uma resposta mais rápida às alterações no desempenho na infraestrutura subjacente. Esses alterações no desempenho podem resultar na falta de disponibilidade dos dados. O Monitoramento Avançado fornece métricas em tempo real do sistema operacional em que a instância do banco de dados do RDS é executada. Um agente é instalado na instância. O agente pode obter métricas de forma mais precisa do que é possível na camada do hipervisor. As métricas de Monitoramento Avançado são úteis quando você deseja ver como os diferentes processos ou threads em uma instância do banco de dados usam a CPU. Para obter mais informações, confira Monitoramento Avançado no Guia do Usuário do Amazon RDS.

Gravidade: Baixa

Verificar se a rotação para CMKs criadas pelo cliente está habilitada

Descrição: o AWS Key Management Service (KMS) permite que os clientes alternem a chave de backup, que é o material de chave armazenado no KMS vinculado ao ID da chave mestra do cliente (CMK) criada pelo cliente. É a chave de backup usada para executar operações criptográficas, como criptografia e descriptografia. No momento, a rotação de chaves automática retém todas as chaves de backup anteriores para que a descriptografia de dados criptografados possa ocorrer de forma transparente. É recomendável que a rotação de chaves CMK esteja habilitada. A rotação de chaves de criptografia ajuda a reduzir o impacto potencial de uma chave comprometida, pois os dados criptografados com uma nova chave não podem ser acessados com uma chave anterior que possa ter sido exposta.

Gravidade: Média

Verificar se o registro em log do acesso de bucket S3 está habilitado no bucket S3 CloudTrail

Descrição: o registro em log de acesso ao bucket do S3 gera um log que contém registros de acesso Certifique-se de que o log de acesso ao bucket do S3 esteja habilitado no bucket do CloudTrail S3 para cada solicitação feita ao bucket do S3. Um registro de log de acesso contém os detalhes sobre a solicitação, como o tipo de solicitação, os recursos especificados na solicitação, bem como a hora e a data em que a solicitação foi processada. É recomendável que o log de acesso do bucket esteja habilitado no bucket S3 do CloudTrail. Ao habilitar o registro em log de buckets do S3 em buckets do S3 de destino, é possível capturar todos os eventos que podem afetar objetos dentro de buckets de destino. A configuração de logs a serem colocados em um bucket separado permite o acesso a informações de log que podem ser úteis nos fluxos de trabalho de segurança e de resposta a incidentes.

Gravidade: Baixa

Verificar se o bucket S3 usado para armazenar os logs do CloudTrail não está acessível publicamente

Descrição: o CloudTrail registra um registro de todas as chamadas de API feitas em sua conta da AWS. Esses arquivos de log são armazenados em um bucket S3. É recomendável que a política de bucket, ou lista de controle de acesso (ACL), seja aplicada ao bucket do S3 que o CloudTrail registra para impedir o acesso público aos logs do CloudTrail. Permitir o acesso público ao conteúdo de log do CloudTrail pode ajudar um adversário a identificar pontos fracos no uso ou na configuração da conta afetada.

Gravidade: Alta

O IAM não deve ter certificados SSL/TLS expirados

Descrição: essa verificação identifica certificados SSL/TLS expirados. Para habilitar conexões HTTPS com seu site ou aplicativo no AWS, você precisa de um certificado de servidor SSL/TLS. Você pode usar o ACM ou o IAM para armazenar e implantar certificados de servidor. A remoção de certificados SSL/TLS expirados elimina o risco de que um certificado inválido seja implantado acidentalmente em um recurso, como o ELB (Elastic Load Balancer) do AWS, que pode prejudicar a credibilidade do aplicativo/site por trás do ELB. Essa verificação vai gerar alertas se houver certificados SSL/TLS expirados armazenados no IAM do AWS. Como melhor prática, é recomendável excluir certificados expirados.

Gravidade: Alta

Os certificados ACM importados devem ser renovados após um período especificado

Descrição: esse controle verifica se os certificados do ACM em sua conta estão marcados para expiração em 30 dias. Ele verifica tanto os certificados importados quanto os certificados fornecidos pelo AWS Certificate Manager. O ACM pode renovar automaticamente os certificados que usam a validação DNS. Para certificados que usam a validação de email, você deve responder a um email de validação de domínio. O ACM também não renova automaticamente os certificados importados. Você deve renovar manualmente os certificados importados. Para obter mais informações sobre a renovação gerenciada para certificados do ACM, confira Renovação gerenciada para certificados do ACM no Guia do Usuário do AWS Certificate Manager.

Gravidade: Média

As identidades provisionadas em excesso em contas devem ser investigadas para reduzir o PCI (Índice de Excesso de Permissões)

Descrição: as identidades provisionadas em contas devem ser investigadas para reduzir o PCI (Índice de Desvio de Permissão) e proteger sua infraestrutura. Reduza o PCI removendo as atribuições de permissão de alto risco não utilizadas. O PCI alto reflete o risco associado às identidades com permissões que excedem o uso normal ou necessário.

Gravidade: Média

As atualizações automáticas de versão secundária do RDS devem estar habilitadas

Descrição: esse controle verifica se as atualizações automáticas de versões secundárias estão habilitadas para a instância de banco de dados do RDS. Habilitar as atualizações automáticas da versão secundária garante que as atualizações da versão secundária mais recentes do RDBMS estejam instaladas. Essas atualizações podem incluir patches de segurança e correções de bugs. Manter-se atualizado com a instalação de patch é uma etapa importante na segurança de sistemas.

Gravidade: Alta

Os instantâneos de cluster do RDS e instantâneos do banco de dados devem ser criptografados em repouso

Descrição: esse controle verifica se os snapshots do banco de dados do RDS estão criptografados. Este controle destina-se a instâncias do banco de dados do RDS. No entanto, também pode gerar conclusões para instantâneos das instâncias do banco de dados do Aurora, instâncias do banco de dados do Neptune e clusters do Amazon DocumentDB. Se essas conclusões não forem úteis, você poderá suprimi-las. A criptografia de dados inativos reduz o risco de um usuário não autenticado obter acesso aos dados armazenados em disco. Os dados nos instantâneos do RDS devem ser criptografados em repouso para obter uma camada adicional de segurança.

Gravidade: Média

Os clusters do RDS devem ter a proteção contra exclusão habilitada

Descrição: esse controle verifica se os clusters do RDS têm a proteção contra exclusão habilitada. Este controle destina-se a instâncias do banco de dados do RDS. No entanto, também pode gerar conclusões para instâncias do banco de dados do Aurora, instâncias do banco de dados do Neptune e clusters do Amazon DocumentDB. Se essas conclusões não forem úteis, você poderá suprimi-las. Habilitar a proteção contra exclusão de cluster é outra camada de proteção contra exclusão acidental de banco de dados ou exclusão por uma entidade não autorizada. Quando a proteção contra exclusão está habilitada, não é possível excluir um cluster do RDS. Antes que uma solicitação de exclusão possa ser realizada com sucesso, a proteção contra exclusão deve ser desabilitada.

Gravidade: Baixa

Os clusters do banco de dados do RDS devem ser configurados para várias Zonas de Disponibilidade

Descrição: os clusters de banco de dados do RDS devem ser configurados para vários dados armazenados. A implantação em várias Zonas de Disponibilidade permite automatizar as Zonas de Disponibilidade para garantir a disponibilidade do ed failover, em caso de problema de disponibilidade da Zona de Disponibilidade e durante eventos regulares de manutenção do RDS.

Gravidade: Média

Os clusters do banco de dados do RDS devem ser configurados para copiar marcas em instantâneos

Descrição: A identificação e o inventário de seus ativos de TI são um aspecto crucial da governança e da segurança. Você precisa ter visibilidade de todos os clusters do banco de dados do RDS para avaliar a postura de segurança e tomar providências nas possíveis áreas de melhoria. Os instantâneos devem ser marcados da mesma maneira que os clusters do banco de dados pai do RDS. Habilitar dessa configuração garante que os instantâneos herdem as marcas dos clusters do banco de dados pai.

Gravidade: Baixa

As instâncias do banco de dados do RDS devem ser configuradas para copiar marcas em instantâneos

Descrição: esse controle verifica se as instâncias de banco de dados do RDS estão configuradas para copiar todas as tags para snapshots quando os snapshots são criados. A identificação e o inventário dos ativos de TI são um aspecto vital de governança e segurança. Você precisa ter visibilidade de todas as instâncias do banco de dados do RDS para avaliar a postura de segurança e tomar providências nas possíveis áreas de melhoria. Os instantâneos devem ser marcados da mesma maneira que as instâncias do banco de dados pai do RDS. Habilitar dessa configuração garante que os instantâneos herdem as marcas das instâncias do banco de dados pai.

Gravidade: Baixa

As instâncias do banco de dados do RDS devem ser configuradas com várias Zonas de Disponibilidade

Descrição: esse controle verifica se a alta disponibilidade está habilitada para suas instâncias de banco de dados do RDS. As instâncias do banco de dados do RDS devem ser configuradas para várias AZs (Zonas de Disponibilidade). Isso garante a disponibilidade dos dados armazenados. As implantações de várias zonas de disponibilidade permitem o failover automático, caso haja um problema com a disponibilidade da Zona de Disponibilidade e durante a manutenção regular do RDS.

Gravidade: Média

As instâncias do banco de dados do RDS devem ter a proteção contra exclusão habilitada

Descrição: esse controle verifica se as instâncias de banco de dados do RDS que usam um dos mecanismos de banco de dados listados têm a proteção contra exclusão habilitada. Habilitar a proteção contra exclusão de instâncias é outra camada de proteção contra exclusão acidental de banco de dados ou exclusão por uma entidade não autorizada. Embora a proteção contra exclusão esteja habilitada, não é possível excluir uma instância do banco de dados do RDS. Antes que uma solicitação de exclusão possa ser realizada com sucesso, a proteção contra exclusão deve ser desabilitada.

Gravidade: Baixa

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

Descrição: esse controle verifica se a criptografia de armazenamento está habilitada para suas instâncias de banco de dados do Amazon RDS. Este controle destina-se a instâncias do banco de dados do RDS. No entanto, também pode gerar conclusões para instâncias do banco de dados do Aurora, instâncias do banco de dados do Neptune e clusters do Amazon DocumentDB. Se essas conclusões não forem úteis, você poderá suprimi-las. Para obter uma camada adicional de segurança para os dados confidenciais nas instâncias do banco de dados do RDS, você deve configurar as instâncias do banco de dados do RDS para serem criptografadas em repouso. Para criptografar os instantâneos e as instâncias do banco de dados do RDS em repouso, habilite a opção de criptografia para as instâncias do banco de dados do RDS. Os dados criptografados em repouso incluem o armazenamento subjacente para instâncias do banco de dados, seus backups automáticos, réplicas de leitura e instantâneos. As instâncias do banco de dados criptografadas do RDS usam o algoritmo de criptografia AES-256 padrão aberto para criptografar os dados no servidor que hospeda as instâncias do banco de dados do RDS. Depois que os dados são criptografados, o Amazon RDS lida com a autenticação de acesso e descriptografia dos dados de forma transparente, com impacto mínimo no desempenho. Você não precisa modificar os aplicativos cliente do banco de dados para usar a criptografia. No momento, a criptografia do Amazon RDS está disponível para todos os mecanismos de banco de dados e tipos de armazenamento. A criptografia do Amazon RDS está disponível para a maioria das classes de instância do banco de dados. Para saber mais sobre as classes de instância de BD que não são compatíveis com a criptografia do Amazon RDS, confira Criptografia dos recursos do Amazon RDS no Guia do Usuário do Amazon RDS.

Gravidade: Média

As Instâncias do banco de dados do RDS devem proibir o acesso público

Descrição: recomendamos que você também garanta que o acesso à configuração da sua instância do RDS seja limitado apenas a usuários autorizados, restringindo as permissões do IAM dos usuários para modificar as configurações e os recursos das instâncias do RDS.

Gravidade: Alta

Os instantâneos do RDS devem proibir o acesso público

Descrição: recomendamos permitir que apenas entidades principais autorizadas acessem o snapshot e alterem a configuração do Amazon RDS.

Gravidade: Alta

Remover os segredos não utilizados do Secrets Manager

Descrição: esse controle verifica se seus segredos foram acessados dentro de um número especificado de dias. O valor padrão é de 90 dias. Se um segredo não tiver sido acessado no número definido de dias, esse controle falhará. Excluir segredos não utilizados é tão importante quanto a rotação de segredos. Os antigos usuários que não precisam mais acessar os segredos não utilizados podem abusar deles. Além disso, à medida que mais usuários têm acesso a um segredo, alguém pode ter feito o uso indevido e revelado o segredo para uma entidade não autorizada, o que aumenta o risco de abuso. A exclusão de segredos não utilizados ajuda a revogar o acesso ao segredo dos usuários que não precisam mais dele. Também ajuda a reduzir o custo do uso do Secrets Manager. Portanto, é essencial excluir regularmente os segredos não utilizados.

Gravidade: Média

Os buckets S3 devem ter a replicação entre regiões habilitada

Descrição: habilitar a replicação entre regiões do S3 garante que várias versões dos dados estejam disponíveis em diferentes regiões distintas. Isso permite que você proteja o bucket S3 contra ataques de DDoS e eventos de corrupção de dados.

Gravidade: Baixa

Os buckets S3 devem ter a criptografia do lado do servidor habilitada

Descrição: habilite a criptografia no lado do servidor para proteger os dados em seus buckets do S3. Criptografar os dados pode impedir o acesso a dados confidenciais, no caso de uma violação de dados.

Gravidade: Média

Os segredos do Secrets Manager configurados com a rotação automática devem girar com êxito

Descrição: esse controle verifica se um segredo do AWS Secrets Manager foi alternado com êxito com base na programação de alternância. O controle falhará se RotationOccurringAsScheduled for false. O controle não avalia segredos que não têm a rotação configurada. 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. Além de configurar segredos para girar automaticamente, você deve garantir que esses segredos girem com êxito de acordo com o agendamento de rotação. 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

Os segredos do Secrets Manager devem ser girados no prazo de dias especificado

Descrição: esse controle verifica se seus segredos foram alternados pelo menos uma vez em 90 dias. A rotação de segredos pode ajudar a reduzir o risco de uso não autorizado dos segredos na conta AWS. Os exemplos incluem credenciais de banco de dados, senhas, chaves de API de terceiros e até mesmo texto arbitrário. Se você não altera os segredos por um longo período, os segredos ficam mais propensos a serem comprometidos. À medida que mais usuários têm acesso a um segredo, aumenta a probabilidade de alguém ter feito o uso indevido e revelado os segredos para uma entidade não autorizada. Os segredos podem ser revelados por meio de logs e dados armazenados em cache. Eles podem ser compartilhados para fins de depuração e podem não alterados ou revogados após a conclusão da depuração. Por todos esses motivos, os segredos devem ser girados com frequência. Você pode configurar os segredos para rotação automática no AWS Secrets Manager. Com a rotação automática, você pode substituir segredos de longo prazo por segredos de curto prazo, reduzindo consideravelmente o risco de comprometimento. O Hub de Segurança recomenda que você habilite a rotação para os segredos do Secrets Manager. 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

Os tópicos do SNS devem ser criptografados em repouso usando o AWS KMS

Descrição: esse controle verifica se um tópico do SNS está criptografado em repouso usando o AWS KMS. A criptografia de dados inativos reduz o risco de que os dados armazenados em disco sejam acessados por um usuário não autenticado no AWS. Ela também adiciona outro conjunto de controles de acesso para limitar a capacidade de usuários não autorizados acessarem os dados. Por exemplo, as permissões de API são necessárias para descriptografar os dados, antes que possam ser lidos. Os tópicos do SNS devem ser criptografados em repouso para uma camada adicional de segurança. Para obter mais informações, confira Criptografia em repouso no Guia do Desenvolvedor do Amazon Simple Notification Service.

Gravidade: Média

O log de fluxo da VPC deve estar habilitado em todas as VPCs

Descrição: os logs de fluxo da VPC fornecem visibilidade do tráfego de rede que passa pela VPC e podem ser usados para detectar tráfego anômalo ou insights durante eventos de segurança.

Gravidade: Média

Recomendações de dados do GCP

Certifique-se de que o sinalizador de banco de dados '3625 (sinalizador de rastreamento)' para o Cloud SQL na instância do SQL Server esteja definido como 'desativado'

Descrição: é recomendável definir o sinalizador de banco de dados "3625 (sinalizador de rastreamento)" para a instância do Cloud SQL SQL Server como "desativado". Os sinalizadores de rastreamento são frequentemente usados para diagnosticar problemas de desempenho ou para depurar procedimentos armazenados ou sistemas de computador complexos, mas também podem ser recomendados pelo Suporte da Microsoft para lidar com o comportamento que está afetando negativamente uma carga de trabalho específica. Todos os sinalizadores de rastreamento documentados e aqueles recomendados pelo Suporte da Microsoft têm suporte total em um ambiente de produção quando usados conforme indicado. "3625(log de rastreamento)" Limita a quantidade de informações retornadas aos usuários que não são membros da função de servidor fixa sysadmin, mascarando os parâmetros de algumas mensagens de erro usando '******'. Isso pode ajudar a evitar a divulgação de informações confidenciais. Portanto, é recomendável desabilitar esse sinalizador. Essa recomendação é aplicável a instâncias do banco de dados SQL Server.

Gravidade: Média

Certifique-se de que o sinalizador do banco de dados 'scripts externos habilitados' para o Cloud SQL na instância do SQL Server esteja definido como 'desativado'

Descrição: é recomendável definir o sinalizador de banco de dados "scripts externos ativados" para a instância do SQL Server do Cloud SQL como desativado. "external scripts enabled" habilita a execução de scripts com certas extensões de linguagens remotas. Essa propriedade está DESATIVADA por padrão. Quando os Serviços de Análise Avançada estiverem instalados, opcionalmente, a instalação poderá definir essa propriedade como true. Como a funcionalidade "External Scripts Enabled" permite que scripts externos ao SQL, como arquivos localizados em uma biblioteca do R, possam afetar negativamente a segurança do sistema e, portanto, isso deve ser desabilitado. Essa recomendação é aplicável a instâncias do banco de dados SQL Server.

Gravidade: Alta

Certifique-se de que o sinalizador do banco de dados 'acesso remoto' para o Cloud SQL na instância do SQL Server esteja definida como 'desativado'

Descrição: é recomendável definir o sinalizador de banco de dados de "acesso remoto" para a instância do SQL Server do Cloud SQL como "desativado". A opção "acesso remoto" controla a execução de procedimentos armazenados de servidores locais ou remotos nos quais as instâncias do SQL Server estão sendo executadas. O valor padrão dessa opção é 1. Isso concede permissão para executar procedimentos armazenados locais de servidores remotos ou procedimentos armazenados remotos do servidor local. Para evitar que procedimentos armazenados locais sejam executados a partir de um servidor remoto ou que procedimentos armazenados remotos sejam executados no servidor local, isso deverá ser desabilitado. A opção Acesso Remoto controla a execução de procedimentos armazenados locais em servidores remotos ou procedimentos armazenados remotos no servidor local. A funcionalidade 'acesso remoto' pode ser abusada para inicializar um ataque de Negação de Serviço (DoS) em servidores remotos ao desativar o processamento de consulta para um destino e, portanto, isso deve ser desabilitado. Essa recomendação é aplicável a instâncias do banco de dados SQL Server.

Gravidade: Alta

Certifique-se de que o sinalizador do banco de dados 'skip_show_database' da instância do MySQL do Cloud SQL esteja definido como 'ativado'

Descrição: é recomendável definir a sinalização de banco de dados "skip_show_database" para a instância Mysql do Cloud SQL como "ativada". O sinalizador de banco de dados 'skip_show_database' impede que as pessoas usem a instrução SHOW DATABASES se não tiverem o privilégio SHOW DATABASES. Isso pode melhorar a segurança se você tiver preocupações de que os usuários possam ver bancos de dados pertencentes a outros usuários. Seu efeito depende do privilégio SHOW DATABASES: se o valor da variável for ON, a instrução SHOW DATABASES será permitida somente aos usuários que têm o privilégio SHOW DATABASES e a instrução exibirá todos os nomes de banco de dados. Se o valor for OFF, SHOW DATABASES será permitido a todos os usuários, mas exibirá os nomes somente dos bancos de dados para os quais o usuário tem o privilégio SHOW DATABASES ou outro. Essa recomendação é aplicável a instâncias do banco de dados MySQL.

Gravidade: Baixa

Certifique-se de que uma Chave de Criptografia gerenciada pelo Cliente (CMEK) padrão esteja especificada para todos os Conjuntos de Dados BigQuery

Descrição: por padrão, o BigQuery criptografa os dados como repouso empregando a criptografia de envelope usando chaves criptográficas gerenciadas pelo Google. Os dados são criptografados usando as chaves de criptografia de dados e as chaves de criptografia de dados são criptografadas ainda mais usando chaves de criptografia de chave. Isso é contínuo e não exige nenhuma entrada adicional do usuário. No entanto, se você quiser ter maior controle, a CMEK (chave de criptografia gerenciada pelo cliente) poderá ser usada como solução de gerenciamento de chaves de criptografia para conjuntos de dados do BigQuery. Por padrão, o BigQuery criptografa os dados como inativos empregando a Criptografia de Envelope usando chaves criptográficas gerenciadas pelo Google. Isso é perfeito e não requer nenhuma entrada adicional do usuário. Para ter maior controle sobre a criptografia, a CMEK (chave de criptografia gerenciada pelo cliente) poderá ser usada como solução de gerenciamento de chaves de criptografia para conjuntos de dados do BigQuery. Definir uma CMEK (chave de criptografia gerenciada pelo cliente) padrão para um conjunto de dados garante que todas as tabelas criadas no futuro usem a CMEK especificada se nenhuma outra for fornecida.

O Google não armazena suas chaves em seus servidores e não pode acessar seus dados protegidos, a menos que você forneça a chave.

Isso também significa que, se você esquecer ou perder sua chave, não há como o Google recuperar a chave ou recuperar quaisquer dados criptografados com a chave perdida.

Gravidade: Média

Certifique-se de que todas as Tabelas BigQuery estejam criptografadas com a Chave de criptografia gerenciada pelo cliente (CMEK)

Descrição: por padrão, o BigQuery criptografa os dados como repouso empregando a criptografia de envelope usando chaves criptográficas gerenciadas pelo Google. Os dados são criptografados usando as chaves de criptografia de dados e as chaves de criptografia de dados são criptografadas ainda mais usando chaves de criptografia de chave. Isso é contínuo e não exige nenhuma entrada adicional do usuário. No entanto, se você quiser ter maior controle, a CMEK (chave de criptografia gerenciada pelo cliente) poderá ser usada como solução de gerenciamento de chaves de criptografia para conjuntos de dados do BigQuery. Se a CMEK for usada, ela será usada para criptografar as chaves de criptografia de dados em vez de usar chaves de criptografia gerenciadas pelo Google. Por padrão, o BigQuery criptografa os dados como inativos empregando a Criptografia de Envelope usando chaves criptográficas gerenciadas pelo Google. Isso é perfeito e não requer nenhuma entrada adicional do usuário. Para ter maior controle sobre a criptografia, a CMEK (chave de criptografia gerenciada pelo cliente) poderá ser usada como solução de gerenciamento de chaves de criptografia para tabelas do BigQuery. A CMEK é usada para criptografar as chaves de criptografia de dados em vez de usar chaves de criptografia gerenciadas pelo Google. O BigQuery armazena a tabela e a associação CMEK e a criptografia/descriptografia é feita automaticamente. A aplicação das chaves gerenciadas pelo cliente padrão em conjuntos de dados do BigQuery garante que todas as novas tabelas criadas no futuro sejam criptografadas usando a CMEK, mas as tabelas existentes precisam ser atualizadas para usar a CMEK individualmente.

O Google não armazena suas chaves em seus servidores e não pode acessar seus dados protegidos, a menos que você forneça a chave. Isso também significa que, se você esquecer ou perder sua chave, não há como o Google recuperar a chave ou recuperar quaisquer dados criptografados com a chave perdida.

Gravidade: Média

Certifique-se de que os conjuntos de dados de BigQuery não estejam acessíveis de modo público nem anônimo

Descrição: é recomendável que a política do IAM em conjuntos de dados do BigQuery não permita 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 estiverem sendo armazenados no conjunto de dados. Portanto, certifique-se de que o acesso anônimo e/ou público a um conjunto de dados não seja permitido.

Gravidade: Alta

Certifique-se de que as instâncias do banco de dados Cloud SQL estejam configuradas com backups automatizados

Descrição: é recomendável ter todas as instâncias do banco de dados SQL definidas para habilitar backups automatizados. Os backups oferecem uma maneira de restaurar uma instância do Cloud SQL a fim de recuperar dados perdidos ou se recuperar de um problema com essa instância. Os backups automatizados precisam ser definidos para qualquer instância que contenha dados que devem ser protegidos contra perda ou danos. Essa recomendação é aplicável para instâncias do SQL Server, PostgreSql, MySql geração 1 e MySql geração 2.

Gravidade: Alta

Garantir que as instâncias do banco de dados do Cloud SQL não sejam abertas para o mundo

Descrição: o servidor de banco de dados deve aceitar conexões somente de rede(s)/IP(s) confiáveis(s) e restringir o acesso do mundo. Para minimizar a superfície de ataque em uma instância do servidor de banco de dados, somente IPs confiáveis/conhecidos e necessários devem ser aprovados para se conectar a ela. Uma rede autorizada não deve ter IPs/redes configurados para 0.0.0.0/0, o que permitirá o acesso à instância de qualquer lugar do mundo. Observe que as redes autorizadas se aplicam somente a instâncias com IPs públicos.

Gravidade: Alta

Certifique-se de que as instâncias do banco de dados Cloud SQL não tenham IPs públicos

Descrição: é recomendável configurar a instância do Sql de segunda geração para usar IPs privados em vez de IPs públicos. Para reduzir a superfície de ataque da organização, os bancos de dados do Cloud SQL não devem ter IPs públicos. Os IPs privados oferecem segurança de rede aprimorada e menor latência para seu aplicativo.

Gravidade: Alta

Certifique-se de que o bucket do Cloud Storage não esteja acessível de modo público nem anônimo

Descrição: é recomendável que a política do IAM no bucket do Cloud Storage não permita acesso anônimo ou público. Permitir acesso anônimo ou público concede permissões a qualquer pessoa para acessar o conteúdo do bucket. Esse acesso pode não ser desejado se você estiver armazenando dados confidenciais. Portanto, certifique-se de que o acesso anônimo ou público a um bucket não seja permitido.

Gravidade: Alta

Verifique se os buckets do armazenamento em nuvem têm o acesso em nível de bucket uniforme habilitado

Descrição: é recomendável que o acesso uniforme no nível do intervalo seja ativado nos intervalos do Cloud Storage. É recomendável usar o acesso uniforme no nível do intervalo para unificar e simplificar a forma como você concede acesso aos recursos do Cloud Storage. O armazenamento em nuvem oferece dois sistemas para conceder aos usuários permissão para acessar seus buckets e objetos: Cloud Identity and Access Management (Cloud IAM) e ACLs (Listas de Controle de Acesso).
Esses sistemas atuam em paralelo – para que um usuário acesse um recurso de armazenamento em nuvem, apenas um dos sistemas precisa conceder permissão ao usuário. O IAM na Nuvem é usado em todo o Google Cloud e permite que você conceda uma variedade de permissões nos níveis de bucket e projeto. As ACLs são usadas apenas pelo armazenamento em nuvem e têm opções de permissão limitadas, mas permitem que você conceda permissões por objeto.

Para dar suporte a um sistema de permissões uniforme, o armazenamento em nuvem tem acesso uniforme no nível do bucket. O uso desse recurso desabilita ACLs para todos os recursos de Armazenamento em Nuvem: o acesso aos recursos do armazenamento em nuvem é concedido exclusivamente por meio do IAM na Nuvem. A ativação do acesso uniforme no nível do bucket garante que, se um bucket de armazenamento não estiver acessível publicamente, nenhum objeto no bucket também estará acessível publicamente.

Gravidade: Média

Certifique-se de que as instâncias de Computação estejam com a Computação Confidencial habilitada

Descrição: o Google Cloud criptografa os dados em repouso e em trânsito, mas os dados do cliente precisam ser descriptografados para processamento. A Computação Confidencial é uma tecnologia inovadora que criptografa os dados em uso enquanto estão sendo processados. Ambientes de computação confidencial mantêm os dados criptografados na memória e em outros lugares fora da CPU (unidade de processamento central). As VMs confidenciais aproveitam o recurso SEV (virtualização criptografada segura) das CPUs AMD EPYC. Os dados do cliente permanecerão criptografados enquanto são usados, indexados, consultados ou treinados. As chaves de criptografia são geradas em hardware, por VM e não são exportáveis. Graças às otimizações de hardware internas de desempenho e segurança, não há penalidade significativa de desempenho para cargas de trabalho de computação confidencial. A computação confidencial permite o código confidencial dos clientes e outros dados criptografados na memória durante o processamento. O Google não tem acesso às chaves de criptografia. A VM confidencial pode ajudar a aliviar as preocupações sobre o risco relacionado à dependência da infraestrutura do Google ou ao acesso de insiders do Google aos dados do cliente de forma clara.

Gravidade: Alta

Certifique-se de que as políticas de retenção em buckets de log estejam configuradas usando o Bloqueio de Bucket

Descrição: a ativação de políticas de retenção em buckets de log protegerá os logs armazenados em buckets de armazenamento em nuvem de serem substituídos ou excluídos acidentalmente. É recomendável configurar políticas de retenção e configurar o Bloqueio de Bucket em todos os buckets de armazenamento usados como coletores de log. Os logs podem ser exportados criando um ou mais coletores que incluem um filtro de log e um destino. À medida que o Stackdriver Logging recebe novas entradas de registro, elas são comparadas com cada coletor. Se uma entrada de log corresponder ao filtro de um coletor, uma cópia da entrada de log será gravada no destino. Os coletores podem ser configurados para exportar logs em buckets de armazenamento. É recomendável configurar uma política de retenção de dados para esses buckets de armazenamento em nuvem e bloquear a política de retenção de dados; evitando assim permanentemente que a apólice seja reduzida ou removida. Dessa forma, se o sistema for comprometido por um invasor ou um insider mal-intencionado que deseja cobrir seus rastros, os logs de atividades serão definitivamente preservados para investigações forenses e de segurança.

Gravidade: Baixa

Certifique-se de que a instância do banco de dados Cloud SQL exija que todas as conexões de entrada usem SSL

Descrição: é recomendável impor todas as conexões de entrada à instância do banco de dados SQL para usar SSL. Conexões de banco de dados SQL se capturadas com sucesso (MITM); pode revelar dados confidenciais, como credenciais, consultas de banco de dados, saídas de consulta, etc. Por segurança, é recomendável sempre usar a criptografia SSL ao se conectar à sua instância. Essa recomendação é aplicável a instâncias Postgresql, MySql geração 1 e MySql geração 2.

Gravidade: Alta

Certifique-se de que o sinalizador do banco de dados 'autenticação de banco de dados independente' para o Cloud SQL na instância do SQL Server esteja definido como 'desativado'

Descrição: é recomendável definir o sinalizador de banco de dados "autenticação de banco de dados independente" para o Cloud SQL na instância do SQL Server definido como "desativado". Um banco de dados independente inclui todas as configurações de banco de dados e metadados necessários para definir o banco de dados e não tem dependências de configuração na instância do Mecanismo de Banco de Dados em que o banco de dados está instalado. Os usuários podem se conectar ao banco de dados sem autenticar um logon no nível do Mecanismo de Banco de Dados. O isolamento do banco de dados do Mecanismo de Banco de Dados facilita mover o banco de dados para outra instância do SQL Server. Bancos de dados independentes têm algumas ameaças exclusivas que devem ser entendidas e mitigadas pelos administradores do Mecanismo de Banco de Dados do SQL Server . A maioria das ameaças está relacionada ao processo de autenticação USER WITH PASSWORD que move o limite de autenticação do nível do Mecanismo de Banco de Dados para o nível do banco de dados e, portanto, isso é recomendado para desabilitar esse sinalizador. Essa recomendação é aplicável a instâncias do banco de dados SQL Server.

Gravidade: Média

Certifique-se de que a sinalização de banco de dados 'encadeamento de propriedade entre bancos de dados' da instância para o Cloud SQL na instância do SQL Server esteja definida como 'desativada'

Descrição: é recomendável definir o sinalizador de banco de dados "encadeamento de propriedade entre bancos de dados" para a instância do SQL Server do Cloud SQL como "desativado". Use a opção "propriedade cruzada do banco de dados" para encadeamento para configurar o encadeamento de propriedade entre bancos de dados para uma instância do Microsoft SQL Server. Essa opção de servidor permite que você controle o encadeamento de propriedade no nível do banco de dados ou em todos os bancos de dados. Habilitar a "propriedade entre bancos de dados" não é recomendado, a menos que todos os bancos de dados hospedados pela instância do SQL Server devam participar do encadeamento de propriedade entre bancos de dados e você esteja ciente das implicações de segurança dessa configuração. Essa recomendação é aplicável a instâncias do banco de dados SQL Server.

Gravidade: Média

Certifique-se de que a sinalização do banco de dados 'local_infile' para o Cloud SQL em uma instância do MySQL esteja definida como 'desativada'

Descrição: é recomendável definir a sinalização do banco de dados local_infile para uma instância do MySQL do Cloud SQL como desativada. O sinalizador local_infile controla a capacidade LOCAL do lado do servidor para instruções LOAD DATA. Dependendo da configuração do local_infile, o servidor recusa ou permite o carregamento de dados locais por clientes que têm LOCAL habilitado no lado do cliente. Para fazer com que o servidor recuse explicitamente instruções LOAD DATA LOCAL (independentemente de como os programas e bibliotecas cliente são configurados no tempo de compilação ou no tempo de execução), comece mysqld com local_infile desabilitado. O local_infile também pode ser definido em runtime. Devido a problemas de segurança associados ao sinalizador local_infile, é recomendável desativá-lo. Essa recomendação é aplicável a instâncias do banco de dados MySQL.

Gravidade: Média

Certifique-se de que haja um filtro de métrica de log e alertas para alterações de permissão de IAM do armazenamento em nuvem

Descrição: é recomendável que um filtro de métrica e um alarme sejam estabelecidos para alterações do IAM do bucket do Cloud Storage. O monitoramento de alterações nas permissões do bucket do Cloud Storage pode reduzir o tempo necessário para detectar e corrigir permissões em buckets e objetos confidenciais do Cloud Storage dentro do bucket.

Gravidade: Baixa

Certifique-se de que haja um filtro de métrica de log e alertas para alterações a configurações de instância do SQL

Descrição: é recomendável que um filtro de métrica e um alarme sejam estabelecidos para alterações de configuração da instância SQL. O monitoramento de alterações nas alterações de configuração da instância SQL pode reduzir o tempo necessário para detectar e corrigir configurações incorretas feitas no SQL Server. Abaixo estão algumas das opções configuráveis que podem afetar a postura de segurança de uma instância SQL:

• Habilite backups automáticos e alta disponibilidade: a configuração incorreta pode afetar negativamente a continuidade dos negócios, a recuperação de desastres e a alta disponibilidade
• Autorizar redes: a configuração incorreta pode aumentar a exposição a redes não confiáveis

Gravidade: Baixa

Certifique-se de que haja apenas chaves de conta de serviço gerenciadas pelo GCP para cada conta de serviço

Descrição: as contas de serviço gerenciadas pelo usuário não devem ter chaves gerenciadas pelo usuário. Qualquer pessoa que tenha acesso às chaves poderá acessar recursos por meio da conta de serviço. As chaves gerenciadas pelo GCP são usadas por serviços do Cloud Platform, como o Mecanismo de Aplicativo e o Mecanismo de Computação. Essas chaves não podem ser baixadas. O Google manterá as chaves e as girará automaticamente com frequência aproximadamente semanal. As chaves gerenciadas pelo usuário são criadas, baixáveis e gerenciadas pelos usuários. Elas expiram 10 anos após a criação. Para chaves gerenciadas pelo usuário, o usuário precisa se apropriar das atividades de gerenciamento de chaves, que incluem:

• Armazenamento de chave
• Distribuição de chaves
• Revogação de chave
• Alteração de chaves
• Proteção de chave contra usuários não autorizados
• Recuperação de chave

Mesmo com as precauções do proprietário da chave, as chaves podem ser facilmente vazadas por práticas de desenvolvimento comuns abaixo do ideal, como verificar as chaves no código-fonte ou deixá-las no diretório Downloads ou deixá-las acidentalmente em blogs/canais de suporte. É recomendável evitar chaves de conta de serviço gerenciadas pelo usuário.

Gravidade: Baixa

Certifique-se de que o sinalizador de banco de dados 'conexões de usuário' para o Cloud SQL na instância do SQL Server esteja definido conforme apropriado

Descrição: é recomendável definir o sinalizador de banco de dados "conexões do usuário" para a instância do Cloud SQL SQL Server de acordo com o valor definido pela organização. A opção "user connections" especifica o número máximo de conexões de usuário simultâneas permitido em uma instância do SQL Server. O número real de conexões de usuário permitidas também depende da versão do SQL Server que você está usando e também dos limites do aplicativo ou aplicativos e do hardware. SQL Server permite um máximo de 32.767 conexões de usuário. Como as conexões de usuário são uma opção dinâmica (autoconfigurada), o SQL Server ajusta o número máximo de conexões de usuário automaticamente conforme necessário, até o valor máximo permitido. Por exemplo, se somente 10 usuários estiverem conectados, 10 objetos de conexão de usuário serão alocados. Na maioria dos casos, não é necessário alterar o valor dessa opção. O padrão é 0, o que significa que as permitidas conexões máximas (32,767) de usuário são permitidas. Essa recomendação é aplicável a instâncias do banco de dados SQL Server.

Gravidade: Baixa

Certifique-se de que o sinalizador do banco de dados 'opções do usuário' para o Cloud SQL na instância do SQL Server não esteja configurado

Descrição: é recomendável que o sinalizador de banco de dados "opções do usuário" para a instância do Cloud SQL SQL Server não seja configurado. A opção "user options" especifica padrões globais para todos os usuários. Uma lista de opções de processamento de consulta padrão é definida para a duração da sessão de trabalho de um usuário. A configuração de opções do usuário permite que você altere os valores padrão das opções SET (se as configurações padrão do servidor não forem apropriadas). Um usuário pode substituir esses padrões usando a instrução SET. Você pode configurar user options dinamicamente para novos logons. Depois de alterar a configuração das opções do usuário, as novas sessões de login usam a nova configuração; As sessões de login atuais não são afetadas. Essa recomendação é aplicável a instâncias do banco de dados SQL Server.

Gravidade: Baixa

O registro em log para clusters do GKE deve estar habilitado

Descrição: essa recomendação avalia se a propriedade loggingService de um cluster contém o local que o Cloud Logging deve usar para gravar registros.

Gravidade: Alta

O controle de versão do objeto deve estar habilitado em buckets de armazenamento nos quais os coletores estão configurados

Descrição: essa recomendação avalia se o campo enabled na propriedade de versionamento do bucket está definido como true.

Gravidade: Alta

As identidades provisionadas em excesso em projetos devem ser investigadas para reduzir o PCI (Permission Creep Index)

Descrição: as identidades superprovisionadas em projetos devem ser investigadas para reduzir o PCI (Índice de Fluência de Permissões) e proteger sua infraestrutura. Reduza o PCI removendo as atribuições de permissão de alto risco não utilizadas. O PCI alto reflete o risco associado às identidades com permissões que excedem o uso normal ou necessário.

Gravidade: Média

Projetos que têm chaves criptográficas não devem ter usuários com permissões de Proprietário

Descrição: essa recomendação avalia a política de permissão do IAM nos metadados do projeto para as entidades principais atribuídas a funções/proprietário.

Gravidade: Média

Os buckets de armazenamento usados como coletor de log não devem ser acessíveis publicamente

Descrição: essa recomendação avalia a política do IAM de um bucket para as entidades principais allUsers ou allAuthenticatedUsers, que concedem acesso público.

Gravidade: Alta

Conteúdo relacionado

• Saiba mais sobre as recomendações de segurança
• Revise as recomendações de segurança