Skip to content

PATTERN Cited by 1 source

MPA-gated restore authorization

Pattern

Require multi-party approval (MPA) as a hard gate before any restore proceeds from a logically air-gapped vault. The pattern uses a predefined set of approvers (configured via IAM Identity Center) — none of whom can act unilaterally — to ensure that even a compromised source account cannot trigger a restore that overwrites or copies sensitive data into an attacker-controlled environment.

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)

When the gate fires

The MPA gate is Stage 3 of the parallel recovery stages workflow:

Stage 1 (timeline)  ─┐
Stage 2 (validate)   ├──► Stage 3 (MPA approval) ──► Stage 4 (rebuild + restore) ──► Stage 5 (cutover)
Stage 4 rebuild leg ─┘

The gate synchronises three parallel streams (timeline + validation + rebuild) before allowing data restore to proceed.

Why MPA, specifically

The cyber-resilience scenario where MPA is load-bearing:

  • The source account is no longer trusted. Even if someone-with-credentials in the source account "approves" a restore, that approval cannot be the only authorisation — because the credential may be the attacker's.
  • A predefined set of approvers (configured before the event, in IAM Identity Center) means the approver list cannot be modified by an attacker who only has source-account credentials — the approvers live in a different identity surface (IAM Identity Center, typically backed by an external IdP).
  • Multiple approvers required means a single compromised approver isn't sufficient — adversary has to compromise multiple identities to authorise a malicious restore.

What the approver decides

The MPA approver authorises a specific restore with documented rationale. The canonicalising source's Stage 3 description:

"Approve only recovery points that pass all validation checks. If the vault is configured with Multi-party approval, the predefined approvers authorize the restore, and the approval action is automatically recorded as an AWS CloudTrail management event. Document the rationale for recovery point selection: investigation findings, validation results, and the basis for the decision, in your incident management process."

The approver's input:

  • Investigation findings — what does the timeline say about the earliest indicator?
  • Validation results — which layers passed/failed for this candidate?
  • Decision basis — why this candidate, why not an earlier one?

Audit trail: CloudTrail management event

A load-bearing property: "the approval action is automatically recorded as an AWS CloudTrail management event."

This means the approval is an immutable audit record that survives the recovery — useful for:

  • Post-incident review — who approved what, when, with what rationale.
  • Compliance reporting — regulators / auditors can trace the approval chain.
  • Future drills — historical approval patterns inform approver selection and training.

Pre-configuration: approvers ready before incident

The pattern requires approvers be predefined — meaning they're configured before an incident happens. This is consequential:

  • At incident time, defining approvers would itself be an IAM configuration change subject to compromise; if the attacker can define the approvers, they can authorise their own restore.
  • Pre-configuration fixes the approver list as part of the recovery design, not an emergency decision.

The canonicalising source's checklist explicitly says "Create a logically air-gapped vault in a dedicated Recovery Account, and configure Multi-party approval for restore operations" as starting-point step 1.

Approver selection considerations

The post doesn't prescribe specific approver selection criteria, but practical considerations follow from the pattern:

  • Geographic / timezone diversity so approvers are reachable during incident time across regions.
  • Independent identities (not a single team) so a compromised team's IdP doesn't compromise the approver list.
  • Incident-response training so approvers know how to evaluate the rationale they're presented.
  • Multiple approvers required so one compromised identity isn't sufficient.

When to use this pattern

Use this pattern when:

  • Recovery actions could plausibly be triggered by a compromised source account.
  • Backup data is sensitive enough that unauthorised restore is itself a security event (regulated data, customer PII, secrets).
  • The team can sustain pre-configured MPA approvers (training, on- call rotation).

Weaker fit when:

  • Recovery RTO is in single-digit minutes (the MPA gate adds human latency that may dominate RTO).
  • Backups are non-sensitive and the cost of unauthorised restore is low.
  • The team is too small to have multiple approvers (in which case the pattern degrades to single-approver, which is just standard IAM authorisation).

Composition with other patterns

Failure modes

  1. Approver unreachable during incident. Stage 3 stalls; recovery MTTR balloons. Mitigation: multiple approvers across geos, documented escalation.
  2. Insufficient information for approval decision. Approvers can't evaluate validation results (e.g. validation pipeline output is too noisy). Mitigation: structured decision template; train approvers; ensure validation pipeline output is action- able.
  3. Approver social-engineered. A compromised attacker convinces an approver that their malicious restore is legitimate. Mitigation: out-of-band verification of incident context; multi-approver requirement so single social-engineering attempt isn't sufficient.
  4. MPA configuration drift. Changes to approver list aren't noticed; an outdated approver still has authority. Mitigation: AWS Config / Audit Manager rules to detect MPA approver-list changes; periodic recertification.
  5. MPA bypass via emergency procedure. If the design has an emergency "break-glass" path that bypasses MPA, that path becomes the attack surface. Mitigation: no break-glass that bypasses MPA for backup vault; if break-glass is necessary, it has its own multi-party approval.

Generalisation beyond AWS

The MPA pattern is substrate-agnostic — applicable to any authorization decision where:

  1. The action is high-stakes (restore, deletion, configuration change).
  2. The source identity may be compromised so single-party authorisation isn't sufficient.
  3. Multiple identities can act independently to gate the action.

GCP equivalents include Approval Workflows; Azure has Privileged Identity Management with approval workflows; on-prem systems implement two-person integrity controls (TPI) for high-stakes actions. The structural property is multi-party authorisation as a structural requirement, not an option.

Seen in

Last updated · 542 distilled / 1,571 read