Где в ИТ-инфраструктуре место для защиты API?

Сергей Одинцов
Системный аналитик компании Вебмониторэкс

Для многих сегодня API (Application Programming Interface, или программный интерфейс приложения) – это что-то обыденное и абсолютно понятное. Технология широко используется и де-факто стала стандартом для взаимодействия различных систем, которых с каждым годом становится всё больше.

Казалось бы, ответ на вопрос из заголовка очевиден – API просто существуют как внешнее подключение и передают или получают необходимые данные. Но что, если посмотреть на них в контексте безопасности? Количество API в современных продуктах постоянно растёт, а значит, увеличивается их число и в ИТ-инфраструктурах.

Компания Вебмониторэкс уже много лет занимается проблемой управления и защиты API. Это позволило сформировать собственную многоэтапную концепцию в данном сегменте и создать линейку продуктов для её реализации. В основе этого подхода лежит принцип API First, который предполагает, что API считаются ключевыми составляющими продукта и процесс их безопасной разработки должен стартовать с самого начала проекта. Подробнее непосредственно про API First можно прочитать в статье: «Управление API или API Security? Что это такое?»

Как создаются API

Теоретические этапы подхода API First достаточно просты. Они представлены на рисунке ниже.

На практике выделяются три основных способа реализации процесса управления API.

1. Простой с использованием подручных средств. Например, проектирование и реализация API на уровне кодирования.

К сожалению, при реализации можно столкнуться рядом недостатков:

Необходимость обработки логов, которая требует большого объёма ручной работы при мониторинге изменений;
Отсутствие проверки соответствия того, что согласовывалось, и того, что опубликовано;
Отсутствие тестирования специальными инструментами динамического анализа (DAST).

2. Процесс, когда всё автоматизировано и интегрировано. С использованием платформ для управления API.

В таком подходе уже уделено больше внимания безопасности, так как появился отдельный этап тестирования. Но, все же, он тоже имеет ряд существенных недостатков:

Отсутствие проверки соответствия того, что согласовывалось, и того, что опубликовано;
Отсутствие мониторинга изменений. Нет верификации трафика через OAS;
Необходимость ручной настройки политик безопасности (например, rate limit, IP Filtering);
Несоответствие Open Source инструментов для DAST полноценной реализации всех задач тестирования API.

3. Подход, включающий в себя не только управление API, но и обеспечение безопасности.

Специалисты Вебмониторэкс поставили перед собой задачу побороть все недостатки двух предыдущих способов управления и защиты API и на сегодня данный подход реализуется с использованием продуктов линейки ПроAPI.

Теперь на этапе стэйджинга появилась возможность провести инвентаризацию API на основе трафика и увидеть то, что реально передаётся в API. После этого построенную структуру можно выгрузить в виде OAS и загрузить для динамического тестирования в продукт ПроAPI Тестирование. А на этапе публикации продукт ПроAPI Защита позволяет согласовать OAS, подготовленные в процессе разработки. И, наконец, на этапе эксплуатации ПроAPI Структура поможет осуществлять мониторинг изменений в API, а ПроAPI Защита обеспечить их безопасность на основе позитивной модели. В итоге будет обеспечена комплексная защита API на всех этапах от создания до эксплуатации.

Однако и у этого подхода также есть хоть и не критичные, но свои особенности. Необходимо учитывать, что реализация потребует инструментов для автоматизации проектирования и публикации API. Кроме того, возможно увеличение длительности и трудоёмкости процесса создания API на этапах «Стэйджинг» и «Согласование».

Моделирование угроз API

Процесс безопасной разработки не ограничивается лишь внедрением в ИТ-инфраструктуру и применением ряда автоматизированных средств. Организация безопасности начинается с выявления рисков и построения матрицы угроз. В рамках данного процесса все выявленные угрозы ранжируются по степени их риска для дальнейшего использования. Уверен, большинство читателей этой статьи знакомы с огромным количеством материалов по построению классической матрицы угроз для ИБ. Но, все же, приведу ниже ряд примеров для наглядности.

После формирования модели угроз, необходимо для каждой угрозы описать меры по защите от неё, например контроли NIST, как на изображении ниже.

Данное упражнение нужно проделать для всех API в инфраструктуре. Если мы говорим о современной средней организации, то получается достаточно трудоёмкое занятие, не правда ли?

Улучшая собственный подход Вебмониторэкс к управлению и защите API, а также связанные с ним продукты, мы решили оптимизировать и этот процесс. Теперь продукт ПроAPI Структура может упростить и ускорить оценку угроз для ваших API. Напомню, что изначально данный продукт был предназначен для инвентаризации API и их составных частей. Ниже на рисунке представлен пример построенной структуры API.

ПроAPI Структура предоставляет исходные данные и инструментарий для определения степени риска каждого конкретного эндпоинта. Механизм расчёта уровня риска основан на методе экспертных оценок. В начале эксперт должен указать для всех параметров расчёта соответствующие коэффициенты важности, далее автоматически производится расчёт рисков и отображение результатов в окне пользовательского интерфейса. Выбор коэффициентов основывается на имеющейся матрице угроз.

Для расчёта риска используются следующие параметры:

Наличие у эндпоинта активных уязвимостей;
Потенциальная уязвимость эндпоинта для атак типа BOLA;
Наличие в эндпоинте параметров с конфиденциальными данными;
Количество параметров запроса и тела;
Использование объектов XML / JSON;
Возможность загрузки файлов на сервер.

Для каждого из факторов установлены значения по умолчанию, представленные в таблице ниже вместе с пояснениями о выбранных значениях. Более подробно про них можно прочитать в нашей документации.

Фактор	Пояснения	Вес
Активные уязвимости	Активные уязвимости могут привести к несанкционированному доступу к данным или повреждению.	9
Потенциально уязвимые для BOLA	Наличие вариативных элементов, таких как ID пользователей, например, /api/articles/author/{parameter_X}. Злоумышленники могут манипулировать идентификаторами объектов и, в случае недостаточной аутентификации запроса, либо считывать, либо изменять конфиденциальные данные объекта (атаки BOLA).	6
Параметры с конфиденциальными данными	Вместо прямой атаки на API злоумышленники могут украсть конфиденциальные данные и использовать их для доступа к вашим ресурсам.	8
Количество параметров запроса и тела	Большое количество параметров увеличивает количество направлений атаки.	6
Использование объектов XML / JSON	Объекты XML или JSON, передаваемые в запросах, могут использоваться злоумышленниками для передачи вредоносных внешних объектов XML и инъекций на сервер.	6
Возможность загрузки файлов на сервер	Эндпоинты часто становятся мишенью для атак с удаленным выполнением кода (RCE), при которых файлы с вредоносным кодом загружаются на сервер. Для обеспечения безопасности этих эндпоинтов загруженные расширения файлов и содержимое должны быть надлежащим образом проверены в соответствии с рекомендациями OWASP.	6

Пользователь может самостоятельно установить значение веса каждого из факторов или полностью исключить какой-либо из них из расчёта. На иллюстрации ниже представлено окно настройки.

Установленные значения весов отобразятся на диаграмме.

После установки значений весов, уровень риска каждого эндпоинта будет автоматически пересчитан и отображён на главном окне ПроAPI Структуры. В соответствии с результатами расчёта, каждому эндпоинту будет присвоен соответствующий уровень риска. Все имеющиеся уровни указаны в таблице:

Значение	Уровень риска	Цвет
от 1 до 3	Низкий	Серый
от 4 до 7	Средний	Оранжевый
от 8 до 10	Высокий	Красный

Эндпоинты можно отсортировать по уровню риска, как это представлено на рисунке ниже.

Далее можно выделить следующие эндпоинты с высоким уровнем риска:

открытые (публичные) API;
эндпоинты c открытыми уязвимостями;
эндпоинты с чувствительными данными;
эндпоинты с большим количеством параметров;
оставшиеся эндпоинты с высоким уровнем риска.

В проведении анализа поможет система фильтров, имеющаяся в продукте ПроAPI Структура. Пользователь может по очереди отобразить в окне интересующие его группы эндпоинтов для последующего анализа с использованием имеющейся модели угроз. Далее информация по выявленным событиям может быть передана в SIEM систему, позволяющую работать с такими метриками уязвимости API как:

количество эндпоинтов с уязвимостями;
распределение уязвимостей API по уровню критичности;
уязвимости API, которые можно эксплуатировать;
среднее время устранения уязвимостей в API.

Как реализуется интеграция с решениями данного класса подробно рассмотрено в наших статьях: «WAF: интеграция в SOC через SIEM или ASOC? (Часть 1)» и «WAF: интеграция в SOC через SIEM или ASOC? (Часть 2)».

После обработки событий уязвимости API в SIEM системе предполагается, что в корпоративной внутренней системе будут созданы задачи для исправления выявленных недостатков и назначены ответственные исполнители. При использовании в ИТ-инфраструктуре решения класса WAF до момента закрытия уязвимостей, для эндпоинтов с высоким риском возможно создание виртуальных патчей.

В результате применения комплексного подхода, предлагаемого экспертами Вебмониторэкс, становится возможным реализовать защиту ИТ-инфраструктуры от атак через API, принципы безопасной разработки, а также интеграцию с другими средствами защиты, такими как SIEM и WAF. И хотя все мы осознаем, что любые нововведения пугают, необходимые в подобном подходе изменения, не выглядят неоправданно сложными с учетом тех преимуществ, которые они дают, не так ли?

erid: 2SDnjdMgkPe

* Реклама, Рекламодатель ООО «ВЕБМОНИТОРЭКС», ИНН 7735194651