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

Cómo proteger el clúster de Galera:8 consejos

Como sistema de base de datos distribuida, Galera Cluster requiere medidas de seguridad adicionales en comparación con una base de datos centralizada. Los datos se distribuyen en varios servidores o incluso en centros de datos, tal vez. Con una importante comunicación de datos entre nodos, puede haber una exposición significativa si no se toman las medidas de seguridad adecuadas.

En esta publicación de blog, vamos a ver algunos consejos sobre cómo asegurar nuestro Galera Cluster. Tenga en cuenta que este blog se basa en nuestra publicación de blog anterior:Cómo proteger sus bases de datos de código abierto con ClusterControl.

Grupo de seguridad y cortafuegos

Los siguientes puertos son muy importantes para un Galera Cluster:

  • 3306 - MySQL
  • 4567 - Comunicación y replicación de Galera
  • 4568 - Galera IST
  • 4444 - Galera SST

Desde la red externa, se recomienda abrir solo el acceso al puerto MySQL 3306. Los otros tres puertos se pueden cerrar desde la red externa, y solo les permite el acceso interno entre los nodos de Galera. Si está ejecutando un proxy inverso sentado frente a los nodos de Galera, por ejemplo, HAProxy, puede bloquear el acceso público al puerto MySQL. Asegúrese también de que el puerto de supervisión para el script de supervisión de HAProxy esté abierto. El puerto predeterminado es 9200 en el nodo Galera.

El siguiente diagrama ilustra nuestra configuración de ejemplo en un clúster Galera de tres nodos, con un HAProxy frente a la red pública con sus puertos relacionados:

Según el diagrama anterior, los comandos de iptables para los nodos de la base de datos son:

$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 3306 -j ACCEPT
$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 4444 -j ACCEPT
$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dports 4567:4568 -j ACCEPT
$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 9200 -j ACCEPT

Mientras está en el balanceador de carga:

$ iptables -A INPUT -p tcp --dport 3307 -j ACCEPT

Asegúrese de finalizar sus reglas de firewall con denegar todo, de modo que solo se permita el tráfico definido en las reglas de excepción. Puede ser más estricto y ampliar los comandos para seguir su política de seguridad, por ejemplo, agregando una interfaz de red, dirección de destino, dirección de origen, estado de conexión y demás.

Cifrado cliente-servidor MySQL

MySQL admite el cifrado entre el cliente y el servidor. Primero tenemos que generar el certificado. Una vez configurado, puede hacer que las cuentas de usuario especifiquen ciertas opciones para conectarse con cifrado a un servidor MySQL.

Los pasos requieren que:

  1. Cree una clave para la autoridad certificadora (ca-key.pem)
  2. Generar un certificado de CA autofirmado (ca-cert.pem)
  3. Cree una clave para el certificado del servidor (server-key.pem)
  4. Generar un certificado para el servidor y firmarlo con ca-key.pem (server-cert.pem)
  5. Cree una clave para el certificado de cliente (client-key.pem)
  6. Generar un certificado para el cliente y firmarlo con ca-key.pem (client-cert.pem)

Siempre tenga cuidado con la clave privada de CA (ca-key.pem):cualquier persona con acceso a ella puede usarla para generar certificados de servidor o cliente adicionales que se aceptarán como legítimos cuando la verificación de CA esté habilitada. La conclusión es que todas las llaves deben mantenerse discretas.

Luego puede agregar las variables relacionadas con SSL bajo la directiva [mysqld], por ejemplo:

ssl-ca=/etc/ssl/mysql/ca-cert.pem
ssl-cert=/etc/ssl/mysql/server-cert.pem
ssl-key=/etc/ssl/mysql/server-key.pem

Reinicie el servidor MySQL para cargar los cambios. Luego cree un usuario con la instrucción REQUIRE SSL, por ejemplo:

mysql> GRANT ALL PRIVILEGES ON db1.* TO 'dbuser'@'192.168.1.100' IDENTIFIED BY 'mySecr3t' REQUIRE SSL;

Se obligará al usuario creado con REQUIRE SSL a conectarse con los archivos SSL de cliente correctos (client-cert.pem, client-key.pem y ca-cert.pem).

Con ClusterControl, el cifrado SSL cliente-servidor se puede habilitar fácilmente desde la interfaz de usuario mediante la función "Crear cifrado SSL".

Cifrado de Galera

Habilitar el cifrado para Galera significa que IST también se cifrará porque la comunicación se realiza a través del mismo socket. SST, por otro lado, debe configurarse por separado como se muestra en la siguiente sección. Todos los nodos del clúster deben estar habilitados con el cifrado SSL y no puede tener una combinación de nodos en los que algunos tengan habilitado el cifrado SSL y otros no. El mejor momento para configurar esto es al configurar un nuevo clúster. Sin embargo, si necesita agregar esto en un sistema de producción en ejecución, lamentablemente deberá reiniciar el clúster y habrá tiempo de inactividad.

Todos los nodos de Galera en el clúster deben usar la misma clave, certificado y CA (opcional). También puede usar la misma clave y certificado creados para el cifrado cliente-servidor de MySQL, o generar un nuevo conjunto solo para este propósito. Para activar el cifrado dentro de Galera, se debe agregar la opción y el valor en wsrep_provider_options dentro del archivo de configuración de MySQL en cada nodo de Galera. Por ejemplo, considere la siguiente línea existente para nuestro nodo Galera:

wsrep_provider_options = "gcache.size=512M; gmcast.segment=0;"

Agregue las variables relacionadas dentro de la cita, delimitadas por un punto y coma:

wsrep_provider_options = "gcache.size=512M; gmcast.segment=0; socket.ssl_cert=/etc/mysql/cert.pem; socket.ssl_key=/etc/mysql/key.pem;"

Para obtener más información sobre los parámetros relacionados con SSL de Galera, consulte aquí. Realice esta modificación en todos los nodos. Luego, detenga el clúster (un nodo a la vez) y arranque desde el último nodo que se apagó. Puede verificar si SSL se cargó correctamente consultando el registro de errores de MySQL:

2018-01-19T01:15:30.155211Z 0 [Note] WSREP: gcomm: connecting to group 'my_wsrep_cluster', peer '192.168.10.61:,192.168.10.62:,192.168.10.63:'
2018-01-19T01:15:30.159654Z 0 [Note] WSREP: SSL handshake successful, remote endpoint ssl://192.168.10.62:53024 local endpoint ssl://192.168.10.62:4567 cipher: AES128-SHA compression:

Con ClusterControl, el cifrado de Galera Replication se puede habilitar fácilmente mediante la función "Crear SSL Galera Encryption".

Cifrado SST

Cuando SST ocurre sin encriptación, la comunicación de datos queda expuesta mientras el proceso SST está en curso. SST es un proceso completo de sincronización de datos de un donante a un nodo de unión. Si un atacante pudiera "ver" la transmisión de datos completa, la persona obtendría una instantánea completa de su base de datos.

SST con cifrado solo es compatible con los métodos mysqldump y xtrabackup-v2. Para mysqldump, al usuario se le debe otorgar "REQUIERE SSL" en todos los nodos y la configuración es similar al cifrado SSL cliente-servidor estándar de MySQL (como se describe en la sección anterior). Una vez que se activa el cifrado cliente-servidor, cree un nuevo usuario SST con SSL obligatorio:

mysql> GRANT ALL ON *.* TO 'sst_user'@'%' IDENTIFIED BY 'mypassword' REQUIRE SSL;

Para rsync, recomendamos usar galera-secure-rsync, una secuencia de comandos rsync SST segura con SSL para Galera Cluster. Funciona casi exactamente como wsrep_sst_rsync excepto que asegura las comunicaciones reales con SSL usando socat. Genere la clave de cliente/servidor y los archivos de certificado necesarios, cópielos en todos los nodos y especifique "secure_rsync" como el método SST dentro del archivo de configuración de MySQL para activarlo:

wsrep_sst_method=secure_rsync

Para xtrabackup, las siguientes opciones de configuración deben estar habilitadas dentro del archivo de configuración de MySQL bajo la directiva [sst]:

[sst]
encrypt=4
ssl-ca=/path/to/ca-cert.pem
ssl-cert=/path/to/server-cert.pem
ssl-key=/path/to/server-key.pem

No es necesario reiniciar la base de datos. Si Galera selecciona este nodo como donante, estas opciones de configuración se seleccionarán automáticamente cuando Galera inicie el SST.

SELinux

Security-Enhanced Linux (SELinux) es un mecanismo de control de acceso implementado en el kernel. Sin SELinux, solo los métodos tradicionales de control de acceso, como los permisos de archivos o ACL, se utilizan para controlar el acceso de los usuarios a los archivos.

De forma predeterminada, con el modo de cumplimiento estricto habilitado, todo se niega y el administrador tiene que hacer una serie de políticas de excepciones a los elementos del sistema que requieren para funcionar. Deshabilitar SELinux por completo se ha convertido en una mala práctica común para muchas instalaciones basadas en RedHat en la actualidad.

Según las cargas de trabajo, los patrones de uso y los procesos, la mejor manera es crear su propio módulo de políticas de SELinux adaptado a su entorno. Lo que realmente necesita hacer es configurar SELinux en modo permisivo (registrar solo sin imponer) y desencadenar eventos que pueden ocurrir en un nodo de Galera para que SELinux registre. Cuanto más extenso, mejor. Ejemplos de eventos como:

  • Nodo inicial como donante o ensamblador
  • Reiniciar nodo para activar IST
  • Utilice diferentes métodos SST
  • Copia de seguridad y restauración de bases de datos MySQL utilizando mysqldump o xtrabackup
  • Habilitar y deshabilitar registros binarios

Un ejemplo es que si ClusterControl supervisa el nodo de Galera y la función de supervisión de consultas está habilitada, ClusterControl habilitará o deshabilitará la variable de registro de consultas lentas para capturar las consultas de ejecución lenta. Por lo tanto, vería la siguiente negación en audit.log:

$ grep -e denied audit/audit.log | grep -i mysql
type=AVC msg=audit(1516835039.802:37680): avc:  denied  { open } for  pid=71222 comm="mysqld" path="/var/log/mysql/mysql-slow.log" dev="dm-0" ino=35479360 scontext=system_u:system_r:mysqld_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file

La idea es permitir que todas las denegaciones posibles se registren en el registro de auditoría, que luego se puede usar para generar el módulo de políticas usando audit2allow antes de cargarlo en SELinux. Codership ha cubierto esto en detalle en la página de documentación, Configuración de SELinux.

Cuenta SST y privilegios

SST es un proceso de sincronización inicial realizado por Galera. Actualiza un nodo de unión con el resto de los miembros del clúster. Básicamente, el proceso exporta los datos del nodo donante y los restaura en el nodo de unión, antes de que se le permita a la unión ponerse al día con las transacciones restantes de la cola (es decir, aquellas que ocurrieron durante el proceso de sincronización). Se admiten tres métodos SST:

  • mysqldump
  • rsync
  • xtrabackup (o xtrabackup-v2)

Para el uso de mysqldump SST, se requieren los siguientes privilegios:

  • SELECCIONAR, MOSTRAR VISTA, ACTIVAR, BLOQUEAR TABLAS, RECARGAR, ARCHIVO

No vamos a ir más allá con mysqldump porque probablemente no se use a menudo en producción como método SST. Además, es un procedimiento de bloqueo sobre el donante. Rsync suele ser una segunda opción preferida después de xtrabackup debido a un tiempo de sincronización más rápido y menos propenso a errores en comparación con mysqldump. La autenticación SST se ignora con rsync, por lo tanto, puede omitir la configuración de los privilegios de la cuenta SST si rsync es el método SST elegido.

Junto con xtrabackup, se recomiendan los siguientes privilegios para los procedimientos estándar de copia de seguridad y restauración basados ​​en la página de documentación de Xtrabackup:

  • CREAR, CREAR ESPACIO DE MESA, EVENTO, INSERTAR, BLOQUEAR MESA, PROCESAR, RECARGAR, CLIENTE DE REPLICACIÓN, SELECCIONAR, MOSTRAR VISTA, SUPER

Sin embargo, para el uso de SST de xtrabackup, solo importan los siguientes privilegios:

  • PROCESAR, RECARGAR, CLIENTE DE REPLICACIÓN

Por lo tanto, la instrucción GRANT para SST se puede minimizar como:

mysql> GRANT PROCESS,RELOAD,REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost' IDENTIFIED BY '[email protected]@sTr0nG%%P4ssW0rD';

Luego, configure wsrep_sst_auth en consecuencia dentro del archivo de configuración de MySQL:

wsrep_sst_auth = sstuser:[email protected]@sTr0nG%%P4ssW0rD

Solo otorgue el usuario SST para localhost y use una contraseña segura. Evite usar el usuario raíz como cuenta SST, ya que expondría la contraseña raíz dentro del archivo de configuración bajo esta variable. Además, cambiar o restablecer la contraseña raíz de MySQL rompería SST en el futuro.

Reforzamiento de la seguridad de MySQL

Galera Cluster es un complemento de replicación multimaestro para el motor de almacenamiento InnoDB, que se ejecuta en las bifurcaciones MySQL y MariaDB. Por lo tanto, las recomendaciones estándar de refuerzo de seguridad de MySQL/MariaDB/InnoDB también se aplican a Galera Cluster.

Este tema ha sido tratado en numerosas publicaciones de blog. También hemos tratado este tema en las siguientes publicaciones de blog:

  • Diez consejos sobre cómo lograr la seguridad de MySQL y MariaDB
  • Consejos y trucos de ClusterControl:asegurar su instalación de MySQL
  • Cómo proteger sus bases de datos de código abierto con ClusterControl

Las publicaciones de blog anteriores resumen la necesidad de cifrar los datos en reposo y los datos en tránsito, tener complementos de auditoría, pautas generales de seguridad, mejores prácticas de seguridad de red, etc.

Usar un equilibrador de carga

Hay una serie de balanceadores de carga de bases de datos (proxy inverso) que se pueden usar junto con Galera:HAProxy, ProxySQL y MariaDB MaxScale, por nombrar algunos. Puede configurar un balanceador de carga para controlar el acceso a sus nodos de Galera. Es una excelente manera de distribuir la carga de trabajo de la base de datos entre las instancias de la base de datos, así como de restringir el acceso, por ejemplo, si desea desconectar un nodo para realizar tareas de mantenimiento o si desea limitar la cantidad de conexiones abiertas en los nodos de Galera. El equilibrador de carga debería poder poner en cola las conexiones y, por lo tanto, proporcionar cierta protección contra sobrecargas a sus servidores de bases de datos.

ProxySQL, un poderoso proxy inverso de base de datos que comprende MySQL y MariaDB, se puede ampliar con muchas funciones de seguridad útiles, como el firewall de consultas, para bloquear consultas ofensivas del servidor de la base de datos. El motor de reglas de consulta también se puede usar para reescribir consultas incorrectas en algo mejor/más seguro, o redirigirlas a otro servidor que pueda absorber la carga sin afectar ninguno de los nodos de Galera. MariaDB MaxScale también es capaz de bloquear consultas basadas en expresiones regulares con su filtro de firewall de base de datos.

Otra ventaja de tener un balanceador de carga para su Galera Cluster es la capacidad de alojar un servicio de datos sin exponer el nivel de la base de datos a la red pública. El servidor proxy se puede utilizar como host bastión para obtener acceso a los nodos de la base de datos en una red privada. Al tener el clúster de la base de datos aislado del mundo exterior, ha eliminado uno de los vectores de ataque importantes.

Eso es todo. Mantente siempre seguro y protegido.