企業間データ共有の「現状」と「あるべき姿」
Push / Pull / Share モデルの最適解と、認証・セキュリティの正しい設計
- この記事は、大企業や金融機関の「ファイル共有ルール」の愚行のリニューアル記事です。 *
はじめに ── 「なぜ今もPPAPなのか」という問い
2020年に日本政府がPPAP（パスワード付きZIPファイルのメール送信）廃止を宣言して数年が経過した。しかし2026年現在もなお、日本の大企業・金融機関とのプロジェクトでは、外部コンサルタントやITエンジニアが「ZIPファイルをお送りします」「パスワードは別途メールにて」というやり取りを強いられる現場が後を絶たない。
社内では Microsoft 365（M365）や Google Workspace を活用し、TeamsやSlackでリアルタイム共同編集を行っているにもかかわらず、一歩社外との連携に踏み込んだ瞬間に「石器時代」に逆戻りする。この矛盾はなぜ起きるのか。
答えはシンプルだ。「ファイル共有」という行為そのものが、Push / Pull / Share という3つの根本的に異なるアーキテクチャを持つことを、多くのセキュリティ担当者が正しく理解していないからである。
本稿では、この3モデルを技術・ガバナンス・認証の各側面から徹底的に整理し、企業が今すぐ取るべき行動を具体的に示す。
第1章：3つのデータ共有モデルの本質的な違い
1-1. Push型（送信型）── データを「コピーして渡す」
定義： 送信者が能動的にデータのコピーを作り、受信者に届ける。送信完了後、そのコピーは送信者の管理下を永久に離れる。
【Push型のデータフロー】
送信者 ──[コピー作成]──→ メール/ZIP/チャット ──→ 受信者のデバイス
↓
（ここから先、送信者に制御不能）
・USBコピー
・個人クラウドアップロード
・第三者転送
・永久保存
代表的な手段と特性：
| 手段 | 暗号化 | 誤送信対策 | マルウェア検知 | ガバナンス |
|---|---|---|---|---|
| メール添付（平文） | ✗ なし | ✗ 不可 | ✅ 可能 | ✗ 皆無 |
| PPAP（ZIP+パスワード） | △ ZIP暗号化 | ✗ 不可 | ✗ 阻害する | ✗ 皆無 |
| チャット直接送信 | ✅ 経路暗号化 | △ 削除可（受信後は不可） | ✅ 可能 | △ ログのみ |
| EDI / B2B連携 | ✅ | ✅ | ✅ | △ 業界標準 |
PPAPの「致命的欠陥」を改めて整理する：
PPAPを「一定のセキュリティ対策」と考えるのは根本的な誤解だ。以下の理由により、PPAPはセキュリティを高めるどころか下げる。
- 経路保護の幻想： パスワードを同一の通信経路（メール）で送るため、経路を傍受された場合には何の意味もない
- マルウェアの隠蔽： ZIP暗号化によりメールゲートウェイのアンチウイルスがファイル内容を検査できなくなる。悪意ある添付ファイルを安全に届ける「ラッパー」として機能してしまう
- 誤送信の救済不可： 誤った相手にZIPを送り、気づいてパスワードを送らなくても、受信者がZIPの中身を推測・解析しようとする可能性がある。根本的な誤送信は解決されない
- 暗号強度の限界： 一般的なZIP暗号化（ZipCrypto）は現代のブルートフォース攻撃に対して著しく脆弱。AES-256使用でも辞書攻撃への耐性は低い
1-2. Pull型（ダウンロード型）── データを「置いて取りに来させる」
定義： 発信者がデータを所定の場所（サーバー・クラウドストレージ）に配置し、受信者が能動的に取りに来る。最終的にデータのコピーは受信者側に作られる。
【Pull型のデータフロー】
送信者 ──[アップロード]──→ 中継サーバー/クラウド
↑
（ここまでは管理可能：ダウンロード期限・回数制限など）
↓
受信者 ──[ダウンロード]──→ 受信者のデバイス
↓
（ここから先は制御不能）
代表的な手段と特性：
| 手段 | 認証 | 期限制限 | ダウンロード後の制御 | 監査ログ |
|---|---|---|---|---|
| ファイル転送サービス（Crypt便等） | △ メール認証 | ✅ 可能 | ✗ 不可 | △ 取得記録のみ |
| S3署名付きURL | ✗ URLのみ | ✅ 必須 | ✗ 不可 | ✅ アクセスログ |
| SFTP（個別アカウント） | ✅ 公開鍵/パスワード | ✗ 手動管理 | ✗ 不可 | ✅ 接続ログ |
| FTPS（システム連携） | ✅ 証明書 | ✗ | ✗ 不可 | ✅ |
Pull型が「Push型よりマシ」な点：
- 通信経路は暗号化される
- ダウンロード期限・回数を制限できる
- 誰がいつアクセスしたかのログが残る
- 大量データのシステム間バッチ連携には依然として有効
Pull型が抱える根本的限界：
「ダウンロードされた瞬間に、そのデータは自社の管理外になる」という本質は変わらない。ファイル転送サービスを「公式の安全なファイル共有手段」として採用する企業は多いが、これは「安全な受け渡し方法」であって「安全なデータ管理」ではない。受け渡し後のデータ管理を相手の善意とモラルに完全に委ねている。
1-3. Share型（共有・コラボレーション型）── データを「動かさずに見せる」
定義： データを自社のクラウド上の一箇所（Single Source of Truth）に留め、外部パートナーにはそこへの「アクセス権限」を一時的に付与する。データのコピーは原則として発生しない。
【Share型のデータフロー】
自社クラウド（金庫）
┌─────────────────────────────────────┐
│ ファイル A（常にここにある） │
│ ・アクセスログ：全操作を記録 │
│ ・DRM：閲覧OK、ダウンロードNG など │
│ ・条件付きアクセス：MFA必須 など │
└─────────────────────────────────────┘
↑ 権限付与（アクセス権限） ↓ アクセス（コピーなし）
自社管理者 外部パートナー（ゲスト）
↑
MFA・条件付きアクセスで
本人確認・デバイス確認
代表的な手段：
| 手段 | プラットフォーム | ゲスト招待方式 |
|---|---|---|
| SharePoint / OneDrive ゲスト招待 | Microsoft 365 | Azure AD B2B |
| Teams 外部ゲスト | Microsoft 365 | Azure AD B2B |
| Google Drive 外部共有 | Google Workspace | Google Identity |
| Box 外部コラボレーター | Box | Box Identity |
| GitHub 外部コラボレーター | GitHub | GitHub OAuth |
| Notion ゲスト | Notion | Notion Identity |
Share型が提供するガバナンスの全体像：
Share型で実現できる制御
操作制御
├── 閲覧のみ許可（ダウンロード・印刷・コピー禁止）
├── 編集許可（バージョン管理付き）
└── コメントのみ許可
アクセス制御
├── 特定フォルダ・ファイルのみ可視化
├── 時間制限（期限付きアクセス）
└── 即時アクセス剥奪（Revoke）
デバイス・場所の制御
├── 特定IPアドレス範囲のみ許可
├── MDM管理デバイスのみ許可
└── 特定地域（国）からのみ許可
監査
├── 誰が・いつ・どのファイルに・何をしたか 全記録
├── SIEMへのリアルタイムログ転送
└── 異常アクセス検知・アラート
第2章：3モデルの総合比較
┌────────────────┬─────────────┬────────────┬────────────┐
│ 比較項目 │ Push 型 │ Pull 型 │ Share 型 │
├────────────────┼─────────────┼────────────┼────────────┤
│ データの移動 │ コピー発生 │ コピー発生 │ 発生しない │
│ 送信後制御 │ ✗ 不可 │ ✗ 不可 │ ✅ 完全制御│
│ アクセス取消 │ ✗ 不可 │ △ 削除のみ │ ✅ 即時 │
│ 操作監査ログ │ △ 送信のみ │ △ 取得のみ │ ✅ 全操作 │
│ DRM/権限制御 │ △ 送信前のみ│ △ 限定的 │ ✅ 継続的 │
│ 誤送信リスク │ ✗ 高 │ △ 中 │ ✅ 低 │
│ MFA強制 │ ✗ 難 │ △ 限定的 │ ✅ 容易 │
│ 外部複製防止 │ ✗ 不可 │ ✗ 不可 │ ✅ 制御可 │
│ コンプライアンス│ △ 困難 │ △ 部分的 │ ✅ 適合 │
│ リアルタイム │ ✗ 不可 │ ✗ 不可 │ ✅ 可能 │
│ バッチ連携 │ ✅ 対応 │ ✅ 最適 │ △ 別途検討 │
└────────────────┴─────────────┴────────────┴────────────┘
判定： 人間が関与する業務上のファイル共有においては、Share型が圧倒的に優位。システム間の自動データ連携においては、Pull型（SFTP/API連携）が引き続き適切な場面もある。
第3章：認証方式の現状と「あるべき姿」
Share型を安全に運用するためには、誰が・どのデバイスで・どこから・いつアクセスするかを正確に確認・制御する認証基盤が不可欠だ。現状の問題から理想的な実装まで体系的に整理する。
3-1. 現状の認証の問題点
問題A：ID/パスワード単体認証の蔓延
多くの企業では未だにID/パスワードのみで外部パートナーのアクセスを認証している。この方式の脆弱性：
- パスワード漏洩： フィッシング、クレデンシャルスタッフィング攻撃に無防備
- 共有アカウント： 複数人で同一アカウントを使い回し、個人の責任追跡が不可能
- 退職・離脱後の残存： プロジェクト終了後もアカウントが有効なまま放置される
- パスワードの使い回し： 他サービスで漏洩したパスワードがそのまま使用可能
問題B：メールアドレス確認のみのファイル転送サービス
多くのファイル転送サービスは「ダウンロードURLを受信したメールアドレスに送る」という方式を採用している。これは：
- そのメールアドレスを所持していることの確認に過ぎず、本人確認ではない
- メールアカウント自体が侵害されていれば完全に突破される
- URLを転送するだけで誰でもアクセス可能
問題C：MFA（多要素認証）の未適用
日本企業では「外部パートナーにMFAを要求するのは失礼」「設定が複雑すぎる」という誤った認識からMFAを省略するケースが多い。しかし侵害された認証情報の大半は、MFAがあれば防げた。
3-2. 認証の進化ロードマップ
【認証の進化段階】
レベル1（最低限）
ID + パスワード
└── 脆弱。フィッシング・漏洩に無防備
レベル2（基本）
ID + パスワード + SMS OTP
└── SMSは傍受・SIMスワップ攻撃に脆弱。改善の余地あり
レベル3（推奨）
ID + パスワード + 認証アプリ（TOTP）
└── Google Authenticator / Microsoft Authenticator 等
└── SMS OTPより大幅にセキュア
レベル4（強固）
ID + パスワード + プッシュ通知型MFA + デバイス情報
└── Microsoft Authenticator のNumbering Match
└── MFA疲労攻撃（MFA Fatigue）への対策も必要
レベル5（最高水準）
パスキー / FIDO2 ハードウェアキー
└── フィッシング耐性あり（鍵がデバイスに紐づく）
└── パスワードレス認証
└── YubiKey等のハードウェアトークン
3-3. 外部ゲストに適用すべき認証アーキテクチャ
(a) Azure AD B2B（Microsoft 365環境の場合）
M365環境でのゲスト招待では、Azure Active Directory（Microsoft Entra ID）のB2B機能を使う。これにより外部ユーザーは自社アカウントでサインインしながら、自社の管理下で動作する。
【Azure AD B2B の認証フロー】
外部パートナーのアカウント（例：partner@abc.com）
↓
① 招待メール受信・承諾
↓
② 自社IdP（Azure ADまたはGoogleなど）でサインイン
→ パートナーが既にMFAを設定していれば活用される
↓
③ 自社テナントの条件付きアクセスポリシーを適用
→ 「MFA必須」「特定IPのみ」等を追加で要求可能
↓
④ アクセス許可・監査ログへの記録
B2Bの強みは「外部ユーザーのIDが自社テナントで管理される」点。
招待されたゲストは、自社のアカウント管理画面で一覧化・管理でき、プロジェクト終了時に一括で無効化できる。
(b) 条件付きアクセス（Conditional Access）の設計
条件付きアクセスは「誰が・どのデバイスで・どこから・何をしようとしているか」をリアルタイムに評価し、アクセス可否とMFA要求を動的に判断する仕組みだ。
外部ゲスト向けの推奨ポリシー設計例：
ポリシー1：外部ゲスト全員にMFA必須
対象：ゲストアカウントすべて
条件：すべてのアプリへのアクセス
制御：MFAを要求
ポリシー2：高リスク操作の追加確認
対象：ゲストアカウント
条件：ダウンロード・エクスポート操作
制御：MFA再認証 + セッション有効期限1時間
ポリシー3：地理的制限
対象：ゲストアカウント
条件：日本国外からのアクセス
制御：ブロック（またはMFA強化）
ポリシー4：デバイスコンプライアンス（高機密プロジェクト用）
対象：機密ラベル付きSharePointサイトへのアクセス
条件：非準拠デバイスからのアクセス
制御：ブロックまたは読み取り専用Webアクセスのみ許可
(c) フェデレーション認証（IdP連携）
大企業同士の連携では、互いのIdP（Identity Provider）をフェデレーション（信頼関係の確立）することで、パートナー企業の社員が自社アカウントでシームレスにアクセスできる。
【フェデレーション認証の仕組み】
自社（Relying Party） パートナー企業（Identity Provider）
M365テナント ←信頼関係→ Azure AD / Okta / Google IdP
↓ ↓
アクセス要求を受理 パートナー側でユーザー認証・MFA実施
↓ ↓
トークンを受け取り権限付与 SAML/OIDCトークンを発行して送付
このモデルの利点：
- パートナー社員は自社システムのID/パスワードを使う（別途アカウント不要）
- MFAはパートナー側で実施済み
- アカウントの活性状態管理はパートナーに委任（退職した社員は自動的にアクセス不能になる）
3-4. DRM（デジタル著作権管理）/IRM（情報権限管理）の活用
Share型の真価を引き出す技術として、DRM/IRMがある。これはファイル自体に権限情報を埋め込み、どこに持ち出されても一定の制御を維持する技術だ。
Microsoft Purview Information Protection（旧：Azure Information Protection）
【秘密度ラベルの設計例】
ラベル「社外秘」
├── 閲覧：✅ 許可
├── 編集：✅ 許可
├── 印刷：✅ 許可
├── ダウンロード：✅ 許可（ただしIRMで保護）
└── コピー&ペースト：✅ 許可
ラベル「機密：閲覧専用」
├── 閲覧：✅ 許可
├── 編集：✗ 禁止
├── 印刷：✗ 禁止
├── ダウンロード：✗ 禁止（Webブラウザのみ）
└── コピー&ペースト：✗ 禁止
ラベル「極秘：期限付き」
├── 閲覧：✅ 許可（2024/12/31まで）
├── すべての操作：日付以降は自動失効
└── オフラインアクセス：✗ 禁止
DRM/IRMを使った場合、ファイルがダウンロードされた場合でも：
- 権限のないユーザーには開けない
- 有効期限を設定すれば期限後は誰も開けない
- 権限を剥奪すればすでにダウンロードしたファイルも開けなくなる（オンライン確認が必要な場合）
これにより、「ファイルを送る必要がある」場面でも最低限のライフサイクル制御が可能になる。
第4章：ゲスト招待 vs ゲスト参加 ── 最大の誤解を解く
4-1. 蔓延する「謎の逆転ルール」
多くの大企業・金融機関では、以下のような矛盾したルールが存在する：
【よく見られる矛盾したルール】
❌ 自社 M365 / Google Workspace への外部ゲスト招待
→ 「稟議が必要」「原則禁止」「情報システム部門の個別審査が必要」
✅ 自社従業員が外部パートナーの環境へゲスト参加
→ 「特に手続き不要」「パートナーの招待を受ければOK」
このルールは、ガバナンスの観点から完全に逆転している。
4-2. 「自社テナントへの招待」vs「他社テナントへの参加」── ガバナンスの比較
【自社テナントへ外部パートナーを招待した場合】
管理主体：自社（最大のメリット）
監視できること：
✅ 誰が・いつ・どのファイルを・何した → すべて自社の監査ログに記録
✅ 条件付きアクセスで MFA を強制
✅ Purview でダウンロード・印刷禁止を適用
✅ プロジェクト終了後、ゲストアカウントを即時無効化
✅ 異常なアクセスパターンを自社 SIEM で検知
リスク：
△ 外部の人間が「自社クラウドに入っている」という心理的抵抗感
（だが実際には自社の完全な管理下にある）
【自社従業員が他社テナントへゲスト参加した場合】
管理主体：他社（最大のデメリット）
監視できないこと：
✗ アクセスログは他社が保持（自社では見えない）
✗ 他社の MFA ポリシーに依存（弱ければ意味がない）
✗ 自社のセキュリティポリシーを適用できない
✗ 自社データを他社クラウドに書き込むリスク
✗ 他社テナント内で何が行われているか自社は把握できない
✗ 他社のデータ漏洩事故に自社データが巻き込まれても対処不能
リスク：
✗ 自社機密情報が「他社の管理下のプラットフォーム」に蓄積される
✗ 退職した従業員が他社テナントにアクセスし続けるリスク
結論：「自社テナントへの招待」の方が、「他社テナントへの参加」よりも圧倒的にガバナンスが効く。
この逆転した認識の根本原因は、「境界防御モデル（Perimeter Security Model）」の古いパラダイムにある。「社内ネットワーク＝安全、社外＝危険」「自社インフラに外部の人間を入れてはいけない」という物理的な境界の発想が、クラウド時代に全く通用しない形で残存しているのだ。
4-3. ゲスト招待の正しい設計と運用
自社テナントへのゲスト招待を「安全に・管理可能な形で」実施するための設計を示す。
ゲスト招待の原則
原則1：最小権限（Least Privilege）
→ 必要なフォルダ・ファイルへのみアクセス権を付与
→ 「プロジェクトAフォルダ」のみ、「閲覧のみ」など細粒度で設定
原則2：期限付きアクセス（Time-bounded Access）
→ Microsoft Entra ID のアクセスレビュー機能で定期的に有効期限を設定
→ プロジェクト終了予定日 = アクセス有効期限
原則3：強固な認証（Strong Authentication）
→ ゲストにも MFA を強制
→ リスクの高い操作（ダウンロードなど）は再認証を要求
原則4：継続的な監視（Continuous Monitoring）
→ すべての操作を監査ログに記録
→ 異常なアクセス（深夜・大量ダウンロード等）をアラート
原則5：明確な終了処理（Clean Offboarding）
→ プロジェクト終了時に即座にゲストアカウントを無効化
→ 四半期ごとのゲストアカウント棚卸しを実施
M365でのゲスト招待 実装ステップ
Step 1: SharePoint サイトまたは Teams チームを作成（プロジェクト専用）
Step 2: 外部パートナーのメールアドレスでゲスト招待
→ Microsoft Entra ID の B2B コラボレーション機能を使用
→ 招待メールが送付され、パートナーが承諾するとゲストアカウントが作成される
Step 3: 条件付きアクセスポリシーの適用（事前設定）
→ 「ゲストユーザーには MFA を必須」ポリシーを設定
→ パートナーは初回ログイン時に MFA を設定・実施
Step 4: アクセス権限の設定（最小権限の原則）
→ 該当フォルダにのみ「閲覧者」または「編集者」権限を付与
→ 機密ドキュメントには Purview の秘密度ラベルを付与
Step 5: アクセスレビューの設定
→ 30日後または60日後に定期レビューを設定
→ 自動的に権限の継続確認・失効を実施
Step 6: プロジェクト終了時のオフボーディング
→ Entra ID 管理画面からゲストアカウントを無効化
→ 必要に応じてアカウントを削除
第5章：シナリオ別・最適な共有モデルの選択
シナリオ マトリックス
┌──────────────────────────────┬───────────┬──────────────────────────────┐
│ シナリオ │ 推奨モデル │ 主要ツール │
├──────────────────────────────┼───────────┼──────────────────────────────┤
│ 外部コンサルとの │ │ M365 SharePoint / Teams │
│ 日常的な提案・資料共有 │ Share 型 │ Google Workspace │
├──────────────────────────────┼───────────┼──────────────────────────────┤
│ 契約書・法的文書のドラフト共有 │ │ M365（Purview + 秘密度ラベル）│
│ （閲覧・コメントのみ） │ Share 型 │ DocuSign / Adobe Acrobat │
├──────────────────────────────┼───────────┼──────────────────────────────┤
│ 本番データ・顧客データを含む │ Share 型 │ MDM管理専用端末 + M365 │
│ システム開発・運用 │ （+専用端末）│ Intune + 条件付きアクセス │
├──────────────────────────────┼───────────┼──────────────────────────────┤
│ 大量データの │ │ SFTP（個別アカウント・公開鍵）│
│ システム間バッチ連携 │ Pull 型 │ S3署名付きURL + IP制限 │
├──────────────────────────────┼───────────┼──────────────────────────────┤
│ 機密性の低い公開資料・ │ Push 型 │ 公開 SharePoint リンク │
│ マーケティング資料の配布 │ または公開 │ Web サイト / メール添付（平文）│
├──────────────────────────────┼───────────┼──────────────────────────────┤
│ 緊急・一時的な大容量 │ Pull 型 │ 期限付き署名 URL（S3等） │
│ ファイル受け渡し（例外的） │ （暫定） │ M365 共有リンク（要認証） │
└──────────────────────────────┴───────────┴──────────────────────────────┘
シナリオ別の詳細実装
シナリオA：外部コンサルタントとの提案フェーズ（非機密資料）
状況： 提案資料・議事録・タスク管理を外部コンサル数名と共有
推奨実装（M365 の場合）：
1. Teams チームを作成（プロジェクト名でチャンネルを整理）
2. 外部コンサルのメールアドレスでゲスト招待（B2B）
3. MFA 条件付きアクセスポリシーが自動適用される
4. Teams チャンネルで資料共有・コメント・会議を一元管理
5. プロジェクト終了時にチームをアーカイブ、ゲストを無効化
セキュリティ設定：
・MFA：必須
・ダウンロード：許可（一般資料のため）
・監査ログ：有効
NGな対応：PPAP、ファイル転送サービス
理由：データが管理外になり、リアルタイム協業も不可能
シナリオB：機密度の高い契約・財務データの共有
状況： M&Aデューデリジェンスや財務情報などの高機密資料共有
推奨実装：
1. SharePoint に専用のバーチャルデータルーム（VDR）を構築
→ 機密性が高い場合は専用 VDR サービス（Datasite / Intralinks）も検討
2. Purview 秘密度ラベル「極秘」を適用
・ダウンロード禁止
・印刷禁止
・コピー禁止
・画面キャプチャ防止（ブラウザベースアクセスのみ）
3. 条件付きアクセスを強化
・特定のIPアドレス（相手のオフィス）からのみアクセス許可
・アクセス時刻制限（営業時間のみ）
4. アクセスレビューを週次で実施
5. 全アクセスを SIEM でリアルタイム監視・アラート
セキュリティ設定：
・MFA：強制（Authenticator App のみ、SMS不可）
・ダウンロード：禁止
・IP制限：有効
・有効期限：プロジェクト期間のみ
シナリオC：システム間の大量データバッチ連携
状況： 毎夜、取引データを外部パートナーシステムに連携する
推奨実装（Pull型 SFTP の場合）：
1. パートナーシステム専用の SFTP アカウントを作成
・共有アカウントは使用しない（個別アカウント必須）
2. 公開鍵認証（SSH Key）を使用（パスワード認証は禁止）
3. IP アドレス制限（パートナーの固定IPのみ接続許可）
4. アクセスログを自社 SIEM に転送・監視
5. ファイルの保持期間と自動削除ポリシーを設定
6. 四半期ごとに SSH キーのローテーション
NGな対応：共有アカウント、パスワード認証のみ
理由：個人の追跡が不可能、パスワード漏洩に無防備
第6章：ゼロトラスト実装のロードマップ
6-1. ゼロトラストとは何か（誤解を解く）
「ゼロトラスト」は「何も信頼しない」という意味ではなく、「場所を信頼しない（ネットワークの境界を信頼しない）」という原則だ。
【従来の境界防御モデル（古い考え方）】
社内ネットワーク → 安全（信頼）
社外ネットワーク → 危険（不信）
ファイアウォールの内側 → 何でも許可
問題：一度侵入されれば内部は無防備
VPN接続 = 社内と同等の信頼 → 危険
内部犯行・内部からの誤操作 → 防御できない
【ゼロトラストモデル（現代の考え方）】
場所は関係ない（社内でも社外でも同様に検証）
「誰が」「何のデバイスで」「どのデータに」「どの条件で」を毎回検証
アクセスするたびに認証・認可を再評価
最小権限：必要最小限のアクセスのみ許可
ゼロトラストを外部パートナーとのデータ共有に適用すると、「外部パートナーを社内に招待してはいけない」という発想自体が誤りであることがわかる。重要なのは「どの認証・認可の条件でアクセスを許可するか」であり、物理的・論理的な「場所」ではない。
6-2. ゼロトラスト実装の4つの柱
柱1：Identity（アイデンティティ）
・MFA の全員適用（社員・ゲスト問わず）
・パスキー / FIDO2 への移行
・リスクベース認証（異常なサインインを自動検知）
・特権アクセス管理（PIM）
柱2：Device（デバイス）
・MDM による デバイス管理（Intune等）
・デバイスコンプライアンスの確認（最新パッチ適用等）
・管理されたデバイスのみアクセス許可（高機密環境）
・エンドポイント保護（EDR）
柱3：Data（データ）
・データ分類と秘密度ラベリング
・DLP（データ損失防止）ポリシー
・IRM（情報権限管理）
・暗号化（保存時・転送時）
柱4：Application（アプリケーション）
・条件付きアクセスポリシー
・CASB（Cloud Access Security Broker）
・シャドーIT の検知・制御
・API セキュリティ
6-3. 段階的移行ロードマップ（現実的なアプローチ）
Phase 0（即時：0〜1ヶ月）── PPAPの完全廃止
✅ PPAP を禁止するポリシーを宣言
✅ 代替手段として「M365 / Google Workspace の共有リンク（要認証）」を承認
✅ セキュリティ部門と業務部門の合意形成
✅ 外部パートナーへの変更通知
Phase 1（短期：1〜3ヶ月）── MFA の全員適用
✅ 全社員への MFA 適用（Authenticator App）
✅ 外部ゲストへの MFA 強制（条件付きアクセスポリシー）
✅ ゲスト招待の承認プロセスの簡素化
（稟議廃止または軽量なフォームに移行）
✅ ゲストアカウントの棚卸しと不要アカウントの削除
Phase 2（中期：3〜6ヶ月）── Share 型の標準化
✅ 外部共有のデフォルトを「Share 型（ゲスト招待）」に変更
✅ 秘密度ラベルの導入と分類基準の策定
✅ DLP ポリシーの適用（高機密データの外部送信を自動ブロック）
✅ 監査ログの SIEM への集約
Phase 3（長期：6〜12ヶ月）── ゼロトラスト基盤の整備
✅ デバイスコンプライアンスの条件付きアクセスへの組み込み
✅ リスクベース認証の導入（Microsoft Identity Protection 等）
✅ アクセスレビューの自動化
✅ パスキー / FIDO2 への移行検討
Phase 4（継続：1年〜）── 継続的改善
✅ AI を活用した異常検知・自動対応
✅ ベンダーリスク管理（VRM）との統合
✅ 定期的なセキュリティ評価・ペネトレーションテスト
✅ インシデントレスポンス演習
第7章：なぜ変われないのか ── 組織的障壁の分析
7-1. 「前例踏襲」の罠
よくある思考パターン：
「PPAP でこれまで問題が起きていない」
→ 問題が顕在化していないだけ。漏洩は気づかれないことも多い。
「新しいシステムを評価・承認するのが大変」
→ 旧来の方式のリスクを定量的に評価していない。
新しい方式のリスクとの比較をせずに変化を拒んでいる。
「外部監査で指摘されていない」
→ 監査の指摘事項が技術の進化に追いついていない。
監査基準を守ることが目的化し、実際のリスク軽減が目的ではなくなっている。
「実装が複雑で管理できない」
→ M365 や Google Workspace はゲスト招待を数クリックで実現できる。
「管理できない」は能力の問題ではなく、学習意欲の問題である。
7-2. セキュリティ部門の役割の再定義
旧来のセキュリティ部門の役割：
「禁止する部署」── 何でも「NG」を出すことでリスクを回避しようとする
あるべきセキュリティ部門の役割：
「安全にコラボレーションさせる土台を整える部署」── ビジネスの目的を達成しながら、リスクを技術的に制御する
この転換なしに、真のDXは実現しない。セキュリティ部門がDX推進の最大のブロッカーになっている現状は、経営層が強いリーダーシップを持って変革を推進するしかない。
7-3. 外部パートナーへの影響
企業がPPAP・ファイル転送サービスを強要し続けることは、外部パートナーにとって：
- 生産性の著しい低下： 必要なファイルを都度ダウンロード・再アップロードする非効率
- バージョン管理の崩壊： どのファイルが最新かわからない「メールによるバージョン地獄」
- セキュリティリスクの転嫁： 「渡した後は相手の管理に委ねる」は、実質的にセキュリティリスクを相手に押し付けている
- パートナーとしての評価低下： 先進的な企業からは「DX後進企業」として認識され、優秀なパートナーが離れていく
おわりに ── データは「送る」ものではなく「見せる」もの
企業間データ共有の本質的な問いは、「どうやってファイルを送るか」ではなく、「データをどこに置き、誰に何を・どの条件で見せるか」だ。
Push型・Pull型は「データを相手に渡すこと」が前提であり、渡した瞬間に自社のガバナンスは消滅する。Share型は「データを自社に留めたまま、アクセス権を一時的に貸し出す」ことで、ガバナンスを維持し続ける。
この根本的なパラダイムシフトを：
- 技術的に実現する のが、ゼロトラストアーキテクチャとIDaaS・MFA・条件付きアクセス・DRMの組み合わせであり
- 組織的に実現する のが、セキュリティ部門のマインドセットの転換と、経営層のリーダーシップだ
2026年現在、M365やGoogle Workspaceには、Share型を安全に実装するための技術がすべて揃っている。あとは「やるかやらないか」だけだ。
「前例がそうだったから」という理由でPPAPやファイル転送サービスにしがみつく企業に、真のDXは訪れない。
付録：認証方式クイックリファレンス
| 認証方式 | セキュリティ強度 | フィッシング耐性 | 利便性 | 推奨用途 |
|---|---|---|---|---|
| パスワードのみ | ✗ 低 | ✗ なし | ✅ 高 | 廃止推奨 |
| パスワード + SMS OTP | △ 中 | △ 低 | ✅ 高 | 最低限の MFA |
| パスワード + TOTP（認証アプリ） | ✅ 高 | △ 低 | ✅ 高 | 標準推奨 |
| パスワード + プッシュ通知（番号一致） | ✅ 高 | ✅ 中 | ✅ 高 | 企業標準推奨 |
| パスキー（FIDO2） | ✅✅ 最高 | ✅ 高 | ✅ 高 | 次世代標準 |
| ハードウェアキー（YubiKey等） | ✅✅ 最高 | ✅ 最高 | △ 中 | 高特権アカウント |
| 証明書認証（クライアント証明書） | ✅✅ 最高 | ✅ 高 | △ 低 | システム間通信 |
付録：用語解説
| 用語 | 説明 |
|---|---|
| PPAP | パスワード付きZIPをメール送信し、パスワードを別メールで送る慣習。無意味かつ有害。 |
| MFA | 多要素認証。知識（パスワード）・所持（スマホ等）・生体（指紋等）の複数要素を組み合わせる。 |
| FIDO2 / パスキー | フィッシングに耐性のある次世代認証。公開鍵暗号を使いデバイスに紐づく。 |
| Azure AD B2B | Microsoft が提供する外部ユーザー連携機能。ゲストを自社テナントに招待できる。 |
| 条件付きアクセス | 「誰が・どのデバイスで・どこから・何に」アクセスするかをリアルタイムに評価してアクセス制御するポリシー機能。 |
| DRM / IRM | ファイルに権限情報を埋め込み、閲覧・編集・印刷・コピーなどを制御する技術。 |
| DLP | データ損失防止。機密情報の外部送信を自動検知・ブロックする機能。 |
| SIEM | セキュリティ情報とイベント管理。ログを集約してリアルタイムに脅威を検知する基盤。 |
| PIM | 特権アクセス管理。管理者権限などの高特権アクセスを時間制限付きで付与する仕組み。 |
| ゼロトラスト | 「場所を信頼しない」原則。すべてのアクセスを毎回検証する現代のセキュリティアーキテクチャ。 |
| IdP | Identity Provider（アイデンティティプロバイダー）。認証を担うサービス（Azure AD、Google等）。 |
| フェデレーション | 複数の IdP 間で信頼関係を結び、シングルサインオンを実現する仕組み。SAML、OIDCが代表的。 |
| CASB | Cloud Access Security Broker。クラウドサービスの利用を可視化・制御するセキュリティ機能。 |
Discussion