Аудит-логирование backend-приложений¶

Требования этого документа применяются к аудиту действий, значимых для безопасности и бизнеса. Аудит-лог не заменяет диагностический лог, трассировку или сбор ошибок. Уровни обязательности определены в корневом README.md.

OBS-AUD-001. Явный перечень аудируемых событий¶

Уровень: MUST

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

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

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

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

Обоснование¶

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

Проверка¶

review модели угроз и перечня событий;
тест каждого события;
сопоставление перечня с API и обработчиками сообщений.

Исключения¶

Исключение события требует утверждённого ADR и оценки риска.

OBS-AUD-002. Отдельная классификация аудит-записей¶

Уровень: MUST

Применяется к: каждой аудит-записи

Аудит-запись должна быть JSON-объектом в одну строку и передаваться через stdout или stderr в Vector. Поле telemetry.type должно иметь значение audit, позволяющее Vector направить запись в отдельный логический stream и применить отдельные права доступа и срок хранения.

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

Обоснование¶

Аудит имеет отдельные требования к доступу, целостности, хранению и полноте.

Проверка¶

интеграционный тест маршрутизации Vector;
проверка отдельного stream и прав доступа в OpenObserve;
тест независимости от уровня диагностического логирования.

Исключения¶

Другой защищённый транспорт возможен только через утверждённый ADR.

OBS-AUD-003. Обязательные поля аудит-события¶

Уровень: MUST

Применяется к: каждой аудит-записи

Запись должна содержать:

timestamp в UTC в формате RFC 3339 с долями секунды;
уникальный event.id;
event.name и event.schema_version как положительное целое число;
service.name, service.version и deployment.environment.name;
actor.type и actor.id либо actor.type со значением anonymous;
action и object.type;
object.id, если его хранение разрешено;
result со значением success или failure;
failure.reason с нормализованной причиной для неуспешного результата;
source.address в разрешённой политикой обработки форме, если источник известен;
trace_id, span_id, request_id и correlation_id, когда они доступны.

Формат и семантика идентификаторов корреляции должны соответствовать OBS-LOG-004. Поля должны быть типизированы и иметь стабильную семантику. Обязательное строковое поле не должно быть пустым или состоять только из пробельных символов. При actor.type: anonymous поле actor.id должно отсутствовать. При result: success поле failure.reason должно отсутствовать.

Обоснование¶

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

Проверка¶

валидация схемы;
contract-тест каждого типа события;
запрос в OpenObserve на отсутствие обязательных полей.

Исключения¶

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

OBS-AUD-004. Содержание изменения¶

Уровень: MUST

Применяется к: операциям изменения состояния

Запись должна идентифицировать тип изменения. Если необходимо фиксировать изменённые поля, должны сохраняться их имена и безопасные представления предыдущего и нового состояния по allowlist.

Полный снимок объекта и произвольная сериализация входных данных запрещены.

Обоснование¶

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

Проверка¶

review схемы события и allowlist;
тест изменения одного и нескольких полей;
security review сохраняемых значений.

Исключения¶

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

OBS-AUD-005. Защита данных¶

Уровень: MUST

Применяется к: всем аудит-записям

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

Фильтрация должна выполняться до вывода записи приложением.

Обоснование¶

Длительное хранение и повышенная доступность аудит-данных увеличивают последствия утечки.

Проверка¶

автоматические тесты схемы и маскирования;
security review;
контролируемое сканирование stream аудита.

Исключения¶

Секреты, аутентификационные данные и полные платёжные данные — без исключений. Персональные данные возможны только по утверждённой политике и цели обработки.

OBS-AUD-006. Корректность результата¶

Уровень: MUST

Применяется к: аудируемым операциям

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

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

Обоснование¶

Преждевременная запись создаёт ложный след, а неатомарная отправка оставляет необнаружимые пробелы.

Проверка¶

тест отката, crash и частичного отказа;
тест отказа фиксации обязательного аудит-события;
проверка соответствия фактического и записанного результата.

Исключения¶

Для события, не являющегося обязательным доказательством операции, допускается неатомарная отправка при явной классификации гарантии доставки и обнаружении потери по OBS-AUD-009.

OBS-AUD-007. Неизменяемость и доступ¶

Уровень: MUST

Применяется к: хранению и просмотру аудит-записей

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

Просмотр и административные действия над аудит-данными сами должны оставлять аудит-след.

Обоснование¶

Аудит, который может изменить проверяемый субъект, не является надёжным доказательством.

Проверка¶

проверка ролей в Vector и OpenObserve;
тест запрета изменения приложением;
тест аудита доступа к данным.

Исключения¶

Удаление по утверждённой политике хранения или обязательному требованию выполняется контролируемым платформенным процессом и само протоколируется.

OBS-AUD-008. Время, порядок и дубликаты¶

Уровень: MUST

Применяется к: формированию и обработке аудит-записей

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

Если для одного объекта требуется порядок, событие должно содержать монотонную версию объекта или иной определённый проектом признак последовательности.

Обоснование¶

В распределённой системе часы расходятся, а доставка может повторяться и менять порядок.

Проверка¶

тест повторной и переставленной доставки;
мониторинг рассинхронизации времени;
тест версии объекта для упорядочиваемых событий.

Исключения¶

Не допускаются для уникального идентификатора события.

OBS-AUD-009. Хранение и контроль полноты¶

Уровень: MUST

Применяется к: платформе аудит-логирования

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

Sampling, rate limit и отбрасывание по уровню логирования для аудит-событий запрещены. Нарушение доставки должно формировать операционное оповещение.

Для критичных событий буферы Vector и промежуточного транспорта должны переживать restart в пределах установленной платформой гарантии. Если такая гарантия недоступна, проект должен использовать атомарную фиксацию намерения по OBS-AUD-006.

Обоснование¶

Неконтролируемая потеря событий уничтожает доказательную ценность аудита.

Проверка¶

review политики хранения;
тест заполнения буфера и недоступности OpenObserve;
тест оповещения о разрыве и ошибке маршрутизации;
периодическая сверка полноты критичных событий.

Исключения¶

Не допускаются для запрета sampling и незаметного отбрасывания.