> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.6mm.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.6mm.com/_mcp/server.

# Архітектура безпеки інтеграції партнерів

Ця сторінка зосереджена на тому, як партнер має розробити безпечну інтеграцію 6MM . Для ширших рівнів безпеки, що використовуються на торговій платформі, див. [Архітектура безпеки платформи](/uk/security-compliance/security-architecture).

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

<h2 id="recommended-trust-boundary">
  Рекомендована межа трасту
</h2>

| Компонент                    | Може містити                                                                        | Не повинен містити                                                       |
| ---------------------------- | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| Партнерський фронтенд        | Публічна конфігурація, короткочасний результат введення, нечутливий стан інтерфейсу | Партнер API секрет, ключ підписання, привілейовані бекенд-облікові дані  |
| Партнерський бекенд          | Відображення користувачів, захищені облікові дані, логіка підпису, обробка вебхуків | Секрети, які розкриваються через відповіді клієнтів або публічні журнали |
| 6MM кінцеві точки інтеграції | Затверджені підписані запити, токени та доставка вебхуків                           | Непідтверджені припущення користувачів на стороні партнера               |

Партнерський фронтенд повинен викликати партнерський бекенд для привілейованих операцій. Бекенд перевіряє партнера-користувача, викликає 6MM через затверджену API або SDK і повертає лише короткочасний результат, необхідний фронтенду.

<h2 id="security-layers">
  Рівні безпеки
</h2>

| Шар                | Необхідна концентрація                                                       |
| ------------------ | ---------------------------------------------------------------------------- |
| API кваліфікації   | Зберігання лише для бекенду, план ротації та контроль доступу.               |
| Підписання запитів | Послідовна обробка часової мітки, підпису та захисту від повтору.            |
| Вбудовувані токени | Короткочасна видача, перевірки права на участь і явна поведінка недійсності. |
| Webhooks           | Журнали перевірки підписів, ідемпотентності, повторень та аудиту події.      |
| Експлуатація       | Ролі доступу, ескалації інцидентів, моніторингу та збереження доказів.       |

<h2 id="production-control-plan">
  План контролю виробництва
</h2>

| Контрольна зона            | Мінімальні докази впровадження                                                                                      |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| Зберігання облікових даних | Розташування секретного менеджера, власник доступу, розділення середовища та процес ротації.                        |
| Запис користувача          | Перевірка сесій, перевірка відповідності, короткочасний потік токенів та обробка збоїв.                             |
| Підписані запити           | Правильне середовище, синхронізований час, логування запитів і сповіщення про помилки підпису.                      |
| Операції з активами        | Унікальні бізнес-ідентифікатори, узгодження тайм-ауту, запити статусу та шлях перегляду оператора.                  |
| Webhooks                   | Верифікація підпису сирого тіла, контроль повторів, збереження ідемпотентності та обробка при повторному засіданні. |
| Моніторинг                 | Сповіщення про помилки автентифікації, аномальні повторні спроби, затримки вебхуків та операційні помилки.          |
| Реагування на інциденти    | Названий власник, канал ескалації, зберігання доказів та процедура анулювання кваліфікації.                         |

<h2 id="launch-review">
  Огляд запуску
</h2>

До виробництва:

1. Намалюйте потоки даних користувача, токена, запиту, активу та вебхука.
2. Позначте, де створено, збережено, використано кожне облікове дані, зареєстровано, повернулося та відкликалося.
3. Тестувати прострочені токени, недійсні підписи, тайм-аути, дублювати вебхуки та поведінку при повторному підключенні.
4. Підтвердити, що команди підтримки можуть знайти операцію за запитом або бізнес-ідентифікатором.
5. Заповніть [Контрольний список запуску виробництва](/uk/solutions/production-launch-checklist).

<h2 id="recommended-docs">
  Рекомендовані документи
</h2>

#### [Секрети та підписання](/uk/sdk/security/secrets-signing)

Захистіть Agent SDK облікові дані та підписані запити.

#### [Підписання запитів](/uk/developer-api/request-signing)

Впровадьте пряме підписання API запитів від розробника.

#### [Вебхук і ідемпотентність](/uk/sdk/security/webhooks-idempotency)

Обробляйте події безпечно.