Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo lista as definições de política internas do Azure Policy relacionadas ao microsoft cloud security benchmark v2 (versão prévia). Cada controle do parâmetro de comparação é mapeado para uma ou mais definições do Azure Policy.
Em conformidade com o Azure Policy 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 do Azure Policy no momento. Portanto, a conformidade no Azure Policy é somente uma exibição parcial do status de conformidade geral.
As associações entre controles e definições do Azure Policy para esse padrão de conformidade podem mudar ao longo do tempo.
IA-1: garantir o uso de modelos aprovados
Para obter mais informações, consulte Segurança de Inteligência Artificial: IA-1: garantir o uso de modelos aprovados.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| [Versão prévia]: as implantações do Azure Machine Learning devem usar apenas modelos de Registro aprovados | Restrinja a implantação de modelos de Registro para controlar modelos criados externamente usados em sua organização | Auditoria; Negar; Desactivado | 1.0.0-preview |
| [Versão prévia]: As implantações do Registro de Modelo do Azure Machine Learning são restritas, exceto pelo Registro permitido | Implante apenas os Modelos de Registro no Registro permitido e que não sejam restritos. | n/a | 1.0.0-preview |
AM-2: usar apenas serviços aprovados
Para obter mais informações, consulte o Gerenciamento de Ativos: AM-2: use 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 Gerenciamento de API do Azure 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 na desativação da plataforma STV1 do Gerenciamento de API – Nuvem global do Azure (agosto de 2024) | Auditoria; Negar; Desactivado | 1.0.0 |
| As contas de armazenamento devem ser migradas para os novos recursos do Azure Resource Manager | Use o novo Azure Resource Manager para suas contas de armazenamento para fornecer aprimoramentos de segurança, como: controle de acesso (RBAC) mais forte, melhor auditoria, implantação e controle com base no Azure Resource Manager, acesso a identidades gerenciadas, acesso ao cofre de chaves por segredos, autenticação baseada no Azure AD e suporte para marcas e grupos de recursos para facilitar o gerenciamento de segurança | Auditoria; Negar; Desactivado | 1.0.0 |
| As contas de armazenamento devem ser migradas para os novos recursos do Azure Resource Manager | Use o novo Azure Resource Manager para suas contas de armazenamento para fornecer aprimoramentos de segurança, como: controle de acesso (RBAC) mais forte, melhor auditoria, implantação e controle com base no Azure Resource Manager, acesso a identidades gerenciadas, acesso ao cofre de chaves por segredos, autenticação baseada no Azure AD e suporte para marcas e grupos de recursos para facilitar o gerenciamento de segurança | Auditoria; Negar; Desactivado | 1.0.0 |
AM-3: garantir a segurança do gerenciamento do ciclo de vida do ativo
Para obter mais informações, consulte Asset Management: AM-3: garantir a segurança do gerenciamento do ciclo de vida do ativo.
| 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. Podem ser APIs que deveriam ter sido preteridas do serviço de Gerenciamento de API do Azure, mas que podem ter sido acidentalmente deixadas ativas. Normalmente, essas APIs não recebem a cobertura de segurança mais atualizada. | AuditIfNotExists; Desactivado | 1.0.1 |
BR-1: garantir backups automatizados 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; Desactivado | 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 armazenados apenas na região em que o servidor está hospedado, mas também é replicado para uma região emparelhada para dar a opção de recuperação em caso de falha de região. A configuração do armazenamento com redundância geográfica para backup só é permitida durante a criação do servidor. | Auditoria; Desactivado | 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 armazenados apenas na região em que o servidor está hospedado, mas também é replicado para uma região emparelhada para dar a opção de recuperação em caso de falha de região. A configuração do armazenamento com redundância geográfica para backup só é permitida durante a criação do servidor. | Auditoria; Desactivado | 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 armazenados apenas na região em que o servidor está hospedado, mas também é replicado para uma região emparelhada para dar a opção de recuperação em caso de falha de região. A configuração do armazenamento com redundância geográfica para backup só é permitida durante a criação do servidor. | Auditoria; Desactivado | 1.0.1 |
BR-2: proteger 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; Desactivado | 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 armazenados apenas na região em que o servidor está hospedado, mas também é replicado para uma região emparelhada para dar a opção de recuperação em caso de falha de região. A configuração do armazenamento com redundância geográfica para backup só é permitida durante a criação do servidor. | Auditoria; Desactivado | 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 armazenados apenas na região em que o servidor está hospedado, mas também é replicado para uma região emparelhada para dar a opção de recuperação em caso de falha de região. A configuração do armazenamento com redundância geográfica para backup só é permitida durante a criação do servidor. | Auditoria; Desactivado | 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 armazenados apenas na região em que o servidor está hospedado, mas também é replicado para uma região emparelhada para dar a opção de recuperação em caso de falha de região. A configuração do armazenamento com redundância geográfica para backup só é permitida durante a criação do servidor. | Auditoria; Desactivado | 1.0.1 |
| [Versão prévia]: A imutabilidade deve ser habilitada nos cofres dos Serviços de Recuperação | Esta política audita se a propriedade de cofres imutáveis está ativada para os cofres dos Serviços de Recuperação no escopo. Isso ajuda a evitar que seus dados de backup sejam excluídos antes da expiração pretendida. Saiba mais em Conceito do cofre Imutável para o Backup do Azure. | Auditoria; Desactivado | 1.0.1-preview |
| [Versão prévia]: A imutabilidade deve ser habilitada para cofres de backup | Essa política audita se a propriedade de cofres imutáveis estiver habilitada para cofres de Backup no escopo. Isso ajuda a evitar que seus dados de backup sejam excluídos antes da expiração pretendida. Saiba mais em Conceito do cofre Imutável para o Backup do Azure. | Auditoria; Desactivado | 1.0.1-preview |
| [Versão prévia]: a exclusão reversível deve ser habilitada para Cofres de Backup | Essa política audita se a exclusão reversível estiver habilitada para cofres de Backup no escopo. A exclusão reversível pode ajudá-lo a recuperar seus dados depois que eles tiverem sido excluídos. Saiba mais em Visão geral da exclusão reversível aprimorada para o Backup do Azure | Auditoria; Desactivado | 1.0.0-preview |
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 uma nova cobertura de descoberta, proteção, detecção e resposta para monitorar ataques comuns e configurações incorretas de segurança baseados em API. | AuditIfNotExists; Desactivado | 1.0.3 |
DP-2: Monitorar anomalias e ameaças direcionadas a 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 |
|---|---|---|---|
| O Azure Defender para servidores do Banco de Dados SQL do Azure deve estar habilitado | O Azure Defender para SQL oferece funcionalidade para expor e reduzir possíveis vulnerabilidades de banco de dados, detectar atividades anômalas que podem indicar ameaças aos Bancos de Dados SQL e descobrir e classificar dados confidenciais. | AuditIfNotExists; Desactivado | 1.0.2 |
| O Azure Defender para servidores SQL em computadores deve estar habilitado | O Azure Defender para SQL oferece funcionalidade para expor e reduzir possíveis vulnerabilidades de banco de dados, detectar atividades anômalas que podem indicar ameaças aos Bancos de Dados SQL e descobrir e classificar dados confidenciais. | AuditIfNotExists; Desactivado | 1.0.2 |
| O Azure Defender para SQL deve ser habilitado para Instâncias Gerenciadas de SQL desprotegidas | Audite cada Instância Gerenciada de SQL sem a segurança de dados avançada. | AuditIfNotExists; Desactivado | 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 detecta atividades anômalas, indicando tentativas incomuns e possivelmente prejudiciais de acesso ou exploração de bancos de dados. Saiba mais sobre os recursos do Azure Defender para bancos de dados relacionais de software livre em visão geral do Defender para bancos de dados relacionais do Open-Source. Importante: a habilitação deste plano resultará em encargos de proteção de 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 para Nuvem | AuditIfNotExists; Desactivado | 1.0.0 |
| O Microsoft Defender para APIs deve estar habilitado | O Microsoft Defender para APIs traz uma nova cobertura de descoberta, proteção, detecção e resposta para monitorar ataques comuns e configurações incorretas de segurança baseados em API. | AuditIfNotExists; Desactivado | 1.0.3 |
| O Microsoft Defender para Armazenamento deve estar habilitado | O Microsoft Defender para Armazenamento detecta 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 dados corrompidos. O novo plano do Defender para Armazenamento inclui Verificação de Malware e Detecção de Ameaças a Dados Confidenciais. Este plano também fornece uma estrutura de preços previsível (por conta de armazenamento) para controle da cobertura e dos custos. | AuditIfNotExists; Desactivado | 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 do 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 inseguros, como HTTP ou WS. | Auditoria; Desactivado; Negar | 2.0.2 |
| O Ambiente do Serviço de Aplicativo deve ser configurado com os conjuntos de codificação TLS mais fortes | Os dois conjuntos de criptografia 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; Desactivado | 1.0.0 |
| O Ambiente do Serviço de Aplicativo deve ter o TLS 1.0 e 1.1 desabilitado | O TLS 1.0 e 1.1 são protocolos desatualizados que não dão suporte a algoritmos de criptografia modernos. A desabilitação do tráfego de entrada do TLS 1.0 e 1.1 ajuda a proteger os aplicativos de um Ambiente do Serviço de Aplicativo. | Auditoria; Negar; Desactivado | 2.0.1 |
| O Ambiente do Serviço de Aplicativo deve ter a criptografia interna habilitada | A definição de InternalEncryption como verdadeiro criptografa o arquivo de paginação, os discos de trabalho e o tráfego de rede interno entre os front-ends e os trabalhos em um Ambiente do Serviço de Aplicativo. Para saber mais, consulte as configurações personalizadas para Ambientes do Serviço de Aplicativo. | Auditoria; Desactivado | 1.0.1 |
| Os slots de aplicativos do Serviço de Aplicativo devem permitir a criptografia de ponta a ponta | Habilitar a 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 aplicativo é criptografado. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os slots de aplicativos do Serviço de Aplicativo devem usar a versão mais recente do TLS | Periodicamente, versões mais recentes são lançadas para o TLS, devido a falhas de segurança, para incluir funcionalidades adicionais e aprimorar a velocidade. Atualize para a versão mais recente do TLS para aplicativos do Serviço de Aplicativo para aproveitar as correções de segurança, se houver, e/ou as novas funcionalidades da versão mais recente. | AuditIfNotExists; Desactivado | 1.2.0 |
| Os aplicativos do Serviço de Aplicativo devem habilitar a criptografia de ponta a ponta | Habilitar a 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 aplicativo é criptografado. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os aplicativos do Serviço de Aplicativo só devem ser acessíveis por HTTPS | O uso do HTTPS garante a autenticação do servidor/serviço e protege os dados em trânsito de ataques de interceptação de camada de rede. | Auditoria; Desactivado; Negar | 4.0.0 |
| Os aplicativos do Serviço de Aplicativo devem exigir apenas o FTPS | Habilite a imposição de FTPS para reforçar a segurança. | AuditIfNotExists; Desactivado | 3.0.0 |
| Os aplicativos do Serviço de Aplicativo devem usar a versão mais recente do TLS | Periodicamente, versões mais recentes são lançadas para o TLS, devido a falhas de segurança, para incluir funcionalidades adicionais e aprimorar a velocidade. Atualize para a versão mais recente do TLS para aplicativos do Serviço de Aplicativo para aproveitar as correções de segurança, se houver, e/ou as novas funcionalidades da versão mais recente. | AuditIfNotExists; Desactivado | 2.2.0 |
| Os pools do Lote 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 no Lote em Criar um pool com criptografia de disco habilitada. | Auditoria; Desactivado; Negar | 1.0.0 |
| O Azure Front Door Standard e Premium devem estar executando a versão mínima do TLS 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 de clientes usando o TLS 1.2 ou mais recente. Não é recomendável usar versões do TLS menores que 1.2, pois elas são fracas e não dão suporte a algoritmos criptográficos modernos. | Auditoria; Negar; Desactivado | 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; Desactivado | 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 do TLS como 1.2 ou mais recente aprimora a segurança garantindo que seu Banco de Dados SQL do Azure só possa ser acessado de clientes que usam o TLS 1.2 ou mais recente. O uso de versões do TLS inferiores à 1.2 não é recomendado, pois elas têm vulnerabilidades de segurança bem documentadas. | Auditoria; Desactivado; 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 geralmente é um requisito para conformidade com padrões regulatórios ou do setor. Visite: Diretrizes de segurança do Bot Framework. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 1.1.0 |
| 'Impor conexão SSL' deve ser habilitada para servidores de banco de dados MySQL | O Banco de Dados do Azure para MySQL dá suporte à conexão de seu servidor de Banco de Dados do Azure para MySQL para aplicativos cliente usando o protocolo SSL. Impor conexões SSL entre seu servidor de banco de dados e os aplicativos cliente ajuda a proteger contra ataques de "intermediários" criptografando o fluxo de dados entre o servidor e seu aplicativo. Essa configuração impõe que o SSL sempre esteja habilitado para acessar seu servidor de banco de dados. | Auditoria; Desactivado | 1.0.1 |
| 'Impor conexão SSL' deve ser habilitada para servidores de banco de dados PostgreSQL | O Banco de Dados do Azure para PostgreSQL dá suporte à conexão de seu servidor de Banco de Dados do Azure para PostgreSQL para aplicativos cliente usando o protocolo SSL. Impor conexões SSL entre seu servidor de banco de dados e os aplicativos cliente ajuda a proteger contra ataques de "intermediários" criptografando o fluxo de dados entre o servidor e seu aplicativo. Essa configuração impõe que o SSL sempre esteja habilitado para acessar seu servidor de banco de dados. | Auditoria; Desactivado | 1.0.1 |
| Os slots do aplicativo de funções devem habilitar a criptografia de ponta a ponta | Habilitar a 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 aplicativo é criptografado. | Auditoria; Negar; Desactivado | 1.1.0 |
| Os slots dos aplicativos de funções devem usar a versão mais recente do TLS | Periodicamente, versões mais recentes são lançadas para o TLS, devido a falhas de segurança, para incluir funcionalidades adicionais e aprimorar a velocidade. Atualize para a última versão do TLS para os aplicativos de funções, a fim de aproveitar as correções de segurança, se houver, e/ou as novas funcionalidades da última versão. | AuditIfNotExists; Desactivado | 1.3.0 |
| Os aplicativos de funções devem habilitar a criptografia de ponta a ponta | Habilitar a 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 aplicativo é criptografado. | Auditoria; Negar; Desactivado | 1.1.0 |
| Os aplicativos de funções só devem ser acessíveis por HTTPS | O uso do HTTPS garante a autenticação do servidor/serviço e protege os dados em trânsito de ataques de interceptação de camada de rede. | Auditoria; Desactivado; Negar | 5.1.0 |
| Os aplicativos de funções devem exigir apenas o FTPS | Habilite a imposição de FTPS para reforçar a segurança. | AuditIfNotExists; Desactivado | 3.1.0 |
| Os aplicativos de funções devem usar a versão mais recente do TLS | Periodicamente, versões mais recentes são lançadas para o TLS, devido a falhas de segurança, para incluir funcionalidades adicionais e aprimorar a velocidade. Atualize para a última versão do TLS para os aplicativos de funções, a fim de aproveitar as correções de segurança, se houver, e/ou as novas funcionalidades da última versão. | AuditIfNotExists; Desactivado | 2.3.0 |
| Os clusters do Kubernetes devem estar acessíveis somente por HTTPS | O uso do HTTPS garante a autenticação e protege os dados em trânsito de ataques de interceptação de camada de rede. Atualmente, essa funcionalidade está em disponibilidade geral para o AKS (Serviço do Kubernetes) e em versão prévia para o Kubernetes habilitado para Azure Arc. Para obter mais informações, visite Noções básicas sobre clusters do Azure Policy para Kubernetes | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 8.2.0 |
| Somente conexões seguras com o Cache do Azure para Redis devem ser habilitadas | Auditoria de habilitação de somente conexões via SSL ao Cache Redis do Azure. O uso de conexões seguras garante a autenticação entre o servidor e o serviço e protege os dados em trânsito dos ataques de camada de rede, como man-in-the-middle, espionagem e sequestro de sessão | Auditoria; Negar; Desactivado | 1.0.0 |
| Os servidores flexíveis do PostgreSQL devem estar executando o TLS versão 1.2 ou mais recente | Essa política ajuda a auditar todos os servidores flexíveis do PostgreSQL em seu ambiente que está em execução com a versão TLS menor que 1.2. | AuditIfNotExists; Desactivado | 1.1.0 |
| A Instância Gerenciada de SQL deve ter a versão mínima do TLS 1.2 | Definir a versão mínima do TLS como 1.2 melhora a segurança, garantindo que sua Instância Gerenciada de SQL só possa ser acessada de clientes usando o TLS 1.2. O uso de versões do TLS inferiores à 1.2 não é recomendado, pois elas têm vulnerabilidades de segurança bem documentadas. | Auditoria; Desactivado | 1.0.1 |
| A transferência segura para contas de armazenamento deve ser habilitada | Exigência de auditoria de transferência segura em sua conta de armazenamento. A transferência segura é uma opção que força a sua conta de armazenamento a aceitar somente solicitações de conexões seguras (HTTPS). O uso de HTTPS garante a autenticação entre o servidor e o serviço e protege dados em trânsito de ataques de camada de rede, como ataques intermediários, interceptação e sequestro de sessão | Auditoria; Negar; Desactivado | 2.0.0 |
| As contas de armazenamento devem ter a versão mínima do TLS especificada | Configure uma versão mínima do TLS para estabelecer uma 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 mais recente lançada, que é o TLS 1.2. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os computadores Windows devem ser configurados para usar protocolos de comunicação seguros | Para proteger a privacidade das informações comunicadas pela Internet, os computadores devem usar a última versão do protocolo de criptografia padrão do setor, o protocolo TLS. O TLS protege as comunicações em uma rede criptografando uma conexão entre computadores. | AuditIfNotExists; Desactivado | 4.1.1 |
| [Versão prévia]: a rede do host e de VMs deve ser protegida nos sistemas do Azure Stack HCI | Proteja os dados na rede do host do Azure Stack HCI e nas conexões da rede de máquinas virtuais. | Auditoria; Desactivado; AuditIfNotExists | 1.0.0-preview |
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 a 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 | Audite o provisionamento de um administrador do Microsoft Entra para 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 dos usuários de banco de dados e de outros serviços da Microsoft | AuditIfNotExists; Desactivado | 1.1.1 |
| As variáveis da conta de automação devem ser criptografadas | É importante habilitar a criptografia dos ativos variáveis da conta de Automação do Azure ao armazenar dados confidenciais | Auditoria; Negar; Desactivado | 1.1.0 |
| Os trabalhos do Azure Data Box devem habilitar criptografia dupla para dados inativos no dispositivo | Habilite uma segunda camada de criptografia baseada em software para dados em repouso no dispositivo. O dispositivo já está protegido por meio da criptografia De Criptografia Avançada Standard de 256 bits para dados em repouso. Essa opção adiciona uma segunda camada de criptografia de dados. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os dispositivos do Centro de Hardware do Azure Edge devem ter suporte de criptografia dupla habilitado | Verifique se os dispositivos ordenados do Centro de Hardware do Azure Edge têm suporte de criptografia dupla habilitado para proteger os dados em repouso no dispositivo. Essa opção adiciona uma segunda camada de criptografia de dados. | Auditoria; Negar; Desactivado | 2.0.0 |
| Os clusters do Azure HDInsight devem usar criptografia no host para criptografar dados inativos | Habilitar a criptografia no host ajuda a proteger e proteger seus dados para atender aos compromissos de conformidade e segurança organizacional. Quando você habilita a criptografia no host, os dados armazenados no host da VM são criptografados em repouso e os fluxos são criptografados para o serviço de armazenamento. | Auditoria; Negar; Desactivado | 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 esteja 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 as chaves gerenciadas pelo cliente do Azure Monitor. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 1.1.0 |
| O servidor flexível do MySQL do Azure deve ter a Autenticação Somente Do Microsoft Entra 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 MySQL do Azure possam ser acessadas exclusivamente pelas identidades do Microsoft Entra. | AuditIfNotExists; Desactivado | 1.0.1 |
| Os volumes SMB do Azure NetApp Files devem usar a criptografia SMB3 | Não permite a criação de volumes SMB sem criptografia SMB3 para garantir a integridade dos dados e a privacidade de dados. | Auditoria; Negar; Desactivado | 1.0.0 |
| Volumes do Azure NetApp Files do tipo NFSv4.1 devem usar criptografia de dados Kerberos | Permitir apenas o uso do modo de segurança de privacidade Kerberos (5p) para garantir que os dados sejam criptografados. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os dispositivos do Azure Stack Edge devem usar criptografia dupla | Para proteger os dados em repouso no dispositivo, verifique se eles são criptografados duas vezes, o acesso aos dados é controlado e, depois que o dispositivo é desativado, os dados são apagados com segurança dos discos de dados. Criptografia dupla é o uso de duas camadas de criptografia: o 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 do dispositivo stack edge específico. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 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 compromissos de conformidade e segurança organizacional. | Auditoria; Negar; Desactivado | 2.0.0 |
| A criptografia dupla deve ser habilitada no Azure Data Explorer | A habilitação da criptografia dupla ajuda a proteger seus dados para atender aos compromissos de conformidade e segurança da sua organização. Quando a criptografia dupla é habilitada, os dados da conta de armazenamento são criptografados duas vezes, uma vez no nível de serviço e outro no nível de infraestrutura, por meio de dois algoritmos de criptografia diferentes e duas chaves distintas. | Auditoria; Negar; Desactivado | 2.0.0 |
| Os namespaces do Hub de Eventos devem ter a criptografia dupla habilitada | A habilitação da criptografia dupla ajuda a proteger seus dados para atender aos compromissos de conformidade e segurança da sua organização. Quando a criptografia dupla é habilitada, os dados da conta de armazenamento são criptografados duas vezes, uma vez no nível de serviço e outro no nível de infraestrutura, por meio de dois algoritmos de criptografia diferentes e duas chaves distintas. | Auditoria; Negar; Desactivado | 1.0.0 |
| A criptografia de infraestrutura deve ser habilitada para servidores do Banco de Dados do Azure para MySQL | Habilite a criptografia de infraestrutura para servidores do Banco de Dados do Azure para MySQL para ter um nível mais alto de garantia de que os dados são seguros. Quando a criptografia de infraestrutura é habilitada, os dados em repouso são criptografados duas vezes usando chaves gerenciadas da Microsoft compatíveis com FIPS 140-2. | Auditoria; Negar; Desactivado | 1.0.0 |
| A criptografia de infraestrutura deve ser habilitada para servidores do Banco de Dados do Azure para PostgreSQL | Habilite a criptografia de infraestrutura para servidores do Banco de Dados do Azure para PostgreSQL para ter um nível mais alto de garantia de que os dados são seguros. Quando a criptografia de infraestrutura está habilitada, os dados em repouso são criptografados duas vezes usando chaves gerenciadas da Microsoft compatíveis com FIPS 140-2 | Auditoria; Negar; Desactivado | 1.0.0 |
| As máquinas virtuais do 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 recurso (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 as ofertas de criptografia. Esta política requer dois pré-requisitos a serem implantados no escopo de atribuição de política. Para obter detalhes, visite Noções básicas sobre a Configuração do Azure Machine. | AuditIfNotExists; Desactivado | 1.2.1 |
| Os discos gerenciados devem ter criptografia dupla, com chaves gerenciadas pelo cliente e pela plataforma | Os clientes confidenciais de alta segurança que estão preocupados com o risco associado a qualquer determinado algoritmo de criptografia, implementação ou chave sendo comprometido 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 a criptografia dupla. Saiba mais na criptografia do lado do servidor dos discos gerenciados do Azure. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os namespaces do Barramento de Serviço devem ter a criptografia dupla habilitada | A habilitação da criptografia dupla ajuda a proteger seus dados para atender aos compromissos de conformidade e segurança da sua organização. Quando a criptografia dupla é habilitada, os dados da conta de armazenamento são criptografados duas vezes, uma vez no nível de serviço e outro no nível de infraestrutura, por meio de dois algoritmos de criptografia diferentes e duas chaves distintas. | Auditoria; Negar; Desactivado | 1.0.0 |
| A propriedade ClusterProtectionLevel dos clusters do Service Fabric deve ser definida como EncryptAndSign | O Service Fabric fornece três níveis de proteção (Nenhum, Sinal e EncryptAndSign) para comunicação de nó a nó usando um certificado de cluster principal. Defina o nível de proteção para garantir que todas as mensagens de nó a nó sejam criptografadas e assinadas digitalmente | Auditoria; Negar; Desactivado | 1.1.0 |
| As contas de armazenamento devem ter criptografia de infraestrutura | Habilite a criptografia de infraestrutura para um nível mais alto de garantia de segurança dos dados. Quando a criptografia de infraestrutura está habilitada, os dados em uma conta de armazenamento são criptografados duas vezes. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os discos temporários e o cache para pools de nós de agente nos clusters do Serviço de Kubernetes do Azure devem ser criptografados no host | Para aprimorar a segurança dos dados, os dados armazenados no host da VM (máquina virtual) de suas VMs dos nós do Serviço de Kubernetes do Azure devem ser criptografados em repouso. Esse é um requisito comum em muitos padrões de conformidade regulatórias e do setor. | Auditoria; Negar; Desactivado | 1.0.1 |
| A Transparent Data Encryption deve ser habilitada para instâncias gerenciadas do Arc SQL. | Habilite a TDE (transparent Data Encryption) em repouso em uma Instância Gerenciada de SQL habilitada para Azure Arc. Saiba mais em Criptografar um banco de dados com criptografia de dados transparente manualmente na Instância Gerenciada de SQL habilitada pelo Azure Arc. | Auditoria; Desactivado | 1.0.0 |
| A Transparent Data Encryption em bancos de dados SQL deve ser habilitada | A Transparent Data Encryption deve ser habilitada para proteger os dados em repouso e atender aos requisitos de conformidade | AuditIfNotExists; Desactivado | 2.0.0 |
| As máquinas virtuais e os conjuntos de dimensionamento de máquinas virtuais devem ter 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 de máquinas virtuais. A criptografia no host habilita a criptografia em repouso para o disco temporário e caches de disco de dados/do sistema operacional. Discos do sistema operacional temporários e efêmeros são criptografados com chaves gerenciadas pela plataforma quando a criptografia no host está habilitada. Caches de disco de dados/do sistema operacional são criptografados em repouso com chave de criptografia gerenciada pela plataforma ou pelo cliente, dependendo do tipo de criptografia selecionado no disco. Saiba mais em Habilitar criptografia de ponta a ponta usando criptografia no host. | Auditoria; Negar; Desactivado | 1.0.0 |
| As máquinas virtuais do Windows 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 recurso (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 as ofertas de criptografia. Esta política requer dois pré-requisitos a serem implantados no escopo de atribuição de política. Para obter detalhes, visite Noções básicas sobre a Configuração do Azure Machine. | AuditIfNotExists; Desactivado | 1.1.1 |
DP-5: usar 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: use 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 os dados inativos com uma chave gerenciada pelo cliente (CMK) | O uso de chaves gerenciadas pelo cliente para criptografar dados inativos oferece 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 estiver habilitado, os dados serão criptografados usando chaves gerenciadas pela plataforma. Para implementar isso, atualize o parâmetro "Efeito" na Política de Segurança para o escopo aplicável. | Auditoria; Negar; Desactivado | 2.2.0 |
| A API do Azure para FHIR deve usar uma chave gerenciada pelo cliente para criptografar dados inativos | Use uma chave gerenciada pelo cliente para controlar a criptografia em repouso dos dados armazenados na API do Azure para FHIR quando esse for um requisito regulatório ou de conformidade. As chaves gerenciadas pelo cliente também fornecem criptografia dupla adicionando uma segunda camada de criptografia sobre a padrão feita com chaves gerenciadas pelo serviço. | auditoria; Auditoria; desactivado; Desactivado | 1.1.0 |
| As contas da Automação do Azure devem usar chaves gerenciadas pelo cliente para criptografar dados inativos | 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 normalmente são necessárias para atender aos padrões de conformidade regulatória. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Azure Key Vault criada por você e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida chave, incluindo rotação e gerenciamento. Saiba mais em Criptografia de ativos seguros na Automação do Azure. | Auditoria; Negar; Desactivado | 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 do Lote. Por padrão, os dados do cliente são criptografados com chaves gerenciadas pelo serviço, mas as chaves gerenciadas pelo cliente normalmente são necessárias para atender aos padrões de conformidade regulatória. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Azure Key Vault criada por você e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida chave, incluindo rotação e gerenciamento. Saiba mais na criptografia de dados da conta do Lote. | Auditoria; Negar; Desactivado | 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 do restante dos seus dados em 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 regulatória. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Azure Key Vault criada por você e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida chave, incluindo rotação e gerenciamento. Saiba mais em Configurar criptografia de disco no Cache do Azure para Redis. | Auditoria; Negar; Desactivado | 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 funcionalidades adicionais para controlar a rotação da principal chave de criptografia ou para apagar dados criptograficamente. | Auditoria; Desactivado; Negar | 1.0.0 |
| As contas do Azure Cosmos DB devem usar chaves gerenciadas pelo cliente para criptografar os dados inativos | Use chaves gerenciadas pelo cliente para gerenciar a criptografia em repouso do seu Azure Cosmos DB. Por padrão, os dados são criptografados em repouso com chaves gerenciadas pelo serviço, mas as chaves gerenciadas pelo cliente normalmente são necessárias para atender aos padrões de conformidade regulatória. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Azure Key Vault criada por você e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida chave, incluindo rotação e gerenciamento. Saiba mais em Configurar chaves de Customer-Managed. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 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 maneira automatizada. Os dados no próprio dispositivo já estão criptografados em repouso com criptografia De Criptografia Avançada Standard de 256 bits e a senha de desbloqueio do dispositivo é criptografada por padrão com uma chave gerenciada da Microsoft. | Auditoria; Negar; Desactivado | 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 aos clientes com requisitos especiais de conformidade e requer um Key Vault para gerenciar as chaves. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os workspaces do Azure Databricks devem ser SKU Premium que dá suporte a recursos como link privado, chave gerenciada pelo cliente para criptografia | Permitir apenas o workspace do Databricks com o Sku Premium que sua organização pode implantar para dar suporte a recursos como Link Privado, chave gerenciada pelo cliente para criptografia. Saiba mais em: Configurar a conectividade privada de back-end com o Azure Databricks. | Auditoria; Negar; Desactivado | 1.0.1 |
| As contas de Atualização de Dispositivo do Azure devem usar a chave gerenciada pelo cliente para criptografar dados inativos | A criptografia de dados em repouso no Azure Device Update com chave gerenciada pelo cliente adiciona uma segunda camada de criptografia sobre as chaves gerenciadas por serviço padrão, permite que o cliente controle chaves, políticas de rotação personalizadas e 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; Desactivado | 1.0.0 |
| Os clusters do Azure HDInsight devem usar chaves gerenciadas pelo cliente para criptografar dados inativos | Use chaves gerenciadas pelo cliente para gerenciar a criptografia em repouso dos 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 normalmente são necessárias para atender aos padrões de conformidade regulatória. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Azure Key Vault criada por você e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida chave, incluindo rotação e gerenciamento. Saiba mais em Criptografia dupla para dados em repouso. | Auditoria; Negar; Desactivado | 1.0.1 |
| Os Bots de Integridade do Azure devem usar chaves gerenciadas pelo cliente para criptografar dados inativos | Use as CMK (chaves gerenciadas pelo cliente) para gerenciar a criptografia em repouso dos dados de seus healthbots. Por padrão, os dados são criptografados em repouso com chaves gerenciadas pelo serviço, mas o CMK geralmente é necessário para atender aos padrões de conformidade regulatória. O CMK permite que os dados sejam criptografados com uma chave do Azure Key Vault criada e de propriedade de você. Você tem total controle e responsabilidade pelo ciclo de vida chave, incluindo rotação e gerenciamento. Saiba mais em Configurar chaves gerenciadas pelo cliente para criptografia de dados no serviço de agente de saúde | Auditoria; Desactivado | 1.0.0 |
| Os workspaces do Azure Machine Learning devem ser criptografados com uma chave gerenciada pelo cliente | Gerencie a criptografia em repouso dos dados do Workspace 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 normalmente são necessárias para atender aos padrões de conformidade regulatória. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Azure Key Vault criada por você e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida chave, incluindo rotação e gerenciamento. Saiba mais em Criar um workspace com o modelo do Azure Resource Manager. | Auditoria; Negar; Desactivado | 1.1.0 |
| Os workspaces do Azure Machine Learning devem ser criptografados com o uso de uma chave gerenciada pelo cliente | Gerencie a criptografia em repouso dos dados do Workspace 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 normalmente são necessárias para atender aos padrões de conformidade regulatória. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Azure Key Vault criada por você e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida chave, incluindo rotação e gerenciamento. Saiba mais em Criar um workspace com o modelo do Azure Resource Manager. | AuditIfNotExists; Desactivado | 1.0.0 |
| Os clusters de Logs do Azure Monitor devem ser criptografados com uma chave gerenciada pelo cliente | Crie o cluster de logs do Azure Monitor com criptografia de chaves gerenciadas pelo cliente. Por padrão, os dados do log são criptografados com chaves gerenciadas pelo serviço, mas as chaves gerenciadas pelo cliente normalmente são necessárias para atender à conformidade regulatória. A chave gerenciada pelo cliente no Azure Monitor oferece mais controle sobre o acesso aos dados, consulte Configurar chaves gerenciadas pelo cliente no Azure Monitor. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 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 todos os metadados e ativos de dados privados de seus trabalhos do Stream Analytics em sua conta de armazenamento. Isso fornece controle total sobre como os dados do Stream Analytics são criptografados. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 1.1.0 |
| Os workspaces 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 workspaces do Azure Synapse. As chaves gerenciadas pelo cliente fornecem criptografia dupla adicionando uma segunda camada de criptografia sobre a criptografia padrão com chaves gerenciadas pelo serviço. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os data factories do Azure devem ser criptografados 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 normalmente são necessárias para atender aos padrões de conformidade regulatória. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Azure Key Vault criada por você e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida chave, incluindo rotação e gerenciamento. Saiba mais em Criptografar o Azure Data Factory com a chave gerenciada pelo cliente. | Auditoria; Negar; Desactivado | 1.0.1 |
| O recurso de teste de carga do Azure deve usar chaves gerenciadas pelo cliente para criptografar dados inativos | Use cmk (chaves gerenciadas pelo cliente) para gerenciar a criptografia em repouso para o recurso de Teste de Carga do Azure. Por padrão, o encryptio é feito usando chaves gerenciadas pelo serviço, chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Azure Key Vault criada e de propriedade de você. Você tem total controle e responsabilidade pelo ciclo de vida chave, incluindo rotaçã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; Desactivado | 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 atender aos compromissos de conformidade e segurança organizacional. Por padrão, as chaves de criptografia gerenciadas pela Microsoft são usadas. Para obter maior flexibilidade no gerenciamento de chaves ou no controle do acesso à sua assinatura, selecione chaves gerenciadas pelo cliente, também conhecidas como BYOK (traga sua própria chave). Saiba mais sobre a criptografia do Serviço de Bot do Azure: criptografia do Serviço de Bot de IA do Azure para dados inativos. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 1.1.0 |
| Os sistemas operacionais e os discos de dados nos clusters do Serviço de Kubernetes do Azure devem ser criptografados por chaves gerenciadas pelo cliente | Criptografar o sistema operacional e os discos de dados usando chaves gerenciadas pelo cliente dá mais controle e flexibilidade no gerenciamento de chaves. Esse é um requisito comum em muitos padrões de conformidade regulatórias e do setor. | Auditoria; Negar; Desactivado | 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 em repouso no conteúdo dos seus Registros. Por padrão, os dados são criptografados em repouso com chaves gerenciadas pelo serviço, mas as chaves gerenciadas pelo cliente normalmente são necessárias para atender aos padrões de conformidade regulatória. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Azure Key Vault criada por você e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida chave, incluindo rotação e gerenciamento. Saiba mais em Customer-Managed Chaves do Registro de Contêiner do Azure. | Auditoria; Negar; Desactivado | 1.1.2 |
| A criptografia de chave gerenciada pelo cliente deve ser usada como parte da Criptografia CMK para instâncias gerenciadas do Arc SQL. | 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 de SQL habilitada pelo Azure Arc. | Auditoria; Desactivado | 1.0.0 |
| O Serviço DICOM deve usar uma chave gerenciada pelo cliente para criptografar dados inativos | 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 Integridade do Azure quando esse for um requisito regulatório ou de conformidade. As chaves gerenciadas pelo cliente também fornecem criptografia dupla adicionando uma segunda camada de criptografia sobre a padrão feita com chaves gerenciadas pelo serviço. | Auditoria; Desactivado | 1.0.0 |
| O Grupo de Volumes ElasticSan deve usar chaves gerenciadas pelo cliente para criptografar dados inativos | Use chaves gerenciadas pelo cliente para gerenciar a criptografia em repouso do VolumeGroup. Por padrão, os dados do cliente são criptografados com chaves gerenciadas pela plataforma, mas os CMKs geralmente são necessários para atender aos padrões de conformidade regulatória. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Azure Key Vault criada e de propriedade de você, com controle total e responsabilidade, incluindo rotação e gerenciamento. | Auditoria; Desactivado | 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 inativos com chaves gerenciadas pela Microsoft (padrão) ou chaves gerenciadas pelo cliente. Optar por criptografar dados usando chaves gerenciadas pelo cliente permite que você atribua, gire, desabilite e revogue o acesso às chaves que o Hub de Eventos usará para criptografar dados em seu namespace. Observe que o Hub de Eventos dá suporte apenas à criptografia com chaves gerenciadas pelo cliente para namespaces em clusters dedicados. | Auditoria; Desactivado | 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 fornecem criptografia dupla adicionando uma segunda camada de criptografia sobre a padrão feita com chaves gerenciadas pelo serviço. | Auditoria; Desactivado | 1.0.0 |
| A Retransmissão fluida deve usar chaves gerenciadas pelo cliente para criptografar dados em repouso | Use chaves gerenciadas pelo cliente para gerenciar a criptografia em repouso do servidor de Retransmissão fluida. Por padrão, os dados do cliente são criptografados com chaves gerenciadas pelo serviço, mas os CMKs geralmente são necessários para atender aos padrões de conformidade regulatória. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Azure Key Vault criada e de propriedade de você, com controle total e responsabilidade, incluindo rotação e gerenciamento. Saiba mais em chaves gerenciadas pelo cliente para criptografia de Retransmissão de Fluidos do Azure. | Auditoria; Desactivado | 1.0.0 |
| As contas do HPC Cache devem usar uma chave gerenciada pelo cliente para criptografia | Gerencie a criptografia em repouso do Azure HPC Cache 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 normalmente são necessárias para atender aos padrões de conformidade regulatória. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Azure Key Vault criada por você e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida chave, incluindo rotação e gerenciamento. | Auditoria; Desactivado; Negar | 2.0.0 |
| O Ambiente de Serviço de Integração dos Aplicativos Lógicos deve ser criptografado com chaves gerenciadas pelo cliente | Implante no Ambiente do Serviço de Integração para gerenciar a criptografia em repouso 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 normalmente são necessárias para atender aos padrões de conformidade regulatória. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Azure Key Vault criada por você e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida chave, incluindo rotação e gerenciamento. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os discos gerenciados devem ter criptografia dupla, com chaves gerenciadas pelo cliente e pela plataforma | Os clientes confidenciais de alta segurança que estão preocupados com o risco associado a qualquer determinado algoritmo de criptografia, implementação ou chave sendo comprometido 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 a criptografia dupla. Saiba mais na criptografia do lado do servidor dos discos gerenciados do Azure. | Auditoria; Negar; Desactivado | 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 | A exigência de um conjunto específico de conjuntos de criptografia de disco a ser usado com discos gerenciados oferece 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 na criptografia do lado do servidor dos discos gerenciados do Azure. | Auditoria; Negar; Desactivado | 2.0.0 |
| Os servidores MySQL devem usar chaves gerenciadas pelo cliente para criptografar dados inativos | Use chaves gerenciadas pelo cliente para gerenciar a criptografia em repouso de seus servidores MySQL. Por padrão, os dados são criptografados em repouso com chaves gerenciadas pelo serviço, mas as chaves gerenciadas pelo cliente normalmente são necessárias para atender aos padrões de conformidade regulatória. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Azure Key Vault criada por você e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida chave, incluindo rotação e gerenciamento. | AuditIfNotExists; Desactivado | 1.0.4 |
| O sistema operacional e os discos de dados devem ser criptografados com uma chave gerenciada pelo cliente | Use chaves gerenciadas pelo cliente para gerenciar a criptografia em repouso no conteúdo dos seus discos gerenciados. Por padrão, os dados são criptografados em repouso com chaves gerenciadas pela plataforma, mas as chaves gerenciadas pelo cliente normalmente são necessárias para atender aos padrões de conformidade regulatória. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Azure Key Vault criada por você e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida chave, incluindo rotação e gerenciamento. Saiba mais na criptografia do lado do servidor dos discos gerenciados do Azure. | Auditoria; Negar; Desactivado | 3.0.0 |
| Os servidores flexíveis do PostgreSQL devem usar chaves gerenciadas pelo cliente para criptografar dados inativos | Use chaves gerenciadas pelo cliente para gerenciar a criptografia em repouso dos servidores flexíveis do PostgreSQL. Por padrão, os dados são criptografados em repouso com chaves gerenciadas pelo serviço, mas as chaves gerenciadas pelo cliente normalmente são necessárias para atender aos padrões de conformidade regulatória. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Azure Key Vault criada por você e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida chave, incluindo rotação e gerenciamento. | Auditoria; Negar; Desactivado | 1.1.0 |
| Os servidores PostgreSQL devem usar chaves gerenciadas pelo cliente para criptografar dados inativos | Use chaves gerenciadas pelo cliente para gerenciar a criptografia em repouso de seus servidores PostgreSQL. Por padrão, os dados são criptografados em repouso com chaves gerenciadas pelo serviço, mas as chaves gerenciadas pelo cliente normalmente são necessárias para atender aos padrões de conformidade regulatória. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Azure Key Vault criada por você e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida chave, incluindo rotação e gerenciamento. | AuditIfNotExists; Desactivado | 1.0.4 |
| O Armazenamento de Filas deve usar chave gerenciada pelo cliente para criptografia | Proteja seu armazenamento de filas 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 funcionalidades adicionais para controlar a rotação da principal chave de criptografia ou para apagar dados criptograficamente. | Auditoria; Negar; Desactivado | 1.0.0 |
| As instâncias gerenciadas de SQL devem usar chaves gerenciadas pelo cliente para criptografar dados inativos | Implementar a TDE (Transparent Data Encryption) com chave própria proporciona maior transparência e controle sobre o protetor de TDE, mais segurança com um serviço externo com suporte a HSM e promoção de separação de tarefas. Essa recomendação se aplica a organizações com um requisito de conformidade relacionado. | Auditoria; Negar; Desactivado | 2.0.0 |
| Os SQL Servers devem usar chaves gerenciadas pelo cliente para criptografar dados inativos | Implementar a TDE (Transparent Data Encryption) com sua chave proporciona maior transparência e controle sobre o protetor de TDE, mais segurança com um serviço externo com suporte a HSM e promoção de separação de tarefas. Essa recomendação se aplica a organizações com um requisito de conformidade relacionado. | Auditoria; Negar; Desactivado | 2.0.1 |
| Os namespaces do Barramento de Serviço Premium devem usar uma chave gerenciada pelo cliente para criptografia | O Barramento de Serviço do Azure dá suporte à opção de criptografar dados inativos com chaves gerenciadas pela Microsoft (padrão) ou chaves gerenciadas pelo cliente. Optar por criptografar dados usando chaves gerenciadas pelo cliente permite que você atribua, gire, desabilite e revogue o acesso às chaves que o Barramento de Serviço usará para criptografar dados em seu namespace. Observe que o Barramento de Serviço dá suporte apenas à criptografia com chaves gerenciadas pelo cliente para namespaces premium. | Auditoria; Desactivado | 1.0.0 |
| Os escopos de criptografia de conta de armazenamento devem usar chaves gerenciadas pelo cliente para criptografar os dados inativos | Use as 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 Azure Key Vault criada por você e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida chave, incluindo rotação e gerenciamento. Saiba mais sobre escopos de criptografia da conta de armazenamento nos escopos de criptografia para armazenamento de Blobs. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os escopos de criptografia de conta de armazenamento devem usar criptografia dupla para os dados inativos | Habilite a criptografia de infraestrutura para criptografia em repouso em seus escopos de criptografia de conta de armazenamento para maior segurança. A criptografia de infraestrutura garante que seus dados sejam criptografados duas vezes. | Auditoria; Negar; Desactivado | 1.0.0 |
| As contas de armazenamento devem usar uma chave gerenciada pelo cliente para criptografia | Proteja sua conta de armazenamento de blobs e arquivos 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 funcionalidades adicionais para controlar a rotação da principal chave de criptografia ou para apagar dados criptograficamente. | Auditoria; Desactivado | 1.0.3 |
| O Armazenamento de Tabelas deve usar a chave gerenciada pelo cliente para criptografia | Proteja seu armazenamento de tabelas 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 funcionalidades adicionais para controlar a rotação da principal chave de criptografia ou para apagar dados criptograficamente. | Auditoria; Negar; Desactivado | 1.0.0 |
| [Preterido]: o Grupo SIM deve usar chaves gerenciadas pelo cliente para criptografar dados em repouso | Essa política foi preterida porque o provedor de recursos Microsoft.MobileNetwork foi desativado sem substituição. Recomendamos que você remova todas as atribuições dessa política e todas as referências a ela de iniciativas. Saiba mais sobre a substituição da definição de política em aka.ms/policydefdeprecation. | Auditoria; Negar; Desactivado | 1.1.0 preterido |
| [Versão prévia]: os sistemas do Azure Stack HCI devem ter volumes criptografados | Usar o BitLocker para criptografar o sistema operacional e os volumes de dados nos sistemas do Azure Stack HCI. | Auditoria; Desactivado; AuditIfNotExists | 1.0.0-preview |
DP-6: Use um processo seguro de gerenciamento de chaves
Para obter mais informações, consulte Proteção de Dados: DP-6: use um processo de gerenciamento de chave segura.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Os valores secretos nomeados do Gerenciamento de API devem ser armazenados no Azure Key Vault | Os valores nomeados são uma coleção global de pares de nome/valor em cada serviço do Gerenciamento de API. Os valores secretos podem ser armazenados como texto criptografado no Gerenciamento de API (segredos personalizados) ou referenciando segredos no Azure Key Vault. Para melhorar a segurança de Gerenciamento de API e segredos, faça referência a valores nomeados do segredo do Azure Key Vault. O Azure Key Vault dá suporte a políticas de rotação de segredo e gerenciamento de acesso granulares. | Auditoria; Desactivado; Negar | 1.0.2 |
| As contas do Azure Cosmos DB não devem exceder o número máximo de dias permitidos desde a regeneração da última chave de conta. | Regenere suas chaves no tempo especificado para manter seus dados mais protegidos. | Auditoria; Desactivado | 1.0.0 |
| As chaves do Key Vault devem ter uma data de validade | As chaves de criptografia devem ter uma data de validade definida e não ser permanentes. As chaves válidas para sempre dão a um invasor potencial mais tempo para comprometer a chave. Uma prática de segurança recomendada é definir as datas de validade em chaves de criptografia. | Auditoria; Negar; Desactivado | 1.0.2 |
| Os segredos do Key Vault devem ter uma data de validade | Os segredos devem ter uma data de validade definida e não ser permanentes. Os segredos são válidos para sempre dão a um invasor potencial mais tempo para comprometê-las. Uma prática de segurança recomendada é definir datas de validade nos segredos. | Auditoria; Negar; Desactivado | 1.0.2 |
| As chaves devem ter uma política de rotação garantindo 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 necessários para a rotação da chave após a criação. | Auditoria; Desactivado | 1.0.0 |
| As chaves devem ter o período máximo de validade especificado | Gerencie seus requisitos de conformidade organizacional especificando o período máximo em dias de validade de uma chave no cofre de chaves. | Auditoria; Negar; Desactivado | 1.0.1 |
| As chaves não devem ficar ativas por mais tempo do que o número de dias especificado | Especifique o número de dias pelos quais uma chave deve estar ativa. As chaves usadas por um longo período de tempo aumentam a probabilidade de um invasor comprometer a chave. Como uma boa prática de segurança, verifique se suas chaves não estão ativas por mais de dois anos. | Auditoria; Negar; Desactivado | 1.0.1 |
| Os segredos devem ter um número maior de dias do que o especificado até a validade | Se um segredo estiver muito próximo da validade, um atraso organizacional para fazer a rotação do segredo poderá resultar em uma interrupção. A rotação dos segredos deve ser feita em um número de dias especificado antes da validade para que haja tempo suficiente para reagir a uma falha. | Auditoria; Negar; Desactivado | 1.0.1 |
| Os segredos devem ter o período máximo de validade especificado | Gerencie seus requisitos de conformidade organizacional especificando o período máximo em dias de validade de um segredo no cofre de chaves. | Auditoria; Negar; Desactivado | 1.0.1 |
| Os segredos não devem ficar ativos por mais tempo do que o número de dias especificado | Se os seus segredos foram criados com uma data de ativação futura definida, verifique se eles não estão ativos há mais tempo do que a duração especificada. | Auditoria; Negar; Desactivado | 1.0.1 |
| As chaves da conta de armazenamento não devem expirar | Verifique se as chaves da conta de armazenamento do usuário não expiraram quando a política de expiração de chave é definida a fim de melhorar a segurança das chaves de conta com a execução de uma ação quando as chaves expiram. | Auditoria; Negar; Desactivado | 3.0.0 |
DP-7: usar um processo seguro de gerenciamento de certificados
Para obter mais informações, consulte Proteção de Dados: DP-7: use um processo seguro de gerenciamento de certificados.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Os certificados devem ter o período máximo de validade especificado | Gerenciar seus requisitos de conformidade organizacional especificando o período de tempo máximo em que um certificado permanece válido no cofre de chaves. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 2.2.1 |
| Os certificados devem ter o período máximo de validade especificado | Gerenciar seus requisitos de conformidade organizacional especificando o período de tempo máximo em que um certificado permanece válido no cofre de chaves. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 2.2.1 |
| Os certificados não devem expirar após o número de dias especificado | Gerenciar os certificados que expirarão após um número especificado de dias para verificar se a organização tem tempo suficiente para mudar de certificado antes da expiração. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 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 da chave e do repositório de certificados.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| O Azure Defender para Key Vault deve estar habilitado | O Azure Defender para Key Vault oferece uma camada adicional de proteção e inteligência de segurança ao detectar tentativas incomuns e potencialmente prejudiciais de acessar ou explorar as contas do Key Vault. | AuditIfNotExists; Desactivado | 1.0.3 |
| O Azure Key Vault deve ter o firewall habilitado ou o 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 IP público ou desabilite o acesso à rede pública para o cofre de chaves para que ele não seja 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 ao Link Privado do Azure | Auditoria; Negar; Desactivado | 3.3.0 |
| Os Azure Key Vaults devem usar um link privado | O Link Privado do Azure permite que você conecte 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 manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Com o mapeamento dos pontos de extremidade privados para o cofre de chaves, você poderá reduzir os riscos de vazamento de dados. Saiba mais sobre links privados em: Integrar o Key Vault ao Link Privado do Azure. | Auditoria; Negar; Desactivado | 1.2.1 |
| Os cofres de chaves devem ter a proteção contra exclusão habilitadas | A exclusão mal-intencionada de um cofre de chaves pode levar à perda permanente de dados. Você pode evitar a perda permanente de dados habilitando a proteção contra limpeza e a exclusão temporária. A proteção de limpeza protege você contra ataques de invasores impondo um período de retenção obrigatório para cofres de chaves de exclusão temporária. Ninguém dentro de sua organização nem a Microsoft poderá limpar os cofres de chaves durante o período de retenção de exclusão temporária. Lembre-se de que os cofres de chaves criados após 1º de setembro de 2019 têm a exclusão temporária habilitada por padrão. | Auditoria; Negar; Desactivado | 2.1.0 |
| Os cofres de chaves devem ter a exclusão temporária habilitada | A exclusão de um cofre de chaves sem a exclusão temporária habilitada permanentemente exclui todos os segredos, as chaves e os certificados armazenados no cofre de chaves. A exclusão acidental de um cofre de chaves pode levar à perda permanente de dados. A exclusão temporária permite recuperar um cofre de chaves excluído acidentalmente por um período de retenção configurável. | Auditoria; Negar; Desactivado | 3.1.0 |
| Os logs de recurso no Key Vault devem estar habilitados | Auditar a habilitação de logs de recurso. Permite recriar trilhas de atividades a serem usadas para fins de investigação quando ocorrer um incidente de segurança ou quando sua rede estiver comprometida | AuditIfNotExists; Desactivado | 5.0.0 |
DS-6: proteger o ciclo de vida da carga de trabalho
Para obter mais informações, consulte DevOps Security: 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 (alimentadas pelo Gerenciamento de Vulnerabilidades do Microsoft Defender) | A avaliação de vulnerabilidade das imagens de contêiner examina seu registro em busca de vulnerabilidades comumente conhecidas (CVEs) e fornece um relatório detalhado de vulnerabilidades 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; Desactivado | 1.0.1 |
| As imagens de contêiner em execução do Azure devem ter vulnerabilidades resolvidas (alimentadas pelo Gerenciamento de Vulnerabilidades do Microsoft Defender) | A avaliação de vulnerabilidade das imagens de contêiner examina seu registro em busca de vulnerabilidades comumente conhecidas (CVEs) e fornece um relatório detalhado de vulnerabilidades para cada imagem. Essa recomendação fornece visibilidade para as imagens vulneráveis atualmente em execução nos seus clusters do Kubernetes. Corrigir vulnerabilidades em imagens de contêiner que estão em execução no momento é fundamental para aprimorar sua postura de segurança, reduzindo de forma significativa a superfície de ataque das suas cargas de trabalho conteinerizadas. | AuditIfNotExists; Desactivado | 1.0.1 |
ES-1: Usar EDR (Detecção e Resposta de Endpoint)
Para obter mais informações, consulte Endpoint Security: ES-1: Use EDR (Detecção e Resposta de Ponto de Extremidade).
| 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 do servidor e gera recomendações de proteção, bem como alertas sobre atividades suspeitas. | AuditIfNotExists; Desactivado | 1.0.3 |
ES-2: Usar software antimalware moderno
Para obter mais informações, consulte Endpoint Security: ES-2: Use software antimalware moderno.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| O Microsoft Defender Exploit Guard deve estar habilitado nos computadores | O Microsoft Defender Exploit Guard usa o agente de Configuração de Convidado do Azure Policy. O Exploit Guard tem quatro componentes que foram projetados para bloquear dispositivos contra uma ampla variedade de vetores de ataque e comportamentos de bloqueio comumente usados em ataques de malware, permitindo que as empresas encontrem um equilíbrio entre os requisitos de produtividade e o risco de segurança enfrentados (somente Windows). | AuditIfNotExists; Desactivado | 2.0.0 |
IM-1: usar ferramentas automatizadas para monitorar anomalias
Para obter mais informações, consulte O Gerenciamento de Identidades: IM-1: use ferramentas automatizadas para monitorar anomalias.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Um administrador do Microsoft Entra deve ser provisionado para servidores PostgreSQL | Audite o provisionamento 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 dos usuários de banco de dados e de outros serviços da Microsoft | AuditIfNotExists; Desactivado | 1.0.1 |
| Um administrador do Azure Active Directory deve ser provisionado para servidores SQL | Audite o provisionamento de um administrador do Active Directory Domain Services do Azure para o seu servidor SQL para habilitar a autenticação do AD do Azure. A autenticação do Microsoft Azure Active Directory permite o gerenciamento simplificado de permissões e o gerenciamento centralizado de identidades dos usuários de banco de dados e de outros serviços da Microsoft | AuditIfNotExists; Desactivado | 1.0.0 |
| Os aplicativos do Serviço de Aplicativo devem ter métodos de autenticação local desabilitados para implantações de FTP | Desabilitar os métodos de autenticação local para implantações FTP melhora a segurança, garantindo que os Serviços de Aplicativos exijam de modo exclusivo as identidades do Microsoft Entra para autenticação. Saiba mais em: Desabilitando a autenticação básica no Serviço de Aplicativo. | AuditIfNotExists; Desactivado | 1.0.3 |
| Os aplicativos do Serviço de Aplicativo devem ter métodos de autenticação local desabilitados para implantações de sites SCM | Desabilitar os métodos de autenticação local para os sites SCM melhora a segurança, garantindo que os Serviços de Aplicativos exijam de modo exclusivo as identidades do Microsoft Entra para autenticação. Saiba mais em: Desabilitando a autenticação básica no Serviço de Aplicativo. | AuditIfNotExists; Desactivado | 1.0.3 |
| Os componentes do Application Insights devem bloquear a ingestão fora do Azure Active Directory. | Impor a ingestão de log para exigir a autenticação do Azure Active Directory evita logs não autenticados de um invasor, o que pode levar a um status incorreto, alertas falsos e logs incorretos armazenados no sistema. | Negar; Auditoria; Desactivado | 1.0.0 |
| Os recursos dos Serviços de IA do Azure devem ter o acesso de chave desabilitado (desabilitar a autenticação local) | Recomenda-se que o acesso à chave (autenticação local) seja desabilitado por segurança. O Azure OpenAI Studio, normalmente usado em desenvolvimento/teste, requer acesso a chaves e não funcionará se o acesso a chaves estiver desabilitado. Após ser desabilitado, o Microsoft Entra ID se torna o único método de acesso, o que permite a manutenção do princípio de privilégio mínimo e o controle granular. Saiba mais em: Autenticação nos serviços de IA do Azure | Auditoria; Negar; Desactivado | 1.1.0 |
| Os Clusters do Serviço de Kubernetes do Azure devem habilitar a integração do Microsoft Entra ID | A integração do Microsoft Entra ID gerenciada pelo AKS pode controlar o acesso aos clusters configurando o RBAC (controle de acesso baseado em função) do Kubernetes com base na identidade do usuário ou na associação ao grupo de diretórios. Saiba mais em: Habilitar a integração do Microsoft Entra gerenciada pelo AKS em um cluster do Serviço de Kubernetes do Azure. | Auditoria; Desactivado | 1.0.2 |
| Os Computadores do Azure Machine Learning devem ter os métodos de autenticação local desabilitados | A desativação dos métodos de autenticação local melhora a segurança, garantindo que os Computadores do Machine Learning exijam identidades do Azure Active Directory exclusivamente para autenticação. Saiba mais em: Controles de Conformidade Regulatória do Azure Policy para o Azure Machine Learning. | Auditoria; Negar; Desactivado | 2.1.0 |
| O Banco de Dados SQL do Azure deve ter a autenticação somente do Microsoft Entra habilitada | Exigir que os servidores lógicos de SQL do Azure usem a autenticação somente do Microsoft Entra. Essa política não impede que os servidores sejam criados com a autenticação local habilitada. Ela impede que a autenticação local seja habilitada nos recursos após a criação. Considere usar a iniciativa "Autenticação somente do Microsoft Entra" para exigir ambos. Saiba mais em: Criar servidor com Microsoft Entra-Only Autenticação Habilitada. | Auditoria; Negar; Desactivado | 1.0.0 |
| O Banco de Dados SQL do Azure deve ter a autenticação somente do Microsoft Entra habilitada durante a criação | Exigir que os servidores lógicos do SQL do Azure sejam criados com a autenticação somente do Microsoft Entra. Essa política não impede que a autenticação local seja reabilitada nos recursos após a criação. Considere usar a iniciativa "Autenticação somente do Microsoft Entra" para exigir ambos. Saiba mais em: Criar servidor com Microsoft Entra-Only Autenticação Habilitada. | Auditoria; Negar; Desactivado | 1.2.0 |
| A Instância Gerenciada de SQL do Azure deve ter a autenticação somente do Microsoft Entra habilitada | Exigir que a Instância Gerenciada de SQL do Azure use a autenticação somente do Microsoft Entra. Essa política não impede que instâncias gerenciadas de SQL do Azure sejam criadas com a autenticação local habilitada. Ela impede que a autenticação local seja habilitada nos recursos após a criação. Considere usar a iniciativa "Autenticação somente do Microsoft Entra" para exigir ambos. Saiba mais em: Criar servidor com Microsoft Entra-Only Autenticação Habilitada. | Auditoria; Negar; Desactivado | 1.0.0 |
| Instâncias gerenciada de SQL do Azure devem ter a autenticação somente do Microsoft Entra habilitada durante a criação | Exigir que a Instância Gerenciada de SQL do Azure seja criada com a autenticação somente do Microsoft Entra. Essa política não impede que a autenticação local seja reabilitada nos recursos após a criação. Considere usar a iniciativa "Autenticação somente do Microsoft Entra" para exigir ambos. Saiba mais em: Criar servidor com Microsoft Entra-Only Autenticação Habilitada. | Auditoria; Negar; Desactivado | 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 desabilitado por segurança. O Azure OpenAI Studio, normalmente usado em desenvolvimento/teste, requer acesso a chaves e não funcionará se o acesso a chaves estiver desabilitado. Após ser desabilitado, o Microsoft Entra ID se torna o único método de acesso, o que permite a manutenção do princípio de privilégio mínimo e o controle granular. Saiba mais em: Autenticação nos serviços de IA do Azure | DeployIfNotExists; Desactivado | 1.0.0 |
| Os registros de contêiner devem ter a conta de administrador local desabilitada. | Desabilite a conta de administrador do registro para que ela não seja acessível pelo administrador local. Desabilitar 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 Active Directory para autenticação. Saiba mais em: Opções de Autenticação do Registro de Contêiner do Azure explicadas. | Auditoria; Negar; Desactivado | 1.0.1 |
| As contas de banco de dados do Cosmos DB devem ter os métodos de autenticação local desabilitados | Desabilitar os métodos de autenticação local aprimora a segurança, garantindo que as contas de banco de dados do Cosmos DB exijam identidades do Azure Active Directory exclusivamente 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; Desactivado | 1.1.0 |
| Os clusters do Service Fabric só devem usar o Azure Active Directory para autenticação de cliente | Auditar o uso da autenticação do cliente somente por meio do Active Directory do Azure no Service Fabric | Auditoria; Negar; Desactivado | 1.1.0 |
| As contas de armazenamento devem impedir o acesso de chave compartilhada | Requisito de auditoria do Azure AD (Azure Active Directory) para autorizar solicitações para sua conta de armazenamento. Por padrão, as solicitações podem ser autorizadas com as credenciais do Azure Active Directory ou usando a chave de acesso da conta para a autorização de chave compartilhada. Desses dois tipos de autorização, o Azure AD fornece segurança superior e facilidade de uso em relação à chave compartilhada e é recomendado pela Microsoft. | Auditoria; Negar; Desactivado | 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 AD (Azure Active Directory) para autorizar solicitações para sua conta de armazenamento. Por padrão, as solicitações podem ser autorizadas com as credenciais do Azure Active Directory ou usando a chave de acesso da conta para a autorização de chave compartilhada. Desses dois tipos de autorização, o Azure AD fornece segurança superior e facilidade de uso em relação à chave compartilhada e é recomendado pela Microsoft. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os Workspaces do Synapse devem ter a autenticação somente do Microsoft Entra habilitada | Exigir que os workspaces do Synapse usem a autenticação somente do Microsoft Entra. Essa política não impede que workspaces sejam criados com a autenticação local habilitada. Ela impede que a autenticação local seja habilitada nos recursos após a criação. Considere usar a iniciativa "Autenticação somente do Microsoft Entra" para exigir ambos. Saiba mais em: Azure Synapse Analytics. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os Workspaces do Synapse devem usar apenas as identidades do Microsoft Entra para autenticação durante a criação do workspace | Exigir que workspaces do Synapse sejam criados com a autenticação somente do Microsoft Entra. Essa política não impede que a autenticação local seja reabilitada nos recursos após a criação. Considere usar a iniciativa "Autenticação somente do Microsoft Entra" para exigir ambos. Saiba mais em: Azure Synapse Analytics. | Auditoria; Negar; Desactivado | 1.2.0 |
| Os gateways de VPN devem usar somente a autenticação do Azure AD (Active Directory) para usuários de ponto a site | Desabilitar os métodos de autenticação local melhora a segurança, garantindo que os gateways de VPN usem apenas identidades do Azure Active Directory para a autenticação. Saiba mais sobre a autenticação do Azure AD na configuração do gateway de VPN P2S para autenticação do Microsoft Entra ID | Auditoria; Negar; Desactivado | 1.0.0 |
| O servidor flexível do MySQL do Azure deve ter a Autenticação Somente Do Microsoft Entra 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 PostgreSQL do Azure possa ser acessado exclusivamente pelas identidades do Microsoft Entra. | Auditoria; Desactivado | 1.0.0-preview |
IM-2: detectar e analisar incidentes de segurança
Para obter mais informações, consulte o Gerenciamento de Identidades: IM-2: detectar e analisar incidentes de segurança.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Os usuários devem autenticar com autenticação multifator para criar ou atualizar recursos | Essa definição de política bloqueia as operações de criação e atualização de recursos quando o chamador não é autenticado via MFA. Para obter mais informações, visite o Plano para MFA (autenticação multifator) obrigatória do Microsoft Entra. | Auditoria; Negar; Desactivado | 1.0.1 |
IM-3: aprimorar processos de resposta a incidentes
Para obter mais informações, consulte O Gerenciamento de Identidades: IM-3: aprimorar os processos de resposta a incidentes.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Os slots de aplicativos do Serviço de Aplicativo devem usar a identidade gerenciada | Usar uma identidade gerenciada para uma segurança de autenticação aprimorada | AuditIfNotExists; Desactivado | 1.0.0 |
| Os aplicativos do Serviço de Aplicativo devem usar a identidade gerenciada | Usar uma identidade gerenciada para uma segurança de autenticação aprimorada | AuditIfNotExists; Desactivado | 3.0.0 |
| A Conta de Automação deve ter a Identidade Gerenciada | Use Identidades Gerenciadas como o método recomendado para autenticação com recursos do Azure 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; Desactivado | 1.0.0 |
| Os serviços vinculados do Azure Data Factory devem usar a autenticação de identidade gerenciada atribuída pelo sistema quando houver suporte | O uso da identidade gerenciada atribuída pelo sistema ao se comunicar com armazenamentos de dados por meio de serviços vinculados evita o uso de credenciais menos protegidas, como senhas ou cadeias de conexão. | Auditoria; Negar; Desactivado | 2.1.0 |
| Os workspaces do Azure Machine Learning devem usar a identidade gerenciada atribuída pelo usuário | Manange acesso ao workspace do Azure ML e recursos associados, Registro de Contêiner do Azure, KeyVault, Armazenamento e App Insights usando a identidade gerenciada atribuída pelo usuário. Por padrão, a identidade gerenciada atribuída pelo sistema é usada pelo workspace do Azure ML para acessar os recursos associados. A identidade gerenciada e atribuída pelo usuário permite criar uma identidade como um recurso do Azure, bem como e manter o ciclo de vida dela. Saiba mais em Configurar a autenticação entre o Azure Machine Learning e outros serviços. | Auditoria; Negar; Desactivado | 1.0.0 |
| As contas dos Serviços Cognitivos devem usar uma identidade gerenciada | A atribuição de uma identidade gerenciada à sua conta dos Serviços Cognitivos ajuda a garantir a autenticação segura. Essa identidade é usada por essa conta dos Serviços Cognitivos para se comunicar de modo seguro com outros serviços do Azure, como o Azure Key Vault, sem a necessidade de gerenciamento de credenciais. | Auditoria; Negar; Desactivado | 1.0.0 |
| O recurso do serviço de comunicação deve usar uma identidade gerenciada | Atribuir uma identidade gerenciada ao 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; Desactivado | 1.0.0 |
| Os aplicativos de funções devem usar a identidade gerenciada | Usar uma identidade gerenciada para uma segurança de autenticação aprimorada | AuditIfNotExists; Desactivado | 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 dê suporte à autenticação do Azure AD | Auditoria; Negar; Desactivado | 1.0.1 |
| O trabalho do Stream Analytics deve usar a identidade gerenciada para autenticar pontos de extremidade | Verifique se os trabalhos do Stream Analytics só se conectam a pontos de extremidade usando a autenticação de identidade gerenciada. | Negar; Desactivado; Auditoria | 1.0.0 |
| A extensão de Configuração de Convidado das máquinas virtuais deve ser implantada com a identidade gerenciada atribuída ao sistema | A extensão de configuração de convidado exige uma identidade gerenciada atribuída ao sistema. As máquinas virtuais do Azure no escopo desta política não estarão em conformidade quando tiverem a extensão de Configuração de Convidado instalada, mas não tiverem uma identidade gerenciada atribuída ao sistema. Saiba mais em Entender a Configuração do Azure Machine | AuditIfNotExists; Desactivado | 1.0.1 |
| [Versão prévia]: uma identidade gerenciada deve ser habilitada em seus computadores | Os recursos gerenciados pelo Gerenciamento Automatizado devem ter uma identidade gerenciada. | Auditoria; Desactivado | 1.0.0-preview |
| [Versão prévia]: As credenciais federadas de identidade gerenciada do Kubernetes do Azure devem ser de fontes confiáveis | Essa política limita a federeação com clusters do Kubernetes do Azure para apenas clusters de locatários aprovados, regiões aprovadas e uma lista de exceções específica de clusters adicionais. | Auditoria; Desactivado; Negar | 1.0.0-preview |
| [Versão prévia]: As credenciais federadas de identidade gerenciada do GitHub devem ser de proprietários de repositório confiáveis | Essa política limita a federação com repositórios do GitHub apenas para proprietários de repositório aprovados. | Auditoria; Desactivado; Negar | 1.0.1-preview |
| [Versão prévia]: As credenciais federadas de identidade gerenciada devem ser de tipos de emissor permitidos | Essa 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; Desactivado; Negar | 1.0.0-preview |
IM-4: habilitar recursos de detecção de ameaças e registro em log
Para obter mais informações, consulte o Gerenciamento de Identidades: IM-4: habilitar recursos de detecção de ameaças e registro em log.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| As chamadas do 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 aos back-ends do Service Fabric. | Auditoria; Desactivado; Negar | 1.0.1 |
| As chamadas do 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 de back-end para todas as chamadas à API. Habilite a validação da impressão digital e do nome do certificado SSL. | Auditoria; Desactivado; Negar | 1.0.2 |
| Os pontos de extremidade de API no Gerenciamento de API 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. Às vezes, os mecanismos de autenticação são implementados incorretamente ou estão ausentes. 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 interrompida aqui: recomendações para atenuar as 10 principais ameaças de segurança da API OWASP usando o Gerenciamento de API | AuditIfNotExists; Desactivado | 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 do TLS como 1.2 ou mais recente aprimora a segurança garantindo que seu Banco de Dados SQL do Azure só possa ser acessado de clientes que usam o TLS 1.2 ou mais recente. O uso de versões do TLS inferiores à 1.2 não é recomendado, pois elas têm vulnerabilidades de segurança bem documentadas. | Auditoria; Desactivado; Negar | 2.0.0 |
IM-6: Usar resposta automatizada a incidentes
Para obter mais informações, consulte O Gerenciamento de Identidades: IM-6: Usar resposta automatizada a incidentes.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| A autenticação para computadores Linux deve exigir chaves SSH | Embora o SSH em si forneça uma conexão criptografada, usar 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 por SSH é com um par de chaves pública-privada, também conhecido como chaves SSH. Saiba mais: Etapas detalhadas: criar e gerenciar chaves SSH para autenticação em uma VM linux no Azure. | AuditIfNotExists; Desactivado | 3.2.0 |
IM-8: restringir o acesso a portas de gerenciamento
Para obter mais informações, consulte O Gerenciamento de Identidades: IM-8: restringir o acesso às portas de gerenciamento.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Os valores secretos nomeados do Gerenciamento de API devem ser armazenados no Azure Key Vault | Os valores nomeados são uma coleção global de pares de nome/valor em cada serviço do Gerenciamento de API. Os valores secretos podem ser armazenados como texto criptografado no Gerenciamento de API (segredos personalizados) ou referenciando segredos no Azure Key Vault. Para melhorar a segurança de Gerenciamento de API e segredos, faça referência a valores nomeados do segredo do Azure Key Vault. O Azure Key Vault dá suporte a políticas de rotação de segredo e gerenciamento de acesso granulares. | Auditoria; Desactivado; Negar | 1.0.2 |
| Os computadores devem ter as descobertas secretas resolvidas | Audita máquinas virtuais para detectar se elas contêm descobertas secretas das soluções de verificação do segredo em suas máquinas virtuais. | AuditIfNotExists; Desactivado | 1.0.2 |
IR-2: Preparação – notificação de incidente de instalação
Para obter mais informações, consulte Resposta a incidentes: IR-2: Preparação – notificação de incidente de instalação.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| A notificação por email para alertas de severidade alta deve ser habilitada | Para que as pessoas relevantes em sua organização sejam notificadas quando houver uma potencial violação de segurança em uma das suas assinaturas, habilite notificações por email para alertas de severidade alta na Central de Segurança. | AuditIfNotExists; Desactivado | 1.2.0 |
| A notificação por email para o proprietário da assinatura para alertas de severidade alta deve ser habilitada | Para que os proprietários de assinatura sejam notificados quando houver uma potencial violação de segurança na assinatura deles, defina que notificações para alertas de severidade alta sejam enviadas por email para os proprietários da assinatura na Central de Segurança. | AuditIfNotExists; Desactivado | 2.1.0 |
| As assinaturas devem ter um endereço de email de contato para problemas de segurança | Para que as pessoas relevantes em sua organização sejam notificadas quando houver uma potencial violação de segurança em uma das suas assinaturas, defina um contato de segurança para receber notificações por email da Central de Segurança. | AuditIfNotExists; Desactivado | 1.0.1 |
IR-3: detecção e análise – criar incidentes com base em alertas de alta qualidade
Para obter mais informações, consulte Resposta a incidentes: IR-3: detecção e análise – crie incidentes com base em alertas de alta qualidade.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| O Azure Defender para o Serviço de Aplicativo deve estar habilitado | O Azure Defender para o Serviço de Aplicativo utiliza a escala da nuvem e a visibilidade que o Azure tem como um provedor de nuvem para monitorar ataques comuns aos aplicativos Web. | AuditIfNotExists; Desactivado | 1.0.3 |
| O Azure Defender para servidores do Banco de Dados SQL do Azure deve estar habilitado | O Azure Defender para SQL oferece funcionalidade para expor e reduzir possíveis vulnerabilidades de banco de dados, detectar atividades anômalas que podem indicar ameaças aos Bancos de Dados SQL e descobrir e classificar dados confidenciais. | AuditIfNotExists; Desactivado | 1.0.2 |
| O Azure Defender para Key Vault deve estar habilitado | O Azure Defender para Key Vault oferece uma camada adicional de proteção e inteligência de segurança ao detectar tentativas incomuns e potencialmente prejudiciais de acessar ou explorar as contas do Key Vault. | AuditIfNotExists; Desactivado | 1.0.3 |
| O Azure Defender para Resource Manager deve ser habilitado | O Azure Defender para o Resource Manager monitora de modo automático todas as operações de gerenciamento de recursos executadas em sua organização. O Azure Defender detecta ameaças e emite alertas sobre atividades suspeitas. Saiba mais sobre os recursos do Azure Defender para Resource Manager no Microsoft Defender para Resource Manager – Benefícios e Recursos . Habilitar este plano do Azure Defender resultará em determinados encargos. 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 para Nuvem . | AuditIfNotExists; Desactivado | 1.0.0 |
| O Azure Defender para servidores SQL em computadores deve estar habilitado | O Azure Defender para SQL oferece funcionalidade para expor e reduzir possíveis vulnerabilidades de banco de dados, detectar atividades anômalas que podem indicar ameaças aos Bancos de Dados SQL e descobrir e classificar dados confidenciais. | AuditIfNotExists; Desactivado | 1.0.2 |
| O Azure Defender para SQL deve ser habilitado para servidores SQL do Azure desprotegidos | Auditar servidores SQL sem Segurança de Dados Avançada | AuditIfNotExists; Desactivado | 2.0.1 |
| O Azure Defender para SQL deve ser habilitado para servidor flexíveis do MySQL desprotegidos | Auditar servidores flexíveis do MySQL sem Segurança de Dados Avançada | AuditIfNotExists; Desactivado | 1.0.0 |
| O Azure Defender para SQL deve ser habilitado para servidores flexíveis do PostgreSQL desprotegidos | Auditar os servidores flexíveis do PostgreSQL sem Segurança de Dados Avançada | AuditIfNotExists; Desactivado | 1.0.0 |
| O Azure Defender para SQL deve ser habilitado para Instâncias Gerenciadas de SQL desprotegidas | Audite cada Instância Gerenciada de SQL sem a segurança de dados avançada. | AuditIfNotExists; Desactivado | 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 detecta atividades anômalas, indicando tentativas incomuns e possivelmente prejudiciais de acesso ou exploração de bancos de dados. Saiba mais sobre os recursos do Azure Defender para bancos de dados relacionais de software livre em visão geral do Defender para bancos de dados relacionais do Open-Source. Importante: a habilitação deste plano resultará em encargos de proteção de 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 para Nuvem | AuditIfNotExists; Desactivado | 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 do servidor e gera recomendações de proteção, bem como alertas sobre atividades suspeitas. | AuditIfNotExists; Desactivado | 1.0.3 |
| O GPSN do Microsoft Defender deve estar habilitado | O GPSN (gerenciamento da postura de segurança na nuvem) do Defender oferece funcionalidades de postura aprimoradas e um novo grafo de segurança de nuvem inteligente para ajudar a identificar, priorizar e reduzir riscos. O GPSN do Defender está disponível além das funcionalidades básicas gratuitas de postura de segurança ativadas por padrão no Defender para Nuvem. | AuditIfNotExists; Desactivado | 1.0.0 |
| O Microsoft Defender para APIs deve estar habilitado | O Microsoft Defender para APIs traz uma nova cobertura de descoberta, proteção, detecção e resposta para monitorar ataques comuns e configurações incorretas de segurança baseados em API. | AuditIfNotExists; Desactivado | 1.0.3 |
| O Microsoft Defender para Contêineres deve estar habilitado | O Microsoft Defender para Contêineres fornece proteção, avaliação de vulnerabilidades e proteções em tempo de execução para seus ambientes Kubernetes do Azure, híbridos e de várias nuvens. | AuditIfNotExists; Desactivado | 1.0.0 |
| O Microsoft Defender para SQL deve ser habilitado nos workspaces do Azure Synapse desprotegidos | Habilite o Defender para SQL para proteger os workspaces do Azure Synapse. O Defender para SQL monitora o SQL do Synapse para detectar atividades anômalas que indiquem tentativas incomuns e possivelmente prejudiciais de acessar ou explorar bancos de dados. | AuditIfNotExists; Desactivado | 1.0.0 |
| O status do Microsoft Defender para SQL deve ser protegido para SQL Servers habilitados para Arc | O Microsoft Defender para SQL oferece funcionalidade para expor e reduzir possíveis vulnerabilidades de banco de dados, detectar atividades anômalas que podem indicar ameaças aos 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, no computador, no workspace e no SQL Server para garantir a proteção ativa. | Auditoria; Desactivado | 1.1.0 |
| O Microsoft Defender para Armazenamento deve estar habilitado | O Microsoft Defender para Armazenamento detecta 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 dados corrompidos. O novo plano do Defender para Armazenamento inclui Verificação de Malware e Detecção de Ameaças a Dados Confidenciais. Este plano também fornece uma estrutura de preços previsível (por conta de armazenamento) para controle da cobertura e dos custos. | AuditIfNotExists; Desactivado | 1.0.0 |
| O provisionamento automático direcionado ao SQL Server deve ser habilitado para servidores SQL no plano de computadores | Para garantir que as VMs do SQL e os SQL Servers habilitados para Arc estejam protegidos, verifique se o Agente de Monitoramento do Azure direcionado ao SQL está configurado para implantar automaticamente. Isso também é necessário se você já configurou o provisionamento automático do Microsoft Monitoring Agent, pois esse componente está sendo preterido. Saiba mais: Migrar para o Defender para SQL em computadores usando AMA | AuditIfNotExists; Desactivado | 1.0.0 |
IR-4: detecção e análise – investigar um incidente
Para obter mais informações, consulte Resposta a incidentes: IR-4: detecção e análise – investigar um incidente.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| O Observador de Rede deve ser habilitado | O Observador de Rede é um serviço regional que permite monitorar e diagnosticar as condições em um nível do cenário da rede em, para e a partir do Azure. O monitoramento de nível do cenário permite diagnosticar problemas em um modo de exibição de nível de rede de ponta a ponta. É necessário ter um grupo de recursos do Observador de Rede a ser criado em todas as regiões em que uma rede virtual está presente. Um alerta será habilitado se um grupo de recursos do Observador de Rede não estiver disponível em uma região específica. | AuditIfNotExists; Desactivado | 3.0.0 |
IR-5: Detecção e análise – priorizar incidentes
Para obter mais informações, consulte Resposta a incidentes: IR-5: detecção e análise – priorize incidentes.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| O Azure Defender para o Serviço de Aplicativo deve estar habilitado | O Azure Defender para o Serviço de Aplicativo utiliza a escala da nuvem e a visibilidade que o Azure tem como um provedor de nuvem para monitorar ataques comuns aos aplicativos Web. | AuditIfNotExists; Desactivado | 1.0.3 |
| O Azure Defender para servidores do Banco de Dados SQL do Azure deve estar habilitado | O Azure Defender para SQL oferece funcionalidade para expor e reduzir possíveis vulnerabilidades de banco de dados, detectar atividades anômalas que podem indicar ameaças aos Bancos de Dados SQL e descobrir e classificar dados confidenciais. | AuditIfNotExists; Desactivado | 1.0.2 |
| O Azure Defender para Key Vault deve estar habilitado | O Azure Defender para Key Vault oferece uma camada adicional de proteção e inteligência de segurança ao detectar tentativas incomuns e potencialmente prejudiciais de acessar ou explorar as contas do Key Vault. | AuditIfNotExists; Desactivado | 1.0.3 |
| O Azure Defender para Resource Manager deve ser habilitado | O Azure Defender para o Resource Manager monitora de modo automático todas as operações de gerenciamento de recursos executadas em sua organização. O Azure Defender detecta ameaças e emite alertas sobre atividades suspeitas. Saiba mais sobre os recursos do Azure Defender para Resource Manager no Microsoft Defender para Resource Manager – Benefícios e Recursos . Habilitar este plano do Azure Defender resultará em determinados encargos. 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 para Nuvem . | AuditIfNotExists; Desactivado | 1.0.0 |
| O Azure Defender para servidores SQL em computadores deve estar habilitado | O Azure Defender para SQL oferece funcionalidade para expor e reduzir possíveis vulnerabilidades de banco de dados, detectar atividades anômalas que podem indicar ameaças aos Bancos de Dados SQL e descobrir e classificar dados confidenciais. | AuditIfNotExists; Desactivado | 1.0.2 |
| O Azure Defender para SQL deve ser habilitado para servidores SQL do Azure desprotegidos | Auditar servidores SQL sem Segurança de Dados Avançada | AuditIfNotExists; Desactivado | 2.0.1 |
| O Azure Defender para SQL deve ser habilitado para servidor flexíveis do MySQL desprotegidos | Auditar servidores flexíveis do MySQL sem Segurança de Dados Avançada | AuditIfNotExists; Desactivado | 1.0.0 |
| O Azure Defender para SQL deve ser habilitado para servidores flexíveis do PostgreSQL desprotegidos | Auditar os servidores flexíveis do PostgreSQL sem Segurança de Dados Avançada | AuditIfNotExists; Desactivado | 1.0.0 |
| O Azure Defender para SQL deve ser habilitado para Instâncias Gerenciadas de SQL desprotegidas | Audite cada Instância Gerenciada de SQL sem a segurança de dados avançada. | AuditIfNotExists; Desactivado | 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 detecta atividades anômalas, indicando tentativas incomuns e possivelmente prejudiciais de acesso ou exploração de bancos de dados. Saiba mais sobre os recursos do Azure Defender para bancos de dados relacionais de software livre em visão geral do Defender para bancos de dados relacionais do Open-Source. Importante: a habilitação deste plano resultará em encargos de proteção de 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 para Nuvem | AuditIfNotExists; Desactivado | 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 do servidor e gera recomendações de proteção, bem como alertas sobre atividades suspeitas. | AuditIfNotExists; Desactivado | 1.0.3 |
| O GPSN do Microsoft Defender deve estar habilitado | O GPSN (gerenciamento da postura de segurança na nuvem) do Defender oferece funcionalidades de postura aprimoradas e um novo grafo de segurança de nuvem inteligente para ajudar a identificar, priorizar e reduzir riscos. O GPSN do Defender está disponível além das funcionalidades básicas gratuitas de postura de segurança ativadas por padrão no Defender para Nuvem. | AuditIfNotExists; Desactivado | 1.0.0 |
| O Microsoft Defender para APIs deve estar habilitado | O Microsoft Defender para APIs traz uma nova cobertura de descoberta, proteção, detecção e resposta para monitorar ataques comuns e configurações incorretas de segurança baseados em API. | AuditIfNotExists; Desactivado | 1.0.3 |
| O Microsoft Defender para Contêineres deve estar habilitado | O Microsoft Defender para Contêineres fornece proteção, avaliação de vulnerabilidades e proteções em tempo de execução para seus ambientes Kubernetes do Azure, híbridos e de várias nuvens. | AuditIfNotExists; Desactivado | 1.0.0 |
| O Microsoft Defender para SQL deve ser habilitado nos workspaces do Azure Synapse desprotegidos | Habilite o Defender para SQL para proteger os workspaces do Azure Synapse. O Defender para SQL monitora o SQL do Synapse para detectar atividades anômalas que indiquem tentativas incomuns e possivelmente prejudiciais de acessar ou explorar bancos de dados. | AuditIfNotExists; Desactivado | 1.0.0 |
| O status do Microsoft Defender para SQL deve ser protegido para SQL Servers habilitados para Arc | O Microsoft Defender para SQL oferece funcionalidade para expor e reduzir possíveis vulnerabilidades de banco de dados, detectar atividades anômalas que podem indicar ameaças aos 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, no computador, no workspace e no SQL Server para garantir a proteção ativa. | Auditoria; Desactivado | 1.1.0 |
| O Microsoft Defender para Armazenamento deve estar habilitado | O Microsoft Defender para Armazenamento detecta 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 dados corrompidos. O novo plano do Defender para Armazenamento inclui Verificação de Malware e Detecção de Ameaças a Dados Confidenciais. Este plano também fornece uma estrutura de preços previsível (por conta de armazenamento) para controle da cobertura e dos custos. | AuditIfNotExists; Desactivado | 1.0.0 |
| O provisionamento automático direcionado ao SQL Server deve ser habilitado para servidores SQL no plano de computadores | Para garantir que as VMs do SQL e os SQL Servers habilitados para Arc estejam protegidos, verifique se o Agente de Monitoramento do Azure direcionado ao SQL está configurado para implantar automaticamente. Isso também é necessário se você já configurou o provisionamento automático do Microsoft Monitoring Agent, pois esse componente está sendo preterido. Saiba mais: Migrar para o Defender para SQL em computadores usando AMA | AuditIfNotExists; Desactivado | 1.0.0 |
LT-1: habilitar recursos de detecção de ameaças
Para obter mais informações, consulte Registro em log e detecção de ameaças: LT-1: habilitar recursos de detecção de ameaças.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| O Azure Defender para o Serviço de Aplicativo deve estar habilitado | O Azure Defender para o Serviço de Aplicativo utiliza a escala da nuvem e a visibilidade que o Azure tem como um provedor de nuvem para monitorar ataques comuns aos aplicativos Web. | AuditIfNotExists; Desactivado | 1.0.3 |
| O Azure Defender para servidores do Banco de Dados SQL do Azure deve estar habilitado | O Azure Defender para SQL oferece funcionalidade para expor e reduzir possíveis vulnerabilidades de banco de dados, detectar atividades anômalas que podem indicar ameaças aos Bancos de Dados SQL e descobrir e classificar dados confidenciais. | AuditIfNotExists; Desactivado | 1.0.2 |
| O Azure Defender para Key Vault deve estar habilitado | O Azure Defender para Key Vault oferece uma camada adicional de proteção e inteligência de segurança ao detectar tentativas incomuns e potencialmente prejudiciais de acessar ou explorar as contas do Key Vault. | AuditIfNotExists; Desactivado | 1.0.3 |
| O Azure Defender para Resource Manager deve ser habilitado | O Azure Defender para o Resource Manager monitora de modo automático todas as operações de gerenciamento de recursos executadas em sua organização. O Azure Defender detecta ameaças e emite alertas sobre atividades suspeitas. Saiba mais sobre os recursos do Azure Defender para Resource Manager no Microsoft Defender para Resource Manager – Benefícios e Recursos . Habilitar este plano do Azure Defender resultará em determinados encargos. 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 para Nuvem . | AuditIfNotExists; Desactivado | 1.0.0 |
| O Azure Defender para servidores SQL em computadores deve estar habilitado | O Azure Defender para SQL oferece funcionalidade para expor e reduzir possíveis vulnerabilidades de banco de dados, detectar atividades anômalas que podem indicar ameaças aos Bancos de Dados SQL e descobrir e classificar dados confidenciais. | AuditIfNotExists; Desactivado | 1.0.2 |
| O Azure Defender para SQL deve ser habilitado para servidores SQL do Azure desprotegidos | Auditar servidores SQL sem Segurança de Dados Avançada | AuditIfNotExists; Desactivado | 2.0.1 |
| O Azure Defender para SQL deve ser habilitado para servidor flexíveis do MySQL desprotegidos | Auditar servidores flexíveis do MySQL sem Segurança de Dados Avançada | AuditIfNotExists; Desactivado | 1.0.0 |
| O Azure Defender para SQL deve ser habilitado para servidores flexíveis do PostgreSQL desprotegidos | Auditar os servidores flexíveis do PostgreSQL sem Segurança de Dados Avançada | AuditIfNotExists; Desactivado | 1.0.0 |
| O Azure Defender para SQL deve ser habilitado para Instâncias Gerenciadas de SQL desprotegidas | Audite cada Instância Gerenciada de SQL sem a segurança de dados avançada. | AuditIfNotExists; Desactivado | 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 detecta atividades anômalas, indicando tentativas incomuns e possivelmente prejudiciais de acesso ou exploração de bancos de dados. Saiba mais sobre os recursos do Azure Defender para bancos de dados relacionais de software livre em visão geral do Defender para bancos de dados relacionais do Open-Source. Importante: a habilitação deste plano resultará em encargos de proteção de 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 para Nuvem | AuditIfNotExists; Desactivado | 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 do servidor e gera recomendações de proteção, bem como alertas sobre atividades suspeitas. | AuditIfNotExists; Desactivado | 1.0.3 |
| Os clusters de Serviço de Kubernetes do Azure devem ter o perfil do Defender habilitado | O Microsoft Defender para Contêineres fornece recursos de segurança para Kubernetes nativos de nuvem incluindo proteção de ambiente, proteção de cargas de trabalho e de tempo de execução. Quando você habilita o SecurityProfile.AzureDefender em seu cluster do Serviço de Kubernetes do Azure, um agente é implantado no cluster para coletar dados de eventos de segurança. Saiba mais sobre o Microsoft Defender para Contêineres em Gerenciar recomendações do MCSB no Defender para Nuvem | Auditoria; Desactivado | 2.0.1 |
| O GPSN do Microsoft Defender deve estar habilitado | O GPSN (gerenciamento da postura de segurança na nuvem) do Defender oferece funcionalidades de postura aprimoradas e um novo grafo de segurança de nuvem inteligente para ajudar a identificar, priorizar e reduzir riscos. O GPSN do Defender está disponível além das funcionalidades básicas gratuitas de postura de segurança ativadas por padrão no Defender para Nuvem. | AuditIfNotExists; Desactivado | 1.0.0 |
| O Microsoft Defender para APIs deve estar habilitado | O Microsoft Defender para APIs traz uma nova cobertura de descoberta, proteção, detecção e resposta para monitorar ataques comuns e configurações incorretas de segurança baseados em API. | AuditIfNotExists; Desactivado | 1.0.3 |
| O Microsoft Defender para Contêineres deve estar habilitado | O Microsoft Defender para Contêineres fornece proteção, avaliação de vulnerabilidades e proteções em tempo de execução para seus ambientes Kubernetes do Azure, híbridos e de várias nuvens. | AuditIfNotExists; Desactivado | 1.0.0 |
| O Microsoft Defender para SQL deve ser habilitado nos workspaces do Azure Synapse desprotegidos | Habilite o Defender para SQL para proteger os workspaces do Azure Synapse. O Defender para SQL monitora o SQL do Synapse para detectar atividades anômalas que indiquem tentativas incomuns e possivelmente prejudiciais de acessar ou explorar bancos de dados. | AuditIfNotExists; Desactivado | 1.0.0 |
| O status do Microsoft Defender para SQL deve ser protegido para SQL Servers habilitados para Arc | O Microsoft Defender para SQL oferece funcionalidade para expor e reduzir possíveis vulnerabilidades de banco de dados, detectar atividades anômalas que podem indicar ameaças aos 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, no computador, no workspace e no SQL Server para garantir a proteção ativa. | Auditoria; Desactivado | 1.1.0 |
| O Microsoft Defender para Armazenamento deve estar habilitado | O Microsoft Defender para Armazenamento detecta 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 dados corrompidos. O novo plano do Defender para Armazenamento inclui Verificação de Malware e Detecção de Ameaças a Dados Confidenciais. Este plano também fornece uma estrutura de preços previsível (por conta de armazenamento) para controle da cobertura e dos custos. | AuditIfNotExists; Desactivado | 1.0.0 |
| O provisionamento automático direcionado ao SQL Server deve ser habilitado para servidores SQL no plano de computadores | Para garantir que as VMs do SQL e os SQL Servers habilitados para Arc estejam protegidos, verifique se o Agente de Monitoramento do Azure direcionado ao SQL está configurado para implantar automaticamente. Isso também é necessário se você já configurou o provisionamento automático do Microsoft Monitoring Agent, pois esse componente está sendo preterido. Saiba mais: Migrar para o Defender para SQL em computadores usando AMA | AuditIfNotExists; Desactivado | 1.0.0 |
| O Microsoft Defender Exploit Guard deve estar habilitado nos computadores | O Microsoft Defender Exploit Guard usa o agente de Configuração de Convidado do Azure Policy. O Exploit Guard tem quatro componentes que foram projetados para bloquear dispositivos contra uma ampla variedade de vetores de ataque e comportamentos de bloqueio comumente usados em ataques de malware, permitindo que as empresas encontrem um equilíbrio entre os requisitos de produtividade e o risco de segurança enfrentados (somente Windows). | AuditIfNotExists; Desactivado | 2.0.0 |
| [Versão prévia]: os clusters do Kubernetes habilitados para Azure Arc devem ter a extensão do Microsoft Defender para Nuvem instalada | A extensão do Microsoft Defender para Nuvem no Azure Arc oferece proteção contra ameaças para os 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 para Kubernetes na nuvem para análise posterior. Saiba mais em Classificação segura no Defender para Nuvem. | AuditIfNotExists; Desactivado | 6.0.0-preview |
LT-2: habilitar a detecção de ameaças para gerenciamento de identidade e acesso
Para obter mais informações, consulte Registro em log e detecção de ameaças: LT-2: habilitar a detecção de ameaças para gerenciamento de identidade e acesso.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| O Azure Defender para o Serviço de Aplicativo deve estar habilitado | O Azure Defender para o Serviço de Aplicativo utiliza a escala da nuvem e a visibilidade que o Azure tem como um provedor de nuvem para monitorar ataques comuns aos aplicativos Web. | AuditIfNotExists; Desactivado | 1.0.3 |
| O Azure Defender para servidores do Banco de Dados SQL do Azure deve estar habilitado | O Azure Defender para SQL oferece funcionalidade para expor e reduzir possíveis vulnerabilidades de banco de dados, detectar atividades anômalas que podem indicar ameaças aos Bancos de Dados SQL e descobrir e classificar dados confidenciais. | AuditIfNotExists; Desactivado | 1.0.2 |
| O Azure Defender para Key Vault deve estar habilitado | O Azure Defender para Key Vault oferece uma camada adicional de proteção e inteligência de segurança ao detectar tentativas incomuns e potencialmente prejudiciais de acessar ou explorar as contas do Key Vault. | AuditIfNotExists; Desactivado | 1.0.3 |
| O Azure Defender para Resource Manager deve ser habilitado | O Azure Defender para o Resource Manager monitora de modo automático todas as operações de gerenciamento de recursos executadas em sua organização. O Azure Defender detecta ameaças e emite alertas sobre atividades suspeitas. Saiba mais sobre os recursos do Azure Defender para Resource Manager no Microsoft Defender para Resource Manager – Benefícios e Recursos . Habilitar este plano do Azure Defender resultará em determinados encargos. 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 para Nuvem . | AuditIfNotExists; Desactivado | 1.0.0 |
| O Azure Defender para servidores SQL em computadores deve estar habilitado | O Azure Defender para SQL oferece funcionalidade para expor e reduzir possíveis vulnerabilidades de banco de dados, detectar atividades anômalas que podem indicar ameaças aos Bancos de Dados SQL e descobrir e classificar dados confidenciais. | AuditIfNotExists; Desactivado | 1.0.2 |
| O Azure Defender para SQL deve ser habilitado para servidores SQL do Azure desprotegidos | Auditar servidores SQL sem Segurança de Dados Avançada | AuditIfNotExists; Desactivado | 2.0.1 |
| O Azure Defender para SQL deve ser habilitado para servidor flexíveis do MySQL desprotegidos | Auditar servidores flexíveis do MySQL sem Segurança de Dados Avançada | AuditIfNotExists; Desactivado | 1.0.0 |
| O Azure Defender para SQL deve ser habilitado para servidores flexíveis do PostgreSQL desprotegidos | Auditar os servidores flexíveis do PostgreSQL sem Segurança de Dados Avançada | AuditIfNotExists; Desactivado | 1.0.0 |
| O Azure Defender para SQL deve ser habilitado para Instâncias Gerenciadas de SQL desprotegidas | Audite cada Instância Gerenciada de SQL sem a segurança de dados avançada. | AuditIfNotExists; Desactivado | 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 detecta atividades anômalas, indicando tentativas incomuns e possivelmente prejudiciais de acesso ou exploração de bancos de dados. Saiba mais sobre os recursos do Azure Defender para bancos de dados relacionais de software livre em visão geral do Defender para bancos de dados relacionais do Open-Source. Importante: a habilitação deste plano resultará em encargos de proteção de 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 para Nuvem | AuditIfNotExists; Desactivado | 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 do servidor e gera recomendações de proteção, bem como alertas sobre atividades suspeitas. | AuditIfNotExists; Desactivado | 1.0.3 |
| Os clusters de Serviço de Kubernetes do Azure devem ter o perfil do Defender habilitado | O Microsoft Defender para Contêineres fornece recursos de segurança para Kubernetes nativos de nuvem incluindo proteção de ambiente, proteção de cargas de trabalho e de tempo de execução. Quando você habilita o SecurityProfile.AzureDefender em seu cluster do Serviço de Kubernetes do Azure, um agente é implantado no cluster para coletar dados de eventos de segurança. Saiba mais sobre o Microsoft Defender para Contêineres em Gerenciar recomendações do MCSB no Defender para Nuvem | Auditoria; Desactivado | 2.0.1 |
| O GPSN do Microsoft Defender deve estar habilitado | O GPSN (gerenciamento da postura de segurança na nuvem) do Defender oferece funcionalidades de postura aprimoradas e um novo grafo de segurança de nuvem inteligente para ajudar a identificar, priorizar e reduzir riscos. O GPSN do Defender está disponível além das funcionalidades básicas gratuitas de postura de segurança ativadas por padrão no Defender para Nuvem. | AuditIfNotExists; Desactivado | 1.0.0 |
| O Microsoft Defender para Contêineres deve estar habilitado | O Microsoft Defender para Contêineres fornece proteção, avaliação de vulnerabilidades e proteções em tempo de execução para seus ambientes Kubernetes do Azure, híbridos e de várias nuvens. | AuditIfNotExists; Desactivado | 1.0.0 |
| O Microsoft Defender para SQL deve ser habilitado nos workspaces do Azure Synapse desprotegidos | Habilite o Defender para SQL para proteger os workspaces do Azure Synapse. O Defender para SQL monitora o SQL do Synapse para detectar atividades anômalas que indiquem tentativas incomuns e possivelmente prejudiciais de acessar ou explorar bancos de dados. | AuditIfNotExists; Desactivado | 1.0.0 |
| O status do Microsoft Defender para SQL deve ser protegido para SQL Servers habilitados para Arc | O Microsoft Defender para SQL oferece funcionalidade para expor e reduzir possíveis vulnerabilidades de banco de dados, detectar atividades anômalas que podem indicar ameaças aos 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, no computador, no workspace e no SQL Server para garantir a proteção ativa. | Auditoria; Desactivado | 1.1.0 |
| O Microsoft Defender para Armazenamento deve estar habilitado | O Microsoft Defender para Armazenamento detecta 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 dados corrompidos. O novo plano do Defender para Armazenamento inclui Verificação de Malware e Detecção de Ameaças a Dados Confidenciais. Este plano também fornece uma estrutura de preços previsível (por conta de armazenamento) para controle da cobertura e dos custos. | AuditIfNotExists; Desactivado | 1.0.0 |
| O provisionamento automático direcionado ao SQL Server deve ser habilitado para servidores SQL no plano de computadores | Para garantir que as VMs do SQL e os SQL Servers habilitados para Arc estejam protegidos, verifique se o Agente de Monitoramento do Azure direcionado ao SQL está configurado para implantar automaticamente. Isso também é necessário se você já configurou o provisionamento automático do Microsoft Monitoring Agent, pois esse componente está sendo preterido. Saiba mais: Migrar para o Defender para SQL em computadores usando AMA | AuditIfNotExists; Desactivado | 1.0.0 |
| O Microsoft Defender Exploit Guard deve estar habilitado nos computadores | O Microsoft Defender Exploit Guard usa o agente de Configuração de Convidado do Azure Policy. O Exploit Guard tem quatro componentes que foram projetados para bloquear dispositivos contra uma ampla variedade de vetores de ataque e comportamentos de bloqueio comumente usados em ataques de malware, permitindo que as empresas encontrem um equilíbrio entre os requisitos de produtividade e o risco de segurança enfrentados (somente Windows). | AuditIfNotExists; Desactivado | 2.0.0 |
| [Versão prévia]: os clusters do Kubernetes habilitados para Azure Arc devem ter a extensão do Microsoft Defender para Nuvem instalada | A extensão do Microsoft Defender para Nuvem no Azure Arc oferece proteção contra ameaças para os 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 para Kubernetes na nuvem para análise posterior. Saiba mais em Classificação segura no Defender para Nuvem. | AuditIfNotExists; Desactivado | 6.0.0-preview |
LT-3: habilitar o registro em log para investigação de segurança
Para obter mais informações, consulte Registro em log e detecção de ameaças: LT-3: habilitar o registro em log para investigação de segurança.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Os aplicativos do Serviço de Aplicativo devem ter logs de recursos habilitados | Auditar a habilitação de logs de recurso no aplicativo. Isso permite recriar trilhas de atividades para fins de investigação se ocorrer um incidente de segurança ou se sua rede estiver comprometida. | AuditIfNotExists; Desactivado | 2.0.1 |
| A auditoria no SQL Server deve ser habilitada | A auditoria no SQL Server deve ser habilitada para acompanhar as atividades de banco de dados em todos os bancos de dados no servidor e salvá-las em um log de auditoria. | AuditIfNotExists; Desactivado | 2.0.0 |
| O Azure Front Door deve ter os logs de recursos habilitados | Habilite os logs de recursos para o Azure Front Door (mais o WAF) e transmita-os para um workspace do Log Analytics. Obtenha visibilidade detalhada do tráfego da Web de entrada e das ações executadas para mitigar os ataques. | AuditIfNotExists; Desactivado | 1.0.0 |
| Os logs de diagnóstico nos recursos dos serviços de IA do Azure devem ser habilitados | Habilite os logs dos recursos dos serviços de IA do Azure. Isso permite recriar trilhas de atividade para fins de investigação, quando ocorrer um incidente de segurança ou sua rede for comprometida | AuditIfNotExists; Desactivado | 1.0.0 |
| Os logs de recurso no Azure Data Lake Storage devem estar habilitados | Auditar a habilitação de logs de recurso. Permite recriar trilhas de atividades a serem usadas para fins de investigação; quando ocorrer um incidente de segurança ou quando sua rede estiver comprometida | AuditIfNotExists; Desactivado | 5.0.0 |
| Os registros de recursos nos Workspaces do Azure Databricks devem estar habilitados | Os logs de recursos permitem a recriação de trilhas de atividades para uso em investigações quando ocorre um incidente de segurança ou quando sua rede é comprometida. | AuditIfNotExists; Desactivado | 1.0.1 |
| Os logs de recursos no Serviço de Kubernetes do Azure devem ser habilitados | Os logs de recurso do Serviço de Kubernetes do Azure podem ajudar a recriar trilhas de atividades ao investigar incidentes de segurança. Habilite-o para garantir que os logs existam quando necessário | AuditIfNotExists; Desactivado | 1.0.0 |
| Os logs de recursos nos Workspaces do Azure Machine Learning devem estar habilitados | Os logs de recursos permitem a recriação de trilhas de atividades para uso em investigações quando ocorre um incidente de segurança ou quando sua rede é comprometida. | AuditIfNotExists; Desactivado | 1.0.1 |
| Os logs de recurso no Azure Stream Analytics devem estar habilitados | Auditar a habilitação de logs de recurso. Permite recriar trilhas de atividades a serem usadas para fins de investigação; quando ocorrer um incidente de segurança ou quando sua rede estiver comprometida | AuditIfNotExists; Desactivado | 5.0.0 |
| Os logs de recurso em contas do Lote devem estar habilitados | Auditar a habilitação de logs de recurso. Permite recriar trilhas de atividades a serem usadas para fins de investigação; quando ocorrer um incidente de segurança ou quando sua rede estiver comprometida | AuditIfNotExists; Desactivado | 5.0.0 |
| Os logs de recurso no Data Lake Analytics devem estar habilitados | Auditar a habilitação de logs de recurso. Permite recriar trilhas de atividades a serem usadas para fins de investigação; quando ocorrer um incidente de segurança ou quando sua rede estiver comprometida | AuditIfNotExists; Desactivado | 5.0.0 |
| Os logs de recurso no Hub de Eventos devem estar habilitados | Auditar a habilitação de logs de recurso. Permite recriar trilhas de atividades a serem usadas para fins de investigação; quando ocorrer um incidente de segurança ou quando sua rede estiver comprometida | AuditIfNotExists; Desactivado | 5.0.0 |
| Os logs de recurso no Hub IoT devem estar habilitados | Auditar a habilitação de logs de recurso. Permite recriar trilhas de atividades a serem usadas para fins de investigação; quando ocorrer um incidente de segurança ou quando sua rede estiver comprometida | AuditIfNotExists; Desactivado | 3.1.0 |
| Os logs de recurso no Key Vault devem estar habilitados | Auditar a habilitação de logs de recurso. Permite recriar trilhas de atividades a serem usadas para fins de investigação quando ocorrer um incidente de segurança ou quando sua rede estiver comprometida | AuditIfNotExists; Desactivado | 5.0.0 |
| Os logs de recurso nos Aplicativos Lógicos devem estar habilitados | Auditar a habilitação de logs de recurso. Permite recriar trilhas de atividades a serem usadas para fins de investigação; quando ocorrer um incidente de segurança ou quando sua rede estiver comprometida | AuditIfNotExists; Desactivado | 5.1.0 |
| Os logs de recurso nos serviços de pesquisa devem estar habilitados | Auditar a habilitação de logs de recurso. Permite recriar trilhas de atividades a serem usadas para fins de investigação; quando ocorrer um incidente de segurança ou quando sua rede estiver comprometida | AuditIfNotExists; Desactivado | 5.0.0 |
| Os logs de recurso no Barramento de Serviço devem estar habilitados | Auditar a habilitação de logs de recurso. Permite recriar trilhas de atividades a serem usadas para fins de investigação; quando ocorrer um incidente de segurança ou quando sua rede estiver comprometida | AuditIfNotExists; Desactivado | 5.0.0 |
LT-4: Habilitar o registro em log de rede para investigação de segurança
Para obter mais informações, consulte Registro em log e detecção de ameaças: LT-4: habilitar o registro em log de rede para investigação de segurança.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Os logs de fluxo deverão ser configurados para cada grupo de segurança de rede | Uma auditoria de grupos de segurança de rede para verificar se os logs de fluxo foram configurados. Habilitar logs de fluxo permite registrar informações sobre o tráfego IP que flui por meio do grupo de segurança de rede. Ele pode ser usado para otimizar os fluxos de rede, monitorar a taxa de transferência, verificar a conformidade, detectar invasões e muito mais. | Auditoria; Desactivado | 1.1.0 |
| [Versão prévia]: o agente de coleta de dados de tráfego de rede deve ser instalado em máquinas virtuais do 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; Desactivado | 1.0.2-preview |
| [Versão Prévia]: O agente de coleta de dados de tráfego de rede deve ser instalado nas Máquinas Virtuais do 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; Desactivado | 1.0.2-preview |
LT-5: centralizar o gerenciamento e a análise de logs de segurança
Para obter mais informações, consulte Registro em log e detecçã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 workspace do Log Analytics para proteger as consultas salvas com criptografia de conta de armazenamento. Normalmente, as chaves gerenciadas pelo cliente são necessárias para atender à conformidade regulatória e obter mais controle sobre o acesso às consultas salvas no Azure Monitor. Para obter mais detalhes sobre o acima, consulte a chave gerenciada pelo cliente para consultas salvas no Azure Monitor. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 1.1.0 |
| [Pré-visualização]: a extensão do Log Analytics deve ser instalada nos computadores Linux do Azure Arc | Esta política audita computadores Linux do Azure Arc se a extensão do Log Analytics não estiver instalada. | AuditIfNotExists; Desactivado | 1.0.1-preview |
| [Pré-visualização]: A extensão do Log Analytics deve ser instalada nos computadores Windows do Azure Arc | Esta política auditará os computadores Windows do Azure Arc se a extensão do Log Analytics não estiver instalada. | AuditIfNotExists; Desactivado | 1.0.1-preview |
LT-6: Configurar a retenção de armazenamento de log
Para obter mais informações, consulte Registro em log e detecçã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 mais | Para fins de investigação de incidentes, é recomendável configurar a retenção de dados para a auditoria do SQL Server no destino de conta de armazenamento para pelo menos 90 dias. Confirme que você está cumprindo as regras de retenção necessárias para as regiões em que está operando. Às vezes, isso é necessário para que você tenha conformidade com os padrões regulatórios. | AuditIfNotExists; Desactivado | 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 nos grupos de segurança de rede associados à sua máquina virtual | A Central de Segurança do Azure identificou algumas das regras de entrada de seus grupos de segurança de rede como permissivas demais. As regras de entrada não devem permitir o acesso por meio de intervalos "Qualquer" ou "Internet". Isso tem o potencial de tornar seus recursos alvos de invasores. | AuditIfNotExists; Desactivado | 3.0.0 |
| As máquinas virtuais para a Internet devem ser protegidas com grupos de segurança de rede | Proteja suas máquinas virtuais contra possíveis ameaças, restringindo o acesso a elas com um NSG (grupo de segurança de rede). Saiba mais sobre como controlar o tráfego com NSGs na visão geral dos grupos de segurança de rede do Azure | AuditIfNotExists; Desactivado | 3.0.0 |
| 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 possíveis ameaças, restringindo o acesso com um NSG (grupo de segurança de rede). Saiba mais sobre como controlar o tráfego com NSGs na visão geral dos grupos de segurança de rede do Azure | AuditIfNotExists; Desactivado | 3.0.0 |
| As sub-redes devem ser associadas a um Grupo de Segurança de Rede | Proteja sua sub-rede contra possíveis ameaças, restringindo o acesso a ela com um NSG (Grupo de Segurança de Rede). Os NSGs contêm uma lista de regras de ACL (lista de controle de acesso) que permitem ou negam o tráfego de rede para sua sub-rede. | AuditIfNotExists; Desactivado | 3.0.0 |
NS-2: Proteger serviços de nuvem com controles de rede
Para obter mais informações, consulte Segurança de Rede: NS-2: Proteger serviços de nuvem com controles de rede.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Os serviços do Gerenciamento de API devem usar uma rede virtual | A implantação da Rede Virtual do Azure fornece isolamento e segurança aprimorada e permite que você coloque o serviço de Gerenciamento de API em uma rede roteável não ligada à Internet para a qual você controla o acesso. Essas redes podem ser conectadas às suas redes locais usando várias tecnologias de VPN, o que permite o acesso aos seus serviços de back-end na rede e/ou locais. O portal do desenvolvedor e o gateway de API podem ser configurados para serem acessados pela Internet ou somente na rede virtual. | Auditoria; Negar; Desactivado | 1.0.2 |
| O Gerenciamento de APIs deve desabilitar o acesso à rede pública nos pontos de extremidade de configuração do serviço | Para melhorar a segurança dos serviços de Gerenciamento de API, restrinja a conectividade com pontos de extremidade de configuração de serviço, como a API de gerenciamento de acesso direto, o ponto de extremidade de gerenciamento de configuração do Git ou o ponto de extremidade de configuração de gateways auto-hospedados. | AuditIfNotExists; Desactivado | 1.0.1 |
| A Configuração de Aplicativos deve desabilitar o acesso à rede pública | A desabilitaçã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 seus recursos criando pontos de extremidade privados. Saiba mais em: Usar pontos de extremidade privados para a Configuração de Aplicativos do Azure. | Auditoria; Negar; Desactivado | 1.0.0 |
| A Configuração de Aplicativo deve usar um SKU que dê suporte a um link privado | Ao usar um SKU com suporte, o Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de link privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Mapeando seus pontos de extremidade privados para suas instâncias de configuração de aplicativos, em vez de todo o serviço, você também estará protegido contra riscos de vazamento de dados. Saiba mais em: Usar pontos de extremidade privados para a Configuração de Aplicativos do Azure. | Auditoria; Negar; Desactivado | 1.0.0 |
| A Configuração de Aplicativos deve usar um link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de link privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Mapeando seus pontos de extremidade privados para suas instâncias de configuração de aplicativos, em vez de todo o serviço, você também estará protegido contra riscos de vazamento de dados. Saiba mais em: Usar pontos de extremidade privados para a Configuração de Aplicativos do Azure. | AuditIfNotExists; Desactivado | 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 sejam acessíveis pela internet pública, é necessário implantar o Ambiente do Serviço de Aplicativo com um endereço IP na rede virtual. Para definir o endereço IP para um IP de rede virtual, o Ambiente do Serviço de Aplicativo deve ser implantado com um balanceador de carga interno. | Auditoria; Negar; Desactivado | 3.0.0 |
| Os slots de aplicativos do Serviço de Aplicativo devem desabilitar o acesso à rede pública | A desabilitaçã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 de extremidade privados pode limitar a exposição do Serviço de Aplicativo. Saiba mais em: Usar pontos de extremidade privados para aplicativos. | Auditoria; Desactivado; Negar | 1.0.0 |
| Os aplicativos do Serviço de Aplicativo devem desabilitar o acesso à rede pública | A desabilitaçã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 de extremidade privados pode limitar a exposição do Serviço de Aplicativo. Saiba mais em: Usar pontos de extremidade privados para aplicativos. | Auditoria; Desactivado; Negar | 1.1.0 |
| Os aplicativos do Serviço de Aplicativo devem usar um SKU que dê suporte a link privado | Com SKUs com suporte, o Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um IP na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Com o mapeamento dos pontos de extremidade privados para os aplicativos, você poderá reduzir os riscos de vazamento de dados. Saiba mais sobre links privados em: Usar pontos de extremidade privados para aplicativos. | Auditoria; Negar; Desactivado | 4.3.0 |
| Os aplicativos do Serviço de Aplicativo do Azure devem usar o link privado | O Link Privado do Azure permite que você conecte 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 manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Com o mapeamento dos pontos de extremidade privados para o Serviço de Aplicativo, você poderá reduzir os riscos de vazamento de dados. Saiba mais sobre links privados em: Usar pontos de extremidade privados para aplicativos. | AuditIfNotExists; Desactivado | 1.0.1 |
| Os componentes do Application Insights devem bloquear a ingestão de logs e a consulta de redes públicas | Melhore a segurança do Application Insights bloqueando a ingestão de logs e a consulta de redes públicas. Somente redes conectadas de link privado poderão ingerir e consultar logs desse componente. Saiba mais em Usar o Link Privado do Azure para conectar redes ao Azure Monitor. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 1.1.0 |
| Os intervalos de IP autorizados devem ser definidos nos Serviços do Kubernetes | Restrinja o acesso à API de Gerenciamento de Serviços do Kubernetes permitindo acesso à API somente aos endereços IP em intervalos específicos. Recomendamos limitar o acesso aos intervalos de IP autorizados para garantir que somente os aplicativos de redes permitidas possam acessar o cluster. | Auditoria; Desactivado | 2.0.1 |
| As contas de automação devem desabilitar o acesso à rede pública | A desabilitação do acesso à rede pública melhora a segurança, garantindo que o recurso não seja exposto na Internet pública. Você pode limitar a exposição dos recursos da conta de Automação criando pontos de extremidade privados. Saiba mais em: Usar o Link Privado do Azure para conectar redes com segurança à Automação do Azure. | Auditoria; Negar; Desactivado | 1.0.0 |
| O serviço Pesquisa de IA do Azure deve usar um SKU que dê suporte a link privado | Com SKUs com suporte do Azure AI Search, o Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de link privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Ao mapear pontos de extremidade privados para 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; Desactivado | 1.0.1 |
| Os serviços do Azure AI Search devem desabilitar o acesso à rede pública | Desabilitar o acesso à rede pública melhora a segurança, garantindo que o serviço do 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 serviço de Pesquisa. Saiba mais em: Criar um ponto de extremidade privado para uma conexão segura. | Auditoria; Negar; Desactivado | 1.0.1 |
| Os recursos dos Serviços de IA do Azure devem restringir p acesso à rede | Ao restringir o acesso à rede, você poderá 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 de IA do Azure. | Auditoria; Negar; Desactivado | 3.3.0 |
| Os recursos dos Serviços de IA do Azure devem usar o Link Privado do Azure | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma Link Privado reduz os riscos de vazamento de dados manipulando a conectividade entre o consumidor e os serviços pela rede de backbone do Azure. Saiba mais sobre links privados em: O que é o Link Privado do Azure? | Auditoria; Desactivado | 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 privado aprovada. Os clientes em uma rede virtual podem acessar com segurança recursos que têm conexões de ponto de extremidade privado por meio de links privados. Para obter mais informações, visite: Configurar o Link Privado para os Serviços de Dados de Integridade do Azure. | Auditoria; Desactivado | 1.0.0 |
| Os Escopos de Link Privado do Azure Arc devem ser configurados com um ponto de extremidade privado | O Link Privado do Azure permite que você conecte 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 manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Com o mapeamento dos pontos de extremidade privados para os Escopos de Link Privado do Azure Arc, os riscos de vazamento de dados são reduzidos. Saiba mais sobre links privados em: Usar o Link Privado do Azure para conectar servidores ao Azure Arc usando um ponto de extremidade privado. | Auditoria; Desactivado | 1.0.0 |
| Os Escopos de Link Privado do Azure Arc devem desabilitar o acesso à rede pública | A desabilitação do acesso à rede pública melhora a segurança, garantindo que os recursos do Azure Arc não possam se conectar pela Internet pública. A criação de pontos de extremidade privados pode limitar a exposição dos recursos do Azure Arc. Saiba mais em: Usar o Link Privado do Azure para conectar servidores ao Azure Arc usando um ponto de extremidade privado. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os clusters de Kubernetes habilitados para Azure Arc devem ser configurados com um escopo de Link Privado do Azure Arc | O Link Privado do Azure permite que você conecte 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 manipula a conectividade entre o consumidor e os serviços na 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: Usar o Link Privado do Azure para conectar servidores ao Azure Arc usando um ponto de extremidade privado. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os servidores habilitados para o Azure Arc devem ser configurados com um Escopo de Link Privado do Azure Arc | O Link Privado do Azure permite que você conecte 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 manipula a conectividade entre o consumidor e os serviços na 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: Usar o Link Privado do Azure para conectar servidores ao Azure Arc usando um ponto de extremidade privado. | Auditoria; Negar; Desactivado | 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, verifique se ele não está exposto à Internet pública e só pode ser acessado de um ponto de extremidade privado. Desabilite a propriedade de acesso à rede pública, conforme descrito em aka.ms/azureattestation. Essa opção desabilitará o acesso de todos os espaços de endereços IP públicos fora do intervalo de IP do Azure, bem como negará logons que correspondam a regras de firewall baseadas em IP ou rede virtual. Isso reduzirá riscos de vazamento de dados. | Auditoria; Negar; Desactivado | 1.0.0 |
| O Cache do Azure para Redis Enterprise deve usar link privado | Os pontos de extremidade privados permitem que você conecte a 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 do Azure para Redis com o Link Privado do Azure?. | AuditIfNotExists; Desactivado | 1.0.0 |
| O Cache do Azure para Redis deve desabilitar o acesso à rede pública | A desabilitação do acesso à rede pública aprimora a segurança, garantindo que o Cache do Azure para Redis não seja exposto na Internet pública. Em vez disso, você pode limitar a exposição do Cache do Azure para Redis criando pontos de extremidade privados. Saiba mais em: O que é o Cache do Azure para Redis com o Link Privado do Azure?. | Auditoria; Negar; Desactivado | 1.0.0 |
| O Cache do Azure para Redis deve usar um link privado | Os pontos de extremidade privados permitem que você conecte a sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. Quando os pontos de extremidade privados são mapeados para as instâncias do Cache do Azure para Redis, os riscos de vazamento de dados são reduzidos. Saiba mais em: O que é o Cache do Azure para Redis com o Link Privado do Azure?. | AuditIfNotExists; Desactivado | 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 evitar o tráfego de fontes não autorizadas. As contas que têm pelo menos uma regra de IP definida com o filtro de rede virtual habilitado são consideradas em conformidade. As contas que desabilitam o acesso público também são consideradas em conformidade. | Auditoria; Negar; Desactivado | 2.1.0 |
| O Azure Cosmos DB deve desabilitar o acesso à rede pública | A desabilitação do acesso à rede pública aprimora a segurança, garantindo que a conta do CosmosDB não seja exposta na Internet pública. A criação de pontos de extremidade privados pode limitar a exposição da conta do CosmosDB. Saiba mais em: Bloquear o acesso à rede pública durante a criação da conta do Azure Cosmos DB. | Auditoria; Negar; Desactivado | 1.0.0 |
| O cluster do Azure Data Explorer deve usar o link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Ao mapear pontos de extremidade privados para o 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; Desactivado | 1.0.0 |
| O Azure Data Explorer deve usar um SKU que dê suporte a um link privado | Com SKUs com suporte, o Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um IP na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Com o mapeamento dos pontos de extremidade privados para os aplicativos, você poderá reduzir os riscos de vazamento de dados. Saiba mais sobre links privados em: Usar pontos de extremidade privados para aplicativos. | Auditoria; Negar; Desactivado | 1.0.0 |
| O Azure Data Factory deve usar o link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. 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: Link Privado do Azure para Azure Data Factory. | AuditIfNotExists; Desactivado | 1.0.0 |
| Os clusters do Azure Databricks devem desabilitar o IP público | A desativação do IP público de clusters nos Workspaces do Azure Databricks melhora a segurança, garantindo que os clusters não sejam expostos na Internet pública. Saiba mais em: Habilitar a conectividade segura do cluster. | Auditoria; Negar; Desactivado | 1.0.1 |
| Os Workspaces do Azure Databricks devem estar em uma rede virtual | As Redes Virtuais do Microsoft Azure fornecem segurança e isolamento aprimorados para seus Workspaces 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; Desactivado | 1.0.2 |
| Os espaços de trabalho do Azure Databricks devem desabilitar o acesso à rede pública | A desabilitaçã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 dos seus recursos criando pontos de extremidade privados. Saiba mais em: Conceitos do Link Privado do Azure. | Auditoria; Negar; Desactivado | 1.0.1 |
| Os Workspaces do Azure Databricks devem usar o link privado | O Link Privado do Azure permite que você conecte 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 manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Ao mapear pontos de extremidade privados para workspaces 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 com o Azure Databricks. | Auditoria; Desactivado | 1.0.2 |
| Os workspaces do Azure Databricks devem ser SKU Premium que dá suporte a recursos como link privado, chave gerenciada pelo cliente para criptografia | Permitir apenas o workspace do Databricks com o Sku Premium que sua organização pode implantar para dar suporte a recursos como Link Privado, chave gerenciada pelo cliente para criptografia. Saiba mais em: Configurar a conectividade privada de back-end com o Azure Databricks. | Auditoria; Negar; Desactivado | 1.0.1 |
| A Atualização de Dispositivo do Azure para contas do Hub IoT deve usar o link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Ao mapear pontos de extremidade privados para a Atualização de Dispositivo do Azure para contas do Hub IoT, os riscos de vazamento de dados são reduzidos. | AuditIfNotExists; Desactivado | 1.0.0 |
| Os domínios da Grade de Eventos do Azure devem desabilitar o acesso à rede pública | A desabilitaçã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 seus recursos criando pontos de extremidade privados. Saiba mais em: Configurar pontos de extremidade privados para tópicos ou domínios. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os domínios da Grade de Eventos do Azure devem usar um link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Por meio do mapeamento de pontos de extremidade privados para o 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; Desactivado | 1.0.2 |
| O agente MQTT do namespace da Grade de Eventos do Azure deve usar o link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Ao mapear pontos de extremidade privados para o namespace da Grade de Eventos em vez de todo o serviço, você também será protegido contra riscos de vazamento de dados. Saiba mais em: Configurar pontos de extremidade privados para tópicos ou domínios. | Auditoria; Desactivado | 1.0.0 |
| O agente de tópicos do namespace da Grade de Eventos do Azure deve usar o link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Ao mapear pontos de extremidade privados para o namespace da Grade de Eventos em vez de todo o serviço, você também será protegido contra riscos de vazamento de dados. Saiba mais em: Configurar pontos de extremidade privados para tópicos ou domínios. | Auditoria; Desactivado | 1.0.0 |
| Os namespaces da Grade de Eventos do Azure devem desabilitar o acesso à rede pública | A desabilitaçã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 seus recursos criando pontos de extremidade privados. Saiba mais em: Configurar pontos de extremidade privados para tópicos ou domínios. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os tópicos da Grade de Eventos do Azure devem desabilitar o acesso à rede pública | A desabilitaçã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 seus recursos criando pontos de extremidade privados. Saiba mais em: Configurar pontos de extremidade privados para tópicos ou domínios. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os tópicos da Grade de Eventos do Azure devem usar um link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Por meio do mapeamento de pontos de extremidade privados para o seu tópico 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; Desactivado | 1.0.2 |
| A Sincronização de Arquivos do Azure deve usar o link privado | A criação de um ponto de extremidade privado para o recurso de Serviço de Sincronização de Armazenamento indicado permite que você resolva o recurso do Serviço de Sincronização de Armazenamento no espaço de endereços IP privado da rede da sua organização e não por meio do ponto de extremidade público acessível à Internet. A criação de um ponto de extremidade privado por si só não desabilita o ponto de extremidade público. | AuditIfNotExists; Desactivado | 1.0.0 |
| Os perfis do Azure Front Door devem usar a camada Premium que dá suporte a regras de WAF gerenciadas e link privado | O Azure Front Door Premium dá suporte a regras de WAF gerenciadas pelo Azure e a um link privado para origens do Azure com suporte. | Auditoria; Negar; Desactivado | 1.0.0 |
| O Azure HDInsight deve usar o link privado | O Link Privado do Azure permite que você conecte 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 manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Mapeando 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 o Link Privado em um cluster do Azure HDInsight. | AuditIfNotExists; Desactivado | 1.0.0 |
| O serviço de desabilitação dos Serviços de Dados de Integridade do Azure deve desabilitar o acesso à rede pública | A desabilitaçã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 seus recursos criando pontos de extremidade privados. | Auditoria; Desactivado | 1.0.0 |
| O serviço de desidenciação dos Serviços de Dados de Integridade do Azure deve usar o link privado | O serviço de desidenciamento dos Serviços de Dados de Integridade do Azure deve ter pelo menos uma conexão de ponto de extremidade privado aprovada. Os clientes em uma rede virtual podem acessar com segurança recursos que têm conexões de ponto de extremidade privado por meio de links privados. | Auditoria; Desactivado | 1.0.0 |
| O workspace dos Serviços de Dados de Integridade do Azure deve usar o link privado | O workspace dos Serviços de Dados de Integridade deve ter pelo menos uma conexão de ponto de extremidade privado aprovada. Os clientes em uma rede virtual podem acessar com segurança recursos que têm conexões de ponto de extremidade privado por meio de links privados. Para obter mais informações, visite: Configurar o Link Privado para os Serviços de Dados de Integridade do Azure. | Auditoria; Desactivado | 1.0.0 |
| O Azure Key Vault deve desabilitar o acesso à rede pública | Desabilite o acesso à rede pública para o seu cofre de chaves de modo que ele não possa ser acessado pela Internet pública. Isso pode reduzir os riscos de vazamento de dados. Saiba mais em: Integrar o Key Vault ao Link Privado do Azure. | Auditoria; Negar; Desactivado | 1.1.0 |
| O Azure Key Vault deve ter o firewall habilitado ou o 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 IP público ou desabilite o acesso à rede pública para o cofre de chaves para que ele não seja 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 ao Link Privado do Azure | Auditoria; Negar; Desactivado | 3.3.0 |
| Os Azure Key Vaults devem usar um link privado | O Link Privado do Azure permite que você conecte 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 manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Com o mapeamento dos pontos de extremidade privados para o cofre de chaves, você poderá reduzir os riscos de vazamento de dados. Saiba mais sobre links privados em: Integrar o Key Vault ao Link Privado do Azure. | Auditoria; Negar; Desactivado | 1.2.1 |
| Os Computadores 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 a partir de máquinas e aplicativos virtuais dentro da rede virtual. | Auditoria; Desactivado | 1.0.1 |
| Os Workspaces do Azure Machine Learning devem desabilitar o acesso à rede pública | A desativação do acesso à rede pública aumenta a segurança, garantindo que os Workspaces do Machine Learning não sejam expostos na Internet pública. Em vez disso, você pode controlar a exposição dos seus espaços de trabalho criando pontos de extremidade privados. Saiba mais em: Configurar um ponto de extremidade privado para um workspace do Azure Machine Learning. | Auditoria; Negar; Desactivado | 2.0.1 |
| O Azure Machine Learning e o Ai Studio devem usar o modo permitir somente vnet gerenciada de saída aprovada | 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 workspace. A VNet gerenciada protege os 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; Desactivado | 1.0.0 |
| Os workspaces do Azure Machine Learning devem usar um link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Ao mapear pontos de extremidade privados para workspaces do Azure Machine Learning, os riscos de vazamento de dados serão reduzidos. Saiba mais sobre links privados em: Configurar um ponto de extremidade privado para um workspace do Azure Machine Learning. | Auditoria; Desactivado | 1.0.0 |
| Os workspaces do Grafana Gerenciado do Azure devem desabilitar o acesso à rede pública | Desabilitar o acesso à rede pública melhora a segurança, garantindo que seu workspace do Grafana Gerenciado do Azure não seja exposto na Internet pública. A criação de pontos de extremidade privados pode limitar a exposição de seus workspaces. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os workspaces do Grafana Gerenciado do Azure devem usar o link privado | O Link Privado do Azure permite que você conecte 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 manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Ao mapear pontos de extremidade privados para o Grafana Gerenciado, você pode reduzir os riscos de vazamento de dados. | Auditoria; Desactivado | 1.0.1 |
| O Escopo de Link Privado do Azure Monitor deve bloquear o acesso a recursos de link não privados | O Link Privado do Azure permite que você conecte suas redes virtuais aos recursos do Azure por meio de um ponto de extremidade privado a um AMPLS (escopo de Link Privado do Azure Monitor). Os modos de Acesso de Link Privado são definidos nos AMPLS para controlar se as solicitações de ingestão e consulta das 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 versus aberto). | Auditoria; Negar; Desactivado | 1.0.0 |
| O Escopo do Link Privado do Azure Monitor deve usar o link privado | O Link Privado do Azure permite que você conecte 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 manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Com o mapeamento dos pontos de extremidade privados para o Escopo de Link Privado do Azure Monitor, você pode reduzir os riscos de vazamento de dados. Saiba mais sobre links privados em: Usar o Link Privado do Azure para conectar redes ao Azure Monitor. | AuditIfNotExists; Desactivado | 1.0.0 |
| As contas do Azure Purview devem usar o link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de link privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Ao mapear pontos de extremidade privados para suas contas do Azure Purview em vez de todo o serviço, você também será protegido contra riscos de vazamento de dados. Saiba mais em: Usar pontos de extremidade privados no portal de governança clássico do Microsoft Purview. | Auditoria; Desactivado | 1.0.0 |
| As Instâncias Gerenciadas de SQL do Azure devem desabilitar o acesso à rede pública | Desabilitar o acesso à rede pública (ponto de extremidade público) em Instância Gerenciada de SQL do Azure melhora a segurança, garantindo que elas só possam ser acessadas de dentro de suas redes virtuais ou por meio de pontos de extremidade privados. Para saber mais sobre o acesso à rede pública, visite Configurar Ponto de Extremidade Público. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os namespaces do Barramento de Serviço do Azure devem usar um link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Quando os pontos de extremidade privados são mapeados para os namespaces do Barramento de Serviço, os riscos de vazamento de dados são reduzidos. Saiba mais em: Permitir acesso aos namespaces do Barramento de Serviço do Azure por meio de pontos de extremidade privados. | AuditIfNotExists; Desactivado | 1.0.0 |
| O Serviço do Azure SignalR deverá desabilitar o acesso à rede pública | Para melhorar a segurança do recurso do Serviço do Azure SignalR, verifique se ele não está exposto à Internet pública e só pode ser acessado de um ponto de extremidade privado. Desabilite a propriedade de acesso à rede pública conforme descrito em Configurar o controle de acesso à rede. Essa opção desabilitará o acesso de todos os espaços de endereços IP públicos fora do intervalo de IP do Azure, bem como negará logons que correspondam a regras de firewall baseadas em IP ou rede virtual. Isso reduzirá riscos de vazamento de dados. | Auditoria; Negar; Desactivado | 1.2.0 |
| O Serviço do Azure SignalR deve usar um SKU habilitado para Link Privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou destino que proteja seus recursos contra riscos de vazamento de dados públicos. A política limita você a SKUs habilitados para Link Privado para o Serviço do Azure SignalR. Saiba mais sobre o link privado em: Usar pontos de extremidade privados. | Auditoria; Negar; Desactivado | 1.0.0 |
| O Serviço do Azure SignalR deve usar o link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de link privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Ao mapear pontos de extremidade privados para seu recurso do Serviço do Azure SignalR em vez de todo o serviço, você reduzirá riscos de vazamento de dados. Saiba mais sobre links privados em: Usar pontos de extremidade privados. | Auditoria; Desactivado | 1.0.0 |
| O Azure Spring Cloud deve usar injeção de rede | As instâncias do Azure Spring Cloud devem usar injeção de rede virtual para as seguintes finalidades: 1. Isole o Azure Spring Cloud da Internet. 2 Habilite a interação do Azure Spring Cloud com sistemas em data centers locais ou no serviço do Azure em outras redes virtuais. 3. Capacite os clientes a controlar comunicações de rede de entrada e saída para o Azure Spring Cloud. | Auditoria; Desactivado; Negar | 1.2.0 |
| Os workspaces do Azure Synapse devem desabilitar o acesso à rede pública | Desabilitar o acesso à rede pública melhora a segurança, garantindo que o workspace do Synapse não seja exposto na Internet pública. A criação de pontos de extremidade privados pode limitar a exposição dos workspaces do Synapse. Saiba mais em: Configurações de conectividade do Azure Synapse Analytics. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os workspaces do Azure Synapse devem usar um link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Ao mapear pontos de extremidade privados para o workspace do Azure Synapse, os riscos de vazamento de dados são reduzidos. Saiba mais sobre links privados em: Conecte-se ao workspace do Azure Synapse usando links privados. | Auditoria; Desactivado | 1.0.1 |
| Os hostpools da Área de Trabalho Virtual do Azure devem desabilitar o acesso à rede pública | Desabilitar o 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 o Link Privado com a Área de Trabalho Virtual do Azure. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os hostpools 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 os 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 o Link Privado com a Área de Trabalho Virtual do Azure. | Auditoria; Negar; Desactivado | 1.0.0 |
| O serviço de Área de Trabalho Virtual do Azure deve usar o link privado | Usar o Link Privado do Azure 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 o Link Privado com a Área de Trabalho Virtual do Azure. | Auditoria; Desactivado | 1.0.0 |
| Os workspaces da Área de Trabalho Virtual do Azure devem desabilitar o acesso à rede pública | Desabilitar o acesso à rede pública para o recurso de workspace 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 seus dados seguros. Saiba mais em: Configurar o Link Privado com a Área de Trabalho Virtual do Azure. | Auditoria; Negar; Desactivado | 1.0.0 |
| O Serviço Web PubSub do Azure deve desabilitar o acesso à rede pública | Desabilitar o 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 do Azure Web PubSub. | Auditoria; Negar; Desactivado | 1.0.0 |
| O Serviço Web PubSub do Azure deve usar uma SKU que dá suporte a links privados | Com o SKU com suporte, o Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. 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 de serviço do Azure Web PubSub. | Auditoria; Negar; Desactivado | 1.0.0 |
| O Serviço Azure Web PubSub deve usar o link privado | O Link Privado do Azure permite que você conecte 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 manipula a conectividade entre o consumidor e os serviços na 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 de serviço do Azure Web PubSub. | Auditoria; Desactivado | 1.0.0 |
| O Serviço de Bot deve ter o acesso à rede pública desabilitado | Os bots devem ser definidos como modo "somente isolado". Essa configuração configura canais do Serviço de Bot que exigem que o tráfego pela Internet pública seja desabilitado. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os recursos do BotService devem usar o link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Ao mapear pontos de extremidade privados para o recurso botService, os riscos de vazamento de dados são reduzidos. | Auditoria; Desactivado | 1.0.0 |
| O ambiente de Aplicativos de Contêiner deve desabilitar o acesso à rede pública | Desabilite 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 remove a necessidade de um endereço IP público e impede o acesso à Internet a todos os Aplicativos de Contêiner dentro do ambiente. | Auditoria; Negar; Desactivado | 1.1.0 |
| Os registros de contêiner devem ter SKUs que dão suporte a Links Privados | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de link privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. 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 o ponto de extremidade privado com o Link Privado para ACR. | Auditoria; Negar; Desactivado | 1.0.0 |
| Os registros de contêiner não devem permitir 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 seus Registros contra possíveis ameaças, permita o acesso somente de pontos de extremidade privados, endereços IP públicos ou intervalos de endereços específicos. Se o Registro não tiver regras de rede configuradas, ele será exibido nos recursos não íntegros. Saiba mais sobre as regras de rede do Registro de Contêiner aqui: Configure o Ponto de Extremidade Privado com o Link Privado para ACR, configure o Acesso ao Registro Público no Azure e restrinja o acesso ao Registro de Contêiner do Azure usando pontos de extremidade de serviço. | Auditoria; Negar; Desactivado | 2.0.0 |
| Os registros de contêiner devem usar um link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de link privado manipula a conectividade entre o consumidor e os serviços pela rede de backbone do Azure. Por meio do mapeamento de 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 o ponto de extremidade privado com o Link Privado para ACR. | Auditoria; Desactivado | 1.0.1 |
| As contas do CosmosDB devem usar um link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Quando os pontos de extremidade privados são mapeados para a 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; Desactivado | 1.0.0 |
| Os recursos de acesso ao disco devem usar o link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Com o mapeamento dos 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; Desactivado | 1.0.0 |
| O ElasticSan deve desabilitar o acesso à rede pública | Desabilite o acesso à rede pública para 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; Desactivado | 1.0.0 |
| Os Namespaces do Hub de Eventos devem desativar o acesso à rede pública | O Hub de Eventos do Azure deve ter o acesso à rede pública desabilitado. A desabilitaçã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 seus recursos criando pontos de extremidade privados. Saiba mais em: Permitir acesso aos namespaces dos Hubs de Eventos do Azure por meio de pontos de extremidade privados | Auditoria; Negar; Desactivado | 1.0.0 |
| Os namespaces do Hub de Eventos devem usar o link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Quando os pontos de extremidade privados são mapeados para os 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; Desactivado | 1.0.0 |
| Os slots dos aplicativos de funções devem desabilitar o acesso à rede pública | A desabilitação do acesso à rede pública aprimora a segurança, garantindo que o aplicativo de funções não seja exposto na internet pública. A criação de pontos de extremidade privados pode limitar a exposição de um aplicativo de funções. Saiba mais em: Usar pontos de extremidade privados para aplicativos. | Auditoria; Desactivado; Negar | 1.1.0 |
| Os aplicativos de funções devem desabilitar o acesso à rede pública | A desabilitação do acesso à rede pública aprimora a segurança, garantindo que o aplicativo de funções não seja exposto na internet pública. A criação de pontos de extremidade privados pode limitar a exposição de um aplicativo de funções. Saiba mais em: Usar pontos de extremidade privados para aplicativos. | Auditoria; Desactivado; Negar | 1.1.0 |
| O IoT Central deve usar o link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de link privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. 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; Desactivado | 1.0.0 |
| As instâncias do serviço de provisionamento de dispositivos do Hub IoT devem desabilitar o acesso à rede pública | Desabilitar o 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; Desactivado | 1.0.0 |
| As instâncias do Serviço de Provisionamento de Dispositivos no Hub IoT devem usar um link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. 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; Desactivado | 1.0.0 |
| Os espaços de trabalho do Log Analytics devem bloquear a ingestão de logs e a consulta de redes públicas | Melhore a segurança do workspace bloqueando a ingestão de logs e a consulta de redes públicas. Somente redes conectadas de link privado poderão ingerir e consultar logs nesse workspace. Saiba mais em Usar o Link Privado do Azure para conectar redes ao Azure Monitor. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 1.1.0 |
| Os discos gerenciados devem desabilitar o acesso à rede pública | A desabilitação do acesso à rede pública aprimora 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 dos discos gerenciados. Saiba mais em: Restringir o acesso de importação/exportação a discos gerenciados. | Auditoria; Negar; Desactivado | 2.1.0 |
| As conexões de ponto de extremidade privado nos Banco de Dados SQL do Azure devem ser habilitadas | As conexões de ponto de extremidade privado impõem comunicações seguras habilitando a conectividade privada ao Banco de Dados SQL do Azure. | Auditoria; Desactivado | 1.1.0 |
| O ponto de extremidade privado deve ser habilitado para servidores MariaDB | As conexões de ponto de extremidade privado impõem comunicações seguras habilitando a conectividade privada ao Banco de Dados do Azure para MariaDB. Configure uma conexão de ponto de extremidade privado para habilitar o acesso ao tráfego proveniente somente de redes conhecidas e impedir o acesso de todos os outros endereços IP, incluindo no Azure. | AuditIfNotExists; Desactivado | 1.0.2 |
| O ponto de extremidade privado deve ser habilitado para servidores MySQL | As conexões de ponto de extremidade privado impõem comunicações seguras habilitando a conectividade privada ao Banco de Dados do Azure para MySQL. Configure uma conexão de ponto de extremidade privado para habilitar o acesso ao tráfego proveniente somente de redes conhecidas e impedir o acesso de todos os outros endereços IP, incluindo no Azure. | AuditIfNotExists; Desactivado | 1.0.2 |
| O ponto de extremidade privado deve ser habilitado para servidores PostgreSQL | As conexões de ponto de extremidade privado impõem comunicações seguras habilitando a conectividade privada ao Banco de Dados do Azure para PostgreSQL. Configure uma conexão de ponto de extremidade privado para habilitar o acesso ao tráfego proveniente somente de redes conhecidas e impedir o acesso de todos os outros endereços IP, incluindo no Azure. | AuditIfNotExists; Desactivado | 1.0.2 |
| O acesso à rede pública para contas do Azure Device Update para Hub IoT deve ser desabilitado | Desabilitar a propriedade de acesso à rede pública melhora a segurança, garantindo que sua Atualização de Dispositivo do Azure para contas do Hub IoT só possa ser acessada de um ponto de extremidade privado. | Auditoria; Negar; Desactivado | 1.0.0 |
| O acesso à rede pública no Azure Data Explorer deve ser desabilitado | Desabilitar a propriedade de acesso à rede pública melhora a segurança, garantindo que o Azure Data Explorer só possa ser acessado de um ponto de extremidade privado. Essa configuração nega todos os logons que correspondam às regras de firewall baseadas em rede virtual ou em IP. | Auditoria; Negar; Desactivado | 1.0.0 |
| O acesso à rede pública no Azure Data Factory deve ser desabilitado | Desabilitar a propriedade de acesso à rede pública melhora a segurança, garantindo que seu Azure Data Factory só possa ser acessado de um ponto de extremidade privado. | Auditoria; Negar; Desactivado | 1.0.0 |
| O acesso à rede pública no Hub IoT do Azure deve ser desabilitado | Desabilitar a propriedade de acesso à rede pública melhora a segurança, garantindo que seu Hub IoT do Azure só possa ser acessado de um ponto de extremidade privado. | Auditoria; Negar; Desactivado | 1.0.0 |
| O acesso à rede pública no Banco de Dados SQL do Azure deve ser desabilitado | Desabilitar a propriedade de acesso à rede pública aprimora a segurança garantindo que o Banco de Dados SQL do Azure só possa ser acessado de um ponto de extremidade privado. Essa configuração nega todos os logons que correspondam às regras de firewall baseadas em rede virtual ou em IP. | Auditoria; Negar; Desactivado | 1.1.0 |
| O acesso à rede pública deve ser desabilitado para a Sincronização de Arquivos do Azure | A desabilitação do ponto de extremidade público permite restringir o acesso ao seu recurso de 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 não seguro sobre a permissão de solicitações para o ponto de extremidade público. No entanto, talvez você queira desabilitá-lo para atender a requisitos regulatórios, legais ou de política organizacional. Você pode desabilitar o ponto de extremidade público para um serviço de sincronização de armazenamento definindo o incomingTrafficPolicy do recurso como AllowVirtualNetworksOnly. | Auditoria; Negar; Desactivado | 1.0.0 |
| O acesso à rede pública deve ser desabilitado para contas do Lote | Desabilitar o acesso à rede pública em uma conta do Lote melhora a segurança, garantindo que sua conta do Lote só possa ser acessada de um ponto de extremidade privado. Saiba mais sobre como desabilitar o acesso à rede pública em Usar pontos de extremidade privados com contas do Lote do Azure. | Auditoria; Negar; Desactivado | 1.0.0 |
| O acesso à rede pública deve ser desabilitado para Registros de Contêiner | Desabilitar o 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 de 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 a ACR. | Auditoria; Negar; Desactivado | 1.0.0 |
| O acesso à rede pública deve ser desabilitado para o IoT Central | Para melhorar a segurança do IoT Central, verifique se ele não está exposto à Internet pública e só pode ser acessado 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. Essa opção desabilitará o acesso de todos os espaços de endereços IP públicos fora do intervalo de IP do Azure, bem como negará logons que correspondam a regras de firewall baseadas em IP ou rede virtual. Isso reduzirá riscos de vazamento de dados. | Auditoria; Negar; Desactivado | 1.0.0 |
| O acesso à rede pública deve ser desabilitado para servidores MariaDB | Desabilitar a propriedade de acesso à rede pública aprimora a segurança e garantir que o Banco de Dados do Azure para MariaDB só possa ser acessado de um ponto de extremidade privado. Essa configuração desabilita estritamente o acesso de qualquer espaço de endereço público fora do intervalo de IP do Azure e nega todos os logons que correspondam a regras de firewall baseadas em IP ou em rede virtual. | Auditoria; Negar; Desactivado | 2.0.0 |
| O acesso à rede pública deve ser desabilitado para servidores MariaDB | Desabilitar a propriedade de acesso à rede pública aprimora a segurança e garantir que o Banco de Dados do Azure para MariaDB só possa ser acessado de um ponto de extremidade privado. Essa configuração desabilita estritamente o acesso de qualquer espaço de endereço público fora do intervalo de IP do Azure e nega todos os logons que correspondam a regras de firewall baseadas em IP ou em rede virtual. | Auditoria; Negar; Desactivado | 2.0.0 |
| O acesso à rede pública deve ser desabilitado para servidores flexíveis do MySQL | Desabilitar a 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 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 rede virtual ou IP. | Auditoria; Negar; Desactivado | 2.3.0 |
| O acesso à rede pública deve ser desabilitado para servidores MySQL | Desabilitar a propriedade de acesso à rede pública aprimora a segurança e garantir que o Banco de Dados do Azure para MySQL só possa ser acessado de um ponto de extremidade privado. Essa configuração desabilita estritamente o acesso de qualquer espaço de endereço público fora do intervalo de IP do Azure e nega todos os logons que correspondam a regras de firewall baseadas em IP ou em rede virtual. | Auditoria; Negar; Desactivado | 2.0.0 |
| O acesso à rede pública deve ser desabilitado para servidores flexíveis do PostgreSQL | Desabilitar a 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 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; Desactivado | 3.1.0 |
| O acesso à rede pública deve ser desabilitado para servidores PostgreSQL | Desabilitar a propriedade de acesso à rede pública aprimora a segurança e garantir que o Banco de Dados do Azure para PostgreSQL só possa ser acessado de um ponto de extremidade privado. Essa configuração desabilita o acesso de qualquer espaço de endereço público fora do intervalo de IP do Azure e nega todos os logons que correspondam a regras de firewall baseadas em IP ou em rede virtual. | Auditoria; Negar; Desactivado | 2.0.1 |
| Os Namespaces do Barramento de Serviço devem desativar o acesso à rede pública | O Barramento de Serviço do Azure deve ter o acesso à rede pública desabilitado. A desabilitaçã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 seus recursos criando pontos de extremidade privados. Saiba mais em: Permitir acesso aos namespaces do Barramento de Serviço do Azure por meio de pontos de extremidade privados | Auditoria; Negar; Desactivado | 1.1.0 |
| O acesso público da conta de armazenamento não deve ser permitido | O acesso de leitura público anônimo a contêineres e blobs no Armazenamento do Azure é uma forma conveniente de compartilhar dados, mas pode representar riscos de segurança. Para evitar violações de dados causadas por acesso anônimo indesejado, a Microsoft recomenda impedir o acesso público a uma conta de armazenamento, a menos que o seu cenário exija isso. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 3.1.1 |
| As contas de armazenamento devem desabilitar o acesso à rede pública | Para aprimorar a segurança das contas de armazenamento, verifique se elas não estão expostas à Internet pública e podem ser acessadas somente em um ponto de extremidade privado. Desabilite a propriedade de acesso à rede pública, conforme descrito no acesso à rede pública da conta de armazenamento. Essa opção desabilitará o acesso de todos os espaços de endereços IP públicos fora do intervalo de IP do Azure, bem como negará logons que correspondam a regras de firewall baseadas em IP ou rede virtual. Isso reduzirá riscos de vazamento de dados. | Auditoria; Negar; Desactivado | 1.0.1 |
| As contas de armazenamento devem restringir o acesso da rede | O acesso da rede às contas de armazenamento deve ser restrito. Configure as regras de rede de tal forma que somente os aplicativos das redes permitidas possam acessar a conta de armazenamento. Para permitir conexões de clientes específicos locais ou da Internet, o acesso pode ser permitido para o tráfego de redes virtuais específicas do Azure ou para intervalos de endereços IP públicos da Internet | Auditoria; Negar; Desactivado | 1.1.1 |
| As contas de armazenamento devem restringir o acesso à rede usando regras de rede virtual | Proteja suas contas de armazenamento contra possíveis ameaças usando regras de rede virtual como um método preferencial, em vez de filtragem baseada em IP. Desabilitar filtragem baseada em IP impede que IPs públicos acessem suas contas de armazenamento. | Auditoria; Negar; Desactivado | 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 possíveis ameaças usando regras de rede virtual como um método preferencial, em vez de filtragem baseada em IP. Desabilitar filtragem baseada em IP impede que IPs públicos acessem suas contas de armazenamento. | Auditoria; Negar; Desactivado | 1.0.0 |
| As contas de armazenamento devem usar um link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Quando os pontos de extremidade privados são mapeados para a conta de armazenamento, os riscos de vazamento de dados são reduzidos. Saiba mais sobre links privados em – O que é o Link Privado do Azure? | AuditIfNotExists; Desactivado | 2.0.0 |
| As contas de armazenamento devem usar o link privado (excluindo as contas de armazenamento criadas pelo Databricks) | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Quando os pontos de extremidade privados são mapeados para a conta de armazenamento, os riscos de vazamento de dados são reduzidos. Saiba mais sobre links privados em – O que é o Link Privado do Azure? | AuditIfNotExists; Desactivado | 1.0.0 |
| Os modelos do Construtor de Imagens de VM devem usar o link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Ao mapear pontos de extremidade privados para seus recursos de criação do Construtor de Imagens de VM, 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; Desactivado; Negar | 1.1.0 |
| [Versão prévia]: O HSM Gerenciado do Azure Key Vault deve desabilitar o acesso à rede pública | Desabilite o acesso à rede pública para o seu HSM Gerenciado do Azure Key Vault de modo que ele não possa ser acessado 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; Desactivado | 1.0.0-preview |
| [Versão prévia]: O HSM Gerenciado do Azure Key Vault deve usar um link privado | O link privado fornece um modo de conectar o HSM Gerenciado do Azure Key Vault aos recursos do Azure sem enviar tráfego pela Internet pública. O link privado fornece uma proteção avançada contra exfiltração dos dados. Saiba mais em: Integrar o HSM Gerenciado ao Link Privado do Azure | Auditoria; Desactivado | 1.0.0-preview |
| [Versão prévia]: os cofres dos Serviços de Recuperação do Azure devem usar o link privado para backup | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Quando os pontos de extremidade privados são mapeados para 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; Desactivado | 2.0.0-preview |
| [Versão prévia]: Os cofres dos Serviços de Recuperação do Azure devem usar o link privado | O Link Privado do Azure permite que você conecte sua rede virtual aos serviços do Azure sem um endereço IP público na origem ou no destino. A plataforma de Link Privado manipula a conectividade entre o consumidor e os serviços na rede de backbone do Azure. Quando os pontos de extremidade privados são mapeados para 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 a replicação para computadores locais com pontos de extremidade privados e habilitar a replicação para pontos de extremidade privados no Azure Site Recovery. | Auditoria; Desactivado | 1.0.0-preview |
NS-3: implantar 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 IP na máquina virtual deve ser desabilitado | A habilitação do encaminhamento de IP na NIC de uma máquina virtual permite que o computador receba o tráfego endereçado a outros destinos. O encaminhamento de IP raramente é necessário (por exemplo, ao usar a VM como uma solução de virtualização de rede) e, portanto, isso deve ser examinado pela equipe de segurança de rede. | AuditIfNotExists; Desactivado | 3.0.0 |
| As portas de gerenciamento de máquinas virtuais devem ser protegidas com o controle de acesso à rede just-in-time | O possível acesso JIT (Just In Time) da rede será monitorado pela Central de Segurança do Azure como recomendação | AuditIfNotExists; Desactivado | 3.0.0 |
| Portas de gerenciamento devem ser fechadas nas máquinas virtuais | As portas abertas de gerenciamento remoto estão expondo sua VM a um alto nível de risco de ataques baseados na Internet. Estes ataques tentam obter credenciais por força bruta para obter acesso de administrador à máquina. | AuditIfNotExists; Desactivado | 3.0.0 |
| [Versão prévia]: todo o tráfego da Internet deve ser roteado por meio do Firewall do Azure implantado | A Central de Segurança do Azure identificou que algumas de suas sub-redes não estão protegidas com um firewall de última geração. Proteja suas sub-redes de ameaças potenciais restringindo o acesso a elas com o Firewall do Azure ou um firewall de última geração compatível | AuditIfNotExists; Desactivado | 3.0.0-preview |
NS-5: implantar proteção contra DDOS
Para obter mais informações, consulte Segurança de Rede: NS-5: Implantar proteção contra 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 seja parte de um gateway de aplicativo com um IP público. | AuditIfNotExists; Desactivado | 3.0.1 |
| As redes virtuais devem ser protegidas pela Proteção contra DDoS do Azure | Proteja suas redes virtuais contra ataques volumétricos e de protocolo com a Proteção contra DDoS do Azure. Para obter mais informações, visite a Visão geral da Proteção contra DDoS do Azure. | Modificar; Auditoria; Desactivado | 1.0.1 |
NS-6: implantar firewall do aplicativo Web
Para obter mais informações, consulte Segurança de Rede: NS-6: implantar o firewall do aplicativo Web.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| O Firewall de Aplicativo Web do Azure deve ser habilitado em pontos de entrada do Azure Front Door | Implante o WAF (Firewall de Aplicativo Web) do Azure na frente de aplicativos Web voltados para o público para que haja uma inspeção adicional do tráfego de entrada. O WAF (Firewall de Aplicativo Web) fornece proteção centralizada de seus aplicativos Web contra vulnerabilidades e explorações comuns como injeções de SQL, Cross-Site Scripting e execuções de arquivo locais e remotas. Você também pode restringir o acesso a seus aplicativos Web por países/regiões, intervalos de endereços IP e outros parâmetros https por meio de regras personalizadas. | Auditoria; Negar; Desactivado | 1.0.2 |
| O WAF (Firewall do Aplicativo Web) deve ser habilitado para o Gateway de Aplicativo | Implante o WAF (Firewall de Aplicativo Web) do Azure na frente de aplicativos Web voltados para o público para que haja uma inspeção adicional do tráfego de entrada. O WAF (Firewall de Aplicativo Web) fornece proteção centralizada de seus aplicativos Web contra vulnerabilidades e explorações comuns como injeções de SQL, Cross-Site Scripting e execuções de arquivo locais e remotas. Você também pode restringir o acesso a seus aplicativos Web por países/regiões, intervalos de endereços IP e outros parâmetros https por meio de regras personalizadas. | Auditoria; Negar; Desactivado | 2.0.0 |
NS-8: Detectar e desabilitar serviços e protocolos inseguros
Para obter mais informações, consulte Segurança de Rede: NS-8: Detectar 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 mais recente do TLS | Periodicamente, versões mais recentes são lançadas para o TLS, devido a falhas de segurança, para incluir funcionalidades adicionais e aprimorar a velocidade. Atualize para a versão mais recente do TLS para aplicativos do Serviço de Aplicativo para aproveitar as correções de segurança, se houver, e/ou as novas funcionalidades da versão mais recente. | AuditIfNotExists; Desactivado | 2.2.0 |
| Os aplicativos de funções devem usar a versão mais recente do TLS | Periodicamente, versões mais recentes são lançadas para o TLS, devido a falhas de segurança, para incluir funcionalidades adicionais e aprimorar a velocidade. Atualize para a última versão do TLS para os aplicativos de funções, a fim de aproveitar as correções de segurança, se houver, e/ou as novas funcionalidades da última versão. | AuditIfNotExists; Desactivado | 2.3.0 |
PA-1: separar e limitar 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 três proprietários deve ser designado para sua assinatura | Recomenda-se designar até 3 proprietários de assinaturas para reduzir o potencial de violação por parte de um proprietário comprometido. | AuditIfNotExists; Desactivado | 3.0.0 |
| As contas bloqueadas com permissões de proprietário em recursos do Azure devem ser removidas | Contas descontinuadas com permissões de proprietário devem ser removidas da sua assinatura. Contas descontinuadas são contas que foram impedidas de fazer login. | AuditIfNotExists; Desactivado | 1.0.0 |
| As contas de convidado com permissões de proprietário em recursos do Azure devem ser removidas | Contas externas com permissões de proprietário devem ser removidas da sua assinatura para evitar o acesso não monitorado. | AuditIfNotExists; Desactivado | 1.0.0 |
| Deve haver mais de um proprietário atribuído à sua assinatura | Recomenda-se designar mais de um proprietário de assinatura para ter redundância de acesso de administrador. | AuditIfNotExists; Desactivado | 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: evite o 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 o controle de acesso à rede just-in-time | O possível acesso JIT (Just In Time) da rede será monitorado pela Central de Segurança do Azure como recomendação | AuditIfNotExists; Desactivado | 3.0.0 |
PA-4: examinar e reconciliar o acesso do usuário regularmente
Para obter mais informações, consulte Acesso Privilegiado: PA-4: examine e reconcilie o acesso do usuário regularmente.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| As contas bloqueadas com permissões de proprietário em recursos do Azure devem ser removidas | Contas descontinuadas com permissões de proprietário devem ser removidas da sua assinatura. Contas descontinuadas são contas que foram impedidas de fazer login. | AuditIfNotExists; Desactivado | 1.0.0 |
| As contas bloqueadas com permissões de leitura e gravação em recursos do Azure devem ser removidas | Contas descontinuadas devem ser removidas de suas assinaturas. Contas descontinuadas são contas que foram impedidas de fazer login. | AuditIfNotExists; Desactivado | 1.0.0 |
| As contas de convidado com permissões de proprietário em recursos do Azure devem ser removidas | Contas externas com permissões de proprietário devem ser removidas da sua assinatura para evitar o acesso não monitorado. | AuditIfNotExists; Desactivado | 1.0.0 |
| As contas de convidado com permissões de leitura em recursos do Azure devem ser removidas | Contas externas com privilégios de leitura devem ser removidas da sua assinatura para evitar o acesso não monitorado. | AuditIfNotExists; Desactivado | 1.0.0 |
| As contas de convidado com permissões de gravação em recursos do Azure devem ser removidas | Contas externas com privilégios de gravação devem ser removidas da sua assinatura para evitar o acesso não monitorado. | AuditIfNotExists; Desactivado | 1.0.0 |
PA-7: Siga o princípio de administração suficiente (privilégio mínimo)
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 escopo para um produto ou uma API individual em vez de todas as APIs, o que pode resultar em uma exposição excessiva de dados. | Auditoria; Desactivado; Negar | 1.1.0 |
| Auditar o uso de funções personalizadas do RBAC | Auditar funções internas, como 'Proprietário, Contribuidor, 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 uma modelagem de ameaças | Auditoria; Desactivado | 1.0.1 |
| O Azure Key Vault deve usar o modelo de permissão RBAC | Habilite o modelo de permissão RBAC em Key Vaults. Saiba mais em: Migrar da política de acesso do cofre para um modelo de permissão de controle de acesso baseado em função do Azure | Auditoria; Negar; Desactivado | 1.0.1 |
| O RBAC (controle de acesso baseado em função) deve ser usado nos Serviços de Kubernetes | Para fornecer filtragem granular das ações que os usuários podem executar, use o RBAC (controle de acesso baseado em função) para gerenciar permissões nos clusters do Serviço de Kubernetes e configurar políticas de autorização relevantes. | Auditoria; Desactivado | 1.1.0 |
PV-2: auditar e impor configurações seguras
Para obter mais informações, consulte Postura e Gerenciamento de Vulnerabilidades: 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 estar 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 serviço. | Auditoria; Desactivado; Negar | 1.0.2 |
| Os aplicativos do Serviço de Aplicativo devem ter os 'Certificados do Cliente (Certificados do cliente recebidos)' habilitados | Os certificados de cliente permitem que o aplicativo solicite um certificado para solicitações recebidas. Somente clientes que possuem um certificado válido poderão acessar o aplicativo. Essa política se aplica a aplicativos com a versão Http definida como 1.1. | AuditIfNotExists; Desactivado | 1.0.0 |
| Os aplicativos do Serviço de Aplicativo devem ter a depuração remota desativada | A depuração remota exige que as portas de entrada estejam abertas em um aplicativo do Serviço de Aplicativo. A depuração remota deve ser desligada. | AuditIfNotExists; Desactivado | 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 recurso de origem cruzada (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; Desactivado | 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 Gerenciamento de API do Azure 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 na desativação da plataforma STV1 do Gerenciamento de API – Nuvem global do Azure (agosto de 2024) | Auditoria; Negar; Desactivado | 1.0.0 |
| Os clusters do Kubernetes habilitados para Azure Arc devem ter a extensão Azure Policy instalada | A extensão Azure Policy para Azure Arc fornece imposições em escala e proteções em seus clusters do Kubernetes habilitados para Arc de maneira centralizada e consistente. Saiba mais em Entender os clusters do Azure Policy para Kubernetes. | AuditIfNotExists; Desactivado | 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 | Certifique-se de que as instâncias de computação do Azure Machine Learning sejam executadas no sistema operacional mais recente disponível. A segurança é melhorada e as vulnerabilidades reduzidas pela execução dos últimos patches de segurança. Para obter mais informações, visite o gerenciamento de vulnerabilidades. | n/a | 1.0.3 |
| O Complemento do Azure Policy para o AKS (serviço de Kubernetes) deve estar instalado e habilitado nos clusters | O Complemento do Azure Policy para o AKS (serviço de Kubernetes) estende o Gatekeeper v3, um webhook do controlador de admissão para o OPA (Open Policy Agent), para aplicar as garantias e imposições em escala aos seus clusters de maneira centralizada e consistente. | Auditoria; Desactivado | 1.0.2 |
| Os aplicativos de funções devem ter a opção Certificados do Cliente (Certificados do cliente de entrada) habilitada | Os certificados de cliente permitem que o aplicativo solicite um certificado para solicitações recebidas. Somente clientes que possuem um certificado válido poderão acessar o aplicativo. Essa política se aplica a aplicativos com a versão Http definida como 1.1. | AuditIfNotExists; Desactivado | 1.1.0 |
| Os Aplicativos de funções devem ter a depuração remota desativada | A depuração remota exige que as portas de entrada estejam abertas em Aplicativos de funções. A depuração remota deve ser desligada. | AuditIfNotExists; Desactivado | 2.1.0 |
| Os aplicativos de funções não devem ter o CORS configurado para permitir que todos os recursos acessem seus aplicativos | O CORS (compartilhamento de recurso de origem cruzada) não deve permitir que todos os domínios acessem seu aplicativo de funções. Permitir que apenas os domínios necessários interajam com seu aplicativo de funções. | AuditIfNotExists; Desactivado | 2.1.0 |
| Os limites de recursos de CPU e memória de contêineres de cluster do Kubernetes não devem exceder os limites especificados | Impor limites de recursos de memória e CPU de contêiner para evitar ataques de esgotamento de recursos em um cluster do Kubernetes. Essa política está em disponibilidade geral para o AKS (Serviço do Kubernetes) e em versão prévia para o Azure Arc habilitado para Kubernetes. Para obter mais informações, consulte Noções básicas sobre o Azure Policy para clusters do Kubernetes. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 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 da ID do processo de host, o namespace de IPC do host e o namespace de rede do host em um cluster do Kubernetes. Essa recomendação se alinha aos Padrões de Segurança de Pod do Kubernetes 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 do Kubernetes. Essa política está em disponibilidade geral para o AKS (Serviço do Kubernetes) e em versão prévia para o Azure Arc habilitado para Kubernetes. Para obter mais informações, consulte Noções básicas sobre o Azure Policy para clusters do Kubernetes. | Auditoria; Negar; Desactivado | 6.0.0 |
| Os contêineres de cluster do Kubernetes devem usar somente os perfis do AppArmor permitidos | Os contêineres devem usar somente os perfis do AppArmor permitidos em um cluster do Kubernetes. Essa política está em disponibilidade geral para o AKS (Serviço do Kubernetes) e em versão prévia para o Azure Arc habilitado para Kubernetes. Para obter mais informações, consulte Noções básicas sobre o Azure Policy para clusters do Kubernetes. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 6.2.1 |
| Os contêineres de cluster do Kubernetes só devem usar recursos permitidos | Restringir as funcionalidades para reduzir a superfície de ataque de contêineres em um cluster do Kubernetes. Essa recomendação faz parte do CIS 5.2.8 e do CIS 5.2.9, que se destinam a aprimorar a segurança de seus ambientes do Kubernetes. Essa política está em disponibilidade geral para o AKS (Serviço do Kubernetes) e em versão prévia para o Azure Arc habilitado para Kubernetes. Para obter mais informações, consulte Noções básicas sobre o Azure Policy para clusters do Kubernetes. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 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 do Kubernetes a vulnerabilidades desconhecidas, problemas de segurança e imagens mal-intencionadas. Para obter mais informações, consulte Noções básicas sobre o Azure Policy para clusters do Kubernetes. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 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 protegê-los contra alterações em runtime com binários mal-intencionados sendo adicionados a PATH em um cluster do Kubernetes. Essa política está em disponibilidade geral para o AKS (Serviço do Kubernetes) e em versão prévia para o Azure Arc habilitado para Kubernetes. Para obter mais informações, consulte Noções básicas sobre o Azure Policy para clusters do Kubernetes. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 6.3.0 |
| Os volumes de hostPath do pod do cluster do Kubernetes devem usar somente os caminhos do host permitidos | Limite as montagens de volume de pod de HostPath aos caminhos de host permitidos em um cluster do Kubernetes. Essa política está em disponibilidade geral para o AKS (Serviço do Kubernetes) e para o Azure Arc habilitado para Kubernetes. Para obter mais informações, consulte Noções básicas sobre o Azure Policy para clusters do Kubernetes. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 6.3.0 |
| Os pods e os contêineres de cluster do Kubernetes devem ser executados somente com IDs de usuário e de grupo aprovadas | Controle as IDs de usuário, de grupo primário, de grupo complementar e de grupo do sistema de arquivos que os pods e os contêineres podem usar para a execução em um Cluster do Kubernetes. Essa política está em disponibilidade geral para o AKS (Serviço do Kubernetes) e em versão prévia para o Azure Arc habilitado para Kubernetes. Para obter mais informações, consulte Noções básicas sobre o Azure Policy para clusters do Kubernetes. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 6.2.0 |
| Os pods de cluster do Kubernetes devem usar apenas a rede de host e a lista de portas aprovadas | Restrinja o acesso de pod à rede de host e às portas de host permitidas em um cluster do Kubernetes. Essa recomendação faz parte do CIS 5.2.4, que se destina a melhorar a segurança de seus ambientes do Kubernetes e se alinha ao PSS (Padrões de Segurança de Pod) para hostPorts. Essa política está em disponibilidade geral para o AKS (Serviço do Kubernetes) e em versão prévia para o Azure Arc habilitado para Kubernetes. Para obter mais informações, consulte Noções básicas sobre o Azure Policy para clusters do Kubernetes. | Auditoria; Negar; Desactivado | 7.0.0 |
| Os serviços de cluster do Kubernetes devem escutar somente em portas permitidas | Restringir serviços para escutar somente nas portas permitidas para proteger o acesso ao cluster do Kubernetes. Essa política está em disponibilidade geral para o AKS (Serviço do Kubernetes) e em versão prévia para o Azure Arc habilitado para Kubernetes. Para obter mais informações, consulte Noções básicas sobre o Azure Policy para clusters do Kubernetes. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 8.2.0 |
| O cluster do Kubernetes não deve permitir contêineres privilegiados | Não permita a criação de contêineres com privilégios no cluster do Kubernetes. Essa recomendação faz parte do CIS 5.2.1, que se destina a aprimorar a segurança de seus ambientes do Kubernetes. Essa política está em disponibilidade geral para o AKS (Serviço do Kubernetes) e em versão prévia para o Azure Arc habilitado para Kubernetes. Para obter mais informações, consulte Noções básicas sobre o Azure Policy para clusters do Kubernetes. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 9.2.0 |
| Os clusters do Kubernetes devem desabilitar as credenciais de API montagem automática | Desabilite as credenciais da API de montagem automática para evitar que um recurso Pod potencialmente comprometido execute comandos de API em clusters do Kubernetes. Para obter mais informações, consulte Noções básicas sobre o Azure Policy para clusters do Kubernetes. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 4.2.0 |
| Os clusters do Kubernetes não devem permitir a elevação de privilégio de contêiner | Não permita que os contêineres sejam executados com escalonamento de privilégios para a raiz em um cluster do Kubernetes. Essa recomendação faz parte do CIS 5.2.5, que se destina a aprimorar a segurança de seus ambientes do Kubernetes. Essa política está em disponibilidade geral para o AKS (Serviço do Kubernetes) e em versão prévia para o Azure Arc habilitado para Kubernetes. Para obter mais informações, consulte Noções básicas sobre o Azure Policy para clusters do Kubernetes. | Auditoria; Negar; Desactivado | 8.0.0 |
| Os clusters do Kubernetes não devem conceder capacidades de segurança CAP_SYS_ADMIN | Para reduzir a superfície de ataque dos seus contêineres, restrinja as funcionalidades CAP_SYS_ADMIN do Linux. Para obter mais informações, consulte Noções básicas sobre o Azure Policy para clusters do Kubernetes. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 5.1.0 |
| Os clusters do Kubernetes não devem usar o namespace padrão | Impeça o uso do namespace padrão em clusters do Kubernetes para proteger contra acesso não autorizado para tipos de recursos ConfigMap, Pod, Segredo, Serviço e ServiceAccount. Para obter mais informações, consulte Noções básicas sobre o Azure Policy para clusters do Kubernetes. | auditoria; Auditoria; negar; Negar; desactivado; Desactivado | 4.2.0 |
PV-4: auditar e impor configurações seguras para recursos de computação
Para obter mais informações, consulte Postura e Gerenciamento de Vulnerabilidades: PV-4: auditar e impor configurações seguras para recursos de computação.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| A extensão de Configuração de Convidado deve ser instalada nos seus computadores | Para garantir configurações seguras de configurações no convidado de seu computador, instale a extensão de 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 a presença do aplicativo e as configurações do ambiente. Depois de instaladas, as políticas no convidado estarão disponíveis, como 'O Windows Exploit Guard deve estar habilitado'. Saiba mais em Entender a Configuração do Azure Machine. | AuditIfNotExists; Desactivado | 1.0.3 |
| Os computadores 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 de atribuição de política. Para obter detalhes, visite Noções básicas sobre a Configuração do Azure Machine. Os computadores não estarão em conformidade se não estiverem configurados corretamente para uma das recomendações na linha de base de segurança de computação do Azure. | AuditIfNotExists; Desactivado | 2.3.0 |
| A extensão de Configuração de Convidado das máquinas virtuais deve ser implantada com a identidade gerenciada atribuída ao sistema | A extensão de configuração de convidado exige uma identidade gerenciada atribuída ao sistema. As máquinas virtuais do Azure no escopo desta política não estarão em conformidade quando tiverem a extensão de Configuração de Convidado instalada, mas não tiverem uma identidade gerenciada atribuída ao sistema. Saiba mais em Entender a Configuração do Azure Machine | AuditIfNotExists; Desactivado | 1.0.1 |
| Os computadores 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 de atribuição de política. Para obter detalhes, visite Noções básicas sobre a Configuração do Azure Machine. Os computadores não estarão em conformidade se não estiverem configurados corretamente para uma das recomendações na linha de base de segurança de computação do Azure. | AuditIfNotExists; Desactivado | 2.1.0 |
| [Versão prévia]: os servidores do Azure Stack HCI devem ter políticas de controle de aplicativo implementadas com consistência | No mínimo, aplique a política básica do WDAC da Microsoft no modo implementado em todos os servidores do Azure Stack HCI. As políticas aplicadas do Controle de Aplicativos do Windows Defender (WDAC) devem ser consistentes em todos os servidores do mesmo cluster. | Auditoria; Desactivado; AuditIfNotExists | 1.0.0-preview |
| [Versão prévia]: os servidores do Azure Stack HCI devem cumprir os requisitos de núcleo seguro | Certifique-se de que todos os servidores do Azure Stack HCI cumpram os requisitos de núcleo seguro. Para habilitar os requisitos de servidor de núcleo protegido: 1. Na página de clusters do Azure Stack HCI, acesse o Windows Admin Center e selecione Conectar. 2 Acesse a extensão Segurança e selecione Núcleo Protegido. 3. Selecione qualquer configuração que não esteja habilitada e clique em Habilitar. | Auditoria; Desactivado; AuditIfNotExists | 1.0.0-preview |
| [Versão prévia]: A extensão Atestado de Convidado deve ser instalada nas máquinas virtuais do Linux com suporte | Instale a extensão Atestado de Convidado em máquinas virtuais do Linux compatíveis a fim de permitir que a Central de Segurança do Azure ateste e monitore de maneira proativa a integridade da inicialização. Após a instalação, a integridade da inicialização será atestada por meio do atestado remoto. Essa avaliação se aplica às máquinas virtuais do Linux Confidenciais e de Início Confiável. | AuditIfNotExists; Desactivado | 6.0.0-preview |
| [Versão prévia]: A extensão Atestado de Convidado deve ser instalada nos conjuntos de dimensionamento de máquinas virtuais do Linux com suporte | Instale a extensão Atestado de Convidado em conjuntos de dimensionamento de máquinas virtuais do Linux compatíveis a fim de permitir que a Central de Segurança do Azure ateste e monitore de maneira proativa a integridade da inicialização. Após a instalação, a integridade da inicialização será atestada por meio do atestado remoto. Essa avaliação se aplica aos conjuntos de dimensionamento de máquinas virtuais de início confiável e Linux Confidencial. | AuditIfNotExists; Desactivado | 5.1.0-preview |
| [Versão prévia]: A extensão Atestado de Convidado deve ser instalada em máquinas virtuais do Windows com suporte | Instale a extensão Atestado de Convidado em máquinas virtuais compatíveis a fim de permitir que a Central de Segurança do Azure ateste e monitore de maneira proativa a integridade da inicialização. Após a instalação, a integridade da inicialização será atestada por meio do atestado remoto. Essa avaliação se aplica às máquinas virtuais do Windows Confidenciais e de Início Confiável. | AuditIfNotExists; Desactivado | 4.0.0-preview |
| [Versão prévia]: A extensão Atestado de Convidado deve ser instalada nos conjuntos de dimensionamento de máquinas virtuais do Windows com suporte | Instale a extensão Atestado de Convidado em conjuntos de dimensionamento de máquinas virtuais compatíveis a fim de permitir que a Central de Segurança do Azure ateste e monitore de maneira proativa a integridade da inicialização. Após a instalação, a integridade da inicialização será atestada por meio do atestado remoto. Essa avaliação se aplica aos conjuntos de dimensionamento de máquinas virtuais de início confiável e Windows Confidencial. | AuditIfNotExists; Desactivado | 3.1.0-preview |
| [Versão prévia]: As máquinas virtuais do Linux devem usar somente componentes de inicialização confiáveis e assinados | Todos os componentes de inicialização do sistema operacional (carregador de inicialização, kernel, drivers do kernel) devem ser assinados por fornecedores confiáveis. O Defender para Nuvem identificou componentes de inicialização de sistema operacional não confiáveis em um ou mais de seus computadores Linux. Para proteger seus computadores contra componentes potencialmente mal-intencionados, adicione-os à lista de permissão ou remova os componentes identificados. | AuditIfNotExists; Desactivado | 1.0.0-preview |
| [Versão prévia]: A Inicialização Segura deve estar habilitada em Máquinas Virtuais do Windows com suporte | Habilite a Inicialização Segura nas máquinas virtuais do Windows compatíveis para atenuar alterações mal-intencionadas e não autorizadas na cadeia de inicialização. Depois que ele for habilitado, somente os carregadores de inicialização, o kernel e os drivers de kernel poderão ser executados. Essa avaliação se aplica às máquinas virtuais do Windows Confidenciais e de Início Confiável. | Auditoria; Desactivado | 4.0.0-preview |
| [Versão prévia]: O vTPM deve estar habilitado nas máquinas virtuais com suporte | Habilite o dispositivo TPM virtual em máquinas virtuais compatíveis para facilitar Inicialização Medida e outros recursos de segurança do sistema operacional que exigem um TPM. Depois que ele for habilitado, o vTPM pode ser usado para atestar a integridade da inicialização. Essa avaliação só se aplica a máquinas virtuais habilitadas para início confiável. | Auditoria; Desactivado | 2.0.0-preview |
PV-5: executar avaliações de vulnerabilidade
Para obter mais informações, consulte Postura e Gerenciamento de Vulnerabilidades: PV-5: executar avaliações de vulnerabilidade.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| Uma solução de avaliação de vulnerabilidade deve ser habilitada nas máquinas virtuais | Audita as máquinas virtuais para detectar se elas estão executando uma solução de avaliação de vulnerabilidade compatível. Um componente principal de cada programa de segurança e risco cibernético é a identificação e a análise das vulnerabilidades. O tipo de preço padrão da Central de Segurança do Azure inclui a verificação de vulnerabilidade para as máquinas virtuais sem custo adicional. Além disso, a Central de Segurança pode implantar essa ferramenta automaticamente para você. | AuditIfNotExists; Desactivado | 3.0.0 |
| Os computadores devem ter as descobertas secretas resolvidas | Audita máquinas virtuais para detectar se elas contêm descobertas secretas das soluções de verificação do segredo em suas máquinas virtuais. | AuditIfNotExists; Desactivado | 1.0.2 |
| A avaliação de vulnerabilidades deve estar habilitada na Instância Gerenciada de SQL | Audite cada Instância Gerenciada de SQL que não tem verificações recorrentes de avaliação de vulnerabilidade habilitadas. A avaliação de vulnerabilidades pode descobrir, acompanhar e ajudar a corrigir possíveis vulnerabilidades do banco de dados. | AuditIfNotExists; Desactivado | 1.0.1 |
| A avaliação da vulnerabilidade deve ser habilitada nos servidores SQL | Audite os servidores SQL do Azure sem verificações recorrentes de avaliação de vulnerabilidade ativadas. A avaliação de vulnerabilidades pode descobrir, acompanhar e ajudar a corrigir possíveis vulnerabilidades do banco de dados. | AuditIfNotExists; Desactivado | 3.0.0 |
PV-6: corrigir vulnerabilidades de forma rápida e automática
Para obter mais informações, consulte Postura e Gerenciamento de Vulnerabilidades: PV-6: corrigir vulnerabilidades de forma rápida e automática.
| Nome | Description | Effect(s) | Versão |
|---|---|---|---|
| As imagens de contêiner do Registro do Azure devem ter vulnerabilidades resolvidas (alimentadas pelo Gerenciamento de Vulnerabilidades do Microsoft Defender) | A avaliação de vulnerabilidade das imagens de contêiner examina seu registro em busca de vulnerabilidades comumente conhecidas (CVEs) e fornece um relatório detalhado de vulnerabilidades 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; Desactivado | 1.0.1 |
| As imagens de contêiner em execução do Azure devem ter vulnerabilidades resolvidas (alimentadas pelo Gerenciamento de Vulnerabilidades do Microsoft Defender) | A avaliação de vulnerabilidade das imagens de contêiner examina seu registro em busca de vulnerabilidades comumente conhecidas (CVEs) e fornece um relatório detalhado de vulnerabilidades para cada imagem. Essa recomendação fornece visibilidade para as imagens vulneráveis atualmente em execução nos seus clusters do Kubernetes. Corrigir vulnerabilidades em imagens de contêiner que estão em execução no momento é fundamental para aprimorar sua postura de segurança, reduzindo de forma significativa a superfície de ataque das suas cargas de trabalho conteinerizadas. | AuditIfNotExists; Desactivado | 1.0.1 |
| Os computadores devem ser configurados para verificar periodicamente se há atualizações ausentes do sistema | Para garantir que as avaliações periódicas de atualizações do sistema ausentes sejam disparadas 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 patch do Windows para Linux: modo de avaliação de patch do Linux. | Auditoria; Negar; Desactivado | 3.9.0 |
| Os bancos de dados SQL devem ter as descobertas de vulnerabilidade resolvidas | Monitore os resultados da verificação da avaliação de vulnerabilidades e as recomendações sobre como corrigir as vulnerabilidades do banco de dados. | AuditIfNotExists; Desactivado | 4.1.0 |
| Os servidores SQL em computadores devem ter as descobertas de vulnerabilidade resolvidas | A avaliação de vulnerabilidades do SQL examina o banco de dados em busca de vulnerabilidades de segurança e expõe os desvios das melhores práticas como configurações incorretas, permissões excessivas e dados confidenciais desprotegidos. Resolver as vulnerabilidades encontradas pode melhorar muito a postura de segurança de seu banco de dados. | AuditIfNotExists; Desactivado | 1.0.0 |
| As atualizações do sistema devem ser instaladas em suas máquinas (impulsionado pelo Centro de Atualização) | As atualizações de sistema, segurança e críticas estão ausentes em seus computadores. As atualizações de software geralmente incluem patches críticos para brechas de segurança. Essas brechas costumam ser exploradas em ataques de malware, portanto, é vital manter seu software atualizado. Para instalar todos os patches pendentes e proteger seus computadores, siga as etapas de correção. | AuditIfNotExists; Desactivado | 1.0.1 |
Próximas etapas
- Examine o parâmetro de comparação de segurança de nuvem da Microsoft para obter mais informações sobre detalhes do controle.
- Atribuir políticas por meio do portal do Azure
- Saiba mais sobre o Azure Policy