En bref : un plan d'urgence informatique pour serveurs web fixe à l'avance qui décide en situation de crise, qui l'on peut joindre, quels systèmes peuvent être concernés et quelles étapes suivent dans quel ordre. Qui veut créer un plan d'urgence informatique n'a pas besoin d'un gros manuel, mais de quelques pages à jour, accessibles même sans informatique fonctionnelle. La situation autour de PHP2Shell est une bonne occasion de le faire maintenant.
Pourquoi un plan d'urgence fait gagner du temps et limite les dégâts
En situation de crise, les premières heures se perdent souvent à chercher : qui a accès à l'hébergeur ? Où sont les sauvegardes ? Qui décide de mettre la boutique hors ligne ? Qui doit être informé ? Un plan d'urgence répond à ces questions à l'avance, dans le calme.
PHP2Shell a montré à quel point le temps peut être court. Le 20 octobre 2026, php.net a annoncé les correctifs, le 21 octobre à 16 h, heure allemande, ils ont été publiés, et le BSI (office fédéral allemand de la sécurité des technologies de l'information) a recommandé la mise à jour immédiate ou l'arrêt temporaire. Les entreprises disposant d'un plan savaient qui appeler et quels serveurs vérifier. Les autres ont d'abord dû découvrir où PHP tourne.
Créer un plan d'urgence informatique : les éléments
Un plan utilisable pour des serveurs web comprend ces parties :
1. Rôles et décisions. Qui dirige en cas d'urgence, qui remplace, qui peut arrêter des systèmes, qui s'exprime vers l'extérieur ? Consignez les noms et les suppléances.
2. Liste de contacts. Interlocuteurs internes, hébergeur, agence, prestataire informatique, délégué à la protection des données, conseil juridique, cyberassurance avec numéro de contrat, autorité de protection des données compétente, le point de contact central cybercriminalité (ZAC) de votre Land allemand. Cette liste doit exister sur papier.
3. Inventaire des systèmes. Chaque site, chaque boutique et chaque portail avec serveur, hébergeur, mode d'exécution, version de PHP, application, responsable et type de données traitées.
4. Règles de décision. Dans quelles conditions déconnectons-nous un système du réseau ? Qui peut en décider ? Que vaut-il la nuit et le week-end ?
5. Procédures. Courtes séquences d'étapes pour les cas typiques : faille critique connue, soupçon d'intrusion, site défiguré, fuite de données, chantage.
6. Voies de notification. Qui examine une obligation de notification selon l'art. 33 du RGPD, si possible dans les 72 heures suivant la prise de connaissance ? Qui notifie au BSI en cas d'obligation NIS2 ? Qui informe l'assureur ?
7. Remise en état. Où se trouvent les sauvegardes, qui peut les restaurer, combien de temps cela prend-il, quand cela a-t-il été testé pour la dernière fois ?
Exemple : procédure « faille PHP critique »
Voici à quoi peut ressembler une procédure telle qu'elle a été nécessaire pour PHP2Shell :
| Étape | Qui | Résultat |
|---|---|---|
| Évaluer l'avis (php.net, BSI) | Responsables informatiques | systèmes concernés selon l'inventaire |
| Installer la mise à jour, redémarrer tous les workers | Administrateur ou prestataire | Justificatif avec état des paquets et heure des processus |
| Là où aucune mise à jour n'est possible : mesures transitoires ou mise hors réseau | La direction décide | décision documentée |
| Sauvegarder les journaux, rechercher des traces | Administrateur ou forensique | constat ou absence de constat |
| En cas de constat : lancer la procédure d'incident | Direction de crise | examiner les voies de notification |
Important : un correctif ferme la faille, mais ne supprime pas les logiciels malveillants introduits auparavant. La recherche de traces doit donc faire partie intégrante de la procédure.
Fixez combien de temps les journaux du serveur web sont conservés et où ils se trouvent en dehors du serveur. Pour PHP2Shell, la presse spécialisée recommandait de conserver les journaux à partir du 20 octobre 2026. Qui ne garde les journaux que quelques jours ne peut pas appliquer de telles recommandations.
La prévention qui rend le plan efficace
Un plan ne vaut que par ses conditions préalables. Vérifiez que des sauvegardes selon la règle 3-2-1 existent et sont testées, voir Sauvegardes selon la règle 3-2-1. Clarifiez par écrit avec l'hébergeur et l'agence qui prend quoi en charge en cas de failles critiques. Conservez les identifiants d'urgence en lieu sûr mais accessible, par exemple dans un coffre-fort de mots de passe protégé avec accès d'urgence.
Préparez en outre des modèles de texte : information interne, message aux clients, indication sur une page de maintenance statique. Des indications figurent sous Communication de crise après une attaque.
S'exercer et tenir à jour
Un plan qui n'a jamais été exercé comporte presque toujours des lacunes. Jouez une fois par an un scénario, par exemple « faille PHP critique le vendredi après-midi », et notez où cela coince. Un test simple suffit pour commencer : une deuxième personne peut-elle, sans l'aide de la première, joindre l'hébergeur, restaurer une sauvegarde et mettre le site en mode maintenance ? Sinon, il manque quelque chose dans le plan, le plus souvent un accès, un numéro de téléphone ou une description. Ce sont précisément ces lacunes que les exercices doivent rendre visibles avant que la situation devienne sérieuse. Mettez le plan à jour après chaque exercice et chaque changement important. Comme cadre méthodologique, l'IT-Grundschutz du BSI et le standard BSI 200-4 sur la gestion de la continuité d'activité conviennent.
Le plan ne règle pas de façon définitive les questions juridiques, par exemple sur les obligations de notification. Il veille à ce que les bonnes personnes soient associées à temps. Cette page est une information générale et ne constitue pas un conseil juridique.
Comment PHP SOS aide-t-il concrètement ?
- Nous établissons avec vous l'inventaire des systèmes de vos serveurs web, mode d'exécution et version de PHP compris.
- Nous rédigeons les procédures techniques pour les scénarios typiques et les coordonnons avec l'hébergeur et l'agence.
- Nous réalisons un exercice et intégrons les enseignements au plan.
- En cas de crise, nous prenons en charge le volet technique par la réponse à incident, sécurisée sur demande par un contrat de maintenance sécurité.
Questions fréquentes
Quelle doit être l'ampleur d'un plan d'urgence informatique ?
Aussi bref que possible, aussi détaillé que nécessaire. Pour des serveurs web, quelques pages avec les contacts, la liste des systèmes, les règles de décision et les procédures suffisent souvent. Plus important que l'ampleur : qu'il soit à jour et qu'on le retrouve en situation de crise.
Où conserver le plan d'urgence ?
À au moins un endroit accessible même sans informatique fonctionnelle, par exemple imprimé ou sur un appareil séparé. Un plan qui ne se trouve que sur le serveur concerné ou dans le réseau d'entreprise verrouillé n'aide pas en situation de crise.
À quelle fréquence le plan doit-il être vérifié ?
Au moins une fois par an et après chaque changement important, par exemple un changement d'hébergeur ou un nouveau logiciel. Un court exercice, au cours duquel un scénario est joué, est judicieux.
Le BSI propose-t-il des modèles ?
Le BSI (office fédéral allemand de la sécurité des technologies de l'information) traite la gestion des situations d'urgence dans le cadre de l'IT-Grundschutz et dans le standard BSI 200-4 sur la gestion de la continuité d'activité. Ils conviennent comme cadre ; pour des serveurs web, une version concise et proche de la pratique vaut la peine.