Meilleures performances et sécurité en surveillant les journaux, les métriques, etc.

Dans l'article précédent de cette série - Le guide complet de la collecte de données dans DevSecOps - nous avons discuté de l'importance de la collecte de données. Dans cet article, nous explorerons le rôle de la surveillance dans l'observabilité, en particulier en ce qui concerne la sécurité, les performances et la fiabilité.

La surveillance est essentielle pour détecter les problèmes et les valeurs aberrantes au fur et à mesure qu'ils surviennent en production et permet aux équipes DevSecOps d'identifier et de résoudre les problèmes avant qu'ils ne causent de graves dommages. La surveillance des dégradations de performances ou des activités suspectes peut entraîner des alertes et des réponses automatiques pour isoler les problèmes ou les attaques potentiels.

Dans cet article, nous examinerons la surveillance en détail, fournirons plusieurs cas d'utilisation et meilleures pratiques, et expliquerons comment la surveillance peut spécifiquement améliorer la sécurité, les performances et la fiabilité grâce à l'observabilité.

Quel est le rôle de la surveillance dans l'observabilité ?

Dans un système observable, nous collectons des données à partir de journaux, de métriques et de traces distribuées. Et tandis que pour les très petits systèmes, vous pouvez parcourir et rechercher manuellement les journaux, visualiser les métriques sous forme de graphiques et tracer des diagrammes montrant comment le trafic circule dans le système afin d'identifier les problèmes - à grande échelle, cela ne suffit pas. Vous avez besoin d'une surveillance, d'un processus automatisé qui garde un œil sur ces données et vous alerte de manière appropriée. (Pour un traitement plus détaillé de la différence entre surveillance et observabilité, vous pouvez consultercette ressource .)

Dans une entreprise, vous avez besoin de moyens automatisés pour filtrer, agréger, enrichir et analyser toutes ces données. Les entreprises ont également besoin de moyens automatisés pour prendre des mesures lorsqu'un événement inhabituel est détecté. La réponse automatisée peut informer l'équipe responsable ou même prendre directement des mesures correctives.

Dans d'autres domaines comme la médecine, la surveillance des signes vitaux des patients est une activité clé, qui sauve des vies. La surveillance des systèmes logiciels est très similaire, et nous utilisons même la même méthodologie pour effectuer des vérifications de l'état et discuter de l'état des différents composants.

Assez de théorie, passons à quelques exemples concrets de monitoring.

Cas d'utilisation de la surveillance de l'observabilité

Voici quelques cas d'utilisation typiques qui tirent parti de la surveillance :

• Les applications Web sont une partie importante de nombreux systèmes distribués à grande échelle et la clé du succès des entreprises axées sur le numérique. La surveillance des applications conteneurisées Kubernetes ou simplement des journaux du serveur Web pour une apparition excessive de codes d'erreur (tels que 4xx ou 5xx ) peut aider une équipe à résoudre les problèmes de performances et de fiabilité avant qu'ils ne deviennent des problèmes importants.
• Au niveau de l'infrastructure, il est important de surveiller le processeur, la mémoire et le stockage de vos serveurs. Comme la plupart des entreprises, vous utilisez probablement l'autoscaling pour que votre système puisse allouer plus de capacité. Les journaux de la plate-forme capturent les changements apportés aux ressources, par exemple lorsqu'elles sont provisionnées, déprovisionnées ou reconfigurées. Cependant, la surveillance de ces métriques et journaux de ressources peut vous aider à vous assurer que vous travaillez dans les limites des quotas et des limites, et cela peut aider votre organisation en matière de planification et de budgétisation des ressources.
• Les banques de données sont au cœur de la plupart des systèmes à grande échelle. Si vos données sont perdues, corrompues ou indisponibles, vous avez une situation sérieuse entre vos mains. Pour suivre vos données, vous devez surveiller les connexions à la base de données, les métriques de durée des requêtes, l'espace disque, les sauvegardes et les taux d'erreur. Vous devez également comprendre vos magasins de données et définir des alertes lorsque vous observez des valeurs en dehors de la plage attendue, telles que des requêtes lentes, un taux élevé d'erreurs ou un espace disque insuffisant. Vous pouvez également configurer la journalisation pour vos bases de données afin de capturer les connexions, les requêtes et les modifications apportées aux champs ou aux tables. La surveillance de vos journaux de base de données peut vous aider à détecter non seulement où vous pouvez améliorer vos performances et votre fiabilité, mais aussi la sécurité si des opérations malveillantes (ou involontaires) sont effectuées.

Notez que la surveillance est beaucoup plus complexe que la définition d'une condition simple (telle que "plus de cinq requêtes INSERT dans la base de données des orders en deux minutes") et le déclenchement d'une alerte lorsque cette condition est remplie. La saisonnalité peut être en jeu, avec des modèles d'utilisation qui provoquent des pics à certains moments de la journée, de la semaine ou de l'année. Une surveillance efficace qui détecte les comportements inattendus tient compte du contexte et peut reconnaître les tendances en fonction des données passées.

Ce type de surveillance, en particulier lorsqu'il est mis en œuvre avec un outil qui combine observabilité, surveillance et sécurité à grande échelle, peut être extrêmement efficace, comme dans cette étude de cas de Sumo Logic et Infor, où Infor a pu économiser 5 000 heures de temps passées sur incidents.

Comment la surveillance contribue-t-elle spécifiquement à l'amélioration des performances et de la fiabilité ?

La surveillance améliore les performances et la fiabilité d'un système en détectant les problèmes tôt pour éviter la dégradation. Les problèmes de performances deviennent souvent des problèmes de disponibilité et de fiabilité. Cela est particulièrement vrai en présence de délais d'attente. Par exemple, supposons qu'une application expire après 60 secondes. En raison d'un récent problème de performances, de nombreuses demandes prennent soudainement plus de 60 secondes à traiter. Toutes ces requêtes vont maintenant échouer et l'application n'est plus fiable.

Une bonne pratique courante pour résoudre ce problème consiste à surveiller les quatre signaux d'or de tout composant dans le chemin critique des services et applications hautement prioritaires : latence, trafic, erreurs et saturation.

Latence

Combien de temps faut-il pour traiter une demande ? Notez que la latence des demandes réussies peut être différente de celle des demandes ayant échoué. Toute augmentation significative de la latence peut indiquer une dégradation des performances du système. D'un autre côté, toute diminution significative pourrait être un signe que certains traitements sont ignorés. Dans tous les cas, la surveillance attirera l'attention sur le problème éventuel.

Circulation

La surveillance du trafic vous permet de comprendre la charge globale de chaque composant. Le trafic peut être mesuré de différentes manières pour différents composants. Par example:

• API REST : le nombre de requêtes
• Un service backend : la profondeur d'une file d'attente
• Un composant de traitement des données : le nombre total d'octets de données traités.

Une augmentation du trafic peut être due à la croissance organique de l'entreprise, ce qui est une bonne chose. Cependant, cela peut également indiquer un problème dans un système en amont qui génère anormalement plus de trafic qu'auparavant.

les erreurs

Une augmentation des taux d'erreur de tout composant a un impact direct sur la fiabilité et l'utilité du système. De plus, si les options défaillantes sont automatiquement retirées, cela peut entraîner une augmentation du trafic, ce qui peut par la suite entraîner des problèmes de performances.

Saturation

Parmi les ressources disponibles, combien le service ou l'application utilise-t-il ? C'est ce que vous dit la surveillance de la saturation. Par exemple, si un disque est plein, un service qui écrit des journaux sur ce disque échouera à chaque demande ultérieure. À un niveau supérieur, si un cluster Kubernetes n'a pas d'espace disponible sur ses nœuds, les nouveaux pods seront en attente et non planifiés, ce qui peut entraîner des problèmes de latence.

Comme vous le remarquez, les quatre signaux dorés sont liés les uns aux autres. Les problèmes se manifestent souvent sur plusieurs signaux.

Comment la surveillance contribue-t-elle spécifiquement à améliorer la sécurité ?

Bien que tout problème de santé du système puisse avoir un impact direct ou indirect sur la sécurité, il existe certaines menaces directes que la surveillance peut aider à détecter et à atténuer.

• Toute anomalie, telle qu'une utilisation excessive du processeur ou un volume élevé de requêtes, peut être un attaquant essayant de provoquer des erreurs de segmentation, d'effectuer une extraction illégale de crypto ou de lancer une attaque DDoS sur le système.
• Un nombre inhabituel de paquets frappant des ports inhabituels peut être une attaque par frappe de port .
• Un nombre élevé d'erreurs 401 (erreurs d'authentification) avec des noms d'utilisateur valides et des mots de passe non valides peut être une attaque par dictionnaire.
• Un nombre élevé d'erreurs 403 (accès interdit) peut être une élévation de privilèges par un attaquant utilisant un compte compromis.
• Des charges utiles non valides pour les API publiques entraînant une augmentation de 400 erreurs peuvent être un attaquant essayant de planter de manière malveillante vos applications Web accessibles au public.
• Un téléchargement de grandes quantités de données ou de toute donnée sensible en dehors des heures de bureau peut être une attaque d'exfiltration par un employé compromis ou un initié malhonnête.

Meilleures pratiques de surveillance pour améliorer les performances et la sécurité

Un système est composé de plusieurs composants, mais il est plus que la somme de ses parties. À un niveau de base, vous devez surveiller chaque composant de votre système (au moins sur les chemins critiques) pour les quatre signaux d'or . Qu'est-ce que cela signifie en pratique ?

• Observer les indicateurs clés
• Établissement des gammes métriques pour un fonctionnement normal
• Définition d'alertes lorsque les composants s'écartent de la plage acceptable

Vous devez également porter une attention particulière aux dépendances externes . Par exemple, si vous exécutez dans le cloud ou intégrez un fournisseur de services tiers, vous devez surveiller les points de terminaison publics dont vous dépendez et définir des alertes pour détecter les problèmes. Si un tiers est en panne ou si ses performances sont dégradées, cela peut entraîner une défaillance en cascade de votre système.

Il n'est pas possible d'avoir des composants fiables à 100 %. Cependant, la surveillance peut vous aider à créer un système fiable à partir de composants non fiables en détectant les problèmes avec les composants (internes et externes) et en les remplaçant ou en dégradant gracieusement le service . Par exemple, si vous exécutez votre système dans une configuration multizone et qu'il y a un problème dans une zone, la surveillance peut le détecter et déclencher le réacheminement (manuel ou automatique) de tout le trafic vers d'autres zones.

Pour des raisons de sécurité, les quatre signaux peuvent également être des indicateurs auxiliaires d'un compromis . C'est particulièrement le cas, par exemple, si vous constatez un pic dans les processeurs de votre périphérique de point de terminaison ou de la charge de travail cloud, ou une augmentation du nombre de tentatives de connexion infructueuses. Cependant, la surveillance de la sécurité doit être très délibérée puisque vous avez affaire à des adversaires malveillants. Vous devez définir le service d'attaque de chaque composant et de l'ensemble du système et vous assurer que les informations que vous collectez sont suffisantes pour détecter les problèmes . Par exemple, pour détecter l'exfiltration de données, vous pouvez surveiller les adresses IP et la quantité de données envoyées en dehors de votre réseau interne par différentes applications et services. Si vous ne disposez pas de ces données, vous serez aveugle à cette méthodologie d'attaque.

Mettre en œuvre une stratégie de surveillance

Une fois que vous avez configuré votre collecte de données, vous pouvez suivre les étapes ci-dessous pour déployer une stratégie de surveillance robuste et efficace.

1. Identifier les actifs critiques.

Vous avez déjà réalisé un inventaire complet de tous vos actifs dans le cadre de la collecte de données. Maintenant, votre tâche consiste à identifier les actifs critiques qui doivent être surveillés de près pour prévenir et atténuer les catastrophes. Il est facile de dire « surveillez simplement tout », mais il y a des coûts à prendre en compte avec la surveillance. La surveillance et le déclenchement d'alertes pour vos environnements de simulation et de développement ou vos services expérimentaux peuvent imposer un stress inutile à vos ingénieurs. Des alertes fréquentes à 3 heures du matin pour des problèmes insignifiants entraîneront une fatigue d'alerte, paralysant la volonté de votre équipe de résoudre un problème quand il compte vraiment.

2. Attribuez un propriétaire à chaque actif critique.

Une fois que vous avez identifié les actifs critiques, vous avez besoin d'un propriétaire clair pour chacun d'eux. Le propriétaire peut être une personne ou une équipe. Dans le cas d'une personne, assurez-vous d'identifier également une solution de repli. Il est également important de conserver la propriété des actifs lorsque des personnes rejoignent et quittent l'organisation ou passent à d'autres rôles et équipes.

3. Définissez des alertes pour les actifs critiques.

En fin de compte, votre stratégie de surveillance vivra ou mourra en fonction de la façon dont vous définissez les alertes pour les actifs qui ne sont pas sains ou potentiellement compromis. Vous devez comprendre ce qui est normal pour chaque actif.

Si vous surveillez des métriques, définir "normal" signifie associer un attribut (tel que l'utilisation du processeur) à une plage de valeurs (telle que "50 % à 80 %"). La bande normale peut changer dynamiquement avec l'entreprise et peut varier à différents moments et à différents endroits. Dans certains cas, vous pouvez n'avoir que des plafonds ou des planchers. En définissant des plages normales, vous créez des alertes pour avertir un propriétaire d'actif lorsque son actif fonctionne en dehors de la plage normale.

Si vous surveillez les journaux, les alertes sont généralement définies en fonction du résultat de certaines requêtes de journal (telles que "nombre d'erreurs 404 enregistrées dans tous les services d'API au cours des cinq dernières minutes") satisfaisant ou échouant à une condition (telle que "est moins de 10"). Les outils de gestion et d'analyse des journaux peuvent vous aider.

4. Définissez des runbooks pour chaque alerte.

Lorsqu'une alerte critique se déclenche, que faites-vous ? Ce que vous ne voulez pas faire, c'est essayer de comprendre votre stratégie sur place, pendant que les clients tweetent sur les produits peu fiables de votre entreprise et que la direction panique.

Un runbook est une recette d'étapes faciles à suivre que vous préparez et testez à l'avance pour vous aider à collecter des informations supplémentaires (par exemple, quels tableaux de bord consulter et quels scripts de ligne de commande exécuter pour diagnostiquer la cause première) et atténuer les actions (par exemple, déployer la version précédente de l'application). Votre runbook doit vous aider à identifier rapidement le problème d'un problème spécifique et à identifier la meilleure personne pour le gérer.

5. Mettre en place un processus d'astreinte.

Vous avez des propriétaires, des alertes et des runbooks. Souvent, les alertes ne sont pas suffisamment précises pour être mappées directement aux propriétaires. La meilleure pratique consiste à affecter des ingénieurs sur appel à différents secteurs de l'entreprise. Cet ingénieur de garde recevra l'alerte, suivra le runbook, consultera le tableau de bord et tentera de comprendre la cause première. S'ils ne peuvent pas comprendre ou résoudre le problème, ils le signaleront au propriétaire. Gardez à l'esprit que ce processus peut être compliqué ; souvent, un problème survient en raison d'une chaîne d'échecs qui nécessite la collaboration de plusieurs parties prenantes pour résoudre le problème.

6. Avancez vers l'auto-guérison.

Les runbooks sont formidables, mais la maintenance de runbooks complexes et la formation d'ingénieurs sur appel pour les suivre demandent beaucoup d'efforts. Et en fin de compte, votre processus de correction dépend toujours d'un humain lent et sujet aux erreurs. Si votre runbook n'est pas à jour, le suivre peut aggraver la crise.

Théoriquement, un runbook peut être exécuté par programmation. Si le runbook indique "lorsque l'alerte X se déclenche, le processus Y doit redémarrer", un script ou un programme peut recevoir une notification d'alerte X et redémarrer le processus Y. Le même programme peut surveiller le processus Y après le redémarrage, s'assurer que tout va bien, et éventuellement générer un rapport sur l'incident, le tout sans réveiller l'ingénieur de garde. Si l'action d'auto-guérison échoue, l'ingénieur de garde peut être contacté.

7. Établissez un processus post-mortem.

L'auto-guérison est géniale, cependant, une once de prévention vaut mieux que guérir, il est donc préférable de prévenir les problèmes en premier lieu. Chaque incident est l'occasion d'apprendre et éventuellement de prévenir toute une classe de problèmes. Par exemple, si plusieurs incidents se produisent parce que du code bogué se rend en production, alors une leçon à tirer des post-mortems d'incidents pourrait être d'améliorer les tests dans la mise en scène. Si la réponse de l'ingénieur de garde à une alerte était trop lente ou si le runbook était obsolète, cela peut suggérer que l'équipe devrait investir dans certaines pratiques d'auto-réparation.

Conclusion

La surveillance est un élément crucial de l'observabilité en général et de l'observabilité pour la sécurité en particulier. Il n'est pas pratique à grande échelle pour les humains de « regarder de temps en temps » divers tableaux de bord et graphiques pour détecter les problèmes. Vous avez besoin d'un ensemble complet de pratiques de réponse aux incidents qui incluent l'identification des propriétaires, la configuration d'alertes, la rédaction de runbooks, l'automatisation des runbooks et la configuration de processus d'astreinte et de processus post-mortem.

Passez une très bonne journée !