Zero Trust в платежах: как нулевое доверие переносится из сети в процедуры согласования транзакций
Модель нулевого доверия давно стала стандартом защиты сетей и доступа к системам. Но самые дорогие инциденты сегодня происходят не в сети, а в процессе согласования платежа — и именно туда Zero Trust должен переехать следующим.
Что такое Zero Trust и почему он вышел за пределы сети
Zero Trust — это архитектурный подход, при котором ни один пользователь, устройство или запрос не считается доверенным только потому, что находится «внутри» периметра. Базовый документ отрасли, NIST SP 800-207, формулирует это просто: доступ предоставляется для каждой сессии отдельно, на основании политики и контекста, а доверие постоянно переоценивается.
Для IT-команд это означало отказ от идеи «безопасной внутренней сети». Для финансовых команд следствие ещё важнее: «внутреннее» письмо от CFO, звонок «знакомого» контрагента или сообщение в корпоративном мессенджере точно так же не являются доказательством легитимности запроса на перевод средств.
Миф о доверенном канале
Большинство платёжных процедур до сих пор построено вокруг канала: если запрос пришёл с корпоративной почты, знакомым голосом или с известного номера — его считают достоверным. Именно эту логику эксплуатируют BEC-атаки, подмена реквизитов поставщика и deepfake-звонки от имени руководителей.
Ключевой сдвиг в мышлении: канал связи — лишь транспорт для запроса. Доверие должно возникать из проверки, которую выполняет процесс, а не из того, откуда или от кого пришло сообщение.
Когда организация переносит Zero Trust в платежи, она перестаёт спрашивать «похоже ли это на настоящего руководителя?» и начинает спрашивать «прошёл ли этот запрос все независимые проверки, предусмотренные политикой?».
Пять принципов Zero Trust для согласования транзакций
- Явная проверка каждого запроса. Каждый платёж и каждое изменение реквизитов проверяются по политике независимо от статуса инициатора и срочности.
- Минимальные полномочия. Лимиты по сумме, перечень разрешённых получателей и отдельные права на создание, согласование и отправку платежа.
- Предположение компрометации. Процесс проектируется так, будто почта или аккаунт руководителя уже взломаны: ни один отдельный канал не может самостоятельно инициировать и подтвердить перевод.
- Независимое подтверждение. Нестандартные операции подтверждаются out-of-band — через заранее зафиксированный контакт, а не через канал, по которому пришёл запрос.
- Непрерывная оценка риска. Сумма, новый получатель, необычное время, новая страна или изменение реквизитов автоматически повышают уровень проверки.
Как выглядит процесс на практике
В зрелой модели платёж проходит несколько независимых «ворот», и каждые из них могут остановить операцию. Ни один человек и ни один канал не могут пройти всю цепочку самостоятельно.
Важная деталь: проверки должны быть встроены в систему (TMS, ERP, банк-клиент), а не существовать только в регламенте. Правило, которое можно обойти «в исключительных случаях», атакующий обязательно превратит в исключение.
С чего начать
- Опишите все пути, по которым в компанию поступают платёжные поручения и изменения реквизитов.
- Разделите роли создания, согласования и отправки платежа между разными людьми и учётными записями.
- Зафиксируйте справочник контактов контрагентов в мастер-данных и запретите его изменение без отдельной процедуры.
- Настройте пороги риска, которые автоматически включают дополнительную проверку.
- Регулярно тестируйте процесс сценариями BEC и deepfake-звонков.
Zero Trust в платежах — это не продукт, а дисциплина: доверие не выдаётся каналу, оно каждый раз зарабатывается проверкой. — Редакция Sentinel Ledger
