Aller au contenu
Initiative Ariovis
Contact

Architecture et sessions privilégiées • Ariovis

Architectures PAM de référence : du coffre-fort aux accès privilégiés réellement maîtrisés

Une architecture PAM organise l’authentification des administrateurs, leurs privilèges, leurs chemins d’accès et les traces de leurs interventions. Quatre modèles pour examiner les contrôles, les contournements et les possibilités d’évolution.

Quatre modèles : choisir selon le chemin à protéger, pas selon un ordre obligatoire
ModèleDécision principaleLimite à vérifier
01 — Coffre seulProtéger et distribuer les identifiants ; rendre visible la limite entre accès au secret et contrôle de l’intervention.Copie ou réutilisation du secret, privilèges trop larges et comptes partagés.
02 — Chemin contrôléImposer un premier chemin d’administration Windows/Linux et vérifier sa couverture réelle.Compromission du poste, de l’IdP, de la passerelle ou d’un compte d’administration du PAM.
03 — Hybride / prestatairesRelier identité, période d’intervention, chemins internes et permissions cloud sans confondre les protocoles.Jetons cloud persistants, clés API, identités applicatives et droits de plateforme hors couverture.
04 — Privilèges temporairesAjouter une attribution et un retrait vérifiés aux contrôles d’identité et de session déjà opérationnels.Compte ou rôle d’orchestration puissant, jetons actifs, cache de groupes et échecs de retrait.

Huit responsabilités à ne pas confondre

Le coffre protège l’identifiant. L’IdP établit la personne ; la politique autorise une activité. Le réseau et la cible imposent le chemin. Le contrôle de session peut isoler et observer, selon la technologie. L’enregistrement conserve ce qui est visible ; la détection exige des règles et une réaction. Enfin, l’attribution et le retrait des droits réduisent leur permanence. Chacune de ces responsabilités a un point d’application et un test distinct.

La sécurité commence avant RDP ou SSH : poste d’origine, authentification, groupes et droits effectifs, interfaces réseau et identifiants utilisés. Elle continue après la déconnexion : preuve, investigation et accès résiduels.

01 — Coffre seul

Mon mot de passe est dans un coffre. Suis-je réellement protégé ?

Figure — Mon mot de passe est dans un coffre. Suis-je réellement protégé ?
Couches du schéma
Lien direct
Mon mot de passe est dans un coffre. Suis-je réellement protégé ?Architecture pédagogique. Protéger et distribuer les identifiants ; rendre visible la limite entre accès au secret et contrôle de l’intervention. Le journal du coffre prouve une récupération autorisée, pas les commandes exécutées ensuite. Le secret peut être réutilisé hors du coffre tant que la cible l’accepte. Des coffres proposent aussi des mécanismes de lancement ou d’isolation : ils ne sont pas représentés ici.Mon mot de passe est dans un coffre. Suis-je réellement protégé ?Architecture pédagogique générique • aucune validation sur un SI clientOrigine de l’administrationGestion des identifiantsInfrastructure cibleL’utilisateur s’authentifie au coffre ; la permission de consulter l’entrée est évaluée dans le coffre.1. Accès au coffreLe coffre remet l’identifiant selon les permissions ; une récupération n’est pas une preuve de session.Remise autoriséeLe secret devient accessible sur le poste ; la restriction du coffre ne peut effacer une copie déjà obtenue.Secret connu du posteLa cible accepte une connexion directe. Elle n’est pas interdite dans cet état initial, mais elle n’est pas contrôlée par le coffre.2. RDP / SSH direct — hors contrôle de session PAMLe coffre journalise la remise ; aucune vidéo ou commande de la session cible n’est déduite de cette trace.Trace de récupérationLes événements Windows/Linux ont leur propre couverture et doivent être corrélés à la personne.Événements natifsAdministrateurPersonne identifiéePoste d’administrationSecret exposé après remisePoint de contrôle : Coffre-fort PAMCoffre-fort PAMAuthentification et permissionsIdentifiant privilégiéSecret remis à l’utilisateurWindows / LinuxCompte privilégié ; RDP / SSHJournal du coffreQui a récupéré quoi et quandJournaux de la cibleCollecte à organiser séparémentLégende — sens des échanges et des points de contrôleAdministration autorisée — trait pleinIdentifiant / droit — tirets courtsJournalisation — pointillésChemin direct hors contrôle PAM — tirets longsDécision / contrôle — trait épaisCadre en tirets : frontière de confiance / réseau • cadre accentué : contrôleLe journal du coffre prouve une récupération autorisée, pas les commandes exécutées ensuite. Le secret peut être réutiliséhors du coffre tant que la cible l’accepte. Des coffres proposent aussi des mécanismes de lancement ou d’isolation : ilsne sont pas représentés ici.Schéma original — Mon Premier PAM / Ariovis • Création et révision : 2026-10-23Hypothèses et références : monpremierpam.fr/architectures-pam#coffre-seul

Le journal du coffre prouve une récupération autorisée, pas les commandes exécutées ensuite. Le secret peut être réutilisé hors du coffre tant que la cible l’accepte. Des coffres proposent aussi des mécanismes de lancement ou d’isolation : ils ne sont pas représentés ici.

Schéma original — Mon Premier PAM / Ariovis. Création éditoriale et révision : . Architecture pédagogique, pas un déploiement client validé. Les exports reprennent les couches et le mode sélectionnés.

Alternative textuelle : composants et échanges
  1. 1. Accès au coffre. L’utilisateur s’authentifie au coffre ; la permission de consulter l’entrée est évaluée dans le coffre.
  2. Remise autorisée. Le coffre remet l’identifiant selon les permissions ; une récupération n’est pas une preuve de session.
  3. Secret connu du poste. Le secret devient accessible sur le poste ; la restriction du coffre ne peut effacer une copie déjà obtenue.
  4. Chemin direct hors contrôle PAM — 2. RDP / SSH direct — hors contrôle de session PAM. La cible accepte une connexion directe. Elle n’est pas interdite dans cet état initial, mais elle n’est pas contrôlée par le coffre.
  5. Trace de récupération. Le coffre journalise la remise ; aucune vidéo ou commande de la session cible n’est déduite de cette trace.
  6. Événements natifs. Les événements Windows/Linux ont leur propre couverture et doivent être corrélés à la personne.

Contexte et objectif

L’administrateur ouvre le coffre, récupère un secret autorisé puis se connecte directement en RDP ou SSH. Ce premier contrôle peut être pertinent : dans le modèle illustré, il ne relaie pas la session.

Protéger et distribuer les identifiants ; rendre visible la limite entre accès au secret et contrôle de l’intervention.

Composants et responsabilités
ComposantResponsabilité / limite
Administrateur / posteÉtablit la connexion et reçoit le secret. La sécurité du terminal reste déterminante.
Coffre-fortProtège le stockage, évalue la consultation et produit sa trace ; rotation selon capacités et configuration.
CibleAuthentifie le compte et applique ses droits effectifs, indépendamment de la consultation du coffre.
JournauxLa récupération et l’activité cible sont deux événements distincts à rapprocher.

Hypothèses et frontières

  • Le modèle suppose une remise du secret, sans intermédiaire de session.
  • La cible reste joignable directement depuis le poste.
  • Aucune rotation automatique, isolation ou collecte centralisée n’est présumée.

Risques réduits

  • Dispersion des secrets et consultations sans permission dans le coffre.
  • Absence d’historique de remise, si la journalisation est activée.

Risques résiduels

  • Copie ou réutilisation du secret, privilèges trop larges et comptes partagés.
  • Poste compromis ; connexions hors coffre ; activité non visible dans le journal de récupération.

Erreurs de conception

  • Confondre le nombre d’entrées en coffre avec les chemins sécurisés.
  • Révoquer la permission du coffre sans modifier un secret déjà connu.
  • Faire tourner un compte de service sans inventorier ses dépendances.
Cinq tests de recette — à réaliser sur un périmètre pilote autorisé
TestRésultat attendu
PermissionUn profil non autorisé ne récupère pas l’entrée ; le refus apparaît dans les traces prévues.
RéutilisationSur une cible de test, vérifier si un secret déjà récupéré fonctionne après retrait de la permission du coffre.
CouvertureComparer un journal de récupération à une activité cible : identifier les informations réellement absentes.
RotationTester le changement et la révocation sur une cible pilote, avec validation des dépendances.
CheminDepuis un poste de test autorisé, inventorier les routes RDP/SSH encore acceptées.

02 — Chemin contrôlé

Le bastion devient un point de contrôle, pas un simple serveur de rebond.

Figure — Le bastion devient un point de contrôle, pas un simple serveur de rebond.
Couches du schéma
Lien direct
Le bastion devient un point de contrôle, pas un simple serveur de rebond.Architecture pédagogique. Imposer un premier chemin d’administration Windows/Linux et vérifier sa couverture réelle. La passerelle ne ferme pas les chemins alternatifs à elle seule. Le mode contrôlé suppose un filtrage réellement appliqué sur les interfaces d’administration. En mode contournable, une session directe peut échapper à l’isolation et à l’enregistrement PAM ; le secours reste une exception distincte et tracée.Le bastion devient un point de contrôle, pas un simple serveur de rebond.Architecture pédagogique générique • aucune validation sur un SI clientPostes et identitéContrôle PAMCibles et preuvesLe PAM reçoit une demande d’activité ciblée, rattachée à une personne et non au seul compte technique.Demande d’activitéL’IdP ou annuaire avec MFA authentifie la personne à l’entrée prévue.Authentification forteLa politique exploite l’identité établie ; l’authentification ne décide pas seule des droits sur la cible.Preuve d’identitéLe PAM décide qui peut faire quoi ; l’intermédiaire applique le chemin de session retenu.Autorisation d’activitéSelon le scénario, le service remet un secret à l’intermédiaire, sans remise nécessaire au poste utilisateur.Identifiant / injectionL’intermédiaire ouvre une session vers la cible ; les règles limitent les sources autorisées.RDP / SSH autoriséCollecter les événements PAM et captures réellement disponibles ; protéger le stockage et transmettre les événements au SIEM.Traces et enregistrementsRapprocher les traces natives avec la session PAM ; surveiller aussi les absences de collecte.Événements cibleLe test de contournement vérifie le refus hors chemins ordinaires retenus. Si le filtrage manque, ce chemin peut être ouvert.Direct ordinaire : REFUSÉ par réseau / cible× REFUSL’urgence n’est pas un contournement libre : autorisation distincte, secret protégé, durée limitée, trace alternative et revue après usage.Secours distinct, autorisé et tracéAdmin nominatif / posteTerminal maîtriséPoint de contrôle : IdP / annuaire + MFAIdP / annuaire + MFAÉtablit l’identitéPoint de contrôle : Politique PAMPolitique PAMPersonne, activité, ciblePoint de contrôle : Intermédiaire de sessionIntermédiaire de sessionIsolation / contrôle selon modeCoffre / identifiantsInjection si nécessairePoint de contrôle : Windows RDP / Linux SSHWindows RDP / Linux SSHFiltrage réseau et ciblePreuves protégées / SIEMJournaux, capture, alertesPoint de contrôle : Accès d’urgenceAccès d’urgenceAutorisé, limité et journaliséLégende — sens des échanges et des points de contrôleAdministration autorisée — trait pleinIdentifiant / droit — tirets courtsJournalisation — pointillésChemin direct hors contrôle PAM — tirets longsDécision / contrôle — trait épaisCadre en tirets : frontière de confiance / réseau • cadre accentué : contrôleLa passerelle ne ferme pas les chemins alternatifs à elle seule. Le mode contrôlé suppose un filtrage réellement appliquésur les interfaces d’administration. En mode contournable, une session directe peut échapper à l’isolation et àl’enregistrement PAM ; le secours reste une exception distincte et tracée.Schéma original — Mon Premier PAM / Ariovis • Création et révision : 2026-10-23Hypothèses et références : monpremierpam.fr/architectures-pam#bastion-controle

La passerelle ne ferme pas les chemins alternatifs à elle seule. Le mode contrôlé suppose un filtrage réellement appliqué sur les interfaces d’administration. En mode contournable, une session directe peut échapper à l’isolation et à l’enregistrement PAM ; le secours reste une exception distincte et tracée.

Schéma original — Mon Premier PAM / Ariovis. Création éditoriale et révision : . Architecture pédagogique, pas un déploiement client validé. Les exports reprennent les couches et le mode sélectionnés.

Alternative textuelle : composants et échanges
  1. Demande d’activité. Le PAM reçoit une demande d’activité ciblée, rattachée à une personne et non au seul compte technique.
  2. Authentification forte. L’IdP ou annuaire avec MFA authentifie la personne à l’entrée prévue.
  3. Preuve d’identité. La politique exploite l’identité établie ; l’authentification ne décide pas seule des droits sur la cible.
  4. Autorisation d’activité. Le PAM décide qui peut faire quoi ; l’intermédiaire applique le chemin de session retenu.
  5. Identifiant / injection. Selon le scénario, le service remet un secret à l’intermédiaire, sans remise nécessaire au poste utilisateur.
  6. RDP / SSH autorisé. L’intermédiaire ouvre une session vers la cible ; les règles limitent les sources autorisées.
  7. Traces et enregistrements. Collecter les événements PAM et captures réellement disponibles ; protéger le stockage et transmettre les événements au SIEM.
  8. Événements cible. Rapprocher les traces natives avec la session PAM ; surveiller aussi les absences de collecte.
  9. Chemin direct hors contrôle PAM — Direct : bloqué en mode contrôlé. Le test de contournement vérifie le refus hors chemins ordinaires retenus. Si le filtrage manque, ce chemin peut être ouvert.
  10. Secours distinct, autorisé et tracé. L’urgence n’est pas un contournement libre : autorisation distincte, secret protégé, durée limitée, trace alternative et revue après usage.

Contexte et objectif

Les administrateurs nominatifs utilisent un poste maîtrisé. L’IdP établit l’identité, le PAM autorise l’activité, un intermédiaire ouvre la session et les règles réseau/cible restreignent les connexions ordinaires directes.

Imposer un premier chemin d’administration Windows/Linux et vérifier sa couverture réelle.

Composants et responsabilités
ComposantResponsabilité / limite
IdP / MFAVérifie qui demande ; protéger aussi les moyens de récupération et les sessions d’authentification.
Politique PAMDécide de l’activité et de la cible. Un compte partagé exige une association vérifiable avec la personne.
IntermédiaireApplique le contrôle de session choisi : proxy, passerelle ou autre technologie ; pas nécessairement un rebond Windows.
Réseau et cibleImposent les sources et interfaces autorisées, IPv4/IPv6, réseaux de gestion et alternatives inclus.
Preuves / SIEMStockage protégé, horloges cohérentes, permissions de consultation, rétention et alertes de collecte.
SecoursProcédure exploitable même si le PAM est indisponible ; réconciliation des traces et rotation après usage.

Hypothèses et frontières

  • Un premier périmètre de cibles et protocoles est défini.
  • Les règles sont appliquées sur tous les chemins ordinaires retenus ; l’urgence est traitée séparément.
  • Isolation, enregistrement et injection sont à confirmer par protocole et produit.

Risques réduits

  • Accès ordinaires depuis des postes non autorisés, si le filtrage est effectif.
  • Exposition des secrets au poste lorsqu’une injection appropriée est utilisée.
  • Sessions sans autorisation ou sans trace dans le chemin couvert.

Risques résiduels

  • Compromission du poste, de l’IdP, de la passerelle ou d’un compte d’administration du PAM.
  • Interfaces oubliées, droits excessifs sur cible, copie de données par presse-papiers ou transferts autorisés.
  • Panne, défaut de collecte ou enregistrement incomplet selon le protocole.

Erreurs de conception

  • Autoriser le bastion sans retirer les sources directes ordinaires.
  • MFA uniquement sur le portail, puis jetons ou sessions durables non maîtrisés.
  • Autoriser presse-papiers, disques redirigés et transferts sans décision explicite.
  • Prévoir une passerelle unique sans reprise testée ni accès de secours.
Cinq tests de recette — à réaliser sur un périmètre pilote autorisé
TestRésultat attendu
Refus du directDepuis un poste hors chemin autorisé, RDP/SSH est refusé sur toutes les interfaces retenues ; vérifier aussi IPv6 et réseau de gestion.
Identité et autorisationUn profil valide mais non autorisé ne rejoint pas la cible ; MFA et refus d’activité produisent la trace attendue.
Session et donnéesOuvrir une session pilote, vérifier injection/absence d’exposition selon mode, isolation, presse-papiers et transferts selon la politique.
PreuvesRelire une intervention connue : personne, compte, cible, horaires, capture disponible et événements cible ; tester les droits de consultation.
Indisponibilité et secoursExercer une panne préparée : continuité ou secours approuvé, traces alternatives, fermeture de l’accès et revue après retour.

03 — Hybride / prestataires

Comment contrôler les administrateurs internes et externes sans multiplier les accès directs ?

Figure — Comment contrôler les administrateurs internes et externes sans multiplier les accès directs ?
Couches du schéma
Lien direct
Comment contrôler les administrateurs internes et externes sans multiplier les accès directs ?Architecture pédagogique. Relier identité, période d’intervention, chemins internes et permissions cloud sans confondre les protocoles. Un VPN peut participer au contrôle réseau, mais ne remplace pas une permission par ressource ni la révocation de mission. Les consoles cloud et leurs API suivent ici un chemin fédéré séparé des sessions RDP/SSH ; leurs journaux natifs rejoignent l’investigation.Comment contrôler les administrateurs internes et externes sans multiplier les accès directs ?Architecture pédagogique générique • aucune validation sur un SI clientIntervenants / InternetEnvironnement d’administrationInterne et cloudL’IdP authentifie la personne interne ; une politique définit ses activités autorisées.Identité interneUne identité nominative ou fédérée est rattachée au prestataire, à la mission et à sa date de fin.Identité de mission + MFAL’accès distant ouvre seulement les destinations et services convenus ; VPN, ZTNA et passerelle ne sont pas supposés équivalents.Autorisation cibléeLe chemin serveur rejoint un contrôle de session compatible avec les protocoles retenus.Chemin serveurUne session vers un serveur cloud est une session serveur, distincte de l’administration de sa console cloud.RDP / SSH autoriséL’IdP fédère l’accès à la console ; les politiques cloud appliquent les permissions. Les API et jetons sont à traiter explicitement.Fédération / rôle cloudLes événements natifs cloud sont collectés : connexion, prise de rôle et opérations exposées par la source.Journaux cloud / APILes traces de session doivent être reliées à la mission, à la personne et aux événements cible.Session / missionCollecter les événements des serveurs et contrôler leur disponibilité.Événements cibleUn VPN trop large ou un accès direct oublié peut court-circuiter les contrôles de session ; recenser et restreindre ces chemins.Accès distant large : chemin résiduel à fermerAdministrateur interneIdentité nominativePrestataire externeIdentité et mission bornéePoint de contrôle : IdP / MFA / politiqueIdP / MFA / politiqueFédération et autorisationsPoint de contrôle : VPN / ZTNA / PAM adaptéVPN / ZTNA / PAM adaptéDestination et accès limitésPoint de contrôle : Contrôle de sessionsContrôle de sessionsRDP / SSH si retenusPoint de contrôle : Console / API cloudConsole / API cloudRôles et journaux natifsServeurs internes / cloudWindows et LinuxSécurité / SOCCorrélation personne–mission–cibleLégende — sens des échanges et des points de contrôleAdministration autorisée — trait pleinIdentifiant / droit — tirets courtsJournalisation — pointillésChemin direct hors contrôle PAM — tirets longsDécision / contrôle — trait épaisCadre en tirets : frontière de confiance / réseau • cadre accentué : contrôleUn VPN peut participer au contrôle réseau, mais ne remplace pas une permission par ressource ni la révocation de mission.Les consoles cloud et leurs API suivent ici un chemin fédéré séparé des sessions RDP/SSH ; leurs journaux natifsrejoignent l’investigation.Schéma original — Mon Premier PAM / Ariovis • Création et révision : 2026-10-23Hypothèses et références : monpremierpam.fr/architectures-pam#hybride-prestataires

Un VPN peut participer au contrôle réseau, mais ne remplace pas une permission par ressource ni la révocation de mission. Les consoles cloud et leurs API suivent ici un chemin fédéré séparé des sessions RDP/SSH ; leurs journaux natifs rejoignent l’investigation.

Schéma original — Mon Premier PAM / Ariovis. Création éditoriale et révision : . Architecture pédagogique, pas un déploiement client validé. Les exports reprennent les couches et le mode sélectionnés.

Alternative textuelle : composants et échanges
  1. Identité interne. L’IdP authentifie la personne interne ; une politique définit ses activités autorisées.
  2. Identité de mission + MFA. Une identité nominative ou fédérée est rattachée au prestataire, à la mission et à sa date de fin.
  3. Autorisation ciblée. L’accès distant ouvre seulement les destinations et services convenus ; VPN, ZTNA et passerelle ne sont pas supposés équivalents.
  4. Chemin serveur. Le chemin serveur rejoint un contrôle de session compatible avec les protocoles retenus.
  5. RDP / SSH autorisé. Une session vers un serveur cloud est une session serveur, distincte de l’administration de sa console cloud.
  6. Fédération / rôle cloud. L’IdP fédère l’accès à la console ; les politiques cloud appliquent les permissions. Les API et jetons sont à traiter explicitement.
  7. Journaux cloud / API. Les événements natifs cloud sont collectés : connexion, prise de rôle et opérations exposées par la source.
  8. Session / mission. Les traces de session doivent être reliées à la mission, à la personne et aux événements cible.
  9. Événements cible. Collecter les événements des serveurs et contrôler leur disponibilité.
  10. Chemin direct hors contrôle PAM — Accès distant large : chemin résiduel à fermer. Un VPN trop large ou un accès direct oublié peut court-circuiter les contrôles de session ; recenser et restreindre ces chemins.

Contexte et objectif

Cas pédagogique : une ETI avec Windows, Linux, Active Directory, ressources cloud, administrateurs internes et deux prestataires. Les accès à distance sont autorisés par personne, mission, destination et fenêtre réelle d’intervention.

Relier identité, période d’intervention, chemins internes et permissions cloud sans confondre les protocoles.

Composants et responsabilités
ComposantResponsabilité / limite
IntervenantsIdentité personnelle, sponsor interne, mission, durée et mécanisme de révocation.
IdP / politiqueFédération, MFA et autorisation par ressource ; gérer également les invités et moyens de récupération.
Accès distantVPN, ZTNA ou PAM selon l’architecture ; portée réseau et destination explicitement testées.
Sessions serveurWindows/Linux internes ou cloud ; capacités de capture et d’isolation dépendantes du mode.
Cloud / Kubernetes / workloadsConsole et API : rôles fédérés et journaux natifs. Kubernetes : RBAC, API et audit propres. Workloads : identité applicative et secrets, sans session humaine nécessaire.
SOCCorrélation des sources, intégrité et procédure d’investigation ; consolidation sans prétendre tout capturer.

Hypothèses et frontières

  • Chaque prestataire possède une identité reliée à une mission.
  • Les permissions cloud sont appliquées dans le cloud, pas par un bastion RDP fictif.
  • Kubernetes et identités applicatives nécessitent une analyse distincte ; ils ne sont pas couverts par les flèches serveur.

Risques réduits

  • Partage de comptes prestataires et accès distants sans destination ni date de fin.
  • Fragmentation des preuves, lorsque les sources sont correctement corrélées.

Risques résiduels

  • Jetons cloud persistants, clés API, identités applicatives et droits de plateforme hors couverture.
  • Fédération compromise, accès fournisseurs alternatifs, révocation ne terminant pas une session déjà ouverte.

Erreurs de conception

  • Considérer qu’un VPN sécurise à lui seul toute intervention.
  • Faire passer artificiellement les consoles et API cloud par RDP/SSH.
  • Fermer le compte invité sans vérifier rôles, jetons, sessions et accès résiduels.
  • Multiplier les portails sans identifier un propriétaire de chaque chemin.
Cinq tests de recette — à réaliser sur un périmètre pilote autorisé
TestRésultat attendu
MissionUne identité prestataire est associée à une mission, un responsable, des cibles et une fenêtre documentée.
PortéeLe prestataire peut joindre la destination approuvée, mais pas une cible ni un réseau hors périmètre.
CloudUn rôle cloud refuse une opération non permise et produit l’événement natif réellement disponible.
RévocationFinir la mission puis tester compte, rôle, jeton et session encore actifs selon les capacités des services.
CorrélationRetrouver la même personne et cible dans IdP, PAM, accès distant et événements cloud ou serveur.

04 — Privilèges temporaires

Et si le privilège n’existait que pendant l’intervention ?

Figure — Et si le privilège n’existait que pendant l’intervention ?
Couches du schéma
Lien direct
Et si le privilège n’existait que pendant l’intervention ?Architecture pédagogique. Ajouter une attribution et un retrait vérifiés aux contrôles d’identité et de session déjà opérationnels. JIT borne l’octroi dans le temps ; ZSP vise l’absence de privilèges permanents dans le périmètre retenu. Une identité éphémère est une manière possible d’y parvenir, pas la seule. L’expiration d’une demande ne prouve ni le retrait effectif des droits, ni la fermeture de toutes les sessions et de tous les jetons.Et si le privilège n’existait que pendant l’intervention ?Architecture pédagogique générique • aucune validation sur un SI clientDemande et décisionAttribution / sessionCible et vérificationLa personne demande une opération et une ressource pour une fenêtre définie.Demander une activitéLa politique décide ; une validation humaine peut être requise, sans être universelle.Évaluer le contexteUn mécanisme applique les droits ou crée l’accès temporaire sur un système compatible.Autoriser l’octroiA : compte persistant avec droits JIT. B : identité ou accès éphémère ; secret/credential selon mécanisme.A : droits JIT, compte persistantLes outils RDP/SSH et contrôles efficaces peuvent être conservés ; compatibilité et adaptation à valider.Session autoriséeLe mécanisme applique le retrait ou la suppression selon le modèle, y compris après incident de session.Fin / échéanceLire les droits effectifs et tester les accès résiduels ; une expiration PAM n’est pas une preuve suffisante.Vérifier, pas présumerConserver le lien entre personne, activité, rôle/compte et session.Usage et preuveJournaliser le succès ou l’échec de révocation et alerter sur les privilèges qui subsistent.Résultat du retraitAdministrateur identifiéIdentité nominative + MFADemande d’interventionCible, opération, duréePoint de contrôle : Politique / contextePolitique / contexteAutorisation et validationPoint de contrôle : Octroi temporaireOctroi temporaireA : droits JIT, compte persistantConnexion contrôléeSocle de session conservéRessource cibleDroits effectifs / activitéPoint de contrôle : Expiration / révocationExpiration / révocationRetrait appliqué sur la ciblePoint de contrôle : Vérification effectiveVérification effectiveDroits, sessions et jetonsSupervision / tracesDemande, octroi, usage, retraitLégende — sens des échanges et des points de contrôleAdministration autorisée — trait pleinIdentifiant / droit — tirets courtsJournalisation — pointillésChemin direct hors contrôle PAM — tirets longsDécision / contrôle — trait épaisCadre en tirets : frontière de confiance / réseau • cadre accentué : contrôleJIT borne l’octroi dans le temps ; ZSP vise l’absence de privilèges permanents dans le périmètre retenu. Une identitééphémère est une manière possible d’y parvenir, pas la seule. L’expiration d’une demande ne prouve ni le retrait effectifdes droits, ni la fermeture de toutes les sessions et de tous les jetons.Schéma original — Mon Premier PAM / Ariovis • Création et révision : 2026-10-23Hypothèses et références : monpremierpam.fr/architectures-pam#privileges-temporaires

JIT borne l’octroi dans le temps ; ZSP vise l’absence de privilèges permanents dans le périmètre retenu. Une identité éphémère est une manière possible d’y parvenir, pas la seule. L’expiration d’une demande ne prouve ni le retrait effectif des droits, ni la fermeture de toutes les sessions et de tous les jetons.

Schéma original — Mon Premier PAM / Ariovis. Création éditoriale et révision : . Architecture pédagogique, pas un déploiement client validé. Les exports reprennent les couches et le mode sélectionnés.

Alternative textuelle : composants et échanges
  1. Demander une activité. La personne demande une opération et une ressource pour une fenêtre définie.
  2. Évaluer le contexte. La politique décide ; une validation humaine peut être requise, sans être universelle.
  3. Autoriser l’octroi. Un mécanisme applique les droits ou crée l’accès temporaire sur un système compatible.
  4. Droit / credential limité. A : compte persistant avec droits JIT. B : identité ou accès éphémère ; secret/credential selon mécanisme.
  5. Session autorisée. Les outils RDP/SSH et contrôles efficaces peuvent être conservés ; compatibilité et adaptation à valider.
  6. Fin / échéance. Le mécanisme applique le retrait ou la suppression selon le modèle, y compris après incident de session.
  7. Vérifier, pas présumer. Lire les droits effectifs et tester les accès résiduels ; une expiration PAM n’est pas une preuve suffisante.
  8. Usage et preuve. Conserver le lien entre personne, activité, rôle/compte et session.
  9. Résultat du retrait. Journaliser le succès ou l’échec de révocation et alerter sur les privilèges qui subsistent.

Contexte et objectif

Une organisation garde son IdP, certaines politiques, son coffre, les contrôles de session et les journaux utiles. Elle ajoute des mécanismes de décision, d’attribution et de retrait compatibles avec ses ressources.

Ajouter une attribution et un retrait vérifiés aux contrôles d’identité et de session déjà opérationnels.

Composants et responsabilités
ComposantResponsabilité / limite
Demande / décisionRessource, opération, justification éventuelle, durée et conditions de validation.
Variante A — JIT, compte persistantLe compte existe avant et après. Les droits sélectionnés sont attribués puis retirés ; les autres droits restent à examiner.
Variante B — accès ou identité éphémèreL’identité privilégiée ou les droits sont établis à la demande puis supprimés/révoqués selon le mécanisme retenu.
Session / coffre / IdPConserver ce qui fonctionne ; aucune compatibilité avec tous les systèmes n’est présumée.
Retrait / vérificationRelire groupes et rôles, tester sessions/jetons ; traiter les échecs, caches et délais de propagation.

Hypothèses et frontières

  • Des interfaces d’attribution et de révocation existent sur le périmètre retenu.
  • Un compte de service durable ne devient pas éphémère sans traitement de ses dépendances.
  • ZSP est un objectif de réduction des privilèges permanents sur un périmètre explicite, pas une garantie globale du SI.

Risques réduits

  • Durée d’exposition de certains droits élevés et réutilisation hors fenêtre.
  • Accès permanents sans justification sur les scénarios intégrés.

Risques résiduels

  • Compte ou rôle d’orchestration puissant, jetons actifs, cache de groupes et échecs de retrait.
  • Droits permanents ailleurs dans le SI ; compromission pendant la fenêtre autorisée.

Erreurs de conception

  • Assimiler fermeture de session, retrait de droits et suppression d’identité.
  • Créer un compte temporaire sans contrôler ses permissions effectives.
  • Ignorer une panne de révocation ou supposer que tous les jetons expirent immédiatement.
Cinq tests de recette — à réaliser sur un périmètre pilote autorisé
TestRésultat attendu
AvantVérifier que les droits sélectionnés ne sont pas disponibles avant l’autorisation.
PendantL’octroi permet seulement l’activité ciblée et produit une trace liée à la demande.
Variante AAprès la fenêtre JIT, le compte persiste mais les droits sélectionnés sont retirés.
Variante BVérifier suppression de l’identité ou révocation de l’accès éphémère, selon le modèle réellement retenu.
Échec / résiduSimuler un retrait impossible sur un pilote : alerte, remédiation, contrôle des sessions, jetons et droits effectifs.

Une ETI fictive : conserver le socle, choisir les extensions

Exemple pédagogique, pas un résultat client : 180 serveurs Windows, 30 Linux, Active Directory, des hyperviseurs hébergeant des systèmes critiques, quelques ressources cloud, 12 administrateurs internes, deux prestataires et des comptes de service historiques.

Le choix du premier chemin dépend des pouvoirs réels : un accès à l’hyperviseur ou à l’annuaire peut compter davantage que de nombreux comptes locaux. La découverte précédente aide à identifier ce périmètre ; elle ne le sécurise pas à elle seule.

Évolution illustrative, ni planning ni séquence obligatoire
ÉtatArbitrage opérationnelVérification
Accès directs historiquesRecenser comptes, interfaces et chemins ; protéger les interventions indispensables.Identifier propriétaires, droits effectifs et voies de secours.
Premier contrôle : coffreOrganiser les identifiants sans casser les dépendances des comptes de service.Récupération autorisée, rotation pilote et limite des preuves.
Premier palier PAMChoisir quelques chemins critiques ; filtrer le direct ordinaire et contrôler les sessions.Essai de contournement, identité, traces et continuité.
Extension hybrideBorner les missions ; séparer serveurs, consoles cloud et identités applicatives.Révocation prestataire et corrélation des sources.
Privilèges temporaires ciblésRéutiliser IdP, coffre et sessions si compatibles ; ajouter octroi et retrait.Absence avant accès, droits pendant, retrait effectif après.

Les contraintes de disponibilité, les applications anciennes et les dépendances d’exploitation peuvent imposer des exceptions documentées. Le JIT peut être retenu dès le premier chemin compatible ; cette progression n’est pas obligatoire pour tous les SI.

Approfondir la procédure JIT et les contrôles de fin d’intervention.

Piège rencontré

Mettre une application ancienne derrière un bastion peut créer un nouveau risque

Scénario pédagogique

Certaines applications d'administration anciennes ne suivent pas un simple parcours « identifiant, mot de passe, connexion ». L'utilisateur choisit d'abord une cible dans un client spécifique, ouvre plusieurs sessions ou s'appuie sur des menus et des actions impossibles à reproduire facilement par le connecteur prévu.

Lire la démarche et les vérifications à réaliser

Si la passerelle oblige finalement l'opérateur à ressaisir le secret dans des champs ou scripts mal maîtrisés, l'identifiant peut se retrouver exposé dans un journal, un enregistrement ou un fichier de configuration. Le gain attendu du bastion devient discutable ; un simple rebond sans gestion correcte du secret ne suffit pas.

À vérifier pendant le pilote : ouverture et changement de cible, sessions simultanées, traitement des secrets sans affichage ni journalisation indésirable, rotation réellement prise en charge, ergonomie acceptable et solution de repli. Une exception documentée et maîtrisée vaut mieux qu'une intégration annoncée comme terminée alors qu'elle dégrade la sécurité.

Références, hypothèses et réutilisation

Responsabilité éditoriale : Ariovis / Mon Premier PAM. Les figures sont des propositions pédagogiques originales. Les tests décrivent des critères à appliquer à votre architecture ; aucun résultat de recette client ni validation indépendante n’est revendiqué.

Sources officielles consultées le 23 octobre 2026. La documentation Azure illustre des capacités et limites propres à ce produit, pas une propriété de tous les bastions. Le catalogue NIST est un cadre de contrôles, pas une certification. Les recommandations CNIL ne fixent pas une durée légale universelle pour tout enregistrement.

CyberArk Blueprint, Secure Infrastructure Access / PSM, PAM FastTrack et analyses Ariovis figurent dans le cadrage conceptuel fourni. Aucun support propriétaire absent du projet n’est présenté comme directement consulté. Aucun schéma propriétaire n’est reproduit ni aucune capacité actuelle Netwrix déduite de ces figures génériques.

Pour citer : « Schéma original — Mon Premier PAM / Ariovis », titre de la figure, date de révision et lien direct. Le téléchargement ne vaut pas licence ouverte : demander une autorisation écrite pour reproduire ou adapter les figures, conformément aux mentions légales.

Votre architecture PAM fonctionne. Comment la faire évoluer ?

Sécuriser un premier chemin d’administration est une étape importante. La suite consiste à étendre cette maîtrise sans multiplier les contournements, les comptes permanents et les contraintes d’exploitation. Ariovis accompagne les organisations vers des architectures PAM évolutives, des privilèges temporaires et une meilleure intégration avec leur stratégie IAM.

Découvrir l’expertise PAM avancée d’Ariovis — nouvelle fenêtre