Notion・Confluenceに眠るAPIキー
買収後の最初のセキュリティ監査で、買い手のエンジニアが対象企業のNotionを開いた。「環境構築手順」というページに、本番データベースの接続文字列がパスワードごと平文で書かれていた。「デプロイ手順」のページには、決済プロバイダーの本番APIキーがコピペされていた。「新人向けセットアップ」には、AWSのアクセスキーが3年前から貼られたままだった。そしてそのNotionワークスペースには、すでに退職した元業務委託者5名が、ゲストとしてアクセスできる状態で残っていた。
社内Wiki ── Notion、Confluence、esa、Google Docs、Wiki.js ── は、チームの知識を蓄積する資産であると同時に、組織内で最も見過ごされている機密漏洩源だ。「とりあえずここに書いておけば共有できる」という利便性が、APIキー・パスワード・秘密鍵・接続情報を、検索可能で・共有可能で・誰がアクセスできるか把握されていない場所に堆積させる。M&Aでは、この堆積した機密が、買い手にそのまま引き継がれる。
本稿では、なぜ社内Wikiが最大の機密漏洩源になるのか、そこに何が眠っているのか、棚卸しと無効化の実務手順、アクセス権と公開設定の盲点、そしてWikiの状態をセキュリティリスクとしてバリュエーションにどう織り込むかを、現場目線で整理する。
1. なぜ社内Wikiが最大の機密漏洩源になるのか
1-1. 「便利だから貼る」という利便性が生む堆積
機密情報がWikiに堆積する根本原因は、利便性だ。手順書を書くとき、コマンドに必要なAPIキーや接続情報をその場に貼り付ければ、読んだ人がコピペで作業できる。「セキュアな保管場所を別途参照させる」より、その場に書く方が圧倒的に楽だ。この小さな利便性の積み重ねが、何年もかけて機密の地層を作る。
しかも、一度書かれた機密は消されない。手順が更新されても古いページは残り、使われなくなったキーも貼られたままになる。Wikiは「書くインセンティブ」はあっても「消すインセンティブ」がないため、機密は一方的に堆積し続ける。そして堆積した機密の全体像を把握している人間は、組織の中に誰もいない。
1-2. 検索可能性という両刃の剣
Wikiの価値は検索性にある。必要な情報にすぐ辿り着ける。しかしこの検索性は、機密に対しても等しく働く。「password」「api_key」「secret」「token」で検索すれば、ワークスペース内の機密が一覧で出てくる。これは攻撃者にとっても、内部の不正者にとっても、極めて効率的な情報源になる。
さらに、Notionの一部ページが「Web公開」設定になっていると、その内容が検索エンジンにインデックスされ、インターネット全体から閲覧可能になる。公開設定のページに機密が含まれていれば、それはもはや漏洩ではなく公開だ。本人たちは社内共有のつもりでも、世界中からアクセスできる状態になっていることがある。
2. Wikiに眠る機密の種類
2-1. 認証情報 ── パスワード・接続文字列・トークン
最も頻出するのが認証情報だ。データベースの接続文字列（ホスト・ユーザー・パスワードを含む）、各種SaaSのログインパスワード、API キー、アクセストークン、Webhookの署名シークレット。これらが「手順書」「環境構築」「トラブルシューティング」といったページに、作業の便宜のために平文で記載されている。
特に危険なのが、本番環境の認証情報だ。本番DBの接続文字列がWikiにあれば、Wikiへのアクセス権を持つ全員が、理論上は本番データに直接アクセスできる。退職者・元委託者がWikiアクセスを保持していれば、彼らは本番環境への鍵を持ち続けていることになる。
2-2. 秘密鍵・証明書という再発行困難な機密
認証情報以上に深刻なのが、秘密鍵や証明書のWiki保管だ。SSHの秘密鍵、SSL証明書の秘密鍵、コード署名鍵、JWT署名用の秘密鍵、各種サービスのプライベートキーが、「サーバー設定メモ」などに貼り付けられていることがある。これらは単なるパスワードと違い、漏洩すれば「なりすまし」や「署名の偽造」を許す。
さらに、本連載で扱ったAndroidの署名鍵のように、再発行できない・再発行すると重大な影響が出る鍵がWikiに平文で存在する場合、その機密性が損なわれた状態そのものが、回復困難な負債になる。秘密鍵がWikiにあるという事実は、その鍵がすでに信頼できない可能性を意味する。
2-3. 内部構造情報 ── 攻撃の地図になる知識
直接的な機密でなくとも、システムの内部構造を詳細に記したページは、攻撃者にとっての地図になる。インフラ構成図、エンドポイント一覧、内部APIの仕様、セキュリティの回避手順、「とりあえずこうすれば動く」という抜け道の記録。これらが漏洩すると、攻撃の難易度が大きく下がる。
これらの知識は事業運営に必要な資産でもあるため、削除はできない。重要なのは、誰がアクセスできるかを厳格に管理することだ。知識資産としての価値と、漏洩時の攻撃地図としてのリスクは、同じページの裏表だ。
3. 棚卸しと無効化の実務手順
3-1. 機密スキャン ── キーワード横断検索
棚卸しの第一歩は、Wiki全体に対するキーワード横断検索だ。「password」「passwd」「secret」「api_key」「apikey」「token」「access_key」「BEGIN PRIVATE KEY」「BEGIN RSA」「.env」「mysql://」「postgres://」といったパターンで全文検索し、ヒットしたページを一件ずつ精査する。NotionやConfluenceのAPIを使えば、全ページのテキストをエクスポートして機械的にスキャンできる。
発見した機密は、台帳化したうえで、まず該当キーが現在も有効かを確認する。有効なものは速やかにローテーション（無効化と再発行）し、Wikiから機密記載を削除して、参照すべきセキュアな保管場所（シークレットマネージャ等）への案内に置き換える。「見つけて消す」だけでは不十分で、「見つけたキーは漏洩した前提でローテーションする」必要がある。
3-2. M&A後の全機密ローテーション
買収側の立場では、Wikiに記載されていた機密は、たとえ削除しても「すでに漏洩している可能性がある」前提で扱うのが原則だ。Wikiにアクセスできた全員 ── 現役社員、退職者、元委託者、ゲスト ── が、その機密を持ち出せた可能性を排除できない。
したがって、買収後のセキュリティ対応として、Wikiから発見された機密に加え、対象企業が使っていた主要な認証情報を一斉にローテーションすることが望ましい。機密のローテーションは、買収による「鍵の引き継ぎ」を完了させ、旧体制の保持していた鍵を無効化する、所有権移転の仕上げの作業だ。
4. アクセス権と公開設定の盲点
4-1. 退職者・ゲスト・外部共有の残存
Wikiのアクセス権は、追加はされても削除されにくい。プロジェクトのたびに招待された外部委託者、退職した社員、一時的に共有したパートナー ── これらのアクセス権が、棚卸しされないまま残存する。彼らは今もWikiの内容を閲覧でき、場合によっては編集もできる。
DDでは、Wikiのメンバー一覧・ゲスト一覧・外部共有リンクの一覧を取得し、現役で正当なアクセス権を持つべき人物と突き合わせる。退職者や元委託者がWikiにアクセスできる状態は、本連載で扱ったCloudflareのゾンビ権限と同種の、誰の管理にも属さない残存アクセスだ。
4-2. Web公開ページと検索インデックス
もう一つの盲点が、Web公開設定のページだ。Notionには「Share to web」機能があり、公開設定のページはURLを知る誰もが、あるいは検索エンジン経由で閲覧できる。社内向けに作ったページが、いつの間にか公開設定になっていることがある。
棚卸しでは、公開設定になっているページを全て洗い出し、機密や内部情報が含まれていないかを確認する。すでに検索エンジンにインデックスされている場合は、公開解除に加えてキャッシュの削除申請も検討する。「社内Wiki」という名前に油断していると、その一部が全世界に公開されていることに気づかない。
5. バリュエーションとチェックリスト
5-1. セキュリティ衛生の指標としてのWiki
Wikiの状態は、組織のセキュリティ衛生（security hygiene）を映す鏡だ。機密がシークレットマネージャで一元管理され、Wikiには機密が記載されず、アクセス権が定期的に棚卸しされ、公開設定が管理されている事業は、セキュリティ運用が成熟している証拠であり、買収後のセキュリティリスクが低い。
逆に、Wikiが平文の機密で溢れ、退職者がアクセスでき、公開ページに内部情報が漏れている事業は、すでにインシデントが起きているか、起きていても気づいていない可能性が高い。Wikiの機密管理状態は、財務諸表に載らないセキュリティ負債として、バリュエーションとリスク評価に反映すべき項目だ。
5-2. 買い手・売り手のチェックリスト
買い手は、①Wiki全体の機密スキャン結果、②発見された機密の有効性とローテーション計画、③メンバー/ゲスト/外部共有の一覧と退職者アクセスの有無、④Web公開ページの棚卸し、⑤シークレット管理の運用実態、を確認する。買収後は発見機密の一斉ローテーションを前提とする。
売り手は、交渉前にWikiの機密スキャンを実施し、機密をシークレットマネージャに移し、Wikiから平文機密を一掃し、アクセス権を棚卸しし、公開設定を点検しておく。「Wikiに機密が一切ない」状態を実証できる売り手は、セキュリティ衛生の高さを示し、買い手の最も根深い不安の一つを解消できる。社内Wikiの棚卸しは、見えない機密の地層を掘り起こす作業だ。
結論：知識資産の裏側に、機密負債が同じ量だけ堆積している
社内Wikiは、チームの知識を蓄積し、運用を引き継ぎ可能にする貴重な資産だ。しかし同じ場所に、「便利だから貼った」機密が、消されることなく堆積している。APIキー、パスワード、秘密鍵、内部構造 ── これらは検索可能で、共有可能で、誰がアクセスできるか把握されていない状態で、事業の最も深い部分への鍵を提供してしまう。
M&AにおけるWiki棚卸しは、知識資産を引き継ぐと同時に、堆積した機密負債を可視化し、無効化する作業だ。売り手にとってはWikiの機密衛生が事業価値を守り、買い手にとっては引き継ぐ機密の漏洩前提でのローテーションが必須の対応になる。技術的DDの本質は、「便利だから」という日常の判断が積み上げた見えないリスクを、検証可能な棚卸し手順に翻訳することにある。社内Wikiは、その最も身近で、最も見過ごされやすい現場だ。
