2026年4月21日にMicrosoftが公開した今回の更新は、Azure Resource Graph Explorer で Redis 構成を横断確認するための公式クエリ集を出したことです。実務で最初に見るべきなのは、microsoft.cache/redis と microsoft.cache/redisEnterprise の切り分け、publicNetworkAccess、minimumTlsVersion、そして Microsoft Entra authentication と access key の扱いです。特に公式の Entra 関連クエリは microsoft.cache/redis 向けで、Azure Managed Redis 側は同じ見方でそのまま判定できません。 (TECHCOMMUNITY.MICROSOFT.COM)
要するに今回の価値は、「Redis に新機能が増えた」ことではなく、「PowerShell や Azure CLI のスクリプトを組む前に、Azure portal の Azure Resource Graph で security posture review を始めやすくなった」ことです。Azure Resource Graph は複数サブスクリプションにまたがるクエリを前提にしており、Resource Graph Explorer からスコープを選んでそのまま実行できます。 (TECHCOMMUNITY.MICROSOFT.COM)
今回の更新を実務でどう読むべきか
Microsoft が今回まとめたのは、Redis の全体棚卸しに必要な観点を公式に整理した点です。具体的には、SKU、Redis バージョン、最小 TLS、パブリック ネットワーク露出、Microsoft Entra 認証と access key 無効化です。ただし、Redis バージョンと Entra/auth の確認は microsoft.cache/redis に寄っており、microsoft.cache/redisEnterprise には同じ列がそのまま出ない点が重要です。 (TECHCOMMUNITY.MICROSOFT.COM)
もうひとつ重要なのは、Azure Resource Graph は「最初のふるい分け」には強い一方で、直接の GET 結果と完全一致するとは限らないことです。Microsoft も、Azure Resource Graph では PII がスクラブされるため、直接取得したリソース情報と差が出る場合があると明記しています。監査証跡や接続元の実態確認まで含めるなら、診断ログや Activity log と組み合わせる前提で使うのが安全です。 (Microsoft Learn)
最初に確認すべき4つの変更点
microsoft.cache/redis と microsoft.cache/redisEnterprise を別集計にする
今回のガイダンスは microsoft.cache/redis と microsoft.cache/redisEnterprise を対象にしています。現行のリソース定義では Microsoft.Cache/redisEnterprise は Azure Managed Redis とされており、ここを分けないまま 1 本の集計で見ると、空欄を「未設定」と誤判定しやすくなります。特に Entra 認証の公式クエリは microsoft.cache/redis 限定なので、最初の棚卸しから resource type で分けるのが実務上の正解です。 (TECHCOMMUNITY.MICROSOFT.COM)
private endpoint の有無だけで安心しない
Azure Managed Redis では publicNetworkAccess によって、private link を使いながら public traffic も許可する構成が取れるようになっています。つまり、「private endpoint がある = public が閉じている」とは限りません。さらに Microsoft.Cache/redisEnterprise の publicNetworkAccess は 2025-07-01 API で導入されたため、古い API で作られたクラスターでは null が返ることがあります。最も安全なのは、VNet と private endpoint を使い、publicNetworkAccess を無効にする構成です。 (Microsoft Learn)
Entra 認証は「有効か」より「どのサービスでどう見るか」が重要
Azure Cache for Redis の公式ドキュメントでは、Microsoft Entra authentication の対象は Basic、Standard、Premium で、旧 Enterprise / Enterprise Flash は対象外です。一方、Azure Managed Redis では Microsoft Entra ID が既定で有効化され、キャッシュ作成時に managed identity も有効になります。今回の ARG ガイダンスが Entra/auth を microsoft.cache/redis だけで見ているのは、この差をそのまま反映したものです。サービス名が似ていても、Entra の読み方は同じではありません。 (Microsoft Learn)
変更作業そのものが接続影響を持つ
Azure Cache for Redis で Entra を有効化すると、ノード再起動が入り、完了まで最大 30 分かかることがあります。さらに access key の無効化は、access key 接続だけでなく Entra 接続も含めて既存クライアント接続をすべて切断します。geo-replicated cache では unlink → disable → relink の順序が必要です。設定だけ直して終わりではなく、maintenance window とクライアントの再接続設計までセットで考える必要があります。 (Microsoft Learn)
すぐ使える Azure Resource Graph クエリ例
Azure portal の Resource Graph Explorer では、ディレクトリ、管理グループ、サブスクリプションをスコープにしてクエリを実行できます。まずは「全資産の切り分け」「公開露出と TLS」「legacy Azure Cache for Redis の認証状態」の 3 本を走らせると、最初の判断材料はかなり揃います。 (Microsoft Learn)
まずは全 Redis 資産を棚卸しする
公式ガイダンスが前提にしている microsoft.cache/redis と microsoft.cache/redisEnterprise をそのまま分けて見ます。ここで resource type を分けるだけで、後続の判断ミスがかなり減ります。 (TECHCOMMUNITY.MICROSOFT.COM)
Resources
| where type in~ ('microsoft.cache/redis', 'microsoft.cache/redisenterprise')
| extend Family = case(type =~ 'microsoft.cache/redis', 'AzureCacheForRedis', 'AzureManagedRedis')
| extend SkuName = coalesce(tostring(sku.name), tostring(properties.sku.name))
| project subscriptionId, resourceGroup, name, location, type, Family, SkuName
| order by Family asc, name ascこの一覧ができたら、少なくとも AzureCacheForRedis と AzureManagedRedis を同じ remediation backlog に入れないことが大切です。Entra の確認方法も access key の止め方も、ここから先は分岐します。 (TECHCOMMUNITY.MICROSOFT.COM)
次に公開露出と TLS を確認する
minimumTlsVersion と publicNetworkAccess は、今回の公式ガイダンスでも両系統で共通に見られる項目です。まずここを見れば、「外から見えているか」「古い暗号設定が残っていないか」を横断的に拾えます。 (TECHCOMMUNITY.MICROSOFT.COM)
Resources
| where type in~ ('microsoft.cache/redis', 'microsoft.cache/redisenterprise')
| extend MinimumTLS = tostring(properties.minimumTlsVersion)
| extend PublicNetworkAccess = tostring(properties.publicNetworkAccess)
| extend PublicNetworkState = case(isempty(PublicNetworkAccess), 'LegacyOrNull', PublicNetworkAccess)
| project subscriptionId, resourceGroup, name, type, location, MinimumTLS, PublicNetworkState
| order by PublicNetworkState desc, MinimumTLS ascPublicNetworkState = Enabled は、意図しない public 公開の候補です。ただし Azure Managed Redis では移行都合で public と private を併用するケースもあり得るので、即 NG ではなく「明示的な例外か」を確認してください。一方で LegacyOrNull は安全を意味しません。古い API 由来の null の可能性があるため、Networking blade か新しい API ベースの運用手順で状態を確定させるべきです。TLS については 1.2 以上が推奨ラインです。 (Microsoft Learn)
legacy Azure Cache for Redis の認証状態を見る
Entra 認証と access key 停止の状況を ARG で見たいなら、今回の公式ガイダンスどおり microsoft.cache/redis に限定して見るのが安全です。Azure Managed Redis はこのクエリの対象ではありません。 (TECHCOMMUNITY.MICROSOFT.COM)
Resources
| where type =~ 'microsoft.cache/redis'
| extend RedisVersion = tostring(properties.redisVersion)
| extend EntraAuthEnabled = tostring(properties.redisConfiguration['aad-enabled'])
| extend AccessKeysDisabled = tostring(properties.disableAccessKeyAuthentication)
| project subscriptionId, resourceGroup, name, location, RedisVersion, EntraAuthEnabled, AccessKeysDisabled
| order by name asc実務では、EntraAuthEnabled=false、AccessKeysDisabled=false のまま残っている本番系キャッシュを優先確認対象にしやすいです。さらに RedisVersion=4.0 が出たら要注意です。Redis 4 の Azure Cache for Redis では Redis ACL と data access policy がサポートされないため、least privilege 設計や Entra ベースの細かな権限分離を前提に進めると詰まります。 (TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Entra authentication で見落としやすい点
- Azure Cache for Redis で Entra を有効化すると、最初に追加したユーザーやサービス プリンシパル、managed identity が既定で Data Owner Access Policy に割り当てられます。PoC では便利でも、本番ではそのままにせず、Data Owner / Data Contributor / Data Reader、必要なら custom data access policy に落とし直すべきです。 (Microsoft Learn)
- Entra グループはサポートされません。さらに Azure Cache for Redis の custom data access policy は Basic / Standard / Premium でのみ使え、旧 Enterprise / Enterprise Flash では使えません。権限設計は「どのサービスか」と「Redis バージョン」を見て分ける必要があります。 (Microsoft Learn)
- Entra 接続は、トークンを期限前に更新して
AUTHを再送できるクライアントでないと安定しません。Microsoft は少なくとも有効期限の 3 分前までに新しいトークンを送ること、さらにAUTHを一斉送信しないよう jitter を入れることを勧めています。 (Microsoft Learn) - access key を止める前は、Azure Cache for Redis なら
Connected ClientsとConnected Clients Using Microsoft Entra Tokenが一致していることを確認してから切り替えるのが安全です。geo-replicated cache では unlink → disable → relink の順序も忘れやすいポイントです。 (Microsoft Learn) - Azure Managed Redis 側で Entra 接続の疎通確認をしたい場合は、
az redisenterprise test-connection --auth entraが使えます。アプリ側の問題か、認証設定か、ネットワークかを切り分ける最初の一手として有効です。 (Microsoft Learn)
継続監査の組み立て方
ARG は discovery に強く、診断ログは runtime に強い、という役割分担で考えると運用しやすくなります。ARG で「どの設定が残っているか」を洗い出し、接続ログで「誰がいつ接続したか」を見て、Activity log で「誰が設定を変えたか」を追う、という三層に分けると、セキュリティレビューが一度きりで終わりにくくなります。 (Microsoft Learn)
特に Azure Managed Redis の接続ログはイベント ベースです。切断ログは取りこぼしの可能性があり、保持期間を短くすると「今も接続中だがログは消えている」状態が起こり得ます。さらに、接続ログの有効化はパフォーマンスに影響する可能性もあるため、regulated workload では retention と有効化範囲を先に決めてから導入したほうが安全です。 (Microsoft Learn)
是正を継続させたいなら、ARG で見つけたルールは Azure Policy に寄せるべきです。Azure Cache for Redis には、public network access の無効化、access key 不使用、private link 必須、SSL only、Log Analytics などへの診断ログ有効化といった built-in policy が用意されています。Azure Managed Redis のセキュリティ ガイドも、Azure Policy による準拠管理を推奨しています。ARG を discovery、Policy を enforcement、diagnostics を evidence と分けると、監査の再現性がかなり上がります。 (Microsoft Learn)
ここまで読んだら最初の1週間でやること
- まず今日中に、Azure Resource Graph で全 Redis 資産を
microsoft.cache/redisとmicrosoft.cache/redisEnterpriseに分けて棚卸しし、publicNetworkAccess、minimumTlsVersion、Entra/auth 状態を赤・黄・緑で分類します。ここを曖昧にしたまま remediation を始めると、後でサービス差異に引っかかります。 (Microsoft Learn) - 今週中に、Entra へ寄せる対象のクライアントを洗い出し、トークン更新と
AUTH再送に対応できるか、maintenance window を取れるか、access key 停止前のメトリクス確認ができるかを見ます。Azure Managed Redis ならaz redisenterprise test-connection --auth entraで疎通確認まで実施しておくと、切替時の事故が減ります。 (Microsoft Learn) - そのうえで、継続条件は Azure Policy と診断設定に移し、移行期限のある旧サービスは remediation と migration を同じ計画で扱います。旧 Azure Cache for Redis Enterprise / Enterprise Flash は 2027年3月31日に廃止、2027年4月1日から無効化です。Basic / Standard / Premium も 2028年9月30日に廃止予定なので、セキュリティ是正だけ先に進めて移行を後回しにするより、Azure Managed Redis への移行計画を同時に進めるほうが現実的です。 (Microsoft Learn)
コメント