「社外共有可」ラベル運用を“提出できる統制”にする

山崎行政書士事務所
4 日前
読了時間: 8分

― 例外を止めずに、管理できる形へ（Microsoft Purview × SharePoint/Teams）―

※本記事は一般的な情報提供です。個別案件の法的助言ではありません。※Microsoft、Azure、Microsoft 365、Entra 等は米国 Microsoft Corporation の商標または登録商標です。当事務所は独立したサービス提供者です。

0. なぜ「社外共有可」は“運用設計”が勝負なのか

事業会社の情シスが一番つらいのは、社外共有そのものではなく、**「例外が爆発したときに、説明できなくなること」**です。

外部共有を堅く締める → 現場が止まる → 個人メール添付 / 私物ストレージ / シャドーITが始まる
外部共有を緩める → 便利になる → “誰が・なぜ・どこまで”を説明できない
監査・親会社・取引先から「統制は？証跡は？」→ 設定はあるのに提出物にならない

そこで「社外共有可」ラベルを入れても、例外処理のルールがないと、結局「ラベルは貼ったが現場が勝手に回避する」か「情シスが承認地獄」になります。

Microsoft Purview の “Secure by default” の考え方でも、ラベリングは「推奨分類」だけでなく**“エンドユーザーが例外を管理するためのオプション”**まで含めて設計することが前提になっています。

1. まず「社外共有可」を“技術の言葉”に翻訳する

「社外共有可」と言っても、Microsoft 365 では少なくとも次の4つが別物です。

Teams / M365 グループに外部（ゲスト）を入れられるか
SharePoint サイトの外部共有レベル（内部のみ／ゲスト／Anyoneリンク等）
共有リンクの既定（“特定のユーザー”が既定か、“誰でも”が既定か）
条件付きアクセス（MFA、ToU、非管理端末制限など）を強制できるか

この4つを同じラベル（＝同じ統制）として結びつけて運用できるのが、Purview の「Teams/Groups/Sites 向け秘密度ラベル」の強みです。

2. Microsoft Purview の“コンテナーラベル”でできること（重要ポイントだけ）

2-1. まず前提：コンテナーラベルを有効化して同期する

Teams / グループ / SharePoint サイトでラベルを効かせるには、一度だけ有効化＆同期が必要です。手順の中に Execute-AzureAdLabelSync が出てきます。

2-2. ラベルで制御できる代表設定

「グループとサイト」スコープのラベルでは、代表的に次を設定できます。

プライバシー（パブリック／プライベート／なし）
- ラベル適用時にプライバシーが設定・ロックされ、変えるには一度ラベルを外す必要がある（＝統制の強さでもあり、運用上の注意点でもある）
外部ユーザーアクセス
- 「グループ所有者がゲストを追加できるか」を制御
外部共有（SharePoint）
- ラベル付き SharePoint サイトの外部共有を「すべてのユーザー（Anyone）／新規および既存のゲスト／組織内のみ」などで制御
条件付きアクセス（SharePoint）
- 非管理端末のアクセス制御、または認証コンテキスト（例：MFA必須、ToU同意）をラベル単位で適用可能

実務で大事：認証コンテキストはすべてのアプリが対応しているわけではないので、「どのクライアントでアクセスするか」を運用で押さえます（例：Office for the web / Teams デスクトップ / Planner などの記載）。

2-3. 罠：Teams の“所有者”はラベルを変えられる

Teams 側のドキュメントに明確に書かれていますが、チーム所有者は、秘密度ラベルとプライバシー設定をいつでも変更できます。

つまり、ラベルを“統制の鍵”にするなら、同時にこう決める必要があります。

誰が Owner になれるのか（Owner = 事実上のガバナンス権限）
Owner に「勝手にラベル変更」される前提で、変更を“例外申請”として扱うのか、Owner権限を絞って自動化で作るのか

3. 「社外共有可」ラベルの“標準形”設計（おすすめの落としどころ）

ここからが情シス向けの実務ルールです。

3-1. ラベルは最低3つに分ける（例）

「社外共有可」を単独で作るより、例外を吸収できる階層にします。

社外共有不可（Default）：原則はこれ
社外共有可（標準）：取引先との共同作業用
社外共有可（Anyoneリンク例外）：配布型・匿名リンクが必要な超例外（原則避ける）

この分け方をしておくと、例外が“どれだけ例外か”をラベル名だけで説明できます（監査・取引先説明が一気にラクになります）。

3-2. 「社外共有可（標準）」に入れる設定例

Microsoft Learn の設定項目に沿うと、標準形は次の組み合わせが扱いやすいです。

プライバシー：プライベート（検索や意図しない検出リスクを下げる）
外部ユーザーアクセス：許可（ただし Owner を統制する）
SharePoint 外部共有：新規および既存のゲスト
- “Anyoneリンク”を標準にしない（後述の例外へ）
条件付きアクセス：認証コンテキスト（MFA必須 or ToU必須）
- 高リスク案件は ToU（使用条件）同意を条件にできる例も記載あり
非管理端末：ブロック or Web限定（業務要件と衝突しやすいので“例外”設計が必須）

3-3. 共有リンク既定は「特定のユーザー」を標準にする

“Secure by default” のガイドでも、リスク軽減のために既定の共有を「特定のユーザー」にすることが推奨されています。

そして、Purview の秘密度ラベルを使って SharePoint サイトの秘密度ラベルに基づき、共有リンクの既定（種類）を構成できる旨も記載があります。

ここ、めちゃくちゃ効きます。外部共有は “できる/できない” だけでなく、**「既定が何か」**で事故率が変わります。既定が “Anyoneリンク” だと、現場は善意で事故ります。

4. 「例外」をどう扱うか：止めるのではなく、台帳にする

ここが本題です。例外をゼロにするのは無理です。むしろ Microsoft のガイドでも、例外の管理方法をユーザーにトレーニングすることが明記されています。

4-1. 例外を4種類に分類する（現場で揉めないための分類）

例外分類がないと、全部が“特別扱い”になって破綻します。私は情シス向けには、まずこれを切ります。

例外A：期間限定の社外共有（期限あり）

例：3か月だけ共同プロジェクトで外部共有が必要
対応：ラベルを「社外共有可（標準）」へ“期限付きで”変更 → 期限で戻す
必須：Expiry（失効日）を台帳に入れる

例外B：Anyoneリンクが必要（匿名配布が必要）

例：外部ユーザーがアカウントを持てない／イベント配布
対応：ラベルを「社外共有可（Anyone例外）」に変更（標準ラベルではやらない）
ガードレール：SharePoint 側で Anyoneリンクの有効期限強制や“表示のみ”強制などを検討（SharePoint 管理の設定として言及あり）
重要：そもそもサイトの外部共有設定は管理センター側での統制が基本（サイト単位の共有設定変更の考え方も参照）

例外C：暗号化が業務アドイン／基幹アプリと衝突

例：Excelアドインが暗号化ラベルで動かない
Microsoft のガイドでも「暗号化で正しく機能しない場合にラベルを変更する方法」をトレーニング項目として挙げています
対応：
- “外部共有可”だけでなく、**ファイル側の保護（暗号化の有無）**を別軸で設計
- 暗号化は「誰がアクセスできるか」を制御でき、場所を問わず保護を維持する前提の機能です