Protégez des applications et des services en tirant parti d’une instance d’hôte dédiée pour répartir des requêtes entre des clients et l’application ou le service. Le répartiteur valide et nettoie les requêtes, peut fournir une couche de sécurité supplémentaire et limiter la surface d’attaque du système.
Contexte et problème
Les services cloud exposent des points de terminaison qui permettent aux applications clientes d’appeler leurs API. Le code utilisé pour implémenter les API déclenche ou effectue plusieurs tâches, notamment (sans s’y limiter) l’authentification, l’autorisation, la validation des paramètres et tout ou partie du traitement des requêtes. 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 des requêtes et accède au stockage. Vous pouvez obtenir un découplage en utilisant une façade ou une tâche dédiée qui interagit avec des clients, puis transmet la requête (éventuellement via une interface découplée) aux hôtes ou aux tâches qui traitent la requête. La figure fournit une vue d’ensemble globale de ce modèle.
Vous pouvez utiliser le modèle d’opérateur de contrôle pour protéger un stockage, ou il peut être utilisé en tant que façade plus complète pour protéger toutes les fonctions de l’application. Les facteurs importants sont les suivants :
- Validation contrôlée. L’opérateur de contrôle valide toutes les requêtes et rejette celles qui ne respectent pas les exigences de validation.
- Risque et exposition limités. L’opérateur de contrôle n’a pas accès aux informations d’identification ni aux clés utilisées par l’hôte approuvé pour accéder au stockage et aux services. Si l’opérateur de contrôle est compromis, l’attaquant n’a pas accès à ces informations d’identification ni aux clés.
- Sécurité appropriée. L’opérateur de contrôle s’exécute dans un mode à privilèges limités, tandis que le reste de l’application s’exécute en mode de sécurité totale, nécessaire pour accéder au stockage et aux services. Si l’opérateur de contrôle est compromis, il ne peut pas accéder directement aux données ni aux services de l’application.
Ce modèle agit comme un pare-feu dans une topographie réseau standard. Il permet à l’opérateur de contrôle d’examiner les requêtes et de prendre une décision sur la transmission de la requête à l’hôte approuvé qui effectue les tâches requises. Cette décision exige généralement de l’opérateur de contrôle qu’il valide et assainisse le contenu de la requête avant de la transmettre à l’hôte approuvé.
Problèmes et considérations
Prenez en compte les points suivants lorsque vous choisissez comment implémenter ce modèle :
- Vérifiez que les hôtes approuvés exposent uniquement des points de terminaison internes ou protégés, utilisés uniquement par l’opérateur de contrôle. Les hôtes approuvés ne doivent pas exposer des interfaces ou des points de terminaison externes.
- L’opérateur de contrôle doit s’exécuter en mode à privilèges limités, ce qui nécessite généralement l’exécution de l’opérateur de contrôle et de l’hôte approuvé dans des services hébergés ou des machines virtuelles distincts.
- L’opérateur de contrôle ne doit effectuer aucun traitement lié à l’application ou aux services, ni accéder aux données. Sa fonction consiste exclusivement à valider et à assainir les requêtes. Il est possible que les hôtes approuvés aient besoin d’effectuer une validation supplémentaire des requêtes, mais l’opérateur de contrôle doit effectuer la validation principale.
- Utilisez un canal de communication sécurisé (HTTPS, SSL ou TLS) entre l’opérateur de contrôle et les hôtes approuvés ou les tâches, lorsque cela est possible. 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 d’opérateur de contrôle aura probablement un impact sur les performances en raison du traitement supplémentaire et de la communication réseau requis.
- L’instance d’opérateur de contrôle peut être un point de défaillance unique. Pour réduire l’impact d’un échec, envisagez de déployer des instances redondantes et d’utiliser un mécanisme de mise à l’échelle automatique pour garantir la capacité nécessaire au maintient de la disponibilité.
Quand utiliser ce modèle
Ce modèle est utile pour les applications qui :
- gèrent des informations sensibles
- exposent des services qui nécessitent un degré élevé de protection contre des attaques malveillantes
- effectuent des opérations stratégiques qui ne peuvent pas être interrompues.
- nécessitent une exécution de la validation des requêtes séparément des tâches principales ou une centralisation de cette validation pour simplifier la maintenance et l’administration
Conception de la charge de travail
Un architecte doit évaluer la façon dont le modèle Gatekeeper 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 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êtes vous permet de centraliser les fonctionnalités de sécurité telles que les pare-feu d’applications web, la DDoS Protection, la détection des robots, la manipulation de requêtes, l’initiation de l’authentification et les contrôles 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 grâce à des optimisations de la mise à l’échelle, des données, du code. | Ce modèle permet d’implémenter la limitation au niveau de la passerelle plutôt que des contrôles 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élection de services |
Comme pour toute autre décision de conception, il convient de prendre en compte les compromis par rapport aux objectifs des autres piliers qui pourraient être introduits avec ce modèle.
Exemple
Dans un scénario d’hébergement cloud, vous pouvez implémenter ce modèle en découplant le rôle d’opérateur de contrôle ou de machine virtuelle des rôles approuvés et des services dans une application. L’implémentation peut utiliser un point de terminaison interne, une file d’attente ou un stockage comme mécanisme de communication intermédiaire. La figure illustre l’utilisation d’un point de terminaison interne.
Ressources associées
Le modèle de clé Valet peut également être intéressant lorsque vous implémentez le modèle d’opérateur de contrôle. Lors de la communication entre l’opérateur de contrôle et les rôles approuvés, il est conseillé de renforcer la sécurité à l’aide de clés ou de jetons qui limitent les autorisations pour accéder aux ressources. Le modèle décrit l’utilisation d’un jeton ou d’une clé qui fournit aux clients un accès direct limité à une ressource ou un service spécifique.