Comment vos credentials d'automatisation sont protégés

Un workflow n8n a besoin d'accès à vos outils : Stripe, Gmail, Sheets, votre CRM. Ce sont des credentials sensibles — un attaquant qui les obtient peut envoyer des emails à vos clients ou vider votre compte Stripe. Voici comment ils sont protégés en pratique, expliqué sans jargon.

Qu'est-ce qu'un credential dans un workflow ?

Quand vous dites à un workflow "envoie un email via Gmail", il a besoin de prouver à Google qu'il a le droit d'envoyer cet email. Cette preuve, c'est un credential : un mot de passe, une clé API, ou un token OAuth.

Quelques exemples typiques :

• Clé API Stripe : permet de créer/modifier des paiements, des clients, des abonnements.
• OAuth Gmail : permet d'envoyer des emails depuis votre adresse pro.
• Webhook signing secret : prouve qu'un webhook reçu vient bien du service prétendu.
• Token CRM : permet de créer/modifier des contacts dans votre CRM.

Un attaquant qui obtient ces credentials a accès à vos outils sans avoir besoin de votre mot de passe. C'est pour ça qu'ils méritent une protection sérieuse.

Le chiffrement AES-256, expliqué simplement

AES-256 est l'algorithme de chiffrement standard utilisé par les banques, les gouvernements, et toute infrastructure qui prend la sécurité au sérieux. Il transforme une donnée lisible en une suite de caractères incompréhensibles, sauf si vous avez la "clé" qui permet de la déchiffrer.

Concrètement : votre clé API Stripe sk_live_51ABC... n'est jamais stockée en clair dans la base de données. Elle est stockée comme une suite illisible : U2FsdGVkX1+9pJ3z.... Sans la clé de chiffrement, même quelqu'un qui aurait un accès direct à la base ne peut rien en faire.

L'enjeu n'est pas seulement "les pirates" — c'est aussi de limiter les dégâts si quelque chose tourne mal côté infrastructure.

Le "256" indique la longueur de la clé : 256 bits, soit 2²⁵⁶ combinaisons possibles. Avec la puissance de calcul actuelle, casser une clé AES-256 par force brute prendrait des milliards de milliards d'années. C'est considéré comme inviolable en pratique.

L'isolation par client : pourquoi ça compte

Sur un hébergement n8n partagé "naïf", tous les clients vivent dans la même instance. Si quelqu'un trouve une faille, il peut potentiellement voir les workflows et credentials des autres. C'est rare, mais c'est arrivé sur plusieurs SaaS en 2022-2024.

L'approche correcte : isoler chaque client dans son propre espace. Concrètement :

• Chaque client a son propre conteneur (un environnement applicatif séparé).
• Chaque conteneur a sa propre clé de chiffrement AES-256, unique et générée au déploiement.
• Les volumes de données sont séparés : un workflow ne peut pas lire des fichiers d'un autre client.
• Les privilèges système sont restreints : un conteneur compromis ne peut pas s'élever vers l'hôte.

Le principe de base : si un workflow a un comportement inattendu, il ne doit pas pouvoir affecter les données des autres clients.

Les sauvegardes : chiffrées ou inutiles

Une sauvegarde non chiffrée est un trésor pour un attaquant : c'est l'intégralité de vos données dans un seul fichier. Quand un cabinet médical s'est fait voler ses sauvegardes en 2023 (incident notoire), c'est précisément parce qu'elles n'étaient pas chiffrées.

L'approche standard :

• Sauvegarde quotidienne (ou plus fréquente selon le plan).
• Chiffrement GPG avec une passphrase forte (32+ caractères aléatoires).
• Stockage sur une infrastructure distincte du serveur principal (sinon une compromission de l'un compromet l'autre).
• Test de restauration régulier — une sauvegarde non testée est une supposition de sauvegarde.
• Rotation : les vieilles sauvegardes sont effacées après 30 jours.

Les transports : TLS partout

Les credentials et données ne se déplacent jamais en clair sur le réseau :

• HTTPS / TLS obligatoire pour toute connexion au workflow (l'interface n8n, les webhooks).
• HSTS activé : le navigateur refuse même de tenter une connexion non chiffrée.
• SSH avec clé publique uniquement pour la maintenance ; pas de mot de passe activé.
• API tierces (Stripe, Google) : leur propre HTTPS protège la communication.

Qui peut accéder à mes credentials, en pratique ?

Question légitime, à laquelle un prestataire honnête doit pouvoir répondre clairement.

Sur une instance n8n bien configurée, en mode "managé" (le prestataire administre l'instance) :

• Vous : via l'interface n8n, avec votre login. Vous pouvez voir et utiliser vos credentials.
• Votre prestataire (administrateur technique) : a accès au serveur et donc à la base chiffrée. Avec la clé de chiffrement (qu'il détient pour faire fonctionner l'instance), il peut techniquement déchiffrer.
• Personne d'autre : ni les autres clients, ni un attaquant qui n'aurait pas la clé.

C'est ce qu'on appelle un modèle de "confiance contractuelle" : votre prestataire pourrait techniquement voir vos credentials, mais s'engage par contrat (DPA) à ne pas le faire. C'est le même modèle que votre banque, votre comptable ou votre hébergeur email.

Pour les besoins ultra-sensibles (santé, défense, juridique), il existe une approche dite "zero-knowledge" où la clé reste sur l'instance client uniquement. C'est techniquement plus contraignant et coûte plus cher, mais le prestataire n'a alors aucune capacité technique à voir les credentials. À discuter au cas par cas selon vos exigences.

Et à la résiliation, que devient ma clé ?

Sur une instance dédiée, à la fin du contrat :

• La clé de chiffrement de votre instance est détruite.
• Les credentials encore stockés deviennent mathématiquement irrécupérables — y compris par votre prestataire.
• Les sauvegardes sont également détruites après la période de rétention contractuelle (typiquement 30 jours).

C'est l'équivalent numérique de "récupérer ses clés et changer la serrure". À la fin de la relation, votre prestataire ne détient plus rien d'utilisable.

Les questions à poser à n'importe quel hébergeur d'automatisation

Que vous évaluiez Zapier, n8n Cloud, nodkon ou un concurrent, voici les questions pour cadrer leur niveau réel de sécurité :

1. Mes credentials sont-ils chiffrés au repos ? Avec quel algorithme ?
2. Chaque client a-t-il sa propre clé de chiffrement, ou une clé partagée ?
3. Les sauvegardes sont-elles chiffrées ? Où sont-elles stockées ?
4. Qui peut techniquement déchiffrer mes credentials ?
5. Que se passe-t-il à la résiliation ? Quand mes données sont-elles effectivement détruites ?
6. Est-ce que je peux exporter mes workflows et credentials avant de partir ?
7. Y a-t-il un DPA disponible ?

Si l'hébergeur n'a pas de réponse claire à ces sept questions, ce n'est probablement pas le bon hébergeur pour des données qui comptent.

L'approche nodkon

On suit chacun des principes ci-dessus, par défaut, sur tous les plans :

• Chiffrement AES-256 avec clé unique par client.
• Isolation par conteneur dédié, volumes séparés, privilèges restreints.
• Sauvegardes quotidiennes chiffrées GPG, stockées sur infrastructure distincte.
• HTTPS/TLS obligatoire, HSTS activé.
• SSH par clé uniquement, accès root désactivé.
• DPA disponible sur demande pour Quick Deploy et Pro, signé pour Enterprise.
• Export complet (workflows + données) à la résiliation, destruction des clés sous 30 jours.

Ces choix coûtent un peu plus à l'opération que le minimum syndical. C'est délibéré : on préfère le faire bien plutôt qu'expliquer une incident plus tard.

Pour aller plus loin

Voir nos articles : RGPD et automatisation pour TPE, Souveraineté numérique pour TPE, ou le comparatif n8n vs Zapier.