Kje izgine uporabniško ime VPN iz cevovoda dnevnikov?
Preden spremenite nastavitev zasebnosti dnevnikov, primerjajte dogodek prehoda, surovo kopijo zbiralnika, indeksirani dogodek in polje ob iskanju.
Seje se prikažejo na nadzorni plošči, medtem ko stolpec z uporabniškim imenom ostane prazen, in prvi impulz je kriviti razčlenjevalnik. Ta impulz preskoči tri prejšnje stopnje, kjer bi se vrednost lahko izgubila. Prehod lahko zakrije identiteto po pravilniku, pravilo sprejema jo lahko izbriše pred indeksiranjem, zajem ob iskanju pa je preprosto ne more poimenovati. Popravek je odvisen od tega, katero mejo lahko dokažete kot odgovorno, zato je koristno delo primerjanje in ne konfiguriranje.
Začnite pri enem dogodku, ne pri nadzorni plošči
Izberite en dogodek preverjanja pristnosti in zapišite, kaj ga prepozna: model in različico prehoda, metodo preverjanja pristnosti, identifikator dogodka, časovni žig in naslov vira. Dodajte uporabniško ime točno tako, kot ga je oseba vnesla, vključno z velikimi in malimi črkami, ker lahko iskanje, občutljivo na velikost črk, skrije obstoječe polje. Ta dogodek obravnavajte kot referenco za vsako poznejšo primerjavo.
Vrste dogodkov si ne delijo iste sheme. Neuspešen poskus, uspešna prijava brez odjemalca in ponovna povezava predora lahko dajo različna polja, nekatere prehode pa identiteto izpustijo, ko poskus ni nikoli dosegel preverjanja pristnosti uporabnika. Prazen stolpec pri eni vrsti dogodka je zato šibek dokaz težave v cevovodu.
Delajte z odobreno preskusno identiteto namesto z resničnim računom zaposlenega in primerjavo držite v mejah pravil dostopa, ki že urejajo podatke dnevnikov. Široko vključevanje podrobnega beleženja preverjanja pristnosti samo za vzorec spremeni sistem, ki ga poskušate izmeriti.
Primerjajte štiri meje po vrsti
Vrednost lahko izgine na eni od štirih točk. Vsaka točka ima drugega lastnika in drugo popravilo.
| 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 |
Ustavite se pri prvi meji, kjer vrednost izgine. Neskladje med pogledom naprave in surovo kopijo kaže na prenos ali konfiguracijo zbiralnika; ujemanje tam, a manjkajoča vrednost v indeksiranem dogodku kaže na pretvorbo; vrednost, ki je v indeksiranem dogodku, a je na nadzorni plošči ni, kaže na zajem ali poizvedbo.
Ta vrstni red je pomemben, ker lahko vsaka poznejša stopnja le izgubi informacije in jih nikoli ne obnovi. Regularni izraz ne more vrniti niza, ki ga je prejšnja stopnja nadomestila z nadomestnim znakom, in nastavitev zasebnosti ne more pojasniti vrednosti, ki ni bila nikoli poslana.
Zakrivanje pri viru je pravilnik, ne napaka razčlenjevalnika
Dokumentacija o beleženju ASA podjetja Cisco opisuje skrivanje uporabniškega imena kot konfigurabilno vedenje, vključno s tem, kako so prikazana neveljavna ali neznana uporabniška imena. Zakrita identiteta v izvornem dogodku je zato lahko natanko to, kar zahteva pravilnik zasebnosti, in obravnavanje tega kot napake razčlenjevanja vodi v zahtevo, ki oslabi nadzor.
Natančen prikaz je odvisen od različice in vrste sporočila. En dogodek lahko nosi nadomestni znak, drugi lahko polje povsem izpusti, neuspeh preverjanja pristnosti pa morda nikoli ne vsebuje imena. Preverite dokumentirano vedenje za določen dogodek, namesto da bi staro poročilo o napaki uporabili za vsako manjkajočo identiteto.
Ko je zakrivanje namerno, se vprašanje spremeni iz tega, kako obnoviti polje, v to, ali je mogoče zahtevo revizije izpolniti drugače. Identifikatorji seje, nadzorovano preslikavo identitet pri manjši skupini ali ožji pooblaščeni tok dogodkov pogosto zadovoljijo potrebo, ne da bi vsako poskušeno uporabniško ime izpostavili vsakemu bralcu dnevnikov.
Anonimizacije pred indeksiranjem ni mogoče razveljaviti
Dokumentacija podjetja Splunk o obdelavi dogodkov opisuje anonimizacijo z izrazi sed in pretvorbami, ki podatke prepišejo ali odstranijo pred indeksiranjem. Prav ta umestitev je bistvo: surovi dogodek se spremeni ob vstopu, zato zajem ob iskanju nima več česa najti.
Urejanje ob indeksiranju in zajem polj ob iskanju rešujeta različne težave. Urejanje omejuje, kdo lahko vrednost sploh vidi; zajem le odloči, katero ime uporabi poizvedba. Zgoščevanje je vmesna možnost, ki ohrani korelacijo, a stabilna zgoščena vrednost na majhnem prostoru uporabniških imen še vedno identificira, ko lahko nekdo proti njej preizkusi kandidatna imena.
Če shranjeni dogodek še vedno vsebuje identiteto, je težava nižje: vrsta vira, deljenje vrstic, obravnava ločil, aliasi polj ali sama poizvedba. To so običajna popravila razčlenjevanja in se ne dotikajo meje zasebnosti.
Izberite popravilo, ki ustreza meji
Odgovor določajo trije pogoji. Prvič, ali pravilnik zasebnosti namerava identiteto izključiti? Drugič, ali proces revizije ali preiskave potrebuje identiteto, psevdonim ali samo sejo? Tretjič, na kateri meji je vrednost potrebna — zbiranje, shranjevanje ali predstavitev?
Če pravilnik namerava izključitev, spremenite zahtevo ali predstavitev, ne nadzora. Če pravilnik identiteto dovoljuje, a jo zbiranje izgubi, popravite zbiralnik in potrdite surovi dogodek. Če je shranjevanje nepoškodovano, popravite zajem in ga preizkusite na odobrenem dogodku, ki ste ga zajeli na začetku.
Preiskavo zaključite tako, da v zapisu spremembe poimenujete mejo: zakrito pri viru, odstranjeno med sprejemom ali zgrešeno pri zajemu. Ta en stavek pove naslednjemu inženirju, kam naj pogleda najprej, in prepreči, da bi se pritožba glede nadzorne plošče spremenila v tiho onemogočeno funkcijo zasebnosti.