Questions d'entretien Security Architect

Non. On ne peut pas comparer la longueur brute des clés entre familles d'algorithmes différentes. En raison de la manière dont les mathématiques sous-jacentes de chacun durcissent, une clé sur courbe elliptique de 256 bits offre à peu près la même sécurité qu'une clé RSA de 3072 bits — environ 128 bits de force, selon le NIST. Plus gros n'est pas simplement plus solide : l'ECC atteint une force équivalente avec des clés bien plus petites, d'où sa préférence dans les systèmes modernes. Au sein d'un même algorithme, des clés plus longues aident, jusqu'à un certain point.

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.

Pas nécessairement. Double-chiffrer avec le même algorithme ne double pas simplement la sécurité — le résultat classique est que le 2DES n'ajoute qu'environ un bit de force effective à cause des attaques par rencontre au milieu (meet-in-the-middle), d'où l'existence du 3DES. Plus important, les schémas multicouches faits maison tendent à introduire des bugs d'implémentation qui affaiblissent l'ensemble. Utilisez plutôt un seul chiffrement authentifié éprouvé (AES-GCM) avec une gestion de clés saine.

Une autonomie sans limites associée à l'accès aux outils, c'est l'« agence excessive » d'OWASP LLM : un modèle manipulé ou en erreur peut entreprendre des actions destructrices. Encadrez-le avec des outils au moindre privilège, exigez une confirmation humaine pour les opérations irréversibles, et gardez des permissions restreintes et auditées. Lui faire confiance ou lui donner les droits admin élargit le rayon d'impact, et masquer un bouton dans l'interface ne change rien à la capacité sous-jacente du modèle à appeler l'action.

Le contenu non fiable que le modèle ingère peut porter des instructions — c'est l'injection de prompt indirecte. Vous ne pouvez pas empêcher totalement le modèle d'être influencé, alors isolez le contenu récupéré en tant que donnée, limitez les outils/permissions de l'agent, exigez une confirmation pour les actions sensibles, et évitez de lui confier des secrets qu'il pourrait être contraint de divulguer. Supposer que le modèle ignorera simplement les instructions injectées, c'est exactement le mode de défaillance exploité.

Envoyer des données personnelles de clients à une API externe les expose au traitement et à la conservation d'un tiers et peut enfreindre des obligations de confidentialité. Minimisez et anonymisez ce qui est envoyé, confirmez les conditions d'usage/conservation du fournisseur et un accord de traitement des données (ou des garanties de non-entraînement), ou passez à un déploiement privé pour les données sensibles. La longueur de la clé n'a aucune importance, et envoyer plus de données personnelles augmente l'exposition.

Si la récupération extrait n'importe quel document indexé quelle que soit la personne qui interroge, le modèle restituera fidèlement des données que l'utilisateur ne devrait pas voir — c'est une faille d'autorisation, pas une hallucination. Imposez les permissions de l'utilisateur au niveau du document au moment de la récupération, pour que seuls les fragments autorisés entrent dans le contexte. Un prompt système plus long est contournable et n'implémente aucun contrôle d'accès, la température n'a aucun rapport, et un autre modèle présente la même faille.

S'entraîner sur des données utilisateurs non vérifiées permet à un attaquant d'empoisonner le modèle — en y implantant des portes dérobées, des déclencheurs ou un comportement biaisé qui surgit plus tard. Maîtrisez-le par la vérification et le filtrage des données, le suivi de provenance, la détection d'anomalies sur le jeu de données et l'évaluation du comportement du modèle après l'entraînement. « Plus de données, c'est mieux » ignore l'intégrité, et le vrai souci est l'empoisonnement, pas la vitesse ni l'espace disque.

Un traitement incohérent traduit généralement l'absence de définition partagée de la sensibilité ; le contrôle fondamental est donc un schéma de classification des données (par ex. public/interne/confidentiel/restreint) avec des exigences définies de traitement, de stockage et de partage par niveau, permettant aux équipes d'appliquer des contrôles proportionnés. Ne rien chiffrer « pour faire simple » ou traiter toutes les données comme publiques retire la protection aux données qui en ont besoin. Supprimer toutes les données de plus d'un jour détruit des enregistrements dont l'entreprise et la loi ont besoin. Seul un schéma de classification aligne la force des contrôles sur la sensibilité réelle des données.

Le périmètre PCI DSS couvre les systèmes qui stockent, traitent ou transmettent les données de titulaires de cartes, plus tout système qui leur est connecté ou peut les affecter ; une segmentation réseau efficace isole donc l'environnement des données de cartes (CDE) et exclut du périmètre les systèmes sans rapport, réduisant coût, effort et risque. Chiffrer tous les serveurs ne définit aucune frontière et les systèmes connectés restent dans le périmètre ; ajouter des pare-feu partout sans cible n'est pas de la segmentation si cela ne restreint ni ne valide les flux de données ; et cesser de lire les numéros de carte à voix haute relève de l'hygiène, pas d'un contrôle de périmètre. La réponse systémique est de maîtriser où vivent les données de cartes et ce qui peut les atteindre.

Un rapport SOC 2 ne vous rassure que si vous le lisez vraiment : confirmez le bon type (le Type II teste l'efficacité opérationnelle dans la durée, le Type I seulement la conception à un instant donné), vérifiez le périmètre et les critères des services de confiance couverts, que la période est récente et sans trou, l'opinion rendue par l'auditeur (sans réserve ou avec réserve), et examinez les exceptions relevées ainsi que les contrôles complémentaires de l'entité utilisatrice (CUEC) qui vous incombent. Se contenter de constater que le rapport existe — ou le juger à son logo de couverture ou à son nombre de pages — ne dit rien de l'efficacité réelle des contrôles du fournisseur ni de vos obligations résiduelles.

L'injection de prompt ne se résout pas entièrement avec plus de texte ; supposez que le modèle peut être détourné et contraignez ce qu'il est autorisé à FAIRE. Donnez aux outils le moindre privilège, conditionnez les actions à fort impact à une confirmation humaine, et validez ou isolez les appels d'outils avant d'agir (OWASP LLM « excès d'autonomie » et « gestion inadéquate des sorties »). Implorer dans le prompt système est contournable. Une température plus élevée n'ajoute que de l'aléa, et la seule journalisation enregistre le dommage sans empêcher l'action injectée.

Équilibrez utilisabilité et risque : imposez un accès conditionnel lié à la posture de l'appareil et isolez les données d'entreprise dans un conteneur géré (MAM/MDM) afin de les contrôler et de les effacer sélectivement sans prendre la main sur tout l'appareil personnel. Un accès illimité risque la fuite sur des terminaux non gérés, possiblement compromis. Une interdiction pure et simple pousse aux contournements non sûrs comme le transfert vers une messagerie personnelle. Et envoyer les données en pièces jointes les disperse de façon incontrôlable sur des appareils que vous ne récupérerez jamais.

Aucun produit unique n'arrête toutes les attaques ; une sécurité mature superpose des contrôles indépendants — la défense en profondeur — pour que la défaillance de l'un ne signifie pas la compromission. Cartographiez la dépense proposée par rapport aux véritables lacunes en identité, réseau, poste de travail, données et détection, et conservez les contrôles complémentaires qui fonctionnent déjà. Tout miser sur un seul outil crée un point unique de défaillance, et arracher les contrôles existants pour les remplacer réduit la couverture. Ne rien dépenser du tout ignore de vraies lacunes.

Le chiffrement au repos ne défend qu'une seule menace — le vol physique ou de disque — et n'apporte rien contre une application compromise, des identifiants volés ou un trafic intercepté, car la base déchiffre de façon transparente pour toute requête autorisée. Une conception saine exige aussi du TLS en transit, une authentification et une autorisation fortes, et une gestion des clés avec séparation des tâches. Doubler le chiffrement au repos ajoute du coût sans changer le modèle de menace, et ne chiffrer que les sauvegardes laisse les données en production et leurs chemins d'accès exposés.

Si la clé réside avec le texte chiffré, quiconque vole la base obtient les deux ; le chiffrement ne protège donc rien — c'est une serrure avec la clé scotchée dessus. Les clés doivent être gérées dans un KMS ou HSM dédié, séparées des données, avec contrôle d'accès strict, rotation et séparation des tâches. Hacher la clé la rend à sens unique et inutile pour le déchiffrement, et stocker des copies supplémentaires au même endroit ne fait que multiplier l'exposition au lieu de la réduire.

La modélisation des menaces est la moins coûteuse et la plus efficace à la conception, avant que le code ne fige les décisions : parcourez les flux de données, énumérez les menaces avec un cadre comme STRIDE, intégrez les mesures, puis révisez à mesure que la conception évolue. La faire seulement après un incident ou au pentest annuel révèle les problèmes une fois qu'ils sont coûteux à corriger et déjà exposés. Et se fier à des « développeurs prudents » est un espoir, non un contrôle reproductible et auditable.

Transmettre des données personnelles à un tiers étend votre périmètre de confiance ; menez donc d'abord une évaluation de sécurité du fournisseur — traitement des données, chiffrement, contrôles d'accès, certifications comme SOC 2 / ISO 27001, sous-traitants, modalités de notification de violation — et signez un accord de traitement des données (DPA) avant tout transfert. Un contrat de prix ou la parole verbale d'un commercial n'est pas une diligence raisonnable. Et un « site web soigné » ne dit rien sur la façon dont le fournisseur protège réellement les données ; vous en restez responsable.

La confiance fondée sur l'emplacement réseau signifie qu'un seul point d'appui à l'intérieur ouvre un large déplacement latéral — un identifiant VPN hameçonné et l'attaquant est « à l'intérieur ». Le zero trust supprime la confiance implicite : chaque accès est authentifié, autorisé et réévalué en continu selon l'identité et la posture de l'appareil, avec moindre privilège et segmentation (NIST SP 800-207). Un second VPN ou un VPN élargi ne fait qu'étendre le même problème de confiance plate, et faire confiance au LAN plutôt qu'au VPN répète l'erreur initiale.

Quand on ne peut pas remédier, on gère le risque : réduire l'exposition par des contrôles compensatoires (segmentation réseau, restriction des accès, surveillance renforcée), quantifier le risque résiduel et faire accepter formellement ce risque par le propriétaire métier responsable, avec une date de revue définie. Un arrêt unilatéral outrepasse l'autorité du RSSI et nuit à l'entreprise. L'ignorer parce qu'il est non corrigeable est une négligence. L'omettre du registre des risques masque la responsabilité, rompt la piste d'audit et signifie que personne n'assume officiellement la décision.

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.

Les réseaux plats permettent à un seul appareil invité compromis d'atteindre directement les systèmes les plus précieux. Segmentez par niveau de confiance et appliquez un trafic à moindre privilège entre les zones pour contenir et surveiller les déplacements latéraux. Un pare-feu de bordure ne fait rien pour le trafic est-ouest entre des hôtes déjà à l'intérieur. Re-adresser les serveurs financiers est de la sécurité par l'obscurité qu'un simple scan déjoue. L'antivirus est une couche de détection, pas un substitut au contrôle architectural d'isolement des systèmes sensibles.

L'IA aide le SOC en triant et dédupliquant les alertes, en résumant les incidents, en enrichissant le contexte, en rédigeant des détections et en accélérant l'intégration des analystes — réduisant la fatigue et le temps de présence. Les risques : conclusions hallucinées ou fausses avec assurance, biais d'automatisation où les analystes cessent de vérifier, prompt injection via des données de logs ou d'alertes contrôlées par l'attaquant, fuite de données sensibles vers des modèles tiers, et adversaires utilisant les mêmes outils. Gardez un humain dans la boucle, vérifiez les sorties et isolez les entrées non fiables.

La prompt injection directe, c'est quand un utilisateur tape des instructions adverses directement dans le prompt pour écraser le system prompt ou les règles de sécurité. La prompt injection indirecte cache des instructions malveillantes dans du contenu externe que le modèle ingère ensuite — une page web, un e-mail, un PDF ou un document RAG — si bien que l'attaque se déclenche sans que la victime ne la tape jamais. L'injection indirecte est le plus grand risque parce que l'attaquant et la victime sont des personnes différentes, et que la charge arrive via des données que l'application fait implicitement confiance.

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.

Le NIST AI Risk Management Framework (AI RMF 1.0) est un cadre volontaire et fondé sur le risque pour gouverner une IA digne de confiance tout au long de son cycle de vie. Son cœur est constitué de quatre fonctions : Govern (culture, politique, responsabilité — et elle traverse les autres), Map (contexte et identification des risques), Measure (évaluer et suivre les risques) et Manage (prioriser et répondre). Il définit aussi des caractéristiques de fiabilité — valide et fiable, sûr, sécurisé et résilient, responsable et transparent, explicable, respectueux de la vie privée et équitable. Il complète des listes techniques comme l'OWASP LLM Top 10 au niveau du programme.

L'OWASP Top 10 for LLM Applications est la liste consensuelle des risques les plus critiques lorsqu'on construit avec de grands modèles de langage. L'édition 2025 couvre la prompt injection, la divulgation d'informations sensibles, la supply chain, l'empoisonnement des données et du modèle, le traitement non sécurisé des sorties, l'excessive agency, la fuite de system prompt, les faiblesses des vecteurs et embeddings, la désinformation et la consommation non bornée. Elle existe parce que les listes appsec traditionnelles ne capturent pas les modes de défaillance propres aux LLM, et elle donne aux équipes un vocabulaire commun et une checklist pour prioriser les contrôles.

La sécurité RAG, c'est traiter chaque document récupéré comme une entrée non fiable. Risques clés : prompt injection indirecte cachée dans le contenu récupéré, empoisonnement de la base de connaissances ou des embeddings, et absence d'autorisation par utilisateur si bien que le modèle renvoie des données auxquelles l'utilisateur n'a pas accès. Les défenses incluent le contrôle d'accès appliqué à la récupération, la provenance du contenu et la vérification à l'ingestion, traiter le texte récupéré comme des données et non des instructions, la validation des sorties et l'isolement du magasin de vecteurs par locataire.

Un agent LLM transforme du texte en actions via des outils et des function calls, donc une prompt injection devient une action réelle — le risque d'excessive agency. Sécurisez-le en donnant à chaque outil le moindre privilège et la portée dont il a besoin, en validant et contraignant les arguments d'outils, en exigeant une confirmation humaine pour les actions sensibles ou irréversibles, en sandboxant l'exécution, en limitant le débit et en budgétant les appels, et en journalisant chaque invocation d'outil. Ne laissez jamais la sortie du modèle, influencée par des données non fiables, autoriser directement une action à fort impact.

Les applis LLM divulguent des données de plusieurs façons : le modèle mémorise et restitue des données d'entraînement ou de fine-tuning sensibles, le system prompt (qui peut contenir des secrets ou de la logique) est extrait, des documents RAG récupérés exposent des données que l'utilisateur ne devrait pas voir, et le contexte d'un utilisateur ou d'une session déborde sur un autre. La prévention passe par la minimisation des données avant l'entraînement, ne jamais mettre de secrets dans les prompts, appliquer l'autorisation par utilisateur à la récupération, le filtrage des sorties et la rédaction de PII, et l'isolement par locataire.

L'empoisonnement des données d'entraînement, c'est quand un attaquant altère les données utilisées pour pré-entraîner, fine-tuner ou créer les embeddings d'un modèle afin que le modèle résultant se comporte de façon malveillante — en intégrant un déclencheur de backdoor, en injectant du biais ou en dégradant la précision. Il exploite le fait que les modèles aspirent et font confiance à de vastes jeux de données souvent issus du web. Les défenses incluent la curation et la signature des sources de données, les vérifications de provenance et d'intégrité, la détection d'anomalies sur les données d'entraînement, le versionnage des jeux de données, et la limitation de qui peut contribuer aux corpus d'entraînement et RAG.

DAC permet au propriétaire des données d'accorder l'accès à sa discrétion ; MAC applique l'accès de façon centralisée via des étiquettes/habilitations et est non discrétionnaire ; RBAC accorde l'accès via des rôles métier ; ABAC évalue des attributs (utilisateur, ressource, environnement) au regard d'une politique pour des décisions fines et contextuelles.

La continuité d'activité (BCP) est la stratégie globale visant à maintenir les fonctions métier critiques pendant et après une perturbation ; la reprise après sinistre (DRP) en est le sous-ensemble informatique qui restaure les systèmes et les données. Le RTO est le temps maximal tolérable pour rétablir une fonction ; le RPO est la perte de données maximale tolérable mesurée en temps.

La classification étiquette les données par sensibilité afin que l'organisation applique des contrôles proportionnés à la valeur et au risque, évitant à la fois la sous-protection et la surprotection coûteuse. Le propriétaire des données (un rôle métier) fixe la classification et accepte le risque, tandis que le dépositaire des données (souvent l'IT) met en œuvre et maintient les contrôles de protection.

La défense en profondeur superpose des contrôles multiples, variés et indépendants à travers les personnes, les processus et la technologie, afin que la défaillance d'un seul contrôle n'entraîne pas de compromission. Elle suppose que chaque contrôle finira par échouer et utilise la redondance et la variété pour ralentir, détecter et contenir un attaquant.

La due diligence est l'investigation et la compréhension continues des risques (savoir ce qu'il faut faire), tandis que la due care consiste à prendre les mesures raisonnables qu'une personne prudente prendrait pour y répondre (le faire réellement). La diligence est la recherche et la supervision ; la care est la mise en œuvre et le maintien.

La gestion du cycle de vie des identités encadre un compte de sa création à sa fin : attribution à l'arrivée (joiner), ajustement des droits lors d'un changement de rôle (mover), et suppression rapide au départ (leaver), avec des revues d'accès périodiques tout au long. Les défaillances les plus courantes sont l'accumulation de privilèges chez les movers et les comptes orphelins issus de suppressions manquées.

Une politique est l'énoncé obligatoire de haut niveau de l'intention de la direction ; une norme est une règle obligatoire et spécifique qui applique la politique (par exemple AES-256) ; une procédure est le mode opératoire obligatoire étape par étape ; une ligne directrice est une recommandation facultative. Les politiques, normes et procédures sont obligatoires, tandis que les lignes directrices sont discrétionnaires.

L'analyse quantitative attribue des valeurs monétaires concrètes pour calculer la perte attendue ; l'analyse qualitative classe le risque sur des échelles relatives (élevé/moyen/faible) par jugement d'expert. La quantitative utilise SLE = valeur de l'actif x facteur d'exposition, ARO = occurrences attendues par an, et ALE = SLE x ARO pour exprimer la perte annuelle attendue en euros.

Vous pouvez atténuer (réduire la probabilité/l'impact avec des contrôles), transférer (déplacer l'impact financier via une assurance ou des contrats), éviter (cesser entièrement l'activité risquée) ou accepter (tolérer sciemment le risque résiduel). Le choix dépend de l'appétit pour le risque et d'une comparaison coûts-bénéfices au regard de la perte attendue du risque.

Intégrez la sécurité à chaque phase du SDLC plutôt que de tester à la fin : les exigences incluent des exigences de sécurité et de confidentialité, la conception inclut la modélisation des menaces, le développement suit des normes de codage sécurisé avec SAST, les tests ajoutent DAST et des revues, et la mise en production nécessite une validation — le tout gouverné par la politique, la séparation des tâches et la gestion des changements. Corriger les failles tôt coûte nettement moins cher qu'après la mise en production.

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

Le client construit une chaîne du certificat serveur (feuille) en remontant par une ou plusieurs autorités de certification intermédiaires jusqu'à une autorité racine de son magasin de confiance. Il vérifie la signature de chaque certificat avec la clé publique de l'émetteur suivant, contrôle les dates de validité, la correspondance du nom/nom d'hôte, l'usage de la clé et la révocation (CRL/OCSP). La confiance se termine à une racine auto-signée pré-approuvée ; la chaîne n'est valide que si chaque maillon est correct.

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 défense en profondeur consiste à superposer plusieurs contrôles de sécurité indépendants afin que, si l'un échoue, les autres protègent encore l'actif. Elle suppose qu'aucun contrôle n'est parfait — par exemple en combinant pare-feu, segmentation réseau, protection des terminaux, MFA, moindre privilège et chiffrement, plutôt que de se fier au seul périmètre.

Les contrôles se classent de deux façons. Par type : administratif (politiques, formation, procédures), technique/logique (pare-feu, MFA, chiffrement) et physique (serrures, badges, caméras). Par fonction : préventif (empêcher un événement — MFA, contrôle d'accès), détectif (repérer un événement — SIEM, IDS, journaux d'audit), correctif (réparer après — restauration de sauvegarde, correctif), dissuasif (décourager — bannières d'avertissement) et compensatoire (une alternative quand le contrôle principal n'est pas faisable). La défense en profondeur superpose ces contrôles pour qu'aucune défaillance isolée ne mène à une compromission.

L'article 5 du GDPR pose sept principes : licéité/loyauté/transparence, limitation des finalités, minimisation des données, exactitude, limitation de la conservation, intégrité et confidentialité, et responsabilité. En cas de violation de données personnelles, le responsable du traitement doit notifier l'autorité de contrôle compétente sans retard injustifié et, si possible, dans les 72 heures après en avoir pris connaissance (article 33). Si la violation est susceptible d'engendrer un risque élevé pour les personnes, le responsable doit aussi notifier les personnes concernées sans retard injustifié (article 34).

La gouvernance est la façon dont la direction fixe le cap, définit la responsabilité et aligne la sécurité sur les objectifs métier — les politiques, les rôles et la supervision qui disent à quoi ressemble « le bon niveau ». La gestion des risques est le processus d'identification, d'évaluation, de traitement et de surveillance des menaces pesant sur ces objectifs. La conformité consiste à démontrer le respect des obligations — lois, règlements, contrats et politiques internes. La gouvernance pilote les décisions de risque ; le risque détermine les contrôles nécessaires ; la conformité prouve que ces contrôles répondent aux normes exigées. La conformité est un résultat d'une bonne GRC, pas un substitut à la sécurité.

HIPAA (la loi américaine Health Insurance Portability and Accountability Act) protège les Protected Health Information (PHI). La Privacy Rule encadre l'utilisation et la divulgation des PHI ; la Security Rule s'applique aux PHI électroniques (ePHI) et exige trois catégories de garanties — administratives, physiques et techniques. Elle s'applique aux covered entities (prestataires, régimes de santé, chambres de compensation) et aux business associates qui traitent des PHI pour leur compte, liés par des Business Associate Agreements. La Breach Notification Rule fixe les obligations de notifier les personnes, le HHS et parfois les médias.

ISO/IEC 27001 spécifie les exigences d'un Information Security Management System (ISMS) : un cadre descendant et fondé sur le risque, fait de politiques, de processus, de rôles et d'amélioration continue (Plan-Do-Check-Act) qui régit la manière dont une organisation gère la sécurité de l'information. L'Annexe A est un catalogue de contrôles de référence. On ne les applique pas tous aveuglément — on mène une analyse des risques, on décide quels contrôles sont nécessaires, et on documente les décisions d'inclusion/exclusion avec justification dans une Statement of Applicability (SoA).

Le NIST Cybersecurity Framework organise les résultats de cybersécurité en fonctions principales. Dans le CSF 2.0, il y en a six : Govern (la nouvelle fonction faîtière pour la stratégie, les rôles, les décisions de risque et la supervision), Identify (comprendre les actifs et les risques), Protect (garanties pour limiter l'impact), Detect (repérer les événements), Respond (agir sur les incidents) et Recover (restaurer les capacités). Elles ne sont pas strictement séquentielles — elles fonctionnent en continu et décrivent ensemble un cycle de vie complet de gestion du cyber-risque.

PCI DSS (Payment Card Industry Data Security Standard) est une norme de sécurité maintenue par le PCI Security Standards Council qui s'applique à toute organisation qui stocke, traite ou transmet des données de titulaires de cartes. Elle s'organise autour d'objectifs de contrôle couvrant un réseau sécurisé, la protection des données stockées, la gestion des vulnérabilités, un contrôle d'accès fort, la surveillance/les tests et une politique de sécurité de l'information. Le périmètre est tout ce qui se trouve dans le cardholder data environment (CDE) — donc la segmentation, la tokenisation et le fait de ne pas stocker de données inutiles sont les principaux moyens de le réduire.

Traitez la sensibilisation comme un changement de comportement, pas comme une case à cocher annuelle. Rendez-la basée sur les rôles (un développeur a besoin d'un contenu différent de celui de la finance), continue plutôt qu'un diaporama une fois par an, et ancrée dans des risques réels comme le phishing, l'ingénierie sociale et la manipulation des données. Renforcez-la avec des simulations de phishing, des rappels au bon moment et des canaux de signalement clairs. Mesurez les résultats — taux de signalement de phishing, taux de clic, temps de signalement — pas seulement les pourcentages d'achèvement. Bâtissez une culture où les gens signalent leurs erreurs sans crainte, car la crainte étouffe le signalement.

Un KPI (Key Performance Indicator) mesure la performance d'une activité de sécurité par rapport à son objectif — par exemple le délai moyen de détection, le respect du SLA de correctifs, ou le pourcentage de systèmes avec MFA. Un KRI (Key Risk Indicator) est un signal prospectif indiquant que l'exposition au risque augmente vers un niveau inacceptable, avec un seuil censé déclencher une action — par exemple le nombre de correctifs critiques en retard, le compte d'appareils non gérés, ou les revues d'accès échouées en hausse. Les KPI vous disent comment vous vous en sortez ; les KRI vous avertissent de la direction que vous prenez.

Un rapport SOC 2 Type I évalue si les contrôles d'une organisation de services sont conçus de façon adéquate à un instant unique. Un rapport Type II va plus loin : il teste si ces contrôles ont fonctionné efficacement sur une période d'examen, généralement de 3 à 12 mois. Les deux reposent sur les Trust Services Criteria de l'AICPA — la Sécurité (les critères communs obligatoires), plus en option la Disponibilité, l'Intégrité du traitement, la Confidentialité et la Vie privée.

Traitez le risque fournisseur comme un cycle de vie, pas comme un questionnaire ponctuel. Inventoriez vos tiers et classez-les par criticité et sensibilité des données. Menez une due diligence proportionnelle au niveau — examinez les rapports SOC 2 / ISO 27001, les questionnaires de sécurité, les synthèses de pentest, ainsi que les données et accès concernés. Inscrivez les contrôles dans le contrat (exigences de sécurité, droit d'audit, notification de violation, traitement des données, sous-traitants). Surveillez ensuite en continu, pas seulement à l'onboarding, et prévoyez un processus d'offboarding propre pour révoquer les accès et récupérer ou détruire les données. Le risque de quatrième partie (sous-traitant) compte aussi.

Les revues d'accès (recertification) sont des vérifications périodiques où un propriétaire responsable confirme que l'accès de chaque personne reste justifié, et révoque ce qui ne l'est pas. Elles constituent le filet de sécurité qui détecte la dérive de privilèges, les comptes orphelins et les droits accordés pour un projet terminé. Le contrôle ne fonctionne que si un propriétaire compétent — généralement le manager ou le propriétaire de la ressource — examine réellement l'accès au lieu de le valider machinalement, et si les révocations sont appliquées.

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 NIST SP 800-63B moderne privilégie la longueur à la complexité : autoriser de longues phrases secrètes (au moins 8, en prendre en charge 64+), accepter tous les caractères y compris les espaces, et ne pas imposer de règles de composition comme « une majuscule, un symbole ». Filtrer les nouveaux mots de passe contre les listes de mots de passe compromis, abandonner l'expiration périodique obligatoire (renouveler uniquement en cas de preuve de compromission), et abandonner les « questions de sécurité » fondées sur la connaissance. Le but : des règles qui résistent aux vraies attaques au lieu d'agacer les utilisateurs vers des schémas prévisibles.

La MFA résistante au hameçonnage signifie que le second facteur ne peut pas être rejoué contre le vrai site même si l'utilisateur est trompé. Les passkeys FIDO2/WebAuthn y parviennent grâce à une cryptographie à clé publique liée à l'origine : l'authentificateur signe un défi lié au domaine du vrai site, de sorte qu'un identifiant capturé par un site sosie ou un attaquant-au-milieu est inutile. Les codes TOTP et les invites par notification restent hameçonnables car ils peuvent être relayés en temps réel.

Le PAM contrôle et surveille les comptes qui peuvent causer le plus de dégâts — administrateurs de domaine, root, comptes de service. Il met en coffre et fait tourner leurs identifiants pour qu'aucun secret ne soit partagé ou codé en dur, courtise les sessions pour que les administrateurs ne voient jamais le mot de passe brut, enregistre ce que font les utilisateurs privilégiés, et accorde idéalement l'élévation juste-à-temps plutôt qu'un accès permanent. L'objectif est de réduire le rayon d'impact des comptes que les attaquants convoitent le plus.

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.

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.

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.

Un proxy direct se place devant les clients et émet des requêtes sortantes en leur nom — pour le contrôle de sortie, le filtrage, la mise en cache et l'anonymat. Un proxy inverse se place devant les serveurs et reçoit les requêtes entrantes en leur nom — pour la répartition de charge, la terminaison TLS, la mise en cache et comme façade de sécurité pour un WAF. Le sens vers lequel il fait face, côté client ou côté serveur, est la distinction clé.

Le NAT (Network Address Translation) réécrit l'IP source et/ou destination à mesure que les paquets franchissent une frontière, mappant généralement des adresses internes privées vers des publiques. Le PAT (Port Address Translation, ou NAT overload) étend cela en traduisant aussi les ports, laissant de nombreux hôtes internes partager une seule IP publique — chaque flux distingué par son port. Le PAT est ce que les routeurs domestiques et de bureau utilisent pour placer tout un LAN derrière une seule adresse.

Un VLAN (réseau local virtuel) partitionne logiquement un commutateur physique en domaines de diffusion de couche 2 distincts, de sorte que des appareils sur des VLAN différents ne peuvent pas se joindre directement, même sur le même matériel. Il est étiqueté par un marqueur 802.1Q sur les liens de trunk. La valeur de sécurité est la segmentation : isoler le trafic des utilisateurs, des serveurs, des invités et de l'IoT limite la portée des diffusions et le mouvement latéral, le trafic inter-VLAN étant forcé de passer par un routeur ou un pare-feu où la politique est appliquée.

Une DMZ (zone démilitarisée) est un segment réseau situé entre l'Internet non fiable et le réseau interne de confiance, hébergeant des services exposés au public comme les serveurs web, mail et DNS. Les règles de pare-feu laissent Internet atteindre la DMZ mais restreignent fortement l'accès de la DMZ au réseau interne. Le but est le confinement : si un serveur public est compromis, l'attaquant reste coincé dans la zone tampon plutôt que d'atterrir dans le LAN.

La défense en profondeur consiste à superposer plusieurs contrôles de sécurité indépendants pour que, si l'un échoue, les autres protègent encore l'actif. Aucun contrôle n'est supposé parfait, on empile donc des mesures préventives, de détection et de réponse sur les couches réseau, hôte, application et données.

Un SDLC sécurisé intègre la sécurité à chaque phase plutôt que de la rajouter à la fin. Les exigences incluent des cas de sécurité et d'abus, la conception ajoute la modélisation des menaces, le développement utilise le codage sécurisé et le SAST plus l'analyse des dépendances, les tests ajoutent le DAST et les tests d'intrusion, et l'exploitation ajoute la surveillance, les correctifs et la réponse aux incidents — en décalant la sécurité vers la gauche.

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.

Une PKI est le système de CA, de certificats et de politiques qui lie les clés publiques aux identités. Pour valider un certificat de serveur, un client construit une chaîne jusqu'à une racine de confiance, vérifie chaque signature, contrôle les dates de validité et le nom d'hôte, confirme l'usage de la clé, et vérifie la révocation via CRL ou OCSP.

La Content-Security-Policy est un en-tête de réponse HTTP qui indique au navigateur quelles sources de scripts, styles, images et autres contenus sont autorisées à se charger et s'exécuter sur une page. En interdisant le script en ligne et les origines non fiables — idéalement via des nonces ou des hachages — elle sert de rempart de défense en profondeur qui neutralise les charges utiles XSS injectées, même lorsqu'une passe au travers.

Ne stockez jamais les mots de passe en clair ni chiffrés de façon réversible, et jamais avec des hachages rapides à usage général comme MD5 ou SHA-256. Utilisez une fonction de hachage de mots de passe lente et exigeante en mémoire — Argon2id (préféré) ou bcrypt — avec un sel aléatoire unique par mot de passe et un facteur de coût ajusté, afin qu'un attaquant qui vole la base de données ne puisse pas casser les hachages de manière réaliste.

Les en-têtes de sécurité clés incluent Strict-Transport-Security (force HTTPS, bloque le SSL stripping), Content-Security-Policy (limite les sources de scripts, atténue le XSS), X-Frame-Options ou CSP frame-ancestors (bloque le clickjacking), X-Content-Type-Options: nosniff (stoppe le MIME sniffing) et Referrer-Policy (contrôle la fuite du référent). Chacun traite une classe d'attaque spécifique.