Топ-10 угроз для API по версии OWASP

Вы просматриваете документацию по Apigee Edge.
Перейдите к документации по Apigee X. Информация

В этом документе описываются различные подходы, которые можно использовать в Apigee для устранения уязвимостей безопасности, выявленных OWASP. Дополнительные подходы, описанные для Apigee, можно найти в разделе Варианты устранения уязвимостей OWASP Top 10 2021 в Google Cloud.

Введение

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

В этом документе рассматриваются подходы к защите от распространенных атак на основе API, которые были выявлены в 2019 году в рамках проекта OWASP Top Ten API Security Threats. В списке самых распространенных угроз, опубликованном недавно, часто упоминаются проблемы, связанные с неправильным размещением средств аутентификации и авторизации. Например, в клиентских приложениях для фильтрации данных, возвращаемых запросом API, используется антипаттерн, при котором контроль доступа осуществляется клиентским приложением.

Экосистема API быстро развивается, и, к сожалению, злоупотребление API и неправильное их использование, приводящие к утечке данных, становятся одним из самых распространенных векторов атак. Безопасность по-прежнему является ключевым приоритетом для Apigee, поэтому мы добавили ряд новых функций, таких как Advanced API Ops, в которую входят функции обнаружения аномалий. Однако правильное проектирование и реализация функций безопасности Apigee имеют решающее значение для снижения вероятности успешных атак на ваши API.

Потребительские приложения следует считать ненадежными или "общедоступными", поскольку вы не контролируете платформу, на которой они работают. Предположим, что любое общедоступное приложение может быть взломано, поэтому ему нельзя доверять принудительное применение контроля доступа (API1, API5), фильтрацию данных ответа (API6) или безопасное хранение секретов клиента (API2), таких как ключи API или токены доступа. Некоторые рекомендации основаны на списке OWASP Top 10 за 2019 год:

  • Определите, какие клиентские приложения будут использовать ваши API (одностраничные приложения, мобильные приложения или приложения на основе браузера), и разработайте подходящие шаблоны аутентификации, авторизации и безопасности.
  • Всегда используйте OAuth или OpenID Connect для "общедоступного клиента" (настоятельно рекомендуется использовать PKCE).
  • Сначала определите бизнес-логику приложения, создайте спецификацию OpenAPI и разработайте прокси API, чтобы фильтровать все данные ответов от внутреннего сервиса в Apigee. Никогда не полагайтесь на логику кода приложения, в которое передается контент.
  • Отфильтруйте все запросы данных, содержащие персональную информацию, чтобы разрешить доступ только к данным из вашего внутреннего сервиса, которые принадлежат пользователю, отправившему запрос.

API1:2019 Некорректная авторизация на уровне объектов

Описание угрозы

Недостаточная проверка авторизации запроса на доступ к объекту позволяет злоумышленнику выполнить несанкционированное действие, повторно используя токен доступа. Эта угроза вызвана неправильной конфигурацией проверок авторизации. Apigee предоставляет правила VerifyApiKey, OAuth и JSON Web Token (JWT), которые помогают защититься от этой уязвимости. Однако важно правильно настроить эти правила, чтобы предотвратить угрозу.

Чтобы предотвратить эту угрозу, важно, чтобы команды разработчиков и специалистов по безопасности тесно сотрудничали. Авторизация – сложная тема, и для эффективной детализированной авторизации требуется глубокое понимание бизнес-логики приложения.

С точки зрения реализации Apigee необходимо учитывать два основных аспекта:

  • Целостность токена доступа
  • Принудительное применение правил доступа

Целостность токена доступа

Важно убедиться, что токен, предоставленный запрашивающим клиентом, не был изменен. Для этого используйте правильный процесс OAuth или OpenID Connect вместе с подходящим механизмом проверки или подписи учетных данных. Apigee поддерживает все распространенные потоки OAuth.

Правила проверки токенов доступа Apigee включают:

Принудительное применение контроля доступа

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

Apigee предоставляет два основных механизма для проверки и применения правил авторизации:

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

Внутренний подход (показан на рисунке выше) рекомендуется, если модель контроля доступа относительно проста. Например, если утверждения, извлеченные из токена доступа, можно использовать для прямой оценки и авторизации запроса объекта API.

Используйте переменные потока, доступные для правил OAuth или JWT, чтобы оценивать запросы на доступ с помощью условных операторов потока.

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

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

API2:2019 Нарушение аутентификации пользователей

Описание угрозы

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

  • Всегда выполняйте аутентификацию как агента пользователя (приложения), так и пользователя, отправившего запрос.
  • Используйте шаблоны делегированной аутентификации и авторизации и не передавайте пароли напрямую в запросе к API.
  • Всегда проверяйте подпись учетных данных для доступа и убедитесь, что у всех используемых учетных данных для доступа задан срок действия.
  • Предотвращение атак методом перебора путем установки квот и использования Apigee Sense для обнаружения атак методом перебора, выполняемых ботами, и реагирования на них

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

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

  • Проектирование безопасности. Полное использование функций Apigee для реализации шаблонов аутентификации.
  • Управление. Обеспечение правильного и единообразного использования разработанных шаблонов аутентификации во всех опубликованных продуктах API.
  • Операционная безопасность: возможность обнаруживать подозрительное или аномальное поведение и попытки обойти или взломать аутентифицированные прокси API.

Безопасность

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

В спецификациях OpenID Connect и OAuth описано множество способов делегированной аутентификации и авторизации, а также участников этих процессов. Это сложная тема, и неудивительно, что нарушение аутентификации входит в число основных угроз API по версии OWASP. Подробное описание правильной реализации стандартов идентификации выходит за рамки этого документа, но у Apigee есть много дополнительных ресурсов для лучшего понимания потоков OAuth, таких как электронная книга, веб-трансляция и пример реализации.

Правила аутентификации

Правила Apigee, которые помогают решать проблемы с идентификацией и аутентификацией, включают:

Управление трафиком

Следующие функции управления трафиком Apigee помогают защититься от атак методом перебора:

  • Правило Spike Arrest для установки общего скользящего среднего ограничения на частоту запросов для прокси API.
  • Правила квот для настройки точных ограничений на количество запросов к прокси API на основе квот, заданных ключами приложений, разработчиками или квотами продуктов API.
  • Правила кеширования для кеширования сохраненных токенов доступа на основе заданного срока действия, а также возможность отзывать кешированные учетные данные (например, в ситуации, когда действительный токен доступа был скомпрометирован).

Руководство

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

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

Контроль доступа на основе ролей (RBAC)

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

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

Общие потоки

Общие потоки позволяют определять правила и ресурсы в виде объектов, которые можно использовать в разных прокси API. Например, вы могли совместно с командой по безопасности разработать несколько шаблонов аутентификации на основе типа приложения, использующего API. Разработчику API не нужно быть экспертом в области идентификации, чтобы использовать этот поток. Ему просто нужно знать, какой общий поток добавить в существующую конфигурацию прокси API с помощью правила Flow callout.

Рисунок. Общие потоки – это многократно используемые наборы правил и условной логики, которые позволяют поддерживать составной шаблон.

Операционная безопасность

После того как ваши API будут запущены в производство с использованием правильных шаблонов аутентификации и базового управления трафиком, ваша команда SecOps также должна иметь возможность отслеживать подозрительную активность и реагировать на нее. Часто она начинается с попыток взлома учетных данных для аутентификации.

Apigee Sense

Apigee Sense защищает ваши API от нежелательного трафика запросов, в том числе от атак вредоносных клиентов. Apigee Sense анализирует трафик запросов API, выявляя шаблоны, которые могут представлять нежелательные запросы. На основе этого анализа вы можете определить клиентов, отправляющих нежелательные запросы, а затем разрешить, заблокировать или пометить эти запросы. В будущем Sense сможет автоматически включать проверку reCAPTCHA для подозрительного трафика.

Apigee Sense позволяет защитить API от шаблонов запросов, которые включают:

  • Автоматизированное поведение, которое неотличимо от человеческого
  • Постоянные попытки с одного IP-адреса
  • Необычные коэффициенты ошибок
  • Подозрительные запросы клиентов
  • Сканирование данных
  • Атаки методом подбора и сбора ключей
  • Всплески активности
  • Географические закономерности

Расширенные операции с API

Sense специально разработан для обнаружения угроз, связанных с ботами, и реагирования на них, а Advanced API Ops включает как обнаружение аномалий, так и определение расширенных оповещений.

Обнаружение аномалий работает на основе моделей искусственного интеллекта (ИИ) и машинного обучения (МО), которые применяются к вашим историческим данным API. Благодаря этому вы сможете получать оповещения в реальном времени о проблемах, о которых даже не подозревали, повышать продуктивность и сокращать среднее время устранения неполадок с API.

Расширенные операции с API дополняют существующий механизм оповещений о мониторинге API следующими типами оповещений:

  • Оповещения об аномалиях. Edge обнаруживает проблемы с трафиком и производительностью, поэтому вам не нужно определять их самостоятельно. После этого вы можете настроить оповещения об этих аномалиях.
  • Оповещения об истечении срока действия TLS. Показывает уведомление, когда срок действия сертификата TLS скоро истечет

API3:2019 Чрезмерное раскрытие данных

Описание угрозы

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

Один из принципов разработки API, используемых Apigee, – внешний подход – подразумевает минимизацию данных. Вместе с UX-дизайнерами и разработчиками определите, какие данные должны быть доступны через API в интерфейсе приложения. Бэкэнд-системы не предназначены для публичного использования, поэтому одна из первых задач при разработке API с помощью Apigee – сократить объем данных, предоставляемых клиентам и разработчикам, до минимума, необходимого для создания качественного продукта API.

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

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

В следующих разделах рассказывается, как:

  • Переписывать запросы и ответы на внутренние сервисы, чтобы минимизировать раскрытие данных.
  • Реализуйте обработку ошибок, чтобы предотвратить раскрытие конфиденциальной информации о серверных службах злоумышленникам с помощью подробных сообщений об ошибках.

Переписывание ответов и запросов

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

Для этого Apigee использует три ключевых правила:

  • Назначить сообщение
  • Уточнения с кодом
  • Обработка ошибок

Как назначить правила для сообщений

Правило Assign Message изменяет или создает новые сообщения запросов и ответов во время выполнения потока прокси-сервера API. Правило позволяет выполнять с такими письмами следующие действия:

  • Добавить новые параметры формы, заголовки или параметры запроса в письмо.
  • Копирование существующих свойств из одного письма в другое.
  • Удалить заголовки, параметры запроса, параметры формы и/или полезную нагрузку сообщения из письма.
  • Задайте значение существующих свойств в сообщении.

С помощью политики Assign Message обычно добавляют, изменяют или удаляют свойства запроса или ответа. Однако вы также можете использовать функцию "Назначить сообщение", чтобы создать собственный запрос или ответ и передать его альтернативному целевому объекту, как описано в разделе Создание собственных запросов.

Сложная переработка с помощью специального кода

Для сложных правил обработки и перезаписи данных, которые нельзя реализовать с помощью правила "Назначить правило для сообщений", можно использовать процедурные языки, такие как JavaScript, Java или Python. Вы можете добавить в прокси-сервер API собственный код, а затем вызвать его из правил, добавленных в поток прокси. Поддержка процедурного кода позволяет упростить реализацию сложных операций с переменными потока, ошибками и телами запросов и ответов.

Процедурный код позволяет:

  • Создавать или изменять сложные значения тела, например значения запросов и ответов.
  • Переписывать URL, например чтобы скрыть целевой URL конечной точки.

В Apigee Edge есть отдельные правила для поддерживаемых языков: правило JavaScript, правило вызова Java и правило скрипта Python.

Обработка ошибок

Apigee позволяет выполнять обработку исключений с помощью правила типа Raise Fault. Правило Raise Fault, которое является разновидностью правила Assign Message, позволяет создавать собственные ответы об ошибках.

Общие потоки

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

API4:2019 Недостаток ресурсов и ограничение частоты

Описание угрозы

Если не реализовать правила ограничения частоты запросов, злоумышленники могут перегрузить бэкенд DoS-атаками.

Эту угрозу можно легко устранить, используя следующие функции Apigee:

  • Квоты и правила защиты от пиковых нагрузок в качестве профилактических мер для ограничения входящих запросов API.
  • Apigee Sense для динамического обнаружения атак, выполняемых ботами, и реагирования на них.
  • Расширенный мониторинг API и оповещения в качестве средств обнаружения, позволяющих получать уведомления о текущих DDoS-атаках.

Ограничение частоты запросов с помощью квот и правил защиты от пиковых нагрузок

В Apigee есть два правила для ограничения скорости:

  • Spike Arrest – это общая политика, заданная на уровне прокси API, которая ограничивает общее количество входящих запросов к серверной части.
  • Квоты – это инструмент для детальной настройки правил, позволяющий применять их на уровне прокси API или продукта API.

Захват шипа

Правило Spike Arrest защищает от резких скачков трафика. Это правило ограничивает количество запросов, обрабатываемых прокси API и отправляемых в серверную часть, чтобы предотвратить снижение производительности и простои. Для этого используется скользящее среднее значение, которое можно задать в правиле.

Квоты

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

  • Продукт, содержащий прокси API
  • Приложение, запрашивающее API
  • Разработчик приложения
  • Множество других критериев

Это правило более детализировано, чем "Предотвращение скачков", и обычно используется вместе с ним.

Обнаружение ботов с помощью Apigee Sense

С помощью Apigee Sense можно разрешать, блокировать или отмечать запросы от определенных клиентов, диапазонов IP-адресов или организаций автономных систем, если эти клиенты или местоположения демонстрируют вредоносное или подозрительное поведение. Apigee Edge применяет эти действия к запросам до того, как их обработают прокси API. Например, можно обнаружить диапазон IP-адресов или определенного клиента, который ведет себя как "грубый угадчик", а затем заблокировать или пометить его.

Обнаружение угроз с помощью Advanced API Ops Monitoring

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

API5:2019 Неработающая авторизация на уровне функций

Описание угрозы

Эта угроза является разновидностью API1 и также представляет собой уязвимость авторизации. При такой угрозе злоумышленник может выполнять действия, отправляя запросы к функциям, к которым у него нет доступа. Например, злоумышленник может изменить или удалить данные, которые ему разрешено только читать, если конечная точка API не проверяет глагол HTTP-запроса, заменив GET на PUT или DELETE. Или, если не реализовать достаточно строгий контроль доступа к пути URI ресурса API, конечная точка API может позволить злоумышленнику просматривать данные другого пользователя, просто изменив путь в запросе.

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

Концептуальные элементы, позволяющие снизить вероятность этой угрозы, обычно делятся на следующие категории:

  • Что защищается? Продумайте стратегию использования API и реализуйте логическую сегментацию функций, следуя рекомендациям по использованию REST при проектировании путей и ресурсов, предоставляемых прокси API Apigee, а также функций продуктов и приложений.
  • Кто получает доступ к ресурсам API? Определите основные роли и реализуйте принцип наименьших привилегий, используя функции аутентификации и авторизации Apigee, как описано в API1 и API2.
  • Как обеспечивается соблюдение правил доступа? Используйте условные потоки и ошибки, чтобы проверять путь URL и глагол всех запросов к API.

Рисунок. На этой диаграмме показано, как в Apigee применяется авторизация на уровне функций с использованием областей, указанных в токене доступа, в качестве прав.

Логическая сегментация с помощью прокси-серверов, продуктов и приложений API

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

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

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

Доступ на уровне функций Управление с помощью областей действия OAuth и утверждений JWT

Хотя описанные выше подходы к авторизации для API1:2019 "Некорректная авторизация объектов" позволяют реализовать точное управление доступом на уровне объектов, не менее важно обеспечить грубое управление доступом на уровне функций. Разрешено ли пользователю, отправившему запрос, запрашивать этот путь URL? Такие правила часто определяются для разных типов пользователей (клиентов, сотрудников, администраторов, внутренних или сторонних разработчиков).

Чтобы снизить риск неправильной настройки, мы рекомендуем обратиться к команде по обеспечению безопасности и убедиться, что утверждения о пользователе, отправившем запрос, содержатся в токене доступа либо с помощью областей действия OAuth, либо с помощью утверждений JWT.

Как запросить проверку с помощью процессов с условиями

На базовом уровне вызов REST API состоит из следующих элементов:

  • конечная точка;
  • ресурс;
  • глагол действия;
  • Любое количество дополнительных атрибутов запроса, например параметров запроса.

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

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

  • Условная логика и правила Raise Fault, чтобы ограничить пути к ресурсам или глаголы на любом этапе конфигурации потока прокси-сервера.
  • JSON и XML Правила защиты от угроз для защиты от атак на основе контента с использованием некорректных полезных нагрузок запросов JSON или XML.

API6:2019 Mass assignment

Описание угрозы

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

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

Обычно для реализации такой угрозы используются два аспекта:

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

В продуктах Apigee есть несколько полезных функций, которые позволяют реализовать надежную фильтрацию данных в ваших API.

Правила фильтрации спецификации OpenAPI

Правило OASValidation (проверка спецификации OpenAPI) позволяет проверять входящие запросы или ответы на соответствие спецификации OpenAPI 3.0 (JSON или YAML). Это правило позволяет:

  1. Создайте спецификацию OpenAPI (OAS) для своего API
  2. Реализовать необходимую логику медиации, безопасности и кеширования, чтобы безопасно предоставлять доступ к продукту API из вашего внутреннего сервиса с помощью Apigee.
  3. Проверяйте входящие запросы на соответствие схеме данных, определенной в спецификации OAS, включая basepath, verb, request message policy и parameters.

Правило проверки сообщений SOAP

Правило проверки сообщений SOAP позволяет проверять запросы на основе XML, сравнивая XML-сообщение со схемой XSD или сообщение SOAP с определением WSDL. Кроме того, вы можете использовать правила проверки сообщений, чтобы убедиться, что полезная нагрузка сообщения JSON или XML имеет правильный формат. В частности, правила позволяют проверить следующее:

  • Один корневой элемент.
  • Контент не содержит недопустимых символов.
  • Объекты и теги правильно вложены.
  • Начальный и конечный теги совпадают

API7:2019 Неправильная конфигурация безопасности

Описание угрозы

Неправильная настройка безопасности обычно является результатом небезопасных конфигураций по умолчанию, неполных или специальных конфигураций, открытого облачного хранилища, неправильно настроенных заголовков HTTP, ненужных методов HTTP, разрешительного совместного использования ресурсов между разными источниками (CORS) и подробных сообщений об ошибках, содержащих конфиденциальную информацию. Злоумышленники часто пытаются найти необновленные уязвимости, общедоступные конечные точки или незащищенные файлы и каталоги, чтобы получить несанкционированный доступ к системе, которую они хотят атаковать, или узнать о ней больше. Неправильная настройка безопасности может привести не только к раскрытию конфиденциальных пользовательских данных, но и к раскрытию системной информации, которая может быть использована для взлома сервера. Кроме того, уязвимости, связанные с неправильной настройкой безопасности, могут использоваться в следующих целях:

  • Неправильная конфигурация TLS
  • Сообщения об ошибках с трассировкой стека
  • Системы без исправлений
  • Панели управления сервером или хранилищем

Организации могут предпринять различные меры, чтобы устранить и снизить риски, связанные с неправильной настройкой безопасности, в том числе:

  1. Создание и стандартизация процессов усиления защиты и установки исправлений
  2. Разработка правил использования экосистемы API
  3. Ограничение доступа с правами администратора и включение аудита и оповещений

Общие потоки и хуки потоков

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

Мониторинг API

Apigee предоставляет комплексную платформу API Monitoring. API Monitoring позволяет организациям заблаговременно выявлять проблемы с трафиком и производительностью API. Apigee API Monitoring работает совместно с Apigee Edge для общедоступного облака и предоставляет контекстную информацию о производительности API в реальном времени. Это помогает быстро диагностировать проблемы и принимать меры для обеспечения непрерывности бизнеса.

Рисунок. Apigee API Monitoring предоставляет широкий спектр инструментов для мониторинга, анализа и устранения проблем. В нем используются лучшие в своем классе функции аналитики от Google Cloud Platform.

Apigee Sense

Apigee Sense помогает защитить API от нежелательного трафика запросов, в том числе от атак вредоносных клиентов. Apigee Sense анализирует трафик запросов API, выявляя шаблоны, которые могут представлять нежелательные запросы.

На основе этого анализа организации могут выявлять клиентов, отправляющих нежелательные запросы, а затем разрешать, блокировать или отмечать эти запросы. Apigee Sense позволяет защитить API от шаблонов запросов, которые включают:

  • Автоматизированное поведение, которое неотличимо от человеческого
  • Постоянные попытки с одного IP-адреса
  • Необычные коэффициенты ошибок
  • Подозрительные запросы клиентов
  • Сканирование данных
  • Сбор ключей
  • Всплески активности
  • Географические закономерности

API8:2019 Инъекции

Описание угрозы

Ненадежное внедрение данных, например SQL, NoSQL, XML-парсеров, ORM, LDAP, команд ОС и JavaScript, в запросы API может привести к выполнению непредусмотренных команд или несанкционированному доступу к данным. Злоумышленники будут передавать в API вредоносные данные через любые доступные векторы внедрения, такие как прямой ввод, параметры, интегрированные сервисы и т. д., ожидая, что они будут отправлены интерпретатору. Злоумышленники могут легко обнаружить эти недостатки, проанализировав исходный код с помощью сканеров уязвимостей и фаззеров. Успешная инъекция может привести к раскрытию информации, нарушению конфиденциальности и потере данных, а в некоторых случаях – к отказу в обслуживании.

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

Apigee Edge, выступая в качестве сервера для входящих запросов API, проверяет, чтобы структура полезной нагрузки находилась в допустимом диапазоне. Это также называется проверкой лимита. Вы можете настроить прокси API так, чтобы процедура проверки входных данных преобразовывала входные данные, удаляя опасные последовательности символов и заменяя их безопасными значениями.

Правило защиты на основе регулярных выражений

Правило RegularExpressionProtection извлекает информацию из сообщения (например, путь URI, параметр запроса, заголовок, параметр формы, переменную, полезную нагрузку XML или полезную нагрузку JSON) и оценивает этот контент на соответствие заданным регулярным выражениям. Если хотя бы одно из указанных регулярных выражений возвращает значение true, письмо считается угрозой и отклоняется. Регулярное выражение (regex) – это набор строк, которые задают шаблон в строке. Регулярные выражения позволяют программно оценивать контент на соответствие шаблонам. Регулярные выражения можно использовать, например, для проверки правильности структуры адреса электронной почты.

Чаще всего RegularExpressionProtection используется для проверки полезных нагрузок JSON и XML на наличие вредоносного контента.

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

На платформе Apigee доступны и другие способы проверки входных данных:

Проверка типов контента

Тип контента – это контент файла, который передается по протоколу HTTP и классифицируется по двухкомпонентной структуре. Apigee рекомендует проверять типы контента для запроса и ответа с помощью условной логики, как описано ниже.

API9:2019 Неправильное управление объектами

Описание угрозы

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

Эту угрозу можно устранить, используя возможности Apigee для управления полным жизненным циклом API. Это позволит вам создать комплексную модель управления, которая обеспечит совместную работу команд и в то же время разделит обязанности между специалистами по безопасности и разработчиками API. Границы и элементы управления можно настраивать и поддерживать с помощью:

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

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

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

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

Организации и среды

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

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

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

Версии Версии позволяют легко переносить API и отдельные функции между средами.

Управление доступом на основе ролей

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

Документация по управлению аудиториями для API

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

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

Крючки Flow

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

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

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

API10:2019 Недостаточное ведение журналов и мониторинг

Описание угрозы

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

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

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

Apigee предоставляет необходимые инструменты для создания комплексной стратегии управления событиями и ведения журналов. К ним относятся:

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

Google Cloud Operation Suite – используйте встроенную интеграцию с масштабируемыми инструментами мониторинга и ведения журналов от Google.

Правила в отношении выносок сервисов. Добавлена поддержка потоков журналов, для которых требуются конечные точки HTTP для отправки событий.

Аналитика: Получайте доступ к метаданным трафика и анализируйте их с помощью готовых и/или специальных отчетов. Создавайте оповещения на основе тенденций и выявляйте аномалии трафика.

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