質問
マルチテナント対応のシークレットローテーションサービスを設計してください。テナントはデータベースのパスワード、サードパーティAPIキー、または証明書とそのローテーション周期を設定できます。サービスは新しい値を生成し、外部システムを更新し、バージョンを保存し、ワークロードへ段階的に通知して、古い値を廃止します。リカバリ、並行性、監査性、認可、およびロールバックを網羅してください。
面接官がテストしていること
- ローテーションを復旧不能なcronスクリプトではなく、再試行可能なステートマシンとしてモデル化しているか。
- 重複メッセージ、単一シークレットに対する並行ジョブ、およびテナントの分離を適切に処理しているか。
- 全社的な即時障害を引き起こすことなく、2つのバージョンをステージングして段階的にロールアウトできるか。
- 廃止処理、侵害時の対応、監査証跡、および最小権限の原則を説明できるか。
模範解答
コアオブジェクトは Secret、イミュータブルな Version、RotationPolicy、Job、および Lease です。スケジューラは次のローテーション時刻のジョブを発行し、キューは secret_id ごとにパーティショニングされ、ワーカーは有効期限付きのリースを取得します。(secret_id, idempotency_key) に対するデータベースの一意性制約により、安全な再試行が可能になります。
scheduled → generating → external_updated → staged → rolling_out → verified → retired などのステートマシンを使用します。各ステップで外部リクエスト識別子、バージョン、および次の再試行時刻を永続化します。最初に外部プロバイダーでクレデンシャルを作成し、次に保留（pending）バージョンを保存します。ワークロードは、イミュータブルなバージョン参照またはリフレッシュメカニズムを介して段階的に切り替わります。ヘルスチェック、エラー率、および認可テストが合格した後にのみ、バージョンを current（現在）に昇格させます。
制御メタデータは暗号化されたシークレットペイロードから分離して保持します。アプリケーションには短期間有効な読み取り権限を付与します。すべての状態遷移は、シークレットの平文を含まない追加専用（append-only）の監査ログに出力されます。ロールバックは依然として有効な古いバージョンを選択し、リカバリが完了する前にそのバージョンを自動的に無効化してはなりません。
アーキテクチャの概要
Scheduler -> Durable Queue -> Rotation Workers
| | |
Policy DB Lease/Idempotency External Provider
| |
Version Store + KMS Rollout Controller -> Workloads
|
Audit Log / Metrics / Alertsワーカーはリースを更新し、有効期限が切れると別のワーカーが処理を引き継ぐことができます。キューメッセージにはシークレットとジョブの識別子のみを含めます。ワーカーは制限されたバージョンストアから値を読み取り、メッセージ、ログ、およびメトリクスラベルに平文が入らないようにします。
重要なフロー
- スケジューラがべき等なジョブを作成し、テナントのクォータを適用します。
- ワーカーがリースを取得し、現在のバージョンとポリシーを読み取ります。完了済みのジョブは安全にリターンします。
- 値を生成し、プロバイダー側のべき等性キーを使用してプロバイダーを呼び出します。
- pending バージョンを書き込み、互換性チェックと少規模なロールアウトを実行します。
- エラー率、認証の成功、およびヘルスプローブを監視し、その後にのみ current に昇格させます。
- すべてのコンシューマーが確認応答した後、古いバージョンを無効化および破棄します。失敗した場合は再試行またはロールバックします。
各ステップで状態と外部レスポンスを永続化します。再起動時は、プロバイダーがすでに変更されたかどうかを推測するのではなく、最後の状態から継続します。
よくある落とし穴
- cronに次回の時刻のみを保存し、再起動後や重複配信時に復旧ポイントが存在しない。
- コネクションプール、キャッシュ、長時間持続する接続を無視して、古い値を即座に無効化してしまう。
- キュー、ログ、トレーススパン、またはエラーメッセージに平文を含めてしまう。
- すべてのテナントに1つのグローバルロックを使用する、またはテナントクォータを省略して1つのテナントがワーカーを枯渇させてしまう。
- 古い値がまだ有効でアクティブであることを確認せずに、単に再度書き込むことをロールバックとして扱う。
一貫性とセキュリティのトレードオフ
ステートマシンと一意性制約には強整合性データベースを使用します。通知とロールアウトは at-least-once（少なくとも1回）でよいため、コンシューマーはべき等である必要があります。バージョンの読み取りは一時的にキャッシュされる場合がありますが、current バージョンの変更や無効化には明示的な無効化パスが必要です。テナント認可により、自身のシークレット、ジョブ、および監査レコードへのアクセスが制限され、ワーカーには現在のステップに必要なプロバイダー権限のみが付与されます。
ローテーション周期は、固定タイマー単体ではなく、キーのタイプ、漏洩リスク、プロバイダーの制限、および復旧ウィンドウを考慮して決定する必要があります。NIST の鍵管理ガイダンスでは、使用期間、目的、保護レベル、および無効化を単一のポリシー決定として扱います。
各状態遷移の前後でワーカーがクラッシュした場合、メッセージが重複した場合、リースが切れた場合、プロバイダーがタイムアウトした場合、部分ロールアウトが失敗した場合、データベースがフェイルオーバーした場合などの障害を注入してテストします。1つのジョブが重複する外部クレデンシャルを作成しないこと、正確に1つのバージョンが current になること、そして確認ウィンドウの後でのみ古い値が無効化されることを検証します。また、テナントの分離、監査ログのマスキング、アラートのレイテンシもテストします。
- AWS Secrets Manager の
AWSPENDING/AWSCURRENTローテーションフロー: ステージングラベルと完了ステップ。 - Google Cloud Secret Manager のローテーションガイダンス: 再試行、非並行ローテーション、段階的ロールアウト、および古いバージョンのクリーンアップ。
- NIST SP 800-57 Part 1: 鍵の目的、保護、使用期間、および無効化の原則。
フォローアップの質問
2つのワーカーが1つのシークレットを同時にローテーションするのをどのように防ぎますか？
データベースリースまたはフェンシングトークン付きの分散ロックを使用し、すべての状態更新にそのトークンを書き込みます。現在のトークンを持たない復旧したワーカーは、より新しい状態を上書きできません。リースには更新と明確な有効期限が必要です。
プロバイダーにべき等なAPIがない場合はどうしますか？
リクエストのフィンガープリントと外部リソース識別子をジョブに永続化し、再試行する前にプロバイダーに問い合わせます。プロバイダーに問い合わせができない場合は、むやみにクレデンシャルを追加作成するのではなく、手動確認のためにステップを一時停止します。
すべてのアプリケーションが latest を読み取るようにしてはいけないのはなぜですか？
latest は、検証されていない値をフリート全体に即座にプッシュしてしまう可能性があります。イミュータブルなバージョン、段階的ロールアウト、およびヘルスチェックにより、影響範囲を限定し、ロールバックポイントを維持できます。
ローテーションジョブが滞留した場合、サービスをどのように保護しますか？
テナントおよびプロバイダーごとに並行性クォータを設定し、優先順位と指数バックオフを使用し、最も古いジョブの経過時間、障害率、および残りの復旧ウィンドウを可視化します。期限切れが近いシークレットは、認可やべき等性をバイパスすることなく優先順位を上げることができます。
シークレットが侵害された後、サービスは何を行いますか？
影響を受けるジョブの通常のスケジュールを一時停止し、高優先度の緊急ローテーションを作成し、ロールアウトの監視ウィンドウを短縮して、フォレンジックログを保持します。古い値を無効化する前に重要なコンシューマーが切り替わったことを確認し、テナントとセキュリティインシデント対応プロセスに通知します。