Miért az Excel a legkockázatosabb dokumentumtípusa?
Az üzleti környezetben személyes adatokat felhalmozó összes dokumentumtípus közül a táblázatok a GDPR-megfelelőség szempontjából az egyik legveszélyesebbek.
Nem azért, mert ezek a legsúlyosabb egyedi kockázatot jelentenek — a kórházi nyilvántartások és a jogi dokumentumok egyértelműen magasabb kockázatot jelentenek az egyes érintettekre nézve. Hanem azért, mert az Excel-táblázatoknak olyan jellemzői vannak, amelyek szisztematikusan alulkezelt hellyé teszik őket a megfelelőségi folyamatok számára:
Mennyiség és kiterjedés: Egyetlen XLSX-fájl 50 000 sort és 100 oszlopot tartalmazhat. Minden cella potenciális személyes adathely. Egyetlen manuális felülvizsgálati folyamat sem méretezhető megbízhatóan erre a mennyiségre.
Szerkezeti sokféleség: A szöveges dokumentumoktól (szekvenciális) és a PDF-ektől (oldalalapú) eltérően az Excelnek kétdimenziós szerkezete van, amelyben a kontextus vízszintesen (oszlopfejlécek) és függőlegesen (sorviszonyok) van elosztva. A személyes adatok bárhol megjelenhetnek.
Üzletileg kritikus, nem személyes adatok keverve személyes adatokkal: Fizetési adatok, teljesítménypontszámok, részlegkódok és más jogos üzleti adatok egyazon táblázatban léteznek a TAJ-számokkal és e-mail-címekkel. Az indiszkriminatív anonimizálás, amely homályossá teszi a nem személyes adatokat is, használhatatlanná teszi a táblázatot.
Hosszú megőrzés felülvizsgálat nélkül: Az Excelben tárolt ügyféladatbázisok, munkavállalói nyilvántartások és szállítói listák évek alatt gyűlnek fel, és gyakran GDPR-felülvizsgálat nélkül tárolják azokat. A GDPR tároláskorlátozási elve (5. cikk (1) bekezdés e) pont) megköveteli, hogy az adatokat „nem hosszabb ideig” tárolják, „mint ami szükséges” — de a „talán hasznos lehet” táblázatok hajlamosak határozatlan ideig megmaradni.
A táblázatos személyes adatok felismerésének műszaki kihívásai
A szokásos szövegelemzési megközelítések kiszámítható módon vallanak kudarcot táblázatokon:
A TAJ-szám mint szám probléma
Az Excelbe kötőjel nélkül (123456789) bevitt TAJ-számokat az Excel számként tárolja, nem szövegként. Az „###-##-####” mintát kereső szövegelemzés ezeket kihagyja. A formátumtudatos felismerésnek fel kell ismernie, hogy egy „TAJ” feliratú oszlopban lévő 9 jegyű szám TAJ-szám kötőjelek nélkül is.
A dátum mint szám probléma
Az Excel belső formátumban sorszámokként tárolja a dátumokat (1900. január 1. = 1; 2024. február 6. = 45329). A „2024.02.06.” megjelenítési értékkel rendelkező cella „45329”-ként tárolódik. Az Excelből exportált CSV elemzésekor a „Születési dátum” oszlopban „45329” szerepelhet — egy szám, nem egy dátum. A kontextustudatos felismerésnek kezelnie kell ezt az átalakítást.
A részleges TAJ-szám probléma
Egyes megfelelőségi munkafolyamatok a TAJ-számokat csak az utolsó négy jeggyel tárolják az operatív felhasználáshoz (*--1234). A teljes TAJ-szám egy külön, jogosult felhasználók számára hozzáférhető zárolt oszlopban tárolódik. A részleges érték anonimizálása kötelező, még akkor is, ha az nem egyezik meg a teljes TAJ-minta formátumával.
A számított személyes adatok problémája
Egyes cellák más cellákból személyes adatokat előállító képleteket tartalmaznak. A =ÖSSZEFŰZ(B2," ",C2) képletű cella teljes nevet állíthat elő a kereszt- és vezetéknév-oszlopokból. A kereszt- és vezetéknév-oszlopok (B és C) anonimizálása helyes; az összefűzési cellát is frissíteni kell. Azok az eszközök, amelyek a cellaértékeket a képlethivatkozások figyelembevétele nélkül elemzik, olyan táblázatokat állíthatnak elő, ahol a személyes adatok megjelennek a képleteredményekben még az adatforrás cellák anonimizálása után is.
A több munkalapos következetesség problémája
Egy nagy Excel-munkafüzetnek lehet 5 munkalapja: „Ügyféllista”, „Rendelések”, „Támogatási jegyek”, „Számlázás”, „Elemzés”. Az ügyfelei nevei mind az öt munkalapon szerepelnek. A következetes anonimizáláshoz az szükséges, hogy ugyanaz az ügyfél ugyanazt az anonimizálási tokent kapja az összes munkalapon — hogy „Kiss János” az Ügyféllistán és „Kiss János” a Támogatási jegyekben mindkettő „PERSON_0047” legyen következetesen, ne két különböző token, amely megtöri a rekordkapcsolatot.
Az oszlopkontextus mint felismerési jelzés
A táblázatspecifikus személyes adat-felismerés legjobb javítása az oszlopfejléc kontextusának elemzése.
Az elv: a „TAJ” vagy „Társadalombiztosítási szám” feliratú oszlop jelzést ad a felismerő motornak, hogy az adott oszlop összes értékét TAJ-számként kell kezelni, még akkor is, ha az egyes értékek részlegesek, másképp formázottak vagy számként tárolódnak.
A felismerési pontosságot javító oszlopkontextus-jelzések:
| Oszlopfejléc | Felismerési jelzés |
|---|---|
| TAJ / Társadalombiztosítási szám / Adóazonosító | TAJ-kontextus — a 9 jegyű számok TAJ-számként kezelendők |
| E-mail / E-mail-cím | E-mail-kontextus — részleges minták esetén is érvényesít |
| Telefon / Telefonszám / Mobil | Telefonkontextus — különböző formázásokat fogad el |
| Születési dátum / Születésnap | Dátumkontextus — sorszámokat dátumokká alakít |
| Keresztnév / Vezetéknév / Teljes név | Névkontextus — csökkenti az NER-felismerés küszöbét |
| Cím / Utca / Város / Irányítószám | Cím-kontextus — összevonja a földrajzi mezőket |
| Páciens azonosítója / Kórlapszám | Egészségügyi azonosítókontextus — intézményspecifikus minták |
Az oszlopkontextus-elemzés nem helyettesíti a tartalmi elemzést — kiegészíti azt. A „TAJ” feliratú, 100 értéket tartalmazó oszlop tartalmi elemzéssel felismeri a 99 jól formázott TAJ-számot; az oszlopkontextus segít felismerni az 1 rosszul formázott vagy részleges értéket.
A megőrzési követelmény: személyes adatok anonimizálása, szerkezet megtartása
A legtöbb Excel GDPR-forgatókönyv megfelelőségi célja nem a táblázat megsemmisítése — hanem a személyes azonosítók eltávolítása, miközben megmarad az a adatszerkezet, amely a táblázatot hasznossá teszi.
Egy 15 000 soros munkavállalói nyilvántartási táblázat esetén a GDPR-megfelelőségi tisztviselőnek a következőkre van szüksége:
Anonimizálandó:
- Munkavállalói nevek → PERSON_XXXX tokenek
- TAJ-számok → REDACTED
- E-mail-címek → REDACTED
- Telefonszámok → REDACTED
- Lakcímek → REDACTED
Megőrzendő:
- Részlegkódok (nem személyes azonosítók)
- Beosztások (általános szerepek, nem egyedileg azonosítók)
- Fizetési sávok (egyes implementációkban összesített kategóriák, nem konkrét összegek)
- Teljesítménypontszámok (statisztikai adatok)
- Belépési dátumok (munkaviszony-időtartam elemzéséhez az egyének azonosítása nélkül)
- Vezető kódok (ha a vezetőket következetesen pszeudoanonimizálják)
Az a eszköz, amely fenntartja az „egyéneket azonosító dolgok” és az „alkalmazási mintákat leíró dolgok” megkülönböztetését, olyan táblázatot állít elő, amely a HR-elemzési célra hasznos marad, miközben teljesíti az adatminimalizálási és pszeudoanonimizálási követelményeket.
Felhasználási eset: M&A HR adatátadás
Egy felvásárló vállalat az átvett vállalat munkavállalói nyilvántartásait kapja meg: 15 000 soros XLSX, 40 oszloppal. Az adatokat meg kell osztani egy külső HR-tanácsadóval juttatási integráció tervezéséhez. A GDPR megköveteli, hogy csak a juttatástervezéshez szükséges adatokat osszák meg — fizetési sávok, részlegkódok, munkaviszony-időtartam, beosztási fokozatok — nem az azonosítási adatokat.
Anonimizálás előtt: 40 oszlop × 15 000 sor, beleértve a teljes neveket, TAJ-számokat, e-mail-címeket, lakcímeket, vészhelyzeti kapcsolattartókat és bankszámlaszámokat a bérszámfejtéshez.
Feldolgozás oszlopkontextus-alapú felismeréssel:
- 12 közvetlenül azonosító oszlop (nevek, TAJ-számok, e-mailek, telefonok, cím, bankszámla): cellánkénti helyettesítés következetes tokenekkel
- 3 közvetetten azonosító oszlop (munkavállalói azonosító, vezető kódja, egyedi beosztáskód): pszeudoanonimizált tokenekkel helyettesítve (a fájlon belül következetes, külső nyilvántartásokhoz nem keresztbe hivatkozható)
- 25 nem azonosító statisztikai adatoszlop (fizetési sáv, részleg, munkaviszony-időtartam, fokozat): változatlanul megőrizve
Feldolgozási idő: 8 perc 600 000 cellához Kimenet: XLSX eredeti formátumban, 40 oszlop sértetlen, 15 oszlop anonimizálva/pszeudoanonimizálva, 25 oszlop változatlan Auditjelentés: Cellaszintű napló az összes 200 000+ anonimizálási műveletről entitástípussal, megbízhatósággal és alkalmazott oszlopkontextus-jelzéssel
A HR-tanácsadónak: a juttatástervezéshez teljes adatkészlet, azonosítási adatok nélkül. A GDPR-megfelelőségi nyilvántartáshoz: auditjelentés, amely bemutatja a célkorlátozást — csak az adott feladathoz szükséges adatokat osztották meg.
A GDPR 5. cikk szerinti követelmények teljesítése strukturált anonimizálással
A táblázatspecifikus anonimizálás egyszerre teljesíti az 5. cikk három elvét:
Adatminimalizálás (5. cikk (1) bek. c) pont): Csak az adott célhoz szükséges oszlopokat osztják meg; az azonosító oszlopokat kianonimizálják.
Tároláskorlátozás (5. cikk (1) bek. e) pont): Az eredeti fájlokat (azonosító adatokkal) a jogszabályi megőrzési időszakokra megtartják; anonimizált verziókat hoznak létre rövidebb vagy semmilyen megőrzési követelményű megosztási kontextusokhoz.
Integritás és bizalmasság (5. cikk (1) bek. f) pont): Az azonosítási adatokat eltávolítják az összes megosztási példányból; csak anonimizált verziók hagyják el az ellenőrzött környezetet.
Az anonimizálási folyamat auditnyomvonala biztosítja az 5. cikk (2) bekezdése szerinti elszámoltathatósági dokumentációt — minden feldolgozott táblázatnál bemutatva az egyes elveknek való megfelelést.
Források: