Web 1.0とWeb 2.0はともに、セキュリティモデルがアプリケーションアーキテクチャーともに変更され、まったく新しい経済の扉を開いた。Web 1.0では、Secure Socekts Layer（SSL、セキュリティ・ソケット・レイヤー）がNetscape（ネットスケープ）によっていち早く開発され、ユーザーのブラウザーとさまざまなサーバーとの間の堅牢なコミュニケーションを可能にした。Google（グーグル）、Microsoft（マイクロソフト）、Amazon（アマゾン）などのWeb 2.0の信頼できる仲介者と認証機関は、SSLの後継となるTransport Layer Security（TLS、トランスポート・レイヤー・セキュリティ）の実装を加速する中心的役割を果たした。
同じことがWeb3でも起きようとしている。これが、新しいWeb3セキュリティ会社への投資が2021年10倍以上増えて10億ドル（約1兆1500万円）を超えた主な理由だ。
Web3の成功は、さまざまなアプリケーションアーキテクチャーが生み出す新たなセキュリティ問題を解決するイノベーションにかかっている。Web3では、分散型アプリケーション（dApps）が、Web 2.0に存在する伝統的アプリケーションロジックやデータベースレイヤーに依存することなく作られている。代わりにブロックチェーン、ネットワークノード、スマートコントラクトなどのプロトコルがロジックと状態の管理に使われている。
ユーザーは今までと変わらずにフロントエンドをアクセスし、そこからノードにつながってデータの更新、たとえば新しいコンテンツの公開や商品の購入などを行う。この手順では、ユーザーが各自のプライベートキー（秘密鍵）を使って取引を承認する必要があり、通常秘密鍵はウォレットで管理される。これはユーザーのコントロールとプライバシーを保護することを目的としたモデルだ。ブロックチェーンを利用した取引は完全に公開されていて、誰もがアクセス可能でイミュータブル（改変不可能）だ。
どんなシステムでも同じだが、このデザインにはセキュリティとのトレードオフがある。ブロックチェーンでは、Web 2.0のように行為者が信頼されている必要がなく、セキュリティ問題に対応するための更新がより困難だ。ユーザーはアイデンティティに関する制御を自ら維持することができるが、アタックを受けたり、キーを悪用された時に助けてくれる仲介者は存在しない（Web 2.0プロバイダーは、盗まれた財産を復活させたりパスワードをリセットできる）。ウォレットも、Ethereum（イーサリアム）アドレスなどの重要情報を漏らす可能性がある。ソフトウェアである限り完璧にはなりえない。
こうしたトレードオフは、当然ながら重大なセキュリティ上の懸念を喚起しているが、それによってWeb3の機運が削がれるべきではなく、実際その可能性は低い。
改めてWeb 1.0、Web 2.0との類似点を見てみよう。SSL/TLSの初期バージョンには致命的な脆弱性があった。かつてのセキュリティツールはよくいって原始的であり、時間とともに堅牢になっていった。Web3のセキュリティ会社やプロジェクト、たとえばCertik（サーティック）、Forta（フォータ）、Slither（スリザー）、Securify（セキュリファイ）などは、Web 1.0やWeb 2.0アプリケーションのために当初開発されたコードスキャニングやアプリケーションセキュリティテスティングのツールに相当する。
しかし、Web 2.0では、セキュリティモデルの中心はレスポンスだった。Web3では、いったん実行された取引は変更不可能なので、その取引がそもそも実行されるべきかどうかを検証する機構が組み込まれている必要がある。言い換えると、セキュリティは予防に関して並外れて優秀でなければならない。
つまりこれは、Web3コミュニティは、系統的脆弱性に正確に対応し、暗号プリミティブからスマート・コントラクトの脆弱性まであらゆるものをターゲットにする新たな攻撃手段を阻止する方法を見つけなければならないことを意味している。現在、予防型Web3セキュリティモデルを推進するイニシアチブが少なくとも4つ、進行している。
脆弱性に関するデータの信頼できる情報源
Web3の既知の脆弱性や弱点に関する信頼できる情報源が必要だ。現在、National Vulnerability Database（NVD、脆弱性情報データベース）が脆弱性管理プログラムのために基本データを提供している。
Web3には、分散型の同等品が必要だ。現在は、不完全な情報がSWC Registry（SWCレジストリー）、Rekt（レクト）、Smart Contract Attack Vectors（スマート・コントラクト・ベクターズ）、DeFi Threat Matrix（ディーファイ・スレット・マトリクス）などさまざまな場所に散らばっている。Immunefi（イミュニファイ）などが実施しているバグバウンティプログラムは、新しい弱点を発見することを目的にしている。
セキュリティに関わる意思決定基準
重要なセキュリティデザインの選択や、Web3の個々の事象に関する意思決定モデルは今のところ知られていない。分散型というのは、誰も問題の責任をもたないという意味なので、ユーザーにとって予期せぬ大問題がおきることがある。最近のLog4j脆弱性のような事例は、セキュリティを分散型コミュニティに委ねる危険性の教訓だ。
関連記事：米FTC、Log4jの脆弱性を修正しない組織に対する法的措置を警告
自律分散型組織（DAO）やセキュリティ専門家Alchemy（アルケミー）やInfura（インフーラ）などのプロバイダーなどが、差し迫るセキュリティ問題にどのように協力して取り組むかを明確にしておく必要がある。大規模なセキュリティコミュニティが協力し、OpenSSF（オープンSSF）やいくつものCNCFアドバイザリーグループを結成してセキュリティ問題に取り組むプロセスを確立したという良い事例がある。
認証と署名
現在ほとんどのdAppは、最も著名なものを含め、APIのレスポンスに認証や署名を行っていない。これは、ユーザーのウォレットがこれらのアプリからデータを取得したとき、レスポンスが意図したアプリから来たものであり、データが何からの方法で改ざんされていないことを検証するまでに時間のずれが生じることを意味している。
アプリが基本的なセキュリティのベストプラクティスを実施していない世界では、アプリのセキュリティに対する姿勢と信頼性を確かめる仕事はユーザーに任されているが、それは事実上不可能だ。最低限、リスクをユーザーに知らせるもっとよい方法が必要だ。
シンプルでユーザーが制御可能なキー管理
暗号化キーは、Web3パラダイムの下でユーザーが取引を行う仕組みを支えるものだ。暗号化キーは、正しく管理することが困難であることでも悪名高い。ビジネス全体がキー管理を中心に作られている必要があり、今後もそれは変わらない。
秘密鍵の管理に関わる複雑さとリスクは、ユーザーが自己管理ウォレット（non-custodial wallet）よりもホスト型ウォレット（hosted wallet）を選びたがる主要な理由だ。しかし、ホスト型ウォレットの利用には2つのトレードオフがある。Coinbase(コインベース）のような新たな「intermediaries」（仲介者）を生み、Web3の完全分散型への方向性を阻害すること。そして、ユーザーがWeb3の提供するものすべてを利用する機会を奪うことだ。理想は、さらなるセキュリティイノベーションによって自己管理ウォレットの使いやすさとセキュリティの両方が改善されることだ。
最初の2つのイニシアチブは人間とプロセスが中心なのに対して、3番目と4番目のイニシアチブはテクノロジーの変化が必要であることは注目に値する。新しい技術と生まれつつあるプロセス、さらに膨大な数のユーザーを調整しなければならないことが、Web3セキュリティの解決を難しくしている。
一方で、最も勇気づけられる変化の1つは、Web3のセキュリティイノベーションが開かれた場で起きていることだ。これがどれほど創造的ソリューションにつながるかを決して過小評価してはならない。
編集部注：本稿の執筆者Wei Lien Dang（ウェイ・リエン・ダン）氏はセキュリティ、インフラストラクチャー・ソフトウェアおよび開発ツールへの投資で知られるUnusual Venturesのゼネラルパートナー。クラウドネイティブセキュリティ会社で後にRed Hatに買収された、StackRoxを共同設立した。
画像クレジット：Westend61 / Getty Images
［原文へ］
（文：Wei Lien Dang、翻訳：Nob Takahashi / facebook ）
