Configuration cloud (CSPM)
Les contrôles de configuration joués sur le graphe, les familles de ressources relevées par cloud, la dérive entre code et cloud, la page AI-SPM et les règles désactivées.
Le module de configuration cloud compare la configuration de vos ressources à un catalogue de règles et produit un constat par ressource non conforme. Il ne lit rien directement chez le fournisseur : il travaille sur le graphe que les collecteurs ont rempli.
Comment une règle est jouée
- Le collecteur de chaque cloud relève la configuration des ressources du compte et l'écrit dans le graphe.
- À la fin de l'inventaire, Ctadel joue la liste des règles actives sur le graphe.
- Chaque règle décrit une condition sur le graphe, en lecture seule. Chaque ressource qui l'enfreint devient un constat, identifié par la règle et la ressource.
- Les constats sont enregistrés, puis affichés dans la page « CSPM ». Un constat dont la ressource ne ressort plus à l'inventaire suivant est fermé.
Une règle qui n'a pas pu être jouée jusqu'au bout n'est pas lue comme « aucune infraction » : ses constats existants sont conservés en l'état. Une ressource peut aussi être réévaluée seule, par exemple après une correction.
Chaque règle porte une sévérité (CRITICAL, HIGH, MEDIUM, LOW), une catégorie et un ou plusieurs clouds. Le texte d'impact, le scénario d'attaque et les étapes de correction sont composés à partir d'un gabarit par cloud et par service ; quand aucun gabarit propre n'existe, un texte générique est utilisé.
Familles de ressources relevées par cloud
Le tableau donne ce que le collecteur de chaque cloud lit. Une famille absente de cette liste n'est pas relevée, et aucune règle ne peut porter sur elle.
| Cloud | Familles relevées |
|---|---|
| AWS | Compte et rapport d'identifiants ; IAM (utilisateurs, groupes, rôles, politiques, identifiants de service) ; EC2 (instances, volumes, instantanés, groupes de sécurité, IP élastiques, groupes d'auto-scaling) ; VPC et appairages ; S3 ; RDS et clusters de bases ; DynamoDB ; ElastiCache ; EFS ; EKS (groupes de nœuds, entrées d'accès) ; ECS ; ECR ; Lambda et couches ; API Gateway ; CloudFront ; ELB ; Route 53 ; ACM ; KMS ; Secrets Manager ; CloudTrail ; CloudWatch ; Config ; GuardDuty ; Security Hub ; WAF ; Shield ; Backup ; Cognito ; SNS et SQS ; EventBridge ; Glue ; Athena ; EMR ; OpenSearch ; CodeBuild ; Amplify ; Lightsail ; Bedrock ; SageMaker |
| Azure | Locataire et abonnement ; Entra (utilisateurs, service principals, affectations de rôles) ; machines virtuelles et disques ; comptes de stockage ; Key Vault et Managed HSM ; SQL ; PostgreSQL flexible ; Cosmos DB ; Redis ; AKS ; registre de conteneurs ; App Service ; Functions ; Logic Apps ; API Management ; Application Gateway ; Front Door ; Azure Firewall ; réseau (réseaux virtuels, NSG, interfaces) ; points de terminaison privés ; DNS ; Event Hubs ; Service Bus ; Data Factory ; Synapse ; HDInsight ; Recovery Services ; Defender ; Monitor et journal d'activité ; App Configuration ; Cognitive Services, dont Azure OpenAI ; AI Search |
| Google Cloud | Organisation et métadonnées de projet ; IAM et politiques IAM ; Compute Engine ; réseau, pare-feu et équilibreurs ; Cloud Armor ; Cloud Storage ; Cloud SQL ; BigQuery ; Memorystore ; GKE ; Cloud Functions ; Artifact Registry ; Cloud Build ; Pub/Sub ; Dataproc ; Dataflow ; Composer ; Cloud DNS ; KMS ; Logging ; Monitoring ; Security Command Center ; Vertex AI Workbench |
| Scaleway | IAM et politiques ; instances ; Elastic Metal ; volumes et instantanés ; Object Storage (buckets et ACL) ; bases de données ; Kapsule ; registre ; conteneurs et fonctions serverless ; Key Manager ; Secret Manager ; équilibreurs ; VPC et passerelles ; groupes de sécurité ; IP flexibles ; domaines |
| OVHcloud | IAM ; instances ; serveurs dédiés ; volumes et instantanés ; buckets ; bases de données ; MKS ; registre ; serverless ; KMS et clés ; réseau ; DNS |
| OUTSCALE | EIM ; machines virtuelles ; images OMI ; volumes BSU ; buckets OOS ; équilibreurs LBU ; réseau et groupes de sécurité ; OKS ; VPN et DirectLink |
Des règles portent aussi sur les objets Kubernetes présents dans le graphe (charges de travail, espaces de noms, comptes de service, RBAC, services). Ces objets sont écrits par le module Kubernetes ; sans cluster connecté, ces règles ne retournent rien. Certaines de ces règles lisent les constats du module Kubernetes plutôt que la ressource elle-même.
Catégories
Chaque règle appartient à une catégorie, reprise dans le filtre « Catégorie » de la page. Les catégories du catalogue sont : réseau, base de données, calcul, stockage, audit, données, IA, Kubernetes, web, IAM, journalisation, identité, supervision, chiffrement, sauvegarde, conteneurs, messagerie, serverless, secrets, DNS, sécurité et gestion de clés. Les libellés affichés sont ceux du catalogue (en anglais : Network, Database, Compute, et ainsi de suite).
La page CSPM
La page « CSPM » liste les constats ouverts et fermés avec les colonnes « Sévérité », « Statut », « Règle », « Catégorie », « Source » et « Ressource ». Les filtres portent sur « Sévérité », « Statut », « Catégorie », « Source » et « Type de ressource » ; le regroupement sur « Sévérité », « Catégorie », « Type de ressource » ou « Règle ». Le bouton « Exporter CSV » exporte la liste filtrée. Un clic sur une ligne ouvre le panneau de détail du constat, décrit dans Lire un constat.
Dérive entre code et cloud
Quand un dépôt Git est connecté, une règle CSPM peut être appariée à une règle Terraform du module Infrastructure as code qui vérifie le même réglage, dans le même sens, sur la même ressource. L'appariement est fixé par Ctadel, règle par règle ; une règle sans paire n'a pas de statut de dérive. La colonne « Source » prend alors une des valeurs suivantes :
| Valeur | Signification |
|---|---|
| « Cloud uniquement » | Aucun code ne déclare la ressource, ou la règle n'a pas de paire. |
| « Code & Cloud » | Un constat IaC ouvert existe pour la règle appariée, sur la même ressource : le défaut est dans le code et il est déployé. |
| « DÉRIVE » | La ressource est gérée par du code (elle est reliée à une ressource IaC par une étiquette ctadel:id résolue) et aucun constat IaC ne correspond : le cloud a divergé de son code. |
Le rapprochement d'une ressource Terraform et d'une ressource cloud se fait par le nom : le nom de la ressource Terraform doit être le dernier segment de l'identifiant cloud, après un / ou un :. Par exemple la ressource data_bucket correspond à arn:aws:s3:::data_bucket. Sans dépôt Git connecté, la colonne reste à « Cloud uniquement » pour tous les constats.
AI-SPM
La page « AI-SPM » (titre « Posture de sécurité IA ») affiche les constats CSPM dont la règle porte sur un service d'IA. Ces règles ont la catégorie AI ; la page « CSPM » affiche toutes les autres catégories. Le tableau et le panneau de détail sont les mêmes.
| Service | Objets relevés |
|---|---|
| Amazon Bedrock | Agents, garde-fous, modèles personnalisés et importés, bases de connaissances |
| Amazon SageMaker | Instances de notebook, configurations de point de terminaison, modèles, domaines, définitions de tâches de qualité des données, définitions de flux |
| Vertex AI | Instances Workbench uniquement |
| Azure OpenAI | Comptes Cognitive Services (dont OpenAI), leurs déploiements et leurs politiques d'IA responsable |
| Azure AI Search | Services AI Search |
Règles désactivées
Une partie du catalogue est livrée désactivée, avec la raison écrite dans la description de la règle, sous la forme Disabled: <raison>. La page « Politiques » affiche ces règles avec leur état. Ces règles restent dans le catalogue et ne produisent aucun constat.
Limites
- Le module ne voit que ce que les collecteurs écrivent. Un service sans collecteur, ou un réglage que l'API du cloud ne renvoie pas, ne peut produire aucun constat, même si une règle le nomme.
- Une évaluation interrompue laisse les règles restantes non jouées : leurs constats ne sont ni créés ni fermés jusqu'à l'inventaire suivant.
- Le statut de dérive n'existe que pour les règles appariées à une règle Terraform. Une ressource dont le nom Terraform ne termine pas l'identifiant cloud n'est pas rapprochée. Le statut « DÉRIVE » suppose une étiquette
ctadel:idposée par le dépôt et résolue dans le graphe. - Les règles sur les objets Kubernetes ne s'appliquent qu'aux clusters connectés au module Kubernetes.
- Pour Vertex AI, seules les instances Workbench sont relevées ; les tâches d'import de modèles Bedrock ne sont pas modélisées.
- Les textes d'impact et de correction d'une règle sans gabarit propre sont génériques.
- Les règles désactivées apparaissent dans le catalogue mais ne produisent rien.