Redis ACL в продакшне: пользователи, категории, key patterns, ротация паролей и отладка

Redis с версии 6 получил полноценные ACL (Access Control Lists), и это изменило подход к безопасности: вместо единого пароля мы управляем пользователями, их правами на команды и ограничениями по ключам/каналам. В этой статье я пройду весь цикл: проектирование ролей, настройка категорий команд и key patterns, безопасная аутентификация (AUTH), ротация паролей (rotate) без простоя, сохранение правил, диагностика и практические шаблоны для production.

Зачем Redis ACL в production

ACL решает классические проблемы: один общий пароль быстро утекает, сложно ограничить доступ только на чтение, опасные команды вроде CONFIG или FLUSHALL нельзя просто запретить одному клиенту. С ACL вы:

• создаёте отдельных пользователей для сервисов и людей;
• назначаете категории команд (+@read, +@write, -@dangerous и т.д.);
• ограничиваете доступ по key patterns (например, только к ключам приложения app:*) и каналам Pub/Sub;
• безопасно проводите rotate паролей;
• аудируете попытки нарушений и быстро отлаживаете политику.

Цель — принцип минимально необходимых прав: запрет по умолчанию, затем точечные разрешения на нужные команды и префиксы ключей.

Если вы запускаете Redis самостоятельно и нужна изоляция и производительность, удобно размещать его на выделенном сервере. Посмотрите тарифы на облачные VDS — там легче соблюсти сетевые и системные политики безопасности.

Базовая модель ACL: пользователи и правила

Ключевые команды управления ACL:

• ACL SETUSER — создание/изменение пользователя и его правил;
• ACL GETUSER — просмотр;
• ACL LIST — список всех;
• ACL CAT — категории команд;
• ACL SAVE / ACL LOAD — сохранение/загрузка из файла;
• ACL WHOAMI — текущий пользователь;
• ACL LOG — аудит нарушений;
• ACL DRYRUN — безопасная проверка, выполнится ли команда от имени пользователя (Redis 7+).

Синтаксис правил в ACL SETUSER строится из нескольких групп:

• Состояние: on/off.
• Пароли: nopass, resetpass, >пароль (добавить пароль в открытом виде), #sha256 (добавить хеш пароля).
• Команды: +команда, -команда, +@категория, -@категория, allcommands, resetcommands.
• Подкоманды: +команда|подкоманда (тонкая фильтрация).
• Ключи и каналы: ~pattern для ключей, &pattern для Pub/Sub каналов; также allkeys/resetkeys и allchannels/resetchannels.
• Сброс всего: reset.

Категории команд

У команд есть категории, смотри ACL CAT. Наиболее полезные:

• @read — команды чтения (GET, MGET, SCARD и т.д.);
• @write — изменяющие (SET, DEL, INCR и т.д.);
• @admin — административные (SAVE, REPLICAOF, CLIENT и т.п.);
• @dangerous — потенциально опасные (FLUSHALL, CONFIG, MODULE, DEBUG);
• @pubsub — для работы с Pub/Sub;
• @keyspace, @scripting, и др.

Категории удобны для базового набора правил. При необходимости их можно донастроить индивидуальными плюсами/минусами для отдельных команд или подкоманд.

Подкоманды

Часть команд имеет подкоманды (например, CLIENT). Можно разрешить конкретную подкоманду, не открывая всю команду. Пример: +client|setname разрешит только CLIENT SETNAME.

Key patterns и каналы Pub/Sub

Самое сильное средство изоляции — ограничение по шаблонам ключей (key patterns). Например, сервис A работает только с appA:*, а сервис B — только с appB:*. На уровне ACL это задаётся правилами вида ~appA:* для пользователя сервиса A.

Для Pub/Sub действует аналогичный принцип, но с префиксом & — &news.* разрешит взаимодействие с каналами, совпадающими с шаблоном news.*.

Если вы не указали ни одного ~pattern и не включили allkeys, доступ к ключам будет запрещён. Это и есть «запрет по умолчанию».

Стратегия «запрет по умолчанию»

Рекомендуемый каркас для любого нового пользователя:

• Выключить всё: reset, затем off;
• Назначить пароль: минимум один >сложный_пароль;
• Включить пользователя: on;
• Команды: выдать только нужные категории и команды (обычно +@read +@write -@dangerous);
• Ключи: перечислить нужные ~pattern;
• Каналы (если нужно): указать &pattern;
• Проверить ACL DRYRUN и только после этого выкатить в приложение.

Файл ACL и персистентность настроек

Изменения ACL хранятся отдельно от RDB/AOF. Чтобы они пережили перезапуск, задайте aclfile в конфиге Redis и сохраняйте изменения:

# redis.conf
aclfile /etc/redis/users.acl

После изменения правил выполните:

ACL SAVE

При необходимости можно перезагрузить правила из файла:

ACL LOAD

Важно: без настроенного aclfile ваши изменения могут не сохраниться между рестартами сервера.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Безопасный baseline для default-пользователя

Исторически Redis имел один общий пароль. С ACL появился пользователь default. В production лучше не полагаться на него, а:

• либо выключить его (user default off в конфиге и/или ACL SETUSER default off),
• либо жёстко ограничить и выдать отдельные учётки для сервисов.

Пример минималистичной и безопасной инициализации в redis.conf (все угловые скобки в примере — это просто комментарии, не вставляйте их дословно):

# redis.conf
aclfile /etc/redis/users.acl

# Запретить default или оставить только чтение по конкретным ключам
# Вариант 1: полностью выключить
user default off

# Вариант 2: ограниченный доступ (пример)
# user default on reset resetpass +@read -@dangerous ~monitor:*

Создавайте отдельных пользователей для каждого приложения. Это удешевляет расследования и упрощает rotate паролей без глобального простоя.

Практика: пользователь приложения с изоляцией по префиксу ключей

Допустим, у нас есть микросервис billing, он должен читать и писать только ключи bill:*, никаких админ-команд, Pub/Sub не нужен.

ACL SETUSER billing reset
ACL SETUSER billing >S3cr3t-2025 on
ACL SETUSER billing +@read +@write -@dangerous
ACL SETUSER billing ~bill:*
ACL GETUSER billing
ACL SAVE

Клиент будет аутентифицироваться так:

AUTH billing S3cr3t-2025

Если клиент пытается выполнить CONFIG GET * или обратиться к user:*, попытка будет заблокирована, а событие попадёт в ACL LOG.

Только чтение: аналитика и отладка

Иногда нужен пользователь только для выборки. Пример ro, который видит только report:*, без права на запись:

ACL SETUSER ro reset
ACL SETUSER ro >RO-Only-2025 on
ACL SETUSER ro +@read -@write -@dangerous
ACL SETUSER ro ~report:*
ACL SAVE

Заметьте, мы явно запрещаем @write и @dangerous.

AUTH: режимы и совместимость

Есть два варианта аутентификации:

• AUTH username password — современный, когда используется конкретный пользователь ACL;
• AUTH password — исторический режим для default-пользователя, оставлен для совместимости.

В новых проектах всегда используйте явный AUTH user pass. Это прозрачно, безопасно и упрощает аудит.

Селекторы ACL (Redis 7+): разные права для разных префиксов

Селекторы позволяют в рамках одного пользователя задавать несколько независимых наборов правил (подмножества ACL). Это удобно, когда сервис должен иметь разные права на разные группы ключей. Пример: читать всё cache:*, но писать можно только в cache:own:*.

# Один пользователь, два селектора
ACL SETUSER api reset >AP1-2025 on
ACL SETUSER api resetcommands resetkeys
ACL SETUSER api +@read +@write -@dangerous

# Селектор 1: доступ только на чтение ко всему cache:*
ACL SETUSER api ~cache:* +@read -@write

# Селектор 2: дополнительно разрешаем запись в cache:own:*
ACL SETUSER api ~cache:own:* +@write

ACL SAVE

Подход с селекторами уменьшает количество служебных пользователей и упрощает конфигурацию клиента.

Pub/Sub: ограничение каналов

Если ваш сервис использует Pub/Sub, ограничьте каналы:

ACL SETUSER notifier reset >Sub-Pub-2025 on
ACL SETUSER notifier +@pubsub -@dangerous
ACL SETUSER notifier &events.*
ACL SAVE

Такой пользователь сможет публиковать и подписываться только на каналы, совпадающие с шаблоном events.*.

Ротация паролей (rotate) без простоя

Стандартный безболезненный сценарий для одного пользователя:

1. Добавьте новый пароль, не удаляя старый: ACL SETUSER app >New-2025.
2. Переключите клиентов на новый пароль (деплой с обновлёнными секретами).
3. Убедитесь в отсутствии подключений со старым паролем (мониторинг отказов в логах ACL, статистика соединений).
4. Удалите старые пароли. Проще всего — resetpass и повторное добавление только нового: ACL SETUSER app resetpass >New-2025.
5. Сохраните файл ACL: ACL SAVE.

Если у вас много инстансов/шардов — применяйте этот порядок на каждом узле последовательно. На время миграции оба пароля остаются валидными, поэтому нет простоя.

Проверка правил перед выкатыванием: ACL DRYRUN

ACL DRYRUN эмулирует выполнение команды от имени пользователя. Пример: можно ли пользователю billing установить ключ bill:1?

ACL DRYRUN billing SET bill:1 42

Команда вернёт OK или укажет причину отказа (запрещённая команда, неподходящий шаблон ключа и т.п.). Это незаменимо для CI-проверок и для «сухого прогона» перед деплоем.

Диагностика, аудит и наблюдаемость

• ACL WHOAMI — быстро понять, под какой учёткой работает клиент;
• ACL LOG — посмотреть недавние нарушения (кто, когда, что пытался выполнить);
• ACL LOG RESET — очистить журнал;
• метрики: количество отказов по ACL удобно выносить в мониторинг как сигнал о регрессиях.

Типичный цикл расследования при аномалии прав: воспроизвести команду, посмотреть ACL DRYRUN для конкретного пользователя, затем сверить категории/подкоманды и шаблоны ключей.

Репликация, кластеры и сервисные пользователи

ACL применяются к клиентским подключениям. Для репликации и sentinel/cluster-узлов используйте отдельные сервисные учётки со строгими правами:

• права только необходимые для репликации и служебных операций;
• изолированные пароли, отдельный цикл rotate;
• никаких «широких» allcommands/allkeys без крайней необходимости.

Если строите высокую доступность, загляните в наш материал про отказоустойчивость Redis с Sentinel.

Помните, что команды типа CONFIG, MODULE, FLUSHALL входят в @dangerous. В повседневной работе злоупотреблять @admin и @dangerous не стоит; выделяйте узкий набор подкоманд, например +client|setname, +ping, и т.д.

Типичные ошибки и как их избежать

• Забыли настроить aclfile — после рестарта правила пропали. Решение: указать aclfile и выполнять ACL SAVE.
• Случайно замкнули себя — изменили права активной сессии. Действуйте через временную сессию с админ-учёткой, используйте ACL DRYRUN, проверяйте ACL GETUSER перед сохранением.
• Слишком широкие шаблоны — ~* оставили «на время». Заведите практику ревью ACL, не выкатывайте «временные» лазейки.
• Открыли @dangerous ради удобства
• Не сделали rotate после инцидента
• Игнорируете Pub/Sub — забыли ограничить &pattern и получили непреднамеренный доступ к чужим каналам.

Полезные практические приёмы

Гранулярные подкоманды вместо целых категорий

Если нужно разрешить единичную админ-функцию, не открывайте @admin. Лучше явно разрешить подкоманду:

ACL SETUSER tool reset >Tool-2025 on
ACL SETUSER tool +ping +client|setname -@dangerous
ACL SETUSER tool ~tool:*
ACL SAVE

Много команд — начните с категорий, затем вычитайте

Быстрее всего: дать +@read +@write и сразу вычеркнуть избыточное: -eval -script (или -@scripting целиком), -sort и т.д. Потом сузить ключи через ~pattern.

Доступ только на чтение с блокировкой потенциальных лазеек

Для «read-only» не забывайте запретить опасные пути обхода: -@scripting, -sort с STORE, и т.п. Если используете Redis для сессий PHP, посмотрите разбор по теме — блокировка PHP‑сессий в Redis.

FAQ

Как увидеть список категорий и команд в них? Выполните ACL CAT и ACL CAT @category.

Можно ли хранить только хеши паролей? Да: используйте форму #sha256 в ACL SETUSER и не передавайте пароль в открытом виде.

Что быстрее — категории или явные команды? С точки зрения производительности разница несущественна. Выбирайте то, что проще сопровождать.

Нужно ли ACL при доступе только с приватной сети? Да. ACL — это изоляция внутри кластера и между сервисами, плюс аудит и удобный rotate.

Повлияют ли ACL на репликацию? Реплики и сервисные компоненты тоже аутентифицируются; выделяйте им отдельные учётки с нужными правами.

Резюме

ACL — это не «галочка безопасности», а полноценный инструмент эксплуатации: он позволяет строго поделить обязанности между сервисами, ограничить команды категориями и подкомандами, изолировать ключи через key patterns, безболезненно делать rotate паролей и получать пригодный для расследований след в ACL LOG. Сформируйте базовый стандарт под ваши приложения, заведите шаблоны пользователей и проверьте их ACL DRYRUN до выката — так вы избежите большинства сюрпризов в production.