音声AI論文研究室
プライバシー・セキュリティ

鍵管理と承認プロセスが守りの要 — Web3 インシデントから学ぶ組織的セキュリティの教訓

📄 Bridging the Cybersecurity Gap Between Web2 and Web3 - An Incident-Based Analysis of Organizational and Application-Level Security Failures

✍️ Yavas, T., Brömme, A.

📅 論文公開: 2026年5月

情報セキュリティ 暗号鍵管理 Human-in-the-Loop ISMS インシデント分析

3つのポイント

  1. 1

    Web3 の大型被害の多くは、スマートコントラクトの脆弱性ではなく、組織のプロセスや人を介した運用フローの不備から生じていると本論文は指摘します。

  2. 2

    実際の侵害事例を既存の Web2 セキュリティ枠組み（OWASP など）に対応づけた結果、暗号鍵管理・取引承認のガバナンス・人を介した手続きが汎用的な対策では十分にカバーされていないことが分かりました。

  3. 3

    著者らは、確立された情報セキュリティマネジメントシステム（ISMS）の導入と、ブロックチェーン固有のセキュリティ統制カテゴリの整備を提案しています。

論文プロフィール

  • 著者: Tarkan Yavas 氏、Arslan Brömme 氏
  • 発表年 / 掲載先: 2026 年 / arXiv（cs.CR：暗号とセキュリティ）プレプリント
  • 研究対象: Web3 エコシステム（暗号資産取引所・カストディサービス・ブロックチェーン基盤）で公開された大規模セキュリティ侵害事例
  • 研究内容: Bybit 取引所（2025 年）、Ronin Network ブリッジ（2022 年）、DMM Bitcoin 取引所（2024 年）など、公開文書化された高インパクトの侵害を質的に分析し、Web2 のセキュリティ参照枠組み（OWASP など）に対応づけて失敗パターンを体系化した研究です。

エディターズ・ノート

この論文を取り上げたのは、技術そのものよりも「組織と人の運用」がセキュリティの最終防衛線になるという指摘が、プライバシーファーストを掲げる私たちにとって他人事ではないからです。暗号化アルゴリズムの強度だけでは守れない領域に、どう向き合うかを考えるきっかけになります。

実験デザイン

本論文は数値実験ではなく、質的・インシデントベースの分析を採用しています。

  • 手法: 公開文書化された高インパクトの侵害事例を選定し、その経緯と原因を体系的に分析
  • 評価の枠組み: 各事例を、確立された Web2 のセキュリティ参照枠組み（OWASP ベースの脆弱性カテゴリ、組織的セキュリティ統制ドメイン）に対応づけ
  • 主な知見: 実世界の損失の多くがオンチェーン（ブロックチェーン上）ではなく、オフチェーンのシステム・組織プロセス・人を介した運用ワークフローに由来していること

著者らは、Web3 環境で支配的な失敗パターンとして次の領域を挙げています。

  • 暗号鍵の管理
  • 取引承認のガバナンス
  • 署名者・検証者インフラ
  • サードパーティツールへの依存
  • 人を介した（Human-in-the-Loop）プロセス

これらは汎用的なセキュリティ統制カタログでは十分に扱われていない、というのが本論文の中心的な主張です。具体的な被害金額や定量的な効果量は本論文では数値として体系的に提示されていないため、ここでは数値グラフは作成しません。

🔍 なぜ「オフチェーン」が狙われるのか

ブロックチェーンのプロトコルそのものは暗号技術で堅牢に守られていることが多い一方、実際の攻撃者は、より弱い「人と組織」の接点を突きます。

  • 鍵を保管する運用環境
  • 取引を承認する人間の判断プロセス
  • 外部ツールやライブラリへの依存

本論文は、これら周辺領域の不備が大規模損失の主因になっていると分析しています。技術の強度と運用の強度は別物である、という視点が重要です。

技術的背景

本論文が繰り返し強調するのは、暗号化技術それ自体ではなく、その鍵をどう管理し、誰がどう承認するかという運用設計の重要性です。

通信や保存データを保護する エンドツーエンド暗号化（E2EE） は強力ですが、その鍵管理や承認プロセスに穴があれば、暗号アルゴリズムの強度は意味をなしません。Web3 の文脈では署名者インフラや多重署名のガバナンスがこれに当たりますが、考え方は一般的な暗号化システムにも通じます。

また、人が最終確認を行う「人を介したプロセス」が攻撃の標的になりうる点も示唆的です。承認 UI の設計や運用フローの堅牢化は、技術と人間の接点を守る課題として位置づけられます。

著者らは、これらを場当たり的に対処するのではなく、確立された情報セキュリティマネジメントシステム（ISMS）の枠組みに乗せて運用すべきだと提案し、ブロックチェーン固有の統制カテゴリを構造化して導出しています。

🔍 ISMS とは — 「仕組みで守る」という発想

ISMS（情報セキュリティマネジメントシステム）は、特定の技術ではなく、組織がリスクを継続的に評価し対策を回し続ける「仕組み」を指します。

本論文の主張は、Web3 のような新しい領域でも、ゼロから独自ルールを作るのではなく、既存の成熟した管理枠組みを土台にしつつ、ドメイン固有のリスク（鍵管理・承認ガバナンスなど）を補うカテゴリを足すべき、というものです。新しさを理由に基本を飛ばさない、という姿勢が読み取れます。

And Family Voice としての解釈

本論文は Web3 を題材にしていますが、その教訓は私たちのプライバシー設計の根幹に深く関わると考えています。

視点A（プロダクト）

私たちは、家族の記録を E2EE（AES-256-GCM） で暗号化してクラウドに蓄積しています。本論文が示すのは、暗号アルゴリズムの強度だけでなく、その鍵管理こそが防衛線だという点です。鍵がどこでどう生成・保管・破棄されるか、その運用設計を継続的に見直す必要があると改めて受け止めています。

加えて、And Family Voice はスワイプ UI による Human-in-the-Loop の承認フローを通ったテキストのみをクラウドに送る設計です。本論文が「人を介したプロセス」を主要な失敗パターンに挙げている点は、私たちにとって直接の示唆です。承認フローを単なる利便機能ではなく、セキュリティ統制の一部として捉え、設計に活かそうとしています。断定はできませんが、これは探求の途中にある課題だと正直に考えています。

視点B（ユーザー）

プロダクトを使っていない方にも届けたい実践のヒントを 1 つ。サービスの安全性を見るとき、「暗号化しています」という言葉だけでなく、「鍵を誰がどう管理しているか」「重要な操作に人の確認が入るか」まで一歩踏み込んで確認してみてください。守りの強さは、技術そのものより運用の丁寧さに表れることが多いのです。

読後感

最も堅牢な暗号も、それを扱う人と組織の手順が脆ければ守りきれない——。あなたが日々使うサービスは、技術の強さと運用の丁寧さ、その両方を備えているでしょうか。