PHP連携における認証情報のローテーションとは、外部サービスへのアクセスに使用するキー、トークン、パスワード、証明書を置き換え、古い認証情報を制御された方法で失効させることです。単に設定ファイルの値を変更すればよいわけではありません。移行によって運用が中断したり、古い認証情報が不必要に長く使われたりしないよう、アプリケーション、実行中のプロセス、外部プロバイダーの動作を連携させる必要があります。
目的は、古い認証情報を失効させる前に、新しい認証情報がすべての利用側で機能することを確認し、互換性を保つ期間を限定するとともに、障害への対応をあらかじめ整えておくことです。手順はサービスの機能に合わせる必要があります。プロバイダーによっては2つのキーを同時に有効にできますが、即時の置き換えが必要で、試験の余地が少ない場合もあります。
ローテーションでアプリケーションとプロバイダーの連携が必要な理由
認証情報は、シークレットマネージャー、環境変数、デプロイ設定、すでに起動しているPHPプロセスなど、複数の場所に同時に存在することがあります。値の保存元を変更しても、すべての利用側がその値を再読み込みしたとは限りません。たとえば、長時間稼働するキューワーカーが古い設定をメモリに保持している一方で、Webインスタンスはすでに新しい設定を使っていることがあります。
外部システムの動作も重要です。古い認証情報と新しい認証情報を同時に受け付ける場合、新しい認証情報をデプロイして利用状況を確認した後、古い認証情報を失効させられます。一方、一度に1つしか受け付けない場合は、メンテナンス時間、連携した手順、またはプロバイダーが提供する切り替え機能が必要になることがあります。併用期間があると決めつけず、ドキュメントで確認し、可能であれば管理された環境でも検証してください。
ローテーションは、一般的な設定管理とは異なります。設定管理は値の受け渡しと利用方法を定めるものですが、ローテーションでは、検証、失効、漏えいへの対応を含め、シークレットとそのライフサイクルを変更します。設定の一元管理は役立ちますが、それだけでは古い認証情報が使われなくなったことを証明できません。
利用側、権限、依存関係を洗い出す
認証情報を生成または変更する前に、発行元のサービス、付与される権限、利用するすべてのシステムを特定します。Webアプリケーション、スケジュール実行コマンド、ワーカー、手動タスク、テスト環境、運用ツールを含めてください。また、リポジトリやCI/CD設定も確認し、古い参照を検出します。ただし、シークレットの値をレポートやチケットに転載してはいけません。
- 利用側：リポジトリ、サービス、プロセス、担当者、実行頻度を特定します。
- 適用範囲：権限、アクセス可能なリソース、ネットワーク制限、有効期限を記録します。
- 受け渡し：各プロセスがどのシークレットマネージャーまたは安全な仕組みから認証情報を取得し、いつ再読み込みするかを確認します。
- 依存関係：他のシステムやチームが同じキーに依存しているか、プロバイダーが複数の認証情報を同時に有効化できるかを調べます。
- 可観測性：機密値を表示せずに変更を確認できる、成功・失敗のメトリクスやログを特定します。
キーの利用者を特定できない場合、トラフィックが少なそうだという理由だけで失効させないでください。月次プロセスや復旧タスクが見落とされることがあります。プロバイダーが提供する利用ログと、各環境の実効設定を使ってインベントリを補完してください。
移行を準備し、併用期間を制限する
プロバイダーの仕組みを使って新しい認証情報を生成し、必要最小限の権限だけを付与します。サービスが2つのキーを同時に有効にできる場合は、期間を明確に定めた併用期間を設定します。利用側のデプロイ、テスト、監視に十分な長さを確保しつつ、必要以上に延長しないでください。期間の管理者と失効条件を記録すれば、暫定期間が無期限に続くことを防げます。
シークレットは、環境で承認されたシステムを通じて受け渡してください。ソースコード、メッセージ、チケット、ログに残る可能性のあるコマンド引数に含めてはいけません。デバッグトレースへの出力も避けてください。手順書では古い認証情報と新しい認証情報を明確に区別して、誤りを減らします。ただし、運用ドキュメントに値を記載してはいけません。
設定の読み込み方法に応じて、変更の順序を決めてください。メモリに保持された値を使わなくするために、シークレットの更新後、アプリケーションをデプロイし、ワーカーやスケジュール実行プロセスを再起動する必要がある場合があります。各インスタンスへの変更の反映方法を確認してください。実行環境の設定を変更しても、既存プロセスには反映されないことがあります。
シークレットを露出させずにデプロイして検証する
プロバイダーが許可する場合は、まず本番環境を代表する環境で変更を適用します。その後、本番環境へ連携してデプロイし、新しい呼び出しだけでなく、実行頻度の低いプロセスも確認してください。基本的な接続テストは有用ですが、連携に依存する実際の操作の検証に代わるものではありません。
- アプリケーションが新しい認証情報を受け取り、インスタンスとワーカーが設定を再読み込みしたことを確認します。
- プロバイダーの応答、エラーコード、業務上重要な操作の動作を確認します。
- 既知の利用側を網羅できる期間にわたり、成功率、認証エラー、再試行、滞留中のキューを監視します。
- 障害の調査にはリクエストIDまたは実行IDを使い、シークレットを含む可能性のあるヘッダーや本文はマスキングまたは除外します。
ログには状況把握に必要な情報を残しつつ、トークン、パスワード、認証ヘッダーを保存しないでください。例外メッセージも確認しましょう。ライブラリやHTTPクライアントが、トレースに機密情報を含めることがあります。連携で個人情報や業務情報を扱う場合は、関連するアクセス、保持、データ保護のポリシーも適用してください。
古い認証情報を失効させ、障害に対応する
既知の利用側すべてが新しい認証情報で動作し、監視期間がそれぞれの関連サイクルをカバーしたら、古いキーを失効させます。プロバイダー上で失効を確認し、その後のエラーを監視してください。古い認証情報による試行が続く場合は、変更完了と判断する前に、見落としたプロセス、更新されていないインスタンス、外部タスクを調査します。
障害時には、認証、権限、接続、リクエスト形式の問題を切り分けてください。古い認証情報がまだ有効で、漏えいの兆候がない場合は、デプロイの修正中に一時的な切り戻し手段として使えることがあります。ただし、承認を得て、運用上の有効期限を明確に定めてください。侵害の疑いに対応するローテーションの場合、古いキーを再有効化するとリスクが再発するおそれがあります。封じ込めを優先し、該当するセキュリティ手順に従ってください。
決定、時刻、担当者、結果、未対応事項を記録します。ただし、シークレットは記録しないでください。この記録は何を変更したかの再構成や手順の再実施に役立ちますが、認証情報の別管理台帳になってはいけません。
再現可能なローテーションのチェックリスト
- 長時間稼働するプロセスや実行頻度の低いタスクを含め、すべての利用側を特定していますか？
- 権限、有効期限、複数の認証情報を同時に有効化する場合のプロバイダー規則を把握していますか？
- 新しい認証情報は安全な経路で、最小権限を付与して受け渡されますか？
- デプロイ順序、設定の再読み込み、監視期間、担当者を計画に明記していますか？
- 検証では実際の操作を確認し、機密値の記録を避けていますか？
- 通常の障害と侵害の可能性に対して、それぞれ異なる対応策がありますか？
- 古い認証情報を失効させ、その後、移行が遅れている利用側が残っていないことを確認しますか？
信頼できるローテーションは、新しい認証情報の検証が完了し、古い認証情報が失効し、移行待ちのプロセスが残っていない時点で完了します。そのいずれかを確認できない場合、変更は未完了です。担当者と明確なフォローアップを設定した運用タスクとして扱ってください。
