Which Essential Eight backup requirements Ceph helps you meet
Ceph can help with three backup requirements in the Information Security Manual (ISM) that sit under the Essential Eight: keeping backups from being changed or deleted during their retention period (ISM-1708), keeping backup administrator accounts separate from the accounts that may access their own backups (ISM-1813 and ISM-1706), and testing restoration to a common point in time (ISM-1515). It does not address the other seven mitigation strategies, and it does not make an environment compliant on its own. The Essential Eight is a set of mitigations assessed against the Essential Eight Maturity Model, not a certification scheme, so there is no ASD certificate to obtain. DeployOpen prepares the Ceph configuration, systems and evidence for an assessment, but it does not issue an assessment result or certificate. Independent assessors reach that conclusion.
The Essential Eight, published by the Australian Signals Directorate through the Australian Cyber Security Centre, lists eight strategies: patch applications, patch operating systems, multi-factor authentication, restrict administrative privileges, application control, restrict Microsoft Office macros, user application hardening and regular backups. The Essential Eight Maturity Model was first published in June 2017, and its current release is dated November 2023. It defines Maturity Levels Zero to Three, and Levels One to Three each set requirements for all eight strategies. In the ISM Essential Eight profiles, every ML1 control is also in ML2, and all but three ML2 controls (ISM-1691, ISM-1695 and ISM-1873) are also in ML3. An organization targeting ML2 therefore inherits the ML1 backup controls, but it should confirm the level of each backup control in the profile version it is assessed against.
Mapping ISM backup controls to Ceph RGW configuration
This table maps the four ISM backup controls in scope to the Ceph capability that addresses each one, the configuration step to set, and what an assessor will ask to see. Read it as a build checklist: the bucket configuration and account separation are decided before the first backup is written, and the restore evidence is what proves the controls work.
| Control and need | Ceph capability and configuration | Evidence to keep |
|---|---|---|
| ISM-1708: backup administrators cannot modify or delete backups during retention | RGW Object Lock on a backup bucket, with a default retention rule set when the bucket is created. Confirm with your release notes how Object Lock is enabled and whether it can be turned on for an existing bucket on Squid or Tentacle. | Bucket creation settings, retention mode and period, and a test showing a delete or overwrite attempt is refused before expiry |
| ISM-1708: separation of backup administration from data access | A bucket policy and IAM identity that let the backup account write and read backup objects but not change Object Lock settings or delete versions. Keep the policy file under version control. | Exported bucket policy, IAM user or role definitions, and the change record for each policy revision |
| ISM-1813 and ISM-1706: unprivileged and non-backup privileged accounts cannot reach backups | Separate RGW users or STS-issued roles for the workload, the platform administrator and the backup account. Deny workload and administrator principals on the backup bucket in the bucket policy and confirm the deny with a test request from each. | Access test results per account, IAM policy listings, and a periodic access review signed by the data owner |
| ISM-1515: restoration to a common point in time is tested | Restore tests that rebuild a consistent set of data from the backup bucket, using recorded object versions and timestamps. Snapshots of RBD or CephFS are a separate concern and must be backed up to the bucket before they are relied on as recovery copies. | Restore test reports with start and end times, recovery point reached, and any data that could not be restored |
| Cross-cutting: keys and credentials for the backup account | Store backup account credentials outside the cluster, rotate them on a planned schedule and record who holds them. Confirm the encryption options available for backup objects in your release before relying on them. | Key custody record, rotation log and the list of holders with their approvals |
Configuring an immutable RGW backup repository step by step
This sequence turns a Ceph Object Gateway cluster into a backup repository where Object Lock holds backup copies unchanged through their retention period, with separate identities for writing, administering and restoring. Each step closes with a check you can record as evidence for the Essential Eight backup and privileged access controls.
Confirm the supported Ceph release
The platform engineering lead confirms which Ceph release the repository will run on before any build work starts. The active releases page lists Tentacle (20.2.x) and Squid (19.2.x) as actively maintained, with published end-of-life estimates for each. Record the chosen release, its end-of-life date and your upgrade window in the design record, because the retention commitments in this design will outlast any single release. Done when the release decision and its support horizon are approved by the CIO or platform owner.
Deploy the Object Gateway with cephadm
The storage engineering team bootstraps the cluster with cephadm, then places RGW daemons on hosts that sit behind the load balancer you have chosen for backup traffic. Cephadm runs Ceph as containers and manages services after bootstrap, so keep the gateway hosts, the backup network and the administrative network documented separately. Illustrative check: confirm the gateway service reports running on every planned host and that an S3 client can list buckets using a test credential. Done when the gateway answers over TLS from the backup network only.
Create the backup bucket with Object Lock enabled
The storage engineer creates a dedicated bucket for backup copies and enables Object Lock at creation, since the setting is applied when the bucket is made. Keep this bucket separate from application and analytics buckets so that no other workload shares its lifecycle or permissions. Illustrative check: request the bucket's Object Lock configuration and confirm the feature is enabled. Done when the bucket exists, Object Lock is on and the bucket name is recorded in the backup register.
Agree retention mode and period with the backup owner
The backup owner, with the risk and compliance lead, selects the default retention mode and period for the bucket and records which backup classes each rule covers. This decision drives ISM-1708, which requires that backup administrator accounts cannot modify or delete backups during retention, so the choice must be made by the business owner, not the storage team alone. Confirm with your own control owners how exceptions, such as legal holds, will be handled. Done when the signed retention decision names the mode, the period and the exception process.
Create the backup-writer identity
The identity team creates a backup-writer account that can upload objects and set retention on the backup bucket, but holds no permission to delete object versions or to shorten or remove retention. Keep this account used only by the backup software, with its key stored in your secrets platform. Illustrative check: attempt a version delete and a retention change with this identity, and confirm both are refused while an upload succeeds. Done when the test results are saved with the identity definition.
Create a separate backup administrator identity
The security team creates a backup administrator account for managing the repository, separate from the writer and from any day-to-day storage or workload administrator. This account is the only one permitted to modify or delete backups within the rules you set, and its use should be logged and reviewed. Assign it to named people, require multi-factor authentication through your identity provider, and keep its privileges narrow enough that the ISM-1708 position is defensible. Done when a role review confirms no other account can change backup retention or delete backup versions.
Restrict workload and unprivileged access to backups
The security engineer reviews every bucket policy, user and role on the gateway, and removes read access to the backup bucket from application workloads, end users and privileged accounts other than the backup administrator. This addresses ISM-1813 and ISM-1706, which say these accounts must not access their own backups. Illustrative check: run read requests against the backup bucket from a workload identity and confirm they are denied. Done when access test results are attached to the control record and any exception is documented with an owner.
Enable msgr2 secure mode and dashboard SSO
The platform team enables msgr2 secure mode so that post-authentication traffic inside the cluster is encrypted and integrity-checked, and configures single sign-on for Ceph Dashboard administrators using SAML 2.0, or OAuth2 when cephadm runs the Management Gateway and OAuth2 Proxy services. Confirm which option your release and deployment support before you commit to it. Illustrative check: verify the messenger configuration reports secure mode and that a dashboard login through the identity provider succeeds for a test administrator. Done when both settings are recorded in the configuration baseline.
Schedule and record restore tests
The backup owner and operations lead schedule restore tests that recover a sample of backup objects to a separate recovery target, then compare them with source data. ISM-1515 requires restoration to a common point in time to be tested in disaster recovery exercises, so include a multi-system restore in the plan, not just single-object retrieval. Record who ran each test, the point in time restored, the checks performed and the findings. Done when the first test report is accepted by the backup owner and the next test date is set in the change calendar.
Evidence an assessor will ask to see for backup controls
An assessor testing backup controls under the Essential Eight will want proof that immutability is configured, that backup administrators are separated from the data they protect, and that restores work. Each item below should be kept as a dated, versioned record, because the assessor decides whether the evidence is sufficient using the ASD evidence guide for enterprise IT.
Bucket Object Lock configuration exports
Export the Object Lock settings for every backup bucket, including whether Object Lock is enabled, the default retention mode and period, and any legal holds. Store each export as a file in Git so every change has an author, a date and a reason. Check that the exported state matches what the bucket reports at the time of the assessment, not only what the runbook says it should be.
IAM and policy definitions for account separation
Provide the user, role and bucket policy definitions that show backup administrators can manage retention and jobs without holding rights to delete or overwrite protected objects, and that ordinary and privileged administrators have no path to read their own backups. Keep these definitions versioned and review them against the separation the ISM controls describe. Ask the assessor which exports they want in which format before you build the set.
Access logs for backup buckets
Retain logs of every request made against the backup buckets, including denied requests, attempted deletions and changes to retention or policy. Logs only help if they are kept outside the backup administrator's control and for a period the assessor accepts. Confirm with your own environment which log sources RGW writes to and where they are forwarded, since logging options depend on your deployment.
Dated restore test records
Keep a dated record for each restore test that names the common point in time restored, the systems included, the person who ran the test, the elapsed time and any failures. Restoring to one common point in time is what the ISM expects for disaster recovery exercises, so records should show that all dependent systems were restored to the same point. Store reports with the date in the file name and keep the restored checksums alongside them.
Change records for retention settings
Record every change to a retention period, Object Lock mode, lifecycle rule or backup administrator account, with the requester, approver, reason and effective date. Tie each change to a ticket and to the Git commit that updated the exported configuration. Assessors look for changes that shorten protection during retention, so flag and explain any such change in the record itself.
How the controls change between ML1, ML2 and ML3
Maturity Level One is the entry point. In the ISM v2026.09.4 Essential Eight profiles, the ML1 baseline contains 46 ISM controls. Every one of them also appears in ML2 and ML3, so the ML1 work carries forward and should be built as the base layer rather than a throwaway first step. For backups, the team should confirm that a regular backup process exists, that backups are stored separately from the systems they protect, and that someone owns the restore process. On Ceph, this means deciding which pools, buckets and workloads are in scope, and confirming that the backup copies are not simply replicas of production data. Replication across OSDs protects against drive loss, but it does not protect against deletion or corruption that replicates along with the data.
- Scope the backup set: list every system whose data must be recoverable, and map each to a bucket, pool or image.
- Separate the copy: confirm backups are not mounted or writable from the production client path.
- Document ownership: name who runs backups, who restores them and who approves a restore.
- Confirm restore capability: check that a restore has been performed at least once, not only that backup jobs succeed.
At this level, check that the ML1 set is complete and that the team can explain it without referring to ML2 or ML3 requirements.
Maturity Level Two raises the count to 87 ISM controls in the same profile set. Because all ML1 controls are included, ML2 adds to the baseline rather than replacing it. For a backup repository, the additions are where immutability and privilege separation matter most. Backup administrator accounts must be prevented from modifying and deleting backups during their retention period (ISM-1708). Unprivileged accounts, and privileged accounts other than backup administrators, must not be able to access their own backups (ISM-1813, ISM-1706). On Ceph, this points to RGW Object Lock with a defined retention mode, a backup administrator identity that holds only the rights needed to write backups, and separate credentials for production administrators. The team should confirm these settings against the ISM text itself, since the Ceph configuration is an implementation choice rather than proof of compliance.
- Immutable retention: confirm Object Lock is enabled on the backup bucket and that the retention period matches the recovery policy.
- Backup administrator scope: check that this identity cannot change retention settings or delete locked versions.
- Account separation: verify that production administrators and general users have no path to backup buckets.
- Common point in time: confirm that restores can be taken to a single agreed point across linked systems.
Check that each ML2 control has a named owner and evidence, and that the Object Lock configuration is tested rather than assumed.
Maturity Level Three contains 123 ISM controls in the v2026.09.4 profile. Three ML2 controls, ISM-1691, ISM-1695 and ISM-1873, are replaced in ML3 by stricter versions. The replacement wording should be read directly in the ISM OSCAL catalog, because the backup team needs to know exactly which requirements tighten, not only that they change. Teams that have built to ML2 should review those three controls first, since they are the points where an existing design may fall short. ML3 also expects the restore process itself to be exercised in disaster recovery exercises, including restoration to a common point in time (ISM-1515). On Ceph, this means testing restores from the immutable copy, not just from snapshots or replicas, and documenting the recovery time and data loss actually observed.
- Replaced controls: compare ISM-1691, ISM-1695 and ISM-1873 at ML2 and ML3 in the ISM OSCAL catalog.
- Recovery exercises: schedule restore tests from the locked repository as part of disaster recovery exercises.
- Common point in time: check that multi-system restores can be aligned to one time point.
- Evidence trail: keep exercise results, retention settings and access reviews together.
Before relying on an ML3 position, confirm each replaced control with the ISM text and your assessor, since the mapping to Ceph features does not replace that reading.
The Ceph configuration in this topic supports several Essential Eight backup requirements, but it does not make any maturity level complete. Object Lock, a separate backup administrator identity, and documented restores address specific controls. Other controls depend on people, process and the wider environment, including backup scheduling, incident handling, monitoring of backup jobs and the assessment evidence the organization retains. Ceph also has its own platform risks, such as the consequences of compromised cluster administration, that sit outside backup controls. A team that treats the Ceph setup as the finished answer will likely have gaps at ML2 and ML3. The Essential Eight is a set of mitigations assessed for implementation and effectiveness, not a certificate, so the evidence has to show that the controls work in the organization's own environment.
- Platform limits: the Ceph settings cover storage behavior, not staff procedures or assessment outcomes.
- Control mapping: list which ISM controls each Ceph feature supports and which remain open.
- Admin access: confirm that cluster administration cannot bypass the backup account separation.
- Assessment evidence: use the ASD assessment evidence guide to plan what to collect.
Review this mapping with your assessor before claiming a maturity level, and record which parts of each level depend on processes outside Ceph.
Why account separation matters as much as Object Lock
Object Lock protects stored object versions during retention, but it does not protect the settings that govern them. A principal that can change bucket configuration, lock settings, bucket policy or lifecycle rules may be able to weaken or route around the control. For Essential Eight backups, the question is therefore less about whether Object Lock is enabled and more about which accounts can change the conditions under which it applies. Separate three roles: the backup writer, which can only put and read the backup objects it creates; the backup administrator, which owns retention and lock configuration; and the everyday administrator, who runs the Ceph cluster or the application estate and should have no path to delete or modify backups. Confirm in your own environment that these roles map to distinct RGW users or accounts with policies scoped to specific buckets, and that no one holds more than one of them.
ISM-1708 applies to backup administrator accounts specifically: they must be prevented from modifying and deleting backups during their retention period. Auditors will look for that prevention in the configuration, not in a policy document. Ask for evidence of the backup administrator's effective permissions, including any s3:PutBucketObjectLockConfiguration-style rights or equivalent Ceph capabilities, and check that the account cannot grant itself additional rights through IAM or STS features enabled on your gateway. Also record how the backup administrator credential is issued, stored and rotated, and who can approve its use. Shared credentials break this model, because a single key used by a script, an operator and a backup job makes it impossible to show which identity made a change. Each role needs its own identity, its own key and its own audit trail, and the audit trail should be exported somewhere the backup administrator cannot edit.
Avoid describing any combination of accounts, locks and retention settings as immutable in absolute terms. Cluster-level compromise, a compromised cluster administrator, or an error in a Ceph upgrade can all affect stored data, which is why separate, off-cluster copies and restore tests belong in the design. Treat the role model as a control that you test on a schedule: attempt the forbidden actions from each account, confirm they are denied, and retain the results. The exact permissions that Object Lock and your chosen Ceph release expose should be verified against the current Ceph Object Gateway documentation for your version before you write them into a control statement.
Questions buyers ask before hiring help with Essential Eight backups
How much effort does an immutable Ceph backup repository take to set up?
The effort depends mostly on how many backup sources feed the repository, how long each backup class must be retained, how identity is integrated, and how many sites are involved. A single cluster with a few backup sources and one identity provider is a much smaller piece of work than several sites with many sources, separate retention classes and integration with an existing directory. Each source needs its own bucket layout, Object Lock mode and retention rule, plus a client path that writes to it. Ask any provider to break the estimate down by these four drivers so you can see which ones move the number.
Can our internal team build Essential Eight backups on Ceph alone?
Often yes, if the team already runs Linux, networking and storage and can read the Ceph documentation carefully. The skills that usually need to be present are Ceph cluster operations with cephadm, RGW administration including Object Lock and bucket policy, identity administration for separate backup administrator accounts, and backup software configuration. The harder part is evidence: the team must show that backup administrators cannot change or delete protected copies during retention, that privileged users cannot read their own backups, and that restores are tested. An internal team should check whether it has time for those tests and for documenting them, not only for the build.
What does our organization need to provide for this work?
Expect to supply named backup owners who decide what must be protected and for how long, a retention schedule approved by the people accountable for the data, and administrative access to the cluster and identity systems during the build. You will also need test windows for restore exercises, since restoring to a common point in time must be tested, and a change process that records who can alter Object Lock settings. Without a retention decision, the repository cannot be configured correctly, so this is usually the first item to settle before any technical work starts.
How long does an Essential Eight backup project take?
The duration follows the same drivers as effort: the number of sources, the retention decisions still open, the state of identity integration, and how many sites must be covered. Projects with settled retention rules and a single site move faster than those that first need owners to agree on classes of data. Restore testing adds time because it needs scheduled windows and a repeatable procedure. Ask for the timeline as phases tied to written deliverables and approval points, and ask what happens if a retention decision changes midway.
Does running Ceph with Object Lock make us Essential Eight compliant?
No. The Essential Eight is a set of mitigation strategies, not a certification scheme, and there is no ASD certificate. Maturity is evidenced by assessing how each strategy is implemented and how effective it is against the maturity model. Ceph Object Gateway features can support the regular backups strategy, and the relevant controls in the Information Security Manual describe what backup administrators, privileged accounts and restore testing must meet. Your organization, and where needed an independent assessor, decides maturity. DeployOpen prepares systems, controls and evidence for that assessment but does not issue assessment reports or attestations.
Which controls and evidence should we expect the platform to produce?
Engineers should expect evidence for four areas: a backup administrator account separated from production and from the people who use the backups, Object Lock retention applied to backup buckets, access rules that stop privileged users from reading their own backup copies, and records of restore exercises that start from a common point in time. Each area should map to a control identifier in the Information Security Manual, such as ISM-1708 for protection of backups during retention, ISM-1813 and ISM-1706 for access to backups, and ISM-1515 for restore testing in disaster recovery exercises. Confirm each mapping with your assessor before relying on it.
What should a quote for this work include?
A useful quote states the scope in writing: the list of backup sources, the target Essential Eight maturity level you plan to evidence, the sites and clusters covered, and the identity systems to integrate. It should list each deliverable, such as the repository configuration, account separation design, retention runbook, restore test plan and test records, plus the acceptance criteria. Ask which items are one-time work and which recur, such as restore exercises, upgrades and support. DeployOpen typically agrees fixed scope and deliverables in writing before work starts, and does not publish a price list, so the quote follows from that written scope.
What breaks most often in immutable backup projects on Ceph?
The most common problems are unclear retention rules that get changed after configuration, backup administrator accounts that also hold production administrative rights, and Object Lock settings applied to some buckets but not others. Restore tests that only check that files can be read, without checking a consistent point in time across sources, also leave gaps. Ask the provider how it will verify each of these and how it will record the results so an assessor can follow them.
What Ceph and this configuration do not cover
Ceph can hold backups immutably for their retention period, but it does not make an organization Essential Eight compliant on its own. The cards below set out what sits outside this configuration, what the organization must own, and what to confirm before relying on it.
No certificate is issued
The Essential Eight is a set of mitigation strategies, not a certification scheme, and ASD issues no certificate for it. Maturity is shown through assessment of how each strategy is implemented and how well it works against the maturity model. Treat a working RGW Object Lock setup as one piece of evidence for the regular backups strategy, and plan the assessment evidence file around it. Confirm with your assessor which Maturity Level they will test against.
Other strategies stay out of scope
This page covers only the regular backups strategy. Patching applications and operating systems, multi-factor authentication, application control, macro restrictions and user application hardening are separate workstreams with their own evidence. A backup repository that is immutable but reachable through an unpatched, single-factor admin console still leaves gaps. Map each of the other seven strategies to an owner before the assessment begins.
Backup software is your choice
Ceph stores and locks the objects, but the backup tool decides what is copied, when jobs run, how catalogs are kept and how retention is written to each object. Confirm that your backup software can write to an S3 endpoint with Object Lock, that it sets retention on upload, and that its catalog survives loss of the repository. Choosing and operating that tool, and the catalog it keeps, remains the client's responsibility.
Restore tests must be run and recorded
ISM-1515 expects restoration to a common point in time to be tested in disaster recovery exercises. DeployOpen can design the test plan and help run the first exercise, but your team must perform, time and record each restore against its recovery targets. Without dated records showing which backups were restored, from which account and to what state, an assessor has nothing to test. Schedule restores on a regular cadence agreed with your risk owner.
Object Lock behavior depends on release
Object Lock semantics, the retention modes available and how lock interacts with versioning, lifecycle rules and multisite replication must be confirmed against the Ceph release you deploy. The supported releases today are Tentacle and Squid, and both receive backports and security fixes, but behavior for a given feature can differ between them. Test a locked bucket on your exact version, including deletion attempts by the backup administrator account, before go-live.
Effectiveness is judged separately
Configuring separate backup administrator accounts and retention locks is a design decision. Whether those controls are effective is a judgment the assessor makes from evidence, such as access logs, permission reviews, restore records and change history. Keeping an account split on paper does not prove that privileged staff cannot reach their own backups. Collect that evidence as routine operation rather than preparing it at assessment time.
Confirming the requirement wording for your assessment
Read the control wording for backup administrator accounts and restoration testing directly from the source, not from a summary or a paraphrase written for this page. The controls cited here, including ISM-1708 on preventing backup administrators from modifying or deleting backups during retention, ISM-1813 and ISM-1706 on access to backups, and ISM-1515 on restoration to a common point in time, are published in the Information Security Manual (ISM) in OSCAL form in the ISM OSCAL catalog. Pull the exact control statements from that catalog, record the ISM version your assessor uses, and map each Ceph configuration decision to the wording you have copied. A paraphrase that drifts from the control text is the most common reason an evidence set is rejected in review.
The current reference for the maturity levels is the Essential Eight Maturity Model (November 2023), published by ASD on cyber.gov.au. Confirm with your assessor that they are working from this release and not an older one, because the level requirements for regular backups are the ones your Ceph design must satisfy. Also confirm which ISM version and which Essential Eight baseline profile (ML1, ML2 or ML3) sets the target for your organization, since the ISM v2026.09.4 profiles differ in control count and in how ML3 replaces some ML2 controls.
The *Assessment evidence guide for enterprise IT* version 2026.10.15, published by ASD in OSCAL as the E4EIT OSCAL repository, has a mapping collection that references the Essential Eight dated 02 Oct 2024. Check whether your assessor expects evidence to be organized against that mapping, against the November 2023 model, or against both, and agree the naming of each evidence item before you collect it. Because the Essential Eight is a set of mitigations rather than a certification scheme, no ASD certificate will result from this work, and an independent assessor will decide the maturity level from the evidence you present.
How DeployOpen works on this
DeployOpen plans and builds the Ceph RGW backup repository inside your own infrastructure, with Object Lock retention and separate backup administrator accounts designed together. The work ends with restore tests against your recovery objectives and documentation your assessor can follow.
How we scope
- The written scope names which systems back up to Ceph, which data classes are in retention, and which Essential Eight maturity level you are targeting.
- We map each backup, administrator and restore control to the relevant ISM control IDs so the scope states exactly what must be evidenced.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. Ongoing support is available as a retainer.
How we build
- We configure RGW buckets with Object Lock retention and separate backup writer, administrator and read-only identities so no single account can alter or delete retained backups.
- We keep unprivileged and non-backup administrator accounts out of backup buckets, and test that access is denied, not only that it is configured.
- We run restore tests to a common point in time across dependent systems, and record measured recovery times against the targets you set.
How we hand over
- You receive configuration records, the account and role model, retention settings and the control-to-evidence mapping for your assessor.
- Restore test runbooks and results are delivered with the steps, data sets used, and any gaps found and how each was closed.
- Your operators are trained on checking Object Lock status, rotating backup credentials, and running a restore exercise without DeployOpen involved.
How we support
- A retainer can cover Ceph and RGW upgrades, including checks that Object Lock and account policies still behave as tested after each change.
- Scheduled restore exercises can be repeated on a planned cadence so evidence stays current for each assessment cycle.
- Assessment support prepares systems, controls and evidence for your independent assessor. DeployOpen does not issue audit reports or certifications.
