On desapareix un nom d’usuari de VPN del pipeline de registres?

Les sessions apareixen al tauler mentre la columna del nom d’usuari queda buida, i el primer impuls és culpar l’analitzador. Aquest impuls salta tres etapes anteriors on el valor podria haver-se perdut. Una passarel·la pot emmascarar una identitat per política, una regla d’ingesta pot esborrar-la abans de la indexació, i una extracció en temps de cerca pot simplement no anomenar-la. La correcció depèn de quina frontera podeu demostrar que n’és responsable, així que la feina útil és la comparació, no la configuració.

Comenceu per un esdeveniment, no pel tauler

Trieu un sol esdeveniment d’autenticació i anoteu què l’identifica: el model i la versió de la passarel·la, el mètode d’autenticació, l’identificador de l’esdeveniment, la marca de temps i l’adreça d’origen. Afegiu el nom d’usuari exactament com el va escriure la persona, incloent-hi les majúscules, perquè una cerca sensible a les majúscules pot amagar un camp que hi és. Tracteu aquest esdeveniment com a referència per a cada comparació posterior.

Els tipus d’esdeveniment no comparteixen un esquema. Un intent fallit, un inici de sessió sense client correcte i una reconnexió de túnel poden produir camps diferents, i algunes passarel·les ometen la identitat quan l’intent no va arribar a l’autenticació d’usuari. Una columna buida en un tipus d’esdeveniment és, per tant, una prova feble d’un problema del pipeline.

Treballeu amb una identitat de prova aprovada en lloc d’un compte real d’empleat, i manteniu la comparació dins de les regles d’accés que ja regeixen les dades de registre. Habilitar àmpliament el registre detallat d’autenticació només per obtenir una mostra canvia el sistema que esteu intentant mesurar.

Compareu les quatre fronteres en ordre

El valor pot desaparèixer en un de quatre punts. Cada punt té un propietari diferent i una reparació diferent.

Atureu-vos a la primera frontera on el valor desapareix. Una discrepància entre la vista del dispositiu i la còpia crua apunta al transport o a la configuració del recopilador; una coincidència aquí però un valor absent a l’esdeveniment indexat apunta a una transformació; un valor present a l’esdeveniment indexat però absent al tauler apunta a l’extracció o a la consulta.

Aquest ordre importa perquè cada etapa posterior només pot perdre informació, mai recuperar-la. Una expressió regular no pot recuperar una cadena que una etapa anterior va substituir per un marcador, i una configuració de privadesa no pot explicar un valor que mai es va enviar.

Emmascarar a l’origen és política, no un error de l’analitzador

La documentació de registre d’ASA de Cisco descriu l’ocultació del nom d’usuari com un comportament configurable, incloent-hi com es representen els noms d’usuari no vàlids o desconeguts. Una identitat emmascarada a l’esdeveniment d’origen pot ser, doncs, exactament el que exigeix la política de privadesa, i tractar-la com un error d’anàlisi porta a una petició que debilita el control.

La representació exacta depèn de la versió i del tipus de missatge. Un esdeveniment pot portar un marcador, un altre pot ometre el camp del tot, i un error d’autenticació pot no incloure mai cap nom. Comproveu el comportament documentat per a l’esdeveniment concret en lloc d’aplicar un informe d’error antic a cada identitat absent.

Quan l’emmascarament és intencionat, la pregunta canvia de com restaurar el camp a si el requisit d’auditoria es pot complir d’una altra manera. Els identificadors de sessió, un mapatge d’identitat controlat en mans d’un grup més petit o un flux d’esdeveniments autoritzat més estret sovint satisfan la necessitat sense posar cada nom d’usuari intentat davant de cada lector de registres.

L’anonimització abans de la indexació no es pot desfer

La documentació de Splunk sobre processament d’esdeveniments descriu l’anonimització mitjançant expressions sed i transformacions que reescriuen o eliminen dades abans de la indexació. Aquesta ubicació és el punt: l’esdeveniment cru es modifica a l’entrada, així que una extracció en temps de cerca no té res a trobar.

La redacció en temps d’indexació i l’extracció de camps en temps de cerca resolen problemes diferents. La redacció limita qui pot arribar a veure el valor; l’extracció només decideix quin nom fa servir la consulta. El resum criptogràfic és una opció intermèdia que preserva la correlació, però un resum estable sobre un espai petit de noms d’usuari encara identifica quan algú pot provar noms candidats contra ell.

Si l’esdeveniment emmagatzemat encara conté la identitat, el problema és més avall: el tipus d’origen, el trencament de línies, el tractament de delimitadors, els àlies de camp o la consulta mateixa. Són reparacions ordinàries d’anàlisi i no toquen la frontera de privadesa.

Trieu la correcció que encaixi amb la frontera

Tres condicions decideixen la resposta. Primera, la política de privadesa vol excloure la identitat? Segona, el procés d’auditoria o d’investigació necessita la identitat, un pseudònim o només la sessió? Tercera, en quina frontera cal el valor: recollida, emmagatzematge o presentació?

Si la política vol excloure-la, canvieu el requisit o la presentació, no el control. Si la política permet la identitat però la recollida la descarta, repareu el recopilador i confirmeu l’esdeveniment cru. Si l’emmagatzematge és intacte, repareu l’extracció i proveu-la contra l’esdeveniment aprovat que vau capturar al principi.

Tanqueu la investigació anomenant la frontera al registre de canvis: emmascarada a l’origen, eliminada durant la ingesta o perduda per l’extracció. Aquesta sola frase diu al següent enginyer on mirar primer, i evita que una queixa sobre el tauler es converteixi en una funció de privadesa desactivada en silenci.