Partage via

Protéger les API avec Application Gateway et Gestion des API

Gestion des API Azure
Application Gateway Azure

Les organisations adoptent de plus en plus des approches de conception API-first tout en faisant face à des menaces croissantes pour les applications web. Vous avez besoin d’une stratégie de sécurité complète pour protéger les API, en particulier lorsque vous exposez des API basées sur l’IA et implémentez des principes d’architecture de confiance zéro. Le modèle de routage de passerelle fournit une approche de la sécurité des API en protégeant le trafic réseau. La passerelle limite les emplacements sources du trafic et la qualité du trafic tout en prenant en charge des règles de routage flexibles. Cet article explique comment utiliser Azure Application Gateway et Gestion des API Azure pour protéger l’accès aux API.

Architecture

Cet article ne traite pas des plateformes sous-jacentes de l’application, telles que App Service Environment, Azure SQL Managed Instance et Azure Kubernetes Service. Ces parties du diagramme présentent ce que vous pouvez implémenter en tant que solution plus large. Cet article traite spécifiquement des zones grisées, Gestion des API et Application Gateway.

Diagramme montrant comment Application Gateway et Gestion des API protègent les API.

Téléchargez un fichier Visio de cette architecture.

Workflow

  1. Application Gateway reçoit les requêtes HTTPS que le groupe de sécurité réseau (NSG) du sous-réseau autorise.

  2. Le pare-feu d’applications web (WAF) sur Application Gateway vérifie la demande par rapport aux règles WAF, y compris les règles personnalisées Geomatch. La demande continue si elle est valide.

  3. Application Gateway sets up a URL proxy mechanism that sends the request to the proper backend pool. Par exemple, selon le format d’URL de l’appel d’API :

    • Les URL mises en forme comme api.<some-domain>/external/* peuvent atteindre le back-end pour interagir avec les API demandées.
    • Les appels mis en forme comme api.<some-domain>/* aller à un dead end (sinkpool), qui est un pool principal sans cible.
    • Une règle de routage au niveau d’Application Gateway redirige les utilisateurs vers portal.<some-domain>/* le portail des développeurs. Les développeurs peuvent gérer les API et leurs configurations à partir d’environnements internes et externes. Vous pouvez également bloquer complètement le portail des développeurs.

  4. Application Gateway accepte et proxies les appels internes à partir de ressources dans le même réseau virtuel Azure sous api.<some-domain>/internal/*.

  5. Au niveau gestion des API, les API acceptent les appels sous les modèles suivants :

    • api.<some-domain>/external/*
    • api.<some-domain>/internal/*

    Dans ce scénario, Gestion des API utilise deux types d’adresses IP : publiques et privées. Les adresses IP publiques sont destinées aux opérations de gestion sur le port 3443 pour le plan de gestion et pour le trafic d’API d’exécution dans la configuration du réseau virtuel externe. Quand Gestion des API envoie une demande à serveur principal accessible via l’Internet public, il affiche une adresse IP publique comme origine de la demande. Pour plus d’informations, consultez Adresses IP du service Gestion des API dans un réseau virtuel.

Components

  • Le réseau virtuel Azure permet à de nombreux types de ressources Azure de communiquer en privé entre elles, internet et réseaux locaux. Dans cette architecture, Application Gateway tunnelise le trafic Internet public dans ce réseau privé.

  • Azure Application Gateway est un équilibreur de charge de trafic web qui gère le trafic vers des applications web. Ce type de routage est connu comme l’équilibrage de charge de la couche d’application (couche OSI 7). Dans cette architecture, la passerelle fournit un routage et héberge un pare-feu d’applications web (WAF) pour se protéger contre les vecteurs d’attaque web courants.

  • Gestion des API Azure est une plateforme de gestion multicloud hybride pour les API dans tous les environnements. Gestion des API crée des passerelles d’API modernes et cohérentes pour les services principaux. Dans cette architecture, Gestion des API fonctionne en mode entièrement privé pour décharger les préoccupations croisées du code et des hôtes d’API.

Recommendations

Cette solution se concentre sur l’implémentation de l’ensemble de la solution et le test de l’accès aux API à partir de l’intérieur et à l’extérieur du réseau virtuel Gestion des API. Pour plus d’informations sur le processus d’intégration de réseau virtuel Gestion des API, consultez Déployer gestion des API dans un réseau virtuel interne avec Application Gateway.

Pour communiquer avec des ressources privées dans le serveur principal, Application Gateway et Gestion des API doivent se trouver dans le même réseau virtuel que les ressources ou dans un réseau virtuel appairé.

  • Le modèle de déploiement privé interne permet à Gestion des API de se connecter à un réseau virtuel existant, ce qui le rend accessible à partir de ce contexte de réseau. To enable this feature, deploy either the Developer or Premium API Management tiers for classic virtual network injection. For newer virtual network options, use Standard v2 or Premium v2 tiers with virtual network integration or injection capabilities.

  • Si vos clients existent dans un autre abonnement ou sont gérés avec un autre répertoire d’ID Entra, utilisez Application Gateway Private Link pour fournir une connectivité privée à Application Gateway à partir de réseaux virtuels clients entre abonnements et régions.

  • Gérer les certificats Application Gateway dans Azure Key Vault.

  • To personalize interactions with the services, you can use CNAME entries.

Alternatives

Vous pouvez utiliser d’autres services pour fournir un niveau similaire de protection pare-feu et pare-feu d’applications web (WAF) :

Considerations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, qui est un ensemble d’ensembles guidants qui peuvent être utilisés pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Reliability

La fiabilité garantit que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d’informations, consultez liste de vérification de la révision de conception pour lede fiabilité.

Azure Application Gateway est toujours déployé de manière hautement disponible, quel que soit le nombre d’instances. Pour éviter l’impact d’un dysfonctionnement de zone, vous pouvez configurer Application Gateway pour couvrir plusieurs zones de disponibilité. Pour plus d’informations, consultez Mise à l’échelle automatique et haute disponibilité.

Activez la redondance de zone pour vos composants de service Gestion des API afin de fournir une résilience et une haute disponibilité. La redondance de zone réplique la passerelle de Gestion des API et le plan de contrôle dans des centres de données situés dans des zones séparées physiquement, ce qui les rend résilients en cas de défaillance d’une zone. The API Management Premium tier is required to support Availability zones.

Gestion des API prend également en charge les déploiements multirégions, ce qui peut améliorer la disponibilité si une région est hors connexion. For more information, see Multi-region deployment. Dans cette topologie, il est important d’avoir une passerelle Application Gateway par région, car Application Gateway est un service régional.

Security

La sécurité offre des garanties contre les attaques délibérées et l’abus de vos données et systèmes précieux. Pour plus d’informations, consultez liste de vérification de la révision de conception pour security.

Pour plus d’informations sur la sécurité d’Application Gateway, consultez Base de référence de sécurité Azure pour Application Gateway.

Pour plus d’informations sur la sécurité de Gestion des API, consultez Base de référence sur la sécurité Azure pour la Gestion des API.

Implémentez toujours ces mesures de sécurité :

  • Utilisez des stratégies WAF (Web Application Firewall) Azure avec la dernière version OWASP Core Rule Set (CRS) 3.2 ou ultérieure pour vous protéger contre les vulnérabilités web courantes, y compris les 10 principales menaces OWASP.

  • Configurez des règles personnalisées waf pour bloquer ou autoriser le trafic en fonction de l’emplacement géographique. Cette approche offre une protection contre les attaques par déni de service distribué (DDoS).

  • Activez la protection DDoS d’Application (Couche 7) à l’aide d’Azure WAF avec Application Gateway pour vous protéger contre les attaques volumetrices et basées sur le protocole. Azure DDoS Protection, combiné à des pratiques de conception d’application, fournit des fonctionnalités d’atténuation DDoS améliorées pour fournir une meilleure défense contre les attaques DDoS.

  • Use private endpoints for API Management to provide secure inbound connectivity.

  • Permettre à Microsoft Defender pour les API de surveiller la posture de sécurité des API et de détecter les menaces.

  • Configurez les règles de protection des bots WAF pour identifier et bloquer les bots malveillants.

Cost Optimization

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’optimisation des coûts.

Le coût de cette architecture dépend des aspects de configuration tels que :

  • Service tiers. Considérez les niveaux Standard v2 et Premium v2 pour gestion des API, qui offrent une amélioration de l’efficacité et des performances.
  • Scalabilité, c’est-à-dire le nombre d’instances allouées dynamiquement par les services pour prendre en charge une demande donnée
  • Que cette architecture s’exécute en continu ou seulement quelques heures par mois
  • Coûts de transfert de données entre régions si vous utilisez des déploiements multirégions
  • Coûts de traitement WAF en fonction du nombre de requêtes et de règles évaluées

Tenez compte de ces stratégies d’optimisation des coûts :

Après avoir évalué ces aspects, utilisez la calculatrice de prix Azure pour estimer la tarification.

Operational Excellence

L’excellence opérationnelle couvre les processus opérationnels qui déploient une application et la maintiennent en production. Pour plus d’informations, consultez la Liste de contrôle de l'examen de la conception pour l'excellence opérationnelle.

Implémentez une surveillance et une observabilité complètes :

Performance Efficiency

L’efficacité des performances est la capacité de votre charge de travail à répondre aux demandes qu’elle impose aux utilisateurs de manière efficace. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’efficacité des performances.

Application Gateway est le point d’entrée de cette architecture, et la fonctionnalité WAF nécessite une puissance de traitement pour chaque analyse de requête. Pour permettre à Application Gateway d’étendre sa capacité de calcul à la demande, activez la mise à l’échelle automatique. Pour plus d’informations, consultez Mise à l’échelle automatique et redondance de zone dans Application Gateway. Suivez les recommandations de la documentation produit pour la configuration de l’infrastructure Application Gateway, y compris le dimensionnement approprié du sous-réseau. Cette approche garantit que le sous-réseau est suffisamment grand pour prendre en charge le scale-out complet.

Pour Gestion des API, tenez compte de ces optimisations de performances :

Next steps

Concevez vos API en suivant de bonnes conception d’API web instructions et implémentez-les à l’aide de bonnes pratiques d’implémentation d’API web .