# Scan Cloud : guide de remédiation des vulnérabilités Le Cloud Scan analyse votre environnement cloud (Microsoft Azure / Entra ID / Microsoft 365, AWS ou Google Cloud) et signale les mauvaises configurations qui pourraient être exploitées par des attaquants. Contrairement aux vulnérabilités logicielles qui nécessitent des correctifs, la plupart des constats cloud sont **des problèmes de configuration** qui peuvent être corrigés directement depuis la console d’administration de votre fournisseur cloud. Chaque section comprend : * **Ce que cela signifie :** une explication du risque en langage clair * **Ce que l'analyse vérifie :** la condition spécifique qui déclenche l’alerte * **Comment corriger :** des instructions étape par étape ## Microsoft Azure / Entra ID / Microsoft 365 Ces constats s’appliquent aux organisations qui utilisent les services cloud Microsoft (abonnements Azure, Microsoft 365, Entra ID / Azure Active Directory). ### Utilisateurs privilégiés sans MFA **Gravité : élevée** #### Ce que cela signifie L’authentification multifacteur (MFA) ajoute une seconde couche de sécurité lors de la connexion — généralement un code provenant d’une application mobile ou une clé matérielle. Sans MFA, si un attaquant devine ou vole le mot de passe d’un administrateur (par hameçonnage, fuite de données ou attaque par force brute), il obtient un accès complet à votre environnement cloud, sans autre barrière pour l’en empêcher. Ce constat signale **les comptes administrateur qui n’ont pas la MFA activée**. Ce sont les comptes les plus sensibles de votre organisation — un compte administrateur compromis peut conduire à un contrôle total de votre messagerie, de vos fichiers et de votre infrastructure. #### Ce que l'analyse vérifie Le scan examine tous les utilisateurs ayant des rôles privilégiés (Administrateur général, Administrateur d’application, Administrateur de la sécurité, etc.) et vérifie s’ils ont enregistré la MFA. L’alerte se déclenche si un utilisateur privilégié a la MFA désactivée. #### Comment corriger **Option A : activer les paramètres de sécurité par défaut (la plus simple)** Si vous n’avez pas encore de stratégies d’Accès conditionnel, les paramètres de sécurité par défaut sont le moyen le plus rapide d’imposer la MFA à tous les utilisateurs : 1. Accédez à [Entra ID](https://entra.microsoft.com) > `Identité` > `Vue d'ensemble` > `Propriétés`. 2. Cliquez sur `Gérer les paramètres de sécurité par défaut`. 3. Définir sur `Activé`. **Option B : utiliser l’Accès conditionnel (recommandé pour les grandes organisations)** 1. Accédez à [Entra ID](https://entra.microsoft.com) > `Protection` > `Accès conditionnel`. 2. Cliquez sur `+ Nouvelle stratégie`. 3. Nommez-la : « Exiger la MFA pour les administrateurs ». 4. Sous `Utilisateurs`: sélectionnez `Rôles du répertoire` et choisissez tous les rôles d’administration (Administrateur général, Administrateur de la sécurité, etc.). 5. Sous `Accorder`: sélectionnez `Exiger l’authentification multifacteur`. 6. Définissez la stratégie sur `Activé` et enregistrez. Après avoir créé la stratégie, chaque administrateur sera invité à configurer la MFA lors de sa prochaine connexion. ### Utilisateurs Shadow Admin **Gravité : faible** #### Ce que cela signifie Un « Shadow Admin » est un utilisateur qui dispose de droits administratifs sans être un administrateur évident. Il possède des rôles comme « Administrateur des mots de passe » ou « Administrateur du service d’assistance », qui lui donnent des autorisations importantes (par exemple, réinitialiser le mot de passe de n’importe qui, gérer des applications), mais il peut ne pas être soumis aux mêmes contrôles de sécurité (MFA, revues d’accès) que les administrateurs officiellement reconnus. Le risque est que ces comptes passent sous le radar : ils n’apparaissent pas dans la liste des « Administrateurs généraux », mais un attaquant qui en compromet un peut tout de même causer de sérieux dégâts — par exemple réinitialiser le mot de passe d’un Administrateur général et prendre le contrôle de l’ensemble du tenant. #### Ce que l'analyse vérifie Le scan identifie les utilisateurs attribués à l’un de ces rôles Entra ID : * Administrateur d’application * Administrateur d’authentification * Administrateur d’application cloud * Administrateur du service d’assistance * Administrateur des mots de passe * Administrateur d’authentification privilégiée * Administrateur des rôles privilégiés * Administrateur de compte utilisateur Les utilisateurs qui ont également le rôle d’Administrateur général sont exclus (ils sont déjà visibles en tant qu’administrateurs complets). #### Comment corriger 1. Accédez à [Entra ID](https://entra.microsoft.com) > `Rôles et administrateurs`. 2. Cliquez sur chacun des rôles listés ci-dessus. 3. Passez en revue la liste des utilisateurs attribués. Pour chaque utilisateur, demandez : * **Cette personne a-t-elle réellement besoin de ce rôle ?** Sinon, supprimez-le. * **S’agit-il d’une attribution permanente ?** Envisagez d’utiliser [Privileged Identity Management (PIM)](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/) pour un accès juste-à-temps plutôt que des attributions de rôle permanentes. * **La MFA est-elle activée pour cet utilisateur ?** Les Shadow Admin doivent avoir les mêmes exigences MFA que les administrateurs complets. ### Pourcentage élevé d’utilisateurs privilégiés **Gravité : moyenne** #### Ce que cela signifie Plus de **10 % de vos utilisateurs** ont des rôles d’administrateur dans Entra ID. C’est le signe que les permissions d’administration ont été accordées de manière trop large — peut-être par commodité, ou parce qu’un accès temporaire n’a jamais été révoqué. Chaque compte administrateur est un point d’entrée potentiel pour un attaquant. Réduire le nombre d’administrateurs limite l’impact en cas de compromission d’un compte. #### Ce que l'analyse vérifie Le scan compte le nombre total d’utilisateurs disposant d’un rôle d’administration et le compare au nombre total d’utilisateurs activés. L’alerte se déclenche si le ratio dépasse 10 %. #### Comment corriger 1. Accédez à [Entra ID](https://entra.microsoft.com) > `Rôles et administrateurs`. 2. Pour chaque rôle d’administration, vérifiez qui est attribué. 3. Supprimez les utilisateurs qui n’ont plus besoin d’un accès administrateur. 4. Pour les utilisateurs qui n’ont besoin d’un accès administrateur qu’occasionnellement, utilisez **Privileged Identity Management (PIM)** pour une élévation juste-à-temps. ### Utilisateurs sans MFA **Gravité : élevée** #### Ce que cela signifie Certains utilisateurs de votre organisation n’ont pas la MFA activée. Sans MFA, un mot de passe volé ou deviné suffit à un attaquant pour accéder à leur boîte de réception, à leurs fichiers et à toutes les applications auxquelles ils ont accès. C’est ainsi que se produisent la majorité des attaques de compromission de messagerie professionnelle (BEC) : un attaquant hameçonne le mot de passe d’un utilisateur, se connecte sans MFA, puis envoie des e-mails frauduleux ou vole des données sensibles. #### Ce que l'analyse vérifie Le scan vérifie l’état d’enregistrement MFA de tous les utilisateurs activés. Tout utilisateur ayant `isMfaRegistered = false` déclenche l’alerte. #### Comment corriger L’approche la plus efficace consiste à imposer la MFA à tous les utilisateurs via l’Accès conditionnel ou les paramètres de sécurité par défaut (voir « Utilisateurs privilégiés sans MFA » ci-dessus pour les instructions détaillées). Pour vérifier quels utilisateurs n’ont pas la MFA : 1. Accédez à [Entra ID](https://entra.microsoft.com) > `Protection` > `Méthodes d’authentification` > `Détails d’enregistrement de l’utilisateur`. 2. Filtrez par « Compatible MFA = Non » pour voir qui ne s’est pas enregistré. ### Aucun contact de sécurité défini **Gravité : moyenne** #### Ce que cela signifie Microsoft Defender for Cloud peut détecter les menaces de sécurité dans votre environnement Azure (tentatives de connexion suspectes, malware, services exposés, etc.). Mais si aucune adresse e-mail n’est configurée, ces alertes n’ont nulle part où aller — personne n’est averti, et les attaques peuvent passer inaperçues. #### Ce que l'analyse vérifie Le scan vérifie qu’au moins un e-mail de contact de sécurité est configuré dans les paramètres de notification de Microsoft Defender for Cloud. #### Comment corriger 1. Accédez au [Azure Portal](https://portal.azure.com). 2. Accédez à `Microsoft Defender for Cloud` > `Paramètres de l’environnement`. 3. Sélectionnez votre abonnement. 4. Cliquez sur `Notifications par e-mail`. 5. Renseignez : * **Adresses e-mail supplémentaires :** ajoutez une liste de distribution (par exemple, `security@yourcompany.com`) — évitez d’utiliser l’e-mail d’une seule personne. * **Types de notifications :** au moins les alertes « Gravité élevée ». 6. Cliquez sur `Enregistrer`. ### Aucun rôle d’administration des verrous de ressources **Gravité : faible** #### Ce que cela signifie Azure **Verrous de ressources** protègent les ressources critiques (bases de données, réseaux virtuels, comptes de stockage) contre la suppression ou la modification accidentelle. Même un administrateur disposant de tous les droits ne peut pas supprimer une ressource verrouillée sans d’abord retirer le verrou. Ce constat signifie que personne dans votre organisation n’a reçu de rôle spécifiquement destiné à la gestion de ces verrous. Sans responsable, les verrous peuvent ne pas être utilisés de manière cohérente, ou des ressources critiques peuvent rester non protégées. #### Ce que l'analyse vérifie Le scan recherche un rôle RBAC personnalisé disposant des autorisations nécessaires pour gérer les verrous de ressources (`Microsoft.Authorization/locks/*`). Si aucun rôle de ce type n’existe ou si personne n’y est affecté, l’alerte se déclenche. #### Comment corriger 1. Accédez au [Azure Portal](https://portal.azure.com) > `Abonnements` > sélectionnez votre abonnement. 2. Accédez à `Contrôle d’accès (IAM)` > `Rôles` > `+ Ajouter` > `Ajouter un rôle personnalisé`. 3. Créez un rôle avec les autorisations suivantes : ``` Microsoft.Authorization/locks/read Microsoft.Authorization/locks/write Microsoft.Authorization/locks/delete ``` 4. Attribuez ce rôle à un administrateur de confiance. 5. Demandez à cet administrateur d’appliquer **Supprimer les verrous** sur les ressources critiques (bases de données, comptes de stockage, coffres de clés). ### Coffre de clés non récupérable **Gravité : élevée** #### Ce que cela signifie Azure Key Vault stocke vos secrets, vos clés de chiffrement et vos certificats. Si quelqu’un supprime accidentellement (ou malicieusement) un coffre de clés, vous perdez tout cela. Sans **suppression réversible** et **la protection contre la purge** activée, un coffre de clés supprimé est perdu à jamais — il n’y a aucune récupération possible. #### Ce que l'analyse vérifie Le scan vérifie que les deux protections sont activées : * **Suppression réversible :** les coffres de clés supprimés sont conservés pendant une période de rétention (90 jours par défaut) et peuvent être récupérés. * **Protection contre la purge :** même après la suppression réversible, le coffre ne peut pas être effacé définitivement pendant la période de rétention. #### Comment corriger 1. Accédez au [Azure Portal](https://portal.azure.com) > `Coffres de clés` > sélectionnez votre coffre. 2. Accédez à `Propriétés`. 3. Activez `Suppression réversible` (remarque : cette option est désormais activée par défaut sur les nouveaux coffres et ne peut pas être désactivée). 4. Activez `Protection contre la purge`. 5. Cliquez sur `Enregistrer`. Pour les coffres existants via Azure CLI : ```bash az keyvault update --name --enable-purge-protection true ``` ### HTTPS non imposé sur App Service **Gravité : élevée** #### Ce que cela signifie Votre Azure App Service (site web ou API) accepte le trafic HTTP non chiffré. Cela signifie que les données envoyées entre les utilisateurs et votre application — y compris les identifiants de connexion, les informations personnelles et les jetons de session — peuvent être interceptées par toute personne se trouvant sur le chemin réseau. #### Ce que l'analyse vérifie Le scan vérifie le paramètre `HTTPS uniquement` sur chaque App Service. S’il est défini sur `Désactivé`, l’alerte se déclenche. #### Comment corriger 1. Accédez au [Azure Portal](https://portal.azure.com) > `App Services` > sélectionnez votre application. 2. Accédez à `Paramètres` > `Configuration` > `Paramètres généraux`. 3. Définissez `HTTPS uniquement` sur `Activé`. 4. Cliquez sur `Enregistrer`. ### Version TLS non sécurisée sur App Service **Gravité : élevée** #### Ce que cela signifie Votre App Service accepte les connexions utilisant TLS 1.0 ou 1.1, qui sont des protocoles de chiffrement obsolètes présentant des vulnérabilités connues. Les navigateurs modernes et les normes de sécurité exigent TLS 1.2 ou une version supérieure. #### Ce que l'analyse vérifie La version TLS minimale configurée sur l’App Service. L’alerte se déclenche si elle est inférieure à 1.2. #### Comment corriger 1. Accédez au [Azure Portal](https://portal.azure.com) > `App Services` > sélectionnez votre application. 2. Accédez à `Paramètres` > `Configuration` > `Paramètres généraux`. 3. Définissez `Version TLS minimale` sur `1.2`. 4. Cliquez sur `Enregistrer`. ### SQL / PostgreSQL / MySQL : l’application de SSL est désactivée **Gravité : élevée** #### Ce que cela signifie Votre serveur de base de données accepte des connexions non chiffrées. Sans application de SSL/TLS, les identifiants et les données envoyés entre votre application et la base de données peuvent être interceptés sur le réseau. #### Comment corriger **Pour Azure Database for MySQL :** 1. Accédez à [Azure Portal](https://portal.azure.com) > `Azure Database for MySQL` > sélectionnez votre serveur. 2. Accédez à `Sécurité de la connexion`. 3. Définissez `Forcer la connexion SSL` sur `ACTIVÉ`. 4. Cliquez sur `Enregistrer`. **Pour Azure Database for PostgreSQL :** 1. Accédez à [Azure Portal](https://portal.azure.com) > `Azure Database for PostgreSQL` > sélectionnez votre serveur. 2. Accédez à `Sécurité de la connexion`. 3. Définissez `Forcer la connexion SSL` sur `ACTIVÉ`. 4. Cliquez sur `Enregistrer`. ### Conteneur Blob public **Gravité : élevée** #### Ce que cela signifie Un ou plusieurs de vos conteneurs blob Azure Storage sont configurés pour un **accès public**, ce qui signifie que toute personne sur Internet peut lire les fichiers qu’ils contiennent sans authentification. C’est une source fréquente de fuites de données. #### Comment corriger 1. Accédez à [Azure Portal](https://portal.azure.com) > `Comptes de stockage` > sélectionnez le compte. 2. Accédez à `Configuration`. 3. Définissez `Autoriser l’accès public aux blobs` sur `Désactivé`. 4. Ou, pour corriger des conteneurs individuels : allez dans `Conteneurs`, sélectionnez le conteneur et modifiez `Niveau d’accès public` sur `Privé`. ### Disques de machine virtuelle non chiffrés **Gravité : élevée** #### Ce que cela signifie Les disques de votre machine virtuelle ne sont pas chiffrés. Si le matériel physique sous-jacent est compromis, mis hors service ou mal éliminé, les données contenues sur ces disques pourraient être lues en clair. #### Comment corriger 1. Accédez à [Azure Portal](https://portal.azure.com) > `Machines virtuelles` > sélectionnez la VM. 2. Accédez à `Disques` > `Paramètres supplémentaires`. 3. Activez `Azure Disk Encryption` (ADE) ou `Chiffrement côté serveur avec des clés gérées par le client`. 4. Pour les nouvelles VM, activez le chiffrement lors de la création. ## Amazon Web Services (AWS) ### Compte racine sans MFA **Gravité : critique** #### Ce que cela signifie Le **compte racine** AWS a un accès sans restriction à tout ce qui se trouve dans votre compte AWS — facturation, tous les services, toutes les données. C’est l’identifiant le plus puissant de toute votre configuration cloud. Sans MFA, un mot de passe racine compromis signifie une prise de contrôle totale. #### Comment corriger 1. Connectez-vous à la [Console AWS](https://console.aws.amazon.com/) en tant que racine. 2. Accédez à `IAM` > `Tableau de bord` > `Activez la MFA sur votre compte racine`. 3. Cliquez sur `Gérer la MFA` > `Activer la MFA`. 4. Choisissez `Appareil MFA virtuel` (recommandé : utilisez une clé matérielle comme YubiKey pour une sécurité maximale). 5. Scannez le code QR avec votre application d’authentification. 6. Saisissez deux codes consécutifs et cliquez sur `Attribuer la MFA`. Après avoir activé la MFA, suivez les bonnes pratiques AWS : * **N’utilisez jamais le compte racine pour les tâches quotidiennes.** Créez des utilisateurs IAM ou utilisez plutôt IAM Identity Center. * Stockez les identifiants racine dans un emplacement sécurisé hors ligne (coffre-fort, gestionnaire de mots de passe). ### Compte racine utilisé récemment **Gravité : élevée** #### Ce que cela signifie Le compte racine a été utilisé pour se connecter au cours des 90 derniers jours. Comme l’administrateur intégré dans Active Directory, le compte racine doit être réservé aux situations d’urgence uniquement (par exemple, récupération de compte, modifications de facturation). Les tâches quotidiennes doivent utiliser des utilisateurs ou des rôles IAM disposant des autorisations appropriées. #### Comment corriger 1. Créer **Utilisateurs IAM** ou utilisez **IAM Identity Center (SSO)** pour l’administration quotidienne. 2. Attribuez uniquement les autorisations dont chaque personne a besoin (principe du moindre privilège). 3. Arrêtez d’utiliser le compte racine pour les tâches courantes. 4. L’alerte disparaîtra après 90 jours d’inactivité sur le compte racine. ### Utilisateurs IAM sans MFA **Gravité : moyenne** #### Ce que cela signifie Un ou plusieurs utilisateurs IAM peuvent se connecter à la console AWS sans MFA. Si leur mot de passe est compromis, l’attaquant obtient un accès complet à tout ce que cet utilisateur peut faire dans AWS. #### Comment corriger 1. Accédez à `IAM` > `Utilisateurs` > sélectionnez l’utilisateur. 2. Accédez au `Informations d’identification de sécurité` . 3. Sous `Authentification multifacteur (MFA)`, cliquez sur `Gérer`. 4. Attribuez un appareil MFA. Pour imposer la MFA à tous les utilisateurs, créez une stratégie IAM qui refuse toutes les actions sauf si la MFA est présente : 1. Accédez à `IAM` > `Stratégies` > `Créer une stratégie`. 2. Utilisez le [modèle de stratégie d’application MFA AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_my-sec-creds-self-manage-mfa-only.html) . 3. Attachez-la à tous les groupes d’utilisateurs. ## Google Cloud Platform (GCP) ### Bucket de stockage cloud accessible publiquement **Gravité : élevée** #### Ce que cela signifie Un bucket Google Cloud Storage est accessible au public sur Internet. Toute personne disposant de l’URL peut télécharger les fichiers. C’est une source fréquente de fuites de données. #### Comment corriger 1. Accédez à [Console Google Cloud](https://console.cloud.google.com) > `Cloud Storage` > `Buckets`. 2. Sélectionnez le bucket. 3. Accédez au `Autorisations` . 4. Supprimez toute entrée pour `allUsers` ou `allAuthenticatedUsers`. 5. Pour empêcher tout accès public futur : allez dans les `Paramètres` du bucket et activez `Empêcher l’accès public`. ### Rôles primitifs IAM en cours d’utilisation **Gravité : moyenne** #### Ce que cela signifie Quelqu’un dans votre organisation GCP utilise des **rôles primitifs** (Propriétaire, Éditeur ou Lecteur). Ils sont très larges — « Éditeur », par exemple, accorde un accès en écriture à presque tout dans le projet. Google recommande d’utiliser des **rôles prédéfinis** à la place, qui ne donnent que les autorisations spécifiques nécessaires. #### Comment corriger 1. Accédez à [Console Google Cloud](https://console.cloud.google.com) > `IAM et administration` > `IAM`. 2. Identifiez les utilisateurs/comptes de service ayant les rôles `Propriétaire`, `Éditeur`, ou `Lecteur` rôles. 3. Remplacez-les par des rôles prédéfinis plus précis (par exemple, `roles/storage.admin` au lieu de `Éditeur`). 4. Utilisez le [IAM Recommender](https://cloud.google.com/iam/docs/recommender-overview) pour obtenir des सुझावგ ### Accès public à Cloud SQL **Gravité : élevée** #### Ce que cela signifie Votre instance de base de données Cloud SQL autorise les connexions depuis n’importe quelle adresse IP sur Internet (`0.0.0.0/0`). Cela expose la base de données aux attaques par force brute et à l’exploitation de toute vulnérabilité. #### Comment corriger 1. Accédez à [Console Google Cloud](https://console.cloud.google.com) > `SQL` > sélectionnez votre instance. 2. Accédez à `Connexions` > `Réseau`. 3. Sous `Réseaux autorisés`, supprimez `0.0.0.0/0` ou toute plage CIDR trop large. 4. N’ajoutez que les adresses IP spécifiques qui ont besoin d’un accès. 5. Mieux encore, utilisez **Cloud SQL Auth Proxy** ou **IP privée** pour vous connecter de manière sécurisée sans exposer l’instance publiquement. ## Foire aux questions #### À quelle fréquence le Cloud Scan s’exécute-t-il ? Le Cloud Scan s’exécute automatiquement régulièrement. Après l’application d’un correctif, laissez jusqu’à 24 heures pour que le prochain scan prenne en compte les changements. Vous pouvez également lancer une nouvelle analyse depuis le portail Stoïk Protect. #### J’ai corrigé le constat mais il s’affiche encore. Pourquoi ? Les raisons les plus courantes : * **Le scan ne s’est pas encore relancé :** attendez le prochain cycle de scan. * **Le correctif a été appliqué à la mauvaise ressource :** vérifiez que vous avez modifié le bon abonnement, groupe de ressources ou projet. * **Il existe plusieurs instances :** le même problème peut exister sur plusieurs ressources (par exemple, plusieurs comptes de stockage avec accès public). #### Ai-je besoin des droits d’Administrateur général pour corriger ces problèmes ? La plupart des constats Azure nécessitent au moins le rôle **Administrateur de la sécurité** ou **Contributeur** sur l’abonnement concerné. Les constats Entra ID (MFA, Shadow Admin) nécessitent le rôle **Administrateur général** ou **Administrateur des rôles privilégiés**. Pour AWS, vous avez besoin d’autorisations IAM pour modifier les services concernés. Pour GCP, vous avez besoin des rôles IAM appropriés. #### Les constats peuvent-ils être ignorés ? Si un constat correspond à un risque accepté ou à un faux positif (par exemple, un bucket de stockage volontairement public pour un site web statique), contactez le support Stoïk pour le documenter comme exception. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.stoik.io/help/help-center-fr/outils-de-prevention/what-is-the-cloud-scan/how-to-read-results-on-the-cloud-scan/cloud-scan-vulnerability-remediation-guide.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.