SaaS権限棚卸しを、管理者ロール、退職者アカウント、OAuth同意、外部共有、APIトークンの観点で整理。初回30日の進め方と優先順位を解説する。
SaaS権限棚卸しは「ユーザー一覧の確認」だけでは足りない
SaaS権限棚卸しというと、Microsoft 365、Google Workspace、Slack、GitHub、Notion、Salesforce などの管理画面からユーザー一覧を出し、退職者が残っていないか確認する作業を想像しやすい。もちろん、それは必要だ。しかし実務で事故につながるのは、ユーザー一覧にきれいに載っている権限だけではない。
見落としやすいのは、外部ゲスト、共有リンク、管理者ロール、OAuth同意済みアプリ、APIトークン、Webhook、Bot、SSO対象外の部門契約SaaSだ。これらは正規の認可経路で動くため、攻撃者が「不正アクセスらしい通信」をしなくても、データへ触れ続けられる場合がある。
この記事では、SaaS権限棚卸しを初めて設計する情シス、CSIRT、開発組織の管理者向けに、確認順序、優先順位、初回30日の進め方を整理する。実際の作業表として使う場合は、SaaS権限棚卸しチェックリスト と併用してほしい。
この記事は、防御・教育・運用改善を目的にしたSaaS権限棚卸しの進め方を扱う。特定サービスの管理画面手順は変更されるため、画面操作の細部ではなく、どの権限をどの順番で確認するかに焦点を置く。
まず棚卸し対象を「人・アプリ・共有・鍵」に分ける
棚卸しを始める前に、対象を4つに分ける。人だけを見ると、外部アプリや共有リンクが抜ける。アプリだけを見ると、退職者や委託先の残存権限が抜ける。最初から分けておくと、担当者が変わっても確認漏れを減らしやすい。
| 対象 | 代表例 | 見落とすと起きること |
|---|---|---|
| 人 | 社員、退職者、異動者、委託先、外部ゲスト | 退職後の閲覧、不要な管理権限、外部コラボレーター経由のアクセス |
| アプリ | OAuth連携、Marketplaceアプリ、Bot、Webhook | 正規の同意済み権限でメールやファイルへアクセスされる |
| 共有 | 外部共有リンク、共有ドライブ、チャンネル、公開ページ | 「リンクを知っている全員」への意図しない公開 |
| 鍵 | APIトークン、Deploy Key、アプリパスワード、長期シークレット | 利用者を無効化しても自動化経路が残る |
ここで重要なのは、SaaSごとに同じ名前の権限が存在しない点だ。あるサービスでは「オーナー」、別のサービスでは「管理者」「共同管理者」「請求管理者」「ワークスペース管理者」と呼ばれる。名称をそろえようとするより、何ができる権限かで分類する方が実務に合う。
高リスクから見る：管理者、外部公開、継続アクセス
すべてのSaaSを同じ深さで確認しようとすると、初回の棚卸しは止まる。最初はリスクの大きい順に見る。優先度を決める軸は、管理者権限、機密データ、外部公開、継続アクセス、未利用状態の5つだ。
| 優先軸 | 優先して見る条件 | 理由 |
|---|---|---|
| 管理者権限 | 全社設定、ユーザー追加、監査ログ閲覧、請求設定ができる | 1アカウントの侵害が全体設定変更へ広がる |
| 機密データ | 顧客情報、契約、ソースコード、財務、人事情報を扱う | 漏えい時の影響説明と通知判断が重くなる |
| 外部公開 | 外部ゲスト、公開リンク、共有ワークスペースが多い | 正規機能のままデータ出口になりやすい |
| 継続アクセス | OAuthアプリ、APIトークン、Webhook、Botがある | パスワード変更だけでは止まらない場合がある |
| 未利用状態 | 長期未ログイン、所有者不明、退職者・異動者の残存 | 誰も見ていない権限が攻撃者の足場になる |
たとえば、全社員が使うチャットSaaSより、利用者が少なくても管理者APIと顧客データに触れる営業支援SaaSの方が先に見るべき場合がある。利用者数だけで優先順位を決めないことが大切だ。
IdPでアカウントを無効化しても、SSO対象外の個別ID、外部ゲスト、OAuth同意、APIトークン、共有リンクは別管理になっていることがある。SaaS棚卸しでは「ログインできるか」だけでなく「データへ触れる経路が残っていないか」を見る。
OAuth同意と外部アプリは別枠で確認する
SaaS権限棚卸しで特に抜けやすいのが、OAuth同意済みアプリだ。ユーザーが正規の同意画面で許可したアプリは、パスワードを盗まなくても、メール、ファイル、カレンダー、連絡先、管理APIへアクセスできる場合がある。これは OAuth同意フィッシング で整理した通り、MFAだけでは閉じにくい領域だ。
外部アプリを見るときは、アプリ名ではなく、要求権限と利用実態を見る。便利そうなアプリ名でも、必要以上のスコープを要求していればリスクは高い。
| 確認項目 | 見るポイント |
|---|---|
| 発行者 | 検証済み発行者か、社内開発アプリか、所有部門が説明できるか |
| 権限範囲 | メール読取、ファイル読取、管理API、オフラインアクセスが含まれるか |
| 利用者数 | 少数利用なのに広い権限を持っていないか |
| 最終利用 | 長期間使われていないのに権限だけ残っていないか |
| 承認経路 | 管理者同意、申請、期限、棚卸し履歴が残っているか |
ここで雑に「不明アプリは全部削除」とすると、業務自動化や部門の重要ツールを壊すことがある。実務では、所有者不明、高権限、長期未利用の3条件が重なるものから無効化候補にする。継続利用が必要な場合も、所有者、目的、期限、要求権限の妥当性を記録する。
退職者・異動者は「アカウント停止後」まで見る
退職者対応は、人事イベントとしては終わっていても、SaaS上では終わっていないことがある。IdPのユーザーが無効化されても、外部コラボレーター、個別契約SaaS、共有アカウント、メール転送、Webhook、APIトークン、GitHub Deploy Key が残る場合がある。
確認対象は、本人アカウントだけではない。退職者が所有していたワークスペース、共有フォルダ、Bot、Webhook、リポジトリ、定期実行ジョブ、請求管理、ドメイン管理も見る。特に開発組織では、個人が作った自動化が本番運用に組み込まれていることがある。
| 対象 | 確認すること |
|---|---|
| SaaSアカウント | 退職者、異動者、長期休職者、委託終了者が残っていないか |
| 所有物 | 共有ドライブ、リポジトリ、Bot、Webhook、ダッシュボードの所有者 |
| 転送・代理 | メール転送、代理送信、共有メールボックス、カレンダー委任 |
| 鍵・トークン | 個人発行のAPIトークン、SSH鍵、Deploy Key、アプリパスワード |
| 外部権限 | 取引先SaaS、外部ワークスペース、ゲスト招待 |
退職処理の実務チェックには 退職者アカウント確認チェックリスト を使うとよい。棚卸しで見つかった残存権限は「削除済み」「移管済み」「期限付き維持」「要確認」に分け、判断理由を残す。あとから説明できない削除や放置を作らないためだ。
初回30日は「完璧な台帳」より「危険な残存権限の除去」を優先する
初回のSaaS権限棚卸しでありがちな失敗は、台帳を完璧に作ろうとして、実際の権限削除が後回しになることだ。最初の目的は、きれいな管理表ではなく、説明できない高リスク権限を減らすことに置く。
| 期間 | やること | 完了条件 |
|---|---|---|
| 1週目 | 主要SaaSを10〜20件に絞り、管理者・所有者・データ種別を洗い出す | 誰が管理しているか分からないSaaSを可視化する |
| 2週目 | 管理者ロール、外部ゲスト、OAuthアプリ、共有リンクを抽出する | 高リスク権限の候補リストを作る |
| 3週目 | 所有部門へ確認し、削除・維持・期限付き保留を判断する | 不明な高権限アプリと退職者権限を減らす |
| 4週目 | 申請、承認、棚卸し周期、例外期限を決める | 次回も同じ観点で確認できる状態にする |
この30日計画では、全SaaSを網羅できなくてもよい。むしろ、顧客データ、ソースコード、メール、ファイル共有、管理者APIへ触れるSaaSに集中する方が成果が出やすい。ゼロトラストの考え方と同じで、最初から全員を信頼するのではなく、重要なアクセスほど継続的に検証する。
関連する設計思想は ゼロトラストアーキテクチャ でも扱っている。SaaS棚卸しは、抽象的なゼロトラストを「誰が、何に、どの権限で、いつまでアクセスできるか」という運用に落とす作業だ。
よくある失敗：CSVを出して終わる、削除だけ急ぐ、例外を放置する
SaaS権限棚卸しは、手順そのものより運用の継続が難しい。よくある失敗は3つある。
1つ目は、CSVを出して満足することだ。ユーザー一覧を出力しても、外部アプリ、共有リンク、APIトークン、Webhook、監査ログを見なければ、実際のアクセス経路は残る。CSVは材料であって、棚卸しの完了条件ではない。
2つ目は、削除だけを急ぐことだ。所有者確認なしに外部アプリやBotを止めると、請求、通知、監査、営業活動、デプロイが止まる場合がある。危険度が高いものは止めるべきだが、業務影響を判断できる情報も同時に集める。
3つ目は、例外を期限なしで残すことだ。「このSaaSだけはSSO非対応」「この委託先だけは共有アカウント」「このBotだけは管理者権限」という例外は、発生自体よりも期限がないことが問題になる。例外には所有者、理由、期限、次回レビュー日を必ず付ける。
スプレッドシートだけで管理すると、誰がいつ判断したかが曖昧になりやすい。削除、維持、期限付き保留、追加調査をチケット化し、証跡を残すと次回レビューが楽になる。
まとめ：SaaS権限は「便利な連携」ではなくデータ出口として見る
SaaS権限棚卸しは、ユーザー一覧を眺める作業ではない。退職者、外部ゲスト、OAuth同意、共有リンク、APIトークン、管理者ロールを分けて確認し、説明できない高リスク権限から減らしていく運用だ。
最初から完璧な台帳を作る必要はない。まずは主要SaaSを絞り、管理者権限、外部公開、継続アクセス、長期未利用を優先して見る。30日で危険な残存権限を減らし、その後に申請・承認・期限付き例外・四半期レビューへつなげる。
次に実務へ落とすなら、SaaS権限棚卸しチェックリスト で確認項目を作業化し、OAuth同意フィッシング で外部アプリのリスクを理解する。基本概念を整理したい場合は、認証と認可の違い と 最小権限の原則 を合わせて確認すると、棚卸し時の判断がぶれにくくなる。
