Sécurité

Présentation

Onagre applique plusieurs couches de protection pour garantir que vos secrets restent en sécurité à chaque étape — au repos, en transit et au niveau applicatif. Cette page détaille le modèle de chiffrement et les contrôles d'accès qui protègent vos données sensibles.


Chiffrement au repos

Toutes les valeurs des secrets sont chiffrées avec AES-GCM et des clés de 256 bits, un standard de chiffrement authentifié qui garantit à la fois la confidentialité et l'intégrité. Chaque valeur est chiffrée avec un nonce aléatoire unique, rendant chaque texte chiffré distinct — même pour des entrées identiques.

Architecture de clés à deux niveaux

Onagre utilise un modèle de chiffrement à deux niveaux pour isoler les organisations les unes des autres :

  • Une clé maître de plateforme sécurise l'infrastructure. Elle est configurée au moment du déploiement et n'est jamais stockée aux côtés de vos données.
  • Une clé spécifique au tenant, unique à votre organisation, chiffre vos secrets. Cette clé de tenant est elle-même chiffrée par la clé maître et n'est jamais stockée en clair.

Cette conception garantit que même dans le cas improbable d'une violation de données, les valeurs des secrets restent illisibles sans accès aux deux niveaux de clés. Compromettre les données d'une organisation n'expose pas celles d'une autre.

Ce qui est chiffré

Donnée Chiffrement
Valeurs des secrets (chaînes de connexion, identifiants) AES-GCM 256 bits avec clé par tenant
Clés de chiffrement des tenants AES-GCM 256 bits avec clé maître de plateforme
Valeurs des variables Non chiffrées (texte clair par conception — utilisez les secrets pour les données sensibles)

Chiffrement en transit

Toutes les communications entre les agents et la plateforme Onagre utilisent le chiffrement TLS. La connexion gRPC entre chaque agent et le Hub est chiffrée de bout en bout, protégeant les valeurs des secrets lors de leur transmission pour l'exécution des sondes.

Les secrets sont déchiffrés sur le Hub (côté serveur) et transmis à l'agent au sein du canal gRPC chiffré. Les agents ne stockent jamais les secrets sur disque — les valeurs sont conservées en mémoire uniquement pendant la durée du contrôle de la sonde.


Contrôles au niveau applicatif

Restrictions d'accès

  • Seuls les Administrateurs et les Gestionnaires peuvent créer, modifier ou supprimer des secrets et des variables.
  • Les utilisateurs avec le rôle Lecteur peuvent voir que des secrets existent (code, type, version) mais ne peuvent ni lire ni modifier leurs valeurs.

Secrets en écriture seule

Les valeurs des secrets ne sont jamais retournées par l'API ni affichées dans l'interface après leur création. La plateforme ne stocke que la forme chiffrée — aucune copie en clair n'est conservée.

Isolation par tenant

Toutes les données sont isolées par tenant par conception. L'accès inter-organisations est interdit à chaque niveau — API, requêtes de base de données et communication avec les agents. Un agent appartenant à une organisation ne peut pas recevoir les secrets d'une autre.

Mise en cache

  • Les clés de tenant sont mises en cache en mémoire pour une durée limitée afin d'éviter le déchiffrement répété de la clé maître.
  • Les valeurs de secrets déchiffrées sont mises en cache brièvement (quelques minutes) pour éviter le déchiffrement répété lors des cycles fréquents d'exécution des sondes.
  • Les caches sont invalidés lorsqu'un secret est mis à jour ou supprimé.

Résumé

Couche Protection
Au repos AES-GCM 256 bits, architecture de clés à deux niveaux, isolation par tenant
En transit Connexion gRPC chiffrée par TLS entre les agents et le Hub
Dans l'interface Les valeurs des secrets sont en écriture seule, jamais affichées
Contrôle d'accès Restreint aux Administrateurs et Gestionnaires
Sur l'agent Aucun stockage sur disque — les secrets n'existent en mémoire que pendant l'exécution
Entre tenants Isolation complète — aucun accès inter-organisations