Admin MPCZ
677f621c81
- Admin applications: CRUD module (list/add/edit/delete/assign/multi-app) avec push iTop bidirectionnel (applications.py + 3 templates) - Correspondance prod<->hors-prod: migration vers server_correspondance globale, suppression ancien code quickwin, ajout filtre environnement et solution applicative, colonne environnement dans builder - Servers page: colonne application_name + equivalent(s) via get_links_bulk, filtre application_id, push iTop sur changement application - Patching: bulk_update_application, bulk_update_excludes, validations - Fix paramiko sftp.put (remote_path -> positional arg) - Tools: wiki_to_pdf.py (DokuWiki -> PDF) + generate_ppt.py (PPTX 19 slides DSI patching) + contenu source (processus_patching.txt, script_presentation.txt) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
392 lines
17 KiB
Plaintext
392 lines
17 KiB
Plaintext
====== Script de présentation — Processus Patching SANEF ======
|
|
|
|
<WRAP round info>
|
|
**Format :** présentation DSI, ~18 minutes de parole + Q&A\\
|
|
**Ton :** oral, direct, factuel. Préférer des phrases courtes. Regarder l'auditoire, pas le slide.\\
|
|
**Astuce :** les phrases en //italique// sont des respirations / silences volontaires, souvent plus efficaces que les arguments.
|
|
</WRAP>
|
|
|
|
----
|
|
|
|
===== Slide 1 — Titre (30 s) =====
|
|
|
|
<code>
|
|
[entrée en scène, attendre quelques secondes]
|
|
</code>
|
|
|
|
Bonjour à tous, merci d'être là.
|
|
|
|
On va parler ce matin du **patching des serveurs SANEF** — de comment ça se passe aujourd'hui, de ce que ça coûte réellement à l'équipe SECOPS, et de ce qu'on est en train de mettre en place pour changer la donne.
|
|
|
|
L'idée, c'est de vous montrer pourquoi l'automatisation qu'on développe — **PatchCenter Web** — n'est pas juste un outil de confort : c'est un vrai levier de sécurité pour SANEF.
|
|
|
|
//[pause — transition slide]//
|
|
|
|
----
|
|
|
|
===== Slide 2 — Sommaire (30 s) =====
|
|
|
|
Voilà rapidement le plan.
|
|
|
|
On va commencer par **dérouler le processus** étape par étape — pour qu'on ait tous la même image en tête de ce que fait concrètement un patcheur dans sa semaine.
|
|
|
|
Ensuite on va regarder **la réalité du terrain** : combien d'heures ça prend, et surtout ce qui se passe quand le patcheur doit aussi faire autre chose — les tickets iTop, les tours de garde, la météo sécurité.
|
|
|
|
Et on finira par **l'apport de l'automatisation** : ce qu'on a déjà — SQATM — et ce qu'on est en train de livrer — PatchCenter Web.
|
|
|
|
----
|
|
|
|
===== Slide 3 — Vue d'ensemble (1 min) =====
|
|
|
|
Le patching d'un serveur, ce n'est pas un geste unique. C'est **quatre phases étalées sur la semaine**.
|
|
|
|
Première phase, le **jeudi à 14 heures** : le COMEP SECOPS. C'est là qu'on répartit les serveurs à patcher entre les intervenants.
|
|
|
|
Deuxième phase, **jeudi après-midi et vendredi** : la préparation — ce qu'on appelle aussi le pré-patching. C'est toute la qualification serveur avant de toucher à quoi que ce soit.
|
|
|
|
Troisième phase, **du lundi au jeudi** de la semaine suivante : l'exécution — le fameux **Jour J**.
|
|
|
|
Et quatrième phase, **le vendredi** : le nettoyage. On supprime les snapshots des serveurs patchés dans la semaine, et on fait le ménage sur les vieux kernels.
|
|
|
|
//[pointer le callout en bas]//
|
|
|
|
Un point important : **on ne patche jamais le vendredi**. Pourquoi ? Parce que si un incident survient, on ne veut pas le traîner tout le weekend. Donc le vendredi est dédié à tout le reste — prépa de la semaine suivante, nettoyage, iTop, météo.
|
|
|
|
----
|
|
|
|
===== Slide 4 — Affectation (45 s) =====
|
|
|
|
Donc on démarre le jeudi au COMEP. 14 heures.
|
|
|
|
Chaque intervenant repart avec **sa liste de serveurs pour la semaine**. En cible on est à **20 serveurs par intervenant**. C'est un chiffre important à garder en tête, on va y revenir.
|
|
|
|
Le livrable du COMEP, c'est une liste enrichie : domaine, environnement, OS, responsable applicatif, criticité. Avec ça, le patcheur peut démarrer la qualification immédiatement.
|
|
|
|
----
|
|
|
|
===== Slide 5 — Préparation (1 min 30) =====
|
|
|
|
La préparation — c'est là que le gros du temps invisible se joue.
|
|
|
|
Pour **chaque serveur**, il faut faire **13 étapes** :
|
|
|
|
//[parcourir la liste à l'écran, ne pas la lire]//
|
|
|
|
Ça va de la recherche dans la console Qualys, à l'analyse des vulnérabilités, au SSH pour vérifier l'espace disque, le satellite, le dry-run yum... et ensuite seulement la partie "humaine" : **contacter le responsable applicatif** et lui proposer des créneaux.
|
|
|
|
//[pointer le KPI à droite]//
|
|
|
|
Résultat : **20 à 30 minutes par serveur** de travail actif. Pour 20 serveurs par patcheur par semaine, ça fait **6h40 à 10 heures** — rien que sur la préparation.
|
|
|
|
Et encore — je ne compte pas le temps d'attente de la validation du responsable. Qui peut prendre 1 heure, ou 48 heures. Donc le patcheur jongle avec une dizaine de serveurs en parallèle, tous à des états différents.
|
|
|
|
----
|
|
|
|
===== Slide 6 — Jour J (1 min 30) =====
|
|
|
|
On arrive au Jour J — forcément entre lundi et jeudi.
|
|
|
|
Là encore, **13 étapes par serveur**.
|
|
|
|
Ça commence par un message Teams pour prévenir, on prend le snapshot vCenter, on met le serveur en maintenance dans Centreon si c'est de la prod, on fait un snap pré-patch des services et des ports — parce qu'on veut pouvoir comparer après reboot. Ensuite seulement, le yum update. Le reboot. La reconnexion. Le check post-patch. Et enfin la **validation par le responsable applicatif** — qui peut demander 15 minutes ou plus si le service n'est pas immédiatement disponible.
|
|
|
|
//[pointer les KPIs]//
|
|
|
|
Le temps actif : **35 à 65 minutes par serveur**. Sur 20 serveurs, on est entre **11h40 et 21h40** par semaine rien que sur l'exécution.
|
|
|
|
//[petit silence]//
|
|
|
|
Pourquoi pas le vendredi ? On l'a dit : **au moins 24 heures de recul avant le weekend**. Si un service tombe dimanche, on veut pouvoir le détecter le vendredi.
|
|
|
|
----
|
|
|
|
===== Slide 7 — Nettoyage (45 s) =====
|
|
|
|
Le vendredi, on **regroupe le nettoyage** de toute la semaine.
|
|
|
|
Suppression des anciens snapshots, suppression des vieux kernels. Environ 1 heure 40 pour le lot de 20 serveurs.
|
|
|
|
Pourquoi on fait ça en un bloc le vendredi ? Pour deux raisons.
|
|
|
|
D'abord : on veut **garder le snapshot pendant au moins 24 heures** après le patch, au cas où une anomalie apparaîtrait en production.
|
|
|
|
Ensuite : c'est un **contexte mental unique**. Traiter les 20 snapshots d'un bloc, c'est beaucoup plus efficace que d'y revenir serveur par serveur.
|
|
|
|
----
|
|
|
|
===== Slide 8 — Synthèse temps (1 min) =====
|
|
|
|
Donc si on additionne tout ça pour **un seul serveur** :
|
|
|
|
* Préparation : 20-30 minutes
|
|
* Jour J : 35-65 minutes
|
|
* Nettoyage : 5 minutes
|
|
|
|
Total : **60 à 100 minutes par serveur**. En moyenne, **1 heure 15**.
|
|
|
|
//[pointer les KPIs du bas]//
|
|
|
|
**1 heure 15 par serveur. 20 serveurs par semaine. 25 heures de patching pur.**
|
|
|
|
//[silence — laisser le chiffre s'installer]//
|
|
|
|
----
|
|
|
|
===== Slide 9 — La réalité du patcheur (1 min 30) =====
|
|
|
|
Maintenant, la vraie question : **est-ce que le patcheur a 25 heures disponibles ?**
|
|
|
|
Regardons son budget. Le patcheur travaille **5 jours sur 7**, **7 heures par jour** — donc **35 heures par semaine**.
|
|
|
|
//[pointer la barre]//
|
|
|
|
Sur ces 35 heures :
|
|
* **28 heures** du lundi au jeudi sont la fenêtre d'exécution des Jours J
|
|
* **3,5 heures** le jeudi après-midi pour le COMEP et le début du pré-patching
|
|
* **7 heures** le vendredi pour finir le pré-patching et nettoyer
|
|
|
|
Et dans ces 35 heures, le patching seul consomme **entre 20 et 33 heures**.
|
|
|
|
Autrement dit : **entre 57 % et 95 % du temps disponible**.
|
|
|
|
//[insister]//
|
|
|
|
Dans le meilleur des cas — si tous les patches passent sans accroc, si personne ne traîne sur la validation, si aucun incident — il reste 2 heures de marge par semaine.
|
|
|
|
Et encore. **On n'a pas parlé des autres missions.**
|
|
|
|
----
|
|
|
|
===== Slide 10 — Missions annexes (1 min) =====
|
|
|
|
Parce qu'un patcheur SECOPS n'est pas que patcheur.
|
|
|
|
//[lister lentement]//
|
|
|
|
Il doit aussi :
|
|
* Traiter les **tickets iTop** de sécurisation serveur — permanent, 2 à 5 heures par semaine
|
|
* Faire les **mises à jour agents Qualys** et **SentinelOne** — 2 à 6 heures par semaine
|
|
* Prendre le **tour de garde** sur les alertes SentinelOne et Defender — 3 à 6 heures quand c'est son tour
|
|
* Produire la **météo sécurité** — 2 à 4 heures quand c'est son tour
|
|
|
|
Au total : **9 à 21 heures de missions annexes**.
|
|
|
|
//[pointer le callout rouge]//
|
|
|
|
Faites le calcul avec moi :
|
|
* Budget disponible : **35 heures**
|
|
* Patching seul : **20 à 33 heures**
|
|
* Missions annexes : **9 à 21 heures**
|
|
* **Charge totale réelle : 29 à 54 heures par semaine**
|
|
|
|
//[silence]//
|
|
|
|
Le patcheur est **structurellement en surcharge**. Pas occasionnellement. Structurellement.
|
|
|
|
----
|
|
|
|
===== Slide 11 — Conséquence sécurité (1 min 30) =====
|
|
|
|
Et c'est là que ça devient **un sujet de sécurité**, pas juste un sujet d'organisation.
|
|
|
|
//[ton plus grave]//
|
|
|
|
Quand un patcheur est en surcharge et qu'il prend son tour de garde sur les alertes SentinelOne et Defender, qu'est-ce qui se passe ?
|
|
|
|
//[lire les points avec poids]//
|
|
|
|
* Les alertes sont **triées en surface** — on regarde la criticité apparente, on coche, on passe
|
|
* Les **faux positifs ne sont pas requalifiés** — le bruit de fond s'accumule et masque les vrais incidents
|
|
* Les **vrais incidents sont détectés tardivement** — un ransomware, une exfiltration, un lateral movement
|
|
* L'**enrichissement de contexte** — corrélation process, réseau, utilisateur — n'est pas fait
|
|
* Les **règles de détection** ne sont jamais affinées, parce qu'on n'a pas le temps de faire ce retour d'expérience
|
|
|
|
//[pointer le callout rouge]//
|
|
|
|
Et là, on parle d'**incidents de sécurité majeurs**. Ransomware, fuite de données, indisponibilité.
|
|
|
|
**Le coût d'une seule alerte EDR ratée — c'est sans commune mesure avec le coût de l'automatisation du patching.**
|
|
|
|
//[silence]//
|
|
|
|
Voilà pourquoi automatiser le patching, ce n'est pas du confort. C'est de la sécurité.
|
|
|
|
----
|
|
|
|
===== Slide 12 — SQATM .exe (45 s) =====
|
|
|
|
On a déjà fait un pas dans cette direction : **SQATM .exe** est en production depuis un moment.
|
|
|
|
Cet outil automatise la **phase qualification** — la fameuse préparation des 20-30 minutes par serveur.
|
|
|
|
//[parcourir le tableau]//
|
|
|
|
La recherche Qualys plus l'analyse des vulnérabilités passe de 5 minutes à 30 secondes.\\
|
|
Le check SSH — disque, satellite, dry-run — passe de 5 minutes à 10 secondes, et surtout on le fait sur 100 serveurs en parallèle.\\
|
|
Le tagging Qualys est instantané.
|
|
|
|
**Gain estimé : 60 à 70 % sur la phase préparation.**
|
|
|
|
//[transition]//
|
|
|
|
Mais SQATM ne couvre que la partie qualification. Pour automatiser le Jour J, il fallait passer au niveau au-dessus.
|
|
|
|
----
|
|
|
|
===== Slide 13 — PatchCenter Web (1 min 30) =====
|
|
|
|
C'est l'objet de **PatchCenter Web**.
|
|
|
|
//[présenter les 3 colonnes]//
|
|
|
|
Trois grands volets.
|
|
|
|
**Préparation** — on centralise tout : vue unifiée des 1165 serveurs, audit SSH parallélisé, détection automatique des correspondances prod / hors-prod, workflow de validation intégré, et les tags Qualys auto-appliqués via les Tag Rules.
|
|
|
|
**Jour J** — on orchestre tout : snapshot vCenter via API, maintenance Centreon via API, notifications Teams automatiques, snap pré et post archivé, yum update en job asynchrone, reboot et reconnexion orchestrés, et détection automatique des régressions.
|
|
|
|
**Gouvernance** — c'est ce qui manquait le plus : la validation prod / hors-prod **bloquante**, l'historique complet par serveur, l'audit log exportable pour la conformité, et l'authentification LDAP AD SANEF avec 4 profils — admin, coordinateur, opérateur, viewer.
|
|
|
|
//[conclure]//
|
|
|
|
Et surtout : le tableau de suivi est **en temps réel**. Fini les Excel.
|
|
|
|
----
|
|
|
|
===== Slide 14 — Comparaison chiffrée (1 min) =====
|
|
|
|
Si on met les trois scénarios côte à côte, serveur par serveur :
|
|
|
|
//[parcourir le tableau rapidement]//
|
|
|
|
En mode manuel, on est à **60-100 minutes par serveur**.\\
|
|
Avec SQATM, on descend à **40-70 minutes** — **gain de 30 %**.\\
|
|
Avec PatchCenter Web, on descend à **15-30 minutes** — **gain de 70 à 75 %**.
|
|
|
|
//[pointer la dernière ligne]//
|
|
|
|
**On divise le temps par 3 à 4.**
|
|
|
|
Et ce qui est intéressant, c'est que **le gain ne vient pas du yum update lui-même** — ça reste le même temps à l'OS de mettre à jour les paquets. Le gain vient de **la suppression des gestes répétitifs** : snapshot, Centreon, notifs, suivi. C'est là que se cache tout le temps perdu.
|
|
|
|
----
|
|
|
|
===== Slide 15 — Impact hebdomadaire (1 min) =====
|
|
|
|
Traduisons ça au niveau hebdomadaire, pour les **20 serveurs par patcheur**.
|
|
|
|
//[parcourir les 3 lignes]//
|
|
|
|
En manuel : le patching occupe 20 à 33 heures. Reste 2 à 15 heures. **Insuffisant pour absorber les missions annexes.**
|
|
|
|
Avec SQATM : on libère 10 à 12 heures supplémentaires. Ça tient si le patcheur n'est pas en tour de garde.
|
|
|
|
**Avec PatchCenter Web : 5 à 10 heures de patching. Il reste 25 à 30 heures.**
|
|
|
|
//[laisser respirer]//
|
|
|
|
**25 à 30 heures par semaine libérées — par patcheur.**
|
|
|
|
De quoi assurer sereinement les tickets iTop, la garde EDR, la météo. Et même **monter la cadence** si le besoin opérationnel le demande — passer de 20 à 25, 30 serveurs par semaine, sans embaucher.
|
|
|
|
----
|
|
|
|
===== Slide 16 — Bénéfices qualitatifs (45 s) =====
|
|
|
|
Au-delà du temps, il y a tout ce qui est plus difficile à chiffrer mais tout aussi important.
|
|
|
|
//[balayer rapidement]//
|
|
|
|
* **Fiabilité** : on ne peut plus oublier un snapshot ou une maintenance Centreon
|
|
* **Traçabilité** : tout est historisé, exportable pour audit
|
|
* **Gouvernance** : les validations prod / hors-prod deviennent bloquantes
|
|
* **Scalabilité** : un intervenant peut piloter 20 serveurs en parallèle
|
|
* **Onboarding** : un nouveau patcheur est opérationnel en quelques jours
|
|
* **Qualité** : le snap pré/post standardisé détecte les régressions de façon fiable
|
|
* **Conformité** : les tags Qualys automatiques alimentent directement les KPI
|
|
* **Communication** : les notifications Teams standardisées donnent de la visibilité projet
|
|
|
|
----
|
|
|
|
===== Slide 17 — Feuille de route (45 s) =====
|
|
|
|
Où on en est concrètement aujourd'hui.
|
|
|
|
//[colonne verte]//
|
|
|
|
**Déjà livré :** SQATM en production. PatchCenter Web avec le catalogue des 1165 serveurs, la correspondance prod / hors-prod, les exclusions patch, le workflow de validation, la gestion des agents Qualys et le déploiement, l'intégration bidirectionnelle iTop, et l'authentification LDAP multi-profils.
|
|
|
|
//[colonne orange]//
|
|
|
|
**À venir :** l'orchestration vCenter et Centreon automatique, l'intégration Teams native, l'exécution patching end-to-end en un clic, le module reporting pour la DSI, et l'extension aux serveurs Windows via WSUS et MECM.
|
|
|
|
On est sur une livraison progressive — on n'attend pas que tout soit fini pour en profiter. Chaque brique livrée apporte déjà du gain.
|
|
|
|
----
|
|
|
|
===== Slide 18 — Conclusion (1 min) =====
|
|
|
|
Je conclus avec **trois messages** à retenir.
|
|
|
|
//[pointer le premier carré]//
|
|
|
|
**Un.** Le patching manuel est un **coût caché**. On le voit peu parce qu'il est étalé sur la semaine, mais c'est **20 à 33 heures par semaine par patcheur**.
|
|
|
|
**Deux.** Le patcheur est **structurellement en surcharge**. Dès qu'il cumule patching, garde et iTop, il dépasse son budget horaire. Ce n'est pas une question de motivation — c'est de l'arithmétique.
|
|
|
|
**Trois.** L'automatisation **libère 25 à 30 heures par semaine**. Du temps pour **analyser correctement les alertes EDR**.
|
|
|
|
//[pointer le callout final]//
|
|
|
|
Le message clé, pour vous, DSI :
|
|
|
|
//[lire posément]//
|
|
|
|
**PatchCenter Web n'est pas qu'un gain de productivité.** C'est un **levier de sécurité stratégique**.
|
|
|
|
Le temps qu'on libère sur le patching, c'est du temps qu'on rend au patcheur pour faire **son vrai métier d'analyste EDR**.
|
|
|
|
Automatiser le patching, c'est **renforcer directement la capacité de détection et de réponse aux incidents de SANEF**.
|
|
|
|
Merci.
|
|
|
|
----
|
|
|
|
===== Slide 19 — Q&A =====
|
|
|
|
//[rester en place, poser le clicker, regarder l'auditoire]//
|
|
|
|
Je prends vos questions.
|
|
|
|
----
|
|
|
|
===== Annexe — Questions fréquentes anticipées =====
|
|
|
|
==== "Pourquoi pas un outil du marché ?" ====
|
|
|
|
On a évalué. Aucun outil marché ne couvre à la fois : la nomenclature SANEF (décodage hostname), l'intégration bidirectionnelle iTop, la correspondance prod / hors-prod, et l'orchestration Centreon / vCenter spécifique SANEF. PatchCenter Web est **conçu pour le contexte**, et ça se voit dans le taux d'adoption de l'équipe.
|
|
|
|
==== "Combien ça coûte à développer vs la licence d'un outil marché ?" ====
|
|
|
|
Le développement est internalisé — pas de licence récurrente, pas de dépendance vendor. Le coût est largement en-dessous de ce qu'aurait coûté un déploiement commercial type Red Hat Satellite Insights ou BigFix sur 1165 serveurs.
|
|
|
|
==== "Et la sécurité de l'outil lui-même ?" ====
|
|
|
|
PatchCenter Web est derrière HAProxy avec TLS, authentification LDAP AD SANEF, séparation des rôles (4 profils), audit log complet. Tout transite par la VRF d'administration SANEF. Aucune exposition internet.
|
|
|
|
==== "Que devient SQATM une fois PatchCenter Web complet ?" ====
|
|
|
|
SQATM reste pertinent pour les opérations unitaires rapides et le tagging ponctuel. Les deux outils **coexistent** : SQATM = léger, rapide, unitaire. PatchCenter = orchestration lourde, campagnes, gouvernance.
|
|
|
|
==== "Risque de régression : si PatchCenter Web tombe, que fait-on ?" ====
|
|
|
|
Le patching manuel reste possible en fallback — tous les outils sous-jacents (SSH, vCenter, Centreon, Qualys) sont indépendants de PatchCenter. On ne crée pas de dépendance critique : PatchCenter Web **orchestre**, il ne **remplace** pas les outils existants.
|
|
|
|
==== "Planning de mise en service complète ?" ====
|
|
|
|
Livraison progressive en cours. Les modules catalogue, correspondance, validations et agents Qualys sont déjà en production. L'orchestration vCenter/Centreon/Teams est prévue sur les mois à venir. Le patching end-to-end en un clic est la dernière brique.
|
|
|
|
----
|
|
|
|
//— Script de présentation — SANEF DSI / Sécurité Opérationnelle — Avril 2026//
|