Quand utiliser le Pare-feu Azure

  • 8 minutes

Vous savez ce qu’est le Pare-feu Azure et comment il fonctionne. Vous avez maintenant besoin de certains critères pour vous aider à déterminer si le Pare-feu Azure et Azure Firewall Manager sont des solutions qui conviennent à votre entreprise. Pour vous aider à décider, examinons les scénarios suivants :

  • Vous voulez protéger votre réseau contre l’infiltration.
  • Vous voulez protéger votre réseau contre une erreur de l’utilisateur
  • Votre entreprise propose un site marchand ou des paiements par carte de crédit.
  • Vous voulez configurer une connectivité Spoke-à-Spoke.
  • Vous voulez surveiller le trafic entrant et sortant.
  • Votre réseau demande plusieurs pare-feu.
  • Vous voulez implémenter des stratégies de pare-feu hiérarchiques.

Dans le cadre de votre évaluation du Pare-feu Azure et d’Azure Firewall Manager, vous savez que Contoso a rencontré plusieurs de ces scénarios. Lisez les sections correspondantes suivantes pour plus de détails.

Vous voulez protéger votre réseau contre l’infiltration

L’un des principaux objectifs d’un grand nombre d’acteurs malveillants consiste à infiltrer votre réseau. Ces intrus risquent de vouloir utiliser vos ressources réseau ou examiner, voler ou détruire des données sensibles ou propriétaires.

Le Pare-feu Azure est conçu pour vous aider à éviter de telles intrusions. Par exemple, un pirate malveillant peut tenter d’infiltrer le réseau en demandant l’accès à une ressource réseau. Le Pare-feu Azure utilise l’inspection avec état des paquets réseau pour examiner le contexte de ces demandes. Si la demande est une réponse à une activité légitime antérieure, il est probable que le pare-feu autorise la demande. Si la demande semble venir de nulle part, comme une demande envoyée par un pirate potentiel, le pare-feu refuse la demande.

Vous voulez protéger votre réseau contre une erreur de l’utilisateur

Peut-être que la méthode la plus courante pour infiltrer un réseau ou installer un logiciel malveillant sur un ordinateur réseau consiste à piéger un utilisateur du réseau en l’incitant à cliquer sur un lien dans un e-mail. Ce lien envoie l’utilisateur sur un site web malveillant contrôlé par un pirate, qui installe le programme malveillant ou piège l’utilisateur en lui demandant d’entrer les informations d’identification du réseau.

Le Pare-feu Azure empêche ces attaques en utilisant le renseignement sur les menaces pour refuser l’accès aux adresses IP et domaines malveillants connus.

Votre entreprise propose des paiements en ligne ou par carte de crédit

Est-ce que votre entreprise a un site marchand ou traite des paiements par carte de crédit ? Si oui, votre entreprise doit probablement se conformer au PCI DSS (Payment Card Industry Data Security Standard). Le PCI DSS est un ensemble de normes de sécurité créées et gérées par le Conseil des normes de sécurité PCI. Pour obtenir la conformité PCI, le PCI DSS liste une douzaine de conditions. Voici la première condition :

  • Installer et gérer la configuration d’un pare-feu pour protéger les données des titulaires de carte.

Le PCI DSS spécifie que vous devez définir une configuration de pare-feu qui restreint tout le trafic entrant et sortant des hôtes et des réseaux non approuvés. Le pare-feu doit également refuser tout autre trafic, à l’exception des protocoles nécessaires au traitement des cartes de paiement.

Vous voulez configurer une connectivité Spoke-à-Spoke

Une topologie de réseau Hub-and-Spoke classique présente les caractéristiques suivantes :

  • Un réseau virtuel jouant le rôle de point de connectivité central : le Hub.
  • Un ou plusieurs réseaux virtuels appairés au Hub : les Spokes. Un réseau local connecté via un circuit ExpressRoute ou une passerelle VPN peut également être considéré comme un Spoke dans cette topologie.

Les réseaux Spoke peuvent échanger des données avec le Hub, mais les Spokes ne peuvent pas communiquer directement entre eux. Vous aurez sans doute besoin d’une connexion directe. Par exemple, un réseau Spoke peut héberger une interface de programmation d’applications (API) qui nécessite des informations d’une base de données SQL déployée sur un autre Spoke.

Une solution consiste à appairer les réseaux Spoke les uns avec les autres. Cela fonctionne pour quelques connexions, mais cela peut devenir rapidement lourd à mesure que le nombre de connexions augmente.

Une solution plus simple et plus sûre consiste à utiliser le Pare-feu Azure pour configurer la connectivité directe entre les Spokes. Vous obtenez cette connectivité en déployant d’abord une instance de Pare-feu Azure dans le Hub. Vous configurez ensuite les réseaux virtuels Spoke avec des routes définies par l’utilisateur qui acheminent spécifiquement les données via le pare-feu et vers l’autre Spoke.

Diagramme du réseau d’une connexion Spoke-à-Spoke entre une machine virtuelle et une base de données SQL via le Pare-feu Azure.

Vous voulez surveiller le trafic entrant et sortant

Votre entreprise peut vouloir analyser des rapports détaillés sur le trafic réseau entrant et sortant. Les raisons de demander ces rapports sont nombreuses, notamment la conformité réglementaire, l’application des stratégies de l’entreprise sur l’utilisation d’Internet et la résolution des problèmes.

Vous pouvez configurer le Pare-feu Azure pour conserver les journaux de diagnostic de quatre types d’activité de pare-feu :

  • Règles d’application
  • Règles de réseau
  • Renseignement sur les menaces
  • Proxy DNS

Par exemple, le journal pour les règles d’application de votre pare-feu peut inclure des entrées telles que les suivantes pour une demande sortante :

  • Requête HTTPS de 10.1.0.20:24352 à somewebsite.com:443. Action : Autoriser. Regroupement de règles : regroupement100. Règle : règle105

De même, le journal pour les règles de réseau de votre pare-feu peut inclure des entrées telles que les suivantes pour une demande entrante :

  • Requête TCP de 73.121.236.17:12354 à 10.0.0.30:3389. Action : Deny

Une fois que vous activez la journalisation des diagnostics, vous pouvez surveiller et analyser les journaux des manières suivantes :

  • Vous pouvez examiner les journaux directement dans leur format JSON natif.
  • Vous pouvez examiner les journaux dans Azure Monitor.
  • Vous pouvez examiner et analyser les journaux dans le workbook Pare-feu Azure.

Votre réseau demande plusieurs pare-feu

Si l’empreinte Azure de votre entreprise s’étend sur plusieurs régions Azure, vous disposez de plusieurs connexions Internet, ce qui signifie que vous avez besoin d’une instance de pare-feu déployée pour chacune de ces connexions. Vous pourriez configurer et gérer ces pare-feu séparément, mais cela créerait plusieurs problèmes :

  • La gestion de plusieurs pare-feu représente beaucoup de travail.
  • Les changements globaux de règles et de paramètres doivent être propagés à tous les pare-feu.
  • Il est difficile de maintenir une cohérence entre tous les pare-feu.

Azure Firewall Manager résout ces problèmes en vous donnant une interface de gestion centralisée pour chaque instance de Pare-feu Azure dans l’ensemble des régions et abonnements Azure. Vous pouvez créer des stratégies de pare-feu, puis les appliquer à chaque pare-feu pour maintenir une cohérence. Les changements apportés à une stratégie sont propagés automatiquement à toutes les instances de pare-feu.

Vous voulez implémenter des stratégies de pare-feu hiérarchiques

De nombreuses entreprises plus petites peuvent utiliser une seule stratégie de pare-feu pour tout. En effet, les petites entreprises peuvent souvent créer une seule stratégie de pare-feu qui s’applique à chaque utilisateur et ressource du réseau.

Toutefois, pour la plupart des entreprises plus grandes, une approche plus nuancée et plus détaillée est nécessaire. Par exemple, examinez les deux scénarios suivants :

  • Un magasin DevOps peut avoir un réseau virtuel pour le développement d’une application, un deuxième réseau virtuel pour la préproduction de l’application et un troisième pour la version de production de l’application.
  • Une grande entreprise peut avoir des équipes distinctes pour les utilisateurs de base de données, les ingénieurs et les vendeurs. Chacune de ces équipes a son propre ensemble d’applications exécutées dans des réseaux virtuels séparés.

Même s’il y a des règles de pare-feu communes à tous, les utilisateurs et les ressources de chaque réseau virtuel nécessitent des règles de pare-feu spécifiques. C’est pourquoi les entreprises plus grandes ont presque toujours besoin de stratégies de pare-feu hiérarchiques. Les stratégies de pare-feu hiérarchiques sont constituées des deux composants suivants :

  • Une seule stratégie de pare-feu de base qui implémente les règles qui doivent être appliquées à l’ensemble de l’entreprise.
  • Une ou plusieurs stratégies de pare-feu locales qui implémentent des règles spécifiques à une application, une équipe ou un service en particulier. Les stratégies locales héritent de la stratégie de pare-feu de base, puis ajoutent des règles relatives à l’application, l’équipe ou le service sous-jacent.

Lorsque vous utilisez Azure Firewall Manager, vous pouvez définir une stratégie de pare-feu de base, puis créer des stratégies locales qui héritent de la stratégie de base et implémentent des règles spécifiques conçues pour la ressource sous-jacente.