セキュリティ監査

暗号資産分野のセキュリティ監査とは？

暗号資産分野のセキュリティ監査とは、攻撃者に脆弱性を悪用される前に見つけるため、ブロックチェーンシステム、スマートコントラクト、ウォレット、プロトコル、ブリッジ、分散型アプリケーション（dApp）、インフラを体系的に検証することです。簡単に言うと、セキュリティ監査は、暗号資産関連のコード、アーキテクチャ、前提、権限、運用管理に対する専門的な検査です。実際のユーザー資金が危険にさらされる前に、バグ、設計上の弱点、安全でない権限、経済的な攻撃経路、連携上のリスクを特定することを目的としています。暗号資産分野ではスマートコントラクトが多額の価値を扱う場合があり、ブロックチェーン取引は承認後に取り消すことが困難、または不可能なことが一般的であるため、セキュリティ監査は特に重要です。一般的なソフトウェアのバグはサービス停止やデータ損失を引き起こす可能性がありますが、スマートコントラクトのバグは、トークンの直接的な損失、資金の凍結、ガバナンスの機能不全、強制決済の失敗、流動性の盗難につながる可能性があります。

Ethereum公式のスマートコントラクトのセキュリティガイダンスでは、監査は有用であるものの、万能な解決策と見なすべきではないと説明されています。

つまり、セキュリティ監査は重要な防御策の一つですが、プロトコルが完全に安全であることを保証するものではありません。強固な暗号資産のセキュリティ体制には、安全な設計、テスト、コードレビュー、監査、形式手法、モニタリング、バグ報奨金、インシデント対応、慎重なアップグレード管理が組み合わされています。

セキュリティ監査の簡単な定義

セキュリティ監査とは、暗号資産システムの稼働開始前や大規模なアップグレード前に、弱点の有無を確認する詳細なレビューです。スマートコントラクト監査では通常、ソースコード、ビジネスロジック、アクセス制御、トークン会計、オラクルの利用、アップグレード可能性、ガスの挙動、既知の脆弱性パターンを確認します。プロトコル全体の監査では、フロントエンドのリスク、バックエンドサービス、管理者キー、マルチシグ管理、ブリッジ設計、バリデーターのインフラ、ガバナンスプロセス、モニタリング計画も確認する場合があります。セキュリティ監査報告書には通常、重大度別の指摘事項、リスクの説明、修正の推奨事項、各問題が修正または認識されたかどうかが記載されます。セキュリティ監査は、プロジェクトが防止可能なリスクの低減に向けて妥当な措置を講じたかを、ユーザー、開発者、投資家、エコシステムのパートナーが理解するのに役立ちます。ただし、監査はプロトコルにリスクがないことを証明するものではありません。特定の監査人が特定の時期に特定の範囲をレビューしたことを示すものにすぎません。

暗号資産分野でセキュリティ監査が重要な理由

暗号資産システムでは、コードを通じて資産を直接管理することが多いため、セキュリティ監査は重要です。DeFiのレンディングコントラクトは、担保や債務ポジションを保有する場合があります。流動性プールには、ユーザーが提供したトークンが保管される場合があります。ブリッジは、複数のチェーンにまたがるラップ資産を管理する場合があります。ステーキングコントラクトは、バリデーターへの委任や報酬計算を管理する場合があります。ガバナンスコントラクトは、アップグレード、財務資金、プロトコルパラメーターを管理する場合があります。こうしたシステムに深刻な脆弱性があると、攻撃者が資金を引き出したり、信頼を長期的に損なったりする可能性があります。セキュリティ監査は、明白で影響の大きいミスが本番環境に持ち込まれる可能性を下げます。また、チームが文書を改善し、前提を明確にし、より安全なデプロイ手順を整えるのにも役立ちます。

暗号資産のセキュリティ監査で一般的に確認される内容

暗号資産のセキュリティ監査は通常、プロジェクトの文書と脅威モデルの確認から始まります。コードが安全に動作するかを判断するには、監査人がプロトコルの本来の動作を理解する必要があります。次に、スマートコントラクトのコードを一行ずつ確認します。残高が正確に管理されているか、権限が適切に制限されているか、外部呼び出しが安全か、例外的な状況に対処できるかを確認します。さらに、リエントランシー、価格操作、不適切な乱数生成、整数計算のミス、署名のリプレイ、サービス拒否、安全でないアップグレード、アクセス制御の不備を利用してシステムが悪用されないかをテストします。

公式のSolidityのセキュリティに関する考慮事項のページでは、新しいリスクやパターンが継続的に現れるため、スマートコントラクトのセキュリティガイダンスを完全なものにはできないと警告しています。

そのため、監査には既知のチェックリストだけでなく、創造的で敵対的な視点からの検討も必要です。優れた監査では、コードが動くかどうかだけでなく、悪意ある状況下でどのように機能しなくなる可能性があるかも確認します。

セキュリティ監査とコードレビューの違い

コードレビューでは、コードが読みやすく、正確で、保守しやすく、開発基準に沿っているかを確認します。セキュリティ監査では、コードがどのように攻撃、悪用、回避、誤用される可能性があるかをより深く調べます。どちらも有用ですが、同じものではありません。通常のコードレビュー担当者は、関数が整理されていて理解しやすいかを確認する場合があります。セキュリティ監査人は、想定外の入力、呼び出し順序、ガバナンスの悪用、オラクル操作、悪意あるコントラクトとのやり取りによって、その関数が悪用されないかを確認します。暗号資産チームは、外部監査を依頼する前に社内でコードレビューを行うべきです。外部監査人が未完成のコードを最初に読む状態にすべきではありません。チームがすでにコードをテストし、文書化し、整理している場合、監査の成果は通常より高まります。

セキュリティ監査と形式検証の違い

形式検証では、定義された前提の下でコードが特定の性質を満たすことを数学的な手法で証明します。セキュリティ監査はより広範で、手動レビュー、ツールを利用した分析、経済的な検討、アーキテクチャレビュー、デプロイリスクの評価を含む場合があります。形式検証は、残高の保存、認可ルール、不変条件の維持など、重要な性質の検証に有効です。ただし、形式検証で証明できるのは、実際に仕様として定義された性質に限られます。仕様が不完全または誤っている場合、証明によって現実のリスクを防げないことがあります。監査と形式検証は、組み合わせることで最大の効果を発揮します。監査人が重要な性質を特定し、形式手法がその性質が保たれていることへの確信を高めます。価値の高いプロトコルでは、形式検証を手動のセキュリティ監査に加えることが有効な場合があります。

セキュリティ監査とバグ報奨金の違い

セキュリティ監査は通常、選定された監査人が、定められた範囲と期間に沿って行う計画的なレビューです。バグ報奨金は、外部の研究者が脆弱性を責任ある方法で報告した場合に報酬を支払う、継続的なプログラムです。監査は、公開前に専門家による集中的なレビューを行うのに役立ちます。バグ報奨金は、稼働開始後に新たな連携、市場環境、攻撃手法に直面するシステムを継続的に確認するのに役立ちます。さまざまなスキルや視点を持つ研究者を集められる点も、バグ報奨金の利点です。バグ報奨金は、デプロイ前の監査の代わりにはなりません。監査も、デプロイ後の継続的なセキュリティ監視の代わりにはなりません。強固な暗号資産のセキュリティプログラムでは、両方が活用されます。

暗号資産のセキュリティ監査の主な種類

スマートコントラクト監査

スマートコントラクト監査では、プロトコルのロジックを実行するオンチェーンコードを確認します。暗号資産分野でセキュリティ監査という場合、これを指すことが最も一般的です。監査人は、トークンコントラクト、レンディングコントラクト、ステーキングコントラクト、ボールトコントラクト、ガバナンスコントラクト、流動性プール、NFTコントラクト、ブリッジコントラクトを確認します。レビューでは、技術的なバグとビジネスロジック上の欠陥の両方を探します。

プロトコルアーキテクチャ監査

プロトコルアーキテクチャ監査では、複数のコントラクト、サービス、参加者、オフチェーンシステムがどのように連携しているかを確認します。個々のコントラクトに問題がないように見えても、プロトコル全体が安全とは限らないため重要です。たとえば、オラクルへの過度な依存、管理者キーへの権限集中、極端な市場状況で機能しない強制決済ルールなどが問題になる場合があります。アーキテクチャ監査は、システム全体のリスクを特定するのに役立ちます。

ブリッジのセキュリティ監査

ブリッジ監査では、クロスチェーンメッセージの検証、バリデーターセット、リレイヤー、署名のしきい値、資産のカストディ、ミントのロジック、障害からの復旧方法を確認します。ブリッジシステムは複数のチェーンにまたがる資産を管理することが多いため、高いリスクを伴います。ブリッジのバグは、送信元チェーンと送信先チェーンの両方に影響する可能性があります。ブリッジ監査では、コードレビュー、バリデーターへの信頼の分析、運用管理、緊急時対応計画を含めるべきです。

ウォレットのセキュリティ監査

ウォレット監査では、秘密鍵の取り扱い、シードフレーズの保護、取引への署名、アドレスの表示、復旧手順、アカウント抽象化のロジック、ユーザーインターフェースの安全性を確認します。ユーザーが署名内容を理解するためにウォレットを利用することから、ウォレットのセキュリティは重要です。暗号技術が強固なウォレットでも、取引確認画面が分かりにくければ、ユーザーがフィッシングにさらされる可能性があります。ウォレット監査では、技術面とユーザー体験の両方からセキュリティを確認する必要があります。

インフラ監査

インフラ監査では、ノード、RPCエンドポイント、インデクサー、バックエンドサービス、デプロイパイプライン、アクセス制御、クラウドシステム、モニタリング、インシデント対応プロセスを確認します。暗号資産ユーザーはスマートコントラクトに注目しがちですが、インフラの障害も大きな損失やサービス停止を引き起こす可能性があります。プロトコルがオフチェーンのキーパー、価格フィード、バリデーター、シーケンサー、リレイヤー、ボットに依存している場合があります。より広範なセキュリティモデルの一環として、こうしたシステムも確認する必要があります。

スマートコントラクトのセキュリティ監査の流れ

スマートコントラクトのセキュリティ監査は通常、対象範囲の定義から始まります。チームと監査人は、対象となるコントラクト、ブランチ、コミット、文書、テスト、スクリプト、デプロイ計画について合意します。次に、監査人がプロジェクトの想定動作と脅威モデルを確認します。コードを手動で確認し、自動分析ツールも実行します。脆弱性が実在するかを確認するため、概念実証のエクスプロイトを作成する場合があります。ユニットテスト、ファズテスト、不変条件テスト、シミュレーションを通じて、例外的なケースを検証することもあります。レビュー後、監査人は重大度と推奨事項を添えて指摘事項を報告します。プロジェクトチームは問題を修正し、監査人が修正内容の有効性を確認するため、再レビューを行う場合があります。

監査範囲に含めるべき内容

監査範囲には、ユーザー資金、権限、会計、アップグレード、ガバナンス、外部連携に影響を与える可能性のあるすべてのコードを含めるべきです。デプロイ予定のスマートコントラクトを含める必要があります。安全なコントラクトでも、誤った方法でデプロイすれば危険になるため、アップグレードスクリプトとデプロイスクリプトも含めるべきです。重要な設定ファイル、ロールの割り当て、アクセス制御設定、初期化パラメーターも対象に含めてください。オラクルとの連携、ブリッジアダプター、キーパーロジック、外部依存関係に関する前提も含める必要があります。想定動作や既知の信頼前提を説明する文書も対象とするべきです。対象範囲を狭くすれば監査費用を抑えられる場合がありますが、システム全体のリスクを見落とす可能性もあります。監査報告書を読むユーザーは、必ず対象に含まれたものと除外されたものを確認してください。

セキュリティ監査で見つかる一般的な脆弱性

一般的な脆弱性の一つにリエントランシーがあります。外部呼び出しによって、状態更新の完了前に想定外の再実行が可能になる問題です。別の一般的な脆弱性はアクセス制御の不備で、権限のないアドレスから特権関数を呼び出せる問題です。また、攻撃者がレンディング、取引、担保システムで使われる価格情報に影響を与えるオラクル操作も、よく見られる問題です。プロキシコントラクトや管理者キーによって危険な形でロジックを変更できる、安全でないアップグレード可能性も一般的です。有効な署名が意図しない状況で再利用される、署名のリプレイもよくある問題です。ゲーム、宝くじ、NFTの割り当てに予測可能な情報源を使う、不適切な乱数生成も問題となります。

OWASPスマートコントラクトTop 10では、開発者やセキュリティチーム向けに、主要なスマートコントラクトのリスク分類がまとめられています。

監査人はこうした一覧を出発点として利用しますが、十分な監査ではプロジェクト固有のロジック上の欠陥も探す必要があります。

監査報告書における重大度

監査報告書では通常、指摘事項を重大度別に分類します。Criticalの指摘事項は、直接的な盗難、資金の恒久的な損失、不正なミント、プロトコルの完全な乗っ取りにつながる可能性があります。Highの指摘事項は、深刻な損失、権限の悪用、会計の機能不全、大規模なサービス拒否を引き起こす可能性があります。Mediumの指摘事項は、特定の条件下や他の問題と組み合わさった場合に、無視できないリスクを生じさせる可能性があります。Lowの指摘事項には、比較的小規模なセキュリティ上の弱点、例外的なケース、セキュリティ強化の機会が含まれる場合があります。Informationalの指摘事項には、コード品質の提案、ガス効率の改善、文書の不足、ベストプラクティスに関する補足が含まれる場合があります。重大度の判断には、技術面と状況面の両方が関わります。あるプロトコルでは小さく見えるバグでも、基幹となる会計や特権管理に影響する場合、別のプロトコルでは重大な問題となる可能性があります。

セキュリティ監査とアクセス制御

アクセス制御は、暗号資産のセキュリティ監査で特に重要な項目です。誰がコントラクトを一時停止できるのか、ロジックをアップグレードできるのか、手数料を変更できるのか、オラクルを更新できるのか、トークンをミントできるのか、資金を引き出せるのか、ユーザーをホワイトリストに追加できるのか、プロトコルのパラメーターを変更できるのかを監査人が確認します。特権ロールが安全なマルチシグ、タイムロック、ガバナンスコントラクトに割り当てられているか、それとも安全でない単一キーのウォレットに割り当てられているかも確認します。アクセス制御が不適切だと、分散型に見えるプロトコルが、侵害された一つのキーで制御されるシステムになりかねません。監査人は報告書で特権ロールを明確に特定するべきです。ユーザーは監査報告書を読み、稼働開始後に誰がシステムを変更できるのかを理解してください。監査済みのコントラクトでも、管理者が透明性のある制御なしに広範な権限を保持していれば、リスクが残ります。強固なアクセス制御では、最小権限の原則に従う必要があります。

セキュリティ監査とアップグレード可能なコントラクト

アップグレード可能なコントラクトでは、デプロイ後にプロトコルのロジックを変更できます。バグの修正や機能改善に役立つ場合があります。一方で、信頼やガバナンスに関する大きなリスクを生じさせることもあります。監査では、プロキシパターン、ストレージレイアウト、初期化関数、アップグレード権限、タイムロック、緊急時の管理機能を確認する必要があります。ストレージレイアウトのミスは、アップグレード時に残高や権限を破損させる可能性があります。保護されていない初期化関数を攻撃者に悪用され、コントラクトが乗っ取られる可能性があります。制限のないアップグレード権限があれば、安全なコードが悪意あるコードに置き換えられる可能性があります。監査済みのプロトコルが、稼働開始後も管理者やガバナンスによってアップグレードされ得るかを理解してください。

セキュリティ監査とオラクル

オラクルは、価格、金利、準備金、乱数などの外部データをスマートコントラクトに取り込みます。多くのDeFiプロトコルでは、強制決済、スワップ、借入上限、ボールト価格の算定、決済にオラクルが使われています。監査では、オラクルデータが操作、遅延、陳腐化、誤設定の影響を受ける可能性がないか確認する必要があります。フォールバックロジック、データの鮮度、桁数の処理、サーキットブレーカー、資産固有のリスクも確認する必要があります。オラクルリスクは、コードだけの問題ではありません。経済面や市場構造にも関係します。価格フィードが技術的に正確でも、基礎となる市場の流動性が低すぎたり、簡単に操作されたりする場合は安全とは限りません。質の高い監査では、オラクルとの連携とデータに関する前提の両方を確認します。

セキュリティ監査と経済的攻撃

単純なプログラミング上のバグがなくても、暗号資産プロトコルが機能しなくなる可能性があります。経済的攻撃では、インセンティブ、流動性、ガバナンス、オラクルのタイミング、レバレッジ、市場の仕組みが悪用されます。担保価格が一時的に過大評価されると、レンディングプロトコルが機能しなくなる場合があります。価格算定式を悪用され、流動性プールから資金が引き出されることがあります。議決権をすばやく借り入れたり集中させたりできる場合、ガバナンスシステムが乗っ取られる可能性があります。バリデーターへのインセンティブが弱かったり、キー管理が不十分だったりすれば、ブリッジが機能しなくなる場合があります。セキュリティ監査ではコードの構文だけでなく、経済的な動きも考慮する必要があります。そのためDeFi監査では、エンジニアリングの専門知識と金融リスク分析の両方が求められることがあります。

セキュリティ監査と自動化ツール

自動化ツールは、既知の脆弱性パターンを効率よく見つけるために役立ちます。静的解析ツール、ファザー、シンボリック実行ツール、リンター、依存関係スキャナー、不変条件テストのフレームワークなどがあります。自動化ツールは有用ですが、専門家による手動レビューの代わりにはなりません。最近のスマートコントラクトセキュリティ解析ツールに関する研究論文では、ツールの精度に大きな差があることが示され、誤検知、見逃し、説明の曖昧さ、実行時間の長さなどが課題として指摘されました。つまり、ツールの出力はプロトコルの状況を理解する人が確認する必要があります。自動化ツールは、網羅性、反復作業、既知のパターンの検出に適しています。手動で監査を行う人は、ビジネスロジック、経済的な検討、アーキテクチャ、創造的な攻撃経路の発見に強みがあります。適切な監査では、ツールを最終的な判定者ではなく、補助役として使います。

セキュリティ監査とテスト

テストは、優れた監査プロセスの基盤です。外部監査の前に、チームは適切にユニットテスト、統合テスト、ファズテスト、不変条件テストを実施しておくべきです。ユニットテストでは個々の関数を確認します。統合テストでは、複数のコンポーネントがどのように連携するかを確認します。ファズテストでは、予想外の不具合を見つけるため、多数のランダムまたは半ランダムな入力を試します。不変条件テストでは、重要なルールが常に維持されているかを確認します。たとえば、レンディングプロトコルでは、債務総額と担保の会計が常に整合していることが求められる場合があります。監査人がゼロから始めるのではなく、既存のテストスイートを確認して拡張できれば、監査の効果が高まります。

セキュリティ監査と標準規格

セキュリティ標準は、チームや監査人が一貫した基準を使うのに役立ちます。

OWASPスマートコントラクトセキュリティ検証標準は、スマートコントラクト、dApp、EVMベースのブロックチェーンシステム向けに、セキュリティ要件とテストを定めています。

EEA EthTrustセキュリティレベル仕様は、スマートコントラクトのセキュリティ認証レベルに関する要件を定めています。

標準規格は専門家によるレビューの代わりにはなりませんが、監査の一貫性を高め、比較しやすくします。監査人が着手する前に、開発チームが準備を進めるうえでも役立ちます。認知された標準に従っていてもプロトコルにバグが残る可能性はありますが、セキュリティレビューに向けた基礎を整えられます。ユーザーは、ロゴや見出しだけでなく、監査方法を説明している監査報告書を選ぶべきです。明確な方法論があれば、監査を評価しやすくなります。

監査報告書に含めるべき内容

有用な監査報告書には、プロジェクト名、監査範囲、コードのコミット、日付、監査人、方法論、制限事項を記載する必要があります。プロトコルの概要も説明するべきです。すべての指摘事項について、重大度、影響、発生可能性、影響を受けるファイル、技術的な説明、推奨される修正を記載します。各問題が修正、一部修正、認識済み、未解決のいずれであるかを明示する必要があります。中央集権化に関するリスク、管理者権限、アップグレード制御、信頼されたロールについても説明するべきです。監査範囲外となった重要な前提も記載する必要があります。開発者が対応でき、ユーザーが主なリスクを理解できるだけの具体性が求められます。技術的な詳細がない曖昧な証明書は、明確な報告書よりも有用性が大きく劣ります。

監査報告書の読み方

まず、報告書がデプロイ済みのコントラクトを対象としているかを確認してください。古いコードバージョンの監査は、現在のデプロイに適用されない可能性があります。コミットハッシュ、コントラクトアドレス、デプロイ日、アップグレード履歴を確認します。「監査済み」という言葉だけでなく、未解決の指摘事項も読むべきです。プロジェクトが監査済みでも、深刻なリスクが認識されたまま残っている可能性があります。稼働開始前にCriticalやHighの指摘事項が修正されたかを確認してください。中央集権化リスク、管理者キー、オラクルに関する前提、外部依存関係も確認しましょう。安全な読み方はシンプルです。監査はレビューが行われた証拠であり、安全性の証明ではありません。

メインネット公開前のセキュリティ監査

公開前監査では、実際の価値を扱う前にコードを確認します。ユーザーが資産を入金する前に修正できるため、深刻な問題を見つける最適なタイミングです。チームは公開直前まで監査依頼を待つべきではありません。監査人がシステムを理解し、前提をテストし、質問し、修正を確認するには時間が必要です。急いで行う監査では重要な問題を見落とす可能性があります。監査開始前にコードを凍結してください。レビュー中にコードが頻繁に変更されると、監査範囲が安定しません。適切な公開前監査プロセスでは、準備、コード凍結、レビュー、修正、再テスト、慎重なデプロイを行います。

デプロイ後のセキュリティ監査

プロトコルのアップグレード、新しいモジュールの追加、オラクルやガバナンスの変更、新システムとの連携を行う場合、デプロイ後の監査も重要です。暗号資産プロトコルは固定されたものではありません。時間の経過とともに、新しい資産、チェーン、ボールト、市場、戦略、ブリッジ経路が追加される場合があります。変更のたびに新たなリスクが生じる可能性があります。公開時点で安全だったプロトコルも、十分なレビューを経ないアップグレードにより危険になる場合があります。デプロイ後の監査は、このリスクの低減に役立ちます。実際の市場環境でしか表面化しないリスクもあるため、稼働中のプロトコルを監視する必要があります。セキュリティは一度きりのイベントではなく、継続的なプロセスです。

DeFiプロトコルのセキュリティ監査

DeFiのセキュリティ監査では、コードと金融ロジックの両方を確認する必要があります。DeFiプロトコルは、担保率、金利モデル、流動性の厚み、価格フィード、強制決済のインセンティブ、手数料計算、ユーザー行動に依存する場合があります。ユーザーがプールから資金を引き出したり、債務確認を回避したり、価格を操作したり、報酬を盗んだり、資金をロックしたりできないかを監査人がテストするべきです。丸め処理、小数点変換、スリッページに関する前提、トークンの互換性も確認してください。手数料徴収型トークン、リベーストークン、ブラックリストや一時停止機能を持つトークンなど、特殊なトークンも考慮する必要があります。緊急時の管理機能や、市場が不安定な状況での出金動作も確認します。監査済みのDeFiプロトコルでも、流動性が薄い場合やガバナンスが中央集権化している場合、ユーザーには依然としてリスクがあります。監査状況は、DeFiのデューデリジェンスの一要素として確認してください。

ブリッジのセキュリティ監査

ブリッジ監査は、暗号資産のセキュリティ監査の中でも特に重要で難易度の高いものです。ブリッジは、一方のチェーンで資産をロックし、別のチェーンで資産をミントまたは解放する場合があります。これにより、スマートコントラクト、メッセージ検証、リレイヤー、バリデーター、署名、カストディ、ファイナリティに関する前提など、複数のリスクが生じます。監査人は、別のチェーンでイベントが発生したことをブリッジがどのように証明するかを確認してください。バリデーターキーの保護方法と、必要な署名数も確認する必要があります。ブリッジ監査では、リプレイ攻撃、不正なメッセージの受け入れ、チェーンの再編成リスク、出金上限、緊急停止をテストするべきです。監査済みでも、クロスチェーンシステムは単純なトークン移転より多くの前提に依存するため、ユーザーはブリッジの利用に注意が必要です。ブリッジ監査では、こうした前提を明確に説明する必要があります。

NFTとゲームのセキュリティ監査

NFTやゲームの監査では、ミントのロジック、メタデータの管理、乱数、ロイヤリティ、移転制限、マーケットプレイスでの承認、ゲーム内資産のルールを確認します。ミステリーミント、ルートボックス、ランダムな属性に対してユーザーが支払う場合、乱数の仕組みは特に重要です。乱数が弱いと、内部関係者、マイナー、バリデーター、ボットが結果を予測または操作できる可能性があります。プロジェクトの所有者がメタデータを誤解を招く形で変更できるかどうかも監査人が確認するべきです。ゲームプロジェクトでは、資産のミント、バーン、報酬、インベントリのロジック、クロスチェーンの資産移転を確認する必要があります。ミントコントラクトが監査済みというだけで、プロジェクトが安全だと判断しないでください。ウェブサイト、ウォレットの確認画面、マーケットプレイスでの承認、管理者権限も重要です。可能であれば、NFT監査ではユーザーの利用手順全体を対象にするべきです。

ウォレットのセキュリティ監査

ウォレットはユーザーとブロックチェーンをつなぐ主要なインターフェースであるため、その監査は重要です。ウォレット監査では、シードフレーズの生成、秘密鍵の保管、署名の手順、アドレス表示、バックアップ手順、取引シミュレーション、フィッシング対策を確認する必要があります。ブラウザー拡張機能の権限、モバイルアプリのデータ保管、ハードウェアウォレットとの連携、アップデートの配布も確認してください。誤ったデータに署名したり、誤ったアドレスを表示したり、重要な取引内容を隠したりすると、ウォレットに問題が生じる可能性があります。ユーザーが承認内容を理解する必要があるため、ウォレット監査には使いやすさの確認も含めるべきです。署名内容が分かりやすければミスを減らせる可能性がありますが、取引の詳細が正確に表示されることが前提です。ウォレットのセキュリティは、安全なアップデート経路と偽造版への対策にも左右されます。ウォレットは信頼できる情報源からのみダウンロードし、リカバリーフレーズはオフラインで保護してください。

セキュリティ監査とガバナンスリスク

トークン保有者、デリゲーター、マルチシグ、管理者ロールがプロトコルの動作を変更できる場合、ガバナンスリスクが生じます。監査では、投票ルール、提案のしきい値、定足数、タイムロック、緊急時の権限、実行ロジックを確認する必要があります。攻撃者が議決権を借り入れたり、悪意ある提案を可決したり、遅延を回避したりできないか確認してください。少数のグループがコントラクトをアップグレードしたり、財務資金を移動したりできないかも確認します。透明性が高く適切に設計されていれば、ガバナンスは強みになります。一方、十分に保護されていないキーや参加率の低い投票システムに広範な権限を与えると、リスクとなります。ユーザーは監査報告書でガバナンスに関する前提を確認してください。プロトコルが技術的に監査済みでも、強く中央集権化されている可能性があります。

セキュリティ監査と運用セキュリティ

運用セキュリティとは、チームがキー、デプロイ、アクセス権、モニタリング、緊急時対応をどのように管理するかを指します。コードが安全でも、運用が安全とは限りません。たとえば、デプロイ用のキーが安全でないノートパソコンに保管されている場合があります。マルチシグの署名者が少なすぎたり、署名者が適切に分散されていなかったりする場合もあります。チェックリストなしにアップグレードが実行されることもあります。攻撃中にアラートシステムが機能しない可能性もあります。ユーザー資金に影響する場合、こうした運用上の前提もセキュリティ監査で確認する必要があります。強固な運用セキュリティには、安全なキー保管、役割分担、ログ記録、モニタリング、インシデント対応手順、適切な事後検証が含まれます。

セキュリティ監査の限界

セキュリティ監査ですべてのバグを見つけられるわけではありません。プロトコルが今後一度も攻撃されないことを保証するものでもありません。将来の市場環境、ガバナンス上の判断、連携の変更を完全に予測することもできません。監査対象外のシステムでユーザーが悪意ある取引に署名することを防ぐこともできません。チームが指摘事項に対応しない限り、不十分な文書、急いだデプロイ、適切でないインシデント対応を監査だけで改善することはできません。未監査の将来のアップグレードを安全にするものでもありません。そのため、「監査済み」を安全かどうかの二択の表示として扱うべきではありません。実際に確認すべきなのは、何が監査され、誰がレビューし、何が見つかり、何が修正され、どのようなリスクが残っているかです。

セキュリティ監査で注意すべき危険信号

監査済みと主張するプロジェクトに公開された監査報告書がない場合は、危険信号です。監査報告書に対象範囲、コミットハッシュ、指摘事項の詳細がない場合も危険信号です。Criticalの指摘事項が未解決のまま記載されている報告書は、重大な警告となります。監査後に新たなレビューを受けずコードを変更したプロジェクトには、追加のリスクがあります。管理者権限やアップグレード権限を隠しているプロジェクトには注意が必要です。監査が安全性を保証すると主張するプロジェクトは、誤解を招く説明をしています。テストスイート、モニタリング、緊急時対応プロセスがないプロジェクトは、監査後もリスクが残る可能性があります。監査をマーケティングにしか使っていない場合は、慎重に判断してください。

監査を依頼する前のベストプラクティス

チームは監査を依頼する前に、明確な文書を作成するべきです。コードを凍結するか、レビュー対象となる正確なコミットを定義してください。アーキテクチャ図、脅威モデル、デプロイ計画、想定される不変条件を準備しましょう。テストスイート全体を含め、既知の問題について説明してください。監査中に大規模な機能を追加することは避けるべきです。監査人が慎重に確認できるだけの時間を確保してください。質問には迅速に回答し、指摘事項には十分に検討して対応します。監査人を直前のチェックリストとして扱うチームよりも、準備を整えたチームのほうが監査から多くの成果を得られます。

監査後のベストプラクティス

チームは公開前に重大な指摘事項を修正するべきです。重要な修正について、監査人に再確認を依頼しましょう。安全で適切な場合は、最終報告書を公開してください。認識したものの修正しなかったリスクを文書化します。デプロイ済みのバイトコードとコントラクトアドレスを検証しましょう。公開後もプロトコルを監視する必要があります。プロトコルが相応の価値を管理する場合、バグ報奨金または責任ある脆弱性開示のプロセスを用意するべきです。大規模なアップグレードに合わせて、新たな監査を計画してください。

ユーザーが監査済みプロジェクトを評価する方法

まず、監査報告書が実在し、公開されていることを確認してください。現在デプロイされているコントラクトが報告書の対象かどうかを確認します。未解決のCriticalまたはHighの問題を確認してください。価値の高いシステムや複雑なシステムでは、複数の監査を受けているか確認します。管理者による制御、アップグレード可能性、オラクル設計、カストディ、ブリッジへの依存を確認してください。バグ報奨金、モニタリング、緊急停止計画があるかも確認します。預かり資産総額（TVL）も考慮してください。価値が高いほど、強力な攻撃者を引き付ける可能性があります。監査によって信頼性は高まりますが、警戒を解くべきではありません。

セキュリティ監査と保険

監査を確認した後、保険や補償の有無を調べる暗号資産ユーザーもいます。監査は保険会社やリスク評価者によるプロトコルの理解に役立つ場合がありますが、それ自体で保険による保護が生じるわけではありません。補償条件では、特定のエクスプロイト、ガバナンスの不全、オラクル攻撃、ブリッジの障害、ユーザーのミスが対象外となる場合があります。保険を頼りにする前に、条件を慎重に確認してください。実際の補償契約がない限り、監査済みであることを理由にユーザーが金銭的に保護されると示すべきではありません。保険、監査、バグ報奨金、モニタリングは、それぞれ異なるリスク管理手段です。それぞれに異なる制限があります。強固なセキュリティには複数の防御層が必要です。

セキュリティ監査と規制上の期待

暗号資産規制では、セキュリティ管理、カストディ、情報開示、運用のレジリエンス、リスク管理への注目が高まっています。セキュリティ監査は、プロジェクトが技術的リスクを真剣に考慮したことを示す一助となる場合があります。ただし、スマートコントラクト監査は法令遵守とは別のものです。トークンが監査済みでも、証券、消費者保護、制裁、税務、カストディに関する問題が生じる可能性があります。ユーザー資金を扱うプロジェクトは、技術レビューと併せて法的レビューも検討するべきです。セキュリティとコンプライアンスは異なる分野ですが、暗号資産商品では重なることがよくあります。たとえば、トークン化資産のプラットフォームには、スマートコントラクト監査と所有記録に関する法的管理の両方が必要となる場合があります。技術的なセキュリティと規制当局の承認を混同しないでください。

セキュリティ監査に関するよくある誤解

よくある誤解は、監査済みなら安全だというものです。監査済みとは、定められた範囲でレビューが行われたことを意味し、将来にわたって安全であることを保証するものではありません。別の誤解は、一度の監査で将来のすべてのバージョンをカバーできるというものです。新しいコード、資産、チェーン、連携によって、新たなリスクが生じる可能性があります。自動化ツールが人間の監査人の代わりになるという誤解もあります。ツールは役立ちますが、状況に応じたロジックの欠陥を見落とすことがあります。スマートコントラクトだけを監査すればよいという誤解もあります。ウォレット、ブリッジ、フロントエンド、バックエンド、ガバナンスシステム、運用プロセスもセキュリティレビューが必要です。

よくある質問

暗号資産分野のセキュリティ監査とは何ですか？

暗号資産分野のセキュリティ監査とは、攻撃者が悪用する前に脆弱性を特定するため、スマートコントラクト、プロトコル、ウォレット、インフラを体系的にレビューすることです。

スマートコントラクト監査とは何ですか？

スマートコントラクト監査とは、オンチェーンコードのセキュリティレビューです。バグ、安全でないロジック、アクセス制御の問題、オラクルの問題、その他の攻撃経路を確認します。

監査済みなら暗号資産プロジェクトは安全ですか？

いいえ。監査によって信頼性は高まりますが、プロジェクトが完全に安全であることや、将来の攻撃を受けないことが保証されるわけではありません。

監査報告書には何を記載すべきですか？

監査報告書には、対象範囲、コミットハッシュ、方法論、指摘事項、重大度、推奨事項、修正状況、制限事項、残存リスクを記載するべきです。

スマートコントラクトに監査が必要なのはなぜですか？

スマートコントラクトはユーザー資金を直接管理でき、デプロイ後に変更するのが難しい場合があるため、監査が必要です。

監査とバグ報奨金の違いは何ですか？

監査は選定された監査人による集中的なレビューです。バグ報奨金は、外部の研究者が脆弱性を報告した場合に報酬を提供する継続的なプログラムです。

自動化ツールはセキュリティ監査人の代わりになりますか？

いいえ。自動化ツールは既知のパターンを見つけるのに役立ちますが、ロジックの欠陥、経済的攻撃、プロトコル固有の検討には人間の監査人が必要です。

監査でよく見つかる問題は何ですか？

リエントランシー、アクセス制御の不備、オラクル操作、安全でないアップグレード、署名のリプレイ、不適切な乱数生成、会計ミスなどがよく見つかります。

暗号資産プロジェクトはどのくらいの頻度で監査を受けるべきですか？

大規模なローンチの前に監査を受け、さらに大規模なアップグレード、新モジュールや新資産の追加、連携、基礎となる前提の変更の際にも監査を受けるべきです。

監査範囲とは何ですか？

監査範囲とは、レビュー対象に含まれたコード、コントラクト、システム、文書、前提の具体的な範囲です。

監査でコミットハッシュが重要なのはなぜですか？

コミットハッシュを使うと、監査人が確認したコードの正確なバージョンをユーザーが検証できます。

監査済みのコントラクトがハッキングされることはありますか？

あります。監査でバグを見落とす場合や、後からコードが変更される場合、前提が崩れる場合、監査範囲外が攻撃される場合があるためです。

監査済みという理由だけでプロジェクトを信頼すべきですか？

いいえ。未解決の指摘事項、管理者権限、アップグレード可能性、オラクルリスク、ブリッジリスク、流動性、バグ報奨金、プロジェクトの運用セキュリティも確認してください。

まとめ

セキュリティ監査は、暗号資産のリスク低減において特に重要な手段の一つです。攻撃者に悪用される前に、スマートコントラクトのバグ、プロトコル設計の欠陥、安全でない権限、経済的な攻撃経路、運用上の弱点を見つけるのに役立ちます。優れた監査では、コードだけでなく、前提、アーキテクチャ、アクセス制御、アップグレード可能性、オラクル、デプロイスクリプト、ユーザーに影響するリスクも確認します。ただし、セキュリティ監査は保証ではありません。監査は期間と対象範囲が限定されており、監査人、文書、コードベース、テスト、修正プロセスの品質に左右されます。優れた暗号資産プロジェクトは、安全な設計、テスト、形式手法、バグ報奨金、モニタリング、インシデント対応、慎重なアップグレードを含むセキュリティライフサイクルの一部として監査を扱います。ユーザーは監査報告書を、マーケティング文句ではなく、有用な証拠として捉えるべきです。実務上の原則はシンプルです。監査済みのプロジェクトは未監査のものより安全な可能性がありますが、重要なのは、何が監査され、何が見つかり、何が修正され、どのようなリスクが残っているかです。