Audit log показывает действие. Для критического контура часто нужен больший контекст: identity; роль; исходное состояние; решение; approval; версия правила; время; результат. Так технический event превращается в доказуемую историю бизнес-операции.
Начать диагностикуОбычная таблица audit может быть достаточно надёжной для многих систем.
Но если администратор способен изменить и транзакцию, и её журнал, независимость контроля ограничена.
AMPE использует append-only, WORM, cryptographic integrity или другие механизмы там, где цена подмены истории действительно этого требует.
В финансовых и платёжных контурах.
В системах с регуляторно значимыми действиями.
Когда критическое изменение должно проходить двойной контроль.
Когда требуется неотказуемая трассируемость.
Когда ошибка одного пользователя может иметь большой финансовый или операционный эффект.
Когда права администратора должны быть отделены от права бизнес-операции.
Когда recovery должен сохранять точную историю состояния.
Двойной контроль имеет смысл, если участники независимы по полномочиям и контексту.
Один инициирует. Другой проверяет.
Если второй участник просто механически повторяет действие первого, контроль формально существует, но не снижает риск.
AMPE связывает approval с типом операции, порогом, ролью и конфликтом интересов.
Опасное сочетание может возникать не в одной permission.
Например: создать контрагента; изменить его реквизиты; создать платёж; подтвердить платёж.
Каждое право отдельно допустимо. Комбинация — нет.
Поэтому SoD анализируется на уровне бизнес-возможностей, а не только технических ролей.
Повторный сетевой запрос не должен повторно провести платёж.
Сбой после фиксации части операции не должен оставлять необнаруживаемое промежуточное состояние.
AMPE связывает transaction design, reconciliation и recovery вокруг бизнес-инварианта.
Даже сильные критические системы используют независимую сверку.
Она позволяет обнаружить: потерянное событие; расхождение между системами; неполный процесс; ошибку внешнего контрагента.
Reconciliation — дополнительный слой доказательства целостности.
Критическая операция получает строгую identity.
Policy определяет допустимость. Approval подтверждает полномочие. Transaction сохраняет инвариант. Audit фиксирует ход. Reconciliation независимо проверяет результат. Monitoring обнаруживает отклонение. Recovery сохраняет доказуемость истории.
Так контроль строится не вокруг доверия к одному компоненту, а вокруг нескольких независимых гарантий.
Критические действия становятся полностью трассируемыми.
SoD и двойной контроль имеют реальный смысл.
Повторная обработка не создаёт повторный эффект.
История защищена сильнее обычных операционных данных.
Расхождения между системами обнаруживаются отдельным механизмом.
И главное — система способна доказать корректность критического результата, а не только заявить, что «ошибок не было».
Первый шаг
Для начала достаточно описать операции, где ошибка, злоупотребление или потеря истории недопустимы. Диагностика покажет, какие гарантии нужны на уровне полномочий, транзакций, аудита и независимой проверки.