AWS security pour débutant : guide pratique 2026

La sécurité AWS pour débutant repose sur cinq blocs fondamentaux à maîtriser avant toute autre exploration : le modèle de responsabilité partagée (AWS sécurise l'infrastructure, le client sécurise ce qu'il déploie), l'IAM (Identity and Access Management avec principe du moindre privilège), le compte root (verrouillé derrière MFA hardware, jamais utilisé au quotidien), les réseaux VPC (Security Groups stateful + NACL stateless), et les services de détection gratuits ou low-cost (GuardDuty, Security Hub, CloudTrail, Config, IAM Access Analyzer). Ces cinq blocs couvrent 80 % des incidents AWS évitables en 2026. Les briques avancées — Service Control Policies (SCPs), Control Tower, AWS Organizations multi-comptes, KMS customer-managed keys, IMDSv2, private endpoints VPC — viennent dans un second temps, une fois le socle en place. Selon les observatoires 2025, plus de 70 % des organisations ont au moins un role IAM avec AdministratorAccess attaché sans justification, et selon le SANS report 2024, moins de 60 secondes s'écoulent entre le push d'une AWS access key sur GitHub public et la première tentative d'abuse par des scanners malveillants. Cet article explique les concepts clés AWS security pour un débutant, détaille les services à activer dans les 30 premiers jours, documente les 10 erreurs récurrentes de débutant, et fournit une checklist de sécurisation opérationnelle en 14 jours.

1. Le modèle de responsabilité partagée : ce que tu fais vs ce qu'AWS fait

1.1 La règle fondatrice

Depuis 2013, AWS formalise son Shared Responsibility Model : la sécurité est partagée entre AWS et le client, avec une frontière qui se déplace selon le service utilisé.

La règle à retenir : la configuration du service, l'accès et la donnée restent toujours ta responsabilité. AWS ne te protège pas d'un bucket S3 que tu as rendu public par erreur, d'une clé IAM que tu as pushée sur GitHub, ou d'un security group ouvert à 0.0.0.0/0.

1.2 Analogie pratique

Louer un appartement : le propriétaire (AWS) assure la solidité de l'immeuble, l'étanchéité du toit, le système électrique. Toi (le client), tu fermes ta porte à clé, tu choisis qui tu laisses entrer, tu installes ou non une alarme.

Si tu laisses ta porte grande ouverte et que tu te fais voler, le propriétaire n'est pas responsable — même si l'immeuble est le plus sûr du quartier.

2. Le compte root : la première chose à verrouiller

2.1 Pourquoi le root est dangereux

Le compte root AWS a un accès illimité : il peut modifier la facturation, fermer le compte, créer ou supprimer n'importe quelle ressource, contourner toutes les IAM policies. Contrairement aux users IAM classiques, le root ne peut pas être restreint par une politique IAM.

Conséquence : le root est la cible #1 en cas de compromission. Un attaquant qui obtient les credentials root peut tout faire — y compris te mettre à la porte de ton propre compte.

2.2 Les 6 actions obligatoires dans les 2 premières heures

1. Activer MFA HARDWARE sur le compte root
   - YubiKey 5 Series, Google Titan, ou equivalent FIDO2/WebAuthn
   - PAS de MFA virtuelle (TOTP sur telephone) : phishable
   - Stocker la cle physiquement en coffre
 
2. Creer un premier user IAM avec AdministratorAccess
   - Nom clair : "admin-prenom" ou "breakglass-1"
   - MFA egalement activee
   - Activer AWS CLI via access keys ou via AWS IAM Identity Center (ex-SSO)
 
3. Ne plus utiliser le root au quotidien
   - Sauf operations qui l'exigent explicitement (changement plan support,
     cloture compte, certains cas billing)
 
4. Activer CloudTrail sur TOUTES les regions
   - Log vers S3 chiffre (KMS) en region differente du compte
   - Activation Log File Validation
 
5. Activer GuardDuty dans les regions actives
   - Detection crypto mining, exfiltration credentials, reconnaissance
   - Cout typique : 20-50 EUR/mois en prod moyenne
 
6. Configurer une alerte budget AWS
   - Seuil 50 EUR/mois pour detecter un usage anormal
   - Notification email + SMS
   - Crypto mining via credentials voles peut generer 1000-5000 EUR/jour

3. IAM : la porte d'entrée de tout

3.1 Les 4 concepts IAM à maîtriser

Règle pratique 2026 : privilégier les roles IAM aux users IAM pour toute application. Un user IAM a des credentials longue durée qui peuvent fuiter ; un role IAM fournit des credentials temporaires (TTL 15 min à 12 h) via STS (Security Token Service), renouvelés automatiquement. Depuis 2022, AWS recommande même IAM Identity Center (ex-AWS SSO) pour les humains, et les roles pour les applications — zéro user IAM humain dans l'idéal.

3.2 Principe du moindre privilège (PoLP)

Exemple minimal : un role applicatif backend qui doit lire un bucket S3 précis et écrire dans une table DynamoDB précise.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ReadFromSpecificBucket",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::mon-bucket-prod",
                "arn:aws:s3:::mon-bucket-prod/*"
            ]
        },
        {
            "Sid": "WriteToSpecificTable",
            "Effect": "Allow",
            "Action": [
                "dynamodb:PutItem",
                "dynamodb:UpdateItem",
                "dynamodb:GetItem"
            ],
            "Resource": "arn:aws:dynamodb:eu-west-3:123456789012:table/Orders"
        }
    ]
}

Points clés :

• Resource nommé explicitement par ARN, jamais "*".
• Action limité au minimum (pas s3:*, mais s3:GetObject).
• Pas de NotAction ou NotResource (anti-pattern fréquent, inverse dangereux).
• Ajouter des Condition quand pertinent (restriction par IP, par tag, par MFA présente).

3.3 Les outils natifs à connaître

• IAM Access Analyzer (gratuit) : scan automatique des ressources (S3, KMS, IAM roles, Secrets Manager, Lambda) accessibles depuis l'extérieur de l'organisation. À activer dès jour 1.
• IAM Access Advisor : rapport par service des dates de dernier usage, permet de détecter les permissions jamais utilisées à retirer.
• IAM Policy Simulator : tester une policy avant déploiement contre des scénarios précis.
• CloudSplaining (open source, Salesforce) : audit des policies trop permissives, priorisation des risques.

4. VPC et réseau : la défense périmétrique

4.1 Les briques de base

Règle pratique : toutes les ressources sensibles (bases de données, workloads applicatifs) en private subnets. Seuls load balancers, bastion (éventuellement), et NAT Gateway en public subnets. Les accès admin internes via AWS Systems Manager Session Manager (pas de bastion SSH exposé en 2026).

4.2 Security Groups : 3 erreurs à ne jamais commettre

1. 0.0.0.0/0 sur port 22, 3389, 3306, 5432, 6379, 27017, 9200, etc. Ouvrir un SSH, RDP, MySQL, PostgreSQL, Redis, MongoDB ou Elasticsearch à tout l'internet est la porte ouverte numéro 1. Scanner Shodan, ZMap détectent ces hosts en quelques minutes.
2. Security Group par défaut modifié. Ne jamais toucher le Security Group default du VPC. Créer des Security Groups nommés par fonction (sg-web-public, sg-app-private, sg-db-internal).
3. Permissive egress 0.0.0.0/0. Par défaut AWS autorise tout trafic sortant. Pour une app sensible, restreindre l'egress aux IPs/domaines nécessaires via security group ou via VPC endpoints (PrivateLink, Gateway Endpoints).

5. Les 8 services AWS de sécurité à connaître

Services natifs à activer dans les 30 premiers jours. Coûts indicatifs pour un compte moyen (100 ressources).

5.1 Le quatuor de base : CloudTrail + Config + GuardDuty + Security Hub

Ces 4 services fonctionnent ensemble comme un SIEM minimal AWS-native :

• CloudTrail collecte tous les appels API (qui a fait quoi, quand).
• Config suit les modifications de configuration des ressources dans le temps.
• GuardDuty détecte les anomalies (activity suspecte, crypto mining, reconnaissance).
• Security Hub agrège les findings et évalue la posture contre CIS Benchmarks AWS 1.5+, PCI-DSS 4.0, NIST SP 800-53 Rev 5, AWS Foundational Security Best Practices.

Activation recommandée en 2 heures dès la création du compte production.

5.2 KMS : chiffrement à comprendre dès le jour 1

Pour un débutant : activer le chiffrement par défaut partout (S3, EBS, RDS), même avec clés AWS-managed. Passer aux CMK customer-managed uniquement pour les données soumises à conformité (PCI-DSS, HDS, RGPD data sensibles) ou cross-account sharing.

6. Les 10 erreurs classiques de débutant

Erreurs récurrentes qui causent 80 % des incidents AWS évitables. Checklist anti-erreur.

6.1 Focus sur l'erreur #5 : fuite de credentials

Le scénario le plus fréquent et le plus coûteux :

1. Développeur stocke ses credentials AWS dans un fichier config.py ou .env pour tester.
2. Il pousse par erreur sur un repo GitHub public (ou un fork public de son projet).
3. Moins de 60 secondes plus tard (rapport SANS 2024), un scanner malveillant détecte la clé.
4. L'attaquant lance des instances EC2 GPU (p3, p4, g5) en crypto mining dans toutes les régions.
5. Facture AWS peut monter à 10 000 à 50 000 € en 24 heures avant détection.

Défense en couches :

• Scan de secrets en pre-commit et CI (voir la ressource scan de secrets dans les pipelines).
• GitHub Secret Scanning + Push Protection activé (AWS est partenaire, blocage automatique).
• AWS Budget Alert à 50 € pour détecter l'abuse.
• IAM Access Analyzer + GuardDuty pour détecter l'activité anormale.
• Jamais de user IAM avec access keys longue durée pour un développeur — préférer IAM Identity Center (SSO) avec session temporaire.

7. Checklist de sécurisation en 14 jours

Plan d'action concret, implémentable par un débutant sur un compte AWS neuf ou en démarrage.

7.1 Jour 1-2 : Verrouillage root et IAM de base

• MFA hardware activée sur root (YubiKey).
• Mot de passe root changé avec gestionnaire type 1Password/Bitwarden.
• Premier user IAM admin créé + MFA.
• Root account stocké en coffre, n'y plus toucher.
• CloudTrail activé toutes régions → S3 chiffré.
• GuardDuty activé régions actives.
• Budget alert 50 €/mois configuré.
• IAM Access Analyzer activé (gratuit).

7.2 Jour 3-5 : Durcissement IAM

• Audit users existants : désactiver ceux non nécessaires.
• Migrer vers IAM Identity Center (ex-AWS SSO) pour humains.
• Supprimer access keys longue durée, remplacer par roles + STS.
• Activer Password Policy IAM (14 caractères minimum, rotation 90j, 5 derniers historique).
• Revue des roles : supprimer AdministratorAccess non justifiés.
• Configurer permissions boundaries sur les roles sensibles.

7.3 Jour 6-8 : Network et données

• Supprimer VPC default non utilisé ou le documenter.
• Créer VPC nommé avec subnets public/private/isolated.
• Security Groups par fonction, nommés, documentés.
• Vérifier qu'aucun SG n'a 0.0.0.0/0 sur ports sensibles (22, 3389, DB ports).
• Activer VPC Flow Logs vers CloudWatch ou S3.
• Block Public Access S3 activé account-wide.
• Chiffrement par défaut activé sur tous les buckets S3 et volumes EBS.

7.4 Jour 9-11 : Détection et conformité

• Security Hub activé avec benchmark AWS Foundational Security Best Practices.
• AWS Config activé + règles managed (CIS AWS Foundations Benchmark v3.0).
• Inspector activé pour scan EC2 + ECR.
• CloudWatch alarms configurées sur événements critiques : console login from unusual location, root usage, IAM policy change, security group change 0.0.0.0/0, CloudTrail disabled attempt.
• Runbook incident rédigé (qui appeler, quelles premières actions).

7.5 Jour 12-14 : Hardening avancé

• IMDSv2 enforced sur tous les EC2 (HttpTokens: required).
• SSM Session Manager configuré pour admin sans bastion SSH.
• Audit des access keys non utilisées > 90 jours, désactivation.
• Multi-compte : activation AWS Organizations + séparation prod / staging / dev.
• SCPs de base appliquées (deny CloudTrail deletion, deny GuardDuty disable, restrict regions).
• Documentation de l'architecture sécurité pour l'équipe.

8. Pour aller plus loin : AWS Well-Architected et certifications

8.1 AWS Well-Architected Framework - Security Pillar

AWS Well-Architected Framework est la référence officielle AWS, gratuit, mis à jour régulièrement. 6 piliers : Security, Reliability, Performance Efficiency, Cost Optimization, Operational Excellence, Sustainability. Le Security Pillar détaille :

• Identity and access management (foundations).
• Detection.
• Infrastructure protection.
• Data protection.
• Incident response.
• Application security.

Lecture recommandée en entier (100-150 pages), plus le tool AWS Well-Architected Tool (gratuit) qui permet d'auto-évaluer un workload contre les bonnes pratiques.

8.2 Certifications AWS pour monter en compétence

Parcours certifications sécurité 2026 :

Parcours recommandé pour un débutant qui vise cloud security : Cloud Practitioner (1 mois) → Solutions Architect Associate (3-4 mois) → Security Specialty (3-4 mois).

8.3 Ressources complémentaires gratuites

• AWS Security Workshops (workshops.aws) : labs hands-on gratuits avec compte AWS personnel.
• AWS Ramp-Up Guide Security : PDF officiel structurant le parcours sécurité.
• AWS Prescriptive Guidance : guides opérationnels par cas d'usage.
• AWS re:Inforce sessions YouTube (conférence annuelle sécurité).
• Labs CTF cloud : CloudGoat (Rhino Security Labs), flaws.cloud, flaws2.cloud.

Pour structurer l'apprentissage cloud security sur 12-18 mois en parcours complet, la ressource roadmap cloud security propose un plan en 6 phases couvrant AWS, Azure, GCP, Kubernetes, CNAPP, compliance. Le rôle opérationnel d'un ingénieur DevSecOps au quotidien est détaillé dans que fait un ingénieur DevSecOps.

Points clés à retenir

• AWS Security = shared responsibility : AWS sécurise l'infra, toi tu sécurises data, IAM, config, accès.
• Root account = plus dangereux service : MFA hardware + ne plus s'en servir + alerte sur usage.
• IAM least privilege non négociable : jamais Resource: "*", jamais AdministratorAccess sur role applicatif.
• 8 services sécurité de base : CloudTrail, GuardDuty, Security Hub, Config, IAM Access Analyzer, Inspector, Macie, KMS.
• SCPs + Control Tower = défense structurelle en multi-comptes, à partir du moment où tu as 2+ comptes.
• IMDSv2 enforced depuis octobre 2024 sur nouveaux EC2 — vérifier les parcs existants (leçon Capital One 2019).
• Fuite de credentials = scénario #1 (< 60 s entre push public et abuse) : scan de secrets + push protection obligatoires.
• 10 erreurs débutant : root quotidien, MFA virtuelle, S3 public, SG 0.0.0.0/0, credentials sur GitHub, IAM *, CloudTrail off, GuardDuty off, IMDSv1, VPC default.
• Well-Architected Security Pillar est la référence gratuite officielle à lire en entier.
• Checklist 14 jours pour sécuriser un compte neuf de bout en bout avec les services natifs.