Пароль и безопасность
Тема дорожной карты · Redis
Аутентификация по паролю Redis является первым рубежом защиты для in-memory хранилища, которое нередко открыто во внутренних сетях, разделяемых многими сервисами. Простейший вариант — установить requirepass <strongpassword> в redis.conf, что вынуждает клиентов проходить аутентификацию командой AUTH <password> до принятия любой команды Redis-сервером. Для более детального управления доступом в Redis 6 появились списки контроля доступа (ACL), позволяющие операторам задавать пароли, белые списки команд и ограничения на шаблоны ключей на уровне пользователя с помощью директив ACL SETUSER. Помимо аутентификации, лучшие практики безопасности Redis включают привязку через bind 127.0.0.1, включение TLS с tls-port и соответствующей конфигурацией сертификатов, а также отключение опасных команд типа FLUSHALL или CONFIG через rename-command. Защита Redis с помощью надёжного пароля и ACL обязательна, когда распределённый кэш хранит чувствительные токены сессий или пользовательские данные.
Как это работает
Пароль и безопасность через пакеты дистрибутива (apt/dnf), официальный tarball + make, Docker (redis:7-alpine) или managed cloud (Yandex Managed Redis, AWS ElastiCache). Конфиг в /etc/redis/redis.conf. Критичные параметры: maxmemory, maxmemory-policy (allkeys-lru — дефолт для кеша), appendonly + appendfsync для AOF persistence, save snapshots для RDB persistence, requirepass для auth, bind для прослушиваемых интерфейсов.
Когда применять
Docker — для dev; bare-metal/VM или managed cloud — для production. Всегда выставляйте maxmemory ниже всей RAM (оставьте запас для fork() при persistence). maxmemory-policy = allkeys-lru для чистого кеша, volatile-lru для микса (вытеснять только ключи с TTL), noeviction если потеря = баг (сами обрабатываете full-memory). Никогда не светите 6379 в интернет — bind только на localhost или приватную сеть.
Типичные ошибки
Ловушки Пароль и безопасность: дефолт bind 0.0.0.0 + без пароля (мгновенный компромисс — Redis-сканеры повсюду); пропущенный maxmemory на кеше (OOM kill); AOF appendfsync always (каждая запись = fsync; throughput падает в 100×); хост со swap (paging памяти хуже, чем drop, для in-memory БД).