Журнал "Information Security/ Информационная безопасность" #1, 2025

Еще в процессе разра- ботки можно протестировать работу API и найти допущен- ные ошибки. Современная разработка, как правило, является про- цессом быстрым и ограни- ченным в ресурсах. Сегодня все чаще обсуж- дается процесс безопасной разработки программного обеспечения: и эксперты отрасли, и регулирующие органы согласны в том, что этап динамического тести- рования является неотъем- лемой его частью. ной логикой WAF, когда его используют для защиты API). Когда API является открытым для всех, к нему поступает огромное количество запросов. Поэтому в этих условиях не применима логика, в которой разрешается все, кроме явно запрещенного, но происходит изучение каждого запроса на наличие атаки, – это неэффек- тивное использование вычис- лительных ресурсов. Правиль- нее будет разделить функции защиты веб-приложений и защиты API между Web Appli- cation Firewall и API Firewall. Имеет смысл поставить API Firewall на передний край защи- ты, чтобы сразу отсекать от WAF максимально зашумлен- ный трафик API-вызовов, так как доля бот-запросов может составлять до 60%. Предотвращение угроз А что, если можно было бы еще сильнее снизить риски и убрать часть угроз до тех эта- пов, когда мы начали инвента- ризировать API и контролиро- вать трафик API-вызовов? Еще в процессе разработки можно протестировать работу API и найти допущенные ошиб- ки, которые могут стать уязви- мостями. Сложность заключа- ется в том, что современная разработка, как правило, является процессом быстрым и ограниченным в ресурсах. Поэтому такая задача требует или замедления доставки новых функций до конечного пользо- вателя, или затрат, которые могут в итоге не окупиться. Либо специального автомати- зированного средства, которое учтет все особенности работы с API и сможет встроиться в непрерывный CI/CD-конвейер. Для решения такой проблемы сегодня широко используются автоматизированные средства оптимизации кода (линтеры), SAST- и DAST-анализаторы. Первые два являются доста- точно простыми средствами и не требуют тонких настроек, так как проверяют статичный программный код. Но при рабо- те с DAST необходимо больше знаний и навыков, так как дина- мическая проверка исполняе- мого приложения является существенно более сложной задачей. Не все DAST-анали- заторы одинаково хороши, и не все из них могут досконально проверить API, используя лишь одну OAS-спецификацию. Наи- более распространенные сред- ства могут выявить в API только уязвимости, связанные с про- стыми инъекциями, не более. Если обратиться к различным нормативным документам, рекомендациям, методологиям и стандартам, то проверка на наличие инъекций является только одним из множества тестов. Сегодня все чаще обсуждается процесс безопас- ной разработки программного обеспечения: и эксперты отрас- ли, и регулирующие органы согласны в том, что этап дина- мического тестирования являет- ся неотъемлемой его частью. Наиболее полное и актуаль- ное описание требований к орга- низации процессов безопасной и качественной разработки ПО в организациях содержится в ГОСТ Р 56939-2024, а также в семействе уточняющих стандар- тов в области РБПО, таких как ГОСТ Р 71207-2024 (требования к процессу статического анали- за исходного кода) и др. Разви- тие стандартов ведется Техни- ческим комитетом 362, предсе- дателем которого является пер- вый заместитель директора ФСТЭК России, а именно под- комитетом№2 "Разработка без- опасного ПО" под руководством представителя Института системного программирования РАН им. В. П. Иванникова. Такое взаимодействие позволяет раз- рабатывать документы сразу в контексте их последующего применения. То есть подкомитет планирует разработку стандарта по динамическому анализу, а регулятор ставит в план обнов- ление ряда методических доку- ментов в области сертификации ПО и принципов создания без- опасного и качественного ПО. И самое важное – учитыва- ется мнение рынка. К обсуж- дению данных вопросов при- влекаются ведущие профиль- ные эксперты отрасли. С недав- них пор к тематике проектиро- вания, тестирования, управле- ния и защиты API подключи- лась и команда "Вебмонито- рэкс". Мы делимся эксперти- зой, так как прошли большой путь в управлении и защите API, сформировав собственный подход, заключающийся в трех этапах, которые мы сегодня и рассмотрели: знать, защи- щать и не допускать. l • 43 Защита API www.itsec.ru АДРЕСА И ТЕЛЕФОНЫ ВЕБМОНИТОРЭКС см. стр. 68 NM Реклама