Confidentialité et comptes locaux

bitcollector expédie de la télémétrie hors de l'hôte à chaque cycle : ce qu'il refuse de collecter compte donc autant que ce qu'il collecte. Les lignes de commande des processus sont désactivées par défaut ; le collecteur de processus ne lit jamais les variables d'environnement ni le contenu des fichiers ; rien de dérivé d'un condensat de mot de passe n'est jamais transporté ; et le collecteur de comptes locaux publie des UID plutôt que des identifiants de connexion, sauf activation explicite de votre part. Les enregistrements de processus font exception dans le binaire que vous pouvez télécharger aujourd'hui : ils portent l'identifiant de connexion du compte propriétaire, et la prochaine version cesse de le publier par défaut — voir ce que portent les enregistrements de processus ci-dessous, la section à lire si les identifiants de connexion sont des données à caractère personnel dans votre analyse.

Cette page couvre ces valeurs par défaut, ainsi que le collecteur de comptes locaux qu'elles concernent le plus. Pour tout le reste de ce que l'agent recueille, voir la présentation de bitcollector.

Confidentialité par défaut

La minimisation des données est l'état par défaut, pas une étape de durcissement dont il faut se souvenir. C'est ce qui rend bitcollector déployable en France sans discussion.

Les lignes de commande des processus sont sur off par défaut. Les lignes de commande transportent couramment des identifiants en clair — mysqldump -pSECRET, --token=…, une DSN avec un mot de passe intégré — et cet agent expédie de la télémétrie hors de l'hôte à chaque cycle.

collectors:
  process:
    command_line: "off"          # off | redacted | full
    i_accept_secret_exposure: false

Mode	Comportement
off	Par défaut. Les lignes de commande ne sont jamais collectées.
redacted	Collectées avec les secrets connus retirés à la capture, avant même que l'enregistrement n'existe.
full	Collectées telles quelles. L'agent refuse de démarrer si i_accept_secret_exposure: true n'est pas également défini.

Et les règles qui l'entourent :

• Le collecteur de processus ne collecte jamais de variables d'environnement ni de contenu de fichiers, quel que soit le mode de ligne de commande.
• Un mode qui ne peut pas être honnêtement assuré sur une plateforme est refusé, pas simulé. Windows n'a pas d'argv fidèle, donc redacted y est refusé plutôt que de faire semblant d'expurger.
• Chaque enregistrement indique le mode qui l'a produit, si bien que l'absence est lisible — un auditeur peut distinguer « il n'y avait rien » de « nous avons choisi de ne pas regarder ».

Comptes privilégiés et dormants

Quels comptes de cet hôte peuvent devenir root, si leur mot de passe est utilisable, et depuis combien de temps personne ne s'est connecté avec eux — sans que quiconque ait à s'y connecter en SSH.

• Le privilège est compté à partir de l'UID 0 et de l'appartenance à sudo/wheel/ admin/root, relevée à la fois dans la liste des membres du groupe et dans les GID primaires. Un compte dont le groupe primaire est sudo n'apparaît dans aucune liste de membres, et c'est exactement celui que vous rateriez.
• La dormance est signalée au-delà d'un seuil configurable — dormant_after: 2160h (90 jours) par défaut, ce qui correspond à PCI DSS 8.1.4 et au contrôle ISO 27001 habituel. Le seuil qui a produit chaque verdict est porté dans l'enregistrement.

Jamais de condensats de mots de passe

Le champ mot de passe de /etc/shadow est confié à un unique classificateur qui renvoie l'une de six constantes (set, locked, no_password_login, empty, unrecognised, unknown). Rien de dérivé du condensat n'est transporté — et l'algorithme de hachage n'est délibérément pas collecté non plus, parce que l'identifiant d'algorithme est un préfixe du condensat. L'enregistrement le dit dans son champ hash_algorithm plutôt que de vous laisser remarquer l'absence.

Le collecteur de comptes locaux publie des UID plutôt que des identifiants de connexion par défaut.

collectors:
  accounts:
    identity: minimal            # minimal (default) | username

minimal ne publie que les UID ; la chaîne de remédiation de l'enregistrement indique à l'opérateur d'exécuter getent passwd <uid> en local. identity: username publie les identifiants de connexion, relève d'une activation explicite, est refusé en cas de faute de frappe et estampille chaque enregistrement qu'il produit. Le GECOS (nom complet, bureau, téléphone) et les répertoires personnels ne sont jamais lus, dans l'un comme dans l'autre mode, et le tty ainsi que l'adresse source d'une connexion sont supprimés dès la capture. Sur un hôte de référence, 34 comptes locaux se sont réduits à 2 enregistrements publiés.

Ce que portent les enregistrements de processus sur le compte propriétaire

Le réglage ci-dessus ne gouverne que le collecteur de comptes. Le collecteur de processus est un chemin de code distinct et, dans le binaire que vous pouvez télécharger aujourd'hui, il publie l'identifiant de connexion du compte propriétaire de chaque processus :

{ "pid": 1421, "name": "nginx", "owner": "www-data", "…": "…" }

Correction : une suppression d'owner par collecteur existe désormais

Une version antérieure de cette page portait un avertissement intitulé « Ce n'est pas conditionné, et aucune clé ne le désactive ». Il indiquait qu'owner était renseigné sans condition sur chaque enregistrement de processus, que collectors.accounts.identity ne s'y appliquait pas et — la phrase à relire — qu'« une suppression d'owner par collecteur n'existe pas encore », ne vous laissant que deux options : désactiver entièrement le collecteur de processus, ou accepter et documenter ce traitement.

Cette dernière phrase a cessé d'être vraie. collectors.process.identity existe, sa valeur par défaut est minimal, et dans ce mode l'identifiant de connexion du compte propriétaire n'est jamais lu. Il n'est pas encore dans le binaire publié — voir l'encadré suivant, qui est la partie de l'ancien avertissement qui tient toujours — mais ce n'est plus quelque chose dont ce produit est dépourvu.

La correction est faite ici plutôt que reformulée en silence, parce que c'est le genre d'énoncé sur lequel vous avez pu agir. Si vous avez désactivé le collecteur de processus pour garder les identifiants de connexion sur vos hôtes, ou si vous avez consigné dans une AIPD ou dans une réponse à un client que ce traitement ne pouvait pas être supprimé, c'est la décision à réexaminer dès que vous exécuterez une version qui contient cette clé.

Une version antérieure de cette page indiquait aussi que les identifiants de connexion « restent sur l'hôte sauf activation explicite de votre part ». C'était vrai du collecteur de comptes et faux pour l'agent dans son ensemble ; la correction est faite ici plutôt que reformulée en silence — un énoncé de protection des données sur lequel vous vous êtes appuyé ne doit pas changer sans que vous en soyez informé.

Cette section décrit la PROCHAINE version, pas le binaire téléchargeable

collectors.process.identity n'est pas publié. Cela ne figure pas dans 0.2.0-ga (commit 0821374), le binaire bitcollector publié le plus récent, ni dans aucune version antérieure. Lancez bitcollector version et comparez avant de bâtir quoi que ce soit sur cette clé.

Ce que fait le binaire que vous pouvez télécharger aujourd'hui. Lu dans le code au commit 0821374 :

• owner — l'identifiant de connexion du compte propriétaire — est renseigné sur chaque enregistrement de processus, à chaque cycle de collecte, dès lors que le collecteur de processus est activé, et il l'est par défaut.
• collectors.accounts.identity ne s'y applique pas : ce réglage n'est lu que par le collecteur de comptes.
• Écrire collectors.process.identity dans un fichier de configuration n'y change rien, et rien ne vous le signale. Le champ n'existe pas dans cette version et le chargeur YAML de l'agent ignore les clés qu'il ne reconnaît pas : il démarre normalement et continue de publier les identifiants de connexion. Aucune erreur, aucune ligne de journal. Ne traitez pas cette clé comme un contrôle tant que bitcollector version ne vous montre pas une version postérieure à 0.2.0-ga.
• owner_uid vaut 0 — c'est-à-dire root — sur chaque enregistrement Windows et sur chaque processus dont l'uid n'a pas pu être lu. Voir owner_uid ne vaut plus root par défaut ci-dessous.

Sur 0.2.0-ga, les deux options restent celles nommées ci-dessus : désactiver le collecteur de processus (collectors.process.enabled: false), ou accepter et documenter ce traitement.

À partir de la prochaine version, collectors.process.identity décide si l'identifiant de connexion quitte l'hôte — délibérément le même nom de clé, les deux mêmes valeurs et le même refus fermé par défaut que collectors.accounts.identity, pour que ce soit un seul concept sur deux collecteurs plutôt que deux réglages qui se ressemblent :

collectors:
  process:
    identity: minimal            # minimal (default) | username

Mode	Ce que porte un enregistrement de processus
minimal	Par défaut. owner_uid seulement — l'uid du compte propriétaire. L'identifiant de connexion n'est jamais lu : il n'atteint donc aucun exportateur, aucun journal, aucune copie en mémoire d'un enregistrement. Résolvez un uid sur l'hôte lui-même avec getent passwd <uid>.
username	owner (l'identifiant de connexion — donnée à caractère personnel au sens du RGPD) et owner_uid. Activation explicite, et estampillage de chaque enregistrement produit.

Et les règles qui l'entourent :

• Toute autre valeur fait refuser le démarrage, en EN et en FR. Un contrôle de confidentialité qui ne peut pas être établi échoue en position fermée plutôt que d'être tranché en silence dans un sens ou dans l'autre — une faute de frappe ne doit ni masquer votre demande explicite de noms, ni expédier des noms que personne n'a demandés.
• Chaque enregistrement estampille le mode qui l'a produit dans owner_identity_mode : minimal, username, unsupported ou unavailable. Les deux derniers sont des estampilles écrites par l'agent pour chaque enregistrement ; ce ne sont pas des valeurs que vous pouvez définir, et le refus ci-dessus les rejette si vous essayez.
• Si l'un de vos tableaux de bord ou l'une de vos requêtes lit owner, il le trouvera vide après la mise à niveau. C'est ce réglage, pas un collecteur cassé. Définissez identity: username pour publier à nouveau les noms.

« minimal » ne veut pas dire la même chose sous Windows

Windows n'a pas d'uid POSIX : sous Windows, minimal ne publie donc aucun identifiant de propriétaire. owner_uid vaut -1 et chaque enregistrement est estampillé owner_identity_mode: "unsupported", si bien que l'absence est lisible plutôt que vide. Windows dispose bien d'un identifiant de compte pseudonyme — le SID utilisateur dans le jeton du processus — et bitcollector ne le collecte délibérément pas : rien n'est livré pour une plateforme sur laquelle ce projet n'a pas fait ses vérifications. Un opérateur Windows qui a besoin d'attribuer un propriétaire définit identity: username, et accepte qu'un nom de compte Windows soit une donnée à caractère personnel.

owner_uid ne vaut plus root par défaut

Dans 0.2.0-ga, owner_uid reste à la valeur zéro de Go dès que l'uid n'est pas lu — et cette valeur est 0, c'est-à-dire root. Chaque enregistrement de processus collecté sous Windows la portait, tout comme chaque enregistrement dont la lecture de l'uid avait été refusée, sans que rien n'indique que le nombre n'avait jamais été observé. À partir de la prochaine version, la valeur non observée est -1, et owner_identity_mode dit pourquoi elle est là : unsupported sur une plateforme sans uid, unavailable quand ce processus-là n'a pas pu être lu. Si vous levez une alerte sur owner_uid == 0, attendez-vous à ce que le compte diminue.

Deux limites honnêtes, énoncées là où vous les lisez plutôt que découvertes plus tard :

• Un agent non privilégié ne peut pas lire /etc/shadow (root:shadow 0640) : il rapporte donc password_status: unknown pour chaque compte et dit pourquoi. Le correctif au moindre privilège consiste à ajouter l'utilisateur de l'agent au groupe shadow.
• « Aucun compte dormant » et « nous n'avons pas pu lire la dernière connexion » ne sont jamais la même réponse. Si lastlog est absent — shadow 4.16+ / Ubuntu 25.04+ l'ont remplacé par lastlog2 — chaque compte rapporte une dormance unknown et l'enregistrement nomme le remplaçant.

Étapes suivantes

• Présentation de bitcollector — le reste des neuf collecteurs, et comment exécuter l'agent.
• Des preuves que votre auditeur peut vérifier — y compris la durée pendant laquelle les enregistrements restent sur l'hôte, et la borne de limitation de conservation qui la régit.
• Droits des personnes concernées — comment Cert-IX traite les demandes portant sur des données à caractère personnel.