翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# のセキュリティ AWS Backup
のクラウドセキュリティが最優先事項 AWS です。お客様は AWS 、セキュリティを最も重視する組織の要件を満たすように構築されたデータセンターとネットワークアーキテクチャを活用できます。
セキュリティは、 AWS とお客様の間の責任共有です。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)では、これをクラウドのセキュリティおよびクラウド内のセキュリティとして説明しています。
+ **クラウドのセキュリティ** – AWS は、 で AWS サービスを実行するインフラストラクチャを保護する責任を担います AWS クラウド。 は、お客様が安全に使用できるサービス AWS も提供します。[「AWS 」 コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)の一環として、サードパーティーの監査が定期的にセキュリティの有効性をテストおよび検証しています。が適用されるコンプライアンスプログラムの詳細については AWS Backup、[AWS 「コンプライアンスプログラムによる対象範囲内のサービス](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。
+ **クラウド内のセキュリティ** – AWS Backup のお客様の責任には以下が含まれますが、これらに限定されるものではありません。また、お客様は、お客様のデータの機密性、組織の要件、および適用可能な法律および規制などの他の要因についても責任を担います。
+ 受信した通信への応答 AWS。
+ 自分とチームが使用する認証情報の管理。詳細については、「 [での Identity and Access Management AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-iam.html)」を参照してください。
+ 組織のデータ保護ポリシーを反映するようにバックアッププランとリソース割り当てを設定します。詳細については、「[バックアッププランの管理](https://docs.aws.amazon.com/aws-backup/latest/devguide/getting-started.html)」を参照してください。
+ 特定のリカバリポイントを見つけてリストアする機能を定期的にテストします。詳細については、「[バックアップの使用](https://docs.aws.amazon.com/aws-backup/latest/devguide/recovery-points.html)」を参照してください。
+ 組織のディザスタリカバリおよびビジネス継続性の書面による AWS Backup 手順に手順を組み込む。開始点については、「[AWS Backupの開始方法](https://docs.aws.amazon.com/aws-backup/latest/devguide/getting-started.html)」を参照してください。
+ 緊急時に、従業員が組織の手順 AWS Backup とともに に精通し、 の使用を実践していることを確認します。詳細については、「[AWS Well-Architected フレームワーク](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)」を参照してください。
このドキュメントは、 を使用する際の責任共有モデルの適用方法を理解するのに役立ちます AWS Backup。以下のトピックでは、セキュリティおよびコンプライアンスの目的を達成する AWS Backup ように を設定する方法を示します。また、 AWS Backup リソースのモニタリングや保護に役立つ他の AWS サービスの使用方法についても説明します。
**Topics**
+ [コンプライアンス検証](backup-compliance.md)
+ [データ保護](data-protection.md)
+ [ID とアクセス管理](backup-iam.md)
+ [インフラストラクチャセキュリティ](infrastructure-security.md)
+ [整合性](backup-integrity.md)
+ [リーガルホールド](legalhold.md)
+ [マルウェア保護](malware-protection.md)
+ [耐障害性](disaster-recovery-resiliency.md)
# のコンプライアンス検証 AWS Backup
AWS のサービス が特定のコンプライアンスプログラムの範囲内にあるかどうかを確認するには、「コンプライアンス[AWS のサービス プログラムによる対象範囲内](https://aws.amazon.com/compliance/services-in-scope/)」の「コンプライアンス」を参照して、関心のあるコンプライアンスプログラムを選択します。一般的な情報については、[AWS 「コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)」を参照してください。
を使用して、サードパーティーの監査レポートをダウンロードできます AWS Artifact。詳細については、[「Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)」を参照してください。
を使用する際のお客様のコンプライアンス責任 AWS のサービス は、お客様のデータの機密性、貴社のコンプライアンス目的、適用される法律および規制によって決まります。を使用する際のコンプライアンス責任の詳細については AWS のサービス、[AWS 「 セキュリティドキュメント](https://docs.aws.amazon.com/security/)」を参照してください。
# でのデータ保護 AWS Backup
AWS Backup は、データ保護に関する規制とガイドラインを含む AWS [責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)に準拠しています。 AWS は、すべての AWS サービスを実行するグローバルインフラストラクチャを保護する責任を担います。 AWS は、顧客コンテンツや個人データを処理するためのセキュリティ設定コントロールなど、このインフラストラクチャでホストされるデータの制御を維持します。データ管理者またはデータ処理者として行動する AWS 顧客と AWS パートナーネットワーク (APN) パートナーは、 に格納された個人データに対して責任を負います AWS クラウド。
データ保護の目的で、 ( AWS Identity and Access Management IAM) を使用して AWS アカウント 認証情報を保護し、個々のユーザーアカウントを設定することをお勧めします。このようにすることで、それぞれの職務を遂行するために必要なアクセス権限のみを各ユーザーに付与することができます。また、次の方法でデータを保護することもお勧めします:
+ 各アカウントで多要素認証 (MFA) を使用します。
+ Secure Sockets Layer (SSL)/Transport Layer Security (TLS) を使用して AWS リソースと通信します。
+ AWS 暗号化ソリューションと、 サービス内のすべての AWS デフォルトのセキュリティコントロールを使用します。
顧客のアカウント番号などの機密の識別情報は、**[名前]** フィールドなどの自由形式のフィールドに配置しないことを強くお勧めします。これは、コンソール、API、または SDK を使用して AWS CLI AWS Backup または他の AWS のサービスを使用する場合も同様です。 AWS SDKs AWS Backup または他のサービスに入力したデータはすべて、診断ログの内容として取得される可能性があります。外部サーバーへの URL を指定するときは、そのサーバーへのリクエストを検証するための認証情報を URL に含めないでください。
データ保護の詳細については、*AWS セキュリティブログ* のブログ投稿「[AWS の責任共有モデルと GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/)」を参照してください。
# でのバックアップの暗号化 AWS Backup
## 独立した 暗号化
AWS Backup は、[フル AWS Backup 管理をサポートするリソースタイプの](backup-feature-availability.md#features-by-resource)独立した暗号化を提供します。独立した暗号化とは、 を介して作成する復旧ポイント (バックアップ) が、ソースリソースの暗号化によって決定されるもの以外の暗号化メソッドを持つ AWS Backup ことができることを意味します。例えば、Amazon S3 バケットのバックアップには、Amazon S3 暗号化で暗号化したソースバケットとは異なる暗号化方式を使用できます。この暗号化は、 にバックアップが保存されているバックアップボールトの AWS KMS キー設定によって制御されます。
によって完全に管理されていないリソースタイプのバックアップは、 AWS Backup 通常、ソースリソースから暗号化設定を継承します。これらの暗号化設定は、「*Amazon EBS ユーザーガイド*」の「[Amazon EBS 暗号化](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html)」など、各サービスの手順に従って設定できます。
IAM ロールは、オブジェクトのバックアップと復元に使用中の KMS キーにアクセスできる必要があります。それ以外の場合、ジョブは成功しますが、オブジェクトはバックアップまたは復元されません。IAM ポリシーと KMS キーポリシーのアクセス許可は一貫している必要があります。詳細については、「*AWS Key Management Service デベロッパーガイド*」の「[IAM ポリシーステートメントで KMS キーを指定する](https://docs.aws.amazon.com/kms/latest/developerguide/cmks-in-iam-policies.html)」を参照してください。
以下の表では、サポートされている各リソースタイプ、バックアップ用の暗号化の設定方法を示しています。また、バックアップ用の独立した暗号化がサポートされているかどうかを示しています。 AWS Backup がバックアップを個別に暗号化する場合、業界標準の AES-256 暗号化アルゴリズムを使用します。での暗号化の詳細については AWS Backup、[「クロスリージョン](cross-region-backup.md)および[クロスアカウントバックアップ](create-cross-account-backup.md)」を参照してください。
| リソースタイプ | 暗号化を設定する方法 | 独立した AWS Backup 暗号化 |
| --- | --- | --- |
| Amazon Simple Storage Service (Amazon S3) | Amazon S3 バックアップは、バックアップボールトに関連付けられた AWS KMS (AWS Key Management Service) キーを使用して暗号化されます。 AWS KMS キーは、カスタマーマネージドキーでも、 AWS Backup サービスに関連付けられた AWSマネージドキーでもかまいません。 は、ソース Amazon S3 バケットが AWS Backup 暗号化されていない場合でも、すべてのバックアップを暗号化します。 | サポート |
| VMware 仮想マシン | VM バックアップは常に暗号化されます。仮想マシンバックアップの AWS KMS 暗号化キーは、仮想マシンバックアップが保存されている AWS Backup ボールトで設定されます。 | サポート |
| [アドバンスト DynamoDB バックアップ](advanced-ddb-backup.md)を有効にした後の Amazon DynamoDB | DynamoDB バックアップは常に暗号化されます。DynamoDB バックアップの AWS KMS 暗号化キーは、DynamoDB バックアップが保存されている AWS Backup ボールトで設定されます。 | サポート |
| [アドバンスト DynamoDB バックアップ](advanced-ddb-backup.md) を有効にしない Amazon DynamoDB | DynamoDB スナップショットは、ソース DynamoDB テーブルの暗号化に使用されたものと同じ暗号化キーで自動的に暗号化されます。暗号化されていない DynamoDB テーブルのスナップショットは引き続き暗号化されません。 AWS Backup が暗号化された DynamoDB テーブルのバックアップを作成するには、バックアップに使用される IAM ロール`kms:GenerateDataKey`にアクセス許可`kms:Decrypt`と を追加する必要があります。または、 AWS Backup デフォルトのサービスロールを使用することもできます。 | 非サポート |
| Amazon Elastic File System (Amazon EFS) | Amazon EFS バックアップは常に暗号化されます。Amazon EFS バックアップの AWS KMS 暗号化キーは、Amazon EFS AWS Backup バックアップが保存されているボールトに設定されます。 | サポート |
| Amazon Elastic Block Store (Amazon EBS) | デフォルトでは、Amazon EBS バックアップは、ソースボリュームの暗号化に使用されたキーを使用して暗号化されるか、暗号化されないかのいずれかです。復元時には、KMS キーを指定してデフォルトの暗号化方法を無効にする選択ができます。 | サポートされていません |
| Amazon Elastic Compute Cloud (Amazon EC2) AMI | AMI は暗号化されていません。EBS スナップショットは、EBS バックアップのデフォルトの暗号化ルールによって暗号化されます (EBS のエントリを参照)。データおよびルートボリュームの EBS スナップショットを暗号化して AMI にアタッチできます。 | サポートされていません |
| Amazon Relational Database Service (Amazon RDS) | Amazon RDS スナップショットは、ソース Amazon RDS データベースの暗号化に使用されたものと同じ暗号化キーで自動的に暗号化されます。暗号化されていない Amazon RDS データベースのスナップショットは引き続き暗号化されません。 | サポートされていません |
| Amazon Aurora | Aurora クラスタースナップショットは、ソース Amazon Auroraーの暗号化に使用されたものと同じ暗号化キーで自動的に暗号化されます。暗号化されていない Aurora クラスターのスナップショットは引き続き暗号化されません。 | サポートされていません |
| AWS Storage Gateway | Storage Gateway スナップショットは、ソース Storage Gateway ボリュームの暗号化に使用されたものと同じ暗号化キーで自動的に暗号化されます。暗号化されていない Storage Gatewayボリュームのスナップショットは引き続き暗号化されません。Storage Gateway を有効化するために、すべてのサービスでカスタマー管理キーを使用する必要はありません。Storage Gateway のバックアップを、KMS キーを設定した保管庫にコピーするだけです。これは、Storage Gateway にサービス固有の AWS KMS マネージドキーがないためです。 | サポートされていません |
| Amazon FSx | Amazon FSx ファイルシステムの暗号化機能は、基盤となるファイルシステムによって異なります。特定の Amazon FSx ファイルシステムの詳細については、[FSx ユーザーガイド](https://docs.aws.amazon.com/fsx/)の該当するサイトを参照してください。 | サポートされていません |
| Amazon DocumentDB | Amazon DocumentDB クラスタースナップショットは、ソース Amazon DocumentDB クラスターの暗号化に使用されたものと同じ暗号化キーで自動的に暗号化されます。暗号化されていない Amazon DocumentDB クラスターのスナップショットは引き続き暗号化されません。 | サポートされていません |
| Amazon Neptune | Neptune クラスタースナップショットは、ソース Neptune クラスターの暗号化に使用されたものと同じ暗号化キーで自動的に暗号化されます。暗号化されていない Neptune クラスターのスナップショットは引き続き暗号化されません。 | サポートされていません |
| Amazon Timestream | Timestream テーブルスナップショットのバックアップは常に暗号化されます。Timestream バックアップの AWS KMS 暗号化キーは、Timestream バックアップが保存されているバックアップボールトに設定されます。 | サポート |
| Amazon Redshift | Amazon Redshift クラスタースナップショットは、ソースの Amazon Redshift クラスターの暗号化に使用されたものと同じ暗号化キーで自動的に暗号化されます。暗号化されていない Amazon Redshift クラスターのスナップショットは引き続き暗号化されません。 | サポートされていません |
| Amazon Redshift Serverless | Redshift Serverless スナップショットは、ソースの暗号化に使用されたものと同じ暗号化キーで自動的に暗号化されます。 | サポートされていません |
| CloudFormation | CloudFormation バックアップは常に暗号化されます。CloudFormation バックアップの CloudFormation 暗号化キーは、CloudFormation バックアップが保存される CloudFormation ボールトに設定されます。 | サポート |
| Amazon EC2 インスタンスでの SAP HANA データベース | SAP HANA データベースのバックアップは常に暗号化されます。SAP HANA データベースバックアップの AWS KMS 暗号化キーは、データベースバックアップが保存されている AWS Backup ボールトで設定されます。 | サポート |
**ヒント**
[AWS Backup Audit Manager](https://docs.aws.amazon.com/aws-backup/latest/devguide/aws-backup-audit-manager.html) は、暗号化されていないバックアップを自動的に検出するのに役立ちます。
## 別のアカウントまたは へのバックアップのコピーの暗号化 AWS リージョン
アカウントまたはリージョン間でバックアップをコピーすると、元のバックアップが暗号化されていない場合でも、 はほとんどのリソースタイプのコピー AWS Backup を自動的に暗号化します。 AWS Backup は、ターゲットボールトの KMS キーを使用してコピーを暗号化します。
あるアカウントから別のアカウント (クロスアカウントコピージョブ) にバックアップをコピーしたり、あるリージョンから別のリージョン (クロスリージョンコピージョブ) にバックアップをコピーしたりする前に、以下の条件に注意してください。その多くは、バックアップのリソースタイプ (復旧ポイント) [が完全に管理されているかどうかによって異なります AWS Backup](backup-feature-availability.md#features-by-resource)。
+ 別の へのバックアップのコピー AWS リージョン は、コピー先ボールトの キーを使用して暗号化されます。
+ **によって完全に管理 AWS Backup**されているリソースの復旧ポイント (バックアップ) のコピーについては、[カスタマーマネージドキー (CMK) または マネージドキー ()](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) を使用して暗号化することを選択できます`aws/backup`。 AWS Backup
によって**完全に管理されていない**リソースの復旧ポイントのコピーの場合 AWS Backup、送信先ボールトに関連付けられたキーは、基盤となるリソースを所有するサービスの CMK またはマネージドキーである必要があります。例えば、EC2 インスタンスをコピーする場合、Backup マネージドキーは使用できません。代わりに、コピージョブの失敗を避けるために、CMK または Amazon EBS KMS キー (`aws/ebs`) を使用する必要があります。
+ AWS マネージドキーを使用したクロスアカウントコピーは、 によって完全に管理されていないリソースではサポートされていません AWS Backup。 AWS 管理キーの[キーポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)はイミュータブルなので、アカウント間でキーがコピーすることはできません。リソースが AWS マネージドキーで暗号化されており、クロスアカウントコピーを実行する場合は、[暗号化キー](https://repost.aws/knowledge-center/update-encryption-key-rds)をカスタマーマネージドキーに変更して、クロスアカウントコピーに使用できます。または、[「クロスアカウントバックアップとクロスリージョンバックアップを使用して暗号化された Amazon RDS インスタンスを保護する](https://aws.amazon.com/blogs/storage/protecting-encrypted-amazon-rds-instances-with-cross-account-and-cross-region-backups/)」の手順に従って、 AWS マネージドキーを引き続き使用できます。
+ Amazon Aurora クラスター、Amazon DocumentDB クラスター、Amazon Neptune クラスターが暗号化されていない場合、そのコピーも暗号化されません。
## AWS Backup アクセス許可、許可、拒否ステートメント
失敗したジョブを回避するには、 AWS KMS キーポリシーを調べて、必要なアクセス許可があり、オペレーションの成功を妨げる拒否ステートメントがないことを確認します。
ジョブの失敗は、KMS キーに適用された 1 つ以上の拒否ステートメント、またはキーの[許可](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)が取り消されたことによって発生する可能性があります。
などの AWS マネージドアクセスポリシーでは[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupFullAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupFullAccess.html)、 が とインターフェイス AWS KMS して、バックアップ、コピー、ストレージオペレーションの一部として、お客様に代わって KMS キーに許可を作成することを許可 AWS Backup するアクションがあります。
このキーポリシーには少なくとも次のアクセス許可が必要です。
+ `kms:createGrant`
+ `kms:generateDataKey`
+ `kms:decrypt`
拒否ポリシーが必要な場合は、バックアップおよび復元オペレーションに必要なロールを許可リストに登録する必要があります。
これらの要素は、次のようになります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "KmsPermissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": [
"kms:ListKeys",
"kms:DescribeKey",
"kms:GenerateDataKey",
"kms:ListAliases"
],
"Resource": "*"
},
{
"Sid": "KmsCreateGrantPermissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": [
"kms:CreateGrant"
],
"Resource": "*",
"Condition": {
"ForAnyValue:StringEquals": {
"kms:EncryptionContextKeys": "aws:backup:backup-vault"
},
"Bool": {
"kms:GrantIsForAWSResource": true
},
"StringLike": {
"kms:ViaService": "backup.*.amazonaws.com"
}
}
}
]
}
```
------
これらのアクセス許可は、 AWS 管理かカスタマー管理かにかかわらず、 キーの一部である必要があります。
1. 必要なアクセス許可が KMS キーポリシーの一部であることを確認します。
1. KMS CLI `get-key-policy` ([https://docs.aws.amazon.com/kms/latest/APIReference/API_GetKeyPolicy.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_GetKeyPolicy.html)) を実行して、指定された KMS キーにアタッチされたキーポリシーを表示します。
1. 返されたアクセス許可を確認します。
1. オペレーションに影響する拒否ステートメントがないことを確認します。
1. CLI `get-key-policy` ([https://docs.aws.amazon.com/kms/latest/APIReference/API_GetKeyPolicy.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_GetKeyPolicy.html)) を実行 (または再実行) して、指定された KMS キーにアタッチされたキーポリシーを表示します。
1. ポリシーを確認します。
1. KMS キーポリシーから関連する拒否ステートメントを削除します。
1. 必要に応じて、[https://docs.aws.amazon.com/kms/latest/APIReference/API_PutKeyPolicy.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_PutKeyPolicy.html) を実行して、キーポリシーを改訂されたアクセス許可に置き換えるか更新し、拒否ステートメントを削除します。
さらに、クロスリージョンコピージョブを開始するロールに関連付けられたキーは、`DescribeKey` アクセス許可に `"kms:ResourcesAliases": "alias/aws/backup"` を含める必要があります。
# 仮想マシンのハイパーバイザー認証情報の暗号化
[ハイパーバイザーによって管理](https://docs.aws.amazon.com//aws-backup/latest/devguide/working-with-hypervisors.html)される仮想マシンは、[AWS Backup Gateway](https://docs.aws.amazon.com/aws-backup/latest/devguide/working-with-gateways.html) を使用してオンプレミスシステムを AWS Backupに接続します。ハイパーバイザーも同じように堅牢で信頼性の高いセキュリティを備えていることが重要です。このセキュリティは、 AWS 所有キーまたはカスタマーマネージドキーのいずれかでハイパーバイザーを暗号化することで実現できます。
## AWS 所有キーとカスタマーマネージドキー
AWS Backup は、ハイパーバイザー認証情報の暗号化を提供し、**AWS 所有の**暗号化キーを使用して顧客の機密ログイン情報を保護します。代わりに**カスタマーマネージドキー**を使用することもできます。
デフォルトでは、ハイパーバイザーの認証情報の暗号化に使用されるキーは**AWS 所有キー**です。 はこれらのキー AWS Backup を使用して、ハイパーバイザーの認証情報を自動的に暗号化します。 AWS 所有キーを表示、管理、使用することも、その使用を監査することもできません。ただし、データを暗号化するキーを保護するためのアクションの実施やプログラムの変更を行う必要はありません。詳細については、「 [https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt)」の AWS 「 所有キー」を参照してください。
または、*カスタマーマネージドキー*を使用して認証情報を暗号化することもできます。 AWS Backup は、暗号化を実行するための、ユーザーが作成、所有、管理する、対称型のカスタマーマネージドキーの使用をサポートします。この暗号化を完全に制御できるため、次のようなタスクを実行できます。
+ キーポリシーの策定と維持
+ IAM ポリシーとグラントの策定と維持
+ キーポリシーの有効化と無効化
+ キー暗号化マテリアルのローテーション
+ タグを追加する
+ キーエイリアスの作成
+ 削除のためのキースケジューリング
カスタマーマネージドキーを使用する場合、 は、ロールにこのキーを使用して復号するアクセス許可があるかどうか AWS Backup を検証します (バックアップジョブまたは復元ジョブが実行される前に）。バックアップまたは復元ジョブの開始に使用するロールに `kms:Decrypt` アクションを追加する必要があります。
`kms:Decrypt` アクションはデフォルトのバックアップロールには追加できないため、カスタマーマネージドキーを使用するにはデフォルトのバックアップロール以外のロールを使用する必要があります。
詳細については、「**AWS Key Management Service デベロッパーガイド」の「[カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)」を参照してください。
## カスタマーマネージドキーを使用する場合に必要な許可
AWS KMS には、カスタマーマネージドキーを使用するための[許可](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)が必要です。カスタマーマネージドキーで暗号化された[ハイパーバイザー設定](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_ImportHypervisorConfiguration.html)をインポートすると、 は[https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html)リクエストを に送信してユーザーに代わって許可 AWS Backup を作成します AWS KMS。 は、お客様のアカウントの KMS キーにアクセスするための許可 AWS Backup を使用します。
許可へのアクセスを取り消すことも、カスタマーマネージドキー AWS Backupへのアクセスを削除することもできます。その場合、ハイパーバイザーに関連付けられているすべてのゲートウェイは、カスタマーマネージドキーで暗号化されたハイパーバイザーのユーザー名とパスワードにアクセスできなくなり、バックアップジョブと復元ジョブに影響します。具体的には、このハイパーバイザー内の仮想マシンで実行するバックアップジョブと復元ジョブは失敗します。
ハイパーバイザーを削除するときに、バックアップゲートウェイは `RetireGrant` 操作を使用して許可を削除します。
## 暗号化キーのモニタリング
AWS Backup リソースで AWS KMS カスタマーマネージドキーを使用する場合、 [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)または [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) を使用して、 が AWS Backup に送信するリクエストを追跡できます AWS KMS。
カスタマーマネージドキーによって暗号化されたデータにアクセスするために によって呼び出されるモニタリング AWS KMS オペレーションで AWS Backup 、 に次の`"eventName"`フィールドがある AWS CloudTrail イベントを探します。
+ `"eventName": "CreateGrant"`
+ `"eventName": "Decrypt"`
+ `"eventName": "Encrypt"`
+ `"eventName": "DescribeKey"`
# での ID とアクセスの管理 AWS Backup
にアクセスするには、 認証情報 AWS Backup が必要です。これらの認証情報には、Amazon DynamoDB インスタンスや Amazon EFS ファイルシステムなどの AWS リソースに対するアクセス許可が含まれている必要があります。さらに、一部の AWS Backupサポートされているサービス AWS Backup に対して によって作成された復旧ポイントは、ソースサービス (Amazon EFS など) を使用して削除できません。これらの復旧ポイントは、 を使用して削除できます AWS Backup。
以下のセクションでは、 [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) と AWS Backup を使用して リソースへの安全なアクセスを支援する方法について詳しく説明します。
**警告**
AWS Backup は、リカバリポイントのライフサイクルを管理するためにリソースを割り当てるときに選択したのと同じ IAM ロールを使用します。そのロールを削除または変更した場合、 AWS Backup は復旧ポイントのライフサイクルを管理できません。この場合、サービスにリンクされたロールを使用して、ライフサイクルを管理しようとします。ごく一部のケースでは、これがうまくいかず、ストレージ上に `EXPIRED` リカバリポイントを残し、不要なコストが発生する可能性があります。`EXPIRED` リカバリポイントを削除するには、[バックアップの削除](https://docs.aws.amazon.com/aws-backup/latest/devguide/deleting-backups.html)の手順を使用して手動で削除してください。
**Topics**
+ [認証](authentication.md)
+ [アクセスコントロール](access-control.md)
+ [IAM サービスロール](iam-service-roles.md)
+ [の管理ポリシー AWS Backup](security-iam-awsmanpol.md)
+ [のサービスにリンクされたロールの使用 AWS Backup](using-service-linked-roles.md)
+ [サービス間の混乱した代理の防止](cross-service-confused-deputy-prevention.md)
# 認証
AWS Backup またはバックアップする AWS サービスにアクセスするには、 がリクエストの認証 AWS に使用できる認証情報が必要です。には、次のいずれかのタイプの ID AWS としてアクセスできます。
+ **AWS アカウント ルートユーザー** – にサインアップするときに AWS、アカウント AWS に関連付けられた E メールアドレスとパスワードを指定します。これは *AWS アカウント のルートユーザー*です。その認証情報は、すべての AWS リソースへの完全なアクセスを提供します。
**重要**
セキュリティ上の理由から、*管理者*を作成する場合にのみルートユーザーを使用することをお勧めします。管理者は、 AWS アカウントに対する完全なアクセス許可を持つ *IAM ユーザー*です。この管理者ユーザーを使用して、制限された許可を持つ他の IAM ユーザーとロールを作成できます。詳細については、*IAM ユーザーガイド*の「[IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#create-iam-users)」および「[最初の IAM 管理者のユーザーおよびグループの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html)」を参照してください。
+ **IAM ユーザー** – [IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)は、 AWS アカウント 内で特定のカスタムアクセス許可 (バックアップ保存用のバックアップ保管庫を作成するためのアクセス許可など) を持つアイデンティティです。IAM ユーザー名とパスワードを使用して、、 [AWS ディスカッションフォーラム](https://forums.aws.amazon.com/)[AWS マネジメントコンソール](https://console.aws.amazon.com/)、 [AWS サポート センター](https://console.aws.amazon.com/support/home#/)などの安全な AWS ウェブページにサインインできます。
ユーザー名とパスワードに加えて、各ユーザーの[アクセスキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)を作成することもできます。これらのキーは、[複数の SDKs のいずれか](https://aws.amazon.com/developer/tools/)を介して、または [AWS Command Line Interface (AWS CLI)](https://aws.amazon.com/cli/) を使用して、プログラムで AWS サービスにアクセスするときに使用できます。SDK と AWS CLI ツールでは、アクセスキーを使用してリクエストが暗号で署名されます。 AWS ツールを使用しない場合は、リクエストを自分で署名する必要があります。リクエストの認証の詳細については、『[』の「](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html)署名バージョン 4 の署名プロセス*AWS 全般のリファレンス*」を参照してください。
+ **IAM ロール** - [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)は、アカウントで作成して特定のアクセス許可を付与できるもうひとつの IAM アイデンティティです。これは IAM ユーザーに似ていますが、特定のユーザーに関連付けられていません。IAM ロールを使用すると、 AWS サービスとリソースへのアクセスに使用できる一時的なアクセスキーを取得できます。IAM ロールと一時的な認証情報は、次の状況で役立ちます:
+ フェデレーティッドユーザーアクセス – IAM ユーザーを作成する代わりに、 Directory Service、エンタープライズユーザーディレクトリ、またはウェブ ID プロバイダーから既存のユーザー ID を使用できます。このようなユーザーはフェデレーションユーザーと呼ばれます。 AWS では、[ID プロバイダー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)を通じてアクセスがリクエストされたとき、フェデレーションユーザーにロールを割り当てます。フェデレーティッドユーザーの詳細については、「*IAM ユーザーガイド*」の「[フェデレーティッドユーザーとロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_access-management.html#intro-access-roles)」を参照してください。
+ クロスアカウント管理 – アカウントの IAM ロールを使用して、アカウントのリソースを管理するための別の AWS アカウント アクセス許可を付与できます。例については、IAM *ユーザーガイド*の[「チュートリアル: IAM ロール AWS アカウント を使用した 間のアクセスの委任](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)」を参照してください。
+ AWS サービスアクセス – アカウントの IAM ロールを使用して、アカウントのリソースにアクセスするための AWS サービスアクセス許可を付与できます。詳細については、*IAM ユーザーガイド*の[「 AWS サービスにアクセス許可を委任するロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)」を参照してください。
+ Amazon Elastic Compute Cloud (Amazon EC2) で実行されているアプリケーション – IAM ロールを使用して、Amazon EC2 インスタンスで実行され、 AWS API リクエストを行うアプリケーションの一時的な認証情報を管理できます。これは、EC2 インスタンス内でのアクセスキーの保存に推奨されます。EC2 インスタンスに AWS ロールを割り当て、そのすべてのアプリケーションで使用できるようにするには、インスタンスにアタッチされたインスタンスプロファイルを作成します。インスタンスプロファイルにはロールが含まれ、EC2 インスタンスで実行されるプログラムは一時認証情報を取得することができます。詳細については、*IAM ユーザーガイド*の「[Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用して権限を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)」を参照してください。
# アクセスコントロール
リクエストを認証するための有効な認証情報を持つことができますが、適切なアクセス許可がない限り、バックアップボールトなどの AWS Backup リソースにアクセスすることはできません。Amazon Elastic Block Store (Amazon EBS) ボリュームなどの AWS リソースをバックアップすることもできません。
すべての AWS リソースは によって所有され AWS アカウント、リソースを作成またはアクセスするアクセス許可はアクセス許可ポリシーによって管理されます。アカウント管理者は、 AWS Identity and Access Management (IAM) ID (ユーザー、グループ、ロール) にアクセス許可ポリシーをアタッチできます。また、一部のサービスでは、アクセス権限ポリシーをリソースにアタッチすることができます。
アカウント管理者 (または管理者ユーザー) は、管理者アクセス許可を持つユーザーです。詳細については、「IAM ユーザーガイド 」の「[IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。
アクセス許可を付与する場合、アクセス許可を取得するユーザー、取得するアクセス許可の対象となるリソース、およびそれらのリソースに対して許可される特定のアクションを決定します。
以下のセクションでは、アクセスポリシーのしくみと、それらのポリシーを使用してバックアップを保護する方法について説明します。
**Topics**
+ [リソースおよびオペレーション](#access-control-resources)
+ [リソース所有権](#access-control-owner)
+ [ポリシー要素 (アクション、効果、プリンシパル) の指定](#access-control-specify-backup-actions)
+ [ポリシーでの条件の指定](#specifying-conditions)
+ [API のアクセス許可: アクション、リソース、条件リファレンス](#backup-api-permissions-ref)
+ [タグ権限のコピー](#copy-tags)
+ [アクセスポリシー](#access-policies)
## リソースおよびオペレーション
リソースは、サービス内に存在するオブジェクトです。 AWS Backup リソースには、バックアッププラン、バックアップボールト、バックアップが含まれます。*Backup* は、 に存在するさまざまなタイプのバックアップリソースを指す一般的な用語です AWS。たとえば、Amazon EBS スナップショット、Amazon Relational Database Service (Amazon RDS) スナップショット、および Amazon DynamoDB バックアップはすべて、バックアップリソースのタイプです。
では AWS Backup、バックアップは*復旧ポイント*とも呼ばれます。を使用する場合は AWS Backup、Amazon EBS ボリュームや DynamoDB テーブルなど、保護しようとしている他の AWS サービスのリソースも操作します。これらのリソースには、一意の Amazon リソースネーム (ARN) が関連付けられています。ARNs AWS リソースを一意に識別します。IAM ポリシーや API コールなど、すべての AWSでリソースを明確に指定する必要がある場合は、ARN が必要です。
以下の表では、リソース、サブリソース、ARN 形式、および一意の ID の例を示しています。
**AWS Backup リソース ARNs**
| リソースタイプ | ARN 形式 | 一意の ID の例 |
| --- | --- | --- |
| バックアッププラン | arn:aws:backup:region:account-id:backup-plan:\$1 | |
| バックアップボールト | arn:aws:backup:region:account-id:backup-vault:\$1 | |
| Amazon EBS の復旧ポイント | arn:aws:ec2:region::snapshot/\$1 | snapshot/snap-05f426fd8kdjb4224 |
| Amazon EC2 の復旧ポイントのイメージ | arn:aws:ec2:region::image/ami-\$1 | image/ami-1a2b3e4f5e6f7g890 |
| Amazon RDS の復旧ポイント | arn:aws:rds:region:account-id:snapshot:awsbackup:\$1 | awsbackup:job-be59cf2a-2343-4402-bd8b-226993d23453 |
| Aurora の復旧ポイント | arn:aws:rds:region:account-id:cluster-snapshot:awsbackup:\$1 | awsbackup:job-be59cf2a-2343-4402-bd8b-226993d23453 |
| Aurora DSQL の復旧ポイント | arn:aws-partition:backup:region:account-id:recovery-point:recovery-point-id | arn:aws:backup:us-east-1:012345678901:recovery-point:8a92c3f1-b475-4d9e-95e6-7c138f2d4b0a |
| Storage Gateway の復旧ポイント | arn:aws:ec2:region::snapshot/\$1 | snapshot/snap-0d40e49137e31d9e0 |
| [アドバンスト DynamoDB バックアップ](advanced-ddb-backup.md) なしの DynamoDB の復旧ポイント | arn:aws:dynamodb:region:account-id:table/\$1/backup/\$1 | table/MyDynamoDBTable/backup/01547087347000-c8b6kdk3 |
| [アドバンスト DynamoDB バックアップ](advanced-ddb-backup.md) が有効な DynamoDB の復旧ポイント | arn:aws:backup:region:account-id:recovery-point:\$1 | 12a34a56-7bb8-901c-cd23-4567d8e9ef01 |
| Amazon EFS の復旧ポイント | arn:aws:backup:region:account-id:recovery-point:\$1 | d99699e7-e183-477e-bfcd-ccb1c6e5455e |
| Amazon FSx の復旧ポイント | arn:aws:fsx:region:account-id:backup/backup-\$1 | backup/backup-1a20e49137e31d9e0 |
| 仮想マシンの復旧ポイント | arn:aws:backup:region:account-id:recovery-point:\$1 | 1801234a-5b6b-7dc8-8032-836f7ffc623b |
| Amazon S3 継続的バックアップの復旧ポイント | arn:aws:backup:region:account-id:recovery-point:\$1 | amzn-s3-demo-bucket-5ec207d0 |
| S3 定期バックアップのリカバリポイント | arn:aws:backup:region:account-id:recovery-point:\$1 | amzn-s3-demo-bucket-20211231900000-5ec207d0 |
| Amazon DocumentDB の復旧ポイント | arn:aws:rds:region:account-id:cluster-snapshot:awsbackup:\$1 | awsbackup:job-ab12cd3e-4567-8901-fg1h-234567i89012 |
| Neptune の復旧ポイント | arn:aws:rds:region:account-id:cluster-snapshot:awsbackup:\$1 | awsbackup:job-ab12cd3e-4567-8901-fg1h-234567i89012 |
| Amazon Redshift の復旧ポイント | arn:aws:redshift:region:account-id:snapshot:resource/awsbackup:\$1 | awsbackup:job-ab12cd3e-4567-8901-fg1h-234567i89012 |
| Amazon Redshift Serverless の復旧ポイント | arn:aws:redshift-serverless:region:account-id:snapshot:resource/awsbackup:\$1 | awsbackup:job-ab12cd3e-4567-8901-fg1h-234567i89012 |
| Amazon Timestream の復旧ポイント | arn:aws:backup:region:account-id:recovery-point:\$1 | recovery-point:1a2b3cde-f405-6789-012g-3456hi789012\$1beta |
| AWS CloudFormation テンプレートの復旧ポイント | arn:aws:backup:region:account-id:recovery-point:\$1 | recovery-point:1a2b3cde-f405-6789-012g-3456hi789012 |
| Amazon EC2 インスタンス上の SAP HANA データベースの復旧ポイント | arn:aws:backup:region:account-id:recovery-point:\$1 | recovery-point:1a2b3cde-f405-6789-012g-3456hi789012 |
フル AWS Backup 管理をサポートするリソースには、すべて 形式の復旧ポイントがあります`arn:aws:backup:region:account-id::recovery-point:*`。 を使用すると、これらの復旧ポイントを保護するためのアクセス許可ポリシーを簡単に適用できます。フル AWS Backup 管理をサポートするリソースを確認するには、[リソース別の機能の可用性](backup-feature-availability.md#features-by-resource)表の セクションを参照してください。
AWS Backup には、 AWS Backup リソースを操作するための一連のオペレーションが用意されています。使用可能なオペレーションのリストについては、「 AWS Backup [アクション](API_Operations.md)」を参照してください。
## リソース所有権
は、リソースを作成したユーザーに関係なく、アカウントで作成されたリソース AWS アカウント を所有します。具体的には、リソース所有者は、リソース作成リクエスト AWS アカウント を認証する[プリンシパルエンティティ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts) ( AWS アカウント ルートユーザー、IAM ユーザー、または IAM ロール) の です。次の例は、この仕組みを示しています。
+ の AWS アカウント ルートユーザー認証情報を使用してバックアップボールト AWS アカウント を作成する場合、 AWS アカウント はボールトの所有者です。
+ で IAM ユーザーを作成し AWS アカウント 、そのユーザーにバックアップボールトを作成するアクセス許可を付与すると、そのユーザーはバックアップボールトを作成できます。ただし、バックアップ保管庫リソースを所有しているのは、このユーザーが属する AWS です。
+ バックアップボールトを作成するアクセス許可 AWS アカウント を持つ で IAM ロールを作成する場合、ロールを引き受けることのできるすべてのユーザーがボールトを作成できます。ロールが属 AWS アカウントする は、バックアップボールトリソースを所有します。
## ポリシー要素 (アクション、効果、プリンシパル) の指定
サービスは AWS Backup 、リソースごとに API オペレーションのセットを定義します (「」を参照[リソースおよびオペレーション](#access-control-resources))[アクション](API_Operations.md)。これらの API オペレーションのアクセス許可を付与するために、 はポリシーで指定できる一連のアクション AWS Backup を定義します。1 つの API オペレーションの実行で、複数のアクションのアクセス権限が必要になる場合があります。
最も基本的なポリシーの要素を次に示します。
+ リソース– ポリシーで Amazon リソースネーム (ARN) を使用して、ポリシーを適用するリソースを識別します。詳細については、「[リソースおよびオペレーション](#access-control-resources)」を参照してください。
+ アクション – アクションキーワードを使用して、許可または拒否するリソース操作を特定します。
+ 効果 – ユーザーが特定のアクションを要求する際の効果を指定します。許可または拒否のいずれかになります。リソースへのアクセスを明示的に付与 (許可) していない場合、アクセスは暗黙的に拒否されます。また、明示的にリソースへのアクセスを拒否すると、別のポリシーによってアクセスが許可されている場合でも、ユーザーはそのリソースにアクセスできなくなります。
+ プリンシパル - ID ベースのポリシー (IAM ポリシー) で、ポリシーがアタッチされているユーザーが黙示的なプリンシパルとなります。リソースベースのポリシーでは、アクセス許可 (リソースベースのポリシーにのみ適用) を受け取りたいユーザー、アカウント、サービス、またはその他のエンティティを指定します。
IAM ポリシーの構文と記述の詳細については、IAM ユーザーガイドの「[IAM JSON ポリシーのリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html)」を参照してください。
すべての AWS Backup API アクションを示す表については、「」を参照してください[API のアクセス許可: アクション、リソース、条件リファレンス](#backup-api-permissions-ref)。
## ポリシーでの条件の指定
許可を付与するとき、IAM ポリシー言語を使用して、ポリシーが有効になる必要がある条件を指定できます。例えば、特定の日付の後にのみ適用されるポリシーが必要になる場合があります。ポリシー言語での条件の指定の詳細については、「*IAM ユーザーガイド*」の「[条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)」を参照してください。
AWS は、グローバル条件キーとサービス固有の条件キーをサポートしています。すべてのグローバル条件キーを確認するには、「*IAM ユーザーガイド*」の「[AWS グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)」を参照してください。
AWS Backup は、独自の条件キーのセットを定義します。 AWS Backup 条件キーのリストを確認するには、*「サービス認可リファレンス*」の「 [の条件キー AWS Backup](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsbackup.html#awsbackup-policy-keys)」を参照してください。
## API のアクセス許可: アクション、リソース、条件リファレンス
[アクセスコントロール](#access-control) をセットアップし、IAM アイデンティティにアタッチできるアクセス権限ポリシー (アイデンティティベースのポリシー) を作成するときは、以下のテーブルをリファレンスとして使用できます。テーブルリスト、各 AWS Backup API オペレーション、アクションを実行するためのアクセス許可を付与できる対応するアクション、およびアクセス許可を付与できる AWS リソースが含まれます。ポリシーの `Action` フィールドでアクションを指定し、ポリシーの `Resource` フィールドでリソースの値を指定します。`Resource` フィールドが空白の場合は、ワイルドカード (`*`) を使用してすべてのリソースを含めることができます。
AWS Backup ポリシーで AWS全体の条件キーを使用して、条件を表現できます。 AWS全体のキーの完全なリストについては、*IAM ユーザーガイド*の[「使用可能なキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#AvailableKeys)」を参照してください。
スクロールバーを使用して、テーブルの残りの部分を確認します。
**AWS Backup API とアクションに必要なアクセス許可**
| AWS Backup API オペレーション | 必要な許可 (API アクション) | リソース |
| --- | --- | --- |
| [CreateBackupPlan](API_CreateBackupPlan.md) | backup:CreateBackupPlan | arn:aws:backup:region:account-id:backup-plan:\$1 |
| [CreateBackupSelection](API_CreateBackupSelection.md) | backup:CreateBackupSelection | arn:aws:backup:region:account-id:backup-plan:\$1 |
| [CreateBackupVault](API_CreateBackupVault.md) | `backup:CreateBackupVault` `backup-storage:MountCapsule` `kms:CreateGrant` `kms:GenerateDataKey` `kms:Decrypt` `kms:RetireGrant` `kms:DescribeKey` | arn:aws:backup:region:account-id:backup-vault:\$1 `backup-storage` の場合: \$1 `kms` の場合: `arn:aws:kms:region:account-id:key/keystring` |
| [DeleteBackupPlan](API_DeleteBackupPlan.md) | backup:DeleteBackupPlan | arn:aws:backup:region:account-id:backup-plan:\$1 |
| [DeleteBackupSelection](API_DeleteBackupSelection.md) | backup:DeleteBackupSelection | arn:aws:backup:region:account-id:backup-plan:\$1 |
| [DeleteBackupVault](API_DeleteBackupVault.md) | backup:DeleteBackupVault 1 | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [DeleteBackupVaultAccessPolicy](API_DeleteBackupVaultAccessPolicy.md) | backup:DeleteBackupVaultAccessPolicy | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [DeleteBackupVaultNotifications](API_DeleteBackupVaultNotifications.md) | backup:DeleteBackupVaultNotifications 1 | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [DeleteRecoveryPoint](API_DeleteRecoveryPoint.md) | backup:DeleteRecoveryPoint 1 | 2 |
| [DescribeBackupJob](API_DescribeBackupJob.md) | backup:DescribeBackupJob | |
| [DescribeBackupVault](API_DescribeBackupVault.md) | backup:DescribeBackupVault 1 | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [DescribeProtectedResource](API_DescribeProtectedResource.md) | backup:DescribeProtectedResource | |
| [DescribeRecoveryPoint](API_DescribeRecoveryPoint.md) | backup:DescribeRecoveryPoint 1 | arn:aws:backup:region:account-id:backup-vault:\$1 2 |
| [DescribeRestoreJob](API_DescribeRestoreJob.md) | backup:DescribeRestoreJob | |
| [DescribeRegionSettings](API_DescribeRegionSettings.md) | backup:DescribeRegionSettings | |
| [ExportBackupPlanTemplate](API_ExportBackupPlanTemplate.md) | backup:ExportBackupPlanTemplate | |
| [GetBackupPlan](API_GetBackupPlan.md) | backup:GetBackupPlan | arn:aws:backup:region:account-id:backup-plan:\$1 |
| [GetBackupPlanFromJSON](API_GetBackupPlanFromJSON.md) | backup:GetBackupPlanFromJSON | |
| [GetBackupPlanFromTemplate](API_GetBackupPlanFromTemplate.md) | backup:GetBackupPlanFromTemplate | arn:aws:backup:region:account-id:backup-plan:\$1 |
| [GetBackupSelection](API_GetBackupSelection.md) | backup:GetBackupSelection | arn:aws:backup:region:account-id:backup-plan:\$1 |
| [GetBackupVaultAccessPolicy](API_GetBackupVaultAccessPolicy.md) | backup:GetBackupVaultAccessPolicy 1 | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [GetBackupVaultNotifications](API_GetBackupVaultNotifications.md) | backup:GetBackupVaultNotifications 1 | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [GetRecoveryPointRestoreMetadata](API_GetRecoveryPointRestoreMetadata.md) | backup:GetRecoveryPointRestoreMetadata 1 | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [GetSupportedResourceTypes](API_GetSupportedResourceTypes.md) | backup:GetSupportedResourceTypes | |
| [ListBackupJobs](API_ListBackupJobs.md) | backup:ListBackupJobs | |
| [ListBackupPlans](API_ListBackupPlans.md) | backup:ListBackupPlans | |
| [ListBackupPlanTemplates](API_ListBackupPlanTemplates.md) | backup:ListBackupPlanTemplates | |
| [ListBackupPlanVersions](API_ListBackupPlanVersions.md) | backup:ListBackupPlanVersions | arn:aws:backup:region:account-id:backup-plan:\$1 |
| [ListBackupSelections](API_ListBackupSelections.md) | backup:ListBackupSelections | arn:aws:backup:region:account-id:backup-plan:\$1 |
| [ListBackupVaults](API_ListBackupVaults.md) | backup:ListBackupVaults | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [ListProtectedResources](API_ListProtectedResources.md) | backup:ListProtectedResources | |
| [ListRecoveryPointsByBackupVault](API_ListRecoveryPointsByBackupVault.md) | backup:ListRecoveryPointsByBackupVault 1 | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [ListRecoveryPointsByResource](API_ListRecoveryPointsByResource.md) | backup:ListRecoveryPointsByResource | |
| [ListRestoreJobs](API_ListRestoreJobs.md) | backup:ListRestoreJobs | |
| [ListTags](API_ListTags.md) | backup:ListTags | |
| [PutBackupVaultAccessPolicy](API_PutBackupVaultAccessPolicy.md) | backup:PutBackupVaultAccessPolicy 1 | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [PutBackupVaultLockConfiguration](API_PutBackupVaultLockConfiguration.md) | backup:PutBackupVaultLockConfiguration 1 | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [PutBackupVaultNotifications](API_PutBackupVaultNotifications.md) | backup:PutBackupVaultNotifications 1 | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [StartBackupJob](API_StartBackupJob.md) | backup:StartBackupJob | arn:aws:backup:region:account-id:backup-vault:\$1 |
| [StartRestoreJob](API_StartRestoreJob.md) | backup:StartRestoreJob | `arn:aws:backup:region:account-id:backup-vault:*` `arn:aws:backup:region:account-id:recovery-point:*` 3 |
| [StopBackupJob](API_StopBackupJob.md) | backup:StopBackupJob | |
| [TagResource](API_TagResource.md) | backup:TagResource | arn:aws:backup:region:account-id:recovery-point:\$1 |
| [UntagResource](API_UntagResource.md) | backup:UntagResource | |
| [UpdateBackupPlan](API_UpdateBackupPlan.md) | backup:UpdateBackupPlan | arn:aws:backup:region:account-id:backup-plan:\$1 |
| [UpdateRecoveryPointLifecycle](API_UpdateRecoveryPointLifecycle.md) | backup:UpdateRecoveryPointLifecycle 1 | arn:aws:backup:region:account-id:backup-vault:\$1 2 |
| [UpdateRegionSettings](API_UpdateRegionSettings.md) | `backup:UpdateRegionSettings` `backup:DescribeRegionSettings` | |
1 既存のボールトのアクセスポリシーを使用します。
2 リソース固有の復旧ポイント ARN については、「[AWS Backup リソース ARNs](#resource-arns-table)」を参照してください。
3 `StartRestoreJob` では、リソースのメタデータにキーと値のペアも必要です。リソースのメタデータを取得するには、`GetRecoveryPointRestoreMetadata` API を呼び出します。
詳細については、「*サービス認可リファレンス*」の「[AWS Backupのアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsbackup.html)」を参照してください。
## タグ権限のコピー
がバックアップジョブまたはコピージョブ AWS Backup を実行すると、ソースリソース (コピーの場合は復旧ポイント) から復旧ポイントにタグをコピーしようとします。
**注記**
AWS Backup は復元ジョブ中にタグをネイティブにコピー**しません**。復元ジョブ中にタグをコピーするイベント駆動型アーキテクチャについては、[AWS Backup 「復元ジョブでリソースタグを保持する方法](https://aws.amazon.com/blogs/storage/how-to-retain-resource-tags-in-aws-backup-restore-jobs/)」を参照してください。
バックアップまたはコピージョブ中、 は、バックアッププラン (またはコピープラン、またはオンデマンドバックアップ) で指定したタグを、ソースリソースのタグで AWS Backup 集約します。ただし、 はリソースあたり 50 個のタグの制限 AWS を適用します。これは を超える AWS Backup ことはできません。バックアップまたはコピージョブがプランとソースリソースからタグを集約すると、合計 50 を超えるタグが検出され、ジョブを完了できず、ジョブが失敗する可能性があります。これは、 AWS全体的なタグ付けのベストプラクティスと一致しています。
+ バックアップジョブタグをソースリソースタグに集約した後、リソースには 50 個を超えるタグがあります。 は、リソースごとに最大 50 個のタグ AWS をサポートします。
+ に提供する IAM ロールには、ソースタグを読み取るか、送信先タグを設定するアクセス許可 AWS Backup がありません。IAM ロールポリシーの詳細とサンプルについては、「[管理ポリシー](https://docs.aws.amazon.com/aws-backup/latest/devguide/access-control.html#managed-policies)」を参照してください。
バックアッププラン (復旧プランに追加されたタグ) を使用して、ソースリソースタグと矛盾するタグを作成できます。2 つの競合が発生すると、バックアッププランのタグが優先されます。ソースリソースからタグ値をコピーしたくない場合は、この方法を使用します。同じタグキーを指定しますが、バックアッププランを使用して、異なる値または空の値を指定します。
**バックアップにタグを割り当てるために必要な権限**
| リソースタイプ | 必要なアクセス権限 |
| --- | --- |
| Amazon EFS ファイルシステム | `elasticfilesystem:DescribeTags` |
| Amazon FSx ファイルシステム | `fsx:ListTagsForResource` |
| Amazon RDS データベースおよび Amazon Aurora クラスター | `rds:AddTagsToResource` `rds:ListTagsForResource` |
| Storage Gateway ボリューム | `storagegateway:ListTagsForResource` |
| Amazon EC2 インスタンスと Amazon EBS ボリューム | `EC2:CreateTags` `EC2:DescribeTags` |
DynamoDB は、最初に [アドバンスト DynamoDB バックアップ](advanced-ddb-backup.md) を有効にしない限り、バックアップへのタグの割り当てをサポートしません。
Amazon EC2 バックアップが Image Recovery Point とスナップショットのセットを作成すると、 AWS Backup はタグを結果の AMI にコピーします。 AWS Backup また、 は Amazon EC2 インスタンスに関連付けられたボリュームから結果のスナップショットにタグをコピーします。
## アクセスポリシー
アクセスポリシー**は、誰が何に対するアクセス権を持っているのかを説明します。IAM アイデンティティにアタッチされているポリシーは、[アイデンティティベース]** のポリシー (IAM ポリシー) と呼ばれます。リソースにアタッチされたポリシーは、*リソースベースの*ポリシーと呼ばれます。 は、アイデンティティベースのポリシーとリソースベースのポリシーの両方 AWS Backup をサポートします。
**注記**
このセクションでは、 のコンテキストでの IAM の使用について説明します AWS Backup。ここでは、IAM サービスに関する詳細情報を提供しません。完全な IAM ドキュメンテーションについては、[[IAM ユーザーガイド]](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) の [IAM とは] を参照してください。IAM ポリシー構文の詳細と説明については、IAM ユーザーガイドの「[IAM JSON ポリシーのリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html)」を参照してください。
### ID ベースのポリシー (IAM ポリシー）
アイデンティティベースのポリシーは、IAM アイデンティティ (ユーザーやロールなど) にアタッチできるポリシーです。たとえば、ユーザーが AWS リソースを表示およびバックアップすることを許可するポリシーを定義できますが、バックアップの復元は禁止できます。
ユーザー、グループ、ロール、許可の詳細については、「[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)」の「アイデンティティ (ユーザー、グループ、ロール)」を参照してください。
IAM ポリシーを使用してバックアップへのアクセスを制御する方法については、「[の管理ポリシー AWS Backup](security-iam-awsmanpol.md)」を参照してください。
### リソースベースのポリシー
AWS Backup は、バックアップボールトのリソースベースのアクセスポリシーをサポートしています。これにより、バックアップ保管庫内の整理された任意のバックアップにどのユーザーがどのようなアクセス許可を持つかを制御できるアクセスポリシーを定義できます。バックアップ保管庫のリソースベースのアクセスポリシーを使用すると、バックアップへのアクセスを簡単に制御できます。
バックアップボールトアクセスポリシーは、 AWS Backup APIs を使用するときのユーザーアクセスを制御します。Amazon Elastic Block Store (Amazon EBS) および Amazon Relational Database Service (Amazon RDS) スナップショットなどの一部のバックアップタイプには、それらのサービスの API を使用してもアクセスできます。バックアップへのアクセスを完全に制御するために、これらの API へのアクセスを制御する個別のアクセスポリシーを IAM で作成できます。
バックアップ保管庫のアクセスポリシーを作成する方法については、「[ボールトアクセスポリシー](create-a-vault-access-policy.md)」を参照してください。
# IAM サービスロール
AWS Identity and Access Management (IAM) ロールは、 AWS アイデンティティができることとできないことを決定するアクセス許可ポリシーを持つアイデンティティであるという点で、ユーザーと似ています AWS。ただし、ユーザーは 1 人の特定の人に一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。サービスロールは、ユーザーに代わってアクションを実行するために AWS サービスが引き受けるロールです。お客様に代わってバックアップオペレーションを実行するサービスとして、 AWS Backup には、お客様に代わってバックアップオペレーションを実行するときに、ロールを渡す必要があります。IAM ロールの詳細については、「IAM ユーザーガイド」の「[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)」を参照してください。**
に渡すロールには、バックアップの作成、復元、期限切れなどのバックアップオペレーションに関連するアクションを実行 AWS Backup するためのアクセス許可を持つ IAM ポリシー AWS Backup が必要です。が AWS Backup サポートするサービスごとに AWS 異なるアクセス許可が必要です。ロールは、 がロールを AWS Backup 引き受けることができる信頼されたエンティティとして AWS Backup リストされている必要があります。
バックアッププランにリソースを割り当てる場合、またはオンデマンドバックアップ、コピー、または復元を実行する場合は、指定されたリソースで基盤となるオペレーションを実行するためのアクセス権を持つサービスロールを渡す必要があります。 は、このロール AWS Backup を使用してアカウント内のリソースを作成、タグ付け、削除します。
## AWS ロールを使用してバックアップへのアクセスを制御する
ロールを使用してバックアップへのアクセスを制御するには、適用範囲を絞り込んだロールを定義し、そのロールを AWS Backupに渡すことのできるユーザーを指定します。たとえば、Amazon Relational Database Service (Amazon RDS) データベースをバックアップするアクセス許可のみを付与し、そのロールを渡すアクセス許可のみを Amazon RDS データベース所有者に付与するロールを作成できます AWS Backup。 は、サポートされているサービスごとにいくつかの事前定義された管理ポリシー AWS Backup を提供します。これらの管理ポリシーは、作成したロールにアタッチできます。これにより、 AWS Backup に必要な適切なアクセス許可を持つサービス固有のロールを簡単に作成できます。
の AWS 管理ポリシーの詳細については AWS Backup、「」を参照してください[の管理ポリシー AWS Backup](security-iam-awsmanpol.md)。
## のデフォルトのサービスロール AWS Backup
AWS Backup コンソールを初めて使用する場合は、 でデフォルトのサービスロール AWS Backup を作成するように選択できます。このロールには、ユーザーに代わってバックアップを作成および復元 AWS Backup するために必要なアクセス許可があります。
**注記**
デフォルトロールは、 AWS マネジメントコンソールを使用すると自動的に作成されます。 AWS Command Line Interface (AWS CLI) を使用してデフォルトのロールを作成できますが、手動で行う必要があります。
リソースタイプごとに異なるロールなど、カスタムロールを使用したい場合は、それを実行し、 AWS Backupにカスタムロールを渡すこともできます。個々のリソースタイプのバックアップと復元を有効にするロールの例を表示するには、[カスタマー管理ポリシー](security-iam-awsmanpol.md#customer-managed-policies) 表を参照してください。
デフォルトのサービスロール名は `AWSBackupDefaultServiceRole` です。このサービスロールには、[AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html) と [AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html) の 2 つのマネージドポリシーが含まれています。
`AWSBackupServiceRolePolicyForBackup` には、バックアップされるリソースを記述する AWS Backup アクセス許可、暗号化されている AWS KMS キーに関係なくバックアップにタグを作成、削除、記述、または追加する機能を付与する IAM ポリシーが含まれています。
`AWSBackupServiceRolePolicyForRestores` には、暗号化されている AWS KMS キーに関係なく、バックアップから作成される新しいリソースを作成、削除、または記述する AWS Backup アクセス許可を付与する IAM ポリシーが含まれています。また、新しく作成されたリソースにタグを付けるためのアクセス許可も含まれています。
Amazon EC2 インスタンスをリストアするには、新しいインスタンスを開始する必要があります。
## コンソール内でデフォールトのサービスロールを作成する
AWS Backup コンソールで実行する特定のアクションによって、 AWS Backup デフォルトのサービスロールが作成されます。
**AWS アカウントに AWS Backup デフォルトのサービスロールを作成するには**
1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。
1. アカウントのロールを作成するには、バックアッププランにリソースを割り当てるか、オンデマンドバックアップを作成します。
1. バックアッププランを作成し、バックアップにリソースを割り当てます。「[バックアッププランの作成](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html)」を参照してください。
1. または、オンデマンドバックアップを作成します。「[オンデマンドバックアップを作成する](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-on-demand-backup.html)」を参照してください。
1. 次の手順に従って、アカウントに `AWSBackupDefaultServiceRole` を作成したことを確認します。
1. 数分待ちます。詳細については、「**AWS Identity and Access Management ユーザーガイド」の「[行った変更がすぐに表示されないことがある](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency)」を参照してください。
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。
1. 左のナビゲーションメニューから **[ロール]** を選択します。
1. 検索バーに「`AWSBackupDefaultServiceRole`」と入力します この選択が存在する場合は、 AWS Backup デフォルトのロールを作成し、この手順を完了します。
1. それでも `AWSBackupDefaultServiceRole` が表示されない場合は、コンソールへのアクセスに使用する IAM ユーザーまたは IAM ロールに次のアクセス許可を追加します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"iam:CreateRole",
"iam:AttachRolePolicy",
"iam:PassRole"
],
"Resource":"arn:aws:iam::*:role/service-role/AWSBackupDefaultServiceRole"
},
{
"Effect":"Allow",
"Action":[
"iam:ListRoles"
],
"Resource":"*"
}
]
}
```
------
中国リージョンの場合は、*aws* を *aws-cn* に置き換えてください。 AWS GovCloud (US) リージョンの場合は、*aws* を *aws-us-gov* に置き換えます。
1. IAM ユーザーまたは IAM ロールにアクセス許可を追加できない場合は、管理者に依頼して、`AWSBackupDefaultServiceRole` *以外*の名前のロールを手動で作成し、そのロールを以下の管理ポリシーにアタッチするよう依頼します。
+ `AWSBackupServiceRolePolicyForBackup`
+ `AWSBackupServiceRolePolicyForRestores`
# の管理ポリシー AWS Backup
管理ポリシーは、 内の複数のユーザー、グループ、ロールにアタッチできるスタンドアロンのアイデンティティベースのポリシーです AWS アカウント。ポリシーをプリンシパルエンティティにアタッチすると、ポリシーで定義されたアクセス権限がエンティティに付与されます。
*AWS 管理ポリシー*は、 によって作成および管理されます AWS。 AWS 管理ポリシーで定義されているアクセス許可は変更できません。が AWS マネージドポリシーで定義されたアクセス許可 AWS を更新すると、その更新はポリシーがアタッチされているすべてのプリンシパル ID (ユーザー、グループ、ロール) に影響します。
*カスタマー管理ポリシー*を使用すると、 でバックアップへのアクセスをきめ細かく制御できます AWS Backup。たとえば、それらを使用して、データベースバックアップ管理者に Amazon RDS バックアップへのアクセス権を付与できますが、Amazon EFS バックアップにはアクセスできません。
詳細については、「*IAM ユーザーガイド*」の「[マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html)」を参照してください。
## AWS マネージドポリシー
AWS Backup では、一般的なユースケース向けに以下の AWS マネージドポリシーを提供しています。これらのポリシーではより簡単に、適切なアクセス許可を定義し、バックアップへのアクセスを制御できます。管理ポリシーには 2 種類あります。1 つのタイプは、 AWS Backupへのアクセスを制御するためにユーザーに割り当てられるように設計されています。もう 1 つのタイプは、 AWS Backupに渡すロールにアタッチされるように設計されています。以下の表では、 AWS Backup が提供するすべての管理ポリシーを示し、それらのポリシーがどのように定義されているかを説明しています。これらの管理ポリシーは、IAM コンソールの**ポリシー**セクションでも確認できます。
**Topics**
+ [AWSBackupAuditAccess](#AWSBackupAuditAccess)
+ [AWSBackupDataTransferAccess](#AWSBackupDataTransferAccess)
+ [AWSBackupFullAccess](#AWSBackupFullAccess)
+ [AWSBackupGatewayServiceRolePolicyForVirtualMachineMetadataSync](#AWSBackupGatewayServiceRolePolicyForVirtualMachineMetadataSync)
+ [AWSBackupGuardDutyRolePolicyForScans](#AWSBackupGuardDutyRolePolicyForScans)
+ [AWSBackupOperatorAccess](#AWSBackupOperatorAccess)
+ [AWSBackupOrganizationAdminAccess](#AWSBackupOrganizationAdminAccess)
+ [AWSBackupRestoreAccessForSAPHANA](#AWSBackupRestoreAccessForSAPHANA)
+ [AWSBackupSearchOperatorAccess](#AWSBackupSearchOperatorAccess)
+ [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup)
+ [AWSBackupServiceLinkedRolePolicyForBackupTest](#AWSBackupServiceLinkedRolePolicyForBackupTest)
+ [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup)
+ [AWSBackupServiceRolePolicyForItemRestores](#AWSBackupServiceRolePolicyForItemRestores)
+ [AWSBackupServiceRolePolicyForIndexing](#AWSBackupServiceRolePolicyForIndexing)
+ [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores)
+ [AWSBackupServiceRolePolicyForS3Backup](#AWSBackupServiceRolePolicyForS3Backup)
+ [AWSBackupServiceRolePolicyForS3Restore](#AWSBackupServiceRolePolicyForS3Restore)
+ [AWSBackupServiceRolePolicyForScans](#AWSBackupServiceRolePolicyForScans)
+ [AWSServiceRolePolicyForBackupReports](#AWSServiceRolePolicyForBackupReports)
+ [AWSServiceRolePolicyForBackupRestoreTesting](#AWSServiceRolePolicyForBackupRestoreTesting)
### AWSBackupAuditAccess
このポリシーは、 AWS Backup リソースとアクティビティに対する期待を定義するコントロールとフレームワークを作成し、定義されたコントロールとフレームワークに対して AWS Backup リソースとアクティビティを監査するアクセス許可をユーザーに付与します。このポリシーは、監査を実行するユーザーの期待を説明するアクセス許可を AWS Config および同様のサービスに付与します。
このポリシーは、Amazon S3 および同様のサービスに監査レポートを配信するアクセス権限も付与し、ユーザーは監査レポートを見つけて開くことができます。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AWSBackupAuditAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupAuditAccess.html)」を参照してください。
### AWSBackupDataTransferAccess
このポリシーは、 AWS Backup ストレージプレーンのデータ転送 APIsのアクセス許可を提供し、 AWS Backint エージェントが AWS Backup ストレージプレーンでバックアップデータ転送を完了できるようにします。Backint エージェントを使用して SAP HANA を実行している Amazon EC2 インスタンスが引き受けるロールに、このポリシーをアタッチできます。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AWSBackupDataTransferAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupDataTransferAccess.html)」を参照してください。
### AWSBackupFullAccess
バックアップ管理者は、バックアッププランの作成または編集、バックアッププランへの AWS リソースの割り当て、バックアップの復元などの AWS Backup オペレーションにフルアクセスできます。バックアップ管理者は、バックアップのコンプライアンスの決定と実施を担当し、組織のビジネスおよび規制関連の要件を満たすバックアッププランを定義します。また、バックアップ管理者は、組織の AWS リソースが適切な計画に割り当てられていることを確認します。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AWSBackupFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupFullAccess.html)」を参照してください。
### AWSBackupGatewayServiceRolePolicyForVirtualMachineMetadataSync
このポリシーは、ユーザーに代わって仮想マシンのメタデータを同期するアクセス許可を Backup ゲートウェイに付与します。
このポリシーのアクセス許可を確認するには、「 *AWS マネージドポリシーリファレンス*」の[AWSBackupGatewayServiceRolePolicyForVirtualMachineMetadataSync](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupGatewayServiceRolePolicyForVirtualMachineMetadataSync.html)」を参照してください。
### AWSBackupGuardDutyRolePolicyForScans
このポリシーは、バックアップを読み取ってスキャンするアクセス許可を Amazon GuardDuty に付与する新しいスキャンロールに追加する必要があります。このスキャンロールは、マルウェア保護またはスキャン設定内でバックアッププランにアタッチする必要があります。 AWS Backup がスキャンを開始すると、このスキャンロールを Amazon GuardDuty に渡します。
このポリシーのアクセス許可を確認するには、「 *AWS マネージドポリシーリファレンス*」の[AWSBackupGuardDutyRolePolicyForScans](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupGuardDutyRolePolicyForScans.html)」を参照してください。
### AWSBackupOperatorAccess
バックアップオペレーターは、担当するリソースが適切にバックアップされていることを確認する責任のあるユーザーです。バックアップオペレーターには、バックアップ管理者が作成するバックアッププランに AWS リソースを割り当てるアクセス許可があります。また、 AWS リソースのオンデマンドバックアップを作成し、オンデマンドバックアップの保持期間を設定するアクセス許可も付与されます。バックアップオペレーターは、バックアッププランを作成または編集したり、スケジュールされたバックアップを作成後に削除したりするためのアクセス許可は持っていません。バックアップオペレーターはバックアップをリストアできます。バックアップオペレーター がバックアッププランに割り当てることができるリソースタイプや、バックアップからリストアできるリソースタイプを制限できます。これを行うには、特定のリソースタイプのアクセス許可 AWS Backup を持つ特定のサービスロールのみを に渡します。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AWSBackupOperatorAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupOperatorAccess.html)」を参照してください。
### AWSBackupOrganizationAdminAccess
組織管理者は、バックアップポリシーの作成、編集、削除、アカウントと組織単位へのバックアップポリシーの割り当て、組織内のバックアップアクティビティのモニタリングなど、 AWS Organizations オペレーションにフルアクセスできます。組織管理者は、組織のビジネス要件および規制要件を満たすバックアップポリシーを定義して割り当てることによって、組織内のアカウントを保護する責任があります。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AWSBackupOrganizationAdminAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupOrganizationAdminAccess.html)」を参照してください。
### AWSBackupRestoreAccessForSAPHANA
このポリシーは、Amazon EC2 で SAP HANA のバックアップを復元する AWS Backup アクセス許可を提供します。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AWSBackupRestoreAccessForSAPHANA](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupRestoreAccessForSAPHANA.html)」を参照してください。
### AWSBackupSearchOperatorAccess
検索オペレーターロールには、バックアップインデックスを作成し、インデックス付きバックアップメタデータの検索を作成するためのアクセス権があります。
このポリシーには、これらの関数に必要なアクセス許可が含まれています。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AWSBackupSearchOperatorAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupSearchOperatorAccess.html)」を参照してください。
### AWSBackupServiceLinkedRolePolicyForBackup
このポリシーは、 という名前のサービスにリンクされたロールにアタッチAWSServiceRoleforBackupされ、 AWS Backup がユーザーに代わって AWS サービスを呼び出してバックアップを管理できるようにします。詳細については、「[ロールを使用したバックアップとコピー](using-service-linked-roles-AWSServiceRoleForBackup.md)」を参照してください。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AWSBackupServiceLinkedRolePolicyforBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceLinkedRolePolicyForBackup.html)」を参照してください。
### AWSBackupServiceLinkedRolePolicyForBackupTest
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AWSBackupServiceLinkedRolePolicyForBackupTest](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceLinkedRolePolicyForBackupTest.html)」を参照してください。
### AWSBackupServiceRolePolicyForBackup
ユーザーに代わって、サポートされているすべてのリソースタイプのバックアップを作成する AWS Backup アクセス許可を提供します。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html)」を参照してください。
### AWSBackupServiceRolePolicyForItemRestores
**説明**
このポリシーは、スナップショット (定期的バックアップの復旧ポイント) 内の個々のファイルと項目を、新規または既存の Amazon S3 バケットまたは新しい Amazon EBS ボリュームに復元するアクセス許可をユーザーに付与します。これらのアクセス許可には、 AWS Backup によって管理されるスナップショットの Amazon EBS に対する読み取りアクセス許可、Amazon S3 バケットに対する読み取り/書き込みアクセス許可、および AWS KMS キーの生成と記述のアクセス許可が含まれます。
**このポリシーの使用**
ユーザー、グループおよびロールに `AWSBackupServiceRolePolicyForItemRestores` をアタッチできます。
**ポリシーの詳細**
+ **タイプ:** AWS 管理ポリシー
+ **作成日時**: 2024 年 11 月 21 日 22:45 UTC
+ **編集日時:** 最初のインスタンス
+ **ARN:** `arn:aws:iam::aws:policy/AWSBackupServiceRolePolicyForItemRestores`
**ポリシーのバージョン:** v1 (デフォルト)
このポリシーのバージョンは、ポリシーのアクセス許可を定義します。ポリシーを持つユーザーまたはロールが AWS リソースへのアクセスをリクエストすると、 はポリシーのデフォルトバージョン AWS をチェックして、リクエストを許可するかどうかを決定します。
**JSON ポリシードキュメント:**
#### AWSBackupServiceRolePolicyForItemRestores JSON
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EBSReadOnlyPermissions",
"Effect": "Allow",
"Action": [
"ec2:DescribeSnapshots"
],
"Resource": "arn:aws:ec2:*::snapshot/*"
},
{
"Sid": "KMSReadOnlyPermissions",
"Effect": "Allow",
"Action": "kms:DescribeKey",
"Resource": "*"
},
{
"Sid": "EBSDirectReadAPIPermissions",
"Effect": "Allow",
"Action": [
"ebs:ListSnapshotBlocks",
"ebs:GetSnapshotBlock"
],
"Resource": "arn:aws:ec2:*::snapshot/*"
},
{
"Sid": "S3ReadonlyPermissions",
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:ListBucket"
],
"Resource": "arn:aws:s3:::*"
},
{
"Sid": "S3PermissionsForFileLevelRestore",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:AbortMultipartUpload",
"s3:ListMultipartUploadParts"
],
"Resource": "arn:aws:s3:::*/*"
},
{
"Sid": "KMSDataKeyForS3AndEC2Permissions",
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:*:*:key/*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"ec2.*.amazonaws.com",
"s3.*.amazonaws.com"
]
}
}
}
]
}
```
------
### AWSBackupServiceRolePolicyForIndexing
**説明**
このポリシーは、定期的な復旧ポイントとも呼ばれるスナップショットのインデックスを作成するアクセス許可をユーザーに付与します。これらのアクセス許可には、Amazon S3 バケットへの読み取り/書き込みアクセス許可によって管理されるスナップショットの Amazon EBS への AWS Backup 読み取りアクセス許可、および AWS KMS キーのアクセス許可の生成と記述が含まれます。
**このポリシーの使用**
ユーザー、グループおよびロールに `AWSBackupServiceRolePolicyForIndexing` をアタッチできます。
**ポリシーの詳細**
+ **タイプ:** AWS 管理ポリシー
+ **編集日時:** 最初のインスタンス
+ **ARN:** `arn:aws:iam::aws:policy/AWSBackupServiceRolePolicyForIndexing`
**ポリシーのバージョン:** v1 (デフォルト)
このポリシーのバージョンは、ポリシーのアクセス許可を定義します。ポリシーを持つユーザーまたはロールが AWS リソースへのアクセスをリクエストすると、 はポリシーのデフォルトバージョン AWS をチェックして、リクエストを許可するかどうかを決定します。
**JSON ポリシードキュメント:**
#### AWSBackupServiceRolePolicyForIndexing JSON
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EBSReadOnlyPermissions",
"Effect": "Allow",
"Action": [
"ec2:DescribeSnapshots"
],
"Resource": "arn:aws:ec2:*::snapshot/*"
},
{
"Sid": "KMSReadOnlyPermissions",
"Effect": "Allow",
"Action": "kms:DescribeKey",
"Resource": "*"
},
{
"Sid": "EBSDirectReadAPIPermissions",
"Effect": "Allow",
"Action": [
"ebs:ListSnapshotBlocks",
"ebs:GetSnapshotBlock"
],
"Resource": "arn:aws:ec2:*::snapshot/*"
},
{
"Sid": "KMSDataKeyForEC2Permissions",
"Effect": "Allow",
"Action": "kms:Decrypt",
"Resource": "arn:aws:kms:*:*:key/*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"ec2.*.amazonaws.com"
]
}
}
}
]
}
```
------
### AWSBackupServiceRolePolicyForRestores
ユーザーに代わって、サポートされているすべてのリソースタイプのバックアップを復元する AWS Backup アクセス許可を提供します。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html)」を参照してください。
EC2 インスタンスのリストアでは、EC2 インスタンスを起動するために次の権限も含める必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPassRole",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::123456789012:role/role-name",
"Effect": "Allow"
}
]
}
```
------
### AWSBackupServiceRolePolicyForS3Backup
このポリシーには、 が S3 バケットをバックアップ AWS Backup するために必要なアクセス許可が含まれています。これには、バケット内のすべてのオブジェクトおよび関連する AWS KMS キーへのアクセスが含まれます。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AWSBackupServiceRolePolicyForS3Backup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForS3Backup.html)」を参照してください。
### AWSBackupServiceRolePolicyForS3Restore
このポリシーには、 が S3 バックアップをバケットに復元 AWS Backup するために必要なアクセス許可が含まれています。これには、バケットへの読み取りおよび書き込みアクセス許可と、S3 オペレーションに関する AWS KMS キーの使用が含まれます。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AWSBackupServiceRolePolicyForS3Restore](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForS3Restore.html)」を参照してください。
### AWSBackupServiceRolePolicyForScans
ポリシーは、バックアッププランのリソース選択で使用する IAM ロールにアタッチする必要があります。このロールは、Amazon GuardDuty でスキャンを開始する AWS Backup アクセス許可を付与します。
このポリシーのアクセス許可を確認するには、「 *AWS マネージドポリシーリファレンス*」の[AWSBackupServiceRolePolicyForScans](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForScans.html)」を参照してください。
### AWSServiceRolePolicyForBackupReports
AWS Backup は、[AWSServiceRoleForBackupReports](https://docs.aws.amazon.com/aws-backup/latest/devguide/using-service-linked-roles-AWSServiceRoleForBackupReports.html) サービスにリンクされたロールにこのポリシーを使用します。このサービスにリンクされたロールは、バックアップ設定、ジョブ、リソースのフレームワークへの準拠をモニタリングおよびレポートする AWS Backup アクセス許可を付与します。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AWSServiceRolePolicyForBackupReports](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRolePolicyForBackupReports.html)」を参照してください。
### AWSServiceRolePolicyForBackupRestoreTesting
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AWSServiceRolePolicyForBackupRestoreTesting](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRolePolicyForBackupRestoreTesting.html)」を参照してください。
## カスタマー管理ポリシー
以下のセクションでは、 でサポートされている AWS サービスおよびサードパーティーアプリケーションに推奨されるバックアップおよび復元のアクセス許可について説明します AWS Backup。既存の AWS 管理ポリシーをモデルとして使用して独自のポリシードキュメントを作成し、 AWS リソースへのアクセスをさらに制限するようにカスタマイズできます。
**重要**
でカスタム IAM ロールを使用する場合は AWS Backup、アクセス許可に加えてリソース固有の AWS Backup アクセス許可を含める必要があります。例えば、Amazon RDS リソースで `backup:ListTags` を呼び出す場合、カスタム IAM ロールには `rds:ListTagsForResource` アクセス許可も含める必要があります。これらのアクセス許可はデフォルトの AWS Backup サービスロールに含まれていますが、カスタマー管理ポリシーに明示的に追加する必要があります。必要な基盤となるリソースのアクセス許可は、実行される特定の AWS サービスとオペレーションによって異なります。
### Amazon Aurora
**バックアップ**
[AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html) からの次のステートメントで始めます。
+ `DynamoDBBackupPermissions`
+ `RDSClusterModifyPermissions`
+ `GetResourcesPermissions`
+ `BackupVaultPermissions`
+ `KMSPermissions`
**Restore**
[AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html) からの `RDSPermissions` ステートメントで始めます。
### Amazon Aurora DSQL
**バックアップ**
[AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html) からの次のステートメントで始めます。
+ `DSQLBackupPermissions`
+ `GetResourcesPermissions`
+ `BackupVaultPermissions`
+ `KMSPermissions`
**Restore**
[AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html) からの `DSQLRestorePermissions` ステートメントで始めます。
### Amazon DynamoDB
**バックアップ**
[AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html) からの次のステートメントで始めます。
+ `DynamoDBPermissions`
+ `DynamoDBBackupResourcePermissions`
+ `DynamodbBackupPermissions`
+ `KMSDynamoDBPermissions`
**Restore**
[AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html) からの次のステートメントで始めます。
+ `DynamoDBPermissions`
+ `DynamoDBBackupResourcePermissions`
+ `DynamoDBRestorePermissions`
+ `KMSPermissions`
### Amazon EBS
**バックアップ**
[AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html) からの次のステートメントで始めます。
+ `EBSResourcePermissions`
+ `EBSTagAndDeletePermissions`
+ `EBSCopyPermissions`
+ `EBSSnapshotTierPermissions`
+ `GetResourcesPermissions`
+ `BackupVaultPermissions`
**Restore**
[AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html) からの `EBSPermissions` ステートメントで始めます。
次のステートメントを追加します。
```
{
"Effect":"Allow",
"Action": [
"ec2:DescribeSnapshots",
"ec2:DescribeVolumes"
],
"Resource":"*"
},
```
### Amazon EC2
**バックアップ**
[AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html) からの次のステートメントで始めます。
+ `EBSCopyPermissions`
+ `EC2CopyPermissions`
+ `EC2Permissions`
+ `EC2TagPermissions`
+ `EC2ModifyPermissions`
+ `EBSResourcePermissions`
+ `GetResourcesPermissions`
+ `BackupVaultPermissions`
**Restore**
[AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html) からの次のステートメントで始めます。
+ `EBSPermissions`
+ `EC2DescribePermissions`
+ `EC2RunInstancesPermissions`
+ `EC2TerminateInstancesPermissions`
+ `EC2CreateTagsPermissions`
次のステートメントを追加します。
```
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::account-id:role/role-name"
},
```
*role-name* を、復元された EC2 インスタンスにアタッチされる EC2 インスタンスプロファイルロールの名前に置き換えます。これは AWS Backup サービスロールではなく、EC2 インスタンスで実行されているアプリケーションにアクセス許可を付与する IAM ロールです。
### Amazon EFS
**バックアップ**
[AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html) からの次のステートメントで始めます。
+ `EFSPermissions`
+ `GetResourcesPermissions`
+ `BackupVaultPermissions`
**Restore**
[AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html) からの `EFSPermissions` ステートメントで始めます。
### Amazon FSx
**バックアップ**
[AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html) からの次のステートメントで始めます。
+ `FsxBackupPermissions`
+ `FsxCreateBackupPermissions`
+ `FsxPermissions`
+ `FsxVolumePermissions`
+ `FsxListTagsPermissions`
+ `FsxDeletePermissions`
+ `FsxResourcePermissions`
+ `KMSPermissions`
**Restore**
[AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html) からの次のステートメントで始めます。
+ `FsxPermissions`
+ `FsxTagPermissions`
+ `FsxBackupPermissions`
+ `FsxDeletePermissions`
+ `FsxDescribePermissions`
+ `FsxVolumeTagPermissions`
+ `FsxBackupTagPermissions`
+ `FsxVolumePermissions`
+ `DSPermissions`
+ `KMSDescribePermissions`
### Amazon Neptune
**バックアップ**
[AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html) からの次のステートメントで始めます。
+ `DynamoDBBackupPermissions`
+ `RDSClusterModifyPermissions`
+ `GetResourcesPermissions`
+ `BackupVaultPermissions`
+ `KMSPermissions`
**Restore**
[AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html) からの `RDSPermissions` ステートメントで始めます。
### Amazon RDS
**バックアップ**
[AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html) からの次のステートメントで始めます。
+ `DynamoDBBackupPermissions`
+ `RDSBackupPermissions`
+ `RDSClusterModifyPermissions`
+ `GetResourcesPermissions`
+ `BackupVaultPermissions`
+ `KMSPermissions`
**Restore**
[AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html) からの `RDSPermissions` ステートメントで始めます。
### Amazon S3
**バックアップ**
[AWSBackupServiceRolePolicyForS3Backup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForS3Backup.html) で始めます。
バックアップを別のアカウントにコピーする必要がある場合は、`BackupVaultPermissions` および `BackupVaultCopyPermissions` ステートメントを追加します。
**Restore**
[AWSBackupServiceRolePolicyForS3Restore](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForS3Restore.html) で始めます。
### AWS Storage Gateway
**バックアップ**
[AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html) からの次のステートメントで始めます。
+ `StorageGatewayPermissions`
+ `EBSTagAndDeletePermissions`
+ `GetResourcesPermissions`
+ `BackupVaultPermissions`
次のステートメントを追加します。
```
{
"Effect": "Allow",
"Action": [
"ec2:DescribeSnapshots"
],
"Resource":"*"
},
```
**Restore**
[AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html) からの次のステートメントで始めます。
+ `StorageGatewayVolumePermissions`
+ `StorageGatewayGatewayPermissions`
+ `StorageGatewayListPermissions`
### 仮想マシン
**バックアップ**
[AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html) からの `BackupGatewayBackupPermissions` ステートメントで始めます。
**Restore**
[AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html) からの `GatewayRestorePermissions` ステートメントで始めます。
### 暗号化されたバックアップ
**暗号化されたバックアップを復元するには、次のいずれかの操作を行います。**
+ AWS KMS キーポリシーの許可リストにロールを追加する
+ 復元のために、[AWSBackupServiceRolePolicyForRestores](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForRestores.html) からの次のステートメントを IAM ロールに追加します。
+ `KMSDescribePermissions`
+ `KMSPermissions`
+ `KMSCreateGrantPermissions`
## のポリシーの更新 AWS Backup
このサービスがこれらの変更の追跡を開始 AWS Backup してからの の AWS 管理ポリシーの更新に関する詳細を表示します。
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| [AWSServiceRolePolicyForBackupRestoreTesting](#AWSServiceRolePolicyForBackupRestoreTesting) – 既存のポリシーの更新 | AWS Backup は、このポリシーに次のアクセス許可を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html) これらのアクセス許可により、 AWS Backup 復元テストは復元テストの完了後に RDS テナントデータベースを削除できます。 | 2026 年 3 月 18 日 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – 既存のポリシーの更新 | AWS Backup は、このポリシーに次のアクセス許可を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html) これらのアクセス許可により、 AWS Backup は復旧ポイントでマルウェアスキャンを開始できます。 | 2026 年 2 月 23 日 |
| [AWSBackupGuardDutyRolePolicyForScans](#AWSBackupGuardDutyRolePolicyForScans) – 新しいポリシー | AWS Backup は、Amazon GuardDuty にお客様のバックアップを読み取ってスキャンするアクセス許可を付与する新しい AWS マネージドポリシーを追加しました。 AWS Backup は、オペレーション を開始するときに、このポリシーを持つロールを GuardDuty に渡します`StartMalwareScan`。 これは、Amazon EC2、Amazon EBS、Amazon S3 リソースの復旧ポイントでのマルウェアスキャンに必要なすべてのアクセス許可を提供するために必要です。 詳細については、[AWSBackupGuardDutyRolePolicyForScans](#AWSBackupGuardDutyRolePolicyForScans) マネージドポリシーを参照してください。 | 2025 年 11 月 19 日 |
| [AWSBackupServiceRolePolicyForScans](#AWSBackupServiceRolePolicyForScans) – 新しいポリシー | AWS Backup は、復旧ポイントでマルウェアスキャンを開始する AWS Backup アクセス許可を提供する新しい AWS マネージドポリシーを追加しました。 これは、Amazon EC2、Amazon EBS、Amazon S3 リソースの復旧ポイントでのマルウェアスキャンに必要なすべてのアクセス許可を提供するために必要です。 詳細については、[AWSBackupServiceRolePolicyForScans](#AWSBackupServiceRolePolicyForScans) 管理ポリシーを参照してください。 | 2025 年 11 月 19 日 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – 既存のポリシーの更新 | マルウェアスキャンジョブを開始するために必要な `IamPassRolePermissions``malware-protection.guardduty.amazonaws.com`を に追加しました。 | 2025 年 11 月 19 日 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – 既存のポリシーの更新 | AWS Backup は、このポリシーに次のアクセス許可を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html) これらのアクセス許可は、マルウェアスキャンジョブを開始するために必要です。 | 2025 年 11 月 19 日 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – 既存のポリシーの更新 | AWS Backup は、このポリシーに次のアクセス許可を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html) これらのアクセス許可により、 AWS Backup は Amazon EKS クラスターをバックアップおよび復元できます。 | 2025 年 11 月 10 日 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – 既存のポリシーの更新 | AWS Backup は、このポリシーに次のアクセス許可を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html) これらのアクセス許可により、 AWS Backup は Amazon EKS クラスターをバックアップおよび復元できます。 | 2025 年 11 月 10 日 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – 既存のポリシーの更新 | AWS Backup は、このポリシーに次のアクセス許可を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html) これらのアクセス許可により AWS Backup 、 は顧客に代わって Amazon EKS クラスターとその関連リソースのバックアップを作成できます。 | 2025 年 11 月 10 日 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – 既存のポリシーの更新 | AWS Backup は、このポリシーに次のアクセス許可を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html) これらのアクセス許可により AWS Backup 、 は顧客に代わって Amazon EKS クラスターとその関連リソースのバックアップを作成できます。 | 2025 年 11 月 10 日 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – 既存のポリシーの更新 | AWS Backup は、このポリシーに次のアクセス許可を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html) これらのアクセス許可により AWS Backup 、 は Amazon EKS クラスターおよび関連するリソースの復元オペレーションをお客様に代わって実行できます。 | 2025 年 11 月 10 日 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – 既存のポリシーの更新 | AWS Backup は、このポリシーに次のアクセス許可を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html) このアクセス許可により AWS Backup 、 は委任された管理者情報を Organizations と同期して、クロスアカウント管理機能を使用できます。 | 2025 年 9 月 9 日 |
| [AWSBackupGuardDutyRolePolicyForScans](#AWSBackupGuardDutyRolePolicyForScans) – 新しいポリシー | AWS Backup は、Amazon GuardDuty にお客様のバックアップを読み取ってスキャンするアクセス許可を付与する新しい AWS マネージドポリシーを追加しました。 AWS Backup は、オペレーション を開始するときに、このポリシーを持つロールを GuardDuty に渡します`StartMalwareScan`。 これは、Amazon EC2、Amazon EBS、Amazon S3 リソースの復旧ポイントでのマルウェアスキャンに必要なすべてのアクセス許可を提供するために必要です。 詳細については、[AWSBackupGuardDutyRolePolicyForScans](#AWSBackupGuardDutyRolePolicyForScans) マネージドポリシーを参照してください。 | 2025 年 11 月 24 日 |
| [AWSBackupServiceRolePolicyForScans](#AWSBackupServiceRolePolicyForScans) – 新しいポリシー | AWS Backup は、復旧ポイントでマルウェアスキャンを開始する AWS Backup アクセス許可を提供する新しい AWS マネージドポリシーを追加しました。 これは、Amazon EC2、Amazon EBS、Amazon S3 リソースの復旧ポイントでのマルウェアスキャンに必要なすべてのアクセス許可を提供するために必要です。 詳細については、[AWSBackupServiceRolePolicyForScans](#AWSBackupServiceRolePolicyForScans) 管理ポリシーを参照してください。 | 2025 年 11 月 24 日 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – 既存のポリシーの更新 | AWS Backup は、このポリシーに次のアクセス許可を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html) これらのアクセス許可は、 がお客様に代わって DSQL リソースのオーケストレーションされたマルチリージョン復元オペレーションを実行する AWS Backup ために必要です。 | 2025 年 7 月 17 日 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – 既存のポリシーの更新 | AWS Backup は、このポリシーに次のアクセス許可を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html) これらのアクセス許可は と AWS Backup AWS アカウント管理 の統合に必要です。 AWS Organizations そのため、お客様は論理エアギャップボールトの一部としてマルチパーティー承認 (MPA) を選択できます。 | 2025 年 6 月 17 日 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – 既存のポリシーの更新: | AWS Backup は、このポリシーに次のアクセス許可を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html) これらのアクセス許可は、お客様が AWS Backupを通じて Amazon FSx for OpenZFS マルチアベイラビリティーゾーン (マルチ AZ) スナップショットを復元するために必要です。 | 2025 年 5 月 27 日 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – 既存のポリシーの更新 | AWS Backup は、このポリシーに次のアクセス許可を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html) これらのアクセス許可により、 AWS Backup は Amazon Aurora DSQL リソースをバックアップおよび復元できます。 | 2025 年 5 月 21 日 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – 既存のポリシーの更新 | AWS Backup は、このポリシーに次のアクセス許可を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html) これらのアクセス許可により、 AWS Backup は Amazon Aurora DSQL リソースをバックアップおよび復元できます。 | 2025 年 5 月 21 日 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – 既存のポリシーの更新 | AWS Backup は、このポリシーに次のアクセス許可を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html) これらのアクセス許可により、 AWS Backup はお客様に代わって Amazon Aurora DSQL スナップショットを作成、削除、取得、管理できます。 | 2025 年 5 月 21 日 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – 既存のポリシーの更新 | AWS Backup は、このポリシーに次のアクセス許可を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html) これらのアクセス許可により、 AWS Backup はお客様に代わって Amazon Aurora DSQL スナップショットを作成、削除、取得、暗号化、復号、管理できます。 | 2025 年 5 月 21 日 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – 既存のポリシーの更新 | AWS Backup は、このポリシーに次のアクセス許可を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html) これらのアクセス許可により AWS Backup 、 はお客様が指定した間隔で Aurora DSQL バックアップを管理できます。 | 2025 年 5 月 21 日 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – 既存のポリシーの更新 | AWS Backup は、このポリシーに次のアクセス許可を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html) これらのアクセス許可は、指定されたお客様が、必要な読み取りアクセス許可や Amazon Redshift Serverless 復旧ポイント (スナップショットバックアップ) を削除する機能を含め、Amazon Redshift Serverless バックアップにフルアクセスするために必要です。 | 2025 年 3 月 31 日 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – 既存のポリシーの更新 | AWS Backup は、このポリシーに次のアクセス許可を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html) これらのアクセス許可は、指定されたお客様が、必要な読み取りアクセス許可を含め、Amazon Redshift Serverless に対する必要なすべてのバックアップアクセス許可を持つために必要です。 | 2025 年 3 月 31 日 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – 既存のポリシーの更新 | AWS Backup は、このポリシーに次のアクセス許可を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html) これらのアクセス許可は、お客様が指定した間隔で Amazon Redshift Serverless スナップショットを管理する AWS Backup ために必要です。 | 2025 年 3 月 31 日 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – 既存のポリシーの更新 | AWS Backup は、このポリシーに次のアクセス許可を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html) これらのアクセス許可は、 AWS Backup がお客様に代わって Amazon Redshift Serverless スナップショットを作成、削除、取得、管理するために必要です。 | 2025 年 3 月 31 日 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – 既存のポリシーの更新 | AWS Backup は、このポリシーに次のアクセス許可を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html) これらのアクセス許可は、 AWS Backup がお客様に代わって Amazon Redshift および Amazon Redshift Serverless スナップショットを復元するために必要です。 | 2025 年 3 月 31 日 |
| [AWSBackupSearchOperatorAccess](#AWSBackupSearchOperatorAccess) – 新しい AWS 管理ポリシーを追加 | AWS Backup に AWSBackupSearchOperatorAccess AWS マネージドポリシーが追加されました。 | 2025 年 2 月 27 日 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – 既存のポリシーの更新 | AWS Backup に、Amazon RDS マルチテナントスナップショットのバックアップのクロスアカウントコピー`rds:AddTagsToResource`をサポートするアクセス許可が追加されました。 このアクセス許可は、お客様がマルチテナント RDS スナップショットのクロスアカウントコピーを作成することを選択した場合に、オペレーションを完了するために必要です。 | 2025 年 1 月 8 日 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – 既存のポリシーの更新 | AWS Backup は、Amazon RDS リソースの復元プロセスをサポートするために、アクセス許可 `rds:CreateTenantDatabase`と を`rds:DeleteTenantDatabase`このポリシーに追加しました。 これらのアクセス許可は、マルチテナントスナップショットを復元するカスタマーオペレーションを完了するために必要です。 | 2025 年 1 月 8 日 |
| [AWSBackupServiceRolePolicyForItemRestores](#AWSBackupServiceRolePolicyForItemRestores) – 新しい AWS 管理ポリシーを追加 | AWS Backup に AWSBackupServiceRolePolicyForItemRestores AWS マネージドポリシーが追加されました。 | 2024 年 11 月 26 日 |
| [AWSBackupServiceRolePolicyForIndexing](#AWSBackupServiceRolePolicyForIndexing) – 新しい AWS 管理ポリシーを追加 | AWS Backup に AWSBackupServiceRolePolicyForIndexing AWS マネージドポリシーが追加されました。 | 2024 年 11 月 26 日 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – 既存のポリシーの更新 | AWS Backup がこのポリシー`backup:TagResource`にアクセス許可を追加しました。 このアクセス許可は、復旧ポイントの作成中にタグ付けアクセス許可を取得するために必要です。 | 2024 年 5 月 17 日 |
| [AWSBackupServiceRolePolicyForS3Backup](#AWSBackupServiceRolePolicyForS3Backup) – 既存のポリシーの更新 | AWS Backup がこのポリシー`backup:TagResource`にアクセス許可を追加しました。 このアクセス許可は、復旧ポイントの作成中にタグ付けアクセス許可を取得するために必要です。 | 2024 年 5 月 17 日 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – 既存のポリシーの更新 | AWS Backup がこのポリシー`backup:TagResource`にアクセス許可を追加しました。 このアクセス許可は、復旧ポイントの作成中にタグ付けアクセス許可を取得するために必要です。 | 2024 年 5 月 17 日 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – 既存のポリシーの更新 | アクセス許可 `rds:DeleteDBInstanceAutomatedBackups` を追加しました。 このアクセス許可は、 AWS Backup が Amazon RDS インスタンスの継続的なバックアップとpoint-in-time-restoreをサポートするために必要です。 | 2024 年 5 月 1 日 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – 既存のポリシーの更新 | AWS Backup Storage Gateway API モデルの変更に対応するため、 はアクセス許可の Amazon リソースネーム (ARN) を `arn:aws:storagegateway:*:*:gateway/*` `storagegateway:ListVolumes`から `*` に更新しました。 | 2024 年 5 月 1 日 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – 既存のポリシーの更新 | AWS Backup Storage Gateway API モデルの変更に対応するため、 はアクセス許可の Amazon リソースネーム (ARN) を `arn:aws:storagegateway:*:*:gateway/*` `storagegateway:ListVolumes`から `*` に更新しました。 | 2024 年 5 月 1 日 |
| [AWSServiceRolePolicyForBackupRestoreTesting](#AWSServiceRolePolicyForBackupRestoreTesting) – 既存のポリシーの更新 | 復元テストプランを実行するために、復旧ポイントと保護されたリソースを記述および一覧表示する次のアクセス許可を追加しました: `backup:DescribeRecoveryPoint`、`backup:DescribeProtectedResource`、`backup:ListProtectedResources`、および `backup:ListRecoveryPointsByResource`。 Amazon EBS アーカイブ階層ストレージをサポートするために、アクセス許可 `ec2:DescribeSnapshotTierStatus` を追加しました。 Amazon Aurora の継続的バックアップをサポートするために、アクセス許可 `rds:DescribeDBClusterAutomatedBackups` を追加しました。 Amazon Redshift バックアップの復元テストをサポートするために、以下のアクセス許可を追加しました: `redshift:DescribeClusters` および `redshift:DeleteCluster`。 Amazon Timestream バックアップの復元テストをサポートするために、アクセス許可 `timestream:DeleteTable` を追加しました。 | 2024 年 2 月 14 日 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – 既存のポリシーの更新 | アクセス許可 `ec2:DescribeSnapshotTierStatus` および `ec2:RestoreSnapshotTier` を追加しました。 これらのアクセス許可は、 に保存された Amazon EBS リソースをアーカイブストレージ AWS Backup から復元するオプションをユーザーが持つために必要です。 EC2 インスタンスの復元では、EC2 インスタンスを起動するために次のポリシーステートメントに示されているアクセス許可も含める必要があります。 | 2023 年 11 月 27 日 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – 既存のポリシーの更新 | バックアップされた Amazon EBS リソースをアーカイブストレージ階層に移行するための追加のストレージオプションをサポートするために、アクセス許可 `ec2:DescribeSnapshotTierStatus` および `ec2:ModifySnapshotTier` を追加しました。 これらのアクセス許可は、 に保存されている Amazon EBS リソースをアーカイブストレージに移行するオプション AWS Backup をユーザーが持つために必要です。 | 2023 年 11 月 27 日 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – 既存のポリシーの更新 | バックアップされた Amazon EBS リソースをアーカイブストレージ階層に移行するための追加のストレージオプションをサポートするために、アクセス許可 `ec2:DescribeSnapshotTierStatus` および `ec2:ModifySnapshotTier` を追加しました。 これらのアクセス許可は、 に保存されている Amazon EBS リソースをアーカイブストレージに移行するオプション AWS Backup をユーザーが持つために必要です。 Aurora クラスターの PITR (ポイントインタイムリストア) に必要なアクセス許可 `rds:DescribeDBClusterSnapshots` および `rds:RestoreDBClusterToPointInTime` を追加しました。 |
| [AWSServiceRolePolicyForBackupRestoreTesting](#AWSServiceRolePolicyForBackupRestoreTesting) – 新しいポリシー | 復元テストを実行するために必要なアクセス許可を提供します。アクセス許可には、Aurora、DocumentDB、DynamoDB、Amazon EBS、Amazon EC2、Amazon EFS、FSx for Lustre、FSx for Windows File Server、FSx for ONTAP、FSx for OpenZFS、Amazon Neptune、Amazon RDS、Amazon S3 といったサービスを復元テストに含めるための、`list, read, and write` アクションが含まれます。 | 2023 年 11 月 27 日 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – 既存のポリシーの更新 | `restore-testing.backup.amazonaws.com`が`IamPassRolePermissions`と`IamCreateServiceLinkedRolePermissions`に追加されました。この追加は、 がお客様に代わって復元テストを実行する AWS Backup ために必要です。 | 2023 年 11 月 27 日 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – 既存のポリシーの更新 | Aurora クラスターの PITR (ポイントインタイムリストア) に必要なアクセス許可 `rds:DescribeDBClusterSnapshots` および `rds:RestoreDBClusterToPointInTime` を追加しました。 | 2023 年 9 月 6 日 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – 既存のポリシーの更新 | Aurora クラスターの継続的バックアップとポイントインタイムリストアに必要なアクセス許可 `rds:DescribeDBClusterAutomatedBackups` を追加しました。 | 2023 年 9 月 6 日 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – 既存のポリシーの更新 | Aurora クラスターの継続的バックアップとポイントインタイムリストアに必要なアクセス許可 `rds:DescribeDBClusterAutomatedBackups` を追加しました。 | 2023 年 9 月 6 日 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – 既存のポリシーの更新 | アクセス許可 `rds:DescribeDBClusterAutomatedBackups` を追加しました。このアクセス許可は、Aurora クラスターの継続的なバックアップとpoint-in-time復元 AWS Backup をサポートするために必要です。 保持期間が終了したときに AWS Backup 、ライフサイクルが Amazon Aurora 継続的復旧ポイントを削除および関連付け解除`rds:DeleteDBClusterAutomatedBackups`できるようにするアクセス許可を追加しました。このアクセス許可は、Aurora 復旧ポイントが `EXIPIRED` の状態への移行を回避するために必要です。 Aurora クラスターとのやり取りを AWS Backup に許可するアクセス許可 `rds:ModifyDBCluster` を追加しました。この追加により、ユーザーは必要な設定に基づいて継続的バックアップを有効または無効にすることができます。 | 2023 年 9 月 6 日 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – 既存のポリシーの更新 | 新しいボールトタイプのリソース共有の関連付けを取得するアクセス許可をユーザーに付与するために、アクション `ram:GetResourceShareAssociations` を追加しました。 | 2023 年 8 月 8 日 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – 既存のポリシーの更新 | 新しいボールトタイプのリソース共有の関連付けを取得するアクセス許可をユーザーに付与するために、アクション `ram:GetResourceShareAssociations` を追加しました。 | 2023 年 8 月 8 日 |
| [AWSBackupServiceRolePolicyForS3Backup](#AWSBackupServiceRolePolicyForS3Backup) – 既存のポリシーの更新 | バケットインベントリを使用してバックアップのパフォーマンス速度を向上させるために、アクセス許可 `s3:PutInventoryConfiguration` を追加しました。 | 2023 年 8 月 1 日 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – 既存のポリシーの更新 | リソースを復元するためのタグを追加するアクセス許可をユーザーに付与するために、以下のアクションを追加しました: `storagegateway:AddTagsToResource`、`elasticfilesystem:TagResource`、(`RunInstances` または `CreateVolume` のいずれかを含む `ec2:CreateAction` の場合のみ `ec2:CreateTags`)、`fsx:TagResource`、および `cloudformation:TagResource`。 | 2023 年 5 月 22 日 |
| [AWSBackupAuditAccess](#AWSBackupAuditAccess) – 既存のポリシーの更新 | API `config:DescribeComplianceByConfigRule` 内のリソース選択をワイルドカードリソースに置き換え、ユーザーがリソースを簡単に選択できるようにしました。 | 2023 年 4 月 11 日 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – 既存のポリシーの更新 | カスタマー管理キーを使用して Amazon EFS を復元するために、以下のアクセス許可を追加しました: `kms:GenerateDataKeyWithoutPlaintext`。これは、ユーザーが Amazon EFS リソースを復元するために必要なアクセス許可を持っていることを確認するために役立ちます。 | 2023 年 3 月 27 日 |
| [AWSServiceRolePolicyForBackupReports](#AWSServiceRolePolicyForBackupReports) – 既存のポリシーの更新 | Audit Manager が Audit Manager マネージド AWS Config ルールにアクセスできるように AWS Backup 、 `config:DescribeConfigRules` および AWS Backup `config:DescribeConfigRuleEvaluationStatus`アクションを更新しました。 | 2023 年 3 月 9 日 |
| [AWSBackupServiceRolePolicyForS3Restore](#AWSBackupServiceRolePolicyForS3Restore) – 既存のポリシーの更新 | `kms:Decrypt`、`s3:PutBucketOwnershipControls`、および `s3:GetBucketOwnershipControls` のアクセス許可をポリシー `AWSBackupServiceRolePolicyForS3Restore` に追加しました。これらのアクセス許可は、元のバックアップで KMS 暗号化が使用されている場合はオブジェクトの復元をサポートし、オブジェクトの所有権が ACL ではなく元のバケットに設定されている場合にオブジェクトを復元するために必要です。 | 2023 年 2 月 13 日 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – 既存のポリシーの更新 | 仮想マシンの VMware タグを使用してバックアップをスケジュールしたり、スケジュールベースの帯域幅スロットリングをサポートしたりするために、以下のアクセス許可を追加しました: `backup-gateway:GetHypervisorPropertyMappings`、`backup-gateway:GetVirtualMachine`、`backup-gateway:PutHypervisorPropertyMappings`、`backup-gateway:GetHypervisor`、`backup-gateway:StartVirtualMachinesMetadataSync`、`backup-gateway:GetBandwidthRateLimitSchedule`、および `backup-gateway:PutBandwidthRateLimitSchedule`。 | 2022 年 12 月 15 日 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – 既存のポリシーの更新 | 仮想マシンの VMware タグを使用してバックアップをスケジュールしたり、スケジュールベースの帯域幅スロットリングをサポートしたりするために、以下のアクセス許可を追加しました: `backup-gateway:GetHypervisorPropertyMappings`、`backup-gateway:GetVirtualMachine`、`backup-gateway:GetHypervisor`、および `backup-gateway:GetBandwidthRateLimitSchedule`。 | 2022 年 12 月 15 日 |
| [AWSBackupGatewayServiceRolePolicyForVirtualMachineMetadataSync](#AWSBackupGatewayServiceRolePolicyForVirtualMachineMetadataSync) – 新しいポリシー | オンプレミスネットワーク内の仮想マシンのメタデータを Backup AWS Backup Gateway と同期するためのアクセス許可を Gateway に提供します。 | 2022 年 12 月 15 日 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – 既存のポリシーの更新 | Timestream バックアップジョブをサポートするために、以下のアクセス許可を追加しました: `timestream:StartAwsBackupJob`、`timestream:GetAwsBackupStatus`、`timestream:ListTables`、`timestream:ListDatabases`、`timestream:ListTagsForResource`、`timestream:DescribeTable`、`timestream:DescribeDatabase`、および `timestream:DescribeEndpoints`。 | 2022 年 12 月 13 日 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – 既存のポリシーの更新 | Timestream 復元ジョブをサポートするために、以下のアクセス許可を追加しました: `timestream:StartAwsRestoreJob`、`timestream:GetAwsRestoreStatus`、`timestream:ListTables`、`timestream:ListTagsForResource`、`timestream:ListDatabases`、`timestream:DescribeTable`、`timestream:DescribeDatabase`、`s3:GetBucketAcl`、および `timestream:DescribeEndpoints`。 | 2022 年 12 月 13 日 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – 既存のポリシーの更新 | Timestream リソースをサポートするために、以下のアクセス許可を追加しました: `timestream:ListTables`、`timestream:ListDatabases`、`s3:ListAllMyBuckets`、および `timestream:DescribeEndpoints`。 | 2022 年 12 月 13 日 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – 既存のポリシーの更新 | Timestream リソースをサポートするために、以下のアクセス許可を追加しました: `timestream:ListDatabases`、`timestream:ListTables`、`s3:ListAllMyBuckets`、および `timestream:DescribeEndpoints`。 | 2022 年 12 月 13 日 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – 既存のポリシーの更新 | Timestream リソースをサポートするために、以下のアクセス許可を追加しました: `timestream:ListDatabases`、`timestream:ListTables`、`timestream:ListTagsForResource`、`timestream:DescribeDatabase`、`timestream:DescribeTable`、`timestream:GetAwsBackupStatus`、`timestream:GetAwsRestoreStatus`、および `timestream:DescribeEndpoints`。 | 2022 年 12 月 13 日 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – 既存のポリシーの更新 | Amazon Redshift リソースをサポートするために、以下のアクセス許可を追加しました: `redshift:DescribeClusters`、`redshift:DescribeClusterSubnetGroups`、`redshift:DescribeNodeConfigurationOptions`、`redshift:DescribeOrderableClusterOptions`、`redshift:DescribeClusterParameterGroups`、`redshift:DescribeClusterTracks`、`redshift:DescribeSnapshotSchedules`、および `ec2:DescribeAddresses`。 | 2022 年 11 月 27 日 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – 既存のポリシーの更新 | Amazon Redshift リソースをサポートするために、以下のアクセス許可を追加しました: `redshift:DescribeClusters`、`redshift:DescribeClusterSubnetGroups`、`redshift:DescribeNodeConfigurationOptions`、`redshift:DescribeOrderableClusterOptions`、`redshift:DescribeClusterParameterGroups,`、`redshift:DescribeClusterTracks`、`redshift:DescribeSnapshotSchedules`、および `ec2:DescribeAddresses`。 | 2022 年 11 月 27 日 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – 既存のポリシーの更新 | Amazon Redshift 復元ジョブをサポートするために、以下のアクセス許可を追加しました: `redshift:RestoreFromCluster Snapshot`、`redshift:RestoreTableFromClusterSnapshot`、`redshift:DescribeClusters`、および `redshift:DescribeTableRestoreStatus`。 | 2022 年 11 月 27 日 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – 既存のポリシーの更新 | Amazon Redshift バックアップジョブをサポートするために、以下のアクセス許可を追加しました: `redshift:CreateClusterSnapshot`、`redshift:DescribeClusterSnapshots`、`redshift:DescribeTags`、`redshift:DeleteClusterSnapshot`、`redshift:DescribeClusters`、および `redshift:CreateTags`。 | 2022 年 11 月 27 日 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – 既存のポリシーの更新 | CloudFormation リソースをサポートするために、以下のアクセス許可を追加しました: `cloudformation:ListStacks`。 | 2022 年 11 月 27 日 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – 既存のポリシーの更新 | CloudFormation リソースをサポートするために、以下のアクセス許可を追加しました: `cloudformation:ListStacks`。 | 2022 年 11 月 27 日 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – 既存のポリシーの更新 | CloudFormation リソースをサポートするために、以下のアクセス許可を追加しました: `redshift:DescribeClusterSnapshots`、`redshift:DescribeTags`、`redshift:DeleteClusterSnapshot`、および `redshift:DescribeClusters`。 | 2022 年 11 月 27 日 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – 既存のポリシーの更新 | CloudFormation アプリケーションスタックのバックアップジョブをサポートするために`cloudformation:GetTemplate`、、`cloudformation:DescribeStacks`、および のアクセス許可を追加しました`cloudformation:ListStackResources`。 | 2022 年 11 月 16 日 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – 既存のポリシーの更新 | CloudFormation アプリケーションスタックのバックアップジョブをサポートするために、次のアクセス許可を追加`cloudformation:CreateChangeSet`しました。 `cloudformation:DescribeChangeSet` | 2022 年 11 月 16 日 |
| [AWSBackupOrganizationAdminAccess](#AWSBackupOrganizationAdminAccess) – 既存のポリシーの更新 | このポリシーに以下のアクセス許可を追加し、組織管理者が委任管理者機能を使用できるようにしました: `organizations:ListDelegatedAdministrator`、`organizations:RegisterDelegatedAdministrator`、および `organizations:DeregisterDelegatedAdministrator` | 2022 年 11 月 27 日 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – 既存のポリシーの更新 | Amazon EC2 インスタンスでの SAP HANA をサポートするために、以下のアクセス許可を追加しました: `ssm-sap:GetOperation`、`ssm-sap:ListDatabases`、`ssm-sap:BackupDatabase`、`ssm-sap:UpdateHanaBackupSettings`、`ssm-sap:GetDatabase`、および `ssm-sap:ListTagsForResource`。 | 2022 年 11 月 20 日 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – 既存のポリシーの更新 | Amazon EC2 インスタンスで SAP HANA をサポートするために、以下のアクセス許可を追加しました: `ssm-sap:GetOperation`、`ssm-sap:ListDatabases`、`ssm-sap:GetDatabase`、および `ssm-sap:ListTagsForResource`。 | 2022 年 11 月 20 日 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – 既存のポリシーの更新 | Amazon EC2 インスタンスで SAP HANA をサポートするために、以下のアクセス許可を追加しました: `ssm-sap:GetOperation`、`ssm-sap:ListDatabases`、`ssm-sap:GetDatabase`、および `ssm-sap:ListTagsForResource`。 | 2022 年 11 月 20 日 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – 既存のポリシーの更新 | Amazon EC2 インスタンスで SAP HANA をサポートするために、以下のアクセス許可を追加しました: `ssm-sap:GetOperation`。 | 2022 年 11 月 20 日 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – 既存のポリシーの更新 | EC2 インスタンスへの Backup ゲートウェイ復元ジョブをサポートするために、以下のアクセス許可を追加しました: `ec2:CreateTags`。 | 2022 年 11 月 20 日 |
| [AWSBackupDataTransferAccess](#AWSBackupDataTransferAccess) – 既存のポリシーの更新 | SAP HANA On Amazon EC2 リソースの安全なストレージデータ転送をサポートするために、以下のアクセス許可を追加しました: `backup-storage:StartObject`、`backup-storage:PutChunk`、`backup-storage:GetChunk`、`backup-storage:ListChunks`、`backup-storage:ListObjects`、`backup-storage:GetObjectMetadata`、および `backup-storage:NotifyObjectComplete`。 | 2022 年 11 月 20 日 |
| [AWSBackupRestoreAccessForSAPHANA](#AWSBackupRestoreAccessForSAPHANA) – 既存のポリシーの更新 | リソース所有者が SAP HANA On Amazon EC2 リソースの復元を実行するために、以下のアクセス許可を追加しました: `backup:Get*`、`backup:List*`、`backup:Describe*`、`backup:StartBackupJob`、`backup:StartRestoreJob`、`ssm-sap:GetOperation`、`ssm-sap:ListDatabases`、`ssm-sap:BackupDatabase`、`ssm-sap:RestoreDatabase`、`ssm-sap:UpdateHanaBackupSettings`、`ssm-sap:GetDatabase`、および `ssm-sap:ListTagsForResource`。 | 2022 年 11 月 20 日 |
| [AWSBackupServiceRolePolicyForS3Backup](#AWSBackupServiceRolePolicyForS3Backup) – 既存のポリシーの更新 | for Amazon S3 のバックアップオペレーション`s3:GetBucketAcl`をサポートするアクセス許可を追加 AWS Backup しました。 | 2022 年 8 月 24 日 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – 既存のポリシーの更新 | マルチアベイラビリティーゾーン (マルチ AZ) 機能をサポートするデータベースインスタンスを作成するアクセス許可を付与するために、以下のアクションを追加しました: `rds:CreateDBInstance`。 | 2022 年 7 月 20 日 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – 既存のポリシーの更新 | リソースワイルドカードを使用して、バックアップするバケットを選択するアクセス許可をユーザーに付与するために、`s3:GetBucketTagging` アクセス許可を追加しました。このアクセス許可がないと、リソースワイルドカードを使用してバックアップするバケットをユーザーが選択しても失敗します。 | 2022 年 5 月 6 日 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – 既存のポリシーの更新 | 既存の `fsx:CreateBackup` および `fsx:ListTagsForResource` アクションの範囲にボリュームリソースを追加するとともに、FSx for ONTAP ボリュームレベルのバックアップをサポートする新しいアクション `fsx:DescribeVolumes` を追加しました。 | 2022 年 4 月 27 日 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – 既存のポリシーの更新 | FSx for ONTAP ボリュームを復元するアクセス許可をユーザーに付与するために、以下のアクションを追加しました: `fsx:DescribeVolumes`、`fsx:CreateVolumeFromBackup`、`fsx:DeleteVolume`、および `fsx:UntagResource`。 | 2022 年 4 月 27 日 |
| [AWSBackupServiceRolePolicyForS3Backup](#AWSBackupServiceRolePolicyForS3Backup) – 既存のポリシーの更新 | バックアップ操作中に Amazon S3 バケットへの変更の通知を受信するアクセス許可をユーザーに付与するために、以下のアクションを追加しました: `s3:GetBucketNotification` および `s3:PutBucketNotification`。 | 2022 年 2 月 25 日 |
| [AWSBackupServiceRolePolicyForS3Backup](#AWSBackupServiceRolePolicyForS3Backup) – 新しいポリシー | Amazon S3 バケットをバックアップするアクセス許可をユーザーに付与するために、以下のアクションを追加しました: `s3:GetInventoryConfiguration`、`s3:PutInventoryConfiguration`、`s3:ListBucketVersions`、`s3:ListBucket`、`s3:GetBucketTagging`、`s3:GetBucketVersioning`、`s3:GetBucketNotification`、`s3:GetBucketLocation`、および `s3:ListAllMyBuckets`。 Amazon S3 バケットオブジェクトをバックアップするアクセス許可をユーザーに付与するために、以下のアクションを追加しました: `s3:GetObject`、`s3GetObjectAcl`、`s3:GetObjectVersionTagging`、`s3:GetObjectVersionAcl`、`s3:GetObjectTagging`、および `s3:GetObjectVersion`。 暗号化された Amazon S3 データをバックアップするアクセス許可をユーザーに付与するために、以下のアクションを追加しました: `kms:Decrypt` および `kms:DescribeKey`。 Amazon EventBridge ルールを使用して Amazon S3 データの増分バックアップを作成するアクセス許可をユーザーに付与するために、以下のアクションを追加しました: `events:DescribeRule`、`events:EnableRule`、`events:PutRule`、`events:DeleteRule`、`events:PutTargets`、`events:RemoveTargets`、`events:ListTargetsByRule`、`events:DisableRule`、`cloudwatch:GetMetricData`、および `events:ListRules`。 | 2022 年 2 月 17 日 |
| [AWSBackupServiceRolePolicyForS3Restore](#AWSBackupServiceRolePolicyForS3Restore) – 新しいポリシー | Amazon S3 バケットを復元するアクセス許可をユーザーに付与するために、以下のアクションを追加しました: `s3:CreateBucket`、`s3:ListBucketVersions`、`s3:ListBucket`、`s3:GetBucketVersioning`、`s3:GetBucketLocation`、および `s3:PutBucketVersioning`。 Amazon S3 バケットを復元するアクセス許可をユーザーに付与するために、以下のアクションを追加しました: `s3:GetObject`、`s3:GetObjectVersion`、`s3:DeleteObject`、`s3:PutObjectVersionAcl`、`s3:GetObjectVersionAcl`、`s3:GetObjectTagging`、`s3:PutObjectTagging`、`s3:GetObjectAcl`、`s3:PutObjectAcl`、`s3:PutObject`、および `s3:ListMultipartUploadParts`。 復元された Amazon S3 データを暗号化するアクセス許可をユーザーに付与するために、以下のアクションを追加しました: `kms:Decrypt`、`kms:DescribeKey`、および `kms:GenerateDataKey`。 | 2022 年 2 月 17 日 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – 既存のポリシーの更新 | バケットのリストを表示し、バックアッププランに割り当てるバケットを選択するアクセス許可をユーザーに付与するために、`s3:ListAllMyBuckets` を追加しました。 | 2022 年 2 月 14 日 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – 既存のポリシーの更新 | 仮想マシンのリストを表示し、バックアッププランに割り当てる仮想マシンを選択するアクセス許可をユーザーに付与するために、`backup-gateway:ListVirtualMachines` を追加しました。 仮想マシンのタグを一覧表示するアクセス許可をユーザーに付与するために、`backup-gateway:ListTagsForResource` を追加しました。 | 2021 年 11 月 30 日 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – 既存のポリシーの更新 | 仮想マシンのバックアップを復元するアクセス許可をユーザーに付与`backup-gateway:Backup`するために を追加しました。 AWS Backup また、仮想マシンのバックアップに割り当てられたタグを一覧表示するアクセス許可をユーザーに`backup-gateway:ListTagsForResource`付与するために を追加しました。 | 2021 年 11 月 30 日 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – 既存のポリシーの更新 | 仮想マシンのバックアップを復元するアクセス許可をユーザーに付与するために、`backup-gateway:Restore` を追加しました。 | 2021 年 11 月 30 日 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – 既存のポリシーの更新 | 仮想マシンをバックアップ、復元、および管理するために AWS Backup ゲートウェイを使用するアクセス許可をユーザーに付与するために、以下のアクションを追加しました: `backup-gateway:AssociateGatewayToServer`、`backup-gateway:CreateGateway`、`backup-gateway:DeleteGateway`、`backup-gateway:DeleteHypervisor`、`backup-gateway:DisassociateGatewayFromServer`、`backup-gateway:ImportHypervisorConfiguration`、`backup-gateway:ListGateways`、`backup-gateway:ListHypervisors`、`backup-gateway:ListTagsForResource`、`backup-gateway:ListVirtualMachines`、`backup-gateway:PutMaintenanceStartTime`、`backup-gateway:TagResource`、`backup-gateway:TestHypervisorConfiguration`、`backup-gateway:UntagResource`、`backup-gateway:UpdateGatewayInformation`、および `backup-gateway:UpdateHypervisor`。 | 2021 年 11 月 30 日 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – 既存のポリシーの更新 | 仮想マシンをバックアップするアクセス許可をユーザーに付与するために、以下のアクションを追加しました: `backup-gateway:ListGateways`、`backup-gateway:ListHypervisors`、`backup-gateway:ListTagsForResource`、および `backup-gateway:ListVirtualMachines`。 | 2021 年 11 月 30 日 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – 既存のポリシーの更新 | `dynamodb:ListTagsOfResource` の高度な DynamoDB バックアップ機能を使用してバックアップする DynamoDB テーブルのタグを一覧表示するアクセス許可をユーザーに付与するために を追加 AWS Backupしました。 | 2021 年 11 月 23 日 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – 既存のポリシーの更新 | 高度なバックアップ機能を使用して DynamoDB テーブルをバックアップするアクセス許可をユーザーに付与するために、`dynamodb:StartAwsBackupJob` を追加しました。 ソースの DynamoDB テーブルからバックアップにタグをコピーするアクセス許可をユーザーに付与するために、`dynamodb:ListTagsOfResource` を追加しました。 | 2021 年 11 月 23 日 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – 既存のポリシーの更新 | 高度な DynamoDB バックアップ機能を使用してバックアップされた DynamoDB テーブル AWS Backupを復元するアクセス許可をユーザーに付与`dynamodb:RestoreTableFromAwsBackup`するために を追加しました。 | 2021 年 11 月 23 日 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – 既存のポリシーの更新 | 高度な DynamoDB バックアップ機能を使用してバックアップされた DynamoDB テーブル AWS Backupを復元するアクセス許可をユーザーに付与`dynamodb:RestoreTableFromAwsBackup`するために を追加しました。 | 2021 年 11 月 23 日 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – 既存のポリシーの更新 | アクション `backup:GetRecoveryPointRestoreMetadata` および `rds:DescribeDBSnapshots` は冗長であったため、削除しました。 AWS Backup は、 `backup:Get*` の一部として `backup:GetRecoveryPointRestoreMetadata`と の両方を必要としませんでした`AWSBackupOperatorAccess`。また、 `rds:describeDBSnapshots`の一部として `rds:DescribeDBSnapshots`と の両方は必要ありません AWS Backup でした`AWSBackupOperatorAccess`。 | 2021 年 11 月 23 日 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – 既存のポリシーの更新 | 新しいアクション `elasticfilesystem:DescribeFileSystems`、`dynamodb:ListTables`、、`storagegateway:ListVolumes`、`ec2:DescribeVolumes`、`ec2:DescribeInstances``rds:DescribeDBInstances`、、 が追加され`fsx:DescribeFileSystems`ました。これにより`rds:DescribeDBClusters`、バックアッププランに割り当てる AWS Backupリソースを選択する際に、サポートされているリソースのリストを表示して選択できます。 | 2021 年 11 月 10 日 |
| [AWSBackupAuditAccess](#AWSBackupAuditAccess) – 新しいポリシー | AWS Backup Audit Manager を使用するためのアクセス許可をユーザーに付与するために を追加`AWSBackupAuditAccess`しました。権限には、コンプライアンスフレームワークを設定し、レポートを生成する機能が含まれます。 | 2021 年 8 月 24 日 |
| [AWSServiceRolePolicyForBackupReports](#AWSServiceRolePolicyForBackupReports) – 新しいポリシー | ユーザーが設定したフレームワークに準拠するためのバックアップ設定、ジョブ、およびリソースのモニタリングを自動化する目的で、サービスにリンクされたロールに対するアクセス許可を付与するため、`AWSServiceRolePolicyForBackupReports` を追加しました。 | 2021 年 8 月 24 日 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – 既存のポリシーの更新 | サービスにリンクされたロールを作成し (ベストエフォートベース)、期限切れの復旧ポイントの削除を自動化するために、`iam:CreateServiceLinkedRole` を追加しました。このサービスにリンクされたロールがない場合、お客様が復旧ポイントの作成に使用した元の IAM ロールを削除した後は、期限切れの復旧ポイントを削除 AWS Backup することはできません。 | 2021 年 7 月 5 日 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – 既存のポリシーの更新 | バックアッププランのライフサイクル設定に基づき、期限切れの DynamoDB 復旧ポイントの削除を自動化する `DeleteRecoveryPoint` アクセス許可を付与するために、新しいアクション `dynamodb:DeleteBackup` を追加しました。 | 2021 年 7 月 5 日 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – 既存のポリシーの更新 | アクション `backup:GetRecoveryPointRestoreMetadata` および `rds:DescribeDBSnapshots` は冗長であったため、削除しました。 AWS Backup は、 `backup:Get*`の一部として `backup:GetRecoveryPointRestoreMetadata`と の両方を必要としませんでした`AWSBackupOperatorAccess`。また、 `rds:describeDBSnapshots`の一部として `rds:DescribeDBSnapshots`と AWS Backup の両方を必要としませんでした。 `AWSBackupOperatorAccess` | 2021 年 5 月 25 日 |
| [AWSBackupOperatorAccess](#AWSBackupOperatorAccess) – 既存のポリシーの更新 | アクション `backup:GetRecoveryPointRestoreMetadata` および `rds:DescribeDBSnapshots` は冗長であったため、削除しました。 AWS Backup は、 `backup:Get*` の一部として `backup:GetRecoveryPointRestoreMetadata`と の両方を必要としませんでした`AWSBackupOperatorAccess`。また、 `rds:describeDBSnapshots`の一部として `rds:DescribeDBSnapshots`と の両方は必要ありません AWS Backup でした`AWSBackupOperatorAccess`。 | 2021 年 5 月 25 日 |
| [AWSBackupServiceRolePolicyForRestores]() – 既存のポリシーの更新 | 復元プロセス中に Amazon FSx ファイルシステムにタグを適用できる `StartRestoreJob` アクセス許可を付与するために、新しいアクション `fsx:TagResource` を追加しました。 | 2021 年 5 月 24 日 |
| [AWSBackupServiceRolePolicyForRestores](#AWSBackupServiceRolePolicyForRestores) – 既存のポリシーの更新 | 復旧ポイントから Amazon EC2 インスタンスを復元できる `StartRestoreJob` アクセス許可を付与するために、新しいアクション `ec2:DescribeImages` および `ec2:DescribeInstances` を追加しました。 | 2021 年 5 月 24 日 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – 既存のポリシーの更新 | リージョンとアカウント全体で Amazon FSx 復旧ポイントをコピーできるようにする `StartCopyJob` アクセス許可を付与するために、新しいアクション `fsx:CopyBackup` を追加しました。 | 2021 年 4 月 12 日 |
| [AWSBackupServiceLinkedRolePolicyForBackup](#AWSBackupServiceLinkedRolePolicyForBackup) – 既存のポリシーの更新 | リージョンとアカウント全体で Amazon FSx 復旧ポイントをコピーできるようにする `StartCopyJob` アクセス許可を付与するために、新しいアクション `fsx:CopyBackup` を追加しました。 | 2021 年 4 月 12 日 |
| [AWSBackupServiceRolePolicyForBackup](#AWSBackupServiceRolePolicyForBackup) – 既存のポリシーの更新 | 更新により、次の要件に準拠しました。 AWS Backup で暗号化された DynamoDB テーブルのバックアップを作成するには、バックアップに使用される IAM ロール`kms:GenerateDataKey`にアクセス許可`kms:Decrypt`と を追加する必要があります。 | 2021 年 3 月 10 日 |
| [AWSBackupFullAccess](#AWSBackupFullAccess) – 既存のポリシーの更新 | 更新により、次の要件に準拠しました。 AWS Backup を使用して Amazon RDS データベースの継続的バックアップを設定するには、バックアッププラン設定で定義された IAM ロールに API アクセス許可`rds:ModifyDBInstance`が存在することを確認します。 Amazon RDS 連続バックアップをリストアするには、リストアジョブ用に送信した IAM ロールに `rds:RestoreDBInstanceToPointInTime` 権限を追加する必要があります。 AWS Backup コンソールで、point-in-timeリカバリに使用できる時間の範囲を記述するには、IAM 管理ポリシーに `rds:DescribeDBInstanceAutomatedBackups` API アクセス許可を含める必要があります。 | 2021 年 3 月 10 日 |
| AWS Backup が変更の追跡を開始しました | AWS Backup は AWS、管理ポリシーの変更の追跡を開始しました。 | 2021 年 3 月 10 日 |
# のサービスにリンクされたロールの使用 AWS Backup
AWS Backup は AWS Identity and Access Management (IAM)[ サービスにリンクされたロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts)を使用します。サービスにリンクされたロールは、直接リンクされた一意のタイプの IAM ロールです AWS Backup。サービスにリンクされたロールは によって事前定義 AWS Backup されており、サービスがユーザーに代わって他の AWS サービスを呼び出すために必要なすべてのアクセス許可が含まれています。
**Topics**
+ [ロールを使用したバックアップとコピー](using-service-linked-roles-AWSServiceRoleForBackup.md)
+ [AWS Backup Audit Manager のロールの使用](using-service-linked-roles-AWSServiceRoleForBackupReports.md)
+ [復元テストでロールを使用する](using-service-linked-roles-AWSServiceRoleForBackupRestoreTesting.md)
# ロールを使用したバックアップとコピー
AWS Backup は AWS Identity and Access Management (IAM)[ サービスにリンクされたロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts)を使用します。サービスにリンクされたロールは、直接リンクされた一意のタイプの IAM ロールです AWS Backup。サービスにリンクされたロールは によって事前定義 AWS Backup されており、サービスがユーザーに代わって他の AWS サービスを呼び出すために必要なすべてのアクセス許可が含まれています。
サービスにリンクされたロールを使用すると、必要なアクセス許可を手動で追加する必要がなくなるため、 の設定 AWS Backup が簡単になります。 は、サービスにリンクされたロールのアクセス許可 AWS Backup を定義し、特に定義されている場合を除き、 のみがそのロールを引き受け AWS Backup ることができます。定義されるアクセス許可には、信頼ポリシーと許可ポリシーが含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。
サービスリンクロールを削除するには、まずその関連リソースを削除します。これにより、 AWS Backup リソースへのアクセス許可が誤って削除されないため、リソースが保護されます。
サービスにリンクされたロールをサポートする他のサービスについては、「[IAM と連携するAWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照して、**サービスにリンクされたロール**列が**はい**になっているサービスを見つけてください。サービスにリンクされた役割に関するドキュメントをサービスで表示するには[**はい**] リンクを選択してください。
## のサービスにリンクされたロールのアクセス許可 AWS Backup
AWS Backup は、**AWSServiceRoleForBackup** という名前のサービスにリンクされたロールを使用して、ユーザーに代わって AWS リソースのバックアップを作成および削除します。
サービスにリンクされた AWSServiceRoleForBackup ロールは、以下のサービスを信頼してロールを引き受けます。
+ `backup.amazonaws.com`
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AWSBackupServiceLinkedRolePolicyforBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceLinkedRolePolicyForBackup.html)」を参照してください。
サービスリンクロールの作成、編集、削除を IAM エンティティ (ユーザー、グループ、ロールなど) に許可するにはアクセス許可を設定する必要があります。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割のアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html#service-linked-role-permissions)」を参照してください。
## のサービスにリンクされたロールの作成 AWS Backup
サービスリンクロールを手動で作成する必要はありません。、、または AWS API でバックアップ、クロスアカウントバックアップの設定 AWS マネジメントコンソール AWS CLI、またはバックアップを実行するリソースを一覧表示すると、 AWS Backup によってサービスにリンクされたロールが作成されます。
**重要**
このサービスリンクロールは、このロールでサポートされている機能を使用する別のサービスでアクションが完了した場合にアカウントに表示されます。詳細については、「[IAM アカウントに新しいロールが表示される](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared)」を参照してください。
このサービスリンクロールを削除した後で再度作成する必要が生じた場合は、同じ手順でアカウントにロールを再作成できます。バックアップするリソースを一覧表示したり、クロスアカウントバックアップを設定したり、バックアップを実行したりすると、 はサービスにリンクされたロールを再度 AWS Backup 作成します。
## のサービスにリンクされたロールの編集 AWS Backup
AWS Backup では、AWSServiceRoleForBackup サービスにリンクされたロールを編集することはできません。サービスリンクロールの作成後は、さまざまなエンティティがロールを参照する可能性があるため、ロール名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については、「*IAM ユーザーガイド*」の「[サービスにリンクされたロールの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-service-linked-role.html#edit-service-linked-role-iam-console)」を参照してください。
## のサービスにリンクされたロールの削除 AWS Backup
サービスリンクロールを必要とする機能やサービスが不要になった場合は、ロールを削除することをお勧めします。そうすることで、モニタリングや保守が積極的に行われていない未使用のエンティティを排除できます。ただし、手動で削除する前に、サービスリンク役割をクリーンアップする必要があります。
### サービスリンク役割のクリーンアップ
IAM を使用してサービスにリンクされた役割を削除するには最初に、その役割で使用されているリソースをすべて削除する必要があります。まず、すべてのリカバリポイントを削除する必要があります。次に、すべてのバックアップ保管庫を削除する必要があります。
**注記**
リソースを削除しようとしたときに AWS Backup サービスがロールを使用している場合は、削除が失敗する可能性があります。失敗した場合は、数分待ってから再度オペレーションを実行してください。
**AWSServiceRoleForBackup で使用される AWS Backup リソースを削除するには (コンソール)**
1. すべての復旧ポイントとバックアップボールト (デフォルトボールトを除く) を削除するには、「[ボールトを削除する](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-a-vault.html#delete-a-vault)」の手順に従ってください。
1. デフォルトの保管庫を削除するには、 AWS CLIの次のコマンドを使用します。
```
aws backup delete-backup-vault --backup-vault-name Default --region us-east-1
```
**AWSServiceRoleForBackup で使用される AWS Backup リソースを削除するには (AWS CLI)**
1. すべての復旧ポイントを削除するには、[delete-recovery-point](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/delete-recovery-point.html) を使用します。
1. すべてのバックアップボールトを削除するには、[delete-backup-vault](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/delete-backup-vault.html) を使用します。
**AWSServiceRoleForBackup (API) で使用される AWS Backup リソースを削除するには**
1. すべてのリカバリポイントを削除するには、`[DeleteRecoveryPoint](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteRecoveryPoint.html)` を使用します。
1. バックアップ保管庫をすべて削除するには、`[DeleteBackupVault](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteBackupVault.html)` を使用します。
### サービスリンクロールの手動による削除
IAM コンソール、 AWS CLI、または AWS API を使用して、AWSServiceRoleForBackup サービスにリンクされたロールを削除します。詳細については、「IAM ユーザーガイド」の「[サービスにリンクされたロールの削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_delete.html#id_roles_manage_delete_slr)」を参照してください
## AWS Backup サービスにリンクされたロールでサポートされているリージョン
AWS Backup は、サービスが利用可能なすべてのリージョンでサービスにリンクされたロールの使用をサポートします。詳細については、[サポートされているAWS Backup 機能とリージョン](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html#features-by-region)を参照してください。
# AWS Backup Audit Manager のロールの使用
AWS Backup は AWS Identity and Access Management (IAM)[ サービスにリンクされたロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts)を使用します。サービスにリンクされたロールは、直接リンクされた一意のタイプの IAM ロールです AWS Backup。サービスにリンクされたロールは によって事前定義 AWS Backup されており、サービスがユーザーに代わって他の AWS サービスを呼び出すために必要なすべてのアクセス許可が含まれています。
サービスにリンクされたロールを使用すると、必要なアクセス許可を手動で追加する必要がなくなるため、 の設定 AWS Backup が簡単になります。 は、サービスにリンクされたロールのアクセス許可 AWS Backup を定義し、特に定義されている場合を除き、 のみがそのロールを引き受け AWS Backup ることができます。定義されるアクセス許可には、信頼ポリシーと許可ポリシーが含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。
サービスリンクロールを削除するには、まずその関連リソースを削除します。これにより、 AWS Backup リソースへのアクセス許可が誤って削除されないため、リソースが保護されます。
サービスにリンクされたロールをサポートする他のサービスについては、「[IAM と連携するAWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照して、**サービスにリンクされたロール**列が**はい**になっているサービスを見つけてください。サービスにリンクされた役割に関するドキュメントをサービスで表示するには[**はい**] リンクを選択してください。
## のサービスにリンクされたロールのアクセス許可 AWS Backup
AWS Backup は、**AWSServiceRoleForBackupReports** という名前のサービスにリンクされたロールを使用します – コントロール、フレームワーク、レポートを作成するアクセス許可 AWS Backup を付与します。
AWSServiceRoleForBackupReports サービスリンクロールは、以下のサービスを信頼してロールを引き受けます。
+ `reports.backup.amazonaws.com`
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AWSServiceRolePolicyForBackupReports](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRolePolicyForBackupReports.html)」を参照してください。
サービスリンクロールの作成、編集、削除を IAM エンティティ (ユーザー、グループ、ロールなど) に許可するにはアクセス許可を設定する必要があります。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割のアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html#service-linked-role-permissions)」を参照してください。
## のサービスにリンクされたロールの作成 AWS Backup
サービスリンクロールを手動で作成する必要はありません。 AWS マネジメントコンソール、、または AWS API でフレームワーク AWS CLIまたはレポートプランを作成すると、 AWS Backup によってサービスにリンクされたロールが作成されます。
**重要**
このサービスリンクロールは、このロールでサポートされている機能を使用する別のサービスでアクションが完了した場合にアカウントに表示されます。詳細については、「[IAM アカウントに新しいロールが表示される](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared)」を参照してください。
このサービスリンクロールを削除した後で再度作成する必要が生じた場合は、同じ手順でアカウントにロールを再作成できます。フレームワークまたはレポートプランを作成すると、 はサービスにリンクされたロールを再度 AWS Backup 作成します。
## のサービスにリンクされたロールの編集 AWS Backup
AWS Backup では、AWSServiceRoleForBackupReports サービスにリンクされたロールを編集することはできません。サービスリンクロールの作成後は、さまざまなエンティティがロールを参照する可能性があるため、ロール名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については、「*IAM ユーザーガイド*」の「[サービスにリンクされたロールの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-service-linked-role.html#edit-service-linked-role-iam-console)」を参照してください。
## のサービスにリンクされたロールの削除 AWS Backup
サービスリンクロールを必要とする機能やサービスが不要になった場合は、ロールを削除することをお勧めします。そうすることで、モニタリングや保守が積極的に行われていない未使用のエンティティを排除できます。ただし、手動で削除する前に、サービスリンク役割をクリーンアップする必要があります。
### サービスリンク役割のクリーンアップ
IAM を使用してサービスにリンクされた役割を削除するには最初に、その役割で使用されているリソースをすべて削除する必要があります。すべてのフレームワークとレポートプランを削除する必要があります。
**注記**
リソースを削除しようとしたときに AWS Backup サービスがロールを使用している場合は、削除が失敗する可能性があります。失敗した場合は、数分待ってから再度オペレーションを実行してください。
**AWSServiceRoleForBackupReports で使用される AWS Backup リソースを削除するには (コンソール)**
1. すべてのフレームワークを削除するには、「[フレームワークの削除](https://docs.aws.amazon.com/aws-backup/latest/devguide/deleting-frameworks.html)」を参照してください。
1. すべてのレポートプランを削除するには、「[レポートプランの削除](https://docs.aws.amazon.com/aws-backup/latest/devguide/delete-report-plan.html)」を参照してください。
**AWSServiceRoleForBackupReports で使用される AWS Backup リソースを削除するには (AWS CLI)**
1. すべてのフレームワークを削除するには、[delete-framework](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/delete-framework.html) を使用してください。
1. すべてのレポートプランを削除するには、[delete-report-plan](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/delete-report-plan.html) を使用してください。
**AWSServiceRoleForBackupReports (API) で使用される AWS Backup リソースを削除するには**
1. すべてのフレームワークを削除するには、[DeleteFramework](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteFramework.html) を使用してください。
1. すべてのレポートプランを削除するには、[DeleteReportPlan](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteReportPlan.html) を使用してください。
### サービスリンク役割の手動による削除
IAM コンソール、 AWS CLI、または AWS API を使用して、AWSServiceRoleForBackupReports サービスにリンクされたロールを削除します。詳細については、「IAM ユーザーガイド」の「[サービスにリンクされたロールの削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_delete.html#id_roles_manage_delete_slr)」を参照してください
## AWS Backup サービスにリンクされたロールでサポートされているリージョン
AWS Backup は、サービスが利用可能なすべてのリージョンでサービスにリンクされたロールの使用をサポートします。詳細については、[サポートされているAWS Backup 機能とリージョン](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html#features-by-region)を参照してください。
# 復元テストでロールを使用する
AWS Backup は AWS Identity and Access Management (IAM)[ サービスにリンクされたロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts)を使用します。サービスにリンクされたロールは、直接リンクされた一意のタイプの IAM ロールです AWS Backup。サービスにリンクされたロールは によって事前定義 AWS Backup されており、サービスがユーザーに代わって他の AWS サービスを呼び出すために必要なすべてのアクセス許可が含まれています。
サービスにリンクされたロールを使用すると、必要なアクセス許可を手動で追加する必要がなくなるため、 の設定 AWS Backup が簡単になります。 は、サービスにリンクされたロールのアクセス許可 AWS Backup を定義し、特に定義されている場合を除き、 のみがそのロールを引き受け AWS Backup ることができます。定義されるアクセス許可には、信頼ポリシーと許可ポリシーが含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。
サービスリンクロールを削除するには、まずその関連リソースを削除します。これにより、 AWS Backup リソースへのアクセス許可が誤って削除されないため、リソースが保護されます。
サービスにリンクされたロールをサポートする他のサービスについては、「[IAM と連携するAWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照して、**サービスにリンクされたロール**列が**はい**になっているサービスを見つけてください。サービスにリンクされた役割に関するドキュメントをサービスで表示するには[**はい**] リンクを選択してください。
## のサービスにリンクされたロールのアクセス許可 AWS Backup
AWS Backup は、**AWSServiceRoleForBackupRestoreTesting** という名前のサービスにリンクされたロールを使用します。復元テストを実行するためのバックアップアクセス許可を提供します。
サービスにリンクされたロール **AWSServiceRoleForBackupRestoreTesting** は、以下のサービスを信頼してロールを引き受けます。
+ `restore-testing.backup.amazonaws.com`
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[AWSServiceRolePolicyForBackupRestoreTesting](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRolePolicyForBackupRestoreTesting.html)」を参照してください。
サービスリンクロールの作成、編集、削除を IAM エンティティ (ユーザー、グループ、ロールなど) に許可するにはアクセス許可を設定する必要があります。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割のアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html#service-linked-role-permissions)」を参照してください。
## のサービスにリンクされたロールの作成 AWS Backup
サービスリンクロールを手動で作成する必要はありません。 AWS マネジメントコンソール、、 AWS CLIまたは AWS API で復元テストを実行すると、 AWS Backup によってサービスにリンクされたロールが作成されます。
**重要**
このサービスリンクロールは、このロールでサポートされている機能を使用する別のサービスでアクションが完了した場合にアカウントに表示されます。詳細については、「[IAM アカウントに新しいロールが表示される](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared)」を参照してください。
このサービスリンクロールを削除した後で再度作成する必要が生じた場合は、同じ手順でアカウントにロールを再作成できます。復元テストを実行すると、 はサービスにリンクされたロールを再度 AWS Backup 作成します。
## のサービスにリンクされたロールの編集 AWS Backup
AWS Backup では、AWSServiceRoleForBackupRestoreTesting サービスにリンクされたロールを編集することはできません。サービスリンクロールの作成後は、さまざまなエンティティがロールを参照する可能性があるため、ロール名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については、「*IAM ユーザーガイド*」の「[サービスにリンクされたロールの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-service-linked-role.html#edit-service-linked-role-iam-console)」を参照してください。
## のサービスにリンクされたロールの削除 AWS Backup
サービスリンクロールを必要とする機能やサービスが不要になった場合は、ロールを削除することをお勧めします。そうすることで、モニタリングや保守が積極的に行われていない未使用のエンティティを排除できます。ただし、手動で削除する前に、サービスリンク役割をクリーンアップする必要があります。
### サービスリンク役割のクリーンアップ
IAM を使用してサービスにリンクされた役割を削除するには最初に、その役割で使用されているリソースをすべて削除する必要があります。すべての復元テストプランを削除する必要があります。
**注記**
リソースを削除しようとしたときに AWS Backup サービスがロールを使用している場合は、削除が失敗する可能性があります。失敗した場合は、数分待ってから再度オペレーションを実行してください。
**AWSServiceRoleForBackupRestoreTesting で使用される AWS Backup リソースを削除するには (コンソール)**
+ すべての復元テストプランを削除するには、「[復元テスト](https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing.html)」を参照してください。
**AWSServiceRoleForBackupRestoreTesting で使用される AWS Backup リソースを削除するには (AWS CLI)**
+ 復元テストプランを削除するには、`delete-restore-testing-plan` を使用します。
**AWSServiceRoleForBackupRestoreTesting (API) で使用される AWS Backup リソースを削除するには**
+ 復元テストプランを削除するには、`DeleteRestoreTestingPlan` を使用します。
### サービスリンク役割の手動による削除
IAM コンソール、 AWS CLI、または AWS API を使用して、**AWSServiceRoleForBackupRestoreTesting** サービスにリンクされたロールを削除します。詳細については、「IAM ユーザーガイド」の「[サービスにリンクされたロールの削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_delete.html#id_roles_manage_delete_slr)」を参照してください
## AWS Backup サービスにリンクされたロールでサポートされているリージョン
AWS Backup は、サービスが利用可能なすべてのリージョンでサービスにリンクされたロールの使用をサポートします。詳細については、[サポートされているAWS Backup 機能とリージョン](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html#features-by-region)を参照してください。
# サービス間の混乱した代理の防止
混乱した代理問題は、アクションを実行するためのアクセス許可を持たないエンティティが、より特権のあるエンティティにアクションの実行を強制できてしまう場合に生じる、セキュリティ上の問題です。では AWS、サービス間のなりすましにより、混乱した代理問題が発生する可能性があります。サービス間でのなりすましは、1 つのサービス (*呼び出し元サービス*) が、別のサービス (*呼び出し対象サービス*) を呼び出すときに発生する可能性があります。呼び出し元サービスは、本来ならアクセスすることが許可されるべきではない方法でその許可を使用して、別のお客様のリソースに対する処理を実行するように操作される場合があります。これを防ぐために、 は、アカウント内のリソースへのアクセス権が付与されたサービスプリンシパルを持つすべてのサービスのデータを保護するのに役立つツール AWS を提供します。
リソースポリシーで [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)および [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) グローバル条件コンテキストキーを使用して、 がリソースに別のサービス AWS Backup に付与するアクセス許可を制限することをお勧めします。両方のグローバル条件コンテキストキーを同じポリシーステートメントで使用する場合は、`aws:SourceAccount` 値と、`aws:SourceArn` 値に含まれるアカウントが、同じアカウント ID を示している必要があります。
を使用してユーザーに代わって Amazon AWS Backup SNS トピック AWS Backup を発行する場合、 の値はボールト`aws:SourceArn`である必要があります。 Amazon SNS
混乱した代理問題から保護するための最も効果的な方法は、リソースの完全な ARN を指定して `aws:SourceArn` グローバル条件コンテキストキーを使用することです。リソースの完全な ARN が不明な場合や、複数のリソースを指定する場合は、`aws:SourceArn` グローバルコンテキスト条件キーを使用して、ARN の未知部分をワイルドカード (`*`) で表します。例えば、`arn:aws::servicename::123456789012:*` です。
次のポリシー例は、 で `aws:SourceArn`および `aws:SourceAccount` グローバル条件コンテキストキーを使用して、混乱した代理問題 AWS Backup を防ぐ方法を示しています。このポリシーは、サービスプリンシパルがバックアップボールトで AWS アカウント 123456789012 に代わって動作している場合にのみ、サービスプリンシパル backup-storage.amazonaws.com に KMS アクションを実行する機能を付与します。
# のインフラストラクチャセキュリティ AWS Backup
マネージドサービスである AWS Backup は、 AWS グローバルネットワークセキュリティで保護されています。 AWS セキュリティサービスと がインフラストラクチャ AWS を保護する方法の詳細については、[AWS 「 クラウドセキュリティ](https://aws.amazon.com/security/)」を参照してください。インフラストラクチャセキュリティのベストプラクティスを使用して AWS 環境を設計するには、*「Security Pillar AWS Well‐Architected Framework*」の[「Infrastructure protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)」を参照してください。
AWS が発行した API コールを使用して、ネットワーク AWS Backup 経由で にアクセスします。クライアントは、Transport Layer Security (TLS) 1.2 以降をサポートする必要があります。また、Ephemeral Diffie-Hellman (DHE) や Elliptic Curve Ephemeral Diffie-Hellman (ECDHE) などの Perfect Forward Secrecy (PFS) を使用した暗号スイートもサポートしている必要があります。これらのモードは Java 7 以降など、ほとんどの最新システムでサポートされています。
また、リクエストにはアクセスキー ID と、IAM プリンシパルに関連付けられているシークレットアクセスキーを使用して署名する必要があります。または、[AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) を使用して、一時的なセキュリティ認証情報を生成し、リクエストに署名することもできます。
# でのデータの整合性 AWS Backup
## AWS Backup データ整合性の目標
AWS Backup は、データの送信、保存、処理中に整合性を維持するよう努めます。 は、保存されたリソースデータをコンテンツに依存しない重要な情報として AWS Backup 扱います。これは、保存するデータの種類に関係なく、お客様に同じ高レベルのセキュリティを提供するという点です。当社はお客様のセキュリティに注意を払い、不正アクセスに対して高度な技術的および物理的対策を講じています。データの分類方法、データを保存するリージョン、データを管理する方法、アーカイブする方法、開示から保護する方法については、お客様が完全に管理できます。
## AWS Backup データ整合性の実装
AWS Backup は、他の AWS および Amazon のサービスと連携して、保存およびやり取りするデータの整合性を維持します。使用するツールはさまざまで、次のようなものがあります (ただしこれらに限定されません)。
+ オブジェクトの破損を防ぐため、チェックサムと照合してオブジェクトを継続的に検証するもの
+ 転送中および保管時のデータの整合性を確認するための内部チェックサム
+ プライマリストアから作成されたバックアップ内のデータに基づいて計算されるチェックサム
+ チェックサムは、対応するデータを使用する前に、常に正しいことが検証されます。チェックサムと一致しないデータが見つかった場合は、正しいコピーに置き換えます。正しいコピーを置き換えられなかった場合、対応するジョブは失敗します。
+ ディスクが破損したり、デバイス障害が検出されたりした場合に、オブジェクトストレージの冗長性を通常のレベルに自動的に復元しようとする試行
+ 物理的に複数の場所にわたるデータの冗長ストレージ
+ 初回書き込み時の複数のアベイラビリティーゾーンにわたるオブジェクトの耐久性の向上と、デバイスが利用不能になった場合やビットロートが検出された場合のさらなるレプリケーションとの組み合わせ
+ すべてのネットワークトラフィックをチェックサムしたえうでの、データを保存または取得する際のデータパケットの破損の検出
AWS Backup Backup ゲートウェイを介して接続された VMware で実行されている Amazon DynamoDB、Amazon EFS、Amazon S3、Amazon Timestream、仮想マシンを使用して Amazon DynamoDB のデータをネイティブに保存します。 AWS Backup は、Amazon Aurora、Amazon DocumentDB、Amazon DynamoDB、Amazon EBS、Amazon EC2、Amazon FSx for Windows File Server、Amazon FSx for Lustre、Amazon FSx for OpenZFS、Amazon FSx for NetApp ONTAP、Amazon Neptune、Amazon RDS、Amazon Redshift などの他の サービスに保存されているデータのバックアップを容易にします。
## AWS Backup データ整合性の客観的な確認と監査
によって直接保存されるデータと AWS Backup 、 AWS Backup やり取りする他の AWS のサービスと連携して保存されるデータは、このデータ整合性を支える Amazon Simple Storage Service (Amazon S3) の厳格なプロセスの対象となります。この整合性は、[AWS Artifact](https://aws.amazon.com/artifact/) から入手できる年次 SOC 監査報告書を通じて、独立した第三者の監査人によって確認済みです。
# リーガルホールドと AWS Backup
## リーガルホールドの概要
リーガルホールドは、ホールド中にバックアップが削除されないようにする管理ツールです。ホールドが実施されている間、ホールド状態にあるバックアップは削除できず、バックアップステータスを変更することになるライフサイクルポリシー (`Deleted` 状態への移行など) は、リーガルホールドが削除されるまで延期されます。
リーガルホールドは、ライフサイクルで許可されている AWS Backup 場合に、 によって作成された 1 つ以上のバックアップ (復旧ポイントとも呼ばれます) に適用できます。リーガルホールドは[継続的バックアップ](https://docs.aws.amazon.com/aws-backup/latest/devguide/point-in-time-recovery.html)には適用されません。
リーガルホールドを作成すると、リソースタイプやリソース ID などの特定のフィルター条件を考慮に入れることができます。さらに、リーガルホールドに含めるバックアップの作成日の範囲を定義できます。
リーガルホールドは、そのリーガルホールドがある元のバックアップにのみ適用されます。バックアップがリージョン間またはアカウント間でコピーされた場合 (リソースがそれをサポートしている場合)、そのバックアップは保持されず、そのリーガルホールドも移行されません。他のリソースと同様に、リーガルホールドは、一意の Amazon リソースネーム (ARN) が関連付けられています。リーガルホールドに含める AWS Backup ことができるのは、 によって作成された復旧ポイントのみです。
[AWS Backup ボールトロック](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html)が、ボールトに対する追加の保護とイミュータビリティを提供するのに対して、リーガルホールドは個々のバックアップ (復旧ポイント) の削除に対する保護を強化することに注意してください。リーガルホールドには有効期限がなく、データはバックアップ内に無期限に保持されます。ホールドは、十分なアクセス許可を持つユーザーが解除するまで有効です。
## 複数のリーガルホールド
1 つのバックアップについて、リーガルホールドが複数ある場合があります。リーガルホールドとバックアップには多対多の関係があります。つまり、1 つのバックアップには複数のリーガルホールドを設定でき、1 つのリーガルホールドには複数のバックアップを含めることができます。
バックアップは、少なくとも 1 つのリーガルホールドを持っている限り削除できません。バックアップに対するすべてのリーガルホールドが削除されると、その保持ライフサイクルプロパティが適用されます。バックアップの削除を防ぐために、少なくとも 1 つのリーガルホールドを維持します。リーガルホールドは、(既存のリーガルホールドのため) バックアップライフサイクル保持日を過ぎて保持されている復旧ポイントに適用できます。
各アカウントで一度に最大 50 個のリーガルホールドを有効化できます。
## リーガルホールドの作成
リーガルホールドは、既存のバックアップ (復旧ポイント) に追加できます。
ステータスが `EXPIRED` または `DELETING` のバックアップ (復旧ポイント) はリーガルホールドに含まれません。ステータスが `CREATING` の復旧ポイント (バックアップ) は、完了時期によってはリーガルホールドに含まれない場合があります。
リーガルホールドは、必要な IAM アクセス許可を持つユーザーが追加できます。
### コンソールを使用してリーガルホールドを作成する
**リーガルホールドを作成するには**
1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。
1. コンソールの左側にあるダッシュボードで、[マイアカウント] を探します。**[リーガルホールド]** を選択します。
1. **[リーガルホールドを追加]** を選択します。
1. **[リーガルホールドの詳細]**、**[リーガルホールドの範囲]**、**[リーガルホールドタグ]** という、3 つのパネルが表示されます。
1. **[リーガルホールドの詳細]** で、表示されるテキストボックスにリーガルホールドのタイトルとリーガルホールドの説明を入力します。
1. **[リーガルホールドの範囲]** パネルで、ホールドに含めるリソースの選択方法を選択します。ホールドを作成するときは、リーガルホールド内のリソースを選択するために使用する方法を選択します。次のいずれかを含める選択ができます。
+ 特定のリソースタイプと ID
+ バックアップボールトの選択
+ アカウント内のすべてのリソースタイプまたはすべてのバックアップボールト
1. リーガルホールドの日付範囲を指定します。日付を YYYY:MM:DD の形式で入力します (日付も含まれます)。
1. オプションで、**[リーガルホールドタグ]** でホールドのタグを追加できます。タグは、将来的な参照や整理のためにホールドを分類するのに役立ちます。最大 50 個のタグを追加できます。
1. 新しいリーガルホールドの設定を確認したら、**[新規ホールドを追加]** ボタンをクリックします。
### を使用してリーガルホールドを作成する AWS CLI
[create-legal-hold](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/create-legal-hold.html) コマンドを使用してリーガルホールドを作成できます。
```
aws backup create-legal-hold --title "my title" \
--description "my description" \
--recovery-point-selection "VaultNames=string,DateRange={FromDate=timestamp,ToDate=timestamp}"
```
## リーガルホールドを表示する
リーガルホールドの詳細は、 AWS Backup コンソールまたはプログラムで確認できます。
### コンソールを使用したリーガルホールドの表示
バックアップコンソールを使用してアカウント内のすべてのリーガルホールドを表示するには、
1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。
1. ダッシュボードの左側にある **[マイアカウント]** で **[リーガルホールド]** をクリックします。
1. **[リーガルホールド]** テーブルには、既存のホールドのタイトル、ステータス、説明、ID、作成日が表示されます。テーブルヘッダーの横にあるカラット (下矢印)をクリックすると、テーブルが、選択した列別でフィルターされます。
### リーガルホールドをプログラムで表示する
すべてのリーガルホールドをプログラムで表示するには、次の API コールを使用できます: [ListLegalHolds](API_ListLegalHolds.md) および [GetLegalHold](API_GetLegalHold.md)。
`GetLegalHold` には次の JSON テンプレートを使用できます。
```
GET /legal-holds/{legalHoldId} HTTP/1.1
Request
empty body
Response
{
Title: string,
Status: LegalHoldStatus,
Description: string, // 280 chars max
CancelDescription: string, // this is provided during cancel // 280 chars max
LegalHoldId: string,
LegalHoldArn: string,
CreatedTime: number,
CanceledTime: number,
ResourceSelection: {
VaultArns: [ string ]
Resources: [ string ]
},
ResourceFilters: {
DateRange: {
FromDate: number,
ToDate: number
}
}
}
```
`ListLegalHolds` には次の JSON テンプレートを使用できます。
```
GET /legal-holds/
&maxResults=MaxResults
&nextToken=NextToken
Request
empty body
url params:
MaxResults: number // optional,
NextToken: string // optional
status: Valid values: CREATING | ACTIVE | CANCELED | CANCELING
maxResults: 1-1000
Response
{
NextToken: token,
LegalHolds: [
Title: string,
Status: string,
Description: string, // 280 chars max
CancelDescription: string, // this is provided during cancel // 280 chars max
LegalHoldId: string,
LegalHoldArn: string,
CreatedTime: number,
CanceledTime: number,
]
}
```
有効なステータス値には以下のものがあります。
| ステータス | 説明 |
| --- | --- |
| [CREATING] (作成中) | リクエストされた復旧ポイントはリーガルホールドのプロセスに入っていますが、リーガルホールドの作成がまだ完了していないため、それらの復旧ポイントの削除リクエストが成功する可能性があります。 |
| アクティブ | リーガルホールドが作成されました。このリーガルホールドに含まれるすべての復旧ポイントが保持されます。 |
| キャンセル中 | リーガルホールドは削除中のため、ホールドの対象になっている復旧ポイントの削除リクエストが成功する可能性があります。 |
| CANCELED | リーガルホールドは完全に解除され、無効になっています。復旧ポイントは削除できます。 |
## リーガルホールドを解除する
リーガルホールドは、十分なアクセス許可を持つユーザーによって削除されるまで有効です。リーガルホールドの削除は、リーガルホールドのキャンセル、解除とも呼ばれます。リーガルホールドを削除すると、そのリーガルホールドがアタッチされていたすべてのバックアップからリーガルホールドが削除されます。リーガルホールド中に期限切れになったバックアップは、リーガルホールドが削除されてから 24 時間以内に削除されます。
### コンソールを使用してリーガルホールドを解除する
**コンソールを使用してホールドを解除するには**
1. [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) で AWS Backup コンソールを開きます。
1. 解除に関連付ける説明を入力します。
1. 詳細を確認し、**[ホールドを解除]** をクリックします。
1. [ホールドを解除] ダイアログボックスが表示されたら、テキストボックスに [`confirm`] と入力してホールドを解除することを確認します。
1. ホールドを解除することを確認するボックスにチェックを入れます。
**[リーガルホールド]** ページでは、すべてのホールドを確認できます。解除が成功すると、そのホールドのステータスが `Released` と表示されます。
### プログラムによるリーガルホールドの解除
プログラムでホールドを削除するには、API コール [CancelLegalHold](API_CancelLegalHold.md) を使用します。
以下の JSON テンプレートを使用します。
```
DELETE /legal-holds/{legalHoldId}
Request
{
CancelDescription: String
DeleteAfterDays: number // optional
}
DeleteAfterDays: optional.
Defaults to 180 days. how long to keep legal hold record after canceled.
This applies to the actual legal hold record only.
Recovery points are unlocked as soon as cancelation processes and are not subject to this date.
Response
Empty body
200 if successful
other standard codes
```
# でのマルウェア保護 AWS Backup
バックアップのマルウェアスキャンは、Amazon GuardDuty Malware Protection によって提供されます。Amazon GuardDuty Malware Protection for AWS Backup を使用すると、既存のバックアップワークフローを通じて復旧ポイントのスキャンを自動化したり、以前に作成したバックアップのオンデマンドスキャンを開始したりできます。この AWS ネイティブソリューションは、バックアップが潜在的なマルウェアからクリーンであることを確認するのに役立ちます。これにより、クリーンデータの復旧を確保することで、コンプライアンス要件を満たし、悪意のあるインシデントに迅速に対応できます。
サポートされているリソースタイプとリージョンのリストを確認するには、[機能の可用性ページ](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-feature-availability.html)にアクセスしてください。
**Topics**
+ [Amazon GuardDuty との統合](#malware-guardduty-integration)
+ [インスタントアクセス](backup-instant-access.md)
+ [マルウェアスキャンの使用方法](#malware-how-to-use)
+ [アクセス](#malware-access)
+ [増分スキャンとフルスキャン](#malware-scan-types)
+ [マルウェアスキャンのモニタリング](#malware-monitoring)
+ [スキャン結果について](#malware-scan-results)
+ [スキャン失敗のトラブルシューティング](#malware-troubleshooting)
+ [計測](#malware-metering)
+ [クォータ](#malware-quotas)
+ [マルウェアスキャンタイプのコンソールと CLI の使用手順](#malware-console-cli-usage)
## Amazon GuardDuty との統合
AWS Backup は Amazon GuardDuty Malware Protection と統合され、復旧ポイントの脅威検出を提供します。マルウェアスキャンを開始すると、 は各バックアップの完了後に Amazon GuardDuty の `StartMalwareScan` API AWS Backup を自動的に呼び出し、復旧ポイントの詳細とスキャナーロールの認証情報を渡します。その後、Amazon GuardDuty はバックアップ内のすべてのファイルとオブジェクトの読み取り、復号、スキャンを開始します。
Amazon GuardDuty がバックアップデータにアクセスすると、そのアクセスは可視性 AWS CloudTrail のためにログインされます。
この統合の詳細については、[Amazon GuardDuty Malware Protection のドキュメント](https://docs.aws.amazon.com/guardduty/latest/ug/malware-protection-backup.html)を参照してください。
# バックアップインスタントアクセス許可
S3 バックアップで Amazon GuardDuty Malware Protection for AWS Backup を使用する場合、Amazon GuardDuty は CreateBackupAccessPoint、DescribeBackupAccessPoint、DeleteBackupAccessPoint の 3 つの APIs を介して S3 バックアップにアクセスします。
Amazon GuardDuty は CreateBackupAccessPoint を使用して暗号化されたバックアップデータにアクセスします。スキャンジョブ中、GuardDuty は DescribeBackupAccessPoint を使用してアクセスポイントの作成が成功したことを確認します。スキャンが完了すると、GuardDuty は DeleteBackupAccessPoint を呼び出してバックアップへのアクセスを削除します。
このワークフローは、論理エアギャップボールトに保存されている S3 バックアップと EC2/EBS バックアップの両方に適用されます。
## マルウェアスキャンの使用方法
Amazon GuardDuty Malware Protection を で使用すると AWS Backup、バックアップでマルウェアを自動的にスキャンできます。この統合により、バックアップ内の悪意のあるコードを検出し、復元オペレーションのクリーンリカバリポイントを特定できます。
Amazon GuardDuty Malware Protection は、バックアップをスキャンするための 2 つの主要なワークフローをサポートしています。
+ **バックアッププランによるマルウェアの自動スキャン** – バックアッププランでマルウェアスキャンを有効にして、 によるマルウェア検出を自動化します AWS Backup。有効にすると、バックアップが正常に完了するたびに Amazon GuardDuty スキャン AWS Backup が自動的に開始されます。特定のバックアッププランルールに対してフルスキャンまたは増分スキャンを設定できます。これにより、バックアップがスキャンされる頻度が決まります。スキャンタイプの詳細については、[増分スキャンとフルスキャン](#malware-scan-types)以下を参照してください。バックアップ作成後のプロアクティブ脅威検出のために、バックアッププランで自動マルウェアスキャンを有効にする AWS Backup ことをお勧めします。
+ **オンデマンドスキャン** – オンデマンドスキャンを実行して既存のバックアップを手動でスキャンし、完全スキャンタイプと増分スキャンタイプのいずれかを選択します。 AWS Backup は、オンデマンドスキャンを使用して最後のクリーンバックアップを特定することをお勧めします。復元オペレーションの前にスキャンする場合は、フルスキャンを使用して最新の脅威検出モデルでバックアップ全体を調べます。
## アクセス
マルウェア保護を開始する前に、アカウントに オペレーションに必要なアクセス許可が必要です。
AWS Backup マルウェアスキャンでは、潜在的なマルウェアの復旧ポイントをスキャンするために 2 つの IAM ロールが必要です。
+ まず、[AWSBackupServiceRolePolicyForBackup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForBackup.html) または [AWSBackupServiceRolePolicyForScans](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupServiceRolePolicyForScans.html) 管理ポリシーを既存または新規のバックアップロールにアタッチする必要があります。これは、コンソールで、または [BackupSelection API](API_CreateBackupSelection.md) を使用して、バックアッププランのリソース割り当てで見つかったのと同じロールです。この管理ポリシーにより AWS Backup 、 は Amazon GuardDuty でマルウェアスキャンを開始できます。
+ 次に、 を信頼する [AWSBackupGuardDutyRolePolicyForScans](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupGuardDutyRolePolicyForScans.html) 管理ポリシーで新しいスキャナーロールが必要です`malware-protection.guardduty.amazonaws.com`。これは、コンソールのバックアッププランのマルウェア保護部分、または [BackupPlan API](API_CreateBackupPlan.md) のスキャン設定で見つかったのと同じロールです。このロールは、スキャンの開始時に によって Amazon GuardDuty AWS Backup に渡され、バックアップへのアクセスを提供します。
## 増分スキャンとフルスキャン
マルウェアスキャンでは、セキュリティ要件とコストの考慮事項に基づいて、増分スキャンとフルスキャンのいずれかを選択できます。
**増分スキャン**は、ターゲットと基本復旧ポイントの間で変更されたデータのみを分析します。これらのスキャンは、通常のスキャンではより高速でコスト効率が高いため、新しくバックアップされたデータをスキャンする頻繁な定期バックアップに最適です。
増分スキャンが選択されている場合でも、 は次の状況でフルスキャン AWS Backup を実行します。
+ **初回スキャン:** リソースの初期スキャンは常にフルスキャンであるため、Amazon GuardDuty は潜在的な脅威のベースラインを確立できます。その後、それ以降のスキャンは増分になります。
+ **有効期限切れのベースライン:** ベースライン復旧ポイントが 365 日以上前にスキャンされた場合、フルスキャンが発生します。Amazon GuardDuty は検出結果情報を 365 日間のみ保持するため、正確なスキャン結果を確保するために新しいベースラインを確立する必要があります。
+ **削除されたベースライン:** 次の増分スキャンを開始する前に基本復旧ポイントが削除されると、フルスキャンが自動的に行われます。
**フルスキャン**は、以前のスキャンに関係なく、復旧ポイント全体を調べます。これらのスキャンは包括的なカバレッジを提供しますが、完了までに時間がかかり、コストも高くなります。フルスキャンはオンデマンドで実行することも、バックアッププランを通じてスケジュールすることもできます。 では、バックアッププランで定期的にフルスキャンを延長間隔で設定して、バックアップデータ全体が最新のマルウェア署名モデルで定期的にスキャンされるように AWS Backup することをお勧めします。
セキュリティとコスト管理を最適化するには、スキャンタイプを選択するときにバックアップの頻度を考慮してください。
**注記**
マルウェアスキャンは現在、Amazon S3 の継続的リカバリポイントではサポートされていません。Amazon S3 の継続的バックアップをスキャンするには、Amazon S3 リソースの定期的なバックアップを設定し、それらの定期的なバックアップでマルウェアスキャンを有効にします。Amazon S3 バケットには、[継続的バックアップと定期的なバックアップを組み合わせて](https://docs.aws.amazon.com/aws-backup/latest/devguide/s3-backups.html)使用できます。
**注記**
増分マルウェアスキャンは、[論理エアギャップボールト](https://docs.aws.amazon.com/aws-backup/latest/devguide/logicallyairgappedvault.html)の Amazon EC2 復旧ポイントまたはコピーされた Amazon EC2 復旧ポイントではサポートされていません。
## マルウェアスキャンのモニタリング
スキャンを有効にする AWS Backup と、 と Amazon GuardDuty の両方が、結果を追跡するために使用できるモニタリングおよび通知メカニズムを提供します。
+ **AWS Backup コンソール:** AWS Backup コンソールは `ListScanJobs`および `DescribeScanJob` APIsを使用しています。Malware Protection セクションにアクセスして、ジョブのステータスとスキャン結果を表すスキャンジョブのリストを表示できます。 は `ListScanJobSummaries` API AWS Backup もサポートしていますが、 コンソールでは利用できません。
+ **AWS Backup Audit Manager:** 過去 24 時間に AWS Backup 開始されたすべてのマルウェアスキャンジョブを表示するようにスキャンレポートを設定できます。
+ **Amazon GuardDuty コンソール:** 基本 Amazon GuardDuty が有効になっている場合は、Malware スキャンの結果で詳細を表示し、Amazon GuardDuty の検出結果ページでマルウェアを調査できます。脅威とファイル名、ファイルパス、スキャンされたオブジェクト/ファイル、スキャンされたバイト数などの情報を表示できます。この詳細な脅威情報は では利用できないため AWS Backup、この情報を表示するには適切な Amazon GuardDuty アクセス許可が必要です。
+ **Amazon EventBridge:** AWS Backup と Amazon GuardDuty の両方が EventBridge イベントを出力するため、バックアップ管理者とセキュリティ管理者が同期的にアラートを受け取ることができます。スキャンが完了したとき、またはマルウェアが検出されたときに通知を受け取るようにカスタムルールを設定できます。
+ **AWS CloudTrail:** AWS Backup と Amazon GuardDuty の両方が CloudTrail イベントを出力するため、API アクセスをモニタリングできます。
## スキャン結果について
のスキャンジョブには、スキャン状態とスキャン結果 AWS Backup があります。
### スキャン状態
スキャン状態はジョブの状態を示し、、`CREATED`、、`COMPLETED`、`COMPLETED_WITH_ISSUES``RUNNING``FAILED`、または の値を指定できます`CANCELED`。
スキャンジョブが 状態で終了する状況は複数あります`COMPLETED_WITH_ISSUES`。
Amazon S3 バックアップの場合、オブジェクトのサイズ/タイプには、オブジェクトのスキャンを妨げる制限があります。スキャン内で少なくとも 1 つのオブジェクトがスキップされると、対応するスキャンジョブは としてマークされます`COMPLETED_WITH_ISSUES`。Amazon EC2/Amazon EBS バックアップの場合、ボリュームサイズ/数量の制限があり、スキャン中にボリュームがスキップされます。このような状況では、Amazon EC2/Amazon EBS バックアップジョブが になります`COMPLETED_WITH_ISSUES`。
ジョブが 状態で終了`COMPLETED_WITH_ISSUES`し、理由に関する詳細情報が必要な場合は、Amazon GuardDuty を介して対応するスキャンジョブからこれらの詳細を取得する必要があります。
**注記**
増分スキャンジョブは、2 つのバックアップ間のデータの差のみをスキャンします。したがって、増分スキャンジョブが上記のいずれの状況にも遭遇しない場合、そのジョブは 状態で終了`COMPLETE`し、基本復旧ポイント`COMPLETED_WITH_ISSUES`から を継承しません。
まれに、Amazon GuardDuty でファイルやオブジェクトのスキャン時に内部の問題が発生し、再試行回数が枯渇することがあります。この場合、スキャンジョブは `FAILED` AWS Backup および Amazon GuardDuty `COMPLETED_WITH_ISSUES`の として表示されます。このステータスの違いにより、サポートされているすべてのファイルとオブジェクトが正常にスキャンされたわけではないことを示すと同時に、Amazon GuardDuty で使用可能なスキャン結果を表示できます。
### スキャン結果
スキャン結果は Amazon GuardDuty からの集計結果を示し`THREATS_FOUND`、 または の値を指定できます`NO_THREATS_FOUND`。
スキャン結果は、潜在的なマルウェアが復旧ポイントで検出されたかどうかを示します。`NO_THREATS_FOUND` ステータスは潜在的なマルウェアが検出されなかったことを意味しますが、 は潜在的なマルウェアが検出された`THREATS_FOUND`ことを示します。詳細な脅威情報については、Amazon GuardDuty コンソールまたは APIs から Amazon GuardDuty の検出結果全体にアクセスしてください。スキャン結果は EventBridge イベントでも利用できるため、感染したバックアップに応答する自動ワークフローを構築できます。
Amazon GuardDuty は検出結果を 365 日間保持し、増分スキャンでファイルまたはオブジェクトを追跡して、脅威が削除されるか、マルウェアの署名が変更されるかを監視します。たとえば、バックアップ 2 でマルウェアが検出された場合、スキャン結果は と表示されます`THREATS_FOUND`。バックアップ 2 をベースとして使用してバックアップ 3 で増分スキャンを実行すると、脅威がデータから削除され`THREATS_FOUND`ない限り、スキャン結果は残ります。
## スキャン失敗のトラブルシューティング
一般的なスキャン障害には、IAM アクセス許可の不足、サービスの制限、リソースアクセスの問題などがあります。
アクセス**許可エラー**は、バックアップロールにアクセス`AWSBackupServiceRolePolicyForScans`許可がない場合、またはスキャナーロールに適切な信頼関係がない場合`AWSBackupGuardDutyRolePolicyForScans`に発生します。
**サービス制限エラー**は、アカウントあたり 150 回の同時スキャン、またはリソースタイプあたり 5 回の同時スキャンを超えると発生します。スキャンジョブは容量が利用可能になるまで `CREATED`状態のままになります。
**アクセス拒否エラー**は、適切な AWS KMS アクセス許可のない暗号化された復旧ポイントや、増分スキャン用の削除された親復旧ポイントを示している可能性があります。
**タイムアウト障害**は、復旧ポイントが非常に大きい場合や、Amazon GuardDuty の負荷が高い期間に発生する可能性があります。
トラブルシューティングを行うには、`DescribeScanJob`API を使用してスキャンジョブのステータスを確認し、IAM ロール設定を検証し、復旧ポイントが存在してアクセス可能であることを確認し、増分スキャンの親参照がない場合はフルスキャンに切り替えることを検討します。
同時スキャンの使用状況を監視し、自動ワークフローにジッターを実装して、サービスの制限に達しないようにします。
## 計測
マルウェア保護は Amazon GuardDuty によって提供され、請求されます。この機能の使用に関連する AWS Backup 料金は表示されません。すべての使用状況は、Amazon GuardDuty の請求で確認できます。詳細については、[Amazon GuardDutyの料金](https://aws.amazon.com/guardduty/pricing/)」を参照してください。
## クォータ
AWS Backup と Amazon GuardDuty の両方にAmazon GuardDuty Malware Protection のクォータ制限があります AWS Backup。
詳細については、[AWS Backup 「クォータ](https://docs.aws.amazon.com/aws-backup/latest/devguide/aws-backup-limits.html)」と[Amazon GuardDuty クォータ](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_limits.html)」を参照してください。
## マルウェアスキャンタイプのコンソールと CLI の使用手順
以下のセクションでは、 コンソールと の両方を使用してさまざまなマルウェアスキャンタイプを設定する手順を示します AWS CLI。
### マルウェアスキャンをセットアップする方法
**コンソール**
1. AWS Backup コンソールに移動する → バックアッププラン
1. 新しいバックアッププランを作成するか、既存のプランを選択する
1. **マルウェア保護**の切り替えを有効にする
1. **スキャナーロール**を選択して、新しいスキャナーロールを選択します。「」で説明されているように、バックアップロールとスキャナーロールの両方に適切なアクセス許可があることを確認します[アクセス](#malware-access)。
1. **スキャン可能なリソースタイプ**を選択します。これにより、選択したリソース選択基準にマルウェアスキャンがフィルタリングされます。例えば、スキャン可能なリソースタイプの選択が Amazon EBS で、プランのリソース選択に Amazon EBS と Amazon S3 が含まれている場合、Amazon EBS マルウェアスキャンのみが実行されます。
1. バックアップルールごとに**スキャンタイプ**を設定します。フルスキャン、増分スキャン、スキャンなしのいずれかを選択できます。スキャンタイプの選択は、関連するバックアップルールのスケジュール頻度でスキャンが行われることを意味します。
1. バックアッププランを保存する
**AWS CLI**
**CreateBackupPlan**
create[create-backup-plan](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/create-backup-plan.html) コマンドを使用して、マルウェアスキャンを有効にしてバックアッププランを作成できます。
```
aws backup create-backup-plan \
--region us-west-2 \
--cli-input-json '{
"BackupPlan": {
"BackupPlanName": "scan-initial-test-demo",
"Rules": [
{
"RuleName": "full",
"TargetBackupVaultName": "Default",
"ScheduleExpression": "cron(0 * * * ? *)",
"StartWindowMinutes": 120,
"CompletionWindowMinutes": 6000,
"Lifecycle": {
"DeleteAfterDays": 3,
"OptInToArchiveForSupportedResources": true
},
"RecoveryPointTags": {
"key1": "foo",
"key2": "foo"
},
"EnableContinuousBackup": true,
"ScanActions": [
{
"MalwareScanner": "GUARDDUTY",
"ScanMode": "FULL_SCAN"
}
]
},
{
"RuleName": "incremental",
"TargetBackupVaultName": "Default",
"ScheduleExpression": "cron(30 * * * ? *)",
"StartWindowMinutes": 100,
"CompletionWindowMinutes": 5000,
"Lifecycle": {
"DeleteAfterDays": 2,
"OptInToArchiveForSupportedResources": true
},
"RecoveryPointTags": {
"key1": "foo",
"key2": "foo"
},
"EnableContinuousBackup": true,
"ScanActions": [
{
"MalwareScanner": "GUARDDUTY",
"ScanMode": "INCREMENTAL_SCAN"
}
]
}
],
"ScanSettings": [
{
"MalwareScanner": "GUARDDUTY",
"ResourceTypes": ["EBS", "EC2", "S3"],
"ScannerRoleArn": "arn:aws:iam::300949271314:role/TestBackupScannerRole"
}
]
}
}'
```
**UpdateBackupPlan**
update[update-backup-plan](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/update-backup-plan.html) コマンドを使用して、マルウェアスキャンを有効にしてバックアッププランを更新できます。
```
aws backup update-backup-plan \
--region us-west-2 \
--cli-input-json '{
"BackupPlanId": "d1391282-68cf-4fce-93ad-e08bc5178bac",
"BackupPlan": {
"BackupPlanName": "scan-initial-test-demo",
"Rules":
[
{"RuleName": "full",
"TargetBackupVaultName": "Default",
"ScheduleExpression": "cron(0 * * * ? *)",
"StartWindowMinutes": 60,
"CompletionWindowMinutes": 3000,
"Lifecycle":
{
"DeleteAfterDays": 6,
"OptInToArchiveForSupportedResources": false},
"RecoveryPointTags":
{"key1": "foo",
"key2": "foo"},
"EnableContinuousBackup": false,
"ScanActions":
[
{"MalwareScanner": "GUARDDUTY",
"ScanMode": "FULL_SCAN"}
]
},
{
"RuleName": "incremental",
"TargetBackupVaultName": "Default",
"ScheduleExpression": "cron(30 * * * ? *)",
"StartWindowMinutes": 120,
"CompletionWindowMinutes": 6000,
"Lifecycle":
{
"DeleteAfterDays": 9,
"OptInToArchiveForSupportedResources": false},
"RecoveryPointTags":
{"key1": "foo",
"key2": "foo"},
"EnableContinuousBackup": false,
"ScanActions":
[
{
"MalwareScanner": "GUARDDUTY",
"ScanMode": "INCREMENTAL_SCAN"
}
]
}
],
"ScanSettings":
[
{
"MalwareScanner": "GUARDDUTY",
"ResourceTypes":
["ALL", "EBS"],
"ScannerRoleArn": "arn:aws:iam::300949271314:role/TestBackupScannerRole"
}
]
}
}'
```
**キーノート**
+ スキャンオプションを有効にする前にターゲット ARN エントリが必要です (コンソール)
+ すべての設定に必要なバックアップ IAM ロールとスキャナー IAM ロールの両方
+ `aws backup list-scan-jobs` を使用してすべてのスキャンジョブを表示する (AWS CLI)
+ コストへの影響は、スキャンタイプ (増分とフル) と頻度によって異なります。
**AWS CLI キーノート**
+ `aws backup list-scan-jobs` を使用してすべてのスキャンジョブを表示する (AWS CLI)
+ ScanResults フィールドで `describe-recovery-point` API 経由で利用可能なスキャン結果 ScanResults
+ すべての設定に必要なバックアップ IAM ロールとスキャナー IAM ロールの両方
+ JSON バックアッププラン構造には、プランレベルでの ScanSettings とルールの ScanActions が含まれます。
# の耐障害性 AWS Backup
AWS Backup は、その耐障害性とデータセキュリティを非常に重視しています。
AWS Backup は、バックアップをバックアップした場合、リソースの元の AWS サービスが提供するのと同等*以上の*耐障害性と耐久性でバックアップを保存します。
AWS Backup は、 AWS グローバルインフラストラクチャを使用して複数のアベイラビリティーゾーンにバックアップをレプリケートするように設計されており、現在の AWS Backup ドキュメントに従っている限り、1 年あたり 99.999999999% (11 9 秒) の耐久性を実現します。
AWS Backup は、保管中のバックアッププランを暗号化し、継続的にバックアップします。( AWS Identity and Access Management IAM) 認証情報とポリシーを使用して、バックアッププランへのアクセスを制限することもできます。詳細については、「[認証](https://docs.aws.amazon.com/aws-backup/latest/devguide/authentication.html)」「[アクセスコントロール](https://docs.aws.amazon.com/aws-backup/latest/devguide/access-control.html)」、および「[IAM のセキュリティベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。
AWS グローバルインフラストラクチャは、 AWS リージョン およびアベイラビリティーゾーンを中心に構築されています。 は、低レイテンシー、高スループット、および高度に冗長なネットワークで接続された、物理的に分離および分離された複数のアベイラビリティーゾーン AWS リージョン を提供します。 は、アベイラビリティーゾーン間でバックアップ AWS Backup を保存します。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、フォールトトレランス、および拡張性が優れています。詳細については、「[AWS Backup サービスレベルアグリーメント (SLA)](https://aws.amazon.com/backup/sla/)」を参照してください。
さらに、 AWS Backup を使用すると、リージョン間でバックアップをコピーして耐障害性を高めることができます。 AWS Backup クロスリージョンコピー機能の詳細については、[「バックアップコピーの作成](https://docs.aws.amazon.com/aws-backup/latest/devguide/recov-point-create-a-copy.html)」を参照してください。
AWS リージョン およびアベイラビリティーゾーンの詳細については、[AWS 「 グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)」を参照してください。