View source for Guides:Multi-Admin Approval for Destructive Storage Operations

''By Steve Umbehocker, CTO, OSNexus &middot; Updated October 3, 2026''

Multi-admin approval is a two-person rule for data-destructive operations: when it is enabled, a delete of a protected object type is held as a pending request until a set number of administrators approve it. QuantaStor applies it grid-wide from the Security Manager, covering deletes of storage volumes, network shares, buckets, scale-up and scale-out pools, object storage classes and Ceph clusters. Approvers work from the Multi-admin Approval toolbar in the web interface, and held deletes issued from the CLI report how many approvals they have so far.

== Why it matters ==

Most storage-side ransomware and insider attacks end with the same step: someone with valid administrator credentials deletes the pools, volumes or buckets that hold the data, and with them the snapshots that would have allowed recovery. Password policy and [[Multi-Factor Authentication Manager|multi-factor authentication]] make it harder to steal those credentials, but once an attacker holds them, a single account can still destroy everything.

Multi-admin approval removes that single point of failure. A stolen or misused account can request a delete, but the delete does not start until other administrators agree. The same control catches honest mistakes, such as a pool deleted on the wrong system or a share removed during the wrong change window.

For regulated environments, it fits alongside the controls described in [[Security Configuration]]: password and lockout policy with a '''Suggested Defaults''' preset aimed at standards such as HIPAA, CJIS and NIST 800-53 / 800-171, role based access control over every management operation, LDAP single sign-on for administrators, and always-on [[Audit Logging|audit logging]] of every management operation, login attempt and authorization decision. Agencies and contractors that need separation of duties for destructive actions can enforce it on the storage itself instead of relying on a change-control process alone.

== How it works ==

The workflow has three parts: a policy, a pending request and the approval votes.

# '''Policy.''' In '''Security Manager''', the '''Multi-admin Approvals''' tab turns the feature on, sets the minimum number of approvals and the expiry time, and selects which delete operations require approval. The policy applies to the whole storage grid.
# '''Pending request.''' When an administrator deletes an object whose type is selected, QuantaStor records a pending multi-admin approval request instead of starting the delete task. The request carries the object name, type and ID, its status, the required and current approval counts, the request originator and an expiry time.
# '''Approval votes.''' Other administrators open '''Security → Multi-admin Approval → Approve''', which "casts an approval vote for the associated data-destructive operation", or '''Reject''' to refuse it. Once the current count reaches the required count, the delete proceeds. If the request is not approved before it expires, the delete does not run.

From the CLI, a held delete reports its approval status, for example <code><nowiki>1 of 3 approvals met</nowiki></code>, rather than returning an empty task, so a script or operator can see exactly why the delete has not started.

[[File:Guide-multi-admin-approval-multi-admin-approval-security-manager.png|frame|center|The Multi-admin Approvals tab of Security Manager: the Enable checkbox, Minimum Approvals and Hours Until Auto-expiration, and the list of delete operations that can require approval]]

=== Operations that can require approval ===

{| class="wikitable"
! Required approval type !! Reference
|-
| Storage Volume : Delete || [[Storage Volume Delete]]
|-
| Network Share : Delete || [[Network Share Delete]]
|-
| Bucket : Delete || [[Object Bucket Delete]]
|-
| Scale-up Storage Pool : Delete || [[Storage Pools]]
|-
| Scale-out Block Pool : Delete || [[Storage Pools]]
|-
| Scale-out File Pool : Delete || [[Storage Pools]]
|-
| Scale-out Object Pool : Delete || [[Storage Pools]]
|-
| Object Storage Class : Delete || 
|-
| Ceph Cluster : Delete || 
|}

Each type is a separate checkbox, and '''Select All''' and '''Clear All''' set them in one step.

== Design and sizing ==

Three settings define the policy. Choose them with your team size and on-call coverage in mind.

{| class="wikitable"
! Setting !! What it controls !! Guidance
|-
| Minimum Approvals || Approvals a pending delete needs before it runs (2 by default in the dialog) || 2 suits most teams. Use a higher number only if that many administrators can realistically be reached during a change window.
|-
| Hours Until Auto-expiration || How long a request waits for approval (48 hours by default in the dialog) || Long enough to span a weekend change window, short enough that stale requests don't linger. A value of 0 means requests never expire.
|-
| Required Approval Types || Which delete operations are held || Select all pool, cluster and bucket types at a minimum, because those deletes remove the most data in one step.
|}

Some practical points:

* '''Give every administrator a named account.''' Approval only means something if each vote comes from a different person. Shared logins such as a single <code><nowiki>admin</nowiki></code> account defeat the purpose. Map named accounts to roles, or use LDAP single sign-on so administrator groups are managed in your directory.
* '''Decide who may approve.''' Approving and rejecting are ordinary RBAC permissions on the <code><nowiki>PendingOperationRequest</nowiki></code> object type (<code><nowiki>view</nowiki></code>, <code><nowiki>create</nowiki></code>, <code><nowiki>approve</nowiki></code>, <code><nowiki>reject</nowiki></code>, <code><nowiki>clear</nowiki></code>). Grant <code><nowiki>approve</nowiki></code> and <code><nowiki>reject</nowiki></code> to the roles that should vote, and leave them off roles such as System Monitor.
* '''Protect the approvers.''' Turn on multi-factor authentication for every account that holds the approve permission, so a single stolen password cannot both request and approve.
* '''Keep snapshots in the plan.''' Approval stops a malicious delete, but it does nothing against data that is encrypted or overwritten in place. Pair it with [[Snapshot Schedules|snapshot schedules]] so there is a clean recovery point when data inside a volume or share is damaged.

[[File:Guide-multi-admin-approval-multi-admin-approval-role-permissions.png|frame|center|Update Role Permissions filtered to the PendingOperationRequest operations, where approve and reject rights are granted to a role. The Administrator role already has this permission but you can create new roles that are limited to a subset of operations including PendingOperationRequest approval and rejection.]]

== Setting it up ==

# Create a named account for each administrator and assign roles under '''Security → Management Users''' and '''Management Roles'''. In '''Add/Remove Permissions''' for each approving role, confirm <code><nowiki>PendingOperationRequest</nowiki></code> <code><nowiki>approve</nowiki></code> and <code><nowiki>reject</nowiki></code> are granted at the scope you need.
# Enable multi-factor authentication for those accounts from '''Multi-Factor Auth Manager'''.
# Open '''Security → Management Users → Security Manager''' (toolbar) and select the '''Multi-admin Approvals''' tab.
# Tick '''Enable Multi-admin Approvals'''.
# Set '''Minimum Approvals''' and '''Hours Until Auto-expiration'''.
# Under '''Required Approval Types''', tick the delete operations to protect, or use '''Select All'''.
# Click '''OK'''. Changes made only on this tab save without the logout and password-expiry confirmation that password-policy changes trigger, so you can enable the feature during working hours.

To roll it out without blocking routine work, start with the operations that destroy the most data at once (pools, Ceph clusters, object storage classes and buckets), run with them for a few weeks, then add volume and share deletes once the team is used to the approval step. Volume and share cleanup is more frequent, so plan who covers approvals before you protect those types.

== Operating and testing ==

Test the policy before relying on it. On a non-production object, for example a scratch volume <code><nowiki>vol-test1</nowiki></code> in <code><nowiki>pool1</nowiki></code>:

# As one administrator, delete <code><nowiki>vol-test1</nowiki></code>. The delete should not start. From the CLI, the response shows the approval status, such as <code><nowiki>1 of 2 approvals met</nowiki></code>.
# As a second administrator, open '''Security → Multi-admin Approval → Approve'''. The '''Pending Multi-admin Approval Requests''' list shows the object name, object type, required and current counts, the originator and the expiry time.
# Select the request and approve it. When the required count is reached, the delete task runs and appears in the Tasks pane.
# Repeat with a second scratch object and use '''Reject''' to confirm a refused delete never runs.

If nothing is waiting, the Approve dialog reports that there are no pending operation requests to approve.

Day to day, treat an unexpected pending request as a security event: check who originated it, and reject it if it isn't tied to an approved change. Every request, approval and delete is recorded by [[Audit Logging|audit logging]], which gives you the trail auditors ask for. For scripted cleanup jobs, check the CLI approval status so the job reports a held delete instead of treating it as a failure. Command syntax is in the [[QuantaStor CLI Command Reference]].

== FAQ ==

=== Which operations does multi-admin approval cover? ===

It covers deletes: storage volumes, network shares, buckets, scale-up storage pools, scale-out block, file and object pools, object storage classes and Ceph clusters. You choose which of these require approval on the Multi-admin Approvals tab of Security Manager. Other management operations are governed by role based access control as usual.

=== Does multi-admin approval protect against ransomware? ===

It protects against the destructive step attackers use once they hold administrator credentials: deleting pools, volumes or buckets so there is nothing left to recover from. It does not stop data from being encrypted inside a volume or share, so combine it with snapshot schedules, replication schedules, multi-factor authentication and audit logging.

=== What happens if nobody approves a request? ===

The delete never runs. The request expires after the configured '''Hours Until Auto-expiration''', and the object stays in place. Setting the expiry to 0 keeps requests open until they are approved or rejected.

=== Is multi-admin approval suitable for government and regulated deployments? ===

It enforces separation of duties for data destruction on the storage system itself, which supports audit and access-control requirements in frameworks such as NIST 800-53 and 800-171. It works alongside QuantaStor's password and lockout policy presets, RBAC, multi-factor authentication, LDAP single sign-on and always-on audit logging, all described in Security Configuration.

=== Can an administrator approve their own delete? ===

Treat approval as needing different people: give each administrator a named account, grant the approve permission only to roles that should vote, and protect those accounts with multi-factor authentication. Check the Request Originator column before approving a request.

----
''Part of the [[Guides:Index|QuantaStor Guides]] series. For reference documentation, see the [[Main Page|QuantaStor documentation]].''

[[Category:Guides]]
<!-- osn-seo-utilities: ../review/articles/wiki-multi-admin-approval.md @ d95f434838dc -->