logmeobf: обфускация логов

logmeobf легко неправильно понять по названию. Можно решить, что это отдельная утилита, которую нужно регулярно запускать над готовыми текстовыми логами: сначала приложение пишет app.log, потом logmeobf превращает его в app.logobf.

Это не основной сценарий работы.

В обычной конфигурации logme обфусцирует запись сразу в момент записи файла. Приложение передает библиотеке ключ, а FileBackend вместо обычного text, JSON или XML record пишет бинарную obfuscated record. Лог-файл с самого начала не содержит readable text.

Утилита logmeobf в таком сценарии нужна в первую очередь не для обфускации, а для работы с ключом и последующей деобфускации файла при диагностике.

Именно поэтому logmeobf правильнее воспринимать как companion tool для obfuscated logs, а не как отдельный post-processing encryptor.

Основной workflow

Работа начинается с создания ключа:

logmeobf --generate-key --key-out logme.key

Это создает 32-байтный obfuscation key. Его нужно хранить отдельно от самих логов и выдавать только тем, кому действительно требуется читать диагностические данные.

Дальше приложение получает этот ключ своим способом: из защищенного файла, environment configuration, secret storage или другой внутренней схемы загрузки ключей. Затем ключ передается logme до начала записи логов:

ObfKey key = /* load key before logging starts */;
Logme::Instance->SetObfuscationKey(&key);

После вызова SetObfuscationKey() file backend меняет поведение. Когда logme готов записать очередное сообщение в файл, он не добавляет туда readable text напрямую. Вместо этого он обфусцирует record и записывает бинарное представление.

То есть при такой конфигурации рабочий файл уже выглядит примерно так:

app.log

но его содержимое не является обычным text log. Его нельзя открыть в Notepad, less, tail или браузере и прочитать сообщения.

Когда нужно исследовать проблему, используется logmeobf:

logmeobf --deobfuscate \
  --key-file logme.key \
  --in app.log \
  --out app-readable.log

После этого app-readable.log можно открыть обычными средствами и передать инженеру, у которого есть право читать эти данные.

Именно это типичный production workflow:

application -> logme FileBackend -> obfuscated log file
                                     |
                                     v
                            logmeobf --deobfuscate
                                     |
                                     v
                              readable diagnostic log

Что делает библиотека во время записи

Обфускация — часть file output path, а не отдельная фоновая задача.

Когда FileBackend получает уже сформированную строку лога, он проверяет, установлен ли в Logger obfuscation key. Если ключа нет, backend записывает обычные bytes. Если ключ установлен, backend превращает конкретную запись в binary obfuscated record и только затем передает ее в файловый путь.

Это важно по двум причинам.

Во-первых, plaintext log не лежит на диске даже временно. Нет фазы, где приложение сначала пишет обычный файл, а потом отдельная утилита должна успеть его обработать.

Во-вторых, не возникает отдельного процесса, который должен следить за новыми файлами, догонять rotation, ждать закрытия файла или обрабатывать частично записанные логи.

Обфускация работает в том же жизненном цикле, что и обычная file logging: запись, rotation, retention, compression и прочие механизмы backend-а остаются частью одной системы.

При этом важно не переоценивать область действия. Обфусцируется именно file output. Если то же сообщение одновременно идет в console backend, debugger backend, callback backend или другой destination, этот output не становится автоматически скрытым. Для каждого output path нужно отдельно понимать, где именно может оказаться readable text.

Зачем тогда нужен —obfuscate

Режим:

logmeobf --obfuscate \
  --key-file logme.key \
  --in old-readable.log \
  --out old-readable.logobf

существует, но это не основной рабочий путь.

Он полезен, когда уже есть старые readable logs и их нужно перевести в obfuscated format. Например, при миграции на logme obfuscation, при переносе диагностических архивов или при создании тестовых данных для проверки совместимости формата.

Но для новых файлов лучше не создавать readable log вообще. Проще и безопаснее установить ключ в приложении и позволить FileBackend обфусцировать записи сразу при их появлении.

Почему эта возможность называется обфускацией, а не encryption

Внутри logme использует 32-байтный ключ и ChaCha20-based reversible transformation для отдельных records. Без ключа файл не читается как обычный текст, а содержание записей нельзя восстановить штатным образом.

Но продуктовая формулировка “обфускация” здесь намеренно осторожная.

logme решает задачу скрытия содержимого логов в файловом output path. Он не предоставляет полноценную инфраструктуру encryption at rest. Он не занимается жизненным циклом ключей, их безопасной доставкой, аудитом доступа, политиками ротации ключей, распределением прав или доказательством неизменности архива.

Особенно важна целостность. Obfuscated log не является authenticated audit log. Механизм не предназначен для доказательства того, что записи никто не удалял, не переставлял и не подменял. Поэтому его нельзя использовать как единственную защиту для forensic storage, финансовых журналов или security audit logs, где нужна проверяемая неизменность данных.

То есть правильная формулировка такая: logme скрывает содержимое file logs без ключа, но не заменяет полноценную систему защищенного хранения.

Что остается видно

После включения obfuscation содержимое сообщений перестает быть readable text. Однако файл все равно содержит техническую структуру, необходимую для чтения records.

Поэтому по нему могут быть видны общий размер, примерная интенсивность логирования, порядок записей и их размеры. Также можно определить, что файл использует logme obfuscated format.

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

Ключ — главная граница доступа

Если у человека есть доступ к файлу, но нет ключа, он не сможет просто открыть лог и прочитать сообщения. Если у него есть и файл, и ключ, он сможет выполнить logmeobf --deobfuscate.

Поэтому ключ важнее самого формата.

logmeobf умеет создать header с ключом:

logmeobf --generate-key \
  --header logme_obf_key.h \
  --name LOGME_OBFUSCATION_KEY

Это удобно для тестов, локальных инструментов и закрытых сценариев. Но для production нужно понимать последствия: ключ, встроенный в source tree или binary, доступен тому, кто может получить эти артефакты.

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

Не путайте logmeobf и OBF

В logme есть еще один механизм с похожим названием:

LogmeI(OBF("internal endpoint: %s"), endpoint);

OBF(...) обфусцирует string literal внутри application binary. Он помогает скрыть format strings от простого просмотра executable.

logmeobf решает другую задачу: он работает с log output и обфусцирует записи, которые попадают в файл.

Они могут использоваться вместе. OBF(...) уменьшает количество читаемых строк в binary, а logme file obfuscation убирает readable text из log files. Но ни один из этих механизмов не заменяет защиту process memory, secrets management, disk encryption или полноценную систему key management.

Когда logmeobf полезен

logmeobf хорошо подходит для production diagnostics, support bundles, локальных log directories и тестовых серверов, где plain text logs не должны быть доступны каждому, у кого есть доступ к рабочей папке.

Он особенно удобен именно потому, что не требует отдельного post-processing pipeline. Приложение пишет obfuscated records сразу. При необходимости инженер деобфусцирует конкретный файл отдельной утилитой и работает с readable copy.

Это снижает риск случайной передачи plain text логов, но сохраняет обычный operational workflow для команды поддержки.

Итог

Главная идея logmeobf проста: в обычной конфигурации лог не обфусцируется после записи. Он вообще не появляется на диске в readable виде.

Приложение устанавливает key через SetObfuscationKey(), а FileBackend обфусцирует каждую запись перед записью в файл. Затем logmeobf используется для генерации ключей и, чаще всего, для деобфускации нужных логов во время диагностики.

--obfuscate полезен для старых файлов и миграции, но не является основным production workflow.

При этом logmeobf нужно позиционировать честно. Это защита содержимого логов от случайного чтения и дополнительный слой безопасности. Это не готовая encryption-at-rest платформа, не tamper-proof audit format и не замена правильному хранению ключей.