SEAL Certificationsは、Security Alliance（SEAL）が公開するオープンソースの運用セキュリティ認証プログラムです。現行のベースラインでは、コントロールと呼ばれる99の具体的な運用要件を、暗号資産プロトコルに関わる人員、アカウント、署名者、ドメイン、インフラ、財務管理プロセス、対応能力を対象とする6つのモジュールに整理しています [1, 2]。
BlockSecは、このプログラムで最初に認定された評価機関の一つであり、現在、アジアに本社を置く唯一の認定評価機関です。SEAL認定評価機関として、当社はクライアントとともに対象範囲を定め、選定したコントロールと証拠を評価し、不備を文書化したうえで、対象範囲の要件が満たされているかを判断します。要件が満たされている場合は、SEALの認定に基づき、オンチェーンの証明を発行します [4]。
この記事では、組織がSEAL認証の取得を目指す理由、認証結果が意味すること、適用され得るモジュール、当社による評価の進め方、評価への準備方法を説明します。
1. SEAL認証を取得する理由
SEALがこのフレームワークを設けた背景には、暗号資産分野における悪用事案の主な原因が、スマートコントラクトの脆弱性から運用上の不備へと移っているという認識があります [1]。そのため評価では、署名者、マルチシグ、ドメイン、認証情報、インフラ監視、インシデント対応に関するコントロールに目を向けます。SEAL認証の評価では、それらのコントロールが実際に運用され、証拠で裏付けられるかを確認します。これにより暗号資産関連の組織は、どのコントロールがベースラインを満たし、どこに不備が残っているかについて、独立した評価を得られます [1, 3]。
SEAL認証が答える保証上の問いは一つです。合意した対象範囲内の運用コントロールは、公開された暗号資産分野向けの運用セキュリティ基準に適合していると、独立した評価によって確認されたか。 プロトコル、取引所、決済プラットフォーム、カストディアンなどの暗号資産関連組織は、投資家、上場審査チーム、コンプライアンス関係者、社内ガバナンス機関、保険会社、デューデリジェンスの審査担当者から運用コントロールに関する独立した証拠を求められた際に、こうした保証を必要とする場合があります。結果には、評価したモジュールと対象範囲の境界、およびその範囲がベースラインを満たしたかどうかが記録されます [5, 6]。
この保証の範囲は、関連するセキュリティ評価と比較すると明確になります。評価では、リポジトリ、CI/CD、インフラのコントロールについて、権限、ブランチ保護設定、コードレビュー記録、セキュリティスキャン結果、パイプラインのコントロール、インフラ構成など、コードに関連する運用上の証拠を調べる場合があります [7]。一方、実装上の脆弱性を発見したり、プロトコルのロジックが正しいかを判断したりするためにソースコードをレビューするものではありません [1]。以下の表では、SEAL認証をコード監査およびペネトレーションテストと比較します。
| 比較項目 | SEAL認証 | コード監査 | ペネトレーションテスト |
|---|---|---|---|
| 主な評価対象 | 合意したモジュールと境界内の運用コントロールおよび裏付けとなる証拠 | 合意した監査範囲内のソースコードおよびプロトコルのロジック | 合意した環境および実施条件内のシステムと攻撃対象領域 |
| 主な問い | 対象範囲内の運用コントロールは、十分な裏付けとなる証拠を伴ってSEALの要件を満たしているか | 対象範囲内のコードに実装上の脆弱性やプロトコルのロジック上の欠陥があるか | 合意した環境で悪用可能な経路を再現できるか |
| 評価方法 | 文書、運用記録、設定、インタビュー、および必要に応じたテストの証拠を通じてコントロールの実装を確認 | 対象範囲内のソースコードと関連仕様をレビューし、実装やロジックの欠陥を確認 | 合意した攻撃対象領域をテストし、特定した弱点を実施条件内で悪用できるか検証 |
| 結果 | 対象範囲の要件を満たした場合は認証と対応するオンチェーンの証明、満たさない場合は不備に関する所見 | 監査範囲に関するセキュリティ上の所見と是正の推奨事項 | テスト範囲に関するセキュリティ上の所見と是正の推奨事項 |
これらのサービスは、それぞれ異なる評価目的に対応します。テストは一部のSEALコントロールの証拠となり得ますが、監査やペネトレーションテストだけでSEAL認証が成立するわけではありません。
SEAL認証は独立した評価プログラムです。認証は、選定した対象範囲がSEALの要件を満たした場合にのみ発行されます [6]。コード監査とペネトレーションテストは別の活動であり、いずれも認証の前提条件ではありません。
より広範な保証基準についても、同じ区別が当てはまります。SEALの意見募集記事によると、SOC 2とISO 27001は引き続き有用であり、最終的には多くの組織に必要になります。しかし、多額のオンチェーン資産を管理する小規模な分散チームのような、暗号資産分野特有の運用モデルを想定して設計されたものではありません [5]。SEALフレームワークは、暗号資産分野の運用コントロールに焦点を絞った出発点を提供し、そうした広範な基準と併用できます。
2. 認証が証明すること
SEAL認証の結果は、評価のために選定した運用コントロール、モジュール、境界に適用されます。選定したコントロールがSEALの要件を満たした場合、BlockSecのようなSEAL認定評価機関が、その認定に基づき、該当するSEALバッジとともに、Ethereum Attestation Serviceを通じてオンチェーンの証明を発行します [4]。証明は公開されますが、詳細な評価報告書と証拠は評価機関とクライアントの間で秘密として扱われます [1]。以下の表では、合格という結果が裏付ける結論と、その範囲外にある主張を区別します。
| SEAL認証に合格した結果が示すこと | 示さないこと |
|---|---|
| 評価対象の組織が、合意した範囲内のモジュールと境界についてSEALの要件を満たしたこと | 記載されていないモジュールや運用システムも評価されたこと |
| 対象範囲内の運用コントロールと裏付けとなる証拠について、独立した第三者による確認が行われたこと | ソースコードの実装上の欠陥がレビューされたこと、攻撃経路がテストされたこと、またはプロトコルに脆弱性がないこと |
| 合意した範囲全体で、コントロールごとに適合が確認されたこと | セキュリティスコア、成熟度の段階、コード品質に関する見解、または規制当局の承認 |
| 再評価が必要な、特定時点での有効期間が限られた認証であること | 継続的な適合、またはインシデントが発生しないという保証 |
こうした限界は、発行後も変わりません。SEALの証明は、プロトコルにセキュリティ上の問題がないことを示すものではありません [1]。有効期間は限られ、定期的な再評価が必要であり、要件を満たさない状態が続いた場合には取り消される可能性があります。SEALは固定の有効期間を公表していません [1]。
3. フレームワークの対象範囲
6つのモジュールは、個別にもまとめても評価できます。現行のベースラインには99のコントロールが含まれます [1, 2]。When it may apply列は、モジュールの定義に基づく編集上の目安であり、SEALの公式な対象範囲設定ルールではありません。最終的な対象範囲は、評価の過程でクライアントと確認します。
| モジュール | 対象となる事項 | 適用され得る場合 |
|---|---|---|
| マルチシグ運用（24コントロール） | 署名者の設定、トランザクションの実行、連携、継続性、緊急時の手順 | マルチシグウォレット、署名者グループ、または連携を要するトランザクション承認がある場合 |
| 財務管理業務（23コントロール） | カストディの構成、資産管理、トランザクションのガバナンス、照合、監視、ベンダー管理、保険、財務管理上の対応 | 財務管理対象の資産、資産配分、カストディ関係、または資金移動がある場合 |
| インシデント対応（13コントロール） | 準備、エスカレーション、連絡、対応手順書、訓練、連携した対応 | セキュリティインシデントの検知、封じ込め、連絡、復旧を担うチームがある場合 |
| DevOpsとインフラ（15コントロール） | リポジトリのガバナンス、コードレビューとスキャンのコントロール、CI/CD、サプライチェーン管理、インフラへのアクセス、監視、回復力 | コードリポジトリ、デプロイパイプライン、クラウドインフラ、または本番環境の管理業務がある場合 |
| DNSとレジストラ（16コントロール） | ドメインの所有権、レジストラへのアクセス、DNS設定、監視、復旧、乗っ取りへの対応 | 重要なドメイン、レジストラのアカウント、DNSレコード、またはメール認証がある場合 |
| アイデンティティとアカウント（8コントロール） | アカウントの棚卸し、所有者、フィッシング耐性のある認証、認証情報の管理、復旧、アクセス権のレビュー、ライフサイクル管理、監視、第三者アクセス | リポジトリ、クラウドプラットフォーム、レジストラ、カストディシステム、または社内ツールに、人、サービス、特権のアカウントがある場合 |
DNSとレジストラのモジュールについて詳しくは、スマートコントラクトの先へ：Web3におけるドメインとDNSの運用セキュリティをご覧ください。
各モジュールを独立して評価する場合でも、運用上のつながりは残ります。DevOpsとインフラ、およびDNSとレジストラの一部のコントロールは、アイデンティティとアカウントで定義されたアカウントセキュリティの実務に依存します。インシデント対応の要件も、インシデント発生時のマルチシグ署名者の連携やアカウントの復旧など、複数のモジュールに含まれています [2]。
こうしたモジュール間の参照は、対象範囲内のコントロールに必要な証拠には影響しますが、参照先のモジュールを自動的に認証したり、必須の認証順序を設けたり、評価の範囲を広げたりするものではありません。DNSのコントロールがアカウントセキュリティの実務に依存するというだけで、DNSとレジストラの証明がアイデンティティとアカウントの証明になるわけではありません。証明が適用されるのは、その対象範囲に明記されたモジュールと境界に限られます [1, 6]。
4. 評価の進め方
SEALはフレームワークを維持し、認証プログラムを運営しています。当社はSEAL認定評価機関として、各クライアントの評価を5つのステップで実施します [1, 4]。
図1。SEAL認証の評価は、対象範囲の合意から証拠の確認、是正、再評価を経て、証明の発行へと進みます。
-
対象範囲の設定。 どのモジュール、コントロール、システム、業務、組織上の境界を対象範囲に含めるか、クライアントと合意します。
-
証拠の収集。 クライアントが、対象範囲内のコントロールの設計、担当者への割り当て、運用、レビューの方法を示す資料を提供します。
-
評価。 当社がその証拠をSEALの公開要件に照らして評価し、不足している裏付けや不十分な裏付けを特定します。
-
是正と再評価。 合意した対象範囲がベースラインを満たさない場合、当社は不備の報告書を提供します。クライアントは特定された不備に対処し、再評価のために更新した証拠を提出します。
-
認証。 合意した対象範囲がベースラインを満たした場合、当社はSEALの認定に基づき、正式なオンチェーンの証明を発行します。
証拠の収集と評価は一体となって進みます。クライアントが裏付け資料を提供し、BlockSecが、それらによって各コントロールが実際に運用されていることを示せるか評価します。SEALの認証ガイドラインは、裏付けとなる証拠を5つのカテゴリーに分類しています。以下に、ガイドラインとモジュールのベースラインにある例とともにまとめます [2, 3, 7]。
| 証拠のカテゴリー | 示すうえで役立つこと |
|---|---|
| 手順書 | 方針、版、承認日を含む、意図されたコントロール |
| 運用の証拠 | ログ、記録、チケット、チームメンバーへのインタビューを通じて、プロセスが実際に使われていること |
| テスト・検証 | 保護策や対応プロセスが実地に試された、または確認されたこと |
| 担当者に関する詳細 | 誰がコントロールを維持し、どの頻度でレビューし、最後にいつ更新したか |
| 技術的資料 | リポジトリやCI/CDの設定、クラウドの構成、レジストラやDNSからのエクスポート、その他の対象範囲内の技術的証拠を含む、設定、スクリーンショット、システムからのエクスポート |
BlockSecはこれらの証拠を用い、対象範囲内の各コントロールを、理由とともに「実装済み」「一部実装済み」「未実装」「該当なし（N/A）」のいずれかとして記録します。正式な認証には、合意した範囲内のコントロールが「実装済み」であるか、根拠を示して「該当なし」と判断され、かつ、その判断を裏付ける証拠があることが必要です。したがって、基礎となる評価はコントロールごとに行われますが、認証の総合判断は合意した範囲全体についての可否の二択となります [3, 6]。
5. 準備の進め方
SEAL認証の評価を始める前に、次の4点を準備してください。
-
対象範囲の案： 取得を目指す認証で示したい内容に関係するモジュール、システム、主体、チーム、境界。
-
コントロールごとの自己評価： 各要件が「実装済み」「一部実装済み」「未実装」「該当なし（N/A）」のいずれに当たると考えられるか、および各判断の根拠。
-
証拠の一覧： 提案する対象範囲に対応付けた、既存の手順、運用記録、テスト結果、担当者に関する記録、技術的資料。
-
担当者の指定： 対象範囲の決定、証拠の収集、是正の調整を担当する人員。
フレームワークとチェックリストは公開されているため、正式な評価を依頼する前からこの作業に着手できます。自己評価は、文書化されていないプロセス、運用の証拠の不足、担当者が割り当てられていないコントロール、既知の是正作業を見つけるのに役立ちます。ただし、あくまで内部での確認段階であり、独立した検証を受けたものではなく、SEALの証明も発行されません [1, 3]。
これら4点は初期の対象範囲設定に役立ちます。詳細な資料の依頼内容は、選定するモジュールによって異なります。上記のモジュール名は対象領域を定義するものであり、必須の認証順序を示すものではありません。各モジュールのコントロールに関するガイダンスは、専用の記事を順次公開する予定です。モジュールの選定、証拠の準備状況、評価の対象範囲については、[email protected]までお問い合わせください。
参考資料
- Security Alliance、SEAL認証フレームワーク：概要。
- Security Alliance、すべての認証をエクスポート（XLSX）。フレームワークの概要ページから入手可能。コントロール数とモジュール間の参照についても、2026年10月に公開済みの6つのモジュールページと照合。
- Security Alliance、認証ガイドライン。
- Security Alliance、監査人の認定、SEAL認証。
- Security Alliance Radar、意見募集：SEAL認証。
- Isaac Patka、Security Alliance Radar、SEAL認証：提供開始（2026年6月2日）。
- Security Alliance、SFC：DevOpsとインフラ。
