大企業や金融機関の「ファイル共有ルール」の愚行
大企業や金融機関の「ファイル共有ルール」の愚行
この記事をアップデートした **企業間データ共有の「現状」と「あるべき姿」 **を書きました。
～セキュリティ担当者の陥りがちな思考停止～
「厳格なセキュリティ・ルール」が、実は自社のDXを根本から阻害し、あろうことか「情報漏洩の最大のリスク」を生み出しているという事実に気づいているだろうか。
日本の大企業や金融機関とプロジェクトを進める際、外部のコンサルタントやITエンジニアが必ずと言っていいほど直面する「絶望」がある。自社内ではMicrosoft 365 (M365) やGoogle Workspaceを導入して、モダンな働き方をアピールしておきながら、外部パートナーとの連携になると、突然「石器時代」のルールを強要してくるという矛盾だ。
「専用端末の払い出し」は正解。だが、日常業務まで縛る「思考停止の愚行」
誤解のないように最初に断っておく。金融機関などにおいて、機密性の高い顧客データや本番システム環境を扱う際、Intune（MDM）等で厳格に管理された「専用端末（PC）」を外部パートナーに払い出す運用は、ゼロトラストの観点からも完全に正しい。そこには何の異論もない。
問題は、その厳格な作業に至る前の「提案フェーズ」や「契約関連データのやり取り」、あるいはシステムに直接触れない「コンサルティング業務や資料作成」において、信じがたい愚行が横行している点だ。
専用端末を使うまでもない日常的なドキュメントのやり取りにおいて、未だに根絶されないPPAP（パスワード付きZIPファイルのメール送信）、ファイル転送サービスの盲信、そして「自社テナントへの外部ゲスト招待の原則禁止」がまかり通っている。
これらは情報保護の観点から見て「 論理的にも技術的にも完全に破綻」している。クラウド時代のアクセス管理を全く理解していないセキュリティ担当者が、前例と慣習に流されて作り上げた「 愚の骨頂」である。
愚行1：社内はクラウド、社外は「PPAP」と「ファイル転送サービス」という滑稽な二重基準
「社内ではTeamsを使っていますが、外部共有は禁止なので、提案資料や契約書のドラフトはパスワード付きZIP（PPAP）で送ります」
あるいは、
「規定により、ファイルの受け渡しには指定のファイル転送サービス（Crypt便など）を使ってください」
2020年代も半ばを過ぎて、このようなやり取りが平然と行われている。PPAPが無意味かつ有害（マルウェア検知の阻害など）であることはもはや常識だが、より深刻なのは、情報システム部門が「ファイル転送サービス」を安全だと妄信している点だ。
確かに経路の暗号化や誤送信対策にはなる。しかし、企業が守るべき「データ・ガバナンス」の観点から見れば、これは単なる「データの投げ渡し（放棄）」に過ぎない。
ファイル転送サービスを通じてパートナーにファイルを送信し、相手がダウンロードした瞬間、そのデータは御社の管理下から完全に外れる。相手のローカルPCに保存されたデータが、USBメモリにコピーされようが、個人のクラウドストレージにアップロードされようが、御社には知る由もない。「渡した後は、相手の善意と管理体制を信じるしかない」という、およそセキュリティとは呼べないお粗末な状態に自ら陥っているのである。
愚行2：「他社への参加はOK、自社への招待はNG」という謎の逆転現象
さらに滑稽なのが、クラウド環境における「ゲスト権限」の扱いの矛盾だ。多くの大企業では、以下のようなルールが敷かれている。
- 原則として、自社のM365等に外部パートナーをゲスト招待することは禁止（または極めて困難な稟議が必要）。
- 一方で、自社の従業員が「外部パートナーの環境（他社テナント）」へゲスト参加することは比較的容易に許可される。
少しでも情報セキュリティの知識があれば、このルールがいかに「自社ガバナンスの完全な崩壊」を意味しているか気づくはずだ。
他社テナントへの参加を許可するということは、自社の従業員が「他社の管理下にあるプラットフォーム」で作業し、そこに自社の機密情報を書き込むリスクを容認しているということだ。そこでは、自社の情報システム部門はアクセスログを一切追えず、データのダウンロード制限もかけられない。
逆に、自社テナントへパートナーを招待（ゲスト参加）させた場合、御社のルールで強力なガバナンスを効かせることができる。
- 誰が、いつ、どのファイルにアクセスしたか、すべて「自社の監査ログ」に残る。
- 閲覧のみを許可し、ダウンロードや印刷、画面キャプチャを禁止する（Microsoft Purview Information Protectionなどの最新DLP/DRM技術）設定が可能である。
- プロジェクトが終了した瞬間、ゲスト・アカウントを無効化すれば、物理的にファイルが相手の手元に残ることは絶対にない。
「自社テナントへの招待」の方が、「他社テナントへの参加」や「ファイル転送」よりも圧倒的にガバナンスが効き、セキュリティリスクが低いのである。にもかかわらず、「自社環境に部外者を入れるのは危険だ」という、物理的な「境界防御モデル」の古いパラダイムから抜け出せないセキュリティ担当者が、この最も理にかなった安全なアプローチを禁止しているのだ。
真のセキュリティは「ファイルを送る」から「アクセスさせる」への転換
データを最も安全に管理する方法、それは「 データを移動させないこと 」である。「ファイルを送る（コピーを相手に渡す）」という行為そのものが、情報漏洩の最大のリスクを生む。現代のクラウド環境において最も正解となる運用は以下の通りだ。
- 自社のクラウド環境に、外部パートナーをゲスト招待する。
- 最小特権の原則に基づき、必要なフォルダにのみ権限を付与する。
- 多要素認証（MFA）の強制や「特定のデバイス・場所からのみアクセスを許可する」といった条件付きアクセス制御など、自社の強固なセキュリティポリシーをゲストにも適用する。
ファイルは常に自社の強固な「金庫（クラウド）」の中にあり、パートナーには「金庫の中を見るための一時的な鍵」を渡すだけ。これこそが、ゼロトラスト・アーキテクチャの基本である。
思考停止の「前例踏襲」は企業を滅ぼす
自社テナントへのゲスト招待を禁じ、未だにファイルを「送信」して相手にデータを明け渡している大企業や金融機関のルールは、セキュリティの名を借りた「リスクの放置」に他ならない。
M365やGoogle Workspaceの環境では多要素認証に対応した、高度な認証やアクセス制御機能がすでに存在している。それを利用せず、旧態依然としたPPAPやファイル転送サービスにしがみついているのは、「 セキュリティ担当者の技術的理解力が低く、新しい仕組みを評価・運用設計する能力（または気力）がないから 」である。
形骸化したルールを守ることで「仕事をした気」になっているセキュリティ部門は、自社のDX推進の最大のブロッカーであり、かえって情報漏洩のリスクを高めている。経営層は今すぐ自社の情報共有ルールを見直し、「送る」から「アクセスさせる」へのパラダイムシフトを強力に推し進めるべきである。思考停止の前例踏襲を続ける企業に、真のデジタルトランスフォーメーションは決して訪れない。
皆さんの異論・反論などがあればぜひお聞かせください。
Discussion
タイトルが壮大だったので興味を持って読み始めたのですが、
読み進めるうちに、この記事が「提言」なのか「個人的な感想」なのかが少し曖昧に感じられました。
以前ならデータの受け渡しは Push／Pull の二つで完結していましたが、
最近は同じデータを複数人で編集する Share（共同編集） という第３の方式も一般的になっています。
そして方式が違えば、必要になる“認証の仕組み”も変わります。
特に Pull 型（相手が取りに来る方式）は、
**「取りに来ていい人をどう判定するか」**が安全性の中心になります。
この記事では、この三つの方式の違いや、
Pull 型で本来必要になる認証の話が整理されないまま
「取りに来させる方が安全」という結論に向かっているように見え、
タイトルの大きさに対して中身が少し追いついていない印象を受けました。
方式の話と認証の話は本来切り分けて考えるべきですが、
実際にはこの二つは密接に絡み合っていて、完全に分離することは難しいテーマだと思います。
たとえば、公開鍵暗号方式を絡めたりしたらどうでしょうかね。
使い方によって暗号化にも電子署名にもなります。
だからこそ、方式と認証の関係を整理したうえで提言されると、
より説得力のある内容になるのではないかと感じました。
詳細で論理的なコメントありがとうございます。
ご指摘いただいた、Push / Pull / Share の整理や、Pull型における「取りに来ていい人をどう判定するか（認証）」の重要性については同意します。データ共有方式と認証を切り離せないという点や、公開鍵暗号方式などを活用した技術的なアプローチは、システムを安全に設計する上で欠かせない本質的な視点ですね。
一方で、今回の記事で私が主眼としてお伝えしたかったのは、技術的なアーキテクチャの最適解というよりも、大企業や金融機関などで見られる「ルールや運用ポリシーの硬直化・形骸化」に対する問題提起 でした。
「とにかくデータを送ってしまえば（Pushすれば）自分たちの責任範囲から外れる」といった業務上の慣習や、本質的な安全性を欠いたまま踏襲されている大企業のルールに対して一石を投じたいという思いがあります。そのため、技術的な認証メカニズムの整理という点では踏み込みが浅く、タイトルの大きさに対して中身が個人的な感想にとどまっているという印象を与えてしまった点については、指摘の通りかと思います。
ただ、実運用を本当に安全で機能するものにするためには、私が触れた「組織のポリシーやルールの見直し」と、コメントでいただいたような「適切な暗号化や認証技術の実装」の両輪が不可欠だと改めて気付かされました。
貴重な視点を共有していただき、本当にありがとうございます。
ご返信ありがとうございます。
「大企業や金融機関でのルールの硬直化」という問題提起はよく分かりますし、実際にそうした現場が存在するのも確かだと思います。
一方で、私の周囲の例で言うと、
PPAPについてはむしろ大企業のほうが廃止に動いている印象があり、
請求書に関しても「サイトへ取りに行く」Pull 型の運用が増えてきています。
逆に、中小企業のほうが PPAP を続けていたり、
請求書ではありませんが、場合によっては暗号化すらせず PDF をそのまま送ってくるケースもあります。
そう考えると、
「大企業・金融機関」という枠に限定するよりも、
旧態依然とした仕組みや慣習全般に対する問題提起
として語ったほうが、より多くの読者に届くのではないかと感じました。
（タイトルにつられた私が言うのもなんですが……）
誰かが一石を投じなければ波紋は起こらないし、広がりません。
今回の一石が次につながることを期待しています。
追加のコメントありがとうございます。おっしゃる通り、大企業を中心にPPAPが廃止され、「Pull型」の運用へ移行しているというのは現場のリアルな実感として深く頷けます。
その上で、本記事のメインテーマである「真のセキュリティ」について1点補足させてください。
記事で意図した「『ファイルを送る』から『アクセスさせる』への転換」は、転送手段（PPAP vs Pull型）の比較ではなく、「データのコピーを相手のローカル環境に渡すこと」自体からの脱却です。Pull型は確かに進歩ですが、ダウンロード（複製）される以上、事後の権限剥奪や追跡が困難であり、本質的には「ファイルを渡している」ことになります。
実際、ベンチャー企業ではSharePointやGoogle Driveで「ファイル転送なしの直接アクセス」が普及しつつあります。しかし、大企業や金融機関ではルールの制約上、厳密なパートナー以外へのアクセス許可が難しいというのも仰る通りの課題ですね。
目指すべきはクラウド上で「必要な時に必要な権限だけを付与する」仕組みであり、私の書き方でそのニュアンスが少し伝わりづらかったかもしれません。
今回のやり取りを通じて、転送手段の改善と、根本的なアクセス権限の転換の違いについて議論を深めることができました。貴重な視点をありがとうございます！
この記事をアップデートした 企業間データ共有の「現状」と「あるべき姿」を書きました。