Dans l'article précédent, j'avais commencé à découper Splunk en plusieurs fonctionnalités pour vous montrer que, globalement, il n’y a rien d’insurmontable à partir du moment où on connaît la solution. J'avais abordé ici la simplicité de mise en oeuvre et de configuration du logiciel, les problématiques de collecte et réception des logs, la mise en place de recherches et d'alertes et l'envoi de logs depuis un serveur ou un poste distant à l'aide de l'universal forwarder. Au programme aujourd'hui : le stockage et l'archivage, la segmentation entres les différents types de logs, la gestion des rôles, l’archivage et la corrélation.
Stockage
Les données indexées dans Splunk correspondent exactement à celles qui sont envoyées par l’équipement source. De plus, et afin de simplifier au maximum les recherches, Splunk ajoute un champ correspondant à l’heure à laquelle le log a été indexé ainsi que trois valeurs permettant de bien identifier les logs et de les différencier. Il s’agit des champs host (correspondant au nom ou à l’adresse IP de l’équipement source), source (correspondant à comment le log a été reçu par Splunk pour distinguer par exemple un fichier texte d’un flux réseau) et sourcetype (équivalent d’un tag et correspondant généralement au type de log dont il est question). Bien entendu, les logs d’origine ne sont pas altérés et peuvent être restitués tels quel à tout moment. Il s’agit ici plutôt de « repères » utilisés par Splunk mais pas de modifications apportées aux logs bruts. A noter également que Splunk permet de signer des blocs de logs au moment de l’indexation. Cette signature est vérifiée à la volée lors des recherches afin de s’assurer que les logs n’ont pas été modifiés depuis leur indexation. Cette fonctionnalité est très coûteuse en termes de ressources pour la machine hôte. En ce sens, il est recommandé de n’utiliser la signature que pour des logs véritablement critiques et non à l’échelle de l’ensemble du Système d’Information. Les logs indexés par Splunk sont stockés dans des fichiers à plat, si si c'est vrai. Pas de bases de données derrière donc, que des fichiers texte correspondant aux logs bruts, tels qu'ils ont été reçus. La méthode d'indexation de base permet de définir des niveaux d'ancienneté de logs de façon assez classique "hot", "warm" et "cold" avec pas mal de possibilités pour faire un tuning précis et adapté aux exigences de tous les environnements. Typiquement en jouant sur la taille de ces "buckets" on va pouvoir optimiser l'utilisation de l'espace disque en fonction de l'importance de tel ou tel type de logs. Voilà qui nous mène tout droit à la notion d'archivage.
Archivage
L’archivage vers une zone donnée sur le réseau est possible à partir du moment où cette zone est accessible par Splunk (c'est fou ça hein ?). Pour mettre en place des politiques d'archivage plus complexe, on peut également s'appuyer sur des scripts que Splunk sait lancer automatiquement au moment opportun. Dans le fonctionnement le plus simple, on va chercher à définir une taille maximum de logs à conserver ou une durée maximale avant l’archivage. En connaissant la volumétrie de logs au quotidien, on peut arriver à des politiques d'archivage poussées et variées en fonction du type de logs dont il est question. Cela permet de supprimer par exemple des logs réseau au bout d'une semaine et de conserver les logs proxy pendant x mois ou années selon les exigences puis de les archiver (en étant tout de même en mesure de les fournir aux autorités si nécessaire). En effet, une fois les logs archivés, ils peuvent être réimportés à tout moment et consultés à partir de l’interface web de la solution. Pas d'inquiétude sur ce point donc. A l'aide de fonctions plus avancées mais tout de même existantes sur Splunk, les logs peuvent être signés. S’ils devaient être réutilisés, il serait possible de vérifier qu’ils n’ont pas été altérés à partir de cette signature. A noter également que la durée de conservation maximale sur le serveur et sur la zone de stockage prévue à cet effet dépend uniquement de la taille du disque dur du serveur et de la capacité de la zone de stockage.
Segmentation
Splunk propose une segmentation simple et efficace afin de ne donner accès à certaines informations (logs) qu’aux personnes en droit de les consulter. Cette segmentation est extrêmement granulaire et permet une gestion des droits fine et précise. La segmentation peut s’effectuer en fonction des différents champs présents dans les logs (en particulier source, sourcetype et host) mais également de façon plus globale en indexant les logs dans des index distincts. Un index est en quelque sorte une zone de stockage dans Splunk. Celle-ci est hermetique et il n’y a pas de communications d’un index à l’autre. La segmentation au sens stockage est à mettre en parallèle de la segmentation au sens « gestion des rôles ».
Gestion des rôles
L’accès au serveur sur lequel Splunk est installé est indépendant de la solution. Le filtrage des accès console ou TSE par exemple doit être effectué au niveau du système d’exploitation En ce qui concerne l’authentification à l’interface web d’administration de Splunk, elle peut être effectuée à partir d’une base locale ou à l’aide d’un couplage avec un annuaire AD / LDAP. En fonction du login d’un administrateur ou de son appartenance à un groupe AD spécifique par exemple, il est possible d’associer un rôle distinct à chaque administrateur. Chaque rôle permet d’avoir un certain nombre de droits (lecture seule, écriture sur tout ou partie des logs, etc) ce qui permet une granularité très fine dans la gestion des comptes d’administration. Ainsi, vous pouvez définir des profils qui n'ont la visibilté que sur une partie des logs sans savoir que d'autres logs sont présents sur Splunk par exemple. Libre à vous également de créer vos propres rôles d'utilisateur ou d'administrateur avec un certains nombres de fonctionnalités associé à chacun (pratique notamment pour les services managés ou encore pour des accès mutualités).
Corrélation
La corrélation à proprement parler est directement liée à la normalisation des logs. La flexibilité de Splunk implique justement l’absence de normalisation des logs par défaut. En effet, par défaut, tous les logs peuvent être indexés et il n’est pas nécessaire qu’ils « entrent » dans un schéma prédéfini. Cependant, il est possible de normaliser les champs de tous les logs. Pour cela, il est nécessaire de définir un modèle sur lesquels tous les logs pourront se calquer. A titre d’exemple, tous les champs correspondant à des noms d’utilisateur devront avoir la même valeur. Ainsi, pour tous les logs du Système d’Information, le résultat sera indexé par exemple en tant que « user=xxxx » là où, de base, on pouvait avoir « user=xxxx » pour les logs d’un firewall, « [email protected] » pour les logs d’un relai de messagerie, « current_user=DOMAIN/xxxx » pour une application métier développée en interne, etc. La majeure partie de cette configuration s’effectue en éditant les fichiers de configuration afin de bénéficier de plus de flexibilité et de précision qu’en utilisant l’interface graphique. A noter que Splunk met à disposition une application spécialement créée pour la normalisation des champs et la « transformation » de Splunk en un SIEM à part entière. Cette application intègre la normalisation des champs pour bon nombre de constructeurs du marché. Bien entendu, pour les logs d’une application spécifique, la normalisation restera à réaliser « manuellement ».
