Azure Monitor 로그 및 Application Insights에서 개인 데이터 관리

Log Analytics는 개인 데이터를 찾을 수 있는 데이터 저장소입니다. Application Insights는 해당 데이터를 Log Analytics 파티션에 저장합니다. 이 문서에서는 Log Analytics 및 Application Insights가 개인 데이터를 저장하는 위치와 이 데이터를 관리하는 방법에 대해 설명합니다.

이 문서에서 로그 데이터는 Log Analytics 작업 영역으로 전송된 데이터를 나타내고 애플리케이션 데이터는 Application Insights에서 수집한 데이터를 나타냅니다. 작업 영역 기반 Application Insights 리소스를 사용하는 경우 로그 데이터에 대한 정보가 적용됩니다. 클래식 Application Insights 리소스를 사용하는 경우 애플리케이션 데이터가 적용됩니다.

참고 항목

개인 데이터를 보거나 삭제하는 방법에 대한 자세한 내용은 특정 영역 및 요구 사항에 따라 GDPR에 대한 일반 데이터 주체 요청, GDPR에 대한 Azure 데이터 주체 요청 또는 GDPR에 대한 Windows 데이터 주체 요청을 참조하세요. GDPR에 대한 자세한 내용은 Microsoft Trust Center의 GDPR 섹션 및 Service Trust 포털의 GDPR 섹션을 참조하세요.

필수 사용 권한

작업	필수 사용 권한
Log Analytics 작업 영역에서 데이터 제거	예를 들어 Log Analytics 기여자 기본 제공 역할에서 제공하는 Log Analytics 작업 영역에 대한 Microsoft.OperationalInsights/workspaces/purge/action 권한

개인 데이터 처리 전략

개인 데이터를 처리하기 위한 전략을 정의하는 것은 사용자와 사용자의 회사에 달려 있지만, 다음은 기술적인 관점에서 가장 선호되는 방식에서 가장 선호되지 않는 방식으로 나열한 몇 가지 방법입니다.

• 개인 데이터 수집을 중단하거나 수집된 데이터를 난독 처리, 익명화 또는 조정하여 "개인"으로 간주되지 않도록 합니다. 이는 훨씬 선호되는 방법이므로 비용이 많이 들고 영향력 있는 데이터 처리 전략을 만들 필요가 없습니다.
• 데이터 플랫폼 및 성능에 대한 부정적인 영향을 줄이기 위해 데이터를 정규화합니다. 예를 들어 명시적 사용자 ID를 로깅하는 대신 사용자 이름과 상관 관계가 있는 조회 및 어디서든 로깅될 수 있는 내부 ID에 대한 상세 정보를 만듭니다. 이렇게 하면 사용자가 개인 정보 삭제를 요청할 경우 조회 테이블에서 해당 사용자에 해당하는 행만 삭제할 수 있습니다.
• 개인 데이터를 수집해야 하는 경우 사용자와 관련된 모든 개인 데이터를 내보내고 제거해야 하는 의무를 충족하기 위해 제거 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
  

• 사용자 ID: 다양한 솔루션과 표에서 사용자 이름과 사용자 ID를 찾을 수 있습니다. 검색 명령을 사용하여 전체 데이터 세트에서 특정 사용자 이름 또는 사용자 ID를 찾을 수 있습니다.

  search "<username or user ID>"
  

  사람이 읽을 수 있는 사용자 이름뿐만 아니라 특정 사용자에게 다시 추적할 수 있는 GUID도 검색해야 합니다.

• 디바이스 ID: 사용자 ID와 마찬가지로 디바이스 ID도 개인 데이터로 간주되는 경우가 있습니다. 사용자 ID에 대해 위에 나열된 방법을 사용하여 개인 데이터를 보유하는 테이블을 식별합니다.

• 사용자 지정 데이터: Log Analytics를 사용하면 사용자 지정 로그, 사용자 지정 필드, HTTP Data Collector API를 통해 그리고 시스템 이벤트 로그의 일부로 사용자 지정 데이터를 수집할 수 있습니다. 개인 데이터에 대한 모든 사용자 지정 데이터를 확인합니다.

• 솔루션에서 캡처된 데이터: 솔루션 메커니즘은 개방되어 있으므로 솔루션에서 생성된 모든 테이블을 검토하여 준수 여부를 확인하는 것이 좋습니다.

애플리케이션 데이터

• IP 주소: Application Insights는 기본적으로 모든 IP 주소 필드를 0.0.0.0으로 난독 처리하지만 세션 정보를 유지 관리하기 위해 이 값을 실제 사용자 IP로 재정의하는 것이 일반적입니다. 아래 쿼리를 사용하여 지난 24시간 동안 0.0.0.0 이외의 IP 주소 열에 값이 포함된 테이블을 찾습니다.

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

• 사용자 ID: 기본적으로 Application Insights는 session_Id, user_Id, user_AuthenticatedId, user_AccountId 및 customDimensions 등의 필드에서 사용자 및 세션 추적을 위해 임의로 생성된 ID를 사용합니다. 그러나 사용자 이름 또는 Microsoft Entra GUID와 같이 애플리케이션과 더 관련이 있는 ID로 해당 필드를 재정의하는 것이 일반적입니다. 이러한 ID는 종종 개인 데이터로 간주됩니다. 이러한 ID를 난독 처리하거나 익명화하는 것이 좋습니다.

• 사용자 지정 데이터: 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 기능과의 다른 모든 상호 작용에 부정적인 영향을 미칠 수 있습니다. 그러나 개인 데이터를 수집해야 하는 경우 이 섹션의 지침을 따릅니다.

Important

대부분의 제거 작업은 훨씬 빨리 완료되지만 제거 작업 완료에 대한 공식 SLA는 데이터 플랫폼에 큰 영향을 미치기 때문에 30일로 설정됩니다. 이 SLA는 GDPR 요구 사항을 충족합니다. 자동화된 프로세스이므로 작업을 신속하게 처리할 방법이 없습니다.

보기 및 내보내기

데이터 요청을 보고 내보내려면 Log Analytics 쿼리 API 또는 Application Insights 쿼리 API를 사용합니다.

참고 항목

기본 및 보조 테이블 계획이 있는 경우에는 Log Analytics 쿼리 API를 사용할 수 없습니다. 대신 Log Analytics /search API를 사용합니다.

데이터를 사용자에게 배달하기 위해 적절한 형식으로 변환하는 논리를 구현해야 합니다. Azure Functions은 이러한 논리를 호스트하기에 좋은 곳입니다.

삭제

Warning

Log Analytics에서 삭제는 파괴적이고 복구할 수 없습니다! 실행할 때 특별히 유의하세요.

Azure Monitor의 제거 API를 사용하면 개인 데이터를 제거할 수 있습니다. 잠재적인 위험, 성능 영향 및 Log Analytics 데이터의 전체 집계, 측정 및 기타 측면을 왜곡할 가능성을 피하기 위해 제거 작업을 자주 사용하지 않습니다. 개인 데이터를 처리하는 다른 방법은 개인 데이터 처리 전략 섹션을 참조하세요.

제거는 높은 권한이 필요한 작업입니다. 데이터 손실 가능성이 있으므로 Azure Resource Manager에서 데이터 제거자 역할은 신중하게 부여합니다.

시스템 리소스를 관리하기 위해 제거 요청을 시간당 50개 요청으로 제한합니다. 제거가 필요한 모든 사용자 ID가 포함된 단일 명령을 전송하여 제거 요청 실행을 일괄 처리합니다. in 연산자를 사용하여 여러 ID를 지정합니다. 제거 요청을 실행하기 전에 쿼리를 실행하여 예상 결과를 확인합니다.

Important

Log Analytics 또는 Application Insights 제거 API를 사용하면 보존 비용에 영향을 미치지 않습니다. 보존 비용을 줄이려면 데이터 보존 기간을 줄여야 합니다.

로그 데이터

• 작업 영역 제거 POST API는 제거할 데이터 매개 변수를 지정하는 개체를 가져와 참조 GUID를 반환합니다.

• 제거 상태 가져오기 POST API는 제거 작업의 상태를 확인하기 위해 호출할 수 있는 URL이 포함된 'x-ms-status-location' 헤더를 반환합니다. 예시:

  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는 제거 작업의 상태를 확인하기 위해 호출할 수 있는 URL이 포함된 'x-ms-status-location' 헤더를 반환합니다. 예시:

  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에서 데이터를 수집, 처리 및 보호하는 방법에 대해 자세히 알아봅니다.