Gestion des incidents de sécurité - MTES-MCT/histologe GitHub Wiki

Gestion technique

Ce document a pour objectif de résumer les actions à prendre en cas d'incident de sécurité.

Préparation

  • Des sauvegardes sont faites quotidiennement par notre prestataire.
  • Des sauvegardes internes sont faites une fois par semaine. Voir Sauvegardes internes
  • Des exercices sont faits régulièrement pour remettre en l'état une sauvegarde passée de la base de données.
  • L'équipe technique s'engage à ce qu'il y ait toujours 2 des 4 développeurs disponibles durant les jours ouvrés en cas d'incident.

Détection

Les problèmes de sécurités peuvent être détectés de plusieurs manières.

Détection technique

  • Le tunnel d'intégration continue est exécuté chaque jour
  • Les vulnérabilités des dépendances Symfony sont vérifiées à chaque exécution du tunnel d'intégration continue
  • GitHub fait une veille automatique des vulnérabilités dans les versions de composants utilisés (JS, PHP)
  • Scalingo nous envoie des alertes déclenchées selon l'utilisation du processeur, de la RAM ou du nombre d'erreurs 5XX.
  • Sentry nous signale l'ensemble des erreurs d'exécution de code

Détection humaine

Réaction

Sauvegarde base de données

Si l'environnement est accessible :

  • récupérer le dernier backup en date,
  • en créer un autre en temps réel.

Passer le mode maintenance

Afin d'éviter toute perte de données, si nécessaire, éditer les variables d'environnement suivantes :

  • MAINTENANCE_ENABLE
  • MAINTENANCE_BANNER_ENABLE
  • MAINTENANCE_BANNER_MESSAGE

Analyse

  • Utiliser Sentry pour suivre, analyser et corriger les performances de l'application
  • Utiliser Scalingo pour accéder aux logs applicatifs et de base de données
  • Croiser les dates de problèmes avec d'éventuels ajouts dans la base de données
  • A venir : vérifier les événements historisés de modification en base de données

Correction

Selon besoin :

  • Réaliser un hotfix
  • Rétablir la dernière version acceptable de la base de données
  • Mettre à jour des composants

Puis faire une veille spécifique à la résolution de l'incident (reproduction, alertes, ...)

Communication externe

Selon besoin :

  • Communication spécifique aux Responsables territoires
  • Communication à l'ensemble des personnes qui possèdent un compte sur la plateforme
  • Communication à l'ensemble des utilisateurs du site (usagers compris)

Post-mortem

Prendre le temps de faire un rapport d'incident en prenant le modèle de Beta. Stocker le rapport dans la partie /docs du repository Git.