Megosztás a következőn keresztül:

Személyes adatok kezelése az Azure Monitor-naplókban és az Application Insightsban

  • Cikk

A Log Analytics egy olyan adattár, ahol valószínűleg személyes adatok találhatók. Az Application Insights egy Log Analytics-partícióban tárolja az adatait. Ez a cikk bemutatja, hogy hol tárolja a Log Analytics és az Application Insights a személyes adatokat, és hogyan kezelheti ezeket az adatokat.

Ebben a cikkben a naplóadatok a Log Analytics-munkaterületre küldött adatokra, az alkalmazásadatok pedig az Application Insights által gyűjtött adatokra vonatkoznak. Ha munkaterület-alapú Application Insights-erőforrást használ, a naplóadatokra vonatkozó információk érvényesek. Ha klasszikus Application Insights-erőforrást használ, az alkalmazásadatok érvényesek.

Feljegyzés

A személyes adatok megtekintésével vagy törlésével kapcsolatos információkért tekintse meg a GDPR általános adattulajdonosi kérelmeit, a GDPR-ra vonatkozó Azure-beli adattulajdonosi kérelmeket vagy a GDPR-ra vonatkozó Windows-adattulajdonosi kérelmeket az Adott területtől és igényektől függően. A GDPR-ról további információt a Microsoft Adatvédelmi központ GDPR-szakaszában és a Szolgáltatásmegbízhatósági portál GDPR szakaszában talál.

A szükséges engedélyek

Művelet A szükséges engedélyek
Adatok törlése Log Analytics-munkaterületről Microsoft.OperationalInsights/workspaces/purge/actiona Log Analytics-munkaterületre vonatkozó engedélyek, a Log Analytics-közreműködő beépített szerepkörének megfelelően, például

A személyes adatok kezelésének stratégiája

Bár Ön és a vállalata határozza meg a személyes adatok kezelésére vonatkozó stratégiát, az alábbiakban felsorolunk néhány módszert, amelyek műszaki szempontból a leginkább előnyben részesíthetők:

  • A személyes adatok gyűjtésének leállítása, illetve az összegyűjtött adatok elhomályosítása, anonimizálása vagy módosítása annak érdekében, hogy kizárja őket a "személyes" adatokból. Ez messze az előnyben részesített megközelítés, ami megtakarítja a költséges és hatékony adatkezelési stratégia létrehozását.
  • Normalizálja az adatokat az adatplatform és a teljesítmény negatív hatásának csökkentése érdekében. Explicit felhasználói azonosító naplózása helyett például hozzon létre egy keresőt, amely egy belső azonosítóval korrelálja a felhasználónevet és a hozzájuk tartozó adatokat, amelyet aztán máshol naplózhat. Így ha egy felhasználó arra kéri, hogy törölje személyes adatait, csak a felhasználónak megfelelő keresőtábla sorát törölheti.
  • Ha személyes adatokat kell gyűjtenie, hozzon létre egy folyamatot a törlési API-útvonal és a meglévő lekérdezési API használatával, hogy megfeleljen a felhasználóhoz társított személyes adatok exportálására és törlésére vonatkozó kötelezettségeknek.

Személyes adatok keresése a Log Analyticsben

A Log Analytics sémát ír elő az adatokhoz, de lehetővé teszi, hogy minden mezőt felülbíráljon egyéni értékekkel. Egyéni sémákat is betölthet. Így lehetetlen pontosan megmondani, hogy hol találhatók a személyes adatok az adott munkaterületen. A következő helyek azonban jó kiindulási pontok a leltárban.

Feljegyzés

Az alábbi lekérdezések némelyike egy munkaterület összes táblájának lekérdezésére használható search * . Javasoljuk, hogy lehetőség szerint kerülje a magas hatékonyságú lekérdezés használatát search *. Ehelyett egy adott táblát kérdezhet le.

Naplóadatok

  • IP-címek: A Log Analytics több táblában gyűjt különböző IP-adatokat. Az alábbi lekérdezés például az összes olyan táblát megjeleníti, amely az elmúlt 24 órában IPv4-címeket gyűjtött össze:

    search * 
| where * matches regex @'\b((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\.|$)){4}\b' //RegEx originally provided on https://stackoverflow.com/questions/5284147/validating-ipv4-addresses-with-regexp
| summarize count() by $table

  • Felhasználói azonosítók: A felhasználói felhasználónevek és a felhasználói azonosítók különböző megoldásokban és táblákban találhatók. A keresési paranccsal megkereshet egy adott felhasználónevet vagy felhasználói azonosítót a teljes adathalmazban:

    search "<username or user ID>"

    Ne feledje, hogy nem csak az ember által olvasható felhasználóneveket, hanem az adott felhasználóra visszavezethető GRAFIKUS GUID-ket is meg kell keresnie.

  • Eszközazonosítók: A felhasználói azonosítókhoz hasonlóan az eszközazonosítók is személyes adatoknak minősülnek. A felhasználói azonosítók esetében a fenti módszer használatával azonosíthatja a személyes adatokat tartalmazó táblákat.

  • Egyéni adatok: A Log Analytics lehetővé teszi egyéni adatok gyűjtését egyéni naplók, egyéni mezők, a HTTP Data Collector API és a rendszeresemény-naplók részeként. Ellenőrizze az összes személyes adatot.

  • Megoldás által rögzített adatok: Mivel a megoldási mechanizmus nyitott, javasoljuk, hogy a megfelelőség biztosítása érdekében tekintse át a megoldások által létrehozott összes táblát.

Alkalmazásadatok

  • IP-címek: Bár az Application Insights alapértelmezés szerint az összes IP-címmezőt 0.0.0.0 elfedi, meglehetősen gyakori, hogy felülbírálja ezt az értéket a tényleges felhasználói IP-címmel a munkamenet-adatok fenntartása érdekében. Az alábbi lekérdezés segítségével megkeresheti azokat a táblázatokat, amelyek az ELMÚLT 24 órában nem 0.0.0.0 az IP-cím oszlopában lévő értékeket tartalmazzák:

    search client_IP != "0.0.0.0"
| where timestamp > ago(1d)
| summarize numNonObfuscatedIPs_24h = count() by $table

  • Felhasználói azonosítók: Az Application Insights alapértelmezés szerint véletlenszerűen létrehozott azonosítókat használ a felhasználók és a munkamenetek nyomon követéséhez olyan mezőkben, mint a session_Id, a user_Id, a user_AuthenticatedId, a user_AccountId és a customDimensions. Gyakran előfordul azonban, hogy ezeket a mezőket az alkalmazás szempontjából relevánsabb azonosítóval, például felhasználónevekkel vagy Microsoft Entra GUID-kkel felülbírálják. Ezeket az azonosítókat gyakran személyes adatoknak tekintik. Javasoljuk, hogy rejtse el vagy anonimizálja ezeket az azonosítókat.

  • Egyéni adatok: Az Application Insights segítségével tetszőleges adattípushoz fűzhet egyéni dimenziókat. Az elmúlt 24 órában gyűjtött egyéni dimenziók azonosításához használja a következő lekérdezést:

    search * 
| where isnotempty(customDimensions)
| where timestamp > ago(1d)
| project $table, timestamp, name, customDimensions

  • Memórián belüli és átvitt adatok: Az Application Insights nyomon követi a kivételeket, a kéréseket, a függőségi hívásokat és a nyomkövetéseket. A személyes adatok gyakran a kód és a HTTP-hívás szintjén találhatók. Tekintse át a kivételeket, a kérelmeket, a függőségeket és a nyomkövetési táblákat az ilyen adatok azonosításához. Ha lehetséges, telemetria-inicializálókat használjon az adatok elrejtéséhez.

  • Pillanatkép-hibakereső rögzíti: Az Application Insights Pillanatkép-hibakereső funkciója lehetővé teszi a hibakeresési pillanatképek gyűjtését, ha az Application Insights kivételt észlel az alkalmazás éles példányán. A pillanatképek a verem minden lépésében elérhetővé teszik a teljes verem nyomkövetését, amely a kivételekhez és a helyi változók értékeihez vezet. Ez a funkció sajnos nem teszi lehetővé a illesztési pontok szelektív törlését vagy a pillanatképen belüli adatok programozott elérését. Ezért ha az alapértelmezett pillanatkép-megőrzési arány nem felel meg a megfelelőségi követelményeknek, javasoljuk, hogy kapcsolja ki a funkciót.

Személyes adatok exportálása és törlése

Határozottan javasoljuk, hogy alakítsa át az adatgyűjtési szabályzatot, hogy ne gyűjtsön személyes adatokat, ne fedje fel vagy anonimizálja a személyes adatokat, vagy egyéb módon módosítsa ezeket az adatokat, amíg az már nem minősül személyesnek. A személyes adatok kezelése során költségekkel jár egy stratégia meghatározása és automatizálása, egy olyan felület létrehozása, amelyen keresztül az ügyfelek kezelhetik az adataikat, valamint a folyamatos karbantartás. Ez a Log Analytics és az Application Insights esetében is számításilag költséges, és az egyidejű lekérdezési vagy purge API-hívások nagy mennyisége negatívan befolyásolhatja a Log Analytics-funkciókkal való minden egyéb interakciót. Ha azonban személyes adatokat kell gyűjtenie, kövesse az ebben a szakaszban található irányelveket.

Fontos

Bár a legtöbb törlési művelet sokkal gyorsabban fejeződik be, a törlési műveletek befejezéséhez szükséges hivatalos SLA 30 napra van beállítva az adatplatformra gyakorolt súlyos hatásuk miatt. Ez az SLA megfelel a GDPR követelményeinek. Ez egy automatizált folyamat, ezért nincs mód a művelet felgyorsítására.

Megtekintés és exportálás

Az adatkérések megtekintéséhez és exportálásához használja a Log Analytics lekérdezési API-t vagy az Application Insights lekérdezési API-t .

Feljegyzés

Nem használhatja a Log Analytics lekérdezési API-t olyanokon, amelyek alapszintű és kiegészítő táblacsomagokkal rendelkeznek. Ehelyett használja a Log Analytics /search API-t.

Implementálnia kell az adatok megfelelő formátumba való konvertálásának logikáját a felhasználók számára történő kézbesítéshez. Az Azure Functions nagyszerű hely az ilyen logika üzemeltetésére.

Törlés

Figyelmeztetés

A Log Analyticsben végzett törlések rombolóak és nem visszafordíthatóak! Kérjük, hogy a végrehajtás során fokozott óvatossággal járjon el.

Az Azure Monitor Purge API-ja lehetővé teszi a személyes adatok törlését. A törlési műveletet takarékosan használva elkerülheti a lehetséges kockázatokat, a teljesítményre gyakorolt hatást, valamint a Log Analytics-adatok összesítésének, mérésének és egyéb aspektusainak eltolásának lehetőségét. A személyes adatok kezelésének alternatív megközelítéséről a Személyes adatok kezelésének stratégiája című szakaszban olvashat.

A törlés egy kiemelt művelet. A Data Purger szerepkör megadása az Azure Resource Managerben az adatvesztés lehetősége miatt óvatosan.

A rendszererőforrások kezeléséhez óránként 50 kérelemre korlátozzuk a törlési kérelmeket. Kötegelje a törlési kérelmek végrehajtását egyetlen parancs elküldésével, amelynek predikátuma tartalmazza a törlést igénylő összes felhasználói identitást. A in operátorral több identitást is megadhat. Futtassa a lekérdezést a törlési kérelem végrehajtása előtt a várt eredmények ellenőrzéséhez.

Fontos

A Log Analytics vagy az Application Insights Purge API használata nem befolyásolja a megőrzési költségeket. A megőrzési költségek csökkentése érdekében csökkentenie kell az adatmegőrzési időt.

Naplóadatok

  • A Workspace Purge POST API egy objektumot vesz fel, amely megadja a törölni kívánt adatok paramétereit, és egy hivatkozási GUID-t ad vissza.

  • A Get Purge Status POST API egy "x-ms-status-location" fejlécet ad vissza, amely tartalmaz egy URL-címet, amelyet meghívhat a törlési művelet állapotának meghatározásához. Például:

    x-ms-status-location: https://management.azure.com/subscriptions/[SubscriptionId]/resourceGroups/[ResourceGroupName]/providers/Microsoft.OperationalInsights/workspaces/[WorkspaceName]/operations/purge-[PurgeOperationId]?api-version=2015-03-20

Feljegyzés

Az Alapszintű és a Kiegészítő táblacsomagokkal rendelkező táblákból nem törölhet adatokat.

Alkalmazásadatok

  • A Components – Purge POST API egy objektumot vesz fel, amely megadja az adatok paramétereit a törléshez, és egy hivatkozási GUID-t ad vissza.

  • A Components – Get Purge Status GET API egy "x-ms-status-location" fejlécet ad vissza, amely tartalmaz egy URL-címet, amelyet meghívhat a törlési művelet állapotának meghatározásához. Példa:

    x-ms-status-location: https://management.azure.com/subscriptions/[SubscriptionId]/resourceGroups/[ResourceGroupName]/providers/microsoft.insights/components/[ComponentName]/operations/purge-[PurgeOperationId]?api-version=2015-05-01

Következő lépések