Gestion des secrets

La source d'un secret et la garde des clés de son organisation sont deux réglages distincts. Ouvrez Paramètres → Plateforme → Secrets pour gérer les deux. Les listes affichent des métadonnées ; elles ne retournent jamais les valeurs des secrets.

Choisir la source

Stocké ne signifie pas géré par la plateforme : un secret stocké peut utiliser une clé détenue par le client. Les valeurs référencées entrent en mémoire du processus pour leur utilisation autorisée, mais elles ne sont ni enregistrées comme texte chiffré de secret ni mises en cache par le résolveur de références.

Les secrets d'organisation sont privés par défaut. Partager avec les espaces de travail rend un secret d'organisation disponible pour ses espaces de travail. Un secret d'espace de travail portant le même nom est prioritaire ; la liste de l'espace de travail affiche tout de même le secret partagé, marqué Remplacé dans cet espace de travail. Le chiffrement suit la politique de l'organisation propriétaire, y compris pour les secrets hérités et les colonnes d'identifiants des extensions.

Choisir la garde des clés

La page comporte trois onglets : Organisation et Espace de travail listent les secrets de chaque portée, et Connexions contient la section Clé de chiffrement (qui détient la clé, son mode d'accès et la couverture de migration) au-dessus de la liste des connexions de coffre. Ajouter une connexion prend en charge :

• OpenBao / HashiCorp Vault Transit : authentification par jeton, AppRole ou Kubernetes ; autorité de certification privée et certificat client facultatifs. Activez Secrets référencés pour lire les valeurs dans le magasin KV v2 du coffre ; un chemin de test est facultatif. Seule une telle connexion peut porter un secret référencé ; s'il n'y en a aucune, Créer un secret → Référencé l'indique et renvoie à l'onglet Connexions, où vous pouvez l'activer sur une connexion existante sans ressaisir ses identifiants. Tester la connexion vérifie une connexion non enregistrée, et l'enregistrement refuse une connexion que le coffre n'accepte pas.
• Azure Key Vault : cloud public Azure, clé d'encapsulation RSA et identité de charge de travail fédérée. Le déploiement fournit le jeton d'identité projeté ; aucun secret client n'est enregistré.

L'authentification Kubernetes et l'identité de charge de travail Azure s'authentifient comme le déploiement Scrydon lui-même ; l'opérateur du déploiement doit donc d'abord lier votre organisation à ce coffre. Les URL de coffre doivent désigner des hôtes HTTPS publics, sauf si l'opérateur autorise les réseaux privés. Consultez les Prérequis opérateur.

Lorsque Tester la connexion ne parvient pas à joindre le coffre, il en indique la raison :

Chaque valeur stockée est scellée avec l'organisation qui la possède. Une valeur copiée dans l'enregistrement d'une autre organisation ne s'y déchiffre pas, même tant que le coffre d'origine répond encore.

Le chiffrement géré par la plateforme est la valeur par défaut. La sélection d'une connexion client la teste, change la garde et rechiffre les secrets stockés existants ainsi que les identifiants des extensions de l'organisation, par lots limités. Gardez la connexion et la clé précédentes disponibles jusqu'à ce que la couverture soit complète. Utilisez Reprendre après une migration interrompue. Une connexion ne peut pas être supprimée tant qu'elle est sélectionnée ou que du texte chiffré ou des références en dépendent encore.

Vérifier la révocation effectue un déballage sans cache. Son résultat ne purge pas les caches des autres processus. Un refus sans cache réussi et le TTL affiché décrivent ensemble la limite de révocation. Une organisation sans enveloppe client ne peut pas effectuer cette vérification. Les échecs du coffre retournent une erreur typée CUSTODY_* et HTTP 503 ; ils ne sélectionnent jamais automatiquement la garde de la plateforme. Les opérations en lot signalent les échecs individuels.

Pour la configuration, la récupération et un exercice reproductible, consultez Apporter ou conserver sa propre clé.

Références

Pour Vault KV v2, saisissez un chemin relatif tel que applications/payments#token ; omettez #token pour retourner l'objet de données complet en JSON. N'incluez ni /v1, ni le montage KV, ni /data, ni une URL. Pour Azure, saisissez le nom du secret sans suffixe de champ. Lire maintenant vérifie l'accès sans afficher la valeur retournée. Une référence absente ou refusée fait échouer l'opération au lieu de fournir une valeur vide.

API et permissions

La gestion des connexions est limitée à l'organisation. L'appartenance d'un espace de travail est résolue à partir des adhésions persistées, jamais à partir de l'organisation revendiquée par l'appelant. Utilisez les actions de garde plutôt que les mises à jour génériques de la politique d'organisation : les écritures génériques sur secrets.keyCustody sont rejetées.

Caviardage des journaux et des événements

Tous les journaux et événements d'analytique passent par un caviardeur avant de quitter le système. Le caviardeur reconnaît deux motifs :

Clés sensibles (par suffixe) — 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 caviardée.

Valeurs sensibles (par regex) — les jetons bearer, les en-têtes d'authentification basique, les préfixes de clés d'API (sk-…, pk-…) et les champs d'identifiants JSON sont détectés par motif et remplacés.

Pour l'analytique et le signalement des erreurs, les clés sensibles sont entièrement supprimées, et 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 dans lesquelles le mot sensible est un préfixe (et non le jeton complet) sont conservées :

Assainissement des workflows à l'export / au partage

Avant qu'un workflow soit exporté ou partagé comme modèle, les données sensibles sont supprimées, et non caviardées :

• Identifiants OAuth → null.
• Champs de mot de passe → null.
• Sélecteurs propres à l'espace de travail (base de connaissances, document, fichier, canal, dossier, projet, serveur MCP) → null.
• Identifiants de champs propres à l'espace de travail (knowledgeBaseId, documentId, fileId, projectId, channelId, folderId, tagFilters) → null.
• Champs de données hérités correspondant aux motifs credential / oauth / token / secret → null.

Les références à des variables d'environnement ({{VAR}}) peuvent éventuellement être conservées pour les scénarios d'export — utile lorsque vous voulez un modèle qui se relie à l'environnement de l'importateur.

Audit

Les opérations sur les secrets et les fournisseurs utilisent le système d'audit existant. Les changements de garde, la progression des migrations et la vérification sans cache émettent CUSTODY_CHANGED, CUSTODY_REENCRYPT_PROGRESS et CUSTODY_VERIFY_REVOCATION. Les lectures de références émettent SECRET_ACCESS avec source: "referenced", l'attribution à l'acteur ou au service, et un code de succès/erreur. Les valeurs, jetons et clés privées sont exclus.

Voir aussi

• Apporter ou conserver sa propre clé
• Journal d'audit
• Autorisation
• Caviardage