Questions d'entretien Cloud

Non. Le cloud repose sur un modèle de responsabilité partagée : le fournisseur sécurise l'infrastructure sous-jacente (« sécurité du cloud »), mais vous restez responsable de vos données, de la gestion des identités et des accès, de la configuration et — en IaaS — du système d'exploitation et des correctifs (« sécurité dans le cloud »). La grande majorité des fuites cloud sont des erreurs de configuration côté client, comme des buckets publics et un IAM trop permissif, et non des défaillances du fournisseur. Croire que le fournisseur sécurise vos données est précisément ainsi que ces fuites surviennent.

Les comptes de service inutilisés et sur-privilégiés sont des cibles de choix et une large surface d'attaque. Inventoriez-les, désactivez ou supprimez les inutilisés (en surveillant les casses), réduisez les survivants au moindre privilège et donnez à chacun un propriétaire et une revue récurrente. Les laisser est un risque permanent, leur accorder un accès admin global maximise le rayon d'impact, et tout consolider sur un compte partagé unique détruit le moindre privilège et la responsabilité.

Récupérer côté serveur des URL contrôlées par l'attaquant relève du Server-Side Request Forgery (SSRF) : cela permet d'atteindre des services internes ou le point de terminaison de métadonnées cloud pour voler des identifiants. Pour l'atténuer, restreignez les hôtes et schémas autorisés par allow-list, bloquez les plages privées et link-local (en revérifiant après chaque redirection) et durcissez l'accès aux métadonnées avec IMDSv2. Dire qu'il n'y a aucun risque ignore l'accès que confère la requête, et un spinner de chargement ou une mise en cache ne change rien aux destinations que le serveur peut joindre.

Sans journaux d'audit du plan de contrôle, vous êtes aveugle à qui a fait quoi au niveau cloud, et détection, forensique et conformité dépendent toutes de cet enregistrement. Activez CloudTrail immédiatement, à l'échelle de l'org, en livrant vers un bucket séparé, à accès contrôlé et résistant à la falsification (immuable). Dire que ça n'a pas d'importance tant que rien ne va mal ignore que vous n'auriez aucun historique le jour où ça ira mal. Attendre un incident signifie que les premières actions décisives sont déjà non journalisées et irrécupérables. Les journaux applicatifs ne capturent pas l'activité API, IAM ou console du plan de contrôle.

Les ports d'administration ouverts à tout Internet sont scannés et attaqués par force brute en quelques minutes ; la solution consiste à réduire la surface d'attaque : restreindre l'ingress du security group à des CIDR d'administration connus ou au VPN, ou supprimer entièrement l'entrant à l'aide d'un bastion ou de SSM Session Manager. Déplacer SSH sur un port non standard est une sécurité par l'obscurité que les scanners contournent trivialement. Un mot de passe plus fort ne réduit pas la surface exposée et n'arrête pas le credential stuffing. Se fier à un pare-feu hôte ignore la surface d'attaque que le security group annonce ouvertement à Internet.

Des données clients publiques constituent une exposition active : remédiez d'abord à l'accès en activant Block Public Access et en corrigeant la politique du bucket et la politique IAM pour stopper la fuite en cours. Récupérez ensuite les journaux d'accès (S3 server access logs / événements de données CloudTrail) pour évaluer ce qui a réellement été atteint, puis déclenchez les processus de violation et de notification prévus par la politique. Créer un ticket pour le prochain sprint laisse des données réglementées exposées pendant des jours. Copier les données ailleurs crée une seconde copie mais laisse le bucket d'origine ouvert. Renommer ne change rien à ses permissions.

Les secrets doivent vivre dans un magasin géré avec contrôle d'accès, audit et rotation, injectés au runtime — jamais versionnés. Utilisez un gestionnaire de secrets (AWS Secrets Manager, HashiCorp Vault) et retirez les valeurs versionnées de l'historique, puis faites-les tourner car elles doivent être considérées comme compromises. Le base64 est de l'encodage, pas une protection — n'importe qui peut le décoder. Un dépôt privé répand quand même le secret à tous ceux qui ont l'accès en clone, plus les systèmes CI et les forks. Le compiler dans le binaire ne fait que cacher un secret toujours trivial à extraire.

Une clé statique intégrée à une image fuit facilement et vit éternellement ; la solution consiste à éliminer entièrement l'identifiant à longue durée de vie : attachez un rôle IAM via un profil d'instance, qui fournit des identifiants temporaires automatiquement renouvelés sans rien d'intégré. Une rotation manuelle tous les 90 jours laisse quand même un secret à longue durée de vie dans l'AMI entre les rotations. Déplacer la clé vers une variable d'environnement ne la rend ni moins statique ni moins exposée. L'envoyer par e-mail à l'équipe ops répand l'exposition dans les boîtes mail et les archives.

Le changement manuel dans la console est une dérive de configuration : le prochain terraform apply peut annuler silencieusement le correctif, et le changement a aussi contourné la revue et l'audit. Réconciliez-le en codifiant le changement dans Terraform, en lançant plan/apply pour que le code et la réalité concordent, et en ajoutant des garde-fous contre les modifications ad hoc dans la console (accès console au moindre privilège, SCP, détection de dérive). Ne rien faire laisse une mine pour le prochain apply. Supprimer l'état Terraform est destructeur et peut orpheliner ou dupliquer des ressources. Abandonner Terraform sacrifie reproductibilité, revue et pistes d'audit.

Un rôle d'instance surprivilégié transforme la moindre faille applicative — notamment une SSRF atteignant le service de métadonnées d'instance — en prise de contrôle complète du compte, car l'attaquant hérite des identifiants du rôle. Remplacez le wildcard par les seules actions et ARN de ressources réellement utilisés par la charge de travail, et imposez IMDSv2 pour durcir le point de terminaison de métadonnées. Un VPC ne contraint en rien l'IAM. Une seule règle de refus relève du jeu de la taupe et laisse tout le reste autorisé. Un répartiteur de charge n'a aucun rapport avec la portée d'impact de l'identifiant.

Considérez tout secret poussé comme grillé : révoquez-le et faites-le tourner d'abord, car les bots scrutent les commits publics en quelques secondes, puis examinez CloudTrail pour détecter un abus et purgez-le de l'historique. Supprimer le commit ne sert à rien — la clé est déjà clonée, forkée et mise en cache par des tiers. Rendre le dépôt privé laisse une clé déjà divulguée et active aux mains des attaquants. Ajouter le fichier au .gitignore ne change rien à un secret déjà commité.

La chaîne d'approvisionnement LLM couvre les modèles de base, les variantes fine-tunées, les jeux de données, les embeddings, les plugins, les bibliothèques et la plateforme d'hébergement — chacun un endroit où introduire du risque. Les menaces incluent le téléchargement de poids de modèle altérés ou avec backdoor, des fine-tunes malveillants, des jeux de données empoisonnés ou à la licence viciée, des plugins vulnérables ou sur-permissionnés et des dépôts de modèles typosquattés. Défenses : sourcer les modèles depuis des registres de confiance, vérifier l'intégrité et la provenance, maintenir un AI bill of materials, scanner et épingler les dépendances, vérifier les plugins et appliquer le moindre privilège à tout ce que le modèle intègre.

Partez d'une image de base minimale et de confiance (distroless ou slim) pour réduire la surface d'attaque, analysez les images à la recherche de CVE connues dans la CI et dans le registre, épinglez et vérifiez les empreintes (digests) des images, exécutez avec un utilisateur non-root et évitez d'intégrer des secrets. Signez les images et imposez des politiques d'admission pour que seules les images analysées et signées s'exécutent. Reconstruisez régulièrement pour que les couches de base corrigées se propagent.

Le chiffrement en transit (TLS) protège les données circulant sur le réseau contre l'écoute et l'altération ; imposez TLS partout et rejetez le texte clair. Le chiffrement au repos protège les données stockées sur les disques et les sauvegardes, généralement via des clés gérées par KMS utilisant le chiffrement par enveloppe. Les deux sont des contrôles de base, mais aucun n'arrête une requête autorisée mais malveillante — le service déchiffre de manière transparente pour les appelants valides — donc le contrôle d'accès reste primordial.

Un utilisateur est une identité à longue durée de vie avec des identifiants permanents ; un rôle est une identité sans identifiants permanents que tout principal de confiance peut assumer pour obtenir des jetons à courte durée de vie ; une politique est le document JSON qui accorde des permissions, attaché à l'un ou l'autre. Le moindre privilège consiste à préférer les rôles aux utilisateurs, à restreindre les politiques à des actions et ressources précises, et à n'accorder que ce dont une tâche a besoin — puis à réviser et élaguer au fil du temps.

IMDS est un point d'accès link-local (169.254.169.254) qui fournit à une instance ses métadonnées, dont les identifiants temporaires de son rôle IAM attaché. La SSRF peut tromper le serveur pour qu'il récupère cette URL et fasse fuiter ces identifiants. IMDSv2 exige un PUT pour obtenir un jeton de session à courte durée de vie, définit une limite de saut (hop limit) / TTL IP par défaut de 1, et rejette les requêtes avec certains en-têtes — si bien qu'un simple GET de SSRF ne peut plus l'atteindre.

Le RBAC contrôle ce que les identités peuvent faire sur l'API Kubernetes — les Roles et ClusterRoles accordent des verbes sur des ressources, liés à des sujets via des RoleBindings — et doit suivre le moindre privilège, en évitant cluster-admin et les wildcards. Les politiques réseau contrôlent le trafic pod-à-pod, qui est autorisé par défaut jusqu'à ce que vous appliquiez un default-deny puis permettiez explicitement les flux requis. Ensemble, ils limitent le rayon d'impact si un pod ou un jeton est compromis.

CloudTrail enregistre chaque appel API dans le compte — qui a fait quoi, quand, d'où — vous donnant la piste d'audit faisant autorité pour les investigations et la conformité. GuardDuty est un service géré de détection des menaces qui analyse CloudTrail, les flux VPC et les journaux DNS pour faire remonter des découvertes comme l'exfiltration d'identifiants ou le minage de cryptomonnaie. CloudTrail est la source de vérité que vous devez protéger ; GuardDuty transforme cette télémétrie en alertes exploitables.

Les erreurs classiques sont des ACL publiques ou des politiques de bucket autorisant un accès anonyme ou à tous les utilisateurs AWS, des principaux trop larges ou des actions avec wildcard, l'absence de chiffrement par défaut et l'absence de journalisation. On les évite en activant le Block Public Access au niveau du compte, en utilisant des politiques IAM/bucket selon le moindre privilège, en imposant le chiffrement par défaut et TLS, et en activant la journalisation des accès et des règles Config pour détecter les dérives.

Stockez les secrets dans un service géré dédié (Secrets Manager, Parameter Store, Vault), chiffrés avec une clé KMS, et accordez l'accès via des rôles IAM pour que les charges de travail les récupèrent à l'exécution avec des identifiants à courte durée de vie. N'intégrez jamais de secrets dans le code, les images de conteneurs ou des fichiers .env versionnés. Ajoutez une rotation automatique, des politiques de clé restreintes et une journalisation d'audit pour que chaque récupération soit traçable.

Les security groups sont des pare-feux à état attachés aux instances/ENI : ils n'ont que des règles d'autorisation, et le trafic de retour d'un flux autorisé est automatiquement permis. Les network ACL sont des filtres sans état à la frontière du sous-réseau : ils ont des règles ordonnées d'autorisation et de refus, et vous devez autoriser explicitement le trafic de retour sur les ports éphémères. Les security groups sont le contrôle principal ; les NACL ajoutent des garde-fous grossiers au niveau du sous-réseau, comme bloquer une plage d'IP.

Le fournisseur sécurise le cloud lui-même — centres de données physiques, matériel, hyperviseur et services gérés qu'il exploite. Vous sécurisez ce que vous mettez dans le cloud — vos données, identités, configurations, l'application des correctifs OS le cas échéant, et les contrôles d'accès. La frontière exacte se déplace : avec l'IaaS vous possédez l'OS et au-dessus, avec le SaaS vous possédez surtout les données et l'accès.

La CI/CD est de grande valeur car elle détient les identifiants de déploiement et exécute du code non fiable. Les risques incluent les dépendances et actions de build compromises, les secrets divulgués ou trop larges, les actions tierces mutables, et les runners ou la confiance OIDC surprivilégiés. Réduisez-les avec des dépendances épinglées et vérifiées, une fédération OIDC à courte durée de vie au lieu de clés à longue durée de vie, le moindre privilège restreint à des dépôts/branches précis, des runners éphémères isolés, et des artefacts signés à provenance tracée (SLSA).

La signature lie cryptographiquement un artefact à son producteur, afin que les consommateurs puissent vérifier qu'il n'a pas été altéré ou substitué. La provenance est une métadonnée signée décrivant comment, où et à partir de quelle source l'artefact a été construit. Ensemble — via des outils comme Sigstore pour la signature sans clé et le framework SLSA pour les niveaux de provenance — ils permettent à un déployeur de vérifier qu'une image provient du pipeline et de la source attendus, déjouant l'altération et les attaques par substitution de dépendances.

Analysez les images pour les CVE connues dans les paquets OS et les bibliothèques applicatives, ainsi que les mauvaises configurations et les secrets intégrés, à la fois au moment du build et en continu dans le registre — car de nouvelles CVE apparaissent après la construction d'une image. Utilisez des images de base minimales ou distroless pour réduire la surface d'attaque, épinglez et référencez les images de base par empreinte, et exécutez le conteneur en non-root. L'analyse est nécessaire mais ne remplace pas la protection à l'exécution.

L'analyse IaC analyse statiquement les définitions Terraform, CloudFormation, Kubernetes et similaires par rapport à une politique pour détecter les mauvaises configurations — buckets S3 publics, groupes de sécurité ouverts, chiffrement manquant — avant même leur provisionnement. Parce que le même modèle provisionne de nombreuses ressources, le corriger une fois évite la dérive répétée, et le détecter avant l'application est bien moins coûteux que de remédier à des ressources cloud actives. Les outils incluent Checkov, tfsec et KICS, idéalement appliqués comme barrières policy-as-code.

Traitez le pipeline comme une infrastructure de production : il détient les identifiants pour livrer le code et atteindre la prod, donc le compromettre contourne tous les contrôles en aval. Durcissez-le avec des runners isolés et éphémères ; des tokens à privilège minimal et courte durée (fédération OIDC au lieu de secrets à longue durée) ; des branches protégées et une config de pipeline revue ; des actions tierces épinglées par empreinte ; et une journalisation d'audit complète. Le pipeline est une cible de premier ordre, pas de la tuyauterie.

Le moindre privilège signifie que chaque utilisateur, processus et service ne reçoit que l'accès minimal requis pour sa tâche, et rien de plus. Cela limite le rayon d'impact d'un compte compromis, réduit le risque de menace interne et diminue la surface d'attaque. On l'applique via l'accès basé sur les rôles, des revues d'accès régulières et l'élévation juste-à-temps.

L'accès conditionnel fait dépendre la décision d'accès du contexte plutôt que d'une règle fixe. Il évalue des signaux — qui est l'utilisateur, la conformité de l'appareil, la localisation, l'application et un score de risque calculé par détection d'anomalies — et répond proportionnellement : autoriser, bloquer ou exiger un renforcement comme la MFA ou un appareil conforme. L'accès basé sur le risque est la variante dynamique où un signal de risque en temps réel pilote la politique.

La fédération d'identités établit une relation de confiance entre un fournisseur d'identité (IdP) qui authentifie les utilisateurs et des fournisseurs de services (parties de confiance) qui consomment cette authentification. L'IdP vérifie l'utilisateur et émet une assertion ou un jeton signé ; le fournisseur de services lui fait confiance au lieu de gérer ses propres identifiants. Cela permet le SSO inter-domaines et un contrôle centralisé, mais concentre le risque : compromettez l'IdP et vous compromettez tout ce qui lui fait confiance.

L'accès juste-à-temps accorde des privilèges élevés uniquement quand c'est nécessaire, pour une durée limitée, généralement avec approbation — puis ils expirent automatiquement, de sorte qu'il n'y a aucun privilège permanent à voler. Les comptes bris de glace sont l'exception délibérée : des comptes d'urgence très privilégiés, normalement dormants, verrouillés derrière des contrôles stricts et de fortes alertes, utilisés uniquement quand les chemins d'accès normaux échouent. Le JIT réduit la surface d'attaque quotidienne ; le bris de glace garantit que vous pouvez encore entrer en cas de crise.

Le RBAC accorde des permissions via des rôles assignés aux utilisateurs — simple à raisonner mais sujet à l'explosion des rôles à mesure que les cas particuliers se multiplient. L'ABAC évalue des politiques sur les attributs de l'utilisateur, de la ressource, de l'action et de l'environnement, ce qui permet des décisions fines et contextuelles au prix de la complexité. La plupart des systèmes matures les combinent : des rôles pour les octrois grossiers, des attributs et des politiques pour les détails conditionnels.

SCIM (System for Cross-domain Identity Management) est une API REST/JSON et un schéma standard pour créer, mettre à jour et supprimer des comptes utilisateurs entre applications. Relié à un système RH ou à un IdP, il automatise le cycle de vie joiner-mover-leaver : les comptes et droits sont provisionnés à l'embauche, ajustés au changement de poste, et — surtout — déprovisionnés au départ, éliminant les comptes orphelins que les attaquants adorent.

Le Zero Trust abandonne l'hypothèse selon laquelle être à l'intérieur du réseau vous rend digne de confiance. Chaque requête vers une ressource est authentifiée et autorisée pour elle-même — en vérifiant l'identité, l'état de santé de l'appareil et le contexte — par un point de décision de politique, accordant un accès au moindre privilège par session. Il n'y a pas de zone interne de confiance ; l'emplacement réseau d'une requête n'est qu'un signal, pas un laissez-passer.

La modélisation des menaces répond à quatre questions : que construisons-nous, qu'est-ce qui peut mal tourner, qu'allons-nous y faire, et avons-nous bien fait le travail. Vous schématisez le système (souvent un diagramme de flux de données avec frontières de confiance), énumérez les menaces avec un framework comme STRIDE, priorisez par risque et assignez des mitigations. PASTA ajoute une saveur centrée sur le risque et l'attaquant ; les arbres d'attaque décomposent un seul objectif. Le faire au moment de la conception est bien moins coûteux que de patcher la production.

La gestion des vulnérabilités est une boucle continue : découvrir les actifs et vulnérabilités (scan, inventaire d'actifs), prioriser selon le risque réel (CVSS plus exploitabilité, exposition et criticité des actifs — des frameworks comme EPSS et SSVC aident), remédier ou atténuer, vérifier la correction et rapporter sur les tendances et les SLA. Le scan est la partie facile ; la discipline est de prioriser et de boucler la boucle pour que le risque baisse réellement avec le temps.

Ne jamais coder en dur les secrets dans le code source ni les committer dans git. Les stocker dans un gestionnaire de secrets ou un coffre-fort dédié, les injecter à l'exécution, restreindre l'accès au moindre privilège, les faire tourner régulièrement, et préférer des identifiants dynamiques à courte durée de vie aux identifiants statiques persistants. Auditer chaque accès.

Le SSRF pousse un serveur à effectuer des requêtes HTTP (ou autres) vers une destination choisie par l'attaquant, en abusant de la position réseau du serveur pour atteindre des services internes derrière le pare-feu. Dans le cloud, c'est particulièrement grave car le service de métadonnées d'instance (par exemple 169.254.169.254) peut renvoyer des identifiants IAM, transformant un SSRF en compromission du compte cloud.