Архитектура защищенного обмена с контрагентами: MFT, API

С чего начинаются риски во внешнем обмене

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

Во внешнем обмене обычно задействованы три канала. Файлы отправляют через общие папки, SFTP/FTPS, «временные» файлообменники и мессенджеры. API используют для интеграций между системами (заказы, статусы, справочники). Почта остается самым массовым способом пересылки актов, реестров, счетов и выгрузок, потому что «так быстрее».

Под внешним контрагентом стоит понимать не только поставщика или клиента. Это и подрядчик на аутсорсе, и банк, и госорган, и учебное учреждение, и любая сторонняя ИТ-площадка, включая сервисы, где контрагент хранит ваши данные. В таких отношениях риск выше: у всех разный уровень зрелости ИБ, разные администраторы, разные требования к хранению и журналам.

Чаще всего «уезжают» или подменяются персональные и кадровые выгрузки, финансовые документы (платежные реестры, счета, акты), коммерческие файлы (прайсы, спецификации, договоры), технические данные (логи, дампы, конфигурации), а также учетные данные в письмах и вложениях (пароли, ключи, токены).

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

Почему «просто VPN» не закрывает вопрос? VPN шифрует канал, но не делает обмен управляемым. Он не отвечает на вопросы ИБ: кто конкретно отправил файл, кто его скачал, что именно было передано, где это зафиксировано, как быстро можно найти инцидент и доказать неизменность данных. Более того, VPN часто превращается в «удлинитель сети», где внешнему пользователю случайно дают больше доступа, чем нужно.

Отправная точка простая: внешние каналы всегда будут. Значит, нужен контроль на уровне передачи, идентификации и понятного аудита, а не только «защищенный туннель».

Роли MFT, API gateway и почтовых шлюзов простыми словами

В разговоре про архитектуру защищенного обмена с контрагентами часто смешивают три разные задачи: передачу файлов, вызовы API и деловую переписку. У каждой задачи свои правила. Попытка «положить все на один сервер» обычно заканчивается серыми зонами, где непонятно, кто что отправил, кто разрешил и где это записано.

MFT (managed file transfer) нужен там, где вы передаете именно файлы: реестры, выгрузки, сканы, отчеты. Его сила в управляемости: он держит очередь, повторяет доставку при сбоях, фиксирует подтверждения и дает прозрачную историю по каждому файлу. Для ИБ это означает быстрые ответы на вопросы «когда ушло», «кто отправил», «дошло ли», «не менялся ли файл по дороге».

API gateway решает другую задачу: безопасный вход в ваши сервисы по API. Он не выполняет бизнес-логику, а задает правила на границе. Проверяет, кто пришел и что ему можно, ограничивает частоту запросов, контролирует методы и форматы. Это снижает риск перегрузки сервиса, обхода контроля или получения лишних данных.

Почтовый шлюз нужен для писем и вложений, где основные риски - фишинг, вредоносные вложения и утечки через «обычную почту». Он проверяет содержимое, применяет политики (например, запрет отправки определенных типов данных), поддерживает шифрование и правила для доменов контрагентов.

Удобная логика такая:

• MFT отвечает за «файл как объект» и доказуемую доставку.
• API gateway отвечает за «запрос как действие» и контроль доступа на входе.
• Почтовый шлюз отвечает за «письмо как канал» и защиту людей и рабочих станций.

Почему опасно смешивать все в одном месте без границ? Потому что у файлов, API и почты разные политики, журналы и уровни доверия. Если один общий сервер принимает и почту, и файлы, и API, то компрометация одного компонента открывает дверь сразу ко всем каналам. Плюс теряется понятный аудит: логи становятся разрозненными или «слипаются» так, что ИБ сложно восстановить цепочку событий.

На практике лучше, чтобы каждый канал имел свою точку контроля и свой набор журналов, а ИБ могла сопоставлять события по идентификаторам (контрагент, документ, время, результат доставки). Так проще защищать обмен и проще его проверять.

Модель угроз и границы доверия

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

Что считаем активами и почему это важно

Активы - это не только файлы или API-запросы. Внешний обмен часто ломается через «вспомогательные» вещи, о которых вспоминают в конце.

К активам обычно относят данные (файлы, вложения, API-пейлоады и метаданные вроде номеров договоров), учетные записи и права (служебные пользователи, группы, роли, токены), криптографию (ключи, сертификаты, секреты, HSM или хранилища секретов), журналы и следы (логи MFT, API gateway, почтовых шлюзов, SIEM-события), а также конфигурации (маршруты, политики, правила фильтрации, списки контрагентов).

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

Кто атакует и где заканчивается доверие

Нарушитель не всегда «хакер снаружи». В B2B чаще встречаются серые сценарии: компрометированная почта партнера, ошибочный скрипт подрядчика, утечка токена в логах.

Полезно разделить типовые роли нарушителя:

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

Дальше рисуют границы доверия. Минимальный набор: внешняя зона (интернет и сети партнеров), DMZ (публичные точки приема и фильтрации), внутренний контур (сервисы и хранилища), отдельная зона управления (админ-доступ, CI/CD, хранилища секретов). Любой переход через границу должен иметь явный контроль: аутентификация, проверка формата, ограничение команд и маршрутов, запись в аудит.

Пример: больница отправляет контрагенту реестр услуг. Файл проходит через DMZ, где проверяется источник и тип данных, затем попадает во внутренний контур только после проверки подписи и правил маршрутизации. Ключи подписи и журналы лежат в зоне управления, куда нет прямого доступа из DMZ. Так границы доверия становятся понятными и проверяемыми на аудите.

Если вы делаете такую схему как интегратор (например, на проектах уровня GSE.kz), удобнее обсуждать с ИБ не «какой продукт поставить», а «какую границу закрываем и каким контролем».

Опорная схема потоков данных без лишних «пробросов»

Хорошая архитектура защищенного обмена с контрагентами начинается с простого правила: разные типы обмена не должны идти по одному и тому же каналу. Файлы живут по своим правилам (размер, повторная доставка, контроль целостности), API-запросы - по своим (частота, авторизация, лимиты), почта - по своим (вложения, антиспам, DMARC). Когда все смешано, появляются обходные маршруты и «временные» пробросы во внутреннюю сеть.

Как разделить потоки и где держать компоненты

Типовой скелет такой: внешняя сторона общается только с периметром, а внутренние системы видят только строго выделенные внутренние коннекторы.

• DMZ (периметр): MFT-шлюз, API gateway, почтовый шлюз (или его внешняя часть), а также сервисы проверки контента (AV, sandbox, DLP при необходимости).
• Внутренний контур: бизнес-системы (ERP, CRM, ЭДО, хранилища), очереди/шины и отдельные коннекторы к MFT и API gateway.

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

Точки контроля, которые закрывают «дырки»

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

• аутентификация и привязка к партнеру: отдельные учетные записи, сертификаты или ключи, без общих логинов;
• проверка контента на входе: антивирус, контроль типов файлов, базовые DLP-правила для чувствительных данных;
• маршрутизация по белым спискам: какие партнеры могут обращаться к каким сервисам и в каких форматах;
• запрет прямых соединений: контрагент не должен ходить во внутренние подсети ни по VPN «для удобства», ни по открытым портам «временно».

Практический критерий: если внутренней системе можно напрямую открыть порт наружу, значит, вы уже строите обход. Правильнее оставить один управляемый вход через MFT/API gateway/почтовый шлюз, а дальше вести трафик внутрь только по коротким, документированным связям.

Пошагово: как собрать безопасную схему с нуля

Начните не с выбора «коробки», а с ясной картины: какие данные уходят наружу, кто за них отвечает и что будет, если канал сломается или его взломают. Тогда архитектура защищенного обмена с контрагентами будет понятна не только ИТ, но и ИБ.

Шаги, которые лучше не пропускать

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

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

3. Спроектируйте сегментацию. Разведите зоны так, чтобы внешние подключения не имели прямого пути к внутренним системам. Внешняя сторона видит только пограничный слой (шлюзы), а дальше обмен идет по строго заданным направлениям и портам. Любые «временные пробросы» фиксируйте как инцидент, а не как норму.

Дальше опишите правила на уровне политики, а не «как получилось в настройках». Простой формат: кто может отправлять или запрашивать что (тип и набор данных), куда (конечный приемник), когда (окна, частота) и какое подтверждение нужно (квитанция, подпись, контроль суммы, повторная отправка).

4. Настройте контрольные точки. В MFT это правила приема, проверка формата, карантин и подтверждение доставки. В API gateway - аутентификация, лимиты, схемы запросов и фильтрация. В почтовом шлюзе - политики вложений, антифишинг и запрет пересылки наружу определенных классов данных.

Шаг 5: тестирование, которое действительно ловит «дыры»

Проверяйте не только «успешный» сценарий, но и то, как система ведет себя в плохих условиях:

• неверные учетные данные, просроченные ключи, попытка доступа к чужому ресурсу;
• поврежденный файл, неверная подпись, подмена отправителя;
• повторная доставка одного и того же сообщения (идемпотентность);
• отказ узла (шлюза, канала, очереди) и корректное восстановление;
• пиковая нагрузка и срабатывание лимитов без падений.

Пример: больница отправляет страховой компании реестр счетов раз в сутки. Реестр идет через MFT в DMZ, где файл проверяется по формату и подписи, затем попадает во внутреннюю систему по одному разрешенному маршруту. Подтверждение (квитанция с идентификатором передачи) уходит обратно тем же каналом. Если подпись неверна, файл не «проскальзывает» внутрь, а уходит в карантин с записью в журнал для ИБ.

Доступ и идентификация: кто может отправлять и получать

Если у обмена с внешними контрагентами нет четких правил доступа, «дыры» появляются не из-за шифрования, а из-за людей и привычек: общий логин, забытый токен, лишние права «на всякий случай». В архитектуре защищенного обмена с контрагентами начните с простого: каждый контрагент должен быть отдельной сущностью в учетных записях, правилах и журналировании.

Единый принцип - минимум прав. Для MFT это означает отдельные сервисные учетные записи на каждого контрагента и, по возможности, на каждый тип обмена (например, «получение актов» и «отправка отчетов»). Для API gateway - отдельные client credentials и ограниченные scope/роли для каждого внешнего приложения. Для почтового шлюза - отдельные доверенные домены и политики для каждого направления, без режима «разрешить всем все».

Общие логины и «один ключ на всех» лучше считать инцидентом, который просто еще не случился. Если нужно дать доступ двум сотрудникам у контрагента, заведите две учетные записи, а не одну shared. Тогда при увольнении или смене подрядчика не придется останавливать весь обмен.

Там, где возможно, включайте MFA: для администраторов MFT, для веб-кабинетов, для ручных операций с выгрузками. Для машинного доступа MFA обычно не подходит, поэтому важнее ротация секретов и короткий срок жизни токенов, плюс понятный процесс перевыпуска.

Полезно заранее определить, как именно вы ограничиваете доступ, чтобы он соответствовал потоку данных, а не был слишком широким: по IP-адресам и подсетям контрагента (и вашим исходящим адресам), по времени (окна обмена), по методам и операциям (только upload или только download), по размерам и типам (лимиты, запрет неожиданных форматов), по частоте (защита от перебора и «шумных» запросов).

Пример: государственная организация получает отчеты от нескольких поставщиков. В MFT каждому поставщику дают доступ только к его папке и только на загрузку, без просмотра чужих файлов. В API gateway для каждого поставщика выпускают отдельный ключ с правом только на один endpoint. На почтовом шлюзе разрешают прием только с согласованных доменов и блокируют вложения нестандартных типов. Так ИБ получает простую картину: кто именно отправил, куда, чем подтвердил личность и что ему было разрешено.

Шифрование, подпись и управление ключами

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

Шифрование в канале: TLS без самообмана

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

Проверьте базовые вещи:

• включена проверка цепочки сертификатов и имени узла (hostname);
• запрещены устаревшие протоколы и слабые шифры;
• настроено взаимное TLS (mTLS), если контрагентов мало и уровень риска высокий;
• сертификаты не общие на всех, а привязаны к сервису и среде (test и prod отдельно);
• события TLS (ошибки валидации, смена сертификата) попадают в журнал.

Шифрование данных и подпись: что шифровать и где подписывать

Для почты обычно выбирают S/MIME или PGP: важно, чтобы шифрование было сквозным на уровне сообщения, а не только между почтовыми серверами. Для файлового обмена через MFT полезно шифровать сам файл (например, перед отправкой), а также шифровать хранилище на стороне MFT, если там есть временные копии и очереди.

Подпись имеет смысл делать на стороне отправителя до передачи, чтобы получатель мог проверить, что данные не менялись по пути. На входе в периметр (почтовый шлюз, MFT, API gateway) проверку подписи лучше делать автоматически и фиксировать результат: корректна ли подпись, кто подписал, какой сертификат, какая политика применена. Это заметно упрощает разбор инцидентов.

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

Управление ключами стоит оформить как процесс, а не как папку с файлами: хранить ключи в защищенном хранилище с доступом по ролям, делать ротацию по расписанию и при смене ответственных, иметь понятный отзыв (revocation) и план действий при утечке, разделить ответственность (владелец ключа, оператор, ИБ), обеспечить резервирование и учет, чтобы ключ не «ушел» вместе с человеком.

Если вы внедряете это в критичных средах (госорганы, финсектор), заранее договоритесь, кто выпускает и кому доверяет сертификаты, и как именно будет выглядеть проверка и журналирование на каждом узле.

Аудит и журналы: как сделать их полезными для ИБ

Журналы во внешнем обмене нужны не «для галочки». Они должны быстро отвечать на три вопроса: кто сделал действие, что именно произошло и где это отразилось дальше. Для архитектуры защищенного обмена с контрагентами это особенно важно: у вас несколько каналов (MFT, API gateway, почта), разные команды и разные зоны ответственности.

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

Старайтесь фиксировать как минимум:

• аутентификацию и авторизацию (входы, отказы, истекшие токены, блокировки);
• передачу данных (старт/финиш, объем, хэш/контрольная сумма, ошибки доставки);
• подозрительные события (превышение лимитов, частые повторы);
• администрирование (изменения политик, маршрутов, сертификатов, списков получателей);
• доступ к журналам (кто смотрел, кто выгружал, кто менял настройки логирования).

Чтобы расследование не превращалось в «сшивание» по времени, введите сквозной идентификатор операции (correlation ID). Он должен появляться при первом входе (в API gateway, MFT или почтовом шлюзе) и передаваться дальше - в заголовках, метаданных задания MFT и записях конечной системы. Тогда по одному ID видно, что запрос прошел проверку, файл загрузился, проверился антивирусом, применились политики, и доставка в целевую систему завершилась.

Логи стоит нормализовать, иначе SIEM будет шуметь. Приведите события к понятным полям: время (с часовым поясом), система-источник, пользователь/сервис, контрагент, канал (API/MFT/почта), действие, результат, причина отказа, адрес и устройство, ID операции, объект (файл/endpoint), классификация данных.

Хранение важно не меньше сбора: задайте сроки (например, 90 дней онлайн и 1-3 года в архиве), обеспечьте неизменяемость (WORM или эквивалент) и разделите права. Администраторы обмена не должны иметь возможность «подчищать» следы, а ИБ - иметь доступ на чтение и выгрузку по регламенту.

Регулярная отчетность помогает ловить проблемы до инцидента: топ отказов по причинам, новые контрагенты и каналы, изменения политик, передачи с отклонениями по объему, попытки доступа к запрещенным ресурсам, а также контроль покрытия логами (какая система перестала писать события).

Частые ошибки, из-за которых появляются «дыры»

Даже когда у вас есть MFT, API gateway и почтовый шлюз, проблемы обычно рождаются не в выборе продукта, а в мелких «упрощениях». В итоге архитектура защищенного обмена с контрагентами выглядит правильно на схеме, но в реальности обходится за 2-3 шага.

Где чаще всего ломается безопасность

Самая частая ошибка - «временный» прямой доступ во внутренние системы. Для ускорения запуска открывают порт напрямую до файлового ресурса или внутреннего API, минуя MFT или gateway. Потом это забывают закрыть, а правила в межсетевом экране остаются годами.

Не менее опасна привычка отключать проверку сертификатов. Обычно это делается «на пару дней», пока контрагент не настроит TLS. Но исключение остается, и дальше подмена на маршруте может пройти как «нормально».

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

Еще один источник дыр - смешение теста и продакшена. Когда тестовые партнеры и боевые контрагенты живут в одном контуре, легко отправить реальные данные в тестовую систему, а тестовые учетные данные могут случайно получить доступ к боевым маршрутам.

Вот как это обычно проявляется:

• «Сделали исключение для сертификата, иначе не подключается», и оно осталось после пилота.
• «Для удобства» открыли прямой вход во внутренний сервис, потому что через MFT дольше.
• Нет подтверждений и повторов, и пропажа файлов обнаруживается только по жалобе.
• Один общий контур для тестовых и боевых интеграций, отличаются только папкой или префиксом.
• Логи есть везде, но их нельзя связать в одну цепочку действий.

Чтобы закрыть эти дырки, проверьте простые вещи: есть ли единая точка входа для каждого типа обмена без обходных маршрутов; включена ли строгая проверка сертификатов и понятен ли процесс утверждения исключений; подтверждается ли доставка (квитанции, статусы) и настроены ли повторы; разделены ли тест и прод по сетям, учетным данным и ключам; можно ли по одному идентификатору операции ответить на вопрос «кто отправил, что именно, куда, когда и чем завершилось».

Короткий чеклист и следующие шаги

Перед запуском внешнего обмена полезно сделать короткую проверку. Она помогает увидеть «дыры» еще до пилота и дать ИБ понятный ответ: кто, что и как передает.

Чеклист перед стартом

Проверьте, что выполнены базовые вещи:

• Для API есть единая точка входа через API gateway, а для файлов и почты выделены отдельные каналы (MFT и почтовый шлюз), без прямых «пробросов» во внутреннюю сеть.
• На каждого контрагента заведены отдельные учетные данные, роли и лимиты (по объему, частоте, доступным методам и направлениям обмена).
• Там, где нужно, включены шифрование и подпись, а также проверка целостности - технически принудительно, а не «по договоренности».
• Логи собираются централизованно и позволяют восстановить цепочку операции: кто инициировал, что отправили, через какой компонент прошло, какой результат и код ошибки.
• Есть процедура действий при сбое, при подозрении на компрометацию ключей, при спорной доставке или отказе от факта отправки.

Если хотя бы по одному пункту ответ «не уверен», лучше остановиться и закрыть вопрос до расширения обмена на всех контрагентов.

План внедрения на 30-60 дней

Сроки зависят от количества контрагентов и требований ИБ, но рабочая рамка обычно такая:

• 1-2 недели: инвентаризация потоков, классификация данных, выбор правил шифрования и хранения журналов.
• 2-4 недели: пилот на 1-2 контрагентах, настройка ролей, лимитов, форматов логов и алертов.
• 4-6 недель: утверждение регламентов (ключи, доступы, инциденты), обучение ответственных, запуск в эксплуатацию.
• 6-8 недель: расширение на остальных контрагентов, проверка устойчивости, ежемесячный разбор журналов с ИБ.

Если нужен партнер для реализации, имеет смысл привлекать системного интегратора, который закрывает не только установку компонентов, но и правила, аудит и поддержку. Например, GSE.kz (gse.kz) работает как производитель и системный интегратор и может помочь выстроить такую схему и обеспечить сопровождение, включая круглосуточную техническую поддержку через сервисную сеть.