Les erreurs de configuration cloud les plus coûteuses en PME sont presque toujours les mêmes six : compte racine mal protégé, droits trop larges, stockage ouvert au public, ports d’administration exposés, journaux désactivés et clés d’accès qui ne meurent jamais. Ce tutoriel vous montre, étape par étape, comment les repérer et les corriger sur AWS, Azure ou Google Cloud, sans outil payant et sans refondre votre architecture.
La plupart des incidents cloud ne viennent pas d’une faille du fournisseur, mais d’un réglage laissé ouvert par commodité lors d’un projet pressé. Le modèle de responsabilité partagée est clair : le fournisseur sécurise l’infrastructure, vous sécurisez ce que vous y configurez. Comptez une demi-journée pour un premier passage sur un compte de taille raisonnable, puis une heure par mois pour l’entretien.
Repérer vos erreurs de configuration cloud avant de corriger
Avant de toucher au moindre réglage, dressez la liste de vos comptes, abonnements et projets. En PME, le piège classique est le compte oublié : un abonnement Azure ouvert par un prestataire, un projet Google Cloud créé pour un test, un compte AWS payé par carte bancaire au nom d’un salarié parti depuis. Pour chacun, notez le propriétaire métier, le moyen de paiement et qui détient les accès administrateur.
Lancez ensuite un premier scan automatique. Les trois fournisseurs proposent un tableau de bord natif : AWS Security Hub, Microsoft Defender for Cloud (son score de sécurité de base est gratuit) et Security Command Center chez Google. Si vous préférez un outil unique pour plusieurs clouds, l’outil open source Prowler couvre AWS, Azure et GCP et s’appuie sur les référentiels du CIS. Ne cherchez pas à tout corriger d’un coup : servez-vous du rapport pour vérifier les six points ci-dessous, dans cet ordre.
Étape 1 : verrouiller le compte racine et imposer le MFA
Le compte racine AWS, le compte « Administrateur général » Microsoft Entra ou le super administrateur Google ont tous les droits, y compris celui de fermer le compte. Une seule fuite de mot de passe suffit.
- Activez une double authentification résistante au phishing (clé FIDO2 ou passkey) sur chaque compte à privilèges.
- Supprimez les clés d’accès programmatiques rattachées au compte racine AWS : il ne doit jamais servir aux scripts.
- Créez au moins deux comptes d’administration nominatifs, et réservez le compte racine aux opérations qui l’exigent.
- Stockez l’accès de secours (mot de passe et clé) hors ligne, sous la responsabilité de deux personnes.
Vérification : dans la console IAM d’AWS, le tableau de bord indique si le MFA est actif sur le compte racine. Côté Microsoft, les paramètres de sécurité par défaut ou une stratégie d’accès conditionnel imposent le MFA à tous les administrateurs.
Étape 2 : réduire les droits IAM au strict nécessaire
Deuxième erreur la plus fréquente : tout le monde est administrateur, parce que « c’était plus simple pour démarrer ». Un compte de développeur compromis devient alors un compte d’administration compromis.
- Exportez la liste des utilisateurs et des rôles disposant de droits administrateur ou propriétaire.
- Pour chacun, demandez au responsable : de quoi cette personne a-t-elle réellement besoin ?
- Remplacez les rôles larges par des rôles prédéfinis plus étroits (lecture seule, gestion d’un seul service).
- Supprimez les comptes inactifs : AWS IAM Access Analyzer et les rapports d’identifiants signalent les accès jamais utilisés.
Visez une règle simple : pas plus de deux ou trois administrateurs permanents, et des droits élevés accordés à la demande pour le reste.
Étape 3 : fermer les stockages ouverts au public
Un bucket S3, un conteneur Azure Blob ou un bucket Cloud Storage accessible sans authentification reste la cause la plus banale de fuite de données. Il suffit d’un partage « temporaire » pour un client ou un site web.
- Sur AWS, activez le blocage de l’accès public S3 au niveau du compte, pas seulement bucket par bucket.
- Sur Azure, désactivez l’option d’accès anonyme aux blobs au niveau du compte de stockage.
- Sur Google Cloud, appliquez la prévention de l’accès public via une règle d’administration de l’organisation.
Si un contenu doit vraiment être public (images d’un site, par exemple), isolez-le dans un stockage dédié qui ne contient rien d’autre. Pour un partage ponctuel avec un client, utilisez une URL signée à durée limitée plutôt qu’un bucket ouvert.
Étape 4 : retirer les ports d’administration exposés à Internet
Des machines virtuelles avec SSH (port 22) ou RDP (port 3389) ouverts à toute l’Internet sont scannées en permanence par des robots. Une règle « 0.0.0.0/0 » dans un groupe de sécurité est souvent un reste de mise en service.
- Listez les groupes de sécurité ou règles de pare-feu qui autorisent ces ports depuis n’importe quelle adresse.
- Remplacez l’accès direct par un bastion géré : AWS Systems Manager Session Manager, Azure Bastion ou IAP chez Google.
- À défaut, limitez l’accès aux adresses IP fixes de vos bureaux ou de votre VPN.
- Faites la même revue pour les bases de données : une base n’a jamais besoin d’être joignable depuis Internet.
Étape 5 : activer et conserver les journaux d’audit
Sans journaux, un incident cloud est impossible à reconstituer : vous ne saurez ni qui s’est connecté, ni ce qui a été modifié. Or certains journaux ne sont pas activés, ou pas conservés assez longtemps, par défaut.
- Sur AWS, créez un trail CloudTrail multi-régions qui écrit dans un bucket protégé contre la suppression.
- Sur Azure, exportez le journal d’activité et les journaux de connexion Entra vers un espace de stockage ou un outil de collecte.
- Sur Google Cloud, vérifiez que les journaux d’accès aux données sont activés pour les services sensibles : seuls les journaux d’activité d’administration le sont d’office.
Fixez une durée de conservation cohérente avec vos obligations et votre contrat d’assurance, puis vérifiez que quelqu’un regarde réellement ces journaux : un journal que personne ne lit ne protège de rien.
Étape 6 : supprimer les clés d’accès longue durée et les secrets en clair
Les clés d’accès programmatiques sans date d’expiration finissent dans un dépôt Git, un fichier de configuration ou un poste de développeur. Une fois volées, elles fonctionnent sans MFA.
- Listez les clés d’accès les plus anciennes et identifiez à quoi elles servent.
- Remplacez-les par des identités gérées ou des rôles : rôles IAM sur AWS, identités managées sur Azure, comptes de service avec fédération chez Google.
- Déplacez les secrets restants dans un coffre (AWS Secrets Manager, Azure Key Vault, Secret Manager) avec rotation.
- Activez l’analyse des secrets sur vos dépôts de code pour attraper les fuites avant qu’elles ne partent.
Nous avons détaillé la marche à suivre quand une clé a déjà fuité dans notre article sur les clés AWS exposées et la reprise de contrôle du cloud.
Tenir ces réglages dans la durée
Une configuration propre se dégrade dès le projet suivant. Instaurez une revue mensuelle courte : relancez le scan, comparez avec le mois précédent, et traitez chaque nouvel écart avant qu’il ne devienne la norme. Ajoutez aussi les alertes de facturation : un pic de consommation inexpliqué est souvent le premier signe d’un compte détourné pour du minage.
Les accès administrateur restent le maillon central de toute cette démarche ; si votre déploiement de la double authentification n’est pas terminé, notre guide pour déployer le MFA en PME étape par étape vous aide à fixer l’ordre de priorité.
Une erreur de configuration exploitée se repère d’autant plus vite que quelqu’un lit vos journaux cloud en continu : découvrez notre SOC managé 24/7 pour PME et ETI.
Ce qu’il faut retenir
- Le fournisseur sécurise l’infrastructure, vous restez responsable de vos réglages.
- Protégez d’abord les comptes à privilèges : MFA résistant au phishing, compte racine inutilisé.
- Fermez les stockages publics et les ports d’administration au niveau du compte entier.
- Activez les journaux d’audit et remplacez les clés longue durée par des rôles.
- Planifiez une revue mensuelle : une configuration propre ne le reste pas toute seule.