在 Azure 監視器記錄和 Application Insights 中管理個人資料

  • 發行項

Log Analytics 是可能找到個人資料的數據存放區。 Application Insights 會將其數據儲存在 Log Analytics 數據分割中。 本文說明 Log Analytics 和 Application Insights 儲存個人資料的位置，以及如何管理此數據。

在本文中， 記錄數據 是指傳送至 Log Analytics 工作區的數據，而 應用程式數據 則是指 Application Insights 收集的數據。 如果您使用工作區型 Application Insights 資源，則會套用記錄數據的相關信息。 如果您使用傳統 Application Insights 資源，則會套用應用程式數據。

注意

如需檢視或刪除個人資料的詳細資訊，請參閱 適用於 GDPR 的 Azure 資料主體要求。 如需 GDPR 的詳細資訊，請參閱 Microsoft 信任中心的 GDPR 區段和服務信任入口網站的 GDPR 區段。

個人資料處理策略

雖然您和貴公司必須定義處理個人資料的策略，但以下是一些方法，從技術觀點最不理想列出：

  • 停止收集個人資料，或模糊化、匿名或調整收集的數據，使其不被視為「個人」。 這是 慣 用的方法，可節省您建立昂貴且具影響力的數據處理策略的需求。
  • 將數據正規化，以減少對數據平臺和效能的負面影響。 例如，不要記錄明確的使用者標識碼，而是建立查閱，以將使用者名稱和其詳細數據與內部標識元相互關聯，然後可記錄到其他地方。 如此一來，如果使用者要求您刪除其個人資訊，您就只能刪除對應至使用者之查閱表格中的數據列。
  • 如果您需要收集個人資料，請使用清除 API 路徑和現有的查詢 API 來建置程式，以符合匯出和刪除與使用者相關聯的任何個人資料的任何義務。

在Log Analytics中尋找個人資料的位置

Log Analytics 會為您的數據指定架構，但可讓您使用自定義值覆寫每個字段。 您也可以內嵌自定義架構。 因此，在特定的工作區中無法確切地指出個人資料的位置。 不過，下列位置在您的清查中是不錯的起點。

注意

下列部分查詢會使用 search * 來查詢工作區中的所有數據表。 我們強烈建議您盡可能避免使用 search *，這會建立非常沒有效率的查詢。 請改為查詢特定數據表。

記錄資料

  • IP 位址：Log Analytics 會收集多個數據表中的各種IP資訊。 例如，下列查詢會顯示過去 24 小時內收集 IPv4 位址的所有資料表：

    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

  • 使用者識別碼：您可以在各種解決方案和數據表中找到使用者使用者名稱和使用者識別碼。 您可以使用搜尋命令，在整個資料集中尋找特定的使用者名稱或使用者識別碼：

    search "<username or user ID>"

    請記得不僅要尋找人類可讀取的用戶名稱，還要尋找可追溯到特定使用者的 GUID。

  • 裝置標識碼：如同使用者標識碼，裝置標識碼有時會被視為個人資料。 針對使用者標識碼使用上述方法，以識別保存個人資料的數據表。

  • 自定義數據：Log Analytics 可讓您透過自定義記錄、自定義欄位、 HTTP 資料收集器 API，以及作為系統事件記錄的一部分收集自定義數據。 檢查個人資料的所有自定義數據。

  • 解決方案擷取的數據：因為解決方案機制是開放式的，因此建議您檢閱解決方案所產生的所有數據表，以確保合規性。

應用程式資料

  • IP 位址：雖然 Application Insights 預設會將所有 IP 位址欄位 0.0.0.0 模糊化，但使用實際的使用者 IP 覆寫此值來維護會話資訊相當常見。 使用下列查詢來尋找包含過去 24 小時內 IP 位址資料行0.0.0.0值的任何資料表：

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

  • 用戶標識符：根據預設，Application Insights 會針對session_Id、user_Id、user_AuthenticatedId、user_AccountId和 customDimensions 等字段中的使用者和會話追蹤使用隨機產生的標識符。 不過，通常會以與應用程式更相關的標識碼來覆寫這些欄位，例如用戶名稱或 Microsoft Entra GUID。 這些標識碼通常被視為個人資料。 建議您模糊化或匿名這些標識碼。

  • 自訂數據：Application Insights 可讓您將一組自定義維度附加至任何數據類型。 使用下列查詢來識別過去 24 小時內收集的自訂維度：

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

  • 記憶體內部和傳輸中的數據：Application Insights 會追蹤例外狀況、要求、相依性呼叫和追蹤。 您通常會在程式代碼和 HTTP 呼叫層級找到個人資料。 檢閱例外狀況、要求、相依性和追蹤數據表，以識別任何這類數據。 盡可能使用 遙測初始化表達式 來模糊化此數據。

  • 快照調試程式擷取： Application Insights 中的快照調試程式 功能可讓您在 Application Insights 偵測到應用程式生產實例上的例外狀況時收集偵錯快照集。 快照集會公開完整的堆疊追蹤，導致堆疊中每個步驟的例外狀況和局部變數的值。 不幸的是，這項功能不允許選擇性刪除快照點或以程式設計方式存取快照集內的數據。 因此，如果預設快照集保留率不符合您的合規性需求，建議您關閉此功能。

匯出和刪除個人資料

強烈建議您重新建構數據收集原則，以停止收集個人資料、模糊化或匿名個人資料，或修改這類數據，直到不再被視為個人數據為止。 在處理個人資料時，您將會產生定義和自動化策略的成本、建置客戶與其數據互動的介面，以及持續維護。 Log Analytics 和 Application Insights 的計算成本也很高，大量的並行查詢或清除 API 呼叫可能會對 Log Analytics 功能的其他所有互動造成負面影響。 不過，如果您必須收集個人資料，請遵循本節中的指導方針。

重要

雖然大部分的清除作業會更快完成， 但完成清除作業的正式 SLA 設定為 30 天 ，因為對數據平臺造成嚴重影響。 此 SLA 符合 GDPR 需求。 這是自動化流程，因此無法加速作業。

檢視和導出

使用 Log Analytics 查詢 API 或 Application Insights 查詢 API 來檢視和匯出數據要求。

您必須實作邏輯，將數據轉換成適當的格式，以傳遞至使用者。 Azure Functions 是裝載這類邏輯的絕佳位置。

刪除

警告

Log Analytics 中的刪除是不可逆的破壞性操作！ 在執行刪除時請特別謹慎。

Azure 監視器的 清除 API 可讓您刪除個人資料。 請謹慎使用清除作業，以避免潛在的風險、效能影響，以及扭曲Log Analytics資料的所有匯總、度量和其他層面的可能性。 如需處理個人資料的替代方法，請參閱個人資料處理策略一節。

清除是高度特殊許可權的作業。 由於數據遺失的可能性，請謹慎地授與 Azure Resource Manager 中的數據清除器角色。

為了管理系統資源，我們會將清除要求限制為每小時 50 個要求。 藉由傳送述詞包含需要清除的所有使用者身分識別的單一命令，來批次執行清除要求。 使用 in 運算子來指定多個身分識別。 執行清除要求之前，請先執行查詢，以確認預期的結果。

重要

使用 Log Analytics 或 Application Insights 清除 API 並不會影響您的保留成本。 若要降低保留成本，您必須減少數據保留期間。

記錄資料

  • 工作區 清除 POST API 會採用 物件，指定要刪除的數據參數，並傳回參考 GUID。

  • 取得 清除狀態 POST API 會傳回 'x-ms-status-location' 標頭，其中包含您可以呼叫的 URL，以判斷清除作業的狀態。 例如：

    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

應用程式資料

  • 元件 - 清除 POST API 會採用 物件，指定要刪除的數據參數，並傳回參考 GUID。

  • 元件 - 取得清除狀態 GET API 會傳回 'x-ms-status-location' 標頭，其中包含您可以呼叫的 URL，以判斷清除作業的狀態。 例如：

    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

下一步