Ctadel, écran par écran
Captures réelles de l’application de démonstration, sur des données fictives. Suivez-les dans l’ordre où un responsable sécurité les parcourt : d’abord la situation, puis un constat, puis le chemin qui y mène, puis chaque module.
- 1
La situation en un écran
Score global, répartition par sévérité, constats ouverts et fermés, et leur histoire jour par jour, reconstituée depuis les dates de découverte et de fermeture. C’est l’écran du comité : ce qui a bougé depuis la dernière fois, et pourquoi.
- 2
Une seule liste pour dix modules
Configuration, identités, données, Kubernetes, hôtes, vulnérabilités, secrets et code arrivent dans la même liste, avec la même échelle de sévérité et les mêmes filtres. Chaque ligne s’ouvre sur la ressource, la règle, la logique de détection, les références de conformité et la correction.
- 3
La chaîne, maillon par maillon
Un chemin d’attaque relie des ressources réelles : une exposition, une vulnérabilité, un droit, une donnée. Ici, sept maillons mènent d’internet à une base de données personnelles en passant par un rôle assumé et un instantané partagé avec un autre compte. L’onglet de remédiation dit quel maillon casser pour fermer le chemin.
- 4
Le graphe, consultable tel quel
Tout ce que Ctadel lit entre dans un graphe : une instance appartient à un réseau, porte un rôle, lit un bucket, exécute une image. L’explorateur le parcourt avec des requêtes prêtes à l’emploi ou les vôtres, relation par relation, pour vérifier chaque étape avant de corriger.
- 5
Les droits effectifs, pas les droits déclarés
Utilisateurs, rôles et comptes de service des six clouds, avec ce qu’ils peuvent vraiment faire, ce qu’ils n’utilisent jamais, et les identités qui existent sur plusieurs clouds à la fois.
- 6
Ce que contiennent vraiment les buckets et les bases
Données personnelles, bancaires, de santé et secrets trouvés dans les objets et les tables, par catégorie, avec des extraits masqués et un volume estimé par ressource. Les bases sont lues sur une copie temporaire dans votre compte, détruite ensuite.
- 7
Clusters, nœuds, charges de travail
EKS, AKS, GKE, Kapsule, MKS et OKS lus par leur API avec un groupe dédié en lecture. Charges de travail, comptes de service, RBAC, règles réseau et images, avec les vulnérabilités de ces images.
- 8
Le code avant le déploiement
Dépôts GitHub et GitLab analysés à chaque push et pull request : Terraform, manifestes Kubernetes, Dockerfiles. Le constat renvoie à la ligne, et la dérive entre le code et le déployé est signalée pour les règles appariées.
- 9
Le catalogue, règle par règle
Chaque règle se lit, s’active et se désactive. Celles que Ctadel désactive, parce que la donnée n’est pas collectée ou que le signal n’a jamais été observé, restent visibles avec leur raison.
- 10
Comptes, équipe, canaux
Comptes cloud et dépôts regroupés en dossiers et projets, utilisateurs et rôles, SSO, canaux de notification et de tickets, rétention, journal d’audit. Tout ce qui sort de l’instance passe par un canal que vous configurez.
Et sur vos comptes ?
La démonstration publique est ouverte à tous, sans compte, sur des données fictives. Pour une instance sur vos propres comptes, demandez une démonstration.