【現場発】シャドーITとサヨナラ！CASBのリスクスコアリングで実現する、SaaS可視化とAPI連携の裏側
こんにちは、ネットワークセキュリティの現場を渡り歩いてきたシニアエンジニアの私だ。
日々、情シスや開発部門からの「この新しいSaaSツール、すぐに業務で使いたいんだけどダメ？」という駆け込み寺のような相談に頭を悩ませている読者も多いことだろう。
リモートワークが当たり前になり、境界防御という「城壁」の内と外の概念が崩れ去った今、企業のデータは社内LANの外、つまりクラウドの海へと無限に拡散している。ここで重要になるのが、ネットワークとセキュリティを統合したSASE（Secure Access Service Edge）、そしてその中でクラウドの利用状況を監視・制御するCASB（Cloud Access Security Broker）だ。
今回は、そのCASBの心臓部とも言える「SaaS利用状況のリスクスコアリング評価基準」に焦点を当てる。外部共有設定の有無や、マルチファクタ認証（MFA）の強制状況といった生々しいパラメーターをどう評価し、いかにして自動化・実務に落とし込むのか。API連携の裏側の通信フローから、Pythonによるスコアリング判定のコードまで、現場の泥臭い知見を交えて徹底的に解説しよう。
—
1. なぜSaaSのリスクスコアリングが必要なのか？
「シャドーIT」という言葉を聞いて胸が痛む管理者は多いはずだ。部門勝手で導入された野良SaaSに、顧客の個人情報やソースコードがアップロードされる。境界防御の時代であれば、プロキシのURLフィルタリングで「ブロック！」と叫べば済んだ話だが、現代のHTTPS暗号化されたWebトラフィックの海では、そうはいかない。
CASBは、プロキシやAPIインライン/アウトオブバンドの連携を通じて、従業員がどのようなクラウドサービスにアクセスし、そこで何をしているかを可視化する。しかし、単に「Slackを使っている」「Notionを使っている」と検知するだけでは意味がない。
- そのNotionのワークスペースは、誰でもアクセス可能な「公開リンク」になっていないか？
- そのSaaSの管理者は、推測可能なパスワードだけでログインし、MFAをバイパスしていないか？
- ベンダーのセキュリティ認証（SOC 2やISO/IEC 27001）はクリアしているか？
こうした膨大な項目の「安全性」を数値化し、経営陣や現場のセキュリティ担当者が一目でリスクを把握できるようにするのが「リスクスコアリング評価基準」の正体だ。
—
2. リスクスコアリングの評価基準とパラメーター設計
CASB製品（Microsoft Defender for Cloud AppsやNetskope、Palo Alto Prisma SASEなど）は、内部のデータベースに世界中の数万種類に及ぶSaaSのカタログ（プロパティ）を保持している。これらは、大きく分けて以下の4つの軸で評価される。
1. コンプライアンスと法規制（Compliance）： SOC 2 Type II、GDPR、HIPAAなどの認証取得状況。
2. データガバナンスと共有範囲（Data Governance）： 外部共有のデフォルト設定、テナント制限の有無、データ暗号化方式。
3. 認証とアクセス制御（Authentication）： MFAの強制、SAML/OIDCによるIdP（Azure AD/Okta等）統合、セッションタイムアウトの制御。
4. 監査・ログ機能（Auditability）： 不正アクセス検知のためのログ出力、SIEM連携の可否。
これらの項目に対し、CASBのエンジンは独自のアルゴリズムで100点満点（または0〜10のスケール）のスコアを割り当てる。例えば、外部への「リンクを知っていれば誰でもアクセス可能（Public Link）」という設定が有効になっているSaaSは、コンプライアンス評価において致命的な減点（リスクスコアの急上昇）を受けることになる。
—
3. API連携によるリアルタイム分析の通信フロー
静的なカタログデータだけでは、組織内で実際にそのSaaSがどう使われているか（動的なリスク）は見えてこない。ここで登場するのがAPI連携（API Connector）だ。
CASBやSaaSの管理API（Microsoft Graph APIやGoogle Workspace Admin SDKなど）がどのように通信し、リスクを評価しているのか、そのシーケンスを見てみよう。
[CASB Engine / SIEM] [SaaS Provider API (e.g., Graph API)]
│ │
│── 1. OAuth 2.0 認証 (Bearer Token) ───>│
│<─ 2. アクセストークン返却 ───────────────│
│ │
│── 3. 監査ログ・外部共有設定の取得要求 ─>│ (GET /v1.0/groups/settings etc.)
│<─ 4. JSONペイロード（設定・共有状況）──│
│ │
│── 5. リスクエンジンのスコアリング処理 ─┤ (ローカルで計算)
│── 6. アラート発報 / 自動修復API実行 ──>│ (PATCH /v1.0/... 外部共有を強制無効化)このフローにおいて、CASBは定期的なポーリングやWebhook（イベント駆動型のプッシュ通知）を利用して、テナント内の設定変更やファイルの外部共有を監視し続ける。
—
4. 実務で使える！PythonによるSaaSリスク評価・スコアリングスクリプト
机上の空論はここまでにして、実際の開発・インフラ運用の現場で役立つコードを見てみよう。
以下は、SaaSから取得したAPIレスポンス（JSON）を想定し、共有範囲やMFAの有効化状況をパースして独自のリスクスコアを算出するPythonスクリプトの実装例だ。
import json
from typing import Dict, Any
def calculate_saas_risk_score(tenant_config: Dict[str, Any]) -> int:
"""
SaaSテナントの構成情報からリスクスコア（0〜100、高いほど高リスク）を算出する関数。
Args:
tenant_config (dict): SaaSのAPIから取得した設定情報の辞書
Returns:
int: 計算されたリスクスコア
"""
base_score = 0
# 1. マルチファクタ認証（MFA）の強制状況チェック
# MFAが強制されていない場合、不正アクセスのリスクが跳ね上がるため重いペナルティ
mfa_enforced = tenant_config.get("mfa_enforced", False)
if not mfa_enforced:
base_score += 40
print("[!] 警告: マルチファクタ認証(MFA)が強制されていません (+40)")
# 2. 外部データ共有のデフォルト設定チェック
# 「リンクを知っていれば誰でもアクセス可能」な設定が許可されているか
external_sharing_allowed = tenant_config.get("external_sharing_allowed", False)
if external_sharing_allowed:
base_score += 30
print("[!] 警告: 外部ユーザーへの直接リンク共有が許可されています (+30)")
# 3. 管理者アカウントの数チェック（特権IDの野良化防止）
# 必要以上にグローバル管理者が多いとリスク増
admin_count = tenant_config.get("admin_count", 0)
if admin_count > 5:
base_score += 15
print(f"[!] 注意: グローバル管理者が基準値(5)を超えています ({admin_count}人) (+15)")
# 4. セッションタイムアウトの有無
session_timeout_min = tenant_config.get("session_timeout_minutes", 480)
if session_timeout_min > 720: # 12時間以上
base_score += 15
print(f"[!] 注意: セッション有効期限が長すぎます ({session_timeout_min}分) (+15)")
# スコアの上限を100に丸める
final_score = min(base_score, 100)
return final_score
# --- 実行テスト用のモックデータとメイン処理 ---
if __name__ == "__main__":
# 危険な設定がてんこ盛りの野良SaaSをシミュレート
mock_saas_response = {
"saas_name": "Shadow-Docs-App",
"mfa_enforced": False,
"external_sharing_allowed": True,
"admin_count": 8,
"session_timeout_minutes": 1440 # 24時間
}
print(f"=== SaaSリスク評価開始: {mock_saas_response['saas_name']} ===")
risk_score = calculate_saas_risk_score(mock_saas_response)
print("-" * 40)
print(f"最終リスクスコア: {risk_score} / 100")
if risk_score >= 70:
print("判定: 【高リスク】即時利用停止または管理者の是正勧告が必要です。")
elif risk_score >= 40:
print("判定: 【中リスク】条件付き許可または追加のモニタリングが必要です。")
else:
print("判定: 【低リスク】安全に利用可能です。")このスクリプトをCI/CDパイプラインや、SOAR（Security Orchestration, Automation, and Response）ツールに組み込むことで、新しいSaaSが申請された瞬間に自動でリスクを査定し、一定以上のスコアであれば自動的にチケット（Jira等）を切ってブロックするといった高度な自動化が実現できる。
—
5. 現場のシニアが教える！導入・運用時のリアルなトラブルシューティング
最後に、実務でCASBやAPI連携によるリスクスコアリングを導入する際、現場で必ずといっていいほど直面する「ハマりどころ」をいくつか共有しておこう。
- APIレートリミット（Throttling）の壁：
大規模な組織で何百ものSaaSや数万人のユーザーをAPI経由でスキャンしようとすると、プロバイダ側のAPI制限（Rate Limit）に引っかかり、データ取得が途中で途切れる。バックオフアルゴリズム（指数関数的バックオフ）を実装したリトライ処理を必ず設計に組み込むこと。
- 「シャドーIT」の定義の揺れ：
情報システム部門が把握していないものはすべてシャドーITとして一律ブロックした結果、現場の業務が完全にマヒしたという笑えない事故が起きる。リスクスコアに応じて、「完全ブロック」「警告表示のみ（Coaching）」「自動承認」とグラデーションを持たせたポリシー設計が肝心だ。
- プライバシーと監査のトレードオフ：
CASBがSaaS内のメッセージやファイルの中身（コンテンツ）までスキャンしすぎると、プライバシー侵害やコンプライアンス上の問題（個人情報保護法や労働法的観点）に抵触する場合がある。メタデータ（共有設定やアクセスログ）を中心としたスコアリングから始め、段階的に深掘りするアプローチが安全だ。
—
まとめ
SaaS利用状況のリスクスコアリング評価基準は、単なる「点数遊び」ではない。激変するクラウドネイティブな環境において、組織のデータを守り抜くための「羅針盤」である。
API連携を駆使してリアルタイムな設定不備を炙り出し、自動化されたスクリプトやCASBのポリシーで即座に是正する。この泥臭くも洗練された仕組みを構築してこそ、真のゼロトラストアーキテクチャが完成する。
さあ、あなたの組織で野放しになっているあのSaaS、一度APIを叩いてリスクスコアを算出してみようではないか。背筋が凍るような数字が飛び出すかもしれないが、それこそがセキュリティエンジニアとしての腕の見せ所だ。
コメント