侵害は一番緩い入口を選ぶ。到達範囲と流入経路で自分の環境を棚卸しした

投稿日 2026/08/25

投稿者 rengotaku

10 分で読めます

参考: 開発環境への不正アクセスから個人情報漏えいに至った事例

まとめ

ある社の開発環境が侵害され、顧客6万人分の個人情報漏えいまで到達した、というニュースを読んだ。入口はトークン1本。出口が顧客データ。落差がおかしい。

認証を N 本の経路で受けているとき、全体の強度はその平均ではない。最小値になる。攻撃側は5つのログイン方法があれば一番脆いものを選ぶだけなので、こちらが4つを厳しくした努力とは関係なく通る。

この形は昔からある。メールで多要素認証を強制しても、レガシーな受信プロトコルの基本認証が生きていれば、そこは ID とパスワードだけで通る。多要素認証は迂回されたのではなく、最初から適用されていなかった。強化した経路と、攻撃者が通る経路が違っただけ。

だから「エンドを強固にした」は、それ単体では進捗として数えられない。数えられるのは最小値が上がったときだけ。

もう一つの軸が到達範囲。秘密情報の危険度は、どこに置いたかではなく、それで何に届くかで決まる。金庫の頑丈さではなく、その鍵で開く扉の数の話。

CI に置いた鍵は「開発者の鍵」に見える。実際にはデプロイのために本番サーバへ SSH する鍵で、そのサーバはアプリの認証情報を持ち、その認証情報は顧客データベースに届く。見え方と実体がずれている。

到達範囲が広い資産に流入経路が5本刺さっていれば、実効的な守りは5本目の一番緩い1本と同じ。棚卸しは2軸でやる。何に届くか、どこから入れるか。

頭の中で数えると漏れるので、設定ファイルから引いた。IaC で全世界に開いている ingress を洗い、CI 設定から資格情報とその到達先をたどり、本流ブランチの保護状況を確認する。

並べたところで目に留まったのが、BI ツールに向かう2本の経路だった。

Web UI は許可プロキシの /32 まで絞ってある。過去にチケットを起票して対応した経路で、設定ファイルには経緯のコメントまで残っている。ちゃんと投資されている。

その同じホストに、SSH でも入れる。許可元は前段のセグメント限定なので、一見まともに見える。ところが前段にいる踏み台のほうが、公開範囲がずっと広かった。手前が緩ければ、奥の限定は限定として働かない。

/32 に絞った経路と、素通しの経路が、同じ資産に対して並んでいた。絞り込みの効果が隣で相殺されている。悪意も手抜きもなくこうなる。強化は「その経路」の担当者が「その経路」を見て実施するので、経路をまたいだ最小値は誰の視界にも入らない。

ついでにセッションマネージャ関連の定義を見たら、中身はパラメータが1件あるだけだった。踏み台が現役なのはそのため。

表1: 選定フロー

手順	判断すること	結果
1	その経路そのものを廃止できるか	廃止できるなら廃止する。踏み台はマネージドなセッション接続へ寄せられる
2	廃止できない場合、認証を多要素に集約できるか	集約できるならそちらへ寄せ、鍵単独の経路を残さない
3	どちらも不可	送信元を既存の許可済みレンジに合わせ、公開範囲だけでも縮める

既定はマネージドなセッション接続への移行。 踏み台という経路が消え、認証がIDプロバイダの多要素に一本化されるので、最小値そのものが上がる。

手順1で落ちるのが IP 絞り込みだけの案。公開範囲は縮むが、経路と認証方式は残る。許可レンジの内側に入られたら効かない。

作業量は自環境での見積もり。小は IaC 数行、中はエージェント配布とIAM設計と運用手順の書き換えまで含む。

表2: 判断の根拠

方式	最弱経路を消せるか	認証を多要素に集約できるか	作業量	前例
送信元IPの絞り込み	縮小のみ。経路は残る	不可。鍵のまま	小	同環境のBIツールで実績あり
マネージド接続へ移行	消せる	可能	中	なし

前例があるぶん、IP 絞り込みは今日でも打てる。移行は設計が要る。両方やるとして、順番は絞り込みが先、移行が本命。応急処置と治療を取り違えないようにだけ気をつける。

読み終えて自分の環境に戻るとき、見るのは強化済みの経路ではなく、まだ誰も見ていない経路のほう。