Secure your Azure Database for PostgreSQL flexible server

Azure Database for PostgreSQL is a fully managed database service that provides built-in high availability, automated backups, and scaling capabilities. Securing your PostgreSQL database deployments helps protect sensitive data and meet compliance requirements.

This article guides you on how to secure your Azure Database for PostgreSQL flexible server deployment.

The security recommendations in this article implement Zero Trust principles: "Verify explicitly", "Use least privilege access", and "Assume breach". For comprehensive Zero Trust guidance, see the Zero Trust Guidance Center.

Network security

Network security controls help you reduce public exposure and integrate Azure Database for PostgreSQL flexible server into a segmented virtual network architecture.

• Disable public network access: Prevent internet exposure by blocking public connectivity to your PostgreSQL flexible server when private connectivity is available. For more information, see Azure Database for PostgreSQL networking with Private Link.

• Use private endpoints: Connect to your PostgreSQL flexible server through Azure Private Link so database traffic stays on a private IP address in your virtual network. For more information, see Azure Database for PostgreSQL networking with Private Link.

• Use virtual network integration: Deploy PostgreSQL flexible server with private access when you need virtual network-level isolation for client access and outbound connectivity to dependent Azure services. For more information, see Network with private access for Azure Database for PostgreSQL.

• Restrict public firewall access: If your deployment requires public access, allow only required client IP addresses and avoid broad firewall rules. For more information, see Public access with firewall rules for Azure Database for PostgreSQL.

• Review public networking behavior: Understand how public access, firewall rules, and allowed IP addresses affect exposure before you choose a connectivity model. For more information, see Networking overview for Azure Database for PostgreSQL with public access.

Identity and access management

Identity and access controls help you centralize authentication, reduce credential exposure, and enforce least privilege across Azure management and PostgreSQL database access.

• Use Microsoft Entra authentication: Prefer Microsoft Entra authentication for PostgreSQL flexible server to centralize identity controls and reduce dependency on local database passwords. For more information, see Microsoft Entra authentication with Azure Database for PostgreSQL.

• Manage Microsoft Entra principals: Assign and review Microsoft Entra administrators, users, and groups for PostgreSQL flexible server so database access follows least privilege. For more information, see Manage Microsoft Entra roles in Azure Database for PostgreSQL.

• Use managed identities for application access: Authenticate Azure-hosted applications to PostgreSQL flexible server with managed identities instead of storing credentials in application code or configuration. For more information, see Managed identities in Azure Database for PostgreSQL.

• Enforce Conditional Access for PostgreSQL administrators: Apply Conditional Access policies such as multifactor authentication and compliant-device requirements to identities that administer PostgreSQL flexible servers and related Azure resources. For more information, see Common Conditional Access policy: Require MFA for Azure management.

• Use SCRAM for local authentication: If local PostgreSQL users are required, use SCRAM authentication and strong password practices to reduce password compromise risk. For more information, see SCRAM authentication in Azure Database for PostgreSQL.

• Manage local database roles: Use PostgreSQL roles and permissions to restrict database-level access to the objects and operations each user needs. For more information, see Manage users in Azure Database for PostgreSQL.

• Implement Azure role-based access control (RBAC): Assign Azure RBAC roles only to identities that need to create, configure, monitor, or delete PostgreSQL flexible server resources. For more information, see Azure role-based access control.

Data protection

Azure Database for PostgreSQL encrypts primary servers, replicas, point-in-time recovery data, and backups at rest by using service-managed keys. Use the following customer-configurable controls when your workload requires stronger encryption governance or data-use protections.

• Verify TLS connections: Configure PostgreSQL clients to validate the server certificate chain and hostname by using sslmode=verify-full, or sslmode=verify-ca where verify-full isn't possible. For more information, see Transport Layer Security in Azure Database for PostgreSQL.

• Maintain trusted root certificates: Keep Azure root certificate authorities in client trust stores and avoid trusting intermediate certificates or individual server certificates so certificate rotations don't break connectivity. For more information, see Transport Layer Security in Azure Database for PostgreSQL.

• Require TLS 1.3 where supported: Set the ssl_min_protocol_version server parameter to TLSv1.3 for clients that support the latest secure protocol version, and don't set ssl_max_protocol_version. For more information, see Transport Layer Security in Azure Database for PostgreSQL.

• Use customer-managed keys for encryption governance: Configure customer-managed keys in Azure Key Vault or Azure Managed HSM when you need key lifecycle control or separation of duties. Use cross-tenant customer-managed keys only for preview scenarios that meet the documented requirements. For more information, see Data encryption at rest in Azure Database for PostgreSQL and Configure data encryption in Azure Database for PostgreSQL.

• Configure automatic key rotation: If you use customer-managed keys, enable key autorotation in Azure Key Vault or Azure Managed HSM and configure PostgreSQL flexible server to use automatic key version updates. For more information, see Configure customer-managed key encryption.

• Use confidential computing for highly sensitive workloads: Deploy PostgreSQL flexible server on supported confidential computing SKUs in supported regions when you need hardware-based protection for data in use. For more information, see Azure confidential computing in Azure Database for PostgreSQL.

• Apply data anonymization for sensitive PostgreSQL data: Use the anon extension when you need database-level data anonymization tools, and configure required shared preload libraries before use. For more information, see List of extensions and modules by name in Azure Database for PostgreSQL flexible server.

Logging and monitoring

Logging and monitoring controls help you detect suspicious activity, investigate incidents, and keep PostgreSQL audit evidence available for operational and compliance workflows.

• Enable diagnostic log collection: Send PostgreSQL flexible server audit logs to Log Analytics by using diagnostic settings and Azure Policy assignments for the audit category group. For more information, see Azure Policy built-ins for Azure Database for PostgreSQL.

• Enable audit logging: Configure PostgreSQL audit logging with the pgaudit extension so database activities are captured for investigation and compliance review. For more information, see Audit logging in Azure Database for PostgreSQL.

• Audit Microsoft Entra authentication events: Monitor Microsoft Entra authentication activity for PostgreSQL flexible server to investigate identity-based access and sign-in patterns. For more information, see Audit Microsoft Entra authentication in Azure Database for PostgreSQL.

• Enable Microsoft Defender for open-source relational databases: Use Microsoft Defender for Cloud to detect anomalous PostgreSQL access patterns, brute-force attempts, suspicious database activity, and PostgreSQL-specific configuration risks. For more information, see Microsoft Defender for Cloud in Azure Database for PostgreSQL flexible server.

Compliance and governance

Compliance and governance controls help you apply consistent configuration, map PostgreSQL deployments to regulatory requirements, and keep security ownership visible at scale.

• Enforce PostgreSQL security configuration with Azure Policy: Assign built-in policies for PostgreSQL flexible server controls such as private endpoints, public access restrictions, diagnostic logging, TLS, customer-managed keys, and geo-redundant backup. For more information, see Azure Policy built-ins for Azure Database for PostgreSQL.

• Review compliance offerings for PostgreSQL: Map Azure Database for PostgreSQL flexible server to relevant compliance certifications and attestations before you process regulated data. For more information, see Compliance in Azure Database for PostgreSQL.

• Apply resource locks to production servers: Use management locks on production PostgreSQL flexible servers and dependent resources to reduce accidental deletion or disruptive configuration changes. For more information, see Protect your Azure resources with a lock.

• Tag PostgreSQL resources for governance: Apply tags such as workload, environment, data classification, owner, and compliance scope to PostgreSQL flexible servers and related resources so policy, inventory, and cost-management workflows can identify protected databases. For more information, see Use tags to organize your Azure resources.

Backup and recovery

Backup and recovery controls help you restore PostgreSQL data after accidental deletion, corruption, or regional disruption while meeting workload recovery objectives.

• Configure automated backup retention: Set the backup retention period from 7 to 35 days based on your point-in-time recovery requirements, and validate that the retention window matches workload recovery needs. For more information, see Backup and restore in Azure Database for PostgreSQL.

• Enable geo-redundant backup for regional recovery: Configure geo-redundant backup when you create the server if your disaster recovery plan requires restore capability in the Azure paired region. For more information, see Geo-disaster recovery in Azure Database for PostgreSQL.

• Configure high availability for critical workloads: Use high availability configurations to provision a standby replica and reduce downtime during zone or infrastructure failures. For more information, see Configure high availability for Azure Database for PostgreSQL.

• Use read replicas for recovery planning: Use read replicas to offload read traffic and support recovery scenarios that require a promoted replica. For more information, see Read replicas in Azure Database for PostgreSQL.

• Protect backup data by using customer-managed keys: Use customer-managed key encryption when backup and restore data must follow your organization's key management requirements. For more information, see Backup and restore in Azure Database for PostgreSQL and Configure data encryption in Azure Database for PostgreSQL.

• Plan business continuity objectives: Align backup retention, high availability, read replicas, and geo-restore options to your workload recovery time objective and recovery point objective. For more information, see Business continuity in Azure Database for PostgreSQL.

Next steps

• Architecture best practices for Azure Database for PostgreSQL
• Zero Trust guidance center