はじめに
お疲れ様です。 矢儀 @yuki_ink です。
AWS Backup、使ってますか？
本記事は、AWS BackupでS3のバックアップを取得するときの勘所をまとめたものです。
AWS Backupは、AWSサービスのバックアップを一元管理できるフルマネージドサービスです。
2019年1月にローンチされ、今やAWS認定資格でも常連の古株サービスですが、最近では、ランサムウェア対策の文脈でAWS Backup、特にその中の「Vault Lock」機能について触れられる機会が多くなったように思います。
AWS Backup Vault Lock
AWS Backup は、バックアップの一元管理と自動化を実現するフルマネージドサービスです。手動と自動スケジュールのバックアップを実施することができます。1 つのコンソールで、多岐にわたる AWS リソースのバックアップの設定と実行、復旧を実施することができ、一元管理することができます。暗号化した個別の Vault と呼ばれる単位でデータを格納することができるため、セキュリティを確保することもできます。Vault は、バックアップを保存および整理するためのコンテナです。AWS Backup Vault Lock は AWS Backup のオプション機能で、対象の Valut を読み込み専用である WORM に設定することができます。この機能により、バックアップデータを変更できなくなるため、バックアップデータの暗号化といった、ランサムウェアによる悪意ある攻撃を防ぐことができます。
また、不注意や誤操作によってバックアップが削除されることも防ぐことができるという利点もあります。
医療機関に限らず、ランサムウェア被害から復旧する際に利用するバックアップデータを、悪意ある上書きや削除から保護することができます。
S3は、言わずと知れた高可用性ストレージで、本来であればバックアップを「保管する側」のサービスです。
しかし、ランサムウェア対策として、そのS3に対してもイミュータブルな形でバックアップを取得したいというニーズは増えてきていると思います。
S3のバックアップを取得するときの勘所
AWS Backupを利用すると、S3バケットもバックアップ対象として扱うことができます。
この記事では、S3のバックアップを取得・復元する際に押さえておきたいポイントを3つに分けて紹介します。
- バックアップの取得・復元に利用するIAMロールについて
- S3バケットの設定について
- 復元時の留意事項について
1. バックアップの取得・復元に利用するIAMロールについて
バックアップの取得・復元に必要なIAMポリシーは、AWS管理ポリシーとして提供されていますが、S3のバックアップの取得・復元については、専用のポリシーが追加で用意されている点には注意が必要です。
- AWSBackupServiceRolePolicyForS3Backup
- AWSBackupServiceRolePolicyForS3Restore
AWS Backup利用時にデフォルトで作成されるIAMロール AWSBackupDefaultServiceRole には、初期状態ではこれらのポリシーは付与されていません。
AWSBackupDefaultServiceRole の権限でS3のバックアップ取得・復元を行いたい場合、手動でポリシーのアタッチを行いましょう。
2. S3バケットの設定について
【バックアップ取得対象のS3バケット】バージョニング・EventBridge連携の有効化が必須
バックアップ対象のS3バケットでは、バージョニングが有効になっている必要があります。
また、これは「必須条件」というわけではないようですが、AWS BackupでS3のバックアップを取得すると、自動的にEventBridge連携が有効化されることが確認できました。
パラメータシートをちゃんと作り込まれている環境では、ご留意ください！
【復元先のS3バケット】バージョニング・ACLの有効化が必須 & バケットポリシーに注意
こちらでもバージョニングの有効化は必須です。
それに加えて、復元先バケットでは、アクセスコントロールリスト (ACL) を有効にしておく必要があります。
▼ ACL設定例
※「オブジェクト所有者」の設定はどちらでもいいっぽいです
なお、復元先バケットでパブリックアクセスのブロックが有効になっている場合、パブリック ACL を持つオブジェクトは復元されません。
※復元ジョブは正常に完了したように見えます！注意！
また、バケットポリシーの設定によっては、オブジェクトの復元ができないケースがあります。
- 復元に利用するIAMロールからの
s3:PutObjectが許可されていない - VPCエンドポイントを経由するアクセスのみ許可している
など…
ただ、↑のようなバケットポリシーでもバックアップの取得は問題なくできてしまうだけに、いざ復元する時になるまで気が付きにくいです😅
バケットポリシーをガチガチにしている場合は、以下のような StringNotEqualsIfExists フレーズを使って、サービスやIAMロール単位で除外設定を入れておくと良いと思います。
"StringNotEqualsIfExists": {
"aws:PrincipalServiceName": "backup.amazonaws.com"
}
3. 復元時の留意事項について
取得したバックアップから復元を行う際、いくつかの留意事項があります。
復元先バケットに同じ名前のオブジェクトがある場合、復元がスキップされる
まず、復元先バケットに同じ名前（またはバージョンID）のオブジェクトがある場合、オブジェクトの復元はスキップされます。
バックアップ取得対象のS3バケットにそのままバックアップを復元したい場合には、注意が必要です。
元の S3 バケットに復元する場合、
- AWS Backup は破壊的な復元を実行しません。つまり、 AWS Backup はバージョンに関係なく、既存のオブジェクトの代わりにバケットにオブジェクトを配置しません。
- 現在のバージョンの削除マーカーはオブジェクトが存在しないものとして扱われるため、復元を実行できます。
- AWS Backup は復元中にバケットからオブジェクト (削除マーカーなし) を削除しません (例: バックアップ中に存在しなかったバケット内の現在のキーは残ります）。
別リージョンのS3バケットにはバックアップの復元ができない
当たり前かもしれませんが…😅
もし別リージョンのS3バケットに対して復元を行いたい場合、AWS Backupでバックアップのクロスリージョンコピーを行い、コピーしたバックアップから復元を行う必要があります。
S3 バックアップはクロスリージョンコピーができますが、復元ジョブは元のバックアップまたはコピーが置かれている同じリージョンでのみなされます。
例: 米国東部 (バージニア北部) リージョンで作成された S3 バケットは、カナダ (中部) リージョンにコピーできます。復元ジョブは、米国東部 (バージニア北部) リージョンの元のバケットを使用して開始し、そのリージョンに復元できます。または、カナダ (中部) リージョンのコピーを使用して復元ジョブを開始し、そのリージョンに復元することもできます。
元の暗号化メソッドを使用して、別のリージョンからコピーされた復旧ポイント (バックアップ) を復元することはできません。クロスリージョンコピー AWS KMS 暗号化は Amazon S3 リソースでは使用できません。代わりに、復元ジョブに別の暗号化タイプを使用します。
【紹介】ACL とオブジェクトタグもバックアップするか選択可能に
最近のアップデートについて、こちらの記事で整理されていましたので、紹介させていただきます。
Amazon S3 のバックアップもサポートされていたのですが、これまでオブジェクトの ACL（アクセスコントロールリスト）とオブジェクトタグもデフォルトで含まれていました。
先日のアップデートでバックアッププランやオンデマンドバックアップの設定オプションでこれらを除外できるようになりました。公式ドキュメントによると、S3 リソースに ACL やオブジェクトタグを使っていない場合は今回の機能で除外すると「効果的」だと記述されています。
AWS Backup はバケット全体をスキャンして各オブジェクトの ACL とタグを取得するらしいので、バックアップ時間が短縮されるとかそのあたりでしょうかね。
設計時に考慮すべきポイントが増えましたねw
終わりに
AWS Backupを利用してS3のバックアップを取得・復元する際に留意いただきたいポイントをまとめてみました。
何かの助けになれば幸いです。
S3はアップデートの多いサービスです。
本記事で紹介した内容については参考に留めていただき、必ず最新のドキュメントを参照いただくようお願いいたします。
参考