【入門編】 SaaS固有のシャドーITリスクスコアリングアルゴリズム:APIアクセス権限の危険度評価 – ゼロトラスト&エンタープライズセキュリティ実践ガイド

みなさん、こんにちは!日々のネットワーク運用やセキュリティ対策、本当にお疲れ様です。技術メディアで主筆ライターをしている私ですが、現場のエンジニアやインフラの世界へ一歩を踏み出したばかりの方から、よくこんな切実な相談を受けるんです。

「うちの会社、知らぬ間に社員が勝手に便利なSaaS(クラウドサービス)を使い始めていて……。データが外に漏れてないか不安で夜も眠れません!」

……わかります。その不安、痛いほどよく分かりますよね。昔なら、会社のネットワークの入り口(境界)に分厚いファイアウォールをドンと置いておけば、社内の安全は守られていました。でも、リモートワークが当たり前になり、みんながカフェや自宅から直接クラウドへアクセスする現代では、その「お城の壁」はもう役に立ちません。

そこで登場するのが SASE(Secure Access Service Edge) や CASB(Cloud Access Security Broker) といった次世代のセキュリティ概念です。今回はその中から、特に現場の頭を悩ませる「SaaS固有のシャドーITリスクスコアリング:APIアクセス権限の危険度評価」について、難しい専門用語の裏側にある「リアルな仕組み」を、身近な例えを交えながら一緒に紐解いていきましょう!

一歩ずつ丁寧に解説していきますので、リラックスしてついて来てくださいね。

—

1. シャドーITって、なぜそんなに怖いの?(現実世界に例えてみよう)

会社に内緒で社員が便利なスケジュール管理アプリやファイル共有ツールを入れること、いわゆる「シャドーIT」ですね。業務効率が上がるならいいじゃないか、と思うかもしれません。

でも、ちょっと待ってください。ここで少し、現実世界の「合鍵」に例えて考えてみましょう。

あなたは自分の家に、信頼できるハウスキーパーさんを雇うことにしました。そのとき、玄関の鍵をすべて渡しますよね。「この人は掃除や料理をしてくれる人だから大丈夫」という信頼(トラスト)の元に鍵を渡します。

SaaSの世界でもこれと全く同じことが起きています。社員が新しいアプリを使い始めるとき、よくこんな画面を見たことありませんか?

> 「〇〇アプリがあなたのGoogle/Microsoftアカウントへのアクセスを求えています」
> [許可する]・[キャンセル]

ここで気軽に [許可する] をポチッと押してしまうと、それは「私の家の合鍵を、素性のよく分からない業者にポーンと渡してしまう行為」に等しいのです。この「合鍵」の正体が、OAuth(オーオース)という仕組みでやり取りされる「APIアクセス権限(スコープ)」なんですね。

—

2. OAuthとAPIスコープの正体:アプリに渡す「合鍵の範囲」

APIアクセス権限、あるいは「スコープ」と呼ばれるものは、いわば「デジタルな合鍵につけられた行動制限カード」のようなものです。

例えば、あるちょっと怪しいカレンダーアプリが、あなたの社内アカウントに対して次のような権限を要求してきたとします。

  • user:read (あなたのプロフィールを見るだけ)
  • files:read_write (社内クラウドにあるすべてのファイルを読む・書き換える・削除する)

……どうですか? カレンダーの予定を表示するだけなのに、「すべてのファイルを自由に書き換えられる権限」なんて絶対に必要ないはずですよね。しかし、利用者はそんなこと気にせず、画面の勢いで [許可する] を押しがちです。

CASBやSASEのソリューションは、この「アプリが欲しがっている合鍵の範囲(スコープ)」を裏側でくまなくスキャンし、「このアプリ、必要以上に危険な権限を持っていないか?」を自動で点数化(リスクスコアリング)してくれているのです。

—

3. リスクスコアリングの裏側:どうやって危険度を評価しているの?

では、CASBなどのシステムは、どのようにしてその危険度をはじき出しているのでしょうか?

基本の考え方はとてもシンプルです。企業にとって「最も奪われたら困るもの(機密データ)」にどれだけ簡単にアクセスできるかを、一定のルールに基づいて計算しています。

危険度評価の主なチェックポイント

1. データの読み書き権限の広さ:「読むだけ」なのか「書き換え・削除」までできるのか。
2. アクセスのスコープ(範囲):「自分個人のフォルダだけ」か「会社全体の全社共有フォルダ」か。
3. アプリの信頼性:開発元はしっかりした企業か、野良の開発者が作った個人アプリか。

これらを組み合わせて、例えば「100点満点中、85点の高リスク!」といった具合に判定を下すわけです。

—

4. 【実践】API権限のリスクをPythonでシミュレーションしてみよう!

百聞は一見に如かず。CASBの裏側で動いているリスクスコアリングのアルゴリズムを、すごくシンプルなPythonのコードで覗いてみましょう。

実務の開発やセキュリティツールのカスタムでもよく使われる考え方ですので、ぜひ参考にしてみてくださいね。

# -*- coding: utf-8 -*-
"""
SaaSアプリのOAuthスコープに基づくリスクスコアリングのシミュレーション
インフラ・セキュリティ初学者向け解説スクリプト
"""

# アプリが要求してきたAPIスコープ(合鍵のリスト)のサンプル
# 例:社員が勝手に入れた怪しい便利ツール
app_name = "超便利PDFコンバーター"
requested_scopes = [
    "user:profile:read",       # 自分のプロフィールを読む(低リスク)
    "drive:files:read",        # ドキュメントを読む(中リスク)
    "drive:files:write",       # ドキュメントを書き換える・削除する(高リスク!)
    "admin:users:manage"       # 全社員のアカウントを管理する(超ウルトラ危険!)
]

def calculate_saas_risk_score(scopes):
    """
    渡されたスコープのリストから、リスクスコア(0〜100点)を計算する関数
    """
    base_score = 0
    
    # スコープごとの危険度(重み付け)を定義
    risk_weights = {
        "user:profile:read": 5,
        "drive:files:read": 20,
        "drive:files:write": 40,
        "admin:users:manage": 50
    }
    
    print(f"--- 診断開始: {app_name} ---")
    
    # 保持しているスコープをひとつずつチェック
    for scope in scopes:
        if scope in risk_weights:
            score = risk_weights[scope]
            base_score += score
            print(f"[検出] スコープ '{scope}' -> 危険度加算: +{score}点")
        else:
            # 未知のスコープに対するデフォルトの加算値
            base_score += 10
            print(f"[警告] 未知のスコープ '{scope}' -> 危険度加算: +10点")
            
    # スコアが100点を超えないように調整
    final_score = min(base_score, 100)
    return final_score

# リスクスコアの算出実行
total_risk_score = calculate_saas_risk_score(requested_scopes)

print("\n================================")
print(f"【判定結果】{app_name} のリスクスコア: {total_risk_score} / 100点")

if total_risk_score >= 70:
    print("判定: 【高リスク (High)】 -> 即座にアクセスをブロックし、管理者に通知を推奨します!")
elif total_risk_score >= 40:
    print("判定: 【中リスク (Medium)】 -> 利用者に正当な業務用途かヒアリングが必要です。")
else:
    print("判定: 【低リスク (Low)】 -> 比較的安全に利用可能です。")
print("================================")

このコードのように、システムは一つひとつの「権限(スコープ)」に点数をつけ、合計点が一定を超えた瞬間にアラートを鳴らしたり、自動でAPIトークンを無効化(リヴォーク)したりしているのです。

—

5. ゼロトラストな世界へ向けて:私たちが現場でできること

ここまで、SaaS固有のシャドーITリスクと、APIアクセス権限の評価アルゴリズムについて見てきました。「何も信頼せず、すべてを検証する(Zero Trust)」というゼロトラストの思想において、シャドーITで見えないところで結ばれたAPI連携ほど怖いものはありません。

今日から現場で実践できるアクションとしては、以下の3つが挙げられます。

1. CASBやSSPM(SaaS Security Posture Management)の導入検討:社内のクラウドサービスで「誰がどのアプリに、どんな権限を渡しているか」を可視化する。
2. 過剰な権限を持つアプリの定期棚卸し:業務で使わなくなった古いアプリのOAuth連携は、こまめに解除(取り消し)する。
3. ユーザー教育の徹底:アプリを連携する際、「お気楽に『許可する』を押さないこと」の重要性を社内に周知する。

難しく見えるセキュリティの仕組みも、身近な「合鍵」の例えに置き換えてみると、スッと理解できるようになりますよね。

今日の知識が、みなさんの日々のネットワーク運用や、安全なクラウド環境づくりの小さなヒントになればとても嬉しいです。それでは、また次回の技術解説でお会いしましょう!

コメント

タイトルとURLをコピーしました