Bonjour à tous   ,
 
Je viens à la pêche aux infos afin de savoir comment dans vos emplois (ou même homelab qui sait) vous gérez les ouvertures de flux sur des firewalls.
Je m'explique, lorsque vous avez des gros ou même petit besoins d'autorisation de ports, faites-vous ceci toujours à la main avec l'interface de votre firewall/en cli, ou avez-vous développé des process ou applications en internes ?
 
Actuellement, la plus classique a toujours été une matrice excel et on passe à la main sur les FW, mais j'aimerai automatiser ceci, et j'aimerai savoir si vous avez pensé à des solutions permettant d'être pratique pour le demandeur des flux, et peut-être automatisable via des API requests, sans rendre infernal un firewall avec une règle par port.
 
Merci d'avance !

Algosec ici mais c'est pas pour toutes les tailles d'infra.

A mon avis le premier truc à comprendre là-dedans c'est qu'il y a deux parties au problème :

1) la partie technique : comment changer la configuration du firewall sans avoir à faire 10000 clics. Ça suivant le constructeur de firewall ça va être plus ou moins simple mais globalement sur du matos de classe entreprise moderne, il y a des APIs qui permettent de s'en sortir (plus ou moins bien facilement selon les constructeurs - le diable est dans les détails)

2) la partie organisationnelle, qui demande de se poser des questions :
- qui sont les demandeurs (des personnes ? des équipes ? des responsables d'applications ?)
- quelles responsabilités ont-ils vis-a-vis des demandes qu'ils font  ? doivent-ils être en mesure de justifier les ressources utilisées (pas juste au moment de la demande mais aussi 3 ans après) et sinon, qu'est-ce qu'il les empêche de faire des demandes d'ouverture à l'infini sans jamais rien décommissionner (parce que s'ils peuvent faire ça c'est ce qu'ils feront vu que c'est plus simple pour eux) ?
- le SI est-il déjà modélisé ? l'automatisation sérieuse ne va pas sans modélisation, il faudra probablement avoir une source de vérité (par exemple CMDB) qui modélise les différents serveurs et services pour lesquels on va demander des accès, mais il y aura peut-être aussi besoin de modéliser l'organisation humaine (pour que tel besoin implémenté sur le firewall puisse être relié à tel demandeur)

Pour une bonne partie des entreprises qui se posent ce genre de question, le problème 2 est beaucoup plus complexe à résoudre que le problème 1, car il implique toute l'entreprise, et il demande souvent aux utilisateurs de devenir responsables des demandes qu'ils font, ce qui revient à leur ajouter du boulot.

Il y a des risques dans ce genre de projet :
- considérer seulement la partie ouverture de flux, ie on traite la demande et dès que ça tombe en marche on oublie. C'est un mode de fonctionnement courant en entreprise mais ça ne passe pas à l'échelle, et ce n'est pas durable. Il faut considérer ces ouvertures comme un besoin qui a un début, une fin, et un responsable qui ne doit pas être l'équipe réseau, mais l'entité qui a réellement le besoin de cette ouverture de flux. L'équipe réseau n'est que l'intermédiaire technique qui permet d'implémenter le besoin demandé, et le décommissionner à la fin. Elle n'a pas à répondre du bien fondé des règles implémentées, et n'est pas responsable en cas de faille de sécu créée par une demande d'ouverture trop large (de même que l'équipe infra qui installe des serveurs ou des ESX n'est pas responsable si un utilisateur de ces systèmes installe une appli trouée dessus)
- croire qu'un outil comme algosec ou tufin va être une solution avant même d'avoir bien compris le problème. Les vendeurs/intégrateurs aiment vendre ce genre de solution, ce sont des usines à gaz bien chères et bien complexes à implémenter, on vend du rêve aux décideurs en leur disant que ça va accélérer les process de mise en prod, on fait signer un gros chèque... et après 2 ans et un nombre incalculable de JH passé dessus, on na l'a toujours pas mis en prod. Parce qu'on s'est concentré sur le problème technique (traduire une demande dans un formulaire web en une suite d'appels API qui vont ouvrir le flux) en oubliant le problème organisationnel, qui était pourtant le plus important. Je ne dis pas que ces outils ne peuvent pas avoir leur utilité, mais à mon avis il faut vraiment se poser la question (ie bien comprendre son besoin avant de parler à un commercial/avant vente de ce genre de produit), car les implémenter prend énormément de temps et ils ne résolvent qu'une partie du problème.

Concernant ta remarque "sans rendre infernal un firewall avec une règle par port" : ce n'est infernal que si le contenu de ton firewall est ta source de vérité. Si cette dernière était ailleurs (idéalement dans une CMDB ou équivalent, mais ça peut aussi être dans un excel pour commencer), ça n'aurait plus aucune importance qu'il y ait une règle par port dans le firewall. De même que quand tu utilises ton PC tu ne te soucies pas de savoir comment tes données sont stockées dans les différentes puces de ton SSD, tout ce que tu veux c'est retrouver ton arborescence de répertoires/fichiers. Ce qui t'intéresse et ce avec quoi tu interagis, c'est l'interface haut niveau.

D'une manière générale on peut décomposer le process en plusieurs éléments :
- un référentiel qui modélise le SI, du plus bas (l'infra) au plus haut (spécifique à l'activité de l'entreprise et compréhensible par les demandeurs)
- un process qui fait la traduction entre le besoin métier exprimé (exemple "je veux que l'entreprise partenaire toto puisse joindre le frontend de notre appli tutu" ) en des termes réseau ("ouvrir les flux depuis le VPN toto vers les machines A B et C sur le port 1234, sur les clusters firewalls titi et tata" )
- un process qui implémente le résultat de l'étape précédente sur les firewalls, en sachant gérer les différents cas d'erreurs possibles et en permettant aussi bien au demandeur qu'à l'équipe réseau/sécu d'avoir un retour clair sur les actions qui ont été faites, à quel moment et avec quel résultat

Des points de vue de gens plus compétents que moi (et qui parlent un peu plus de technique) si ça peut être utile :
https://blog.ipspace.net/2019/01/fi [...] th-ci.html
https://blog.ipspace.net/2019/04/au [...] ewall.html

Une autre source d'inspiration sur le concept général peut être les AWS, Azure GCP et autres qui ont effectivement mis en place exactement ça : un système qui permet de gérer les ouvertures de flux à très grande échelle. Et ce n'est pas une coïncidence s'ils ont à la fois une modélisation de l'orga humaine (les rôles avec différents droits), un responsable identifié pour chaque ressource consommée, et un moyen effectif de le responsabiliser pour qu'il ne fasse pas n'importe quoi (en l'occurence c'est la facturation, mais à plus petite échelle dans une entreprise on pourrait imaginer d'autres choses).

   
Merci connaissais pas du tout !
 

 
 
Salut, alors déjà pour ta réponse super précise!
 
C'est effectivement totalement l'idée de splitter la problématique en deux, très clairement le besoin actuel c'est du temps, actuellement le client X va envoyer ses flux à l'arrache, rien ne sera normé et le SI derriere interprète et effectue les ouvertures de ports. Le soucis c'est que ça charge énormément pour des tâches peu valorisantes dès qu'on a un nouvel applicatif qui débarque. La forme est quasi exclusivement du Excel de ce côté là, et je pense qu'avec des query sur les API des matos je pourrai m'en sortir (quid de l'exposition de l'API dans ce cas ?     ) La technique ne sera pas vraiment le soucis (sauf sur des détails comme tu le dis, les APIs des anciens matos Citrix pour certains matos j'en fais encore des cauchemars     )
 
Les équipes SI sont demandeuses, le client l'est implicitement en souhaitant de la rapidité et aucune erreur.
 
Toutes les SI sont matures, fixes et peu évolutives, pas de risque de changement drastique car l'infra est moderne.
L'idée étant surtout d'appliquer un process X qui tournerait avec une première API, et si on voit que le besoin est vraiment présent, continuer à développer la chose (car dans des SDWAN complexes, c'est rarement qu'une ouverture de flux   )
 
Concernant ta remarque "sans rendre infernal un firewall avec une règle par port" : ce n'est infernal que si le contenu de ton firewall est ta source de vérité. Si cette dernière était ailleurs (idéalement dans une CMDB ou équivalent, mais ça peut aussi être dans un excel pour commencer), ça n'aurait plus aucune importance qu'il y ait une règle par port dans le firewall. De même que quand tu utilises ton PC tu ne te soucies pas de savoir comment tes données sont stockées dans les différentes puces de ton SSD, tout ce que tu veux c'est retrouver ton arborescence de répertoires/fichiers. Ce qui t'intéresse et ce avec quoi tu interagis, c'est l'interface haut niveau.
-> Pour cette partie, tous nos FW sont accédés par leur biais ou des services tiers de management du fournisseur, ainsi, on se débrouille avec les objets etc pour ranger mais c'est un foutoir monstre car ce n'est pas fais pour   Cependant, j'ai les mains liés sur ça, il faut quelque chose d'humainement maintenable simplement, ce qui n'est pas impossible, mais pas simple non plus.  
Cependant, nous possédons une CMDB, si tu as des idées/ressources sur des gestion externalisée et simplifiée pour des FW, je suis totalement preneur !  
 
 
Les deux liens que tu m'as envoyé sont fort intéressant, je ne connaissais pas du tout ce blog je vais découvrir ceci avec beaucoup de plaisir    
Effectivement côté Cloud Public et autres grosses distros, il y a moyen de s'en inspirer sur les bords, mais les échelles sont différentes    
 
 

 
Tout le monde est demandeur de progrès, mais sont-ils prêts à accepter les contraintes qui vont avec ? ie probablement des demandes formulées de façon plus stricte, et la responsabilité de gérer des cycles de vie au lieu de demandes one-shot (parce que sinon, automatisation sans contrainte, tu vas te retrouver avec encore plus de merde à traiter à la fin). C'est je pense un vrai sujet et plus généralement ça permet de se demander à quoi pourrait ressembler l'interface entre les clients et les implémenteurs (aujourd'hui c'est un excel si je comprends bien, demain tu voudrais remplacer ça par une API que tu leur exposes ? Quelles données y aurait-il dans le payload des requêtes, comment seraient-elles validées ? etc)
 
 

 
Je ne comprends pas cette partie, c'est quoi votre mode de fonctionnement actuel ?
 
 

 
Est-ce que tout ce dont tu aurais besoin pour construire tes rulesets de firewalls est présent dans ta CMDB ? Sinon il te manquerait quoi, et vois-tu une manière de palier ce manque ? par exemple faire du dev pour faire évoluer ta CMDB, ou avoir accès aux infos qui manquent dans une autre source de vérité tel qu'un annuaire corporate ou une appli métier tierce. En fait on appelle parfois ça une single source of truth mais ça ne veut pas dire que toute l'info nécessaire doit être dans un unique outil, mais plutôt qu'une info donnée doit se trouver dans un et un seul référentiel, qui fait donc autorité sur cette info.  
Par exemple sur un job précédent d'avais automatisé certaines parties des règles firewall, et pour certains cas j'avais des groupes de serveurs dont le contenu était pompé directement dans l'active directory (parce que le use case était à destination des admin windows justement), du coup les utilisateurs n'avaient même pas à faire de demande, les groupes d'objets firewalls se mettaient à jour tout seul quand ils changeaient l'AD, c'était transparent pour eux (et en contrepartie le jour où ils mettent de la merde dans leurs groupes, c'est leur problème pas le mien).
 
 

 
Oui c'est un très bon blog Cependant son auteur a mis fin a son activités de vidéos de formation fin 2023, je ne sais pas si ça veut aussi dire qu'il va arrêter son blog, j'espère que non...

 
En fait nous sommes une ESN ( ou SSII pour les nostalgiques ), actuellement le client envoies sa matrice Excel faite à l'arrache dans un ticket et nous on va sur le(s) Firewall(s) et on met tout à la main en faisant des objets, groupes, etc. puis on cloture le ticket en mettant des commentaires.
On utilise une plateforme de ticketing bien connu qui est une usine à gaz gigantesque, on peut gérer du formulaire custom de côté là, mais c'est vrai que par soucis de praticité, j'aurai aimé rester sur de la matrice type Excel (ou un form développé à la main, c'est pas vraiment un soucis ! ).
Je ne voudrai pas dénaturer le client qui remplit sa matrice et nous l'envoi (ou alors qui remplirait un form online), juste la rendre plus normée afin que lui ne rentre rien "à la main et à l'arrache". De notre côté les tech rentreraient la matrice dans un moulin qui feraient des requests sur les firewalls.
 
La partie validation serait dans un premier laps de temps humaine mais avec des vérifs dans un backend avant les requetes vers les firewalls, (notamment éviter les boucles, répétitions, les any partout etc). Je voudrai surtout ajouter une gestion logique pour nous humain, des objets et groupes propres, mais ça      
 

 
Ma CMDB est actuellement vierge de chez vierge, rien ne concerne les FW, et c'est - je trouve - un vrai soucis justement. Le seul moyen actuel que j'ai pour récupérer de la data c'est les APIs des FW en eux-mêmes.  
Intéressant ta partie sur l'Active Directory, je vais garder ça dans un coin de ma tête, merci  
 

 
Effectivement très sympathique.
 
Sans indiscrétion, quel job occupes-tu ?  

Outil de ticketing genre JIRA ?
Tu dois pouvoir récupérer le excel via un call API, comme ça le process côté client n'est pas trop changé pour le moment, mais toi tu peux déjà commencer l'automatisation en passant le excel dans une moulinette et en détectant les problèmes les plus faciles (champs obligatoire vide ou ce genre de truc), et même éventuellement répondre automatiquement au client dans ce cas via le ticket.
Il y a forcément une phase un peu difficile où il va falloir demander au client de faire des efforts sur ses demandes, ça se passera d'autant mieux si tu :
- te concertes bien avec lui pour établir les règles/format du document attendu
- fais en sorte que ta moulinette lui fasse un retour le plus clair possible sur le problème rencontré quand il y en a un
- lui fais bien comprendre qu'à terme il gagnera du temps sur ses demandes

Une fois que tu as avancé un peu sur ce process et que tu reçois des excel exploitables, tu peux faire générer à ta moulinette une config/suite de commandes à faire relire par un opérateur et balancer dans le firewall manuellement (ça reste manuel mais ça fait gagner du temps et ça limite les erreurs humaines, tout en n'étant pas non plus en mode "full auto" qui peut te péter ton infra). Et enfin une fois que tout est rôdé, faire en sorte que la moulinette aille jusqu'à modifier les firewalls directement. Avec les nouveaux problèmes à gérer que ça pose : comment on gère si le firewall répond une erreur ou ne répond plus, comment revient-on en arrière si besoin etc.
Mais en plus des problèmes ça offre aussi des opportunités, par exemple tu peux dans la foulée faire des tests automatisés pour valider le bon fonctionnement, que ce soit des tests liés au nouveau flux qui vient d'être implémenté ou supprimé, ou un jeu de test de use cases basiques joués systématiquement pour vérifier que l'infra n'est pas pétée, ou si tu veux vraiment aller loin, un test spécifique à chaque ouverture de flux (défini dans le même excel que la demande d'ouverture), qui permet à tout moment de valider tous les flux qui sont censés fonctionner. Bien sûr ça demande d'avoir accès aux machines concernées (ou des machines de tests dans les mêmes réseaux/environnements, on avait mis en place ce genre de truc à un job précédent). Un autre angle d'approche de la validation du fonctionnement est de surveiller les logs firewall (toujours de façon automatisée) pour voir si des flux importants n'ont pas cessé brusquement après le changement des règles. C'est un peu moins déterministe mais dans certains cas ça peut faire l'affaire quand même.

Oui à mon avis garder sa source de vérité dans les équipements ça montre ses limites à un moment.
Mais l'impression que j'ai c'est que pour mettre en place une meilleure solution (qui va coûter cher à implémenter, au moins en termes de JH) il faut avoir une idée assez claire de ce dont on a besoin, et ça c'est plus facile quand on a déjà nettoyé/simplifié ses process (interface avec le client, workflow d'un change etc, bref ce que je disais juste au dessus).
Donc pour moi c'est un but à garder en tête, mais pas forcément le premier truc sur lequel travailler activement.

J'ai bossé une dizaine d'années dans des boîtes de taille moyenne (1000-5000 personnes) où j'étais en charge des sujets réseau, et en plus de mon boulot d'ingé réseau classique j'ai eu l'occasion d'automatiser pas mal de choses, parcs de switchs, firewalls, systèmes de logging, outils de supervision etc. Dernièrement je bosse dans une grosse boîte française dans une petite équipe qui développe justement un système d'automatisation des configurations (5-10k devices, une centaine de sites), pour l'instant surtout du switch et du routeur mais là on s'attaque à la gestion des règles firewall justement, jusqu'à présent on marchait avec du excel sur la partie firewall mais là on est en train de sortir la modélisation de tout ça, avec un outil graphique pour que le client puisse faire clic-clic sur une interface qui ressemble à son réseau (qui référence des termes haut niveau qui parlent au client, ie des applications ou des VPNs, pas des adresses IP ou des noms d'interface) et que nous en backend on génère et implémente les règles correspondantes aux flux demandés. Mais on ne peut se permettre de se lancer là-dedans que parce que le reste du réseau est déjà très bien modélisé et que si on reçoit une demande pour que l'appli toto cause à l'appli tutu, on a déjà dans notre référentiel toutes les infos pour déterminer quelles actions sont à faire sur quels firewalls et routeurs, il faut juste pondre le bout de script qui fera effectivement les actions.

Salut à toi,
Merci de ton retour très précis.
 
J'ai échangé à propos de l'utilisation de la CMDB, j'utilise Service Now qui est je pense un des plus connus mais une des plus grosses machines à gaz haha.. J'ai vu que des "modules" FW existent, je vais voir ce que je peux faire de ce côté là et échanger peut-être avec leurs équipes au besoin.
 
En fait de ce que je m'en rends et comme tu l'as souligné, c'est loin d'être un soucis technique, c'est un soucis organisationnel en tout point !  
 
 
Concernant la partie de l'effort du client c'est malheuresement évident, mais on y passe tous j'ai envie de dire..
Concernant la surveillance, une bête surveillance des flux avec un trafic > à X peut-être faite, ce qui m'embête plus c'est de transformer la chose en passoire ou que la "crasse" s'accumule avec le temps, même si une rétention peut se mettre en place.
 
 
Enfin concernant ton dernier point, tu es totalement un profil qui va dans le sens de ce que je veux faire sur ce projet, c'est très intéressant d'échanger avec toi je t'en remercie.
Le soucis est que le réseau des clients ne sont pas forcément modélisés ou sujets à évolutions pour de nouveaux projets, services, segments, etc. Ce qui in fine doit être facilité justement par le projet que je veux mettre en place.