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

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

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

Gorjeta

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

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

Recomendações de dados do Azure

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

Descrição: Desativar 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 endpoints privados pode limitar a exposição da sua conta do Cosmos DB. Mais informações. (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 habilitação para 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 exigido por requisitos de conformidade ou políticas restritivas. Para habilitar essa recomendação, navegue até sua Política de Segurança para obter o escopo aplicável e atualize o parâmetro Effect para a política correspondente para auditar ou impor o uso de chaves gerenciadas pelo cliente. Saiba mais em Gerir 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 por serviço, mas as chaves gerenciadas pelo cliente (CMK) geralmente são necessárias para atender aos padrões de conformidade regulamentar. As CMKs permitem que os dados sejam criptografados com uma chave do Cofre da Chave do Azure criada 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 espaços de trabalho do Azure Machine Learning devem ser criptografados com uma chave gerenciada pelo cliente (CMK)

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 habilitação para 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 exigido por requisitos de conformidade ou políticas restritivas. Para habilitar essa recomendação, navegue até sua Política de Segurança para obter o escopo aplicável e atualize o parâmetro Effect para a política correspondente para auditar ou impor o uso de chaves gerenciadas pelo cliente. Saiba mais em Gerir políticas de segurança. Gerencie a criptografia no restante dos dados do espaço de trabalho do Azure Machine Learning com chaves gerenciadas pelo cliente (CMK). Por padrão, os dados do cliente são criptografados com chaves gerenciadas por serviço, mas as CMKs geralmente são necessárias para atender aos padrões de conformidade regulamentar. As CMKs permitem que os dados sejam criptografados com uma chave do Cofre da Chave do Azure criada 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 espaços de trabalho do Azure Machine Learning devem ser criptografados com uma chave gerenciada pelo cliente (CMK)).

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 TLS como 1.2 ou mais recente melhora a segurança, garantindo que seu Banco de Dados SQL do Azure só possa ser acessado de clientes que usam TLS 1.2 ou mais recente. O uso de versões do TLS inferiores a 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 estar executando o TLS versão 1.2 ou mais recente).

Gravidade: Média

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

Descrição: A desativação do acesso à rede pública (ponto de extremidade público) nas Instâncias Gerenciadas 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 SQL do Azure devem desabilitar o acesso à rede pública).

Gravidade: Média

As contas do Cosmos DB devem usar link privado

Descrição: O Azure Private Link permite conectar sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma Private Link lida com a conectividade entre o consumidor e os serviços através da rede de backbone do Azure. Quando os endpoints privados são mapeados para sua conta do Cosmos DB, os riscos de vazamento de dados são reduzidos. Saiba mais sobre links privados. (Política relacionada: As contas do Cosmos DB devem usar 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 habilitação para 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 exigido por requisitos de conformidade ou políticas restritivas. Para habilitar essa recomendação, navegue até sua Política de Segurança para obter o escopo aplicável e atualize o parâmetro Effect para a política correspondente para auditar ou impor o uso de chaves gerenciadas pelo cliente. Saiba mais em Gerir 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 por serviço, mas as chaves gerenciadas pelo cliente (CMK) geralmente são necessárias para atender aos padrões de conformidade regulamentar. As CMKs permitem que os dados sejam criptografados com uma chave do Cofre da Chave do Azure criada e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo rotação e gerenciamento. (Política relacionada: Traga sua própria chave de proteção de dados deve ser ativado 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 habilitação para 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 exigido por requisitos de conformidade ou políticas restritivas. Para habilitar essa recomendação, navegue até sua Política de Segurança para obter o escopo aplicável e atualize o parâmetro Effect para a política correspondente para auditar ou impor o uso de chaves gerenciadas pelo cliente. Saiba mais em Gerir 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 por serviço, mas as chaves gerenciadas pelo cliente (CMK) geralmente são necessárias para atender aos padrões de conformidade regulamentar. As CMKs permitem que os dados sejam criptografados com uma chave do Cofre da Chave do Azure criada e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo rotação e gerenciamento. (Política relacionada: Traga sua própria chave de proteção de dados deve ser habilitada para servidores PostgreSQL).

Gravidade: Baixa

(Ativar, se necessário) As instâncias gerenciadas pelo 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 habilitação para 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 exigido por requisitos de conformidade ou políticas restritivas. Para habilitar essa recomendação, navegue até sua Política de Segurança para obter o escopo aplicável e atualize o parâmetro Effect para a política correspondente para auditar ou impor o uso de chaves gerenciadas pelo cliente. Saiba mais em Gerir políticas de segurança. A implementação da Criptografia de Dados Transparente (TDE) com sua própria chave proporciona maior transparência e controle sobre o Protetor TDE, maior segurança com um serviço externo apoiado por HSM e promoção da separação de tarefas. Esta recomendação aplica-se a organizações com um requisito de conformidade relacionado. (Política relacionada: As instâncias gerenciadas pelo 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 habilitação para 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 exigido por requisitos de conformidade ou políticas restritivas. Para habilitar essa recomendação, navegue até sua Política de Segurança para obter o escopo aplicável e atualize o parâmetro Effect para a política correspondente para auditar ou impor o uso de chaves gerenciadas pelo cliente. Saiba mais em Gerir políticas de segurança. A implementação da Criptografia de Dados Transparente (TDE) com sua própria chave proporciona maior transparência e controle sobre o Protetor TDE, maior segurança com um serviço externo apoiado por HSM e promoção da separação de tarefas. Esta recomendação aplica-se 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 chave gerenciada pelo cliente (CMK) 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 habilitação para 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 exigido por requisitos de conformidade ou políticas restritivas. Para habilitar essa recomendação, navegue até sua Política de Segurança para obter o escopo aplicável e atualize o parâmetro Effect para a política correspondente para auditar ou impor o uso de chaves gerenciadas pelo cliente. Saiba mais em Gerir políticas de segurança. Proteja sua conta de armazenamento com maior flexibilidade usando chaves gerenciadas pelo cliente (CMKs). Quando você especifica uma CMK, essa chave é usada para proteger e controlar o acesso à chave que criptografa seus dados. O uso de CMKs fornece recursos adicionais para controlar a rotação da chave de criptografia de chave ou apagar dados criptograficamente. (Política relacionada: As contas de armazenamento devem usar a chave gerenciada pelo cliente (CMK) para criptografia).

Gravidade: Baixa

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

Descrição: o acesso público de leitura anónimo a contentores e blobs no Armazenamento do Azure é uma forma conveniente de partilhar dados, mas pode apresentar riscos de segurança. Para evitar violações de dados causadas por acesso anônimo indesejado, a Microsoft recomenda impedir o acesso público a uma conta de armazenamento, a menos que seu cenário exija.

Política relacionada: O acesso público da conta de armazenamento não deve ser permitido

Gravidade: Média

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

Descrição: é recomendável habilitar todos os tipos avançados de proteção contra ameaças em suas instâncias gerenciadas pelo SQL. Habilitar todos os tipos protege contra injeção de SQL, vulnerabilidades de banco de dados e quaisquer outras atividades anômalas. (Nenhuma política relacionada)

Gravidade: Média

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

Descrição: Recomenda-se habilitar todos os tipos avançados de proteção contra ameaças em seus servidores SQL. Habilitar todos os tipos protege contra injeção de SQL, vulnerabilidades de banco de dados e quaisquer outras atividades anômalas. (Nenhuma política relacionada)

Gravidade: Média

Os serviços de 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 não relacionada à Internet à qual você controla o acesso. Essas redes podem ser conectadas às suas redes locais usando várias tecnologias VPN, que permitem o acesso aos seus serviços de back-end dentro da rede e/ou no local. O portal do desenvolvedor e o gateway de API podem ser configurados para serem acessíveis a partir da Internet ou somente dentro da rede virtual. (Política relacionada: Os serviços de Gerenciamento de API devem usar uma rede virtual).

Gravidade: Média

A configuração do aplicativo deve usar link privado

Descrição: O Azure Private Link permite conectar 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 lida com a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Ao mapear pontos de extremidade privados para as instâncias de configuração do seu aplicativo 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 do Aplicativo deve usar link privado).

Gravidade: Média

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

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

Gravidade: Baixa

A auditoria no SQL Server deve ser habilitada

Descrição: habilite a auditoria no SQL Server para controlar 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 servidor SQL 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 for Cloud coleta dados de suas máquinas virtuais do Azure. Os dados são coletados pelo agente do Log Analytics, anteriormente conhecido como Microsoft Monitoring Agent (MMA), que lê várias configurações relacionadas à segurança e logs de eventos da máquina e copia os dados para o espaço de trabalho do Log Analytics para análise. Recomendamos habilitar o provisionamento automático para implantar automaticamente o agente em todas as VMs do Azure com suporte e em quaisquer novas que sejam criadas. (Política relacionada: O provisionamento automático do agente do Log Analytics deve ser habilitado na sua assinatura).

Gravidade: Baixa

O Cache Redis do Azure deve residir em uma rede virtual

Descrição: A implantação da Rede Virtual do Azure (VNet) fornece segurança e isolamento aprimorados para seu 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 Redis do Azure é configurada com uma VNet, ela não é endereçável publicamente e só pode ser acessada de máquinas virtuais e aplicativos dentro da VNet. (Política relacionada: O Cache Redis do Azure deve residir em uma rede virtual).

Gravidade: Média

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

Descrição: provisione um administrador do Azure AD para seu 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 Ative Directory do Azure deve ser provisionado para servidores MySQL).

Gravidade: Média

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

Descrição: provisione um administrador do Azure AD para seu Banco de Dados do Azure para PostgreSQL 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 Ative Directory deve ser provisionado para servidores PostgreSQL).

Gravidade: Média

O banco de dados do Azure para servidor flexível PostgreSQL deve ter a autenticação do Microsoft Entra habilitada apenas

Descrição: Desabilitar métodos de autenticação local e exigir autenticação do Microsoft Entra melhora a segurança garantindo que o Banco de Dados do Azure para servidor flexível PostgreSQL possa ser acessado apenas por identidades do Microsoft Entra (Política relacionada: o servidor flexível do Azure PostgreSQL deve ter a Autenticação Somente 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 IP definida com o filtro de rede virtual ativado são consideradas compatíveis. As contas que desativam o acesso público também são consideradas compatíveis. (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 link privado

Descrição: O Azure Private Link permite conectar 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 lida com a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Ao mapear pontos de extremidade privados para 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 link privado).

Gravidade: Média

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

Descrição: O Azure Private Link permite conectar 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 lida com a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Ao mapear endpoints 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 link privado).

Gravidade: Média

Os espaços de trabalho do Azure Machine Learning devem usar link privado

Descrição: O Azure Private Link permite conectar 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 lida com a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Ao mapear pontos de extremidade privados para seus espaços de trabalho 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 espaços de trabalho do Azure Machine Learning devem usar link privado).

Gravidade: Média

O Serviço Azure SignalR deve usar link privado

Descrição: O Azure Private Link permite conectar 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 lida com a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Ao mapear 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 Azure SignalR deve usar link privado).

Gravidade: Média

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 o Azure Spring Cloud para interagir com sistemas em data centers locais ou com o serviço do Azure em outras redes virtuais. 3. Capacite os clientes para controlar as comunicações de rede de entrada e saída para o Azure Spring Cloud. (Política relacionada: O Azure Spring Cloud deve usar a injeção de rede).

Gravidade: Média

Os servidores SQL devem ter um administrador do Azure Ative Directory provisionado

Descrição: provisione um administrador do Azure AD para seu servidor SQL 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 Ative Directory deve ser provisionado para servidores SQL).

Gravidade: Alta

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

Descrição: O modo de autenticação do Azure Synapse Workspace deve ser Somente Azure Ative Directory Os métodos de autenticação somente do Azure Ative Directory melhoram a segurança, garantindo que os Espaços de Trabalho Synapse exijam exclusivamente identidades do Azure AD para autenticação. Mais informações. (Política relacionada: Os Espaços de Trabalho Synapse devem usar apenas identidades do Azure Ative Directory para autenticação).

Gravidade: Média

Os repositórios de código devem ter as descobertas de varredura de código resolvidas

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

Gravidade: Média

Os repositórios de código devem ter as descobertas de varredura do Dependabot resolvidas

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

Gravidade: Média

Os repositórios de código devem ter infraestrutura à medida que os resultados da varredura de código forem resolvidos

Descrição: O Defender for DevOps encontrou problemas de configuração de segurança de código em repositórios. Os problemas mostrados abaixo foram detetados em arquivos de modelo. Para melhorar a postura de segurança dos recursos de nuvem relacionados, é altamente recomendável corrigir esses problemas. (Nenhuma política relacionada)

Gravidade: Média

Os repositórios de código devem ter as descobertas de varredura secretas resolvidas

Descrição: O Defender for DevOps encontrou um segredo nos repositórios de código. Esta situação deve ser corrigida imediatamente para evitar uma violação da segurança. Segredos encontrados em repositórios podem ser vazados ou descobertos por adversários, levando ao comprometimento de um aplicativo ou serviço. Para o Azure DevOps, a ferramenta Microsoft Security DevOps CredScan verifica apenas as compilações nas quais foi configurada para ser executada. Portanto, os resultados podem não refletir o status completo dos segredos em seus repositórios. (Nenhuma política relacionada)

Gravidade: Alta

As contas dos Serviços Cognitivos devem permitir a encriptação de dados

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

Gravidade: Baixa

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

Descrição: esta política audita qualquer conta de Serviços Cognitivos que não utilize armazenamento de propriedade do cliente nem encriptação de dados. Para cada conta de 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 Repositório Azure Data Lake devem ser habilitados

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

Gravidade: Baixa

Os logs de diagnóstico no Data Lake Analytics devem ser habilitados

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

Gravidade: Baixa

A notificação por e-mail para alertas de alta gravidade deve ser ativada

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 e-mail para alertas de alta gravidade no Defender for Cloud. (Política relacionada: A notificação por e-mail para alertas de alta gravidade deve ser ativada).

Gravidade: Baixa

A notificação por e-mail ao proprietário da assinatura para alertas de alta gravidade deve ser habilitada

Descrição: para garantir que os proprietários da sua subscrição são notificados quando existe uma potencial violação de segurança na respetiva subscrição, defina notificações por e-mail aos proprietários da subscrição para alertas de elevada gravidade no Defender for Cloud. (Política relacionada: A notificação por e-mail ao proprietário da assinatura para alertas de alta gravidade deve ser ativada).

Gravidade: Média

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

Descrição: O Banco de Dados do Azure para MySQL dá suporte à conexão do seu Banco de Dados do Azure para servidor MySQL a aplicativos cliente usando SSL (Secure Sockets Layer). A imposição de conexões SSL entre o servidor de banco de dados e os aplicativos cliente ajuda a proteger contra ataques "man in the middle", criptografando o fluxo de dados entre o servidor e seu aplicativo. Essa configuração impõe que o SSL esteja sempre habilitado para acessar o 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 habilitado para servidores de banco de dados PostgreSQL

Descrição: O Banco de Dados do Azure para PostgreSQL dá suporte à conexão do seu Banco de Dados do Azure para servidor PostgreSQL a aplicativos cliente usando SSL (Secure Sockets Layer). A imposição de conexões SSL entre o servidor de banco de dados e os aplicativos cliente ajuda a proteger contra ataques "man in the middle", criptografando o fluxo de dados entre o servidor e seu aplicativo. Essa configuração impõe que o SSL esteja sempre habilitado para acessar o 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ção devem ter as descobertas de vulnerabilidade resolvidas

Descrição: A verificação de vulnerabilidades em tempo de execução para funções verifica seus aplicativos funcionais em busca de vulnerabilidades de segurança e expõe descobertas detalhadas. Resolver as vulnerabilidades pode melhorar muito a postura de segurança de seus aplicativos sem servidor e protegê-los de ataques. (Nenhuma 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 seu 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 apenas armazenados na região em que o servidor está hospedado, mas também são replicados para uma região emparelhada para fornecer 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 seu 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 apenas armazenados na região em que o servidor está hospedado, mas também são replicados para uma região emparelhada para fornecer 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 seu 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 apenas armazenados na região em que o servidor está hospedado, mas também são replicados para uma região emparelhada para fornecer 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 verificação 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, triar e priorizar correções para problemas existentes em seu código. A verificação de código também pode impedir que os desenvolvedores introduzam novos problemas. As verificações podem ser agendadas 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 encontrar uma vulnerabilidade ou erro potencial no código, o GitHub exibirá um alerta no repositório. Uma vulnerabilidade é um problema no código de um projeto que pode ser explorado para danificar a confidencialidade, integridade ou disponibilidade do projeto. (Nenhuma política relacionada)

Gravidade: Média

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

Descrição: O GitHub envia alertas do Dependabot quando deteta vulnerabilidades nas dependências de código que afetam os repositórios. Uma vulnerabilidade é um problema no código de um projeto que pode ser explorado para danificar a confidencialidade, integridade ou disponibilidade do projeto ou de outros projetos que usam seu código. As vulnerabilidades variam em 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. (Nenhuma política relacionada)

Gravidade: Média

Os repositórios do GitHub devem ter a verificação secreta ativada

Descrição: O GitHub verifica os repositórios em busca de tipos conhecidos de segredos, para evitar o uso fraudulento de segredos que foram acidentalmente cometidos em repositórios. A verificação secreta verificará todo o histórico do Git em todas as ramificações presentes no repositório GitHub em busca de quaisquer segredos. Exemplos de segredos são tokens e chaves privadas que um provedor de serviços pode emitir para autenticação. Se um segredo for verificado em um repositório, qualquer pessoa que tenha acesso de leitura ao repositório poderá usá-lo 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. (Nenhuma política relacionada)

Gravidade: Alta

Os servidores do Banco de Dados SQL do Microsoft Defender for Azure devem ser habilitados

Descrição: O Microsoft Defender for SQL é um pacote unificado que fornece recursos avançados de segurança SQL. Ele inclui funcionalidade para revelar e mitigar possíveis vulnerabilidades do banco de dados, detetar atividades anômalas que possam indicar uma ameaça ao seu banco de dados e descobrir e classificar dados confidenciais.

As proteções deste plano são cobradas conforme mostrado na página de planos do Defender. Se você não tiver nenhum servidor do Banco de Dados SQL do Azure nesta assinatura, não será cobrado. Se, posteriormente, criar servidores da Base de Dados SQL do Azure nesta subscrição, estes serão automaticamente protegidos e as cobranças começarão. Saiba mais sobre os detalhes de preços por região.

Saiba mais em Introdução ao Microsoft Defender para SQL. (Política relacionada: Os servidores do Banco de Dados SQL do Azure Defender for Azure devem ser habilitados).

Gravidade: Alta

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 for DNS alerta-o sobre atividades suspeitas na camada DNS. Saiba mais em Introdução ao Microsoft Defender para DNS. Habilitar este plano Defender resulta em cobranças. Saiba mais sobre os detalhes de preços por região na página de preços do Defender for Cloud: Preços do Defender for Cloud. (Nenhuma política relacionada)

Gravidade: Alta

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

Descrição: O Microsoft Defender para bancos de dados relacionais de código aberto deteta atividades anômalas indicando 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.

Habilitar esse plano resultará em cobranças para proteger seus bancos de dados relacionais de código aberto. Se você não tiver nenhum banco de dados relacional de código aberto nesta assinatura, nenhuma cobrança será cobrada. Se você criar bancos de dados relacionais de código aberto nesta assinatura no futuro, eles serão automaticamente protegidos e as cobranças começarão nesse momento. (Nenhuma política relacionada)

Gravidade: Alta

O Microsoft Defender for Resource Manager deve estar habilitado

Descrição: O Microsoft Defender for Resource Manager monitoriza automaticamente as operações de gestão de recursos na sua organização. O Defender for Cloud deteta ameaças e alerta-o sobre atividades suspeitas. Saiba mais em Introdução ao Microsoft Defender for Resource Manager. Habilitar este plano Defender resulta em cobranças. Saiba mais sobre os detalhes de preços por região na página de preços do Defender for Cloud: Preços do Defender for Cloud. (Nenhuma política relacionada)

Gravidade: Alta

O Microsoft Defender para SQL em máquinas deve ser habilitado em espaços de trabalho

Descrição: O Microsoft Defender para servidores oferece deteção de ameaças e defesas avançadas para suas máquinas Windows e Linux. Com este plano Defender ativado em suas assinaturas, mas não em seus espaços de trabalho, 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 espaço de trabalho, todas as máquinas que se reportam a esse espaço de trabalho serão cobradas pelo 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, essas máquinas não poderão aproveitar o acesso de VM just-in-time, controles de aplicativos adaptáveis e deteções de rede para recursos do Azure. Saiba mais em Introdução ao Microsoft Defender para servidores. (Nenhuma política relacionada)

Gravidade: Média

Microsoft Defender para SQL servidores em máquinas deve ser habilitado

Descrição: O Microsoft Defender for SQL é um pacote unificado que fornece recursos avançados de segurança SQL. Ele inclui funcionalidade para revelar e mitigar possíveis vulnerabilidades do banco de dados, detetar atividades anômalas que possam indicar uma ameaça ao seu banco de dados e descobrir e classificar dados confidenciais.

A correção dessa recomendação resultará em cobranças para proteger seus servidores SQL em máquinas. Se você não tiver nenhum servidor SQL em máquinas nesta assinatura, nenhuma cobrança será cobrada. Se você criar quaisquer servidores SQL em máquinas com essa assinatura no futuro, eles serão automaticamente protegidos e as cobranças começarão nesse momento. Saiba mais sobre o Microsoft Defender para servidores SQL em máquinas. (Política relacionada: O Azure Defender para SQL servers em máquinas deve ser habilitado).

Gravidade: Alta

O Microsoft Defender for SQL deve ser habilitado para servidores SQL do Azure desprotegidos

Descrição: O Microsoft Defender for SQL é um pacote unificado que fornece recursos avançados de segurança SQL. Ele revela e mitiga possíveis vulnerabilidades do banco de dados e deteta atividades anômalas que podem indicar uma ameaça ao seu banco de dados. O Microsoft Defender for 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 for SQL deve ser habilitado para instâncias gerenciadas SQL desprotegidas

Descrição: O Microsoft Defender for SQL é um pacote unificado que fornece recursos avançados de segurança SQL. Ele revela e mitiga possíveis vulnerabilidades do banco de dados e deteta atividades anômalas que podem indicar uma ameaça ao seu banco de dados. O Microsoft Defender for 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 SQL).

Gravidade: Alta

O Microsoft Defender for Storage deve estar habilitado

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

As proteções deste plano são cobradas conforme mostrado na página de planos do Defender. Se não tiver quaisquer contas de Armazenamento do Azure nesta subscrição, não será cobrado. Se, posteriormente, criar contas de Armazenamento do Azure nesta subscrição, estas serão automaticamente protegidas e as cobranças começarão. Saiba mais sobre os detalhes de preços por região. Saiba mais em Introdução ao Microsoft Defender for Storage. (Política relacionada: O Azure Defender for Storage deve estar habilitado).

Gravidade: Alta

O Inspetor de Rede deve estar ativado

Descrição: o Inspetor 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 no nível do cenário permite diagnosticar problemas em uma exibição de nível de rede de ponta a ponta. As ferramentas de diagnóstico e visualização de rede disponíveis com o Observador de Rede ajudam-no a compreender, diagnosticar e obter informações sobre a sua rede no Azure. (Política relacionada: O Inspetor de Rede deve estar ativado).

Gravidade: Baixa

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

Descrição: As conexões de ponto de extremidade privado impõem 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

Ponto de extremidade privado deve ser habilitado para servidores MariaDB

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

Gravidade: Média

Ponto de extremidade privado deve ser habilitado para servidores MySQL

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

Gravidade: Média

Ponto de extremidade privado deve ser habilitado para servidores PostgreSQL

Descrição: As conexões de ponto de extremidade privado impõem comunicação segura habilitando a conectividade privada com o Banco de Dados do Azure para PostgreSQL. Configure uma conexão de ponto de extremidade privada para habilitar o acesso ao tráfego proveniente apenas de redes conhecidas e impedir o acesso de todos os outros endereços IP, inclusive 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 seu Banco de Dados SQL do Azure só possa ser acessado de um ponto de extremidade privado. Essa configuração nega todos os logins que correspondam às regras de firewall baseadas em IP ou rede virtual. (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 desativado para contas de Serviços Cognitivos

Descrição: esta política audita qualquer conta de Serviços Cognitivos em seu ambiente com o acesso à rede pública habilitado. O acesso à rede pública deve ser desativado para que apenas sejam permitidas ligações a partir de terminais privados. (Política relacionada: O acesso à rede pública deve ser desativado para contas de Serviços Cognitivos).

Gravidade: Média

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

Descrição: desative a propriedade de acesso à rede pública para melhorar a segurança e garantir que seu Banco de Dados do Azure para MariaDB só possa ser acessado a partir 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 às regras de firewall baseadas em IP ou rede virtual. (Política relacionada: O acesso à rede pública deve ser desativado para servidores MariaDB).

Gravidade: Média

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

Descrição: desative a propriedade de acesso à rede pública para melhorar a segurança e garantir que seu Banco de Dados do Azure para MySQL só possa ser acessado a partir 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 às regras de firewall baseadas em IP ou rede virtual. (Política relacionada: O acesso à rede pública deve ser desativado para servidores MySQL).

Gravidade: Média

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

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

Gravidade: Média

O Cache Redis deve permitir acesso somente via SSL

Descrição: Habilite apenas conexões via SSL para Cache Redis. O uso de conexões seguras garante a autenticação entre o servidor e o serviço e protege os dados em trânsito contra ataques da camada de rede, como man-in-the-middle, escutas e sequestro de sessão. (Política relacionada: Somente conexões seguras com seu Cache Redis do Azure 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 o 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 do seu banco de dados. Saiba mais (Política relacionada: as vulnerabilidades em seus bancos de dados SQL devem ser corrigidas).

Gravidade: Alta

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

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

Gravidade: Alta

Servidores SQL em máquinas devem ter descobertas de vulnerabilidade resolvidas

Descrição: A avaliação de vulnerabilidades do SQL verifica o 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 do seu banco de dados. Saiba mais (Política relacionada: as vulnerabilidades em seus servidores SQL na máquina devem ser corrigidas).

Gravidade: Alta

Os servidores SQL devem ter um administrador do Azure Ative Directory provisionado

Descrição: provisione um administrador do Azure AD para seu servidor SQL 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 Ative Directory deve ser provisionado para servidores SQL).

Gravidade: Alta

Os servidores SQL devem ter a avaliação de vulnerabilidades configurada

Descrição: a avaliação de vulnerabilidades pode descobrir, rastrear e ajudá-lo 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 uma comunicação segura, fornecendo conectividade privada à 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 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 no Azure AD e suporte para tags e grupos de recursos para facilitar o gerenciamento de segurança. Saiba mais (Política relacionada: as contas de armazenamento devem ser migradas para os novos recursos do Azure Resource Manager).

Gravidade: Baixa

As contas de armazenamento devem impedir o acesso à chave compartilhada

Descrição: Requisito de auditoria do Azure Ative Directory (Azure AD) para autorizar solicitações para sua conta de armazenamento. Por padrão, as solicitações podem ser autorizadas com credenciais do Azure Ative Directory ou usando a chave de acesso da conta para autorização de Chave Compartilhada. Desses dois tipos de autorização, o Azure AD oferece 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 ameaças potenciais usando regras de rede virtual como método preferencial em vez de filtragem baseada em IP. A desativação da 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 subscrições devem ter um endereço de e-mail de contacto para questões 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 e-mail do Defender for Cloud. (Política relacionada: As subscrições devem ter um endereço de e-mail de contacto para questões de segurança)

Gravidade: Baixa

A criptografia de dados transparente 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 criptografia de dados transparente em bancos de dados SQL deve ser habilitada).

Gravidade: Baixa

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

Descrição: Auditar modelos do Construtor de Imagens de VM que não têm uma rede virtual configurada. Quando uma rede virtual não é 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 VM Image Builder devem usar link privado).

Gravidade: Média

O Web Application Firewall (WAF) deve ser habilitado para o Application Gateway

Descrição: Implante o Firewall de Aplicativo Web do Azure (WAF) na frente de aplicativos Web voltados para o público para inspeção adicional do tráfego de entrada. O Web Application Firewall (WAF) fornece proteção centralizada de seus aplicativos Web contra exploits e vulnerabilidades comuns, como injeções de SQL, scripts entre sites e execuções de arquivos locais e remotos. Também pode restringir o acesso às suas aplicações Web por países/regiões, intervalos de endereços IP e outros parâmetros http(s) através de regras personalizadas. (Política relacionada: O Web Application Firewall (WAF) deve estar habilitado para o Application Gateway).

Gravidade: Baixa

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

Descrição: Implante o Firewall de Aplicativo Web do Azure (WAF) na frente de aplicativos Web voltados para o público para inspeção adicional do tráfego de entrada. O Web Application Firewall (WAF) fornece proteção centralizada de seus aplicativos Web contra exploits e vulnerabilidades comuns, como injeções de SQL, scripts entre sites e execuções de arquivos locais e remotos. Também pode restringir o acesso às suas aplicações Web por países/regiões, intervalos de endereços IP e outros parâmetros http(s) através de regras personalizadas. (Política relacionada: O Web Application Firewall (WAF) deve ser habilitado para o serviço Azure Front Door?service)

Gravidade: Baixa

Recomendações de dados da AWS

Clusters do Amazon Aurora devem ter backtracking habilitado

Descrição: esse controle verifica se os clusters do Amazon Aurora têm backtracking habilitado. Os backups ajudam você a se recuperar mais rapidamente de um incidente de segurança. Eles também fortalecem a resiliência de seus sistemas. O backtracking do Aurora reduz o tempo de recuperação de um banco de dados para um point-in-time. Ele não requer uma restauração de banco de dados para fazer isso. Para obter mais informações sobre backtracking no Aurora, consulte Backtracking de um cluster de banco de dados do Aurora no Guia do usuário do Amazon Aurora.

Gravidade: Média

Os snapshots do Amazon EBS não devem ser restauráveis publicamente

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

Gravidade: Alta

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

Descrição: esse controle verifica se uma definição de tarefa ativa do Amazon ECS com modo de rede de host também tem definições de contêiner privilegiado ou de usuário. O controle falha para definições de tarefa que têm modo de rede host e definições de contêiner onde privileged=false ou está vazio e user=root ou está vazio. Se uma definição de tarefa tem 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 nó a nó habilitada. O HTTPS (TLS) pode ser usado para ajudar a impedir que invasores em potencial espionem ou manipulem o tráfego da rede usando ataques de pessoa no meio ou semelhantes. Somente conexões criptografadas por HTTPS (TLS) devem ser permitidas. A ativação da criptografia nó a nó para domínios do Amazon ES garante que as comunicações dentro do cluster sejam criptografadas em trânsito. Pode haver uma penalidade de desempenho associada a essa configuração. Você deve estar ciente e testar a compensação de desempenho antes de ativar essa opção.

Gravidade: Média

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

Descrição: é importante habilitar as criptografias restantes de 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 RDS criptografados com chaves KMS padrão e não com chaves gerenciadas pelo cliente. Como prática líder, use chaves gerenciadas pelo cliente para criptografar os dados em seus bancos de dados RDS e manter o controle de suas chaves e dados em cargas de trabalho confidenciais.

Gravidade: Média

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

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

Gravidade: Média

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

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

Gravidade: Média

Os clusters do Amazon Redshift devem ter snapshots automáticos habilitados

Descrição: esse controle verifica se os clusters do Amazon Redshift têm snapshots automatizados habilitados. Ele também verifica se o período de retenção de snapshot é maior ou igual a sete. Os backups ajudam você a se recuperar mais rapidamente de um incidente de segurança. Eles fortalecem a resiliência dos seus sistemas. O Amazon Redshift tira snapshots periódicos por padrão. Esse controle verifica se os instantâneos automáticos estão habilitados e retidos 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

Clusters do Amazon Redshift devem proibir acesso público

Descrição: recomendamos que os clusters do Amazon Redshift evitem a acessibilidade pública avaliando o campo 'publiclyAccessible' no item de configuração do cluster.

Gravidade: Alta

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

Descrição: esse controle verifica se as atualizações automáticas de versões principais estão habilitadas para o cluster do Amazon Redshift. A ativação de atualizações automáticas de versões principais garante que as atualizações de versão principal mais recentes para 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 patches é um passo importante para proteger os 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 criptografia do lado do servidor (SSE) permite transmitir dados confidenciais em filas criptografadas. Para proteger o conteúdo de mensagens em filas, o SSE usa chaves gerenciadas no AWS KMS. Para obter mais informações, consulte Criptografia em repouso no Guia do desenvolvedor do Amazon Simple Queue Service.

Gravidade: Média

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

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 chave-valor da categoria do evento. DBCluster: [Manutenção e falha]. As notificações de eventos do RDS usam o Amazon SNS para informar sobre alterações na disponibilidade ou configuração dos recursos do RDS. Estas notificações permitem uma resposta rápida. Para obter mais informações sobre notificações de eventos do RDS, consulte Usar notificação de eventos do Amazon RDS no Guia do usuário do Amazon RDS.

Gravidade: Baixa

Uma assinatura de notificações de eventos RDS deve ser configurada para eventos críticos de instância 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 chave-valor da categoria do evento. DBInstance: [Manutenção, alteração de configuração e falha]. As notificações de eventos do RDS usam o Amazon SNS para informar sobre alterações na disponibilidade ou configuração dos recursos do RDS. Estas notificações permitem uma resposta rápida. Para obter mais informações sobre notificações de eventos do RDS, consulte Usar notificação de eventos do Amazon RDS no Guia do usuário do Amazon RDS.

Gravidade: Baixa

Uma assinatura de notificações de eventos RDS deve ser configurada para eventos críticos do parameter group 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 chave-valor da categoria do evento. DBParameterGroup: ["configuração","alterar"]. As notificações de eventos do RDS usam o Amazon SNS para informar sobre alterações na disponibilidade ou configuração dos recursos do RDS. Estas notificações permitem uma resposta rápida. Para obter mais informações sobre notificações de eventos do RDS, consulte Usar notificação de eventos do Amazon RDS no Guia do usuário do Amazon RDS.

Gravidade: Baixa

Uma assinatura de notificações de eventos RDS deve ser configurada para eventos críticos do grupo de segurança 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 chave-valor da categoria do evento. DBSecurityGroup: [Configuração, alteração, falha]. As notificações de eventos do RDS usam o Amazon SNS para informar sobre alterações na disponibilidade ou configuração dos recursos do RDS. Estas notificações permitem uma resposta rápida. Para obter mais informações sobre notificações de eventos do RDS, consulte Usar notificação de eventos do Amazon RDS no Guia do usuário do Amazon RDS.

Gravidade: Baixa

O log da API Gateway REST e da API WebSocket deve ser 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 log não for ERROR nem INFO. Os estágios da API Gateway REST ou WebSocket API devem ter logs relevantes habilitados. O log de execução da API Gateway REST e WebSocket API fornece registros detalhados das solicitações feitas aos estágios REST e WebSocket API do API Gateway. Os estágios incluem respostas de back-end de integração de API, respostas do autorizador do Lambda e o requestId para endpoints de integração da AWS.

Gravidade: Média

Os dados de cache da API REST do API Gateway 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 cache habilitado estão criptografados. O controle falhará se qualquer método em um estágio de API REST do API Gateway estiver configurado para cache e o cache não estiver criptografado. A criptografia de dados em repouso reduz o risco de os dados armazenados no disco serem acessados por um usuário não autenticado na AWS. Ele 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 eles possam ser lidos. Os caches de API REST do API Gateway devem ser criptografados em repouso para uma camada adicional de segurança.

Gravidade: Média

Os estágios da API REST do API Gateway 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 API Gateway. Os estágios da API REST do API Gateway devem ser configurados com certificados SSL para permitir que os sistemas de back-end autentiquem que as solicitações são originadas do API Gateway.

Gravidade: Média

Os estágios da API REST do API Gateway devem ter o AWS X-Ray Tracing 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 de raios-X permite uma resposta mais rápida às mudanças de desempenho na infraestrutura subjacente. Alterações no desempenho podem resultar em falta de disponibilidade da API. O rastreamento ativo do X-Ray fornece métricas em tempo real das solicitações do usuário que fluem através de suas operações de API REST do API Gateway e serviços conectados.

Gravidade: Baixa

O API Gateway deve ser associado a uma ACL da 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 da web do AWS WAF não estiver conectada a um estágio do REST API Gateway. O AWS WAF é um firewall de aplicativos da web que ajuda a proteger aplicativos da web e APIs contra ataques. Ele permite que você configure uma ACL, que é um conjunto de regras que permitem, bloqueiam ou contam solicitações da Web com base em regras e condições de segurança da Web personalizáveis que você define. Certifique-se de que o estágio do API Gateway esteja associado a uma ACL da web do AWS WAF para ajudar a protegê-lo de ataques mal-intencionados.

Gravidade: Média

O registro em log de aplicativos e Classic Load Balancers deve ser habilitado

Descrição: esse controle verifica se o Application Load Balancer e o Classic Load Balancer têm o registro em log habilitado. O controle falhará se access_logs.s3.enabled for false. O Elastic Load Balancing fornece logs de acesso que capturam informações detalhadas sobre solicitações enviadas ao seu load balancer. Cada log contém informações como a hora em que a solicitação foi recebida, o endereço IP do cliente, latências, caminhos de solicitação e respostas do servidor. Você pode usar logs de acesso para analisar padrões de tráfego e solucionar problemas. Para saber mais, consulte Logs de acesso para seu Classic Load Balancer no Guia do Usuário para Classic Load Balancers.

Gravidade: Média

Os volumes do EBS anexados 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 passar nessa verificação, os volumes do EBS devem estar em uso e criptografados. Se o volume do EBS não estiver anexado, ele não estará sujeito a essa verificação. Para obter uma camada adicional de segurança de seus dados confidenciais em volumes do EBS, você deve habilitar a criptografia do EBS em repouso. A criptografia do Amazon EBS oferece uma solução de criptografia direta para seus recursos do EBS que não exige que você crie, mantenha e proteja sua própria infraestrutura de gerenciamento de chaves. Ele usa chaves mestras do cliente (CMK) do AWS KMS ao criar volumes e snapshots criptografados. Para saber mais sobre a criptografia do Amazon EBS, consulte Criptografia do Amazon EBS no Guia do usuário do Amazon EC2 para instâncias do Linux.

Gravidade: Média

As instâncias de replicação do AWS Database Migration Service não devem ser públicas

Descrição: para proteger as instâncias replicadas contra ameaças. Uma instância de replicação privada deve ter um endereço IP privado que você não pode 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 estiverem na mesma rede e a rede estiver conectada à VPC da instância de replicação usando uma VPN, AWS Direct Connect ou emparelhamento de VPC. Você também deve garantir que o acesso à configuração da instância do AWS DMS seja limitado apenas a usuários autorizados. Para fazer isso, restrinja as permissões do IAM dos usuários para modificar as configurações e os recursos do AWS DMS.

Gravidade: Alta

Os ouvintes do Classic Load Balancer 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 front-end (cliente para balanceador de carga). O controle é aplicável se um Classic Load Balancer tiver ouvintes. Se o seu Classic Load Balancer não tiver um ouvinte configurado, o controle não relatará nenhuma descoberta. O controle passa se os ouvintes do Classic Load Balancer estiverem configurados com TLS ou HTTPS para conexões front-end. O controle falhará se o ouvinte não estiver configurado com TLS ou HTTPS para conexões 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 e a porta configurados para verificar solicitações de conexão. Os ouvintes podem suportar os protocolos HTTP e HTTPS/TLS. Você deve sempre 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 Classic Load Balancers devem ter a drenagem de conexões habilitada

Descrição: Este 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 íntegros. Ele mantém as conexões existentes abertas. Isso é útil para instâncias em grupos de Auto Scaling, para garantir que as conexões não sejam cortadas abruptamente.

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 da Web. O AWS WAF é um firewall de aplicativos da web que ajuda a proteger aplicativos da web e APIs contra ataques. Ele permite que você configure um conjunto de regras, chamado de lista de controle de acesso à Web (ACL da Web), que permitem, bloqueiam ou contam solicitações da Web com base em regras e condições de segurança da Web personalizáveis que você define. Certifique-se de que sua distribuição do CloudFront esteja associada a uma ACL da web do AWS WAF para ajudar a protegê-la de ataques mal-intencionados.

Gravidade: Média

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

Descrição: esse controle verifica se o 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 que o CloudFront recebe. 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 usa redirecionamento. O controle falhará se ViewerProtocolPolicy estiver definido como allow-all para defaultCacheBehavior ou para cacheBehaviors. O HTTPS (TLS) pode ser usado para ajudar a impedir que invasores em potencial usem ataques de pessoa no meio ou semelhantes para espionar ou manipular o tráfego da rede. Somente conexões criptografadas por HTTPS (TLS) devem ser permitidas. A criptografia de dados em trânsito pode afetar o desempenho. Você deve testar seu 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 CMKs KMS

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

Gravidade: Média

As conexões com 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 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 invasores em potencial usem ataques de pessoa no meio ou semelhantes para espionar ou manipular o tráfego da rede. Somente conexões criptografadas por TLS devem ser permitidas. A criptografia de dados em trânsito pode afetar o desempenho. Você deve testar seu aplicativo com esse recurso para entender o perfil de desempenho e o impacto do TLS.

Gravidade: Média

As conexões com domínios do Elasticsearch devem ser criptografadas usando 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 invasores em potencial usem ataques de pessoa no meio ou semelhantes para espionar ou manipular o tráfego da rede. Somente conexões criptografadas por HTTPS (TLS) devem ser permitidas. A criptografia de dados em trânsito pode afetar o desempenho. Você deve testar seu 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 às versões anteriores do TLS.

Gravidade: Média

As tabelas do DynamoDB devem ter a recuperação point-in-time 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. Eles também fortalecem a resiliência de seus sistemas. A recuperação point-in-time do DynamoDB automatiza backups para tabelas do DynamoDB. Ele reduz o tempo de recuperação de operações acidentais de exclusão ou gravação. As tabelas do DynamoDB com o PITR ativado podem ser restauradas para qualquer point-in-time nos últimos 35 dias.

Gravidade: Média

A criptografia padrão do EBS deve ser 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 sua conta, os volumes e as cópias de snapshot do Amazon EBS são criptografados em repouso. Isso adiciona outra camada de proteção para seus dados. Para obter mais informações, consulte 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 suportam criptografia: R1, C1 e M1.

Gravidade: Média

Os ambientes do Elastic Beanstalk devem ter relatórios de integridade aprimorados habilitados

Descrição: esse controle verifica se os relatórios de integridade aprimorados estão habilitados para seus ambientes do AWS Elastic Beanstalk. Os relatórios de integridade aprimorados do Elastic Beanstalk permitem uma resposta mais rápida a alterações na integridade da infraestrutura subjacente. Essas alterações podem resultar na falta de disponibilidade do aplicativo. Os relatórios de integridade aprimorados do Elastic Beanstalk fornecem um descritor de status para avaliar a gravidade dos problemas identificados e identificar possíveis causas a serem investigadas. O agente de integridade do Elastic Beanstalk, incluído nas AMIs (Amazon Machine Images) suportadas, avalia logs e métricas de instâncias EC2 do ambiente.

Gravidade: Baixa

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

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

Gravidade: Alta

O Elastic Load Balancer não deve ter o certificado do ACM expirado ou expirando em 90 dias.

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

Gravidade: Alta

O registro de erros de domínio do Elasticsearch no CloudWatch Logs deve ser habilitado

Descrição: esse controle verifica se os domínios do Elasticsearch estão configurados para enviar logs de erro para o CloudWatch Logs. Você deve habilitar os logs de erro para domínios do Elasticsearch e enviá-los para o CloudWatch Logs para retenção e resposta. Os logs de erros de domínio podem ajudar com auditorias de segurança e acesso e podem 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 mestres dedicados. Esse controle falhará se o domínio não usar nós mestres dedicados. Esse controle passa 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 requer 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 porque há mais nós para gerenciar. A implantação de um domínio do Elasticsearch com pelo menos três nós mestres dedicados garante capacidade suficiente de recursos do nó mestre e operações de cluster se um nó falhar.

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 é true. Um domínio do Elasticsearch requer pelo menos três nós de dados para alta disponibilidade e tolerância a falhas. A implantação de um domínio do Elasticsearch com pelo menos três nós de dados garante operações de cluster se um nó falhar.

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 log de auditoria habilitado. 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 em seus clusters do Elasticsearch, incluindo sucessos e falhas de autenticação, solicitações ao OpenSearch, alterações de índice e consultas de pesquisa de entrada.

Gravidade: Média

O monitoramento aprimorado deve ser configurado para instâncias de banco de dados RDS e clusters

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

Gravidade: Baixa

Garantir que a rotação das CMKs criadas pelo cliente esteja ativada

Descrição: o AWS Key Management Service (KMS) permite que os clientes alternem a chave de suporte, que é o material de chave armazenado no KMS vinculado ao ID de chave da chave mestra do cliente (CMK) criada pelo cliente. É a chave de suporte que é usada para executar operações criptográficas, como criptografia e descriptografia. Atualmente, a rotação automatizada de chaves retém todas as chaves de suporte anteriores para que a descriptografia de dados criptografados possa ocorrer de forma transparente. Recomenda-se que a rotação de chaves CMK seja ativada. A rotação de chaves de encriptação ajuda a reduzir o impacto potencial de uma chave comprometida, uma vez que os dados encriptados com uma nova chave não podem ser acedidos com uma chave anterior que possa ter sido exposta.

Gravidade: Média

Verifique se o log de acesso ao bucket do S3 está ativado no bucket do CloudTrail S3

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

Gravidade: Baixa

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

Descrição: o CloudTrail registra um registro de cada chamada de API feita em sua conta da AWS. Esses arquivos de log são armazenados em um bucket do 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 deveria ter expirado certificados SSL/TLS

Descrição: Esta verificação identifica certificados SSL/TLS expirados. Para habilitar conexões HTTPS com seu site ou aplicativo na 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 AWS Elastic Load Balancer (ELB), o que pode prejudicar a credibilidade do aplicativo/site por trás do ELB. Essa verificação gera alertas se houver certificados SSL/TLS expirados armazenados no AWS IAM. Como prática recomendada, recomenda-se excluir certificados expirados.

Gravidade: Alta

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

Descrição: esse controle verifica se os certificados ACM em sua conta estão marcados para expiração dentro de 30 dias. Ele verifica os certificados importados e os certificados fornecidos pelo AWS Certificate Manager. O ACM pode renovar automaticamente certificados que usam validação de DNS. Para certificados que usam 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 os certificados importados manualmente. Para obter mais informações sobre a renovação gerenciada para certificados ACM, consulte Renovação gerenciada para certificados ACM no Guia do usuário do AWS Certificate Manager.

Gravidade: Média

Identidades provisionadas em excesso em contas devem ser investigadas para reduzir o PCI (Permission Creep Index)

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

Gravidade: Média

As atualizações automáticas de versões secundárias do RDS devem ser ativadas

Descrição: esse controle verifica se as atualizações automáticas de versões secundárias estão habilitadas para a instância do banco de dados RDS. A habilitação de atualizações automáticas de versões secundárias garante que as atualizações de versão secundária mais recentes para o sistema de gerenciamento de banco de dados relacional (RDBMS) sejam instaladas. Essas atualizações podem incluir patches de segurança e correções de bugs. Manter-se atualizado com a instalação de patches é um passo importante para proteger os sistemas.

Gravidade: Alta

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

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

Gravidade: Média

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

Descrição: esse controle verifica se os clusters RDS têm a proteção contra exclusão habilitada. Esse controle é destinado a instâncias de banco de dados RDS. No entanto, ele também pode gerar descobertas para instâncias de banco de dados do Aurora, instâncias de banco de dados do Neptune e clusters do Amazon DocumentDB. Se essas descobertas não forem úteis, você pode 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, um cluster RDS não pode ser excluído. Antes que uma solicitação de exclusão seja bem-sucedida, a proteção contra exclusão deve ser desativada.

Gravidade: Baixa

Os clusters de banco de dados RDS devem ser configurados para várias zonas de disponibilidade

Descrição: Os clusters de banco de dados 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 failover ed no caso de um problema de disponibilidade da Zona de Disponibilidade e durante eventos regulares de manutenção do RDS.

Gravidade: Média

Os clusters de banco de dados RDS devem ser configurados para copiar marcas para snapshots

Descrição: A identificação e o inventário de seus ativos de TI são um aspeto crucial da governança e da segurança. Você precisa ter visibilidade de todos os seus clusters de banco de dados RDS para que possa avaliar sua postura de segurança e agir em possíveis áreas de fraqueza. Os instantâneos devem ser marcados da mesma forma que os clusters de banco de dados RDS pai. Habilitar essa configuração garante que os instantâneos herdem as marcas de seus clusters de banco de dados pai.

Gravidade: Baixa

As instâncias de banco de dados RDS devem ser configuradas para copiar marcas para snapshots

Descrição: esse controle verifica se as instâncias de banco de dados RDS estão configuradas para copiar todas as marcas para snapshots quando os snapshots são criados. A identificação e o inventário de seus ativos de TI são um aspeto crucial da governança e da segurança. Você precisa ter visibilidade de todas as suas instâncias de banco de dados RDS para que possa avaliar sua postura de segurança e tomar medidas em possíveis áreas de fraqueza. Os instantâneos devem ser marcados da mesma forma que as instâncias de banco de dados RDS pai. Habilitar essa configuração garante que os instantâneos herdem as tags de suas instâncias de banco de dados pai.

Gravidade: Baixa

As instâncias de banco de dados 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 RDS. As instâncias de banco de dados RDS devem ser configuradas para várias zonas de disponibilidade (AZs). Isso garante a disponibilidade dos dados armazenados. As implantações Multi-AZ permitem failover automatizado se houver um problema com a disponibilidade da zona de disponibilidade e durante a manutenção regular do RDS.

Gravidade: Média

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

Descrição: esse controle verifica se as instâncias de banco de dados 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ância é 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, uma instância de banco de dados RDS não pode ser excluída. Antes que uma solicitação de exclusão seja bem-sucedida, a proteção contra exclusão deve ser desativada.

Gravidade: Baixa

As instâncias de banco de dados 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. Esse controle é destinado a instâncias de banco de dados RDS. No entanto, ele também pode gerar descobertas para instâncias de banco de dados do Aurora, instâncias de banco de dados do Neptune e clusters do Amazon DocumentDB. Se essas descobertas não forem úteis, você pode suprimi-las. Para obter uma camada adicional de segurança para seus dados confidenciais em instâncias de banco de dados RDS, você deve configurar suas instâncias de banco de dados RDS para serem criptografadas em repouso. Para criptografar suas instâncias de banco de dados RDS e snapshots em repouso, habilite a opção de criptografia para suas instâncias de banco de dados RDS. Os dados criptografados em repouso incluem o armazenamento subjacente para instâncias de banco de dados, seus backups automatizados, réplicas de leitura e snapshots. As instâncias de banco de dados criptografadas RDS usam o algoritmo de criptografia AES-256 padrão aberto para criptografar seus dados no servidor que hospeda suas instâncias de banco de dados RDS. Depois que seus dados são criptografados, o Amazon RDS lida com a autenticação de acesso e a descriptografia de seus dados de forma transparente, com um impacto mínimo no desempenho. Você não precisa modificar seus aplicativos cliente de banco de dados para usar criptografia. Atualmente, 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 de banco de dados. Para saber mais sobre classes de instância de banco de dados que não oferecem suporte à criptografia do Amazon RDS, consulte Criptografar recursos do Amazon RDS no Guia do usuário do Amazon RDS.

Gravidade: Média

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

Descrição: recomendamos que você também garanta que o acesso à configuração da 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 RDS devem proibir o acesso público

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

Gravidade: Alta

Remover segredos não utilizados do Gestor de Segredos

Descrição: este controlo verifica se os seus segredos foram acedidos dentro de um número especificado de dias. O valor predefinido é 90 dias. Se um segredo não foi acessado dentro do número definido de dias, esse controle falhará. Eliminar segredos não utilizados é tão importante como alternar segredos. Segredos não utilizados podem ser abusados por seus antigos usuários, que não precisam mais ter acesso a esses segredos. Além disso, à medida que mais usuários têm acesso a um segredo, alguém pode tê-lo manipulado incorretamente e vazado 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 secreto de usuários que não precisam mais dele. Também ajuda a reduzir o custo de utilização do Gestor de Segredos. Portanto, é essencial excluir rotineiramente segredos não utilizados.

Gravidade: Média

Os buckets do 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 seu bucket do S3 contra ataques DDoS e eventos de corrupção de dados.

Gravidade: Baixa

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

Descrição: habilite a criptografia do lado do servidor para proteger os dados em seus buckets do S3. A encriptação dos dados pode impedir o acesso a dados sensíveis em caso de violação de dados.

Gravidade: Média

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

Descrição: esse controle verifica se um segredo do AWS Secrets Manager foi girado com êxito com base na programação de rotação. O controle falhará se RotationOccurringAsScheduled for false. O controle não avalia segredos que não têm rotação configurada. O Secrets Manager ajuda-o a melhorar a postura de segurança da sua organização. Os segredos incluem credenciais de banco de dados, senhas e chaves de API de terceiros. Você pode usar o Gerenciador de Segredos para armazenar segredos centralmente, criptografar segredos automaticamente, controlar o acesso a segredos e girar segredos de forma segura e automática. O Gestor de Segredos pode rodar segredos. Você pode usar a rotação para substituir segredos de longo prazo por segredos de curto prazo. Girar seus segredos limita por quanto tempo um usuário não autorizado pode usar um segredo comprometido. Por esta razão, deve rodar os seus segredos com frequência. Além de configurar segredos para girar automaticamente, você deve garantir que esses segredos girem com êxito com base na programação de rotação. Para saber mais sobre rotação, consulte Rotação dos segredos do AWS Secrets Manager no Guia do usuário do AWS Secrets Manager.

Gravidade: Média

Os segredos do Secrets Manager devem ser alternados dentro de um número especificado de dias

Descrição: Este controlo verifica se os seus segredos foram alternados pelo menos uma vez no prazo de 90 dias. A rotação de segredos pode ajudá-lo a reduzir o risco de um uso não autorizado de seus segredos em sua conta da AWS. Os exemplos incluem credenciais de banco de dados, senhas, chaves de API de terceiros e até texto arbitrário. Se você não mudar seus segredos por um longo período de tempo, os segredos são mais propensos a serem comprometidos. À medida que mais usuários obtêm acesso a um segredo, pode se tornar mais provável que alguém o manipulou incorretamente e vazou para uma entidade não autorizada. Os segredos podem ser vazados através de logs e dados de cache. Eles podem ser compartilhados para fins de depuração e não alterados ou revogados quando a depuração for concluída. Por todas estas razões, os segredos devem ser alternados com frequência. Você pode configurar seus 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 significativamente o risco de comprometimento. O Security Hub recomenda que você habilite a rotação para seus segredos do Gerenciador de Segredos. Para saber mais sobre rotação, consulte Rotação dos segredos do AWS Secrets Manager no Guia do usuário do AWS Secrets Manager.

Gravidade: Média

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 em repouso reduz o risco de os dados armazenados no disco serem acessados por um usuário não autenticado na AWS. Ele também adiciona outro conjunto de controles de acesso para limitar a capacidade de usuários não autorizados de acessar os dados. Por exemplo, as permissões de API são necessárias para descriptografar os dados antes que eles 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, consulte Criptografia em repouso no Guia do desenvolvedor do Amazon Simple Notification Service.

Gravidade: Média

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

Descrição: Os VPC Flow Logs fornecem visibilidade do tráfego de rede que passa pela VPC e podem ser usados para detetar tráfego anômalo ou insights durante eventos de segurança.

Gravidade: Média

Recomendações de dados do GCP

Verifique se o sinalizador de banco de dados '3625 (sinalizador de rastreamento)' para a instância do Cloud SQL Server está 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 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 abordar 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 são totalmente suportados 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, recomenda-se desativar este sinalizador. Essa recomendação é aplicável a instâncias de banco de dados do SQL Server.

Gravidade: Média

Verifique se o sinalizador de banco de dados 'scripts externos habilitados' para a instância do Cloud SQL Server está definido como 'desativado'

Descrição: é recomendável definir o sinalizador de banco de dados "scripts externos habilitados" para a instância do Cloud SQL Server como desativado. "Scripts externos habilitados" permitem a execução de scripts com determinadas extensões de linguagem remota. Esta propriedade está OFF por padrão. Quando o Advanced Analytics Services é instalado, a configuração pode, opcionalmente, definir essa propriedade como true. Como o recurso "Scripts externos habilitados" permite que scripts externos ao SQL, como arquivos localizados em uma biblioteca R, sejam executados, o que pode afetar negativamente a segurança do sistema, portanto, isso deve ser desativado. Essa recomendação é aplicável a instâncias de banco de dados do SQL Server.

Gravidade: Alta

Verifique se o sinalizador de banco de dados de 'acesso remoto' para a instância do Cloud SQL Server está definido como 'desativado'

Descrição: é recomendável definir o sinalizador de banco de dados "acesso remoto" para a instância do Cloud SQL Server 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. Esse valor padrão para essa opção é 1. Isso concede permissão para executar procedimentos armazenados locais de servidores remotos ou procedimentos armazenados remotos do servidor local. Para impedir que procedimentos armazenados locais sejam executados a partir de um servidor remoto ou que procedimentos armazenados remotos sejam executados no servidor local, isso deve ser desabilitado. A opção Acesso Remoto controla a execução de procedimentos armazenados locais em servidores remotos ou procedimentos armazenados remotos em servidores locais. A funcionalidade de 'acesso remoto' pode ser abusada para iniciar um ataque de negação de serviço (DoS) em servidores remotos descarregando o processamento de consultas para um alvo, portanto, isso deve ser desativado. Essa recomendação é aplicável a instâncias de banco de dados do SQL Server.

Gravidade: Alta

Verifique se o sinalizador de banco de dados 'skip_show_database' para a instância do Cloud SQL Mysql está definido como 'on'

Descrição: Recomenda-se definir o sinalizador de banco de dados "skip_show_database" para a instância do Cloud SQL Mysql como "on". 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 sobre os usuários poderem 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 é permitido a todos os usuários, mas exibe os nomes apenas dos bancos de dados para os quais o usuário tem o privilégio SHOW DATABASES ou outro. Esta recomendação é aplicável a instâncias de banco de dados Mysql.

Gravidade: Baixa

Verifique se uma chave de criptografia gerenciada pelo cliente (CMEK) padrão está especificada para todos os conjuntos de dados do 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 próprias chaves de criptografia de dados são criptografadas usando chaves de criptografia de chave. Isso é contínuo e não requer nenhuma entrada adicional do usuário. No entanto, se você quiser ter maior controle, as chaves de criptografia gerenciadas pelo cliente (CMEK) podem ser usadas como solução de gerenciamento de chaves de criptografia para conjuntos de dados do BigQuery. Por padrão, o BigQuery criptografa os dados como restantes, empregando a criptografia de envelope usando chaves criptográficas gerenciadas pelo Google. Isso é contínuo e não requer nenhuma entrada adicional do usuário. Para maior controle sobre a criptografia, as chaves de criptografia gerenciadas pelo cliente (CMEK) podem ser usadas como solução de gerenciamento de chaves de criptografia para conjuntos de dados do BigQuery. Definir uma chave de criptografia gerenciada pelo cliente padrão (CMEK) para um conjunto de dados garante que todas as tabelas criadas no futuro usarão o CMEK especificado se nenhuma outra for fornecida.

A Google não armazena as suas chaves nos seus servidores e não pode aceder aos seus dados protegidos, a menos que 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

Verifique se todas as tabelas do BigQuery estão 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 próprias chaves de criptografia de dados são criptografadas usando chaves de criptografia de chave. Isso é contínuo e não requer nenhuma entrada adicional do usuário. No entanto, se você quiser ter maior controle, as chaves de criptografia gerenciadas pelo cliente (CMEK) podem ser usadas como solução de gerenciamento de chaves de criptografia para conjuntos de dados do BigQuery. Se o CMEK for usado, o CMEK será usado 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 restantes, empregando a criptografia de envelope usando chaves criptográficas gerenciadas pelo Google. Isso é contínuo e não requer nenhuma entrada adicional do usuário. Para maior controle sobre a criptografia, as chaves de criptografia gerenciadas pelo cliente (CMEK) podem ser usadas como solução de gerenciamento de chaves de criptografia para tabelas do BigQuery. O CMEK é usado 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 encriptação/desencriptação é feita automaticamente. A aplicação das chaves padrão gerenciadas pelo cliente em conjuntos de dados do BigQuery garante que todas as novas tabelas criadas no futuro serão criptografadas usando o CMEK, mas as tabelas existentes precisam ser atualizadas para usar o CMEK individualmente.

A Google não armazena as suas chaves nos seus servidores e não pode aceder aos seus dados protegidos, a menos que 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 do BigQuery não estejam anonimamente ou acessíveis publicamente

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 a allUsers ou allAuthenticatedUsers permite que qualquer pessoa acesse o conjunto de dados. Esse acesso pode não ser desejável se estiverem a ser armazenados dados sensíveis 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 sejam 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 fornecem uma maneira de restaurar uma instância do Cloud SQL para recuperar dados perdidos ou 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 perdas ou danos. Esta recomendação é aplicável para instâncias SQL Server, PostgreSql, MySql geração 1 e MySql geração 2.

Gravidade: Alta

Certifique-se de que as instâncias do banco de dados 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 e restringir o acesso do mundo. Para minimizar a superfície de ataque em uma instância do servidor de banco de dados, somente IP(s) 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 apenas a instâncias com IPs públicos.

Gravidade: Alta

Verifique se as instâncias do banco de dados Cloud SQL não têm IPs públicos

Descrição: É recomendável configurar a instância Sql de segunda geração para usar IPs privados em vez de IPs públicos. Para diminuir a superfície de ataque da organização, os bancos de dados Cloud SQL não devem ter IPs públicos. Os IPs privados fornecem segurança de rede melhorada e menor latência para a sua aplicação.

Gravidade: Alta

Certifique-se de que o bucket de armazenamento em nuvem não esteja anonimamente ou acessível publicamente

Descrição: é recomendável que a política do IAM no bucket de armazenamento em nuvem 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

Certifique-se de que os buckets de armazenamento em nuvem tenham acesso uniforme no nível do bucket habilitado

Descrição: é recomendável que o acesso uniforme no nível do bucket esteja habilitado em buckets de armazenamento em nuvem. É recomendável usar o acesso uniforme em nível de bucket para unificar e simplificar a forma como você concede acesso aos seus recursos de armazenamento em nuvem. O Cloud Storage oferece dois sistemas para conceder permissão aos usuários para acessar seus buckets e objetos: Cloud Identity and Access Management (Cloud IAM) e Access Control Lists (ACLs).
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 Cloud IAM é 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 Cloud Storage e têm opções de permissão limitadas, mas permitem que você conceda permissões por objeto.

Para suportar um sistema de permissão uniforme, o Cloud Storage tem acesso uniforme no nível do bucket. O uso desse recurso desativa as ACLs para todos os recursos de armazenamento em nuvem: o acesso aos recursos de armazenamento em nuvem é concedido exclusivamente por meio do Cloud IAM. Habilitar o 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 tenham a Computação Confidencial ativada

Descrição: o Google Cloud criptografa dados em repouso e em trânsito, mas os dados do cliente devem ser descriptografados para processamento. A Computação Confidencial é uma tecnologia inovadora que encripta os dados em uso enquanto estão a ser processados. Os ambientes informáticos confidenciais mantêm os dados encriptados na memória e fora da unidade central de processamento (CPU). VMs confidenciais aproveitam o recurso Secure Encrypted Virtualization (SEV) das CPUs AMD EPYC. Os dados do cliente permanecerão criptografados enquanto forem usados, indexados, consultados ou treinados. As chaves de criptografia são geradas no hardware, por VM, e não exportáveis. Graças às otimizações de hardware integradas 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 que o código sensível dos clientes e outros dados sejam 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 pessoas internas do Google aos dados do cliente de forma clara.

Gravidade: Alta

Verifique se as políticas de retenção em buckets de log estão configuradas usando o Bucket Lock

Descrição: habilitar políticas de retenção em buckets de log protegerá os logs armazenados em buckets de armazenamento em nuvem contra a substituição ou exclusão acidental. É recomendável configurar políticas de retenção e configurar o Bucket Lock 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 log, 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; impedindo, assim, permanentemente que a política seja reduzida ou suprimida. Dessa forma, se o sistema for comprometido por um invasor ou um insider mal-intencionado que queira cobrir seus rastros, os registros de atividades são definitivamente preservados para perícias e investigações de segurança.

Gravidade: Baixa

Verifique se a instância do banco de dados Cloud SQL requer todas as conexões de entrada para usar SSL

Descrição: Recomenda-se 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 êxito (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. Esta recomendação é aplicável para instâncias Postgresql, MySql geração 1 e MySql geração 2.

Gravidade: Alta

Verifique se o sinalizador de banco de dados 'autenticação de banco de dados contido' para Cloud SQL na instância do SQL Server está definido como 'desativado'

Descrição: é recomendável definir o sinalizador de banco de dados "autenticação de banco de dados contido" para o Cloud SQL na instância do SQL Server está definido como "desativado". Um banco de dados contido inclui todas as configurações e metadados de banco de dados 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 onde 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. Isolar o banco de dados do Mecanismo de Banco de Dados torna possível mover facilmente o banco de dados para outra instância do SQL Server. Os bancos de dados contidos têm algumas ameaças exclusivas que devem ser compreendidas e atenuadas 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, portanto, recomenda-se desativar esse sinalizador. Essa recomendação é aplicável a instâncias de banco de dados do SQL Server.

Gravidade: Média

Certifique-se de que o sinalizador de banco de dados 'cross db ownership chaining' para a instância do Cloud SQL Server esteja definido como 'off'

Descrição: é recomendável definir o sinalizador de banco de dados "cross db ownership chaining" para a instância do Cloud SQL Server como "off". Use a opção "propriedade de banco de dados cruzado" 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 controlar o encadeamento de propriedade entre bancos de dados no nível do banco de dados ou permitir o encadeamento de propriedade entre bancos de dados para 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 de banco de dados do SQL Server.

Gravidade: Média

Certifique-se de que o sinalizador de banco de dados 'local_infile' para uma instância do Cloud SQL Mysql esteja definido como 'off'

Descrição: é recomendável definir o sinalizador de banco de dados local_infile para uma instância do Cloud SQL MySQL como desativado. O sinalizador local_infile controla a capacidade LOCAL do lado do servidor para instruções LOAD DATA. Dependendo da configuração local_infile, o servidor recusa ou permite o carregamento de dados locais por clientes que têm o 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 em tempo de compilação ou tempo de execução), comece mysqld com local_infile desabilitado. local_infile também pode ser definido em tempo de execução. Devido a problemas de segurança associados ao sinalizador local_infile, recomenda-se desativá-lo. Esta recomendação é aplicável a instâncias de banco de dados MySQL.

Gravidade: Média

Verifique se a métrica de log, o filtro e os alertas existem para alterações de permissão do IAM de armazenamento em nuvem

Descrição: é recomendável estabelecer um filtro métrico e um alarme para alterações no IAM do bucket de armazenamento em nuvem. O monitoramento de alterações nas permissões do bucket de armazenamento em nuvem pode reduzir o tempo necessário para detetar e corrigir permissões em buckets e objetos confidenciais de armazenamento em nuvem dentro do bucket.

Gravidade: Baixa

Verifique se a métrica de log, o filtro e os alertas existem para alterações na configuração da instância SQL

Descrição: Recomenda-se que um filtro métrico e um alarme sejam estabelecidos para alterações na configuração da instância SQL. O monitoramento de alterações na configuração da instância SQL pode reduzir o tempo necessário para detetar e corrigir configurações incorretas feitas no servidor SQL. 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: configurações incorretas podem afetar negativamente a continuidade de 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

Verifique se há 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 da Cloud Platform, como o App Engine e o Compute Engine. Essas chaves não podem ser baixadas. O Google manterá as chaves e as alternará automaticamente em uma base aproximadamente semanal. As chaves gerenciadas pelo usuário são criadas, baixáveis e gerenciadas pelos usuários. Eles expiram 10 anos a partir da criação. Para chaves gerenciadas pelo usuário, o usuário tem que assumir a propriedade das atividades de gerenciamento de chaves, que incluem:

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

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

Gravidade: Baixa

Verifique se o sinalizador de banco de dados 'conexões de usuário' para a instância do Cloud SQL Server está definido conforme apropriado

Descrição: é recomendável definir o sinalizador de banco de dados "conexões de usuário" para a instância do Cloud SQL Server de acordo com o valor definido pela organização. A opção "conexões de usuário" especifica o número máximo de conexões de usuário simultâneas permitidas 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 seu aplicativo ou aplicativos e hardware. O 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 (autoconfiguração), o SQL Server ajusta o número máximo de conexões de usuário automaticamente conforme necessário, até o valor máximo permitido. Por exemplo, se apenas 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 o máximo (32.767) de conexões de usuário é permitido. Essa recomendação é aplicável a instâncias de banco de dados do SQL Server.

Gravidade: Baixa

Verifique se o sinalizador de banco de dados 'opções do usuário' para a instância do Cloud SQL Server não está configurado

Descrição: é recomendável que o sinalizador de banco de dados "opções do usuário" para a instância do Cloud SQL Server não seja configurado. A opção "opções do usuário" especifica padrões globais para todos os usuários. Uma lista de opções de processamento de consulta padrão é estabelecida 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 as opções do usuário dinamicamente para novos logins. Depois de alterar a configuração das opções do usuário, 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 de banco de dados do SQL Server.

Gravidade: Baixa

O registro em log para clusters GKE deve ser habilitado

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

Gravidade: Alta

O controle de versão de objetos deve ser habilitado em buckets de armazenamento onde os coletores estão configurados

Descrição: esta recomendação avalia se o campo habilitado na propriedade de controle de versão do bucket está definido como true.

Gravidade: Alta

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

Descrição: identidades provisionadas em excesso em projetos devem ser investigadas para reduzir o PCI (Permission Creep Index) e proteger sua infraestrutura. Reduza o PCI removendo as atribuições de permissão de alto risco não utilizadas. PCI alto reflete o risco associado às identidades com permissões que excedem seu 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: esta recomendação avalia a política de permissão do IAM nos metadados do projeto para as principais funções atribuídas/Proprietário.

Gravidade: Média

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

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

Gravidade: Alta

Conteúdos relacionados

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