Sans agent ne veut pas dire lecture seule

La promesse « sans agent, en lecture seule » se lit sur beaucoup de sites. Elle est à moitié vraie, et la moitié fausse mérite d’être expliquée avant la signature, pas après l’audit de votre équipe IAM.

Ce qui est vraiment en lecture

L’inventaire : instances, volumes, réseaux, groupes de sécurité, identités, bases gérées, clusters, buckets, clés, journaux. Tout cela vient des API de gestion de vos clouds et se lit avec un accès en lecture : un rôle AWS avec les politiques d’audit, un service principal Azure en lecture sur l’abonnement, un compte de service Google Cloud, une clé d’API Scaleway, OVHcloud ou OUTSCALE limitée aux lectures.

Avec cet accès seul, Ctadel sait déjà beaucoup : la configuration de chaque ressource, les permissions effectives des identités, les ports ouverts sur le monde, les clusters Kubernetes et leur contenu, le code de vos dépôts, et les chemins d’attaque qui relient tout cela.

Ce qui ne peut pas l’être

Pour savoir ce qu’il y a dans un serveur, il y a deux méthodes. Installer un agent, qui tourne en permanence chez vous. Ou demander au cloud une copie du disque et la lire ailleurs. Ctadel fait la seconde, et c’est là que la lecture seule s’arrête.

Pour un disque, Ctadel crée un instantané du volume, restaure un volume de travail, démarre une instance éphémère dans votre compte avec ce volume monté en lecture seule, y cherche les secrets, les données sensibles, la liste des paquets installés et les réglages d’hôte, puis supprime l’instance, le volume et l’instantané. Le serveur d’origine n’est jamais touché : aucune connexion, aucune commande.

Pour une base de données gérée, Ctadel ne lit jamais l’instance de production. Il demande une restauration dans une instance temporaire, y lit un échantillon de chaque colonne de texte, puis la supprime.

Créer un instantané, un volume, une instance, une paire de clés, un groupe de sécurité, une instance de base : ce sont des droits d’écriture. Dire le contraire serait faux.

Comment ils sont demandés

Trois choix de conception rendent ces droits acceptables pour une équipe IAM.

• Ils sont séparés. Le gabarit AWS a une option par capacité : copie de disques, copie de bases, lecture du contenu des buckets, accès aux clusters. Sur Scaleway, OVHcloud, OUTSCALE, Azure et Google Cloud, les droits de copie sont une politique à part. Chacune peut être désactivée : l’inventaire fonctionne, ces contenus ne sont simplement pas lus.
• Ils sont bornés. L’instance de scan vit dans votre compte, dans un sous-réseau que vous choisissez, avec un groupe de sécurité restreint à la seule adresse de sortie de votre instance Ctadel. Si ce groupe ne peut pas être créé, le scan échoue plutôt que de s’ouvrir.
• Tout est détruit, une fois exactement. En cas de succès, d’échec à n’importe quelle étape ou d’interruption, l’instance, le volume de travail et l’instantané sont supprimés dans l’ordre inverse de leur création. Une ressource dont la création a répondu avec un identifiant puis a échoué est elle aussi supprimée.

Ce qui est créé vous est facturé par votre cloud le temps de son existence, soit quelques minutes par volume. La page Sans agent décrit chaque étape et ce que la copie de disque ne peut pas voir : l’état en mémoire, un service qui tourne à l’instant, la sortie d’une commande.

La question à poser à n’importe quel éditeur

« Pour lire l’intérieur de mes serveurs, que créez-vous dans mon compte, avec quels droits, et que se passe-t-il si le scan plante au milieu ? » Si la réponse est « rien, nous sommes en lecture seule », soit l’éditeur n’analyse pas vos disques, soit il installe un agent, soit il ne vous dit pas tout.

Les gabarits de droits de Ctadel pour chaque cloud sont dans la documentation de connexion, lisibles avant toute démonstration.