Журнал доступа к прокси: что фиксировать для аудита
Прикладной журнал должен позволять восстановить последовательность действий: кто, когда, над каким объектом и с каким результатом действовал. Сырые секреты для этого не нужны.
Главное за минуту
- Событие должно иметь стабильный correlation ID.
- Доступ к журналу и его экспорт сами являются аудируемыми действиями.
- Системные поля аудита версионируются и не заменяются свободным текстом.
- Исправление журнала оформляется новым связанным событием.
Минимальный состав
Записывайте время в едином формате, actor, действие, объект, исход, источник запроса, correlation ID и версию команды.
Используйте версионируемую схему события: event ID, UTC timestamp, actor type и actor ID, tenant ID, action, resource type/ID, outcome, reason code, request/correlation ID и источник интерфейса. IP и User-Agent включайте только при определённой цели и уровне доступа. Свободный текст администратора отделяйте от системных полей, чтобы поиск и экспорт оставались однозначными.
Что исключить
Не храните пароли, Proxy-Authorization, cookies, API-токены и рабочие ссылки смены IP. Чувствительные значения маскируйте до записи.
Создайте централизованный redaction-фильтр и тесты с контрольными значениями для паролей, Authorization, cookies, API-ключей, платёжных реквизитов и подписанных ссылок. Маскирование после записи недостаточно: секрет уже мог попасть в резервную копию или внешнюю систему. Не помещайте чувствительные значения в exception message; используйте код ошибки и безопасный идентификатор объекта.
Целостность
Ограничьте изменение и удаление, синхронизируйте время и отделите аудит от обычного debug-лога. Экспорт снабжайте контрольной суммой.
Аудит храните в append-only потоке с ограниченными правами сервисного аккаунта. Периодически рассчитывайте контрольную сумму выгрузки и проверяйте непрерывность event ID или цепочки, а часы синхронизируйте на всех узлах. Администратор не должен редактировать исходное событие: исправление оформляется новым связанным событием. Недоступность хранилища требует явного безопасного режима и алерта.
Срок хранения
Срок определяется целью, законом и договором. По окончании цели данные удаляют или обезличивают по утверждённой процедуре.
Составьте матрицу retention по категориям: безопасность, договор, платежи, поддержка и техническая диагностика. Для каждой укажите цель, основание, срок, владельца и способ удаления или обезличивания, включая backups. Конкретные сроки проверяйте по актуальным требованиям и договорам с ответственным специалистом. Legal hold оформляйте отдельно и снимайте документированным решением, а не бессрочно.
Практический чек-лист
- 1Опишите обязательные поля события.
- 2Добавьте маскирование до записи.
- 3Проверьте восстановление временной линии.
- 4Протестируйте redaction контрольными секретами.
- 5Проверьте удаление данных из backups.
Источники и документы
Материал подготовлен по первичным, официальным и техническим источникам. Формулировки статьи являются самостоятельным изложением.
Материал носит справочный характер. Требования необходимо сверять с актуальной редакцией закона и, при необходимости, с профильным специалистом. Это не индивидуальная юридическая консультация.