次の方法で共有

Microsoft Entra ID とデータ所在地

  • [アーティクル]

Microsoft Entra ID は、クラウド内の ID とアクセス データを保存および管理する、サービスとしての ID (IDaaS) ソリューションです。 データを使用して、クラウド サービスへのアクセスを有効化および管理し、モビリティ シナリオを実現し、組織をセキュリティで保護できます。 テナントと呼ばれる Microsoft Entra サービスのインスタンスは、顧客がプロビジョニングして所有するディレクトリ オブジェクト データの分離されたセットです。

Note

Microsoft Entra 外部 ID は顧客 ID およびアクセス管理 (CIAM) ソリューションであり、顧客向けアプリと顧客ディレクトリ データのために作成された別のテナントにデータを格納して管理します。 このテナントは外部テナントと呼ばれます。 外部テナントを作成するときに、データを保管する地理的な場所を選できます。 この記事で示すように、データの場所と利用できるリージョンは、Microsoft Entra ID とは異なる場合があることに注意してください。

Core Store

Core Store は、スケール ユニットに保存されているテナントで構成され、各スケール ユニットには複数のテナントが含まれます。 Microsoft Entra Core Store でのデータの更新または取得操作は、ユーザーのセキュリティ トークンに基づいて 1 つのテナントに関連付けられ、これによりテナントの分離が実現されます。 スケール ユニットは、地理的な場所に割り当てられます。 それぞれの地理的な場所では、2 つ以上の Azure リージョンを使用してデータを格納します。 各 Azure リージョンでは、スケール ユニット データが、回復性とパフォーマンスのために物理的なデータセンターにレプリケートされます。

詳細情報: Microsoft Entra Core Store のストア スケール ユニット

Microsoft Entra ID は、次のクラウドで使用できます。

  • パブリック
  • 中国*
  • 米国政府*

* 現在、外部テナントには利用できません。

パブリック クラウドでは、テナント作成の時点で場所を選択するよう求められます (Office 365 または Azure へのサインアップや、Azure portal でのより多くの Microsoft Entra インスタンスの作成など)。 Microsoft Entra ID では、その選択を地理的な場所と、その中の 1 つのスケール ユニットにマップします。 テナントの場所を設定後に変更することはできません。

テナント作成中に選択された場所は、次のいずれかの地理的な場所にマップされます。

  • オーストラリア*
  • アジア/太平洋
  • ヨーロッパ、中近東およびアフリカ (EMEA)
  • 日本*
  • 北米
  • 世界全域

* 現在、外部テナントには利用できません。

Microsoft Entra ID では、使いやすさ、パフォーマンス、所在地、または地理的な場所に基づくその他の要件に基づいて Core Store データを処理します。 Microsoft Entra ID は、次の条件に基づいて、スケール ユニットを使用してデータセンター間で各テナントをレプリケートします。

  • 待ち時間やユーザーのサインイン時間を短縮するために、テナント所在地の場所に最も近いデータセンターに保存されている Microsoft Entra Core Store データ
  • 1 つのデータセンターでの予期しない致命的なイベント中の可用性を確保するために、地理的に分離されたデータセンターに保存されている Microsoft Entra Core Store データ
  • 特定の顧客および地理的な場所のためのデータ所在地やその他の要件への準拠

Microsoft Entra のクラウド ソリューション モデル

次の表を使用して、インフラストラクチャ、データの場所、運用主権に基づいた Microsoft Entra のクラウド ソリューション モデルを確認してください。

モデル 場所 データの場所 運用担当者 このモデルでのテナントの配置
パブリックな地理的な場所 オーストラリア*、北米、ヨーロッパ、中近東およびアフリカ、日本*、アジア/太平洋 保存時は、ターゲットの場所の中。 サービスまたは機能ごとに例外あり Microsoft が運用。 Microsoft データセンターの担当者はバックグラウンド チェックに合格する必要があります。 サインアップ エクスペリエンスでテナントを作成します。 データ所在地の場所を選択します。
世界中のパブリックな場所 世界全域 すべての場所 Microsoft が運用。 Microsoft データセンターの担当者はバックグラウンド チェックに合格する必要があります。 公式のサポート チャネルを経由し、かつ Microsoft の裁量に従って実行可能なテナント作成。
ソブリン クラウドまたは各国のクラウド 米国政府*、中国* 保存時は、ターゲットの場所の中。 例外。 データ管理人 (1) が運用。 担当者は要件に従ってスクリーニングされます。 各国のクラウド インスタンスごとに、サインアップ エクスペリエンスがあります。

* 現在、外部テナントには利用できません。

テーブル参照:

(1) データ管理人: 米国政府のクラウド内のデータセンターは Microsoft によって運用されています。 中国では、Microsoft Entra ID は 21Vianet とのパートナーシップを通じて運用されています。

詳細情報:

Microsoft Entra コンポーネント間のデータ所在地

詳細情報: Microsoft Entra 製品の概要

Note

Exchange Online や Skype for Business などのサービス データの場所を把握するには、対応するサービス ドキュメントを参照してください。

Microsoft Entra コンポーネントとデータ ストレージの場所

Microsoft Entra コンポーネント 説明 データ ストレージの場所
Microsoft Entra 認証サービス このサービスはステートレスです。 認証用のデータは、Microsoft Entra Core Store にあります。 ディレクトリ データはありません。 Microsoft Entra 認証サービスは、Azure Storage と、サービス インスタンスが実行されているデータセンターでログ データを生成します。 ユーザーが Microsoft Entra ID を使用して認証しようとすると、Microsoft Entra 論理リージョンに含まれている、地理的に最も近いデータセンター内のインスタンスにルーティングされます。 地理的な場所の中
Microsoft Entra の ID およびアクセス管理 (IAM) サービス ユーザーと管理のエクスペリエンス: Microsoft Entra 管理エクスペリエンスはステートレスであり、ディレクトリ データはありません。 ログと使用状況データが生成され、Azure テーブル ストレージに保存されます。 ユーザー エクスペリエンスは、Azure portal と似ています。
ID 管理ビジネス ロジックとレポート サービス: これらのサービスには、グループとユーザー用にローカルにキャッシュされたデータ ストレージがあります。 これらのサービスにより、ログと使用状況データが生成され、Azure テーブル ストレージ、Azure SQL、および Microsoft Elastic Search レポート サービスに送られます。		 地理的な場所の中
Microsoft Entra 多要素認証 多要素認証操作のデータ ストレージと保持の詳細については、「Microsoft Entra 多要素認証のデータ所在地と顧客データ」を参照してください。 Microsoft Entra 多要素認証では、ユーザー プリンシパル名 (UPN)、音声通話の電話番号、SMS チャレンジがログに記録されます。 モバイル アプリ モードへのチャレンジの場合、サービスは UPN と一意のデバイス トークンをログに記録します。 北米リージョンにあるデータセンターが Microsoft Entra 多要素認証と、生成されるログを保存します。 北米
Microsoft Entra Domain Services 「リージョン別の利用可能な製品」で、Microsoft Entra Domain Services が公開されているリージョンを参照してください。 このサービスは、Azure テーブルにシステム メタデータをグローバルに保持し、個人データは含まれません。 地理的な場所の中
Microsoft Entra Connect Health Microsoft Entra Connect Health は、Azure テーブル ストレージと BLOB ストレージにアラートとレポートを生成します。 地理的な場所の中
Microsoft Entra 動的メンバーシップ グループ、Microsoft Entra セルフサービス グループ管理 Azure Table Storage には、動的メンバーシップ グループの規則の定義が保持されます。 地理的な場所の中
Microsoft Entra アプリケーション プロキシ Microsoft Entra アプリケーション プロキシは、テナント、コネクタ マシン、および構成データに関するメタデータを Azure SQL に保存します。 地理的な場所の中
Microsoft Entra Connect での Microsoft Entra パスワード ライトバック 初期構成時に、Microsoft Entra Connect は、Rivest-Shamir-Adleman (RSA) 暗号化システムを使用して非対称キー ペアを生成します。 次に、セルフサービス パスワード リセット (SSPR) クラウド サービスに公開キーを送信します。これにより、次の 2 つの操作が実行されます。

1. Microsoft Entra Connect オンプレミス サービス用の 2 つのAzure Service Bus リレーを作成して、SSPR サービスと安全に通信する
2. Advanced Encryption Standard (AES) キー K1 を生成する

Azure Service Bus リレーの場所、対応するリスナー キー、AES キー (K1) のコピーが、応答で Microsoft Entra Connect に送られます。 今後の SSPR と Microsoft Entra Connect の間の通信は、新しい ServiceBus チャネル経由で行われ、SSL を使用して暗号化されます。
操作中に送信された新しいパスワード リセットは、クライアントによってオンボード中に生成された RSA 公開キーで暗号化されます。 それらは、Microsoft Entra Connect マシン上の秘密キーによって暗号化解除されるため、パイプライン サブシステムがプレーンテキスト パスワードにアクセスすることを防止できます。
AES キーはメッセージ ペイロード (暗号化されたパスワード、追加データ、メタデータ) を暗号化します。これにより、悪意のある ServiceBus 攻撃者が内部 ServiceBus チャネルへのフル アクセスを持っている場合でも、ペイロードの改ざんを防止できます。
パスワード ライトバックの場合、Microsoft Entra Connect にはキーとデータが必要です。

- リセット ペイロードを暗号化する AES キー (K1)、または ServiceBus パイプライン経由での SSPR サービスから Microsoft Entra Connect への変更要求
- リセットまたは変更要求ペイロードでパスワードを暗号化解除する非対称キー ペアからの秘密キー
- ServiceBus リスナー キー

AES キー (K1) と非対称キーペアは、少なくとも 180 日ごとにローテーションされます。これは、特定のオンボードまたはオフボード構成イベント中に変更できる期間です。 たとえば、顧客がパスワード ライトバックを無効にしてから再度有効にした場合などです。これは、サービスやメンテナンス中のコンポーネントのアップグレード時に発生することがあります。
Microsoft Entra Connect データベースに保存されているライトバック キーとデータは、データ保護アプリケーション プログラミング インターフェイス (DPAPI) (CALG_AES_256) によって暗号化されます。 その結果、マスター ADSync 暗号化キーが生成されます。これは、ADSync オンプレミス サービス アカウントのコンテキストで Windows Credential Vault に保存されます。 Windows Credential Vault では、サービス アカウントのパスワードが変更されると、シークレットの再暗号化が自動的に行われます。 サービス アカウントのパスワードをリセットすると、サービス アカウントの Windows Credential Vault 内のシークレットが無効になります。 新しいサービス アカウントを手動で変更すると、保存されているシークレットが無効になる可能性があります。
既定では、ADSync サービスは仮想サービス アカウントのコンテキストで実行されます。 アカウントは、インストール中に最小特権ドメイン サービス アカウント、マネージド サービス アカウント (Microsoft アカウント)、またはグループ管理サービス アカウント (gMSA) にカスタマイズされる場合があります。 仮想サービス アカウントとマネージド サービス アカウントにはパスワードの自動ローテーションが備わっていますが、カスタム プロビジョニングされたドメイン アカウントのパスワード ローテーションは顧客が管理します。 前述したように、パスワードをリセットすると、保存されているシークレットが失われます。		 地理的な場所の中
Microsoft Entra デバイス登録サービス Microsoft Entra Device Registration Service では、コンピューターとデバイスのライフサイクル管理がディレクトリで行われます。これにより、デバイス状態の条件付きアクセスやモバイル デバイス管理などのシナリオが可能になります。 地理的な場所の中
Microsoft Entra プロビジョニング Microsoft Entra プロビジョニングでは、サービスとしてのソフトウェア (サービスとしてのソフトウェア (SaaS)) アプリケーションなどのシステム内のユーザーを作成、削除、更新します。 これは、クラウド人事ソース (Workday など) からの Microsoft Entra ID およびオンプレミス Microsoft Windows Server Active Directory でのユーザー作成を管理します。 サービスは、その構成を Azure Cosmos DB インスタンスに保存します。ここには、保持しているユーザー ディレクトリのグループ メンバーシップ データが保存されます。 Azure Cosmos DB は、Microsoft Entra クラウド ソリューション モデルに従って、テナントと同じリージョン内の複数のデータセンターにデータベースをレプリケートしてデータを分離します。 レプリケーションにより、高可用性と複数の読み取りおよび書き込みのエンドポイントが作成されます。 Azure Cosmos DB にはデータベース情報に対する暗号化があり、暗号化キーは Microsoft 用のシークレット ストレージに保存されます。 地理的な場所の中
Microsoft Entra 企業間 (B2B) コラボレーション Microsoft Entra の B2B コラボレーションにはディレクトリ データがありません。 他のテナントとの B2B 関係にあるユーザーおよびその他のディレクトリ オブジェクトは、ユーザー データが他のテナントにコピーされるため、データ所在地に影響を与える可能性があります。 地理的な場所の中
Microsoft Entra ID Protection Microsoft Entra ID Protection では、企業や業界のソースからの複数のシグナルを含むリアルタイムのユーザー ログイン データを使用して、異常なログインを検出する機械学習システムにフィードします。 個人データは、機械学習システムに渡される前に、リアルタイムのログイン データからスクラブされます。 残りのログイン データは、潜在的にリスクの高いユーザー名とログインを識別します。 分析後、データはMicrosoft レポート システムに送られます。 リスクのあるログインとユーザー名は、管理者向けのレポートに表示されます。 地理的な場所の中
Azure リソースのマネージド ID マネージド ID システムを使用する Azure リソースのマネージド ID は、資格情報を保存せずに Azure サービスに対する認証を行うことができます。 マネージド ID は、ユーザー名とパスワードを使用するのではなく、証明書を使用して Azure サービスに対する認証を行います。 このサービスは、発行する証明書を米国東部リージョンの Azure Cosmos DB に書き込みます。これは、必要に応じて別のリージョンにフェールオーバーします。 Azure Cosmos DB geo 冗長性は、グローバル データ レプリケーションによって発生します。 データベース レプリケーションでは、Microsoft Entra マネージド ID が実行される各リージョンに読み取り専用コピーを配置します。 詳細については、「マネージド ID を使用して他のサービスにアクセスできる Azure サービス」を参照してください。 Microsoft は、Microsoft Entra クラウド ソリューション モデル内の各 Azure Cosmos DB インスタンスを分離します。
仮想マシン (VM) ホストなどのリソース プロバイダーは、認証用の証明書と ID フローを他の Azure サービスと共に保存します。 このサービスは、Azure Cosmos DB にアクセスするためのマスター キーをデータセンター シークレット管理サービスに保存します。 Azure Key Vault には、マスター暗号化キーが保存されます。		 地理的な場所の中

Microsoft Cloud オファリングでのデータ所在地の詳細については、次の記事を参照してください。

次のステップ