2026年4月21日時点で、Azure Cache for Redis の管理者が最初にやるべきことは、Azure Resource Graph を使って Redis 構成を横断的に棚卸しし、TLS、Public Network Access、Microsoft Entra authentication、アクセスキー認証の状態を一覧化することです。Microsoft は Azure Resource Graph Explorer と KQL を使い、複数サブスクリプションにまたがる Redis 構成を短時間で確認する方法を示しました。対象は microsoft.cache/redis と microsoft.cache/redisenterprise で、SKU、Redis バージョン、TLS、公開ネットワーク、Microsoft Entra 認証、アクセスキー無効化の確認が中心です。(TECHCOMMUNITY.MICROSOFT.COM)
ただし、発表直後に本番環境の設定を一括変更するのは危険です。まず Azure Resource Graph で現状を見える化し、リスクの高い Redis インスタンスから順に、アプリ担当者への周知、検証環境での接続確認、保守時間帯での切り替えを進めるのが現実的です。特に Microsoft Entra authentication の有効化やアクセスキー認証の無効化は、既存接続への影響を伴うため、運用計画とセットで扱う必要があります。(Microsoft Learn)
Azure Resource Graph で Redis セキュリティ姿勢を確認する理由
Azure Cache for Redis のセキュリティレビューでは、これまで Azure CLI、PowerShell、REST API、ポータル確認を組み合わせることが多くありました。単一環境なら問題ありませんが、サブスクリプション、リージョン、環境区分、本番・検証・開発が増えると、確認漏れが起きやすくなります。
Azure Resource Graph は、Azure リソースを KQL で横断検索できる仕組みです。Microsoft のガイダンスでも、Azure Resource Graph Explorer を使うことで、スクリプト作成やモジュール導入を最小限にしながら、Redis 構成を複数サブスクリプション横断で確認できる点が強調されています。(TECHCOMMUNITY.MICROSOFT.COM)
管理者が見るべきポイントは、単に「Redis が存在するか」ではありません。次の状態を一枚の棚卸し表にまとめることが重要です。
| 確認項目 | 見るべき値 | 管理者の判断 |
|---|---|---|
| SKU | Basic、Standard、Premium、Enterprise など | 本番用途か、移行計画の対象かを分類する |
| Redis バージョン | properties.redisVersion | 古い構成や互換性確認が必要な環境を洗い出す |
| 最小 TLS バージョン | properties.minimumTlsVersion | TLS 1.2 以上を前提に、古いクライアント依存を確認する |
| Public Network Access | Enabled / Disabled | 公開エンドポイントが必要か、Private Endpoint 化できるかを判断する |
| Microsoft Entra authentication | aad-enabled | ID ベース認証へ移行済みか確認する |
| アクセスキー認証 | disableAccessKeyAuthentication | キー認証を残す理由があるか確認する |
まず実行する Azure Resource Graph クエリ
Azure Portal で「Resource Graph Explorer」を開き、対象サブスクリプションを選択してから以下の KQL を実行します。Azure Resource Graph を使うには、確認対象リソースに対する少なくとも読み取り権限が必要です。権限がないリソースは結果に表示されないため、全社棚卸しでは Reader 以上の権限範囲を事前に確認してください。(Microsoft Learn)
Redis インスタンスと SKU を一覧化する
最初は、全 Redis リソースの存在と SKU を把握します。ここで本番、検証、開発、所有チーム、アプリ名などのタグも確認できるようにしておくと、後続の周知が楽になります。
Resources
| where type in~ ("microsoft.cache/redis", "microsoft.cache/redisenterprise")
| extend skuName = coalesce(tostring(sku.name), tostring(properties.sku.name))
| project subscriptionId, resourceGroup, location, name, type, skuName, tags
| order by subscriptionId, resourceGroup, nameこのクエリの目的は、設定変更ではなく「対象範囲の確定」です。結果に出た Redis をすべて同じ優先度で扱うのではなく、業務影響が大きい本番系、外部公開の可能性がある環境、所有者タグがない環境を先にレビューします。
Redis バージョンを確認する
Redis バージョンは、アプリケーション互換性や移行計画に関わります。Microsoft のガイダンスでは、Redis バージョン確認は OSS Azure Cache for Redis、つまり Basic、Standard、Premium 向けの確認として扱われています。(TECHCOMMUNITY.MICROSOFT.COM)
Resources
| where type =~ "microsoft.cache/redis"
| project subscriptionId,
resourceGroup,
location,
name,
skuName = tostring(sku.name),
redisVersion = tostring(properties.redisVersion)
| order by redisVersion asc, subscriptionId, nameバージョンの結果だけで即時アップグレードを判断するのではなく、アプリケーション側の Redis クライアント、接続文字列、クラスタリング対応、保守時間帯を合わせて確認します。
最小 TLS バージョンを確認する
TLS は Redis の通信経路を保護するうえで基本です。Azure Cache for Redis の ARM スキーマでは minimumTlsVersion があり、接続に必要な TLS バージョンを指定するプロパティとして扱われています。(Microsoft Learn)
Resources
| where type in~ ("microsoft.cache/redis", "microsoft.cache/redisenterprise")
| project subscriptionId,
resourceGroup,
location,
name,
type,
minimumTlsVersion = tostring(properties.minimumTlsVersion)
| extend review =
case(
minimumTlsVersion in ("1.0", "1.1"), "要是正: TLS 1.2 以上へ移行を計画",
minimumTlsVersion == "1.2", "確認済み: TLS 1.2",
isempty(minimumTlsVersion), "要確認: 値が取得できない",
"確認"
)
| order by review, subscriptionId, nameTLS 1.0 や TLS 1.1 が残っている場合、先にクライアント側の対応を確認します。古いアプリケーション、古いランタイム、古い Redis クライアントライブラリでは、TLS 設定を変えた瞬間に接続できなくなる可能性があります。
Public Network Access を確認する
Public Network Access が Enabled の Redis は、構成上パブリックエンドポイント経由の接続を許可している可能性があります。Microsoft のガイダンスでは、Enabled はパブリックエンドポイントからアクセス可能、Disabled は Private Endpoint または仮想ネットワーク経由のアクセスとして整理されています。(TECHCOMMUNITY.MICROSOFT.COM)
Resources
| where type in~ ("microsoft.cache/redis", "microsoft.cache/redisenterprise")
| project subscriptionId,
resourceGroup,
location,
name,
type,
publicNetworkAccess = tostring(properties.publicNetworkAccess)
| extend exposureReview =
case(
publicNetworkAccess =~ "Enabled", "要確認: 公開経路あり",
publicNetworkAccess =~ "Disabled", "確認済み: 公開ネットワーク無効",
"要確認: 値が未取得または未設定"
)
| order by exposureReview, subscriptionId, nameEnabled が見つかった場合でも、すぐに無効化するのではなく、接続元、ファイアウォール規則、Private Endpoint の有無、DR 構成、運用監視ツールの接続方式を確認します。特にグローバル環境では、別リージョンや別会社管理の運用基盤が Redis に接続していることがあります。
Microsoft Entra authentication とアクセスキー認証を確認する
Microsoft Entra authentication の確認は、Basic、Standard、Premium の Azure Cache for Redis を中心に行います。Microsoft Learn では、Azure Cache for Redis の認証方式としてアクセスキーと Microsoft Entra を説明し、Microsoft Entra はパスワードレスな認証機構として位置付けられています。対象範囲は Basic、Standard、Premium で、Enterprise / Enterprise Flash では Azure Cache for Redis の Microsoft Entra authentication はサポートされません。(Microsoft Learn)
Resources
| where type =~ "microsoft.cache/redis"
| extend entraAuthEnabled = tostring(properties.redisConfiguration["aad-enabled"])
| extend accessKeyAuthDisabled = tostring(properties.disableAccessKeyAuthentication)
| project subscriptionId,
resourceGroup,
location,
name,
skuName = tostring(sku.name),
entraAuthEnabled,
accessKeyAuthDisabled
| extend authReview =
case(
entraAuthEnabled =~ "true" and accessKeyAuthDisabled =~ "true",
"確認済み: Entra 認証中心",
entraAuthEnabled =~ "true" and accessKeyAuthDisabled !~ "true",
"移行中: キー利用の残存確認が必要",
entraAuthEnabled !~ "true",
"要計画: Entra 認証未導入",
"要確認"
)
| order by authReview, subscriptionId, nameこの結果で重要なのは、entraAuthEnabled=true だけで満足しないことです。アクセスキー認証が残っていれば、古い接続文字列を使うアプリや運用ツールが引き続きキーで接続できる可能性があります。
導入・設定チェックリスト
以下は、Azure Resource Graph の確認結果を実際の運用アクションへ落とし込むためのチェックリストです。
| フェーズ | チェック項目 | 完了条件 |
|---|---|---|
| 棚卸し | 全サブスクリプションで Redis リソースを抽出したか | microsoft.cache/redis と microsoft.cache/redisenterprise の一覧がある |
| 所有者確認 | タグまたは CMDB でアプリ担当者を特定したか | 所有者不明の Redis が別リスト化されている |
| TLS | TLS 1.0 / 1.1 相当の構成がないか | 古い TLS がある場合、クライアント更新計画がある |
| ネットワーク | Public Network Access が必要な理由を確認したか | Enabled の Redis に業務上の根拠または是正計画がある |
| 認証 | Microsoft Entra authentication の利用可否を確認したか | Basic / Standard / Premium で導入対象が分類されている |
| アクセスキー | キー認証を無効化できるか確認したか | キー接続の残存がメトリックやアプリ確認で把握されている |
| 保守計画 | 接続断が許容できる時間帯を決めたか | アプリ担当、運用担当、セキュリティ担当で合意済み |
| ロールバック | 変更失敗時の戻し方を決めたか | 接続文字列、認証方式、監視アラートの復旧手順がある |
Microsoft Entra authentication を展開する順序
Microsoft Entra authentication は、セキュリティを強化する有効な選択肢ですが、設定だけを先行させるとアプリケーション接続で問題が起きます。Microsoft Learn では、Microsoft Entra authentication を有効化するとキャッシュノードが新しい構成を読み込むために再起動されること、操作は保守時間帯またはピーク外で行うことが推奨されています。(Microsoft Learn)
おすすめの展開順序は次の通りです。
| 順序 | 作業 | 失敗しやすいポイント |
| -: | ——————————————- | ————————– |
| 1 | 対象 Redis を ARG で抽出する | 権限不足で一部サブスクリプションが見えていない |
| 2 | アプリ担当者に接続方式を確認する | 古いアクセスキー接続がドキュメント化されていない |
| 3 | 検証環境で Microsoft Entra authentication を有効化する | クライアントがトークン更新に対応していない |
| 4 | Redis User、マネージド ID、サービスプリンシパルを整理する | 個人ユーザーで本番接続してしまう |
| 5 | メトリックで Entra トークン接続の比率を確認する | 一部のバッチ、監視、管理ツールだけキー接続のまま残る |
| 6 | 保守時間帯にアクセスキー認証を無効化する | 既存接続が切断される影響を周知していない |
| 7 | 変更後の接続、監視、アラートを確認する | アプリは動くが運用監視だけ失敗する |
特に重要なのは、アクセスキー認証を無効化する前の確認です。Microsoft Learn では、Microsoft Entra authentication が有効で、少なくとも 1 つの Redis User が構成されていること、全アプリが Microsoft Entra authentication に切り替わっていること、Connected Clients と Connected Clients Using Microsoft Entra Token の値が一致していることを確認するよう案内しています。値が一致しない場合、アクセスキーで作成された接続がまだ残っていることを意味します。(Microsoft Learn)
アクセスキー認証を無効化する前に必ず周知すること
アクセスキー認証の無効化は、単なるセキュリティ設定変更ではありません。Microsoft Learn では、アクセスキー認証を無効化すると、アクセスキー利用か Microsoft Entra 利用かにかかわらず、既存のクライアント接続が終了すると説明されています。再接続のためのリトライ実装も必要です。(Microsoft Learn)
周知文では、以下を明確にします。
| 周知項目 | 伝える内容 |
|---|---|
| 変更理由 | Redis の認証をアクセスキー中心から Microsoft Entra authentication 中心へ移行する |
| 影響 | 変更時に既存接続が切断される可能性がある |
| 対象 | 対象 Redis 名、サブスクリプション、リソースグループ、リージョン |
| アプリ側作業 | 接続ライブラリ、マネージド ID、サービスプリンシパル、トークン更新処理の確認 |
| 運用側作業 | 監視ツール、ジョブ、手動運用スクリプトの接続方式確認 |
| 実施時間 | ピーク外または承認済みの保守時間帯 |
| 判断基準 | Entra トークン接続メトリックが全接続と一致すること |
| 戻し方 | 失敗時の接続方式、連絡先、切り戻し判断者 |
周知文の例は次のようにします。
件名: Azure Cache for Redis 認証方式変更に伴う接続確認のお願い
対象の Azure Cache for Redis について、Microsoft Entra authentication への移行状況を確認します。
アクセスキー認証の無効化を予定しているため、対象 Redis に接続するアプリケーション、バッチ、監視ツール、運用スクリプトが Microsoft Entra authentication に対応しているか確認してください。
確認してほしい内容:
- アクセスキーを含む接続文字列を使用していないか
- マネージド ID またはサービスプリンシパルで接続できるか
- Redis クライアントが Microsoft Entra トークンの更新に対応しているか
- 接続断時にリトライできるか
- 監視・ジョブ・手動スクリプトに古い接続情報が残っていないか
変更時は既存接続が切断される可能性があります。
影響がある場合は、実施予定日までに運用担当へ連絡してください。ネットワーク設定の見直しは「Public Network Access の有無」だけで終わらせない
Public Network Access が Enabled の Redis は優先的にレビューすべきです。ただし、Disabled であれば完全に安全という意味ではありません。Private Endpoint、DNS、接続元ネットワーク、監視経路、バックアップ・エクスポート先、運用端末の経路まで含めて確認する必要があります。
Azure Cache for Redis の作成・設定画面では、ネットワーク方式として Private Endpoint が推奨されています。また、Microsoft Learn では Microsoft Entra ID とマネージド ID を使った認可が共有アクセスキーより安全で扱いやすいと説明されています。(Microsoft Learn)
実務では、次のように判断します。
| 状態 | 判断 | 次のアクション |
|---|---|---|
| Public Network Access が Enabled | 要レビュー | 接続元、Firewall、Private Endpoint 移行可否を確認 |
| Public Network Access が Disabled | 基本方針として望ましい | Private DNS、監視経路、運用端末の接続確認 |
| 値が取得できない | ARG だけで判断しない | Azure Portal、CLI、テンプレート、リソース定義で再確認 |
| 本番なのに所有者タグがない | 高リスク | アプリ責任者を特定し、変更承認ルートを作る |
Azure Resource Graph の結果を過信しない
Azure Resource Graph はセキュリティレビューの入り口として非常に便利ですが、最終判断のすべてを任せるべきではありません。Microsoft Learn では、Azure Resource Graph は Azure Resource Manager の更新通知や定期的なフルスキャンでデータを更新し、各リソースプロバイダーの最新の非プレビュー API を使ってプロパティを収集すると説明されています。一方で、期待するプロパティが利用できない場合があることも示されています。(Microsoft Learn)
そのため、ARG の結果は「一次スクリーニング」として使い、変更前には Azure Portal、Azure CLI、ARM/Bicep テンプレート、アプリ接続ログ、監視メトリックで確認します。特に 値が空、未取得、想定外の値 が出た場合は、セキュリティ違反と即断せず、リソース種別や API 露出の違いを確認してください。
Azure Cache for Redis の提供終了も計画に入れる
Redis セキュリティ姿勢レビューは、単発の設定確認で終わらせるべきではありません。Azure Cache for Redis には提供終了スケジュールがあり、Basic、Standard、Premium は 2028年9月30日に廃止、Enterprise / Enterprise Flash は 2027年3月31日に廃止予定です。Microsoft は、既存の Azure Cache for Redis インスタンスを Azure Managed Redis へアップグレードすることを推奨しています。(Microsoft Learn)
つまり、今回の Azure Resource Graph レビューでは、次の2つを同時に整理すると効率的です。
| 観点 | 今すぐ見ること | 中長期で見ること |
|---|---|---|
| セキュリティ | TLS、Public Network Access、Entra 認証、アクセスキー | 継続監査、例外管理、標準構成化 |
| 移行 | SKU、Redis バージョン、ネットワーク、認証方式 | Azure Managed Redis への移行可否、アプリ改修、期限管理 |
| 運用 | 所有者、保守枠、監視、接続方式 | グローバル展開、標準手順、変更承認フロー |
Azure Managed Redis への移行を検討する場合は、クラスタリング、ネットワーク分離、Microsoft Entra ID、TLS、データベース数などの違いも確認が必要です。たとえば Azure Managed Redis は既定でクラスタリングされるため、非クラスタ構成の Basic / Standard から移る場合、Redis クライアント側の対応が必要になることがあります。(Microsoft Learn)
管理者向けの最終チェックリスト
公開直後の対応としては、以下の順に進めると失敗しにくくなります。
| 優先度 | チェック | 実施内容 |
|---|---|---|
| 高 | Redis 棚卸し | ARG で全 Redis を抽出し、所有者、環境、SKU、リージョンを整理する |
| 高 | 公開経路 | Public Network Access が Enabled の Redis を優先レビューする |
| 高 | 認証 | Microsoft Entra authentication とアクセスキー認証の状態を確認する |
| 高 | 変更影響 | Entra 有効化、キー無効化、TLS 変更時の接続影響を確認する |
| 中 | TLS | 最小 TLS バージョンと古いクライアント依存を洗い出す |
| 中 | Redis バージョン | 古い構成、互換性、移行計画の要否を整理する |
| 中 | 周知 | アプリ、運用、セキュリティ、グローバル拠点へ変更内容を伝える |
| 中 | 移行計画 | Azure Managed Redis への移行期限と技術差分を確認する |
| 低 | 継続運用 | ARG クエリを定期レビュー手順に組み込む |
まとめ: まず棚卸し、次に周知、最後に段階展開
Azure Resource Graph を使った Redis セキュリティ姿勢レビューの価値は、複数サブスクリプションに散らばった Azure Cache for Redis の状態を短時間で可視化できる点にあります。特に TLS、Public Network Access、Microsoft Entra authentication、アクセスキー認証は、セキュリティリスクと運用影響の両方に直結します。
次に取るべき行動は明確です。まず本記事の KQL で Redis 一覧を作成し、Public Network Access = Enabled、Microsoft Entra authentication 未導入、アクセスキー認証が有効、TLS が古い Redis を抽出します。その後、アプリ担当者へ接続方式の確認を依頼し、検証環境で Microsoft Entra authentication とアクセスキー無効化の影響を確認します。本番反映は、必ず保守時間帯、メトリック確認、ロールバック手順、関係者周知をそろえてから実施してください。
コメント