Infrastructure réseau
Dernière mise à jour
Cet article vous a-t-il été utile ?
Dernière mise à jour
Cet article vous a-t-il été utile ?
Dans l'infrastructure informatique d'une entreprise, il est presque systématique que plusieurs niveaux de confidentialité et/ou de privilèges existent. Certains services ne servent qu'aux administrateurs ou aux membres les plus hauts de la hiérarchie. Certaines données sont plus confidentielles et sensibles que d'autres. C'est pour cela qu'il est important de créer une compartimentation réseau de ces différentes zones opératoires.
On voit sur ce schéma ci-dessus que deux DMZ (sous-réseaux locaux cloisonnés par un pare-feu restreignant le flux réseau avec l'extérieur) existent. Une DMZ Admin et une DMZ contenant des services moins critiques en terme de compromission. Ce deuxième pare-feu entre ces deux DMZ permet d'apporter une couche de sécurité et de contrôle supplémentaire. En effet, même si une machine de la première DMZ est compromise, elle n'aura pas un accès réseau direct aux machines sensibles situées dans la DMZ Admin.
On peut également profiter de cette décomposition des accès en plusieurs sous-réseaux pour par exemple permettre l'accès à la DMZ Admin exclusivement via un VPN et donc rajouter une sécurité supplémentaire et de la traçabilité via le certificat VPN, deux notions cruciales que l'on aborde un peu plus bas.
Les failles existent et ne peuvent pas être évitées, en effet, même avec une infrastructure parfaite, composée exclusivement de services et de configurations sans aucune faille (ce qui est hautement improbable), l'erreur humaine et l'inattention est toujours possible. C'est pour cela qu'il est crucial d'aborder la sécurité en couches. Par exemple dans l'exemple ci-dessus, accéder au service Zabbix demande de s'introduire dans la première DMZ puis dans la seconde via le second pare-feu. Pour peu qu'un VPN soit de mise sur la seconde DMZ, il est presque impossible d'y accéder.
Lorsque quelqu'un effectue une action, que ça soit un client sur un site internet, n'importe quelle requête à un service, lorsque cette action est importante, généralement, elle se fait en étant authentifié. Cette authentification permet également d'identifié la personne réalisant l'action. Inutile de préciser pourquoi en réponse à incident, cela est indispensable. Si un attaquant effectue une action, alors remonter la cause du problème est bien plus facile si on sait quels accès il a utilisé, quel utilisateur a été compromis.
C'est pour cette raison que vous devez absolument générer un utilisateur par personne et éviter le plus possible les comptes mutualisés, utilisés par plusieurs personnes. Cette règle permet aussi d'ajouter de l'isolation, c'est à dire qu'on pourra plus facilement restreindre les permissions et les accès à chaque employé dans notre entreprise. Cela va avoir comme conséquence de minimiser le champs d'action de l'attaquant en cas de compromission du compte utilisateur.
Nous allons voir un peu plus bas que cette traçabilité sera précieuse en réponse à incident ou même en cas d'opérations de routine avec le monitoring. Sans pour autant s'être fait attaquer, lorsqu'un employé fait une manipulation accidentelle, c'est très pratique de pouvoir vérifier exactement quand et avec quel compte cette manipulation a eu lieu, et donc identifier avec précision l'employé concerné.
Maintenant que votre structure est établie, il faut sécuriser un maximum votre infrastructure en interdisant tout échange réseau sauf ceux qui sont strictement nécessaires au bon fonctionnement de votre infrastructure. C'est en procédant ainsi que vous allez éliminer au maximum le nombre de vecteurs d'attaques.
Par exemple pour la cartographie réseau présentée sur l'image précédente, voici une matrice de flux pertinente :
Web vitrine (443)
0.0.0.0/0
192.168.0.6
Web admin (4443)
192.168.0.0/24
192.168.0.6
VPN (8443)
0.0.0.0/0
192.168.0.5
Suricata (9443)
192.168.1.0/24
192.168.0.5
Zabbix (443)
192.168.1.0/24
192.168.1.2
Database (3306)
192.168.1.0/24 192.168.0.6
192.168.0.4
SSH (22)
192.168.1.0/24
192.168.0.0/24
SSH (22)
192.168.1.0/24
192.168.1.0/24
En cybersécurité, plus les choses sont claires et facilement vérifiables, mieux c'est. C'est pour cela qu'il faut tout noter, garder trace de tous nos scripts de déploiement, de nos informations d'utilisateurs et de toutes nos informations IT. La cartographie fait partie de ces informations. Voici ce que vous devez y noter :
Les routeurs, switch et tout autre instrument réseau.
Chaque serveur ainsi que les services qui tournent dessus.
Chaque connexion existante, qu'elle soit filaire ou wifi.
Toutes les IP statiques à côté de sa machine correspondante.
Toutes les plages IP des sous-réseaux.
Les services externes tels que des Cloud Azure ou AWS .
Les transferts de données de backup ainsi que leur fréquence.
Voici un exemple de cartographie. On peut voir qu'il manque pas mal d'informations par rapport à la liste précédente, mais si possible, mettez-les tout de même, elles sont importantes et tiennent toutes facilement sur un schéma lisible :
Il est très important en sécurité informatique d'effectuer une veille régulière pour surveiller les vulnérabilités potentiellement patchées avec les mises à jour des différents services utilisés dans notre infrastructure. Voici les 3 notions de veille les plus importantes :
Surveiller les EOL (End Of Life) des softwares utilisés car cela signifie souvent qu'aucun patch de vulnérabilité ne sera effectué si de nouvelles CVE surviennent. Fuyez à tout prix les services en EOL, ils sont dangereux car une vulnérabilité sera forcément trouvée car il en existe partout, la seule raison pour laquelle nous sommes en sécurité, c'est qu'elles sont patchées aussitôt rendues publiques. Ce qui n'est pas le cas pour les produits en EOL.
Faites régulièrement vos mises à jour. Il y a cependant deux subtilités à prendre en compte. Des fois les mises à jour sont foireuses et peuvent mettre votre activité en péril. Attendez donc que d'autres entreprises/utilisateurs fassent la mise à jour et assurez-vous que tout va bien de leur côté. Faites également des tests sur des serveurs de développement (pas en production). Deuxième subtilité, si vous avez des besoins et dépendances spécifiques qui casseraient en cas de mise à jour, vous pouvez patcher vous même les vulnérabilités corrigées dans la mise à jour de sécurité, c'est pas courant, mais ça peut arriver.
Si vous êtes obligés de travailler avec des systèmes vulnérables comme des logiciels sous Windows XP par exemple, alors isolez ces systèmes du réseau, ne les connectez pas au reste de votre parc informatique et évidemment, ne les exposés pas à internet. Ayez conscience des vulnérabilités présentes.
Effectuez vous même des tests d'intrusion en whitebox. Cela n'est pas suffisant, engagez également des entreprises externes pour réaliser des tests d'intrusion en blackbox, avec un scope plus ou moins large. Il y a forcément des choses qui peuvent vous échapper et une intervention externe est également un gage de professionnalisme aux yeux de votre entreprise et de confiance en votre infrastructure.
Pour que votre infrastructure réseau soit surveillée et que vous ayez une idée précise de ce qu'il s'y passe, il est crucial de mettre en place un système de monitoring des appareils réseau, des serveurs et des services. En effet, la collecte de logs est indispensable car votre infrastructure ne doit pas être aveugle !! Auquel cas, les conséquences lors d'une réponse à incident seraient catastrophiques. Il peut même s'avérer impossible dans certains cas de retrouver la source de l'intrusion et donc d'en empêcher une prochaine. C'est aussi très utile en cas d'incidents mineurs ou d'optimisation de notre infrastructure.
Le deuxième point important est le système d'alerte. En effet, on fait du monitoring, on a notre système de centralisation des logs, mais on ne va pas garder les yeux rivés dessus en permanence. Un système d'alerte pas notifications par exemple lorsque certains types de logs sont générés peut s'avérer très utiles.
Je conseille personnellement la suite d'outils développés par la communauté de . Je les trouve complet et en plein essor. Il y a évidemment d'autres solutions avec chacune ses avantages et inconvénients. J'ai par exemple entendu parler de , qui serait peut être plus facile pour la remise en forme des logs.
