Réduis services, ports, logiciels et fonctions inutiles

01Utilise quatre décisions distinctes

KEEP
Le composant est requis dans son état cible.

RESTRICT
La fonction reste nécessaire mais son exposition ou ses droits diminuent.

DISABLE
Le composant reste installé pour un retour rapide mais ne doit pas s'exécuter.

REMOVE
Le composant et ses artefacts actifs sont retirés selon une procédure réversible.

Ces décisions n’ont pas le même impact opérationnel.

02Manipule le plan de réduction

lab=/tmp/soria-hardening-lot1-$USER
bash module1-baseline-change-recovery.sh setup "$lab"
bash module1-baseline-change-recovery.sh run "$lab"

column -s, -t "$lab/output/reduction-plan.csv"
diff -u "$lab/work/services-before.csv" "$lab/work/services-target.csv" || true

Le delta attendu conserve les fonctions métier et traite les composants hérités.

03Observe les décisions SORIA

Le lab ne ferme aucun port réel. Il valide la cohérence des décisions.

04Commence par la nécessité

Pour chaque service :

Qui en est propriétaire ?
Quelle mission dépend de lui ?
Qui doit y accéder ?
Depuis quelle zone ?
À quel moment ?
Existe-t-il un remplacement ?
Quel test démontre que la mission reste disponible ?

Sans réponse, marque l’élément comme écart à examiner. Ne le supprime pas automatiquement sur un système réel.

05Restreins avant de retirer quand le rôle l’exige

ssh et web-admin restent nécessaires. La réduction porte sur leur chemin :

avant
administration accessible depuis plusieurs zones

cible
administration depuis management via chemin dédié

preuve attendue
source autorisée acceptée
source utilisateur refusée
fonction d'administration disponible

La mise en œuvre réseau détaillée avec OPNsense et WireGuard appartient au Lot 5.

06Associe un test fonctionnel

Le retrait de FTP n’est acceptable que si le transfert métier a réellement une alternative.

Dans la fixture :

awk 'END { print NR - 1 }' "$lab/restore/snapshot-2026-08-05/data/orders.csv"
grep -F 'service=erp-api' "$lab/restore/snapshot-2026-08-05/app/config/app.conf"

Le test montre que les données et la configuration représentées restent lisibles.

Sur un vrai ERP, il faudrait exécuter un parcours métier autorisé, pas seulement vérifier un processus.

07Prépare le rollback par type d’action

RESTRICT
restaurer règle ou configuration précédente

DISABLE
réactiver service et vérifier son état

REMOVE
réinstaller version approuvée et restaurer configuration

KEEP
aucun changement ; surveiller la dérive

Le rollback doit inclure l’artefact, l’autorité et le test après retour.

08Reconnais les échecs classiques

• suppression d’un agent nécessaire à la sauvegarde ;
• retrait d’une bibliothèque utilisée indirectement ;
• fermeture du seul chemin d’administration ;
• désactivation d’un service d’identité critique ;
• suppression sans preuve before ;
• test technique vert mais fonction métier cassée ;
• rollback documenté sans paquet ni configuration disponibles.

Un critère d’arrêt doit déclencher le rollback avant que l’effet ne s’étende.

09Valide les refus

Le validateur exige que :

telnet      removed
ftp         removed
sample-app  removed
avahi       disabled
ssh         restricted
web-admin   restricted

Il exige aussi que :

https erp-api dns kerberos wireguard backup-ingest

restent présents dans l’état cible représenté.