管理 Azure 監視器 Log 和 Application Insights 中的個人資料

Log Analytics 是有望找到個人資料的資料存放區。 Application Insights 會將其資料儲存在 Log Analytics 分割區中。 本文說明 Log Analytics 和 Application Insights 儲存個人資料的位置，以及管理此資料的方式。

在本文中，記錄資料是指傳送至 Log Analytics 工作區的資料，而應用程式資料則是指 Application Insights 所收集的資料。 如果您使用以工作區為基礎的 Application Insights 資源，則會套用記錄資料的相關資訊。 如果您使用傳統 Application Insights 資源，則會套用應用程式資料。

需要的權限

個人資料處理策略

雖然是由您和貴公司來定義處理個人資料的策略，但以下為一些方法，從技術觀點出發並從最可取到最不推薦依序列出：

• 停止收集個人資料，或將收集的資料混淆處理、匿名化或加以調整，使其無法視為「個人」。 這是截至目前為止最推薦的方法，可讓您不必建立成本高且影響層面極大的資料處理策略。
• 將資料正規化，以減少對資料平臺和效能的負面影響。 例如，不是記錄明確的使用者識別碼，而是建立查閱，將使用者名稱及其詳細資料關聯至某個可於隨後記錄至他處的內部識別碼。 如此一來，如果使用者要求您刪除其個人資訊，您可以僅刪除查閱表格中對應至該使用者的資料列。
• 如果您需要收集個人資料，請使用清除 API 路徑和現有的查詢 API 來建置程式，以符合匯出和刪除與使用者相關聯的任何個人資料的所有義務。

Log Analytics 中的個人資料位於何處

Log Analytics 指定資料結構描述，但允許您覆寫每個含有自訂值的欄位。 您也可以內嵌自訂結構描述。 因此，很難確實指出個人資料在特定工作區中的存放位置。 不過，您可以先從以下位置開始清查。

記錄資料

• 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 覆寫此數值，維護工作階段資訊。 請使用以下查詢來尋找資料表，其 [IP 位址] 欄在過去 24 小時內包含 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 功能的所有其他互動產生負面影響。 不過如果必須收集個人資料，請遵循本節中的指導方針。

檢視和匯出

針對檢視和匯出資料的要求，均使用 Log Analytics 查詢 API 或 Application Insights 查詢 API。

您必須實作邏輯，將資料轉換成適當的格式以傳遞至使用者。 Azure Functions 很適合用來裝載這類邏輯。

刪除

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

清除是具有高度權限的作業。 在 Azure Resource Manager 中授與「資料清除者」角色時請小心，因為此動作可能會導致資料遺失。

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

記錄資料

• 工作區清除 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
  

下一步

• 深入了解 Log Analytics 收集、處理和保護資料的方式。
• 深入了解 Application Insights 收集、處理和保護資料的方式。