Premier projet PAM • Ariovis

Modèle de note de cadrage PAM

Douze rubriques remplies pour une ETI entièrement fictive. Adaptez les objectifs, les exclusions et les conditions de recette, puis récupérez un document modifiable.

Note de cadrage modifiable

Modifications limitées à cette page ouverte : téléchargez avant de quitter. Aucun envoi ni stockage sur le site. Ne saisissez aucun secret, mot de passe ni donnée confidentielle.

# Note de cadrage — Premier palier PAM

Exemple entièrement fictif, à adapter. Aucun résultat client ni engagement de délai.
Version : exemple pédagogique — Responsable de validation : DSI à désigner.

## 1. Contexte et problème de départ
ETI fictive : 180 serveurs Windows, 30 serveurs Linux, un Active Directory, une infrastructure de virtualisation, 12 administrateurs internes et 2 prestataires. Des comptes de service historiques subsistent. Aucun PAM centralisé ne couvre tout le périmètre. Les usages Domain Admin depuis des postes bureautiques et l’administration des hyperviseurs hébergeant les DC sont les chemins prioritaires.

## 2. Objectifs de sécurité
Attribuer les interventions à une identité nominative ; fermer les chemins directs non autorisés vers les cibles retenues ; vérifier les droits et leur retrait ainsi que la reconstruction d’une intervention. Les seuils de durée, délais de révocation et besoins de conservation seront approuvés avant la recette.

## 3. Risques traités
Vol d’un identifiant administratif depuis un poste bureautique, propagation vers l’annuaire et contrôle indirect d’un DC par l’hyperviseur. Les risques hors premier périmètre restent inscrits au registre, sans être réputés résolus par le PAM.

## 4. Comptes, identités et systèmes concernés
Identités nominatives des administrateurs AD habilités ; comptes privilégiés associés aux activités AD retenues ; hyperviseurs hébergeant les DC et interfaces d’administration correspondantes. Inventaire nominatif et liste exacte des cibles conservés dans l’annexe interne sécurisée, validés par les propriétaires. Les 12 administrateurs ne reçoivent pas tous les mêmes droits.

## 5. Périmètre explicitement exclu
Rotation des comptes de service historiques avant cartographie des consommateurs ; couverture de tous les comptes locaux Windows ; administration Linux et cloud non liée aux cibles pilotes. Évaluer LAPS existant avant chaque vague Windows. Les prestataires sont analysés selon leur exposition : un accès direct vers une cible pilote doit être fermé ou faire l’objet d’une exception approuvée, même si l’onboarding général des prestataires est reporté.

## 6. Choix d’architecture
Identité nominative via annuaire, authentification forte, politique explicite par activité et cible, gestion du secret si nécessaire, contrôle de session et filtrage des flux depuis les postes autorisés. Journaux PAM, annuaire, réseau et cible corrélables. Poste d’administration, bastion et coffre n’assurent pas la même fonction. JIT peut être retenu dès ce palier si création et retrait des droits sont compatibles et testables. Un schéma de flux et une liste de ports seront validés avec le réseau ; aucun secret dans cette note.

## 7. Équipes et responsabilités
RSSI approuve la politique et suit les exceptions ; propriétaire de ressource décide des droits ; PAM implémente les activités ; IAM raccorde les identités et leur cycle de vie ; réseau filtre ; infrastructure réalise les interventions et valide les outils ; SOC exploite les traces. Le responsable RUN est nommé avant mise en production. Si plusieurs rôles sont tenus par la même personne, la responsabilité reste explicitement attribuée.

## 8. Critères de réussite
Parcours autorisé fonctionnel, refus hors périmètre, accès direct interdit bloqué, privilège réel vérifié sur cible, révocation effective, traces retrouvables, secours éprouvé et onboarding reproduit. Réaliser les 20 tests de recette ; justifier chaque non-applicable. Un test critique en échec ne devient pas acceptable parce que le coffre contient plus de comptes.

## 9. Risques résiduels et exceptions
Compte de service multi-scripts : risque de rotation non maîtrisée ; propriétaire applicatif responsable de la cartographie avant changement. Tout accès de secours ou flux temporaire a un motif, un responsable, un contrôle compensatoire, une échéance et une date de réexamen. Aucune exception sans propriétaire ne peut être acceptée. Les enregistrements ne couvrent pas nécessairement toutes les opérations ni tous les protocoles.

## 10. Planning et jalons
Exemple 30/60/90 jours, pas garantie : jours 1–30 cadrage et architecture ; jours 31–60 intégration et tests nominaux ; jours 61–90 contournement, secours et transfert RUN. GO 1 : périmètre et propriétaires approuvés. GO 2 : parcours, refus et traces éprouvés. GO 3 : recette et reprise validées. Replanifier si les prérequis ne sont pas réunis.

## 11. Conditions de mise en production
Tous les tests applicables réussis ou exceptions formellement acceptées par l’autorité compétente ; aucun contournement critique non maîtrisé ; secours testé ; supervision, sauvegardes, reprise, support et procédures approuvés. PV signé par DSI, responsable RUN et propriétaires concernés, selon les délégations de l’organisation. Cette note n’est pas une attestation de conformité.

## 12. Prochaine vague de déploiement
Reproduire sur une famille d’hyperviseurs compatible, intégrer les prestataires selon leur exposition puis étendre Windows après analyse LAPS. Traiter les secrets techniques dans un lot avec inventaire des consommateurs, rotation de test et retour arrière. Réévaluer l’automatisation, IAM/IGA, JIT et réduction des privilèges permanents à chaque vague.

# Note de cadrage — Premier palier PAM Exemple entièrement fictif, à adapter. Aucun résultat client ni engagement de délai. Version : exemple pédagogique — Responsable de validation : DSI à désigner. ## 1. Contexte et problème de départ ETI fictive : 180 serveurs Windows, 30 serveurs Linux, un Active Directory, une infrastructure de virtualisation, 12 administrateurs internes et 2 prestataires. Des comptes de service historiques subsistent. Aucun PAM centralisé ne couvre tout le périmètre. Les usages Domain Admin depuis des postes bureautiques et l’administration des hyperviseurs hébergeant les DC sont les chemins prioritaires. ## 2. Objectifs de sécurité Attribuer les interventions à une identité nominative ; fermer les chemins directs non autorisés vers les cibles retenues ; vérifier les droits et leur retrait ainsi que la reconstruction d’une intervention. Les seuils de durée, délais de révocation et besoins de conservation seront approuvés avant la recette. ## 3. Risques traités Vol d’un identifiant administratif depuis un poste bureautique, propagation vers l’annuaire et contrôle indirect d’un DC par l’hyperviseur. Les risques hors premier périmètre restent inscrits au registre, sans être réputés résolus par le PAM. ## 4. Comptes, identités et systèmes concernés Identités nominatives des administrateurs AD habilités ; comptes privilégiés associés aux activités AD retenues ; hyperviseurs hébergeant les DC et interfaces d’administration correspondantes. Inventaire nominatif et liste exacte des cibles conservés dans l’annexe interne sécurisée, validés par les propriétaires. Les 12 administrateurs ne reçoivent pas tous les mêmes droits. ## 5. Périmètre explicitement exclu Rotation des comptes de service historiques avant cartographie des consommateurs ; couverture de tous les comptes locaux Windows ; administration Linux et cloud non liée aux cibles pilotes. Évaluer LAPS existant avant chaque vague Windows. Les prestataires sont analysés selon leur exposition : un accès direct vers une cible pilote doit être fermé ou faire l’objet d’une exception approuvée, même si l’onboarding général des prestataires est reporté. ## 6. Choix d’architecture Identité nominative via annuaire, authentification forte, politique explicite par activité et cible, gestion du secret si nécessaire, contrôle de session et filtrage des flux depuis les postes autorisés. Journaux PAM, annuaire, réseau et cible corrélables. Poste d’administration, bastion et coffre n’assurent pas la même fonction. JIT peut être retenu dès ce palier si création et retrait des droits sont compatibles et testables. Un schéma de flux et une liste de ports seront validés avec le réseau ; aucun secret dans cette note. ## 7. Équipes et responsabilités RSSI approuve la politique et suit les exceptions ; propriétaire de ressource décide des droits ; PAM implémente les activités ; IAM raccorde les identités et leur cycle de vie ; réseau filtre ; infrastructure réalise les interventions et valide les outils ; SOC exploite les traces. Le responsable RUN est nommé avant mise en production. Si plusieurs rôles sont tenus par la même personne, la responsabilité reste explicitement attribuée. ## 8. Critères de réussite Parcours autorisé fonctionnel, refus hors périmètre, accès direct interdit bloqué, privilège réel vérifié sur cible, révocation effective, traces retrouvables, secours éprouvé et onboarding reproduit. Réaliser les 20 tests de recette ; justifier chaque non-applicable. Un test critique en échec ne devient pas acceptable parce que le coffre contient plus de comptes. ## 9. Risques résiduels et exceptions Compte de service multi-scripts : risque de rotation non maîtrisée ; propriétaire applicatif responsable de la cartographie avant changement. Tout accès de secours ou flux temporaire a un motif, un responsable, un contrôle compensatoire, une échéance et une date de réexamen. Aucune exception sans propriétaire ne peut être acceptée. Les enregistrements ne couvrent pas nécessairement toutes les opérations ni tous les protocoles. ## 10. Planning et jalons Exemple 30/60/90 jours, pas garantie : jours 1–30 cadrage et architecture ; jours 31–60 intégration et tests nominaux ; jours 61–90 contournement, secours et transfert RUN. GO 1 : périmètre et propriétaires approuvés. GO 2 : parcours, refus et traces éprouvés. GO 3 : recette et reprise validées. Replanifier si les prérequis ne sont pas réunis. ## 11. Conditions de mise en production Tous les tests applicables réussis ou exceptions formellement acceptées par l’autorité compétente ; aucun contournement critique non maîtrisé ; secours testé ; supervision, sauvegardes, reprise, support et procédures approuvés. PV signé par DSI, responsable RUN et propriétaires concernés, selon les délégations de l’organisation. Cette note n’est pas une attestation de conformité. ## 12. Prochaine vague de déploiement Reproduire sur une famille d’hyperviseurs compatible, intégrer les prestataires selon leur exposition puis étendre Windows après analyse LAPS. Traiter les secrets techniques dans un lot avec inventaire des consommateurs, rotation de test et retour arrière. Réévaluer l’automatisation, IAM/IGA, JIT et réduction des privilèges permanents à chaque vague.