Audit Events

This is an attempt to codify how audit events should ideally work. It is not representative of how audit events currently work in CC.

This applies only to audit events. It does not apply to usage events!

Product Description

An audit event shall be created:

1. When the action represented by the event is attempted
2. Regardless of whether the event was triggered directly by user action
3. Regardless of whether the action succeeds or fails
4. After authentication and authorization are checked
5. After superficial validations are completed
6. For async jobs, when work on the async job is started, not when it is requested

Engineering Implications:

1. Audit events should be created in Action classes
2. Audit events should be created before work is attempted in the action
3. Audit events should not be created in transactions shared with other resources

Interesting case studies

app.crash

• Triggered by TPS watcher, not indicative of user action/ intent

audit.app.delete-request (and other audit.*.delete-request)

• Named "delete-request" instead of "delete"

audit.service.*

• Generally occurs when operation succeeds instead of when attempted

blob.remove_orphan

• Triggered by nightly job, non indicative of user action/ intent