Audit des bases de données sur The Grid Partie 2 : Observations post-déploiement

Dans le post précédent de cette série, j'ai expliqué comment nous avons collecté les exigences pour ce projet, comment nous avons décidé quel outil utiliser et comment nous avons planifié le déploiement pour éviter les interruptions de service. Comme promis, ce post de suivi se concentre sur les observations post-déploiement et sur les facteurs qui ont fait de cette histoire une réussite pour nous.

Instructions préparées et filtrage des classes de commandes

Notre conception initiale pour ce projet visait à tirer parti d'une fonctionnalité du plug-in percona qui vous permet de filtrer les événements émis pour utiliser une liste de commandes incluses ou de commandes exclues afin de limiter la portée à ce que nous devons réellement auditer.

La fonctionnalité repose sur le plugin marquant chaque commande sql détectée avec une classe basée sur une liste inhérente à mysql et à partir de là, décidant dans la couche de sortie si la classe de commande détectée doit être supprimée ou émise.

Nous avons donc écrit le plan initial pour tirer parti de la fonctionnalité audit_log_exclude_commands afin d'exclure toutes les commandes sql qui n'ont pas provoqué d'écritures ou de modifications des données de ligne. Nous avons opté pour une liste d'exclusion car nous estimions qu'une liste d'inclusion risquait de manquer des classes de commandes dans la portée et pouvait devenir une raison d'avoir des lacunes dans nos journaux d'audit.

Cependant, sur le premier cluster que nous avons testé, nous avons constaté que toutes les commandes auditées étaient classées comme des erreurs, même s'il était clair que ces instructions s'exécutaient avec succès et, en cas de modification des données, le faisaient également avec succès. Nous avons également vu que toutes les requêtes étaient émises vers le serveur syslog centralisé, quelle que soit cette liste d'exclusion qui semble corrélée à cette classification d'erreur.

Cela signifiait que nous stockions beaucoup plus d'événements dans elasticsearch que nous n'en avions réellement besoin, ce qui aura certainement un impact sur notre capacité à analyser et à détecter les comportements errants en temps opportun. En collaboration avec l'équipe de sécurité, nous avons décidé d'informer Percona du problème via leur outil de suivi des bogues, mais également de déplacer le filtrage basé sur les commandes vers la couche syslog centrale.

Comme tout dans l'ingénierie, le compromis ici était d'envoyer plus de données via la couche réseau DB et de rendre le filtrage dans la couche syslog centralisée plus complexe et en retour, cela rendait nos besoins de mise à l'échelle de la recherche élastique plus gérables et la configuration côté base de données plus simple.

Performance

L'une des décisions les plus cruciales de ce projet qui nous a épargné beaucoup de chagrin est de décider d'utiliser la fonction rsyslog pour piéger et expédier ces journaux vers un serveur syslog centralisé.

Mais rien n'est sans avantages et inconvénients.

Cette décision signifiait que la disponibilité d'un système séparé et la fiabilité de la pile réseau intermédiaire devenaient cruciales pour fournir le SLA dont nous avions besoin pour donner à notre équipe d'audit la confiance dans cette solution d'audit.

Pour ceux qui ne veulent pas faire ce compromis et qui ont besoin de garder la responsabilité de la persistance des journaux d'audit dans la pile de base de données, je recommande d'utiliser le gestionnaire FILE dans le plugin d'audit, puis d'utiliser le logstash local pour prendre les journaux et les transmettre à leur système d'analyse de choix.

Ce dernier choix signifie beaucoup plus d'IOP de disque consommées en dehors du processus de base de données et prises par le plugin d'audit et le logstash et cela signifie que vous devez équilibrer soigneusement l'espace disque sur vos instances entre vos fichiers de table de base de données, les journaux opérationnels et l'audit journaux du plug-in. La pesée de vos options dépend uniquement de ce qui est le plus facile à utiliser/acceptable par l'entreprise, mais vous avez néanmoins des choix.

Dans notre cas, le choix de rsyslog s'est avéré être le moins impactant pour nos bases de données les plus occupées, culminant à environ 5400 transactions/sec, pendant les opérations normales, nous n'avons vu aucun impact sur les performances. Le plug-in d'audit fonctionnait, envoyant ses événements sans impact sur les performances de la base de données. Tout cela parce que nous avions choisi une architecture qui évitait de consommer des opérations sur disque côté base de données.

Les décisions passées portent leurs fruits

L'une des premières préoccupations que nous avons eues lorsque nous nous sommes lancés dans ce projet a été son impact sur la performance. L'un des clusters de bases de données concernés a connu des périodes très chargées et ses applications sont sensibles au décalage, nous devions donc nous assurer que nous gardions une trace des mesures de performances telles que les transactions par seconde, l'utilisation du disque et du processeur afin de comparer les chiffres après le déploiement du plugin et voir quelle est la sanction pour cela.

Ce fut une heureuse surprise de voir que nous n'avons pas encouru beaucoup de pénalités dans les opérations normales. Comme mentionné précédemment, parce que nous avons décidé d'utiliser le gestionnaire SYSLOG, cela signifiait que nous n'avions normalement pas besoin d'utiliser la capacité du disque local pour suivre ces événements d'audit.

Mais nous ne voulions pas non plus planifier en nous basant uniquement sur les heures de « fonctionnement normal ».

Nous devions également savoir que lorsque rsyslog doit se replier sur des fichiers spool locaux, ces événements ne s'aggravent pas en interruptions affectant le service pour les clusters de bases de données les plus critiques. En testant le comportement de mise en file d'attente de rsyslog sous surveillance étroite en production, nous avons réalisé que les dernières années de travail pour partitionner fonctionnellement nos bases de données nous ont valu l'avantage imprévu d'une grande capacité d'IOP de disque pour absorber des événements tels que la mise en file d'attente de rsyslog sur disque puis nécessaire pour renvoyer tous ces événements.

Nous avons certainement noté l'augmentation de l'utilisation du disque lors de ces événements, mais cela n'a jamais amené les instances de base de données à un état critique ni affecté l'activité en contact avec les clients.

Compromis

Comme tout dans le génie logiciel, il y a toujours des compromis. Dans ce projet, nous avons envisagé une méthode de livraison de grumes plus fiable et moins susceptible de perdre des grumes. Cela impliquerait d'écrire les journaux sur le disque, puis d'utiliser quelque chose comme logstash pour les ingérer et les envoyer vers des destinations d'analyse pour que l'équipe de sécurité les utilise.

Mais cela aurait signifié une consommation importante d'IOP de disque du côté de la base de données, ce qui, nous le savions, pourrait potentiellement avoir un impact sur la qualité de service des appels destinés aux clients vers ces bases de données.

Nous avons décidé que nos besoins commerciaux seraient suffisamment satisfaits en utilisant une journalisation résiliente dans rsyslog, en utilisant un spool de taille raisonnable et en utilisant TCP pour envoyer les événements à notre pile de surveillance des journaux. Comme tout dans la vie, rien n'est éternel. Et nous sommes conscients que cette décision devra peut-être être réexaminée à l'avenir.

finalement

Ce projet, bien qu'englobant une demi-douzaine de clusters et un grand nombre d'instances, a été achevé en un seul trimestre alors que l'équipe DB ops continuait à garder les lumières allumées dans une activité toujours en croissance rapide. Cela n'aurait pas pu se produire sans une étroite collaboration entre le DBE et l'équipe de sécurité et non sans une solide gestion des produits qui a gardé la portée limitée et connue pour s'assurer que nous gardons tous nos yeux sur l'objectif final de rendre notre entreprise plus sûre.