Разработчик включает подробный лог запроса и получает работающий поиск по платежам. Через неделю оказывается, что в поиске доступны Authorization и email клиентов. Забор вокруг склада не исправляет привычку складывать ключи от квартир в общий ящик. Защита логов начинается до хранилища.
Три разных задачи
TLS
защищает передачу, а аутентификация отвечает «кто ты». Авторизация отвечает «что тебе можно». Все три нужны между агентом, Logstash, Elasticsearch и Kibana.
Не отключай проверку сертификата ради быстрого подключения. Сертификат должен соответствовать имени сервера, клиент должен доверять его CA. API-ключ не заменяет TLS: перехваченный ключ даёт доступ в пределах своих прав.
Раздели читателя и писателя
| Участник | Нужный доступ |
|---|---|
| агент или Logstash | запись в назначенные потоки |
| дежурный | чтение production-логов и просмотр Kibana |
| разработчик | чтение своих разрешённых окружений |
| администратор схем | шаблоны, lifecycle и управление доступом |
Не выдавай всем superuser. RBAC ограничивает операции и имена источников. Пространства Kibana помогают разделять сохранённые объекты, но сами по себе не заменяют права на индексы Elasticsearch. API-ключи ограничивай сроком и ролью, храни в secrets или keystore, ротируй.
Точные права писателя зависят от того, кто создаёт streams и templates. Если шаблоны заранее устанавливает администратор, писателю не нужно право управлять всеми шаблонами. Проверяй права на настоящем стенде под конкретным аккаунтом, включая ожидаемые отказы.
Не собирай секрет, если он не нужен
Пароли, токены, полные номера карт и тела чувствительных запросов не должны попадать в логгер. Email и адрес клиента тоже требуют цели и срока хранения. Идентификатор заказа часто полезнее полного профиля клиента.
Ниже второй рубеж: Logstash удаляет поля и маскирует известный формат токена. Песочница выполняет преобразование событий, но не проверяет сертификаты, ключи или серверные роли.
Проверь не только password, но и event.original: исходная строка содержит секреты даже после удаления разобранных полей. message тоже может повторять токен. Во второй, обрезанной строке нельзя надёжно удалить поле JSON, поэтому учебный пайплайн заменяет исходный текст безопасным сообщением и оставляет тег ошибки разбора.
Это осознанная потеря содержимого, не доказательство универсальной безопасности. Секрет может попасть в любое новое поле, Unicode-текст или stack trace. Поэтому ограничение полей на стороне приложения и проверка схемы важнее списка регулярных выражений. Для служебного карантина тоже нужны маскирование, отдельные права и короткий срок хранения.
Если утечка уже случилась
- Отзови попавшие в лог ключи: удаление строки не делает токен недействительным.
- Останови источник утечки и ограничь доступ.
- Найди копии в индексах, архиве, snapshots и экспортированных файлах.
- По принятой процедуре удали данные и зафиксируй, кто мог их прочитать.
ILM задаёт срок индексов, но не заменяет экстренную реакцию на утечку. В сквозном примере соберём конвейер уже с этой границей безопасности.
урок из курса
Урок из курса «Elasticsearch и ELK». Курс покупается один раз и остаётся навсегда: 500 ₽.
Оплата пока не подключена: премиум и курсы открываются промокодом.