Gdje korisničko ime VPN-a nestaje iz cjevovoda zapisa?
Usporedite događaj pristupnika, sirovu kopiju kolektora, indeksirani događaj i polje pri pretrazi prije nego što promijenite postavku privatnosti zapisa.
Sesije se pojavljuju na nadzornoj ploči dok stupac korisničkog imena ostaje prazan, a prvi poriv je okriviti parser. Taj poriv preskače tri ranije faze u kojima je vrijednost mogla biti izgubljena. Pristupnik može maskirati identitet prema pravilniku, pravilo unosa može ga izbrisati prije indeksiranja, a izdvajanje pri pretrazi može ga jednostavno propustiti imenovati. Popravak ovisi o tome koja se granica može dokazati kao odgovorna, pa je koristan posao usporedba, a ne konfiguracija.
Pođite od jednog događaja, a ne od nadzorne ploče
Odaberite jedan događaj autentifikacije i zapišite što ga identificira: model i izdanje pristupnika, metodu autentifikacije, identifikator događaja, vremensku oznaku i izvornu adresu. Dodajte korisničko ime točno onako kako ga je osoba upisala, uključujući velika i mala slova, jer pretraga osjetljiva na velika slova može sakriti polje koje postoji. Uzmite taj događaj kao referencu za svaku kasniju usporedbu.
Vrste događaja ne dijele istu shemu. Neuspjeli pokušaj, uspješna prijava bez klijenta i ponovno povezivanje tunela mogu dati različita polja, a neki pristupnici izostavljaju identitet kada pokušaj nije stigao do autentifikacije korisnika. Prazan stupac kod jedne vrste događaja zato je slab dokaz problema u cjevovodu.
Radite s odobrenim testnim identitetom umjesto sa stvarnim računom zaposlenika i držite usporedbu unutar pravila pristupa koja već uređuju podatke zapisa. Široko uključivanje opširnog zapisivanja autentifikacije samo da biste dobili uzorak mijenja sustav koji pokušavate izmjeriti.
Usporedite četiri granice redom
Vrijednost može nestati na jednoj od četiri točke. Svaka točka ima drugog vlasnika i drugi popravak.
| Boundary | What to compare | A gap means |
|---|---|---|
| Gateway event view | The device's own event display and logging policy | The identity was masked or never emitted |
| Collector receive | The raw event as received, before parsing | Transport, filter or source selection dropped it |
| Index-time pipeline | Transforms applied before storage | Redaction or rewriting removed the value |
| Search-time extraction | The field name and regex used by the query | The label does not match the stored key |
Zaustavite se na prvoj granici na kojoj vrijednost nestaje. Neusklađenost između prikaza uređaja i sirove kopije upućuje na prijevoz ili konfiguraciju kolektora; podudaranje tamo, ali vrijednost koja nedostaje u indeksiranom događaju upućuje na transformaciju; vrijednost prisutna u indeksiranom događaju, ali odsutna na nadzornoj ploči upućuje na izdvajanje ili upit.
Taj je redoslijed važan jer svaka kasnija faza može samo izgubiti informaciju, nikada je vratiti. Regularni izraz ne može vratiti niz koji je ranija faza zamijenila rezerviranim mjestom, a postavka privatnosti ne može objasniti vrijednost koja nikada nije poslana.
Maskiranje na izvoru je pravilnik, a ne greška parsera
Ciscova dokumentacija o zapisivanju ASA opisuje skrivanje korisničkog imena kao konfigurabilno ponašanje, uključujući to kako se prikazuju nevaljana ili nepoznata korisnička imena. Maskirani identitet u izvornom događaju zato može biti upravo ono što pravilnik privatnosti zahtijeva, a tretiranje toga kao greške pri raščlambi vodi zahtjevu koji slabi kontrolu.
Točan prikaz ovisi o izdanju i vrsti poruke. Jedan događaj može nositi rezervirano mjesto, drugi može potpuno izostaviti polje, a neuspjeh autentifikacije možda nikada neće sadržavati ime. Provjerite dokumentirano ponašanje za konkretan događaj umjesto da primjenjujete stari izvještaj o grešci na svaki nedostajući identitet.
Kada je maskiranje namjerno, pitanje se mijenja od toga kako vratiti polje na to može li se zahtjev revizije ispuniti na drugi način. Identifikatori sesije, kontrolirano mapiranje identiteta koje drži manja skupina ili uži ovlašteni tok događaja često zadovoljavaju potrebu bez izlaganja svakog pokušanog korisničkog imena svakom čitatelju zapisa.
Anonimizacija prije indeksiranja ne može se poništiti
Splunkova dokumentacija o obradi događaja opisuje anonimizaciju pomoću sed izraza i transformacija koje prepisuju ili uklanjaju podatke prije indeksiranja. Upravo je to mjesto poanta: sirovi događaj mijenja se na ulazu, pa izdvajanje pri pretrazi nema što pronaći.
Redakcija pri indeksiranju i izdvajanje polja pri pretrazi rješavaju različite probleme. Redakcija ograničava kome je vrijednost uopće vidljiva; izdvajanje samo odlučuje koje ime upit koristi. Raspršivanje je srednja opcija koja čuva korelaciju, ali stabilan raspršeni zapis nad malim prostorom korisničkih imena ipak identificira kada netko može testirati moguća imena prema njemu.
Ako pohranjeni događaj još sadrži identitet, problem je nizvodno: vrsta izvora, lomljenje redaka, obrada razdjelnika, aliasi polja ili sam upit. To su obični popravci raščlambe i ne diraju granicu privatnosti.
Odaberite popravak koji odgovara granici
Tri uvjeta određuju odgovor. Prvo, namjerava li pravilnik privatnosti isključiti identitet? Drugo, treba li procesu revizije ili istrage identitet, pseudonim ili samo sesija? Treće, na kojoj je granici vrijednost potrebna — prikupljanje, pohrana ili prikaz?
Ako pravilnik namjerava isključenje, promijenite zahtjev ili prikaz, a ne kontrolu. Ako pravilnik dopušta identitet, ali prikupljanje ga ispušta, popravite kolektor i potvrdite sirovi događaj. Ako je pohrana ispravna, popravite izdvajanje i testirajte ga na odobrenom događaju koji ste snimili na početku.
Zatvorite istragu imenovanjem granice u zapisu o promjeni: maskirano na izvoru, uklonjeno tijekom unosa ili propušteno pri izdvajanju. Ta jedna rečenica govori sljedećem inženjeru gdje prvo pogledati i sprječava da se pritužba na nadzornu ploču pretvori u tiho onemogućenu značajku privatnosti.