Droits demandés
Par cloud, les droits de lecture que Ctadel demande, les droits d’écriture facultatifs de la copie des disques et des bases, et ce que le scanner crée puis supprime chez vous.
Cette page liste, cloud par cloud, ce que l’identité confiée à Ctadel peut faire chez vous : d’abord la lecture, qui suffit à l’inventaire et aux règles, puis les droits d’écriture facultatifs qui servent uniquement à copier un disque ou une base pour en lire le contenu.
Deux niveaux de droits
L’accès à vos comptes passe par les API des clouds. Il n’est pas « en lecture seule » dans son ensemble : l’inventaire ne fait que lire, mais les analyses de contenu créent des ressources chez vous. Il faut donc distinguer deux niveaux : des droits de lecture pour l’inventaire et la configuration, plus des droits de copie de disques et de bases pour les analyses de contenu.
Avec les seuls droits de lecture, Ctadel produit l’inventaire, la posture des comptes, des buckets, des bases et des clusters (CSPM, KSPM, AI-SPM), les identités et leurs permissions (CIEM), les combinaisons toxiques et les chemins d’attaque.
Trois analyses lisent du contenu et demandent plus :
| Analyse | Ce qu’elle lit | Droits en plus |
|---|---|---|
| Contenu des buckets | Les objets, en place, pour les secrets et les données sensibles | Lecture des objets (aucune écriture) |
| Disques des machines (Vulnérabilités, Secrets, Données et HCR sur les disques) | Une copie du volume, montée dans une machine éphémère créée dans votre compte | Création et suppression de snapshots, volumes, machines, clés et groupes de sécurité : des droits d’écriture |
| Bases de données | Une copie temporaire de l’instance, lue puis supprimée | Création et suppression d’une instance et d’un utilisateur sur la copie : des droits d’écriture |
Chacune se désactive sans effet sur le reste. Le contenu d’un disque ou d’une base ne quitte jamais votre compte : seuls les constats remontent vers votre instance.
Lecture par cloud
| Cloud | Identité | Droits de lecture |
|---|---|---|
| AWS | Un rôle que Ctadel endosse avec un ExternalId, ou une clé d’accès | SecurityAudit, ViewOnlyAccess et une liste d’actions complémentaires (voir ci-dessous) |
| Azure | Un service principal | Reader et Log Analytics Reader sur l’abonnement ; permissions d’application Microsoft Graph en lecture |
| Google Cloud | Une clé de compte de service, ou une fédération external_account sans clé | roles/viewer, roles/iam.securityReviewer, roles/browser et des rôles de lecture ciblés |
| Scaleway | Une application IAM | AllProductsReadOnly, IAMReadOnly, OrganizationReadOnly |
| OVHcloud | Une application API et une Consumer Key | Routes GET listées, plus POST .../openstack/token et POST .../kube/*/kubeconfig |
| OUTSCALE | Un utilisateur EIM avec une clé d’accès à expiration | api:Read* et la lecture de configuration des buckets OOS |
AWS
Le mode recommandé est un rôle créé dans votre compte par le gabarit CloudFormation fourni par Ctadel : aucune clé permanente ne sort de chez vous, et supprimer la pile CloudFormation coupe l’accès. Le rôle n’est endossable que par le principal de votre instance Ctadel et avec l’ExternalId que vous générez dans l’application. Ctadel demande une session de 12 heures (MaxSessionSeconds, de 3 600 à 43 200 secondes) et se replie sur une heure si le rôle l’interdit.
Le rôle porte les politiques gérées SecurityAudit et ViewOnlyAccess, plus une politique CtadelReadExtras qui ajoute : iam:GenerateCredentialReport, iam:GetCredentialReport, shield:DescribeSubscription, shield:ListProtections, elasticloadbalancing:DescribeSSLPolicies, lambda:GetFunction, lambda:GetFunctionConfiguration, ecr:GetRepositoryPolicy, elasticfilesystem:DescribeFileSystemPolicy, eks:ListAccessEntries, eks:DescribeAccessEntry, eks:ListAssociatedAccessPolicies, ec2:DescribeTransitGatewayAttachments, ec2:GetSnapshotBlockPublicAccessState, ec2:GetImageBlockPublicAccessState, redshift-serverless:ListNamespaces, redshift-serverless:ListWorkgroups, appsync:GetApiCache, wafv2:GetWebACLForResource, cloudwatch:GetMetricData, route53resolver:ListResolverQueryLogConfigAssociations, les lectures bedrock:*, bedrock-agentcore:* et sagemaker:* de l’inventaire IA, et iam:ListServiceSpecificCredentials. lambda:GetFunction renvoie une URL de téléchargement du code des fonctions, analysé pour les secrets, les données sensibles et les paquets vulnérables.
Les options du gabarit, toutes à true par défaut sauf EnableSSMTransport, à false :
| Paramètre | Droits ajoutés | Sans lui |
|---|---|---|
EnableBucketScanning | s3:GetObject, s3:GetObjectVersion, kms:Decrypt limité au service S3 | Posture des buckets conservée, contenu non lu |
EnableDiskScanning | Politique CtadelDiskScanning (voir plus bas) | Rien sur les disques des machines |
EnableDatabaseScanning | Politique CtadelDatabaseScanning (voir plus bas) | Posture des bases conservée, contenu non lu |
EnableKubernetesAccess | eks:CreateAccessEntry, eks:DescribeAccessEntry, eks:AssociateAccessPolicy | Vous créez vous-même l’entrée d’accès du cluster |
EnableRuntimeEvents | sqs:ReceiveMessage, sqs:DeleteMessage, sqs:GetQueueAttributes, sqs:GetQueueUrl | CloudTrail lu à chaque scan par cloudtrail:LookupEvents |
EnableSSMTransport | iam:PassRole sur un rôle d’instance dédié, ssm:SendCommand limité au document AWS-RunShellScript et aux instances étiquetées ctadel-managed, lecture des résultats de commande | Le scanner est joint en SSH |
Avec une clé d’accès à la place du rôle, attachez SecurityAudit et ViewOnlyAccess à un utilisateur IAM ; le secret est alors stocké chiffré dans votre instance, voir Données et chiffrement.
Azure
Sur l’abonnement : Reader (inventaire ARM, affectations de rôles, journal d’activité) et Log Analytics Reader. Pour le contenu des blobs : Storage Blob Data Reader ; Ctadel obtient un jeton Entra pour https://storage.azure.com/ et n’appelle jamais listKeys, qui livrerait une clé de compte en écriture. Pour les Azure Functions : un rôle personnalisé avec Microsoft.Web/sites/config/list/action et Microsoft.Web/sites/publish/action, et AcrPull sur le registre des fonctions conteneurisées ; sans eux la fonction est rapportée non lue.
Pour les clusters AKS, Ctadel obtient le kubeconfig par listClusterAdminCredential, une action absente de Reader : elle demande le rôle « Azure Kubernetes Service Cluster Admin Role » sur le cluster, et le kubeconfig obtenu est un kubeconfig d’administrateur. Sans ce rôle, la posture AKS lue par ARM reste, mais les objets du cluster ne sont pas lus.
Permissions d’application Microsoft Graph, avec consentement administrateur : Application.Read.All, Directory.Read.All, User.Read.All, Policy.Read.All, AccessReview.Read.All, AuditLog.Read.All, Reports.Read.All. Une permission absente laisse la propriété correspondante inconnue, jamais « conforme ».
Google Cloud
Au niveau de l’organisation, ou du projet en mode mono-projet : roles/viewer, roles/iam.securityReviewer, roles/browser. Des règles précises demandent roles/accessapproval.viewer, roles/policyanalyzer.activityAnalysisViewer, roles/monitoring.viewer, roles/logging.viewer et roles/serviceusage.serviceUsageViewer. Le fichier d’identifiants peut être un external_account (fédération d’identité) qui ne contient aucune clé privée.
Scaleway
Une application IAM dont la politique porte AllProductsReadOnly, IAMReadOnly et OrganizationReadOnly, à l’échelle de l’organisation.
OVHcloud
Une application API sur eu.api.ovh.com et une Consumer Key sans date d’expiration, limitée aux routes GET de /me, /me/api/*, /me/identity/user*, /iam/policy*, /cloud/project/{projectId}*, /dedicated/server* et /domain/zone*, plus POST /cloud/project/{projectId}/openstack/token et POST /cloud/project/{projectId}/kube/*/kubeconfig. Les clés API ne lisent pas les objets : le contenu des buckets demande un utilisateur Object Storage du projet et ses identifiants S3, facultatifs.
OUTSCALE
Un utilisateur EIM sans accès console, une politique créée depuis le document de politique de lecture fourni par Ctadel (api:Read* et sept lectures de configuration OOS) et une clé d’accès avec date d’expiration. L’API étant régionale, une entrée de compte par région.
Écriture : la copie des disques
Pour chaque volume analysé, le scanner de disques crée dans votre compte un snapshot, un volume restauré depuis ce snapshot, puis une machine éphémère à laquelle il attache ce volume ; il lit la copie, puis libère les trois dans l’ordre inverse. La libération a lieu au succès, à l’échec de n’importe quelle étape, à l’annulation et en cas d’arrêt inattendu du scan.
| Cloud | Droits d’écriture | Ce qui est créé, où | Marquage |
|---|---|---|---|
| AWS | ec2:CreateSnapshot, CreateVolume, ImportKeyPair, CreateSecurityGroup, AuthorizeSecurityGroupIngress, RunInstances, AttachVolume ; CreateTags uniquement pendant ces créations ; TerminateInstances, DetachVolume, DeleteVolume, DeleteSnapshot, DeleteKeyPair, DeleteSecurityGroup uniquement sur les ressources étiquetées ctadel-managed=true | Snapshot, volume, paire de clés, groupe de sécurité et instance dans la région et la zone du volume source | Name=ctadel-scanner-ephemeral, ctadel-managed=true |
| Azure | Création de snapshot, disque, groupe de sécurité réseau, adresse publique, interface et machine, et création d’un groupe de ressources ctadel-scan-<région> avec son réseau virtuel | Tout dans le groupe de ressources ctadel-scan-<région> de votre abonnement | ctadel-managed=true |
| Google Cloud | Snapshot, disque, règle de pare-feu et instance | Dans le projet du disque source | Libellé ctadel-managed=true, étiquette réseau ctadel-scanner, règle ctadel-ssh-* |
| Scaleway | Snapshot (API Block ou Instance), volume, groupe de sécurité et serveur | Dans le projet du compte connecté | Tags ctadel-scanner et ephemeral, volume ctadel-temp-sbs-*, snapshot ctadel-scan-snap-* |
| OVHcloud | POST .../volume/*/snapshot, DELETE .../volume/snapshot/*, POST .../volume/*/attach, POST .../volume/*/detach, DELETE .../volume/*, POST .../instance, DELETE .../instance/* | Dans le projet Public Cloud connecté | Noms ctadel-snap-*, ctadel-vol-*, ctadel-scanner-* |
| OUTSCALE | api:CreateSnapshot, CreateVolume, LinkVolume, UnlinkVolume, CreateVms, DeleteVms, CreateKeypair, DeleteKeypair, CreateSecurityGroup, CreateSecurityGroupRule, DeleteSecurityGroup, CreatePublicIp, LinkPublicIp, UnlinkPublicIp, DeletePublicIp, DeleteVolume, DeleteSnapshot, CreateTags | Dans la sous-région du volume source | Name=ctadel-scanner-ephemeral, ctadel-managed=true, clé et groupe ctadel-scanner-* |
Sur AWS, le gabarit conditionne ec2:CreateTags à l’action de création en cours : le rôle ne peut pas étiqueter une de vos ressources existantes pour la rendre supprimable, et les suppressions ne portent que sur ce qui a été créé avec l’étiquette.
Écriture : la copie des bases
Seules les bases PostgreSQL sont lues ; les autres moteurs sont refusés avant toute copie, et un cluster Aurora n’est pas pris en charge. Le scanner de bases crée la copie, y crée un compte de lecture, lance l’analyse puis supprime la copie, quelle que soit l’issue de l’analyse.
| Cloud | Droits d’écriture | Ce qui est créé | Nettoyage |
|---|---|---|---|
| AWS | rds:CreateDBSnapshot, RestoreDBInstanceFromDBSnapshot, ModifyDBInstance, AddTagsToResource ; DeleteDBInstance et DeleteDBSnapshot uniquement sur les ressources étiquetées ctadel-managed=true | Un snapshot, puis une instance db.t3.micro restaurée dans le groupe de sous-réseaux de la source, un groupe de sécurité temporaire qui n’accepte que l’adresse de sortie de votre instance Ctadel ; le mot de passe maître est réinitialisé sur la copie seulement | Instance supprimée sans snapshot final, snapshot supprimé, groupe de sécurité supprimé |
| Google Cloud | Clonage par l’API Cloud SQL Admin, création d’un utilisateur, suppression | Une instance ctadel-dspm-<horodatage> dans le projet de la source | Instance supprimée |
| Scaleway | Clonage RDB, création d’un utilisateur, suppression | Une instance ctadel-dspm-clone-<horodatage> de type DB-PLAY2-PICO | Instance supprimée |
| Azure, OVHcloud, OUTSCALE | Aucun | Les bases managées de ces clouds ne sont pas copiées | Sans objet |
Le scanner éphémère
- Le contenu reste chez vous. La machine éphémère lit la copie du disque à l’intérieur de votre compte ; seuls les constats sont renvoyés.
- Un port, une source. Le groupe de sécurité, le NSG ou la règle de pare-feu n’ouvre que le port 22, et seulement depuis l’adresse de sortie de votre instance Ctadel (fixée à la configuration de l’instance, sinon découverte automatiquement). Sans plage utilisable, le scan échoue plutôt que d’ouvrir le port.
- Des clés par scan. Le scanner génère pour chaque scan la clé de connexion et la clé d’hôte SSH de la machine, les transmet par les données utilisateur, et refuse toute autre clé d’hôte. Chez OVHcloud, aucune clé n’est enregistrée par l’API.
- Sans adresse publique. Par compte, dans « Paramètres », « Intégrations », « Fournisseurs cloud », la section « Réseau du scanner de disques (facultatif) » épingle un sous-réseau et retire l’adresse publique (AWS, OUTSCALE, Google Cloud) ; cela suppose un chemin privé entre votre instance et le réseau concerné. Sur AWS, le transport SSM supprime toute règle entrante et toute adresse.
- Balayage des orphelins. Au plus une fois par heure et par compte, Ctadel supprime les ressources de scan de plus de deux heures qui portent ses étiquettes ou ses noms, pour qu’un arrêt brutal ne laisse rien de facturé.
Limites
- Accès Kubernetes sur AWS. Avec
EnableKubernetesAccessàtrue, Ctadel crée une entrée d’accès EKS pour le rôle et lui associe la politiqueAmazonEKSClusterAdminPolicy, soit des droits d’administration du cluster, alors que la lecture suffit. Pour n’accorder que la lecture, mettez le paramètre àfalseet créez l’entrée d’accès vous-même, voir Connecter Kubernetes. - Accès Kubernetes sur Azure. Le kubeconfig AKS est demandé par
listClusterAdminCredential: le rôle accordé donne l’administration du cluster, pas seulement la lecture. Ctadel n’utilise paslistClusterUserCredential. Pour n’accorder que la lecture, enregistrez vous-même un kubeconfig à droits restreints pour ce cluster dans « Intégrations », « Kubernetes » : un kubeconfig fourni prend le pas sur les identifiants cloud, voir Connecter Kubernetes. - Copie de base sur AWS. Le groupe de sécurité temporaire de la copie est créé avec des actions
ec2:*qui figurent dans la politique de la copie des disques, pas dans celle des bases : avecEnableDiskScanningàfalseetEnableDatabaseScanningàtrue, la copie de base échoue. - Périmètre des droits d’écriture hors AWS. Chez Azure, Google Cloud, Scaleway et OVHcloud, Ctadel nomme les droits d’écriture sans fournir de gabarit qui les restreigne par étiquette : la restriction aux seules ressources étiquetées repose sur votre configuration IAM. Les ressources sont créées dans l’abonnement, le projet ou le compte analysé, pas dans un espace séparé.
- Droits non documentés. Le clonage Cloud SQL et le clonage RDB demandent des droits d’écriture sur ces services que la documentation d’intégration ne liste pas encore ; demandez-les à Ctadel lors de la mise en place. Chez Azure, la création du groupe de ressources
ctadel-scan-<région>et de son réseau virtuel demande plus queDisk Snapshot Contributor. - Buckets OUTSCALE. La politique fournie ne contient ni
oos:ListBucketnioos:GetObject: sans les ajouter, le contenu des buckets OOS n’est pas lu. - Sortie Internet du scanner. Au premier démarrage, la machine éphémère installe ses outils d’analyse depuis des dépôts publics : elle a besoin d’un accès sortant vers Internet. Sans lui, l’inventaire des paquets vulnérables est vide.
- Copies de bases orphelines. Il n’existe pas de balayage des copies de bases laissées par un arrêt brutal, contrairement aux ressources de disque.
- Adresse publique de la copie de base AWS. La copie est publiquement accessible ou non selon un réglage global de l’instance, fixé par Ctadel, pas selon le réglage par compte.
- Événements d’exécution. Les droits
EnableRuntimeEventset les rôles de lecture des journaux d’audit sont demandés par les gabarits, mais la détection sur ces journaux est en validation interne, non disponible pour les clients.