Chiffrement, sécurisation des données utilisateur et plus encore : nos conseils pour sécuriser gratuitement vos clusters Elasticsearch

Depuis le lancement des versions 6.8 et 7.1 de la Suite Elastic, de nombreuses fonctionnalités de sécurité Elasticsearch sont accessibles à tous : nous avons en effet choisi de les intégrer gratuitement à la distribution par défaut. Nous sommes vraiment ravis de partager cette bonne nouvelle. Reste à mettre à jour notre documentation et nos conseils relatifs à la sécurisation de la Suite Elastic. Car le temps où un serveur proxy suffisait à sécuriser la Suite est bel et bien révolu !

J'ai donc revisité bon nombre de nos anciens articles de blog axés sur la sécurité, et l'objectif est maintenant de mettre à jour nos conseils, de démystifier certaines idées, d'en souligner de nouvelles, et de veiller à ce que vous puissiez sécuriser votre Suite mieux que jamais.

C'est pourquoi vous ne trouverez ici aucun lien vers les anciens articles. Certains d'entre-eux donnent en effet des conseils qui ne sont plus valables aujourd'hui, et que nous considérons même comme dangereux, compte tenu de l'évolution de la Suite Elastic au fil des ans. (Conclusion, méfiez-vous des conseils de sécurité fournis dans les anciens articles de blog : les choses changent très vite.) Nous allons diriger tous ces anciens liens vers cette page. Toutefois, si, sur d'autres sites, vous rencontrez des versions mises en cache de ces articles, nous vous invitons à les diriger vers cette nouvelle page.

Chiffrement TLS

Le chiffrement TLS fait maintenant partie des fonctionnalités de sécurité gratuites d'Elasticsearch et Kibana, que nous avons intégrées à la distribution par défaut. L'objectif est de chiffrer les communications réseau. Nous chiffrons donc les communications entre les nœuds de votre cluster, entre les clients et le cluster, ainsi que les connexions de Kibana aux utilisateurs.

Nous utilisons aussi des certificats TLS, qui nous permettent de contrôler si un nœud est autorisé à rejoindre un cluster. Sans TLS, n'importe qui peut ajouter un nœud à un cluster. Bien que cela puisse être exploité par un attaquant aux intentions malveillantes, dans les faits, il arrive bien plus souvent qu'un nœud rejoigne le mauvais cluster par accident. TLS permet d'éviter ce genre de problèmes, car sans le certificat adéquat, il est impossible que le nœud rejoigne le cluster.

Avant les versions 6.8 et 7.1, si vous aviez une licence Basic et que vous vouliez utiliser le chiffrement TLS avec la Suite Elastic, il fallait s'en remettre à un proxy quelconque, ce qui augmentait considérablement les tâches de configuration. Or, la configuration de TLS est déjà assez difficile en soi, même sans proxy à configurer entre les nœuds et les clients. Ajouter un proxy, c'est compliquer sensiblement un problème déjà difficile. C'est pourquoi nous avons choisi d'intégrer la prise en charge TLS directement dans la Suite Elastic.

Côté configuration, nous vous proposons une documentation conséquente, qui vous explique comment configurer TLS. Si vous avez déjà travaillé avec TLS, vous savez que la configuration des certificats n'est jamais chose aisée. Pour simplifier les choses, nous vous proposons donc des outils intégrés qui vous aident à générer des certificats et des autorités de certification à l'échelle du cluster.  Je vous invite à garder un œil sur ce blog : nous y publierons des articles qui aborderont en détail les bonnes pratiques de configuration TLS pour tous les composants de la Suite Elastic. Mais pour vous lancer sans attendre, le plus simple est de consulter l'article de blog intitulé Prise en main de la sécurité Elasticsearch, ou encore de jeter un œil à notre Kubernetes Operator officiel.

Authentification

Avec les versions 6.8 et 7.1, l'authentification native est accessible à tous. Son objectif est de permettre aux clients de s'identifier pour accéder à la Suite Elastic. Il s'agit souvent du nom d'utilisateur et du mot de passe que vous utilisez pour vous connecter à un système. Mais laisser un cluster plein de données ouvert aux quatre vents n'est généralement pas une bonne idée. C'est d'autant plus dangereux si le cluster est directement connecté à Internet, où n'importe qui peut se connecter sans mot de passe.

Auparavant, on conseillait l'utilisation d'un serveur Nginx et l'activation de la basic auth (authentification de base) entre le client et le cluster. Réussir cette configuration pouvait s'avérer incroyablement difficile. Chaque nœud pouvant servir des requêtes externes, si on oubliait de désactiver un nœud, n'importe qui pouvait se connecter au cluster sans s'authentifier.

Désormais, vous pouvez utiliser gratuitement l'authentification de domaine native et basée sur fichiers (file realms). Le file realm stocke les informations utilisateur dans un fichier présent sur chaque nœud. Vous devez veiller à la bonne synchronisation de ces fichiers sur l'ensemble des nœuds. Le domaine natif est quant à lui plus rationalisé et effectue à peu près ce qu'on attend de lui : les données utilisateur sont stockées dans un index du cluster auquel chaque nœud a accès. Vous ajoutez les noms d'utilisateur et les mots de passe via une API REST, et ces comptes peuvent alors se connecter. Pour en savoir plus, consultez l'article de blog Prise en main de la sécurité Elasticsearch.

Si vous avez besoin d'une méthode d'authentification plus complexe (LDAP, Active Directory, SAML ou autre), nous proposons un service cloud (SaaS) qui intègre directement certaines de ces méthodes, de même que d'autres fonctionnalités commerciales. Vous pouvez aussi nous contacter pour discuter de nos solutions sur site. Pour découvrir les différentes options d'authentification que nous proposons, n'hésitez pas à consulter la documentation consacrée à l'authentification.

Autorisation

L'autorisation et l'authentification sont souvent inséparables. Il en va de même dans la Suite Elastic. Nous avons développé un système extrêmement flexible, capable de définir les règles d'autorisation du cluster et des index, mais aussi de descendre jusqu'au niveau des documents et des champs. Nous avons même mis au point ce que nous appelons un moteur d'autorisation, qui vous permet de développer votre propre plug-in d'autorisation.

Donner des conseils dans ce domaine n'a jamais été chose aisée. On a pu suggérer par le passé d'utiliser un proxy comme Nginx et d'écrire des règles de filtrage assez complexes, puis de tenter d'exploiter les alias filtrés pour parvenir à quelque chose qui se rapproche d'une autorisation. Nous déconseillons vivement l'utilisation de ces méthodes d'autorisation. Il ne s'agit pas de fonctionnalités de sécurité, elles risquent de ne pas produire l'effet escompté et sont incroyablement difficiles à maintenir. Ces solutions ne donneront plus les résultats attendus, car au fil du temps, le nombre d'API Elasticsearch a explosé. Les moyens d'accéder aux index et aux données qu'ils contiennent pour les interroger sont nombreux. Mais il n'existe aucun moyen de garantir que vous avez réussi à bloquer chaque requête ou à en limiter l'accès. La deuxième raison découle de la première : le nombre de points de terminaison à protéger est énorme et il ne cesse de croître. Veiller à ce que ces filtres restent à jour représenterait un travail colossal.

Mais tout cela est de l'histoire ancienne. Les versions 6.8 et 7.1 vous donnent maintenant accès à une multitude de fonctionnalités d'autorisation. Elles sont trop nombreuses pour être présentées dans cet article, mais la documentation consacrée à la sécurité de la Suite Elastic explique à merveille l'ensemble des privilèges existants. Dans de prochains articles de blog, nous examinerons de près certaines des solutions que vous pouvez mettre en place grâce à notre modèle d'autorisation.

Comme pour l'authentification, nous proposons des fonctionnalités d'autorisation encore plus avancées, qui peuvent être appliquées à des documents ou à des champs individuels. Vous avez la possibilité de développer vos propres plug-ins d'authentification et d'autorisation, et même logger les événements de sécurité sur le cluster. Vous pouvez accéder à ces fonctionnalités via notre service cloud ou nous contacter pour discuter des possibilités de déploiement sur site.

Placer la Suite derrière un VPN et/ou un pare-feu

Nous avons longtemps suggéré de placer la Suite Elastic derrière un VPN ou un pare-feu. Dans bien des cas, l'idée était que sans TLS ni authentification, il pouvait être difficile de protéger un cluster au moyen d'un unique proxy, et qu'il était donc plus simple de bloquer l'accès à tout le monde, plutôt que de configurer correctement chaque élément.

Mais même armé de TLS et de l'authentification, certains préfèrent ne pas se séparer de leur pare-feu ou de leur VPN, et on ne peut qu'approuver. La meilleure sécurité est une sécurité multicouches. Et il se trouve qu'aujourd'hui, le VPN et le pare-feu ne sont plus l'unique couche.

Scripts limités

Il y a longtemps, nous avions publié un article de blog au sujet de la limitation des scripts dans Elasticsearch. Mais avec le langage de script Painless, il est devenu beaucoup plus difficile d'arrêter un cluster, même avec des scripts malveillants. Cela n'est cependant pas impossible. C'est pourquoi nous partageons nos bonnes pratiques et nos réflexions à ce sujet dans notre documentation consacrée à la sécurité des scripts. Toutefois, en matière de sécurité, nous vous recommandons toujours d'étudier votre environnement et de prendre les mesures les plus adaptées à votre situation. La sécurité est plus efficace quand on dispose de plusieurs couches. Il n'existe donc pas une seule, mais plusieurs "meilleures solutions".

Isolation

Nous avons plus d'une fois abordé l'isolation des nœuds et des clusters pour des raisons de sécurité. Conteneurs, pare-feu, filtrage IP... Les solutions sont multiples.

Ce conseil est toujours d'actualité et toujours aussi judicieux : isolez tout ce que vous pouvez isoler. Ces dernières années, nous avons beaucoup œuvré à vous faciliter la tâche. L'isolation est désormais plus simple que jamais. Vous pouvez utiliser nos images deconteneur officielles, publiées sur le hub Docker. Vous pouvez aussi capitaliser surElasticsearch Service, et nous vous déchargeons des tâches les plus complexes. Et nous venons d'annoncer notre Kubernetes Operator officiel, que vous pouvez d'ores et déjà essayer.

Sauvegardez vos index (notamment .kibana, qui est facilement modifiable)

Sauvegarder ses données est toujours aussi essentiel. Aucune solution de sécurité ne vous dispense de sauvegardes, même si nos fonctionnalités Security sont toujours plus performantes.

Le plus grand avantage ? Nous pouvons maintenant utiliser Kibana Spaces pour limiter l'accès en écriture à certains tableaux de bord. Encore une fonctionnalité disponible gratuitement dans les versions 6.8 et 7.1. Jusque-là, quiconque avait accès à Kibana pouvait y modifier ce qu'il voulait. Il n'était donc pas rare qu'un utilisateur modifie des tableaux de bord par erreur, voire, dans certains cas, qu'il les supprime tous accidentellement. Nous conseillions donc de sauvegarder l'index .kibana régulièrement pour pouvoir le récupérer rapidement en cas d'erreur. Il est bien plus rapide de restaurer un index que de recréer tous vos tableaux de bord. Il est donc toujours important de sauvegarder votre index .kibana, mais grâce à Spaces et aux autorisations, vous n'aurez normalement plus à le restaurer régulièrement.

Autre grand avantage de Security : la possibilité de contrôler les utilisateurs autorisés à effectuer des instantanés, créer des index et modifier les données. Sans Security, un utilisateur autorisé en lecture seule peut potentiellement apporter des modifications désastreuses aux données. Avec Security, vous pouvez prendre des mesures pour éviter les modifications non intentionnelles des données importantes.

Pour terminer

L'objectif de cet article de blog était de réexaminer certains des conseils que nous vous donnions il y a quelque temps sur la sécurisation de vos déploiements de la Suite Elastic. Dans le monde de la sécurité, la seule constante est le changement. Les conseils partagés dans cet article seront eux aussi dépassés un jour. Dans la Suite Elastic, la sécurité offre tant de possibilités qu'elle peut en devenir intimidante. (C'est une fonctionnalité, pas un bug.) N'hésitez surtout pas à poser des questions sur les forums, ni à lire nos articles de blog et notre documentation.

Sécuriser la Suite Elastic via un simple bouton ? C'est aussi possible. Dans notre offre Elasticsearch Service TLS est préconfiguré pour tous les clusters, l'authentification et les autorisations sont activées, ainsi que nos fonctionnalités de sécurité Enterprise, elles aussi activées par défaut. Et si vous n'êtes pas très cloud, bon nombre de ces fonctionnalités sont aussi disponibles via notre offre Elasticsearch Service hébergée dans votre propre data center grâce Elastic Cloud Enterprise (ECE). Notre Kubernetes Operator peut aussi se charger de tâches complexes, comme l'activation TLS et la configuration par défaut de l'authentification. Et bien sûr, si vous avez opté pour un abonnement Enterprise et que vous exécutez la Suite Elastic, notre équipe de support technique est là pour vous aider à résoudre tous les problèmes. Et elle est épatante.

Restez connecté pour ne rien manquer des nouveautés. Une multitude de conseils pratiques sont dans le pipeline, mais aussi de nouvelles fonctionnalités de sécurité. Utiliser la Suite Elastic n'a jamais été aussi passionnant.