技術開発者と企業は、Web3 の可能性を評価する際に、セキュリティに対する積極的なアプローチを取る必要があります。ブロックチェーンと暗号通貨は、ソーシャルエンジニアリング、インサイダー攻撃、欠陥のある実装といった従来の問題から、分散型アプリケーション、取引所、ウォレットにおけるWeb3ネイティブの悪用といった新しいクラスまで、セキュリティに関する懸念が高まっています。
ブロックチェーン領域における攻撃は、しばしば従来のアプリケーションよりも被害が大きくなります。これらの事象は不可逆的であり、スマートコントラクトを条件とするため、悪用された場合、単一のノードではなくネットワーク全体に連鎖します。
セキュリティリーダーは、Web3セキュリティのベストプラクティスを参考に、リスクを軽減することができます。
伝統的なセキュリティ設計の原則は、Web3システムにも他のシステムと同様に不可欠です。開発者は、セキュリティを意識した基準を設計し、製品、およびインフラストラクチャに組み込む必要があります。例えば、攻撃対象領域を最小化し、ゼロトラストフレームワークを考慮し、権限を分離して最小化するよう努力する必要があります。
セキュリティ・バイ・デザインの原則が第一ですが、組織はどのような種類のブロックチェーンを使用する予定なのかも検討する必要があります。
イーサリアムやソラナなどのパブリックブロックチェーンネットワークはオープンであり、誰でも参加することができます。また、ユーザーは用途に応じてさまざまな匿名性を享受することができます。これに対し、プライベート（許可制）のブロックチェーン・ネットワークは、ユーザーが自分の身元だけでなく、メンバーシップやアクセス権限も確認する必要があります。
パブリック、プライベートに関わらず、ブロックチェーンの種類によって複雑さが異なるため、1つのブロックチェーンを理解しても、すべてのブロックチェーンを理解したことにはなりません。サイドチェーン、マルチチェーン、クロスチェーン、フェデレーション、オラクル、その他の分散型台帳コンポーネントなど、さまざまなハイブリッドインフラは、スピード、効率、回復力など、セキュリティチームと接点を持つ他の基準にも影響を及ぼします。
Web3 の「西部開拓時代」には、テクノロジーだけでなく、デザイナーが考慮しなければならない法律的、文化的、経済的な力学が含まれています。たとえば、アイデンティティに関しては、特定の設定や統合が、Know Your Customer や GDPR などの既存のコンプライアンス体制に抵触する可能性があります。
ID 以外にも、暗号技術に関する規制は管轄地域によって異なります。さらに、多くのWeb3エンティティは、プロジェクトや分散型自律組織です。
また、ソーシャルエンジニアリングのセキュリティへの影響も考慮してください。Discordのコミュニティは、デジタル資産の利点をどのように誤解し、誇張するでしょうか。暗号プラットフォームの暗号化された金融化は、悪質な行為者にどのようなインセンティブを与えるのでしょうか。
サイバーリスク管理プログラムは、新たな脅威に対する理解を深め、緩和するために、業界の同業者と協力することで利益を得ることができます。Web3 の文脈では、GitHub や OODA Loop が最近リリースした Cryptocurrency Incident Database のようなオープンソースプラットフォームなど、従来のリソースに類似したチャネルがあります。OODA Loop は、Web3 プロジェクトの間でサイバーセキュリティ事件が多発していることに着目し、セキュリティ研究者やエンジニアが共通のサイバー攻撃カテゴリや根本原因を確認できるように、このデータベースを構築しました。また、ビルダーは、自社のプラットフォームで開発者向けのセキュリティガイダンスを公開する必要があります。Web3 の開発は比較的公開されているため、Reddit、Discord、Twitter などで調査を行うことも可能です。
組織は、開発プロセスの前と全体を通して、リスクをモデル化し、分析し、軽減する必要があります。ブロックチェーン開発者とセキュリティ専門家は、事前に以下のような質問をする必要があります。
- コードの中で最も影響が大きいのはどの部分か？
- インシデント対応プロトコルはどのように影響されますか？
- 脆弱性はどのように報告されるのか?
- リスクを高めるために、ユーザはどのようにサポートされるのか？
- ユーザーの権限はどのように管理され、ウォレットやチェーンなどの相互運用性はどのように説明されるべきか？
- 組織はコミュニティ参加型のガバナンスに対応していますか？
- 違反が発生した場合、大規模な変更やチェーンの分岐はどのように処理されますか？
このような質問は、インシデントが発生したときよりも、むしろ先手を打って対処したほうがよいでしょう。その答えは、組織のサイバーセキュリティガバナンスプログラムに沿ったものであるべきです。
情報の品質やデータ操作のリスクを評価することは、オンチェーンかオフチェーンか、また、取引や所有権を確認するために必要な情報は何か、といった判断と関連付ける必要があります。
フィッシングなどの一般的な脅威には、テクノロジーのアーキテクチャと UX ワークフローの両方で対応する。例えば、セキュリティチームは、悪意のあるリンク検出ソフトウェアをブラウザにインストールするようユーザーに促し、多要素認証を要求し、オープンなWi-Fiネットワークを回避し、システムの更新を行うよう定期的にリマインダーを送信する必要があります。
また、プルーフ・オブ・ワーク型合意形成アルゴリズムの回避、マイニングプールの監視、他のノードの不審な行動の分析により、51%攻撃やシビル攻撃といったブロックチェーンアーキテクチャに特有のリスクを回避する必要があります。ブロックチェーンのキーとウォレットに関連する新しいユーザーの責任を考えると、セキュリティはユーザーのオンボーディング、コミュニケーション、およびエクスペリエンス・デザインに含まれる必要があります。
Web3 の開発ペースは速いですが、構築者は新しいコードやコミットを開始する前と後に、プロジェクトを評価し、テストする必要があります。これを怠ると、一般的なエクスプロイト、インサイダー攻撃のベクトル、ユーザーのプライバシー保護、その他のミスを見落としてしまい、違反や巨額の損失につながる可能性があります。
特に新興の開発企業は、従来の企業のようなセキュリティガバナンスがない可能性があるため、組織は定期的な監査も実施する必要があります。
その中には、開発の各段階で監査レベルのチェックを行う技術を開発したDeepReasonも含まれています。
セキュリティ・リーダーは、この新しいクラスのテクノロジーを取り入れるべきです。従来のセキュリティ手法も多く適用されますが、分散型台帳、暗号資産、ウォレット、およびデジタル通信の広範な金融化によって、セキュリティにはいくつかの明確な意味が生まれます。Web3 は企業とは無関係に思えるかもしれませんが、その根底にある技術は、企業とその顧客にとって大きな破壊的可能性を持っています。
出典：7 best practices for Web3 security risk mitigation
