3ステップでS3オブジェクトロックの概要と特徴をざっくり理解する

AWS運用自動化サービス「Cloud Automator」

「rootアカウントですら永久にオブジェクトを削除できなくなるような機能がS3に追加されたらしい・・・」

S3オブジェクトロック機能がローンチされた際ちらほらこんな噂が聞かれました。
こうした「rootですら削除できなくなる」「設定中は無期限で削除できなくなる」といった一部機能に関する話題が若干の誤解付きで広まってしまい使いづらい機能と決めつけている人がいかんせん多いように思います。

今回は3ステップに分けて、S3 オブジェクトロックは(ちゃんと使えば)怖くない、
割と使い道はあるということを皆さんにご理解いただくためにこのエントリーを書いてみました。

第1ステップ:オブジェクトロックは怖い機能でないことを理解する

オブジェクトロック機能は既存のS3バケットでは有効化できず、新規作成時に明示的に設定しないと利用することができません。
コンソールでの作成手順でいうと、名前とリージョンを入力した後の[オプションの設定]の段階の[詳細設定]にて設定することができるのですが、有効化しようとした際に表示されるのが下記の画面です。
おっかないですね。「完全に」という文言には圧迫感があり、作成直後にすぐさま削除不可となるような印象を受けます。

ただ、実際はそんなことはありません。
その後も設定を進めてバケットを作成し終えた後のオブジェクトロック設定は以下のような表示になっています。
オブジェクトのロックを設定しうる機能が「完全に有効化」されているだけで、実際にバケットのオブジェクトに対してどの程度の強度・期間でロックをかけるかは別問題。それらの設定は追々することになるということです。

なので機能の有効化自体はあまり身構えずに行っていただければと思います(もちろん、本番利用用のバケットで利用予定もないのにむやみやたらに有効化するのはやめましょう)

第2ステップ:主要機能の概要を理解する

それでは機能有効化後に設定できる「ガバナンスモード」、「コンプライアンスモード」はそれぞれどういった機能なのでしょうか。

概略は以下の通りです。

  • ガバナンスモード:オブジェクトが保存されてから指定期間が経過するまでにおいて、特定の権限を持つユーザ以外に対して、バケット内のオブジェクトのバージョンの上書きや削除・ロック設定変更を防ぐことが可能
    • 指定期間内root含めs3:BypassGovernanceModeを持つユーザであれば操作可能
  • コンプライアンスモード:オブジェクトが保存されてから指定期間が経過するまでにおいて、バケット内のオブジェクトのバージョンの上書きや削除を一切防ぐことが可能
    • 指定期間内においては、root含めいかなるユーザいかなるシチュエーションでも削除不可能

いずれのモードでも保存されてから指定期間が過ぎれば削除操作は可能となります。無期限に適用されることはないのですね。

保護指定期間は1日から設定可能なため検証時は短めの設定で試用すれば自身の想定と異なる挙動をしてもそうそう困ることはないと思います。

具体的な設定手順としては、[なし]以外の2つのいずれかのモードにチェックをすると
保持期間の入力フォームが出現するためそこで任意の日数を指定して[保存]を押すと

以下のような警告が出ますので、[確認]を押すと設定を有効化できます。
アホみたいに長い日数を指定するのは自重しましょう。

なお、これらのモードとは別に「リーガルホールド」と呼ばれる個々のオブジェクトバージョンに対して適用できる機能も存在します。

このモードはどのモードを有効化している状況下でも(あるいはモードの適用が[なし]の状態でも)オブジェクトのロックを設定できる機能が「完全に有効化」されていさえすればいつでも設定することができます。

リーガルホールドを解除するまで、同機能が設定されたオブジェクトバージョンは無期限で保護されますが、適用の解除はrootではなくs3:PutObjectLegalHoldという権限を持つユーザであれば実行可能なため気軽に試せる機能と言えます。

また、ここでオブジェクトロックの各モードやリーガルホールドを有効化&オブジェクトを保存した後に、オブジェクトを操作した際の
具体的な挙動について以下に整理しておきますので参考にしてください。

  • 既存のオブジェクトを新しいファイルにて更新・上書きしようと試みた場合 => 失敗はせず、新しいファイルが最新verとして保存される。既存のオブジェクトは過去のverとして保存される
  • 既存のオブジェクトの削除を試みた場合 => 失敗はせず、見かけ上はオブジェクトは削除されたかのように見える(削除マーカが最新Verとして保存される)が、削除操作前のオブジェクトは過去Verとして保存され復旧可能
  • 既存のオブジェクトの具体的なバージョンに対して更新や削除を試みた場合 => 失敗する

第3ステップ:MFA Delete機能と比較してオブジェクトロックの長所を理解する

ここまで読み進めていただければ、オブジェクトロックの概要と同機能が極度に危険なものでないことはご理解いただけたかと思います。

ただ、「MFA Deleteって機能があったよね。あれでよくね?」と思われる方が一部にはいらっしゃいそうです。私はむしろオブジェクトロックの利点はMFA Deleteと比較してこそ理解できるのではないかと考えています。

以下にごくごく簡単な比較表を作成してみました。

  MFA Delete ガバナンスモード コンプライアンスモード
機能の実装方法 rootユーザのみ設定可能 非rootユーザで設定可能 非rootユーザで設定可能
有効環境下でのオブジェクトバージョンの削除 MFAデバイスの認証がある場合にのみ削除可能 保護期間内はいかなる場合でも削除不可 保護期間内は特定権限を持つユーザのみ削除可能
有効環境下でのライフサイクルポリシーの設定 設定不可 設定可能  設定可能

まず、MFA Deleteに言えることは実装方法が若干面倒であるということです。

rootユーザしか実装できず、この機能を欲するようなユーザはrootをかなりセキュアに管理していることがままある(ex.rootユーザログイン用のMFAデバイスを特定部署の金庫で管理している)ため、実装に躊躇したり手間取ることがありえます。

一方、オブジェクトロックに関しては比較的容易に実装が可能なため、機能概要を把握しているユーザからすればこちらの方が導入するのに便利であると言えるでしょう。

また、ライフサイクルポリシーを設定不可であるということもMFA Deleteのポイントでしょう。

MFA Delete有効化の環境下ではバージョンは削除されず肥大化する一方ですが、オブジェクトロック機能を有効にした環境下では適切な設定を実施さえすれば必要最低限の期間内・容量分だけオブジェクトの保持ができるようになります。

・・・いかがでしょう。他にも比較のポイントはあると思いますが、これらだけでも
CloudTrailの保存先等セキュアな運用を必要とするバケットをはじめとして
そこそこ採用の余地があるような感じはしないでしょうか。

最後に

今回はS3 オブジェクトロックの概要と利点を紹介してみました。今まで同機能を敬遠してたもしくは無視してた方が「ちょっと試してみようかな」と思うきっかけにこの記事がなれば嬉しく思います。

なお、実際に検証する際はバージョニングされたオブジェクトの削除は保護されていなくても若干面倒ですので、少量で展開することをおすすめします。

AWS運用自動化サービス「Cloud Automator」