CompTIA SY0-701: Gestion des identités et des accès — Guide d'étude

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Fait partie du CompTIA Security+ SY0-701 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens CompTIA, ou passez des tests chronométrés sur ExamRoll.io.

La gestion des identités et des accès (IAM) est la discipline qui consiste à s’assurer que les bons sujets — utilisateurs, services et périphériques — obtiennent le bon accès aux bonnes ressources au bon moment, et uniquement pour la durée nécessaire. Elle repose sur deux piliers conceptuellement distincts qui sont fréquemment, et dangereusement, confondus : l’authentification, qui prouve qui est un sujet, et l’autorisation, qui détermine ce que ce sujet authentifié peut faire. Un utilisateur qui se connecte à un poste de travail avec une empreinte digitale s’est authentifié ; savoir si cet utilisateur peut ouvrir la base de données de paie est une question d’autorisation. Toute conception de contrôle qui brouille la distinction entre les deux est une porte ouverte à la compromission.

Facteurs d’authentification et authentification multifacteur

Les facteurs d’authentification sont traditionnellement regroupés en cinq catégories : quelque chose que vous savez (mots de passe, codes PIN), quelque chose que vous possédez (cartes à puce, jetons matériels, téléphones exécutant des applications TOTP), quelque chose que vous êtes (empreinte digitale, rétine, géométrie faciale), un endroit où vous êtes (géolocalisation ou contexte basé sur le réseau), et quelque chose que vous faites (biométrie comportementale comme la cadence de frappe). L’authentification multifacteur (MFA) exige des preuves provenant d’au moins deux catégories différentes. Un mot de passe combiné à une question de sécurité n’est pas une MFA — les deux relèvent de la catégorie « quelque chose que vous savez ». Un mot de passe combiné à un code TOTP provenant de Google Authenticator est une MFA.

Les jetons matériels existent sous plusieurs formes. Les clés de sécurité FIDO2/WebAuthn telles que les YubiKeys utilisent la cryptographie asymétrique : la clé privée ne quitte jamais le périphérique, et le serveur ne détient qu’une clé publique, ce qui contre le phishing et les attaques par rejeu. Les jetons HOTP génèrent des mots de passe à usage unique à partir d’un compteur ; les jetons TOTP les génèrent à partir de l’heure actuelle en utilisant une construction HMAC-SHA1 :

TOTP = HMAC-SHA1(shared_secret, floor(current_unix_time / 30))

Les cartes à puce, communément les cartes PIV ou CAC dans les environnements gouvernementaux, stockent un certificat X.509 et une clé privée sur une puce inviolable. La présentation de la carte, combinée à un code PIN, satisfait à deux facteurs et permet l’authentification basée sur des certificats à des systèmes comme Active Directory via Kerberos PKINIT.

La MFA est le contrôle le plus efficace contre le vol d’identifiants. Lorsque des utilisateurs signalent des connexions provenant d’adresses IP dont ils ne sont pas à l’origine, la réinitialisation des mots de passe traite le symptôme ; l’application de la MFA s’attaque à la cause racine, car un mot de passe volé devient à lui seul insuffisant.

Authentification unique (SSO) et fédération

L’authentification unique (SSO) permet à un utilisateur de s’authentifier une seule fois et d’accéder à plusieurs applications sans avoir à saisir de nouveau ses identifiants. La fédération étend ce principe au-delà des frontières organisationnelles ou de confiance — le fournisseur d’identité (IdP) d’un utilisateur dans un domaine se porte garant de l’utilisateur auprès d’un fournisseur de services (SP) dans un autre. L’idée fausse la plus courante ici est de traiter SAML et OAuth comme s’ils étaient interchangeables ; ils résolvent des problèmes différents.

SAML 2.0 est un protocole basé sur XML conçu pour le SSO d’entreprise et les assertions d’authentification. Lorsqu’un utilisateur demande une application SaaS, le SP redirige le navigateur vers l’IdP, qui authentifie l’utilisateur et renvoie une assertion SAML signée contenant des attributs d’identité. C’est le mécanisme standard pour permettre aux employés d’accéder à des applications cloud comme Salesforce ou Workday en utilisant les identifiants Active Directory de l’entreprise.

OAuth 2.0 est un cadre d’autorisation, pas un protocole d’authentification. Il accorde à une application tierce un accès délégué à une ressource au nom de l’utilisateur via des jetons d’accès. Permettre à une application de publier sur votre fil Twitter est un flux OAuth. OpenID Connect (OIDC) est une couche d’identité construite sur OAuth 2.0 qui ajoute un id_token (un JWT) fournissant des assertions d’authentification — c’est ce qui rend possible la fonctionnalité « Se connecter avec Google ».

Un piège critique : le SSO et la fédération réduisent la prolifération des identifiants mais ne suppriment pas le besoin de MFA. Au contraire, ils concentrent le risque — un seul identifiant SSO compromis déverrouille désormais toutes les applications fédérées. La MFA doit être appliquée au niveau de l’IdP, et les comptes à privilèges devraient exiger une authentification renforcée même après le SSO.

Modèles de contrôle d’accès

Une fois l’identité établie, un modèle de contrôle d’accès régit les décisions d’autorisation. Le contrôle d’accès discrétionnaire (DAC) permet aux propriétaires de ressources de définir des permissions, généralement via des listes de contrôle d’accès (ACL). Le contrôle d’accès obligatoire (MAC) applique une politique de manière centralisée en se basant sur des étiquettes et des niveaux d’habilitation, ce qui est courant dans les systèmes militaires et mis en œuvre par des frameworks comme SELinux. Le contrôle d’accès basé sur les rôles (RBAC) attribue des permissions à des rôles et des utilisateurs à des rôles — un rôle « Analyste de facturation » comporte un ensemble de permissions défini, et les utilisateurs héritent des permissions par leur appartenance au rôle. Le contrôle d’accès basé sur les attributs (ABAC) évalue les politiques en fonction des attributs du sujet, de la ressource, de l’action et de l’environnement, permettant des règles telles que « autoriser l’accès en lecture aux fichiers RH uniquement pendant les heures de bureau à partir de périphériques gérés par l’entreprise ».

À tous ces modèles se superpose le principe du moindre privilège : les sujets ne reçoivent que l’accès minimum nécessaire pour accomplir leur fonction, et rien de plus. En complément, la séparation des tâches empêche un seul individu de contrôler entièrement un processus sensible — la personne qui demande un paiement ne devrait pas être celle qui l’approuve.

Les contrôles d’accès pratiques incluent les ACL de système de fichiers, les ACL réseau sur les routeurs et les pare-feu, et les restrictions horaires qui n’autorisent la connexion que pendant les heures autorisées. Une entrée ACL Windows accordant un accès en lecture seule à un partage financier pourrait se lire comme suit :

icacls C:\Finance /grant "Domain\Finance-RO:(OI)(CI)R"

Gestion des accès à privilèges

Les comptes à privilèges — administrateurs de domaine, root, administrateurs de bases de données, comptes root du cloud, comptes de service — sont les joyaux de la couronne de tout environnement. Les systèmes de gestion des accès à privilèges (PAM) tels que CyberArk, BeyondTrust ou HashiCorp Vault appliquent des contrôles autour de ces comptes : les informations d’identification sont stockées dans un coffre-fort (vaulted) et leur rotation est effectuée automatiquement, les sessions sont enregistrées, l’extraction (checkout) nécessite une justification et souvent une approbation, et les mots de passe sont fréquemment à usage unique ou éphémères.

L’accès juste-à-temps (JIT) élève les privilèges uniquement pour la durée d’une tâche spécifique, éliminant ainsi les droits d’administration permanents. Un développeur qui doit exécuter une migration de base de données reçoit des informations d’identification à durée limitée qui expirent automatiquement après 30 minutes — il n’y a pas de compte à privilèges persistant à dérober. Le service Privileged Identity Management (PIM) dans Azure AD implémente ce modèle de manière native, exigeant des flux de travail d’approbation et une nouvelle authentification MFA avant l’élévation des privilèges.

Les comptes de service présentent un défi particulier. Ils disposent souvent de privilèges excessifs, leurs mots de passe sont rarement renouvelés et leur utilisation est rarement auditée. Les comptes de service gérés (MSA) et les comptes de service gérés de groupe (gMSA) dans Active Directory automatisent la rotation des mots de passe et éliminent complètement le besoin pour les humains de connaître les informations d’identification des comptes de service.

Services d’annuaire et provisionnement

Active Directory (AD) reste le magasin d’identités sur site (on-premises) dominant. Les utilisateurs, les ordinateurs et les groupes sont organisés en unités d’organisation (OU), et les objets de stratégie de groupe (GPO) appliquent des paramètres de configuration et de sécurité de manière hiérarchique. Les approbations AD (trusts) étendent l’authentification à travers les domaines et les forêts. Azure Active Directory (Entra ID) étend ces concepts au cloud, en y ajoutant des stratégies d’accès conditionnel, une notation du risque de protection de l’identité et une intégration transparente avec des milliers d’applications SaaS.

LDAP (Lightweight Directory Access Protocol) est le protocole sous-jacent pour interroger les services d’annuaire. RADIUS centralise l’authentification pour l’accès au réseau — l’authentification pour le VPN, le Wi-Fi et le filaire 802.1X s’effectue généralement auprès d’un serveur RADIUS adossé à AD. TACACS+ joue un rôle similaire pour l’administration des équipements réseau, avec l’avantage supplémentaire de séparer l’authentification, l’autorisation et la traçabilité (accounting) en phases distinctes.

Le provisionnement et le déprovisionnement des utilisateurs doivent être étroitement liés aux processus RH. La défaillance la plus persistante en matière d’IAM est le compte orphelin — le compte Active Directory d’un ancien employé qui reste actif des semaines ou des mois après son départ. Le provisionnement automatisé via SCIM (System for Cross-domain Identity Management) ou des connecteurs RH-vers-AD, combiné à des listes de contrôle de déprovisionnement obligatoires, comble cette lacune.

Scénario pratique : Compromission d’informations d’identification via un compte orphelin

L’équipe informatique d’une entreprise de fabrication a découvert un accès inhabituel en dehors des heures de bureau à son système ERP provenant d’un compte de service qui avait été créé pour un projet d’intégration désormais abandonné. Le compte disposait de droits d’utilisateur de domaine et n’avait jamais été examiné lors des revues d’accès trimestrielles, car il n’était pas associé à un employé nommé. Un attaquant qui avait acheté des informations d’identification provenant d’un dump du dark web a utilisé le compte pour énumérer les partages de fichiers, exfiltrer des données de tarification et établir une persistance via une tâche planifiée. La violation n’a été découverte que lorsque le fournisseur de l’ERP a signalé des modèles d’appels d’API anormaux. La cause première était un processus de déprovisionnement défaillant : l’intégration a été mise hors service, mais le compte n’a jamais été désactivé. La mise en œuvre d’un système PAM avec découverte automatisée des comptes orphelins et des cycles de revue obligatoires aurait fait apparaître le compte bien avant qu’il ne soit exploité.

← Gouvernance · Tous les domaines · Menaces →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →