ゲストユーザーが増えるほど“監査が詰む”問題
- 山崎行政書士事務所
- 4 日前
- 読了時間: 11分
Entra × SharePoint × Teams で外部コラボを「提出物」にする、情シス実務ルール
取引先・委託先との共同作業が当たり前になった一方で、情シスがいちばん苦しむのは ゲストユーザーと共有リンクの“増殖” です。事故が起きるときは、だいたい「誰が・誰に・何を・いつまで」共有しているかが、即答できない。
山崎行政書士事務所のクラウド法務で重視しているのは、技術的に“設定して終わり”ではなく、「提出できる」「保全できる」「主語が割れない」状態を運用として作ることです。外部コラボ統制も同じで、監査・取引先照会・インシデント時に必要なのは「設定値」だけではなく、台帳・承認・棚卸し・ログの証跡が揃っていることです。
想定読者
事業会社の情シス／セキュリティ担当
Teams/SharePoint が全社展開済みで、取引先共有が増えている
「外部共有の統制」と「現場の生産性」を両立したい
監査対応（ISMS、顧客監査、委託先監査、NIST系の統制要求）で、毎回ヒヤッとする
まず整理：Teamsの「外部アクセス」と「ゲストアクセス」は別物
ここを混同すると統制が破綻します。
外部アクセス：他組織のユーザーを検索・通話・チャットできる仕組み（既定で有効と記載）
ゲストアクセス：組織外ユーザーをチームに招待して、ファイル共有など“リソースにアクセスさせる”仕組み。招待されたユーザーは Microsoft Entra B2B のゲスト アカウントを取得します。
つまり、監査で問われる「社外が社内データに触れているか」は、ほぼゲスト側（とSharePoint共有側）で決まります。
外部コラボ統制の“提出物”3点セット
情シスが疲弊しないために、最初から提出物の形にしておきます。
提出物①：外部コラボ運用ルール（誰が・何を・どの方式で共有できるか）
データ分類（公開／社外共有可／機密／個人データ 等）
共有方式の許容（外部アクセス／ゲスト／共有リンク（特定/Anyone））
例外の承認要件（期限・理由・承認者・棚卸し頻度）
提出物②：台帳（ゲスト台帳＋共有リンク台帳）
ゲストの“スポンサー（社内責任者）”と“期限”
共有リンク（特にAnyone）の“例外承認”と“期限”
提出物③：証跡パック（設定値スナップショット＋棚卸し結果＋監査ログ方針）
山崎行政書士事務所でよくある詰みポイントは、ログはあるのに説明できない、保存できない、責任の主語が割れるの3点です。外部コラボでも、設定値の画面キャプチャ、棚卸し結果、監査ログの保存方針まで含めて“証跡”にします。
技術設計：入口・継続・出口・証跡（4点セット）
ここからは Microsoft 公式（Microsoft Learn 日本語）に沿って、現場で迷わないように分解します。
1) 入口：Entraで「誰がゲストを招待できるか」を締める
Entra の外部コラボレーション設定では、外部ユーザーを招待できるロールや、特定ドメインの許可/ブロック、ゲストがディレクトリで見える範囲の制限などを設定できます。
招待できる人の既定が強すぎる（要注意）
Microsoft Learn では、既定として「組織内のすべてのユーザー（ゲストユーザー含む）が外部ユーザーを招待できる」と記載があります。
この既定のままだと起きること：
現場の善意でゲストが増殖（スポンサー不明）
退職・異動で“責任者が消える”
監査で「誰の判断で招待した？」が追えない
実務推奨（運用が回る落としどころ）
招待権限を 「メンバー＋特定管理者」または「特定管理者のみ」へ寄せる
（少なくとも「ゲストも招待できる」は原則避ける）
どうしても現場招待を残すなら、“スポンサー必須”（台帳に残す）とセット運用
ゲストがディレクトリで見える範囲も“最小化”が基本
Entra ではゲストユーザーのアクセス範囲を3段階で選べます。「ゲストがメンバーと同じアクセス権（最も包括的）」〜「自分のオブジェクトのみに制限（最も厳しい）」まであり、既定は “limited access” と記載されています。
危険シグナル（高リスク）
「ゲスト＝メンバーと同等」を許可している（ディレクトリ情報の露出が増える）
2) 入口：SharePoint/OneDriveの共有は“Entra設定と連動する”前提で設計する
SharePoint/OneDrive には外部共有モデルがあり、Entra B2B 統合を有効にしているかどうかで挙動が変わります。
B2B 統合が有効：ゲストアカウントが作成され、Entra設定が適用される（サイト共有もファイル共有も）
B2B 統合が無効：ファイル共有で ゲストアカウントが作成されないケースがある、と記載があります。
ここは情シスが見落としやすいポイントです。「Entra側でドメイン制限したから安心」…と思っていても、モデルによって効き方が変わり得ます。
組織レベルの共有設定（SharePoint管理センター）
Microsoft Learn には、SharePoint/OneDrive の共有レベルとして以下が示されています。
すべてのユーザー（Anyoneリンク）：認証なしアクセスも可能
新規および既存のゲスト
既存のゲスト
組織内のユーザーのみ
また、組織レベルで共有を制御しつつ、サイト単位では同じか、より制約的にできると明記されています。
実務推奨（監査耐性が上がる既定値）
原則：「新規および既存のゲスト」または「既存のゲスト」 をベース
“Anyoneリンク（すべてのユーザー）”を許容するなら、
有効期限を必須化
権限を閲覧のみへ寄せる
を組織ポリシーとして先に決める（Microsoft Learnにも「期限を強制」「閲覧のみ」などの制御が可能と記載）
既定の共有リンク種別は「特定のユーザー」を基本にする
SharePoint/OneDrive の既定リンク種別として
特定のユーザー
組織内のみ
リンクを持つすべてのユーザー（Anyone）
が示され、Anyoneリンクは「追跡できなくなる」旨が明記されています。
危険シグナル（高リスク）
既定リンクが “Anyone”
期限なし、編集可
例外承認が台帳に残らない
ゲストアクセス期限（自動期限切れ）を“運用コスト削減”に使う
SharePoint/OneDrive には「ゲストアクセスが一定日数後に期限切れ」設定があり、管理者が有効期限を設定できると記載されています。
これがあると、
退職・プロジェクト終了で放置されるゲストを自然減させられる
“棚卸しで追い込み”の負荷が下がる
3) 入口：サイト単位の共有設定で“現場の例外”を吸収する
サイトの共有設定は、組織と同じ/より制約的である必要があり、サイト単位でゲスト有効期限や既定リンク種別を変える手順も示されています。
また重要な挙動として、組織レベルで外部共有をオフにすると、サイトレベルでは外部共有が使えなくなり、共有リンクが機能しなくなる（オンに戻すと復帰する）という記載があります。
この仕様は“緊急遮断スイッチ”として覚えておく価値があります。インシデント時に「止められる」ことは統制の一部です。
4) 入口：Teamsゲストは“全社設定”＋“チーム単位制御”の二段構えにする
Teams のゲストアクセスは、招待されたユーザーが Entra のゲストアカウントになり、チーム退出だけではアカウントが削除されない（削除は管理者側）と記載があります。
さらに、ゲストアクセスは組織レベルでオン/オフだが、秘密度ラベルでチーム単位の制御が可能と明記されています。
実務推奨：ラベルで「社外共有可チーム」を限定する
Microsoft Purview の秘密度ラベルは、ファイル/メールだけでなく、Teams/グループ/SharePointサイトという“コンテナー”にも適用でき、外部ユーザーアクセスや外部共有などの設定に使えるとされています。
運用としては：
ラベル例
「社外共有不可（デフォルト）」
「社外共有可（スポンサー必須・期限必須）」
「高度機密（社外共有禁止＋追加CA）」
“社外共有可”ラベルを付けたチームだけ、ゲストを許容
注意点（設計ミスが起きやすい）外部共有オプション等をラベル設定として構成すると、サイト所有者がラベルを変更することで外部共有の設定を変更できるようになる、という注意書きがあります。「現場に委ねたくない」場合は、そのラベル設定を構成しない、という判断が必要です。
5) 継続：クロステナントアクセス設定で“相手テナントとの境界”を詰める
B2B で他の Entra 組織と連携する場合、クロステナントアクセス設定で受信/送信のスコープを見直す必要がある、と外部コラボ設定ページから参照されています。
Microsoftアカウント（MSA）フォールバックを許すか？
クロステナントアクセス設定には、B2BユーザーがMicrosoftアカウントで招待を引き換えできないようにする手順が記載され、MSAを無効化する操作が示されています。同時に「フォールバックIDプロバイダーは少なくとも1つ有効が必要」「MSAを無効にするならメールOTPを有効に」等の注意もあります。
実務観点
取引先が“個人のMicrosoftアカウント”で入ってくる運用は、スポンサー・本人性・棚卸しで揉めやすい
B2Bの原則は 相手組織IDで入ってもらう（例外は例外として台帳で管理）
外部テナントのMFAを「信頼する」か
クロステナント設定の信頼設定には、外部組織のMFA要求を条件付きアクセスが信頼できるようにするオプションが記載されています。
ここは取引先の成熟度に左右されるため、一律ONは危険です。“信頼する/しない”を取引先区分（重要委託先・一般取引先など）で決めるのが現実的です。
6) 継続：条件付きアクセスで「ゲストはMFA必須」を原則にする
Microsoft Learn には、ゲスト/外部ユーザーにMFAを要求する条件付きアクセスの作り方として、対象ユーザーに「すべてのゲスト ユーザーと外部ユーザー」を選び、まずレポート専用で検証する流れが示されています。
実務推奨
まず レポート専用（Report-only） で影響確認 → 段階的に本番適用
“緊急用アカウント（ブレークグラス）”の除外など、運用を壊さない配慮をセットにする（同ページで除外例が言及）
7) 出口：アクセスレビューで“期限管理”を自動化する
アクセスレビューは、ゲスト本人や意思決定者に継続利用の確認を求め、不要なアクセスを削除できると説明されています。前提条件として Microsoft Entra ID P2 または Entra ID Governance が必要と明記されています。
また、実務的に重要なのは「回答がないユーザーも削除した方がよい」と明確に書かれている点です。
実務ルール例（そのまま社内規程に落とせる粒度）
レビュー頻度：四半期（重要委託先は毎月も検討）
レビュアー：スポンサー（業務オーナー）＋情シス（監督）
“未回答＝削除候補”を原則とし、例外は期限付き延長（台帳に残す）
監査で刺さる「危険シグナル集」（外部コラボ版）
情シスが早期に潰しておくと、監査・顧客照会・事故対応が一気に楽になります。
レベル高（すぐ是正候補）
Entra：ゲストがメンバー同等、またはゲストの招待権限が広すぎる（既定が強いので要確認）
SharePoint：既定リンクが Anyone、期限なし、編集可（追跡不能になり得る）
Teams：ゲストアクセスを全社でONにしているのに、チーム単位の統制（ラベル等）がない
“チームから外したからOK”と思っている（ゲストアカウントは残り得る）
レベル中（運用で漏れやすい）
サイト単位の例外（共有レベル変更）が台帳にない
クロステナント設定でMSAフォールバックが実質許容されている（意図せず個人ID流入）
ゲストMFAの条件付きアクセスが未適用（または例外が多すぎる）
レベル低（改善余地）
ゲスト有効期限が未活用（棚卸しが人力になりがち）
レビュー頻度が年1で形骸化（実態は“無期限”と同義）
「提出できる」状態を作る運用設計（最小構成）
ここは行政書士としての“文書化・運用化”の出番ですが、本記事は一般情報として、情シスが社内で回せる粒度に落とします（個別案件の法的判断は別途）。
承認フロー（最小）
現場：外部コラボ申請（テンプレ）
スポンサー（業務オーナー）：データ分類・必要性・期限に責任
情シス：方式妥当性（ゲスト/外部アクセス/共有リンク種別）、設定適用
棚卸し：アクセスレビュー or 台帳棚卸しで更新
台帳に必ず入れる項目（これだけで監査が変わる）
外部ユーザー（UPN/email）
スポンサー（社内）
アクセス先（チーム/サイト/アプリ）
データ分類
有効期限
次回棚卸し日
例外承認（ある場合）
このために、本文冒頭で Excelテンプレ（台帳＋棚卸し＋証跡インデックス） を添付しています。運用に合わせて列を削ってもOKです。
証跡：ログは「ある」ではなく「出せる」へ
監査・事故対応で問われるのは、“ログがあるか”ではなく 「いつでも同じ手順で提出できるか」 です。
Microsoft Purview 監査については、監査（標準）が多くの組織で既定で有効とされ、監査ソリューションの一つとして整理されています。また、監査ログの保存期間は「監査ログ保持ポリシー」で延長でき、保持期間やライセンス要件が整理されています。
実務のコツ
“監査ログを検索できる人”と“提出を承認する人”を分ける（主語固定）
重要変更（外部共有の変更、ゲスト招待ポリシー変更等）は、設定スナップショットも同時保管
「証跡パック」シートに、取得頻度・保存先・責任者を固定で書く（テンプレに入れています）
最後に
外部コラボ統制は「全部禁止」でも「野放し」でも失敗します。現場の生産性を落とさずに監査耐性を上げる鍵は、入口を締め、期限と棚卸しを自動化し、証跡を提出物として整形することです。
山崎行政書士事務所では、技術（Entra/Teams/SharePoint/Purview）と文書設計（規程・台帳・運用設計）をつなぎ、「情シスの現場で回る」統制に落とし込む支援を行っています（※個別の法律判断や紛争対応は弁護士領域です）。
コメント