プロンプトとコンテキスト
マルチテナントのWORMオブジェクトサービスを構築します。オブジェクトはバージョン管理され、固定の保持期間を設定でき、リーガルホールドによって無期限に保護できます。顧客は、保持期間中の削除および上書きの拒否、ガバナンスモードおよびコンプライアンスモード、そして管理者、レプリケーション、ライフサイクルクリーンアップによってバイパスできない監査パスを求めています。書き込み、読み取り、削除、レプリケーション、リカバリ、監査のフローを説明してください。
面接官がテストしていること
- オブジェクトバージョン、保持期間、ガバナンスモード、コンプライアンスモード、リーガルホールドを明確に区別できているか。
- 不変性がクライアントの規約ではなく、ストレージの実行によって強制されているか。
- 権限、ガバナンスバイパス、ルートアカウントの境界、二重承認を設計できるか。
- レプリケーション、リトライ、削除マーカー、クロックの一貫性を処理できるか。
- すべてのポリシー変更と拒否が証明可能な形で監査可能であるか。
最初に明確にすべき質問
- ポリシーはバケット、プレフィックス、オブジェクトバージョン、テナント契約のどれによって定義されますか？
- コンプライアンスモードでは、有効期限前のルートアカウントによる削除も防止する必要がありますか？
- 誰がリーガルホールドを開始、解除、承認し、4-eyes（二重）承認が必要ですか？
- レプリカはロック状態と日付を保持する必要がありますか？また、許容されるクロスリージョン遅延はどれくらいですか？
- クライアントは強い整合性のある読み取り、バージョン一覧表示、証明のエクスポートが必要ですか、それとも削除の拒否だけで十分ですか？
30秒の回答
「私は、オブジェクトデータ、バージョンインデックス、保持ポリシーを分離し、それらの状態をアトミックにコミットします。書き込みによって不変のバージョンが作成され、ポリシーエンジンが retainUntil、モード、リーガルホールド状態を計算し、すべての削除パスが同一の認可境界内でそれらの事実を検証します。ガバナンスモードでは明示的に認可されたバイパスが許可されますが、コンプライアンスモードでは有効期限前のすべての削除が拒否されます。リーガルホールドには日付がなく、承認ワークフローを通じてのみ解除できます。レプリケーションはバージョンとロックのメタデータを引き継ぎます。書き込み、拒否された削除、バイパス、ポリシー変更は、証拠を生成できる追記専用（append-only）の監査ログに記録されます。」
ステップごとの詳細解説
1. バージョンとロック状態のモデル化
保護されるエンティティはオブジェクトキーではなく、objectVersionId です。コンテンツダイジェスト、書き込み時刻、retainUntil、モード、リーガルホールド、テナント、ポリシーバージョンを保存します。単純な削除では、保護されたバージョンを物理的に削除するのではなく削除マーカーを作成します。完全な削除にはバージョンを指定し、ロックチェックを通過する必要があります。
2. 書き込みとデフォルト保持の設計
バケットまたはテナントポリシーでデフォルトのモードと期間を提供でき、書き込み時にオブジェクトレベルの値を要求することもできます。最大期間、時刻ソース、権限を検証し、計算されたメタデータをバージョンにアトミックにバインドします。ポリシー変更は将来のバージョンにのみ影響し、既存の保持期間を遡及して短縮することはできません。
{
"objectVersionId": "v_91c2",
"retention": {"mode": "COMPLIANCE", "retainUntil": "2027-01-01T00:00:00Z"},
"legalHold": "OFF",
"policyVersion": 18
}3. 削除および上書きゲートの強制
削除、上書き、保持期間の短縮、リーガルホールドの解除は、単一の認可サービスを使用します。最新のバージョンを読み取り、時刻、モード、プリンシパルの権限、ホールド状態を条件付きでチェックします。ガバナンスモードには明示的なバイパス権限とリクエストマーカーが必要です。コンプライアンスモードでは、管理者を含む有効期限前のすべての削除が拒否されます。拒否時には安定したエラーと監査IDが返されます。
4. リーガルホールドと承認の設計
リーガルホールドは保持期間とは独立しており、明示的に解除されるまでバージョンを保護します。解除ワークフローには、案件または契約、理由、実行者、承認者、ステップアップ認証が紐付けられます。高リスクのテナントでは2名による承認を必須にできます。解除後も、有効期限内の retainUntil が引き続きバージョンを保護するため、ホールドは保持期間を上書きするものではありません。
5. レプリケーション、リカバリ、クロックの処理
レプリケーションは、コンテンツ、バージョンID、ダイジェスト、完全なロックメタデータを転送します。ターゲットはコミット前にソースの署名とポリシーバージョンを検証します。ソースはターゲットが確認するまで削除の拒否を継続し、ターゲットはロック検証前にコンプライアンスを主張することはできません。リカバリは新しいバージョンを作成し、古いバージョンを変更することは決してありません。日付の比較には、単一のマシンクロックではなく、制御された時刻サービスと単調増加する監査タイムスタンプを使用します。
6. 監査と証明の構築
書き込み、バージョン作成、成功または拒否された削除、バイパス、リーガルホールドの変更、レプリケーション確認、ポリシー発行を監査します。イベントは、ハッシュまたは署名チェーンを備え、クエリ権限が制限された独立した追記専用ログに保存します。定期的にバージョンインベントリ、ロック状態、監査ダイジェストをエクスポートし、顧客が特定の時点での保護を証明できるようにします。
優れた回答の例
「私はバージョンとロックのメタデータを不変の事実として扱い、すべての削除パスで現在の状態を読み取って条件付きチェックを実行します。書き込み時、ポリシーエンジンが保持期間、モード、リーガルホールドを計算し、それらをバージョンにアトミックにバインドします。ガバナンスモードでは明示的に認可されたバイパスを許可し、コンプライアンスモードでは有効期限前のすべての削除を拒否します。リーガルホールドは、案件、理由、承認がある場合にのみ解除されます。レプリケーションはバージョン、ダイジェスト、ロックメタデータを伝送し、ターゲットでの確認後にのみコンプライアントになります。拒否、バイパス、ポリシー変更、レプリケーションは追記専用の署名付き監査ログに記録され、クライアントはそこからバージョンインベントリと証明ダイジェストをエクスポートできます。」
よくある間違い
- APIレイヤーでのみロックをチェックする → クリーンアップやレプリケーションパスでバイパスされる → ストレージ削除実行時に再チェックする。
- バケットポリシーの変更を古いバージョンに適用する → 既存の保持期間が不正に短縮される可能性がある → ポリシーをバージョン管理し、将来の書き込みにのみ影響させる。
- リーガルホールドを固定の日付として扱う → 期限切れ後の自動削除が案件に違反する可能性がある → 明示的な解除を伴う独立したホールドとして維持する。
- ガバナンスバイパスを暗黙的なものにする → 特権の不正使用を説明できなくなる → 明示的な権限、マーカー、承認監査を必須にする。
- レプリケーション送信時にコンプライアンスを宣言する → ターゲットがロックメタデータを失う可能性がある → ターゲットのバージョンとロック状態を最初に確認する。
フォローアップと回答
なぜ単純なDELETEがバージョンを削除せずに成功するのですか？
バージョン管理されたオブジェクトでは、単純なDELETEは現在のバージョンを非表示にする新しい削除マーカーを作成するだけで、保護されたバージョンは残ります。完全な削除にはバージョンIDを指定し、ロックゲートを通過する必要があります。
なぜコンプライアンスモードにはより強力なアカウント境界が必要なのですか？
その意味は、ルートアカウントやストレージ管理者を含むいかなるプリンシパルも、保持日より前に削除できないということです。特権ロールがコンプライアンスを無効化できないよう、削除は通常のIAMスーパーユーザー権限から隔離されている必要があります。
拒否された削除が監査から漏れていないことをどのように証明しますか？
認可決定、バージョン状態、監査イベントに単一のリクエストIDを使用し、そのイベントを別の追記専用ログに書き込みます。削除リクエスト、バージョンインベントリ、拒否イベントを定期的に照合し、ギャップが発生した場合は高リスクな操作を凍結します。
レプリケーションが遅延している間、ソースを削除してもよいですか？
いいえ。ターゲットがコンテンツダイジェスト、バージョンID、保持メタデータを確認するまで、ソースのロックは維持されます。そうしないと、レプリケーションの失敗によってコンプライアントなコピーが存在しない期間が生じてしまいます。