Sans agent

Ctadel n'installe aucun logiciel sur vos serveurs, vos conteneurs ou vos postes. Tout ce qu'il sait vient de quatre sources : les API de vos clouds, une copie de vos disques, une copie temporaire de vos bases PostgreSQL et le contenu de vos buckets. Cette page décrit chaque méthode, puis ce qu'elle ne permet pas.

Les API des clouds

Un collecteur par cloud interroge les API de gestion avec l'accès que vous avez accordé, en lecture pour cette partie : rôle AWS, service principal Azure, compte de service Google Cloud, clé d'API Scaleway, OVHcloud ou OUTSCALE. Il obtient la liste des ressources et leur configuration : instances, volumes, réseaux, groupes de sécurité, identités, bases gérées, clusters, buckets, clés, journaux. C'est cet inventaire qui alimente le graphe et les règles de configuration. La page de chaque cloud, dans la section Démarrer, donne les droits exacts.

La copie de disque

Pour lire l'intérieur d'un serveur, Ctadel ne s'y connecte pas. Il demande au cloud une copie du disque et la lit dans votre compte, sur une machine éphémère :

1. Un instantané du volume est créé.
2. Un volume de travail est restauré depuis cet instantané.
3. Une instance de scan est démarrée dans votre compte, avec ce volume attaché et une paire de clés générée pour l'occasion.
4. Le volume est monté en lecture seule sur l'instance.
5. Trois lectures sont faites sur le point de montage : la recherche de secrets et de données sensibles, la liste des paquets installés (base de paquets du système, puis registre Windows pour les disques NTFS) pour les vulnérabilités, et les contrôles de configuration d'hôte.
6. L'instance, le volume de travail et l'instantané sont supprimés, dans l'ordre inverse de leur création.

La suppression a lieu une fois exactement, en cas de succès, d'échec à n'importe quelle étape ou d'interruption du scan. Une ressource dont la création a répondu avec un identifiant puis a échoué est elle aussi supprimée. Ce qui est créé vit dans votre compte et vous est facturé le temps de son existence ; la page Réglages du scanner décrit le réseau dans lequel l'instance est placée.

Ces créations, comme la copie temporaire de base décrite plus bas, demandent des droits d'écriture dans votre compte (création et suppression d'instantanés, de volumes, d'instances, de paires de clés, de groupes de sécurité, d'instances de base), accordés en plus des droits de lecture de l'inventaire. Sans eux, l'inventaire par API fonctionne et ces contenus ne sont pas lus. « Sans agent » ne veut donc pas dire « en lecture seule » : la page Connecter un compte cloud détaille ce que chaque analyse demande.

Le serveur d'origine n'est jamais touché : aucune connexion SSH, aucune commande, aucun agent. Les volumes des nœuds Kubernetes gérés sont ignorés, car les données applicatives sont dans les volumes persistants ; un disque sans système de fichiers, ou dont aucun système de fichiers ne peut être monté, est signalé comme non lu plutôt que comme vide.

La copie temporaire de base

Pour les bases de données gérées, Ctadel ne lit jamais l'instance de production. Il demande au cloud une restauration dans une instance temporaire, y crée un compte de lecture ctadel_dspm_scanner avec un mot de passe généré, lit, puis supprime l'instance. Ici encore, la suppression a lieu une fois exactement, quel que soit le déroulement.

La lecture est un échantillonnage : dans chaque base, pour chaque colonne de type texte, JSON, XML ou assimilé de tous les schémas non système, 100 lignes prises au hasard sont examinées par les règles de données sensibles. Seul un échantillon masqué (deux caractères de chaque côté) est conservé par règle et par colonne, avec le nombre de correspondances et le nombre de lignes de la table. Au-delà de 5 000 colonnes, le résultat est marqué incomplet et aucun constat antérieur n'est fermé.

Seul PostgreSQL est lu, sur AWS RDS, Google Cloud SQL et Scaleway. Les autres moteurs sont refusés avant toute copie, pour ne pas vous facturer une restauration inutile.

Les buckets

Le lecteur d'objets se connecte directement au bucket avec l'accès accordé (S3, Google Cloud Storage, Azure Blob, OVHcloud et OUTSCALE en S3) et liste son contenu, jusqu'à 100 000 objets. Les objets vides et ceux en classe d'archivage sont ignorés. Un fichier texte est lu par échantillon de 10 Mo au plus ; un PDF, une archive ou un document bureautique est téléchargé en entier jusqu'à 50 Mo puis son texte est extrait. Les règles de secrets et de données sensibles s'appliquent au texte obtenu. Rien n'est écrit dans le bucket.

Si la liste a été tronquée, ou si des objets n'ont pas pu être lus, le résultat est marqué incomplet et les constats des objets non vus restent ouverts.

Les clusters Kubernetes

Pour un cluster géré, Ctadel obtient un accès à l'API du cluster par l'API du cloud. Pour un cluster déclaré avec un kubeconfig, le fichier est contrôlé avant usage : tout plugin d'exécution, fournisseur d'authentification, chemin de fichier, mandataire ou serveur non HTTPS est refusé, et seuls les jetons et certificats inclus en ligne sont acceptés. Les objets du cluster sont lus par l'API ; les images des conteneurs sont tirées et analysées sur votre instance Ctadel. Aucun composant n'est déployé dans le cluster.

Ce que cette méthode ne permet pas

La copie de disque est une photographie du système arrêté. Elle contient la configuration de démarrage, mais pas l'état en mémoire. Les règles d'hôte en tiennent compte :

Type de contrôle	Lecture sur copie de disque
Fichiers de configuration, permissions, propriétaires, paramètres noyau, comptes, politique de mots de passe, SUID, fichiers modifiables par tous	Lue
Service actif	Lu comme « activé au démarrage » ; le constat le précise. Qu'un service tourne à l'instant n'est pas connaissable
Paquet installé, options de montage, règles d'audit, modules noyau	Lus depuis la base de paquets, /etc/fstab, les règles auditd et la configuration modprobe
Sortie d'une commande (command_output)	SKIPPED : aucune commande n'est exécutée sur l'hôte
Droits utilisateur Windows (windows_user_rights) et politique d'audit avancée (windows_audit_policy)	SKIPPED : ces réglages ne sont pas lus sur une copie de disque

Les règles de ces trois derniers types sont désactivées dans le catalogue, avec la raison inscrite dans leur description. Une règle qui vise une distribution, un rôle de serveur Windows ou un type d'hôte différent de celui lu est marquée SKIPPED et dit pourquoi, jamais réussie ni échouée. Un fichier de configuration absent du disque (logiciel non installé) donne aussi un SKIPPED.

Limites

• Aucune commande n'est exécutée sur vos hôtes ; les contrôles qui en dépendent sont SKIPPED ou désactivés.
• Les contrôles d'hôte ne tournent que sur un volume système ; un volume de données ou un volume persistant Kubernetes n'est lu que pour les secrets et les données sensibles. Les systèmes immuables (Container-Optimized OS, Flatcar, Bottlerocket) ne reçoivent pas de contrôles d'hôte.
• Les volumes des nœuds Kubernetes gérés et certains types de volumes historiques ne sont pas copiés.
• Un volume dont aucun système de fichiers n'a pu être monté (LVM, format non pris en charge, disque endommagé) est un scan refusé, pas un disque sans constat.
• La liste des paquets dépend d'un accès Internet depuis l'instance de scan ; sans lui, les vulnérabilités du disque ne sont pas évaluées.
• La recherche de secrets sur disque est bornée à 30 minutes par volume.
• Les bases gérées : seul PostgreSQL est lu ; Aurora, MySQL, SQL Server et les autres moteurs sont refusés. Azure SQL et les bases gérées OVHcloud ne sont pas lues du tout.
• La lecture de base est un échantillon de 100 lignes par colonne : une donnée rare peut ne pas y figurer.
• Les buckets : 100 000 objets au plus par bucket, 10 Mo par fichier texte, 50 Mo par fichier à extraire ; les formats non lisibles (ancien .doc, archive tronquée) sont ignorés.
• Chaque copie (instantané, volume, instance, base restaurée) est facturée par votre cloud le temps de son existence.