逻辑上受物理隔离的保管库 - Amazon Backup
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

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

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

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

Amazon Backup 提供了一种辅助类型的保管库,可以将备份存储在具有其他安全功能的容器中。逻辑上空隙的保管库是一种专门的保管库,它提供了比标准备份保管库更高的安全性,并且能够与其他账户共享保管库访问权限,这样在发生需要快速恢复资源的事件时,恢复时间目标 (RTOs) 可以更快、更灵活。

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

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

为了提高弹性,我们建议在相同或单独的账户中在逻辑上存在气隙的保管库中创建跨区域副本。但是,如果您想通过仅维护一个副本来降低存储成本,则可以在加入 MPA 后使用主备份来实现逻辑上空隙的保管库。 Amazon

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

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

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

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

  • 合规模式下使用保管库锁定功能自动设置

  • 默认情况下,使用 Amazon 自有密钥提供加密。(可选)您可以提供客户托管密钥

  • 包含通过 Amazon RAM 或 MPA 与创建备份的帐户不同的帐户共享和恢复的备份

注意事项和限制

  • 对于包含 Amazon Aurora、Amazon DocumentDB 和 Amazon Neptune 的备份,目前不支持跨区域复制到逻辑上受物理隔离的保管库或从该保管库跨区域复制。

  • 包含一个或多个 Amazon EBS 卷并复制到逻辑上受物理隔离的保管库的备份必须小于 16 TB;超过该大小的此类资源的备份不受支持。

  • EC2 允许亚马逊 EC2 报价 AMIs。如果您的账户启用了此设置,请将别名 aws-backup-vault 添加到您的允许列表中。

    如果不包括此别名,则从逻辑上隔绝的存储库复制到备份存储库的操作以及从逻辑上空隙的保管库中恢复 EC2 实例的操作将失败,并显示错误消息,例如 “在区域中找不到源 AMI ami-xxxxxx”。

  • 存储在逻辑上受物理隔离的保管库中的恢复点的 ARN(Amazon 资源名称)将使用 backup 代替底层资源类型。例如,如果原始 ARN 以 arn:aws:ec2:region::image/ami-* 开头,则逻辑上受物理隔离的保管库中恢复点的 ARN 将为 arn:aws:backup:region:account-id:recovery-point:*

    您可以使用 CLI 命令 list-recovery-points-by-backup-vault 确定 ARN。

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

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

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

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

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

与备份存储库类似,逻辑上的气隙存储库也支持 Amazon 备份的受限标签。 EC2

功能 备份保管库 逻辑上受物理隔离的保管库
Amazon Backup Audit Manager 您可以使用 Audi Amazon Backup t Manager 控制和修复 来监控您的备份存储库。 除了标准保管库可用的控件外,还要确保按照您确定的时间表将特定资源的备份存储在至少一个逻辑上存在气隙的保管库中。

Billing

完全由 Amazon Backup 托管的资源的存储和数据传输费用记在“Amazon Backup”下。其他资源类型的存储和数据传输费用将记在各自的服务下。

例如,Amazon EBS 备份将显示在“Amazon EBS”下;Amazon S3 备份将显示在“Amazon Backup”下。

这些保管库的所有账单费用(存储或数据传输)都记在“Amazon Backup”下。

区域

在所有 Amazon Backup 运营地区均可用

在支持的大多数地区都可用 Amazon Backup。目前在亚太地区(马来西亚)、加拿大西部(卡尔加里)、墨西哥(中部)、亚太地区(泰国)、亚太地区(台北)、亚太地区(新西兰)、中国(北京)、中国(宁夏) Amazon GovCloud 、(美国东部) Amazon GovCloud 或(美国西部)不可用。

资源

可以存储大多数支持跨账户复制的资源类型的备份副本。

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

还原

备份可以由保管库所属的同一个账户进行还原,

也可以由与其所属账户不同的另一个账户进行还原,但前提是这两个账户共享该保管库。

安全性

可以选择使用密钥进行加密(客户管理或 Amazon 管理)

可以选择在合规模式或监管模式下使用保管库锁定功能

可以使用Amazon 自有密钥或客户管理的密钥进行加密

在合规模式下始终使用保管库锁定功能进行锁定

通过 Amazon RAM 或 MPA 共享文件库时,加密密钥类型信息会被保留并可见

共享

可以通过策略和 Amazon Organizations 管理访问权限

不兼容 Amazon RAM

可以选择使用 Amazon RAM 跨账户共享

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

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

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

Console
从控制台创建逻辑气隙保管库
  1. https://console.aws.amazon.com/backup 上打开 Amazon 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 响应元素。如果操作成功,则新的逻辑上存在气隙的保管库将 VaultState 为。CREATING

创建完成并分配 KMS 加密密钥后, VaultState 将转换为AVAILABLE。该保管库为可用状态后,即可供使用。可以通过调用 DescribeBackupVaultListBackupVaults 来检索 VaultState

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

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

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

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

  3. 文件库描述下方将列出三个列表:该账户创建的保管库通过 RAM 共享的保管库以及可通过多方批准访问的保管库。选择所需的选项卡以查看保管库。

  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" }

在逻辑隔绝的保管库中创建备份

从逻辑上讲,空隙存储库可以是备份计划中的复印任务目标或按需复印作业的目标。它也可以用作主备份目标。请参见对逻辑气隙存储库的主备份

兼容的加密

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

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

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

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

您可以通过创建新的备份计划或在 Amazon Backup 控制台中更新现有备份计划或通过 Amazon CLI 命令create-backup-plan和将备份(恢复点)从标准备份保管库复制到逻辑上隔绝的保管库。update-backup-plan您也可以将其用作主目标,直接在逻辑上存在气隙的保管库中创建备份。有关更多详细信息,请参阅对逻辑气隙保管库的主备份

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

按需将备份复制到逻辑上受物理隔离的保管库

要在逻辑上受物理隔离的保管库中创建一次性按需备份副本,可以从标准备份保管库中进行复制。如果资源类型支持副本类型,则可以使用跨区域或跨账户副本。

副本可用性

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

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

Console
  1. https://console.aws.amazon.com/backup 上打开 Amazon 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

有关更多信息,请参阅复制备份跨区域备份跨账户备份

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

您可以使用 Amazon Resource Access Manager (RAM) 与您指定的其他账户共享逻辑上存在气隙的保管库。共享文件库时,加密密钥类型信息(Amazon由所有或客户管理的 KMS 密钥)会保留,与之共享保管库的账户可见。

可以与同一组织内的账户共享保管库,也可以与其他组织内的账户共享保管库。不能与整个组织共享保管库,只能与组织内的账户共享。

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

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

  • 两个或更多可以访问的账户 Amazon Backup

  • 打算共享的拥有保管库的账户拥有必要的 RAM 权限。此过程需要权限 ram:CreateResourceShare。策略 AWSResourceAccessManagerFullAccess 包含所有必需的 RAM 相关权限:

    • backup:DescribeBackupVault

    • backup:DescribeRecoveryPoint

    • backup:GetRecoveryPointRestoreMetadata

    • backup:ListProtectedResourcesByBackupVault

    • backup:ListRecoveryPointsByBackupVault

    • backup:ListTags

    • backup:StartRestoreJob

  • 至少一个逻辑气隙保管库

Console
  1. https://console.aws.amazon.com/backup 上打开 Amazon 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 相关的权限。

  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 步 resourceShareArn 到第 4 步,请向执行者索取。

    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 APIs 控制台查看。通过 Amazon RAM 或 MPA 共享文件库时,会保留加密密钥类型信息,并使与之共享保管库的账户可见。这种透明度有助于您了解保管库的加密配置,并就备份和还原操作做出明智的决策。

加密密钥类型值

EncryptionKeyType字段可以具有以下值:

  • AWS_OWNED_KMS_KEY-保管库使用 Amazon自有密钥加密。如果未指定客户管理的密钥,则这是逻辑上空隙保管库的默认加密方法。

  • CUSTOMER_MANAGED_KMS_KEY-使用由您控制的客户管理的 KMS 密钥对保管库进行加密。此选项提供了对加密密钥和访问策略的额外控制。

注意
  • Amazon Backup 建议将 Amazon 拥有的密钥与逻辑上隔开的保管库一起使用。但是,如果您的组织政策要求使用客户托管密钥,则最佳做法是使用辅助组织中另一个账户中专门用于恢复的密钥。您可以参考博客 Encrypt Amazon Backup 带有客户管理密钥的逻辑气隙保管库,以收集有关设置基于 CMK 的逻辑气隙保管库的更多见解。

  • 您只能在创建保管库期间选择 Amazon KMS 加密密钥。创建后,保管库中包含的所有备份都将使用该密钥进行加密。您不能更改或迁移您的保管库以使用不同的加密密钥。

创建 CMK 加密的逻辑空隙保管库的密钥策略

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

  • CMK 必须与逻辑上存在气隙的保管库所在的账户共享

{ "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" } } }

复制/恢复的密钥策略

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

  • 对于所有复制方案,都 CMKs 必须与源副本角色共享

{ "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" } } }
  • 从 CMK 加密的逻辑空隙保管库复制到备份保管库时,还必须与目标账户 SLR 共享 CMK

{ "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" } } }
  • 使用 RAM/MPA 共享的逻辑隔空保管库从恢复账户进行复制或还原时

{ "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 角色

在执行逻辑上隔开的保管库复制操作时,客户可以利用包含托 Amazon管策略AWSBackupDefaultServiceRole的。AWSBackupServiceRolePolicyForBackup但是,如果客户更喜欢实施最低权限策略方法,则他们的 IAM 策略必须包括一项具体要求:

  • 源账户的复制角色必须同时具有源账户和目标账户的访问权限 CMKs。

{ "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" } } }, ] }

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

查看加密密钥类型

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

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

Amazon CLI/API:查询逻辑上空隙的文件库时,以下操作的响应中会返回加密密钥类型:

  • list-backup-vaults(包括--by-shared共享文件库)

  • describe-backup-vault

  • describe-recovery-point

  • list-recovery-points-by-backup-vault

  • list-recovery-points-by-resource

保管库加密的注意事项

在处理逻辑上存在气隙的保管库和加密密钥类型时,请考虑以下几点:

  • 创建期间的密钥选择:在创建逻辑上隔绝的保管库时,您可以选择指定客户管理的 KMS 密钥。如果未指定,则将使用 Amazon拥有的密钥。

  • 共享保管库可见性:与之共享保管库的账户可以查看加密密钥类型,但不能修改加密配置。

  • 恢复点信息:在逻辑上存在气隙的保管库中查看恢复点时,也可以使用加密密钥类型。

  • 还原操作:了解加密密钥类型有助于您规划还原操作并了解任何潜在的访问要求。

  • 合规性:加密密钥类型信息通过提供用于备份数据的加密方法的透明度,支持合规性报告和审计要求。

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

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

AccessDeniedException

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

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

  • describe-backup-vault

  • describe-recovery-point

  • get-recovery-point-restore-metadata

  • list-protected-resources-by-backup-vault

  • list-recovery-points-by-backup-vault

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

OperationNotPermittedException

错误:CreateResourceShare 调用后返回 OperationNotPermittedException

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

解决方案:重试该操作,但指定一个账户(而不是组织或 OU)作为 principals 的值。

未显示加密密钥类型

问题:查看逻辑上存在气隙的保管库或其恢复点时,加密密钥类型不可见。

可能的原因:

  • 您正在查看在添加加密密钥类型支持之前创建的较旧保管库

  • 您使用的是 Amazon CLI 或 SDK 的旧版本

  • API 响应不包含加密密钥类型字段

解决方法:

  • Amazon CLI 将你的版本更新到最新版本

  • 对于较旧的保管库,加密密钥类型将自动填充并应出现在后续的 API 调用中

  • 验证您使用的是返回加密密钥类型信息的 API 操作是否正确

  • 对于共享文件库,请验证保管库是否已通过正确共享 Amazon Resource Access Manager

CloudTrail 日志 AccessDeniedException 中 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"

可能的原因:

  • 保管库是使用客户托管密钥创建的,但代入的角色没有使用密钥创建文件库所需的密钥策略 CreateGrant 权限

解决方法: