Wasabi Hot Storage with S3 Object Lock: Meeting Essential Eight Backup Requirements

The Essential Eight remains the foundation of cyber security uplift across Australian government, aged care, and enterprise environments. Of its eight mitigation strategies, the regular backups control often receives the least architectural scrutiny, yet it is the control that determines whether an organisation can recover after a ransomware event or a compromised administrator account. Modern extortion campaigns deliberately target backup repositories first, because attackers understand that intact, restorable data removes their leverage entirely.

Immutable object storage addresses this threat directly by ensuring that backup data cannot be altered or deleted for a defined retention period, even by a privileged account. Wasabi Hot Storage, an S3-compatible cloud storage service, supports S3 Object Lock and can serve as a cost-effective destination for immutable backup copies. This article explains how Object Lock in compliance mode maps to the Essential Eight backup expectations, and how to configure it as part of a tested, air-gapped restore strategy.

What the Essential Eight expects from backups

The Essential Eight Maturity Model treats regular backups as a control with escalating requirements across its maturity levels. At the higher levels, the model expects backups of important data, software, and configuration settings to be performed and retained in accordance with business continuity requirements. Critically, it also expects that unprivileged accounts, and privileged accounts other than a designated backup administrator, cannot access, modify, or delete backups during their retention period.

This last expectation is where many backup designs fail. If a domain administrator or a compromised backup service account can delete or encrypt the backup repository, the backups provide no genuine protection against a determined attacker. The maturity model also requires that restoration of data, applications, and settings is tested as part of disaster recovery exercises, which means immutability alone is insufficient without a proven recovery process. Meeting these combined requirements calls for storage that enforces retention independently of the identities that manage the environment.

How S3 Object Lock delivers immutability

S3 Object Lock is a write once, read many capability that prevents object versions from being overwritten or deleted for a specified duration. It operates in two modes, and the distinction matters for compliance. In governance mode, users with sufficient permissions can still shorten the retention period or remove the lock, which offers flexibility but leaves a path for a compromised privileged account to tamper with data.

Compliance mode removes that path entirely. When an object is written under compliance mode with a retention period, no account can delete or modify it until the retention period expires, including the root or account owner. This behaviour is precisely what the Essential Eight backup control seeks, because it guarantees that even a fully compromised administrator cannot destroy the restore points. Wasabi supports Object Lock with these modes, allowing organisations to enforce retention at the storage layer rather than relying on the backup application or the surrounding identity controls.

Configuring Wasabi Object Lock in compliance mode

Object Lock must be enabled at the point a bucket is created, because it cannot be retrofitted to an existing bucket. When provisioning the destination, enable Object Lock and confirm that versioning is active, since Object Lock depends on object versioning to protect individual versions of each backup file. From there, define a default retention configuration that applies compliance mode and a retention period aligned to your business continuity and regulatory obligations, for example a period that satisfies aged care records retention or government recordkeeping requirements.

Careful planning of the retention period is essential, because compliance mode locks are irreversible for their duration and directly influence storage consumption and cost. Set the retention window to match your recovery point objectives and any legal hold obligations, and model the storage footprint that results from retaining multiple immutable versions over that window. Access to the storage account should follow least privilege principles, with a dedicated backup identity, separate credentials, and multi factor authentication, so that the storage tier and the production environment do not share a single point of compromise.

Tested, air-gapped restore points in practice

Immutability creates a logical air gap, because backup data written to a separate cloud account under compliance mode is isolated from the production identity plane and cannot be reached by an attacker who has taken control of the internal environment. To realise this benefit, the backup application should authenticate to Wasabi using credentials that are not reused elsewhere and are not stored on systems within the protected network. Many Microsoft-centric organisations already protect Microsoft 365 and Azure workloads with backup tools that support S3-compatible immutable targets, allowing an existing Microsoft-native backup strategy to write immutable copies to Wasabi without replacing the primary platform.

Immutability is only half of the control, because the Essential Eight also requires that restoration is tested. Establish a schedule for restoration exercises that validates recovery of representative data, applications, and configuration settings, and record the results so they can be presented during an assessment. Regular testing confirms that the restore points are complete and usable, verifies that recovery time objectives are achievable, and surfaces configuration drift before a real incident forces a rushed recovery. Combining compliance mode immutability, least privilege access, and documented restoration testing produces a backup posture that stands up to both ransomware and administrator compromise.

References

• ACSC Essential Eight Maturity Model
• Amazon S3 Object Lock documentation