メインコンテンツへスキップ
委託先・外部パートナーアカウントの棚卸し ─ SaaS・GitHub・Slackでまず確認すること
チュートリアル 中級

委託先・外部パートナーアカウントの棚卸し ─ SaaS・GitHub・Slackでまず確認すること

チュートリアル 中級

委託先・取引先・外部パートナーのSaaS、GitHub、Slack、Microsoft 365権限を棚卸しする手順を整理。確認項目、初動対応、エスカレーション条件を実務向けに解説します。

外部パートナーのアクセスは「例外」ではなく継続的な管理対象

委託先、取引先、開発パートナー、代理店、外部監査人などにSaaSアクセスを付与することは、多くの組織で日常的になっている。Microsoft 365やGoogle Workspaceのゲスト、GitHubの外部コラボレーター、Slack Connect、ファイル共有リンク、プロジェクト管理SaaSの外部ユーザーは、業務を進めるうえで便利な仕組みだ。

一方で、外部パートナーのアクセスは、社員アカウントの入退社管理とは違う場所に残りやすい。契約終了、担当者変更、プロジェクト終了、委託先側の退職が社内IdPに連動していない場合、正規の認可経路のままデータへ触れ続けられる可能性がある。

この記事では、委託先・外部パートナーアカウントの棚卸しを、攻撃手順ではなく防御・確認・初動対応の観点で整理する。対象は、情シス、SaaS管理者、開発組織の管理者、CSIRT、外部委託を扱う部門責任者を想定している。

この記事で扱う範囲

現時点で公開情報から確認できる範囲の公式ドキュメントをもとに、外部ユーザー権限の棚卸し手順を実務向けに整理する。個別サービスの画面手順は変わるため、ボタン名ではなく「何を確認し、どう判断するか」に焦点を置く。


読者別の影響:誰が何を見ればよいか

委託先アカウントの棚卸しは、SaaS管理者だけで完結しない。契約、業務所有者、開発、法務、CSIRTがそれぞれ別の情報を持っているためだ。最初に役割ごとの確認ポイントを分けると、削除してよい権限と、期限付きで残すべき権限を判断しやすい。

読者・担当者主な関心まず確認すること
情シス・SaaS管理者外部ユーザー、ゲスト、共有リンク、管理者権限どのSaaSに外部ユーザーがいるか、SSO外アカウントがあるか
開発者・DevOpsGitHub、CI/CD、クラウド、APIトークン外部コラボレーター、Deploy Key、Bot、リポジトリ権限
SaaSオーナー・部門責任者業務影響、契約、担当者変更その外部ユーザーが今も業務上必要か、契約期間内か
CSIRT・SOC不審利用、ログ、初動判断最終ログイン、共有・ダウンロード、権限変更、招待履歴
法務・購買契約終了、委託先管理、通知判断委託契約・NDA・再委託条件とアクセス実態が一致しているか

重要なのは、「外部ユーザーが存在すること」自体を問題視しすぎないことだ。業務上必要な外部アクセスはある。問題は、所有者不明、期限なし、過剰権限、長期未利用、契約終了後の残存アクセスが説明できない状態で残ることにある。


まず確認すること:外部アカウント棚卸しの10項目

最初から全SaaSを完璧に棚卸ししようとすると止まりやすい。まずは、顧客情報、ソースコード、契約書、財務、人事、認証情報、監査ログに触れるSaaSを優先する。確認項目は次の10個に分けると、作業表に落とし込みやすい。

確認項目見るポイント
1. 外部ユーザー一覧ゲスト、外部コラボレーター、Slack Connect相手、共有ワークスペース
2. 所有者社内の責任者、部門、プロジェクト、契約担当が説明できるか
3. 契約・業務期限契約終了日、プロジェクト終了日、次回レビュー日があるか
4. 権限範囲管理者、編集者、リポジトリ書き込み、請求管理、監査ログ閲覧
5. 認証経路SSO配下か、外部IdPか、個別IDか、MFAが求められるか
6. データ範囲顧客情報、ソースコード、契約書、個人情報、秘密情報に触れるか
7. 最終利用長期未ログイン、招待未承諾、利用実態なしの権限がないか
8. 共有設定リンク共有、外部共有フォルダ、外部チャンネル、ゲスト招待
9. 自動化経路Bot、Webhook、APIトークン、Deploy Key、外部アプリの権限
10. 証跡招待者、承認者、変更履歴、監査ログ、削除・保留判断の記録

この10項目は、SaaS権限棚卸しチェックリスト と合わせて使うと作業に落とし込みやすい。退職者や委託終了者に焦点を当てる場合は、退職者アカウント確認チェックリスト で、人事イベント後に残るアクセス経路も確認する。

削除だけを急がない

外部アカウントを一括削除すると、監査、顧客対応、保守、請求、インシデント調査に必要なアクセスまで止める場合がある。高リスク権限は止めるべきだが、所有者、業務影響、契約、ログを確認しながら判断する。


サービス別に見る観点:Entra、GitHub、Slack、Google Workspace

外部ユーザーは、サービスごとに名前と管理単位が違う。同じ「外部パートナー」でも、Microsoft EntraではB2Bユーザー、GitHubではoutside collaborator、SlackではSlack Connect、Google Workspaceでは外部共有・訪問者共有として現れることがある。

サービス領域代表的な外部アクセス実務で見る観点
Microsoft Entra / Microsoft 365B2B collaboration、ゲストユーザー、外部テナントアクセスレビュー、期限、MFA/条件付きアクセス、グループ所属
GitHub Organizationoutside collaborator、team外のリポジトリアクセスリポジトリ権限、2FA要件、招待者、最終活動、退職・契約終了との整合
SlackSlack Connectチャンネル、外部組織とのDM/チャンネル外部接続一覧、チャンネル所有者、共有範囲、機密情報の扱い
Google Workspace外部共有リンク、訪問者共有、信頼ルール共有範囲、リンク共有、外部ドメイン、Drive/Groups/Calendarの設定
その他SaaSゲスト、共有プロジェクト、外部アプリ管理者権限、請求管理、監査ログ、SSO対象外の個別ID

Microsoft Entraのようにアクセスレビューや期限付きアクセスを設計できる環境では、外部ユーザーを「作ったら終わり」にしないことが重要だ。GitHubでは、Organizationメンバーではない外部コラボレーターが特定リポジトリへアクセスできるため、個別リポジトリの権限が残っていないかを見る。Slack ConnectやGoogle Workspaceでは、外部ユーザーそのものだけでなく、チャンネル・共有リンク・共有ドライブがデータ出口になっていないかを確認する。

このあたりは 認証と認可の違い を理解していると判断しやすい。ログインできることが認証、どのデータや機能へ触れるかが認可だ。外部ユーザー棚卸しでは、認証を止めたつもりでも、別の認可経路が残っていないかを見る必要がある。


初動対応:見つけた権限をどう扱うか

棚卸しで不明な外部アカウントが見つかった場合、最初にやることは「すぐ削除」だけではない。高リスクなものは一時停止・権限縮小を優先し、業務影響が不明なものは所有者確認と期限付き保留を組み合わせる。

判断取る対応記録すること
明らかに不要無効化、削除、共有解除、トークン失効対象、時刻、判断者、削除理由、ログ確認範囲
業務上必要権限を最小化し、期限と所有者を設定所有者、契約、目的、期限、次回レビュー日
所有者不明一時停止または読み取り専用化し、確認依頼連絡先、回答期限、影響範囲、暫定措置
高権限・不審利用ありCSIRTへエスカレーションし、ログ保全最終利用、権限変更、共有・ダウンロード、関連アカウント
外部共有が広すぎる公開範囲を制限し、必要な相手だけ再付与共有元、共有先、データ種別、再付与理由

やってはいけないのは、削除した事実だけ残して、なぜ削除したかを記録しないことだ。後日、委託先や監査対応で説明が必要になる場合がある。逆に、必要だから残した権限も、所有者、目的、期限、再確認日がなければ例外の固定化につながる。

外部共有が漏えい疑いにつながる場合は、漏えい疑い初動テンプレート で、事実関係、影響範囲、初動記録を分けて整理する。GitHubなど開発基盤の権限が関係する場合は、GitHub secret leak対応チェックリストGitHub secret leak 初動ミニCTF も合わせて確認すると、認証情報の失効・再発行の考え方を練習できる。


判断基準:どこまでエスカレーションするか

外部パートナーアカウントは、すべてをインシデント扱いにする必要はない。ただし、次の条件が重なる場合は、通常の棚卸しではなくセキュリティ対応として扱う。

エスカレーション条件理由
管理者権限を持つ外部アカウントが所有者不明設定変更、ユーザー追加、ログ閲覧など影響が大きい
契約終了後も顧客情報やソースコードへアクセス可能契約・通知・監査上の説明が必要になる可能性がある
SSO外の個別IDでMFA未設定社内IdPの停止やポリシーが効かない
長期未利用なのに外部共有リンクやAPIトークンが有効誰も見ていないデータ出口になりやすい
不審なログイン、共有、ダウンロード、権限変更がある通常の棚卸しではなく調査・保全が必要
個人メールアドレスの外部ユーザーが高権限所属・管理責任・本人性を確認しにくい

エスカレーション時は、アクセス停止、ログ保全、対象データの特定、所有者確認、契約・法務確認を並行して進める。ここでも、攻撃者名や被害規模を推測で断定しない。ログと公式な管理情報で確認できる事実、推測、未確認事項を分けることが重要だ。


よくある誤解

「SSOを使っているので外部アカウントは管理できている」

SSOは重要だが、外部ゲスト、GitHub outside collaborator、共有リンク、Slack Connect、OAuthアプリ、APIトークンは別の管理単位で残る場合がある。SSO配下かどうかと、データへ触れる認可経路が残っているかは分けて確認する。

「外部ユーザーを消せば棚卸しは完了」

削除は一部の対応にすぎない。所有者移管、共有解除、BotやWebhookの確認、監査ログの保全、期限付き例外の設定まで含めて完了条件を決める必要がある。

「委託先の退職者は委託先側で管理しているはず」

委託先側の退職処理と、自社SaaS上の外部ユーザー削除は自動連動しないことが多い。契約や運用ルールで、担当者変更・契約終了・プロジェクト終了時の連絡経路と削除期限を決めておく。

「外部共有は部門の利便性なのでセキュリティの対象外」

外部共有は、正規機能であると同時にデータ出口でもある。利便性を否定する必要はないが、共有範囲、期限、所有者、機密ラベル、監査ログを確認対象に入れる。


関連用語・関連ページ

委託先アカウントの棚卸しは、用語だけでなく実務導線とセットで理解すると進めやすい。


まとめ:外部アクセスは「誰が、何に、いつまで」を残す

委託先・外部パートナーアカウントの棚卸しでは、外部ユーザーがいること自体を問題にするのではなく、説明できないアクセスを減らすことが目的になる。見るべき軸は、所有者、契約・業務期限、権限範囲、認証経路、データ範囲、最終利用、共有設定、自動化経路、証跡だ。

まずは主要SaaSと開発基盤に絞り、管理者権限、外部共有、SSO外アカウント、長期未利用、高権限の外部ユーザーから確認する。必要な権限は最小化し、所有者と期限を付ける。不要な権限は止め、理由と時刻を記録する。

次に進むなら、SaaS権限棚卸しチェックリスト で作業項目を整理し、退職者アカウント確認チェックリスト で人事イベント後の残存アクセスを確認する。漏えい疑いに発展する場合は、漏えい疑い初動テンプレート で、事実、推測、未確認事項を分けて記録する。

公式情報・参考情報

ESC