Caviardage

Chaque ligne de journal, événement analytique et chemin d'export dans Scrydon passe par une couche de caviardage. Cette page documente les schémas qu'elle applique et les cas de faux positifs qu'elle évite délibérément.

Deux familles de schémas

Le caviardage fonctionne sur deux familles de schémas : les clés et les valeurs.

Clés sensibles (basées sur les suffixes)

Toute clé d'objet dont le nom se termine par l'un de ces schémas est caviardée :

api_key            access_token       refresh_token
client_secret      private_key        auth_token
*secret            *password          *token
*credential        authorization      bearer

Les schémas avec astérisque correspondent à tout ce qui contient ce mot en tant que suffixe. Ainsi mySecret correspond, password correspond, mais passwordStrength ne correspond pas (le mot sensible est un préfixe, pas un suffixe).

Valeurs sensibles (basées sur des expressions régulières)

Toute valeur de chaîne correspondant à l'un de ces schémas est caviardée, indépendamment de la clé sous laquelle elle est stockée :

• Jetons Bearer — Bearer <jeton opaque> → Bearer [REDACTED]
• Auth Basic — Basic <base64> → Basic [REDACTED]
• Préfixes de clé API — sk-…, pk-…, api-…, key-… (20+ caractères) → [REDACTED]
• Champs d'identifiants JSON — valeurs JSON pour les clés correspondant au schéma de clé sensible → [REDACTED]

Exemple : caviardage d'objet

const input = {
  apiKey: "sk-abc123",
  access_token: "token-value",
  password: "hunter2",
  normalField: "visible",
};
// → { apiKey: "[REDACTED]", access_token: "[REDACTED]", password: "[REDACTED]", normalField: "visible" }

Exemple : caviardage imbriqué en profondeur

Le caviardeur parcourt les objets et tableaux imbriqués :

const input = {
  users: [{
    name: "John",                     // ← conservé
    credentials: {
      apiKey: "secret-key",           // ← [REDACTED]
      username: "john_doe",           // ← conservé
    },
  }],
  config: {
    database: {
      password: "db-password",        // ← [REDACTED]
      host: "localhost",              // ← conservé
    },
  },
};

Assainissement des événements (clés entièrement supprimées)

Pour les analyses et les rapports d'erreurs, les clés sensibles sont supprimées, pas masquées. Cela garantit qu'un collecteur d'événements en aval ne les voit jamais :

sanitizeEventData({
  action: "login",
  apiKey: "secret-key",      // ← supprimée
  password: "secret-pass",   // ← supprimée
  userId: "123",             // ← conservée
});

Faux positifs que le caviardeur évite

Les clés dont le mot sensible est un préfixe (pas le mot complet) sont conservées :

C'est important en pratique — les événements d'utilisation des LLMs contiennent des champs tokenCount, et un caviardeur naïf qui correspondrait à toute clé contenant « token » les supprimerait et casserait la facturation.

Où cela s'exécute

Le caviardage est appliqué à trois frontières :

1. Émission de journaux — chaque déclaration de journal structuré passe par le caviardeur avant d'être sérialisée.
2. Événements analytiques — chaque événement publié vers le pipeline analytique est assaini.
3. Export de workflow — voir Gestion des secrets → Assainissement du workflow à l'export / partage.

Voir aussi

• Gestion des secrets — comment les identifiants sont stockés avant d'entrer dans le chemin de caviardage.
• Journalisation d'audit — ce qui est journalisé, ce qui est toujours caviardé dans les métadonnées.