aws-backup-restore-read-data
backup:StartRestoreJob provisions a new resource from a backup recovery point; the restored resource can be accessed if the principal also has target-service read permissions (RDS login, EC2 key pair, EFS mount, etc.).
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:StartRestoreJob on ?vault ARN (or on recovery points within it)
emit
| source type | Identity |
|---|---|
| target type | Storage |
| source | ?principal |
| target | ?vault |
| permissions | backup:StartRestoreJob |
| conditions | iam_permission resource_policy key_permission scp_or_org_policy service_state |
| state logic | CONDITIONAL(iam_permission) when backup:StartRestoreJob is EFFECTIVE but the restored resource's target-service access (e.g., rds:DescribeDBInstances for RDS, EC2 key pair access for EC2, EFS mount permissions, dynamodb:Scan for DynamoDB) has not been confirmed. The restore capability alone is NOT data-plane read without target-service access. ACTIVE ONLY when BOTH (1) backup:StartRestoreJob is EFFECTIVE AND (2) the principal has confirmed access to the target service for the resource type being restored. This requires collection-time integration with target-service rules. Conservatively, emit CONDITIONAL(iam_permission) pending target-service access confirmation. CONDITIONAL(key_permission) when recovery points in ?vault are encrypted with a CMK and the restoring principal / Backup service role lacks confirmed kms:Decrypt on that key — the restore will fail. Cite credential-chains decrypt-gates-secret-read for resolution when the decrypt is subsequently confirmed. CONDITIONAL(resource_policy) when the vault has an access policy that may restrict backup:StartRestoreJob but hasn't been evaluated. CONDITIONAL(scp_or_org_policy) when an SCP may restrict cross-account restore. BLOCKED when: an SCP or vault access policy explicitly denies backup:StartRestoreJob for the principal; OR the vault is empty; OR Vault Lock retention period prevents access (Vault Lock does not block restore, only delete — this is typically CONDITIONAL for restore pending key_permission and target-service confirmation). |
Narrative
{principal.name} can restore a recovery point from vault {vault.name} (backup:StartRestoreJob), provisioning a new {resourceType} resource with complete point-in-time data - PROVIDED the principal also has {resourceType}-specific access permissions (database login, EC2 key pair, EFS mount, etc.) to read from the restored resource.
Raw rule rules/derived/aws/backup.yaml
id: aws-backup-restore-read-data
emits: CanReadData
description: backup:StartRestoreJob provisions a new resource from a backup recovery point; the restored
resource can be accessed if the principal also has target-service read permissions (RDS login, EC2 key
pair, EFS mount, etc.).
match:
- - principal: null
- HasPermission
- vault: null
where:
- node_type(?vault) == Backup
- ?vault.provider_type == 'AWS::Backup::BackupVault'
- ?principal has EFFECTIVE backup:StartRestoreJob on ?vault ARN (or on recovery points within it)
emit:
source_type: Identity
target_type: Storage
source: ?principal
target: ?vault
permissions:
- backup:StartRestoreJob
conditions:
- iam_permission
- resource_policy
- key_permission
- scp_or_org_policy
- service_state
state_logic: "CONDITIONAL(iam_permission) when backup:StartRestoreJob is EFFECTIVE but the restored\
\ resource's target-service access (e.g., rds:DescribeDBInstances for RDS, EC2 key pair access for\
\ EC2, EFS mount permissions, dynamodb:Scan for DynamoDB) has not been confirmed. The restore capability\
\ alone is NOT data-plane read without target-service access. ACTIVE ONLY when BOTH (1) backup:StartRestoreJob\
\ is EFFECTIVE AND (2) the principal has confirmed access to the target service for the resource type\
\ being restored. This requires collection-time integration with target-service rules. Conservatively,\
\ emit CONDITIONAL(iam_permission) pending target-service access confirmation. CONDITIONAL(key_permission)\
\ when recovery points in ?vault are encrypted with a CMK and the restoring principal / Backup service\
\ role lacks confirmed kms:Decrypt on that key \u2014 the restore will fail. Cite credential-chains\
\ decrypt-gates-secret-read for resolution when the decrypt is subsequently confirmed. CONDITIONAL(resource_policy)\
\ when the vault has an access policy that may restrict backup:StartRestoreJob but hasn't been evaluated.\
\ CONDITIONAL(scp_or_org_policy) when an SCP may restrict cross-account restore. BLOCKED when: an\
\ SCP or vault access policy explicitly denies backup:StartRestoreJob for the principal; OR the vault\
\ is empty; OR Vault Lock retention period prevents access (Vault Lock does not block restore, only\
\ delete \u2014 this is typically CONDITIONAL for restore pending key_permission and target-service\
\ confirmation)."
confidence: min(contributing_confidences) * 0.65
derived_from:
- ?principal HasPermission ?vault (backup:StartRestoreJob effective permission)
- ListRecoveryPointsByBackupVault confirms non-empty vault
- target-service access TBD by integration with rds/ec2/efs/dynamodb rules
false_positive_note: "backup:StartRestoreJob is NECESSARY but NOT SUFFICIENT to read data. The restored\
\ resource (RDS DB instance, EC2 instance, EFS filesystem, DynamoDB table) must also be accessible\
\ to the principal via target-service permissions:\n - RDS: rds:DescribeDBInstances + database authentication\
\ (master password or IAM auth)\n - EC2: ec2:DescribeInstances + EC2 key pair in account or SSM Session\
\ Manager access\n - EFS: ec2:DescribeFileSystems + mount capabilities + mount permissions in Linux/Windows\n\
\ - DynamoDB: dynamodb:Scan / dynamodb:Query + table access + credentials to make calls\nThis rule\
\ conservatively emits CONDITIONAL(iam_permission) until target-service access is confirmed. Do NOT\
\ set ACTIVE without evidence of target-service access.\nCMK-encrypted recovery points: the Backup\
\ service role (passed via iam:PassRole at restore time) must be granted kms:Decrypt on the wrapping\
\ key \u2014 without it the restore job fails before any data is accessible. Emit CONDITIONAL(key_permission)\
\ until confirmed.\nIf the vault is access-policy-restricted and the policy hasn't been evaluated,\
\ downgrade to CONDITIONAL(resource_policy).\nLatency: restore jobs may take minutes to hours for\
\ large resources; the restored resource is eventually available, but the data-read path is not instantaneous."
narrative: "{principal.name} can restore a recovery point from vault {vault.name} (backup:StartRestoreJob),\
\ provisioning a new {resourceType} resource with complete point-in-time data \u2014 PROVIDED the\
\ principal also has {resourceType}-specific access permissions (database login, EC2 key pair, EFS\
\ mount, etc.) to read from the restored resource."