Gestion des secrets
Comment Scrydon stocke et récupère les identifiants — trois stratégies (LOCAL / BYOK / HYOK), rédaction à chaque frontière et audit à chaque accès.
Chaque identifiant géré par Scrydon — tokens OAuth, clés API, mots de passe SMTP, secrets de vendeurs — est chiffré au repos et rédigé dans les journaux, les exports et les événements analytiques. Cette page documente les trois stratégies de stockage et le modèle d'accès.
Les trois stratégies
Scrydon gère la clé de chiffrement. Les secrets sont chiffrés au repos dans la base de données de la plateforme via AES.
- Plus simple à exploiter — aucun KMS externe requis.
- La clé de chiffrement est stockée dans un secret Kubernetes que vous contrôlez.
- Les valeurs chiffrées sont stockées dans la base de données de la plateforme.
Utilisez LOCAL quand votre équipe opérationnelle n'est pas encore prête à intégrer un KMS externe dans le chemin critique de la plateforme.
Vous fournissez la clé de chiffrement. Le matériel chiffré est toujours stocké dans la base de données de la plateforme, mais la clé de chiffrement des données (DEK) est enveloppée par une clé gérée par le client dans votre KMS.
Fournisseurs KMS pris en charge :
- AWS KMS
- Azure Key Vault
- HashiCorp Vault
- GCP KMS
Utilisez BYOK quand votre politique de sécurité exige des clés de chiffrement contrôlées par le client mais que vous acceptez le texte chiffré au repos dans la base de données de la plateforme.
La valeur du secret ne réside jamais dans la plateforme. Scrydon stocke uniquement un URI de référence ; le secret est récupéré à l'exécution depuis votre KMS ou coffre-fort pour chaque utilisation autorisée.
Fournisseurs KMS pris en charge :
- AWS KMS
- Azure Key Vault
- HashiCorp Vault
- GCP KMS
Utilisez HYOK quand votre politique de sécurité stipule que la base de données de la plateforme ne doit pas contenir même du matériel d'identification chiffré.
L'API du coffre
Les secrets sont accessibles via une petite API typée. Chaque appel est soumis à une vérification d'autorisation et audité.
| Endpoint | Qui peut l'appeler | Objectif |
|---|---|---|
/secret/save | Administrateur de workspace ou supérieur | Créer ou mettre à jour un secret avec chiffrement. |
/secret/get | Administrateur de workspace ou supérieur | Récupérer la valeur déchiffrée. |
/secret/delete | Administrateur de workspace ou supérieur | Supprimer un secret. |
/secret/list | Membre du workspace ou supérieur | Lister les métadonnées uniquement. Les valeurs ne sont jamais retournées par list. |
/secret/save-bulk | Administrateur de workspace ou supérieur | Création / mise à jour par lot. |
/secret/get-bulk | Administrateur de workspace ou supérieur | Récupération par lot. |
/secret/admin/get | Service-à-service uniquement (mTLS) | Accès service interne — utilisé par le runtime de workflow pour injecter les identifiants. |
L'endpoint interne requiert SPIFFE / Dapr mTLS — il n'y a pas de chemin utilisateur vers celui-ci. Voir SPIFFE / mTLS.
Rédaction des journaux et événements
Tous les journaux et événements analytiques passent par un rédacteur avant de quitter le système. Le rédacteur reconnaît deux patterns :
Clés sensibles (basé sur les suffixes) — toute clé se terminant par api_key, access_token, refresh_token, client_secret, private_key, auth_token, secret, password, token, credential, authorization, ou bearer est rédigée.
Valeurs sensibles (basé sur les regex) — les tokens bearer, les en-têtes basic-auth, les préfixes de clés API (sk-…, pk-…), et les champs d'identification JSON sont appariés par pattern et remplacés.
Pour les analyses et les rapports d'erreurs, les clés sensibles sont entièrement supprimées, pas seulement masquées, de sorte qu'elles n'entrent jamais dans le magasin d'événements.
Prévention des faux positifs
Les clés où le mot sensible est un préfixe (et non le token complet) sont préservées :
| Clé | Traitée comme |
|---|---|
tokenCount: 100 | Pas un token — préservé |
passwordStrength: "strong" | Pas un mot de passe — préservé |
authMethod: "oauth" | Pas des données d'authentification — préservé |
tokenizer: "gpt" | Pas un token — préservé |
Assainissement des workflows lors de l'export / partage
Avant tout export ou partage d'un workflow comme template, les données sensibles sont supprimées, pas rédigées :
- Identifiants OAuth →
null. - Champs mot de passe →
null. - Sélecteurs spécifiques au workspace (base de connaissances, document, fichier, canal, dossier, projet, serveur MCP) →
null. - Identifiants de champs spécifiques au workspace (knowledgeBaseId, documentId, fileId, projectId, channelId, folderId, tagFilters) →
null. - Champs de données hérités correspondant aux patterns credential / oauth / token / secret →
null.
Les références à des variables d'environnement ({{VAR}}) peuvent optionnellement être préservées pour les scénarios d'export — utile quand vous souhaitez un template qui se relie à l'environnement de l'importateur.
Audit
Chaque opération sur les secrets est capturée dans le journal d'audit :
SECRET_CREATE,SECRET_UPDATE,SECRET_DELETE,SECRET_ACCESSPROVIDER_CREATE,PROVIDER_UPDATE,PROVIDER_DELETE,PROVIDER_TEST
Chaque événement enregistre l'identifiant de l'acteur, l'adresse IP, l'agent utilisateur et un objet de métadonnées décrivant le secret concerné (sans la valeur).
La rétention des audits est configurable par organisation. La valeur par défaut est 365 jours ; certains référentiels de conformité exigent des durées plus longues — voir Conformité pour les valeurs par défaut spécifiques aux référentiels.
Voir aussi
- Journal d'audit — ce qui est capturé à chaque accès aux secrets.
- Autorisation — les grants d'exécution pour les lectures de secrets dans les workflows.
- Modèle de permissions — qui peut appeler quel endpoint.
- Rédaction — catalogue complet des patterns pour les journaux et événements.