Безопасность стека логирования

Логи — это концентрат чувствительных данных; защита стека логирования так же важна, как защита прод-базы.

Безопасность стека логирования — комплекс мер (аутентификация, шифрование, разграничение доступа, очистка данных), защищающих и доступ к логам, и сами логи от утечки.

Почему логи опасны

В логах оседает многое: IP пользователей, email, иногда по недосмотру — токены, номера карт, тексты запросов. Централизованное хранилище логов — это огромный агрегат чувствительных данных в одном месте. Незащищённый Elasticsearch с логами — классический источник утечек: их регулярно находят открытыми в интернете без пароля. Безопасность тут не опция.

Аутентификация и роли

Первое правило: никакого доступа без аутентификации. В Elastic Stack есть встроенная система пользователей и ролей. Доступ выдаётся по принципу минимальных привилегий: разработчику — чтение логов своих сервисов, дежурному — чтение всего и управление алертами, аналитику — только Kibana без админки. Роли можно ограничивать вплоть до конкретных индексов и даже полей (field-level security — скрыть поле с email от части пользователей).

  роль "dev-team-a":
    индексы: logs-team-a-*   (только свои)
    права:   read
  роль "on-call":
    индексы: logs-*          (всё)
    права:   read + manage alerts

Шифрование

Логи передаются по сети между Beats, Logstash и Elasticsearch — этот трафик шифруют TLS, иначе логи (включая чувствительные поля) идут открыто и перехватываемы. Так же TLS защищает доступ к Kibana и API ES. На больших инсталляциях включают и шифрование данных на диске.

Очистка чувствительных данных

Лучшая защита данных — не хранить лишнее. На этапе обработки секреты и персональные данные маскируют до попадания в индекс. В Logstash это делают фильтром (вырезать токен, заменить номер карты на маску):

filter {
  mutate {
    gsub => [ "message", "(?<=password=)\S+", "***" ]
  }
}

Принцип: данные, которых нет в индексе, невозможно утечь. Логировать пароли и токены нельзя в принципе — но и страховка маскированием на входе обязательна.

Как работает под капотом: аудит самого стека

Зрелые установки включают аудит доступа к самому Elasticsearch: кто и какие запросы делал к логам. Это важно, потому что доступ к централизованным логам — привилегия, которой можно злоупотребить (например, посмотреть активность конкретного пользователя). Аудит-лог стека — это «логи о том, кто читал логи». Парадоксально, но необходимо для комплаенса и расследования внутренних инцидентов.

Логи как поверхность атаки и как улика

У безопасности логов две стороны, которые легко спутать. Первая — защитить сами логи: ограничить доступ, зашифровать, не дать им утечь, как мы обсудили. Вторая, не менее важная — логи как инструмент безопасности: именно по централизованным логам обнаруживают атаки и расследуют взломы. Всплеск ошибок аутентификации, необычные запросы, доступ из неожиданной географии — всё это видно в логах раньше, чем в чём-либо ещё. Поэтому security-команды строят на ELK так называемый SIEM (систему управления событиями безопасности): те же логи, но с правилами обнаружения угроз и корреляции подозрительных событий. Лог одновременно и ценность, которую надо защищать, и сенсор, который защищает.

Из этой второй роли вытекает требование, противоречащее интуиции эксплуатации: некоторые логи нельзя удалять рано, даже если они занимают место. Логи аудита и безопасности часто обязаны храниться долго именно для расследования инцидентов, которые могут обнаружиться спустя месяцы. Поэтому к ним применяют отдельную ILM-политику с долгим хранением и, главное, защищают от подделки и удаления — атакующий, проникнув в систему, первым делом пытается стереть следы в логах. Логи, которые легко изменить или удалить, бесполезны как улика; здесь надёжность и неизменность важнее экономии диска.

Частые ошибки

• Открытый Elasticsearch. ES без аутентификации, доступный из интернета — готовая утечка. Это одна из самых частых причин публичных сливов данных.
• Незашифрованный трафик Beats → ES. Логи с персональными данными, идущие открыто по сети, перехватываются. Включайте TLS.
• Секреты в логах. Токен в логе попадает в индекс и виден всем, у кого есть доступ. Маскируйте на входе и не логируйте секреты в коде.

Итоги

• Централизованные логи — концентрат чувствительных данных; их защита обязательна, а не опциональна.
• Аутентификация + роли по минимальным привилегиям (вплоть до индексов и полей) ограничивают доступ.
• TLS шифрует трафик Beats → Logstash → ES и доступ к Kibana/API.
• Маскируйте секреты и ПДн на этапе обработки — чего нет в индексе, то не утечёт.