Partilhar via

Segurança no Banco de Dados do Azure para PostgreSQL - Servidor Flexível

  • Artigo

APLICA-SE A: Banco de Dados do Azure para PostgreSQL - Servidor Flexível

Várias camadas de segurança estão disponíveis para ajudar a proteger os dados em seu Banco de Dados do Azure para PostgreSQL - instância do Servidor Flexível. Este artigo destaca essas opções de segurança.

À medida que as organizações dependem cada vez mais de dados armazenados em bancos de dados para impulsionar atividades críticas de tomada de decisão que geram vantagem competitiva, a necessidade de medidas sólidas de segurança de banco de dados nunca foi tão importante. Um lapso de segurança pode desencadear consequências catastróficas, incluindo a exposição de dados confidenciais, causando danos reputacionais à organização.

Proteção e encriptação de informações

O Banco de Dados do Azure para PostgreSQL - Servidor Flexível criptografa dados de duas maneiras:

  • Dados em trânsito: o Banco de Dados do Azure para PostgreSQL - Servidor Flexível criptografa dados em trânsito com Secure Sockets Layer e Transport Layer Security (SSL/TLS). A encriptação é imposta por predefinição. Para obter informações mais detalhadas sobre segurança de conexão com SSL\TLS, consulte esta documentação. Para maior segurança, você pode optar por habilitar a autenticação SCRAM no Banco de Dados do Azure para PostgreSQL - Servidor Flexível.

    Embora não seja altamente recomendado, se necessário, devido à incompatibilidade do cliente herdado, você tem uma opção para desabilitar TLS\SSL para conexões com o Banco de Dados do Azure para PostgreSQL - Servidor Flexível atualizando o require_secure_transport parâmetro do servidor para OFF. Você também pode definir a versão TLS definindo ssl_max_protocol_version os parâmetros do servidor.

  • Dados em repouso: para criptografia de armazenamento, o Banco de Dados do Azure para PostgreSQL - Servidor Flexível usa o módulo criptográfico validado FIPS 140-2. Os dados são encriptados no disco, incluindo cópias de segurança e os ficheiros temporários criados enquanto as consultas estão em execução.

    O serviço usa o modo Galois/Counter Mode (GCM) com cifra AES de 256 bits incluída na criptografia de armazenamento do Azure e as chaves são gerenciadas pelo sistema. O funcionamento é semelhante a outras tecnologias de encriptação inativa, como encriptação de dados transparentes no SQL Server ou bases de dados Oracle. A encriptação de armazenamento está sempre ativada e não pode ser desativada.

Segurança da rede

Quando estiver a executar a Base de Dados do Azure para PostgreSQL – Servidor Flexível, tem duas opções de rede principais:

  • Acesso privado: pode implementar o servidor numa rede virtual do Azure. As redes virtuais do Azure ajudam a permitir uma comunicação de rede privada e segura. Os recursos numa rede virtual podem comunicar através de endereços IP privados. Para obter mais informações, consulte a visão geral de rede do Banco de Dados do Azure para PostgreSQL - Servidor Flexível.

    As regras de segurança em grupos de segurança de rede permitem-lhe filtrar o tipo de tráfego que pode fluir de/para as sub-redes da rede virtual e as interfaces de rede. Para obter mais informações, consulte a visão geral dos grupos de segurança de rede.

  • Acesso público: pode aceder ao servidor através de um ponto final público. O ponto final público é um endereço DNS publicamente resolvível. O acesso a ele é protegido por meio de um firewall que bloqueia todas as conexões por padrão.

    As regras de firewall de IP concedem acesso ao servidor com base no endereço IP de origem de cada pedido. Para obter mais informações, consulte a visão geral das regras de firewall.

Suporte do Microsoft Defender for Cloud

O Microsoft Defender para bancos de dados relacionais de código aberto deteta atividades anômalas indicando tentativas incomuns e potencialmente prejudiciais de acessar ou explorar bancos de dados. O Defender for Cloud fornece alertas de segurança sobre atividades anômalas para que você possa detetar ameaças potenciais e responder a elas à medida que ocorrem. Quando você habilita esse plano, o Defender for Cloud fornece alertas quando deteta padrões anômalos de acesso e consulta ao banco de dados e atividades suspeitas do banco de dados.

Estes alertas aparecem na página de alertas de segurança do Defender for Cloud e incluem:

  • Detalhes da atividade suspeita que os desencadeou
  • A tática associada MITRE ATT&CK
  • Ações recomendadas para investigar e mitigar a ameaça
  • Opções para continuar suas investigações com o Microsoft Sentinel

Microsoft Defender para ataques de nuvem e força bruta

Um ataque de força bruta está entre os métodos de hacking mais comuns e bastante bem-sucedidos, apesar de serem métodos de hacking menos sofisticados. A teoria por trás de tal ataque é que se você fizer um número infinito de tentativas para adivinhar uma senha, você está fadado a estar certo eventualmente. Quando o Microsoft Defender for Cloud deteta um ataque de força bruta, ele aciona um alerta para informá-lo de que um ataque de força bruta ocorreu. Ele também pode separar o ataque de força bruta simples do ataque de força bruta a um utilizador válido ou um ataque de força bruta bem-sucedido.

Para receber alertas do plano Microsoft Defender, primeiro você precisará ativá-lo , conforme mostrado na próxima seção.

Habilite a segurança aprimorada com o Microsoft Defender for Cloud

  1. No portal do Azure, navegue até o menu Segurança no painel esquerdo
  2. Escolha o Microsoft Defender for Cloud
  3. No painel do lado direito, selecione Ativar.

Captura de ecrã do portal do Azure a mostrar como ativar o Cloud Defender.

Nota

Se você tiver o recurso "bancos de dados relacionais de código aberto" habilitado em seu plano do Microsoft Defender, observará que o Microsoft Defender é habilitado automaticamente por padrão para seu recurso de servidor flexível do Banco de Dados do Azure para PostgreSQL.

Gestão de acesso

A melhor maneira de gerenciar o Banco de Dados do Azure para PostgreSQL - permissões de acesso ao banco de dados do Servidor Flexível em escala é usando o conceito de funções. Uma função pode ser um usuário de banco de dados ou um grupo de usuários de banco de dados. As funções podem possuir os objetos de banco de dados e atribuir privilégios nesses objetos a outras funções para controlar quem tem acesso a quais objetos. Também é possível conceder associação em uma função a outra função, permitindo que a função de membro use privilégios atribuídos a outra função. O Banco de Dados do Azure para PostgreSQL - Servidor Flexível permite conceder permissões diretamente aos usuários do banco de dados. Como uma boa prática de segurança, pode ser recomendado que você crie funções com conjuntos específicos de permissões com base nos requisitos mínimos de aplicativo e acesso. Em seguida, você pode atribuir as funções apropriadas a cada usuário. As funções são usadas para impor um modelo de privilégios mínimos para acessar objetos de banco de dados.

A instância do Banco de Dados do Azure para PostgreSQL - Servidor Flexível é criada com as três funções padrão definidas, além das funções internas criadas pelo PostgreSQL. Você pode ver essas funções executando o comando:

SELECT rolname FROM pg_roles;

As funções estão listadas abaixo:

  • azure_pg_admin
  • Azuresu
  • Função de administrador

Ao criar o Banco de Dados do Azure para PostgreSQL - instância de Servidor Flexível, você fornece credenciais para uma função de administrador. Esta função de administrador pode ser utilizada para criar mais funções do PostgreSQL.

Por exemplo, abaixo podemos criar um exemplo de usuário/função chamado 'demouser'


 CREATE USER demouser PASSWORD password123;

A função de administrador nunca deve ser usada pelo aplicativo.

Em ambientes PaaS baseados em nuvem, o acesso a um Banco de Dados do Azure para PostgreSQL - Conta de superusuário do Servidor Flexível é restrito para controlar operações de plano apenas por operadores de nuvem. Portanto, a azure_pg_admin conta existe como uma conta de pseudo-superusuário. Sua função de administrador é um membro da azure_pg_admin função.
No entanto, a conta de administrador do servidor não faz parte da azuresu função, que tem privilégios de superusuário e é usada para executar operações de plano de controle. Como esse serviço é um serviço PaaS gerenciado, apenas a Microsoft faz parte da função de superusuário.

Você pode auditar periodicamente a lista de funções no servidor. Por exemplo, você pode se conectar usando psql o cliente e consultar a pg_roles tabela, que lista todas as funções, juntamente com privilégios como criar outras funções, criar bancos de dados, replicação etc.


select * from pg_roles where rolname='demouser';
-[ RECORD 1 ]--+---------
rolname        | demouser
rolsuper       | f
rolinherit     | t
rolcreaterole  | f
rolcreatedb    | f
rolcanlogin    | f
rolreplication | f
rolconnlimit   | -1
rolpassword    | ********
rolvaliduntil  |
rolbypassrls   | f
rolconfig      |
oid            | 24827

Importante

Recentemente, a capacidade de criar comandos CAST foi habilitada no Banco de Dados do Azure para o Servidor Flexível PostgreSQL. Para executar a instrução CREATE CAST, o usuário deve ser membro do grupo azure_pg_admin . Por favor, esteja ciente de que, atualmente, não é possível descartar um CAST depois que ele foi criado.

O log de auditoria no Banco de Dados do Azure para PostgreSQL - Servidor Flexível também está disponível com o Banco de Dados do Azure para PostgreSQL - Servidor Flexível para rastrear a atividade em seus bancos de dados.

Controlar o acesso ao esquema

Os bancos de dados recém-criados no Banco de Dados do Azure para PostgreSQL - Servidor Flexível têm um conjunto padrão de privilégios no esquema público do banco de dados que permite que todos os usuários e funções do banco de dados criem objetos. Para limitar melhor o acesso do usuário do aplicativo aos bancos de dados que você cria em seu Banco de Dados do Azure para PostgreSQL - instância do Servidor Flexível, recomendamos que você considere revogar esses privilégios públicos padrão. Depois de fazer isso, você pode conceder privilégios específicos para usuários de banco de dados em uma base mais granular. Por exemplo:

  • Para impedir que os usuários do banco de dados do aplicativo criem objetos no esquema público, revogue os privilégios de criação para public o esquema da public função.

    REVOKE CREATE ON SCHEMA public FROM PUBLIC;

  • Em seguida, crie um novo banco de dados.

    CREATE DATABASE Test_db;

  • Revogue todos os privilégios do esquema PUBLIC neste novo banco de dados.

    REVOKE ALL ON DATABASE Test_db FROM PUBLIC;

  • Criar função personalizada para usuários do banco de dados do aplicativo

    CREATE ROLE Test_db_user;

  • Dê aos usuários do banco de dados com essa função a capacidade de se conectar ao banco de dados.

    GRANT CONNECT ON DATABASE Test_db TO Test_db_user;
GRANT ALL PRIVILEGES ON DATABASE Test_db TO Test_db_user;

  • Criar usuário de banco de dados

    CREATE USER user1 PASSWORD 'Password_to_change'

  • Atribuir função, com seus privilégios de conexão e seleção ao usuário

    GRANT Test_db_user TO user1;

Neste exemplo, o usuário user1 pode se conectar e tem todos os privilégios em nosso banco de dados de teste Test_db, mas não qualquer outro db no servidor. Recomenda-se ainda, em vez de dar a este usuário\função TODOS os PRIVILÉGIOS nesse banco de dados e seus objetos, fornecer permissões mais seletivas, como SELECT,INSERT,EXECUTE, etc. Para obter mais informações sobre privilégios em bancos de dados PostgreSQL, consulte os comandos GRANT e REVOKE nos documentos do PostgreSQL.

Alterações de propriedade do esquema público no PostgreSQL 15

A partir da versão 15 do Postgres, a propriedade do esquema público foi alterada para a nova função pg_database_owner. Ele permite que cada proprietário de banco de dados possua o esquema público do banco de dados.
Mais informações podem ser encontradas nas notas de versão do PostgreSQL.

Alterações do PostgreSQL 16 com segurança baseada em função

Na função de banco de dados PostgreSQL pode ter muitos atributos que definem seus privilégios. Um desses atributos é o atributo CREATEROLE, que é importante para o gerenciamento de banco de dados PostgreSQL de usuários e funções. No PostgreSQL 16 foram introduzidas alterações significativas neste atributo. No PostgreSQL 16, os usuários com o atributo CREATEROLE não têm mais a capacidade de distribuir associação em qualquer função para ninguém, em vez disso, como outros usuários, sem esse atributo, eles só podem distribuir associações em funções para as quais possuem ADMIN OPTION. Além disso, no PostgreSQL 16, o atributo CREATEROLE ainda permite que um não-superusuário tenha a capacidade de provisionar novos usuários, no entanto, eles só podem descartar usuários que eles mesmos criaram. As tentativas de descartar usuários, que não são criadas pelo usuário com o atributo CREATEROLE , resultarão em um erro.

O PostgreSQL 16 também introduziu funções internas novas e aprimoradas. Nova função pg_use_reserved_connections no PostgreSQL 16 permite o uso de slots de conexão reservados via reserved_connections. A função pg_create_subscription permite que os superusuários criem assinaturas.

Importante

O Banco de Dados do Azure para PostgreSQL - Servidor Flexível não permite que os usuários recebam pg_write_all_data atributo, que permite ao usuário gravar todos os dados (tabelas, exibições, sequências), como se tivesse direitos INSERT, UPDATE e DELETE nesses objetos e direitos USAGE em todos os esquemas, mesmo sem tê-lo explicitamente concedido. Como uma solução alternativa recomendada para conceder permissões semelhantes em um nível mais finito por banco de dados e objeto.

Segurança ao nível da linha

A segurança em nível de linha (RLS) é um recurso de segurança do Banco de Dados do Azure para PostgreSQL - Servidor Flexível que permite que os administradores de banco de dados definam políticas para controlar como linhas específicas de dados são exibidas e operam para uma ou mais funções. A segurança em nível de linha é um filtro adicional que você pode aplicar a um Banco de Dados do Azure para PostgreSQL - Tabela de banco de dados do Servidor Flexível. Quando um usuário tenta executar uma ação em uma tabela, esse filtro é aplicado antes dos critérios de consulta ou outra filtragem e os dados são reduzidos ou rejeitados de acordo com sua política de segurança. Você pode criar políticas de segurança em nível de linha para comandos específicos como SELECT, INSERT, UPDATE e DELETE, especificá-lo para TODOS os comandos. Os casos de uso para segurança em nível de linha incluem implementações compatíveis com PCI, ambientes classificados e hospedagem compartilhada / aplicativos multilocatário.

Somente usuários com SET ROW SECURITY direitos podem aplicar direitos de segurança de linha a uma tabela. O proprietário da tabela pode definir a segurança da linha em uma tabela. Como OVERRIDE ROW SECURITY este é atualmente um direito implícito. A segurança em nível de linha não substitui as permissões existentes GRANT , ela adiciona um nível de controle mais refinado. Por exemplo, a configuração ROW SECURITY FOR SELECT para permitir que um determinado usuário conceda linhas só daria acesso a esse usuário se o usuário também tiver SELECT privilégios na coluna ou tabela em questão.

Veja um exemplo que mostra como criar uma política que garante que apenas os membros da função "gerente" personalizada possa acessar apenas as linhas de uma conta específica. O código no exemplo a seguir foi compartilhado na documentação do PostgreSQL.

CREATE TABLE accounts (manager text, company text, contact_email text);

ALTER TABLE accounts ENABLE ROW LEVEL SECURITY;

CREATE POLICY account_managers ON accounts TO managers
    USING (manager = current_user);

A cláusula USING adiciona implicitamente uma WITH CHECK cláusula, garantindo que os membros da função de gerente não possam executar SELECT, DELETEou UPDATE operações em linhas que pertencem a outros gerentes e não INSERT possam novas linhas pertencentes a outro gerente. Você pode soltar uma política de segurança de linha usando o comando DROP POLICY, como em seu exemplo:



DROP POLICY account_managers ON accounts;

Embora você possa ter descartado a política, o gerenciador de funções ainda não é capaz de exibir quaisquer dados que pertençam a qualquer outro gerente. Isso ocorre porque a diretiva de segurança em nível de linha ainda está habilitada na tabela de contas. Se a segurança em nível de linha estiver habilitada por padrão, o PostgreSQL usará uma política de negação padrão. Você pode desativar a segurança em nível de linha, como no exemplo abaixo:

ALTER TABLE accounts DISABLE ROW LEVEL SECURITY;

Ignorando a segurança em nível de linha

O PostgreSQL tem permissões BYPASSRLS e NOBYPASSRLS , que podem ser atribuídas a uma função; NOBYPASSRLS é atribuído por padrão. Com servidores recém-provisionados no Banco de Dados do Azure para PostgreSQL - Servidor Flexível ignorando o privilégio de segurança em nível de linha (BYPASSRLS) é implementado da seguinte maneira:

  • Para servidores versionados Postgres 16 e superiores, seguimos o comportamento padrão do PostgreSQL 16. Os usuários não administrativos criados por azure_pg_admin função de administrador permitem que você crie funções com atributo BYPASSRLS\privilégio conforme necessário.
  • Para servidores versionados Postgres 15 e inferiores. , você pode usar azure_pg_admin usuário para executar tarefas administrativas que exigem privilégio BYPASSRLS, mas não pode criar usuários não administradores com privilégio BypassRLS, uma vez que a função de administrador não tem privilégios de superusuário, como comum em serviços PostgreSQL PaaS baseados em nuvem.

Atualizar palavras-passe

Para maior segurança, é uma boa prática alternar periodicamente sua senha de administrador e senhas de usuários do banco de dados. Recomenda-se o uso de senhas fortes usando maiúsculas e minúsculas, números e caracteres especiais.

Usar SCRAM

O Salted Challenge Response Authentication Mechanism (SCRAM) melhora consideravelmente a segurança da autenticação de usuário baseada em senha, adicionando vários recursos de segurança importantes que impedem ataques de mesa arco-íris, ataques man-in-the-middle e ataques de senha armazenada, além de adicionar suporte para vários algoritmos de hash e senhas que contêm caracteres não-ASCII.

Na autenticação SCRAM, o cliente participa do trabalho de criptografia para produzir a prova de identidade. Portanto, a autenticação SCRAM descarrega parte do custo de computação para seus clientes, que na maioria dos casos são servidores de aplicativos. A adoção do SCRAM, além de um algoritmo de hash mais forte, oferece também proteção contra ataques distribuídos de negação de serviço (DDoS) contra o PostgreSQL, evitando uma sobrecarga da CPU do servidor para calcular hashes de senha.

Se o driver do cliente oferecer suporte à SCRAM, você poderá configurar o acesso ao Banco de Dados do Azure para PostgreSQL - Servidor Flexível usando a SCRAM como scram-sha-256 versus padrãomd5.

Redefinir senha de administrador

Siga o guia de como redefinir a senha de administrador.

Atualizar senha de usuário do banco de dados

Você pode usar ferramentas de cliente para atualizar senhas de usuário do banco de dados.
Por exemplo,

ALTER ROLE demouser PASSWORD 'Password123!';
ALTER ROLE

Suporte do Azure Policy

A Política do Azure ajuda a impor padrões organizacionais e a avaliar a conformidade em escala. Através do dashboard de conformidade, proporciona uma visão agregada para avaliar o estado geral do ambiente, com a capacidade de desagregar a granularidade por recurso e por política. Também ajuda a fazer com que os recursos fiquem em conformidade através da remediação em massa dos recursos existentes e da reparação automática dos recursos novos.

Definições de política incorporadas

As políticas internas são desenvolvidas e testadas pela Microsoft, garantindo que atendam a padrões comuns e práticas recomendadas, e sejam implantadas rapidamente sem a necessidade de configuração adicional, tornando-as ideais para requisitos de conformidade padrão. As políticas incorporadas geralmente abrangem padrões e estruturas de conformidade amplamente reconhecidos.

A seção abaixo fornece um índice das definições de política interna da Política do Azure para o Banco de Dados do Azure para PostgreSQL - Servidor Flexível. Use o link na coluna Origem para exibir a fonte no repositório GitHub da Política do Azure.

Nome (Portal do Azure) Descrição Efeito(s) Versão (GitHub)
Um administrador do Microsoft Entra deve ser provisionado para servidores flexíveis PostgreSQL Provisionamento de auditoria de um administrador do Microsoft Entra para seu servidor flexível PostgreSQL para habilitar a autenticação do Microsoft Entra. A autenticação do Microsoft Entra permite o gerenciamento simplificado de permissões e o gerenciamento centralizado de identidades de usuários de banco de dados e outros serviços da Microsoft AuditIfNotExists, desativado 1.0.0
A auditoria com PgAudit deve ser habilitada para servidores flexíveis PostgreSQL Esta política ajuda a auditar quaisquer servidores flexíveis PostgreSQL em seu ambiente, que não está habilitado para usar pgaudit. AuditIfNotExists, desativado 1.0.0
A limitação de conexão deve ser habilitada para servidores flexíveis PostgreSQL Esta política ajuda a auditar quaisquer servidores flexíveis PostgreSQL em seu ambiente sem a limitação de conexão habilitada. Essa configuração permite a limitação temporária de conexão por IP para muitas falhas de login de senha inválidas AuditIfNotExists, desativado 1.0.0
Implantar configurações de diagnóstico para servidores flexíveis PostgreSQL no espaço de trabalho do Log Analytics Implanta as configurações de diagnóstico para servidores flexíveis PostgreSQL para transmitir para um espaço de trabalho regional do Log Analytics quando qualquer servidor flexível PostgreSQL, que está faltando essa configuração de diagnóstico, é criado ou atualizado DeployIfNotExists, desativado 1.0.0
As desconexões devem ser registradas para servidores flexíveis PostgreSQL Esta política ajuda a auditar quaisquer servidores flexíveis PostgreSQL em seu ambiente sem log_disconnections habilitados AuditIfNotExists, desativado 1.0.0
Impor conexão SSL deve ser habilitado para servidores flexíveis PostgreSQL O Banco de Dados do Azure para PostgreSQL dá suporte à conexão do seu servidor flexível do Banco de Dados do Azure para PostgreSQL a aplicativos cliente usando SSL (Secure Sockets Layer). Impor conexões SSL entre seu servidor flexível de banco de dados e seus aplicativos cliente ajuda a proteger contra ataques "man in the middle", criptografando o fluxo de dados entre o servidor e seu aplicativo. Essa configuração impõe que o SSL esteja sempre habilitado para acessar seu servidor flexível PostgreSQL AuditIfNotExists, desativado 1.0.0
O backup com redundância geográfica deve ser habilitado para o Banco de Dados do Azure para servidores flexíveis PostgreSQL O Banco de Dados do Azure para servidores flexíveis PostgreSQL permite que você escolha a opção de redundância para seu servidor de banco de dados. Ele pode ser definido como um armazenamento de backup com redundância geográfica no qual os dados não são apenas armazenados na região em que o servidor está hospedado, mas também são replicados para uma região emparelhada para fornecer opção de recuperação em caso de falha de região. A configuração do armazenamento com redundância geográfica para backup só é permitida durante a criação do servidor Auditoria, Desativado 1.0.0
Os pontos de verificação de log devem ser habilitados para servidores flexíveis PostgreSQL Esta política ajuda a auditar quaisquer servidores flexíveis PostgreSQL em seu ambiente sem log_checkpoints configuração habilitada AuditIfNotExists, desativado 1.0.0
As conexões de log devem ser habilitadas para servidores flexíveis PostgreSQL Esta política ajuda a auditar quaisquer servidores flexíveis PostgreSQL em seu ambiente sem log_connections configuração habilitada AuditIfNotExists, desativado 1.0.0
Os servidores PostgreSQL FlexIble devem usar chaves gerenciadas pelo cliente para criptografar dados em repouso Use chaves gerenciadas pelo cliente para gerenciar a criptografia em repouso de seus servidores flexíveis PostgreSQL. Por padrão, os dados são criptografados em repouso com chaves gerenciadas por serviço, mas as chaves gerenciadas pelo cliente geralmente são necessárias para atender aos padrões de conformidade regulamentar. As chaves gerenciadas pelo cliente permitem que os dados sejam criptografados com uma chave do Cofre de Chaves do Azure criada e de sua propriedade. Você tem total controle e responsabilidade pelo ciclo de vida da chave, incluindo rotação e gerenciamento Auditoria, Negar, Desativado 1.0.0
Os servidores flexíveis PostgreSQL devem estar executando o TLS versão 1.2 ou mais recente Esta política ajuda a auditar quaisquer servidores flexíveis PostgreSQL em seu ambiente, que está sendo executado com TLS versão inferior a 1.2 AuditIfNotExists, desativado 1.0.0
Ponto de extremidade privado deve ser habilitado para servidores flexíveis PostgreSQL As conexões de ponto de extremidade privado impõem uma comunicação segura habilitando a conectividade privada com o Banco de Dados do Azure para PostgreSQL. Configure uma conexão de ponto de extremidade privada para habilitar o acesso ao tráfego proveniente apenas de redes conhecidas e impedir o acesso de todos os outros endereços IP, inclusive no Azure AuditIfNotExists, desativado 1.0.0

Definições de política personalizadas

As políticas personalizadas podem ser adaptadas com precisão para atender aos requisitos específicos da sua organização, incluindo políticas de segurança exclusivas ou mandatos de conformidade. Com políticas personalizadas, você tem controle total sobre a lógica e os parâmetros da política, permitindo definições de política sofisticadas e refinadas.

Conteúdos relacionados