Identités (CIEM)

Les identités relevées, les droits effectifs calculés dans le graphe pour chaque cloud, les droits inutilisés, la corrélation entre clouds et la page Identités.

Le module d'identités relève les utilisateurs, les comptes de service, les rôles et les politiques de chaque compte cloud, puis calcule dans le graphe ce que chaque identité peut atteindre. La page « Identité & Accès » présente le résultat.

Ce qui est relevé

Cloud	Identités et objets relevés
AWS	Utilisateurs IAM (avec le rapport d'identifiants : MFA, dernière connexion), groupes, rôles (rôles de service distingués, dernière utilisation), politiques gérées et inline, clés d'accès
Azure	Utilisateurs Entra (synchronisation locale, dernière connexion, âge du mot de passe, inscription MFA, rôles d'annuaire privilégiés), service principals et leurs identifiants (secrets, certificats, expiration), affectations de rôles RBAC
Google Cloud	Comptes de service et leurs clés ; liaisons IAM de projet et d'organisation. Les utilisateurs et groupes nommés dans une liaison reçoivent un nœud à partir de la liaison, car le collecteur n'inventorie que les comptes de service
Scaleway	Utilisateurs (MFA), applications, groupes, politiques et leurs règles, clés d'API
OVHcloud	Utilisateurs d'identité, applications d'API et leurs clés d'application, politiques IAM
OUTSCALE	Utilisateurs EIM et leurs clés d'accès (y compris les clés du compte racine quand l'inventaire tourne avec elles), groupes, politiques gérées et inline, politique d'accès à l'API du compte

Les utilisateurs, groupes et politiques OUTSCALE prennent les mêmes types que ceux d'AWS, ce qui permet aux mêmes règles et aux mêmes chemins d'attaque de s'appliquer.

Droits effectifs

Après chaque inventaire, Ctadel recalcule une relation « peut accéder » entre chaque identité et chaque ressource qu'elle atteint, avec un niveau (read, write, delete, admin). Le calcul procède dans cet ordre :

Les utilisateurs propriétaires reçoivent admin sur toutes les ressources.
Les groupes reçoivent ce que leurs politiques accordent ; leurs membres les atteignent par l'appartenance au groupe.
Les utilisateurs et comptes de service reçoivent ce que leurs propres politiques accordent.
Les rôles reçoivent ce que leurs politiques accordent.
Les liaisons IAM Google Cloud (projet et organisation) sont pliées dans le même modèle.
Les affectations de rôles Azure le sont aussi, limitées à leur périmètre : une affectation sur un groupe de ressources n'atteint que ce qui est sous ce groupe, pas tout l'abonnement.
Le calcul qui porte une identité hérite de ses droits : une instance derrière un profil d'instance ou un compte de service, une fonction ou une définition de tâche derrière son rôle d'exécution, une charge de travail Kubernetes derrière son compte de service.

Les niveaux ne se cumulent qu'à l'intérieur d'un même périmètre (projet, organisation, compte). Un droit lu sur un projet et un droit d'écriture sur un autre ne donnent pas admin partout. Une identité ne sort jamais de son cloud ni, pour AWS et OUTSCALE, de son compte.

Chaque cloud exprime ses permissions à sa façon ; Ctadel traduit le vocabulaire de chaque cloud en couples (type de ressource, niveau) :

Cloud	Vocabulaire traduit	Ce qui n'est pas traduit
AWS	Préfixes d'actions IAM (`s3:GetObject`), le préfixe le plus long l'emporte	Une action non traduite n'accorde rien ; seul le caractère `*` seul accorde tout
Google Cloud	Rôles prédéfinis (`roles/editor`)	Les rôles personnalisés et les rôles prédéfinis non traduits n'accordent rien
Azure	Noms des rôles intégrés (Owner, Contributor, Storage Blob Data Reader) et préfixes d'actions RBAC (`Microsoft.Compute/virtualMachines/write`)	Les rôles personnalisés, connus par leur identifiant, n'accordent rien
Scaleway	Noms des ensembles de permissions tels que la documentation Scaleway les écrit	Les ensembles des produits non inventoriés (facturation, support, observabilité) n'accordent rien
OVHcloud	Actions `<produit>:apiovh:<route>/<méthode>` et groupes de permissions gérés par URN	Les produits hors inventaire
OUTSCALE	Actions EIM `api:<Verbe><Nom>` avec jokers, verbes OOS	Les noms hors des familles inventoriées

Les ressources atteignables sont les buckets, instances, volumes, bases, clusters Kubernetes, équilibreurs, réseaux privés, groupes de sécurité, secrets, registres, fonctions et conteneurs serverless, zones DNS, passerelles, IP flexibles, clés de chiffrement, serveurs dédiés, instantanés, projets et VPC. Ces relations alimentent l'explorateur et les chemins d'attaque.

Droits inutilisés

Pour chaque identité qui porte des politiques, le module compare ce qui lui est accordé à ce que les journaux d'audit du cloud montrent qu'elle utilise, et produit une recommandation par identité : actions accordées, actions vues, actions inutilisées, et un conseil par action inutilisée (retirer une action destructrice, d'administration ou d'écriture jamais exercée).

La télémétrie d'usage vient des journaux d'audit du cloud, lus par Ctadel et agrégés par identité et par action. Cette lecture fait partie de la détection sur journaux d'audit, en validation interne. Sans télémétrie pour un cloud, aucune identité de ce cloud ne reçoit de recommandation : « jamais utilisé » voudrait seulement dire « jamais vu ».

Les droits accordés et les appels observés ne sont pas dans le même vocabulaire. Le rapprochement est fait pour AWS (motifs d'actions avec jokers), OUTSCALE (oapi:ReadVms dans le journal pour api:ReadVms dans la politique), Scaleway (ensembles de permissions contre produit.Méthode) et OVHcloud (actions contre MÉTHODE /route). Une identité dont un appel ne peut pas être placé dans le vocabulaire de ses droits ne reçoit pas de recommandation, plutôt qu'une fausse. Les recommandations des identités disparues sont retirées.

Corrélation entre clouds

Le module relie les identités qui désignent la même personne ou la même machine dans deux clouds différents :

Identités	Critère	Confiance	Valeur de « Correspondance »
Personnes	Même adresse électronique	Haute	`email`
Personnes	Nom d'utilisateur égal à la partie locale d'une adresse (les utilisateurs IAM AWS n'ont pas d'adresse)	Moyenne	`email_local_part`
Machines (comptes de service, rôles)	Même nom, séparateurs mis à part (`deploy_role` et `deploy-role`)	Moyenne	`name`

Les parties locales trop génériques (admin, root, ops, support et quelques autres) ne rapprochent personne ; une égalité d'adresse complète les rapproche quand même. Les rôles de service appartenant au fournisseur (AWSServiceRoleFor…) ne sont jamais corrélés. La corrélation est refaite après chaque inventaire.

Drapeaux de risque

« Sur-privilégié » : une politique attachée est jugée administrative à l'inventaire (Scaleway, OVHcloud, OUTSCALE), ou une politique accorde toutes les actions (* ou *:*).
« Sans MFA » : l'utilisateur n'a pas de second facteur d'après l'inventaire.
« Actions inutilisées » : l'identité a une recommandation de moindre privilège.

La page Identités

La page « Identité & Accès » (entrée « Identités » du menu, sous « Inventaire ») a quatre onglets. Chaque onglet a un champ de recherche, des filtres et un bouton « Exporter CSV ».

Onglet	Colonnes	Filtres
« Utilisateurs »	« Utilisateur », « Cloud », « Statut », « MFA », « Sur-privilégié », « Politiques », « Groupes », « Actions inutilisées »	« Cloud », « Statut », « MFA », « Risque »
« Comptes de service »	« Nom », « Cloud », « Politiques », « Clés API », « Actions inutilisées »	« Cloud », « Permissions »
« Rôles »	« Rôle », « Cloud », « Type » (« Service » ou « Personnalisé »), « Dernière utilisation », « Politiques », « Actions inutilisées »	« Cloud », « Type », « Utilisé »
« Multi-Cloud »	« Source », « Correspondance », « Cible », « Ressources » (nombre de ressources atteintes de chaque côté)	« Cloud source », « Cloud cible », « Correspondance »

L'onglet « Comptes de service » réunit les applications Scaleway et OVHcloud, les comptes de service Google Cloud et les service principals Azure.

Limites

Les droits effectifs ne couvrent que les types de ressources listés plus haut et les familles de permissions traduites. Une permission non traduite n'accorde rien : le module sous-estime plutôt qu'il ne surestime.
Les rôles personnalisés Google Cloud et Azure ne sont pas traduits.
Les recommandations de moindre privilège dépendent de la télémétrie des journaux d'audit, en validation interne ; sans elle, la colonne « Actions inutilisées » reste vide. Elles ne concernent que les identités porteuses de politiques (utilisateurs, comptes de service, rôles), jamais les identités Google Cloud et Azure, dont les appels ne sont pas rapprochés des droits.
La « Dernière utilisation » d'un rôle et la distinction « Service » ou « Personnalisé » viennent d'AWS ; les rôles des autres clouds n'ont pas ces informations.
OUTSCALE n'expose aucun fait MFA par utilisateur : le filtre « Sans MFA » n'a pas de sens pour ce cloud.
Le drapeau « Sur-privilégié » se fonde sur les politiques attachées. Les rôles d'annuaire privilégiés d'Entra sont relevés sur l'utilisateur et les service principals, mais ne posent pas ce drapeau sur cette page.
Sur Google Cloud, les utilisateurs et groupes humains n'existent dans le graphe que s'ils sont nommés dans une liaison IAM ; ils n'ont ni statut ni MFA.
Pour Azure, certaines propriétés restent inconnues quand la permission Graph correspondante manque (rôles d'annuaire, activité de connexion, inscription MFA) ; elles ne sont pas mises à false.
Une identité n'est jamais corrélée à une autre du même cloud.