Sécuriser les accès à l'infrastructure
Mise à jour :
Qui peut accéder à quoi, et comment le prouver ? Cette question est au cœur de la sécurité des infrastructures modernes. Avec des équipes distribuées, des environnements éphémères et des exigences de conformité croissantes, la gestion des accès ne peut plus reposer sur des clés SSH partagées ou des VPN monolithiques.
Pourquoi sécuriser les accès ?
L’accès aux systèmes est le premier vecteur d’attaque. Une clé SSH compromise, un mot de passe réutilisé ou un compte orphelin suffisent à ouvrir une brèche.
Les approches traditionnelles montrent leurs limites :
- VPN classiques : une fois connecté, l’attaquant a accès à tout le réseau
- Clés SSH partagées : impossibilité de savoir qui a fait quoi
- Comptes génériques : aucune traçabilité individuelle
- Accès permanents : les droits s’accumulent, jamais ne se révoquent
La sécurisation moderne des accès repose sur trois piliers : centralisation des identités, application du moindre privilège et audit exhaustif.
Qui est concerné ?
| Profil | Besoin principal |
|---|---|
| Ops / SRE | Accès SSH aux serveurs, kubectl, bases de données |
| Développeurs | Accès aux environnements de dev/staging, logs applicatifs |
| DBA | Connexion sécurisée aux bases de production |
| Auditeurs | Preuves d’accès, enregistrement des sessions |
| RSSI | Visibilité sur qui accède à quoi, alertes sur anomalies |
Comment ça fonctionne ?
Authentification centralisée
L’utilisateur s’authentifie une seule fois via un fournisseur d’identité (IdP) : SSO, LDAP, Active Directory, Okta, Google Workspace. Un certificat ou token de courte durée est émis. Fini les clés SSH à distribuer et révoquer manuellement.
Autorisation granulaire
Les droits sont définis par rôle, équipe ou projet. L’accès est accordé uniquement aux ressources nécessaires, pour une durée limitée (just-in-time).
Audit et traçabilité
Chaque connexion est journalisée : qui, quoi, quand, depuis où. Les sessions peuvent être enregistrées (session recording) pour répondre aux exigences de conformité (SOC 2, ISO 27001, PCI-DSS).
Scénario : accès d’urgence en production
Un incident survient à 3h du matin. L’ingénieur d’astreinte doit se connecter à un serveur de production.
Sans solution moderne : il utilise une clé SSH partagée, stockée dans un wiki ou un fichier sur son poste. Aucun moyen de savoir exactement ce qu’il a fait. La clé reste valide indéfiniment.
Avec un bastion zero trust : il s’authentifie via SSO (MFA activé), demande un accès temporaire au serveur concerné. Un certificat de 4 heures est émis. Toute la session est enregistrée. Le lendemain, l’équipe peut revoir exactement les commandes exécutées.
Pièges courants
- Implémenter sans intégration SSO — on recrée un silo d’identités
- Oublier les comptes de service — les accès machine-to-machine aussi doivent être contrôlés
- Accorder des accès permanents “pour simplifier” — la dette s’accumule
- Négliger les logs — auditer sans analyser ne sert à rien
- Ignorer les environnements hors-prod — staging contient souvent des données sensibles
Outils disponibles
Outils à explorer
Ces outils méritent d’être évalués pour compléter cette section :
- Pritunl — VPN open source avec interface web et intégration SSO
- Apache Guacamole — accès remote (RDP/VNC/SSH) sans client à installer
- WALLIX Bastion — PAM entreprise avec enregistrement de session et coffre-fort
- Zitadel — IAM cloud-native open source, alternative à Auth0/Keycloak
À retenir
- Centralisez les identités — un utilisateur = une identité, intégrée au SSO existant
- Appliquez le moindre privilège — accès just-in-time, durée limitée, périmètre restreint
- Auditez tout — chaque session doit être traçable (qui, quoi, quand, où)
- Éliminez les secrets statiques — préférez les certificats courts aux clés SSH permanentes
- Zero Trust — ne faites confiance à aucun réseau, vérifiez chaque requête