2026年4月21日にMicrosoftが公開した「Azure Resource Graph Queries for Azure Redis Configuration」は、Azure Cache for RedisのSKU、Redisバージョン、TLS設定、パブリックネットワーク公開、Microsoft Entra authenticationの状態をAzure Resource Graphで横断確認するための実務ガイダンスです。結論から言うと、これは単なるKQLサンプル集ではありません。Azure Redis運用は今後、個別スクリプトで点検する運用から、Azure Resource Graphで継続的に棚卸しし、Azure Managed Redisへの移行とMicrosoft Entra authenticationを前提に標準化する運用へ移るべきです。(TECHCOMMUNITY.MICROSOFT.COM)
特にProduct owner、IT decision-maker、technical strategistにとって重要なのは、「いま危険なRedis設定を見つける」だけではなく、「どのサービスを残し、どのサービスを移行し、どの認証方式を標準にするか」をロードマップとして決めることです。Azure Cache for Redisには提供終了スケジュールがあり、Basic／Standard／Premiumは2028年9月30日、Enterprise／Enterprise Flashは2027年3月31日が提供終了日として示されています。運用判断を後回しにすると、セキュリティ対応と移行対応が同時に発生します。(Microsoft Learn)
Microsoftの今回の更新で何を読むべきか
今回のMicrosoft Tech Communityの記事は、Azure Resource Graph ExplorerでRedis構成を素早く確認する方法を示しています。対象としているリソースタイプは microsoft.cache/redis と microsoft.cache/redisenterprise で、KQLを使って複数サブスクリプションのRedis構成を一覧化する流れです。確認項目は、SKU、Redisバージョン、最小TLSバージョン、パブリックネットワークアクセス、Microsoft Entra認証、アクセスキー認証の状態です。(TECHCOMMUNITY.MICROSOFT.COM)
この更新から読み取れる製品方向性は、主に3つあります。
| 観点 | 読み取れる方向性 | 運用上の意味 |
|---|---|---|
| Azure Resource Graph | Azureリソースの構成を横断的に見える化する基盤として使う | Redis単体ではなく、クラウド資産管理・セキュリティレビューの一部として扱う |
| Azure Cache for Redis | 既存資産は維持よりも移行計画の対象になる | SKU、リージョン、認証方式、ネットワーク構成を棚卸しし、Azure Managed Redisへの移行順を決める |
| Microsoft Entra authentication | アクセスキー中心の運用からIDベース認証へ寄せる | 静的キーの漏えいリスクを下げ、マネージドIDやサービスプリンシパルを前提に設計する |
ポイントは、Azure Resource Graphを「監査時に一度だけ使うツール」と見ないことです。複数サブスクリプションにRedisが散在している組織では、KQLで定期的に状態を確認し、移行計画・セキュリティ基準・例外管理を同じデータで進めることが実務上の価値になります。
Azure Resource GraphはRedis運用の「棚卸し基盤」になる
Azure Resource Graphは、Azureリソースをサブスクリプション横断で高速に検索・集計するためのサービスです。Azure Resource Managerに個別問い合わせするのではなく、Resource Graphに蓄積されたリソースプロパティをKQLで検索できます。Microsoftの説明でも、複雑なフィルタリング、グルーピング、ソート、ポリシー適用影響の評価、リソースプロパティ変更の確認に使えるとされています。(Microsoft Learn)
Redis運用でAzure Resource Graphを使う価値は、次のような場面で出ます。
| ユースケース | 具体的に見る項目 | 判断に使えること |
|---|---|---|
| セキュリティレビュー | TLS、パブリックネットワーク、認証方式 | 公開リスクやキー認証依存を洗い出す |
| 移行計画 | SKU、リージョン、リソースタイプ | Azure Managed Redisへの移行対象を優先順位付けする |
| 標準化 | タグ、リソースグループ、サブスクリプション | 所有者不明・用途不明のRedisを減らす |
| 経営報告 | 環境別・事業部別のRedis数 | 提供終了対応の進捗を可視化する |
従来のAzure CLIやPowerShellでも同じような確認はできます。ただし、モジュール準備、スクリプト保守、サブスクリプションごとの実行、例外処理が増えると、点検そのものが属人化します。Azure Resource Graphを使うと、KQLを共有し、同じ観点で全体を確認しやすくなります。
Azure Cache for Redisは「使い続けるか」ではなく「どう移行するか」を考える段階
Azure Cache for Redisは、すでに提供終了のタイムラインが示されています。Basic、Standard、Premiumの全インスタンスは2028年9月30日に提供終了し、2028年10月1日以降は残存インスタンスが無効化されると説明されています。EnterpriseおよびEnterprise Flashはさらに早く、2027年3月31日に提供終了し、2027年4月1日以降は無効化される予定です。(Microsoft Learn)
したがって、今後の基本方針は次のように整理できます。
| 現在の利用状況 | 推奨される方針 | 理由 |
|---|---|---|
| 新規ワークロード | 原則としてAzure Managed Redisを検討する | Azure Cache for Redisの提供終了を前提に、将来の再移行を避けるため |
| 既存のBasic／Standard／Premium | 2026年中に棚卸しと移行検証を始める | 2028年まで猶予はあるが、アプリ改修・負荷試験・認証変更に時間がかかるため |
| 既存のEnterprise／Enterprise Flash | 優先度を上げて移行計画を作る | 提供終了が2027年3月31日で、猶予が短いため |
| 本番クリティカルなRedis | 先にセキュリティ是正、次に移行設計 | パブリック公開やキー認証依存を放置したまま移行するとリスクを持ち越すため |
Azure Managed RedisはRedis EnterpriseソフトウェアをベースにしたAzure上のマネージドサービスで、Microsoftが運用するサービスとして説明されています。単なる後継サービスというより、Azure Redis系サービスの中核がAzure Managed Redisへ移っていく流れとして読むべきです。(Microsoft Learn)
Microsoft Entra authenticationは「有効化すれば終わり」ではない
Redisのセキュリティで最も大きな転換点は、アクセスキー中心の認証からMicrosoft Entra authenticationへの移行です。Azure Managed RedisではMicrosoft Entra IDによるパスワードレス認証が提供され、新しいキャッシュ作成時にはMicrosoft Entra IDが既定で使われ、マネージドIDも有効になると説明されています。(Microsoft Learn)
ただし、実務では「Entra認証をオンにする」だけでは不十分です。次の点を事前に確認する必要があります。
| 確認項目 | 実務上の注意点 |
|---|---|
| クライアントライブラリ | Microsoft Entraトークンで接続できる実装に変更できるか |
| トークン更新 | 長時間接続でトークン期限切れ前に再認証できるか |
| マネージドID | アプリケーション実行基盤がマネージドIDを利用できるか |
| サービスプリンシパル | 非Azure環境やCI/CDから接続する場合の認証設計ができているか |
| アクセスキー無効化 | 無効化時に既存接続が切断されても、アプリが再接続できるか |
Microsoftのドキュメントでは、Azure Managed RedisのMicrosoft Entra認証はSSL接続のみでサポートされ、Microsoft Entraグループはサポートされないとされています。また、アクセスキーを無効化すると、アクセスキー認証かMicrosoft Entra認証かにかかわらず既存のクライアント接続が終了するため、再接続処理を用意する必要があります。(Microsoft Learn)
ここで失敗しやすいのは、インフラ側だけで認証方式を切り替えようとすることです。Redis接続はアプリケーションコード、ライブラリ、接続プール、再試行設定に強く依存します。Product ownerは「セキュリティ設定変更」ではなく「アプリケーション接続方式の変更」として扱うべきです。
まず確認すべきRedisセキュリティ項目
今回のAzure Resource Graphガイダンスを運用に落とし込むなら、最初に見るべき項目は次の5つです。
| 優先度 | 項目 | 望ましい状態 | 放置した場合のリスク |
|---|---|---|---|
| 高 | パブリックネットワークアクセス | 不要なら無効化し、Private Linkなどを検討 | インターネット到達可能な攻撃面が残る |
| 高 | 認証方式 | Microsoft Entra authenticationを優先 | 静的アクセスキーの漏えい・共有・ローテーション漏れ |
| 高 | アクセスキー認証 | Entra移行後に無効化を検討 | キーが残ることでIDベース統制が徹底されない |
| 中 | 最小TLSバージョン | TLS 1.2以上を基準にする | 古い暗号設定が残り、監査・コンプライアンス上の問題になる |
| 中 | Redisバージョン・SKU | サポート状況と移行先SKUを確認 | 機能差分や移行時の互換性問題に気づけない |
Microsoftのサンプルでも、TLS、パブリックネットワークアクセス、Microsoft Entra認証、キー認証状態が主要な確認対象になっています。特にMicrosoft Entra認証とキー認証の確認は、OSS Azure Cache for RedisのBasic／Standard／Premium向けのクエリとして示されており、Azure Managed Redisでは一部プロパティがAzure Resource Graphに露出していない点にも注意が必要です。(TECHCOMMUNITY.MICROSOFT.COM)
Azure Resource GraphでRedis構成を棚卸しするKQL例
次のKQLは、Redis関連リソースを一覧化し、運用判断に必要な項目をまとめて確認するための例です。Microsoftの公開サンプルをそのまま実行する前に、自社の命名規則、タグ、サブスクリプション構造に合わせて列を追加してください。
Resources
| where type in~ ("microsoft.cache/redis", "microsoft.cache/redisenterprise")
| extend skuName = coalesce(tostring(sku.name), tostring(properties.sku.name))
| extend redisVersion = tostring(properties.redisVersion)
| extend minimumTlsVersion = tostring(properties.minimumTlsVersion)
| extend publicNetworkAccess = tostring(properties.publicNetworkAccess)
| extend entraAuthEnabled = tostring(properties.redisConfiguration["aad-enabled"])
| extend keyBasedAuthDisabled = tostring(properties.disableAccessKeyAuthentication)
| project
subscriptionId,
resourceGroup,
name,
type,
location,
skuName,
redisVersion,
minimumTlsVersion,
publicNetworkAccess,
entraAuthEnabled,
keyBasedAuthDisabled
| order by subscriptionId asc, resourceGroup asc, name ascこのクエリの目的は、単に一覧を出すことではありません。出力結果をもとに、次のようにアクションへ変換します。
| 出力結果 | 次に取るべき行動 |
|---|---|
publicNetworkAccess が Enabled | 本当に公開が必要か確認し、不要ならPrivate Link中心の構成に変更する |
minimumTlsVersion が空または古い | 現行クライアントがTLS 1.2以上に対応しているか確認し、更新計画を作る |
entraAuthEnabled が false | アプリの接続方式を確認し、Microsoft Entra authenticationへの移行可否を検証する |
keyBasedAuthDisabled が false | Entra移行後にアクセスキー無効化のメンテナンス計画を作る |
| SKUやバージョンが古い | Azure Managed Redis移行時のSKUマッピング、性能試験、互換性確認に回す |
大規模環境では、Azure Resource Graphの取得上限にも注意が必要です。Resource Graphは既定でクエリ結果を1,000件に制限し、first の最大値も1,000です。大量のRedisや関連リソースを扱う場合は、ページング、CSV出力、Power BI連携などを前提に設計してください。(Microsoft Learn)
また、Azure Resource Graphは権限のあるリソースだけを返します。読み取り権限が不足しているサブスクリプションやリソースは結果に出ないため、「クエリに出てこない＝存在しない」と判断してはいけません。(Microsoft Learn)
ロードマップとしての運用方針
Azure Resource Graph、Azure Cache for Redis、Microsoft Entra authenticationを別々のテーマとして扱うと、対応が分断されます。2026年以降は、次のようなロードマップでまとめて進めるのが現実的です。
直近30日でやること
まずはRedis資産の棚卸しです。Azure Resource Graphで、全サブスクリプションのRedis関連リソースを抽出し、SKU、リージョン、所有者、環境、本番影響度、公開設定、認証方式を一覧化します。
この段階では、完璧な移行計画よりも「何がどこにあるか」を明確にすることが重要です。特に所有者不明のRedis、タグがないRedis、パブリックアクセスが有効なRedisは、早めに例外管理の対象にします。
30〜90日でやること
次に、セキュリティ姿勢の是正を進めます。優先順位は、パブリック公開、TLS、アクセスキー依存、Microsoft Entra authentication未対応の順で考えると判断しやすくなります。
ただし、アクセスキー無効化は既存接続を切断する可能性があるため、いきなり本番で実施しないでください。開発環境やステージング環境で、クライアントライブラリ、再接続、トークン更新、監視アラートを確認してから本番へ展開します。
2026年中にやること
2026年中には、Azure Managed Redisへの移行パターンを確立しておきたいところです。Microsoftの移行ドキュメントでは、Azure Cache for Redisから事前作成したAzure Managed Redisへ移行するツールがプレビューとして説明されており、移行後はアプリケーションの動作確認、旧Azure Cache for Redisの削除、Azure Managed Redisホスト名への更新が必要とされています。(Microsoft Learn)
ここでの成果物は、単なる手順書ではなく、次のような標準パターンです。
| 成果物 | 内容 |
|---|---|
| 移行判定シート | SKU、リージョン、クラスタリング、データ保持、ネットワーク要件を整理 |
| 接続方式テンプレート | Microsoft Entra authentication、マネージドID、サービスプリンシパルの使い分け |
| 性能試験シナリオ | レイテンシ、スループット、接続数、フェイルオーバー時の挙動 |
| ロールバック方針 | 移行中の接続断、データ差分、DNS・ホスト名更新への対応 |
| 例外管理 | すぐに移行できない理由、期限、責任者、代替リスク低減策 |
2027年以降に残してはいけないこと
2027年に入ってからEnterprise／Enterprise Flashの移行検証を始めるのは危険です。提供終了が2027年3月31日であるため、クリティカルな本番環境では、2026年中に移行先の技術検証と費用見積もりを完了させるべきです。Basic／Standard／Premiumは2028年まで猶予がありますが、数が多い組織ほど後半に作業が集中します。(Microsoft Learn)
Azure Managed Redis移行で見落としやすい差分
Azure Managed Redisは後継候補として有力ですが、既存のAzure Cache for Redisと完全に同じ前提で扱うと失敗します。Microsoftの移行差分では、Azure Managed Redisは既定でクラスタリングされること、仮想ネットワーク注入やIPベースのファイアウォール規則をサポートしないこと、Private Linkへの切り替えが必要になる場合があること、単一データベースのみをサポートすることなどが説明されています。(Microsoft Learn)
特に注意すべき差分は次の通りです。
| 差分 | 影響を受けるチーム | 確認ポイント |
|---|---|---|
| クラスタリングが既定 | アプリ開発、SRE | クライアントライブラリがクラスタ対応か、MOVED リダイレクトを扱えるか |
| 単一データベース | アプリ開発 | Redis DB番号で論理分離している場合、キーprefixなどに設計変更できるか |
| VNet injection非対応 | ネットワーク、セキュリティ | Private Link中心のネットワーク設計に切り替えられるか |
| Microsoft Entra ID RBACの差分 | IAM、セキュリティ | 既存の権限モデルをそのまま移せるか、個別ユーザー・サービスプリンシパル管理が必要か |
| TLS／非TLSの扱い | アプリ開発、基盤 | 接続モードを混在させていないか |
移行計画では、サービス名だけを置き換えるのではなく、アプリケーションアーキテクチャ、ネットワーク、認証、運用監視をまとめて確認してください。
Product ownerとIT decision-makerが決めるべきこと
技術チームだけに任せると、Redis対応は「クエリを実行して一覧を出す」段階で止まりがちです。意思決定者は、次の3つを明確にする必要があります。
新規構築の標準サービスを決める
新規プロジェクトでAzure Cache for Redisを使い続けると、将来の再設計リスクを抱えます。原則としてAzure Managed Redisを標準候補にし、Azure Cache for Redisを選ぶ場合は明確な例外理由を求めるべきです。
アクセスキーをいつまで許容するか決める
アクセスキー認証は簡単ですが、共有・漏えい・ローテーション漏れが起きやすい認証方式です。Microsoft Entra authenticationを標準にするなら、アクセスキーを「暫定的に許可するもの」として期限を設定します。
例外を認める場合も、次の情報を残してください。
| 例外管理項目 | 記録する内容 |
|---|---|
| 例外理由 | クライアントライブラリ未対応、移行期間中、外部システム制約など |
| 期限 | いつまでアクセスキーを許可するか |
| 責任者 | Product ownerまたはシステム責任者 |
| 補完策 | Key Vault管理、短いローテーション周期、ネットワーク制限など |
| 解消条件 | Entra対応ライブラリ導入、アプリ改修完了、移行完了など |
提供終了対応を予算とロードマップに入れる
Redisはアプリケーションの裏側にあるため、経営層や事業部から見えにくいサービスです。しかし、セッション、ランキング、キャッシュ、メッセージングなどに使われている場合、停止影響は大きくなります。
Azure Cache for Redisの提供終了対応は、単なるインフラ保守費ではなく、アプリケーション継続性、セキュリティ、クラウド標準化の投資として扱うべきです。
よくある失敗と回避策
Azure Resource Graphの結果だけで安全と判断する
Azure Resource Graphは強力ですが、万能の監査証跡ではありません。プロパティがResource Graphに露出していない場合や、権限不足で見えないリソースがある場合があります。MicrosoftのRedis向けガイダンスでも、Azure Managed Redisの一部プロパティはAzure Resource Graphに露出していない旨が注記されています。(TECHCOMMUNITY.MICROSOFT.COM)
回避策は、Azure Resource Graphを一次棚卸しに使い、重要システムについてはAzure Portal、Azure CLI、ポリシー、アプリケーション接続テストで確認することです。
Entra認証を有効化したのにアプリが対応していない
Microsoft Entra authenticationでは、クライアントがEntraトークンを取得し、Redis接続で使い、期限切れ前に更新する必要があります。過去にアクセスキーを前提としていたクライアントでは、接続ワークフローの変更が必要になる場合があります。(Microsoft Learn)
回避策は、本番Redisではなく検証用Redisで先に接続方式を確認することです。特に長時間接続、接続プール、再接続、トークン更新の挙動は必ずテストしてください。
移行を「期限直前の作業」として扱う
Azure Cache for Redisの提供終了日はまだ先に見えるかもしれません。しかし、実際の移行では、棚卸し、移行先SKU選定、ネットワーク設計、アプリ改修、性能試験、データ移行、運用監視の更新が必要です。Enterprise／Enterprise Flashは2027年3月31日が提供終了日であり、優先対応が必要です。(Microsoft Learn)
回避策は、すべてのRedisを同じ優先度で扱わないことです。本番影響度、公開状態、認証方式、提供終了日、移行難易度でスコアを付け、上位から着手します。
実務で使えるRedis対応スコアリング例
複数のRedisがある場合は、次のような簡易スコアで優先順位を決めると、部門間の合意形成がしやすくなります。
| 評価軸 | 条件 | 点数 |
|---|---|---|
| 提供終了の近さ | Enterprise／Enterprise Flash | 3 |
| 本番影響度 | ユーザー向け本番サービスで利用 | 3 |
| ネットワークリスク | パブリックアクセス有効 | 3 |
| 認証リスク | アクセスキー依存、Entra未対応 | 3 |
| 移行難易度 | 複数DB、クラスタ非対応クライアント、特殊コマンド利用 | 2 |
| 所有者不明 | タグや運用責任者が不明 | 2 |
合計点が高いRedisから、セキュリティ是正と移行検証を始めます。目安として、10点以上は早急に対応計画を作り、7〜9点は四半期内に検証、6点以下は標準移行計画に組み込むと管理しやすくなります。
今後の運用方針は「棚卸し、標準化、移行」の順で進める
今回のMicrosoftによるAzure Resource Graph guidanceは、Redisセキュリティレビューを効率化する実務的な更新です。ただし、本質はKQLの便利さだけではありません。Azure Redis運用全体が、次の方向へ進んでいることを示しています。
まず、Azure Resource Graphで全体を見える化します。次に、TLS、パブリックネットワーク、Microsoft Entra authentication、アクセスキー認証の状態をセキュリティ基準に照らして是正します。最後に、Azure Cache for Redisの提供終了スケジュールを踏まえ、Azure Managed Redisへの移行をロードマップに組み込みます。
次に取るべき行動は明確です。今月中にAzure Resource GraphでRedis資産を一覧化し、パブリック公開・アクセスキー依存・提供終了が近いSKUを特定してください。そのうえで、Microsoft Entra authentication対応の検証環境を作り、Azure Managed Redisへの移行パターンを1つ確立することが、2026年以降のRedis運用を安定させる最短ルートです。
コメント