Questions d'entretien Cloud Security Engineer

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.

Non. Le NAT (et le PAT) associe des adresses privées à une IP publique et, par effet de bord, rejette les connexions entrantes non sollicitées car aucune correspondance n'existe pour elles. Ce n'est pas une politique de sécurité — pas d'inspection, pas de règles, pas de journalisation — et la traversée de NAT, le hole punching et le C2 initié en sortie passent sans problème. Le NAT est un outil d'adressage ; il vous faut un vrai pare-feu. « NAT = pare-feu » est l'idée fausse.

Un modèle tiers est une dépendance de chaîne d'approvisionnement : vérifiez qu'il provient d'une source de confiance avec des sommes de contrôle/signatures correspondantes, que sa licence autorise votre usage, et que le format de fichier n'exécute pas de code arbitraire au chargement (préférez une sérialisation sûre aux formats de type pickle). « Il se charge » et « la vitesse de téléchargement » ne disent rien de la confiance, et supposer que les modèles publics sont sûrs ignore les risques réels d'empoisonnement et de désérialisation.

SSLv3, TLS 1.0 et RC4 sont cassés ou obsolètes et permettent des attaques par rétrogradation et déchiffrement ; désactivez-les donc et exigez TLS 1.2 ou 1.3 avec des suites de chiffrement robustes et à confidentialité persistante, en acceptant la rare perte de très vieux clients. Les laisser actifs par compatibilité maintient la faiblesse exploitable. Ajouter un second certificat ou passer à un certificat auto-signé ne supprime pas les protocoles faibles, et l'auto-signé nuit à la confiance sans corriger la cryptographie.

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é.

Comme les pare-feu évaluent les règles de haut en bas, une large règle any/any près du haut court-circuite toutes les règles en dessous et autorise tout le trafic — le pare-feu cesse en pratique d'imposer quoi que ce soit. Remplacez-la par des règles explicites de moindre privilège pour les flux réellement nécessaires, ordonnées pour que les autorisations et refus spécifiques prennent effet, et terminez par un refus par défaut. La qualifier d'efficace est faux, la déplacer en bas peut encore masquer le refus par défaut, et la renommer ne change rien à ce qu'elle autorise.

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.

Moindre privilège plus accès juste-à-temps : accordez le minimum de permissions nécessaires, limité dans le temps et journalisé, pour que le débogage soit possible sans admin permanent devenant un risque durable et un angle mort d'audit. Un cluster-admin permanent viole le moindre privilège et élargit le rayon d'impact de toute compromission. Un refus total bloque le travail légitime et invite à des contournements parallèles risqués. Partager l'identifiant commun du compte de service admin détruit la responsabilité — les actions ne sont plus rattachables à une personne.

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é.

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).

L'application redirige l'utilisateur vers le serveur d'autorisation pour se connecter et consentir. Le serveur redirige avec un code d'autorisation de courte durée. Le backend de l'application échange ensuite ce code (plus son secret client) au point de terminaison de jeton contre un jeton d'accès, via un canal arrière de serveur à serveur. Cela garde les jetons hors du navigateur/de l'URL. Les clients publics ajoutent PKCE pour lier le code au demandeur initial.

Le SSO centralise l'authentification chez un fournisseur d'identité (IdP). Quand un utilisateur visite un fournisseur de service (l'application), l'application redirige vers l'IdP ; l'utilisateur se connecte une fois, et l'IdP renvoie une assertion ou un jeton signé attestant son identité. SAML porte cela comme une assertion XML signée ; OIDC le porte comme un jeton d'identité JSON signé posé sur OAuth 2.0. L'application fait confiance à la signature de l'IdP plutôt que de gérer elle-même les mots de passe.

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.

Un SBOM est un inventaire lisible par machine de chaque composant, bibliothèque et dépendance d'un logiciel, avec les versions et idéalement les empreintes (hashes). Il est important car lorsqu'une nouvelle vulnérabilité apparaît, vous pouvez interroger vos SBOM pour répondre instantanément à « sommes-nous affectés et où ? » au lieu de paniquer. Les deux standards dominants sont SPDX et CycloneDX, et les SBOM sont de plus en plus exigés par la réglementation et les achats.

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.

La MFA exige au moins deux facteurs d'authentification de catégories différentes — quelque chose que vous savez (mot de passe), quelque chose que vous possédez (téléphone/jeton), quelque chose que vous êtes (biométrie). Elle aide car un attaquant qui vole un facteur, comme un mot de passe, ne peut toujours pas se connecter sans les autres. La MFA résistante à l'hameçonnage comme FIDO2 est la plus forte.

Un pare-feu contrôle le trafic entre zones réseau en l'autorisant ou en le refusant selon des règles. Un pare-feu sans état évalue chaque paquet isolément par rapport aux règles ; un pare-feu à état suit l'état des connexions pour autoriser le trafic de retour des sessions qu'il a permises. Les pare-feu nouvelle génération ajoutent la connaissance de la couche applicative.

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.

Gardez les jetons d'accès à courte durée de vie (quelques minutes) pour qu'un jeton volé expire vite, et utilisez des jetons de rafraîchissement à plus longue durée pour obtenir de nouveaux jetons d'accès sans re-solliciter l'utilisateur. Faites tourner les refresh tokens à chaque utilisation et détectez la réutilisation d'un jeton consommé comme un signal de vol, en révoquant la chaîne. L'objectif est d'équilibrer la limitation de la fenêtre d'un jeton compromis sans forcer les utilisateurs à se réauthentifier sans cesse.

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.

Réduire la surface d'attaque (supprimer paquets et services inutilisés), imposer SSH par clé uniquement sans connexion root, maintenir le système à jour, exécuter un pare-feu en deny-par-défaut n'exposant que les ports nécessaires, appliquer le moindre privilège via sudo et les permissions de fichiers, activer auditd et la journalisation centralisée, et ajouter la surveillance d'intégrité ainsi qu'un MAC comme SELinux ou AppArmor.

Le moindre privilège signifie que chaque utilisateur, processus ou service ne reçoit que l'accès minimal nécessaire à sa tâche, et rien de plus. Cela réduit le rayon d'impact de toute compromission ou erreur. On l'applique avec l'accès basé sur les rôles, l'élévation juste-à-temps, des revues d'accès régulières et la suppression des droits administrateurs permanents.

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.

Imposer TLS partout, authentifier chaque requête (par exemple des jetons OAuth2/OIDC) et autoriser par objet pour que les utilisateurs n'atteignent que leurs propres données. Ajouter la validation des entrées, la limitation de débit et les quotas, la validation de schéma et une journalisation approfondie. La faille d'API la plus courante est l'autorisation au niveau objet défaillante, vérifiez donc la propriété à chaque accès à une ressource.

La segmentation divise un réseau en zones isolées pour qu'une intrusion dans l'une ne puisse pas atteindre librement les autres, limitant le mouvement latéral. Le zero trust va plus loin : il supprime entièrement la confiance implicite fondée sur l'emplacement réseau, en authentifiant et autorisant chaque requête où qu'elle provienne — la microsegmentation est l'un des moyens de l'implémenter.

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.