データ主体要求 (DSR) の概要
欧州連合一般データ保護規則 (GDPR) は、雇用主または他の種類の機関またはorganization (データ管理者または単なる管理者と呼ばれる) が収集する個人データを管理する権利を (データ主体として規制で知られている) 人に付与します。 GDPR は、個人データを、特定された自然人または特定可能な自然人に関連するデータとして広く定義します。 GDPR は、データ主体に個人データに対する特定の権利を付与します。 これらの権利には、個人データのコピーの取得、修正の要求、処理の制限、削除、または別の管理者に移動できるように電子形式で受け取ることが含まれます。 データ主体がコントローラーに対して個人データへのアクションを実行するよう正式に要求することを、データ主体の要求または DSR と呼びます。
同様に、カリフォルニア州消費者プライバシー法 (CCPA) は、カリフォルニア州の消費者にプライバシーの権利と義務を提供します。 これらの権利には、GDPR のデータ主体の権利に似た権利が含まれます。たとえば、個人情報を削除、アクセス、受信 (移植性) する権利などです。 また、CCPA では、特定の開示、権利の行使を選択する際の差別に対する保護、"売上" として分類された特定のデータ転送の "オプトアウト/オプトイン" 要件を規定します。 このドキュメントは、Microsoft の製品とサービスの使用における、GDPR および CCPA に基づくデータ主体の要求 (DSR) の完了に関する情報を提供します。
このガイドでは、Microsoft の製品、サービス、管理ツールを使用して、コントローラーのお客様が DSR に対応するために個人データを見つけて対処する方法について説明します。 具体的には、この情報には、Microsoft クラウドに存在する個人データを検索、アクセス、および操作する方法が含まれます。 このガイドに記載されているプロセスの概要を次に示します。
- 発見： 検索ツールと検出ツールを使用すると、DSR の対象となる可能性のある顧客データをより簡単に見つけることができます。 応答性の高い可能性のあるドキュメントを収集したら、次の手順で説明する 1 つ以上の DSR アクションを実行して、要求に応答できます。 または、要求が DSR に応答するためのorganizationのガイドラインを満たしていないと判断することもできます。
- アクセス： Microsoft クラウドに存在する個人データを取得し、要求された場合は、データ主体がアクセスできるコピーを作成します。
- 修正: 必要に応じて、個人データを変更したり、要求された他の操作を個人データに対して実行したりします。
- 制限: さまざまな Azure サービスのライセンスを削除するか、可能な場合は該当するサービスを無効にすることで、個人データの処理を制限します。 また、データを Microsoft クラウドから削除してオンプレミスまたは別の場所で保持することもできます。
- 削除: Microsoft クラウドに格納されていた個人データを完全に削除します。
- エクスポート/受信 (移植性): 個人データまたは個人情報の電子コピー (コンピューターで読み取り可能な形式) をデータ主体に提供します。
このガイドの各セクションでは、Microsoft クラウド内の個人データに関する DSR への対応としてデータ コントローラー組織が実行できる技術的な手順の概要を示します。
用語
このガイドに関連する定義を次に示します。
- コント ローラー： 個人データの処理の目的と手段を単独または共同で決定する、自然人または法人、公的機関、機関、またはその他の機関。 そのような処理の目的と手段が、連合または加盟国の法律、コントローラー、またはその指名のための特定の基準によって決定される場合は、連合または加盟国の法律によって提供される場合があります。
- 個人データとデータ主体: 特定または識別可能な自然人 ('データ主体') に関連する情報。 識別可能な自然人とは、特に、名前、識別番号、位置情報、オンライン識別子などの識別子、またはその自然人の物理的、生理的、遺伝的、精神的、経済的、文化的、または社会的アイデンティティに固有の 1 つ以上の要因を参照して、直接的または間接的に識別できる人です。
- 処理者: 管理者に代わって個人データを処理する自然人または法人、公的機関、団体、その他の組織。
- 顧客データ: エンタープライズ サービスの使用を通じて、お客様が Microsoft に提供するすべてのテキスト、サウンド、ビデオ、またはイメージ ファイル、ソフトウェアを含むすべてのデータ。 顧客データには、エンド ユーザーの (1) 識別可能な情報 (たとえば、Microsoft Entra IDのユーザー名と連絡先情報) と (2) 顧客が特定のサービスにアップロードまたは作成する顧客コンテンツ (たとえば、Azure Storage アカウントの顧客コンテンツ、Azure SQL Database の顧客コンテンツ、顧客の仮想マシン イメージなど) の両方が含まれます。Azure Virtual Machines)。
- システム生成ログ: Microsoft がエンタープライズ サービスをユーザーに提供するうえで役立つ、Microsoft により生成されるログおよび関連データ。 システム生成ログには、主に一意識別子などの仮名化されたデータが含まれます。 通常、システムによって生成された数値は、個人を識別することはできませんが、エンタープライズ サービスをユーザーに提供するために使用されます。 システム生成ログには、エンド ユーザーに関する識別可能な情報 (ユーザー名など) も含まれている場合があります。
このガイドの使用方法
このガイドは次のような 2 部構成になっています。
- パート 1: 顧客データに対するデータ主体の要求への応答: このガイドのパート 1 では、データを作成したアプリケーションからデータにアクセス、修正、制限、削除、エクスポートする方法について説明します。 このセクションでは、カスタマー コンテンツとエンド ユーザー個人情報の両方に対して DSR を実行する方法について詳しく述べます。
- 第 2 部: システム生成ログに関するデータ主体の要求に対応する: Microsoft のエンタープライズ サービスを利用する際、Microsoft がサービスを提供するために使われるシステム生成ログという情報が生成されます。 このガイドの第 2 部では、Azure でこのような情報にアクセスしたり、削除したり、エクスポートしたりする方法について説明します。
Microsoft Entra IDおよび Microsoft サービス アカウントの DSR について
拡張ディレクトリ ダイレクト トークン (EDDT) を使用すると、テナント内のゲスト ユーザーは複数のテナント間で DSR を開始できます。 ユーザーによって開始された DSR は、対応するテナント管理者によってユーザーが承認されているすべてのテナントに対して実行されます。
また、エンタープライズ顧客に提供されるサービスのコンテキスト内の Microsoft サービス アカウント (MSA) にも同じプロセスが適用されます。 Microsoft Entra テナントに関連付けられている MSA アカウントに対する DSR の実行は、テナント内のデータにのみ関連します。 さらに、テナント内で MSA アカウントを処理する場合は、次の点を理解することが重要です。
- MSA ユーザーがAzure サブスクリプションを作成した場合、サブスクリプションはMicrosoft Entra テナントであるかのように処理されます。 そのため、DSR は、上記のようにテナント内でスコープが設定されます。
- MSA アカウントを介して作成されたAzure サブスクリプションが削除された場合、実際の MSA アカウントには影響しません。 前述のように、Azure サブスクリプション内で実行される DSR は、テナント自体のスコープに制限されます。
ユーザーは、コンシューマー プライバシー ダッシュボードを使用して、特定のテナントの外部にある MSA アカウント自体に対して DSR を実行します。
第 1 部: 顧客データに関する DSR ガイド
顧客データに対する DSR の実行
Microsoft は、特定のサービス (製品内エクスペリエンスとも呼ばれます) の既存のアプリケーション プログラミング インターフェイス (API) またはユーザー インターフェイス (UI) を介して、Azure portalを介して特定の顧客データにアクセス、削除、エクスポートする機能を提供します。 このような製品内エクスペリエンスについての詳細は、各サービスのリファレンス ドキュメントに記載されています。
重要
製品内の DSR をサポートするサービスは、サービスのアプリケーション プログラミング インターフェイス (API) またはユーザー インターフェイス (UI) を直接使用して、適切な CRUD (作成、読み取り、更新、削除) 操作を記述する必要があります。 特定のデータ主体に対する完全な要求を完了するには、Azure portal内での DSR の実行に加えて、特定のサービス内で DSR を実行する必要があります。 詳細については、特定のサービスのリファレンス ドキュメントを参照してください。
ステップ 1: 検出
DSR への応答の最初の手順は、要求でカバーされる個人データを見つけることです。 個人データを見つけて確認すると、DSR が DSR を尊重または拒否するためのorganizationの要件を満たしているかどうかを判断するのに役立ちます。 たとえば、個人データを見つけて確認した後、要求がorganizationの要件を満たしていないと判断する場合があります。これは、要求を満たすことが他者の権利と自由に悪影響を及ぼす可能性があるためです。
データを見つけたら、特定のアクションを実行して、データ主体による要求を満たすことができます。
AZURE PORTALを介して管理される DSR
Microsoft Entra IDは、Microsoft のクラウドベースのマルチテナント ディレクトリと ID 管理サービスです。 Azure portalを使用して、顧客と従業員のユーザー プロファイルや、Microsoft Entra ID環境内の個人データを含むユーザーの作業情報など、エンド ユーザーの識別可能な情報を特定できます。
この情報は、特定のユーザーの個人データを検索または変更する場合に役立ちます。 ユーザー プロファイルや勤務先情報を追加したり、変更したりすることもできます。 ディレクトリのグローバル管理者のアカウントを使用してサインインする必要があります。
ユーザー プロファイルや勤務先情報を検出または表示する方法
- ディレクトリのグローバル管理者であるアカウントを使用して Azure Portal にサインインします。
- [Microsoft Entra ID] を選択します。
- [ユーザー] を選択します。
- [ すべてのユーザー ] ブレードで、一覧からユーザーを選択します。 選択したユーザーのブレードで、[ プロパティ ] を選択して、個人データを含む可能性があるユーザー プロファイル情報を表示します。
- ユーザー プロファイル情報を追加または変更する必要がある場合は、コマンド バーで [プロパティの編集 ] を選択し、変更後に [保存 ] を選択します。
サービス API を介して管理される DSR
Microsoft は、既存のアプリケーション プログラミング インターフェイス (API) または特定のサービスのユーザー インターフェイス (UI) を介して顧客データを直接検出する機能を提供します。 詳細については、該当する CRUD (作成、読み取り、更新、削除) 操作について、各サービスのリファレンス ドキュメントで説明します。
ステップ 2: アクセス
DSR に応答する可能性のある個人データを含む顧客データを見つけたら、お客様とorganizationは、データ主体に提供するデータを決定します。 実際のドキュメントのコピー、適切に編集されたバージョン、または共有するのが適切と思われる部分のスクリーンショットを提供できます。 アクセス要求に対するこれらの各応答について、ドキュメントまたは応答性の高いデータを含むその他のアイテムのコピーを取得する必要があります。
データ主体にコピーを提供する場合、他のデータ主体および機密情報に関する個人情報を削除または編集することが必要になる場合があります。
AZURE PORTALを介して管理される DSR
Microsoft では、ポータルと製品内エクスペリエンスの両方を提供し、エンタープライズ顧客のテナント管理者に DSR アクセス要求を管理する機能を提供します。 DSR Access 要求を使用すると、エンド ユーザーとシステムによって生成されたログに関する識別可能な情報など、ユーザーの個人データにアクセスできます。
サービス API を介して管理される DSR
Microsoft は、既存のアプリケーション プログラミング インターフェイス (API) または特定のサービスのユーザー インターフェイス (UI) を介して顧客データを直接検出する機能を提供します。 詳細については、該当する CRUD (作成、読み取り、更新、削除) 操作について、各サービスのリファレンス ドキュメントで説明します。
ステップ 3: 修正
データ主体から、organizationのデータに存在する個人データの修正を求められた場合、お客様とorganizationは、要求を受け入れるのが適切かどうかを判断する必要があります。 データの修正には、ドキュメントやその他の種類やアイテムから個人データを編集、編集、削除するなどのアクションが含まれる場合があります。
AZURE PORTALを介して管理される DSR
エンタープライズのお客様は、特定の Microsoft サービスの性質に応じて制限された編集機能を含む DSR 修正要求を管理できます。 データ プロセッサとして、Microsoft はシステム生成ログを修正する機能を提供していません。これは、事実に基づくアクティビティを反映し、Microsoft サービス内のイベントの履歴レコードを構成するためです。 Microsoft Entra IDの場合、次のセクションでさらに説明するように、エンド ユーザーに関する識別可能な情報を修正するために、制限付き編集機能が存在します。
Microsoft Entra ID: 不正確または不完全な個人データを修正または修正する
Azure portalを使用して、エンド ユーザーに関する識別可能な情報 (顧客と従業員のユーザー プロファイル、ユーザーの名前、仕事のタイトル、住所、電話番号など) を含むユーザーの作業情報を、Microsoft Entra ID環境で修正、更新、または削除できます。 ディレクトリのグローバル管理者ロールに割り当てられているアカウントでサインインする必要があります。
Microsoft Entra IDでユーザー プロファイルと作業情報を修正または更新操作方法。
- ディレクトリのグローバル管理者のアカウントを使用して Azure Portal にサインインします。
- [Microsoft Entra ID] を選択します。
- [ 管理 ] タブを展開し、[ユーザー] を選択 します。
- [ すべてのユーザー ] ブレードで、一覧からユーザーを選択します。 選択したユーザーのブレードで、[ プロパティ ] を選択して、修正または更新する必要があるユーザー プロファイル情報を表示します。
- コマンド バーで [ プロパティの編集 ] を選択して、作業情報を含むユーザー プロファイル情報を修正または更新します。 変更後に [保存] を選択します 。
サービス API を介して管理される DSR
Microsoft は、既存のアプリケーション プログラミング インターフェイス (API) または特定のサービスのユーザー インターフェイス (UI) を介して顧客データを直接検出する機能を提供します。 詳細については、該当する CRUD (作成、読み取り、更新、削除) 操作について、各サービスのリファレンス ドキュメントで説明します。
ステップ 4: 制限
データ主体は、個人データの処理を制限することを要求する場合があります。 Microsoft では、Azure portalと既存のアプリケーション プログラミング インターフェイス (API) またはユーザー インターフェイス (UI) の両方を提供しています。 これらのエクスペリエンスを利用すると、お客様企業のテナント管理者は、データのエクスポートとデータの削除を組み合わせて、DSR を管理することができます。 お客様は、(1) アカウント、(b) システム生成ログ、(c) 関連ログなど、ユーザーの個人データの電子コピーをエクスポートし、(2) Microsoft システム内に存在するアカウントと関連データを削除できます。
ステップ 5: 削除
GDPR は、organizationの顧客データから個人データを削除することを要求することで、"消去する権利" を保護します。 個人データの削除には、監査ログ情報を除く、すべての個人データとシステム生成ログの削除が含まれます。 ユーザーを 論理的に削除 する場合 (以下の詳細を参照)、アカウントを 30 日間無効にします。 この 30 日間に何のアクションも行われない場合、そのユーザーは完全削除 (これも下記を参照) されます。 完全削除された場合、そのユーザーのアカウント、個人データ、システム生成ログがその後 30 日以内に抹消されます。 テナント管理者が即時に完全削除を発行した場合、ユーザーのアカウント、個人データ、システム生成ログがその後 30 日以内に抹消されます。
重要
ユーザーをテナントから削除するには、テナント管理者でなければなりません。
Azure Portal を介してユーザーおよび関連データを削除する
データ主体の削除要求を受け取ったら、Azure portalを使用して、ユーザーと関連する個人情報とシステム生成ログの両方を削除します。
このデータを削除することは、テナントからユーザーを削除することも意味します。 ユーザーは最初は論理的に削除されます。つまり、アカウントは、論理的な削除としてマークされてから 30 日以内にテナント管理者が回復できます。 30 日後、アカウントは自動的に削除され、テナントから完全に削除されます。 その 30 日前に、ごみ箱から論理的に削除されたユーザーを手動で削除できます。
Azure テナントからユーザーを削除するには
- ディレクトリのグローバル管理者のアカウントを使用して Azure Portal にサインインします。
- [Microsoft Entra ID] を選択します。
- [ 管理 ] タブを展開し、[ユーザー] を選択 します。
- 削除するユーザーの横にあるボックスをオンにして [ユーザーの削除] を選択し、ユーザー削除を確認するボックスで [はい] を選択します。
- [ すべてのユーザー ] ブレードで、[ 管理 ] タブを展開し、[ 削除されたユーザー] を選択します。
- 同じユーザーをもう一度選択し、コマンド バーで [ 完全に削除 ] を選択し、確認するかどうかを確認するボックスで [ はい ] を選択します。
重要
[はい] をクリックすると、ユーザーと関連付けられているすべてのデータとシステム生成ログが完全かつ取り消し不能に削除されます。 間違えた場合は、ユーザーを手動でテナントに追加し直す必要があります。 関連付けられたデータとシステム生成のログは回復できません。
Azure テナントにアカウントがない場合にユーザーのデータを削除する
一部のユーザーは削除できるアカウントをAzureテナントに持っているが、ビジネス間 (B2B) 直接接続ユーザーは使用しない。 B2B 直接接続ユーザーは、ネイティブ ID を使用して、テナントでホストされているアプリとリソースへのテナント間アクセスを受け取ります。 テナントでゲスト アカウントを必要とせずに、ホーム テナントでホストされているユーザー アカウントを使用します。
これらのユーザーの DSR を尊重するには、ユーザー アカウント自体ではなく、テナント内のユーザーに関連付けられている個人データを削除します。
Azure portalを開き、[すべてのサービス] を選択し、フィルターに「ユーザー プライバシー」と入力し、[ユーザー プライバシー] を選択します。
[ 概要 ] ブレードで、[ 削除要求の追加] を選択します。
[新しいデータの削除] 要求フォームに入力します。
- ユーザー: 削除を要求したMicrosoft Entra ID ユーザーのメール アドレスを入力します。
[削除] を選択します。
削除要求は [保留中] 状態になります。 レポートの状態は、[ ユーザーのプライバシー>Overview ] ブレードで確認できます。
重要
個人データは複数のシステムから取得される可能性があるため、削除プロセスが完了するまでに最大 1 か月かかる場合があります。
ユーザーの削除、ユーザーの一括削除、Entra ID からのテナントの削除の詳細については、次のガイダンスを参照してください。
サービス API を介して管理される DSR 削除
Microsoft は、既存のアプリケーション プログラミング インターフェイス (API) または特定のサービスのユーザー インターフェイス (UI) を介して顧客データを直接検出する機能を提供します。 詳細については、該当する CRUD (作成、読み取り、更新、削除) 操作について、各サービスのリファレンス ドキュメントで説明します。
ステップ 6: エクスポート
"データの移植性の権利" により、データ主体は、別のデータ コントローラーに送信できる "構造化された、一般的に使用される、コンピューターが読み取り可能で、相互運用可能な形式" の電子形式で個人データのコピーを要求できます。 Azureでは、organizationでネイティブ JSON 形式のデータを指定された Azure Storage Container にエクスポートできるようにすることで、この権限をサポートしています。
重要
ユーザー データをテナントからエクスポートするには、テナント管理者である必要があります。
AZURE PORTALを介して管理される DSR
顧客データの場合、Microsoft はポータルと製品内エクスペリエンスの両方を提供し、エンタープライズ顧客のテナント管理者は、エンド ユーザーに関する特定可能な情報のエクスポート要求を管理する機能を提供します。
サービス API を介して管理される DSR
Microsoft は、既存のアプリケーション プログラミング インターフェイス (API) または特定のサービスのユーザー インターフェイス (UI) を介して顧客データを直接検出する機能を提供します。 詳細については、該当する CRUD (作成、読み取り、更新、削除) 操作について、各サービスのリファレンス ドキュメントで説明します。
第 2 部: システム生成ログ
また、Microsoft は、テナント管理者に対して DSR を実行して、特定のシステム生成ログにテナント管理者としてアクセス、削除、およびエクスポートする機能も提供します。
重要
システム生成ログを制限または修正する機能はサポートされていません。 システム生成ログは、Microsoft クラウドと診断データ内で実行される事実に基づくアクションを構成します。 このようなデータを変更すると、アクションの履歴が損なわれ、詐欺やセキュリティ リスクが増加します。
システム生成ログに対する DSR の実行
テナント管理者は、Azure portalを介して特定のシステム生成ログの DSR を実行したり、特定のサービスのプログラム ユーザー インターフェイスを介して直接実行したりできます。 詳細については、各サービスの参照ドキュメンテーションに記載されています。
重要
製品内の DSR をサポートするサービスは、サービスのアプリケーション プログラミング インターフェイス (API) またはユーザー インターフェイス (UI) を直接使用する必要があります。 特定のデータ主体に対する完全な要求を完了するには、Azure ポータル内での DSR の実行に加えて、製品内 DSR の実行を行う必要があります。詳細については、特定のサービスのリファレンス ドキュメントを参照してください。
手順 1: アクセス
システム生成ログにキャプチャされた個人データに関連するデータ主体要求を実行できるのは、organizationのテナント管理者だけです。 アクセス要求に対して取得されるデータは、コンピューターが読み取り可能な形式であり、データが関連付けられているサービスを示すファイルに格納されます。 前に説明したように、取得されたデータには、サービスのセキュリティを侵害する可能性のあるデータは含まれません。
Microsoft Entra IDを介して管理されるシステム生成ログの DSR アクセス
Microsoft では、エンタープライズ顧客のテナント管理者にアクセス要求を管理する機能を提供するポータルと製品内エクスペリエンスの両方を提供します。 アクセス要求を使用すると、エンド ユーザーとサービスによって生成されたログに関する特定可能な情報を含む、ユーザーの個人データへのアクセスが許可されます。 このプロセスは、「パート 1:手順 2: Access」の「Microsoft Entra ID」セクションで説明されているプロセスと同じです。
サービス API を介して管理されるシステム生成ログの DSR アクセス
Microsoft は、既存のアプリケーション プログラミング インターフェイス (API) または特定のサービスのユーザー インターフェイス (UI) を介して顧客データを直接検出する機能を提供します。 詳細については、該当する CRUD (作成、読み取り、更新、削除) 操作について、各サービスのリファレンス ドキュメントで説明します。
手順 2: 削除
テナント管理者のみが、Azure テナント内の特定のユーザーに対して DSR 削除要求を実行できます。
AZURE PORTALを介して管理される DSR
Microsoft では、ポータルと製品内エクスペリエンスの両方を提供し、エンタープライズ顧客のテナント管理者に DSR 削除要求を管理する機能を提供します。 DSR 削除要求は、「パート 1:手順 5: 削除」の「Azure portalセクションを使用してユーザーと関連付けられたデータを削除する」で説明されているのと同じプロセスに従います。
サービス API を介して管理される DSR
Microsoft は、既存のアプリケーション プログラミング インターフェイス (API) または特定のサービスのユーザー インターフェイス (UI) を介して顧客データを直接検出する機能を提供します。 詳細については、該当する CRUD (作成、読み取り、更新、削除) 操作について、各サービスのリファレンス ドキュメントで説明します。
テナント内のゲストの DSR 削除
すべてのゲストは、[ マイ アカウント ] - [組織] (microsoft.com) で共同作業できる組織を確認できます。
ユーザーが [休暇] を選択した場合:
B2B コラボレーション ユーザーがorganizationを離れると、ディレクトリ ソフトによってユーザーのアカウントが削除されます。 既定では、ユーザー オブジェクトはMicrosoft Entra IDの [削除済みユーザー] 領域に移動しますが、永続的な削除は 30 日間開始されません。 この論理的な削除により、ユーザーがアカウントを完全に削除する前にアカウントの復元を要求した場合、管理者はグループやアクセス許可を含むユーザー アカウントを復元できます。
必要に応じて、テナント管理者は、次の手順を使用して、論理的に削除された期間中にいつでもアカウントを完全に削除できます。 このアクションは取り消し不可能です。
- 外部 ID プロバイダー管理者としてMicrosoft Entra 管理センターにサインインします。
- [Id>Users>すべてのユーザー] に移動します。 1. [ 削除されたユーザー] を選択します。 1. 削除されたユーザーの [チェック] ボックスを選択し、[完全に削除] を選択します。
完全削除は管理者が開始するか、論理的な削除期間の終了時に自動的に行われます。 完全削除は、データの削除に最大で 30 日かかることがあります。
B2B 直接接続ユーザーの場合、ユーザーが [確認メッセージに 残す ] を選択するとすぐにデータの削除が開始され、完了するまでに最大 30 日かかることがあります。
手順 3: エクスポート
システム生成ログにキャプチャされた個人データに関連するデータ主体要求を実行できるのは、テナント管理者だけです。 エクスポート要求に対して取得されるデータは、コンピューターが読み取り可能な形式であり、データが関連付けられているサービスを示すファイルに含まれています。 前に説明したように、取得されたデータには、サービスのセキュリティまたは安定性を損なう可能性のあるデータは含まれません。
AZURE PORTALを介して管理される DSR
データ主体のエクスポート要求を受け取ったら、管理ポータルを使用してログをダウンロードします。 ポータル内のログのダウンロードの詳細については、「Microsoft Entra ID でログをダウンロードする方法 - Microsoft Entra ID |Microsoft Learn。
テナント管理者は、 Microsoft Data Log Export を使用してシステム生成ログをエクスポートすることもできます。 テナント管理者は、[ エクスポート要求の追加] を選択し、次のフィールドに入力する必要があります。
- ユーザーの種類: ユーザーが B2B コラボレーション ユーザーか B2B 直接接続ユーザーか選択します。
- ユーザー: エクスポートを要求したMicrosoft Entra ID ユーザーのメール アドレスを入力します。
- Azureサブスクリプション: リソースの使用状況を報告し、サービスに対して課金するために使用するアカウントを選択します。 このアカウントは、Azure ストレージ アカウントの場所でもあります。
- ストレージ アカウント: Azure Storage (BLOB) の場所を選択し、[作成] を選択します。 詳細については、「Microsoft Azure Storageの概要 - BLOB ストレージ」を参照してください。
エクスポート要求は [保留中] 状態になります。 レポートの状態は、[ ユーザーのプライバシー] [概要 ] ブレードで確認できます。
重要
個人データは複数のシステムから取得できるため、エクスポート プロセスが完了するまでに最大 1 か月かかることがあります。
サービス API を介して管理される DSR
Microsoft は、既存のアプリケーション プログラミング インターフェイス (API) または特定のサービスのユーザー インターフェイス (UI) を介して顧客データを直接検出する機能を提供します。 詳細については、該当する CRUD (作成、読み取り、更新、削除) 操作について、各サービスのリファレンス ドキュメントで説明します。
管理されていないテナントのメンバーである場合(つまり、グローバル管理者がいない場合)、独自の個人データをエクスポートおよび削除できます。 Power Automate ライセンスを持つMicrosoft Entra アカウントが必要です。 詳細については、「個人データ要求への応答 (Microsoft Entra ID)」を参照してください。
問題のエクスポートまたは削除について Microsoft に通知する方法
Azure portalからのデータのエクスポートまたは削除中に問題が発生した場合は、[Azure portal ヘルプとサポート] ブレードに移動します。 [ サブスクリプションの管理>None of the above>Problem Type>Privacy とコンプライアンス要求のサブスクリプション>Problem サブタイプ>Privacy Blade および GDPR 要求の新しいチケットを送信します。