Communication sécurisé Elasticsearch

Des communications sécurisées au sein d’un groupe de recherche Elasticsearch

Introduction

Un élément clé de toute architecture sécurisée est la capacité de chiffrer les communications entre les applications. Dans le cas de l’Elastic Stack, cela signifie que chaque nœud doit pouvoir communiquer avec les autres de manière sécurisée ainsi qu’avec tous les clients tels que Logstash, Beats, Kibana et vos propres applications clientes.

Une autre fonction consiste à limiter l’accès aux seuls acteurs autorisés à communiquer. Vous voulez éviter les attaques des “intermédiaires”, qui permettent à quelqu’un de “rejoindre le groupe” ou même de communiquer avec le groupe alors qu’il ne devrait pas le faire. Les fonctions de sécurité de l’Elastic Stack prennent en charge cette fonction grâce à la sécurité de la couche transport (TLS).

Certificats de nœuds générateurs

La sécurité d’Elasticsearch utilise la sécurité de la couche transport (TLS) pour effectuer le cryptage des messages et l’authentification des différents nœuds. Ce protocole nécessite des certificats X.509 qui doivent être signés par une autorité de certification (CA) de confiance.

Selon le niveau de validation des certificats, il existe différents scénarios lorsqu’un nouveau nœud souhaite rejoindre le cluster :

  • certificats : Lorsque des nœuds sont ajoutés à votre grappe, il leur suffit d’utiliser un certificat signé par la même autorité de certification et le nœud est automatiquement autorisé à rejoindre la grappe. Comme le nœud imposteur n’a pas de certificat signé, s’il essaie de rejoindre le cluster, il sera rejeté.
  • full verification : Lorsque des nœuds tentent de rejoindre le cluster, une vérification complète du certificat est effectuée. Les nœuds vérifieront que le certificat a été signé par la même AC et que le nom d’hôte (ou l’adresse IP) du serveur correspond aux noms identifiés dans le certificat.
  • no verification : Il n’y a pas de vérification des certificats des nœuds, ce qui permet à n’importe quel nœud de rejoindre la grappe. Ce n’est pas quelque chose que vous utiliserez en production, mais il peut être utile pour un diagnostic temporaire.

Vous pouvez utiliser votre propre AC pour générer et signer des certificats, ou vous pouvez utiliser un outil appelé elasticsearch-certutil, qui se charge de générer une AC et de signer des certificats avec celle-ci. Vous pouvez générer un certificat en deux étapes simples :

  1. Créez une autorité de certification pour votre cluster Elasticsearch :
bin/elasticsearch-certutil ca
  1. Générez un certificat et une clé privée pour chaque nœud de votre grappe en utilisant votre AC :
bin/elasticsearch-certutil cert --ca /path/to/your/ca

Cela générera un magasin de clés PKCS#12 qui contient le certificat du nœud, la clé du nœud et le certificat de l’AC. Vous pouvez éventuellement utiliser l’adresse IP (utiliser –ip) ou le nom de domaine (utiliser –dns) si vous souhaitez effectuer une vérification complète du certificat, qui vérifie que le certificat fourni est signé par une autorité de confiance (CA) et vérifie également que le nom d’hôte du serveur (ou l’adresse IP) correspond aux noms identifiés dans le certificat.

  1. Sécuriser la communication entre les nœuds

Maintenant que tous vos nœuds ont leur propre certificat PKCS#12, regardez la vidéo suivante pour voir comment vous pouvez l’utiliser pour crypter les communications entre les nœuds.

Pour activer et configurer TLS, ajoutez les paramètres suivants au fichier de configuration elasticsearch.yml de chaque nœud :

xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate 
xpack.security.transport.ssl.keystore.path: certs/elastic-certificates.p12 
xpack.security.transport.ssl.truststore.path: certs/elastic-certificates.p12

Vous devrez fournir le chemin d’accès à la clé et au certificat du nœud concerné. Le fichier PKCS#12 est un keystore qui contient les deux. Si vous avez créé le certificat du nœud avec une adresse IP, vous pouvez définir le mode de vérification sur plein.

Une fois que vous avez mis à jour le fichier de configuration de chaque nœud, effectuez un redémarrage complet du cluster et les nœuds devraient communiquer en toute sécurité !

Filtrage IP

La dernière chose que vous apprendrez dans cette leçon est le filtrage de la propriété intellectuelle. Le filtrage IP vous permet de mettre sur liste blanche certaines adresses IP afin qu’une personne qui n’a pas été enregistrée ou mise sur liste blanche en tant qu’adresse IP reconnue ne puisse pas accéder à votre groupe. Par exemple, vous pouvez mettre sur liste blanche les logiciels de vos clients qui communiquent avec votre groupe de recherche Elasticsearch, qu’il s’agisse de Kibana, de Logstash ou de vos propres applications utilisant un client linguistique. Utilisez le filtrage IP pour ajouter une autre couche de sécurité.

Le filtrage IP est une bonne pratique et devrait toujours être en place. Il existe différentes façons d’y parvenir (par exemple, les règles de pare-feu), et la sécurité d’Elasticsearch est l’une d’entre elles. À la différence de toutes les autres fonctionnalités abordées dans cette formation, le filtrage IP fait partie de l’abonnement Gold/Platinum qui contient d’autres fonctionnalités de sécurité avancées, telles que la journalisation des audits et l’authentification LDAP. Ces fonctions de sécurité avancées sont couvertes dans notre cours “Techniques avancées de sécurisation de la recherche Elasticsearch”, qui sera bientôt disponible.

Il y a deux façons de configurer le filtrage IP dans Elasticsearch :

  1. Mettre à jour les paramètres dans le fichier elasticsearch.yml en définissant des règles pour le transport et les protocoles HTTP.
xpack.security.transport.filter.allow: localhost
xpack.security.transport.filter.deny: '*.google.com'
xpack.security.http.filter.allow: 172.16.0.0/16
xpack.security.http.filter.deny: _all
  1. Au lieu de modifier le fichier de configuration et de redémarrer le nœud, une autre option consiste à utiliser l’API de mise à jour des paramètres du cluster. Par exemple :
PUT /_cluster/settings
{
    "persistent" : {
        "xpack.security.transport.filter.allow" : "172.16.0.0/24"
   }
}

Questionnaire

Le cryptage des communications n’est possible que si l’autorité de certification est connue du public.

  • Vrai
  • Faux

Quel est le risque si vous ne mettez pas en place l’authentification des nœuds ?

  • Pas de problème car vous avez déjà mis en place l’authentification des utilisateurs
  • Un nœud imposteur pourrait rejoindre le cluster et avoir accès à des données critiques
  • Vos nœuds ne peuvent pas communiquer entre eux

Lors de la génération d’un certificat de nœud avec certutil, quels sont les trois composants inclus dans le keystore PKCS#12 ?

  • Node certificate
  • CA key
  • Node key
  • CA certificate