Arquitectura Cero-Secretos: Cómo Minimizar tu Superficie de Ataque

La industria de seguridad se obsesiona con la rotación y el cifrado de secretos, pero pasa por alto la métrica más predictiva: el conteo. Una startup que maneja cuarenta secretos no es solo más vulnerable que una que maneja seis; es desproporcionadamente más vulnerable. La superficie de ataque crece de forma no lineal porque cada secreto introduce nuevas rutas de exposición: el archivo .env local, el sistema de CI/CD, la herramienta de gestión de secretos, el log accidental, el screenshot compartido en Slack, el desarrollador que se va.

Cuando hicimos la auditoría inicial de Pillar, listamos cada llave API, token, contraseña y certificado activo. El resultado fueron aproximadamente seis secretos. Comparado con el promedio de la industria de veinte a cincuenta para un SaaS de etapa temprana, esto representa una reducción de superficie de ataque de un orden de magnitud. Más importante aún: la carga operativa de mantenerlos es trivial. Un trimestre completo de rotación de secretos toma menos de una hora.

Esto no es accidente. Es el resultado directo de decisiones arquitectónicas tomadas con la pregunta: ¿podemos entregar esta funcionalidad sin sostener un secreto? En la mayoría de los casos, la respuesta es sí, si estás dispuesto a cambiar control por simplicidad.

Pagos sin llave de Stripe. En lugar de integrar la API de Stripe en un backend (lo que requiere una llave secreta del servidor), Pillar usa Stripe Payment Links y Stripe Checkout. El flujo de pago completo ocurre en infraestructura alojada por Stripe. El cliente nunca toca un servidor de Pillar para pagar. No hay llave secreta de Stripe en nuestro lado porque no hay código de servidor que la necesite. La única integración con Stripe es un webhook verificado por un secreto compartido aislado.

Email sin llave de Mailgun o SendGrid. Los formularios de contacto y captura usan Formspree, que recibe submissions vía un endpoint público y entrega los correos sin que Pillar gestione una llave de proveedor de email. Para emails transaccionales, Resend ofrece un modo público similar. Cada llave de proveedor de email eliminada es una llave que nunca puede filtrarse en un log o en un repositorio.

Base de datos sin credenciales y deploy sin llaves. Pillar opera con una arquitectura static-first: el contenido vive en archivos JSON versionados en GitHub y se sirve desde Cloudflare Pages. No hay base de datos en producción y, por lo tanto, no hay credenciales que rotar. Para escritura dinámica, Formspree o un Cloudflare Worker con D1 pueden manejar el caso sin exponer credenciales tradicionales. Cloudflare Pages se despliega vía el CLI de Wrangler ejecutado localmente: la autenticación vive en la máquina del desarrollador, no en un sistema de CI. No hay token de deploy que un atacante pueda exfiltrar de GitHub Actions porque GitHub Actions no tiene credenciales de producción. wrangler pages deploy es el comando completo.

Después de eliminar y delegar, queda un núcleo pequeño de secretos inevitables. En el caso de Pillar, el principal es el webhook signing secret de Stripe, que se usa para verificar que las notificaciones de eventos de pago provienen realmente de Stripe y no de un atacante simulando llamadas. Este secreto no puede delegarse: tiene que vivir en algun lado de tu lado para ejecutar la verificación criptográfica.

La práctica estándar es poner ese secreto en un archivo .env de tu aplicación principal. Esto es exactamente lo que la Pila Cero-Secretos rechaza. En su lugar, el secreto vive en un Cloudflare Worker dedicado y aislado, configurado como variable de entorno cifrada vía wrangler secret put. Ese Worker hace una sola cosa: recibir webhooks de Stripe, verificar la firma, y registrar el evento. Nada más tiene acceso al secreto. Si el resto del sitio se ve comprometido, el secreto de webhook permanece intacto.

Este patrón se generaliza: para cualquier secreto inevitable, pásale un Worker dedicado con una superficie mínima. El Worker es tu permetro reducido. Comparado con un secreto compartido en una aplicación monolítica con docenas de endpoints, el radio de explosión se reduce a una función con un solo propósito auditable.

La arquitectura Cero-Secretos tiene compromisos reales. Cuando delegas pagos a Stripe Payment Links, pierdes flexibilidad sobre la UI del checkout. Cuando usas Formspree, no controlas la entrega del email. Cuando operas sin base de datos, ciertas funcionalidades dinámicas requieren rearquitectura. Para muchos productos, estos compromisos son inaceptables; necesitan el control que los secretos compran.

Pero para una clase grande de negocios, especialmente operaciones lean de uno o dos fundadores, los compromisos son enormemente favorables. Ganas: superficie de ataque cercana a cero, carga operativa trivial, deploys reproducibles desde cualquier máquina con el CLI correcto, ningún estado de credenciales que mantener en sincronía entre desarrolladores, y una postura de seguridad que un equipo de cumplimiento puede auditar en una hora.

El verdadero costo de mantener veinte secretos no es la rotación: es el peso cognitivo permanente de saber que tienes veinte caminos potenciales hacia el compromiso. La Pila Cero-Secretos no es minimalismo por estética; es minimalismo por escalabilidad operativa.