6 min read

Архитектура proxy-контура

architecture security proxy
English version

Когда несколько MVP работают с внешними API, возникает вопрос: кто контролирует исходящий трафик? Если каждый сервис вызывает внешние API напрямую, появляются проблемы с безопасностью, аудитом и управлением данными.

Проблема

Представьте: у вас три MVP, каждый из которых использует OpenAI API. Без централизации:

  • Каждый сервис хранит свой API-ключ
  • Нет единого лога вызовов
  • Персональные данные могут утечь в payload
  • Невозможно быстро отключить провайдера

Решение: api-broker

api-broker — это единственная точка исходящих вызовов. Все MVP обращаются к внешним API через него.

Классификация payload

Каждый запрос классифицируется по уровню чувствительности:

  • Class A — технический payload без персональных данных. Проходит свободно.
  • Class B — допустимый после фильтрации. Email, имена маскируются перед отправкой.
  • Class C — запрещённый. Содержит данные, которые нельзя передавать во внешний API.

Маскирование

Перед отправкой во внешний API, broker:

  1. Проверяет payload на наличие PII (personally identifiable information)
  2. Маскирует email, телефоны, ФИО, Telegram-хэндлы
  3. Заменяет пользовательские ID на анонимные токены
  4. Логирует факт маскирования

Аудит

Каждый вызов записывается в лог:

  • Кто вызвал (какой MVP)
  • Какой провайдер
  • Какой маршрут
  • Статус ответа
  • Был ли применён маскинг

Payload ответа не хранится — только метаданные.

Реестр провайдеров

Каждый внешний API регистрируется как провайдер с указанием:

  • Страны
  • Типа данных, которые принимает
  • Класса риска
  • Допустимых маршрутов

Это позволяет принимать архитектурные решения на уровне политики, а не на уровне кода каждого MVP.

Следующие шаги

Сейчас proxy-контур находится на стадии проектирования. Первая реализация появится вместе с первым MVP, который использует внешний API.