Nativement, Elasticsearch https://www.elastic.co/products/elasticsearch ne fournit aucun mécanisme d’authentification ou d’autorisation.
En revanche, depuis 2015, le plugin x-pack fournit une brique de sécurité https://www.elastic.co/guide/en/x-pack/current/xpack-security.html permettant de mettre en place les mécanismes de sécurité manquants (authentification, autorisation, intégrité, chiffrement, supervision etc…).
Mise en place du chiffrement des échanges
Avant toute opération, il faut mettre en place le chiffrement des échanges TLS.
https://www.elastic.co/guide/en/x-pack/current/ssl-tls.html
Réinitialisation des mots de passes
Pensez à réinitialiser les mots de passes par défaut :
<pre class="programlisting">curl -XPUT -u elastic 'localhost:9200/_xpack/security/user/elastic/_password' -H "Content-Type: application/json" -d '{
"password" : "elasticpassword"
}'
curl -XPUT -u elastic 'localhost:9200/_xpack/security/user/kibana/_password' -H "Content-Type: application/json" -d '{
"password" : "kibanapassword"
}'
curl -XPUT -u elastic 'localhost:9200/_xpack/security/user/logstash_system/_password' -H "Content-Type: application/json" -d '{
"password" : "logstashpassword"
}'</pre>
… puis désactivez les mots de passes par défaut : xpack.security.authc.accept_default_password:false.
Mise en place des ACLs
Vous pouvez désormais créer des rôles en fonction de vos besoins et leur attribuer uniquement les permissions nécessaires pour leur fonctionnement.
Exemple :
curl -XPOST -u elastic 'localhost:9200/_xpack/security/role/products_reader' -H "Content-Type: application/json" -d '{
"indices" : [
{
"names" : [ "products*" ],
"privileges" : [ "read" ]
}
]
}'
Il est également possible de paramétrer l’accès aux “fields” si le rôle ne dispose que du privilège “read”.
L’authentification peut se faire avec un annuaire LDAP ou Active Directory ou par certificats client.
Désactivation des scripts dynamiques
Tout d’abord, bien que certains langages soient “sandboxed”, il est préférable de désactiver les scripts dynamiques dans le fichier `config/elasticsearch.yml` :
script.inline: false script.indexed: false script.file: true
Nous autorisons alors uniquement les “preloaded” scripts distribués dans le dossier config/scripts/ sur tous les noeuds du cluster.
Prévention des dénis de service
Il n’est pas évident de mettre en place un mécanisme générique pour éviter les risques liés aux attaques de type déni de service.
Il faut donc s’assurer que le format des données indexées ainsi que les “queries” sont bien optimisées. Par exemple, il faut absolument éviter de stocker des documents avec des “fields” dont les noms sont dynamiques.
Il est également recommandé de mettre en place un monitoring des “queries” pour détecter les problèmes de performance ou les abus.
Wishtack 