- Чому важливо виявляти тіньові 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.
