許可リスト運用を破綻させない設計 — 粒度・例外・棚卸し

「許可リスト型（ホワイトリスト型）の制御が堅牢なのは分かる。でも運用が回らない」——これは許可リストに対する最も多い、そして最も正当な批判です。実際、設計を誤った許可リストは数年で形骸化します。この記事では、許可リストが破綻する典型パターンを直視したうえで、破綻させないための設計のコツを整理します。

許可リストはこうして破綻する

破綻のパターンは驚くほど似通っています。

• 例外が積もる — 「急ぎなので一時的に許可」が恒久化し、例外がリストの過半を占める
• 誰も消せない — 「この許可、まだ使っているのか？」に誰も答えられず、消して業務が止まるのが怖いので残り続ける
• 申請が形骸化する — 追加申請が増えすぎて審査が「右から左」になり、実質なんでも通る

共通する根本原因は、追加には動機があるが、削除には動機がないことです。追加は業務が止まるので誰かが必ず申請しますが、削除は放置してもその日は何も起きません。放っておけばリストは単調に増え、「許可リスト」という名の全許可に近づいていきます。

設計のコツ① 粒度 — 広すぎる許可は許可リストの意味を失う

ホスト単位（api.example.com）で許可するか、ワイルドカード（*.example.com）で許可するかは、運用の手間と制御の効きのトレードオフです。

ワイルドカードは申請頻度を減らせますが、広げすぎると本末転倒になります。極端な例として、誰でもコンテンツを置ける大手クラウドやCDNのドメイン全体をワイルドカードで許可すると、攻撃者もその上に宛先を用意できるため、許可リストを持っている意味が薄れます。「そのワイルドカードの傘下に、信頼できない主体がコンテンツを置けるか」を粒度判断の基準にするのが実務的です。

設計のコツ② 例外 — 期限と理由をセットで

例外をゼロにはできません。重要なのは例外を特別扱いの構造にすることです。

• 期限付きにする — 「一時的に許可」には必ず失効日を付け、期限が来たら自動で棚卸し対象に上げる
• 理由を記録する — 「誰が・何の業務で・いつまで」をリスト自体に残す。後年「消せない」状態になる最大の原因は、理由が失われることです

例外管理は正直に言って面倒です。しかしこの面倒を引き受けない許可リストは、数年後に「消せない行の集積」になります。

設計のコツ③ 棚卸し — 観測データを根拠に消す

「使われていない許可」を定期的に削除する工程が棚卸しです。ここで効くのが観測データです。各許可エントリが最後に実際の通信でヒットした日時が分かれば、「90日間通信実績のない許可」を機械的に棚卸し候補に挙げられます。勘や記憶ではなく通信の実績を根拠にできるため、「消して大丈夫か」の議論が前へ進みます。

削除に不安があれば、いきなり消すのではなく「もし遮断したら何が止まるか」を先に確認できる運用（would-block 型のレビュー）を挟むと、安全に消し込めます。

最大のコツ — 「リストが小さく保てる場所」に適用する

粒度・例外・棚卸しの設計をどれだけ磨いても、接続先が多様で流動的な環境では許可リストは回りません。一般従業員のWeb閲覧全体に許可リストを適用しようとすれば、申請は無限に発生し、形骸化は時間の問題です。

逆に、接続先が少数で安定しているセグメント——サーバ、自動処理、AIエージェントの専用セグメントなど——では、リストは小さいまま保てて、例外も棚卸しも現実的な量に収まります。全社に許可リストは無理でも、セグメントを絞れば回る。適用範囲の選択こそが、運用設計の最も重要な判断です。

正直な注意点

接続先が安定した環境でも、「少数のドメインで必ず済む」と約束はできません。ツールの追加や仕様変更でリストは必ず動きますし、例外申請の窓口と棚卸しの工数は恒常的に発生します。許可リストは「作って終わり」ではなく、小さく保つ運用コストを払い続ける制御だと理解したうえで採用すべきです。

まとめ

• 許可リスト破綻の根本原因は「追加には動機があるが、削除には動機がない」こと
• 粒度: ワイルドカードの傘下に信頼できない主体が入り込めるなら広すぎる
• 例外: 期限と理由をセットで記録し、失効を棚卸しに接続する
• 棚卸し: 通信の観測データ（最終ヒット日時）を根拠に、定期的に消す
• 最大のコツはリストが小さく保てるセグメントに絞って適用すること。全社一律では回らない

Tate（盾）は、許可リストの根拠になる通信の観測と、遮断前のレビュー（would-block）を運用の中核に据えた設計です。詳しくは可視化・AI解析をご覧ください。