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

「そのOAuth許可、Google Driveを乗っ取らせる気か？」——SaaSシャドーITの危険度をAPIで可視化する

ネットワークの境界が消滅し、我々の管理下を離れてクラウドへデータが散逸する現代。SASEの導入が進む現場でも、依然として止まらないのが「従業員による勝手なSaaS利用」、いわゆるシャドーITだ。

「便利だから」という理由で、個人のGoogleアカウントや認可されていないSaaSに、業務用のMicrosoft 365やGoogle Workspaceを連携させる。これ、セキュリティエンジニアから見れば「自ら鍵を開けて泥棒を招き入れている」のと同じだ。

今日は、CASB（Cloud Access Security Broker）が裏側で一体何を評価し、なぜそのSaaSへのアクセスが「高リスク」と判定されるのか、その核心である「OAuthスコープの権限評価ロジック」を、実務レベルで深掘りしていこう。

—

OAuthスコープ：便利さと引き換えの「全権委任」

OAuth 2.0において、我々が最も警戒すべきはscopeパラメーターだ。ユーザーが「連携」ボタンを押す際、アプリ側から要求されるこの文字列こそが、そのアプリが持つ「破壊力」を決定づける。

例えば、Google WorkspaceのAPIで最も恐ろしいのは、https://www.googleapis.com/auth/driveといった広範なスコープだ。「全ファイルの読み書き」を許可するこの権限は、たとえサードパーティの「お遊びアプリ」であっても、企業の機密情報をすべて外部へ送信できる特権を付与してしまう。

なぜ「シャドーITのリスクスコアリング」が必要なのか

企業が導入するCASBは、APIを通じてテナント内の「どのアプリが、どの権限を、いつ許可されたか」を列挙する。ここで重要なのが、「権限の最小化（Least Privilege）」が守られているかをスコアリングするアルゴリズムだ。

例えば、以下のようなロジックが一般的だ。

スコープの広さ（Breadth）: drive.readonly ならスコアは低めだが、drive（フルアクセス）なら即座に警告レベルを最大化する。
APIの機密性（Sensitivity）: userinfo.email（メールアドレスのみ）と、gmail.modify（メール送信・削除）では、リスクの重みが桁違いだ。
アプリの信頼性（Trust Score）: パブリッシャーが検証済みか、ユーザー数はどれくらいか。

—

実践：Google Cloud APIでOAuthトークンのスコープを調査する

現場で「今、社内からどのアプリがどの権限を持っているか」を調査する際、私はよく gcloud コマンドやPythonの google-api-python-client を活用する。以下は、特定のユーザーに紐づくトークン情報を取得し、スコープを解析するスクリプトの断片だ。

# 必要なライブラリ：google-api-python-client
from googleapiclient.discovery import build

def check_oauth_tokens(user_id):
    # Admin SDK APIを使って、ユーザーの認可済みアプリ一覧を取得
    service = build('admin', 'directory_v1')
    tokens = service.tokens().list(userKey=user_id).execute()

    for token in tokens.get('items', []):
        client_id = token['clientId']
        scopes = token['scopes'] # ここに権限リストが入っている
        
        # 危険なスコープが含まれているか判定する簡易ロジック
        risky_scopes = [s for s in scopes if 'drive' in s or 'gmail' in s]
        
        if risky_scopes:
            print(f"警告: アプリ {client_id} は機密スコープを保持しています: {risky_scopes}")

# 実際には管理者のOAuth認証情報で実行する

このコードを実行すると、驚くほど多くの「かつて試用しただけの怪しいアプリ」が、依然としてdriveへのフルアクセス権を保持している事実に気づくはずだ。

—

API設計者への教訓：OAuthフローの「守り」

もしあなたがSaaS製品を開発する側のエンジニアなら、OAuthスコープの設計には細心の注意を払ってほしい。「開発が楽だから」と、とりあえずfull_accessのような広範なスコープを要求するのは、顧客のセキュリティ担当者から見れば「即座に利用禁止リストへ入れる」という合図に等しい。

セキュアなスコープ設計のTips

1. Read-onlyをデフォルトに: ユーザーが書き込みを必要としないなら、readonlyスコープを分離して定義せよ。
2. Incremental Authorization: 最初から全ての権限を要求するのではなく、特定の機能を使うタイミングで段階的に権限を要求する設計にする。
3. トークンのライフサイクル管理: ユーザーがアプリをアンインストールした際、バックエンド側で即座にOAuthトークンを無効化するプロセスを実装しておくこと。

—

最後に：泥臭い管理こそが最大の防壁

高度なCASBを導入してAPIを監視しても、現場のエンジニアが「OAuthの意味」を理解していなければ、セキュリティはザルだ。

ユーザーが「許可」ボタンを押すその瞬間、彼らは「社内の全データを、見ず知らずのサードパーティのサーバーにアップロードする権利」を渡している——この事実を、我々インフラ屋はもっと口酸っぱく啓蒙していく必要がある。

もし皆さんの環境で「使っているSaaSが把握できない」と嘆いているなら、まずは admin APIを叩いて、許可されているOAuthトークンのリストをCSVで書き出してみることから始めてほしい。そのリストの長さが、そのまま貴社の「隠れたリスクの総量」である。

次回の記事では、このリストを元に「どのSaaSを排除すべきか」を判断する、自動化されたリスク評価フローの構築について解説しようと思う。現場からは以上だ。