Как ограничить доступ к API через списки IP

Функциональность доступна не на всех проектах. Уточните возможность подключения у менеджера вашего проекта.

Ограничение доступа по IP к API — это второй фактор защиты API Mindbox в дополнение к секретному ключу. Даже если ключ окажется в чужих руках, запросы с неизвестных IP-адресов будут отклонены, а данные клиентов защищены.

Доступ к настройке

Для редактирования списка нужны пермиссии:

  • «Просмотр интеграций»
  • «Редактирование интеграций»
  • «Управление списком разрешенных IP для API»

По умолчанию все эти пермиссии есть у групп безопасности «Владельцы» и «Инженер по безопасности». При необходимости их можно выдать другим сотрудникам.

В каких точках интеграции работает фильтр

  • Веб-сайт
  • iOS / Android приложение
  • Данные для аналитики
  • Другое
Почему функции нет в других точках интеграции
  • Интеграция для вебхуков — отправляет только исходящие запросы из Mindbox во внешние сервисы (например, CRM). Подробнее о вебхуках в статье;
  • Продуктовые фиды — не принимает входящие запросы, Mindbox сам получает фид по URL;
  • Рекламные кабинеты — список IP зафиксирован адресами Albato;
  • Кошелек — список IP зафиксирован адресами Кошелька.

Шаги настройки

  1. Откройте раздел Интеграции и перейдите в точку интеграции:

    endpoint-ip-list.png

  2. В блоке «Настройки доступа по IP» введите адреса вашей инфраструктуры — каждый адрес с новой строки. Допустимый формат описан ниже.

  3. При необходимости поставьте галочку «Проверять IP-адреса только в запросах с секретным ключом» - см. как работает опция.

  4. Нажмите «Сохранить» в блоке, а затем «Сохранить» на странице интеграции.

    endpoint-ip-setting.png

Фильтр начнет отклонять запросы с неразрешенных IP через 5 минут после сохранения точки интеграции.

Точки интеграции с настроенным ограничением IP-адресов отображаются в списке с иконкой щита:

endpoint-ip-list-protected.png

Формат списка IP-адресов

Поддерживается:

  • одиночные IPv4-адреса: 130.193.65.96;

  • подсети в формате CIDR в каноническом виде: 130.193.65.96/30;

    Как привести запись к каноническому виду

    1. «Круглые» маски (/8, /16, /24, /32)

      • /32 — всегда каноническая: 1.2.3.4/32

      • /24 — последний октет равен 0:

        Канонический Неканонический
        1.2.3.0/24 1.2.3.7/24

      • /16 — последние два октета 0:

        Канонический Неканонический
        1.2.0.0/16 1.2.3.0/16

      • /8 — последние три октета 0:

        Канонический Неканонический
        1.0.0.0/8 1.2.0.0/8

    2. «Некруглые» маски

    Маска Допустимые значения последнего октета
    /31 любое четное число (0, 2, 4, 6, 8, …)
    /30 кратно 4 (0, 4, 8, 12, …)
    /29 кратно 8 (0, 8, 16, 24, …)
    /28 кратно 16 (0, 16, 32, 48, …)
    /27 кратно 32 (0, 32, 64, 96, 128, 160, 192, 224)
    /26 кратно 64 (0, 64, 128, 192)
    /25 только 0 или 128

  • комментарии после # в той же строке: 130.193.65.96 # прод-балансировщик Москва;

  • до 100 строк в одной точке интеграции;

  • длина строки — не более 120 символов.

Не поддерживается:

  • диапазоны через дефис: 130.193.65.96 — 130.193.65.97;

  • несколько записей в одной строке: 130.193.65.96/30, 130.193.65.92 # прод-балансировщик Москва;

  • адреса специального назначения: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — фильтр работает только с публичными IP;

    Список адресов, которые попадают под ограничение
    CIDR Категория
    0.0.0.0/8 Служебный, RFC 1122
    10.0.0.0/8 Частный, RFC 1918
    100.64.0.0/10 CGNAT, RFC 6598
    127.0.0.0/8 Loopback, RFC 1122
    169.254.0.0/16 Link-local, RFC 3927
    172.16.0.0/12 Частный, RFC 1918
    192.0.0.0/24 Служебный протокольный, RFC 6890
    192.0.2.0/24 Документационный, RFC 5737
    192.88.99.0/24 Отключен, RFC 7526
    192.168.0.0/16 Частный, RFC 1918
    198.18.0.0/15 Бенчмаркинг, RFC 2544
    198.51.100.0/24 Документационный, RFC 5737
    203.0.113.0/24 Документационный, RFC 5737
    224.0.0.0/4 Multicast, RFC 5771
    240.0.0.0/4 Зарезервированный / Class E, RFC 1112
    255.255.255.255/32 Broadcast, RFC 919

  • маска /0 (разрешает доступ с любого IP).

Опция «Проверять IP только в запросах с секретным ключом»

Галочка определяет, какие запросы попадают под фильтр:

Состояние

Что фильтруется

Когда выбрать

Снята

Все входящие запросы в точку интеграции, включая запросы без секретного ключа и события из JS-трекера

Трафик через точку интеграции исходит только из вашей инфраструктуры.

Не рекомендуется использовать для интеграций с типом Веб-сайт или iOS / Android приложение. Вызовы из них невозможно полностью проксировать.

Поставлена (по умолчанию)

Только запросы с основным секретным ключом.

Запросы от конечных пользователей (например, события с JS-трекера) проходят без проверки IP-адреса

Для большинства интеграций с типом Веб-сайт или iOS / Android приложение, где запросы приходят с IP покупателя, а не сервера (например, просмотры продуктов, изменение списков клиента и др.)

Запросы с тестовым секретным ключом никогда не попадают под фильтр — это сделано, чтобы менеджеры проектов и поддержки могли отлаживать промоакции и интеграции.

Что происходит при блокировке запроса

Mindbox проверяет фактический IP-адрес сервера, с которого был отправлен запрос. Этот же IP отображается в заголовке X-Forwarded-For.

Отклоненный запрос возвращает статус 403 с ответом:

Incorrect IP address 1.2.3.4 for endpoint ’<system name>’

Где 1.2.3.4 — фактический IP отправителя, а <system name> — системное имя точки интеграции.

При большом количестве заблокированных запросов на проекте открываются проблемы.

История изменений

Все действия со списком IP (кто и когда вносил изменения) логируются в Журнал событий. Для их просмотра перейдите по ссылке «История изменений» или отфильтруйте записи журнала по типу события «Редактирование настроек доступа по IP».

endpoint-ip-changelog.png

Предыдущая
Как создать и настроить точку интеграции
Следующая
Рекомендации по обеспечению безопасности ключей