Aller au contenu
Documentation

Concepts

Le graphe de sécurité

Ce que le graphe contient, comment chaque parcours le met à jour, et ce que permettent l’explorateur et la page Schéma.

Cette page décrit le graphe dans lequel Ctadel range tout ce qu’il lit, la façon dont chaque parcours le met à jour, et les deux pages qui permettent de le consulter : l’explorateur et le schéma.

Ce que contient le graphe

Le graphe est une base de nœuds typés reliés par des relations typées. Un nœud représente une ressource, un constat ou un objet de rattachement ; une relation représente un lien observé ou calculé entre deux nœuds. Ctadel tient la liste de ces types ; c’est elle que la page Schéma affiche et que l’explorateur propose.

Les familles de nœuds

FamilleExemples de types
InfrastructureInstance, BaremetalServer, Volume, Snapshot, MachineImage, FlexibleIP, MessageQueue, BackupVault
RéseauVPC, PrivateNetwork, Subnet, SecurityGroup, SecurityGroupRule, PublicGateway, LoadBalancer, LoadBalancerBackend, DNSZone, DNSRecord, CDN, APIGateway, PrivateEndpoint, VpcPeering
Stockage et donnéesBucket, Database, FileStorage, BigQueryDataset, BigQueryTable, AthenaWorkgroup, DataFactory, DataprocCluster, EMRCluster
Kubernetes et conteneursKubernetesCluster, NodePool, KubernetesNode, Namespace, KubernetesWorkload, K8sService, RBACBinding, PersistentVolumeClaim, ContainerImage, ContainerRegistry, RegistryImage, ContainerService
Serverless et applicationsServerlessFunction, ServerlessContainer, WebApp, WorkflowLogicApp
Identités et accèsUser, IamApplication, IamGroup, IamRole, IamPolicy, IAMStatement, APIKey, ServicePrincipal, RoleAssignment, Account, AzureTenant, GCPOrganization, GCPProject, CognitoUserPool
SécuritéSecret, EncryptionKey, Certificate, CloudCertificate, AuditLog, WAF, MonitoringConfig, SecurityService
IACognitiveAccount
Droits observésActionUsage, PrivilegeRecommendation
ÉvénementsCloudEvent
ConstatsSecurityFinding, CVE, SecretFinding, Data, HcrFinding, IacFinding, AttackPath
Code sourceRepository, IacResource, CIService
RattachementProject

Toute ressource cloud porte les mêmes propriétés de base : id, name, state, cloud, project_id, region, created_at, tags. Les ressources qui ont une présence réseau portent en plus public_ips, private_ips, vpc_id et security_group_ids. Chaque type ajoute ensuite ses propriétés propres, et Ctadel normalise certaines d’entre elles entre clouds pour qu’une règle puisse viser un seul nom de propriété quel que soit le fournisseur.

Les lectures approfondies (disques, buckets, bases, clusters, dépôts) écrivent des propriétés supplémentaires sur les ressources qu’elles ont lues : has_sensitive_data et data_classification sur ce qui contient des données, has_secrets sur ce qui contient un secret, has_sbom et package_count sur ce dont l’inventaire de paquets est connu, os_family sur un hôte dont le disque a été lu, has_hcr_findings sur un hôte dont la configuration a été revue.

Les familles de relations

FamilleExemples de relations
StructureBELONGS_TO_PROJECT, HAS_VOLUME, HAS_SUBNET, HAS_RECORD, HAS_RULE, HAS_NODEPOOL, HAS_IMAGE, IN_NETWORK, IN_VPC, IN_NAMESPACE, ATTACHED_TO, RUNS_ON, USES_IMAGE, USES_VOLUME, USES_PVC
Exposition et routageROUTES_TO, RESOLVES_TO, LOAD_BALANCES, HAS_BACKEND, PROTECTED_BY
Identités et accèsCAN_ACCESS, HAS_ACCESS_TO, GRANTS, HAS_POLICY, MEMBER_OF, HAS_API_KEY, HAS_ROLE_ASSIGNMENT, USES_SA, SAME_IDENTITY, CLUSTER_ADMIN_OF, BOUND_TO, BINDING_IN, PERFORMED_ACTION, HAS_RECOMMENDATION
Données et chiffrementCONTAINS_DATA, ENCRYPTED_WITH, STORED_IN, WRITES_TO, LOGS_TO, REPLICATES_TO, MIRRORS
ConstatsHAS_FINDING, HAS_CVE, HAS_VULNERABILITY, HAS_SECRET, HAS_HCR_FINDING, HAS_IAC_FINDING, PART_OF_ATTACK_PATH, ATTACK_STEP, TRIGGERED
Du code au cloudDEPLOYED_AS, PROVISIONED_BY, CREATED_FROM, USES_TOOL, MANAGES, PART_OF

La relation CAN_ACCESS n’est pas lue telle quelle dans un cloud : Ctadel la calcule à partir des politiques, des rôles et des liaisons IAM qu’il a lus, pour exprimer qu’une identité peut atteindre une ressource. C’est elle que suivent la plupart des chemins d’attaque.

Comment chaque parcours le met à jour

À chaque inventaire, Ctadel met le graphe à jour avec ce qu’il vient de lire : une ressource déjà connue est mise à jour, une ressource nouvelle est ajoutée, et leurs relations sont réécrites. Aucun historique n’est conservé dans le graphe lui-même ; l’historique des constats est tenu à part.

Les ressources disparues sont ensuite nettoyées, avec trois précautions.

  • Le nettoyage porte sur un type, dans un compte (couple cloud et projet) : les nœuds de ce type et de ce compte qui ne figurent pas dans l’inventaire reçu sont supprimés, avec leurs relations.
  • Seuls les types dont la lecture a réussi sont nettoyés. Si la lecture d’un type a échoué, ses nœuds sont conservés tels quels jusqu’à la prochaine lecture réussie.
  • Le rafraîchissement d’une seule ressource ne nettoie rien.

Les nœuds enfants (enregistrements DNS, sous-réseaux, certificats, pools de nœuds, images de registre, clés d’API, règles de groupe de sécurité, backends d’équilibreur, instructions de politique IAM) suivent le même principe sous leur parent : mise à jour, puis suppression de ceux qui n’ont pas été revus.

Les lectures approfondies écrivent ensuite leurs résultats par-dessus l’inventaire : nœuds Data et propriétés de classification pour les données sensibles, SecretFinding et HAS_SECRET pour les secrets, CVE et HAS_CVE pour les vulnérabilités, SecurityFinding et HAS_FINDING pour les constats de configuration, HcrFinding pour la revue des hôtes, IacFinding et DEPLOYED_AS pour le code d’infrastructure, AttackPath et PART_OF_ATTACK_PATH pour les chemins d’attaque.

L’explorateur

La page « Explorateur » (titrée « Graphe de sécurité ») permet d’interroger le graphe sans écrire de requête.

L’explorateur avec un modèle de requête chargé et ses résultats en vue graphe.
Figure 1. Figure 1. L’explorateur, un modèle de la catégorie Exposition chargé. Données de démonstration.

Une requête se construit en trois temps.

  1. « Trouver » : le type de nœud de départ, choisi dans la liste des types.
  2. « Où » : des filtres sur ses propriétés. Les opérateurs disponibles sont égal, différent, contient, ne contient pas, commence par, finit par, supérieur à, inférieur à, vide, non vide et dans une liste ; les filtres se combinent en ET ou en OU.
  3. « Qui » : des entités connectées, par relation, avec leurs propres filtres et sous-branches.

Le bouton « Modèles » ouvre une bibliothèque de requêtes prêtes, classées en six catégories : exposition et surface d’attaque, identités et accès, chiffrement et secrets, Kubernetes et conteneurs, sécurité des données, chemins d’attaque. Chaque modèle porte une sévérité indicative et se charge dans le constructeur, où vous pouvez le modifier.

La barre « Demandez à l’IA » accepte une phrase (« instances publiques avec SSH ouvert ») et la transforme en requête dans le constructeur ; une seconde phrase affine la précédente.

Les résultats s’affichent en vue « Graphe » ou « Tableau », avec export CSV. Ils respectent le périmètre sélectionné dans l’en-tête : un utilisateur limité à certains projets ne lit que leur partie du graphe, et un utilisateur sans projet ne lit rien.

Une requête utile peut devenir une règle : « Enregistrer comme politique CSPM » la convertit en politique personnalisée, évaluée à chaque parcours comme les règles du catalogue.

La page Schéma

Le menu utilisateur de l’en-tête propose « Graphe de sécurité », qui ouvre la page « Schéma du graphe de sécurité ». Elle affiche la liste des types : les types de nœuds par catégorie, leurs propriétés avec leur type, les relations entrantes et sortantes de chaque type, et le nombre d’instances de chaque type dans votre graphe. Si le graphe est vide, la page vous invite à lancer un scan.

Limites

  • Certaines relations ne sont pas modélisées, et les chaînes du catalogue qui en auraient besoin sont désactivées : CAN_ACCESS aboutit toujours sur une ressource, jamais sur un rôle ; aucune relation ne relie une identité cloud à un dépôt Git ; l’identité de charge de travail Kubernetes (IRSA, pod identity, fédération) n’est pas modélisée ; aucune relation ne relie un équilibreur de charge à la charge de travail Kubernetes derrière lui ; un nœud VpcPeering n’est relié à rien.
  • Une base de données managée n’est pas analysée pour les vulnérabilités, et une image machine n’est pas analysée pour les secrets.
  • Les comptes Cognito sont lus comme réservoirs d’utilisateurs ; les réservoirs d’identités, qui portent les rôles, ne sont pas collectés.
  • Quelques propriétés affichées sur la page Schéma ne sont jamais renseignées : name sur un CVE (le nom du paquet est sur la relation HAS_CVE), image_name sur une ContainerImage, state et last_used sur une APIKey.
  • Un type dont la collecte a échoué garde ses nœuds précédents : le graphe peut montrer, pour ce type, l’état de la dernière lecture réussie.
  • L’explorateur limite une requête à 10 relations enchaînées, à 100 résultats par défaut et 500 au maximum, et à 15 secondes d’exécution.
  • Les noms des modèles de requêtes et de leurs catégories ne sont disponibles qu’en anglais.
  • Les comptes d’instances de la page Schéma sont recalculés au plus une fois par heure.