Enable the logging parameters that record failed connections, disconnections, lock waits and other database activity needed for investigation. Use PostgreSQL logging to capture security-relevant events, then send those logs to a central system for review and retention. Do not rely on defaults alone, and check that the settings match your audit and incident response requirements.
What security logging means for Azure Database for PostgreSQL
Security logging is about turning PostgreSQL activity into evidence you can trust during investigation, incident response and routine review. For Azure Database for PostgreSQL, the important settings are the ones that record connection attempts, disconnections, lock waits and other events that help reconstruct what happened around a suspicious query, outage or access issue.
The practical point is that logging only helps when it is both enabled and useful. If you collect too little, you miss the sequence of events. If you collect everything without a plan, you create noise and retention problems. The right balance is to enable the parameters that capture security-relevant database activity, then forward the logs to a central location where they can be retained, searched and correlated.
Database logging is part of evidence collection, not just troubleshooting. In cloud databases, the logs are often the only durable record of who tried to connect, when a session ended, whether a lock was contended, and whether an operational issue lined up with suspicious behaviour.
Which PostgreSQL events are worth capturing first?
Start with the events that help answer the most common questions in an investigation: did a connection succeed or fail, did a session disconnect unexpectedly, and was the database under contention at the time of the incident. Failed connections matter because they can indicate credential attacks, misconfigured clients or brute-force activity. Disconnections matter because they help establish session boundaries. Lock waits matter because they can explain stalls, timeouts or application behaviour that may hide malicious activity.
You should also consider whether your environment needs broader statement-level or session-level logging for accountability, but that choice should be driven by audit need, performance overhead and log volume. For some systems, a narrow set of high-value events is enough. For others, especially regulated or heavily shared databases, the logging policy needs to be stricter so that analysts can reconstruct administrative actions and unusual access patterns.
The control objective is not to log every possible event. It is to ensure that the events most useful for detecting abuse, diagnosing incidents and proving what happened are actually captured.
How to make the logs useful after you enable them
Logging parameters alone are not sufficient if the output stays local or is kept only briefly. Security logging should feed a central system where records can be reviewed independently of the database, retained for the required period and protected from casual tampering. That centralisation also makes it easier to correlate PostgreSQL events with cloud platform logs, application logs and identity events.
This is where teams often get the control wrong: they enable a parameter, assume logging is complete and then discover that retention, searchability or time synchronisation was never designed into the process. If the logs cannot be reviewed quickly during an incident, they do not serve their purpose even if they were technically captured.
Cloud Logging and Audit Trail Guide is useful when you want to think about log coverage, audit trail retention and tamper resistance as one operating model rather than separate tasks.
Database Security Guide is the broader reference point for database auditing, hardening and exposure control, which is the right context for deciding how far PostgreSQL logging should go in your environment.
Microsoft Azure Security Guide helps place PostgreSQL logging inside the wider Azure control plane, including logging, monitoring and identity-adjacent operational controls.
Risk and Threat Considerations
Weak database logging creates a visibility gap that attackers can exploit by blending into normal client behaviour, using repeated failed access attempts, or making changes that are hard to reconstruct later. The risk is not only data theft, but also delayed detection, weak forensics and uncertain incident scope when the database is part of a larger application stack.
Failure mechanism: If failed connections, disconnections and contention events are not logged, investigators lose the timeline needed to distinguish operational errors from suspicious access patterns, and a short-lived intrusion can leave little evidence behind.
Impact: That gap can delay containment, make root-cause analysis unreliable and weaken your ability to prove whether sensitive data or administrative access was exposed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-8 — Audit Log Management | Database security logging depends on collecting and reviewing audit records. |
| Recommendation — Enable and centralise audit logging for database events that matter to investigation. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | The answer is about selecting which security-relevant database events to record. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Central review and investigation of PostgreSQL logs is a core part of the recommendation. | |
| Recommendation — Define database events to log and ensure the logging policy covers security-relevant activity. Review database logs centrally and correlate them with other security telemetry. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | PostgreSQL security logging is directly about capturing and retaining operational evidence. |
| A.8.16 — Monitoring activities | The logs are meant for monitoring, investigation and incident detection. | |
| Recommendation — Specify database logging settings and retain records for security review. Monitor database logs for abnormal access, failures and contention patterns. | ||
Practitioner Guidance
What to verify: Confirm that the logging settings you enable actually produce searchable records for failed logins, session ends and lock waits, then test the full path into the central logging system. The control is only real if the event survives collection, forwarding and retention.
What good looks like: You should be able to answer basic incident questions from the logs without querying the database directly, and you should be able to distinguish routine application noise from abnormal access behaviour.
Practitioner takeaway: Treat PostgreSQL logging as an evidence system, not a checkbox, and prioritise the event types that most improve investigation quality and incident reconstruction.