シャドーITとは：リスクと、見えない資産の見つけ方

部門が独自に契約した SaaS、開発チームが立てた検証用のサブドメイン、退職者が残したままのクラウドリソース。どれも実在して動いていますが、IT 部門の台帳には載っていません。

シャドー IT と呼ばれるこの状態は、正規の手順を通らずに増えた IT の総称です。

01 / シャドー IT は、動いているのに台帳に載っていない資産

止まっているわけでも、壊れているわけでもありません。業務で使われていて、外からも見えるのに、管理する側の一覧にだけ存在しないという状態です。

図1：動いているのに台帳に無い、という状態

深掘り：規模を数字で語るのは難しい

把握していない資産の割合を示す数字はいくつも出回っていますが、母集団の取り方が調査ごとに違うため、そのまま自社に当てはめられません。自社の割合を知りたければ、外から探索した結果と手元の台帳を突き合わせるのが確実です。

承認を待つより早い、引き継ぎから漏れた、作る速度が管理の速度を上回った、社外で作業する必要があった。悪意から生まれるものではないので、禁止の通達だけでは減りません。

図2：4 つの入り口と、その背景にある事情

深掘り：承認の重さが原因になっている場合

公式に用意された道具が使いにくかったり、申請から利用開始までが長かったりすると、迂回する動機が生まれます。この場合は検出を強めるより、正規の経路を軽くするほうが効きます。検出はあくまで、起きたことを見つける仕組みです。

台帳に無い資産は、守る対象にも、点検の対象にも、報告の対象にもなりません。攻撃を受けたときに、どこまで影響したのかを答えられなくなります。

図3：起きるのは資産の問題ではなく、把握の問題

深掘り：問い合わせに答えられなくなる

顧客や取引先から「弊社のデータをどこに置いていますか」と聞かれたとき、台帳に無いサービスに置かれていれば答えようがありません。実害が出ていなくても、答えられないこと自体が取引の条件に響きます。何がどこにあるかを説明できる状態を保つことが、対策の目的の1つです。

社内に申告を求めても、申告する側が「これは申告するものだ」と思わなければ出てきません。攻撃者と同じ側に立って外から探すと、申告に依存せずに見つかります。

図4：申告に頼る方法と、外から探す方法の違い

深掘り：外から探すと何が出るか

集めるのは、組織のドメインからたどれるサブドメイン・IP アドレス・ポート・使用技術です。仕組みはASM の解説にあります。台帳と突き合わせれば、どれが把握済みでどれが初見かを分けられるはずです。

一度の棚卸しで終わらせると、翌月には同じ状態へ戻ります。新しいシャドー IT は日々生まれるため、探索のほうも継続が要ります。

図5：一度で終わらせず、回し続ける 4 つの流れ

自社のドメインから何が出てくるかは、14日間無料で試せます。

付録：起きることと、打ち手

表1：シャドー IT があると起きること

起きること	中身
データの置き場が分からない	管理していない SaaS に業務データが置かれ、アクセス制御の設定も確かめられない
攻撃面が知らないうちに広がる	パッチが当たっていない古いサーバーや、既定の設定のままのサービスが外に出ている
検知が遅れる	監視の対象に入っていないので、異常が起きても気づく経路が無い
影響範囲を出せない	何がどこにあるか分からないため、事後の調査に時間がかかる

表2：ASM での打ち手

打ち手	中身
外部からの資産探索	ドメインを起点に、サブドメイン・IP・ポート・使用技術を自動で集める
継続的な監視	新たに出てきた資産を、その都度検知する
リスクの自動評価	脆弱性や設定の不備を評価し、TER バンドで順番を付ける
変更の追跡	追加・削除・変更を時系列で残し、未承認の変更に気づけるようにする

見えないものは守れませんが、見えるようにするだけでも守れるわけではありません。見つけたものを順番付けて片付けるところまでが対策です。