¡Hola, chicos!

El 6 de febrero participé en el Mesa Redonda #212 en el canal Coding Night, en una conversación extensa y profundamente práctica sobre seguridad al utilizar bases de datos, teniendo como referencia principal los materiales de la OWASP. La propuesta del concierto no fue presentar soluciones nuevas o sofisticadas, sino revisar los fundamentos que continúan siendo ignorados, incluso después de décadas de recomendaciones consolidadas.

A lo largo de la discusión, quedó claro que la mayoría de los incidentes de seguridad que involucran bases de datos no están asociados con ataques complejos o técnicas avanzadas, sino más bien con abandono de las prácticas básicas, ampliamente documentado y conocido por la comunidad técnica.

Enlace de transmisión:

OWASP como base conceptual y práctica

Uno de los primeros puntos tratados fue la contextualización de OWASP. Más que una lista de vulnerabilidades, OWASP se ha consolidado como una referencia mundial en buenas prácticas de seguridad, basado en la observación continua de los ataques más recurrentes en el mundo real.

lo conocido Top 10 de OWASP surgió precisamente del análisis estadístico de los ataques más frecuentes a las aplicaciones. A medida que la comunidad maduró, este trabajo evolucionó hacia materiales más específicos, como:

  • OWASP Top 10 para API

  • OWASP Top 10 para CI/CD

  • OWASP Top 10 para contenedores

  • Hoja de referencia de seguridad de la base de datos OWASP

Estos materiales funcionan como listas de verificación prácticas, y no como teoría académica. El vivo se centró precisamente en discutir cómo estas recomendaciones se aplican al día a día de quienes trabajan con bases de datos, desarrollo e infraestructura.

La seguridad básica sigue siendo el mayor obstáculo

Un punto que se reforzó varias veces fue que la mayoría de las vulnerabilidades explotadas hoy en día son muy conocidas. La inyección SQL, la exposición de credenciales, los bancos accesibles directamente a través de Internet, los permisos excesivos y la falta de cifrado siguen apareciendo en entornos productivos.

No se trata de una profunda falta de conocimientos técnicos, sino de falta de disciplina, presión de plazos y acumulación de deuda técnica que nunca se aborda.

A menudo se sacrifica la seguridad cuando los plazos son ajustados. El problema surge cuando esta decisión no se registra, no se prioriza o no se revisa más adelante. La deuda de garantía técnica se asume pero nunca se paga.

Protección de backend de bases de datos y aislamiento de red

Una parte importante de la conversación estuvo dedicada a protección de fondo de base de datos, comenzando con el aislamiento a nivel de red. La primera línea de defensa de cualquier banco debería ser garantizar que no es innecesariamente accesible.

Prácticas como:

  • Restringir las conexiones solo a hosts o IP específicos

  • Evite la exposición directa del banco a Internet

  • Utilice firewalls, reglas de red y, cuando sea posible, DMZ

  • Asegúrese de que solo los servidores de aplicaciones puedan conectarse

Incluso si una credencial está comprometida, el atacante no debería poder establecer una conexión si está fuera del contexto esperado. Este tipo de control reduce drásticamente la superficie de ataque.

Autenticación y el problema de las credenciales olvidadas

Otro punto central fue la forma en que se implementa la autenticación. Los bancos que utilizan autenticación basada únicamente en nombre de usuario y contraseña crean un problema recurrente: credenciales que permanecen válidas indefinidamente.

Se discutió cómo la autenticación integrada (por ejemplo, Active Directory o Single Sign-On) aporta claros beneficios:

  • No hay ninguna contraseña viajando por la red.

  • Desactivar un usuario invalida automáticamente todos los accesos

  • Reduce drásticamente el riesgo de cuentas huérfanas

Se mencionaron casos reales donde ex empleados mantuvieron acceso indirecto a la base de datos simplemente porque la credencial nunca fue eliminada.

Principio de privilegio mínimo en la práctica

El principio de privilegio mínimo no se trató como un concepto abstracto, sino como una práctica diaria. Otorgar permisos amplios “por conveniencia” es uno de los errores más comunes y peligrosos.

Se destacó que:

  • La mayoría de las aplicaciones no necesitan permisos administrativos.

  • El acceso de lectura mal controlado también supone un riesgo

  • Los permisos deben otorgarse en el menor alcance posible.

Además, los permisos deben ser revisado periódicamente, y no sólo durante auditorías puntuales. Los entornos sin revisiones periódicas tienden a acumular accesos innecesarios con el paso de los años.

Almacenamiento seguro de credenciales

Gran parte del directo abordó el almacenamiento inadecuado de credenciales en las aplicaciones. Ejemplos del mundo real han demostrado cómo las contraseñas expuestas en el código fuente o en los archivos de configuración se explotan en cuestión de segundos.

Las mejores prácticas discutidas incluyeron:

  • Nunca versionar credenciales

  • Utilice bóvedas secretas dedicadas

  • Restringir el acceso a la bóveda sólo a aquellos que realmente lo necesitan

  • Preferir variables de entorno solo como alternativa intermedia.

Se enfatizó que las bóvedas de contraseñas no solo protegen las credenciales sino que también evitan la exposición accidental al compartir pantalla, grabaciones o demostraciones.

Cifrado en reposo y en tránsito

El debate sobre el cifrado dejó claro que proteger por sí solo los datos almacenados no es suficiente. Los datos también deben protegerse durante el trafico entre la aplicación y el banco.

El uso de:

  • TLS para conexiones bancarias

  • Certificados válidos y versiones de protocolos seguros.

  • Evite aceptar conexiones inseguras incluso con redirección

La analogía utilizada fue sencilla: no tiene sentido proteger la caja fuerte si el dinero se transporta sin escolta.

Gestión consciente de la deuda técnica en valores

Uno de los puntos más maduros de la conversación fue la discusión sobre deuda técnica de seguridad. No siempre es posible implementar todo correctamente desde el principio, especialmente en startups o proyectos con plazos de entrega agresivos.

El problema no es asumir la deuda, sino no reconocerlo ni registrarlo. Las vulnerabilidades conocidas deben documentarse, priorizarse y tener un plan de corrección definido. La seguridad no puede depender únicamente de los recuerdos de las personas.

Uso de herramientas y automatización como soporte.

El directo también mostró cómo las herramientas automatizadas pueden ayudar a identificar vulnerabilidades básicas antes de invertir en pruebas más avanzadas. Las herramientas de análisis estático (SAST), las herramientas de análisis dinámico (DAST) y los escáneres API ayudan a eliminar los "malos conceptos básicos".

Estas herramientas no reemplazan las pruebas manuales ni a los profesionales especializados, pero reducen drásticamente la cantidad de problemas triviales que llegan a una auditoría formal.

La seguridad como responsabilidad colectiva

Un punto reforzado a lo largo de la mesa redonda fue que la seguridad no es responsabilidad exclusiva de los DBA, los desarrolladores o la infraestructura. Surge de interacción entre todas estas áreas.

Las decisiones de desarrollo impactan al banco. Las configuraciones de infraestructura impactan la aplicación. Las fallas de comunicación entre equipos crean brechas que no existirían si el problema se abordara de manera conjunta.

Consideraciones finales

La Mesa Redonda #212 reforzó algo esencial: La seguridad falla, la mayoría de las veces, debido a conceptos básicos mal hechos.. No es falta de conocimiento, ni de herramientas, sino de disciplina, proceso y madurez.

Mientras las prácticas fundamentales sigan siendo tratadas como opcionales, seguirán ocurriendo incidentes. Para empezar, la seguridad no requiere soluciones complejas, requiere compromiso para hacer lo que ya se sabe correctamente.

Este directo tuvo como objetivo precisamente sacar a la luz esta realidad, de una manera directa, técnica y acorde con lo que realmente sucede en el mercado.