本文へスキップ
株式会社オープンナレッジ
株式会社オープンナレッジ Open Knowledge Inc.
Cloud Storage Security:Access Control & Capability URLs 執筆:株式会社オープンナレッジ 技術調査・編集室(監修:加藤 明生)

クラウド共有フォルダの「リンクを知っている全員が閲覧可能」設定による情報漏洩と、 安全なファイル受け渡し設計

対象:経営者様・営業事務スタッフ様・取引先とクラウドで図面や請求書をやり取りするすべての方 / 読了目安:約5分

1. 基本と全体像

この記事の要点と4つの章のご案内

身近なたとえで見る仕組み:「合鍵の番号が書かれた紙」を街中で配る危険性に関するイメージ写真
身近なたとえで見る仕組み:「合鍵の番号が書かれた紙」を街中で配る危険性
構造図解:「誰でも開ける無期限リンク」と「本人確認+期限付き受け渡しボックス」の違いに関するイメージ写真
構造図解:「誰でも開ける無期限リンク」と「本人確認+期限付き受け渡しボックス」の違い
クラウド共有フォルダの「リンクを知っている全員が閲覧可能」設定による情報漏洩と、 安全なファイル受け渡し設計 の各章におけるテーマと要点一覧表
章構成 主なテーマ 要点と確認ポイント
1. 基本と全体像 身近なたとえで見る仕組み:「合鍵の番号が書かれた紙」を街中で配る危険性 GoogleドライブやOneDriveの「リンクを知っている全員が閲覧可能」は、メールの誤送信・転送・退職者の持ち出し・チャット履歴の流出が起きた瞬間、世界中の誰でも認証なしで開ける「無施錠の私書箱」に変わります。
2. 現場での進め方と対策 構造図解:「誰でも開ける無期限リンク」と「本人確認+期限付き受け渡しボックス」の違い さらに危険なのは、個別のファイルではなく「親フォルダごと公開リンクを発行してしまうミス」です。数年後に別件でそのフォルダへ入れた顧客名簿や見積書まで、自動的に外部へ公開され続けます。
3. 関連する制度とルール 現場で陥りやすい落とし穴と回避策 安全にファイルを受け渡すには、「01 相手のメールアドレスを名指しで指定する」「02 閲覧期限(7日間など)とダウンロード制限を必ず付ける」「03 受け渡し専用の一時フォルダを使い、完了後に空にする」の3原則を順守します。
4. 詳しい技術仕様としくみ 理解を深める確認クイズ かつて日本のビジネス現場では、メールに「パスワード付きZIPファイル」を添付し、すぐ後のメールで「パスワードをお知らせします」と送る習慣(いわゆるPPAP)が広く使われていました。しかし、同じ経路で鍵と箱を送っても盗聴対策にならず、しかもウイルス検査をすり抜けてしまうため、現在では官公庁や大手企業を中心に廃止されています。
第1章〜第4章では、実務チェックリスト・公的制度基準・詳しい技術仕様を確認できます。
この記事のポイント
  • 01. GoogleドライブやOneDriveの「リンクを知っている全員が閲覧可能」は、メールの誤送信・転送・退職者の持ち出し・チャット履歴の流出が起きた瞬間、世界中の誰でも認証なしで開ける「無施錠の私書箱」に変わります。
  • 02. さらに危険なのは、個別のファイルではなく「親フォルダごと公開リンクを発行してしまうミス」です。数年後に別件でそのフォルダへ入れた顧客名簿や見積書まで、自動的に外部へ公開され続けます。
  • 03. 安全にファイルを受け渡すには、「01 相手のメールアドレスを名指しで指定する」「02 閲覧期限(7日間など)とダウンロード制限を必ず付ける」「03 受け渡し専用の一時フォルダを使い、完了後に空にする」の3原則を順守します。
第1章:仕組みと構造図解

01. 身近なたとえで見る仕組み:「合鍵の番号が書かれた紙」を街中で配る危険性

かつて日本のビジネス現場では、メールに「パスワード付きZIPファイル」を添付し、すぐ後のメールで「パスワードをお知らせします」と送る習慣(いわゆるPPAP)が広く使われていました。しかし、同じ経路で鍵と箱を送っても盗聴対策にならず、しかもウイルス検査をすり抜けてしまうため、現在では官公庁や大手企業を中心に廃止されています。

その代わりとして急速に広まったのが、Googleドライブ、Microsoft OneDrive、Box、Dropboxなどの「クラウドストレージの共有リンク」をメールやチャットで送る方法です。ところが、この移行に伴って全国で急増しているのが、「リンクを知っている全員が閲覧(または編集)可能」という設定による重大な情報漏洩事故です。

これを身近な暮らしにたとえると、「身分証の確認を一切せず、暗証番号が書かれた紙切れ(URLリンク)を持っている人なら、誰でも・何年後でも・何回でも入れる貸金庫」を作ってしまうようなものです。最初は取引先のAさんだけに渡したつもりでも、次のような経路でそのリンクは簡単に社外へ広まってしまいます。

「リンクを知っている全員」設定から情報が漏れる3つの経路

経路 01(メールの転送・CC追加による拡散): 受け取った取引先が「この資料、外部の協力会社にも見せておこう」とメールをそのまま転送した瞬間、あなたが知らない第三者も中身を自由にダウンロードできるようになります。

経路 02(退職者や委託終了後の永久アクセス): 有効期限を設定していない共有リンクは、1年後も3年後も生き続けます。退職した元社員や契約が終了した外注先が、自分のスマホにブックマークしていたリンクから最新の社内資料を見続けることができてしまいます。

経路 03(親フォルダ公開による「後から入れた機密書類」の連鎖流出): 1つのファイルではなく「取引先共有フォルダ」全体に公開リンクを設定してしまうと、半年後にうっかりそのフォルダの下に保存した「全社顧客リスト」や「他社の見積書」まで、自動的に公開状態になってしまいます。

漏洩原因の上位
設定ミス・誤公開が多発

個人情報保護委員会への漏洩報告において、高度なハッキングだけでなく「クラウドサービスの設定不備・権限設定ミス」による大量漏洩が毎年多数報告されています。

放置リンクの寿命
無期限(手動停止まで)

有効期限を設定せずに発行された共有リンクは、ファイルが存在する限り何年間も有効なまま残り続け、発覚するまで平均数百日以上放置される傾向があります。

推奨される有効期限
最大 7日間(自動失効)

業務上のファイル受け渡しリンクに「3日〜7日間の自動失効期限」と「受取人本人認証」を付与するだけで、過去の共有リンク放置による漏洩リスクを99%以上遮断できます。

02. 構造図解:「誰でも開ける無期限リンク」と「本人確認+期限付き受け渡しボックス」の違い

普段何気なくクリックしている「共有」ボタンの設定ひとつで、情報の安全性がどれほど変わるのかを図で確認してみましょう。

危険な共有方法:社内作業フォルダのまま「リンクを知っている全員が閲覧可(無期限)」で送る 01 親フォルダごと公開リンク作成 「相手のログインが面倒だから」と 全員閲覧OK・期限なしでURL発行 02 URLがメール転送・履歴に残存 誤送信先・再委託先・退職者の端末へ URLがコピーされ誰が持ったか不明に 03 後日入れた別顧客のデータまで流出 半年後に同じフォルダへ保存した名簿や 図面が認証なしで外部から丸見えに 安全な共有方法:「受け渡し専用の一時ボックス」+「宛先メールアドレス認証」+「7日間自動失効」 手順 01:受け渡し専用フォルダへ分離 社内原本フォルダは原則として共有せず、 渡す1ファイルだけを一時領域へコピー 効果:他ファイルの巻き添え漏洩ゼロ 手順 02:相手メールアドレスの明示指定 「特定のユーザーのみ」を選び、相手の アドレス宛にワンタイム確認コードを要求 効果:万一URLが転送されても第三者は開けない 手順 03:有効期限(7日)と監査ログ 7日後にリンクが自動消滅する設定を標準化 誰がいつダウンロードしたか記録を残す 効果:過去の放置リンクからの漏洩を根絶
第2章:Practical Field Guide & Self-Check

03. 現場で陥りやすい落とし穴と回避策

実際の業務現場で「うっかり情報漏洩」を引き起こしやすい3つの場面と、誰でも迷わず安全に運用できる具体的な工夫をご紹介します。

「取引先がGoogleアカウントを持っていないから」と全員公開にしてしまう

現場の悩み:「相手のメールアドレスを指定して共有したら、『ログイン画面が出て見られません』と言われてしまい、仕方なく全員閲覧可能に変えた」

回避策: Google Workspace(法人版ドライブ)やMicrosoft OneDrive / SharePointには、相手がアカウントを持っていなくても、「指定したメールアドレス宛に届く6桁の確認コード(ワンタイムパスコード)を入力するだけで安全に閲覧できるゲスト共有機能(ビジター共有)」が備わっています。管理画面でこの機能を有効にしておけば、相手にアカウント作成の手間をかけずに「指定した本人しか開けない共有」が簡単に実現できます。

スプレッドシートやExcelの「別シート・非表示行」に他社情報が残っている

現場の悩み:「A社様向けの見積もりシートを共有したつもりが、同じファイルの別タブや非表示の列にB社・C社の単価一覧が残っていた」

回避策: Excelやスプレッドシートで「行やシートを非表示」にしても、共有された相手がファイルをコピーしたりダウンロードしたりすれば、1クリックで非表示を解除してすべて読めてしまいます。社外へ渡す書類は、相手が共同編集する必要がある場合を除き、「必要なページだけをPDFとして書き出したファイル」にしてから共有する習慣をつけるだけで、裏データの流出を確実に防げます。

個人の無料クラウドアカウント(野良クラウド)での業務ファイル共有

現場の悩み:「会社のファイルサーバーが使いにくいので、社員が自分の個人Googleアカウントや無料ファイル転送サイトを使って顧客へ図面を送っている」

回避策: 個人アカウントや広告付きの無料転送サイトを使うと、会社側で「どのファイルが誰に公開されているか」を把握できず、その社員が退職した後も個人のクラウド上に会社の機密データが残り続けてしまいます。必ず会社管理の法人アカウントを用意し、管理者設定で「デフォルトの共有範囲=社内のみ(外部共有時は期限必須)」に固定しましょう。

Interactive Self-Check:Cloud Sharing Hygiene

クラウド共有のうっかり漏洩を防ぐ「3つの安全設定」チェックリスト

現在お使いのGoogleドライブ・OneDrive・Box等の設定を思い浮かべながら、3つの項目を点検してみてください。

現在 0 / 3 項目を確認済みです。クリックして自社の共有ルールを点検してみましょう。 クラウド設定診断へ →

04. 理解を深める確認クイズ

質問:取引先の担当者(1名)に、機密性の高い「新製品の設計図面PDF」をクラウドストレージ経由で送る場合、最も安全で適切な手順はどれでしょうか?

選択肢 A:社内の「設計図面マスターフォルダ」ごと『リンクを知っている全員が編集可能』に設定し、URLをメールで送る 解説を見る ↓

最も危険な方法です。
マスターフォルダごと全員公開にすると、他の取引先の図面まで見られてしまうだけでなく、「編集可能」にしているため相手側が誤ってファイルを削除・上書きしてしまう事故にもつながります。

選択肢 B:受け渡し専用フォルダに対象PDFだけを置き、「取引先担当者のメールアドレスのみ閲覧可」+「7日間の有効期限」を設定して送る 解説を見る ↓

正解です。これが情報漏洩を構造的に防ぐベストプラクティスです。
仮にメールが誤転送されても指定したメールアドレス本人以外は開けず、7日後には自動的にリンクが失効するため、将来の放置リスクもゼロになります。

選択肢 C:ファイルを4桁の数字パスワード付きZIPに圧縮してメール添付し、同じ宛先へ1分後にパスワードを別メールで送る 解説を見る ↓

いわゆる「PPAP」と呼ばれる古い方式であり、現在は推奨されません。
1通目のメールが誤送信された場合、2通目のパスワードメールも同じ相手へ届いてしまうため誤送信対策にならず、また4桁程度のZIPパスワードは数秒で解読されてしまいます。

関連コラム・豆知識

ホテルの「カードキー」がチェックアウト時刻に自動で止まる理由

現代のホテルの客室カードキーは、宿泊客がチェックアウトする日時の午前11時を過ぎると、自動的に磁気やICのデータが失効してドアが開かなくなるようプログラムされています。もし宿泊客がうっかりカードキーをポケットに入れたまま持ち帰ってしまったとしても、次の宿泊客の安全が脅かされることはありません。クラウドでのファイル共有もこれと同じで、「最初から失効日時(チェックアウト時刻)を決めて発行する」仕組みにしておくだけで、人間がいちいち手動で鍵を回収し忘れるミスを100%カバーできるのです。

Google Workspace / Microsoft 365 の共有権限を総点検しませんか?

外部公開中ファイルの棚卸しと安全な受け渡しルール設計の個別相談・設定確認

クラウド設定診断を申し込む →
場面別の実務確認ポイント
経営者・管理部門責任者の方へ

なぜ「ウイルス感染」ではなく「日々のちょっとした共有設定ミス」で何万件もの個人情報漏洩が起きているのか、会社の信用を守るルール作りを基本構造として整理しています。

営業・事務・制作スタッフの方へ

取引先から「パスワード付きZIPメール(PPAP)は送らないで」と言われたとき、代わりにどう設定すれば相手に手間をかけず安全にファイルを渡せるかを「第2章」で具体的に紹介します。

Web・クラウド設計技術者の方へ

Capability URLのエントロピー境界、Referer/ブラウザ履歴からの漏洩経路、HMAC-SHA256署名付きURL(Pre-Signed URL)の数理、およびRustによるACL自動監査実装を「第3章」で詳解します。

技術仕様・実装解説(CAPABILITY URLS & HMAC-SHA256 PRE-SIGNED ACL) 4. 詳しい技術仕様としくみ
Rust 2024(Zero-Standing-Privilege Object Sharing)

無記名Capability URLの漏洩確率モデル、HMAC-SHA256期限付き署名URL(Pre-Signed URL)と封筒暗号化(Envelope Encryption)、およびRust 2024アクセス制御検証器

本モノグラフでは、クラウドストレージにおける「リンクを知っている全員(Bearer Capability URL)」設定が、トークン空間のエントロピー不足ではなく「検証主体(Subject Principal)の欠落と無期限性」によって破綻するメカニズムを定式化する。さらに、時刻・受取人ID・クライアントIP・オブジェクトSHA-256ダイジェストを束縛した HMAC-SHA256 Pre-Signed URL 仕様と、Rust 2024 によるクラウド共有ポリシー監査・署名検証器を提示する。

Access Control Model
Principal-Bound Capability + TTL
MAC Construction
HMAC-SHA256 (RFC 2104 / Constant-Time)
Payload Confidentiality
AES-256-GCM Envelope Encryption
Standing Exposure
0 sec Post-TTL (Auto-Revoked)
1. 設計仕様・数理モデル(Exposure Surface Formulation & Principal-Bound Pre-Signed URL Construction)

1. 無記名 Capability URL(Anyone with the link)の時間積分リスク数理:
W3C Capability URL パターンにおいて、URL 文字列自体に十分なランダムエントロピー(例:Base64URL 33文字 ≈ 198 bits)が含まれていれば、外部からの単純な総当たり推測確率は 2^-198 と無視できる。しかし現実の漏洩は推測(Brute-force)ではなく、HTTP `Referer` ヘッダ漏洩、メール転送・メーリングリストアーカイブ、ブラウザ履歴同期、退職者のローカルログ、およびディレクトリ継承(親フォルダ共有 F_parent に対する子オブジェクト o_i ∈ F_parent の暗黙公開)によって発生する。共有リンクの生存期間を T、単位時間あたりのリンク拡散ハザード率を λ(t)、フォルダ内の機密オブジェクト数を N(t) とすると、累積漏洩期待値 R(T) は次式で単調増大する: R(T) = ∫_0^T N(t) · (1 - exp(-∫_0^t λ(τ) dτ)) dt 無期限共有(T → ∞)かつ親フォルダ共有(N(t) が時間とともに増加)の場合、R(T) は発散し、情報漏洩は確率ではなく時間の問題となる。

2. プリンシパル束縛・期限付き HMAC-SHA256 署名(Canonical Request Signing):
URL 文字列単体での無記名アクセスを禁止し、受取人プリンシパル識別子 sub(OIDC Subject または検証済みメールアドレスハッシュ)、オブジェクト識別子 oid、コンテンツハッシュ H(payload)、有効期限エポック秒 t_exp、および最大ダウンロード回数 c_max を正規化文字列(Canonical String)として結合し、サーバー秘密鍵 K_mac で HMAC-SHA256 タグ σ を生成する: σ = HMAC-SHA256(K_mac, oid ∥ sub ∥ t_exp ∥ c_max ∥ SHA256(payload)) 認可ゲートウェイはリクエスト受信時に、(i) 定数時間比較 ct_eq(σ, σ') == 1、(ii) 現在時刻 t_now ≤ t_exp、(iii) セッション認証済み主体 caller_sub == sub、および (iv) 累積取得回数 c < c_max の4条件がすべて成立した場合にのみオブジェクトストリームを返却する。

3. 親フォルダACL継承遮断(Non-Inheritable Isolated Drop-Box):
ファイルシステムおよびクラウドストレージのディレクトリ木 G = (V, E) において、内部保管ノード v_internal ∈ V_corp には `external_share_allowed = false` 不変制約を課し、外部共有は単一ファイル単位かつ有効期限 T ≤ 7 days が強制された隔離バケット V_dropoff でのみ許可することで、ディレクトリ継承による連鎖漏洩を構造的に消滅させる。

2. パラメータ・構成仕様(File Sharing Architecture Security Comparison Matrix)
Sharing Method Recipient Identity Proof Revocation & TTL Gateway Malware Scan
Legacy PPAP (Encrypted ZIP via SMTP) None (Same SMTP path) Impossible once sent Bypasses Email AV Scanner
Cloud "Anyone with the link" None (Bearer URL only) Often Infinite / Forgotten Scanned on Cloud Upload
Named Guest OTP + 7-Day TTL Email OTP / OIDC Subject Auto-Expires in <= 168h Full Sandboxed Scan + Audit Log
Principal-Bound Pre-Signed URL Cryptographic HMAC + Session Strict Epoch TTL & Max Count SHA-256 Digest Verified
3. 実装コード・設定仕様(Executable Specification (crates/ok-cloud-acl/src/share_policy_verifier.rs)) Rust 2024(Cloud Share Policy Auditor & Constant-Time Token Verifier)
#![forbid(unsafe_code)]

/// Maximum permitted lifetime for external file sharing links (7 days in seconds).
pub const MAX_EXTERNAL_SHARE_TTL_SECS: u64 = 7 * 24 * 3600;

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum ShareScope {
    InternalOnly,
    SpecificVerifiedPrincipals,
    AnyoneWithLinkBearer,
}

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum ResourceKind {
    SingleFileObject,
    DirectoryContainer,
}

#[derive(Debug, Clone)]
pub struct SharePolicyEntry {
    pub object_id: u64,
    pub kind: ResourceKind,
    pub scope: ShareScope,
    pub created_at_epoch: u64,
    pub expires_at_epoch: Option<u64>,
    pub allow_editor_write: bool,
    pub recipient_principal_hash: Option<[u8; 32]>,
}

#[derive(Debug, Clone, PartialEq, Eq)]
pub enum PolicyViolation {
    PublicBearerLinkForbidden { object_id: u64 },
    DirectoryLevelExternalShareForbidden { object_id: u64 },
    MissingOrExcessiveExpiration { object_id: u64 },
    ExternalWritePermissionRisk { object_id: u64 },
    MissingRecipientBinding { object_id: u64 },
}

/// Audits a cloud storage sharing entry against zero-leakage corporate governance rules.
pub fn audit_share_policy(entry: &SharePolicyEntry) -> Vec<PolicyViolation> {
    let mut violations = Vec::new();

    if entry.scope == ShareScope::InternalOnly {
        return violations;
    }

    // 1. "Anyone with the link" bearer access is strictly prohibited
    if entry.scope == ShareScope::AnyoneWithLinkBearer {
        violations.push(PolicyViolation::PublicBearerLinkForbidden {
            object_id: entry.object_id,
        });
    }

    // 2. Directories must never be shared externally (prevents future child object leakage)
    if entry.kind == ResourceKind::DirectoryContainer {
        violations.push(PolicyViolation::DirectoryLevelExternalShareForbidden {
            object_id: entry.object_id,
        });
    }

    // 3. Enforce strict TTL bound (<= 7 days)
    match entry.expires_at_epoch {
        None => violations.push(PolicyViolation::MissingOrExcessiveExpiration {
            object_id: entry.object_id,
        }),
        Some(exp) => {
            let ttl = exp.saturating_sub(entry.created_at_epoch);
            if ttl == 0 || ttl > MAX_EXTERNAL_SHARE_TTL_SECS {
                violations.push(PolicyViolation::MissingOrExcessiveExpiration {
                    object_id: entry.object_id,
                });
            }
        }
    }

    // 4. External shares should be read-only by default and bound to a verified recipient
    if entry.allow_editor_write {
        violations.push(PolicyViolation::ExternalWritePermissionRisk {
            object_id: entry.object_id,
        });
    }
    if entry.recipient_principal_hash.is_none() {
        violations.push(PolicyViolation::MissingRecipientBinding {
            object_id: entry.object_id,
        });
    }

    violations
}

/// Constant-time 32-byte digest comparison to prevent timing side-channel leaks.
#[inline]
pub fn constant_time_eq_32(a: &[u8; 32], b: &[u8; 32]) -> bool {
    let mut diff: u8 = 0;
    for i in 0..32 {
        diff |= a[i] ^ b[i];
    }
    diff == 0
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn rejects_unbounded_directory_bearer_link() {
        let bad_entry = SharePolicyEntry {
            object_id: 42,
            kind: ResourceKind::DirectoryContainer,
            scope: ShareScope::AnyoneWithLinkBearer,
            created_at_epoch: 1_700_000_000,
            expires_at_epoch: None,
            allow_editor_write: true,
            recipient_principal_hash: None,
        };
        let issues = audit_share_policy(&bad_entry);
        assert_eq!(issues.len(), 5);
    }
}
検証環境・運用について: 当社ではGoogle Workspace / Microsoft 365 の共有ポリシー自動監査と、取引先が迷わず安全に使える期限付きファイル受け渡し基盤の導入を支援しています。
クラウド共有監査・設計のお問い合わせ
ご質問・公的制度の活用に関するお問い合わせ窓口

掲載資料に関するご質問・公的制度活用のご案内

本ページの図解や解説内容に関するご質問、経済産業省「SCS評価制度」やIPA「SECURITY ACTION・サイバーセキュリティお助け隊サービス」等の公的制度の確認方法について、落ち着いた参考窓口としてご案内しております。売り込みや営業連絡は一切行いませんので、社内勉強会やご家庭での確認資料としてご自由にご活用ください。

図解・ビジュアルの拡大表示

図表内のテキストもそのまま選択・検索可能です(ベクターSVG描画) 枠外クリックまたは ESC キーで閉じます