Módulo 5: Credential And Secrets Security
3. Higiene de credenciales y mínimo privilegio
Descripción
Al terminar esta lección vas a poder auditar una credencial de producción como lo hace un operador con experiencia: sabiendo qué permisos tiene frente a qué permisos usa, quién la usa, cuándo se rotó por última vez y quién responde por ella. Vas a entender el principio de mínimo privilegio —qué es, por qué reduce el daño en lugar de la probabilidad, y cómo se aplica a una llave de API concreta—. Vas a saber crear cuentas de servicio dedicadas en vez de reutilizar la cuenta personal de alguien. Vas a tener un procedimiento de rotación sin caída que puedes ejecutar en una instancia con 4.000 ejecuciones diarias sin parar la operación. Y vas a usar la auditoría integrada de n8n para encontrar las credenciales que nadie usa y que siguen siendo válidas.
Esto importa más que ninguna otra lección del módulo, y no es énfasis retórico. Las lecciones 2, 4 y 5 tratan de dónde vive el secreto, que es un problema mayormente resuelto: si guardaste tus llaves como credenciales de n8n, ya hiciste el 80% de ese trabajo. Esta lección trata de qué puede hacer el secreto, y ahí es donde están los desastres reales. Una llave perfectamente cifrada, guardada con todo el cuidado del mundo, que resulta tener permisos de administrador sobre el ERP de la empresa, es una bomba con el temporizador puesto. El cifrado no la desactiva. Solo el mínimo privilegio lo hace.
Conexión con el módulo: la lección 2 te dio el modelo de almacenamiento —qué es una credencial por dentro y qué protege el cifrado—. Esta lección opera sobre el contenido de esa credencial: los permisos que lleva en el sistema externo, que el cifrado ni conoce ni protege. Es la defensa 2 y la 3 de la lección 1 trabajando juntas: quién puede usar la llave, y cuánto daño hace si igual se escapa. Las lecciones 4 y 5 van a cambiar de dónde sale el valor de la credencial, pero no cambian nada de lo que ves aquí: una llave de administrador guardada en HashiCorp Vault sigue siendo una llave de administrador. La lección 6 aplica la misma idea del lado de la instancia —mínimo privilegio para las personas, no para las llaves—. Y la lección 8 va a verificar que erp_api quedó reducida de verdad.
La llave maestra del conserje
Vamos con la imagen, porque es la que hace que el principio deje de ser una frase de manual.
Piensa en un edificio de oficinas. Trabaja ahí un conserje que riega las plantas del piso 4 todos los martes. Para hacer su trabajo necesita entrar a las oficinas del piso 4, y nada más. Pero cuando lo contrataron, administración le dio la llave maestra del edificio: abre los 12 pisos, el cuarto de servidores, la caja fuerte de la recepción y el archivo de recursos humanos.
¿Por qué se la dieron? Por una razón perfectamente humana: pedir una llave que abra solo el piso 4 implicaba llenar un formulario, esperar al proveedor de cerraduras y coordinar con seguridad. Tres días. La llave maestra estaba en un cajón y se entregaba en tres minutos. Nadie tomó una mala decisión; se tomó la decisión rápida, que es lo que se toma cuando hay que empezar el lunes.
Ahora piensa en las consecuencias, y fíjate bien en cuáles son:
No es más probable que el conserje pierda la llave por ser maestra. La pierde con la misma probabilidad que perdería la del piso 4. Un llavero se cae de un bolsillo con la misma frecuencia sin importar qué abra.
Lo que cambia es qué pasa cuando la pierde. Si perdió la llave del piso 4, alguien puede regar unas plantas sin permiso. Si perdió la maestra, alguien puede entrar al cuarto de servidores y al archivo de recursos humanos.
Ahí está el principio completo, y esta distinción es la que hay que grabar:
El mínimo privilegio no reduce la probabilidad de que algo salga mal. Reduce cuánto duele cuando sale mal.
erp_api en Terra Market es esa llave maestra. Tiene rol de administrador en el ERP: puede leer, escribir, borrar y cambiar la configuración del sistema. ¿Qué necesita? inventory-update la usa para leer el inventario y order-sync la usa para crear pedidos. Nadie borra nada. Nadie cambia la configuración. Pero la llave puede, y por eso el peor escenario posible de Terra Market hoy no es "alguien lee nuestro inventario", es "alguien borra el ERP".
Qué es el mínimo privilegio, con anatomía
Definámoslo con precisión, porque la frase se repite mucho y se aplica poco.
El principio de mínimo privilegio dice que toda identidad —una persona, un programa, una llave de API— debe tener exactamente los permisos que necesita para hacer su trabajo, y ni uno más, durante el tiempo que los necesita, y ni un minuto más.
Fíjate en las dos dimensiones, porque casi todo el mundo recuerda solo la primera:
Dimensión 1 — el alcance. Qué operaciones puede hacer y sobre qué recursos. Una llave que solo lee es más chica que una que escribe. Una que lee solo la colección de inventario es más chica que una que lee todo. Una que lee el inventario de una sola tienda es más chica todavía.
Dimensión 2 — el tiempo. Cuánto vive la credencial antes de expirar o de ser rotada. Una llave que dura 90 días expone menos que una que dura para siempre, porque si se filtró y nadie lo notó, el atacante pierde el acceso solo. Esta dimensión es la que la rotación cubre, y por eso rotación y mínimo privilegio son la misma idea vista desde dos ángulos.
Y una tercera que a veces se cuenta aparte y conviene tener presente:
Dimensión 3 — la identidad. Quién es el titular. Una llave asociada a una cuenta de servicio dedicada expone menos que una asociada a la cuenta personal de la líder de operaciones, porque la cuenta personal probablemente tiene permisos que no vienen de la automatización sino del cargo.
La anatomía de una credencial "bien dimensionada", entonces, tiene cuatro propiedades que puedes verificar una por una:
| Propiedad | Pregunta que responde | Estado deseable |
|---|---|---|
| Alcance | ¿Qué puede hacer y sobre qué? | Solo las operaciones que el workflow ejecuta |
| Duración | ¿Cuándo caduca o se rota? | Una fecha concreta, no "nunca" |
| Identidad | ¿A nombre de quién está? | Una cuenta de servicio, no una persona |
| Dueño | ¿Quién responde por ella? | Una persona con nombre, del equipo |
Fíjate en que las dos últimas parecen contradecirse y no lo hacen: la credencial está a nombre de una cuenta de servicio (no de una persona), pero tiene un dueño humano que la administra. Son cosas distintas. La cuenta de servicio es la identidad técnica; el dueño es la responsabilidad organizativa.
La distancia entre lo que TIENE y lo que USA
Volvamos al inventario de la lección 1, porque ahora podemos leerlo con otros ojos. Estas eran las dos columnas que separamos a propósito:
| Credencial | Permisos que TIENE | Permisos que USA | Distancia |
|-------------|-----------------------------|-------------------------|-----------|
| erp_api | Administrador (todo el ERP) | Leer inventario, | ENORME |
| | | crear pedidos | |
| carrier_api | Lectura de envíos | Lectura de envíos | ninguna |
| llm_token | Uso del modelo | Uso del modelo | ninguna* |
| store_api | Por confirmar | Leer catálogo, | ? |
| | | actualizar existencias | |
| smtp_notify | Enviar correo | Enviar correo | ninguna |
Esa columna nueva —distancia— es la métrica central de la lección. Mide el hueco entre el poder que una credencial tiene y el que ejerce. Y ese hueco es, literalmente, la superficie de daño extra que estás llevando sin recibir nada a cambio.
Tres lecturas de la tabla:
carrier_api y smtp_notify están bien. Distancia cero. Lo que pueden hacer es lo que hacen. Que sean las dos credenciales más aburridas del inventario es exactamente la señal de que están bien dimensionadas.
erp_api es el problema. La distancia es enorme y el recurso es el sistema más crítico de la empresa. Es la fila que hay que arreglar primero.
store_api es el problema oculto. "Por confirmar" no significa "probablemente esté bien". Significa que no sabes, y en seguridad no saber se trata como el peor caso hasta que se compruebe otra cosa. Esta fila es una tarea concreta de media hora: entrar al panel de la tienda y mirar qué alcance tiene esa credencial.
Y el asterisco de llm_token: la distancia en permisos es cero —solo puede usar el modelo—, pero le falta la dimensión que este cuadro no muestra, que es el límite de gasto. Esa es la lección 7, y es un buen ejemplo de que "mínimo privilegio" en una llave de IA incluye una dimensión económica que no existe en las demás.
Las cuatro preguntas de la auditoría
Auditar una credencial no es un ritual complicado. Son cuatro preguntas, y lo difícil no es responderlas: es acordarse de hacerlas. Vamos una por una con el ejemplo de Terra Market.
Pregunta 1 — ¿Qué workflows la usan?
Esta responde si la credencial sirve para algo y qué se rompería al tocarla.
Cómo se responde. En n8n puedes revisar los workflows que referencian cada credencial. Y hay un atajo mucho mejor: la auditoría integrada. Según la documentación, n8n trae un comando de auditoría que genera cinco reportes —credenciales, base de datos, sistema de archivos, nodos e instancia— y el de credenciales reporta específicamente tres riesgos:
- Credenciales que ningún workflow usa.
- Credenciales que ningún workflow activo usa.
- Credenciales que ningún workflow activo recientemente usa.
Se ejecuta de tres formas, según la documentación: con el comando n8n audit en la línea de comandos, con una llamada POST al endpoint /audit de la API (autenticándote como dueño de la instancia), o agregando el nodo n8n a un workflow y eligiendo Resource > Audit y Operation > Generate. Esa última forma es especialmente cómoda para operar: puedes programar la auditoría como un workflow que corre cada mes y te manda el reporte.
Qué hacer con la respuesta. Una credencial que ningún workflow usa es riesgo sin beneficio: sigue siendo válida en el sistema externo, sigue abriendo lo que abre, y no aporta nada. La regla es revocarla en el sistema externo y borrarla de n8n, en ese orden. Y ojo con un matiz: "no la usa ningún workflow activo" no siempre significa que sobre —puede ser de un workflow estacional que se activa en temporada alta—, así que antes de revocar, pregunta. Lo que sí es siempre cierto es que merece una decisión explícita, no el olvido.
Pregunta 2 — ¿Qué permisos tiene, de verdad?
Esta es la pregunta que más gente responde mal, y el error tiene una forma muy específica: se responde con lo que la credencial hace en lugar de con lo que puede hacer.
Cómo se responde. No en n8n. n8n guarda la llave, pero no sabe qué permisos tiene esa llave en el ERP: eso lo decide el ERP. Así que la respuesta está en el panel del sistema externo, en su sección de llaves de API, tokens o cuentas de servicio.
Para erp_api, el procedimiento sería: entrar al panel del ERP, buscar la llave por su nombre o su prefijo, y leer qué rol o qué alcances tiene asignados. Qué esperar: en el caso de Terra Market, encontrarías un rol llamado algo como "Administrator" o "Full access", que es exactamente el hallazgo.
Un detalle que ahorra sustos: el vocabulario varía muchísimo entre sistemas. Algunos hablan de roles (administrador, editor, lector), otros de alcances o scopes (orders:read, orders:write, inventory:read), otros de permisos granulares por recurso. Son formas distintas de expresar lo mismo. Lo que buscas siempre es la lista de operaciones permitidas, se llame como se llame en ese panel.
Pregunta 3 — ¿Cuándo se rotó por última vez?
Esta responde la dimensión del tiempo.
Cómo se responde. A veces el panel del sistema externo muestra la fecha de creación de la llave, que es una buena aproximación si nunca se rotó. Si no, la respuesta honesta suele ser "no sé", y eso ya es información: una llave sin fecha conocida de rotación se trata como si nunca se hubiera rotado.
Qué hacer con la respuesta. Fijar una cadencia y una fecha. Volvemos a esto en la sección de rotación.
Pregunta 4 — ¿Quién es su dueño?
Esta es la más barata de responder y la que más orden trae.
El dueño de una credencial es una persona con nombre que se hace responsable de tres cosas: decidir quién la usa, rotarla en su fecha, y responder cuando aparece algo raro. No es quien la creó, ni quien más la usa: es quien responde por ella.
Por qué importa tanto. Porque sin dueño, cada una de las decisiones anteriores queda huérfana. ¿Quién autoriza bajar erp_api de administrador a lectura? ¿Quién avisa a los ocho que tienen la llave vieja cuando se rote? ¿A quién se le escribe cuando el ERP reporta un acceso desde una IP desconocida a las tres de la mañana? Si la respuesta a esas tres preguntas es "al equipo", en la práctica la respuesta es "a nadie", y las cosas no pasan.
Y una regla que vale la pena adoptar en Terra Market: una credencial sin dueño no entra a producción. Es una regla barata de cumplir —es poner un nombre en una tabla— y corta de raíz la deriva que produjo los tres hallazgos de la lección 1.
Ejemplo trabajado: reducir el alcance de erp_api sin romper producción
Vamos con la parte que da miedo y tiene método. Bajar los permisos de una credencial que usan dos workflows con miles de ejecuciones diarias suena a apagar la luz mientras alguien opera. No lo es, si lo haces en el orden correcto.
El objetivo: pasar erp_api de administrador a exactamente lo que necesita, sin que order-sync ni inventory-update fallen ni una ejecución.
Recuerda: tú haces esto en tu instancia y en tu ERP; la guía no ejecuta nada.
Paso 1 — Averigua qué operaciones ejecuta de verdad. Antes de decidir el alcance nuevo, necesitas la lista exacta de operaciones. No la adivines: obsérvala. Abre los dos workflows y recorre cada nodo que usa erp_api, anotando el método HTTP y la ruta:
Operaciones observadas de erp_api — Terra Market
order-sync
- POST /api/v1/orders → crear un pedido
- GET /api/v1/customers/{id} → leer datos del cliente
inventory-update
- GET /api/v1/inventory → leer existencias
- GET /api/v1/products/{sku} → leer un producto
Total: 1 operación de escritura (crear pedidos), 3 de lectura.
Ninguna operación de borrado. Ninguna de configuración.
Qué esperar: una lista corta. Casi siempre lo es, y ese es justamente el punto —una llave de administrador que ejecuta cuatro operaciones es la norma, no la excepción—. Si tu instancia tiene observabilidad de las llamadas salientes (el módulo 4), puedes cruzar esta lista contra lo que se llamó de verdad en el último mes, que es todavía mejor que leer los workflows: cubre las ramas que solo se ejecutan en casos raros.
Paso 2 — Traduce la lista al vocabulario de tu ERP. Ahora conviertes esas operaciones en el modelo de permisos del sistema externo. Con el vocabulario típico de alcances quedaría así:
Alcance mínimo propuesto para erp_api:
orders:write (crear pedidos)
customers:read (leer clientes)
inventory:read (leer existencias)
products:read (leer productos)
Lo que se elimina respecto del rol de administrador:
orders:delete, inventory:write, products:write, customers:write,
settings:*, users:*, y todo lo demás del sistema.
Fíjate en lo que acaba de pasar: pasaste de "puede hacer todo en el ERP" a "puede crear pedidos y leer tres colecciones". El peor escenario de una fuga cambió de "nos borran el ERP" a "alguien lee inventario y crea pedidos falsos". Sigue siendo malo —crear pedidos falsos es un problema real— pero es reversible, mientras que un borrado masivo puede no serlo.
Paso 3 — Crea una credencial NUEVA, no modifiques la vieja. Este es el paso que hace que la operación sea segura, y es contraintuitivo, así que vale la pena el porqué.
La tentación es entrar al ERP y bajarle los permisos a la llave existente. Si te equivocaste en el paso 1 —olvidaste una operación que ocurre solo el último día del mes—, order-sync empieza a fallar en producción y tienes que revertir bajo presión.
En cambio, si creas una llave nueva con el alcance reducido y dejas la vieja intacta:
- Puedes probar la nueva sin tocar nada de lo que está corriendo.
- Si algo falla, la vuelta atrás es cambiar un selector en un nodo, no re-negociar permisos con el administrador del ERP.
- La llave vieja sigue ahí como red de seguridad hasta que confirmes que la nueva basta.
En el ERP, entonces: crea una llave nueva con los cuatro alcances del paso 2. En n8n, crea una credencial nueva con esa llave, con un nombre claro: erp_api_scoped. Qué esperar: ahora tienes dos credenciales en la lista, la vieja y la nueva, y ningún workflow usa la nueva todavía. Eso está bien: es el estado intermedio del procedimiento.
Paso 4 — Cambia un solo workflow y observa. No los dos. Empieza por el de menor riesgo, que aquí es inventory-update —solo lee—. Cambia sus nodos para que usen erp_api_scoped en lugar de erp_api, guarda, y deja correr.
Qué esperar: las ejecuciones de inventory-update siguen en verde y las existencias se siguen actualizando en la tienda. Si algo falla, vas a ver un error de autorización (típicamente un 403 del ERP) que te dice exactamente qué operación no está permitida —y esa es información valiosa, no un fracaso: acabas de descubrir una operación que tu inventario del paso 1 no incluía—. En ese caso, agregas el alcance faltante a la llave nueva y vuelves a probar.
Deja pasar al menos un ciclo completo de operación —un día entero si el workflow tiene comportamiento distinto por horario, o una semana si hay algo mensual— antes de dar el paso siguiente. La prisa aquí no compra nada.
Paso 5 — Cambia el segundo workflow. Con inventory-update estable, haz lo mismo con order-sync. Este tiene la operación de escritura, así que observa con más atención: confirma no solo que las ejecuciones estén en verde, sino que los pedidos estén llegando al ERP. Una llamada que devuelve 200 sin crear nada es un fallo silencioso, y el módulo 3 te dio las herramientas para detectarlo.
Paso 6 — Revoca la llave vieja. Aquí se cierra el círculo, y es el paso que más se olvida.
Cuando los dos workflows llevan tiempo estables con erp_api_scoped, entra al ERP y revoca la llave vieja. No la dejes "desactivada por si acaso": revócala. Después borra la credencial erp_api de n8n.
Y fíjate en el beneficio extra, que resuelve el hallazgo 1 de la lección 1: la llave que ocho personas tenían en su chat acaba de dejar de funcionar. No hiciste falta pedirles que la borraran; la volviste inútil. Rotar y reducir el alcance son dos operaciones que, hechas juntas, resuelven el problema de la llave que circuló sin depender de la memoria de nadie.
Paso 7 — Actualiza el inventario. La fila de erp_api en tu tabla cambia:
| Credencial | Permisos que TIENE | Permisos que USA | Distancia | Última rotación | Dueño |
|-----------------|-----------------------------------------|------------------|-----------|-----------------|--------------|
| erp_api_scoped | orders:write, customers:read, | los mismos | ninguna | <hoy> | <un nombre> |
| | inventory:read, products:read | | | | |
Distancia: ninguna. Rotación: hoy. Dueño: con nombre. Esa fila es el objetivo de la lección hecho realidad, y es lo que la lección 8 va a verificar.
Cuentas de servicio: la credencial no es de una persona
Hay un patrón que aparece en casi todas las instancias heredadas y que conviene nombrar: la credencial que está a nombre de alguien.
Sucede así. Cuando se construyó order-sync, la persona que lo armó necesitaba una llave del ERP. Tenía su propio usuario, generó una llave desde su cuenta, y funcionó. Nadie hizo nada mal.
Los problemas aparecen después, y son tres:
Problema 1: los permisos vienen del cargo, no de la tarea. Si esa persona es la líder de operaciones, su cuenta tiene permisos amplios porque su trabajo los requiere. La llave hereda esos permisos, y de golpe order-sync puede hacer todo lo que la líder de operaciones puede hacer, que es muchísimo más de lo que un sincronizador de pedidos necesita. La distancia entre TIENE y USA nace enorme por construcción.
Problema 2: la persona se va, y la automatización se cae. El día que esa persona deja Terra Market, alguien de sistemas desactiva su cuenta —correctamente— y order-sync deja de funcionar sin que nadie entienda por qué. La causa raíz tarda horas en encontrarse porque nadie conecta "se fue Ana" con "los pedidos no llegan al ERP".
Problema 3: la trazabilidad miente. El registro del ERP dice que la líder de operaciones creó 3.200 pedidos el martes. No es cierto: los creó un workflow. Cuando llegue el día de investigar algo raro, ese registro no te ayuda; te confunde.
La solución es una cuenta de servicio: una identidad en el sistema externo que no pertenece a una persona sino a un proceso. Se llama, por ejemplo, svc-n8n-order-sync, no tiene contraseña de acceso interactivo, tiene solo los permisos de su tarea, y su titular administrativo es el equipo.
Las tres propiedades que la hacen valiosa son el reverso exacto de los tres problemas:
- Sus permisos vienen de la tarea, así que empiezan mínimos por diseño.
- No depende de que nadie siga en la empresa. Las personas rotan; el proceso sigue.
- La trazabilidad es honesta. El registro dice
svc-n8n-order-sync, y eso es exactamente lo que pasó.
Un matiz de honestidad: no todos los sistemas tienen cuentas de servicio. Algunos SaaS pequeños solo generan llaves de API asociadas a un usuario, y no hay otra opción. En ese caso, el patrón de reemplazo es crear un usuario dedicado a la automatización —con su propio correo, del estilo automation@terramarket.example, y con los permisos mínimos— en lugar de usar el de una persona. No es tan limpio, pero recupera las tres propiedades. Y donde ni eso se pueda, documéntalo en el inventario como una limitación conocida en vez de dejarlo implícito. Una deuda escrita se paga algún día; una deuda invisible, no.
Rotación: la dimensión del tiempo
Definamos primero, porque el término se usa con dos sentidos distintos y conviene separarlos.
Rotar una credencial es reemplazar su valor por uno nuevo e invalidar el anterior. Es lo que haces cuando cambias la llave del ERP por una llave nueva y revocas la vieja. Ojo: esto es distinto de la rotación de llaves de cifrado de la lección 2, que cambia la llave con la que n8n cifra sus credenciales. Mismo verbo, dos objetos. Aquí hablamos de rotar la credencial en sí.
Por qué se rota si no pasó nada. Esta es la pregunta razonable, y tiene una respuesta buena. Se rota porque no sabes si pasó algo. Una llave que circuló por chat entre ocho personas hace dos años pudo haber terminado en cualquier lado, y no hay forma de comprobar que no. La rotación periódica no responde "¿se filtró?"; hace que la pregunta importe menos, porque una llave filtrada hace nueve meses ya no sirve. Es exactamente la misma lógica de cambiar la cerradura cuando te mudas a un departamento: no sospechas del inquilino anterior, simplemente no sabes cuántas copias existen.
Cada cuánto. No hay un número universal, y desconfía de quien te dé uno sin preguntarte nada. Una forma sensata de decidirlo es por consecuencia:
| Tipo de credencial | Cadencia razonable | Por qué |
|---|---|---|
| Llave con permisos de escritura en un sistema crítico | Cada 3–6 meses | El daño de una fuga es alto |
| Llave de solo lectura de datos no sensibles | Cada 12 meses | El daño es acotado |
| Token de un proveedor de IA con gasto | Cada 3–6 meses | Además del dato, cuesta dinero (lección 7) |
| Cualquier credencial tras la salida de alguien que la conocía | De inmediato | La lista de quién la tiene cambió |
| Cualquier credencial que apareció en un lugar público | De inmediato | Se considera comprometida |
Las dos últimas filas no son cadencias: son disparadores. Y esa distinción es útil de tener clara: la rotación programada es higiene; la rotación disparada es respuesta a un evento. Un equipo maduro tiene las dos.
El procedimiento de rotación sin caída
Aquí está lo que hace que la rotación se pueda ejecutar en una instancia con 4.000 ejecuciones diarias sin parar nada. La clave es una propiedad de la mayoría de los sistemas externos que la gente no aprovecha: puedes tener dos llaves válidas al mismo tiempo.
Si esa propiedad existe, el procedimiento es este:
- Crea la llave nueva en el sistema externo, sin tocar la vieja. Ahora hay dos llaves válidas y todo sigue funcionando con la vieja.
- Actualiza el valor de la credencial en n8n con la llave nueva. A partir de la siguiente ejecución, los workflows usan la nueva. La vieja sigue válida pero ya nadie la usa.
- Observa un ciclo completo. Confirma que las ejecuciones siguen en verde y que los efectos ocurren de verdad (no solo que el
200llega). - Revoca la llave vieja en el sistema externo. Ahora sí, la vieja deja de funcionar.
- Anota la fecha en el inventario.
Ese solapamiento entre los pasos 1 y 4 es lo que elimina la caída: en ningún momento el workflow se queda sin una llave válida. Es la misma lógica del paso 3 al 6 del ejemplo trabajado de arriba, y no es casualidad: reducir el alcance y rotar son el mismo procedimiento, porque los dos consisten en reemplazar una credencial por otra mejor sin interrumpir.
¿Y si el sistema externo no permite dos llaves a la vez? Entonces hay una ventana inevitable entre revocar la vieja y guardar la nueva, y esa ventana se planea: una hora de baja actividad, aviso al equipo, y el valor nuevo ya copiado y listo para pegar. Son treinta segundos de riesgo controlado, no una improvisación. Anótalo en el inventario: "este sistema no soporta solapamiento" es un dato que ahorra tiempo la próxima vez.
La separación por entorno (y dónde está desarrollada)
Un principio que pertenece a esta familia y que conviene nombrar aunque su desarrollo esté en otra guía.
Si Terra Market tuviera un entorno de pruebas —y debería—, la regla de higiene sería que ese entorno nunca use las llaves reales. La llave del ERP de producción vive solo en la instancia de producción; el entorno de pruebas usa una llave de un ERP sandbox, con datos de mentira. Así, una prueba mal hecha no toca los pedidos reales, y un desarrollador que necesita probar algo no necesita, ni siquiera de paso, acceso a los datos verdaderos.
Es mínimo privilegio aplicado a los entornos en lugar de a las operaciones: el entorno de pruebas necesita poder probar, no poder tocar producción.
El flujo completo está en la guía de Git y Entornos, módulo 4 —cómo se configuran las credenciales por entorno, por qué una credencial no se puede copiar cifrada de un entorno a otro (porque cada entorno cifra con su propia llave), y el patrón de "una referencia, tres valores"—. No lo vamos a reescribir aquí: este módulo trata una instancia de producción única y a fondo.
Lo que sí te llevas de aquí es el criterio: cuando en tu inventario una credencial aparezca usada tanto en pruebas como en producción, eso es un hallazgo, del mismo tipo que el rol de administrador. Anótalo en la tabla.
Errores comunes
Responder "qué permisos tiene" con "qué permisos usa" (conceptual, y el error central de la lección). Qué pasa: alguien llena el inventario poniendo en la columna de permisos lo que el workflow hace —"lee inventario"— sin entrar al panel del sistema externo a comprobar qué alcance tiene la llave. El inventario queda lleno de credenciales que parecen bien dimensionadas y no lo están. Por qué pasa: la respuesta correcta está en otro sistema, requiere credenciales de administrador de ese sistema, y toma tiempo; la respuesta cómoda está a la vista en el workflow. Cómo detectarlo: si llenaste la columna de permisos sin abrir el panel del ERP, de la tienda o del proveedor, es esto. Cómo corregirlo: la columna "permisos que tiene" solo se llena mirando el sistema externo. Si no puedes mirarlo hoy, escribe "por confirmar" —que es honesto— en vez de una suposición —que es peor que un hueco, porque da falsa tranquilidad—.
Modificar los permisos de la credencial en producción, en caliente (práctico, y causa incidentes). Qué pasa: alguien entra al ERP, le baja el rol a erp_api de administrador a lectura, y order-sync empieza a fallar porque también escribía. Ahora hay un incidente en producción y hay que revertir bajo presión, con el administrador del ERP en otra reunión. Por qué pasa: parece el camino directo, y modificar es más rápido que crear una llave nueva y migrar workflows. Cómo detectarlo: si tu plan para reducir permisos empieza con "entro al ERP y cambio el rol", es esto. Cómo corregirlo: llave nueva con el alcance reducido, credencial nueva en n8n, migración workflow por workflow empezando por el de menor riesgo, observación de un ciclo completo, y recién entonces revocar la vieja. La llave vieja intacta es tu vuelta atrás, y cuesta cero tenerla.
Rotar sin revocar la llave vieja (práctico, y anula el ejercicio). Qué pasa: se crea la llave nueva, se actualiza n8n, todo funciona, y la llave vieja se queda válida "por si acaso" —o simplemente porque nadie volvió al panel a cerrarla—. Por qué pasa: el paso de revocar ocurre días después del resto, cuando la sensación de tarea terminada ya llegó. Cómo detectarlo: entra al panel del sistema externo y cuenta cuántas llaves activas hay; si hay más llaves válidas que credenciales en uso, tienes sobras. Cómo corregirlo: la rotación no termina cuando la llave nueva funciona; termina cuando la vieja deja de funcionar. Agenda el paso de revocación como una tarea con fecha, no como un "después lo cierro". Una llave rotada pero no revocada es exactamente el mismo riesgo que antes, con el trabajo hecho a medias.
Creer que el cifrado sustituye al mínimo privilegio (conceptual). Qué pasa: "nuestras credenciales están cifradas en la base de datos, así que estamos bien" — y erp_api sigue con permisos de administrador. Por qué pasa: el cifrado es visible, técnico y satisfactorio; el mínimo privilegio es una conversación con el administrador de otro sistema. Cómo detectarlo: si tu respuesta a "¿están seguras las credenciales?" menciona el cifrado y no menciona permisos, es esto. Cómo corregirlo: son dos defensas distintas contra dos escenarios distintos. El cifrado protege contra alguien que obtiene la base de datos. El mínimo privilegio protege contra alguien que obtiene la llave —por cualquier vía: un chat, un export mal guardado, un empleado que se va—. La segunda situación es mucho más común que la primera, y el cifrado no hace absolutamente nada contra ella.
Dejar credenciales huérfanas porque "no molestan" (práctico). Qué pasa: la auditoría reporta tres credenciales que ningún workflow usa, alguien las mira, no reconoce ninguna, y las deja "hasta averiguar qué eran". Siguen ahí dos años después. Por qué pasa: borrar algo que no entiendes se siente arriesgado, y no borrarlo no tiene costo visible. Cómo detectarlo: corre n8n audit y mira el reporte de credenciales. Cómo corregirlo: una credencial huérfana es riesgo sin beneficio —sigue siendo válida en el sistema externo y no aporta nada—. El procedimiento es preguntar al equipo con una fecha límite ("si nadie reclama estas tres para el viernes, las revoco"), revocarlas en el sistema externo, y después borrarlas de n8n. En ese orden, porque borrar la credencial de n8n sin revocar la llave deja la llave viva y sin dueño: lo peor de los dos mundos.
Confiar en que "el sistema externo tiene registros, así que sabríamos" (conceptual). Qué pasa: se justifica no reducir permisos con que el ERP registra todos los accesos. Cómo detectarlo: pregúntate quién revisa esos registros y con qué frecuencia; si la respuesta es "nadie, pero están ahí", es esto. Cómo corregirlo: un registro que nadie mira no es una defensa, es evidencia para la autopsia. Y aunque alguien lo mirara, un acceso hecho con una llave legítima se ve legítimo. Los registros ayudan a reconstruir lo que pasó; el mínimo privilegio ayuda a que lo que pasó sea menos grave.
Ejercicios
Ejercicio 1 — Dimensiona tres credenciales. Para cada caso, di qué alcance mínimo propondrías y qué se elimina respecto de lo que tiene hoy. Justifica en una frase.
(a) shipment-notify usa carrier_api para consultar el estado de un envío por su número de guía. La llave hoy tiene el rol "Operations" del transportista, que permite consultar envíos, crear envíos, cancelar envíos y descargar reportes de facturación.
(b) Un workflow nuevo va a leer las ventas del mes del ERP para armar un reporte que se manda por correo cada lunes. Todavía no existe la credencial.
(c) llm_token se usa para clasificar mensajes de clientes. El proveedor de IA ofrece llaves con acceso a todos sus modelos y también llaves restringidas a modelos específicos y con tope de gasto mensual.
Ver solución
(a) Alcance mínimo: consultar envíos, solo lectura. Se elimina crear envíos, cancelar envíos y descargar reportes de facturación. El workflow solo consulta el estado por número de guía; las otras tres operaciones son poder que no se usa. La de cancelar es especialmente incómoda: una llave filtrada podría cancelar envíos reales de clientes de Terra Market, y eso tiene consecuencias inmediatas y visibles.
(b) Alcance mínimo: lectura de ventas, y nada más. Y una decisión de diseño importante: no reutilices erp_api_scoped. Aunque ya está reducida, incluye orders:write porque order-sync la necesita, y este reporte no escribe nada. Una credencial nueva de solo lectura mantiene la distancia en cero para los dos workflows. La regla general: cuando un workflow nuevo necesita menos permisos que una credencial existente, se crea una credencial nueva, no se reutiliza la que "ya funciona".
(c) Alcance mínimo: restringida al modelo que el workflow usa, con tope de gasto mensual. Se elimina el acceso a los demás modelos, que además de ser poder no usado tiene una consecuencia económica: los modelos más caros del proveedor son justamente los que un atacante elegiría. Este caso muestra que el mínimo privilegio en una llave de IA tiene una dimensión que las otras no tienen —el dinero— y es el puente a la lección 7.
Por qué funciona: fíjate en el patrón de las tres respuestas. En cada caso preguntaste primero qué hace el workflow, después qué permite la llave, y propusiste la diferencia como recorte. Ese es todo el método. Y (b) enseña la trampa más sutil: reutilizar una credencial "ya reducida" es cómodo y aumenta la distancia otra vez.
Ejercicio 2 — Escribe el plan de rotación. La líder de operaciones de Terra Market —que conocía el valor de erp_api— deja la empresa el viernes. Escribe el plan de rotación que ejecutarías, con los pasos en orden, qué observas en cada uno, y qué haces si el ERP no permite dos llaves válidas a la vez.
Ver solución
El plan, con solapamiento (el caso normal):
- Antes del viernes, crea la llave nueva en el ERP con el mismo alcance reducido que la actual (
orders:write,customers:read,inventory:read,products:read). No toques la vieja. Ahora hay dos llaves válidas y la operación sigue con la vieja: cero riesgo. - Actualiza el valor de la credencial en n8n con la llave nueva. A partir de la siguiente ejecución,
order-synceinventory-updateusan la nueva. Qué observas: las ejecuciones siguen en verde; y enorder-sync, que los pedidos efectivamente llegan al ERP, no solo que la llamada devuelve200. - Deja pasar un ciclo completo, al menos un día. Si hay comportamiento mensual en algún workflow, considera la ventana con más cuidado o revisa qué operaciones ejecuta ese caso.
- Revoca la llave vieja en el ERP. Este es el paso que de verdad cierra el riesgo: desde aquí, lo que la líder de operaciones conocía ya no sirve. Qué observas: las ejecuciones siguen en verde (porque nadie usaba la vieja desde el paso 2). Si algo se cae aquí, es que había un consumidor de esa llave fuera de n8n —un script de alguien, una integración olvidada—, y descubrirlo es en sí mismo un hallazgo valioso.
- Anota la fecha de rotación y el motivo en el inventario. El motivo importa: "salida de una persona que conocía el valor" es un disparador, y tenerlo escrito ayuda a que la próxima vez alguien haga esto sin que se lo pidan.
Si el ERP no permite dos llaves a la vez: hay una ventana inevitable entre revocar la vieja y guardar la nueva. Se maneja así: elige una hora de baja actividad (para Terra Market, de madrugada), avisa al equipo, ten el valor nuevo copiado y listo antes de tocar nada, y ejecuta el cambio de corrido —revocar, generar, pegar en n8n, verificar—. Son segundos de exposición planeados, no una improvisación. Y déjalo anotado en el inventario: "este sistema no soporta solapamiento" es un dato que ahorra tiempo la próxima vez.
Un paso extra que suma: aprovecha la rotación para revisar el alcance. Si vas a crear una llave nueva de todos modos, es el momento más barato para preguntarte si el alcance sigue siendo el correcto o si algún workflow dejó de usar una operación.
Por qué funciona: el plan separa la parte que se puede hacer sin riesgo (crear la nueva) de la parte que sí lo tiene (revocar la vieja), y pone observación entre las dos. Y no se olvida del paso 4, que es el que la gente omite y sin el cual la rotación no rota nada.
Ejercicio 3 — Prioriza con criterio. Tienes el inventario de Terra Market y una tarde. Estas son las filas pendientes. Ordénalas por prioridad y justifica el orden con el criterio de cuánto reduce el peor caso por unidad de esfuerzo.
erp_apicon rol de administrador (2 workflows la usan).- Una credencial huérfana sin nombre claro que ningún workflow usa.
store_apicon permisos "por confirmar".smtp_notifysin rotar hace 8 meses.- Ninguna credencial tiene dueño asignado.
Ver solución
Un orden defendible, con su razonamiento:
Primero, (2) la credencial huérfana. Puede sorprender que no sea erp_api, y la razón es el criterio: por unidad de esfuerzo. Revocar una credencial que nadie usa toma diez minutos, no requiere coordinar con nadie, no puede romper ningún workflow —porque ninguno la usa— y elimina riesgo puro. Es la mejor relación entre lo que reduces y lo que cuesta. Con la precaución de preguntar antes al equipo con fecha límite, por si es de algo estacional.
Segundo, (5) asignar dueños. También es barato —es una conversación y una columna en la tabla— y desbloquea todo lo demás: sin dueño no hay quién autorice bajar el rol de erp_api ni quién ejecute la rotación de smtp_notify. Es infraestructura organizativa que multiplica el efecto del resto del trabajo.
Tercero, (3) confirmar los permisos de store_api. Media hora de entrar al panel de la tienda y mirar. Puede resultar que esté bien —y entonces ganaste certeza— o que sea un segundo erp_api que no sabías que tenías. En seguridad, cerrar un "no sé" es progreso real, porque un riesgo desconocido no se puede priorizar.
Cuarto, (1) reducir erp_api. Es el hallazgo más grave y por eso duele ponerlo cuarto. La razón es que no cabe en una tarde: el procedimiento correcto incluye crear una llave nueva, migrar un workflow, observar un ciclo completo, migrar el segundo, observar otra vez, y revocar. Es un trabajo de una semana con pasos cortos. Lo que sí hace hoy es empezarlo: inventariar las operaciones (paso 1) y pedir la llave nueva, que es lo que suele tener tiempo de espera.
Quinto, (4) rotar smtp_notify. Ocho meses sin rotar es higiene pendiente, pero su alcance ya es mínimo (enviar correo) y no hay disparador —nadie se fue, nada apareció en público—. Es la fila de menor riesgo del inventario y puede esperar a la siguiente ventana.
Por qué funciona: el orden no sigue la gravedad de los hallazgos, sigue el retorno del esfuerzo. Es contraintuitivo y es lo correcto: empezar por lo más grave suele significar empezar por lo que no se termina, y una tarde que termina con cuatro cosas cerradas y una empezada vale más que una tarde con una sola cosa a medias. Si tu orden puso erp_api primero pero reconociste que solo alcanza a empezarlo, tu razonamiento también es bueno —lo que hace mala una respuesta es no distinguir entre lo que se cierra hoy y lo que se abre hoy—.
Resumen y siguiente paso
En esta lección cambiaste de plano: de dónde vive el secreto a qué puede hacer. Con la imagen de la llave maestra del conserje grabaste el principio y su matiz más importante: el mínimo privilegio no reduce la probabilidad de que algo salga mal, reduce cuánto duele cuando sale mal. Definiste el principio con sus tres dimensiones —alcance, tiempo e identidad— y aprendiste a leer la distancia entre los permisos que una credencial tiene y los que usa, que es la superficie de daño que llevas sin recibir nada a cambio. Recorriste las cuatro preguntas de la auditoría —quién la usa, qué permisos tiene de verdad, cuándo se rotó, quién responde por ella— y conociste la auditoría integrada de n8n (n8n audit, el endpoint /audit, o el nodo n8n con Resource > Audit), que reporta credenciales que ningún workflow usa. Ejecutaste el procedimiento completo para reducir el alcance de erp_api sin romper producción: inventariar operaciones reales, traducirlas al vocabulario del sistema externo, crear una credencial nueva en vez de modificar la vieja, migrar un workflow a la vez empezando por el de menor riesgo, observar un ciclo completo, y revocar al final —con el beneficio extra de que revocar deja inútil la llave que ocho personas tenían en su chat—. Entendiste por qué las credenciales van a nombre de cuentas de servicio y no de personas. Y fijaste la rotación como la dimensión del tiempo, con su tabla de cadencias, sus dos disparadores inmediatos, y el procedimiento de solapamiento que la hace ejecutable sin caída.
Antes de avanzar deberías poder: explicar por qué el mínimo privilegio reduce el daño y no la probabilidad; nombrar las cuatro preguntas de la auditoría; describir el procedimiento de reducción de alcance en producción y por qué se crea una credencial nueva; explicar qué es una cuenta de servicio y qué tres problemas resuelve; y describir la rotación con solapamiento.
La lección 4 se mueve otra vez de plano, ahora hacia dónde puede vivir el secreto cuando la organización crece. Vas a conocer las bóvedas de secretos externas —HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, 1Password, Infisical— y la integración de n8n que las conecta, con la sintaxis $secrets y su limitación clave. Y vas a recibir la advertencia de honestidad más importante del módulo, dicha de frente y temprano: esa integración es una función Enterprise. No vamos a describirte durante veinte minutos algo que no puedes usar y avisarte al final; vas a saber desde el principio en qué plan está, qué compra exactamente el que la paga, y por qué —para una instancia como la de Terra Market— la alternativa de la lección 5 cubre lo esencial a costo cero.
Recursos
- Run security audits — n8n Docs — la auditoría integrada: las tres formas de ejecutarla (
n8n audit, el endpoint/audit, el nodo n8n) y los cinco reportes, incluido el de credenciales que ningún workflow usa. - Credentials — n8n Docs — cómo se crean, editan y asignan las credenciales a los nodos, que es la mecánica del procedimiento de reducción de alcance de esta lección.
- Manage credentials — n8n Docs — la sección de administración: compartir credenciales, usarlas dentro de proyectos y conectarlas a almacenes externos.
- Security — n8n Docs — el índice de seguridad de la instancia, del que sale la auditoría y varias de las medidas que retoma la lección 6.