sql >> Base de Datos >  >> RDS >> MariaDB

SQL Firewall simplificado con ClusterControl y ProxySQL

Leer el título de esta publicación de blog puede generar algunas preguntas. Cortafuegos SQL:¿qué es eso? ¿Qué hace? ¿Por qué necesitaría algo así en primer lugar? Bueno, la capacidad de bloquear ciertas consultas podría ser útil en ciertas situaciones. Al usar ProxySQL frente a sus servidores de base de datos, el proxy puede inspeccionar todas las declaraciones SQL que se envían. ProxySQL tiene un motor de reglas sofisticado y puede hacer coincidir las consultas que deben permitirse, bloquearse, reescribirse sobre la marcha o enrutarse a un servidor de base de datos específico. Veamos algunos ejemplos.

Tiene un esclavo dedicado que utilizan los desarrolladores para probar sus consultas con los datos de producción. Desea asegurarse de que los desarrolladores solo puedan conectarse a ese host en particular y ejecutar solo consultas SELECT.

Otro caso, digamos que encontró demasiados accidentes con personas que ejecutan cambios de esquema y le gustaría limitar qué usuarios pueden ejecutar la instrucción ALTER.

Finalmente, pensemos en un enfoque paranoico en el que los usuarios pueden ejecutar solo un conjunto de consultas predefinidas en la lista blanca.

En nuestro entorno tenemos una configuración de replicación con el maestro y dos esclavos.

Frente a nuestras bases de datos, tenemos tres nodos ProxySQL con Keepalived administrando IP Virtual. También tenemos configurado el clúster de ProxySQL (como se explicó en este blog anterior), por lo que no tenemos que preocuparnos por realizar cambios en la configuración o en las reglas de consulta tres veces en los tres nodos de ProxySQL. Para las reglas de consulta, se configura una simple división de lectura y escritura:

Echemos un vistazo a cómo ProxySQL, con su amplio mecanismo de reglas de consulta, puede ayudarnos a lograr nuestros objetivos en los tres casos.

Bloquear el acceso de los usuarios a un solo grupo de host

Un esclavo dedicado disponible para los desarrolladores:esta práctica no es poco común. Siempre que sus desarrolladores puedan acceder a los datos de producción (y si no están permitidos, por ejemplo, por razones de cumplimiento, el enmascaramiento de datos como se explica en nuestro tutorial de ProxySQL puede ayudar), esto puede ayudarlos a probar y optimizar las consultas en los datos del mundo real. colocar. También puede ayudar a verificar los datos antes de ejecutar algunos de los cambios de esquema. Por ejemplo, ¿mi columna es realmente única antes de agregar un índice único?

Con ProxySQL es bastante fácil restringir el acceso. Para empezar, supongamos que el grupo de host 30 contiene el esclavo al que queremos que accedan los desarrolladores.

Necesitamos un usuario que será utilizado por los desarrolladores para acceder a ese esclavo. Si ya lo tiene en ProxySQL, está bien. De lo contrario, es posible que deba importarlo a ProxySQL (si se creó en MySQL pero no en ProxySQL) o crearlo en ambas ubicaciones (si va a crear un nuevo usuario). Vamos con la última opción, creando un nuevo usuario.

Vamos a crear un nuevo usuario con privilegios limitados tanto en MySQL como en ProxySQL. Lo usaremos en las reglas de consulta para identificar el tráfico proveniente de los desarrolladores.

En esta regla de consulta, vamos a redirigir todas las consultas ejecutadas por el usuario dev_test al grupo de host 30. Queremos que esta regla esté activa y debería ser la última en analizarse, por lo tanto, habilitamos 'Aplicar'. También configuramos RuleID para que sea más pequeño que el ID de la primera regla existente, ya que queremos que esta consulta se ejecute fuera de la configuración de división de lectura/escritura normal.

Como puede ver, usamos un nombre de usuario pero también hay otras opciones.

Si puede predecir qué hosts de desarrollo enviarán el tráfico a la base de datos (por ejemplo, puede hacer que los desarrolladores usen un proxy específico antes de que puedan acceder a la base de datos), también puede usar la opción "Dirección del cliente" para hacer coincidir las consultas ejecutadas por ese único host y redirigirlos a un grupo de host correcto.

Prohibir que el usuario ejecute ciertas consultas

Ahora, consideremos el caso en el que queremos limitar la ejecución de algunos comandos en particular a un usuario determinado. Esto podría ser útil para garantizar que las personas adecuadas puedan ejecutar algunas de las consultas que afectan el rendimiento, como los cambios de esquema. ALTER será la consulta que usaremos en este ejemplo. Para empezar, agreguemos un nuevo usuario al que se le permitirá ejecutar cambios de esquema. Lo llamaremos 'admin_user'. A continuación, debemos crear las reglas de consulta requeridas.

Crearemos una regla de consulta que use la expresión regular '.*ALTER TABLE.*' para hacer coincidir las consultas. Esta regla de consulta debe ejecutarse antes que otras reglas divididas de lectura/escritura. Le asignamos un ID de regla de 20. Definimos un mensaje de error que se devolverá al cliente en caso de que se active esta regla de consulta. Una vez hecho esto, procedemos a otra regla de consulta.

Aquí usamos la misma expresión regular para capturar la consulta, pero no definimos ningún texto de error (lo que significa que la consulta no devolverá un error). También definimos qué usuario puede ejecutarlo (admin_user en nuestro caso). Nos aseguramos de que esta consulta se verifique antes que la anterior, por lo que le asignamos un ID de regla inferior de 19.

Una vez que estas dos reglas de consulta estén en su lugar, podemos probar cómo funcionan. Intentemos iniciar sesión como usuario de la aplicación y ejecutar una consulta ALTER TABLE:

[email protected]:~# mysql -P6033 -usbtest -ppass -h10.0.0.111
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 43160
Server version: 5.5.30 (ProxySQL)

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> use sbtest;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> alter table sbtest1 add index (pad);
ERROR 1148 (42000): You are not allowed to execute ALTER
mysql> ^DBye

Como era de esperar, no pudimos ejecutar esta consulta y recibimos un mensaje de error. Ahora intentemos conectarnos usando nuestro 'admin_user':

[email protected]:~# mysql -P6033 -uadmin_user -ppass -h10.0.0.111
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 43180
Server version: 5.5.30 (ProxySQL)

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> use sbtest;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> alter table sbtest1 add index (pad);
Query OK, 0 rows affected (0.99 sec)
Records: 0  Duplicates: 0  Warnings: 0

Logramos ejecutar ALTER cuando iniciamos sesión usando 'admin_user'. Esta es una forma muy sencilla de garantizar que solo las personas designadas puedan ejecutar cambios de esquema en sus bases de datos.

Crear una lista blanca de consultas permitidas

Finalmente, consideremos un entorno estrictamente cerrado donde solo se pueden ejecutar consultas predefinidas. ProxySQL se puede utilizar fácilmente para implementar dicha configuración.

En primer lugar, debemos eliminar todas las reglas de consulta existentes antes de poder implementar lo que necesitamos. Luego, necesitamos crear una regla de consulta catch-all, que bloqueará todas las consultas:

El resto que tenemos que hacer es crear reglas de consulta para todas las consultas permitidas. Puede hacer una regla por consulta. O puede usar expresiones regulares si, por ejemplo, los SELECT siempre están bien para ejecutar. Lo único que debe recordar es que el ID de la regla debe ser más pequeño que el ID de la regla de esta regla general y asegurarse de que la consulta finalmente llegue a la regla con la opción "Aplicar" habilitada.

Esperamos que esta publicación de blog le haya dado una idea de cómo puede utilizar ClusterControl y ProxySQL para mejorar la seguridad y garantizar el cumplimiento de sus bases de datos.