メインコンテンツまでスキップ

受容リスク

セキュリティレビューで指摘されるであろう挙動のうち、Merlon が承知の上で行っているものと、その理由。これらは欠陥ではなく判断である。ただし貴組織が引き継ぐ判断であるため、発見されるのではなく明記しておく。

各項目は、リスクが何であるか、代替案がなぜより悪かったか、どのような補完統制があるかを述べる。貴組織の評価が異なる結論に至る場合、その項目が何を変更すべきかを示している。

初期セットアップは未認証で実行できる​

リスク。 POST /api/v1/setup は認証なしに最初の管理者アカウントを作成する。

理由。 新規デプロイには認証情報が存在しないため、最初の認証情報の作成を認可できる主体が存在しない。代替案（ビルド時の既定パスワード、イメージ内の共有ブートストラップシークレット、帯域外のトークンファイル）はいずれも、運用者が選んでいない使用可能な認証情報を事前にどこかへ置くことになる。

補完統制。 このルートはちょうど1回だけ成功する。ユーザー行が1件でも存在した時点で 409 を返すため、後から2人目の管理者を発行する目的で再実行することはできない。セットアップが完了するまで GET /healthz/ready は unhealthy を報告し、この期間を隠さず可視化する。

プローブが開示するのはこのセットアップ状態だけである。/healthz、/healthz/live、/healthz/ready は必然的に未認証である（オーケストレーターは、プロセスが資格情報を保持できる状態かを確認するための資格情報を持ちえない）。そのため、これらはどの依存先が失敗しているかのみを示し（{"postgres":"error"}）、それ以上は返さない。依存先のエラー本文はサーバーログに記録する。PostgreSQL の接続エラーはデータベースのホスト・ポート・ユーザー・データベース名を含み、エンジンのエラーは設定ファイルのパスを含むためである。

利用者が行うべきこと。 セットアップを完了する前に、新規インスタンスを信頼できないネットワークへ公開しないこと。露出期間は初回起動から最初の管理者作成までであり、それを短く保つのは利用者の責任である。

アラートエンジンは検知側に倒れる​

リスク。 判断が曖昧な状況や機能低下時には、沈黙ではなくアラートを生成する。これは誤検知率とレビュー負荷を上げる。

理由。 逆の失敗モードは検知漏れであり、それは検査官が発見するまで正常動作と区別がつかない。誤検知はアナリストの時間を消費するが、検知漏れは本来行われるべきだった届出を失わせる。

補完統制。 アラート抑止、二重統制付きのホワイトリスト、候補ルールセットに対するバックテストが存在し、検知力を弱めるのではなく意図的に調整できるようになっている。

スクリーニングは古いリストで継続する​

リスク。 制裁リストや PEP リストの取得元へ到達できない場合、Merlon は最後に取得に成功したリストで照合を継続する。したがってスクリーニング判断が数時間から数日古いデータに基づいて行われうる。

理由。 代替案は、fail-open（何とも照合せず、すべての顧客を素通しさせる）か、fail-close（スクリーニングを完全に停止し、一時的なネットワークエラーで顧客受入を止める）である。

補完統制。 連続失敗はリストごとにカウントされ、3回連続でその状態にフラグが立つ。インポートジョブは needs_operational_alert=true を含む構造化エラーログを出力し、ダッシュボードのスクリーニング鮮度データにも同じフラグが載り、merlon_screening_list_stale_days ゲージが各リストの経過日数を /metrics で公開する。Merlon 自身が誰かに通知することはなく、組み込みの通知機構は存在しない。インポート状態は引き続き照会可能であり、任意の判断の背後にあるリストの鮮度を復元できる。

利用者が行うべきこと。 これらのフラグを人に届くよう自ら結線すること。すなわち、ログのフィールド、または merlon_screening_list_stale_days を、自組織の監視基盤でアラート対象にする。何かがそれを読む人へ届けて初めて、この統制は機能する。

マイグレーションは前方向のみ​

リスク。 down マイグレーションが存在しない。スキーマを変更したリリースをロールバックするにはバックアップからの復元が必要であり、バックアップ以降に書き込まれたデータは失われる。

理由。 データ変換を逆転させる down マイグレーションは、失われるものがあるか正しくないかのいずれかであり、どちらであるかを知る最悪のタイミングがインシデントの最中である。復元は遅いが、その性質は事前に把握できる。

補完統制。 マイグレーションランナーはマイグレーションごとにチェックサムを記録し、適用後にファイルが変更されていた場合は処理を拒否する。2回適用しても no-op である。リリースチェックリストは、文書化された復元ではなくリハーサル済みの復元を要求する。

利用者が行うべきこと。 復元をテストすること。テストされていないバックアップはロールバック計画ではない。

暗号鍵リングの紛失は回復不能​

リスク。 直接的な PII 顧客属性は MERLON_ENCRYPTION_KEY_RING の鍵によって保存時に暗号化され、鍵はデータベース外にある。対応する鍵を伴わないデータベースバックアップは恒久的に読み取れない。

理由。 保護対象のデータと同じ場所に保管された鍵は、そのデータを保護しない。その帰結として、鍵の保管が運用上の責任になる。

補完統制。 鍵ローテーションはオンラインかつバッチで再暗号化を行うため、ダウンタイムも一斉切り替えも必要としない。

利用者が行うべきこと。 鍵リングをデータベースとは別にバックアップし、退避した鍵をその鍵で書かれたバックアップの保持期間以上保持し、復元演習に暗号化データの読み出し確認を含めること。

プラグイン／拡張のサンドボックスは無い​

リスク。 Merlon 内部で第三者のコードを実行する手段が無い。プラグイン機構であれば実現できた連携は、REST API に対する外部サービスとして構築する必要がある。

理由。 インプロセスの第三者コードは、規制記録を生成するトランザクション境界の内側で動作することになる。拡張は設定（ルール、YAML アダプター、webhook）によって行い、これは任意コードにはない監査可能性を持つ。

補完統制。 REST API、発行可能な API キー、設定可能な REST アダプター、Dead Letter Queue を備えた外向き webhook。

デモ構成は認証が無効​

リスク。 docker-compose.demo.yml は MERLON_AUTH_ENABLED=false かつシード済みの合成データで動作する。

理由。 セットアップの手間なしに評価できるようにするためである。

補完統制。 127.0.0.1 にのみバインドし、データセットは完全に合成であり、MERLON_SEED=true は MERLON_ENV=production では明示的に拒否される。MERLON_AUTH_ENABLED=false も同様に本番では拒否される。

利用者が行うべきこと。 この compose ファイルを実データへ向けないこと、到達可能なホストで実行しないこと。