Migrer vers Palo Alto sans coupure, et repartir avec un jeu de règles lisible
NeoEdge est partenaire Palo Alto Networks et accompagne les organisations qui remplacent leur pare-feu par une solution Palo Alto. Nous opérons un SOC français actif 24/7 et un CERT, depuis quatre agences couvrant la quasi-totalité du territoire.
Sur ce type de projet, la réussite ne se mesure pas au matériel installé. Elle se mesure à deux chiffres : le nombre d’heures d’exploitation récupérées chaque mois, et le nombre de règles supprimées. Sur un parc de dix ans, c’est souvent la moitié du jeu de règles qui disparaît — et c’est ce qui change vraiment la vie de l’équipe.
Le vrai sujet d’une migration de pare-feu : les règles, pas le boîtier
Remplacer un équipement est une opération d’une journée. Reprendre une politique de sécurité accumulée sur dix ans en est une tout autre.
Un parc ancien contient invariablement les mêmes strates : des règles ouvertes pour un prestataire parti depuis longtemps, des exceptions « temporaires » devenues permanentes, des objets réseau qui ne correspondent plus à rien, et des autorisations larges posées un vendredi soir pour débloquer une situation. Personne n’ose y toucher, parce que personne ne sait ce qui casserait.
Notre méthode consiste à ne pas transposer cette dette. Nous partons des flux réellement observés plutôt que des règles déclarées : ce qui n’a jamais été utilisé sur une période d’observation significative ne sera pas repris. La politique cible est construite sur l’usage constaté, validée avec les responsables applicatifs, puis appliquée d’abord en observation avant de passer en blocage.
C’est plus long qu’une conversion automatique, et c’est la raison pour laquelle le résultat est différent. Une conversion mécanique reproduit le désordre sur un équipement neuf.
Passer du filtrage par port au filtrage applicatif
L’intérêt d’un pare-feu de nouvelle génération n’est pas d’être plus rapide, c’est de raisonner en applications plutôt qu’en ports. Une règle qui autorise un port ouvre la porte à tout ce qui sait l’emprunter ; une règle qui autorise une application précise ne laisse passer que celle-là.
La bascule ne se fait pas d’un coup. Nous procédons par étapes : observation des applications réellement vues sur chaque règle, remplacement progressif des autorisations par port, contrôle des effets, puis fermeture. Chaque étape est réversible.
Remplacer un pare-feu existant
Nous intervenons sur les migrations depuis les principales solutions du marché. Les difficultés ne sont pas les mêmes selon l’origine : la traduction des règles de translation d’adresses, la reprise des tunnels chiffrés vers les partenaires, la gestion des accès distants pendant la bascule, et la correspondance des objets sont les points qui demandent le plus d’attention.
Le plan de bascule prévoit systématiquement une fenêtre de retour arrière et une période de fonctionnement en parallèle sur les flux critiques. Nous ne coupons jamais l’ancien équipement le jour de la mise en service.
NIS2 : ce que la directive demande au pare-feu
La plupart des contenus disponibles expliquent ce qu’est NIS2. Très peu expliquent ce qu’il faut faire, concrètement, sur les équipements.
Les exigences se traduisent par des chantiers précis : segmenter les domaines afin qu’une compromission ne se propage pas latéralement, journaliser les flux refusés et pas seulement les flux autorisés — sans quoi une tentative d’intrusion ne laisse aucune trace —, authentifier fortement les accès d’administration, et être capable de produire l’historique des changements de configuration lors d’un contrôle.
Le cas industriel mérite une mention particulière. La séparation entre le domaine bureautique et le domaine industriel est l’un des points les plus regardés, et l’un des plus délicats à mettre en œuvre sans interrompre la production. C’est un travail d’ingénierie, pas de documentation.
Auditer avant de remplacer
Beaucoup d’organisations envisagent un changement d’équipement alors que le problème réel est ailleurs. Notre audit de configuration établit l’état des lieux : règles jamais utilisées, autorisations trop larges, objets orphelins, interfaces d’administration exposées, journalisation incomplète, versions logicielles en retard.
C’est une mission courte, à résultat immédiat, qui aboutit à un plan priorisé. Il arrive qu’elle conclue qu’un remplacement n’est pas nécessaire — et nous le disons.
Supervision continue par notre SOC
Un pare-feu bien configuré se dégrade avec le temps si personne ne suit ses évolutions. Notre SOC assure la surveillance permanente, la qualification des alertes, le suivi des versions et des correctifs, et la revue périodique des règles. Notre CERT intervient en réponse à incident.
Une couverture nationale depuis quatre agences
Marseille, notre siège, couvre le bassin méditerranéen d’Aix-en-Provence et Toulon à Nice, Montpellier et Nîmes, et remonte jusqu’à Valence. Lyon couvre l’Auvergne-Rhône-Alpes, de Grenoble à Clermont-Ferrand, Saint-Étienne, Annecy et Dijon. Amiens couvre les Hauts-de-France avec Lille, la Normandie avec Rouen et Le Havre, ainsi que Reims et le nord de l’Île-de-France. Paris couvre l’Île-de-France et les grands comptes nationaux.
Questions fréquentes
Combien de temps dure une migration de pare-feu ?
Peut-on convertir automatiquement les règles depuis un autre pare-feu ?
Faut-il couper le service pendant la bascule ?
Qu'apporte le filtrage applicatif par rapport au filtrage par port ?
Que demande NIS2 concernant les pare-feu ?
NeoEdge peut-il auditer notre pare-feu sans projet de remplacement ?
Combien de règles inutiles dans votre pare-feu ?
Notre audit de configuration part des flux réellement observés et produit un plan priorisé. Il conclut parfois qu’il ne faut rien remplacer.