Infraestructura production-like

Infraestructura production-like

Esta seccion explica que necesita infraestructura para correr MedSync de forma segura con autenticacion basada en cookies. No es un tutorial para “prender produccion” en un solo paso. Es una guia para preparar un ambiente production-like, validarlo con evidencia y decidir si se puede avanzar.

La regla principal es sencilla:

La autenticacion basada en cookies no se considera production-ready hasta que funcione en HTTPS/domain real, con cookies Secure=true, CORS/CSRF reales, reset password invalidation probado, backups, observabilidad y rollback claro.

MedSync es un SaaS medico multi-tenant. El backend y el frontend actuales viven en carpetas con sufijo legacy, pero esas carpetas son los proyectos reales vigentes:

Componente	Ruta
Backend API	F:\HemiaAssistantGlobal\hemia-assistance-back-legacy
Frontend web	F:\HemiaAssistantGlobal\hemia-assistance-front-legacy
Documentacion web	F:\HemiaAssistantGlobal\medsync-docs
Documentacion tecnica interna de auth	F:\HemiaAssistantGlobal\docs\auth

Como leer esta seccion

Si estas preparando un ambiente nuevo, lee en este orden:

1. D2 production para juniors para entender el camino completo sin asumir experiencia previa.
2. Arquitectura para entender las piezas.
3. Prerequisitos para saber que debe existir antes de desplegar.
4. Variables de entorno para preparar backend y frontend.
5. CORS, CSRF y cookies para cerrar la parte delicada de autenticacion por cookies.
6. Rollout y rollback para ejecutar el plan.
7. QA smoke tests y Checklist production-ready para validar.

Si estas operando un incidente, ve directo a Incident response, Observabilidad y Backups y restore.

Que hace y que no hace

Este manual si hace:

• define la topologia esperada;
• enumera variables de entorno;
• explica las validaciones obligatorias de seguridad;
• ordena rollout y rollback;
• define smoke tests y criterios de aborto;
• explica que debe monitorearse.

Este manual no hace:

• no activa el modo de cookies por default en production-like o produccion;
• no toca produccion;
• no reemplaza secret manager;
• no inventa dominios reales;
• no valida SMTP por si solo;
• no marca production-ready.

Validaciones antes de produccion

No marques MedSync como production-ready si falta cualquiera de estas validaciones:

• El refresh cookie-only debe estar probado localmente y repetirse en production-like con cookies Secure=true.
• Browser real, DevTools o Playwright debe repetirse en production-like para comprobar cookies, storage, document.cookie y ausencia de Authorization.
• El plan de rollout/rollback debe estar aprobado; ese plan solo autoriza avanzar a validacion production-like, no a production-ready.
• Reset password invalidation debe probarse end-to-end con SMTP sandbox o intervencion humana autorizada.
• Dominios reales frontend/API deben estar cerrados antes de definir SameSite, Secure, Domain, CORS y CSRF finales.
• Tenant restricted/suspended/inactive debe validar el hard-block aprobado por CTO/Product: sin sesion, sin access cookie, sin refresh cookie, sin datos clinicos y con error generico.
• No se deben copiar valores de .env.local ni secretos historicos de ejemplos a produccion.

Estado del plan de despliegue

El plan operacional define rollout, rollback, matriz de variables, browser QA production-like, validacion de reset password invalidation, tenant hard-block, backups/restore, observabilidad y decision go/no-go. No despliega, no activa el modo de cookies en produccion y no marca production-ready. El modo local de desarrollo si usa D2 por default para evitar regresiones hacia Authorization.

El siguiente paso esperado es una validacion production-like o release candidate, ejecutada con HTTPS y dominio real o en un staging equivalente a produccion.

Resumen para junior

Local HTTP usa cookies dev sin Secure:

http://localhost:8080
http://127.0.0.1:3009
medsync_at_dev, medsync_rt_dev, medsync_csrf_dev

Production-like debe usar HTTPS y cookies Secure=true:

https://app.<dominio>
https://api.<dominio>
__Host-medsync_at, __Host-medsync_rt, __Host-medsync_csrf

En ambos casos, el frontend navegador no debe mandar Authorization. Si aparece Authorization, revisar primero comandos legacy, terminales viejas y residuos del navegador.

Decision CTO/Product: tenant restricted

Para el MVP/productivo inicial, tenant restricted/suspended/inactive en login se bloquea de forma dura. Tambien se bloquea usuario inactivo/bloqueado. El backend no debe emitir sesion ni cookies auth y no debe exponer datos clinicos.

La ruta /tenant-restricted se conserva para sesiones ya existentes que luego detecten tenantOperational.allowed=false, por ejemplo si el tenant cambia de estado durante una sesion activa o si /api/auth/session hidrata un tenant no operativo. No se implementa ahora un login limitado para tenant restricted.

Backlog futuro: Limited restricted tenant session for billing/self-service UX.

Que protege este manual

MedSync maneja datos personales, operativos y clinicos de tenants medicos. Por eso el despliegue productivo debe proteger:

• Credenciales de usuarios.
• Sesiones activas y refresh tokens.
• Cookies HttpOnly.
• Datos de tenant, roles y permisos.
• Datos clinicos, documentos, firmas, tratamientos, odontogramas, citas y archivos.
• Credenciales DB, SMTP, storage y servicios externos.
• Logs y backups con informacion sensible.

Reglas que no se negocian en produccion

• Produccion no debe usar el modo legacy de navegador como destino final.
• Produccion no debe devolver access token ni refresh token legibles por JavaScript.
• Produccion no debe enviar Authorization como auth de navegador.
• Produccion no debe usar CORS wildcard con credenciales.
• Produccion no debe tener CSRF apagado si las cookies autentican requests.
• Produccion no debe usar cookies auth sin Secure.
• Produccion no debe usar secretos default, placeholders ni valores copiados de ejemplos.
• Produccion no debe cachear endpoints de auth ni registrar cookies completas.

Paginas

1. Arquitectura
2. D2 production para juniors
3. Prerequisitos
4. Variables de entorno
5. Flujo de autenticacion con cookies
6. Backend deployment
7. Frontend deployment
8. Base de datos y migraciones
9. Reverse proxy, TLS y dominios
10. CORS, CSRF y cookies
11. Gestion de secretos
12. SMTP y correo
13. Observabilidad, logs y alertas
14. Backups y restore
15. QA smoke tests
16. Rollout y rollback
17. Incident response
18. Checklist production-ready