Как получить список всех ключей в Redis (и почему это опасно)

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

Команда KEYS *: как работает и почему она опасна

Команда KEYS * — это самый прямой способ получить все ключи, хранящиеся в текущей базе данных Redis. Она возвращает массив строк, соответствующих шаблону. Звёздочка означает «любое имя», то есть команда вернёт полный список.
На первый взгляд, это удобно: вы подключаетесь к Redis через redis-cli и выполняете:

KEYS *

— и видите всё, что есть в базе. Однако за этой простотой скрывается серьёзная проблема: команда блокирует основной поток выполнения.
Redis — однопоточная система. Это означает, что все команды выполняются последовательно, одна за другой. Когда вы запускаете KEYS * на инстансе с миллионами ключей, Redis полностью останавливается на время выполнения этой операции. Ни один клиент не сможет прочитать или записать данные, пока сканирование не завершится.
В реальных условиях это может привести к простою сервиса на несколько секунд или даже минут. Представьте, что ваш сайт использует Redis для хранения сессий пользователей, а в пик нагрузки администратор случайно запускает KEYS *. Результат — массовый таймаут API, падение метрик, жалобы пользователей.

Также важно понимать, что KEYS не масштабируется. С ростом количества ключей время выполнения растёт линейно. На тестовой базе из 10 000 ключей команда может отработать за 50 мс, но на 10 млн — уже за 30–60 секунд. Такое поведение делает её неприемлемой для production-сред.
Ещё один нюанс: KEYS * возвращает только ключи из активной базы (по умолчанию DB 0). Если вы используете несколько баз (DB 0–15), нужно переключаться между ними вручную с помощью SELECT, что усложняет процесс и увеличивает риск ошибки.

Безопасная альтернатива: команда SCAN и её реализация

Для решения проблемы блокировки Redis предлагает команду SCAN. В отличие от KEYS, она работает итеративно, возвращая часть ключей за один вызов и указатель на следующую итерацию — cursor.
Синтаксис:

SCAN cursor [MATCH pattern] [COUNT count]

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

SCAN 0 MATCH * COUNT 100

— начинает сканирование с курсора 0, ищет все ключи (шаблон *) и возвращает до 100 элементов за раз.
Работа с SCAN требует цикла:

1. Выполняется SCAN 0, получаем ответ: [next_cursor, keys_list]
2. Если next_cursor != 0, повторяем запрос с новым курсором
3. Цикл продолжается, пока курсор не вернётся к 0

Это позволяет распределить нагрузку во времени. Сервер не блокируется — между итерациями Redis обслуживает другие запросы.

Кроме того, SCAN поддерживает фильтрацию по шаблону через MATCH. Например:

SCAN 0 MATCH user:*

— поможет найти только ключи, связанные с пользователями.
Важно понимать, что SCAN не гарантирует консистентности. Поскольку он работает в течение нескольких тактов, в промежутке могут появиться новые ключи или удалиться старые. Это нормально для большинства сценариев, но критично, если вам нужна точная «моментальная» выборка.
Для автоматизации можно использовать скрипты. Пример на Python:

import redis
r = redis.Redis(host='localhost', port=6379, db=0)
cursor = '0'
keys = []
while cursor != 0:
 cursor, batch = r.scan(cursor=cursor, match='*', count=100)
 keys.extend(batch)

Такой подход легко интегрировать в систему мониторинга или резервного копирования без риска для производительности.

Риски безопасности при получении списка ключей

Возможность просматривать ключи — это не только технический вопрос, но и серьёзная угроза безопасности. Ключи в Redis часто содержат чувствительные данные: токены аутентификации, персональную информацию, внутренние идентификаторы.
Если злоумышленник получит доступ к команде KEYS или SCAN, он сможет:

• Анализировать структуру данных по именам ключей (например, user:123:token или session:abc)
• Выявить уязвимости в логике приложения
• Собрать данные для дальнейших атак, таких как подбор сессий или подмена токенов

Даже если сам Redis защищён паролем, слабый пароль или утечка учётных данных (например, через конфигурационные файлы в Git) могут дать доступ к этим командам.

Кроме того, в Redis нет встроенной роли-based авторизации (до версии 6). Это значит, что любой пользователь с доступом к CLI может выполнять любые команды, включая FLUSHALL или DEBUG SEGFAULT.
Начиная с Redis 6 появилась система ACL (Access Control List), позволяющая ограничивать права пользователей. Например:

ACL SETUSER reader on >password ~readonly:* +@read -DEL -FLUSHDB

— создаёт пользователя с правом только на чтение, но без доступа к удалению или просмотру всех ключей.
Тем не менее, даже с ACL нужно быть осторожным. Разрешение на +KEYS или +SCAN должно выдаваться только доверенным сервисам и администраторам.

Лучшие практики управления ключами в Redis

Чтобы минимизировать риски и обеспечить стабильную работу, придерживайтесь проверенных подходов:

• Никогда не используйте KEYS * в production — только SCAN с разумным COUNT.
• Назначайте осмысленные префиксы — например, cache:product:, session:user:. Это упрощает фильтрацию и анализ.
• Ограничивайте доступ к Redis — через брандмауэр, VLAN, TLS (в Redis 6+) и строгие ACL.
• Не храните чувствительные данные в чистом виде — шифруйте токены, персональные данные, пароли.
• Устанавливайте TTL по умолчанию — чтобы избежать накопления «мёртвых» ключей.

Автоматизация — ключ к безопасности. Вместо ручного доступа используйте скрипты с логированием и ограничениями. Например, скрипт для анализа ключей должен:

1. Работать в off-peak часы
2. Использовать SCAN с COUNT 100
3. Фильтровать по префиксам
4. Логировать начало и завершение операции

Также рекомендуется регулярно проводить аудит ключей: кто их создаёт, как долго живут, насколько часто используются. Инструменты вроде redis-cli --bigkeys помогают находить аномалии.

Для микросервисной архитектуры лучше всего выделить отдельные инстансы Redis на каждый сервис или тип данных. Это снижает риск перекрёстного доступа и упрощает управление.

Мониторинг и аудит: как отслеживать использование команд

Чтобы контролировать, кто и когда использует команды просмотра ключей, необходимо включить аудит и мониторинг.
Redis не имеет встроенного логирования команд по умолчанию, но предоставляет два мощных инструмента:

• SLOWLOG — журнал медленных команд. Если KEYS * попадает в него, это тревожный сигнал.
• MONITOR — режим реального времени, показывающий все входящие команды. Полезен для отладки, но создаёт нагрузку.

На практике лучше использовать внешние решения:

• Prometheus + Exporter для Redis — собирает метрики, включая количество вызовов команд.
• ELK-стек или Loki — для анализа логов, если вы логируете команды через прокси или sidecar.
• Собственные middleware — в приложении можно оборачивать вызовы Redis и логировать подозрительные операции.

Настройте алерты на события:

• Обнаружение команды KEYS
• Резкий рост числа ключей
• Появление ключей с подозрительными префиксами

Также полезно периодически выполнять:

redis-cli INFO commandstats

— чтобы увидеть статистику по использованию команд. Если там есть вызовы KEYS, найдите источник и замените на SCAN.

Заключение

Получение списка ключей в Redis — задача, которая кажется простой, но на деле требует глубокого понимания рисков и архитектурных последствий. Команда KEYS * может вывести из строя весь сервис, а неосторожное управление доступом — привести к утечке данных.

• Команда KEYS * блокирует Redis и опасна в production.
• Используйте SCAN для безопасного, итеративного обхода ключей.
• Ограничьте доступ к командам просмотра через ACL и сетевые правила.
• Не храните чувствительные данные в открытом виде.
• Внедряйте мониторинг и алертинг на подозрительные действия.