Privacy by design : l'architecture
L'agent poison0 collecte le minimum techniquement possible, et ce qu'il collecte est vérifiable localement. Cette page associe chaque propriété de confidentialité à son mécanisme, avec l'approfondissement lié par sujet.
Vue d'ensemble
Chaque propriété, son mécanisme et où elle est spécifiée :
| Propriété | Mécanisme | Détails |
|---|---|---|
| Pas d'horodatages d'activité | La liveness est un compte à rebours relatif ; aucune heure absolue de dernière activité n'est persistée | Cette page |
| Egress minimal | Chemin plus diff caviardé, limité aux lignes ajoutées ; chaque requête dans un registre d'egress local | Ce que le mode Cloud envoie |
| Analyse sur l'appareil | Le modèle s'exécute localement dans les deux modes ; un appareil privé contacte le réseau au plus tous les 30 jours | Cloud ou privé |
| Stockage borné | Rétention de quarantaine 30 jours, plafond d'audit 50 Mio, entretien quotidien | Stockage, conservation et nettoyage |
| Votre propre second évaluateur | Un point d'accès à TLS épinglé que vous hébergez ; le contenu reste sur votre réseau | Utiliser votre propre modèle on-prem |
| Pas d'usage secondaire | Ni profilage d'activité, ni vente de données, ni ad-tech | Cette page |
Pas d'horodatages d'activité
La liveness d'un appareil est un compte à rebours relatif, pas un horodatage :
- Compte à rebours : un balayage planifié décrémente le compteur ; un heartbeat de l'appareil le réinitialise.
- Pas d'heure absolue : aucun horodatage de dernière activité n'est persisté ; le tableau de bord ne peut pas reconstituer quand une personne était à sa machine, et les heures de travail ne peuvent pas en être dérivées.
- Auto-rapport : un appareil rapporte son statut et la santé de son moteur avec un marqueur de liveness grossier, jamais des heures d'activité.
Minimisation des données au sens de l'art. 5(1)(c) du RGPD ; pertinent pour la codétermination selon le §87(1) n° 6 du BetrVG allemand.
Minimisation des données à la frontière d'egress
En mode Cloud, la surface des points d'accès est fixe ; le contenu ne la franchit que sous forme de diff caviardé, limité aux lignes ajoutées :
| Point d'accès | Charge utile |
|---|---|
/evaluate | chemin et diff unifié caviardé, limité aux lignes ajoutées (pas de textes complets) |
/reportQuarantine | ID du cas, chemin, raison, scores et le diff caviardé (taille plafonnée) |
/reportAudit | horodatage, action, chemin, raison, scores |
/getConfig | jeton d'authentification uniquement |
- Caviardé localement : secrets et PII structurées sont remplacés par des espaces réservés et les répertoires personnels masqués avant qu'un octet ne parte.
- Lignes supprimées : seul leur nombre quitte l'appareil, jamais le texte supprimé.
- Registre d'egress : chaque requête sortante est consignée localement avec
timestamp,endpoint,bytes,sha256de la charge utile etstatusHTTP, recoupable avec les journaux du pare-feu.
Le contrat champ par champ, les classes de caviardage et le format du registre : ce que le mode Cloud envoie.
Le modèle local et le mode Privé
Le modèle d'analyse s'exécute sur l'appareil dans les deux modes ; le mode, persisté dans un fichier local devicemode, décide seulement de ce qui quitte la machine :
- Contact tous les 30 jours : un daemon privé contacte le réseau au plus une fois tous les 30 jours, vers une URL de mise à jour documentée ; vérification de mise à jour et pointage de licence partagent cette unique requête.
- Pas de rapport d'incident : un appareil privé n'envoie rien sur soupçon ; les statistiques agrégées sont opt-in et uniquement des nombres.
- Air-gap : une installation entièrement hors ligne et un kill-switch de mise à l'arrêt sont disponibles.
Le choix du mode et ses garanties : cloud ou privé. Un second évaluateur sur votre propre réseau : utiliser votre propre modèle on-prem.
Isolation Enterprise et résidence des données
La résidence est une propriété du déploiement ; Enterprise offre une souveraineté et une résidence cloud sur mesure :
| Déploiement | Isolation | Région |
|---|---|---|
| Instance Enterprise dédiée | Console propre sous votre propre nom d'hôte, base de données de tenant propre, rien de partagé avec d'autres clients | Votre région au choix : Allemagne, UE, États-Unis ou Asie ; la base de données du tenant suit ce choix |
| Offre partagée (par défaut) | Installation partagée | Hébergée en Allemagne, europe-west3 (Francfort) |
Chiffrement
- En transit : TLS sur tout le trafic.
- Au repos dans le cloud : AES-256 sur Google Cloud.
- Au repos sur l'appareil : le modèle de détection est conservé chiffré-authentifié et inviolable de manière détectable ; toute altération échoue en fail-closed. Chaque version de modèle a sa propre clé, dérivée de clés maîtresses conservées dans des modules de sécurité matériels (HSM) de Google Cloud, qui ne peuvent pas être extraites ; un appareil ne reçoit que les clés des modèles qu'il est autorisé à utiliser, enveloppées avec une clé propre à l'appareil.
Rétention, suppression et le DPA
| Données | Limite | Application |
|---|---|---|
| Blobs de quarantaine | Fenêtre de rétention, 30 jours par défaut (plage 1 à 3650) | La passe d'entretien quotidienne les fait expirer et les supprime |
| Journal d'audit (appareil) | Plafond de taille, 50 Mio par défaut (plage 1 à 1024) | Tourné vers une sauvegarde au plafond |
| Données d'audit (cloud) | Limites de rétention | Supprimables sur demande |
Un accord de traitement des données (DPA/AVV) est disponible pour les clients Enterprise.
Les magasins, la passe d'entretien quotidienne et le réglage par appareil : stockage, conservation et nettoyage.
À lire ensuite
Le contrat d'egress exact : ce que le mode Cloud envoie. Le choix du mode et ses garanties : cloud ou privé. La rétention locale en détail : stockage, conservation et nettoyage. Un second évaluateur sur votre propre réseau : utiliser votre propre modèle on-prem.