Как банки будут контролировать ИТ-подрядчиков с доступом к банковской тайне

3 часа назад

© Изображение сгенерировано нейросетью

2 ноября 2026 года официально опубликован Федеральный закон № 350‑ФЗ, устанавливающий условия передачи финансовыми организациями отдельных ИТ-функций внешним исполнителям. Документ позволяет банкам привлекать подрядчиков к обработке информации ограниченного доступа, включая банковскую тайну и персональные данные, при соблюдении установленных требований к исполнителю и контролю со стороны заказчика.

В частности, финансовая организация должна уведомить Банк России о привлечении подрядчика, а исполнитель — сообщить заказчику об инциденте информационной безопасности в течение двух часов с момента его выявления.

Для банков это означает, что безопасность поставщика становится предметом постоянного контроля: важно понимать, кто получает доступ к данным, как разделены среды разных клиентов и что произойдет в первые часы после обнаружения подозрительной активности.

Аутсорсинг — не угроза сам по себе

Как считает Артём Куличкин, CISO одного из московских банков, передача части ИТ-функций внешнему исполнителю не означает автоматического роста рисков. Решающее значение имеет то, как банк выстраивает контроль за подрядчиком.

«Я бы не называл аутсорсинг сам по себе угрозой. Вопрос в том, как организована работа с подрядчиком и насколько банк понимает, что происходит с его данными. Передать обработку информации можно, но контроль над доступами, действиями сотрудников и безопасностью сервиса должен сохраняться»,  — говорит Куличкин.

Среди ключевых рисков эксперт выделяет компрометацию учётных записей подрядчика, избыточные права и ошибки настройки доступа. Например, инженер получает доступ для конкретной задачи, но после её завершения его права не отзывают. Другой сценарий — рабочая копия банковской базы оказывается в тестовой среде с менее строгими требованиями к защите.

Злоумышленники все чаще используют подрядчиков и цепочки поставок ПО как точку входа в инфраструктуру заказчиков. В материале RUБЕЖ «„Газинформсервис“: за четыре года кибератаки в России сместились от публичных взломов к скрытым операциям» отмечается рост атак с использованием ранее скомпрометированных учетных записей сотрудников и подрядчиков. Поэтому контроль внешних доступов, своевременный отзыв прав и мониторинг активности поставщика становятся частью защиты банковской инфраструктуры.

Один подрядчик — несколько банков

Если ИТ-компания обслуживает сразу нескольких заказчиков из финансового сектора, банку необходимо проверить изоляцию клиентских сред, использование персональных учетных записей и возможность восстановить действия конкретного администратора.

«Подписанное соглашение о конфиденциальности этих вопросов не решает», — подчеркивает Куличкин.

До запуска услуги необходимо определить, кто фактически обслуживает систему, каким сотрудникам и субподрядчикам доступны данные и может ли основной исполнитель передать часть работ третьей организации без согласования с банком. Ответственность подрядчика за привлеченные организации также стоит закрепить отдельно.

Два часа — на первичную оценку

Двухчасовой срок нужен не для завершения расследования, а для первичной квалификации события и запуска совместных действий банка и исполнителя.

«За два часа подрядчик должен сообщить, что обнаружено, какие системы могут быть затронуты и что уже сделано. Установить точную причину, полный объем затронутых данных и все последствия за это время удастся не всегда»,  — отмечает Куличкин.

В первом уведомлении должны быть указаны время обнаружения, затронутые или потенциально затронутые системы и категории данных, влияние на сервисы и клиентов, меры локализации, контакт ответственного и срок следующего обновления.

«Если несанкционированный доступ подтвержден, а факт выгрузки данных еще проверяется, именно так и нужно написать. Не стоит заявлять об отсутствии утечки только потому, что ее пока не успели подтвердить», — говорит Куличкин.

Для соблюдения срока необходим круглосуточный процесс обработки событий. Подрядчик может использовать внешний SOC, но ответственные за связь с банком, внутреннюю эскалацию и резервные каналы коммуникации должны быть определены заранее.

Киберсоглашение и проверяемые обязательства

Эксперт предлагает закреплять порядок взаимодействия сторон в отдельном киберсоглашении. Оно не заменяет законодательные требования, но позволяет перевести их в конкретные обязательства.

В документе стоит определить:

-события, о которых подрядчик обязан уведомлять банк;

-порядок фиксации времени выявления инцидента;

-основной и резервный каналы связи;

-подтверждение получения уведомления;

-сроки последующих обновлений;

-роли сторон при локализации и расследовании;

-порядок привлечения субподрядчиков;

-возврат данных, отзыв доступов и удаление оставшихся копий после завершения договора.

Внутренняя эскалация у исполнителя должна оставлять запас времени для сообщения банку. Ждать завершения расследования или согласования формулировок всеми подразделениями не следует.

Аудит: от документов к реальной защите

Операционный аудит не должен сводиться к проверке наличия политик и приобретенных средств защиты.

«Я бы проверял не столько наличие документов и приобретенных средств защиты, сколько их реальную работу. Есть ли сегментация между средами заказчиков, проходят ли привилегированные подключения через PAM, используется ли многофакторная аутентификация, фиксируются ли действия администраторов, устраняются ли критические уязвимости?», — поясняет Куличкин.

Банку следует оценивать сегментацию сред, MFA, контроль привилегированных подключений, журналирование действий, устранение критических уязвимостей, защищённость резервных копий и готовность к реагированию.

В материале RUБЕЖ «ФСТЭК обновила требования к защите ГИС: почему формальная аттестация не спасает от сбоев и киберрисков» разбирается, почему заказчику необходимо контролировать доступы, изменения конфигураций, журналы событий, резервное копирование и распределение ответственности с поставщиком в процессе эксплуатации. Хотя требования к ГИС не становятся автоматически требованиями для банков, принцип непрерывного контроля применим и к ИТ-аутсорсингу.

Отдельное внимание требуется резервному копированию и восстановлению.

«Отчет об успешном создании копии еще не отвечает на вопрос, сможет ли подрядчик восстановить услугу в нужный банку срок. Поэтому нужны результаты практических проверок», — подчеркивает Куличкин.

Периодичность проверок, сценарии, целевые сроки восстановления и формат предоставления результатов банку стоит заранее закрепить в киберсоглашении.

Контроль на всём жизненном цикле услуги

После подписания договора банк не должен ограничиваться ежегодным отчетом подрядчика. Для критичных услуг исполнителя стоит включать в процессы управления доступами, уязвимостями, изменениями и инцидентами заказчика. Это может включать передачу согласованного набора событий в SOC банка или возможность оперативно получить необходимые журналы.

Среди показателей для киберсоглашения эксперт выделяет полноту контроля привилегированных доступов, количество просроченных критических уязвимостей, время обнаружения и локализации инцидентов, соблюдение срока уведомления, результаты тестов восстановления и совместных киберучений.

«Для меня хороший ИТ-аутсорсинг — это ситуация, когда банк может проверить выполнение обязательств поставщика и понимает, как действовать при сбое или атаке», — резюмирует эксперт.

Вопрос круглосуточного мониторинга особенно важен для соблюдения двухчасового срока уведомления: подрядчик может использовать внешний SOC, но обязан обеспечить непрерывную обработку событий и заранее определить ответственного за связь с банком. О развитии внешних SOC, MDR и SOCaaS — в материале RUБЕЖ «Объем российского рынка SOC в 2026 году может превысить 30 млрд рублей».