S3に重要なデータを保存する
目次
はじめに
S3 は機能がシンプルなぶん、名前は知っていても「パブリックアクセスの制御」「バージョニング」「暗号化」「レプリケーション」といった個々の機能まではきちんと触ったことがない、という方も多いのではないでしょうか。バケットを作っただけの状態では、重要なデータを長期間安全に保管する構成としては不十分です。
本記事では、重要度の高いデータを S3 バケットに保存することを想定し、以下のようなシナリオで設定を進めていきます。同じような構成を検討している方の参考になれば幸いです。
本記事で作成するバケットの設定内容
- パブリックからのアクセスは拒否する
- 誤ってオブジェクトの削除が行われても復元できるようにする
- データは AWS KMS による暗号化を行う
- マルチリージョンでデータを保管する（東京リージョンと大阪リージョン）
- アクセスログを取得可能とする
- ライフサイクルポリシーを設定する（※次回の記事で解説予定）
暗号化用の AWS KMS カスタマー管理型キーを作成する
S3 バケットのオブジェクトを暗号化するために、まず AWS KMS のサービス画面からカスタマー管理型のキーを作成します。今回は東京リージョンと大阪リージョンで同じカスタマーキーを利用したいので、マルチリージョンキーを選択しておいてください。
作成が完了すると、以下のようにキー一覧に表示されます。
詳細ページの「リージョンごと」のメニューから、大阪リージョン向けのマルチリージョンキー（レプリカキー）も作成しておいてください。あとでバックアップ用バケットの暗号化に使用します。
S3 で重要なデータを守るための設定ポイント
ここからは、重要なデータ保管用の S3 バケットを実際に作成しながら、冒頭で挙げた設定を順番に行っていきます。
1. パブリックからのアクセスを拒否する
課題：デフォルト設定のままだとバケットポリシーの設定次第でオブジェクトが意図せず公開されるリスクがある。
解決策：バケット作成時に「パブリックアクセスをすべてブロック」を有効にし、重要なデータへの外部アクセス経路自体をなくす。
2. 誤ってオブジェクトの削除が行われても復元できるようにする
課題：操作ミスでオブジェクトを削除してしまうと、通常はそのまま失われてしまう。
解決策：バケットのバージョニングを有効にする。バージョニングを有効にしたバケットでは、削除は実体の削除ではなく「削除マーカー」の付与として扱われるため、あとから復元が可能になる。
3. データは AWS KMS による暗号化を行う
課題：S3 のデフォルト暗号化（SSE-S3）だけでは、鍵の管理・ローテーションを細かく制御できない。
解決策：バケットのデフォルト暗号化に、先ほど作成したカスタマー管理型の KMS キーを指定する。鍵の利用状況は KMS 側の CloudTrail 連携で追跡できる。
これで重要なデータを保存するバケット本体は完成です。テスト用にいくつかアップロードして良いファイルを用意しておきましょう。
4. マルチリージョンでデータを保管する（東京リージョンと大阪リージョン）
課題：単一リージョンにしかデータがない構成は、リージョン単位の障害が発生した際にデータが失われるリスクがある。
解決策：別リージョンにバックアップ用バケットを作成し、クロスリージョンレプリケーション（CRR）で自動的にデータを複製する。
まず、レプリケーション先となるバックアップ用の S3 バケットを、上記と同じ手順で作成します。リージョンのみ、重要なデータ用のバケットとは異なるリージョンを選択してください（今回は大阪リージョンで作成しました）。バックアップを別リージョンにコピーするクロスリージョンレプリケーションの設定の宛先に、このバケットを使用します。
次に、重要なデータのログ保管用にバケットをもう一つ作成しておきます。こちらはバージョン管理や暗号化の設定は不要です。
レプリケーションしたいバケットの管理メニューから、レプリケーションルールを表示します。
レプリケーションルールを作成していきます。
送信先には、大阪リージョンに作成したバックアップ用のバケットを指定します。
後は先ほど作成したレプリカキーを改めて選択すれば設定は完了です。これで「4. マルチリージョンでデータを保管する（東京リージョンと大阪リージョン）」の設定も完了となります。
5. アクセスログを取得可能とする
課題：重要なデータに「誰が・いつ・何にアクセスしたか」が記録されていないと、インシデント発生時の追跡ができない。
解決策：バケットのサーバーアクセスログを有効にし、ターゲットバケットに先ほど作成したログ保管用バケットを指定する。
重要なデータを保管するバケットのプロパティを開き、サーバーアクセスのログ記録のメニューを編集します。ターゲットバケットには先に作成したログ保管用バケットを選択してください。
これで「5. アクセスログを取得可能とする」の設定も完了です。
設定した内容が正しく機能しているかの動作確認
1. バージョニングによる復元を確認する（削除してみる）
中身のオブジェクトを削除してみます。
あれ……バージョニングを有効にしたら間違って削除しても復元できると聞いていたのに、一覧からは普通に消えてしまいました。
少し焦りましたが、バージョンの表示を有効にすることで、消してしまったように見えたファイルを確認できます。バージョニングが有効なオブジェクトへの削除操作は、オブジェクト自体を削除するのではなく、削除マーカーを先頭に置くことで「削除された」ものとして扱っているようです。そのため、この削除マーカーを削除すれば、オブジェクトを復元できます。
以下のように削除マーカーのオブジェクトを削除します。
その後、以下のように正常にオブジェクトが復元されていることが確認できます。
2. クロスリージョンレプリケーションが動いているかを確認する
公式ドキュメントによると、レプリケーションはほとんどの場合 15 分以内、場合によっては数時間かかるとのことでした。私の環境では、ファイルを新規アップロードした直後に、バックアップ用のバケットへ重要なデータバケットのオブジェクトがレプリケートされていることを確認できました。
3. アクセスログが取得できているかを確認する
こちらも正常に設定できていれば、以下のように対象の S3 オブジェクトへのアクセス記録がログ保管用バケットに保存されているはずです。
まとめ：重要なデータの保管に S3 の標準機能だけで対応できる理由
本記事では、重要なデータを S3 に保存する際の設定例について解説しました。今回紹介したポイントをまとめます。
- パブリックアクセスのブロック：バケット作成時に有効化するだけで外部公開のリスクをなくせる
- バージョニング：削除は削除マーカーの付与として扱われるため、誤削除からの復元が可能
- AWS KMS による暗号化：カスタマー管理型キーを使うことで鍵の利用状況を追跡できる
- クロスリージョンレプリケーション：別リージョンのバケットへ自動でデータを複製し、リージョン障害に備える
- サーバーアクセスログ：専用のログ保管用バケットを用意し、アクセス記録を残す
私自身、初めて触る機能も多かったのですが、実際に手を動かしてみることで理解が深まりました。この記事を読んだ方も、ぜひ自身の環境で試してみてください。次回は、今回見送ったライフサイクルポリシーの設定について、S3 標準ストレージクラスから低頻度アクセス層への自動移行や、古いバージョンの自動削除といった内容を具体的に解説します。