Pentesting de una plataforma de datos para clientes institucionales

Las plataformas de la compañía son su negocio: aplicaciones web desde las que sus clientes acceden a sus productos de datos, y APIs que los distribuyen de forma programática. Cada cliente — organizaciones institucionales y corporativas con exigencias de seguridad muy altas — opera sobre la misma plataforma compartida. En un modelo así, la pregunta que quita el sueño es una: ¿puede el cliente A ver, por cualquier vía, los datos del cliente B?

No era una inquietud teórica. Varios de sus clientes exigían contractualmente pruebas de intrusión periódicas realizadas por un tercero independiente, y las renovaciones empezaban a pedir evidencia. Se acordó un pentest con alcance y reglas de enfrentamiento firmadas: qué sistemas, qué técnicas, qué ventanas horarias y qué canal de aviso inmediato si aparecía algo grave a mitad de prueba.

1. Reconocimiento y modelado de amenazas — mapa de la superficie expuesta y de los flujos de datos de la plataforma, para decidir dónde golpearía primero un atacante real: cuentas de cliente, APIs de distribución e infraestructura perimetral. Las pruebas se priorizaron por impacto de negocio, no por catálogo.
2. Pruebas OWASP sobre las aplicaciones web — autenticación, gestión de sesión, inyecciones y, sobre todo, control de acceso: qué puede hacer cada rol y qué puede alcanzar una cuenta legítima más allá de lo que le corresponde.
3. Foco en el aislamiento entre tenants — la prueba central del encargo: con cuentas legítimas de un cliente, intentar acceder a datos, trabajos y metadatos de otros por todas las vías — identificadores predecibles, autorización a nivel de objeto, filtrados incompletos en listados y buscadores.
4. Abuso de las APIs de distribución de datos — autorización a nivel de objeto en cada endpoint, límites de consumo y cuotas (¿puedo descargar más de lo contratado?), y abuso de la lógica de negocio de la distribución programática.
5. Infraestructura expuesta — inventario y prueba de todos los servicios accesibles desde internet, incluidos los que no deberían estarlo: paneles de administración, entornos auxiliares y servicios olvidados.
6. Informe, plan de corrección y retest — cada hallazgo con evidencia reproducible, impacto y corrección recomendada, más un resumen ejecutivo para dirección. Tras las correcciones, retest formal de cada vulnerabilidad y certificación escrita del cierre.

De las 11 vulnerabilidades, ninguna era crítica explotable sin autenticación — pero las dos altas tocaban justo donde más duele. La primera: una debilidad de control de acceso que permitía, con una cuenta legítima, acceder a metadatos de trabajos de otros clientes — no a los datos en sí, pero suficiente para revelar qué encargaba cada cliente y cuándo. La segunda: endpoints internos de administración accesibles desde internet con autenticación débil. El resto — varias medias y bajas — se documentó con la misma evidencia reproducible y un plan de corrección priorizado.

El equipo del cliente corrigió las dos altas en menos de tres semanas y el retest verificó el cierre de ambas. El efecto comercial llegó después: el informe — hallazgos, correcciones y cierre certificado por un tercero independiente — pasó a formar parte del paquete estándar que la compañía presenta en sus renovaciones con clientes institucionales. Lo que empezó como un requisito se convirtió en un argumento de venta.