Skip to content
Cloud Provider Benchmarks

Cloud security & auditing

Cloud audit trail best practices: coverage, retention, integrity and review

A practical checklist for cloud audit trails: what to log, how long to keep it, how to protect it from tampering and how to review it, mapped to provider features.

Published: Updated: Türkçe oku

Direct answer

Log all control-plane activity in every account and region, enable data-access logging for sensitive resources, attribute every event to an individual identity, export logs to separate write-once storage, retain them for at least a year, restrict who can change logging, and review high-risk events continuously.

Executive summary

A cloud audit trail is only useful if it is complete, retained long enough, protected from tampering and actually reviewed. This checklist groups best practices into coverage, identity, retention, integrity, access control, normalisation and review, with references to NIST SP 800-92 and the CIS Controls, and shows which provider features support each practice.

Key findings

  1. 01 Coverage gaps are the most common failure: new accounts, new regions and data-plane access are often not logged.
  2. 02 Logs stored in the same account an attacker controls can be deleted; separate accounts or projects and write-once storage reduce that risk.
  3. 03 Shared credentials defeat attribution — the audit trail can only be as specific as the identities used.
  4. 04 Changes to logging configuration should themselves be logged and alerted on.

1. Coverage

  • Enable control-plane logging in every account, subscription or project and every region, including ones you do not expect to use.
  • Enable data-access logging for sensitive stores (object buckets with personal data, secret managers, key management) and accept the cost.
  • Include organisation-level events (account creation, policy changes) as well as workload events.

2. Identity

  • Use individual identities for people and distinct service identities for automation; shared credentials make attribution impossible.
  • Capture the scope (account, project, role or session) along with the user, so you can tell which privileges were used.
  • Federate sign-in to a central identity provider so audit identities match HR records.

3. Retention

  • Define retention by policy and regulation; a year is a common baseline.
  • Export to storage you control before the provider’s default window expires.
  • Keep enough request metadata (source IP, user agent, request ID) to correlate with network and application logs.

4. Integrity

  • Use integrity validation where available (CloudTrail digest files).
  • Write exported logs to write-once storage (object lock or retention policies).
  • Store logs in a separate security account or project that workload administrators cannot modify.

5. Access control

  • Restrict who can stop, delete or reconfigure logging; alert on any such change.
  • Separate read access for investigators from write access for the logging pipeline.

6. Normalisation

If you operate in more than one cloud, normalise events to a common schema so that rules and searches work across providers. The event model below maps vTrail’s fields to CloudTrail, Google Cloud and CADF equivalents.

Conceptual cloud audit event data model For research documentation; does not represent production audit records.
Field Type Description AWS CloudTrail Google Cloud Audit Logs OpenStack CADF
event_time string (RFC 3339) When the operation was received, in UTC. eventTime timestamp eventTime
request_id string Unique request identifier used to correlate gateway, service and resource logs. requestID insertId / operation.id id / requestId (attachment)
http_method string HTTP verb of the API call (GET, POST, PUT, PATCH, DELETE). — httpRequest.requestMethod action (mapped)
full_path string Requested API path, identifying the target resource. eventSource + eventName protoPayload.methodName / resourceName target.id / requestPath
http_status integer Response status code — the outcome of the operation. errorCode (on failure) protoPayload.status.code outcome / reason.reasonCode
client_ip string (IP) Source IP address of the caller. sourceIPAddress protoPayload.requestMetadata.callerIp initiator.host.address
user_agent string Client software (console, CLI, SDK, Terraform). userAgent protoPayload.requestMetadata.callerSuppliedUserAgent initiator.host.agent
auth_user_id string Stable identifier of the authenticated user. userIdentity.principalId protoPayload.authenticationInfo.principalSubject initiator.id
auth_user_name string Human-readable user name at the time of the request. userIdentity.userName / arn protoPayload.authenticationInfo.principalEmail initiator.name
auth_project_id string Project (tenant) the token was scoped to. recipientAccountId resource.labels.project_id initiator.project_id
auth_scope string Authorisation scope or role context of the token. userIdentity.sessionContext protoPayload.authorizationInfo initiator.credential
service_id string Backend cloud service that handled the request (compute, network, storage). eventSource protoPayload.serviceName observer.id / target.typeURI
route_id string API gateway route that matched the request. — — —
request_time number (ms) End-to-end request processing time. — httpRequest.latency —
Empty template (JSON)
{
  "event_time": "",
  "request_id": "",
  "http_method": "",
  "full_path": "",
  "http_status": null,
  "client_ip": "",
  "user_agent": "",
  "auth_user_id": "",
  "auth_user_name": "",
  "auth_project_id": "",
  "auth_scope": "",
  "service_id": "",
  "route_id": "",
  "request_time": null
}

7. Review

  • Alert continuously on a short list of high-risk events (see cloud activity monitoring).
  • Review privileged activity on a schedule.
  • Test the trail: perform a known action and confirm it appears, attributed correctly, in the exported store.

How provider features map to the checklist

Documented features of cloud audit logging services
Feature vTrail PortvMind Cloud AWS CloudTrail Amazon Web Services Azure Monitor Activity Log Microsoft Azure Cloud Audit Logs Google Cloud
Control-plane audit scope Records management operations (create, modify, delete) performed through the API or console. Yes Cloud management API operations. Yes Management events recorded by default. Yes Azure Resource Manager write/delete/action operations. Yes Admin Activity logs always enabled.
Identity attribution Identifies the authenticated user, project/account and scope behind each operation. Yes User ID, user name, project ID and auth scope. Yes userIdentity block (principal, account, session). Yes Caller and claims. Yes authenticationInfo.principalEmail.
Request metadata Captures request ID, HTTP method, path, status code, source IP and user agent. Yes Request ID, HTTP method, path, status, client IP, user agent, request time. Yes eventTime, requestID, sourceIPAddress, userAgent, errorCode. Partial Correlation ID, operation, status and caller IP in HTTP request details where available. Yes requestMetadata.callerIp and callerSuppliedUserAgent; status.
Data-plane (data access) events Optional recording of data-level reads and writes (for example object reads). Unverified Yes Data events (for example S3 object-level) are optional and charged. Partial Via resource logs and diagnostic settings, not the Activity Log itself. Yes Data Access logs, mostly disabled by default.
Event search and filtering Console or API search by user, time range, resource or operation. Unverified Yes Event history lookup; SQL queries in CloudTrail Lake. Yes Portal filtering and Log Analytics (KQL). Yes Logs Explorer and Log Analytics.
Configurable retention Documented default retention and options to extend it. Unverified Yes 90-day event history; longer retention via trails to S3 or CloudTrail Lake. Yes 90 days in the platform; longer through Log Analytics or Storage. Yes Admin Activity retained 400 days in _Required; other buckets configurable.
Export and streaming Delivery to object storage, log analytics or SIEM pipelines. Unverified Yes S3, CloudWatch Logs, EventBridge. Yes Diagnostic settings to Log Analytics, Storage and Event Hubs. Yes Sinks to Cloud Storage, BigQuery and Pub/Sub.
Log integrity validation Cryptographic or immutability controls that detect tampering. Unverified Yes Log file integrity validation with digest files. Partial Immutable storage policies on the export destination. Partial Locked log buckets prevent retention changes.
Pricing model Whether baseline audit history is included and how extended capabilities are charged. Unverified Yes Event history and one copy of management events free; data events and Lake charged. Yes 90-day Activity Log included; ingestion into Log Analytics is charged. Yes Admin Activity at no charge; Data Access ingestion charged beyond free allotment.
Information source Supplied by provider team Official documentation Official documentation Official documentation

Limitations

This checklist is general guidance, not legal or compliance advice. Provider feature assessments follow the cloud auditing methodology; vTrail details are provider-supplied and several are marked unverified.

Conclusion

An audit trail fails quietly: missing regions, short retention or deletable storage are only discovered during an incident. Close coverage gaps first, move logs somewhere attackers cannot reach, and test the trail regularly.

Frequently asked questions

How long should cloud audit logs be kept?

As long as your policies and regulations require; one year is a common minimum, with some frameworks requiring longer. Default provider retention is often shorter, so plan for export.

What is a tamper-evident audit log?

One where alteration or deletion can be detected, for example through signed digest files or storage that prevents modification for a retention period.

Sources

  1. [1] NIST SP 800-92: Guide to Computer Security Log Management — NIST Official documentation accessed:
  2. [2] CIS Critical Security Controls — Audit Log Management — Center for Internet Security Secondary source accessed:
  3. [3] AWS CloudTrail User Guide — AWS Official documentation accessed:
  4. [4] Cloud Audit Logs overview — Google Cloud Official documentation accessed:
  5. [5] Azure Monitor activity log — Microsoft Official documentation accessed: