Les pratiques opérationnelles qui exposent les organisations sans le savoir

Les comptes de service : une surface d'attaque structurelle

Les comptes de service — utilisés par les applications et les scripts automatisés pour s'authentifier sur les systèmes — constituent l'une des surfaces d'attaque les moins bien gérées dans les environnements d'exploitation. Ces comptes sont souvent créés pour un besoin spécifique, dotés de privilèges étendus par commodité, et jamais révoqués quand le besoin disparaît. Leurs mots de passe ne sont pas renouvelés régulièrement, parfois encodés en dur dans les scripts ou les fichiers de configuration. L'inventaire des comptes de service actifs dans un environnement d'exploitation mature révèle systématiquement des comptes orphelins dont la suppression réduit immédiatement la surface d'attaque.

Le partage de credentials : commodité et risque systémique

Le partage de credentials d'administration entre plusieurs membres d'une équipe est une pratique répandue dans les équipes d'exploitation sous pression. Elle est aussi fondamentalement dangereuse. Elle supprime l'imputabilité : quand un compte admin partagé effectue une action malveillante ou erronée, il est impossible d'identifier qui était connecté. Elle multiplie les surfaces d'exposition : chaque personne qui connaît les credentials est un vecteur potentiel de compromission. Et elle rend impossible la révocation ciblée en cas de départ d'un collaborateur ou de suspicion de compromission. Les solutions alternatives — PAM (Privileged Access Management), comptes nominatifs avec élevation temporaire — existent et sont matures.

Les mots de passe dans les scripts et fichiers de configuration

La présence de credentials en clair dans des scripts, des fichiers de configuration ou des repositories de code est une pratique opérationnelle héritée de l'époque où les systèmes de gestion des secrets (vaults) n'étaient pas disponibles. Ces credentials sont aujourd'hui accessibles à toute personne ayant accès au repository ou au système de fichiers, et parfois indexés dans des outils de recherche de code. Les solutions modernes — HashiCorp Vault, AWS Secrets Manager, Azure Key Vault — permettent de centraliser et de sécuriser les secrets sans les exposer dans les fichiers de configuration. Migrer les credentials existants vers ces solutions est une priorité pour les équipes d'exploitation soucieuses de leur posture sécuritaire.

Cas EU Renault (2017) — WannaCry avait exploité une vulnérabilité SMB pour se propager dans les réseaux industriels de Renault. La propagation rapide dans les usines avait révélé des pratiques d'exploitation caractéristiques des environnements OT : comptes administrateurs locaux avec des mots de passe identiques sur de nombreuses machines, absence de segmentation entre le réseau IT et le réseau industriel, systèmes non patchés depuis de longues périodes.

Les accès permanents : le risque de l'accès persistant

Les accès d'administration permanents — comptes toujours actifs avec des privilèges élevés — sont une pratique d'exploitation commode mais risquée. Le modèle d'accès juste-à-temps (Just-In-Time access) propose une alternative : les comptes admin n'ont des privilèges élevés que pendant la durée nécessaire à l'opération, avec une demande et une approbation formelles. Ce modèle réduit considérablement la fenêtre d'exposition en cas de compromission d'un compte. Son implémentation est facilitée par les solutions PAM modernes et ne nécessite pas de refonte complète de l'infrastructure — elle peut être déployée progressivement, en commençant par les systèmes les plus critiques.

La documentation lacunaire comme facteur de risque

Les équipes d'exploitation qui ne documentent pas précisément leurs systèmes ne peuvent pas évaluer leur surface d'attaque. Sans inventaire à jour des services actifs, des ports ouverts, des comptes existants et des flux inter-systèmes, il est impossible de savoir ce qui est potentiellement exposé. Cette lacune documentaire n'est pas un problème de conformité — c'est un problème opérationnel de premier ordre. Les équipes qui investissent dans la documentation de leur infrastructure ne le font pas pour les auditeurs : elles le font pour elles-mêmes, pour être capables de détecter les déviations et de répondre efficacement aux incidents.