Durcissement de la sécurité Elasticsearch (security, TLS, rôles, audit)
ElasticsearchNiveau: AvancéDurée: 10 min (audit) – 2 heures (durcissement complet)Ni une installation ni l'exploitation courante : un runbook par scénarios pour durcir un cluster Elasticsearch en service. Audit de sécurité en lecture seule, activation de la sécurité désactivée avec le TLS transport (redémarrage complet du cluster), migration rolling vers le TLS HTTP, rôles DBA/application, API key avec expiration, utilisateur d'urgence du file realm, retrait d'elastic de l'usage quotidien, désactivation de l'accès anonyme, network.host et filtrage IP, audit logging (avec contrôle de licence), accès au dépôt de snapshots et token de service account Kibana ; à la fin, l'audit est relancé pour montrer que les risques sont fermés. Sur les installations RPM/DEB 8.x/9.x, la sécurité et le TLS sont déjà activés : commencez par l'audit et n'appliquez que les scénarios qui remontent RISK ou WARNING. Les tâches shard, disque et node sont dans le guide d'exploitation, les sauvegardes dans le guide snapshot.
Topologie: Cluster Elasticsearch de 1 à 12 nodes (+ Kibana)
Scénarios
- Audit de l'état de sécurité (lecture seule) — Ne modifie rien. Sécurité activée ou non, accès sans authentification, TLS HTTP/transport, accès anonyme, utilisateurs et usage d'elastic, API keys sans expiration, audit logging, filtrage IP, adresses d'écoute et état de la licence sont rapportés en OK / WARNING / RISK. Choisissez cette option si vous ne savez pas par où commencer.
- Durcissement complet (tout, dans l'ordre) — Audit → security + TLS transport/HTTP (si désactivée ; redémarrage complet du cluster) → utilisateurs/rôles/API keys, désactivation de l'accès anonyme, retrait d'elastic de l'usage quotidien → réseau et filtrage IP → audit logging (si la licence le permet) → accès au dépôt de snapshots → connexion Kibana → audit final.
- Sécurité désactivée : activer la sécurité et le TLS transport — Cluster avec xpack.security.enabled: false, ou mis à niveau depuis la 7.x, accessible sans authentification. Les certificats sont générés et la sécurité est activée avec le TLS transport (et en option HTTP). Un redémarrage complet du cluster est nécessaire (interruption) : des connexions avec et sans TLS entre nodes ne peuvent pas coexister.
- Passer le trafic HTTP (REST) en TLS — La sécurité est activée mais le port 9200 est en HTTP simple : les mots de passe sont lisibles sur le réseau. Les certificats HTTP sont distribués et les nodes redémarrés un par un ; les clients passent en https://.
- Utilisateurs, rôles, API key ; accès elastic et anonyme — Les applications se connectent avec le superutilisateur elastic, l'accès anonyme est activé ou il existe des API keys sans expiration. Rôles/utilisateurs distincts pour les DBA et les applications, API key avec expiration pour l'application, utilisateur d'urgence (file realm) ; le mot de passe d'elastic est changé et elastic est retiré de l'usage quotidien.
- Activer l'audit logging — Qui a accédé à quel index, les tentatives de connexion échouées, les refus d'autorisation et les modifications des paramètres de sécurité doivent être enregistrés. xpack.security.audit.enabled (statique, redémarrage rolling) — nécessite une licence (l'étape vérifie la licence).
- Accès réseau et filtrage IP — 9200/9300 écoutent sur toutes les interfaces ou sont ouverts à tous. network.host est restreint à l'IP interne ; avec le firewall et le filtrage IP d'Elasticsearch, seuls les nodes, Kibana et le réseau applicatif sont autorisés.
- Sécuriser l'accès au dépôt de snapshots — Le répertoire des snapshots est lisible par tous, le privilège de gestion du dépôt est trop large, ou les clés d'accès cloud sont dans elasticsearch.yml. Permissions du répertoire, rôle d'opérateur snapshot, keystore et enregistrement du dépôt en lecture seule sur le second cluster.
- Sécuriser la connexion Kibana — Kibana se connecte avec l'utilisateur elastic ou sans chiffrement, et le mot de passe est en clair dans kibana.yml. Token de service account, vérification de la CA, keystore et clés de chiffrement.
Avant de commencer
- root/sudo sur tous les nodes ; SSH du premier node vers les autres (distribution des certificats).
- Le cluster est green ; les opérations rolling ne se font pas sur un cluster en mauvaise santé.
- python3 (analyse JSON), openssl et unzip sont installés.
- Activer la sécurité (TLS transport) exige un redémarrage complet du cluster : fenêtre de maintenance et snapshot pris au préalable.
- Inventaire des clients (Kibana, Logstash, Beats, applications) : une fois le TLS HTTP et l'authentification activés, chacun doit être mis à jour avec https + CA + utilisateur/API key.
- L'audit logging et le filtrage IP sont des fonctionnalités de licence payante (Gold et au-delà : Gold, Platinum, Enterprise ou essai de 30 jours ; pour les nouveaux abonnements self-managed, Platinum/Enterprise). Aucun des deux ne fonctionne avec une licence Basic : le paramètre est accepté, mais aucun enregistrement d'audit n'est produit et le filtre IP ne bloque aucune connexion. Licence : GET _license.
Phases du guide
- Préparation : filet de sécurité et outils d'aide — Sauvegarde de la configuration, du keystore et des certificats : … · Prendre un snapshot (recommandé) · PyYAML et outils : … · Permissions des fichiers de configuration : … · Écrire les identifiants d'administration dans le fichier netrc
- Audit de l'état (lecture seule) — Rapport de sécurité : … · Associer les constats aux scénarios
- Activer la sécurité : diagnostic et certificats — Diagnostic : la sécurité est-elle vraiment désactivée ? · Générer la CA et les certificats des nodes · Distribuer les certificats aux nodes · Permissions des certificats : … · elasticsearch.yml : paramètres security et TLS : … · Arrêter l'allocation des shards et faire un flush
- Activer la sécurité : redémarrage complet du cluster — Arrêter : … · Démarrer : … · Définir le mot de passe d'elastic · Écrire les identifiants d'administration dans le fichier netrc (elastic) · Réactiver l'allocation des shards et attendre la santé du cluster · Mot de passe de kibana_system …
- TLS HTTP : certificats — État actuel · Générer les certificats HTTP · Distribuer et fixer les permissions : …
- Utilisateurs, rôles et API key — Utilisateurs, rôles et API keys existants · Utilisateur d'administration DBA (…) · Utilisateur d'urgence (file realm) : … · Rôle et utilisateur applicatifs (…) · API key avec expiration pour l'application · Vérifier le moindre privilège (…) …
- Accès réseau et filtrage IP — Firewall : … · network.host est-il sur l'IP interne : … · Filtrage IP Elasticsearch
- Audit logging : licence et paramètres — La licence permet-elle l'audit logging ?
- Audit logging : sélection des événements et vérification — Quels événements enregistrer · Des enregistrements d'audit sont-ils produits : …
- Accès au dépôt de snapshots — Permissions du répertoire des snapshots : … · Liste des dépôts, clés cloud et rôle d'opérateur snapshot
- Connexion Kibana — Token de service account Kibana · kibana.yml et keystore · Vérifier la connexion Kibana
- Audit final (après durcissement) — Rapport de sécurité : … (état final)
- Nettoyage et suite — Supprimer les fichiers d'identifiants temporaires : … · Suite