- Почему важно обнаруживать теневые API
- План проверки для обнаружения теневых API
- Шаг 1: Создание базового списка API
- Шаг 2: Сравнение документации с активностью во время выполнения
- Шаг 3: Поиск неизвестных конечных точек в журналах
- Шаг 4: Проверка кода, репозиториев и конвейеров CI/CD
- Шаг 5: Проверка открытости в облачных, Kubernetes и бессерверных средах
- Шаг 6: Анализ DNS и субдоменов на предмет открытости API
- Шаг 7: Обнаружение API извне
- Шаг 8: Проверка открытости и механизмов контроля доступа
- Шаг 9: Классификация конфиденциальной информации и бизнес-функций
- Шаг 10: Назначение ответственных и классификация API
- Шаг 11: Тестирование активных API на уязвимости
- Шаг 12: Приоритезация и устранение недостатков по реальному риску
- Шаг 13: Внедрение непрерывного управления для обнаруженных API
- Шаг 14: Постоянное обнаружение новых и измененных API
- Критерии выбора инструментов для обнаружения теневых API
- Как Invicti помогает обнаруживать и защищать теневые API
Появление теневых API возможно в любом месте, где реальная конфигурация отличается от задокументированной. Приведенный чек-лист позволяет обнаруживать недокументированные API на уровне кода, трафика, сетевых шлюзов, настроек DNS, инфраструктуры и приложений – для дальнейшей проверки их видимости, тестирования безопасности, закрепления ответственных лиц и восстановления контроля.
Теневые API представляют собой активные конечные точки API, существующие вне утвержденной документации, инвентаризации, процессов назначения ответственных или тестирования безопасности. Они могут возникать в процессе обычной разработки – временная конечная точка, которая становится постоянной, старая версия API, остающаяся доступной, бэкенд мобильного приложения, который никогда не попадает в центральный каталог, или сервис, развернутый вне стандартного шлюза API.
Независимо от происхождения, проблема безопасности одинакова: неизвестный API вряд ли будет подвергаться такому же тестированию, мониторингу и управлению, как и известный.
Приведенный чек-лист по обнаружению теневых API обеспечивает команды по безопасности приложений (AppSec), безопасности API, инфраструктурных платформ и разработки практическим алгоритмом для поиска недокументированных API, проверки их открытости, оценки безопасности и возвращения под контроль.
Под теневым API понимают активный API, существующий за пределами утвержденных организацией процессов инвентаризации, документирования, назначения ответственных или обеспечения безопасности. Теневой API не обязательно является уязвимым или вредоносным – однако пока он не обнаружен и не оценен, состояние его безопасности остается неизвестным.
Почему важно обнаруживать теневые API
Доступ к API в современных приложениях может открываться благодаря веб-приложениям, мобильным приложениям, микросервисам, бессерверным функциям, партнерским интеграциям, внутренним службам, облачной инфраструктуре и межмашинному взаимодействию. Из-за постоянного создания и изменения API различными командами в разных средах, задокументированный список часто начинает расходиться с тем, что развернуто на самом деле.
Это расхождение имеет прямые последствия для безопасности.
OWASP включает «Ненадлежащее управление инвентаризацией» (Improper Inventory Management) под пунктом API9:2023 в список OWASP API Security Top 10 2023. Другие риски для API включают нарушение авторизации на уровне объектов (BOLA), нарушение аутентификации, нарушение авторизации на уровне функций, неограниченный доступ к критическим бизнес-потокам и неправильную конфигурацию безопасности. Недокументированная конечная точка может потенциально содержать любую из этих уязвимостей – и при этом оставаться вне пределов регулярного тестирования безопасности.
Поэтому эта задача сложнее простого обнаружения неизвестного URL-адреса. Процесс обнаружения теневых API требует установления того, что именно существует, является ли оно фактически доступным, какие функции выполняет, кому принадлежит, какие данные обрабатывает, а также работают ли его средства контроля безопасности так, как предусмотрено.
| Риск теневых API | Почему это имеет значение |
| Неизвестная доступность | Конечная точка вне инвентаризации может также оказаться вне стандартных средств контроля безопасности. |
| Пробелы в аутентификации | Старые, временные или тестовые конечные точки могут использовать более слабые методы аутентификации, чем текущие сервисы. |
| Слабости авторизации | Недокументированные API могут обходить тестирование контроля доступа, применяемое к управляемым конечным точкам. |
| Раскрытие конфиденциальных данных | Неизвестные конечные точки могут создавать неотслеживаемые пути к клиентским, финансовым, медицинским, аутентификационным или корпоративным данным. |
| Отсутствие ответственных | Процесс исправления недостатков усложняется, когда за API никто не несет ответственности. |
| Пробелы в тестировании безопасности | API, отсутствующие в реестре для тестирования, могут оставаться непроверенными. |
| Отклонения жизненного цикла | Устаревшие версии могут оставаться доступными еще долго после их замены. |
| Пробелы в управлении | Неотслеживаемые API усложняют понимание и контроль поверхности атаки приложения. |
Эффективный подход к этой проблеме заключается в сопоставлении разных уровней видимости среды API:
- Документация указывает, что должно существовать.
- Код показывает, что разработано.
- Инфраструктура демонстрирует, что развернуто.
- Анализ среды выполнения выявляет то, что применяется.
- Внешнее сканирование определяет, к чему можно получить доступ.
Расхождения между этими данными указывают на места, где чаще всего появляются теневые API.
План проверки для обнаружения теневых API
Чтобы обнаружить теневые API, необходимо сравнить утвержденный реестр API с несколькими независимыми подтверждениями их наличия, а затем исследовать все активы, которые существуют в реальности, но не управляются официально.
Приведенный план проверки является начальным этапом для построения циклического процесса обнаружения API. Подробности выполнения каждого шага добавлены ниже.
| Шаг | Процесс обнаружения | Информация для сбора |
| 1 | Создание списка задокументированных API | Каталоги API, спецификации, маршруты шлюзов, реестры служб |
| 2 | Сопоставление документации с показателями выполнения | Запросы или конечные точки, не имеющие соответствия в спецификациях |
| 3 | Проверка журналов шлюзов и инфраструктуры | Неизвестные пути, методы, имена хостов, версии и клиенты |
| 4 | Инспекция исходного кода и систем развертывания | Маршруты, контроллеры, обработчики, спецификации API, бессерверные функции |
| 5 | Аудит облачной и контейнерной инфраструктуры | Маршруты шлюзов, функции, правила маршрутизации входящего трафика, сервисы, прямые пути доступа |
| 6 | Поиск в системах DNS и субдоменах | Имена хостов API, неактуальные записи, оставленные среды, открытый доступ к сервисам |
| 7 | Поиск внешне достижимых API | Хосты API, конечные точки, запросы от приложений, среды стейджинга, предварительные версии |
| 8 | Валидация открытости и средств контроля доступа | Аутентификация, авторизация, уровни привилегий, лимиты запросов, покрытие через шлюз |
| 9 | Классификация конфиденциальности данных и бизнес-рисков | Конфиденциальные данные, учетные записи, токены, операции с высокими привилегиями |
| 10 | Определение ответственности и этапа жизненного цикла | Владелец процесса, назначение для бизнеса, среда, статус (актуальный или устаревший) |
| 11 | Тестирование действующих API на уязвимости | Результаты динамического тестирования (DAST) и проверок безопасности API |
| 12 | Определение приоритетов и исправление | Уровень открытости, пригодность к эксплуатации, привилегии, конфиденциальность данных, влияние на деятельность компании |
| 13 | Интеграция API в системы постоянного контроля | Учет, мониторинг, регулярное тестирование, управление рисками безопасности |
| 14 | Циклическое обнаружение и мониторинг изменений в реестрах | Только что обнаруженные конечные точки, измененные API, расхождения в инвентаризации |
Шаг 1: Создание базового списка API
Процесс обнаружения теневых API требует базы для сравнения. Необходимо начать с формирования максимально полного реестра на основе утвержденных источников.
Нужно собрать спецификации OpenAPI или Swagger, схемы GraphQL, конфигурации шлюзов API, записи реестров сервисов, внутренние каталоги API и другие источники описаний API. В реестр следует включить внутренние, партнерские, мобильные и межмашинные API, не ограничиваясь только публичными конечными точками.
Среда также имеет значение. API, выведенный из продакшна, может до сих пор функционировать в стейджинге (staging) или в среде тестирования (QA). Аналогично, среда разработки или предварительного просмотра, которая предполагалась как временная, может стать частью внешне доступной поверхности атаки.
Действенный реестр API фиксирует не только имя хоста и путь:
| Поле реестра | Почему это имеет значение |
| Имя хоста | Определяет точку открытого доступа к API |
| Путь и метод HTTP | Определяет выполняемую операцию |
| Среда | Различает продакшн, стейджинг (staging), среду тестирования и разработки |
| Аутентификация | Демонстрирует механизм контроля доступа |
| Классификация данных | Помогает установить потенциальное влияние в случае инцидента |
| Ответственное лицо | Обеспечивает ответственность за устранение недостатков |
| Источник | Фиксирует место обнаружения или документирования API |
| Последняя зафиксированная активность | Помогает отличить активные конечные точки от неактивных |
| Статус жизненного цикла | Идентифицирует активные, выведенные из эксплуатации, тестовые или неизвестные сервисы |
Реестр API в режиме реального времени необходимо рассматривать как рабочий инструмент безопасности, а не как статичную электронную таблицу. Эффективное управление таким реестром также требует наличия процессов назначения ответственных, определения статуса жизненного цикла, отслеживания изменений и тестирования безопасности, чтобы только что обнаруженные API не превращались в обычные дополнительные записи в базе данных.
Шаг 2: Сравнение документации с активностью во время выполнения
Спецификации описывают ожидаемое поведение API. Они не обязательно отражают реальное состояние развертывания. Сравнение известных определений API с наблюдаемой активностью позволяет выявить следующие расхождения:
| Известный реестр | Наблюдаемое поведение | На что это может указывать |
| /api/v1/users | /api/v1/users/export | Недокументированная функциональность |
| Задокументирован метод GET | Также принимается запрос POST | Недокументированная операция записи |
| /api/v2/orders | /api/v1/orders до сих пор получает трафик | Устаревшее или Zombie API |
| Мобильное API не задокументировано | Мобильный клиент вызывает /mobile/api/session | Недокументированный мобильный бэкенд |
| Маршрут шлюза отсутствует | Сервер происхождения получает трафик API | Прямой доступ или обход шлюза |
Периоды наблюдения имеют значение. Конечная точка, используемая для ежемесячной интеграции или периодических рабочих процессов партнеров, может не появиться во время короткого окна мониторинга. Аналогично, конечная точка без зафиксированного трафика не обязательно является недоступной.
Именно поэтому обнаружение во время выполнения является мощным инструментом, но недостаточным само по себе. Оно фиксирует то, что было активно во время наблюдения, но не обязательно все возможные вызовы.
Шаг 3: Поиск неизвестных конечных точек в журналах
Существующие журналы инфраструктуры могут предоставить полезные данные еще до развертывания специализированных инструментов для обнаружения API.
К соответствующим источникам могут относиться шлюзы API, обратные прокси, фаерволы (WAF), балансировщики нагрузки, сети доставки контента (CDN), контроллеры входящего трафика Kubernetes, сервисные сетки, журналы доступа к приложениям, облачные сервисы и бессерверные платформы.
Необходимо обращать внимание на неизвестные пути и имена хостов, нетипичные методы HTTP, устаревшие версии API, маршруты для администрирования или дебага, тестовые форматы наименований, неожиданных клиентов, прямые вызовы к инфраструктуре происхождения и конечные точки, возвращающие конфиденциальную информацию.
Важным этапом является корреляция. Обнаружение /api/internal/export в журнале прокси не делает его автоматически теневым API. Эту запись нужно сравнить с утвержденным реестром, спецификациями API, конфигурацией шлюза, данными об ответственных лицах и другими доступными источниками.
Цель состоит в обнаружении необъяснимых расхождений, а не в создании еще одного списка URL-адресов.
Шаг 4: Проверка кода, репозиториев и конвейеров CI/CD
Данные среды выполнения показывают те API, которые уже используются. Исходный код способен выявить API еще до того, как они начнут получать трафик и, потенциально, до их попадания в продакшн.
Поиск в репозиториях приложений должен охватывать определения маршрутов, контроллеры, обработчики, бессерверные функции, резолверы GraphQL, аннотации API и файлы спецификаций. Эти определения необходимо сравнить с утвержденным каталогом API.
Инфраструктура как код (IaC) и конфигурации развертывания могут предоставить дополнительный срез информации. Определения шлюзов, правила Ingress, конфигурации систем DNS, триггеры бессерверных функций, контейнерные сервисы и манифесты непрерывной интеграции и непрерывного развертывания (CI/CD) – все это способно выявить доступность API, которая никогда не попадала в централизованную документацию.
| Источник | Потенциальный признак |
| Определение маршрута или контроллера | Конечная точка существует в коде, но отсутствует в реестре |
| Спецификация API | Спецификация существует, но никогда не была зарегистрирована централизованно |
| Бессерверная функция | Триггер HTTP или URL-адрес функции открывает доступ к неизвестному сервису |
| Шаблон IaC | Маршрут шлюза или входящего трафика существует вне каталога API |
| Манифест развертывания | Сервис открыт в стейджинге или в продакшне |
| Мобильное приложение | Клиент обращается к недокументированному бэкенду |
| Устаревший репозиторий | Старая версия API может до сих пор соответствовать развернутому сервису |
Обнаружение на основе кода также предоставляет важное преимущество сдвига влево (shift left): недокументированный API может быть потенциально идентифицирован перед развертыванием, а не только после того, как он станет доступным.
Если процесс разработки это позволяет, можно также требовать наличия спецификации API или соответствующей записи в реестре перед выпуском нового API. Тогда шлюзы развертывания (deployment gates) смогут проверять, были ли зарегистрированы и утверждены только что внедренные маршруты API. Эти меры контроля не устранят теневые API полностью, особенно в сложных или децентрализованных средах, но они способны уменьшить их количество, возникающее из-за обычных отклонений в процессах.
Шаг 5: Проверка открытости в облачных, Kubernetes и бессерверных средах
Распределенная инфраструктура создает больше мест, где API могут возникать за пределами ожидаемого маршрута в продакшн.
Проверке подлежат конфигурации облачных шлюзов API, триггеры HTTP и URL-адреса бессерверных функций, правила Ingress и определения сервисов Kubernetes, маршрутизация сервисных сеток, балансировщики нагрузки, контейнеризированные сервисы, среды предварительного просмотра и инфраструктура стейджинга.
Особенно важным является установление того, доступен ли сервис непосредственно, а не через шлюз или другие предусмотренные механизмы контроля безопасности. Реестр шлюза обеспечивает высоконадежное представление о тех API, которые им управляются, однако технически не способен выявить сервисы, работающие за его пределами.
Облачные и контейнерные среды также быстро меняются. Поэтому сопоставление развернутой инфраструктуры с утвержденным учетом API должно быть повторяющимся процессом, а не оставаться исключительно для ежегодного аудита.
Шаг 6: Анализ DNS и субдоменов на предмет открытости API
DNS обеспечивает дополнительную видимость поверхности атаки на API, особенно в отношении конечных точек и сред, которые могут больше не отображаться в централизованной документации.
Проверке подлежат известные домены и субдомены на наличие таких шаблонов наименования, как api, api-v1, api-v2, mobile, partner, internal, dev, test, staging и legacy. Эти записи необходимо сравнить с утвержденными реестрами активов и API.
Особое внимание следует обращать на устаревшие или непонятные записи DNS. Имя хоста, созданное для миграции, проверки концепции, предварительной версии API или временной среды, может оставаться доступным для распознавания еще долго после завершения изначального проекта.
Обнаружение через DNS само по себе не доказывает существования API или его достижимости. Имя хоста может указывать на неактивный сервис, а API может функционировать без очевидного имени хоста, связанного с API. DNS следует рассматривать как дополнительный сигнал обнаружения, требующий валидации данными инфраструктуры, среды выполнения и приложений.
Аналогично стоит проверять и противоположный сценарий: сервисы, достижимые непосредственно через IP-адрес, сгенерированное в облаке имя хоста, балансировщик нагрузки или URL-адрес бессерверной среды, могут вообще обходить ожидаемые правила именования публичных DNS организации.
Шаг 7: Обнаружение API извне
Внутренние записи отражают информацию, которая уже известна организации. Внешнее обнаружение помогает установить, какие части поверхности атаки на API достижимы за пределами организации.
Анализу подлежат доступные извне хосты, связанные с API, системы разработки или среды стейджинга, старые версии API, мобильные бэкенды, конечные точки для партнеров и API, доступные через веб-приложения.
Динамическое тестирование безопасности приложений (DAST) может обеспечить дополнительный сигнал для обнаружения на этом этапе. Когда сканер обходит веб-приложение, он может фиксировать вызовы API, инициированные приложением, и идентифицировать конечные точки, которые могут быть неочевидными из документации или интерфейса пользователя..
Это особенно полезно для API, связанных с приложениями, однако не является полноценным методом обнаружения. API без интерфейса и межсервисные API (service-to-service) могут не иметь веб-интерфейса для сканирования. В свою очередь анализ трафика выявляет только те API, которые генерируют доступный для наблюдения трафик. Эффективное обнаружение API комбинирует эти подходы, не опираясь на предположение, что любой из них самостоятельно обеспечивает полную видимость.
Шаг 8: Проверка открытости и механизмов контроля доступа
Процесс обнаружения лишь подтверждает существование API. Следующий вопрос заключается в том, какое значение он имеет для безопасности.
Для каждого подозрительного теневого API необходимо установить, является ли он общедоступным в интернете, доступен ли только внутри сети, требуется ли аутентификация, какие лица и роли могут им пользоваться, какие операции он открывает, а также какие средства контроля безопасности размещены перед ним.
Особое внимание следует уделить авторизации. Аутентификация отвечает на вопрос, кем является тот, кто осуществляет вызов. Авторизация определяет, имеет ли этот субъект право на доступ к определенному объекту или функции.
Например, нарушение авторизации на уровне объектов (BOLA) возникает тогда, когда API принимает действительный аутентифицированный запрос, но не проверяет, разрешен ли тому, кто осуществляет вызов, доступ к запрошенному объекту. Тестирование на подобные уязвимости требует большего, чем просто проверка наличия токена аутентификации – оно предполагает проверку границ доступа между пользователями.
Подобным образом, недокументированные административные операции или альтернативные методы HTTP могут раскрывать проблемы с авторизацией на уровне функций.
Рейтинг OWASP API Top 10 является удобным ориентиром для выявления слабых мест, которые следует учитывать, однако непосредственной целью на этом этапе является классификация: необходимо детально понять уровень открытости и привилегий конечной точки, чтобы определить срочность проведения более глубокого тестирования или принятия мер по локализации.
Шаг 9: Классификация конфиденциальной информации и бизнес-функций
Два недокументированных API могут представлять совершенно разные уровни риска.
Внутреннюю конечную точку проверки состояния, возвращающую неконфиденциальные данные, нельзя приравнивать к публичной конечной точке экспорта с записями клиентов. Именно поэтому для определения приоритетов необходим контекст данных и бизнеса.
Необходимо определить, обрабатывает ли API персональные данные (PII), платежную информацию, медицинские сведения, учетные данные, токены, интеллектуальную собственность или другие конфиденциальные данные компании. Также следует идентифицировать операции, позволяющие создавать, изменять, удалять, утверждать, передавать, экспортировать или администрировать ресурсы.
Особого внимания требуют чувствительные бизнес-процессы. В классификации OWASP API6:2023 («Неограниченный доступ к чувствительным бизнес-процессам») отмечается, что технически правильный функционал API все равно может создавать серьезный риск в случае автоматизации или злоупотребления им без надлежащих средств контроля.
Шаг 10: Назначение ответственных и классификация API
Не каждый API, отсутствующий в реестре, относится к одной и той же категории:
| Тип API | Описание | Основная проблема |
| Теневой API | Активный, но недокументированный, неизвестный или неуправляемый | Неизвестное состояние безопасности |
| Zombie API | Устаревший API, который остается доступным | Устаревший функционал и средства контроля |
| Rogue API | API, развернутый вне утвержденных процедур управления | Отсутствие проверки и подотчетности |
| Заброшенный API (Orphaned API) | API без четко определенного владельца | Проблемы с обновлением и жизненным циклом |
| Внутренний API | API, предназначенный исключительно для внутреннего использования | Непредвиденный доступ извне |
| Партнерский API | API для поддержки сторонних интеграций | Управление доступом и данными |
| API для тестирования или стейджинга (staging) | API вне продакшна, который остается доступным | Более слабый контроль или доступность тестовых данных |
Эти категории могут пересекаться. Устаревшая конечная точка, забытая первоначальной командой, может быть одновременно zombie и теневой. API стейджинга, открытый непосредственно в интернет, может быть одновременно недокументированным, заброшенным и некорректно настроенным для внешнего доступа.
Классификация полезна только тогда, когда она стимулирует к действиям. Каждый активный API должен иметь ответственного владельца и понятное назначение для бизнеса.
Если владельца идентифицировать невозможно, это само по себе является полезной информацией для управления и безопасности. API без ответственной команды имеет значительно меньшие шансы на своевременное получение обновлений, устранение уязвимостей, поддержку жизненного цикла или аудит в случае изменения его задач для бизнеса.
Шаг 11: Тестирование активных API на уязвимости
Сам факт обнаружения API не указывает на наличие в нем уязвимостей.
Все API, которые остаются активными, необходимо включить в процесс тестирования безопасности организации. Именно на этом этапе результаты обнаружения превращаются в реальные доказательства состояния безопасности.
Динамическое тестирование безопасности (DAST) имеет особое значение, поскольку многие уязвимости API зависят от поведения во время выполнения. Ошибки аутентификации, недостатки авторизации, уязвимости к инъекциям, неправильные настройки безопасности и проблемы рабочих процессов невозможно полностью оценить только на основе данных реестра.
Тестирование с пройденной аутентификацией особенно важно для API, ведь важный функционал обычно скрыт за формой входа, токеном или идентификатором сервиса. Проверка только неаутентифицированных конечных точек может привести к пропуску ошибок авторизации и других слабых мест, которые проявляются только после установления действительной сессии.
По возможности тестирование следует автоматизировать как часть жизненного цикла разработки программного обеспечения (SDLC), в частности в стейджинге (до выхода в продакшн). Это снижает вероятность обнаружения недокументированного и уязвимого API уже после того, как он начал работать в среде продакшна.
Шаг 12: Приоритезация и устранение недостатков по реальному риску
Статус «недокументировано» сам по себе не должен определять уровень критичности уязвимости.
Каждый обнаруженный API требует приоритезации с учетом следующих факторов: внешняя доступность, аутентификация и авторизация, чувствительность данных, уровень привилегий, возможности записи или администрирования, известные уязвимости, критичность для бизнеса, наличие владельца, а также способность конечной точки обходить ожидаемые шлюзы или средства контроля безопасности.
Действенная модель приоритезации может выглядеть следующим образом:
| Приоритет | Примеры критериев | Рекомендуемые действия |
| P0 | Внешнее, неаутентифицированное, открывает конфиденциальные данные или привилегированный функционал | Немедленно ограничить или заблокировать и провести расследование |
| P1 | Внешнее, недокументированное, конфиденциальное или с подтвержденной уязвимостью | Назначить владельца, тщательно протестировать, усилить средства контроля |
| P2 | Внутреннее, но обрабатывает конфиденциальные данные или имеет привилегированные функции | Проверить идентификацию, авторизацию, сегментацию и провести тестирование |
| P3 | Устаревшее API с низким уровнем использования | Разработать план вывода из эксплуатации |
| P4 | Действительный API с низким риском, отсутствующий в документации | Добавить в реестр, закрепить владельца и включить в регулярный мониторинг |
Эту модель не следует применять механически. Конечная точка с низким трафиком, наделенная административным доступом, может иметь гораздо большее значение, чем API для чтения с высокой нагрузкой. Подтвержденные уязвимости аналогичным образом должны повышать приоритет устранения сверх того уровня, который вытекает лишь из факта внешней открытости.
Каждый обнаруженный API требует четкого последующего действия: задокументировать, защитить, ограничить доступ, вывести из эксплуатации или удалить.
Действительный API, который остается необходимым, следует задокументировать, назначить владельца, при необходимости перевести на утвержденные средства контроля безопасности и включить в регулярное тестирование и мониторинг. Слабую аутентификацию или авторизацию необходимо исправлять так же, как и для любого другого сервиса в продакшне.
Устаревшие API могут нуждаться в поэтапном выводе из эксплуатации, если от них до сих пор зависят клиенты. API, которые больше не имеют действительного назначения для бизнеса, подлежат удалению или деактивации, однако не стоит полагать, что каждое теневое API нужно просто удалить.
Иногда конечная точка является действительной, а недостатки возникают в самом процессе. В таком случае решение заключается во включении API в систему управления, а не в его удалении.
Такие решения следует фиксировать в процессах управления уязвимостями и инвентаризации API, чтобы не пришлось обнаруживать и исследовать одну и ту же конечную точку с нуля.
Шаг 13: Внедрение непрерывного управления для обнаруженных API
Обнаружение и исправление одного теневого API решает проблему лишь локально. Долгосрочная цель – сделать API частью стандартных операций безопасности.
Это предполагает обновление реестра API, назначение ответственных лиц, фиксацию статуса жизненного цикла, подключение к соответствующему мониторингу, установку необходимых средств контроля безопасности и включение в постоянное тестирование безопасности API.
Для API, находящихся в активной разработке, такие средства контроля интегрируются в процессы разработки. Спецификации API и записи в реестре могут проверяться в рамках CI/CD, тогда как тестирование безопасности может выполняться на этапе стейджинга и других соответствующих стадиях жизненного цикла разработки ПО (SDLC).
Для организаций с масштабной инфраструктурой API такая связь между обнаружением, инвентаризацией, тестированием и устранением недостатков является критической. Иначе результаты обнаружения станут просто еще одним источником данных о безопасности, требующим ручного согласования, вместо реального уменьшения неизвестных угроз.
Шаг 14: Постоянное обнаружение новых и измененных API
Проведение разовой инвентаризации отвечает на устаревший вопрос: «Какие API удалось обнаружить?».
Реальный вопрос для обеспечения безопасности иной: «Какие API существуют сейчас и что претерпело изменения?».
API претерпевает изменения при развертывании новых сервисов, обновлении мобильных приложений, добавлении интеграций с партнерами, модификации микросервисов, создании облачных функций или поддержании активности старых версий в процессе миграций. Поэтому реестр, данные которого были точными три месяца назад, сегодня может оказаться неполным.
Постоянный контроль помогает уменьшить это отклонение:
| Непрерывный контроль | Цель |
| Комплексное обнаружение API | Находит API на основе множества независимых сигналов |
| Сопоставление реестров | Выявляет несоответствия между известными и найденными API |
| Обнаружение изменений и сравнение версий реестра | Фиксирует новые, модифицированные, удаленные или непонятные API |
| Мониторинг во время выполнения | Отображает API, активно обрабатывающие трафик |
| Поиск в исходном коде | Находит API непосредственно на стадии разработки |
| Проверки реестра в рамках CI/CD | Отмечает новые маршруты API, которые не включены в официальное управление |
| Требования к спецификациям API | Обеспечивает создание четкой записи для новых API до или во время релиза |
| DAST и сканирование API | Проверяет активные конечные точки на уязвимости времени выполнения |
| Проверка ответственных лиц | Гарантирует актуальность информации об ответственных командах |
| Анализ жизненного цикла | Идентифицирует API, которые следует вывести из эксплуатации или удалить |
Цель заключается не просто в более частом проведении обнаружения. Она состоит в создании цикла обратной связи, благодаря которому недавно обнаруженный или измененный API автоматически или с минимальным ручным вмешательством попадает в процессы инвентаризации, тестирования, назначения владельца и устранения недостатков.
Такой цикл обратной связи также позволяет получить фактическую оценку расхождений в реестре. Если во время каждой проверки постоянно фиксируется API, который был неизвестен командам безопасности, проблема не ограничивается отдельными теневыми конечными точками – это пробел в процессах разработки, развертывания или инвентаризации, позволяющий такому API оставаться неуправляемым.
Критерии выбора инструментов для обнаружения теневых API
При оценке возможностей обнаружения API необходимо осознавать, что ни один отдельный источник данных не дает полной видимости API:
- Данные шлюза являются авторитетным источником для управляемых API, но не позволяют видеть конечные точки, которые обходят шлюз.
- Трафик во время выполнения выявляет активные API, однако может пропустить неактивные сервисы или сервисы с низкой частотой запросов.
- Анализ кода способен идентифицировать конечные точки до развертывания, но не доказывает их доступности.
- Сканирование веб-приложений может раскрыть API, используемые приложением, но не обязательно выявит сервисы без интерфейса пользователя.
Оптимальный подход предполагает комбинирование множества сигналов с последующим совмещением обнаружения и проверки безопасности.
В зависимости от инфраструктуры такие функции могут реализовываться через единую платформу или набор инструментов, интегрированных в процессы обеспечения безопасности приложений (AppSec), управления API, мониторинга и учета активов. Ниже приведено, как каждый уровень возможностей повышает видимость и улучшает сбор аналитических данных:
| Возможность | Почему это важно |
| Многоуровневое обнаружение API | Уменьшает количество «слепых зон», присущих любому отдельному методу обнаружения |
| Обнаружение в исходном коде | Идентифицирует API еще до развертывания |
| Обнаружение по трафику во время выполнения | Раскрывает API, которые фактически используются |
| Обнаружение через шлюз API | Добавляет видимость централизованно управляемых маршрутов |
| Обнаружение на основе приложений | Находит API, которые используются веб-приложениями |
| Обработка спецификаций API | Использует существующие определения и уменьшает объем ручной настройки |
| Обнаружение изменений и сравнение реестров | Идентифицирует новые или измененные API, которые отклоняются от утвержденного реестра |
| Поддержка аутентификации | Обеспечивает доступ к защищенному функционалу для реалистичного тестирования |
| Тестирование API с учетом состояния | Тестирует рабочие процессы, охватывающие несколько запросов |
| Классификация конфиденциальных данных | Помогает установить потенциальное влияние открытия доступа к API |
| Привязка к владельцам | Связывает обнаруженные API с ответственными командами |
| Подтверждение уязвимостей | Помогает отличить подтвержденные проблемы безопасности от теоретической открытости |
| Непрерывная инвентаризация | Поддерживает актуальность информации об обнаруженных API |
| Интеграция с управлением уязвимостями | Связывает результаты проверки API с рабочими процессами назначения владельцев и устранения недостатков |
Средство, выполняющее только функцию обнаружения, способно сообщить лишь о наличии конечной точки. Для специалистов по безопасности приложений (AppSec) гораздо большую ценность представляет переход к следующему этапу: установление того, является ли обнаруженный API уязвимым, и передача необходимых доказательств команде, ответственной за исправление.
Как Invicti помогает обнаруживать и защищать теневые API
Платформа Invicti подходит к обеспечению видимости API как к процессу многоуровневого обнаружения.
Вместо того чтобы полагаться на единственный источник, платформа сопоставляет результаты обнаружения API на основе исходного кода, сетевого трафика, шлюзов API и сканирования веб-приложений. Обнаружение в исходном коде способно идентифицировать конечные точки и спецификации во время разработки, тогда как динамическое сканирование приложений фиксирует вызовы API, осуществляемые во время работы веб-приложений. Сигналы от шлюзов и сети обеспечивают дополнительную видимость развернутых и активных API.
Сочетание этих методов обнаружения позволяет выявить пробелы между существующей документацией и реальным состоянием инфраструктуры, охватывая теневые, зомби, межсервисные API и API без интерфейса пользователя.
Процесс обнаружения обеспечивает данными постоянно обновляемый реестр API и процедуры проверки безопасности. Платформа Invicti способна извлекать или восстанавливать схемы API непосредственно из источников обнаружения, благодаря чему API подготавливается к сканированию без необходимости полностью полагаться на созданные вручную спецификации.
На этом этапе фундамент DAST в решении от Invicti становится крайне важным. Как только API обнаружен, эта же платформа может динамически тестировать его на наличие уязвимостей во время выполнения, в частности специфических для API проблем безопасности. Тестирование с учетом состояния и аутентификации позволяет проверять рабочие процессы API и средства контроля доступа, вместо того чтобы ограничивать проверку только изолированными запросами без аутентификации.
Для категорий уязвимостей, для которых предусмотрено сканирование с подтверждением, Invicti способна безопасно доказать наличие эксплойта и добавить соответствующие доказательства в отчет о находке. Это позволяет специалистам отделять подтвержденные недостатки защиты от факта существования незадокументированной конечной точки.
Результатом является единый связный рабочий процесс: обнаружение API, ведение реестра, тестирование достижимых компонентов, валидация реальных уязвимостей, приоритезация выявленных проблем и возвращение результатов устранения в общую программу AppSec.
