Database Security and Audit Logging: PostgreSQL and SQL Server for Texas Businesses

Every other control you own is designed to stop an attacker from reaching the database. The database controls are what remain after those failed - and that is the normal shape of a breach: a phished credential, a vulnerable public-facing app, or an over-permissioned service account gets someone onto a machine that already has a legitimate connection string.

At that point your endpoint security stack is looking at a process behaving normally, using valid credentials, running a query type it runs every day. The only thing separating theft from business as usual is volume, timing, and scope - and the only place that distinction is visible is the database's own audit trail. This is the same logic behind zero trust architecture and least privilege access control: assume the perimeter fails, and design so the failure is survivable and visible.

Database security decomposes cleanly into four layers, and they are worth working in order because effort spent on layer four is largely wasted if layer one is wide open: reachability (who can open a TCP connection at all), authentication and authorization (who can log in, and what they can do once in), encryption (data at rest and in transit), and auditing (a durable, tamper-resistant record of who did what).

The single most common finding in our network security audits is a database listening on a public interface - sometimes deliberately, to let a remote developer or reporting tool connect, more often because a cloud security group was opened during a migration and never closed. SQL Server on 1433 and PostgreSQL on 5432 are both scanned continuously by internet-wide crawlers, and a publicly reachable instance with password authentication is a brute-force target measured in hours, not months.

What to do instead

• Bind to a private interface. In PostgreSQL, set listen_addresses to the specific internal IP, not *. In SQL Server, disable the protocols and IP bindings you do not need in Configuration Manager.
• Enforce it at the network. Host-level binding is a setting someone can change. A firewall rule or cloud security group that permits 5432 only from the application subnet is a control. Both, ideally - see our approach to firewall management.
• Give admins a real path in. Nobody should need a public port to do their job. A ZTNA broker or mesh VPN handles this cleanly; we compared the options in Tailscale vs ZeroTier vs ZTNA.
• Restrict PostgreSQL at the auth layer too. pg_hba.conf is a second, independent gate. Use CIDR-scoped entries and hostssl, never host all all 0.0.0.0/0.

Database permission models are old, powerful, and almost universally misconfigured in small environments. The default state after most application installs is a single account with far more privilege than the application needs, shared by every process that touches the data. Five changes carry most of the value.

• Kill the shared superuser. The application should not connect as sa, postgres, or a member of db_owner. Create a role scoped to the tables and operations the app actually performs. Most applications need SELECT, INSERT, UPDATE, and DELETE on a specific schema and nothing else.
• Separate humans from services. Service accounts should be non-interactive and unable to log in from a workstation. Human accounts should be individually attributed, because an audit log that says "app_user" tells you nothing during an investigation.
• Use directory-backed identity where you can. SQL Server integrates with Active Directory and Entra ID; PostgreSQL supports LDAP, GSSAPI, and cloud IAM. That moves account lifecycle into the system you already manage, which means offboarding actually removes database access instead of leaving an orphaned login behind.
• Gate the admin accounts. Break-glass database credentials belong in a vault with checkout and session recording, not a password manager shared by the IT team. This is the core case for privileged access management.
• Rotate and inventory connection strings. Hardcoded credentials in config files, scheduled tasks, and reporting tools are the reason "rotate the database password" turns into a two-day outage. Inventory them before you need to rotate under pressure.

If your AD design predates this thinking, the Active Directory tiering model is the structural fix that makes the rest of it hold.

Encryption is the layer people assume is handled and frequently is not.

In transit is the easier win and the more commonly missed one. SQL Server accepts unencrypted connections unless you set Force Encryption; PostgreSQL does the same unless pg_hba.conf requires hostssl. On a flat internal network, an attacker with a foothold can read query traffic and harvest credentials without ever touching the database host. Force TLS on both, using a certificate the clients actually validate rather than a self-signed cert with validation disabled in the connection string.

At rest, SQL Server offers Transparent Data Encryption and PostgreSQL relies on volume encryption plus optional column-level encryption via pgcrypto. Be clear-eyed about what this buys: protection against stolen disks, decommissioned hardware, and snapshot exfiltration. It does nothing against a compromised application account, which receives decrypted data by design. Worth enabling, not a substitute for layers one, two, and four - our data encryption practice treats it that way.

This is the layer almost nobody has configured. Default logging on both platforms captures errors and connection failures - not successful queries, privilege changes, or bulk reads. Which is to say, none of the things you need during an investigation.

SQL Server Audit

SQL Server has a native, well-built audit framework. A server audit defines the destination (file, Windows Security log, or Windows Application log), and audit specifications define what gets captured. A reasonable starting specification captures:

• Successful and failed logins - the baseline for detecting credential abuse
• Role and permission changes - SERVER_ROLE_MEMBER_CHANGE_GROUP and DATABASE_ROLE_MEMBER_CHANGE_GROUP, since privilege escalation is a reliable attacker tell
• Schema changes - SCHEMA_OBJECT_CHANGE_GROUP
• SELECT on sensitive tables - scoped to the tables holding regulated data, not everything
• Audit configuration changes - so that disabling the audit is itself audited

Set the audit's ON_FAILURE behavior deliberately: SHUTDOWN is the strict choice for a compliance-scoped instance, FAIL_OPERATION is usually the right balance, and the default CONTINUE means an attacker who fills the audit volume silently blinds you.

PostgreSQL and pgaudit

PostgreSQL's built-in log_statement = 'all' is a blunt instrument - enormous volume, no structure. The pgaudit extension is the right tool, and it is available in every major managed PostgreSQL service and most distribution packages.

Configure it by class rather than globally. pgaudit.log = 'ddl, role, write' gives you schema changes, permission changes, and data modification at modest volume. Adding read globally on a busy OLTP database generates more log than the database generates data, so scope reads with object-level auditing instead: grant a dedicated audit role SELECT on your sensitive tables and set pgaudit.role to it.

Also enable log_connections and log_disconnections, and set log_line_prefix to include user, database, application name, and remote host. Without those fields, tying a database event to a person or machine is guesswork.

An audit log stored only on the audited host is a log an attacker with local administrator rights can edit or delete. That one gap undoes everything above.

Ship database audit events to a system the database account cannot write to - a SIEM, a log aggregation service, or at minimum a write-restricted share with append-only permissions. Once centralized, the events become correlatable with the rest of your telemetry: a bulk read at 2 a.m. is ambiguous on its own, and not ambiguous at all when it lines up with an impossible-travel sign-in from the same account forty minutes earlier.

Our guide to log retention and SIEM data sources covers sizing, and Microsoft Sentinel ingests both SQL Server audit and PostgreSQL logs natively. For businesses without an internal security team to watch the alerts, this is exactly what managed detection and response exists to cover.

Backups are usually owned by operations and evaluated only on whether a restore works. Treat them as a security asset too, because a backup file is a complete copy of the data with none of your access controls attached. Encrypt them with keys stored separately from the media, restrict storage access to a dedicated identity rather than the database service account, keep an immutable or offline copy since ransomware operators target backup repositories first, and test restores on a schedule against measured times - see RPO vs RTO for setting the targets.

On the Gulf Coast this overlaps with physical risk. Our hurricane season disaster recovery guidance and business continuity practice both assume the primary site can be unavailable for days.

If you are pursuing a compliance attestation or renewing cyber coverage, the database questions have become specific. Expect to demonstrate an inventory of databases holding regulated data with a named owner; access reviews showing who holds privileged access and when it was last checked; evidence of audit logging, meaning the configuration plus a sample of retained events; retention meeting the framework's requirement, typically twelve months for SOC 2 and PCI DSS; and encryption status at rest and in transit.

These map onto NIST 800-171 AU-family controls and the FTC Safeguards Rule requirement to monitor authorized user activity. The Texas Data Privacy and Security Act does not prescribe database logging directly, but its notification obligations are effectively impossible to meet without it - you cannot describe what was accessed if nothing recorded the access.

• Audit enabled, nobody reading it. Logging without alerting is forensics, not detection. Define at least three rules: privilege grants, audit configuration changes, and bulk reads above a threshold.
• Dev and test copies with production data. Rarely hardened the same way, frequently the actual breach path. Mask, subset, or protect them identically.
• Reporting tools with god-mode credentials. BI connectors get broad read access and then get shared widely. Scope them to views.
• Retention shorter than dwell time. Thirty days of logs will not cover the intrusion you find in month two.
• Unpatched engines. Databases get skipped because restarts are disruptive. Put them in the maintenance calendar deliberately - our patch management strategy covers scheduling around them.

You do not need a six-month project. Do this in the next two weeks:

1. Inventory. List every PostgreSQL and SQL Server instance, what data it holds, and who owns it. Include the ones running under someone's desk.
2. Check reachability. From outside your network, scan for 1433 and 5432. Anything that answers is your first fix.
3. Pull the privileged account list. For SQL Server, membership in sysadmin and db_owner. For PostgreSQL, roles with SUPERUSER or CREATEROLE. Remove what should not be there.
4. Turn on auditing for logins, privilege changes, and schema changes on your most sensitive instance. Start there, not everywhere.
5. Ship the logs somewhere else and write one alert rule.

For an outside read before committing to a plan, our security assessment covers database configuration alongside the rest of the environment, and the free IT assessment gives you a fast baseline. To run this continuously rather than once, managed IT services and co-managed IT both fold database hardening into the standard maintenance cycle.

Will audit logging slow down my database?

Scoped correctly, overhead is typically a low single-digit percentage for DDL, role, and write auditing. Unscoped read auditing on a high-transaction database is where performance problems come from. Audit reads only on tables holding sensitive data, benchmark before and after, and size log storage for the volume you measure rather than the volume you guess.

How long should I keep database audit logs?

Twelve months is the common compliance floor for SOC 2 and PCI DSS, with the most recent 90 days immediately searchable. Even without a compliance requirement, keep at least six months - attacker dwell time frequently exceeds a 30-day window, so shorter retention means the evidence is gone before you know you need it.

Does at-rest encryption satisfy a compliance requirement on its own?

No. Transparent Data Encryption and volume encryption address stolen media and snapshot theft. They do nothing about a compromised application account, which receives decrypted data by design. Frameworks requiring encryption almost always require access control and audit logging alongside it.

My database is managed by a cloud provider. Is this handled for me?

Partially. Managed PostgreSQL and SQL Server services handle patching and offer encryption and audit features, but enabling those features is your responsibility and the access model is entirely yours. Public accessibility, over-privileged application roles, and disabled audit extensions are all common in managed instances. The provider secures the platform; you secure the configuration.

We use a vendor application. Can we change the database permissions?

Sometimes, but verify with the vendor first - some applications genuinely require elevated rights, and many simply ship with a superuser connection because it was easier. Ask for the minimum permission set in writing. That request belongs in your vendor management process.

LayerLogix provides database security assessments, hardening, and audit log monitoring for businesses across Texas. With 20+ years of experience and 100% Texas-based support, we work with teams running everything from a single line-of-business SQL Server to multi-instance PostgreSQL environments.

• Managed IT Services in Houston
• Cybersecurity Services in The Woodlands
• Managed IT Services in Sugar Land
• Cybersecurity Services in Austin
• Managed IT Services in Dallas-Fort Worth

Ready to find out what your databases are actually exposing? Contact our team to schedule a database security review.