Les API jouent un rôle de plus en plus important dans la façon dont les entreprises et les clients accèdent aux services, à la fois en interne et en externe. En interne, les API sont utilisées pour accéder aux applications métier, aux solutions maison et aux intégrations tierces. En externe, de plus en plus d’entreprises cherchent à être productives et à monétiser leurs API. Face à cette tendance, la Gestion des API devient un composant central d’une approche standard de gestion, de gouvernance et de publication des API, à la fois pour des publics internes et externes.
Avec l’aide d’Azure Application Gateway, il est désormais possible de protéger et de restreindre l’accès des API servies via la Gestion des API Azure. Cet article décrit une solution dans laquelle vous pouvez gérer les API internes et externes via une seule instance de Gestion des API. Vous pouvez maintenir une posture sécurisée contre l’exposition directe via Internet, mais l’accès s’effectue à la place via une passerelle applicative.
Notes
Cette architecture est utilisée comme base de l’accélérateur de zone d’atterrissage Gestion des API Azure dans le Cloud Adoption Framework.
Architecture
Dans ce diagramme architectural, une zone globale regroupe l’étendue d’un abonnement, une zone DNS privée où les domaines privés sont résolus et l’étendue d’un réseau virtuel nommé APIM-CS VNet. Au-dessus de l’abonnement se trouve une zone qui indique qu’il s’agit d’une charge de travail locale. La zone contient une icône désignant un serveur. Un canal indique une connexion de site à site ou Azure ExpressRoute vers l’instance Gestion des API dans l’abonnement Azure. Sept autres zones plus petites se trouvent à l’intérieur de la grande zone représentant l’abonnement Azure. Quatre zones sont sur la ligne du haut et trois sur la ligne du bas. Chaque zone individuelle représente un sous-réseau distinct, avec un groupe de sécurité réseau attaché. Dans la partie la plus à gauche, une adresse IP publique est attachée à Azure Application Gateway dans la zone la plus à gauche de la ligne du haut. Application Gateway réside également dans l’une des sept zones plus petites, avec le sous-réseau nommé App GW Subnet. À droite se trouve une autre zone qui contient l’instance Gestion des API, avec le sous-réseau nommé APIM Subnet. À côté se trouve la troisième zone de la ligne du haut, qui contient un point de terminaison privé pour l’instance Azure Functions dans le sous-réseau nommé PE Subnet. La zone la plus à droite de la ligne du haut est le sous-réseau back-end qui contient Azure Function Apps, le plan Azure App Service pour la fonction et le compte de stockage associé à l’application de fonction. Sur la ligne du bas, en partant de la gauche,une zone contient Azure Bastion dans le sous-réseau Bastion. La deuxième zone contient la machine virtuelle jumpbox de gestion dans le sous-réseau Jumpbox. La dernière zone de la ligne du bas est l’agent DevOps contenu dans le sous-réseau DevOps. En bas à droite de l’image se trouvent trois ressources partagées avec leurs icônes respectives. De gauche à droite, vous avez les zones suivantes : Key Vault, Application Insights et Espace de travail Log Analytics. Il existe deux ensembles de workflows. Le premier workflow est indiqué par des cercles noirs et le second par des cercles bleus. Des explications vous seront données dans les prochaines sections. Le workflow noir indique l’accès aux API disponibles en externe. Le flux part de l’utilisateur accédant à l’adresse IP publique. La flèche pointe ensuite vers la passerelle applicative. Une autre flèche va de la passerelle applicative au point de terminaison privé, et une autre du point de terminaison privé à l’application de fonction. Le workflow bleu part du serveur local. Une flèche pointe vers l’instance de Gestion des API et passe par une icône de pipeline en indiquant une connexion de site à site ou via ExpressRoute. Le reste du flux est identique à celui décrit ci-dessus : de la Gestion des API au point de terminaison privé, et du point de terminaison privé à Azure Functions.
Cette architecture part du principe que les stratégies sont en place à partir de l’accélérateur de zone d’atterrissage Azure et que la structure est tirée vers le bas à partir du groupe d’administration.
Téléchargez un fichier Visio de cette architecture.
Workflow
Scénario hybride (cercles bleus)
Ce scénario nécessite une connexion de site à site ou une connexion Azure ExpressRoute à votre environnement local.
- Une application locale nécessite l’accès à une API interne qui est servie via la Gestion des API Azure.
- La Gestion des API se connecte aux API back-end hébergées sur Azure Functions. Cette connexion est établie via un point de terminaison privé, disponible via le plan de Azure Functions Premium et hébergé dans son propre sous-réseau.
- Le point de terminaison privé accède de manière sécurisée à l’API interne hébergée sur Azure Functions.
Scénario d’accès externe (cercles noirs)
- Une application externe accède à une adresse IP publique ou à un nom de domaine complet personnalisé, qui est attaché à Azure Application Gateway.
- Application Gateway agit comme pare-feu d’applications web, ce qui nécessite des certificats PFX pour la terminaison SSL.
- La Gestion des API se connecte aux API back-end qui sont hébergées sur Azure Functions via un point de terminaison privé. Ce point de terminaison est disponible via le plan Azure Functions Premium et est hébergé dans son propre sous-réseau.
- Le point de terminaison privé accède de manière sécurisée à l’API disponible en externe hébergée sur Azure Functions.
Composants
L’architecture utilise les composants suivants :
Gestion des API Azure est un service managé qui vous permet de gérer des services dans des environnements hybrides et multiclouds. La Gestion des API fait office de façade pour obstruer l’architecture back-end, et fournit le contrôle et la sécurité nécessaires aux utilisateurs internes et externes pour observer et consommer des API.
Azure Functions est une solution serverless qui vous permet de vous concentrer davantage sur les blocs de code qui peuvent être exécutés avec une gestion d’infrastructure minimale. Les fonctions peuvent être hébergées dans différents plans d’hébergement, tandis que cette architecture de référence utilise le plan Premium en raison de l’utilisation de points de terminaison privés.
Azure Application Gateway est un service managé qui agit comme un équilibreur de charge de couche 7 et un pare-feu d’applications web. Dans ce scénario, la passerelle applicative protège l’instance APIM interne, ce qui vous permet d’utiliser les modes interne et externe.
Les zones DNS privées d’Azure DNS vous permettent de gérer et de résoudre les noms de domaine dans un réseau virtuel, sans qu’il soit nécessaire d’implémenter une solution DNS personnalisée. Une zone DNS privée peut être alignée sur un ou plusieurs réseaux virtuels via des liaisons de réseau virtuel. Azure Functions étant exposé sur un point de terminaison privé utilisé par cette architecture de référence, vous devez utiliser une zone DNS privée.
Application Insights d’Azure Monitor permet aux développeurs de détecter les anomalies, de diagnostiquer les problèmes et de comprendre les modèles d’utilisation. Application Insights offre une gestion et une supervision extensibles des performances des applications pour les applications web en production. Différentes plateformes sont prises en charge, y compris .NET, Node.js, Java et Python. Les applications hébergées dans Azure, localement, dans un environnement hybride ou dans d’autres clouds publics sont prises en charge. Application Insights est incluse dans cette architecture de référence pour superviser les comportements de l’application déployée.
Azure MonitorLog Analytics vous permet de modifier et d’exécuter des requêtes de journal avec des données dans les Journaux Azure Monitor, éventuellement à partir du portail Azure. Les développeurs peuvent exécuter des requêtes simples sur un ensemble d’enregistrements ou utiliser Log Analytics pour effectuer une analyse avancée. Ils peuvent ensuite visualiser les résultats. Log Analytics est configuré dans le cadre de cette architecture de référence pour agréger tous les journaux de monitoring à des fins d’analyse et de production de rapports.
Machines virtuelles Azure est une ressource informatique qui peut être utilisée pour héberger de nombreuses charges de travail différentes. Dans cette architecture de référence, les machines virtuelles sont utilisées pour fournir un serveur jumpbox de gestion ainsi qu’un hôte pour l’agent DevOps ou l’exécuteur GitHub.
Azure Key Vault est un service cloud qui stocke et accède de façon sécurisée à des secrets, qui peuvent aller de clés d’API et de mots de passe à des certificats et des clés de chiffrement. Cette architecture de référence utilise Azure Key Vault pour stocker les certificats SSL utilisés par la passerelle applicative.
Azure Bastion est une plateforme en tant que service (PaaS) provisionnée dans le réseau virtuel du développeur. Il fournit une connectivité RDP/SSH sécurisée aux machines virtuelles des développeurs sur TLS, à partir du portail Azure. Avec Azure Bastion, les machines virtuelles n’ont plus besoin d’une adresse IP publique pour se connecter via RDP/SSH. Cette architecture de référence utilise Azure Bastion pour accéder au serveur de l’agent DevOps ou de l’exécuteur GitHub, ou au serveur jumpbox de gestion.
Si vous utilisez un outil DevOps comme Azure DevOps ou GitHub, les agents hébergés dans le cloud ou les exécuteurs fonctionnent sur l’Internet public. Étant donné que la gestion des API dans cette architecture est définie sur un réseau interne, vous devez utiliser un agent DevOps ayant accès au réseau virtuel. L’agent DevOps vous aidera à déployer des stratégies et d’autres modifications sur les API dans votre architecture. Ces peuvent être utilisés pour désassembler le processus et permettre à vos équipes de développement de déployer des modifications par API. Ils sont exécutés par les exécuteurs DevOps.
Autres solutions
Pour les services back-end auxquels l’instance Gestion des API se connecte, plusieurs alternatives sont disponibles en plus d’Azure Functions qui est utilisé dans cette implémentation de référence :
- Azure App Service est un service HTTP complètement managé qui génère, déploie et met à l’échelle des applications web. .NET, .NET Core, Java, Ruby, Node.js, PHP et Python sont tous pris en charge. Les applications peuvent s’exécuter et effectuer un scale-in dans des environnements Windows ou Linux.
- Azure Kubernetes Service offre des clusters Kubernetes complètement managés intégrant sécurité, gouvernance et expérience CI/CD (intégration continue et livraison continue).
- Azure Logic Apps est une plateforme basée sur le cloud permettant de créer et d’exécuter des workflows automatisés. Vous trouverez un exemple d’architecture de référence dans Intégration d’entreprise de base sur Azure.
- Azure Container Apps vous permet d’exécuter des microservices et des applications conteneurisées sur une plateforme serverless.
Pour les déploiements multirégions, envisagez d’utiliser Azure Front Door pour fournir un accès rapide, fiable et sécurisé entre vos utilisateurs et le contenu web statique et dynamique de vos applications.
Pour obtenir des exemples supplémentaires de la façon dont Application Gateway peut protéger les API, consultez Protéger les API avec Application Gateway et Gestion des API.
Considérations
Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d'informations, consultez Microsoft Azure Well-Architected Framework.
Fiabilité
La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.
- Déployez au moins deux unités d’échelle de Gestion des API réparties sur deux zones de disponibilité, par région. Cette méthode optimise la disponibilité et les performances.
- Le peering de réseaux virtuels offre d’excellentes performances dans une région, mais a une scalabilité maximale de 500 réseaux. Si vous devez connecter davantage de charges de travail, utilisez une conception hub-and-spoke ou Azure Virtual WAN.
Sécurité
La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.
- Les stratégies de validation de Gestion des API sont disponibles pour valider les demandes et les réponses d’API par rapport à un schéma OpenAPI. Ces fonctionnalités ne remplacent pas un pare-feu d’applications web, mais elles peuvent fournir une protection supplémentaire contre certaines menaces. L’ajout de stratégies de validation peut avoir des répercussions sur les performances. Nous vous recommandons donc de réaliser des tests de charge de performances pour évaluer leur impact sur le débit de l’API.
- Déployez un pare-feu d’applications web (WAF) Azure devant Gestion des API pour fournir une protection contre les attaques et vulnérabilités courantes des applications web.
- Appliquez des valeurs nommées avec des secrets Key Vault pour protéger les informations sensibles dans les stratégies APIM.
- Utilisez Application Gateway pour l’accès externe à une instance APIM interne afin de protéger l’instance APIM et d’activer la connectivité hybride.
- Déployez la passerelle Gestion des API dans un réseau virtuel pour prendre en charge une connectivité hybride et une sécurité accrue.
- Le peering de réseaux virtuels offre d’excellentes performances dans une région, mais a une scalabilité maximale de 500 réseaux. Si vous devez connecter davantage de charges de travail, utilisez une conception hub-and-spoke ou Azure Virtual WAN.
Optimisation des coûts
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 Vue d’ensemble du pilier d’optimisation des coûts.
- Les zones de disponibilité et les réseaux virtuels devant être pris en charge, nous avons sélectionné le niveau Premium de Gestion des API, en respectant les tarifs de chaque région. De plus, dans cette charge de travail, Azure Functions est hébergé sur le plan Premium en raison de l’accès obligatoire au réseau virtuel.
- Pour obtenir une preuve de concept ou des prototypes, nous vous recommandons d’utiliser d’autres niveaux de Gestion des API (comme Développeur ou Standard).
Excellence opérationnelle
L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.
- Les configurations de Gestion des API doivent être représentées sous la forme de modèles ARM et vous devez privilégier l’infrastructure en tant que code dans vos démarches.
- Utilisez un processus CI/CD pour gérer, versionner et mettre à jour les configurations de Gestion des API.
- Créez des sondes d’intégrité personnalisées pour valider l’état de votre instance de Gestion des API. Utilisez l’URL
/status-0123456789abcdefpour créer un point de terminaison d’intégrité commun pour le service APIM dans la passerelle d’application. - Les certificats mis à jour dans le coffre de clés sont automatiquement permutés dans Gestion des API, qui est mis à jour dans les 4 heures.
- Déployez au moins deux unités d’échelle de Gestion des API réparties sur deux zones de disponibilité, par région. Cette méthode optimise la disponibilité et les performances.
Déployer ce scénario
Cette architecture est disponible sur GitHub. Elle contient tous les fichiers d’infrastructure en tant que code nécessaires ainsi que les instructions de déploiement.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteurs principaux :
- Pete Messina | Architecte de solution cloud senior
- Anthony Nevico | Architecte de solution cloud senior
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
- Cette même architecture est utilisée comme base de l’accélérateur de zone d’atterrissage Gestion des API Azure dans le Cloud Adoption Framework.
- CI/CD pour la gestion des API à l’aide de modèles de Azure Resource Manager
- Introduction à Gestion des API
- Gérer des API avec APIM
- Ressources Gestion des API pour bien démarrer
Consultez les ressources clés suivantes :
- Accélérateur de zone d’atterrissage Azure
- Opérations d’API
- Documentation Gestion des API Azure
- Concepts clés de Gestion des API Azure
- Documentation Application Gateway
- Accélérateur de zone d’atterrissage pour le service Gestion des API Azure
Pour en savoir plus sur ces services clés, consultez :
- Vue d’ensemble des fonctions Azure
- Zones Azure DNS privé
- Vue d’ensemble d’Azure Application Insights
- Vue d’ensemble d’Azure Log Analytics
- Présentation des machines virtuelles Azure
- Concepts d’Azure Key Vault
- Vue d’ensemble d’Azure Bastion