Voici l’**arbre de questions dynamique** pour l’audit de l’architecture d’un
**Serveur DHCP**, focalisé sur la position des dispositifs et l’intégration
d’autres assets pour le protéger. Chaque question est accompagnée des **gaps
possibles** identifiés selon les réponses, et fait référence aux normes **NIST
SP 800-53** et **ISO 27001**.
---
## 1. Segmentation et Isolation
*(Standards : NIST SP 800-53 SC-7, ISO 27001 A.11.1.1)*
**Q1.1 – L’emplacement physique du serveur DHCP est-il clairement défini (ex. data
center, salle serveur dédiée, armoire réseau sécurisée) ?**
- 🔲 **A.** Oui, l’emplacement est bien identifié et documenté
- 🔲 **B.** Partiellement, l’emplacement est connu mais non officiellement documenté
ou sécurisé
- 🔲 **C.** Non, l’emplacement physique exact n’est pas précisé ou difficilement
identifiable
> **Gaps possibles :**
> - (B) Risque d’accès non planifié ou non sécurisé à l’équipement
> - (C) Impossibilité de contrôler physiquement les accès, non-conformité
ISO 27001 A.11.1.1 citeturn0search14
**Q1.2 – Le serveur DHCP est-il isolé dans un segment réseau dédié (VLAN ou
sous-réseau spécifique) pour limiter son exposition ?**
- 🔲 **A.** Oui, il est clairement isolé dans un segment dédié
- 🔲 **B.** Partiellement, la segmentation existe mais nécessite une révision des
règles de pare-feu pour un isolement plus efficace
- 🔲 **C.** Non, le serveur est accessible depuis plusieurs segments sans filtrage
adéquat
> **Gaps possibles :**
> - (B) Trafic non critique peut transiter sur le même segment, difficulté à
appliquer des ACL cohérentes
> - (C) Exposition accrue aux attaques latérales, non-conformité NIST SC-7
citeturn0search9
**Q1.3 – Un dispositif de contrôle d’accès réseau (pare-feu NGFW, IDS/IPS) est-il
positionné en périphérie du segment du serveur DHCP ?**
- 🔲 **A.** Oui, un pare-feu et/ou IDS/IPS protège le segment
- 🔲 **B.** Partiellement, un dispositif est mentionné mais son placement reste flou
- 🔲 **C.** Non, aucun dispositif de protection n’est prévu
> **Gaps possibles :**
> - (B) Filtrage partiel, vecteurs d’attaque non couverts
> - (C) Absence de détection/prévention d’intrusion, non-conformité NIST SI-4
citeturn0search13
---
## 2. Authentification et Contrôle d’Accès
*(Standard : NIST SP 800-53 AC-2)*
**Q2.1 – Existe-t-il un processus de gestion des comptes et des accès pour le
serveur DHCP (incluant révocation des comptes inactifs ou obsolètes) ?**
- 🔲 **A.** Oui, revue périodique et révocation formalisée
- 🔲 **B.** Partiellement, certains comptes sont gérés mais pas de politique
formelle
- 🔲 **C.** Non, aucun processus clairement défini
> **Gaps possibles :**
> - (B) Comptes dormants pouvant être compromis
> - (C) Risk de comptes non autorisés actifs, non-conformité NIST AC-2
citeturn0search11
**Q2.2 – Les contrôles d’accès (RBAC, ACL) sont-ils appliqués de manière cohérente
sur tous les points de gestion du serveur DHCP ?**
- 🔲 **A.** Oui, mécanismes uniformes et centralisés
- 🔲 **B.** Partiellement, certaines interfaces bénéficient d’un meilleur contrôle
- 🔲 **C.** Non, incohérences dans l’application des règles
> **Gaps possibles :**
> - (B) Zones avec privilèges non maîtrisés
> - (C) Accès non restreint, violation du principe du moindre privilège
citeturn0search11
---
## 3. Protection Contre les Menaces
*(Standard : NIST SP 800-53 SI-4)*
**Q3.1 – Le design intègre-t-il des mécanismes de détection et de prévention
spécifiques aux attaques DHCP (usurpation, rogue DHCP) ?**
- 🔲 **A.** Oui, dispositifs dédiés (DHCP snooping, DHCP guard) sont en place
- 🔲 **B.** Partiellement, certaines mesures existent mais restent incomplètes
- 🔲 **C.** Non, aucun mécanisme dédié n’est prévu
> **Gaps possibles :**
> - (B) Usurpation d’adresse IP possible
> - (C) Attaques rogue DHCP non détectées, non-conformité NIST SI-4
citeturn0search13
---
## 4. Journalisation et Surveillance
*(Standard : NIST SP 800-53 AU-2)*
**Q4.1 – Le document d’architecture définit-il des mécanismes de journalisation
pour le serveur DHCP (attributions, requêtes, erreurs) ?**
- 🔲 **A.** Oui, logs complets et structurés
- 🔲 **B.** Partiellement, certains événements sont capturés mais couverture
incomplète
- 🔲 **C.** Non, pas de stratégie de journalisation spécifique
> **Gaps possibles :**
> - (B) Incidents détectés tardivement
> - (C) Impossibilité de reconstituer la chaîne d’événements, non-conformité
NIST AU-2 citeturn0search12
---
## 5. Redondance et Haute Disponibilité
*(Standard : NIST SP 800-53 CP-2)*
**Q5.1 – Le document d’architecture prévoit-il une redondance (DHCP failover,
clustering) pour assurer la continuité du service ?**
- 🔲 **A.** Oui, solution de basculement clairement définie
- 🔲 **B.** Partiellement, dispositif de failover mentionné mais non détaillé
- 🔲 **C.** Non, aucune redondance prévue
> **Gaps possibles :**
> - (B) Risque d’interruption prolongée lors d’une panne
> - (C) Point unique de défaillance, non-conformité NIST CP-2
citeturn0search10
**Q5.2 – Le design permet-il une restauration rapide et une continuité des services
en cas d’incident majeur ?**
- 🔲 **A.** Oui, procédures de reprise optimisées
- 🔲 **B.** Partiellement, restauration possible mais délais importants
- 🔲 **C.** Non, plan de continuité insuffisant
> **Gaps possibles :**
> - (B) Temps de rétablissement non garanti
> - (C) Continuité de service compromise, non-conformité NIST CP-2
citeturn0search10
---
Cet arbre, riche en **logique conditionnelle**, identifie pour chaque réponse les
**gaps de sécurité et d’emplacement**, et oriente automatiquement vers les
questions de remédiation ou de documentation complémentaire.
