Comment planifier un firewall de nouvelle génération dans le cloud avant d'écrire la première règle

Il y a un chantier qui semble commencer par le firewall et qui commence en réalité bien avant : sécuriser le réseau VPC d'une organisation avec Cloud NGFW (Cloud Next Generation Firewall, le firewall distribué de Google Cloud qui se configure avec des politiques plutôt qu'avec des règles liées à chaque instance). Yuri, ingénieur réseau cloud chez Cymbal Bank, le reçoit de la direction un jour ordinaire et ne sait pas par où commencer. Le cas et ce qui suit viennent de « Plan Your Cloud Next Generation Firewall Needs », de Google Skills. La réponse que donne la source est inconfortable d'abord et libératrice ensuite : le point de départ ne sont pas les règles. C'est de comprendre ce qu'on protège et comment tout se connecte.

Quoi rassembler avant de toucher à une seule règle

Avant de concevoir la protection, Yuri doit rassembler quatre choses. Des cartes de topologie réseau, avec leurs entrées, leurs sorties et leurs flux de trafic. Les applications qui tournent sur les réseaux VPC. Les exigences de sécurité de ces applications et de leurs données. Et les exigences de conformité qui pèsent sur l'affaire.

Rien de tout cela ne vit dans la console de firewall. Cela vit dans la documentation d'architecture, dans les conversations avec les équipes qui font tourner les applications et dans les cadres de conformité que l'entreprise a déjà signés. La raison de le rassembler d'abord est pratique : la sécurité n'est pas « taille unique », et une conception efficace de firewall part d'une compréhension profonde de ce qui est protégé et de comment tout se connecte. Savoir quelles VM existent ne suffit pas. Une VM ne dit pas si y vit un processeur de cartes ou un environnement de test jetable.

flowchart TD
    I[Cartes de topologie avec entrées, sorties et flux] --> C[Classer les actifs : impact métier et niveau de données]
    A[Applications sur les réseaux VPC et leurs exigences] --> C
    R[Exigences de conformité] --> C
    C --> G[Grouper les actifs avec les mêmes besoins de sécurité]
    G --> S[Subnets, secure tags et address groups]
    S --> P[Règles avec le moindre privilège et politique documentée]

Classer : deux questions sur chaque actif

Avec l'information en main, la suite est de classer, et le schéma utilise deux questions sur chaque actif.

La première question porte sur l'impact métier. D'un côté se trouve l'infrastructure critique : plateformes e-commerce et applications métier principales, avec un coût d'arrêt très élevé. De l'autre se trouvent les systèmes de support : outils internes et environnements de développement, dont l'impact est moindre. La réponse change ce qui se conçoit ensuite : haute disponibilité et tolérance quasi nulle d'un côté ; permissions plus relâchées et cycles de changement plus rapides de l'autre.

La seconde question porte sur le niveau de sécurité des données, en trois paliers. Restreint : informations personnelles de santé et numéros de carte, qui réclament l'isolement le plus fort et le contrôle d'accès le plus strict. Confidentiel : données internes de l'affaire et propriété intellectuelle, avec protection forte mais accès plus large au sein de l'organisation. Public : contenu web et matériaux téléchargeables, qui a encore besoin d'une protection contre le défacement ou les modifications non autorisées, avec un contrôle d'accès moins restrictif.

Le troisième palier est le plus sous-estimé. « Public » décrit qui peut lire le contenu, pas qui peut le modifier. Un site public mal configuré reste un actif que quelqu'un peut altérer.

Segmenter : grouper pour pouvoir régler

Avec les actifs classés, la segmentation consiste à grouper actifs et applications ayant les mêmes besoins de sécurité. Grouper est ce qui rend les règles écritables : règles par groupe, pas par IP en vrac. En renfort, la source applique des politiques de firewall à l'hôte de la base de données comme seconde ligne de défense, de sorte qu'une erreur dans la politique du réseau ne laisse pas la base exposée par accident.

Trois mécanismes rendent ce groupement concret :

Subnets. Vérifier que seuls des utilisateurs de subnets spécifiques accèdent à la base de données, et documenter la politique qui n'autorise le trafic qu'à partir de ces subnets.
Secure tags. Créer une étiquette « environment » avec les valeurs development ou production, appliquer ces paires libellé/valeur aux réseaux VPC et associer des politiques de firewall par cette paire. L'avantage est que la politique pend de l'étiquette et non d'une liste d'IP qui change à chaque fois qu'une nouvelle ressource se lève.
Address groups. Grouper des plages d'IP sous un nom. Dans l'exemple de la source, un groupe « web-servers » avec les plages d'IP de tous les serveurs web, et une règle qui autorise le trafic de ce groupe vers les serveurs de base de données.

Les trois se complètent. Le subnet définit où vit la ressource, le secure tag définit ce qu'elle est, et l'address group définit depuis où on peut la toucher.

Réseaux connectés : qui est propriétaire des règles

Les actifs ne vivent presque jamais seuls. Il y a des réseaux connectés, et là apparaît une question de confiance : l'autre réseau est-il géré par la même équipe ? A-t-il les mêmes exigences de sécurité ? La réponse décide de la rigueur des règles.

Le cours traite deux façons de connecter des réseaux. En Shared VPC, le projet hôte gère les politiques et règles de firewall, si bien que la configuration reste d'un seul côté. En VPC Network Peering, chaque projet garde ses propres politiques et règles, et cette liberté est aussi une charge : si l'équipe d'à côté n'a pas la même discipline, le trafic entre quand même. La règle pratique qui en sort est que le niveau de confiance entre réseaux connectés est une donnée de conception, pas un détail d'implémentation.

Les deux axes du trafic

Avec les groupes et les connexions clairs, la carte des flux permet de regarder le trafic selon ses deux directions de travail.

flowchart LR
    subgraph NS[Nord-sud]
        E[Internet ou un autre cloud] -->|entrée : seulement le nécessaire| V[VPC Google Cloud]
        V -->|sortie : contre l'exfiltration| E
    end
    subgraph EW[Est-ouest]
        V2[Couche applicative] -->|requêtes et APIs internes| B[Base de données]
    end

Le nord-sud est le trafic entre les réseaux VPC Google Cloud et les sources externes, qu'il s'agisse d'internet public ou d'autres clouds. Les règles d'entrée n'autorisent que les connexions nécessaires, par exemple HTTP/HTTPS pour les serveurs web. Les règles de sortie restreignent l'accès sortant pour prévenir l'exfiltration de données et limiter l'exposition à des sites externes malveillants. La sortie est la moitié la plus négligée : un serveur compromis qui peut encore parler vers l'extérieur n'est pas contenu, il est simplement cassé.

L'est-ouest est le trafic entre réseaux VPC, même sous des nœuds d'organisation différents : la communication entre couches applicatives, les connexions aux bases de données et les appels internes aux APIs. Il est généralement moins sensible que le nord-sud, et pourtant c'est l'axe où un mouvement latéral exploite un service mal configuré pour monter d'un niveau.

Connexions externes : chacune avec son risque

La source clôt avec un inventaire des connexions externes qu'il faut garder à l'esprit au moment d'écrire les règles, parce que chaque type demande une réponse différente.

Adresse IP publique. C'est la connexion qui demande le plus de protection. Les politiques appliquent strictement le principe du moindre privilège, et il vaut ajouter des mesures supplémentaires comme VPC Service Controls, qui bornent le périmètre autour des services Google Cloud.

Cloud VPN. Il a un peu moins de risque parce que les utilisateurs sont connus, mais le firewall se conçoit quand même. Si on contrôle le réseau pair, configurez aussi un firewall là-bas, pour que la protection existe avant que le trafic n'entre dans Google Cloud. Au minimum, une politique qui autorise le trafic entrant depuis le réseau pair. Et si certains types de trafic sont refusés, créez des règles de sortie supplémentaires au lieu d'attendre que quelqu'un signale le problème.

Cloud Interconnect. Il relie généralement le réseau on-premise propre, considéré comme plus fiable qu'internet public, et il demande aussi un firewall sur le réseau pair. La confiance plus grande ne supprime pas le contrôle : elle le déplace.

Cloud NAT. Il sert surtout au trafic sortant des instances de subnets privées sans IP publique. Ces instances peuvent être compromises et commencer à se connecter à des serveurs externes malveillants. Les règles doivent contrôler ce qu'elles accessent à l'extérieur, bloquer des destinations connues comme malveillantes ou restreindre le trafic sortant vers des services de confiance ou nécessaires.

Ce que ce cadrage laisse et ce qui reste à prouver

Le cadrage a un bénéfice qui ne se remarque qu'une fois appliqué : les règles se retrouvent avec un but documenté. On n'écrit pas « autoriser 443 parce que l'équipe d'applications l'a demandé », on écrit « les serveurs web du groupe web-servers atteignent les serveurs de base de données parce que cette couche l'exige, et tout le reste non ». Quand quelqu'un demandera pourquoi une règle existe, la réponse est dans la carte de topologie et dans la classification des actifs, pas dans la mémoire de qui l'a écrite.

Ce qui reste à prouver est le habituel. C'est un cadrage de planification : l'implémentation propre sur un réseau avec budget et politiques réels n'a pas eu lieu, et les décisions de moindre privilège ne se testent qu'à la première application qui casse le schéma. Et le quiz que la source propose pour confirmer le contenu n'a pas non plus été complété. Ce qui reste clair, c'est où regarder la prochaine fois que quelqu'un demandera à « mettre un firewall » : dans la carte, dans la classification et dans les flux, avant la console.

---

Source : « Plan Your Cloud Next Generation Firewall Needs », de Google Skills (cours google.cloud-ngfw).