Data is the fuel that drives today’s economy. Its protection and reporting of any breach or other wrongdoing is increasingly expected and even dictated by new and emerging laws in Australia, Europe and across the world.
Networks and databases around the world are generating massive volumes of records regarding daily events — these records take the form of log files, which need to be audited. When it comes to data, auditing your log files helps reduce your company's exposure to spoofing, unauthorised database access, application manipulation, and misuse of privileges, as well as business downtime, reputation damage and legal liabilities.
Enter dedicated database auditing
Database audits are one of the most important components you can deploy in this age of compliance. You need to show that you are tracking and analysing what data was accessed, when it was accessed, how it was accessed, and by whom.
In the PostgreSQL open source world, FujitsuEnterprise Postgres delivers with a Dedicated Audit Log feature for data accountability, traceability, and auditability.
While many database systems have audit logs, the key here is that details relating to database access are stored in a dedicated audit log, by extending the PostgreSQL Audit extension (pgaudit) functionality. Since database access details are stored on a different location, message monitoring in the server log is not affected.
PCI DSS compliance
This feature is also compliant with Payment Card Industry Data Security Standard (PCI DSS). PCI DSS is a set of security standards designed to ensure companies that accept, process, store, or transmit credit card information maintain a secure environment. Fujitsu Enterprise Postgres is compliant with all PCI DSS requirements and as such can be used in these highly sensitive environments.
See the list of all PCI DSS requirements that relate to audit logs (audit trails) >>>
Furthermore, the Dedicated Audit Log in Fujitsu Enterprise Postgres provides the level of detail you'll need in an audit because it goes beyond providing basic statement logging via the standard logging facility with “log_statement = all”.
It establishes what happened while the database was satisfying each request. In fact, there are two types of audit log that can be output:
1. Session audit logging
Session audit logging provides a detailed log of:
- all SQL executed by a user in the backend
- information relating to starting and connecting databases, and
- information related to errors.
In session audit logging, performance degradation caused by the output of large volumes of log records can be prevented by specifying the log output conditions and filtering the log records.
"INSERT INTO myschema.orders(order_id, cust_id) VALUES ('55735', '6537');",<not logged>
AUDIT: SESSION,READ,2017-03-12 19:00:58 PDT,fephost2, 19975,psql,appuser,fsep,2/8,2,1,SELECT,,TABLE,myschema.customers,,
SELECT * FROM myschema.customers;,<not logged>
2. Object audit logging
Execution of SELECT, INSERT, UPDATE, or DELETE on specific objects (tables and columns), can also be output to the dedicated audit log. Object operations for which privileges have been assigned to specified roles can also be logged. Object audit logging can control log output at an even finer level of granularity than session audit logging.
SELECT order_id FROM orders;,<not logged>
UPDATE customers SET last_name = 'Smith' WHERE cust_id='6537';,<not logged>
Dedicated audit logging is a requirement of many commercial environments these days. So if you are considering an open source database strategy, consider the hardened version of PostgreSQL with Fujitsu Enterprise Postgres. Our technology and support team is ready to help do great things — and remain compliant along the way.
If you’d like to hear how you could be developing new applications with the use of performance and reliability of Fujitsu Enterprise Postgres, then contact our experts on email@example.com.