À la fin de ce cours, vous saurez
- Expliquer le modèle IAAA et distinguer sans confusion identification, authentication, authorization et accountability.
- Choisir et justifier un type de facteur d'authentification (something you know/have/are) et concevoir une multi-factor authentication pertinente.
- Interpréter les taux d'erreur biométriques FAR (Type 2), FRR (Type 1) et le crossover error rate (CER) pour comparer des capteurs.
- Comparer les modèles d'autorisation DAC, MAC, RBAC, RuBAC et ABAC et les rattacher à un contexte de classification.
- Concevoir un single sign-on et une fédération d'identité (FIM) avec Kerberos, SAML, OAuth ou OpenID Connect en identifiant les rôles client, SP/RP et IdP.
- Piloter le cycle de vie de l'access provisioning, de l'identity proofing à la deprovisioning, et prévenir le privilege creep par des access reviews.
- Mettre en place une gestion des comptes privilégiés (PAM) et des contrôles de monitoring/logging produisant un audit trail forensique.
- Relier les choix IAM aux exigences de conformité (GDPR, HIPAA) et au principe que due care et due diligence ne se sous-traitent pas.
Prérequis : Il est utile d'avoir parcouru le Domaine 1 (risk management, triade CIA, due care et due diligence), le Domaine 2 (data owner, data custodian et classification) et le Domaine 3 (security models et concepts d'architecture). Ces notions servent de socle au vocabulaire et aux décisions d'autorisation du Domaine 5.
Parcours conseillé
Trois sessions d'environ trois à quatre heures chacune, répartissant les 9 modules. La progression va des fondations conceptuelles vers les mécanismes (facteurs, fédération, autorisation), puis vers l'opérationnel (cycle de vie, comptes privilégiés, systèmes d'authentification). Travaillez chaque checkpoint avant de passer à la session suivante.
-
Session 1 - Fondations et identité
MODULE 1 · MODULE 2 · MODULE 3
Vocabulaire de l'access control, identités comme labels, et le modèle IAAA (identification, authentication, authorization, accountability) comme colonne vertébrale du domaine.
-
Session 2 - Facteurs, fédération et autorisation
MODULE 4 · MODULE 5 · MODULE 6
Facteurs et biométrie (FAR, FRR, CER), single sign-on et federated identity management (Kerberos, SAML, OAuth, OIDC), puis modèles d'autorisation DAC, MAC, RBAC et ABAC.
-
Session 3 - Cycle de vie et systèmes
MODULE 7 · MODULE 8 · MODULE 9
Access provisioning life cycle et prévention du privilege creep, gestion des comptes privilégiés (PAM), puis systèmes d'authentification et session management en production.
Fondations de l'IAM : actifs, sujets/objets, IAAA, accès physique et logique
Prérequis : Aucun. Point d'entrée du Domaine 5.
Toute organisation classifie et catégorise son information selon la valeur qu'elle représente pour ses activités. Si l'une des caractéristiques de sécurité de cette information est compromise, l'organisation évalue l'impact sur cette valeur. C'est de là que naît la mission de l'identity and access management (IAM) : créer et gérer les identités, leur associer des privilèges, puis utiliser cette information pour garantir qu'aucune identité inconnue ou non reconnue, humaine ou non humaine, n'accède aux ressources ni n'exécute d'opérations dessus.
Ce module pose le socle du domaine. Vous y distinguerez IAM et identity management (IdM), vous maîtriserez le « triple A » résumé par l'acronyme IAAA (identification, authentication, authorization, accounting/accountability), et vous comprendrez le vocabulaire fondamental subjects/objects ainsi que les opérations CRUD. Vous verrez ensuite comment administrer un système de contrôle d'accès (centralisé, décentralisé, hybride), comment combiner contrôles administratifs, physiques et logiques, et pourquoi la sécurité physique constitue un problème distinct qu'aucune défense logique coûteuse ne remplace.
Les notions paraissent simples mais l'examen les teste sur des distinctions fines : IAM vs IdM, identification vs authentication, PACS comme classe générale vs jeu de normes fédérales américaines. À la fin du module, vous saurez relier la valeur d'un actif et le résultat du risk management au bon mélange de contrôles, et expliquer pourquoi la classification de l'information doit précéder le choix des contrôles.
1.1 IAM vs IdM, et le cycle IAAA
Le marché hésite entre deux termes. Certaines sources, comme Gartner, réservent identity management (IdM) au processus d'émission et de gestion des identités pour contrôler leur accès aux ressources d'un système, et gardent IAM pour le problème plus large de l'identité et de l'accès dans les systèmes cloud et fédérés. Le cours retient IAM comme terme englobant. Un système IAM crée et gère les identités, leur associe des privilèges, puis exploite cette information pour qu'aucune identité inconnue ou non reconnue n'accède aux ressources ni n'agisse dessus. Il doit aussi tracer tout le cycle de vie d'une identité et de ses tentatives d'accès.
Point capital : les utilisateurs ne sont pas tous humains. L'IAM doit gérer les humains mais aussi les non-humains - logiciels, matériels, objets connectés (IoT) et un nombre croissant de robots. Un service applicatif, un script d'automatisation ou un capteur IoT possède une identité et demande des accès, exactement comme une personne.
Au cœur de l'IAM se trouve le « triple A » : authentication, authorization et accounting (AAA). Avec la fonction d'identity management qui le précède, on parle de l'acronyme IAAA : identification (déclarer qui l'on est), authentication (le prouver), authorization (déterminer ce que l'on a le droit de faire) et accounting/accountability (tracer et imputer les actions). Sans cette pierre angulaire, aucun contrôle de sécurité ne saurait quelles activités autoriser et lesquelles bloquer.
- IAM est le terme englobant ; IdM (sens Gartner) se limite à l'émission et la gestion d'identités
- L'IAM gère humains ET non-humains : logiciels, IoT, robots
- IAAA = identification, authentication, authorization, accounting/accountability
- Identification déclare, authentication prouve : ne pas les confondre
1.2 Subjects, objects et opérations d'accès
ISO/IEC 27000:2016(E) définit le contrôle d'accès comme un « moyen de garantir que l'accès aux actifs est autorisé et restreint selon les exigences métier et de sécurité ». Énoncé plus explicitement, le contrôle d'accès consiste à contrôler l'accès des subjects aux objects dans un système. Un object est un actif informationnel ou une ressource système à protéger : fichiers, enregistrements ou champs d'une base, mais aussi mémoire, temps CPU, espace disque, interfaces réseau, zones physiques d'un bâtiment, documents imprimés, voire canaux Wi-Fi. Un object peut même être un autre subject. Un subject est toute personne, processus, device ou entité qui veut accéder à un object.
L'accès s'exprime en termes de base de données par les opérations CRUD - create, read, update, delete - auxquelles le data security life cycle du Domaine 2 ajoute trois actions explicites : share, archive et store. Identifier la bonne opération est essentiel : un droit de lecture (read) n'est pas un droit de modification (update).
La figure illustre la complexité du sujet demandeur réel (ultimate requesting subject). Un humain utilise souvent un ordinateur intermédiaire, qui peut ne pas lui appartenir, pour atteindre une base sur un serveur. L'utilisateur lance une application sur son device, à laquelle l'OS attribue des process IDs ; l'un de ces process IDs, pour un thread donné, émet des appels système pour ouvrir une connexion à la base distante, en sollicitant d'autres process IDs qui agissent pour son compte. Le serveur ne voit que la demande de connexion distante et les requêtes d'accès qui suivent. Le SGBD doit alors recevoir des credentials disant en substance : « l'utilisateur X, reconnu et approuvé sur son propre système, demande l'accès à ces enregistrements pour y effectuer ces actions CRUD ; pouvez-vous approuver ? »
- Subject = qui demande ; Object = ce qui est demandé (parfois un autre subject)
- CRUD plus share, archive, store décrivent les opérations possibles
- Identifier l'ultimate requesting subject est complexe à cause des process IDs en chaîne
- ISO/IEC 27000 : l'accès est autorisé ET restreint selon les exigences métier et sécurité
1.3 Administrer l'IAM : centralisé, décentralisé, hybride
L'information sur les accès, qu'ils soient logiques ou physiques, est conservée quelque part sous forme de données. Sa gestion s'organise de trois façons principales. En administration centralisée, une seule fonction configure les contrôles d'accès ; toute modification passe par cette administration centrale, après approbation par une procédure établie et l'autorité compétente. Avantages : contrôle strict (peu d'individus peuvent agir), supervision centralisée de chaque compte, fermeture aisée de tous les accès d'un partant, procédures uniformes faciles à imposer. Contrepartie : toutes les actions d'authentification et d'autorisation passent par le système central, ce qui rend les mises à jour immédiatement disponibles sur tous les nuds, mais impose de fortes contraintes de performance à ce système.
En administration décentralisée (ou distribuée), l'accès est contrôlé par les owners ou créateurs des fichiers, où qu'ils soient. Avantage : le contrôle est entre les mains des personnes les plus accountable de l'information, les plus familières avec elle et les mieux placées pour juger qui doit faire quoi. Inconvénients : manque de cohérence des procédures entre owners, difficulté à obtenir une vue système de tous les accès, risque de conflits d'intérêts introduits par inadvertance, et difficulté à révoquer correctement les accès lors d'un transfert ou d'un départ. Surtout, pousser les mises à jour de la base d'AC vers tous les serveurs peut prendre 24 à 48 heures ; cette latence ouvre une fenêtre où un attaquant peut exploiter des privilèges que le management a décidé de révoquer mais que tous les nuds n'ont pas encore appliqués.
En administration hybride, le contrôle centralisé s'applique à certaines informations et le contrôle décentralisé à d'autres. Schéma typique : l'administration centrale fournit l'accès le plus large et basique, tandis que les créateurs/owners de fichiers gèrent les accès à leurs propres fichiers. Un nouvel embauché reçoit ainsi de l'administrateur central des permissions selon son service, sa classification d'emploi et sa tâche - par exemple lecture seule sur une bibliothèque SharePoint d'entreprise, mais lecture-écriture sur le rapport hebdomadaire de son service ; et s'il quitte un projet, le chef de projet ferme aisément son accès au fichier concerné.
- Centralisé : contrôle strict, révocation facile, mais forte charge sur le système central
- Décentralisé : owners décident, meilleure fault tolerance, mais latence de 24-48 h
- Hybride : central pour la base, owners pour leurs propres fichiers
- La latence décentralisée ouvre une fenêtre d'exploitation de privilèges révoqués
1.4 Le contrôle d'accès comme système : administratif, physique, logique
Un système de contrôle d'accès se construit avec les trois catégories de contrôles de sécurité. Les contrôles administratifs - politiques, directives, procédures, formation, standards et exigences de conformité tournés vers l'humain - pilotent la conception des workflows pour répondre aux besoins de sécurité. À partir de cette base de conception, les professionnels choisissent le bon mélange de contrôles physiques et logiques (ou techniques). Les publications NIST et ISO sur l'AC renvoient autant à des politiques et procédures qu'à des dispositifs et des règles logicielles.
Un contrôle physique guide, empêche ou permet le mouvement des personnes et des devices dans un espace défini : l'exemple le plus simple est une porte qu'on peut verrouiller. Un contrôle logique agit dans les flux de données du système : le processus de login en est l'illustration, il transforme les données générées par les actions physiques de l'utilisateur (frappes, clics) pour décider d'accorder ou non l'étape logicielle suivante. Une smart card mélange les deux. Le lecteur sur la porte n'actionne pas directement les serrures : les données lues sur la carte, plus d'éventuelles données saisies, sont envoyées par le réseau à un serveur d'AC. Ce serveur décide d'accorder ou non l'accès selon sa base de règles, puis commande au contrôleur d'entrée d'ouvrir ou de refuser. Au titre de l'accounting, il enregistre la tentative et la décision ; le contrôleur journalise aussi de son côté.
Une précédence essentielle : avant de sélectionner et implémenter le type de contrôle logique, le data owner doit classifier et catégoriser son information. Ces processus complémentaires identifient le type de protection requis (en termes CIANA+PS) et son ampleur, pour répondre aux besoins globaux de risk management de l'organisation. Cette étape doit venir en premier. Les PME repoussent souvent cette approche par le risque, croyant qu'elle ajoute trop d'analyse et de coût ; ce n'est pas une fatalité.
- Trois catégories : administratif, physique, logique (technique)
- La smart card mélange physique et logique via un AC server qui décide et journalise
- Classifier et catégoriser l'information (CIANA+PS) DOIT précéder le choix des contrôles
- Les contrôles découlent du risk management et de la valeur de l'actif
1.5 Systèmes logiques (FICAM) et physiques (PACS) ; protéger applications, services, devices
La feuille de route américaine FICAM (Federal Identity, Credential and Access Management) définit un Logical Access Control System comme un système automatisé qui : autorise ou refuse l'usage à un utilisateur individuel ; l'autorise ou le permet ; repose sur le fait que l'utilisateur a une identité enregistrée et approuvée par le système ; utilise des ressources du système d'information (endpoints, postes, réseaux, applications, logiciels système ou données) ; et accorde, pour cet accès, les instances de permissions enregistrées pour cette identité. Le volume de remote users impose souvent un système d'AC logique bien plus complexe et nuancé que le contrôle physique : il est plus simple en principe de restreindre les mouvements de personnes que de contrôler les multiples formes d'accès distant et de partage de ressources.
Les Physical Access Control Systems (PACS) utilisent en règle générale des systèmes automatisés - donc des éléments logiques - pour gérer le passage des personnes, du matériel et des équipements par des entrées définies, ou pour autoriser/empêcher l'accès physique à un device précis (endpoint, serveur, local technique). Un exemple purement physique : l'intérieur d'un rack serveur configuré pour exiger deux personnes, chacune ouvrant son propre cadenas à combinaison, avec un processus administratif garantissant qu'aucune personne seule ne connaît les deux combinaisons. Des règles d'autorisation spécifiques authentifient l'identité qui veut franchir l'entrée (user ID, manifeste d'expédition, device ID, étiquette d'inventaire) ; NIST SP 800-53r4 précise ces aspects.
L'acronyme PACS a un double sens : il désigne la classe générale des systèmes d'AC physique, et aussi un jeu précis de politiques, procédures et standards (comme NIST SP 800-53r4) utilisé par les agences fédérales américaines et leurs sous-traitants. Enfin, l'IAM protège trois grandes familles d'actifs avec le principe de least privilege : les applications (tous les employés n'ont pas besoin des mêmes ressources ni du même niveau de permission - exemple Microsoft 365/SharePoint, ou une application comptable réservée aux finances) ; les services (offerts par les fournisseurs cloud via des policies déterminant quels subjects accèdent à quels services) ; et les devices.
- FICAM définit le Logical Access Control System comme un système automatisé fondé sur une identité enregistrée
- PACS : double sens, classe générale de systèmes OU normes fédérales américaines (NIST SP 800-53r4)
- Le rack à deux personnes illustre la séparation des connaissances en sécurité physique
- Applications, services et devices se protègent au least privilege
Cas d'étude
Le PACS du U.S. Department of Homeland Security
Contexte : Le U.S. Department of Homeland Security (DHS) opère dans des bâtiments publics, des espaces loués et des installations fournies par des sous-traitants. Son approche des Physical Access Control Systems (PACS) illustre plusieurs concepts de sécurité. Le PACS du DHS se divise en quatre domaines opérant indépendamment sous la direction de l'administrateur PACS. Identification : le PACS exige la personally identifiable information (PII) d'une personne pour autoriser l'accès physique ; ses capteurs lisent la carte personal identity verification (PIV) pour vérifier l'autorisation. Visitor management : les visiteurs et sous-traitants sans carte PIV doivent être identifiés avant tout accès. Parking permit management : l'Office of the Chief Administrative Officer (OCAO) émet et suit les permis de stationnement via le PACS (nom, courriel, numéro et type de permis, dates). Alarm monitoring et intrusion detection : l'application d'alarme permet à l'OCAO de surveiller l'intrusion detection system (IDS) ; chaque activation d'alarme ou incident (panne de communication ou d'alimentation) est enregistré. L'IDS combine capteurs, éclairages et mécanismes par lesquels l'Office of the Chief Security Officer (OCSO) détecte les intrusions ; la seule PII collectée par l'IDS sont les nom et prénom de la personne autorisée à armer/désarmer l'alarme et son code PIN.
Question : Nommez les systèmes logiques ou physiques décrits dans le PACS. Que peut-on supposer de la nature de l'information d'identification ? Et pourquoi le DHS voit-il le contrôle de l'accès physique comme un ensemble de problèmes distinct de l'accès aux systèmes d'information ?
Voir l'analyse et la correction
Le PACS est un ensemble de processus et technologies d'AC physique applicable à toute organisation, pas seulement aux bâtiments fédéraux. Il décrit les contrôles à appliquer à toute entité entrant dans un espace contrôlé : employés, sous-traitants, visiteurs citoyens ou non. Dans tous les cas, une forme de pré-screening précède l'admission.
Les systèmes décrits mêlent physique et logique. Un PACS commence par un processus d'identification et d'autorisation - tourniquet, mantrap, barrière ou borne escamotable pour véhicules - qui présente à la fois une barrière physique et logique. Viennent ensuite des capteurs physiques (CCTV, capteurs de mouvement et acoustiques) pour la surveillance continue de l'espace, et des capteurs logiques (IDS, IPS) qui surveillent l'activité sur le réseau et les hôtes critiques. L'information d'identification (PII, carte PIV, codes PIN) est sensible et permet, vu le degré de pré-screening exigé, une assurance raisonnable qu'aucune menace ne pèse sur la sécurité des occupants ou des données du site.
Le DHS a raison de traiter la sécurité physique comme un problème distinct. Les organisations dépensent énormément pour protéger réseaux, données et systèmes des attaques externes, souvent avec des technologies coûteuses et complexes - mais leur existence crée parfois un faux sentiment de sécurité. Si un acteur malveillant obtient un accès physique au site, et que les occupants croient leur site sûr, ils baissent la garde : l'accès physique permet de contourner nombre de ces solutions coûteuses.
À retenir : Un PACS combine barrières et capteurs physiques ET logiques ; la sécurité physique reste un problème distinct car un accès physique contourne des défenses logiques coûteuses.
- Un PACS mêle barrières physiques et logiques (mantrap, IDS/IPS) et exige du pré-screening
- L'information d'identification (PIV, PII, PIN) est sensible et fonde l'autorisation
- Un accès physique contourne les défenses logiques les plus coûteuses ; ne jamais baisser la garde
Waxbill/MLZ Systems : contrôler l'accès physique aux actifs critiques
Contexte : Vous êtes Chief Security Officer de MLZ Systems, qui poursuit un contrat gouvernemental pour la vente de UAV (drones). Le liaison de projet fédéral vous contacte au sujet d'une revue de vos contrôles d'accès physiques. Il veut comprendre comment vous régulez l'accès aux actifs critiques - équipements, serveurs, installations -, vos processus d'authentification et d'autorisation pour l'entrée physique en zones restreintes, vos protocoles pour le personnel externe et les sous-traitants, vos procédures d'ajustement ou de révocation des droits en cas de changement de rôle ou de départ, et la façon dont vos politiques de sécurité physique sont communiquées et appliquées.
Question : Comment l'accès physique aux actifs critiques est-il contrôlé, et quels mécanismes empêchent l'entrée non autorisée, notamment pour le personnel externe et lors d'un départ ou d'un changement de rôle ?
Voir l'analyse et la correction
Authentification et autorisation : MLZ applique un système strict de keycard couplé à une authentification biométrique pour réguler l'entrée en zones sensibles. Les droits d'accès sont attribués selon les rôles et responsabilités, garantissant que chaque employé n'entre que dans les zones pertinentes à ses fonctions - une application directe du least privilege au monde physique.
Personnel externe : les externes, fournisseurs inclus, subissent des background checks approfondis avant tout accès. Un accès escorté et des badges à durée limitée sont imposés aux tiers, minimisant la menace. Ce traitement reprend la logique du visitor management du cas DHS : pré-screening, identification, et confinement temporel et spatial de l'accès.
Ajustement et révocation : les droits sont revus et mis à jour en temps réel via un système d'AC centralisé. Des procédures de révocation immédiate s'appliquent aux départs et changements de rôle, empêchant tout accès non autorisé. Ce point illustre l'avantage du modèle centralisé du module : la révocation est immédiate sur tous les nuds, là où un modèle décentralisé subirait une latence de 24 à 48 heures - fenêtre exploitable par un partant rancunier. Enfin, des politiques claires sont communiquées par des formations régulières, une documentation accessible, des rappels périodiques et des quiz entretenant une culture de sécurité (contrôle administratif).
À retenir : Keycard plus biométrie, accès escorté et à durée limitée pour les externes, et révocation temps réel via un AC centralisé : la sécurité physique applique le least privilege et profite de l'immédiateté de la centralisation.
- L'authentification physique forte combine keycard et biométrie, avec droits attribués par rôle
- Les externes exigent background check, escorte et badges à durée limitée
- La révocation temps réel via AC centralisé supprime la fenêtre de latence d'un départ ou changement de rôle
Identification vs authentication
L'examen oppose souvent ces deux premières lettres de l'IAAA. L'identification est la simple déclaration d'une identité : annoncer un user ID, présenter une carte PIV. L'authentication est la preuve de cette identité : saisir un mot de passe, valider une biométrie. Déclarer n'est pas prouver. Si une question parle de « présenter sa carte » ou de « saisir son nom d'utilisateur », c'est identification ; si elle parle de « vérifier », « prouver » ou « valider » la prétention, c'est authentication. Vient ensuite l'authorization (ce que l'identité prouvée a le droit de faire), puis l'accounting/accountability (la traçabilité).
PACS : double sens
Le sigle PACS a deux acceptions et l'examen joue sur l'ambiguïté. D'une part, PACS désigne la classe générale des Physical Access Control Systems - n'importe quel système d'AC physique, dans n'importe quelle organisation. D'autre part, il désigne un jeu précis de politiques, procédures et standards (comme NIST SP 800-53r4) utilisé par les agences fédérales américaines et leurs sous-traitants. Le contexte de la question doit vous orienter : ne rejetez pas la notion de PACS sous prétexte que votre organisation n'a aucun lien avec le marché fédéral américain ; la classe générale, elle, s'applique partout.
La sécurité physique est un problème distinct
Un piège récurrent consiste à croire que des défenses logiques coûteuses suffisent. Elles peuvent au contraire créer un faux sentiment de sécurité. Un accès physique au site contourne nombre de ces solutions : un attaquant qui atteint un serveur, un poste ou un local technique peut court-circuiter les contrôles réseau. C'est pourquoi le contrôle de l'accès physique exige des politiques propres, distinctes de l'accès aux systèmes d'information, et des mesures comme le rack à deux personnes ou le mantrap. Ne répondez jamais qu'investir dans le logique dispense du physique.
Point de contrôle — Vérification des acquis
-
Quelles considérations devraient principalement piloter l'implémentation des contrôles d'accès physiques et logiques ?
- A Le résultat de l'exercice de risk management et la valeur de l'actif selon le data owner
- B L'usage obligatoire de NIST SP 800-53 dans tous les cas
- C Les services d'analytique des journaux (log analytics)
- D Le nombre de process IDs générés par le système d'exploitation
Réponse & justification
Réponse : A — Le résultat de l'exercice de risk management et la valeur de l'actif selon le data owner
Les menaces, leur probabilité et leur impact (résultat du risk management) façonnent l'environnement de contrôle, et la valeur de l'actif déterminée par le data owner fixe le niveau d'investissement. NIST SP 800-53 peut être exigé pour des agences fédérales mais n'est pas une considération générale. Les log analytics, historiques, peuvent nourrir le risk management mais ne pilotent pas directement les contrôles. Le nombre de process IDs n'a rien à voir avec le pilotage des contrôles.
-
Quelle est la différence entre administration centralisée et décentralisée ?
- A En centralisée, une fonction unique configure le contrôle d'accès ; en décentralisée, il est géré par les owners ou créateurs des ressources
- B En décentralisée, une fonction unique configure le contrôle d'accès ; en centralisée, il est géré par les owners ou créateurs des ressources
- C L'administration centralisée est très répandue tandis que la décentralisée est rarement utilisée
- D L'administration décentralisée est très répandue tandis que la centralisée est rarement utilisée
Réponse & justification
Réponse : A — En centralisée, une fonction unique configure le contrôle d'accès ; en décentralisée, il est géré par les owners ou créateurs des ressources
Un point central d'administration permet de configurer et d'administrer des contrôles très stricts (réponse A). La réponse B inverse les définitions : en décentralisé, le contrôle est entre les mains des personnes les plus accountable et familières de l'information. Les réponses C et D sont fausses : les deux modèles s'observent en usage courant, le choix dépend des besoins d'infrastructure de l'organisation.
-
Dans la Figure 5.1, un humain utilise un poste intermédiaire pour atteindre une base sur un serveur. Pourquoi est-il difficile de connaître le sujet demandeur réel (ultimate requesting subject) ?
- A L'application reçoit des process IDs de l'OS, et des process IDs en chaîne émettent les requêtes pour le compte du demandeur
- B Le serveur chiffre toutes les identités avant de les enregistrer
- C Les subjects ne peuvent jamais être des processus, seulement des humains
- D La base de données supprime l'identité de l'utilisateur lors de chaque opération CRUD
Réponse & justification
Réponse : A — L'application reçoit des process IDs de l'OS, et des process IDs en chaîne émettent les requêtes pour le compte du demandeur
L'utilisateur lance une application à laquelle l'OS attribue des process IDs ; l'un d'eux ouvre la connexion distante en sollicitant d'autres process IDs qui agissent pour son compte, si bien que le serveur ne voit que la connexion distante. La réponse B (chiffrement) est hors sujet. La réponse C est fausse : un subject peut être une personne, un processus, un device ou une entité. La réponse D est inventée et contraire au fonctionnement décrit.
-
Quelle affirmation décrit correctement le double sens de l'acronyme PACS ?
- A Il désigne la classe générale des systèmes d'AC physique ET un jeu précis de normes (ex : NIST SP 800-53r4) du marché fédéral américain
- B Il désigne uniquement un protocole de chiffrement réseau
- C Il désigne exclusivement les systèmes d'AC logique définis par FICAM
- D Il ne s'applique qu'aux organisations sans aucun lien avec le marché fédéral américain
Réponse & justification
Réponse : A — Il désigne la classe générale des systèmes d'AC physique ET un jeu précis de normes (ex : NIST SP 800-53r4) du marché fédéral américain
PACS désigne à la fois la classe générale des Physical Access Control Systems et un ensemble de politiques, procédures et standards (comme NIST SP 800-53r4) utilisé par les agences fédérales américaines et leurs sous-traitants. La réponse B confond avec un protocole. La réponse C inverse physique et logique (FICAM concerne le logique). La réponse D inverse la logique : la classe générale s'applique partout, y compris hors du marché fédéral.
Points essentiels à retenir
- IAM est le terme englobant (cloud, fédéré inclus) ; IdM, au sens Gartner, se limite à l'émission et la gestion d'identités.
- L'IAM gère des utilisateurs humains ET non humains : logiciels, matériels, IoT, robots.
- IAAA = identification (déclarer), authentication (prouver), authorization (droits), accounting/accountability (traçabilité) ; le triple A en est le cur.
- Subjects accèdent aux objects via CRUD plus share/archive/store ; l'ultimate requesting subject se cache derrière des process IDs en chaîne.
- Trois modèles d'administration : centralisé (contrôle strict, révocation immédiate, charge serveur), décentralisé (owners décident, fault tolerance, latence 24-48 h), hybride (central pour la base, owners pour les fichiers).
- Le contrôle d'accès est un système combinant contrôles administratifs, physiques et logiques ; la smart card mélange physique et logique via un AC server.
- Classifier et catégoriser l'information (CIANA+PS) DOIT précéder le choix des contrôles ; ceux-ci découlent du risk management et de la valeur de l'actif selon le data owner.
- FICAM définit le Logical Access Control System ; PACS a un double sens (classe générale OU normes fédérales américaines).
- Applications, services et devices se protègent au least privilege ; le rack à deux personnes illustre la séparation des connaissances.
- La sécurité physique est un problème distinct : un accès physique contourne des défenses logiques coûteuses, d'où des politiques propres.
Identité, identity store et gestion des credentials
Prérequis : Module M1 (cycle IAAA, distinction sujets/objets et identification vs authentication).
L'identité numérique a connu une évolution radicale en deux décennies. Ce module replace la gestion des identités dans son histoire (trois ères successives), puis explique les briques techniques qui la rendent possible aujourd'hui : l'identity store et les protocoles de fédération, les Credential Management Systems, et les frameworks d'enrôlement comme FICAM et le modèle NIST SP 800-63.
Le fil conducteur est la notion de credential : un binding entre un authenticator (ce qui prouve) et un identifier (qui est prouvé). Comprendre comment un credential est sponsorisé, produit, émis puis géré tout au long de son cycle de vie est central pour le Domaine 5. On relie ce processus au modèle d'identité numérique de NIST, vu comme l'implémentation temps réel du cycle de vie de l'identité.
Enfin, le module installe une grille de lecture que l'examen adore tester : les trois niveaux d'assurance de NIST 800-63-3 - IAL (force du proofing), AAL (force de l'authentification) et FAL (force de l'assertion fédérée). Savoir choisir le bon IAL pour un service donné (forum vs banque) est une compétence directement évaluée.
2.1 Les trois ères de l'identité numérique
L'usage de l'identité lors des connexions initiales et de l'authentification à travers de multiples systèmes reflète une évolution, voire une révolution, dans la façon dont marchés, individus et gouvernements ont dû composer avec l'identité numérique. On distingue trois grandes ères.
La première ère, au début de l'ère internet, calquait l'identité numérique sur les pratiques business, gouvernementales et personnelles existantes : un même individu possédait de multiples fichiers d'identité, un par entreprise ou administration avec laquelle il traitait, contenant des informations différentes ou figées à des instants différents. La deuxième ère démarre avec la généralisation des online social networks : les sites se mettent à accepter qu'un client se connecte avec son identité de réseau social (OSM). En peu de temps, Facebook, LinkedIn, Google, Apple et Microsoft deviennent les leaders de ce social login et instaurent des relations de transitive trust (le site fait confiance à l'OSM qui fait confiance à l'utilisateur).
La troisième ère décolle entre 2015 et 2020, portée par la demande de data sovereignty : les individus veulent posséder les données sur leurs habitudes, actions et transactions plutôt que de les laisser aux agrégateurs colossaux des réseaux sociaux. De nouvelles technologies comme la blockchain ouvrent la voie à des identités numériques souveraines ; des nations comme l'Estonie et le Canada, et l'UE via plusieurs initiatives, font des progrès notables vers des IDs numériques citoyens. La COVID-19 a accéléré le travail à distance, l'achat en ligne et la télémédecine, mais aussi des fraudes inventives. Aucune de ces forces n'a encore imposé un standard unique : les systèmes actuels reposent sur des technologies mûries depuis 10 à 15 ans, dont l'identity store, le single sign-on (SSO) et la federated identity management (FIM).
- Ère 1 : identités multiples, une par organisme, incohérentes entre elles
- Ère 2 : OSM et social login (Facebook, Google, Apple, Microsoft, LinkedIn) via transitive trust
- Ère 3 : data sovereignty, blockchain, IDs souverains (Estonie, Canada, UE), accélérés par la COVID-19
- Aucun standard unique imposé ; SSO, FIM et identity store dominent encore
2.2 The Identity Store et les repositories de fédération
Au fil du temps, la multiplication des systèmes a rendu la maintenance d'identity stores séparés coûteuse et source d'erreurs. Les organisations ont donc cherché des mécanismes pour simplifier la gestion des credentials, réduire la charge des utilisateurs (qui devaient jongler avec de multiples credentials) et standardiser les services d'identité dans des environnements hétérogènes.
Les premiers systèmes de fédération reposaient sur du scripting pour faire transiter les credentials entre un identity store central et différents systèmes. Le scripting était simple à mettre en oeuvre, mais peinait à passer à l'échelle et restait vulnérable à l'interception de credentials puis au spoofing. Plusieurs approches techniques ont alors évolué pour répondre aux demandes concurrentes d'identity, d'authentication et d'authorization, suivant l'évolution des protocoles de communication et la dépendance croissante aux systèmes d'information.
Quelques repositories bien connus de l'identity store : Kerberos, RADIUS (Remote Authentication Dial-in User Service), LDAP (Lightweight Directory Access Protocol), OAuth / OAuth 2.0 (Open Authorization), SAML (Security Assertion Markup Language), OpenID, OpenID Connect, FIDO (FIDO U2F, FIDO UAF, FIDO2) et WebAuthn (Web Authentication). Ces protocoles ne jouent pas tous le même rôle : LDAP et RADIUS servent surtout d'annuaire et d'authentification réseau, Kerberos délivre des tickets, SAML et OpenID Connect portent des assertions de fédération, OAuth gère l'autorisation déléguée, et FIDO/WebAuthn standardisent l'authentification forte sans mot de passe. On les détaillera dans les modules dédiés à la fédération.
- Des identity stores séparés sont coûteux et propices aux erreurs
- La fédération par scripting est simple mais fragile (scale, interception, spoofing)
- Repositories clés : Kerberos, RADIUS, LDAP, OAuth/OAuth2.0, SAML, OpenID, OpenID Connect, FIDO, WebAuthn
- Chaque protocole couvre un rôle distinct : annuaire, authentication, authorization ou fédération
2.3 Credential Management Systems : le credential comme binding
Un credential est le binding entre un authenticator et un identifier (utilisateur, service ou système). Autrement dit, il lie ce qui prouve l'identité (un secret, une clé, un certificat) à qui ou quoi est identifié. Un Credential Management System (CMS) est une forme établie d'émission et de gestion de credentials, basée sur du logiciel.
Le logiciel de CMS peut faire partie d'une public key infrastructure (PKI) et peut servir à émettre des identités à two-factor authentication (2FA). Les credentials peuvent être collectés et gérés par un credential service provider (CSP). Les exemples de credentials incluent, sans s'y limiter, les smart cards, les clés cryptographiques privées/publiques et les digital certificates.
Le CMS n'est donc pas un simple coffre à mots de passe : il pilote tout le cycle de vie du credential, depuis sa production (souvent adossée à la PKI) jusqu'à sa révocation. Retenez la définition exacte du credential pour l'examen : ce n'est ni l'identifier seul, ni l'authenticator seul, mais le lien vérifiable entre les deux. Confondre credential et identifier (ou credential et mot de passe) est une erreur fréquente.
- Credential = binding authenticator + identifier (ni l'un ni l'autre seul)
- Un CMS émet et gère les credentials par logiciel
- Le CMS peut s'appuyer sur une PKI et émettre des identités 2FA
- Exemples de credentials : smart cards, clés crypto privées/publiques, digital certificates
2.4 FICAM / ICAM : l'enrôlement en cinq étapes
En 2009, le gouvernement fédéral américain a constaté qu'un framework de gestion des identités était nécessaire pour garantir la conformité de l'ensemble du secteur fédéral. Il a publié l'architecture FICAM, qui fournit des règles communes d'Identity Credential Access Management (ICAM) pour bâtir une architecture de credentials saine dans les agences fédérales.
Le FICAM Roadmap and Implementation Guidance Version 2.0 définit un processus d'enrôlement en cinq étapes. 1. Sponsorship : une entité autorisée sponsorise des claimants pour un credential auprès d'un CSP. 2. Enrollment : le claimant sponsorisé s'enrôle pour le credential ; cette étape inclut l'identity proofing, qui peut impliquer la capture de données biographiques et biométriques. 3. Credential Production : les credentials sont produits sous forme de smart cards, de clés cryptographiques privées/publiques ou de digital certificates. 4. Issuance : le claimant reçoit son credential. 5. Credential Life Cycle Management : les credentials sont maintenus par des activités incluant revocation, reissuance, reenrollment, expiration, suspension ou reinstatement.
Cette architecture sert de référence pour implémenter un CMS dans diverses organisations. FICAM reste utile mais sa dernière mise à jour majeure date de décembre 2011 ; fin 2020, le CIO du gouvernement américain et la General Services Administration ont lancé un effort de migration et de restructuration baptisé Managing Federal Identity Programs Roadmap and Playbooks. D'autres référentiels plus récents, comme les NIST Digital Identity Guidelines (SP 800-63) et l'ISO 27001 Annexe 9 (Access Control), peuvent aussi servir.
- FICAM (2009) fournit les règles ICAM pour les agences fédérales US
- Cinq étapes : Sponsorship, Enrollment (avec identity proofing), Credential Production, Issuance, Credential Life Cycle Management
- Le proofing (biographique/biométrique) se situe dans l'étape 2 Enrollment
- FICAM évolue vers le Managing Federal Identity Programs Roadmap and Playbooks (depuis fin 2020)
2.5 Proofing vs authentication, et les niveaux IAL / AAL / FAL
En 2018, NIST a publié SP 800-63 pour actualiser la gestion des credentials. Son modèle d'identité numérique (Figure 5.2) illustre l'usage de la PKI pour des services d'authentification d'identité par certificat, et se lit comme l'implémentation temps réel du cycle de vie de l'identité. Le flux part d'un user en rôle d'applicant, qui entre dans un processus d'enrollment et de proofing avec un CSP (Google, Facebook, LinkedIn, Outlook Live, ou un CSP interne sponsorisé par l'organisation). L'utilisateur devient ensuite claimant lorsqu'il tente d'accéder à un service comme potential subscriber, ce qui le fait interagir avec le verifier pour authentifier ses credentials auprès du CSP. Cela l'élève au rôle de subscriber, et au final le relying party (RP) - celui qui réalise le vrai travail de la session - obtient l'assurance dont il a besoin. La confiance est passée du CSP, via le verifier, jusqu'au RP.
Il faut bien distinguer deux décisions. L'identity proofing est la décision initiale : prouver qu'une personne est bien celle qu'elle prétend être, lors de l'enrôlement. L'authentication est la décision temps réel : vérifier, à chaque tentative d'accès, une revendication d'identité d'un user, process ou device. Le proofing crée la relation de confiance ; l'authentication la rejoue à chaque session.
NIST SP 800-63-3 définit trois niveaux d'assurance. L'Identity Assurance Level (IAL) concerne le proofing : à IAL1 les attributs (s'il y en a) sont self-asserted ; à IAL2 ils sont vérifiés en personne ou à distance selon SP 800-63A ; à IAL3 le proofing en personne est exigé, avec vérification des attributs par un représentant CSP autorisé sur pièces physiques. L'Authenticator Assurance Level (AAL) concerne la force du processus d'authentification. Le Federation Assurance Level (FAL) concerne la force de l'assertion dans un environnement fédéré, utilisée pour communiquer l'authentification et, le cas échéant, les attributs à un RP. À retenir : Facebook, LinkedIn ou Gmail fonctionnent à IAL1 (self-asserted) à la création de compte, tandis qu'ouvrir un compte bancaire relève d'IAL3 (passeport ou permis plus justificatif de domicile, vérifiés en personne).
- Le modèle NIST 800-63 = implémentation temps réel du cycle de vie de l'identité
- Proofing = décision initiale (enrôlement) ; authentication = décision temps réel (chaque accès)
- IAL1 self-asserted, IAL2 vérifié à distance/en personne, IAL3 en personne par le CSP
- IAL = proofing ; AAL = authentification ; FAL = assertion fédérée vers le RP
Cas d'étude
Choisir le bon IAL : forum communautaire vs banque en ligne
Contexte : Une entreprise lance deux services. Le premier est un forum communautaire gratuit où les utilisateurs publient des messages publics et peuvent se connecter avec leur compte Google. Le second est une banque en ligne qui ouvre des comptes courants et exécute des virements. Le RSSI demande de fixer le niveau d'identity proofing (IAL) requis à l'enrôlement pour chacun.
Question : Quel IAL attribuer au forum et lequel à la banque, et pourquoi ?
Voir l'analyse et la correction
Pour le forum, le risque lié à une fausse identité est faible : un pseudonyme suffit, le préjudice se limite à du spam ou des messages indésirables. IAL1 convient : les attributs sont self-asserted, l'utilisateur n'a rien à prouver de son identité réelle. Se connecter via Google ne change pas ce niveau : Google lui-même fonctionne à IAL1 pour la création de compte, donc la transitive trust hérite d'un proofing self-asserted.
Pour la banque, l'enjeu est tout autre : ouvrir un compte et déplacer de l'argent expose à la fraude, au blanchiment et à des obligations réglementaires (KYC). On exige IAL3 : proofing en personne, vérification des attributs par un représentant CSP autorisé sur pièces physiques (passeport ou permis de conduire) et justificatif de domicile. IAL2 (vérification à distance) pourrait convenir à des produits intermédiaires, mais l'ouverture de compte bancaire est l'exemple canonique d'IAL3.
Le piège serait de raisonner sur la force du mot de passe ou de la MFA pour fixer ce niveau : ce serait confondre IAL et AAL. L'IAL répond à la question -prouve-moi qui tu es à l'inscription- ; l'AAL répond à -prouve-moi que c'est toi à chaque connexion-. Ici on ne dimensionne que le proofing initial, donc l'IAL.
À retenir : Le niveau de proofing (IAL) se choisit selon le risque du service : IAL1 self-asserted pour un forum, IAL3 en personne pour une banque ; ne pas le confondre avec l'AAL.
- Plus le préjudice d'une fausse identité est grand, plus l'IAL requis est élevé
- Le social login hérite du proofing du CSP (souvent IAL1)
- Choisir l'IAL ne se confond pas avec choisir l'AAL ou la MFA
IAL vs AAL vs FAL
Les trois niveaux de NIST 800-63-3 répondent à trois questions différentes. L'IAL (Identity Assurance Level) mesure la force de l'identity proofing : à quel point on est sûr que l'identité revendiquée est la vraie. L'AAL (Authenticator Assurance Level) mesure la force du processus d'authentification : à quel point le mécanisme (mot de passe, MFA, FIDO) résiste à l'usurpation. Le FAL (Federation Assurance Level) mesure la force de l'assertion transmise à un RP en environnement fédéré. L'examen brouille les pistes en décrivant une MFA robuste pour vous faire répondre IAL : une MFA forte relève de l'AAL, pas de l'IAL. Mnémonique : IAL = qui es-tu (proofing), AAL = est-ce bien toi (authentication), FAL = que dit l'assertion fédérée.
Identity proofing (décision initiale) vs authentication (décision temps réel)
Identity proofing et authentication ne se produisent pas au même moment ni avec le même but. Le proofing est une décision unique et initiale, à l'enrôlement : on prouve qu'une personne est bien celle qu'elle prétend être (étape Enrollment de FICAM, mesurée par l'IAL). L'authentication est une décision temps réel, répétée à chaque tentative d'accès durant une session ou une journée de travail : on vérifie une revendication d'identité avant d'accorder l'accès. Si une question d'examen parle de l'inscription d'un nouvel employé et de la capture de données biométriques, c'est du proofing ; si elle parle de la vérification du badge à chaque porte, c'est de l'authentication.
CSP vs verifier vs relying party (RP)
Dans le modèle NIST SP 800-63, ne confondez pas les trois acteurs. Le CSP (credential service provider) enrôle l'applicant, réalise le proofing et émet le credential. Le verifier vérifie les credentials du claimant auprès du CSP au moment de l'accès. Le relying party (RP) est celui qui consomme l'assurance et conduit le vrai travail de la session avec le subscriber. La confiance passe du CSP, via le verifier, jusqu'au RP : le RP ne refait pas le proofing, il s'appuie sur l'assertion. Une question qui demande -qui établit l'identité à l'origine- vise le CSP ; -qui mène la session applicative- vise le RP.
Point de contrôle — Vérification des acquis
-
À quel Identity Assurance Level (IAL) fonctionnent des organisations comme Facebook, LinkedIn ou Gmail lorsqu'elles permettent aux utilisateurs de créer un compte ?
- A IAL1
- B IAL2
- C IAL3
- D IAL1 et IAL2
Réponse & justification
Réponse : A — IAL1
IAL1 correspond au self-assertion : l'utilisateur n'a rien à présenter qui confirme son identité réelle. IAL2 exigerait une vérification des attributs à distance ou en personne (ex : preuve pour une réduction militaire ou étudiante). IAL3 exige un proofing en personne par un CSP (ex : ouvrir un compte bancaire avec passeport ou permis et justificatif de domicile). Ces réseaux ne demandent pas IAL2 pour la simple création de compte.
-
Dans le processus d'enrôlement FICAM en cinq étapes, à quelle étape se situe l'identity proofing (capture éventuelle de données biographiques et biométriques) ?
- A Étape 2 : Enrollment
- B Étape 1 : Sponsorship
- C Étape 3 : Credential Production
- D Étape 4 : Issuance
Réponse & justification
Réponse : A — Étape 2 : Enrollment
L'identity proofing fait partie de l'étape 2, Enrollment, où le claimant sponsorisé s'enrôle pour le credential ; cette étape peut inclure la capture de données biographiques et biométriques. Le Sponsorship (étape 1) ne fait qu'autoriser la démarche. La Credential Production (étape 3) fabrique smart cards, clés ou certificats. L'Issuance (étape 4) remet le credential.
-
Quelle affirmation distingue correctement l'identity proofing de l'authentication ?
- A Le proofing est la décision initiale (prouver qui l'on est à l'enrôlement) ; l'authentication est la décision temps réel répétée à chaque accès
- B Le proofing se fait à chaque accès ; l'authentication une seule fois à l'inscription
- C Les deux sont synonymes et interchangeables
- D Le proofing approuve l'action demandée ; l'authentication mesure la valeur de l'actif
Réponse & justification
Réponse : A — Le proofing est la décision initiale (prouver qui l'on est à l'enrôlement) ; l'authentication est la décision temps réel répétée à chaque accès
Le proofing est une décision unique et initiale, à l'enrôlement, mesurée par l'IAL : on établit que la personne est bien celle qu'elle prétend être. L'authentication est une décision temps réel, rejouée à chaque tentative d'accès durant la session. Les options inversées, synonymes ou mêlant l'autorisation et la valeur d'actif sont fausses.
-
Qu'est-ce qu'un credential au sens de la gestion des identités ?
- A Le binding entre un authenticator et un identifier
- B Uniquement le mot de passe de l'utilisateur
- C Uniquement l'identifier (user/service/system)
- D La politique d'autorisation appliquée à une ressource
Réponse & justification
Réponse : A — Le binding entre un authenticator et un identifier
Un credential est le binding entre un authenticator (ce qui prouve) et un identifier (user, service ou système). Ce n'est ni l'authenticator seul (le mot de passe), ni l'identifier seul, ni une politique d'autorisation. Un CMS émet et gère ces credentials, souvent via une PKI.
Points essentiels à retenir
- Trois ères d'identité numérique : comptes multiples par organisme, puis OSM/social login via transitive trust, puis data sovereignty et IDs souverains (blockchain, Estonie, Canada, UE), accélérée par la COVID-19.
- Des identity stores séparés sont coûteux ; la fédération par scripting est fragile (scale, interception, spoofing).
- Repositories de l'identity store : Kerberos, RADIUS, LDAP, OAuth/OAuth2.0, SAML, OpenID, OpenID Connect, FIDO (U2F/UAF/FIDO2), WebAuthn.
- Credential = binding authenticator + identifier ; un CMS l'émet et le gère par logiciel, souvent via une PKI, et peut produire des identités 2FA.
- Exemples de credentials : smart cards, clés cryptographiques privées/publiques, digital certificates ; collectés par un CSP.
- FICAM/ICAM (2009) : enrôlement en 5 étapes - Sponsorship, Enrollment (avec identity proofing), Credential Production, Issuance, Credential Life Cycle Management.
- Le modèle NIST SP 800-63 (Fig 5.2) est l'implémentation temps réel du cycle de vie de l'identité : applicant, CSP, claimant, verifier, subscriber, RP ; la confiance passe du CSP au RP via le verifier.
- Identity proofing = décision initiale à l'enrôlement ; authentication = décision temps réel à chaque accès.
- IAL1 self-asserted, IAL2 vérifié à distance/en personne, IAL3 en personne par le CSP ; Facebook/LinkedIn/Gmail = IAL1 à la création de compte, banque = IAL3.
- IAL (proofing), AAL (force de l'authentification) et FAL (force de l'assertion fédérée) répondent à trois questions distinctes.
IAAA en détail : authentication, authorization, accounting et session management
Prérequis : Module M2 (modèle d'identité numérique, enrollment, identity proofing) acquis.
Le coeur de l'IAM est résumé par l'acronyme IAAA : identification, authentication, authorization et accounting. Le sous-ensemble authentication, authorization, accounting est aussi appelé le triple A (AAA) et est reconnu de longue date comme la pierre angulaire de la sécurité. Sans lui, aucun contrôle ne saurait quelles activités autoriser et lesquelles interdire. Ce module dissèque ces fonctions une à une, puis ajoute deux briques opérationnelles modernes : le self-service identity management, le password-less authentication et le session management.
L'enjeu pédagogique est la discrimination. L'examen oppose sans cesse authentication (prouver qu'une identité est valide) et authorization (décider ce qu'elle a le droit de faire), puis accounting (tracer ce qu'elle a réellement fait). Il oppose aussi identity proofing (décision initiale, hors temps réel) et authentication (décision temps réel). Confondre ces fonctions coûte des points même à des praticiens expérimentés.
À la fin du module, vous saurez situer chaque fonction dans le cycle d'accès, expliquer pourquoi authentication n'approuve jamais une action, relier accounting à la non-repudiation et à l'e-discovery, et sécuriser une session contre un session replay grâce au nonce, au timeout d'inactivité et à la détection d'anomalie.
3.1 Authentication : vérifier une revendication d'identité, sans approuver l'action
Authentication est la fonction qui vérifie une revendication d'identité. Quand un subject présente un identifiant, le système doit valider trois choses : que l'ID est bien on file (une identité émise par le système), qu'il est correctement associé au porteur qui le présente, et qu'il n'est pas suspendu ni révoqué. Cette vérification est une décision temps réel : elle se produit à chaque tentative d'accès et peut donc survenir plusieurs fois au cours d'une même session, par exemple lors d'une ré-authentification avant une opération sensible.
Le point d'examen majeur : authentication n'approuve PAS l'action demandée. Elle répond seulement à la question « cette identité est-elle valide et bien portée par celui qui la présente ? ». Décider si l'identité a le droit de faire ce qu'elle demande relève d'authorization, une fonction distincte qui intervient ensuite. Prouver qui vous êtes ne dit rien de ce que vous avez le droit de faire.
Il faut aussi distinguer authentication d'identity proofing. Identity proofing est la décision initiale, prise lors de l'enrollment, que la revendication d'identité d'un utilisateur peut être validée par des preuves ou une attestation tierce acceptables. Authentication est la décision temps réel qu'une identité émise par le système et revendiquant des droits d'accès est (a) une identité valide émise par le système et (b) utilisée ou présentée par le subject auquel elle a été délivrée. L'une se fait une fois, à froid ; l'autre se rejoue à chaque accès.
- Authentication valide : ID on file, bien associé au porteur, non suspendu
- Décision temps réel, possible plusieurs fois par session
- Authentication n'approuve PAS l'action : cela relève d'authorization
- Identity proofing = décision initiale ; authentication = décision temps réel
3.2 Authorization et self-service identity management
Authorization a deux sens qu'il faut savoir séparer. Le premier est la décision initiale d'accorder certaines permissions à une identité, concernant les actions qu'elle pourra entreprendre à l'avenir sur des objets particuliers : c'est l'octroi de droits, posé en amont. Le second est la confirmation temps réel qu'une requête d'action, par un subject sur un objet donné, est bien permise par les privilèges définis pour ce subject, cet objet et d'éventuels autres critères. Le premier sens définit les droits ; le second les vérifie au moment de l'usage.
Le self-service identity management donne aux utilisateurs la capacité de demander eux-mêmes des modifications de leur identité et des permissions associées. Les usages courants incluent : changer un password, une passphrase ou un PIN ou tout autre paramètre de challenge ; mettre à jour une adresse physique, des numéros de téléphone ou autres données ; demander l'accès à des ressources sur un serveur, un système, un extranet ou un dépôt documentaire ; demander ou tenter d'utiliser une application qui exige la création d'une identité applicative séparée.
La clé de lecture : toutes ces opérations sont en réalité des access requests. L'utilisateur tente d'accéder à des services, qui sont des objets, pour modifier des valeurs enregistrées dans d'autres objets, comme l'identity store. Vu sous cet angle, un changement de PIN n'est pas une opération à part : c'est une requête d'accès à l'identity store, qui doit donc être gouvernée par des permissions, exactement comme toute autre tentative d'accès vers un objet.
- Authorization sens 1 : décision initiale d'octroi de permissions
- Authorization sens 2 : confirmation temps réel qu'une requête est permise
- Self-service : changer password/PIN/adresse, demander un accès, créer une identité applicative
- Toute opération de self-service est une access request gouvernée par des permissions
3.3 Accounting : traçabilité, non-repudiation et trigger events
Accounting est la fonction d'identity management qui garde la trace de chaque action impliquant chaque identité définie dans le système. C'est elle, par exemple, qui fournit à l'utilisateur la date et l'heure de son dernier login réussi ou échoué. En capturant l'information sur chaque tentative d'accès au système ou à ses ressources, et en notant si elle a réussi avec octroi d'accès ou les motifs de refus, l'accounting fournit les détails nécessaires à l'évaluation, à la revue et à l'audit de sécurité d'un système.
Ce faisant, l'accounting implémente la non-repudiation : il établit la preuve qui empêche un utilisateur de nier avoir réalisé ou tenté une action particulière. Ces données jouent un rôle dans de nombreuses investigations, du simple troubleshooting d'un problème de compte jusqu'aux cas de misuse de ressources. Elles peuvent et doivent être considérées comme une source de preuve admissible en justice, et sont souvent l'objet de demandes de digital discovery (e-discovery). Elles font aussi partie des jeux de données du monitoring de sécurité de routine : un utilisateur de base n'a en principe pas le droit d'installer un logiciel ; des tentatives d'installation peuvent signaler un comportement inapproprié ou la présence d'un installeur de malware, et même si un outil de blocage empêche l'installation, l'accounting doit en garder la trace.
Enfin, l'accounting alimente les trigger events : des occurrences d'actions qui peuvent exiger une décision humaine pour être résolues. Un exemple typique est une tentative d'aller au-delà des limites fixées par les privilèges d'une identité, c'est-à-dire un échec d'authentication ou d'authorization. Ces déclencheurs peuvent lever des alarmes en temps réel ou alimenter un reporting de statut de routine produit par les fonctions d'accounting du système de contrôle d'accès.
- Accounting trace chaque action de chaque identité (incl. dernier login)
- Il implémente la non-repudiation : on ne peut nier une action tracée
- Données = preuve admissible, objet d'e-discovery, base du monitoring
- Trigger events = actions exigeant une décision humaine, alarmes temps réel
3.4 Password-less authentication
De nombreuses breaches sont causées par des passwords faibles, réutilisés ou volés. Le password-less authentication consiste à vérifier l'identité d'un utilisateur par autre chose qu'un password. Si certains débattent des bénéfices de cette approche, le dénominateur commun reste les problèmes qui ont toujours affligé les passwords : ils sont facilement compromis, coûteux et lourds à gérer, et offrent une mauvaise expérience utilisateur.
Le password-less authentication peut prendre de nombreuses formes selon le cas d'usage. Deux exemples typiques sont les push notifications, où l'utilisateur approuve une connexion depuis un appareil de confiance déjà enrôlé, et l'authentification biométrique, comme l'empreinte digitale. L'objectif est de retirer le secret mémorisé de l'équation, donc de retirer la cible que les attaquants savent le mieux voler ou deviner.
Du point de vue de l'examen, le password-less ne supprime pas le besoin d'authentication : il en change seulement le facteur. Il faut le replacer dans la logique des facteurs d'authentification (something you know, have, are) que le module suivant détaille : remplacer un facteur know fragile par un facteur have (appareil de confiance) ou are (biométrie) plus difficile à compromettre à distance.
- Beaucoup de breaches viennent de passwords faibles, réutilisés ou volés
- Password-less = vérifier l'identité sans password mémorisé
- Motivations : compromission facile, coût de gestion, mauvaise UX
- Formes : push notifications, biométrie (ex : empreinte)
3.5 Session management : du nonce au session replay
Les sessions sont créées, gérées, supportées puis terminées par divers protocoles de la session layer, ou Layer 5 du modèle OSI à 7 couches. Du point de vue IAM, l'authenticated session management est l'ensemble des activités qui garantissent que le système maintient un chemin de protection ininterrompu pour les ressources tout au long de la session ; dans la plupart des cas, cela repose sur des certificats x.509. Le session management consiste à suivre et sécuriser de multiples requêtes vers un service venant d'un même subject : d'abord l'identifier comme utilisateur légitime, puis tracer le quand (date et heure), le où logique (adresse IP ou MAC) et le où physique (quelle porte, quel tourniquet), enfin tracer la fin de session et les actions effectuées.
La menace numéro 2 du Top 10 OWASP est le broken authentication and session management. Le RFC 2965 montre comment maintenir une session avec des cookies : l'état des interactions est conservé dans un session cookie, et chaque nouvelle connexion est liée à ce cookie, ce qui fournit une non-repudiation via la piste d'audit. La soumission de l'authentification fournit un session identifier (session ID). Ces session IDs sont des valeurs longues et aléatoires, infaisables à deviner, et à usage unique : d'où le terme de nonce, une valeur qui ne peut servir qu'une fois. Avec la plupart des virements bancaires, par exemple, un nombre de 30 chiffres est créé à l'initiation et permet de vérifier ensuite qui, quand et où le transfert a commencé ; de même, un login dans un realm Kerberos génère l'event ID 4768, suivi de la demande et de la génération d'un ticket d'authentification dont les codes d'événements assurent l'audit.
Une organisation doit suivre tous les session IDs et être prête à terminer de force les sessions, soit après un timeout d'inactivité (comme en banque en ligne), soit lorsqu'une anomalie survient. Ces anomalies incluent un changement soudain de source, comme un changement d'adresse IP, des logins multiples détectés (typique d'un partage de compte), ou un access token réutilisé deux fois sans logout préalable. Le risque majeur vient de ce que le session ID est souvent stocké dans le cookie : si un attaquant capture le cookie de session, ou si sa transmission est retardée, il peut simplement rejouer le cookie vers le système et se connecter avec des credentials volés. C'est le session replay, ou replay attack. Les contre-mesures combinent nonce à usage unique, timeout, détection d'anomalie et protection du cookie (attributs HttpOnly et Secure).
- Sessions gérées par les protocoles de la couche 5 (session) OSI ; souvent via x.509
- OWASP Top 10 numéro 2 : broken authentication and session management ; RFC 2965 (cookies)
- Session ID = valeur longue, aléatoire, à usage unique = nonce
- Suivre tous les session IDs ; terminer de force sur timeout ou anomalie
- Anomalies : changement d'IP, logins multiples, token réutilisé
- Session replay : cookie capturé/retardé puis rejoué = credentials volés
Cas d'étude
Le cookie de session volé du portail bancaire
Contexte : Sur le portail d'internet banking de BanqueNord, un client se connecte depuis un café via un Wi-Fi public non chiffré. Son session cookie, qui contient le session ID, transite en clair. Un attaquant sur le même réseau capture la requête et retarde sa transmission. Quelques minutes plus tard, depuis sa propre machine et une autre adresse IP, l'attaquant rejoue le cookie vers le portail et se retrouve connecté dans la session du client, sans jamais avoir connu son password. Le portail utilise des session IDs de 24 caractères, mais ne les invalide pas après usage, n'applique aucun timeout d'inactivité et ne compare pas l'adresse IP source en cours de session. Les cookies n'ont ni l'attribut HttpOnly ni l'attribut Secure.
Question : Quelle attaque est en cours, et quelles contre-mesures de session management l'auraient empêchée ?
Voir l'analyse et la correction
L'attaque est un session replay (replay attack). Le cookie de session ayant été capturé puis rejoué, l'attaquant se connecte avec ce qui sont, de fait, des credentials volés - sans jamais casser le password. C'est exactement le scénario décrit par OWASP au rang numéro 2 de son Top 10 (broken authentication and session management) et permis ici par le stockage du session ID dans un cookie transmis en clair.
La première contre-mesure est de faire du session ID un véritable nonce : une valeur longue, aléatoire et surtout à usage unique, invalidée dès qu'une session se termine, de sorte qu'un cookie rejoué ne corresponde plus à aucune session active. La deuxième est le timeout d'inactivité : en banque en ligne, la session doit être terminée de force après une courte période sans activité, réduisant la fenêtre de rejeu. La troisième est la détection d'anomalie : le changement d'adresse IP source entre le login du client et la requête de l'attaquant, ou des logins multiples, doivent déclencher une terminaison forcée.
Enfin, la protection du cookie lui-même : l'attribut Secure empêche sa transmission hors HTTPS (donc en clair sur le Wi-Fi public), et l'attribut HttpOnly le soustrait au JavaScript, réduisant le vol par script. Combinées, ces mesures - nonce à usage unique, timeout, détection d'anomalie, HttpOnly et Secure - ferment la surface de replay.
À retenir : Un session ID stocké dans un cookie est une surface de replay : seul un nonce à usage unique, plus timeout, détection d'anomalie et cookies HttpOnly/Secure, neutralise le rejeu.
- Un replay attack n'exige pas de connaître le password : le cookie suffit
- Le nonce à usage unique invalide le cookie rejoué
- Changement d'IP et logins multiples sont des anomalies à traiter par terminaison forcée
Authentication vs authorization vs accounting
L'examen oppose ces trois fonctions du AAA dans la même question. Authentication vérifie qu'une revendication d'identité est valide et bien portée par celui qui la présente : elle prouve QUI vous êtes, mais n'approuve aucune action. Authorization décide ce que cette identité a le droit de faire (octroi initial puis confirmation temps réel d'une requête). Accounting trace ce que l'identité a réellement fait, fondant la non-repudiation. Règle mnémonique : authentication = qui, authorization = quoi (a le droit), accounting = quoi (a fait). Si la question parle d'approuver ou de refuser une action, c'est authorization, jamais authentication.
Identity proofing vs authentication
Ne confondez pas la décision initiale et la décision temps réel. Identity proofing se fait une seule fois, à l'enrollment : on valide la revendication d'identité par des preuves ou une attestation tierce acceptables, à froid. Authentication se rejoue à chaque tentative d'accès, en temps réel : on vérifie que l'identité émise par le système est valide et présentée par son titulaire. Indice d'examen : « à chaque login », « en temps réel », « plusieurs fois par session » pointent vers authentication ; « lors de l'inscription », « preuve tierce », « décision initiale » pointent vers identity proofing.
Le session ID dans le cookie : surface de replay
Un piège récurrent : croire qu'un session ID long et aléatoire suffit. Sa robustesse contre le guessing ne le protège pas du rejeu. Comme le session ID est souvent stocké dans le cookie, un attaquant qui capture ce cookie (Wi-Fi non chiffré, transmission retardée) peut le rejouer pour se connecter avec des credentials de fait volés : c'est le session replay. La protection ne vient pas de la longueur seule mais de l'usage unique (nonce invalidé après la session), du timeout, de la détection d'anomalie (changement d'IP, double login, token réutilisé) et des attributs HttpOnly/Secure sur le cookie.
Point de contrôle — Vérification des acquis
-
Un système confirme avec succès qu'un utilisateur présente bien une identité valide qui lui a été émise. L'utilisateur tente ensuite de supprimer un fichier auquel il n'a aucun droit, et l'action est refusée. Quelle fonction a opéré ce refus ?
- A Authorization
- B Authentication
- C Identity proofing
- D Accounting
Réponse & justification
Réponse : A — Authorization
Authentication a déjà réussi (l'identité est validée) mais elle n'approuve aucune action. Décider qu'une requête sur un objet est permise ou non relève d'authorization, dans son sens de confirmation temps réel. Identity proofing est la décision initiale à l'enrollment ; accounting ne fait que tracer.
-
Un employé nie avoir lancé un virement frauduleux. Quelle fonction IAM fournit la preuve qui empêche cette dénégation ?
- A Accounting (non-repudiation)
- B Authentication
- C Authorization
- D Self-service identity management
Réponse & justification
Réponse : A — Accounting (non-repudiation)
L'accounting trace chaque action de chaque identité et implémente ainsi la non-repudiation : il établit la preuve qui empêche un utilisateur de nier une action effectuée. Ces données sont admissibles en justice et objet d'e-discovery. Authentication et authorization décident, elles ne conservent pas la trace probante.
-
Pourquoi un session ID doit-il être une valeur longue, aléatoire et à usage unique ?
- A Pour être infaisable à deviner et ne pouvoir être rejoué (nonce)
- B Pour réduire la taille du cookie transmis
- C Pour accélérer le chiffrement de la session
- D Pour être lisible par l'utilisateur dans l'URL
Réponse & justification
Réponse : A — Pour être infaisable à deviner et ne pouvoir être rejoué (nonce)
Long et aléatoire rend le session ID infaisable à deviner ; l'usage unique en fait un nonce (number used once), de sorte qu'une valeur capturée ne peut être réutilisée. Cela ferme à la fois le guessing et, combiné à l'invalidation, le rejeu. Les autres options ne sont pas l'objectif de sécurité visé.
-
Au cours d'une session active, l'adresse IP source change brutalement et un second login simultané est détecté sur le même compte. Que doit faire le système ?
- A Traiter ces anomalies et terminer de force la session
- B Ignorer : un changement d'IP est normal
- C Prolonger automatiquement le timeout d'inactivité
- D Demander à l'utilisateur de réenrôler son identité (identity proofing)
Réponse & justification
Réponse : A — Traiter ces anomalies et terminer de force la session
Un changement soudain de source (IP) et des logins multiples sont précisément les anomalies de session qui doivent déclencher une terminaison forcée. L'organisation suit tous les session IDs pour pouvoir terminer ces sessions. Prolonger le timeout aggraverait l'exposition ; l'identity proofing n'a rien à voir avec une session en cours.
Points essentiels à retenir
- IAAA = identification, authentication, authorization, accounting ; le coeur AAA est la pierre angulaire de la sécurité.
- Authentication vérifie qu'une identité est on file, bien associée au porteur et non suspendue ; c'est une décision temps réel, possiblement répétée dans la session.
- Authentication n'approuve PAS l'action : décider du droit relève d'authorization.
- Identity proofing = décision initiale à l'enrollment ; authentication = décision temps réel à chaque accès.
- Authorization a deux sens : octroi initial de permissions, puis confirmation temps réel qu'une requête est permise.
- Toute opération de self-service (changer password/PIN/adresse, demander un accès, créer une identité applicative) est une access request.
- Accounting trace chaque action de chaque identité, implémente la non-repudiation, fournit une preuve admissible et d'e-discovery, et alimente monitoring et trigger events.
- Password-less authentication répond aux passwords faibles/réutilisés/volés ; formes : push notifications, biométrie.
- Le session ID est un nonce (valeur longue, aléatoire, à usage unique) ; OWASP Top 10 numéro 2 = broken authentication and session management.
- Un cookie de session capturé puis rejoué = session replay ; contre-mesures : nonce, timeout d'inactivité, détection d'anomalie (IP, logins multiples, token réutilisé), HttpOnly/Secure.
Facteurs d'authentification, MFA, tokens et biométrie (FAR/FRR/CER)
Prérequis : Module M3 (gestion de session et cycle de l'identité numérique) recommandé : on suppose acquis subject, object, identification et authentication.
Authentifier, c'est présenter une preuve qu'une entité déjà identifiée a le droit de franchir un point de contrôle. La force de cette preuve dépend du nombre et de la nature des facteurs exigés. Ce module distingue la single-factor authentication (SFA) de la multi-factor authentication (MFA), puis détaille les trois facteurs classiques (know, have, are or do) et deux facteurs émergents (location, node).
Nous descendons ensuite dans les technologies : les access control tokens (physiques et logiques) et la biométrie, avec leurs forces et leurs limites. La biométrie introduit une réalité incontournable : aucun capteur n'est parfait. D'où la section centrale du module sur les erreurs de contrôle d'accès, les False Rejection Rate (FRR, Type 1) et False Acceptance Rate (FAR, Type 2), et leur arbitrage via le crossover error rate (CER).
L'examen aime ces distinctions fines : Type 1 contre Type 2, deux méthodes d'un même facteur qui ne font pas une MFA, et le mythe du CER comme réglage idéal. À la fin du module, vous saurez choisir un seuil biométrique en fonction du risque métier réel, pas d'une règle toute faite.
4.1 SFA contre MFA : compter les facteurs, pas les méthodes
Authentifier consiste à présenter une preuve qu'une entité identifiée doit être autorisée à franchir un point de contrôle. Les preuves standard se rangent en trois facteurs primaires : something you know (password, PIN, réponses à des challenge questions), something you have (token, smart card) et something you are or do (biométrie, empreinte digitale). La single-factor authentication (SFA) consiste à fournir un seul type de preuve. Point crucial pour l'examen : un même facteur peut être prouvé par plusieurs méthodes. Un password ET un PIN, ce sont deux méthodes du même facteur (something you know) - donc encore une SFA, pas une MFA.
La multi-factor authentication (MFA) exige plus d'un facteur de preuve : par exemple un password (know) plus un iris scan (are). Chaque facteur ajoute un obstacle pour un attaquant ; à mesure que les facteurs s'empilent, les couches de defense in depth croissent. Le prix à payer : une MFA peut augmenter la complexité de gestion du système et réduire ou perturber la productivité de l'utilisateur qui cherche à se connecter.
Deux facteurs émergents complètent le tableau. Location authentication utilise la géolocalisation pour autoriser ou refuser une connexion selon la zone géographique : des SP comme Netflix et Amazon s'en servent pour protéger leurs contenus contre les fuites de propriété intellectuelle. Node authentication reconnaît le type d'appareil (un smartphone, un laptop ou un desktop précis) comme moyen d'authentification. Du point de vue du risque, une SFA de type what you know s'est révélée inadéquate : les utilisateurs choisissent des mots de passe faciles à retenir donc faciles à casser. La 2FA est plus sûre, et le mécanisme 2FA le plus répandu est le one-time password (OTP) envoyé par SMS ou généré par une application.
- SFA = 1 type de preuve ; MFA = plus d'un facteur DIFFÉRENT
- Password + PIN = deux méthodes du même facteur (know) = encore SFA
- Chaque facteur = un obstacle de plus, une couche de defense in depth
- MFA peut alourdir la gestion et réduire la productivité
- Facteurs émergents : location (géoloc) et node (type d'appareil)
4.2 Physical security tokens : something you have
Les access control devices (systèmes ou composants logiques) ajoutent une couche de protection à l'accès aux données : tokens matériels et logiciels, clés, cartes. Combinés à d'autres méthodes d'identification, ils fournissent une MFA. Les access control tokens prennent deux formes distinctes aux usages distincts. La première, le physical security token, adresse la part something you have d'un challenge MFA.
Beaucoup de ces tokens utilisent aujourd'hui des technologies de cryptographic hash et de pseudorandom number (PRNG) qui génèrent une nouvelle valeur à chaque activation du token par l'utilisateur. Ils s'activent en pressant un bouton, en swipant ou insérant le token dans un lecteur adapté, ou via des technologies near-field communication (NFC) qui les scannent. Le dispositif fonctionne comme un one-time pad cryptographique : le provider doit initialiser à la fois le token (livré sous forme de key fob, smart card ou autre format) et les données du compte de l'utilisateur sur ses systèmes.
Les applications de contrôle d'accès peuvent aussi être installées sur les smartphones ou autres endpoints des utilisateurs, les transformant en token physique plus volumineux mais souvent plus capable. C'est le ressort des authenticator apps : le téléphone devient le facteur have. Retenez pour l'examen que la lecture des credentials d'un token physique peut se faire par swipe (bande magnétique), par insertion (puce), ou en le plaçant sur ou près d'un reader (puce sans contact) : selon la façon dont le token stocke l'information, ces trois modes sont tous valides.
- Le physical token couvre le facteur something you have
- Hash et PRNG produisent une nouvelle valeur à chaque activation
- Lecture : bouton, swipe, insertion ou NFC près d'un reader
- One-time pad : token et compte initialisés ensemble par le provider
- Un smartphone avec authenticator app devient un token physique
4.3 Logical access tokens : le paquet de privilèges
La seconde forme de token est le logical access token. Ce sont des paquets de données générés par un système de contrôle d'accès pour un user ID déjà authentifié. Ils contiennent des informations sur cette identité, les privilèges qui lui sont accordés et d'autres métadonnées. À ne pas confondre avec le physical token : le logical token n'est pas un objet que l'on porte, c'est une structure de données interne au système.
Ces tokens sont ensuite passés à divers programmes applicatifs ou systèmes serveurs, ou intégrés aux handshakes qui établissent les sessions sur les réseaux de l'organisation. Ils portent presque invariablement une date et heure d'expiration, qui peut descendre à quelques minutes si les besoins de sécurité l'imposent. C'est le mécanisme qui limite la fenêtre d'exploitation d'un token volé : un access token à courte durée de vie réduit la valeur d'un rejeu.
La distinction examen est nette : le physical token prouve qui vous êtes au moment de l'authentification (facteur have) ; le logical token, lui, transporte ce que vous avez le droit de faire après l'authentification (identité plus privilèges). L'un est une preuve présentée, l'autre une autorisation propagée.
- Logical token = données générées pour un user ID authentifié
- Contient identité, privilèges et autres métadonnées
- Propagé aux applications et aux handshakes de session
- Expiration souvent courte pour limiter le rejeu
- Physical token = preuve présentée ; logical token = autorisation propagée
4.4 Biométrie : who are you ?
Les dispositifs biométriques mesurent des caractéristiques physiologiques de l'utilisateur : rétines, capillary patterns (réseau capillaire), géométrie des mains ou du visage, empreintes digitales, voire enregistrement vocal. Ces caractéristiques offrent des mesures variables d'unicité : sur des milliards de personnes, très peu partagent les mêmes empreintes, et seule une poignée aurait des scans rétiniens quasi identiques. C'est ce qui en fait des facteurs something you are.
Chaque technologie biométrique a une susceptibilité différente aux erreurs et aux biais de mesure. Pour cette raison, peu de systèmes s'appuient sur une seule technique biométrique comme facteur unique d'authentification. Intégrée dans une MFA, en revanche, la biométrie réduit fortement la vulnérabilité du système à une intrusion. L'enrôlement (enrollment) est l'étape qui établit la baseline : on capture la mesure de référence à laquelle les présentations futures seront comparées.
Pour la protection des données biométriques, la référence n'est pas stockée en clair : elle peut être hachée et conservée sur une smart card que l'utilisateur porte, plutôt que dans une base centrale. On combine ainsi le facteur are (la mesure) et le facteur have (la carte). Retenez le piège d'examen : la biométrie est rarement un facteur unique ; sa vraie valeur est dans une MFA, et la qualité d'un capteur se juge sur ses taux d'erreur, sujet de la leçon suivante.
- Biométrie = facteur something you are, basé sur l'unicité
- Rétine, capillaires, géométrie main/visage, empreintes, voix
- Rarement facteur unique ; sa valeur est dans une MFA
- Enrôlement = capture de la baseline de référence
- Référence souvent hachée sur smart card (are + have)
4.5 Erreurs de contrôle d'accès : FRR, FAR, CER
Quelles que soient les technologies employées, il y aura des erreurs : bruit, dégradation ou panne de capteur, miscalibration, mauvais usage. Les systèmes de contrôle d'accès classent ces erreurs en deux grands types. Le False Rejection Rate (FRR ou Type 1) survient quand le système ne reconnaît pas une identité légitime qui tente d'accéder ; il peut se produire lors de l'authentication comme de l'authorization. Le False Acceptance Rate (FAR ou Type 2) survient quand le système accorde l'accès (ou autorise une action) à une identité qui n'est pas et ne devrait pas être approuvée. Bien que souvent discutés pour les capteurs biométriques, ces taux s'appliquent à tout système de détection d'événement, pas seulement à la biométrie.
Leurs impacts diffèrent radicalement. Une false rejection bloque un travail légitime et nécessaire : un utilisateur qui ne peut se connecter, une mise à jour qui n'est pas exécutée, un poste qui ne joint pas le réseau, avec un coût de réauthentification. Une false acceptance accorde l'accès à un imposteur : c'est une intrusion, potentiellement le point d'entrée d'un advanced persistent threat (APT). Pour l'examen, le FAR (Type 2) porte le risque le plus élevé, car il ouvre la porte à un acteur illégitime.
La figure 5.5 montre le trade space. Augmenter les dépenses sur les technologies de contrôle d'accès (coût plein cycle de vie, y compris la main-d'œuvre) peut baisser le FAR tout en augmentant le FRR. Le point où les courbes se croisent est le crossover error rate (CER). L'axe horizontal montre le risque croissant vers la droite et son inverse logique, la sécurité, croissant vers la gauche. Attention au mythe : croire que le minimum du CER est le sweet spot où coûts et risques sont le mieux équilibrés est une croyance répandue mais fausse. Le climat de risque réel de l'organisation, ses impératifs métier et la tolérance au risque de ses clients et parties prenantes peuvent dicter un tout autre mélange d'erreurs Type 1 et Type 2.
- Type 1 = FRR = false rejection d'une identité légitime
- Type 2 = FAR = false acceptance d'une identité illégitime
- FAR (Type 2) = risque le plus élevé : intrusion, possible APT
- S'applique à tout détecteur, pas seulement la biométrie
- Dépenser baisse le FAR mais augmente le FRR ; CER = croisement
- Le minimum du CER n'est PAS toujours le bon réglage
Cas d'étude
Lire la courbe CER : coffre bancaire contre cantine
Contexte : Une banque déploie un même lecteur biométrique d'empreinte à deux endroits. Site A : la salle des coffres, où un imposteur admis pourrait causer une perte massive et déclencher un APT. Site B : la cantine du personnel, où le scan ne fait qu'autoriser le paiement du repas. Au seuil du CER mesuré sur ce capteur, FAR = FRR = 1 %. Si l'on déplace le seuil vers plus de sécurité, le FAR tombe à 0,1 % mais le FRR monte à 5 %. Si on le déplace vers moins de friction, le FAR monte à 4 % mais le FRR tombe à 0,2 %.
Question : Pour chaque site, faut-il rester au CER, ou choisir un autre seuil ? Justifiez avec les chiffres.
Voir l'analyse et la correction
Le mythe du sweet spot dirait : réglez les deux sites au CER (1 %/1 %), point d'équilibre. C'est faux, car l'impact d'une erreur n'est pas le même selon le site. Le bon seuil dépend du risque métier réel, pas du croisement des courbes.
Site A, le coffre : une false acceptance est catastrophique (intrusion, vol, APT) ; une false rejection coûte seulement une réauthentification à un employé. On accepte donc d'augmenter le FRR pour écraser le FAR. Réglage vers plus de sécurité : FAR 0,1 %, FRR 5 %. On divise le risque d'admission d'un imposteur par dix par rapport au CER, au prix de cinq fois plus de rejets légitimes - un compromis acceptable ici, car l'impact d'un FAR domine.
Site B, la cantine : une false acceptance fait au pire payer le mauvais compte de cantine ; une false rejection bloque un employé affamé dans la file et nuit à la productivité et à l'expérience. On privilégie donc le confort : FAR 4 %, FRR 0,2 %. Le FAR multiplié par quatre reste sans conséquence sérieuse, tandis qu'on réduit les rejets légitimes par cinq. Conclusion : un même capteur, deux seuils opposés, dictés par l'impact métier et la risk tolerance, pas par le CER.
- Le bon seuil dépend de l'impact d'une erreur, pas du croisement des courbes
- Fort enjeu (coffre) : minimiser le FAR même si le FRR grimpe
- Faible enjeu et forte fréquence (cantine) : minimiser le FRR pour la productivité
Type 1 = FRR, Type 2 = FAR, et lequel est le pire
Ne confondez jamais les deux types. Type 1 = False Rejection Rate (FRR) : le système rejette une identité LÉGITIME ; impact = travail bloqué, coût de réauthentification. Type 2 = False Acceptance Rate (FAR) : le système accepte une identité ILLÉGITIME ; impact = intrusion, possible APT. Si une question demande l'erreur au risque le plus élevé, répondez Type 2 (FAR) : accorder l'accès à un imposteur est bien plus grave que faire patienter un employé. Astuce : Type 1 commence comme « légitime » rejeté, Type 2 va « trop loin » en acceptant un intrus.
Deux méthodes d'un même facteur ne font pas une MFA
Password + PIN, ou password + sélection de chiffres d'un passcode, restent une SFA : tout cela est something you know, un seul facteur, même si plusieurs secrets sont demandés. Une MFA exige des facteurs DIFFÉRENTS, par exemple know + have (token) ou know + are (biométrie). Si la question décrit deux preuves du même type, répondez SFA, jamais MFA. Et ne tombez pas dans le piège du OTP : si le secret sous-jacent reste constant entre les connexions, ce n'est pas un vrai one-time password.
Le CER n'est pas toujours le réglage optimal
Croyance répandue mais fausse : le minimum du CER serait le sweet spot où coûts et risques sont le mieux équilibrés. En réalité, le climat de risque réel, les impératifs métier et la tolérance au risque des parties prenantes peuvent imposer un tout autre mix de false rejections et false acceptances. Si une question présente le CER comme le réglage idéal universel, méfiez-vous : le bon seuil se choisit selon l'impact métier de chaque erreur, pas par le simple croisement des courbes.
Point de contrôle — Vérification des acquis
-
Dans une implémentation biométrique, quel type d'erreur représente une false rejection ?
- A Type 1
- B Type 2
- C Type 3
- D Type 4
Réponse & justification
Réponse : A — Type 1
Une erreur Type 1 est une false rejection d'une assertion valide (FRR). Le Type 2 est une false acceptance d'une assertion invalide (FAR). Il n'existe ni Type 3 ni Type 4.
-
Quel type d'erreur présente à l'organisation le risque le plus élevé ?
- A Type 1
- B Type 2
- C Type 3
- D Tous, à parts égales
Réponse & justification
Réponse : B — Type 2
Une erreur Type 2 (FAR) est une false acceptance : elle identifie à tort un imposteur comme légitime et lui accorde l'accès, ouvrant la porte à une intrusion voire un APT. Un Type 1 (FRR) ne fait que refuser un utilisateur légitime. Il n'y a pas de Type 3, et un choix porte bien un risque plus élevé que les autres.
-
Avec des physical access control tokens, comment les credentials de l'utilisateur sont-ils lus pour être transmis au système logique de contrôle d'accès ?
- A Par swipe (bande magnétique)
- B Par insertion (puce)
- C En le plaçant sur ou près d'un reader
- D Toutes ces réponses
Réponse & justification
Réponse : D — Toutes ces réponses
Les trois sont des procédés valides : le swipe lit la bande magnétique, l'insertion lit la puce, et le placement sur ou près d'un reader lit une puce sans contact (NFC). Le mode dépend de la façon dont le token stocke l'information, donc la bonne réponse est toutes ces réponses.
-
Votre banque vous demande d'enregistrer un passcode et un password. À la connexion, la plateforme demande votre password ainsi qu'une sélection aléatoire de chiffres du passcode, qui change à chaque login. Quelle approche d'authentification est représentée ici ?
- A Single-Factor Authentication (SFA)
- B Multi-Factor Authentication (MFA)
- C Strong Authentication
- D One-Time Password (OTP)
Réponse & justification
Réponse : A — Single-Factor Authentication (SFA)
C'est une SFA, pas une MFA : passcode et password sont tous deux du something you know, donc un seul facteur. Ce n'est pas une MFA faute d'un facteur have ou are. Ce n'est pas du strong authentication (généralement password-less). Et ce n'est pas un vrai OTP : le passcode sous-jacent reste constant entre les connexions, et les mêmes chiffres peuvent être redemandés.
-
Sur la courbe de la figure 5.5, vous déplacez le seuil du capteur vers la gauche (Greater Security). Quel effet attendre sur les taux d'erreur ?
- A Le FAR baisse et le FRR monte
- B Le FAR monte et le FRR baisse
- C FAR et FRR baissent tous les deux
- D On atteint forcément le réglage optimal au CER
Réponse & justification
Réponse : A — Le FAR baisse et le FRR monte
Vers la gauche (plus de sécurité), on durcit le capteur : il accepte moins d'imposteurs (FAR baisse) mais rejette davantage de légitimes (FRR monte). On ne peut pas baisser les deux simultanément, c'est tout le compromis. Et le CER n'est pas forcément optimal : le bon seuil dépend du risque métier réel, pas du croisement des courbes.
Points essentiels à retenir
- SFA = un seul facteur ; MFA = plus d'un facteur DIFFÉRENT ; password + PIN restent une SFA (même facteur know).
- Facteurs : something you know, have, are or do, plus location (géoloc) et node (type d'appareil).
- Chaque facteur ajoute une couche de defense in depth, mais la MFA peut alourdir la gestion et la productivité ; l'OTP par SMS ou app est le mécanisme 2FA le plus répandu.
- Physical security token (have) : hash/PRNG, nouvelle valeur à chaque activation, lu par bouton, swipe, insertion ou NFC ; un smartphone avec authenticator app en est un.
- Logical access token : paquet de données généré pour un user ID authentifié (identité + privilèges), propagé aux apps et sessions, à expiration souvent courte.
- Biométrie (are) : rétine, capillaires, géométrie, empreintes, voix ; rarement facteur unique, sa valeur est dans une MFA ; référence enrôlée puis hachée, souvent sur smart card.
- Type 1 = FRR = false rejection (légitime bloqué) ; Type 2 = FAR = false acceptance (imposteur admis) ; ces taux valent pour tout détecteur, pas que la biométrie.
- Le FAR (Type 2) porte le risque le plus élevé : intrusion, possible APT ; le FRR coûte surtout des réauthentifications.
- Sur la courbe, dépenser baisse le FAR mais augmente le FRR ; leur croisement est le CER (crossover error rate).
- Le minimum du CER n'est PAS toujours le bon réglage : le seuil se choisit selon le risque réel, les impératifs métier et la risk tolerance.
SSO, fédération (FIM), JIT identity et services tiers
Prérequis : Module M2 (identity store, credentials, identity proofing) : il faut savoir ce qu'est un dépôt d'identités et comment une preuve d'identité est établie avant d'aborder le partage entre domaines.
Une organisation moderne ne vit jamais seule : ses utilisateurs accèdent à des applications hébergées chez des partenaires, dans le cloud, chez des fournisseurs SaaS. Ce module traite des mécanismes qui permettent de partager et de réutiliser une identité au-delà des frontières d'un seul système : le Single Sign-On (SSO), la Federated Identity Management (FIM), la Just-in-Time identity et la fédération avec un service tiers (IDaaS).
Le fil conducteur est la confiance. Un serveur d'authentification doit faire confiance aux credentials qu'on lui présente, mais selon le principe « Trust, but verify ». Quand ces credentials proviennent d'une autre organisation - votre identifiant Facebook pour vous connecter à LinkedIn - la vérification devient un problème de confiance entre security domains, résolu par la fédération.
L'examen teste surtout des distinctions fines : SSO (une expérience de login unifiée) n'est pas FIM (une relation de confiance entre domaines), même si on confond souvent les deux. Le SP, et non l'IdP, prend la décision finale d'accès. Et la due care comme la due diligence ne se sous-traitent jamais, même quand l'identité est gérée par un tiers.
5.1 Federated Identity Management (FIM) : la confiance entre domaines
Une identity federation s'applique lorsqu'un ou plusieurs systèmes autorisent les utilisateurs à se connecter en s'authentifiant contre l'un des systèmes participant à la fédération. Le besoin naît quand des organisations différentes doivent partager une information commune : pensez à des plateformes comme LinkedIn et Twitter, aux modèles d'affaires distincts mais à la base de clients partagée. La FIM crée une relation de confiance entre security (trust) domains distincts, de sorte que vos credentials Facebook puissent servir à vous connecter à LinkedIn.
La fédération repose sur trois composants : le client ou principal (l'utilisateur), le SP ou RP (service provider / relying party) et l'IdP (identity provider). L'IdP est un brokering service : son rôle est de fournir l'assertion que le principal est bien qui ou ce qu'il prétend être. Le SP maintient un authorization server et reste responsable de la décision finale accept/reject. On parle de resident IdP (ou local, incumbent) quand son rôle se limite à attester des identités de son propre domaine de confiance ; il devient un federated IdP quand il atteste la validité de credentials appartenant à un autre security domain.
La Figure 5.3 illustre les sept étapes pour Sue, cliente d'Any Bank Inc. : 1) Sue clique « Login » et génère une demande d'accès à la banque (SP). 2) Any Bank envoie une verification request à l'IdP. 3) L'IdP présente un login à Sue. 4) Sue fournit ses credentials, envoyés à l'identity database de l'IdP. 5) La base renvoie la vérification à l'IdP. 6) L'IdP notifie la banque que la personne est bien Sue. 7) La banque autorise la connexion. La FIM s'appuie sur deux standards largement adoptés, SAML et OAuth, qui produisent des déclarations lisibles par l'humain et traitables par la machine sur l'identité, l'authentification et l'autorisation. OpenID Connect est bâti sur l'un d'eux, et l'organisation Open Authentication promeut une architecture de référence nommée OATH pour s'éloigner des services propriétaires. Des acteurs majeurs comme Microsoft et Apple ne cherchent plus à monétiser l'identity-as-a-service mais voient les opportunités créées par une identité numérique fiable et omniprésente.
- FIM = relation de confiance entre security domains distincts
- Trois composants : principal, SP/RP, IdP
- L'IdP atteste (broker) ; le SP décide accept/reject
- Resident IdP = domaine propre ; federated IdP = autre domaine
- Standards : SAML et OAuth ; OpenID Connect bâti sur l'un d'eux ; OATH
5.2 Single Sign-On (SSO) : un login pour toutes les ressources
L'idée du Single Sign-On est qu'un utilisateur ne s'authentifie qu'une fois auprès d'un unique authorization provider, puis se voit accorder l'accès à toutes les ressources pour lesquelles il a des privilèges : information assets, dossiers, systèmes. Le SSO est parfois appelé reduced sign-on, ou confondu avec la federated ID management. Les systèmes SSO classiques fournissent un central repository de credentials utilisateurs (identifiants et mots de passe) associé à une suite d'applications. Le client SSO ouvre l'application appropriée et lui envoie les bonnes frappes clavier, simulant ainsi l'utilisateur tapant lui-même son ID et son password.
La Figure 5.4 montre le fonctionnement : la demande de login initiale est authentifiée par le SSO server (étapes 1 et 2). Chaque tentative d'accès à un autre serveur (service web, plateforme applicative) déclenche un échange d'authentification back-end entre le SSO server et l'applications server (étapes 3 à 6). Le SSO server empaquette l'identité de l'utilisateur authentifié et un mot de passe applicatif courant tiré de sa base interne, transmis à l'applications server. Des access tokens peuvent remplacer les mots de passe applicatifs, selon les besoins d'authentification des applications. Des technologies comme SAML servent à implémenter le SSO.
Le SSO présente des limites. Les legacy systems ne le supportent pas toujours, et il est parfois difficile de trouver des experts capables d'y travailler. Surtout, le single point of failure : certains experts y voient « tous les œufs dans le même panier ». Si un attaquant obtient un seul jeu de credentials dans une organisation en SSO, il accède à toutes les ressources de cet utilisateur ; et la base SSO elle-même devient un actif convoité. Ce risque se mitige par des mécanismes additionnels comme la 2FA et la limitation d'accès par time/geolocation. Enfin, la password synchronization est nécessaire : tout changement de mot de passe doit se propager à tous les systèmes intégrés pour que le mécanisme fonctionne.
- Un seul login donne accès à toutes les ressources autorisées
- Le client SSO simule la frappe ID/password vers chaque application
- Étapes 1-2 = auth au SSO server ; 3-6 = échanges back-end
- Single point of failure mitigé par 2FA et limitation time/geo
- Legacy systems et password synchronization sont des contraintes
5.3 Just-in-Time (JIT) identity : le privilège à la demande
La Just-in-Time identity (JIT identity, sans confondre avec JITI) fournit la création et le provisioning on-demand, en temps réel ou quasi réel, d'identités d'utilisateurs humains et non-humains, leur escalation et de-escalation de privilèges, puis leur deprovisioning, suspension ou termination dans chaque système. C'est un full identity life cycle service à la demande. Les utilisateurs non-humains comptent : à part les périphériques d'entrée et les supports amovibles, tout ce qu'un humain fait passe par du logiciel - agents, processus, mobile code - et des identités organisationnelles ou fonctionnelles, dont les robots qui « apprennent » via internet.
Le cas le plus fréquent et le plus exigeant est l'escalation et de-escalation : fournir des privilèges momentanés. Au lieu de privilèges « allumés » 24h/24 comme dans le PAM statique, le JIT PAM plafonne les privilèges et n'accorde que des sous-ensembles role-based, élevés temporairement pour un process ID précis, avec un TTL court. Tout doit s'exécuter on-demand, en temps réel, ce qui impose un modèle de triage : la majorité des cas est traitée de façon entièrement automatisée, et les exceptions sont bloquées avec un avis de contacter un administrateur. La JIT identity utilise typiquement SAML et se retrouve sur des plateformes de classe mondiale : Azure, Amazon Web Services, OKTA, Salesforce, avec intégration aux IdP sociaux (Windows Live, Facebook, Google, Yahoo, Twitter, LinkedIn).
Les use cases servent à appliquer least privilege, separation of duties et la gestion des vulnérabilités. Le PAM (privileged account management) est le plus familier : les privilèges ne deviennent actifs qu'au moment où l'identité demande la ressource. Le privileged session management n'est pas réservé aux administrateurs : même un humble read est la première étape d'un workflow légitime ou d'une reconnaissance, et la JIT permet l'attribution fine de privilèges aux activités de session. L'endpoint privilege management empêche d'exécuter des processus avec de mauvais privilèges sur un endpoint ou de pivoter vers d'autres nœuds. Enfin, le remote help desk repose sur un agent de confiance et un ID générique de help desk, ce qui exige un haut degré de confiance mutuelle : l'utilisateur doit faire confiance au support, et l'organisation doit s'assurer que le endpoint ne piège pas de credentials réutilisables.
- JIT = provisioning temps réel + escalation/de-escalation + deprovisioning
- Couvre utilisateurs humains et non-humains (agents, robots)
- JIT PAM plafonne les privilèges au lieu de les laisser « on » 24h/24
- Use cases : PAM, privileged session, endpoint, remote help desk
- Implémenté via SAML sur Azure, AWS, OKTA, Salesforce
5.4 Fédération avec un service tiers : IDaaS (5.3)
La fédération fondée sur des relations de confiance mutuelle entre organisations peut s'implémenter via des services tiers. Les fournisseurs d'infrastructure, de plateforme et de logiciel as-a-service proposent presque toujours de l'identity-as-a-service (IDaaS) avec provisioning et administration, multi-factor authentication, Single Sign-On et autres capacités. Mais l'IDaaS n'est pas sans risque : outage de service, fuite ou divulgation de données d'identité critiques. Les services tiers peuvent couvrir le risk management, le security assessment and testing, l'incident response, la planification BC/DR et l'identity management lui-même.
Le point d'examen central : peu importe l'outsourcing, l'offboarding ou les relations fournisseur, le fardeau ultime de la due care et de la due diligence reste TOUJOURS avec votre organisation. On peut déléguer l'exécution, jamais la responsabilité. L'IAM intégré doit toujours s'envisager dans le contexte des exigences globales de sécurité de l'information de l'organisation.
Trois modèles existent. On-premises : gestion dans l'infrastructure propre, offrant customisation et contrôle accru, meilleure sécurité et conformité aux politiques internes ; mais il faut peser le trade-off CapEx vs OpEx, des temps de setup et déploiement longs, le besoin de ressources IT qualifiées et une scalabilité on-demand limitée. Cloud : pas de coût ni de temps initial d'acquisition, scalabilité, support de la croissance, accès depuis n'importe où ; mais des risques liés à la multitenancy, aux outages, et au fait que des données d'identité sensibles sont détenues par un fournisseur externe. Hybrid : beaucoup de systèmes IAM on-premises n'ont pas évolué, et les solutions cloud-only ne couvrent pas toujours des besoins métiers spécifiques ; pour une infrastructure mixte, les solutions qui intègrent on-premises et cloud sont bénéfiques.
- IDaaS = identité gérée par un tiers (MFA, SSO, provisioning)
- Due care et due diligence ne se sous-traitent jamais
- On-premises : contrôle et customisation, CapEx, setup long
- Cloud : scalable et accessible partout, mais multitenancy/outage
- Hybrid : intègre on-premises et cloud pour besoins mixtes
5.5 SSO ou FIM ? Trier les briques de l'accès partagé
SSO, FIM, JIT identity et IDaaS sont souvent évoqués ensemble, mais ils répondent à des questions différentes et l'examen exige de les séparer nettement. Le SSO répond à « comment offrir une expérience de login unifiée à l'intérieur d'un périmètre » : un seul login, un central credential repository, des échanges back-end. La FIM répond à « comment faire confiance à une identité venue d'un autre security domain » : une relation de confiance entre organisations, portée par SAML ou OAuth, avec un IdP qui atteste et un SP qui décide.
Les deux se recouvrent dans la pratique - une fédération produit souvent une expérience SSO entre plusieurs SP - mais ils ne sont pas équivalents. On peut avoir un SSO purement interne sans aucune fédération, et une fédération qui n'offre pas une expérience SSO complète. La JIT identity se superpose encore : elle provisionne l'identité et les privilèges au moment du besoin, et l'utilisateur la déclenche souvent sans le savoir via ses capacités SSO. L'IDaaS, enfin, est le mode de livraison : un tiers fournit tout ou partie de ces capacités en service.
Une bonne façon de mémoriser : SSO est une expérience (côté utilisateur), FIM est une confiance (entre domaines), JIT est un timing (au moment du besoin), IDaaS est un modèle de fourniture (qui opère). Sur une question d'examen, identifiez d'abord lequel de ces quatre angles est interrogé avant de choisir la réponse.
- SSO = expérience ; FIM = confiance ; JIT = timing ; IDaaS = fourniture
- Un SSO peut être purement interne, sans fédération
- Une fédération s'appuie sur SAML/OAuth entre security domains
- Identifier l'angle interrogé avant de répondre en examen
Cas d'étude
Activité 5.2 : FIM chez Aeros 3
Contexte : Aeros 3 gère des systèmes à la fois on-site et dans le cloud, et a implémenté la Federated Identity Management pour permettre une authentification d'identité fluide et sécurisée entre environnements. Tamika planifie une revue et des mises à jour des standards FIM ; un knowledge gap apparaît chez les juniors de l'IT, et une session SETA est programmée avant la publication des changements. La session s'appuie sur l'exemple de la Figure 5.3 (Sue, Any Bank, IdP, identity database). Provenance : activité tirée du cours officiel D5 (section 5.2).
Question : Qui peut jouer les rôles d'IdP et de SP ? Pourquoi le process en trois étapes est-il nécessaire et bénéfique ? Quels types d'erreurs (false positive / false negative) surviennent, et lequel est pire pour la banque ou pour le client ?
Voir l'analyse et la correction
Rôles : le SP est toute organisation fournissant un service au client - une banque, un détaillant en ligne, une agence de voyage. L'IdP est plus subtil : c'est un tiers fournissant des services de vérification d'identité pour le compte du SP ; des exemples sont Facebook ou Google, qui acceptent leurs credentials dans le login et servent d'identity provider.
Nécessité et bénéfice : le process n'est pas toujours indispensable au métier, mais il permet un SSO entre plusieurs service providers, donc le client a moins de credentials à mémoriser. Il est bénéfique car il apporte un niveau d'assurance supplémentaire que le requestor est bien qui ou ce qu'il prétend être.
Erreurs : des false positives et false negatives peuvent survenir. Un false positive identifie à tort un utilisateur invalide comme valide ; un false negative refuse l'accès à un utilisateur valide. Avec un SSO, plusieurs comptes peuvent être compromis simultanément. Dans les deux cas, l'issue est probablement pire pour le client : soit un acteur malveillant accède au compte et vole son argent, soit le client est privé de l'accès à son propre compte. Ces erreurs naissent du partage de credentials, du vol de credentials chez l'IdP, ou de connexions réseau lentes ou rompues.
À retenir : Dans une fédération, le SP fournit le service et l'IdP atteste l'identité ; le process apporte du SSO et de l'assurance, mais ses erreurs (false positive/negative) pèsent surtout sur le client.
- L'IdP est souvent un tiers (Facebook, Google) attestant pour le SP
- Le SSO réduit le nombre de credentials mais concentre le risque de compromission
- Un false positive donne accès à un imposteur ; un false negative bloque un légitime
Dropbox 2012 : un mot de passe employé volé
Contexte : La fuite de données Dropbox de 2012 a exposé des vulnérabilités du service de stockage cloud, touchant des millions d'utilisateurs. Des attaquants ont exploité le mot de passe volé d'un employé Dropbox pour accéder sans autorisation à un document contenant des adresses e-mail d'utilisateurs. Dropbox a affirmé qu'aucun compte n'avait été directement compromis, mais l'incident a mis en lumière les risques des services cloud et l'importance de mesures de sécurité renforcées. À la suite de la fuite, Dropbox a déployé des pratiques comme la two-factor authentication pour renforcer la protection et restaurer la confiance. Le cas Waxbill Part 1 éclaire le contexte : plusieurs organisations (MLZ, Schneider-Antman, GTI) collaborent sur un projet sensible. Pour stocker les identités, on a envisagé Novell Directory Service (NDS) et Microsoft Active Directory (AD) ; comme les deux utilisent LDAP pour interroger des annuaires X.500, le choix d'un dépôt X.500 central interrogé via LDAP donne un directory service commun et réduit l'overhead - ce qui rend justement la FIM nécessaire entre partenaires. Provenance : étude de cas et scénario tirés du cours officiel D5 (section 5.3).
Question : Quelles leçons l'incident Dropbox enseigne-t-il sur la MFA et sur l'intégration de services d'identification tiers avec une IDaaS ?
Voir l'analyse et la correction
La cause racine est un single factor compromis : un mot de passe employé volé a suffi à accéder à des données. La multi-factor authentication exige deux facteurs ou plus (par exemple un mot de passe plus une biométrie), ce qui réduit fortement le risque d'accès non autorisé même si un facteur est compromis. C'est précisément la mesure que Dropbox a adoptée après coup.
L'incident a aussi poussé à réévaluer l'intégration de services d'identification tiers. Lorsqu'on intègre de tels services avec une IDaaS, l'organisation doit évaluer les standards de sécurité et de conformité du tiers, assurer une intégration propre avec les systèmes existants, chiffrer les données d'identité en transmission et au stockage, et surveiller et auditer régulièrement le service tiers. Le scénario Waxbill rappelle que dès que plusieurs organisations partagent des identités, il faut un dépôt et un protocole communs (X.500 via LDAP) et une fédération pour vérifier les credentials de chacun, quel que soit son employeur.
Leçon de gouvernance : confier le stockage ou la vérification d'identité à un tiers ne transfère pas la responsabilité. La due care et la due diligence restent chez l'organisation, qui doit donc encadrer le tiers par des contrôles, des audits et de la MFA.
À retenir : Un seul facteur volé suffit à percer un service cloud ; la MFA et un encadrement strict des tiers (évaluation, chiffrement, audit) sont indispensables, sans jamais déléguer la responsabilité.
- La MFA aurait pu contenir l'impact d'un mot de passe volé
- Intégrer un tiers IDaaS impose évaluation, chiffrement et audit réguliers
- Plusieurs organisations partageant des identités requièrent un dépôt commun (X.500/LDAP) et la FIM
SSO n'est pas FIM
Le cours appelle parfois le SSO « reduced sign-on » ou même « federated ID management », ce qui entretient la confusion. Pour l'examen, gardez la distinction : le SSO est une expérience de login (un seul login donne accès à toutes les ressources autorisées à l'intérieur d'un périmètre), tandis que la FIM est une relation de confiance (trust) entre security domains distincts, portée par SAML ou OAuth. Une fédération produit souvent une expérience SSO, mais l'inverse n'est pas vrai : on peut avoir un SSO purement interne sans aucune fédération. Si la question parle de confiance entre organisations différentes, c'est FIM ; si elle parle d'un login unique vers plusieurs applications d'un même périmètre, c'est SSO.
Resident IdP vs federated IdP, et qui décide
Deux pièges se cumulent autour de l'IdP. D'abord la terminologie : un resident IdP (local, incumbent) se limite à attester des identités de son propre security domain, tandis qu'un federated IdP atteste la validité de credentials appartenant à un autre security domain ; ne les inversez pas. Ensuite la décision finale : l'IdP n'est qu'un brokering service qui fournit l'assertion que le principal est bien qui il prétend être ; c'est le SP (via son authorization server) qui prend la décision accept/reject. Une question piège vous présentera l'IdP comme « celui qui autorise » : c'est faux, il atteste, il n'autorise pas.
La due care/diligence ne se sous-traite jamais
Quand on confie l'identité à un tiers (IDaaS), il est tentant de croire que la responsabilité part avec le service. Faux. Le cours est explicite : peu importe l'outsourcing, l'offboarding ou la relation fournisseur, le fardeau ultime de la due care et de la due diligence reste TOUJOURS avec votre organisation. On délègue l'exécution d'une tâche, jamais la responsabilité de s'assurer qu'elle est bien faite. Sur une question d'examen, si une réponse suggère que choisir un fournisseur réputé décharge l'organisation de sa responsabilité légale, écartez-la : l'organisation doit toujours évaluer, surveiller et auditer le tiers.
Point de contrôle — Vérification des acquis
-
Dans le modèle de confiance fédérée, quels sont les trois composants qui consomment les common digital identities ?
- A Le client/principal, le SP/RP et l'IdP
- B L'utilisateur, le pare-feu et la base de données
- C Le SSO server, le legacy system et le token
- D Le CapEx, l'OpEx et le multitenancy
Réponse & justification
Réponse : A — Le client/principal, le SP/RP et l'IdP
La fédération repose sur trois composants : le client ou principal, le SP ou RP, et l'IdP. Les autres options mélangent des éléments d'architecture SSO, des contraintes économiques ou des composants techniques sans rapport avec le modèle de confiance fédérée.
-
Un SSO est décrit comme « tous les œufs dans le même panier ». Quelle mitigation du single point of failure le cours cite-t-il explicitement ?
- A Ajouter de la 2FA et une limitation d'accès time/geolocation
- B Supprimer le central credential repository
- C Désactiver la password synchronization
- D Remplacer SAML par du texte clair
Réponse & justification
Réponse : A — Ajouter de la 2FA et une limitation d'accès time/geolocation
Le risque qu'un seul jeu de credentials ouvre toutes les ressources se mitige par des mécanismes additionnels comme la 2FA et la limitation par time/geolocation. Supprimer le repository casserait le SSO, et désactiver la synchronisation l'empêcherait de fonctionner.
-
Une organisation envisage une IDaaS en mode cloud. Quel couple avantage/risque correspond à ce modèle ?
- A Avantage : scalabilité et accès partout ; risque : multitenancy et données d'identité chez le provider
- B Avantage : aucun fournisseur impliqué ; risque : CapEx élevé
- C Avantage : contrôle total on-premises ; risque : setup instantané
- D Avantage : suppression de la due diligence ; risque : aucun
Réponse & justification
Réponse : A — Avantage : scalabilité et accès partout ; risque : multitenancy et données d'identité chez le provider
Le cloud élimine le coût et le temps initiaux, apporte scalabilité et accès depuis n'importe où ; ses risques tiennent à la multitenancy, aux outages et aux données d'identité sensibles détenues par un fournisseur externe. Les autres options décrivent l'on-premises ou sont fausses (la due diligence ne disparaît jamais).
-
Dans un flux de fédération, qui prend la décision finale accept/reject de l'accès ?
- A Le SP, via son authorization server
- B L'IdP, car il atteste l'identité
- C Le principal lui-même
- D L'identity database
Réponse & justification
Réponse : A — Le SP, via son authorization server
L'IdP est un brokering service : il fournit l'assertion que le principal est bien qui il prétend être, mais c'est le SP qui maintient l'authorization server et reste responsable de la décision finale accept/reject. Confondre les deux rôles est un piège classique.
Points essentiels à retenir
- FIM = relation de confiance entre security domains ; trois composants : principal, SP/RP, IdP.
- L'IdP est un brokering service qui atteste ; le SP (authorization server) décide accept/reject.
- Resident IdP atteste son propre domaine ; federated IdP atteste un autre domaine.
- SSO = un login unique vers toutes les ressources autorisées ; le client simule la frappe ID/password.
- Le single point of failure du SSO (« tous les œufs dans le même panier ») se mitige par 2FA et limitation time/geo.
- SSO n'est pas FIM : expérience de login vs confiance entre domaines ; SAML et OAuth portent la fédération.
- La JIT identity provisionne identité et privilèges à la demande, avec escalation/de-escalation (PAM, session, endpoint, help desk).
- IDaaS = identité fournie en service par un tiers ; modèles on-premises (contrôle/CapEx), cloud (scalable/multitenancy), hybrid (intégration).
- La due care et la due diligence restent toujours avec l'organisation, même en cas d'outsourcing.
- Dropbox 2012 : un mot de passe employé volé suffit ; la MFA et l'encadrement strict des tiers sont indispensables.
Modèles et mécanismes d'autorisation
Prérequis : Module M1 (subjects, objects et opérations) et module M3 (autorisation et décision d'accès).
L'autorisation ne se réduit pas à cocher « accès accordé » : elle repose sur des modèles formels qui traduisent une politique de sécurité en décisions permit/deny reproductibles. Ce module distingue d'abord deux familles de modèles que l'examen confond souvent. Les security models (Biba, Bell-LaPadula, Clark-Wilson, revus en Domaine 3) encadrent ce qu'un subject a le droit de faire sur un object, en particulier pour protéger l'intégrité. Les access control models, eux, traduisent ces concepts en fonctions concrètes qui autorisent ou refusent une opération.
Nous parcourons ensuite l'arbre des décisions de conception. Le premier choix structurant oppose MAC, DAC et NDAC : la politique doit-elle être imposée centralement à tous, ou laissée à la discrétion des owners et managers locaux ? À partir de là se déclinent RBAC (rôles par fonction métier), RuBAC (listes de règles when/where/if), ABAC (attributs sujet/ressource/environnement) et le risk-based access control (seuils dynamiques selon le risque courant).
À la fin du module, vous saurez relier une exigence métier au bon modèle, distinguer RBAC de RuBAC, comprendre pourquoi RuBAC est une implémentation de DAC et NDAC une application mandatory de RBAC, et décrire la chaîne d'application d'une politique (PDP, PEP, context handler) selon NIST SP 800-162.
6.1 Deux familles de modèles : security models et access control models
Deux types de modèles fondent les implémentations de contrôle d'accès. Les security models se concentrent sur les actions qu'un subject peut effectuer dans un système, ou dont il doit être empêché. Ils sont liés aux procédures de traitement de l'information du Domaine 2 et ont été revus en Domaine 3 : Biba, par exemple, protège l'integrity. Les access control models, eux, traduisent les concepts d'un ensemble choisi de security models en fonctions concrètes qui permettent ou refusent qu'une action ait lieu. Ils fournissent des cadres formels et conceptuels pour répondre aux besoins de sécurité d'un système.
Un exemple de bibliothèque mélange bien les deux. Une bibliothèque maintient une vaste collection de documents numériques, tous déjà publiés en version imprimée. Leur contenu n'est pas confidentiel, mais il ne doit pas être modifié par quiconque autre que des archivistes formés et autorisés. Ici la confidentialité n'est pas en jeu, c'est l'intégrité des données qui prime : un security model comme Biba est pertinent. Un bibliothécaire peut gérer la collection, l'accès des usagers, le catalogage et la qualité, mais seules les deux dernières fonctions exigent de pouvoir modifier le contenu d'un document.
Pour appliquer strictement ces contrôles, avec une politique sans exception, on recourt au mandatory access control. Un role-based access control peut alors forcer le bibliothécaire à changer de rôle, via une connexion séparée, pour obtenir les permissions nécessaires aux altérations de documents. Cet exemple illustre comment un access control model traduit la politique d'intégrité d'un security model en décisions d'accès opérationnelles.
- Security models encadrent ce qu'un subject peut faire (Biba protège l'intégrité)
- Access control models traduisent la politique en décisions permit/deny
- L'exemple bibliothèque : intégrité > confidentialité, donc Biba + RBAC mandatory
- Changer de rôle (login séparé) pour obtenir les droits de modification
6.2 Opérations atomiques et définition NIST des AC models
NIST SP 800-192 définit les access control models comme « les présentations formelles des politiques de sécurité appliquées par les systèmes de contrôle d'accès », utiles pour prouver les limites théoriques d'un système. Ces modèles comblent l'écart d'abstraction entre la policy et le mechanism. Le Domaine 5 traite DAC, MAC, NDAC (nondiscretionary access control), RBAC (role-based), RuBAC (rule-based) et ABAC (attribute-based) ; NIST SP 800-192 fournit la définition de chacun.
Chaque modèle propose une stratégie différente pour contrôler quels subjects peuvent effectuer les fonctions de base sur les objects. Ces opérations fondamentales ou atomiques incluent généralement la lecture (read), l'écriture ou modification (write/modify), la création (create), la suppression (delete) et le chargement pour exécution comme programme (execute). Les fonctions complexes d'un système, comme monter ou démonter un disque virtuel, ne sont rien d'autre que des séquences de ces opérations atomiques.
D'autres opérations fondamentales gérées par les AC systems incluent la capacité de lire, définir ou changer les paramètres de sécurité associés à un object, ou d'influencer la façon dont ces propriétés sont héritées par d'autres objects ou subjects qui l'utilisent. Comprendre ce socle atomique est essentiel : un modèle de contrôle d'accès ne fait jamais qu'autoriser ou refuser une combinaison de ces opérations élémentaires.
- NIST SP 800-192 : AC model = présentation formelle de la politique appliquée
- Opérations atomiques : read, write/modify, create, delete, execute
- Les fonctions complexes sont des séquences d'opérations atomiques
- Six modèles couverts : DAC, MAC, NDAC, RBAC, RuBAC, ABAC
6.3 Le premier choix : MAC, DAC ou NDAC
La première décision des concepteurs de sécurité reflète une stratégie de contrôle d'accès à grande échelle. Choisir entre MAC, DAC et NDAC, c'est décider si les politiques doivent être fixées et appliquées centralement à tous les utilisateurs, ou si les circonstances permettent aux users ou aux managers locaux de faire ces choix. La Figure 5.6 résume ces trois options selon Policy Decisions, Security Planning et Models Supported.
Dans le MAC (Mandatory Access Control), les décisions de politique sont prises par une autorité centrale, pas par le owner individuel d'un object, et l'utilisateur ne peut pas changer ses droits d'accès. Exemple militaire : un data owner ne décide pas qui détient une habilitation top-secret, et ne peut pas reclasser un object de top-secret à secret. Planification centralisée top-down, tout security model est supporté.
Le DAC (Discretionary Access Control) laisse une part du contrôle à la discrétion du owner de l'object, ou de toute personne autorisée à en gérer l'accès. Le owner détermine qui a quels droits. Le DAC offre la plus grande flexibilité, mais c'est aussi la forme la plus vulnérable : le owner peut propager des faiblesses contribuant à l'aggregation d'accès et de privilèges. Windows et Android utilisent des formes de DAC pour que l'acheteur adapte les contrôles. Le NDAC (Nondiscretionary Access Control) applique le role-based access control de façon mandatory, avec une autorité centrale décidant la politique ; users et line-level managers ne peuvent pas modifier les droits. Le NDAC souligne que RBAC, RuBAC et ABAC peuvent tous être implémentés de manière mandatory ou discretionary.
- MAC : autorité centrale, user ne peut pas changer (ex : top-secret militaire)
- DAC : discrétion du owner, la plus flexible MAIS la plus vulnérable (Windows, Android)
- NDAC : RBAC mandatory, autorité centrale, line-level managers exclus
- RBAC, RuBAC, ABAC : implémentables en mandatory ou discretionary
6.4 Role-Based Access Control (RBAC) et ses usages None/Limited/Hybrid/Full
Le RBAC est une politique d'accès qui restreint l'accès au système aux utilisateurs autorisés via des rôles définis par fonction métier. L'organisation crée des rôles selon les job functions et leur associe les autorisations (privileges) nécessaires aux opérations. L'accès peut être accordé par le owner comme en DAC, et appliqué selon une politique comme en MAC : le RBAC se décline en plusieurs intensités (Figures 5.7, 5.8, 5.9).
Le RBAC se déploie en quatre usages. None : aucun accès n'est protégé par les rôles, les privilèges individuels doivent être définis et gérés un par un (par exemple, on bloque par user ID le personnel accounts payable pour qu'il ne lance pas Visual Studio). Limited : certaines applications sont RBAC-protected (le rôle accounts payable peut lancer QuickBooks, le rôle développeur teste d'autres apps), d'autres non (la bureautique et les navigateurs comme Firefox ou Chrome restent libres). Hybrid : toute combinaison de fonctionnalités ; un individu peut porter un ou plusieurs rôles, chacun permettant une ou plusieurs applications, les droits du Role A différant de ceux du Role B même pour la même application.
Full : chaque application, y compris bureautique et navigateurs, exige une permission basée sur un rôle. Exemple point-of-sale : les rôles salesclerk et sales supervisor existent, mais seul le supervisor peut lancer le price override ou le transaction void. Exemple HR : un manager RH se connecte avec son rôle HR pour accéder aux dossiers du personnel, puis se déconnecte et se reconnecte avec son rôle bureautique pour la correspondance courante. Le principe clé : pour changer de permissions, l'utilisateur change de rôle.
- RBAC : rôles par job function, privilèges attachés au rôle
- Quatre usages : None, Limited, Hybrid, Full
- Limited : QuickBooks pour accounts payable, bureautique libre
- Full : point-of-sale supervisor (price override) vs salesclerk ; HR change de rôle
6.5 Rule-Based (RuBAC) et Attribute-Based Access Control (ABAC)
Le RuBAC (Rule-Based Access Control) est une liste prédéfinie de règles qui déterminent l'accès avec une granularité supplémentaire : when, where et if le système autorisera read, write ou execute selon des conditions spéciales. Il est géré par le system owner et représente une implémentation de DAC. Ces règles s'expriment souvent en logique booléenne et peuvent être complexes. Exemple : un CFO a normalement de larges permissions pour consulter la finance et autoriser de très gros paiements ; le RuBAC peut restreindre l'usage de ces privilèges en accès distant à un ensemble étroit d'adresses IP, à certains jours et heures. Si le CFO voyage dans des zones à risque, cela protège l'organisation en cas d'enlèvement ou de vol du smartphone.
L'ABAC (Attribute-Based Access Control) accorde les droits via des politiques qui combinent des attributs : attributs de l'utilisateur, de la ressource et de l'environnement. C'est une forme plus simple de RuBAC. La Figure 5.10 montre une access attempt testée en parallèle sur plusieurs attributs (Who, When, Where, Role, Resource, Threat, Recent actions), aboutissant à PASS (accès approuvé) ou FAIL (refus, challenge supplémentaire ou alerte). La décision dépend non seulement des attributs habituels de subjects et objects, mais aussi de variables environnementales.
Ainsi les mêmes données sur un archive server peuvent exiger des restrictions différentes que sur le production system. Les utilisateurs en accès distant peuvent être restreints selon leur localisation géographique exacte au moment de la requête, ce qui aide à repérer les connexions via des VPN comme TOR qui masquent l'IP par sauts constants : un utilisateur ne change pas de pays paquet par paquet. PayPal et de nombreuses banques utilisent ce type de contrôle.
- RuBAC : règles prédéfinies when/where/if, géré par le system owner = implémentation de DAC
- Exemple CFO : restriction IP, jours et heures, protection en voyage à risque
- ABAC : attributs user/resource/environment, forme plus simple de RuBAC
- ABAC ajoute l'environnement : archive vs production, géolocalisation, détection TOR/VPN (PayPal, banques)
6.6 Risk-Based Access Control et l'application de la politique (PDP/PEP)
Une critique récurrente de la plupart des AC models est qu'ils supposent des risques relativement statiques sur des semaines ou des mois. Cela permet de construire, tester puis valider les bases de règles ou de paramètres de RuBAC, RBAC ou ABAC, et de ne les changer qu'à la création de nouveaux subjects et objects. Le risk-based access control rompt avec cette hypothèse : il fournit aux administrateurs des paramètres pour relever ou abaisser dynamiquement les seuils de filtrage des requêtes d'accès.
En circonstances de bas risque, stables, le système peut se contenter d'une dual-factor authentication à deux couches de challenge. Lorsque les administrateurs voient les conditions de risque externe augmenter, ils activent des challenges ou filtres supplémentaires que les utilisateurs doivent franchir. Exemple : les virements internationaux. En risque routinier, un client peut soumettre des demandes jusqu'à un plafond sans restriction ; le risk-based AC exige des vérifications supplémentaires si le transfert vise un groupe de pays montrant de forts niveaux de fraude. De même, on durcit les challenges pendant les pics de shopping en ligne, qui sont aussi des saisons de fraude par carte, puis on relâche ensuite. Des approches émergentes utilisent le behavior modeling par boucles de rétroaction internes, voire des smart contracts pour lier le comportement de l'utilisateur à la gestion du risque.
Toute politique d'accès doit être appliquée par un mécanisme. Selon NIST SP 800-162, ce mécanisme assemble les informations d'autorisation : l'object protégé, le subject demandeur, les politiques applicables et tout contexte nécessaire. En évaluant chaque élément, il s'appuie sur un policy decision point (PDP) qui rend la décision, un policy enforcement point (PEP) qui l'applique, et un context handler (coordinateur de workflow) qui gère la collecte des attributs requis pour décider.
- La plupart des modèles supposent un risque statique ; le risk-based AC ajuste les seuils dynamiquement
- Bas risque : 2FA ; montée du risque externe : challenges/filtres supplémentaires
- Exemples : virements internationaux, saisons de fraude, behavior modeling, smart contracts
- NIST SP 800-162 : PDP décide, PEP applique, context handler collecte les attributs
Cas d'étude
Activité 5.4 : moderniser le Limited RBAC d'Aeros 3
Contexte : Aeros 3 implémente un Limited Role Based Access Control depuis plusieurs années. Tamika veut conserver cette implémentation, mais les politiques et les mécanismes d'application doivent être significativement mis à jour après des signalements récents d'accès non autorisés. En revue, Tamika sollicite des collègues de confiance dans des secteurs hors aviation pour discuter du modèle de contrôle d'accès et de ses politiques.
Question : Comment le RBAC peut-il être utilisé efficacement comme mécanisme d'autorisation en entreprise ? Quels sont ses avantages et ses défis potentiels dans le contexte d'Aeros 3 gérant l'accès à des actifs critiques ?
Voir l'analyse et la correction
Le RBAC assigne les permissions selon les rôles métier, ce qui rationalise la gestion des accès et garantit que chacun n'accède qu'aux ressources nécessaires - une application directe du least privilege. Il existe plusieurs façons de l'implémenter : None (aucun accès basé sur les rôles), Limited (certaines apps protégées par rôle), Full (toute app exige un rôle) et Hybrid (combinaison), où les administrateurs définissent des rôles avec des permissions spécifiques.
L'avantage pour Aeros 3 est la lisibilité : les droits suivent la fonction, pas l'individu, ce qui simplifie l'audit et la révocation. Le défi central, mis en lumière par les accès non autorisés constatés, est la dérive : des rôles obsolètes ou trop larges accumulent des privilèges. Des revues régulières et des mises à jour des rôles sont nécessaires pour maintenir leur pertinence et leur sécurité.
La discipline clé : chaque changement de statut d'emploi, de fonctions ou de responsabilités doit déclencher une revue des permissions associées. Pour Aeros 3, cela signifie coupler le Limited RBAC à un processus de revue déclenché par les événements RH (joiner, mover, leaver), et resserrer les mécanismes d'application pour fermer les chemins d'accès non autorisés détectés.
À retenir : Le RBAC n'est efficace que s'il vit : chaque changement de statut déclenche une revue des rôles, sinon les privilèges dérivent et ouvrent des accès non autorisés.
- Le RBAC aligne les permissions sur la fonction métier et facilite l'audit
- Sans revue régulière, les rôles dérivent et causent des accès non autorisés
- Chaque changement d'emploi ou de responsabilités déclenche une revue des permissions
RBAC vs RuBAC : rôle contre règle
Les sigles se ressemblent mais les modèles diffèrent. Le RBAC (Role-Based) accorde l'accès selon le rôle métier de l'utilisateur : on change de rôle pour changer de permissions. Le RuBAC (Rule-Based) accorde l'accès selon une liste prédéfinie de règles en logique booléenne avec granularité when/where/if (IP, jours, heures), géré par le system owner. Retenez le R supplémentaire : RuBAC = Rule. À l'examen, si la décision dépend de la fonction de la personne, c'est RBAC ; si elle dépend de conditions horaires, géographiques ou logiques, c'est RuBAC.
RuBAC = implémentation de DAC ; NDAC = RBAC mandatory ; ABAC = RuBAC enrichi
Trois relations piègent les candidats. Le RuBAC, géré par le system owner, est une implémentation de DAC, pas un modèle mandatory par nature. Le NDAC applique le RBAC de façon mandatory via une autorité centrale - donc NDAC n'est pas l'opposé de RBAC mais une manière de l'imposer. L'ABAC est une forme plus simple de RuBAC, mais plus riche dans sa décision car il intègre des attributs d'environnement (lieu, heure, menace) en plus des attributs de subjects et objects. Ne dites pas que ces modèles s'excluent : ils se composent.
Domain Access Control n'existe pas
Les types de contrôle d'accès couverts sont DAC, MAC, NDAC, RBAC, RuBAC et ABAC. Domain Access Control n'est pas un type de contrôle d'accès : c'est un distracteur d'examen. Quand une question demande de repérer l'intrus dans une liste de modèles, méfiez-vous des intitulés plausibles mais inventés. RuBAC, MAC et DAC sont réels ; Domain AC ne l'est pas.
Point de contrôle — Vérification des acquis
-
Dans les implémentations modernes de contrôle d'accès, quel modèle mappe les utilisateurs aux applications puis aux rôles ?
- A RBAC
- B Limited RBAC
- C RuBAC
- D DAC
Réponse & justification
Réponse : B — Limited RBAC
En Limited RBAC, l'utilisateur reçoit d'abord une permission d'accès à une application, puis un rôle donné au sein de cette application : il peut accéder à une application financière mais seulement comme user, pas comme développeur. Le RBAC simple place les users dans des groupes par fonction sans cette double association app-puis-rôle. RuBAC repose sur des règles, DAC sur la discrétion du owner.
-
Parmi les propositions suivantes, laquelle n'est PAS un type de contrôle d'accès ?
- A Domain Access Control
- B Rule-Based Access Control (RuBAC)
- C Mandatory Access Control (MAC)
- D Discretionary Access Control (DAC)
Réponse & justification
Réponse : A — Domain Access Control
Domain Access Control n'est pas un type de contrôle d'accès, c'est un distracteur. RuBAC repose sur une liste de règles prédéfinies offrant une granularité fine. MAC fait décider une autorité centrale, pas les owners individuels. DAC laisse une part de discrétion au owner de l'object ou à son délégué.
-
Dans un environnement militaire, un data owner ne peut ni accorder une habilitation top-secret ni reclasser un object. Quel modèle est appliqué ?
- A MAC (Mandatory Access Control)
- B DAC (Discretionary Access Control)
- C RuBAC (Rule-Based Access Control)
- D ABAC (Attribute-Based Access Control)
Réponse & justification
Réponse : A — MAC (Mandatory Access Control)
En MAC, les décisions de politique sont prises par une autorité centrale et l'utilisateur ne peut pas changer ses droits ni la classification d'un object : c'est exactement le cas militaire décrit. Le DAC laisserait cette discrétion au owner. RuBAC et ABAC reposent respectivement sur des règles et des attributs, sans correspondre à cette interdiction stricte de reclassement par le owner.
-
Quel modèle de contrôle d'accès offre la plus grande flexibilité mais constitue la forme la plus vulnérable ?
- A DAC (Discretionary Access Control)
- B MAC (Mandatory Access Control)
- C NDAC (Nondiscretionary Access Control)
- D RBAC (Role-Based Access Control)
Réponse & justification
Réponse : A — DAC (Discretionary Access Control)
Le DAC laisse le owner décider des accès, ce qui offre la plus grande flexibilité mais aussi la plus grande vulnérabilité : le owner peut propager des faiblesses et favoriser l'aggregation de privilèges (Windows, Android). MAC et NDAC centralisent la décision et sont donc moins flexibles mais plus robustes ; RBAC structure par rôle.
-
Une banque refuse un virement selon le lieu de connexion, l'heure et le niveau de fraude du pays destinataire, en combinant des attributs d'environnement. Quel modèle est en jeu ?
- A ABAC (Attribute-Based Access Control)
- B RBAC (Role-Based Access Control)
- C MAC (Mandatory Access Control)
- D NDAC (Nondiscretionary Access Control)
Réponse & justification
Réponse : A — ABAC (Attribute-Based Access Control)
L'ABAC accorde l'accès en combinant des attributs d'utilisateur, de ressource et d'environnement (lieu, heure, menace), exactement le scénario bancaire décrit. Le RBAC déciderait par rôle métier, sans variables environnementales. MAC et NDAC centralisent la décision mais ne reposent pas sur cette combinaison d'attributs contextuels.
Points essentiels à retenir
- Deux familles : security models (Biba, intégrité, Domaine 3) et access control models (traduisent la politique en permit/deny).
- NIST SP 800-192 : un AC model est une présentation formelle de la politique appliquée, comblant l'écart policy/mechanism.
- Opérations atomiques gérées par un AC system : read, write/modify, create, delete, execute.
- Premier choix MAC/DAC/NDAC : autorité centrale ou discrétion locale (Fig 5.6 : Policy Decisions, Security Planning, Models Supported).
- MAC : autorité centrale, user ne change rien (militaire). DAC : la plus flexible mais la plus vulnérable (Windows, Android).
- NDAC : RBAC appliqué de façon mandatory ; RBAC, RuBAC et ABAC peuvent être mandatory ou discretionary.
- RBAC : rôles par fonction métier, usages None/Limited/Hybrid/Full ; pour changer de droits, on change de rôle.
- RuBAC : liste de règles when/where/if, géré par le system owner, implémentation de DAC.
- ABAC : forme plus simple mais plus riche de RuBAC ; ajoute les attributs d'environnement (PayPal, banques, détection TOR).
- Risk-based AC : seuils dynamiques selon le risque ; NIST SP 800-162 : PDP décide, PEP applique, context handler collecte les attributs.
Cycle de vie des identités et provisioning (JML)
Prérequis : Avoir suivi M2 (notion d'identité et identity proofing) et M6 (modèles d'autorisation MAC/DAC/RBAC/ABAC).
Dans une organisation, chaque identité devrait posséder l'exact ensemble de permissions nécessaire à ses tâches assignées - no more and no less. Cette règle paraît évidente, mais la maintenir dans le temps est un processus continu : les personnes rejoignent ou quittent des projets, des étapes de projet, voire des postes. Gérer ce flux est l'objet du cycle de vie des identités, souvent résumé par l'acronyme JML (Joiner, Mover, Leaver).
Deux idées contre-intuitives structurent ce module. D'abord, les identités ne concernent pas que les humains : une carte réseau a une MAC address, un CPU un numéro de série, un logiciel une clé d'identification unique, un processus un process ID. Ensuite, elles ne concernent pas que le personnel permanent : les guests et visitors accèdent à une partie des locaux ou systèmes, et l'organisation doit pouvoir différencier les visiteurs d'aujourd'hui sur le Wi-Fi du parking des invités d'hier présents sur site.
Les permissions ne sont pas statiques : elles doivent suivre les changements de poste, de tâches et de responsabilités. Des revues périodiques ET event-driven sont donc indispensables pour éviter le privilege creep, l'accumulation indue de privilèges au-delà du nécessaire. À la fin du module, vous saurez dérouler le cycle provisioning -> management -> offboarding, attribuer chaque étape au bon rôle (data owner vs data custodian), et concevoir une account access review qui débusque comptes inactifs, permissions excessives et comptes sans permission.
7.1 Le cycle de vie des identités : provisioning, management, offboarding
Une identité est un label et une structure de données que tout subject et tout object d'un système doivent posséder pour être désignés de façon claire et non ambiguë. Traditionnellement, l'IAM s'est concentré sur les humains : on associe des privilèges d'accès à une identité afin que l'enforcement des politiques de sécurité soit possible à l'exécution. Mais les identités ne sont ni réservées aux humains, ni au personnel permanent. Au niveau matériel, une carte réseau possède une MAC address et un CPU un numéro de série, gravés dans le firmware (réinitialisables ou spoofables). Un logiciel installé reçoit une clé d'identification unique ; chaque instance lancée comme processus reçoit un process ID. Les guests et visitors ont aussi besoin d'identités, et l'organisation doit différencier les visiteurs du parking d'aujourd'hui des invités présents hier sur site.
Fournir une identité à chaque user humain ou non humain et lui rattacher des privilèges suppose un cycle de provisioning, management (review) et offboarding, illustré par la Figure 5.11. Ce cycle gravite autour d'un central store qui contient l'information sur les identités et leurs privilèges, et qui trace aussi le comportement de chacune. Chaque identité démarre sa vie au stade du provisioning et la termine lorsqu'elle est disabled puis deprovisioned.
Le rythme, lui, diffère d'une identité à l'autre. Un schéma d'activité inapproprié ou suspect chez un user peut déclencher des revues fréquentes et urgentes pour décider d'une action corrective, tandis qu'un autre n'en exigera que rarement. Certains changent peu souvent de rôle ou de fonction ; d'autres initient beaucoup de changements en self-service. Le principe directeur reste constant : l'exact ensemble de permissions, ni excessif ni insuffisant, pour ne pas exposer l'organisation et ses actifs.
- Toute identité démarre au provisioning et finit deprovisioned, mais le rythme des revues diffère
- Les identités couvrent humains ET non humains (MAC, CPU serial, clé logicielle, process ID)
- Guests et visitors ont des identités à différencier jour par jour
- Le central store conserve identités, privilèges et comportements
7.2 Provisioning : qui demande, qui approuve, qui implémente
Le provisioning suit une chaîne de responsabilités précise. La demande d'accès part en général du hiring manager ou du superviseur de l'unité de travail, qui engage ensuite la sécurité IT et les administrateurs pour valider et implémenter. Le requérant fournit des preuves d'identité (documents officiels ou ID numérique) ; l'identity proofing les authentifie pour s'assurer que la personne est bien, de façon unique et non ambiguë, celle qu'elle prétend être, et non un imposteur.
Vient ensuite la décision d'autorisation. Le data owner (ou asset owner, ou manager fonctionnel responsable) revoit la demande et transmet une approbation ou un rejet au data custodian. C'est le point d'examen clé : le data owner est accountable - il décide et donne la granularité des permissions, que ce soit en termes très larges (par exemple all operational environments, but not development ones) ou très fins selon les procédures de sécurité. Le data custodian, lui, est responsible : il crée le compte avec les bonnes permissions. Selon le système, l'environnement et les privilèges, cela peut exiger la création de plusieurs comptes avec des credentials distincts, et le push (populating) de ces account IDs vers diverses plateformes applicatives, d'autres systèmes ou d'autres domaines de l'infrastructure.
Le data custodian notifie enfin le user et le data owner de la création du compte. Le user commence alors à accéder aux systèmes et ressources dans le périmètre des permissions accordées. Ne confondez pas ce trio avec le data processor : ce dernier traite la donnée pour le compte du data controller ; il est responsible mais non accountable de la décision d'accès.
- La demande part du hiring manager ; le requérant fournit des preuves (identity proofing)
- Le data owner approuve et fixe la granularité ; il est accountable
- Le data custodian crée le compte (parfois multiple) et le pousse vers les plateformes
- Notification du user et du data owner à la création
7.3 User Behavior Review : détecter les écarts de comportement
Une fois le compte actif, la phase de management commence par la définition de schémas de comportement acceptables et attendus dans la plupart des circonstances. Ces patterns sont dérivés des job and task descriptions, qui identifient l'accès aux protected assets dont le user a besoin. Par définition, toute autre tentative d'accès devrait être interdite. Comme pour tout contrôle, la première décision est administrative : des directives de politique posent les limites, puis des contrôles technical et physical sont implémentés sur une base coût-bénéfice.
La plupart des régimes de conformité imposent une revue périodique de tous les comptes pour déterminer si un abus de privilèges a été tenté ou réussi, ou si une action pourtant dans les limites des permissions a produit une violation de sécurité. Une user behavior review peut révéler plusieurs circonstances nécessitant une intervention : usage inapproprié des ressources (sans forcément mettre l'information en danger) ; identités de visitor ou guest qui tentent à répétition de dépasser leurs permissions ; rogue devices cherchant à se connecter ou à se faire passer pour des équipements approuvés (par exemple de faux points d'accès Wi-Fi) ; tentatives de contourner le configuration management et les systèmes de contrôle, ou de court-circuiter les allowed/blocked lists ; mauvais usage répété d'applications (données d'entrée invalides ou incomplètes) ; usage de ressources autorisées mais à des horaires, jours ou circonstances anormaux pour cette classe d'identité.
Chacun de ces signaux peut indiquer soit un employé à réorienter vers les bonnes procédures, soit une tentative concertée d'un attaquant pour sonder, fingerprinter ou pénétrer le système via une identité dérobée. Ce dernier cas demande parfois un modeling comportemental plus sophistiqué, surtout avec le travail à distance et la mobilité. Un processus de review et d'adjudication peut être nécessaire pour protéger à la fois l'organisation et l'employé d'une accusation injustifiée, en particulier si d'autres signaux (relations avec collègues ou superviseurs) suggèrent un risque d'insider threat.
- Les patterns acceptables viennent des job/task descriptions ; le reste est interdit
- La revue périodique est imposée par la conformité
- Signaux : usage inapproprié, guest dépassant ses droits, rogue device, contournement, horaires anormaux
- Un comportement déviant peut signaler un insider threat ou une identité dérobée
7.4 Job or Duties Review : contenir le privilege creep
Les changements de besoins métier, de menaces, d'évaluations de risque et de profils d'activité d'identités spécifiques - qu'il s'agisse de personnes, de constructs virtuels ou de devices - sont autant de déclencheurs d'une modification des permissions. Le privilege creep survient quand une identité collecte les permissions nécessaires à de nouvelles tâches mais ne relinquit pas celles devenues inutiles. Laissé sans contrôle, ce phénomène expose l'organisation : un user surchargé de droits peut, sciemment ou non, perturber les opérations ou exposer les actifs.
Les identités changent de fonctions, de jobs, de duties ou de responsabilités au gré de l'organisation. Ces changements modifient les assets auxquels le user doit accéder, ce qui doit piloter l'ajustement de ses permissions. L'achèvement d'un projet majeur, par exemple, justifie de downgrader les droits d'accès et de modification liés à ce projet. Une responsabilité managériale accrue peut exiger l'accès à des informations de supervision de plus haut niveau tout en retirant l'accès aux données opérationnelles détaillées de l'ancien poste. L'exemple canonique : un accounting clerk dont la carrière le mène au poste de CFO ne devrait plus disposer des permissions nécessaires pour originer un paiement.
Tout cela illustre l'application combinée de need to know et de separation of duties comme impératifs de conception. Concrètement, chaque changement de statut d'emploi, de jobs assignés, de duties ou de responsabilités devrait déclencher une revue de permissions associée. C'est précisément ce qui prévient le privilege creep : non pas une revue calendaire isolée, mais une revue event-driven attachée à chaque transition de l'identité.
- Privilege creep = accumulation de droits non relinquis lors des changements de poste
- Chaque changement de statut/poste doit déclencher une revue de permissions
- Clerk devenu CFO : retirer le droit d'originer un paiement (separation of duties)
- Need to know + separation of duties guident la modification des droits
7.5 Disable and Deprovision : désactiver, pas supprimer
Toutes les identités prennent fin. Users humains et non humains peuvent devenir redondants ou migrer vers d'autres organisations et environnements. Un humain qui quitte l'emploi ou change d'association ne devrait plus voir son identité système rester active (le décès conduit aussi à une désactivation puis un deprovisioning). Les users non humains peuvent être décommissionnés et retirés de l'usage actif. Des décisions de management peuvent en outre imposer une désactivation temporaire, par exemple pour un employé sur le départ ou supposé sous stress, contrainte ou impairment. Les professionnels de la sécurité doivent travailler avec les RH/HR pour garantir des procédures de disablement prompt des comptes quand c'est nécessaire.
Le deprovisioning propage la désactivation des permissions à travers l'ensemble des systèmes. Point d'examen majeur : les comptes ne sont pas supprimés (deleted) mais désactivés (disabled). Le data custodian ou les administrateurs IAM réalisent ces tâches. La désactivation est réversible et conserve les traces ; la suppression détruit l'historique.
La data retention et l'archiving sont une part cruciale de cette étape. Les régimes légaux et réglementaires peuvent dicter des périodes de rétention minimales ET maximales pour les données relatives à une personne. L'investigation d'événements en cours, après qu'une identité a été désactivée et que la personne a quitté l'organisation, peut exiger de fouiller les archives. Les advanced persistent threats (APT) ont montré leur propension à s'introduire, installer des capacités de reconnaissance et de command and control, puis à rester dormants jusqu'au moment voulu : les données d'archive sont parfois le seul moyen de détecter une telle présence. C'est pourquoi disable plutôt que delete sert directement la capacité d'enquête.
- Désactiver (disable) et non supprimer (delete) : réversible, traces conservées
- Disable temporaire pour un employé sous stress ou sur le départ ; travailler avec les RH
- Le deprovisioning propage la désactivation à tous les systèmes
- Data retention min/max légale ; archives utiles contre les APT dormants
7.6 Account Access Review : comptes inactifs, excessifs, sans permission
La revue d'accès aux comptes, régulière, structurée et systématique, est une part impérative du cycle de provisioning. Elle est généralement organisée par groupes de comptes - par exemple tous les system administrators d'un domaine ou d'une business unit. Ce sont des planned reviews, à ne pas confondre avec les event-triggered reviews d'un compte individuel évoquées plus haut. Ces revues identifient les écarts entre rôles et permissions des users, devices, processes et systèmes, et révèlent des activités irrégulières qui, bien que permises, méritent un examen complémentaire.
Trois familles d'anomalies ressortent typiquement. Les comptes inactifs non révoqués : un employé licencié, volontairement ou non, ou parti en congé prolongé puis quittant l'organisation, dont le compte reste actif. Les comptes aux permissions excessives : quand un employé change de poste et reçoit de nouveaux droits sans révocation des anciens - c'est la permission aggregation, cousine du privilege creep. Et, plus surprenant, les comptes sans permissions : car si un individu a besoin de droits pour son rôle mais qu'ils ne lui sont pas alloués, il trouvera un moyen de faire son travail, parfois en empruntant les credentials d'un autre user, ce qui détruit notre capacité de non-repudiation.
Ces revues doivent être conduites en continu pour repérer toute activité suspecte à temps ; planifiées et régulières, elles révèlent des vulnérabilités appelant révocation, disablement ou suppression de permissions, voire d'un compte entier. Il est vital d'y inclure les privileged accounts - system accounts comme administrator, sudo ou root - très convoités des attaquants pour élever leurs capacités. La revue couvre donc trois natures de comptes : user, system et service.
- Revue planned par groupes, distincte de la revue event-triggered individuelle
- Détecte comptes inactifs non révoqués et permission aggregation
- Comptes sans permission = risque : emprunt de credentials, perte de non-repudiation
- Inclure les privileged et service accounts (administrator, sudo, root)
Cas d'étude
Activité 5.5 : décrire les étapes clés du cycle de vie chez Aeros 3
Contexte : Après les discussions sur les modèles et politiques de contrôle d'accès, Tamika revisite le cycle de vie des identités pour s'assurer que les processus IAM d'Aeros 3 s'alignent sur les bonnes pratiques. Elle doit décrire les étapes clés du cycle de provisioning d'accès et leur importance pour le maintien de la sécurité.
Question : Quelles sont les étapes clés du cycle de vie des identités et d'accès, et pourquoi chacune est-elle significative pour la sécurité ?
Voir l'analyse et la correction
Le cycle comprend des étapes telles que l'onboarding, les role changes (changements de rôle) et l'offboarding. L'onboarding garantit que les nouveaux users reçoivent l'accès nécessaire - ni plus ni moins - via un provisioning piloté par le data owner et exécuté par le data custodian.
Les role changes adaptent les permissions à l'évolution des responsabilités : chaque changement de statut doit déclencher une revue afin d'éviter le privilege creep et la permission aggregation, en appliquant need to know et separation of duties.
L'offboarding révoque promptement l'accès des employés partis, minimisant le risque d'accès non autorisé ; on désactive sans supprimer pour préserver les archives. Enfin, des revues et audits réguliers (user behavior review et account access review) maintiennent l'efficacité du cycle dans la durée.
À retenir : Onboarding, role changes et offboarding, soutenus par des revues régulières, forment un cycle qui garde chaque identité à l'exact niveau de droits requis.
- Chaque étape sert un objectif de sécurité distinct (accès juste, adaptation, révocation)
- Les revues régulières sont ce qui maintient le cycle efficace dans le temps
Profil 5.5 : account access review après un fort turnover
Contexte : Aeros 3 a connu un turnover important sur l'année écoulée. Tamika découvre que, durant cette période, l'organisation n'a conduit aucune account access review distincte des revues event-triggered. Elle doit définir comment mener et gérer ces revues, en se concentrant sur les comptes user, system et service.
Question : Comment Tamika peut-elle conduire et gérer les account access reviews chez Aeros 3, en couvrant comptes user, system et service ? Quelles fréquence, processus et considérations clés pour assurer conformité et sécurité dans la durée ?
Voir l'analyse et la correction
Tamika doit instaurer des revues planned, structurées par groupes de comptes (par exemple tous les administrators d'une business unit), distinctes des revues event-triggered individuelles. Étant donné le fort turnover, la priorité est de détecter les comptes inactifs non révoqués d'employés partis, les permissions excessives issues de permission aggregation lors de changements de poste, et les comptes sans permission qui poussent les users à emprunter des credentials et détruisent la non-repudiation.
La fréquence doit combiner une cadence régulière (alignée sur les régimes de conformité) et un déclenchement continu pour repérer toute activité suspecte à temps. Le processus rapproche rôles et permissions effectives, puis recommande révocation, disablement ou suppression des droits, voire d'un compte entier.
Un point vital : inclure les privileged accounts - comptes system comme administrator, sudo ou root - très convoités des attaquants, ainsi que les service accounts non humains, souvent oubliés. La coordination avec les RH garantit que les départs déclenchent un disablement prompt.
À retenir : Après un fort turnover, une account access review planifiée et par groupes, couvrant user, system et service accounts, est indispensable pour éliminer les comptes orphelins et les droits résiduels.
- Les revues planifiées de groupe complètent, sans remplacer, les revues event-triggered
- Privileged et service accounts doivent être inclus, pas seulement les comptes user
Data owner vs data custodian vs data processor
Question piège classique : qui approuve une demande d'accès ? La bonne réponse est le data owner, car il est accountable et décide ; il fixe aussi la granularité des droits. Le data custodian est seulement responsible : il implémente la décision en créant le compte. Le data processor traite la donnée pour le compte du data controller et ne décide pas de l'accès. Si une option dit only senior managers, c'est faux : un data owner peut être un senior manager, mais ce n'est pas toujours le cas.
Disable vs delete
À l'offboarding, l'examen attend disable, pas delete. La désactivation est réversible et préserve les traces ; la suppression détruit l'historique. Cette nuance sert directement la data retention (périodes légales min ET max) et les investigations futures, notamment contre les APT dormants dont seules les archives peuvent révéler la présence. Un disable temporaire convient aussi à un employé sous stress ou sur le départ. Ne répondez jamais delete the account immediately à une question d'offboarding.
Privilege creep, permission aggregation et comptes sans permission
Privilege creep et permission aggregation décrivent le même mal : des droits accumulés lors de changements de poste sans révocation des anciens ; la parade est une revue déclenchée à chaque changement de statut, guidée par need to know et separation of duties. Piège plus subtil : un compte SANS permission est aussi un risque. Privé des droits nécessaires, le user emprunte les credentials d'un collègue pour faire son travail, ce qui détruit la non-repudiation. L'examen peut demander pourquoi un manque de permissions est dangereux : la réponse est l'emprunt de credentials et la perte de traçabilité.
Point de contrôle — Vérification des acquis
-
Parmi les étapes suivantes, laquelle ou lesquelles sont requises dans le processus d'onboarding lors de la gestion des identités ?
- A Creation seule
- B Allocation seule
- C Defining seule
- D All of the above (les trois sont requises)
Réponse & justification
Réponse : D — All of the above (les trois sont requises)
La gestion des identités commence toujours par la création du compte (Creation), manuelle ou en self-provisioning. On définit ensuite le rôle et les règles nécessaires (Defining), puis on alloue l'accès aux ressources selon cette définition (Allocation). Aucune seule ne suffit : les trois sont requises, d'où all of the above.
-
Dans le flux de gestion des identités, un individu demande l'accès à des ressources comme des données. Qui est responsable de l'approbation de cette demande ?
- A Le data processor
- B Le data owner
- C Le data custodian
- D Uniquement les senior managers
Réponse & justification
Réponse : B — Le data owner
L'accès est toujours approuvé par le data owner : ce rôle est accountable et décide donc de l'accès. Il peut être un senior manager, mais pas nécessairement. La demande est ensuite transmise au data custodian, qui est responsible de l'implémentation mais ne décide pas. Le data processor traite la donnée pour le controller, sans trancher l'accès.
-
Un comptable promu CFO conserve son ancien droit d'originer des paiements tout en obtenant de nouveaux droits de supervision. Comment nomme-t-on cette accumulation et comment l'éviter ?
- A Identity proofing ; par une revue à l'embauche
- B Privilege creep ; par une revue de permissions déclenchée à chaque changement de statut
- C Single sign-on ; par la centralisation des comptes
- D Deprovisioning ; par la suppression immédiate du compte
Réponse & justification
Réponse : B — Privilege creep ; par une revue de permissions déclenchée à chaque changement de statut
L'accumulation de droits non relinquis lors de changements de poste est le privilege creep (ici aussi permission aggregation). La parade est une job or duties review déclenchée à chaque changement de statut, appliquant separation of duties : le CFO ne doit plus pouvoir originer un paiement.
-
Lors de l'offboarding d'un employé qui quitte l'organisation, quelle action est recommandée pour son compte ?
- A Supprimer (delete) immédiatement le compte pour libérer de l'espace
- B Désactiver (disable) le compte sans le supprimer, et propager le deprovisioning
- C Laisser le compte actif au cas où l'employé reviendrait
- D Transférer les credentials à un collègue
Réponse & justification
Réponse : B — Désactiver (disable) le compte sans le supprimer, et propager le deprovisioning
Les comptes sont désactivés (disabled), pas supprimés (deleted) : la désactivation est réversible et préserve les traces nécessaires à la data retention et aux investigations (y compris contre les APT dormants). Le deprovisioning propage ensuite la désactivation à tous les systèmes. Transférer des credentials détruirait la non-repudiation.
-
Une account access review révèle qu'un employé ayant changé de poste a obtenu de nouveaux droits sans révocation des anciens. Comment nomme-t-on cette anomalie ?
- A Permission aggregation
- B Compte inactif
- C Compte sans permission
- D Identity proofing
Réponse & justification
Réponse : A — Permission aggregation
Le cumul de nouveaux droits sans révocation des anciens lors d'un changement de poste est la permission aggregation (forme de privilege creep). À distinguer du compte inactif (compte d'un parti non révoqué) et du compte sans permission (qui pousse à emprunter des credentials et détruit la non-repudiation).
Points essentiels à retenir
- Le principe directeur : chaque identité a l'exact ensemble de droits nécessaire - no more and no less.
- Les identités couvrent humains ET non humains (MAC address, CPU serial, clé logicielle, process ID) et incluent guests/visitors à différencier jour par jour.
- Le cycle de vie va de provisioning à management puis offboarding, autour d'un central store (Fig 5.11).
- Au provisioning : le hiring manager demande, le requérant prouve (identity proofing), le data owner approuve (accountable), le data custodian crée le compte (responsible).
- Les permissions ne sont pas statiques : revues périodiques ET event-driven, déclenchées à chaque changement de statut.
- Privilege creep et permission aggregation = droits accumulés sans révocation ; need to know et separation of duties les contiennent (clerk devenu CFO ne peut plus originer un paiement).
- À l'offboarding on disable, on ne delete pas : réversible, traces conservées, data retention min/max, archives utiles contre les APT dormants.
- L'account access review est planned, par groupes, distincte des revues event-triggered ; elle couvre comptes user, system et service.
- Anomalies clés : comptes inactifs non révoqués, permissions excessives, et comptes sans permission (qui poussent à emprunter des credentials et détruisent la non-repudiation).
- Une user behavior review détecte usage hors horaires, rogue devices, guests dépassant leurs droits et signale un possible insider threat.
Comptes à privilèges (PAM), escalade et service accounts
Prérequis : Module M7 (account access review et revue périodique des permissions).
La revue des comptes ne s'arrête pas aux utilisateurs ordinaires. Elle doit impérativement couvrir les comptes à privilèges - les system accounts comme administrator, sudo ou root - parce que ce sont précisément ceux que les attaquants convoitent le plus. Obtenir un de ces comptes, c'est le « holy grail » de l'attaquant : une fois en main, il peut parcourir le réseau, lire, copier, altérer ou détruire données, fichiers de configuration et processus.
Ce module relie trois sujets que l'examen aime tester ensemble : la protection des comptes privilégiés (renommage, obscurcissement des attributs et des SID, MFA), la mécanique de la privilege escalation (verticale vs horizontale) et sa prévention, puis la place de l'IAAA dans le modèle élargi CIANA+PS. Il se termine sur les service accounts, ces comptes non humains souvent surdimensionnés qui doivent être ramenés au least privilege.
À la fin du module, vous saurez distinguer une escalade verticale (élévation de niveau) d'une escalade horizontale (lateral movement), expliquer pourquoi la security by obscurity seule ne suffit pas, et appliquer le least privilege aux service accounts.
8.1 Comptes privilégiés dans la revue d'accès et security by obscurity
Quand on parle de revue des comptes, il est vital d'y inclure les comptes à privilèges : les system accounts tels que administrator, sudo ou root. Ces comptes sont hautement désirables pour des attaquants qui les cherchent justement pour élever leur capacité d'action dans le réseau de l'organisation. Réduire leur visibilité est donc la première ligne de défense.
Il est conseillé d'éviter de lier le nom du compte à sa fonction, car cela augmente les chances qu'il soit ciblé. Changer le nom d'un compte privilégié est ainsi la première couche de défense. Mais la security by obscurity exige ici plus que renommer un utilisateur ou un compte système : d'autres attributs, comme l'identifiant numérique statique assigné par le système (le SID sous Windows), peuvent révéler à l'attaquant la vraie nature d'un compte. Ces attributs doivent donc être modifiés eux aussi.
Sur les systèmes Microsoft Windows, plusieurs security identifiers (SID) de comptes intégrés peuvent et devraient être obscurcis : Administrator (le seul compte ayant par défaut le contrôle total du système), Default Account (compte neutre introduit avec Windows 10 et Windows Server 2016 pour exécuter des processus multi-utilisateurs ou agnostiques), Guest (compte sans mot de passe pour les personnes sans compte individuel, désactivé par défaut) et Domain Administrators (groupe global dont les membres administrent le domaine et sont propriétaires par défaut de tout objet créé). Retenez le principe d'examen : l'obscurité n'est jamais un contrôle suffisant à elle seule ; elle complète, mais ne remplace pas, les contrôles de fond.
- La revue d'accès DOIT couvrir les comptes privilégiés, pas seulement les utilisateurs
- Renommer un compte est la première couche ; ne pas lier le nom à la fonction
- Obscurcir aussi les attributs (SID statique), sinon l'obscurité est illusoire
- SID Windows à masquer : Administrator, Default Account, Guest, Domain Administrators
8.2 Privilege escalation : le « holy grail » de l'attaquant
La privilege escalation est l'acte d'élever ses permissions d'accès à des ressources protégées en exploitant un bug, un défaut de conception ou un oubli de configuration dans un OS ou une application. Une attaque d'escalade survient quand un attaquant obtient un compte utilisateur régulier, contourne le canal d'autorisation normal et finit par s'octroyer à lui-même des permissions élevées.
Obtenir des privilèges élevés est le « holy grail » de l'attaquant. S'il réussit à s'emparer d'un compte privilégié, il peut alors accéder à diverses parties de l'organisation, puis examiner, copier, altérer ou supprimer purement et simplement données importantes, fichiers de configuration ou processus. Si l'organisation réalise qu'elle a été compromise, il est vital de déterminer quelles permissions l'attaquant a réussi à obtenir, et quels processus et ressources ont pu être impactés et comment.
Beaucoup d'organisations ajoutent des protections supplémentaires sur les utilisateurs considérés comme privilégiés, comme les domain admins et les database administrators, en ajoutant une multi-factor authentication (MFA) pour réduire le risque d'usage de ces comptes dans une attaque d'escalade. Attention au piège : comme les utilisateurs peuvent agréger des permissions au fil de leur emploi (permission aggregation), et comme ils sont considérés comme « réguliers », les contrôles d'accès renforcés peuvent ne pas leur être appliqués. Ces comptes à permissions agrégées peuvent alors être exploités par un attaquant tout en échappant aux contrôles réservés aux comptes privilégiés.
- L'escalade exploite bug, défaut de conception ou oubli de configuration
- Obtenir un compte privilégié = holy grail ; capacité de lire/altérer/détruire
- MFA sur domain admins et DBA réduit le risque d'escalade
- Piège : un user régulier aux permissions agrégées contourne les contrôles renforcés
8.3 Verticale vs horizontale, et comment prévenir l'escalade
Il existe deux approches pour mener une attaque d'escalade. La vertical privilege escalation (aussi appelée privilege elevation) se produit quand l'attaquant utilise un compte auquel il a déjà accès (ou dont il a obtenu un usage non autorisé) pour exécuter des applications ou services à des niveaux de permission supérieurs. Cela arrive quand les développeurs ont fait de mauvaises hypothèses sur les cas d'usage des fonctions privilégiées, ou quand l'application permet l'injection de commandes ou d'exploits. Les attaques de phishing qui poussent la victime à saisir ses identifiants servent fréquemment de tremplin (stepping stone) à l'escalade verticale.
La horizontal privilege escalation (aussi appelée lateral movement dans un système) se produit quand l'attaquant utilise un compte auquel il a accès pour découvrir, fingerprinter et accéder à d'autres ressources. Par exemple, un utilisateur d'applications et de données sur un serveur peut sauter vers un autre serveur et accéder à ses données ou ressources. Ces attaques requièrent l'élévation des privilèges associés aux comptes abusés et exigent généralement un plus haut degré de sophistication technique.
Prévenir l'escalade suppose d'agir sur les vulnérabilités humaines, système et de processus. Côté humain : security awareness training et simulations de phishing. S'y ajoutent des contrôles d'accès comme la two-factor authentication (2FA), une gestion continue des patchs et des vulnérabilités, et de la détection-réponse via IDS, IPS et SIEM. Ces couches se combinent pour casser la chaîne phishing → compte régulier → élévation → mouvement latéral.
- Verticale = élévation de niveau (privilege elevation), souvent via phishing/injection
- Horizontale = lateral movement, sauter entre ressources, plus de sophistication technique
- Le phishing est un tremplin (stepping stone) classique vers l'escalade verticale
- Prévention : awareness, simulations phishing, 2FA, patch/vuln mgmt, IDS/IPS/SIEM
8.4 IAAA implémente CIANA+PS
Les domaines précédents ont identifié les capacités critiques que les programmes et contrôles de sécurité doivent adresser, résumées par l'acronyme CIANA : confidentiality, integrity, availability, non-repudiation et authenticity, plus privacy et safety. Correctement implémenté, un système IAM répond à ces besoins via ses fonctions intégrées d'identity, authentication, authorization et accounting (IAAA).
Prenons l'integrity comme exemple. Elle exige une grande confiance dans le fait que seuls des processus de confiance, invoqués par des subjects de confiance (utilisateurs humains ou non), modifient les actifs informationnels. Fournir cette confiance repose sur trois piliers : des solutions d'identity management qui créent et prouvent les identités puis gèrent les privilèges associés ; des authentication controls qui restreignent l'accès aux seules identités valides ; et des authorization controls qui n'autorisent les identités authentifiées et de confiance qu'à utiliser des outils de confiance pour effectuer uniquement les actions permises par leurs permissions.
La safety et la privacy ajoutent souvent des exigences de forte non-repudiation et d'authenticity. Les accounting controls d'un système IAAA fournissent la preuve auditable qu'exige la non-repudiation. Et garantir que les commandes modifiant des informations sensibles ne peuvent être qu'authentiques - émises par une autorité compétente - résulte de la combinaison des fonctions IAAA. Autrement dit, c'est l'IAAA pris comme un tout qui matérialise CIANA+PS dans le système.
- IAAA (identity, authentication, authorization, accounting) implémente CIANA+PS
- L'integrity exige que seuls des process de confiance modifient les actifs
- La non-repudiation s'appuie sur l'accounting (preuve auditable)
- L'authenticity = commande émise par une autorité compétente
8.5 Service accounts et application du least privilege
Certains system accounts sont prédéfinis comme service accounts. Ces comptes non humains peuvent posséder des privilèges étendus dans un système informatique et se comporter comme le système lui-même au sein du réseau. Ils disposent souvent d'un accès et d'un contrôle non bridés (unabated) sur la plupart des objets du système.
Dans certains cas, ces comptes sont actifs sans exiger aucune méthode d'authentification et ne sont associés à aucun compte utilisateur connecté, ce qui pose un risque significatif : pas de propriétaire humain identifiable, pas de session interactive, donc une surface d'attaque idéale pour qui veut « se comporter comme le système ». C'est précisément le maillon qu'une escalade cherche à atteindre.
Or, beaucoup de service accounts n'ont pas besoin des niveaux de privilège élevés que leur accorde la configuration par défaut : ils sont surdimensionnés. Lorsque c'est le cas, réduire les privilèges au niveau le plus bas possible est une application appropriée du principe de least privilege. En pratique : inventorier les service accounts lors de la revue d'accès, retirer les droits inutilisés, exiger une authentification forte quand c'est possible et tracer leur activité. Le least privilege transforme un compte « comme le système » en un compte « juste ce qu'il faut pour son service ».
- Les service accounts ont des privilèges étendus et se comportent comme le système
- Risque : parfois actifs sans authentification, non liés à un user connecté
- Souvent surdimensionnés par la config par défaut
- Remède : appliquer le least privilege et réduire au niveau strictement nécessaire
Cas d'étude
Du phishing au domain admin : anatomie d'une escalade
Contexte : Chez un distributeur régional, un comptable reçoit un courriel imitant le portail RH et saisit ses identifiants sur une fausse page. L'attaquant obtient ainsi un compte utilisateur régulier. Depuis ce poste, il découvre qu'une application interne tourne sous un service account « svc-backup » dont les privilèges par défaut donnent un contrôle quasi total sur les serveurs de fichiers, sans MFA et sans propriétaire humain. Il abuse de ce service account pour exécuter des commandes à un niveau supérieur, puis rebondit d'un serveur de fichiers à un autre. L'organisation ne s'en aperçoit que trois semaines plus tard, lors d'une revue d'accès tardive.
Question : Identifiez les phases d'escalade en jeu et listez les contrôles manquants qui auraient brisé la chaîne d'attaque.
Voir l'analyse et la correction
La chaîne suit un schéma d'examen classique. Le phishing sert de stepping stone : il fournit un compte régulier. L'abus du service account surdimensionné pour exécuter des commandes à un niveau de permission supérieur est une vertical privilege escalation (privilege elevation). Le rebond ensuite d'un serveur de fichiers à un autre pour découvrir et accéder à d'autres ressources est une horizontal privilege escalation, c'est-à-dire du lateral movement.
Plusieurs contrôles manquants ont rendu l'attaque possible. Côté humain, l'absence de security awareness training et de simulations de phishing a laissé passer le courriel initial ; la 2FA aurait empêché la réutilisation directe des identifiants volés. Côté comptes, le service account « svc-backup » était surdimensionné : le least privilege aurait dû réduire ses droits au strict nécessaire, et une authentification forte aurait dû lui être imposée plutôt qu'un fonctionnement sans authentification ni propriétaire. Côté détection, un SIEM corrélant les connexions anormales et les sauts inter-serveurs aurait alerté bien avant trois semaines.
Enfin, la security by obscurity des comptes privilégiés (renommage et masquage des attributs comme le SID) aurait compliqué le repérage du service account, sans jamais constituer un contrôle suffisant à elle seule. La leçon de gouvernance : des revues d'accès régulières, et non seulement déclenchées par un événement, auraient détecté à la fois le service account surdimensionné et les permissions agrégées exploitées.
À retenir : Une escalade réelle combine élévation verticale et mouvement latéral ; chaque maillon (phishing, service account surdimensionné, absence de SIEM) est un contrôle qui aurait pu la stopper.
- Le phishing est un tremplin vers l'escalade verticale ; la 2FA casse la réutilisation des identifiants
- Un service account surdimensionné devient le vecteur d'élévation ; appliquer le least privilege
- Le lateral movement se détecte par un SIEM corrélant les sauts inter-serveurs
- Des revues d'accès régulières (pas seulement event-triggered) auraient révélé le compte surdimensionné
Verticale vs horizontale
L'examen oppose souvent les deux types d'escalade. La vertical privilege escalation (privilege elevation) est une élévation de niveau : exécuter à un niveau de permission supérieur, par exemple passer d'un user régulier à root ou admin. La horizontal privilege escalation est un lateral movement : se déplacer entre ressources de même niveau, sauter de serveur en serveur pour découvrir et accéder à d'autres données. Si le stem parle de « niveau supérieur de permissions », c'est vertical ; s'il parle de « sauter vers d'autres ressources/serveurs », c'est horizontal.
Security by obscurity ne suffit jamais seule
Renommer le compte « Administrator » est la première couche, mais l'examen attend que vous sachiez que cela ne suffit pas : l'identifiant numérique statique (le SID Windows) reste un attribut qui trahit la fonction réelle du compte. Il faut donc aussi masquer ces attributs. Plus largement, la security by obscurity n'est jamais un contrôle suffisant à elle seule : elle complète le least privilege, la MFA et la détection, elle ne les remplace pas. Une réponse qui propose « renommer le compte » comme unique mesure est incomplète.
Les permissions agrégées contournent les contrôles renforcés
Piège subtil : on protège les domain admins et DBA par MFA, mais on oublie qu'un utilisateur « régulier » peut avoir accumulé des permissions au fil des ans (permission aggregation). Comme il reste classé « régulier », les contrôles d'accès renforcés réservés aux comptes privilégiés ne lui sont pas appliqués. Un attaquant qui s'empare de ce compte hérite alors d'un pouvoir étendu tout en échappant aux protections. La bonne réponse insiste sur les revues d'accès régulières pour repérer et révoquer ces permissions agrégées.
Point de contrôle — Vérification des acquis
-
Quel type d'attaque d'escalade survient quand un utilisateur légitime (titulaire d'un compte) tente d'obtenir des niveaux de permission supérieurs ?
- A Vertical escalation
- B Horizontal escalation
- C Privilege spoofing
- D Privilege manipulation
Réponse & justification
Réponse : A — Vertical escalation
La vertical escalation (privilege elevation) survient quand un acteur utilise un compte qu'il possède déjà (ou dont il a obtenu l'usage) pour exécuter des applications ou services à des niveaux de permission supérieurs. Le spoofing consiste à se faire passer pour quelqu'un d'autre, pas à élever ses propres droits. L'horizontal escalation est un lateral movement vers d'autres ressources de même niveau. « Privilege manipulation » est un terme générique qui ne désigne pas ce type précis.
-
Parmi les propositions suivantes, laquelle est un type d'attaque d'escalade de privilèges ?
- A Vertical
- B Domain
- C Root
- D Admin
Réponse & justification
Réponse : A — Vertical
L'escalade verticale est le type valide : un acteur élève les identifiants d'un user régulier vers un niveau supérieur comme root ou admin. « Domain » désigne un ensemble d'objets (users, machines), pas un type d'escalade. « Root » et « Admin » sont des comptes déjà au plus haut niveau : il n'y a aucun intérêt à y mener une escalade.
-
Un attaquant ayant pris un compte sur un serveur l'utilise pour découvrir, fingerprinter et accéder à d'autres serveurs au même niveau de privilège. Comment nomme-t-on cette technique ?
- A Horizontal escalation (lateral movement)
- B Vertical escalation (privilege elevation)
- C Permission aggregation
- D Security by obscurity
Réponse & justification
Réponse : A — Horizontal escalation (lateral movement)
Découvrir, fingerprinter et accéder à d'autres ressources en sautant de serveur en serveur définit l'horizontal privilege escalation, aussi appelée lateral movement. L'escalade verticale viserait au contraire un niveau de permission supérieur. La permission aggregation est l'accumulation de droits dans le temps. La security by obscurity est une mesure défensive, pas une technique d'attaque.
-
Une revue d'accès découvre un service account dont la configuration par défaut accorde un contrôle quasi total sur tous les serveurs de fichiers, bien au-delà de son besoin réel. Quelle est la mesure la plus appropriée ?
- A Réduire ses privilèges au niveau strictement nécessaire (least privilege)
- B Le renommer pour appliquer la security by obscurity
- C Le laisser tel quel car les service accounts doivent agir comme le système
- D Lui ajouter d'autres permissions pour éviter les blocages
Réponse & justification
Réponse : A — Réduire ses privilèges au niveau strictement nécessaire (least privilege)
Beaucoup de service accounts sont surdimensionnés par leur config par défaut. Lorsque c'est le cas, réduire les privilèges au niveau le plus bas possible est l'application appropriée du least privilege. Le renommage (obscurity) ne réduit pas les droits excessifs. Laisser le compte intact perpétue le risque. Ajouter des permissions aggrave exactement le problème.
Points essentiels à retenir
- La revue d'accès doit inclure les comptes privilégiés (administrator, sudo, root), très convoités comme « holy grail » de l'attaquant.
- La security by obscurity exige de renommer le compte ET de masquer les attributs ; le SID statique trahit sinon la fonction.
- SID Windows à obscurcir : Administrator, Default Account, Guest, Domain Administrators.
- Vertical escalation (privilege elevation) = exécuter à un niveau de permission supérieur ; tremplin fréquent : le phishing.
- Horizontal escalation = lateral movement : découvrir et accéder à d'autres ressources, plus de sophistication technique.
- Prévention : awareness training, simulations de phishing, 2FA, patch/vuln mgmt continu, IDS/IPS/SIEM.
- Piège : un user régulier aux permissions agrégées échappe aux contrôles renforcés réservés aux comptes privilégiés.
- IAAA (identity, authentication, authorization, accounting) implémente CIANA+PS ; l'accounting fonde la non-repudiation.
- L'integrity exige que seuls des process de confiance, invoqués par des subjects de confiance, modifient les actifs.
- Les service accounts sont souvent surdimensionnés et parfois sans authentification : appliquer le least privilege.
Systèmes d'authentification : Kerberos, SAML, OAuth/OIDC, RADIUS/TACACS+, LDAP/AD
Prérequis : M2 (identity store et identity proofing) et M5 (single sign-on et fédération).
Les contrôles d'accès se sont implémentés de multiples façons. Certains sont nés de designs propriétaires d'éditeurs qui sont ensuite passés en open source ou ont été licenciés ; d'autres sont partis d'implémentations open source fondées sur des standards publiés. Le point commun des systèmes qui ont duré, c'est leur capacité à s'adapter et à s'améliorer face à l'évolution du threat landscape. Quelle que soit l'approche, tous délivrent les mêmes fonctions de base attendues d'un système intégré d'identity management et de contrôle d'accès, et tous sont étroitement liés à la notion de session.
Ce module passe en revue les méthodes d'authentification en usage, du simple couple username/password à la MFA et aux méthodes centralisées modernes. Les infrastructures à base de Linux ou Unix combinent souvent Kerberos et LDAP ; les infrastructures Microsoft reposent presque invariablement sur Active Directory. La plupart de ces produits sont platform-agnostic et OS-agnostic, et presque tous utilisent le X.500 Directory Access Protocol ou une variante.
À la fin du module, vous saurez situer chaque protocole sur les axes authentication vs authorization, distinguer RADIUS de TACACS+, expliquer le flux de tickets Kerberos (TGT puis ST), décrire les rôles SAML et OAuth/OIDC, et raisonner sur le modèle de responsabilité d'une offre IDaaS.
9.1 Early concepts : du password à la MFA, Linux vs Microsoft
Plusieurs méthodes d'authentification coexistent aujourd'hui, du simple couple username/password à la MFA, jusqu'aux méthodes centralisées modernes les plus complexes. Certaines, comme RADIUS, peuvent sembler legacy mais restent bien présentes sur le marché. Le choix de la pile dépend largement de l'écosystème : les infrastructures fondées sur Linux ou Unix combinent souvent Kerberos et LDAP, tandis que les infrastructures centrées sur Microsoft reposent presque invariablement sur Active Directory.
La plupart de ces produits sont, à des degrés divers, platform-agnostic et OS-agnostic : ils supportent quasiment n'importe quel device ou système réseau capable de parler leur protocole. Point structurant pour l'examen : presque tous utilisent le X.500 Directory Access Protocol de l'ITU-T, ou une variante. LDAP en est l'héritier allégé adapté à la pile IP, et Active Directory s'appuie sur LDAP.
Ce module détaille donc une famille cohérente : annuaires (LDAP, AD), protocoles AAA réseau (RADIUS, TACACS+), authentification par tickets (Kerberos), et fédération/délégation moderne (SAML, OAuth, OIDC). Tous sont liés à la notion de session vue dans M3.
- Méthodes du simple username/password à la MFA et aux systèmes centralisés
- Linux/Unix = Kerberos + LDAP ; Microsoft = Active Directory
- Presque tous les systèmes dérivent du X.500 Directory Access Protocol
- Ces produits sont largement platform-agnostic et OS-agnostic
9.2 RADIUS et TACACS+ : protocoles AAA réseau
RADIUS (Remote Authentication Dial-In User Service) est né au début des années 1990 pour authentifier les clients dial-up et a longtemps servi le remote access classique. Interrogé par un client qui fournit des credentials candidats, un serveur RADIUS répond par un message Access-Accept, Access-Reject ou Access-Challenge. Cette structure légère permet des authentifications rapides et simples quand c'est possible, ou de basculer vers la MFA et des dialogues challenge-response quand ils sont requis. RADIUS supporte des extensions comme l'EAP (Extensible Authentication Protocol) et ses nombreuses variantes, et il prend en charge le roaming des utilisateurs et des devices.
TACACS (Terminal Access Controller Access Control System) est issu des besoins d'automatisation de l'authentification des utilisateurs distants au Department of Defense. Vers 1984 il s'est répandu sur les serveurs Unix ; en 1990 Cisco a développé une version propriétaire, Extended TACACS (XTACACS). Ni TACACS ni XTACACS n'étaient des standards ouverts, et ils sont largement remplacés aujourd'hui, même si on les croise encore sur de vieux systèmes.
TACACS+ est un protocole entièrement nouveau, inspiré de concepts de TACACS, développé lui aussi par le DoD puis enrichi et commercialisé par Cisco. Il sépare authentication, authorization et accounting en fonctions distinctes, donnant aux administrateurs un meilleur contrôle et une meilleure visibilité sur chacune. Il utilise TCP pour une connexion de meilleure qualité et chiffre ses paquets vers et depuis le serveur TACACS+. Il définit des politiques selon le type d'utilisateur, le rôle, la location, le type de device ou l'heure de la journée, s'intègre bien à Active Directory et à LDAP (utile pour le SSO), et offre un command logging et une central management renforcés pour répondre aux besoins AAA du réseau.
- RADIUS : léger, Access-Accept/Reject/Challenge, EAP, roaming, années 90
- TACACS/XTACACS : DoD puis Cisco, propriétaires, largement remplacés
- TACACS+ : nouveau protocole, sépare A/A/A, TCP, paquets chiffrés
- TACACS+ : politiques par type/rôle/location/heure, intègre AD/LDAP
9.3 LDAP et Active Directory : services d'annuaire
LDAP (Lightweight Directory Access Protocol) est un service d'annuaire fondé sur le standard X.500 Directory Access Protocol de l'ITU-T, conçu pour tirer parti de la pile IP qui a évolué après l'adoption de X.500. On le compare souvent à un ancien annuaire téléphonique : un serveur LDAP contient des informations sur les utilisateurs dans un directory tree, et les clients l'interrogent pour obtenir des détails. Les grandes entreprises maintiennent des serveurs LDAP répliqués en différents points du réseau pour répondre vite.
Chaque entrée de l'arbre LDAP est une collection d'informations sur un objet, pointée par un identifiant unique appelé Distinguished Name (DN) : le DN représente le chemin complet dans l'arbre jusqu'à l'entrée voulue. Des composants nommés appelés attributs portent les données de l'entrée (numéros de téléphone, adresses physiques, postales, email). LDAP peut aussi authentifier des credentials via la commande bind : dans le cas le plus simple, bind compare le password candidat à l'attribut password de l'utilisateur et renvoie un code de succès ou l'erreur invalid credentials.
L'Active Directory de Microsoft, développé pour les réseaux de domaine Windows, utilise LDAP versions 2 et 3. C'est un service d'annuaire propriétaire. Un serveur exécutant Active Directory Domain Services (AD DS), appelé domain controller, authentifie les utilisateurs et autorise les actions, vérifie leurs credentials et définit leurs droits d'accès. AD DS fournit un stockage de données hiérarchique structuré pour les utilisateurs, imprimantes et services. À plus grande échelle, multi-réseaux ou multi-entreprises, Active Directory Federation Services (AD FS) permet de partager l'information entre partenaires de confiance et offre du SSO aux partenaires fédérés, comme les autres systèmes FIM.
- LDAP dérive de X.500 ; annuaire arborescent répliqué, requêtes clients
- DN = chemin complet ; attributs = données ; bind authentifie un password
- Active Directory propriétaire utilise LDAP v2/v3, authentifie et autorise
- AD FS apporte le SSO fédéré aux partenaires de confiance
9.4 OAuth 2.0 et OpenID Connect : autorisation et authentification
OAuth 2.0 est lui-même un protocole d'autorisation. Grâce à lui, une application cliente peut demander l'accès à une ressource protégée à l'entité qui la possède. La demande va à un authorization server, qui doit authentifier le owner, valider la demande, obtenir l'autorisation du resource owner, puis relayer un authorization token au resource server hébergeant la ressource protégée. Ses quatre composants sont le resource owner (l'utilisateur), l'application cliente, l'authorization server et le resource server.
OpenID Connect (OIDC) est une implémentation au-dessus du framework d'autorisation OAuth 2.0 : c'est une couche d'authentification. Le RP (relying party) est une application OAuth 2.0 qui demande un ID token à un OpenID Connect Provider (OP). Les champs du token contiennent des données appelées claims sur l'utilisateur (le subject, ou sub, identifié par un identifiant localement unique) et sur le timing de l'événement d'authentification : issued at time (iat) et expiration time (exp). Le token contient aussi l'issuer identifier (iss) de l'OP et le client identifier (audience, ou aud) enregistré pour le RP chez l'issuer. Les claims peuvent porter d'autres informations, comme first_name, last_name, etc.
Une façon de voir cette extension d'OAuth 2.0 : OpenID Connect permet en pratique à une application de demander l'autorisation d'authentifier un utilisateur. Là où SAML relaie spécifiquement des requêtes depuis un site web, OIDC peut effectuer l'authentification avec un site web ou une application mobile comme requérant. C'est la grande discrimination d'examen : OAuth = autorisation (déléguer un accès), OIDC = authentification (prouver qui est l'utilisateur).
- OAuth 2.0 = autorisation ; 4 composants dont le user = resource owner
- Authorization server authentifie le owner et relaie un token au resource server
- OIDC = couche d'authentification au-dessus d'OAuth ; RP demande un ID token à un OP
- Claims clés : sub, iss, aud, iat, exp (plus first_name/last_name)
- OIDC marche avec site web OU mobile ; SAML relaie depuis un site web
9.5 Kerberos : KDC, TGT et service ticket
Le nom Kerberos vient de la mythologie grecque : c'est le chien à trois têtes qui gardait l'entrée des Enfers. Le système Kerberos garde un réseau à l'aide de trois éléments : authentication, authorization et auditing. C'est essentiellement un protocole d'authentification réseau conçu pour fournir une authentification forte aux applications client/serveur via la secret key cryptography (chiffrement symétrique). Il repose sur l'interaction de trois systèmes : le système demandeur (le principal), le endpoint server de destination (où réside l'application ou la ressource), et le Key Distribution Center (KDC). Un principal est toute entité interagissant avec le serveur Kerberos (workstation, application, service). Le KDC remplit deux fonctions : authentication server (AS) et ticket-granting server (TGS), et il maintient une base des secret keys de tous les principaux.
Les principaux ont un compte préenregistré avec une secret key dans le KDC. À l'ajout d'un principal au realm, on lui fournit une realm key pour les communications de confiance initiales ; pour un utilisateur, il est courant que Kerberos utilise un hash du password comme user key. Une fois incorporé, l'utilisateur est authentifié par l'AS, qui lui renvoie un authentication ticket (TGT) passé en aveugle au TGS. La possession du TGT prouve que le client a réussi l'authentification et a le droit de demander un service/session ticket (ST). Le TGT est chiffré avec une clé partagée uniquement entre AS et TGS. Le TGS le déchiffre, puis crée un ST chiffré avec une autre clé. Les ST sont valides plus longtemps, typiquement de huit à dix heures, après quoi l'utilisateur doit se réauthentifier. Une fois le TGT émis, plus aucun usage de password : quand une ressource a besoin d'accès, elle demande une copie du ST, chiffrée avec une clé connue du seul TGS et de la ressource ; si la ressource déchiffre le ST, l'accès est accordé.
Points clés des tickets et limites : l'analogie est le passeport (le TGT certifie que vous êtes un citoyen légal mais ne donne pas droit d'entrer dans un autre pays). Les tickets sont stockés dans le Kerb Tray, zone mémoire non-paginable. Kerberos est extrêmement time-sensitive et requiert souvent des daemons NTP : une désynchronisation provoque des échecs d'authentification, un vecteur attractif de DoS. Le but premier est d'assurer des communications privées entre systèmes ; en revanche, Kerberos n'offre pas de mécanisme sécurisé pour transmettre les données, ce qui exigerait IPSec ou MACSec. Ses drawbacks : le KDC est un single point of failure (à mitiger par plusieurs KDC ; en AD DS, tous les domain controllers sont des KDC, supprimant le SPOF), il faut sécuriser physiquement le KDC, la longueur des clés est critique (trop courte = brute force, trop longue = surcharge), et le talon d'Achille reste que le chiffrement est in fine fondé sur des passwords, donc vulnérable au password-guessing.
- Kerberos : 3 éléments (authentication, authorization, auditing), chiffrement symétrique
- KDC = AS + TGS et base des secret keys ; principal, endpoint server
- AS émet le TGT (droit de demander) ; TGS émet le ST (accès), valable 8 à 10 h
- Très time-sensitive (NTP) ; désync = échec d'auth = vecteur DoS
- Kerberos ne transmet pas les données en sécurité : besoin d'IPSec/MACSec
- Drawbacks : KDC = SPOF (mitigé par plusieurs KDC/AD), longueur des clés, password-guessing
9.6 SAML et IDaaS : fédération XML et identité as-a-service
SAML (Security Assertion Markup Language) définit un framework XML pour décrire et échanger de l'information de sécurité entre relations d'affaires en ligne. Cette information est portée par des SAML assertions qui travaillent à travers les frontières de trust domains. SAML a trois rôles : l'IdP (identity provider), le SP/RP (service provider ou relying party) et le user agent. Il s'appuie sur quatre composants : Assertions (comment les messages d'attributs, d'authentification et d'autorisation request-response sont échangés), Bindings (comment les assertions et échanges de messages se font en paires request-response), Protocols (quels protocoles sont utilisés, dont SOAP et HTTP) et Profiles (les use cases combinant assertions, bindings et protocols pour un besoin fonctionnel précis). La Figure 5.13 illustre le support du web browser SSO en huit étapes numérotées entre le service provider, le user agent et l'identity provider.
Côté audit et compliance reporting, l'identity-as-a-service (IDaaS) s'est généralisé : Gartner et d'autres l'ont défini comme un service majoritairement cloud-based, en multi-tenant ou en mode dédié hébergé, mêlant identity management, provisioning, governance et administration. Les fonctions se classent en trois familles : Identity governance and administration (IGA) - provisioning de l'identité dans les systèmes cloud, gestion des privilèges, reset de password ; Access - authentification temps réel des utilisateurs et devices (SSO), autorisation, support de la fédération via SAML ou OAuth ; Intelligence - logging, monitoring, reporting et alerting, soit l'accounting des systèmes AC.
De plus en plus de services de sécurité sont fournis en mode as-a-service. Pour clarifier le vocabulaire souvent flou, focalisez-vous sur deux déterminants. D'abord, qui emploie (et embauche/licencie) les administrateurs qui font les tâches IAM : in-house management (employés directs) ou third-party management (via SLA et contrat avec une organisation externe). Ensuite, où les systèmes et bases AAA sont physiquement hébergés : on-premises (chez vous), cloud-hosted (cloud public, privé ou hybride), ou hybrid (mélange on-premises et cloud, très courant). Les éditeurs ne sont pas toujours précis sur la dénomination de leurs services ; retenez l'essentiel : la responsabilité finale de l'application correcte de ces services reste avec la direction de votre organisation, que les personnes soient internes ou externes, sur site ou dans le cloud. Ne perdez jamais cela de vue.
- SAML : framework XML, 3 rôles (IdP, SP/RP, user agent), assertions entre trust domains
- 4 composants SAML : Assertions, Bindings, Protocols (SOAP/HTTP), Profiles
- Web SSO SAML en 8 étapes (Figure 5.13)
- IDaaS : IGA, Access, Intelligence (=accounting), majoritairement cloud
- Deux déterminants : in-house vs third-party (SLA), on-premises vs cloud vs hybrid
- La responsabilité finale reste avec votre organisation
Cas d'étude
Activité 5.6 : OAuth vs OpenID Connect
Contexte : Lors d'une discussion sur l'adéquation de différents protocoles au sein d'Aeros 3, l'équipe de Tamika pose quelques questions de clarification sur OAuth par rapport à OpenID Connect. Le groupe veut comprendre le rôle de chaque acteur et savoir quand préférer l'un ou l'autre.
Question : Au regard des quatre composants d'OAuth, quel rôle joue l'utilisateur ? Donnez des exemples d'usage d'OAuth puis d'OpenID Connect. Quelles opportunités et quels défis pour les organisations qui migrent vers OpenID ou OAuth ?
Voir l'analyse et la correction
Premièrement, l'utilisateur est le resource owner. Quand une application tente d'accéder à une ressource protégée, c'est l'utilisateur qui décide d'autoriser ou de refuser l'accès. C'est le point qui ancre OAuth comme protocole d'autorisation : on délègue un accès au nom du propriétaire de la ressource.
Deuxièmement, les exemples. OAuth : sourcer automatiquement des contacts depuis le carnet d'un téléphone ou via des applications de réseaux sociaux, ou utiliser une application mobile tierce pour se connecter à plusieurs comptes bancaires. OpenID Connect : se connecter à TripAdvisor (ou un site similaire) avec ses credentials Gmail. La nuance est nette : OAuth délègue l'accès à des données, OIDC prouve l'identité pour un sign-in.
Troisièmement, opportunités et défis. En résumé, ils tiennent à la sécurité et à l'usability. OpenID Connect comme OAuth utilisent des tokens, donc le token management peut devenir un enjeu. Et si l'authentification échoue, il peut être difficile d'identifier quel composant a échoué, ce qui complique le diagnostic.
À retenir : L'utilisateur est le resource owner ; OAuth délègue l'accès, OIDC authentifie ; tous deux reposent sur des tokens dont la gestion et le diagnostic d'échec sont les vrais défis.
- Dans OAuth, l'utilisateur est le resource owner qui autorise ou refuse
- OAuth = délégation d'accès (contacts, comptes bancaires tiers)
- OIDC = authentification fédérée (sign-in TripAdvisor via Gmail)
- Le token management et le diagnostic d'échec sont les principaux défis
OAuth (autorisation) vs OIDC (authentification)
Le piège le plus fréquent du 5.6 : OAuth 2.0 est un protocole d'autorisation, il délègue l'accès à une ressource au nom du resource owner. OpenID Connect est une couche d'authentification au-dessus d'OAuth, qui délivre un ID token prouvant qui est l'utilisateur. Si la question parle de prouver l'identité ou de sign-in (se connecter à un site avec son compte Google), la réponse est OIDC ; si elle parle d'accorder à une application un accès à des données (contacts, comptes bancaires), la réponse est OAuth. Formule à retenir : OIDC permet à une application de demander l'autorisation d'authentifier un utilisateur.
TGT vs ST : passeport vs visa
Dans Kerberos, ne confondez pas le TGT et le ST. Le TGT (authentication ticket) prouve seulement que vous avez réussi l'authentification et vous donne le droit de demander un service/session ticket ; c'est l'analogie du passeport, qui certifie votre citoyenneté mais ne vous fait pas entrer dans un autre pays. Le ST (service/session ticket) est ce qui ouvre l'accès effectif à une ressource, après que la ressource a déchiffré le ST, et il vaut typiquement de huit à dix heures. À l'examen : qui émet quoi ? L'AS émet le TGT, le TGS émet le ST, et les deux résident dans le même KDC.
RADIUS vs TACACS+ et la sensibilité au temps de Kerberos
Deux discriminations classiques. D'abord RADIUS vs TACACS+ : RADIUS est léger, combine les fonctions AAA et répond par Access-Accept/Reject/Challenge ; TACACS+ utilise TCP, sépare authentication, authorization et accounting en fonctions distinctes et chiffre l'intégralité de ses paquets (RADIUS ne chiffre historiquement que le password). Si la question insiste sur la séparation AAA, le command logging fin ou le chiffrement des paquets, c'est TACACS+. Ensuite Kerberos : il est extrêmement time-sensitive et s'appuie sur NTP ; une désynchronisation d'horloge provoque des échecs d'authentification, ce qui en fait un vecteur attractif de DoS. Souvenez-vous aussi que Kerberos n'assure pas la confidentialité des données transmises (il faut IPSec ou MACSec) et que son KDC est un single point of failure mitigé par plusieurs KDC.
Point de contrôle — Vérification des acquis
-
Un détaillant en ligne veut un CIAM permettant le self-provisioning et un enrôlement simple, en laissant les clients réutiliser des comptes existants. Quel protocole convient le mieux ?
- A OAuth pour fédérer des comptes existants
- B Une implémentation LDAP séparée pour les clients
- C SAML pour intégrer un web-service de self-enrollment à l'Active Directory
- D Un helpdesk accompagnant chaque utilisateur dans l'enrôlement
Réponse & justification
Réponse : A — OAuth pour fédérer des comptes existants
OAuth est couramment utilisé pour laisser les utilisateurs réutiliser des credentials existants (par exemple autoriser l'accès via un compte de réseau social), ce qui sert parfaitement le self-provisioning du CIAM. Une LDAP dédiée fonctionnerait mais n'est pas optimale ; SAML vers AD pourrait marcher mais reste non optimal ; un helpdesk dédié ne supporte ni la simplicité ni le self-provisioning visés (Check 5.6).
-
Dans le flux OAuth 2.0, quel rôle est responsable d'authentifier le owner, valider la demande et relayer un token au resource server ?
- A Authorization server
- B Relying party
- C Service provider
- D KDC
Réponse & justification
Réponse : A — Authorization server
C'est l'authorization server qui authentifie le owner, valide la demande, obtient l'autorisation et relaie le token au resource server. Relying party et service provider sont des rôles de SAML (et le RP est aussi côté OIDC), et le KDC appartient à Kerberos (Quiz Q9).
-
Dans Kerberos, quelles sont les deux fonctions remplies par le KDC ?
- A Authentication server (AS) et ticket-granting server (TGS)
- B Identity provider et service provider
- C Resource owner et resource server
- D Domain controller et federation service
Réponse & justification
Réponse : A — Authentication server (AS) et ticket-granting server (TGS)
Le KDC remplit deux fonctions : authentication server (AS), qui authentifie le principal et émet le TGT, et ticket-granting server (TGS), qui échange le TGT contre un ST. Les autres paires relèvent de SAML, OAuth ou Active Directory.
-
Un utilisateur Kerberos possède un TGT valide mais n'a pas encore de ST pour le serveur cible. Que signifie cette situation ?
- A Il peut demander l'accès à la ressource, mais l'accès effectif n'est pas encore accordé
- B Il a déjà accès à toutes les ressources du realm
- C Son authentification a échoué et il doit recommencer
- D Le KDC est hors service
Réponse & justification
Réponse : A — Il peut demander l'accès à la ressource, mais l'accès effectif n'est pas encore accordé
Le TGT seul ne permet pas l'accès : il autorise seulement à demander un ST, comme un passeport certifie la citoyenneté sans donner droit d'entrer dans un autre pays. L'accès effectif n'arrive qu'avec un ST déchiffré par la ressource.
-
Quelle affirmation distingue correctement OAuth 2.0 d'OpenID Connect ?
- A OAuth est un protocole d'autorisation ; OIDC est une couche d'authentification au-dessus d'OAuth
- B OAuth est une couche d'authentification ; OIDC est un protocole d'autorisation
- C Les deux sont des protocoles d'authentification équivalents
- D OAuth émet des ID tokens ; OIDC émet des authorization tokens
Réponse & justification
Réponse : A — OAuth est un protocole d'autorisation ; OIDC est une couche d'authentification au-dessus d'OAuth
OAuth 2.0 est un protocole d'autorisation (déléguer l'accès) ; OIDC est une couche d'authentification construite au-dessus d'OAuth, qui délivre un ID token porteur de claims. C'est l'ID token (sub, iss, aud, iat, exp) qui appartient à OIDC, pas à OAuth.
Points essentiels à retenir
- Linux/Unix = Kerberos + LDAP ; Microsoft = Active Directory ; presque tout dérive de X.500.
- RADIUS : léger, AAA combinés, Access-Accept/Reject/Challenge, EAP, roaming ; TACACS+ : TCP, AAA séparés, paquets chiffrés, command logging.
- LDAP : DN = chemin complet, attributs, bind authentifie un password ; AD DS sur domain controller, AD FS = SSO fédéré.
- OAuth 2.0 = autorisation, user = resource owner, authorization server relaie un token ; OIDC = authentification, RP demande un ID token à un OP.
- Claims OIDC : sub, iss, aud, iat, exp (plus first_name/last_name) ; OIDC marche avec site web ou mobile.
- Kerberos : KDC = AS + TGS, chiffrement symétrique ; AS émet le TGT (droit de demander), TGS émet le ST (accès), valable 8 à 10 h.
- Kerberos très time-sensitive (NTP) ; ne sécurise pas les données transmises (IPSec/MACSec) ; KDC = SPOF mitigé par plusieurs KDC.
- SAML : framework XML, 3 rôles (IdP, SP/RP, user agent), 4 composants (Assertions, Bindings, Protocols SOAP/HTTP, Profiles).
- IDaaS : IGA, Access, Intelligence (=accounting) ; in-house vs third-party (SLA), on-premises vs cloud vs hybrid.
- La responsabilité finale d'une IDaaS reste avec votre organisation, quels que soient les acteurs et l'hébergement.
Synthèse du domaine
L'IAM se situe au coeur du maintien de la sécurité de l'information : c'est un composant critique de la posture de sécurité d'une organisation. Des pratiques IAM efficaces garantissent que seuls les individus autorisés accèdent aux informations et ressources sensibles, tout en empêchant les accès non autorisés et en s'assurant que l'accès est accordé via des politiques et procédures décidées par l'organisation. L'IAM repose sur quatre composants clés : identification (identifier les utilisateurs, leurs rôles et privilèges), authentication (vérifier l'identité via passwords, biometrics ou autres méthodes), authorization (accorder l'accès selon le rôle et le niveau de privilège) et accountability (tracer et surveiller l'accès pour vérifier qu'il reste approprié).
Plusieurs technologies et processus servent à mettre en oeuvre l'IAM : les access controls restreignent l'accès selon l'identité et le niveau de privilège ; les systèmes d'identity and access management pilotent l'ensemble du processus (user provisioning, gestion des accès, monitoring) ; les solutions de single sign-on (SSO) permettent d'accéder à plusieurs systèmes avec un seul jeu d'identifiants, améliorant l'efficacité et réduisant le risque d'accès non autorisé. L'IAM implique aussi des politiques et procédures soutenant la posture globale de sécurité : création et gestion des access control policies, et procédures de gestion et de retrait des accès quand c'est nécessaire.
L'IAM comporte enfin des considérations légales et réglementaires, comme le General Data Protection Regulation (GDPR) et le Health Insurance Portability and Accountability Act (HIPAA), qui exigent de protéger la confidentialité et la sécurité des informations personnelles. Pour protéger l'information, des contrôles d'accès physiques et logiques sont implémentés afin que l'accès aux actifs soit géré et sécurisé. Les éléments essentiels d'un access provisioning life cycle couvrent tout le spectre de la gestion système liée aux personnes, aux équipements et aux ressources ; identification, authentication et authorization assurent que les bons utilisateurs accèdent au système et que l'usage des ressources reste correct.
Glossaire (Terms & Definitions)
Les termes-clés du Domaine 5, à maîtriser en anglais pour l'examen.
| Terme | Définition |
|---|---|
| Access Control System | Moyen garantissant que l'accès aux actifs est autorisé et restreint selon les exigences métier et de sécurité, pour les systèmes logiques et physiques. |
| Access Control Tokens | Justificatifs (matériels ou logiciels) ; le système accorde ou refuse l'accès selon la validité du jeton au point de lecture (heure, date, jour, condition). Support du MFA. |
| Accounting | Processus de contrôle d'accès qui enregistre toutes les tentatives d'accès aux ressources par toutes les identités. Voir authentication, authorization. |
| Authentication | Processus validant l'identité revendiquée par comparaison d'un ou plusieurs facteurs (ce que l'on est, possède, sait). SFA = un facteur, MFA = deux ou plus. |
| Authorization | Définition des ressources dont un utilisateur a besoin et détermination du type d'accès qu'il peut avoir sur celles-ci. |
| Identification | Action de revendiquer une identité unique (login, ID) auprès du système, première étape avant l'authentification. |
| IAAA | Modèle de contrôle d'accès : Identification, Authentication, Authorization, Accounting (parfois Auditing/Accountability). |
| Crossover Error Rate (CER) | Point où le FAR (Type 2) égale le FRR (Type 1) pour un capteur donné ; FAR et FRR varient inversement avec la sensibilité, le CER mesure la qualité du biométrique (plus bas = meilleur). |
| False Acceptance Rate (FAR / Type 2) | Authentifier à tort une identité revendiquée comme légitime et lui accorder l'accès. Erreur la plus dangereuse pour la sécurité. |
| False Rejection Rate (FRR / Type 1) | Refuser à tort l'authentification à une identité légitime, lui refusant ainsi l'accès. Affecte la convivialité. |
| Type 1 Authentication Factor (something you know) | Facteur de connaissance : mot de passe, PIN, phrase secrète, réponses aux questions défis. |
| Type 2 Authentication Factor (something you have) | Facteur de possession : jeton matériel, carte à puce, smartphone, OTP, clé FIDO. |
| Type 3 Authentication Factor (something you are) | Facteur d'inhérence : caractéristique biométrique (empreinte, iris, visage, voix). |
| Biometrics | Authentification par caractéristiques physiologiques ou comportementales ; sujette à FAR/FRR/CER et à l'enrôlement. Facteurs additionnels : quelque chose que l'on fait, un lieu, un moment. |
| Fingerprint Biometric | Lecture des minuties de l'empreinte digitale ; courant et peu coûteux, sensible aux faux capteurs. |
| Iris vs Retina Scan | Iris : motifs colorés, très précis, faible CER, sans contact. Rétine : vaisseaux du fond d'oeil, précis mais intrusif et révèle des données de santé. |
| Facial Recognition | Analyse de la géométrie du visage ; sans contact mais sensible à l'éclairage et aux variations. |
| Vein / Voice Biometric | Veine : lecture du réseau veineux par infrarouge, difficile à falsifier. Voix : empreinte vocale, sensible au bruit et au replay. |
| Data Custodian | Personne qui gère permissions et accès au quotidien selon les instructions du data owner ; protège l'actif en sa possession. |
| Data Owner / Data Controller | Personne ou entité responsable de classifier, catégoriser et autoriser l'accès aux données ; connaît le mieux leur importance. |
| Discretionary Access Control (DAC) | Contrôle d'accès où le propriétaire du système (ou de la ressource) décide qui obtient l'accès. |
| Mandatory Access Control (MAC) | Contrôle d'accès où le système lui-même applique les permissions selon les politiques de sécurité (étiquettes/labels). |
| Non-Discretionary Access Control (NDAC) | Contrôle d'accès géré centralement par une autorité plutôt que par le propriétaire ; englobe RBAC et RuBAC. |
| RBAC (Role-Based Access Control) | Permissions attribuées à des rôles, eux-mêmes assignés aux utilisateurs ; simplifie l'administration à grande échelle. |
| RuBAC (Rule-Based Access Control) | Accès régi par des règles globales (ex : ACL pare-feu, horaires) appliquées à tous, indépendamment de l'identité. |
| ABAC (Attribute-Based Access Control) | Décision d'accès calculée à partir d'attributs du sujet, de l'objet, de l'action et du contexte (politiques dynamiques). |
| Least Privilege | Accorder à chaque identité strictement les permissions nécessaires à ses fonctions, ni plus ni moins. |
| Separation of Duties (SoD) | Répartir une tâche sensible entre plusieurs personnes pour qu'aucune ne puisse agir seule ; prévient fraude et erreurs. |
| Need-to-Know | Restreindre l'accès aux seules informations nécessaires à la mission, même si l'habilitation le permettrait. |
| Entitlement | Ensemble des droits et privilèges effectivement accordés à une identité sur les ressources. |
| Privilege Creep | Accumulation inutile de privilèges, généralement par non-retrait des droits devenus obsolètes. |
| Access Review / Recertification | Révision périodique des permissions pour révoquer, désactiver ou supprimer les droits superflus et détecter les anomalies. |
| Identity Lifecycle | Cycle de vie d'une identité : provisioning, gestion/changements, révision, puis désactivation et deprovisioning. |
| Provisioning | Création et activation d'une identité et de ses accès au démarrage du cycle de vie. |
| Deprovisioning | Désactivation et suppression d'une identité et de ses accès en fin de cycle de vie (départ, changement). |
| JIT Provisioning (Just-in-Time) | Création à la demande, en temps réel, d'une identité et de ses accès au moment du besoin (réduit les comptes dormants). |
| SCIM (System for Cross-domain Identity Management) | Standard REST/JSON automatisant le provisioning et deprovisioning des identités entre fournisseurs et applications. |
| Identity Proofing | Collecte et vérification d'informations sur une personne pour prouver qu'elle est bien celle qu'elle prétend, et établir un lien fiable avec le credential. |
| IAL (Identity Assurance Level) | Niveau de confiance dans la vérification d'identité (NIST SP 800-63A) : IAL1 sans preuve, IAL2 à distance, IAL3 en présentiel. |
| AAL (Authenticator Assurance Level) | Robustesse du processus d'authentification (NIST SP 800-63B) : AAL1 SFA, AAL2 MFA, AAL3 MFA cryptographique matériel. |
| FAL (Federation Assurance Level) | Robustesse des assertions fédérées (NIST SP 800-63C) : FAL1 à FAL3 selon protection et chiffrement de l'assertion. |
| Identity as-a-Service (IDaaS) | Services cloud qui intermédient les fonctions IAM vers des systèmes cibles sur site, dans le cloud, ou les deux. |
| Self-Service Identity Management | Éléments du cycle de vie que l'utilisateur peut initier seul (réinitialisation de mot de passe, mise à jour d'adresse, questions défis). |
| Logical Access Control System | Systèmes automatisés autorisant ou refusant l'accès à un SI et ses actifs en vérifiant que l'identité présentée correspond à celle approuvée. |
| Single-Factor Authentication (SFA) | Utilisation d'un seul des trois facteurs disponibles pour réaliser l'authentification. |
| Multi-Factor Authentication (MFA) | Authentification combinant deux facteurs ou plus de catégories différentes ; plus de facteurs, plus de confiance. |
| Mutual Authentication | Authentification bidirectionnelle où client et serveur prouvent chacun leur identité (ex : TLS mutuel). |
| Password Policy | Règles de longueur, complexité, historique, expiration et verrouillage régissant les mots de passe. |
| Salting | Ajout d'une valeur aléatoire unique à un mot de passe avant hachage pour empêcher tables arc-en-ciel et collisions. |
| Credential Management | Cycle de vie sécurisé des authentifiants : émission, stockage, rotation, récupération et révocation. |
| Certificate-Based Authentication | Authentification par certificat numérique X.509 prouvant la possession de la clé privée associée (PKI). |
| Smart Card | Carte à puce stockant des credentials/certificats ; facteur de possession, souvent couplée à un PIN. |
| FIDO2 / WebAuthn / Passkey | Standards d'authentification forte sans mot de passe par cryptographie à clé publique liée à l'origine, résistante au phishing. |
| SSO (Single Sign-On) | Mécanisme permettant à l'utilisateur de s'authentifier une fois pour accéder à plusieurs systèmes ; réduit le nombre de credentials. |
| FIM (Federated Identity Management) | Création de relations de confiance entre domaines de sécurité distincts via des identités numériques communes (client, SP/RP, IdP). |
| Federation Trust | Relation de confiance établie entre IdP et SP/RP permettant l'acceptation d'assertions d'identité inter-domaines. |
| Identity Provider (IdP) | Entité qui authentifie l'utilisateur et émet des assertions/jetons d'identité aux fournisseurs de services. |
| Service Provider (SP) / Relying Party (RP) | Application ou service consommant l'assertion d'identité de l'IdP pour accorder l'accès ; RP est le terme OAuth/OIDC. |
| Subjects and Objects | Sujet : entité active demandant l'accès (utilisateur, processus) ; objet : ressource passive accédée (fichier, table). |
| Open Authorization (OAuth) | Cadre d'autorisation OAuth 2.0 permettant à une application tierce un accès limité à un service HTTP au nom du propriétaire ou pour son propre compte. |
| OpenID Connect (OIDC) | Couche d'identité au-dessus d'OAuth 2.0 ajoutant l'authentification via un ID Token (JWT) signé par l'IdP. |
| SAML | Security Assertion Markup Language : standard XML d'échange d'assertions d'authentification et d'autorisation pour le SSO fédéré web. |
| JWT (JSON Web Token) | Jeton compact JSON signé (et éventuellement chiffré) portant des claims d'identité ; utilisé par OIDC et les API. |
| Token (Bearer / Access / Refresh) | Access token : accès court à une ressource ; refresh token : renouvelle l'access ; bearer : utilisable par tout porteur (à protéger). |
| Kerberos | Protocole d'authentification réseau à tickets utilisant un KDC et de la cryptographie symétrique ; pas de mot de passe sur le réseau. |
| KDC (Key Distribution Center) | Composant central de Kerberos (AS + TGS) qui authentifie les principaux et émet les tickets. |
| TGT (Ticket-Granting Ticket) | Ticket délivré par le KDC après authentification initiale, permettant d'obtenir des tickets de service sans se réauthentifier. |
| LDAP | Lightweight Directory Access Protocol : protocole d'interrogation et de modification d'annuaires d'identités hiérarchiques. |
| Active Directory | Service d'annuaire Microsoft basé sur LDAP, Kerberos et DNS ; gère identités, GPO et authentification dans un domaine Windows. |
| RADIUS | Remote Authentication Dial-In User Service : protocole AAA centralisé (UDP) chiffrant seulement le mot de passe ; courant pour l'accès réseau. |
| TACACS+ | Protocole AAA Cisco (TCP) chiffrant tout le payload et séparant authentification, autorisation et accounting. |
| Diameter | Successeur de RADIUS, protocole AAA plus robuste et extensible (transport fiable, sécurité), utilisé en mobile/IMS. |
| Session Management | Création, maintien et terminaison sécurisés des sessions : ID de session imprévisibles, expiration/timeout, invalidation à la déconnexion. |
| Privileged Account | Compte à droits élevés (administrateur, root) nécessitant surveillance et contrôles renforcés. |
| Service Account | Compte non humain utilisé par une application ou un service ; souvent à privilèges, à surveiller et faire tourner. |
| Shared Account | Compte utilisé par plusieurs personnes ; rompt l'imputabilité, généralement déconseillé. |
| PAM (Privileged Access Management) | Ensemble de contrôles gérant les comptes à privilèges : coffre-fort de secrets, accès JIT, élévation contrôlée, enregistrement de sessions. |
| Zero Trust | Modèle « never trust, always verify » : aucune confiance implicite, vérification continue de chaque requête selon identité, appareil et contexte. |
| Centralized vs Decentralized vs Hybrid Access Control | Trois méthodes de gestion des accès physiques/logiques : centralisée (autorité unique), décentralisée (locale), ou hybride. |
| CIANA+PS | Types de protection à fournir : Confidentiality, Integrity, Availability, Non-Repudiation, Authenticity, Privacy, Safety. |
Points essentiels du domaine
Ce qu'il faut absolument retenir
- L'IAM consiste à gérer le cycle de vie des comptes utilisateurs, de la création (provisioning) à la suppression (deprovisioning).
- Identification, authentication et authorization sont les trois composants clés de l'access control ; l'accountability les complète par le suivi et la journalisation.
- Les mécanismes d'authentification incluent passwords, tokens, biometrics et multi-factor authentication ; plus on combine de facteurs, plus la confiance dans l'authenticité augmente.
- Les mécanismes d'autorisation incluent les access control lists (ACL), le role-based access control (RBAC) et le mandatory access control (MAC), aux côtés de DAC, RuBAC et ABAC.
- Les comptes privilégiés (comptes administrateur) exigent une attention particulière et une gestion dédiée (PAM) pour éviter les abus.
- Le single sign-on (SSO) et le federated identity management (FIM) simplifient l'access control et réduisent le nombre de comptes et de mots de passe à gérer ; le FIM repose sur trois rôles : client/principal, service provider (RP) et identity provider (IdP).
- Le monitoring et le logging de l'access control sont essentiels pour détecter et prévenir les accès non autorisés et fournir un audit trail exploitable en analyse forensique.
- Les identités sont des labels et des constructs de données que tout sujet et tout objet doivent posséder pour être référencés de façon claire et non ambigue.
- Tout changement de statut d'emploi ou de responsabilités doit déclencher une revue de permissions afin de prévenir le privilege creep.
- Les permissions access reviews doivent être menées en continu et de façon planifiée pour révéler les vulnérabilités exigeant révocation, désactivation ou suppression d'un accès ou d'un compte entier.
- Externaliser ou offboarder des fonctions de sécurité ne transfère jamais la responsabilité : le poids ultime de due care et due diligence reste à l'organisation.