Cas client

Introduction

Le choix du support d’hébergement s’est porté sur un cluster de serveurs physiques hébergeant des serveurs virtuels (hyperviseur de type 1). Les serveurs virtuels (ou machines virtuelles) permettent la segmentation système et réseaux des différents services qui y sont hébergés ainsi qu’une facilité d’administration et de configuration. Enfin, la segmentation système des services facilite leurs sauvegardes et réplications dans l’objectif de mettre en place une haute disponibilité active/passive.

Le cluster doit être accessible depuis Internet (réseau Wide Area Network – WAN) afin d’héberger les sites publics (site vitrine, boutique, etc). Il doit également être accessible depuis le réseau interne (réseau Local Area Network – LAN) afin d’héberger les services internes (applications métiers, drive interne, etc.).

Enfin, une sauvegarde journalière des machines virtuelles est réalisée et conservée sur un serveur dédié et distant. L’objectif du serveur distant est de sauver les données de l’entreprise en cas de sinistre.

La section suivante décrit l’architecture de haute disponibilité choisie pour le client, permettant d’assurer la disponibilité des services principaux (sites publics et services internes) en cas de défaillance d’un serveur physique ou d’un serveur virtuel.

Architecture de Haute Disponibilité (HA)

La création d’un cluster de haute disponibilité nécessite un minimum de trois nœuds (serveurs physiques) afin d’obtenir un quorum (nombre minimum de nœuds actifs permettant d’obtenir un état de cohérence du cluster). 

Le cluster est de type Actif-Passif, c’est-à-dire qu’en cas de défaillance d’un nœud, les services présents sur celui-ci sont redémarrés automatiquement sur un autre nœud. Pour ce faire, les machines virtuelles présentes sur un nœuds sont régulièrement répliquées sur les autres nœuds.

Voici l’architecture minimale requise pour un cluster de ce type :

La communication inter-nœuds et la réplication des machines virtuelles sont réalisées sur un réseau dédié de haut débit (10GbE). Le commutateur SW_HA permet l’interconnexion de ce réseau entre les nœuds.

Dans cette architecture, deux Points de Défaillance Unique existent :

• L’accès réseau du Fournisseur d’accès à Internet (FAI) ;
• Les commutateurs réseau SW_WAN, SW_LAN et SW_HA pouvant être rapidement remplacés par un commutateur en réserve.

Étant donné le coût d’abonnement à un second accès Internet auprès d’un second FAI, le client accepte le risque.

L’architecture réseau est basée sur l’utilisation des Virtual LAN (VLAN), qui sont des réseaux locaux virtuels au sein d’un réseau local (LAN). Ainsi, sur un même lien réseau physique, plusieurs réseaux locaux indépendants coexistent. Les VLANs permettent la segmentation réseau.

L’architecture suivante segmente le réseau en cinq zones distinctes :

• Zone démilitarisée 1 (DMZ1) – Réseau d’hébergement des services ouverts sur Internet (site, boutique, etc.) ;
• Zone démilitarisée 2 (DMZ2) – Réseau d’hébergement des bases de données utilisées par les services en DMZ1 ;
• Zone de réseau interne (INTERNE) – Réseau d’hébergement des services internes (non ouvert sur Internet), des utilisateurs et périphériques de l’entreprise ;
• Zone de réseau invité (INVITE) – Réseau dédié pour les visiteurs utilisant le Wi-Fi invité ;
• Zone de réseau d’administration (ADMIN) – Réseau dédié pour l’administration de l’ensemble des systèmes.

Les communications entre les zones sont restreintes par des règles de pare-feu précises. Par exemple, la zone DMZ1 peut uniquement communiquer avec Internet et la zone DMZ2. La zone DMZ2 est isolée de toute communication vers l’extérieur. Ainsi, en cas de compromission d’un serveur exposé sur Internet, l’attaquant ne pourra pas se propager sur le réseau interne.

Nous retrouvons sur le schéma les éléments suivants :

• Les serveurs applicatifs SRV_DMZ1, SRV_DMZ2 et SRV_INTERNE ;
• Le serveur des bases de données des services publics DB_DMZ2 ;
• Les points d’accès wifi AP_INVITE et AP_INTERNE ;
• Le pare-feu FW ;
• Les stations de travail et périphériques du réseau interne.

Monitoring

Une architecture de centralisation des journaux système permet d’avoir un retour en temps réel de l’état des services et serveurs.  Ici, un ensemble de serveurs de centralisation des journaux (en orange sur le schéma) collectent les journaux des différents serveurs et périphériques présents sur chaque zone réseau. Les journaux collectés sont centralisés sur un serveur de monitoring (tel que la suite Elastic) afin de les traiter (statistiques, graphiques, alertes, etc.).

Nous retrouvons en orange sur le schéma les serveurs de journalisation LOGS_DMZ1, LOGS_DMZ2 et LOGS_INTERNE qui retransmettent les journaux vers le serveur de monitoring (elastic).

Sécurité

Cette architecture permet également l’installation d’outils de sécurité afin de détecter des comportements anormaux sur le réseau ouvert sur Internet. Des outils de Détection et de Prévention d’Intrusions (IPS/IDS) tels que Crowdsec analysent les journaux et lèvent des alertes en cas de détection de signatures caractéristiques d’attaques. Crowdsec permet également de restreindre l’accès à une liste communautaire d’adresses IP connues pour être malveillantes. 

La mise en place de Crowdsec passe par l’utilisation d’un proxy inverse (en orange sur le schéma), permettant de créer un point d’entrée unique pour les trames réseau provenant d’Internet et d’y appliquer les décisions prises :

Les décisions appliquées sur les adresses IP suspectes vont du simple blocage par captcha (pour différencier un humain d’une machine) au blocage temporaire ou définitif de l’accès. Les décisions sont régulièrement remontées auprès de l’API centrale de Crowdsec permettant de participer à la liste communautaire d’adresses IP malveillantes.

Conteneurisation

Une grande partie des sites et services hébergés sont conteneurisés grâce à la technologie Docker. La conteneurisation permet de créer des environnements isolés du système hôte (appelés conteneurs). Ainsi, plusieurs applications nécessitant des environnements système complètement opposés peuvent fonctionner sur le même serveur hôte, sans impact ni conflit avec ce dernier. Le système hôte ne devient alors qu’un support d’hébergement de conteneur.

La conteneurisation permet donc une grande souplesse et facilite l’administration et le déploiement de services. De plus, si la technologie est correctement utilisée et configurée, elle ajoute une couche supplémentaire de sécurité.

Public Key Infrastructure 

Lors de l’hébergement de services Web dans un réseau local d’entreprise, un Domain Name Server (DNS) interne est configuré afin de résoudre les noms d’hôtes internes (exemple : app.entreprise.corp). Ainsi, afin d’établir des connexions sécurisées et de confiance vers ces noms d’hôtes, une Public Key Infrastructure (PKI) doit être mise en place afin de créer une arborescence de certificats SSL d’autorités, intermédiaires et de services/utilisateurs. 

Une PKI est une chaine de confiance arborescente de certificats dont chaque certificat est signé par le certificat intermédiaire du niveau supérieur. Lorsque le certificat public d’autorité est installé sur un périphérique, celui-ci peut alors établir une communication de confiance avec un pair utilisant un certificat provenant également de la PKI.