Guide : La sécurité du cloud computing

Pourquoi la sécurité cloud est différente de la sécurité on-premise ?

Avec AWS, Google Cloud, Azure, Google Workspace ou Microsoft 365, vous ne sécurisez plus un serveur — vous sécurisez une configuration. Et c’est précisément là que tout se joue : 80 % des fuites cloud (Capital One 100M+ records, Twitch source code, Equifax) sont dues à des misconfigurations client (bucket S3 public, bases de données ouvertes, IAM trop permissif), pas à des failles du fournisseur. Au Sénégal, le passage massif au cloud (Google Workspace pour les PME, AWS pour les startups) impose de comprendre le modèle de responsabilité partagée avant tout.

Le cloud computing : nouvelles opportunités, nouveaux risques

La migration vers le cloud (AWS, Azure, Google Cloud) offre flexibilité et économies, mais introduit aussi de nouveaux risques de sécurité. La responsabilité de la sécurité est partagée entre vous et le fournisseur.

Le modèle de responsabilité partagée

Couche	IaaS (ex: EC2)	PaaS (ex: Heroku)	SaaS (ex: Gmail)
Données	Vous	Vous	Vous
Applications	Vous	Vous	Fournisseur
OS / Runtime	Vous	Fournisseur	Fournisseur
Infrastructure	Fournisseur	Fournisseur	Fournisseur

Les 5 risques cloud les plus courants

1. Mauvaise configuration — buckets S3 publics, bases de données exposées (cause N°1 de fuites)
2. Gestion des accès faible — trop de comptes admin, pas de MFA
3. Données non chiffrées — en transit et au repos
4. Absence de logs — impossible de détecter une intrusion
5. Shadow IT — employés utilisant des services cloud non approuvés

Sécuriser vos services cloud

1. Gestion des identités (IAM)

• Principe du moindre privilège : chaque utilisateur n’a que les droits nécessaires
• MFA obligatoire pour tous les comptes, surtout les admins
• Rotation des clés d’accès tous les 90 jours
• Pas de clés d’accès root en production

2. Chiffrement

• En transit : TLS/SSL obligatoire pour toute communication
• Au repos : activer le chiffrement des disques et bases de données
• Gestion des clés : utilisez AWS KMS, Azure Key Vault ou GCP KMS

3. Réseau

• VPC : isolez vos ressources dans un réseau virtuel privé
• Security Groups : n’ouvrez que les ports nécessaires
• WAF : Web Application Firewall devant vos applications web

4. Monitoring et logs

• Activez CloudTrail (AWS), Activity Log (Azure)
• Configurez des alertes pour les activités suspectes
• Centralisez les logs avec un SIEM

Sécurité SaaS (Google Workspace, Microsoft 365)

Erreurs fréquentes (cloud)

1. Bucket S3/GCS configuré « public-read » par défaut

Cause : on crée un bucket pour stocker des images publiques de site web, et on configure tout le bucket en lecture publique. Mais on y stocke aussi par mégarde des backups DB, exports clients, fichiers internes.

Solution : activez Block Public Access au niveau compte AWS. Pour les fichiers publics, utilisez une CDN (CloudFront, Cloudflare R2) qui distribue sans exposer le bucket. Auditez avec CloudSploit ou Prowler.

2. Clés d’accès AWS commitées dans Git

Cause : on push .env avec AWS_SECRET_ACCESS_KEY sur GitHub public. Les bots scannent en permanence et minent du Bitcoin sur votre compte en quelques heures, vous coûtant des milliers d’USD.

Solution : .gitignore systématique pour .env + Gitleaks en pre-commit. Utilisez AWS Secrets Manager / GCP Secret Manager pour les credentials, et IAM Roles au lieu de clés d’accès quand possible.

3. Pas de MFA sur le compte root

Cause : le compte root AWS sans MFA = porte ouverte. Une seule fuite du mot de passe (ou phishing du DSI) donne accès à toute l’infrastructure.

Solution : MFA matériel (YubiKey) sur le compte root. Et n’utilisez root que pour les opérations qui le nécessitent vraiment : créez des comptes IAM individuels avec MFA pour le quotidien.

4. Sauvegardes Google Workspace inexistantes

Cause : « Google fait les backups ». Faux : Google protège son infrastructure mais une suppression accidentelle d’utilisateur ou un compromise admin efface vos données définitivement après 30 jours.

Solution : backup tiers indépendant : Spin.AI, Spanning, Synology Active Backup (gratuit avec NAS). Y compris pour Microsoft 365.

5. Logs cloud non centralisés

Cause : CloudTrail/Activity Log activés mais stockés dans un bucket que personne ne lit. Une intrusion passe inaperçue 6 mois, jusqu’à la facture surprise.

Solution : centralisez les logs vers un SIEM : AWS Security Hub, Datadog, ou Wazuh (gratuit open source). Configurez des alertes EventBridge sur les actions sensibles (création utilisateur IAM, désactivation MFA, suppression de bucket).

Exercice pratique

Pour étoffer le tableau

• Gérer les droits d’accès dans votre entreprise — IAM est l’épine dorsale du cloud.
• Créer un plan de reprise après sinistre — backups cloud indépendants.
• Sécuriser les API de votre application — les API sont le front-end du cloud.
• Sécuriser un serveur Linux (VPS) — IaaS reste votre responsabilité.
• Référence officielle : CIS Benchmarks AWS/Azure/GCP et OWASP Cloud Native Top 10.
• Outils gratuits : Prowler (audit AWS/Azure/GCP), CloudSploit, Wazuh (SIEM).

Etape 1 : cartographier les actifs avant d’acheter du cloud

La securite cloud commence avant la migration, pas apres. Sans inventaire des donnees, des applications et des dependances, impossible de dimensionner les controles. Une PME a Dakar qui hesite entre AWS Cape Town, Azure Johannesburg et un datacenter local Sonatel doit d’abord lister ce qu’elle deplace : base clients, factures, logs applicatifs, sauvegardes, secrets API.

# Inventaire rapide d'un serveur Linux existant
sudo find /var /home /opt -type f -size +10M 2>/dev/null > inventaire.txt
sudo du -sh /var/lib/mysql /var/www 2>/dev/null
ls -la /etc/ssl/private/ 2>/dev/null

Le fichier inventaire.txt liste les gros fichiers. La taille des bases MySQL et des dossiers web donne l’ordre de grandeur. La presence de cles privees dans /etc/ssl/private signale ce qu’il faudra absolument migrer vers un gestionnaire de secrets et jamais committer dans Git.

Etape 2 : comprendre le modele de responsabilite partagee

Chez AWS, Azure, GCP, OVHcloud, Scaleway : le fournisseur securise l’infrastructure (datacenter, hyperviseur, reseau physique), le client securise ce qu’il y depose (OS, applications, donnees, identites, configurations). Cette ligne bouge selon le service. En IaaS (machine virtuelle), 80% du travail reste cote client. En SaaS (Microsoft 365, Google Workspace), le client gere surtout les identites et les permissions.

Pratiquement, cela veut dire qu’un bucket S3 mal configure reste de la responsabilite du client, meme si AWS facture le stockage. La majorite des fuites massives publiques sur 2024-2025 viennent de cette zone grise mal comprise.

Etape 3 : durcir les identites et les acces (IAM)

L’authentification est la premiere ligne de defense. Activer le MFA sur tous les comptes admin, sans exception. Sur AWS, desactiver l’usage des cles d’acces racine et creer des roles IAM avec permissions minimales.

# AWS CLI : creer un utilisateur avec permissions limitees
aws iam create-user --user-name dev-dakar
aws iam attach-user-policy --user-name dev-dakar \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
aws iam create-access-key --user-name dev-dakar

La sortie contient un AccessKeyId et un SecretAccessKey. Le secret n’est affiche qu’une seule fois — le stocker immediatement dans un coffre (AWS Secrets Manager, HashiCorp Vault, Bitwarden auto-heberge). Pour Azure, l’equivalent passe par Entra ID et les role assignments. Pour GCP, par les service accounts et les conditions IAM.

Etape 4 : chiffrer au repos et en transit

Le chiffrement en transit (TLS 1.3) est devenu standard et active par defaut chez tous les grands fournisseurs. Le chiffrement au repos demande plus d’attention : choisir entre cles managees par le fournisseur, cles managees par le client (CMK), ou apporter sa propre cle (BYOK).

# Activer le chiffrement par defaut sur un bucket S3 existant
aws s3api put-bucket-encryption \
  --bucket factures-pme-dakar \
  --server-side-encryption-configuration '{
    "Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]
  }'

Verifier avec aws s3api get-bucket-encryption --bucket factures-pme-dakar. La reponse JSON doit afficher SSEAlgorithm: AES256. Pour les donnees personnelles soumises a la loi senegalaise 2008-12, la regle de prudence : chiffrement cote client avant upload, surtout si les cles restent en juridiction nationale.

Etape 5 : reseau prive, segmentation et firewall applicatif

Mettre une base de donnees en acces public est l’erreur la plus frequente. La regle : VPC prive, sous-reseaux dedies, security groups restrictifs, et acces externe uniquement via un bastion ou un VPN. Pour le HTTP public, un WAF (Web Application Firewall) filtre les attaques SQLi, XSS et bots avant qu’elles ne touchent l’application.

# AWS : security group qui n'autorise MySQL que depuis l'app
aws ec2 create-security-group --group-name db-sg --description "DB privee"
aws ec2 authorize-security-group-ingress \
  --group-name db-sg --protocol tcp --port 3306 \
  --source-group sg-app123456

La base devient inaccessible depuis Internet. Tester avec nmap -p 3306 depuis l’exterieur — la reponse doit etre filtered ou closed. Si open, revenir au security group et retirer toute regle 0.0.0.0/0 sur les ports de base de donnees.

Etape 6 : journaux, alertes et detection d’incidents

Sans logs, pas d’investigation post-incident. Activer CloudTrail sur AWS, Activity Log sur Azure, Cloud Audit Logs sur GCP. Centraliser dans un bucket dedie, avec retention minimum 90 jours, ideal 1 an pour traiter les incidents lents.

# Activer CloudTrail pour toute l'organisation
aws cloudtrail create-trail \
  --name audit-trail \
  --s3-bucket-name logs-audit-pme \
  --is-multi-region-trail \
  --enable-log-file-validation
aws cloudtrail start-logging --name audit-trail

Apres 24h, le bucket contient des fichiers JSON gzippes par heure. Brancher un service de detection (GuardDuty sur AWS, Defender for Cloud sur Azure, Security Command Center sur GCP) pour recevoir des alertes sur comportements suspects : connexions depuis pays inhabituels, escalades de privileges, exfiltration de donnees.

Etape 7 : sauvegardes immuables et test de restauration

Une sauvegarde non testee n’est pas une sauvegarde. La regle 3-2-1 reste valable : 3 copies, 2 supports differents, 1 hors site. Dans le cloud, l’equivalent moderne ajoute l’immuabilite : un attaquant qui prend le controle d’un compte ne doit pas pouvoir effacer les sauvegardes.

# S3 Object Lock : sauvegardes immuables 30 jours
aws s3api put-object-lock-configuration \
  --bucket backups-pme \
  --object-lock-configuration '{
    "ObjectLockEnabled":"Enabled",
    "Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}
  }'

En mode COMPLIANCE, meme la racine du compte ne peut pas supprimer les objets avant 30 jours. Tester une restauration complete au moins une fois par trimestre : monter une instance vide, restaurer la base, verifier l’integrite. Le signal de reussite : la PME peut redemarrer son SI complet en moins de 4 heures.

Etape 8 : conformite et residence des donnees en Afrique de l’Ouest

Pour une entreprise soumise a la loi senegalaise sur les donnees personnelles, ou aux obligations sectorielles BCEAO pour la fintech, choisir une region cloud devient un acte juridique. AWS Cape Town, Azure Johannesburg et GCP n’ont pas de region dans la zone UEMOA — les transferts hors zone exigent des clauses contractuelles. OVHcloud Paris reste dans le RGPD europeen, ce qui simplifie pour les clients de l’UE mais ne resout pas la residence locale.

La parade pratique : architecture hybride. Donnees nominatives chiffrees dans un datacenter local (Sonatel, Atos Cote d’Ivoire), traitement et calcul dans le cloud public, tokens reversibles uniquement cote client. Le cout supplementaire reste limite (environ 65 595 FCFA par mois pour 100 GB local, soit 100 EUR au taux fixe 1 EUR = 655,957 FCFA).

Etape 9 : exercices reguliers et culture de securite

La securite cloud n’est pas un projet ferme : c’est une discipline continue. Programmer un exercice trimestriel : revue des permissions IAM, rotation des cles, test de restauration, simulation de phishing sur les equipes. Documenter chaque incident meme mineur dans un registre — ce qui n’est pas mesure n’est pas ameliore.

Pour étoffer le tableau sur l’isolation reseau et la gestion d’identite, voir la gestion d’un WordPress Multisite qui partage les memes principes de cloisonnement. Pour automatiser les controles, jeter un oeil au guide pratique Gemini qui aide a generer des politiques IAM et detecter les anomalies dans les logs.

Etape 10 : checklist finale avant mise en production

Avant d’exposer un service au public, valider sept points : MFA actif sur tous les comptes admin, chiffrement au repos et en transit confirme, ports de base de donnees inaccessibles depuis Internet, journaux centralises et retention 90 jours minimum, sauvegardes immuables testees, alertes branchees sur un canal lu (email + Telegram ou Slack), et plan de reponse a incident ecrit avec numeros de telephone des responsables. Si un seul de ces points manque, repousser la mise en production — un incident coute toujours plus cher qu’une semaine de retard.