SEAL認証とは？暗号資産の運用上のセキュリティを保証する仕組み

SEAL Certificationsは、Security Alliance（SEAL）が公開するオープンソースの運用セキュリティ認証プログラムです。現行のv0.0.1ベースラインでは、コントロールと呼ばれる99項目の具体的な運用要件を、暗号資産プロトコルを取り巻く人員、アカウント、署名者、ドメイン、インフラ、財務管理プロセス、対応能力を対象とする6つのモジュールに整理しています [1, 2]。

BlockSecは、このプログラムで最初に認定された評価機関の1つであり、現在、アジアに本社を置く唯一の認定評価機関です。SEAL認定評価機関として、当社はクライアントとともに評価範囲を定め、選択されたコントロールと証拠を評価し、不足点を文書化したうえで、対象範囲の要件が満たされているかを判断します。要件が満たされている場合は、SEALの認定に基づきオンチェーンのアテステーションを発行します [4]。

この記事では、組織がSEAL認証を取得する理由、認証結果が意味すること、適用され得るモジュール、当社の評価方法、そしてチームが評価に向けて準備する方法を説明します。

1. SEAL認証を取得する理由

SEALがこのフレームワークを設けた理由は、暗号資産分野における悪用事案の主な原因が、スマートコントラクトの脆弱性から運用上の不備へと移っていることです [1]。そのため評価では、署名者、マルチシグ、ドメイン、認証情報、インフラ監視、インシデント対応に関するコントロールに注意が向けられます。SEAL認証の評価では、それらのコントロールが実際に機能し、証拠によって裏付けられるかを確認します。これにより、暗号資産関連組織は、どのコントロールがベースラインを満たし、どこに不足が残るかについて、独立した見解を得られます [1, 3]。

SEAL認証が答える保証上の問いは1つです。合意された範囲内の運用コントロールは、独立した評価を受け、公開されている暗号資産分野固有の運用セキュリティ基準を満たすと認められたか？ プロトコル、取引所、決済プラットフォーム、カストディアンなどの暗号資産関連組織は、投資家、上場審査チーム、コンプライアンス関係者、社内のガバナンス機関、保険会社、デューデリジェンスの審査担当者から運用コントロールに関する独立した証拠を求められる際に、この保証を必要とする場合があります。結果には、評価対象となったモジュールと境界、およびその範囲がベースラインを満たしたかどうかが記録されます [5, 6]。

この保証の範囲は、隣接するセキュリティ活動と比較するとより明確になります。評価では、リポジトリ、CI/CD、インフラのコントロールに関する、コードに関連した運用上の証拠を調べる場合があります。具体的には、権限、ブランチ保護設定、コードレビュー記録、セキュリティスキャン結果、パイプラインのコントロール、インフラ構成などです [7]。実装上の脆弱性を発見したり、プロトコルのロジックが正しいかを判断したりするためにソースコードをレビューするものではありません [1]。これらや関連する目的は、別のセキュリティ活動が担います。コード監査はソースコードの実装上の脆弱性とプロトコルロジックの欠陥を評価し、ペネトレーションテストは合意された環境で悪用可能な経路を再現できるかを評価します。バグバウンティは外部からの発見事項を継続的に受け付ける窓口となり、継続的な監視は継続的な検知と対応を支えます。

SEAL認証は独立した評価プログラムです。認証は、選択された範囲がSEALの要件を満たした場合にのみ発行されます [6]。コード監査、ペネトレーションテスト、バグバウンティ、継続的な監視は別個の活動であり、いずれも認証の前提条件ではありません。

より広範な保証基準についても、同じ区別が当てはまります。SEALの意見募集記事によると、SOC 2とISO 27001は引き続き有用であり、多くの組織にとって最終的には必要になるものの、多額のオンチェーン資産を管理する小規模な分散型チームのような、暗号資産分野に特有の運用モデルを念頭に設計されたものではありません [5]。SEALフレームワークは、暗号資産分野の運用コントロールに対する、より焦点を絞った出発点を提供し、これらの広範な基準と併用できます。

2. 認証が証明すること

SEAL認証の結果は、評価のために選択された運用コントロール、モジュール、境界に適用されます。選択されたコントロールがSEALの要件を満たすと、BlockSecのようなSEAL認定評価機関が、その認定に基づき、該当するSEALバッジとともにEthereum Attestation Serviceを通じてオンチェーンのアテステーションを発行します [4]。アテステーションは公開されますが、詳細な評価報告書と証拠は評価機関とクライアントの間で秘密として扱われます [1]。以下の表は、合格という結果によって裏付けられる結論と、その範囲外にある主張を区別したものです。

これらの限界は発行後も変わりません。SEALのアテステーションは、プロトコルにセキュリティ上の問題がないことを示すものではありません [1]。有効期間には限りがあり、定期的な再評価が必要です。また、継続的な不適合があった場合には取り消されることがあります。SEALは固定の有効期間を公表していません [1]。

3. フレームワークの対象範囲

6つのモジュールは、個別にもまとめても評価できます。現行のベースラインには99項目のコントロールが含まれています [1, 2]。適用され得る場合の列は、モジュールの定義に基づく編集上の目安であり、SEALの公式な範囲設定ルールではありません。最終的な範囲は、評価の際にクライアントと確認します。

各モジュールを個別に評価する場合でも、運用上のつながりは残ります。DevOps・インフラとDNS・レジストラに含まれる一部のコントロールは、ID・アカウントで定義されるアカウントセキュリティの実践に依存しています。インシデント対応の要件も、マルチシグ署名者の連携やインシデント時のアカウント復旧など、複数のモジュールに含まれています [2]。

こうしたモジュール間の参照は、対象範囲内のコントロールに必要な証拠に影響しますが、参照先のモジュールが自動的に認証されるわけでも、認証の順序が定められるわけでも、評価範囲が拡大するわけでもありません。DNS・レジストラのコントロールがアカウントセキュリティの実践に依存しているだけで、DNS・レジストラのアテステーションがID・アカウントのアテステーションになることはありません。アテステーションが適用されるのは、その範囲として明示されたモジュールと境界のみです [1, 6]。

4. 評価の進め方

SEALはフレームワークを維持し、認証プログラムを運営しています。SEAL認定評価機関として、当社は各クライアントの評価を5つのステップで実施します [1, 4]：

図1. SEAL認証の評価は、合意された範囲の設定から証拠のレビュー、是正、再評価を経て、アテステーションの発行へと進みます。

1. 範囲設定。 対象となるモジュール、コントロール、システム、業務、組織上の境界について、クライアントと合意します。

2. 証拠の収集。 クライアントは、対象範囲内のコントロールがどのように設計され、担当者が割り当てられ、運用され、レビューされているかを示す資料を提供します。

3. 評価。 当社はSEALの公開要件に照らして証拠を評価し、不足している、または裏付けが不十分な点を特定します。

4. 必要に応じた是正。 合意された範囲がベースラインを満たさない場合、当社は不足点をまとめた報告書を提供します。クライアントは特定された不足点に対応し、再評価のために更新した証拠を提出します。

5. 認証。 合意された範囲がベースラインを満たした場合、当社はSEALの認定に基づき、正式なオンチェーンのアテステーションを発行します。

証拠の収集と評価は一体となって進みます。クライアントが裏付け資料を提供し、BlockSecが各コントロールの実際の運用をその資料によって示せるか評価します。SEALの認証ガイドラインは裏付けとなる証拠を5つのカテゴリーに分類しています。以下に、ガイドラインとモジュールのベースラインに示された例とともにまとめます [2, 3, 7]：

BlockSecはこれらの証拠を用いて、対象範囲内の各コントロールを「実装済み」「一部実装済み」「未実装」、または理由を付した「該当なし」として記録します。正式な認証には、合意された範囲内のコントロールが、主張を裏付ける証拠とともに「実装済み」、または妥当な理由に基づく「該当なし」であることが必要です。したがって、基礎となる評価はコントロールごとに行われますが、認証の最終判断は合意された範囲全体に対する合否の二択となります [3, 6]。

5. 準備の方法

SEAL認証の評価を開始する前に、次の4点を準備してください。

1. 提案する評価範囲： 意図する認証上の主張に関係するモジュール、システム、法人・組織、チーム、境界。

2. コントロールごとの自己評価： 各要件について「実装済み」「一部実装済み」「未実装」「該当なし」のどれに当たると考えるか、および各回答の根拠。

3. 証拠の一覧： 提案する評価範囲に対応付けた、既存の手順書、運用記録、テスト結果、責任者の記録、技術的な資料。

4. 担当者の指定： 範囲に関する意思決定、証拠の収集、是正の調整を担当する人員。

フレームワークとチェックリストは公開されているため、チームは正式な評価を始める前からこの作業に着手できます。自己評価は、文書化されていないプロセス、運用の証拠の不足、担当者が割り当てられていないコントロール、既知の是正事項を見つけるのに役立ちます。ただし、あくまで社内での確認です。独立した検証を受けるものではなく、SEALのアテステーションも発行されません [1, 3]。

この4点は初期の範囲設定に役立ちますが、詳細な資料の依頼内容は選択するモジュールによって異なります。上記のモジュール名は対象領域を定義するものであり、必須の認証順序を示すものではありません。各モジュールのコントロールに関する詳しいガイダンスは、専用の記事で順次提供します。モジュールの選択、証拠の準備状況、評価範囲についてのご相談は、お問い合わせください [需实证:CONTACT_OR_RELEVANT_PAGE_URL]。

参考文献

1. Security Alliance、SEAL認証フレームワーク：概要。フレームワークの背景、モジュール、独立した範囲設定、評価の流れ、自己評価、アテステーションとバッジ、秘密保持、再評価、取り消し。https://frameworks.securityalliance.org/certs/overview/

2. Security Alliance、全認証のエクスポート（XLSX）。現行のモジュール別コントロール数とモジュール間の参照。SEAL認証フレームワークの概要から入手できる公式エクスポートと照合済み。2026年9月閲覧。https://frameworks.securityalliance.org/certs/overview/

3. Security Alliance、認証ガイドライン。コントロールごとのステータス、認証基準、証拠のカテゴリー。https://frameworks.securityalliance.org/certs/certification-guidelines/

4. Security Alliance、評価機関の認定、およびSEAL認証。認定プロセス、評価機関の責任、プログラムの状況、現在公開されているパートナー情報。https://frameworks.securityalliance.org/certs/certified-partners/ および https://securityalliance.org/our-work/certifications

5. Security Alliance Radar、意見募集：SEAL認証。コントラクトセキュリティの成熟度、SOC 2とISO 27001の位置付け、モジュール方式、検証可能性の根拠。https://radar.securityalliance.org/request-for-comments-seal-certifications/

6. Security Alliance Radar、SEAL認証：提供開始（Isaac Patka、2026年6月2日）。6領域の概要と、合意された範囲全体に対する単一の合否判断。https://radar.securityalliance.org/seal-certifications-auditor-accreditations-protocol-assessments/

7. Security Alliance、SFC：DevOps・インフラ。リポジトリの権限、ブランチ保護、コードレビューとスキャンのコントロール、CI/CD、サプライチェーン管理、インフラ構成に関する公開ベースライン。https://frameworks.securityalliance.org/certs/sfc-devops-infrastructure/