Sécurité du service

Cette section décrit l’instance que Ctadel exploite pour vous : ce qui lui appartient, où elle tourne, qui y accède et ce qui en sort. Ce que le service ne fait pas est dit dans les limites de chaque page, pas passé sous silence.

Une instance par client

Chaque client reçoit une instance complète et isolée, déployée sur un serveur qui lui est réservé. La base de données, le graphe de sécurité, les clés de chiffrement et le certificat TLS appartiennent à cette instance ; aucun composant applicatif n’est partagé entre deux clients.

L’instance comprend l’application web, l’inventaire des six clouds (Scaleway, OVHcloud, OUTSCALE, AWS, Azure, Google Cloud), l’évaluation des règles, les scanners de contenu (disques, buckets, bases de données, Kubernetes, fonctions serverless, vulnérabilités, vérification des secrets, dépôts Git), les assistants et un composant dédié à l’authentification unique SAML. Un seul point d’entrée est exposé sur Internet, en HTTPS ; tous les autres composants communiquent sur un réseau interne au serveur, inaccessible de l’extérieur.

Les secrets de l’instance sont générés à sa création, un jeu par client : mots de passe des bases, clé de chiffrement des identifiants cloud, clé de scellement des ordres de scan, jetons internes, secrets du composant SAML et mot de passe du premier administrateur. Ils sont conservés sur le serveur, lisibles par l’administrateur du serveur uniquement, et une copie est gardée par Ctadel dans un espace réservé à ce client.

Un composant seulement est commun à tous les clients : le relais de webhooks webhook.ctadel.eu, exploité par Ctadel, qui transmet les événements de l’application GitHub à l’instance concernée. Il n’intervient que si vous connectez des dépôts GitHub.

Le point d’entrée

Votre instance répond sur https://<client>.ctadel.eu, avec un certificat Let’s Encrypt renouvelé automatiquement. Le point d’entrée distingue trois usages : les webhooks GitHub et GitLab (signature vérifiée avant tout traitement), les échanges nécessaires à l’authentification unique SAML (seuls les points d’entrée que le navigateur et votre fournisseur d’identité doivent atteindre sont exposés), et l’application web. Le navigateur ne parle qu’à l’application web ; les appels internes de l’application restent sur le réseau du serveur.

Chaque réponse porte les en-têtes suivants : Strict-Transport-Security: max-age=31536000; includeSubDomains; preload, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin et une Permissions-Policy qui refuse caméra, micro et géolocalisation. L’en-tête Server est retiré. La taille des corps de requête est plafonnée à 200 Mo (dépôt de SBOM).

Hébergement

L’instance est hébergée sur un serveur physique dédié chez Scaleway, à Paris (France), sous Ubuntu LTS. Son nom de domaine <client>.ctadel.eu est géré dans la zone DNS de Ctadel, chez Scaleway également.

Avant tout déploiement, le serveur est préparé ainsi :

• pare-feu : tout le trafic entrant est refusé sauf HTTPS, HTTP (nécessaire à l’obtention du certificat) et l’accès d’administration de Ctadel ;
• accès d’administration : par clé uniquement, l’authentification par mot de passe est désactivée ;
• mises à jour de sécurité du système appliquées automatiquement ;
• répertoire de l’application accessible à l’administrateur du serveur seul ;
• sauvegarde quotidienne à 03:00, décrite dans Sauvegardes et reprise.

Sous-traitants techniques

Prestataire	Usage
Scaleway SAS	Serveur dédié à Paris, zone DNS, stockage objet des sauvegardes (région Paris)
Scaleway TEM	Courriel transactionnel (invitations, réinitialisation, alertes)
Scaleway Generative APIs	Modèles de langue des assistants, servis en Europe
Let’s Encrypt	Certificats TLS

Les appels sortants vers les API de vos clouds et vers les bases de vulnérabilités sont décrits dans Données et chiffrement.

Journaux

Les composants de l’instance écrivent des journaux techniques structurés, conservés sur le serveur avec une rotation : au-delà d’un volume fixé par composant, les lignes les plus anciennes sont écrasées. Ces journaux restent sur le serveur ; aucun envoi vers un collecteur externe n’est configuré.

Le journal d’audit applicatif (qui a fait quoi dans l’interface) est distinct : il est conservé dans la base de l’instance et consultable dans l’application, voir Journal d’audit.

Surveillance

Chaque composant de l’instance signale sa présence à intervalle régulier. Ctadel agrège ces signaux avec l’état des bases. Un composant est considéré sain tant que son dernier signal date de moins de 90 secondes, en retard jusqu’à 5 minutes de silence, indisponible au-delà ; les trois minutes qui suivent un redémarrage de l’instance sont une période de grâce.

Chaque passage à l’état indisponible déclenche une alerte vers l’équipe d’exploitation Ctadel, par courriel et par webhook, avec l’identifiant de votre instance. Le rétablissement est notifié de la même façon. Vos administrateurs ne reçoivent pas ces alertes par défaut : une instance par client, une panne de composant se traite côté Ctadel. Vous pouvez néanmoins les recevoir sur vos propres canaux en ajoutant le type system à une règle de notification, voir Notifications.

Dans l’application, la carte « État du système » (« Paramètres », onglet « Général ») affiche ces états, rafraîchis toutes les 30 secondes. Une pastille apparaît dans l’en-tête uniquement quand l’instance est dégradée ou indisponible.

Mises à jour

Ctadel met votre instance à jour à distance. Seuls les composants dont le code a changé sont reconstruits et redémarrés ; les secrets et les clés de l’instance ne sont pas modifiés par une mise à jour. À la fin, Ctadel vérifie que https://<client>.ctadel.eu répond.

Un composant mis à jour est indisponible le temps de son redémarrage. Il n’existe pas de fenêtre de maintenance ni de déploiement sans interruption. Les mises à jour du système d’exploitation sont indépendantes et automatiques (voir Hébergement).

Suppression d’une instance

À la fin du contrat, Ctadel supprime votre instance en confirmant explicitement le nom du client, puis, dans l’ordre :

1. arrêt de l’instance et suppression de toutes ses données (base, graphe, certificat) ;
2. suppression du serveur dédié, et avec lui son disque ;
3. suppression de l’enregistrement DNS <client>.ctadel.eu ;
4. suppression de l’espace de sauvegardes du client et de son contenu ;
5. mise de côté des secrets du client chez Ctadel.

Si une étape échoue, la procédure s’arrête en listant ce qui reste à supprimer à la main et conserve les informations nécessaires pour réessayer.

Limites

• Chiffrement du disque. Le disque du serveur n’est pas chiffré ; les données de l’instance (base, graphe) y sont écrites en clair. Seuls les identifiants cloud et les ordres de scan sont chiffrés au niveau applicatif, voir Données et chiffrement.
• Certification. Ctadel ne détient aucune certification pour le service. Les attestations de Scaleway concernent ses centres de données et ses produits, pas cette application.
• Un seul serveur. L’instance n’est pas redondée. La défaillance du serveur interrompt le service jusqu’à une restauration depuis les sauvegardes sur un nouveau serveur.
• Trafic interne en clair. Entre les composants de l’instance, les échanges ne sont pas chiffrés ; ils restent sur le réseau interne d’un seul serveur.
• Accès de Ctadel. Ctadel accède au serveur avec des droits d’administration, par clé, et conserve une copie des secrets de l’instance. Aucun mécanisme technique ne vous permet de constater ces accès ; seul le journal d’audit applicatif trace les actions faites dans l’interface.
• Clés partagées entre clients. La clé d’accès à la base de vulnérabilités NVD, celle des modèles de langue, les identifiants du service de courriel et la clé d’accès au stockage des sauvegardes sont les mêmes pour toutes les instances. Cette dernière donne donc accès aux sauvegardes de tous les clients.
• Journaux. Les journaux techniques ne sont ni exportés ni conservés au-delà de la rotation décrite plus haut, et vous n’y avez pas accès.
• Alertes. Les alertes de panne vont à Ctadel ; si aucun destinataire d’exploitation n’est configuré sur une instance, la panne n’est que journalisée.