Защо Excel е вашият файл с най-висок риск
Excel файловете са един от най-големите GDPR рискове в повечето бизнеси. Медицинските досиета могат да съдържат по-чувствителни данни на ред. Но таблиците натрупват PII бързо -- и екипите по съответствие често ги пропускат.
Три неща правят Excel файловете трудни за управление.
Обем: Един XLSX файл може да съдържа 50 000 реда и 100 колони. Това са пет милиона клетки. Никакъв ръчен преглед не може да провери всички тях.
Решетъчно оформление: Текстът тече в една посока. Excel разпределя данните по редове и колони. Личните данни могат да се скрият навсякъде в тази решетка.
Смесено съдържание: Диапазони на заплатите, кодове на отдели и нива на длъжности се намират в същия файл заедно с SSN и имейл адреси. Изтриването на всичко прави файла безполезен.
Дълго задържане: Списъците на персонала и записите на клиентите остават в Excel с години. Член 5(1)(e) от GDPR гласи, че данните трябва да се съхраняват "не по-дълго от необходимото". Файловете, "които може да са полезни", често остават далеч след тази точка.
Защо стандартното сканиране на текст се проваля при таблици
Инструментите за текстов анализ са изградени за документи. Те се провалят при таблици по няколко общи начина.
Проблемът с SSN-като-число
Excel записва номерата на социална осигуровка без тирета (123456789) като обикновени числа -- не текст. Скенер, изграден за намиране на ###-##-####, ще ги пропусне. Добрият инструмент трябва да знае, че 9-цифрено число в колона, наречена "SSN", е номер на социална осигуровка.
Проблемът с датата-като-число
Excel съхранява датите като серийни числа. 6 февруари 2024 г. се съхранява като 45329. CSV експортът ще покаже "45329" в колона "Дата на раждане". Скенерът трябва да преобразува това число в реална дата, преди да може да маркира стойността.
Проблемът с частичния SSN
Някои системи показват само последните четири цифри на SSN (*--1234). Пълният номер се намира в заключена колона. Частичната стойност все още трябва да бъде анонимизирана -- дори ако не изглежда като пълен SSN.
Проблемът с PII от формула
Някои клетки изграждат PII от други клетки. Клетка с =CONCATENATE(B2," ",C2) показва пълно име. Ако изчистите колони B и C, това пълно име все още е видимо в клетката с формула. Инструмент, който чете само съхранени стойности -- не връзки от формули -- ще остави PII на място.
Проблемът с многолистовата книга
Голяма работна книга може да има пет листа: Списък с клиенти, Поръчки, Заявки за поддръжка, Фактуриране и Анализи. Имената на клиентите се появяват и в петте. "John Smith" в един лист трябва да стане същия токен -- "PERSON_0047" -- в останалите листа. Два различни токена нарушават връзките на записите.
Заглавките на колоните като сигнал
Най-голямото подобрение при засичане на PII в таблици е анализът на заглавките на колоните.
Колона, наречена "SSN", казва на инструмента, че всички стойности в тази колона са номера на социална осигуровка. Това работи дори ако стойностите са частични, необичайно форматирани или съхранени като числа.
| Заглавка на колоната | Какво сигнализира |
|---|---|
| SSN / Social Security / Tax ID | Третирайте 9-цифрените числа като SSN |
| Email / E-mail / Email Address | Маркирайте дори частични имейл образци |
| Phone / Telephone / Mobile / Cell | Приемете всеки телефонен формат |
| DOB / Date of Birth / Birthday | Преобразувайте серийните числа в дати |
| First Name / Last Name / Full Name | Намалете прага за засичане на имена |
| Address / Street / City / ZIP | Комбинирайте близки полета за местоположение |
| Patient ID / MRN / Record Number | Приложете образци за здравни идентификатори |
Контекстът на колоната не замества сканирането на съдържанието. Той го допълва. Колона, наречена "SSN" с 99 добре форматирани стойности: сканирането на съдържанието ги улавя. Контекстът на колоната улавя тази, която изглежда необичайно.
Запазете структурата, премахнете имената
Целта в повечето Excel GDPR случаи не е да унищожите файла. Тя е да изчистите личните данни, като запазите частите, които правят файла полезен.
За файл с 15 000 реда на служителски записи, служителят по съответствие се нуждае от:
Премахване:
- Имена на служители --> токени PERSON_XXXX
- SSN --> REDACTED
- Имейл адреси --> REDACTED
- Телефонни номера --> REDACTED
- Домашни адреси --> REDACTED
Запазване:
- Кодове на отдели
- Длъжности (само общи роли)
- Диапазони на заплатите (широки категории)
- Оценки за изпълнение (групови данни)
- Начални дати (за статистика за стаж)
- Кодове на мениджъри (ако са псевдонимизирани)
Инструмент, който знае разликата между "данни, идентифициращи хора" и "данни, описващи работни места", ви дава файл, който все още работи за HR анализ -- и отговаря на правилата за минимизиране на данните по GDPR.
Реален случай: Прехвърляне на HR данни при M&A
Придобиваща компания получава служителски записи от придобитата фирма: XLSX файл с 15 000 реда и 40 колони. Файлът трябва да отиде при外部 HR фирма за планиране на обезщетения. GDPR гласи, че само данните, необходими за тази задача, могат да бъдат споделени.
Преди обработката: 40 колони с пълни имена, SSN, имейли, домашни адреси, лица за спешен контакт и банкови данни.
След обработката с контекст на колони:
- 12 колони директно идентифицират хора (имена, SSN, имейли, телефон, адреси, банкови данни): заменени с последователни токени
- 3 колони косвено идентифицират хора (ID на служител, код на мениджър, код на длъжност): заменени с псевдонимни токени, съвпадащи в рамките на файла
- 25 колони са обобщени данни (диапазон на заплата, отдел, стаж, ниво): оставени непроменени
Време: 8 минути за 600 000 клетки
Резултат: Същото XLSX оформление, 40 колони, 15 анонимизирани, 25 непроменени
Одитен журнал: Запис на ниво клетка за всяко действие с тип обект, оценка за увереност и използван сигнал за колона
HR фирмата получава пълен набор от данни за работата си -- без имена или идентификатори. Записът за съответствие получава доказателство, че са споделени само правилните данни.
Това предизвикателство не е уникално за Excel. Всеки файлов формат се проваля по свой начин. Вижте как фрагментацията на формати влияе на засичането на PII за поглед върху различните типове файлове.
Три правила от член 5 на GDPR, един процес
Структурираната анонимизация на таблици отговаря на три правила наведнъж.
Минимизиране на данните (чл. 5(1)(в)): Само колоните, необходими за задачата, отиват при получателя. Идентифициращите колони се изчистват.
Ограничаване на съхранението (чл. 5(1)(д)): Оригиналният файл остава за правно задържане. Чисто копие се прави за споделяне -- с по-кратка или без нужда от задържане.
Цялост и поверителност (чл. 5(1)(е)): Никакви идентифициращи данни не напускат контролната зона. Споделят се само чисти копия.
Одитният журнал от процеса е и вашето доказателство по член 5(2). Той показва как е спазено всяко правило за всеки файл.
Ако вашият екип обработва DSAR или голям обем от износ на данни, същата логика се прилага на API ниво. Вижте как минимизирането на данните по GDPR работи в API в реално време.
За екипи, работещи с голям обем при кратки срокове, вижте групова обработка на GDPR DSAR в мащаб за работни модели, приложими и тук.