Обеспечьте безопасность развертывания Azure API Management

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

В этой статье приведены рекомендации по безопасности, которые помогут защитить ваше развертывание Azure API Management.

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

Безопасность для конкретной службы

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

  • Проверяйте запросы и ответы API на шлюзе: применяйте политики validate-content и validate-parameters для принудительной проверки схем тела запроса, пути, строки запроса и заголовков до того, как запросы будут переданы в бэкенды, а политики validate-headers и validate-status-code — для проверки ответов от бэкендов, прежде чем они будут возвращены клиентам. Для получения дополнительной информации смотрите раздел Политики валидации контента.
  • Минимизация распространённых угроз API: Настройте политики, рекомендованные для OWASP API Security Top 10, чтобы защитить опубликованные API от инъекции, чрезмерного распространения данных и других атак, специфичных для API. Для получения дополнительной информации см. раздел «Смягчить угрозы безопасности API OWASP».
  • Применяйте ограничения частоты запросов и квоты для защиты бэкенда: Используйте политику rate-limit-by-key для ограничения запросов от злоупотребляющих клиентов и политику quota-by-key для применения возобновляемых или пожизненных квот на количество вызовов, защищая внутренние службы от скачков трафика и атак типа «отказ в обслуживании». Для получения дополнительной информации см. раздел «Политика ограничения тарифов и квот».
  • Не полагайтесь на ключи подписки как на механизм аутентификации: ключ подписки указывает на подписку управления API, а не на пользователя или приложение, и подвержен распространению или утечке. Аутентифицируйте звонящих с помощью OAuth 2.0 или клиентских сертификатов, а подписочные ключи рассматривайте только как грубый контроль доступа. Для получения дополнительной информации см. раздел «Аутентификация и авторизация для API».

Сетевая безопасность

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

  • Ограничьте входящий доступ с помощью приватной конечной точки: настройте входящую частную конечную точку так, чтобы клиенты в вашей виртуальной сети достигали шлюза через Приватный канал Azure, а не через публичный IP-адрес. Для получения дополнительной информации см. Как подключиться к управлению API через входящую частную конечную точку.
  • Отключить доступ к публичной сети: Когда вы подключаете клиентов через приватную конечную точку, отключите доступ к публичной сети, чтобы шлюз принимал трафик только с одобренных приватных соединений. Для получения дополнительной информации см. Как подключиться к управлению API через входящую частную конечную точку.
  • Изолировать шлюз в виртуальной сети: использовать поддерживаемую модель виртуальной сети для управления подключением к бэкендам и другим ресурсам Azure: инъекция виртуальной сети для Premium v2 или классических экземпляров Developer и Premium, или интеграция виртуальной сети для исходящего доступа на уровнях Standard v2 и Premium v2. Дополнительные сведения см. в статье "Использование виртуальной сети с помощью управления API".
  • Контролировать исходящую связь с помощью интеграции виртуальной сети: в уровнях Standard v2 и Premium v2 интегрируйте шлюз с виртуальной сетью, чтобы вызовы в бэкенды проходили через вашу сеть и соблюдали правила сетевой безопасности и межсетевого экрана. Для получения дополнительной информации см . раздел «Интеграция экземпляра уровня v2 с виртуальной сетью для исходящей связи».
  • Разместите перед шлюзом межсетевой экран веб-приложений: разместите Шлюз приложений Azure с Брандмауэр веб-приложений перед внутренним экземпляром API Management для проверки и фильтрации входящего трафика, прежде чем он достигнет шлюза. Дополнительные сведения см. в разделе Интеграции управления API в внутренней виртуальной сети с шлюзом приложений.
  • Фильтруйте клиентский трафик по IP-адресу: используйте ip-filter политику для разрешения или отклонения вызовов с определённых IP-адресов или диапазонов на уровне API или операции. Для получения дополнительной информации см. политику ip-фильтрации.
  • Включите защиту от DDoS для экземпляров, внедрённых в виртуальную сеть: для классических экземпляров Developer или Premium, внедрённых в виртуальную сеть во внешнем режиме, включите Azure DDoS Protection для виртуальной сети, чтобы защитить открытые конечные точки шлюза от объёмных атак. Во внутреннем режиме защита от DDoS охватывает только управляющую конечную точку порта 3443. Для получения дополнительной информации см. раздел «Защита управления API от DDoS-атак».
  • Защитите серверные ресурсы с помощью периметра сетевой безопасности: разместите API Management перед ресурсом Azure, защищённым периметром сетевой безопасности, и настройте аутентификацию к нему с помощью управляемого удостоверения шлюза, чтобы серверная часть запрещала публичный доступ. Для получения дополнительной информации см. Front — ресурс, защищённый сетевым периметром с управлением API.

TLS и HTTPS

API Management поддерживает версии TLS до TLS 1.3 как для клиентских, так и для бэкенд-соединений, при этом TLS 1.2 по умолчанию включён. Ограничить шлюз надёжными протоколами и обеспечить доверие на основе сертификатов, где это уместно.

  • Отключите устаревшие протоколы TLS и слабые шифры: отключите TLS 1.0, TLS 1.1, SSL 3.0 и слабые наборы шифров на настраиваемых клиентских и бэкенд-настройках, чтобы шлюз согласовал только сильную транспортную безопасность. Уровни Consumption, Basic v2, Standard v2 и Premium v2 не поддерживают изменения стандартной конфигурации шифра, а управляемые шлюзы рабочего пространства не поддерживают изменения стандартного протокола или конфигурации шифра. Для получения дополнительной информации см. раздел «Управление протоколами и шифрами в управлении API».
  • Требовать аутентификацию по клиентскому сертификату (взаимная TLS-аутентификация): Требовать и проверять клиентские сертификаты на шлюзе для аутентификации вызывающих приложений, а также проверять свойства сертификатов с помощью политики validate-client-certificate. Для получения дополнительной информации см . раздел «Безопасные API с использованием аутентификации клиентских сертификатов».
  • Аутентификация на бэкенды с клиентскими сертификатами: Представьте управляемый клиентский сертификат от шлюза к серверным сервисам, чтобы бэкенд принимал вызовы только от API Management. Для получения дополнительной информации см . раздел «Безопасные бэкенд-сервисы с использованием аутентификации клиентских сертификатов».

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

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

  • Авторизуйте доступ к API с помощью OAuth 2.0 и Microsoft Entra ID: проверяйте токены JWT на шлюзе с помощью политики validate-jwt или validate-azure-ad-token, чтобы только вызывающие клиенты с действительными токенами могли получать доступ к вашим серверным службам. Для получения дополнительной информации см. раздел «Аутентификация и авторизация для API».
    • Защитите бэкенд-API с помощью Microsoft Entra ID: Настройте авторизацию бэкенд-API так, чтобы шлюз получал и передавал действительные токены на бэкенд. Для получения дополнительной информации см. раздел «Защитить сервер API с Microsoft Entra ID».
  • Назначайте встроенные роли RBAC по принципу наименьших привилегий в плоскости управления: предоставляйте каждому оператору минимально необходимую роль, соответствующую его обязанностям, а не широкие права владельца. Используйте API Management Service Reader для доступа только для чтения, API Management Service Operator для управления сервисом, но не его сущностями, и резервируйте API Management Service Contributor для полных администраторов; используйте роли API Management workspace и API Management Developer Portal Content Editor для задач с ограниченным обхватом. Для получения дополнительной информации см . Использование ролевого контроля доступа в управлении API.
  • Включите управляемую идентичность для экземпляра: Настройте управляемую идентичность, назначенную системой или пользователем так, чтобы шлюз аутентифицировался в Key Vault, бэкенды и другие ресурсы Azure без сохранения учетных данных. Для получения дополнительной информации см. раздел «Использование управляемых идентичностей в управлении API».
  • Безопасное управление ключами подписки: регулярно генерируйте ключи подписки, требуйте подписочный ключ на API, где он необходим, и вращайте первичные и вторичные ключи отдельно, чтобы избежать простоя. Для получения дополнительной информации см. раздел «Подписки в управлении API».
    • Ограничьте встроенную подписку с полным доступом: ограничите подписку полного доступа авторизованными администраторами и никогда не встраивайте ключ в клиентские приложения, так как он предоставляет доступ ко всем API в экземпляре. Для получения дополнительной информации см. раздел «Создать подписки в управлении API».
  • Ограничить доступ к порталу разработчиков: Контролируйте, кто может входить и просматривать контент в портале, а также отключайте анонимный доступ к продуктам и API, которые не должны быть публичными. Для получения дополнительной информации смотрите раздел «Безопасный доступ к порталу разработчиков».
  • Обеспечение условного доступа для администраторов управления API: применить политики условного доступа, требующие многофакторной аутентификации и совместимых устройств для идентификаторов, способных управлять сервисом управления API, его политиками и именными значениями, связанным Key Vault и виртуальными сетевыми ресурсами, от которых зависит шлюз. Для получения дополнительной информации см. раздел «Требуется MFA для управления Azure».

Защита данных

Управление API хранит секреты, учетные данные бэкенда и сертификаты TLS. Храните их в управляемом секретном магазине и ссылайтесь на них, а не встраивайте их в правила.

  • Храните секреты в Azure Key Vault как именованные значения: Ссылайтесь на безверсионные идентификаторы секрета Key Vault из именованных значений вместо встраивания учетных данных в определения политик, чтобы API Management получало ротированные секреты, и они никогда не появлялись в конфигурации. Интеграция Key Vault для именованных значений в настоящее время недоступна в рабочих пространствах. Дополнительные сведения см. в разделе "Использование именованных значений" в политиках управления API.
  • Получить секреты и сертификаты Key Vault с управляемой идентификацией: Предоставьте управляемому идентификатору шлюза доступ к Key Vault, чтобы он читал секреты и сертификаты без сохранения учетных данных. Для получения дополнительной информации см. раздел «Использование управляемых идентичностей в управлении API».
  • Храните пользовательские доменные TLS-сертификаты в Key Vault: используйте сертификаты Key Vault для вашего домена, установите автопродление сертификата и используйте уровень с поддержкой SLA, чтобы API Management автоматически воспринимал последнюю версию сертификата без простоев. Для получения дополнительной информации см. раздел «Настроить пользовательское доменное имя для вашего экземпляра управления API».

Ведение журналов и мониторинг

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

  • Собирайте журналы ресурсов шлюза с помощью параметров диагностики: в уровнях, поддерживающих журналы ресурсов, отправляйте журналы ресурсов API Management, включая журналы запросов шлюза, в рабочую область Log Analytics, концентратор событий или учетную запись хранения для хранения и анализа. Уровень потребления не поддерживает сбор журналов ресурсов. Дополнительные сведения см. в разделе "Мониторинг управления API".
  • Отслеживайте метрики и настраивайте оповещения: отслеживайте пропускную способность шлюза, а также метрики запросов и ошибок в Azure Monitor и оповещайте об аномалиях, которые могут указывать на злоупотребления или сбои. Уровни v2 и шлюзы рабочего пространства отражают метрики использования процессора и памяти вместо классической метрики ёмкости шлюза. Для получения дополнительной информации см. раздел Monitor API Management с Azure Monitor.
  • Отслеживание запросов с помощью Application Insights: Интегрируйте Application Insights для захвата сквозной телеметрии запросов и диагностики подозрительных паттернов вызовов. Для получения дополнительной информации см. раздел «Интеграция управления API с аналитикой приложений».
  • Передача журналов и событий в Event Hubs для SIEM: Для API, не относящихся к рабочей области, используйте политику log-to-eventhub для пересылки запросов и пользовательских событий в концентратор событий для приема системой управления событиями и информацией безопасности. Дополнительные сведения см. в разделе Регистрация событий в Центры событий Azure.
  • Включите обнаружение угроз в Defender for APIs: Подключите REST API экземпляра к Microsoft Defender for APIs, чтобы выявлять угрозы во время работы и получать рекомендации, например удалить неиспользуемые конечные точки и защитить неаутентифицированные конечные точки. Дополнительные сведения см. в разделе Защита API с Defender for APIs.

Соответствие требованиям и управление

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

  • Обеспечение конфигурации с помощью Политика Azure: Назначьте встроенные определения политики управления API для контролей, таких как требование развертывания виртуальной сети, ограничение доступа к публичным конфигурациям к конечным точкам, требование зашифрованных протоколов, проверка сертификатов бэкенда и поддержка именных значений с помощью Key Vault. Для получения дополнительной информации см. раздел «Встроенные определения политики для управления API».
  • Пересмотрите облачную безопасность с помощью Defender для облака: следуйте рекомендациям по управлению API в Microsoft Defender для облака, таких как интеграция REST API в Defender для API и удаление неаутентифицированных или неиспользуемых конечных точек. Для получения дополнительной информации смотрите рекомендации по безопасности API и управления API.
  • Примените блокировки ресурсов к экземпляру: Добавьте блокировку на удаление для рабочих экземпляров API Management, чтобы предотвратить случайное удаление шлюза и его конфигурации. Для получения дополнительной информации смотрите ресурсы блокировки для предотвращения изменений.
  • Ресурсы управления API-тегами для управления: применяйте теги ресурсов к экземплярам, чтобы отслеживать владение, окружение и чувствительность данных по всему вашему API-массиву. Дополнительные сведения см. в статье Использование тегов для организации ресурсов в Azure.

Резервное копирование и восстановление

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

Связанные материалы

  • Последнее обновление: