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 ではデータのスキーマが規定されていますが、どのフィールドもカスタム値でオーバーライドできます。 カスタム スキーマを取り込むこともできます。 そのため、特定のワークスペースのどこに個人データがあるかを正確に述べることは不可能です。 しかし、インベントリの次の場所から手を着けるのが妥当です。

Note

以下に示すクエリの一部では、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 コマンドを使用します。

    search "<username or user ID>"

    人間が判読できるユーザー名だけでなく、特定のユーザーまでさかのぼって追跡できる GUID も検索するようにしてください。

  • デバイス ID: ユーザー ID と同様に、デバイス ID も個人データを見なされる場合があります。 ユーザー ID に対する上記のアプローチを使用して、個人データを保持するテーブルを特定します。

  • カスタム データ: 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

  • ユーザー ID: Application Insights では、session_Id、user_Id、user_AuthenticatedId、user_AccountId、customDimensions などのフィールドで、ユーザーとセッションの追跡用にランダムに生成された ID が既定で使用されます。 ただし、これらのフィールドは、アプリケーションに関連した ID (ユーザー名や Azure Active Directory GUID など) でオーバーライドされるのが一般的です。 こうした 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 や消去 API の同時呼び出しが大量に発生して、Log Analytics 機能に対する他のすべての操作に悪影響が生じる可能性があります。 その上で個人データを収集する必要がある場合は、このセクションのガイドラインに従ってください。

重要

ほとんどの消去操作ははるかに短い期間で完了しますが、データ プラットフォームへの影響が大きいために、消去操作の完了に関する正式な SLA は 30 日に設定されています。 この SLA は、GDPR の要件を満たしています。 これは自動化されたプロセスであるため、操作を迅速化することはできません。

表示とエクスポート

データ要求の表示とエクスポートには、Log Analytics クエリ API または Application Insights クエリ API を使用します。

データをユーザーへの配信に適した形式に変換するロジックを実装する必要があります。 Azure Functions は、そのようなロジックをホストするのに適した場所です。

削除

警告

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

Azure Monitor の消去 API を使用して個人データを削除することができます。 潜在的なリスクやパフォーマンスへの影響、Log Analytics データの総計や測定などを歪める可能性を避けるために、消去操作は控え目に使用してください。 個人データを処理する別のアプローチについては、「個人データの処理に関する戦略」セクションを参照してください。

消去は高い特権を必要とする操作です。 データ損失の可能性があるため、Azure Resource Manager でデータ消去者ロールを慎重に付与します。

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

ログ データ

  • ワークスペース消去 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

次のステップ