Problématique de départ :

L’infrastructure actuelle sauvegarde les données des machines virtuelles vers le PBS qui les enregistre ensuite sur un seul et unique disque dur. Dans le cas où le disque dur ou le PBS vient à tomber en panne toutes les sauvegardes et toutes les données ne seraient plus accessibles, voire perdues.
De plus, il est vivement conseillé par l’ANSSI d’éviter au maximum l’accès aux données de sauvegarde ainsi qu’à la DMZ interne qui contient les services critiques du SI. Dans le cas d’une cyberattaque, la disponibilité, l’intégrité ou la confidentialité des données pourraient être mises en péril.

Résolution de la problématique :

Pour pallier aux problèmes cités précédemment, nous allons effectuer plusieurs tâches :

• Modification des ACL (ACCESS CONTROL LIST) de TrueNAS afin d’interdire tout le monde d’interroger le serveur TrueNAS en DMZ interne, sauf le PBS. Il sera le seul à pouvoir questionner le serveur TrueNAS pour envoyer les sauvegardes vers son stockage.
• Installation et configuration d’un Serveur TrueNAS dans la DMZ interne avec un stockage sur 3 disques en RAIDZ1 (Redundant Array of Independent Disks)(le RAIDZ1 est un équivalent du RAID5 sur un système de fichier ZFS (Zettabyte File System))
• Partage du stockage via NFS (Network File System) et SMB (Server Message Block). Et ajout du stockage en temps que Datastore sur le PBS.
• Ajout du nouveau datastore sur tous les hyperviseurs.
• Vérification de l’accès des machines virtuelles au datastore du PBS.
• Test d’une première sauvegarde manuelle d’une VM, ainsi que vérification de l’intégrité de la sauvegarde et de la possibilité de la restaurer.

Conclusion :

Cette modification apporte un nouveau niveau de sécurité du SI en cloisonnant un peu plus les systèmes critiques, la protection des données de sauvegarde face à la panne d’un des disques de stockage et/ou du PBS, un filtrage cohérent des accès aux données de sauvegarde et une rapidité de lecture et d’écriture sur le stockage supérieure à la configuration d’origine.

Problématique de départ :

L’infrastructure actuelle dispose d’un unique pare-feu hébergeant des services de routage, pare-feu, DNS (Domain Name System) et DHCP (Dynamic Host Configuration Protocol). Il assure le routage et le filtrage de toutes les communications de l’infrastructure.
Dans le cas d’une cyberattaque, il est le seul rempart vers l’accès au service critique de l’infrastructure. S’il est compromis, des attaquants pourraient avoir un accès direct à la totalité de l’infrastructure. Cela représente un risque pour la disponibilité, l’intégrité ou la confidentialité des données de l’infrastructure.
De plus, il est vivement conseillé par l’ANSSI (Agence nationale de la sécurité des systèmes d’information) d’éviter, dans un premier temps, la communication « directe » entre des services web et le reste de l’infrastructure, mais aussi plus globalement, d’éviter au maximum les échanges entre les services web de l’entreprise et les différentes DMZ qui peuvent contenir les services critiques du SI.

Résolution de la problématique :

Pour pallier aux problèmes cités précédemment, nous allons effectuer plusieurs tâches. Toutes ces tâches seront à effectuer en dehors des horaires de production car elles arrêtent tous les différents services :

Intégration de cette nouvelle machine à la politique de sauvegarde de l’entreprise, suivi d’une
sauvegarde manuelle et d’une vérification du bon fonctionnement de ladite sauvegarde.

Reconfiguration du Switch0 pour accueillir la nouvelle machine ainsi qu’appliquer de nouvelles règles de filtrage sur le port du Switch0 où est branché le PFsense primaire.

Installation et configuration du PFsense secondaire.

Migration d’une partie de l’adressage IP du PFsense primaire vers le PFsense secondaire (se référer au schéma antérieur et postérieur au projet). Migration du service DHCP.

Configuration de toutes les règles et les filtrages de communication sur les deux PFsense.

Vérification des communications autorisées mais aussi de celles interdites entre tous les différents éléments de l’infrastructure et de l’extérieur.

Conclusion :

Cette modification apporte un nouveau niveau de sécurité du SI en cloisonnant davantage les systèmes critiques, un filtrage plus important des communications entre la DMZ externe et le reste du réseau et les services web ne doivent pas communiquer directement avec le reste de l’infrastructure.