Как настроить правила доступа в Redis ACL

Redis — одна из самых популярных in-memory баз данных, широко используемая для кэширования, хранения сессий, реализации очередей и других задач, требующих высокой производительности. С выходом версии 6.0 Redis внедрил систему управления доступом на основе ролей (ACL), что стало важным шагом в сторону повышения безопасности. Настройка правил доступа через ACL позволяет точно контролировать, кто и какие команды может выполнять, а также к каким ключам получать доступ.

Что такое ACL в Redis и зачем он нужен

До версии 6.0 Redis полагался исключительно на парольную аутентификацию, причём один общий пароль для всех подключений. Это серьёзное уязвимое место: если пароль скомпрометирован, злоумышленник получает полный контроль над экземпляром. Система ACL (Access Control List) кардинально меняет подход к безопасности, позволяя создавать нескольких пользователей с разными уровнями доступа.
Каждый пользователь в Redis теперь может иметь:
— собственный пароль (или несколько);
— список разрешённых или запрещённых команд;
— шаблоны ключей, к которым разрешён доступ;
— статус активности (включён/отключён).
Это особенно важно в распределённых системах, где разные сервисы используют один и тот же Redis-экземпляр, но должны видеть только свои данные. Например, микросервис аутентификации не должен иметь доступ к данным корзины покупок.

Система ACL устраняет проблему «всё или ничего», характерную для старых версий Redis. Теперь можно выдать пользователю права только на выполнение команд GET, SET и DEL для ключей, начинающихся с префикса session:. Это соответствует принципу минимальных привилегий — одному из основополагающих принципов информационной безопасности.

Как включить и настроить ACL в Redis

По умолчанию Redis поставляется с включённым пользователем default, который имеет полный доступ ко всем командам и ключам. Первый шаг к безопасной настройке — это изменение поведения этого пользователя или его отключение.
ACL можно настраивать двумя способами:
— Через конфигурационный файл redis.conf;
— Через команды в интерактивном режиме (например, через redis-cli).
Для работы с ACL в конфигурации Redis должна быть строка:

aclfile /etc/redis/users.acl

Этот файл будет содержать все определения пользователей и их прав. При старте Redis загружает этот файл, и все изменения, сделанные через CLI, сохраняются туда командой ACL SAVE.
Пример базовой настройки в redis.conf:

aclfile /etc/redis/users.acl
requirepass your_strong_password

Однако использование requirepass совместно с ACL не рекомендуется, так как оно автоматически задаёт пароль для пользователя default. Лучше отключить requirepass и управлять паролями через ACL SETUSER.

Шаги по включению ACL

1. Убедитесь, что используется Redis 6.0 или выше: redis-server --version.
2. Откройте redis.conf и укажите путь к ACL-файлу.
3. Перезапустите сервер или перезагрузите конфигурацию через CONFIG REWRITE.
4. Подключитесь через redis-cli и проверьте текущих пользователей: ACL LIST.
5. Отключите или ограничьте пользователя default: ACL SETUSER default off.
6. Создайте нового администратора с полными правами и паролем.

Создание пользователей и управление правами

Основная команда для управления пользователями — ACL SETUSER. Она позволяет создать или изменить пользователя с указанием его атрибутов. Атрибуты задаются в виде флагов и спецификаторов.
Пример создания пользователя с ограниченными правами:

ACL SETUSER reader on >mypass ~cache:* +get +keys +scan

Разберём по частям:
— reader — имя пользователя;
— on — включить пользователя;
— >mypass — установить пароль (не отображается в списке);
— ~cache:* — разрешить доступ к ключам, начинающимся с cache:;
— +get +keys +scan — разрешить выполнение этих команд.
Чтобы проверить, какие права есть у пользователя, используйте:

ACL WHOAMI

— покажет текущего пользователя;

ACL GETUSER username

— подробная информация о конкретном пользователе.

Флаги и атрибуты пользователя

Работа с разрешениями на команды

Одна из самых мощных возможностей ACL — тонкая настройка прав на уровне отдельных команд. Это позволяет создавать специализированных пользователей, например, только для чтения, только для публикации в каналы или для мониторинга.
Например, чтобы создать пользователя для мониторинга:

ACL SETUSER monitor on >monpass &@admin +ping +info -shutdown

Здесь мы разрешили категорию @admin, но исключили опасную команду SHUTDOWN. Это типичный случай: дать возможность диагностировать систему, но не выключать её.
Команды можно добавлять и убирать по одной:

ACL SETUSER api +set +del -flushall -flushdb

Такой пользователь может работать с данными, но не сможет очистить всю БД.

Динамическое управление правами

Вы можете модифицировать права пользователя «на лету»:

• ACL SETUSER user +newcommand — добавить команду;
• ACL SETUSER user -dangerouscmd — запретить команду;
• ACL SETUSER user ~newprefix:* — расширить доступ к ключам.

Изменения применяются немедленно, без перезагрузки. Однако для сохранения в файл нужно выполнить ACL SAVE.

Ограничение доступа по шаблонам ключей

Шаблоны ключей (key patterns) — это механизм, позволяющий ограничить доступ пользователя только к определённому набору ключей. Это критически важно в мультитенантных системах или при разделении данных между сервисами.
Например:

ACL SETUSER payments on >pay123 ~payments:* ~invoices:* +get +set +hgetall

Теперь этот пользователь не сможет читать ключи из пространства users: или cache:.
Шаблоны поддерживают символ * как wildcard. Можно указать несколько шаблонов:

• ~orders:* ~cart:* ~promo:* — доступ к трём префиксам;
• ~* — доступ ко всем ключам (по умолчанию у default);
• ~config:??? — доступ к ключам с ровно тремя символами после префикса.

Обратите внимание: Redis не поддерживает отрицательные шаблоны (типа «всё, кроме»). Если нужно запретить доступ к определённым ключам — лучше явно разрешить только нужные.

Пример: микросервисная архитектура

Представьте три сервиса: auth, catalog, orders. Каждый работает с Redis, но должен видеть только свои данные.

ACL SETUSER auth on >authpass ~session:* ~tokens:* +get +set +expire
ACL SETUSER catalog on >catpass ~product:* ~category:* +get +mget +keys
ACL SETUSER orders on >orderpass ~order:* ~cart:* +hset +hgetall +del

Теперь даже при утечке одного пароля, злоумышленник не сможет получить доступ к данным других сервисов.

Лучшие практики безопасности при использовании ACL

Настройка ACL — это не разовое действие, а часть стратегии безопасности. Вот проверенные рекомендации:

• Отключите пользователя default: ACL SETUSER default off — обязательный шаг для production.
• Используйте сложные пароли: минимум 16 символов, лучше — случайные строки. Храните их в менеджере секретов (Hashicorp Vault, AWS Secrets Manager).
• Принцип минимальных привилегий: давайте только то, что необходимо. Не используйте &@all без крайней необходимости.
• Регулярно аудируйте пользователей: запускайте ACL LIST и ACL GETUSER при инцидентах или плановых проверках.
• Автоматизируйте развертывание: храните ACL-конфигурацию в Git, применяйте через Ansible, Terraform или CI/CD.

Для критически важных систем можно включить логирование команд:

slowlog-log-slower-than 0

Это позволит анализировать, какие команды выполняются и к каким ключам обращаются.

Многофакторная аутентификация

Redis не поддерживает MFA напрямую, но вы можете реализовать двухэтапную проверку на уровне сети:

• Ограничьте IP-адреса через брандмауэр;
• Используйте TLS для шифрования соединений;
• Разместите Redis за прокси с дополнительной аутентификацией (например, с OAuth).

Типичные ошибки и как их исправить

Даже опытные администраторы сталкиваются с проблемами при настройке ACL. Вот самые частые:

Ошибка: «NOPERM: User has no permissions»

Пользователь не может выполнить команду. Причины:

• Команда не добавлена через +command;
• Команда запрещена через -command;
• Доступ к ключу запрещён по шаблону.

Решение: проверьте ACL GETUSER username и сравните с нужными правами.

Ошибка: «NOAUTH: Authentication required»

Пользователь не авторизован. Возможные причины:

• Пароль не установлен или неверный;
• Пользователь отключён (off);
• Не выполнена аутентификация: AUTH username password.

Решение: убедитесь, что пользователь on и пароль передаётся правильно.

Ошибка: «ACL SAVE failed»

Redis не может сохранить ACL в файл. Причины:

• Нет прав на запись в директорию;
• Файл заблокирован;
• Путь не указан в redis.conf.

Решение: проверьте права на файл /etc/redis/users.acl и владельца процесса Redis.

Экспертное мнение

Правильная настройка ACL — это не просто техническая задача, а элемент общей стратегии безопасности. Система должна быть прозрачной, легко воспроизводимой и поддающейся аудиту. Лучше потратить время на проектирование ролей, чем потом реагировать на утечку данных.
При проектировании ACL-политик рекомендуется:
— Чётко определить зоны ответственности сервисов;
— Документировать, какие команды и ключи нужны каждому компоненту;
— Регулярно пересматривать права доступа при изменении архитектуры.
Автоматизация — ключевой фактор. Ручные изменения в продакшене недопустимы. Все изменения должны проходить через CI/CD, с предварительным тестированием в staging-среде.

Вопросы и ответы

Заключение

Настройка правил доступа в Redis через ACL — это обязательный шаг при развёртывании базы данных в production-среде. Она позволяет кардинально повысить безопасность, ограничив доступ каждого пользователя строго необходимым минимумом команд и ключей. Отключение пользователя default, создание ролей по принципу минимальных привилегий и автоматизация управления — ключевые элементы успешной стратегии.

• Всегда отключайте пользователя default в production;
• Используйте шаблоны ключей и категории команд для гибкой настройки;
• Храните и разворачивайте ACL-конфигурацию через IaC;
• Контролируйте доступ с помощью брандмауэров и TLS;
• Регулярно аудируйте пользователей и их права.