Azure Resource Graph / Azure Cache for Redis / Microsoft Entra authentication の今回の動きで現場がまず変わるのは、Redis のセキュリティ確認を「各サブスクリプションを開いて目視する作業」から「KQLで横断抽出し、是正対象をすぐ判断する作業」に移せる点です。
2026年4月21日時点で押さえたい更新は、Microsoft が Azure Redis 構成レビュー向けに Azure Resource Graph のクエリ活用ガイダンスを公開していることです。対象には SKU、Redis バージョン、最小 TLS、Public Network Access、Microsoft Entra 認証、アクセスキー認証の状態が含まれます。従来は PowerShell、Azure CLI、REST API のスクリプトを個別に用意しがちでしたが、Azure Resource Graph Explorer を使えば、複数サブスクリプションの Redis 構成を Azure portal からまとめて確認できます。(TECHCOMMUNITY.MICROSOFT.COM)
特に管理者、Power User、ソリューションオーナーにとって重要なのは、「Entra 認証を有効にするか」だけではありません。どの Redis がまだアクセスキーを使っているのか、どの環境がパブリック公開されているのか、移行対象の SKU はどこにあるのかを、運用会議やセキュリティレビューで使える一覧に変えることが本当の価値です。
Azure Resource Graph / Azure Cache for Redis / Microsoft Entra authentication の最新動向
Microsoft のガイダンスでは、Azure Resource Graph Explorer から Resources テーブルを使い、microsoft.cache/redis と microsoft.cache/redisenterprise を対象に Azure Redis の構成値を取得する流れが示されています。確認できる代表的な項目は、SKU、Redis バージョン、最小 TLS バージョン、Public Network Access、Microsoft Entra 認証、アクセスキー認証の状態です。(TECHCOMMUNITY.MICROSOFT.COM)
これが現場で効く理由は、Azure Cache for Redis の管理が「単一リソースの設定確認」では済まなくなっているためです。複数のアプリ、複数のリージョン、複数のサブスクリプションに Redis が分散している環境では、ポータルで1つずつ見るだけでは、次のような問いにすぐ答えられません。
- 本番環境でアクセスキー認証が残っている Redis はどれか
- Public Network Access が有効な Redis はどれか
- TLS 設定が古い Redis はどれか
- Azure Cache for Redis のリタイア対応や Azure Managed Redis 移行の対象はどれか
- Microsoft Entra authentication の rollout をどの順番で進めるべきか
Azure Resource Graph を使うと、これらを「調査」ではなく「棚卸し」として定例化できます。つまり、セキュリティチームが全体像を出し、アプリ担当者が該当リソースを確認し、ソリューションオーナーが移行や例外承認を判断する流れを作れます。
何が変わるのか：Redis管理のワークフロー比較
| 観点 | 従来の進め方 | Azure Resource Graph 活用後 |
|---|---|---|
| 構成確認 | ポータルで個別確認、または CLI / PowerShell スクリプトを作成 | Resource Graph Explorer で KQL を実行し、複数サブスクリプションを横断確認 |
| 認証方式の棚卸し | アプリ担当者へのヒアリングに依存しやすい | Entra 認証とアクセスキー無効化の状態を一覧化 |
| セキュリティレビュー | 年次・四半期の手作業レビューになりがち | 月次チェック、チケット化、例外管理に組み込みやすい |
| 移行計画 | SKU や環境の一覧作成から時間がかかる | SKU、リージョン、リソースグループ単位で優先順位を付けやすい |
| グローバル運用 | 拠点やリージョンごとの確認結果がばらつく | 同じ KQL を使い、共通フォーマットで報告できる |
ポイントは、Azure Resource Graph が修正そのものを自動化するわけではないことです。役割は「正しい修正対象を早く見つけること」です。是正は Azure Policy、IaC、手動変更、アプリ改修、メンテナンスウィンドウと組み合わせて進めます。
まず使いたいKQL：Redisの全体像を一覧化する
最初に実行すべきなのは、Redis インスタンスの一覧化です。SKU、リージョン、リソースグループが見えるだけでも、誰が管理すべきか、どの環境から着手すべきかを判断しやすくなります。
Resources
| where type in~ ("microsoft.cache/redis", "microsoft.cache/redisenterprise")
| extend SKU = coalesce(tostring(sku.name), tostring(properties.sku.name))
| project name, resourceGroup, subscriptionId, location, type, SKU
| order by location asc, resourceGroup asc, name ascこのクエリは、Azure Cache for Redis と Redis Enterprise 系のリソースを横断して、基本的な棚卸しを行うためのものです。Microsoft のガイダンスでも、SKU 情報は性能、高可用性、スケーリング構成を理解するための入り口として扱われています。(TECHCOMMUNITY.MICROSOFT.COM)
実務では、この結果に次の列を手作業または別システムで補うと使いやすくなります。
| 追加するとよい項目 | 使い道 |
|---|---|
| アプリ名 | 是正依頼の宛先を明確にする |
| 環境区分 | 本番、検証、開発で優先順位を分ける |
| オーナー | チケット担当者を決める |
| 期限 | Entra 認証移行や公開設定見直しの期限を管理する |
| 例外理由 | すぐ変更できないリソースの説明責任を残す |
タグ設計が整っている組織なら、tags を project に含めるとさらに実用的です。逆にタグが不足している場合は、今回の棚卸しをきっかけに「Redis には必ず owner、environment、application タグを付ける」といったルールを整備すると、次回以降のレビューが楽になります。
シナリオ：Microsoft Entra authentication の rollout 対象を見つける
もっとも実務に直結するのが、Microsoft Entra authentication の rollout です。Azure Cache for Redis では、Basic、Standard、Premium の OSS キャッシュについて、Microsoft Entra 認証とアクセスキー認証の状態を Resource Graph で確認できます。Microsoft のガイダンスでは、properties.redisConfiguration["aad-enabled"] と properties.disableAccessKeyAuthentication を使うクエリが示されています。(TECHCOMMUNITY.MICROSOFT.COM)
Resources
| where type =~ "microsoft.cache/redis"
| extend EntraAuthEnabled = tostring(properties.redisConfiguration["aad-enabled"])
| extend KeyBasedAuthDisabled = tostring(properties.disableAccessKeyAuthentication)
| project name, resourceGroup, subscriptionId, location, EntraAuthEnabled, KeyBasedAuthDisabled
| order by KeyBasedAuthDisabled asc, EntraAuthEnabled ascこの結果は、次のように読むと判断しやすくなります。
| EntraAuthEnabled | KeyBasedAuthDisabled | 状態 | 次のアクション |
|---|---|---|---|
true | true | Entra 認証へ移行済み | 定期監査と接続監視を継続 |
true | false | Entra 認証は使えるが、アクセスキーも残っている | アプリ接続状況を確認し、アクセスキー無効化を計画 |
false | false | 従来型のアクセスキー依存 | アプリ改修、認証方式変更、メンテナンス計画が必要 |
false | true | 通常は要確認 | 個別リソースの設定、接続可否、構成変更履歴を確認 |
注意したいのは、アクセスキーを無効化する作業は「セキュリティ設定のチェックを入れるだけ」ではないことです。Microsoft Learn では、アクセスキー認証を無効化すると、アクセスキー接続か Microsoft Entra 接続かに関係なく既存のクライアント接続が終了すると説明されています。また、無効化前には Entra 認証が有効であること、少なくとも1つの Redis User が構成されていること、アプリが Entra 認証へ切り替わっていること、接続クライアント数と Entra トークン利用クライアント数のメトリックが一致していることを確認する必要があります。(Microsoft Learn)
そのため、現場では次の順番で進めるのが安全です。
| フェーズ | 実施内容 | 判断基準 |
|---|---|---|
| 棚卸し | Resource Graph で Entra 認証とアクセスキー状態を一覧化 | KeyBasedAuthDisabled=false を優先的に抽出 |
| 影響確認 | Redis に接続するアプリ、ジョブ、運用ツールを洗い出す | 接続文字列やシークレットにアクセスキーが残っていないか確認 |
| アプリ改修 | Managed Identity、サービスプリンシパル、MSAL などを使う接続方式へ変更 | Entra トークンで安定接続できること |
| メトリック確認 | Entra トークン利用クライアント数を確認 | アクセスキー利用の接続が残っていないこと |
| 変更実施 | メンテナンス時間帯にアクセスキー認証を無効化 | 再接続処理、リトライ、監視アラートを準備 |
| 事後確認 | アプリ稼働、エラー率、接続数を確認 | 障害がなければ例外リストから除外 |
シナリオ：Public Network Access の見直しを定例化する
Redis はアプリケーションのキャッシュ、セッションストア、メッセージング用途で使われることが多く、公開範囲のミスがセキュリティリスクになりやすいサービスです。Microsoft のガイダンスでは、properties.publicNetworkAccess を使って、Public Network Access が有効かどうかを確認するクエリも示されています。(TECHCOMMUNITY.MICROSOFT.COM)
Resources
| where type in~ ("microsoft.cache/redis", "microsoft.cache/redisenterprise")
| extend PublicNetworkAccess = tostring(properties.publicNetworkAccess)
| project name, resourceGroup, subscriptionId, location, type, PublicNetworkAccess
| where PublicNetworkAccess =~ "Enabled"
| order by location asc, resourceGroup ascこのクエリで抽出された Redis は、すぐに「危険」と断定するのではなく、次の観点で分類します。
| 分類 | 例 | 対応方針 |
|---|---|---|
| すぐ是正 | 本番 Redis が不要にパブリック公開されている | Private Endpoint 化、Public Network Access 無効化を優先 |
| 設計確認 | 外部拠点や別ネットワークから接続する要件がある | ネットワーク設計、Firewall、Private Link の可否を確認 |
| 一時例外 | 移行中、検証中、期限付きの公開 | 期限、承認者、代替案を明記 |
| 誤検知・確認待ち | プロパティ値だけでは意図が判断できない | 個別リソースの設定と接続経路を確認 |
Azure Policy には、Azure Cache for Redis の public network access 無効化、Private Link 利用、SSL only、アクセスキー認証を使わないことを監査・制御する組み込みポリシーが用意されています。Resource Graph で「現状把握」、Azure Policy で「継続的な逸脱検知」を行うと、レビューが一度きりで終わりません。(Microsoft Learn)
シナリオ：TLSとRedisバージョンを移行計画に結び付ける
セキュリティレビューでは、認証方式だけでなく、TLS と Redis バージョンも確認対象になります。Microsoft のガイダンスでは、最小 TLS バージョンを properties.minimumTlsVersion で取得するクエリ、Basic / Standard / Premium の OSS キャッシュに対して Redis バージョンを properties.redisVersion で取得するクエリが紹介されています。(TECHCOMMUNITY.MICROSOFT.COM)
Resources
| where type in~ ("microsoft.cache/redis", "microsoft.cache/redisenterprise")
| extend MinimumTLS = tostring(properties.minimumTlsVersion)
| project name, resourceGroup, subscriptionId, location, type, MinimumTLS
| order by MinimumTLS ascResources
| where type =~ "microsoft.cache/redis"
| project name, resourceGroup, subscriptionId, location, SKU=sku.name, RedisVersion=properties.redisVersion
| order by RedisVersion ascここで大切なのは、古い設定を見つけたら、単純に「最新版へ上げる」と決めないことです。Redis はアプリケーションの接続ライブラリ、クラスタリング、接続再試行、タイムアウト設定と密接に関係します。特に本番環境では、以下を確認してから変更します。
| 確認項目 | 具体的に見るポイント |
|---|---|
| クライアントライブラリ | Entra 認証、クラスタリング、TLS 要件に対応しているか |
| 接続再試行 | ノード再起動や一時切断時に復旧できるか |
| 運用ジョブ | バッチ、監視、メンテナンスツールも同じ認証方式に対応しているか |
| シークレット管理 | Key Vault や CI/CD 変数に古いアクセスキーが残っていないか |
| ロールバック | 設定変更後に問題が出た場合の戻し方を決めているか |
Microsoft Learn では、Microsoft Entra 認証を有効化した後、キャッシュ内のノードが再起動して新しい構成を読み込むため、操作に最大30分かかる場合があり、メンテナンス期間中またはピーク外に行うことが推奨されています。(Microsoft Learn)
シナリオ：Azure Cache for Redis のリタイア対応にも使う
Azure Cache for Redis は、今後の移行計画も無視できません。Microsoft Learn の FAQ では、Basic、Standard、Premium は 2028年9月30日にリタイア、Enterprise と Enterprise Flash は 2027年3月31日にリタイア予定と案内されています。また、Microsoft は Azure Managed Redis への早期アップグレードを推奨しています。(Microsoft Learn)
この文脈でも Azure Resource Graph は有効です。まず既存の Redis を SKU 別に一覧化し、次のように優先順位を付けます。
| 優先度 | 対象 | 理由 |
|---|---|---|
| 高 | Enterprise / Enterprise Flash | リタイア期限が近い |
| 高 | 本番かつアクセスキー認証が残っている Redis | セキュリティ改善と移行計画を同時に進める必要がある |
| 中 | Public Network Access が有効な Redis | ネットワーク設計の見直しが必要 |
| 中 | 古い Redis バージョンや TLS 設定の確認が必要な Redis | アプリ互換性の確認に時間がかかる |
| 低 | 開発・検証環境の小規模 Redis | 本番移行方針の後に標準化しやすい |
ただし、Azure Resource Graph だけで Azure Managed Redis まで完全に同じ粒度で確認できるとは限りません。Microsoft のガイダンスでは、Redis バージョンや Microsoft Entra 認証状態に関する一部クエリについて、Azure Managed Redis の該当プロパティは Azure Resource Graph に公開されていないため対象外とされています。(TECHCOMMUNITY.MICROSOFT.COM)
つまり、Azure Resource Graph は「既存 Azure Cache for Redis の棚卸し」と「移行対象の切り分け」に強い一方、移行後の Azure Managed Redis については、個別の管理画面、API、監視、移行ドキュメントと組み合わせて確認する必要があります。
Microsoft Entra認証へ移すときの失敗しやすいポイント
Microsoft Entra authentication の rollout でよく起きる失敗は、Redis 側の設定変更だけを先に進めてしまうことです。実際には、アプリケーション側の接続方式、権限、トークン更新、再接続処理まで含めて設計しないと、設定変更の瞬間に障害へつながります。
Microsoft Learn では、多くの Azure Cache for Redis クライアントはパスワードとアクセスキーを使う前提であるため、Microsoft Entra トークンを使うようにクライアントワークフローを更新する必要があると説明されています。接続時には、ユーザーとしてマネージド ID またはサービスプリンシパルの Object ID を使い、パスワードとして MSAL などで取得した Microsoft Entra トークンを使う流れが示されています。(Microsoft Learn)
特に注意すべき点は次のとおりです。
| 注意点 | 実務上の対策 |
|---|---|
| トークン期限切れ | Redis クライアントが期限前に再認証できるようにする |
| 一斉再認証 | 複数クライアントが同時に AUTH しないようランダム遅延を入れる |
| 接続断 | アクセスキー無効化時に既存接続が切れる前提でリトライを実装する |
| 権限過多 | すべてのアプリに Data Owner 相当を与えず、用途別にアクセス範囲を分ける |
| 運用ツール漏れ | アプリ本体だけでなく、バッチ、監視、手動運用ツールも確認する |
Microsoft Learn では、Microsoft Entra 認証のベストプラクティスとして、Private Link や Firewall でキャッシュを保護すること、トークン期限の少なくとも3分前に新しいトークンを送ること、定期的な AUTH にランダム遅延を加えることも推奨されています。(Microsoft Learn)
管理者・ソリューションオーナー別の使い方
Azure Resource Graph の結果は、誰が見るかによって価値が変わります。単にクエリ結果を共有するだけではなく、役割ごとに「次の判断」へつなげることが重要です。
| 役割 | 見るべき項目 | 取るべきアクション |
|---|---|---|
| クラウド管理者 | Public Network Access、TLS、SKU、Policy 準拠 | 標準設定、Azure Policy、例外ルールを整備 |
| セキュリティ担当 | アクセスキー認証、Entra 認証、公開範囲 | 高リスク項目をチケット化し、期限を設定 |
| アプリ担当 | 接続方式、クライアントライブラリ、トークン更新 | Entra 認証対応と再接続処理を実装 |
| ソリューションオーナー | 本番影響、移行期限、コスト、可用性 | 移行順序、停止許容時間、例外承認を判断 |
| Power User | クエリ結果、タグ、リソースグループ | レポート化、ダッシュボード化、定例レビューを支援 |
グローバル環境では、リージョンや拠点ごとに運用成熟度が異なることがあります。その場合でも、共通の KQL を使えば、各国・各部門の Redis 構成を同じ基準で比較できます。これは、英語圏のチーム、日本の管理部門、外部ベンダーが同じ一覧を見ながら議論する場面で特に有効です。
実務に落とし込むためのチェックリスト
最後に、今回の更新を現場で活かすための最小手順を整理します。
| 手順 | やること | 成果物 |
|---|---|---|
| 1 | Azure Resource Graph Explorer で Redis 一覧を取得 | Redis インベントリ |
| 2 | Entra 認証、アクセスキー、Public Network Access、TLS を抽出 | セキュリティ姿勢レビュー表 |
| 3 | 本番、検証、開発に分類 | 優先順位リスト |
| 4 | アプリオーナーを紐付け | 是正チケット |
| 5 | Entra 認証対応の可否を確認 | アプリ改修計画 |
| 6 | メンテナンス時間帯を決める | 変更計画 |
| 7 | アクセスキー無効化後に接続・メトリックを確認 | 完了証跡 |
| 8 | Azure Policy や定例クエリで継続監査 | 再発防止の仕組み |
最初の一歩は、大がかりな自動化ではありません。まず Resource Graph Explorer で Redis の一覧を出し、KeyBasedAuthDisabled=false と PublicNetworkAccess=Enabled のリソースを見つけることです。そこから、アプリオーナー確認、Entra 認証対応、メンテナンス計画、Azure Policy による継続監査へ進めれば、今回の Azure Resource Graph / Azure Cache for Redis / Microsoft Entra authentication の更新は、単なるニュースではなく、現場のセキュリティ運用を変える実用的なワークフローになります。
コメント