sql >> Base de Datos >  >> RDS >> Mysql

Comprender el registro de auditoría de ProxySQL

ProxySQL se convirtió en una parte muy importante de la infraestructura en los entornos de bases de datos. Funciona como un equilibrador de carga, ayuda a dar forma al flujo del tráfico y reduce el tiempo de inactividad. Con un gran poder viene una gran responsabilidad. ¿Cómo puede mantenerse actualizado sobre quién accede a la configuración de ProxySQL? ¿Quién se conecta a la base de datos a través de ProxySQL? Esas preguntas se pueden responder usando ProxySQL Audit Log, que está disponible a partir de ProxySQL 2.0.5. En esta publicación de blog, veremos cómo habilitar esta función y cómo se ve el contenido del registro.

Los pasos iniciales serán implementar ProxySQL. Podemos hacerlo fácilmente usando ClusterControl:tanto la replicación de MySQL como los tipos de clúster de Galera admiten la implementación de ProxySQL.

Suponiendo que tenemos un clúster en funcionamiento, podemos implementar ProxySQL desde Manage -> LoadBalancers:

Tenemos que decidir en qué nodo instalar ProxySQL, su versión ( mantendremos el valor predeterminado 2.x) y definiremos las credenciales para los usuarios administrativos y de supervisión de ProxySQL.

A continuación, podemos importar usuarios de aplicaciones existentes desde la base de datos o crear una nueva uno asignando nombre, contraseña, esquema y privilegios de MySQL. Luego podemos configurar qué nodos deben incluirse en ProxySQL y decidir si usamos transacciones implícitas o no. Una vez que todo esté hecho, podemos implementar ProxySQL. Para una alta disponibilidad, probablemente desee agregar un segundo ProxySQL y luego mantener vivo encima de ellos. Keepalived también se puede implementar fácilmente desde ClusterControl:

Aquí tenemos que elegir los nodos en los que se implementa ProxySQL, pasar el Virtual Se debe asignar IP y VIP de interfaz de red. Una vez hecho esto, ClusterControl puede implementar Keepalived por usted.

Ahora, echemos un vistazo al registro de auditoría. Todas las configuraciones deben realizarse en ambos nodos ProxySQL. Alternativamente, puede usar una opción para sincronizar los nodos:

Hay dos configuraciones que rigen cómo debe funcionar el registro de auditoría:

El primero define el archivo donde se deben almacenar los datos, el segundo indica el tamaño que debe tener el archivo de registro antes de rotarlo. Configuremos el inicio de sesión en el directorio de datos de ProxySQL:

Ahora, podemos echar un vistazo a los datos que vemos en la auditoría archivo de registro. En primer lugar, el formato en el que se almacenan los datos es JSON. Hay dos tipos de eventos, uno relacionado con la conectividad de MySQL y el segundo relacionado con la conectividad de la interfaz de administración de ProxySQL.

Aquí hay un ejemplo de entradas activadas por el tráfico de MySQL:

  "client_addr": "10.0.0.100:40578",

  "event": "MySQL_Client_Connect_OK",

  "proxy_addr": "0.0.0.0:6033",

  "schemaname": "sbtest",

  "ssl": false,

  "thread_id": 810,

  "time": "2020-01-23 14:24:17.595",

  "timestamp": 1579789457595,

  "username": "sbtest"

}

{

  "client_addr": "10.0.0.100:40572",

  "event": "MySQL_Client_Quit",

  "proxy_addr": "0.0.0.0:6033",

  "schemaname": "sbtest",

  "ssl": false,

  "thread_id": 807,

  "time": "2020-01-23 14:24:17.657",

  "timestamp": 1579789457657,

  "username": "sbtest"

}

{

  "client_addr": "10.0.0.100:40572",

  "creation_time": "2020-01-23 14:24:17.357",

  "duration": "299.653ms",

  "event": "MySQL_Client_Close",

  "extra_info": "MySQL_Thread.cpp:4307:process_all_sessions()",

  "proxy_addr": "0.0.0.0:6033",

  "schemaname": "sbtest",

  "ssl": false,

  "thread_id": 807,

  "time": "2020-01-23 14:24:17.657",

  "timestamp": 1579789457657,

  "username": "sbtest"

}

Como puede ver, la mayoría de los datos se repiten:dirección del cliente, dirección de ProxySQL, nombre del esquema, si se usó SSL en las conexiones, número de hilo relacionado en MySQL, usuario que creó la conexión. El evento "MySQL_Client_Close" también contiene información sobre la hora en que se creó la conexión y la duración de la conexión. También puede ver qué parte del código ProxySQL fue responsable de cerrar la conexión.

Las conexiones de administración son bastante similares:

{

  "client_addr": "10.0.0.100:52056",

  "event": "Admin_Connect_OK",

  "schemaname": "information_schema",

  "ssl": false,

  "thread_id": 815,

  "time": "2020-01-23 14:24:19.490",

  "timestamp": 1579789459490,

  "username": "proxysql-admin"

}

{

  "client_addr": "10.0.0.100:52056",

  "event": "Admin_Quit",

  "schemaname": "information_schema",

  "ssl": false,

  "thread_id": 815,

  "time": "2020-01-23 14:24:19.494",

  "timestamp": 1579789459494,

  "username": "proxysql-admin"

}

{

  "client_addr": "10.0.0.100:52056",

  "creation_time": "2020-01-23 14:24:19.482",

  "duration": "11.795ms",

  "event": "Admin_Close",

  "extra_info": "MySQL_Thread.cpp:3123:~MySQL_Thread()",

  "schemaname": "information_schema",

  "ssl": false,

  "thread_id": 815,

  "time": "2020-01-23 14:24:19.494",

  "timestamp": 1579789459494,

  "username": "proxysql-admin"

}

Los datos recopilados son muy similares, la principal diferencia es que están relacionados con las conexiones a la interfaz administrativa de ProxySQL.

Conclusión

Como ves, de una forma muy sencilla puedes habilitar la auditoría del acceso a ProxySQL. Esto, especialmente el acceso administrativo, es algo que debe monitorearse desde el punto de vista de la seguridad. El complemento de auditoría lo hace bastante fácil de lograr.