Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure HorizonDB is a cloud-native, fully managed, PostgreSQL-compatible database service for mission-critical workloads.
This article describes security best practices for protecting Azure HorizonDB deployments.
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 controls help restrict which clients can reach your Azure HorizonDB cluster before database authentication and authorization occur.
- Use private endpoints when public routing isn't required: Use private endpoints for workloads that can connect privately to Azure HorizonDB instead of routing database traffic over public internet paths. For more information, see Networking overview with public access (allowed IP addresses) and private endpoints in Azure HorizonDB.
- Restrict public access to approved IP addresses: Add firewall rules only for trusted client and application IP addresses or ranges. By default, no public IP addresses are allowed. For more information, see Add firewall rules in Azure HorizonDB (Preview).
- Limit broad Azure service access: Avoid the
0.0.0.0firewall rule unless your scenario requires it, because it allows connections from IP addresses allocated to Azure services and assets, including resources in other customer subscriptions. For more information, see Networking overview with public access (allowed IP addresses) and private endpoints in Azure HorizonDB. - Use fully qualified domain names for connections: Use the Azure HorizonDB cluster fully qualified domain name in connection strings instead of an IP address, because the cluster IP address isn't guaranteed to remain static. For more information, see Networking overview with public access (allowed IP addresses) and private endpoints in Azure HorizonDB.
Identity and access management
Use Azure RBAC for Azure resource management and PostgreSQL roles for database-level authorization.
- Assign Azure RBAC permissions by least privilege: Grant users and automation only the Azure permissions needed to create, view, modify, or delete Azure HorizonDB resources. For more information, see Azure role-based access control (Azure RBAC).
- Create database roles for application access: Use PostgreSQL roles with specific permissions instead of using the administrator role for applications. For more information, see Access management in Azure HorizonDB (Preview).
- Manage local database users separately from Azure RBAC: Create database users and grant database, schema, and table privileges based on each user's workload requirements. For more information, see Manage users in Azure HorizonDB (Preview).
- Require SCRAM-SHA-256 password authentication: Configure
password_encryptionand supported authentication methods to use SCRAM-SHA-256, and update user passwords before enforcing SCRAM-only authentication. For more information, see SCRAM authentication in Azure HorizonDB (Preview). - Use row-level security for tenant or row-scoped access: Define PostgreSQL row-level security policies when authorization depends on row ownership, tenant boundaries, or classified data access. For more information, see Access management in Azure HorizonDB (Preview).
Data protection
Azure HorizonDB always encrypts managed data at rest by using service-managed keys. Customer-managed keys aren't available in preview, so the configurable data-protection controls focus on TLS, client-side protection, and PostgreSQL data access patterns. For more information, see Azure HorizonDB limitations and Data encryption at rest in Azure HorizonDB (Preview).
- Verify TLS certificates for client connections: Configure PostgreSQL clients to use
sslmode=verify-fullorsslmode=verify-caso clients validate the Azure HorizonDB cluster certificate. For more information, see Connect clients with TLS security to your database in Azure HorizonDB (Preview). - Require TLS 1.3 when clients support it: Set the
ssl_min_protocol_versionparameter toTLSv1.3for workloads that don't need TLS 1.2 compatibility. For more information, see Transport layer security (TLS) in Azure HorizonDB (Preview). - Maintain trusted root certificates: Keep required Azure HorizonDB root certificate authorities in client trust stores and avoid trusting intermediate certificate authorities or individual cluster certificates. For more information, see Transport layer security (TLS) in Azure HorizonDB (Preview).
- Encrypt sensitive values before storing them: For data that requires application-controlled secrecy in addition to service-managed encryption at rest, encrypt values in the application before writing them to Azure HorizonDB and manage encryption keys separately from database administrators. For more information, see Azure encryption overview.
- Use data masking for controlled data exposure: Use supported PostgreSQL anonymizer capabilities for patterns such as anonymous dumps, static masking, dynamic masking, masking views, and masking data wrappers when you need to reduce sensitive data exposure. For more information, see HorizonDB customized options.
Backup and recovery
Backup and recovery controls help you recover from accidental data changes, destructive operations, and availability events.
- Validate recovery requirements against preview backup limits: Azure HorizonDB currently keeps automated backups for seven days, and configurable backup retention from 1 to 35 days isn't yet available. For more information, see Backups in Azure HorizonDB (Preview).
- Restore to a custom point after accidental changes: Use point-in-time restore to create a new cluster from a selected restore point within the current retention window. For more information, see Restore for Azure HorizonDB (Preview).
- Configure replicas for availability goals: Use at least two compute replicas for zonal resilience, and use in-region read replicas to offload read workloads and provide failover targets. For more information, see Overview of business continuity in Azure HorizonDB (Preview).
- Protect clusters from accidental deletion: Apply Azure resource locks to critical Azure HorizonDB clusters because deleted servers can't currently be restored. For more information, see Protect against accidental deletion by using resource locks in Azure HorizonDB (Preview).