Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Este artigo lista as definições de política interna da Política do Azure relacionadas ao benchmark de segurança na nuvem v2 da Microsoft (visualização). Cada controle da referência é mapeado para uma ou mais definições de Política do Azure.
Compatível na Política do Azure refere-se apenas às próprias definições de política; Isso não garante que você esteja totalmente em conformidade com todos os requisitos de um controle. O padrão de conformidade inclui controles que não são abordados por nenhuma definição de Política do Azure no momento. Portanto, a conformidade na Política do Azure é apenas uma exibição parcial do seu status geral de conformidade.
As associações entre controles e definições de Política do Azure para esse padrão de conformidade podem mudar ao longo do tempo.
AI-1: Garantir a utilização de modelos aprovados
Para obter mais informações, consulte Segurança de Inteligência Artificial: AI-1: Garantir o uso de modelos aprovados.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| [Pré-visualização]: As Implementações do Azure Machine Learning só devem utilizar Modelos de Registo aprovados | Restringir a implantação de modelos do Registro para controlar modelos criados externamente usados em sua organização | Auditoria; Negar; Desabilitado | 1.0.0-pré-visualização |
| [Pré-visualização]: As Implementações de Registo do Modelo do Azure Machine Learning são restritas, exceto para o Registo permitido | Implante Modelos de Registro somente no Registro permitido e que não sejam restritos. | não aplicável | 1.0.0-pré-visualização |
AM-2: Utilizar apenas serviços aprovados
Para obter mais informações, consulte Gerenciamento de ativos: AM-2: usar apenas serviços aprovados.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| A versão da plataforma de Gerenciamento de API do Azure deve ser stv2 | A versão da plataforma de computação stv1 do Azure API Management será desativada a partir de 31 de agosto de 2024 e essas instâncias devem ser migradas para a plataforma de computação stv2 para suporte contínuo. Saiba mais em API Management stv1 platform retirement - Global Azure cloud (agosto de 2024) | Auditoria; Negar; Desabilitado | 1.0.0 |
| As contas de armazenamento devem ser migradas para novos recursos do Azure Resource Manager | Use o novo Azure Resource Manager para suas contas de armazenamento para fornecer aprimoramentos de segurança, como: RBAC (controle de acesso mais forte), melhor auditoria, implantação e governança baseadas no Azure Resource Manager, 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 | Auditoria; Negar; Desabilitado | 1.0.0 |
| As contas de armazenamento devem ser migradas para novos recursos do Azure Resource Manager | Use o novo Azure Resource Manager para suas contas de armazenamento para fornecer aprimoramentos de segurança, como: RBAC (controle de acesso mais forte), melhor auditoria, implantação e governança baseadas no Azure Resource Manager, 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 | Auditoria; Negar; Desabilitado | 1.0.0 |
AM-3: Garanta a segurança do gerenciamento do ciclo de vida dos ativos
Para obter mais informações, consulte Gerenciamento de ativos: AM-3: Garantir a segurança do gerenciamento do ciclo de vida dos ativos.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Os pontos de extremidade de API que não são usados devem ser desabilitados e removidos do serviço de Gerenciamento de API do Azure | Como prática recomendada de segurança, os pontos de extremidade de API que não recebem tráfego há 30 dias são considerados não utilizados e devem ser removidos do serviço de Gerenciamento de API do Azure. Manter pontos de extremidade de API não utilizados pode representar um risco de segurança para sua organização. Essas podem ser APIs que deveriam ter sido preteridas do serviço de Gerenciamento de API do Azure, mas podem ter sido acidentalmente deixadas ativas. Essas APIs normalmente não recebem a cobertura de segurança mais atualizada. | AuditIfNotExists; Desabilitado | 1.0.1 |
BR-1: Garantir cópias de segurança automatizadas regulares
Para obter mais informações, consulte Backup e recuperação: BR-1: Garantir backups automatizados regulares.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| O Backup do Azure deve ser habilitado para Máquinas Virtuais | Garanta a proteção de suas Máquinas Virtuais do Azure habilitando o Backup do Azure. O Backup do Azure é uma solução de proteção de dados segura e econômica para o Azure. | AuditIfNotExists; Desabilitado | 3.0.0 |
| O backup com redundância geográfica deve ser habilitado para o Banco de Dados do Azure para MariaDB | 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ção de recuperação em caso de falha de região. A configuração do armazenamento georredundante para cópia de segurança só é permitida durante a criação do servidor. | Auditoria; Desabilitado | 1.0.1 |
| O backup com redundância geográfica deve ser habilitado para o Banco de Dados do Azure para MySQL | 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ção de recuperação em caso de falha de região. A configuração do armazenamento georredundante para cópia de segurança só é permitida durante a criação do servidor. | Auditoria; Desabilitado | 1.0.1 |
| O backup com redundância geográfica deve ser habilitado para o Banco de Dados do Azure para PostgreSQL | 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ção de recuperação em caso de falha de região. A configuração do armazenamento georredundante para cópia de segurança só é permitida durante a criação do servidor. | Auditoria; Desabilitado | 1.0.1 |
BR-2: Proteja os dados de backup e recuperação
Para obter mais informações, consulte Backup e recuperação: BR-2: Proteger dados de backup e recuperação.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| O Backup do Azure deve ser habilitado para Máquinas Virtuais | Garanta a proteção de suas Máquinas Virtuais do Azure habilitando o Backup do Azure. O Backup do Azure é uma solução de proteção de dados segura e econômica para o Azure. | AuditIfNotExists; Desabilitado | 3.0.0 |
| O backup com redundância geográfica deve ser habilitado para o Banco de Dados do Azure para MariaDB | 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ção de recuperação em caso de falha de região. A configuração do armazenamento georredundante para cópia de segurança só é permitida durante a criação do servidor. | Auditoria; Desabilitado | 1.0.1 |
| O backup com redundância geográfica deve ser habilitado para o Banco de Dados do Azure para MySQL | 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ção de recuperação em caso de falha de região. A configuração do armazenamento georredundante para cópia de segurança só é permitida durante a criação do servidor. | Auditoria; Desabilitado | 1.0.1 |
| O backup com redundância geográfica deve ser habilitado para o Banco de Dados do Azure para PostgreSQL | 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ção de recuperação em caso de falha de região. A configuração do armazenamento georredundante para cópia de segurança só é permitida durante a criação do servidor. | Auditoria; Desabilitado | 1.0.1 |
| Pré-visualização: A imutabilidade tem de estar ativada para os cofres dos Serviços de Recuperação | Esta política audita se a propriedade vaults imutáveis está habilitada para vaults dos Serviços de Recuperação no escopo. Isso ajuda a proteger seus dados de backup de serem excluídos antes do vencimento pretendido. Saiba mais em Conceito de cofre imutável para Backup do Azure. | Auditoria; Desabilitado | 1.0.1-Pré-visualização |
| [Pré-visualização]: A imutabilidade tem de estar ativada para cofres de cópia de segurança | Esta política audita se a propriedade vaults imutáveis está habilitada para cofres de backup no escopo. Isso ajuda a proteger seus dados de backup de serem excluídos antes do vencimento pretendido. Saiba mais em Conceito de cofre imutável para Backup do Azure. | Auditoria; Desabilitado | 1.0.1-Pré-visualização |
| [Pré-visualização]: A eliminação suave deve ser ativada para os Cofres de Cópia de Segurança | Esta política audita se a exclusão suave está habilitada para cofres de backup no escopo. A exclusão suave pode ajudá-lo a recuperar seus dados depois que eles foram excluídos. Saiba mais em Visão geral da exclusão suave aprimorada para o Backup do Azure | Auditoria; Desabilitado | 1.0.0-pré-visualização |
DP-1: Descoberta de dados confidenciais
Para obter mais informações, consulte Proteção de dados: DP-1: descoberta de dados confidenciais.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| O Microsoft Defender para APIs deve estar habilitado | O Microsoft Defender para APIs traz novas descobertas, proteção, deteção, cobertura de resposta de & para monitorar ataques comuns baseados em API ou configurações incorretas de segurança. | AuditIfNotExists; Desabilitado | 1.0.3 |
DP-2: Monitorizar anomalias e ameaças que visam dados confidenciais
Para obter mais informações, consulte Proteção de dados: DP-2: monitorar anomalias e ameaças direcionadas a dados confidenciais.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Os servidores do Banco de Dados SQL do Azure Defender for Azure devem ser habilitados | O Azure Defender para SQL fornece funcionalidade para revelar e mitigar possíveis vulnerabilidades de banco de dados, detetar atividades anômalas que podem indicar ameaças a bancos de dados SQL e descobrir e classificar dados confidenciais. | AuditIfNotExists; Desabilitado | 1.0.2 |
| Azure Defender para SQL servidores em máquinas deve ser habilitado | O Azure Defender para SQL fornece funcionalidade para revelar e mitigar possíveis vulnerabilidades de banco de dados, detetar atividades anômalas que podem indicar ameaças a bancos de dados SQL e descobrir e classificar dados confidenciais. | AuditIfNotExists; Desabilitado | 1.0.2 |
| O Azure Defender for SQL deve ser habilitado para Instâncias Gerenciadas SQL desprotegidas | Audite cada instância gerenciada SQL sem segurança de dados avançada. | AuditIfNotExists; Desabilitado | 1.0.2 |
| O Azure Defender para bancos de dados relacionais de código aberto deve ser habilitado | O Azure 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 sobre os recursos do Azure Defender para bancos de dados relacionais de código aberto em Visão geral do Defender para Open-Source bancos de dados relacionais. Importante: habilitar esse plano resultará em cobranças para proteger seus bancos de dados relacionais de código aberto. Saiba mais sobre os preços na página de preços da Central de Segurança: Preços - Microsoft Defender for Cloud | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Microsoft Defender para APIs deve estar habilitado | O Microsoft Defender para APIs traz novas descobertas, proteção, deteção, cobertura de resposta de & para monitorar ataques comuns baseados em API ou configurações incorretas de segurança. | AuditIfNotExists; Desabilitado | 1.0.3 |
| O Microsoft Defender for Storage deve estar habilitado | O Microsoft Defender for Storage deteta ameaças potenciais às suas contas de armazenamento. Ele ajuda a evitar os três principais impactos em seus dados e carga de trabalho: uploads de arquivos mal-intencionados, exfiltração de dados confidenciais e corrupção de dados. O novo plano do Defender for Storage inclui verificação de malware e deteção de ameaças de dados confidenciais. Esse plano também fornece uma estrutura de preços previsível (por conta de armazenamento) para controle sobre a cobertura e os custos. | AuditIfNotExists; Desabilitado | 1.0.0 |
DP-3: Criptografar dados confidenciais em trânsito
Para obter mais informações, consulte Proteção de dados: DP-3: criptografar dados confidenciais em trânsito.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| As APIs de gerenciamento de API devem usar apenas protocolos criptografados | Para garantir a segurança dos dados em trânsito, as APIs devem estar disponíveis apenas por meio de protocolos criptografados, como HTTPS ou WSS. Evite usar protocolos não seguros, como HTTP ou WS. | Auditoria; Deficientes; Negar | 2.0.2 |
| O Ambiente do Serviço de Aplicativo deve ser configurado com pacotes de codificação TLS mais fortes | Os dois pacotes de codificação mais mínimos e mais fortes necessários para que o Ambiente do Serviço de Aplicativo funcione corretamente são: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 e TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. | Auditoria; Desabilitado | 1.0.0 |
| O Ambiente do Serviço de Aplicativo deve ter o TLS 1.0 e 1.1 desabilitado | TLS 1.0 e 1.1 são protocolos desatualizados que não suportam algoritmos criptográficos modernos. A desativação do tráfego TLS 1.0 e 1.1 de entrada ajuda a proteger aplicativos em um Ambiente do Serviço de Aplicativo. | Auditoria; Negar; Desabilitado | 2.0.1 |
| O Ambiente do Serviço de Aplicativo deve ter a criptografia interna habilitada | Definir InternalEncryption como true criptografa o ficheiro de paginação, os discos dos trabalhadores e o tráfego de rede interna entre as interfaces frontais e os trabalhadores em um Ambiente de Serviço de Aplicações. Para saber mais, consulte Definições de configuração personalizadas para ambientes do Serviço de Aplicativo. | Auditoria; Desabilitado | 1.0.1 |
| Os slots de apps no App Service devem habilitar a criptografia de ponta a ponta | A habilitação da criptografia de ponta a ponta garante que o tráfego intra-cluster front-end entre os front-ends do Serviço de Aplicativo e os trabalhadores que executam cargas de trabalho de aplicativos seja criptografado. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os slots da aplicação do Serviço de Aplicações devem usar a versão TLS mais recente | Periodicamente, versões mais recentes são lançadas para TLS devido a falhas de segurança, incluem funcionalidades adicionais e aumentam a velocidade. Atualize para a versão TLS mais recente para aplicativos do Serviço de Aplicativo para aproveitar as correções de segurança, se houver, e/ou novas funcionalidades da versão mais recente. | AuditIfNotExists; Desabilitado | 1.2.0 |
| Os aplicativos do Serviço de Aplicativo devem habilitar a criptografia de ponta a ponta | A habilitação da criptografia de ponta a ponta garante que o tráfego intra-cluster front-end entre os front-ends do Serviço de Aplicativo e os trabalhadores que executam cargas de trabalho de aplicativos seja criptografado. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os aplicativos do Serviço de Aplicativo só devem ser acessíveis por HTTPS | O uso de HTTPS garante a autenticação do servidor/serviço e protege os dados em trânsito contra ataques de espionagem da camada de rede. | Auditoria; Deficientes; Negar | 4.0.0 |
| Os aplicativos do Serviço de Aplicativo devem exigir apenas FTPS | Habilite a imposição de FTPS para maior segurança. | AuditIfNotExists; Desabilitado | 3.0.0 |
| Os aplicativos do Serviço de Aplicativo devem usar a versão TLS mais recente | Periodicamente, versões mais recentes são lançadas para TLS devido a falhas de segurança, incluem funcionalidades adicionais e aumentam a velocidade. Atualize para a versão TLS mais recente para aplicativos do Serviço de Aplicativo para aproveitar as correções de segurança, se houver, e/ou novas funcionalidades da versão mais recente. | AuditIfNotExists; Desabilitado | 2.2.0 |
| Os pools de Lotes do Azure devem ter a criptografia de disco habilitada | Habilitar a criptografia de disco do Lote do Azure garante que os dados sejam sempre criptografados em repouso no nó de computação do Lote do Azure. Saiba mais sobre a criptografia de disco em Lote em Criar um pool com a criptografia de disco habilitada. | Auditoria; Deficientes; Negar | 1.0.0 |
| O Azure Front Door Standard e Premium deve estar executando a versão TLS mínima da versão 1.2 | Definir a versão mínima do TLS como 1.2 melhora a segurança, garantindo que seus domínios personalizados sejam acessados a partir de clientes que usam o TLS 1.2 ou mais recente. O uso de versões do TLS inferiores a 1.2 não é recomendado, pois são fracas e não suportam algoritmos criptográficos modernos. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os clusters do Azure HDInsight devem usar criptografia em trânsito para criptografar a comunicação entre nós de cluster do Azure HDInsight | Os dados podem ser adulterados durante a transmissão entre nós de cluster do Azure HDInsight. Habilitar a criptografia em trânsito resolve problemas de uso indevido e adulteração durante essa transmissão. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O Banco de Dados SQL do Azure deve estar executando o TLS versão 1.2 ou mais recente | 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. | Auditoria; Deficientes; Negar | 2.0.0 |
| O ponto de extremidade do Serviço de Bot deve ser um URI HTTPS válido | Os dados podem ser adulterados durante a transmissão. Existem protocolos que fornecem criptografia para resolver problemas de uso indevido e adulteração. Para garantir que seus bots estejam se comunicando apenas por canais criptografados, defina o ponto de extremidade como um URI HTTPS válido. Isso garante que o protocolo HTTPS seja usado para criptografar seus dados em trânsito e também seja frequentemente um requisito para conformidade com padrões regulatórios ou do setor. Por favor, visite: Bot Framework diretrizes de segurança. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 1.1.0 |
| Impor conexão SSL deve ser habilitado para servidores de banco de dados MySQL | 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. | Auditoria; Desabilitado | 1.0.1 |
| Impor conexão SSL deve ser habilitado para servidores de banco de dados PostgreSQL | 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. | Auditoria; Desabilitado | 1.0.1 |
| Os slots de aplicativo de função devem habilitar a criptografia de ponta a ponta | A habilitação da criptografia de ponta a ponta garante que o tráfego intra-cluster front-end entre os front-ends do Serviço de Aplicativo e os trabalhadores que executam cargas de trabalho de aplicativos seja criptografado. | Auditoria; Negar; Desabilitado | 1.1.0 |
| Os slots das aplicações de função devem usar a versão mais recente do TLS | Periodicamente, versões mais recentes são lançadas para TLS devido a falhas de segurança, incluem funcionalidades adicionais e aumentam a velocidade. Atualize para a versão TLS mais recente para aplicativos Function para aproveitar as correções de segurança, se houver, e/ou novas funcionalidades da versão mais recente. | AuditIfNotExists; Desabilitado | 1.3.0 |
| Os aplicativos de função devem habilitar a criptografia de ponta a ponta | A habilitação da criptografia de ponta a ponta garante que o tráfego intra-cluster front-end entre os front-ends do Serviço de Aplicativo e os trabalhadores que executam cargas de trabalho de aplicativos seja criptografado. | Auditoria; Negar; Desabilitado | 1.1.0 |
| Os aplicativos de função só devem ser acessíveis por HTTPS | O uso de HTTPS garante a autenticação do servidor/serviço e protege os dados em trânsito contra ataques de espionagem da camada de rede. | Auditoria; Deficientes; Negar | 5.1.0 |
| Os aplicativos de função devem exigir apenas FTPS | Habilite a imposição de FTPS para maior segurança. | AuditIfNotExists; Desabilitado | 3.1.0 |
| Os aplicativos de função devem usar a versão TLS mais recente | Periodicamente, versões mais recentes são lançadas para TLS devido a falhas de segurança, incluem funcionalidades adicionais e aumentam a velocidade. Atualize para a versão TLS mais recente para aplicativos Function para aproveitar as correções de segurança, se houver, e/ou novas funcionalidades da versão mais recente. | AuditIfNotExists; Desabilitado | 2.3.0 |
| Clusters Kubernetes devem ser acessíveis somente através de HTTPS | O uso de HTTPS garante a autenticação e protege os dados em trânsito contra ataques de espionagem da camada de rede. Esse recurso está atualmente disponível para o Serviço Kubernetes (AKS) e em visualização para o Kubernetes habilitado para Azure Arc. Para obter mais informações, visite Compreender a Política do Azure para clusters Kubernetes | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 8.2.0 |
| Somente conexões seguras com seu Cache Redis do Azure devem ser habilitadas | Ativação de auditoria apenas de conexões via SSL para o Cache do Azure para 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 | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os servidores flexíveis PostgreSQL devem estar executando o TLS versão 1.2 ou mais recente | Esta política ajuda a auditar quaisquer servidores flexíveis PostgreSQL em seu ambiente que esteja sendo executado com TLS versão inferior a 1.2. | AuditIfNotExists; Desabilitado | 1.1.0 |
| A Instância Gerenciada SQL deve ter a versão TLS mínima da 1.2 | Definir a versão mínima do TLS como 1.2 melhora a segurança, garantindo que sua Instância Gerenciada SQL só possa ser acessada a partir de clientes que usam o TLS 1.2. O uso de versões do TLS inferiores a 1.2 não é recomendado, pois elas têm vulnerabilidades de segurança bem documentadas. | Auditoria; Desabilitado | 1.0.1 |
| A transferência segura para contas de armazenamento deve ser ativada | Requisito de auditoria de transferência segura em sua conta de armazenamento. A transferência segura é uma opção que força sua conta de armazenamento a aceitar solicitações somente de conexões seguras (HTTPS). O uso de HTTPS 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 | Auditoria; Negar; Desabilitado | 2.0.0 |
| As contas de armazenamento devem ter a versão TLS mínima especificada | Configure uma versão mínima do TLS para comunicação segura entre o aplicativo cliente e a conta de armazenamento. Para minimizar o risco de segurança, a versão mínima recomendada do TLS é a versão mais recente, que atualmente é o TLS 1.2. | Auditoria; Negar; Desabilitado | 1.0.0 |
| As máquinas Windows devem ser configuradas para usar protocolos de comunicação seguros | Para proteger a privacidade das informações comunicadas pela Internet, suas máquinas devem usar a versão mais recente do protocolo criptográfico padrão do setor, Transport Layer Security (TLS). O TLS protege as comunicações através de uma rede encriptando uma ligação entre máquinas. | AuditIfNotExists; Desabilitado | 4.1.1 |
| [Preview]: A rede de host e VM deve ser protegida em sistemas HCI do Azure Stack | Proteja dados na rede de hosts HCI do Azure Stack e em conexões de rede de máquina virtual. | Auditoria; Deficientes; AuditIfNotExists | 1.0.0-pré-visualização |
DP-4: Habilitar a criptografia de dados em repouso por padrão
Para obter mais informações, consulte Proteção de dados: DP-4: habilitar criptografia de dados em repouso por padrão.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Um administrador do Microsoft Entra deve ser provisionado para servidores MySQL | Provisionamento de auditoria de um administrador do Microsoft Entra para o seu servidor MySQL para habilitar a autenticação do Microsoft Entra. A autenticação do Microsoft Entra 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 | AuditIfNotExists; Desabilitado | 1.1.1 |
| As variáveis de conta de automação devem ser criptografadas | É importante habilitar a criptografia de ativos variáveis de conta de automação ao armazenar dados confidenciais | Auditoria; Negar; Desabilitado | 1.1.0 |
| Os trabalhos do Azure Data Box devem habilitar a criptografia dupla para dados em repouso no dispositivo | Habilite uma segunda camada de criptografia baseada em software para dados em repouso no dispositivo. O dispositivo já está protegido através da encriptação Advanced Encryption Standard de 256 bits para dados em repouso. Esta opção adiciona uma segunda camada de encriptação de dados. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os dispositivos do Centro de Hardware de Borda do Azure devem ter suporte a criptografia dupla habilitado | Certifique-se de que os dispositivos encomendados a partir do Centro de Hardware de Borda do Azure têm suporte de criptografia dupla habilitado, para proteger os dados em repouso no dispositivo. Esta opção adiciona uma segunda camada de encriptação de dados. | Auditoria; Negar; Desabilitado | 2.0.0 |
| Os clusters do Azure HDInsight devem usar criptografia no host para criptografar dados em repouso | Habilitar a criptografia no host ajuda a proteger e proteger seus dados para atender aos seus compromissos organizacionais de segurança e conformidade. Quando você habilita a criptografia no host, os dados armazenados no host da VM são criptografados em repouso e fluem criptografados para o serviço de armazenamento. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os clusters de Logs do Azure Monitor devem ser criados com criptografia de infraestrutura habilitada (criptografia dupla) | Para garantir que a criptografia de dados segura seja habilitada no nível de serviço e no nível de infraestrutura com dois algoritmos de criptografia diferentes e duas chaves diferentes, use um cluster dedicado do Azure Monitor. Essa opção é habilitada por padrão quando há suporte na região, consulte Chaves gerenciadas pelo cliente do Azure Monitor. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 1.1.0 |
| O servidor flexível do Azure MySQL deve ter a Autenticação Apenas Entra da Microsoft habilitada | Desabilitar os métodos de autenticação local e permitir apenas a Autenticação do Microsoft Entra melhora a segurança, garantindo que o servidor flexível do Azure MySQL possa ser acessado exclusivamente pelas identidades do Microsoft Entra. | AuditIfNotExists; Desabilitado | 1.0.1 |
| Os Volumes SMB dos Arquivos NetApp do Azure devem usar a criptografia SMB3 | Não permitir a criação de volumes SMB sem criptografia SMB3 para garantir a integridade e a privacidade dos dados. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Arquivos NetApp do Azure Os volumes do tipo NFSv4.1 devem usar a criptografia de dados Kerberos | Só permita o uso do modo de segurança de privacidade Kerberos (5p) para garantir que os dados sejam criptografados. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os dispositivos do Azure Stack Edge devem usar criptografia dupla | Para proteger os dados em repouso no dispositivo, certifique-se de que está duplamente encriptado, que o acesso aos dados é controlado e, uma vez que o dispositivo é desativado, os dados são apagados com segurança dos discos de dados. A criptografia dupla é o uso de duas camadas de criptografia: BitLocker XTS-AES criptografia de 256 bits nos volumes de dados e criptografia interna dos discos rígidos. Saiba mais na documentação de visão geral de segurança para o dispositivo Stack Edge específico. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 1.1.0 |
| A criptografia de disco deve ser habilitada no Azure Data Explorer | Habilitar a criptografia de disco ajuda a proteger e proteger seus dados para atender aos seus compromissos organizacionais de segurança e conformidade. | Auditoria; Negar; Desabilitado | 2.0.0 |
| A criptografia dupla deve ser habilitada no Azure Data Explorer | Habilitar a criptografia dupla ajuda a proteger e proteger seus dados para atender aos seus compromissos organizacionais de segurança e conformidade. Quando a criptografia dupla é habilitada, os dados na conta de armazenamento são criptografados duas vezes, uma no nível de serviço e outra no nível de infraestrutura, usando dois algoritmos de criptografia diferentes e duas chaves diferentes. | Auditoria; Negar; Desabilitado | 2.0.0 |
| Os namespaces do Hub de Eventos devem ter criptografia dupla habilitada | Habilitar a criptografia dupla ajuda a proteger e proteger seus dados para atender aos seus compromissos organizacionais de segurança e conformidade. Quando a criptografia dupla é habilitada, os dados na conta de armazenamento são criptografados duas vezes, uma no nível de serviço e outra no nível de infraestrutura, usando dois algoritmos de criptografia diferentes e duas chaves diferentes. | Auditoria; Negar; Desabilitado | 1.0.0 |
| A criptografia de infraestrutura deve ser habilitada para o Banco de Dados do Azure para servidores MySQL | Habilite a criptografia de infraestrutura para o Banco de Dados do Azure para servidores MySQL para ter um nível mais alto de garantia de que os dados estão seguros. Quando a criptografia de infraestrutura está habilitada, os dados em repouso são criptografados duas vezes usando chaves gerenciadas pela Microsoft compatíveis com FIPS 140-2. | Auditoria; Negar; Desabilitado | 1.0.0 |
| A criptografia de infraestrutura deve ser habilitada para o Banco de Dados do Azure para servidores PostgreSQL | Habilite a criptografia de infraestrutura para o Banco de Dados do Azure para servidores PostgreSQL para ter um nível mais alto de garantia de que os dados estão seguros. Quando a criptografia de infraestrutura está habilitada, os dados em repouso são criptografados duas vezes usando chaves gerenciadas pela Microsoft compatíveis com FIPS 140-2 | Auditoria; Negar; Desabilitado | 1.0.0 |
| As máquinas virtuais Linux devem habilitar o Azure Disk Encryption ou EncryptionAtHost. | Embora o sistema operacional e os discos de dados de uma máquina virtual sejam criptografados em repouso por padrão usando chaves gerenciadas pela plataforma; discos de recursos (discos temporários), caches de dados e dados que fluem entre recursos de computação e armazenamento não são criptografados. Use o Azure Disk Encryption ou EncryptionAtHost para corrigir. Visite Visão geral das opções de criptografia de disco gerenciado para comparar ofertas de criptografia. Essa política requer dois pré-requisitos para ser implantada no escopo da atribuição de política. Para obter detalhes, visite Compreender a configuração da máquina do Azure. | AuditIfNotExists; Desabilitado | 1.2.1 |
| Os discos gerenciados devem ser duplamente criptografados com chaves gerenciadas pela plataforma e gerenciadas pelo cliente | Os clientes sensíveis à alta segurança que estão preocupados com o risco associado a qualquer algoritmo de criptografia específico, implementação ou chave comprometida podem optar por uma camada adicional de criptografia usando um algoritmo/modo de criptografia diferente na camada de infraestrutura usando chaves de criptografia gerenciadas pela plataforma. Os conjuntos de criptografia de disco são necessários para usar criptografia dupla. Saiba mais em Criptografia do lado do servidor de discos gerenciados do Azure. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os namespaces do Service Bus devem ter criptografia dupla habilitada | Habilitar a criptografia dupla ajuda a proteger e proteger seus dados para atender aos seus compromissos organizacionais de segurança e conformidade. Quando a criptografia dupla é habilitada, os dados na conta de armazenamento são criptografados duas vezes, uma no nível de serviço e outra no nível de infraestrutura, usando dois algoritmos de criptografia diferentes e duas chaves diferentes. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os clusters do Service Fabric devem ter a propriedade ClusterProtectionLevel definida como EncryptAndSign | O Service Fabric fornece três níveis de proteção (Nenhum, Assinar e EncryptAndSign) para comunicação nó a nó usando um certificado de cluster primário. Defina o nível de proteção para garantir que todas as mensagens nó a nó sejam criptografadas e assinadas digitalmente | Auditoria; Negar; Desabilitado | 1.1.0 |
| As contas de armazenamento devem ter criptografia de infraestrutura | Habilite a criptografia de infraestrutura para obter um nível mais alto de garantia de que os dados estão seguros. Quando a criptografia de infraestrutura está habilitada, os dados em uma conta de armazenamento são criptografados duas vezes. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os discos temporários e o cache para pools de nós de agente nos clusters do Serviço Kubernetes do Azure devem ser criptografados no host | Para melhorar a segurança dos dados, os dados armazenados no host da máquina virtual (VM) das VMs dos nós do Serviço Kubernetes do Azure devem ser criptografados em repouso. Este é um requisito comum em muitas normas regulatórias e de conformidade do setor. | Auditoria; Negar; Desabilitado | 1.0.1 |
| A criptografia de dados transparente deve ser habilitada para instâncias gerenciadas do Arc SQL. | Habilite a criptografia de dados transparente (TDE) em repouso em uma Instância Gerenciada SQL habilitada para Azure Arc. Saiba mais em Criptografar um banco de dados com criptografia de dados transparente manualmente na Instância Gerenciada SQL habilitada pelo Azure Arc. | Auditoria; Desabilitado | 1.0.0 |
| A criptografia de dados transparente em bancos de dados SQL deve ser habilitada | A criptografia de dados transparente deve ser habilitada para proteger os dados em repouso e atender aos requisitos de conformidade | AuditIfNotExists; Desabilitado | 2.0.0 |
| Máquinas virtuais e conjuntos de dimensionamento de máquinas virtuais devem ter a criptografia no host habilitada | Use a criptografia no host para obter criptografia de ponta a ponta para sua máquina virtual e dados do conjunto de dimensionamento da máquina virtual. A criptografia no host permite a criptografia em repouso para seus caches de disco temporário e SO/disco de dados. Os discos temporários e efêmeros do sistema operacional são criptografados com chaves gerenciadas pela plataforma quando a criptografia no host está ativada. Os caches de disco de SO/dados são criptografados em repouso com chave gerenciada pelo cliente ou gerenciada pela plataforma, dependendo do tipo de criptografia selecionado no disco. Saiba mais em Habilitar criptografia de ponta a ponta usando criptografia no host. | Auditoria; Negar; Desabilitado | 1.0.0 |
| As máquinas virtuais do Windows devem habilitar a Criptografia de Disco do Azure ou EncryptionAtHost. | Embora o sistema operacional e os discos de dados de uma máquina virtual sejam criptografados em repouso por padrão usando chaves gerenciadas pela plataforma; discos de recursos (discos temporários), caches de dados e dados que fluem entre recursos de computação e armazenamento não são criptografados. Use o Azure Disk Encryption ou EncryptionAtHost para corrigir. Visite Visão geral das opções de criptografia de disco gerenciado para comparar ofertas de criptografia. Essa política requer dois pré-requisitos para ser implantada no escopo da atribuição de política. Para obter detalhes, visite Compreender a configuração da máquina do Azure. | AuditIfNotExists; Desabilitado | 1.1.1 |
DP-5: Use a opção de chave gerenciada pelo cliente na criptografia de dados em repouso quando necessário
Para obter mais informações, consulte Proteção de dados: DP-5: usar a opção de chave gerenciada pelo cliente na criptografia de dados em repouso quando necessário.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Os recursos dos Serviços de IA do Azure devem criptografar dados em repouso com uma chave gerenciada pelo cliente (CMK) | O uso de chaves gerenciadas pelo cliente para criptografar dados em repouso fornece mais controle sobre o ciclo de vida da chave, incluindo rotação e gerenciamento. Isso é particularmente relevante para organizações com requisitos de conformidade relacionados. Isso não é avaliado por padrão e só deve ser aplicado quando exigido por requisitos de conformidade ou de política restritiva. Se não estiverem habilitados, os dados serão criptografados usando chaves gerenciadas pela plataforma. Para implementar isso, atualize o parâmetro 'Effect' na Política de Segurança para o escopo aplicável. | Auditoria; Negar; Desabilitado | 2.2.0 |
| A API do Azure para FHIR deve usar uma chave gerenciada pelo cliente para criptografar dados em repouso | Use uma chave gerenciada pelo cliente para controlar a criptografia em repouso dos dados armazenados na API do Azure para FHIR quando isso for um requisito regulatório ou de conformidade. As chaves gerenciadas pelo cliente também oferecem criptografia dupla, adicionando uma segunda camada de criptografia à padrão feita com chaves gerenciadas por serviço. | auditoria; Auditoria; deficientes; Desabilitado | 1.1.0 |
| As contas de Automação do Azure devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso | Use chaves gerenciadas pelo cliente para gerenciar a criptografia em repouso de suas Contas de Automação do Azure. Por padrão, os dados do cliente são criptografados com chaves gerenciadas pelo serviço, mas as chaves gerenciadas pelo cliente geralmente são necessárias para atender aos padrões de conformidade regulamentar. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Cofre de Chaves do Azure criada e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo substituição e gerenciamento. Saiba mais em Criptografia de ativos seguros na Automação do Azure. | Auditoria; Negar; Desabilitado | 1.0.0 |
| A conta do Lote do Azure deve usar chaves gerenciadas pelo cliente para criptografar dados | Use chaves gerenciadas pelo cliente para gerenciar a criptografia em repouso dos dados da sua conta Batch. Por padrão, os dados do cliente são criptografados com chaves gerenciadas pelo serviço, mas as chaves gerenciadas pelo cliente geralmente são necessárias para atender aos padrões de conformidade regulamentar. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Cofre de Chaves do Azure criada e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo substituição e gerenciamento. Saiba mais em Criptografia de dados de conta em lote. | Auditoria; Negar; Desabilitado | 1.0.1 |
| O Cache do Azure para Redis Enterprise deve usar chaves gerenciadas pelo cliente para criptografar dados de disco | Use chaves gerenciadas pelo cliente (CMK) para gerenciar a criptografia em repouso dos dados no disco. Por padrão, os dados do cliente são criptografados com chaves gerenciadas pela plataforma (PMK), mas as chaves gerenciadas pelo cliente geralmente são necessárias para atender aos padrões de conformidade regulamentar. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Cofre de Chaves do Azure criada e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo substituição e gerenciamento. Saiba mais em Configurar criptografia de disco no Cache do Azure para Redis. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O grupo de contêineres da Instância de Contêiner do Azure deve usar a chave gerenciada pelo cliente para criptografia | Proteja seus contêineres com maior flexibilidade usando chaves gerenciadas pelo cliente. Quando você especifica uma chave gerenciada pelo cliente, essa chave é usada para proteger e controlar o acesso à chave que criptografa seus dados. O uso de chaves gerenciadas pelo cliente fornece recursos adicionais para controlar a rotação da chave de criptografia de chave ou apagar dados criptograficamente. | Auditoria; Deficientes; Negar | 1.0.0 |
| As contas do Azure Cosmos DB devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso | 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 geralmente são necessárias para atender aos padrões de conformidade regulamentar. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Cofre de Chaves do Azure criada e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo substituição e gerenciamento. Saiba mais em Configurar chaves de Customer-Managed. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 1.1.0 |
| Os trabalhos do Azure Data Box devem usar uma chave gerenciada pelo cliente para criptografar a senha de desbloqueio do dispositivo | Use uma chave gerenciada pelo cliente para controlar a criptografia da senha de desbloqueio do dispositivo para o Azure Data Box. As chaves gerenciadas pelo cliente também ajudam a gerenciar o acesso à senha de desbloqueio do dispositivo pelo serviço Data Box, a fim de preparar o dispositivo e copiar dados de forma automatizada. Os dados no próprio dispositivo já estão criptografados em repouso com criptografia de 256 bits Advanced Encryption Standard e a senha de desbloqueio do dispositivo é criptografada por padrão com uma chave gerenciada pela Microsoft. | Auditoria; Negar; Desabilitado | 1.0.0 |
| A criptografia do Azure Data Explorer em repouso deve usar uma chave gerenciada pelo cliente | Habilitar a criptografia em repouso usando uma chave gerenciada pelo cliente em seu cluster do Azure Data Explorer fornece controle adicional sobre a chave que está sendo usada pela criptografia em repouso. Esse recurso geralmente é aplicável a clientes com requisitos especiais de conformidade e requer um Cofre de Chaves para gerenciar as chaves. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os espaços de trabalho do Azure Databricks devem ser SKU Premium que ofereça suporte a recursos como link privado, chave gerenciada pelo cliente para criptografia | Permita apenas o espaço de trabalho Databricks com Sku Premium que sua organização possa implantar para oferecer suporte a recursos como Private Link, chave gerenciada pelo cliente para criptografia. Saiba mais em: Configurar a conectividade privada de back-end para o Azure Databricks. | Auditoria; Negar; Desabilitado | 1.0.1 |
| As contas do Azure Device Update devem usar a chave gerenciada pelo cliente para criptografar dados em repouso | A criptografia de dados em repouso na Atualização de Dispositivo do Azure com chave gerenciada pelo cliente adiciona uma segunda camada de criptografia sobre as chaves gerenciadas pelo serviço padrão, permite o controle de chaves pelo cliente, políticas de rotação personalizadas e a capacidade de gerenciar o acesso aos dados por meio do controle de acesso de chave. Saiba mais em:Criptografia de dados para Atualização de Dispositivo para Hub IoT. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os clusters do Azure HDInsight devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso | Use chaves gerenciadas pelo cliente para gerenciar a criptografia em repouso de seus clusters do Azure HDInsight. Por padrão, os dados do cliente são criptografados com chaves gerenciadas pelo serviço, mas as chaves gerenciadas pelo cliente geralmente são necessárias para atender aos padrões de conformidade regulamentar. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Cofre de Chaves do Azure criada e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo substituição e gerenciamento. Saiba mais em Criptografia dupla para dados em repouso. | Auditoria; Negar; Desabilitado | 1.0.1 |
| Os Bots de Saúde do Azure devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso | Use chaves gerenciadas pelo cliente (CMK) para gerenciar a criptografia em repouso dos dados de seus healthbots. Por padrão, os dados são criptografados em repouso com chaves gerenciadas por serviço, mas a CMK geralmente é necessária para atender aos padrões de conformidade regulamentar. A CMK permite 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 substituição e gerenciamento. Saiba mais em Configurar chaves gerenciadas pelo cliente para criptografia de dados no serviço do agente de assistência médica | Auditoria; Desabilitado | 1.0.0 |
| Os espaços de trabalho do Azure Machine Learning devem ser criptografados com uma chave gerenciada pelo cliente | Gerencie a criptografia no restante dos dados do espaço de trabalho do Azure Machine Learning com chaves gerenciadas pelo cliente. Por padrão, os dados do cliente são criptografados com chaves gerenciadas pelo serviço, mas as chaves gerenciadas pelo cliente geralmente são necessárias para atender aos padrões de conformidade regulamentar. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Cofre de Chaves do Azure criada e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo substituição e gerenciamento. Saiba mais em Criar um espaço de trabalho com o modelo do Azure Resource Manager. | Auditoria; Negar; Desabilitado | 1.1.0 |
| Os espaços de trabalho do Azure Machine Learning devem ser criptografados com o uso de uma chave gerenciada pelo cliente | Gerencie a criptografia no restante dos dados do espaço de trabalho do Azure Machine Learning com chaves gerenciadas pelo cliente. Por padrão, os dados do cliente são criptografados com chaves gerenciadas pelo serviço, mas as chaves gerenciadas pelo cliente geralmente são necessárias para atender aos padrões de conformidade regulamentar. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Cofre de Chaves do Azure criada e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo substituição e gerenciamento. Saiba mais em Criar um espaço de trabalho com o modelo do Azure Resource Manager. | AuditIfNotExists; Desabilitado | 1.0.0 |
| Os clusters do Azure Monitor Logs devem ser criptografados com chave gerenciada pelo cliente | Crie o cluster de logs do Azure Monitor com criptografia de chaves gerenciadas pelo cliente. Por padrão, os dados de log são criptografados com chaves gerenciadas por serviço, mas as chaves gerenciadas pelo cliente geralmente são necessárias para atender à conformidade regulamentar. A chave gerenciada pelo cliente no Azure Monitor oferece mais controle sobre o acesso aos seus dados, consulte Configurar chaves gerenciadas pelo cliente no Azure Monitor. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 1.1.0 |
| Os trabalhos do Azure Stream Analytics devem usar chaves gerenciadas pelo cliente para criptografar dados | Use chaves gerenciadas pelo cliente quando quiser armazenar com segurança quaisquer metadados e ativos de dados privados de seus trabalhos do Stream Analytics em sua conta de armazenamento. Isso lhe dá controle total sobre como seus dados do Stream Analytics são criptografados. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 1.1.0 |
| Os espaços de trabalho do Azure Synapse devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso | Use chaves gerenciadas pelo cliente para controlar a criptografia em repouso dos dados armazenados nos espaços de trabalho do Azure Synapse. As chaves gerenciadas pelo cliente oferecem criptografia dupla adicionando uma segunda camada de criptografia sobre a criptografia padrão com chaves gerenciadas por serviço. | Auditoria; Negar; Desabilitado | 1.0.0 |
| As fábricas de dados do Azure devem ser criptografadas com uma chave gerenciada pelo cliente | Use chaves gerenciadas pelo cliente para gerenciar a criptografia em repouso do Azure Data Factory. Por padrão, os dados do cliente são criptografados com chaves gerenciadas pelo serviço, mas as chaves gerenciadas pelo cliente geralmente são necessárias para atender aos padrões de conformidade regulamentar. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Cofre de Chaves do Azure criada e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo substituição e gerenciamento. Saiba mais em Criptografar o Azure Data Factory com chave gerenciada pelo cliente. | Auditoria; Negar; Desabilitado | 1.0.1 |
| O recurso de teste de carga do Azure deve usar chaves gerenciadas pelo cliente para criptografar dados em repouso | Use chaves gerenciadas pelo cliente (CMK) para gerenciar a criptografia em repouso para seu recurso de Teste de Carga do Azure. Por padrão, a criptografia é feita usando chaves gerenciadas pelo serviço, as chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Cofre de Chaves do Azure criada e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo substituição e gerenciamento. Saiba mais em Configurar chaves gerenciadas pelo cliente para o Teste de Carga do Azure com o Azure Key Vault. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O Serviço de Bot deve ser criptografado com uma chave gerenciada pelo cliente | O Serviço de Bot do Azure criptografa automaticamente seu recurso para proteger seus dados e cumprir os compromissos organizacionais de segurança e conformidade. Por padrão, as chaves de criptografia gerenciadas pela Microsoft são usadas. Para maior flexibilidade na gestão de chaves ou no controlo do acesso à sua subscrição, selecione chaves geridas pelo cliente, também conhecidas como traga a sua própria chave (BYOK). Saiba mais sobre a criptografia do Serviço de Bot do Azure: criptografia do Serviço de Bot do Azure AI para dados em repouso. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 1.1.0 |
| Os sistemas operacionais e os discos de dados nos clusters do Serviço Kubernetes do Azure devem ser criptografados por chaves gerenciadas pelo cliente | A encriptação do SO e dos discos de dados utilizando chaves geridas pelo cliente proporciona mais controlo e maior flexibilidade na gestão de chaves. Este é um requisito comum em muitas normas regulatórias e de conformidade do setor. | Auditoria; Negar; Desabilitado | 1.0.1 |
| Os registros de contêiner devem ser criptografados com uma chave gerenciada pelo cliente | Use chaves gerenciadas pelo cliente para gerenciar a criptografia no restante do conteúdo de seus registros. Por padrão, os dados são criptografados em repouso com chaves gerenciadas por serviço, mas as chaves gerenciadas pelo cliente geralmente são necessárias para atender aos padrões de conformidade regulamentar. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Cofre de Chaves do Azure criada e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo substituição e gerenciamento. Saiba mais em Customer-Managed Chaves para o Registro de Contêiner do Azure. | Auditoria; Negar; Desabilitado | 1.1.2 |
| A criptografia de chave gerenciada pelo cliente deve ser usada como parte do CMK Encryption for Arc SQL managed instances. | Como parte da criptografia CMK, a criptografia de chave gerenciada pelo cliente deve ser usada. Saiba mais em Criptografar um banco de dados com criptografia de dados transparente manualmente na Instância Gerenciada SQL habilitada pelo Azure Arc. | Auditoria; Desabilitado | 1.0.0 |
| O Serviço DICOM deve usar uma chave gerenciada pelo cliente para criptografar dados em repouso | Use uma chave gerenciada pelo cliente para controlar a criptografia em repouso dos dados armazenados no Serviço DICOM dos Serviços de Dados de Saúde do Azure quando isso for um requisito regulatório ou de conformidade. As chaves gerenciadas pelo cliente também oferecem criptografia dupla, adicionando uma segunda camada de criptografia à padrão feita com chaves gerenciadas por serviço. | Auditoria; Desabilitado | 1.0.0 |
| O ElasticSan Volume Group deve usar chaves gerenciadas pelo cliente para criptografar dados em repouso | Use chaves gerenciadas pelo cliente para gerenciar a criptografia no restante do seu VolumeGroup. Por padrão, os dados do cliente são criptografados com chaves gerenciadas pela plataforma, mas as CMKs geralmente são necessárias para atender aos padrões de conformidade regulamentar. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Cofre de Chaves do Azure criada e de sua propriedade, com total controle e responsabilidade, incluindo rotação e gerenciamento. | Auditoria; Desabilitado | 1.0.0 |
| Os namespaces do Hub de Eventos devem usar uma chave gerenciada pelo cliente para criptografia | Os Hubs de Eventos do Azure dão suporte à opção de criptografar dados em repouso com chaves gerenciadas pela Microsoft (padrão) ou chaves gerenciadas pelo cliente. Optar por criptografar dados usando chaves gerenciadas pelo cliente permite atribuir, girar, desabilitar e revogar o acesso às chaves que o Hub de Eventos usará para criptografar dados em seu namespace. Observe que o Hub de Eventos só oferece suporte à criptografia com chaves gerenciadas pelo cliente para namespaces em clusters dedicados. | Auditoria; Desabilitado | 1.0.0 |
| O Serviço FHIR deve usar uma chave gerenciada pelo cliente para criptografar dados em repouso | Use uma chave gerenciada pelo cliente para controlar a criptografia em repouso dos dados armazenados no Serviço FHIR dos Serviços de Dados de Integridade do Azure quando esse for um requisito regulatório ou de conformidade. As chaves gerenciadas pelo cliente também oferecem criptografia dupla, adicionando uma segunda camada de criptografia à padrão feita com chaves gerenciadas por serviço. | Auditoria; Desabilitado | 1.0.0 |
| O Fluid Relay deve usar chaves gerenciadas pelo cliente para criptografar dados em repouso | Use chaves gerenciadas pelo cliente para gerenciar a criptografia em repouso do seu servidor Fluid Relay. 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 chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Cofre de Chaves do Azure criada e de sua propriedade, com total controle e responsabilidade, incluindo rotação e gerenciamento. Saiba mais em Chaves gerenciadas pelo cliente para criptografia do Azure Fluid Relay. | Auditoria; Desabilitado | 1.0.0 |
| As contas de cache HPC devem usar a chave gerenciada pelo cliente para criptografia | Gerencie a criptografia em repouso do Cache HPC do Azure com chaves gerenciadas pelo cliente. Por padrão, os dados do cliente são criptografados com chaves gerenciadas pelo serviço, mas as chaves gerenciadas pelo cliente geralmente são necessárias para atender aos padrões de conformidade regulamentar. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Cofre de Chaves do Azure criada e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo substituição e gerenciamento. | Auditoria; Deficientes; Negar | 2.0.0 |
| O Ambiente do Serviço de Integração de Aplicativos Lógicos deve ser criptografado com chaves gerenciadas pelo cliente | Implante no Integration Service Environment para gerenciar a criptografia no restante dos dados dos Aplicativos Lógicos usando chaves gerenciadas pelo cliente. Por padrão, os dados do cliente são criptografados com chaves gerenciadas pelo serviço, mas as chaves gerenciadas pelo cliente geralmente são necessárias para atender aos padrões de conformidade regulamentar. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Cofre de Chaves do Azure criada e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo substituição e gerenciamento. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os discos gerenciados devem ser duplamente criptografados com chaves gerenciadas pela plataforma e gerenciadas pelo cliente | Os clientes sensíveis à alta segurança que estão preocupados com o risco associado a qualquer algoritmo de criptografia específico, implementação ou chave comprometida podem optar por uma camada adicional de criptografia usando um algoritmo/modo de criptografia diferente na camada de infraestrutura usando chaves de criptografia gerenciadas pela plataforma. Os conjuntos de criptografia de disco são necessários para usar criptografia dupla. Saiba mais em Criptografia do lado do servidor de discos gerenciados do Azure. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os discos gerenciados devem usar um conjunto específico de conjuntos de criptografia de disco para a criptografia de chave gerenciada pelo cliente | Exigir que um conjunto específico de conjuntos de criptografia de disco seja usado com discos gerenciados lhe dá controle sobre as chaves usadas para criptografia em repouso. Você pode selecionar os conjuntos criptografados permitidos e todos os outros são rejeitados quando anexados a um disco. Saiba mais em Criptografia do lado do servidor de discos gerenciados do Azure. | Auditoria; Negar; Desabilitado | 2.0.0 |
| Os servidores MySQL devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso | 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 geralmente são necessárias para atender aos padrões de conformidade regulamentar. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Cofre de Chaves do Azure criada e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo substituição e gerenciamento. | AuditIfNotExists; Desabilitado | 1.0.4 |
| OS e discos de dados devem ser criptografados com uma chave gerenciada pelo cliente | Use chaves gerenciadas pelo cliente para gerenciar a criptografia no restante do conteúdo de seus discos gerenciados. Por padrão, os dados são criptografados em repouso com chaves gerenciadas pela plataforma, mas as chaves gerenciadas pelo cliente geralmente são necessárias para atender aos padrões de conformidade regulamentar. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Cofre de Chaves do Azure criada e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo substituição e gerenciamento. Saiba mais em Criptografia do lado do servidor de discos gerenciados do Azure. | Auditoria; Negar; Desabilitado | 3.0.0 |
| Os servidores flexíveis do PostgreSQL devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso | Use chaves gerenciadas pelo cliente para gerenciar a criptografia em repouso de seus servidores flexíveis PostgreSQL. Por padrão, os dados são criptografados em repouso com chaves gerenciadas por serviço, mas as chaves gerenciadas pelo cliente geralmente são necessárias para atender aos padrões de conformidade regulamentar. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Cofre de Chaves do Azure criada e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo substituição e gerenciamento. | Auditoria; Negar; Desabilitado | 1.1.0 |
| Os servidores PostgreSQL devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso | 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 geralmente são necessárias para atender aos padrões de conformidade regulamentar. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Cofre de Chaves do Azure criada e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo substituição e gerenciamento. | AuditIfNotExists; Desabilitado | 1.0.4 |
| O armazenamento em fila deve usar a chave gerenciada pelo cliente para criptografia | Proteja seu armazenamento em fila com maior flexibilidade usando chaves gerenciadas pelo cliente. Quando você especifica uma chave gerenciada pelo cliente, essa chave é usada para proteger e controlar o acesso à chave que criptografa seus dados. O uso de chaves gerenciadas pelo cliente fornece recursos adicionais para controlar a rotação da chave de criptografia de chave ou apagar dados criptograficamente. | Auditoria; Negar; Desabilitado | 1.0.0 |
| As instâncias gerenciadas pelo SQL devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso | 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. | Auditoria; Negar; Desabilitado | 2.0.0 |
| Os servidores SQL devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso | 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. | Auditoria; Negar; Desabilitado | 2.0.1 |
| Os namespaces Premium do Service Bus devem usar uma chave gerenciada pelo cliente para criptografia | O Barramento de Serviço do Azure dá suporte à opção de criptografar dados em repouso com chaves gerenciadas pela Microsoft (padrão) ou chaves gerenciadas pelo cliente. Optar por criptografar dados usando chaves gerenciadas pelo cliente permite atribuir, girar, desabilitar e revogar o acesso às chaves que o Service Bus usará para criptografar dados em seu namespace. Observe que o Service Bus só oferece suporte à criptografia com chaves gerenciadas pelo cliente para namespaces premium. | Auditoria; Desabilitado | 1.0.0 |
| Os escopos de criptografia de conta de armazenamento devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso | Use chaves gerenciadas pelo cliente para gerenciar a criptografia em repouso dos escopos de criptografia da conta de armazenamento. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do cofre de chaves do Azure criada e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo substituição e gerenciamento. Saiba mais sobre escopos de criptografia de conta de armazenamento em Escopos de criptografia para armazenamento de Blob. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os escopos de criptografia de conta de armazenamento devem usar criptografia dupla para dados em repouso | Habilite a criptografia de infraestrutura para criptografia em repouso dos escopos de criptografia da conta de armazenamento para maior segurança. A criptografia de infraestrutura garante que seus dados sejam criptografados duas vezes. | Auditoria; Negar; Desabilitado | 1.0.0 |
| As contas de armazenamento devem usar a chave gerenciada pelo cliente para criptografia | Proteja sua conta de armazenamento de arquivos e blob com maior flexibilidade usando chaves gerenciadas pelo cliente. Quando você especifica uma chave gerenciada pelo cliente, essa chave é usada para proteger e controlar o acesso à chave que criptografa seus dados. O uso de chaves gerenciadas pelo cliente fornece recursos adicionais para controlar a rotação da chave de criptografia de chave ou apagar dados criptograficamente. | Auditoria; Desabilitado | 1.0.3 |
| O armazenamento de tabela deve usar a chave gerenciada pelo cliente para criptografia | Proteja o armazenamento da sua mesa com maior flexibilidade usando chaves gerenciadas pelo cliente. Quando você especifica uma chave gerenciada pelo cliente, essa chave é usada para proteger e controlar o acesso à chave que criptografa seus dados. O uso de chaves gerenciadas pelo cliente fornece recursos adicionais para controlar a rotação da chave de criptografia de chave ou apagar dados criptograficamente. | Auditoria; Negar; Desabilitado | 1.0.0 |
| [Preterido]: O Grupo SIM deve usar chaves gerenciadas pelo cliente para criptografar dados em repouso | Esta política foi preterida porque o provedor de recursos Microsoft.MobileNetwork foi desativado sem substituição. Recomendamos que você remova todas as atribuições desta política e todas as referências a ela das iniciativas. Saiba mais sobre a substituição da definição de política em aka.ms/policydefdeprecation. | Auditoria; Negar; Desabilitado | 1.1.0-preterido |
| [Pré-visualização]: Os sistemas HCI do Azure Stack devem ter volumes encriptados | Use o BitLocker para criptografar o sistema operacional e os volumes de dados nos sistemas HCI do Azure Stack. | Auditoria; Deficientes; AuditIfNotExists | 1.0.0-pré-visualização |
DP-6: Use um processo seguro de gerenciamento de chaves
Para obter mais informações, consulte Proteção de dados: DP-6: usar um processo seguro de gerenciamento de chaves.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Os valores nomeados do segredo do Gerenciamento de API devem ser armazenados no Cofre de Chaves do Azure | Os valores nomeados são uma coleção de pares de nome e valor em cada serviço de Gerenciamento de API. Os valores secretos podem ser armazenados como texto criptografado no Gerenciamento de API (segredos personalizados) ou fazendo referência a segredos no Cofre de Chaves do Azure. Para melhorar a segurança do Gerenciamento de API e segredos, faça referência a valores nomeados de segredo do Cofre de Chaves do Azure. O Azure Key Vault dá suporte a gerenciamento de acesso granular e políticas de rotação de segredos. | Auditoria; Deficientes; Negar | 1.0.2 |
| As contas do Azure Cosmos DB não devem exceder o número máximo de dias permitido desde a última regeneração da chave de conta. | Regenere as suas chaves no tempo especificado para manter os seus dados mais protegidos. | Auditoria; Desabilitado | 1.0.0 |
| As chaves do Cofre da Chave devem ter uma data de expiração | As chaves criptográficas devem ter uma data de validade definida e não ser permanentes. As chaves que são válidas para sempre fornecem a um atacante em potencial mais tempo para comprometer a chave. É uma prática de segurança recomendada definir datas de expiração em chaves criptográficas. | Auditoria; Negar; Desabilitado | 1.0.2 |
| Os segredos do Cofre de Chaves devem ter uma data de validade | Os segredos devem ter uma data de validade definida e não ser permanentes. Segredos que são válidos para sempre fornecem a um atacante em potencial mais tempo para comprometê-los. É uma prática de segurança recomendada definir datas de validade em segredos. | Auditoria; Negar; Desabilitado | 1.0.2 |
| As chaves devem ter uma política de rotação que garanta que sua rotação seja agendada dentro do número especificado de dias após a criação. | Gerencie seus requisitos de conformidade organizacional especificando o número máximo de dias após a criação da chave até que ela seja rotativa. | Auditoria; Desabilitado | 1.0.0 |
| As chaves devem ter o período de validade máximo especificado | Gerencie seus requisitos de conformidade organizacional especificando a quantidade máxima de tempo em dias que uma chave pode ser válida dentro do seu cofre de chaves. | Auditoria; Negar; Desabilitado | 1.0.1 |
| As chaves não devem ficar ativas por mais tempo do que o número especificado de dias | Especifique o número de dias em que uma chave deve estar ativa. As chaves que são usadas por um longo período de tempo aumentam a probabilidade de que um invasor possa comprometer a chave. Como boa prática de segurança, certifique-se de que as suas chaves não estão ativas há mais de dois anos. | Auditoria; Negar; Desabilitado | 1.0.1 |
| Os segredos devem ter mais do que o número especificado de dias antes da expiração | Se um segredo estiver muito perto da expiração, um atraso organizacional para girar o segredo pode resultar em uma interrupção. Os segredos devem ser alternados em um número especificado de dias antes da expiração para fornecer tempo suficiente para reagir a uma falha. | Auditoria; Negar; Desabilitado | 1.0.1 |
| Os segredos devem ter o período máximo de validade especificado | Gerencie seus requisitos de conformidade organizacional especificando a quantidade máxima de tempo em dias que um segredo pode ser válido em seu cofre de chaves. | Auditoria; Negar; Desabilitado | 1.0.1 |
| Os segredos não devem estar ativos por mais tempo do que o número de dias especificado | Se seus segredos foram criados com uma data de ativação definida no futuro, você deve garantir que seus segredos não estejam ativos por mais tempo do que a duração especificada. | Auditoria; Negar; Desabilitado | 1.0.1 |
| As chaves de conta de armazenamento não devem ter expirado | Certifique-se de que as chaves da conta de armazenamento do usuário não tenham expirado quando a política de expiração de chaves for definida, para melhorar a segurança das chaves de conta tomando medidas quando as chaves expirarem. | Auditoria; Negar; Desabilitado | 3.0.0 |
DP-7: Use um processo seguro de gerenciamento de certificados
Para obter mais informações, consulte Proteção de dados: DP-7: usar um processo seguro de gerenciamento de certificados.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Os certificados devem ter o período de validade máximo especificado | Gerencie seus requisitos de conformidade organizacional especificando a quantidade máxima de tempo que um certificado pode ser válido em seu cofre de chaves. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 2.2.1 |
| Os certificados devem ter o período de validade máximo especificado | Gerencie seus requisitos de conformidade organizacional especificando a quantidade máxima de tempo que um certificado pode ser válido em seu cofre de chaves. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 2.2.1 |
| Os certificados não devem expirar dentro do número de dias especificado | Gerencie certificados que expirarão dentro de um número especificado de dias para garantir que sua organização tenha tempo suficiente para girar o certificado antes da expiração. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 2.1.1 |
DP-8: Garantir a segurança do repositório de chaves e certificados
Para obter mais informações, consulte Proteção de dados: DP-8: Garantir a segurança do repositório de chaves e certificados.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| O Azure Defender for Key Vault deve ser habilitado | O Azure Defender for Key Vault fornece uma camada adicional de proteção e inteligência de segurança ao detetar tentativas incomuns e potencialmente prejudiciais de acessar ou explorar contas de cofre de chaves. | AuditIfNotExists; Desabilitado | 1.0.3 |
| O Azure Key Vault deve ter firewall habilitado ou acesso à rede pública desabilitado | Habilite o firewall do cofre de chaves para que o cofre de chaves não seja acessível por padrão a nenhum IPs público ou desabilite o acesso à rede pública do cofre de chaves para que ele não esteja acessível pela Internet pública. Opcionalmente, você pode configurar intervalos de IP específicos para limitar o acesso a essas redes. Saiba mais em: Segurança de rede para o Azure Key Vault e Integrar o Key Vault com o Azure Private Link | Auditoria; Negar; Desabilitado | 3.3.0 |
| Os Cofres de Chaves do Azure devem usar o link privado | O Azure Private Link permite conectar suas redes virtuais 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. Ao mapear pontos de extremidade privados para o cofre de chaves, você pode reduzir os riscos de vazamento de dados. Saiba mais sobre links privados em: Integrar o Cofre da Chave com o Azure Private Link. | Auditoria; Negar; Desabilitado | 1.2.1 |
| Os cofres de chaves devem ter a proteção contra exclusão ativada | A exclusão maliciosa de um cofre de chaves pode levar à perda permanente de dados. Você pode evitar a perda permanente de dados ativando a proteção contra limpeza e a exclusão suave. A proteção contra limpeza protege você contra ataques internos, impondo um período de retenção obrigatório para cofres de chaves excluídos por software. Ninguém dentro da sua organização ou da Microsoft poderá limpar seus cofres de chaves durante o período de retenção de exclusão suave. Lembre-se de que os cofres de chaves criados após 1º de setembro de 2019 têm a exclusão suave habilitada por padrão. | Auditoria; Negar; Desabilitado | 2.1.0 |
| Os cofres de chaves devem ter a exclusão suave ativada | A exclusão de um cofre de chaves sem a exclusão automática habilitada exclui permanentemente todos os segredos, chaves e certificados armazenados no cofre de chaves. A exclusão acidental de um cofre de chaves pode levar à perda permanente de dados. A exclusão suave permite que você recupere um cofre de chaves excluído acidentalmente por um período de retenção configurável. | Auditoria; Negar; Desabilitado | 3.1.0 |
| Os logs de recursos no Azure Key Vault devem ser ativados | Ativação de auditoria de logs de recursos. Isso permite que você recrie trilhas de atividade para usar para fins de investigação quando ocorrer um incidente de segurança ou quando sua rede estiver comprometida | AuditIfNotExists; Desabilitado | 5.0.0 |
DS-6: Proteja o ciclo de vida da carga de trabalho
Para obter mais informações, consulte Segurança de DevOps: DS-6: Proteger o ciclo de vida da carga de trabalho.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| As imagens de contêiner do Registro do Azure devem ter vulnerabilidades resolvidas (com tecnologia Microsoft Defender Vulnerability Management) | A avaliação de vulnerabilidade da imagem de contêiner verifica o registro em busca de vulnerabilidades comumente conhecidas (CVEs) e fornece um relatório de vulnerabilidade detalhado para cada imagem. A resolução de vulnerabilidades pode melhorar muito sua postura de segurança, garantindo que as imagens sejam seguras para uso antes da implantação. | AuditIfNotExists; Desabilitado | 1.0.1 |
| As imagens de contentores em execução no Azure devem ter as vulnerabilidades resolvidas (impulsionado por Microsoft Defender Vulnerability Management) | A avaliação de vulnerabilidade da imagem de contêiner verifica o registro em busca de vulnerabilidades comumente conhecidas (CVEs) e fornece um relatório de vulnerabilidade detalhado para cada imagem. Essa recomendação fornece visibilidade para imagens vulneráveis atualmente em execução em seus clusters Kubernetes. Corrigir vulnerabilidades em imagens de contêiner que estão em execução no momento é fundamental para melhorar sua postura de segurança, reduzindo significativamente a superfície de ataque para suas cargas de trabalho conteinerizadas. | AuditIfNotExists; Desabilitado | 1.0.1 |
ES-1: Usar Detecção e Resposta de Endpoint (EDR)
Para obter mais informações, consulte Endpoint Security: ES-1: Use Endpoint Detection and Response (EDR).
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| O Azure Defender para servidores deve estar habilitado | O Azure Defender para servidores fornece proteção contra ameaças em tempo real para cargas de trabalho de servidor e gera recomendações de proteção, bem como alertas sobre atividades suspeitas. | AuditIfNotExists; Desabilitado | 1.0.3 |
ES-2: Utilize software moderno de anti-malware
Para obter mais informações, consulte Endpoint Security: ES-2: Use software antimalware moderno.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| O Windows Defender Exploit Guard deve ser ativado nas suas máquinas | O Windows Defender Exploit Guard usa o agente de Configuração de Convidado de Política do Azure. O Exploit Guard tem quatro componentes projetados para bloquear dispositivos contra uma ampla variedade de vetores de ataque e bloquear comportamentos comumente usados em ataques de malware, permitindo que as empresas equilibrem seus requisitos de segurança, risco e produtividade (somente Windows). | AuditIfNotExists; Desabilitado | 2.0.0 |
IM-1: Use ferramentas automatizadas para monitorar anomalias
Para obter mais informações, consulte Gerenciamento de identidade: IM-1: usar ferramentas automatizadas para monitorar anomalias.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Um administrador do Microsoft Entra deve ser provisionado para servidores PostgreSQL | Provisionamento de auditoria de um administrador do Microsoft Entra para seu servidor PostgreSQL para habilitar a autenticação do Microsoft Entra. A autenticação do Microsoft Entra 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 | AuditIfNotExists; Desabilitado | 1.0.1 |
| Um administrador do Ative Directory do Azure deve ser provisionado para servidores SQL | Provisionamento de auditoria de um administrador do Azure Ative Directory 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 | AuditIfNotExists; Desabilitado | 1.0.0 |
| Os aplicativos do Serviço de Aplicativo devem ter métodos de autenticação local desabilitados para implantações FTP | A desativação de métodos de autenticação local para implantações FTP melhora a segurança, garantindo que os Serviços de Aplicativo exijam exclusivamente identidades do Microsoft Entra para autenticação. Saiba mais em: Desativando autenticação básica no Serviço de Aplicativo. | AuditIfNotExists; Desabilitado | 1.0.3 |
| Os aplicativos do Serviço de Aplicativo devem ter métodos de autenticação local desabilitados para implantações de site SCM | A desativação de métodos de autenticação local para sites SCM melhora a segurança, garantindo que os Serviços de Aplicativo exijam exclusivamente identidades do Microsoft Entra para autenticação. Saiba mais em: Desativando autenticação básica no Serviço de Aplicativo. | AuditIfNotExists; Desabilitado | 1.0.3 |
| Os componentes do Application Insights devem bloquear a ingestão baseada no Ative Directory que não seja do Azure. | Obrigar a ingestão de logs a exigir a autenticação do Active Directory do Azure impede que um invasor envie logs não autenticados, o que pode levar a estados incorretos, alertas falsos e logs incorretos armazenados no sistema. | Negar; Auditoria; Desabilitado | 1.0.0 |
| Os recursos dos Serviços de IA do Azure devem ter o acesso à chave desabilitado (desabilitar a autenticação local) | Recomenda-se que o acesso à chave (autenticação local) seja desativado por segurança. O Azure OpenAI Studio, normalmente usado em desenvolvimento/teste, requer acesso de chave e não funcionará se o acesso de chave estiver desabilitado. Após a desativação, o Microsoft Entra ID torna-se o único método de acesso, que permite manter o princípio de privilégio mínimo e controle granular. Saiba mais em: Autenticação nos serviços de IA do Azure | Auditoria; Negar; Desabilitado | 1.1.0 |
| Os Clusters de Serviço do Kubernetes do Azure devem habilitar a integração do Microsoft Entra ID | A integração do Microsoft Entra ID gerenciada pelo AKS pode gerenciar o acesso aos clusters configurando o controle de acesso baseado em função do Kubernetes (Kubernetes RBAC) com base na identidade do usuário ou na associação ao grupo de diretórios. Saiba mais em: Habilite a integração do Microsoft Entra gerenciada pelo AKS em um cluster do Serviço Kubernetes do Azure. | Auditoria; Desabilitado | 1.0.2 |
| Os Cálculos do Azure Machine Learning devem ter os métodos de autenticação local desativados | A desativação de métodos de autenticação local melhora a segurança, garantindo que os Cálculos de Aprendizado de Máquina exijam identidades do Azure Ative Directory exclusivamente para autenticação. Saiba mais em: Controles de Conformidade Regulatória de Política do Azure para o Azure Machine Learning. | Auditoria; Negar; Desabilitado | 2.1.0 |
| O Banco de Dados SQL do Azure deve ter a autenticação somente Microsoft Entra-habilitada | Exija que os servidores lógicos SQL do Azure usem a autenticação somente Microsoft Entra. Esta política não impede que os servidores sejam criados com a autenticação local ativada. Ele impede que a autenticação local seja habilitada em recursos após a criação. Considere usar a iniciativa 'Microsoft Entra-only authentication' em vez de exigir ambos. Saiba mais em: Criar servidor com a autenticação do Microsoft Entra-Only habilitada. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O Banco de Dados SQL do Azure deve ter a autenticação somente Microsoft Entra-somente habilitada durante a criação | Exija que os servidores lógicos SQL do Azure sejam criados com autenticação somente Microsoft Entra. Esta política não impede que a autenticação local seja reativada em recursos após a criação. Considere usar a iniciativa 'Microsoft Entra-only authentication' em vez de exigir ambos. Saiba mais em: Criar servidor com a autenticação do Microsoft Entra-Only habilitada. | Auditoria; Negar; Desabilitado | 1.2.0 |
| A Instância Gerenciada SQL do Azure deve ter a autenticação somente Microsoft Entra-habilitada | Exija que a Instância Gerenciada SQL do Azure use a autenticação somente Microsoft Entra. Esta política não impede que instâncias SQL Managed do Azure sejam criadas com a autenticação local habilitada. Ele impede que a autenticação local seja habilitada em recursos após a criação. Considere usar a iniciativa 'Microsoft Entra-only authentication' em vez de exigir ambos. Saiba mais em: Criar servidor com a autenticação do Microsoft Entra-Only habilitada. | Auditoria; Negar; Desabilitado | 1.0.0 |
| As Instâncias Gerenciadas SQL do Azure devem ter a autenticação somente Microsoft Entra-habilitada durante a criação | Exija que a Instância Gerenciada SQL do Azure seja criada com autenticação somente Microsoft Entra. Esta política não impede que a autenticação local seja reativada em recursos após a criação. Considere usar a iniciativa 'Microsoft Entra-only authentication' em vez de exigir ambos. Saiba mais em: Criar servidor com a autenticação do Microsoft Entra-Only habilitada. | Auditoria; Negar; Desabilitado | 1.2.0 |
| Configurar os recursos dos Serviços de IA do Azure para desabilitar o acesso à chave local (desabilitar a autenticação local) | Recomenda-se que o acesso à chave (autenticação local) seja desativado por segurança. O Azure OpenAI Studio, normalmente usado em desenvolvimento/teste, requer acesso de chave e não funcionará se o acesso de chave estiver desabilitado. Após a desativação, o Microsoft Entra ID torna-se o único método de acesso, que permite manter o princípio de privilégio mínimo e controle granular. Saiba mais em: Autenticação nos serviços de IA do Azure | DeployIfNotExists; Desabilitado | 1.0.0 |
| Os registros de contêiner devem ter a conta de administrador local desabilitada. | Desative a conta de administrador do seu registro para que ele não seja acessível pelo administrador local. A desativação de métodos de autenticação local, como usuário administrador, tokens de acesso com escopo de repositório e pull anônimo, melhora a segurança, garantindo que os registros de contêiner exijam exclusivamente identidades do Azure Ative Directory para autenticação. Saiba mais em: Opções de autenticação do Registro de contêiner do Azure explicadas. | Auditoria; Negar; Desabilitado | 1.0.1 |
| As contas de banco de dados do Cosmos DB devem ter métodos de autenticação local desabilitados | A desativação de métodos de autenticação local melhora a segurança, garantindo que as contas de banco de dados do Cosmos DB exijam exclusivamente identidades do Azure Ative Directory para autenticação. Saiba mais em: Conectar-se ao Azure Cosmos DB para NoSQL usando o controle de acesso baseado em função e a ID do Microsoft Entra. | Auditoria; Negar; Desabilitado | 1.1.0 |
| Os clusters do Service Fabric só devem usar o Azure Ative Directory para autenticação de cliente | Auditar o uso da autenticação de cliente somente por meio do Azure Ative Directory no Service Fabric | Auditoria; Negar; Desabilitado | 1.1.0 |
| As contas de armazenamento devem impedir o acesso à chave compartilhada | 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. Destes dois tipos de autorização, o Azure AD garante segurança superior e facilidade de utilização da Chave Partilhada, pelo que é a recomendação da Microsoft. | Auditoria; Negar; Desabilitado | 2.0.0 |
| As contas de armazenamento devem impedir o acesso de chave compartilhada (excluindo contas de armazenamento criadas pelo Databricks) | 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. Destes dois tipos de autorização, o Azure AD garante segurança superior e facilidade de utilização da Chave Partilhada, pelo que é a recomendação da Microsoft. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os espaços de trabalho Synapse devem ter a autenticação somente Microsoft Entra-habilitada | Exija que o Synapse Workspaces use a autenticação somente do Microsoft Entra. Esta política não impede que espaços de trabalho sejam criados com a autenticação local ativada. Ele impede que a autenticação local seja habilitada em recursos após a criação. Considere usar a iniciativa 'Microsoft Entra-only authentication' em vez de exigir ambos. Saiba mais em: Azure Synapse Analytics. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os espaços de trabalho Synapse devem usar apenas identidades do Microsoft Entra para autenticação durante a criação do espaço de trabalho | Exija que os espaços de trabalho Synapse sejam criados com autenticação somente Microsoft Entra. Esta política não impede que a autenticação local seja reativada em recursos após a criação. Considere usar a iniciativa 'Microsoft Entra-only authentication' em vez de exigir ambos. Saiba mais em: Azure Synapse Analytics. | Auditoria; Negar; Desabilitado | 1.2.0 |
| Os gateways de VPN devem usar apenas a autenticação do Azure Ative Directory (Azure AD) para usuários ponto a site | A desativação de métodos de autenticação local melhora a segurança, garantindo que os Gateways de VPN usem apenas identidades do Azure Ative Directory para autenticação. Saiba mais sobre a autenticação do Azure AD em Configurar gateway VPN P2S para autenticação de ID do Microsoft Entra | Auditoria; Negar; Desabilitado | 1.0.0 |
| [Pré-visualização]: O servidor flexível do Azure PostgreSQL deve ter a Autenticação Apenas Entra da Microsoft ativada | Desabilitar métodos de autenticação local e permitir apenas a Autenticação Microsoft Entra melhora a segurança, garantindo que o servidor flexível PostgreSQL do Azure possa ser acessado exclusivamente por identidades Microsoft Entra. | Auditoria; Desabilitado | 1.0.0-pré-visualização |
IM-2: Detetar e analisar incidentes de segurança
Para obter mais informações, consulte Gerenciamento de identidade: IM-2: detetar e analisar incidentes de segurança.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Os usuários devem se autenticar com autenticação multifator para criar ou atualizar recursos | Esta definição de política bloqueia operações de criação e atualização de recursos quando o chamador não é autenticado via MFA. Para obter mais informações, visite Plan for mandatory Microsoft Entra multifactor authentication (MFA). | Auditoria; Negar; Desabilitado | 1.0.1 |
IM-3: Melhorar os processos de resposta a incidentes
Para obter mais informações, consulte Gerenciamento de identidade: IM-3: melhorar os processos de resposta a incidentes.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Os slots de aplicações do Serviço de Aplicações devem usar identidade gerida | Usar uma identidade gerenciada para segurança de autenticação aprimorada | AuditIfNotExists; Desabilitado | 1.0.0 |
| Os aplicativos do Serviço de Aplicativo devem usar identidade gerenciada | Usar uma identidade gerenciada para segurança de autenticação aprimorada | AuditIfNotExists; Desabilitado | 3.0.0 |
| A Conta de Automação deve ter Identidade Gerenciada | Use Identidades Gerenciadas como o método recomendado para autenticação com recursos do Azure a partir dos runbooks. A identidade gerenciada para autenticação é mais segura e elimina a sobrecarga de gerenciamento associada ao uso da Conta RunAs no código do runbook. | Auditoria; Desabilitado | 1.0.0 |
| Os serviços vinculados do Azure Data Factory devem usar a autenticação de identidade gerenciada atribuída ao sistema quando houver suporte | O uso de identidade gerenciada atribuída ao sistema ao se comunicar com armazenamentos de dados por meio de serviços vinculados evita o uso de credenciais menos seguras, como senhas ou cadeias de conexão. | Auditoria; Negar; Desabilitado | 2.1.0 |
| Os espaços de trabalho do Azure Machine Learning devem usar a identidade gerenciada atribuída pelo usuário | Acesso Manange ao espaço de trabalho do Azure ML e recursos associados, Azure Container Registry, KeyVault, Storage e App Insights usando a identidade gerenciada atribuída pelo usuário. Por padrão, a identidade gerenciada atribuída ao sistema é usada pelo espaço de trabalho do Azure ML para acessar os recursos associados. A identidade gerenciada atribuída pelo usuário permite que você crie a identidade como um recurso do Azure e mantenha o ciclo de vida dessa identidade. Saiba mais em Configurar a autenticação entre o Azure Machine Learning e outros serviços. | Auditoria; Negar; Desabilitado | 1.0.0 |
| As contas dos Serviços Cognitivos devem usar uma identidade gerenciada | Atribuir uma identidade gerenciada à sua conta do Serviço Cognitivo ajuda a garantir uma autenticação segura. Essa identidade é usada por essa conta de serviço Cognitivo para se comunicar com outros serviços do Azure, como o Cofre da Chave do Azure, de forma segura, sem que você precise gerenciar credenciais. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O recurso de serviço de comunicação deve usar uma identidade gerenciada | A atribuição de uma identidade gerenciada ao seu recurso de serviço de Comunicação ajuda a garantir a autenticação segura. Essa identidade é usada por esse recurso de serviço de Comunicação para se comunicar com outros serviços do Azure, como o Armazenamento do Azure, de forma segura, sem que você precise gerenciar credenciais. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os aplicativos de função devem usar identidade gerenciada | Usar uma identidade gerenciada para segurança de autenticação aprimorada | AuditIfNotExists; Desabilitado | 3.1.0 |
| A Identidade Gerenciada deve ser habilitada para Aplicativos de Contêiner | A imposição de identidade gerenciada garante que os Aplicativos de Contêiner possam se autenticar com segurança em qualquer recurso que ofereça suporte à autenticação do Azure AD | Auditoria; Negar; Desabilitado | 1.0.1 |
| O trabalho do Stream Analytics deve usar a identidade gerenciada para autenticar pontos de extremidade | Certifique-se de que os trabalhos do Stream Analytics se conectem apenas a pontos de extremidade usando autenticação de identidade gerenciada. | Negar; Deficientes; Auditoria | 1.0.0 |
| A extensão Configuração de Convidado das máquinas virtuais deve ser implantada com identidade gerenciada atribuída ao sistema | A extensão Configuração de Convidado requer uma identidade gerenciada atribuída ao sistema. As máquinas virtuais do Azure no âmbito desta política não serão compatíveis quando tiverem a extensão Configuração de Convidado instalada, mas não tiverem uma identidade gerida atribuída ao sistema. Saiba mais em Compreender a Configuração da Máquina do Azure | AuditIfNotExists; Desabilitado | 1.0.1 |
| [Pré-visualização]: Uma identidade gerida deve ser ativada nas suas máquinas | Os recursos gerenciados pelo Automanage devem ter uma identidade gerenciada. | Auditoria; Desabilitado | 1.0.0-pré-visualização |
| [Preview]: As credenciais federadas de identidade gerenciada do Kubernetes do Azure devem ser de fontes confiáveis | Esta política limita a federeation com clusters do Azure Kubernetes apenas a clusters de locatários aprovados, regiões aprovadas e uma lista de exceções específica de clusters adicionais. | Auditoria; Deficientes; Negar | 1.0.0-pré-visualização |
| [Preview]: As credenciais federadas de identidade gerenciada do GitHub devem ser de proprietários de repositórios confiáveis | Esta política limita a federação com repositórios GitHub apenas a proprietários de repositórios aprovados. | Auditoria; Deficientes; Negar | 1.0.1-Pré-visualização |
| [Visualização]: As credenciais federadas de identidade gerenciada devem ser de tipos de emissor permitidos | Esta política limita se as Identidades Gerenciadas podem usar credenciais federadas, quais tipos de emissor comuns são permitidos e fornece uma lista de exceções de emissor permitidas. | Auditoria; Deficientes; Negar | 1.0.0-pré-visualização |
IM-4: Habilite os recursos de registro e deteção de ameaças
Para obter mais informações, consulte Gerenciamento de identidade: IM-4: habilitar recursos de registro e deteção de ameaças.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| As chamadas de gerenciamento de API para back-ends de API devem ser autenticadas | As chamadas do Gerenciamento de API para back-ends devem usar alguma forma de autenticação, seja por meio de certificados ou credenciais. Não se aplica a back-ends do Service Fabric. | Auditoria; Deficientes; Negar | 1.0.1 |
| As chamadas de gerenciamento de API para back-ends de API não devem ignorar a impressão digital do certificado ou a validação de nome | Para melhorar a segurança da API, o Gerenciamento de API deve validar o certificado do servidor back-end para todas as chamadas de API. Habilite a impressão digital do certificado SSL e a validação de nome. | Auditoria; Deficientes; Negar | 1.0.2 |
| Os endpoints de API no API Management do Azure devem ser autenticados | Os pontos de extremidade de API publicados no Gerenciamento de API do Azure devem impor a autenticação para ajudar a minimizar o risco de segurança. Por vezes, os mecanismos de autenticação são implementados incorretamente ou estão em falta. Isso permite que os invasores explorem falhas de implementação e acessem dados. Saiba mais sobre a ameaça da API OWASP para autenticação de usuário quebrada aqui: Recomendações para mitigar a segurança da API OWASP As 10 principais ameaças usando o Gerenciamento de API | AuditIfNotExists; Desabilitado | 1.0.1 |
| O Banco de Dados SQL do Azure deve estar executando o TLS versão 1.2 ou mais recente | 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. | Auditoria; Deficientes; Negar | 2.0.0 |
IM-6: Usar resposta automatizada a incidentes
Para obter mais informações, consulte Gerenciamento de identidade: IM-6: usar resposta automatizada a incidentes.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| A autenticação em máquinas Linux deve exigir chaves SSH | Embora o próprio SSH forneça uma conexão criptografada, o uso de senhas com SSH ainda deixa a VM vulnerável a ataques de força bruta. A opção mais segura para autenticação em uma máquina virtual Linux do Azure sobre SSH é com um par de chaves público-privado, também conhecido como chaves SSH. Saiba mais: Etapas detalhadas: crie e gerencie chaves SSH para autenticação em uma VM Linux no Azure. | AuditIfNotExists; Desabilitado | 3.2.0 |
IM-8: Restringir o acesso às portas de gerenciamento
Para obter mais informações, consulte Gerenciamento de identidade: IM-8: restringir o acesso às portas de gerenciamento.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Os valores nomeados do segredo do Gerenciamento de API devem ser armazenados no Cofre de Chaves do Azure | Os valores nomeados são uma coleção de pares de nome e valor em cada serviço de Gerenciamento de API. Os valores secretos podem ser armazenados como texto criptografado no Gerenciamento de API (segredos personalizados) ou fazendo referência a segredos no Cofre de Chaves do Azure. Para melhorar a segurança do Gerenciamento de API e segredos, faça referência a valores nomeados de segredo do Cofre de Chaves do Azure. O Azure Key Vault dá suporte a gerenciamento de acesso granular e políticas de rotação de segredos. | Auditoria; Deficientes; Negar | 1.0.2 |
| Máquinas devem ter descobertas secretas resolvidas | Audita máquinas virtuais para detetar se elas contêm descobertas secretas das soluções de verificação secretas em suas máquinas virtuais. | AuditIfNotExists; Desabilitado | 1.0.2 |
IR-2: Preparação – notificação de incidente de configuração
Para obter mais informações, consulte Resposta a incidentes: IR-2: Preparação – notificação de incidente de configuração.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| A notificação por e-mail para alertas de alta gravidade deve ser ativada | 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 as notificações por e-mail para alertas de alta gravidade na Central de Segurança. | AuditIfNotExists; Desabilitado | 1.2.0 |
| A notificação por e-mail ao proprietário da assinatura para alertas de alta gravidade deve ser habilitada | 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 Centro de Segurança. | AuditIfNotExists; Desabilitado | 2.1.0 |
| As subscrições devem ter um endereço de e-mail de contacto para questões de segurança | Para garantir que as pessoas relevantes na sua organização sejam notificadas quando houver uma potencial violação de segurança numa das suas subscrições, defina um contacto de segurança para receber notificações por correio eletrónico do Centro de Segurança. | AuditIfNotExists; Desabilitado | 1.0.1 |
IR-3: Deteção e análise – crie incidentes com base em alertas de alta qualidade
Para obter mais informações, consulte Resposta a incidentes: IR-3: deteção e análise – crie incidentes com base em alertas de alta qualidade.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| O Azure Defender for App Service deve estar habilitado | O Azure Defender for App Service aproveita a escala da nuvem e a visibilidade que o Azure tem como um provedor de nuvem para monitorar ataques comuns a aplicativos Web. | AuditIfNotExists; Desabilitado | 1.0.3 |
| Os servidores do Banco de Dados SQL do Azure Defender for Azure devem ser habilitados | O Azure Defender para SQL fornece funcionalidade para revelar e mitigar possíveis vulnerabilidades de banco de dados, detetar atividades anômalas que podem indicar ameaças a bancos de dados SQL e descobrir e classificar dados confidenciais. | AuditIfNotExists; Desabilitado | 1.0.2 |
| O Azure Defender for Key Vault deve ser habilitado | O Azure Defender for Key Vault fornece uma camada adicional de proteção e inteligência de segurança ao detetar tentativas incomuns e potencialmente prejudiciais de acessar ou explorar contas de cofre de chaves. | AuditIfNotExists; Desabilitado | 1.0.3 |
| O Azure Defender for Resource Manager deve estar habilitado | O Azure Defender for Resource Manager monitoriza automaticamente as operações de gestão de recursos na sua organização. O Azure Defender deteta ameaças e alerta-o sobre atividades suspeitas. Saiba mais sobre os recursos do Azure Defender for Resource Manager em Microsoft Defender for Resource Manager - Benefícios e Recursos . Habilitar este plano do Azure Defender resulta em cobranças. Saiba mais sobre os detalhes de preços por região na página de preços da Central de Segurança: Preços - Microsoft Defender for Cloud . | AuditIfNotExists; Desabilitado | 1.0.0 |
| Azure Defender para SQL servidores em máquinas deve ser habilitado | O Azure Defender para SQL fornece funcionalidade para revelar e mitigar possíveis vulnerabilidades de banco de dados, detetar atividades anômalas que podem indicar ameaças a bancos de dados SQL e descobrir e classificar dados confidenciais. | AuditIfNotExists; Desabilitado | 1.0.2 |
| O Azure Defender for SQL deve ser habilitado para servidores SQL do Azure desprotegidos | Audite servidores SQL sem Segurança de Dados Avançada | AuditIfNotExists; Desabilitado | 2.0.1 |
| O Azure Defender for SQL deve ser habilitado para servidores flexíveis MySQL desprotegidos | Audite servidores flexíveis MySQL sem Segurança de Dados Avançada | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Azure Defender for SQL deve ser habilitado para servidores flexíveis PostgreSQL desprotegidos | Audite servidores flexíveis PostgreSQL sem Segurança de Dados Avançada | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Azure Defender for SQL deve ser habilitado para Instâncias Gerenciadas SQL desprotegidas | Audite cada instância gerenciada SQL sem segurança de dados avançada. | AuditIfNotExists; Desabilitado | 1.0.2 |
| O Azure Defender para bancos de dados relacionais de código aberto deve ser habilitado | O Azure 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 sobre os recursos do Azure Defender para bancos de dados relacionais de código aberto em Visão geral do Defender para Open-Source bancos de dados relacionais. Importante: habilitar esse plano resultará em cobranças para proteger seus bancos de dados relacionais de código aberto. Saiba mais sobre os preços na página de preços da Central de Segurança: Preços - Microsoft Defender for Cloud | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Azure Defender para servidores deve estar habilitado | O Azure Defender para servidores fornece proteção contra ameaças em tempo real para cargas de trabalho de servidor e gera recomendações de proteção, bem como alertas sobre atividades suspeitas. | AuditIfNotExists; Desabilitado | 1.0.3 |
| Microsoft Defender CSPM deve ser habilitado | O Defender Cloud Security Posture Management (CSPM) fornece recursos aprimorados de postura e um novo gráfico inteligente de segurança na nuvem para ajudar a identificar, priorizar e reduzir riscos. O Defender CSPM está disponível, além dos recursos gratuitos de postura de segurança fundamental ativados por padrão no Defender for Cloud. | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Microsoft Defender para APIs deve estar habilitado | O Microsoft Defender para APIs traz novas descobertas, proteção, deteção, cobertura de resposta de & para monitorar ataques comuns baseados em API ou configurações incorretas de segurança. | AuditIfNotExists; Desabilitado | 1.0.3 |
| Microsoft Defender for Containers deve estar habilitado | O Microsoft Defender for Containers fornece proteção, avaliação de vulnerabilidades e proteções em tempo de execução para seus ambientes Kubernetes Azure, híbridos e multinuvem. | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Microsoft Defender para SQL deve ser habilitado para espaços de trabalho Synapse desprotegidos | Habilite o Defender for SQL para proteger seus espaços de trabalho Synapse. O Defender for SQL monitora seu Synapse SQL para detetar atividades anômalas que indicam tentativas incomuns e potencialmente prejudiciais de acessar ou explorar bancos de dados. | AuditIfNotExists; Desabilitado | 1.0.0 |
| O status do Microsoft Defender for SQL deve ser protegido para SQL Servers habilitados para Arc | O Microsoft Defender for SQL fornece funcionalidade para detetar e mitigar possíveis vulnerabilidades de banco de dados, detetar atividades anômalas que podem indicar ameaças a bancos de dados SQL, descobrir e classificar dados confidenciais. Uma vez habilitado, o status de proteção indica que o recurso é monitorado ativamente. Mesmo quando o Defender está habilitado, várias definições de configuração devem ser validadas no agente, na máquina, no espaço de trabalho e no servidor SQL para garantir a proteção ativa. | Auditoria; Desabilitado | 1.1.0 |
| O Microsoft Defender for Storage deve estar habilitado | O Microsoft Defender for Storage deteta ameaças potenciais às suas contas de armazenamento. Ele ajuda a evitar os três principais impactos em seus dados e carga de trabalho: uploads de arquivos mal-intencionados, exfiltração de dados confidenciais e corrupção de dados. O novo plano do Defender for Storage inclui verificação de malware e deteção de ameaças de dados confidenciais. Esse plano também fornece uma estrutura de preços previsível (por conta de armazenamento) para controle sobre a cobertura e os custos. | AuditIfNotExists; Desabilitado | 1.0.0 |
| O provisionamento automático direcionado ao SQL Server deve ser habilitado para servidores SQL no plano de máquinas | Para garantir que suas VMs SQL e SQL Servers habilitados para Arc estejam protegidos, verifique se o Agente de Monitoramento do Azure direcionado para SQL está configurado para implantação automática. Isso também é necessário se você configurou anteriormente o provisionamento automático do Microsoft Monitoring Agent, pois esse componente está sendo preterido. Saiba mais: Migrar para o Defender for SQL em máquinas que usam AMA | AuditIfNotExists; Desabilitado | 1.0.0 |
IR-4: Deteção e análise – investigar um incidente
Para obter mais informações, consulte Resposta a incidentes: IR-4: Deteção e análise – investigar um incidente.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| O Inspetor de Rede deve estar ativado | 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 visualização de nível de rede de ponta a ponta. É necessário ter um grupo de recursos de observador de rede a ser criado em cada região onde uma rede virtual está presente. Um alerta será ativado se um grupo de recursos do inspetor de rede não estiver disponível em uma região específica. | AuditIfNotExists; Desabilitado | 3.0.0 |
IR-5: Deteção e análise – priorizar incidentes
Para obter mais informações, consulte Resposta a incidentes: IR-5: Deteção e análise – priorizar incidentes.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| O Azure Defender for App Service deve estar habilitado | O Azure Defender for App Service aproveita a escala da nuvem e a visibilidade que o Azure tem como um provedor de nuvem para monitorar ataques comuns a aplicativos Web. | AuditIfNotExists; Desabilitado | 1.0.3 |
| Os servidores do Banco de Dados SQL do Azure Defender for Azure devem ser habilitados | O Azure Defender para SQL fornece funcionalidade para revelar e mitigar possíveis vulnerabilidades de banco de dados, detetar atividades anômalas que podem indicar ameaças a bancos de dados SQL e descobrir e classificar dados confidenciais. | AuditIfNotExists; Desabilitado | 1.0.2 |
| O Azure Defender for Key Vault deve ser habilitado | O Azure Defender for Key Vault fornece uma camada adicional de proteção e inteligência de segurança ao detetar tentativas incomuns e potencialmente prejudiciais de acessar ou explorar contas de cofre de chaves. | AuditIfNotExists; Desabilitado | 1.0.3 |
| O Azure Defender for Resource Manager deve estar habilitado | O Azure Defender for Resource Manager monitoriza automaticamente as operações de gestão de recursos na sua organização. O Azure Defender deteta ameaças e alerta-o sobre atividades suspeitas. Saiba mais sobre os recursos do Azure Defender for Resource Manager em Microsoft Defender for Resource Manager - Benefícios e Recursos . Habilitar este plano do Azure Defender resulta em cobranças. Saiba mais sobre os detalhes de preços por região na página de preços da Central de Segurança: Preços - Microsoft Defender for Cloud . | AuditIfNotExists; Desabilitado | 1.0.0 |
| Azure Defender para SQL servidores em máquinas deve ser habilitado | O Azure Defender para SQL fornece funcionalidade para revelar e mitigar possíveis vulnerabilidades de banco de dados, detetar atividades anômalas que podem indicar ameaças a bancos de dados SQL e descobrir e classificar dados confidenciais. | AuditIfNotExists; Desabilitado | 1.0.2 |
| O Azure Defender for SQL deve ser habilitado para servidores SQL do Azure desprotegidos | Audite servidores SQL sem Segurança de Dados Avançada | AuditIfNotExists; Desabilitado | 2.0.1 |
| O Azure Defender for SQL deve ser habilitado para servidores flexíveis MySQL desprotegidos | Audite servidores flexíveis MySQL sem Segurança de Dados Avançada | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Azure Defender for SQL deve ser habilitado para servidores flexíveis PostgreSQL desprotegidos | Audite servidores flexíveis PostgreSQL sem Segurança de Dados Avançada | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Azure Defender for SQL deve ser habilitado para Instâncias Gerenciadas SQL desprotegidas | Audite cada instância gerenciada SQL sem segurança de dados avançada. | AuditIfNotExists; Desabilitado | 1.0.2 |
| O Azure Defender para bancos de dados relacionais de código aberto deve ser habilitado | O Azure 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 sobre os recursos do Azure Defender para bancos de dados relacionais de código aberto em Visão geral do Defender para Open-Source bancos de dados relacionais. Importante: habilitar esse plano resultará em cobranças para proteger seus bancos de dados relacionais de código aberto. Saiba mais sobre os preços na página de preços da Central de Segurança: Preços - Microsoft Defender for Cloud | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Azure Defender para servidores deve estar habilitado | O Azure Defender para servidores fornece proteção contra ameaças em tempo real para cargas de trabalho de servidor e gera recomendações de proteção, bem como alertas sobre atividades suspeitas. | AuditIfNotExists; Desabilitado | 1.0.3 |
| Microsoft Defender CSPM deve ser habilitado | O Defender Cloud Security Posture Management (CSPM) fornece recursos aprimorados de postura e um novo gráfico inteligente de segurança na nuvem para ajudar a identificar, priorizar e reduzir riscos. O Defender CSPM está disponível, além dos recursos gratuitos de postura de segurança fundamental ativados por padrão no Defender for Cloud. | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Microsoft Defender para APIs deve estar habilitado | O Microsoft Defender para APIs traz novas descobertas, proteção, deteção, cobertura de resposta de & para monitorar ataques comuns baseados em API ou configurações incorretas de segurança. | AuditIfNotExists; Desabilitado | 1.0.3 |
| Microsoft Defender for Containers deve estar habilitado | O Microsoft Defender for Containers fornece proteção, avaliação de vulnerabilidades e proteções em tempo de execução para seus ambientes Kubernetes Azure, híbridos e multinuvem. | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Microsoft Defender para SQL deve ser habilitado para espaços de trabalho Synapse desprotegidos | Habilite o Defender for SQL para proteger seus espaços de trabalho Synapse. O Defender for SQL monitora seu Synapse SQL para detetar atividades anômalas que indicam tentativas incomuns e potencialmente prejudiciais de acessar ou explorar bancos de dados. | AuditIfNotExists; Desabilitado | 1.0.0 |
| O status do Microsoft Defender for SQL deve ser protegido para SQL Servers habilitados para Arc | O Microsoft Defender for SQL fornece funcionalidade para detetar e mitigar possíveis vulnerabilidades de banco de dados, detetar atividades anômalas que podem indicar ameaças a bancos de dados SQL, descobrir e classificar dados confidenciais. Uma vez habilitado, o status de proteção indica que o recurso é monitorado ativamente. Mesmo quando o Defender está habilitado, várias definições de configuração devem ser validadas no agente, na máquina, no espaço de trabalho e no servidor SQL para garantir a proteção ativa. | Auditoria; Desabilitado | 1.1.0 |
| O Microsoft Defender for Storage deve estar habilitado | O Microsoft Defender for Storage deteta ameaças potenciais às suas contas de armazenamento. Ele ajuda a evitar os três principais impactos em seus dados e carga de trabalho: uploads de arquivos mal-intencionados, exfiltração de dados confidenciais e corrupção de dados. O novo plano do Defender for Storage inclui verificação de malware e deteção de ameaças de dados confidenciais. Esse plano também fornece uma estrutura de preços previsível (por conta de armazenamento) para controle sobre a cobertura e os custos. | AuditIfNotExists; Desabilitado | 1.0.0 |
| O provisionamento automático direcionado ao SQL Server deve ser habilitado para servidores SQL no plano de máquinas | Para garantir que suas VMs SQL e SQL Servers habilitados para Arc estejam protegidos, verifique se o Agente de Monitoramento do Azure direcionado para SQL está configurado para implantação automática. Isso também é necessário se você configurou anteriormente o provisionamento automático do Microsoft Monitoring Agent, pois esse componente está sendo preterido. Saiba mais: Migrar para o Defender for SQL em máquinas que usam AMA | AuditIfNotExists; Desabilitado | 1.0.0 |
LT-1: Habilite os recursos de deteção de ameaças
Para obter mais informações, consulte Registro em log e deteção de ameaças: LT-1: habilitar recursos de deteção de ameaças.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| O Azure Defender for App Service deve estar habilitado | O Azure Defender for App Service aproveita a escala da nuvem e a visibilidade que o Azure tem como um provedor de nuvem para monitorar ataques comuns a aplicativos Web. | AuditIfNotExists; Desabilitado | 1.0.3 |
| Os servidores do Banco de Dados SQL do Azure Defender for Azure devem ser habilitados | O Azure Defender para SQL fornece funcionalidade para revelar e mitigar possíveis vulnerabilidades de banco de dados, detetar atividades anômalas que podem indicar ameaças a bancos de dados SQL e descobrir e classificar dados confidenciais. | AuditIfNotExists; Desabilitado | 1.0.2 |
| O Azure Defender for Key Vault deve ser habilitado | O Azure Defender for Key Vault fornece uma camada adicional de proteção e inteligência de segurança ao detetar tentativas incomuns e potencialmente prejudiciais de acessar ou explorar contas de cofre de chaves. | AuditIfNotExists; Desabilitado | 1.0.3 |
| O Azure Defender for Resource Manager deve estar habilitado | O Azure Defender for Resource Manager monitoriza automaticamente as operações de gestão de recursos na sua organização. O Azure Defender deteta ameaças e alerta-o sobre atividades suspeitas. Saiba mais sobre os recursos do Azure Defender for Resource Manager em Microsoft Defender for Resource Manager - Benefícios e Recursos . Habilitar este plano do Azure Defender resulta em cobranças. Saiba mais sobre os detalhes de preços por região na página de preços da Central de Segurança: Preços - Microsoft Defender for Cloud . | AuditIfNotExists; Desabilitado | 1.0.0 |
| Azure Defender para SQL servidores em máquinas deve ser habilitado | O Azure Defender para SQL fornece funcionalidade para revelar e mitigar possíveis vulnerabilidades de banco de dados, detetar atividades anômalas que podem indicar ameaças a bancos de dados SQL e descobrir e classificar dados confidenciais. | AuditIfNotExists; Desabilitado | 1.0.2 |
| O Azure Defender for SQL deve ser habilitado para servidores SQL do Azure desprotegidos | Audite servidores SQL sem Segurança de Dados Avançada | AuditIfNotExists; Desabilitado | 2.0.1 |
| O Azure Defender for SQL deve ser habilitado para servidores flexíveis MySQL desprotegidos | Audite servidores flexíveis MySQL sem Segurança de Dados Avançada | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Azure Defender for SQL deve ser habilitado para servidores flexíveis PostgreSQL desprotegidos | Audite servidores flexíveis PostgreSQL sem Segurança de Dados Avançada | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Azure Defender for SQL deve ser habilitado para Instâncias Gerenciadas SQL desprotegidas | Audite cada instância gerenciada SQL sem segurança de dados avançada. | AuditIfNotExists; Desabilitado | 1.0.2 |
| O Azure Defender para bancos de dados relacionais de código aberto deve ser habilitado | O Azure 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 sobre os recursos do Azure Defender para bancos de dados relacionais de código aberto em Visão geral do Defender para Open-Source bancos de dados relacionais. Importante: habilitar esse plano resultará em cobranças para proteger seus bancos de dados relacionais de código aberto. Saiba mais sobre os preços na página de preços da Central de Segurança: Preços - Microsoft Defender for Cloud | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Azure Defender para servidores deve estar habilitado | O Azure Defender para servidores fornece proteção contra ameaças em tempo real para cargas de trabalho de servidor e gera recomendações de proteção, bem como alertas sobre atividades suspeitas. | AuditIfNotExists; Desabilitado | 1.0.3 |
| Os clusters do Serviço Kubernetes do Azure devem ter o perfil do Defender habilitado | O Microsoft Defender for Containers fornece recursos de segurança Kubernetes nativos da nuvem, incluindo proteção de ambiente, proteção de carga de trabalho e proteção em tempo de execução. Quando você habilita o SecurityProfile.AzureDefender no cluster do Serviço Kubernetes do Azure, um agente é implantado no cluster para coletar dados de eventos de segurança. Saiba mais sobre o Microsoft Defender for Containers em Gerenciar recomendações MCSB no Defender for Cloud | Auditoria; Desabilitado | 2.0.1 |
| Microsoft Defender CSPM deve ser habilitado | O Defender Cloud Security Posture Management (CSPM) fornece recursos aprimorados de postura e um novo gráfico inteligente de segurança na nuvem para ajudar a identificar, priorizar e reduzir riscos. O Defender CSPM está disponível, além dos recursos gratuitos de postura de segurança fundamental ativados por padrão no Defender for Cloud. | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Microsoft Defender para APIs deve estar habilitado | O Microsoft Defender para APIs traz novas descobertas, proteção, deteção, cobertura de resposta de & para monitorar ataques comuns baseados em API ou configurações incorretas de segurança. | AuditIfNotExists; Desabilitado | 1.0.3 |
| Microsoft Defender for Containers deve estar habilitado | O Microsoft Defender for Containers fornece proteção, avaliação de vulnerabilidades e proteções em tempo de execução para seus ambientes Kubernetes Azure, híbridos e multinuvem. | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Microsoft Defender para SQL deve ser habilitado para espaços de trabalho Synapse desprotegidos | Habilite o Defender for SQL para proteger seus espaços de trabalho Synapse. O Defender for SQL monitora seu Synapse SQL para detetar atividades anômalas que indicam tentativas incomuns e potencialmente prejudiciais de acessar ou explorar bancos de dados. | AuditIfNotExists; Desabilitado | 1.0.0 |
| O status do Microsoft Defender for SQL deve ser protegido para SQL Servers habilitados para Arc | O Microsoft Defender for SQL fornece funcionalidade para detetar e mitigar possíveis vulnerabilidades de banco de dados, detetar atividades anômalas que podem indicar ameaças a bancos de dados SQL, descobrir e classificar dados confidenciais. Uma vez habilitado, o status de proteção indica que o recurso é monitorado ativamente. Mesmo quando o Defender está habilitado, várias definições de configuração devem ser validadas no agente, na máquina, no espaço de trabalho e no servidor SQL para garantir a proteção ativa. | Auditoria; Desabilitado | 1.1.0 |
| O Microsoft Defender for Storage deve estar habilitado | O Microsoft Defender for Storage deteta ameaças potenciais às suas contas de armazenamento. Ele ajuda a evitar os três principais impactos em seus dados e carga de trabalho: uploads de arquivos mal-intencionados, exfiltração de dados confidenciais e corrupção de dados. O novo plano do Defender for Storage inclui verificação de malware e deteção de ameaças de dados confidenciais. Esse plano também fornece uma estrutura de preços previsível (por conta de armazenamento) para controle sobre a cobertura e os custos. | AuditIfNotExists; Desabilitado | 1.0.0 |
| O provisionamento automático direcionado ao SQL Server deve ser habilitado para servidores SQL no plano de máquinas | Para garantir que suas VMs SQL e SQL Servers habilitados para Arc estejam protegidos, verifique se o Agente de Monitoramento do Azure direcionado para SQL está configurado para implantação automática. Isso também é necessário se você configurou anteriormente o provisionamento automático do Microsoft Monitoring Agent, pois esse componente está sendo preterido. Saiba mais: Migrar para o Defender for SQL em máquinas que usam AMA | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Windows Defender Exploit Guard deve ser ativado nas suas máquinas | O Windows Defender Exploit Guard usa o agente de Configuração de Convidado de Política do Azure. O Exploit Guard tem quatro componentes projetados para bloquear dispositivos contra uma ampla variedade de vetores de ataque e bloquear comportamentos comumente usados em ataques de malware, permitindo que as empresas equilibrem seus requisitos de segurança, risco e produtividade (somente Windows). | AuditIfNotExists; Desabilitado | 2.0.0 |
| [Pré-visualização]: Os clusters Kubernetes ativados para Azure Arc devem ter a extensão Microsoft Defender for Cloud instalada | A extensão do Microsoft Defender for Cloud para Azure Arc fornece proteção contra ameaças para seus clusters Kubernetes habilitados para Arc. A extensão coleta dados de todos os nós no cluster e os envia para o back-end do Azure Defender for Kubernetes na nuvem para análise posterior. Saiba mais em Pontuação segura no Defender for Cloud. | AuditIfNotExists; Desabilitado | 6.0.0-pré-visualização |
LT-2: Habilite a deteção de ameaças para gerenciamento de identidade e acesso
Para obter mais informações, consulte Registro em log e deteção de ameaças: LT-2: habilitar a deteção de ameaças para gerenciamento de identidade e acesso.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| O Azure Defender for App Service deve estar habilitado | O Azure Defender for App Service aproveita a escala da nuvem e a visibilidade que o Azure tem como um provedor de nuvem para monitorar ataques comuns a aplicativos Web. | AuditIfNotExists; Desabilitado | 1.0.3 |
| Os servidores do Banco de Dados SQL do Azure Defender for Azure devem ser habilitados | O Azure Defender para SQL fornece funcionalidade para revelar e mitigar possíveis vulnerabilidades de banco de dados, detetar atividades anômalas que podem indicar ameaças a bancos de dados SQL e descobrir e classificar dados confidenciais. | AuditIfNotExists; Desabilitado | 1.0.2 |
| O Azure Defender for Key Vault deve ser habilitado | O Azure Defender for Key Vault fornece uma camada adicional de proteção e inteligência de segurança ao detetar tentativas incomuns e potencialmente prejudiciais de acessar ou explorar contas de cofre de chaves. | AuditIfNotExists; Desabilitado | 1.0.3 |
| O Azure Defender for Resource Manager deve estar habilitado | O Azure Defender for Resource Manager monitoriza automaticamente as operações de gestão de recursos na sua organização. O Azure Defender deteta ameaças e alerta-o sobre atividades suspeitas. Saiba mais sobre os recursos do Azure Defender for Resource Manager em Microsoft Defender for Resource Manager - Benefícios e Recursos . Habilitar este plano do Azure Defender resulta em cobranças. Saiba mais sobre os detalhes de preços por região na página de preços da Central de Segurança: Preços - Microsoft Defender for Cloud . | AuditIfNotExists; Desabilitado | 1.0.0 |
| Azure Defender para SQL servidores em máquinas deve ser habilitado | O Azure Defender para SQL fornece funcionalidade para revelar e mitigar possíveis vulnerabilidades de banco de dados, detetar atividades anômalas que podem indicar ameaças a bancos de dados SQL e descobrir e classificar dados confidenciais. | AuditIfNotExists; Desabilitado | 1.0.2 |
| O Azure Defender for SQL deve ser habilitado para servidores SQL do Azure desprotegidos | Audite servidores SQL sem Segurança de Dados Avançada | AuditIfNotExists; Desabilitado | 2.0.1 |
| O Azure Defender for SQL deve ser habilitado para servidores flexíveis MySQL desprotegidos | Audite servidores flexíveis MySQL sem Segurança de Dados Avançada | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Azure Defender for SQL deve ser habilitado para servidores flexíveis PostgreSQL desprotegidos | Audite servidores flexíveis PostgreSQL sem Segurança de Dados Avançada | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Azure Defender for SQL deve ser habilitado para Instâncias Gerenciadas SQL desprotegidas | Audite cada instância gerenciada SQL sem segurança de dados avançada. | AuditIfNotExists; Desabilitado | 1.0.2 |
| O Azure Defender para bancos de dados relacionais de código aberto deve ser habilitado | O Azure 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 sobre os recursos do Azure Defender para bancos de dados relacionais de código aberto em Visão geral do Defender para Open-Source bancos de dados relacionais. Importante: habilitar esse plano resultará em cobranças para proteger seus bancos de dados relacionais de código aberto. Saiba mais sobre os preços na página de preços da Central de Segurança: Preços - Microsoft Defender for Cloud | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Azure Defender para servidores deve estar habilitado | O Azure Defender para servidores fornece proteção contra ameaças em tempo real para cargas de trabalho de servidor e gera recomendações de proteção, bem como alertas sobre atividades suspeitas. | AuditIfNotExists; Desabilitado | 1.0.3 |
| Os clusters do Serviço Kubernetes do Azure devem ter o perfil do Defender habilitado | O Microsoft Defender for Containers fornece recursos de segurança Kubernetes nativos da nuvem, incluindo proteção de ambiente, proteção de carga de trabalho e proteção em tempo de execução. Quando você habilita o SecurityProfile.AzureDefender no cluster do Serviço Kubernetes do Azure, um agente é implantado no cluster para coletar dados de eventos de segurança. Saiba mais sobre o Microsoft Defender for Containers em Gerenciar recomendações MCSB no Defender for Cloud | Auditoria; Desabilitado | 2.0.1 |
| Microsoft Defender CSPM deve ser habilitado | O Defender Cloud Security Posture Management (CSPM) fornece recursos aprimorados de postura e um novo gráfico inteligente de segurança na nuvem para ajudar a identificar, priorizar e reduzir riscos. O Defender CSPM está disponível, além dos recursos gratuitos de postura de segurança fundamental ativados por padrão no Defender for Cloud. | AuditIfNotExists; Desabilitado | 1.0.0 |
| Microsoft Defender for Containers deve estar habilitado | O Microsoft Defender for Containers fornece proteção, avaliação de vulnerabilidades e proteções em tempo de execução para seus ambientes Kubernetes Azure, híbridos e multinuvem. | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Microsoft Defender para SQL deve ser habilitado para espaços de trabalho Synapse desprotegidos | Habilite o Defender for SQL para proteger seus espaços de trabalho Synapse. O Defender for SQL monitora seu Synapse SQL para detetar atividades anômalas que indicam tentativas incomuns e potencialmente prejudiciais de acessar ou explorar bancos de dados. | AuditIfNotExists; Desabilitado | 1.0.0 |
| O status do Microsoft Defender for SQL deve ser protegido para SQL Servers habilitados para Arc | O Microsoft Defender for SQL fornece funcionalidade para detetar e mitigar possíveis vulnerabilidades de banco de dados, detetar atividades anômalas que podem indicar ameaças a bancos de dados SQL, descobrir e classificar dados confidenciais. Uma vez habilitado, o status de proteção indica que o recurso é monitorado ativamente. Mesmo quando o Defender está habilitado, várias definições de configuração devem ser validadas no agente, na máquina, no espaço de trabalho e no servidor SQL para garantir a proteção ativa. | Auditoria; Desabilitado | 1.1.0 |
| O Microsoft Defender for Storage deve estar habilitado | O Microsoft Defender for Storage deteta ameaças potenciais às suas contas de armazenamento. Ele ajuda a evitar os três principais impactos em seus dados e carga de trabalho: uploads de arquivos mal-intencionados, exfiltração de dados confidenciais e corrupção de dados. O novo plano do Defender for Storage inclui verificação de malware e deteção de ameaças de dados confidenciais. Esse plano também fornece uma estrutura de preços previsível (por conta de armazenamento) para controle sobre a cobertura e os custos. | AuditIfNotExists; Desabilitado | 1.0.0 |
| O provisionamento automático direcionado ao SQL Server deve ser habilitado para servidores SQL no plano de máquinas | Para garantir que suas VMs SQL e SQL Servers habilitados para Arc estejam protegidos, verifique se o Agente de Monitoramento do Azure direcionado para SQL está configurado para implantação automática. Isso também é necessário se você configurou anteriormente o provisionamento automático do Microsoft Monitoring Agent, pois esse componente está sendo preterido. Saiba mais: Migrar para o Defender for SQL em máquinas que usam AMA | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Windows Defender Exploit Guard deve ser ativado nas suas máquinas | O Windows Defender Exploit Guard usa o agente de Configuração de Convidado de Política do Azure. O Exploit Guard tem quatro componentes projetados para bloquear dispositivos contra uma ampla variedade de vetores de ataque e bloquear comportamentos comumente usados em ataques de malware, permitindo que as empresas equilibrem seus requisitos de segurança, risco e produtividade (somente Windows). | AuditIfNotExists; Desabilitado | 2.0.0 |
| [Pré-visualização]: Os clusters Kubernetes ativados para Azure Arc devem ter a extensão Microsoft Defender for Cloud instalada | A extensão do Microsoft Defender for Cloud para Azure Arc fornece proteção contra ameaças para seus clusters Kubernetes habilitados para Arc. A extensão coleta dados de todos os nós no cluster e os envia para o back-end do Azure Defender for Kubernetes na nuvem para análise posterior. Saiba mais em Pontuação segura no Defender for Cloud. | AuditIfNotExists; Desabilitado | 6.0.0-pré-visualização |
LT-3: Ativar o registo para investigação de segurança
Para obter mais informações, consulte Log and Threat Detection: LT-3: Enable logging for security investigation.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| As aplicações do App Service devem ter os registos de recursos ativados | Auditar a ativação de logs de recursos na aplicação. Isso permite que você recrie trilhas de atividade para fins de investigação se ocorrer um incidente de segurança ou se sua rede for comprometida. | AuditIfNotExists; Desabilitado | 2.0.1 |
| A auditoria no SQL Server deve ser habilitada | A auditoria no SQL Server deve ser habilitada para controlar as atividades do banco de dados em todos os bancos de dados no servidor e salvá-las em um log de auditoria. | AuditIfNotExists; Desabilitado | 2.0.0 |
| Azure Front Door deve ter registos de recursos ativados | Habilite os logs de recursos para o Azure Front Door (mais WAF) e transmita para um espaço de trabalho do Log Analytics. Obtenha visibilidade detalhada do tráfego de entrada na Web e das ações tomadas para mitigar ataques. | AuditIfNotExists; Desabilitado | 1.0.0 |
| Os logs de diagnóstico nos recursos dos serviços de IA do Azure devem ser habilitados | Habilite logs para recursos de serviços de IA do Azure. Isso permite que você recrie trilhas de atividade para fins de investigação, quando ocorre um incidente de segurança ou sua rede é comprometida | AuditIfNotExists; Desabilitado | 1.0.0 |
| Os logs de recursos no Repositório Azure Data Lake devem ser habilitados | Ativação de auditoria de logs de recursos. Isso permite que você recrie trilhas de atividades para usar para fins de investigação; quando ocorre um incidente de segurança ou quando a sua rede está comprometida | AuditIfNotExists; Desabilitado | 5.0.0 |
| Os logs de recursos nos workspaces do Azure Databricks devem ser ativados | Os logs de recursos permitem a recriação de trilhas de atividade para uso para fins de investigação quando ocorre um incidente de segurança ou quando sua rede é comprometida. | AuditIfNotExists; Desabilitado | 1.0.1 |
| Os logs de recursos no Serviço Kubernetes do Azure devem ser habilitados | Os logs de recursos do Serviço Kubernetes do Azure podem ajudar a recriar trilhas de atividade ao investigar incidentes de segurança. Habilite-o para garantir que os logs existirão quando necessário | AuditIfNotExists; Desabilitado | 1.0.0 |
| Os logs de recursos nos Espaços de Trabalho do Azure Machine Learning devem ser ativados | Os logs de recursos permitem a recriação de trilhas de atividade para uso para fins de investigação quando ocorre um incidente de segurança ou quando sua rede é comprometida. | AuditIfNotExists; Desabilitado | 1.0.1 |
| Os logs de recursos no Azure Stream Analytics devem ser habilitados | Ativação de auditoria de logs de recursos. Isso permite que você recrie trilhas de atividades para usar para fins de investigação; quando ocorre um incidente de segurança ou quando a sua rede está comprometida | AuditIfNotExists; Desabilitado | 5.0.0 |
| Os registos de recursos nas contas de Batch devem ser ativados | Ativação de auditoria de logs de recursos. Isso permite que você recrie trilhas de atividades para usar para fins de investigação; quando ocorre um incidente de segurança ou quando a sua rede está comprometida | AuditIfNotExists; Desabilitado | 5.0.0 |
| Os logs de recursos no Data Lake Analytics devem ser habilitados | Ativação de auditoria de logs de recursos. Isso permite que você recrie trilhas de atividades para usar para fins de investigação; quando ocorre um incidente de segurança ou quando a sua rede está comprometida | AuditIfNotExists; Desabilitado | 5.0.0 |
| Os logs de recursos na Central de Eventos devem ser ativados | Ativação de auditoria de logs de recursos. Isso permite que você recrie trilhas de atividades para usar para fins de investigação; quando ocorre um incidente de segurança ou quando a sua rede está comprometida | AuditIfNotExists; Desabilitado | 5.0.0 |
| Os logs de recursos no Hub IoT devem ser habilitados | Ativação de auditoria de logs de recursos. Isso permite que você recrie trilhas de atividades para usar para fins de investigação; quando ocorre um incidente de segurança ou quando a sua rede está comprometida | AuditIfNotExists; Desabilitado | 3.1.0 |
| Os logs de recursos no Azure Key Vault devem ser ativados | Ativação de auditoria de logs de recursos. Isso permite que você recrie trilhas de atividade para usar para fins de investigação quando ocorrer um incidente de segurança ou quando sua rede estiver comprometida | AuditIfNotExists; Desabilitado | 5.0.0 |
| Os registos de recursos em Logic Apps devem ser ativados | Ativação de auditoria de logs de recursos. Isso permite que você recrie trilhas de atividades para usar para fins de investigação; quando ocorre um incidente de segurança ou quando a sua rede está comprometida | AuditIfNotExists; Desabilitado | 5.1.0 |
| Os logs de recursos nos serviços de Pesquisa devem ser ativados | Ativação de auditoria de logs de recursos. Isso permite que você recrie trilhas de atividades para usar para fins de investigação; quando ocorre um incidente de segurança ou quando a sua rede está comprometida | AuditIfNotExists; Desabilitado | 5.0.0 |
| Os logs de recursos no Service Bus devem ser habilitados | Ativação de auditoria de logs de recursos. Isso permite que você recrie trilhas de atividades para usar para fins de investigação; quando ocorre um incidente de segurança ou quando a sua rede está comprometida | AuditIfNotExists; Desabilitado | 5.0.0 |
LT-4: Habilitar o log de rede para investigação de segurança
Para obter mais informações, consulte Registro em log e deteção de ameaças: LT-4: habilitar o log de rede para investigação de segurança.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Os logs de fluxo devem ser configurados para cada grupo de segurança de rede | Auditoria de grupos de segurança de rede para verificar se os logs de fluxo estão configurados. A habilitação de logs de fluxo permite registrar informações sobre o tráfego IP que flui através do grupo de segurança de rede. Ele pode ser usado para otimizar fluxos de rede, monitorar a taxa de transferência, verificar a conformidade, detetar invasões e muito mais. | Auditoria; Desabilitado | 1.1.0 |
| [Preview]: O agente de coleta de dados de tráfego de rede deve ser instalado em máquinas virtuais Linux | A Central de Segurança usa o agente de dependência da Microsoft para coletar dados de tráfego de rede de suas máquinas virtuais do Azure para habilitar recursos avançados de proteção de rede, como visualização de tráfego no mapa de rede, recomendações de proteção de rede e ameaças de rede específicas. | AuditIfNotExists; Desabilitado | 1.0.2-Pré-visualização |
| [Pré-visualização]: O agente de recolha de dados de tráfego de rede deve ser instalado em máquinas virtuais Windows | A Central de Segurança usa o agente de dependência da Microsoft para coletar dados de tráfego de rede de suas máquinas virtuais do Azure para habilitar recursos avançados de proteção de rede, como visualização de tráfego no mapa de rede, recomendações de proteção de rede e ameaças de rede específicas. | AuditIfNotExists; Desabilitado | 1.0.2-Pré-visualização |
LT-5: Centralize o gerenciamento e a análise de logs de segurança
Para obter mais informações, consulte Registro em log e deteção de ameaças: LT-5: centralize o gerenciamento e a análise de logs de segurança.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| As consultas salvas no Azure Monitor devem ser salvas na conta de armazenamento do cliente para criptografia de logs | Vincule a conta de armazenamento ao espaço de trabalho do Log Analytics para proteger consultas salvas com criptografia de conta de armazenamento. As chaves gerenciadas pelo cliente geralmente são necessárias para atender à conformidade regulatória e para ter mais controle sobre o acesso às suas consultas salvas no Azure Monitor. Para obter mais detalhes sobre os itens acima, consulte Chave gerenciada pelo cliente para consultas salvas no Azure Monitor. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 1.1.0 |
| [Pré-visualização]: A extensão do Log Analytics deve ser instalada nas suas máquinas Linux Azure Arc | Esta política audita máquinas Linux Azure Arc se a extensão do Log Analytics não estiver instalada. | AuditIfNotExists; Desabilitado | 1.0.1-Pré-visualização |
| [Preview]: A extensão do Log Analytics deve ser instalada em suas máquinas Windows Azure Arc | Esta política audita máquinas Windows Azure Arc se a extensão do Log Analytics não estiver instalada. | AuditIfNotExists; Desabilitado | 1.0.1-Pré-visualização |
LT-6: Configurar a retenção de armazenamento de log
Para obter mais informações, consulte Registro em log e deteção de ameaças: LT-6: Configurar a retenção de armazenamento de log.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Os servidores SQL com auditoria para o destino da conta de armazenamento devem ser configurados com retenção de 90 dias ou superior | Para fins de investigação de incidentes, recomendamos definir a retenção de dados para a auditoria do SQL Server para o destino da conta de armazenamento para pelo menos 90 dias. Confirme se você está cumprindo as regras de retenção necessárias para as regiões em que está operando. Isso às vezes é necessário para a conformidade com as normas regulamentares. | AuditIfNotExists; Desabilitado | 3.0.0 |
NS-1: Estabelecer limites de segmentação de rede
Para obter mais informações, consulte Segurança de rede: NS-1: Estabelecer limites de segmentação de rede.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Todas as portas de rede devem ser restritas em grupos de segurança de rede associados à sua máquina virtual | A Central de Segurança do Azure identificou que algumas das regras de entrada dos seus grupos de segurança de rede são muito permissivas. As regras de entrada não devem permitir o acesso a partir de intervalos de «Qualquer» ou «Internet». Isso pode potencialmente permitir que os invasores direcionem seus recursos. | AuditIfNotExists; Desabilitado | 3.0.0 |
| As máquinas virtuais voltadas para a Internet devem ser protegidas com grupos de segurança de rede | Proteja suas máquinas virtuais contra ameaças potenciais restringindo o acesso a elas com grupos de segurança de rede (NSG). Saiba mais sobre como controlar o tráfego com NSGs na visão geral dos grupos de segurança de rede do Azure | AuditIfNotExists; Desabilitado | 3.0.0 |
| As máquinas virtuais não voltadas para a Internet devem ser protegidas com grupos de segurança de rede | Proteja suas máquinas virtuais não voltadas para a Internet contra ameaças potenciais restringindo o acesso com grupos de segurança de rede (NSG). Saiba mais sobre como controlar o tráfego com NSGs na visão geral dos grupos de segurança de rede do Azure | AuditIfNotExists; Desabilitado | 3.0.0 |
| As sub-redes devem estar associadas a um Grupo de Segurança de Rede | Proteja sua sub-rede contra ameaças potenciais restringindo o acesso a ela com um NSG (Network Security Group). Os NSGs contêm uma lista de regras de ACL (Lista de Controle de Acesso) que permitem ou negam tráfego de rede para sua sub-rede. | AuditIfNotExists; Desabilitado | 3.0.0 |
NS-2: Serviços de nuvem seguros com controles de rede
Para obter mais informações, consulte Segurança de rede: NS-2: Serviços de nuvem seguros com controles de rede.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Os serviços de gerenciamento de API devem usar uma rede virtual | A implantação da Rede Virtual do Azure fornece segurança aprimorada, isolamento e permite que você coloque seu serviço de Gerenciamento de API em uma rede roteável que não seja da Internet à qual você controla o acesso. Essas redes podem ser conectadas às suas redes locais usando várias tecnologias VPN, o que permite 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 apenas dentro da rede virtual. | Auditoria; Negar; Desabilitado | 1.0.2 |
| O Gerenciamento de API deve desabilitar o acesso de rede pública aos pontos de extremidade de configuração do serviço | Para melhorar a segurança dos serviços de Gerenciamento de API, restrinja a conectividade a pontos de extremidade de configuração de serviço, como API de gerenciamento de acesso direto, ponto de extremidade de gerenciamento de configuração Git ou ponto de extremidade de configuração de gateways auto-hospedados. | AuditIfNotExists; Desabilitado | 1.0.1 |
| A configuração do aplicativo deve desabilitar o acesso à rede pública | A desativação do acesso à rede pública melhora a segurança, garantindo que o recurso não seja exposto na Internet pública. Em vez disso, você pode limitar a exposição de seus recursos criando pontos de extremidade privados. Saiba mais em: Usar pontos de extremidade privados para a Configuração de Aplicativo do Azure. | Auditoria; Negar; Desabilitado | 1.0.0 |
| A Configuração do Aplicativo deve usar uma SKU que suporte link privado | Ao usar uma SKU com suporte, 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: Usar pontos de extremidade privados para a Configuração de Aplicativo do Azure. | Auditoria; Negar; Desabilitado | 1.0.0 |
| A configuração do aplicativo deve usar link privado | 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: Usar pontos de extremidade privados para a Configuração de Aplicativo do Azure. | AuditIfNotExists; Desabilitado | 1.0.2 |
| Os aplicativos do Ambiente do Serviço de Aplicativo não devem ser acessíveis pela Internet pública | Para garantir que os aplicativos implantados em um Ambiente do Serviço de Aplicativo não estejam acessíveis pela Internet pública, deve-se implantar o Ambiente do Serviço de Aplicativo com um endereço IP na rede virtual. Para definir o endereço IP como um IP de rede virtual, o Ambiente do Serviço de Aplicativo deve ser implantado com um balanceador de carga interno. | Auditoria; Negar; Desabilitado | 3.0.0 |
| Os slots de aplicativo do Serviço de Aplicativo devem desabilitar o acesso à rede pública | A desativação do acesso à rede pública melhora a segurança, garantindo que o Serviço de Aplicativo não seja exposto na Internet pública. A criação de pontos finais privados pode limitar a exposição de um App Service. Saiba mais em: Usar pontos de extremidade privados para aplicativos. | Auditoria; Deficientes; Negar | 1.0.0 |
| Os aplicativos do Serviço de Aplicativo devem desabilitar o acesso à rede pública | A desativação do acesso à rede pública melhora a segurança, garantindo que o Serviço de Aplicativo não seja exposto na Internet pública. A criação de pontos finais privados pode limitar a exposição de um App Service. Saiba mais em: Usar pontos de extremidade privados para aplicativos. | Auditoria; Deficientes; Negar | 1.1.0 |
| Os aplicativos do Serviço de Aplicativo devem usar uma SKU que ofereça suporte a link privado | Com SKUs suportados, 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. Ao mapear pontos de extremidade privados para aplicativos, você pode reduzir os riscos de vazamento de dados. Saiba mais sobre links privados em: Usar pontos de extremidade privados para aplicativos. | Auditoria; Negar; Desabilitado | 4.3.0 |
| Os aplicativos do Serviço de Aplicativo devem usar link privado | O Azure Private Link permite conectar suas redes virtuais 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. Ao mapear pontos de extremidade privados para o Serviço de Aplicações, pode reduzir os riscos de vazamento de dados. Saiba mais sobre links privados em: Usar pontos de extremidade privados para aplicativos. | AuditIfNotExists; Desabilitado | 1.0.1 |
| Os componentes do Application Insights devem bloquear a ingestão de logs e consultas de redes públicas | Melhore a segurança do Application Insights bloqueando a ingestão de logs e consultas de redes públicas. Somente redes com ligação privada poderão recolher e consultar logs deste componente. Saiba mais em Usar o Azure Private Link para conectar redes ao Azure Monitor. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 1.1.0 |
| Os intervalos de IP autorizados devem ser definidos nos Serviços Kubernetes | Restrinja o acesso à API de Gerenciamento de Serviços do Kubernetes concedendo acesso à API apenas a endereços IP em intervalos específicos. Recomenda-se limitar o acesso a intervalos de IP autorizados para garantir que apenas aplicativos de redes permitidas possam acessar o cluster. | Auditoria; Desabilitado | 2.0.1 |
| As contas de automação devem desativar o acesso à rede pública | A desativação do acesso à rede pública melhora a segurança, garantindo que o recurso não seja exposto na Internet pública. Em vez disso, você pode limitar a exposição dos recursos da sua conta de automação criando pontos de extremidade privados. Saiba mais em: Use o Azure Private Link para conectar redes com segurança à Automação do Azure. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O serviço Azure AI Search deve usar uma SKU que ofereça suporte ao link privado | Com SKUs suportadas do Azure AI Search, o Azure Private Link permite-lhe ligar a 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 o seu serviço de pesquisa, os riscos de vazamento de dados são reduzidos. Saiba mais em: Criar um ponto de extremidade privado para uma conexão segura. | Auditoria; Negar; Desabilitado | 1.0.1 |
| Os serviços Azure AI Search devem desativar o acesso à rede pública | A desativação do acesso à rede pública melhora a segurança, garantindo que seu serviço Azure AI Search não seja exposto na Internet pública. A criação de pontos de extremidade privados pode limitar a exposição do seu serviço de Pesquisa. Saiba mais em: Criar um ponto de extremidade privado para uma conexão segura. | Auditoria; Negar; Desabilitado | 1.0.1 |
| Os recursos dos Serviços de IA do Azure devem restringir o acesso à rede | Ao restringir o acesso à rede, você pode garantir que apenas as redes permitidas possam acessar o serviço. Isso pode ser alcançado configurando regras de rede para que apenas aplicativos de redes permitidas possam acessar o serviço Azure AI. | Auditoria; Negar; Desabilitado | 3.3.0 |
| Os recursos dos Serviços de IA do Azure devem usar o Azure Private Link | 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 reduz os riscos de fuga de dados ao lidar com a conectividade entre o consumidor e os serviços através da rede de backbone do Azure. Saiba mais sobre links privados em: O que é o Azure Private Link? | Auditoria; Desabilitado | 1.0.0 |
| A API do Azure para FHIR deve usar o link privado | A API do Azure para FHIR deve ter pelo menos uma conexão de ponto de extremidade privada aprovada. Os clientes em uma rede virtual podem acessar com segurança recursos que têm conexões de ponto de extremidade privadas por meio de links privados. Para obter mais informações, visite: Configurar Link Privado para Serviços de Dados de Integridade do Azure. | Auditoria; Desabilitado | 1.0.0 |
| Os escopos de link privado do Azure Arc devem ser configurados com um ponto de extremidade privado | O Azure Private Link permite conectar suas redes virtuais 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. Ao mapear pontos de extremidade privados para Escopos de Link Privado do Azure Arc, os riscos de vazamento de dados são reduzidos. Saiba mais sobre links privados em: Use o Azure Private Link para conectar servidores ao Azure Arc usando um ponto de extremidade privado. | Auditoria; Desabilitado | 1.0.0 |
| Os escopos de link privado do Azure Arc devem desabilitar o acesso à rede pública | A desativação do acesso à rede pública melhora a segurança, garantindo que os recursos do Azure Arc não possam se conectar por meio da Internet pública. A criação de pontos de extremidade privados pode limitar a exposição dos recursos do Azure Arc. Saiba mais em: Use o Azure Private Link para conectar servidores ao Azure Arc usando um ponto de extremidade privado. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os clusters kubernetes habilitados para Azure Arc devem ser configurados com um Escopo de Link Privado do Azure Arc | O Azure Private Link permite conectar suas redes virtuais 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. Ao mapear servidores habilitados para Azure Arc para um Escopo de Link Privado do Azure Arc configurado com um ponto de extremidade privado, os riscos de vazamento de dados são reduzidos. Saiba mais sobre links privados em: Use o Azure Private Link para conectar servidores ao Azure Arc usando um ponto de extremidade privado. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os servidores habilitados para Azure Arc devem ser configurados com um Escopo de Link Privado do Azure Arc | O Azure Private Link permite conectar suas redes virtuais 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. Ao mapear servidores habilitados para Azure Arc para um Escopo de Link Privado do Azure Arc configurado com um ponto de extremidade privado, os riscos de vazamento de dados são reduzidos. Saiba mais sobre links privados em: Use o Azure Private Link para conectar servidores ao Azure Arc usando um ponto de extremidade privado. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os provedores de atestado do Azure devem desabilitar o acesso à rede pública | Para melhorar a segurança do Serviço de Atestado do Azure, certifique-se de que ele não esteja exposto à Internet pública e só possa ser acessado a partir de um ponto de extremidade privado. Desative a propriedade de acesso à rede pública conforme descrito no aka.ms/azureattestation. Esta opção desativa o acesso de qualquer espaço de endereçamento 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. Isso reduz os riscos de vazamento de dados. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O Cache do Azure para Redis Enterprise deve usar link privado | Os pontos de extremidade privados permitem conectar sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. Ao mapear pontos de extremidade privados para suas instâncias do Cache do Azure para Redis Enterprise, os riscos de vazamento de dados são reduzidos. Saiba mais em: O que é o Cache Redis do Azure com o Azure Private Link?. | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Cache Redis do Azure deve desabilitar o acesso à rede pública | A desativação do acesso à rede pública melhora a segurança, garantindo que o Cache Redis do Azure não seja exposto na Internet pública. Em vez disso, você pode limitar a exposição do Cache Redis do Azure criando pontos de extremidade privados. Saiba mais em: O que é o Cache Redis do Azure com o Azure Private Link?. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O Cache Redis do Azure deve usar o link privado | Os pontos de extremidade privados permitem conectar sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. Ao mapear pontos de extremidade privados para seu Cache do Azure para instâncias Redis, os riscos de vazamento de dados são reduzidos. Saiba mais em: O que é o Cache Redis do Azure com o Azure Private Link?. | AuditIfNotExists; Desabilitado | 1.0.0 |
| As contas do Azure Cosmos DB devem ter regras de firewall | 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. | Auditoria; Negar; Desabilitado | 2.1.0 |
| O Azure Cosmos DB deve desabilitar o acesso à rede pública | A desativação do acesso à rede pública melhora a segurança, garantindo que sua conta do CosmosDB não seja exposta na Internet pública. A criação de endpoints privados pode limitar a exposição da sua conta do CosmosDB. Saiba mais em: Bloqueando o acesso à rede pública durante a criação da conta do Azure Cosmos DB. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O cluster do Azure Data Explorer deve usar link privado | 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. Ao mapear pontos de extremidade privados para seu cluster do Azure Data Explorer, os riscos de vazamento de dados são reduzidos. Saiba mais sobre links privados em: Pontos de extremidade privados para o Azure Data Explorer. | Auditoria; Desabilitado | 1.0.0 |
| O Azure Data Explorer deve usar uma SKU que ofereça suporte ao link privado | Com SKUs suportados, 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. Ao mapear pontos de extremidade privados para aplicativos, você pode reduzir os riscos de vazamento de dados. Saiba mais sobre links privados em: Usar pontos de extremidade privados para aplicativos. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O Azure Data Factory deve usar o link privado | 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. Ao mapear pontos de extremidade privados para o Azure Data Factory, os riscos de vazamento de dados são reduzidos. Saiba mais sobre links privados em: Azure Private Link for Azure Data Factory. | AuditIfNotExists; Desabilitado | 1.0.0 |
| Os Clusters do Azure Databricks devem desativar o IP público | A desativação do IP público de clusters no Azure Databricks Workspaces melhora a segurança, garantindo que os clusters não sejam expostos na Internet pública. Saiba mais em: Habilite a conectividade segura de cluster. | Auditoria; Negar; Desabilitado | 1.0.1 |
| Os Espaços de Trabalho do Azure Databricks devem estar em uma rede virtual | As Redes Virtuais do Azure fornecem segurança e isolamento aprimorados para seus Espaços de Trabalho do Azure Databricks, bem como sub-redes, políticas de controle de acesso e outros recursos para restringir ainda mais o acesso. Saiba mais em: Implantar o Azure Databricks em sua rede virtual do Azure (injeção de VNet). | Auditoria; Negar; Desabilitado | 1.0.2 |
| Os Espaços de Trabalho do Azure Databricks devem desativar o acesso à rede pública | A desativação do acesso à rede pública melhora a segurança, garantindo que o recurso não seja exposto na Internet pública. Em vez disso, você pode controlar a exposição de seus recursos criando pontos de extremidade privados. Saiba mais em: Conceitos de Link Privado do Azure. | Auditoria; Negar; Desabilitado | 1.0.1 |
| Azure Databricks Workspaces deve usar link privado | O Azure Private Link permite conectar suas redes virtuais 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. Ao mapear pontos de extremidade privados para espaços de trabalho do Azure Databricks, você pode reduzir os riscos de vazamento de dados. Saiba mais sobre links privados em: Configurar a conectividade privada de back-end para o Azure Databricks. | Auditoria; Desabilitado | 1.0.2 |
| Os espaços de trabalho do Azure Databricks devem ser SKU Premium que ofereça suporte a recursos como link privado, chave gerenciada pelo cliente para criptografia | Permita apenas o espaço de trabalho Databricks com Sku Premium que sua organização possa implantar para oferecer suporte a recursos como Private Link, chave gerenciada pelo cliente para criptografia. Saiba mais em: Configurar a conectividade privada de back-end para o Azure Databricks. | Auditoria; Negar; Desabilitado | 1.0.1 |
| A Atualização de Dispositivo do Azure para contas do Hub IoT deve usar link privado | 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. Ao mapear pontos de extremidade privados para contas do Hub IoT da Atualização de Dispositivo do Azure, os riscos de vazamento de dados são reduzidos. | AuditIfNotExists; Desabilitado | 1.0.0 |
| Os domínios da Grade de Eventos do Azure devem desabilitar o acesso à rede pública | A desativação do acesso à rede pública melhora a segurança, garantindo que o recurso não seja exposto na Internet pública. Em vez disso, você pode limitar a exposição de seus recursos criando pontos de extremidade privados. Saiba mais em: Configurar pontos de extremidade privados para tópicos ou domínios. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os domínios da Grade de Eventos do Azure devem usar link privado | 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. Ao mapear pontos de extremidade privados para seu domínio 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: Configurar pontos de extremidade privados para tópicos ou domínios. | Auditoria; Desabilitado | 1.0.2 |
| O broker MQTT do namespace da Grade de Eventos do Azure deve usar o link privado | 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. Ao mapear pontos de extremidade privados para seu namespace 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: Configurar pontos de extremidade privados para tópicos ou domínios. | Auditoria; Desabilitado | 1.0.0 |
| O agente de tópicos do namespace da Grade de Eventos do Azure deve usar o link privado | 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. Ao mapear pontos de extremidade privados para seu namespace 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: Configurar pontos de extremidade privados para tópicos ou domínios. | Auditoria; Desabilitado | 1.0.0 |
| Os namespaces da Grade de Eventos do Azure devem desabilitar o acesso à rede pública | A desativação do acesso à rede pública melhora a segurança, garantindo que o recurso não seja exposto na Internet pública. Em vez disso, você pode limitar a exposição de seus recursos criando pontos de extremidade privados. Saiba mais em: Configurar pontos de extremidade privados para tópicos ou domínios. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os tópicos da Grade de Eventos do Azure devem desabilitar o acesso à rede pública | A desativação do acesso à rede pública melhora a segurança, garantindo que o recurso não seja exposto na Internet pública. Em vez disso, você pode limitar a exposição de seus recursos criando pontos de extremidade privados. Saiba mais em: Configurar pontos de extremidade privados para tópicos ou domínios. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os tópicos da Grade de Eventos do Azure devem usar o link privado | 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. Ao mapear pontos de extremidade privados para o tópico da Grade de Eventos em vez de todo o serviço, você também estará protegido contra riscos de vazamento de dados. Saiba mais em: Configurar pontos de extremidade privados para tópicos ou domínios. | Auditoria; Desabilitado | 1.0.2 |
| O Azure File Sync deve usar o link privado | A criação de um ponto de extremidade privado para o recurso do Serviço de Sincronização de Armazenamento indicado permite que você aborde o recurso do Serviço de Sincronização de Armazenamento a partir do espaço de endereço IP privado da rede da sua organização, em vez de por meio do ponto de extremidade público acessível pela Internet. A criação de um ponto de extremidade privado por si só não desabilita o ponto de extremidade público. | AuditIfNotExists; Desabilitado | 1.0.0 |
| Os perfis do Azure Front Door devem usar a camada Premium que ofereça suporte a regras WAF gerenciadas e link privado | O Azure Front Door Premium suporta regras WAF geridas pelo Azure e ligação privada para origens do Azure suportadas. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Azure HDInsight deve usar link privado | O Azure Private Link permite conectar suas redes virtuais 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. Ao mapear pontos de extremidade privados para clusters do Azure HDInsight, você pode reduzir os riscos de vazamento de dados. Saiba mais sobre links privados em: Habilitar Link Privado em um cluster do Azure HDInsight. | AuditIfNotExists; Desabilitado | 1.0.0 |
| O serviço de desidentificação dos Serviços de Dados de Saúde do Azure deve desativar o acesso à rede pública | A desativação do acesso à rede pública melhora a segurança, garantindo que o recurso não seja exposto na Internet pública. Em vez disso, você pode limitar a exposição de seus recursos criando pontos de extremidade privados. | Auditoria; Desabilitado | 1.0.0 |
| O serviço de desidentificação dos Serviços de Dados de Saúde do Azure deve usar link privado | O serviço de desidentificação dos Serviços de Dados de Saúde do Azure deve ter pelo menos uma conexão de ponto de extremidade privada aprovada. Os clientes em uma rede virtual podem acessar com segurança recursos que têm conexões de ponto de extremidade privadas por meio de links privados. | Auditoria; Desabilitado | 1.0.0 |
| O espaço de trabalho dos Serviços de Dados de Integridade do Azure deve usar link privado | O espaço de trabalho Serviços de Dados de Integridade deve ter pelo menos uma conexão de ponto de extremidade privada aprovada. Os clientes em uma rede virtual podem acessar com segurança recursos que têm conexões de ponto de extremidade privadas por meio de links privados. Para obter mais informações, visite: Configurar Link Privado para Serviços de Dados de Integridade do Azure. | Auditoria; Desabilitado | 1.0.0 |
| O Azure Key Vault deve desativar o acesso à rede pública | Desative o acesso à rede pública para o cofre da chave para que ele não seja acessível pela Internet pública. Isso pode reduzir os riscos de vazamento de dados. Saiba mais em: Integrar o Cofre da Chave com o Azure Private Link. | Auditoria; Negar; Desabilitado | 1.1.0 |
| O Azure Key Vault deve ter firewall habilitado ou acesso à rede pública desabilitado | Habilite o firewall do cofre de chaves para que o cofre de chaves não seja acessível por padrão a nenhum IPs público ou desabilite o acesso à rede pública do cofre de chaves para que ele não esteja acessível pela Internet pública. Opcionalmente, você pode configurar intervalos de IP específicos para limitar o acesso a essas redes. Saiba mais em: Segurança de rede para o Azure Key Vault e Integrar o Key Vault com o Azure Private Link | Auditoria; Negar; Desabilitado | 3.3.0 |
| Os Cofres de Chaves do Azure devem usar o link privado | O Azure Private Link permite conectar suas redes virtuais 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. Ao mapear pontos de extremidade privados para o cofre de chaves, você pode reduzir os riscos de vazamento de dados. Saiba mais sobre links privados em: Integrar o Cofre da Chave com o Azure Private Link. | Auditoria; Negar; Desabilitado | 1.2.1 |
| Os Cálculos do Azure Machine Learning devem estar em uma rede virtual | As Redes Virtuais do Azure fornecem segurança e isolamento aprimorados para seus Clusters e Instâncias de Computação do Azure Machine Learning, bem como sub-redes, políticas de controle de acesso e outros recursos para restringir ainda mais o acesso. Quando uma computação é configurada com uma rede virtual, ela não é endereçável publicamente e só pode ser acessada de máquinas virtuais e aplicativos dentro da rede virtual. | Auditoria; Desabilitado | 1.0.1 |
| Os Espaços de Trabalho do Azure Machine Learning devem desativar o acesso à rede pública | A desativação do acesso à rede pública melhora a segurança, garantindo que os espaços de trabalho de Machine Learning não sejam expostos na Internet pública. Pode-se controlar a exposição dos seus espaços de trabalho criando, em vez disso, pontos de extremidade privados. Saiba mais em: Configurar um ponto de extremidade privado para um espaço de trabalho do Azure Machine Learning. | Auditoria; Negar; Desabilitado | 2.0.1 |
| O Azure Machine Learning e o Ai Studio devem usar o modo Permitir Somente Vnet Gerenciado de Saída Aprovado | O isolamento de VNet gerenciado simplifica e automatiza sua configuração de isolamento de rede com uma VNet gerenciada do Azure Machine Learning interna no nível do espaço de trabalho. A VNet gerenciada protege seus recursos gerenciados do Azure Machine Learning, como instâncias de computação, clusters de computação, computação sem servidor e pontos de extremidade online gerenciados. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os espaços de trabalho do Azure Machine Learning devem usar link privado | 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. Ao mapear pontos de extremidade privados para espaços de trabalho do Azure Machine Learning, os riscos de vazamento de dados são reduzidos. Saiba mais sobre links privados em: Configurar um ponto de extremidade privado para um espaço de trabalho do Azure Machine Learning. | Auditoria; Desabilitado | 1.0.0 |
| Os espaços de trabalho do Azure Managed Grafana devem desativar o acesso à rede pública | A desativação do acesso à rede pública melhora a segurança, garantindo que seu espaço de trabalho do Azure Managed Grafana não seja exposto na Internet pública. A criação de pontos de extremidade privados pode limitar a exposição de seus espaços de trabalho. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os espaços de trabalho do Azure Managed Grafana devem usar link privado | O Azure Private Link permite conectar suas redes virtuais 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. Ao mapear endpoints privados para o Managed Grafana, você pode reduzir os riscos de vazamento de dados. | Auditoria; Desabilitado | 1.0.1 |
| O Escopo de Link Privado do Azure Monitor deve bloquear o acesso a recursos de link não privados | O Azure Private Link permite conectar suas redes virtuais aos recursos do Azure por meio de um ponto de extremidade privado a um escopo AMPLS (Azure Monitor Private Link). Os modos de Acesso de Link Privado são definidos em seu AMPLS para controlar se as solicitações de ingestão e consulta de suas redes podem alcançar todos os recursos ou apenas recursos de Link Privado (para evitar a exfiltração de dados). Saiba mais sobre links privados em: Modos de acesso do Link Privado do Azure (somente privado vs. aberto). | Auditoria; Negar; Desabilitado | 1.0.0 |
| O Escopo de Link Privado do Azure Monitor deve usar o link privado | O Azure Private Link permite conectar suas redes virtuais 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. Ao mapear pontos de extremidade privados para o Escopo de Links Privados do Azure Monitor, você pode reduzir os riscos de vazamento de dados. Saiba mais sobre links privados em: Use o Azure Private Link para conectar redes ao Azure Monitor. | AuditIfNotExists; Desabilitado | 1.0.0 |
| As contas do Azure Purview devem usar o link privado | 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 suas contas do Azure Purview em vez de todo o serviço, você também estará protegido contra riscos de vazamento de dados. Saiba mais em: Use pontos de extremidade privados no portal de governança clássico do Microsoft Purview. | Auditoria; Desabilitado | 1.0.0 |
| As Instâncias Gerenciadas SQL do Azure devem desabilitar o acesso à rede pública | 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. Para saber mais sobre o acesso à rede pública, visite Configurar ponto de extremidade público. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os namespaces do Barramento de Serviço do Azure devem usar link privado | 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. Ao mapear pontos de extremidade privados para namespaces do Service Bus, os riscos de vazamento de dados são reduzidos. Saiba mais em: Permitir acesso a namespaces do Barramento de Serviço do Azure por meio de pontos de extremidade privados. | AuditIfNotExists; Desabilitado | 1.0.0 |
| O Serviço Azure SignalR deve desativar o acesso à rede pública | Para melhorar a segurança do recurso do Serviço SignalR do Azure, certifique-se de que ele não esteja exposto à Internet pública e só possa ser acessado a partir de um ponto de extremidade privado. Desative a propriedade de acesso à rede pública conforme descrito em Configurar controle de acesso à rede. Esta opção desativa o acesso de qualquer espaço de endereçamento 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. Isso reduz os riscos de vazamento de dados. | Auditoria; Negar; Desabilitado | 1.2.0 |
| O Serviço Azure SignalR deve usar uma SKU habilitada para Link Privado | 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, o que protege seus recursos contra riscos de vazamento de dados públicos. A política limita você a SKUs habilitadas para Link Privado para o Serviço Azure SignalR. Saiba mais sobre o link privado em: Usar pontos de extremidade privados. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O Serviço Azure SignalR deve usar link privado | 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 seu recurso do Serviço Azure SignalR em vez de todo o serviço, você reduzirá os riscos de vazamento de dados. Saiba mais sobre links privados em: Usar pontos de extremidade privados. | Auditoria; Desabilitado | 1.0.0 |
| Azure Spring Cloud deve usar injeção de rede | 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. | Auditoria; Deficientes; Negar | 1.2.0 |
| Os espaços de trabalho do Azure Synapse devem desabilitar o acesso à rede pública | A desativação do acesso à rede pública melhora a segurança, garantindo que o espaço de trabalho Synapse não seja exposto na Internet pública. A criação de pontos de extremidade privados pode limitar a exposição de seus espaços de trabalho Synapse. Saiba mais em: Configurações de conectividade do Azure Synapse Analytics. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os espaços de trabalho do Azure Synapse devem usar link privado | 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. Ao mapear pontos de extremidade privados para o espaço de trabalho do Azure Synapse, os riscos de vazamento de dados são reduzidos. Saiba mais sobre links privados em: Conecte-se ao seu espaço de trabalho do Azure Synapse usando links privados. | Auditoria; Desabilitado | 1.0.1 |
| Os grupos de hosts da Área de Trabalho Virtual do Azure devem desabilitar o acesso à rede pública | A desativação do acesso à rede pública melhora a segurança e mantém seus dados seguros, garantindo que o acesso ao serviço de Área de Trabalho Virtual do Azure não seja exposto à Internet pública. Saiba mais em: Configurar Link Privado com a Área de Trabalho Virtual do Azure. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os grupos de hosts da Área de Trabalho Virtual do Azure devem desabilitar o acesso à rede pública somente em hosts de sessão | Desabilitar o acesso à rede pública para seus hosts de sessão do hostpool da Área de Trabalho Virtual do Azure, mas permitir o acesso público para usuários finais, melhora a segurança, limitando a exposição à Internet pública. Saiba mais em: Configurar Link Privado com a Área de Trabalho Virtual do Azure. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O serviço de Área de Trabalho Virtual do Azure deve usar link privado | Usar o Azure Private Link com seus recursos da Área de Trabalho Virtual do Azure pode melhorar a segurança e manter seus dados seguros. Saiba mais sobre links privados em: Configurar Link Privado com a Área de Trabalho Virtual do Azure. | Auditoria; Desabilitado | 1.0.0 |
| Os espaços de trabalho da Área de Trabalho Virtual do Azure devem desabilitar o acesso à rede pública | A desativação do acesso à rede pública para seu recurso de espaço de trabalho da Área de Trabalho Virtual do Azure impede que o feed seja acessível pela Internet pública. Permitir apenas o acesso à rede privada melhora a segurança e mantém os seus dados seguros. Saiba mais em: Configurar Link Privado com a Área de Trabalho Virtual do Azure. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O Serviço Azure Web PubSub deve desativar o acesso à rede pública | A desativação do acesso à rede pública melhora a segurança, garantindo que o serviço Azure Web PubSub não seja exposto na Internet pública. A criação de pontos de extremidade privados pode limitar a exposição do serviço Azure Web PubSub. Saiba mais em: Controle de acesso à rede Azure Web PubSub. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O Serviço Azure Web PubSub deve usar uma SKU que ofereça suporte ao link privado | Com a SKU suportada, 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. Ao mapear pontos de extremidade privados para o serviço Azure Web PubSub, você pode reduzir os riscos de vazamento de dados. Saiba mais sobre links privados em: Ponto de extremidade privado do serviço Azure Web PubSub. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O Serviço Azure Web PubSub deve usar o link privado | O Azure Private Link permite conectar suas redes virtuais 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 seu Serviço Azure Web PubSub, você pode reduzir os riscos de vazamento de dados. Saiba mais sobre links privados em: Ponto de extremidade privado do serviço Azure Web PubSub. | Auditoria; Desabilitado | 1.0.0 |
| O Serviço de Bot deve ter o acesso à rede pública desativado | Os bots devem ser definidos para o modo 'apenas isolado'. Essa configuração configura os canais do Serviço de Bot que exigem que o tráfego na Internet pública seja desativado. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os recursos do BotService devem usar link privado | 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. Ao mapear endpoints privados para seu recurso BotService, os riscos de vazamento de dados são reduzidos. | Auditoria; Desabilitado | 1.0.0 |
| O ambiente de aplicativos de contêiner deve desabilitar o acesso à rede pública | Desative o acesso à rede pública para melhorar a segurança expondo o ambiente de Aplicativos de Contêiner por meio de um balanceador de carga interno. Isso elimina a necessidade de um endereço IP público e impede o acesso à Internet a todos os aplicativos de contêiner no ambiente. | Auditoria; Negar; Desabilitado | 1.1.0 |
| Os registros de contêiner devem ter SKUs que ofereçam suporte a Links Privados | 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 registros de contêiner em vez de todo o serviço, os riscos de vazamento de dados são reduzidos. Saiba mais em: Configurar ponto de extremidade privado com link privado para ACR. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os registos de contentores não devem permitir o acesso irrestrito à rede | Por padrão, os registros de contêiner do Azure aceitam conexões pela Internet de hosts em qualquer rede. Para proteger os seus registos de potenciais ameaças, permita o acesso apenas a partir de terminais privados específicos, endereços IP públicos ou intervalos de endereços. Se o seu registro não tiver regras de rede configuradas, ele aparecerá nos recursos não íntegros. Saiba mais sobre as regras de rede do Registro de Contêiner aqui: Configurar Ponto de Extremidade Privado com Link Privado para ACR, Configurar o Acesso ao Registro Público no Azure e Restringir o Acesso ao Registro de Contêiner do Azure Usando Pontos de Extremidade de Serviço. | Auditoria; Negar; Desabilitado | 2.0.0 |
| Os registos de contentores devem utilizar a ligação privada | 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 registros de contêiner em vez de todo o serviço, você também estará protegido contra riscos de vazamento de dados. Saiba mais em: Configurar ponto de extremidade privado com link privado para ACR. | Auditoria; Desabilitado | 1.0.1 |
| As contas do CosmosDB devem usar link privado | 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. Ao mapear endpoints privados para sua conta do CosmosDB, os riscos de vazamento de dados são reduzidos. Saiba mais sobre links privados em: Configurar o Link Privado do Azure para uma conta do Azure Cosmos DB. | Auditoria; Desabilitado | 1.0.0 |
| Os recursos de acesso ao disco devem usar link privado | 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. Ao mapear pontos de extremidade privados para diskAccesses, os riscos de vazamento de dados são reduzidos. Saiba mais sobre links privados em: Restringir o acesso de importação/exportação a discos gerenciados. | AuditIfNotExists; Desabilitado | 1.0.0 |
| O ElasticSan deve desativar o acesso à rede pública | Desative o acesso à rede pública do seu ElasticSan para que ele não seja acessível pela Internet pública. Isso pode reduzir os riscos de vazamento de dados. | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os namespaces do Hub de Eventos devem desabilitar o acesso à rede pública | O Hub de Eventos do Azure deve ter o acesso à rede pública desabilitado. A desativação do acesso à rede pública melhora a segurança, garantindo que o recurso não seja exposto na Internet pública. Em vez disso, você pode limitar a exposição de seus recursos criando pontos de extremidade privados. Saiba mais em: Permitir acesso a namespaces de Hubs de Eventos do Azure por meio de pontos de extremidade privados | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os namespaces do Hub de Eventos devem usar link privado | 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. Ao mapear pontos de extremidade privados para namespaces do Hub de Eventos, os riscos de vazamento de dados são reduzidos. Saiba mais em: Permitir acesso aos namespaces dos Hubs de Eventos do Azure por meio de pontos de extremidade privados. | AuditIfNotExists; Desabilitado | 1.0.0 |
| Os slots de aplicativos de função devem desabilitar o acesso à rede pública | A desativação do acesso à rede pública melhora a segurança, garantindo que o aplicativo Função não seja exposto na Internet pública. A criação de endereços de rede privados pode limitar a exposição de uma aplicação de funções. Saiba mais em: Usar pontos de extremidade privados para aplicativos. | Auditoria; Deficientes; Negar | 1.1.0 |
| Os aplicativos de função devem desativar o acesso à rede pública | A desativação do acesso à rede pública melhora a segurança, garantindo que o aplicativo Função não seja exposto na Internet pública. A criação de endereços de rede privados pode limitar a exposição de uma aplicação de funções. Saiba mais em: Usar pontos de extremidade privados para aplicativos. | Auditoria; Deficientes; Negar | 1.1.0 |
| IoT Central deve usar link privado | 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 seu aplicativo IoT Central em vez de todo o serviço, você reduzirá os riscos de vazamento de dados. Saiba mais sobre links privados em: Segurança de rede usando pontos de extremidade privados no IoT Central. | Auditoria; Negar; Desabilitado | 1.0.0 |
| As instâncias de serviço de provisionamento de dispositivos do Hub IoT devem desabilitar o acesso à rede pública | A desativação do acesso à rede pública melhora a segurança, garantindo que a instância do serviço de provisionamento de dispositivos do Hub IoT não seja exposta na Internet pública. A criação de pontos de extremidade privados pode limitar a exposição das instâncias de provisionamento de dispositivos do Hub IoT. Saiba mais em: Conexões de rede virtual para DPS. | Auditoria; Negar; Desabilitado | 1.0.0 |
| As instâncias de serviço de provisionamento de dispositivos do Hub IoT devem usar link privado | 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. Ao mapear pontos de extremidade privados para o serviço de provisionamento de dispositivos do Hub IoT, os riscos de vazamento de dados são reduzidos. Saiba mais sobre links privados em: Conexões de rede virtual para DPS. | Auditoria; Desabilitado | 1.0.0 |
| Os espaços de trabalho do Log Analytics devem bloquear a ingestão e consulta de logs de redes públicas | Melhore a segurança do espaço de trabalho bloqueando a ingestão de logs e consultas de redes públicas. Somente redes conectadas por ligação privada poderão ingerir e consultar logs neste espaço de trabalho. Saiba mais em Usar o Azure Private Link para conectar redes ao Azure Monitor. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 1.1.0 |
| Os discos gerenciados devem desabilitar o acesso à rede pública | A desativação do acesso à rede pública melhora a segurança, garantindo que um disco gerenciado não seja exposto na Internet pública. A criação de pontos de extremidade privados pode limitar a exposição de discos gerenciados. Saiba mais em: Restringir o acesso de importação/exportação a discos gerenciados. | Auditoria; Negar; Desabilitado | 2.1.0 |
| As conexões de ponto de extremidade privado no Banco de Dados SQL do Azure devem ser habilitadas | As conexões de ponto de extremidade privado impõem uma comunicação segura habilitando a conectividade privada com o Banco de Dados SQL do Azure. | Auditoria; Desabilitado | 1.1.0 |
| Ponto de extremidade privado deve ser habilitado para servidores MariaDB | As conexões de ponto de extremidade privado impõem uma 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. | AuditIfNotExists; Desabilitado | 1.0.2 |
| Ponto de extremidade privado deve ser habilitado para servidores MySQL | 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. | AuditIfNotExists; Desabilitado | 1.0.2 |
| Ponto de extremidade privado deve ser habilitado para servidores PostgreSQL | As conexões de ponto de extremidade privado impõem uma 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. | AuditIfNotExists; Desabilitado | 1.0.2 |
| O acesso à rede pública para contas do Azure Device Update for IoT Hub deve ser desabilitado | A desativação da propriedade de acesso à rede pública melhora a segurança, garantindo que suas contas da Atualização de Dispositivo do Azure para o Hub IoT só possam ser acessadas a partir de um ponto de extremidade privado. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O acesso à rede pública no Azure Data Explorer deve ser desabilitado | A desativação da propriedade de acesso à rede pública melhora a segurança, garantindo que o Azure Data Explorer só possa ser acessado a partir 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. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O acesso à rede pública no Azure Data Factory deve ser desabilitado | A desativação da propriedade de acesso à rede pública melhora a segurança, garantindo que seu Azure Data Factory só possa ser acessado a partir de um ponto de extremidade privado. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O acesso à rede pública no Hub IoT do Azure deve ser desabilitado | A desativação da propriedade de acesso à rede pública melhora a segurança, garantindo que seu Hub IoT do Azure só possa ser acessado a partir de um ponto de extremidade privado. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O acesso à rede pública no Banco de Dados SQL do Azure deve ser desabilitado | A desativação da propriedade de acesso à rede pública melhora a segurança, garantindo que seu Banco de Dados SQL do Azure só possa ser acessado a partir 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. | Auditoria; Negar; Desabilitado | 1.1.0 |
| O acesso à rede pública deve ser desabilitado para o Azure File Sync | A desativação do ponto de extremidade público permite restringir o acesso ao recurso do Serviço de Sincronização de Armazenamento a solicitações destinadas a pontos de extremidade privados aprovados na rede da sua organização. Não há nada inerentemente inseguro em permitir solicitações para o ponto de extremidade público, no entanto, você pode desativá-lo para atender aos requisitos de política regulamentar, legal ou organizacional. Você pode desabilitar o ponto de extremidade público para um Serviço de Sincronização de Armazenamento definindo incomingTrafficPolicy do recurso como AllowVirtualNetworksOnly. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O acesso à rede pública deve ser desativado para contas em lote | A desativação do acesso à rede pública em uma conta Batch melhora a segurança, garantindo que sua conta Batch só possa ser acessada a partir de um ponto de extremidade privado. Saiba mais sobre como desativar o acesso à rede pública em Usar pontos de extremidade privados com contas do Lote do Azure. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O acesso à rede pública deve ser desabilitado para registros de contêiner | A desativação do acesso à rede pública melhora a segurança, garantindo que os registros de contêiner não sejam expostos na Internet pública. A criação de pontos de extremidade privados pode limitar a exposição dos recursos do Registro de contêiner. Saiba mais em: Configurar o Acesso ao Registro Público no Azure e Configurar o Ponto de Extremidade Privado com Link Privado para ACR. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O acesso à rede pública deve ser desativado para o IoT Central | Para melhorar a segurança do IoT Central, certifique-se de que ele não esteja exposto à internet pública e só possa ser acessado a partir de um ponto de extremidade privado. Desabilite a propriedade de acesso à rede pública conforme descrito em Criar um ponto de extremidade privado para o Azure IoT Central. Esta opção desativa o acesso de qualquer espaço de endereçamento 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. Isso reduz os riscos de vazamento de dados. | Auditoria; Negar; Desabilitado | 1.0.0 |
| O acesso à rede pública deve ser desativado para servidores MariaDB | 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 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. | Auditoria; Negar; Desabilitado | 2.0.0 |
| O acesso à rede pública deve ser desativado para servidores MariaDB | 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 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. | Auditoria; Negar; Desabilitado | 2.0.0 |
| O acesso à rede pública deve ser desativado para servidores flexíveis MySQL | A desativação da propriedade de acesso à rede pública melhora a segurança, garantindo que seus servidores flexíveis do Banco de Dados do Azure para MySQL só possam ser acessados a partir de um ponto de extremidade privado. Essa configuração desabilita estritamente o acesso de qualquer espaço de endereçamento 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. | Auditoria; Negar; Desabilitado | 2.3.0 |
| O acesso à rede pública deve ser desativado para servidores MySQL | 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. | Auditoria; Negar; Desabilitado | 2.0.0 |
| O acesso à rede pública deve ser desativado para servidores flexíveis PostgreSQL | A desativação da propriedade de acesso à rede pública melhora a segurança, garantindo que seus servidores flexíveis do Banco de Dados do Azure para PostgreSQL só possam ser acessados 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. | Auditoria; Negar; Desabilitado | 3.1.0 |
| O acesso à rede pública deve ser desabilitado para servidores PostgreSQL | Desabilite 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. | Auditoria; Negar; Desabilitado | 2.0.1 |
| Os namespaces do Service Bus devem desabilitar o acesso à rede pública | O Barramento de Serviço do Azure deve ter o acesso à rede pública desabilitado. A desativação do acesso à rede pública melhora a segurança, garantindo que o recurso não seja exposto na Internet pública. Em vez disso, você pode limitar a exposição de seus recursos criando pontos de extremidade privados. Saiba mais em: Permitir acesso a namespaces do Barramento de Serviço do Azure por meio de pontos de extremidade privados | Auditoria; Negar; Desabilitado | 1.1.0 |
| O acesso público da conta de armazenamento não deve ser permitido | O acesso público de leitura anônimo a contêineres e blobs no Armazenamento do Azure é uma maneira conveniente de compartilhar dados, mas pode apresentar riscos de segurança. Para evitar violações de dados causadas por acesso anônimo indesejado, a Microsoft recomenda impedir o acesso público a uma conta de armazenamento, a menos que seu cenário exija. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 3.1.1 |
| As contas de armazenamento devem desativar o acesso à rede pública | Para melhorar a segurança das Contas de Armazenamento, certifique-se de que elas não estejam expostas à Internet pública e só possam ser acessadas a partir de um ponto de extremidade privado. Desative a propriedade de acesso à rede pública conforme descrito em Acesso à rede pública da conta de armazenamento. Esta opção desativa o acesso de qualquer espaço de endereçamento 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. Isso reduz os riscos de vazamento de dados. | Auditoria; Negar; Desabilitado | 1.0.1 |
| As contas de armazenamento devem restringir o acesso à rede | O acesso à rede para contas de armazenamento deve ser restrito. Configure regras de rede para que apenas aplicativos de redes permitidas possam acessar a conta de armazenamento. Para permitir conexões de clientes específicos da Internet ou locais, o acesso pode ser concedido ao tráfego de redes virtuais específicas do Azure ou a intervalos de endereços IP da Internet pública | Auditoria; Negar; Desabilitado | 1.1.1 |
| As contas de armazenamento devem restringir o acesso à rede usando regras de rede virtual | Proteja suas contas de armazenamento contra ameaças potenciais usando regras de rede virtual como um método preferencial em vez da filtragem baseada em IP. A desativação da filtragem baseada em IP impede que IPs públicos acessem suas contas de armazenamento. | Auditoria; Negar; Desabilitado | 1.0.1 |
| As contas de armazenamento devem restringir o acesso à rede usando regras de rede virtual (excluindo contas de armazenamento criadas pelo Databricks) | Proteja suas contas de armazenamento contra ameaças potenciais usando regras de rede virtual como um método preferencial em vez da filtragem baseada em IP. A desativação da filtragem baseada em IP impede que IPs públicos acessem suas contas de armazenamento. | Auditoria; Negar; Desabilitado | 1.0.0 |
| As contas de armazenamento devem usar link privado | 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. Ao mapear endpoints privados para sua conta de armazenamento, os riscos de vazamento de dados são reduzidos. Saiba mais sobre links privados em - O que é o Azure Private Link? | AuditIfNotExists; Desabilitado | 2.0.0 |
| As contas de armazenamento devem usar link privado (excluindo contas de armazenamento criadas pelo Databricks) | 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. Ao mapear endpoints privados para sua conta de armazenamento, os riscos de vazamento de dados são reduzidos. Saiba mais sobre links privados em - O que é o Azure Private Link? | AuditIfNotExists; Desabilitado | 1.0.0 |
| Os modelos do Construtor de Imagens de VM devem usar link privado | 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. Ao mapear pontos de extremidade privados para seus recursos de criação do VM Image Builder, os riscos de vazamento de dados são reduzidos. Saiba mais sobre links privados em: Opções de rede do Construtor de Imagens de VM do Azure - Implantar usando uma VNET existente. | Auditoria; Deficientes; Negar | 1.1.0 |
| [Pré-visualização]: Azure Key Vault Managed HSM deve desativar o acesso à rede pública | Desative o acesso à rede pública para o HSM gerenciado do Azure Key Vault para que ele não esteja acessível pela Internet pública. Isso pode reduzir os riscos de vazamento de dados. Saiba mais em: Permitir que serviços confiáveis acessem o HSM gerenciado. | Auditoria; Negar; Desabilitado | 1.0.0-pré-visualização |
| [Pré-visualização]: Azure Key Vault Managed HSM deve utilizar ligação privada | O link privado fornece uma maneira de conectar o Azure Key Vault Managed HSM aos seus recursos do Azure sem enviar tráfego pela Internet pública. O link privado fornece proteção de defesa em profundidade contra a exfiltração de dados. Saiba mais em: Integrar HSM gerenciado com o Azure Private Link | Auditoria; Desabilitado | 1.0.0-pré-visualização |
| [Pré-visualizar]: Os cofres dos Serviços de Recuperação do Azure devem usar ligação privada para backup | 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. Ao mapear pontos de extremidade privados para os cofres dos Serviços de Recuperação do Azure, os riscos de vazamento de dados são reduzidos. Saiba mais sobre links privados em: Criar e usar pontos de extremidade privados para o Backup do Azure. | Auditoria; Desabilitado | 2.0.0-pré-visualização |
| [Pré-visualizar]: Cofres dos Serviços de Recuperação devem usar uma ligação privada | 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. Ao mapear pontos de extremidade privados para os cofres dos Serviços de Recuperação do Azure, os riscos de vazamento de dados são reduzidos. Saiba mais sobre links privados para o Azure Site Recovery em: Habilitar replicação para máquinas locais com pontos de extremidade privados e Habilitar replicação para pontos de extremidade privados no Azure Site Recovery. | Auditoria; Desabilitado | 1.0.0-pré-visualização |
NS-3: Implante o firewall na borda da rede corporativa
Para obter mais informações, consulte Segurança de rede: NS-3: implantar firewall na borda da rede corporativa.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| O encaminhamento de IP em sua máquina virtual deve ser desabilitado | Habilitar o encaminhamento de IP na NIC de uma máquina virtual permite que a máquina receba tráfego endereçado a outros destinos. O encaminhamento de IP raramente é necessário (por exemplo, ao usar a VM como um dispositivo virtual de rede) e, portanto, isso deve ser revisado pela equipe de segurança de rede. | AuditIfNotExists; Desabilitado | 3.0.0 |
| As portas de gerenciamento de máquinas virtuais devem ser protegidas com controle de acesso à rede just-in-time | O possível acesso à rede Just In Time (JIT) será monitorado pela Central de Segurança do Azure como recomendações | AuditIfNotExists; Desabilitado | 3.0.0 |
| As portas de gerenciamento devem ser fechadas em suas máquinas virtuais | As portas de gerenciamento remoto abertas estão expondo sua VM a um alto nível de risco de ataques baseados na Internet. Esses ataques tentam obter credenciais de força bruta para obter acesso de administrador à máquina. | AuditIfNotExists; Desabilitado | 3.0.0 |
| [Pré-visualização]: Todo o tráfego da Internet deve ser encaminhado através da Firewall do Azure implementada | A Central de Segurança do Azure identificou que algumas de suas sub-redes não estão protegidas com um firewall de próxima geração. Proteja suas sub-redes contra ameaças potenciais restringindo o acesso a elas com o Firewall do Azure ou um firewall de próxima geração com suporte | AuditIfNotExists; Desabilitado | 3.0.0-Pré-visualização |
NS-5: Implantar a proteção DDOS
Para obter mais informações, consulte Segurança de rede: NS-5: implantar proteção DDOS.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| A Proteção contra DDoS do Azure deve ser habilitada | A proteção contra DDoS deve ser habilitada para todas as redes virtuais com uma sub-rede que faça parte de um gateway de aplicativo com um IP público. | AuditIfNotExists; Desabilitado | 3.0.1 |
| As redes virtuais devem ser protegidas pela Proteção contra DDoS do Azure | Proteja as suas redes virtuais contra ataques volumétricos e de protocolo com a Proteção contra DDoS do Azure. Para obter mais informações, visite Visão geral da proteção contra DDoS do Azure. | Modificar; Auditoria; Desabilitado | 1.0.1 |
NS-6: Implante o firewall de aplicativos Web
Para obter mais informações, consulte Segurança de rede: NS-6: Implantar firewall de aplicativos Web.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| O Firewall de Aplicativo Web do Azure deve ser habilitado para pontos de entrada do Azure Front Door | 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. | Auditoria; Negar; Desabilitado | 1.0.2 |
| O Web Application Firewall (WAF) deve ser habilitado para o Application Gateway | 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. | Auditoria; Negar; Desabilitado | 2.0.0 |
NS-8: Detetar e desabilitar serviços e protocolos inseguros
Para obter mais informações, consulte Segurança de rede: NS-8: detetar e desabilitar serviços e protocolos inseguros.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Os aplicativos do Serviço de Aplicativo devem usar a versão TLS mais recente | Periodicamente, versões mais recentes são lançadas para TLS devido a falhas de segurança, incluem funcionalidades adicionais e aumentam a velocidade. Atualize para a versão TLS mais recente para aplicativos do Serviço de Aplicativo para aproveitar as correções de segurança, se houver, e/ou novas funcionalidades da versão mais recente. | AuditIfNotExists; Desabilitado | 2.2.0 |
| Os aplicativos de função devem usar a versão TLS mais recente | Periodicamente, versões mais recentes são lançadas para TLS devido a falhas de segurança, incluem funcionalidades adicionais e aumentam a velocidade. Atualize para a versão TLS mais recente para aplicativos Function para aproveitar as correções de segurança, se houver, e/ou novas funcionalidades da versão mais recente. | AuditIfNotExists; Desabilitado | 2.3.0 |
PA-1: Separe e limite usuários altamente privilegiados/administrativos
Para obter mais informações, consulte Acesso privilegiado: PA-1: Separar e limitar usuários altamente privilegiados/administrativos.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Um máximo de 3 proprietários devem ser designados para a sua subscrição | Recomenda-se designar até 3 proprietários de assinatura para reduzir o potencial de violação por um proprietário comprometido. | AuditIfNotExists; Desabilitado | 3.0.0 |
| Contas bloqueadas com permissões de proprietário em recursos do Azure devem ser removidas | Contas preteridas com permissões de proprietário devem ser removidas da sua assinatura. Contas preteridas são contas que foram bloqueadas para entrar. | AuditIfNotExists; Desabilitado | 1.0.0 |
| Contas de convidado com permissões de proprietário em recursos do Azure devem ser removidas | As contas externas com permissões de proprietário devem ser removidas da sua subscrição para evitar o acesso não monitorizado. | AuditIfNotExists; Desabilitado | 1.0.0 |
| Deve haver mais de um proprietário atribuído à sua assinatura | É recomendável designar mais de um proprietário de assinatura para ter redundância de acesso de administrador. | AuditIfNotExists; Desabilitado | 3.0.0 |
PA-2: Evite o acesso permanente para contas de usuário e permissões
Para obter mais informações, consulte Acesso privilegiado: PA-2: evitar acesso permanente para contas de usuário e permissões.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| As portas de gerenciamento de máquinas virtuais devem ser protegidas com controle de acesso à rede just-in-time | O possível acesso à rede Just In Time (JIT) será monitorado pela Central de Segurança do Azure como recomendações | AuditIfNotExists; Desabilitado | 3.0.0 |
PA-4: Revise e reconcilie o acesso do usuário regularmente
Para obter mais informações, consulte Acesso privilegiado: PA-4: revisar e reconciliar o acesso do usuário regularmente.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Contas bloqueadas com permissões de proprietário em recursos do Azure devem ser removidas | Contas preteridas com permissões de proprietário devem ser removidas da sua assinatura. Contas preteridas são contas que foram bloqueadas para entrar. | AuditIfNotExists; Desabilitado | 1.0.0 |
| Contas bloqueadas com permissões de leitura e gravação em recursos do Azure devem ser removidas | As contas preteridas devem ser removidas das suas subscrições. Contas preteridas são contas que foram bloqueadas para entrar. | AuditIfNotExists; Desabilitado | 1.0.0 |
| Contas de convidado com permissões de proprietário em recursos do Azure devem ser removidas | As contas externas com permissões de proprietário devem ser removidas da sua subscrição para evitar o acesso não monitorizado. | AuditIfNotExists; Desabilitado | 1.0.0 |
| Contas de convidado com permissões de leitura em recursos do Azure devem ser removidas | As contas externas com privilégios de leitura devem ser removidas da sua subscrição para evitar o acesso não monitorizado. | AuditIfNotExists; Desabilitado | 1.0.0 |
| Contas de convidado com permissões de gravação em recursos do Azure devem ser removidas | As contas externas com privilégios de escrita devem ser removidas da sua subscrição para evitar o acesso não monitorizado. | AuditIfNotExists; Desabilitado | 1.0.0 |
PA-7: Siga o princípio de administração suficiente (menor privilégio)
Para obter mais informações, consulte Acesso privilegiado: PA-7: Siga o princípio de administração suficiente (privilégio mínimo).
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| As assinaturas de Gerenciamento de API não devem ter escopo para todas as APIs | As assinaturas do Gerenciamento de API devem ter como escopo um produto ou uma API individual em vez de todas as APIs, o que pode resultar em uma exposição excessiva de dados. | Auditoria; Deficientes; Negar | 1.1.0 |
| Auditar o uso de funções RBAC personalizadas | Audite funções internas, como 'Proprietário, Contribuinte, Leitor' em vez de funções RBAC personalizadas, que são propensas a erros. O uso de funções personalizadas é tratado como uma exceção e requer uma revisão rigorosa e modelagem de ameaças | Auditoria; Desabilitado | 1.0.1 |
| O Azure Key Vault deve usar o modelo de permissão RBAC | Habilite o modelo de permissão RBAC nos Cofres de Chaves. Saiba mais em: Migrar da política de acesso ao cofre para um modelo de permissão de controle de acesso baseado em função do Azure | Auditoria; Negar; Desabilitado | 1.0.1 |
| O RBAC (Controle de Acesso Baseado em Função) deve ser usado nos Serviços Kubernetes | Para fornecer filtragem granular sobre as ações que os usuários podem executar, use o RBAC (Controle de Acesso Baseado em Função) para gerenciar permissões em Clusters de Serviço do Kubernetes e configurar políticas de autorização relevantes. | Auditoria; Desabilitado | 1.1.0 |
PV-2: Auditar e impor configurações seguras
Para obter mais informações, consulte Gerenciamento de postura e vulnerabilidade: PV-2: auditar e impor configurações seguras.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| O ponto de extremidade de gerenciamento direto do Gerenciamento de API não deve ser habilitado | A API REST de gerenciamento direto no Gerenciamento de API do Azure ignora os mecanismos de controle de acesso, autorização e limitação baseados em função do Azure Resource Manager, aumentando assim a vulnerabilidade do seu serviço. | Auditoria; Deficientes; Negar | 1.0.2 |
| Os aplicativos do Serviço de Aplicativo devem ter os Certificados de Cliente (certificados de cliente de entrada) habilitados | Os certificados de cliente permitem que o aplicativo solicite um certificado para solicitações de entrada. Somente os clientes que possuem um certificado válido poderão acessar o aplicativo. Esta política aplica-se a aplicações com a versão Http definida como 1.1. | AuditIfNotExists; Desabilitado | 1.0.0 |
| As aplicações do App Service devem ter a depuração remota desativada | A depuração remota requer que as portas de entrada sejam abertas numa aplicação do App Service. A depuração remota deve ser desativada. | AuditIfNotExists; Desabilitado | 2.0.0 |
| Os aplicativos do Serviço de Aplicativo não devem ter o CORS configurado para permitir que todos os recursos acessem seus aplicativos | O Compartilhamento de Recursos entre Origens (CORS) não deve permitir que todos os domínios acessem seu aplicativo. Permita que apenas os domínios necessários interajam com seu aplicativo. | AuditIfNotExists; Desabilitado | 2.0.0 |
| A versão da plataforma de Gerenciamento de API do Azure deve ser stv2 | A versão da plataforma de computação stv1 do Azure API Management será desativada a partir de 31 de agosto de 2024 e essas instâncias devem ser migradas para a plataforma de computação stv2 para suporte contínuo. Saiba mais em API Management stv1 platform retirement - Global Azure cloud (agosto de 2024) | Auditoria; Negar; Desabilitado | 1.0.0 |
| Os clusters Kubernetes habilitados para Azure Arc devem ter a extensão Azure Policy instalada | A extensão da Política do Azure para o Azure Arc fornece imposições e proteções em escala em seus clusters Kubernetes habilitados para Arc de maneira centralizada e consistente. Saiba mais em Compreender a Política do Azure para clusters Kubernetes. | AuditIfNotExists; Desabilitado | 1.1.0 |
| As instâncias de computação do Azure Machine Learning devem ser recriadas para obter as atualizações de software mais recentes | Garanta que as instâncias de computação do Azure Machine Learning sejam executadas no sistema operacional disponível mais recente. A segurança é melhorada e as vulnerabilidades reduzidas através da execução com os patches de segurança mais recentes. Para obter mais informações, visite Gerenciamento de vulnerabilidades. | não aplicável | 1.0.3 |
| O Complemento de Política do Azure para o serviço Kubernetes (AKS) deve ser instalado e habilitado em seus clusters | O Complemento de Política do Azure para o serviço Kubernetes (AKS) estende o Gatekeeper v3, um webhook de controlador de admissão para o Open Policy Agent (OPA), para aplicar imposições e proteções em escala em seus clusters de maneira centralizada e consistente. | Auditoria; Desabilitado | 1.0.2 |
| Os aplicativos de função devem ter os Certificados de Cliente (Certificados de cliente de entrada) habilitados | Os certificados de cliente permitem que o aplicativo solicite um certificado para solicitações de entrada. Somente os clientes que possuem um certificado válido poderão acessar o aplicativo. Esta política aplica-se a aplicações com a versão Http definida como 1.1. | AuditIfNotExists; Desabilitado | 1.1.0 |
| As aplicações de funções devem ter a depuração remota desativada | A depuração remota requer que as portas de entrada sejam abertas nas aplicações Function. A depuração remota deve ser desativada. | AuditIfNotExists; Desabilitado | 2.1.0 |
| Os aplicativos de função não devem ter o CORS configurado para permitir que todos os recursos acessem seus aplicativos | O Compartilhamento de Recursos entre Origens (CORS) não deve permitir que todos os domínios acessem a sua aplicação Function. Permita que apenas os domínios necessários interajam com seu aplicativo Function. | AuditIfNotExists; Desabilitado | 2.1.0 |
| Os limites de recursos de CPU e memória dos contêineres de cluster do Kubernetes não devem exceder os limites especificados | Imponha limites de recursos de CPU e memória de contêiner para evitar ataques de esgotamento de recursos em um cluster Kubernetes. Esta política está geralmente disponível para o Serviço Kubernetes (AKS) e a visualização para o Kubernetes habilitado para Azure Arc. Para obter mais informações, consulte Compreender a política do Azure para clusters Kubernetes. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 9.3.0 |
| Os contêineres de cluster do Kubernetes não devem compartilhar namespaces de host | Bloqueie os contêineres de pod de compartilhar o namespace de ID de processo do host, o namespace IPC do host e o namespace de rede do host em um cluster Kubernetes. Esta recomendação está alinhada com os Padrões de Segurança do Kubernetes Pod para namespaces de host e faz parte do CIS 5.2.1, 5.2.2 e 5.2.3, que se destinam a melhorar a segurança de seus ambientes Kubernetes. Esta política está geralmente disponível para o Serviço Kubernetes (AKS) e a visualização para o Kubernetes habilitado para Azure Arc. Para obter mais informações, consulte Compreender a política do Azure para clusters Kubernetes. | Auditoria; Negar; Desabilitado | 6.0.0 |
| Os contêineres de cluster do Kubernetes só devem usar perfis permitidos do AppArmor | Os contêineres só devem usar perfis AppArmor permitidos em um cluster Kubernetes. Esta política está geralmente disponível para o Serviço Kubernetes (AKS) e a visualização para o Kubernetes habilitado para Azure Arc. Para obter mais informações, consulte Compreender a política do Azure para clusters Kubernetes. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 6.2.1 |
| Os contêineres de cluster do Kubernetes devem usar apenas os recursos permitidos | Restrinja os recursos para reduzir a superfície de ataque de contêineres em um cluster Kubernetes. Esta recomendação faz parte do CIS 5.2.8 e do CIS 5.2.9, que se destinam a melhorar a segurança de seus ambientes Kubernetes. Esta política está geralmente disponível para o Serviço Kubernetes (AKS) e a visualização para o Kubernetes habilitado para Azure Arc. Para obter mais informações, consulte Compreender a política do Azure para clusters Kubernetes. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 6.2.0 |
| Os contêineres de cluster do Kubernetes só devem usar imagens permitidas | Use imagens de registros confiáveis para reduzir o risco de exposição do cluster Kubernetes a vulnerabilidades desconhecidas, problemas de segurança e imagens maliciosas. Para obter mais informações, consulte Compreender a política do Azure para clusters Kubernetes. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 9.3.0 |
| Os contêineres de cluster do Kubernetes devem ser executados com um sistema de arquivos raiz somente leitura | Execute contêineres com um sistema de arquivos raiz somente leitura para proteger contra alterações em tempo de execução com binários mal-intencionados sendo adicionados ao PATH em um cluster Kubernetes. Esta política está geralmente disponível para o Serviço Kubernetes (AKS) e a visualização para o Kubernetes habilitado para Azure Arc. Para obter mais informações, consulte Compreender a política do Azure para clusters Kubernetes. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 6.3.0 |
| Os volumes hostPath do pod de cluster do Kubernetes só devem usar caminhos de host permitidos | Limite as montagens de volume do pod HostPath aos caminhos de host permitidos em um cluster Kubernetes. Esta política está geralmente disponível para o Serviço Kubernetes (AKS) e o Kubernetes habilitado para Azure Arc. Para obter mais informações, consulte Compreender a política do Azure para clusters Kubernetes. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 6.3.0 |
| Os pods e contêineres de cluster do Kubernetes só devem ser executados com IDs de usuário e grupo aprovados | Controle os IDs de usuário, grupo primário, grupo suplementar e grupo do sistema de arquivos que pods e contêineres podem usar para executar em um cluster Kubernetes. Esta política está geralmente disponível para o Serviço Kubernetes (AKS) e a visualização para o Kubernetes habilitado para Azure Arc. Para obter mais informações, consulte Compreender a política do Azure para clusters Kubernetes. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 6.2.0 |
| Os pods do cluster do Kubernetes devem utilizar apenas a rede de host e a lista de portas aprovadas | Restrinja o acesso do pod à rede host e às portas de host permitidas em um cluster Kubernetes. Esta recomendação faz parte do CIS 5.2.4, que se destina a melhorar a segurança de seus ambientes Kubernetes e se alinha com os Pod Security Standards (PSS) para hostPorts. Esta política está geralmente disponível para o Serviço Kubernetes (AKS) e a visualização para o Kubernetes habilitado para Azure Arc. Para obter mais informações, consulte Compreender a política do Azure para clusters Kubernetes. | Auditoria; Negar; Desabilitado | 7.0.0 |
| Os serviços de cluster do Kubernetes devem escutar somente nas portas permitidas | Restrinja os serviços para escutar apenas nas portas permitidas para proteger o acesso ao cluster do Kubernetes. Esta política está geralmente disponível para o Serviço Kubernetes (AKS) e a visualização para o Kubernetes habilitado para Azure Arc. Para obter mais informações, consulte Compreender a política do Azure para clusters Kubernetes. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 8.2.0 |
| O cluster do Kubernetes não deve permitir contêineres privilegiados | Não permita a criação de contêineres privilegiados em um cluster do Kubernetes. Esta recomendação faz parte do CIS 5.2.1 que se destina a melhorar a segurança de seus ambientes Kubernetes. Esta política está geralmente disponível para o Serviço Kubernetes (AKS) e a visualização para o Kubernetes habilitado para Azure Arc. Para obter mais informações, consulte Compreender a política do Azure para clusters Kubernetes. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 9.2.0 |
| Os clusters Kubernetes devem desativar as credenciais de API de montagem automática | Desative as credenciais de API de montagem automática para impedir que um recurso de Pod potencialmente comprometido execute comandos de API em clusters Kubernetes. Para obter mais informações, consulte Compreender a política do Azure para clusters Kubernetes. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 4.2.0 |
| Os clusters do Kubernetes não devem permitir o escalonamento de privilégios de contêiner | Não permita que contêineres sejam executados com escalonamento de privilégios para enraizar em um cluster Kubernetes. Esta recomendação faz parte do CIS 5.2.5 que se destina a melhorar a segurança dos seus ambientes Kubernetes. Esta política está geralmente disponível para o Serviço Kubernetes (AKS) e a visualização para o Kubernetes habilitado para Azure Arc. Para obter mais informações, consulte Compreender a política do Azure para clusters Kubernetes. | Auditoria; Negar; Desabilitado | 8.0.0 |
| Os clusters Kubernetes não devem conceder recursos de segurança CAP_SYS_ADMIN | Para reduzir a superfície de ataque de seus contêineres, restrinja CAP_SYS_ADMIN recursos do Linux. Para obter mais informações, consulte Compreender a política do Azure para clusters Kubernetes. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 5.1.0 |
| Os clusters Kubernetes não devem usar o namespace padrão | Impeça o uso do namespace padrão em clusters Kubernetes para proteger contra acesso não autorizado para os tipos de recursos ConfigMap, Pod, Secret, Service e ServiceAccount. Para obter mais informações, consulte Compreender a política do Azure para clusters Kubernetes. | auditoria; Auditoria; negar; Negar; deficientes; Desabilitado | 4.2.0 |
PV-4: Auditar e impor configurações seguras para recursos de computação
Para obter mais informações, consulte Gerenciamento de postura e vulnerabilidade: PV-4: auditar e impor configurações seguras para recursos de computação.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| A extensão Configuração do Convidado deve ser instalada em suas máquinas | Para garantir configurações seguras das configurações de convidado da sua máquina, instale a extensão Configuração de convidado. As configurações no convidado que a extensão monitora incluem a configuração do sistema operacional, a configuração ou presença do aplicativo e as configurações do ambiente. Uma vez instaladas, as políticas de convidado estarão disponíveis, como 'o Windows Exploit Guard deve ser ativado'. Saiba mais em Compreender a Configuração da Máquina do Azure. | AuditIfNotExists; Desabilitado | 1.0.3 |
| As máquinas Linux devem atender aos requisitos da linha de base de segurança de computação do Azure | Requer que os pré-requisitos sejam implantados no escopo da atribuição de política. Para obter detalhes, visite Compreender a configuração da máquina do Azure. As máquinas não serão compatíveis se a máquina não estiver configurada corretamente para uma das recomendações na linha de base de segurança de computação do Azure. | AuditIfNotExists; Desabilitado | 2.3.0 |
| A extensão Configuração de Convidado das máquinas virtuais deve ser implantada com identidade gerenciada atribuída ao sistema | A extensão Configuração de Convidado requer uma identidade gerenciada atribuída ao sistema. As máquinas virtuais do Azure no âmbito desta política não serão compatíveis quando tiverem a extensão Configuração de Convidado instalada, mas não tiverem uma identidade gerida atribuída ao sistema. Saiba mais em Compreender a Configuração da Máquina do Azure | AuditIfNotExists; Desabilitado | 1.0.1 |
| As máquinas Windows devem atender aos requisitos da linha de base de segurança de computação do Azure | Requer que os pré-requisitos sejam implantados no escopo da atribuição de política. Para obter detalhes, visite Compreender a configuração da máquina do Azure. As máquinas não serão compatíveis se a máquina não estiver configurada corretamente para uma das recomendações na linha de base de segurança de computação do Azure. | AuditIfNotExists; Desabilitado | 2.1.0 |
| [Pré-visualização]: Os servidores HCI do Azure Stack devem ter políticas de controlo de aplicações aplicadas de forma consistente | No mínimo, aplique a política base do Microsoft WDAC no modo imposto em todos os servidores HCI do Azure Stack. As diretivas WDAC (Controle de Aplicativo do Windows Defender) aplicadas devem ser consistentes entre servidores no mesmo cluster. | Auditoria; Deficientes; AuditIfNotExists | 1.0.0-pré-visualização |
| [Pré-visualização]: Os servidores HCI do Azure Stack devem cumprir os requisitos Secured-core | Certifique-se de que todos os servidores HCI do Azure Stack atendam aos requisitos de núcleo seguro. Para habilitar os requisitos do servidor Secured-core: 1. Na página Clusters HCI do Azure Stack, vá para o Windows Admin Center e selecione Conectar. 2. Vá para a extensão Segurança e selecione Secured-core. 3. Selecione qualquer configuração que não esteja habilitada e clique em Ativar. | Auditoria; Deficientes; AuditIfNotExists | 1.0.0-pré-visualização |
| [Preview]: A extensão Guest Attestation deve ser instalada em máquinas virtuais Linux suportadas | Instale a extensão Atestado de Convidado em máquinas virtuais Linux suportadas para permitir que a Central de Segurança do Azure ateste e monitore proativamente a integridade da inicialização. Uma vez instalado, a integridade de inicialização será atestada via Atestado Remoto. Esta avaliação aplica-se a máquinas virtuais Linux Trusted Launch e Confidential. | AuditIfNotExists; Desabilitado | 6.0.0-pré-visualização |
| [Preview]: A extensão Guest Attestation deve ser instalada em conjuntos de dimensionamento de máquinas virtuais Linux suportados | Instale a extensão Atestado de Convidado em conjuntos de dimensionamento de máquinas virtuais Linux suportadas para permitir que a Central de Segurança do Azure ateste e monitore proativamente a integridade da inicialização. Uma vez instalado, a integridade de inicialização será atestada via Atestado Remoto. Esta avaliação aplica-se aos conjuntos de dimensionamento de máquinas virtuais Linux Confiáveis e Confidenciais. | AuditIfNotExists; Desabilitado | 5.1.0-Pré-visualização |
| [Pré-visualização]: A extensão de Atestado de Convidado deve ser instalada em máquinas virtuais Windows suportadas | Instale a extensão Atestado de Convidado em máquinas virtuais suportadas para permitir que a Central de Segurança do Azure ateste e monitore proativamente a integridade da inicialização. Uma vez instalado, a integridade de inicialização será atestada via Atestado Remoto. Esta avaliação aplica-se a máquinas virtuais Windows Confiáveis e Confidenciais. | AuditIfNotExists; Desabilitado | 4.0.0-Pré-visualização |
| [Pré-visualização]: A extensão de Atestado de Convidado deve ser instalada em conjuntos de dimensionamento de máquinas virtuais Windows suportados | Instale a extensão Atestado de Convidado em conjuntos de dimensionamento de máquinas virtuais com suporte para permitir que a Central de Segurança do Azure ateste e monitore proativamente a integridade da inicialização. Uma vez instalado, a integridade de inicialização será atestada via Atestado Remoto. Esta avaliação aplica-se aos conjuntos de dimensionamento de máquinas virtuais Windows Confiáveis e Confidenciais. | AuditIfNotExists; Desabilitado | 3.1.0-Pré-visualização |
| [Pré-visualização]: As máquinas virtuais Linux devem utilizar apenas componentes de arranque assinados e fidedignos | Todos os componentes de inicialização do sistema operacional (carregador de inicialização, kernel, drivers do kernel) devem ser assinados por editores confiáveis. O Defender for Cloud identificou componentes de inicialização do sistema operacional não confiáveis em uma ou mais de suas máquinas Linux. Para proteger as suas máquinas de componentes potencialmente maliciosos, adicione-os à sua lista de permissões ou remova os componentes identificados. | AuditIfNotExists; Desabilitado | 1.0.0-pré-visualização |
| [Pré-visualização]: O Arranque Seguro deve ser ativado em máquinas virtuais Windows suportadas | Habilite a Inicialização Segura em máquinas virtuais Windows suportadas para mitigar alterações mal-intencionadas e não autorizadas na cadeia de inicialização. Uma vez ativados, apenas bootloaders confiáveis, kernel e drivers do kernel poderão ser executados. Esta avaliação aplica-se a máquinas virtuais Windows Confiáveis e Confidenciais. | Auditoria; Desabilitado | 4.0.0-Pré-visualização |
| [Pré-visualização]: o vTPM deve ser ativado em máquinas virtuais suportadas | Habilite o dispositivo TPM virtual em máquinas virtuais suportadas para facilitar a inicialização medida e outros recursos de segurança do sistema operacional que exigem um TPM. Uma vez ativado, o vTPM pode ser usado para atestar a integridade da inicialização. Essa avaliação só se aplica a máquinas virtuais habilitadas para inicialização confiável. | Auditoria; Desabilitado | 2.0.0-pré-visualização |
PV-5: Realizar avaliações de vulnerabilidade
Para obter mais informações, consulte Gerenciamento de postura e vulnerabilidade: PV-5: Executar avaliações de vulnerabilidade.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Uma solução de avaliação de vulnerabilidade deve ser habilitada em suas máquinas virtuais | Audita máquinas virtuais para detetar se elas estão executando uma solução de avaliação de vulnerabilidade suportada. Um componente central de cada programa de segurança e risco cibernético é a identificação e análise de vulnerabilidades. O nível de preços padrão da Central de Segurança do Azure inclui a verificação de vulnerabilidades para suas máquinas virtuais sem custo extra. Além disso, a Central de Segurança pode implantar automaticamente essa ferramenta para você. | AuditIfNotExists; Desabilitado | 3.0.0 |
| Máquinas devem ter descobertas secretas resolvidas | Audita máquinas virtuais para detetar se elas contêm descobertas secretas das soluções de verificação secretas em suas máquinas virtuais. | AuditIfNotExists; Desabilitado | 1.0.2 |
| A avaliação de vulnerabilidade deve ser habilitada na Instância Gerenciada SQL | Audite cada Instância Gerenciada do SQL que não tenha verificações recorrentes de avaliação de vulnerabilidades habilitadas. A avaliação de vulnerabilidades pode descobrir, rastrear e ajudá-lo a corrigir possíveis vulnerabilidades do banco de dados. | AuditIfNotExists; Desabilitado | 1.0.1 |
| A avaliação de vulnerabilidade deve ser habilitada em seus servidores SQL | Audite os servidores SQL do Azure que não têm a avaliação de vulnerabilidades configurada corretamente. A avaliação de vulnerabilidades pode descobrir, rastrear e ajudá-lo a corrigir possíveis vulnerabilidades do banco de dados. | AuditIfNotExists; Desabilitado | 3.0.0 |
PV-6: Corrige vulnerabilidades de forma rápida e automática
Para obter mais informações, consulte Gerenciamento de postura e vulnerabilidade: PV-6: corrigir vulnerabilidades rápida e automaticamente.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| As imagens de contêiner do Registro do Azure devem ter vulnerabilidades resolvidas (com tecnologia Microsoft Defender Vulnerability Management) | A avaliação de vulnerabilidade da imagem de contêiner verifica o registro em busca de vulnerabilidades comumente conhecidas (CVEs) e fornece um relatório de vulnerabilidade detalhado para cada imagem. A resolução de vulnerabilidades pode melhorar muito sua postura de segurança, garantindo que as imagens sejam seguras para uso antes da implantação. | AuditIfNotExists; Desabilitado | 1.0.1 |
| As imagens de contentores em execução no Azure devem ter as vulnerabilidades resolvidas (impulsionado por Microsoft Defender Vulnerability Management) | A avaliação de vulnerabilidade da imagem de contêiner verifica o registro em busca de vulnerabilidades comumente conhecidas (CVEs) e fornece um relatório de vulnerabilidade detalhado para cada imagem. Essa recomendação fornece visibilidade para imagens vulneráveis atualmente em execução em seus clusters Kubernetes. Corrigir vulnerabilidades em imagens de contêiner que estão em execução no momento é fundamental para melhorar sua postura de segurança, reduzindo significativamente a superfície de ataque para suas cargas de trabalho conteinerizadas. | AuditIfNotExists; Desabilitado | 1.0.1 |
| As máquinas devem ser configuradas para verificar periodicamente se há atualizações do sistema ausentes | Para garantir que as avaliações periódicas de atualizações do sistema ausentes sejam acionadas automaticamente a cada 24 horas, a propriedade AssessmentMode deve ser definida como 'AutomaticByPlatform'. Saiba mais sobre a propriedade AssessmentMode para Windows: modo de avaliação de patches do Windows, para Linux: modo de avaliação de patches Linux. | Auditoria; Negar; Desabilitado | 3.9.0 |
| Os bancos de dados SQL devem ter as descobertas de vulnerabilidade resolvidas | Monitore a avaliação de vulnerabilidades, os resultados da verificação e as recomendações sobre como corrigir vulnerabilidades do banco de dados. | AuditIfNotExists; Desabilitado | 4.1.0 |
| Servidores SQL em máquinas devem ter descobertas de vulnerabilidade resolvidas | A avaliação de vulnerabilidade do SQL verifica seu banco de dados em busca de vulnerabilidades de segurança e expõe quaisquer desvios das práticas recomendadas, como configurações incorretas, permissões excessivas e dados confidenciais desprotegidos. Resolver as vulnerabilidades encontradas pode melhorar muito a postura de segurança do seu banco de dados. | AuditIfNotExists; Desabilitado | 1.0.0 |
| As atualizações do sistema devem ser instaladas em suas máquinas (alimentadas pela Central de Atualizações) | Suas máquinas estão faltando sistema, segurança e atualizações críticas. As atualizações de software geralmente incluem patches críticos para falhas de segurança. Essas falhas são frequentemente exploradas em ataques de malware, por isso é vital manter seu software atualizado. Para instalar todos os patches pendentes e proteger suas máquinas, siga as etapas de correção. | AuditIfNotExists; Desabilitado | 1.0.1 |
Próximas Etapas
- Analise o benchmark de segurança na nuvem da Microsoft para obter mais informações sobre detalhes de controle.
- Atribuir políticas através do portal do Azure
- Saiba mais sobre o Azure Policy