Кто видел этот секрет? Почему аудит-логи важнее, чем вы думаете

Вам приходит уведомление в 3 часа ночи. Кто-то использовал учетные данные от production-базы данных, чтобы выполнить разрушительный запрос. Ущерб уже нанесен. Первый вопрос, который вы задаете — не «как они проникли?», а «у кого был доступ к этому паролю?».

Если ваша команда не может ответить на этот вопрос в течение нескольких минут, у вас проблема, которую не решить никаким шифрованием или ротацией. Без аудит-логов вы действуете вслепую. Секрет мог утекать неделями, и у вас не было бы способа узнать, была ли это внешняя атака или кто-то из вашей команды.

Камера видеонаблюдения для ваших секретов

Представьте аудит-логи секретов как камеру видеонаблюдения на входе в здание. Каждый раз, когда кто-то или что-то запрашивает секрет, хранилище фиксирует, кто сделал запрос, какой секрет был запрошен, точное время и откуда пришел запрос. Эта запись называется журналом аудита.

Критическое правило: обычные пользователи не могут отключить или удалить эти логи. Только администраторы со специальными привилегиями имеют на это право. Если бы пользователи могли стирать историю своего доступа, вся система аудита стала бы бесполезной. У вас были бы логи, показывающие только то, что люди хотят, чтобы вы видели.

Что должен фиксировать каждый журнал аудита

Полезный журнал аудита должен содержать как минимум четыре элемента информации:

Кто получил доступ. Это может быть имя пользователя, сервисный аккаунт или имя приложения. Вам нужно точно знать, какая именно сущность сделала запрос, а не просто «кто-то из бэкенд-команды».

Какой секрет был запрошен. Записывайте имя или путь к секрету, а не его значение. Вам не нужно хранить фактический пароль в логе. Достаточно знать, что был запрошен «пароль от production-базы данных».

Когда это произошло. Временные метки должны иметь точность до секунды. При расследовании инцидента разница в несколько минут может полностью изменить картину. Доступ был получен за пять минут до инцидента или через пять минут после?

Результат. Запрос выполнен успешно или отклонен? Если отказано, то почему? Неудачная попытка доступа может быть так же важна, как и успешная. Она может указывать на то, что кто-то проверяет украденные учетные данные.

Современные хранилища, такие как HashiCorp Vault, AWS Secrets Manager и Azure Key Vault, предоставляют такие логи «из коробки». Логи можно отправлять в SIEM-систему или централизованное хранилище логов, например Elasticsearch. Важно не то, где хранятся логи, а то, кто может их читать. Команды безопасности и реагирования на инциденты должны иметь доступ на чтение. Обычным разработчикам обычно не нужно просматривать журнал аудита.

Вот как выглядит реальная запись аудит-лога из HashiCorp Vault:

{
  "time": "2025-03-15T02:34:12.847Z",
  "type": "response",
  "auth": {
    "client_token": "hmac-sha256:abc123...",
    "display_name": "deploy-bot",
    "policies": ["deploy", "default"]
  },
  "request": {
    "path": "secret/data/production/db-password",
    "operation": "read",
    "remote_address": "10.0.1.42"
  },
  "response": {
    "data": {
      "data": null
    },
    "warnings": null
  }
}

Чтение логов требует практики

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

Рассмотрим сценарий: ваш аудит-лог показывает, что аккаунт «deploy-bot» обратился к секрету «db-production-password» в 2:34 ночи. Это нормально? Зависит от обстоятельств. Если ваш пайплайн выполняет ночные деплои, такой доступ ожидаем. Но если в эту ночь не было запланированного деплоя, нужно задавать вопросы. Возможно, кто-то вручную запустил пайплайн. Или же учетные данные deploy-bot были скомпрометированы.

Вот несколько подозрительных паттернов, которые часто встречаются в аудит-логах:

  • Многократный доступ к одному и тому же секрету за короткий промежуток времени
  • Доступ с IP-адреса, который не входит в обычный диапазон вашей команды
  • Разработчик, который обычно работает только с секретами staging-окружения, внезапно запрашивает production-учетные данные
  • Доступ к секретам из окружений, не соответствующих роли пользователя

Последний пункт — самый коварный. Иногда разработчику действительно нужен доступ к production для срочного исправления. Но если это происходит регулярно без объяснения причин, это может указывать на злоупотребление. Аудит-лог дает вам данные для такого разговора.

Аудит-логи помогают и при восстановлении

Когда вы подозреваете, что секрет скомпрометирован, аудит-логи показывают, насколько далеко распространился ущерб. Вы можете точно увидеть, какие именно сущности запрашивали этот секрет в определенном временном окне. Это помогает расставить приоритеты при ротации. Если только один сервисный аккаунт обращался к скомпрометированному секрету, вам нужно сменить учетные данные только для него. Если же его запрашивали двадцать разных пользователей и приложений, объем работы по зачистке будет гораздо больше.

Без аудит-логов вам придется предполагать худшее и ротировать всё. Это создает лишнюю работу и простои. С аудит-логами вы ротируете только то, что действительно нужно.

Практический чек-лист для аудит-логов секретов

Если вы настраиваете управление секретами сегодня, вот краткий чек-лист для проверки покрытия аудита:

  • Каждый доступ к секрету логируется с указанием сущности, имени секрета, временной метки и результата
  • Логи не могут быть удалены или изменены обычными пользователями
  • Аудит-логи отправляются в централизованное хранилище, к которому команды безопасности могут выполнять запросы
  • У вас есть процесс периодического просмотра логов, а не только во время инцидентов
  • Вы знаете, как выглядят нормальные паттерны доступа для каждого окружения

Суть

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