Если ваш инвентарь API не актуален, вы не видите полную поверхность, которую, как думаете, защищаете.
В большинстве организаций инвентарь API живёт в документации приложений, устаревших файлах схем или списках, поддерживаемых отдельными командами. Но приложения меняются с каждым релизом: добавляются новые эндпоинты, старые забываются, тестовые пути остаются в production. Команды безопасности обычно узнают, какие API активны в реальном трафике, позже, чем команды разработчиков.
Этот разрыв усиливает риск shadow API и zombie-эндпоинтов. Недокументированный эндпоинт может полностью находиться вне политики WAF; эндпоинт, который больше не должен использоваться, может оставаться доступным. С точки зрения злоумышленника эти области имеют низкую видимость, слабо защищены и заслуживают исследования.
Полагаться только на внешне предоставленный файл схемы также недостаточно. Если схема неактуальна, она не будет соответствовать реальному трафику. Команда приложения могла изменить эндпоинт без обновления схемы, или путь, который никогда не фигурирует в схеме, может работать в production. В этом случае политика защиты опирается на устаревшее предположение, а не на реальное поведение приложения.
Традиционная негативная модель безопасности сама по себе не решает эту проблему. Блокировка известных паттернов атак важна, но настоящая сила в безопасности API — явное определение разрешённых методов, заголовков, параметров, MIME-типов и полей тела. Без позитивной безопасности неизвестные, но внешне корректные вредоносные запросы могут проходить без проверки.
TR7 API Discovery & Schema закрывает этот разрыв: изучает поведение API из реального трафика, поддерживает генерацию схемы из OpenAPI-потока или генерацию правил из схемы и внедряет контроли позитивной безопасности inline.
Наш подход
TR7 применяет API discovery совместно с обучением на трафике, позитивной схемой, ограничениями размера и глубины, а также валидацией на уровне поля.
Паттерны эндпоинтов извлекаются из трафика через группировку путей
TR7 может изучать поведение путей и методов из реального трафика и строить паттерны эндпоинтов. Пути, содержащие переменные ID, даты или токены, нормализуются в более читаемый инвентарь API.
Позитивная модель безопасности основана на разрешённой схеме
Allow-листы могут быть определены для методов, заголовков, параметров запроса, JSON-ключей, XML-элементов, полей форм и MIME-типов. Вместо того чтобы только искать известные плохие паттерны, политика явно декларирует ожидаемое поведение API.
Ограничения размера, глубины и количества ограничивают злоупотребления
Можно применить ограничения длины пути, глубины пути, количества заголовков, количества параметров запроса, глубины JSON, глубины XML и размера тела. Эти ограничения обеспечивают проверку слишком больших или слишком сложных запросов до того, как они достигнут бэкенда.
Regex-валидация на уровне поля проверяет формат данных
Regex-валидация может быть определена для каждого заголовка, параметра запроса, поля формы или поля тела. Email, телефон, ID, код страны или форматы, специфичные для сервиса, проверяются на уровне поля.
Возможности
API Discovery & Schema превращает выученный инвентарь эндпоинтов в применяемые позитивные правила безопасности.
Группировка путей на основе трафика создаёт реальный инвентарь API
TR7 может анализировать информацию о путях и методах из входящих запросов для получения паттернов эндпоинтов. Пути вроде `/api/users/123` и `/api/users/456` могут быть сгруппированы под единый логический паттерн. Этот подход делает видимыми эндпоинты, отсутствующие в документации, но активно работающие в production. Инвентарь API основан на реальном поведении трафика, а не на предположениях.
Выученная структура может перетечь в схему, а схема — в правила через OpenAPI-поток
TR7 позиционирован для поддержки потока генерации OpenAPI-совместимых схем из выученного поведения API. В обратном направлении из OpenAPI-схемы, предоставленной пользователем, могут быть сгенерированы правила TR7. Эта двунаправленная модель уменьшает разрыв между реальным трафиком и задокументированным API-контрактом. Оператор использует ту же платформу как для discovery, так и для enforcement.
Разрешённые методы применяют allow-лист методов на уровне эндпоинта
Список разрешённых методов — GET, POST, PUT, DELETE, PATCH и другие — может быть определён на каждый эндпоинт. Например, если POST отправляется на эндпоинт, ожидающий только GET, это поведение может рассматриваться как нарушение политики. Allow-лист на основе метода — простой, но эффективный позитивный слой безопасности. Некорректное или злоупотребительное поведение эндпоинта перехватывается раньше.
Allow-листы заголовков и параметров запроса сужают поверхность запросов
Разрешённые заголовки и параметры запроса могут быть определены на каждый эндпоинт. Для каждого поля может применяться имя, формат значения и regex-валидация. Неожиданные заголовки или параметры могут быть привязаны к scoring безопасности, оповещению или блокировке. Данные вне API-контракта, таким образом, не передаются на бэкенд без проверки.
Поля JSON, XML и форм валидируются по позитивной схеме
TR7 может строить allow-листы на уровне JSON-ключей, XML-элементов и полей форм. Обязательные поля могут быть определены через mustArgs; неизвестные поля могут быть исключены из разрешённого списка. Эта структура описывает ожидаемое тело запроса, а не только ищет сигнатуры атак. API-эндпоинты защищаются способом, остающимся ближе к их собственному контракту. SOAP покрывается тем же путём: конверт SOAP — это XML, поэтому структура конверта, злоупотребление заголовком SOAPAction и враждебные конструкции проверяются как XML, а рядом со схемными проверками работают отдельные сигнатуры для инъекции в SOAPAction. Для AJAX отдельный механизм тоже не нужен: вызов XHR или fetch приходит как тело JSON или формы и проверяется именно в этих областях.
Контроли MIME-типов блокируют неожиданные типы контента
Allow-листы разрешённых MIME-типов могут быть определены для формы и тела. Отправка данных на ожидающий JSON эндпоинт с другим типом контента может рассматриваться как нарушение политики. Этот контроль особенно важен для API, основанных на загрузке файлов или форм. Тип контента становится прямым входом в решение безопасности.
Ограничения размера и глубины снижают риск слишком больших нагрузок
Общие ограничения размера могут применяться для заголовков, строк запроса, форм, JSON, XML и тела. Контроли глубины вложенности JSON и XML предотвращают добавление слишком глубокими нагрузками нагрузки на парсер и бэкенд. Также могут быть определены ограничения количества ключей, количества значений, длины на поле и количества дублирований. Эти контроли создают защитную границу как для безопасности, так и для производительности.
Переключатели Block JSON и Block XML ограничивают тип тела эндпоинта
Некоторым эндпоинтам вовсе не нужно принимать JSON или XML тела. TR7 может предоставить контроли для полного отключения использования JSON или XML тела на основе каждого эндпоинта. Это предотвращает достижение неожиданных форматов тела бэкенда. Особенно эффективно для простых GET-эндпоинтов и сервисов, не принимающих нет-форменные транзакции.
Regex на уровне поля валидирует формат данных на уровне поля
Regex-валидация может применяться для каждого заголовка, параметра запроса, поля формы или поля тела. Email, телефон, UUID, числовой ID, код страны или форматы, специфичные для организации, проверяются таким образом. Значения с неверным форматом не оставляются приложению — они перехватываются на границе. Эта модель вносит размерность формата данных API-контракта в политику безопасности.
Рекомендации по shadow API и zombie-эндпоинтам выявляются
Эндпоинты, выученные из трафика, могут сравниваться с существующим задокументированным списком API. Активные эндпоинты, отсутствующие в документации, могут помечаться как кандидаты shadow API; эндпоинты, которые больше не должны получать трафик, но всё ещё получают, могут помечаться как кандидаты zombie-эндпоинтов. Эти рекомендации представляются как обучающие предложения для проверки оператором, а не как абсолютные решения enforcement. Команды безопасности могут быстрее составить карту реальной API-поверхности.
Обнаружение дрейфа схемы улавливает изменяющееся поведение API
Со временем могут появляться новые JSON-ключи, новые параметры запроса или различное использование методов. TR7 может делать видимыми различия между выученным поведением и текущей политикой схемы. Эти различия могут сигнализировать об изменении версии приложения, неправильно работающем клиенте или попытке злоупотребления. Оператор может принять изменение и добавить его в схему или рассматривать как нарушение политики.
Отчёты о соответствии усиливают видимость активных эндпоинтов
API discovery помогает отчитываться, какие эндпоинты были активны в течение определённого периода. Вопросы вроде «Какие эндпоинты получали трафик за последние 30 дней?» важны для команд безопасности и соответствия. Инвентарь на основе трафика обеспечивает более реалистичную базу аудита, чем статический документ. Организация мониторит свою API-поверхность в сравнении с реальным поведением.
Операционная глубина
Контроли API discovery и схемы работают в областях пути, запроса, заголовка, формы, JSON, XML и raw.
Семь областей схемы
Контроли схемы TR7 охватывают поля пути, запроса, заголовка, формы, JSON, XML и raw. Каждая область может иметь собственные ограничения, allow-листы и правила валидации. Безопасность API определяется по всей поверхности запроса, а не только по телу.
Разнообразие типов правил
Правила схемы могут быть определены с различными типами, такими как complexInput, regex, numeric, boolean и enumSelect. Простые вкл/выкл контроли и подробные списки полей управляются в рамках одного DSL. Оператор выбирает тип правила исходя из поведения API.
Целевые области
Правила могут применяться на различных целевых уровнях: web application, api endpoint и application server. Это позволяет разграничить общую политику сервиса и схему, специфичную для одного эндпоинта. Выбор правильной области создаёт политику с меньшим количеством повторений и более чётким диапазоном действия.
Структура дерева обучения
Модель обучения может хранить узлы на каждый путь, счётчики частоты и информацию о дочерних путях. Сводная информация может извлекаться по хосту или группе сервисов. Эта структура помогает понять, какие части API-поверхности имеют высокий трафик, разреженны или появляются впервые.
Рабочий процесс рекомендаций и одобрения
Выученные изменения могут быть отправлены на одобрение администратора, а не применяться автоматически. Оператор рассматривает предложения по новым эндпоинтам, новым полям или новым паттернам и преобразует подходящие в политику. Эта модель позиционирует обучение как направляемую поддержку принятия решений, а не неконтролируемую автоматизацию.
Пакетный анализ логов
Исторические файлы логов могут быть проанализированы пакетно для ретроспективного получения поведения API. Это означает, что процесс discovery не ограничен только живым трафиком. Более ранние периоды трафика, временные окна кампаний или моменты инцидентов могут быть изучены отдельно.
Когда использовать
Обнаружение и видимость shadow API
Команды безопасности могут сравнивать список эндпоинтов, выученных из реального трафика, с существующей документацией API. Активные пути, отсутствующие в документации, принимаются для проверки как кандидаты shadow API.
Инвентаризация эндпоинтов на microservice gateway
Команды microservice могут видеть поведение эндпоинтов каждого сервиса из трафика, не дожидаясь ручной документации. TR7 помогает превратить инвентарь на основе путей и методов в политику безопасности.
Отчёт об активных API для аудита соответствия
Команды соответствия могут отчитываться, какие эндпоинты были активны в течение определённого периода. Это делает API-поверхность, обрабатывающую данные, более чётко видимой во время аудита.
Обнаружение тестовых эндпоинтов, оставшихся открытыми в production
Если эндпоинты, открытые для тестирования или staging, появляются в production-трафике, их можно заметить в рекомендациях обучения. Команда операций может затем закрыть, ограничить или поместить их под правильную политику безопасности.
Часто задаваемые вопросы
Как работает обучение с группировкой путей?
Как появляются рекомендации по shadow API и zombie-эндпоинтам?
Как работает интеграция с OpenAPI?
Чем позитивная модель безопасности отличается от негативной?
Что означает обнаружение дрейфа схемы?
На какие поля применяются ограничения размера и глубины?
Изучите и защитите вашу API-поверхность из реального трафика
Инвентаризация эндпоинтов на основе трафика, видимость shadow API и позитивные схема-правила — давайте пройдём через живую настройку на ваших собственных сервисах.