Privacidad y cuentas locales

bitcollector envía telemetría fuera del host en cada ciclo, así que lo que se niega a recopilar importa tanto como lo que recopila. Las líneas de comandos de los procesos están desactivadas por defecto; el recopilador de procesos nunca lee variables de entorno ni el contenido de los ficheros; nunca se lleva nada derivado de un hash de contraseña; y el recopilador de cuentas locales publica UID en lugar de nombres de inicio de sesión salvo que usted lo active explícitamente. Los registros de procesos son la excepción en el binario que usted puede descargar hoy: llevan el nombre de inicio de sesión de la cuenta propietaria, y la próxima versión deja de publicarlo por defecto — vea qué llevan los registros de procesos más abajo, que es la sección que hay que leer si los nombres de inicio de sesión son datos personales en su evaluación.

Esta página cubre esos valores por defecto y el recopilador de cuentas locales sobre el que más inciden. Para todo lo demás que reúne el agente, consulte la visión general de bitcollector.

Valores por defecto de privacidad

La minimización de datos es el estado por defecto, no un paso de endurecimiento que usted tenga que recordar. Esto es lo que hace que bitcollector se pueda desplegar en Francia sin discusiones.

Las líneas de comandos de los procesos están en off por defecto. Las líneas de comandos llevan habitualmente credenciales en texto claro — mysqldump -pSECRET, --token=…, un DSN con la contraseña incrustada — y este agente envía telemetría fuera del host en cada ciclo.

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

Modo	Comportamiento
off	Por defecto. Las líneas de comandos nunca se recopilan.
redacted	Se recopilan con los secretos conocidos eliminados en la captura, antes de que el registro exista.
full	Se recopilan literalmente. El agente se niega a arrancar salvo que además se establezca i_accept_secret_exposure: true.

Y las reglas que lo rodean:

• El recopilador de procesos nunca recopila variables de entorno ni el contenido de los ficheros, en ningún modo de línea de comandos.
• Un modo que no puede cumplirse honestamente en una plataforma se rechaza, no se simula. Windows no tiene un argv fiel, así que redacted se rechaza allí en lugar de fingir que redacta.
• Cada registro declara con qué modo se produjo, de modo que la ausencia es legible — un auditor puede distinguir "no había nada" de "decidimos no mirar".

Cuentas privilegiadas e inactivas

Qué cuentas de este host pueden convertirse en root, si su contraseña puede usarse y cuánto hace que alguien inició sesión con ellas — sin que nadie tenga que entrar por SSH.

• El privilegio se cuenta a partir del UID 0 más la pertenencia a sudo/wheel/admin/root, tomada tanto de la lista de miembros del grupo como de los GID primarios. Una cuenta cuyo grupo primario es sudo no aparece en ninguna lista de miembros, y es exactamente la que se le escaparía.
• La inactividad se señala a partir de un umbral configurable — dormant_after: 2160h (90 días) por defecto, que es PCI DSS 8.1.4 y el control habitual de ISO 27001. El umbral que produjo cada veredicto se lleva en el registro.

Nunca, jamás, hashes de contraseña

El campo de contraseña de /etc/shadow se entrega a un único clasificador que devuelve una de seis constantes (set, locked, no_password_login, empty, unrecognised, unknown). No se lleva nada derivado del hash — y el algoritmo de hash tampoco se recoge deliberadamente, porque el identificador del algoritmo es un prefijo del hash. El registro lo dice así en su campo hash_algorithm en lugar de dejar que usted note la ausencia.

El recopilador de cuentas locales publica UID en lugar de nombres de inicio de sesión por defecto.

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

minimal publica únicamente UID; la propia cadena de remedio del registro le dice al operador que ejecute getent passwd <uid> localmente. identity: username publica los nombres de inicio de sesión, requiere activación explícita, se rechaza si se escribe mal y marca todos los registros que produce. GECOS (nombre completo, oficina, teléfono) y los directorios personales nunca se leen en ninguno de los dos modos, y el tty y la dirección de origen de un inicio de sesión se descartan en la captura. En un host de referencia, 34 cuentas locales se redujeron a 2 registros publicados.

Qué llevan los registros de procesos sobre la cuenta propietaria

El control anterior rige únicamente el recopilador de cuentas. El recopilador de procesos es una ruta de código independiente y, en el binario que usted puede descargar hoy, publica el nombre de inicio de sesión de la cuenta propietaria de cada proceso:

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

Corrección: ya existe una supresión de owner por recopilador

Una versión anterior de esta página llevaba una advertencia titulada «Esto no está condicionado, y no hay ninguna clave que lo desactive». Decía que owner se establecía incondicionalmente en todos los registros de procesos, que collectors.accounts.identity no se le aplicaba y — la frase que conviene releer — que «todavía no existe una supresión de owner por recopilador», dejándole solo dos opciones: desactivar por completo el recopilador de procesos, o aceptar y documentar el tratamiento.

Esa última frase ha dejado de ser cierta. collectors.process.identity existe, su valor por defecto es minimal y, en ese modo, el nombre de inicio de sesión de la cuenta propietaria no se lee nunca. Todavía no está en el binario publicado — vea el recuadro siguiente, que es la parte de la vieja advertencia que sigue en pie —, pero ya no es algo de lo que este producto carezca.

Se corrige aquí en lugar de reescribirse en silencio, porque es el tipo de declaración sobre la que usted pudo actuar. Si desactivó el recopilador de procesos para mantener los nombres de inicio de sesión en sus hosts, o dejó constancia en una EIPD o en una respuesta a un cliente de que este tratamiento no podía suprimirse, esa es la decisión que conviene revisar en cuanto ejecute una versión que tenga la clave.

Una versión anterior de esta página decía además que los nombres de inicio de sesión "se quedan en el host salvo que usted lo active explícitamente". Eso era cierto del recopilador de cuentas y falso respecto al agente en su conjunto, y se corrige aquí en lugar de reescribirse en silencio — una declaración de protección de datos en la que usted confió no debería cambiar sin que se le diga.

Esta sección describe la PRÓXIMA versión, no el binario que puede descargar

collectors.process.identity está sin publicar. No está en 0.2.0-ga (commit 0821374), el binario de bitcollector publicado más reciente, ni en ninguna versión anterior. Ejecute bitcollector version y compare antes de planificar nada sobre esta clave.

Lo que hace el binario que puede descargar hoy. Leído del código en el commit 0821374:

• owner — el nombre de inicio de sesión de la cuenta propietaria — se establece en todos los registros de procesos, en cada ciclo de recopilación, siempre que el recopilador de procesos esté habilitado, y lo está por defecto.
• collectors.accounts.identity no se le aplica: ese ajuste solo lo lee el recopilador de cuentas.
• Escribir collectors.process.identity en un fichero de configuración no cambia nada allí, y nada se lo advierte. El campo no existe en esa versión y el cargador YAML del agente ignora las claves que no reconoce: arranca con normalidad y sigue publicando nombres de inicio de sesión. No hay error ni línea de registro. No trate la clave como un control hasta que bitcollector version le muestre una versión posterior a 0.2.0-ga.
• owner_uid vale 0 — es decir, root — en todos los registros de Windows y en todo proceso cuyo uid no se pudo leer. Vea owner_uid ya no vale root por defecto más abajo.

En 0.2.0-ga las dos opciones siguen siendo las citadas arriba: desactivar el recopilador de procesos (collectors.process.enabled: false), o aceptar y documentar el tratamiento.

A partir de la próxima versión, collectors.process.identity decide si el nombre de inicio de sesión sale del host — deliberadamente el mismo nombre de clave, los mismos dos valores y el mismo rechazo en posición cerrada que collectors.accounts.identity, para que sea un solo concepto en dos recopiladores y no dos ajustes que se parecen:

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

Modo	Qué lleva un registro de proceso
minimal	Por defecto. Solo owner_uid — el uid de la cuenta propietaria. El nombre de inicio de sesión no se lee nunca, así que no llega a ningún exportador, ni a ningún registro de log, ni a ninguna copia en memoria de un registro. Resuelva un uid en el propio host con getent passwd <uid>.
username	owner (el nombre de inicio de sesión — dato personal según el RGPD) y owner_uid. De activación explícita, y sellado en todos los registros que produce.

Y las reglas que lo rodean:

• Cualquier otro valor hace que el agente se niegue a arrancar, en EN y FR. Un control de privacidad que no puede establecerse falla en posición cerrada en lugar de resolverse en silencio en un sentido o en otro — una errata no debe ocultar su petición explícita de nombres, ni enviar nombres que nadie pidió.
• Cada registro sella el modo que lo produjo en owner_identity_mode: minimal, username, unsupported o unavailable. Los dos últimos son sellos que el agente escribe por registro; no son valores que usted pueda fijar, y el rechazo anterior los descarta si lo intenta.
• Si algún panel o alguna consulta suya lee owner, lo encontrará vacío tras actualizar. Eso es este ajuste, no un recopilador roto. Ponga identity: username para volver a publicar los nombres.

«minimal» no significa lo mismo en Windows

Windows no tiene uid POSIX, así que en Windows minimal no publica ningún identificador de propietario: owner_uid es -1 y todos los registros llevan el sello owner_identity_mode: "unsupported", de modo que la ausencia es legible en lugar de quedar en blanco. Windows sí tiene un identificador de cuenta seudonimizado — el SID de usuario en el token del proceso — y bitcollector deliberadamente no lo recopila: no se publica nada para una plataforma sobre la que este proyecto no ha hecho comprobaciones. Un operador de Windows que necesite atribuir el propietario pone identity: username, y acepta que un nombre de cuenta de Windows es un dato personal.

owner_uid ya no vale root por defecto

En 0.2.0-ga, owner_uid se queda en el valor cero de Go siempre que el uid no se lee — y ese valor es 0, que es root. Todos los registros de procesos recopilados en Windows lo llevaban, igual que todos aquellos cuya lectura del uid fue denegada, sin nada que dijera que el número nunca se había observado. A partir de la próxima versión, el valor no observado es -1, y owner_identity_mode dice por qué está ahí: unsupported en una plataforma sin uid, unavailable cuando ese proceso concreto no se pudo leer. Si usted alerta sobre owner_uid == 0, espere que el recuento baje.

Dos límites honestos, declarados donde usted los lee y no descubiertos más tarde:

• Un agente sin privilegios no puede leer /etc/shadow (root:shadow 0640), así que reporta password_status: unknown para cada cuenta y dice por qué. La solución de mínimo privilegio es añadir el usuario del agente al grupo shadow.
• "No hay cuentas inactivas" y "no pudimos leer el último inicio de sesión" nunca son la misma respuesta. Si lastlog no está — shadow 4.16+ / Ubuntu 25.04+ lo sustituyeron por lastlog2 — cada cuenta reporta inactividad unknown y el registro nombra el sustituto.

Próximos pasos

• Visión general de bitcollector — el resto de los nueve recopiladores, y cómo ejecutar el agente.
• Evidencia que un auditor puede verificar — incluido cuánto tiempo permanecen los registros en el host, y el límite de limitación del plazo de conservación que lo gobierna.
• Derechos de los interesados — cómo gestiona Cert-IX las solicitudes sobre datos personales.