Groupes de sécurité et pare-feu cloud : trois erreurs qui exposent un serveur
Un serveur cloud ne devient pas joignable par accident : il le devient parce qu'une règle l'a autorisé, souvent pour dépanner, et que personne ne l'a retirée. Les trois erreurs décrites ici partagent la même cause, une ouverture décidée dans l'urgence et jamais revue, et se corrigent dans un ordre précis, sinon la fermeture coupe le service.
Le mécanisme : des règles attachées à une machine
Dans une offre cloud, le pare-feu se présente comme un groupe de règles attaché à une ou plusieurs machines. Le filtrage tient compte de l'état des connexions : une connexion sortante autorisée laisse revenir le trafic correspondant sans règle supplémentaire. Les règles décrivent donc des flux, pas des paquets isolés, et une machine peut porter plusieurs groupes à la fois.
Deux modèles coexistent selon l'offre. Certains moteurs lisent les règles par priorité et s'arrêtent à la première correspondance, refus compris. D'autres n'acceptent que des autorisations : chaque règle est examinée et la plus permissive l'emporte pour un flux donné. Dans les deux cas, attacher deux groupes à la même machine revient à faire l'union de leurs autorisations. Ce point se vérifie dans la documentation de l'offre utilisée avant de conclure qu'une règle en cache une autre.
Première erreur : la règle par défaut qui accepte
Le groupe créé par défaut à l'ouverture du compte, ou celui recopié d'un tutoriel, autorise parfois tout le trafic entrant. On le garde parce que le serveur répond, puis on empile les règles métier par-dessus. Le modèle est alors inversé : ce qui n'est pas interdit passe. L'ANSSI décrit l'inverse comme la base, un modèle positif où tout ce qui n'est pas explicitement autorisé est interdit, et demande une règle finale de refus, explicite et journalisée, car le refus implicite de certains équipements ne laisse aucune trace.
La seconde source d'exposition est la sortie. Beaucoup d'équipes laissent le serveur sortir partout, en jugeant le risque théorique. Une machine compromise peut alors joindre un serveur de collecte, envoyer des données ou balayer le réseau interne sans qu'aucune règle ne s'y oppose. Restreindre la sortie aux dépôts de paquets, à la résolution de noms et aux services réellement appelés demande une soirée d'inventaire, et transforme une intrusion en incident bruyant.
Deuxième erreur : ouvrir une plage au lieu d'une adresse
L'ouverture large arrive presque toujours pour une bonne raison apparente : l'adresse du bureau change, le prestataire annonce une plage, le lien du moment passe par un réseau mobile, et la console refuse un nom d'hôte. On saisit alors un bloc entier, parfois toutes les adresses, sur le port d'administration. Le service fonctionne et l'incident futur est silencieux : les journaux de connexion se remplissent, sans distinguer l'administrateur d'un inconnu qui a trouvé le port.
La correction commence par une question posée au fournisseur d'accès ou au prestataire : quelle adresse de sortie voyez-vous réellement. Une réponse en plage se traduit en liste d'adresses, pas en bloc. À défaut, une machine passerelle, dont l'adresse est fixe, porte l'accès d'administration, et les autres machines n'acceptent ce port que depuis cette adresse. Le principe du moindre accès s'applique à la lettre : une adresse source, un port, un protocole.
Troisième erreur : test et production dans le même groupe
Un groupe de sécurité décrit une zone de confiance. Y attacher l'instance de recette le temps d'une mise en production revient à déclarer que cette machine mérite les mêmes accès que la production, alors qu'elle est moins surveillée, moins corrigée, et souvent dotée d'un mot de passe de démonstration. La règle de production qui autorise la base de données s'applique alors à elle. Une faille sur la recette ouvre la base sans qu'aucune règle n'ait été modifiée.
La séparation utile est double : celle des groupes et celle du réseau. Un groupe par environnement, nommé sans ambiguïté, et un segment distinct quand l'offre le permet, pour que la production ne soit pas joignable depuis la recette autrement que par un flux nommé. L'ANSSI place ce cloisonnement parmi les mesures de base, avec un réseau dédié à l'administration. Une machine de test qui doit lire des données lit une copie, jamais l'original.
Auditer l'existant avant de toucher aux règles
L'audit se fait sur deux sources, et non sur la seule console. La première est la politique telle qu'elle est écrite : règles désactivées, objets déclarés et jamais utilisés, doublons, règles sans commentaire, autorisations sur toutes les adresses. La seconde est le journal des flux, qui dit ce qui a réellement été accepté et depuis quelles adresses. L'ANSSI propose cette lecture croisée pour repérer les règles inutilisées et les règles redondantes, et fixe une revue au moins annuelle, biannuelle de préférence.
Trois questions suffisent à trier. Quelles machines partagent un groupe, et lesquelles n'ont rien à y faire. Pour chaque règle d'administration, quelles adresses sources ont été vues dans les journaux sur la période. Quelles règles n'ont produit aucune connexion, et qui les revendique. Une règle que personne ne revendique et qui n'a rien journalisé est un candidat sérieux à la désactivation. Vérifier depuis l'extérieur que seuls les ports attendus répondent complète le tableau, avec une autorisation écrite.
Corriger dans l'ordre, sans couper le service
Commencer par sauvegarder. Exporter la politique complète, vérifier que la restauration fonctionne, et savoir qui rétablit quoi en cas d'erreur. Ensuite seulement, la mise en conformité : traiter les règles désactivées, supprimer les objets inutilisés, renommer selon une convention lisible. Ces opérations ne changent aucun flux. C'est l'étape que l'ANSSI place en premier, précisément parce qu'elle est sans risque et qu'elle rend la suite compréhensible.
Le resserrement vient après, règle par règle, en s'appuyant sur les adresses observées dans les journaux de la règle elle-même : on ajoute les adresses réellement vues, on vérifie que l'ancienne règle cesse de produire des événements, puis on la désactive. La désactivation se fait par petits lots, avec la date et le motif inscrits en commentaire, et la règle reste en place quelques semaines avant suppression. La règle finale de refus, journalisée, montre alors ce qui a été bloqué.
Ce cycle ne se termine pas. Une revue périodique des groupes, la journalisation des refus et un inventaire des flux à jour valent mieux qu'un audit unique suivi d'un retour aux habitudes. C'est le travail d'exploitation courante que décrit l'infogérance cloud : un contrôle qui se vérifie, avec une date et un responsable.