Rollout y Rollback

Rollout y rollback

Este plan no activa produccion. Prepara rollout, rollback y checklist production-like, pero no marca la autenticacion por cookies como production-ready. Se ejecuta cuando las pruebas locales, las validaciones en browser real y los controles humanos esten cerrados en production-like.

Alcance del plan

Este documento deja listo el plan tecnico para desplegar de forma segura. No despliega, no toca produccion, no activa el modo de cookies por default y no usa datos reales.

El siguiente paso esperado es una validacion production-like o release candidate.

Ruta corta para juniors

Antes de tocar un ambiente production-like, confirma que entiendes estas cuatro reglas:

1. Local HTTP usa cookies dev como medsync_at_dev; production-like usa HTTPS y cookies Secure=true.
2. El frontend navegador no debe mandar Authorization.
3. Access y refresh no deben aparecer en document.cookie, localStorage ni sessionStorage.
4. Si una validacion de seguridad falla, se aborta rollout y se corrige antes de continuar.

Para una explicacion paso a paso, usa D2 production para juniors.

Dominios objetivo

Frontend: https://app.<dominio>
API:      https://api.<dominio>
Docs:     opcional

Validaciones obligatorias:

• HTTPS obligatorio.
• Certificados validos.
• CORS allowlist exacta.
• CSRF origins exactos.
• Cookies Secure=true.
• Cookies __Host-* sin Domain.
• Path=/.
• SameSite=Lax si app/API comparten raiz de dominio.

Rollout

1. Preparacion: congelar alcance funcional, confirmar owners y revisar pruebas locales, browser QA y decision de tenant restricted.
2. Backup previo: tomar backup DB/storage y documentar punto de restore.
3. Secrets: confirmar secret manager o mecanismo infra equivalente; no copiar .env.local.
4. DB/migraciones: validar schema auth, session, refresh_token, forgot password y ausencia de fixtures QA vivos.
5. Backend: desplegar con env de autenticacion por cookies, CSRF y CORS exacto.
6. Frontend: compilar con flags de cookies y publicar en https://app.<dominio>.
7. Smoke tecnico: CSRF, CORS permitido/rechazado, session anonima, login tokenless, refresh cookie-only y logout.
8. Browser QA production-like: DevTools o Playwright en HTTPS/domain real.
9. Reset password invalidation: SMTP sandbox o humano autorizado para OTP.
10. Super Admin close: individual y masivo con usuarios QA ficticios.
11. Tenant hard-block: restricted/suspended/inactive e inactivo/bloqueado sin sesion ni cookies auth.
12. Flujo clinico minimo: doctor QA, paciente QA y mutacion clinica no destructiva con CSRF.
13. Monitoreo intensivo: 401/403/429/500, CSRF, CORS, refresh, login, logout y session.
14. Go/no-go: aplicar criterios de esta pagina.
15. Activacion controlada: solo cuando la validacion production-like este aprobada.
16. Post-deploy monitoring: registrar evidencia sin secretos.

Checklist minimo durante la activacion:

• DevTools cookies: access/refresh HttpOnly=true y Secure=true.
• DevTools console: document.cookie no muestra access/refresh.
• DevTools storage: no hay tokens ni contexto auth sensible.
• DevTools network: no existe Authorization.
• Mutaciones: tienen X-CSRF-Token.
• Reset password: invalida sesiones anteriores.

Browser QA production-like

Browser QA local cubrio el escenario HTTP. En production-like debe repetirse con HTTPS/domain real:

• access cookie HttpOnly=true.
• refresh cookie HttpOnly=true.
• cookies auth Secure=true.
• SameSite=Lax.
• Path=/.
• __Host-* sin Domain.
• document.cookie sin access/refresh.
• storage sin tokens ni contexto auth sensible.
• Network sin Authorization.
• mutaciones con X-CSRF-Token.
• refresh cookie-only con body {}.
• logout limpia cookies.
• Super Admin close produce 401 y cleanup.
• tenant restricted hard-block sin cookies.
• usuario inactivo hard-block sin cookies.

Parametrizacion Playwright:

$env:D2_BROWSER_FRONTEND_URL='https://app.<dominio>'
$env:D2_BROWSER_API_URL='https://api.<dominio>'
node scripts\qa\d2-browser-security-evidence.js

Validacion de reset password invalidation

Validacion obligatoria antes de production-ready:

• SMTP sandbox o mecanismo humano autorizado para OTP.
• Usuario QA logueado antes del reset.
• Ejecutar reset password.
• Access viejo falla.
• Refresh viejo falla.
• Password anterior falla.
• Password nueva funciona.
• Frontend limpia estado tras 401.
• No imprimir OTP/password/tokens.

Si no hay SMTP sandbox, registrar pendiente humano y no marcar production-ready.

Criterios de exito

• Login tokenless funciona.
• /api/auth/session hidrata usuario.
• Refresh cookie-only funciona.
• Logout limpia cookies.
• CSRF positivo/negativo funciona.
• CORS positivo/negativo funciona.
• No hay Authorization navegador.
• Storage sin tokens.
• Super Admin close funciona.
• Reset password invalidation funciona.
• Tenant restricted/suspended/inactive y usuario inactivo/bloqueado hacen hard-block en login sin sesion, sin access cookie, sin refresh cookie y sin datos clinicos.
• /tenant-restricted funciona solo para sesiones existentes que luego detectan tenantOperational.allowed=false.
• Browser QA production-like pasa en HTTPS/domain real.
• Backup/restore aprobado.
• Observabilidad minima activa.
• No hay incremento anormal de 500/401/403.

Criterios para abortar

• Refresh cookie-only falla en runtime.
• Login devuelve tokens al frontend.
• Cookies access/refresh no son HttpOnly.
• AUTH_COOKIE_SECURE=false en production-like.
• CORS wildcard con credentials.
• CSRF apagado o bypass evidente.
• Tenant restricted/inactive emite sesion o cookies auth en login.
• Tenant restricted/inactive expone datos clinicos.
• Browser QA production-like detecta Authorization, tokens en storage o access/refresh en document.cookie.
• Backup o restore no estan listos.
• Observabilidad minima no esta disponible.
• 500 en auth sostenidos.
• Reset password no invalida sesiones.
• DB/SMTP degradado.

Rollback seguro

Rollback no debe convertir legacy en destino final. Si hay que retroceder:

1. Pausar rollout.
2. Mantener CORS cerrado.
3. No apagar CSRF mientras cookies auth sigan activas.
4. Expirar cookies de autenticacion con atributos correctos.
5. Revocar sesiones/refresh tokens si hay riesgo.
6. Publicar frontend anterior o build corregido.
7. Revertir backend/env solo segun plan aprobado.
8. Ejecutar smoke post-rollback.
9. Documentar riesgo temporal y fecha de retiro si se reusa legacy.

Smoke post-rollback:

• login;
• /api/auth/session;
• logout;
• reset password invalidation si aplica;
• Super Admin close;
• CORS/CSRF;
• cookies de autenticacion expiradas;
• storage sin tokens persistidos como estado final.

Tabla de sintomas

Sintoma	Accion inmediata	Rollback requerido	Validacion
Login 403 masivo	Revisar CSRF/CORS origins.	No si config se corrige rapido.	Login QA y CSRF positivo/negativo.
Session 401 tras login	Revisar cookies, withCredentials, domain/path.	Si afecta usuarios reales y no hay fix rapido.	/api/auth/session autenticado.
Refresh 400	Detener rollout; confirmar contrato cookie-only.	Si no hay hotfix.	Refresh cookie-only OK.
Tokens en JSON	Detener inmediatamente.	Si backend no puede corregirse.	Login JSON tokenless.
Cookies sin HttpOnly	Detener inmediatamente.	Si no hay fix.	DevTools cookies.
CORS wildcard credentials	Corregir env/proxy.	Si expuesto publicamente.	Preflight negativo.
Tenant restricted emite cookies	Detener rollout; hard-block aprobado no se cumple.	Si no hay fix inmediato.	Login restricted sin sesion/cookies y error generico.
Browser QA muestra tokens en storage	Detener rollout.	Si no hay fix inmediato.	Storage sin tokens y sin Authorization.
Cookies sin Secure	Detener rollout.	Si no hay fix inmediato.	DevTools cookies Secure=true.
SMTP caido	Pausar reset/firma dependiente.	No necesariamente.	Envio sandbox/real OK.
DB errores	Activar incidente.	Segun severidad.	Health DB y smoke app.