Kie malaperas VPN-uzantnomo el la protokola fluo?
Komparu la pordegan eventon, la krudan kopion de la kolektanto, la indeksitan eventon kaj la kampon dum serĉado antaŭ ol ŝanĝi privatecan kontrolon de protokoloj.
Sesioj aperas en la panelo dum la kolumno de uzantnomo restas malplena, kaj la unua instinkto estas kulpigi la analizilon. Tiu instinkto preterlasas tri pli fruajn etapojn, kie la valoro povus esti perdita. Pordego povas kaŝi identecon laŭ politiko, enira regulo povas forigi ĝin antaŭ indeksado, kaj eltiraĵo dum serĉado povas simple malsukcesi nomi ĝin. La korekto dependas de tio, kiun limon vi povas pruvi respondeca, do la utila laboro estas komparado, ne agordado.
Komencu per unu evento, ne per la panelo
Elektu unu aŭtentikigan eventon kaj notu, kio identigas ĝin: la modelo kaj eldono de la pordego, la aŭtentikiga metodo, la eventa identigilo, la tempindiko kaj la fonta adreso. Aldonu la uzantnomon ĝuste tiel, kiel la persono tajpis ĝin, inkluzive de uskleco, ĉar usklo-sentema serĉo povas kaŝi kampon, kiu ĉeestas. Traktu tiun eventon kiel referencon por ĉiu posta komparo.
Eventaj tipoj ne dividas unu skemon. Malsukcesa provo, sukcesa ensaluto sen kliento kaj rekonekto de tunelo povas ĉiu produkti malsamajn kampojn, kaj iuj pordegoj ellasas la identecon, kiam la provo neniam atingis uzantan aŭtentikigon. Malplena kolumno ĉe unu eventa tipo estas do malforta pruvo de problemo en la fluo.
Laboru kun aprobita testa identeco anstataŭ reala dungita konto, kaj tenu la komparadon ene de la aliraj reguloj, kiuj jam regas la protokolajn datumojn. Larĝe ŝalti detalhavigan aŭtentikigan protokoladon nur por akiri specimenon ŝanĝas la sistemon, kiun vi provas mezuri.
Komparu la kvar limojn laŭ ordo
La valoro povas malaperi ĉe unu el kvar punktoj. Ĉiu punkto havas alian posedanton kaj alian riparon.
| 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 |
Haltu ĉe la unua limo, kie la valoro malaperas. Malkongruo inter la vido de la aparato kaj la kruda kopio montras al transporto aŭ agordo de la kolektanto; kongruo tie, sed mankanta valoro en la indeksita evento montras al transformo; valoro ĉeesta en la indeksita evento sed mankanta en la panelo montras al eltiraĵo aŭ la informpeto.
Tiu ordo gravas, ĉar ĉiu posta etapo povas nur perdi informon, neniam restarigi ĝin. Regula esprimo ne povas rekuperi ĉenon, kiun pli frua etapo anstataŭigis per lokokupilo, kaj privateca agordo ne povas klarigi valoron, kiu neniam estis sendita.
Kaŝado ĉe la fonto estas politiko, ne cimo de la analizilo
La dokumentaro de Cisco pri ASA-protokolado priskribas kaŝadon de uzantnomo kiel agordeblan konduton, inkluzive de tio, kiel prezentiĝas nevalidaj aŭ nekonataj uzantnomoj. Kaŝita identeco en la fonta evento do povas esti ĝuste tio, kion la privateca politiko postulas, kaj trakti ĝin kiel analizan malsukceson kondukas al peto, kiu malfortigas la kontrolon.
La preciza prezento dependas de la eldono kaj de la mesaĝa tipo. Unu evento povas porti lokokupilon, alia povas tute ellasi la kampon, kaj aŭtentikiga malsukceso eble neniam enhavos nomon. Kontrolu la dokumentitan konduton por la konkreta evento anstataŭ apliki historian cimraporton al ĉiu mankanta identeco.
Kiam kaŝado estas intenca, la demando ŝanĝiĝas de kiel restarigi la kampon al ĉu la revizia postulo povas esti plenumita alimaniere. Sesiaj identigiloj, kontrolita identeca mapado tenata de pli malgranda grupo, aŭ pli mallarĝa rajtigita eventa fluo ofte kontentigas la bezonon sen meti ĉiun provitan uzantnomon antaŭ ĉiu protokola leganto.
Anonimigo antaŭ indeksado ne estas malfarebla
La dokumentaro de Splunk pri eventa prilaborado priskribas anonimigon per sed-esprimoj kaj transformoj, kiuj reskribas aŭ forigas datumojn antaŭ ol ili estas indeksitaj. Ĝuste tiu loko estas la punkto: la kruda evento ŝanĝiĝas dum la eniro, do eltiraĵo dum serĉado havas nenion plu por trovi.
Redaktado dum indeksado kaj kampa eltiraĵo dum serĉado solvas malsamajn problemojn. Redaktado limigas, kiu entute povas vidi la valoron; eltiraĵo nur decidas, kiun nomon la informpeto uzas. Haketado estas meza opcio, kiu konservas korelacion, sed stabila haketaĵo super malgranda uzantnoma spaco ankoraŭ identigas, kiam iu povas testi kandidatajn nomojn kontraŭ ĝi.
Se la konservita evento ankoraŭ enhavas la identecon, la problemo estas pli malsupre: fonta tipo, linio-rompado, traktado de disigiloj, kampaj alinomoj aŭ la informpeto mem. Tiuj estas ordinaraj analizaj riparoj kaj ili ne tuŝas la privatecan limon.
Elektu la riparon, kiu kongruas kun la limo
Tri kondiĉoj decidas la respondon. Unue, ĉu la privateca politiko intencas ekskludi la identecon? Due, ĉu la revizia aŭ esplora procezo bezonas la identecon, pseŭdonimon aŭ nur la sesion? Trie, ĉe kiu limo la valoro necesas — kolektado, konservado aŭ prezentado?
Se la politiko intencas ekskludon, ŝanĝu la postulon aŭ la prezentadon, ne la kontrolon. Se la politiko permesas la identecon sed kolektado perdas ĝin, riparu la kolektanton kaj konfirmu la krudan eventon. Se la konservado estas sendifekta, riparu la eltiraĵon kaj testu ĝin kontraŭ la aprobita evento, kiun vi kaptis komence.
Fermu la esploron nomante la limon en la ŝanĝa registro: kaŝita ĉe la fonto, forigita dum eniro aŭ pretervidita de eltiraĵo. Tiu unu frazo diras al la sekva inĝeniero, kie unue rigardi, kaj ĝi malhelpas, ke plendo pri la panelo fariĝu silente malŝaltita privateca funkcio.