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

  • Article

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.

Diagramme montrant une requête HTTPS en cours de routage vers deux charges de travail situées dans des régions différentes.

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.

Diagramme montrant une requête HTTPS qui n’est pas routée vers une charge de travail non saine.

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.

Diagramme montrant une requête HTTPS avec une instruction SQL dans la chaîne de requête d’une requête qui n’est pas arrêtée à la périphérie.

Modèles

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

Conception

Diagramme montrant le flux d’une requête par le biais d’Azure Front Door (AFD) Premium vers des empreintes régionales.

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 charge :
    • 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

Diagramme montrant le flux d’une requête web.

  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

Diagramme montrant le flux qu’un administrateur utiliserait pour se connecter à une ressource protégée.

  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. Le serveur de rebond interroge le DNS pour obtenir le point de terminaison du compte de Stockage Blob Azure public : storageaccountname.blob.core.windows.net.

    DNS privé conclut finalement 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é :

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 :

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