Cloud Security
Intermediate 16 min read Cloud Security

Cloud Audit Trail: The Trail, Logs, and Evidence

Build the evidence trail that makes cloud audits and incident response possible: who did what, when, from where, and what the provider actually logs.

AWS CloudTrailAzure Monitoraudit logsimmutabilityevidencelog forwarding
Prerequisites: IAM Basics Telemetry and Logging
Introduction

What is this?

Cloud audit logging captures the control-plane actions on your account — API calls, who invoked them, their source — so security and compliance can reconstruct events weeks later.

Motivation

Why do you need it?

  • No incident response, no compliance attestation, no IAM cleanup works without 'what happened' evidence.
  • Audit logs are cheap insurance: the only control that answers 'who did that' after the fact.
  • Providers log only what you enable; a default-off audit trail is a self-inflicted blind spot.
Think about it

Mental model

Imagine

A building's key-card log

Think of

The building changing its locks weekly without logs

You may think you secured it — but you cannot even tell who your own team let in.

Mechanics

How it works

  • CloudTrail/Monitor events write API calls with identity, action, resource, and source IP to a log.
  • Logs are usually delivered to an immutable store (S3 object-lock / blob immutability) so tampering is impossible.
  • Enablement thresholds matter: management events by default, data events on demand (noisy).
  • Forward to your SIEM/analytics; correlate with metric and flow logs for the full picture.

The audit trail pipeline

API call
Log
Immutable
Forward
Evidence
Real world

In production

  • An incident responder replays the 48h trail around a key leak: every action the key touched, from one query.
  • A compliance team proves 'no admin login at 3am' with the immutable log the auditor actually trusts.
  • An org enables data-event logging on one sensitive bucket for 90 days, catches an exfil pattern, and tunes a rule.
Guidelines

Best practices

  • Enable audit logging in EVERY region on day one; a region without a trail is a hole.
  • Send logs to an immutable, cross-account store with least-privilege readers.
  • Alert on management-plane anomalies: root usage, new IAM user, security-group opens.
  • Retain per compliance the full period; never purge audit evidence on a whim.
Watch out

Common mistakes

  • Leaving audit logs in the same account as the attacker's first foothold — covered up or deleted with the account.
  • Enabling management events but never data events where the actual data touches happened.
  • Never querying the logs; a trail that is never read is storage, not protection.
  • Letting ingestion pipelines drop events silently for misshapen JSON.
When things break

Debugging tips

  • Search a single event by its eventName + who = fastest root-cause query.
  • Compare trail timestamps against your metric timestamps for clock-skew sanity.
  • Test your retention: delete a test record in a scratch path and confirm the object-lock blocks it.
Security

Security considerations

  • Audit logs themselves are sensitive evidence — restrict read access and protect at rest.
  • Your own test events pollute the trail; tag them so analysts can filter.
Interviews

Interview checkpoint

Practice

Hands-on lab

Produce, Lock, and Query a Local Audit Trail
40 min · intermediate
In progress
Objectives
  • Simulate audit events locally with a script YOU write.
  • Write them to a file with a hash chain so tampering is detectable.
  • Verify the chain: append one record, re-hash, and watch the mismatch.

Produce, Lock, and Query a Local Audit Trail

40 min · intermediate

0/3 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

Audit events are most useful for...

2

Why forward audit logs off-account (immutable store)?

Go deeper

Official documentation

AWS CloudTrail docs
docs
Azure Activity Log docs
docs