# Cómo asegurar MySQL o MariaDB en un servidor Linux

**Categoría:** Linux · **Nivel:** Intermedio · **Lectura:** 19 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/linux/como-asegurar-mysql-o-mariadb-en-un-servidor-linux/

## Respuesta rápida

[Instalar MySQL o MariaDB](../../bases-de-datos/mysql-instalacion-y-primeros-pasos/index.md) y ponerlos a funcionar es fácil; **dejarlos seguros** es lo que marca la diferencia, y lo que mucha gente omite. Una base de datos mal asegurada es una de las **puertas de entrada más habituales** a un servidor: guarda los datos más valiosos y, si queda expuesta o con credenciales débiles, es un objetivo directo. Asegurarla en un servidor Linux se apoya en unos pocos principios. **(1) El asistente de seguridad:** MySQL y MariaDB traen un asistente (el clásico `mysql_secure_installation`) que, en un par de minutos, resuelve los problemas de una instalación recién hecha: pone contraseña al usuario administrador, **elimina los usuarios anónimos**, **deshabilita el acceso remoto del administrador**, y borra la base de datos de prueba. Ejecutarlo es el primer paso, siempre. **(2) El principio de privilegio mínimo:** la regla de oro de la seguridad de bases de datos. Cada aplicación que use la base de datos debe tener **su propio usuario**, con acceso **solo a su base de datos** y **solo a los permisos que necesita** —nunca el usuario administrador para todo—. Así, si esa aplicación se ve comprometida, el atacante no obtiene control total, sino solo lo que tenía ese usuario limitado. **(3) Limitar el acceso a la red:** una base de datos rara vez debe estar expuesta a internet. Lo correcto es que **solo escuche en local** (o en la red interna) y que sea la *aplicación*, no el mundo, quien se conecte a ella; el cortafuegos y la configuración de *bind* lo aseguran. Con esos tres pilares —asistente, privilegio mínimo y acceso restringido— más las buenas prácticas de todo servidor (actualizar, contraseñas fuertes, backups), una base de datos queda razonablemente protegida. Esta guía se centra en el **endurecimiento** tras la instalación; el uso y el diseño de la base de datos son temas aparte.

## Por qué asegurarla

La base de datos es, casi siempre, **lo más valioso** de un servidor: ahí viven los datos de los usuarios, los pedidos, el contenido, todo. Por eso es un **objetivo prioritario** para un atacante, y por eso una base de datos mal asegurada es una de las vías de compromiso más frecuentes. El problema es que la fase de [instalación](../../bases-de-datos/mysql-instalacion-y-primeros-pasos/index.md) deja el sistema **funcional pero no seguro**: una instalación recién hecha suele tener usuarios de prueba, accesos de más y configuraciones pensadas para «que funcione», no para «que esté protegido». Cerrar esa brecha entre «funciona» y «está seguro» es el trabajo de endurecimiento que cubre esta guía.

> **Instalar no es asegurar**
>
> Es útil separar dos cosas que a menudo se confunden. **Instalar y usar** una base de datos —ponerla en marcha, crear tablas, hacer consultas— es una cosa, y tiene su propia [guía de primeros pasos](../../bases-de-datos/mysql-instalacion-y-primeros-pasos/index.md). **Asegurarla** es otra: es endurecer esa instalación para que resista un entorno hostil —internet, usuarios malintencionados, aplicaciones que pueden tener fallos—. Una base de datos puede estar perfectamente instalada y funcionando y, a la vez, ser un colador de seguridad. Esta guía se ocupa exactamente de esa segunda parte, la que convierte una base de datos «que funciona» en una «que funciona y está protegida», y que muchos administradores noveles pasan por alto.

## Los pasos clave

Los dos primeros pilares, en detalle:

| Pilar | Qué resuelve |
|---|---|
| Asistente de seguridad | Contraseña de admin, sin usuarios anónimos, sin admin remoto, sin base de prueba |
| Privilegio mínimo | Un usuario por aplicación, con acceso solo a su base y solo a sus permisos |

> **Atención**
>
> Si hay que quedarse con una sola idea de seguridad de bases de datos, es el **principio de privilegio mínimo**: cada quien tiene **solo los permisos que necesita, y ni uno más**. En la práctica, esto significa que **nunca** se usa el usuario administrador (que puede todo) para el día a día ni para que se conecten las aplicaciones. En su lugar, cada aplicación tiene **su propio usuario**, con acceso **solo a la base de datos que usa** y **solo a las operaciones que necesita** —muchas apps solo necesitan leer y escribir en unas tablas, no borrar bases enteras ni crear usuarios—. La razón es de **contención del daño**: si una aplicación tiene un fallo de seguridad y un atacante logra ejecutar consultas a través de ella, solo podrá hacer lo que ese usuario limitado permita. Con un usuario todopoderoso, el mismo fallo le daría **control total** de la base de datos. Es el mismo principio de privilegio mínimo que ordena los [permisos de archivos en Linux](../permisos-y-propietarios-de-archivos-en-linux/index.md): dar lo justo, nunca de más.

## Acceso y red

El tercer pilar es **controlar desde dónde se accede** a la base de datos. La regla general: una base de datos **no debe estar expuesta a internet**.

- **Que escuche solo donde debe.** Configurar la base para que escuche en *localhost* (si la app está en el mismo servidor) o en la red interna, no en todas las interfaces.
- **El cortafuegos, cerrado por defecto.** El puerto de la base de datos no debe estar abierto a internet; solo accesible desde donde vive la aplicación.
- **La app se conecta, no el mundo.** Quien habla con la base de datos es la aplicación, con su usuario limitado; nadie más debería poder alcanzarla.
- **Cifrar si el tráfico cruza redes.** Si la app y la base están en máquinas distintas por una red no confiable, cifrar la conexión.

> **Atención**
>
> Una parte enorme de las grandes filtraciones de datos tiene el mismo origen: una **base de datos accesible desde internet**, a menudo sin contraseña o con una débil. Herramientas de rastreo escanean internet buscando precisamente eso, y lo encuentran a diario. Por eso la regla es tan tajante: la base de datos **vive detrás**, escuchando solo donde hace falta, y el **cortafuegos** le cierra la puerta al exterior. Combiná esto con el resto del [endurecimiento del servidor](../administracion-de-servidores-linux-desde-cero/index.md) —el acceso administrativo por [SSH protegido](../fail2ban-para-proteger-ssh-de-ataques-de-fuerza-bruta/index.md), actualizaciones, contraseñas fuertes— y con **backups** de la base de datos (que son, además, tu red de seguridad ante un incidente). Asegurar la base de datos no es una tarea aislada: es una pieza del endurecimiento integral del servidor, y una de las más importantes por lo que hay en juego.

## Errores frecuentes

- **Saltarse el asistente de seguridad.** Deja usuarios anónimos, admin remoto y base de prueba; ejecutarlo siempre tras instalar.
- **Usar el usuario administrador para las aplicaciones.** Un fallo en la app daría control total; cada app con su usuario limitado.
- **Exponer la base de datos a internet.** Es la causa de innumerables filtraciones; que escuche solo donde debe.
- **Dar permisos de más «por comodidad».** El privilegio mínimo significa solo lo necesario, aunque cueste un poco más configurarlo.
- **Dejar la contraseña de admin por defecto o vacía.** Es lo primero que prueba un atacante; contraseña fuerte y única.
- **No hacer backups de la base de datos.** Ante un incidente o un borrado, es la única red de seguridad.
- **Confundir asegurar con instalar.** Una base instalada y funcionando puede seguir siendo insegura; hay que endurecerla.

## Preguntas frecuentes

**¿Por qué hay que asegurar MySQL o MariaDB después de instalarlo?**
Hay que asegurar MySQL o MariaDB después de instalarlo porque una instalación recién hecha queda funcional pero no segura, y una base de datos mal asegurada es una de las puertas de entrada más habituales a un servidor, dado que contiene los datos más valiosos y es un objetivo prioritario para los atacantes. La base de datos suele ser lo más valioso de un servidor, ya que en ella residen los datos de los usuarios, los pedidos, el contenido y, en general, la información crítica del sistema o de la aplicación. Precisamente por ese valor, es un objetivo prioritario para quien quiera comprometer un servidor, y una base de datos que no se ha asegurado adecuadamente se convierte en una vía de ataque frecuente y peligrosa. El problema de fondo es que el proceso de instalación de una base de datos deja el sistema en un estado funcional pero no seguro, es decir, la base de datos funciona y se puede usar, pero conserva una serie de elementos y configuraciones que suponen riesgos de seguridad. Entre ellos, es habitual que una instalación recién hecha tenga usuarios de prueba o anónimos, que permita accesos que no deberían estar habilitados, como el acceso remoto del usuario administrador, que incluya una base de datos de prueba, y que en algunos casos el usuario administrador ni siquiera tenga una contraseña establecida o tenga una débil. Todas estas condiciones están pensadas para que la base de datos funcione fácilmente nada más instalarla, pero no para que esté protegida frente a un entorno hostil como internet. Por ello, existe una brecha entre que una base de datos funcione y que esté segura, y cerrar esa brecha es el trabajo de endurecimiento que hay que realizar tras la instalación. Es importante entender que instalar y usar una base de datos es una tarea distinta de asegurarla, y que una base de datos puede estar perfectamente instalada y en funcionamiento y, al mismo tiempo, ser muy insegura. Asegurarla implica aplicar una serie de medidas, como ejecutar el asistente de seguridad que resuelve los problemas de la instalación inicial, aplicar el principio de privilegio mínimo en los usuarios y permisos, limitar el acceso a la red para que la base de datos no esté expuesta a internet, y seguir las buenas prácticas generales de todo servidor. Solo tras aplicar estas medidas la base de datos pasa de estar simplemente instalada a estar instalada y protegida.

**¿Qué hace el asistente de seguridad de MySQL o MariaDB?**
El asistente de seguridad de MySQL y MariaDB es una herramienta que se ejecuta tras la instalación de la base de datos y que, en unos pocos minutos y de forma guiada, resuelve los principales problemas de seguridad que presenta una instalación recién hecha, siendo el primer paso imprescindible del proceso de endurecimiento. Este asistente, que se invoca mediante un comando específico proporcionado por la propia base de datos, plantea al administrador una serie de preguntas y aplica una serie de cambios que corrigen las configuraciones inseguras predeterminadas. Entre las acciones más importantes que realiza se encuentran las siguientes. En primer lugar, establece o refuerza la contraseña del usuario administrador, que es la cuenta con el máximo nivel de privilegios sobre la base de datos, asegurándose de que esté protegida por una contraseña robusta, ya que una instalación puede dejar esta cuenta sin contraseña o con una débil, lo que sería un grave riesgo. En segundo lugar, elimina los usuarios anónimos, que son cuentas sin nombre de usuario que algunas instalaciones crean y que permitirían el acceso a la base de datos sin identificarse, constituyendo una puerta abierta que debe cerrarse. En tercer lugar, deshabilita el acceso remoto del usuario administrador, de modo que la cuenta con todos los privilegios solo pueda usarse desde el propio servidor y no a través de la red, lo que reduce enormemente el riesgo de que alguien intente acceder a ella desde el exterior. En cuarto lugar, elimina la base de datos de prueba que se crea por defecto en algunas instalaciones y que cualquiera podría utilizar. Y por último, recarga los privilegios para que todos estos cambios surtan efecto de inmediato. Ejecutar este asistente es una operación rápida y sencilla que conviene realizar siempre inmediatamente después de instalar la base de datos, ya que resuelve de golpe varios de los problemas de seguridad más comunes de una instalación inicial. No obstante, es importante entender que el asistente de seguridad es solo el primer paso del endurecimiento, y que por sí solo no deja la base de datos completamente segura, sino que debe complementarse con la aplicación del principio de privilegio mínimo en la creación de usuarios y permisos, con la limitación del acceso a la red para que la base de datos no esté expuesta a internet, y con las buenas prácticas generales de administración de servidores.

**¿Qué es el principio de privilegio mínimo en bases de datos?**
El principio de privilegio mínimo es la regla fundamental de la seguridad de bases de datos, y establece que cada usuario o aplicación debe tener únicamente los permisos que necesita para realizar su función, y ni uno más, evitando en particular el uso del usuario administrador todopoderoso para las tareas cotidianas y las conexiones de las aplicaciones. En la práctica, aplicar este principio en una base de datos significa que no se debe utilizar la cuenta del administrador, que tiene control total sobre todo el sistema de bases de datos, para el trabajo diario ni para que se conecten las aplicaciones que usan la base de datos. En su lugar, cada aplicación debe tener su propio usuario dedicado, creado específicamente para ella, con acceso exclusivamente a la base de datos que esa aplicación utiliza, y con permisos limitados únicamente a las operaciones que realmente necesita realizar. Por ejemplo, muchas aplicaciones solo necesitan leer y escribir datos en ciertas tablas, por lo que su usuario debería tener solo esos permisos, y no otros más peligrosos como el de eliminar bases de datos completas, modificar la estructura de las tablas o crear nuevos usuarios. La razón de ser de este principio es la contención del daño ante un posible compromiso. Si una aplicación tiene un fallo de seguridad, como una vulnerabilidad que permita a un atacante ejecutar consultas a la base de datos a través de ella, el alcance de lo que ese atacante podría hacer queda limitado a los permisos que tenga el usuario de esa aplicación. Si el usuario está limitado según el principio de privilegio mínimo, el atacante solo podrá realizar las operaciones restringidas que ese usuario permita, lo que acota considerablemente el daño. En cambio, si la aplicación se conectase con el usuario administrador o con un usuario con permisos excesivos, el mismo fallo de seguridad le daría al atacante control total sobre la base de datos, con consecuencias potencialmente catastróficas, como el robo o la destrucción de todos los datos. Por ello, el principio de privilegio mínimo es una de las medidas más importantes para asegurar una base de datos, y consiste en crear usuarios específicos y acotados para cada aplicación y finalidad, otorgando siempre los permisos justos y necesarios. Es el mismo principio que rige la asignación de permisos en muchos otros ámbitos de la seguridad informática, como los permisos de archivos en los sistemas operativos, y su lógica es siempre la misma: dar lo justo y nunca de más, para minimizar el impacto de cualquier fallo o compromiso.

**¿Por qué una base de datos no debe estar expuesta a internet?**
Una base de datos no debe estar expuesta a internet porque hacerlo la convierte en un objetivo directo y accesible para atacantes de todo el mundo, y las bases de datos expuestas son una de las causas más frecuentes de las grandes filtraciones de datos, por lo que la práctica correcta es que la base de datos solo sea accesible desde donde realmente lo necesita, que es la aplicación que la utiliza, y no desde la red pública. El riesgo de exponer una base de datos a internet es muy elevado por varios motivos. En primer lugar, existen herramientas y servicios de rastreo que escanean continuamente internet en busca de bases de datos accesibles, y las encuentran a diario, de modo que una base de datos expuesta será descubierta con rapidez. En segundo lugar, muchas de esas bases de datos expuestas resultan estar además mal protegidas, sin contraseña o con una contraseña débil, lo que permite a los atacantes acceder a ellas sin apenas esfuerzo y robar o destruir toda la información que contienen. De hecho, una parte muy importante de las grandes filtraciones de datos que se producen tiene precisamente este origen, una base de datos accesible desde internet y con una protección insuficiente. Por todo ello, la regla general de seguridad es tajante: la base de datos debe permanecer resguardada y no ser accesible desde internet. La forma de conseguirlo implica varias medidas. La primera es configurar la base de datos para que solo escuche en la dirección local, si la aplicación que la usa está en el mismo servidor, o en la red interna, en lugar de escuchar en todas las interfaces de red, lo que la haría accesible desde el exterior. La segunda es configurar el cortafuegos del servidor para que el puerto de la base de datos no esté abierto a internet, sino que solo sea accesible desde donde reside la aplicación. De este modo, quien se comunica con la base de datos es únicamente la aplicación, utilizando su usuario limitado, mientras que nadie más desde el exterior puede siquiera alcanzarla. En los casos en que la aplicación y la base de datos estén en máquinas distintas y la comunicación entre ellas deba atravesar una red no confiable, es importante además cifrar esa conexión para proteger los datos en tránsito. En definitiva, mantener la base de datos fuera del alcance de internet, escuchando solo donde debe y protegida por el cortafuegos, es una de las medidas de seguridad más importantes y eficaces para prevenir accesos no autorizados y filtraciones de datos.

**¿En qué se diferencia asegurar una base de datos de instalarla?**
Asegurar una base de datos y instalarla son dos tareas distintas y complementarias, ya que instalar consiste en poner en marcha la base de datos y dejarla funcionando y lista para usar, mientras que asegurar consiste en endurecer esa instalación para que resista un entorno hostil, de modo que una base de datos puede estar perfectamente instalada y en funcionamiento y, sin embargo, ser insegura. La instalación de una base de datos abarca el proceso de descargar e instalar el software del sistema de bases de datos, ponerlo en funcionamiento, y realizar la configuración básica necesaria para poder empezar a usarlo, así como los primeros pasos de uso, como crear bases de datos y tablas y ejecutar consultas. El objetivo de la instalación es tener la base de datos operativa y disponible para el trabajo. Esta fase tiene su propio ámbito y su propia guía de primeros pasos, centrada en poner en marcha y empezar a utilizar la base de datos. El aseguramiento o endurecimiento, en cambio, es una tarea diferente que parte de una base de datos ya instalada y se ocupa de protegerla frente a las amenazas de un entorno hostil, como internet, los usuarios malintencionados o las aplicaciones que puedan tener fallos de seguridad. El objetivo del aseguramiento no es que la base de datos funcione, cosa que ya hace tras la instalación, sino que funcione de forma segura, cerrando las brechas y corrigiendo las configuraciones inseguras que deja una instalación recién hecha. Las medidas de aseguramiento incluyen ejecutar el asistente de seguridad que resuelve los problemas iniciales, aplicar el principio de privilegio mínimo creando usuarios específicos y acotados para cada aplicación, limitar el acceso a la red para que la base de datos no esté expuesta a internet, y aplicar las buenas prácticas generales de administración. La distinción es importante porque una de las confusiones más habituales, especialmente entre administradores noveles, es creer que una base de datos que está instalada y funcionando ya está lista y protegida, cuando en realidad una instalación funcional puede ser al mismo tiempo un auténtico colador de seguridad. Por ello, tras instalar una base de datos, es imprescindible dedicar tiempo a asegurarla, entendiendo que se trata de una segunda tarea, distinta de la instalación, y que es precisamente la que convierte una base de datos que simplemente funciona en una que funciona y está debidamente protegida frente a los riesgos del entorno en el que opera.

**¿Qué otras buenas prácticas de seguridad conviene aplicar?**
Además de los tres pilares principales de asegurar una base de datos, que son ejecutar el asistente de seguridad, aplicar el principio de privilegio mínimo y limitar el acceso a la red, conviene aplicar una serie de buenas prácticas de seguridad generales que completan el endurecimiento y que forman parte de la protección integral tanto de la base de datos como del servidor que la aloja. La primera buena práctica es mantener el software actualizado, tanto el sistema de bases de datos como el sistema operativo del servidor, aplicando las actualizaciones de seguridad con prontitud, ya que estas corrigen vulnerabilidades conocidas que de otro modo podrían ser explotadas por los atacantes. La segunda es utilizar contraseñas fuertes y únicas para todas las cuentas, muy especialmente para el usuario administrador de la base de datos y para los usuarios de las aplicaciones, evitando contraseñas por defecto, débiles o reutilizadas, ya que las credenciales débiles son uno de los primeros objetivos de los atacantes. La tercera, y de enorme importancia, es realizar copias de seguridad periódicas de la base de datos y comprobar que se pueden restaurar, ya que los backups son la red de seguridad ante cualquier incidente, ya sea un ataque, un fallo del sistema o un borrado accidental, y permiten recuperar los datos en caso de desastre. La cuarta es asegurar también el resto del servidor, ya que la base de datos no vive aislada, sino en un servidor que debe estar igualmente protegido, con el acceso administrativo seguro, por ejemplo mediante conexiones remotas protegidas con claves y con herramientas que frenen los ataques de fuerza bruta, con el cortafuegos correctamente configurado y con los demás servicios endurecidos. La quinta es aplicar el cifrado cuando corresponda, tanto de las conexiones a la base de datos cuando el tráfico atraviesa redes no confiables, como potencialmente de los propios datos sensibles almacenados, según las necesidades. La sexta es revisar y auditar periódicamente los usuarios, los permisos y los accesos, eliminando las cuentas y los privilegios que ya no sean necesarios y detectando posibles accesos anómalos. Y la séptima es registrar la actividad relevante, de modo que quede constancia de los accesos y las operaciones importantes, lo que facilita detectar problemas y responder ante incidentes. En conjunto, estas buenas prácticas, sumadas a los tres pilares fundamentales, conforman una estrategia sólida de seguridad para la base de datos, entendida siempre como una pieza dentro del endurecimiento integral del servidor, ya que de nada sirve proteger muy bien la base de datos si el servidor que la aloja queda desprotegido, ni al revés.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [GNU/Linux](https://underc0de.org/foro/gnu-linux/). Servidores y bases de datos.
2. **Underc0de, foro.** [Bases de datos](https://underc0de.org/foro/bases-de-datos/). Seguridad de MySQL y MariaDB.

### Documentación oficial

1. **Oracle.** [MySQL Security](https://dev.mysql.com/doc/refman/8.0/en/security.html). Guía de seguridad de MySQL.
2. **MariaDB.** [Securing MariaDB](https://mariadb.com/kb/en/securing-mariadb/). Endurecimiento de MariaDB.
3. **NIST.** [SP 800-123](https://csrc.nist.gov/pubs/sp/800/123/final). Seguridad de servidores.
4. **OWASP.** [Database Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html). Buenas prácticas.

## Guías relacionadas

- [MySQL: instalación y primeros pasos](../../bases-de-datos/mysql-instalacion-y-primeros-pasos/index.md)
- [Administración de servidores](../administracion-de-servidores-linux-desde-cero/index.md)
- [Fail2ban para SSH](../fail2ban-para-proteger-ssh-de-ataques-de-fuerza-bruta/index.md)
- [Permisos de archivos](../permisos-y-propietarios-de-archivos-en-linux/index.md)
- [Índice de Linux](../index.md)