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).
match
A conjunctive graph pattern. Variables (?x) bind node ids; every clause must hold.
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). |
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.'