Ensure all pathsecrets are backup in key-vault

[osuketh]

• backup/recover Attested TLSにおけるcommunicationエラーなどでkey-vault側でbackupできていなく、anonify側でbackupできている場合、key-vault側に必要なpathsecretのバックアップができていなく、anonify側の処理が進んでしまうケースがある。

anonify側のpathsecret全てが必ずkeyvaultにバックアップされていることを保証するために、以下の処理を追加実装する

• そもそもbackupされているpathsecretが不足していることに気づく仕組み
• 定期的にanonify側がpathsecrets/配下のファイルをkey-vault側へ送り、key-vaultは足りていないファイルを記録
• backup apiをanonify側に生やし、マニュアルでpathsecretを送る

[osuketh]

そもそもbackup pathsecretが不足するパターンとそれに気づく仕組み

• バックアップ時のエラーでそもそもバックアップできていない（レスポンスエラーで検出）
• key-vault VMのハードウェア割り当てが解除（オペミスによる解除、 クラウドメンテ）し、backup path secretが復元できなくなる（システム監視・メンテナンスメールをslack通知）
• Diskやオブジェクトストレージが壊れる（システム監視）

都度バックアップ

• 実装済み
• must

それぞれのTEEノードで新しくpath secretが生成する時に都度自動でkey-vaultサーバーに送信する。

マニュアルバックアップ

• 未実装
• must

具体施策例

• anonify TEEノードにall backup エンドポイントを生やし、APIにリクエストを送ることでローカルの全てのselad path secretをバックアップ
• single backup エンドポイントを生やし、path secret idを指定し、一つのpath secretのみマニュアルでバックアップ

定期バックアップ

• 未実装
• optinal 関連: #326

具体施策例

• 専用スレッドで設定固定値BACKUP_PERIOD（例：１日ごと）ごとに、ローカルのsealed path secret全てをunsealし、key-vaultへ送り、万が一バックアップできていないpath secretがあった場合は記録する

[osuketh]

マニュアルバックアップ用API

• all_backup_to: anonify node --> key-vault nodeへ手持ち全てをバックアップ
• single_backup_to: anonify node --> key-vault nodeへ鍵idを指定して一つバックアップ
• all_backup_from: key-vault node --> anonify nodeへバックアップを全て取得
• single_backup_from: key-vault node --> anonify nodeへ鍵idを指定して取得