パート 5: レジャーリカバリの起源 - 運用上のセキュリティ | 元帳

パート 5: Ledger Recover の起源 – 運用上のセキュリティ | 元帳

これまで、パート 1 と 2 で元帳の回復方法を説明してきました。 シードをシェアに分割します および それらの共有を安全に送信します 〜へ 友達 信頼できるバックアッププロバイダー。 パート 3 では、その方法を示しました。 シードのシェアを安全に保存 (および復元)、ハードウェア暗号化によって保護され、個人情報に関連付けられ、多様化されます。 パート 4 では、Ledger Recover がどのようにして あなただけがバックアップにアクセスできるようにします.

今こそ、運用レベルで最大限のセキュリティを確保する方法を詳しく検討するときです。 一目でわかるように、運用上のセキュリティは以下によって実現されます。

  • Ledger Recoverを支えるインフラストラクチャの強化、
  • Ledger Recoverのさまざまなオペレーターに職務の分離を適用し、
  • 重要なコンポーネントとオペレーションを監視し、
  • リカバリ固有のインシデント対応の実装。

これらの各項目の意味を詳しく見てみましょう。

インフラストラクチャの強化

インフラストラクチャの強化にはさまざまな形があります。 これは、セキュリティ リスクの徹底的な分析に基づく幅広い活動を含む 360 度の演習です。 通常、セキュリティ上の問題 (データ漏洩、共有の不正な復元につながるクライアントのなりすまし、システムの応答不能、サービスの中断など) につながる可能性のある攻撃シナリオのカタログを維持することから始まります。 運用レベルでのこれらの問題の防止は、リソースの分離、システム アクセス規制、ネットワーク トラフィック制御、脆弱性管理などの活動を中心に組織されています。

パート 5: レジャー リカバリの起源 - 運用上のセキュリティ | Ledger Platoブロックチェーンデータインテリジェンス。垂直検索。あい。
パート 5: レジャーリカバリの起源 - 運用上のセキュリティ | 元帳

Ledger Recover のインフラストラクチャを強化するための主要な対策の概要は次のとおりです。

サービスの可用性

インフラストラクチャは、 単一障害点 (NSPOF) がないこれは、システムがあらゆるコンポーネントの障害に対して回復力があることを意味します。 次の例を考えてみましょう。当社のデータ センターは、建物の両端にある XNUMX つの独立したインターネット サービス プロバイダー (ISP) によってサービスを受けています。 建物の一部で進行中の建設作業によりファイバーが損傷した場合、データは単純に他の ISP を介してルーティングされます。 中断のないメンテナンスは、可用性を高めるもう XNUMX つの利点です。 Ledger Recover のすべてのソフトウェア コンポーネントに少なくとも XNUMX つのインスタンスがあることを考慮すると、インスタンス B を交換/アップグレード/修正している間、インスタンス A のみを使用するようにシステムを再構成できます。

Ledger Recover アプリケーションへの制限された管理者アクセス

のみ 限られたユーザーのセットに管理者アクセスが付与されます Ledger Recover専用のリソースへ。 ユーザーのリストが短いほど、内部関係者の脅威が管理者アクセスを取得するリスクを軽減できます。

安全な物理データセンター

バックアップ プロバイダーの HSM は次の場所でホストされています。 地理的に冗長 物理データセンターは、次の機能を使用して物理および仮想の脅威から保護されます。 業界グレードのセキュリティ技術と手順。 物理的保護のレベルにより、権限のない個人が気軽に HSM を持ち歩くことができなくなります。 複数のサイトにまたがるデータセンターに依存するということは、ある場所で問題が発生した場合に、別の場所が引き継ぎ、次のようなサービスを提供できることを意味します。 中断のないサービスの可用性。 最後になりましたが、独自の HSM を管理することで得られるものは次のとおりです。 誰がアクセスできるかを制御する 彼らへ そしてどのようなコードがデプロイされているか その上。

Ledger Recoverリソースの分離

すべての Ledger Recover リソースは、Coincover および Ledger 内を含む Ledger Recover のサービス プロバイダー内の他のリソースから分離されています。 この分離は、他のネットワーク スライスのリソースを悪用することを目的とした、XNUMX つのネットワーク スライスからの潜在的な攻撃を確実に阻止できるようにするために必要です。

複数の柱を通じてコードレベルのセキュリティを確保
  • を使用しております コードスキャナ 脆弱性を早期に特定して対処し、本番環境への侵入を防ぎます。
  • Code is そして承認されました by 独立したチーム Ledger Recoverを開発している者の一人。 この分離は、セキュリティ上の懸念につながる可能性のある論理的欠陥を検出することで、コード全体の品質を向上させるためのもう XNUMX つの手段です。
  • のコード 重要なモジュール Ledger Recover の 暗号署名を使用して署名される。 署名はコードの内容に基づいて部分的に生成され、署名を期待値と比較することで改ざんされたコードの展開を防ぎます。 このセキュリティ チェックは、コードが実行される前に行われます。
ネットワークトラフィック制御

ネットワーク トラフィックは、3 つのバックアップ プロバイダーすべてのトラフィック フローのルールを定義するポリシーによって厳密に制御されます。 による 許可および拒否されるトラフィックのルールの定義、攻撃対象領域を制限し、不正アクセスのリスクを軽減します。 また、個々のサービス間の通信を制限することで、 たとえ XNUMX つのコンポーネントが侵害されたとしても、攻撃者の横方向の動きは制限されます。 さらに、相互 TLS (mTLS) 認証を適用して中間者 (MiM) 攻撃を防ぎます。 相互 TLS は、証明書を使用して双方の ID を検証することにより、次のことを保証します。 信頼できるエンティティのみが安全な接続を確立できます.

キーのローテーション

Encryption キー (データや通信の暗号化などに使用されます) 定期的に変更される 暗号化のベストプラクティスに沿って。 この利点は、キーが侵害された場合に、 ダメージは限定的 ローテーション間の時間と、古いキーで暗号化されたデータに適用されます。

アウトバウンドトラフィックのセキュリティ

アウトバウンド トラフィックは、既知のドメインと IP アドレスのみに制限されます (バックアップ プロバイダー、サービス プロバイダー)。 送信トラフィックを制限および監視することは、 潜在的なデータ漏洩に常に注意を払う。 送信データ フローの量が予想よりも多い場合、悪意のある攻撃者が Ledger Recover システムから機密データを大規模に抽出している可能性があります。 

インバウンド交通のセキュリティ

受信トラフィックは、DDoS 対策、Web アプリケーション フィルタリング (WAF)、および IP フィルタリング技術の組み合わせによって保護されます。 分散型サービス拒否 (DDoS) 攻撃は、ターゲット システムにリクエストをあふれさせることで被害を及ぼします。 受信リクエストの数を制限する このような攻撃に対するよく知られた対策です。 現在、すべての攻撃が量を重視しているわけではなく、一部の攻撃は質を重視しています。 ここで WAF が活躍します。 WAF 受信したリクエストを調べて、 意図された動作を検査します: リクエストが不正アクセスやデータ操作を目的としている場合、フィルタはリクエストをブロックします。 最後に、IP フィルタリングは次の XNUMX つの手法を採用します。 ホワイトリスト、つまり許可する 特定の IP アドレスからのトラフィックのみ または範囲、および b) ブラックリスト、つまりブロックする 既知の攻撃者 IP からのトラフィック.       

脆弱性管理

Ledger Recover インフラストラクチャのコンポーネントは継続的かつ体系的に実行されます。 スキャンしました 既知の脆弱性と設定ミスについて、パッチ/アップデートが定期的に適用されます。 これにより、新たなタイプの脅威が出現した際の対応が容易になり、セキュリティ対策を最新かつ世界クラスに保つことができます。

職務の分離

職務の分離は、Ledger Recover のセキュリティ戦略の中核です。 

さまざまな部門間の職務の分離 バックアッププロバイダー (パート 3) および IDVプロバイダーs (パート 4) については、以前の投稿で説明しました。 次のようなものがあることを思い出してください。

  • 3 つの独立したバックアップ プロバイダーによって管理されるシークレット リカバリ フレーズの 3 つの共有 (共謀を防ぐためにデータベースを多様化します)
  • 2 つの独立した ID 検証者 (IDV プロバイダー)

インフラストラクチャレベルでは、 職務の分離 適用されます Ledger Recoverの開発と運用に関わるさまざまな役割間の連携.

さらに、職務の分離と 「最小限の特権」の原則。 「最小限の特権」は、システム オペレーターと管理者に適用される原則です。 彼らには、必要なことだけを行う権利が与えられています、職務を遂行するために必要な最低レベルの許可が確実に与えられるようにします。 

そうするとき 「最小限の特権」と「職務の分離」が組み合わされる, さまざまな管理者の役割がさまざまな人に割り当てられます そのため、誰一人としてシステム コンポーネントの機密性や完全性を損なったり侵害したりすることはできません。 たとえば、Ledger Recover コードの開発者は、自分が作成したコードを実行しているシステムにアクセスできません。

パート 5: レジャー リカバリの起源 - 運用上のセキュリティ | Ledger Platoブロックチェーンデータインテリジェンス。垂直検索。あい。
パート 5: レジャーリカバリの起源 - 運用上のセキュリティ | 元帳
ガバナンス : 定足数

複数のアクターにブロックを検証させることで完全性とセキュリティを保証するブロックチェーンのコンセンサスメカニズムと同様に、運用上のセキュリティを強化するために、Ledger Recover システム内にクォーラムを採用しました。

当社の従業員に対する強力な身元調査にもかかわらず、人間はどのようなシステムにおいても弱点となり得るという事実は変わりなく、暗号圏も例外ではありません。 注目を集めるセキュリティインシデント 2014 年のマウントゴックス ハック、個人がどのように悪用されたり、セキュリティの欠陥につながる可能性があるかを示します。 人々は、金銭、イデオロギー、強制、エゴ(別名、MICE(S))といったさまざまな動機を通じて影響を受けたり、強制されたりする可能性があり、最も厳格な身元調査であっても完全に確実というわけではありません。

このようなリスクを軽減するために、当社ではクォーラムの概念に基づいたシステムを採用しています。 このフレームワークでは、重要な決定や重要なアクションを実行する前に、バックアップ プロバイダー内のさまざまなチームまたは部門からの少なくとも XNUMX 人の権限のある個人の合意が必要です。 

さまざまな定足数に参加する正確な人数は、セキュリティ上の理由から非公開のままです。 それでも、その存在だけで、侵害された単一の個人の潜在的な影響力が弱まり、運用上のセキュリティが大幅に強化されます。

クォーラムを使用するアクティビティの一部を次に示します。

1. Ledger Recover HSM の秘密キーの生成: この重要な操作は、Coincover、EscrowTech、Ledger の各エンティティ内の独立したクォーラムによって保護されています。 これらの個別のクォーラムの各メンバーは、それぞれの HSM で秘密キーを生成するために存在する必要があります。 各クォーラム メンバーはバックアップ キーにアクセスできます。バックアップ キーは、必要に応じて HSM シークレットを復元および再生成するために重要です。 この構造は、XNUMX つのバックアップ プロバイダー HSM のいずれかに対して誰かが不当な影響力を持つリスクから保護するだけでなく、各クォーラムが独立して動作し、互いの詳細を認識しないため、システム全体の整合性も強化されます。

パート 5: レジャー リカバリの起源 - 運用上のセキュリティ | Ledger Platoブロックチェーンデータインテリジェンス。垂直検索。あい。
パート 5: レジャーリカバリの起源 - 運用上のセキュリティ | 元帳
クォーラムが完全に侵害された場合でも、ユーザー資産を危険にさらすことはできないことに留意してください。 から思い出す ブログ投稿 2: 各バックアッププロバイダーは単一の共有のみを処理します。 必要な共有がすべてなければ、ユーザーのシードを再構築することは不可能です。 

さらに、既存の共有を解読するために必要な HSM の秘密キーを抽出することは、クォーラムのバックアップ キーでは実行できません。 バックアップ プロバイダーのクォーラム メンバーは、新しい HSM の復元と再作成のみが可能です。

2. 顧客の株式の例外的な放出の決定: まれではありますが、特定の状況では、顧客の株式の例外的な解放が必要となる場合があります。 これらは、本人確認の失敗 (名前の変更、物理的な損傷など)、または非公開のセキュリティ対策によりデバイスが誤ってブロックブラックリストに登録されたことが原因である可能性があります。 このような状況が発生した場合、バックアッププロバイダーの複数の個人からなる定足数が集まります。 この手順には広範な合意が必要であり、意思決定が性急に行われたり一方的に行われたりすることがなくなり、顧客のセキュリティが強化されます。 定足数の各メンバーは、Ledger Nano デバイス (独自の PIN 付き) を使用してリリースを承認し、共謀の可能性や個別のエラーに対するセキュリティ層をさらに追加します。

3. HSM ファームウェア コードの更新に署名する: 新しいファームウェア アップデートを HSM に展開する前に、当社の製品セキュリティ チームである Ledger Donjon は、包括的なレビュー プロセスを実施します。 Ledger Donjon はファームウェア クォーラムの一部であるため、悪意のある内部関係者やサプライ チェーン攻撃による開発パイプラインの侵害によってバックドアや悪意のあるコードが導入されていないことを保証します。 そうすることで、ファームウェア アップデートの整合性とセキュリティが維持されます。

4. 署名台帳デバイス (Nano および Stax) ファームウェア コードの更新: HSM のファームウェアと同様に、Ledger デバイスのファームウェアの更新は厳格なレビュー プロセスを経て、Ledger Live 経由でユーザーに提案される前にクォーラムの承認が必要になります。

まとめると、クォーラムは Ledger Recover のセキュリティ アーキテクチャの不可欠な部分です。 これらは、重要な作戦中の内部不正の脅威や共謀に対する防御を強化する上で重要な役割を果たします。 Ledger デバイスとサービスの最高レベルのセキュリティを活用することで、クォーラムは信頼を確保し、悪意のある内部関係者からユーザーのデジタル資産を保護するのに役立ちます。

重要なコンポーネントとオペレーションの監視

この章を詳しく説明する際に、セキュリティ上の理由から、Ledger Recover サービスの広範な監視アクティビティのサブセットのみを公開していることに注意することが重要です。 当社は透明性への取り組みを堅持する一方、内部統制の詳細についての裁量権を維持し、運用上のセキュリティを監視することの重要性も認識しています。

Ledger では、セキュリティが最優先事項です。 これは当社のソリューションの中核であり、詳細については、堅牢な暗号化プロトコルに基づいて構築されています。 Ledger Recover ホワイトペーパー。 しかし、私たちの仕事は安全なシステムの構築を超えて続きます。 私たちは常に業務を監視および評価し、疑わしい活動がないか探しています。 この継続的な警戒により、当社のセキュリティスタンスが強化され、常に対応できるようになります。 

多層アプローチの例をいくつか見てみましょう。

管理者のアクティビティの監視: 当社では管理者に対して厳格なアクセス制御を実施しています。 インフラストラクチャへのすべての管理接続に 2FA (XNUMX 要素認証) を要求するだけでなく、システムの重要な部分に対する管理者のインフラストラクチャ アクセスに対して複数人による検証も義務付けています。 さらに、当社のシステムはあらゆる管理活動を綿密に記録し、追跡します。 これらのログは、社内の発券システムと自動的に相互参照され、計画外のアクションが検出されます。 この慎重な関連付けにより、異常または不審な動作についてセキュリティ チームに即座に警告することができ、運用上のセキュリティが強化されます。

バックアッププロバイダー間の相互制御: 透明性と説明責任は、バックアッププロバイダー、Ledger、EscrowTech、Coincover 間の関係の基礎を形成します。 システムの監視とセキュリティに使用されるログのリアルタイム交換を確立しました。 これにより、アクティビティの相互検証が可能になります。 不一致が検出された場合、ユーザーの資産を保護するためにサービスは直ちにロックされます。

例外的なリリース活動の監督: まれに発生する手動共有リリースは、前のセクションで説明したように、マルチ クォーラム プロセスを通じて細心の注意を払って制御されます。 例外的なリリースアクティビティの実行後、Ledger Recover システムは、関係者、操作時間、その他の関連詳細の詳細なログ記録と分析を含む、包括的な監視を続行します。 マルチクォーラム実行と事後監視の両方を含むこのプロセスにより、意思決定プロセスのすべての段階で例外的な株式の解放が厳密に制御されます。

セキュリティ情報およびイベント管理 (SIEM) の活用: SIEM ソリューションは、Ledger Recover 監視戦略の重要な部分を形成します。 この専用 SIEM は、潜在的なセキュリティ問題をリアルタイムで特定して対応する能力を強化します。 Ledger Recover サービス用に特別に開発された特定の検出ルールのおかげで、クラスターおよび Ledger Recover アプリケーション ログに基づいてさまざまな侵害痕跡 (IoC) を識別するように微調整されています。 カスタム IoC が検出された場合、応答は自動的かつ即座に行われ、徹底的な分析が行われるまでクラスター全体がロックされます。 Ledger Recover サービスでは、ユーザーの資産を最大限に保護するために、サービスの可用性より機密性が優先されます。

サイバーセキュリティのダイナミックな状況において、私たちはさまざまなシナリオに向けて戦略を立て、準備してきました。 当社の脅威モデルは、異なるバックアップ プロバイダーの複数のインフラストラクチャ管理者が侵害される可能性があるという、ありそうもない状況を考慮しています。 Ledger Recover サービスは、厳格な安全対策と自動応答が導入されているため、このような異常な状況でもユーザーの資産の継続的なセキュリティを確保することを目的としています。 次のセクションでは、このような仮想的な状況に対処するために構築された包括的な対応策の概要を説明します。

Ledger Recover 固有のインシデント対応

Ledger Recover サービスでは、XNUMX つのバックアップ プロバイダーと協力して設計されたインシデント対応戦略が構築されています。 この戦略の中心となるのは、インフラストラクチャのいずれかの部分で不審なアクティビティが検出されるとすぐにシステム全体をロックする自動保護機能です。 

本質的に、「常に安全で決して後悔しない」プロトコルが Ledger Recover サービスに組み込まれています。 セキュリティは最優先事項であり、決して妥協することはできません。 

私たちは、次の 100 億人のユーザーを Web3 に参加させるためのシームレスなユーザー エクスペリエンスを提供するよう継続的に努力していますが、これらの安全策を有効にすることを躊躇しません。 潜在的な脅威が発生した場合に、Ledger Recover サービス全体を効果的にロックダウンします。。 保護するという私たちの使命において、侵害される可能性のあるサービスを実行するか、究極のセキュリティを確保するかの選択は明らかです。私たちはセキュリティを選択します。

まとめ

ここで、このシリーズの運用セキュリティの部分は終了です。 このパートでは、Ledger Recover システムのセキュリティ対策の難攻不落性がどのように確保されるかについて、お客様が抱く懸念に答えようとしました。 私たちはインフラストラクチャ、職務の分離、ガバナンスと監視、そして最後にインシデント対応戦略について話し合いました。 

ここまで読んでいただき、改めてありがとうございました! これで、Ledger Recover の運用上のセキュリティについて包括的に理解できるようになりました。 このブログ投稿シリーズの最終回では、私たちが最後に抱えていたセキュリティ上の懸念について、より正確には、ユーザーに最大レベルのセキュリティを保証するために、内部および外部のセキュリティ監査をどのように管理したかについて説明します。 乞うご期待! 

タイムスタンプ:

より多くの 元帳