Overview
Enable log_disconnections on PostgreSQL Servers.
NOTE: This recommendation currently only applies to Single Server, not Flexible Server. See additional information below for details about the planned retirement of Azure PostgreSQL Single Server.
Rationale
Enabling log_disconnections helps PostgreSQL Database to Logs end of a session, including duration, which generates query and error logs. Query and error logs can be used to identify, troubleshoot, and repair configuration errors and sub-optimal performance.
Impact
Enabling this setting will enable a log of all disconnections. If this is enabled for a high traffic server, the log may grow exponentially.
Default Value
By default, log_disconnections is disabled (set to off).
Additional Information
RETIREMENT of Azure PostgreSQL Single Server: Azure PostgreSQL Single Server is slated for retirement by March 25, 2025. Please use these resources to consider and prepare for migration:
- https://learn.microsoft.com/en-us/azure/postgresql/single-server/whats-happening-to-postgresql-single-server
- https://learn.microsoft.com/en-us/azure/postgresql/migrate/concepts-single-to-flexible
Remediation guidance
Remediate from Azure Portal
- Open the server using the
Open in Azurebutton - Under
Settings, clickServer parameters. - Search for
log_disconnections. - Set
log_disconnectionstoON. - Click
Save.
Remediate from Azure CLI
Use the below command to update log_disconnections configuration.
az postgres server configuration set --resource-group <resourceGroupName> --server-name <serverName> --name log_disconnections --value on
Remediate from PowerShell
Use the below command to update log_disconnections configuration.
Update-AzPostgreSqlConfiguration -ResourceGroupName -ServerName -Name log_disconnections -Value on
Multiple Remediation Paths
Azure
SERVICE-WIDE (RECOMMENDED when many resources are affected): Assign Azure Policy initiatives at management group/subscription scope and trigger remediation tasks.
az policy assignment create --name <assignment-name> --scope /subscriptions/<subscription-id> --policy-set-definition <initiative-id>
az policy remediation create --name <remediation-name> --policy-assignment <assignment-id>
ASSET-LEVEL: Apply the resource-specific remediation steps above to the listed non-compliant resources.
PREVENTIVE: Embed Azure Policy checks into landing zones and IaC workflows to block or auto-remediate drift.
References for Service-Wide Patterns
- Azure Policy overview: https://learn.microsoft.com/en-us/azure/governance/policy/overview
- Azure Policy remediation: https://learn.microsoft.com/en-us/azure/governance/policy/how-to/remediate-resources
- Azure Policy initiative structure: https://learn.microsoft.com/en-us/azure/governance/policy/concepts/initiative-definition-structure
Operational Rollout Workflow
Use this sequence to reduce risk and avoid repeated drift.
1. Contain at Service-Wide Scope First (Recommended)
- Azure: assign policy initiatives at management group/subscription scope and run remediation tasks.
az policy assignment create --name <assignment-name> --scope /subscriptions/<subscription-id> --policy-set-definition <initiative-id>
az policy remediation create --name <remediation-name> --policy-assignment <assignment-id>
2. Remediate Existing Affected Assets
- Execute the control-specific Console/CLI steps documented above for each flagged resource.
- Prioritize internet-exposed and production assets first.
3. Validate and Prevent Recurrence
- Re-scan after each remediation batch.
- Track exceptions with owner and expiry date.
- Add preventive checks in IaC/CI pipelines.
Query logic
These are the stored checks tied to this control.
Server parameter 'log_disconnections' is set to 'ON' for PostgreSQL Database Server
Connectors
Covered asset types
Expected check: eq []
{
postgreSqlServers(
where: {
configurations_SOME: {
name: "log_disconnections"
value_MATCHES: "(?i)off"
}
}
) {
...AssetFragment
}
}
Microsoft Azure