Чтение хеш-сцепленного журнала изменений и его самостоятельная проверка

Что содержит одна строка

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

Когда и кто

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

Где и что

Поверхность, на которой сделано изменение. Совершённое действие. Цель, на которую оно подействовало. Семантический слой, ретранслятор, ключи провайдеров, запуски скриптов и консоль администратора пишут сюда все.

Состояние в виде хешей

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

Связь

Хеш предыдущей записи и собственный хеш этой записи. Эти два поля и есть цепочка.

Детали

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

Он стоит рядом с аудиторским следом оператора, а не заменяет его. Две записи, два читателя. Аудиторский след это история консоли, которую администратор просматривает в течение недели. Журнал это то, что кто-то читает через год, ничего из этого не помня.

Что доказывает цепочка

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

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

Назвать первую испорченную строку это большая часть ценности. «Где-то в пятидесяти тысячах строк что-то не так» это тревога. «Строка 8 214, несовпадение хеша» это отправная точка. Это ещё и ограничивает вопрос, потому что всё до неё прошло проверку.

Функция это простой SHA-256 без секретного ключа. Это осознанный компромисс. Конструкция с ключом доказывала бы, что запись исходит от нас. Конструкция без ключа позволяет любому, у кого есть экспорт, проверить его тридцатью строками собственного скрипта. Для аудитора это несравненно более полезное свойство.

Вопросы к другим контролям

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

• Было ли изменение вообще записано. Цепочка ничего не говорит о записи, которая никогда не была написана. Записи сериализованы и только добавляются. Неудавшаяся запись громко журналируется и ничего не возвращает, не прерывая действия администратора. Это правильный компромисс для живой консоли. Но это значит, что полнота держится на пути записи, а не на цепочке. Спросите, что происходит при сбое записи и как вы об этом узнаете.
• Каким на самом деле было изменение. «До» и «после» это хеши содержимого. Журнал подтверждает, что состояние изменилось и что оно совпадает с состоянием, которое у вас уже есть. Прочитать старое значение обратно из хеша невозможно, хеш на это не способен. Именно поэтому секреты можно полностью держать вне журнала.
• Был ли переписан весь файл. Цепочка без ключа обнаруживает частичную правку. Тот, кто способен переписать каждую строку, мог бы пересчитать каждую связь. На это отвечают путь записи только с добавлением и права на файл. И прежде всего копии, которые уже держит кто-то другой.
• Перезапускалась ли цепочка. Если хвост не удаётся прочитать при старте, добавление продолжается от генезисной связи. Проверка помечает стык и никогда его не сглаживает. У разорванной связи на границе перезапуска обычно скучное объяснение. Вопроса она всё равно заслуживает.

Вендор, который охотно отвечает на все четыре, полезнее того, который говорит, что цепочка их покрывает.

Самостоятельная перепроверка экспорта

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

1. Начните с предыдущего хеша из шестидесяти четырёх нулей.
2. Для каждой строки по порядку скопируйте объект и удалите его поле хеша записи.
3. Сериализуйте оставшееся как JSON. Отсортируйте ключи, не оставляйте пробелов между токенами и экранируйте символы вне ASCII.
4. Допишите предыдущий хеш к этому тексту. Закодируйте результат в UTF-8. Возьмите дайджест SHA-256 в шестнадцатеричном виде строчными буквами.
5. Сравните его с записанным хешем записи. Сравните записанный предыдущий хеш строки с тем, что вы принесли. Затем перенесите собственный хеш этой строки дальше.
6. Остановитесь на первой строке, где одно из сравнений не сходится. Запишите её индекс и то, какое сравнение не сошлось.

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

Сохраните скрипт. Проверка, которую можно запустить снова по требованию, это контроль. Проверка, которую кто-то однажды выполнил на совещании, это анекдот.

Почему экспорт уходит дальше

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

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

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

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

Рутина, которую можно повторять

1. В конце каждого периода экспортируйте полный диапазон в JSON. Не применяйте фильтры.
2. Проверьте его собственным скриптом и храните экспорт и скрипт вместе.
3. Сравните новый экспорт с предыдущим. Каждая общая строка должна быть идентична, символ в символ. Это та проверка, которая ловит переписывание, которое одна цепочка оставляет открытым.
4. Выборочно проверьте несколько строк по изменениям, которые кто-то помнит. Проверьте участника и роль, записанные рядом.
5. Храните каждый экспорт там, где у продукта нет доступа на запись.
6. Записывайте, кто его снял и когда, рядом с файлом, а не в отдельной системе.

Третий шаг превращает самосогласованный файл в проверенный. Он стоит одной команды сравнения. Всё остальное на этой странице это подготовка к её запуску.