I’m looking at using the pgaudit extension on my Postgresql database to maintain an audit trail, which as I understand it would create the audit trail in the Postgres logs.
What are the best practices around logging and archiving those logs in a HIPAA compliant environment? I see archiving to S3 mentioned in the Aptible Log Drain documentation as well as the documentation for tools like Datadog and Mezmo (LogDNA), but if logs are archived to an S3 account I control then HIPAA data has left the managed Aptible/Datadog/Mezmo stack and I’m responsible for ensuring my AWS account’s HIPAA compliance, which is what I’m trying to avoid/delegate as much as possible by using Aptible/Datadog/Mezmo in the first place. Is the trick just to exclude PHI/PII from the logs? If that’s the case, is an audit trail without the details of what changed “good enough” for HIPAA (i.e. “user X changed record B”, not “user X changed the phone number in record B to 1234556789”)?
Does anyone have experience maintaining an audit trail for HIPAA using the pgaudit extension? Or maybe even maintaining an audit trail at the application level (I’m using python and sqlalchemy)?
Perhaps one way to look at your logging requirements as a whole is to consider your application’s audit logs and your application’s container/system logs as two separate concerns. Your custom application presumably will have activities that should be audit-logged in a HIPAA environment, such as creating/updating/deleting records inside the application.
In relation to your container logs, we are considering those logs sent to stdout or stderr from your application and database containers, as well as ssh sessions and endpoints. In those cases you also have several options, including to create log drains which send logs to self-hosted Aptible ElasticSearch database, or to send your logs via log drains to other hosted logging services such as LogDNA, Datadog, Sumo Logic, and others.
Given that PHI may be included in those logs, it is important to ensure that those providers have a BAA with you. In practice, it is generally advisable to store as little PHI as possible and even potentially completely mask/filter it from logs except in cases where it is required for temporary debugging.
Another example of limiting PHI in logs would be to store an internal record id in an error message instead of raw PHI (patient name), which would still be useful for debugging, but provides security in that it requires an internal user to use the secured application to get additional context.
A quick list of documentation for additional information: