Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

逻辑上受物理隔离的保管库

逻辑上受物理隔离的保管库概述

Amazon Backup 提供一种辅助类型的保管库，可以将备份存储在具有其他安全功能的容器中。逻辑上受物理隔离的保管库是一种专门的保管库，除了标准备份保管库的功能外，它还提供增强的安全功能，并且能够与其他账户共享保管库访问权限，以便在发生需要快速恢复资源的事件时可以更快、更灵活地设置恢复时间目标（RTO）。

逻辑上的气隙保管库配备了额外的保护功能；每个保管库都使用Amazon 自有密钥（默认）或可选使用客户管理的 KMS 密钥进行加密，并且每个保管库都配备Amazon Backup 了 Vault Lock 的合规模式。加密密钥类型信息可通过 Amazon Backup API 和控制台查看，以实现透明度和合规性报告。

您可以将逻辑上隔离的保管库与Multi-party 批准 (MPA) 集成，这样即使无法访问保管库拥有的账户，也能恢复保管库中的备份，这有助于保持业务连续性。此外，您可以选择与 Amazon Resource Access Manager (RAM) 集成，与其他 Amazon 账户（包括其他组织的账户）共享逻辑隔离保管库，这样，如果需要进行数据丢失恢复或还原测试，可以从共享保管库的账户恢复保管库中存储的备份。作为增强安全性的一部分，逻辑上气隙隔离的保管库将其备份存储在 Amazon Backup 服务拥有的帐户中（这会导致备份在日志中的修改属性项中显示为在组织外部共享）。 Amazon CloudTrail

在您的逻辑上处于隔离状态的保管库所属账户被关闭（恶意或以其他方式）的情况下，您仍然可以通过 MPA 访问保管库中的备份（还原或复制它们），直到关闭后期结束为止。https://docs.amazonaws.cn/accounts/latest/reference/manage-acct-closing.html#post-closure-period关闭后期限到期后，将无法再访问备份。在关闭后期间，您可以参考Amazon 账户管理文档，在进行恢复的同时重新获得对账户的控制权。

为了提高灵活性，我们建议在相同或不同账户的逻辑气隙保管库中创建跨区域副本。但是，如果您想通过仅保留单个副本来降低存储成本，则可以在加入 MPA 后使用主备份对逻辑上隔绝的保管库进行备份。 Amazon

您可以在 Amazon Backup 定价页面上查看逻辑上受物理隔离的保管库中受支持服务的备份的存储定价。

有关您可以复制到逻辑上受物理隔离的保管库的资源类型，请参阅按资源划分的功能可用性。

逻辑上受物理隔离的保管库的用例

逻辑上受物理隔离的保管库是作为数据保护策略一部分的辅助保管库。当您希望为备份使用符合以下条件的保管库时，此保管库可以帮助增强组织的保留策略和恢复能力

注意事项和限制

与标准备份保管库进行比较和对比

备份保管库是 Amazon Backup中使用的主要和标准类型的保管库。创建备份时，每个备份都存储在备份保管库中。您可以分配基于资源的策略来管理存储在保管库中的备份，例如存储在保管库中的备份的生命周期。

逻辑气隙保管库是一种专门的保管库，具有更高的安全性和灵活共享功能，可缩短恢复时间 (RTO)。该保管库存储最初创建并存储在标准备份保管库中的主备份或备份副本。

备份保管库使用密钥进行加密，这是一种限制目标用户访问权限的安全机制。这些密钥可以由客户管理或 Amazon 管理。有关复制作业期间的加密行为（包括复制到逻辑上受物理隔离的保管库），请参阅复制加密。

此外，借助保管库锁定功能，可以更安全地保护备份保管库；逻辑上受物理隔离的保管库配备了合规模式下的保管库锁定功能。

与备份文件库类似，逻辑气隙保管库也支持 Amazon EC2 备份的受限标签。

创建逻辑上受物理隔离的保管库

您可以通过 Amazon Backup 控制台或通过和 CLI 命令的组合来创建逻辑上气隙隔离的 Amazon Backup 保 Amazon RAM 管库。

在合规模式下，每个逻辑上受物理隔离的保管库都配有保管库锁定功能。请参阅Amazon Backup 保管库锁定，以帮助确定适合运营的保留期值

Console

从控制台创建逻辑气隙保管库

1. 在处打开 Amazon Backup 控制台https://console.aws.amazon.com/backup。

2. 在导航窗格中，选择保管库。

3. 将显示两种类型的保管库。选择创建新保管库。

4. 输入备份保管库的名称。您对保管库的命名可以体现出将要存储在其中的内容，或者便于搜索您所需的备份。例如，您可以将其命名为 FinancialBackups。

5. 选择逻辑上受物理隔离的保管库所对应的单选按钮。

6. （可选）选择加密密钥。您可以选择客户管理的 KMS 密钥以进一步控制加密，也可以使用默认 Amazon拥有的密钥（推荐）。

7. 设置最短保留期。

   此值（以天、月或年为单位）是可以在此保管库中保留备份的最短时间。无法将保留期短于此值的备份复制到此保管库。

   允许的最小值为 7 天。月数和年数的值满足这一最低要求。

8. 设置最长保留期。

   此值（以天、月或年为单位）是可以在此保管库中保留备份的最长时间。无法将保留期大于此值的备份复制到此保管库。

9. （可选）设置加密密钥。

   指定用于保管库的密钥。您可以选择Amazon 自有密钥（由管理 Amazon Backup），也可以输入客户管理密钥的 ARN，该密钥最好属于您有权访问的其他账户。 Amazon Backup 建议使用 Amazon 自有密钥。

10. （可选）添加标签，以帮助您搜索和识别逻辑气隙保管库。例如，您可以添加 BackupType:Financial 标签。

11. 选择创建保管库。

12. 检查设置。如果所有设置都按预期显示，请选择创建逻辑气隙保管库。

13. 控制台将带您进入新保管库的详细信息页面。验证保管库详细信息是否符合预期。

14. 选择保管库以查看您账户中的保管库。此时将显示逻辑上受物理隔离的保管库。KMS 密钥将在保管库创建后大约 1 到 3 分钟内可用。刷新页面以查看关联的密钥。一旦密钥可见，保管库即处于可用状态，可供使用。

Amazon CLI

从 CLI 创建逻辑上受物理隔离的保管库

您可以使用 Amazon CLI 以编程方式对逻辑上的气隙保管库执行操作。每个 CLI 都特定于其起源的 Amazon 服务。与共享相关的命令在前面加上 aws ram；所有其他命令都应在前面加上 aws backup。

使用 CLI 命令 create-logically-air-gapped-backup-vault，该命令用以下参数进行了修改：

aws backup create-logically-air-gapped-backup-vault
--region us-east-1 // optional
--backup-vault-name sampleName // required
--min-retention-days 7 // required Value must be an integer 7 or greater
--max-retention-days 35 // required
--encryption-key-arn arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012 // optional
--creator-request-id 123456789012-34567-8901 // optional

可选--encryption-key-arn参数允许您为保管库加密指定客户管理的 KMS 密钥。如果未提供，保管库将使用 Amazon自有密钥。

用于创建逻辑上受物理隔离的保管库的 CLI 命令示例：

aws backup create-logically-air-gapped-backup-vault
--region us-east-1
--backup-vault-name sampleName
--min-retention-days 7
--max-retention-days 35
--creator-request-id 123456789012-34567-8901 // optional

使用客户管理的加密创建逻辑气隙保管库的 CLI 命令示例：

aws backup create-logically-air-gapped-backup-vault
--region us-east-1
--backup-vault-name sampleName
--min-retention-days 7
--max-retention-days 35
--encryption-key-arn arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012
--creator-request-id 123456789012-34567-8901 // optional

有关创建操作之后的信息，请参阅 CreateLogicallyAirGappedBackupVault API 响应元素。如果操作成功，则新的逻辑气隙保管库将为 of。 VaultState CREATING

创建完成并分配 KMS 加密密钥后， VaultState 将过渡到AVAILABLE。该保管库为可用状态后，即可供使用。可以通过调用 DescribeBackupVault 或 ListBackupVaults 来检索 VaultState。

查看逻辑上受物理隔离的保管库的详细信息

您可以通过 Amazon Backup 控制台或 Amazon Backup CLI 查看保管库的详细信息，例如摘要、恢复点、受保护资源、账户共享、访问策略和标签。

Console

1. 在处打开 Amazon Backup 控制台https://console.aws.amazon.com/backup。

2. 从左侧导航窗格中，选择保管库。

3. 保管库描述下方将列出三个列表：由该账户创建的保管库、通过 RAM 共享的保管库和通过批准可访问的保管库。 Multi-party 选择所需的选项卡以查看保管库。

4. 在保管库名称下，单击保管库名称以打开详细信息页面。您可以查看摘要、恢复点、受保护的资源、账户共享、访问策略和标签详细信息。

   详细信息的显示视账户类型而定：拥有保管库的账户可以查看账户共享；不拥有保管库的账户将无法查看账户共享。对于共享保管库，加密密钥类型（Amazon自有或客户管理的 KMS 密钥）显示在保管库摘要中。

Amazon CLI

通过 CLI 查看逻辑上受物理隔离的保管库的详细信息

CLI 命令 describe-backup-vault 可用于获取有关保管库的详细信息。参数 backup-vault-name 是必需项，region 是可选项。

aws backup describe-backup-vault
--region us-east-1
--backup-vault-name testvaultname

响应示例：

{
            "BackupVaultName": "LOG-AIR-GAP-VAULT-TEST",
            "BackupVaultArn": "arn:aws:backup:us-east-1:234567890123:backup-vault:IAD-LAGV-01",
            "VaultType": "LOGICALLY_AIR_GAPPED_BACKUP_VAULT",
            "EncryptionKeyType": "AWS_OWNED_KMS_KEY",
            "CreationDate": "2024-07-25T16:05:23.554000-07:00",
            "NumberOfRecoveryPoints": 0,
            "Locked": true,
            "MinRetentionDays": 8,
            "MaxRetentionDays": 30,
            "LockDate": "2024-07-25T16:05:23.554000-07:00"
}

注意

在逻辑气隙保管库不可用的区域，该VaultType字段不包含在 API 响应中。

在逻辑上存在气隙的保管库中创建备份

从逻辑上讲，气隙保管库可以是备份计划中的拷贝作业目标目标，也可以是按需拷贝作业的目标。它也可以用作主要的备份目标。请参阅逻辑气隙保管库的主备份。

兼容的加密

要确保成功从备份保管库复制到逻辑上受物理隔离的保管库，需要一个由所复制的资源类型确定的加密密钥。

当您创建或复制完全托管资源类型的备份时，源资源可以通过客户管理的密钥或托管密钥进行加密。 Amazon

当您创建或复制其他资源类型（未完全托管的）的备份时，必须使用客户管理的密钥对源进行加密。 Amazon 不支持非完全托管资源的托管密钥。

通过备份计划创建备份或将备份复制到逻辑上存在气隙的保管库

您可以通过在 Amazon Backup 控制台中创建新的备份计划或更新现有备份计划或通过命令和将备份（恢复点）从标准备份保管库复制到逻辑气隙保管库。 Amazon CLI create-backup-plan update-backup-plan您还可以将逻辑隔开的保管库用作主要目标，直接在逻辑隔离的保管库中创建备份。有关更多详细信息，请参阅逻辑气隙保管库目标为逻辑上受物理隔离的保管库的主备份的主备份。

可以按需将备份从一个逻辑上受物理隔离的保管库复制到另一个逻辑上受物理隔离的保管库（无法在备份计划中安排此类备份）。只要使用客户托管密钥对副本进行加密，就可以将备份从逻辑上受物理隔离的保管库复制到标准备份保管库。

On-demand 将副本备份到逻辑上存在气隙的保管库

要创建一次性按需备份副本到逻辑气隙保管库，可以从标准备份保管库复制。 Cross-Region 或者，如果资源类型支持副本类型，则可以使用跨账户副本。

副本可用性

可以从保管库所属的账户创建备份副本。共享保管库的账户可以查看或还原备份，但不能创建副本。

只能包括支持跨区域或跨账户复制的资源类型。

Console

1. 在处打开 Amazon Backup 控制台https://console.aws.amazon.com/backup。

2. 从左侧导航窗格中，选择保管库。

3. 在保管库详细信息页面中，将显示该保管库中的所有恢复点。在要复制的恢复点旁边打勾标记。

4. 选择操作，然后选择下拉菜单中的复制。

5. 在下一个屏幕上，输入目的地详细信息。

   1. 指定目标区域。

   2. 目的地备份保管库下拉菜单显示符合条件的目的地保管库。按类型 logically air-gapped vault 选择一个

6. 将所有详细信息设置为首选项后，选择复制。

在控制台的作业页面上，您可以选择复制作业以查看当前的复制作业。

Amazon CLI

使用 start-copy-job 将备份保管库中的现有备份复制到逻辑上受物理隔离的保管库。

CLI 输入示例：

aws backup start-copy-job
--region us-east-1
--recovery-point-arn arn:aws:resourcetype:region::snapshot/snap-12345678901234567
--source-backup-vault-name sourcevaultname
--destination-backup-vault-arn arn:aws:backup:us-east-1:123456789012:backup-vault:destinationvaultname
--iam-role-arn arn:aws:iam::123456789012:role/service-role/servicerole

有关更多信息，请参阅复制备份、跨区域 Cross-account备份和备份。

共享逻辑上受物理隔离的保管库

您可以使用 Amazon Resource Access Manager (RAM) 与您指定的其他账户共享逻辑隔离保管库。共享保管库时，加密密钥类型信息（Amazon自有或客户管理的 KMS 密钥）会被保留，与之共享保管库的账户可见。

保管库只能与个人 Amazon Web Services 账户 ID 共享。您可以与组织中的账户共享，也可以与其他组织中的账户共享。保管库不能与整个组织或组织单位 (OU) 共享，仅支持个人账户 ID 作为共享主体。

只有具有特定 IAM 权限的账户才能共享和管理保管库共享。

要使用共享 Amazon RAM，请确保您具备以下条件：

Console

1. 在处打开 Amazon Backup 控制台https://console.aws.amazon.com/backup。

2. 从左侧导航窗格中，选择保管库。

3. 保管库描述下方将显示两个列表，即该账户拥有的保管库和与该账户共享的保管库。该账户拥有的保管库有资格进行共享。

4. 在保管库名称下，选择逻辑气隙保管库的名称以打开详细信息页面。

5. 账户共享窗格显示正在与哪些账户共享保管库。

6. 要开始与其他账户共享或编辑已共享的账户，请选择管理共享。

7. 选择 “管理共享” 后， Amazon RAM 控制台将打开。有关使用 Amazon RAM 共享资源的步骤，请参阅 RAM 用户指南中的在 Amazon RAM 中Amazon 创建资源共享。

8. 受邀接受共享邀请的账户有 12 小时的时间接受邀请。请参阅《Amazon RAM 用户指南》中的接受和拒绝资源共享邀请。

9. 如果共享步骤已完成并被接受，则保管库摘要页面将显示在账户共享 =“已共享 - 参见下面的账户共享表”下方。

Amazon CLI

Amazon RAM 使用 CLI 命令create-resource-share。只有拥有足够权限的账户才能访问此命令。有关 CLI 步骤，请参阅在 Amazon RAM中创建资源共享。

第 1 步到第 4 步是使用拥有逻辑气隙保管库的账户执行的。第 5 步到第 8 步是使用将与之共享逻辑气隙保管库的账户执行的。

1. 登录所属账户，或者请求您组织中具有足够凭证的用户访问源账户，完成这些步骤。

   1. 如果之前创建了资源共享，且您希望向其添加其他资源，请使用 CLI associate-resource-share，而不是新保管库的 ARN。

2. 获取具有足够权限的角色的凭证，以便通过 RAM 进行共享。将这些输入到 CLI 中。

   1. 此过程需要权限 ram:CreateResourceShare。该策略AWSResourceAccessManagerFullAccess包含所有 RAM-related权限。

3. 使用 create-resource-share。

   1. 包括逻辑气隙保管库的 ARN。

   2. 输入示例：

      aws ram create-resource-share
      --name MyLogicallyAirGappedVault
      --resource-arns arn:aws:backup:us-east-1:123456789012:backup-vault:test-vault-1
      --principals 123456789012
      --region us-east-1

   3. 示例输出：

      {
         "resourceShare":{
            "resourceShareArn":"arn:aws:ram:us-east-1:123456789012:resource-share/12345678-abcd-09876543",
            "name":"MyLogicallyAirGappedVault",
            "owningAccountId":"123456789012",
            "allowExternalPrincipals":true,
            "status":"ACTIVE",
            "creationTime":"2021-09-14T20:42:40.266000-07:00",
            "lastUpdatedTime":"2021-09-14T20:42:40.266000-07:00"
         }
      }

4. 在输出中复制资源共享 ARN（后续步骤需要这样做）。将 ARN 交给您邀请接收共享的账户操作员。

5. 获取资源共享 ARN

   1. 如果您没有执行第 1 步到第 4 步，请ShareArn 从执行者那里获取资源。

   2. 示例：arn:aws:ram:us-east-1:123456789012:resource-share/12345678-abcd-09876543

6. 在 CLI 中，假设接收账户的凭证。

7. 通过 get-resource-share-invitations 获取资源共享邀请。有关更多信息，请参阅《Amazon RAM 用户指南》中的接受和拒绝邀请。

8. 在目的地（恢复）账户中接受邀请。

   1. 使用 accept-resource-share-invitation（也可使用 reject-resource-share-invitation）。

您可以使用 Amazon RAM CLI 命令查看共享项目：

• 已共享的资源：

  aws ram list-resources --resource-owner SELF --resource-type backup:backup-vault --region us-east-1

• 显示主体：

  aws ram get-resource-share-associations --association-type PRINCIPAL --region us-east-1

• 其他账户共享的资源：

  aws ram list-resources --resource-owner OTHER-ACCOUNTS --resource-type backup:backup-vault --region us-east-1

从逻辑上受物理隔离的保管库中还原备份

您可以从拥有该保管库的账户或与之共享保管库的任何账户，还原存储在逻辑上受物理隔离的保管库中的备份。

有关如何通过 Amazon Backup 控制台还原恢复点的信息，请参阅还原备份。

将备份从逻辑上受物理隔离的保管库共享到您的账户后，您可以使用 start-restore-job 来还原备份。

示例 CLI 输入可能包括以下命令和参数：

aws backup start-restore-job
--recovery-point-arn arn:aws:backup:us-east-1:accountnumber:recovery-point:RecoveryPointID
--metadata {\"availabilityzone\":\"us-east-1d\"}
--idempotency-token TokenNumber
--resource-type ResourceType
--iam-role arn:aws:iam::number:role/service-role/servicerole
--region us-east-1

删除逻辑上受物理隔离的保管库

参阅删除保管库。如果保管库仍包含备份（恢复点），则无法将其删除。在启动删除操作之前，请确保保管库中没有备份。

根据密钥删除策略，保管库删除操作还会在该保管库被删除七天后删除与该保管库关联的密钥。

以下示例 CLI 命令 delete-backup-vault 可用于删除保管库。

aws backup delete-backup-vault
--region us-east-1 
--backup-vault-name testvaultname

逻辑上受物理隔离的保管库的其他编程选项

可以修改 CLI 命令 list-backup-vaults，以列出该账户拥有和存在的所有保管库：

aws backup list-backup-vaults
--region us-east-1

要仅列出逻辑气隙保管库，请添加参数

--by-vault-type LOGICALLY_AIR_GAPPED_BACKUP_VAULT

包括用于筛选返回的保管库列表的参数 by-shared，以仅显示共享的逻辑上受物理隔离的保管库。响应将包括每个共享保管库的加密密钥类型信息。

aws backup list-backup-vaults
--region us-east-1
--by-shared

显示加密密钥类型信息的示例响应：

{
    "BackupVaultList": [
        {
            "BackupVaultName": "shared-logically air-gapped-vault",
            "BackupVaultArn": "arn:aws:backup:us-east-1:123456789012:backup-vault:shared-logically air-gapped-vault",
            "VaultType": "LOGICALLY_AIR_GAPPED_BACKUP_VAULT",
            "EncryptionKeyType": "AWS_OWNED_KMS_KEY",
            "CreationDate": "2024-07-25T16:05:23.554000-07:00",
            "Locked": true,
            "MinRetentionDays": 7,
            "MaxRetentionDays": 30
        }
    ]
}

了解逻辑气隙保管库的加密密钥类型

逻辑上的气隙保管库支持不同的加密密钥类型，这些信息可通过 Amazon Backup API 和控制台查看。当通过 Amazon RAM 或 MPA 共享保管库时，加密密钥类型信息会被保留下来，并可供共享保管库的账户看见。这种透明性可帮助您了解保管库的加密配置，并就备份和还原操作做出明智的决策。

加密密钥类型值

该EncryptionKeyType字段可以有以下值：

创建 CMK 加密逻辑气隙保管库的密钥政策

使用客户管理的密钥创建逻辑气隙保管库时，必须将 Amazon-managed 策略AWSBackupFullAccess应用于您的账户角色。此策略包括 Amazon Backup 允许在备份、复制和存储Allow操作期间与 Amazon KMS KMS 密钥进行交互以创建授权的操作。此外，您必须确保您的客户管理密钥（如果使用）政策包括所需的特定权限。

{  
    "Sid": "Allow use of the key to create a logically air-gapped vault",  
    "Effect": "Allow",  
    "Principal": {  
        "Amazon": "arn:aws:iam::[account-id]:role/TheRoleToAccessAccount"  
    },  
    "Action": [  
        "kms:CreateGrant",  
        "kms:DescribeKey"  
    ],  
    "Resource": "*",  
   "Condition": {  
        "StringLike": {  
            "kms:ViaService": "backup.*.amazonaws.com"  
        }  
   }  
}

的关键政策 copy/restore

为防止任务失败，请查看您的 Amazon KMS 密钥策略，确保其包含所有必需的权限，并且不包含任何可能阻止操作的拒绝语句。以下条件适用：

{  
    "Sid": "Allow use of the key for copy",  
    "Effect": "Allow",  
    "Principal": {  
        "Amazon": "arn:aws:iam::[source-account-id]:role/service-role/AWSBackupDefaultServiceRole"      //[Source copy role]          
    },  
    "Action": [  
        "kms:Encrypt",  
        "kms:Decrypt",  
        "kms:ReEncrypt*",  
        "kms:GenerateDataKey*",  
        "kms:DescribeKey"  
    ],  
    "Resource": "*",  
   "Condition": {  
         "StringLike": {  
            "kms:ViaService": "backup.*.amazonaws.com"  
         }  
   }  
},  
{  
    "Sid": "Allow Amazon Backup to create grant on the key for copy",  
    "Effect": "Allow",  
    "Principal": {  
        "Amazon": "arn:aws:iam::[source-account-id]:role/service-role/AWSBackupDefaultServiceRole" //[Source copy role]   
    },  
    "Action": [  
        "kms:CreateGrant"  
    ],  
    "Resource": "*",  
    "Condition": {  
        "Bool": {  
            "kms:GrantIsForAWSResource": "true"  
        },  
        "StringLike": {  
            "kms:ViaService": "backup.*.amazonaws.com"  
        }  
    }  
}

{  
    "Sid": "Allow use of the key for copy from a CMK encrypted logically air-gapped vault to normal backup vault",
    "Effect": "Allow",  
    "Principal": {  
        "Amazon": ["arn:aws:iam::[source-account-id]:role/service-role/AWSBackupDefaultServiceRole",      //[Source copy role]  
                "arn:aws:iam::[destination-account-id]:role/aws-service-role/backup.amazonaws.com/AWSServiceRoleForBackup"], //[Destination SLR]    
    },  
    "Action": [  
        "kms:Encrypt",  
        "kms:Decrypt",  
        "kms:ReEncrypt*",  
        "kms:GenerateDataKey*",  
        "kms:DescribeKey"  
    ],  
    "Resource": "*"  
},  
{  
    "Sid": "Allow Amazon Backup to create grant on the key for copy",  
    "Effect": "Allow",  
    "Principal": {  
          "Amazon": ["arn:aws:iam::[source-account-id]:role/service-role/AWSBackupDefaultServiceRole",      //[Source copy role]  
                  "arn:aws:iam::[destination-account-id]:role/aws-service-role/backup.amazonaws.com/AWSServiceRoleForBackup"], //[Destination SLR]   
    },  
    "Action": [  
        "kms:CreateGrant"  
    ],  
    "Resource": "*",  
    "Condition": {  
        "Bool": {  
            "kms:GrantIsForAWSResource": "true"  
        }  
    }  
}

{  
    "Sid": "Allow use of the key for copy/restore from a recovery account",  
    "Effect": "Allow",  
    "Principal": {  
        "Amazon": ["arn:aws:iam::[recovery-account-id]:role/service-role/AWSBackupDefaultServiceRole", //[Recovery account copy/restore role]
                "arn:aws:iam::[destination-account-id]:role/aws-service-role/backup.amazonaws.com/AWSServiceRoleForBackup"] //[Destination SLR]    
    },  
    "Action": [  
        "kms:Encrypt",  
        "kms:Decrypt",  
        "kms:ReEncrypt*",  
        "kms:GenerateDataKey*",  
        "kms:DescribeKey"  
    ],  
    "Resource": "*"  
},  
{  
    "Sid": "Allow Amazon Backup to create grant on the key for copy",  
    "Effect": "Allow",  
    "Principal": {  
        "Amazon": ["arn:aws:iam::[recovery-account-id]:role/service-role/AWSBackupDefaultServiceRole" //[Recovery account copy/restore role]    
                "arn:aws:iam::[destination-account-id]:role/aws-service-role/backup.amazonaws.com/AWSServiceRoleForBackup"], //[Destination SLR]  
                  
    },  
    "Action": [  
        "kms:CreateGrant"  
    ],  
    "Resource": "*",  
    "Condition": {  
        "Bool": {  
            "kms:GrantIsForAWSResource": "true"  
        }  
    }  
}

IAM 角色

在执行逻辑上气隙隔离的保管库复制操作时，客户可以使用包括管理策略在内AWSBackupDefaultServiceRole的 Amazon。AWSBackupServiceRolePolicyForBackup但是，如果客户更愿意实施最低权限策略方法，则他们的 IAM 政策必须包含特定要求：

{  
    "Version": "2012-10-17",  
    "Statement": [  
         {  
            "Sid": "KMSPermissions",  
            "Effect": "Allow",  
            "Action": "kms:DescribeKey",  
            "Resource": [  
                "arn:aws:kms:*:[source-account-id]:key/*",  - Source logically air-gapped vault CMK -   
                "arn:aws:kms:*:[destination-account-id]:key/*".  - Destination logically air-gapped vault CMK -   
            ]  
        },  
        {  
            "Sid": "KMSCreateGrantPermissions",  
            "Effect": "Allow",  
            "Action": "kms:CreateGrant",  
            "Resource": [  
                "arn:aws:kms:*:[source-account-id]:key/*",  - Source logically air-gapped vault CMK -   
                "arn:aws:kms:*:[destination-account-id]:key/*".  - Destination logically air-gapped vault CMK -   
            ]  
            "Condition": {  
                "Bool": {  
                    "kms:GrantIsForAWSResource": "true"  
                }  
            }  
        },  
    ]  
}

因此，当客户未能为其 CMK 和复制角色提供足够的权限时，最常见的客户错误之一发生在复制过程中。

查看加密密钥类型

您可以通过 Amazon Backup 控制台查看加密密钥类型信息，也可以使用 Amazon CLI 或 SDK 以编程方式查看加密密钥类型信息。

控制台：在控制 Amazon Backup 台中查看逻辑气隙保管库时，加密密钥类型显示在保管库详细信息页面的安全信息部分下。

Amazon CLI/API：查询逻辑气隙保管库时，将在以下操作的响应中返回加密密钥类型：

保管库加密的注意事项

使用逻辑气隙保管库和加密密钥类型时，请考虑以下几点：

服务自有密钥的使用

Amazon Backup 创建和管理加密密钥，这些密钥用于加密存储在逻辑气隙保管库中的所有备份数据，以保护和防止在数据丢失事件期间丢失对加密密钥的访问权限。

访问Amazon KMS 文档以了解更多信息。

安全自动修复注意事项

将 EC2 (AMI) 备份 Amazon Backup 复制到逻辑气隙保管库时，它会临时向服务拥有的账户launchPermission（在 AMI 上）和createVolumePermission（在关联的 EBS 快照上）授予权限。复制完成后，这些权限会自动撤销。

这些操作会在您的 Amazon CloudTrail 日志中生成ModifyImageAttribute和ModifySnapshotAttribute事件，userIdentity.invokedBy设置为backup.amazonaws.com。

如果您有监控这些事件并撤消跨账户共享的安全自动修复逻辑（例如，Amazon EventBridge 规则 Amazon Lambda），则必须排除事件所在位置。userIdentity.invokedBy backup.amazonaws.com否则，将任务复制到逻辑气隙保管库将失败，并显示：“您无权访问此 ami 的存储。”

这种排除是安全的，因为副本是由您的文件库访问策略（backup:CopyFromBackupVault在源文件库和目标文件库backup:CopyIntoBackupVault上）授权的，这些策略是在任何 EC2 属性修改之前进行评估的。临时权限仅授予固定的 Amazon 服务拥有的账户，并在复制完成后自动撤销。

排除 Amazon Backup 操作的 EventBridge 规则事件模式示例：

{
  "source": ["aws.ec2"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["ec2.amazonaws.com"],
    "eventName": ["ModifySnapshotAttribute", "ModifyImageAttribute"],
    "userIdentity": {
      "invokedBy": [{"anything-but": "backup.amazonaws.com"}]
    }
  }
}

解决逻辑上受物理隔离的保管库问题

如果工作流中出现错误，请查阅以下错误和建议解决方案的示例：

EC2 AMI 向逻辑气隙保管库的复制任务因权限错误而失败

错误：Copy job fails with "You do not have permission to access the storage of this ami."

可能的原因：在 EC2 AMI 将任务复制到逻辑气隙保管库期间， Amazon Backup 临时向服务拥有的账户授予启动权限 (AMI) 和创建卷权限（EBS 快照），在日志中生成ModifyImageAttribute和ModifySnapshotAttribute事件。 Amazon CloudTrail 如果您有监控这些事件并自动撤消跨账户共享权限的安全自动修复逻辑（例如使用 Lambda 的 EventBridge规则），则它可以在复制完成之前删除临时访问权限。

解决方案：更新您的 EventBridge 规则事件模式以排除由执行的操作 Amazon Backup。具体而言，排除当前事件userIdentity.invokedBy是backup.amazonaws.com为了确保您的自动修复逻辑不会撤消在复制过程中 Amazon Backup 授予的临时跨账户权限。

AccessDeniedException

错误：An error occured (AccessDeniedException) when calling the [command] operation: Insufficient privileges to perform this action."

可能的原因：在 RAM 共享的保管库上运行以下请求之一时未包括参数 --backup-vault-account-id：

解决方案：重试返回错误的命令，但要包括指定拥有该保管库的账户的参数 --backup-vault-account-id。

OperationNotPermittedException

错误：在 CreateResourceShare 调用后返回 OperationNotPermittedException。

可能的原因：如果您尝试与其他组织共享资源（例如逻辑上受物理隔离的保管库），则可能会出现此异常。保管库可以与其他组织内的账户共享，但不能与其他组织本身共享。

解决方案：重试该操作，但指定一个账户（而不是组织或 OU）作为 principals 的值。

未显示加密密钥类型

问题：查看逻辑气隙保管库或其恢复点时，加密密钥类型不可见。

可能的原因：

解决方法：

AccessDeniedException 在 CloudTrail 日志中 “失败” VaultState

出现错误 CloudTrail："User: <assumed role> is not authorized to perform: kms:CreateGrant on this resource because the resource does not exist in this Region, no resource-based policies allow access, or a resource-based policy explicitly denies access"

可能的原因：

解决方法：

无法删除处于 “失败” 状态的恢复访问备份保管库

错误：还原访问备份保管库处于 “失败” 状态。RevokeRestoreAccessBackupVault返回错误，要求保管库处于可用状态，然后CreateRestoreAccessBackupVault返回LimitExceededException。

可能的原因：

解决方案：DeleteBackupVault从恢复账户中调用以删除失败的还原访问备份保管库。RevokeRestoreAccessBackupVault仅适用于处于可用状态的文件库。文件库锁定不会阻止这种删除，因为还原访问权限备份保管库是底层逻辑气隙保管库的视图，本身不包含任何恢复点。删除后，更正 KMS 密钥策略并添加mpa:StartSession权限，然后再重新创建保管库。