Données et chiffrement
Ce que votre instance conserve, où, sous quelle protection, combien de temps, et vers quels services extérieurs elle émet des appels.
Votre instance Ctadel conserve une description de vos comptes cloud et les constats qui en découlent, pas vos données. Cette page dit ce qui est stocké, où, comment les identifiants sont protégés, combien de temps chaque chose est gardée, et quels appels sortent de l'instance.
Ce qui est conservé
| Donnée | Contenu | Où |
|---|---|---|
| Inventaire | Les ressources de vos comptes (identifiants, noms, configuration, relations) telles que les API des clouds les décrivent | Le graphe de sécurité ; la liste des comptes dans la base |
| Constats | Règle, ressource, sévérité, état, dates, projet, pour chaque module | La base ; reflétés dans le graphe, rattachés à la ressource |
| Échantillons de données sensibles | Pour chaque constat de données : le chemin ou la colonne, le nombre de correspondances et un échantillon masqué, deux caractères visibles de chaque côté | La base |
| Secrets détectés | Le chemin, la ligne, la catégorie, une empreinte et un extrait masqué ; la valeur elle-même n'est pas stockée et ne va jamais dans le graphe | La base et le graphe |
| Liste des paquets | Les paquets installés lus sur chaque disque et chaque image, pour les rapprocher des vulnérabilités connues | La base |
| Journal d'audit | Qui a fait quelle action, quand, depuis quelle adresse ; jamais le contenu des requêtes | La base |
| Utilisateurs | Adresse, nom, rôle, langue ; le mot de passe sous forme de hachage bcrypt | La base |
Pour un secret dont la valeur est longue, l'extrait garde au plus quatre caractères de chaque côté ; une valeur de moins de seize caractères est masquée entièrement. La base et le graphe tournent dans votre instance et ne sont partagés avec aucun autre client.
Les identifiants que vous confiez
Les identifiants des comptes cloud (clés d'API, secrets de service principal, clés de compte de service, clés de consommateur OVHcloud) sont chiffrés en AES-256-GCM avant d'être écrits dans la base, avec une clé de 256 bits propre à l'instance, tenue hors de la base. Chaque chiffrement tire un nonce aléatoire. L'interface ne peut pas relire les valeurs : à la modification d'un compte, les champs secrets laissés vides conservent la valeur enregistrée.
Sont protégés de la même façon : les kubeconfigs des clusters déclarés, les secrets client des fournisseurs d'authentification unique, la configuration des intégrations de tickets, les jetons OAuth GitLab et les secrets de webhook Git.
À l'intérieur de l'instance, les ordres de scan qui transportent des identifiants vers un scanner sont scellés avec une seconde clé propre à l'instance, en AES-256-GCM ; seul le scanner destinataire les ouvre. Un ordre reçu sans la clé est refusé plutôt que pris pour vide.
La clé de chiffrement des identifiants n'est pas dans les sauvegardes : une restauration sur une instance qui n'a pas la même clé laisse les identifiants illisibles. Voir Sauvegardes et reprise.
Durées de conservation
| Donnée | Durée |
|---|---|
| Constats fermés (résolus, corrigés, faux positifs, révoqués) | « Période de rétention » : 90 jours par défaut, réglable de 7 à 3650 jours dans « Paramètres », carte « Rétention des données ». Un constat ouvert n'est jamais purgé |
| Journal d'audit | 365 jours, non réglable |
| Ordres de scan en transit dans l'instance | 24 heures au plus |
| Inventaire | Remplacé à chaque parcours ; une ressource disparue est retirée du graphe au parcours suivant |
| Sauvegardes | 7 jours sur l'instance, 30 jours sur le stockage objet |
Les appels sortants
L'instance émet des appels vers l'extérieur pour cinq usages. Aucun autre service tiers n'est appelé.
| Destination | Usage | Ce qui part |
|---|---|---|
| API de vos clouds | Inventaire, copies de disques et de bases, lecture des buckets, API des clusters | Vos identifiants, les demandes de lecture et de création des ressources éphémères |
NVD (services.nvd.nist.gov), CISA KEV, EPSS (epss.cyentia.com), suivis de sécurité Debian, Ubuntu et Alpine | Base de vulnérabilités du rapprochement des paquets | Aucune donnée de votre instance : téléchargement des flux publics |
| API GitHub et GitLab | Analyse des dépôts connectés, commentaires et statuts de pull request | Le jeton de l'intégration et les résultats d'analyse du dépôt concerné |
| Fournisseur du secret (adresse de vérification propre à chaque règle) | Si « Validation des secrets » est activée dans « Paramètres » : vérifier qu'un secret détecté est encore actif | Le secret lui-même, dans une requête authentifiée vers le service qui l'a émis ; il transite chiffré dans l'instance et n'est jamais stocké |
| Modèles de langue servis en Europe par Scaleway | Les assistants | La question, un résumé de la posture du périmètre de l'utilisateur (nombres de constats par sévérité et par catégorie, règles les plus fréquentes, titres des incidents, couverture par référentiel), et le résultat des lectures que l'assistant fait pendant la conversation : noms de ressources, constats, extraits de configuration ou de code concernés. Jamais les identifiants cloud |
| Service de courriel (Scaleway TEM) | Courriels de compte et récapitulatif de fin de parcours | Adresse du destinataire et contenu du courriel |
| Vos propres canaux (webhooks, messageries, outils de tickets, serveurs SSO) | Notifications, tickets, authentification | Ce que vous avez configuré |
| Opérateur Ctadel (webhook et courriels d'exploitation) | Alerte quand un composant de l'instance est indisponible ou quand une sauvegarde échoue | Le nom d'hôte, l'identifiant du client, le composant concerné ; aucun constat, aucune donnée d'inventaire |
La machine éphémère de lecture des disques, qui tourne dans votre compte, installe ses outils d'analyse depuis des dépôts publics, met à jour sa base de vulnérabilités et vérifie l'accès à Internet ; elle n'envoie rien ailleurs que vers votre instance.
Limites
- Les adresses de webhook des canaux de notification et leur secret de signature sont stockés dans la base sans chiffrement applicatif ; ils sont protégés par le contrôle d'accès à la base et au serveur, pas par la clé de chiffrement des identifiants.
- Le chiffrement des disques de l'instance n'est pas réalisé par Ctadel ; la page ne l'affirme pas.
- La valeur d'un secret détecté transite vers le service émetteur quand la validation est activée ; désactivez « Validation des secrets » si vous ne voulez aucun appel vers ces services.
- L'inventaire et les constats ne sont pas chiffrés au niveau applicatif, ni dans la base ni dans le graphe : ils sont lisibles par quiconque accède au serveur de l'instance.
- Les rétentions ne s'appliquent qu'aux constats fermés ; le libellé « Les findings de plus de N jours sont supprimés définitivement. » de la carte « Rétention des données » ne précise pas cette restriction.
- Ce que le fournisseur des modèles de langue fait des requêtes reçues relève de ses conditions ; cette documentation ne l'affirme pas. Sans accès aux modèles configuré, les assistants répondent que l'IA n'est pas configurée et rien ne part.
- Il n'existe pas d'export des données ni d'effacement sélectif par ressource depuis l'interface.