"Usá contraseñas fuertes" no es una práctica de seguridad. Es higiene básica. Cuando reviso la postura de seguridad de aplicaciones web B2B, las brechas que encuentro casi nunca son sobre la fortaleza de las contraseñas — son sobre decisiones estructurales que se tomaron (u omitieron) durante la fase de diseño y nunca se revisaron.

Estas son las siete prácticas que trato como no negociables en cada sistema B2B en producción que construyo o audito.

1. Consultas Parametrizadas — Siempre, Sin Excepción

La inyección SQL sigue siendo uno de los vectores de ataque más comunes y más dañinos en las aplicaciones web. La solución no es complicada: nunca concatenes la entrada del usuario en una cadena SQL. Usá consultas parametrizadas o un ORM que las genere por vos.

Con Entity Framework Core o Dapper en .NET, obtenés parametrización por default siempre que uses correctamente las APIs de consulta proporcionadas. La zona de peligro es la interpolación de cadenas sin formato — $"SELECT * FROM users WHERE email = '{input}'" — que le da a un atacante una línea directa a tu base de datos. Reviso cada capa de acceso a datos en una auditoría específicamente buscando este patrón.

2. Principio de Mínimo Privilegio en Cuentas de Base de Datos

El usuario de base de datos de la aplicación debe tener solo los permisos que necesita para hacer su trabajo — nada más. Un servicio de reportes con muchas lecturas no debería tener permisos de INSERT, UPDATE o DELETE. El usuario principal de la aplicación no debería ser el propietario de la base de datos. Un usuario que solo necesita leer una tabla no debería tener acceso a todo el esquema.

Esto limita el radio de explosión. Si un atacante compromete la capa de aplicación y escala a la conexión de base de datos, obtiene exactamente lo que esa conexión puede hacer — no las llaves de toda la base de datos. Configuro esto a nivel de base de datos, no a nivel de aplicación.

3. Cifrado en Reposo

Para aplicaciones B2B que manejan datos de clientes, PII o cualquier cosa sujeta a GDPR, HIPAA o similares — el cifrado en reposo es obligatorio. En AWS RDS esto es una casilla al momento de aprovisionamiento (habilitála; no hay excusa de rendimiento para no hacerlo). En SQL Server, el Cifrado de Datos Transparente (TDE) cifra los archivos de datos subyacentes.

El cifrado en reposo no protege contra una aplicación comprometida con credenciales válidas. Protege contra el robo físico de medios de almacenamiento, la exfiltración de archivos de backup y ciertas clases de mala configuración en la nube. No es suficiente por sí solo, pero es necesario.

4. TLS en Tránsito — Incluyendo el Tráfico Interno

Cifrá la conexión entre tu servidor de aplicaciones y tu base de datos. Esto es estándar para el tráfico que enfrenta internet pero se omite rutinariamente para el tráfico VPC interno bajo la suposición de que el perímetro de red es protección suficiente.

No lo es. Si un atacante obtiene acceso a tu red (a través de una instancia EC2 comprometida, un grupo de seguridad mal configurado, o un compromiso de la cadena de suministro), el tráfico de base de datos interno sin cifrar es legible con una captura de paquetes. Habilitar TLS en las conexiones RDS es un cambio de configuración, no un esfuerzo de desarrollo.

5. Aislamiento VPC e Higiene de Grupos de Seguridad

Tu base de datos nunca debería ser directamente accesible desde internet. Sin excepciones. En AWS, esto significa colocar instancias RDS en subnets privadas sin ruta al gateway de internet, y configurar grupos de seguridad para permitir tráfico entrante solo desde el grupo de seguridad de tu capa de aplicaciones — no desde un rango CIDR, y ciertamente no desde 0.0.0.0/0.

Rutinariamente encuentro bases de datos en sistemas B2B que fueron aprovisionadas "temporalmente" con acceso público habilitado y un grupo de seguridad abierto, luego promovidas a producción sin nunca haber sido aseguradas. Un grupo de seguridad mal configurado es una de las causas más comunes de brechas de datos en la nube.

6. Seguridad a Nivel de Fila para Datos Multi-Tenant

Si tu aplicación B2B sirve a múltiples organizaciones desde un único esquema de base de datos (la arquitectura más común para SaaS y portales B2B), necesitás asegurarte de que un tenant no pueda acceder a los datos de otro.

La Seguridad a Nivel de Fila (RLS) en PostgreSQL y SQL Server te permite definir políticas de acceso a nivel del motor de base de datos — la propia base de datos aplica el aislamiento de tenants, independientemente de lo que haga la capa de aplicación. Esto significa que un bug en la lógica de filtrado de tenants de tu aplicación no se convierte automáticamente en una brecha de datos. Es una capa de defensa en profundidad que implemento en cada sistema multi-tenant.

7. Gestión de Secretos — Sin Credenciales en Código ni Archivos de Configuración

Las cadenas de conexión de base de datos, las claves de API y las credenciales de cuentas de servicio nunca deben aparecer en tu código fuente, archivos .env comprometidos en un repositorio, o archivos de configuración sin cifrar en un servidor.

En entornos AWS uso AWS Secrets Manager o SSM Parameter Store con roles IAM. La instancia de la aplicación tiene un rol IAM que le permite leer secretos específicos — no se almacenan credenciales en la instancia en absoluto. La rotación de secretos es automatizada. El acceso a los secretos se registra a través de CloudTrail.

Esta única práctica previene toda una clase de incidentes de exposición de credenciales — incluido el escenario extremadamente común donde un desarrollador junior accidentalmente hace commit de un archivo .env a un repositorio público de GitHub.

Estas siete prácticas son la línea de base. No son seguridad avanzada — son el estándar mínimo para un sistema B2B que maneja datos de clientes en 2025. Si a tu sistema actual le falta alguna de ellas, eso es un proyecto de remediación, no un nice-to-have.

Para un tratamiento más profundo de cómo las decisiones de diseño de base de datos afectan tanto la seguridad como el rendimiento, mi artículo sobre cuellos de botella en bases de datos de pymes cubre el lado estructural. Y si necesitás una revisión de seguridad de un sistema existente, contactáme.