Amazon S3のオブジェクトロック機能についてあらためて調べてみた

こんにちは。サービスグループの武田です。

AWS環境において、ログの保存はCloudWatch LogsやS3を使用することが一般的です。さて、AWS CloudTrailで収集された監査ログはS3に保存できますが、勝手に消されては困るデータです。そのデータを守る手段として何が考えられるでしょうか。ひとつは次のエントリで紹介されているSCPでs3:Delete*を制限する方法です。

このエントリでは別の方法としてオブジェクトロックについて考えてみます。

オブジェクトロックとは

オブジェクトロックはS3バケットに保存するオブジェクトに対してWORM（Write Once Read Many）モデルを提供する機能です。これにより、オブジェクトが削除および上書きされるのを一定期間または無期限に防止できます。

バケットのオブジェクトロックを有効にすると、自動的に バージョニングも有効 になり、無効化はできません。AWS CLIなどでバケットを作成する際も、明示的にバージョニング有効化を指定しなくても有効化されるため、この挙動は把握しておきましょう。

オブジェクトロックではリテンションモードとして、次の2種類のモードを提供しています。

• ガバナンスモード
  • s3:BypassGovernanceRetention権限を持たないユーザーはオブジェクトの上書き、削除ができない
• コンプライアンスモード
  • ルートユーザーを含め、すべてのユーザーはオブジェクトの上書き、削除ができない

一度コンプライアンスモードでロックしてしまうと保持期間を過ぎるまでオブジェクトの削除などができなくなります。そのため事前にガバナンスモードで保持期間の設定テストなどをするとよいでしょう。ちなみに無期限にロックしたい場合はリーガルホールドという機能を使用しますが、ここでは深く触れません。

テストはガバナンスモードで

前述したようにガバナンスモードはs3:BypassGovernanceRetention権限を持っていれば削除などが可能です。実際にはリクエストヘッダーにx-amz-bypass-governance-retention:trueが必要なのですが、マネジメントコンソールでは自動で付与されるため意識せず操作できます。またAdministratorAccessポリシーを付与しているようなユーザーは権限を持っているため削除できてしまいます。テストする際には権限を絞ったユーザーを用意するようにしましょう。

ストレージクラスの移行について

オブジェクトロックが有効であってもストレージクラスの移行は可能です。しかし、バージョニングが有効なことによる注意点があります。ストレージクラスを変更する方法は手動での変更とライフサイクルルールによる移行がありますが、それぞれで挙動が異なります。

• 手動での変更
  • 元のオブジェクトは以前のバージョンとして変更前のストレージクラスに残り、最新バージョンが変更後のストレージクラスに作られる
• ライフサイクルルールによる移行
  • 指定したバージョンのストレージクラスが直接変更される（最新バージョンか以前のバージョンかはライフサイクルの設定による）
  • 新しいバージョンが作られることはない

バージョニングの挙動を正しく理解していなかったのもあり、この挙動の違いは学びでした。

ライフサイクルルールによる削除

ライフサイクルルールによるオブジェクト削除は可能です。ただし最新バージョンの場合は削除マーカーが付くだけで完全に削除はされません。また以前のバージョンについては、オブジェクトロックの保持期間を過ぎれば完全に削除が可能です。

リテンションモードの変更

リテンションモードの変更はどうでしょうか。これはバケットとオブジェクトで扱いが異なります。そもそも実際にロックされているのはオブジェクトであり、バケットはデフォルトを設定しているだけということが重要です。

バケットの設定は相互にリテンションモードを変更できますし、デフォルトの保持期間を無効にもできます。前述したように、この設定は新規オブジェクトへ適用されるデフォルト設定であるため、既存オブジェクトには影響しません。

一方でオブジェクトの設定はガバナンスモード→コンプライアンスモードの一方向のみ可能です。もちろんガバナンスモードの場合はロックを外すこともできますが、コンプライアンスモードはイミュータブルのため一切変更できません。

保持期間の変更

オブジェクトロックの保持期間はどちらのリテンションモードでも 伸ばすことは可能 です。反対に短くすることはどちらのリテンションモードでもできません。

ただしガバナンスモードの場合はワークアラウンドがあります。一度設定した保持期間は短くできないので、代わりに新しく短い期間を設定してやればよいです。具体的には次の手順で保持期間を短くできます。

1. 対象オブジェクトのオブジェクトロックを無効化する
2. 対象オブジェクトに以前より短い日付を指定してオブジェクトロックを有効化する

オブジェクトロックが設定されたS3バケットをサポートしないケース

一部のAWSサービスはオブジェクトロックが設定されたS3バケットをサポートしません。すべてを調べられてはいませんが、ドキュメントで確認できたものを紹介します。

• AWS Configの配信チャネル
  • 配信チャネルの管理 - AWS Config
• S3のサーバーアクセスログ
  • S3 オブジェクトロックの仕組み - Amazon Simple Storage Service

まとめ

結論としては ログを保護する機能として有用 ではないかと思われます。AWS Configと違いCloudTrailはサポートされています。またコンプライアンスモードを設定しておけば万が一ルートユーザーやAdministrator権限のアクセスキーが漏洩してしまっても証跡は消されません（もちろん漏洩しないに越したことはないです）。

最後に保持期間ですが、これは悩ましいですね。セキュリティポリシーなどにもよりますが、長すぎず短すぎずで1年間あたりが落とし所でしょうか？ライフサイクルルールによるストレージクラスの移行も検討したいところですが、CloudTrailの証跡ログは比較的小さいファイルのためスタンダードのままでよいのではないでしょうか。

CloudTrailのログを守る手段の候補としてオブジェクトロックを調べてみました。参考になれば幸いです。