Partager via

Mise en œuvre de modèle pour un ingress sécurisé du réseau.

L’entrée sécurisée du réseau encapsule plusieurs modèles de conception, notamment les modèles de routage global, de déchargement global et de surveillance de l'intégrité des points de terminaison. Vous pouvez utiliser l’implémentation de modèle dans cet article en tant que passerelle pour toute charge de travail HTTP ou HTTPS nécessitant une haute disponibilité ou une fiabilité en fournissant un routage global sécurisé vers des charges de travail dans différentes régions avec un basculement à faible latence.

Vidéo : Implémentation d’entrée sécurisée réseau

Exigences en matière de modèles

Cet article décrit trois exigences sur lesquelles l’implémentation de modèle pour l’entrée sécurisée réseau se concentre sur le routage global, le basculement à faible latence et l’atténuation des attaques en périphérie.

Routage global

Le modèle d’entrée sécurisé réseau encapsule le modèle de routage global. Par conséquent, l’implémentation peut acheminer les demandes vers des charges de travail dans différentes régions.

Diagramme montrant une requête HTTPS routée vers deux charges de travail 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 de manière temporelle. 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 nécessite la partie « sécurisée du réseau » de l’implémentation. Les charges de travail ou les services PaaS (Platform as a Service) ne doivent pas être accessibles via Internet. Le trafic Internet doit être acheminé uniquement via 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 une requête qui transite par Azure Front Door Premium vers des serveurs régionaux.

Cette implémentation inclut les détails suivants :

  • Il utilise des comptes Stockage Blob Azure pour simuler des charges de travail web statiques s’exécutant dans deux régions. Cette implémentation n’inclut aucune charge de travail s’exécutant derrière un équilibreur de charge interne (ILB). Le diagramme montre un ILB pour illustrer que cette implémentation fonctionnerait pour les charges de travail privées exécutées derrière un ILB.
  • Il utilise le niveau Premium Azure Front Door comme passerelle globale.
  • L’instance Azure Front Door a une stratégie de pare-feu d’applications web (WAF) globale configurée avec des règles managées qui vous aident à vous protéger contre les attaques courantes.
  • Les comptes de stockage ne sont pas exposés sur Internet.
  • Le niveau Premium Azure Front Door accède aux comptes de stockage via Azure Private Link.
  • L’instance Azure Front Door a la configuration générale suivante :
    • Point de terminaison avec un itinéraire unique qui pointe vers un groupe d’origine unique. Un groupe d’origines est une collection d’origines ou de back-ends.
    • Le groupe d’origine a une origine configurée pour pointer vers chaque compte de stockage.
    • Chaque origine demande l’accès Private Link au compte de stockage.
    • Le groupe d’origine dispose de 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 peuvent accéder à l’origine dans trois des quatre dernières tentatives, l’origine est considérée comme saine.

Composants

Requête web

  • Pare-feu d’applications web Azure : le niveau Premium du pare-feu d’applications web prend en charge les règles gérées par Microsoft qui aident à se 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. Cette exposition permet à la communication de circuler sur le réseau principal Microsoft et non sur l’Internet public.
  • Niveau Azure Front Door Premium : Azure Front Door fournit un équilibrage de charge global de couche 7. Azure Front Door est intégré au pare-feu d’applications web. Le niveau Premium prend en charge :
    • Azure Private Link : la prise en charge de Private Link permet à Azure Front Door de communiquer avec les services PaaS ou les charges de travail s’exécutant dans un réseau virtuel privé sur le réseau principal Microsoft.
    • Ensembles de règles gérés par Microsoft : le niveau Premium d’Azure Front Door prend en charge le niveau Premium du pare-feu d’applications web, qui prend en charge l’ensemble de règles managées dans le WAF.
  • Stockage Azure : cette implémentation utilise des comptes Blob Storage pour représenter un site web ou une charge de travail statique.
  • É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 identique à celui des équilibreurs de charge.

Opérations

La sécurisation des ressources du point de vue du réseau permet de se protéger contre les attaques, mais elle isole également les ressources des processus ou administrateurs qui peuvent 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. En outre, un administrateur peut avoir besoin d’accéder à la ressource à des fins de résolution des problèmes.

Pour illustrer l’accès au réseau sécurisé à des fins opérationnelles, cette implémentation déploie une machine virtuelle dans un réseau virtuel disposant 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 machine virtuelle. Pour le scénario de déploiement, un agent de build privé peut être déployé sur le réseau virtuel, de la même manière que la machine virtuelle.

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

  • Réseau virtuel Azure : cette implémentation utilise le réseau virtuel pour contenir les composants requis pour qu’un administrateur communique en toute sécurité avec le compte de stockage sur le réseau principal Microsoft privé.
  • Machines virtuelles Azure : cette implémentation utilise une machine virtuelle comme jumpbox pour que les administrateurs se connectent. La machine virtuelle est déployée dans le réseau virtuel privé.
  • Azure Bastion : Azure Bastion permet à l’administrateur de se connecter en toute sécurité à la machine virtuelle jumpbox via Secure Shell (SSH) sans que la machine virtuelle ait une adresse IP publique.
  • Point de terminaison Private Link : le point de terminaison privé reçoit une adresse IP privée à partir 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 Private Link du compte de stockage Azure vers l’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 à un point de terminaison Azure Front Door.

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

  3. L’itinéraire configuré dans Azure Front Door est mis en correspondance et le groupe d’origine correct est sélectionné. Dans cet exemple, le chemin d’accès était au contenu statique dans le site web.

  4. L’origine est sélectionnée à partir du groupe d’origines.

    a) Dans cet exemple, les sondes de santé ont jugé le site Web comme étant malsain, il est donc éliminé des origines possibles.
    b. Ce site web est sélectionné.

  5. La requête est acheminée vers le compte de stockage Azure via Private Link sur le réseau principal Microsoft.

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

Flux opérationnel

Diagramme montrant le flux utilisé par un administrateur 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 à la machine virtuelle jumpbox.

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

    Le DNS privé est finalement résolu en storageaccountname.privatelink.blob.core.windows.net. Elle retourne l’adresse IP privée du point de terminaison Private Link, qui est 10.0.2.5 dans cet exemple.

  4. Une connexion privée au compte de stockage est établie via le point de terminaison 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 Vue d’ensemble du pilier de fiabilité.

Ce scénario traite les points clés suivants concernant la fiabilité :

  • Le routage global avec une faible latence, grâce à l’utilisation de sondes d’intégrité, permet la fiabilité en isolant l’application contre les pannes régionales.
  • Le pare-feu d’applications web sur Azure Front Door offre une protection centralisée pour les requêtes HTTP et HTTPS.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’abus de vos données et systèmes précieux. Pour plus d’informations, consultez Vue d’ensemble du pilier de sécurité.

Ce scénario traite les points clés suivants concernant 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 qu’Azure Front Door Premium et le pare-feu d’applications web Premium fournissent des fonctionnalités de sécurité avancées sur le niveau Standard, il existe des coûts supplémentaires pour les deux. Consultez les ressources suivantes pour en savoir plus sur la tarification d’Azure Front Door et du pare-feu d’applications web :

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é aux opérations et au déploiement. Gardez ces éléments à l’esprit :

  • Les plages d’adresses IP pour les agents hébergés par Microsoft varient au fil du temps. Envisagez 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 d’opérations doivent accéder aux ressources sécurisées réseau.
  • L’utilisation du pare-feu d’applications web sur Azure Front Door pour fournir une protection centralisée pour les requêtes HTTP et HTTPS est un exemple de modèle de déchargement de passerelle. La responsabilité de l’examen des demandes d’exploits est déchargée sur le pare-feu d’applications web dans Azure Front Door. L’avantage d’un point de vue de l’excellence opérationnelle est que vous devez gérer les règles dans un seul endroit.

Important

L’exemple d’entrée sécurisée réseau vous permet de déployer toutes les ressources requises pour vous connecter à un jumpbox via Azure Bastion et de vous connecter à une machine virtuelle sécurisée réseau.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s'adapter aux besoins pour répondre aux demandes que les utilisateurs exigent. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.

Le routage global permet une mise à l’échelle horizontale via le déploiement de ressources supplémentaires dans la même région ou dans différentes régions.

Étapes suivantes