Cómo pienso sobre integraciones seguras de backend

La seguridad en las integraciones de backend generalmente falla en los bordes aburridos: un token que nunca rota, una línea de registro que imprime un encabezado, un rol de IAM que era "temporal".

Mi modelo mental

Pienso en cada integración como tres anillos concéntricos:

1. El secreto en sí — clave API, clave privada, contraseña de la base de datos.
2. La identidad que el secreto prueba — qué rol/principal/servicio.
3. El alcance al que está vinculada esa identidad — qué recursos, qué acciones, por cuánto tiempo.

Cada incidente que he visto fue un colapso del anillo 2 o del anillo 3, no del anillo 1. El secreto no se filtró; el alcance era demasiado amplio.

Postura por defecto

• Cada secreto proviene de un vault (Secrets Manager, Parameter Store, Vault). No se comitea ningún .env, no hay secretos en los registros de CI.
• Cada identidad está limitada al recurso + acción más estrechos que hacen que la función funcione. Si no puedo articular el alcance en una oración, es demasiado amplio.
• Cada token rota. Si la rotación es "difícil", eso es un error de diseño, no un error de operaciones.

La línea que te salva

La práctica de seguridad más subestimada es: registra identidades, no secretos, y registra decisiones de alcance en el momento en que se toman.

logger.info(
    "crm.lookup autorizado",
    extra={
        "principal": principal.id,
        "scope": ["crm:read:customer"],
        "resource": f"customer:{customer_id}",
        "reason": "fulfillment handler",
    },
)

Cuando algo sale mal a las 2 a.m., querrás saber qué identidad hizo qué. Nunca querrás que el secreto esté en el registro.