Sécurité Zero Trust sur les serveurs Bare Metal

Pourquoi la sécurité périmétrique traditionnelle ne marche pas sur les infrastructures dédiées

Un serveur dédié typique est protégé par un pare-feu qui autorise le trafic provenant de ports spécifiques. Une fois que le trafic atteint le serveur, les services internes communiquent souvent entre eux sans authentification supplémentaire. MySQL écoute sur le port 3306 et accepte les connexions provenant du réseau local. Redis est accessible à tous les processus s'exécutant sur le serveur. Le code de l'application s'exécute avec des autorisations étendues sur le système de fichiers.

Ça marche bien jusqu'à ce que quelque chose à l'intérieur du périmètre soit compromis. Un shell web téléchargé via un WordPress vulnérable peut maintenant accéder directement à MySQL. Un processus d'application compromis peut lire des fichiers appartenant à d'autres applications. Le périmètre a tenu bon, mais pas l'intérieur.

Le modèle « zero trust » résout ce problème en supprimant complètement le concept de « confiance interne ». Chaque demande d'accès, qu'elle provienne d'un utilisateur externe ou d'un service interne, est authentifiée, autorisée et enregistrée.

Contrôle d'accès basé sur l'identité pour les services

Le principe de base du « zero trust » au niveau des services, c'est de s'assurer que les services s'authentifient entre eux, pas seulement auprès des utilisateurs externes.

Accès à la base de données: MySQL ne devrait pas accepter les connexions provenant de 127.0.0.1 sans identifiants limités aux autorisations minimales nécessaires. Créez des utilisateurs de base de données spécifiques à l'application plutôt que d'utiliser root :

— Crée un utilisateur pour l'appli avec juste les droits nécessaires.

Créer un utilisateur « nom_de_l'application »@« 127.0.0.1 » avec le mot de passe « mot_de_passe_fort_aléatoire » ;

GRANT SELECT, INSERT, UPDATE, DELETE ON appname_db.* TO ‘appname’@’127.0.0.1’ ;

Vider les privilèges ;

— Vérifier les privilèges

Afficher les autorisations pour « appname »@« 127.0.0.1 » ;

L'appli web se connecte sous le nom appname et peut seulement accéder à appname_db. Même si ces infos d'identification sont exposées, les dégâts sont limités à une seule base de données.

Accès Redis: par défaut, Redis accepte toutes les connexions sans authentification sur localhost. Active l'authentification dans /etc/redis/redis.conf :

tu dois passer ton mot de passe Redis super fort

lier 127.0.0.1

Avec un mot de passe fort et une connexion limitée au bouclage, les connexions Redis ont besoin à la fois d'une proximité réseau et des bonnes informations d'identification.

Segmentation du réseau avec espaces de noms et VLAN

Pour les environnements multi-applications sur un seul serveur dédié, les espaces de noms réseau Linux permettent d'isoler les applications au niveau du réseau sans avoir besoin de matériel séparé :

# Create an isolated network namespace for an application

ip netns add appname_ns

# Create a veth pair (virtual ethernet cable)

ip link add veth0 type veth peer name veth1

# Move one end into the namespace

ip link set veth1 netns appname_ns

# Configure addressing

ip addr add 192.168.100.1/30 dev veth0

ip netns exec appname_ns ip addr add 192.168.100.2/30 dev veth1

# Bring interfaces up

ip link set veth0 up

ip netns exec appname_ns ip link set veth1 up

Les processus qui tournent dans l'espace de noms ne peuvent atteindre que les adresses réseau qui leur ont été configurées explicitement. Ils ne peuvent pas accéder directement aux bases de données ou aux services liés au réseau hôte sans passer par une passerelle contrôlée.

Pour simplifier l'isolation multi-locataires, les règles nftables peuvent appliquer des politiques de communication entre les applications sur le même serveur :

# Only allow MySQL connections from the application's specific process user (via UID match)

nft add rule inet filter output skuid 1001 tcp dport 3306 accept

nft add rule inet filter output tcp dport 3306 drop

Ça permet que les processus qui tournent sous l'UID 1001 (l'utilisateur de l'appli) puissent se connecter à MySQL — tous les autres processus sont bloqués au niveau du noyau.

Micro-segmentation pour le trafic intra-serveur

AppArmor (Ubuntu/Debian) et SELinux (RHEL/AlmaLinux/Rocky Linux) offrent un contrôle d'accès obligatoire au niveau du noyau, limitant les fichiers, les ressources réseau et les appels système auxquels un processus peut accéder, peu importe les permissions Unix.

Un profil AppArmor pour Nginx le limite aux ressources dont il a besoin :

/etc/apparmor.d/usr.sbin.nginx:

#include <tunables/global>

/usr/sbin/nginx {

  #include <abstractions/base>

  #include <abstractions/nameservice>

  capability net_bind_service,

  capability setuid,

  capability setgid,

  /var/www/** r,

  /etc/nginx/** r,

  /var/log/nginx/** w,

  /run/nginx.pid rw,

  # Deny everything else

  deny /home/** rwx,

  deny /root/** rwx,

  deny /etc/shadow r,

}

Avec ce profil activé, même si un pirate arrive à exécuter du code dans le Nginx , il ne peut pas lire /etc/shadow, accéder aux répertoires personnels des utilisateurs ou écrire en dehors denginx/. Le noyau applique ces restrictions, peu importe ce que le code du pirate essaie de faire.

La doc AppArmor explique comment créer des profils et les modes d'application. Commence par le mode « complain » (qui enregistre les violations sans bloquer) pour vérifier ton profil avant de passer au mode « enforce ».

Accès zéro confiance pour l'accès administratif

Appliquer le principe du « zero trust » à l'accès SSH, ça veut dire remplacer les identifiants statiques par des certificats à durée de vie courte et à identité vérifiée.

L'autorité de certification SSH HashiCorp Vault délivre des certificats SSH qui expirent après une durée configurable : 30 minutes, 1 heure, 8 heures. Un ingénieur s'authentifie auprès de Vault avec ses identifiants, reçoit un certificat SSH à courte durée de vie et l'utilise pour se connecter au serveur. Si le certificat est volé, il expire rapidement. Si l'ingénieur quitte l'organisation, la révocation de son accès à Vault met immédiatement fin à sa capacité à obtenir de nouveaux certificats.

La doc sur le moteur de secrets SSH de Vault explique comment configurer la vérification côté serveur et la délivrance de certificats client.

Pour les équipes qui ne sont pas encore prêtes à utiliser Vault, une façon plus simple d'améliorer la sécurité SSH avec le modèle Zero Trust, c'est d'utiliser une liste blanche d'adresses IP et de changer régulièrement les certificats:

# In /etc/ssh/sshd_config

# Match only connections from corporate VPN or jump host IP

Match Address 10.0.0.0/8

  PasswordAuthentication no

  PubkeyAuthentication yes

Match Address *

  DenyUsers *

Enregistrement et vérification en continu

La confiance zéro sans journalisation, c'est juste un espoir. Chaque décision d'accès a besoin d'une piste d'audit. Pour un serveur dédié :

Journalisation des accès SSH: vérifie que les journaux sshd sont enregistrés dans /var/log/auth.log (Debian) ou /var/log/secure (RHEL). Chaque tentative de connexion, réussie ou pas, avec l'adresse IP source et le nom d'utilisateur.

Journalisation des audits au niveau des applications: assurez-vous que votre application enregistre les actions des utilisateurs authentifiés, et pas seulement les requêtes. Enregistrez l'identité de la personne qui a effectué chaque opération, et pas seulement le fait que l'opération a eu lieu.

Envoi centralisé des journaux: les données des journaux stockées uniquement sur le serveur piraté peuvent être supprimées par un pirate. Envoyez les journaux vers un récepteur syslog distant ou un service de journalisation dans le cloud sur lequel le serveur ne peut pas écrire ni supprimer.

Vérification régulière des accès: tous les mois, vérifie toutes les clés SSH actives dans /root/.ssh/authorized_keys et dans ~/.ssh/authorized_keys de chaque utilisateur. Supprime les clés des anciens employés, des anciens sous-traitants ou des systèmes qui n'ont plus besoin d'accès.

Le Zero Trust, c'est un truc qui dure, pas juste un truc à mettre en place

Les entreprises qui ont la meilleure sécurité sur leurs infrastructures dédiées n'ont pas mis en place le modèle Zero Trust en un week-end. Elles ont commencé par les chemins d'accès les plus risqués (SSH, connexions aux bases de données) et y ont d'abord ajouté la vérification d'identité et la journalisation. Ensuite, elles ont continué en renforçant la communication entre les services et les contrôles d'accès au niveau des processus.

Le service géré Premier Care d'InMotion comprend la configuration de sécurité de base adaptée à un serveur dédié de production. Les équipes qui bossent sous des exigences de conformité strictes ou des modèles de menace (services financiers, soins de santé, données réglementées) ajoutent généralement des contrôles Zero Trust supplémentaires à cette base.

Lectures connexes: Meilleures pratiques pour renforcer la sécurité des serveurs | Stratégies de protection contre les attaques DDoS pour les infrastructures dédiées