Azure Monitor ログは、個人データが見つかる可能性が高いデータ ストアです。 この記事では、Azure Monitor ログに個人データが格納される場所と、このデータを管理する方法について説明します。
注
個人データの表示または削除については、具体的な領域とニーズに応じて、「GDPR に関する一般的なデータ主体の要求」、「GDPR に関する Azure データ主体の要求」、「GDPR に関する Windows データ主体の要求」のいずれかを参照してください。 GDPR の詳細については、Microsoft Trust Center の GDPR に関するセクションおよび Service Trust Portal の GDPR に関するセクションをご覧ください。
個人データの処理に関する戦略
個人データを処理する際の戦略を策定するのはお客様とその会社ですが、技術的な観点からいくつかのアプローチを最も望ましいものから順に紹介します。
- データ 収集変換を使用して、収集されたデータを除外、難読化、匿名化、または調整して、"個人" と見なされないようにします。 "圧倒的" に望ましいのはこのアプローチです。このアプローチでは、コストがかかり影響も大きいデータ処理戦略を策定する必要がありません。
- データを正規化して、データ プラットフォームとパフォーマンスへの負の影響を軽減します。 たとえば、明示的なユーザー ID を記録するのではなく、ユーザー名とその詳細を内部 ID に関連付ける参照を作成し、別の場所に記録します。 これにより、ユーザーから個人情報の削除を求められた場合に、参照テーブルからそのユーザーに対応する行を削除するだけで済みます。
- 個人データを収集する必要がある場合:
- データの 削除 API または 消去 API と クエリ API を使用して、ユーザーに関連付けられている個人データをエクスポートおよび削除します。
- 概要ルールを使用して、より広く共有できる新しいテーブル内の個人データを削除または難読化し、テーブル レベルの読み取りアクセスを管理することで、個人データを使用してテーブルへのアクセスを制限します。
Azure Monitor ログで個人データを検索する場所
Azure Monitor ログでは、データにスキーマが規定されますが、すべてのフィールドをユーザー設定の値でオーバーライドできます。 カスタム スキーマを取り込むこともできます。 そのため、特定のワークスペースに個人データが存在する場所を正確に言うことは不可能です。 しかし、インベントリの次の場所から手を着けるのが妥当です。
注
この記事の一部のクエリでは、 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 に関して説明されている方法を使用して、個人データを保持するテーブルを識別します。
カスタム データ: Azure Monitor ログを使用すると、カスタム ログ、カスタム フィールド、 ログ インジェスト API、およびシステム イベント ログの一部として、カスタム データを収集できます。 すべてのカスタム データを調べて個人データがないかを確認します。
ソリューションによって収集されたデータ: ソリューションのメカニズムは変更可能であることから、コンプライアンスを確保するために、ソリューションで生成されたすべてのテーブルを確認することをお勧めします。
個人データのエクスポート、削除、または消去
私たちはデータ収集の方法変更を使用して個人データと見なされなくなるまで、個人データの収集を停止、フィルター処理、難読化、匿名化を行い、またはその他の変更を行うために、データ収集ポリシーを再構築することを強くお勧めします。 個人データの処理では、戦略の定義と自動化、顧客がデータを操作するためのインターフェイスの構築、および継続的なメンテナンスにコストが発生します。 Log Analytics と Application Insights では計算コストも高く、大量のクエリ、データの削除、または消去 API 呼び出しが同時に実行されると、Log Analytics 機能との他のすべての対話に悪影響を及ぼす可能性があります。 その上で個人データを収集する必要がある場合は、このセクションのガイドラインに従ってください。
注
データを削除または消去しても、課金には影響しません。 データ保持コストを制御するには、 データ保持設定を構成します。
表示とエクスポート
Log Analytics クエリ API を使用して、データ要求の表示とエクスポートを送信します。
注
基本テーブル プランと補助テーブル プランを持つテーブルでは、Log Analytics クエリ API を使用できません。 代わりに、 Search API を使用します。
データをユーザーへの配信に適した形式に変換するロジックを実装する必要があります。 Azure Functions は、そのようなロジックをホストするのに適した場所です。
削除
Azure Monitor ログのデータ削除 API を使用すると、Log Analytics ワークスペース内の特定のテーブルのデータを削除するための非同期要求を行うことができます。 データの削除操作は慎重に行い、潜在的なリスク、パフォーマンスへの影響、そして Log Analytics データの集計、測定、その他の側面を偏らせる可能性を回避してください。 個人データを処理する別のアプローチについては、「個人データの処理に関する戦略」セクションを参照してください。
一般データ保護規則 (GDPR) の要件に準拠する必要がある場合は、 Purge API を使用します。これはパフォーマンスが低く、GDPR コンプライアンスに必要な操作のみをサポートします。
警告
削除操作と消去操作は破壊的であり、元に戻すことはできません。 実行には細心の注意を払ってください。
粛清
Azure Monitor の Purge API を使用すると、GDPR で必要に応じて個人データを消去できます。 Purge API のパフォーマンスは、 データの削除 API よりも低くなります。 Azure Monitor では、データの削除 API を使用することをお勧めします。また、GDPR コンプライアンスに必要な消去要求のみを承認します。
システム リソースを管理するために、消去要求の数は 1 時間に 50 件に制限されています。 消去要求の実行をバッチ処理するには、消去が必要なすべてのユーザー ID を述語に含む 1 つのコマンドを送信します。 複数の ID を指定するには、in 演算子を使用します。 消去要求を実行する前にクエリを実行して、想定される結果になることを確認してください。
重要
ほとんどの消去操作ははるかに短い期間で完了しますが、データ プラットフォームへの影響が大きいために、消去操作の完了に関する正式な SLA は 30 日に設定されています。 この SLA は、GDPR の要件を満たしています。 これは自動化されたプロセスであるため、操作を迅速化することはできません。
必要な許可
アクション | 必要な許可 |
---|---|
Log Analytics ワークスペースからデータを削除する | Microsoft.OperationalInsights/workspaces/purge/action Log Analytics 共同作成者ロールと Data Purger 組み込みロールによって提供される Log Analytics ワークスペースへのアクセス許可 |
ログ データを消去する
ワークスペース消去 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
注
Basic および Auxiliary テーブル プランがあるテーブルからデータを消去することはできません。
次のステップ
- Azure Monitor のセキュリティについて説明します。
- Application Insights でデータがどのように収集され、処理され、セキュリティ保護されるかを詳しく確認します。