Comment protéger ses données sensibles ? (2/2)

Partie 2 : une sphère en perpétuel progrès

Un site web ne peut plus être défini aujourd’hui comme la mise en place d’un unique moyen de mise à disposition du contenu (pages HTML, CMS, framework, etc), du moins au niveau professionnel. Le milieu s’est complexifié avec les années et avec lui les outils et la complexité des vulnérabilités de sécurité. Dès lors de nombreuses failles peuvent exister autour d’un CMS comme Drupal, dans les services qui le porte, tels apache ou nginx, mais aussi dans les services annexes (solR, elastic search, memcached, redis, et autres) ou dans les bibliothèques de code qui viennent compléter le besoin fonctionnel et technique de l’application. Dès lors, il est primordial de maîtriser tout le périmètre des configurations, de mise à jour et de monitoring de tous ces éléments.

4. Mauvaises configurations de sécurité

Bien des erreurs se produisent uniquement du fait d’une inattention lors de l’implémentation ou d’un manque de temps qui emmène au déploiement d’outils avec des configurations de sécurité par défaut ou des habitudes de développement catastrophiques en termes de vulnérabilité.

Nous l’avons déjà exprimé, il est impératif de masquer les erreurs aux utilisateurs non autorisés et impératif de les journaliser avec un délai de rétention raisonnable pour rester dans le cadre de la légalité (par exemple un an pour la RGPD).

La désactivation de protocoles de sécurité vulnérables doit être vérifiée et effective : SSL ou les anciennes versions de TLS. Ce sont des éléments critiques à maintenir à jour en permanence dans les écosystèmes qui hébergent un projet web.

La présence de snapshots de base de données, de backups divers ou de tout autre type de dump dans un dossier accessible publiquement est à vérifier et proscrire à tout prix.

Les mots de passe par défaut des différents services utilisés (en particulier la base de données) devraient toujours être modifiés et ne pas utiliser de mots de passe non sécurisés.

L’accès aux environnements doit être sécurisé autant que possible (utilisation de SSH avec une clé, firewall pour filtrage des IPs, mise en place de bastions, etc).

5. Usage de composants à vulnérabilités connues

D’une façon générale il faut considérer un site web comme un organisme vivant qui évolue dans le temps. Les services et composants qui le constitue évoluent, se renforcent, les failles de sécurité sont corrigées.

Il est donc essentiel de toujours être à jour sur l’ensemble des services utilisés (PHP, MySQL) et pour Drupal sur l’ensemble des éléments qui le constitue (le core, les modules contrib, les librairies tierces embarquées, etc)

Dans le cas de Drupal 8 pour lequel l’usage de composer est devenu une bonne pratique, l’exécution de composer update permet de mettre à jour rapidement l’ensemble des composants avec leurs dernières versions. Attention, il est important de contrôler la bonne montée de version et la compatibilité des différents éléments entre eux. Un pipeline CI/CD (Continuous Integration / Continuous Deployment) est fortement recommandé pour tester automatiquement l’ensemble des modifications apportées lors d’une mise à jour.

Drupal émet des annonces de sécurité tous les mercredi soir, un développeur Drupal devrait souscrire aux notifications de sécurité pour être informé de ces mises à jour.

Pour compléter l’usage de composer les deux outils suivants permettent de s’assurer de ne pas embarquer de composant déjà vulnérable au moment de les ajouter :

https://github.com/drupal-composer/drupal-security-advisories

https://github.com/Roave/SecurityAdvisories

6. Journalisation insuffisante

La journalisation est un point clé de la détection des tentatives d’actions malicieuses sur un site et doit être considéré avec sérieux.

Comme exprimé plus haut le code implémenté doit toujours utiliser des errors handlers et lever des exceptions autant que possible. Il est également important que toutes les erreurs qui n’ont pas été traitées soient récupérées et traitées en fin de pile. Drupal récupère déjà un grand nombre d’erreurs nativement mais il est important de toujours s’assurer qu’un module ne brise pas la récupération de ces erreurs et provoque une exposition de données sensibles.

Le journal doit, autant que possible, être écrit dans un fichier ou envoyé à un outil dédié (comme un ELK). L’écriture de ce fichier doit toujours être fait selon un mode d’ajout progressif pour ne pas permettre la réécriture du fichier mais uniquement l’insertion de nouveaux éléments. Enfin le fichier doit régulièrement faire l’objet d’une rotation pour stocker les journaux les plus anciens dans un espace de stockage à part.

Le système de journalisation doit idéalement journaliser les tentatives de connexion SSH, les changements d’IP ou toute autre activité potentiellement suspecte.

Enfin, un système de monitoring doit être déployé pour permettre de suivre les tendances de trafic et les pics inhabituels d’activité des serveurs.

Conclusion

La sécurité est un domaine en perpétuelle évolution. Les vulnérabilités de demain dépendent entièrement de l’état actuel de nos technologies, c’est pourquoi il faut être attentif à tous les détails depuis la mise en place de l’infrastructure jusqu’au choix d’implémentation de code et aux versions de modules et autres composants. Un projet web devrait toujours dédier une part de son budget au cadrage de ces aspects comme un développement continu au même titre que le test fonctionnel ou unitaire. C’est un projet dans le projet qui a des impacts dans l’architecture profonde de l’application et peut causer des préjudices aussi importants que difficiles à détecter.