Azure Redis Enterprise（EnterpriseCluster/Balanced_B0 など）で ACL SETUSER を実行すると「ERR command ‘acl|setuser’ is not allowed」が出て困ることがあります。本記事では、ACL が使えない理由と、代替でロール分離を実現する設計・運用の落とし所を整理します。
発生するエラーと状況（再現コマンド）
典型的には、Azure の Redis Enterprise 系インスタンス（例：SKU が Balanced_B0、Clustering Policy が EnterpriseCluster）で、ACL を使って新しいユーザーを作成しようとしたときに発生します。
ACL SETUSER demo-svc on >DemoPass123! +@read +set ~demo*このとき、次のようなエラーが返ってきます。
(error) ERR command 'acl|setuser' is not allowedポイントは、「Redis の ACL 機能を使った RBAC（ロール分離）を、サービス側がコマンドとして許可していない」という点です。クライアントの打ち間違い、権限不足、TLS 設定などの“よくあるミス”ではないケースが多いです。
| 確認項目 | この事象の典型 | 切り分けのヒント |
|---|---|---|
| 実行コマンド | ACL SETUSER / ACL LIST など ACL 系 | ACL 関連だけが拒否されるなら“仕様でブロック”の可能性が高い |
| エラーメッセージ | ERR command 'acl|setuser' is not allowed | 「allowed ではない」＝そのコマンド自体が提供されていない/無効化されている |
| 構成 | Enterprise/Enterprise Flash、または Azure Managed Redis の Enterprise 系 | 同じ “Redis” でも SKU/サービスで管理機能が大きく異なる |
結論：Azure Redis Enterprise では ACL コマンドを有効化できない
まず結論から言うと、Azure Redis Enterprise（Enterprise/Enterprise Flash、EnterpriseCluster 構成を含む）では ACL SETUSER などの ACL コマンドはサポートされていません。そのため、ERR command 'acl|setuser' is not allowed は設定ミスではなくサービス仕様に沿ったエラーです。
また、「権限を付与すれば動く」「フラグを有効化すれば使える」というタイプの機能ではなく、現時点ではユーザー側で ACL コマンドを許可する手段がありません。
「Data Access Configuration（データ アクセス構成）」が見つからない理由
ドキュメントやブログで「Data Access Configuration（データ アクセス構成）」というメニューや、+@read +set ~demo* のようなカスタムポリシー設定が出てくることがあります。しかしこの UI はどの Redis を使っているか（SKU/サービス）で表示可否が変わります。
Azure ポータルの「Data Access Configuration」メニューは Basic/Standard/Premium で提供され、Enterprise/Enterprise Flash には表示されません。そのため、Enterprise 系を使っていると、同じ手順を探しても“メニューが存在しない”状態になります。
さらに、Microsoft Learn の RBAC（データ アクセス ポリシー）関連ドキュメントでも、データアクセス ポリシーの構成は Enterprise/Enterprise Flash では未サポートであることが明記されています。
「+@read +set ~demo*」は何を表しているのか（ACL 構文の意味）
ドキュメントに出てくる +@read +set ~demo* のような文字列は、Redis の ACL（Access Control List）機能で使う権限文字列です。Redis 6 以降の ACL では、ユーザーごとに「許可するコマンドカテゴリ」「許可するコマンド」「アクセスできるキーのパターン」などを指定できます。
| 例 | 意味 | よくある用途 |
|---|---|---|
+@read | 読み取り系コマンドカテゴリを許可 | 読み取り専用 API / 集計処理 |
+set | SET コマンドを個別に許可 | 限定的に書き込みを許可したい |
~demo* | demo で始まるキーだけアクセス許可（キー・パターン） | プレフィックスでテナント分離 |
on / off | ユーザーの有効/無効 | 緊急停止、棚卸し |
>password | ユーザーのパスワード設定 | ユーザー追加/ローテーション |
重要なのは、この ACL 構文自体は Redis の標準機能である一方、Azure の “管理された Redis” では、SKU/サービスにより ACL コマンドの実行が制限されることがある点です（今回の “not allowed” がまさにそれです）。
まず整理したい：Azure の Redis は「名前が似ていて別物」が多い
「Azure Redis」「Azure Cache for Redis」「Azure Redis Enterprise」「Azure Managed Redis」など、呼び方が似ていて混乱しやすいのですが、実際には機能差がかなり大きいです。特にアクセス制御（ACL/RBAC/Entra 連携）を考えるときは、次の観点で整理すると判断が早くなります。
| 観点 | Basic/Standard/Premium（Azure Cache for Redis） | Enterprise/Enterprise Flash（Azure Cache for Redis Enterprise） | Azure Managed Redis |
|---|---|---|---|
ACL コマンド（ACL SETUSER 等） | “直接叩く”運用ではなく、Entra 連携＋ポリシー管理が中心 | コマンド自体がブロックされる | 現時点では ACL 未サポート |
| Data Access Configuration（データ アクセス構成） | 表示される（カスタム ポリシー作成可能） | 表示されない | 現時点では Data Access Policy 未サポート（UI で見つからないことが多い） |
| Microsoft Entra 認証 | サポート（RBAC と連動） | サポート外 | サポート（ただし権限は Access Keys と同等＝実質フルアクセス） |
| 注意点 | 全 SKU のリタイアが告知されており移行計画が重要 | ACL による細粒度制御ができない | Entra は使えるが “認証” の置換が主で “認可” は限定的 |
Basic/Standard/Premium の「カスタム データ アクセス ポリシー」は Enterprise/Enterprise Flash では提供されないこと、そして Azure Managed Redis では現時点で ACL／Data Access Policy が未サポートであることが、混乱の根本原因になりがちです。
なお、Azure Cache for Redis は全 SKU のリタイアが告知され、Azure Managed Redis への移行が推奨されています（最新状況は公式ドキュメントを確認してください）。
なぜ Enterprise で ACL が使えないと困るのか（現場で起きやすいこと）
ACL が使えないと、次のような “Redis 側で止めたい事故” を、Redis だけでは止めにくくなります。
- 読み取り専用にしたいサービスが、誤って更新系コマンドを叩いてしまう
- テナント A の処理が、テナント B のキーを読めてしまう（プレフィックス分離が守られない）
- 運用・デバッグ目的の接続が、想定外のコマンドを実行してしまう
- 「誰が何をしたか」を Redis のユーザー単位で追えず、原因調査が難航する
この “困りごと” に対して、Enterprise では「Redis 自体に細粒度権限を持たせる」のではなく、設計・運用の層で代替するのが現実的な解になります。
代替となるロールベースアクセス（RBAC）の現実解
Azure Redis Enterprise で ACL が使えない場合、よく採られる代替案は大きく 3 つです。どれが正解というより、要件（セキュリティ粒度・運用コスト・性能・予算）で最適解が変わります。
| 代替案 | 概要 | 向いているケース | 注意点 |
|---|---|---|---|
| アプリケーション側でアクセス制御 | Redis は “単一の接続” で使い、誰がどのキーを触れるかはアプリで判定 | 権限設計が複雑／頻繁に変わる、ロールをビジネスロジックと同期したい | Redis へ直結できる人/システムが増えると破綻しやすい（ネットワーク設計が重要） |
| 用途・権限ごとに Redis を分割 | 読み取り専用、管理用、バッチ用などで Redis インスタンス（またはデータベース）を分ける | 役割が少数で明確（read-only / read-write / admin など） | インスタンス数が増えるとコスト・監視・運用が増える |
| SKU/サービスの見直し（または別基盤） | Redis 側で細粒度制御が必須なら、対応している環境へ移す | 監査要件が厳格、Redis 側での “強制” が必要 | 移行コスト、接続方式、サポート機能の差分に注意 |
アプリケーション側でアクセス制御する設計のコツ
アプリ側で RBAC を持つ場合、実務では「キー設計」と「接続経路の固定化」が成否を分けます。特にクラスタ構成（EnterpriseCluster/Redis Cluster 相当）では、データベース番号での分離（SELECT で DB を切り替える）に頼れません。Redis Cluster は DB0 のみで、SELECT は使えない仕様です。
キー命名で “権限の境界線” を作る
キーのプレフィックス（または名前空間）を、認可の単位に合わせて設計します。
| 要件 | キー設計例 | 解説 |
|---|---|---|
| テナント分離 | tenant:{tenantId}:* | アプリ側で tenantId を必ず付与。ログ/監査も tenantId を軸に集約しやすい |
| 機能別分離 | feature:cart:{tenantId}:{userId} | 「どの機能が触るデータか」をキーで明確化。運用時の棚卸しにも強い |
| 環境分離（dev/stg/prod） | prod:tenant:{tenantId}:* | 環境跨ぎの誤接続事故を減らす（接続先分離が理想だが、キーでも保険をかける） |
Redis 直結を減らす（“正しい入口” を 1 つにする）
アプリ側認可のモデルでは、Redis に直接接続できる人/プロセスが増えるほど、RBAC は崩れます。運用としては次が有効です。
- Redis への接続情報（アクセスキー/接続文字列）を配布する先を最小化する
- 開発者が “便利ツールから直結” できるネットワーク経路を作らない（必要なら踏み台/承認を挟む）
- アプリ経由の操作に寄せ、Redis への操作ログ（誰が何を要求したか）をアプリ側で残す
実装パターン：Redis クライアントを “権限付き” でラップする
アプリ側で RBAC を実装するなら、散らばった if 文で守るよりも、Redis 呼び出し口を 1 箇所に集約し、ロールごとに許可 API を分ける方が事故が減ります。
// 擬似コード例（考え方）
// - 直接キーを受け取らず、「テナント/機能/ID」からキーを組み立てる
// - ロール（Reader/Writer/Admin）ごとに公開メソッドを分ける
class TenantCache {
getUserProfile(tenantId, userId) { /* GET only */ }
setUserProfile(tenantId, userId, data) { /* Writer only */ }
purgeTenant(tenantId) { /* Admin only / そもそも本番では公開しない */ }
}この形にすると、コードレビューの段階で「この操作は Reader から呼ばれないよね？」を追いやすくなり、運用でも “権限逸脱” を検知しやすくなります。
用途・権限ごとに Redis インスタンスを分ける（実質的なロール分離）
ロールが少数で、役割境界が明確なら、Redis を分割するのが一番わかりやすい解になります。Enterprise では ACL が効かない以上、ネットワーク・接続先・秘密情報の配布ポリシーで境界線を作る発想です。
よくある分割例
- read-cache：参照専用 API が使う（TTL 長め、容量大きめ）
- write-cache：更新処理・バッチが使う（書き込み頻度高い）
- admin-cache：運用ツールや一時調査用（本番では接続できる人を最小限に）
| 分割の軸 | メリット | デメリット | 現場のコツ |
|---|---|---|---|
| 読み取り/書き込み | 事故（誤更新）の確率を下げられる | データ二重化や同期が必要な場合がある | 読み取り側は “生成元は DB/ストレージ” に寄せ、Redis 同期を必須にしない |
| 環境（dev/stg/prod） | 誤接続が激減 | コスト増 | 少なくとも prod は必ず分離（同一 Redis に prod/dev が混在は危険） |
| テナント | 強い隔離（法令/契約要件に対応しやすい） | インスタンス数が増えると運用が大変 | “大口テナントだけ分離” のハイブリッドが現実的 |
「SKU を変えれば RBAC できる？」を正しく判断する
ここが一番迷いがちなポイントです。結論としては、「やりたい RBAC が何か」で答えが変わります。
Redis 側で “コマンド/キー単位” の制御が必要なら
Redis の ACL 構文（例：+@read +set ~demo*）で “キーやコマンドを絞る” という意味の RBAC をやりたいなら、Data Access Configuration（データ アクセス構成）でデータアクセス ポリシーを作れる層が必要になります。これは Basic/Standard/Premium で提供され、Enterprise/Enterprise Flash では提供されません。
一方で、Azure Managed Redis は Microsoft Entra 認証自体は使えますが、現時点では ACL／Data Access Policy が未サポートで、細粒度の許可・拒否を作る仕組みは用意されていない状況です。
“認証を強くする” だけなら（パスワードレス化したいなら）
「アクセスキー（固定シークレット）を配りたくない」「Managed Identity やサービスプリンシパルで接続したい」という意味なら、Azure Managed Redis の Microsoft Entra 認証が役立ちます。ただし、公式ドキュメント上は Entra で接続しても権限は Access Keys と同等（≒フルアクセス）として扱われるため、“認証の置き換え” と “認可（RBAC）” を混同しないことが重要です。
判断に迷ったときのチェックリスト
「Enterprise で ACL が使えない」と分かった後に、次の質問に答えると方針が固まります。
| 質問 | Yes の場合の有力案 | No の場合の有力案 |
|---|---|---|
| Redis 側で “キー/コマンド単位” の強制が必須？ | データアクセス ポリシー対応の層へ移行、または別基盤（自前 Redis/Redis Cloud 等） | アプリ側制御＋ネットワーク分離で十分なことが多い |
| ロールは 3 種類以内（read/write/admin など）で固定？ | インスタンス分割がシンプルで強い | アプリ側 RBAC の方が変更に強い |
| 開発者・運用者が Redis に直結する運用が避けられない？ | 直結用の専用インスタンス（admin-cache）を用意し、本番データとは分離 | 直結経路を閉じ、アプリ経由に統一 |
| 近い将来に移行計画（Azure Managed Redis など）がある？ | “いまだけの最適化” を避け、アプリ側制御・分割方針を先に固める | 現行 SKU の機能で最短に寄せる |
よくある質問（FAQ）
設定や権限で ACL SETUSER を有効化できますか？
できません。Azure Redis Enterprise では ACL コマンド自体がサポートされておらず、設定で解決するタイプの問題ではありません。
なぜドキュメントの手順どおりに進められないのですか？
その手順は Basic/Standard/Premium の “Data Access Configuration” を前提にしている場合があります。Enterprise/Enterprise Flash（および Azure Managed Redis の現行仕様）では同じメニューが存在しない/同等機能が未提供のためです。
Azure Managed Redis なら ACL で RBAC できますか？
現時点では ACL（および Data Access Policy）が未サポートで、細粒度 RBAC の実現は難しい状況です。公式にも「現時点で未サポート」「いつ/提供されるかは不明」といった趣旨の回答が出ています。
それでも “安全に” 運用するための最低ラインは？
- Redis へ到達できるネットワーク経路を最小化する（誰でも到達できる状態にしない）
- 接続情報（アクセスキー等）の配布先を絞り、ローテーション運用を前提にする
- アプリ側で「誰が何のキーを触ったか」をログに残し、監査できる形にする
- 役割が明確ならインスタンス分割で境界線を作る
まとめ
- Azure Redis Enterprise では
ACL SETUSERを含む ACL コマンドがサポートされず、エラーは仕様によるものです。 - 「Data Access Configuration（データ アクセス構成）」は Basic/Standard/Premium の機能であり、Enterprise/Enterprise Flash には表示されません。
- Azure Managed Redis は Entra 認証が利用できる一方、現時点で ACL／Data Access Policy は未サポートで、細粒度 RBAC の代替は設計で補う必要があります。
- 代替策は「アプリ側で制御」「インスタンス分割」「基盤の見直し」の 3 つ。要件に合わせて組み合わせるのが現実的です。
コメント