Pratique une banque de remédiations transversales

01Utilise toujours le même contrat de remédiation

Pour chaque cas, remets une fiche courte :

1. symptôme exact et périmètre
2. faits disponibles
3. au moins trois hypothèses classées
4. test discriminant choisi et raison du choix
5. résultat observé
6. cause confirmée ou niveau de certitude
7. correction ou confinement borné
8. risque + rollback
9. test du service après action
10. test négatif ou contrôle collatéral pertinent
11. preuves conservées
12. limite de la conclusion

Une action sans preuve avant/après ne valide pas le cas.

02Réutilisation : ne recrée pas ce qui existe déjà

La banque s’appuie sur les évaluations BTS déjà présentes :

poste client                  -> évaluations support / poste Windows
DNS + annuaire                -> évaluations résilience AD/DNS
routage + VLAN + pare-feu     -> évaluations réseau/segmentation
service web                   -> évaluation publication/DMZ
sauvegarde + haute disponibilité -> évaluations résilience
supervision                   -> évaluation supervision/exploitation

Les cas ci-dessous ne remplacent pas ces évaluations. Ils permettent des variantes courtes et ajoutent surtout les familles encore peu exercées comme remédiations autonomes : DHCP, GPO, privilèges et certificat.

03Cas A — poste client

Symptôme fourni : un seul poste ne peut plus atteindre l’intranet alors qu’un poste voisin du même service y accède.

Pièces possibles :

configuration IP du poste
table de routage
résolution DNS
résultat TCP vers le service
ticket utilisateur

Le formateur choisit une cause unique parmi une mauvaise configuration locale, une résolution incorrecte ou une règle locale. Le candidat ne reçoit pas la cause.

04Cas B — DNS

Symptôme : le nom app.soria.lab échoue depuis certains clients mais le service répond par adresse IP.

Le dossier peut contenir :

résolveur configuré sur deux clients
extrait de zone synthétique
résultats nslookup/Resolve-DnsName
horodatage d'un changement récent

Le candidat doit déterminer si la panne est client, enregistrement, serveur interrogé ou propagation/réplication du scénario.

05Cas C — DHCP

Symptôme : de nouveaux clients d’un VLAN reçoivent une adresse inattendue ou aucune adresse alors que les clients existants fonctionnent.

Réutilise notamment :

windows/deployer-verifier-dhcp-laboratoire
windows/configurer-dhcp-failover

Variantes injectables :

scope épuisé
option de passerelle erronée
scope désactivé
relay/VLAN incohérent dans la maquette
partenaire de failover non cohérent avec l'état présenté

Le candidat doit d’abord distinguer absence de bail, bail incorrect et dépendance réseau.

06Cas D — annuaire

Symptôme : un utilisateur peut ouvrir une session mais ne reçoit plus l’accès attendu à une ressource liée à son identité.

Indices possibles :

appartenance aux groupes
OU de l'objet
réplication disponible
journal d'authentification
matrice d'habilitations

Le candidat doit éviter de « réparer » en ajoutant l’utilisateur à un groupe très privilégié.

07Cas E — GPO

Symptôme : une politique attendue s’applique à CLIENT-01 mais pas à CLIENT-02.

Réutilise :

windows/concevoir-lier-depanner-gpo

Pièces :

OU des deux postes
liens GPO
résultat gpresult ou équivalent de laboratoire
état DNS/joignabilité domaine
heure du dernier rafraîchissement observé

Le candidat doit distinguer portée, héritage/filtrage, connectivité/dépendance et simple délai de rafraîchissement avant de modifier la GPO.

08Cas F — routage

Symptôme : le réseau utilisateur atteint sa passerelle mais pas un service situé sur un autre réseau.

Le dossier contient des extraits bornés de :

tables de routage
traceroute
adressage
matrice de flux

Une route manquante et un filtrage sont deux hypothèses différentes ; une modification globale du pare-feu n’est pas un test de routage.

09Cas G — VLAN

Symptôme : un poste branché sur un port donné obtient un comportement réseau correspondant à une autre zone.

Le candidat utilise les preuves de commutation déjà apprises : VLAN du port, trunk, table MAC, adressage reçu et chemin attendu.

10Cas H — pare-feu

Symptôme : le service existe et écoute, mais un seul flux légitime attendu est refusé.

Le candidat doit :

identifier source/destination/protocole/port
localiser le point de filtrage
examiner la règle pertinente et son ordre
proposer la modification minimale
prouver que le flux attendu passe
prouver qu'un flux qui doit rester interdit reste refusé

Une règle any/any invalide la remédiation.

11Cas I — service web

Symptôme : le nom se résout et le port répond, mais la recette HTTP/HTTPS échoue.

Les pièces peuvent montrer : binding, état du service, réponse HTTP, journal serveur et certificat présenté. Le candidat doit séparer panne applicative, binding, TLS et dépendance réseau.

12Cas J — sauvegarde

Symptôme : une sauvegarde est marquée terminée mais une restauration de contrôle ne satisfait pas la recette.

Le candidat doit comparer :

objet attendu
point de restauration choisi
intégrité/présence des données
RPO/RTO du scénario
preuve de restore

« Job vert » n’est pas équivalent à « reprise validée ».

13Cas K — haute disponibilité

Symptôme : un composant secondaire existe mais le service ne reste pas disponible pendant le basculement contrôlé.

Le candidat doit identifier la dépendance réellement non redondée : DNS, adressage, réplication, health-check, route ou service selon le scénario fourni.

14Cas L — supervision

Symptôme : Centreon signale un service CRITICAL, mais un test utilisateur semble fonctionner.

Réutilise observabilite/superviser-infrastructure-centreon et l’évaluation supervision. Le candidat distingue panne réelle, check mal paramétré, seuil inadapté et donnée périmée avant acquittement ou correction.

15Cas M — compte privilégié

Symptôme : une action d’administration fonctionne uniquement avec un compte trop privilégié alors qu’une délégation plus bornée est attendue.

Réutilise :

windows/appliquer-agdlp-deleguer-administration
windows/durcir-domaine-comptes-privilegies

Le dossier fournit une matrice de responsabilités, les groupes utiles et un extrait d’audit synthétique. Le candidat ne doit jamais contourner le problème en ajoutant durablement un compte à Domain Admins ou à un équivalent très privilégié.

La correction attendue est une délégation conforme au besoin et testée avec :

action autorisée réussie
action non autorisée refusée
trace d'administration disponible
rollback de la délégation documenté

16Cas N — certificat

Symptôme : un service HTTPS répond mais le client signale une erreur de confiance ou d’identité.

Réutilise :

cybersecurity/gerer-cles-certificats-tls-confiance

Pièces possibles :

nom demandé
SAN/CN observé
émetteur
chaîne de confiance
période de validité
heure du client
certificat réellement présenté par le service

Le candidat doit identifier la propriété en défaut sans désactiver globalement la vérification TLS. Les clés privées réelles sont exclues des preuves.

17Cas O — incident sécurité multi-source

Ce cas sert de transition vers l’évaluation longue.

Le formateur fournit au moins trois sources synthétiques :

journal d'authentification
journal hôte ou annuaire
journal réseau / pare-feu / IDS
éventuellement journal applicatif

Le candidat doit produire une chronologie factuelle, distinguer événement/alerte/incident, formuler deux hypothèses concurrentes et indiquer quelle preuve manque encore.

Aucun exercice offensif n’est requis : les traces sont préparées pour l’analyse.

18Rotation pédagogique

La banque n’a pas vocation à faire les quinze cas dans une seule séance.

Progression recommandée :

rotation 1 : 3 cas mono-cause de familles différentes
rotation 2 : 3 cas avec deux dépendances possibles
rotation 3 : 2 cas avec preuve incomplète et niveau de certitude
rotation 4 : 1 cas multi-source avant l'évaluation longue

Le formateur peut changer les valeurs, hôtes et symptômes sans changer la compétence évaluée.

19Barème commun d’un cas court

Le score récompense le raisonnement, pas le nombre de commandes exécutées.