鍵のローテーション手順
テナントルートの更新は、有効な導出ルートを維持し、Deriver AとBの運用シェアを置き換えます。 ウォレットの公開鍵とアドレスは変わりません。 その他の種類は、鍵のローテーションを参照してください。
受付と実行
- 認証済みのConsole境界が、テナント識別情報と有効な鍵管理系統を特定します。呼び出し側が渡すのは操作IDです。代替シェアや別のテナントルート識別情報は渡しません。
- Routerが管理するテナントのDurable Objectが、操作の受付を記録します。R120は、直近1時間で1回の手動更新成功を許可します。同時の別要求や待機期間中の要求を、Deriverやプロバイダーの処理前に拒否します。
- コントロールプレーンがロール別のコマンドを発行します。各Deriverは、バックアップの書き込み前に永続状態を予約します。自身の更新済みシェアだけを導入し、署名済み公開証跡を返します。
- 有効化には、A/Bの証跡の一致とルートの継続性が必要です。正規のライフサイクルリビジョンを進め、手動完了時刻と再生用記録を一緒に確定します。
- 廃止処理は、置き換えられた有効レコードとバックアップを削除します。有効化後の失敗には廃止処理の再開が必要です。前のエポックを再有効化しません。
通常署名は、操作の間も既存の署名素材を使います。 有効なエポックが変わる間、新しいテナント導出の手順は停止する場合があります。
中断した操作
同じ操作IDで再試行してください。永続的な予約と実行チェックポイントにより、既存の試行を再開できます。 完了済みIDは、記録済み結果を返します。 遅れた再試行で、新しい更新に置き換えられたエポックを再導入することはできません。 最終的なロールの確定には、再生可能なRouterの導入チェックポイントもあります。
有効化と廃止を、別の結果として扱ってください。 通常署名が動作していても、廃止が未完了の更新にはクリーンアップが必要です。 応答が不明な状態を修復するために、無関係なローテーションを開始しないでください。
復元と破棄
管理型復元は、復元したロールシェアを検証し、通常のライフサイクル受付の再開前に、次世代への更新を必須とします。 承認は手動のテナント更新とは別で、テナントの迂回フラグでは選択できません。
現在のGoogle KMSバックアップ鍵は、ロール内で複数テナントが共有します。 古いR2オブジェクトの削除だけでは、過去の暗号文コピーすべてを復元不能にできません。 運用上のローテーションとクリーンアップを正確に報告してください。 より強い暗号学的消去の主張には、独立した鍵破棄の検証が必要です。
提供状況
テナントルートの更新は、公開済みWallet Serverに含まれます。 実際の環境で、1時間の受付ポリシー、ダッシュボードの追加認証、進行状況、スケジューラー、復元素材の管理を確認してください。 SDKの公開だけでは、これらの運用経路を確認できません。 ホスト環境への展開と復元提供の条件は、復元と移行を参照してください。
次に、テナントルートのバックアップと復元と移行を参照してください。