本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
逻辑上受物理隔离的保管库
逻辑上受物理隔离的保管库概述
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:开头,则逻辑上受物理隔离的保管库中恢复点的 ARN 将为region::image/ami-*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 控制和修复 来监控您的备份存储库。 | 除了标准保管库可用的控件外,还要确保按照您确定的时间表将特定资源的备份存储在至少一个逻辑上存在气隙的保管库中。 |
完全由 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 文件库锁,以帮助确定适合运营的保留期值
查看逻辑上受物理隔离的保管库的详细信息
您可以通过 Amazon Backup 控制台或 Amazon Backup CLI 查看文件库的详细信息,例如摘要、恢复点、受保护的资源、帐户共享、访问策略和标签。
在逻辑隔绝的保管库中创建备份
从逻辑上讲,空隙存储库可以是备份计划中的复印任务目标或按需复印作业的目标。它也可以用作主备份目标。请参见对逻辑气隙存储库的主备份。
兼容的加密
要确保成功从备份保管库复制到逻辑上受物理隔离的保管库,需要一个由所复制的资源类型确定的加密密钥。
在创建或复制完全托管资源类型的备份时,可以通过客户托管密钥或托管密钥对源资源进行加密。 Amazon
创建或复制其他资源类型(未完全托管的资源)的备份时,必须使用客户管理的密钥对源进行加密。 Amazon 不支持非完全托管资源的托管密钥。
通过备份计划创建备份或将备份复制到逻辑上空隙的保管库
您可以通过创建新的备份计划或在 Amazon Backup
控制台中更新现有备份计划或通过 Amazon CLI 命令create-backup-plan和将备份(恢复点)从标准备份保管库复制到逻辑上隔绝的保管库。update-backup-plan
可以按需将备份从一个逻辑上受物理隔离的保管库复制到另一个逻辑上受物理隔离的保管库(无法在备份计划中安排此类备份)。只要使用客户托管密钥对副本进行加密,就可以将备份从逻辑上受物理隔离的保管库复制到标准备份保管库。
按需将备份复制到逻辑上受物理隔离的保管库
要在逻辑上受物理隔离的保管库中创建一次性按需备份副本,可以从标准备份保管库中进行复制。如果资源类型支持副本类型,则可以使用跨区域或跨账户副本。
副本可用性
可以从保管库所属的账户创建备份副本。共享保管库的账户可以查看或还原备份,但不能创建副本。
只能包括支持跨区域或跨账户复制的资源类型。
共享逻辑上受物理隔离的保管库
您可以使用 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
-
-
至少一个逻辑气隙保管库
从逻辑上受物理隔离的保管库中还原备份
您可以从拥有该保管库的账户或与之共享保管库的任何账户,还原存储在逻辑上受物理隔离的保管库中的备份。
有关如何通过 Amazon Backup 控制台还原恢复点的信息,请参阅还原备份。
将备份从逻辑上受物理隔离的保管库共享到您的账户后,您可以使用 start-restore-job
示例 CLI 输入可能包括以下命令和参数:
aws backup start-restore-job --recovery-point-arnarn: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-nametestvaultname
逻辑上受物理隔离的保管库的其他编程选项
可以修改 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-vaultdescribe-recovery-pointlist-recovery-points-by-backup-vaultlist-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-vaultdescribe-recovery-pointget-recovery-point-restore-metadatalist-protected-resources-by-backup-vaultlist-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 权限
解决方法:
授予该创建 CMK 加密的逻辑空隙保管库的密钥策略部分中指定的权限,然后重试文件库创建工作流程。