GDPR および CCPA のための Azure データ主体要求

データ主体要求 (DSR) の概要

欧州連合の一般データ保護規則 (GDPR) は、規制においてデータ主体と呼ばれる人に、雇用主または他の種類の機関や組織 (データ コントローラーまたは単にコントローラーと呼ばれます) によって収集された個人データを管理する権限を与えます。 GDPR における個人データは、特定された自然人または特定可能な自然人に関連するすべてのデータとして広範囲に定義されています。 GDPR では、個人データに対するデータ主体固有の権限が付与されます。このような権限には、個人データのコピーの取得、個人データの修正の要求、個人データの処理の制限、個人データの削除、または別のコントローラーに移動できる電子的な形式での個人データの受け取りが含まれます。 データ主体がコントローラーに対して個人データへのアクションを実行するよう正式に要求することを、データ主体の要求または DSR と呼びます。

同様に、カリフォルニア州消費者プライバシー法 (CCPA) では、個人情報の削除、アクセスおよび受信 (移植性) など、GDPR のデータ主体の権利に類似している権利を含む、カリフォルニア州の消費者のプライバシーの権利および義務を規定します。 CCPAはまた、特定の開示、権利の選択時の差別に対する保護、および「販売」として分類される特定のデータ転送に対する「オプトアウト/オプトイン」要件を提供します。売上は、重要な考慮事項のためにデータの共有を含むように広く定義されています。 CCPA の詳細については、「カリフォルニア州消費者プライバシー法」と「カリフォルニア州消費者プライバシー法に関する FAQ」を参照してください。

このガイドでは、コントローラーが DSR 要求に応じて個人データを検索して操作できるように Microsoft 製品、サービス、管理ツールを使用する方法について説明します。 具体的には、この情報には、Microsoft クラウドに存在する個人データを検索、アクセス、および操作する方法が含まれます。 このガイドに記載されているプロセスの概要を次に示します。

• 検出: 検索および検出ツールを使用して、DSR の対象である可能性がある顧客データを簡単に検索します。 可能性のある応答ドキュメントが収集されると、以下の手順に示す 1 つ以上の DSR アクションを実行して、要求に応答できます。 または、DSR への応答に関する組織のガイドラインを要求が満たしていないと判断する場合もあります。
• アクセス: Microsoft クラウドにある個人データを取り出し、要求がある場合は、データ主体が利用できるコピーを作成します。
• 修正: 必要に応じて、個人データを変更したり、要求された他の操作を個人データに対して実行したりします。
• 制限: さまざまな Azure サービスのライセンスを削除するか、可能な場合は該当するサービスを無効にすることで、個人データの処理を制限します。 また、データを Microsoft クラウドから削除してオンプレミスまたは別の場所で保持することもできます。
• 削除: Microsoft クラウドに格納されていた個人データを完全に削除します。
• エクスポート/受信 (移植性): 個人データまたは個人情報の電子コピー (コンピューターで読み取り可能な形式) をデータ主体に提供します。 CCPA における個人情報とは、識別された人、または識別可能な人に関するあらゆる情報のことです。 個人の私的、公的、または職業上の役割による区別はありません。 "個人情報" と定義された用語は、GDPR における "個人データ" とほぼ同義です。 ただし、CCPA では家族データおよび世帯データも含まれます。 CCPA の詳細については、「カリフォルニア州消費者プライバシー法」と「カリフォルニア州消費者プライバシー法に関する FAQ」を参照してください。

このガイドの各セクションでは、Microsoft クラウド内の個人データに関する DSR への対応としてデータ コントローラー組織が実行できる技術的な手順の概要を示します。

用語集

このガイドに関連する用語を以下に定義します。

• 管理者: 単独または他者と共同で、個人データの処理に関する目的と手段を決定する自然人や法人、公的機関、団体、その他の組織。そのような処理の目的と手段が EU 法もしくは加盟国の法律によって決定される場合、コントローラーまたはその指名に関する具体的な基準が EU 法または加盟国の法律によって提供される場合があります。
• 個人データおよびデータ主体: 特定されたまたは特定可能な自然人 ('データ主体') に関するあらゆる情報。特定可能な自然人とは、その者の名前、ID 番号、位置データ、オンライン ID、または当該自然人に固有の 1 つ以上の特に身体的、生理学的、遺伝的、心理的、経済的、文化的、社会的な識別情報などの要素を参照することにより、直接または間接的に特定することができる者のことです。
• 処理者: 管理者に代わって個人データを処理する自然人または法人、公的機関、団体、その他の組織。
• 顧客データ: これは、顧客または顧客の代理が エンタープライズ サービスの使用を通じて Microsoft に提供する、テキスト、音声、ビデオ、画像ファイル、およびソフトウェアを含むすべてのデータのことです。 顧客データには、エンド ユーザーの (1) 識別可能な情報 (Microsoft Entra ID のユーザー名と連絡先情報など) と、顧客が特定のサービスにアップロードまたは作成する顧客コンテンツ (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 Entra テナントに関連付けられている MSA アカウントに対する DSR の実行は、テナント内のデータにのみ関連します。 さらに、テナント内で MSA アカウントを処理する場合は、次の点を理解することが重要です。

• MSA ユーザーが Azure サブスクリプションを作成した場合、サブスクリプションは Microsoft Entra テナントであるかのように処理されます。 そのため、DSR は、上記のようにテナント内でスコープが設定されます。
• MSA アカウントを介して作成された Azure サブスクリプションが削除された場合、実際の MSA アカウントには 影響しません 。 前述のように、Azure サブスクリプション内で実行される DSR は、テナント自体のスコープに制限されます。

特定のテナントの外部にある MSA アカウント自体に対する DSR は、コンシューマー プライバシー ダッシュボードを介して実行されます。

第 1 部: 顧客データに関する DSR ガイド

顧客データに対する DSR の実行

Microsoft は、特定のサービス ( 製品内エクスペリエンスとも呼ばれます) の既存のアプリケーション プログラミング インターフェイス (API) またはユーザー インターフェイス (UI) を介して、Azure portal を介して特定の顧客データにアクセス、削除、エクスポートする機能を提供します。 このような製品内エクスペリエンスについての詳細は、各サービスのリファレンス ドキュメントに記載されています。

ステップ 1: 検出

DSR に対応する最初の手順は、要求の件名の個人データを見つけることです。 この最初の手順 (問題の個人データを見つけて確認する) は、DSR が DSR を尊重または拒否するための組織の要件を満たしているかどうかを判断するのに役立ちます。 たとえば、該当する個人データを検出して確認した後、その要求を実行すると他者の権利や自由が侵害される恐れがあるので、その要求は組織の要件に適合しないと判断する場合があるかもしれません。

データが見つかったら、データ主体の要求に対応するために特定の操作を実行できます。

Azure portal を介して管理される DSR

Microsoft Entra ID は、Microsoft のクラウドベースのマルチテナント ディレクトリと ID 管理サービスです。 Azure portal を使用して、顧客や従業員のユーザー プロファイル、Microsoft Entra ID 環境の個人データを含むユーザー作業情報など、エンド ユーザーの識別可能な情報を特定できます。

これは、特定のユーザーの個人データを検索または変更する場合に役立ちます。 ユーザー プロファイルや勤務先情報を追加したり、変更したりすることもできます。 ディレクトリのグローバル管理者のアカウントを使用してサインインする必要があります。

ユーザー プロファイルや勤務先情報を検出または表示する方法

1. ディレクトリのグローバル管理者であるアカウントを使用して Azure Portal にサインインします。

2. [ Microsoft Entra ID] を選択します。

3. [ユーザー] を選択します。

4. [すべてのユーザー] ブレードで、リストからユーザーを選択し、そのユーザーのブレードの [プロファイル] を選択すると、ユーザー プロファイル情報が表示されます。そこには個人データが含まれる可能性があります。

5. ユーザー プロファイル情報を追加または変更する必要がある場合は、コマンド バーの [編集] を選択し、追加または変更を行った後に、[保存] を選択します。

サービス API を介して管理される DSR

Microsoft は、既存のアプリケーション プログラミング インターフェイス (API) または特定のサービスのユーザー インターフェイス (UI) を介して顧客データを直接検出する機能を提供します。 詳細については、該当する CRUD (作成、読み取り、更新、削除) 操作について、各サービスのリファレンス ドキュメントで説明します。

ステップ 2: アクセス

DSR に対して応答性が高い可能性のある個人データを含む顧客データを見つけたら、データ主体に提供するデータを決定するのは、お客様と組織次第です。 実際のドキュメントのコピー、適切に編集されたバージョン、または共有するのが適切だと思われる部分のスクリーンショットを提供できます。 アクセス要求に対するこれらの各応答には、ドキュメントのコピー、または応答性のあるデータを含む他のアイテムのコピーを取得する必要があります。

データ主体にコピーを提供する際には、別のデータ主体に関する個人情報などの機密情報を削除または編集することが必要になる場合があります。

Azure portal を介して管理される DSR

お客様企業のテナント管理者はポータルと製品エクスペリエンスの両方を利用して、DSR アクセス要求を管理することができます。 DSR アクセス要求により、(a) エンド ユーザーに関する特定可能なデータ、および (b) システム生成ログを含むユーザーの個人データへのアクセスが可能になります。

サービス API を介して管理される DSR

Microsoft は、既存のアプリケーション プログラミング インターフェイス (API) または特定のサービスのユーザー インターフェイス (UI) を介して顧客データを直接検出する機能を提供します。 詳細については、該当する CRUD (作成、読み取り、更新、削除) 操作について、各サービスのリファレンス ドキュメントで説明します。

ステップ 3: 修正

データ主体が、組織のデータに存在する個人データの修正を求めた場合、担当者および組織は、その要求に応じることが適切かどうかを判断する必要があります。 データの訂正には、ドキュメントや他の種類のアイテムに含まれている個人情報の編集、修正、または削除などの処置が伴います。

Azure portal を介して管理される DSR

エンタープライズのお客様は、特定の Microsoft サービスの性質に応じて制限された編集機能を含め、DSR の修正要求を管理できます。 データ プロセッサとして、Microsoft はシステム生成ログを修正する機能を提供していません。これは、事実に基づくアクティビティを反映し、Microsoft サービス内のイベントの履歴レコードを構成するためです。 Microsoft Entra ID に関しては、以下で詳しく説明するように、エンド ユーザーに関する識別可能な情報を修正するための限定的な編集機能が存在します。

Microsoft Entra ID: 不正確または不完全な個人データを修正/修正する

Azure portal を使用して、Microsoft Entra ID 環境で、顧客と従業員のユーザー プロファイル、ユーザーの名前、仕事のタイトル、住所、電話番号などの個人データを含むユーザー作業情報など、エンド ユーザーに関する識別可能な情報を修正、更新、または削除できます。 ディレクトリのグローバル管理者のアカウントを使用してサインインする必要があります。

Microsoft Entra ID でユーザー プロファイルと作業情報を修正または更新するにはどうすればよいですか?

1. ディレクトリのグローバル管理者のアカウントを使用して Azure Portal にサインインします。

2. [ Microsoft Entra ID] を選択します。

3. [ユーザー] を選択します。

4. [すべてのユーザー] ブレードで、リストからユーザーを選択し、そのユーザーのブレードの [プロファイル] を選択して修正または更新が必要なユーザー プロファイル情報を表示します。

5. コマンド バーで [編集 ] を選択して、作業情報を含むユーザー プロファイル情報を修正または更新し、変更後に [保存 ] を選択します。

サービス API を介して管理される DSR

Microsoft は、既存のアプリケーション プログラミング インターフェイス (API) または特定のサービスのユーザー インターフェイス (UI) を介して顧客データを直接検出する機能を提供します。 詳細については、該当する CRUD (作成、読み取り、更新、削除) 操作について、各サービスのリファレンス ドキュメントで説明します。

ステップ 4: 制限

データ主体は個人データの処理を制限することを要求する場合があります。 Azure portal と既存のアプリケーション プログラミング インターフェイス (API) とユーザー インターフェイス (UI) の両方を提供します。 これらのエクスペリエンスを利用すると、お客様企業のテナント管理者は、データのエクスポートとデータの削除を組み合わせて、DSR を管理することができます。 お客様は (1) (a) アカウント、(b) システム生成ログ、および (c) 関連ログを含むユーザーの個人データの電子コピーをエクスポートすることができ、続いて (2) Microsoft システム内に存在するアカウントおよび関連付けられたデータが削除されます。

ステップ 5: 削除

組織のサポート データからの個人データの削除による「削除する権利」は GDPR における主要な保護の 1 つです。 個人データの削除には、監査ログ情報を除く、すべての個人データとシステム生成ログの削除が含まれます。 あるユーザーが回復可能削除 (下記を参照) されると、そのアカウントが 30 日間にわたり無効になります。 この 30 日間に何のアクションも行われない場合、そのユーザーは完全削除 (これも下記を参照) されます。 完全削除された場合、そのユーザーのアカウント、個人データ、システム生成ログがその後 30 日以内に抹消されます。 テナント管理者が即時に完全削除を発行した場合、ユーザーのアカウント、個人データ、システム生成ログがその後 30 日以内に抹消されます。

Azure Portal を介してユーザーおよび関連データを削除する

データ サブジェクトから削除要求を受け取った後、Azure Portal を使用してユーザーおよび関連する個人情報、さらにシステム生成ログを削除することができます。

このデータを削除することは、テナントからユーザーを削除することも意味します。 ユーザーは最初は論理的に削除されます。つまり、アカウントは、論理的な削除としてマークされてから 30 日以内にテナント管理者が回復できます。 30 日後、アカウントは自動的に、完全にテナントから削除されます。 その 30 日前に、ごみ箱から論理的に削除されたユーザーを手動で削除できます。

テナントからユーザーを削除する大まかな手順は次のとおりです。

1. Azure Portal に移動し、ユーザーを見つけます。

2. ユーザーを削除します。 ユーザーを最初に削除すると、ユーザーのアカウントがごみ箱に送信されます。 この時点で、ユーザーは論理的に削除されますが、Microsoft Entra ID から削除されません。

3. [最近削除されたユーザー] の一覧に移動し、ユーザーを完全に削除します。 この時点で、ユーザーは完全に削除されます (ハード削除とも呼ばれます)。つまり、アカウントは Microsoft Entra ID から削除されています

Azure テナントからユーザーを削除するには

1. ディレクトリのグローバル管理者のアカウントを使用して Azure Portal にサインインします。

2. [ Microsoft Entra ID] を選択します。

3. [ユーザー] を選択します。

4. 削除するユーザーの横にあるボックスをオンにして [ユーザーの削除] を選択し、ユーザー削除を確認するボックスで [はい] を選択します。

5. [ すべてのユーザー ] ブレードで、[ 削除されたユーザー] を選択します。

6. 同じユーザーをもう一度選択し、コマンド バーで [ 完全に削除 ] を選択し、確認するかどうかを確認するボックスで [ はい ] を選択します。

Azure テナントにアカウントがない場合にユーザーのデータを削除する

Azure テナントに削除できるアカウントを持っているユーザーもいますが、 ビジネス間 (B2B) 直接接続ユーザー は使用できません。 B2B 直接接続ユーザーは、ネイティブ ID を使用して、テナントでホストされているアプリとリソースへのテナント間アクセスを受け取ります。 テナントでゲスト アカウントを必要とせずに、ホーム テナントでホストされているユーザー アカウントを使用します。

これらのユーザーの DSR を受け入れるには、ユーザー アカウント自体ではなく、テナント内のユーザーに関連付けられている個人データを削除します。

1. Azure Portal を開き、[すべてのサービス] を選択し、フィルターに「policy」と入力して [ポリシー] を選択します。

2. [ ポリシー ] ブレードで、[ ユーザー プライバシー] を選択し、[ ユーザー要求の管理] を選択し、[ 削除要求の追加] を選択します。

3. [新しいデータの削除] 要求を完了します。

   • ユーザー。 削除を要求した Microsoft Entra ユーザーのメール アドレスを入力します。

4. [削除] を選択します。

削除要求は [保留中] 状態になります。 レポートの状態は、[ ユーザーのプライバシー>Overview ] ブレードで確認できます。

サービス API を介して管理される DSR 削除

Microsoft は、既存のアプリケーション プログラミング インターフェイス (API) または特定のサービスのユーザー インターフェイス (UI) を介して顧客データを直接検出する機能を提供します。 詳細については、該当する CRUD (作成、読み取り、更新、削除) 操作について、各サービスのリファレンス ドキュメントで説明します。

ステップ 6: エクスポート

「データ移植性の権利」により、データ主体は、別のデータ コントローラーに送信できる電子的な形式 (つまり構造化され、一般使用される、マシン読み取り可能かつ相互運用可能な形式) の個人データのコピーを要求できます。 Azure では、ユーザーの組織がネイティブ JSON 形式のデータを指定の Azure Storage コンテナーにエクスポートできるようにすることでこれをサポートしています。

Azure Portal を使用して管理される DSR

顧客データに関して、お客様企業のテナント管理者はポータルと製品エクスペリエンスの両方を利用して、エンド ユーザーに関する特定可能な情報のエクスポート要求を管理することができます。

サービス API を介して管理される DSR

Microsoft は、既存のアプリケーション プログラミング インターフェイス (API) または特定のサービスのユーザー インターフェイス (UI) を介して顧客データを直接検出する機能を提供します。 詳細については、該当する CRUD (作成、読み取り、更新、削除) 操作について、各サービスのリファレンス ドキュメントで説明します。

第 2 部: システム生成ログ

また、Microsoft は、テナント管理者に対して DSR を実行して、特定のシステム生成ログにアクセス、削除、およびエクスポートする機能も提供します。

システム生成ログに対する DSR の実行

テナント管理者は、Azure Portal を介して特定のシステム生成ログの DSR を実行したり、特定のサービスのプログラム インターフェイスまたはユーザー インターフェイスを介して直接実行したりできます。 詳細については、各サービスの参照ドキュメンテーションに記載されています。

手順 1: アクセス

テナント管理者は、システムによって生成されたログにキャプチャされた個人データに関連するデータ主体要求を実行できる組織内の唯一のユーザーです。 アクセス要求に対して取得されるデータは、コンピューターが読み取り可能な形式で提供され、ユーザーがデータに関連付けられているサービスを認識できるファイルで提供されます。 上記で説明したように、取得されるデータにはサービスのセキュリティを損なう可能性があるデータは含まれません。

Microsoft Entra ID を使用して管理されるシステム生成ログの DSR アクセス

お客様企業のテナント管理者は、ポータルおよび製品内エクスペリエンスを介してアクセス要求を管理できます。 アクセス要求では (a) エンド ユーザーに関する特定可能なデータ、および (b) サービス生成ログを含むユーザーの個人データへのアクセスが扱われます。 このプロセスは、パート 1 の「手順 2: Access」の「Microsoft Entra ID」セクションで説明されているプロセスと同じです。

サービス API を介して管理されるシステム生成ログの DSR アクセス

Microsoft は、既存のアプリケーション プログラミング インターフェイス (API) または特定のサービスのユーザー インターフェイス (UI) を介して顧客データを直接検出する機能を提供します。 詳細については、該当する CRUD (作成、読み取り、更新、削除) 操作について、各サービスのリファレンス ドキュメントで説明します。

ステップ 2: 削除

組織内で、Azure テナントの特定のユーザーに関する DSR 削除要求を実行できるのはテナント管理者だけです。

Azure Portal を使用して管理される DSR

お客様企業のテナント管理者はポータルと製品エクスペリエンスの両方を利用して、DSR 削除要求を管理することができます。 DSR 削除要求は、「第 1 部、ステップ 5: 削除の「Azure portal でユーザーと関連データを削除する」セクションで説明されているのと同じです。

サービス API を介して管理される DSR

Microsoft は、既存のアプリケーション プログラミング インターフェイス (API) または特定のサービスのユーザー インターフェイス (UI) を介して顧客データを直接検出する機能を提供します。 詳細については、該当する CRUD (作成、読み取り、更新、削除) 操作について、各サービスのリファレンス ドキュメントで説明します。

テナント内のゲストの DSR 削除

すべてのゲストは、 マイ アカウント - Organization (microsoft.com) で共同作業できる組織を確認できます。

ユーザーが [休暇] を選択した場合:

1. アカウントが B2B ゲスト アカウントの場合、テナント管理者アクセス許可を持つテナントからユーザーが削除されます。
2. アカウントが Direct Connect アカウント (EDDT) の場合、DSR スタックに "データの削除" 要求が発行されます。これはテナント管理者のアクセス許可に基づいて発行されます。

手順 3: エクスポート

テナント管理者は、システム生成ログにキャプチャされた個人データに関連するデータ主体要求を実行できる組織内の唯一のユーザーです。 エクスポート要求に対して取得されるデータは、コンピューターが読み取り可能な形式で提供され、ユーザーがデータに関連付けられているサービスを認識できるファイルで提供されます。 上記で説明したように、取得されるデータにはサービスのセキュリティまたは安定性を損なう可能性があるデータは含まれません。

Azure portal を介して管理される DSR

データ サブジェクトのエクスポート要求を受け取った後、Azure Portal を使用して、特定のユーザーに関連するシステム生成ログをエクスポートできます。

テナントからデータをエクスポートする大まかな手順は次のとおりです。

1. Azure Portal に移動し、ユーザーに代わってエクスポート要求を作成します。
2. データをエクスポートして、ファイルをユーザーに送ります。

Azure テナントからユーザーの情報をエクスポートするには

1. Azure portal を開き、[ すべてのサービス] を選択し、フィルターに「 ユーザー プライバシー」 と入力し、[ ユーザー プライバシー] を選択します。

2. [ ユーザー プライバシー] で、[ ユーザー要求の管理] を選択し、[ エクスポート要求の追加] を選択します。

3. [データ エクスポート要求] に次のように入力します。

• ユーザー。 エクスポートを要求した Microsoft Entra ユーザーのメール アドレスを入力します。
• サブスクリプション。 リソースの使用状況の報告とサービスの請求に使用するアカウントを選択します。 これは、Azure Storage アカウントの場所でもあります。
• ストレージ アカウント。 Azure Storage (Blob) の場所を選択します。 詳細については、「Microsoft Azure Storage の概要 – Blob ストレージ」の記事を参照してください。
• Container。 エクスポートされたユーザー プライバシー データの保存場所として新しいコンテナーを作成するか、既存のものを選択します。

4. [作成] を選択します。

エクスポート要求は [保留中] 状態になります。 レポートの状況は [ユーザー プライバシー - 概要] ブレードで確認できます。

サービス API を介して管理される DSR

Microsoft は、既存のアプリケーション プログラミング インターフェイス (API) または特定のサービスのユーザー インターフェイス (UI) を介して顧客データを直接検出する機能を提供します。 詳細については、該当する CRUD (作成、読み取り、更新、削除) 操作について、各サービスのリファレンス ドキュメントで説明します。

問題のエクスポートまたは削除について Microsoft に通知する方法

Azure portal からのデータのエクスポートまたは削除中に問題が発生した場合は、Azure portal の [ヘルプとサポート ] ブレードに移動し、[ サブスクリプションの管理] > [プライバシーとコンプライアンスの要求] の下にある新しいチケット > [プライバシー] ブレードと [GDPR 要求] に送信します。

詳細情報

• Microsoft Trust Center