La liste de vérification de sécurité infonuagique que toute PME doit avoir avant l'arrivée des auditeurs

La plupart des défaillances de sécurité infonuagique ne résultent pas d'exploits sophistiqués de type zero-day. Elles résultent de mauvaises configurations qui sont en production depuis des mois - un compartiment S3 laissé public, un rôle IAM avec des privilèges d'administrateur attaché à un serveur de développement, une base de données sans chiffrement au repos, un VPC sans segmentation réseau.

Le rapport Verizon Data Breach Investigations de 2024 a conclu que les mauvaises configurations demeurent l'une des principales causes de violations liées à l'infonuagique. L'attaquant n'avait pas besoin d'une technique nouvelle. Il avait besoin d'un moteur de recherche et d'une cible avec une clé AWS exposée dans un dépôt GitHub public.

La bonne nouvelle : la plupart de ces défaillances sont évitables avec un examen systématique de votre posture infonuagique. Cette liste de vérification couvre les contrôles à plus fort impact sur AWS, Azure et GCP, avec une attention particulière à ce que les entreprises québécoises doivent faire en vertu de la Loi 25 avant de stocker ou de traiter des renseignements personnels dans l'infonuage.

Pourquoi la sécurité infonuagique est un problème différent

La sécurité périmétrique traditionnelle suppose une frontière claire entre « l'intérieur » et « l'extérieur ». Les environnements infonuagiques n'ont pas de périmètre. Chaque ressource que vous déployez est, par défaut, accessible depuis Internet à moins que vous ne la configuriez explicitement autrement. Chaque politique IAM que vous écrivez qui est trop permissive est un chemin d'attaque. Chaque secret que vous codez en dur dans votre code d'application est une violation attendant d'être découverte par un scanner automatisé.

Le modèle de responsabilité partagée du fournisseur infonuagique est précis sur ce point : AWS, Azure et GCP sécurisent l'infrastructure. Vous êtes responsable de tout ce que vous y mettez - contrôles d'accès, chiffrement des données, configuration réseau, journalisation et réponse aux incidents.

Les équipes DevOps sous pression de livraison tendent à prioriser la vitesse sur les contrôles de sécurité. Les équipes de sécurité manquent souvent de l'expertise spécifique à l'infonuage pour examiner efficacement le code d'infrastructure. Le résultat est une accumulation de mauvaises configurations qui ne déclenchent pas d'alertes, n'apparaissent pas dans la surveillance de disponibilité, et ne deviennent visibles que lorsque quelqu'un ayant des intentions malveillantes les trouve en premier.

Les sept domaines de contrôle que vous devez aborder

Structurez votre examen de sécurité infonuagique autour de sept domaines. Dans chacun, priorisez par impact - corrigez d'abord les problèmes les plus susceptibles de mener à une violation.

Domaine 1 : Pré-migration et classification

Avant de migrer des charges de travail vers l'infonuage - ou si vous avez déjà migré sans exercice de classification formel - répondez à ces questions :

Quelles données stockez-vous dans des environnements infonuagiques? Les renseignements personnels (dossiers d'employés, données de clients, données de santé) doivent être identifiés et traités différemment des données d'affaires générales. En vertu de la Loi 25, les renseignements personnels stockés dans des environnements infonuagiques déclenchent des obligations spécifiques.

Où ces données résideront-elles physiquement? Cela importe parce que la Loi 25 exige une évaluation d'impact sur la protection des données (EIPD) avant de transférer des renseignements personnels hors du Québec. Les trois principaux fournisseurs infonuagiques offrent des régions canadiennes (AWS ca-central-1, Azure Canada Central, GCP northamerica-northeast1 à Montréal). L'utilisation d'une région canadienne n'est pas une conformité automatique - vous devez encore comprendre ce que les schémas de réplication des données, de journalisation et d'accès au soutien signifient pour la résidence des données - mais c'est un point de départ nécessaire.

Quelles sont vos obligations de conformité? Cartographiez vos types de données aux cadres qui les régissent : Loi 25 pour les renseignements personnels québécois, GDPR pour les sujets de données de l'UE, HIPAA pour les données de santé, PCI-DSS pour les données de titulaires de carte. Chacun a des exigences techniques spécifiques pour le chiffrement, le contrôle d'accès et la journalisation d'audit.

Domaine 2 : Gestion des identités et des accès

Les mauvaises configurations IAM constituent la catégorie de risque à impact le plus élevé dans les environnements infonuagiques. Le schéma d'attaque est cohérent : trouvez un compte surprivilégié, volez les identifiants, utilisez l'accès pour vous déplacer latéralement et exfiltrer des données.

Corrections immédiates à impact le plus élevé :

Cessez d'utiliser les comptes racine ou propriétaire pour les opérations quotidiennes. Les comptes racine AWS et les comptes administrateur général Azure doivent être utilisés uniquement pour les opérations de récupération d'urgence, avec l'AMF activée et les identifiants stockés de manière sécurisée hors ligne.

Appliquez l'authentification multifacteur partout. Chaque identité humaine accédant à votre environnement infonuagique - développeurs, administrateurs, analystes - doit utiliser l'authentification multifacteur. Ce seul contrôle arrête la majorité des attaques basées sur des identifiants. Il n'y a aucune raison opérationnelle valide d'avoir un utilisateur humain sans AMF en 2026.

Appliquez le principe du moindre privilège. Chaque rôle IAM, principal de service ou compte de service devrait avoir exactement les permissions dont il a besoin pour effectuer sa fonction - rien de plus. Auditez les permissions génériques (*) dans les politiques IAM AWS. Auditez les rôles Propriétaire et Contributeur dans Azure. Chacun est un chemin d'escalade de privilèges potentiel.

Faites la rotation des clés d'accès. Les clés d'accès de développeur qui ont 180 jours ou plus ne sont pas des clés - ce sont des clés compromise que vous n'avez pas encore découvertes. Définissez une politique de rotation de 90 jours et appliquez-la.

Supprimez les identifiants inutilisés. Lancez un audit des utilisateurs IAM et des comptes de service qui n'ont pas été actifs pendant 90 jours ou plus. Les comptes inactifs sont des cibles. Désactivez-les ou supprimez-les.

Domaine 3 : Protection des données

Vos données infonuagiques doivent être chiffrées en transit et au repos. Ce n'est pas optionnel - c'est une exigence de base dans chaque cadre de conformité et une exigence minimale en vertu de la Loi 25 pour les renseignements personnels.

Chiffrement en transit : Appliquez TLS 1.2 ou supérieur sur tous les points de terminaison d'API. Bloquez HTTP. Utilisez l'épinglage de certificat pour les applications sensibles. Évitez les suites de chiffrement obsolètes (RC4, MD5, SHA1).

Chiffrement au repos :

• AWS : Activez SSE-KMS sur les compartiments S3 (pas seulement SSE-S3). Assurez-vous que le chiffrement RDS est activé à la création - il ne peut pas être ajouté rétroactivement. Utilisez les clés KMS gérées par le client pour les données qui nécessitent votre contrôle sur la rotation des clés.
• Azure : Activez Transparent Data Encryption sur les bases de données SQL. Utilisez Azure Key Vault pour tous les secrets, certificats et chaînes de connexion. Ne stockez jamais de secrets dans les fichiers de configuration d'application.
• GCP : Utilisez les clés de chiffrement gérées par le client (CMEK) pour les compartiments Cloud Storage contenant des données sensibles. Activez le chiffrement au repos sur Cloud SQL.

Sauvegarde et récupération : Définissez votre RPO et votre RTO avant d'en avoir besoin. Testez votre processus de restauration de sauvegarde au moins mensuellement - les systèmes de sauvegarde qui n'ont jamais été testés ne sont pas des sauvegardes, c'est de l'espoir. Conservez au moins une copie de sauvegarde dans une région différente. Activez les sauvegardes immuables là où elles sont disponibles; elles sont votre défense principale contre les rançongiciels ciblant votre infrastructure de sauvegarde.

Domaine 4 : Sécurité réseau

Votre réseau infonuagique doit fonctionner selon le principe de la compromission présumée : concevez-le de sorte qu'une ressource compromise dans un niveau ne puisse pas atteindre librement les ressources dans un autre niveau.

Segmentez votre réseau. Les ressources accessibles au public (équilibreurs de charge, passerelles API) appartiennent à un sous-réseau public. Les serveurs d'application appartiennent à un sous-réseau privé sans accès Internet direct. Les bases de données appartiennent à un sous-réseau privé distinct accessible uniquement à partir du niveau application. Cette architecture en couches signifie qu'un attaquant qui compromise votre niveau web fait toujours face à une frontière réseau avant d'atteindre vos données.

Resserrez les règles de groupe de sécurité et de pare-feu. La configuration de groupe de sécurité par défaut dans la plupart des environnements infonuagiques permet tout le trafic sortant. Restreignez l'appel sortant à des destinations et ports spécifiques. Supprimez les règles d'appel entrant qui permettent l'accès depuis 0.0.0.0/0 (l'Internet entier) sur des ports autres que 80 et 443. RDP (port 3389) et SSH (port 22) ne doivent jamais être ouverts sur Internet - utilisez un VPN ou un hôte bastion.

Activez la journalisation des flux. Les journaux de flux VPC (AWS), les journaux de flux NSG de Network Watcher (Azure) et les journaux de flux VPC (GCP) vous donnent la visibilité réseau dont vous avez besoin pour détecter les déplacements latéraux, l'exfiltration de données et les modèles de trafic anormaux. Sans journalisation des flux, vous enquêtez sur une violation sans preuve réseau.

Domaine 5 : Journalisation et surveillance

Vous ne pouvez pas détecter ce que vous ne pouvez pas voir. La journalisation et la surveillance ne sont pas une case de conformité - elles sont le fondement de votre capacité de détection.

Activez la journalisation d'audit sur chaque compte. CloudTrail AWS doit être actif sur chaque compte AWS, avec des journaux livrés à un compartiment S3 centralisé et sécurisé. Les journaux d'activité Azure et les journaux d'audit Azure AD doivent être alimentés dans Log Analytics. Cloud Audit Logs GCP devrait capturer Admin Activity au minimum, et les journaux d'accès aux données pour les services sensibles.

Conservez les journaux suffisamment longtemps pour être utiles. Le temps moyen entre la compromission et la détection est mesuré en semaines, pas en heures. Si vous conservez les journaux pendant seulement 30 jours, vous n'avez peut-être pas les preuves dont vous avez besoin quand vous découvrez un incident. Conservez les journaux pendant 90 jours au minimum; un an pour les services traitant des données personnelles ou sensibles.

Configurez la détection des menaces. AWS GuardDuty, Azure Defender et GCP Security Command Center offrent une détection automatique des menaces en utilisant l'analyse comportementale et l'intelligence sur les menaces. Ce ne sont pas des services coûteux - activez-les. Examinez les résultats au moins mensuellement.

Domaine 6 : Préparation à la réponse aux incidents

Votre plan de réponse aux incidents infonuagiques doit tenir compte des capacités et des contraintes spécifiques des environnements infonuagiques.

Lorsqu'une instance infonuagique est compromise, vos options de réponse sont différentes de celles d'un environnement on-premise : vous pouvez créer un instantané de l'instance pour analyse forensique, la supprimer immédiatement et créer un remplacement propre en minutes. Cette capacité est précieuse - mais seulement si vous avez un manuel qui dit à votre équipe de l'utiliser.

Définissez vos procédures d'isolation pour chaque fournisseur infonuagique. Sachez comment détacher une instance d'un VPC sans la détruire. Sachez comment exporter les journaux CloudTrail avant qu'un compte soit compromise davantage. Sachez comment révoquer les sessions IAM actives immédiatement.

Connectez votre plan de réponse aux incidents infonuagiques à votre processus de réponse aux incidents plus large. Les déclencheurs de détection, les classifications de sévérité et les chemins d'escalade doivent être cohérents.

Domaine 7 : Cartographie de la conformité

Pour les entreprises québécoises, la conversation sur la conformité commence par la Loi 25. Voici les contrôles techniques qu'elle exige pour les environnements infonuagiques :

EIPD (Évaluation d'impact sur la protection des données) : Requise avant tout transfert de renseignements personnels hors du Québec. Si vous utilisez un service infonuagique en région américaine ou un produit SaaS avec stockage de données aux États-Unis, vous avez besoin d'une EIPD. L'évaluation doit évaluer si la juridiction destinataire fournit un niveau de protection adéquat.

Minimisation des données : Collectez et conservez uniquement les renseignements personnels dont vous avez besoin. Le stockage infonuagique est peu coûteux, ce qui crée une tendance à tout conserver indéfiniment. La Loi 25 exige que vous justifiiez la rétention et supprimiez les données quand le but est rempli.

Journalisation des accès : Vous devez pouvoir démontrer qui a accédé aux renseignements personnels, quand et à quelle fin. Cela signifie activer les journaux d'accès aux données sur les services infonuagiques qui stockent des renseignements personnels - et conserver ces journaux de manière appropriée.

Notification des violations : Comme indiqué dans notre article sur la réponse aux incidents, la Loi 25 exige une notification rapide à la CAI si un incident de confidentialité crée un risque de préjudice sérieux.

Les 10 corrections que vous pouvez apporter cette semaine

Vous n'avez pas besoin d'aborder tout à la fois. Commencez par les contrôles qui arrêtent les modèles d'attaque les plus courants :

1. Activez l'AMF sur tous les comptes humains - sans exception
2. Faites la rotation ou supprimez les clés d'accès IAM de plus de 90 jours
3. Supprimez les permissions génériques (*) des politiques IAM
4. Vérifiez que tous les compartiments S3 ne sont pas publiquement accessibles (utilisez AWS Trusted Advisor ou S3 Block Public Access)
5. Activez CloudTrail / Journaux d'activité / Cloud Audit Logs s'ils ne le sont pas déjà
6. Activez GuardDuty / Azure Defender / GCP SCC sur tous les comptes
7. Auditez les groupes de sécurité pour RDP/SSH ouvert depuis 0.0.0.0/0
8. Confirmez que le chiffrement au repos des bases de données est activé
9. Testez une restauration de sauvegarde - confirmez que votre RTO est atteignable
10. Si vous stockez des renseignements personnels : confirmez la région et initiez votre EIPD si les données sont hors du Québec

Téléchargez la liste de vérification complète avec la matrice de notation