Multi-Tenant Log Auditing for Government Cloud: Isolation, Retention, and MLPS 2.0

Where multi-tenant isolation ends

The typical government cloud setup: the platform owner runs one observability system, and dozens of agencies plug in their own application logs. If isolation is weak, an operator from agency A can search agency B's logs—and in a government context, that is not a bug, it is an incident with real consequences.

Isolation must happen in three layers at once. Data layer: shard by tenant (agency), tagging every record with tenant_id at write time. Permission layer: resource-level authorization per tenant, so search, alerts, and dashboards only ever see their own tenant. Presentation layer: inject the tenant context into every query so nobody can forget a where clause and leak data. Miss any one layer and isolation is paper-thin, no matter how good the other two look in a demo.

What audit logs must keep, and for how long

Audit logs are not business logs: they record who did what to the system, and when. Login, search conditions, exports, config changes, and alert handling must all be captured in full, and no role may delete or modify them—not even an administrator, because the whole point is an immutable record.

Retention follows the Cybersecurity Law and MLPS requirements: keep logs for at least 6 months, and 12 months or more for critical information infrastructure. Compress cold data into archives—read-heavy, write-light, cheap. Keep audit logs separate from business logs so routine cleanup never sweeps audit records away with it, and so a retention policy change on business logs cannot silently shorten your compliance window.

Hard requirements in MLPS 2.0

MLPS 2.0 has explicit clauses on log auditing. Focus on these:

• Audit records must include event time, subject (user/process), object (resource), and result, with time synced to a unified NTP;
• The audit process and records must be protected against unauthorized deletion, modification, or overwrite;
• Critical operations (failed logins, privilege-escalation attempts, config changes) must trigger alerts to the security administrator;
• Audit logs must be backed up periodically against host failure.

A deployable checklist

Here is a minimal workable plan:

1. Create an isolated tenant per agency; enforce tenant_id at the ingest layer and reject records that lack it.
2. Route audit events through a dedicated topic into an immutable audit index with all delete interfaces disabled.
3. Alert rules cover: repeated login failures, off-hours exports, and cross-tenant query attempts.
4. Back up the audit index to object storage daily, rolling on a 12-month retention policy.

One more: give the audit index a hot/warm/cold tier split—last 30 days queryable in seconds, anything older than 90 days archived to cold—so query experience and storage cost stop fighting each other. Before go-live, run an authorization drill: use agency A's account to search agency B's data. The result must be empty, and the attempt must leave an audit record. Pass that and you are actually compliant—not just configured, but verifiably so.

Finally, agree up front on who can read the audit index. Auditors and security administrators get read access; operators get read access only to their own tenant's business logs, never to another tenant's audit trail. This separation is what makes the record trustworthy when an incident review asks who searched what and when—the answer must come from a system that cannot be edited after the fact. A common mistake is routing audit events through the same ingest pipeline as business logs and letting one retention job touch both; keeping the two streams separate from day one is far cheaper than disentangling them later.

One more operational detail: most of what people actually query in an audit index is a handful of recurring questions—"who logged in as X in the last week," "show every export from this tenant in the last quarter," "who changed this alert rule." If you pre-build these as saved queries with tenant and time-range parameters, an auditor can self-serve the answers instead of filing a request with ops. It sounds trivial, but it is where compliance reviews either glide through or get stuck for days.