Также: API gateway, шлюз API
API-шлюз – единая точка входа для вызовов API, которая проверяет, кто и что запрашивает, и ограничивает опасные запросы.
Современные сервисы передают данные между собой и мобильными приложениями через API, и через них же утекают ПДн: слишком широкие права, отсутствие проверки владельца записи, перебор идентификаторов. Шлюз собирает защиту в одном месте, а не в каждом сервисе по отдельности.
Шлюз стоит перед сервисами и принимает все вызовы. Он проверяет подлинность клиента (токены OAuth 2.0, ключи, сертификаты), права доступа к методу и объекту, формат и размер запроса по описанию API (OpenAPI), ограничивает частоту запросов, шифрует канал, ведет журнал и отдает его для анализа. Часть решений обнаруживает аномальное поведение и нелегитимный перебор.
Не исправляет ошибки логики самого сервиса, такие как нарушение авторизации на уровне объекта: шлюз не знает, чья именно запись запрашивается. Не защищает от атак на другие точки входа в обход шлюза. Неактуальное описание API ведет к ложным блокировкам или пропускам. Не заменяет безопасную разработку.
Отдельной сертификации API-шлюзов как класса нет. Если шлюз выполняет функции межсетевого экрана веб-приложений или ставится на границе информационной системы, могут применяться требования ФСТЭК России к межсетевым экранам; шифрование канала выполняют сертифицированные СКЗИ, если это требуется моделью угроз. Решение принимают по уровню защищенности ИСПДн.
Меры приказа ФСТЭК № 21: УПД.2 (реализация методов и правил разграничения доступа), ИАФ.1 и ИАФ.6 (идентификация и аутентификация работников и внешних пользователей), УПД.3 (управление информационными потоками), ЗИС.3 (защита ПДн при передаче), РСБ.3 (регистрация событий). Для API, отдающих ПДн, шлюз помогает показать контроль доступа и журнал обращений.
- Поддержка нужных способов аутентификации (OAuth 2.0, JWT, mTLS) и интеграция с вашим каталогом.
- Проверка запросов по описанию OpenAPI, лимиты частоты, защита от перебора.
- Журналы и выгрузка в SIEM, маскирование ПДн в журналах.
- Производительность и задержки, отказоустойчивость.
- Поддержка в российских условиях и совместимость с инфраструктурой (контейнеры, Kubernetes).
- Возможность видеть все API, включая забытые и недокументированные.
Platform V Synapse API Mesh (СберТех), Вебмониторэкс, Kong Gateway (открытый код, без сертификата). Это не рекомендация. Наличие, тип, класс и срок действия сертификата каждого продукта проверять в реестре на дату закупки.
Перечень API, отдающих ПДн, способ аутентификации и проверки прав, журнал обращений, лимиты, результаты тестирования на проникновение, наличие забытых и недокументированных API. Типичная ошибка: проверяют роль пользователя, но не проверяют принадлежность записи, поэтому по подбору идентификатора можно получить чужие данные.
Примеры применения (3)
- Мобильное приложение получает данные пользователя только по токену, а шлюз ограничивает число запросов в минуту.
- Для внутренних сервисов включена взаимная проверка сертификатов (mTLS).
- Описание API сверяется с реальным трафиком, найденные забытые методы закрываются.
Связанные понятия
Источники (3)
- Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»
- OWASP API Security Project
- ISO/IEC 27002:2022 «Information security, cybersecurity and privacy protection – Information security controls»
Как это проверяют на аудите: курс «Аудитор ИСПДн 2.0» Все средства защиты
Материал: Школа персональных данных № 1. Обновлено 02.10.2026