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

• Nous pouvons le détecter de manière interne au service
• Des usagers du service peuvent nous contacter en direct ou via le formulaire de contact
• Des tiers peuvent nous contacter ou contribuer via la procédure de contribution

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

Ce mode permet un fonctionnement du site en mode dégradé. Il permet notamment d'afficher une bannière spéciale et personnalisable.

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

En cas d'indisponibilité totale

Nous avons une procédure de service indisponible

Cette procédure permet de définir une page statique qui donne accès aux informations minimales du site. La page statique peut donner des informations importantes, ou laisser des fichiers pdf à disposition si nécessaire.

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 (indisponibilité ou fuite de données) :

• 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)

Listes à trouver ici : https://histologe-metabase.osc-fr1.scalingo.io/dashboard/82-dashboard-listes-mails

A venir : des templates de mail à utiliser en cas d'urgence.

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.