Соответствие требованиям и запуск

Архитектура безопасности интеграции партнёров

Границы траста и контроль производства для встроенной торговли, API, SDK, webhook, передачи активов и операционных интеграций.

Просмотр в формате Markdown

Эта страница посвящена тому, как партнёр должен проектировать безопасную интеграцию 6MM . Для более широких уровней безопасности, используемых на торговой платформе, см. Архитектура безопасности платформы.

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

КомпонентМожет содержатьНе должно содержать
Партнёрский фронтендПубличная конфигурация, кратковременный результат ввода данных, нечувствительное состояние интерфейсаПартнёр API секрет, ключ с подписью, привилегированные бэкенд-учетные данные
Партнёрский бэкендСопоставление пользователей, защищённые учетные данные, логика подписи, обработка вебхуковСекреты, раскрытые через ответы клиентов или публичные логи
6MM интеграционные конечные точкиОдобренные подписанные запросы, токены и доставка вебхуковНепроверенные предположения пользователей на стороне партнёра

Партнёрский фронтенд должен вызывать партнёрский бэкэнд для выполнения привилегированных операций. Бэкенд проверяет партнера, вызывает 6MM через утверждённый API или SDK и возвращает только кратковременный результат, необходимый фронтенду.

Уровни безопасности

СлойОбязательный акцент
API квалификацииХранилище только в бэкенде, план ротации и контроль доступа.
Подписание запросаПостоянная обработка временной метки, подписи и защиты от повторов.
Встраиваемые токеныКратковременная выдача, проверки на соответствие и явное поведение опровержения.
ВебхукиЖурналы проверки подписи, идентификации, повторов и аудита событий.
ЭксплуатацияРоли доступа, эскалация инцидентов, мониторинг и хранение доказательств.

План контроля производства

Зона управленияМинимальные доказательства реализации
Хранение учетных данныхРасположение секретного менеджера, владелец доступа, разделение среды и процесс ротации.
Запись пользователяПроверка сессии, проверка правоприменимости, кратковременный поток токенов и обработка сбоев.
Подписанные запросыПравильная среда, синхронизированное время, логирование запросов и оповещения об ошибках подписи.
Эксплуатация активовУникальные бизнес-идентификаторы, согласование тайм-аута, запросы на статус и путь проверки оператора.
ВебхукиПроверка подписи сырого тела, управление повтором, сохранение идемпотентности и обработка с безопасным повтором.
МониторингОповещения о сбоях аутентификации, аномальных повторах, задержках webhook и операционных ошибках.
Реагирование на инцидентыУказанный владелец, канал эскалации, удержание доказательств и процедура аннулирования аккредитации.

Обзор запуска

До производства:

  1. Нарисовать потоки данных пользователя, токена, запроса, актива и вебхука.
  2. Отмечайте, где создаются, хранятся, используются, ведутся, ротируются и отзываются каждую учетную запись.
  3. Тестирование просроченных токенов, недействительных подписей, тайм-аутов, дублирования вебхуков и повторного подключения.
  4. Убедитесь, что команды поддержки могут определить операцию по запросу или бизнес-идентификатору.
  5. Заполнить Чек-лист запуска производства.
Секреты и подписания

Защитите Agent SDK учетные данные и подписанные запросы.

Подписание запросов

Реализуйте прямое подписание от разработчика API запросов.

Вебхук и идемпотентность

Безопасно обрабатывайте события.