Ochrana osobních údajů v datech pro analýzy na úrovni cloudu v Azure

Článek
10/10/2023

Analýzy na úrovni cloudu umožňují organizacím určit nejlepší vzory, které vyhovují jejich požadavkům, a zároveň chránit osobní údaje na více úrovních. Osobní údaje jsou jakákoli data, která lze použít k identifikaci jednotlivců, například čísla řidičského průkazu, čísla sociálního pojištění, čísla bankovního účtu, čísla pasů, e-mailové adresy a další. Dnes existuje mnoho předpisů, které chrání ochranu osobních údajů uživatelů.

Schéma klasifikace důvěrnosti dat

Klasifikace	Popis
Veřejný	Kdokoli má přístup k datům a může je odeslat komukoli. Například otevřete data státní správy.
Pouze interní použití	K datům mají přístup jenom zaměstnanci a nemůžou se posílat mimo společnost.
Důvěrné	Data se dají sdílet jenom v případě, že jsou potřebná pro konkrétní úkol. Data nelze odeslat mimo společnost bez smlouvy o nezveřejnění.
Citlivá (osobní údaje)	Data obsahují soukromé informace, které musí být maskovány a sdíleny pouze po omezenou dobu. Data se nedají posílat neoprávněným pracovníkům ani mimo společnost.
Omezeno	Data je možné sdílet pouze s pojmenovanými osobami, kteří jsou zodpovědní za jejich ochranu. Například právní dokumenty nebo obchodní tajemství.

Před ingestováním dat musíte data zařadit do kategorií jako důvěrná nebo nižší nebo citlivá (osobní údaje):

Data můžou být seřazena do důvěrných nebo níže, pokud uživatel získá přístup k datovému prostředku v rozšířeném nebo kurátorovaném prostředku. Uživatelé můžou zobrazit všechny sloupce a řádky.
Data mohou být seřazena do citlivých (osobních údajů), pokud existují omezení, pro které sloupce a řádky jsou viditelné pro různé uživatele.

Důležité

Datová sada se může při kombinování dat změnit z důvěrných nebo nižšíchna citlivá (osobní data). V situacích, kdy by data měla být trvalá, by se měla zkopírovat do samostatné složky, která odpovídá klasifikaci a zpracování důvěrnosti dat pro jejich onboarding.

Důvěrné nebo níže

Pro každý zprovozněný datový produkt vytvoříme dvě složky data lake v rozšířené a kurátorované vrstvě, důvěrné nebo níže a citlivé (osobní údaje) a pomocí seznamů řízení přístupu povolíme předávací ověřování v adresáři Microsoft Azure (Microsoft Entra ID).

Pokud tým datové aplikace nasadí důvěrný nebo nižší datový asset, dají se hlavní názvy uživatelů a instanční objekty přidat do dvou skupin Microsoft Entra (jedna pro přístup jen pro čtení a zápis a druhá pro přístup jen pro čtení). Tyto dvě skupiny Microsoft Entra by se měly vytvořit během procesu onboardingu a seřadit do příslušné složky datového produktu s důvěrnými nebo pod kontejnery pro nezpracovaná a rozšířená data.

Tento model umožňuje všem výpočetním produktům, které podporují předávací ověřování Microsoft Entra, připojení k datovému jezeře a ověření přihlášených uživatelů. Pokud je uživatel součástí skupiny Microsoft Entra datového prostředku, může k datům přistupovat prostřednictvím předávacího ověřování Microsoft Entra. Umožňuje uživatelům ve skupině číst celý datový prostředek bez filtrů zásad. Access je pak možné auditovat podrobně pomocí příslušných protokolů a Microsoft Graphu.

Doporučení týkající se rozložení datového jezera najdete v tématu Zřízení tří účtů Azure Data Lake Storage Gen2 pro každou cílovou zónu dat.

Poznámka

Mezi příklady výpočetních produktů patří fondy Azure Databricks, Azure Synapse Analytics, Apache Spark a Azure Synapse SQL na vyžádání s povoleným předávacím ověřováním Microsoft Entra.

Citlivá data (osobní údaje)

U citlivých (osobních údajů) musí podnik omezit, co uživatelé vidí prostřednictvím zásad, kopií dat nebo výpočetních prostředků. V takovém případě musí organizace zvážit přesunutí nebo vložení řízení přístupu do výpočetní vrstvy. Existují čtyři možnosti, jak přistupovat k zabezpečení dat v rámci analýzy v cloudovém měřítku.

Ukázkový scénář

Následující příklad popisuje možnosti zabezpečení citlivých (osobních údajů):

Datová aplikace ingestuje datový produkt lidských zdrojů (HR) pro Severní Amerika a Evropu. Případ použití vyzývá evropské uživatele, aby viděli pouze evropské záznamy o zaměstnancích a Severní Amerika n uživatelů, aby viděli pouze Severní Amerika n personální záznamy. Dále je omezena tak, aby sloupce, které obsahují data o mzdách, viděli jenom manažeři personálního oddělení.

Možnost 1: Modul zásad (doporučeno)

První dvě možnosti poskytují způsob, jak zpracovávat citlivé (osobní údaje) a také udělují řízení operací integrace a datovým produktovým týmům k identifikaci a omezení přístupu. Může to stačit pro malou analytickou platformu, ale modul zásad by se měl umístit do cílové zóny správy dat pro velký podnik se stovkami datových produktů. Moduly zásad podporují centrální způsob správy, zabezpečení a řízení:

Přístup k datům
Správa životního cyklu dat
Vnitřní a vnější politiky a předpisy
Zásady sdílení dat
Identifikace citlivých (osobních údajů)
Přehledy o ochraně a dodržování předpisů
Zásady pro vytváření sestav ochrany dat

Modul zásad se obvykle integruje s katalogem dat, jako je Azure Purview. Azure Marketplace nabízí řešení třetích stran a někteří dodavatelé pracují s Azure Synapse a Azure Databricks za účelem šifrování a dešifrování informací a zároveň poskytují zabezpečení na úrovni řádků a sloupců. Od ledna 2022 služba Azure Purview spustila veřejnou verzi Preview zásad přístupu pro řízení přístupu k datům uloženým v objektech blob a Azure Data Lake Storage (ADLS) Gen2. Viz zřizování datových sad podle vlastníka dat pro Azure Storage (Preview)

Modul zásad by měl používat skupiny Microsoft Entra k použití zásad na datové produkty. Očekává se, že jakékoli řešení zásad poskytující ochranu osobních údajů bude tokenizovat citlivé (osobní údaje) a vždy kontrolovat řízení přístupu atributů tak, aby uživatel mohl detokenizovat sloupce, ke kterým potřebuje přístup.

Jak už bylo zmíněno, aby modul zásad uspěl, je důležité, aby se integrovali do katalogu dat a devOps použili rozhraní REST API k připojení nové datové sady. Vzhledem k tomu, že týmy datových aplikací vytvářejí zdroje dat pro čtení, budou zaregistrovány v katalogu dat a pomáhají identifikovat citlivé (osobní údaje). Modul zásad by měl importovat definici a odepřít veškerý přístup k datům, dokud týmy nenastaví své zásady přístupu. To vše by se mělo provést prostřednictvím pracovního postupu rozhraní REST API z řešení pro správu IT služeb.

Možnost 2: Důvěrné nebo nižší a citlivé verze (osobní údaje)

Pro každý datový produkt, který je klasifikován jako citlivý (osobní údaje) dvě kopie, jsou vytvořeny kanálem. Ten, který je klasifikován jako důvěrný nebo nižší , který má odebrané všechny citlivé sloupce (osobní údaje) a je vytvořen v rámci důvěrné nebo podsložky pro datový produkt. Druhá kopie se vytvoří ve složce citlivých (osobních údajů) pro datový produkt, který obsahuje všechna citlivá data. Každá složka by byla přiřazena skupině zabezpečení Microsoft Entra reader a skupině zabezpečení Microsoft Entra writer. Pomocí správy přístupu k datům může uživatel požádat o přístup k datovému produktu.

I když to splňuje oddělení citlivých (osobních údajů) a důvěrných nebo níže, uživatel udělený přístup prostřednictvím předávacího ověřování služby Active Directory k citlivým (osobním údajům) by mohl dotazovat všechny řádky. Pokud potřebujete zabezpečení na úrovni řádků, budete muset použít možnost 1: Modul zásad (doporučeno) nebo možnost 3: Azure SQL Database, SQL Managed Instance nebo fondy SQL Služby Synapse Analytics.

Možnost 3: Fondy SQL Azure SQL Database, SQL Managed Instance nebo Azure Synapse Analytics

Datová aplikace používá fondy SQL Database, SQL Managed Instance nebo Azure Synapse Analytics k načtení datových produktů do databáze, která podporuje zabezpečení na úrovni řádků, zabezpečení na úrovni sloupců a dynamické maskování dat. Týmy datových aplikací vytvářejí různé skupiny Microsoft Entra a přiřazují oprávnění, která podporují citlivost dat.

V případě použití tohoto scénáře by týmy datových aplikací potřebovaly vytvořit následující čtyři skupiny Microsoft Entra s přístupem jen pro čtení:

Seskupit	Oprávnění
`DA-AMERICA-HRMANAGER-R`	Zobrazte si datový prostředek personálního oddělení Severní Amerika s informacemi o platu.
`DA-AMERICA-HRGENERAL-R`	Zobrazení datového prostředku personálního oddělení Severní Amerika bez informací o platu
`DA-EUROPE-HRMANAGER-R`	Zobrazit datový prostředek personálního oddělení Evropy s informacemi o platu
`DA-EUROPE-HRGENERAL-R`	Zobrazit datový prostředek personálního oddělení Evropy bez informací o platu

První úroveň omezení by podporovala dynamické maskování dat, které skryje citlivá data od uživatelů bez oprávnění. Jednou z výhod tohoto přístupu je, že se dá integrovat do onboardingu datové sady pomocí rozhraní REST API.

Druhou úrovní je přidat zabezpečení na úrovni sloupců, aby správci, kteří nejsou zaměstnanci personálního oddělení, viděli platy a zabezpečení na úrovni řádků, aby omezili, které řádky mohou vidět členové týmu a Severní Amerika n.

Kromě transparentního šifrování dat by vrstva zabezpečení měla při čtení šifrovat sloupec dat a dešifrovat je.

Tabulky je možné zpřístupnit azure Databricks pomocí konektoru Apache Spark: SQL Server a Azure SQL Database.

Možnost 4: Azure Databricks

Možnost 4 je použít Azure Databricks k prozkoumání citlivých (osobních údajů). Použití kombinace šifrovacích knihoven Fernetu, uživatelem definovaných funkcí (UDF), tajných kódů Databricks, řízení přístupu k tabulce a funkcí dynamického zobrazení pomáhá šifrovat a dešifrovat sloupce.

Jako blogový příspěvek popisuje vynucení šifrování na úrovni sloupce a zabránění duplikování dat:

Prvním krokem v tomto procesu je ochrana dat šifrováním během příjmu dat a jedním z možných řešení je knihovna Fernet Pythonu. Fernet používá symetrické šifrování, které je sestaveno s několika standardními kryptografickými primitivami. Tato knihovna se používá v rámci funkce definované uživatelem šifrování, která nám umožní šifrovat libovolný daný sloupec v datovém rámci. K uložení šifrovacího klíče používáme tajné kódy Databricks s ovládacími prvky přístupu, aby k němu mohl přistupovat pouze náš proces příjmu dat. Jakmile se data zapíšou do tabulek Delta Lake, sloupce osobních dat, které obsahují hodnoty, jako je číslo sociálního pojištění, telefonní číslo, číslo platební karty a další identifikátory, nebudou možné, aby ho neoprávněný uživatel přečetl.

Jakmile budete mít citlivá data zapsaná a chráněná, potřebujete způsob, jak privilegovaní uživatelé číst citlivá data. První věcí, kterou je potřeba udělat, je vytvoření trvalé uživatelem definované uživatelem pro přidání do instance Hive spuštěné v Databricks. Aby byla funkce definovaná uživatelem trvalá, musí být napsaná v jazyce Scala. Fernet má naštěstí také implementaci Scala, kterou můžete použít pro dešifrovaná čtení. Tato funkce definovaná uživatelem také přistupuje ke stejnému tajnému kódu použitému v zašifrovaném zápisu k dešifrování a v tomto případě se přidá do konfigurace Sparku clusteru. To vyžaduje, abychom přidali řízení přístupu ke clusteru pro privilegované a neprivilegované uživatele, aby mohli řídit přístup ke klíči. Po vytvoření definované uživatelem ji můžeme použít v definicích zobrazení pro privilegované uživatele, abychom viděli dešifrovaná data.

Pomocí funkcí dynamického zobrazení můžete vytvořit pouze jedno zobrazení a vrátit šifrované nebo dešifrované hodnoty na základě skupiny Databricks, do které patří.

V předchozím příkladu byste vytvořili dvě dynamické funkce zobrazení, jednu pro Severní Amerika a druhou pro Evropu a implementovali techniky šifrování v tomto poznámkovém bloku.

zobrazení Severní Amerika n:

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW vhr_us AS
SELECT
  emp_id,
  CASE WHEN
    is_member('DA-AMERICA-HRMANAGER-R') THEN udfPIIDecrypt(salary, "${spark.fernet}")
    ELSE 0
  END AS salary,
FROM hr_enriched
where region='US'

Evropský pohled:

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW vhr_eu AS
SELECT
  emp_id,
  CASE WHEN
    is_member('DA-EUROPE-HRMANAGER-R') THEN udfPIIDecrypt(salary, "${spark.fernet}")
    ELSE 0
  END AS salary,
FROM hr_enriched
where region='EU'

Aby to fungovalo, povolili byste v pracovním prostoru řízení přístupu k tabulce Azure Databricks a použili následující oprávnění:

Udělte DA-AMERICA-HRMANAGER-R skupině DA-AMERICA-HRGENERAL-R Microsoft Entra přístup k vhr_us zobrazení.
Udělte DA-EUROPE-HRMANAGER-R skupině DA-EUROPE-HRGENERAL-R Microsoft Entra přístup k vhr_eu zobrazení.

Vzhledem k tomu, že sloupce jsou šifrované a nejde je dešifrovat v důvěrném nebo pod pracovním prostoru, můžou důvěrné nebo následující pracovní prostory dál používat předávací ověřování Microsoft Entra a umožnit uživatelům prozkoumávat jezero na základě jejich oprávnění.

Pokud se používá přístup k tabulce, týmy, které vyžadují přístup, se přidají do pracovního prostoru Azure Databricks. Azure Databricks by k mapování na Azure Data Lake Storage použil instanční objekty, ale data by byla zabezpečená pomocí řízení přístupu k tabulce Azure Databricks.

Při nasazení nových datových produktů by část procesu DevOps potřebovala spouštět skripty pro nastavení oprávnění tabulky v pracovním prostoru Azure Databricks a přidání správných skupin Microsoft Entra do těchto oprávnění.

Poznámka

Řízení přístupu k tabulce Azure Databricks se nedá kombinovat s předávacím ověřováním Microsoft Entra. Proto můžete použít pouze jeden pracovní prostor Azure Databricks a místo toho použít řízení přístupu k tabulce.

Omezená data

Spolu s implementací možností pro důvěrná nebo omezená data také doporučujeme hostovat vysoce důvěrná data ve vyhrazené cílové zóně dat a cílové zóně správy dat.

Umožňuje konkrétní požadavky, jako je přístup za běhu, klíče spravované zákazníkem pro šifrování a omezení příchozích nebo odchozích přenosů, která se vztahují na cílovou zónu. Pokyny vyhodnotily umístění dat tohoto typu do stejné cílové zóny dat, ale do různých účtů úložiště. Může ale komplikovat řešení na síťové vrstvě, například se skupinami zabezpečení sítě a dalšími.

Vyhrazená cílová zóna správy dat s omezeným přístupem by se měla připojit k katalogu dat v cílové zóně s omezeným přístupem. Měl by omezit, kdo může tato data hledat v katalogu.

Další kroky

Správa přístupu k datům