Реализация защиты сети и защиты от угроз API

Завершено

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

Фильтрация запросов по IP-адресу

Политика ip-filter разрешает или блокирует запросы на основе исходного IP-адреса вызывающего абонента или диапазона бесклассовой междоменной маршрутизации (CIDR). Он оценивает запрос во время входящей обработки перед любой маршрутизацией или перенаправлением на серверную часть.

Используйте список разрешений, когда партнеры Contoso Retail подключаются из известных фиксированных диапазонов IP-адресов:

<inbound>
  <ip-filter action="allow">
    <address>203.0.113.0/24</address>
    <address>198.51.100.5</address>
  </ip-filter>
  <base />
</inbound>

С помощью action="allow"управления API принимаются запросы только из перечисленных адресов и диапазонов CIDR и отклоняются все остальные запросы с ответом 403 Forbidden . При этом action="deny"запросы из перечисленных адресов блокируются, а все остальные исходные IP-адреса разрешены.

Для продукта Contoso Retail для партнеров разрешающий список диапазонов исходящих IP-адресов партнеров ограничивает доступ к входящей конечной точке шлюза — даже пользователям с действительным ключом подписки будет отказано в доступе, если их исходный IP-адрес отсутствует в списке.

Замечание

Политика ip-filter оценивает IP-адрес так, как это воспринимается системой управления API. Если вызывающие серверы обращаются к шлюзу через прокси-сервер или шлюз NAT, управление API видит IP-адрес прокси-сервера, а не IP-адрес исходного клиента. Учитывайте это при определении списка разрешений— добавьте исходящий диапазон IP-адресов прокси-сервера, а не отдельные внутренние адреса клиента.

Применение ограничения пропускной способности и управления квотами

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

Политика rate-limit ограничивает вызовы для каждой подписки в течение короткого периода времени:

<inbound>
  <rate-limit calls="100" renewal-period="60" />
  <base />
</inbound>

В этом примере допускается 100 вызовов в течение 60 секунд на подписку. Когда вызывающий объект превышает ограничение, система управления API возвращает 429 Too Many Requests. Счетчик сбрасывается автоматически в конце каждого периода продления. Примените эту политику в области продукта, чтобы обеспечить согласованные ограничения для всех подписчиков в продукте.

Применяемая политика rate-limit-by-key ограничивает скорость при помощи пользовательского ключа счетчика — это может быть любое выражение, которое оценивается в строку, идентифицирующую вызывающий объект.

<inbound>
  <rate-limit-by-key calls="30"
                     renewal-period="60"
                     counter-key="@(context.Request.IpAddress)" />
  <base />
</inbound>

Используйте rate-limit-by-key, когда вызывающие стороны не используют ключи подписки, или когда вы хотите применить дополнительное ограничение на основе IP-адреса, независимо от идентификатора подписки. Вы можете извлечь ключ счетчика из утверждения JSON Web Token (JWT), значения заголовка или любого другого атрибута запроса, доступного через контекст выражения политики.

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

<inbound>
  <quota calls="10000" bandwidth="40960" renewal-period="2592000" />
  <base />
</inbound>

В этом примере каждая подписка ограничивает 10 000 вызовов или 40 МБ передаваемых данных за 30-дневный период (2 592 000 секунд). Когда квота исчерпана, вызывающие получают 403 Forbidden ответ до продления периода.

Различие между rate-limit и quota отражает два разных риска потребления.

• rate-limit предотвращает злоупотребление спайками — внезапное увеличение запросов к API за короткий промежуток времени.
• quota применяет ограничения по использованию ресурсами по договору, гарантируя, что подписчик не превышает месячные объемные лимиты.

Для Contoso Retail применяется rate-limit в области продукта для защиты серверных систем от пиков трафика и quota в той же области, чтобы применить ежемесячные лимиты на подписку, которые соответствуют уровням контрактов партнера.

Интеграция управления API с Azure Virtual Network

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

Управление API поддерживает два режима интеграции виртуальной сети:

Внешний режим развертывает управление API в подсети виртуальной сети при сохранении общедоступного IP-адреса. Шлюз принимает запросы из Интернета и также может взаимодействовать с внутренними ресурсами виртуальной сети, такими как интерфейсы API серверной части, работающие на виртуальных машинах, средах службы приложений или Служба Azure Kubernetes кластерах. Используйте режим External, когда партнерам необходимо подключаться к API через Интернет, но ваши бэкэнд сервисы должны оставаться приватными в VNet, недоступными напрямую извне виртуальной сети.

Внутренний режим развертывает управление API полностью внутри виртуальной сети без общедоступной конечной точки. Уровень шлюза и управления доступен только из виртуальной сети или из подключенных локальных сетей через VPN или Azure ExpressRoute. Общедоступный IP-адрес не предоставляется. Используйте внутренний режим, если и вызывающие абоненты, и серверные службы находятся в частных сетях и доступ к шлюзу через Интернет никогда не требуется. Внутренний режим обеспечивает самую сильную сетевую изоляцию двух вариантов.

Это важно

Возможности виртуальной сети зависят от уровня. Внедрение виртуальной сети (полная изоляция — без общедоступного IP-адреса на шлюзе) доступно только на уровнях Разработчик, Премиум (классический), и Премиум v2. Стандартная версия 2 поддерживает только интеграцию виртуальной сети (исходящее подключение только к частным серверным службам; конечная точка шлюза остается общедоступной из Интернета). Частные конечные точки (входящая изоляция без полной интеграции виртуальной сети) доступны для уровня Разработчика, Базовый, Стандартный, Стандартный версии 2, Премиум и Премиум версии 2. Выберите уровень, соответствующий требованиям к изоляции перед развертыванием, — изменение уровней после первоначального развертывания не является простой операцией.

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

Для Contoso Retail правильная модель зависит от того, кто использует API:

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

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