Implémentation de modèle pour l’entrée sécurisée du réseau

L’entrée sécurisée du réseau encapsule plusieurs modèles de conception, notamment les modèles du routage global, du déchargement global et de monitoring de point de terminaison d’intégrité. Cette implémentation de modèle peut être utilisée comme passerelle pour toute charge de travail HTTPou HTTPS nécessitant une disponibilité ou fiabilité élevée avec un routage global sécurisé vers les charges de travail dans différentes régions, avec un basculement à faible latence.

Vidéo : Implémentation de l’entrée sécurisée du réseau

Exigences du modèle

Cet article met l’accent sur les trois exigences sur lesquelles se concentre l’implémentation du modèle d’entrée sécurisée du réseau : le routage global, le basculement à faible latence et l’atténuation des attaques à la périphérie.

Routage global

Le modèle d’entrée sécurisée du réseau encapsule le modèle du routage global. Ainsi, l’implémentation est en mesure de router les requêtes vers des charges de travail situées dans différentes régions.

Basculement à faible latence

L’implémentation doit être en mesure d’identifier les charges de travail saines et non saines et d’ajuster le routage en conséquence au moment opportun. La latence doit être en mesure de prendre en charge l’ajustement du routage en quelques minutes.

Atténuation des attaques à la périphérie

L’atténuation des attaques à la périphérie fait appel à la «  partie sécurisée du réseau » de l’implémentation. Les charges de travail ou les services PaaS ne doivent pas être accessibles via Internet. Le trafic Internet doit uniquement être en mesure d’être routé par le biais de la passerelle. La passerelle doit avoir la possibilité d’atténuer les attaques.

Modèles

Cette solution implémente les modèles de conception suivants.

• Modèle de routage de passerelle : routage des requêtes vers plusieurs services ou instances de service qui peuvent résider dans différentes régions.
• Modèle de déchargement de passerelle : déchargement des fonctionnalités, comme l’atténuation des attaques, vers un proxy de passerelle.
• Modèle de monitoring de point de terminaison d’intégrité : les charges de travail exposent des points de terminaison qui valident l’intégrité de la charge de travail.

Conception

Le diagramme montre le flux d’une requête HTTPS vers une zone Azure Front Door Premium avec Azure Web Application Firewall (WAF). Ceci illustre l’intégration entre Azure Front Door Premium et Azure Web Application Firewall. Le diagramme montre ensuite le flux de la requête par le biais de Azure Private Link vers deux empreintes différentes dans des régions différentes. Chaque empreinte a un site web statique et un équilibreur de charge interne. Les requêtes passent par Azure Private Link pour accéder aux sites web statiques et aux équilibreurs de charge dans les deux empreintes.

Cette implémentation inclut les détails suivants :

• Des comptes de Stockage Blob Azure sont utilisés pour simuler des charges de travail web statiques exécutées dans deux régions. Cette implémentation n’inclut aucune charge de travail s’exécutant derrière un équilibreur de charge interne. L’équilibreur de charge interne est illustré dans le diagramme pour montrer que cette implémentation fonctionnerait pour les charges de travail privées exécutées derrière un équilibreur de charge interne.
• Le niveau Premium d’Azure Front Door est utilisé comme passerelle globale.
• L’instance Azure Front Door a une stratégie Azure Web Application Firewall (WAF) globale configurée avec des règles gérées de protection contre les exploitations de failles de sécurité communes.
• Les comptes de stockage ne sont pas exposés sur Internet.
• Le niveau Premium d’Azure Front Door accède aux comptes de stockage par le biais d’Azure Private Link.
• La configuration générale de l’instance Azure Front Door est la suivante :
  • Un point de terminaison avec une route unique pointant vers un seul groupe d’origines. Un groupe d’origines est une collection d’origines ou de back-ends.
  • Le groupe d’origines a une origine configurée qui pointe vers chaque compte de stockage.
  • Chaque origine demande un accès Private Link au compte de stockage.
  • Le groupe d’origine a des sondes d’intégrité configurées pour accéder à une page HTML dans les comptes de stockage. La page HTML sert de point de terminaison d’intégrité pour les charges de travail statiques. Si les sondes sont capables d’accéder correctement à l’origine trois fois sur les quatre dernières tentatives, l’origine est considérée comme saine.

Composants

Requête web

• Azure Web Application Firewall : le niveau Premium de Web Application Firewall prend en charge les règles gérées par Microsoft pour se e protéger contre les attaques courantes.
• Azure Private Link : les points de terminaison privés dans Azure Private Link exposent un service PaaS Azure à une adresse IP privée dans un réseau virtuel. Le flux de communication s’effectue donc sur le réseau principal de Microsoft, et non sur l’Internet public.
• Niveau Premium d’Azure Front Door : Azure Front Door fournit un équilibrage de charge global de couche 7. Azure Front Door est intégré à Web Application Firewall. Le niveau Premium prend en charg ce qui suit :
  • Azure Private Link  : la prise en charge de Azure Private Link permet à Azure Front Door de communiquer avec les charges de travail ou services PaaS s’exécutant dans un réseau virtuel privé sur le réseau principal de Microsoft.
  • Prise en charge de l’ensemble de règles gérées Microsoft : le niveau Premium d’Azur Front Door prend en charge le niveau Premium de Web Application Firewall, qui prend en charge l’ensemble de règles gérées dans WAF.
• Compte de stockage Azure : des comptes de stockage Blob sont utilisés dans cette implémentation pour représenter un site web statique ou une charge de travail.
• Équilibreur de charge interne : cette implémentation n’utilise pas l’équilibreur de charge interne. Il apparaît ici pour représenter une charge de travail privée qui s’exécute derrière cet équilibreur de charge. Le routage vers le compte de stockage est le même que celui vers des équilibreurs de charge.

Opérations

La sécurisation des ressources depuis la perspective d’un réseau protège contre les attaques, mais isole également les ressources des processus ou des administrateurs pouvant avoir besoin d’accéder à ces ressources. Par exemple, un agent de build dans un pipeline DevOps peut avoir besoin d’accéder au compte de stockage pour déployer une mise à jour sur l’application web. De plus, un administrateur peut avoir besoin d’accéder à la ressource à des fins de résolution des problèmes.

Pour illustrer l’octroi d’un accès sécurisé au réseau à des fins opérationnelles, cette implémentation déploie une machine virtuelle (MV) dans un réseau virtuel doté d’un accès Private Link aux comptes de stockage. Cette implémentation déploie Azure Bastion, que l’administrateur peut utiliser pour se connecter à la MV. Pour le scénario de déploiement, un agent de build privée peut être déployé sur un réseau virtuel de la même façon que la MV l’a été.

Voici des détails sur les composants pour les opérations :

• Réseau virtuel Azure (VNet) : le réseau virtuel dans cette implémentation est utilisé pour contenir les composants nécessaires pour qu’un administrateur communique de manière sécurisée avec le compte de stockage sur le réseau principal de Microsoft privé.
• Machines Virtuelles Azure : cette implémentation utilise une MV comme serveur de rebond auquel les administrateurs peuvent se connecter. La MV est déployée dans le réseau virtuel privé.
• Azure Bastion : Azure Bastion permet à l’administrateur de se connecter de manière sécurisée à la MV serveur de rebond par le biais du protocole SSH sans obliger la machine virtuelle à avoir une adresse IP publique.
• Point de terminaison Private Link : le point de terminaison privé reçoit une adresse IP privée issue du réseau virtuel et se connecte au service PaaS du compte de stockage. Cette connexion permet aux ressources du réseau virtuel privé de communiquer avec le compte de stockage via l’adresse IP privée.
• Zone Azure DNS privée : la zone Azure DNS privée est un service DNS utilisé pour résoudre le nom d’hôte Azure Private Link du compte de stockage Azure en adresse IP privée du point de terminaison privé.

Flux de requête web

Le diagramme montre un utilisateur qui effectue une requête web auprès d’Azure Front Door. Dans la zone Azure Front Door, le diagramme montre chacune des étapes du flux de routage Azure Front Door. Dans le flux est mise en exergue l’étape où les règles WAF sont évaluées, où la route AFD est mise en correspondance et un groupe d’origines est sélectionné, et où l’origine est sélectionnée à partir du groupe d’origines. Le dernier élément mis en exergue est l’emplacement auquel AFD se connecte au compte de Stockage Blob Azure par le biais de Private Link.

1. L’utilisateur émet une requête HTTP ou HTTPS auprès d’un point de terminaison Azure Front Door.

2. Les règles WAF sont évaluées. Les règles qui correspondent sont toujours journalisées. Si le mode de stratégie Azure WAF Front Door est défini sur  Prévention  et que la règle de correspondance a une action définie sur  Bloquer sur anomalie , la requête est bloquée. Sinon, la requête continue, elle est redirigée ou les règles suivantes sont évaluées.

3. La route configurée dans Azure Front Door est mise en correspondance et le groupe d’origines approprié est sélectionné. Dans cet exemple, le chemin menait au contenu statique inclus dans le site web.

4. L’origine est sélectionnée dans le groupe d’origines.

   a. Dans cet exemple, les sondes d’intégrité ont jugé le site web défectueux, donc il est éliminé des origines possibles.
   b. Ce site web est sélectionné.

5. La requête est routée vers le compte de stockage Azure par le biais d’une liaison privée sur le réseau principal de Microsoft.

Pour plus d’informations sur l’architecture de routage Azure Front Door, consultez Vue d’ensemble de l’architecture de routage.

Flux opérationnel

Le diagramme comporte trois parties. La première partie montre le Stockage Blob Azure agissant en tant que site web statique. Azure Front Door se connecte via Private Link au compte de stockage. La deuxième partie est une zone qui représente un réseau virtuel. Le réseau virtuel a des sous-réseaux et leur contenu. Ces sous-réseaux incluent un sous-réseau de point de terminaison Azure Private Link avec une adresse IP 10.0.2.5, 2) un sous-réseau avec une MV serveur de rebond et un sous-réseau Azure Bastion qui contient Azure Bastion. La troisième partie est un utilisateur administratif qui utilise SSH pour accéder à la MV serveur de rebond dans le réseau virtuel via Azure Bastion. Une flèche va de la MV à la zone Azure DNS privée. La dernière flèche relie la machine virtuelle au point de terminaison Azure Private Link, puis au compte de stockage.

1. Un administrateur se connecte à l’instance Azure Bastion déployée dans le réseau virtuel.

2. Azure Bastion fournit une connectivité SSH au serveur de rebond/MV.

3. L’administrateur de la jumpbox tente d’accéder au compte de stockage par le biais d’Azure CLI. La jumpbox interroge le DNS pour le point de terminaison du compte public Azure Blob Storage : storageaccountname.blob.core.windows.net.

   Le DNS privé se résout en fin de compte en storageaccountname.privatelink.blob.core.windows.net. Il retourne l’adresse IP privée du point de terminaison Azure Private Link, qui est 10.0.2.5 dans cet exemple.

4. Une connexion privée au compte de stockage est établie par le biais du point de terminaison de Azure Private Link .

Considérations

Gardez à l’esprit les points suivants lorsque vous utilisez cette solution.

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é.

Ce scénario traite les points clés suivants en ce qui concerne la fiabilité :

• Le routage global avec une latence faible, par le biais de l’utilisation de sondes d’intégrité, assure la fiabilité en isolant l’application des pannes régionales.
• Web Application Firewall (WAF) sur Azure Front Door assure une protection centralisée pour les requêtes HTTP et HTTPS.

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é.

Ce scénario traite les points clés suivants en ce qui concerne la sécurité :

• La prise en charge de Private Link par le niveau Premium d’Azure Front Door élimine le besoin d’exposer vos services internes ou PaaS sur Internet. Private Link permet à Azure Front Door de communiquer avec vos services privés ou PaaS par le biais du réseau principal de Microsoft.
• Web Application Firewall (WAF) sur Azure Front Door assure une protection centralisée pour les requêtes HTTP et HTTPS.
• Les règles gérées dans Web Application Firewall Premium sont des règles gérées par Microsoft qui vous protègent contre un ensemble courant de menaces de sécurité.

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.

Bien que les niveaux Premium d’Azure Front Door et Web Application Firewall fournissent des fonctionnalités de sécurité avancées par rapport au niveau standard, ils impliquent aussi des coûts supplémentaires. Passez en revue les ressources suivantes pour en savoir plus sur les prix d’Azure Front Door et Web Application Firewall :

• Tarifs d’Azure Front Door
• Tarifs de Web Application Firewall
• Calculatrice de prix Azure

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.

L’implémentation des limites de sécurité réseau ajoute de la complexité en ce qui concerne les opérations et le déploiement. Gardez à l’esprit les points suivants :

• Les plages d’adresses IP pour les agents hébergés par Microsoft varient au fil du temps. Vous devez envisager d’implémenter des agents auto-hébergés dans votre réseau virtuel.
• Implémentez Azure Bastion pour les scénarios où les équipes des opérations ont besoin d’accéder à des ressources réseau sécurisées.
• L’utilisation de Web Application Firewall sur Azure Front Door fournit une protection centralisée pour les requêtes HTTP et HTTPS et constitue un exemple de modèle de déchargement de passerelle. La responsabilité de l’examen des requêtes afin de détecter d’éventuelles attaques a été déchargée vers WAF dans Azure Front Door. L’avantage d’une perspective d’excellence opérationnelle est que vous devez gérer les règles depuis un seul endroit.

Important

L’exemple d’entrée sécurisée du réseau vous permet de déployer toutes les ressources nécessaires pour vous connecter à un serveur de rebond par le biais d’Azure Bastion et vous connecter à une machine virtuelle sécurisée du réseau.

Efficacité des performances

L’efficacité des performances réside dans la capacité de votre charge de travail à s’adapter efficacement pour répondre aux besoins des utilisateurs. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.

Le routage global permet une mise à l’échelle horizontale par le biais du déploiement de ressources supplémentaires dans des régions identiques ou différentes.

Étapes suivantes

• Déployez cette implémentation en suivant les étapes décrites dans l’exemple d’entrée sécurisée au réseau .