aws-backup-vault-policy-self-grant

backup:PutBackupVaultAccessPolicy allows rewriting a backup vault's access policy, enabling an attacker to grant itself or an external account data-access permissions (StartRestoreJob, StartCopyJob).

derived aws emits CanModifyPolicy

match

A conjunctive graph pattern. Variables (?x) bind node ids; every clause must hold.

{'principal': None} HasPermission {'vault': None}

where

node_type(?vault) == Backup ?vault.provider_type == 'AWS::Backup::BackupVault' ?principal has EFFECTIVE backup:PutBackupVaultAccessPolicy on ?vault ARN

emit

source typeIdentity
target typePolicy
source?principal
target<vault access policy (ResourcePolicy) node>
permissionsbackup:PutBackupVaultAccessPolicy
conditionsiam_permission scp_or_org_policy
state logicACTIVE when backup:PutBackupVaultAccessPolicy is confirmed EFFECTIVE on ?vault (identity policy + no SCP deny). CONDITIONAL(scp_or_org_policy) when an SCP may restrict backup:PutBackupVaultAccessPolicy. BLOCKED when: an SCP or vault policy explicitly denies backup:PutBackupVaultAccessPolicy for the principal; OR ?vault is a Logically Air-Gapped (LAG) vault (policy modification blocked by design).

Narrative

{principal.name} can rewrite the access policy of backup vault {vault.name} (backup:PutBackupVaultAccessPolicy), potentially granting itself or an external account full access to all recovery points in the vault.

Raw rule rules/derived/aws/backup.yaml

id: aws-backup-vault-policy-self-grant
emits: CanModifyPolicy
description: backup:PutBackupVaultAccessPolicy allows rewriting a backup vault's access policy, enabling
  an attacker to grant itself or an external account data-access permissions (StartRestoreJob, StartCopyJob).
match:
- - principal: null
  - HasPermission
  - vault: null
where:
- node_type(?vault) == Backup
- ?vault.provider_type == 'AWS::Backup::BackupVault'
- ?principal has EFFECTIVE backup:PutBackupVaultAccessPolicy on ?vault ARN
emit:
  source_type: Identity
  target_type: Policy
  source: ?principal
  target: <vault access policy (ResourcePolicy) node>
  permissions:
  - backup:PutBackupVaultAccessPolicy
  conditions:
  - iam_permission
  - scp_or_org_policy
  state_logic: 'ACTIVE when backup:PutBackupVaultAccessPolicy is confirmed EFFECTIVE on ?vault (identity
    policy + no SCP deny). CONDITIONAL(scp_or_org_policy) when an SCP may restrict backup:PutBackupVaultAccessPolicy.
    BLOCKED when: an SCP or vault policy explicitly denies backup:PutBackupVaultAccessPolicy for the principal;
    OR ?vault is a Logically Air-Gapped (LAG) vault (policy modification blocked by design).'
  confidence: min(contributing_confidences) * 0.95
  derived_from:
  - ?principal HasPermission ?vault (backup:PutBackupVaultAccessPolicy effective permission)
  - cited by aws-backup-put-vault-access-policy explicit edge
  false_positive_note: "backup:PutBackupVaultAccessPolicy is sufficient to rewrite vault policy and grant\
    \ broader access. No additional resource-policy gate applies (the policy itself is the target of modification).\
    \ LAG vaults block this by design. Vault Lock in compliance mode (after cool-off) does NOT block PutBackupVaultAccessPolicy\
    \ (it blocks DELETE), so policy modifications remain possible \u2014 emit ACTIVE. The policy-add action\
    \ can broaden access; the lock prevents reversal."
  narrative: '{principal.name} can rewrite the access policy of backup vault {vault.name} (backup:PutBackupVaultAccessPolicy),
    potentially granting itself or an external account full access to all recovery points in the vault.'
move · open · esc close