Sécurité cloud pour PME canadiennes : Zero Trust, IAM et conformité

En 2019, Capital One se fait voler les données personnelles de 106 millions de clients. Le vecteur d'attaque ? Une mauvaise configuration d'un rôle IAM AWS qui donnait accès à des métadonnées d'instance. En 2022, Uber subit une brèche catastrophique via une attaque de credential stuffing aggravée par l'absence de MFA sur un compte VPN. En 2023, des chercheurs de Wiz trouvent plus de 38 térabytes de données Microsoft exposées sur Azure Blob Storage — un partage de formation configuré avec des permissions trop larges.

Ces brèches ont en commun un fait troublant : aucune n'est due à une faille dans l'infrastructure du provider cloud. AWS, Azure et GCP ont bien sécurisé leur côté. La vulnérabilité était entièrement du côté client.

Si vous pensez que "migrer vers le cloud" vous rend automatiquement plus sécurisé, ce billet est pour vous.

Le modèle de responsabilité partagée : ce que le provider gère vs ce que vous devez gérer

Chaque grand provider cloud communique clairement son modèle de responsabilité partagée. En pratique, peu d'organisations le lisent vraiment — et c'est là que les catastrophes commencent.

Ce que le provider gère (son périmètre) :

• Sécurité physique des datacenters (accès biométrique, gardes, géo-redondance)
• Hardware : serveurs, stockage, réseau backbone
• Infrastructure de virtualisation et hyperviseurs
• Disponibilité et résilience des zones/régions
• Conformité infrastructure (certifications SOC 2, ISO 27001, PCI-DSS au niveau infra)
• Patches OS des services entièrement managés (RDS, Lambda, Azure SQL Managed Instance)

Ce que VOUS devez gérer (votre périmètre) :

• Gestion des identités et des accès (IAM) — rôles, policies, permissions
• Configuration des Security Groups, NSG, firewalls
• Chiffrement de vos données au repos et en transit
• Patches OS de vos VMs (EC2, Azure VM) — si vous gérez l'OS, vous patchez
• Configuration des buckets S3 / Azure Blob / GCS — public vs privé
• Gestion de vos secrets, clés API, certificats
• Logs, monitoring, alertes de sécurité
• Conformité réglementaire (LPRPDE, PHIPA, OSFI) — le provider ne fait pas ça pour vous

La règle de Gartner s'applique parfaitement ici : "À travers 2025, 99% des défaillances de sécurité cloud seront la faute du client." Ce n'est pas une critique des providers — c'est la réalité du modèle partagé.

Zero Trust : "ne jamais faire confiance, toujours vérifier"

Le modèle de sécurité traditionnel était basé sur le périmètre réseau : tout ce qui est dans le réseau d'entreprise est "de confiance", tout ce qui est à l'extérieur ne l'est pas. Le firewall était le château fort, le VPN le pont-levis.

Dans le cloud, ce modèle est mort. Vos ressources sont réparties sur plusieurs régions, plusieurs providers, plusieurs équipes. Les employés travaillent de partout. Les microservices communiquent entre eux dans le même VPC. Il n'y a plus de "périmètre" — seulement des identités et des ressources.

Zero Trust, formalisé par John Kindervag chez Forrester, repose sur trois principes fondamentaux :

1. Ne jamais faire confiance implicitement — même une requête venant de l'intérieur du réseau interne doit être authentifiée et autorisée
2. Toujours vérifier explicitement — chaque accès est évalué en temps réel : qui est l'utilisateur ? Quel est son appareil ? D'où vient la requête ? Quelle est la sensibilité de la ressource ?
3. Supposer la compromission — concevoir l'architecture comme si l'attaquant était déjà dans le réseau. Segmenter pour limiter le blast radius.

Implémentation pratique Zero Trust en cloud

Micro-segmentation : Ne mettez pas toutes vos ressources dans un seul sous-réseau. Isolez par fonction et sensibilité : les bases de données dans un subnet privé sans accès internet, les API dans un subnet applicatif, les outils d'administration dans un subnet dédié accessible uniquement depuis des IPs connues (ou via VPN/bastion). Sur AWS : VPC avec subnets privés/publics distincts, Security Groups granulaires par workload. Sur Azure : VNet avec NSG et Azure Firewall.

MFA partout et pour tout : L'authentification multi-facteurs est la mesure de sécurité avec le meilleur ROI qui existe. Microsoft affirme que le MFA bloque 99,9% des attaques basées sur des mots de passe compromis. Obligatoire pour : comptes root / Global Admin, tous les comptes humains avec accès console, VPN et bastion hosts, accès aux secrets et au vault.

Device trust : Zero Trust évalue aussi l'état de l'appareil. Un accès depuis un laptop non patché, sans chiffrement de disque, doit être refusé ou limité. AWS Verified Access et Azure Conditional Access permettent d'évaluer la conformité de l'appareil avant d'accorder l'accès. Intégrez avec votre MDM (Jamf, Microsoft Intune) pour automatiser ces vérifications.

Principe de la session courte : Au lieu de credentials à longue durée de vie (clés API qui ne changent jamais), utilisez des tokens temporaires. AWS STS génère des credentials temporaires valides 1 heure maximum. Azure Managed Identities éliminent complètement la gestion de secrets pour les services Azure.

IAM : le principe du moindre privilège, rigoureusement appliqué

La gestion des identités et des accès est, de loin, le domaine où les PME font le plus d'erreurs — et où les conséquences sont les plus graves.

Rôles vs Policies vs Service Accounts

Policies définissent CE QUE vous pouvez faire (Allow/Deny sur des actions et ressources spécifiques). Rôles regroupent des policies et peuvent être assumés par des utilisateurs ou des services. Service Accounts (ou Managed Identities sur Azure) sont des identités pour les applications, pas pour les humains.

Principe du moindre privilège en pratique :

• Ne donnez jamais *:* (toutes actions sur toutes ressources) — même temporairement "pour déboguer"
• Utilisez des policies granulaires : un service de lecture de logs ne doit avoir que logs:GetLogEvents, pas logs:*
• Séparez les rôles humains par fonction : développeur ≠ ops ≠ sécurité ≠ admin
• Revue trimestrielle des accès : supprimez les permissions inutilisées (AWS IAM Access Analyzer détecte les permissions non utilisées depuis 90 jours)

Service Accounts et rotation des clés

Chaque service qui appelle une API cloud doit avoir sa propre identité avec le minimum de permissions. Pas de compte partagé entre plusieurs applications. Et surtout :

• Rotation automatique des clés d'accès tous les 90 jours maximum
• Préférez les IAM Roles aux access keys statiques pour les services EC2 / Lambda / Kubernetes (les roles n'ont pas de clé — ils utilisent des tokens temporaires automatiques)
• Auditez les clés existantes : AWS IAM Access Analyzer et Azure Credential Scanner identifient les clés non utilisées depuis longtemps

MFA obligatoire sur tous les comptes humains

Imposez le MFA via une policy IAM qui refuse toutes les actions sauf iam:EnableMFA tant que l'utilisateur n'a pas configuré son authentificateur. Exemple de policy AWS :

{
  "Effect": "Deny",
  "NotAction": ["iam:EnableMFA", "iam:GetUser"],
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}
  }
}

Audit logs : votre boîte noire

CloudTrail (AWS), Azure Monitor Activity Log, et GCP Audit Logs enregistrent toutes les actions API sur votre compte. Ces logs sont votre première ligne de défense après un incident — et souvent la seule façon de savoir ce qui s'est passé. Configuration obligatoire :

• Activer CloudTrail multi-region avec export S3 + alertes CloudWatch sur les événements critiques (LoginWithNoMFA, DeleteTrail, ConsoleLogin depuis une IP inconnue)
• Rétention minimale : 90 jours actif + 1 an en cold storage
• Centraliser les logs dans un compte séparé — l'attaquant qui compromet votre compte principal ne doit pas pouvoir supprimer ses traces

Sécurité réseau cloud

Security Groups (AWS) / NSG (Azure) : Les security groups sont des firewalls stateful au niveau instance. Règle d'or : refuser par défaut, autoriser explicitement. Fermez le port 22 (SSH) sur internet — utilisez AWS Systems Manager Session Manager ou Azure Bastion pour l'accès administratif sans exposer de ports. Jamais de règle 0.0.0.0/0 sur SSH ou RDP.

VPC / VNet isolation : Isolez vos workloads par environnement (VPC prod ≠ VPC staging) et par sensibilité. VPC Peering pour les communications inter-VPC contrôlées. PrivateLink / Private Endpoints pour accéder aux services managés (S3, RDS, Key Vault) sans passer par internet.

NACLs (Network Access Control Lists) : Couche de défense supplémentaire au niveau subnet (stateless). Moins granulaires que les security groups, mais utiles pour bloquer des plages d'IPs malveillantes au niveau réseau.

WAF (Web Application Firewall) : AWS WAF, Azure Front Door WAF, ou GCP Cloud Armor protègent vos API et applications web contre les attaques OWASP Top 10 (injection SQL, XSS, etc.). Activez les règle sets managés (Core Rule Set) et configurez le rate limiting pour contrer les attaques par force brute.

Protection DDoS : AWS Shield Standard (inclus gratuitement) protège contre les attaques DDoS volumétriques communes. AWS Shield Advanced (3 000 USD/mois) offre une protection plus sophistiquée avec accès à l'équipe DDoS Response Team d'Amazon. Azure DDoS Protection Standard et GCP Cloud Armor proposent des offres équivalentes.

Chiffrement : données au repos et en transit

At rest — AES-256 : Activez le chiffrement sur tous vos volumes (EBS, Azure Disk, GCP Persistent Disk), buckets (S3 SSE, Azure Blob Encryption, GCS), et bases de données (RDS, Azure SQL, Cloud SQL). Sur AWS, aws:kms permet d'utiliser vos propres clés via KMS. C'est une case à cocher — mais vérifiez qu'elle est cochée sur TOUTES vos ressources, pas seulement les nouvelles.

In transit — TLS 1.3 : Tout le trafic entre vos services doit être chiffré. Entre le client et l'API : HTTPS (TLS 1.3 minimum, désactivez TLS 1.0/1.1). Entre les services internes dans un VPC : mTLS (mutual TLS) pour une authentification bidirectionnelle. AWS ACM (Certificate Manager) gère gratuitement vos certificats TLS avec renouvellement automatique.

KMS / Key Vault : gestion des clés

Un chiffrement sans gestion des clés solide, c'est une porte verrouillée avec la clé sous le paillasson. Les services de gestion de clés cloud sont conçus pour ça :

• AWS KMS : service managé, intégration native avec S3, EBS, RDS, Lambda. Customer Managed Keys (CMK) vous donnent le contrôle. Clés régionales, audit trail complet dans CloudTrail.
• Azure Key Vault : stocke clés, secrets et certificats. Premium tier utilise des HSM FIPS 140-2 Level 2. Intégration native avec tous les services Azure via Managed Identity.
• GCP Cloud KMS : gestion centralisée avec Cloud HSM disponible. Key Access Justification (Cloud EKM) permet de voir et d'approuver/refuser chaque accès à vos clés.

Rotation des clés : Configurez la rotation automatique annuelle minimum pour vos clés KMS. Pour les secrets applicatifs (mots de passe, tokens API), rotation tous les 90 jours via AWS Secrets Manager ou Azure Key Vault avec rotation automatique intégrée.

Conformité canadienne : LPRPDE, PHIPA, OSFI

Pour les PME canadiennes, la conformité n'est pas optionnelle — et le cloud ne vous en exempte pas.

LPRPDE / PIPEDA (Loi sur la protection des renseignements personnels et les documents électroniques) : Régit la collecte, l'utilisation et la divulgation des données personnelles au Canada. Exigences clés pour le cloud :

• Consentement explicite avant collecte
• Divulgation des atteintes à la vie privée si risque réel de préjudice grave
• Accès des individus à leurs données et droit de correction
• Si vos données sortent du Canada, connaître les lois du pays destinataire

Résidence des données en Canada : La LPRPDE ne l'impose pas explicitement, mais beaucoup de secteurs réglementés (public, santé, finance) l'exigent contractuellement ou par politique. AWS Canada (ca-central-1 à Montréal), Azure Canada (Canada Central à Toronto, Canada East à Québec), et GCP Canada (northamerica-northeast1 à Montréal, northamerica-northeast2 à Toronto) offrent tous des régions canadiennes. Vérifiez que vos sauvegardes et logs restent aussi au Canada — les region pairs de réplication par défaut peuvent exporter vers des régions américaines.

PHIPA (Personal Health Information Protection Act, Ontario) : Réglemente les données de santé des résidents ontariens. Les dépositaires d'information sur la santé (hôpitaux, cliniques, pharmacies, applications santé) doivent :

• Utiliser des fournisseurs cloud qui signent des accords de protection de l'information sur la santé (Health Privacy Agreements)
• Limiter l'accès aux données de santé au strict nécessaire (principe IAM direct)
• Maintenir des logs d'audit de tous les accès aux données de santé
• Notifier le Commissaire à la vie privée en cas de brèche dans les 24-72 heures

OSFI (Bureau du surintendant des institutions financières) : Pour les institutions financières fédérales (banques, assureurs, coopératives de crédit), la ligne directrice B-10 sur la gestion des risques liés aux tiers impose :

• Évaluation de risque formelle avant tout engagement cloud
• Contrôle des données critiques et droit d'audit des providers cloud
• Plans de résilience et de sortie (exit strategy) documentés
• Notification au BSIF pour services "matériels" hébergés dans le cloud

Tableau : AWS vs Azure vs GCP — Outils de sécurité natifs

Les erreurs qui ouvrent la porte aux attaquants

🚨 Clés AWS hardcodées dans Git
C'est l'erreur numéro un, celle qu'on retrouve dans presque chaque audit PME. Un développeur pousse un commit avec AWS_ACCESS_KEY_ID=AKIA... dans un fichier de config. GitHub (ou GitLab) expose ce repo publiquement — souvent par erreur. Des bots scannent GitHub en continu et récupèrent ces clés en moins de 4 minutes. Résultat : un attaquant mine du Bitcoin sur votre compte AWS à 50 000 USD par jour.

Solution : git-secrets (AWS Labs) ou detect-secrets en pre-commit hook. AWS Secrets Manager + IAM Roles pour éliminer les clés statiques. GitHub Advanced Security pour détecter les secrets dans l'historique existant.

🚨 Buckets S3 publics
AWS a forcé la configuration "Block Public Access" par défaut en avril 2023 — mais les comptes créés avant cette date peuvent encore avoir des buckets publics. Un bucket S3 public, c'est potentiellement une base de données clients, des sauvegardes, des fichiers de config exposés à internet. Vérifiez : aws s3api list-buckets + aws s3api get-bucket-acl ou utilisez AWS Config Rule s3-bucket-public-read-prohibited pour un audit automatique.

🚨 Logs désactivés ou non centralisés
CloudTrail, VPC Flow Logs, Access Logs S3 — des PME les désactivent "pour économiser sur le stockage". Résultat : quand un incident survient, il est impossible de retracer ce qui s'est passé, qui a fait quoi, et depuis quand. Le coût des logs de sécurité est négligeable (quelques dizaines de dollars par mois pour un compte moyen). Le coût de leur absence lors d'un incident peut atteindre des centaines de milliers de dollars.

🚨 MFA absent sur le compte root / Global Admin
Le compte root AWS ou le Global Administrator Azure est la clé du château. Sans MFA, un mot de passe compromis (phishing, password spray) donne à l'attaquant un accès total, immédiat et irréversible. Activez le MFA sur ces comptes aujourd'hui, maintenant, avant de continuer à lire ce billet.

🚨 Security Groups trop permissifs "en attendant"
"Je vais ouvrir le port 22 de partout temporairement pour déboguer" — et la règle reste là des mois. Les security groups doivent être revus tous les 90 jours. AWS Config Rule restricted-ssh détecte automatiquement les Security Groups qui autorisent SSH depuis 0.0.0.0/0.

Cas concret BOTUM : 23 vulnérabilités critiques, remédiées en 2 semaines

Contexte : agence de marketing digital québécoise, 45 employés, stack AWS (EC2, RDS, S3, CloudFront, Lambda). Le RSSI nouvellement nommé contacte BOTUM pour un audit de sécurité cloud complet — "juste pour voir où on en est". Ils pensaient être en bonne forme.

Résultats de l'audit (semaine 1) :

• 3 clés AWS actives dans des repos GitHub publics — dont une clé avec permissions AdministratorAccess poussée il y a 8 mois, toujours active
• 2 buckets S3 publics contenant des exports de bases de données clients (noms, emails, numéros de téléphone)
• 17 règles Security Group autorisant SSH ou RDP depuis 0.0.0.0/0
• CloudTrail désactivé dans la région us-east-1 (où tournaient 60% de leurs workloads)
• Aucun MFA sur 6 comptes IAM humains, dont 2 avec AdministratorAccess
• Rotation de clés inexistante — des clés d'accès créées il y a 3 ans toujours actives
• RDS exposé sur internet (port 3306 ouvert depuis 0.0.0.0/0) — protégé uniquement par un mot de passe de 8 caractères

Total : 23 vulnérabilités critiques ou élevées, représentant un risque CVSS composite de 9.1/10.

Plan de remédiation (semaine 2) :

• Révocation immédiate des 3 clés AWS compromises. Audit de toutes les actions effectuées par ces clés depuis 8 mois via CloudTrail.
• Migration vers IAM Roles pour toutes les applications EC2 et Lambda — zéro clé statique.
• Blocage public access sur tous les buckets S3 + notification aux clients potentiellement affectés (LPRPDE).
• Activation de CloudTrail multi-region avec 90 jours de rétention active + export S3 vers compte séparé.
• Fermeture de toutes les règles SSH/RDP publiques — passage à AWS Systems Manager Session Manager.
• MFA obligatoire imposé via IAM Policy sur tous les comptes humains.
• Fermeture du port RDS, migration vers accès via VPC privé uniquement.

Résultat : 23 vulnérabilités critiques → 0 en 14 jours. Surface d'attaque réduite de 87%. Coût de la remédiation : 3 jours d'ingénierie BOTUM. Coût potentiel d'une brèche sur ces vulnérabilités : estimé entre 500 000 et 2 000 000 CAD (sanctions LPRPDE + notification clients + frais légaux + réputation).

Conclusion : la sécurité cloud, ça se gère

La sécurité cloud n'est pas optionnelle pour une PME en 2024. Les attaquants ne font pas de distinction entre une PME de 20 personnes et une entreprise du Fortune 500 — ils cherchent les configurations mal faites, les clés exposées, les permissions trop larges. Ces configurations existent dans les deux cas.

La bonne nouvelle : les outils existent, ils sont natifs aux providers cloud, et la plupart sont inclus dans vos frais d'infrastructure existants. Un audit sécurité de base — 2 à 3 jours — révèle systématiquement les problèmes les plus critiques. Et les corriger prend rarement plus de 2 semaines.

La question n'est pas "est-ce que je peux me permettre de faire ça ?" La vraie question : "est-ce que je peux me permettre de ne pas le faire ?"