Благодаря большему количеству рабочих нагрузок, которые соответствуют подходу API-первого подхода, а также растущему числу угроз и серьезности угроз веб-приложениям через Интернет, важно иметь стратегию безопасности для защиты API. Одним из этапов обеспечения безопасности API является защита сетевого трафика с помощью шаблона маршрутизации шлюза. Шлюз используется для ограничения расположения источника трафика и качества трафика в дополнение к поддержке гибких правил маршрутизации. В этой статье описывается, как использовать Шлюз приложений Azure и Azure Управление API для защиты доступа к API.
Архитектура
В этой статье не рассматриваются базовые службы приложения, такие как Среда службы приложений, Управляемый экземпляр SQL Azure и Служба Azure Kubernetes. Эти части схемы демонстрируют только то, что можно сделать в качестве более широкого решения. В этой статье рассматриваются затененных областей, Управление API и Шлюз приложений.
Скачайте файл Visio для этой архитектуры.
Workflow
Шлюз приложений получает HTTP-запросы, разрешенные группой безопасности сети (NSG).
Брандмауэр веб-приложений (WAF) на Шлюз приложений затем проверка запрос к правилам WAF, включая фильтрацию geomatch. Если запрос действителен, запрос выполняется.
Шлюз приложений настраивает механизм прокси-сервера URL-адреса, который отправляет запрос в соответствующий внутренний пул. Например, в зависимости от формата URL-адреса вызова API:
URL-адреса, отформатированные как
api.<some-domain>/external/*можно получить доступ к внутреннему интерфейсу для взаимодействия с запрошенными API.Вызовы, отформатированные как
api.<some-domain>/*переход к взаимодоставке (sinkpool), который является внутренним пулом без целевого объекта.
Кроме того, Шлюз приложений принимает внутренние вызовы и прокси-серверы, поступающие из ресурсов в той же виртуальной сети Azure.
api.<some-domain>/internal/*Наконец, на уровне Управление API API настраиваются для приема вызовов в следующих шаблонах:
api.<some-domain>/external/*api.<some-domain>/internal/*
В этом сценарии Управление API использует два типа IP-адресов, общедоступных и частных. Общедоступные IP-адреса предназначены для внутреннего взаимодействия через порт 3443 и для трафика API среды выполнения в конфигурации внешней виртуальной сети. Когда Управление API отправляет запрос в общедоступную серверную часть интернета, он отображает общедоступный IP-адрес в качестве источника запроса. Дополнительные сведения см. в разделе IP-адресов службы Управление API в виртуальной сети.
Правило маршрутизации на уровне Шлюз приложений правильно перенаправляет пользователей на
portal.<some-domain>/*портал разработчиков, чтобы разработчики могли управлять API и их конфигурацией как из внутренних, так и из внешних сред.
Компоненты
Azure виртуальная сеть позволяет многим типам ресурсов Azure приватно взаимодействовать друг с другом, Интернетом и локальными сетями.
Шлюз приложений Azure — это подсистема балансировки нагрузки веб-трафика, которая управляет трафиком в веб-приложения. Этот тип маршрутизации называется балансировкой нагрузки на уровне приложения (уровень 7 OSI). Он размещает Брандмауэр веб-приложений (WAF) для защиты от распространенных векторов атак на основе веб-сайтов.
Azure Управление API — это гибридная платформа управления несколькими облаками для API во всех средах. Управление API создает согласованные современные шлюзы API для существующих внутренних служб.
Рекомендации
Это решение ориентировано на реализацию всего решения и тестирование доступа API изнутри и за пределами виртуальной сети Управление API. Дополнительные сведения о процессе интеграции Управление API виртуальной сети см. в статье "Интеграция Управление API в внутренней виртуальной сети с Шлюз приложений".
Чтобы взаимодействовать с частными ресурсами в серверной части, Шлюз приложений и Управление API должны находиться в той же виртуальной сети, что и ресурсы или в одноранговой виртуальной сети.
Частная внутренняя модель развертывания позволяет Управление API подключаться к существующей виртуальной сети, что делает ее доступной изнутри этого сетевого контекста. Чтобы включить эту функцию, разверните уровни "Разработчик" или "Премиум" Управление API.
Управление сертификатами и паролями в Azure Key Vault.
Для персонализации взаимодействия со службами можно использовать записи CNAME.
Альтернативные варианты
Вы можете использовать другие службы для обеспечения аналогичного уровня защиты брандмауэра и Брандмауэр веб-приложений (WAF):
- Azure Front Door
- Брандмауэр Azure
- Партнерские решения, такие как Barracuda
- Другие решения, доступные в Azure Marketplace
Рекомендации
Надежность
Шлюз приложений Azure всегда развертывается в высокодоступном режиме, независимо от количества экземпляров. Чтобы избежать влияния неисправности зоны, можно настроить Шлюз приложений для нескольких Зоны доступности. Дополнительные сведения см. в разделе "Автомасштабирование" и "Высокий уровень доступности".
Включите избыточность зоны для компонентов службы Управление API, чтобы обеспечить устойчивость и высокий уровень доступности. Избыточность зон реплика управляет шлюзом Управление API и уровнем управления в центрах обработки данных в физически разделенных зонах, что делает их устойчивыми к сбою зоны. Для поддержки зон доступности требуется уровень Управление API Premium.
Управление API также поддерживает развертывания с несколькими регионами, что может повысить доступность, если один регион переходит в автономный режим. Дополнительные сведения см. в разделе "Развертывание в нескольких регионах". В этой топологии важно также иметь один Шлюз приложений в каждом регионе, так как Шлюз приложений является региональной службой.
Безопасность
Дополнительные сведения о безопасности Шлюз приложений см. в базовом плане безопасности Azure для Шлюз приложений.
Дополнительные сведения о безопасности Управление API см. в разделе "Базовые показатели безопасности Azure" для Управление API.
Защита от атак DDoS Azure в сочетании с рекомендациями по проектированию приложений предоставляет расширенные функции защиты от атак DDoS. Необходимо включить защиту от атак DDOS Azure в любой виртуальной сети периметра.
Оптимизация затрат
Стоимость этой архитектуры зависит от таких аспектов конфигурации, как:
- Уровни службы
- Масштабируемость, то есть количество экземпляров динамически выделяется службами для поддержки заданного спроса.
- Будет ли эта архитектура работать непрерывно или всего несколько часов в месяц
После оценки этих аспектов перейдите к калькулятору цен Azure, чтобы оценить цены.
Оптимизация производительности
Шлюз приложений — это точка входа для этой архитектуры, а функция WAF требует дополнительных вычислительных мощностей для каждого анализа запросов. Чтобы разрешить Шлюз приложений расширить вычислительные мощности на месте, важно включить автомасштабирование. Дополнительные сведения см. в разделе "Указание автомасштабирования". Следуйте рекомендациям по документации по продуктам о размере подсети для Шлюз приложений. Это гарантирует, что подсеть достаточно велика для поддержки полного масштабирования.
Чтобы поддерживать высоко одновременные сценарии, включите автоматическое масштабирование Управление API. Автомасштабирование расширяет возможности Управление API в ответ на растущее число входящих запросов. Дополнительные сведения см. в статье Автоматическое масштабирование экземпляра службы управления API Azure.
Развертывание этого сценария
Этот сценарий демонстрируется в публикации коллекции быстрого запуска Azure Шлюз приложений с внутренним Управление API и веб-приложением.
Следующие шаги
Разработайте API, следуя рекомендациям по проектированию веб-API, и реализуйте их с помощью хороших методик реализации веб-API.