API в контексте информационной безопасности: главные проблемы и риски

Интерфейсы прикладного программирования (Application Programming Interface, API) используются в современных приложениях и позволяют наладить взаимодействие между разными продуктами, открывая множественные возможности для интеграции. Но также API имеют и недостатки, которые вырастают в серьёзные проблемы и риски для безопасности. Расскажем, в чём польза API, какие существуют сложности в их защите и как снизить риски.

1. Введение
2. Что такое API?
3. Преимущества API
4. Основные вехи технологического развития API
5. Типы API
6. Проблемы безопасности API
7. Риски для безопасности
8. Прогнозы развития API
9. Выводы

Введение

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

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

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

Что такое API?

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

Для успешной коммуникации на машинном уровне между приложениями или их частями API необходимо иметь чёткие правила взаимодействия. Такой набор требований представляет собой «спецификацию», или, иными словами, «контракт» API, в котором описано, какие сервисы предоставляют те или иные интерфейсы, кто имеет к ним доступ, а также какие данные принимаются и передаются с их помощью. Части интерфейсов, которые непосредственно принимают и/или отдают данные, называются «конечными точками».

Таким образом, разработчики в процессе создания какого-либо приложения реализуют те или иные бизнес-задачи за счёт того, что компонуют нужным образом сервисы, которые предоставляют и потребляют данные, и программируют их на взаимодействие согласно этим контрактам.

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

Преимущества API

В отличие от старых способов, разработка информационных систем с использованием API даёт ценные преимущества:

1. Процессы разработки ускоряются за счёт параллельного написания кода различных сервисов.
2. Задачи разработчиков упрощаются, поскольку программирование взаимодействия сервисов (вместо написания отдельного компонента монолитной системы) зачастую делает код легче и чище с точки зрения содержания.
3. Внесение изменений и новой функциональности происходит быстрее, так как обычно написать новый сервис проще, чем встроить дополнительные опции в монолитный код.
4. Область взаимодействия изначальной системы с остальными продуктами расширяется за счёт переиспользования сервисов, открываются огромные просторы для интеграции и реализации сложных бизнес-идей.

Основные вехи технологического развития API

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

Рисунок 1. История развития стилей создания и внедрения API

Все стили с технологической точки зрения имеют свои особенности, которые касаются форматов используемых данных (бинарные файлы, XML, HTML, Protobuf, JSON), организации информации внутри протоколов (сообщения, очереди, асинхронные запросы, вызовы процедур), возможностей поддержки архитектуры с точки зрения сообщества, области применения (как следствие из предыдущих особенностей). В рамках данной статьи тоже отдельно стоит вопрос об особенностях защиты систем, которые реализованы с использованием каждой из инфраструктур.

Типы API

Теперь, абстрагируясь от конкретных технологий, но оставаясь в контексте безопасности, посмотрим на API с другой стороны. В современных методологиях существуют три основных типа интерфейсов прикладного программирования.

1. Публичные — доступны любому внешнему разработчику бесплатно или же при плате за каждый вызов. К ним можно отнести, например, картографические сервисы или сервисы справочников.
2. Партнёрские — API, доступ к которым имеют только компании-партнёры на основании бизнес-потребностей. Передаваемые по такой модели данные (например, фрагменты клиентской информации, которая необходима для реализации совместных задач) зачастую представляют большую коммерческую ценность.
3. Внутренние — исключительно закрытые интерфейсы, действующие в рамках одной компании, например бухгалтерские сервисы или HR-платформы для работы с сотрудниками.

Все эти типы по-разному влияют на безопасность как приложений, так и инфраструктуры в целом.

Проблемы безопасности API

Здесь давайте сведём воедино понимание того, как широко используются сервисы (по сути, каждый из них — как маленькое приложение), насколько разными они могут быть (имея собственные требования по функциональности и безопасности) и какие технологии (или архитектурные стили) применяются для их построения.

Всё это порождает весьма сложные задачи. Как понять, какие данные защищать? Как обеспечить безопасность важной информации, которая передаётся между сервисами? Как разобраться с задачами ИБ самих сервисов? Что ещё нужно учесть? На эти вопросы пока нет конкретных ответов, специалисты продолжают искать оптимальные решения.

Если мы посмотрим на статистику, проблема станет ощущаться ещё острее. 95 % организаций, которые приняли участие в опросе Salt Security, в 2021 году столкнулись с инцидентами связанными с безопасностью программных интерфейсов. 85 % заявили, что используемые ими инструменты защиты не очень эффективны в отражении атак. 34 % организаций сообщили, что у них вообще нет какой-либо стратегии безопасности API.

Также существует проблема консервативного подхода компаний к защите API, который был сформирован на базе опыта полученного в процессе разработки монолитных систем. Организации применяют старые методы к современным распределённым облачным системам, в которых количество сервисов несравнимо с числом «классических» приложений, а сложность их бизнес-логики зачастую ставит в тупик даже самые инновационные инструменты безопасности.

Риски для безопасности

Среди наиболее специфичных рисков, характерных для безопасности API, можно выделить следующие:

1. Нарушение авторизации объектов, в результате чего злоумышленник может получить доступ к данным API.
2. Нарушение системы аутентификации — приводит к тому, что злоумышленнику становятся доступны учётные записи систем и пользователей, которые взаимодействуют с API. Он может установить контроль над всеми данными скомпрометированных учётных записей.
3. Избыточность раскрываемых данных: иногда сервисы могут выдавать намного больше данных, чем требуется для выполнения бизнес-задачи. В этом случае клиентское приложение самостоятельно фильтрует сведения. Если к таким данным относится, например, персональная информация всех пользователей, это однозначно является риском нарушения конфиденциальности.
4. Отсутствие ограничений на количество обращений — риск заключается в том, что злоумышленник может нагрузить API большим объёмом запросов и тем самым ухудшить или вообще остановить работу всей системы.

На самом деле, этот список можно продолжать ещё весьма долго; с остальными рисками я бы порекомендовал вам ознакомиться в документе OWASP API Security Top 10.

Прогнозы развития API

По прогнозам Gartner, в обозримом будущем сегмент API будет развиваться с учётом следующих тенденций:

• К 2025 году под контролем будут находиться менее 50 % корпоративных API, поскольку скорость их распространения превосходит темпы развития инструментов управления.
• Доля сторонних API, используемых в приложениях, к 2025 году составит около 30 %. В 2021 году этот показатель достигал примерно 10 %.
• К 2025 году более 50 % компаний будут использовать GraphQL в промышленной эксплуатации, в 2021 году таких организаций было менее 10 %. GraphQL — это язык запросов, созданный специально для взаимодействия с API. Он предоставляет клиентам только те данные, которые они запрашивают, именно поэтому GraphQL-API приобретают всё большее значение: они дают разработчикам пользовательского интерфейса возможность контролировать содержание ответов API и быть менее зависимыми от изменений серверной стороны.

Выводы

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

• Налаживать управление API, инвестируя в обнаружение, каталогизацию и автоматическую валидацию, а также используя адаптивный подход к контролю широкого спектра типов и сценариев использования API.
• Разработать стратегию безопасности, включающую в себя специфичные сценарии атак на API.
• Проводить тщательную инвентаризацию API — это позволит лучше ориентироваться во всех интерфейсах, которые применяет компания. К процессу стоит привлечь команду безопасности.
• Включить в разработку API практики тестирования безопасности: DAST, SAST, фаззинг и другие.
• Составить перечень сторонних API, с которыми взаимодействуют системы организации, и использовать его для отслеживания сбоев в чужих интерфейсах и формулирования предположений о последствиях.
• Контролировать внешние API так, как нужно управлять SaaS-приложениями: следить за соблюдением условий лицензирования и SLA (соглашения об уровне обслуживания), соответствием требованиям по безопасности и так далее.