Зашифрованные журналы аудита: что доказывает офлайн-проверка

Зашифрованный журнал аудита может дать внешнему проверяющему полезные свидетельства, не раскрывая ему содержимое ни одной записи. Проверяющий может установить, образуют ли записи шифротекста ожидаемую последовательность, изменилась ли более ранняя запись и на каком месте экспорт впервые перестает соответствовать заявленной истории.

У таких свидетельств есть четкие границы. Корректный результат проверки не доказывает, что каждое утверждение в журнале правдиво, что архив начинается с первого события или что временная отметка отражает реальное время. Команды ослабляют собственную позицию, когда называют все это «целостностью». Это разные утверждения, и для каждого аудитор должен запросить отдельные свидетельства.

Шифротекст может нести след целостности

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

Простая концептуальная цепочка выглядит так:

record_1 = Encrypt(event_1)
link_1   = H(record_1)

record_2 = Encrypt(event_2)
link_2   = H(link_1 || record_2)

record_3 = Encrypt(event_3)
link_3   = H(link_2 || record_3)

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

Проверяющий читает экспортированные записи шифротекста по порядку. Для каждой записи он вычисляет следующую ожидаемую связь по предыдущей принятой связи и текущим байтам шифротекста. Затем он сравнивает полученное значение со связью, сохраненной в текущей или следующей записи, в зависимости от формата. Несовпадение означает, что переданная последовательность не соответствует правилу цепочки.

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

Поэтому аудитор, видящий только шифротекст, может сделать точное утверждение: «При таком правиле цепочки и таком якоре эти зашифрованные записи не изменялись и не перемещались внутри переданной последовательности». Это ценное утверждение. Не превращайте его в заявление о смысле скрытых записей.

Корректная цепочка доказывает непрерывность, но не правдивость

Хеш-цепочка доказывает узкое свойство целостности: последующие связи зависят от ранее сохраненных байтов. Она не доказывает, что программа точно записала действие, что были записаны все действия или что сотрудник не создал чистую, но вводящую в заблуждение историю.

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

• Запись до вызова показывает попытку выполнить действие.
• Запись после вызова может показать, что приложение достигло собственной точки завершения.
• Квитанция на стороне поставщика может показать, что удаленный сервис принял запрос.
• Сетевой захват может показать трафик, но не обязательно раскрывает стоявшее за ним намерение пользователя.

Цепочка не устраняет этот смысловой разрыв. Приложение решает, что утверждает каждая запись. В проекте аудита нужно ясно описать это значение, включая правила записи ошибок, отказов, повторных попыток, отмен и частичных ответов.

Особенно важно это различие после инцидента. Кто-то спросит: «Агент удалил репозиторий?» Расшифрованная локальная запись может сказать, что шлюз действий отправил запрос на удаление. Но сама по себе она не доказывает, что поставщик выполнил запрос. На второй вопрос может ответить событие у поставщика. И наоборот, событие поставщика может доказать факт удаления, но не показать, какой локальный процесс его запросил. Следователям нужно объединять свидетельства, а не считать один журнал полной историей.

Та же проблема возникает с идентичностью агента. Запись может идентифицировать процесс, полномочия подписи кода, сессию или одобрение пользователя. Это разные действующие лица. Если в записи сказано «сессия агента 42», аудитор не должен переписывать это как «это сделала Алиса», если отдельные записи не связывают одобрение Алисы с этой сессией. Цепочка сохраняет байты, но не исправляет слишком широкую трактовку этих байтов.

Первая доверенная точка определяет пределы доказательства

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

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

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

log identity: agent-actions-prod
checkpoint sequence: 18427
checkpoint digest: 7f...c2
record format version: 3
hash algorithm: SHA-256
checkpoint captured by: release-control process
checkpoint captured at: 2025-03-08T18:20:00Z

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

Контрольные точки позволяют проверять не весь архив, а отдельный интервал. Если аудитор доверяет точке на последовательности 18 427 и получает записи до 19 100, проверяющий может установить, что более поздний сегмент происходит от доверенной точки. Так предел утверждения ограничивается указанным окном, вместо того чтобы делать вид, будто журнал имеет непрерывную историю со дня установки.

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

Поля времени остаются утверждениями, пока их не закрепит независимая сторона

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

Команды часто путают последовательность со временем. Цепочка может установить, что запись 108 следует за записью 107 по правилам цепочки. Но она не доказывает, что запись 108 произошла в 09:17 UTC, лишь потому что в ней есть такой текст. Даже монотонные счетчики имеют ограничения: они показывают порядок в одном журнале, но не говорят, сколько физического времени прошло между записями.

Если аудиту нужно надежное время, привяжите контрольные точки к источнику, который автор не контролирует. Дополнительные свидетельства могут дать независимый сервис отметок времени, квитанция удаленного сервиса или отдельно администрируемый сборщик событий. Каждый вариант выражает свое доверительное утверждение. Независимая временная отметка говорит, что другая сторона увидела обязательство не позднее указанного времени. Квитанция удаленного сервиса говорит, что этот сервис увидел запрос или результат. Ни то ни другое не делает локальный текст события истинным само по себе.

RFC 3161 описывает протокол отметок времени, при котором служба отметок возвращает подписанный токен для отпечатка сообщения, обычно хеша. Для зашифрованных журналов важен именно отпечаток сообщения. Служба может поставить отметку на дайджесте контрольной точки, не получая зашифрованные записи или ключи их расшифровки. Но важно помнить об ограничении: токен связывает дайджест с заявленным службой временем. Он не проверяет скрытые записи, не оценивает их смысл и не доказывает, что переданный дайджест представляет полный архив.

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

Офлайн-проверка должна сохранять исходные байты свидетельства

Офлайн-проверяющий анализирует байты, а не удобное для человека отображение этих байтов. Аудит-команда может испортить корректное свидетельство, открыв экспорт в редакторе, изменив окончания строк, повторно сериализовав JSON, обрезав файл при копировании или объединив сегменты в неправильном порядке.

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

Процесс проверки должен разделять сбор, проверку целостности и доступ к содержимому:

1. Сохраните зашифрованный экспорт и вычислите дайджест файла для реестра свидетельств.
2. Получите нужную доверенную контрольную точку по документированному независимому каналу, а не из заметки внутри того же экспорта.
3. Запустите проверяющий инструмент для нетронутой рабочей копии и сохраните код завершения и вывод.
4. Если проверка прошла, решите, нужна ли расшифровка. Если нужна, предоставьте доступ по отдельной процедуре.
5. Если проверка не прошла, прекратите редактирование и сохраните и неудачную копию, и заявленную контрольную точку.

Именно на третьем шаге важен результат командной строки. На компьютере с установленными инструментами командной строки Sallyport аудитор может выполнить:

sp audit verify

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

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

Разорванная связь показывает, где искать, но не кто это сделал

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

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

Характер сбоя может сузить круг причин:

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

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

Хорошо спроектированный проверяющий инструмент должен сообщать достаточно сведений для расследования, не раскрывая зашифрованное содержимое. Обычно достаточно номера последовательности, смещения записи, ожидаемого дайджеста, наблюдаемого дайджеста и версии формата. В отчет не стоит выводить шифротекст, если он попадет в систему задач или переписку. Шифротекст может быть нечитаемым без ключей, но обращаться с ним все равно нужно осторожно: при утечке ключей он может стать чувствительным.

Для удаления и обрезания нужны разные меры защиты

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

Представим архив с записями с 1 по 500. Злоумышленник удаляет записи с 451 по 500 и передает аудитору записи с 1 по 450. Первые 450 записей могут пройти проверку идеально. У цепочки нет будущей записи, указывающей на 451, поэтому проверяющему нужно внешнее ожидание того, что история должна продолжаться.

Такое ожидание может исходить из контрольной точки на записи 500, подписанного ежедневного количества, внешней системы, знающей последний номер последовательности, или процесса хранения, фиксирующего завершенные диапазоны экспорта. Полезное утверждение будет конкретным: «Архив содержит все записи до последовательности 500». Одна цепочка поддерживает лишь утверждение: «Переданный архив согласован до последовательности 450».

Удаление до первой переданной записи создает ту же проблему. Если аудитор получает цепочку, начинающуюся с записи 200, он не может понять, существовали ли когда-либо записи с 1 по 199. В формате экспорта нужно указать, является ли он полным архивом от начала до текущего момента или ограниченным сегментом. Для ограниченных сегментов нужна начальная контрольная точка. Полным архивам все равно нужны доверенное начальное значение или внешнее обязательство, если противник может заменить весь файл.

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

Здесь защищенный от изменений след отличается от утверждения о хранилище с однократной записью. След дает проверяющему возможность обнаружить определенные изменения. Хранилище с однократной записью пытается не допустить изменения с помощью контроля доступа или особенностей хранения. Надежные программы аудита используют оба подхода и проверяют оба. Если считать одно доказательством другого, в защите останется пробел, через который может провалиться расследование инцидента.

Проверяющий должен знать формат, а не угадывать его

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

Не используйте входные данные для хеша, зависящие от удобного отображения. Порядок полей объекта JSON, пробелы, нормализация Unicode и необязательные поля могут различаться в разных реализациях при одинаковом видимом объекте. Если цепочка охватывает сериализованный JSON, определите каноническую сериализацию и протестируйте ее в реализациях на разных языках. Еще лучше связывать бинарный конверт с явными длинами полей и байтами версии.

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

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

Публикация Национального института стандартов и технологий FIPS 180-4 определяет семейство SHA-2 и хеш-функцию над последовательностью битов, а не над намерением приложения. Эта сухая деталь содержит практическое предупреждение. Свойство целостности относится ровно к входным байтам. Команды, говорящие «мы хешируем событие», часто еще не решили, хешируют ли они строку UTF-8, строку базы данных, сжатый объект или зашифрованный конверт. Пока это не определено, воспроизводимой аудиторской проверки нет.

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

Журналам агентов нужны два уровня свидетельств

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

Запись сессии отвечает на вопросы о процессе, подключившемся к шлюзу действий, полномочиях подписи кода этого процесса, времени одобрения запуска человеком и времени отзыва оператором. Запись действия отвечает на вопросы о конкретном запросе HTTP или SSH, выполненном шлюзом. У одного запуска может быть одно одобрение и много записей действий. Проверяющий, видящий только след сессии, не может вывести из него все внешние эффекты, а видящий только записи действий может не понять, почему процесс имел полномочия.

Sallyport хранит журнал Sessions и журнал Activity, построенные из одного защищенного от записи, зашифрованного журнала аудита с хеш-цепочкой. Такое устройство дает аудитору два представления одной защищенной истории и сохраняет единственный след целостности для проверки.

Термин «защищенный от записи» требует точности. Он означает, что компонент, добавляющий свидетельства аудита, не должен иметь удобного способа читать и переписывать старые записи в рамках обычной работы. Это не значит, что автор журнала не способен создавать ложные утверждения. Скомпрометированный агент может запросить вредоносные действия. Скомпрометированный шлюз может записывать неверные данные, сохраняя математически корректную цепочку. Такая конструкция снижает один класс риска перезаписи, но не отменяет необходимость целостности программного обеспечения, одобрения сессии, одобрения действий при необходимости и сравнения с данными удаленной системы.

Для действий HTTP сохраняйте достаточно защищенных метаданных, чтобы различать назначение, метод, ссылку на учетные данные, контекст одобрения, класс результата и идентификатор корреляции, не помещая в запись секретные материалы. Для действий SSH различайте целевой хост, границу команды, контекст сессии и результат. Зашифрованная запись может хранить эти детали для уполномоченных следователей. Офлайн-проверяющему они не нужны, чтобы установить изменение последовательности.

Так команды могут передать пакет целостности специалисту по безопасности, у которого нет постоянного разрешения просматривать рабочие секреты. Это также делает расследование спокойнее. Сначала установите, сохранилось ли переданное свидетельство в исходном виде. Затем предоставьте минимально необходимый доступ к расшифровке, чтобы истолковать события.

Утверждение аудита должно соответствовать доступным свидетельствам

Полезный аудиторский отчет описывает границы простым языком. В нем указаны экспортированный сегмент, формат цепочки, версия проверяющего инструмента, источник контрольной точки, результат проверки и оставшиеся ограничения. Такой отчет может звучать менее эффектно, чем «журналы неизменяемы», зато выдерживает техническую проверку.

Используйте формулировки вроде: «Проверяющий инструмент принял записи с 18 428 по 19 100 как непрерывную цепочку шифротекста, основанную на контрольной точке 18 427, которую процесс release-control сохранил отдельно». Это утверждение говорит ровно то, что подтверждают свидетельства. Если у команды есть подписанная внешняя временная отметка, укажите это отдельно. Если выбранные действия сравнивались с событиями поставщика, тоже скажите об этом отдельно.

Избегайте фраз «ничего не удаляли», если такое утверждение не подтверждается закрепленной конечной контрольной точкой или другим независимым источником. Не говорите «агент сделал это», когда свидетельство идентифицирует только локальный процесс. Не говорите «в это точное время», если единственными часами были часы проверяемого хоста. Это не формальности для юристов. От этих различий зависит, сможет ли другой инженер воспроизвести ваш вывод, когда расследование станет сложным, а всем захочется простого ответа.

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