Bonnes pratiques de sécurité AWS pour les entreprises : 16 contrôles

La sécurité AWS en entreprise est souvent insuffisante car l'ensemble complet de contrôles représente un coût réel et récurrent. Les RSSI, les responsables du cloud et les équipes FinOps savent parfois quels services activer, mais limitent tout de même la surveillance, la journalisation, les sauvegardes ou les contrôles réseau aux comptes de production ou à une seule région lorsque le budget ne couvre pas l'ensemble du parc.

Le modèle de responsabilité partagée d'AWS signifie qu'AWS protège l'infrastructure cloud sous-jacente, tandis que votre organisation protège ses identités, ses charges de travail, ses configurations et ses données. Ce guide couvre des domaines de programme mesurables, notamment les risques liés aux identités tels que les clés d'accès, la gouvernance, la protection des données, le chiffrement au repos, la détection, l'infrastructure, la résilience et la réponse. Ces bonnes pratiques de sécurité AWS favorisent des contrôles de sécurité plus solides et une posture de sécurité mesurable sur l'ensemble du parc. Le guide complète le pilier de sécurité du cadre AWS Well-Architected en y intégrant des considérations de mise en œuvre au niveau du compte et de coûts. Spendbase collabore avec les entreprises sur la réduction des coûts AWS et les examens de la posture de sécurité, y compris les moyens de réduire votre facture AWS afin que des contrôles plus stricts soient plus faciles à maintenir. Commençons par les schémas de défaillance qui exposent le plus souvent les environnements d'entreprise.

Principaux enseignements

• La sécurité AWS en entreprise dépend d'une couverture complète du parc à travers les comptes, les régions, les charges de travail et les copies de sauvegarde, et pas seulement les environnements de production.
• Établissez une zone de réception multi-comptes, fédérez l'accès humain, éliminez les clés d'accès à longue durée de vie, appliquez le principe du moindre privilège et protégez les identifiants racine avec une MFA résistante au phishing.
• Centralisez la journalisation infalsifiable, la détection des menaces, la gestion des vulnérabilités, la classification des données, le chiffrement, la gestion des secrets et les contrôles réseau préventifs.
• Traitez la sécurité comme un programme opérationnel avec des propriétaires désignés, des SLA mesurables, des examens de conformité continus, des exercices de réponse aux incidents et des processus de récupération des sauvegardes testés.
• Modélisez à la fois les frais de service AWS et les coûts d'exploitation, puis déployez les contrôles par phases afin qu'une couverture plus solide reste viable financièrement.
• Vous pouvez faire défiler la page jusqu'à notre auto-évaluation à la fin de cet article pour savoir comment vous situer dès maintenant.

Comment la sécurité AWS des entreprises échoue réellement

La sécurité AWS des entreprises échoue généralement aux frontières entre les comptes, les équipes et les processus opérationnels. Un rôle IAM trop large permet un mouvement latéral, un instantané public expose des données sensibles, ou une région non surveillée donne à un attaquant le temps d'agir sans être remarqué.

Le Le modèle de responsabilité partagée d'AWS définit quelles protections AWS fournit pour l'infrastructure cloud et lesquelles votre organisation doit exploiter. Votre organisation reste responsable des identités, des configurations, des données, des charges de travail et de la réponse. Les bonnes pratiques de sécurité AWS efficaces couvrent donc la gestion des identités et des accès, la détection, la protection de l'infrastructure, la protection des données, la réponse aux incidents et la gouvernance. Le Un cadre bien conçu pour AWS, y compris son pilier de sécurité, fournit un cadre utile. Les contrôles ci-dessous déterminent si ces orientations améliorent concrètement votre posture de sécurité.

Configurez une zone de réception multi-comptes avant que la complexité d'AWS ne devienne incontrôlable

Ce que c'est : Séparez les outils de sécurité, l'archivage des journaux, le réseau, la production, la non-production, les bacs à sable et les charges de travail suspendues dans des comptes distincts. Cette structure clarifie également la responsabilité de la gestion des identités et des accès.

Comment procéder : Créez une structure d'UO sous une seule organisation AWS, puis migrez les charges de travail compte par compte. Commencez par la non-production afin que les équipes puissent résoudre les problèmes de compte, de réseau et de déploiement avant de déplacer les systèmes critiques.

Comment y parvenir : Utilisez AWS Organizations et AWS Control Tower pour les garde-fous, Account Factory ou Account Factory pour Terraform (AFT) pour le provisionnement reproductible, et AWS RAM pour partager les réseaux et services gérés de manière centralisée.

Ce que cela évite : La compromission d'un identifiant de développement qui atteint la production, les conflits IAM entre équipes et une concentration excessive de rôles et de ressources dans un seul compte.

Impact pour l'entreprise : Des comptes séparés réduisent la zone d'impact, simplifient la refacturation, limitent la portée des audits et accélèrent l'isolation des incidents. La contrepartie réside dans un réel travail de migration et de provisionnement, nécessitant souvent plusieurs semaines d'ingénierie de plateforme.

Ce que c'est : Supprimez les identifiants racine permanents des comptes membres et exigez une authentification multifacteur résistante au phishing pour les administrateurs humains.

Comment procéder : Utilisez une gestion centralisée des accès racine, conservez un accès étroitement contrôlé pour l'utilisateur racine dans le compte de gestion, et stockez les identifiants de secours ainsi que les clés matérielles FIDO2 dans un endroit sécurisé. Exigez un double contrôle pour le retrait et enregistrez chaque utilisation.

Comment y parvenir : Combinez AWS Organizations, la gestion des accès racine IAM, des clés de sécurité ou clés d'accès FIDO2, et les alertes AWS CloudTrail pour les connexions racine et les actions racine privilégiées.

Ce que cela évite : La prise de contrôle d'un compte via la fuite d'un identifiant racine, y compris les tentatives de désactivation de la journalisation, de suppression d'utilisateurs ou de destruction des contrôles de sécurité.

Impact pour l'entreprise : Cela permet une réduction majeure des risques avec peu de coûts de service récurrents. Vos principales dépenses concernent les clés matérielles, le stockage sécurisé, les tests et la gestion des processus.

Fédérez l'accès humain et éliminez les clés d'accès à longue durée de vie

Ce que c'est : Les employés s'authentifient via le fournisseur d'identité de l'entreprise et reçoivent des sessions AWS de courte durée. Les applications assument des rôles au lieu de stocker des clés d'accès statiques.

Comment procéder : Connectez IAM Identity Center à Microsoft Entra ID, Okta ou Ping. Associez les groupes à des ensembles d'autorisations, automatisez les changements liés aux arrivées, départs et mobilités, recensez les utilisateurs et les clés d'accès IAM, attribuez-en la propriété et supprimez les clés d'accès inutilisées.

Comment y parvenir : Utilisez IAM Identity Center, les rapports d'identifiants, l'OIDC pour la CI/CD, les profils d'instance EC2 et EKS Pod Identity ou IRSA pour les charges de travail Kubernetes.

Ce que cela évite : La fuite de clés via des référentiels, des ordinateurs portables, des systèmes de build, des journaux et des comptes d'anciens employés. L'élimination des clés d'accès à longue durée de vie limite également la valeur des identifiants volés.

Impact pour l'entreprise : Les examens d'accès deviennent plus faciles et les changements concernant les employés s'intègrent dans les processus d'identité existants. Les scripts et applications qui dépendent de clés d'accès statiques nécessitent une planification de migration et des tests.

Appliquez le principe du moindre privilège avec des politiques adaptées à l'échelle des équipes

Ce que c'est : Appliquez le principe du moindre privilège, en accordant à chaque entité uniquement l'accès requis pour sa fonction. Les contrôles à l'échelle de l'organisation doivent également empêcher les politiques IAM individuelles de les contourner.

Comment procéder : Commencez par des SCP en mode audit, examinez les autorisations inutilisées, générez des politiques à partir de l'activité CloudTrail et ajoutez des vérifications de politiques aux pipelines d'infrastructure. Utilisez des demandes d'accès en libre-service afin que les développeurs puissent obtenir des autorisations approuvées sans exceptions informelles.

Comment y parvenir : Combinez les politiques de contrôle des services (SCP), les politiques de contrôle des ressources (RCP), les limites d'autorisations et IAM Access Analyzer pour détecter les accès inutilisés, les accès externes et valider les politiques personnalisées.

Ce que cela évite : L'élévation de privilèges et le mouvement latéral après qu'un attaquant a compromis une identité à faibles privilèges.

Impact pour l'entreprise : Le moindre privilège réduit les frictions pour les développeurs lorsque les demandes sont prévisibles et documentées. Il nécessite une attribution claire des politiques, du temps d'examen et une application progressive plutôt qu'un blocage soudain et généralisé.

Établissez un périmètre de données AWS et contrôlez le trafic sortant

Ce que c'est : Limitez l'accès aux identités, ressources, réseaux approuvés et destinations de confiance. Cela constitue un élément central de la sécurité réseau.

Comment procéder : Associez les SCP à des politiques de contrôle des ressources et des politiques de point de terminaison d'un VPC. Acheminez le trafic sortant via des chemins inspectés, définissez les domaines approuvés et limitez l'accès NAT plutôt que de permettre à chaque sous-réseau privé d'accéder à Internet.

Comment y parvenir : Utilisez des SCP, des RCP, des politiques de point de terminaison de VPC, AWS Network Firewall, le filtrage de domaine et un routage NAT restrictif.

Ce que cela évite : L'exfiltration vers des compartiments contrôlés par un attaquant, les accès inter-comptes non autorisés et l'utilisation abusive d'identifiants valides depuis des emplacements non approuvés.

Impact pour l'entreprise : Un périmètre de données réduit les dommages qu'une identité compromise peut causer. Testez les politiques par étapes car des restrictions trop larges peuvent interrompre les API des fournisseurs, les dépôts de correctifs et les intégrations légitimes.

Chiffrez les données partout et gérez correctement les clés KMS

Ce que c'est : Chiffrez les données au repos et en transit sur EBS, S3, RDS, Aurora et les instantanés (snapshots) sensibles. Il s'agit d'un contrôle fondamental de la protection des données.

Comment procéder : Activez les valeurs par défaut du chiffrement EBS au niveau du compte, exigez le chiffrement côté serveur pour les compartiments Amazon S3 et sélectionnez le chiffrement lors de la création de ressources RDS ou Aurora. Utilisez des clés KMS gérées par le client pour les données réglementées, des politiques de clés ciblées et la rotation automatique.

Comment y parvenir : Utilisez AWS Key Management Service (KMS), les certificats ACM, les politiques S3 aws:SecureTransport et CloudHSM lorsque des exigences d'assurance plus élevées ou des réglementations spécifiques s'appliquent.

Ce que cela évite : Exposition due à des instantanés volés, des AMI copiées, des volumes abandonnés et du trafic intercepté.

Impact pour l'entreprise : Le chiffrement prend en charge les exigences réglementaires courantes, mais les requêtes KMS à volume élevé peuvent augmenter les coûts. La mise en cache des clés de données peut réduire les appels API répétés là où la charge de travail le permet.

Centralisez la gestion des secrets et effectuez la rotation automatique des identifiants

Ce que c'est : Conservez les mots de passe de base de données, les jetons d'API et les identifiants d'application hors du code source, des images, des AMI, des journaux et des fichiers de build.

Comment procéder : Analysez les dépôts et les images de conteneurs, supprimez les secrets exposés, migrez-les vers un stockage géré et accordez l'accès aux applications via des rôles IAM. Activez la rotation pour les identifiants de base de données et autres secrets pris en charge.

Comment y parvenir : Utilisez AWS Secrets Manager pour les secrets sensibles et SSM Parameter Store pour les configurations à sensibilité moindre.

Ce que cela évite : Vol d'identifiants à partir de l'historique Git, des couches d'images, des journaux, des fichiers de support et des artefacts de build.

Impact pour l'entreprise : La rotation automatisée élimine une source courante de dette technique. Les équipes doivent tout de même mettre à jour les applications qui attendent des identifiants dans des fichiers ou des variables d'environnement statiques.

Segmentez les réseaux et privilégiez la connectivité privée

Ce que c'est : Placez les ressources de calcul et les bases de données dans des sous-réseaux privés, n'exposez que des équilibreurs de charge contrôlés et séparez les systèmes par niveau et par sensibilité au sein d'un Virtual Private Cloud (VPC).

Comment procéder : Remplacez les règles CIDR larges par des références de groupes de sécurité étroites. Utilisez des points de terminaison d'interface et de passerelle VPC pour les services AWS, Transit Gateway pour le routage centralisé et PrivateLink pour les connexions partenaires approuvées.

Comment y parvenir : Combinez des niveaux de sous-réseau publics, privés et isolés avec des groupes de sécurité, des listes de contrôle d'accès qui les complètent, Transit Gateway, PrivateLink et AWS Network Firewall.

Ce que cela évite : Accès direct à Internet pour les bases de données et les services internes, ainsi que mouvements est-ouest après un compromis initial.

Impact pour l'entreprise : La connectivité privée réduit la surface d'attaque, mais les points de terminaison d'interface, Transit Gateway et le traitement des données ajoutent des frais récurrents. Incluez ces coûts dans les normes de la plateforme avant d'appliquer la conception.

Centralisez la journalisation et rendez les enregistrements d'audit inviolables

Ce que c'est : Envoyez les enregistrements d'audit de l'ensemble de l'organisation vers un compte Log Archive dédié que les comptes de charge de travail ne peuvent pas modifier. Les preuves immuables protègent également l'ensemble plus large des contrôles de sécurité.

Comment procéder : Configurez un journal d'audit AWS CloudTrail multirégional pour l'ensemble de l'organisation. Ajoutez les événements de données sensibles S3 et Lambda, les journaux de flux VPC, l'enregistrement AWS Config à l'échelle de l'organisation et une rétention CloudWatch définie. Appliquez S3 Object Lock en mode conformité.

Ce que cela évite : Des attaquants supprimant les preuves après un compromis ou laissant les enquêteurs sans historique d'activité fiable.

Impact pour l'entreprise : Les journaux immuables améliorent l'analyse forensique, les preuves d'audit et l'analyse des failles. La journalisation étant l'un des coûts de sécurité récurrents les plus importants, conservez les données récentes dans un stockage à chaud et archivez les enregistrements plus anciens.

Exécutez une détection continue des menaces avec des opérations de sécurité unifiées

Ce que c'est : Détectez les activités suspectes sur l'ensemble des comptes et des régions, puis acheminez les résultats vers un processus de réponse unique. La détection centralisée des menaces permet d'identifier plus facilement les lacunes de couverture.

Comment procéder : Activez Amazon GuardDuty à l'échelle de l'organisation via un administrateur délégué. Activez les plans de protection pertinents pour S3, EKS, RDS, Lambda, les logiciels malveillants et l'activité d'exécution. Centralisez les résultats dans Security Hub et envoyez les alertes de haute gravité à un SIEM.

Comment y parvenir : Utilisez GuardDuty, Security Hub, Inspector, Macie, EventBridge, Lambda, la correction SSM et les enquêtes Detective.

Ce que cela évite : Utilisation abusive d'identifiants, activité de commande et contrôle, minage de cryptomonnaie, accès malveillant aux données et longues périodes d'activité non détectée.

Impact pour l'entreprise : La détection sans réponse humaine ne fait que générer du volume d'alertes. Prévoyez un budget pour l'utilisation des services, l'acheminement SIEM, le temps d'enquête et la capacité d'astreinte.

Gérez les vulnérabilités et appliquez les correctifs aux charges de travail selon un SLA défini

Ce que c'est : Établissez la gestion des vulnérabilités en analysant en continu EC2, ECR et Lambda, puis associez les résultats à des échéances de correction basées sur la gravité.

Comment procéder : Définissez des seuils de build CI, définissez des bases de référence Systems Manager Patch Manager, planifiez des fenêtres de maintenance et remplacez les charges de travail immuables plutôt que d'appliquer manuellement des correctifs aux hôtes en cours d'exécution.

Comment y parvenir : Utilisez Amazon Inspector, l'analyse ECR améliorée, Systems Manager, EC2 Image Builder et les AMI de référence (golden AMIs).

Ce que cela évite : Exploitation de vulnérabilités connues dans les hôtes, les images, les dépendances et les fonctions.

Impact pour l'entreprise : Suivez le temps moyen de correction par gravité. Sans propriétaires et échéances clairs, les scanners produisent un arriéré ignoré au lieu d'une réduction mesurable du risque.

Classifiez les données sensibles et empêchez l'exposition publique

Ce que c'est : Identifiez les données sensibles et rendez l'accès public difficile à créer ou à maintenir. Incluez les compartiments Amazon S3, les instantanés, les bases de données et d'autres ressources dans l'examen de l'exposition.

Comment procéder : Appliquez le blocage de l'accès public S3 au niveau du compte via une SCP. Utilisez Macie pour découvrir les PII, PHI et données de paiement, examinez les résultats d'accès externe d'IAM Access Analyzer et appliquez des balises (tags) de ressources prenant en charge l'ABAC.

Comment y parvenir : Combinez Macie, les contrôles S3, les vérifications de la configuration de référence d'AWS Config, les normes de balisage et les politiques ABAC.

Ce que cela évite : Compartiments publics, instantanés exposés, bases de données ouvertes et incertitude quant aux données réglementées contenues dans une ressource compromise.

Impact pour l'entreprise : La classification améliore la définition de la portée de la conformité et l'analyse des failles. Les coûts de Macie dépendent du volume de données, de sorte qu'une découverte ciblée et un échantillonnage peuvent être plus pratiques qu'une analyse continue de chaque objet.

Protégez la périphérie et la couche applicative avec des contrôles WAF et DDoS

Ce que c'est : Filtrez et limitez le débit du trafic avant qu'il n'atteigne les applications publiques.

Comment procéder : Placez CloudFront et Route 53 devant les services publics. Associez des groupes de règles gérées AWS WAF et des règles basées sur le débit, commencez en mode comptage, ajustez en fonction du trafic réel, puis appliquez le blocage.

Comment y parvenir : Utilisez AWS WAF, CloudFront, Shield Standard, Shield Advanced, les contrôles de bots et l'analyse du trafic.

Ce que cela évite : Risques OWASP, bourrage d'identifiants (credential stuffing), scraping et attaques DDoS au niveau de la couche applicative.

Impact pour l'entreprise : Shield Advanced doit refléter les revenus à risque et les exigences de disponibilité. Son coût d'abonnement est important, il ne s'agit donc pas d'un achat par défaut pour chaque charge de travail.

Sécuriser l'intégration et le déploiement continus (CI/CD) ainsi que la chaîne d'approvisionnement logicielle

Ce que c'est : Traitez les systèmes de construction comme des infrastructures de production privilégiées, car ils peuvent effectuer des déploiements sur des comptes sensibles.

Comment procéder : Utilisez des rôles de déploiement fédérés OIDC avec des autorisations spécifiques à l'environnement. Vérifiez les dépendances, stockez les packages approuvés dans CodeArtifact, signez les artefacts et les conteneurs, et analysez les modifications d'infrastructure avant le déploiement.

Comment y parvenir : Utilisez AWS Signer, la vérification ECR, CodeArtifact, CloudFormation Guard, cfn-nag, Checkov et les vérifications de politiques IAM.

Ce que cela évite : Dépendances compromises, étapes de construction corrompues, artefacts non signés et modifications d'infrastructure non sécurisées.

Impact pour l'entreprise : Commencez par des barrières d'avertissement, puis bloquez les résultats graves au fur et à mesure que les équipes s'adaptent. Une application progressive améliore l'adoption sans affaiblir la norme finale.

Rendre les sauvegardes immuables et tester chaque scénario de restauration

Ce que c'est : Conservez des copies de sauvegarde qu'un attaquant disposant d'un accès administrateur de production ne peut ni supprimer ni modifier.

Comment procéder : Appliquez les politiques d'organisation AWS Backup, copiez les sauvegardes sur plusieurs comptes et régions, et utilisez le verrouillage de coffre ou des coffres logiquement isolés (air-gapped). Protégez les données S3 avec le versioning, Object Lock, les contrôles de rétention et le chiffrement.

Ce que cela évite : Ransomwares, collaborateurs malveillants et processus de sauvegarde qui semblent réussis mais échouent lors de la restauration.

Impact pour l'entreprise : Effectuez des exercices de restauration au moins tous les trimestres et documentez les résultats RTO et RPO mesurés. Les coûts de stockage, de réplication et de transfert sont réels, mais réduire ce budget peut augmenter le risque d'interruption.

Institutionnaliser la réponse aux incidents et la conformité continue

Ce que c'est : Maintenez des procédures de réponse éprouvées et examinez les contrôles de sécurité après tout déploiement et changement majeur.

Comment procéder : Créez un plan de réponse aux incidents avec des guides opérationnels (playbooks) pour la compromission d'identifiants, l'exposition de données publiques, les ransomwares et l'utilisation abusive interne. Pré-provisionnez un compte d'investigation numérique (forensics) et des rôles d'incident, organisez des exercices sur table deux fois par an et automatisez la collecte de preuves.

Comment y parvenir : Utilisez Amazon Detective, AWS Security Incident Response, les packs de conformité AWS Config, Audit Manager, ainsi que des évaluations annuelles avec l'outil AWS Well-Architected et le pilier Sécurité.

Ce que cela évite : Réponse lente, dérive de configuration, preuves d'audit incomplètes et décisions improvisées lors d'un événement de sécurité.

Impact pour l'entreprise : Des examens réguliers réduisent le travail de préparation de l'audit et maintiennent le bon fonctionnement des autres contrôles. Le programme de sécurité doit être examiné chaque année et après des changements architecturaux majeurs.

Le coût réel de la mise en œuvre de la sécurité AWS en entreprise

La sécurité AWS pour les entreprises coûte plus cher que la simple activation de quelques services dans la console. Votre facture comprend les frais AWS basés sur l'utilisation, l'ingénierie de l'infrastructure cloud, les travaux de migration, les opérations de sécurité, la réponse aux incidents, la préparation aux audits et le temps nécessaire pour maintenir l'efficacité des contrôles.

La bonne question n'est pas : “ Combien coûte GuardDuty ? ”. Demandez plutôt :, “ Quel sera le coût d'une couverture complète sur l'ensemble des comptes, régions, charges de travail, sources de journaux et copies de sauvegarde ? ” Un déploiement limité à la production peut sembler abordable tout en laissant les comptes de développement, les régions secondaires ou les flux de données sensibles sans surveillance.

Séparer les frais AWS du coût d'exploitation de la sécurité

Les services de sécurité AWS évoluent généralement en fonction de la taille et de l'activité de votre environnement. Les comptes, les régions, le volume de journaux, les données analysées, le nombre de ressources, les requêtes API, le trafic, les résultats d'analyse, les périodes de conservation et les copies de sauvegarde peuvent tous influencer le montant final.

Votre modèle financier doit séparer les frais cloud directs des coûts d'exploitation internes. Il doit également prendre en compte la protection des données, la propriété et l'effort nécessaire pour maintenir l'efficacité de chaque contrôle. Sinon, le budget de sécurité semblera plus restreint que ce que le programme représente réellement.

Catégorie de coût	Ce qui génère le coût	Pression budgétaire typique
Identité et gouvernance	Clés MFA, migration de comptes, conception de politiques, revues d'accès, clés d'accès	Temps d'ingénierie et de processus
Journalisation et surveillance	Événements CloudTrail, journaux de flux VPC (VPC Flow Logs), enregistrements Config, conservation, requêtes	Frais de stockage, d'ingestion et de SIEM
Détection et analyse	Sources de données GuardDuty, ressources Security Hub, analyses Inspector, découverte Macie	Nombre de ressources et volume de données
Protection réseau	Points de terminaison VPC, Transit Gateway, Network Firewall, NAT, trafic inspecté	Frais horaires et traitement des données
Chiffrement et secrets	Requêtes KMS, clés gérées par le client, entrées et rotation Secrets Manager	Volume de requêtes et nombre de secrets
Protection périphérique (Edge)	Requêtes WAF, règles gérées, Bot Control, Shield Advanced	Trafic public et besoins d'abonnement
Résilience des sauvegardes	Stockage, réplication, transfert entre régions, tests de restauration	Exigences de conservation et de récupération

La facture AWS directe n'est qu'une partie du total. Les équipes ont également besoin de temps pour la restructuration des comptes, la migration IAM, le test des politiques, les modifications d'applications, les exercices sur table, la correction des vulnérabilités et la collecte de preuves.

Par exemple, le remplacement de clés d'accès statiques peut avoir un coût de service minime, tout en consommant des semaines de travail pour les équipes d'ingénierie. Le déplacement de charges de travail vers des sous-réseaux privés peut réduire l'exposition, mais peut nécessiter de nouvelles routes, des points de terminaison VPC, des règles de pare-feu et de la connectivité partenaire. Ces coûts de main-d'œuvre doivent être inclus dans l'analyse de rentabilisation.

Un contrôle de sécurité qui n'a pas de propriétaire, de destination d'alerte ou de calendrier de révision est un contrôle inachevé, même lorsque le service AWS est activé.

### La journalisation et la détection deviennent les coûts récurrents les plus importants

La journalisation centralisée est souvent la première augmentation majeure après la standardisation de l'architecture de sécurité d'une entreprise. AWS CloudTrail, les VPC Flow Logs, AWS Config, les événements de données S3, les événements de données Lambda et les journaux d'applications à l'échelle de l'organisation peuvent générer un volume important d'enregistrements.

Les choix de rétention sont essentiels. Conserver chaque journal dans CloudWatch Logs pendant des années est rarement la conception la plus économique. De nombreuses organisations conservent les enregistrements récents dans un stockage consultable, puis transfèrent les données plus anciennes vers des compartiments Amazon S3 et un stockage d'archivage avec des politiques de rétention et de verrouillage d'objets (Object Lock). Ce sont les exigences réglementaires qui doivent déterminer la période de rétention, et non la commodité.

Le même principe s'applique à la détection des menaces. La tarification d'Amazon GuardDuty dépend des sources de données analysées et de l'activité des charges de travail, notamment les journaux de service, les vCPU, les charges de travail d'exécution et les données analysées à la recherche de logiciels malveillants. Cela signifie que deux organisations disposant du même nombre de comptes AWS peuvent recevoir des factures très différentes.

Security Hub propose désormais un modèle de tarification simplifié qui regroupe les éléments essentiels de Security Hub, Amazon Inspector et Cloud Security Posture Management dans une structure par ressource avec des analyses illimitées dans le cadre du plan applicable. L'exemple de tarification d'AWS utilise 1 210 unités de ressources à $3.75 par ressource, ce qui donne un exemple mensuel de $4 537.50. Considérez ce chiffre comme une illustration et non comme un devis d'entreprise, car la combinaison de ressources et la région affectent le résultat. Consultez la grille tarifaire actuelle d'AWS Security Hub avant d'approuver un déploiement.

La détection génère également des coûts opérationnels. Les résultats doivent parvenir à un SIEM, à un système de billetterie ou à une rotation d'astreinte. Quelqu'un doit enquêter sur les faux positifs, ajuster les règles, clôturer les résultats et confirmer que la correction automatisée n'a pas interrompu une charge de travail légitime.

Une prévision utile comprend donc :

• Le nombre de comptes et de régions activées.
• Les ressources couvertes par chaque plan de détection et d'analyse.
• Le volume d'événements CloudTrail, réseau, d'application et de données.
• Le pourcentage de résultats envoyés à un SIEM externe.
• Le nombre d'analystes ou d'ingénieurs affectés à la réponse.
• Les périodes de rétention et d'archivage prévues.

Activer chaque détecteur sans financer la réponse revient à installer des avertisseurs de fumée sans que personne ne soit chargé de les vérifier.

Les contrôles réseau, de chiffrement et de périphérie comportent des compromis visibles

La connectivité privée peut ajouter des frais récurrents importants. Les points de terminaison d'un VPC d'interface entraînent des coûts horaires et de traitement des données. Transit Gateway ajoute des frais d'association et de traitement, tandis que Network Firewall et le trafic NAT inspecté ajoutent des coûts de capacité et de traitement supplémentaires. Ensemble, ces services façonnent le coût de la sécurité réseau.

Ces services ne sont pas systématiquement un gaspillage. Ils peuvent réduire l'exposition publique, simplifier les normes de routage et limiter les voies disponibles pour l'exfiltration de données. Cependant, vous devez modéliser les modèles de trafic avant de les rendre obligatoires pour chaque compte. Une petite charge de travail interne peut nécessiter une conception différente de celle d'une plateforme d'analyse à volume élevé.

Les coûts de chiffrement ont tendance à apparaître via les requêtes KMS plutôt que via la décision de base d'utiliser le chiffrement au repos. Les charges de travail qui appellent AWS Key Management Service pour chaque objet ou transaction peuvent générer d'importants volumes de requêtes. La mise en cache des clés de données et des modèles d'enveloppe de chiffrement judicieux peuvent réduire les appels répétés sans affaiblir la protection.

Secrets Manager génère un coût récurrent par secret stocké et ajoute des frais pour les appels d'API. Cette dépense est généralement modeste par rapport à l'effort d'ingénierie requis pour renouveler manuellement les identifiants ou enquêter sur un mot de passe divulgué. Néanmoins, les secrets inactifs doivent être supprimés et les applications doivent demander les secrets au moment de l'exécution via des rôles plutôt que de les copier dans les artefacts de build.

Pour les compartiments Amazon S3, le chiffrement côté serveur en soi n'est généralement pas le principal facteur de coût. Les demandes de clés associées, la réplication, le stockage et le traitement des données peuvent affecter le total. Pour les applications publiques, les coûts du WAF dépendent du volume de requêtes et des fonctionnalités sélectionnées. Les règles gérées, les règles basées sur le débit, Bot Control et la journalisation peuvent chacun affecter le total. Shield Advanced ajoute un engagement d'abonnement important, cette décision doit donc être basée sur l'exposition des revenus, les objectifs de disponibilité et le coût de l'assistance en cas d'incident.

Les sauvegardes et la conformité font de la sécurité un engagement à long terme

Les sauvegardes immuables nécessitent plus d'un instantané planifié. Les copies multi-comptes et multi-régions augmentent les coûts de stockage et de transfert, tandis qu'une rétention plus longue maintient ces frais actifs. Le versioning S3, Object Lock, la réplication et les tests de récupération ajoutent des tâches de stockage et opérationnelles supplémentaires tout au long du cycle de vie de la sauvegarde et de la récupération.

Pourtant, une sauvegarde qui n'a jamais été restaurée est une hypothèse, pas un plan de reprise. Les exercices de restauration trimestriels nécessitent du temps d'ingénierie, des environnements de test, des propriétaires d'applications et des résultats RTO et RPO documentés. Ces exercices révèlent les défaillances pendant que vous pouvez encore les corriger.

La conformité entraîne également un coût de main-d'œuvre. Les packs de conformité AWS Config, Audit Manager, les preuves centralisées et les révisions d'accès récurrentes réduisent le travail manuel, mais ils n'éliminent pas la responsabilité. Les normes de conformité varient selon l'organisation, et chaque contrôle nécessite une équipe responsable, un processus d'exception et une cadence de révision. Les audits de sécurité ajoutent une autre demande récurrente de preuves et de révisions.

Budgétisez ces catégories séparément :

1. Coût de build : conception de la zone d'atterrissage, migrations, élaboration de politiques et modifications d'applications.
2. Coût de fonctionnement (run) : services AWS, intégration SIEM, stockage, licences et couverture d'astreinte.
3. Coût d'assurance : audits, tests d'intrusion, exercices de restauration, exercices de simulation sur table, gestion des vulnérabilités et examens indépendants.
4. Coût de changement : nouvelles régions, acquisitions, lancements de charges de travail et modifications majeures d'architecture.

Le chiffre final variera selon le parc informatique. Une petite entreprise avec un volume de journaux modeste peut dépenser peu en services mais davantage en ingénierie initiale. Une grande plateforme multi-région peut dépenser énormément en traitement de données, en rétention, en intégration SIEM et en personnel d'intervention.

Réduire le tarif effectif d'AWS peut faciliter le maintien d'une couverture complète des contrôles sans couper de services ni raccourcir la rétention. Les services de Spendbase Réductions AWS peuvent aider les équipes financières à examiner ce calcul parallèlement à leur couverture de sécurité, afin que les économies soutiennent les contrôles plutôt que de devenir une raison de les limiter.

Créez les prévisions à partir de données réelles d'utilisation et de compte, puis testez trois scénarios : une couverture de conformité minimale, une couverture d'entreprise recommandée et une couverture complète pour les charges de travail à haut risque. Cette comparaison offre au RSSI et au directeur financier un choix pragmatique, au lieu de forcer les décisions de sécurité dans une demande budgétaire floue du type tout ou rien.

Déployez la liste de contrôle de sécurité AWS en 90 jours

Un environnement AWS sécurisé doit s'améliorer grâce à des étapes planifiées, et non par un sprint d'audit précipité. AWS recommande un parcours progressif aligné sur le Un cadre bien conçu pour AWS, en commençant par la structure des comptes et la gestion des identités et des accès (IAM), puis en ajoutant des contrôles multicouches, la protection des données, l'automatisation et la préparation aux incidents.

Appliquez ces meilleures pratiques de sécurité AWS dans une liste de contrôle de 90 jours pour une charge de travail critique d'abord. Une fois les modèles validés, étendez-les via l'infrastructure as code au reste de votre organisation. Cette approche permet de réaliser des progrès mesurables sans attendre que chaque compte, région et application change en même temps.

Jours 1 à 30 : Établir l'identité, la visibilité et la responsabilité

Le premier mois doit permettre d'éliminer les risques qui pourraient donner à un attaquant un accès étendu ou laisser votre équipe sans preuves fiables. Désignez un parrain exécutif, un responsable technique et un responsable pour chaque contrôle de sécurité. Enregistrez ensuite chaque compte AWS, région, charge de travail, magasin de données, utilisateur IAM, clé d'accès et intégration externe.

Commencez par la gouvernance des comptes. Confirmez que tous les comptes appartiennent à une seule organisation AWS, identifiez le compte de gestion et créez des comptes dédiés aux outils de sécurité et à l'archivage des journaux. Si votre zone d'atterrissage est incomplète, définissez la structure des unités d'organisation (OU) et appliquez les premiers garde-fous Control Tower avant de déplacer les charges de travail de production.

Ensuite, protégez les accès privilégiés, en particulier l'utilisateur racine (root) :

1. Supprimez les identifiants d'utilisateur racine inutiles des comptes membres en utilisant la gestion centralisée des accès racine.
2. Exigez une authentification multifacteur pour chaque identité humaine, avec des clés de sécurité FIDO2 ou des clés d'accès (passkeys) pour les administrateurs et les identités de secours.
3. Connectez IAM Identity Center à votre fournisseur d'identité d'entreprise.
4. Remplacez les utilisateurs IAM et les clés d'accès à longue durée de vie par des ensembles d'autorisations, des rôles IAM et des sessions fédérées à courte durée de vie.
5. Examinez chaque rôle privilégié, attribuez-lui un propriétaire et documentez son utilisation approuvée.

N'attendez pas la fin du mois pour établir la traçabilité. Créez un suivi AWS CloudTrail multi-régions à l'échelle de l'organisation et transmettez les journaux à un compartiment S3 dans le compte d'archivage des journaux. Limitez l'accès des charges de travail à ce compartiment, définissez des périodes de rétention et appliquez Object Lock lorsque les exigences réglementaires exigent des enregistrements immuables.

Activez l'enregistrement AWS Config sur l'ensemble des comptes et des régions concernés. Utilisez les résultats d'AWS Config pour établir une base de référence pour les ressources publiques, le stockage non chiffré, les groupes de sécurité non restreints, la journalisation désactivée et les balises manquantes. Les conseils de sécurité cloud d'AWS mettent également l'accent sur l'identité, la surveillance, la protection de l'infrastructure et la sécurité des données en tant que parties connectées du programme.

Au 30e jour, votre équipe devrait disposer d'un inventaire écrit, d'une revue des accès, de journaux d'audit centralisés, de métriques de couverture MFA et d'une liste d'exceptions à haut risque. Incluez les clés d'accès actuelles dans l'inventaire et signalez la posture de sécurité initiale. L'objectif n'est pas encore de respecter parfaitement le principe du moindre privilège. L'objectif est de savoir qui peut agir, ce qu'il peut atteindre et où se trouvent les preuves.

Jours 31 à 60 : Ajoutez la détection, des garde-fous stratégiques et des contrôles de données

Le deuxième mois transforme la visibilité en protection active et en détection des menaces. Commencez par la détection à l'échelle de l'organisation, puis associez les résultats à une personne ou à un système capable de réagir. Un résultat sans propriétaire n'est qu'un élément de plus dans une console.

Activez Amazon GuardDuty via un administrateur délégué dans le compte Security Tooling. Activez les plans de protection correspondant à votre parc, y compris la couverture pertinente pour S3, EKS, RDS, Lambda, les logiciels malveillants et l'activité d'exécution. Centralisez les résultats d'Amazon GuardDuty dans AWS Security Hub, puis acheminez les événements de haute gravité vers votre SIEM, votre système de tickets ou votre processus d'astreinte via EventBridge.

Ajoutez la gestion des vulnérabilités au cours de la même phase. Activez Amazon Inspector pour EC2, ECR et Lambda le cas échéant. Définissez des accords de niveau de service (SLA) de remédiation, tels que des délais plus courts pour les vulnérabilités critiques exposées sur Internet. Connectez les résultats d'Inspector aux flux de travail d'ingénierie et intégrez les contrôles des conteneurs ou de l'infrastructure au pipeline de build.

Introduisez maintenant des garde-fous préventifs :

• Utilisez les SCP pour bloquer les régions non approuvées et empêcher les comptes de désactiver AWS CloudTrail, GuardDuty, AWS Config ou tout autre contrôle requis.
• Appliquez des limites d'autorisations aux rôles qui peuvent créer ou déléguer des accès.
• Utilisez IAM Access Analyzer pour identifier les autorisations inutilisées, les accès externes et les politiques de confiance non sécurisées.
• Appliquez l'accès public bloqué S3 (S3 Block Public Access) au niveau du compte, avec une politique organisationnelle empêchant les équipes de le désactiver.
• Exigez le chiffrement au repos pour le stockage, y compris le chiffrement côté serveur pour Amazon S3, et exigez TLS pour les transferts de données sensibles.

La protection des données nécessite un inventaire, pas seulement une déclaration de politique. Utilisez Amazon Macie pour identifier les informations sensibles dans certains compartiments Amazon S3, puis classez les données en fonction de leur impact commercial et réglementaire. Examinez chaque semaine les résultats concernant les accès publics jusqu'à ce que l'arriéré soit sous contrôle. Pour les charges de travail réglementées, utilisez des clés KMS gérées par le client avec des politiques de clés restrictives et une séparation claire entre les administrateurs de clés et les utilisateurs de données. Validez ces choix par rapport aux normes de conformité et aux exigences réglementaires applicables.

Ajoutez la surveillance de la conformité d'AWS Config au processus de contrôle des données, parallèlement à la classification des données sensibles et aux examens de chiffrement. Le périmètre des données doit également être intégré à cette phase. Limitez l'accès intercompte à l'aide de SCP et de politiques de contrôle des ressources. Examinez les politiques des points de terminaison VPC, resserrez les routes NAT et envoyez le trafic sortant sensible via des chemins d'inspection approuvés. Testez chaque restriction par rapport aux intégrations de fournisseurs connues avant de l'appliquer de manière générale.

Au 60e jour, vous devriez disposer de résultats centralisés, d'accords de niveau de service (SLA) documentés pour les vulnérabilités, de politiques préventives testées et d'une liste prioritaire de magasins de données sensibles. Validez le chiffrement au repos pour les charges de travail critiques et enregistrez les exceptions. Laissez les nouvelles règles en mode audit ou surveillance dans la mesure du possible. Passez-les en mode application après que les propriétaires d'applications ont confirmé que le trafic légitime et les chemins de déploiement fonctionnent toujours.

Jours 61 à 90 : Renforcez la reprise d'activité, les applications et la réponse

Le dernier mois se concentre sur les contrôles qui réduisent l'impact d'un incident. La détection peut montrer qu'un compte est compromis, mais la reprise d'activité et la réponse déterminent jusqu'où l'événement se propage et à quelle vitesse les opérations reprennent.

Protégez les applications publiques avec CloudFront, Route 53 et AWS WAF. Associez des groupes de règles gérés et des règles basées sur le débit, puis commencez en mode comptage afin que votre équipe puisse mesurer les faux positifs. Après affinement, appliquez le blocage pour les modèles d'attaque confirmés. Basez les décisions concernant Shield Advanced sur l'exposition des revenus, les exigences de disponibilité et les besoins de réponse plutôt que d'appliquer le même niveau de dépenses à chaque application.

Examinez la sécurité du réseau et les chemins réseau pour la charge de travail critique. Placez les bases de données et les ressources de calcul dans des sous-réseaux privés, remplacez les règles CIDR larges par des références à des groupes de sécurité et utilisez des points de terminaison VPC pour l'accès aux services AWS lorsque la conception les prend en charge. Confirmez que l'accès administratif utilise des chemins contrôlés, comme une approche Systems Manager sans bastion, au lieu de ports de gestion entrants ouverts.

Ensuite, rendez la sauvegarde et la reprise d'activité indépendantes de l'administration de la production. Créez des politiques AWS Backup qui copient les points de récupération vers un compte et une région distincts. Utilisez le verrouillage de coffre-fort (vault lock) ou des coffres-forts logiquement isolés pour les systèmes qui nécessitent une protection contre un administrateur ayant déjà pris le contrôle de la production. Appliquez le versioning S3 et Object Lock là où la récupération au niveau des objets est importante.

Une politique de sauvegarde est incomplète tant que quelqu'un n'a pas restauré les données. Réalisez un exercice de restauration avant le 90e jour et mesurez le temps de récupération réel, la fenêtre de perte de données, les défaillances de dépendance et les étapes manuelles. Mettez à jour le guide de procédures pendant que les résultats sont encore récents.

Préparez un plan de réponse aux incidents pour la compromission d'identifiants, l'exposition de données publiques, les ransomwares et l'utilisation abusive par des utilisateurs internes. Provisionnez à l'avance des rôles d'incident, un compte d'investigation numérique, des autorisations de collecte de preuves et des canaux de communication. Organisez un exercice de simulation du plan de réponse aux incidents avec les responsables de la sécurité, de la plateforme, des affaires juridiques, de la conformité et de l'activité. Peuvent-ils isoler un compte sans détruire de preuves ? Peuvent-ils révoquer un rôle sans arrêter tous les services critiques ?

Enfin, automatisez les contrôles qui ont passé les tests. Stockez les politiques d'organisation (Organizations policies), les ensembles d'autorisations IAM, les règles AWS Config, les configurations WAF, les plans de sauvegarde et les normes de journalisation dans des référentiels contrôlés par version. Utilisez Terraform, CloudFormation ou un autre système d'infrastructure-as-code approuvé pour les appliquer de manière cohérente. Chaque exception doit avoir un propriétaire, une date d'expiration et un motif commercial documenté.

À la fin des 90 jours, signalez des résultats mesurables :

• Couverture MFA pour les utilisateurs humains et les administrateurs.
• Pourcentage de comptes et de régions envoyant des journaux de manière centralisée.
• Nombre de clés d'accès actives à longue durée de vie.
• Résultats critiques et de haute gravité dépassant leur SLA de remédiation.
• Pourcentage de magasins de données critiques chiffrés et classés.
• Résultats de restauration de sauvegarde réussis par rapport aux objectifs RTO et RPO définis.
• Exceptions de sécurité ouvertes et leurs dates d'expiration.

Le déploiement doit ensuite se poursuivre sous la forme d'un cycle opérationnel reproductible. Commencez par une charge de travail critique, validez les contrôles et étendez-les via l'infrastructure-as-code. Cela permet de lier les bonnes pratiques de sécurité AWS à une appropriation réelle, à une couverture mesurable et au coût de fonctionnement de l'environnement.

Questions fréquemment posées

Quels sont les contrôles de sécurité AWS les plus importants pour les entreprises ?

Commencez par une gouvernance multi-comptes, une identité centralisée, la protection de l'utilisateur racine (root), la MFA, le moindre privilège et une journalisation à l'échelle de l'organisation. Ajoutez la détection, la protection des données, la gestion des vulnérabilités, des sauvegardes résilientes et une réponse aux incidents testée dans le cadre d'un programme structuré en couches.

Les contrôles de sécurité AWS doivent-ils être activés dans chaque compte et chaque région ?

Oui, les failles de sécurité dans les comptes de développement, les régions secondaires ou les chemins de données non surveillés peuvent fournir aux attaquants un point d'entrée ou un espace pour opérer sans être détectés. La couverture doit correspondre aux exigences de risque et de conformité de l'organisation, avec des exceptions documentées comprenant des propriétaires et des dates d'expiration.

Comment les entreprises peuvent-elles réduire les coûts de sécurité AWS sans affaiblir la protection ?

Séparez les frais AWS directs des coûts d'ingénierie et d'exploitation, puis modélisez l'utilisation par compte, région, ressource, volume de données et période de rétention. Utilisez les niveaux de journaux appropriés, archivez les enregistrements plus anciens, supprimez les secrets inactifs, optimisez l'utilisation de KMS et examinez les tarifs négociés ou les remises au lieu de réduire la couverture essentielle.

À quelle fréquence la restauration des sauvegardes AWS et la réponse aux incidents doivent-elles être testées ?

Exécutez des exercices de restauration de sauvegarde au moins une fois par trimestre et mesurez les résultats réels du RTO et du RPO. Organisez des exercices de simulation de réponse aux incidents deux fois par an, avec des examens supplémentaires après des changements architecturaux ou organisationnels majeurs.

Que doit apporter un déploiement de la sécurité AWS en 90 jours ?

Au jour 30, établissez la propriété, l'inventaire, la MFA, l'accès fédéré et les journaux d'audit centralisés. Au jour 60, ajoutez la détection, les SLA de vulnérabilité, les garde-fous préventifs et les contrôles de données ; au jour 90, renforcez les applications et les réseaux, testez la restauration, répétez la réponse et signalez des résultats mesurables.

Conclusion

Les meilleures pratiques de sécurité AWS pour les entreprises constituent un programme opérationnel et non un projet de configuration unique. Le programme attribue des propriétaires et des cycles d'examen aux contrôles d'identité, aux preuves AWS CloudTrail, aux résultats AWS Config, aux données protégées et à la préparation à la reprise. Il maintient également l'utilisateur racine sous contrôle strict et conserve un plan de réponse aux incidents que les équipes répètent.

Votre prochaine étape consiste à réserver une évaluation gratuite de la sécurité AWS axée sur une charge de travail critique. Présentez-la comme une évaluation structurée alignée sur le framework AWS Well-Architected, tenant compte des normes de conformité applicables. L'évaluation doit produire un classement des problèmes à haut et moyen risque, plutôt qu'un simple résultat de réussite ou d'échec. Vous pouvez également vérifier si votre organisation est éligible aux crédits AWS, puis explorer la réduction continue des coûts AWS grâce à des tarifs de facturation négociés et à l'optimisation de l'utilisation.

L'évaluation identifie ce qu'il faut corriger. Les crédits et les remises aident à financer la remédiation, de sorte que la couverture de sécurité ne se limite pas aux comptes de production ou à une seule région. Avant la publication, vérifiez les conditions d'éligibilité, les limites de crédit, les taux de remise et le positionnement exact de l'évaluation par rapport aux conditions actuelles de Spendbase et d'AWS.

Test d'auto-évaluation

Vous pouvez lancer notre auto-évaluation pour comprendre où vérifier votre sécurité AWS.