プロンプトと適用範囲
マルチテナントプラットフォームにはすでに監査イベントが保存されていますが、セキュリティチームは、プライマリデータベースへのアクセス権を持つ者によって履歴レコードが削除、並べ替え、または再計算されていないかを判断する独立した方法を必要としています。正規化、セグメント化されたハッシュチェーン、署名、外部アンカー、検証ツールの出力、および検証不能な区間の処理に焦点を当てて検証プロトコルを設計してください。
追記専用（append-only）レコードとハッシュチェーンにより、後からの編集を検出できるようになりますが、イベントが最初に書き込まれたときに真実であったことまでは証明できません。この質問では、脅威モデリング、証拠性、および運用をテストします。イミュータブルなオブジェクトストレージ単体では完全な設計とは言えません。
面接官が評価するポイント
アクター、対象、アクション、時刻、ソース、結果に関するイベントフィールド、ビジネストランザクションへの信頼性の高い結合、セグメント化およびアンカーされたハッシュチェーン、テナントの分離、インデックス、キーの権限、保持期間、削除、および実用的な検証ツールを評価します。
回答前に明確にすべき質問
- 脅威アクターは、イベントストア、ハッシュカタログ、署名キー、およびアンカーメディアを変更できますか？
- 検証では、削除、変更、並べ替えの検出のみが必要ですか、それともイベントソースの証明も必要ですか？
- プラットフォーム、セキュリティチーム、または外部監査人の誰が検証ツールを実行しますか？
- レコードはどのくらいの期間アンカーされない状態を維持でき、ギャップが発生した後に調査ワークフローはどのように縮退（デグレード）すべきですか？
30秒の回答フレームワーク
「イミュータブルな正規化イベントを定義し、ビジネストランザクションのコミット後にアウトボックス（outbox）経由で発行します。分離されたライターがイベントをテナントと時間ごとにグループ化し、ハッシュチェーンを構築して、各チェーンヘッドを独立した追記専用ストアまたは透明性台帳に定期的にアンカーします。クエリには再構築可能なインデックスを使用し、証拠を決して変更しません。検証ツールはチェーンを再計算してアンカーと比較します。整合性はチェーンから得られますが、イベントの真実性は依然としてビジネス上の認可とトランザクションレコードに依存します。」
ステップごとの詳細な回答
ステップ 1：脅威モデルと証拠の目標を定義する
アプリケーション管理者またはデータベース管理者がレコードの削除、並べ替え、または書き換えを行う可能性があり、アンカーサービスが利用できない場合があると想定します。目標が欠落、変更、または並べ替えられたイベントを検出することなのか、それとも主体が行動したことを証明することなのかを判断します。監査ログはアクセス制御の代わりにはなりません。
ステップ 2：正規化イベントを設計する
イベントID、テナント、アクターとIDソース、アクション、リソース、事前および事後のダイジェスト、リクエストID、イベント時刻、サーバーシーケンス、結果、およびポリシーバージョンを含めます。シリアライズの順序によってハッシュが変わらないように、JSONなどのフィールドを正規化します。機密値については、ダイジェストまたは制御された参照のみを保存します。
ステップ 3：ビジネス書き込みと監査書き込みを結合する
ビジネストランザクションがアウトボックスに書き込み、信頼できるコンシューマーがコミット後にイベントを発行します。ビジネス書き込み後のベストエフォートなロギングに依存してはいけません。再試行はイベントIDによって冪等性を保ち、障害は分離されたキューに送られてアラートを発報します。監査のレイテンシは制限される場合がありますが、サイレントな損失は許容されません。
ステップ 4：セグメント化されたハッシュチェーンを構築する
前のハッシュ、正規化イベント、および現在のハッシュ（H(previous || event || metadata) など）を保存します。テナント、日付、またはサイズごとにセグメントをローテーションし、セグメントの開始、終了、およびシーケンスを記録します。シャード間の順序付けには、クライアントの時計のみではなく、サーバーのシーケンスと受信時刻を使用します。
ステップ 5：外部にアンカーし、キーを管理する
アンカー時刻、セグメントID、および署名とともに、各セグメントヘッドを独立した追記専用メディアに定期的に書き込みます。署名キーは制御されたキーサービス内に保持し、ローテーションと失効自体も監査対象とします。独立したアンカーにより、データベースライターがチェーン全体を不可視に再計算して置き換えるのを防ぎます。
ステップ 6：クエリと権限を分離する
検索インデックスまたはリードレプリカに、アクター、リソース、アクション、および時刻のインデックスを構築します。インデックスは再構築可能ですが、証拠は更新できません。テナント、ロール、および目的のチェックを適用し、エクスポートに検証ダイジェストを含めます。すべての読み取り、エクスポート、または検証は、新たな監査イベントになります。
ステップ 7：保持、削除、およびプライバシーを処理する
規制に従って保持、WORM、またはオブジェクトロックポリシーを設定します。個人データの削除には、削除が発生したという証拠を保持しながら、暗号消去、フィールドのマスキング（墨消し）、または不可逆なダイジェストを使用します。決してサイレントに履歴を書き換えてはいけません。バックアップ、キャッシュ、およびアンカーの保持期間を一致させます。
ステップ 8：検証、回復、および監視を行う
検証ツールは、チェーンの連続性、シーケンス、正規ハッシュ、署名、および外部アンカーをチェックします。定期的なサンプリングおよび完全検証を実行し、ギャップ、遅延、重複、アンカリング障害、および検証時間を監視します。信頼できる最後のアンカーからアウトボックスと追記専用セグメントをリプレイして回復し、証明不能な範囲を分離します。
より深いトレードオフと境界
#### 単一チェーン vs セグメント化されたチェーン
単一のチェーンはクエリを簡素化しますが、回復と並行書き込みを複雑にします。セグメント化により、セグメントアンカーと順序メタデータのコストと引き換えに、テナントの分離、並列検証、および保持管理が可能になります。
#### ハッシュチェーン vs 署名付きログ
ハッシュチェーンは安価で編集を検出します。署名は組織横断的な検証とキー管理コストを追加します。外部への証明が必要な場合はこれらを組み合わせます。
#### 整合性 vs 真実性
チェーンはレコード間の関係とアンカーの一貫性を証明しますが、イベントの内容が真実であったことは証明しません。真実性は依然としてID、認可、トランザクション、および独立した証拠に依存します。
障害訓練と進化
#### 中間のレコードが削除された場合
セグメントから1つのオブジェクトを削除し、シーケンスのギャップとチェーンの切断がセグメントおよびアンカーの位置とともに報告されることを検証します。
#### データベース管理者がハッシュを再計算した場合
セグメントを書き換えてそのヘッドを置き換えます。独立したアンカーが新しいチェーンを拒否し、調査のために古いチェーンが取得可能なままである必要があります。
#### アンカーサービスが利用できない場合
接続を切断し、セグメントがアンカー保留状態になり、イベントの耐久性が維持され、回復後にアラートとともにアンカーが順序通りに追加されることを検証します。
高品質な回答例
「私はまず検証の境界を定義します。攻撃者はイベントストアや検索インデックスを変更する可能性がありますが、独立したアンカーを書き換えたり検証キーを取得したりすることはできません。ライターは各イベントを決定論的な正規表現に変換し、テナントと時間ごとにレコードをセグメント化し、シーケンス番号、前のハッシュ、および現在のハッシュを保存します。各セグメントの末尾に署名し、別個の権限の下で追記専用メディアにチェーンヘッドを定期的にコミットします。
独立した検証ツールは、信頼できるアンカーから開始し、正規ハッシュを再計算して、シーケンスの連続性、セグメント間のリンク、署名、アンカー時刻、および保持ポリシーをチェックします。削除はシーケンスギャップを生じさせ、変更はハッシュの不一致を生じさせ、並べ替えは先行リンクを切断し、セグメント全体を再計算した管理者も外部アンカーと一致させることはできません。結果は、単一のブール値ではなく、検証された範囲、最初の失敗位置、アンカーされていないウィンドウ、および証拠の参照を報告します。区間を検証できない場合、影響を受けるエクスポートを凍結し、元のオブジェクトを保持してセキュリティチームに通知します。チェーンはレコードの整合性を確立しますが、イベントの真実性を確立するには、ID、認可、およびビジネストランザクションの証拠が依然として必要です。」
よくある間違い
- 誰が書き込みや保持期間の変更を行えるかを定義せずに、データをWORMストレージに配置すること。
- フィールドの順序、エンコーディング、およびタイムスタンプを正規化せずに生のJSONをハッシュ化すること。
- 有効なハッシュチェーンを、すべてのイベントが真実であったことの証拠として扱うこと。
- 失敗したチェーンを自動的に再構築して置き換え、調査の証拠を破壊してしまうこと。
フォローアップの質問と回答
外部アンカーは何を解決しますか？
プライマリDitabaseへの書き込みアクセス権を持つオペレーターが、セグメント全体を密かに再計算してそのチェーンヘッドを置き換えるのを防ぎます。アンカーには個別の権限と保持期間が必要です。
レコードが削除されたことを検証ツールはどのように証明できますか？
シーケンスのギャップと後続ハッシュの破損の両方を検出し、最も近い信頼できるアンカーを使用して欠落した区間を境界づけます。検索インデックスからの欠落だけでは不十分です。
アンカーサービスが利用できない間はどうなりますか？
シーケンス番号が付与されたローカルセグメントの書き込みを継続し、保留中としてマークします。回復後に順序通りに送信します。アンカーされていないウィンドウは検証ツールの出力とアラートに表示される必要があり、完全に検証されたものとして記述することはできません。
検証不能な区間はどのように処理すべきですか？
影響を受けるエクスポートを隔離し、元のオブジェクト、署名、およびアンカー証拠を保持し、セキュリティチームに通知して対応を記録します。回復処理によって、未知の区間に完全であるというラベルを再度付けてはなりません。