Mihin VPN-käyttäjänimi katoaa lokien putkesta?
Vertaa yhdyskäytävän tapahtumaa, kerääjän raakaa kopiota, indeksoitua tapahtumaa ja hakuaikaista kenttää ennen kuin muutat lokien tietosuoja-asetusta.
Istunnot näkyvät koontinäytöllä, kun taas käyttäjänimen sarake pysyy tyhjänä, ja ensimmäinen vaisto on syyttää jäsentäjää. Tämä vaisto ohittaa kolme aiempaa vaihetta, joissa arvo on voinut kadota. Yhdyskäytävä voi peittää identiteetin käytännön mukaan, sisäänotto sääntö voi poistaa sen ennen indeksointia, ja hakuaikainen poiminta voi yksinkertaisesti jättää nimeämättä sen. Korjaus riippuu siitä, minkä rajan voit todistaa vastuulliseksi, joten hyödyllinen työ on vertailu eikä määritys.
Aloita yhdestä tapahtumasta, älä koontinäytöstä
Valitse yksi todentamistapahtuma ja kirjoita muistiin, mikä sen tunnistaa: yhdyskäytävän malli ja versio, todentamismenetelmä, tapahtumatunniste, aikaleima ja lähdeosoite. Lisää käyttäjänimi täsmälleen niin kuin henkilö kirjoitti sen, myös kirjainkoko, koska kirjainkoosta riippuva haku voi piilottaa kentän, joka on olemassa. Pidä tätä tapahtumaa viitteenä jokaiselle myöhemmälle vertailulle.
Tapahtumatyypit eivät jaa samaa skeemaa. Epäonnistunut yritys, onnistunut kirjautuminen ilman asiakasta ja tunnelin uudelleenyhdistäminen voivat tuottaa eri kentät, ja jotkin yhdyskäytävät jättävät identiteetin pois, kun yritys ei koskaan saavuttanut käyttäjän todentamista. Tyhjä sarake yhdessä tapahtumatyypissä on siis heikko todiste putken ongelmasta.
Työskentele hyväksytyllä testi-identiteetillä todellisen työntekijätilin sijaan ja pidä vertailu niiden käyttöoikeussääntöjen sisällä, jotka jo hallitsevat lokitietoja. Yksityiskohtaisen todentamislokituksen laaja käyttöönotto pelkän näytteen saamiseksi muuttaa järjestelmää, jota yrität mitata.
Vertaa neljää rajaa järjestyksessä
Arvo voi kadota yhdessä neljästä kohdasta. Jokaisella kohdalla on eri omistaja ja eri korjaus.
| 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 |
Pysähdy ensimmäisellä rajalla, jolla arvo katoaa. Laitteen näkymän ja raa'an kopion välinen ero viittaa siirtoon tai kerääjän määritykseen; yhtäläisyys siellä mutta puuttuva arvo indeksoidussa tapahtumassa viittaa muunnokseen; indeksoidussa tapahtumassa oleva mutta koontinäytöltä puuttuva arvo viittaa poimintaan tai kyselyyn.
Tämä järjestys on tärkeä, koska jokainen myöhempi vaihe voi vain menettää tietoa, ei koskaan palauttaa sitä. Säännöllinen lauseke ei voi palauttaa merkkijonoa, jonka aiempi vaihe korvasi paikkamerkillä, eikä tietosuoja-asetus voi selittää arvoa, jota ei koskaan lähetetty.
Peittäminen lähteessä on käytäntö, ei jäsentäjän virhe
Ciscon ASA-lokituksen dokumentaatio kuvaa käyttäjänimen piilottamisen määritettävissä olevana toimintana, mukaan lukien sen, miten virheelliset tai tuntemattomat käyttäjänimet esitetään. Lähteen tapahtumassa peitetty identiteetti voi siis olla täsmälleen se, mitä tietosuojakäytäntö vaatii, ja sen käsitteleminen jäsennyksen epäonnistumisena johtaa pyyntöön, joka heikentää valvontaa.
Tarkka esitys riippuu versiosta ja viestityypistä. Yksi tapahtuma voi sisältää paikkamerkin, toinen voi jättää kentän kokonaan pois, eikä todentamisvirhe välttämättä sisällä nimeä koskaan. Tarkista kyseisen tapahtuman dokumentoitu toiminta sen sijaan, että soveltaisit vanhaa virheraporttia jokaiseen puuttuvaan identiteettiin.
Kun peittäminen on tahallista, kysymys muuttuu siitä, miten kenttä palautetaan, siihen, voidaanko auditointivaatimus täyttää toisella tavalla. Istuntotunnisteet, pienemmän ryhmän hallussa oleva valvottu identiteettikartta tai kapeampi valtuutettu tapahtumavirta tyydyttävät usein tarpeen asettamatta jokaista yritettyä käyttäjänimeä jokaisen lokin lukijan eteen.
Ennen indeksointia tehtyä anonymisointia ei voi peruuttaa
Splunkin tapahtumankäsittelyn dokumentaatio kuvaa anonymisointia sed-lausekkeilla ja muunnoksilla, jotka kirjoittavat tiedot uudelleen tai poistavat ne ennen indeksointia. Juuri sijainti on pointti: raakaa tapahtumaa muutetaan sisään tullessa, joten hakuaikaisella poiminnalla ei ole enää mitään löydettävää.
Indeksointiaikainen poisto ja hakuaikainen kenttien poiminta ratkaisevat eri ongelmia. Poisto rajoittaa, kuka voi ylipäätään nähdä arvon; poiminta päättää vain, mitä nimeä kysely käyttää. Tiivistys on keskitie, joka säilyttää korrelaation, mutta vakaa tiiviste pienen käyttäjänimiavaruuden yli on silti tunnistava, kun joku voi testata ehdokasnimiä sitä vastaan.
Jos tallennettu tapahtuma sisältää yhä identiteetin, ongelma on alavirrassa: lähdetyyppi, rivien katkaisu, erottimien käsittely, kenttien aliakset tai itse kysely. Ne ovat tavallisia jäsennyksen korjauksia eivätkä ne kosketa tietosuojan rajaa.
Valitse korjaus, joka vastaa rajaa
Vastauksen ratkaisee kolme ehtoa. Ensinnäkin, aikooko tietosuojakäytäntö sulkea identiteetin pois? Toiseksi, tarvitseeko auditointi- tai tutkintaprosessi identiteetin, salanimen vai vain istunnon? Kolmanneksi, millä rajalla arvoa tarvitaan — keruu, tallennus vai esitys?
Jos käytäntö aikoo sulkea pois, muuta vaatimusta tai esitystä, älä valvontaa. Jos käytäntö sallii identiteetin mutta keruu pudottaa sen, korjaa kerääjä ja vahvista raaka tapahtuma. Jos tallennus on ehjä, korjaa poiminta ja testaa se hyväksyttyä tapahtumaa vasten, jonka tallensit alussa.
Sulje tutkinta nimeämällä raja muutoskirjaukseen: lähteessä peitetty, sisäänotossa poistettu tai poiminnan ohittama. Se yksi lause kertoo seuraavalle insinöörille, mistä katsoa ensin, ja estää koontinäytön valituksen muuttumisen hiljaa poistetuksi tietosuojaominaisuudeksi.