Hardening de producción SaaS con datos sensibles

Hardening de producción para SaaS con datos sensibles cuesta entre 6,000 y 15,000 USD, tarda 2 a 4 semanas y cubre 5 áreas: red y firewall, autenticación con refresh tokens cortos, base de datos con Row Level Security real, audit log inmutable y disaster recovery con restore probado. Saltar uno de estos pilares es la causa principal de las filtraciones que se reportan en LATAM cada trimestre. Eres dueño de todo. Código. Datos. Infraestructura.

Si tu SaaS está en producción con clientes B2B y todavía no auditaste los 5 pilares, este artículo es el checklist operativo que aplicar en las próximas 4 semanas.

El error de tratar hardening como una checklist de HTTPS

La mayoría de los equipos PYME en LATAM entienden hardening como activar HTTPS, poner el firewall en la nube y configurar Cloudflare. Eso cubre solo la superficie. Las filtraciones que se reportan en la región vienen casi siempre de errores en otras 4 áreas:

• RBAC implementado solo en frontend, sin RLS real en base de datos
• Tokens de larga duración sin rotación, comprometidos por meses sin detectar
• Audit log faltante o modificable, imposibilita forensia post-incidente
• Backups que nunca se probaron en restore, descubres el día del incidente que están corruptos
• Rate limiting ausente en endpoints sensibles, permite enumeración por bot

Cubrir solo HTTPS y firewall sin estos 4 frentes es como cerrar la puerta de la casa con llave pero dejar las ventanas abiertas.

Los 5 pilares de hardening operativo

Cada control mínimo es el piso. Los controles deseables son lo que separa un SaaS B2B serio de uno que pasa la primera auditoría de cliente y se cae en la segunda.

El caso real: hardening de Hetzner Ashburn con DNS Cloudflare

En un proyecto reciente para una plataforma multi-tenant que sirve a 100 franquicias internacionales, Catalizadora aplicó el siguiente hardening sobre Hetzner CCX23 (4 vCPU, 16 GB) en Ashburn:

• UFW abierto solo 22, 80, 443; resto bloqueado en kernel
• fail2ban activado con regla de 5 intentos 401 = ban de 1 hora en SSH y nginx-auth
• SSH key only, password authentication completamente deshabilitada
• HSTS preload activado con max-age de 2 años
• Rate limiting en producción de 200 requests por segundo con burst 200 por IP
• DNS gestionado por Cloudflare API token con permiso scoped solo a una zone
• Let's Encrypt cert migrado desde DigitalOcean a Hetzner sin downtime
• Connection pooler de Supabase en session mode, no transaction mode

El hardening completo se aplicó en Sprint 1 dentro de un proyecto de 12 semanas. Las decisiones fueron documentadas, auditables y replicables a otros entornos. Cuando los datos se unifican, los problemas se anuncian solos.

Stack recomendado de hardening en LATAM

Para un SaaS B2B PYME en producción que serve menos de 100,000 usuarios:

• Hosting en Hetzner, DigitalOcean o Render, no AWS o GCP a menos que ya tengas equipo cloud
• Firewall en UFW directamente en VM o security groups del proveedor cloud
• WAF y DDoS protection con Cloudflare plan Pro (20 USD mensuales) suficiente para SaaS PYME
• Autenticación con Supabase Auth, Clerk o WorkOS, no rodar tu propia capa de auth desde cero
• Base de datos PostgreSQL con RLS y connection pooler en session mode
• Backups automáticos del proveedor más backup propio a S3 con cifrado al cliente
• Monitoreo con Sentry para errores y Better Stack para uptime y logs estructurados

Evitar al inicio: Kubernetes sin operador managed, Vault sin caso de uso claro y mTLS interna en lugar de service mesh administrada. Para SaaS PYME, complejidad cuesta más que la seguridad incremental que aporta.

Checklist de 30 días para hardening completo

Semana 1, auditoría y plan:

1. Inventario de cada endpoint, qué autenticación requiere y qué data devuelve
2. Inventario de cada tabla sensible, qué RLS tiene actualmente y a quién protege
3. Inventario de cada llave, token y credencial, dónde vive y cuándo rotó por última vez
4. Mapa de superficie de ataque visible desde fuera con nmap y scan automático

Semana 2 y 3, remediación priorizada:

1. Habilitar RLS en cada tabla sensible, escribir tests que confirmen que un usuario no ve data ajena
2. Implementar refresh tokens cortos y rotar todas las claves de API
3. Crear tabla de audit log append-only con trigger SHA-256
4. Configurar UFW, fail2ban, HSTS y rate limiting si no estaban
5. Habilitar MFA obligatoria para roles admin

Semana 4, verificación y documentación:

1. Pen test ligero externo con OWASP ZAP o Burp Suite comunidad
2. Restore desde backup completo a entorno paralelo, verificar integridad
3. Runbook de incidente documentado con quién hace qué en las primeras 4 horas
4. Comunicación al equipo de los nuevos controles y capacitación de 1 hora

Este checklist se puede ejecutar internamente o tercerizarse a Catalizadora dentro de una fase MAGIA Forge.

Errores comunes en hardening de SaaS LATAM

Cinco errores que vemos repetir al auditar plataformas en producción en LATAM:

1. RLS modelado pero nunca testeado con curl directo de un usuario malicioso
2. Backups corriendo pero nunca probados en restore completo
3. Audit log presente pero modificable por superuser, no append-only real
4. SSH con password todavía habilitado en algún servidor olvidado
5. Cloudflare en modo development o sin WAF activo en endpoints sensibles

Cada uno de estos 5 errores ha sido la causa real de incidentes que terminaron en pérdida de cliente B2B. La forma de evitarlos es ejecutar el checklist de 30 días con disciplina, no como un proyecto aislado sino como práctica recurrente cada trimestre.

Próximos pasos

Si tu SaaS B2B con datos sensibles necesita hardening completo aplicado en las próximas 4 semanas, MAGIA Forge entrega el proyecto en 12 semanas por 20,000 USD con hardening incluido desde la fase de Implementación. Si necesitas solo una auditoría rápida con plan de remediación priorizado, agenda llamada de 30 minutos, sin pitch deck, conversación real sobre tu plataforma. Contexto adicional en Wikipedia: Hardening (computing).