Microsoft AzureOverview
Enable log_checkpoints on PostgreSQL Database Servers.
Rationale
Enabling log_checkpoints helps the PostgreSQL Database to log each checkpoint and generate query and error logs. Access to transaction logs is not supported. Query and error logs can be used to identify, troubleshoot, and repair configuration errors and sub-optimal performance.
Remediation guidance
From Azure Console
- Go to
Azure Database for PostgreSQL servers - For each database, under
Settings, selectServer parameters - Search for
log_checkpointsand set its value toON - Click
Save
Using Azure Command Line Interface
Use the below command to update the configuration for log_checkpoints.
az postgres server configuration set --resource-group <resourceGroupName> --server-name <serverName> --name log_checkpoints --value on
Using PowerShell
Update-AzPostgreSqlConfiguration -ResourceGroupName <resourceGroupName> -ServerName <serverName> -Name log_checkpoints -Value on
Default value
By default, log_checkpoints is set to ON.
References
- https://learn.microsoft.com/en-us/rest/api/postgresql/configurations/listbyserver
- https://learn.microsoft.com/en-us/azure/postgresql/howto-configure-server-parameters-using-portal
- https://learn.microsoft.com/en-us/azure/security/benchmarks/security-controls-v2-logging-threat-detection#lt-4-enable-logging-for-azure-resources
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_checkpoints' is set to 'ON' for PostgreSQL Database Server
Connectors
Covered asset types
Expected check: eq []
{postgreSqlServers(where:{configurations_NONE:{name:"log_checkpoints",value_MATCHES:"(?i)on"}},){...AssetFragment}}
