CHAPITRE 6 : ANALYSE ET DISCUSSION
2. Objectifs
4.1 Architecture de l’environnement virtuel
Après avoir choisi d’utiliser OpenIndiana combinée à VirtualBox comme solution de virtualisation pour le déploiement du centre de données de BJNet, nous avons conçu l’architecture de l’environnement de virtualisation et proposer des recommandations pour le déploiement de celui-ci.
4.1 Architecture de l’environnement virtuel
A l’analyse de la topologie physique présentée à la figure 1.1, nous avons déduit une première architecture présentée à la figure 4.1 ci-dessous :
Figure 4.1: Première approche d’architecture
Comme on peut le voir sur la figure précédente, l’idéal pour la mise en place des serveurs aurait été que les serveurs physiques disposent de quatre interfaces réseaux ; chacune étant dédiée à chacun des quatre réseaux qui constituent le centre de données de BJNet.
Cette architecture a donc été modifiée au regard des points suivants :
Réalisé par Joris Dagbégnon FAGBEMIRO 44
1) Concernant le routage du trafic entre les 4 réseaux
Le serveur n’ayant qu’une seule interface réseau, on a deux options : le routeur qui s’en occupera peut être physique (comme sur la figure 4.1) et donc situé à l’extérieur du serveur ou il peut être virtuel et donc situé à l’intérieur du serveur.
Dans le premier cas, il faudrait utiliser les VLAN. Chaque réseau sera donc associé à un VLAN (les paquets provenant de ce réseau seront marqués avec l’identifiant de ce VLAN). Ainsi, si un serveur d’un VLAN doit joindre un autre serveur appartenant à un VLAN différent, le paquet devra passer par l’interface réseau du serveur pour aller vers le routeur avant de revenir par cette interface pour aller vers sa destination. L’interface réseau du serveur sera donc sollicitée six fois, pour le traitement d’une seule requête par exemple :
d’abord, lorsque la requête du client va vers l’un des relais dans l’une des DMZ ;
ensuite, lorsque le relais doit joindre le serveur concerné et envoie donc le paquet au routeur (les VLANs étant différents) ;
ensuite, lorsque le routeur doit envoyer ce paquet vers ledit serveur ;
ensuite, lorsque le serveur, après avoir généré la réponse la renvoie au relais en passant une fois encore par cette interface pour joindre le routeur ;
ensuite, lorsque le routeur envoie le paquet au relais et
enfin lorsque le relais répond au client.
Réalisé par Joris Dagbégnon FAGBEMIRO 45
Puisque les requêtes vers le centre de données seront nombreuses et simultanées, les performances de cette carte réseau seraient fortement diminuées.
La deuxième option, qui suppose la création d’une zone routeur, est donc la mieux adaptée au besoin d’utilisation efficiente de la bande passante offerte par la carte réseau.
2) Concernant l’interconnexion entre les cartes réseau virtuelles (VNIC25) des zones
Dans Crossbow, une VNIC est toujours liée à un lien de données (datalink) qui peut être une carte réseau physique (NIC) ou un etherstub (switch virtuel) (Nagarajayya, 2008). Donc pour interconnecter deux VNIC, il faut toujours un etherstub (Oracle, 2012).
3) Concernant la sécurité du trafic inter-zones
Certaines zones, dans un fonctionnement normal du centre de données, ne doivent pas initier de requêtes vers certaines autres zones. Par exemple, un relais HTTP ne doit pas initier de requêtes vers le serveur de bases de données situé dans le réseau de données critiques ; seuls les serveurs web et mail doivent y accéder. De telles requêtes peuvent donc être l’œuvre d’attaquants ayant pris le contrôle de ce relais web par exemple. Les pare-feux étant chargés de contrôler l’accès aux machines d’un réseau, le trafic venant d’une zone ou allant vers une zone doit donc toujours passer par eux.
A leur niveau, ils vérifient si les paquets respectent les règles de sécurité configurées ; si oui les paquets peuvent continuer, sinon ils sont supprimés.
25 VNIC : Virtual Network Interface Card
Réalisé par Joris Dagbégnon FAGBEMIRO 46
4) Concernant le réseau de données critiques
Une mesure supplémentaire de sécurité sera rajoutée à ce réseau, regroupant des serveurs sensibles, en ne le rendant pas directement accessible depuis l’extérieur du réseau du centre de données. Il ne sera donc pas directement connecté à la carte réseau physique. Les clients n’auront pas conscience de son existence et ce sont les DMZ qui se chargeront de transférer leurs requêtes.
5) Concernant le centre d’administration réseau
Les machines virtuelles qui hébergeront les systèmes d’exploitation adaptés aux outils prévus (Dude, Nagios et OpenVAS) seront créées dans VirtualBox, qui sera installée dans une zone (appelons la « zone_admin »).
Cette zone doit avoir les cartes réseaux nécessaires pour permettre la visibilité depuis l’extérieur du serveur et la connexion avec le reste du réseau du centre de données.
Nous avons deux options pour la création du centre d’administration réseau : on peut installer le pare-feu dans une zone et installer les machines abritant les outils d’administration dans une autre zone hébergeant VirtualBox ou installer lesdites machines et le pare-feu dans VirtualBox.
Dans le premier cas, la zone pare-feu aurait trois VNICs pour se connecter aux deux zones routeurs et à la zone où VirtualBox serait installé. Les machines créées dans VirtualBox devront être en mode “pont“26 sur la ou les VNICs de la zone hôte pour pouvoir communiquer avec le pare-feu. Or dans
26 Le mode pont est un mode réseau de VirtualBox où la carte réseau de la machine virtuelle est liée à la carte réseau de la machine qui héberge VirtualBox ; et la machine virtuelle apparaît dans le réseau auquel est connectée la machine hôte comme une nouvelle machine (Oracle, 2013). Ainsi la machine virtuelle peut avoir accès à Internet par exemple.
Réalisé par Joris Dagbégnon FAGBEMIRO 47
le mode pont, une VNIC doit être exclusivement dédiée à la machine virtuelle (Oracle, 2013). Alors, il faudrait autant de VNIC que de machines à créer.
Dans le second cas, le réseau entre le pare-feu et les machines clientes serait entièrement contenu dans VirtualBox et c’est le pare-feu qui sera connecté aux VNICs de la zone. Il faudrait donc dans ce cas, juste deux VNICs.
L’ajout de nouvelles machines au centre d’administration réseau ne nécessiterait pas la reconfiguration de la zone hôte et peut en outre permettre d’installer un pare-feu différent de celui de OpenIndiana (pfSense par exemple).
Nous avons donc choisi la seconde option.
En tenant compte des contraintes sus-citées, nous avons conçu l’architecture présentée à la figure 4.2.
Réalisé par Joris Dagbégnon FAGBEMIRO 48
Figure 4.2 : Architecture de l’environnement virtuel du centre de données de BJNet
Réalisé par Joris Dagbégnon FAGBEMIRO 49
Il convient, afin de mieux faire comprendre notre architecture, de faire les remarques suivantes:
a) Concernant la zone routeur 1 (zrouter1)
Elle est l’interface entre le réseau extérieur au centre de données et celui-ci. Elle se charge de router les requêtes des clients vers la DMZ concernée et ensuite de renvoyer la réponse ;
b) Concernant la zone routeur 2 (zrouter2)
Elle est chargée de router le trafic entre les zones. C’est donc par elle que les relais joindront les serveurs auxquels ils correspondent ; et que les outils d’administration joindront les machines à administrer.
c) Concernant les passerelles par défaut
Les passerelles par défaut, auxquelles les machines adresseront les paquets à destination d’un réseau qui leur est inconnu, sont réparties comme suit :
celles des serveurs, relais et des machines d’administration sont les pare-feux de leur réseau respectif ;
celle des pare-feux des DMZ et du centre d’administration réseau est la zone routeur 1 ;
celle du pare-feu du réseau de données critiques est la zone routeur 2 ;
et celle de la zone routeur 1 est le routeur physique auquel est connecté le serveur.
Réalisé par Joris Dagbégnon FAGBEMIRO 50
d) Concernant le centre d’administration réseau
VirtualBox voit comme cartes réseau physiques, les deux cartes réseau virtuelles créées pour la zone (zone_admin) qui l’héberge. Ainsi la machine virtuelle faisant office de pare-feu a aussi trois cartes réseau:
- l’une en mode “pont“ sur la carte réseau virtuelle de la zone, qui est connectée à la zone routeur 1 (et donc à l’extérieur) ;
- la seconde en mode “pont“ sur la carte réseau virtuelle de la zone, qui est connectée à la zone routeur 2 ;
- la dernière en mode “réseau interne privé“27 et reliée aux machines virtuelles hébergeant Nagios, Dude et OpenVAS.
Les cartes réseaux des machines Nagios, Dude et OpenVAS sont aussi en mode “réseau interne privé“.