このガイドでは、Microsoft Azure製品、サービス、管理ツールを使用して、管理者のお客様が個人データを見つけて行動してデータ主体の要求 (DSR) に対応できるようにする方法について説明します。
GDPR 用語の定義については、「 一般的なデータ保護規則」を参照してください。 データ プロセッサとしての Microsoft の役割については、「データ プロセッサ としての Microsoft」を参照してください。
DSR ライフサイクルの手順、製品固有のガイドの使用方法、DSR がMicrosoft Entra IDテナント内でどのように適用されるかなど、一般的な DSR プロセス情報については、「データ主体の要求と GDPR と CCPA」を参照してください。
このガイドの使用方法
このガイドは次のような 2 部構成になっています。
- パート 1: 顧客データに対するデータ主体の要求への応答: このガイドのパート 1 では、データを作成したアプリケーションからデータにアクセス、修正、制限、削除、エクスポートする方法について説明します。 このセクションでは、顧客コンテンツとユーザーの識別可能な情報の両方に対して DSR を実行する方法について説明します。
- 第 2 部: システム生成ログに関するデータ主体の要求に対応する: Microsoft のエンタープライズ サービスを利用する際、Microsoft がサービスを提供するために使われるシステム生成ログという情報が生成されます。 このガイドの第 2 部では、Azure でこのような情報にアクセスしたり、削除したり、エクスポートしたりする方法について説明します。
Microsoft Entra IDおよび Microsoft サービス アカウントの 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 管理サービスです。 ユーザーの識別可能な情報 (顧客プロファイルやユーザー プロファイル、Microsoft Entra ID環境内の個人データを含むユーザー作業情報など) は、Azure portalを使用して特定できます。
この情報は、特定のユーザーの個人データを検索または変更する場合に役立ちます。 ユーザー プロファイルや勤務先情報を追加したり、変更したりすることもできます。 ディレクトリのグローバル管理者のアカウントを使用してサインインする必要があります。
重要
Microsoft では、アクセス許可が可能な限りで少ないロールを使用することをお勧めします。 グローバル管理者ロールを持つユーザーの数を最小限に抑えることで、組織のセキュリティを向上させることができます。
ユーザー プロファイルや勤務先情報を検出または表示する方法
ユーザー プロファイル情報 (名前、作業タイトル、住所、電話番号、その他の個人データ) は、Microsoft Entra 管理センターで表示または編集できます。 詳細な手順については、「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でユーザー プロファイルと作業情報を修正または更新操作方法。
Microsoft Entra 管理センターを使用して、プロパティの編集や変更の保存など、ユーザー プロファイル情報を修正または更新できます。 詳細な手順については、「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 テナントからユーザーを削除するには
Microsoft Entra 管理センターを使用して、Azure テナントからユーザーを論理的に削除または完全に削除できます。 30 日間の論理的な削除期間が切れる前に完全に削除するには、 削除された ユーザーの一覧からユーザーを手動で削除する必要があります。
重要
ユーザーを完全に削除すると、ユーザーと関連するすべてのデータとシステム生成ログが取り消し不能になります。 間違えた場合は、ユーザーを手動でテナントに追加し直す必要があります。 関連付けられたデータとシステム生成のログは回復できません。
詳細な手順については、「Microsoft Entra IDでユーザーを作成または削除する方法」を参照してください。
Azure テナントにアカウントがない場合にユーザーのデータを削除する
一部のユーザーは削除できるアカウントをAzureテナントに持っているが、ビジネス間 (B2B) 直接接続ユーザーは使用しない。 B2B 直接接続ユーザーは、ネイティブ ID を使用して、テナントでホストされているアプリとリソースへのテナント間アクセスを受け取ります。 テナントでゲスト アカウントを必要とせずに、ホーム テナントでホストされているユーザー アカウントを使用します。
これらのユーザーの DSR を尊重するには、ユーザー アカウント自体ではなく、テナント内のユーザーに関連付けられている個人データを削除します。
Azure portalを開き、[すべてのサービス] を選択し、フィルターに「ユーザー プライバシー」と入力し、[ユーザー プライバシー] を選択します。
[ 概要 ] ブレードで、[ 削除要求の追加] を選択します。
[新しいデータの削除] 要求フォームに入力します。
- ユーザー: 削除を要求したMicrosoft Entra ID ユーザーのメール アドレスを入力します。
[削除] を選択します。
削除要求は [保留中] 状態になります。 レポートの状態は、[ ユーザーのプライバシー>Overview ] ブレードで確認できます。
重要
個人データは複数のシステムから取得される可能性があるため、削除プロセスが完了するまでに最大 1 か月かかる場合があります。
ユーザーの削除、ユーザーの一括削除、およびMicrosoft 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 日間開始されません。 この論理的な削除により、ユーザーがアカウントを完全に削除する前にアカウントの復元を要求した場合、管理者はグループやアクセス許可を含むユーザー アカウントを復元できます。
必要に応じて、テナント管理者は、Microsoft Entra 管理センターを使用して、論理的に削除された期間中にいつでもアカウントを完全に削除できます。 このアクションは取り消し不可能です。 詳細な手順については、「 最近削除したユーザーを復元または完全に削除する」を参照してください。
完全削除は管理者が開始するか、論理的な削除期間の終了時に自動的に行われます。 完全削除は、データの削除に最大で 30 日かかることがあります。
B2B 直接接続ユーザーの場合、ユーザーが [確認メッセージに 残す ] を選択するとすぐにデータの削除が開始され、完了するまでに最大 30 日かかることがあります。
テナント間委任管理者のデータ削除
テナント間委任された管理者に関連付けられたデータは、テナント間アクションを実行すると、アクティビティ ログに記録されます。
DSR 削除操作では、テナント間委任管理機能によって生成されたアクティビティ レコードは削除されません。
セキュリティ、コンプライアンス、監査の目的で、監査ログとサインイン ログに格納されているアクティビティ レコードは、該当するサービス保持ポリシーに従って保持され、DSR 削除要求の一部として削除されません。 この動作は、システム生成ログの既存の処理と一致します
手順 3: エクスポート
システム生成ログにキャプチャされた個人データに関連するデータ主体要求を実行できるのは、テナント管理者だけです。 エクスポート要求に対して取得されるデータは、コンピューターが読み取り可能な形式であり、データが関連付けられているサービスを示すファイルに含まれています。 前に説明したように、取得されたデータには、サービスのセキュリティまたは安定性を損なう可能性のあるデータは含まれません。
AZURE PORTALを介して管理される DSR
データ主体のエクスポート要求を受け取ったら、管理ポータルを使用してログをダウンロードします。 ポータル内のログのダウンロードの詳細については、「Microsoft Entra ID でログをダウンロードする方法 - Microsoft Entra ID |Microsoft Learn。
テナント間委任管理者のデータ エクスポート
テナント間委任管理機能 (Microsoft パートナー センターやMicrosoft Entra テナント ガバナンスなど) を介してorganizationにアクセスするユーザーによって実行されるアクティビティは、DSR エクスポートの結果には含まれません。
テナント間委任管理者に関連付けられているアクティビティを特定してエクスポートするには、organizationの監査ログとアクティビティ ログを使用します。 管理者は、委任された管理者の ID の監査ログを検索し、使用可能な監査ログエクスポート機能を使用して関連レコードを取得できます。 詳細については、 テナント間管理監査ログ ガイドを参照してください。
Microsoft Data Log Export
テナント管理者は、 Microsoft Data Log Export を使用してシステム生成ログをエクスポートすることもできます。 テナント管理者は、[ エクスポート要求の追加] を選択し、次のフィールドに入力する必要があります。
- ユーザーの種類: ユーザーが B2B コラボレーション ユーザーか B2B 直接接続ユーザーか選択します。
- ユーザー: エクスポートを要求したMicrosoft Entra ID ユーザーのメール アドレスを入力します。
- Azureサブスクリプション: リソースの使用状況を報告し、サービスに対して課金するために使用するアカウントを選択します。 このアカウントは、Azure ストレージ アカウントの場所でもあります。
- ストレージ アカウント: Azure Storage (BLOB) の場所を選択し、[作成] を選択します。 詳細については、「Microsoft Azure Storageの概要 - BLOB ストレージ」を参照してください。
エクスポート要求は [保留中] 状態になります。 レポートの状態は、[ ユーザーのプライバシー] [概要 ] ブレードで確認できます。
重要
テナント間委任管理機能を介して生成されたアクティビティは、Microsoft Data Log Export の結果には含まれません。 委任された管理者に関連付けられているアクティビティをエクスポートするには、前のセクションで説明したように、監査ログとアクティビティ ログを使用します。
個人データは複数のシステムから取得できるため、エクスポート プロセスが完了するまでに最大 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 要求の新しいチケットを送信します。