sql >> Databáze >  >> RDS >> Database

Jakou funkci maskování dat bych měl použít?

Podle Simsona L. Garfinkela z Laboratoře informačních technologií divize NIST Information Access Division,

Deidentifikace není jediná technika, ale soubor přístupů, algoritmů a nástrojů, které lze aplikovat na různé druhy dat s různou úrovní účinnosti. Obecně platí, že ochrana soukromí se zlepšuje, protože se používají agresivnější techniky deidentifikace, ale ve výsledné datové sadě zůstává méně užitečnosti.

-De-Identification of Personal Information, NISTIR 8053

Statické maskování dat (SDM) je průmyslově uznávaný termín pro tyto různé způsoby deidentifikace datových prvků v klidu. Prvky jsou typicky databázové sloupce nebo hodnoty polí s plochým souborem, které jsou považovány za citlivé; ve zdravotnictví jsou označovány jako klíčové identifikátory. Konkrétně jsou ohroženy osobní údaje (PII), chráněné zdravotní informace (PHI), primární čísla účtů (PAN), obchodní tajemství nebo jiné citlivé hodnoty.

Bezpečnostní produkt IRI FieldShield zaměřený na data „startpoint“ – nebo produkt IRI CoSort a platforma IRI Voracity, které zahrnují stejné funkce – poskytují více funkcí zjišťování dat a SDM pro více zdrojů dat. Dostupné funkce maskování pro jednotlivá pole/sloupce zahrnují:

  1. více šifrovacích (a dešifrovacích) algoritmů vyhovujících NSA Suite B a FIPS, včetně zachování formátu šifrování
  2. Hašování SHA-1 a SHA-2
  3. ASCII de-ID (bitové kódování)
  4. binární kódování a dekódování
  5. rozmazání dat nebo bucketing (anonymizace)
  6. náhodné generování nebo výběr
  7. redakce (zatemnění znaků)
  8. vratná a nevratná pseudonymizace
  9. logika vlastního výrazu (výpočet / náhodné přehrávání)
  10. podmíněné/částečné filtrování nebo odstranění (vynechání)
  11. náhrada vlastní hodnoty
  12. funkce posouvání bajtů a řetězců
  13. tokenizace (pro PCI)

Můžete také „natočit svou vlastní“ funkci maskování externích dat. To vám umožňuje za běhu volat vlastní napsanou rutinu na úrovni pole namísto vestavěné.

Otázkou zůstává, jakou maskovací funkci mám použít (u každé položky)? To závisí na vašich obchodních potřebách a pravidlech a také na platných zákonech o ochraně osobních údajů. Na technické úrovni to obvykle znamená rozhodnout, jak musí výsledný šifrovaný text (maskovaná data) vypadat, zda musí být reverzibilní nebo jedinečný, jak je bezpečný a případně jaké druhy výpočetních zdrojů a času jsou pro proces k dispozici. . Podívejme se podrobně na tato běžná rozhodovací kritéria:

Vzhled (realismus)

Měla by nově maskovaná data vypadat víceméně jako původní data? A co jeho velikost a formát? Pseudonymizace a šifrování se zachováním formátu jsou dva nejběžnější způsoby 

zachovat vzhled a dojem vlastních podstatných jmen a alfanumerických čísel účtu nebo telefonních čísel. Ale maskování podřetězců (a/k/a částečná redakce pole, např. XXX-XX-1234) může být v pořádku pro věci, jako jsou SSN. Zamyslete se nad stálostí a zobrazováním dat pro analýzy atd.

V souvislosti s tím může vzhled a realističnost šifrovaného textu také určovat použitelnost výsledků. Cíle aplikací a databázových tabulek (načítání) mohou vyžadovat, aby formát dat nejen vyhovoval předem definovaným strukturám, ale aby pokračoval v práci v dotazech nebo jiných provozních kontextech.

Jinými slovy, pokud jsou vyžadována maskovaná data, která jsou hezká a/nebo funkční data, nepouštějte se do úplné redakce, randomizace, hashování nebo přímého šifrování (které rozšiřuje a zatemňuje výsledky). Možná vám projdou menší úpravy, jako je stárnutí a manipulace podřetězců, ale zvažte dopad těchto voleb na vaše další rozhodovací kritéria…

Vratnost (re-identifikace)

Potřebujete obnovit původní data? Odpověď na to může záviset na tom, zda necháte zdrojová data na pokoji, jako byste to udělali u dynamického maskování dat, nebo když maskovaná data zapisujete do nových cílů. V těchto případech je odpověď ne.

Pokud je odpověď ne, možná stále potřebujete realismus. V těchto případech může být nevratná pseudonymizace vaší nejlepší volbou. Pokud ne a na vzhledu nezáleží, použijte úpravu postavy. A pokud ani jedno není pravda, zvažte přímé odstranění zdrojového sloupce z cíle.

Pokud je odpověď ano, zobrazí se funkce maskování dat IRI, jako je šifrování, reverzibilní pseudonymizace nebo tokenizace, kódování nebo ASCII re-ID (bitové kódování). V pokročilejších případech použití můžete také potřebovat diferenciální reverzaci; tj. když různí příjemci stejného cíle jsou oprávněni vidět různé věci ve stejném souboru dat. V takových případech lze nasadit soukromé šifrovací klíče, skripty úlohy odhalení specifické pro uživatele nebo dokonce vlastní aplikace.

Jedinečnost (konzistence)

Musí být stejná původní hodnota vždy nahrazena stejnou, ale jinou náhradní hodnotou? Budou data spojena nebo seskupena podle náhradních hodnot? Pokud ano, pak musí zvolený náhradní algoritmus poskytovat výsledky, které jsou jedinečné a opakovatelné, aby byla zachována referenční integrita navzdory maskování, ke kterému došlo.

Toho lze dosáhnout pomocí šifrování, když se stejný algoritmus a přístupová fráze (klíč) používají proti stejnému otevřenému textu. Průvodci klasifikací dat a ochranou mezi tabulkami v IRI Workbench IDE pro FieldShield, Voracity atd. to usnadňují pomocí křížové tabulky (nebo globálnější) aplikace přizpůsobeného maskovacího pravidla. Tímto způsobem získá stejná hodnota prostého textu vždy stejný výsledek v šifrovaném textu bez ohledu na jeho umístění.

Pseudonymizace je zde však složitější z důvodu nedostatku jedinečných náhradních jmen, duplicitních původních jmen a změn ( vloží, aktualizuje nebo odstraní) na původní hodnoty ve zdrojových tabulkách nebo souborech. IRI se v tomto příkladu pracovního postupu Voracity zabývalo problémem konzistentní pseudonymizace napříč tabulkami.

Síla (zabezpečení)

Pohled na algoritmy uvnitř každé funkce vám může pomoci určit jejich relativní „prolomitelnost“ a zhodnotit ji ve srovnání s ostatními aspekty šifrovaného textu, jako je vzhled a rychlost. Například funkce AES256 IRI je silnější než možnost AES128, SHA2 je silnější než SHA1 a všechny jsou silnější než funkce kódování/dekódování base64 a funkce ASCII de-ID/re-ID.

Podle definice jsou reverzibilní funkce obvykle slabší než ty, které nelze vrátit zpět. Například nevratná pseudonymizační metoda IRI (sada cizího vyhledávání) je bezpečnější než její reverzibilní (zakódovaná původní sada) pseudonymizační metoda. To znamená, že šifrovací algoritmus AES-256 může být velmi obtížné prolomit, když dojde ke ztrátě klíče.

Ještě silnější zabezpečení je samozřejmě opomenutí, po kterém následuje obfuskace (redakce), které jsou nevratné. Nevýhodou je ale nedostatečná použitelnost. V kontextu bezpečného přístavu HIPAA je odstranění klíčových identifikátorů v souladu. Pokud však potřebujete použít jakoukoli část zdrojových dat pro analýzu, výzkum, marketing nebo demonstraci, budete místo toho potřebovat maskovací funkci a odborníka, který určí (a potvrdí), že vaše technika (techniky) má nízkou statistickou hodnotu. pravděpodobnost opětovné identifikace.

Zatímco jsme u tématu deidentifikace HIPAA, pamatujte, že může existovat také riziko spojené s takzvanými kvazi identifikátory (jako je PSČ a věk). Tyto hodnoty lze použít ve spojení s jinými soubory dat k vytvoření reidentifikace, a proto je v mnoha případech také vhodné maskovat; zda a jak podléhají stejným úvahám.

Výpočet (výkon)

Jednou z pěkných věcí na přístupu k maskování dat – i když jsou zahrnuty výpočetně náročné šifrovací algoritmy – je to, že jeho režie ve vztahu k šifrování se širokým štětcem (celé sítě, databáze, souboru/systému, diskové jednotky) je mnohem nižší. Pouze ty datové prvky (hodnoty sloupců), které určíte pro ochranu, musí být přijaty, zpracovány a vráceny z maskovací funkce.

Obecně platí, že čím složitější (a silnější) algoritmus, tím déle bude trvat jeho použití. Rychlost maskování dat bude také záviset na počtu použitých funkcí, počtu sloupců a řádků DB, počtu omezení vyhledávání, která je třeba v procesu respektovat (pro referenční integritu), šířce pásma sítě, RAM, I/O, souběžných procesech a již brzy.

Následující nevědecká tabulka rozebírá většinu atributů popsaných výše pro pohodlnou referenci, pro některé (ale ne všechny!) podporované funkční kategorie maskování dat IRI a pouze obecně relativní. Netřeba dodávat, že IRI se zříká jakékoli záruky způsobilosti nebo odpovědnosti za tuto tabulku!

Funkce maskování dat IRI (v FieldShield &Voracity)


Ať už používáte vestavěné funkce maskování dat IRI nebo vlastní funkce, které definujete, myšlenkou je aplikovat je na základě vašich obchodních pravidel na konkrétní řádky nebo sloupce a/nebo napříč tabulkami. A uděláte to pomocí pravidel maskování dat, která můžete definovat, uložit a znovu použít. Je také možné (a preferováno) použít tyto funkce maskování dat na automaticky klasifikovaná data jako pravidla pro pohodlí a konzistenci. A několik z nich můžete využít v aplikacích pro dynamické maskování dat prostřednictvím volání API.

Uživatelé FieldShield (nebo Voracity) mohou vytvářet, spouštět a spravovat vaše úlohy maskování dat v bezplatném nejmodernějším grafickém rozhraní, postaveném na Eclipse.™ Nebo mohou upravovat a spouštět kompatibilní, samodokumentující skripty 4GL definující jejich zdrojová/cílová data a maskovací funkce a spouštějte tyto skripty na příkazovém řádku.

Další informace najdete na https://www.iri.com/solutions/data-masking nebo se obraťte na svého zástupce IRI.


  1. Různé způsoby porovnání schématu a dat tabulek SQL Server

  2. Databázová tabulka Android SQLite se nevytváří

  3. Pomalá migrace do cloudu

  4. Sloupec Postgresql nebyl nalezen, ale zobrazuje se v popisu