Au cours des dernières années, nous avons aidé de nombreux clients à passer au Cloud, en créant des Landing Zones et en effectuant des migrations de serveurs.
Réduire au minimum les temps d’arrêt tout en préservant l’intégrité des données est une exigence clé que les clients demandent en permanence et nous nous engageons à y répondre.
La sécurité des réseaux est également une exigence obligatoire. Le verrouillage des groupes de sécurité n’autorisant que la connectivité requise est une nécessité pour éviter l’exfiltration des données, réduire le rayon des cyberattaques et protéger vos applications.
Si la stratégie de migration est un réhébergement (c’est-à-dire Lift & Shift), la plupart des échecs des tests système/fonctionnels après la transition sont dus à l’absence de groupes de sécurité ou de règles NACL, difficiles à capturer pendant les sessions de découverte.
La détection de ces lacunes lors de la phase de triage post-coupure, et leur correction en temps voulu, est la clé du succès de la migration.
Dans les prochains paragraphes, je vais passer en revue les services qu’AWS fournit pour avoir une visibilité sur les logs de connectivité réseau dans un VPC.
Journaux de flux VPC
Sortie il y a 6 ans, cette fonctionnalité VPC accomplit une tâche très simple : elle consigne les métadonnées du trafic réseau pour chaque ENI (Elastic Network Interface) dans votre VPC.
Au fil des ans, le nombre de métadonnées prises en charge et pouvant être enregistrées a augmenté (liste complète ici).
Nous sommes intéressés par les IPs source/destination, le protocole, et l’action (rejet ou acceptation).
Les dernières versions du service incluent des informations très utiles telles que la région, le service AWS, le VPC, la direction du flux et le chemin du trafic.
Les journaux de VPC Flow peuvent être poussés vers Amazon S3 ou Cloudwatch Logs, en fonction du modèle de consommation que vous souhaitez adopter.
La journalisation n’est pas en temps réel. En général, les données sont stockées 5 minutes après l’événement avec Cloudwatch comme cible et 10 minutes avec S3.
Dans notre triage, nous devons utiliser Cloudwatch Logs comme cible car il nous permet d’interroger les journaux de réseau en utilisant Cloudwatch Logs Insights.
Vous pouvez (et devriez, pour des raisons de sécurité) activer les journaux de flux VPC à partir de vos paramètres VPC.
Pour chaque ENI, un flux de journaux est créé par VPC Flow Logs. Voici à quoi cela ressemble dans la console AWS :
Limitations des journaux de flux VPC
Compte tenu de la nature de VPC Flow Logs (un flux de journaux pour chaque ENI), il peut être difficile de trier les dysfonctionnements du réseau, comme vous devriez le faire :
- obtenir l’ID ENI pour l’instance EC2 / service AWS
- Rechercher l’ID ENI dans le groupe de journaux VPC Flow Logs
- Filtrer par action et adresse IP cible à l’aide de la recherche en texte intégral
Cette approche, bien que valide, n’est peut-être pas aussi immédiate que vous le souhaiteriez. La corrélation des journaux de différents flux de journaux est difficile (flowlogs-reader est un outil puissant à cet effet) car la plupart du temps, vous ne savez pas quel serveur ne fonctionne pas comme prévu. Le scénario typique à trier est « L’application X ne fonctionne pas » et non « le serveur A ne peut pas se connecter au serveur B ».
C’est pourquoi vous avez besoin d’un outil permettant d’interroger rapidement plusieurs flux de journaux à la fois, sans savoir quels identifiants ENI sont concernés.
Cloudwatch Logs Insights
AWS a sorti Cloudwatch Log Insights lors du 2018 re:Invent.
Citation de la documentation :
CloudWatch Logs Insights vous permet de rechercher et d’analyser de manière interactive vos données de journal dans Amazon CloudWatch Logs. Vous pouvez effectuer des requêtes pour vous aider à répondre plus efficacement aux problèmes opérationnels. Si un problème survient, vous pouvez utiliser CloudWatch Logs Insights pour identifier les causes potentielles et valider les corrections déployées.
CloudWatch Logs Insights comprend un langage de requête spécialement conçu à cet effet, avec quelques commandes simples mais puissantes. CloudWatch Logs Insights fournit des exemples de requêtes, des descriptions de commandes, l’autocomplétion de requêtes et la découverte de champs de journaux pour vous aider à démarrer. Des exemples de requêtes sont inclus pour plusieurs types de journaux de services AWS.
CloudWatch Logs Insights découvre automatiquement les champs dans les journaux des services AWS tels que Amazon Route 53, AWS Lambda, AWS CloudTrail et Amazon VPC, ainsi que toute application ou journal personnalisé qui émet des événements de journal en JSON.
C’est littéralement ce qu’il fait. L’aspect puissant de l’outil est que vous pouvez définir une requête qui couvre jusqu’à 20 groupes de journaux et tous les flux de journaux sous-jacents.
Auparavant, vous deviez utiliser Amazon Athena pour effectuer des analyses de données similaires. Le résultat final est similaire, bien que la configuration et l’utilisation d’Amazon Athena ne soient pas aussi simples que celles de Cloudwatch Logs Insights et qu’il y ait un délai de livraison supplémentaire du fait de l’utilisation de données provenant de S3.
Voici comment Cloudwatch Logs Insights se présente dans la console AWS :
Vous pouvez sélectionner plusieurs groupes de journaux à rechercher, leur période de temps et, enfin, la requête.
Nous allons ensuite définir une requête spécifique pour les journaux de flux VPC.
Tarification
Le modèle de tarification est basé sur la quantité de données analysées. Il tend à être raisonnablement bon marché pour interroger les données produites dans les dernières minutes dans les journaux Cloudwatch (c’est le champ d’application qui nous intéresse) étant donné qu’il ne coûte que 0,005 $ par Go de données analysées après les 5 Go inclus dans le niveau gratuit. La quantité de données stockées dépend du nombre de serveurs actifs et du format des journaux de flux VPC.
Mise en place
Une fois que vous avez activé les journaux de flux VPC ciblant les journaux Cloudwatch, vous verrez un flux de journaux pour chaque ENI. N’oubliez pas que chaque service déployé dans un VPC utilise un ou plusieurs ENI (par exemple Lambda, FSx, RDS, etc.).
Disons que nous venons de couper une application à trois niveaux composée de 3 serveurs (Web, App et DB).
Supposons maintenant que, pour une raison inconnue, l’application ne fonctionne pas comme prévu, par exemple, un dépassement de délai ou une erreur HTTP 503. Lors de la migration d’applications anciennes ou mal documentées, il peut être difficile de comprendre l’analyse des causes profondes d’un dysfonctionnement.
Pour détecter (ou exclure) les problèmes de réseau liés à l’absence de groupe de sécurité ou de règle NACL, ouvrez Cloudwatch Insights et utilisez la requête suivante :
filter( action="REJECT" and #We are only interested in rejected connections dstAddr like /^(10\.|192\.168\.)/ et #Regex pour n’inclure que les réseaux internes srcAddr like /^(10\.|192\.168\.)/ et ( #Liste des IPsdu serveur dans la portée de triage, nous sommes srcAddr = "10.0.0.6" ou #intéressés par les connexions entrantes et sortantes dstAddr = "10.0.0.6" ou #(srcAddr+dstAddr) srcAddr = "10.0.0.7" ou dstAddr = "10.0.0.7" ou srcAddr = "10.0.0.8" ou dstAddr = "10.0.0.8" ou ) )| les statistiques comptent(*) comme #Évitez les résultats en double (comptez-les plutôt) enregistrement avec srcAddr,dstAddr,dstPort,protocol | #Nous sommes intéressés par les IP de source/destination, #port de destination et protocole trier enregistrements desc | limiter 5 #Uniquement afficher les 5 premières entrées #Web Server 10.0.0.6 #App Server 10.0.0.7 #DB Server 10.0.0.8
Définir une période de 1 heure (ou plus si vous avez besoin d’une meilleure image). Mon conseil est de réduire la quantité de données interrogées pour obtenir de meilleures performances à moindre coût.
La requête résultante ressemblera à ce qui suit :
Dans cet exemple :
- Le serveur d’application essaie de se connecter à la base de données SQL en utilisant un port dynamique
- Un client du réseau interne tente de se connecter au serveur Web en utilisant le protocole HTTP
- Le serveur Web essaie de se connecter au port SQL 1434/UDP (typique des instances SQL named)
- Le serveur d’application essaie de se connecter à un partage de fichiers dans un autre VPC dans AWS (445/TCP correspond au protocole SMB)
- Le serveur d’applications essaie de se connecter au serveur Web en utilisant un port personnalisé
Notez que le numéro de protocole correspond aux numéros de protocole Internet attribués par l’IANA Assigned Internet Protocol Numbers (par exemple, 6 = TCP, 17 = UDP).
Il est important de souligner qu’une connexion signalée comme « acceptée » dans les journaux de flux VPC ne signifie pas nécessairement que la connectivité de bout en bout fonctionne.
Par exemple, si un pare-feu sur site bloque une connexion, le journal affichera quand même l’état « ACCEPT », car AWS autorise la connexion. Une bonne pratique pour détecter ces flux bloqués consiste à isoler les connexions sans retour.
Conclusion
La correction et le test de ces lacunes ne prendraient que quelques minutes au lieu de quelques heures.
Cette approche minimisera le temps d’arrêt de l’application dû à la migration, permettant aux équipes de se concentrer sur les tests de performance et fonctionnels et de mettre l’application à la disposition des utilisateurs finaux plus rapidement.
Dans les grands projets de migration, l’automatisation est la clé pour réduire au minimum les efforts déployés par les ingénieurs afin de construire et d’exécuter les requêtes Cloudwatch Logs Insights.
L’utilisation de l’API AWS (sous la forme de CLI ou de SDK) est recommandée pour éviter les étapes manuelles.
Cliquez ici pour en savoir plus sur notre approche « intelligente » des migrations vers le Cloud.
