#Web3SecurityGuide

#Web3SecurityGuide
Web3セキュリティガイド完全版：主要レイヤーと実際の事例を徹底解説

レイヤー1 ウォレットの設定
長期保管にはハードウェアウォレットを使い、日常利用にはホットウォレットを使って、用途を明確に分ける
2台ルールを採用し、保管用にはクリーンな端末を1台、Web3の日常利用には別の端末を1台使う
PINとパスフレーズを有効にし、内容を確認せずに署名する機能をブロックし、出金先の許可リストと新規アドレスへの24時間ロックを設定する
同じウォレットを長期保管、エアドロップ、テスト、ハイリスクな取引に使い回さない
良い事例 ユーザーが90パーセントをハードウェアウォレットで保管し、10パーセントをホットウォレットに入れていたため、ホットウォレットが侵害されても保管資産は安全だった
別の事例 ユーザーが1つのウォレットをすべての用途に使い、フィッシングによって全資産を失った

レイヤー2 シードと秘密鍵
シードは金属製の媒体にオフラインで保管し、クラウド、メール、スマートフォンのメモ、ブラウザ、チャットには決して保存しない
多額の資産を保管する場合は、Shamir方式でシードを分割し、事前に復元テストを行ったうえで、分割したものを地理的に離れた2か所の金庫に保管する
シードをサイト、フォーム、アプリに入力せず、画面共有や写真で表示することもしない
秘密鍵ファイルをデスクトップやダウンロードフォルダに保存しない
悪い事例 ユーザーがシードをクラウドのメモに保存し、クラウドアカウントがフィッシング被害に遭った結果、数分ですべての資産を失った
2つ目の事例 ユーザーがシードを紙に書いたが、その紙が濡れて紛失し、バックアップもなかったため、資産が永久に利用不能になった

レイヤー3 フィッシングと偽リンク
偽の請求、偽のエアドロップ、偽のサポートDMが、資産を抜き取られる主な原因になっている
公式ドメインを必ずブックマークし、DM、メール、広告バナーのリンクは決してクリックしない
URLを1文字ずつ確認し、ホモグラフ攻撃、余分なハイフン、偽のTLDがないか確認する
Web3専用のブラウザプロファイルを使い、ポップアップをブロックし、自動接続を無効にし、トランザクションシミュレーションを利用する
良い事例 本物と見分けがつかない偽トークンローンチサイトが無制限の承認を要求し、ユーザーがクリックしただけでウォレットから資産を抜き取った
2つ目の事例 偽のウォレットアップデートが悪意のあるコードを注入し、クリップボード経由で送金先をすり替えた
3つ目の事例 偽のヘルプデスクがリモート操作ツールを要求し、ブラウザ拡張機能の保管ファイルを盗んだ

レイヤー4 承認とPermit
無制限の承認は取り消すまで有効なままになり、攻撃者は後からそれを利用できる
承認上限を限定し、1回限りの使用にして、revokeツールで毎週取り消す
承認先がEOAではなくコントラクトであることを確認し、コントラクトの経過期間、トランザクション数、検証済みソースを確認する
第三者がガス代なしでトークンを移動できるPermitやメタトランザクションに署名することを避ける
読めないTyped Dataや、内容を確認できないハッシュへの署名を避ける
良い事例 ユーザーがファーミングコントラクトにUSDTの無制限承認を与え、数か月後にそのコントラクトが悪用され、攻撃者が残っていた承認を使ってUSDTを抜き取った
2つ目の事例 ユーザーが無料NFTのためにPermitへ署名し、そのPermitによって攻撃者にUSDC全額の使用権限を与えた

レイヤー5 コントラクトとコードのリスク
監査済みでも安全とは限らないが、監査がない場合は高リスクである
TVL、運用期間、チームの実績、バグ報奨金、マルチシグ、タイムロック、プロキシ、オーナーキーを確認する
流動性が低く、匿名チームが運営し、単一のオーナーキーとミント機能を持つ高利回りのフォークを避ける
署名前にシミュレーションツールを使い、残高の変化とトークンの流れを確認する
良い事例 コードをコピーしたフォークに隠しミント機能が追加され、開発者がトークンをミントして売り抜けた
2つ目の事例 低流動性の価格フィードを使うボールトが、フラッシュローンと価格操作の被害を受けた

レイヤー6 ブリッジとクロスチェーン
ブリッジは大量の資金プールを保有し、複雑なリレイヤーと証明ロジックを持つため、主要な攻撃対象になる
最初に少額のテストトランザクションを実行し、チェーンIDとアドレス形式を確認して、ファイナリティを待つ
監査が少なく、TVLが低く、バリデーターが1つしかない新しいブリッジを避ける
良い事例 ブリッジが偽の証明を悪用され、攻撃者が偽のラップドトークンをミントして、本物の資産と交換した
2つ目の事例 ユーザーが誤ったチェーンIDに送金し、別チェーン上の同じアドレスへ送ってしまったため、復旧手段がなく資産を失った

レイヤー7 端末とアカウントのOPSEC
専用のメールアドレス、強力なパスワード、アプリベースの2FA、高額資産を扱うアカウントへのログイン用ハードウェアキーを使う
APIキーをローテーションし、IPを制限し、出金先リストをロックし、使わない場合は証拠金取引と先物取引を無効にする
端末をロックし、使用後はキャッシュを消去してログアウトし、マルウェアをスキャンし、クラックツールや海賊版ボットを避ける
良い事例 トレーダーがフォーラムと取引プラットフォームで同じパスワードを使い回し、フォーラムへの侵害後にAPIキーが悪用されて資産を抜き取られた
2つ目の事例 トレーダーがクラックされたボットをインストールし、ボットにキーファイルを盗まれた

レイヤー8 ソーシャルリスクと人的リスク
利益、ウォレット残高、シード、所在地を公の場で決して共有しない
資金を送る前に別の通信経路で本人確認を行い、最初は少額でテストする
チームの財務資産にはマルチシグを使い、承認数、タイムロック、ロールベースのアクセス制御を設定する
良い事例 チームの財務資産が単一のキーで管理されていたため、キー保有者がいなくなると資金がロックされた

レイヤー9 復旧計画
各チェーンに少額のガス代を入れたバックアップウォレットを用意しておく
資産を抜き取られた場合は、フロントランニングを避けるため、プライベートRPC経由で残りの資産を速やかにクリーンなウォレットへ移す
クリーンな端末から承認を取り消し、トランザクションハッシュと資金の流れを記録し、チームに報告するとともにエクスプローラー上でラベル付けする
ウォレット、連絡先、安全なアドレスのオフライン記録を保管する

プロトレーダーの日次チェックリスト

1 公式ドキュメントとエクスプローラーでドメインとコントラクトアドレスを確認する
2 トランザクションをシミュレーションし、残高の変化と承認の変更を確認する
3 承認上限を低く設定し、1回限りの承認にする
4 最初に少額でテストする
5 すべての操作を記録し、毎週見直して、脆弱なツールと悪い習慣を減らす

マインドセット
セキュリティは一度きりの作業ではなく、習慣である
日々の小さなセキュリティ対策、ハードウェアウォレット、限定的な承認、検証、低い信頼度、迅速な取り消しを組み合わせることで、資産を安全に保てる
運ではなくプロセスに集中し、繰り返し実行できる安全なフローを目指す。