Audit and verification

OBSESC gives you three ways to show what happened to your data. The query audit trail records who read it. Optional custody verification shows whether OBSESC’s stored records have been changed. Evidence bundles package results so a third party can check them.

Query audit trail

The audit trail is on by default. It writes one record for every API request the console or a client makes, including requests refused because the caller lacked permission. Requests that fail authentication aren’t recorded. Each record contains:

Field	Meaning
ts_ms	When the request happened
principal, role	Who made the request, for example a signed-in user’s identity
method, endpoint	What was requested
request_sha256, request_bytes	A digest and size of the request
status	The HTTP status returned

Records are written to the query/audit/ prefix of your raw bucket.

Query text isn’t stored by default. SQL and search terms often contain customer data, such as user IDs, so a record holds only a digest that you can use for correlation. Record the full text only if the people who can read the trail are cleared to see query content:

security:
  audit:
    enabled: true
    record_query_text: false   # true stores the query text verbatim

Reading the trail

Reading the trail needs the audit:read permission. Only admin has it by default, or you can grant it to a custom auditor role (see IAM and permissions).

curl -s "https://<node-private-ip>:18080/v1/audit?limit=500" \
  -H "Authorization: Bearer $TOKEN" | jq '.records[]'

The trail returns newest records first. The default limit is 100 and the maximum is 1000.

A slow or broken audit store never slows or fails a query. If a record can’t be written, the trail has a gap. Contact us if you need to monitor for gaps.

Custody verification

Custody verification is optional and off by default. When it’s on, OBSESC keeps tamper-evident records that let you verify its stored data hasn’t been altered or removed since it was written.

• Turning it on. Set the stack parameter EvaluationFeatures to Enabled. This also turns on other optional console features. On an existing stack, contact us before you change it.
• Coverage. Verification covers data written after you turn it on. Earlier data isn’t covered.
• What it doesn’t cover. It doesn’t cover the raw events in your S3 bucket. Protect those with S3 Object Lock.
• Retention and erasure. Data removed by retention, and erasures you carry out, aren’t reported as tampering.
• Verifying. You can verify custody at any time, and evidence bundles include verification reports for the services you choose. Contact us if you need help interpreting a result.

Verification is tamper-evident, not tamper-proof. Someone with administrator rights in the account that holds the data could change the data and its records together. For stronger protection, OBSESC can publish regular integrity checkpoints to a bucket in a separate account protected by S3 Object Lock in compliance mode. Verification reports can also be signed with a key you control, so an auditor can confirm they came from your deployment unchanged. Contact us to set up either of these.

Evidence bundles

From the console you can build an evidence bundle: a zip file for handing to an auditor or investigator. Give it a label and choose what to include, such as an incident’s evidence or a set of queries over a time window. The bundle contains:

• the query results
• custody verification reports for the services you choose, if custody verification is on
• a manifest listing a SHA-256 digest of every file in the bundle

If part of a bundle can’t be built, the bundle is still produced, but it is labelled incomplete and the failed part is included as an error file.

Limits

• Verification can’t reach further back than your configured retention.
• Verification covers OBSESC’s own stored records. Your raw bucket is protected by S3 Object Lock, not by custody verification.

Related

• Compliance for retention, legal holds and erasure
• IAM and permissions