Derrière cette phrase simpliste se cache en réalité un réel problème de sécurité. Prenons le cas d’un site marchand en ligne, que nous appellerons Nil – car Amazone est déjà pris. Nil a des visiteurs, des clients, et des salariés qui mettent en ligne les articles et traitent les commandes. Toutes les visites du site, toutes les actions laissent des traces d’audit permettant de reconstituer qui a fait quoi. L’important est que celui qui fait l’action ne puisse pas effacer ses traces.
Cela fonctionne très bien, jusqu’au moment où l’on s’aperçoit que celui qui gère la base de données des traces – il y a forcément quelqu’un – peut effacer ses propres traces.
Qu’à cela ne tienne, rajoutons quelqu’un qui surveille cet administrateur. Et nous voilà partis dans une boucle infinie de surveillants. D’où cette question essentielle : qui surveille les surveillants ?
La bonne nouvelle, c’est que nous avons la solution !
Le bastion
Il y a deux axes fondamentaux dans la solution à ce problème : la collecte systématique des traces et l’intégrité de ces traces.
Collecte systématique
Pour bien comprendre cet axe, prenons un exemple de la vie réelle : les sociétés d’autoroutes. Elles ont aussi un besoin de collecte systématique, d’argent certes mais cela ne change rien au propos.
Pour que le système fonctionne, elles doivent s’assurer que tous les usagers d’un tronçon d’autoroute passent forcément par un point de contrôle, que s’appellorio péage.
Le principe est exactement le même en informatique : tous les accès doivent passer par l’équivalent du péage, que l’on nomme bastion. Le bastion se charge de collecter les traces d’audit nécessaires : le fameux QQCOQP (qui-quoi-comment-où-quand-pourquoi). On n’oubliera pas de bloquer toutes les tentatives de connexion qui ne passeraient pas par le bastion, au risque de rendre ce dernier inutile.
Intégrité des traces
Jusque là, nous n’avons fait que déporter le problème : les administrateurs disposant de tous les pouvoirs, ils peuvent toujours effacer leurs traces si besoin.
D’où ce deuxième axe, qui passe par une séparation des pouvoirs. Les administrateurs des systèmes protégés par le bastion ne doivent pas pouvoir administrer le bastion, et inversement.
Better, stronger…
Une fois ce bastion en place, le Nil est sous contrôle : les administrateurs ne peuvent plus effacer leurs traces, et ils sont surveillés par une équipe dédiée qui elle-même n’a pas accès aux serveurs et ne peut donc pas générer de trace.
Mais on peut faire mieux !
Surveillance poussée
Maintenant que les administrateurs doivent obligatoirement passer par le bastion, on peut enregistrer ce qu’ils tapent au clavier, ce que leur répond le serveur, mais aussi ce qu’ils voient sur leur écran – au format vidéo s’il-vous-plaît !
Traçabilité améliorée
Puisque les administrateurs ne se connectent plus directement aux serveurs, ils n’ont peut-être pas besoin d’avoir un compte dessus, d’avoir un mot de passe qui peut se perdre ou une clé SSH qui peut être volée.
Pourquoi ne pas prévoir un seul compte par serveur, dont le mot de passe est seulement connu (et géré automatiquement !) par le bastion ? Les administrateurs s’authentifient sur le bastion, puis ouvrent de manière transparente une session sur le serveur.
Contrôle d’accès
Enfin, dernière amélioration apportée par les bastions : le contrôle d’accès.
Les administrateurs ne se connectent plus directement aux serveurs, ils n’en connaissent d’ailleurs plus les codes d’accès. Il est désormais simple de garder une matrice de quel administrateur a droit à quels serveurs.
Je passe sous silence les modalités de déploiement ainsi qu’une petite étude de marché. Ce n’est pas l’objet de cet article, des cabinets de conseil et le Gartner feront ça mieux que moi. Mais maintenant, vous savez qui surveille les surveillants !