Adatok védelme felhőalapú elemzésekhez az Azure-ban

A felhőalapú elemzések segítségével a szervezetek a követelményeknek megfelelő legjobb mintákat határozhatják meg, miközben több szinten is őrzik a személyes adatokat. A személyes adatok az egyének azonosítására használható adatok, például a jogosítványok száma, a társadalombiztosítási számok, a bankszámlaszámok, az útlevélszámok, az e-mail-címek stb. Számos szabályozás létezik ma a felhasználói adatvédelem védelmére.

Adattitkosság-besorolási séma

Classification	Leírás
Nyilvános	Bárki hozzáférhet az adatokhoz, és bárkinek elküldheti őket. Például nyissa meg a kormányzati adatokat.
Csak belső használat	Csak az alkalmazottak férhetnek hozzá az adatokhoz, és nem küldhetők el a vállalaton kívül.
Bizalmas	Az adatok csak akkor oszthatók meg, ha egy adott tevékenységhez szükséges. Az adatok nem küldhetők el a vállalaton kívül titoktartási szerződés nélkül.
Bizalmas (személyes adatok)	Az adatok személyes adatokat tartalmaznak, amelyeket csak korlátozott ideig kell maszkolni és megosztani. Az adatok nem küldhetők el jogosulatlan személyeknek vagy a vállalaton kívülre.
Korlátozott	Az adatok csak nevesített személyekkel oszthatók meg, akik a védelemért felelősek. Például jogi dokumentumok vagy üzleti titkok.

Az adatok betöltése előtt bizalmas vagy bizalmas (személyes) adatokként kell kategorizálnia az adatokat:

• Az adatok bizalmas vagy alacsonyabb kategóriába rendezhetők, ha egy felhasználó gazdagított vagy válogatott verzióban fér hozzá az adategységhez. A felhasználók megtekinthetik az összes oszlopot és sort.

• Az adatok bizalmas (személyes) adatokká rendezhetők, ha vannak olyan korlátozások, amelyeknél az oszlopok és sorok különböző felhasználók számára láthatók.

Fontos

Az adathalmazok bizalmas vagy bizalmas (személyes) adatokra válthatnakaz adatok kombinálásakor. Olyan esetekben, amikor az adatoknak állandónak kell lenniük, azokat egy külön mappába kell másolni, amely megfelel az adatok bizalmassági besorolásának és az előkészítési folyamatnak.

Bizalmas vagy lenti

Minden előkészített adattermékhez két Data Lake-mappát hozunk létre a bővített és válogatott rétegekben, bizalmas vagy bizalmas(személyes adatok) alatt, és hozzáférés-vezérlési listák használatával engedélyezzük a Microsoft Azure-címtár (Microsoft Entra ID) átmenő hitelesítését.

Ha egy adatalkalmazás-csapat egy bizalmas vagy az alatta lévő adategységet készít, akkor az egyszerű felhasználónevek és a szolgáltatásnév-objektumok két Microsoft Entra-csoporthoz vehetők fel (az egyik olvasási/írási, a másik pedig írásvédett hozzáférést biztosít). Ezt a két Microsoft Entra-csoportot az előkészítési folyamat során létre kell hozni, és a megfelelő adattermékmappába kell rendezni, a nyers és gazdagított adatok bizalmas vagy alatti tárolóival.

Ez a minta lehetővé teszi, hogy a Microsoft Entra átmenő hitelesítést támogató számítási termékek csatlakozzanak a data lake-hez, és hitelesítsék a bejelentkezett felhasználókat. Ha egy felhasználó az adategység Microsoft Entra-csoportjának része, a Microsoft Entra átmenő hitelesítéssel férhet hozzá az adatokhoz. Lehetővé teszi a csoporton belüli felhasználók számára, hogy szabályzatszűrők nélkül olvassák be a teljes adategységet. Az Access ezután részletesen naplózható a megfelelő naplókkal és a Microsoft Graphtal.

A data lake elrendezésével kapcsolatos javaslatokért tekintse át a három Azure Data Lake Storage Gen2-fiók üzembe helyezését az egyes adat-kezdőzónákhoz.

Megjegyzés:

Számítási termékek például az Azure Databricks, az Azure Synapse Analytics, az Apache Spark és az Azure Synapse SQL igény szerinti készletei, amelyek engedélyezve vannak a Microsoft Entra átmenő hitelesítésével.

Bizalmas adatok (személyes adatok)

Bizalmas (személyes adatok) esetén a vállalatnak korlátoznia kell, hogy a felhasználók mit láthatnak szabályzattal, adatmásolattal vagy számítással. Ebben az esetben a szervezetnek fontolóra kell vennie a hozzáférés-vezérlés számítási rétegbe való áthelyezését vagy injektálását. A felhőalapú elemzések adatainak védelmét négyféleképpen lehet megközelíteni.

Példaforgatókönyv

Az alábbi példa a bizalmas (személyes adatok) védelmének lehetőségeit ismerteti:

Az adatalkalmazások emberi erőforrások (HR) személyzeti adatterméket használnak fel Észak-Amerika és Európa számára. A használati eset arra kéri az európai felhasználókat, hogy csak az európai személyzeti rekordokat lássák, és Észak-Amerika felhasználók csak Észak-Amerika személyi rekordokat lássanak. További korlátozás, hogy csak a HR-vezetők láthassák a fizetésadatokat tartalmazó oszlopokat.

1. lehetőség: Házirendmotor (ajánlott)

Az első két lehetőség lehetővé teszi a bizalmas (személyes adatok) kezelését, valamint az integrációs műveletek és az adattermék-csapatok számára is lehetővé teszik a hozzáférés azonosítását és korlátozását. Lehet, hogy elég egy kis méretű elemzési platformhoz, de egy szabályzatmotort egy több száz adatterméket tartalmazó nagyvállalat adatkezelési célzónájába kell helyezni. A szabályzatmotorok támogatják a központi kezelési, biztonsági és vezérlési módot:

• Hozzáférés az adatokhoz
• Az adatéletciklus kezelése
• Belső és külső szabályzatok és szabályozások
• Adatmegosztási szabályzatok
• Bizalmas (személyes adatok) azonosítása
• Elemzések a védelemről és a megfelelőségről
• Adatvédelmi jelentéskészítési szabályzatok

A szabályzatmotorok általában integrálhatók egy olyan adatkatalógussal, mint az Azure Purview. Az Azure Marketplace külső gyártói megoldásokat is tartalmaz, és egyes szállítók az Azure Synapse és az Azure Databricks segítségével titkosítják és visszafejtik az információkat, miközben sorszintű és oszlopszintű biztonságot nyújtanak. 2022. januárhoz hasonlóan az Azure Purview nyilvános előzetes verziót indított el a hozzáférési szabályzatok számára a Blobban és az Azure Data Lake Storage (ADLS) Gen2-ben tárolt adatokhoz való hozzáférés szabályozásához. Lásd : Adathalmazok kiépítése adattulajdonos által az Azure Storage-hoz (előzetes verzió).

A szabályzatmotornak a Microsoft Entra-csoportokkal kell szabályzatokat alkalmaznia az adattermékekre. Az adatvédelmet biztosító szabályzatmegoldások elvárása a bizalmas (személyes adatok) tokenizálása, valamint az attribútumhozzáférés-vezérlés folyamatos ellenőrzése, hogy a felhasználó detokenizálhassa a hozzáféréshez szükséges oszlopokat.

Mint már említettük, a szabályzatmotor sikerességéhez fontos, hogy integrálható legyen az adatkatalógusba, és hogy a DevOps REST API-t használjon egy új adathalmaz előkészítéséhez. Ahogy az adatalkalmazás-csapatok olvasási adatforrásokat hoznak létre, regisztrálva lesznek az adatkatalógusban, és segítenek azonosítani a bizalmas (személyes) adatokat. A szabályzatmotornak importálnia kell a definíciót, és meg kell tagadnia az adatokhoz való hozzáférést, amíg a csapatok be nem állítják a hozzáférési szabályzatait. Mindezt egy REST API-munkafolyamaton keresztül kell elvégezni az informatikai szolgáltatásfelügyeleti megoldásból.

2. lehetőség: Bizalmas vagy bizalmas (személyes adatok) verziók

Minden bizalmas (személyes adatként ) besorolt adattermék esetében a folyamat két példányt hoz létre. A bizalmas vagy az alatti besorolású oszlop, amely eltávolítja az összes bizalmas (személyes adat) oszlopot, és az adattermék bizalmas vagy alatti mappája alatt jön létre. A másik példány a bizalmas (személyes adatok) mappában jön létre az adattermékhez, amely tartalmazza az összes bizalmas adatot. Minden mappához hozzá lesz rendelve egy Microsoft Entra olvasó biztonsági csoport és egy Microsoft Entra író biztonsági csoport. Az Adathozzáférés-kezelés használatával a felhasználó hozzáférést kérhet az adattermékhez.

Bár ez megfelel a bizalmas (személyes adatok) és bizalmas adatok elkülönítésének, a bizalmas (személyes adatok) számára active Directory-hitelesítésen keresztül hozzáférést biztosító felhasználó az összes sort le tudja kérdezni. Ha sorszintű biztonságra van szüksége, akkor az 1. lehetőség: Szabályzatmotor (ajánlott) vagy a 3. lehetőség: Azure SQL Database, felügyelt SQL-példány vagy Azure Synapse Analytics SQL-készletek használata szükséges.

3. lehetőség: Azure SQL Database, felügyelt SQL-példány vagy Azure Synapse Analytics SQL-készletek

Az adatalkalmazások SQL Database, felügyelt SQL-példány vagy Azure Synapse Analytics SQL-készletek használatával töltik be az adattermékeket egy olyan adatbázisba, amely támogatja a sorszintű biztonságot, az oszlopszintű biztonságot és a dinamikus adatmaszkolást. Az adatalkalmazási csapatok különböző Microsoft Entra-csoportokat hoznak létre, és olyan engedélyeket rendelnek hozzá, amelyek támogatják az adatok bizalmassági állapotát.

Ebben a forgatókönyvben az adatalkalmazási csapatoknak a következő négy, írásvédett hozzáféréssel rendelkező Microsoft Entra-csoportot kell létrehozniuk:

Csoportosítás	Permission
DA-AMERICA-HRMANAGER-R	Tekintse meg Észak-Amerika HR-személyzet adategységét a béradatokkal.
DA-AMERICA-HRGENERAL-R	Fizetésadatok nélkül tekintheti meg Észak-Amerika HR-személyzet adategységét.
DA-EUROPE-HRMANAGER-R	Az Europe HR személyzeti adategységének megtekintése a béradatokkal .
DA-EUROPE-HRGENERAL-R	Az Europe HR személyzeti adategységének megtekintése fizetésadatok nélkül .

A korlátozások első szintje támogatja a dinamikus adatmaszkolást, amely bizalmas adatokat rejt el a jogosultságokkal nem rendelkező felhasználók elől. Ennek a megközelítésnek az egyik előnye, hogy egy REST API-val integrálható az adathalmazok előkészítési folyamatába.

A második szint az oszlopszintű biztonság hozzáadása annak érdekében, hogy a nem HR-vezetők ne láthassák a fizetéseket és a sorszintű biztonságot, hogy az európai és Észak-Amerika csapattagok mely sorokat láthatják.

A transzparens adattitkosítás mellett a biztonsági réteg az adatoszlop titkosítása és a visszafejtés az olvasáskor.

A táblák elérhetővé tehetők az Azure Databricks számára az Apache Spark-összekötővel : SQL Server és Azure SQL Database.

4. lehetőség: Azure Databricks

A negyedik lehetőség az Azure Databricks használata bizalmas (személyes adatok) feltárására. A Fernet-titkosítási kódtárak, a felhasználó által definiált függvények (UDF-ek), a Databricks-titkos kódok, a táblahozzáférés-vezérlés és a dinamikus nézetfüggvények kombinációja segít az oszlopok titkosításában és visszafejtésében.

Blogbejegyzésként, az oszlopszintű titkosítás kényszerítése és az adatok duplikálása elkerülése érdekében a következőket írja le:

Ennek a folyamatnak az első lépése az adatok védelme a betöltés során történő titkosítással, és az egyik lehetséges megoldás a Fernet Python-kódtár. A Fernet szimmetrikus titkosítást használ, amely számos szabványos titkosítási primitível rendelkezik. Ezt a tárat egy titkosítási UDF-ben használjuk, amely lehetővé teszi számunkra az adatkeret adott oszlopának titkosítását. A titkosítási kulcs tárolásához a Databricks titkos kulcsait használjuk a hozzáférés-vezérléssel, hogy csak az adatbetöltési folyamatunk férhessen hozzá. Miután az adatokat a Delta Lake-táblákba írtuk, a személyes adatoszlopok olyan értékeket tartalmaznak, mint a társadalombiztosítási szám, a telefonszám, a hitelkártyaszám és más azonosítók, a jogosulatlan felhasználók számára lehetetlen lesz elolvasni.

Miután megírta és védte a bizalmas adatokat, módot kell adnia arra, hogy a kiemelt felhasználók elolvassák a bizalmas adatokat. Első lépésként létre kell hoznia egy állandó UDF-t, amely hozzáadható a Databricksen futó Hive-példányhoz. Ahhoz, hogy egy UDF végleges legyen, a Scalában kell írni. Szerencsére a Fernet egy Scala-implementációval is rendelkezik, amelyet a visszafejtett olvasásokhoz használhat. Ez az UDF ugyanahhoz a titkos kódhoz fér hozzá, amelyet a titkosított írásban használ a visszafejtéshez, és ebben az esetben hozzáadja a fürt Spark-konfigurációjába. Ehhez fürthozzáférés-vezérlőket kell hozzáadni a kiemelt és a nem kiemelt felhasználók számára, hogy szabályozhassuk a kulcshoz való hozzáférésüket. Az UDF létrehozása után a jogosultsággal rendelkező felhasználók nézetdefinícióiban használhatjuk a visszafejtött adatok megtekintéséhez.

Dinamikus nézetfüggvényekkel csak egy nézetet hozhat létre, és visszaadhatja a titkosított vagy visszafejtett értékeket azon Databricks-csoport alapján, amelyhez tartoznak.

Az előző példában két dinamikus nézetfüggvényt hozna létre, egyet Észak-Amerika és egy másikat Európában, és implementálná a titkosítási technikákat ebben a jegyzetfüzetben.

Észak-Amerika nézet:

-- 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'

Európai nézet:

-- 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'

Ahhoz, hogy működjön, engedélyeznie kell az Azure Databricks-tábla hozzáférés-vezérlését a munkaterületen, és a következő engedélyeket alkalmazhatja:

• Hozzáférés biztosítása DA-AMERICA-HRMANAGER-R és DA-AMERICA-HRGENERAL-R a Microsoft Entra csoportok számára a vhr_us nézethez való hozzáférés biztosítása.
• Hozzáférés biztosítása DA-EUROPE-HRMANAGER-R és DA-EUROPE-HRGENERAL-R a Microsoft Entra csoportok számára a vhr_eu nézethez való hozzáférés biztosítása.

Mivel az oszlopok titkosítva vannak, és nem fejthetők vissza a bizalmas vagy az alatti munkaterületen, a bizalmas vagy az alatti munkaterületek továbbra is használhatják a Microsoft Entra átmenő hitelesítést, és lehetővé teszik a felhasználók számára, hogy engedélyük alapján felfedezzék a tavat.

A táblahozzáférés használata esetén a hozzáférést igénylő csapatok bekerülnek az Azure Databricks-munkaterületre. Az Azure Databricks szolgáltatásnevek használatával képezné le az Azure Data Lake Storage-t, de az adatokat az Azure Databricks táblahozzáférési vezérlése biztosítaná.

Az új adattermékek üzembe helyezésekor a DevOps-folyamat egy részének szkripteket kell futtatnia, hogy beállíthassa a táblaengedélyeket az Azure Databricks-munkaterületen, és hozzá kell adnia a megfelelő Microsoft Entra-csoportokat ezekhez az engedélyekhez.

Megjegyzés:

Az Azure Databricks táblahozzáférés-vezérlése nem kombinálható a Microsoft Entra átmenő hitelesítésével. Ezért csak egy Azure Databricks-munkaterületet használhat, és ehelyett táblahozzáférés-vezérlést használhat.

Korlátozott adatok

A bizalmas vagy korlátozott adatokra vonatkozó implementálási lehetőségek mellett azt is javasoljuk, hogy szigorúan bizalmas adatokat tároljon egy dedikált adat-célzónában és adatkezelési célzónában.

Lehetővé teszi az olyan konkrét követelményeket, mint a just-in-time hozzáférés, az ügyfél által felügyelt titkosítási kulcsok, valamint a célzónára alkalmazott bejövő vagy kimenő korlátozások. Az útmutató kiértékelte, hogy az ilyen típusú adatokat ugyanabba az adat-kezdőzónába helyezi, de különböző tárfiókokat. Ez azonban megnehezítheti a megoldást a hálózati rétegen, például hálózati biztonsági csoportokkal és másokkal.

A dedikált "korlátozott" adatkezelési célzónának csatlakoznia kell a "korlátozott" adat-célzónában lévő adatok katalógusához. Korlátoznia kell, hogy kik kereshetnek ezekre az adatokra a katalógusban.

Következő lépések

• Adathozzáférés-kezelés