Перейти к содержимому

Безопасность

На странице

Безопасность

Узнайте, как Paymos защищает балансы токенов изолированной подписью выводов, белым списком адресов, HMAC-аутентификацией, подписанными вебхуками и аудитом.

Paymos — кастодиальный шлюз: мы держим ключи, которыми ваши средства двигаются в блокчейне. У любого мерчанта тут законный вопрос: что мешает Paymos забрать мои деньги — и что будет, если что-то сломается?

Эта страница отвечает на оба — сначала коротким списком обещаний, потом простым языком с объяснением, почему так. Здесь — гарантии платформы и то, что каждая из них вам даёт, а не «чертёж» внутренностей. То, что относится к публичному API (как подписать запрос, как проверить вебхук), описано точно — без этого не подключиться.

Почему ваши деньги в безопасности

Контроль адресов и изолированная подпись

  • Изолированная инфраструктура подписи. Paymos исполняет кастодиальную подпись вне публичного веб-контура. Это управляемое хранение, а не прямой контроль ключей со стороны бизнеса.
  • Обязательный белый список. Деньги уходят только на адреса, которые вы одобрили заранее. Даже полный угон ваших API-ключей не позволит придумать новый адрес для вывода.
  • Кто одобряет получателя и кто двигает деньги — разные права. Белый список правит только владелец аккаунта. Роль «Финансы» отправляет выводы, но вписать в список новый адрес не может: тот, кто двигает деньги, работает по списку, который утвердил не он. Любая выдача прав пишется в журнал.
  • Вывод — по вашему графику. Баланс ваш с момента финальности платежа. Мы не блокируем средства. Выводите хоть раз в час, хоть никогда: между запросом и отправкой транзакции нет ни расчётного окна, ни очереди, а дальше время в пути определяет сама сеть.
  • Раздельные балансы. Баланс каждого мерчанта учитывается отдельно. Мы не складываем средства в общий котёл и не пускаем их в оборот.

Деньги не пропадут незаметно

  • На баланс попадают платежи с глубиной подтверждения, выбранной по сети и сумме — достаточной, чтобы реорг был редкостью, но не такой, чтобы называть его невозможным.
  • Никаких откатов. Подтверждённый платёж не отменяется. Если он всё же выпадет из цепочки при реорге, убыток берёт Paymos, а не вы.
  • Вывод не уйдёт дважды. У каждого вывода есть ваш ключ идемпотентности.
  • Многоуровневые заморозки могут автоматически остановить один актив, если картина в блокчейне разойдётся с учётом.
  • Вывод сверяется с вашим балансом до приёма — если суммы вместе с комиссией сети на балансе нет, ошибка приходит сразу, а вывод не создаётся.
  • Записи, которые не подделать: каждое значимое действие попадает в аудит, а секреты и подписи вычищаются из записи до её сохранения.

Никаких откатов. Подтверждённый платёж не отменяется. Если он всё же выпадет из цепочки при реорге, убыток берёт Paymos, а не вы.

Дальше — каждый пункт простыми словами. Если встречали слова HMAC или SSRF и хотелось понять, что это, — читайте ниже.

Модель угроз

Мы защищаемся от:

  • Средства в покое — ключи, которыми можно двигать балансы в блокчейне
  • Средства в движении — авторизация вывода и подмена адреса назначения
  • Доступ к API — кража ключей, повтор запроса (replay), расширение прав
  • Доставка вебхуков — поддельные тела запросов и использование нашей инфраструктуры как SSRF-плацдарма для атаки на вашу
  • Операционные риски — случайные разрушительные действия, гонки между серверами, пробелы в аудите

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

Подпись выводов и контроль адресов

В чём проблема. Средствами в блокчейне управляют ключи подписи. Украденные реквизиты, подменённый адрес или компрометация контура подписи могут привести к потере денег, если окружающие ограничения не закрываются безопасно.

Что делает Paymos. Исходящие транзакции подписываются в изолированной инфраструктуре. Вывод возможен только на адрес из белого списка бизнеса, а пустой список блокирует выводы целиком. Правка списка — отдельное действие, и оно попадает в журнал аудита. Если у сотрудника подключён второй фактор, правка дополнительно потребует свежего подтверждения. Если второго фактора нет, подтверждать нечем: этот слой начинает работать в тот день, когда вы его включите.

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

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

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

HMAC — как API понимает, что запрос реально от вас

HMAC (Hash-based Message Authentication Code — «код проверки подлинности на основе хеша»). Звучит страшно, суть простая.

В чём проблема. Ваш сервер шлёт нам «создай вывод на 1 000 $». У нас два вопроса: это правда вы, а не самозванец? И не подменил ли кто-то запрос по дороге — сумму или адрес? Если просто класть пароль внутрь запроса, любой, кто перехватит трафик, украдёт его и будет слать запросы от вашего имени.

Что делает HMAC. У вас и у нас есть общий секрет (ваш API-секрет). На каждый запрос вы считаете «отпечаток» (подпись) — это хеш от содержимого запроса вместе с секретом. Шлёте запрос и отпечаток, но не сам секрет. Мы своим экземпляром секрета считаем такой же отпечаток. Совпало — значит, это точно вы, и ничего не подменили: измените хоть один символ, и отпечаток не сойдётся.

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

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

Точный формат (для интеграции)

Каждый аутентифицированный запрос несёт два заголовка:

Authorization: HMAC-SHA256 {api_key_id}:{base64(signature)}
X-Request-Timestamp: {unix_seconds}

Подпись — это HMAC-SHA256 по канонической строке:

{timestamp}\n{METHOD}\n{path}\n{query}\n{sha256_hex_lower(body)}

Пустое тело подставляется в этот слот как пустая строка — его не хешируют; параметры запроса подписываются ровно в том виде, в каком они в URL. Подробности — на странице Аутентификация.

Защита от повтора (anti-replay)

А переслать ваш старый, записанный запрос — повторить «создай вывод» сто раз? В подпись входит метка времени, и мы отвергаем запрос, если X-Request-Timestamp разошёлся с временем сервера больше чем на ±5 минут (ответ 401). Записанный запрос живёт пять минут и умирает. А вместе с идемпотентностью (см. ниже) даже внутри этих минут повтор не отправит средства дважды.

Аналогия. Билет с окном входа на пять минут — вчерашний не сработает.

Сравнение «за постоянное время»

Когда мы сверяем две подписи, наивное сравнение обрывается на первом неверном символе — и по времени ответа можно угадать, сколько символов уже верны, и подобрать подпись по байту. Мы сравниваем за постоянное время: ответ «нет» занимает одинаково долго, сколько бы вы ни угадали.

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

Типы ключей и ротация

Два типа ключей. У каждого — жёстко закреплённый набор прав, и сервер проверяет его при каждом вызове:

  • Payment-ключ — всё, что про деньги на входе: создавать и читать инвойсы, управлять платёжными каналами и читать их депозиты. Не может читать балансы и создавать выводы.
  • Payout-ключ — создавать, читать и отменять выводы, читать балансы. Не может создавать инвойсы и не достаёт до платёжного канала.

Секреты меняются без простоя: вы генерируете новый, а предыдущий работает до previous_secret_expires_at — это ровно 24 часа с момента смены. Окно фиксированное, параметром его не задать. Пока оно открыто, принимаются оба ключа, затем — только новый.

Безопасность вебхуков — тот же HMAC, только наоборот

HMAC выше защищает ваши запросы к нам. Вебхук — это мы стучимся к вам («инвойс оплачен»). Тот же приём наоборот: мы подписываем каждый вебхук секретом вашего эндпоинта, а вы проверяете подпись, прежде чем поверить. Иначе любой, кто узнает адрес вашего вебхука, мог бы прислать поддельное «оплачено» и выманить товар.

X-Webhook-Signature: t={unix_seconds},v1={hex_hmac}

Подписывается строка {timestamp}.{request_body}. Схема совпадает со Stripe, поэтому библиотеки проверки от Stripe работают почти без правок; во время ротации секрета мы кладём в заголовок обе подписи. См. Проверка вебхуков.

Защита от SSRF

SSRF (Server-Side Request Forgery — «подделка запроса со стороны сервера»). Вы задаёте адрес вебхука, и наши серверы ходят на него. Хитрый злоумышленник укажет URL не наружу, а внутрь нашей сети — на адрес облачных метаданных или внутреннюю панель — и наш сервер сходит туда за него, превратив Paymos в «прокладку» к тому, что видно только из нашей сети.

Мы это предотвращаем: адрес вебхука проверяется на то, что ведёт на публичный адрес — loopback, приватные, внутренние диапазоны и метаданные отклоняются, — а соединение «прибивается» к проверенному адресу, чтобы не было окна для DNS-rebinding. Редиректы не выполняем. Адрес, не прошедший проверку, сразу отбрасывается, поэтому «прощупывать» бесполезно.

Аналогия. Курьер, который доставляет только на реальные внешние адреса, отказывается нести «в серверную этого же здания», проверяет адрес до выхода и не ведётся на записку «вообще-то отнеси вон туда».

Семантика доставки

URL вебхука должен быть на HTTPS (проверяется при сохранении). Доставка — не реже одного раза: дедуплицируйте по идентификатору события на своей стороне (так делают Stripe, GitHub, PayPal). Неуспешные доставки повторяются с экспоненциальной задержкой — всего 11 попыток примерно за 16 часов, полное расписание см. в Доставке и повторах, — затем помечаются неуспешными и доступны для переотправки из дашборда. У каждой попытки свой тайм-аут.

Защита вывода — несколько замков подряд

Вывод средств — самое уязвимое место кастодиального шлюза, поэтому слоёв тут больше всего:

  • Белый список (обязателен). Вывод уходит только на адреса, одобренные заранее. Если для семейства сетей список пуст — вывод нельзя создать вообще; лазейки «первый вывод задаёт адрес» нет. Даже с угнанными ключами слать можно лишь на ваши же кошельки, так что у кражи ключей пропадает смысл. Аналогия: счёт, который переводит только на заранее зарегистрированный список получателей — вор с вашим паролем нового не впишет.
  • Разделение обязанностей. Менять белый список может только владелец аккаунта — это право не входит даже в набор администратора. Отправлять выводы на уже одобренные адреса умеет роль «Финансы»: она двигает деньги в границах, которые очертил кто-то другой. Выдача любого права попадает в аудит.
  • Второй фактор (2FA). Шестизначный код из приложения, меняется каждые 30 секунд; добавленный passkey работает вместо него. По умолчанию он выключен, и подключают его вручную — но именно он включает повторное подтверждение на опасных действиях: изменить белый список выводов, поправить список разрешённых IP у API-ключа или отключить сам второй фактор без свежего кода уже не выйдет.
  • Заморозки (стоп-кран). Можем заморозить всё сразу, один токен в одной сети или одного мерчанта. Заморозка по активу включится сама, если балансы в блокчейне разойдутся с учётом сверх безопасного порога.
  • Проверка баланса до приёма. Сумма вывода вместе с комиссией сети сверяется с вашим доступным балансом ещё до того, как запрос принят. Не хватает — приходит insufficient_balance, и вывод не создаётся: ничего не повисает.
  • Идемпотентность. Ваш идентификатор заказа — ключ идемпотентности: пришлёте его дважды — получите тот же единственный вывод, а не второй перевод. Аналогия: номерок гардероба; сдадите его дважды — получите одно и то же пальто.
  • Безопасность при гонках. Параллельные запросы на вывод для одного аккаунта выстраиваются в очередь на сервере, поэтому два одновременных вызова не проскочат мимо одной проверки баланса.

Авторизация и изоляция

  • Каждый запрос проверяется на сервере перед любым действием: среда ключа должна совпадать со средой ресурса, прав ключа должно хватать на операцию, а ресурс должен принадлежать вызывающему. Интерфейс лишь показывает результат этих проверок.
  • 404, а не 403. Если ресурса нет — или он есть, но не ваш — вы получите 404. Так не отличить «такой ID существует, но не твой» от «такого ID нет». Аналогия: швейцар говорит «такого нет» и когда человека нет, и когда он есть, но вам нельзя.
  • Кто вы — берётся из ключа, а не из тела запроса. Подставить чужой идентификатор бесполезно: действовать от имени другого мерчанта, подменив ID, нельзя.
  • Гранулярные права. Доступ управляется тонкими ролевыми правами (например: вывод, просмотр баланса, управление вебхуками), каждое выдаётся отдельно. Граница — серверная проверка; дашборд лишь отражает её.

Ограничение частоты запросов

У каждого мерчанта свои лимиты. Превысили — приходит 429 Too Many Requests с заголовком Retry-After, поэтому одна «сбойная» интеграция бьёт только по своей пропускной способности, а не по платформе и не по другим мерчантам.

Финальность в блокчейне — почему «деньги не пропадут»

В блокчейне транзакция «появляется» в блоке быстро, но недавнюю историю цепочка ещё может переписать (реорг) — и то, что выглядело подтверждённым, исчезает. Как сырые чернила: вроде написано, но ещё может смазаться.

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

Главное обещание: если уже подтверждённый платёж всё же выпадет при реорге (большая редкость) — убыток берёт Paymos, а не вы. Как пришёл вебхук о подтверждении — на него можно реагировать сразу. Бонусом: нет возвратных платежей (chargeback) — в отличие от карт, оплату по которым покупатель отменяет много месяцев спустя, — и поздний платёж невозможен в принципе: оплата, подтверждённая после истечения инвойса, на этот истёкший инвойс не зачислится.

Защита данных

В пути: весь трафик по TLS 1.2+, в рабочей среде включён HSTS, незашифрованные запросы перенаправляются на HTTPS.

В покое: сессионные куки — HttpOnly, Secure, SameSite=Strict; ссылки для входа одноразовые, быстро истекают и хранятся зашифрованными.

Защита от подделки запроса (CSRF): действия в дашборде, меняющие состояние, несут анти-CSRF-токен, который вместе с куками SameSite=Strict снимает риск межсайтовой подделки.

Журнал аудита: по каждому значимому действию записывается, кто его выполнил, что именно сделано, когда и с каким результатом. Чувствительные значения — секреты, пароли, токены, хеши, подписи — затираются ещё до записи.

Операционная устойчивость

  • Безопасность на нескольких серверах. Работа в несколько серверов не приводит к повторной обработке платежа, вывода или вебхука: параллельные операции над одним объектом согласованы так, чтобы выполниться ровно один раз. Проверяется автотестами, а не «на честном слове».
  • Отчёты об ошибках без утечки данных. Из отчётов о сбоях вычищаются персональные данные и содержимое запросов до того, как они покинут наши системы.
  • Безопасные изменения схемы. Миграции базы применяются один раз, по порядку и только «вперёд» — без разрушительных откатов по рабочим данным.

Комплаенс и работа с данными

KYC в Paymos нет. Начать тестирование можно без документов о личности, адресе и бенефициарах; Paymos также не собирает такие документы у ваших клиентов. В продукте нет ни анкеты, ни загрузки документов, ни отдельного шага, который открывал бы рабочий режим. Paymos не проверяет бизнес, лицензии и категории мерчантов и не проводит санкционный скрининг клиентов — эти обязанности остаются у мерчанта; где проходит граница, описано в политике AML.

Данные на стороне клиента. Изначально Paymos не собирает персональные данные ваших клиентов на странице оплаты — ни email, ни телефон, ни имя, ни данные карты. Поток: инвойс → платёжная страница → кошелёк платит → готово. Мы видим адреса кошельков и суммы, а не личности, поэтому ваши риски по GDPR/CCPA через Paymos практически нулевые.

Данные на стороне мерчанта. По вашему аккаунту мы храним название бизнеса, контактный email, страну и метаданные проектов (URL вебхуков, идентификаторы API-ключей). Права по GDPR, включая удаление, и адрес для запроса — в Политике конфиденциальности.

Чего мы не делаем

  • Не заявляем то, чего не построили. Эта страница описывает систему как она развёрнута. Планы развития не появляются здесь, пока не выпущены.
  • Не держим средства дольше, чем нужно. Деньги на балансе с момента подтверждения; когда выводить — решаете вы.
  • Не складываем балансы в общий котёл. Каждый баланс раздельный. Неплатёжеспособность или спор одного мерчанта не дотянется до средств другого. Именно смешение средств в общий котёл погубило биржи вроде FTX.
  • Не обещаем безопасность на стороне получателя. После подписи вывода транзакция уже в блокчейне и необратима. Белый список спасает от опечаток и кражи ключей — но не проверит, как поведёт себя одобренный вами адрес.

Сообщить об уязвимости

Присылайте на [email protected].

  • Подтверждение получения: в течение двух рабочих дней после полного отчёта
  • Область программы: рабочие paymos.io и *.paymos.io, публичный REST API, опубликованные Paymos SDK и модули CMS
  • Вне области: отказ в обслуживании через лимиты частоты, социальная инженерия, сторонние сервисы (ваш CDN, хостинг и т.п.)
  • Вознаграждение за уязвимости (bug bounty): публичной программы пока нет; приватное раскрытие значимых находок вознаграждается индивидуально, с упоминанием по запросу.

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

Серверные SDK