Modèle de déchargement de passerelle

Déchargez des fonctionnalités de service partagé ou spécialisé sur un proxy de passerelle. Cette approche simplifie le développement d’applications en centralisant les préoccupations croisées, telles que l’arrêt de certificat TLS côté client, dans la passerelle au lieu de les dupliquer entre les services.

Lorsque plusieurs services partagent des responsabilités telles que l’authentification, la surveillance ou la traduction de protocole, la consolidation de ces préoccupations dans une passerelle unique réduit la surcharge de configuration par service et le risque de déploiement.

Contexte et problème

Certaines fonctionnalités sont couramment utilisées dans plusieurs services et elles doivent être configurées, gérées et maintenues. Un service partagé ou spécialisé que vous distribuez avec chaque déploiement d’application ajoute une surcharge administrative et augmente la probabilité d’erreur de déploiement. Vous devez déployer toutes les mises à jour d’une fonctionnalité partagée sur tous les services qui partagent cette fonctionnalité.

Les problèmes de sécurité tels que la validation de jeton, le chiffrement et la gestion des certificats TLS peuvent nécessiter que les membres de l’équipe aient des compétences hautement spécialisées. Par exemple, sans passerelle, vous devrez peut-être configurer et déployer un certificat côté client sur chaque instance d’application. Vous devez suivre son expiration et sa mise à jour, le tester et le vérifier dans ces instances.

D’autres services courants comme l’authentification, l’autorisation, la journalisation, la surveillance ou la limitation peuvent être difficiles à implémenter et à gérer dans un grand nombre de déploiements. La consolidation de ce type de fonctionnalité réduit la surcharge et le risque d’erreurs.

Solution

Déchargez certaines fonctionnalités dans une passerelle. La passerelle prend ensuite en charge des préoccupations transversales telles que la gestion des certificats côté client, l’authentification, la terminaison TLS, la supervision, la traduction de protocoles et la limitation du débit pour le compte des services back-end.

Le diagramme suivant montre une passerelle qui met fin aux connexions TLS entrantes et applique des fonctionnalités partagées. La passerelle valide le certificat principal et chiffre à nouveau le trafic via une connexion TLS distincte au service principal.

Diagramme d’un client se connectant à une passerelle via TLS.

Ce modèle présente les avantages suivants :

  • Simplifiez le développement des services en centralisant la configuration partagée, telle que l’authentification, la limitation et la journalisation des demandes, au lieu de l’implémenter dans chaque service principal. La centralisation améliore la cohérence et rend les mises à niveau de service plus simples.

  • Offrez aux équipes dédiées la possibilité d’implémenter des fonctionnalités qui nécessitent une expertise particulière telle que la sécurité. Votre équipe principale peut ensuite se concentrer sur les fonctionnalités de l’application, en laissant ces préoccupations spécialisées mais croisées aux experts pertinents.

  • Offrez une certaine cohérence pour la surveillance et la journalisation des requêtes et des réponses. Même si un service n’est pas correctement instrumenté, la passerelle peut fournir un niveau de référence de supervision et de journalisation.

  • Centraliser la gestion du trafic sensible au carbone. Une passerelle peut ajuster la mise en cache, la limitation de débit et les comportements de journalisation en fonction des signaux d’intensité carbone en temps réel. Gestion des API Azure fournit ces fonctionnalités en préversion limitée, dans certaines régions et niveaux classiques (Développeur, De base, Standard et Premium). Pour plus d’informations sur la disponibilité et la configuration, consultez les API écologiquement durables dans Gestion des API Azure.

Problèmes et considérations

Prenez en compte les points suivants lorsque vous choisissez comment implémenter ce modèle :

  • Haute disponibilité et résilience. Vérifiez que la passerelle est hautement disponible et résiliente en cas de défaillance. Évitez les points de défaillance uniques en exécutant plusieurs instances de votre passerelle. Étant donné que la passerelle termine les connexions client et peut mettre en mémoire tampon les corps de requête, tenez compte de la façon dont les requêtes en cours sont gérées en cas de défaillance d’une instance. Utilisez des mécanismes de drainage de connexion ou d’arrêt appropriés afin que la suppression ou le redémarrage d’une instance de passerelle ne supprime pas les sessions actives.

  • Capacité et mise à l’échelle. Assurez-vous que la passerelle est conçue pour répondre aux besoins en termes de capacité et de mise à l’échelle de votre application et de vos points de terminaison. Assurez-vous que la passerelle ne devient pas un goulot d’étranglement pour l’application et qu’elle est suffisamment évolutive. La passerelle doit être provisionnée pour absorber les pics soudains de trafic, et non seulement la charge moyenne. Le sous-approvisionnement de la passerelle afin de réduire les coûts dégrade directement les performances de chaque service derrière celui-ci.

  • Portée de l'étendue. Décharger les fonctionnalités partagées par plusieurs services ou itinéraires lors de leur centralisation réduit l’implémentation et la gestion dupliquées.

  • Séparation de la logique métier. Ne déchargez jamais la logique métier vers la passerelle.

  • Suivi des transactions. Si vous avez besoin de suivre des transactions, envisagez de générer des ID de corrélation à des fins de journalisation.

  • Surcoût de latence. La passerelle ajoute un saut réseau à chaque requête. Chaque fonction prise en charge par la passerelle, comme la terminaison TLS, l’authentification ou l’inspection des requêtes, allonge le temps de traitement sur le cheminement de la requête. Le regroupement de connexions de passerelle et la conservation des connexions aux services principaux peuvent partiellement compenser le coût de latence en réutilisant les connexions plutôt que d’en établir de nouvelles pour chaque requête. Déterminez si la latence combinée du tronçon de passerelle et les fonctions déchargées sont acceptables pour les objectifs de performances de la charge de travail.

  • Complexité opérationnelle. Une passerelle centralisée consolide la gestion, mais concentre également la responsabilité opérationnelle. Vous devez gérer la configuration de la passerelle, le cycle de vie des certificats, les mises à jour de stratégie et les mises à niveau de version en tant que préoccupation partagée. Assurez-vous que l’équipe responsable de la passerelle dispose de la capacité et des outils pour la gérer à l’échelle de tous les services qui en dépendent.

  • Implications en matière de sécurité. La passerelle est une cible à valeur élevée, car elle centralise les fonctions de sécurité croisées telles que l’authentification, l’arrêt TLS et l’inspection des demandes. Une compromission de la passerelle peut exposer tous les services en aval. Renforcez la passerelle, limitez sa surface de gestion et surveillez-la pour un comportement anormal indépendamment des services principaux qu’elle protège.

  • Prévention du contournement de la passerelle. Configurez les services principaux pour accepter les demandes uniquement via le chemin d’accès de passerelle prévu. Sinon, les clients peuvent se connecter directement à un backend et contourner l’authentification, la limitation du débit, l’inspection des requêtes et la journalisation au niveau de la passerelle.

  • Propagation de l’identité. Définissez si chaque back-end autorise l’appelant initial, l’identité de charge de travail de la passerelle, ou les deux. Conservez les jetons de l’appelant ou les revendications fiables uniquement lorsque le back-end nécessite un contexte utilisateur délégué. Authentifiez toujours séparément la passerelle auprès du backend. Ne considérez pas les en-têtes retransmis non vérifiés comme une preuve d’identité.

  • Maintenance de TLS. Si la passerelle met fin au protocole TLS, rétablissez le protocole TLS sur le serveur principal. Ne transférez pas le trafic via HTTP non chiffré. Traitez tous les réseaux comme non approuvés. Cette topologie nécessite toujours un processus pour émettre, faire pivoter et révoquer des certificats back-end.

  • En-têtes transférés et contexte client. Lorsque la passerelle met fin aux connexions clientes et établit de nouvelles connexions aux services principaux, des informations telles que l’adresse IP du client, le protocole d’origine et le nom d’hôte sont perdues, sauf si la passerelle la transfère explicitement. Pour connaître les stratégies d’atténuation, consultez Conserver le nom d’hôte HTTP d’origine entre un proxy inverse et son application web back-end.

Quand utiliser ce modèle

Utilisez ce modèle dans les situations suivantes :

  • Un déploiement d’application a une préoccupation partagée, comme les certificats TLS ou le chiffrement.
  • Une fonctionnalité courante dans les déploiements d’applications peut avoir différentes exigences en matière de ressources, telles que les ressources mémoire, la capacité de stockage ou les connexions réseau.
  • Vous souhaitez déplacer la responsabilité des problèmes tels que la sécurité réseau, la limitation ou d’autres problèmes de limite réseau vers une équipe plus spécialisée.

Ce modèle peut ne pas convenir lorsque :

  • La passerelle doit contenir des règles de logique ou de routage spécifiques au service qui couplent étroitement les modifications apportées aux modifications de configuration de la passerelle. Le couplage du niveau de passerelle avec des services internes signifie que les mises à jour principales peuvent forcer le redéploiement de la passerelle, ce qui réduit l’indépendance du déploiement.
  • La tâche déportée est légère et la charge de travail est sensible à la latence. Le tronçon réseau supplémentaire via la passerelle peut ne pas être justifié lorsque la surcharge dépasse l’avantage de la centralisation.
  • La centralisation des problématiques au sein d’une passerelle partagée crée un goulot d’étranglement dans la gestion des changements. Si le cycle de publication de l’équipe de passerelle est plus lent que celui des équipes de service, l’externalisation peut retarder les mises à jour des certificats, des stratégies d’authentification ou des règles réseau.

Conception de la charge de travail

Un architecte doit évaluer la façon dont le modèle de déchargement de passerelle peut être utilisé dans la conception de leurs charges de travail pour se conformer aux objectifs et principes abordés dans les piliers d’Azure Well-Architected Framework. Par exemple:

Pilier Comment ce modèle soutient les objectifs des piliers.
Les décisions de conception de fiabilité aident votre charge de travail à devenir résiliente au dysfonctionnement et à s’assurer qu’elle se rétablit dans un état entièrement opérationnel après une défaillance. Décharger cette responsabilité sur une passerelle réduit la complexité du code d’application sur les nœuds principaux. Dans certains cas, le transfert remplace complètement la fonctionnalité par une fonction fiable fournie par la plateforme.

- RE :01 Simplicité et efficacité
Les décisions relatives à la conception de la sécurité permettent de garantir la confidentialité, l’intégrité et la disponibilité des données et des systèmes de votre charge de travail. L’ajout d’une passerelle dans le flux de requête vous permet de centraliser les contrôles tels que les pare-feu d’applications web et les stratégies TLS clientes. Toutes les fonctionnalités déchargées fournies par la plateforme offrent déjà une sécurité renforcée.

- Se :06 Contrôles de réseau
- SE :08 Ressources de renforcement
L’optimisation des coûts se concentre sur le maintien et l’amélioration du retour sur investissement de votre charge de travail. Ce modèle permet de réorienter les coûts des ressources qui seraient dépensées par nœud vers la mise en œuvre de la passerelle. Dans le modèle de traitement centralisé, les coûts sont souvent inférieurs à ceux du modèle distribué.

- CO :14 Consolidation
L’excellence opérationnelle permet de fournir une qualité de charge de travail grâce à des processus standardisés et à la cohésion de l’équipe. Dans ce modèle, la configuration et l’entretien des fonctionnalités déchargées sont associées à un point unique au lieu d’exiger la gestion à partir de plusieurs nœuds. Cette centralisation normalise la façon dont les préoccupations croisées sont appliquées, en apportant des changements opérationnels réguliers et ad hoc cohérents et prévisibles.

- Oe :02 Normaliser les opérations
L’efficacité des performances permet à votre charge de travail de répondre efficacement aux demandes par le biais d’optimisations de la mise à l’échelle, des données et du code. L’ajout d’une passerelle de déchargement au processus de requête vous permet d’utiliser moins de ressources par nœud, car la fonctionnalité est centralisée sur la passerelle. Vous pouvez optimiser l’implémentation de la fonctionnalité déchargée indépendamment du code d’application. Les fonctionnalités fournies par la plateforme et externalisées sont déjà très performantes.

- PE :03 Sélection de services

Si ce modèle introduit des compromis au sein d’un pilier, considérez-les contre les objectifs des autres piliers.

Exemple

Azure Application Gateway WAF_v2 pouvez implémenter ce modèle pour une application web régionale. La passerelle met fin aux connexions TLS clientes, applique les stratégies waf et de routage et établit de nouvelles connexions TLS aux services principaux. Cette conception conserve les problèmes de traitement des demandes partagés hors du code de l’application back-end.

Application Gateway avec déchargement TLS

Le diagramme suivant montre comment Application Gateway met fin aux connexions TLS entrantes, inspecte et filtre le trafic et le chiffre à nouveau avant de le transférer vers un pool principal via TLS.

Diagramme montrant Application Gateway terminant les connexions TLS entrantes des clients, appliquant des règles WAF et de routage, puis rechiffrant le trafic via TLS vers un pool de serveurs principaux.

Cette architecture utilise les composants Application Gateway suivants pour décharger les fonctionnalités partagées et rechiffrer le trafic principal :

  • Écouteur HTTPS. Un écouteur HTTPS sur le port 443 accepte les connexions TLS entrantes des clients.
  • Certificat TLS. Un certificat PFX, source de Azure Key Vault, est attaché à l’écouteur HTTPS. Application Gateway déchiffre le trafic entrant pour l’inspecter et l’acheminer, puis le rechiffre avant de l’envoyer au pool de back-ends. Les serveurs principaux ont toujours besoin de certificats pour les connexions rechiffrés, mais dans de nombreux cas, les certificats gérés par la plateforme peuvent être utilisés.
  • Pool de backend. Un pool principal définit l’ensemble de serveurs HTTPS qui reçoivent le trafic rechiffré. Les cibles principales peuvent être des machines virtuelles, des Groupes de machines virtuelles identiques Azure, des adresses IP ou des instances Azure App Service. Limitez l’accès back-end afin que les clients ne puissent pas contourner Application Gateway et sa stratégie WAF en vous connectant directement.
  • Paramètres HTTP principaux. Définissez le protocole du serveur principal sur HTTPS et le port sur le port TLS du serveur principal, tel que 443. Configurez l’approbation de certificat et un nom d’hôte qui correspond au certificat principal. Pour une autorité de certification privée, configurez le certificat racine approuvé. Pour plus d’informations, consultez TLS de bout en bout avec la référence SKU v2.
  • Règle de routage. Une règle de routage des requêtes associe l’écouteur au pool principal et aux paramètres HTTP principaux. Les règles basées sur des chemins d’accès peuvent router différents chemins d’URL vers différents pools principaux.
  • Stratégie WAF. La stratégie définit les règles managées et personnalisées utilisées pour inspecter les requêtes, y compris les règles Geomatch.

Étant donné que Application Gateway déchiffre le trafic, il peut inspecter le contenu de la demande pour le routage intelligent, réécrire les en-têtes HTTP et les URL, et appliquer des règles WAF. Il chiffre ensuite à nouveau le trafic avant de transférer des demandes vers le back-end.

Pour obtenir des conseils de configuration, consultez le chiffrement TLS de bout en bout avec Application Gateway.

Technologies de prise en charge

Les services Azure suivants peuvent vous aider à implémenter ce modèle :

Étapes suivantes

  • Last updated on