Audit logs

[tgeoghegan]

Subscribers may want audit logs of sensitive operations:

• logins
• adding users to accounts
• CRUD on tasks
• CRUD on paired aggregators

We should emit audit logs that note what user did this and perhaps things like IP address or a geolocation.

[jbr]

If we intend to display these logs through the web interface, it may make the most sense to throw them in the database and associate them with the given account and membership or token.

[jbr]

I assume we only need create/update/delete logs for tasks or aggregators, not read? The web interface makes a lot of duplicate get requests to make sure that the interface is displaying fresh data. The only GET requests I think we'd want audit logs for would be task collector auth tokens, as they're more sensitive

[branlwyd]

We should probably talk to subscribers about their expectations.

An in-UI audit log makes sense if that's what subscribers want.

However, we might also export audit logs via the normal logging process, set up with an appropriate retention period. This wouldn't expose audit logs to subscribers but would allow us to provide support for cases like "[something bad] happened with our account, can you tell us why?" It would be less costly to implement/maintain this than an in-UI audit log.

[jbr]

Stdout is definitely easier but if they want access to logs, in-ui isn't terribly hard to implement (I've built a few versions of it in the past). I do think in-ui logging is easier than offering to send logs to some external log ingestion system on a per-account basis, which I was worried might be floated as an possibility. We could possibly do an outbound webhook on activity, but I think we'd still want a local record in the db

[jbr]

I think most within-account acl features on b2b apps can be replaced with soft deleting records and having an audit trail that's visible to everyone. People are way less likely to abuse permissions when they know it's easy to see exactly what they did and revert it

[jbr]

It seems like the "we'll log it to gcp log collection and if you want to know what happened, contact a support person (engineer) and we will investigate" likely works for a while, but doesn't scale particularly gracefully because every audit investigation requires human intervention. I think for that level of infrequent investigation we already have sufficient info in our http logs, or could easily supplement them