Log Analytics と Application Insights に格納される個人データに関するガイダンス

Log Analytics は、個人データが存在する可能性が高いデータ ストアです。 Application Insights では、そのデータが Log Analytics パーティションに格納されます。 この記事では、そのようなデータがよく存在する Log Analytics および Application Insights の場所と、そのようなデータを処理するために使用できる機能について説明します。

注意

この記事では、"ログ データ" とは Log Analytics ワークスペースに送信されるデータのことで、"アプリケーション データ" とは Application Insights によって収集されるデータのことです。 ワークスペースベースの Application Insights リソースを使用している場合は、ログ データに関する情報が適用されますが、クラシック Application Insights リソースを使用している場合は、アプリケーション データが適用されます。

注意

個人データの表示または削除については、「GDPR のための Azure データ サブジェクト要求」を参照してください。 GDPR の詳細については、Microsoft Trust Center の GDPR に関するセクションおよび Service Trust Portal の GDPR に関するセクションをご覧ください。

個人データの処理に関する戦略

プライベート データを処理する際の戦略を策定するとしたら、それを最終的に行うのはお客様とその会社になりますが、考えられるアプローチをいくつか以下に紹介します。 これらは、技術的な観点から優先するべき順序で (上位から下位へ) 記載されています。

  • 可能であれば、データの収集をやめるか、収集されるデータの難読化または匿名化を行う。そうでない場合は、"プライベート" と見なされるデータがなくなるよう、収集されるデータを調整する。 "圧倒的" に望ましいのはこのアプローチです。このアプローチでは、非常にコストがかかり影響も大きいデータ処理戦略を策定する必要がありません。
  • 不可能であれば、データの正規化を試みて、データ プラットフォームやパフォーマンスへの影響を軽減します。 たとえば、明示的なユーザー ID を記録するのではなく、ユーザー名と詳細が内部 ID に関連付けられる参照データを作成し、別の場所から記録できるようにします。 そうすることで、あるユーザーから個人情報の削除を依頼された場合に、そのユーザーに対応するルックアップ テーブルの行を削除するだけで済ませることができます。
  • 最後に、プライベート データを収集する必要がある場合は、消去 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
    
  • ユーザー ID:ユーザー ID は、さまざまなソリューションとテーブルで見つかります。 検索コマンドを使用して、データセット全体で特定のユーザー名を検索することができます。
    search "[username goes here]"
    
    人間が判読できるユーザー名だけでなく、特定のユーザーまで直接追跡できる GUID も忘れずに検索してください。
  • デバイス ID:ユーザー ID と同様、デバイス ID も "プライベート" と見なされる場合があります。 上に記載されているユーザー ID の場合と同じ方法を使用して、これが問題となるかもしれないテーブルを特定します。
  • カスタム データ:Log Analytics では、カスタム ログとカスタム フィールド、HTTP データ コレクター API、システムのイベント ログの一部として収集されるカスタム データなど、さまざまな方法による収集が可能です。 これらはすべてプライベート データを含んでいる可能性があり、そのようなデータが存在するかどうかを確認するために調べる必要があります。
  • ソリューションによって収集されたデータ: ソリューションのメカニズムは変更可能です。そのため、コンプライアンスを確保するために、ソリューションによって生成されたすべてのテーブルを確認することをお勧めします。

アプリケーション データ

  • IP アドレス:Application Insights は既定で、すべての IP アドレス フィールドを "0.0.0.0" に難読化しますが、セッション情報を保持しておくために、この値を実際のユーザー IP で上書きするのがかなり一般的なパターンです。 Analytics の次のクエリを使用すると、過去 24 時間にわたって、IP アドレス以外の列に "0.0.0.0" 以外の値が含まれるすべてのテーブルを検索できます。
    search client_IP != "0.0.0.0"
    | where timestamp > ago(1d)
    | summarize numNonObfuscatedIPs_24h = count() by $table
    
  • ユーザー ID:既定では、Application Insights は、ユーザーとセッションの追跡のために、ランダムに生成された ID を使用します。 しかし、これらのフィールドは、アプリケーションにとってより関連性の高い ID を格納するために上書きされるのが一般的です。 たとえば、ユーザー名や AAD GUID などです。これらの ID は多くの場合、個人データの範囲にあると見なされます。そのため、適切に処理する必要があります。 これらの ID については、常に難読化または匿名化を試みることをお勧めします。 これらの値がよく見つかるフィールドには、session_Id、user_Id、user_AuthenticatedId、user_AccountId、customDimensions などがあります。
  • カスタム データ:Application Insights では、どのデータ型にもカスタム ディメンションのセットを追加できます。 これらのディメンションは、どのような データでもありえます。 過去 24 時間にわたって収集されたすべてのカスタム ディメンションを識別するには、次のクエリを使用します。
    search * 
    | where isnotempty(customDimensions)
    | where timestamp > ago(1d)
    | project $table, timestamp, name, customDimensions 
    
  • メモリ内および転送中のデータ:Application Insights では、例外、要求、依存関係の呼び出し、およびトレースが追跡されます。 プライベート データは、多くの場合、コードや HTTP 呼び出しのレベルで収集できます。 例外、要求、依存関係、およびトレース テーブルを確認して、このようなデータをすべて識別します。 可能な場所ではテレメトリ初期化子を使用してこのデータを難読化します。
  • スナップショット デバッガーのキャプチャ:Application Insights の スナップショット デバッガー機能では、アプリケーションの実稼働インスタンスで例外がキャッチされるたびにデバッグのスナップショットを収集できます。 スナップショットでは、例外と、スタックに含まれるすべてのステップのローカル変数の値にたどり着く完全なスタック トレースが公開されます。 残念ながら、この機能では、スナップ ポイントを選択的に削除したり、スナップショット内のデータにプログラムからアクセスしたりすることができません。 そのため、既定のスナップショット保有期間のペースではお客様のコンプライアンス要件が満たされない場合は、この機能を無効にすることをお勧めします。

プライベート データをエクスポートして削除する方法

個人データの処理に関する戦略」セクションで先ほど述べたとおり、可能な場合はデータ収集ポリシーを再構築することが 強く 推奨されます。プライベート データの収集を無効にするか、難読化または匿名化を行ってください。そうでなければ、"プライベート" と見なされるデータがなくなるよう修正してください。 データの処理を行う場合、戦略を定義して自動化するコスト、顧客が問題なくデータを操作できるインターフェイスを作成するコスト、継続的なメンテナンス コストがまず、お客様とそのチームにかかります。 そのうえ、Log Analytics と Application Insights で多額の計算コストがかかります。また、クエリ API または消去 API の同時呼び出しが大量に発生して、Log Analytics 機能に対するすべての他の操作に悪影響が及ぶ可能性があります。 とは言うものの、実際には、プライベート データを収集する必要があるシナリオが有効な場合もあります。 このような場合、このセクションで説明されているとおりデータを処理する必要があります。

注意

この記事は、デバイスまたはサービスから個人データを削除する手順について説明しており、GDPR の下で義務を果たすために使用できます。 GDPR に関する一般情報については、Microsoft Trust Center の GDPR に関するセクションおよび Service Trust Portal の GDPR に関するセクションをご覧ください。

表示とエクスポート

データ要求の表示とエクスポートの両方に、Log Analytics クエリ API または Application Insights クエリ API を使用する必要があります。 必要な場合、ユーザーに提供するためにデータの形式を適切なものに変換するロジックを実装できます。 そのようなロジックをホストするには、Azure Functions が適しています。

重要

消去操作の大部分は SLA よりもずっと短期間に完了する場合がありますが、使用されるデータ プラットフォームへの影響が大きいため、消去操作の完了の正式な SLA は 30 日に設定されています。 この SLA は、GDPR の要件を満たしています。 これは自動化されたプロセスのため、操作処理の高速化を要求する方法はありません。

削除

警告

Log Analytics の削除は破壊的であり、元に戻せません。 実行には細心の注意を払ってください。

プライバシー処理の一環として、Microsoft は "消去" API パスを提供しています。 実行に関するリスク、パフォーマンスへの潜在的な影響、Log Analytics データの総集計や測定などにおけるスキューの発生の可能性があり、このパスは慎重に使用する必要があります。 プライベート データを処理する別のアプローチについては、「個人データの処理に関する戦略」セクションを参照してください。

注意

消去操作が実行されると、消去操作の状態が "保留中" の間はデータにアクセスできなくなります。

消去は高度な特権が必要な操作であり、Azure Resource Manager でロールが明示的に付与されない限り、Azure のアプリまたはユーザーは (リソース所有者でさえも) 実行のアクセス許可を得られません。 このロールは "データ消去者" であり、データ損失の可能性があるため慎重に委任する必要があります。

重要

システム リソースを管理するために、消去要求は 1 時間あたり 50 要求に制限されます。 消去要求の実行をバッチ処理するには、消去が必要なすべてのユーザー ID を述語に含む 1 つのコマンドを送信します。 複数の ID を指定するには、in 演算子を使用します。 消去要求を実行する前にクエリを実行して、想定される結果になることを確認するようにします。

Azure Resource Manager ロールが割り当てられると、2 つの新しい API パスが利用できるようになります。

ログ データ

  • POST purge - 削除するデータのパラメーターを指定するオブジェクトを受け取り、参照 GUID を返します

  • 消去状態の GET - 消去の POST 呼び出しは、"x-ms-status-location" ヘッダーを返します。ここには、消去 API の状態を確認するために呼び出せる 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
    

重要

ほとんどの消去操作は Microsoft の SLA よりもはるかに早く完了すると考えられます。しかし、Log Analytics によって使用されるデータ プラットフォームへの重大な影響があるため、消去操作の完了の正式な SLA は 30 日に設定されています

アプリケーション データ

  • POST purge - 削除するデータのパラメーターを指定するオブジェクトを受け取り、参照 GUID を返します

  • 消去状態の GET - 消去の POST 呼び出しは、"x-ms-status-location" ヘッダーを返します。ここには、消去 API の状態を確認するために呼び出せる 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
    

重要

消去操作の大部分は、Application Insights で使用されるデータ プラットフォームへの影響が大きいため、SLA よりもずっと短期間に完了する場合があります。消去操作の完了についての SLA は、30 日に設定されています

次のステップ