Безопасность, соответствие PCI DSS и защита данных
Обзор и принципы
Безопасность API платежей — фундамент нашего сервиса. Мы строим процессинг и интеграции так, чтобы чувствительные данные карт не оказывались в зоне риска, а ваши клиенты оплачивали покупки быстро и безопасно. Подход включает соответствие требованиям PCI DSS, "по умолчанию безопасные" настройки, избирательный доступ, глубокий мониторинг и прозрачную отчетность.
Ключевые векторы защиты:
- Защита данных при передаче и хранении: шифрование TLS, токенизация, изоляция сред.
- Сильная аутентификация плательщика: 3DS 2.0 безопасность.
- Многоуровневый контроль доступа и хранение секретов API по принципу наименьших привилегий.
- Интеграции без хранения PAN на стороне мерчанта, чтобы упростить PCI DSS платежи и снизить риски.
Для начала работы изучите страницы: Прием платежей через API, Быстрый старт интеграции и Документация API.
Соответствие PCI DSS и зоны ответственности
Мы разрабатываем и эксплуатируем платформу в соответствии с стандартом PCI DSS v4.0, регулярно проходим внешние оценки и тесты на проникновение. Это позволяет обрабатывать данные карт безопасно и предсказуемо.
Как это влияет на мерчанта:
- Если вы используете наши хостовые решения (SDK/виджеты) и не обрабатываете PAN на своих серверах, вы, как правило, подпадаете под упрощенную самооценку saq a pci.
- При прямом серверном приеме реквизитов (например, кастомные формы без токенизации) зона соответствия расширяется и может потребовать SAQ D.
Таблица зон ответственности
| Контроль PCI DSS |
Что делаем мы |
Что делает мерчант |
| Сегментация и защита среды обработки карт |
Сегментируем сети, используем IDS/IPS, изолируем среду |
Не хранить PAN, использовать рекомендованные SDK |
| Шифрование данных при передаче |
Принудительно TLS 1.2+/1.3, HSTS, PFS |
Включить HTTPS для всех интеграций, актуальные cipher suites |
| Шифрование/токенизация при хранении |
Токенизация карт, шифрование ключами HSM |
Не сохранять PAN/CSC, хранить только токены |
| Доступ и управление учетками |
RBAC, MFA, журналирование |
Настроить роли и MFA для своей команды |
| Тестирование и мониторинг |
EDR/SIEM, внешние пентесты |
Регулярный код‑ревью, сканирование зависимостей |
Если вы сомневаетесь, как корректно сузить область соответствия, обратитесь к нашей команде или изучите разделы Методы оплаты и Рекуррентные платежи — там описаны интеграционные паттерны, упрощающие SAQ.
Шифрование TLS: защита данных при передаче
Для всех конечных точек API и платежных форм действует шифрование tls платежи на базе TLS 1.2+ (рекомендуем TLS 1.3) с поддержкой Perfect Forward Secrecy. Мы применяем:
- Политику HSTS и редиректы на HTTPS.
- Современные наборы шифров и строгую валидацию сертификатов.
- ALPN/HTTP2 для оптимальной производительности.
![Схема шифрования трафика TLS между мерчантом, платформой и банками-эквайерами — диаграмма-плейсхолдер]
Рекомендации для интеграции:
- Отключите устаревшие протоколы (TLS 1.0/1.1). Проверьте ciphers на своем сервере.
- Включите проверки hostname и pinning там, где допустимо, особенно в мобильных приложениях (Mobile SDK).
Токенизация карт и минимизация рисков хранения
Токенизация карт — ключ к снижению рисков и упрощению PCI DSS. Вместо PAN мы храним и обмениваемся surrogate-значениями (токенами), которые непригодны за пределами нашей платформы.
Основные типы токенов:
- Одноразовые токены для разовых платежей.
- Токены для card-on-file и подписок — безопасная основа для Рекуррентных платежей.
- Поддержка сетевых токенов (network tokens) там, где доступно.
Выгоды:
- Снижение ответственности мерчанта и упрощение SAQ A PCI.
- Мгновенная аннулируемость токена при компрометации.
- Минимальная поверхность атаки: PAN не проходит через ваши сервера.
Если требуется хранение чувствительных переменных, используйте выделенные секрет‑хранилища и не пытайтесь кешировать реквизиты карточек локально.
3DS 2.0: сильная аутентификация без трения
3DS 2.0 безопасность обеспечивает дополнительную проверку плательщика эмитентом, повышая одобрения и снижая риск чарджбеков. Мы поддерживаем как frictionless, так и challenge‑потоки, передавая расширенный набор контекста транзакции (device, адрес, история покупок) для корректной оценки риска ACS.
Преимущества 3DS 2.0:
- Больше одобрений благодаря risk‑based аутентификации.
- Меньше отказов из‑за снятия трения у добросовестных клиентов.
- Перенос ответственности за фрод на банк‑эмитент при успешном прохождении 3DS.
В API доступны гибкие сценарии включения/исключения 3DS по типу платежа и рисковому профилю. Подробности — в Документации API.
Контроль доступа (RBAC) и хранение секретов API
Безопасный периметр начинается с правильной модели доступа. Мы предлагаем контроль доступа rbac с преднастроенными ролями:
- Owner/Администратор: полные права, управление ключами и командами.
- Разработчик: управление интеграциями, просмотр логов, без финансовых операций.
- Финансы/Аналитика: доступ к отчетам и выплатам без изменения настроек.
- Read‑only/Поддержка: просмотр ограниченного набора данных.
Хранение секретов api:
- Ключи API, секреты вебхуков и OAuth‑токены шифруются и ротируются; поддерживается ограничение по IP и времени.
- Разделение prod/sandbox: используйте Песочницу и тестирование для безопасной отладки.
- Рекомендуем использовать менеджеры секретов (Vault/KMS), исключить хранение ключей в переменных окружения без шифрования и в репозиториях кода.
Безопасность вебхуков: подпись, WAF и защита от подмены
Вебхуки передают статусы платежей и служебные события. Чтобы исключить злоупотребления:
- Каждый запрос подписывается HMAC‑SHA256 на основе общего секрета. Наши библиотеки автоматически проверяют заголовки и метку времени, исключая повторное воспроизведение.
- Доступ к конечным точкам защищает waf для вебхуков, фильтрующий аномальные запросы и блокирующий злоумышленников по поведенческим признакам.
- Возможна привязка по исходящим IP, rate‑limit и повторная доставка с экспоненциальной задержкой.
Включена защита от подмены подпись: некорректная или просроченная подпись отклоняется. См. раздел Вебхуки и события с примерами кода и рекомендациями по безопасности.
Журналирование аудита и мониторинг
Прозрачность — неотъемлемая часть безопасности. Для всех действий админов, разработчиков и автоматических агентов ведется журналирование аудита:
- Изменения настроек, ключей, прав и вебхуков.
- Административные входы, MFA‑события, ошибки аутентификации.
- Технические логи API вызовов с маскированием чувствительных полей.
Мы агрегируем метрики и события в централизованную систему мониторинга, настраиваем алерты по SLA и аномалиям. Для финансовых команд доступны Отчеты и выгрузки с детализацией статусов, возвратов и действий пользователей.
Антифрод и риск-менеджмент
Техническая безопасность дополняется управлением рисками. Встроенный движок позволяет применять правила по устройствам, географии, суммам и историческим поведенческим метрикам. Подробно — в разделе Антифрод и риск.
Советы:
- Включите динамические правила по корзинам товаров и среднему чеку.
- Используйте 3DS 2.0 для транзакций с повышенным риском.
- Включите прогрессивные лимиты и требование повторной аутентификации для подозрительных сценариев.
Чек‑лист безопасной интеграции
Чтобы быстро запустить и сохранить высокий уровень защиты, следуйте этому списку:
- Выберите интеграцию, минимизирующую область PCI (виджеты/SDK, токенизация). См. Быстрый старт интеграции.
- Обменивайтесь только токенами, не логируйте PAN/CSC.
- Включите подписи вебхуков и валидацию метки времени. Инструкции — Вебхуки и события.
- Ограничьте ключи API по ролям и IP, храните секреты в защищенных хранилищах.
- Примените TLS 1.2+/1.3 и современный набор шифров, используйте HSTS.
- Проверьте обработку возвратов и отмен — Возвраты и отмены.
- Для подписок используйте токены и автоматику — Рекуррентные платежи.
- Мобильные приложения — через Mobile SDK. Готовые интеграции — CMS плагины.
- Тестируйте сценарии в Песочнице и тестировании и оформляйте выпуск ключей через change‑management.
Непрерывность, SLA и реагирование на инциденты
Наша инфраструктура строится с учетом отказоустойчивости: георезервирование, многоузловые кластеры, автоматическое восстановление и резервное копирование. Для критичных компонентов определены RTO/RPO и процедуры регулярных учений.
![Диаграмма непрерывности и SLA — иллюстрация-плейсхолдер]
Выводы и следующий шаг
Безопасность платежей — это сочетание технологий, процессов и дисциплины. Шифрование TLS, токенизация карт, 3DS 2.0 и строгий RBAC снижают риски, а соответствие PCI DSS структурирует контроль. Следуйте лучшим практикам, используйте вебхуки с подписью и храните секреты правильно — так вы сохраните доверие клиентов и стабильность бизнеса.
Готовы начать? Перейдите к Документации API, пройдите Быстрый старт интеграции и протестируйте в Песочнице и тестировании. Если нужны рекомендации по архитектуре безопасности или оценке SAQ, свяжитесь с нашей командой поддержки — мы поможем запустить безопасно и быстро.
