Endurecimiento de bases de datos: PostgreSQL y MySQL en producción

Una base de datos de producción es donde viven las joyas de la corona, lo que hace del endurecimiento de bases de datos una de las actividades de mayor impacto en las que un equipo defensivo puede invertir. PostgreSQL y MySQL son robustos y, en estados por defecto o configurados con prisa, exponen más de lo que deberían. Esta guía adopta la mirada del blue team: explica la superficie de exposición de una base de datos de producción, cómo suelen desarrollarse los ataques contra los almacenes de datos a alto nivel y —el meollo— los controles, la telemetría y las detecciones concretas que mantienen los datos confidenciales, íntegros y disponibles. El enfoque es entender para defender, no para explotar.

Por qué importa el endurecimiento de bases de datos#

Las aplicaciones se parchean, los firewalls reciben reglas y los endpoints reciben EDR, pero la base de datos suele quedar detrás de todo eso con una postura de confianza por defecto. Por eso es un objetivo: una sola credencial débil, una cuenta de aplicación con exceso de privilegios o un respaldo sin cifrar pueden entregar todo el conjunto de datos de una vez. Endurecer la base de datos reduce el valor de cualquier otro punto de apoyo, porque incluso un atacante que alcanza el segmento de red aún enfrenta autenticación, mínimo privilegio, cifrado y monitoreo. Piénselo como defensa en profundidad aplicada al único activo cuyo compromiso suele ser el verdadero objetivo de la intrusión.

La superficie de exposición de una base de datos de producción#

La superficie de exposición tiene varias caras. Está la cara de red: el puerto en el que escucha el motor y quién puede alcanzarlo. Está la cara de autenticación: cómo se identifican las identidades y cuán fuertes son esas pruebas. Está la cara de autorización: qué puede leer, escribir o administrar cada rol. Está la cara de datos en reposo: archivos, tablespaces y respaldos en disco. Y está la cara de observabilidad: si alguien notaría un acceso anómalo. Una base de datos endurecida estrecha cada una; una instalación por defecto deja varias abiertas de par en par, casi siempre escuchando en todas las interfaces y confiando en las conexiones locales de forma implícita.

Cómo se desarrollan los ataques a bases de datos a alto nivel#

Conceptualmente, una intrusión dirigida a los datos suele seguir un arco reconocible. El adversario primero alcanza una posición desde la que la base de datos es direccionable: un servidor de aplicaciones, un jump host o un puerto expuesto. Luego intenta autenticarse, ya sea con credenciales reutilizadas halladas en otro sitio, una contraseña débil o por defecto, o una cuenta de aplicación con más derechos de los que necesita. Ya conectado, enumera esquemas y privilegios buscando el camino más corto a tablas sensibles o a capacidad administrativa. Finalmente intenta la extracción masiva o la persistencia. Cada etapa mapea a un control defensivo, por lo que el endurecimiento se planifica mejor como un conjunto de barreras a lo largo de ese arco que como un solo muro.

Autenticación y control de acceso#

Empiece por eliminar la confianza por defecto. En PostgreSQL, revise pg_hba.conf para que ninguna regla use el método trust salvo en sockets locales estrictamente controlados, y prefiera scram-sha-256 para autenticación por contraseña. En MySQL, elimine cuentas anónimas y cualquier cuenta con contraseña vacía o por defecto, y prefiera plugins de autenticación fuertes. Dé a cada persona y a cada aplicación su propio rol nombrado, nunca un superusuario compartido. Donde la plataforma lo permita, intégrese con un proveedor de identidad central o autenticación basada en certificados de vida corta para que las credenciales sean rotables y revocables. Aplique políticas de contraseña fuertes y, para acceso administrativo, exija autenticación multifactor en el bastión frente a la base de datos.

Exposición de red y cifrado en tránsito#

Vincule el motor a las interfaces específicas que debe servir, no a todas las direcciones, y colóquelo en un segmento de red privado alcanzable solo desde la capa de aplicación y los bastiones administrativos. Use firewalls de host y grupos de seguridad de red como segunda barrera para que ni una mala configuración exponga el puerto a la red más amplia. Exija TLS en cada conexión y desactive el repliegue sin cifrar: en PostgreSQL imponga reglas hostssl y establezca ssl = on; en MySQL exija transporte seguro. Valide los certificados del lado del cliente para que un intermediario no pueda degradar o interceptar la sesión en silencio. Trate cualquier conexión de base de datos en texto plano en producción como un incidente por corregir, no como una comodidad tolerable.

Mínimo privilegio y permisos de esquema#

Las cuentas con exceso de privilegios son el hallazgo más común en las revisiones de bases de datos. Las cuentas de aplicación suelen correr como propietarias o superusuarias cuando solo necesitan select, insert, update y delete en un puñado de tablas. Conceda el mínimo, revoque el resto y use herencia de roles para mantenerlo manejable. En PostgreSQL, sea deliberado con el esquema public y los privilegios por defecto, y considere seguridad a nivel de fila para datos multiinquilino. En MySQL, acote los grants a bases de datos y tablas específicas en vez de usar grants con comodín. Separe la cuenta que ejecuta migraciones de la que sirve tráfico, para que un compromiso cotidiano de la aplicación no confiera automáticamente poder para alterar el esquema.

Cifrado en reposo y gestión de secretos#

Proteger los datos en disco cierra el camino en el que un atacante o un respaldo perdido entrega el conjunto de datos directamente. Habilite cifrado a nivel de almacenamiento o de sistema de archivos para el directorio de datos y, sobre todo, cifre los respaldos con claves gestionadas por separado del host de la base de datos. Nunca incruste contraseñas de base de datos en el código fuente ni en archivos de configuración versionados; recupérelas en tiempo de ejecución desde un gestor de secretos con registro de acceso. Rote las credenciales de forma programada e inmediatamente tras cualquier exposición sospechada. La regla rectora es que poseer un disco, una instantánea o un archivo de respaldo no debe bastar para leer los datos sin poseer también claves bajo control separado.

Detección: registro y monitoreo#

Endurecer sin detectar lo deja ciego ante los intentos que sí pasan. En PostgreSQL, habilite el registro de conexiones y desconexiones, registre las autenticaciones fallidas y considere la extensión pgaudit para auditoría a nivel de sentencia de objetos sensibles. En MySQL, habilite el plugin de audit log y los registros general o de consultas lentas según convenga, y capture los eventos de inicio de sesión fallidos. Envíe estos registros a un SIEM central y alerte ante las señales significativas: un pico de fallos de autenticación, un inicio de sesión desde un host inesperado o a una hora inusual, concesiones de privilegios, volúmenes de resultados grandes o inusuales que sugieran extracción masiva, y cualquier cambio en la configuración de auditoría. Monitoree la salud de la propia tubería de registro.

Respaldo, recuperación e integridad#

La disponibilidad y la integridad son parte de la seguridad, no algo aparte. Mantenga respaldos probados y cifrados con una retención definida, y guarde al menos una copia en un lugar que un atacante que comprometa el primario no pueda alcanzar ni borrar. Ensaye la recuperación con regularidad; un respaldo que nunca se ha restaurado es una esperanza, no un control. Proteja los respaldos con la misma disciplina de mínimo privilegio y monitoreo que la base de datos viva, porque un repositorio de respaldos desprotegido es simplemente una segunda copia, más silenciosa, de todo. Para resiliencia ante ransomware, el almacenamiento de respaldo inmutable o de una sola escritura asegura que un intruso con acceso a la base de datos no pueda destruir además los medios de recuperación.

Errores comunes#

Los errores recurrentes incluyen dejar el motor escuchando en todas las interfaces, mantener cuentas administrativas por defecto o compartidas, conceder a los usuarios de la aplicación mucho más de lo que necesitan, y almacenar cadenas de conexión con contraseñas incrustadas en repositorios. Los equipos a menudo habilitan el cifrado en tránsito pero nunca lo imponen, de modo que los clientes caen en silencio a texto plano. Otros cifran el volumen vivo pero dejan los respaldos en claro. Una brecha de detección frecuente es un registro que existe pero nunca se reenvía ni se revisa, así que solo sirve en la autopsia posterior al incidente. Por último, cuidado con los atajos por rendimiento que desactivan autenticación o auditoría para un trabajo por lotes y nunca se reactivan.

Lista de verificación de endurecimiento#

Un punto de partida defensivo: (1) eliminar confianza por defecto, cuentas anónimas y por defecto; (2) exigir credenciales fuertes, rotadas y por identidad con MFA en las rutas administrativas; (3) vincular a interfaces específicas dentro de un segmento privado tras firewalls de host y de red; (4) exigir y validar TLS en cada conexión; (5) aplicar mínimo privilegio a cada rol y separar cuentas de migración y de ejecución; (6) cifrar datos en reposo y cifrar respaldos con claves gestionadas por separado; (7) obtener secretos de un gestor, nunca del control de versiones; (8) habilitar auditoría de conexiones, de logins fallidos y de sentencias y reenviarla a un SIEM; (9) alertar ante anomalías de autenticación, cambios de privilegios y extracción masiva; (10) mantener respaldos probados, inmutables y fuera del primario y ensayar la recuperación.

FAQ: ¿Basta el cifrado en tránsito en una red privada?#

No. Una red privada reduce la exposición pero no elimina el movimiento lateral, la mala configuración ni un interno en el mismo segmento. El cifrado en tránsito protege la sesión de la interceptación y la degradación sin importar dónde esté el límite de red, y debe combinarse con mínimo privilegio, cifrado en reposo y monitoreo. La defensa en profundidad asume que cualquier capa individual, incluido el perímetro de red, puede fallar.

FAQ: ¿Debería la aplicación usar un superusuario por comodidad?#

Nunca en producción. Una cuenta de aplicación debe tener solo los derechos de manipulación de datos que de verdad necesita sobre los objetos específicos que toca. Correr como superusuario significa que cualquier compromiso de la capa de aplicación —una falla de inyección, un token robado— se convierte de inmediato en compromiso total de la base de datos. Separe cuentas para ejecución, migraciones y administración para que el radio de acción de una sola credencial quede contenido.

Conclusión#

Endurecer PostgreSQL y MySQL en producción consiste en colocar barreras a lo largo de todo el camino que un adversario recorrería hacia los datos: autenticación que resiste la reutilización, aislamiento de red que limita el alcance, mínimo privilegio que contiene cualquier punto de apoyo, cifrado que neutraliza discos y respaldos robados, y detección que convierte el acceso anómalo silencioso en una alerta ruidosa. Nada de esto es exótico y, en conjunto, convierten el activo más valioso del parque de un objetivo blando en uno monitoreado y defendible. Trate la lista como algo vivo, revísela tras cada cambio y cada incidente, y verifique la configuración viva en vez de confiar en la prevista.