Checklist sécurité infonuagique PME : que vérifier avant un audit

2026-07-19•24 min de lecture

Introduction

La plupart des défaillances de sécurité infonuagique ne viennent pas d'exploits sophistiqués de type zero-day. Elles viennent souvent de mauvaises configurations restées en production trop longtemps : un stockage public, un rôle trop permissif, une clé exposée, une base de données mal protégée ou une journalisation insuffisante.

Le rapport Verizon Data Breach Investigations Report 2025 rappelle que les erreurs humaines, les mauvaises configurations et les erreurs de publication demeurent des facteurs importants dans les incidents de sécurité. Dans l'infonuagique, ces erreurs peuvent être exploitées rapidement, parfois par de simples scans automatisés.

La bonne nouvelle : beaucoup de ces risques sont évitables avec un examen systématique de votre posture infonuagique. Cette checklist aide les PME à vérifier les contrôles essentiels sur AWS, Microsoft Azure et Google Cloud, avec une attention particulière aux obligations des entreprises québécoises en vertu de la Loi 25.

Réponse courte : que vérifier avant un audit infonuagique ?

Avant un audit de sécurité infonuagique, une PME devrait vérifier en priorité :

  • les accès humains et techniques ;
  • l'authentification multifacteur ;
  • les permissions excessives ;
  • les clés d'accès longue durée ;
  • l'exposition publique des stockages ;
  • le chiffrement des données ;
  • les règles réseau trop ouvertes ;
  • la journalisation d'audit ;
  • la détection des menaces ;
  • les sauvegardes et tests de restauration ;
  • la résidence des données ;
  • les obligations liées à la Loi 25 et aux EFVP.

L'objectif n'est pas de tout corriger en une seule journée, mais d'identifier rapidement les failles les plus susceptibles de mener à une violation.

Pourquoi les mauvaises configurations infonuagiques exposent les PME

Dans l'infonuagique, l'exposition dépend fortement de la configuration. Une règle réseau trop ouverte, un stockage mal paramétré, une clé exposée ou un rôle trop permissif peuvent rendre une ressource accessible ou exploitable beaucoup plus rapidement que dans un environnement traditionnel.

Les PME sont particulièrement exposées pour trois raisons :

  • les équipes techniques doivent livrer vite ;
  • les responsabilités infonuagiques sont parfois mal réparties ;
  • les contrôles de sécurité sont ajoutés après coup, plutôt que dès la conception.

Un environnement infonuagique peut être robuste, mais il exige une discipline continue : identité, chiffrement, réseau, journalisation, sauvegarde, conformité et réponse aux incidents.

Pourquoi la sécurité infonuagique est différente

La sécurité périmétrique traditionnelle suppose une frontière relativement claire entre "l'intérieur" et "l'extérieur". Les environnements infonuagiques fonctionnent autrement. Les ressources sont dynamiques, les identités sont nombreuses, les API sont partout, et une simple permission mal configurée peut créer un chemin d'attaque.

Le modèle de responsabilité partagée est central. AWS, Microsoft Azure et Google Cloud sécurisent l'infrastructure sous-jacente. L'entreprise cliente reste responsable de ce qu'elle configure et exploite :

  • comptes et identités ;
  • rôles et permissions ;
  • chiffrement des données ;
  • configuration réseau ;
  • stockage ;
  • journalisation ;
  • sauvegardes ;
  • surveillance ;
  • réponse aux incidents ;
  • conformité réglementaire.

Autrement dit, utiliser un grand fournisseur infonuagique ne rend pas automatiquement l'environnement sécuritaire. La sécurité dépend de la manière dont les services sont configurés, surveillés et gouvernés.

Les 7 domaines à vérifier avant un audit cloud

1. Pré-migration, classification et Loi 25

Avant de migrer des charges de travail vers l'infonuagique, ou si vous avez déjà migré sans classification formelle, commencez par les données.

Questions à poser :

  • Quelles données sont stockées dans l'infonuagique ?
  • Contiennent-elles des renseignements personnels ?
  • S'agit-il de données clients, employés, santé, financières ou contractuelles ?
  • Où ces données résident-elles physiquement ?
  • Qui peut y accéder ?
  • Des sous-traitants ou équipes de soutien hors Québec peuvent-ils y accéder ?
  • Quelle est la durée de conservation ?
  • Une EFVP est-elle requise ?

Au Québec, on parle d'EFVP, soit une évaluation des facteurs relatifs à la vie privée. Une EFVP est notamment requise lorsqu'un projet implique l'acquisition, le développement ou la refonte d'un système traitant des renseignements personnels, ou lorsqu'il y a communication de renseignements personnels à l'extérieur du Québec.

AWS, Azure et Google Cloud offrent des régions canadiennes. AWS ca-central-1 est dans la région de Montréal, Google Cloud northamerica-northeast1 est à Montréal, Azure Canada Central est à Toronto et Azure Canada East est au Québec. Le choix d'une région canadienne aide la résidence des données, mais ne suffit pas à lui seul à démontrer la conformité.

Il faut aussi vérifier :

  • la réplication des données ;
  • les journaux et métadonnées ;
  • les accès de soutien ;
  • les sous-traitants ;
  • les sauvegardes ;
  • les clauses contractuelles ;
  • les mesures de protection appliquées aux renseignements personnels.

2. Gestion des identités et des accès

Les erreurs de gestion des identités et des accès sont parmi les risques les plus critiques dans l'infonuagique. Un compte trop permissif, une clé exposée ou un rôle mal attribué peut permettre à un attaquant de se déplacer latéralement et d'accéder à des données sensibles.

Contrôles prioritaires :

  • cesser d'utiliser les comptes racine ou propriétaires pour les opérations quotidiennes ;
  • activer l'authentification multifacteur pour tous les comptes humains ;
  • privilégier la fédération d'identité et les accès temporaires ;
  • éliminer les clés longue durée lorsque possible ;
  • auditer les rôles avec privilèges élevés ;
  • supprimer les comptes inactifs ;
  • revoir régulièrement les permissions.

Les comptes racine AWS et les comptes administrateur général Azure doivent être réservés aux opérations exceptionnelles. Ils doivent être protégés par authentification multifacteur, surveillés et utilisés le moins possible.

L'authentification multifacteur doit être appliquée à tous les utilisateurs humains : développeurs, administrateurs, analystes, prestataires et comptes de gestion. En 2026, un compte humain sans authentification multifacteur dans un environnement infonuagique est un risque difficile à justifier.

Pour les clés d'accès, la meilleure approche consiste à éviter les clés longue durée lorsque c'est possible. Privilégiez les rôles temporaires, l'identité fédérée et les mécanismes natifs du fournisseur. Lorsqu'une clé longue durée reste nécessaire, elle doit être inventoriée, surveillée, limitée et renouvelée selon une politique claire. Les clés âgées de plus de 90 ou 180 jours doivent être considérées comme à risque élevé.

3. Protection des données

Les données infonuagiques doivent être protégées en transit et au repos. Ce contrôle est fondamental pour la cybersécurité, la conformité et la confiance des clients.

Pour le chiffrement en transit :

  • appliquez TLS 1.2 ou supérieur ;
  • bloquez HTTP pour les interfaces sensibles ;
  • désactivez les protocoles et suites de chiffrement obsolètes ;
  • utilisez l'épinglage de certificat seulement pour les applications très sensibles, lorsque l'exploitation et la maintenance le justifient.

Pour le chiffrement au repos :

  • vérifiez que les bases de données sont chiffrées ;
  • utilisez des clés gérées par le client lorsque les données ou exigences de conformité le nécessitent ;
  • centralisez les secrets dans un coffre-fort de clés ;
  • ne stockez jamais de secrets dans le code ou les fichiers de configuration ;
  • séparez les accès aux données et les accès aux clés.

Sur AWS, Amazon S3 chiffre automatiquement les nouveaux objets avec SSE-S3 depuis 2023. Pour les données sensibles ou les contextes exigeant un contrôle plus fin des clés, privilégiez SSE-KMS ou des clés gérées par le client lorsque pertinent.

Sur Azure, utilisez Azure Key Vault pour les secrets, certificats et chaînes de connexion. Activez les mécanismes de chiffrement appropriés pour les bases de données et les services de stockage.

Sur Google Cloud, utilisez Cloud KMS et les clés de chiffrement gérées par le client pour les charges sensibles lorsque le contrôle des clés est requis.

Pour les sauvegardes :

  • définissez le RPO et le RTO ;
  • testez les restaurations régulièrement ;
  • conservez au moins une copie dans une région ou un compte séparé lorsque pertinent ;
  • activez les sauvegardes immuables lorsque disponibles ;
  • documentez la procédure de restauration.

Une sauvegarde jamais testée n'est pas une garantie. C'est une hypothèse.

4. Sécurité réseau

Votre réseau infonuagique doit être conçu selon le principe de compromission présumée : si une ressource est compromise, elle ne doit pas pouvoir atteindre librement toutes les autres.

Contrôles à vérifier :

  • segmenter les réseaux ;
  • isoler les bases de données ;
  • limiter l'accès Internet direct ;
  • restreindre les règles entrantes ;
  • contrôler les flux sortants ;
  • utiliser des bastions, VPN ou accès conditionnels ;
  • activer les journaux de flux réseau.

Une architecture simple peut déjà réduire fortement le risque :

  • ressources publiques : équilibreurs de charge, passerelles API ;
  • ressources applicatives : sous-réseaux privés ;
  • bases de données : sous-réseaux privés séparés ;
  • administration : accès via VPN, bastion ou service sécurisé.

Les ports RDP 3389 et SSH 22 ne devraient pas être ouverts à Internet. Les règles 0.0.0.0/0 doivent être limitées aux cas justifiés, documentés et surveillés.

Pour la visibilité réseau :

  • AWS : activez VPC Flow Logs ;
  • Azure : privilégiez Azure Virtual Network flow logs pour les nouveaux déploiements ;
  • Google Cloud : activez VPC Flow Logs.

Microsoft a annoncé le retrait progressif des NSG flow logs : pour les nouveaux déploiements, Azure Virtual Network flow logs est l'option à privilégier.

5. Journalisation et surveillance

Vous ne pouvez pas détecter ce que vous ne voyez pas. La journalisation n'est pas seulement une exigence de conformité : c'est la base de la détection et de la réponse à incident.

À vérifier :

  • AWS CloudTrail activé sur tous les comptes ;
  • journaux Azure Activity Log et Microsoft Entra ID alimentés dans une plateforme de surveillance ;
  • Google Cloud Audit Logs activés ;
  • journaux centralisés dans un compte ou espace sécurisé ;
  • accès aux journaux restreint ;
  • conservation suffisante ;
  • alertes configurées sur les événements critiques.

Conservez les journaux assez longtemps pour qu'ils soient utiles. Beaucoup d'incidents sont détectés après plusieurs jours ou semaines. Une rétention de 90 jours est un minimum pratique pour de nombreux environnements ; les systèmes traitant des renseignements personnels ou données sensibles peuvent nécessiter une conservation plus longue selon le contexte.

Activez les services de détection adaptés :

  • AWS GuardDuty ;
  • Microsoft Defender for Cloud ;
  • Google Cloud Security Command Center.

Ces services ne remplacent pas une surveillance humaine, mais ils offrent une première couche de détection comportementale et de signalement des risques.

6. Réponse aux incidents infonuagiques

La réponse aux incidents infonuagiques doit tenir compte des capacités propres au cloud. Lorsqu'une instance est compromise, il est souvent possible de l'isoler, d'en prendre un instantané, de préserver les journaux, puis de reconstruire une version propre rapidement.

Mais cela ne fonctionne que si la procédure est connue à l'avance.

Votre plan devrait couvrir :

  • l'isolation d'une ressource compromise ;
  • la collecte des journaux ;
  • la préservation des preuves ;
  • la révocation des sessions actives ;
  • la rotation des secrets ;
  • la désactivation de clés exposées ;
  • la reconstruction d'environnements propres ;
  • l'escalade interne ;
  • la notification réglementaire si nécessaire.

Pour une PME, un manuel simple vaut mieux qu'un plan théorique de 80 pages. L'équipe doit savoir quoi faire, qui appeler et comment éviter d'effacer les preuves importantes.

7. Cartographie de la conformité

Pour les entreprises québécoises, la conformité infonuagique doit intégrer la Loi 25 dès le début.

Les points à vérifier :

  • les renseignements personnels traités ;
  • la finalité de la collecte ;
  • la durée de conservation ;
  • la localisation des données ;
  • les communications hors Québec ;
  • les fournisseurs et sous-traitants ;
  • les mesures contractuelles ;
  • les contrôles d'accès ;
  • la journalisation ;
  • le chiffrement ;
  • les procédures de notification.

Une région cloud canadienne ne suffit pas à elle seule pour être conforme. Elle peut soutenir la résidence des données, mais l'entreprise doit aussi évaluer les accès, la réplication, les journaux, les sous-traitants et les garanties contractuelles.

En cas d'incident de confidentialité présentant un risque de préjudice sérieux, la Loi 25 prévoit aussi des obligations de notification, notamment auprès de la Commission d'accès à l'information du Québec.

Les 10 corrections à faire cette semaine

Vous n'avez pas besoin de tout traiter en même temps. Commencez par les contrôles à plus fort impact.

  • [ ] Activer l'authentification multifacteur sur tous les comptes humains.
  • [ ] Supprimer ou remplacer les clés d'accès longue durée lorsque possible.
  • [ ] Auditer les permissions trop larges et les rôles administrateurs.
  • [ ] Vérifier que les stockages publics sont bloqués ou justifiés.
  • [ ] Activer CloudTrail, Azure Activity Logs ou Google Cloud Audit Logs.
  • [ ] Activer AWS GuardDuty, Microsoft Defender for Cloud ou Google Cloud Security Command Center lorsque disponibles et adaptés.
  • [ ] Supprimer les accès SSH/RDP exposés à Internet.
  • [ ] Confirmer le chiffrement des bases de données et stockages sensibles.
  • [ ] Tester une restauration de sauvegarde.
  • [ ] Si des renseignements personnels sont traités, confirmer la région, les accès fournisseur et le besoin d'une EFVP.

Tableau de priorisation rapide

| Priorité | Contrôle | Pourquoi c'est important | | -------- | ----------------------------- | ------------------------------------------------------ | | Critique | Authentification multifacteur | Réduit fortement le risque lié aux identifiants volés | | Critique | Permissions minimales | Limite l'impact d'un compte compromis | | Critique | Stockages non publics | Évite l'exposition directe de données | | Haute | Journaux d'audit | Permet d'enquêter et de prouver les actions | | Haute | Chiffrement | Protège les données sensibles et appuie la conformité | | Haute | Sauvegardes testées | Réduit l'impact d'un incident ou rançongiciel | | Moyenne | Détection des menaces | Accélère l'identification des comportements suspects | | Moyenne | EFVP | Encadre les risques liés aux renseignements personnels |

Téléchargez la checklist complète

Télécharger la liste de vérification de sécurité infonuagique

Obtenez la checklist complète de 50 points avec matrice de notation pour AWS, Azure et Google Cloud, incluant les contrôles liés à la Loi 25 et aux EFVP.

Aucun spam. Désinscription en tout temps.

Besoin d'une expertise guidée ?

Vous préparez un audit, une migration infonuagique ou une revue de sécurité AWS, Azure ou Google Cloud ? Cybernow peut vous aider à évaluer votre posture, prioriser les corrections, documenter les contrôles et structurer votre gouvernance de sécurité.

Notre service vCISO fractionnel fournit un leadership sécurité adapté aux PME, sans nécessiter l'embauche d'un responsable sécurité à temps plein.

Découvrir le service vCISO

FAQ

Qu'est-ce qu'une checklist de sécurité infonuagique ?

Une checklist de sécurité infonuagique est une liste de contrôles permettant de vérifier les accès, configurations réseau, chiffrement, sauvegardes, journaux, alertes et obligations de conformité avant un audit, une migration cloud ou une mise en production.

Une PME québécoise doit-elle faire une EFVP avant d'utiliser le cloud ?

Une EFVP est notamment requise lorsqu'un projet implique l'acquisition, le développement ou la refonte d'un système traitant des renseignements personnels, ou lorsqu'il y a communication de renseignements personnels à l'extérieur du Québec. Le besoin exact doit être évalué selon le contexte du projet.

Une région cloud canadienne suffit-elle pour être conforme à la Loi 25 ?

Non. Une région canadienne aide à la résidence des données, mais l'entreprise doit aussi vérifier les accès du fournisseur, les sous-traitants, les journaux, la réplication, les mesures contractuelles et les protections appliquées aux renseignements personnels.

Quels contrôles cloud corriger en priorité ?

Les priorités sont l'authentification multifacteur, les permissions excessives, les clés longue durée, les stockages publics, le chiffrement, les ports SSH/RDP ouverts, la journalisation d'audit et les sauvegardes testées.

Quelle est la différence entre sécurité cloud et sécurité infonuagique ?

Les deux expressions désignent généralement le même domaine. Au Québec, "sécurité infonuagique" est le terme français recommandé, tandis que "sécurité cloud" est souvent utilisé dans les milieux techniques.

Qui est responsable de la sécurité dans le cloud ?

Le fournisseur sécurise l'infrastructure sous-jacente. L'entreprise cliente reste responsable de la configuration, des accès, des données, des applications, des journaux, des sauvegardes et de la conformité de ses propres environnements.

Sources principales

Besoin d'une Expertise Guidée?

Notre service vCISO fractionnel fournit le leadership en sécurité et l'orientation stratégique adaptée à votre organisation.