Durcissement de la sécurité MongoDB (autorisation, TLS, rôles, audit)

Runbook par scénarios pour durcir sans interruption un MongoDB en service (serveur standalone, replica set ou sharded cluster) : audit de sécurité en lecture seule, activation rolling de l'autorisation avec keyFile + transitionToAuth, custom roles et utilisateurs au moindre privilège, SCRAM-SHA-256, bindIp et firewall, passage allowTLS → preferTLS → requireTLS, authentification des membres par x.509, audit log (Enterprise/Percona) et encryption at rest ; à la fin, l'audit est relancé pour montrer que les risques sont fermés. Sur les systèmes installés avec les guides d'installation de ce site, l'autorisation et le keyfile sont déjà activés : commencez par l'audit et n'appliquez que les scénarios qui remontent un RISQUE. L'exploitation courante et la sauvegarde sont traitées dans des guides MongoDB distincts.

Topologie: Serveur standalone, replica set de 3 membres ou plus, ou sharded cluster

Scénarios

• Audit de l'état de sécurité (lecture seule) — Ne modifie rien. L'accès sans authentification, les adresses d'écoute, TLS, les mécanismes d'authentification, les utilisateurs à privilèges élevés, l'audit et l'encryption at rest sont rapportés en OK / ALERTE / RISQUE. Choisissez ce scénario si vous ne savez pas par où commencer.
• Durcissement complet (tout, dans l'ordre) — Audit → authentification interne + autorisation (sans interruption grâce à transitionToAuth) → utilisateurs au moindre privilège → SCRAM-SHA-256 → bindIp/firewall → TLS (allowTLS → preferTLS → requireTLS) → audit (Enterprise/Percona) → audit final. En rolling dans un replica set ; chaque étape à risque demande une confirmation.
• Autorisation désactivée : activer l'autorisation (keyFile, sans interruption) — Tout le monde peut se connecter sans nom d'utilisateur ni mot de passe. Dans un replica set et un sharded cluster, l'autorisation est activée en rolling et sans interruption avec keyFile + transitionToAuth ; un serveur standalone nécessite un court redémarrage.
• Utilisateurs au moindre privilège et custom roles (application, sauvegarde, supervision) — Les applications se connectent avec root ou un compte d'administration partagé. On crée un custom role qui n'accorde à l'application que les opérations dont elle a besoin dans sa propre base, ainsi que des utilisateurs distincts pour la sauvegarde et la supervision ; le stockage sécurisé des mots de passe côté cron/application est montré.
• Désactiver SCRAM-SHA-1, uniquement SCRAM-SHA-256 — Les identifiants des anciens utilisateurs sont stockés en SHA-1, ou l'audit a trouvé SCRAM-SHA-1 activé. Les utilisateurs sont migrés vers SHA-256, puis authenticationMechanisms est restreint avec un redémarrage rolling.
• Restreindre l'accès réseau (bindIp 0.0.0.0, firewall) — mongod écoute sur toutes les interfaces (0.0.0.0, bindIpAll) ou le port est ouvert à tous. bindIp est réduit à localhost + l'IP interne du serveur, et le firewall n'autorise que les membres et le réseau applicatif. En rolling, sans interruption.
• Chiffrer les connexions : TLS (allowTLS → preferTLS → requireTLS) — Le trafic entre l'application et les membres, et entre les membres, n'est pas chiffré. Les certificats sont distribués, les membres passent d'abord en allowTLS par un redémarrage rolling, puis en preferTLS à chaud, et en requireTLS une fois les applications prêtes. En option : authentification x.509 entre membres.
• Activer l'audit log (Enterprise / Percona) — Qui s'est connecté et quand, les modifications d'utilisateurs/rôles et les opérations drop doivent être tracés. Dans MongoDB Enterprise et Percona Server for MongoDB, cela s'active avec auditLog ; Community ne dispose pas de cette fonctionnalité (une alternative est présentée).
• Encryption at rest (chiffrer les données sur disque) — Si un disque ou une sauvegarde est volé, les données doivent rester illisibles. Sur Enterprise/Percona, le chiffrement WiredTiger s'active en reconstruisant les membres un par un par initial sync ; sur Community, le disque de données est chiffré avec LUKS.

Avant de commencer

• Accès root/sudo sur tous les serveurs mongod… et mongos… ; SSH du premier serveur vers les autres (pour copier le keyfile et les certificats).
• …Le replica set est sain : tous les membres PRIMARY/SECONDARY, lag faible. Aucune opération rolling sur un cluster en mauvaise santé.…mongod est en service.…
• Liste des applications et de leurs responsables : la chaîne de connexion de chaque application sera mise à jour avant que l'autorisation/TLS ne deviennent obligatoires. La chaîne de connexion doit contenir tous les membres et replicaSet= (pour ne pas décrocher pendant les redémarrages rolling).
• Fenêtre de maintenance : les opérations rolling ne provoquent pas d'interruption, mais chaque changement de primary fait attendre les écritures quelques secondes. Sur un serveur standalone, l'activation de l'autorisation/TLS nécessite une courte interruption.
• Si l'autorisation est déjà activée dans un sharded cluster : le primary de chaque shard doit avoir un utilisateur local au shard (root) avec le même nom et le même mot de passe que … sur mongos. Les étapes par membre (rs.stepDown lors du redémarrage rolling, setParameter, audit) se connectent directement aux membres du shard ; les utilisateurs mongos n'y sont pas valides. Contrôle : sur un membre du shard, mongosh --port <port du shard> puis db.getSiblingDB("admin").auth("…", passwordPrompt()).
• Une sauvegarde complète récente dont la restauration a été testée.
• Une licence MongoDB Enterprise ou Percona Server for MongoDB pour l'audit et l'encryption at rest. Community ne dispose pas de ces fonctionnalités.
• Les noms des membres sont résolus sur chaque serveur (DNS ou /etc/hosts) ; en TLS, les connexions utilisent ces noms.

Phases du guide

• Préparation : filet de sécurité et outils d'aide — Sauvegarde de la configuration et de l'état · Installer PyYAML · Écrire l'outil d'édition YAML (dbatlas-yaml) · Écrire l'outil de redémarrage rolling (dbatlas-mongod-restart) · Écrire le mot de passe d'administration dans un fichier temporaire
• Audit de l'état (lecture seule) — Réseau, processus et droits des fichiers : … · Réseau et processus : … · Autorisation, TLS et paramètres : … · Autorisation, TLS et paramètres : … · Utilisateurs, rôles et mécanismes d'authentification · Associer les constats aux scénarios
• Autorisation : diagnostic et keyfile — Diagnostic : l'autorisation est-elle vraiment désactivée ? · Recenser les connexions applicatives · Créer le keyfile · Copier le keyfile sur les autres serveurs · Droits du keyfile : … · Droits du keyfile : …
• Autorisation : utilisateur d'administration — Créer l'utilisateur d'administration (…) · Administrateur local au shard : …
• Utilisateurs au moindre privilège et custom roles — Créer un custom role pour l'application (…@…) · Créer l'utilisateur applicatif (…) · Utilisateurs de sauvegarde et de supervision · Vérifier le moindre privilège (…) · Stocker les mots de passe de façon sécurisée côté application et cron
• Autorisation : vérifier qu'il ne reste aucune connexion non authentifiée — Connexions client non authentifiées : …
• Appliquer l'autorisation (serveur standalone) — authorization: enabled · Redémarrer le service en sécurité (…)
• Autorisation : vérification — L'accès non authentifié est-il refusé ? · Vérifier le moindre privilège (…) · Retour arrière (si nécessaire)
• SCRAM-SHA-256 : migrer les utilisateurs — Utilisateurs avec des identifiants SHA-1 · Réduire les utilisateurs à SCRAM-SHA-256 seul
• SCRAM-SHA-256 : vérification — La connexion avec SHA-1 est-elle refusée ?
• Accès réseau : firewall — Règles de firewall
• Accès réseau : vérification — Adresses d'écoute : …
• TLS : certificats — État TLS actuel · Générer la CA interne et les certificats serveur · Distribuer les certificats · Droits et vérification des certificats : … · Droits des certificats : …
• TLS : basculer les applications — Passer les applications en TLS et compter les connexions TLS
• TLS : vérification — Les connexions sans TLS sont-elles refusées : …
• Audit log : contrôle préalable — Ce mongod prend-il en charge l'audit : …
• Audit log : vérification et rotation — Les enregistrements d'audit sont-ils écrits : … · Alternative Community : surveiller les logs d'authentification
• Encryption at rest : contrôle préalable et sauvegarde — Prise en charge du chiffrement et espace disque : … · Une sauvegarde complète a-t-elle été effectuée ?
• Encryption at rest : marqueur de test — Écrire un marqueur en clair
• Encryption at rest (Community) : disque de données avec LUKS — Préparer le disque LUKS : … · Déplacer les données sur le disque chiffré : …
• Audit final (après durcissement) — Réseau, processus et droits des fichiers : … (état final) · Réseau et processus : … (état final) · Autorisation, TLS et paramètres : … (état final) · Autorisation, TLS et paramètres : … (état final) · Utilisateurs, rôles et mécanismes d'authentification (état final)
• Nettoyage et suite — Supprimer le fichier de mot de passe temporaire · Suite : supervision et tâches périodiques