Comment éviter la prise en otage de vos données

Dernièrement, des attaques malicieuses ont été reportées à l’encontre de bases de données MongoDB non-sécurisées et ouvertes sur internet. Les attaquants ont supprimé les données et demandé le paiement d’une rançon pour leur restauration.

Si vous avez des raisons de penser que votre base de données a été attaquée, nous vous suggérons d’appliquer les procédures suivantes (cf Procédure possible pour diagnostiquer et répondre efficacement à une attaque).

Il est possible de prévenir ces attaques par la mise en place des fonctionnalités de sécurité nativement présentes dans MongoDB. Il est important d’utiliser ces fonctionnalités correctement, et notre documentation sur le sujet vous y aidera. Vous trouverez ci-dessous les liens vers la documentation et les ressources adéquates:

  • La sécurité est adressée de manière détaillée dans notre Security Manual. Nous avons également récemment étendu les contenus de notre formation en ligne sur la sécurité, dans le cadre des cours délivrés par la MongoDB University.

  • Suivez les étapes de notre Security Checklist. Cette liste couvre la mise en place de l’authentification, du contrôle des droits d’accès, la limitation de l’exposition du réseau, ainsi que d’autres bonnes pratiques essentielles.

  • Le package d’installation (RPM) de MongoDB le plus répandu limite par défaut l’accès réseau au localhost. Utilisez également cette configuration si vous installez MongoDB par un autre biais.

  • MongoDB Cloud Manager et MongoDB Ops Manager offrent un backup continu et une restauration point in time. Les utilisateurs ont également la possibilité d’activer des alertes

*Figure 1: créer une nouvelle alerte pour notifier si une instance est exposée à l’Internet public.*

* * *
- La dernière version de MongoDB, MongoDB 3.4, vous permet de [configurer l'authentification](https://docs.mongodb.com/manual/release-notes/3.4/#security-enhancement "Configure Authentication") sans interruption de service.
  • Notre service de base de données hébergée MongoDB Atlas fournit nativement plusieurs niveaux de sécurité. Ceux-ci incluent un contrôle d'accès robuste, l'isolation du réseau via les VPC d'Amazon et le VPC Peering, des listes blanches IP, du chiffrement des données en transit TLS/SSL et le chiffrement optionnel at rest du filesystem sous-jacent.

  • Nous encourageons les utilisateurs qui ont fait face à un incident de sécurité avec MongoDB de créer un rapport de vulnérabilité. Si vous souhaitez créer un rapport, ou nous contacter, cliquez-ici.

  • Pour en savoir plus sur les bonnes pratiques de sécurité, consultez notre Livre Blanc Security Architecture.

Étapes à suivre pour diagnostiquer et répondre à une attaque

Comment savoir si une attaque a mis vos données en péril?

  • Si vous avez correctement configuré le contrôle d’accès à votre base de données, les hackers ne devraient pas avoir eu accès à vos données. Consultez notre Security Checklist afin de déterminer d’éventuelles vulnérabilités dans votre configuration.

  • Vérifiez vos bases de données et vos collections. Dans les cas récemment identifiés, le hacker a supprimé les bases de données et/ou collections et les a remplacées par une nouvelle contenant une demande de rançon.

  • Si le contrôle d’accès est activé, faites un audit des logs système sur les tentatives d’accès non autorisés et les activités douteuses.

Si votre instance MongoDB n’était pas sécurisée et à été compromise:

  • Si vous êtes client MongoDB, ouvrez un ticket P1 au plus vite afin que nos ingénieurs puissent vous indiquer la marche à suivre.

  • Votre première priorité devrait consister à sécuriser votre cluster afin d’empêcher tout nouvel accès non autorisé. Suivez les étapes indiquées dans notre Security Checklist.

  • Si vous aviez des utilisateurs existants dans votre système, vérifiez qu’aucun utilisateur n’a été ajouté, supprimé ou modifié via la commande usersInfo.

  • Examinez les logs pour déterminer l’heure exacte de l’attaque. Cherchez les commandes responsables de la suppression des données, de la modification de comptes utilisateurs, ou de création de la demande de rançon.

  • Si vous effectuez des sauvegardes régulières de la base de données concernée, vous pouvez restaurer la plus récente sauvegarde; il vous faudra alors identifier les données susceptibles d’avoir été modifiées entre la dernière sauvegarde et l’heure de l’attaque. Si vous utilisez Ops Manager ou Cloud Manager pour vos sauvegardes, vous pourrez probablement effectuer une restauration point-in-time juste avant l’heure de l’attaque. Vérifiez que vous êtes toujours dans les délais pour une restauration point-in-time (les dernières 24h par défaut). Si tel est le cas, assurez-vous d’effectuer la restauration avant que le délai n’expire. Si vous êtes hors délais, il sera toujours possible de restaurer une sauvegarde récente.

  • Si vous ne disposez pas de sauvegarde ou n’avez pas la possibilité de restaurer les données, il est malheureusement possible que vos données soient perdues de manière définitive.

  • Il faut présumer que le hacker possède une copie de toutes les données de la (les) base(s) de données attaquée(s). Suivez vos procédures de sécurité internes dans le cadre d’une fuite de données.

  • Enfin, référez-vous à nos bonnes pratiques en matière de sécurité et à nos ressources dédiées pour protéger au mieux vos données à l’avenir.


About the Author - Andreas Nilsson

Andreas is the Director of Product Security at MongoDB. Prior to joining MongoDB, Andreas was a Security Architect at NASDAQ OMX responsible for the security architecture of the trading systems. Past employment includes Check Point Software Technologies and Certezza. Andreas holds an MS degree in Computer Security from Columbia University and an MS degree in Engineering Physics from KTH Stockholm.