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.).

derived aws emits CanReadData

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:StartRestoreJob on ?vault ARN (or on recovery points within it)

emit

source typeIdentity
target typeStorage
source?principal
target?vault
permissionsbackup:StartRestoreJob
conditionsiam_permission resource_policy key_permission scp_or_org_policy service_state
state logicCONDITIONAL(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."
move · open · esc close