Защита API корпоративных приложений

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

Редакция CISOCLUB поговорила с экспертами на эту тему, спросив о наиболее актуальных угрозах для защиты API корпоративных приложений, современных подходах к предотвращению атак, использовании Zero Trust, методах аутентификации и авторизации, о том, как выстроить процессы проектирования, мониторинга и тестирования API для минимизации рисков и повышения эффективности работы. Эксперты ответили и на множество других вопросов. С нами пообщались:

• Павел Нагин, директор по развитию, компания SQUAD.
• Никита Черняков, руководитель департамента развития бизнеса решений ИБ компании Axoft.
• Артем Гребенюк, директор департамента эксплуатации информационной безопасности «Ростелекома».
• Анастасия Травкина, младший системный аналитик, Вебмониторэкс.
• Антон Чемякин, руководитель аналитического отдела Servicepipe.
• Александр Зубриков, генеральный директор ITG Security.

Какие угрозы наиболее актуальны для защиты API корпоративных приложений сегодня, и как они эволюционируют в условиях меняющегося ландшафта киберугроз?

Павел Нагин, директор по развитию, компания SQUAD:

«При оценке актуальных угроз для API лучше всего ориентироваться на ТОП 10 от некоммерческой организации OWASP (Open Worldwide Application Security Project): Угрозы, действительно, эволюционируют, поэтому данный список регулярно обновляется: первая версия вышла в 2019-м, последняя и актуальная — в 2023-м. Также нужно учитывать специфику ваших API. Например, если у вас открытое API, в котором нет аутентификации и авторизации, то соответствующие угрозы будут для вас нерелевантны:

• API2:2023 — Broken Authentication
• API1:2023 — Broken Object Level Authorization
• API3:2023 — Broken Object Property Level Authorization
• API5:2023 — Broken Function Level Authorization».

Никита Черняков, руководитель департамента развития бизнеса решений ИБ компании Axoft:

«Масштабы потенциальных рисков от недостаточной защиты корпоративных API, как мне кажется, достаточно сильно недооценены со стороны представителей служб информационной безопасности компаний. Если говорить про объемы использования API, то можно привести данные из отчета «2024 API Security and Management Report» от Cloudflare – в каждом регионе присутствия, который защищает Cloudflare, трафик API составил более половины динамического HTTP-трафика (Европа – 57,7%, Средний Восток – 60,4%). При этом основная угроза безопасности, которая выделяется многими исследователями и авторами – это так называемый «теневой API» – скрытый, недокументированный API, на который при этом есть трафик. Не зная о существовании такого API, компании не могут ни управлять им, ни защищать его. По данным того же отчета, на долю теневого API приходится до 30% от общего числа.

Стоить отметить, что профессиональные сообщества все больше внимания уделяют вопросу защиты API: в марте 2022 года был выпущен обновленный стандарт PCI DSS версии 4.0, в котором напрямую затрагивались вопросы безопасности API. А в 2023-ем вышла вторая версия OWASP API Security Top 10, в котором перечислены 10 главных рисков безопасности API. Данная информация является полезной как для понимания основных угроз использования API, так и для выработки методики и выбора средств защиты корпоративных API».

Анастасия Травкина, младший системный аналитик, Вебмониторэкс:

«Сегодня корпоративные приложения сталкиваются с множеством угроз, связанных с использованием API. Например, DDoS-атаки, SQL-инъекции, подбор паролей методом перебора (brute force), захват сессий (session hijacking), межсайтовый скриптинг (XSS), подделка межсайтового запроса (CSRF), эксплуатация уязвимостей из списка OWASP Top 10, атаки «человек посередине» (MITM) и неправильная настройка API.

Внедрение искусственного интеллекта автоматизирует атаки и позволяет злоумышленникам быстрее подбирать пароли, генерировать реалистичные фишинговые письма и создавать сложные сценарии для обхода защитных механизмов вроде CAPTCHA. Становясь сложнее и разнообразнее, эти угрозы распространяются на всё большее количество компонентов ИТ-инфраструктуры, а передовые методы маскировки злоумышленников делают традиционные средства защиты менее эффективными против них».

Антон Чемякин, руководитель аналитического отдела Servicepipe:

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

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

API, будучи одной из точек входа сервиса, может стать причиной DDoS-атаки, при этом, если нет валидации входных параметров, – весьма чувствительной.

Ну, и стоящие несколько особняком проблемы с «забытой автоматизацией» (Shadow/Zombie API) – когда устаревшие, неэффективные, ставшие слишком ресурсоемкими “забытые” методы годами “дёргают” свои или партнерские сервисы».

Александр Зубриков, генеральный директор ITG Security: «В первую очередь, это ошибки в функциях авторизации и контроля уровня доступа, которые позволяют злоумышленникам получить доступ к данным без наличия должных прав. Уязвимости аутентификации, вызванные, например, использованием слабых или устаревших методов, делают API уязвимыми к атакам, нацеленным на хищение учетных данных. Атаки на передаваемые в систему данные, включая SQL-инъекции и XSS, остаются одними из наиболее распространенных.

С ростом количества IOT-ботнетов растет угроза DDoS-атак и ресурсного флуда, перегружающих API запросами и нарушающих их доступность. Увеличение количества комплексных, целенаправленных атак в которых злоумышленники становятся более подготовленными и профессиональными, используют новые инструменты и AI».

Артем Гребенюк, директор департамента эксплуатации информационной безопасности «Ростелекома»:

«Несмотря на тесную связь API с WEB и пересечение по актуальным рискам, для API интерфейсов OWASP Foundation определяет свой отдельный ТОП перечень угроз. Большинство угроз связаны с безопасностью аутентификации и авторизации опубликованных интерфейсов и отдельных вызовов. Например, злоумышленники могут воспользоваться отсутствием или слабой проверкой прав доступа к данным или операциям через опубликованные API. API интерфейсы часто предоставляют много возможностей и параметров, в отличие от традиционного WEBа, что с одной стороны предоставляет максимальную гибкость разработчику, но с другой — требует тщательного анализа необходимости и достаточности, а также разумного ограничения при публикации.

Трендом в последние года стали атаки через поставщиков услуг и подрядчиков (supply chain), что не обошло стороной и угрозы для API. В ТОП 10 вошли атаки через интеграции со сторонними сервисами, например сторонние системы аутентификации. В случае, если безопасность стороннего сервиса обеспечена хуже, злоумышленник может сосредоточить свои усилия на нем, завладеть токеном авторизации, и далее для защищаемой системы будет не отличим от легального пользователя».

Какие инструменты стоит применять для обеспечения безопасности API, и насколько они эффективны в предотвращении конкретных типов атак?

По словам Александра Зубрикова, генерального директора ITG Security, можно выделить следующие инструменты:

• API Gateway для Контроля доступа и аутентификации.
• Web Application Firewall (WAF) для фильтрации трафика.
• Runtime Application Self-Protection (RASP) для обнаружения и блокировки атак в реальном времени внутри приложения.
• Инструменты мониторинга и анализа логов для сбора и анализа логов API, а также обнаружения аномалий.
• Инструменты статического анализа кода (SAST) и Динамическое тестирование API на уязвимости (DAST) на этапах разработки и мажорных версиях продукта.
• Средства управления безопасностью контейнеров и облачных сервисов для защиты среды, где развернуты API.
• Проведение тестирований на проникновение и участие в Bug Bounty программах.

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

Артем Гребенюк, директор департамента эксплуатации информационной безопасности «Ростелекома»: «Традиционные средства защиты WEB типа WAF имеют ограниченную эффективность в части защиты API, поскольку большинство атак связаны с бизнес-логикой приложения и манипуляцией легальными параметрами либо способами авторизации. WAF актуален для защиты от l7ddos, ограничить поверхность атаки через явно разрешенные интерфейсы и параметры. Application firewall все еще актуален в части сигнатурного анализа и предотвращения различных инъекций.

Кроме того, отслеживая время отклика и коды ответа приложения, с помощью WAF есть возможность реализовывать подобие троттлинга или явно ограничивать особенно тяжелые запросы и отдельные IP адреса. На мой взгляд, основной профит в защите API принесут практики безопасной разработки на всех этапах разработки приложения и фаззинг перед публикацией в продуктивной среде. Анализ кода на этапе разработки и своевременное исправление выявленных дефектов позволяет существенно минимизировать риски эксплуатации злоумышленником, а инструментальный и/или ручной фаззинг позволяет отловить недокументированное поведение приложения при различных входных параметрах».

Антон Чемякин, руководитель аналитического отдела Servicepipe, указал на то, что более 80% веб-трафика сегодня — это вызовы API, и этот трафик также насыщен ботами.

«Первое, что приходит на ум – учёт всех доступных методов API и продуманная валидациях всех параметров запросов. Если говорить о “внешних“ средства защиты API сегодня — это анализ логов, API-шлюз, WAF и Антибот-системы».

Как отметил эксперт, многие поставщики веб-защиты предлагают в качестве механизма выявления ботов JS-челлендж (если агенты поддерживают JS), который работает только для веб-сайтов и прерывает работу приложения на стороне пользователя. API-шлюз умеет защищать лишь на уровне аутентификации/авторизации и с помощью грубых рейт-лимитов.

Важным нюансом также является неспособность многих решений защищать API без раскрытия приватного ключа SSL, что довольно важно для компаний, обрабатывающих платежи на бэкенде. Реализовать защиту API (в том числе API мобильных приложений), можно с помощью гибридной схемы внедрения защиты с установкой модуля NGINX в контур инфраструктуры заказчика. Гибридная модель подходит для защиты систем, в которых присутствуют разнородные службы и сервисы. Как работает гибридная защита: параллельно с перенаправлением трафика через облачную платформу фильтрации внутри инфраструктуры размещаются локальные компоненты фильтрующей платформы.

«Неплохо справляются с защитой API решения класса WAF, которые распознают фейковые/модифицированные приложения, используемые для проведения атак на бизнес-логику. Большинство угроз — из эталонного списка OWASP API Security Top 10. Но есть и другая часть — новые угрозы (zero-day) – например, Zombie/Shadow/Orphan API, SMS-бомбинг и ATO-атаки (Credential stuffing). Работающим на базе сигнатурного анализа фаерволам веб-приложений не всегда по зубам угрозы нулевого дня».

Анастасия Травкина, младший системный аналитик, Вебмониторэкс, заявила, чтосуществует достаточное количество инструментов для защиты API, но ни один из них не гарантирует полную безопасность сам по себе. Например, WAF отлично справляется с известными видами атак, OAuth/OpenID Connect помогает предотвратить утечку данных за счет надежной аутентификации и авторизации, Rate Limiting сдерживает DDoS-атаки, а SSL/TLS шифрует передачу данных, чтобы защитить их от перехвата.

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

Павел Нагин, директор по развитию, компания SQUAD, уверен, что наиболее эффективным будет использование специализированного решения по защите API. Часть задач по защите API могут решать WAF, API Manager или подходы DevSecOps, но при этом нужно понимать, что каждый из этих инструментов имеет свои недостатки. WAF будет неэффективен против угроз, связанных некорректной аутентификацией и авторизацией, а также в задачах инвентаризации API. API manager наоборот предлагает проверенные механизмы для аутентификации и авторизации, но не защищает от атак.

«DevSecOps повышает безопасность разрабатываемых API, но учитывает только те угрозы, которые известны на момент разработки. В любом случае, если у организации уже есть WAF или API Manager, которые предлагают функции защиты API, то стоит их попробовать».

Как внедрение Zero Trust подхода помогает минимизировать риски при использовании корпоративных API, и какие сложности возникают при его реализации?

Анастасия Травкина, младший системный аналитик, Вебмониторэкс, подметила, что подход Zero Trust, то есть «нулевого доверия», помогает существенно снизить риски при работе с корпоративными API, так как он основан на принципе недоверия ко всем запросам, вне зависимости от их происхождения. Даже если злоумышленник проникнет внутрь сети, ему будет сложно воспользоваться полученным преимуществом из-за тщательной проверки каждой сессии.

Александр Зубриков, генеральный директор ITG Security, отметил, что при использовании API внедрение Zero Trust подхода помогает минимизировать риски благодаря строгому контролю доступа, постоянной проверке доверия и мониторингу активности. При этом все пользователи и сервисы получают только минимально необходимый доступ к API. Каждому запросу к API предшествуют строгие проверки: кто делает запрос, откуда и тд. Концепция Zero Trust подразумевает постоянное наблюдение за активностью API с помощью SIEM и тд.

«Реализация Zero Trust требует значительных инвестиций в инфраструктуру (например, внедрение сложных СЗИ, таких как IAM, WAF, API Gateway, SIEM), а также глубокого понимания существующей архитектуры API и сервисов. Постоянные проверки доверия могут замедлить работу API и повлиять на производительность. Постоянное обновление политик безопасности и мониторинга требует значительных вычислительных ресурсов, поддержка этих политик — значительных человеческих ресурсов и их достаточно высокую компетенцию».

Павел Нагин, директор по развитию, компания SQUAD, подчеркнул, что внедрение Zero Trust подходов позволяет уменьшить поверхность атаки, а также затруднить продвижение злоумышленника во внутренней инфраструктуре. Zero Trust поможет усилить механизмы аутентификации и контроля доступов в сервисах API.

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

Как выстраивать процессы контроля и мониторинга API в режиме реального времени, чтобы своевременно обнаруживать инциденты?

Антон Чемякин, руководитель аналитического отдела Servicepipe, уверен, что основные подходы мониторинга API сущностно не отличаются от мониторинга любых сервисов, в которые обращаются пользователи и/или легитимная автоматизация. Если стоит задача собственными силами «поднять» анализ трафика, следует чётко разделять эти 2 вида активности и ответить на вопрос: возможен ли каждый из них при обращении к API? Для анализа нужно организовать логирование, как минимум временные метки запросов, вызываемых методов, IP-адресов (и по возможности его производных – подсетей и т.д.), user-agent. Но чем больше информации будет собрано, тем лучше.

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

Если бизнес-логика предполагает, что в API может обращаться автоматизация, то требуется дать ответ на вопрос: Это закрытое API, в которое могут обращаться лишь получившие авторизационный токен партнеры, либо открытое API, куда может обращаться любой пользователь? В обоих случаях следует дать ответ на вопрос: Каковы границы легитимной автоматизации? Как минимум – сколько запросов в сутки/час/минуту может отправлять легитимная автоматизация. Возможно, существуют ограничение на количество и/или тип вызываемых методов. Эту активность так же следует логировать, обсчитывать и мониторить.

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

Павел Нагин, директор по развитию, компания SQUAD: «В первую очередь нужно осуществлять инвентаризацию ваших API, чтобы в любой момент времени иметь актуальную информацию о методах и параметрах, которые использует каждый эндпойнт. Дополнительно полезно понимать какая аутентификация используется, осуществляется ли доступ из сети Интернет или из внутренней сети, какие данные обрабатываются (персональные, финансовые, медицинские, …). Если у вас есть описание API в формате OpenAPI Specification (OAS), то вы можете контролировать соответствие запросов и ответов этому описанию. Для борьбы с атаками перебора (brute force, password spraying, credential stuffing, IDOR) рекомендуется настраивать лимиты по количеству запросов. Ну и наконец, всегда полезно применять сигнатуры для выявления атак в сетевом трафике. Если организация использует Security Operation Center (SOC), то он должен получать события от таких систем контроля и реагировать на инциденты, связанные с API».

Артем Гребенюк, директор департамента эксплуатации информационной безопасности «Ростелекома»: «В «Ростелекоме» мониторинг поведения API проводится как минимум с двух сторон. DevOps инженеры контролируют метрики приложения, производительности, частоту вызова различных функций, производительность ВМ и состояние контейнеров, а также другие параметры. В случае отклонения метрик своевременно реагируют, в том числе привлекая службы ИБ. Со стороны информационной безопасности отслеживается код ответа и частота ответов, время отклика, URI, сессии пользователя и IP адреса и много других параметров. Это позволяет оперативно обнаруживать и реагировать на аномалии».

Александр Зубриков, генеральный директор ITG Security: «Эффективный контроль и мониторинг API в режиме реального времени начинается с централизованного сбора логов и данных запросов, что позволяет фиксировать любые аномалии. Важным элементом выступают инструменты реального времени: API Gateway и WAF, которые защищают API от DDoS-атак, брутфорса и инъекций, фильтруя подозрительный трафик. Для глубокого анализа поведения API используются системы мониторинга (например, SIEM), которые выявляют аномалии и инциденты на основе анализа паттернов активности. Основной момент — автоматизация реагирования: интеграция с SOAR-платформами позволяет оперативно блокировать угрозы и уведомлять ответственных специалистов».

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

Анастасия Травкина, младший системный аналитик, Вебмониторэкс: «Эксперты Вебмониторэкс выделяют следующие методы:

• OAuth 2.0 / OpenID Connect. Эти стандарты обеспечивают безопасный обмен токенами доступа и идентификационной информацией между различными приложениями.
• JSON Web Tokens (JWT). Легковесные и самоописательные токены, которые облегчают проверку подлинности и авторизации.
• Mutual TLS (mTLS). Двухсторонняя аутентификация, усиливающая безопасность взаимодействия между сервисами.
• Multi-Factor Authentication (MFA). Добавляет еще один уровень защиты, требуя использования нескольких факторов для успешной аутентификации.

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

Павел Нагин, директор по развитию, компания SQUAD, сообщил, что в настоящее время существует множество проверенных стандартов аутентификации и авторизации в API: oAuth, OpenID Connect, client certificates, mutual TLS, JSON Web Token (JWT) и так далее. Основная рекомендация для разработчиков – не пытаться самостоятельно разрабатывать свои методы, для этого нужная большая экспертиза в криптографии и многолетний опыт создания подобных систем. Лучше использовать популярные фрэймворки (например, Spring Security), и аккуратно следовать рекомендациям их поставщиков и международных стандартов в этой области.

«Отдельно нужно обратить внимание на защиту секретов, используемых для аутентификации, от доступа посторонних. Например, закрытые ключи от сертификатов желательно хранить на носителях, исключающих их извлечение и копирование: токены, смарт-карты, аппаратные модули безопасности (HSM). Токены и ключи аутентификации не должны быть прописаны в исходных кодах приложения, а для их передачи нужно использовать защищенные протоколы (TLS). Для пользователя удобно, когда разработчик побеспокоился о безопасной реализации, и ему нужно осуществлять минимум усилий для работы с API. Хороший пример — использование отпечатков пальцев в мобильных устройствах для доступа к возможностям мобильного приложения».

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

Никита Черняков, руководитель департамента развития бизнеса решений ИБ компании Axoft: «Боюсь показаться неоригинальным, но подход к обеспечению безопасности API на стадии проектирования и разработки не должен отличаться от подходов к обеспечению защиты самого приложения. Этот подход обычно называют «Security by Design» – при нём механизмы и средства киберзащиты интегрированы в архитектуру и код приложения и являются неотъемлемой его частью.

Другими словами, если разработчики на этапе проектирования и разработки заложат механизмы обеспечения безопасности в том числе и API – это повысит общий уровень защищенности с одной стороны, с другой – минимизирует издержки, связанные с использованием наложенных средств защиты при эксплуатации. Рекомендации для разработчиков можно почерпнуть, например, в OWASP API Security Top10».

Павел Нагин, директор по развитию, компания SQUAD, уточнил, что на стадии проектирования полезно выбрать стек технологий и решений, которые имеют встроенные функции безопасности для API, чтобы не разрабатывать их самостоятельно. Если в API планируются функции безопасности такие как аутентификация, авторизация, шифрование или электронная подпись, то для их реализации обязательно потребуется экспертиза в области информационной безопасности.

«Пользовательские сценарии (user story) также лучше заранее согласовать с экспертом по кибербезопасности. Это позволит избежать очевидных уязвимостей в бизнес-логике, которые в последующем будут иметь серьезные последствия. Пример из жизни – необходимо выдавать клиентам купоны для скидки, но для простоты реализации используются короткие коды и не проверятся факт их использования. Если не подключить подразделение ИБ, то будут следующие последствия: в лучшем случае кодами многократно сможет воспользоваться любой пользователь, а в худшем случае скидка будет суммироваться и что-то получится купить за 0».

Александр Зубриков, генеральный директор ITG Security: «К вопросу безопасности API следует подходить как и к безопасности других компонентов.

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

Важно сразу заложить принципы минимальных привилегий, декомпозировать функциональность, запроектировать мандатно-ролевой доступ и т. д., чтобы каждая операция проходила проверку аутентификации и авторизации. Документирование API с использованием стандартов, таких как OpenAPI, и тщательная валидация входных данных должна уберечь от механических уязвимостей по типу SQLi.

Ну, и регулярное тестирование API, включая fuzz-тестирование и анализ безопасности в CI/CD pipeline, позволит выявить проблемы на ранних этапах».

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

Помимо этого, необходимо внедрить современные методы аутентификации и авторизации, такие как OAuth или JWT, обеспечить шифрование данных при передаче данных через протоколы TLS/SSL. Не менее важен и контроль доступа к сетевым ресурсам с применением брандмауэров и списков контроля. На более поздних этапах проектирования и создания API необходимо обязательно предусмотреть механизмы для регистрации и анализа событий безопасности, а также провести статический и динамический анализ кода, включая тестирование на проникновение. Наконец, убедится, что ваш проект соответствует актуальным стандартам безопасности, таким как OWASP или ISO».

Какие подходы помогают эффективно выстроить взаимодействие команд разработки и ИБ для защиты API, и как это влияет на снижение рисков и ускорение процессов разработки?

Артем Гребенюк, директор департамента эксплуатации информационной безопасности «Ростелекома»: «Самое сложное в защите разветвленных интерфейсов, особенно динамично развивающихся, — это тщательное и корректное документирование API и поддержка этой информации в актуальном состоянии. Без такой документации сложно представить аудит и контроль функционала перед публикацией, кастомизированную защиту на WAF/WAAP, и вероятность публикации лишних параметров в Интернет сильно возрастает. Кроме того, без хорошей документации по опубликованным интерфейсам и параметрам средства защиты WEB и API будут блокировать легальных пользователей, особенно после свежего релиза. В “Ростелекоме” DevOps-инженеры используют Swagger для документирования. Это позволяет подразделениям кибербезопасности оперативно и однозначно обеспечивать и актуализировать меры защиты».

Как заявил Александр Зубриков, генеральный директор ITG Security, эффективное взаимодействие команд разработки и ИБ является ключевым фактором защиты API. Важно внедрить подход DevSecOps, чтобы безопасность интегрировалась на всех этапах жизненного цикла разработки. Это включает автоматизированное тестирование безопасности API в CI/CD-процессах и использование инструментов, которые легко интегрируются в рабочие процессы разработчиков. Совместное создание спецификаций API с учетом требований безопасности позволяет предотвратить уязвимости еще на этапе проектирования.

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

«Например, в крупных организациях принимается много усилий по обеспечению безопасной разработки API и его публикации в продуктиве: анализ кода (SAST), компонентный анализ (SCA), сканирование (DAST), использование шлюзов API, … Однако регулярно возникает ситуация, когда релиз новых сервисов задерживается из-за того, что не пройдена часть проверок, а устранение несоответствий требует значительного времени. Компромиссным решением могла быть публикация уязвимого сервиса за специализированным решением по защите API, которое снижает риски успешных атак (виртуальный патчинг)».

Как проводить тестирование API на уязвимости, чтобы избежать ложноположительных результатов и не упустить критические ошибки?

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

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

Александр Зубриков, генеральный директор ITG Security: «Использование проверенных инструментов, таких как OWASP ZAP или Burp Suite, в сочетании с анализом спецификаций API (например, OpenAPI/Swagger).

Для повышения точности нужно проводить тестирование в реальной среде с различными ролями пользователей.

Комбинированное использование статического (SAST) и динамического (DAST) тестирования помогает обнаруживать как проблемы в коде, так и уязвимости в поведении API.

Обязательно проводить ручное тестирование критических функций. Это дополняет автоматизацию, позволяя анализировать бизнес-логику и управление сессиями. Следовательно, делать пентесты и участвовать в Bug Bounty.

Интеграция автоматического тестирования в CI/CD pipeline обеспечивает регулярную проверку на ранних этапах разработки, а ретестирование после исправления подтверждает устранение проблем».

Какие метрики или показатели эффективности стоит применять для оценки уровня защиты API?

Артем Гребенюк, директор департамента эксплуатации информационной безопасности «Ростелекома»: «Единственной и относительно объективной мерой защищенности является инструментальный анализ защищенности. Чем больше усилий будет вложено в анализ защищенности перед публикацией приложения, тем меньше вероятность того, что злоумышленник выявит и проэксплуатирует недокументированные возможности. Для наиболее критичных сервисов имеет смысл проводить публичное тестирование на проникновение (bug bounty) — это существенно расширяет возможности внутренней команды по анализу защищенности».

Александр Зубриков, генеральный директор ITG Security: «Одной из ключевых метрик является количество обнаруженных и устраненных уязвимостей, что позволяет оценить качество тестирования и своевременность исправлений.

• Важным показателем также является доля успешных попыток несанкционированного доступа.
• Время реакции на инциденты (Mean Time to Detect и Mean Time to Respond) отражает эффективность процессов мониторинга и реагирования.
• Метрика частоты вызова ошибок (HTTP 4xx/5xx)
• Частота отклоненных запросов (например, из-за rate limiting или подозрительной активности) показывает, насколько эффективно API защищено от DDoS-атак и брутфорса».

Павел Нагин, директор по развитию, компания SQUAD: «Инциденты ИБ, связанные с API, случаются нечасто, поэтому их отсутствие обычно не говорит о высоком уровне защищенности. Если организация на регулярной основе выполняет сканирование на уязвимости своих API сервисов (DAST), то можно отслеживать количество новых и актуальных уязвимостей разной критичности.

Рост этого количества может говорить о неэффективности процессов патчинга и в итоге приведет к тому, что уязвимостью воспользуется злоумышленник. Если на периодической основе выполняется тест на проникновение, то его результаты также можно анализировать в динамике. В наиболее зрелых организациях применяют комплексную имитацию атак (red teaming), в таком случае проверяют реагирование сотрудников SOC. Именно поэтому важен мониторинг обращений к API, который позволяет выявлять атаку на ранних этапах. Актуальная инвентаризация API критична на стадии реагирования. По наличию или отсутствию этих процессов (мониторинг и инвентаризация) уже можно судить об эффективности защиты API».