Seguridad de una base de datos en MySQL: usuarios y permisos

Hola, ¿cómo están? Continuando con el curso de MySQL, hoy veremos seguridad. Va temprano en el curso a propósito: es mucho más fácil crear bien los usuarios desde el principio que corregirlo con el sistema en producción.

¡Empecemos!

El error que casi todos cometen

Instalas MySQL, te conectas como root, y desde ahí haces todo. Y cuando llega el momento de programar, pones esas mismas credenciales en la aplicación:

<?php
$pdo = new PDO($dsn, 'root', '');

Eso es un problema serio, y por dos motivos.

Primero: root puede hacer absolutamente todo, incluido borrar bases de datos enteras. Si alguien logra inyectar SQL en tu aplicación, no le has puesto ningún límite.

Segundo: root sin contraseña, que es como viene XAMPP, significa que cualquiera con acceso al servidor entra sin resistencia.

El principio del mínimo privilegio

La regla que gobierna todo lo demás:

Cada usuario debe tener exactamente los permisos que necesita, y ni uno más.

Tu aplicación web necesita leer e insertar registros. No necesita crear tablas, ni borrar bases de datos, ni gestionar usuarios. Si le das solo lo que usa, un ataque exitoso tiene un techo.

Crear un usuario

CREATE USER 'app_tienda'@'localhost'
IDENTIFIED BY 'una-clave-larga-y-aleatoria';

Fíjate en las dos partes del nombre: usuario y host. 'app_tienda'@'localhost' solo puede conectarse desde el propio servidor. Es distinto de 'app_tienda'@'%', que puede conectarse desde cualquier lugar.

Usa siempre localhost salvo que realmente necesites conexiones remotas. Un usuario con % es una puerta abierta a internet.

Conceder permisos con GRANT

GRANT SELECT, INSERT, UPDATE, DELETE
ON tienda.*
TO 'app_tienda'@'localhost';

FLUSH PRIVILEGES;

Esto le da los cuatro permisos básicos —consultar, insertar, actualizar y eliminar— solo sobre la base tienda. No puede tocar ninguna otra.

FLUSH PRIVILEGES recarga la tabla de permisos.

Los permisos más habituales

Permiso	Qué autoriza
SELECT	Consultar datos
INSERT	Agregar registros
UPDATE	Modificar registros
DELETE	Eliminar registros
CREATE	Crear tablas y bases
DROP	Eliminar tablas y bases
ALTER	Modificar estructura
ALL PRIVILEGES	Todo

Evita ALL PRIVILEGES salvo para tu usuario de administración personal.

Permisos a nivel de tabla

Se puede afinar aún más:

GRANT SELECT ON tienda.productos TO 'consulta'@'localhost';
GRANT SELECT (nombre, precio) ON tienda.productos TO 'consulta'@'localhost';

La segunda línea concede acceso solo a dos columnas. Útil para un usuario de reportes que no debe ver datos sensibles.

Un esquema de usuarios sensato

Para un proyecto real, tres usuarios:

-- 1. La aplicación web: solo lo que usa a diario
CREATE USER 'app'@'localhost' IDENTIFIED BY '...';
GRANT SELECT, INSERT, UPDATE, DELETE ON tienda.* TO 'app'@'localhost';

-- 2. Migraciones y despliegues: puede cambiar la estructura
CREATE USER 'deploy'@'localhost' IDENTIFIED BY '...';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP, INDEX
ON tienda.* TO 'deploy'@'localhost';

-- 3. Reportes: solo lectura
CREATE USER 'reportes'@'localhost' IDENTIFIED BY '...';
GRANT SELECT ON tienda.* TO 'reportes'@'localhost';

FLUSH PRIVILEGES;

Con este esquema, una inyección SQL en la aplicación no puede borrar tablas: el usuario app simplemente no tiene ese permiso.

Revisar y quitar permisos

-- Ver qué permisos tiene un usuario
SHOW GRANTS FOR 'app'@'localhost';

-- Listar usuarios
SELECT user, host FROM mysql.user;

-- Quitar un permiso
REVOKE DELETE ON tienda.* FROM 'app'@'localhost';

-- Eliminar un usuario
DROP USER 'antiguo'@'localhost';

Revisa periódicamente SELECT user, host FROM mysql.user. En sistemas con años suelen aparecer usuarios de gente que ya no está, o de pruebas que nadie borró.

Cambiar contraseñas

ALTER USER 'app'@'localhost' IDENTIFIED BY 'nueva-clave';
FLUSH PRIVILEGES;

Y lo primero que deberías hacer tras instalar MySQL:

ALTER USER 'root'@'localhost' IDENTIFIED BY 'una-clave-fuerte';

Buenas prácticas de contraseñas

• Largas y aleatorias. Generadas, no inventadas. Nadie va a escribirlas a mano: van en un archivo de configuración.
• Distintas para cada usuario y cada entorno. La de producción no puede ser la misma que la de desarrollo.
• Nunca en el código. Como vimos en seguridad de PHP: archivo de configuración aparte, fuera del repositorio.

Otras medidas importantes

Elimina los usuarios anónimos. Algunas instalaciones antiguas los crean:

DELETE FROM mysql.user WHERE User = '';
FLUSH PRIVILEGES;

No expongas el puerto 3306 a internet. Si la aplicación y la base están en el mismo servidor, MySQL no necesita escuchar fuera. Es de las configuraciones que más ataques evita.

Mantén MySQL actualizado. Las versiones sin soporte acumulan vulnerabilidades conocidas.

Elimina la base de datos de ejemplo si tu instalación trae test.

Copias de seguridad

La seguridad no es solo impedir accesos: es poder recuperarte.

# Respaldar una base de datos
mysqldump -u root -p tienda > respaldo_tienda.sql

# Restaurar
mysql -u root -p tienda < respaldo_tienda.sql

Tres reglas sobre respaldos:

1. Automatízalos. Un respaldo manual es un respaldo que algún día no se hace.
2. Guárdalos fuera del servidor. Si se pierde el servidor, se pierden los respaldos que estaban en él.
3. Prueba la restauración. Un respaldo que nunca se probó no es un respaldo: es una suposición.

Ese tercer punto es el que más se ignora, y el que más disgustos da.

Errores comunes

• Usar root en la aplicación.
• Dejar root sin contraseña.
• Crear usuarios con % como host sin necesitarlo.
• Conceder ALL PRIVILEGES por comodidad.
• No tener respaldos, o no haberlos probado nunca.
• Guardar las credenciales en el código.

Para cerrar

La seguridad en MySQL se resume en dos ideas: un usuario por función, con los permisos justos, y respaldos automáticos que hayas probado restaurar.

Configurarlo al principio toma quince minutos. Corregirlo después de un incidente toma bastante más.

En las dos siguientes lecciones veremos cómo hacer todo esto con interfaz gráfica: primero en phpMyAdmin y después en MySQL Workbench.

Saludos y éxitos.