Partilhar via

Proteja seu Banco de Dados do Azure para PostgreSQL Server

O Banco de Dados do Azure para PostgreSQL é um serviço de banco de dados totalmente gerenciado que fornece alta disponibilidade interna, backups automatizados e recursos de dimensionamento. Proteger suas implantações de banco de dados PostgreSQL é crucial para proteger dados confidenciais e manter a conformidade com os padrões do setor.

Este artigo orienta você sobre como proteger seu Banco de Dados do Azure para implantação do PostgreSQL Server.

Importante

A partir de 11 de novembro de 2025, as regiões do Azure na lista a seguir estão planejadas para uma rotação de certificados TLS/SSL que usa novos certificados de CA intermediários.

  • E.U.A. Centro-Oeste
  • Ásia Leste
  • Sul do Reino Unido

A partir de 19 de janeiro de 2026, essa rotação está planejada para se estender a todas as regiões restantes do Azure, incluindo o Azure Government e todas as outras regiões.

Para obter informações sobre solução de problemas, consulte Problemas de fixação de certificados.

Segurança de rede

A seção Segurança de Rede orienta você através da prevenção de acesso público e do uso dos recursos de rede para integrar seu PostgreSQL em uma arquitetura de rede de nuvem segura e segmentada.

  • Desativar o acesso à rede pública: desative o acesso à rede pública para o seu PostgreSQL para evitar a exposição à internet. Essa ação garante que apenas redes confiáveis possam acessar seu banco de dados.

  • Pontos de extremidade privados: use pontos de extremidade privados para se conectar com segurança ao seu PostgreSQL de dentro de sua rede virtual.

  • Como alternativa, use a integração de rede virtual: use a integração de rede virtual para conectar seu PostgreSQL à sua rede virtual. Essa integração permite o acesso seguro de seus recursos do Azure e do servidor a recursos consumidos, como IA.

  • Regras de firewall herdadas e pontos de extremidade de serviço: Se você precisar permitir o acesso de endereços IP específicos, use regras de firewall herdadas e pontos de extremidade de serviço. No entanto, essa abordagem não é recomendada. Em vez disso, prefira usar pontos de extremidade privados ou integração de rede virtual.

Os artigos de segurança de rede estão nas seções de rede:

Gestão de identidades

A seção Gerenciamento de Identidades se concentra na autenticação, proteção de identidades e controles de acesso usando sistemas centralizados de gerenciamento de identidade e acesso. Ele abrange práticas recomendadas, como mecanismos de autenticação forte e identidades gerenciadas para aplicativos.

Aqui estão alguns possíveis serviços de segurança, recursos e práticas recomendadas para a seção de gerenciamento de identidades:

  • Use o Entra em vez da autenticação local do banco de dados: você deve não permitir a autenticação local para seu servidor PostgreSQL. Em vez disso, use apenas a autenticação do Microsoft Entra (não o modo misto) para gerenciar o acesso ao seu banco de dados. O Microsoft Entra fornece autenticação centralizada com controles de segurança fortes e proteção em tempo real do Defender for Identity. Para obter mais informações, visite Microsoft Entra em geral e Autenticação do Microsoft Entra com o Banco de Dados do Azure para PostgreSQL.

  • Usar identidades gerenciadas para acesso seguro a aplicativos: use identidades gerenciadas no Azure para autenticar aplicativos e serviços com segurança sem a necessidade de gerenciar credenciais. Isso fornece uma maneira segura e simplificada de acessar recursos como o Banco de Dados do Azure para PostgreSQL. Para obter mais informações, visite Identidades gerenciadas.

  • Impor segurança por meio de políticas de acesso condicional: configure políticas de acesso condicional no Microsoft Entra para impor controles de segurança com base no contexto do usuário, local ou dispositivo. Estas políticas permitem a aplicação dinâmica de requisitos de segurança com base no risco, melhorando a postura geral de segurança. Para obter mais informações, visite Acesso condicional do Microsoft Entra.

  • A autenticação local deve usar a autenticação SCRAM: se você precisar usar a autenticação local, certifique-se de que as políticas de senha forte sejam aplicadas. Use os requisitos de complexidade de senha e a rotação regular de senhas para minimizar o risco de contas comprometidas. Para obter mais informações, visite Autenticação SCRAM no Banco de Dados do Azure para PostgreSQL.

Controlo de acessos

A seção de controle de acesso se concentra em proteger o nível de acesso com base no princípio de menor privilégio. Ele enfatiza a minimização do risco de acesso não autorizado a recursos confidenciais, restringindo e gerenciando permissões elevadas, impondo autenticação multifator e garantindo que ações privilegiadas sejam registradas e auditadas.

Aqui estão alguns possíveis serviços de segurança, recursos e práticas recomendadas para a seção de controle de acesso:

  • Use Entra roles for access control: implemente o Azure Role-Based Access Control (Role-Based Access Control (RBAC) para gerenciar o acesso ao Banco de Dados do Azure para recursos do PostgreSQL. Atribua funções com base no princípio do menor privilégio, garantindo que os usuários e aplicativos tenham apenas as permissões de que precisam. Para obter mais informações, visite o RBAC (Controle de Acesso Baseado em Função) do Azure em geral e Gerenciar funções do Microsoft Entra no Banco de Dados do Azure para PostgreSQL.

  • Siga as melhores práticas do Entra: Utilize MFA, políticas de Acesso Condicional, acesso just in time (JIT) para proteger seus usuários e bancos de dados.

  • Gerenciar usuários, funções e permissões do banco de dados local: use o gerenciamento de funções interno do PostgreSQL para controlar o acesso no nível do banco de dados. Crie funções personalizadas com permissões específicas para impor o princípio de menor privilégio. Analise e audite regularmente essas funções para garantir a conformidade com as políticas de segurança. Para obter mais informações, visite Criar usuários no Banco de Dados do Azure para PostgreSQL.

Proteção de dados

A seção de proteção de dados se concentra na proteção de dados confidenciais em repouso e em trânsito. Ele garante que os dados sejam criptografados, o acesso seja controlado e as informações confidenciais sejam protegidas contra acesso não autorizado. Ele enfatiza o uso de criptografia, conexões seguras e mascaramento de dados para salvaguardar a integridade e a confidencialidade dos dados.

Aqui estão alguns possíveis serviços de segurança, recursos e práticas recomendadas para a seção de proteção de dados:

Criptografar dados em trânsito

  • Verificar conexões TLS: o Azure PostgreSQL sempre usa SSL ou TLS para criptografar dados em trânsito entre seu aplicativo e o banco de dados. Você deve configurar seu aplicativo para verificar o certificado usado, como a autoridade de certificação raiz, certificados expirados, incompatibilidade de nome de host e revogação de certificado. Essa prática ajuda a proteger informações confidenciais contra escutas e ataques man-in-the-middle. Para obter mais informações, visite Conectividade segura com TLS e SSL no Banco de Dados do Azure para PostgreSQL.

  • Verifique se o cliente tem os certificados TLS mais recentes instalados: certifique-se de que seus aplicativos cliente tenham os certificados TLS mais recentes instalados para oferecer suporte a conexões seguras. Essa prática ajuda a evitar falhas de conexão e garante que seu aplicativo possa estabelecer conexões seguras com o servidor PostgreSQL. Para obter mais informações, visite Baixar certificados de CA raiz e atualizar clientes de aplicativos.

  • Exigir o uso de TLS 1.3: Configure seu servidor PostgreSQL para exigir TLS 1.3 para todas as conexões. Essa configuração garante que apenas a versão mais recente e segura do protocolo seja usada, proporcionando melhor segurança e desempenho. Para obter mais informações, visite Versões TLS.

Encriptação em repouso

  • Os dados são sempre criptografados de forma transparente em repouso com o SMK: o Banco de Dados do Azure para PostgreSQL criptografa automaticamente os dados em repouso usando chaves gerenciadas por serviço (SMK). Esta encriptação garante que os seus dados estão protegidos sem necessitar de configuração adicional. Ele depende da infraestrutura de armazenamento subjacente do Azure. Ele abrange o servidor primário, réplicas, recuperação point-in-time (PITR) e backups. Para obter mais informações, visite Criptografia de dados no Banco de Dados do Azure para PostgreSQL.

  • Usar chaves gerenciadas pelo cliente para controle adicional: se você precisar de mais controle sobre chaves de criptografia, use chaves gerenciadas pelo cliente (CMK) armazenadas no Cofre de Chaves do Azure ou no Azure HSM. Essa opção permite que você gerencie suas chaves de criptografia e fornece mais opções de segurança e conformidade. Para obter mais informações, visite chaves gerenciadas pelo cliente no Banco de Dados do Azure para PostgreSQL e Configurar a criptografia de dados no Banco de Dados do Azure para PostgreSQL.

  • Configurar a rotação automática de chaves no KV ou no HSM gerenciado: se você usar chaves gerenciadas pelo cliente, configure a rotação automática de chaves no Cofre de Chaves do Azure para garantir que suas chaves de criptografia sejam atualizadas regularmente. O Banco de Dados do Azure para PostgreSQL dá suporte a atualizações automáticas de versão de chave depois que uma chave é girada. Para obter mais informações, visite Configurar a rotação automática de chaves no HSM gerenciado do Azure ou Noções básicas sobre rotação automática no Cofre de Chaves do Azure para obter mais detalhes sobre o Cofre de Chaves. Para obter mais informações, visite Configurar criptografia de dados com chave gerenciada pelo cliente durante o provisionamento do servidor para obter mais detalhes sobre como configurar a rotação automática de chaves.

  • Criptografe dados ultrassensíveis com criptografia do lado do cliente: para dados ultrasconfidenciais, considere implementar a criptografia do lado do cliente. Essa abordagem envolve criptografar dados antes de enviá-los para o banco de dados, garantindo que apenas dados criptografados sejam armazenados no banco de dados. Essa prática fornece uma camada maior de segurança, pois o próprio banco de dados e, portanto, o administrador do banco de dados não tem acesso aos dados não criptografados.

Computação confidencial

A Computação Confidencial do Azure (ACC) permite que as organizações processem e colaborem com segurança em dados confidenciais, como dados pessoais ou informações de saúde protegidas (PHI). O ACC fornece proteção integrada contra acesso não autorizado, protegendo os dados em uso por meio de TEEs (Trusted Execution Environments).

  • SaaS e provedores de hospedagem consideram configurar computação confidencial: se você for um Software como serviço (SaaS) ou provedor de hospedagem e suas cargas de trabalho do PostgreSQL envolverem o processamento de dados confidenciais, considere usar a Computação Confidencial do Azure para proteger os dados em uso. Esta solução proporciona uma maior camada de segurança ao garantir que os dados são processados num ambiente seguro, impedindo o acesso não autorizado mesmo de utilizadores privilegiados. Para obter mais informações, visite Computação Confidencial do Azure para Banco de Dados do Azure para PostgreSQL para obter mais detalhes.

Mascaramento e redação de dados

  • Implementar mascaramento de dados: use a extensão PostgreSQL Anonymizer para dar suporte:

  • Despejos anônimos: exporte os dados mascarados para um arquivo SQL.

  • Mascaramento estático: Remova os dados pessoais de acordo com as regras.

  • Mascaramento Dinâmico: Oculte dados pessoais apenas para os usuários mascarados.

  • Mascarar visualizações: crie visualizações dedicadas para os usuários mascarados.

  • Mascarar wrappers de dados: aplique regras de mascaramento em dados externos.

Registo e deteção de ameaças

A seção de registro em log e deteção de ameaças aborda controles para detetar ameaças em ambientes do Azure. Ele aborda a habilitação, coleta e armazenamento de logs de auditoria para serviços do Azure. Ele enfatiza o uso de recursos nativos de deteção de ameaças, gerenciamento centralizado de logs e retenção adequada de logs para investigações de segurança e conformidade. Esta seção se concentra na geração de alertas de alta qualidade, centralizando a análise de segurança por meio das ferramentas do Azure, mantendo a sincronização de tempo precisa e garantindo estratégias eficazes de retenção de logs.

Aqui estão alguns possíveis serviços de segurança, recursos e práticas recomendadas para a seção de registro em log e deteção de ameaças:

Cópia de segurança e recuperação

A seção de backup e recuperação se concentra em garantir que os dados e as configurações nos serviços do Azure sejam regularmente copiados, protegidos e recuperáveis em falhas ou desastres. Ele enfatiza a automação de backups, a proteção dos dados de backup e a garantia de que os processos de recuperação sejam testados e validados para atender aos objetivos de tempo de recuperação (RTO) e aos RPOs (Recovery Point Objetives, objetivos de ponto de recuperação). A seção também destaca a importância de monitorar e auditar os processos de backup para garantir a conformidade e a prontidão. Para obter uma visão geral, Para obter mais informações, visite Visão geral da continuidade de negócios com o Banco de Dados do Azure para PostgreSQL.

Aqui estão alguns possíveis serviços de segurança, recursos e práticas recomendadas para a seção de deteção de backup e recuperação:

  • Utilize alta disponibilidade: implemente configurações de alta disponibilidade (HA) para sua instância de servidor flexível do PostgreSQL para minimizar o tempo de inatividade e garantir acesso contínuo ao seu banco de dados. Para obter mais informações, visite Alta disponibilidade (confiabilidade) no Banco de Dados do Azure para PostgreSQL e Configurar alta disponibilidade.

  • Configurar backups automatizados: o Banco de Dados do Azure para PostgreSQL executa automaticamente backups diários de seus arquivos de banco de dados e faz backup contínuo dos logs de transações. Você pode reter backups de sete dias até 35 dias. Você pode restaurar o servidor de banco de dados para qualquer point-in-time dentro do período de retenção de backup. O RTO depende do tamanho dos dados a serem restaurados e do tempo para executar a recuperação de log. Pode variar de alguns minutos até 12 horas. Para obter mais informações, visite Backup e restauração no Banco de Dados do Azure para PostgreSQL.

  • Configurar réplicas de leitura: use as réplicas de leitura para descarregar operações de leitura do servidor primário, melhorando o desempenho e a disponibilidade. Você também pode usar réplicas de leitura para cenários de recuperação de desastres, permitindo que você alterne rapidamente para uma réplica com uma falha do servidor primário. Para obter mais informações, visite Ler réplicas no Banco de Dados do Azure para PostgreSQL.

  • Proteja os dados de backup com criptografia de chave gerenciada pelo cliente: proteja seus dados de backup usando criptografia em repouso.

Conteúdo relacionado

  • Last updated on