Azure Cache for Redis のセキュリティ監査は、PowerShell や Azure CLI のスクリプトを組む前に、Azure Resource Graph Explorer で横断的に始めるのが最短です。2026年4月21日時点で、Microsoft は Azure Resource Graph を使って Redis の SKU、バージョン、TLS、Microsoft Entra 認証、アクセスキー認証、パブリック公開状態を確認するガイダンスを公開しています。複数サブスクリプションを持つ企業なら、まず KQL で一覧化し、危険度の高い Redis から修正計画に落とし込むのが現実的です。(TECHCOMMUNITY.MICROSOFT.COM)
この記事では、Azure Resource Graph を使った Redis セキュリティ監査の進め方を、Azure 管理者、クラウドセキュリティ担当、コンプライアンス担当者向けに整理します。ゴールは「スクリプトなしで全体像を把握し、TLS 1.2 未満、Microsoft Entra 認証未設定、アクセスキー有効、パブリック公開といったリスクをすぐに洗い出すこと」です。
Azure Resource GraphでRedis監査を行うメリット
Azure Resource Graph は、Azure リソースを Kusto Query Language、つまり KQL で検索・集計できるサービスです。Microsoft Learn では、複数サブスクリプションにまたがるリソースを効率よく探索し、リソースプロパティでフィルター、グループ化、並べ替えできるサービスとして説明されています。(Microsoft Learn)
Redis 監査で特に大きいメリットは、各 Redis インスタンスに対して個別に API 呼び出しを行わなくても、Azure Resource Graph Explorer から構成情報をまとめて確認できる点です。Microsoft の Redis 向けガイダンスでも、従来は PowerShell、Azure CLI、REST API で行っていた確認を、Azure Resource Graph Explorer と KQL でより速くスケーラブルに実行できると説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
ただし、Azure Resource Graph は「修正ツール」ではなく「可視化・監査ツール」です。設定変更は Azure portal、Azure Policy、IaC、CLI、PowerShell などで別途行います。まず ARG で発見し、CSV やチケットに落とし込み、所有チームに修正してもらう流れが実務では扱いやすいです。
まず監査すべきRedisセキュリティ項目
Redis のセキュリティ監査では、すべてを一度に深掘りするより、攻撃面と認証方式に直結する項目から確認します。特に優先度が高いのは、TLS、非TLSポート、パブリックネットワークアクセス、Microsoft Entra 認証、アクセスキー認証です。
| 監査項目 | ARGで見る主なプロパティ | リスクの目安 | 次の対応 |
|---|---|---|---|
| TLS最小バージョン | properties.minimumTlsVersion | 1.0、1.1、空欄 | TLS 1.2 以上を基準に見直す |
| 非TLSポート | properties.enableNonSslPort | true | 非TLS接続が必要な例外を確認し、原則無効化 |
| パブリック公開 | properties.publicNetworkAccess | Enabled | Private Endpoint、VNet、Firewall 条件を確認 |
| Microsoft Entra認証 | properties.redisConfiguration["aad-enabled"] | false、空欄 | アプリの対応状況を見て Entra 認証へ移行 |
| アクセスキー認証 | properties.disableAccessKeyAuthentication | false | Microsoft Entra 認証へ移行後、アクセスキー無効化を検討 |
| SKU・リソース種別 | sku.name、properties.sku.name、type | 古いSKU、移行対象、例外運用 | 移行・標準化の対象に分類 |
| Redisバージョン | properties.redisVersion | 旧バージョン、空欄 | サポート状況と移行計画を確認 |
Azure Cache for Redis の ARM テンプレート参照では、minimumTlsVersion、enableNonSslPort、publicNetworkAccess、disableAccessKeyAuthentication、redisConfiguration などのプロパティが定義されています。publicNetworkAccess は Enabled または Disabled を取り、Disabled の場合はプライベートエンドポイントなどが排他的なアクセス方法になります。(Microsoft Learn)
Microsoft の Redis 向け ARG ガイダンスでは、監査対象のリソースタイプとして microsoft.cache/redis と microsoft.cache/redisenterprise が示されています。一方、Microsoft Entra 認証とアクセスキー無効化の確認クエリは、Basic、Standard、Premium などの OSS Azure Cache for Redis 向けであり、Azure Managed Redis では同じプロパティが ARG に露出しない場合があると説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
監査前に確認する前提条件
Azure Resource Graph の結果は、実行ユーザーが読み取り権限を持つリソースに限られます。Microsoft Learn でも、クエリ対象の Azure オブジェクトまたはオブジェクトグループに少なくとも read 権限がない場合、結果は返らないと説明されています。(Microsoft Learn)
大規模環境では、次の前提を先にそろえておくと失敗しにくくなります。
| 確認事項 | 実務でのポイント |
|---|---|
| スコープ | 管理グループ、ディレクトリ、サブスクリプション単位で対象範囲を決める |
| 権限 | セキュリティ監査用の閲覧ロールを用意し、対象サブスクリプションに付与する |
| 結果の扱い | CSV 出力後に、所有チーム、環境、重要度、期限を付ける |
| 値が空欄の扱い | 「安全」ではなく「ARGで未取得」または「対象外」として確認する |
| 直近変更の扱い | 変更直後のリソースは、ポータルや ARM 取得結果でも確認する |
Azure Resource Graph は更新通知と定期的なフルスキャンによってデータを最新化しますが、使用する API やリソースプロバイダーによって期待するプロパティが取得できない場合があります。そのため、空欄や想定外の値は「安全」と断定せず、Azure portal や対象サービスの設定画面で再確認するのが安全です。(Microsoft Learn)
Azure Resource Graph ExplorerでRedis設定を確認する手順
Azure portal から実行する場合、作業はシンプルです。Microsoft Learn のクイックスタートでは、Azure portal で Resource Graph Explorer を検索し、スコープを選択してクエリを実行する流れが説明されています。(Microsoft Learn)
| 手順 | 操作 |
|---|---|
| 1 | Azure portal にサインインする |
| 2 | 上部検索バーで Resource Graph Explorer を検索する |
| 3 | 必要に応じて Directory から管理グループまたはサブスクリプションを選ぶ |
| 4 | KQL クエリを貼り付ける |
| 5 | Run query を実行し、Results と Messages を確認する |
| 6 | 必要に応じて CSV としてダウンロードする |
Azure Resource Graph Explorer では、結果を CSV でダウンロードできます。ただし、CSV エクスポートは最大 55,000 レコードに制限されます。大量の Redis や関連リソースがあるテナントでは、管理グループ、サブスクリプション、リージョン、タグで分割して実行すると扱いやすくなります。(Microsoft Learn)
すべてのRedisインスタンスを棚卸しするKQL
まずは、Redis 関連リソースを横断的に一覧化します。監査の最初の目的は「どこに何があるか」を把握することです。ここで SKU、リソースタイプ、リージョン、TLS、公開状態、認証状態を同じ表に並べます。
Resources
| where type in~ ("microsoft.cache/redis", "microsoft.cache/redisenterprise")
| extend skuName = coalesce(tostring(sku.name), tostring(properties.sku.name))
| extend kindValue = tostring(kind)
| extend redisVersion = tostring(properties.redisVersion)
| extend minimumTlsVersion = tostring(properties.minimumTlsVersion)
| extend nonTlsPortEnabled = tostring(properties.enableNonSslPort)
| extend publicNetworkAccess = tostring(properties.publicNetworkAccess)
| extend entraAuthEnabled = tostring(properties.redisConfiguration["aad-enabled"])
| extend keyBasedAuthDisabled = tostring(properties.disableAccessKeyAuthentication)
| project
subscriptionId,
resourceGroup,
name,
type,
kindValue,
location,
skuName,
redisVersion,
minimumTlsVersion,
nonTlsPortEnabled,
publicNetworkAccess,
entraAuthEnabled,
keyBasedAuthDisabled,
id
| order by subscriptionId asc, resourceGroup asc, name ascこのクエリで、監査対象の全体像を把握できます。特に type が microsoft.cache/redis のものと microsoft.cache/redisenterprise のものは、後続の認証確認で見方が変わるため、同じ Redis としてひとまとめにしないことが重要です。
TLS設定と非TLSポートを確認するKQL
TLS は Redis セキュリティ監査の最優先項目です。Microsoft の Redis 向け ARG ガイダンスでは、properties.minimumTlsVersion を使って Redis の最小 TLS バージョンを確認するクエリが紹介され、TLS 1.2 以上の利用が推奨されています。(TECHCOMMUNITY.MICROSOFT.COM)
Resources
| where type in~ ("microsoft.cache/redis", "microsoft.cache/redisenterprise")
| extend MinimumTLS = tostring(properties.minimumTlsVersion)
| extend NonTlsPortEnabled = tolower(tostring(properties.enableNonSslPort))
| extend TlsFinding = case(
isempty(MinimumTLS), "要確認: ARGで未取得",
MinimumTLS in ("1.0", "1.1"), "要対応: TLS 1.2未満",
MinimumTLS == "1.2", "OK: TLS 1.2",
"要確認: 想定外の値"
)
| extend NonTlsFinding = case(
NonTlsPortEnabled == "true", "要対応: 非TLSポート有効",
NonTlsPortEnabled == "false", "OK: 非TLSポート無効",
"要確認: ARGで未取得"
)
| project
subscriptionId,
resourceGroup,
name,
type,
location,
MinimumTLS,
NonTlsPortEnabled,
TlsFinding,
NonTlsFinding,
id
| order by TlsFinding asc, NonTlsFinding ascここで注意したいのは、TLS だけを見て安心しないことです。minimumTlsVersion が問題なくても、非TLSポートが有効になっていれば、古いクライアントや例外運用が残っている可能性があります。アプリ側の接続文字列、クライアントライブラリ、接続先ポートまで確認してから無効化します。
パブリックネットワーク公開を確認するKQL
Redis はアプリケーションのセッション、キャッシュ、キュー、ランキング、トークン周辺データなどを扱うことがあります。パブリック公開が許可されている Redis は、認証やファイアウォール設定があっても優先的に確認すべきです。
Resources
| where type in~ ("microsoft.cache/redis", "microsoft.cache/redisenterprise")
| extend PublicNetworkAccess = tostring(properties.publicNetworkAccess)
| extend ExposureFinding = case(
PublicNetworkAccess =~ "Enabled", "要確認: パブリックネットワークアクセス有効",
PublicNetworkAccess =~ "Disabled", "OK: パブリックネットワークアクセス無効",
isempty(PublicNetworkAccess), "要確認: ARGで未取得",
"要確認: 想定外の値"
)
| project
subscriptionId,
resourceGroup,
name,
type,
location,
PublicNetworkAccess,
ExposureFinding,
id
| order by ExposureFinding asc, subscriptionId asc, name ascMicrosoft の Azure Cache for Redis 設定ドキュメントでは、セキュリティのため Private Endpoint が推奨されています。また、Private Endpoint は Basic、Standard、Premium、Enterprise の各層でサポートされ、複数の VNet への接続にも利用できます。(Microsoft Learn)
実務では、PublicNetworkAccess = Enabled をすぐに違反と決めつけるのではなく、次の順で判断します。
| 判断ポイント | 確認内容 |
|---|---|
| 本番か非本番か | 本番で公開有効なら優先度を上げる |
| Firewallルール | 許可IPが広すぎないか、0.0.0.0/0 相当になっていないか |
| Private Endpoint | 既にプライベート接続へ移行済みか |
| 認証方式 | アクセスキー認証が残っていないか |
| アプリ依存 | 外部SaaSや別ネットワークからの接続要件があるか |
Microsoft Entra認証とアクセスキー認証を確認するKQL
Azure Cache for Redis には、アクセスキー認証と Microsoft Entra 認証の2つの認証方法があります。Microsoft Learn では、アクセスキー認証はシンプルな一方で、セキュリティとパスワード管理の課題があり、Microsoft Entra 統合によりパスワードなしの認証メカニズムと ACL によるロールベースのアクセス制御が提供されると説明されています。(Microsoft Learn)
Basic、Standard、Premium の Azure Cache for Redis では、次の KQL で Microsoft Entra 認証とアクセスキー無効化の状態を確認できます。
Resources
| where type =~ "microsoft.cache/redis"
| extend EntraAuthEnabled = tolower(tostring(properties.redisConfiguration["aad-enabled"]))
| extend KeyBasedAuthDisabled = tolower(tostring(properties.disableAccessKeyAuthentication))
| extend AuthFinding = case(
EntraAuthEnabled == "true" and KeyBasedAuthDisabled == "true",
"OK: Entra認証有効、アクセスキー無効",
EntraAuthEnabled == "true" and KeyBasedAuthDisabled != "true",
"要対応: Entra認証は有効だがアクセスキーが残存",
EntraAuthEnabled != "true" and KeyBasedAuthDisabled == "true",
"要確認: アクセスキー無効だがEntra状態を確認",
EntraAuthEnabled != "true" and KeyBasedAuthDisabled != "true",
"要対応: Entra認証未確認、アクセスキー有効",
"要確認"
)
| project
subscriptionId,
resourceGroup,
name,
location,
EntraAuthEnabled,
KeyBasedAuthDisabled,
AuthFinding,
id
| order by AuthFinding asc, subscriptionId asc, name ascこの結果で最も危険度が高いのは、EntraAuthEnabled が false または空欄で、KeyBasedAuthDisabled が false の Redis です。アプリがアクセスキーで接続している可能性が高いため、接続元、利用チーム、クライアントライブラリ、シークレット保管場所を確認してから Microsoft Entra 認証へ移行します。
Microsoft Entra 認証を有効化すると、構成読み込みのためキャッシュ内のノードが再起動され、接続が一時的に切断される可能性があります。Microsoft Learn では、メンテナンス期間中またはピーク時間外に実行することが推奨されています。(Microsoft Learn)
また、アクセスキー認証を無効化する場合も注意が必要です。Azure Managed Redis のドキュメントでは、アクセスキー設定を変更すると、アクセスキーまたは Microsoft Entra を使っている既存クライアント接続が終了すると説明されています。実施前に再接続処理、リトライ、トークン更新処理を確認してください。(Microsoft Learn)
Azure Managed RedisやRedis Enterpriseで補助的に見るべき項目
Azure Managed Redis は Microsoft Entra ID を既定で使用し、新しいキャッシュ作成時にはマネージド ID が有効になります。一方で、アクセスキー認証は引き続き利用可能であり、セキュリティとパスワード管理の課題があるため、Microsoft Entra ID への切り替えとアクセスキー無効化が推奨されています。(Microsoft Learn)
microsoft.cache/redisenterprise 系では、データベース側の子リソースに accessKeysAuthentication や clientProtocol が定義されています。Microsoft Learn のテンプレート参照では、accessKeysAuthentication は現在のアクセスキーによるアクセスを許可または拒否するプロパティ、clientProtocol は TLS 暗号化または平文 Redis プロトコルの接続可否を示すプロパティとして説明されています。(Microsoft Learn)
環境の Schema browser に microsoft.cache/redisenterprise/databases が表示される場合は、次の補助クエリも使えます。
Resources
| where type =~ "microsoft.cache/redisenterprise/databases"
| extend AccessKeysAuthentication = tostring(properties.accessKeysAuthentication)
| extend ClientProtocol = tostring(properties.clientProtocol)
| extend DatabaseFinding = case(
AccessKeysAuthentication =~ "Enabled" and ClientProtocol =~ "Plaintext",
"要対応: アクセスキー有効、平文プロトコル許可",
AccessKeysAuthentication =~ "Enabled",
"要確認: アクセスキー有効",
ClientProtocol =~ "Plaintext",
"要対応: 平文プロトコル許可",
AccessKeysAuthentication =~ "Disabled" and ClientProtocol =~ "Encrypted",
"OK: アクセスキー無効、暗号化プロトコル",
"要確認: ARGで未取得または想定外"
)
| project
subscriptionId,
resourceGroup,
name,
location,
AccessKeysAuthentication,
ClientProtocol,
DatabaseFinding,
id
| order by DatabaseFinding asc, subscriptionId asc, name ascMicrosoft Entra のアクセス割り当て状況を確認したい場合は、アクセスポリシー割り当ての子リソースも確認対象になります。microsoft.cache/redisEnterprise/databases/accessPolicyAssignments には、accessPolicyName とユーザーの objectId が定義されています。(Microsoft Learn)
Resources
| where type =~ "microsoft.cache/redisenterprise/databases/accessPolicyAssignments"
| extend accessPolicyName = tostring(properties.accessPolicyName)
| extend userObjectId = tostring(properties.user.objectId)
| project
subscriptionId,
resourceGroup,
name,
accessPolicyName,
userObjectId,
id
| order by subscriptionId asc, resourceGroup asc, name ascここで見えるのは、あくまでリソースとしての割り当て情報です。実際にアプリが Microsoft Entra トークンを正しく更新しているか、接続が継続できるかは、アプリケーション側の実装と接続テストで確認する必要があります。
危険度順に並べるKQL
監査結果をそのまま一覧で出すだけでは、所有チームに修正を依頼しにくくなります。複数サブスクリプションにまたがる環境では、簡易スコアを付けて「先に直すべき Redis」を並べると実務に乗せやすくなります。
Resources
| where type in~ ("microsoft.cache/redis", "microsoft.cache/redisenterprise")
| extend skuName = coalesce(tostring(sku.name), tostring(properties.sku.name))
| extend MinimumTLS = tostring(properties.minimumTlsVersion)
| extend NonTlsPortEnabled = tolower(tostring(properties.enableNonSslPort))
| extend PublicNetworkAccess = tostring(properties.publicNetworkAccess)
| extend EntraAuthEnabled = tolower(tostring(properties.redisConfiguration["aad-enabled"]))
| extend KeyBasedAuthDisabled = tolower(tostring(properties.disableAccessKeyAuthentication))
| extend riskScore =
iif(PublicNetworkAccess =~ "Enabled", 40, 0)
+ iif(NonTlsPortEnabled == "true", 30, 0)
+ iif(MinimumTLS in ("1.0", "1.1"), 30, 0)
+ iif(type =~ "microsoft.cache/redis" and KeyBasedAuthDisabled != "true", 25, 0)
+ iif(type =~ "microsoft.cache/redis" and EntraAuthEnabled != "true", 20, 0)
| extend priority = case(
riskScore >= 70, "P1: 早急に確認",
riskScore >= 40, "P2: 計画的に修正",
riskScore > 0, "P3: 例外または改善候補",
"OKまたは追加確認"
)
| project
priority,
riskScore,
subscriptionId,
resourceGroup,
name,
type,
location,
skuName,
MinimumTLS,
NonTlsPortEnabled,
PublicNetworkAccess,
EntraAuthEnabled,
KeyBasedAuthDisabled,
id
| order by riskScore desc, subscriptionId asc, name ascこのスコアはあくまで初期分類です。たとえば開発環境の一時 Redis と、顧客向け本番システムの Redis では、同じ PublicNetworkAccess = Enabled でもリスクの重みが違います。タグ、重要度、データ種別、インターネット到達性、アプリの再接続性を加えて最終判断してください。
監査結果を修正アクションに変える方法
Redis セキュリティ監査でよくある失敗は、KQL の結果を出して終わってしまうことです。実務では、結果を次のように分けると修正が進みます。
| 分類 | 例 | 対応 |
|---|---|---|
| 即時確認 | 本番 Redis でパブリック公開有効、アクセスキー有効 | 所有チームに連絡し、接続元と例外理由を確認 |
| 計画修正 | Entra 認証は有効だがアクセスキーも有効 | アプリ移行完了後、メンテナンス枠でアクセスキー無効化 |
| 技術検証 | 非TLSポート有効、古いクライアント利用の疑い | クライアントライブラリと接続文字列を確認 |
| 仕様確認 | ARG上で値が空欄 | Azure portal、ARM、サービスドキュメントで再確認 |
| 継続監視 | 現時点で問題なし | 保存クエリやダッシュボードで定期確認 |
Microsoft Entra 認証では、クライアントが Microsoft Entra トークンを期限前に更新し、Redis サーバーへ AUTH コマンドを送る必要があります。Azure Managed Redis のドキュメントでは、トークン期限の少なくとも3分前に新しい Microsoft Entra トークンを送ることや、AUTH コマンドが集中しないようジッターを加えることがベストプラクティスとして示されています。(Microsoft Learn)
つまり、監査結果だけを見てアクセスキーをすぐ無効化するのは危険です。先にアプリの接続方式を確認し、Entra トークン更新、再接続、リトライ、障害時の監視を整えてから変更します。
Azure Cache for Redisの移行計画にも監査結果を使う
Redis 監査は、セキュリティだけでなく移行計画にも役立ちます。Microsoft Learn の FAQ では、Azure Cache for Redis の Basic、Standard、Premium は 2028年9月30日に廃止され、Azure Cache for Redis Enterprise と Enterprise Flash は 2027年3月31日に廃止されると説明されています。(Microsoft Learn)
そのため、ARG の棚卸し結果には次の列を追加して管理すると便利です。
| 管理項目 | 使い方 |
|---|---|
| 所有チーム | 修正依頼先を明確にする |
| 業務重要度 | 本番、準本番、検証、廃止予定を分ける |
| 認証方式 | Entra 移行済みか、アクセスキー依存かを記録 |
| ネットワーク方式 | Public、Private Endpoint、VNet、Firewall を分類 |
| 移行候補 | Azure Managed Redis への移行優先度を決める |
| 例外期限 | 例外を恒久化させないため期限を設定する |
移行とセキュリティを別々に管理すると、同じ Redis に対して二重に調査が発生します。最初の ARG 監査で「リスク」「所有者」「移行候補」を同じ台帳に入れておくと、セキュリティレビュー、クラウド運用、アプリチームの会話が早くなります。
よくある落とし穴
ARGで値が空欄なら安全だと判断してしまう
空欄は「設定されていない」ではなく、「ARGに露出していない」「リソース種別が違う」「APIバージョン上見えない」「権限が足りない」可能性があります。特に Entra 認証やアクセスキー関連は、Azure Cache for Redis と Azure Managed Redis で見方が変わります。
パブリック公開だけを見てアクセスキーを見落とす
PublicNetworkAccess = Disabled でも、アクセスキー認証が残っていれば、キー漏えい時のリスクは残ります。ネットワーク制御と認証制御は別軸で確認してください。
アクセスキー無効化をアプリ確認なしで実施する
アクセスキーを無効化すると、既存接続が切断される可能性があります。Entra 認証に移行していても、トークン更新や再接続処理が不十分だと障害になります。変更前に、対象アプリの接続方式、ライブラリ、再接続設定、メンテナンス枠を確認します。
EnterpriseやAzure Managed RedisをOSS向けクエリだけで判断する
properties.redisConfiguration["aad-enabled"] や properties.disableAccessKeyAuthentication を見るクエリは、主に microsoft.cache/redis 向けです。microsoft.cache/redisenterprise やその子リソースでは、accessKeysAuthentication、clientProtocol、accessPolicyAssignments など、別の観点も確認します。
次にやるべきこと
まず Azure Resource Graph Explorer を開き、Redis の棚卸しクエリを実行してください。次に、TLS、パブリック公開、Microsoft Entra 認証、アクセスキー認証の結果を CSV 化し、リスクスコア順に並べます。P1 に入った Redis は、所有チーム、接続元、環境、本番影響を確認し、修正方針を決めます。
Redis セキュリティ監査で重要なのは、KQL を一度実行することではありません。複数サブスクリプションにまたがる Redis を継続的に可視化し、例外を期限付きで管理し、Microsoft Entra 認証、TLS 1.2 以上、Private Endpoint、アクセスキー無効化へ段階的に寄せていくことです。Azure Resource Graph は、その最初の棚卸しと継続監査をスクリプトなしで始めるための実用的な入口になります。
コメント