Cómo se compromete una base de datos (y cómo se evita)
Publicado el 2026-09-12 por frfrand
Los cinco caminos reales por los que se filtran datos, en orden de frecuencia. Ninguno implica romper el cifrado, y casi todos se cierran con decisiones que ya conoces.
Cuando se habla de "hackear una base de datos" la imagen mental suele ser alguien rompiendo un cifrado. En la realidad, casi ninguna filtración ocurre así.
Estos son los caminos reales, en orden de frecuencia.
1. Estaba abierta
El más común, y el menos glamoroso.
Un puerto de base de datos expuesto a Internet, con una contraseña débil o directamente sin autenticación. Redes enteras escanean el espacio de direcciones buscando exactamente eso, todo el día.
Casi nunca se abrió a propósito: quedó así después de una prueba, de una migración o de un "lo abro cinco minutos".
Se cierra así: que la base escuche sólo en localhost, y que el acceso remoto sea por túnel o red privada. Si algo no necesita estar abierto, no se abre.
2. Inyección SQL
Sigue vigente después de veinticinco años.
Ocurre cuando la entrada del usuario se pega dentro de una consulta como texto. Si alguien escribe algo que incluye comillas y más SQL, ese SQL se ejecuta.
La solución no es escapar comillas a mano, ni filtrar palabras sospechosas. Es usar consultas parametrizadas: el valor viaja aparte de la consulta y nunca se convierte en parte del SQL.
# vulnerable q = "SELECT * FROM usuarios WHERE mail = '" + mail + "'"
# correcto cur.execute("SELECT * FROM usuarios WHERE mail = %s", [mail])
Todo ORM moderno lo hace por defecto. El riesgo aparece cuando alguien arma una consulta a mano "porque el ORM no lo soportaba".
3. Una credencial filtrada
La contraseña de la base terminó en un commit, en un log, en una captura de pantalla, en un chat.
Se reduce así: credenciales fuera del código, .env ignorado desde el primer commit, y —lo más importante— rotarlas apenas se sospeche. Recordá que borrar una clave de un commit no la saca de la historia.
4. Demasiados privilegios
Este no abre la puerta, pero decide cuánto se pierde.
Si tu aplicación se conecta con el usuario administrador, cualquiera de los tres caminos anteriores da acceso total: leer todo, modificar todo, borrar todo.
Si se conecta con un usuario que sólo puede leer y escribir en las tablas que usa, el mismo fallo tiene un alcance mucho menor.
Es la medida más barata de todas y la que más se saltea, porque al principio "es más cómodo así".
5. La copia de seguridad
La base puede estar perfectamente protegida y el volcado nocturno estar en una carpeta accesible, o en un almacenamiento en la nube mal configurado, o en la laptop de alguien.
Un backup es una copia completa de tus datos sin ninguna de las protecciones de la base. Merece el mismo cuidado: cifrado, permisos estrictos, y acceso limitado.
Lo que hay que mirar hoy
Cinco preguntas concretas:
- ¿La base escucha en todas las interfaces o sólo en localhost?
- ¿Tu aplicación se conecta con el superusuario?
- ¿Hay alguna consulta armada con concatenación de texto?
- ¿Dónde están los backups y quién puede leerlos?
- ¿Cuándo se actualizó por última vez el motor?
Ninguna de esas preguntas requiere conocimientos de seguridad avanzados. Es justamente el punto: la mayoría de las filtraciones se evitaban con decisiones que el equipo ya sabía tomar.
Comprobación básica de seguridad para una base de datos
Antes de poner una base en producción revisá cuatro aspectos: si escucha en una interfaz pública, quién puede autenticarse, qué operaciones permite cada usuario y dónde se guardan las copias. Un puerto abierto, credenciales dentro de Git o una API sin autorización pueden exponer información aunque la base esté actualizada.
Si usás PostgreSQL en un VPS de ArduMaker, lo habitual es que la aplicación acceda por una red restringida y que el mantenimiento remoto se realice mediante un túnel autorizado, en lugar de abrir el puerto 5432 a todo Internet. Además, creá un usuario de aplicación con permisos acotados y probá una restauración de backup.
Relacionado: Conectar PostgreSQL sin exponerlo · Firewall Linux.