プロンプトとスコープ
マルチテナント対応の Certificate Transparency（CT）ログモニターを設計してください。ユーザーが1つ以上のドメインを登録すると、本サービスは公開 CT ログを継続的にチェックし、一致する証明書または事前証明書（precertificates）についてアラートを発報するとともに、ログデータが不正に書き換えられていないことを証明します。また、停滞したログ、証明の失敗、maximum merge delay 違反も検出する必要があります。
これは、プラットフォームセキュリティおよび証明書インフラストラクチャの職種における優れたシステムデザイン問題です。重要なのは、流行りのサービスを列挙することではなく、検証可能なデータパイプラインと明確な障害境界を構築することです。
面接官が評価するポイント
- モニターの役割をブラウザポリシーや CA の発行処理と明確に区別できているか。
- signed tree head（STH）、マークル包含証明、一貫性証明、追記専用（append-only）セマンティクスを理解しているか。
- maximum merge delay（MMD）を測定可能なスケジューリングおよびアラート条件として落とし込めているか。
- 複数ログの監視、重複読み取り、スプリットビュー、障害発生時の挙動、テナント分離を考慮しているか。
- ストレージ、冪等性、アラートノイズ制御、キャパシティの前提条件が具体的であるか。
最初に確認すべき明確化のための質問
次の4つの境界を確認します：
- マッチングは完全一致、登録可能ドメイン、ワイルドカード、SAN 内の名前のどこまでカバーすべきか。
- 準リアルタイムの検出が必要か、それとも分単位のレイテンシで十分か。どの通知チャネルやオンコールエスカレーションが必要か。
- モニターはすべての公開ログを検査する必要があるか、それとも選択された信頼済みログセットのみでよいか。生の証明書と証明データは保持すべきか。
- テナント数、保持期間、プライバシー要件、予算はどの程度か。
回答が得られない場合は、100個のログを毎分1回ポーリングし、エンドツーエンドの検出目標を5分とし、監査証跡を保持する前提で進めます。
30秒での回答フレームワーク
システムをログ収集、暗号検証、証明書マッチング、アラート、監査ストレージに分割します。各ログは検証済みのツリーサイズと最新の STH を保持します。コレクターは STH の署名を検証し、増分でエントリを取得し、包含証明または一貫性証明を使用して追記専用動作を確認します。マッチング層は SAN、ワイルドカード、登録可能ドメインを正規化します。アラート層は重複を排除し、テナントポリシーに従ってエスカレーションします。監査層は生のエントリ、STH、証明、ハッシュを保存します。主要なメトリクスは STH の鮮度、ログの遅延、証明失敗率、アラートレイテンシ、偽陽性率です。スプリットビューや MMD 違反が発生した場合、そのログの信頼状態を凍結してエスカレーションします。
ステップごとの詳細解説
1. 収集とステートマシン
各ログの識別情報、公開鍵、信頼済みツリーサイズ、最終検証済み STH、最終ポーリング時刻、状態を保存します。スケジューラーは状態に応じて作業を割り当てます。通常のログには増分読み取りを行い、一時的な障害には指数バックオフを適用し、障害が続く場合は隔離状態に移行させます。ログの識別情報とターゲットツリーサイズをタスクキーとして使用し、リトライが冪等になるようにします。
2. STH とマークル検証
まずログの公開鍵で STH の署名とタイムスタンプを検証し、次にツリーサイズが単調非減少であることを要求します。初回同期で完全なスナップショットを確立し、それ以降の同期では一貫性証明を使用して新しいツリーが古いツリーを含んでいることを示します。一致した各エントリについて、包含証明を使用してそれがそのツリーに属していることを証明します。証明の失敗、ロールバック、不正な署名があった場合、古い状態を上書きしてはなりません。証拠を保持し、ログに疑わしいフラグを立てます。
3. 増分読み取りと整合性
最後に確認されたツリーサイズ以降の範囲をリクエストし、生の証明書、事前証明書、ログ内の位置、受信時刻を書き込みます。1つの証明書が複数のログに現れたという事実を破棄することなく、エントリの識別情報によって重複排除します。MMD 以内に検証可能な新しい STH が届かない場合は、ログの遅延を記録し、プラットフォームアラートを発生させます。「新しいエントリが確認されなかった」ことから「一致する証明書は存在しない」と推論してはなりません。
4. 証明書のマッチングとアラート
SAN、ワイルドカード、発行者、notBefore、notAfter、証明書のフィンガープリントをパースします。部分文字列の一致よりも、明示的な名前や登録可能ドメインのルールを優先します。アラートには、テナント、ドメイン名、ログ、フィンガープリント、初回観測時刻、証拠へのリンクを含める必要があります。短い時間枠内での同一フィンガープリントは重複排除します。新しい発行者、不自然に短い有効期間、本番ドメインである場合は重要度を引き上げます。
5. ストレージ、マルチテナンシー、復旧
ホットな状態はリレーショナルデータベースまたはキーバリューストアに保持し、生のエントリと証明データはログとツリーサイズでインデックスを付けたオブジェクトストレージに格納します。再生（リプレイ）用として、不変の監査ストリームにイベントを書き込みます。テナントのクエリは、認可されたドメイン名のみを返します。モニターが公開ログに過度な負荷をかけないよう、ログごとのレート制限とグローバルな同時実行数上限を適用します。ローカルの状態が失われた場合は、未検証のカーソルを信頼するのではなく、最後に信頼された STH から復旧し、一貫性証明を使用して追いつきます。
6. 可観測性と障害処理
STH の経過時間、MMD 遅延、確認済みツリーサイズ、取得スループット、証明失敗数、ログの可用性、マッチ率、アラートレイテンシ、重複数を測定します。停止が発生した場合は、最後に信頼された状態を保持してリトライします。スプリットビューや一貫性検証の失敗が発生した場合は、そのログの一致結果の使用を停止し、他のログを使用しつつ、セキュリティイベントを発行します。通知が失敗した場合は、イベントを永続キューに保存し、復旧後にイベント ID に基づいて配信します。
高品質な回答例
まず信頼できる進行（trusted progress）を定義します。ログのカーソルは、正しく署名され単調増加するサイズの STH が一貫性証明を通過した後にのみ進めます。コレクターはそのカーソルとリクエストされた範囲をリトライトークンとともに保存します。初回実行でベースラインを確立し、それ以降はツリーサイズの範囲ごとに読み取ります。すべてのエントリは、フィンガープリント、SAN、ログ位置、生のレスポンス、検証証明を保持します。
マッチャーは SAN を正規化してから、完全一致名、登録可能ドメイン、明示的ワイルドカードに関するテナントルールと比較します。テナント、フィンガープリント、ログをキーとするイベントがキューに入り、通知ワーカーが重複排除、エスカレーション、配信記録を行います。監査ストレージは STH、証明、エントリハッシュ、検証機能のバージョンを保持し、セキュリティエンジニアが後から独自に判定を再生できるようにします。
ログの異常はデータ信頼性の破綻として扱います。不正な署名、ロールバック、一貫性証明の失敗、MMD タイムアウトが発生した場合は、高優先度のプラットフォームイベントを生成します。該当するログは隔離され、以前の信頼状態が保護されます。ログごとのシャーディング、レート制限、バッチ読み取り、オブジェクトストレージによりコストを抑制し、認可されたクエリとテナントごとのクォータにより分離を強制します。STH の鮮度、証明失敗率、検出レイテンシ、アラートの偽陽性率、再生成功率を用いてこの設計を評価します。
よくある間違い
- 1つのログのみをポーリングし、証明書が複数のログに現れる可能性があることを見落とす。
- STH の署名やマークル証明を検証せずに証明書のテキストを読み取る。
- データが検証されていないにもかかわらず、直近のリクエストが成功したという理由だけでカーソルを進めてしまう。
- MMD を証明書の有効期限と混同する、またはログの鮮度に関するアラートをまったく用意しない。
- 部分文字列検索でドメインをマッチングし、類似した名前や無関係な SAN に対する偽陽性を大量に発生させる。
- フィンガープリントをグローバルに重複排除してしまい、複数のログにまたがる出現場所の情報を失う。
- ログに異常が発生している最中に、信頼性の低い「検出されませんでした」という結論を出し続ける。
- 最終的なアラートのみを保持し、生のエントリ、STH、証明データを残さないため、監査が不可能になる。
追加の質問と回答
ログがより小さなツリーサイズを返してきた場合はどうしますか？
カーソルを進めてはなりません。双方の STH とレスポンスを保存し、そのログを隔離して一貫性アラートを発生させます。人間によるレビューを受けるか、新たに信頼できるベースラインが確立された後にのみ再開します。
準リアルタイムポーリングのコストをどのように削減しますか？
ログ単位でシャーディングし、新しい範囲をバッチ化し、ポーリング頻度を動的に調整し、アクセスの少ない証拠データはオブジェクトストレージに配置します。レイテンシ目標を達成するために検証処理を省略してはなりません。
ドメインの所有権はどのように検証しますか？
モニター作成時に、DNS、HTTP、または組織による認可を要求します。認可されたプリンシパルのみがマッチングルールを変更でき、すべての変更は監査ログに記録されます。
モニターはブラウザの CT ポリシーとどのように異なりますか？
モニターは公開ログ内のエントリを検出し、暗号学的に証明します。ブラウザポリシーは、証明書が接続要件を満たしているかどうかを判断します。障害処理と信頼の境界が異なります。
これをどのようにテストしますか？
制御可能なログまたは記録されたレスポンスを使用して、不正な署名、無効な証明、ロールバック、MMD タイムアウト、重複エントリ、通知のリトライを注入します。カーソルが誤って進まないこと、イベントの冪等性が保たれること、監査が正常に再生できることを検証します。