Azure Data Collection Rules: Ingestion-time PII maskování v Log Analytics

V Christie's jsme měli klasický problém: aplikační logy obsahovaly e-maily klientů, telefonní čísla a občas i hodnoty draženého zboží. Vše tohle se dostávalo do Log Analytics workspace, kam má read přístup celý platform tým – tedy lidé, kteří nemají legitimní důvod vidět konkrétní PII. SOC zákazníka si toho všiml během compliance auditu a deadline na nápravu byl konec ledna.

Klasické řešení by bylo „upravte aplikaci, aby tohle nelogovala". V realitě? Třicet legacy aplikací, šest týmů, šest priorit – takže odpověď byla ingestion-time transformace přes Data Collection Rules.

Architektura: kde DCR sedí v pipeline

[Aplikace] → [AMA / Logs Ingestion API] → [DCR transformace] → [Log Analytics tabulka]
                                                ↑
                                       Tady maskujeme PII

Klíčové vlastnosti, kvůli kterým jsme DCR vybrali místo logstash/splunk forwarderu:

• Nativní v Azure – žádný další serverový komponent k údržbě
• Per-tabulkové scope – jiná pravidla pro AppTraces a jiná pro AppExceptions
• Audit DCR změn přes Azure Activity Log – kdokoliv změní transformaci, je to vidět
• Bez dopadu na schéma – transformace běží před zápisem, schema tabulky zůstává stabilní

Příklad 1: maskování e-mailových adres

První pravidlo, které jsme nasadili, bylo nejjednodušší. Najít e-mail v Message sloupci a nahradit lokální část hvězdičkami.

source
| extend Message = replace(
    @'([a-zA-Z0-9._%+-]+)(@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,})',
    @'***\2',
    Message
  )

Pozor: v DCR transformacích není dostupný replace_regex(). Musíte použít replace(), který v DCR variantě regex přijímá (na rozdíl od některých dokumentací). Toto byla nejnepříjemnější část onboardingu – KQL v DCR a v běžných queries se chová jinak.

Po nasazení vypadá v Log Analytics e-mail martin.rylko@example.com jako ***@example.com. Doména zůstane pro debug, lokální část je pryč. Pro forensní účely máme paralelní pipeline (viz sekce 6).

Příklad 2: kompletní vymazání čísel karet

Pro PCI data nejde o maskování, ale o úplné odstranění. Zde používáme prázdnou náhradu:

source
| extend Message = replace(
    @'\b(?:\d[ -]*?){13,19}\b',
    '[CARD_REDACTED]',
    Message
  )

Regex pokrývá 13–19místné sekvence číslic s volitelnými mezerami/pomlčkami, což chytá Visa, Mastercard, AMEX i divočejší formáty.

Příklad 3: pojmenované entity z aplikační vrstvy

Některá data si aplikace logují strukturovaně – třeba clientId=CL-12345. Pro tyhle si můžeme dovolit hashovat místo maskovat, abychom zachovali možnost agregace:

source
| extend ClientHash = case(
    Message has 'clientId=',
    hash_sha256(extract(@'clientId=([A-Z0-9-]+)', 1, Message)),
    ''
  )
| extend Message = replace(@'clientId=[A-Z0-9-]+', 'clientId=[HASHED]', Message)
| project-away ClientHash

Trik je v case() – pokud řádek nemá clientId=, hash se nepočítá vůbec. To dramaticky snižuje CPU overhead na agentovi.

Nasazení DCR přes Bicep

Manuální tvorba přes Portal je dobrá pro první lab. Pro produkci jdeme Bicepem:

resource dcr 'Microsoft.Insights/dataCollectionRules@2023-03-11' = {
  name: 'dcr-pii-masking-prod'
  location: location
  kind: 'Direct'
  properties: {
    streamDeclarations: {
      'Custom-AppTraces': {
        columns: [
          { name: 'TimeGenerated', type: 'datetime' }
          { name: 'Message',       type: 'string'   }
          { name: 'SeverityLevel', type: 'int'      }
          { name: 'AppRoleName',   type: 'string'   }
        ]
      }
    }
    destinations: {
      logAnalytics: [
        {
          workspaceResourceId: workspaceId
          name: 'la-destination'
        }
      ]
    }
    dataFlows: [
      {
        streams: ['Custom-AppTraces']
        destinations: ['la-destination']
        transformKql: '''
          source
          | extend Message = replace(@'([a-zA-Z0-9._%+-]+)(@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,})', @'***\\2', Message)
          | extend Message = replace(@'\\b(?:\\d[ -]*?){13,19}\\b', '[CARD_REDACTED]', Message)
        '''
        outputStream: 'Microsoft-AppTraces'
      }
    ]
  }
}

Tři věci, na kterých jsme se v Christie's spálili a které stojí za zmínku:

1. outputStream musí odpovídat cílové tabulce – pro AppTraces je to Microsoft-AppTraces, ne custom název
2. Escaping backslashů v Bicepu – v multiline string literal ('''...''') musíte zdvojit zpětná lomítka, jinak Bicep parser regex rozbije
3. AMA potřebuje DCR association, ne přímé přiřazení – musíte separátně vytvořit Microsoft.Insights/dataCollectionRuleAssociations

Lab pattern: jak validovat transformaci před produkcí

Tohle je můj nejcennější tip. Microsoft poskytuje Invoke-AzOperationalInsightsQuery ekvivalent pro DCR transformace – DCR Sandbox v Azure Portal (Monitor → Data Collection Rules → vyberete DCR → Transformation editor → "Run").

Workflow:

1. Vezměte 50 reálných řádků produkčního logu (sanitized export)
2. Vložte do JSON formátu očekávaného streamem
3. Spusťte transformaci v editoru
4. Zkontrolujte, že žádný řádek nepropouští plné PII
5. Diff oproti baseline pro regression check

V Christie's jsme tohle pověsili na CI – PR na DCR Bicep souboru spouští unit test, který vezme fixture s 200 řádky a ověří absence regex matchů na originální PII vzory ve výstupu.

Compliance: co to vlastně řeší (a co ne)

Co DCR neřeší: pokud aplikace pošle do Application Insights TrackException s plným stack trace obsahujícím PII, transformace v AppExceptions musí explicitně pokrýt i OuterMessage a Details. Snadno se zapomene.

Závěr

DCR transformace jsou v lednu 2026 nejčistší cesta, jak v Azure Monitoru splnit „PII nikdy v plné podobě nedorazí do log storage" požadavek bez přepisování aplikací. Cena: 30–40 hodin engineering času na první rule sadu, +10 % CPU na agentech, +10 sekund ingest latence.

Hodnota: kompliance audit bez nálezů a klid SOC týmu, kterému už nehrozí, že ho někdo zavolá kvůli e-mailu v logu.

Pokud řešíte podobný problém s logováním PII a chcete DCR pattern nasadit do vlastního prostředí, podívejte se na naše služby cloudové architektury nebo se ozvěte pro lab walkthrough.