本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 逻辑上受物理隔离的保管库
## 逻辑上受物理隔离的保管库概述
AWS Backup 提供了一种辅助类型的保管库，可以将备份存储在具有其他安全功能的容器中。**逻辑上空隙的保管库**是一种专门的保管库，它提供了比标准备份保管库更高的安全性，并且能够与其他账户共享保管库访问权限，这样在发生需要快速恢复资源的事件时，恢复时间目标 (RTOs) 可以更快、更灵活。
从逻辑上讲，气隙保管库配备了额外的保护功能；每个保管库都使用[AWS 自有密钥（默认）或可选的客户管理的 KMS 密钥](https://docs.aws.amazon.com//kms/latest/developerguide/concepts.html#key-mgmt)进行加密，并且每个保管库都配备了 Vault [Lock 的合AWS Backup 规](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html)模式。加密密钥类型信息可通过控制台查看 AWS Backup APIs ，以实现透明度和合规性报告。
您可以将逻辑上空隙的保管库与[多方批准](multipartyapproval.md) (MPA) 集成，即使无法访问保管库拥有者的帐户，也可以恢复保管库中的备份，这有助于保持业务连续性。此外，您可以选择与 [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html)(RAM) 集成，与其他 AWS 账户（包括其他组织中的账户）共享逻辑上存在空隙的保管库，以便在需要进行数据丢失恢复或还原测试时，可以从共享该保管库的账户中[恢复](restore-testing.md)存储在保管库中的备份。作为增强安全性的一部分，逻辑上隔绝的保管库将其备份存储在 AWS Backup 服务拥有的账户中（这会导致在 AWS CloudTrail 日志中的修改属性项中显示为组织外部共享的备份）。
[在您的逻辑上存在气隙的保管库拥有账户被关闭（恶意或其他方式）的情况下，您仍然可以通过 MPA 访问存储库中的备份（恢复或复制），直到关闭后的期限结束。](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-closing.html#post-closure-period)关闭后期限到期后，将无法再访问备份。在关闭后期间，您可以参考[AWS 账户管理文档，在恢复账户](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-closing.html#what-to-expect-after-closure)的同时重新获得对账户的控制权。
为了提高弹性，我们建议在相同或单独的账户中在逻辑上存在气隙的保管库中创建跨区域副本。但是，如果您想通过仅维护一个副本来降低存储成本，则可以在加入 MPA 后使用[主备份来实现逻辑上空隙的保管库](lag-vault-primary-backup.md)。 AWS
您可以在 [AWS Backup 定价](https://aws.amazon.com/backup/pricing/)页面上查看逻辑上受物理隔离的保管库中受支持服务的备份的存储定价。
有关您可以复制到逻辑上受物理隔离的保管库的资源类型，请参阅[按资源划分的功能可用性](backup-feature-availability.md#features-by-resource)。
**Topics**
+ [逻辑上受物理隔离的保管库概述](#lag-overview)
+ [逻辑上受物理隔离的保管库的用例](#lag-usecase)
+ [与标准备份保管库进行比较和对比](#lag-compare-and-contrast)
+ [创建逻辑上受物理隔离的保管库](#lag-create)
+ [查看逻辑上受物理隔离的保管库的详细信息](#lag-view)
+ [在逻辑隔绝的保管库中创建备份](#lag-creation)
+ [共享逻辑上受物理隔离的保管库](#lag-share)
+ [从逻辑上受物理隔离的保管库中还原备份](#lag-restore)
+ [删除逻辑上受物理隔离的保管库](#lag-delete)
+ [逻辑上受物理隔离的保管库的其他编程选项](#lag-programmatic)
+ [了解逻辑上存在气隙的保管库的加密密钥类型](#lag-encryption-key-types)
+ [服务自有密钥的使用](#lag-service-owned-key)
+ [安全自动修复的注意事项](#lag-security-auto-remediation)
+ [解决逻辑上受物理隔离的保管库问题](#lag-troubleshoot)
+ [目标为逻辑上受物理隔离的保管库的主备份](lag-vault-primary-backup.md)
+ [逻辑上受物理隔离的保管库的多方审批](multipartyapproval.md)
## 逻辑上受物理隔离的保管库的用例
逻辑上受物理隔离的保管库是作为数据保护策略一部分的辅助保管库。当您希望为备份使用符合以下条件的保管库时，此保管库可以帮助增强组织的保留策略和恢复能力
+ 在[合规模式](vault-lock.md)下使用保管库锁定功能自动设置
+ 默认情况下，使用 AWS 自有密钥提供加密。（可选）您可以提供客户托管密钥
+ 包含通过 AWS RAM 或 MPA 与创建备份的帐户不同的帐户共享和恢复的备份
**注意事项和限制**
+ 未加密的 Amazon Aurora、Amazon DocumentDB 和 Amazon Neptune 集群不支持逻辑空隙保管库，因为它们不支持对未加密的数据库集群快照进行加密。
+ 亚马逊 EC2 提供 [EC2 允许 AMIs](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-allowed-amis.html)。如果您的账户启用了此设置，请将别名 `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 命令 [https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListRecoveryPointsByBackupVault.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListRecoveryPointsByBackupVault.html) 确定 ARN。
## 与标准备份保管库进行比较和对比
**备份保管库**是 AWS Backup中使用的主要和标准类型的保管库。创建备份时，每个备份都存储在备份保管库中。您可以分配基于资源的策略来管理存储在保管库中的备份，例如存储在保管库中的备份的生命周期。
**逻辑气隙保管库**是一种专门的保管库，具有更高的安全性和灵活共享功能，可缩短恢复时间 (RTO)。此存储库存储最初创建并存储在标准备份存储库中的主备份或备份副本。
备份保管库使用密钥进行加密，这是一种限制目标用户访问权限的安全机制。这些密钥可以由客户管理或 AWS 管理。有关复制作业期间的加密行为（包括复制到逻辑上受物理隔离的保管库），请参阅[复制加密](encryption.md#copy-encryption)。
此外，借助保管库锁定功能，可以更安全地保护备份保管库；逻辑上受物理隔离的保管库配备了合规模式下的保管库锁定功能。
与备份存储库类似，逻辑上的气隙存储库也支持 [Amazon EC2 备份的受限标签](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#tag-restrictions)。
| 功能 | 备份保管库 | 逻辑上受物理隔离的保管库 |
| --- | --- | --- |
| [AWS Backup Audit Manager](aws-backup-audit-manager.md) | 您可以使用 Audi AWS Backup t Manager [控制和修复](controls-and-remediation.md) 来监控您的备份存储库。 | 除了标准存储库可用的控件外，还要确保按照您确定的时间表将特定资源的备份存储在[至少一个逻辑上存在气隙的保管库](controls-and-remediation.md#resources-in-lag-vault-control)中。 |
| [Billing](https://aws.amazon.com/backup/pricing/) | 完全由 AWS Backup 托管的资源的存储和数据传输费用记在“AWS Backup”下。其他资源类型的存储和数据传输费用将记在各自的服务下。 例如，Amazon EBS 备份将显示在“Amazon EBS”下；Amazon S3 备份将显示在“AWS Backup”下。 | 这些保管库的所有账单费用（存储或数据传输）都记在“AWS Backup”下。 |
| [区域](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html#features-by-region) | 在所有 AWS Backup 运营地区均可用 | 在支持的大多数地区都可用 AWS Backup。目前在亚太地区（马来西亚）、加拿大西部（卡尔加里）、墨西哥（中部）、亚太地区（泰国）、亚太地区（台北）、亚太地区（新西兰）、中国（北京）、中国（宁夏） AWS GovCloud 、（美国东部） AWS GovCloud 或（美国西部）不可用。 |
| [资源](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html#supported-resources) | 可以存储大多数支持跨账户复制的资源类型的备份副本。 | 有关可以复制到此保管库的资源，请参阅[按资源划分的功能可用性](backup-feature-availability.md#features-by-resource)中的逻辑上受物理隔离的保管库列。 |
| [还原](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html) | 备份可以由保管库所属的同一个账户进行还原， | 也可以由与其所属账户不同的另一个账户进行还原，但前提是这两个账户共享该保管库。 |
| [安全性](https://docs.aws.amazon.com/aws-backup/latest/devguide/security-considerations.html) | 可以选择使用密钥进行加密（客户管理或 AWS 管理） 可以选择在合规模式或监管模式下使用保管库锁定功能 | 可以使用[AWS 自有密钥或客户管理的密钥](https://docs.aws.amazon.com//kms/latest/developerguide/concepts.html#key-mgmt)进行加密 在合规模式下始终使用[保管库锁定](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html)功能进行锁定 通过 AWS RAM 或 MPA 共享文件库时，加密密钥类型信息会被保留并可见 |
| [共享](#lag-share) | 可以通过策略和 [AWS Organizations](https://docs.aws.amazon.com/aws-backup/latest/devguide/manage-cross-account.html) 管理访问权限 不兼容 AWS RAM | 可以选择使用 [AWS RAM](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html) 跨账户共享 |
## 创建逻辑上受物理隔离的保管库
您可以通过 AWS Backup 控制台或通过 AWS Backup 和 CL AWS RAM I 命令的组合来创建逻辑上隔绝的保管库。
在合规模式下，每个逻辑上受物理隔离的保管库都配有保管库锁定功能。请参阅[AWS Backup 文件库锁](vault-lock.md)，以帮助确定适合运营的保留期值
------
#### [ Console ]
**从控制台创建逻辑气隙保管库**
1. 在 [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) 上打开 AWS Backup 控制台。
1. 在导航窗格中，选择**保管库**。
1. 将显示两种类型的保管库。选择**创建新保管库**。
1. 输入备份保管库的名称。您对保管库的命名可以体现出将要存储在其中的内容，或者便于搜索您所需的备份。例如，您可以将其命名为 `FinancialBackups`。
1. 选择**逻辑上受物理隔离的保管库**所对应的单选按钮。
1. *（可选）*选择加密密钥。您可以选择客户管理的 KMS 密钥来进一步控制加密，也可以使用默认 AWS拥有的密钥（推荐）。
1. 设置**最短保留期**。
此值（以天、月或年为单位）是可以在此保管库中保留备份的最短时间。无法将保留期短于此值的备份复制到此保管库。
允许的最小值为 `7` 天。月数和年数的值满足这一最低要求。
1. 设置**最长保留期**。
此值（以天、月或年为单位）是可以在此保管库中保留备份的最长时间。无法将保留期大于此值的备份复制到此保管库。
1. *（可选）*设置**加密密钥**。
指定要用于保管库的密钥。您可以选择**AWS 拥有的密钥（由管理 AWS Backup）**，也可以为**客户管理的密钥输入 ARN，该密钥**最好属于您有权访问的其他账户。 AWS Backup 建议使用 AWS 自有密钥。
1. *（可选）*添加标签，以帮助您搜索和识别逻辑气隙保管库。例如，您可以添加 `BackupType:Financial` 标签。
1. 选择**创建保管库**。
1. 检查设置。如果所有设置都按预期显示，请选择**创建逻辑气隙保管库**。
1. 控制台将带您进入新保管库的详细信息页面。验证保管库详细信息是否符合预期。
1. 选择**保管库**以查看您账户中的保管库。此时将显示逻辑上受物理隔离的保管库。KMS 密钥将在保管库创建后大约 1 到 3 分钟内可用。刷新页面以查看关联的密钥。一旦密钥可见，保管库即处于可用状态，可供使用。
------
#### [ AWS CLI ]
从 CLI 创建逻辑上受物理隔离的保管库
您可以使用以编程方式 AWS CLI 对逻辑上存在气隙的保管库执行操作。每个 CLI 都特定于其来源的 AWS 服务。与共享相关的命令在前面加上 `aws ram`；所有其他命令都应在前面加上 `aws backup`。
使用 CLI 命令 [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/create-logically-air-gapped-backup-vault.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/create-logically-air-gapped-backup-vault.html)，该命令用以下参数进行了修改：
```
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 密钥。如果未提供，则保管库将使用 AWS拥有的密钥。
用于创建逻辑上受物理隔离的保管库的 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 响应元素](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_CreateLogicallyAirGappedBackupVault.html)。如果操作成功，则新的逻辑上存在气隙的保管库将 VaultState 为。`CREATING`
创建完成并分配 KMS 加密密钥后， VaultState 将转换为`AVAILABLE`。该保管库为可用状态后，即可供使用。可以通过调用 [https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DescribeBackupVault.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DescribeBackupVault.html) 或 [https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListBackupVaults.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListBackupVaults.html) 来检索 `VaultState`。
------
## 查看逻辑上受物理隔离的保管库的详细信息
您可以通过 AWS Backup 控制台或 AWS Backup CLI 查看文件库的详细信息，例如摘要、恢复点、受保护的资源、帐户共享、访问策略和标签。
------
#### [ Console ]
1. 在 [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) 上打开 AWS Backup 控制台。
1. 从左侧导航窗格中，选择**保管库**。
1. 文件库描述下方将列出三个列表：**该账户创建的保管库**、**通过 RAM 共享的保管库以及可通过**多方批准**访问的保管库**。选择所需的选项卡以查看保管库。
1. 在**保管库名称**下，单击保管库名称以打开详细信息页面。您可以查看摘要、恢复点、受保护的资源、账户共享、访问策略和标签详细信息。
详细信息的显示视账户类型而定：拥有保管库的账户可以查看账户共享；不拥有保管库的账户将无法查看账户共享。对于共享文件库，加密密钥类型（AWS由所有或客户管理的 KMS 密钥）显示在文件库摘要中。
------
#### [ AWS CLI ]
通过 CLI 查看逻辑上受物理隔离的保管库的详细信息
CLI 命令 [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/describe-backup-vault.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/describe-backup-vault.html) 可用于获取有关保管库的详细信息。参数 `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"
}
```
**注意**
在逻辑上隔开的保管库不可用的区域，API 响应中不包含该`VaultType`字段。
------
## 在逻辑隔绝的保管库中创建备份
从逻辑上讲，空隙存储库可以是备份计划中的复印任务目标或按需复印作业的目标。它也可以用作主备份目标。请参见[对逻辑气隙存储库的主备份](lag-vault-primary-backup.md)。
**兼容的加密**
要确保成功从备份保管库复制到逻辑上受物理隔离的保管库，需要一个由所复制的资源类型确定的加密密钥。
在创建或复制[完全托管资源类型的](backup-feature-availability.md#features-by-resource)备份时，可以通过客户托管密钥或托管密钥对源资源进行加密。 AWS
创建或复制其他资源类型（[未完全托管的资源）的备份时，必须使用客户管理](backup-feature-availability.md#features-by-resource)的密钥对源进行加密。 AWS 不支持非完全托管资源的托管密钥。
**通过备份计划创建备份或将备份复制到逻辑上空隙的保管库**
您可以通过[创建新的备份计划或在 AWS Backup 控制台中[更新现有](updating-a-backup-plan.md)备份计划或通过 AWS CLI 命令[https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/create-backup-plan.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/create-backup-plan.html)和将备份（恢复点）从标准备份](creating-a-backup-plan.md)保管库复制到逻辑上隔绝的保管库。[https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/update-backup-plan.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/update-backup-plan.html)您也可以将其用作主目标，直接在逻辑上存在气隙的保管库中创建备份。有关更多详细信息，请参阅[对逻辑气隙保管库的主备份](lag-vault-primary-backup.md)。
可以按需将备份从一个逻辑上受物理隔离的保管库复制到另一个逻辑上受物理隔离的保管库（无法在备份计划中安排此类备份）。只要使用客户托管密钥对副本进行加密，就可以将备份从逻辑上受物理隔离的保管库复制到标准备份保管库。
**按需将备份复制到逻辑上受物理隔离的保管库**
要在逻辑上受物理隔离的保管库中创建一次性[按需](recov-point-create-on-demand-backup.md)备份副本，可以从标准备份保管库中进行复制。如果资源类型支持副本类型，则可以使用跨区域或跨账户副本。
**副本可用性**
可以从保管库所属的账户创建备份副本。共享保管库的账户可以查看或还原备份，但不能创建副本。
只能包括[支持跨区域或跨账户复制的资源类型](backup-feature-availability.md#features-by-resource)。
------
#### [ Console ]
1. 在 [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) 上打开 AWS Backup 控制台。
1. 从左侧导航窗格中，选择**保管库**。
1. 在保管库详细信息页面中，将显示该保管库中的所有恢复点。在要复制的恢复点旁边打勾标记。
1. 选择**操作**，然后选择下拉菜单中的**复制**。
1. 在下一个屏幕上，输入目的地详细信息。
1. 指定目标区域。
1. 目的地备份保管库下拉菜单显示符合条件的目的地保管库。按类型 `logically air-gapped vault` 选择一个
1. 将所有详细信息设置为首选项后，选择**复制**。
在控制台的**作业**页面上，您可以选择**复制**作业以查看当前的复制作业。
------
#### [ AWS CLI ]
使用 [start-copy-job](https://amazonaws.com/aws-backup/latest/devguide/API_StartCopyJob.html) 将备份保管库中的现有备份复制到逻辑气隙保管库。
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
```
------
有关更多信息，请参阅[复制备份](https://docs.aws.amazon.com/aws-backup/latest/devguide/recov-point-create-a-copy.html)、[跨区域备份](https://docs.aws.amazon.com/aws-backup/latest/devguide/cross-region-backup.html)和[跨账户备份](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-cross-account-backup.html)。
## 共享逻辑上受物理隔离的保管库
您可以使用 AWS Resource Access Manager (RAM) 与您指定的其他账户共享逻辑上存在气隙的保管库。共享文件库时，加密密钥类型信息（AWS由所有或客户管理的 KMS 密钥）会保留，与之共享保管库的账户可见。
可以与同一组织内的账户共享保管库，也可以与其他组织内的账户共享保管库。不能与整个组织共享保管库，只能与组织内的账户共享。
只有具有特定 IAM 权限的账户才能共享和管理保管库共享。
要使用共享 AWS RAM，请确保您具备以下条件：
+ 两个或更多可以访问的账户 AWS 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](https://console.aws.amazon.com/backup) 上打开 AWS Backup 控制台。
1. 从左侧导航窗格中，选择**保管库**。
1. 保管库描述下方将显示两个列表，即**该账户拥有的保管库**和**与该账户共享的保管库**。该账户拥有的保管库有资格进行共享。
1. 在**保管库名称**下，选择逻辑气隙保管库的名称以打开详细信息页面。
1. **账户共享**窗格显示正在与哪些账户共享保管库。
1. 要开始与其他账户共享或编辑已共享的账户，请选择**管理共享**。
1. 选择 “**管理共享”** 后， AWS RAM 控制台将打开。有关使用 AWS RAM 共享资源的步骤，请参阅 RAM *用户指南*[中的在 AWS RAM 中AWS 创建资源共享](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html)。
1. 受邀接受共享邀请的账户有 12 小时的时间接受邀请。请参阅《AWS RAM 用户指南》**中的[接受和拒绝资源共享邀请](https://docs.aws.amazon.com/ram/latest/userguide/working-with-shared-invitations.html)。
1. 如果共享步骤已完成并被接受，则保管库摘要页面将显示在**账户共享 =“已共享 - 参见下面的账户共享表**”下方。
------
#### [ AWS CLI ]
AWS RAM 使用 CLI 命令`create-resource-share`。只有拥有足够权限的账户才能访问此命令。有关 CLI 步骤，请参阅[在 AWS RAM中创建资源共享](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html)。
第 1 步到第 4 步是使用拥有逻辑气隙保管库的账户执行的。第 5 步到第 8 步是使用将与之共享逻辑气隙保管库的账户执行的。
1. 登录所属账户，或者请求您组织中具有足够凭证的用户访问源账户，完成这些步骤。
1. 如果之前创建了资源共享，且您希望向其添加其他资源，请使用 CLI `associate-resource-share`，而不是新保管库的 ARN。
1. 获取具有足够权限的角色的凭证，以便通过 RAM 进行共享。[将这些输入到 CLI 中](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-quickstart.html#getting-started-quickstart-new)。
1. 此过程需要权限 `ram:CreateResourceShare`。该策略[AWSResourceAccessManagerFullAccess](https://console.aws.amazon.com/iamv2/home?region=us-east-1#/policies/details/arn%3Aaws%3Aiam%3A%3Aaws%3Apolicy%2FAWSResourceAccessManagerFullAccess)包含所有与 RAM 相关的权限。
1. 使用 [create-resource-share](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ram/create-resource-share.html)。
1. 包括逻辑气隙保管库的 ARN。
1. 输入示例：
```
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
```
1. 示例输出：
```
{
"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"
}
}
```
1. 在输出中复制资源共享 ARN（后续步骤需要这样做）。将 ARN 交给您邀请接收共享的账户操作员。
1. 获取资源共享 ARN
1. 如果您没有执行第 1 步 resourceShareArn 到第 4 步，请向执行者索取。
1. 示例：`arn:aws:ram:us-east-1:123456789012:resource-share/12345678-abcd-09876543`
1. 在 CLI 中，假设接收账户的凭证。
1. 通过 [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ram/get-resource-share-invitations.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ram/get-resource-share-invitations.html) 获取资源共享邀请。有关更多信息，请参阅《AWS RAM 用户指南》**中的[接受和拒绝邀请](https://docs.aws.amazon.com/ram/latest/userguide/working-with-shared-invitations.html)。
1. 在目的地（恢复）账户中接受邀请。
1. 使用 [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ram/accept-resource-share-invitation.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ram/accept-resource-share-invitation.html)（也可使用 [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ram/reject-resource-share-invitation.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ram/reject-resource-share-invitation.html)）。
您可以使用 AWS 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`
------
## 从逻辑上受物理隔离的保管库中还原备份
您可以从拥有该保管库的账户或与之共享保管库的任何账户，还原存储在逻辑上受物理隔离的保管库中的备份。
有关如何通过 AWS Backup 控制台还原恢复点的信息，请参阅[还原备份](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html)。
将备份从逻辑上受物理隔离的保管库共享到您的账户后，您可以使用 [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/start-restore-job.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/start-restore-job.html) 来还原备份。
示例 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
```
## 删除逻辑上受物理隔离的保管库
参阅[删除保管库](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-a-vault.html#delete-a-vault)。如果保管库仍包含备份（恢复点），则无法将其删除。在启动删除操作之前，请确保保管库中没有备份。
根据密钥删除策略，保管库删除操作还会在该保管库被删除七天后删除与该保管库关联的密钥。
以下示例 CLI 命令 [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/delete-backup-vault.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/delete-backup-vault.html) 可用于删除保管库。
```
aws backup delete-backup-vault
--region us-east-1
--backup-vault-name testvaultname
```
## 逻辑上受物理隔离的保管库的其他编程选项
可以修改 CLI 命令 [https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListBackupVaults.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListBackupVaults.html)，以列出该账户拥有和存在的所有保管库：
```
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
}
]
}
```
**注意**
在逻辑上隔开的保管库不可用的区域，API 响应中不包含该`VaultType`字段。
## 了解逻辑上存在气隙的保管库的加密密钥类型
从逻辑上讲，气隙保管库支持不同的加密密钥类型，这些信息可通过 AWS Backup APIs 控制台查看。通过 AWS RAM 或 MPA 共享文件库时，会保留加密密钥类型信息，并使与之共享保管库的账户可见。这种透明度有助于您了解保管库的加密配置，并就备份和还原操作做出明智的决策。
### 加密密钥类型值
该`EncryptionKeyType`字段可以有以下值：
+ `AWS_OWNED_KMS_KEY`-保管库使用 AWS自有密钥加密。如果未指定客户管理的密钥，则这是逻辑上空隙保管库的默认加密方法。
+ `CUSTOMER_MANAGED_KMS_KEY`-使用由您控制的客户管理的 KMS 密钥对保管库进行加密。此选项提供了对加密密钥和访问策略的额外控制。
**注意**
AWS Backup 建议将 AWS 拥有的密钥与逻辑上隔开的保管库一起使用。
如果您的组织政策要求使用客户托管密钥，则除了测试之外， AWS 不建议使用来自同一账户的密钥。对于生产工作负载，最佳做法是使用辅助组织中另一个账户的客户托管密钥，专门用于恢复。您可以参考博客 [Encrypt AWS Backup 带有客户管理密钥的逻辑气隙保管库](https://aws.amazon.com/blogs/storage/encrypt-aws-backup-logically-air-gapped-vaults-with-customer-managed-keys/)，以收集有关设置基于 CMK 的逻辑气隙保管库的更多见解。
您只能在创建保管库期间选择 AWS KMS 加密密钥。创建后，保管库中包含的所有备份都将使用该密钥进行加密。您不能更改或迁移您的保管库以使用不同的加密密钥。
### 创建 CMK 加密的逻辑空隙保管库的密钥策略
使用客户托管密钥创建逻辑上隔绝的保管库时，必须将 AWS-managed 策略应用`AWSBackupFullAccess`于您的账户角色。此策略包括 AWS Backup 允许在备份、复制和存储`Allow`操作期间与 AWS KMS KMS 密钥进行交互以创建授权的操作。此外，您必须确保您的客户托管密钥（如果使用）策略包含所需的特定权限。
+ 必须与逻辑上存在气隙的保管库所在的账户共享 CMK
```
{
"Sid": "Allow use of the key to create a logically air-gapped vault",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::[account-id]:role/TheRoleToAccessAccount"
},
"Action": [
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": "backup.*.amazonaws.com"
}
}
}
```
**复制/恢复的密钥策略**
为防止任务失败，请查看您的 AWS KMS 密钥策略，确保其包含所有必需的权限，并且不包含任何可能阻止操作的拒绝语句。以下条件适用：
+ 对于所有复制方案，都 CMKs 必须与源副本角色共享
```
{
"Sid": "Allow use of the key for copy",
"Effect": "Allow",
"Principal": {
"AWS": "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 AWS Backup to create grant on the key for copy",
"Effect": "Allow",
"Principal": {
"AWS": "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": {
"AWS": ["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 AWS Backup to create grant on the key for copy",
"Effect": "Allow",
"Principal": {
"AWS": ["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": {
"AWS": ["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 AWS Backup to create grant on the key for copy",
"Effect": "Allow",
"Principal": {
"AWS": ["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 角色**
在执行逻辑上隔开的保管库复制操作时，客户可以利用包含托 AWS管策略`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 和副本角色提供足够的权限。
### 查看加密密钥类型
您可以通过 AWS Backup 控制台查看加密密钥类型信息，也可以使用 AWS CLI 或 SDKs以编程方式查看加密密钥类型信息。
**控制台：**在控制 AWS Backup 台中查看逻辑上存在气隙的保管库时，加密密钥类型显示在保管库详细信息页面的安全信息部分下。
**AWS 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 密钥。如果未指定，则将使用 AWS拥有的密钥。
+ **共享保管库可见性：**与之共享保管库的账户可以查看加密密钥类型，但不能修改加密配置。
+ **恢复点信息：**在逻辑上存在气隙的保管库中查看恢复点时，也可以使用加密密钥类型。
+ **还原操作：**了解加密密钥类型有助于您规划还原操作并了解任何潜在的访问要求。
+ **合规性：**加密密钥类型信息通过提供用于备份数据的加密方法的透明度，支持合规性报告和审计要求。
## 服务自有密钥的使用
AWS Backup 创建和管理加密密钥，这些密钥用于加密存储在逻辑气隙保管库中的所有备份数据，以保护和防止在数据丢失事件期间丢失对加密密钥的访问权限。
+ 这些密钥是免费的，不计入您账户的 AWS KMS 配额。
+ 单个密钥仅用于特定的保管库，不与任何其他账户或其他目的共享。
+ 一旦分配的（空）保管库也被删除，这些密钥就会被删除。
+ 这些密钥是使用 [SYMMETRIC\$1](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-choose-key-spec.html#symmetric-cmks) DEFAULT 密钥规范创建的。
+ 默认轮换政策为 90 天。您可以通过支持票请求轮换（每 6 个月一次）为逻辑上空隙的保管库轮换（每 6 个月一次）。
请访问[AWS KMS 文档](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html)以了解更多信息。
## 安全自动修复的注意事项
将 EC2 (AMI) 备份 AWS Backup 复制到逻辑上空隙的保管库时，它会暂时`launchPermission`（在 AMI 上）和`createVolumePermission`（在关联的 EBS 快照上）向服务拥有的账户授权。复制完成后，这些权限将自动撤销。
这些操作会在您的 AWS CloudTrail 日志中生成`ModifyImageAttribute``ModifySnapshotAttribute`事件，`userIdentity.invokedBy`设置为`backup.amazonaws.com`。
如果您有用于监控这些事件并撤消跨账户共享的安全自动修复逻辑（例如，Amazon EventBridge 规则 AWS Lambda），则必须将事件排除在外。`userIdentity.invokedBy` `backup.amazonaws.com`否则，将任务复制到逻辑上隔绝的保管库将失败，并显示：“您无权访问此 ami 的存储。”
这种排除是安全的，因为副本由您的文件库访问策略（`backup:CopyFromBackupVault`源文件库和`backup:CopyIntoBackupVault`目标文件库）授权，这些策略将在任何 EC2 属性修改发生之前进行评估。临时权限仅授予固定 AWS 服务拥有的账户，并在复制完成后自动撤销。
排除 AWS 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 to logically air-gapped vault fails with permission error`
**错误**：`Copy job fails with "You do not have permission to access the storage of this ami."`
**可能的原因：**在将 EC2 AMI 复制到逻辑上空隙的保管库的任务中， AWS Backup 临时向服务拥有的账户授予启动权限 (AMI) 和创建卷权限（EBS 快照），从而在日志中生成`ModifyImageAttribute``ModifySnapshotAttribute`事件。 AWS CloudTrail 如果您有安全自动修复逻辑（例如使用 Lambda 的 EventBridge规则）来监控这些事件并自动撤消跨账户共享权限，则它可以在复制完成之前删除临时访问权限。
**注意**
对于其他资源（如 Amazon）的拷贝任务，同样也会发生这种情况 FSx。
**解决方案：**更新您的 EventBridge 规则事件模式以排除由执行的操作 AWS Backup。具体而言，排除事件`userIdentity.invokedBy`是`backup.amazonaws.com`为了确保您的自动修复逻辑不会撤消在复制过程中 AWS Backup 授予的临时跨账户权限。
### `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` 的值。
### 未显示加密密钥类型
**问题：**查看逻辑上存在气隙的保管库或其恢复点时，加密密钥类型不可见。
**可能的原因：**
+ 您正在查看在添加加密密钥类型支持之前创建的较旧保管库
+ 您使用的是 AWS CLI 或 SDK 的旧版本
+ API 响应不包含加密密钥类型字段
**解决方法：**
+ AWS CLI 将你的版本更新到最新版本
+ 对于较旧的保管库，加密密钥类型将自动填充并应出现在后续的 API 调用中
+ 验证您使用的是返回加密密钥类型信息的 API 操作是否正确
+ 对于共享文件库，请验证保管库是否已通过正确共享 AWS Resource Access Manager
### CloudTrail 日志 AccessDeniedException 中 VaultState 有 “失败”
**错误在 CloudTrail：**`"User: 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 权限
**解决方法：**
+ 授予该[创建 CMK 加密的逻辑空隙保管库的密钥策略](#key-policy-lag-vault-creation)部分中指定的权限，然后重试文件库创建工作流程。