Articles

Affichage des articles associés au libellé Sécurité

Pourquoi utiliser Secrets Manager plutôt que de coder les secrets en dur ?

Un dépôt privé ne protège pas un mot de passe de base de données codé en dur — c'est une illusion de sécurité que l'on découvre souvent trop tard, après une rotation d'accès forcée ou une fuite via un log d'application. AWS Secrets Manager existe précisément pour découpler les secrets du code, et sa rotation automatique change fondamentalement la surface d'attaque. Résumé (TL;DR) — Secrets Manager vs. secrets codés en dur Critère Secret codé en dur AWS Secrets Manager Exposition en cas de fuite du dépôt Immédiate et permanente Aucune (le code ne contient pas le secret) Rotation du mot de passe Manuelle, risquée, souvent ignorée Automatique, sans interruption de service Audit d'accès Impossible CloudTrail enregistre chaque appel GetSecretValue Gestion multi-environnements Copie manuelle, divergence garantie Secrets distincts par environnement, même code Révocation d'urgence...

Qui a supprimé cette instance EC2 ? Retrouver le responsable avec CloudTrail

Une instance EC2 disparaît sans explication un matin — aucune alerte, aucun ticket, et l'équipe pointe dans toutes les directions. Retrouver qui a déclenché l'action TerminateInstances est exactement le cas d'usage pour lequel CloudTrail Event History existe, à condition de savoir où chercher et comment interpréter ce qu'on y trouve. TL;DR — Retrouver l'auteur d'une suppression EC2 Étape Action Ce qu'on obtient 1 Ouvrir CloudTrail Event History Journal des appels API des 90 derniers jours 2 Filtrer sur TerminateInstances Liste des événements de terminaison 3 Identifier l'instance cible Correspondance par ID de ressource 4 Lire le champ userIdentity IAM user, rôle assumé, ou service AWS 5 Corréler avec sourceIPAddress et userAgent Contexte d'exécution (console, CLI, SDK) Comment CloudTrail enregistre les actions EC2 CloudTrail capture les appels API effectu...

Structure de base d'une politique IAM : Effect, Action, Resource et Condition expliqués

La première fois qu'on ouvre une politique IAM JSON en production pour diagnostiquer un accès refusé, les quatre éléments Effect , Action , Resource et Condition semblent évidents — jusqu'au moment où une permission ne se comporte pas comme prévu et qu'on réalise qu'on avait mal compris la portée d'un seul de ces champs. Comprendre la structure d'une politique IAM, c'est comprendre comment AWS évalue chaque requête API avant de l'autoriser ou de la rejeter. TL;DR — Structure d'une politique IAM Élément Rôle Obligatoire Effect Autorise ( Allow ) ou refuse ( Deny ) explicitement Oui Action Quelle(s) opération(s) API sont ciblées Oui Resource Sur quel(s) objet(s) AWS s'applique la règle Oui Condition Contraintes contextuelles supplémentaires (IP, MFA,...

Créer une URL Présignée S3 : Accès Temporaire à un Fichier Privé

Vous avez un fichier privé dans S3 et vous devez donner à un utilisateur un accès temporaire pour le télécharger — sans exposer vos credentials, sans rendre le bucket public, et sans passer par un proxy applicatif. C'est exactement le cas d'usage des URLs présignées S3 : générer un lien à durée limitée qui porte la signature de votre identité IAM, valide pendant la fenêtre que vous définissez. TL;DR — Résumé Opérationnel Élément Détail Objectif Générer une URL présignée S3 avec expiration de 1 heure SDK recommandé AWS SDK v3 pour Python (boto3) ou JavaScript (v3) Opération signée GetObject Durée maximale (credentials IAM) 7 jours (604 800 secondes) avec credentials à long terme Durée maximale (rôle IAM / STS) Limitée à la durée de session du token STS Prérequis IAM s3:GetObject sur la ressource cible Visibilité bucket Le bucket reste privé — aucune modification de politique nécessa...

Récupérer l'ID d'instance EC2 via le Service de Métadonnées : Pourquoi IMDSv2 est Indispensable

Vous écrivez un script de démarrage sur une instance EC2 et vous avez besoin de l'ID de l'instance — sans le coder en dur, sans appel API externe. Le réflexe naturel est d'interroger le service de métadonnées local. Mais si votre script utilise encore IMDSv1, vous exposez potentiellement votre infrastructure à une classe d'attaques bien documentée que IMDSv2 a été conçu pour éliminer. Résumé (TL;DR) : IMDSv1 vs IMDSv2 pour Récupérer l'ID d'Instance EC2 Aspect IMDSv1 IMDSv2 Mécanisme d'authentification Aucun — requête GET directe Token de session obligatoire (TTL configurable) Résistance aux SSRF Non — une requête suffit Oui — nécessite un PUT préalable avec en-tête spécifique Commande principale curl http://169.254.169.254/latest/meta-data/instance-id Obtenir un token puis interroger avec l'en-tête X-aws-ec2-metadata-token Recommandation AWS Déprécié pour nouveaux déploieme...