Auditoría de bases de datos en The Grid Parte 2: Observaciones posteriores a la implementación

En la publicación anterior de esta serie, hablé sobre cómo recopilamos los requisitos para este proyecto, cómo tomamos una decisión sobre qué herramienta usar y cómo planificamos la implementación para evitar interrupciones en el servicio. Como se prometió, esta publicación de seguimiento se centra en las observaciones posteriores a la implementación y los factores que hicieron de esta una historia exitosa para nosotros.

Declaraciones preparadas y filtrado de clases de comando

Nuestro diseño inicial para este proyecto pretendía aprovechar una función en el complemento percona que le permite filtrar los eventos emitidos para usar una lista de comandos incluidos o comandos excluidos como una forma de limitar el alcance a lo que realmente necesitamos auditar.

La función se basa en que el complemento marca cada comando sql detectado con una clase basada en una lista inherente a mysql y, a partir de ahí, decide en la capa de salida si la clase de comando detectada debe suprimirse o emitirse.

Así que escribimos el plan inicial para aprovechar la función audit_log_exclude_commands para excluir cualquier comando sql que no causara escrituras o cambios en los datos de fila. Optamos por una lista de exclusión porque sentimos que una lista de inclusión conllevaba el riesgo de perder cualquier clase de comando en el alcance y podría convertirse en una razón para tener lagunas en nuestros registros de auditoría.

Sin embargo, en el primer clúster que probamos, vimos que todos los comandos que se auditaban se clasificaban como errores , aunque estaba claro que estas declaraciones se ejecutaban correctamente y, en caso de cambiar los datos, también lo hacían correctamente. También vimos que todas las consultas se emitían al servidor syslog centralizado, independientemente de la lista de exclusión que parece estar relacionada con esa clasificación de errores.

Esto significaba que estábamos almacenando muchos más eventos en elasticsearch de los que realmente necesitábamos, lo que definitivamente afectará nuestra capacidad para analizar y detectar comportamientos errantes de manera oportuna. Con la colaboración del equipo de seguridad, decidimos informar a Percona del problema a través de su rastreador de errores, pero también trasladar el filtrado basado en comandos a la capa central de syslog.

Como todo en ingeniería, la compensación aquí fue enviar más datos a través de la capa de red de base de datos y hacer que el filtrado en la capa centralizada de syslog sea más complejo y, a cambio, hizo que nuestras necesidades de escalado de búsqueda elástica sean más manejables y la configuración en el lado de la base de datos más simple.

Rendimiento

Una de las decisiones más cruciales en este proyecto que nos ahorró muchos dolores de cabeza es decidir usar la función rsyslog para interceptar y enviar estos registros a un servidor syslog centralizado.

Pero nada está exento de pros y contras.

Esta decisión significó que el tiempo de actividad de un sistema separado y la confiabilidad de la pila de red en el medio se volvieron cruciales para proporcionar el SLA que necesitábamos para darle a nuestro equipo de auditoría la confianza en esta solución de auditoría.

Para aquellos que no estén dispuestos a hacer ese compromiso y necesiten mantener la responsabilidad de la persistencia de los registros de auditoría dentro de la pila de base de datos, recomiendo usar el controlador de ARCHIVO en el complemento de auditoría y luego usar logstash local para tomar los registros y reenviarlos a su sistema de análisis de elección.

Esa última opción significa que se consumen muchos más IOP de disco fuera del proceso de la base de datos y que son absorbidos por el complemento de auditoría y logstash, y significa que debe equilibrar cuidadosamente el espacio en disco en sus instancias entre los archivos de la tabla de la base de datos, los registros operativos y la auditoría. registros de complementos. Sopesar sus opciones depende únicamente de cuál es más fácil de operar/aceptable para la empresa, pero de todos modos tiene opciones.

En nuestro caso, la elección de rsyslog resultó ser la que menos impacto tuvo en nuestras bases de datos más ocupadas, alcanzando un máximo de alrededor de 5400 transacciones por segundo, durante las operaciones normales no vimos ningún impacto en el rendimiento. El complemento de auditoría avanzaba, enviando sus eventos sin afectar el rendimiento de la base de datos. Todo porque habíamos elegido una arquitectura que evitaba consumir operaciones basadas en disco en el lado de la base de datos.

Decisiones pasadas dando sus frutos

Una de las primeras preocupaciones que tuvimos cuando nos embarcamos en este proyecto fue su impacto en el rendimiento. Uno de los clústeres de bases de datos en el alcance ha experimentado tiempos muy ocupados y sus aplicaciones son sensibles al retraso, por lo que necesitábamos asegurarnos de realizar un seguimiento de las métricas de rendimiento, como transacciones por segundo, uso de disco y CPU para comparar números después de implementar el complemento y mira cuál es la pena por eso.

Fue una feliz sorpresa ver que no incurrimos en una gran penalización en las operaciones normales. Como se mencionó anteriormente, debido a que decidimos usar el controlador SYSLOG, significaba que normalmente no necesitábamos usar ninguna capacidad de disco local para rastrear estos eventos de auditoría.

Pero tampoco queríamos planificar en función únicamente de los tiempos de 'operación normal'.

También necesitábamos saber que cuando rsyslog necesita retroceder a los archivos de spool locales, estos eventos no se combinan en cortes que afecten el servicio para los clústeres de base de datos más críticos. Al probar el comportamiento de spooling de rsyslog bajo estrecha vigilancia en producción, nos dimos cuenta de que el trabajo de los últimos años para fragmentar funcionalmente nuestras bases de datos nos ha brindado el beneficio no planificado de una gran cantidad de capacidad de IOP de disco para absorber eventos como el spooling de rsyslog en disco y luego reenviarlo. todos estos eventos.

Definitivamente notamos el aumento en la utilización del disco durante estos eventos, pero nunca llevó las instancias de base de datos a un estado crítico ni afectó la actividad de cara al cliente.

compensaciones

Como todo en la ingeniería de software, siempre hay compensaciones. En este proyecto, consideramos un método de entrega de registros que era más confiable y tenía menos posibilidades de pérdida de registros. Eso implicaría escribir los registros en el disco, luego usar algo como logstash para ingerirlos y enviarlos a destinos de análisis para que los use el equipo de seguridad.

Pero eso habría significado un consumo significativo de IOP de disco en el lado de la base de datos que sabíamos que podría afectar potencialmente la calidad del servicio de las llamadas de los clientes a estas bases de datos.

Decidimos que nuestras necesidades comerciales se cumplirían de manera suficiente mediante el uso de un registro resistente en rsyslog, un spool de tamaño razonable y el uso de TCP para enviar los eventos a nuestra pila de monitoreo de registros. Como todo en la vida, nada es para siempre. Y somos conscientes de que esta decisión puede necesitar ser revisada en el futuro.

Finalmente

Este proyecto, que abarcaba media docena de clústeres y una gran cantidad de instancias, se completó en un solo trimestre mientras el equipo de operaciones de base de datos aún mantenía las luces encendidas en un negocio que aún estaba en rápido crecimiento. Eso no podría haber sucedido sin una estrecha colaboración entre el DBE y el equipo de seguridad y no sin una sólida gestión de productos que mantuvo el alcance finito y conocido para garantizar que todos mantuviéramos nuestros ojos en el objetivo final de hacer que nuestro negocio sea más seguro.