Azure Cosmos DBのキー ローテーションで最も怖いのは、「もう使っていないはず」と思って再生成したキーが、実はバッチ処理や古いアプリで使われていた、という事故です。2026年6月にPublic Previewとして案内された「Safe Key Rotation」は、Azure Cosmos DBのアカウントキーごとの最終使用日時を確認できるようにし、キー再生成やローカル認証の無効化をより安全に進めるための機能です。Azure UpdatesではID 562774の更新として「Public Preview: Safe key rotation for Azure Cosmos DB」がIn previewとして掲載されています。(マイクロソフト Azure)
結論から言うと、Azure Cosmos DBでアカウントキー認証を使っている環境では、Safe Key Rotationを「キーを回す直前の確認機能」として導入する価値があります。ただし、Public Previewのため本番運用の自動判定にそのまま組み込むのではなく、診断ログ、アプリ設定、Key VaultやCI/CDの参照先確認と組み合わせて使うのが現実的です。
Azure Cosmos DBのSafe Key Rotationとは
Safe Key Rotationは、Azure Cosmos DBアカウントキーの利用状況を可視化し、キー ローテーション時の停止リスクを下げるための機能です。Microsoftの公式ブログでは、この機能により各アカウントキーが最後に使われた日時を確認でき、キー再生成やMicrosoft Entra IDへの移行前に判断しやすくなると説明されています。(Microsoft for Developers)
従来のキー ローテーションでは、管理者が「このキーはもう使われていないはず」と判断しても、実際には以下のような場所で使われ続けていることがありました。
| 見落としやすい利用元 | 具体例 | 起こり得る問題 |
|---|---|---|
| 古いアプリ設定 | App Service、Azure Functions、VM上の環境変数 | キー再生成後に接続エラーが発生する |
| 定期実行ジョブ | 月次バッチ、年次処理、夜間集計 | ローテーション直後は問題なく見え、後日失敗する |
| 共有された接続文字列 | チーム間でコピーされた設定、ローカル開発環境 | 利用者を特定しにくい |
| CI/CDや運用スクリプト | GitHub Actions、Azure DevOps、PowerShell | デプロイやメンテナンス処理が失敗する |
| 監視・分析ツール | 独自監視、データ抽出ツール | 本体アプリ以外の接続が切れる |
Safe Key Rotationは、こうした「見えないキー利用」をゼロにする魔法の機能ではありません。役割は、キーごとの最終使用日時を見せることで、再生成してよいかを判断する材料を増やすことです。
何が変わるのか
今回のPublic Previewで重要なのは、キー管理の判断材料が増えた点です。公式ブログでは、Public Previewにより、各キーの最終使用タイムスタンプを確認できること、Azure portalのFeaturesブレードから有効化できること、キー再生成やローカル認証無効化の前にキーが使われていないことを確認しやすくなることが示されています。(Microsoft for Developers)
| 項目 | これまでの課題 | Safe Key Rotationでできること |
|---|---|---|
| キーの利用状況 | どのキーが最近使われたか分かりにくい | 各キーの最終使用日時を確認できる |
| キー再生成の判断 | 利用者への聞き取りや推測に頼りがち | 実際の利用実績を見て判断しやすい |
| ローカル認証の無効化 | まだキー認証が残っているか不安が残る | キーが使われていないことを確認してから進めやすい |
| 移行計画 | Entra ID移行前の棚卸しが難しい | キー利用が残るアプリを洗い出す手掛かりになる |
特に大きいのは、「主観的な判断」から「観測データに基づく判断」へ寄せられることです。セキュリティ担当者にとってはキーの定期更新を進めやすくなり、開発者にとっては突然の認証エラーを避けやすくなります。
対象になる環境と影響範囲
Azure Cosmos DBのキー ローテーション手順の公式ドキュメントでは、対象としてNoSQL、MongoDB、Apache Cassandra、Apache Gremlin、Tableが示されています。(Microsoft Learn)
影響を受けやすいのは、次のような環境です。
| 環境 | 確認すべき理由 |
|---|---|
| アカウントキーまたは接続文字列でCosmos DBへ接続しているアプリ | キー再生成の影響を直接受ける |
| 複数チームで同じCosmos DBアカウントを共有している環境 | どのチームがどのキーを使っているか不明になりやすい |
| 定期バッチや運用スクリプトが多い環境 | 普段のトラフィックだけでは利用有無を判断しにくい |
| Microsoft Entra ID認証へ移行中の環境 | ローカル認証を無効化する前の確認材料になる |
| セキュリティ監査でキー更新ルールを求められる環境 | ローテーションの根拠を残しやすい |
一方で、すでにMicrosoft Entra ID認証へ完全移行しており、キー認証を無効化済みの環境では、直接的な利用頻度は低くなります。ただし、移行済みと思っている環境でも、古い運用スクリプトや検証用ツールに接続文字列が残っていることは珍しくありません。Safe Key Rotationは、その確認にも使えます。
Public Previewとして使う際の注意点
Safe Key Rotationは便利ですが、現時点ではPublic Previewです。Microsoft Learnのキー ローテーション記事では、Account Key Usage MetadataはPublic Previewであり、サービスレベルアグリーメントなしで提供され、本番ワークロードには推奨されないと説明されています。(Microsoft Learn)
そのため、実務では次のように扱うのが安全です。
| 注意点 | 実務での対応 |
|---|---|
| プレビュー機能である | 本番の自動ローテーション判定をこの情報だけに依存させない |
| 有効化直後は十分な履歴がない可能性がある | 少なくとも定期ジョブの実行周期をまたいで観測する |
| 最終使用日時だけでは利用元を特定できない | 診断ログやアプリ設定の棚卸しと併用する |
| 「最近使われていない」ことは「今後も使われない」と同義ではない | 月次・四半期・年次処理を確認する |
| ポータル表示だけでは変更管理に残りにくい | 作業記録、チケット、承認履歴に判断根拠を残す |
特に重要なのは、有効化した直後に「最終使用日時がないから未使用」と判断しないことです。Private Preview時点の説明では、利用データは有効化後から収集が始まるとされていました。(Microsoft for Developers) 月次バッチがある環境では、少なくともそのバッチが動くタイミングを待ってから判断する必要があります。
管理者が確認すべき設定
管理者は、Safe Key Rotationを有効化するだけでなく、キー認証をどの程度残すのか、Microsoft Entra IDへ移行するのかをセットで考える必要があります。
Azure portalで機能を有効化できるか確認する
Public Previewでは、Safe Key RotationをAzure portalのFeaturesブレードから有効化できるとされています。(Microsoft for Developers) まずは対象のAzure Cosmos DBアカウントで、機能が表示されるか確認します。
確認の流れは次のとおりです。
| 手順 | 確認内容 |
|---|---|
| Azure portalで対象のCosmos DBアカウントを開く | 本番・検証・開発のどのアカウントかを取り違えない |
| Settings配下のFeaturesを確認する | Safe Key RotationまたはAccount Key Usage Metadataに相当する機能を探す |
| プレビュー機能として有効化する | 組織のプレビュー機能利用ルールに従う |
| Keys画面で最終使用日時を確認する | Primary、Secondaryなど各キーの利用状況を確認する |
| 変更履歴に記録する | 有効化日、対象アカウント、作業者を残す |
複数サブスクリプションや複数環境がある場合は、いきなり本番ではなく、開発・検証環境で表示や挙動を確認してから展開するのが無難です。
診断ログを有効にして利用元を追跡する
Safe Key Rotationで分かるのは、主に「そのキーが最後に使われた日時」です。どのアプリが使ったのかまで特定したい場合は、診断ログの併用が必要です。MicrosoftのPrivate Preview時点の説明では、診断ログを有効にすることで、User Agentや操作種類などの詳細なテレメトリを確認できるとされています。(Microsoft for Developers)
Azure Cosmos DBの診断設定では、Azure MonitorのLog Analyticsワークスペースへリソースログを送信できます。公式ドキュメントでも、診断設定を使ってAzure Cosmos DBのデータプレーン操作ログを収集できることが説明されています。(Microsoft Learn)
実務では、次のように役割を分けて見ると整理しやすくなります。
| 見る情報 | 主な目的 |
|---|---|
| Safe Key Rotationの最終使用日時 | キーが最近使われたかを判断する |
| 診断ログ | どの種類の操作が発生しているかを確認する |
| User Agentや接続元情報 | 利用元アプリの候補を絞る |
| アプリ設定・Key Vault・CI/CD変数 | 実際にどのキーが設定されているかを確認する |
| デプロイ履歴 | キー切り替えがいつ反映されたかを確認する |
「最終使用日時が更新され続けているが、どのアプリか分からない」という状態になったら、診断ログとアプリ設定の棚卸しを先に行うべきです。そこで原因を特定せずに再生成すると、停止リスクが残ります。
Azure Policyでローカル認証の方針を決める
キー認証を段階的に減らすなら、最終的にはローカル認証を無効化する方針も検討対象になります。Azure Cosmos DBには、ローカル認証を無効化してAzure Active Directory、現在のMicrosoft Entra IDによる認証を要求する組み込みポリシーが用意されています。(Microsoft Learn)
ただし、ポリシーをいきなりDenyで適用すると、新規作成や変更が止まり、現場のデプロイに影響することがあります。最初はAuditで現状を可視化し、キー認証が残るアカウントを把握してから、段階的にDenyやModifyを検討する方が安全です。
開発者が確認すべきアプリ側のポイント
開発者が見るべきポイントは、「コードがどの認証方式でCosmos DBに接続しているか」です。接続文字列を直接使っている場合、キー ローテーションの影響を受けます。Microsoft Entra ID認証やマネージドIDに移行できる場合は、長期的にはキー管理そのものを減らせます。
接続文字列の保管場所を洗い出す
最初に、Cosmos DBの接続情報がどこに置かれているかを確認します。
| 確認場所 | 見るべき内容 |
|---|---|
| Azure App Serviceの構成 | AccountEndpoint、AccountKeyを含む接続文字列がないか |
| Azure Functionsのアプリケーション設定 | CosmosDBConnectionなどの設定名でキーを参照していないか |
| Azure Key Vault | Cosmos DBキーや接続文字列のシークレットが残っていないか |
| Kubernetes Secret | 古い接続文字列をPodが参照していないか |
| GitHub Actions / Azure DevOps | CI/CD変数にCosmos DBキーが保存されていないか |
| ローカル開発設定 | appsettings.Development.jsonや.envにキーが残っていないか |
| 運用スクリプト | PowerShell、Bash、Pythonなどで接続文字列を直書きしていないか |
この棚卸しを行わずにSafe Key Rotationの表示だけを見ても、事故防止としては不十分です。特にローカル開発用の設定や古い運用スクリプトは、管理者の目に入りにくい場所に残ります。
Microsoft Entra ID認証への移行を検討する
Azure Cosmos DB for NoSQLでは、Microsoft Entra IDとRBACを使った接続が可能です。公式ドキュメントでは、キー ベース認証を無効化して、アプリケーションにMicrosoft Entra認証のみを使わせる手順が示されています。(Microsoft Learn)
ただし、ここで混同しやすいのが、Azureの管理権限とCosmos DBのデータアクセス権限です。Cosmos DB for NoSQLでは、データプレーンアクセスには専用のロール定義やロール割り当てが関係します。公式ドキュメントでも、データプレーンアクセスはアイテムの読み書きやクエリ実行などを対象とし、組み込みロールやカスタムロールを使って権限を付与すると説明されています。(Microsoft Learn)
つまり、開発者が「Azureポータルで共同作成者だからアプリも読めるはず」と考えるのは危険です。アプリの実行IDに、Cosmos DBのデータプレーン権限が適切なスコープで割り当てられているかを確認してください。
安全なキー ローテーションの進め方
Safe Key Rotationを使う場合でも、キー ローテーションの基本手順は変わりません。重要なのは、PrimaryとSecondaryを片方ずつ使い、アプリが新しいキーで安定して接続できることを確認してから古いキーを再生成することです。
Microsoft Learnでは、キー再生成に1分から複数時間かかる場合があり、ローテーション開始前にアプリがPrimaryまたはSecondaryのどちらかを一貫して使っていることを確認するよう説明されています。(Microsoft Learn)
Primary Keyを使っている場合
| 手順 | 作業 | 判断ポイント |
|---|---|---|
| 1 | Safe Key RotationでPrimary Keyの最終使用日時を確認する | 現在使われているキーを把握する |
| 2 | Secondary Keyを再生成する | 使っていない側を先に新しくする |
| 3 | 新しいSecondary Keyで接続テストする | 検証環境や一部インスタンスで確認する |
| 4 | アプリ設定をPrimaryからSecondaryへ切り替える | Key Vaultや環境変数の反映漏れに注意する |
| 5 | Safe Key RotationでPrimaryの利用が止まったことを確認する | 定期ジョブの実行周期も考慮する |
| 6 | Primary Keyを再生成する | 旧Primaryを無効化する |
公式ドキュメントでも、アプリがPrimary Keyを使っている場合は、Secondary Keyを再生成して検証し、アプリをSecondary Keyに切り替えてからPrimary Keyを再生成する流れが示されています。(Microsoft Learn)
Secondary Keyを使っている場合
| 手順 | 作業 | 判断ポイント |
|---|---|---|
| 1 | Safe Key RotationでSecondary Keyの最終使用日時を確認する | 実際の利用状況を確認する |
| 2 | Primary Keyを再生成する | 使っていない側を先に新しくする |
| 3 | 新しいPrimary Keyで接続テストする | 認証エラー、スロット差分、リージョン差分を見る |
| 4 | アプリ設定をSecondaryからPrimaryへ切り替える | 全インスタンスへ反映されたか確認する |
| 5 | Safe Key RotationでSecondaryの利用停止を確認する | バッチや運用ツールも確認する |
| 6 | Secondary Keyを再生成する | 旧Secondaryを無効化する |
Secondary Keyを使っている場合は、Primary Keyを再生成して検証し、アプリをPrimary Keyに切り替えてからSecondary Keyを再生成する流れになります。(Microsoft Learn)
展開時に失敗しやすいポイント
Safe Key Rotationの導入で失敗しやすいのは、機能そのものよりも、運用設計の抜けです。特に次のパターンは注意してください。
| 失敗パターン | 原因 | 対策 |
|---|---|---|
| 最終使用日時だけを見て即再生成する | 有効化前の利用履歴や低頻度ジョブを見落とす | 観測期間を決め、月次・年次ジョブを確認する |
| アプリは切り替えたが運用スクリプトが古いまま | 本番アプリ以外の棚卸し不足 | CI/CD、手動運用、監視ツールまで確認する |
| Key Vaultだけ更新してアプリが再読み込みしていない | アプリ側の設定反映タイミングを誤解 | 再起動、設定更新、シークレット参照の仕様を確認する |
| PrimaryとSecondaryを同時期に再生成する | ロールバック先がなくなる | 必ず片方ずつ切り替える |
| Entra ID移行後に権限不足で失敗する | データプレーンRBACの設定漏れ | 実行ID、ロール、スコープを事前に検証する |
| 本番で初めて手順を試す | プレビュー機能や反映時間を確認していない | 検証環境で作業ログを作ってから本番適用する |
特にKey Vaultを使っている環境では、「Key Vaultの値を更新したから完了」と考えがちです。実際には、アプリがシークレットを起動時だけ読み込む構成なら、再起動や再デプロイが必要になる場合があります。キー ローテーションは、Cosmos DB側の作業ではなく、アプリ設定の反映確認まで含めて完了です。
導入前チェックリスト
Safe Key Rotationを有効化する前に、次の項目を確認しておくと、導入後の判断がぶれにくくなります。
| チェック項目 | 完了の目安 |
|---|---|
| 対象のCosmos DBアカウントを一覧化した | 開発、検証、本番を分けて管理できている |
| どのアプリがどのアカウントに接続しているか整理した | アプリ名、環境、担当チームが分かる |
| PrimaryとSecondaryのどちらを使っているか確認した | 接続文字列やKey Vaultの値で確認済み |
| 定期ジョブの実行周期を確認した | 月次・四半期・年次処理も含めて把握済み |
| 診断ログの送信先を決めた | Log Analyticsなどで確認できる |
| ローテーション時のロールバック手順を決めた | 切り戻し先のキーと反映方法が明確 |
| 変更管理の承認フローを決めた | 作業日時、承認者、影響範囲を記録できる |
| Entra ID移行の方針を決めた | キー認証を残すのか段階的に廃止するのか明確 |
このチェックリストを満たしてからSafe Key Rotationを使うと、単なる画面確認ではなく、運用改善として活用できます。
まず何をすべきか
Azure Cosmos DBでアカウントキー認証を使っているなら、最初にやるべきことはキーの再生成ではありません。まず、対象アカウントを洗い出し、Safe Key Rotationを検証環境で有効化し、キーの最終使用日時がどのように表示されるかを確認してください。
そのうえで、本番環境では次の順序で進めるのが現実的です。
| 優先度 | やること | 目的 |
|---|---|---|
| 高 | Cosmos DBアカウントと接続アプリを棚卸しする | 影響範囲を明確にする |
| 高 | Safe Key Rotationを有効化して観測を開始する | キー利用状況を把握する |
| 高 | 診断ログを有効化する | 利用元特定の手掛かりを増やす |
| 中 | Primary/Secondaryの切り替え手順を検証する | 本番作業の失敗を防ぐ |
| 中 | 低頻度ジョブの実行タイミングを確認する | 「使われていない」誤判定を防ぐ |
| 中 | Microsoft Entra ID認証への移行可否を検討する | 長期的にキー管理を減らす |
| 低 | Azure Policyでローカル認証の監査を始める | 組織全体のセキュリティ標準に近づける |
Safe Key Rotationは、Azure Cosmos DBのキー ローテーションを安全にするための重要な一歩です。ただし、最終使用日時だけで判断せず、診断ログ、アプリ設定、運用ジョブ、Microsoft Entra IDへの移行計画まで含めて確認することが大切です。まずは検証環境で機能を有効化し、自社のキー利用がどれだけ見えるかを確認するところから始めてください。
コメント