Kde mizí uživatelské jméno VPN z pipeline protokolů?
Porovnejte událost brány, surovou kopii sběrače, indexovanou událost a pole při hledání, než změníte nastavení soukromí protokolů.
Relace se na panelu zobrazují, zatímco sloupec s uživatelským jménem zůstává prázdný, a prvním impulsem je vinit parser. Ten impuls přeskakuje tři dřívější fáze, ve kterých se hodnota mohla ztratit. Brána může identitu maskovat podle zásad, pravidlo příjmu ji může smazat před indexací a extrakce při hledání ji může prostě nenazvat. Oprava závisí na tom, kterou hranici dokážete prokázat jako odpovědnou, takže užitečná práce je srovnávání, ne konfigurace.
Začněte u jedné události, ne u panelu
Vyberte jednu událost ověření a zapište, co ji identifikuje: model a verzi brány, metodu ověření, identifikátor události, časové razítko a zdrojovou adresu. Přidejte uživatelské jméno přesně tak, jak ho člověk napsal, včetně velikosti písmen, protože hledání citlivé na velikost písmen může skrýt pole, které existuje. Berte tuto událost jako referenci pro každé další srovnání.
Typy událostí nesdílejí stejné schéma. Neúspěšný pokus, úspěšné přihlášení bez klienta a opětovné připojení tunelu mohou dávat různá pole a některé brány identitu vynechávají, když se pokus nedostal k ověření uživatele. Prázdný sloupec u jednoho typu události je proto slabým důkazem problému v pipeline.
Pracujte se schválenou testovací identitou místo skutečného účtu zaměstnance a držte srovnání v mezích přístupových pravidel, která už data protokolů řídí. Široké zapnutí podrobného protokolování ověřování jen kvůli vzorku mění systém, který se snažíte měřit.
Porovnejte čtyři hranice popořadě
Hodnota může zmizet v jednom ze čtyř bodů. Každý bod má jiného vlastníka a jinou opravu.
| 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 |
Zastavte se u první hranice, kde hodnota mizí. Nesoulad mezi pohledem zařízení a surovou kopií ukazuje na přenos nebo konfiguraci sběrače; shoda tam, ale chybějící hodnota v indexované události ukazuje na transformaci; hodnota přítomná v indexované události, ale chybějící na panelu, ukazuje na extrakci nebo dotaz.
Toto pořadí je důležité, protože každá další fáze může jen ztrácet informace a nikdy je neobnoví. Regulární výraz nemůže vrátit řetězec, který dřívější fáze nahradila zástupným znakem, a nastavení soukromí nemůže vysvětlit hodnotu, která nebyla nikdy odeslána.
Maskování u zdroje je zásada, ne chyba parseru
Dokumentace k protokolování ASA od Cisco popisuje skrývání uživatelského jména jako konfigurovatelné chování, včetně toho, jak se zobrazují neplatná nebo neznámá uživatelská jména. Maskovaná identita ve zdrojové události tak může být přesně to, co zásady soukromí vyžadují, a její pojetí jako chyby parsování vede k požadavku, který kontrolu oslabuje.
Přesná podoba závisí na verzi a typu zprávy. Jedna událost může nést zástupný znak, jiná může pole úplně vynechat a neúspěch ověření nemusí nikdy obsahovat jméno. Ověřte dokumentované chování pro konkrétní událost, místo abyste na každou chybějící identitu aplikovali starou zprávu o chybě.
Když je maskování záměrné, otázka se mění z toho, jak pole obnovit, na to, zda lze požadavek auditu splnit jinak. Identifikátory relace, řízené mapování identit držené menší skupinou nebo užší autorizovaný tok událostí často potřebu splní, aniž by každé zkoušené uživatelské jméno vystavily každému čtenáři protokolů.
Anonymizaci před indexací nelze vrátit
Dokumentace Splunku k zpracování událostí popisuje anonymizaci pomocí výrazů sed a transformací, které přepisují nebo odstraňují data před indexací. Právě to umístění je podstatné: surová událost se mění na vstupu, takže extrakce při hledání nemá co najít.
Redakce při indexaci a extrakce polí při hledání řeší různé problémy. Redakce omezuje, kdo hodnotu vůbec může vidět; extrakce jen rozhoduje, které jméno dotaz použije. Hašování je střední možnost, která zachovává korelaci, ale stabilní haš nad malým prostorem uživatelských jmen přesto identifikuje, když proti němu někdo může zkoušet kandidátní jména.
Pokud uložená událost stále obsahuje identitu, problém je níž: typ zdroje, dělení řádků, zpracování oddělovačů, aliasy polí nebo samotný dotaz. To jsou běžné opravy parsování a nedotýkají se hranice soukromí.
Vyberte opravu, která odpovídá hranici
Odpověď určují tři podmínky. Za prvé, chce zásada soukromí identitu vyloučit? Za druhé, potřebuje proces auditu nebo vyšetřování identitu, pseudonym, nebo jen relaci? Za třetí, na které hranici je hodnota potřeba — sběr, uložení, nebo prezentace?
Pokud zásada chce vyloučení, změňte požadavek nebo prezentaci, ne kontrolu. Pokud zásada identitu povoluje, ale sběr ji ztrácí, opravte sběrač a potvrďte surovou událost. Pokud je uložení neporušené, opravte extrakci a otestujte ji proti schválené události, kterou jste zachytili na začátku.
Vyšetřování uzavřete pojmenováním hranice v záznamu o změně: maskováno u zdroje, odstraněno při příjmu, nebo minuto extrakcí. Ta jediná věta řekne dalšímu inženýrovi, kam se podívat nejdřív, a zabrání tomu, aby se stížnost na panel proměnila v tiše vypnutou funkci soukromí.