Datenschutz und lokale Konten

bitcollector versendet in jedem Zyklus Telemetrie vom Host, deshalb zählt das, was er nicht erfasst, genauso viel wie das, was er erfasst. Prozess-Kommandozeilen sind standardmäßig aus; der process-Collector liest niemals Umgebungsvariablen oder Dateiinhalte; nichts, was aus einem Passwort-Hash abgeleitet ist, wird jemals mitgeführt; und der Collector für lokale Konten veröffentlicht UIDs statt Login-Namen, sofern Sie sich nicht aktiv dafür entscheiden. Prozess-Datensätze sind in dem Binary, das Sie heute herunterladen können, die Ausnahme: Sie führen den Login-Namen des besitzenden Kontos mit, und die nächste Version veröffentlicht ihn standardmäßig nicht mehr — siehe was Prozess-Datensätze mitführen weiter unten; das ist der Abschnitt, den Sie lesen sollten, wenn Login-Namen in Ihrer Bewertung personenbezogene Daten sind.

Diese Seite behandelt diese Voreinstellungen und den Collector für lokale Konten, den sie am stärksten betreffen. Alles Übrige, was der Agent erhebt, steht im bitcollector-Überblick.

Datenschutz-Voreinstellungen

Datenminimierung ist der Standardzustand, kein Härtungsschritt, an den Sie denken müssen. Das ist es, was bitcollector in Frankreich ohne Diskussion einsetzbar macht.

Prozess-Kommandozeilen sind standardmäßig off. Kommandozeilen tragen routinemäßig Zugangsdaten im Klartext — mysqldump -pSECRET, --token=…, einen DSN mit eingebettetem Passwort — und dieser Agent versendet in jedem Zyklus Telemetrie vom Host.

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

Modus	Verhalten
off	Voreinstellung. Kommandozeilen werden nie erfasst.
redacted	Erfasst, wobei bekannte Geheimnisse bei der Erfassung entfernt werden, bevor der Datensatz überhaupt existiert.
full	Wortgetreu erfasst. Der Agent verweigert den Start, sofern nicht zusätzlich i_accept_secret_exposure: true gesetzt ist.

Und die Regeln drumherum:

• Der process-Collector erfasst niemals Umgebungsvariablen oder Dateiinhalte — in keinem Kommandozeilen-Modus.
• Ein Modus, der auf einer Plattform nicht ehrlich geliefert werden kann, wird verweigert, nicht vorgetäuscht. Windows hat kein originalgetreues argv, deshalb verweigert redacted dort den Dienst, statt eine Schwärzung vorzutäuschen.
• Jeder Datensatz nennt den Modus, der ihn erzeugt hat, sodass Abwesenheit lesbar ist — ein Auditor kann „da war nichts“ von „wir haben uns entschieden, nicht nachzusehen“ unterscheiden.

Privilegierte und inaktive Konten

Welche Konten auf diesem Host Root werden können, ob ihr Passwort verwendet werden kann und wie lange es her ist, dass sich jemand damit angemeldet hat — ohne dass sich jemand per SSH anmelden muss.

• Privilegierung wird aus UID 0 zuzüglich der Mitgliedschaft in sudo/wheel/admin/root gezählt, und zwar sowohl aus der Gruppenmitgliederliste als auch aus den primären GIDs. Ein Konto, dessen primäre Gruppe sudo ist, taucht in überhaupt keiner Mitgliederliste auf — und ist genau das, das Sie übersehen würden.
• Inaktivität wird ab einer konfigurierbaren Schwelle markiert — standardmäßig dormant_after: 2160h (90 Tage), was PCI DSS 8.1.4 und der üblichen ISO-27001-Kontrolle entspricht. Die Schwelle, die zu einem Urteil geführt hat, wird im Datensatz mitgeführt.

Niemals Passwort-Hashes

Das Passwortfeld aus /etc/shadow wird an einen einzigen Klassifizierer übergeben, der eine von sechs Konstanten zurückgibt (set, locked, no_password_login, empty, unrecognised, unknown). Nichts, was aus dem Hash abgeleitet ist, wird mitgeführt — und auch der Hash-Algorithmus wird bewusst nicht erfasst, denn die Algorithmus-Kennung ist ein Präfix des Hashes. Der Datensatz sagt das in seinem Feld hash_algorithm, statt es Ihnen zu überlassen, die Abwesenheit zu bemerken.

Der Collector für lokale Konten veröffentlicht standardmäßig UIDs statt Login-Namen.

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

minimal veröffentlicht ausschließlich UIDs; der Remedy-String des Datensatzes sagt dem Operator selbst, dass er lokal getent passwd <uid> ausführen soll. identity: username veröffentlicht Login-Namen, ist Opt-in, wird bei einem Tippfehler verweigert und stempelt jeden Datensatz, den es erzeugt. GECOS (vollständiger Name, Büro, Telefon) und Home-Verzeichnisse werden in keinem der beiden Modi gelesen, und tty sowie Quelladresse einer Anmeldung werden bereits bei der Erfassung verworfen. Auf einem Referenzhost reduzierten sich 34 lokale Konten auf 2 veröffentlichte Datensätze.

Was Prozess-Datensätze über das besitzende Konto mitführen

Die obige Einstellung gilt ausschließlich für den accounts-Collector. Der process-Collector ist ein eigener Codepfad, und in dem Binary, das Sie heute herunterladen können, veröffentlicht er den Login-Namen des Kontos, dem der jeweilige Prozess gehört:

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

Korrektur: Eine Unterdrückung von owner je Collector gibt es jetzt

Eine frühere Fassung dieser Seite trug eine Warnung mit der Überschrift „Das ist nicht abgesichert, und es gibt keinen Schlüssel, der es abschaltet“. Sie sagte, owner werde bedingungslos in jedem Prozess-Datensatz gesetzt, collectors.accounts.identity gelte dafür nicht und — der Satz zum Nachlesen — „eine Unterdrückung von owner je Collector gibt es noch nicht“, womit Ihnen nur zwei Optionen blieben: den process-Collector ganz abschalten, oder die Verarbeitung akzeptieren und dokumentieren.

Dieser letzte Satz hat aufgehört, wahr zu sein. collectors.process.identity existiert, steht standardmäßig auf minimal, und in diesem Modus wird der Login-Name des besitzenden Kontos überhaupt nicht gelesen. Im veröffentlichten Binary steckt er noch nicht — siehe den nächsten Kasten, den Teil der alten Warnung, der weiterhin gilt —, aber er ist nichts mehr, was diesem Produkt fehlt.

Das wird hier korrigiert statt stillschweigend umformuliert, denn es ist die Art von Aussage, nach der Sie gehandelt haben könnten. Wenn Sie den process-Collector abgeschaltet haben, um Login-Namen auf Ihren Hosts zu halten, oder in einer DSFA oder einer Kundenauskunft festgehalten haben, diese Verarbeitung lasse sich nicht unterdrücken, ist das die Entscheidung, die Sie neu prüfen sollten — sobald Sie einen Build mit diesem Schlüssel betreiben.

Eine frühere Fassung dieser Seite sagte außerdem, Login-Namen „bleiben auf dem Host, sofern Sie sich nicht aktiv dafür entscheiden“. Das galt für den accounts-Collector und war für den Agenten insgesamt falsch; es wird hier korrigiert statt stillschweigend umformuliert — eine Datenschutzaussage, auf die Sie sich verlassen haben, darf sich nicht ändern, ohne dass Sie davon erfahren.

Dieser Abschnitt beschreibt die NÄCHSTE Version, nicht das herunterladbare Binary

collectors.process.identity ist unveröffentlicht. Es steckt nicht in 0.2.0-ga (Commit 0821374), dem neuesten veröffentlichten bitcollector-Binary, und in keiner Version davor. Führen Sie bitcollector version aus und vergleichen Sie, bevor Sie etwas auf diesen Schlüssel stützen.

Was das Binary tut, das Sie heute herunterladen können. Aus dem Code zu Commit 0821374 gelesen:

• owner — der Login-Name des besitzenden Kontos — wird in jedem Prozess-Datensatz gesetzt, in jedem Erfassungszyklus, sobald der process-Collector aktiviert ist, und er ist standardmäßig aktiviert.
• collectors.accounts.identity gilt dafür nicht: Diese Einstellung wird nur vom accounts-Collector gelesen.
• collectors.process.identity in eine Konfigurationsdatei zu schreiben ändert dort nichts, und nichts sagt Ihnen das. Das Feld existiert in diesem Build nicht, und der YAML-Lader des Agenten ignoriert Schlüssel, die er nicht kennt: Er startet normal und veröffentlicht weiter Login-Namen. Kein Fehler, keine Logzeile. Behandeln Sie den Schlüssel nicht als Kontrolle, solange bitcollector version Ihnen nicht eine Version nach 0.2.0-ga zeigt.
• owner_uid ist 0 — also root — in jedem Windows-Datensatz und in jedem Prozess, dessen uid nicht gelesen werden konnte. Siehe owner_uid steht nicht mehr standardmäßig auf root weiter unten.

Auf 0.2.0-ga bleiben es die beiden oben genannten Optionen: den process-Collector abschalten (collectors.process.enabled: false), oder die Verarbeitung akzeptieren und dokumentieren.

Ab der nächsten Version entscheidet collectors.process.identity, ob der Login-Name den Host verlässt — bewusst derselbe Schlüsselname, dieselben zwei Werte und dieselbe Verweigerung in sicherer Richtung wie bei collectors.accounts.identity, damit es ein Konzept auf zwei Collectorn ist und nicht zwei Einstellungen, die sich ähneln:

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

Modus	Was ein Prozess-Datensatz mitführt
minimal	Standard. Nur owner_uid — die uid des besitzenden Kontos. Der Login-Name wird nie gelesen, erreicht also keinen Exporter, kein Log und keine Kopie eines Datensatzes im Speicher. Eine uid lösen Sie auf dem Host selbst mit getent passwd <uid> auf.
username	owner (der Login-Name — personenbezogene Daten nach DSGVO) und owner_uid. Aktive Entscheidung, und in jedem erzeugten Datensatz gestempelt.

Und die Regeln darum herum:

• Jeder andere Wert lässt den Agenten den Start verweigern, auf EN und FR. Eine Datenschutzkontrolle, die sich nicht herstellen lässt, scheitert in die sichere Richtung, statt still in die eine oder andere Richtung aufgelöst zu werden — ein Tippfehler darf weder Ihren ausdrücklichen Wunsch nach Namen verdecken noch Namen versenden, die niemand wollte.
• Jeder Datensatz stempelt den Modus, der ihn erzeugt hat, in owner_identity_mode: minimal, username, unsupported oder unavailable. Die letzten beiden sind Stempel, die der Agent je Datensatz schreibt; es sind keine Werte, die Sie setzen können, und die Verweigerung oben lehnt sie ab, wenn Sie es versuchen.
• Wenn ein Dashboard oder eine Abfrage von Ihnen owner liest, findet sie es nach dem Upgrade leer. Das ist diese Einstellung, kein kaputter Collector. Setzen Sie identity: username, um Namen wieder zu veröffentlichen.

„minimal“ bedeutet unter Windows nicht dasselbe

Windows hat keine POSIX-uid, also veröffentlicht minimal unter Windows überhaupt keine Besitzerkennung: owner_uid ist -1, und jeder Datensatz trägt den Stempel owner_identity_mode: "unsupported", damit das Fehlen lesbar ist statt bloß leer. Windows hat durchaus eine pseudonyme Kontokennung — die Benutzer-SID im Prozess-Token — und bitcollector erhebt sie bewusst nicht: Für eine Plattform, auf der dieses Projekt nicht geprüft hat, wird nichts ausgeliefert. Ein Windows-Betreiber, der die Zuordnung zum Besitzer braucht, setzt identity: username und akzeptiert, dass ein Windows-Kontoname personenbezogene Daten sind.

owner_uid steht nicht mehr standardmäßig auf root

In 0.2.0-ga bleibt owner_uid auf Gos Nullwert, sobald die uid nicht gelesen wird — und dieser Wert ist 0, also root. Jeder unter Windows erhobene Prozess-Datensatz trug ihn, ebenso jeder Datensatz, dessen uid-Lesung verweigert wurde, und nichts sagte, dass die Zahl nie beobachtet worden war. Ab der nächsten Version ist der nicht beobachtete Wert -1, und owner_identity_mode sagt, warum er dort steht: unsupported auf einer Plattform ohne uid, unavailable, wenn genau dieser Prozess nicht gelesen werden konnte. Wenn Sie auf owner_uid == 0 alarmieren, rechnen Sie mit einem sinkenden Zählerstand.

Zwei ehrliche Grenzen, benannt dort, wo Sie sie lesen, statt später entdeckt:

• Ein unprivilegierter Agent kann /etc/shadow nicht lesen (root:shadow 0640), deshalb meldet er für jedes Konto password_status: unknown und sagt, warum. Die Least-Privilege-Lösung ist, den Benutzer des Agenten der Gruppe shadow hinzuzufügen.
• „Keine inaktiven Konten“ und „wir konnten die letzte Anmeldung nicht lesen“ sind niemals dieselbe Antwort. Fehlt lastlog — shadow 4.16+ / Ubuntu 25.04+ haben es durch lastlog2 ersetzt —, meldet jedes Konto die Inaktivität als unknown, und der Datensatz benennt den Ersatz.

Nächste Schritte

• bitcollector — Überblick — die übrigen der neun Collectors und wie Sie den Agenten betreiben.
• Nachweise, die ein Auditor verifizieren kann — einschließlich dessen, wie lange Datensätze auf dem Host bleiben, und der Grenze der Speicherbegrenzung, die das regelt.
• Ihre Datenschutzrechte (DSGVO) — wie Cert-IX Anfragen zu personenbezogenen Daten bearbeitet.