こんにちは！ネットワークやセキュリティの世界へようこそ。インフラエンジニアの皆さん、そして日々の業務で安全な接続を守る奮闘中の皆さん、いつもお疲れ様です。
突然ですが、皆さんの会社では「ちょっとこの便利なファイル転送ツール、仕事で使ってもいいですか？」「みんなが使っているあのカレンダーアプリ、業務効率化に良さそうだから入れちゃおう！」といった声が、現場から上がっていませんか？
セキュリティのルールが厳しくなる一方で、便利で魅力的なクラウドサービス（SaaS）は世の中にあふれています。管理部門の知らないところで、社員が勝手に業務データをクラウドへアップロードしてしまう。この「こっそり使われている未承認のクラウドサービス」、いわゆる「シャドーIT」の存在テロリズムは、現代の企業セキュリティにおいて最大の悩みの種の一つです。
「ファイアウォールでブロックすればいいのでは？」と思われるかもしれませんが、今のクラウドのほとんどは、安全な通信である HTTPS（鍵付きの通信）を使っています。そのため、中身のデータが丸見えになってしまう昔ながらの方法では、「誰が、どの危険なサービスに、どれだけの機密データを流しているか」を完全に把握するのが難しくなっているのです。
そこで今回の主役が登場します。それが、クラウド利用の守護神である CASB（カスブ：Cloud Access Security Broker） です！
今回は、CASBがどうやって社内のシャドーITを見つけ出し、リスクを評価しているのか、その裏側の仕組みを身近な例えを交えながら一歩ずつ紐解いていきましょう。難解な英語のヘッダーやパケットの細かい構造はひとまず置いておいて、まずはその本質を掴んでみてくださいね！
—
1. 郵便局の「仕分け係」に例えるログ解析の仕組み
CASBがシャドーITを見つける最初のステップは、いわば「会社全体の郵便物の宛先をチェックする、凄腕の仕分け係」の仕事にそっくりです。
社員の皆さんがパソコンやスマホからインターネットの海へ繰り出すとき、会社の出入り口にあるルーターやプロキシサーバーには、膨大な通信の履歴（ログ）が記録されます。
「誰が（社員のIPアドレスやユーザー名）」
「どこへ（アクセス先のドメイン名やIPアドレス）」
「いつ（タイムスタンプ）」
「どれくらいの量の荷物を運んだか（バイト数）」
CASBはこの過去のログをごっそり受け取り、独自の辞書と照らし合わせます。例えば、アクセス先の宛先が dropbox.com や we.tl（Wetransfer） であれば、「お、これはオンラインストレージだな」と仕分けていくわけです。
ここでポイントなのは、CASBは通信の中身（パスワードやファイルそのもの）を盗み見ているわけではなく、「どこ宛ての封筒が、何通、どれくらいの重さでやり取りされたか」という外側のラベル情報を丹念に集めているという点です。
2. 収集したログをどう評価する？CASBのリスクスコア算出アルゴリズム
ただ「あの部署の誰かが、見知らぬクラウドサービスを使っています」と報告されても、セキュリティ担当者は困ってしまいますよね。「それが本当に危険なものなのか？」を判断しなければなりません。
ここでCASBの頭脳である評価アルゴリズムが稼働します。CASBは、世の中にある数万〜数百万種類ものクラウドサービスに対して、あらかじめ「安全性テスト」を行っています。これを身近な例えで言うなら、「レストランの衛生管理チェックシート」のようなものです。
CASBベンダーの調査チームが、各クラウドサービスを次のような基準で採点し、100点満点（あるいは1〜10点などのスケール）のリスクスコアをつけています。
- 法規制とコンプライアンス: そのサービスは、個人情報保護法やGDPR（EUの厳しいデータ保護規則）などの基準を満たしているか？
- セキュリティ対策: データを暗号化して保存しているか？ 多要素認証（MFA）に対応しているか？ 過去に大規模な情報漏洩を起こしていないか？
- 企業の透明性: 運営会社の身元はしっかりしているか？ 利用規約に「ユーザーのデータを広告やAIの学習に勝手に使います」なんて恐ろしいことが書かれていないか？
これらの多角的なチェック項目を総合し、例えば「セキュリティがボロボロで過去に事故を起こしたマイナーなファイル共有サービス」には、高いリスクスコア（危険度「高」）を刻印します。
—
3. 実践！Pythonで疑似的にシャドーITの「リスク評価ロジック」を書いてみよう
「理屈は分かったけれど、裏側ではどんなふうにスコアを計算しているの？」
そんな好奇心旺盛なエンジニアの皆さんのために、CASBの評価アルゴリズムの縮図とも言えるシンプルなPythonスクリプトを用意しました。
実際の企業インフラではクラウド側の巨大なデータベースやAPIと連携しますが、ここでは「プロキシのアクセスログ」と「クラウドサービスの危険度データベース」を突き合わせて、社内のリスクをあぶり出す流れをコードで体験してみましょう！
# ---------------------------------------------------------
# シャドーIT検出・リスク評価のシミュレーションスクリプト
# ---------------------------------------------------------
# 1. クラウドサービスのデータベース（CASBが保持している評価データ）
# スコアが高いほど「危険（リスク大）」と定義します（10段階評価）
cloud_risk_database = {
"storage-free-99.example.com": {"name": "怪しい無料ストレージ", "category": "ストレージ", "risk_score": 9},
"collab-tools-alpha.net": {"name": "社外製チャットツール", "category": "コラボレーション", "risk_score": 6},
"enterprise-m365.microsoft.com": {"name": "Microsoft 365", "category": "オフィス", "risk_score": 1},
"super-safe-drive.com": {"name": "認定済みセキュアクラウド", "category": "ストレージ", "risk_score": 2}
}
# 2. プロキシサーバーからエクスポートした通信ログのサンプル
# （実際には数百万行のCSVやJSONログになります）
proxy_access_logs = [
{"user": "yamada@company.co.jp", "destination": "enterprise-m365.microsoft.com", "bytes_transferred": 5000000},
{"user": "tanaka@company.co.jp", "destination": "storage-free-99.example.com", "bytes_transferred": 120000000}, # 大容量！
{"user": "suzuki@company.co.jp", "destination": "collab-tools-alpha.net", "bytes_transferred": 800000},
]
def evaluate_shadow_it(logs, db):
print("=== シャドーIT リスク評価レポートの生成を開始します ===\n")
for log in logs:
user = log["user"]
dest = log["destination"]
bytes_sent = log["bytes_transferred"]
# ログの宛先がクラウドデータベースに登録されているかチェック
if dest in db:
service_info = db[dest]
score = service_info["risk_score"]
# リスク判定のロジック（例：スコアが7以上、かつ転送量が1MBを超える場合は「要警戒」）
alert_level = "正常（承認済み、または低リスク）"
if score >= 7 and bytes_sent > 1000000:
alert_level = "【警告】重大なシャドーITリスク（高リスクかつ大量データ通信）"
elif score >= 5:
alert_level = "【注意】未承認または中リスクサービスの利用"
print(f"ユーザー: {user}")
print(f" -> 宛先サービス: {service_info['name']} ({dest})")
print(f" -> カテゴリ: {service_info['category']} | リスクスコア: {score}/10")
print(f" -> 通信データ量: {bytes_sent / 1000000:.2f} MB")
print(f" -> 判定結果: {alert_level}")
print("-" * 50)
else:
# データベースにない未知のサービスの処理
print(f"ユーザー: {user} -> 宛先: {dest} は未知のサービスです（調査対象に追加）")
print("-" * 50)
# スクリプトの実行
if __name__ == "__main__":
evaluate_shadow_it(proxy_access_logs, cloud_risk_database)このコードを実行すると、田中さんが「怪しい無料ストレージ」に対して大量のデータをやり取りしているログをキャッチし、自動的に「【警告】重大なシャドーITリスク」としてフラグを立ててくれます。CASBのダッシュボード画面の裏側では、まさにこのようなデータ処理が高速で行われているのです。
—
4. 見える化した後のステップ：ただ禁止するのではなく「誘導」する
CASBがシャドーITを見つけ出し、「このサービスは危険です」と可視化できたとします。さて、セキュリティ担当者としてはここからどう動くべきでしょうか？
昔のセキュリティであれば、「怪しいから全部ファイアウォールで遮断（ブロック）しよう！」となりがちでした。しかし、これでは現場の社員が「仕事がやりづらくなったから、こっそり個人のスマホのテザリングで通信しよう（シャドーITの野良化）」という、さらにタチの悪い行動（迂回路の形成）走る原因になってしまいます。
現代のゼロトラストの思想に基づいたアプローチは、こうです。
1. 可視化と納得のプロセス: 「なぜそのサービスが危険なのか（スコアの根拠）」を現場や管理職に共有する。
2. 代替手段の提示: 「リスクの高い無料ストレージの代わりに、会社が契約している安全な公式クラウド（例: OneDriveやBoxなど）を使いましょう」と優しく導く。
3. 段階的な制御: どうしても業務上必要な例外であれば、CASBやSWG（セキュアWebゲートウェイ）の機能を使って、「データのダウンロードは禁止、閲覧（アップロード）のみ許可」といった細かい制御（ポリシー適用）を行う。
シャドーITの検出とは、ただ社員を取り締まるための「警察の取り締まり」ではありません。「会社全体がどんなクラウドに依存していて、どこにセキュリティの穴があるのか」を知るための、大切な健康診断なのです。
—
まとめ
今回は、CASBにおけるシャドーITの検出と評価アルゴリズムについて、身近な例えやPythonのコードを交えながら優しく解説してきました。
- ログ解析: プロキシやファイアウォールの出入り口の記録から、宛先のドメインを紐解いてクラウド利用をあぶり出す。
- リスク評価スコア: セキュリティ体制や法規制への準拠度を基に、CASBベンダーが算出した「通信の通信簿」を活用する。
- 活用の目的: 単なる禁止ではなく、適切な代替手段の提示や柔軟なアクセス制御へ繋げるための羅針盤とする。
インフラやセキュリティの世界は、一見すると難解な専門用語ばかりで壁が高く感じられるかもしれません。ですが、一歩ずつ構造を分解して身近な仕組みに置き換えていけば、「なるほど、そういうことか！」とスッキリ理解できるようになります。
皆さんのネットワークが、安全で、かつ現場の創造性を邪魔しない素晴らしい環境になることを、心から応援しています！
それではまた、次の技術解説でお会いしましょう。
コメント