Sécurité

• PKI dans Elasticsearch
• Sécurisation des données en transit
• Certificats
• Sécurisation des données au repos
• Accès basé sur les rôles
• Données sensibles

PKI dans Elasticsearch

Depuis la version 5.0, l'ancien plug-in d'activation TLS est devenu obsolète et a été remplacé par un nouveau plug-in intitulé X-Pack. X-Pack offre un certain nombre de fonctions supplémentaires proposées aux utilisateurs d'entreprise, mais il requiert une licence. Ces fonctions sont gratuites pendant une période limitée de 30 jours, au-delà de laquelle toutes les fonctions X-Pack sont désactivées.

Search Guard {: newwindow} est un autre produit qui offre des plug-ins relatifs à la sécurité pour la pile ELK. Contrairement à X-Pack, certaines de ses fonctions sont proposées à partir de la catégorie édition de communauté_ sans limitation d'utilisation. Comme indiqué dans le fichier Readme, Search Guard propose gratuitement toutes les fonctions de sécurité de base. L'édition de communauté de Search Guard peut être utilisée pour tous les projets, dont les projets commerciaux, totalement gratuitement.` Le chiffrement TLS avec PKI est l'une de ces fonctions de l'édition de communauté.

Par défaut, la pile ELK IBM Cloud Private utilise Search Guard pour fournir PKI. Si vous disposez déjà d'une licence pour X-Pack ou si vous prévoyez d'en acheter une, vous pouvez spécifier les paramètres suivants lors du déploiement pour configurer la pile ELK de manière à utiliser l'implémentation PKI de X-Pack. Le client est responsable de l'installation de la licence après le déploiement.

   logging:
     security:
       provider: xpack

Sécurisation des données en transit

Chaque déploiement de la pile Elasticsearch est sécurisé par défaut avec une authentification mutuelle via TLS. La pile ELK gérée est également configurée de manière à utiliser l'autorité de certification IBM Cloud Private pour signer les certificats qu'utilise la pile. Par défaut, toutes les autres piles ELK créent leur propre autorité de certification sur le déploiement. Pour activer ou désactiver la sécurité de plusieurs piles ELK, désactivez la sécurité dans l'interface utilisateur du catalogue ou dans le fichier de substitution de valeurs pour le déploiement Helm.

• Helm

Le fragment suivant peut être ajouté à un fichier de remplacement de valeurs pour le déploiement Helm afin d'activer ou de désactiver la sécurité :

  security:
    enabled: true|false

Certificats

Toutes les connexions à Elasticsearch doivent être configurées pour échanger un certificat correctement signé lorsque la sécurité est activée. L'architecture de pile ELK IBM Cloud Private génère un certain nombre de certificats à appliquer à des rôles discrets. Ces derniers sont tous stockés dans le même secret Kubernetes, en respectant la convention de dénomination suivante : <release_name>-ibm-icplogging-certs.

Sécurisation des données au repos

La pile Elasticsearch n'offre pas de chiffrement pour les données au repos en interne. La société Elastic recommande d'utiliser des solutions tierces pour réaliser cela. IBM Cloud Private comporte des instructions relatives aux méthodes prises en charge en matière de chiffrement de données sur disque. Pour plus d'informations, voir Chiffrement des volumes utilisés par IBM Cloud Private.

Accès basé sur les rôles

La version 2.0.0 de la charte Helm ibm-icplogging (incluse dans IBM Cloud Private 3.1.0) introduit un nouveau module qui fournit des contrôles d'accès à base de rôles (RBAC) pour tous les appels d'API REST Elasticsearch. Ce nouveau module est disponible uniquement pour les piles ELK gérées.

Le module RBAC est en réalité un proxy qui se trouve devant chaque pod client Elasticsearch. Toutes les connexions doivent avoir des certificats signés par l'autorité de certification de cluster Elasticsearch. Par défaut, il s'agit de l'autorité de certification (CA) racine IBM Cloud Private. Le module RBAC examine la demande pour un en-tête authorization et, à partir de là, applique des contrôles basés sur les rôles. En général, les règles RBAC sont les suivantes :

1. Un utilisateur disposant du rôle ClusterAdministrator est autorisé à accéder à n'importe quelle ressource, qu'il s'agisse d'un journal d'audit ou d'application.
2. Un utilisateur disposant du rôle Auditor n'est autorisé à accéder qu'aux journaux d'audit présents dans les espaces de nom auxquels il est autorisé à accéder. Si les journaux d'audit sont montés sur ELK au lieu de l'outil SIEM d'entreprise existant suggéré, voir Intégration de la journalisation d'audit IBM Cloud Private aux outils SIEM d'entreprise.
3. Un utilisateur disposant de n'importe quel rôle ne peut accéder qu'aux journaux d'application présents dans les espaces de nom auxquels il est autorisé à accéder.
4. Toute tentative d'accès à des journaux d'application par un auditeur ou à des journaux d'audit par une personne autre qu'un auditeur, est rejetée.

Les règles RBAC fournissent un contrôle d'extraction de données de base aux utilisateurs qui accèdent à Kibana. Les règles n'empêchent pas de visualiser des métadonnées telles que les noms de zone de journal ou les tableaux de bord Kibana sauvegardés.

Données sensibles

Vous devrez peut-être masquer les données sensibles avant qu'elles n'atteignent Elasticsearch. Logstash est déployé avec un plugin nommé Mutate qui offre de nombreuses fonctions permettant de localiser des données considérées comme sensibles. Pour que ces masques puissent être ajoutés, il est nécessaire de personnaliser la configuration de Logstash, qui se trouve généralement dans une ressource configmap nommée <release_name>-ibm-icplogging-logstash-config. release_name fait référence au nom d'édition donné à un déploiement de charte Helm spécifique.

Les modifications apportées à la configuration de Logstash seront automatiquement propagées sur les conteneurs déployés après un court délai.

Les modifications apportées aux mappes de configuration sont perdues si vous redéployez la charte de journalisation. Par exemple, si vous effectuez une mise à niveau vers une nouvelle version.