S3 Object LockのCompliance設定｜rootでも期限前に削除できない

S3 Object LockのComplianceモードでは、AWSの保持モードの説明にある通り、AWSアカウントのrootユーザーも保護対象のオブジェクトバージョンを保持期限前に削除・上書きできず、保持期間も短縮できない。制限がかかるのはバケット内のすべてのデータをひとまとめにした単位ではなく、保持設定を受けた個々のバージョンだ。

安全に導入する順序は、テスト用バケットでバージョニングとObject Lockを有効にし、Governanceで削除の挙動を試してから、Complianceの対象と保持期間を決めることだ。続けて、バケットの既定保持と個別設定の優先順位、リーガルホールド、保護済みバージョンからの復元を確かめる。Complianceを適用した後に保持期間の入力ミスを修正することはできないため、設定値だけでなく、実際に作成されたバージョンの状態を見る必要がある。

テスト用バケットでバージョニングを確かめる

最初に実データを入れない汎用バケットを用意する。AWSのObject Lock設定手順では、新規バケットの作成時にバージョニングとObject Lockを有効にする操作に加え、既存バケットの「プロパティ」からObject Lockを有効にする操作も示している。Object Lockが機能するのは、バージョニングが有効なバケットだけだ。

有効化後はObject Lock自体を無効にできず、そのバケットのバージョニングも停止できない。この不可逆性を踏まえ、テスト用と本番用のバケットを分けて考える。既存バケットを使う場合は、バージョニングの状態だけでなく、そこに残る既存のオブジェクトバージョンも確認してから有効化する。バケットで機能を有効にする操作と、各バージョンに必要な保持条件を与える操作は別だ。

まずテスト用のオブジェクトをアップロードし、バージョンIDを記録する。続けて同じキー名で内容を変えたオブジェクトを置き、別のバージョンが作られることを確認する。Object Lockの保持設定はバージョンごとに適用されるので、後から作ったバージョンの設定だけを見て、以前のバージョンも保護されたと判断しない。保持モードと保持期日は、それぞれのバージョンについて確かめる。

Governanceで削除を試してからComplianceを選ぶ

Governanceは通常の利用者による保護対象バージョンの削除や保持設定の変更を制限しつつ、権限を持つ利用者の例外操作を認める。バイパスには「s3:BypassGovernanceRetention」権限と、バイパスを明示したリクエストが必要になる。ただしS3コンソールは、権限がある利用者の操作に必要なヘッダーを自動で付ける。コンソール上での削除を試すときは、その利用者にどの権限があるかも結果と一緒に記録する。

Complianceでは、保護済みバージョンについて同じ例外を設けられない。保持期限の設定が長すぎても、そのバージョンのモードを変更したり期限を早めたりすることはできない。保持期限前に対象を削除する手段としてAWSが挙げるのは、関連するAWSアカウント自体の削除だけだ。管理者による訂正の余地が必要ならGovernance、rootユーザーにも期限前の削除を認めない要件ならComplianceという違いを、対象データと運用責任者の間で先に決めておく。

テストではGovernanceを設定したバージョンに対し、例外権限のない利用者と権限のある利用者で操作を分ける。削除の可否に加え、どのバージョンIDを指定したかを残す。Complianceを試すときは、保持期限を慎重に選んだ別のテストバージョンを使う。Governanceの設定を後からComplianceに切り替えて元に戻す、という試し方を前提にしないほうが、期限を誤って延ばす危険を避けやすい。

「上書きできない」という制限もバージョン単位で理解する。同じキー名に新しい内容をアップロードすると、S3は保護済みの旧バージョンを改変せず、新しいバージョンを作る。現在のキー名から見える内容が変わっても、旧バージョンの保持期限はそのまま残る。バックアップの保全を確かめるときは、キー名だけでなく、守るべきバージョンIDとその保持状態を対応させる。

既定保持と個別設定の優先順位を確認する

バケットに既定保持を設定すると、以後そこに置かれるオブジェクトバージョンに、指定したモードと期間が適用される。期間は日数または年数で指定し、各バージョンの作成時刻を基に保持期日が決まる。既定保持を変更できることと、すでにComplianceで保護されたバージョンの期限を短縮できることは別の話だ。変更後のバケット設定だけを見ても、過去に作成したバージョンの期限は分からない。

アップロード時にバージョンごとの保持モードと期間を明示した場合は、その個別設定がバケットの既定保持より優先される。たとえば、既定をGovernanceにしたバケットでも、特定のバージョンにComplianceを明示すれば、そのバージョンはComplianceの制限を受ける。バックアップ処理やアップロードに使うツールが個別設定を送っているなら、バケットの既定値だけを監査しても実際の保持状態を把握できない。

テスト用バケットでは、既定値だけを使ったアップロードと、個別の保持条件を付けたアップロードを分ける。作成された各バージョンについて、バージョンID、保持モード、保持期日を照合する。期間を決める際は、保護したいデータの保存要件に加え、誤投入したデータも期限まで残り得ることを織り込む。特にComplianceの既定保持を本番バケットへ設定する前に、実際の書き込み経路が意図した条件でバージョンを作るか確かめたい。

リーガルホールドを別の条件として扱う

リーガルホールドは、終了日を指定する保持期間とは独立した、バージョン単位の保護設定だ。明示的に解除されるまで続くため、終了日を事前に決められない保全に使える。保持期間と同じバージョンに併用することもでき、期限が満了してもホールドが残っていれば保護は続く。

一方、リーガルホールドは所定の権限を持つ利用者が解除できる。Complianceの保持期間中にホールドを解除しても、その保持期限が早まるわけではない。テストでは、対象のバージョンIDを指定してホールドを付け、状態を確認し、解除権限を持つ利用者と解除判断の手順を確かめる。期間満了後も残す必要があるデータと、定めた期限まで保存すればよいデータを分けることが、設定の混同を防ぐ。

削除マーカーを見分け、元のバージョンを復元する

削除テストでは、バージョンIDを指定しない通常の削除と、保護対象のバージョンIDを指定する永久削除を分ける。AWSの削除マーカーの説明にあるように、通常の削除では削除マーカーが加わっても、保護済みの元のバージョンは残る。削除マーカー自体は、元のバージョンの保持期間やリーガルホールドによる保護を受けない。

テスト用オブジェクトの内容とバージョンIDを控えてから通常の削除を行い、バージョン一覧に削除マーカーと元のバージョンが並ぶことを確認する。キー名だけで取得すると削除されたように見えても、元のバージョンIDを指定すれば残った内容を取得できる。次に、保持期限前の保護済みバージョンをID指定で削除しようとし、拒否されることを確かめる。通常の削除操作が受け付けられたという結果だけでは、保護の成否は判断できない。

復元確認は、残ったバージョンを取得するところで終えない。削除マーカーを取り除くか、必要な内容を新しいバージョンとして戻し、利用側が再び目的のデータを参照できるところまで試す。保護された旧バージョンと復元後の新しいバージョンには、それぞれ別の保持状態があり得るため、復元後もバージョンIDと保持条件を確認する。これで、削除を防ぐ設定と、必要なときにデータを使える状態へ戻す手順を一続きで検証できる。