При проверке клиента, ИТ-подрядчика или ИИ-агента компании нужны основания для конкретного решения: кто совершает действие, какие полномочия имеет и кто разбирает расхождения. Дайджест за 30 октября — 6 ноября 2026 года показывает, какие проверки нельзя заменить паспортными данными, ответом сервиса или токеном.
Кратко:
- Кредитору нужно подтвердить участие заявителя в заключении договора, а не только наличие его паспортных данных.
- При расхождениях в данных клиента заказчику следует дополнительно проверить результат KYC-провайдера.
- Закон № 350-ФЗ предусматривает для банков проверку ИТ-подрядчиков, уведомление регулятора и условия сообщения об инцидентах.
- Заказчику облачных услуг нужно проверить получение резервных копий и восстановление системы при недоступности провайдера.
- Сервису, принимающему запрос ИИ-агента, нужно сопоставить операцию с действующим поручением пользователя.
2 ноября президент подписал закон № 350-ФЗ об ИТ-аутсорсинге, который установит требования к передаче финансовыми организациями обработки данных подрядчикам. В опубликованном на этой неделе разборе дела об онлайн-займе Верховный суд потребовал установить, кто заключил договор с использованием паспортных данных гражданина.
После атаки на Beget заказчикам потребовалось восстанавливать данные в облачных сервисах. Гонконгский регулятор HKMA запустил проект SAGE для исследования финансовых ИИ-агентов, их идентичности и полномочий. В выпуске разбираем, какие сведения подтверждают личность и право на операцию, как проверять исполнение договорённостей и что предусмотреть при сбое или компрометации.
Какие доказательства нужны при дистанционной проверке клиента

2 ноября «Адвокатская газета» разобрала определение Верховного суда от 13 октября по делу № 67-КГ26-10-К8. На имя гражданина дистанционно оформили заём на 30 тыс. руб. В заявке были его паспортные данные и фотография паспорта. Номер телефона для SMS-подтверждения и банковская карта, на которую перечислили деньги, принадлежали другому человеку. Три нижестоящие инстанции удовлетворили требования коллектора.
Верховный суд отменил эти акты и направил дело на новое рассмотрение. При повторном рассмотрении суд должен установить, как кредитор идентифицировал заявителя и совершал ли владелец паспортных данных действия по заключению договора. Чтобы связать чужой номер и чужую карту с ответчиком, нужно выяснить, указал ли он их сам. Окончательного решения о незаключённости договора или списании долга Верховный суд не принял.
Кредитору нужны сведения, которые подтверждают, что заявитель подал заявку, согласился с условиями договора и указал реквизиты для перечисления денег. Проверки документа и записи о вводе SMS-кода недостаточно, если неизвестно, кто совершил эти действия. Банкам и МФО следует проверять, кому принадлежат указанные телефон и платёжные реквизиты. Если ими владеет другой человек, нужно выяснить, сам ли заявитель указал их для заключения договора и получения денег. Записи о подтверждении договора должны содержать номер, на который отправили код, время его ввода и версию подтверждённого договора. На основании этих сведений кредитор должен обосновать, почему счёл участником сделки конкретного клиента.
Оценить связь заявителя с указанным телефоном помогает проверка использования телефонного номера физлицом. При проверке учитываются сведения о том, на кого оформлен номер, как часто человек им пользуется, и другие параметры. Кредитор сопоставляет результат со сведениями о платёжных реквизитах и подтверждении договора, чтобы выявить расхождения в данных заявителя.
5 ноября американская саморегулируемая организация FINRA оштрафовала Webull Financial, онлайн-брокера для частных инвесторов, на 4,2 млн долларов. Основанием стали недостатки программ противодействия отмыванию денег, предотвращения кражи личности и обеспечения наилучшего исполнения клиентских поручений. Часть претензий FINRA касалась проверки клиентов с привлечением внешних сервисов.
По выводам FINRA, с января 2020 года по сентябрь 2023 года брокер открыл более 120 тыс. счетов с использованием сторонних сервисов проверки, не получив достаточного подтверждения личности клиентов. Более чем в 50 случаях заявители предоставили фотографии пейзажей вместо удостоверений личности. Webull также открывала счета, несмотря на сведения о смерти клиентов в собственных системах. Десятки счетов иностранных граждан брокер открыл с одного IP-адреса или устройства, не выявив признаки возможного использования чужих данных. Webull согласилась на урегулирование, не признавая и не отрицая нарушений.
В России МФО и брокеры могут нести ответственность за нарушения внутреннего контроля в сфере ПОД/ФТ по статье 15.27 КоАП РФ. К банкам Банк России вправе применять меры по статье 74 закона № 86-ФЗ, включая штрафы и ограничение отдельных операций.
В работе с KYC-провайдером заказчику следует определить, кто рассматривает расхождения между ответом поставщика, документами клиента и сведениями компании, какие дополнительные данные запрашивает и как фиксирует решение об открытии счёта. Положительный ответ внешнего сервиса не должен прекращать проверку, если другие сведения ставят её результат под сомнение.
Что предлагают изменить в применении простой подписи в КЭДО

2 ноября «Коммерсантъ» сообщил о возражениях Ассоциации больших данных против проекта Минтруда, который меняет правила кадрового электронного документооборота (КЭДО). По оценке АБД, предложенная редакция исключает использование простой электронной подписи, выпущенной работодателем, даже для повседневных документов, например заявления на отпуск. Сейчас сотрудник может подписывать такие документы в корпоративной системе с помощью логина и пароля.
Ассоциация предупреждает, что при принятии предложенной редакции компаниям придётся подключать государственные средства подтверждения личности либо переходить на другие виды электронной подписи. Подключение к инфраструктуре «Госуслуг» АБД оценивает примерно в 32 млн рублей на компанию. Минтруд сообщил, что дорабатывает проект с учётом предложений работодателей.
От окончательной редакции проекта зависит, сохранится ли действующий порядок применения простой электронной подписи работодателя и какие изменения потребуются в КЭДО. После утверждения требований компании смогут определить, нужна ли интеграция с государственной инфраструктурой, включая ЕСИА, или переход на другие способы подписания.
Как закон № 350-ФЗ меняет проверку ИТ-подрядчиков

2 ноября президент подписал закон № 350-ФЗ о передаче обработки конфиденциальной информации внешним организациям в финансовом секторе. Закон вступит в силу 3 ноября 2027 года. Он устанавливает требования к подрядчикам, порядок уведомления Банка России и условия договоров на обработку данных.
По новой статье 30.2 закона «О банках и банковской деятельности» банк должен будет заранее уведомить регулятора о намерении привлечь подрядчика. К уведомлению потребуется приложить заключение или отчёт по результатам операционного аудита поставщика. Поручить обработку информации можно будет по истечении 60 дней, следующих за днём направления уведомления, если Банк России не примет предусмотренного законом решения о запрете.
Информационные системы, в которых подрядчик будет обрабатывать переданные данные, должны находиться в России. Передавать государственную тайну в рамках этого порядка нельзя. Обработку персональных данных можно будет поручить без согласия их субъектов при соблюдении установленных условий, в том числе требований к договору по части 3 статьи 6 закона № 152-ФЗ. Подрядчик сможет выполнять только те действия с данными, на которые имеет право сам банк.
Банку потребуется проверить организацию и её руководителя на соответствие установленным ограничениям. В частности, организация не должна находиться в процессе ликвидации или банкротства, а руководитель не должен иметь предусмотренных законом судимостей. Компания и её руководитель не должны входить в указанные законом перечни. Подрядчик должен будет назначить штатных сотрудников, отвечающих за информационную безопасность и сохранность данных, организовать внутренний контроль и ежегодный операционный аудит. Для аудита потребуется привлечь организацию с необходимыми лицензиями ФСБ и/или ФСТЭК.
В договоре стороны должны будут закрепить порядок сообщения банку об инцидентах в течение двух часов с момента их выявления подрядчиком. Требование касается нарушений защиты информации и операционной надёжности. Подрядчик также должен будет ежеквартально предоставлять сведения о соблюдении целевых показателей защиты и надёжности. Стороны обязаны будут определить ответственность за разглашение информации и порядок уведомления о расторжении договора.
Подрядчик должен будет предупредить банк о намерении расторгнуть договор не позднее чем за шесть месяцев до предполагаемой даты его прекращения. До передачи данных банку поставщик обязан обеспечить их сохранность. Банк должен принять данные до расторжения договора.
Атака на Beget: что проверить в плане восстановления
В ночь на 2 ноября злоумышленники получили доступ к управляющей части инфраструктуры Beget и запустили скрипты, обнуляющие данные. По сообщениям Beget, которые 3 ноября привёл Хабр, компания утратила данные в облачных сервисах VPS, S3 и Kubernetes, а также настройки CDN и IP. При этом провайдер сообщил о сохранении файловых резервных копий VPS. Точные сроки полного восстановления сервисов на момент этих сообщений компания не назвала.
Даже при сохранённых резервных копиях срок восстановления зависит от доступа к ним и готовности инфраструктуры. Заказчику необходимо знать, как получить копии при недоступности панели провайдера, где развернуть систему и кто выполнит восстановление. Работоспособность этого порядка можно проверить во время тестового восстановления, зафиксировав время и результат.
Что показывает проверка цифровых рисков подрядчика
5 ноября Infosecurity из группы Softline объявила о запуске услуги Cyberinspect. По описанию компании, специалисты проверяют цифровую инфраструктуру контрагента, утечки корпоративных данных и учётных записей, открытые репозитории, поддельные аккаунты руководителей и другие признаки технических и репутационных угроз. Найденные события проходят ручную проверку. Заказчик получает отчёт с подтверждающими материалами и оценкой риска.
Заказчику нужно выяснить, какие результаты проверки относятся к подрядчику и создают риск для сотрудничества. Например, открытый репозиторий сам по себе не подтверждает утечку: необходимо установить, какие данные в нём доступны. Для подтверждённых проблем можно согласовать меры устранения и запросить подтверждение их выполнения. Возможность восстановить данные и соблюдение требований к аудиту заказчику потребуется проверить отдельно.
Проверка регистрационных сведений и базовых рисков компании дополняет технический аудит поставщика, но не заменяет его.
Что резервирование ресурсов ЦОД означает для заказчика

Указ Президента № 802 от 2 ноября обязывает владельцев российских центров обработки данных зарезервировать 10 % имеющихся площадей и мощностей не позднее десяти дней со дня вступления указа в силу. Требование не распространяется на перечисленные в документе государственные органы, органы местного самоуправления, государственные и муниципальные унитарные предприятия и учреждения. Указ действует со дня опубликования, 2 ноября.
После решения правительственной подкомиссии владельцы ЦОД должны предоставить зарезервированные ресурсы в течение суток для поддержки работы российских информационных ресурсов. Предельную плату за предоставление этих площадей и мощностей установит подкомиссия.
Указ также предусматривает временное использование зарубежных вычислительных мощностей для поддержки российских информационных ресурсов в связи с недружественными действиями иностранных государств. В рамках этого механизма потребуется решение подкомиссии, согласованное с ФСБ.
До решения подкомиссии владельцы ЦОД могут продолжать использовать зарезервированные ресурсы. Заказчику облачных услуг нужно выяснить, как поставщик будет действовать после получения решения: потребуется ли перенос нагрузок, как он повлияет на работу сервисов и за счёт каких ресурсов провайдер сохранит согласованные показатели доступности.
Как злоумышленники используют ИИ

2 ноября «Лаборатория Касперского» опубликовала технический разбор атак с CyberStrikeAI на образовательные организации в Латинской Америке и Африке. Инструмент разработан для автоматизации тестирования на проникновение: по заданию оператора языковая модель выбирает инструменты, формирует команды и анализирует результаты их выполнения.
В одном из разобранных инцидентов злоумышленники сначала вручную собирали информацию и готовили инструменты, используя ранее скомпрометированный SQL-сервер. После двухнедельной паузы они установили программу удалённого управления CyberStrikeAI. За следующие три-четыре дня атакующие получили доступ к учётным записям администраторов домена. Заключительный этап, включая перемещение между компьютерами, сбор учётных данных и экспорт базы, занял не более часа.
Языковая модель работала на сервере злоумышленников. На компьютерах жертвы установленная программа выполняла команды и передавала результаты, не обращаясь напрямую к ИИ-сервисам. Поэтому отсутствие таких обращений не исключает применения ИИ в атаке. Для обнаружения «Лаборатория Касперского» рекомендует отслеживать подозрительные команды, попытки извлечения учётных данных, закрепление в системе и сетевую активность между устройствами.
По сведениям Positive Technologies, опубликованным Forbes, при атаке на российскую компанию от первоначального проникновения до утечки прошло около трёх часов. Специалисты зафиксировали запуск десятков скриптов на нескольких серверах с интервалом в секунды. Сложные операции сочетались с ошибками в командах, которые атакующие быстро исправляли. По этим признакам исследователи предположили, что всю последовательность действий выполнили ИИ-агенты. Полная автономность атаки остаётся их гипотезой.
Как VOLTA использует ИИ для анализа похищенных данных
31 октября Cisco Talos описала вредоносную программу VOLTA, в которой языковую модель используют после сбора данных с заражённого устройства. Программа похищает пароли, данные активных сессий, токены доступа, ключи облачных сервисов и сведения о криптовалютных кошельках. Затем она формирует досье и отправляет его модели с помощью сервиса OpenRouter. В ответ оператор получает оценку активов жертвы по потенциальной выгоде и описание недостатков её защиты.
VOLTA также собирает дополнительные сведения, используя похищенные данные сессий для доступа к сервисам. Например, программа ищет в почте чеки с домашним адресом и получает историю заказов из сервисов доставки. В досье она объединяет личные сведения, данные о работодателе, рабочих сервисах и документах. По результатам анализа злоумышленник выбирает, какие учётные записи, ключи и другие похищенные данные использовать дальше.
После заражения рабочего устройства службе безопасности необходимо установить, какие данные и средства доступа могла собрать программа. Cisco Talos рекомендует сохранить журнал её работы, отозвать потенциально скомпрометированные токены и сменить пароли. Специалистам также нужно проверить доступные с устройства корпоративные системы: смена одного пароля не предотвращает использование других похищенных средств доступа.
Даже если участие ИИ остаётся предположением, службе безопасности необходимо установить объём похищенных данных и прекратить доступ по скомпрометированным учётным записям, токенам и ключам. Эти действия нельзя откладывать до окончательного вывода о том, кто выполнял команды: человек или программный агент.
Как поддельное собеседование используют для проникновения в компанию

3 ноября Axios опубликовал новые сведения Binance о расследовании кражи примерно 6,3 млрд долларов. По версии биржи, одному из инженеров написал человек, представлявшийся руководителем проекта в вымышленной компании. На первом собеседовании с сотрудником провели видеозвонок и показали правдоподобный профиль представителя работодателя с личными фотографиями и видео. На втором этапе ему предложили скачать заражённый репозиторий с кодом для выполнения тестового задания.
Binance рассматривает эпизод с поддельным собеседованием как одну из нескольких предполагаемых попыток проникновения. В опубликованном описании расследования биржа не сводит причины инцидента к одному тестовому заданию.
Полномочия представителя работодателя следует подтверждать по независимому каналу связи с компанией. Полученный код требует отдельной проверки. Для его запуска мы рекомендуем изолированную среду без рабочих учётных данных, ключей и доступа к внутренним ресурсам. Подтверждённая личность отправителя сама по себе не делает задание безопасным.
Как проверить происхождение и полномочия ИИ-агента

2 ноября Retail.ru опубликовал наблюдения StormWall о DDoS-атаках ботов, маскирующихся под ИИ-агентов. В сентябре и октябре злоумышленники атаковали интернет-магазины, медиа и финансовые организации, указывая в HTTP-заголовке User-Agent имена GPTBot, ChatGPT-User и других известных ботов. Среди признаков подмены StormWall отметила обращения к API, нетипичные для имитируемых программ.
Отправитель может подделать User-Agent, поэтому заявленное название не подтверждает происхождение бота. Такая маскировка также не доказывает применения ИИ атакующими. Если программа получает право совершать операции от имени клиента, помимо её происхождения нужно проверить, кто передал ей полномочия и какие действия разрешил.
Что Project SAGE исследует в проверке ИИ-агентов
2 ноября Управление денежного обращения Гонконга, HKMA, запустило Project SAGE. Участники исследуют применение ИИ-агентов в финансовых операциях, их идентичность и переданные полномочия, включая практики Know Your Agent (KYA) и аутентификацию.
Экспертная группа из представителей финансового и технологического секторов, консультантов и учёных также займётся совместимостью решений, распределением ответственности и защитой потребителей. Участники проекта исследуют практические сценарии и обсуждают будущие правила применения агентов.
Что подтверждает токен Skyfire при проверке Akamai
2 ноября Akamai описала применение протокола KYA компании Skyfire. Skyfire проверяет пользователя и оператора агента. Сведения о них и идентификатор агента включаются в подписанный токен, который программа передаёт с запросом. Akamai проверяет подпись и срок действия, после чего площадка определяет допустимые операции по своим правилам доступа.
Расширение KYAPay позволяет передать разрешение на оплату и лимит покупки. Антифрод-проверки и авторизация платежа выполняются отдельно: корректный токен не гарантирует одобрения платежа. По данным Akamai, один поставщик финансовых данных сформировал 2,5 млн агентских транзакций с KYA на защищаемых ею сайтах. Число оплаченных покупок компания не приводит.
Почему идентификация агента не подтверждает право на операцию
Подтверждение идентичности агента не заменяет проверки его полномочий. Пользователь может разрешить подбор товара без покупки, а для платежа установить ограничения по сумме и сроку.
Перед выполнением операции сервис должен проверить, разрешил ли пользователь агенту именно это действие и действует ли поручение. После отзыва поручения доступ к разрешённым им операциям нужно прекратить. В журнале следует фиксировать идентификатор агента, пользователя, от имени которого он действовал, и основание разрешения операции.
Как распределить проверку прав и реагирование на инциденты

После предоставления доступа компании нужно проверять актуальность прав и разбирать подозрительные действия. Автоматический мониторинг выявляет отклонения по заданным правилам, сотрудники проверяют их причины, а матрица эскалации определяет, кому передать сведения об инциденте и кто принимает решения.
Компания определяет периодичность проверок, сроки реакции и полномочия сотрудников с учётом своих систем и рисков. В таблице приведена наша модель распределения задач; роли и примеры не являются нормативными требованиями.
|
Критерий |
Автоматические проверки и мониторинг |
Ручные проверки |
Матрица эскалации инцидентов |
|---|---|---|---|
|
Задача |
Обнаруживать отклонения в правах и событиях доступа по заданным правилам |
Проверять обоснованность прав, разбирать исключения и неоднозначные события |
Определять ответственных, сроки реакции и порядок принятия решений |
|
Предмет контроля |
Изменения ролей, выдача привилегий, действия сервисных учётных записей и агентов, попытки использовать отозванные средства доступа |
Соответствие прав рабочим задачам, актуальность согласований, необходимость временного доступа |
Критичность события, затронутые системы и данные, необходимость привлечения дополнительных специалистов |
|
Когда применяется |
Непрерывно для событий доступа; по расписанию и после изменений для сверки прав |
После значимых изменений, при подозрительных событиях и во время планового пересмотра прав |
При обнаружении события, отвечающего критериям эскалации, или изменении масштаба инцидента |
|
Пример применения |
Средство мониторинга обнаруживает выдачу административной роли, которой нет в согласованной конфигурации |
Владелец системы выясняет, почему интеграции предоставили права на изменение данных вместо чтения |
При подтверждении несанкционированного доступа дежурный привлекает команду реагирования и владельца системы |
|
Результат |
Оповещение с указанием учётной записи, действия, времени и нарушенного правила |
Решение сохранить, ограничить или отозвать права с зафиксированным основанием |
Назначенный руководитель реагирования, перечень действий, сроки и порядок уведомления |
|
Кто отвечает |
Команда мониторинга и администраторы средств контроля |
Владелец системы или данных совместно со специалистами ИБ и администратором доступа |
Заранее назначенные дежурный, руководитель реагирования и владелец системы; при необходимости юристы и руководство |
|
Ограничения |
Качество проверки зависит от полноты журналов и правил; автоматизация не всегда позволяет установить деловую причину операции |
Проверка требует времени и компетенций; выборка не охватывает все события |
Матрица определяет порядок реагирования, но не обнаруживает нарушения и не ограничивает доступ технически |
|
Как оценивать результат |
Охват систем журналированием, время обнаружения, доля ложных срабатываний |
Доля проверенных прав, число просроченных пересмотров, срок устранения необоснованного доступа |
Время назначения ответственного, соблюдение сроков реакции, число событий без назначенного ответственного |
Что фиксировать при проверке клиента, подрядчика и агента

Паспортные данные, ответ KYC-провайдера, договор с ИТ-подрядчиком и токен агента подтверждают разные обстоятельства. Каждый из этих элементов требует сопоставления с конкретной операцией: кто её совершил, какие полномочия имел и соблюдал ли условия её выполнения.
Кредитору нужны подтверждения участия заявителя в заключении договора. Заказчику ИТ-услуг необходимо проверить способность поставщика защищать данные, сообщать об инцидентах и возвращать информацию при прекращении сотрудничества. Сервису, принимающему запросы ИИ-агентов, нужно сопоставлять каждую операцию с действующим поручением пользователя. Единого положительного результата идентификации для этих задач недостаточно.
Компания должна иметь возможность обосновать принятое решение и определить, когда его нужно пересмотреть. Для этого в рабочих процедурах следует закрепить достаточные подтверждения, причины дополнительной проверки и сотрудников, которые вправе разрешить операцию или приостановить её. Сохранённые результаты проверок и основания решений должны позволять восстановить действия компании при споре или инциденте.
Проверьте компанию-подрядчика до заключения договора
Получите регистрационные сведения и оценку базовых рисков ИТ-подрядчика до заключения договора.