Sécurité du scan

Vous êtes sur le point d'autoriser un outil externe à lire votre environnement infonuagique. C'est une décision sérieuse, et vous avez raison de vouloir savoir exactement ce qu'elle engage avant de l'accorder. Cette page répond à l'avance, avec les noms de rôles précis plutôt que des formules rassurantes.

1. Ce n'est pas nous qui nous connectons

Le point le plus important, et celui qu'on attend le moins : vous ne nous confiez aucun accès à votre console. Vous exécutez vous-même un script, dans votre propre environnement, avec vos propres identifiants d'administrateur. Ce script crée une identité de lecture seule dans votre locataire, et vous remet des identifiants. Vous décidez ensuite de les coller, ou non, dans CloudNorma.

Nous ne voyons jamais vos identifiants d'administrateur. Nous ne lançons rien chez vous. Le script est en texte clair, lisible avant exécution — c'est du PowerShell, pas un binaire.

2. Les permissions exactes, par fournisseur

Microsoft Azure

Un principal de service est créé dans votre locataire Entra ID, avec trois rôles à la portée de l'abonnement que vous désignez :

S'y ajoutent trois autorisations d'application Microsoft Graph, en lecture seule, nécessaires à neuf contrôles CIS portant sur l'identité :

Sans ces trois autorisations, le scan fonctionne : les neuf contrôles d'identité sont simplement rapportés comme non évalués, jamais comme conformes ou non conformes à tort.

Amazon Web Services

Un utilisateur IAM est créé dans votre compte, avec une seule politique gérée par AWS :

Ce que nous avons volontairement retiré. Jusqu'au 11 octobre 2026, notre script attachait aussi ReadOnlyAccess. Cette politique dépasse la configuration : elle accorde s3:GetObject, donc la lecture du contenu de vos seaux. Nous l'avons retirée. Un outil qui vend de la conformité ne peut pas demander plus que ce dont il a besoin.

Google Cloud Platform

Un compte de service est créé dans votre projet, avec six rôles prédéfinis et un rôle sur mesure de deux permissions, tous en lecture :

Nous n'utilisons aucun rôle de base — ni roles/viewer, ni editor, ni owner. Google déconseille lui-même les rôles de base en production, et viewer aurait inclus storage.objects.get, c'est-à-dire la lecture du contenu de vos objets. Chaque rôle ci-dessus est accordé parce qu'un contrôle CIS précis l'exige.

Pourquoi un rôle sur mesure plutôt qu'un rôle prédéfini de plus. Deux contrôles avaient besoin de permissions qu'aucun des six rôles n'apporte. Le réflexe aurait été d'ajouter roles/compute.viewer. Nous avons lu son contenu avant : ses 427 permissions incluent compute.instances.getSerialPortOutput et compute.instances.getScreenshot — la console série d'une machine et une capture de son écran. La console série contient des journaux de démarrage, parfois des secrets. Ce serait lire le contenu d'une machine, exactement ce que cette page vous promet de ne pas pouvoir faire. Nous avons donc nommé les deux permissions, et rien d'autre.

3. Ce que nous ne pouvons pas faire, même en le voulant

• Écrire, modifier, supprimer ou déplacer quoi que ce soit. Aucun des rôles ci-dessus ne contient une permission d'écriture.
• Lire le contenu d'un fichier, d'un objet, d'une base de données ou d'une file de messages.
• Lire la valeur d'un secret, d'une clé ou d'un certificat.
• Installer un agent. CloudNorma interroge les API de votre fournisseur. Rien n'est déposé dans votre environnement, donc rien n'est à désinstaller, et votre surface d'attaque n'augmente pas.
• Accéder à un autre abonnement, compte ou projet que celui que vous avez désigné. La portée est fixée à la création et ne s'étend pas d'elle-même.

4. Ce que nous conservons, et où

Les identifiants de lecture que vous nous confiez sont chiffrés au repos et ne servent qu'à exécuter vos scans. Les résultats conservés sont des scores, des écarts et des métadonnées de ressources — jamais le contenu des ressources elles-mêmes.

L'ensemble est hébergé sur Microsoft Azure, région Canada Central. Les données ne sortent pas du Canada dans le cadre normal du service. Le détail figure dans notre politique de confidentialité.

5. Révoquer, à tout moment, sans nous le demander

L'identité a été créée chez vous : vous la supprimez chez vous, et l'accès cesse immédiatement. Aucune intervention de notre part n'est requise, et nous ne pouvons pas nous y opposer.

Azure  az ad app delete --id <identifiant-de-l-application>
AWS    aws iam delete-access-key --user-name cloudnorma-scanner --access-key-id <cle>
GCP    gcloud iam service-accounts delete <compte>@<projet>.iam.gserviceaccount.com
       gcloud iam roles delete cloudnorma_scan_complement --project=<projet>

Sur GCP, la première commande coupe l'accès immédiatement ; la seconde retire le rôle sur mesure, qui ne sert plus une fois le compte supprimé.

Vous pouvez aussi agir depuis CloudNorma, en deux temps distincts. Retirer une connexion la met hors service immédiatement : plus aucun balayage n'est lancé, l'historique déjà produit est conservé, et l'opération est réversible. Supprimer définitivement est une seconde action, volontairement séparée : elle exige que la connexion ait d'abord été retirée et que vous retapiez son nom exact. C'est elle, et elle seule, qui détruit les identifiants chiffrés et l'historique associé — sans retour possible.

6. Ce que nous ne prétendons pas

Trois précisions, parce qu'une page de sécurité qui ne dit que du bien n'est pas crédible.

• CloudNorma n'est pas certifié SOC 2 ni ISO 27001 à ce jour. Nous appliquons les contrôles que nous mesurons chez nos clients, mais nous n'avons pas encore fait auditer notre propre organisation. Nous préférons l'écrire plutôt que de laisser croire le contraire.
• Notre couverture de la Loi 25 porte sur les exigences techniques traçables dans une infrastructure infonuagique. Elle ne couvre ni vos politiques internes, ni vos contrats, ni votre gouvernance documentaire.
• Un scan de configuration ne remplace pas un test d'intrusion ni une revue de code. Il établit l'état de votre infrastructure au regard de référentiels publics, ce qui est autre chose.

7. Une question que cette page n'a pas couverte

Écrivez à infos@xyconsulting.cloud. Si votre équipe de sécurité a un questionnaire fournisseur, envoyez-le : nous le remplissons.