シャドーITという名の「見えない牙城」を崩せ――CASBによる可視化とリスク評価の最前線
ネットワークエンジニアとして現場に立っていると、どれほど強固な境界防御を築いても、社員の「利便性」という名の欲求は、常に想定外の抜け穴を探し出すものだと痛感させられます。社内の人間が情シスに無断で導入するSaaS、いわゆる「シャドーIT」です。
「Dropboxは禁止しているのに、なぜかトラフィックが流れている」「個人のGoogleドライブで機密資料を同期している」……こうした事態を放置することは、データ漏洩の最大の温床となります。今回は、SASEの要であり、この見えない境界を可視化する「CASB（Cloud Access Security Broker）」の裏側、特にシャドーIT検出のロジックと実務的な解析アプローチについて深掘りしていきましょう。
—
1. シャドーITはどこで「バレる」のか？――通信フローの勘所
CASBがシャドーITを検知する基本は、プロキシやファイアウォールから吸い上げたログの解析にあります。ネットワークエンジニアにとって馴染み深い、HTTP/HTTPSのハンドシェイクやヘッダー情報をどう活用するか、そのシーケンスを整理しましょう。
通信フローと検知ポイント
通常、従業員の端末がSaaSにアクセスする際、以下のステップを踏みます。
1. DNS問い合わせ: 端末が api.dropbox.com などのドメインを解決する。
2. TLSハンドシェイク: プロキシ経由、あるいは直接SaaSのIPへ接続を試みる。
3. HTTPリクエスト: Host ヘッダーや User-Agent が送出される。
CASBは、プロキシから転送されたログ（W3C形式やJSON形式）を突き合わせ、以下のアルゴリズムで「これは未承認か？」を判断します。
- URL/FQDNの照合: CASBベンダーが保有するクラウドサービスデータベース（約3万〜5万件のサービスが登録されています）と、ログ上のドメインをマッチングさせる。
- SNI（Server Name Indication）の解析: TLSの
ClientHelloパケットに含まれるSNI情報をキャプチャすることで、暗号化されていても宛先ドメインを特定します。
—
2. リスクスコア算出のアルゴリズム――「何を持って危険とみなすか」
CASBのダッシュボードに表示される「リスクスコア（1〜100）」は、単なる目安ではありません。実務的には、以下のパラメーターの加重平均で導き出されることが多いです。
- コンプライアンス適合性: ISO27001、SOC2、GDPRなどの認証を取得しているか。
- データ保護機能: 保存時の暗号化、DLP（データ漏洩防止）機能の有無。
- アクセス制御: MFA（多要素認証）やSSO（SAML/OIDC）への対応状況。
- 運用実績: サービスの運営企業の資本力や信頼性。
これらを JSON で定義し、独自の判定エンジンに食わせるイメージを持つと、実務でのチューニングが非常に楽になります。
—
3. 実践：ログ解析とAPI連携による「自動検知」
現場では、ベンダー提供のダッシュボードを見るだけでは足りないことがあります。「特定の部門からの特定のSaaSへのアクセスが急増したときだけアラートを出したい」といった要件ですね。
ここでは、Pythonを用いて、クラウド上のログ基盤から不審なSaaSアクセスを抽出する簡単な例を紹介します。
import requests
import json
# ログ基盤（SIEM等）からログをフェッチする想定
def fetch_proxy_logs(api_key, time_range):
headers = {"Authorization": f"Bearer {api_key}"}
# プロキシログのフィルタリングAPIを叩く
response = requests.get("https://siem.internal.corp/api/v1/logs",
headers=headers,
params={"range": time_range})
return response.json()
def evaluate_shadow_it(logs):
# 承認済みサービスリスト（ホワイトリスト）
approved_services = ["office365.com", "slack.com", "zoom.us"]
for entry in logs:
# FQDNがホワイトリストにない場合を「シャドーIT」と判定
if entry['fqdn'] not in approved_services:
print(f"[ALERT] 未承認サービスを検出: {entry['fqdn']}")
print(f"ユーザー: {entry['user']}, 通信量: {entry['bytes']} bytes")
# 実行
logs = fetch_proxy_logs("YOUR_API_KEY", "1h")
evaluate_shadow_it(logs)Tips: curl での即時確認
調査中、疑わしいエンドポイントがどんなヘッダーを要求してくるかを知りたいときは、シンプルに curl でプローブを投げます。
# 宛先SaaSのレスポンスヘッダーを確認し、どのサービスかを特定する
curl -Iv https://www.example-unknown-saas.com \
-H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)" \
--connect-timeout 5—
4. 現場のシニアとしてのアドバイス：運用の泥臭い現実
技術的に検知することは難しくありません。本当に難しいのは、「検知した後の運用」です。
1. いきなりブロックしない: 業務で不可欠なツールを遮断すると、情シスへのクレームの嵐が吹き荒れます。まずは「警告（Warn）モード」でログを収集し、利用実態を部門長と共有するところから始めましょう。
2. ホワイトリストの更新を怠らない: SaaSの世界は日進月歩です。サービス名が変わったり、CDNの構成が変わってIPが頻繁に変わることは日常茶飯事。CASBの「サービスカタログ」の更新頻度を監視する運用フローを組み込んでください。
3. 「なぜ使うのか」をヒアリングする: シャドーITの多くは「既存のツールが使いにくいから」という正当な不満から生まれます。シャドーITの可視化は、社内ツールを見直す絶好のチャンスでもあるのです。
ゼロトラストとは、単に製品を導入することではなく、「何が起きているか」を解像度高く把握し、それに対するポリシーを柔軟かつ迅速に適用し続けるプロセスそのものです。
皆さんのネットワークが、明日も安全であることを願っています。何かトラブルがあれば、またいつでもログを片手に議論しましょう。
コメント