2026年4月21日に Microsoft が公開した Azure Resource Graph の Redis 向けガイダンスを、安全対策の文脈で読むなら、先に着手すべきなのは3つです。公開経路の遮断、アクセスキー依存の廃止、監査証跡の整備です。今回の更新の価値は、Azure Resource Graph で Redis の設定を横断的に洗い出し、どのサブスクリプションのどのキャッシュが危ないかを短時間で優先順位付けできるようになったことにあります。実務では、ARG を棚卸しに使い、その結果を Azure Policy と Azure Monitor に接続して強制・監査まで回すのが最も事故を減らしやすい運用です。 (TECHCOMMUNITY.MICROSOFT.COM)
しかも、いまの Redis セキュリティレビューは単なる設定点検では終わりません。Azure Cache for Redis の全 SKU には提供終了タイムラインがあり、Enterprise / Enterprise Flash は 2027年3月31日、Basic / Standard / Premium は 2028年9月30日に提供終了予定です。さらに、Azure Cache for Redis Enterprise では Microsoft Entra 認証が使えず、Azure Managed Redis では Entra ID が既定で有効です。つまり、どの環境を先に移行すべきかまで含めて判断しないと、セキュリティ改善が中途半端になります。 (Microsoft Learn)
2026年4月21日の更新をどう読むべきか
Microsoft の Azure PaaS Blog で公開されたのは、Azure Resource Graph Explorer から microsoft.cache/redis と microsoft.cache/redisenterprise を横断し、SKU、Redis バージョン、最小 TLS、パブリック ネットワーク公開、Microsoft Entra 認証、アクセスキー無効化状態を KQL で確認する方法です。個別に PowerShell や CLI スクリプトを作る代わりに、ポータル上の KQL で複数サブスクリプションを一気に見る、という運用に切り替えやすくなりました。 (TECHCOMMUNITY.MICROSOFT.COM)
Azure Resource Graph 自体も、Kusto Query Language ベースで Azure Resource Manager のリソース プロパティを大規模に探索でき、ポリシー適用の影響評価に向くことが公式に示されています。今回の更新が刺さるのは、まさに「変更を入れる前に、影響範囲を先に知りたい」というセキュリティ チームの検索意図に合っているからです。 (Microsoft Learn)
ただし、ここで誤解しやすいのは、ARG はあくまでコントロールプレーンの設定棚卸しだという点です。実際の接続、認証失敗、切断イベントといった運用監査は Diagnostic settings 側で取る必要があります。さらに、Microsoft のブログでも、Azure Managed Redis の認証関連プロパティは ARG に同じ形では出てこないと明記されています。ARG の結果だけで「認証まで安全」と結論付けるのは早すぎます。 (TECHCOMMUNITY.MICROSOFT.COM)
どのサービスを先に直すべきか
| 対象 | Microsoft Entra 認証 | ARG で見やすい点 | いちばん重要な次の一手 |
|---|---|---|---|
| Azure Cache for Redis Basic / Standard / Premium | 対応 | publicNetworkAccess、minimumTlsVersion、aad-enabled、disableAccessKeyAuthentication、Redis バージョン | 公開経路を閉じ、Entra 認証へ切り替え、アクセスキーを無効化する |
| Azure Cache for Redis Enterprise / Enterprise Flash | 非対応 | TLS や一部ネットワーク設定の棚卸し | Private Link と監査を整えつつ、Azure Managed Redis への移行を前倒しする |
| Azure Managed Redis | 既定で対応 | SKU や一部ネットワーク/TLS は把握しやすいが、認証状態は ARG だけでは完結しにくい | publicNetworkAccess 無効化、アクセスキー無効化、接続ログと復旧設計を整える |
表の整理は、Microsoft の公開した ARG ガイダンス、Entra 認証のサポート範囲、提供終了 FAQ、Azure Managed Redis のセキュリティ ガイドを踏まえた実務向けの判断基準です。 (TECHCOMMUNITY.MICROSOFT.COM)
優先度1: 公開面を閉じる
Redis で最優先なのは、インターネットから到達できる経路を残さないことです。Azure Cache for Redis でも Azure Managed Redis でも、ネットワーク層の推奨は Private Endpoint です。特に見落としやすいのが、Private Endpoint を作っただけでは十分でないケースです。Azure Cache for Redis の Private Link ドキュメントでは、publicNetworkAccess が Enabled だと パブリックとプライベートの両方から到達でき、Disabled にして初めてプライベート専用になると明記されています。Azure Managed Redis のセキュリティ ガイドでも、Private Endpoint を使うなら publicNetworkAccess を無効化するのが最も安全とされています。 (Microsoft Learn)
ここで注意したいのは、microsoft.cache/redisenterprise を一括で見ると、旧 Enterprise / Enterprise Flash と Azure Managed Redis を同じ列で読んでしまいやすいことです。旧 Enterprise / Enterprise Flash では publicNetworkAccess フラグ自体がサポートされません。一方、Azure Managed Redis では無効化が推奨です。つまり、redisenterprise 系の ARG 結果で PublicNetworkAccess が空でも、それを安全判定に使ってはいけません。旧 Enterprise 系は Private Link と移行計画を別で確認する必要があります。 (TECHCOMMUNITY.MICROSOFT.COM)
運用としては、まず ARG で公開面の洗い出しをし、その後 Azure Policy を Audit → Deny / Modify の順で強化するのが堅実です。Azure Cache for Redis には、Azure Cache for Redis should disable public network access、Azure Cache for Redis should use private link、Configure Azure Cache for Redis to disable public network access といった組み込みポリシーが用意されています。影響範囲の把握に ARG、強制に Policy という役割分担がきれいです。 (Microsoft Learn)
優先度2: アクセスキーから Microsoft Entra 認証へ寄せる
Azure Cache for Redis では、認証方式は アクセスキー と Microsoft Entra の2つです。Microsoft は Entra を「より安全な接続方法」と位置付けており、Basic / Standard / Premium では ACL ベースのデータアクセス ポリシーも使えます。組み込みポリシーは Data Owner、Data Contributor、Data Reader の3つで、要件が合わなければカスタム ポリシーも作成できます。逆に、Enterprise / Enterprise Flash では Entra 認証もカスタム データアクセス ポリシーもサポートされません。さらに Redis バージョン 4 のキャッシュでは ACL とデータアクセス ポリシーが使えません。 (Microsoft Learn)
実務での切り替え順は、次の順番が安全です。
- Microsoft Entra 認証を有効化する。
- 最低1つの Redis User を追加し、必要最小限のデータアクセス ポリシーを割り当てる。
- アプリケーションをトークンベース認証へ切り替える。
Connected ClientsとConnected Clients using Microsoft Entra Tokenの値がそろうことを確認する。- その後でアクセスキーを無効化する。 (Microsoft Learn)
この順番を守る理由は明確です。Entra 有効化やアクセスキー無効化の変更では、ノード再起動や接続切断が発生し得ます。公式ドキュメントでは、Entra の有効化後にノードが再起動し、処理に 最大30分かかること、アクセスキー無効化時には アクセスキー接続も Entra 接続も含めて既存接続が切断されることが案内されています。geo レプリケーション構成では、unlink → disable keys → relink の手順も必要です。さらに、Microsoft Entra グループはサポートされないため、ユーザー、サービス プリンシパル、マネージド ID を明示的に登録する前提で設計する必要があります。 (Microsoft Learn)
Azure Managed Redis では、Microsoft Entra ID が既定で使われ、キャッシュ作成時にマネージド ID も有効になります。ここでもアクセスキーは残せますが、推奨は Entra ベースです。運用面では、トークン期限切れ前に再 AUTH できるクライアントであることが重要で、Microsoft は少なくとも 有効期限の3分前までに新しいトークンを送り、AUTH のタイミングにジッターを入れて集中を避けるよう勧めています。 (Microsoft Learn)
優先度3: TLS と非SSLポートは、互換性より先に解消する
今回の ARG ガイダンスでも、minimumTlsVersion の確認は独立した重要項目です。Microsoft はブログ内で TLS 1.2 以上を推奨しており、Azure Cache for Redis では TLS 1.0 / 1.1 のサポート終了が 2024年10月1日から進んでいます。さらに、Azure Policy には 非SSLポートの無効化とセキュア接続のみ許可を促す組み込み定義があります。ARM / Bicep のスキーマ上は enableNonSslPort や minimumTlsVersion がまだ見えるため、古い構成が IaC に残っていないかまで確認したほうが安全です。 (TECHCOMMUNITY.MICROSOFT.COM)
Azure Managed Redis は既定で TLS 1.2 または 1.3 を使い、非TLSアクセスを無効にした状態が推奨です。ここに例外を作ると、Entra 認証や監査の設計も崩れやすくなります。6379 や旧TLSを必要とするクライアントは「例外」ではなく「移行負債」として扱うのが実務的です。 (Microsoft Learn)
優先度4: 監査と検知を、サービス別に設計する
ARG で設定を見つけても、誰が接続したか、認証が失敗したか、いつ設定が変わったかは別の仕組みで取らなければ意味がありません。Azure Cache for Redis の Diagnostic settings では接続ログとメトリックを送れますが、Basic / Standard / Premium の接続ログは 10秒間隔のスナップショット型で、成功・失敗を含む認証イベントや切断イベントは記録しません。ここを SIEM の真実のソースだと思い込むと、見落としが出ます。 (Microsoft Learn)
その代わり、Azure Cache for Redis には MSEntraAuthenticationAuditLog というログ カテゴリがあり、Log Analytics の ACREntraAuthenticationAuditLog テーブルで Microsoft Entra 認証監査イベントを扱えます。さらにメトリック側には ConnectedClientsUsingAADToken があり、Errors には MicrosoftEntraAuthenticationFailure や MicrosoftEntraTokenExpired といった観点もあります。Entra 切り替え後は、接続総数、Entra 接続数、Entra 認証失敗、トークン期限切れをまとめてアラート対象にするのが実用的です。 (Microsoft Learn)
一方、Enterprise / Enterprise Flash や Azure Managed Redis では、接続ログが イベントベースで、接続・切断・認証イベント、失敗した認証イベントまで含めて記録できます。こちらは監査証跡としてかなり使いやすい反面、Diagnostic settings の流入開始まで 最大90分かかる点は要注意です。設定直後にログが見えないからといって、未動作とは限りません。 (Microsoft Learn)
ガバナンス面では、Azure Cache for Redis に対して Log Analytics / Event Hub / Storage へのログ出力を自動化する Policy が組み込みで用意されています。Azure Managed Redis 側でも、Microsoft は Azure Policy、Activity log、Azure Monitor アラート、Diagnostic settings の併用を推奨しています。監査証跡は「あとで入れる」のではなく、Entra 切り替え前に必ず先回りして入れておくべきです。 (Microsoft Learn)
監査と同じくらい忘れやすいのが復旧設計です。Azure Managed Redis では、Persistence は障害時の回復には役立ちますが バックアップや PITR ではありません。壊れたデータが書かれれば、それも永続化されます。真のバックアップ用途は Export を使うべきで、さらに Active Geo-Replication と Persistence は両立しないため、単一リージョンの耐久性を取るのか、クロスリージョンの継続性を取るのかを先に決めておく必要があります。 (Microsoft Learn)
優先度5: 提供終了対応を「更改」ではなく「安全対策」として扱う
Azure Cache for Redis の Basic / Standard / Premium は 2028年9月30日、Enterprise / Enterprise Flash は 2027年3月31日に提供終了です。Microsoft はどちらについても、期限を待たず 今すぐ Azure Managed Redis へアップグレードすることを推奨しています。これはコストや機能の話だけでなく、Entra 認証を前提にした設計へ寄せられるというセキュリティ上の意味が大きいからです。 (Microsoft Learn)
実務上の優先順位は、次の考え方で十分です。旧 Enterprise / Enterprise Flash を最優先、次に 公開経路やアクセスキーが残っている Basic / Standard / Premium、その次に Redis 4 など最小権限化が進めにくい OSS キャッシュです。既にプライベート接続・Entra・監査が整っている OSS キャッシュは、期限を見ながら計画移行に回せます。 (Microsoft Learn)
すぐ使える Azure Resource Graph クエリ
以下は、Microsoft のブログで示された確認軸を、優先順位付けしやすい形にまとめた実務向けの例です。ARG はディレクトリ、管理グループ、サブスクリプションにスコープを切り替えられるので、まずは管理グループ単位で走らせるのが効率的です。 (Microsoft Learn)
Azure Cache for Redis（Basic / Standard / Premium）の危険度をざっと並べる
Resources
| where type =~ "microsoft.cache/redis"
| extend MinimumTLS = tostring(properties.minimumTlsVersion),
PublicNetworkAccess = tostring(properties.publicNetworkAccess),
EntraAuthEnabled = tostring(properties.redisConfiguration["aad-enabled"]),
KeyBasedAuthDisabled = tostring(properties.disableAccessKeyAuthentication),
NonSslPortEnabled = tostring(properties.enableNonSslPort)
| extend RiskScore =
iff(PublicNetworkAccess =~ "Enabled", 40, 0) +
iff(KeyBasedAuthDisabled =~ "false", 25, 0) +
iff(EntraAuthEnabled =~ "false", 20, 0) +
iff(NonSslPortEnabled =~ "true", 10, 0) +
iff(MinimumTLS !~ "1.2", 5, 0)
| project subscriptionId, resourceGroup, name, location,
MinimumTLS, PublicNetworkAccess, EntraAuthEnabled,
KeyBasedAuthDisabled, NonSslPortEnabled, RiskScore
| order by RiskScore descこのクエリで上位に出るものは、公開面・静的資格情報・旧接続方式が同時に残っている可能性が高いキャッシュです。公式ブログの公開経路、Entra、有効なアクセスキー、TLS の観点を、優先順位付け向けに1本へまとめています。 (TECHCOMMUNITY.MICROSOFT.COM)
redisenterprise 系は、まずサービス種別を分けて見る
Resources
| where type =~ "microsoft.cache/redisenterprise"
| extend SKU = coalesce(tostring(sku.name), tostring(properties.sku.name)),
MinimumTLS = tostring(properties.minimumTlsVersion),
PublicNetworkAccess = tostring(properties.publicNetworkAccess)
| project subscriptionId, resourceGroup, name, location, SKU, MinimumTLS, PublicNetworkAccess
| order by SKU asc, name ascこの結果は有用ですが、PublicNetworkAccess をそのまま安全判定に使わないでください。旧 Enterprise / Enterprise Flash ではこのフラグがサポートされず、Azure Managed Redis では無効化が推奨されます。空値は「安全」ではなく「別確認が必要」です。 (TECHCOMMUNITY.MICROSOFT.COM)
Redis 4 系を先に見つける
Resources
| where type =~ "microsoft.cache/redis"
| project subscriptionId, resourceGroup, name, RedisVersion=tostring(properties.redisVersion)
| where RedisVersion startswith "4"Redis 4 系の Azure Cache for Redis では ACL とデータアクセス ポリシーが使えないため、最小権限化の実装が詰まりやすくなります。公開経路やキー依存が残っていなくても、移行またはアップグレードの優先度は高めです。 (TECHCOMMUNITY.MICROSOFT.COM)
失敗しやすいポイント
| 失敗しやすいポイント | なぜ起きるか | 実務での回避策 |
|---|---|---|
| Private Endpoint を作っただけで安心する | publicNetworkAccess が残ると、公開経路も生きたままになり得る | supported SKU では publicNetworkAccess=Disabled を明示確認する |
| ARG の結果が空だったので安全だと判断する | スコープ不足や RBAC 不足、プロパティ未露出の可能性がある | 管理グループ/ディレクトリ スコープで再実行し、クエリ実行主体の read 権限を確認する |
| Entra 有効化直後にアクセスキーを切る | 既存接続が落ち、クライアント実装が追従できない | Entra 接続数メトリックを確認してから切る。メンテナンス時間帯で実施する |
| Entra グループでまとめて付与しようとする | Redis 側では Entra グループ非対応 | ユーザー、サービス プリンシパル、マネージド ID を明示的に登録する |
| ログがすぐ流れないので設定失敗と誤解する | Diagnostic settings は流入まで時間がかかる | 最大90分の遅延を見込み、切り替え判定を急がない |
| 旧 Enterprise / Enterprise Flash でも後から Entra を有効化できると思う | その SKU では Entra 認証非対応 | そこに設計努力を投じず、Azure Managed Redis 移行を優先する |
表の内容は、Resource Graph の権限仕様、Entra 認証ドキュメント、Private Link の挙動、Diagnostic settings の制約を踏まえた現場向けの注意点です。 (Microsoft Learn)
まず30日でやること
最初の7日
管理グループまたはディレクトリ スコープで ARG を流し、サービス種別を3つに分けることから始めます。
- Azure Cache for Redis Basic / Standard / Premium
- Azure Cache for Redis Enterprise / Enterprise Flash
- Azure Managed Redis
この時点で、publicNetworkAccess、アクセスキー無効化、Entra 有効化、Redis バージョン、最小 TLS を一覧化し、「今週閉じる穴」と「移行が必要な穴」を分けます。 (Microsoft Learn)
2週目
公開面と旧TLSの是正に集中します。Private Endpoint 未導入、publicNetworkAccess=Enabled、非SSLポート有効のキャッシュを優先して閉じ、Azure Policy はまず Audit で当てます。ここでログ出力先も先に決め、Log Analytics か Event Hub へ診断を流せる状態にしておきます。 (Microsoft Learn)
3週目
Basic / Standard / Premium で Entra 切り替えを開始します。Redis User とデータアクセス ポリシーを作り、アプリをトークンベース認証へ切り替え、Entra 接続メトリックを確認します。AMR では Redis users の最小権限化、アクセスキー無効化、接続ログ有効化まで進めます。 (Microsoft Learn)
4週目
旧 Enterprise / Enterprise Flash は、セキュリティ改善の継続先を Azure Managed Redis に切り替えます。Entra 非対応のまま残すより、移行設計に工数を投じたほうが効果が高いからです。あわせて、規制要件が強い環境では、Enterprise / AMR での CMK と resource locks も次段階の統制として検討すると、監査対応がしやすくなります。 (Microsoft Learn)
今回の更新で本当に重要なのは、KQL のサンプルそのものではありません。Redis セキュリティレビューを、棚卸し → 優先順位付け → 強制 → 監査 → 移行の流れに変えやすくなったことです。最初の一手は、ARG で publicNetworkAccess、アクセスキー、TLS、Redis バージョンを横断的に出し、OSS キャッシュは Entra へ、旧 Enterprise / Enterprise Flash は Azure Managed Redis へ、というふうに行き先を分けることです。これが、いま最も効果の大きい Redis のリスク低減策です。 (TECHCOMMUNITY.MICROSOFT.COM)
コメント