¡Hola, chicos!

El 11 de junio participé en el Mesa Redonda #222 en el canal Noche de codificación, en su segunda edición, con un enfoque total en seguridad al utilizar bases de datos. La propuesta del directo fue continuar la edición anterior y profundizar puntos críticos del material del OWASP, especialmente aquellos que siguen siendo descuidados incluso en entornos corporativos maduros.

La conversación se desarrolló de forma abierta, práctica y sin la preocupación de “embellecer” el tema. El objetivo era discutir lo que realmente sucede a diario, los errores más comunes y por qué los problemas de seguridad siguen recurriendo, incluso cuando las recomendaciones son ampliamente conocidas.

Enlace de transmisión:

Hoja de referencia de seguridad de la base de datos OWASP como hilo conductor

Usamos como base el Hoja de referencia de seguridad de la base de datos OWASP, que reúne recomendaciones organizadas de la A a la Z sobre seguridad de bases de datos. Un punto importante destacado al principio fue que este material no debe verse como una lista teórica, sino como una lista de verificación práctica.

Los incidentes de seguridad más graves no ocurren debido a fallas sofisticadas, sino a Falta de implementación de controles básicos., ampliamente documentado durante años. La inyección SQL, por ejemplo, se sigue explorando no porque sea nueva, sino porque sigue siendo posible.

Autenticación, identidad y el problema de las cuentas olvidadas

Una parte importante del directo estuvo dedicada a autenticación y gestión de identidad. Discutimos cómo el uso de autenticación integrada (Active Directory, autenticación federada o identidades administradas en la nube) reduce drásticamente los riesgos operativos.

El problema recurrente es el uso de:

  • Usuarios locales en la base de datos.

  • Cuentas de aplicaciones con permisos excesivos

  • Credenciales que permanecen activas después de que los empleados se van

Le expliqué que las cuentas “olvidadas” son una de las mayores puertas de entrada a incidentes. Muchas veces, el usuario ni siquiera necesita ser externo: alguien que salió de la empresa, cambió de área o regresó como tercero aún puede tener acceso privilegiado si este control no se realiza correctamente.

Principio de privilegio mínimo aplicado de manera realista

Otro punto central de la discusión fue el principio de privilegio mínimo, no sólo como concepto, sino como práctica eficaz.

Hablamos de:

  • Evite otorgar acceso a nivel de base de datos cuando sea necesario a nivel de tabla

  • Evitar permisos de escritura cuando el uso es de solo lectura

  • El riesgo real de que un simple acceso de lectura mal controlado genere indisponibilidad (incluidos ataques de denegación de servicio por lectura excesiva)

Se reforzó que la seguridad no es sólo evitar escribir o borrar datos, sino también asegurar disponibilidad.

Seguridad de aplicaciones: credenciales, configuración y errores clásicos

El evento en vivo trajo varios ejemplos reales que involucran aplicaciones que almacenan credenciales en ubicaciones inapropiadas, como archivos de configuración versionados en repositorios Git. Los casos en los que las contraseñas han sido expuestas públicamente y explotadas en cuestión de segundos muestran que este riesgo no es hipotético.

Hablamos de prácticas como:

  • Uso de una bóveda secreta o, como mínimo, variables de entorno.

  • Nunca versione las credenciales, ni siquiera en repositorios privados

  • Extremar cuidado en demostraciones en vivo, grabaciones e impresiones.

También comentamos cómo han evolucionado plataformas como GitHub para detectar automáticamente filtraciones secretas, pero esto no reemplaza las buenas prácticas.

Fortalecimiento de bases de datos y sistemas operativos

Otro punto fuerte del directo fue la discusión sobre endurecimiento, tanto la base de datos como el sistema operativo subyacente. Proteger sólo el DBMS no resuelve el problema si el sistema operativo queda expuesto.

Puntos como:

  • Deshabilitar funciones peligrosas cuando no se utilizan (por ejemplo, xp_cmdshell, CLR, navegador SQL)

  • Evite el uso de usuarios estándar o ampliamente conocidos.

  • Separación clara entre cuentas administrativas del sistema y de la base de datos

La idea central era reducir la superficie de ataque y dificultar cualquier intento de elevar los privilegios.

La copia de seguridad como pilar de la seguridad, no solo de la recuperación

La estrategia de respaldo fue tratada como una elemento de seguridad, y no sólo la continuidad del negocio. Se citaron casos reales en los que las empresas tuvieron que pagar rescates simplemente porque no tenían copias de seguridad externas válidas.

Hablamos de:

  • Copia de seguridad periódica y probada

  • Cifrado de respaldo

  • Almacenamiento externo y, preferentemente, en la nube

  • Definición clara de RPO y RTO alineados con el negocio

Se reforzó que la estrategia de respaldo no debe ser definida solo por TI, sino en conjunto con el área de negocio, considerando el impacto financiero y operativo.

La inyección SQL sigue siendo un problema actual

Incluso después de décadas, la inyección SQL sigue apareciendo con frecuencia en incidentes graves. La discusión dejó claro que el problema no está sólo en el idioma o en el banco, sino en la cómo se desarrollan las aplicaciones.

Destacamos:

  • Uso obligatorio de parámetros.

  • Riesgos de SQL dinámico mal implementado

  • Falsa sensación de seguridad al utilizar ORM incorrectamente

  • La necesidad de validación de entradas, independientemente de la tecnología utilizada.

También comentamos que las bases de datos no pueden, por sí solas, diferenciar una consulta legítima de una consulta maliciosa si la aplicación entrega SQL no válido.

Granularidad de acceso y aislamiento de entornos.

Otro tema recurrente fue la adecuada separación entre los entornos de desarrollo, prueba y producción. Compartir usuarios y credenciales entre entornos aumenta drásticamente el riesgo de error humano.

También hablamos de:

  • Seguridad a nivel de fila

  • Seguridad a nivel de columna

  • Usar vistas y procedimientos como capas adicionales de control

Estos mecanismos le permiten reducir la exposición de datos confidenciales incluso cuando el acceso es legítimo.

Consideraciones finales

La Mesa Redonda #222 reforzó algo que considero fundamental: La seguridad no falla por falta de información, sino por falta de disciplina. La mayoría de los problemas discutidos involucran prácticas básicas que continúan siendo ignoradas debido a las prisas, la falta de proceso o el exceso de confianza.

La seguridad de la base de datos no es responsabilidad exclusiva de los administradores de bases de datos, los desarrolladores o la infraestructura. Es un esfuerzo conjunto y continuo que debe ser tratado como una parte esencial de la arquitectura, no como un complemento opcional.

Esta edición dejó claro que, mientras las buenas prácticas no se traten como estándar, seguiremos viendo repetirse los mismos incidentes, sólo que con diferentes nombres y tecnologías.