Comment intégrer les données de AWS CloudWatch dans Splunk

Splunk a publié plusieurs modèles AWS Lambda pour faciliter l’importation continue des logs, des événements et des alertes provenant de plus de 15 services AWS dans Splunk pour bénéficier de renseignements stratégiques sur la sécurité et les opérations de votre infrastructure AWS et vos applications. Dans cet article, nous allons vous guider pas à pas dans l’utilisation de l’un de ces modèles AWS Lambda, le modèle Lambda pour CloudWatch Logs, qui permet d’importer AWS CloudWatch Logs dans Splunk en continu via AWS Lambda afin d’obtenir des capacités d’analyse et de visualisation en quasi-temps réel, comme décrit dans le schéma ci-dessous. Dans l’exemple suivant, nous nous intéressons à l’importation des logs VPC Flow, qui sont conservés dans CloudWatch Logs. Les logs VPC Flow capturent des informations sur tout le trafic IP en provenance et à destination des interfaces réseau, et ils sont donc essentiels pour l’analyse de sécurité et la résolution des problèmes. Cela dit, le mécanisme suivant s’applique à tous les logs stockés dans CloudWatch Logs.

Contenu de ce guide :

1. Tout d’abord, une remarque sur les méthodes d’ingestion « pull » et « push »
2. Guide pas à pas de l’importation d’AWS CloudWatch Logs
3. En bonus, des tableaux de bord de trafic et de sécurité !
4. Résolution des problèmes
5. Conclusion

Tout d’abord, une remarque sur les méthodes d’ingestion « pull » et « push »

Splunk prend en charge différentes méthodes d’importation des données : supervision des fichiers locaux, diffusion des données de transaction, importation des données d’API tierces distantes, et réception des données via syslog, tcp/udp ou http.

Un bon exemple d’importation « pull » des données depuis des sources distantes est avec l’extension Splunk pour AWS qui collecte de façon fiable les données de différentes services AWS.
À l’inverse, la fonction AWS Lambda « pousse » les événements via HTTPS vers le Collecteur d’événements HTTP (HEC) de Splunk.

Ces deux modèles pull et push s’appliquent à des scénarios d’utilisation différents et font l’objet de considérations distinctes. Ce billet aborde le modèle push qui s’applique particulièrement aux architectures de microservices et à l’informatique orientée événements comme AWS Lambda. Comme il n’y a pas de sondeur dédié à gérer et à orchestrer, le modèle push offre généralement les avantages suivants :

• Complexité opérationnelle et coûts d’exploitation réduits
• Évolutivité plus facile
• Peu de frictions
• Latence faible

• Étape 1 : Activation de la diffusion de CloudWatch Logs
• Étape 2 : Configuration de l’entrée HEC Splunk
• Étape 3 : Configuration de la fonction Lambda
   

1. Activation de la diffusion de CloudWatch Logs

Le guide ci-dessous utilise les logs VPC Flow comme par exemple pour la diffusion de logs CloudWatch. Si vous avez déjà un flux de log CloudWatch provenant de logs VPC Flow ou autre, vous pouvez passer à l’étape 2 en remplaçant les références aux logs VPC Flow par votre type de données particulier.

1a. Créez un rôle Flow Logs (logs de flux) pour autoriser le service VPC Flow Logs à publier des logs dans CloudWatch Logs. Créez ensuite un nouveau rôle IAM associé à la politique IAM suivante :


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}


Notez bien le nom du rôle, par exemple vpcFlowLogsRole, car vous allez en avoir besoin pour la prochaine étape. Vous devrez également attribuer une relation de confiance à ce rôle pour autoriser le service flow logs à l’endosser. Cliquez sur « Edit Trust Relationship » (Modifier la relation de confiance) dans l’onglet « Trust Relationships » (Relations de confiance) du nouveau rôle, supprimez toute politique existante et collez ce qui suit à la place :


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "vpc-flow-logs.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}


1b. Activez Flow Logs sur vos VPC à l’aide de la console AWS VPC, comme décrit dans la documentation AWS VPC. Pour le reste de ce guide, imaginons que vous avez spécifié vpcFlowLogs comme groupe CloudWatch Logs de destination, que nous référencerons à une étape ultérieure. Dans quelques minutes, vous devriez voir des enregistrements flow logs dans la console CloudWatch Logs, sous ce groupe de logs.

2. Configuration de l’entrée HEC Splunk

Maintenant que des flow logs sont enregistrés, nous allons mettre en place le pipeline de données en partant de la fin, autrement dit Splunk, puis en remontant jusqu’à la source.

2a. Installez l’extension Splunk pour AWS. Notez que, dans la mesure où nous allons utiliser le HEC Splunk, nous n’allons *pas* nous appuyer sur les entrées modulaires de l’extension pour recueillir les données de CloudWatch Logs ou VPC Flow Logs. Toutefois, nous allons exploiter la logique d’interprétation des données (sourcetype) qui se trouve déjà dans l’extension pour lire automatiquement les enregistrements des logs VPC Flow et en extraire les champs.

2b. Créez un jeton HEC à partir de Splunk Enterprise. Consultez la documentation Splunk HEC pour obtenir des instructions détaillées.
Lors de la configuration des paramètres d’entrée, pensez à spécifier « aws:cloudwatchlogs:vpcflow » comme sourcetype. C’est important pour activer l’extraction automatique des champs. N’oubliez pas de noter la valeur de votre nouveau jeton HEC.
Remarque : dans les déploiements Splunk Cloud, HEC doit être activé par le support Splunk.

Voici à quoi ressemblent les paramètres d’entrée des données :

3. Configuration de la fonction Lambda

L’étape de pipeline avant le HEC Splunk est AWS Lambda. Elle est exécutée par CloudWatch Logs à chaque fois qu’il y a des logs dans un groupe, et envoie ces enregistrements à Splunk. Fort heureusement, il existe déjà un modèle Lambda, publié par Splunk dans ce but précis.

3a. Créez la fonction Lambda à l’aide du modèle Lambda « CloudWatch Logs to Splunk » (CloudWatch Logs vers Splunk) depuis la console AWS en cliquant ici. Vous pouvez également vous rendre sur la console AWS Lambda, cliquer sur « Create a Lambda function » (Créer une fonction Lambda) puis rechercher « splunk » sous « Select blueprint » (Sélectionner un modèle). Sélectionnez alors le modèle Lambda splunk-cloudwatch-logs-processor.  

3b. Configurez le déclencheur de la fonction Lambda. Sélectionnez « CloudWatch Logs » comme déclencheur si ce n’est pas déjà le cas. Indiquez ensuite vpcFlowLogs comme groupe de logs. Saisissez le « Filter Name » (Nom de filtre), par exemple vpcFlowLogsFilter. Vous pouvez également saisir une valeur pour « Filter pattern » (Motif de filtrage) si vous souhaitez limiter ce qui est envoyé à Lambda. Avant de cliquer sur « Next » (Suivant), vérifiez que la case « Enable trigger » (Activer le déclencheur) est cochée. Voici un exemple du formulaire rempli :

On l’appelle également filtre de souscription CloudWatch Logs, et il a pour effet de créer un flux en temps réel des événements de log provenant du groupe de logs sélectionné, vpcFlowLogs dans notre cas.

Notez qu’au moment où vous ajouterez ce déclencheur Lambda dans la console AWS, Lambda donnera au service CloudWatch Logs les permissions nécessaires pour invoquer cette fonction Lambda.

3c. Configurez la fonction Lambda. Cette fonction implémente déjà la logique nécessaire pour traiter les données CloudWatch Logs, en les décodant, en les décompressant et en découpant les événements avant de les envoyer au HEC Splunk. Vous aurez besoin des paramètres suivants :

• En haut : spécifiez le nom de votre fonction Lambda, par exemple vpcFlowLogsProcessor
• Sous le code de la fonction : renseignez les paramètres Splunk sous Environment Variables (variables d’environnement), comme indiqué dans la capture d’écran, comme suit :
  • SPLUNK_HEC_URL est l’URL Splunk du point de terminaison HEC, par exemple https://:8088/services/collector, où l’hôte est le nom de domaine entièrement qualifié ou l’adresse IP de Splunk. Notez que le port par défaut de HEC est 8088
  • SPLUNK_HEC_TOKEN est la valeur du jeton de l’entrée HEC que vous avez créé précédemment.
• Sous « Lambda function handler and role » (gestionnaire de fonction et rôle) : pour Role (rôle), sélectionnez « Choose an existing role » (choisir un rôle existant) puis, pour Existing Role (rôle existant), sélectionnez « lambda_basic_execution » qui donne à la fonction Lambda les autorisations minimales requises pour inscrire ses propres logs dans CloudWatch Logs.

Notez qu’AWS Lambda chiffre par défaut les variables d’environnement au repos à l’aide d’une clé de service Lambda. Les variables d’environnement sont automatiquement déchiffrées par AWS Lambda lorsque la fonction est invoquée. Bien que ce ne soit pas indispensable dans cette configuration, vous avez également la possibilité de chiffrer les variables d’environnement avant de déployer la fonction Lambda. Pour plus d’informations, consultez Création d’une fonction Lambda en utilisant des variables d’environnement pour stocker des informations sensibles.

Vous pouvez maintenant cliquer sur « Next » (suivant) après avoir relu votre configuration Lambda, qui doit être de la forme suivante :

Au bout de quelques minutes, vous devriez commencer à voir des événements Splunk Enterprise.
Vous pouvez faire une recherche par sourcetype


sourcetype="aws:cloudwatchlogs:vpcflow"


Ou par source, définie par la fonction Lambda avec une valeur par défaut de « lambda: » :


source="lambda:vpcFlowLogsProcessor"


En bonus, des tableaux de bord de trafic et de sécurité !

En utilisant l’assimilation des données basée sur Lambda, vous bénéficiez non seulement de la simplicité de configuration décrite ci-dessus, mais aussi de tableaux de bord avancés et d’analyses sophistiquées de trafic et de sécurité sur les logs VPC Flow fournis avec l’Application Splunk pour AWS. Si vous définissez le bon sourcetype, par exemple « aws:cloudwatchlogs:vpcflow » dans le cas des logs VPC Flow comme indiqué ci-dessus, vous devriez voir les tableaux de bord correspondants se remplir automatiquement. Après l’avoir installée, rendez-vous dans l’Application Splunk pour AWS et affichez le tableau de bord « VPC Flow Logs: Traffic Analysis » (Logs VPC Flow : Analyse du trafic) sous le menu déroulant Trafic et accès, et le tableau de bord « VPC Flow Logs: Security Analysis » (Logs VPC Flow : Analyse de sécurité) sous le menu déroulant Security (Sécurité) : 

Résolution des problèmes

Si vous ne voyez pas d’événements dans Splunk, vous pouvez résoudre le problème en procédant par segment de pipeline, en suivant le flux des données :

1. Vérifiez que les logs VPC Flow sont bien capturés dans le groupe de logs CloudWatch que vous avez indiqué. Si vous ne voyez toujours aucun log, voici des causes possibles :
   • Il peut falloir plusieurs minutes pour collecter et publier les logs de flux dans CloudWatch Logs lors de la création d’un flow log.
   • Le groupe de logs dans CloudWatch Logs n’est créé qu’au moment de l’enregistrement du trafic. Vérifiez qu’il y a bien du trafic sur les interfaces réseau des VPC sélectionnés.
   • Le service VPC flow logs ne possède pas les autorisations adéquates. Vérifiez le rôle et la politique IAM comme détaillé à l’étape 1 ci-dessus.
      
2. Vérifiez que la fonction Lambda est bien déclenchée par les événements CloudWatch Logs. Tout d’abord, vérifiez que le déclencheur est activé en vous rendant dans la Console AWS Lambda -> Functions (fonctions) -> (nom de votre fonction) puis en sélectionnant l’onglet « Triggers » (déclencheurs). S’il est activé, le déclencheur CloudWatch Logs doit comporter un bouton « disable » (désactiver). À ce stade, le meilleur endroit pour dépanner la fonction Lambda se trouve dans les logs capturés dans CloudWatch Logs. Sélectionnez l’onglet « Monitoring » (supervision), puis cliquez sur « View logs in CloudWatch » (afficher les logs dans CloudWatch). Par défaut, le modèle de la fonction Lambda enregistre les lots de données décodées provenant de CloudWatch Logs, puis la réponse provenant de Splunk, ainsi que le nombre d’événements de log traités. Si vous voyez des erreurs de requête, voici quelques causes courantes :
   • Le port du HEC Splunk est protégé par un pare-feu ;
   • Le jeton HEC Splunk n’est pas valide et renvoie un code d’état « unauthorized » (non autorisé).

Conclusion

Nous vous avons montré comment configurer un pipeline de données léger et hautement évolutif pour intégrer en continu vos précieux logs CloudWatch dans votre déploiement Splunk Enterprise en conjuguant AWS Lambda et le HEC Splunk. Ce pipeline de données permet le traitement et l’analyse des données en quasi-temps réel par Splunk Enterprise.

Pour prendre un exemple de log CloudWatch, nous avons utilisé les logs VPC Flow qui sont stockés dans CloudWatch. Ces données sont indispensables pour comprendre le trafic au sein d’un VPC et pour toute question de sécurité. Notez toutefois que les logs VPC Flow sont eux-mêmes capturés selon un intervalle de quelques minutes, si bien que l’analyse des logs VPC Flow ne peut se faire que par lot.

Cliquez ici pour apprendre à utiliser les modèles Lambda pour Splunk directement depuis votre Console AWS. Nous sommes impatients de voir comment vous allez exploiter la puissance d’AWS Lambda et du HEC Splunk pour mettre sur pied vos propres architectures sans serveur et pipelines de données. Laissez-nous un message ci-dessous pour vous faire part de vos commentaire, ou sur Splunk Answers si vous avez la moindre question.

----------------------------------------------------
Merci !
Roy Arsan

^{*Cet article est une traduction de celui initialement publié sur le blog Splunk anglais.}