記事の概要を読む
SaaS権限棚卸しの進め方を、人・アプリ・共有・鍵に分けて解説。Microsoft Entraのレビュー完了と権限反映の違い、Google WorkspaceのOAuth確認、削除・保留の判断例、証跡の残し方を整理します。情シスが使えるチェックリストと記録テンプレートにもつながります。
この記事の目次 10項目から選ぶ
SaaS権限棚卸しは「ユーザー一覧の確認」だけでは足りない
権限棚卸しはAccess Review（アクセスレビュー）とも呼ばれる。英語画面の「review permissions」は権限の確認・見直しを指し、確認と承認は同じとは限らない。画面の意味から知りたい場合は、用語ページの説明を先に参照してほしい。
SaaS権限棚卸しというと、Microsoft 365、Google Workspace、Slack、GitHub、Notion、Salesforce などの管理画面からユーザー一覧を出し、退職者が残っていないか確認する作業を想像しやすい。もちろん、それは必要だ。しかし実務で事故につながるのは、ユーザー一覧にきれいに載っている権限だけではない。
見落としやすいのは、外部ゲスト、共有リンク、管理者ロール、OAuth同意済みアプリ、APIトークン、Webhook、Bot、SSO対象外の部門契約SaaSだ。これらは正規の認可経路で動くため、攻撃者が「不正アクセスらしい通信」をしなくても、データへ触れ続けられる場合がある。
最初にすべきことは、管理者権限・退職者・所有者不明の連携を抽出し、誰が判断するかを決めることだ。「確認した」「権限変更を実施した」「変更後を検証した」を分けると、一覧を確認しただけで完了にする誤りを避けられる。
対象読者は情シス、CSIRT、開発組織・SaaSの管理者。実作業には、判断と反映を別欄で残せるSaaS権限棚卸しチェックリスト・記録テンプレートを使ってほしい。
この記事は、防御・教育・運用改善を目的にしたSaaS権限棚卸しの進め方を扱う。特定サービスの管理画面手順は変更されるため、画面操作の細部ではなく、どの権限をどの順番で確認するかに焦点を置く。
棚卸しの完了条件：判断・反映・検証を分ける
- 1. 判断する
対象、権限の由来、所有者、業務影響を照合し、維持・削除・期限付き保留を決める。
- 2. 反映する
承認された変更を権限の管理元で実施する。自動反映か手動作業かを記録する。
- 3. 検証する
対象SaaSで残存経路と業務影響を確認し、実施者・確認者・証跡・次回期限を残す。
Microsoft Entra：CompletedとResult appliedは別の状態
Microsoftの完了手順では、レビューの終了と結果の適用を分けている。自動適用を設定していなければ、管理者による結果適用が必要になる。Completedを見ただけで削除済みと判定しない。
また、オンプレミス由来のグループ、入れ子のグループ経由の権限、動的グループなどでは、レビュー結果だけで期待した変更が行われない場合がある。権限の管理元・付与経路を確認し、必要な作業を別チケットにする。Result appliedになっていても、個別ID・共有リンク・APIトークンまで消えたとは限らないため、対象SaaSでの検証を完了条件に加える。
アクセスレビュー機能の利用可否は、対象機能と契約によって異なる。公式概要のライセンス要件を確認し、機能を使えない環境では、同じ判断・反映・検証の記録を手動で残す。
Google Workspace：アプリ名ではなくクライアントID・スコープ・適用範囲を見る
Googleのアプリアクセス制御ガイドを基に、管理権限のある担当者がAPIの制御から、設定済み・アクセスされたアプリと要求スコープを照合する。同名アプリの取り違えを避けるため、クライアントID、利用部門、Googleデータへのアクセス範囲を結び付ける。
「信頼できる（Trusted）」は管理上のアクセス設定であり、安全性を第三者が保証した意味として扱わない。組織部門別の設定がある場合は、その適用範囲も確認する。一律ブロック前に所有者と業務影響を確認し、不審なアクセスがある場合は平時の棚卸しから漏えい疑いの初動対応へ切り替える。
判断例：削除候補を見つけても、未確認を「完了」にしない
以下は説明用の架空例であり、実環境での検証結果ではない。社内の停止承認・証跡保全ルールを優先する。
| 見つかった状態 | 判断と次の作業 | 完了前に残す証跡 |
|---|---|---|
| 委託終了者がグループ経由で顧客資料を閲覧可能 | 契約終了を確認し、権限の管理元で削除を承認・実施。別グループ・直接共有も照合 | 対象ID、付与経路、承認者、変更日時、資料側の権限確認結果 |
| 所有者不明のOAuthアプリに広いファイル権限 | 利用部門・ジョブ・スコープを調査。必要なら期限付き保留、不審利用があれば緊急対応 | 判断理由、調査担当、期限、制限内容、ログの保全先 |
| 正当な連携だが管理者権限が過大 | 必要権限を所有者と合意し、影響を確認して縮小 | 変更前後の権限、業務確認結果、例外と次回レビュー日 |
記録はチェックリストの報告テンプレートへ転記できる。秘密値や利用者情報の原文をこのサイトに入力する必要はない。
まず棚卸し対象を「人・アプリ・共有・鍵」に分ける
棚卸しを始める前に、対象を4つに分ける。人だけを見ると、外部アプリや共有リンクが抜ける。アプリだけを見ると、退職者や委託先の残存権限が抜ける。最初から分けておくと、担当者が変わっても確認漏れを減らしやすい。
| 対象 | 代表例 | 見落とすと起きること |
|---|---|---|
| 人 | 社員、退職者、異動者、委託先、外部ゲスト | 退職後の閲覧、不要な管理権限、外部コラボレーター経由のアクセス |
| アプリ | OAuth連携、Marketplaceアプリ、Bot、Webhook | 正規の同意済み権限でメールやファイルへアクセスされる |
| 共有 | 外部共有リンク、共有ドライブ、チャンネル、公開ページ | 「リンクを知っている全員」への意図しない公開 |
| 鍵 | APIトークン、Deploy Key、アプリパスワード、長期シークレット | 利用者を無効化しても自動化経路が残る |
ここで重要なのは、SaaSごとに同じ名前の権限が存在しない点だ。あるサービスでは「オーナー」、別のサービスでは「管理者」「共同管理者」「請求管理者」「ワークスペース管理者」と呼ばれる。名称をそろえようとするより、何ができる権限かで分類する方が実務に合う。
高リスクから見る：管理者、外部公開、継続アクセス
すべてのSaaSを同じ深さで確認しようとすると、初回の棚卸しは止まる。最初はリスクの大きい順に見る。優先度を決める軸は、管理者権限、機密データ、外部公開、継続アクセス、未利用状態の5つだ。
| 優先軸 | 優先して見る条件 | 理由 |
|---|---|---|
| 管理者権限 | 全社設定、ユーザー追加、監査ログ閲覧、請求設定ができる | 1アカウントの侵害が全体設定変更へ広がる |
| 機密データ | 顧客情報、契約、ソースコード、財務、人事情報を扱う | 漏えい時の影響説明と通知判断が重くなる |
| 外部公開 | 外部ゲスト、公開リンク、共有ワークスペースが多い | 正規機能のままデータ出口になりやすい |
| 継続アクセス | OAuthアプリ、APIトークン、Webhook、Botがある | パスワード変更だけでは止まらない場合がある |
| 未利用状態 | 長期未ログイン、所有者不明、退職者・異動者の残存 | 誰も見ていない権限が攻撃者の足場になる |
たとえば、全社員が使うチャットSaaSより、利用者が少なくても管理者APIと顧客データに触れる営業支援SaaSの方が先に見るべき場合がある。利用者数だけで優先順位を決めないことが大切だ。
OAuth同意と外部アプリは別枠で確認する
Botや自動処理用IDは、人の退職者リストだけでは見落としやすい。サービスアカウントの棚卸し手順では、所有者・利用ジョブ・認証情報・権限を結び付け、未使用と判断する前の確認と安全な廃止の順序を整理している。
SaaS権限棚卸しで特に抜けやすいのが、OAuth同意済みアプリだ。ユーザーが正規の同意画面で許可したアプリは、パスワードを盗まなくても、メール、ファイル、カレンダー、連絡先、管理APIへアクセスできる場合がある。これは OAuth同意フィッシング で整理した通り、MFAだけでは閉じにくい領域だ。
外部アプリを見るときは、アプリ名ではなく、要求権限と利用実態を見る。便利そうなアプリ名でも、必要以上のスコープを要求していればリスクは高い。
| 確認項目 | 見るポイント |
|---|---|
| 発行者 | 検証済み発行者か、社内開発アプリか、所有部門が説明できるか |
| 権限範囲 | メール読取、ファイル読取、管理API、オフラインアクセスが含まれるか |
| 利用者数 | 少数利用なのに広い権限を持っていないか |
| 最終利用 | 長期間使われていないのに権限だけ残っていないか |
| 承認経路 | 管理者同意、申請、期限、棚卸し履歴が残っているか |
ここで雑に「不明アプリは全部削除」とすると、業務自動化や部門の重要ツールを壊すことがある。実務では、所有者不明、高権限、長期未利用の3条件が重なるものから無効化候補にする。継続利用が必要な場合も、所有者、目的、期限、要求権限の妥当性を記録する。
同じ発想はブラウザ拡張機能にも当てはまる。拡張機能はSaaS画面の上で動き、サイトアクセスやタブ情報に触れることがあるため、ブラウザ拡張機能の権限棚卸し もSaaS棚卸しの一部として扱うと確認漏れを減らせる。
退職者・異動者は「アカウント停止後」まで見る
退職者対応は、人事イベントとしては終わっていても、SaaS上では終わっていないことがある。IdPのユーザーが無効化されても、外部コラボレーター、個別契約SaaS、共有アカウント、メール転送、Webhook、APIトークン、GitHub Deploy Key が残る場合がある。
確認対象は、本人アカウントだけではない。退職者が所有していたワークスペース、共有フォルダ、Bot、Webhook、リポジトリ、定期実行ジョブ、請求管理、ドメイン管理も見る。特に開発組織では、個人が作った自動化が本番運用に組み込まれていることがある。
| 対象 | 確認すること |
|---|---|
| SaaSアカウント | 退職者、異動者、長期休職者、委託終了者が残っていないか |
| 所有物 | 共有ドライブ、リポジトリ、Bot、Webhook、ダッシュボードの所有者 |
| 転送・代理 | メール転送、代理送信、共有メールボックス、カレンダー委任 |
| 鍵・トークン | 個人発行のAPIトークン、SSH鍵、Deploy Key、アプリパスワード |
| 外部権限 | 取引先SaaS、外部ワークスペース、ゲスト招待 |
退職処理の実務チェックには 退職者アカウント確認チェックリスト を使うとよい。棚卸しで実際に残存権限が見つかった場合は、退職者アカウントが残っていた時の初動対応 のように、停止、ログ確認、所有物移管、エスカレーションを分けて扱う。棚卸し結果は「削除済み」「移管済み」「期限付き維持」「要確認」に分け、判断理由を残す。あとから説明できない削除や放置を作らないためだ。
初回30日は「完璧な台帳」より「危険な残存権限の除去」を優先する
この日程は平時に棚卸しを立ち上げる例であり、是正期限や製品の公式推奨ではない。退職者の機密データ閲覧や不審なOAuth利用を確認した場合は、翌週の作業を待たず、組織のインシデント対応窓口へ連絡する。
初回の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権限棚卸しチェックリスト で確認項目を作業化し、SaaS外部共有リンクの棚卸し でファイル共有・Slack Connectのデータ出口を確認する。委託先、取引先、開発パートナーの外部ユーザーを重点的に見る場合は、委託先・外部パートナーアカウントの棚卸し を合わせて読むと、所有者、契約期限、権限範囲、ログの記録まで整理しやすい。非常用の高権限アカウントは、緊急用管理者アカウントの棚卸し で、通常管理者、PIM、break glassを分けて確認する。IdP側のMFA除外、場所例外、端末条件は、条件付きアクセス例外の棚卸し で別枠に切り出すと漏れにくい。OAuth同意フィッシング で外部アプリのリスクを理解することも重要だ。基本概念を整理したい場合は、認証と認可の違い と 最小権限の原則 を合わせて確認すると、棚卸し時の判断がぶれにくくなる。
公式情報・参考情報
2026年10月16日追記：Microsoft Entraの結果適用と制約、Google Workspaceのアプリアクセス制御を公式資料と照合した。判断例・三段階の完了条件は編集部の運用整理であり、各製品の実機検証や第三者による監修を意味しない。画面、契約条件、組織の設定は実施時に再確認してほしい。
- Microsoft Learn: Access reviews in Microsoft Entra ID Governance
- Microsoft Learn: Complete an access review
- Google Workspace: Control which apps access Google Workspace data
- CISA: Secure Cloud Business Applications Project
- Google Workspace Admin Help: Security best practices
- Okta: Identity Governance and access certifications
この記事のよくある質問
SaaSの権限棚卸しは、ユーザー一覧を確認すれば十分ですか？
十分ではありません。対象を「人・アプリ・共有・鍵」に分けて確認します。人だけを見ると外部アプリや共有リンクが抜け、アプリだけを見ると退職者や委託先に残った権限が抜けます。
すべてのSaaSを同じ深さで確認すべきですか？
最初はリスクの大きい順に見ます。優先度を決める軸は、管理者権限、機密データ、外部公開、継続アクセス、未利用の状態の5つです。
アクセスレビューが完了すれば、不要な権限も削除されていますか？
完了とは限りません。Microsoft Entraではレビュー完了と結果の適用は別です。自動適用設定や手動適用の結果に加え、グループ経由などの残存経路と対象SaaS側の状態を確認します。
