Cybersécurité

Sécurité du cloud : Azure, AWS et Google Cloud

11 min de lecture

Ce que vous saurez faire

  1. Sécuriser AWS/Azure/GCP avec IAM minimal
  2. KMS pour chiffrement
  3. VPC et network policies
  4. Monitoring CloudTrail

Vue d’ensemble 1 — Responsabilité partagée

Provider:  physique, hyperviseur, network core
Client:    OS, apps, data, IAM, network virtuel

Mauvaise config IAM = JAMAIS la faute du fournisseur.

Vue d’ensemble 2 — IAM avec MFA obligatoire

aws iam create-user --user-name aminata
aws iam create-access-key --user-name aminata

# Policy least-privilege
aws iam put-user-policy --user-name aminata \
  --policy-name ReadOnlyS3 \
  --policy-document file://policy.json
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject","s3:ListBucket"],
    "Resource": ["arn:aws:s3:::itsc-docs","arn:aws:s3:::itsc-docs/*"],
    "Condition": {
      "Bool": { "aws:MultiFactorAuthPresent": "true" }
    }
  }]
}

Vue d’ensemble 3 — Rotation clés automatique

#!/usr/bin/env bash
# Tous les 90j
USER=aminata
NEW=$(aws iam create-access-key --user-name $USER --query 'AccessKey.AccessKeyId' --output text)
# Update app avec $NEW
# Puis:
aws iam update-access-key --user-name $USER --access-key-id ANCIEN --status Inactive

Vue d’ensemble 4 — KMS chiffrement

aws kms create-key --description "itsc-app-key"

aws s3api put-bucket-encryption --bucket itsc-docs \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "arn:aws:kms:us-east-1:123:key/abc"
      },
      "BucketKeyEnabled": true
    }]
  }'

Vue d’ensemble 5 — Azure KeyVault

az keyvault key create --vault-name itsc-kv --name app-key --kty RSA --size 4096

az storage account update --name itscstorage \
  --encryption-key-vault $VAULT_URI \
  --encryption-key-name app-key \
  --encryption-key-source Microsoft.Keyvault

Vue d’ensemble 6 — VPC avec subnets privés

aws ec2 create-vpc --cidr-block 10.0.0.0/16
aws ec2 create-subnet --vpc-id vpc-xxx --cidr-block 10.0.1.0/24 --availability-zone us-east-1a  # public
aws ec2 create-subnet --vpc-id vpc-xxx --cidr-block 10.0.10.0/24 --availability-zone us-east-1a # privé

aws ec2 create-security-group --group-name itsc-api-sg --vpc-id vpc-xxx
aws ec2 authorize-security-group-ingress --group-id sg-xxx \
  --protocol tcp --port 443 --cidr 0.0.0.0/0

Vue d’ensemble 7 — CloudTrail

aws cloudtrail create-trail --name itsc-audit \
  --s3-bucket-name itsc-audit-logs \
  --is-multi-region-trail \
  --include-global-service-events \
  --kms-key-id arn:aws:kms:us-east-1:123:key/abc

aws cloudtrail start-logging --name itsc-audit

Vue d’ensemble 8 — Azure Activity Log

az monitor diagnostic-settings create \
  --name itsc-audit-diag \
  --resource /subscriptions/$SUB/resourceGroups/rg-itsc \
  --logs '[{"category":"Administrative","enabled":true}]' \
  --workspace /subscriptions/$SUB/resourceGroups/rg-audit/providers/Microsoft.OperationalInsights/workspaces/itsc-logs

Vue d’ensemble 9 — Config Rules (guardrails)

Resources:
  Rule1:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: s3-bucket-public-read-prohibited
      Source: { Owner: AWS, SourceIdentifier: S3_BUCKET_PUBLIC_READ_PROHIBITED }
  Rule2:
    Properties:
      ConfigRuleName: encrypted-volumes
      Source: { Owner: AWS, SourceIdentifier: ENCRYPTED_VOLUMES }
  Rule3:
    Properties:
      ConfigRuleName: root-account-mfa-enabled
      Source: { Owner: AWS, SourceIdentifier: ROOT_ACCOUNT_MFA_ENABLED }

Vue d’ensemble 10 — Secrets Manager

aws secretsmanager create-secret --name prod/db/creds \
  --secret-string '{"username":"app","password":"'$(openssl rand -base64 32)'"}'

# Rotation auto
aws secretsmanager rotate-secret --secret-id prod/db/creds \
  --rotation-lambda-arn arn:aws:lambda:us-east-1:123:function:rotate-db \
  --rotation-rules AutomaticallyAfterDays=30

# Usage app
DB_SECRET=$(aws secretsmanager get-secret-value --secret-id prod/db/creds --query SecretString --output text)

Vue d’ensemble 11 — Zero Trust (Private Endpoints)

# VPC Endpoint S3 = pas d'Internet
aws ec2 create-vpc-endpoint --vpc-id vpc-xxx \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-xxx \
  --vpc-endpoint-type Gateway

# Azure: Private Endpoint
# GCP: Private Service Connect

Vue d’ensemble 12 — WAF managé

aws wafv2 create-web-acl --name itsc-waf --scope CLOUDFRONT \
  --region us-east-1 \
  --default-action Allow={} \
  --rules '[{
    "Name": "AWS-AWSManagedRulesCommonRuleSet",
    "Priority": 1,
    "OverrideAction": { "None": {} },
    "Statement": {
      "ManagedRuleGroupStatement": {
        "VendorName": "AWS",
        "Name": "AWSManagedRulesCommonRuleSet"
      }
    },
    "VisibilityConfig": {
      "SampledRequestsEnabled": true,
      "CloudWatchMetricsEnabled": true,
      "MetricName": "CommonRuleSet"
    }
  }]'

Checklist hebdo

✓ Aucun IAM sans MFA
✓ Aucune clé d'accès > 90 jours
✓ Tous buckets chiffrés, non publics
✓ CloudTrail/Activity Log actif global
✓ Aucun SG avec 0.0.0.0/0 sur 22/3389
✓ Alertes cost overrun configurées
✓ Secrets dans vault, jamais en IaC clair

Pour appliquer ce tutoriel sur un vrai serveur

Hostinger reste l’option la plus simple pour démarrer. Lien partenaire — votre achat soutient le blog sans surcoût.

Réserver un VPS Hostinger →

Lien d affiliation. Si vous achetez via ce lien, le blog reçoit une petite commission sans surcoût pour vous.

Étape 1 : poser le périmètre cloud avant toute configuration

Avant de toucher à une console Azure, AWS ou Google Cloud depuis Dakar ou Abidjan, listez ce qui doit être protégé : workloads de production, bases clients, secrets applicatifs, journaux d’audit. Sans cet inventaire, vos règles de sécurité tapent à côté. Notez chaque ressource dans un tableur partagé avec son propriétaire métier, sa classification (publique, interne, sensible) et sa zone géographique. Cette cartographie devient le socle de toutes les étapes suivantes.

Ouvrez ensuite trois onglets : Azure Portal, AWS Console, Google Cloud Console. Activez la facturation détaillée et les rapports de coûts. Une ressource oubliée coûte cher et reste souvent mal sécurisée. Indicateur que tout est en place : vous obtenez un rapport hebdomadaire par mail listant chaque service actif et son responsable.

Étape 2 : verrouiller les identités avec le moindre privilège

Le principe du moindre privilège est la première barrière. Sur Azure, créez des groupes Entra ID par fonction (devops-prod, data-readonly, finance-billing) puis attribuez des rôles RBAC précis comme Reader, Contributor scoped au resource group, Storage Blob Data Reader. Évitez Owner global. Sur AWS, utilisez IAM Identity Center connecté à votre annuaire, créez des permission sets adaptés et bannissez les access keys long terme. Sur Google Cloud, préférez les comptes de service avec Workload Identity Federation plutôt que des clés JSON téléchargées sur les postes.

az role assignment create \
  --assignee groupe-devops-prod@entreprise.sn \
  --role "Contributor" \
  --scope /subscriptions/SUB_ID/resourceGroups/rg-prod-dakar

Cette commande limite l’équipe devops au seul resource group de production basé à Dakar. La sortie attendue affiche un objet JSON avec principalId et roleDefinitionName. Si vous voyez Owner ou un scope racine, recommencez : c’est trop large.

Étape 3 : imposer la MFA et les clés matérielles

Activez la MFA sur tous les comptes humains, sans exception. Sur Azure, configurez Conditional Access pour exiger une authentification forte depuis l’extérieur du réseau bureau. Sur AWS, branchez des clés FIDO2 (YubiKey 5C ou équivalent) sur les comptes root et les rôles privilégiés ; les SMS sont à proscrire. Sur Google Cloud, activez l’Advanced Protection Program pour les administrateurs de l’organisation.

Indicateur que tout est en place : un test de connexion avec mot de passe seul échoue, et un audit IAM montre 100 % de comptes humains avec MFA matérielle. Si un commercial à Abidjan se plaint de la friction, expliquez qu’une clé physique évite le coût d’une fuite client.

Étape 4 : chiffrer les données au repos et en transit

Le chiffrement par défaut est activé partout, mais la maîtrise des clés est ce qui distingue un setup sérieux. Sur Azure, créez un Key Vault par environnement et utilisez Customer-Managed Keys pour Storage, SQL Database et Disk Encryption. Sur AWS, KMS avec des CMK par projet, rotation automatique annuelle activée. Sur GCP, Cloud KMS avec rotation et CMEK pour BigQuery, Cloud Storage et Compute Engine.

aws kms create-key \
  --description "CMK production paiements Dakar" \
  --key-usage ENCRYPT_DECRYPT \
  --enable-key-rotation

Cette commande crée une clé dédiée au domaine paiements. La sortie renvoie un KeyId à noter dans votre coffre de secrets. Référencez ensuite cette clé sur chaque bucket S3 et chaque base RDS du périmètre. Côté transit, imposez TLS 1.2 minimum partout, idéalement TLS 1.3, et rejetez les anciens algorithmes.

Étape 5 : isoler les réseaux et bloquer le trafic latéral

Sur les trois clouds, partez du principe deny-all par défaut. Azure : un Virtual Network par environnement, des subnets dédiés (web, app, data), des NSG restrictifs, et Azure Firewall Premium ou un NVA pour la sortie internet. AWS : VPC séparés prod et non-prod, security groups stateful avec règles minimales, AWS Network Firewall ou inspection via Gateway Load Balancer. GCP : VPC partagé, firewall rules avec target tags, Cloud NAT pour la sortie sans IP publique exposée.

Activez les flow logs partout (NSG flow logs, VPC Flow Logs, GCP VPC Flow Logs) et envoyez-les vers un SIEM. Le signal : vous voyez en moins de 5 minutes qu’un pod a tenté un appel sortant suspect vers une IP inconnue.

Étape 6 : centraliser logs, alertes et détection

Une équipe basée à Cotonou ne peut pas surveiller trois consoles séparées. Centralisez. Azure : Microsoft Sentinel sur un Log Analytics Workspace dédié, connecteurs Defender for Cloud et Entra ID activés. AWS : Security Hub, GuardDuty, Detective et CloudTrail multi-région agrégés sur un compte audit dédié. GCP : Security Command Center Premium, audit logs et VPC Service Controls.

Définissez des alertes ciblées : création de clé d’accès, désactivation de log, élévation de privilèges, exfiltration anormale (>1 Go en une heure). Branchez-les sur un canal Teams ou Slack dédié SOC. Le marqueur de succès : votre tableau de bord SOC affiche moins de 10 alertes critiques par semaine, toutes traitées sous 24 h.

Étape 7 : automatiser la conformité et la posture

Les contrôles manuels ne tiennent pas. Sur Azure, déployez Azure Policy avec les initiatives CIS Microsoft Azure Foundations Benchmark v2.1 et Azure Security Benchmark. Sur AWS, AWS Config avec les conformance packs CIS AWS Foundations 3.0 et NIST 800-53. Sur GCP, Security Health Analytics et les Posture Management policies. Programmez des scans hebdomadaires et exportez les écarts vers Jira ou Linear pour suivi.

gcloud scc settings services enable \
  --service=security-health-analytics \
  --organization=ORG_ID

La sortie confirme l’activation. Au bout d’une semaine, ouvrez Security Command Center : vous voyez chaque ressource non conforme avec le contrôle CIS associé. Pour explorer plus loin sur la base WordPress qui consomme ces services, voyez notre série sécurité et le tutoriel tutoriels du blog.

Étape 8 : tester la résilience et préparer la réponse à incident

Une posture qui n’a jamais été testée n’existe pas. Programmez deux fois par an un exercice red team interne ou un pentest externe. Validez vos sauvegardes par des restaurations réelles : un dump SQL chiffré ne sert à rien si la clé KMS a été supprimée. Documentez un runbook d’incident court : qui isole le compte compromis, qui coupe l’accès réseau, qui prévient le DPO. Stockez-le hors du cloud audité (Notion, Confluence on-prem, ou simple PDF chiffré sur un drive séparé).

Le signal final : lors du dernier exercice, l’équipe a contenu un compte AWS compromis simulé en moins de 15 minutes, sans coupure du service client à Lomé. Vous itérez ensuite chaque trimestre pour rester aligné avec les évolutions des trois fournisseurs.

Étape 9 : durcir les services managés stratégiques

Les bases de données et les stockages objet concentrent la valeur. Sur Azure, activez Defender for Storage et Defender for SQL, désactivez l’accès réseau public sur les comptes Storage et SQL Database, exigez des Private Endpoints. Sur AWS, S3 Block Public Access au niveau du compte, RDS dans des subnets privés avec Performance Insights et IAM database authentication, DynamoDB avec Point-in-Time Recovery. Sur GCP, Cloud Storage avec Uniform Bucket-Level Access et VPC Service Controls, Cloud SQL avec connexions privées via Cloud SQL Auth Proxy.

Auditez chaque trimestre les buckets et conteneurs publics depuis votre SIEM. Une fuite de données client à Yopougon part presque toujours d’un bucket S3 mal configuré ou d’un Storage Account ouvert par erreur lors d’un test rapide. La preuve que ça tourne : zéro ressource de stockage avec accès public dans le rapport hebdomadaire, hors CDN documentés.

Étape 10 : maîtriser les coûts et la dette de sécurité

Une console qui dérape financièrement finit par voir ses contrôles désactivés pour économiser. Posez des budgets par projet sur les trois clouds, avec alertes à 50, 80 et 100 %. Désactivez systématiquement les régions inutiles via Azure Management Groups, AWS Service Control Policies et GCP Organization Policies (constraints/gcp.resourceLocations). Cela ferme aussi des angles d’attaque géographiques.

Tenez un registre de la dette de sécurité : chaque exception (port ouvert temporaire, rôle trop large, compte de service partagé) reçoit une date d’expiration et un ticket. Sans cela, les exceptions deviennent permanentes. Le signal final : votre backlog sécurité ne contient pas plus de 20 % de tickets ouverts depuis plus de 30 jours, et le coût mensuel des trois clouds reste prévisible à plus ou moins 10 %. Vous pouvez alors présenter sereinement une posture cloud sécurisée à votre direction et à vos clients basés à Bamako, Cotonou ou Plateau.

Annexe : matrice de mapping des contrôles entre les trois clouds

Pour les équipes mixtes Dakar-Abidjan qui jonglent avec Azure et AWS sans tout doublonner, gardez en tête ces équivalences pratiques. Identités : Entra ID = IAM Identity Center = Cloud Identity. Politiques : Azure Policy = AWS Config Rules + SCP = Organization Policies. Détection : Defender for Cloud = Security Hub + GuardDuty = Security Command Center. Secrets : Key Vault = Secrets Manager = Secret Manager. Réseau privé : Private Endpoint = VPC Endpoint = Private Service Connect.

Construisez un seul référentiel de contrôles internes (par exemple ISC-SEC-001 « MFA matérielle obligatoire ») et mappez-le vers le service natif de chaque cloud. Vos audits gagnent en clarté et vos nouveaux ingénieurs montent en compétence plus vite. Le signal final : un nouvel arrivant à Sicap Liberté implémente un contrôle sur les trois clouds en moins d’une demi-journée à partir de votre référentiel.

Partager
#sécurité

Articles Similaires