GlobaLeaksとは何か
GlobaLeaksを組織や通報窓口の設計に関わる仕組みとして位置づけ、利用者側の注意点も整理します。
GlobaLeaksは、匿名通報や情報提供の窓口を作るためのオープンソース基盤です。
報道機関だけでなく、NGO、企業、公共機関、監査・コンプライアンス窓口などで使われることがあります。内部告発や公益通報の受付を、一度きりの送信フォームではなく、担当者管理や返信を含む継続的な窓口として運用しやすい点が紹介する理由です。
URL : https://globaleaks.org/
この記事では、GlobaLeaksを「安全な通報フォーム」という一言で済ませず、利用者側と運用者側の両方から整理します。
GlobaLeaksの基本
GlobaLeaksは、情報提供者が窓口にアクセスし、メッセージや資料を送るための仕組みです。
受け取り側は、通報内容を確認し、担当者や案件管理の流れを設計します。組織が内部通報制度や公益通報窓口を作るときの基盤として使われることがあります。
| 立場 | 役割 |
|---|---|
| 通報者 | 窓口にアクセスし、情報や資料を送る |
| 運用組織 | 窓口を設置し、受け取り方や担当者を決める |
| 担当者 | 通報内容を確認し、必要な対応を行う |
| GlobaLeaks | 通報受付のためのシステム基盤になる |
GlobaLeaksは、通報フローを作るための道具です。
運用組織がどう設定し、どう扱うかが重要になります。
ここで重要なのは、GlobaLeaksが匿名性を自動的に完成させる箱ではないことです。 通報受付の仕組みを整える基盤であり、実際の安全性は運用に左右されます。 誰が管理するのか、誰が通報を読めるのか、ログをどう扱うのか、通報者へどう返信するのかが重要です。
通報者側も、職場端末や業務ネットワークからアクセスすれば別の痕跡が残ります。 窓口が匿名性を意識していても、利用者の環境までは自動で守りません。
SecureDropとの違い
SecureDropは報道機関の情報提供窓口として語られることが多く、GlobaLeaksは通報受付や組織的な窓口の文脈で使われることが多いです。
| 項目 | GlobaLeaks | SecureDrop |
|---|---|---|
| 主な文脈 | 内部通報、公益通報、組織窓口 | 報道機関への情報提供 |
| 運用者 | 企業、NGO、公共機関、団体など | 報道機関、NGOなど |
| 強い点 | 通報フローや担当者管理 | 取材源保護を意識した情報提供 |
| 注意点 | 運用組織への信頼が重要 | 受け入れ側の専門運用が重要 |
どちらが常に優れているという話ではありません。
用途と運用体制で選ばれます。
SecureDropについては、報道機関への情報提供や取材源保護の文脈で別の記事でも扱います。 GlobaLeaksは、企業や団体、公共機関などが通報受付の流れを作る場面でも使われます。 そのため、比較するときは機能名だけでなく、運用者と目的を見ます。
読者が使う側なら、窓口の運用主体を確認します。 設置する側なら、技術導入だけでなく、通報者保護の運用を設計します。
通報者側の注意点
GlobaLeaksの窓口を使う場合でも、通報者側の注意点は残ります。
職場端末、実名アカウント、業務ネットワーク、付きファイルを使えば、別の経路から身元が分かることがあります。
| 注意点 | 理由 |
|---|---|
| アクセスする環境 | 職場端末や業務ネットワークはログが残る |
| 提出するファイル | 作成者、組織名、編集履歴が残る |
| 通報内容 | 情報を知る人が少ないと候補が絞られる |
| 送信時刻 | 内部イベントやアクセスログと照合される |
| 返信確認 | 継続的なやり取りにも痕跡が残る |
窓口が匿名性を意識していても、通報者の環境まで自動で守るわけではありません。
通報内容も重要です。 名前を書かなくても、どの資料を見たか、どの会議を知っているか、どの時刻に送ったかで候補が絞られます。 資料に作成者情報、組織名、変更履歴、文書番号、透かしが残っていれば、提出経路とは別に出どころが見えます。
通報前には、本文、添付ファイル、送信環境、送信時刻を確認します。 高リスクな内部告発では、記事だけで判断せず、信頼できる相談先を検討します。
運用者側の責任
GlobaLeaksを設置する側には、強い責任があります。
通報者に何を記録するのかを説明する。誰が閲覧できるかを制限する。資料を安全に扱う。通報者を不用意に特定しない。通報後の対応で報復につながる情報を漏らさない。
| 運用項目 | 理由 |
|---|---|
| アクセス権限 | 通報内容を見られる人を限定する |
| ログ方針 | 何を記録するかを明確にする |
| 資料管理 | ファイルやメタデータを慎重に扱う |
| 連絡方法 | 返信や追加質問で通報者を危険にしない |
| 説明責任 | 通報者にリスクと扱いを伝える |
匿名通報窓口は、設置するだけでは意味がありません。
運用が雑なら、通報者を危険にします。
運用者は、通報者に分かりやすい説明を用意します。 どの情報を記録するのか。 誰が通報を読めるのか。 返信はどのように行うのか。 添付ファイルのメタデータはどう扱うのか。 報復を防ぐためにどの手順を取るのか。
また、担当者が不用意に通報者を特定しようとしない設計も必要です。 通報内容を調査する過程で、組織内に情報を広げすぎると、通報者が疑われます。 技術基盤と運用ルールをセットで考えます。
導入前に確認すること
GlobaLeaksを導入する側は、設置前に運用を決めます。
| 確認すること | 理由 |
|---|---|
| 運用主体 | 誰が責任を持つかを明確にする |
| アクセス権限 | 通報内容を見られる人を制限する |
| ログ方針 | 何を記録し、何を記録しないかを決める |
| 添付ファイル管理 | メタデータや証拠性を扱うため |
| 返信ルール | 追加質問で通報者を危険にしないため |
導入後も、担当者教育、権限管理、監査、通報者への説明を続ける必要があります。 通報窓口は、作って終わりではありません。
窓口を見直す
GlobaLeaksのような通報窓口は、運用しながら見直します。 担当者が増えすぎていないか。 古いアカウントが残っていないか。 通報者への説明が分かりにくくないか。 添付ファイルのメタデータ確認が運用に入っているか。 返信で通報者を危険にしていないか。
匿名通報窓口は、技術よりも継続運用で差が出ます。 定期的に権限、ログ、説明文、資料管理、対応手順を確認します。
まとめ
GlobaLeaksは、匿名通報や情報提供の窓口を作るためのオープンソース基盤です。
GlobaLeaksを検討する場合は、公式サイトで導入、運用、通報フロー、管理者向け情報を確認します。
URL : https://globaleaks.org/
内部通報、公益通報、組織的な情報提供フローで使われることがあります。
ただし、GlobaLeaksを使えば自動的に安全になるわけではありません。
通報者側の端末、ネットワーク、ファイルメタデータ、送信内容、送信時刻は別に注意が必要です。
運用者側も、アクセス権限、ログ方針、資料管理、返信方法を慎重に設計する必要があります。
関連ツール
SecureDrop
SecureDropは、報道機関やNGOが匿名の情報提供を受け付けるために導入できるオープンソースの内部告発・情報提供システムです。
紹介する理由: 取材源保護や内部告発の文脈で、提出先、Tor Browser、ファイルメタデータ、運用前提を考える代表的な実用例として紹介します。
URL : https://securedrop.org/
GlobaLeaks
GlobaLeaksは、組織が通報・内部告発窓口を構築するための自由でオープンソースのソフトウェアです。
紹介する理由: 内部告発や相談窓口では、提出先の信頼性、運用者、ログ、ファイルメタデータを考える必要があります。その比較対象として紹介します。
URL : https://globaleaks.org/