Автор: Тимофей Горбунов, продуктовый маркетолог “Вебмониторэкс”
Оставаясь лидером в сфере веб-защиты, компания "Вебмониторэкс" рассматривает будущее интернет-технологий как экосистему сервисов, основанных на веб-решениях и API.
Задумайтесь, какое количество "толстых" клиентов вы используете уже сегодня? Какие тренды зарубежного технологического рынка сформировались за последние годы и дойдут до нас в полном объеме в ближайшее время?
Одного только первого вопроса достаточно, чтобы срочно начать принимать меры по защите API. При этом никому не хочется быть первопроходцем и самостоятельно решать все возникающие проблемы. Но хорошая новость заключается в том, что мы уже прошли этот путь, преодолев все трудности и собрав все необходимые методологии и технологии в собственный уникальный подход.
Для начала мы определили, как решали проблему раньше, когда атак на API было мало. Ответ оказался прост – их фильтровали тем же WAF, что и обычный интернет-трафик. При прежнем уровне угроз простого мониторинга API-вызовов действительно хватало. Но сегодня этого недостаточно. Учитывая растущий уровень угроз, теперь требуются специальные средства защиты и конкретные действия по анализу и блокировке передаваемых данных.
Приложение или инфраструктура – это динамично развивающиеся сущности, в работе над которыми принимают участие десятки человек, каждый из которых отвечает за что-то свое.
Думаю, каждый сможет вспомнить ситуацию, когда неожиданно выяснилось, что какой-то компонент работал не так, как должен, а про другой вообще забыли, – API могут быть подвержены таким же проблемам. Прежде чем создать систему защиты, необходимо проверить ИТ-инфраструктуру, провести инвентаризацию всех API. Это поможет выявить те, что не имеют должной документации, а также те, которые почему-то не получают трафик или числятся отключенными, но продолжают использоваться.
На первом этапе можно проанализировать весь трафик обнаруженных API: определить для каждого из них адреса конечных точек сервиса, на которые отправляются запросы (эндпоинты) и используемые на них параметры; создать необходимую документацию, фиксирующую разрешенные возможности каждого API, а также оценить угрозы и риски.
Документация, описывающая API (OAS-спецификация), является важнейшим элементом в создании системы защиты. Ее следует формировать на первом этапе построения безопасности даже для тех API, у которых она была утрачена или отсутствовала. Далее можно настроить проверку трафика более точным средством, чем привычный WAF, чтобы проверять не базовые параметры, а соответствие заявленной спецификации. Этим средством защиты является API Firewall.
API Firewall, в отличие от WAF, работает на основе позитивной модели, то есть запрещает любые действия, для которых нет явного разрешения (именно это и есть главная проблема действующего с противоположной логикой WAF, когда его используют для защиты API). Когда API является открытым для всех, к нему поступает огромное количество запросов. Поэтому в этих условиях не применима логика, в которой разрешается все, кроме явно запрещенного, но происходит изучение каждого запроса на наличие атаки, – это неэффективное использование вычислительных ресурсов. Правильнее будет разделить функции защиты веб-приложений и защиты API между Web Application 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, председателем которого является первый заместитель директора ФСТЭК России, а именно подкомитетом No2 "Разработка безопасного ПО" под руководством представителя Института системного программирования РАН им. В. П. Иванникова. Такое взаимодействие позволяет разрабатывать документы сразу в контексте их последующего применения. То есть подкомитет планирует разработку стандарта по динамическому анализу, а регулятор ставит в план обновление ряда методических документов в области сертификации ПО и принципов создания безопасного и качественного ПО.
И самое важное – учитывается мнение рынка. К обсуждению данных вопросов привлекаются ведущие профильные эксперты отрасли. С недавних пор к тематике проектирования, тестирования, управления и защиты API подключилась и команда "Вебмониторэкс". Мы делимся экспертизой, так как прошли большой путь в управлении и защите API, сформировав собственный подход, заключающийся в трех этапах, которые мы сегодня и рассмотрели: знать, защищать и не допускать.