Privacy e account locali

bitcollector invia telemetria fuori dall'host a ogni ciclo, quindi ciò a cui rinuncia conta quanto ciò che raccoglie. Le righe di comando dei processi sono disattivate per impostazione predefinita; il collector process non legge mai variabili d'ambiente né contenuti di file; nulla di derivato da un hash di password viene mai trasportato; e il collector degli account locali pubblica gli UID anziché i nomi di login, a meno che tu non scelga esplicitamente il contrario. I record dei processi fanno eccezione nel binario che puoi scaricare oggi: riportano il nome di login dell'account proprietario, e la prossima versione smette di pubblicarlo per impostazione predefinita — vedi cosa riportano i record dei processi più sotto: è la sezione da leggere se nella tua valutazione i nomi di login sono dati personali.

Questa pagina copre queste impostazioni predefinite e il collector degli account locali su cui incidono di più. Per tutto il resto di ciò che l'agente raccoglie, vedi la panoramica di bitcollector.

Impostazioni predefinite di privacy

La minimizzazione dei dati è lo stato predefinito, non un passo di hardening che devi ricordarti di fare. È questo che rende bitcollector distribuibile in Francia senza discussioni.

Le righe di comando dei processi sono off per impostazione predefinita. Le righe di comando trasportano regolarmente credenziali in chiaro — mysqldump -pSECRET, --token=…, un DSN con password incorporata — e questo agente invia telemetria fuori dall'host a ogni ciclo.

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

Modalità	Comportamento
off	Predefinita. Le righe di comando non vengono mai raccolte.
redacted	Raccolte con i segreti noti rimossi al momento della cattura, prima che il record esista.
full	Raccolte alla lettera. L'agente si rifiuta di avviarsi a meno che non sia impostato anche i_accept_secret_exposure: true.

E le regole che le accompagnano:

• Il collector process non raccoglie mai variabili d'ambiente né contenuti di file, in nessuna modalità di riga di comando.
• Una modalità che non può essere onestamente garantita su una piattaforma viene rifiutata, non simulata. Windows non ha un argv fedele, quindi lì redacted rifiuta anziché fingere di oscurare.
• Ogni record dichiara la modalità che lo ha prodotto, così l'assenza è leggibile: un auditor può distinguere "non c'era nulla" da "abbiamo scelto di non guardare".

Account privilegiati e dormienti

Quali account su questo host possono diventare root, se la loro password è utilizzabile e da quanto tempo nessuno vi accede — senza che nessuno debba collegarsi in SSH.

• Il privilegio è calcolato da UID 0 più l'appartenenza a sudo/wheel/admin/root, presa sia dall'elenco dei membri del gruppo sia dai GID primari. Un account il cui gruppo primario è sudo non compare in nessun elenco di membri, ed è esattamente quello che ti sfuggirebbe.
• La dormienza viene segnalata oltre una soglia configurabile — dormant_after: 2160h (90 giorni) per impostazione predefinita, che è il PCI DSS 8.1.4 e il consueto controllo ISO 27001. La soglia che ha prodotto ciascun verdetto è riportata nel record.

Nessun hash di password, mai

Il campo password di /etc/shadow viene passato a un unico classificatore che restituisce una di sei costanti (set, locked, no_password_login, empty, unrecognised, unknown). Non viene trasportato nulla di derivato dall'hash — e neppure l'algoritmo di hashing viene raccolto, perché l'identificativo dell'algoritmo è un prefisso dell'hash. Il record lo dichiara nel proprio campo hash_algorithm invece di lasciarti notare l'assenza.

Il collector degli account locali pubblica gli UID anziché i nomi di login per impostazione predefinita.

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

minimal pubblica solo gli UID; la stringa di rimedio del record stesso indica all'operatore di eseguire getent passwd <uid> in locale. identity: username pubblica i nomi di login, richiede attivazione esplicita, viene rifiutato se scritto male e marca ogni record che produce. GECOS (nome completo, ufficio, telefono) e le home directory non vengono mai lette in nessuna delle due modalità, e il tty e l'indirizzo di provenienza di un login vengono scartati al momento della cattura. Su un host di riferimento, 34 account locali si sono ridotti a 2 record pubblicati.

Cosa riportano i record dei processi sull'account proprietario

Il controllo qui sopra governa solo il collector degli account. Il collector dei processi è un percorso di codice distinto e, nel binario che puoi scaricare oggi, pubblica il nome di login dell'account proprietario di ciascun processo:

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

Correzione: una soppressione di owner per singolo collector adesso esiste

Una versione precedente di questa pagina riportava un avviso intitolato «Non è condizionato, e non esiste alcuna chiave che lo disattivi». Diceva che owner veniva impostato incondizionatamente su ogni record di processo, che collectors.accounts.identity non vi si applicava e — la frase da rileggere — che «una soppressione di owner per singolo collector non esiste ancora», lasciandoti due sole opzioni: disattivare del tutto il collector dei processi, oppure accettare e documentare il trattamento.

Quest'ultima frase ha smesso di essere vera. collectors.process.identity esiste, il suo valore predefinito è minimal e in quella modalità il nome di login dell'account proprietario non viene mai letto. Non è ancora nel binario pubblicato — vedi il riquadro successivo, che è la parte del vecchio avviso che resta valida — ma non è più qualcosa che a questo prodotto manca.

La correzione è fatta qui anziché riformulata in silenzio, perché è il tipo di dichiarazione su cui potresti aver agito. Se hai disattivato il collector dei processi per tenere i nomi di login sui tuoi host, o hai messo agli atti in una DPIA o in una risposta a un cliente che questo trattamento non poteva essere soppresso, quella è la decisione da riesaminare non appena eseguirai una build che ha la chiave.

Una versione precedente di questa pagina diceva anche che i nomi di login "restano sull'host a meno che tu non scelga esplicitamente il contrario". Era vero per il collector degli account ed errato per l'agente nel suo complesso, ed è corretto qui anziché riformulato in silenzio — una dichiarazione in materia di protezione dei dati su cui hai fatto affidamento non deve cambiare senza che tu ne sia informato.

Questa sezione descrive la PROSSIMA versione, non il binario scaricabile

collectors.process.identity non è rilasciato. Non è in 0.2.0-ga (commit 0821374), il binario di bitcollector pubblicato più recente, né in alcuna versione precedente. Esegui bitcollector version e confronta prima di programmare qualsiasi cosa su questa chiave.

Cosa fa il binario che puoi scaricare oggi. Letto dal codice al commit 0821374:

• owner — il nome di login dell'account proprietario — viene impostato su ogni record di processo, a ogni ciclo di raccolta, ogni volta che il collector dei processi è abilitato, ed è abilitato per impostazione predefinita.
• collectors.accounts.identity non si applica a esso: quella impostazione è letta solo dal collector degli account.
• Scrivere collectors.process.identity in un file di configurazione lì non cambia nulla, e nulla te lo segnala. Il campo non esiste in quella build e il caricatore YAML dell'agente ignora le chiavi che non riconosce: parte normalmente e continua a pubblicare i nomi di login. Nessun errore, nessuna riga di log. Non trattare la chiave come un controllo finché bitcollector version non ti mostra una versione successiva a 0.2.0-ga.
• owner_uid vale 0 — cioè root — su ogni record Windows e su ogni processo il cui uid non è stato letto. Vedi owner_uid non vale più root per impostazione predefinita più sotto.

Su 0.2.0-ga le opzioni restano le due indicate sopra: disattivare il collector dei processi (collectors.process.enabled: false), oppure accettare e documentare il trattamento.

Dalla prossima versione, collectors.process.identity decide se il nome di login lascia l'host — deliberatamente lo stesso nome di chiave, gli stessi due valori e lo stesso rifiuto in posizione chiusa di collectors.accounts.identity, così che sia un unico concetto su due collector e non due impostazioni che si somigliano:

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

Modalità	Cosa riporta un record di processo
minimal	Predefinita. Solo owner_uid — l'uid dell'account proprietario. Il nome di login non viene mai letto, quindi non raggiunge alcun exporter, alcun log né alcuna copia in memoria di un record. Risolvi un uid sull'host stesso con getent passwd <uid>.
username	owner (il nome di login — dato personale ai sensi del GDPR) e owner_uid. Scelta esplicita, e marcata in ogni record che produce.

E le regole che la circondano:

• Qualsiasi altro valore fa rifiutare l'avvio, in EN e FR. Un controllo di privacy che non può essere stabilito fallisce in posizione chiusa anziché essere risolto in silenzio in una direzione o nell'altra — un refuso non deve né nascondere la tua richiesta esplicita di nomi, né spedire nomi che nessuno ha chiesto.
• Ogni record marca la modalità che lo ha prodotto in owner_identity_mode: minimal, username, unsupported o unavailable. Le ultime due sono marcature che l'agente scrive per singolo record; non sono valori che puoi impostare, e il rifiuto qui sopra le respinge se ci provi.
• Se una tua dashboard o una tua query legge owner, dopo l'aggiornamento lo troverà vuoto. È questa impostazione, non un collector rotto. Imposta identity: username per pubblicare di nuovo i nomi.

«minimal» non significa la stessa cosa su Windows

Windows non ha un uid POSIX, quindi su Windows minimal non pubblica alcun identificativo del proprietario: owner_uid è -1 e ogni record è marcato owner_identity_mode: "unsupported", così l'assenza è leggibile anziché vuota. Windows ha comunque un identificativo di account pseudonimo — il SID utente nel token del processo — e bitcollector deliberatamente non lo raccoglie: nulla viene rilasciato per una piattaforma su cui questo progetto non ha verificato. Un operatore Windows che ha bisogno di attribuire il proprietario imposta identity: username, e accetta che un nome di account Windows sia un dato personale.

owner_uid non vale più root per impostazione predefinita

In 0.2.0-ga, owner_uid resta al valore zero di Go ogni volta che l'uid non viene letto — e quel valore è 0, cioè root. Ogni record di processo raccolto su Windows lo riportava, come ogni record la cui lettura dell'uid era stata rifiutata, senza che nulla dicesse che quel numero non era mai stato osservato. Dalla prossima versione il valore non osservato è -1, e owner_identity_mode dice perché è lì: unsupported su una piattaforma senza uid, unavailable quando quel singolo processo non è stato letto. Se generi un allarme su owner_uid == 0, aspettati che il conteggio cali.

Due limiti dichiarati con onestà, esposti dove li leggi anziché scoperti in seguito:

• Un agente senza privilegi non può leggere /etc/shadow (root:shadow 0640), quindi riporta password_status: unknown per ogni account e dice perché. La correzione a privilegio minimo è aggiungere l'utente dell'agente al gruppo shadow.
• "Nessun account dormiente" e "non siamo riusciti a leggere l'ultimo accesso" non sono mai la stessa risposta. Se lastlog è assente — shadow 4.16+ / Ubuntu 25.04+ lo hanno sostituito con lastlog2 — ogni account riporta dormienza unknown e il record nomina il sostituto.

Passi successivi

• Panoramica di bitcollector — il resto dei nove collector e come eseguire l'agente.
• Evidenze che un auditor può verificare — compreso per quanto tempo i record restano sull'host e il vincolo di limitazione della conservazione che lo governa.
• I tuoi diritti in materia di protezione dei dati (GDPR) — come Cert-IX gestisce le richieste relative ai dati personali.