Сделайте его append-only и неизменяемым, сцепите каждую запись с предыдущей через хеш, чтобы фальсификация была обнаружима, партиционируйте по времени, чтобы старые данные дёшево устаревали, и архивируйте запечатанные партиции в WORM объектное хранилище (write-once) с политикой retention — никогда не допускайте / на живых записях.
UPDATEDELETEservice ──emit event──▶ append-only writer
│ hash = H(prev_hash || payload)
▼
audit_2026_07 (hot partition) ◀── query by actor/time
│ month sealed
▼
WORM object store (S3 Object Lock) ── retention: 7y
│
periodic anchor: publish latest hash externally
Вся ценность audit log в том, что вы можете доверять ему позже, поэтому схема должна запрещать мутацию. Дайте приложению только INSERT — никаких UPDATE/DELETE — и обеспечьте это на уровне роли БД, а не только в коде. Поверх этого постройте цепочку хешей: каждая строка хранит hash = SHA256(prev_hash || this_row). Измените любую историческую строку — и каждый последующий хеш ломается, так что фальсификация обнаружима даже тем, у кого есть доступ к БД. Периодически якорите последний хеш где-то вне вашего контроля (нотариус, публичный ledger, подписанное письмо), чтобы даже админ, переписавший всю цепочку, не смог совпасть с заякоренным значением.
Многолетние логи растут неограниченно, поэтому партиционируйте по времени (например, месячные range-партиции). Плюсы: запросы фильтруются по партиции, а вывод старых данных — это метаданные DETACH/DROP PARTITION — мгновенно, а не гигантский DELETE, раздувающий таблицу. Запечатанные партиции переезжают в WORM хранилище — S3 Object Lock в compliance mode физически предотвращает удаление до даты retention, удовлетворяя регуляциям вроде SOX/HIPAA. Держите свежие месяцы горячими в Postgres для быстрых запросов; всё старше — холодное в объектном хранилище, запрашиваемое по требованию.
Проверка в том, понимаете ли вы, что «audit log» означает неизменяемость и доказуемость, а не просто «таблицу с временной меткой». Хорошо: append-only таблица. Отлично: append-only обеспеченный ролью БД, цепочка хешей с внешним якорением, временное партиционирование для retention, WORM для комплаенса. Частая ловушка: хранить audit-строки в той же мутабельной таблице приложения (баг или злонамеренный DBA может тихо переписать историю) — аудиторы это отвергнут.
Библиотека вопросов для IT-собеседований с подробными ответами — от Junior до Senior.
Поддержать