Modèle de gardien

Protégez les applications et les services à l’aide d’un composant dédié servant d’intermédiaire pour les requêtes entre les clients et l’application ou le service. Le répartiteur valide et nettoie les demandes et peut fournir une couche supplémentaire de sécurité et limiter la surface d’attaque du système.

Contexte et problème

De nombreux services cloud exposent des points de terminaison qui permettent aux applications clientes d’appeler leurs API sur Internet ou sur un autre réseau non approuvé. Le code qui implémente les API déclenche ou effectue plusieurs tâches, notamment l’authentification, l’autorisation, la validation des paramètres et tout ou partie du traitement des demandes. Le code d’API est susceptible d’accéder au stockage et à d’autres services au nom du client.

Si un utilisateur malveillant compromet le système et accède à l’environnement d’hébergement de l’application, ses mécanismes de sécurité, ainsi que l’accès aux données et à d’autres services sont exposés. Par conséquent, l’utilisateur malveillant peut accéder sans restrictions aux informations d’identification, aux clés de stockage, à des informations sensibles et à d’autres services.

Solution

Une solution à ce problème consiste à dissocier le code qui implémente des points de terminaison publics à partir du code qui traite les demandes et accède au stockage. Dissociez le code à l’aide d’un niveau de façade qui interagit avec les clients et route les demandes approuvées via un point de terminaison interne, une file d’attente ou un répartiteur vers les composants de charge de travail qui gèrent l’opération métier. Le diagramme fournit une vue d’ensemble générale de ce modèle.

Vous pouvez utiliser le modèle Gatekeeper pour protéger le stockage, ou vous pouvez l’utiliser comme façade plus complète pour protéger toutes les fonctions de l’application. Les facteurs importants sont les suivants :

Validation contrôlée : Le gatekeeper valide toutes les demandes et rejette les demandes qui ne répondent pas aux exigences de validation.
Risque limité et exposition : Les risques et l’exposition sont réduits, car le gardien de contrôle n’accède pas aux informations d’identification ou aux clés utilisées par l’hôte approuvé pour accéder au stockage et aux services. Si le gardien de contrôle devient compromis, les attaquants ne peuvent pas accéder à ces informations d’identification ou clés.
Sécurité appropriée : Le gardien de contrôle s’exécute en mode privilège limité, tandis que le reste de l’application s’exécute en mode confiance totale nécessaire pour accéder au stockage et aux services. Si le gardien est compromis, il ne peut pas accéder directement aux services ou aux données de l’application.

Ce modèle agit comme un pare-feu dans une topographie réseau standard. Contrairement à un pare-feu traditionnel, il permet au gardien de contrôle d’examiner en détail les demandes et de prendre une décision basée sur l’application concernant la transmission de la demande à l’hôte approuvé qui effectue les tâches requises. Cette décision exige généralement que le gardien de contrôle valide et désinfecte le contenu de la demande avant de le transmettre à l’hôte approuvé. Les gardiens de contrôle peuvent autoriser la requête, rechercher du contenu de charge utile inattendu ou non valide, effectuer une limitation du débit et effectuer différentes autres vérifications.

Problèmes et considérations

Tenez compte des points suivants lorsque vous décidez comment implémenter ce modèle :

Assurez-vous que les hôtes approuvés exposent uniquement les points de terminaison internes ou protégés que seul le gardien de contrôle utilise. Les hôtes approuvés ne doivent pas exposer des interfaces ou des points de terminaison externes.
Le gatekeeper doit s’exécuter avec des privilèges limités. Dans la pratique, hébergez le serveur principal de contrôle et le back-end approuvé sur des limites de calcul distinctes et conservez les points de terminaison principaux privés.
Le gardien de contrôle ne doit pas effectuer de traitement lié à l’application ou aux services ou aux données d’accès. Sa fonction consiste uniquement à valider et à nettoyer les demandes. Les hôtes approuvés peuvent avoir besoin d’effectuer une validation de requête supplémentaire, mais le gardien de contrôle doit effectuer la validation principale.
Utilisez un canal de communication sécurisé tel que HTTPS, SSL (Secure Sockets Layer) ou TLS (Transport Layer Security) entre le gardien de contrôle et les hôtes ou tâches approuvés, le cas échéant. Toutefois, certains environnements d’hébergement ne prennent pas en charge HTTPS sur les points de terminaison internes.
L’ajout de la couche supplémentaire pour implémenter le modèle Gatekeeper est susceptible d’affecter les performances en raison du traitement supplémentaire et de la communication réseau requise.
Le gatekeeper peut constituer un point unique de défaillance (SPoF). Pour réduire l’impact d’une défaillance, envisagez de déployer des instances redondantes et d’utiliser un mécanisme de mise à l’échelle automatique pour garantir la capacité et maintenir la disponibilité.

Quand utiliser ce modèle

Utilisez ce modèle dans les situations suivantes :

Vous gérez les informations sensibles.
Vous exposez des services qui nécessitent une protection forte contre le trafic malveillant.
Vous effectuez des opérations stratégiques qui ne peuvent pas tolérer une exposition directe des services back-end.
Vous avez besoin de la validation et de l’assainissement des demandes pour être séparés du traitement métier de base.

Ce modèle peut ne pas convenir lorsque :

Vous pouvez satisfaire aux exigences de sécurité et de validation par le biais de contrôles de plateforme intégrés sur le service back-end sans ajouter de niveau gatekeeper dédié.
Les tronçons réseau ajoutés et la latence de validation ne respectent pas les exigences strictes en matière de latence de bout en bout.

Conception de la charge de travail

Évaluez comment utiliser le modèle Gatekeeper dans la conception d'une charge de travail pour répondre aux objectifs et principes abordés dans les piliers Azure Well-Architected Framework. Le tableau suivant fournit des conseils sur la façon dont ce modèle prend en charge les objectifs de chaque pilier.

Pilier	Comment ce modèle soutient les objectifs des piliers.
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.	Un gardien dans le flux de requêtes vous aide à centraliser les fonctionnalités de sécurité telles que les pare-feu d’applications web, la protection DDoS, la détection de bot, la manipulation des demandes, l’initiation d’authentification et les vérifications d’autorisation. - Se :06 Contrôles de réseau - SE :10 Surveillance et détection des menaces
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.	Vous pouvez utiliser ce modèle pour implémenter la limitation au niveau du gardien de contrôle plutôt que d’implémenter des vérifications de débit au niveau du nœud. La coordination de l’état de débit entre tous les nœuds n’est pas intrinsèquement performante. - PE :03 Sélectionner des services

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

Example

Le modèle Gatekeeper implémente généralement un chemin de requête en couches, où chaque couche a une responsabilité spécifique et une étendue d’approbation limitée.

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

Dans cette conception, Azure Application Gateway avec Azure Web Application Firewall est le gardien externe. Il inspecte le trafic accessible sur Internet et applique des contrôles de sécurité avant que le trafic atteigne le niveau API. Gestion des API Azure est le gardien interne. Il applique des contrôles spécifiques à l’API et transfère uniquement le trafic approuvé aux back-ends privés.

Par exemple, Azure Web Application Firewall pouvez détecter et bloquer les modèles d’injection SQL et de script intersites, appliquer des règles de taille de protocole et de taille de requête et appliquer un filtrage basé sur un bot et une adresse IP avant que les requêtes atteignent la gestion des API ou les back-ends privés.

Lorsque vous utilisez Gestion des API dans la couche interne, elle applique des stratégies aux requêtes entrantes et aux réponses sortantes dans le pipeline de passerelle. Pour plus d’informations sur la façon dont gestion des API traite les demandes et les réponses, consultez Stratégies dans Gestion des API. Pour les options de stratégie telles que la validation de jeton Web JSON (JWT), la limitation du débit, la transformation des en-têtes et la mise en forme des réponses, consultez la documentation de référence des stratégies d’API Management.

Utilisez systématiquement les identités managées pour les ressources Azure pour l’authentification entre services dans ce parcours. Par exemple, API Management peut utiliser la stratégie d’authentification avec une identité managée pour obtenir des jetons Microsoft Entra pour les appels au back-end sans stocker de secrets.

La partie serveur reste privée. Par exemple, le serveur principal peut être une application Azure App Service qui utilise un point de terminaison private, afin que l’application soit accessible en privé.

Pour les charges de travail conteneurisées, une alternative peut remplacer la gestion des API et le chemin interne App Service par le calcul ingressé :

Azure Kubernetes Service (AKS), ce qui vous donne plus de contrôle sur le choix du contrôleur d’entrée, les stratégies Kubernetes, la topologie de réseau et les opérations de cluster.
Azure Container Apps, une plateforme serverless de conteneurs managée qui fournit des fonctionnalités d’entrée et réduit les besoins de gestion de l’infrastructure.

Dans ces alternatives, l’ingress peut router le trafic en fonction de l’hôte ou du chemin, assurer la terminaison TLS et exposer des services accessibles uniquement en interne. Des fonctionnalités spécifiques telles que les limites de requête et les règles d’autorisation ou de refus dépendent de l’implémentation d’entrée sélectionnée. Dans tous les cas, maintenez le périmètre du gatekeeper : appliquez la validation et l’application des politiques au point d’entrée, et veillez à ce que les services de back-end ne soient accessibles qu’au travers de ce point de passage contrôlé.

Chaque couche de ce parcours génère des journaux et des métriques que vous devez centraliser. Les journaux de diagnostic d’Azure Web Application Firewall enregistrent, pour chaque requête, les règles mises en correspondance et bloquées. API Management émet des journaux de passerelle qui consignent la durée des requêtes, les codes de réponse et les résultats des stratégies. Les services principaux émettent des données de télémétrie au niveau de l’application. Collectez ces journaux et métriques dans Azure Monitor et routez-les vers un espace de travail Log Analytics pour l’interrogation unifiée. Normaliser la corrélation des demandes de bout en bout en générant ou en transférant un ID de corrélation à la périphérie et en la propageant via gestion des API et les services principaux (par exemple, par le biais d’en-têtes de requête et de contexte de trace distribué) afin qu’une transaction unique reste traceable sur toutes les couches. Utilisez Microsoft Defender for Cloud pour exposer les recommandations de sécurité sur les composants gatekeeper. Configurez des alertes en cas de taux de blocage anormaux d’Azure Web Application Firewall ou de pics d’erreurs d’API Management afin de détecter les menaces avant qu’elles n’atteignent des back-ends privés.

Étapes suivantes

Les conseils suivants peuvent être pertinents lorsque vous implémentez ce modèle :

Les modèles de conception cloud suivants sont souvent utilisés avec le modèle Gatekeeper :

Commentaires

Est-ce que cette page vous a été utile?

Last updated on 2026-06-03