Skip to content

SYSTEM Cited by 1 source

AWS Multi-party approval (MPA)

Definition

AWS Multi-party approval (MPA) is an AWS service primitive that requires a predefined set of approvers — configured via IAM Identity Center — to authorise specific actions before they proceed. In cyber-resilience designs, MPA is configured on AWS Backup logically air-gapped vaults to gate restore authorization.

Verbatim from the canonicalising source:

"Configure Multi-party approval for restore. MPA, configured through IAM Identity Center, requires a predefined set of approvers before a restore proceeds. This is particularly valuable when the source account might no longer be trusted." (Source: sources/2026-05-20-aws-cyber-resilience-on-aws-a-reference-approach-for-recovery-from-ransomware-and-destructive-events)

Why a separate service primitive

MPA could in principle be implemented with IAM policies + manual review, but having it as a dedicated service provides:

  • Pre-defined approver lists that survive credential compromise.
  • Approval workflow plumbing — request submission, approver notification, approval recording.
  • Audit trail integration — approvals are recorded as CloudTrail management events.
  • Identity-Center integration — approvers authenticate via the organisation's federated identity provider, not via account-local IAM users.

Architectural property: pre-defined approvers

The load-bearing MPA property is that approvers are predefined before any incident — not selected at incident time. This is why "the source account might no longer be trusted" matters:

  • An attacker with source-account credentials cannot add themselves to the approver list because the approver list lives in a different identity surface (IAM Identity Center, typically backed by an external IdP).
  • An attacker cannot approve their own restore because they're not on the approver list.

The approver list is configured at the same time as the vault, under whatever security review the design's IAM Identity Center posture requires.

CloudTrail audit trail

"The approval action is automatically recorded as an AWS CloudTrail management event."

This means every MPA approval has an immutable audit record:

  • Who approved (approver identity).
  • When (timestamp).
  • What (the specific action authorised).
  • From where (source IP, user agent).

This audit trail survives the recovery and provides:

  • Post-incident review evidence.
  • Compliance / regulatory reporting evidence.
  • Drift detection (if approval patterns change suddenly, that's a signal).

Use cases beyond restore authorization

While the canonicalising source focuses on restore authorization, MPA generalises to any high-stakes action where:

  1. The action is structurally consequential (cannot be easily undone).
  2. The actor's identity may be compromised (source account credentials are not trusted).
  3. Multiple approvers can act independently to gate the action.

Plausible extensions include vault deletion (after retention expires), MPA configuration changes, and SCP modifications affecting the Recovery Account.

Relationship to existing IAM controls

MPA is additive to standard IAM:

  • IAM still controls who can initiate a restore (typically a scoped role in the Recovery Account or IRE).
  • MPA gates whether that initiated restore proceeds.

A user with the IAM permissions to initiate a restore cannot complete it without MPA approval; an MPA approver cannot initiate a restore without an IAM-permitted initiator. The two layers compose.

Configuration via IAM Identity Center

"MPA, configured through IAM Identity Center, requires a predefined set of approvers."

IAM Identity Center (formerly AWS SSO) is the substrate for approver identity:

  • Approvers authenticate via the organisation's IdP.
  • Approver group membership is managed in the IdP, not in account- local IAM.
  • Approval requests can be routed to approver email / Slack / etc. via Identity Center's notification integrations.

This means MPA approver compromise requires IdP compromise — not just AWS account compromise — providing the trust isolation MPA relies on.

Operational considerations

Approver pool design

The canonicalising source doesn't prescribe approver pool size, but practical considerations:

  • Geographic / timezone diversity for reachability during incident time.
  • Independent identities (not a single team).
  • Multiple approvers required per action (if MPA supports m-of-n configurations).
  • Incident-response training so approvers can evaluate the validation evidence presented.

Pre-approval rationale documentation

"Document the rationale for recovery point selection: investigation findings, validation results, and the basis for the decision, in your incident management process."

CloudTrail captures the approval action itself, but the rationale (why this candidate, not an earlier or later one) lives in the incident-management system (e.g. Jira, ServiceNow). Both are needed: CloudTrail for tamper-evidence, incident-management for context.

Coverage

MPA is currently AWS-Backup-vault-focused (per the canonicalising source's framing). The pattern itself (MPA-gated restore authorization) generalises beyond AWS — see that page for cross- provider equivalents (GCP Approval Workflows, Azure PIM with approval workflows, on-prem two-person integrity controls).

Seen in

Last updated · 542 distilled / 1,571 read