Compartilhar 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

Há várias camadas de segurança disponíveis para ajudar a proteger os dados em sua instância do Banco de Dados do Azure para PostgreSQL - Servidor Flexível. Este artigo descreve 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 expor dados confidenciais, causando danos à reputação da organização.

Proteção e criptografia de informações

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

  • Dados em trânsito: o Banco de Dados do Azure para PostgreSQL - Servidor Flexível criptografa os dados em trânsito com os protocolos SSL e TLS. A criptografia é imposta por padrão. Para obter informações mais detalhadas sobre segurança de conexão com SSL\TLS, consulte esta documentação. Para obter uma melhor segurança, você pode optar por habilitar a autenticação SCRAM no Banco de Dados do Azure para PostgreSQL – Servidor Flexível.

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

  • Dados inativos: para criptografia de armazenamento, o Banco de Dados do Azure para PostgreSQL - Servidor Flexível usa o módulo criptográfico validado pelo FIPS 140-2. Os dados, incluindo backups, são criptografados no disco, assim como os arquivos temporários criados durante a execução de consultas.

    O serviço usa o modo Galois/Modo de Contador (GCM) com a criptografia de 256 bits do AES incluída na criptografia de armazenamento do Azure e as chaves são gerenciadas pelo sistema. Isso é semelhante a outras tecnologias de criptografia de dados inativos, como a TDE (Transparent Data Encryption) em bancos de dados do SQL Server ou Oracle. A criptografia de armazenamento está sempre ativada e não pode ser desabilitada.

Segurança de rede

Ao executar o Banco de Dados do Azure para PostgreSQL – Servidor Flexível, você tem duas opções de rede principais:

  • Acesso privado: você pode implantar seu servidor flexível em uma rede virtual do Azure. As redes virtuais do Azure fornecem comunicação de rede privada e segura. Os recursos em uma rede virtual podem se comunicar por meio de endereços IP privados. Para mais informações, confira Visão geral da rede – Banco de Dados do Azure para PostgreSQL – Servidor flexível.

    As regras de segurança em grupos de segurança de rede permitem filtrar o tipo de tráfego de rede que pode fluir para dentro e fora das sub-redes da rede virtual e dos adaptadores de rede. Para saber mais, confira Visão geral dos grupo de segurança de rede.

  • Acesso público: o servidor flexível pode ser acessado por meio de um ponto de extremidade público. O ponto de extremidade público é um endereço DNS que poderia ser resolvido publicamente. 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 permitem acesso ao servidor com base no endereço IP de origem de cada solicitação. Para obter mais informações, consulte a visão geral de regras de firewall.

Suporte para o Microsoft Defender para Nuvem

O Microsoft Defender para bancos de dados relacionais de código aberto detecta atividades anômalas que indicam tentativas incomuns e potencialmente prejudiciais de acessar ou explorar bancos de dados. O Defender para Nuvem fornece alertas de segurança sobre atividades anômalas para que você possa detectar possíveis ameaças e responder a elas à medida que ocorrem. Quando você habilita esse plano, o Defender para Nuvem fornece alertas quando detectar padrões anômalos de consulta e acesso a banco de dados e atividades suspeitas no banco de dados.

Esses alertas aparecem na página de alertas de segurança do Defender para Nuvem e incluem:

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

Microsoft Defender para Nuvem e ataques de 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 de adivinhar uma senha, só poderá estar certo eventualmente. Quando o Microsoft Defender para Nuvem detecta um ataque de força bruta, ele dispara um alerta para conscientizá-lo de que ocorreu um ataque de força bruta. Ele também pode separar o ataque de força bruta simples do ataque de força bruta em um usuário válido ou um ataque de força bruta bem-sucedido.

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

Habilitar a segurança aprimorada com o Microsoft Defender para Nuvem

  1. No portal do Azure, navegue até o menu Segurança no painel esquerdo
  2. Escolha Microsoft Defender para Nuvem
  3. Selecione Habilitar no painel direito.

Captura de tela do portal do Azure mostrando como habilitar o Cloud Defender.

Observação

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

Gerenciamento de acesso

A melhor maneira de gerenciar as permissões de acesso ao banco de dados do Banco de Dados do Azure para PostgreSQL - Servidor Flexível em escala é usar 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 ser proprietárias dos 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 a associação de uma função a outra função, permitindo assim que a função 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, recomendamos que você crie funções com conjuntos específicos de permissões com base nos requisitos mínimos de acesso e do aplicativo. 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 os objetos de banco de dados.

A instância do Servidor Flexível do Banco de Dados do Azure para PostgreSQL é 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 a instância do Banco de Dados do Azure para PostgreSQL - Servidor Flexível, forneça credenciais para uma função de administrador. Essa função Administrador pode ser usado para criar funções adicionais do PostgreSQL.

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


 CREATE USER demouser PASSWORD password123;

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

Em ambientes PaaS baseados em nuvem, o acesso a uma conta de superusuário do Banco de Dados do Azure para PostgreSQL - Servidor Flexível é restrito a operações de plano de controle apenas por operadores de nuvem. Portanto, a conta azure_pg_admin existe como uma conta de pseudo-superusuário. Sua função de administrador é um membro da função azure_pg_admin.
No entanto, a conta de administrador do servidor não faz parte da função azuresu, que tem privilégios de superusuário e é usada para executar operações de plano de controle. Como esse serviço é um serviço gerenciado de PaaS, somente 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 o cliente psql e consultar a tabela pg_roles, que lista todas as funções junto com os 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 Servidor Flexível do Banco de Dados do Azure para PostgreSQL. Para executar a instrução CREATE CAST, o usuário deve ser membro do grupo azure_pg_admin. Atualmente não é possível descartar um CAST após a sua criação.

O Log de auditoria no Banco de Dados do Azure para PostgreSQL – Servidor Flexível também está disponível no Banco de Dados do Azure para PostgreSQL – Servidor Flexível para acompanhar 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 na instância do Banco de Dados do Azure para PostgreSQL - Servidor Flexível, recomendamos que você considere revogar esses privilégios públicos padrão. Depois de fazer isso, é possível conceder privilégios específicos aos usuários do banco de dados de forma mais granular. Por exemplo:

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

    REVOKE CREATE ON SCHEMA public FROM PUBLIC;

  • Em seguida, crie o novo banco de dados.

    CREATE DATABASE Test_db;

  • Revogue todos os privilégios para o 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;

  • Conceda 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 do 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 em qualquer outro banco de dados no servidor. Além disso, seria recomendável, em vez de conceder a esse usuário\função ALL PRIVILEGES para o banco de dados e seus objetos, você conceda a ele 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 na documentação do PostgreSQL.

Alterações de propriedade de 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 de pg_database_owner. Ela permite que todos os proprietários de banco de dados possuam o esquema público do banco de dados.
Encontre mais informações em Notas sobre a versão do PostgreSQL.

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

Na função de banco de dados do 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 do PostgreSQL de usuários e funções. No PostgreSQL 16, foram introduzidas alterações significativas nesse atributo. No PostgreSQL 16, os usuários com o atributo CREATEROLE não têm mais a capacidade de distribuir a associação em qualquer função para qualquer pessoa; em vez disso, como outros usuários, sem esse atributo, eles só podem distribuir associações em funções para as quais possuemADMIN OPTION. Além disso, no PostgreSQL 16, o atributo CREATEROLE ainda permite que um não superusuário provisione novos usuários, mas ele só pode remover usuários que ele mesmo criou. As tentativas de remover usuários, que não foram criados por um usuário com o atributo CREATEROLE, resultarão em um erro.

O PostgreSQL 16 também apresentou funções internas novas e aprimoradas. A 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 o atributo pg_write_all_data seja concedido aos usuários, o que permite que o usuário grave 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ê-los concedidos explicitamente. 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 em nível de linha

A RLS (segurança em nível de linha) é um recurso de segurança do Banco de Dados do Azure para PostgreSQL - Servidor Flexível que permite aos administradores de banco de dados definir políticas para controlar como linhas específicas de dados são exibidas e operadas para uma ou mais funções. A segurança em nível de linha é um filtro adicional que você pode aplicar a uma tabela de banco de dados do Banco de Dados do Azure para PostgreSQL - 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 restringidos 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 ou especificá-las para TODOS os comandos. Os casos de uso para segurança em nível de linha incluem implementações em conformidade com PCI, ambientes classificados e aplicativos de hospedagem compartilhada/multilocatários.

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

Este é um exemplo que mostra como criar uma política que garante que apenas os membros da função "gerente" criada personalizada possam acessar somente as linhas de uma conta específica. O código do 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 cláusula WITH CHECK, garantindo que os membros da função de gerente não possam executar operações SELECT, DELETE ou UPDATE em linhas que pertencem a outros gerentes e não possam executar INSERT em novas linhas pertencentes a outro gerente. Elimine uma política de segurança de linha usando o comando DROP POLICY, como no exemplo:



DROP POLICY account_managers ON accounts;

Embora você possa ter removido a política, o gerente de função ainda não consegue visualizar nenhum dado que pertença a qualquer outro gerente. Isso ocorre porque a política 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 desabilitar a segurança em nível de linha, como no exemplo abaixo:

ALTER TABLE accounts DISABLE ROW LEVEL SECURITY;

Como ignorar a Segurança em Nível de Linha

O PostgreSQL tem as 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, é possível implementar o recurso para ignorar o privilégio da Segurança em Nível de Linha (BYPASSRLS) da seguinte maneira:

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

Atualizar senhas

Para maior segurança, é uma boa prática alternar periodicamente a senha do administrador e as senhas dos usuários do banco de dados. Recomendamos usar senhas fortes usando letras maiúsculas e minúsculas, números e caracteres especiais.

Usar SCRAM

O SCRAM (Mecanismo de Autenticação de Resposta do Desafio Salted) melhora muito a segurança da autenticação de usuário baseada em senha adicionando vários recursos de segurança importantes que impedem ataques de tabela arco-íris, ataques man-in-the-middle e ataques de senha armazenados, ao mesmo tempo em que adiciona suporte para vários algoritmos de hash e senhas que contêm caracteres não ASCII.

Na autenticação SCRAM, o cliente participa da realização do trabalho de criptografia para produzir a prova de identidade. Portanto, a autenticação SCRAM transfere 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 de DDoS (negação de serviço distribuído) ao PostgreSQL, impedindo uma sobrecarga da CPU do servidor para computar hashes de senha.

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

Redefinir a senha de administrador

Siga o guia de instruções para redefinir a senha de administrador.

Atualizar a senha de usuário do banco de dados

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

ALTER ROLE demouser PASSWORD 'Password123!';
ALTER ROLE

Suporte ao Azure Policy

O Azure Policy ajuda a impor padrões organizacionais e a avaliar a conformidade em escala. Por meio do painel de conformidade, ele fornece uma exibição agregada para avaliar o estado geral do ambiente, com a capacidade de drill down para a granularidade por recurso, por política. Ele também ajuda a deixar seus recursos em conformidade por meio da correção em massa de recursos existentes e da correção automática para novos recursos.

Definições de Políticas Internas

As políticas internas são desenvolvidas e testadas pela Microsoft, garantindo que atendam aos padrões e melhores práticas comuns, uma implantação rápida sem a necessidade de configuração adicional, tornando-as ideais para requisitos de conformidade padrão. As políticas internas geralmente abrangem padrões amplamente reconhecidos e estruturas de conformidade.

A seção a seguir fornece um índice de definições de política internas do Azure Policy para o Banco de Dados do Azure para PostgreSQL – Servidor Flexível. Use o link da coluna Origem para ver a origem no repositório GitHub do Azure Policy.

Nome (portal do Azure) Descrição Efeito(s) Versão(GitHub)
Um administrador do Microsoft Entra deve ser provisionado para servidores flexíveis PostgreSQL Audite o provisionamento 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 dos usuários de banco de dados e de outros serviços da Microsoft AuditIfNotExists, desabilitado 1.0.0
Auditoria com PgAudit deve estar habilitada para servidores flexíveis PostgreSQL Essa política ajuda a auditar os servidores flexíveis PostgreSQL no seu ambiente, que não é habilitado para usar pgaudit. AuditIfNotExists, desabilitado 1.0.0
A limitação de conexão deve estar habilitada para os servidores flexíveis do PostgreSQL Esta política ajuda a auditar os servidores flexíveis do PostgreSQL no seu ambiente sem a limitação de conexão habilitada. Essa configuração permite a limitação de conexão temporária por IP para muitas falhas inválidas de login de senha AuditIfNotExists, desabilitado 1.0.0
Implantar as Configurações de Diagnóstico de servidores flexíveis PostgreSQL no workspace do Log Analytics Implanta as configurações de diagnóstico dos servidores flexíveis PostgreSQL a serem transmitidas para um workspace do Log Analytics regional em qualquer servidor flexível do PostgreSQL criado ou atualizado que não tenha essa configuração de diagnóstico DeployIfNotExists, desabilitado 1.0.0
As desconexões devem ser registradas em log para os servidores flexíveis do PostgreSQL Esta política ajuda a auditar os servidores flexíveis do PostgreSQL no seu ambiente sem a configuração log_disconnections habilitada AuditIfNotExists, desabilitado 1.0.0
A configuração Impor conexão SSL deve estar habilitada para servidores flexíveis do PostgreSQL O Banco de Dados do Azure para PostgreSQL dá suporte à conexão do seu servidor flexível de Banco de Dados do Azure para PostgreSQL com aplicativos cliente usando o protocolo SSL. Impor conexões SSL entre seu servidor flexível de banco de dados e seus aplicativos cliente ajuda a proteger contra ataques de "intermediários" criptografando o fluxo de dados entre o servidor e o seu aplicativo. Essa configuração impõe que o SSL sempre esteja habilitado para acessar seu servidor flexível do PostgreSQL AuditIfNotExists, desabilitado 1.0.0
O backup com redundância geográfica deve ser habilitado para os servidores flexíveis de Banco de Dados do Azure para PostgreSQL O Banco de Dados do Azure para PostgreSQL com servidores flexíveis 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 Audit, desabilitado 1.0.0
Registrar pontos de verificação em log deve estar habilitado para os servidores flexíveis do PostgreSQL Esta política ajuda a auditar qualquer servidor flexível do PostgreSQL no seu ambiente sem a configuração log_checkpoints habilitada AuditIfNotExists, desabilitado 1.0.0
A configuração Registrar conexões em log deve estar habilitada para os servidores flexíveis do PostgreSQL Esta política ajuda a auditar os servidores flexíveis do PostgreSQL no seu ambiente sem a configuração log_connections habilitada AuditIfNotExists, desabilitado 1.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 de dados inativos de seus servidores flexíveis 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 da chave, incluindo rotação e gerenciamento Audit, Deny, desabilitado 1.0.0
Os servidores flexíveis PostgreSQL devem estar executando o TLS versão 1.2 ou mais recente Essa política ajuda a auditar os servidores flexíveis PostgreSQL no seu ambiente que está em execução com o TLS versão anterior a 1.2 AuditIfNotExists, desabilitado 1.0.0
O ponto de extremidade privado deve estar habilitado para servidores flexíveis do 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, desabilitado 1.0.0

Definições de políticas personalizadas

As políticas personalizadas podem ser adaptadas com precisão para corresponder 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 da política e os parâmetros, permitindo definições de política sofisticadas e refinadas.

Conteúdo relacionado