Alex HerreraDesarrollador de software · Enfoque en ciberseguridad
EN
← Volver a proyectos

Profesional

Plataforma de Intercargo | ERP interno y sitio público

Sitio público y portal interno en servicios separados, para que un fallo del sitio no alcance los documentos de clientes.

  • Seguridad
  • Full stack
Rol
Desarrollo y modelo de seguridad
Periodo
2026-07 – actualidad

Stack

  • Next.js
  • React
  • TypeScript
  • MySQL
  • Google Cloud Run
  • Docker
  • Vitest
  • Playwright
  • Gemini

Contexto

La plataforma reúne el sitio público de Intercargo y el portal donde trabaja su personal. El portal cubre la debida diligencia de clientes, las cuentas por cobrar, la nómina y el seguimiento de las solicitudes que llegan por el sitio. Está en desarrollo activo y crece por módulos.

El encargo original era el portal interno. El equipo propuso rehacer también el sitio público. Mover ambos a una infraestructura propia era la única forma de operar el portal con las garantías que pedía el cliente. Mi papel fue construir sobre la plataforma y definir su modelo de seguridad.

Problema

El sitio funcionaba sobre un servicio de terceros que el equipo no administraba. Sin control sobre esa infraestructura, no había forma de alojar junto a él un portal con documentos de clientes.

La debida diligencia se hacía leyendo esos documentos a mano, expediente por expediente. Cada alta ocupaba a una persona antes de que el cliente pudiera operar. El ritmo de altas dependía de cuánta gente hubiera disponible para revisarlas.

Decisiones técnicas

Un sitio de marketing y un portal con documentos de clientes tienen exposiciones opuestas. Servirlos desde el mismo proceso convertiría cualquier fallo del primero en un acceso al segundo.

Por eso la frontera está en el despliegue y no en el código. La misma imagen se publica como dos servicios con identidades separadas, y el servicio público no tiene acceso a la base de datos.

La segunda regla es que el código del navegador nunca importa código de servidor, ni siquiera para tipos. Una sola constante importada de un módulo de servidor incluyó en el JavaScript del navegador, a través del grafo de dependencias, el SDK entero del modelo. Eran cientos de kilobytes de JavaScript inútil en cada visita. Ahora una orden de la integración continua comprueba esa regla.

Arquitectura

Los dos servicios comparten imagen y binario. Cada uno se ejecuta con su propia identidad, y de ella dependen todos sus permisos.

VisitanteSitio públicoInvitaciónPortalDatos

La misma imagen se despliega dos veces con identidades distintas. Al servicio público se le retira el acceso a la base de datos, así que un fallo en el sitio abierto no tiene ruta hacia lo que guarda el portal.

No hay registro abierto ni contraseñas propias. Se entra por invitación y con un solo proveedor de identidad. Las sesiones se revocan desde el servidor, no solo caducan.

Tamaño de archivo, peticiones por origen y validación de tipo se aplican antes de que nada llegue al modelo. El límite lo fija el servidor; el modelo no decide cuánto puede pedir.

La integración continua comprueba los tipos, ejecuta las pruebas, construye la imagen y la escanea. Una vulnerabilidad crítica aborta el despliegue antes de que exista un servicio nuevo.

La separación la impone el despliegue: dos servicios de la misma imagen, con permisos distintos.

Un documento que sube un cliente pasa primero por los límites de tamaño, tipo y frecuencia, y después por el modelo. Lo que el modelo devuelve se valida contra el esquema antes de escribirse, así que una extracción mal formada no llega a la base de datos.

Resultado

La plataforma sirve el sitio público, el portal interno, la debida diligencia y las cuentas por cobrar desde dos servicios con permisos distintos. La revisión documental que antes ocupaba a una persona ahora la propone el sistema, y la persona la confirma o la corrige.

Cada despliegue pasa por 2 243 pruebas unitarias en 144 archivos y 27 suites de extremo a extremo, entre ellas suites de ataque dedicadas.

Lo que aprendí

Separar por despliegue cuesta más que una comprobación dentro del código. Son dos servicios que configurar, dos identidades que mantener y un despliegue que puede quedar a medias entre versiones.

A cambio, la garantía no depende de que la aplicación se comporte como se espera. El servicio del sitio público no tiene credenciales de base de datos, haga lo que haga su código. Para un portal que guarda documentos de clientes, esa garantía justifica el coste de operar dos servicios.