Configurar l’accés remot segur a MySQL

Quan configures l’accés remot a MySQL pot convertir-se en un forat enorme sense que te’n adonis. Sembla fàcil: obre el port, crea un usuari amb %, i llestos. Però per a que sigui un accés realment segur, has de fixar-te als detalls del teu stack, xarxa, rols d’usuari i l’arquitectura.

1. Què volem aconseguir, realment?

Primer convé definir objectius clars. “Connectar des de fora” es pot fer de diverses maneres:

1. Obrir port 3306 i permetre accés directe.
2. Tunelitzar sobre SSH client–servidor.
3. Fer servir VPN i que el servei quedi dins de la xarxa privada.
4. Servei intermediari (ProxySQL, MySQL Router).

Hi ha riscos diferents en cadascun. Si optes per 1, el treball real és blindar la connexió: xifrat, autenticació, control d’ IP i monitoratge. Si fas servir túnels o VPN, la clau està en automatitzar-lo i detectar fallades. El nivell de risc que estiguis disposat a assumir defineix el camí.

2. Obrir port MySQL: primeres precaucions

Quan et demanen obertura directa de 3306 perquè “el client ho necessita”, el primer és confirmar si aquest client pot fer túnels o fer servir VPN. Si la resposta és “no, només 3306”, llavors:

1. Habilita require_secure_transport = ON en mysqld.cnf para forzar TLS.
2. Genera certificat i clau de host, fins i tot si no fas servir client-cert. Evita certificats autosignats febles: aplica ssl_ciphers = TLSv1.2+, ssl_prefer_server_ciphers = ON i deshabilita protocols obsolets (TLSv1, TLSv1.1).
3. Fes servir usuaris específics per IP: evita ‘user’@’%’. Millor ‘user’@’client-ip’ o ‘user’@’vpn-subnet’.

Un error que es repeteix sovint és tenir bind-address = 0.0.0.0 sense control de firewall. Per defecte MySQL escolta a totes les interfícies. Si el servidor té IP públiques, limites només a la privada i després fas servir regles com ara:

iptables -A INPUT -p tcp --dport 3306 -s X.X.X.X -j ACCEPT
iptables -A INPUT -p tcp --dport 3306 -j DROP

Molts obliden deixar un log de connexions rebutjades (-j LOG) per auditar.

3. Usuaris amb TLS obligatori i evitar %

Un cop activat TLS, els usuaris s’haurien de crear així:

CREATE USER 'reporter'@'10.1.2.%'
  IDENTIFIED BY 's3cure'
  REQUIRE SUBJECT '/C=ES/ST=Catalonia/L=Sabadell/O=MyOrg/CN=client1';
GRANT SELECT ON db.* TO 'reporter'@'10.1.2.%';

Això obliga a que el client presenti un certificat amb el CN adequat, impedint que algú es connecti amb usuari/contrasenya exposats.

Si el client no suporta client-certs, almenys assegura’ t que:

1. validate_password_policy MEDIUM o STRONG.
2. El host no és %.
3. max_connections i max_user_connections estiguin limitats per usuari per prevenir l’ abús.

Un error habitual és que algú faci servir molt %, pensant que serà “menys restrictiu” però en realitat és una porta oberta si no combinen firewall i TLS.

4. Configuració TLS en detall

No n’hi ha prou amb generar ca.pem, server-cert.pem, server-key.pem. Requereix diversos ajustos:

[mysqld]
ssl_ca=/etc/mysql/ssl/ca.pem
ssl_cert=/etc/mysql/ssl/server-cert.pem
ssl_key=/etc/mysql/ssl/server-key.pem
require_secure_transport=ON
ssl_cipher=ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256

Errors freqüents:

1. Claus amb permís incorrecte (chmod 600 i duel mysql:mysql).
2. Arxius en lloc diferent al basedir.
3. No reiniciar MySQL o esborrar caché (FLUSH PRIVILEGES).
4. El client no suporta TLS1.2 per ser una versió vella, així que proves i “funciona” però en realitat no està xifrat.

Per provar:

mysql --ssl-mode=VERIFY_IDENTITY \
      --ssl-ca=ca.pem \
      --ssl-cert=client-cert.pem \
      --ssl-key=client-key.pem \
      -h prod-db -u reporter -p

Si falla en verify identity, el certificat no encaixa amb l’esperat.

5. SSH tunneling: l’opció segura i pràctica

Quan tens control del client i el servidor permet SSH,

ssh -fNL 33306:localhost:3306 myuser@db.host

i després connectes a localhost:33306. Claus SSH amb passphrase, ~/.ssh/config amb ServerAliveInterval, ExitOnForwardFailure yes i -o ControlMaster=auto per a multiplexació. Així redueixes dependència SSL de MySQL, ja que el túnel xifrat és més robust.

El problema més habitual és desconnexió del túnel en xarxes inestables. Per solucionar-ho:

1. Fes servir autossh -M 0 -N -o “ServerAliveInterval 60” -o “ServerAliveCountMax 3”.
2. Escolta només a localhost, mai en 0.0.0.0.
3. Crea el túnel com un servei per a usuari. Exemple /etc/systemd/user/db-tunnel.service.

Si tens dotzenes de clients, fes servir scripting o una plantilla Ansible per a desplegar el túnel.

6. VPN: balanç entre seguretat i complexitat

Si tens VPN IPsec, WireGuard o OpenVPN, pots deixar bind-address = 0.0.0.0 en la interfície privada, i permetre connexions només des de la xarxa VPN.

Avantatge: pots fer servir certificats TLS de MySQL sense rutes públiques.

Desavantatge: problemes com latència, MTU, configuració automàtica en clients, i necessitat de renovació de certificats. Una cosa crítica en entorns grans.

7. Hardening addicional: controls i monitoratge

L’ accés remot s’ ha d’ auditar i monitorar:

1. Habilita general log o audit log per registrar connexions remotes, amb filtres –skip-show-database.
2. Utilitzeu log_error_verbosity=3 o 2.
3. Monitoritza sessions TCP a netstat per a detectar pics.
4. Configura alertes per max_connections o Aborted_connects.
5. Fes servir pt-heartbeat com a heartbeating mínim si depèn d’aplicacions crítiques.

També convé generar automàticament certificats temporals per a entorns de desenvolupament i forçar la seva rotació.

8. Errors comuns en producció

1. Oblidar els usuaris obsolets: revisa mysql.user cada mes i revoca qualsevol connexió des de %.
2. No rotar certificats o no regenerar CA: si algú abandona, pots retirar el seu certificat, però la CA segueix sent vàlida.
3. Oblidar require_secure_transport: així poden entrar en text pla.
4. Deixar el port exposat sense regles de xarxa: encara que l’usuari exigeixi %, el firewall hauria de filtrar.
5. Clients mal configurats que no fan servir TLS: revisa –ssl-mode. No VERIFY_IDENTITY, estàs en perill de MITM.
6. Desconèixer replicació o binlog: si habilites accés remot per a replicació, assegura’t que aquests usuaris tinguin permisos mínims i rotació de binlogs activada.

9. Checklist abans de posar-lo en marxa

1. require_secure_transport=ACTIVAT
2. Certificats amb ciphers strong, permisos correctes.
3. Usuaris amb host específics (client-ip o subnet).
4. Firewall limitant 3306 només a orígens permesos.
5. Rotació de certificats i revocació d’ usuaris documentada.
6. Logs i alertes configurades.
7. Tunnel autossh o VPN per a connexions remotes.
8. Proves de connexió: text clar, TLS broken, client, càrrega.

Conclusió

Aconseguir un accés remot segur a MySQL implica més esforç del que sembla. Moltes vegades es veu només la part visible (crear usuari, obrir port), i s’obliden altres fronts: VPN/TLS sòlid, firewall, aprenentatge de com el servei i la xarxa funcionen en producció, detecció primerenca d’errors.

Qui actua responsablement no deixa buits ni confia en defaults. Manté certificats, revisa usuaris, mesura fallades, documenta les excepcions. Si tot això xoca amb la realitat política de la teva organització, almenys tindràs arguments tècnics fundats per proposar alternatives.