Scénarios d’architecture sécurisée

Mise en situation : Une instance EC2 exécute une application Web qui doit lire des objets dans un compartiment S3 précis. L’équipe de sécurité exige qu’aucun identifiant à long terme ne soit stocké sur l’instance et que l’accès respecte le principe du moindre privilège. Solution : Créez un rôle IAM associé à une politique autorisant uniquement s3:GetObject sur l’ARN du compartiment concerné. Attachez le rôle à l’instance EC2 sous la forme d’un profil d’instance. L’application utilise le service de métadonnées d’instance (IMDS) pour récupérer automatiquement des identifiants temporaires : aucune clé stockée n’est nécessaire.

Mise en situation : Une entreprise stocke des données personnelles identifiables (PII) de ses clients dans une base de données RDS PostgreSQL. L’équipe chargée de la conformité exige un chiffrement au repos avec la possibilité d’auditer l’utilisation des clés. Solution : Activez le chiffrement RDS avec AWS KMS à l’aide d’une clé gérée par le client (CMK). La CMK permet à l’équipe de sécurité de contrôler la rotation des clés, de consulter leur utilisation dans CloudTrail et de révoquer l’accès si nécessaire. Remarque : le chiffrement doit être activé lors de la création de l’instance RDS ; vous ne pouvez pas chiffrer sur place une instance RDS existante qui ne l’est pas. Pour chiffrer une base existante, créez un instantané, copiez-le en activant le chiffrement, puis restaurez-le à partir de l’instantané chiffré.

Mise en situation : Un développeur a accidentellement rendu public un compartiment S3, exposant ainsi des données client. L’équipe de sécurité veut garantir qu’aucun compartiment S3 du compte ne puisse jamais être rendu public, même si un développeur tente de le faire. Solution : Activez le blocage de l’accès public S3 au niveau du compte. Cette fonctionnalité remplace toute politique ou ACL au niveau du compartiment accordant un accès public, quelles que soient les configurations des différentes équipes. Associez-y une règle AWS Config (s3-bucket-public-read-prohibited) pour détecter en continu les compartiments non conformes et générer des alertes.

Mise en situation : Une entreprise veut s’assurer que sa base de données RDS est accessible uniquement depuis ses serveurs d’application et non depuis Internet. Solution : Placez RDS dans un sous-réseau privé sans route vers une passerelle Internet. Créez un groupe de sécurité pour RDS qui autorise uniquement le trafic entrant sur le port 5432 (PostgreSQL) depuis le groupe de sécurité des serveurs d’application — et non depuis une plage d’adresses IP. Ainsi, même si un serveur d’application est compromis, l’attaquant ne peut pas atteindre la base de données depuis l’extérieur du VPC, et les déplacements latéraux sont limités par les règles des groupes de sécurité.

Mise en situation : Le code de l’application contient actuellement des identifiants de base de données inscrits en dur dans des fichiers de configuration. L’audit de sécurité considère cela comme un risque critique. Solution : Stockez les identifiants dans AWS Secrets Manager et configurez la rotation automatique (Secrets Manager fournit des fonctions Lambda intégrées pour la rotation de RDS). Mettez à jour l’application afin qu’elle récupère les identifiants auprès de Secrets Manager au moment de l’exécution à l’aide du SDK. L’application obtient automatiquement des identifiants à jour sans déploiement à chaque rotation. Activez le modèle de rotation des secrets RDS pour bénéficier d’une rotation entièrement gérée et sans interruption.

Mise en situation : Une entreprise veut détecter si les identifiants d’un compte AWS sont compromis et utilisés depuis des emplacements inattendus. Solution : Activez Amazon GuardDuty dans toutes les Régions. GuardDuty analyse les événements CloudTrail, les journaux de flux VPC et les journaux DNS au moyen de l’apprentissage automatique pour détecter les anomalies : appels d’API depuis des zones géographiques inhabituelles, schémas de minage de bitcoins sur EC2, communications avec des nœuds de sortie Tor ou schémas d’exfiltration d’identifiants. GuardDuty génère des résultats qui peuvent déclencher des règles EventBridge afin de notifier automatiquement l’équipe de sécurité via SNS ou de créer un ticket d’assistance.

Mise en situation : Une application Web exécutée derrière un ALB reçoit des attaques par injection SQL. L’application ne peut pas être modifiée immédiatement. Solution : Associez AWS WAF à l’ALB. Déployez le groupe de règles AWS Managed Rules for Common Threats (Core Rule Set et groupe de règles SQL Database), qui comprend une détection préconfigurée des injections SQL. WAF inspecte les requêtes HTTP avant qu’elles n’atteignent l’ALB et bloque celles qui correspondent à des schémas d’attaque — aucune modification du code de l’application n’est nécessaire. Activez également la journalisation WAF vers Kinesis Firehose pour l’analyse de sécurité.

Mise en situation : Un compte de sécurité central a besoin d’un accès en lecture seule à tous les comptes de charge de travail d’une AWS Organisation afin d’effectuer des audits de sécurité. Solution : Dans chaque compte de charge de travail, créez un rôle IAM doté d’une politique d’approbation autorisant le compte de sécurité (par ID de compte) à l’assumer. Associez-lui une politique en lecture seule (par exemple, la politique gérée AWS SecurityAudit). L’équipe de sécurité du compte central utilise STS AssumeRole pour assumer temporairement le rôle dans chaque compte de charge de travail. Cette approche respecte le principe du moindre privilège : aucun utilisateur IAM permanent n’est créé dans les comptes de charge de travail.

Mise en situation : Une entreprise utilise AWS Organizations et veut empêcher tout compte d’une OU hors production de lancer des instances GPU coûteuses. Solution : Créez une politique de contrôle des services (SCP) qui refuse ec2:RunInstances pour les familles d’instances GPU (p3, p4, g4, g5), puis associez-la à l’OU hors production. Les SCP s’appliquent même aux utilisateurs racine et aux utilisateurs IAM disposant de privilèges d’administrateur dans les comptes membres : elles servent de garde-fous qu’aucune identité du compte ne peut contourner. Cela empêche des dépenses importantes accidentelles ou malveillantes dans les comptes de développement et de test.

Mise en situation : Une entreprise de services financiers doit démontrer aux auditeurs que tous les appels d’API AWS sont journalisés, protégés contre toute altération et conservés pendant 7 ans. Solution : Créez une piste AWS CloudTrail multi-Région qui envoie les journaux vers un compartiment S3 dédié dans un compte de journalisation. Activez la validation de l’intégrité des fichiers journaux (fichiers d’empreintes cryptographiques qui détectent toute altération des journaux). Définissez une politique S3 Object Lock en mode Compliance avec une durée de conservation de 7 ans sur le compartiment de journalisation. Ainsi, les journaux ne peuvent être ni supprimés ni modifiés — même par l’utilisateur racine — pendant la durée de conservation requise.

Mise en situation : Des instances EC2 dans un VPC privé doivent accéder à S3 sans que le trafic ne traverse Internet. Une passerelle NAT est actuellement utilisée, et les coûts sont élevés en raison des frais de traitement des données de la passerelle NAT. Solution : Créez un point de terminaison VPC de type passerelle pour S3. Ajoutez une entrée de route à la table de routage du sous-réseau privé, en dirigeant la liste de préfixes S3 vers le point de terminaison. Le trafic vers S3 reste désormais entièrement au sein du réseau fédérateur AWS : aucune passerelle NAT ni passerelle Internet n’est nécessaire. Les points de terminaison VPC de type passerelle pour S3 sont gratuits (contrairement aux points de terminaison d’interface, facturés à l’heure et par AZ). Cette solution améliore également la sécurité en supprimant l’accès à S3 du chemin passant par Internet.

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez étudié des scénarios portant sur les rôles IAM et les profils d’instance pour accéder à EC2 sans identifiants, Secrets Manager pour la rotation automatique des identifiants de Database, AWS WAF pour bloquer les attaques par injection sans modifier le code, ainsi que CloudTrail avec S3 Object Lock pour des journaux de conformité infalsifiables. Nous allons maintenant aborder des scénarios d’architecture résiliente et hautement disponible.