10 основных угроз API OWASP

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

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

Введение

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

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

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

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

  • Определите, какие клиентские приложения будут использовать ваши API (SPA, мобильные или браузерные), и разработайте соответствующие шаблоны аутентификации, авторизации и безопасности.
  • Всегда используйте потоки 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. Следующим шагом является определение вместе с вашей командой по идентификации шаблонов интеграции, которые будут реализованы с вашим решением по идентификации.

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

Политики аутентификации

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

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

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

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

Управление

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

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

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

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

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

Общие потоки

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

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

Отчеты о безопасности

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

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

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

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

Апигейное чувство

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

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

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

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

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

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

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

  • Общие оповещения о дорожном движении . Вызывает оповещение, когда трафик изменяется на указанный процент в течение диапазона времени. Например, вы можете подать оповещение, когда трафик увеличится на 5 % или более в течение одного часа или уменьшится на 10 % или более в течение одной недели.
  • Оповещения об аномалиях . Edge обнаруживает проблемы с трафиком и производительностью вместо того, чтобы вам приходилось определять их самостоятельно. Затем вы можете поднять оповещение об этих аномалиях.
  • Оповещения об истечении срока действия TLS . Вызывает уведомление, когда срок действия сертификата TLS близок к истечению.

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

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

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

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

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

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

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

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

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

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

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

  • Назначить сообщение
  • Выноски кода
  • Обработка ошибок

Назначить политику сообщений

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

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

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

Сложный рерайтинг с кастомным кодом

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

С помощью процедурного кода вы можете:

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

Apigee Edge включает отдельную политику для поддерживаемых языков: политику JavaScript , политику Java Callout и политику Python Script .

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

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

Общие потоки

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

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

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

Не реализуя политики ограничения скорости, злоумышленники могут перегрузить серверную часть атаками типа «отказ в обслуживании».

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

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

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

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

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

Спайк Арест

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

Квоты

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

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

Эта политика более детальна, чем арест Спайка, и обычно ее следует использовать одновременно с ней.

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

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

Обнаружение угроз с помощью расширенного мониторинга операций API

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

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

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

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

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

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

  • Что защищается? Подумайте о своей стратегии продукта API и реализуйте логическую сегментацию функциональности при использовании лучших практик RESTful для проектирования путей и ресурсов, предоставляемых прокси-серверами Apigee API, функциями продуктов и приложений.
  • Кто имеет доступ к вашим ресурсам 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 Массовое назначение

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

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

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

Обычно существует два аспекта, допускающих этот тип угрозы:

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

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

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

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

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

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

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

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

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

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

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

  • Неправильно настроен TLS
  • Сообщения об ошибках с трассировкой стека
  • Непропатченные системы
  • Открытое хранилище или панели управления сервером

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

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

Общие потоки и перехватчики потоков

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

Отчеты о безопасности API

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

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

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

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

Мониторинг API

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

Рисунок: Мониторинг API API API предоставляет широкий спектр инструментов для мониторинга, расследования и действия по вопросам. Он лучше всего использует в функциях интеллекта класса с Google Cloud Platform.

Апигей смысл

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

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

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

API8: 2019 Инъекция

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

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

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

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

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

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

Наиболее распространенным использованием regularexpressionProtection является оценка полезных нагрузок JSON и XML для вредоносного контента.

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

Есть несколько других подходов к проверке ввода, доступных с платформой Apigee:

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

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

API Security Reporting

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Потоковые крючки

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

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

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

Отчеты о безопасности

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

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

Трафик времени выполнения : универсальный представление для APIS-проницательности на: целевые серверы, виртуальные хосты, конфигурация TLS, изменения трафика на среду и многое другое.

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

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

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

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

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

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

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

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

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

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

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

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

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