Kit d’architecture réutilisable • Ariovis
Kit d’architectures PAM : schémas, fiches techniques et checklist de revue
Quatre figures originales avec leurs hypothèses, critères de recette et limites. Téléchargement sans inscription ; une revue en 20 points pour préparer la discussion d’architecture.
01 — Coffre seul — fiche technique
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. Accès au coffre. L’utilisateur s’authentifie au coffre ; la permission de consulter l’entrée est évaluée dans le coffre.
- Remise autorisée. Le coffre remet l’identifiant selon les permissions ; une récupération n’est pas une preuve de session.
- Secret connu du poste. Le secret devient accessible sur le poste ; la restriction du coffre ne peut effacer une copie déjà obtenue.
- 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.
- 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.
- É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.
| Composant | Responsabilité / limite |
|---|---|
| Administrateur / poste | Établit la connexion et reçoit le secret. La sécurité du terminal reste déterminante. |
| Coffre-fort | Protège le stockage, évalue la consultation et produit sa trace ; rotation selon capacités et configuration. |
| Cible | Authentifie le compte et applique ses droits effectifs, indépendamment de la consultation du coffre. |
| Journaux | La 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.
| Test | Résultat attendu |
|---|---|
| Permission | Un profil non autorisé ne récupère pas l’entrée ; le refus apparaît dans les traces prévues. |
| Réutilisation | Sur une cible de test, vérifier si un secret déjà récupéré fonctionne après retrait de la permission du coffre. |
| Couverture | Comparer un journal de récupération à une activité cible : identifier les informations réellement absentes. |
| Rotation | Tester le changement et la révocation sur une cible pilote, avec validation des dépendances. |
| Chemin | Depuis un poste de test autorisé, inventorier les routes RDP/SSH encore acceptées. |
02 — Chemin contrôlé — fiche technique
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
- Demande d’activité. Le PAM reçoit une demande d’activité ciblée, rattachée à une personne et non au seul compte technique.
- Authentification forte. L’IdP ou annuaire avec MFA authentifie la personne à l’entrée prévue.
- Preuve d’identité. La politique exploite l’identité établie ; l’authentification ne décide pas seule des droits sur la cible.
- Autorisation d’activité. Le PAM décide qui peut faire quoi ; l’intermédiaire applique le chemin de session retenu.
- Identifiant / injection. Selon le scénario, le service remet un secret à l’intermédiaire, sans remise nécessaire au poste utilisateur.
- RDP / SSH autorisé. L’intermédiaire ouvre une session vers la cible ; les règles limitent les sources autorisées.
- Traces et enregistrements. Collecter les événements PAM et captures réellement disponibles ; protéger le stockage et transmettre les événements au SIEM.
- Événements cible. Rapprocher les traces natives avec la session PAM ; surveiller aussi les absences de collecte.
- 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.
- 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.
| Composant | Responsabilité / limite |
|---|---|
| IdP / MFA | Vérifie qui demande ; protéger aussi les moyens de récupération et les sessions d’authentification. |
| Politique PAM | Décide de l’activité et de la cible. Un compte partagé exige une association vérifiable avec la personne. |
| Intermédiaire | Applique le contrôle de session choisi : proxy, passerelle ou autre technologie ; pas nécessairement un rebond Windows. |
| Réseau et cible | Imposent les sources et interfaces autorisées, IPv4/IPv6, réseaux de gestion et alternatives inclus. |
| Preuves / SIEM | Stockage protégé, horloges cohérentes, permissions de consultation, rétention et alertes de collecte. |
| Secours | Procé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.
| Test | Résultat attendu |
|---|---|
| Refus du direct | Depuis 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 autorisation | Un profil valide mais non autorisé ne rejoint pas la cible ; MFA et refus d’activité produisent la trace attendue. |
| Session et données | Ouvrir une session pilote, vérifier injection/absence d’exposition selon mode, isolation, presse-papiers et transferts selon la politique. |
| Preuves | Relire une intervention connue : personne, compte, cible, horaires, capture disponible et événements cible ; tester les droits de consultation. |
| Indisponibilité et secours | Exercer une panne préparée : continuité ou secours approuvé, traces alternatives, fermeture de l’accès et revue après retour. |
03 — Hybride / prestataires — fiche technique
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
- Identité interne. L’IdP authentifie la personne interne ; une politique définit ses activités autorisées.
- Identité de mission + MFA. Une identité nominative ou fédérée est rattachée au prestataire, à la mission et à sa date de fin.
- Autorisation ciblée. L’accès distant ouvre seulement les destinations et services convenus ; VPN, ZTNA et passerelle ne sont pas supposés équivalents.
- Chemin serveur. Le chemin serveur rejoint un contrôle de session compatible avec les protocoles retenus.
- RDP / SSH autorisé. Une session vers un serveur cloud est une session serveur, distincte de l’administration de sa console cloud.
- 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.
- Journaux cloud / API. Les événements natifs cloud sont collectés : connexion, prise de rôle et opérations exposées par la source.
- Session / mission. Les traces de session doivent être reliées à la mission, à la personne et aux événements cible.
- Événements cible. Collecter les événements des serveurs et contrôler leur disponibilité.
- 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.
| Composant | Responsabilité / limite |
|---|---|
| Intervenants | Identité personnelle, sponsor interne, mission, durée et mécanisme de révocation. |
| IdP / politique | Fédération, MFA et autorisation par ressource ; gérer également les invités et moyens de récupération. |
| Accès distant | VPN, ZTNA ou PAM selon l’architecture ; portée réseau et destination explicitement testées. |
| Sessions serveur | Windows/Linux internes ou cloud ; capacités de capture et d’isolation dépendantes du mode. |
| Cloud / Kubernetes / workloads | Console 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. |
| SOC | Corré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.
| Test | Résultat attendu |
|---|---|
| Mission | Une identité prestataire est associée à une mission, un responsable, des cibles et une fenêtre documentée. |
| Portée | Le prestataire peut joindre la destination approuvée, mais pas une cible ni un réseau hors périmètre. |
| Cloud | Un rôle cloud refuse une opération non permise et produit l’événement natif réellement disponible. |
| Révocation | Finir la mission puis tester compte, rôle, jeton et session encore actifs selon les capacités des services. |
| Corrélation | Retrouver la même personne et cible dans IdP, PAM, accès distant et événements cloud ou serveur. |
04 — Privilèges temporaires — fiche technique
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
- Demander une activité. La personne demande une opération et une ressource pour une fenêtre définie.
- Évaluer le contexte. La politique décide ; une validation humaine peut être requise, sans être universelle.
- Autoriser l’octroi. Un mécanisme applique les droits ou crée l’accès temporaire sur un système compatible.
- Droit / credential limité. A : compte persistant avec droits JIT. B : identité ou accès éphémère ; secret/credential selon mécanisme.
- Session autorisée. Les outils RDP/SSH et contrôles efficaces peuvent être conservés ; compatibilité et adaptation à valider.
- Fin / échéance. Le mécanisme applique le retrait ou la suppression selon le modèle, y compris après incident de session.
- 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.
- Usage et preuve. Conserver le lien entre personne, activité, rôle/compte et session.
- 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.
| Composant | Responsabilité / limite |
|---|---|
| Demande / décision | Ressource, opération, justification éventuelle, durée et conditions de validation. |
| Variante A — JIT, compte persistant | Le 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ère | L’identité privilégiée ou les droits sont établis à la demande puis supprimés/révoqués selon le mécanisme retenu. |
| Session / coffre / IdP | Conserver ce qui fonctionne ; aucune compatibilité avec tous les systèmes n’est présumée. |
| Retrait / vérification | Relire 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.
| Test | Résultat attendu |
|---|---|
| Avant | Vérifier que les droits sélectionnés ne sont pas disponibles avant l’autorisation. |
| Pendant | L’octroi permet seulement l’activité ciblée et produit une trace liée à la demande. |
| Variante A | Après la fenêtre JIT, le compte persiste mais les droits sélectionnés sont retirés. |
| Variante B | Vérifier suppression de l’identité ou révocation de l’accès éphémère, selon le modèle réellement retenu. |
| Échec / résidu | Simuler un retrait impossible sur un pilote : alerte, remédiation, contrôle des sessions, jetons et droits effectifs. |
Checklist de revue d’architecture : 20 points
0 points vérifiés · 0 écarts · 20 à vérifier · 0 non applicables. Aucun score de conformité.
1. Identités
Chaque utilisateur est identifiable ; invités et comptes partagés ont un responsable.
État : À vérifier — Constat : Non renseigné
2. Authentification
MFA et récupération d’accès sont testés sur les entrées prévues.
État : À vérifier — Constat : Non renseigné
3. Autorisations
Personne, activité et cible sont explicitement autorisées ; tester un refus.
État : À vérifier — Constat : Non renseigné
4. Privilèges
Les droits effectifs sur la cible sont justifiés et limités.
État : À vérifier — Constat : Non renseigné
5. Identifiants
Remise, injection, rotation et révocation des secrets sont documentées et testées.
État : À vérifier — Constat : Non renseigné
6. Segmentation
Sources, interfaces, IPv4/IPv6 et réseaux de gestion sont recensés.
État : À vérifier — Constat : Non renseigné
7. Connexions directes
Les chemins ordinaires non autorisés sont effectivement refusés.
État : À vérifier — Constat : Non renseigné
8. Isolation
Le mode de session et ses frontières d’isolation sont vérifiés par protocole.
État : À vérifier — Constat : Non renseigné
9. Enregistrement
Une intervention pilote produit une capture exploitable lorsqu’elle est prévue.
État : À vérifier — Constat : Non renseigné
10. Journaux
PAM, IdP et cibles sont corrélés ; une absence de collecte est signalée.
État : À vérifier — Constat : Non renseigné
11. Prestataires
Mission, sponsor, cibles, date de fin et révocation sont vérifiables.
État : À vérifier — Constat : Non renseigné
12. Comptes partagés
La personne reste associable au compte technique et à son intervention.
État : À vérifier — Constat : Non renseigné
13. Comptes de service
Dépendances et usages non interactifs sont recensés avant modification.
État : À vérifier — Constat : Non renseigné
14. Cloud
Console, API, Kubernetes et workloads ont des permissions et traces adaptées.
État : À vérifier — Constat : Non renseigné
15. Disponibilité
La reprise et les dépendances critiques sont exercées sur un pilote.
État : À vérifier — Constat : Non renseigné
16. Urgence
Le secours reste autorisé, protégé, limité et traçable hors disponibilité PAM.
État : À vérifier — Constat : Non renseigné
17. Révocation
Droits, identités, sessions et jetons résiduels sont vérifiés après usage.
État : À vérifier — Constat : Non renseigné
18. Exploitation des preuves
Intégrité, horloges, accès, rétention et procédure d’investigation sont documentés.
État : À vérifier — Constat : Non renseigné
19. Contournement
Un essai négatif couvre les chemins alternatifs du périmètre, après autorisation.
État : À vérifier — Constat : Non renseigné
20. Risques résiduels
Un responsable accepte et documente les limites, exceptions et prochaine revue.
État : À vérifier — Constat : Non renseigné
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.
- Microsoft — exemple de limites de capture RDP/SSH dans Azure Bastion ↗ — nouvelle fenêtre
- Microsoft — chemin RDP via Bastion et exposition réseau ↗ — nouvelle fenêtre
- CNIL — sécurité : tracer les opérations ↗ — nouvelle fenêtre
- NIST SP 800-53 — contrôle d’accès et audit ↗ — nouvelle fenêtre
- Microsoft Entra PIM — activation limitée des rôles éligibles ↗ — nouvelle fenêtre
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.