0

Our infrastructure is hosted on Google Cloud and uses postgresql instances via Cloud SQL

I need to configure logging for HIPAA compliance. I have read 2 articles from Google's documentation:

https://cloud.google.com/logging/docs/audit/configure-data-access#config-console https://cloud.google.com/sql/docs/postgres/pg-audit#overview

The first talks about enabling Audit Logs from within IAM, here I can select Cloud SQL and enable r+w logs for data and admins

The second talks about PgAudit and sets the following flag pgaudit.log=all

I have a couple of questions:

  1. How do IAM logs and PgAudit differ, should I enable both or is there redundancy by doing so?
  2. For HIPAA compliance using PgAudit, should I log all or is there another value that makes sense
Shawn Northrop
  • 5,826
  • 6
  • 42
  • 80

1 Answers1

2

How do IAM logs and PgAudit differ, should I enable both or is there redundancy by doing so?

Well the IAM Logs focus on Admin Activity and data access:

  • Admin Activity audit logs: Includes "admin write" operations that write metadata or configuration information.
  • Data Access audit logs: Includes "admin read" operations that read metadata or configuration information. Also includes "data read" and "data write" operations that read or write user-provided data.

On the other hand the pgAudit extension applies to executed SQL commands and queries.

Basic statement logging can be provided by the standard logging facility with log_statement = all. This is acceptable for monitoring and other usages but does not provide the level of detail generally required for an audit. It is not enough to have a list of all the operations performed against the database. It must also be possible to find particular statements that are of interest to an auditor. The standard logging facility shows what the user requested, while pgAudit focuses on the details of what happened while the database was satisfying the request.

For HIPAA compliance using PgAudit, should I log all or is there another value that makes sense

When it comes to HIPAA compliance, I do not have any experience in the topic, but in this page it is mentioned that part of the Technical safeguards of HIPAA security rule is to introduce activity logs and audit controls.

Maybe combining the IAM logs (Who did what, where, and when?) with the pgAudit(executed commands and queries) will provide better coverage to face this implementation specification.

  • That makes sense. Regarding PgAudit, all of the logs originate from the user that is configured for our API. Our application users are defined in the db and not IAM. Essentially we lose sight of (Who?) did what, where and when as all database logs originate from the api user. Do you know of any ways to approach this situation? – Shawn Northrop Nov 12 '21 at 03:54
  • Well, when we talk about Audit logs, it means that an audit log is a document that records an event in an information (IT) technology system. In addition to documenting what resources were accessed, audit log entries usually include destination and source addresses, a timestamp and user login information. And the information gathered by pgAudit is an audit log, so this information and the configuration that you can make to obtain more detailed information about your DB, should be enough to collect the information that you need. – Ismael Clemente Aguirre Nov 12 '21 at 18:18
  • Also, when you review the data access audit logs in GCP, do they not show any kind of information about the users who accessed the resources (read or write)? – Ismael Clemente Aguirre Nov 12 '21 at 18:18
  • Here is an example log from PgAudit: ```{ "@type": "type.googleapis.com/google.cloud.sql.audit.v1.PgAuditEntry", "auditClass": "READ", "auditType": "SESSION", "chunkCount": 1, "chunkIndex": 1, "command": "SELECT", "database": "app-db", "databaseSessionId": 249726, "object": "", "objectType": "", "parameter": "", "statement": "SELECT \"foo\".\"created\" FROM \"foo\" WHERE \"foo\".\"id\" = 'xxxxxxxx-xxx-xxx-xxx-xxxx'::uuid", "statementId": 12, "substatementId": 1, "user": "api-user" }``` – Shawn Northrop Nov 12 '21 at 18:37
  • As you can see, the "api-user" executed this statement. The actual authenticated user was using our frontend application, which in turn called the api, which called the db. – Shawn Northrop Nov 12 '21 at 18:38
  • 1
    This question deserves a new post in SO, please post your issue as a new question, in order to reach more users and find a solution or workaround for your doubt. – Ismael Clemente Aguirre Nov 17 '21 at 23:49