データ保護に関する考慮事項

次の図は、サービスがロールベースのアクセス制御 (RBAC) 承認レイヤー経由で Microsoft Entra オブジェクト データを格納および取得する方法を示しています。 このレイヤーは内部ディレクトリ データ アクセス層を呼び出して、ユーザーのデータ要求が許可されていることを確認します。

Microsoft Entra の内部インターフェイス アクセス: Microsoft 365 などの他の Microsoft サービスとのサービス間通信では、クライアント証明書を使用してサービスの呼び出し元を承認する Microsoft Entra ID インターフェイスを使用します。

Microsoft Entra の外部インターフェイス アクセス: Microsoft Entra 外部インターフェイスは、RBAC を使用してデータ漏えいを防ぐのに役立ちます。 ユーザーなどのセキュリティ プリンシパルが、Microsoft Entra ID インターフェイス経由で情報を読み取るアクセス要求を行うときは、セキュリティ トークンが要求に付随している必要があります。 トークンには、要求を行うプリンシパルに関するクレームが含まれています。

セキュリティ トークンは、Microsoft Entra 認証サービスによって発行されます。 承認システムでは、ユーザーの存在、有効状態、ロールに関する情報を使用して、ターゲット テナントへのアクセス要求を当該セッションの当該ユーザーに対して承認するかどうかを決定します。

アプリケーション アクセス: アプリケーションはユーザー コンテキストなしでアプリケーション プログラミング インターフェイス (API) にアクセスできるため、アクセス チェックには、ユーザーのアプリケーションに関する情報と、要求されたアクセスのスコープ (読み取り専用、読み取り/書き込みなど) が含まれます。 多くのアプリケーションでは、OpenID Connect または OAuth を使用して、ユーザーに代わってディレクトリにアクセスするためのトークンを取得します。 これらのアプリケーションには、ディレクトリへのアクセス権を明示的に付与する必要があり、そうしない場合には、Microsoft Entra 認証サービスからトークンを受信せず、付与されているスコープからデータにアクセスします。

監査: アクセスは監査されます。 たとえば、ユーザーの作成やパスワードのリセットなどの承認されたアクションは監査証跡を作成し、それをテナント管理者がコンプライアンスへの取り組みや調査の管理に使用できます。 テナント管理者は、Microsoft Entra の監査 API を使用して監査レポートを生成できます。

Microsoft Entra ID の監査ログに関するページを参照してください

テナントの分離: Microsoft Entra マルチテナント環境でのセキュリティの適用は、次の 2 つの主な目標を達成するのに役立ちます。

• テナント間でのデータ漏えいとアクセスの防止: テナント 1 に属するデータを、テナント 1 による明示的な承認なしにテナント 2 のユーザーが取得することはできません。
• テナント間のリソース アクセスの分離: テナント 1 によって実行される操作は、テナント 2 のリソースへのアクセスには影響しません。

テナントの分離

テナントの分離の概要を次の情報に示します。

• サービスは、RBAC ポリシーを使用してテナントをセキュリティで保護し、データの分離を確保します。
• テナントへのアクセスを有効にするには、プリンシパル (ユーザーやアプリケーションなど) が、コンテキストを取得するために Microsoft Entra ID に対して認証でき、テナントで定義されている明示的なアクセス許可を持っている必要があります。 テナントでプリンシパルが承認されない場合、結果のトークンはアクセス許可を伝達せず、RBAC システムはこのコンテキストでの要求を拒否します。
• RBAC により、テナントへのアクセスは、テナントで承認されたセキュリティ プリンシパルによって実行されるようになります。 テナント管理者が同じテナントにセキュリティ プリンシパル表現を作成するか (B2B コラボレーションを使用してゲスト ユーザー アカウントをプロビジョニングする場合など)、テナント管理者が別のテナントとの信頼関係を有効にするポリシーを作成すると、テナント間でのアクセスが可能になります。 たとえば、B2B 直接接続を有効にするクロステナント アクセス ポリシーなどです。 各テナントは分離境界です。あるテナント内の存在は、管理者が許可しない限り、別のテナント内の存在と同じにはなりません。
• 複数のテナントの Microsoft Entra データは、特定のパーティションの同じ物理サーバーとドライブに格納されます。 データへのアクセスは RBAC 承認システムによって保護されるため、分離が保証されます。
• 顧客アプリケーションが、必要な認証なしに Microsoft Entra ID にアクセスすることはできません。 最初の接続ネゴシエーション プロセスの一部として資格情報が付随していない場合、要求は拒否されます。 この働きにより、近隣テナントによるテナントへの不正アクセスが防止されます。 フェデレーション信頼を使用して仲介されるのは、ユーザー資格情報のトークン、または Security Assertion Markup Language (SAML) トークンのみです。 そのため、アプリケーション所有者が構成した共有キーに基づいて、Microsoft Entra ID によって検証されます。
• コア ストアから実行できるアプリケーション コンポーネントはないため、1 つのテナントが近隣テナントの整合性を強制的に侵害することは不可能です。

データのセキュリティ

転送中の暗号化: データのセキュリティを確保するために、Microsoft Entra ID のディレクトリ データは、スケール ユニット内のデータセンター間の転送中、署名および暗号化されます。 データは、関連付けられている Microsoft データセンターのセキュリティで保護されたサーバー ホスティング領域内に存在する、Microsoft Entra Core Store 層によって暗号化および非暗号化されます。

顧客向け Web サービスは、トランスポート層セキュリティ (TLS) プロトコルを使用してセキュリティで保護されます。

シークレット ストレージ: Microsoft Entra サービスのバックエンドでは、暗号化を使用して、Microsoft 独自のテクノロジを使用した証明書、キー、資格情報、ハッシュなどの、サービス使用向けの機密性の高い素材を格納します。 使用されるストアは、サービス、操作、シークレットのスコープ (ユーザー全体かテナント全体)、およびその他の要件によって異なります。

これらのストアは、証明書の要求、更新、失効、破棄などの、確立された自動化とワークフローを介してセキュリティに重点を置いたグループによって運用されています。

これらのストア/ワークフロー/プロセスに関連するアクティビティ監査があり、永続的なアクセスはありません。 アクセスは要求と承認に基づいていて、時間が限られています。

保存時のシークレット暗号化の詳細については、次の表を参照してください。

アルゴリズム: 次の表に、Microsoft Entra コンポーネントで使用される最小暗号化アルゴリズムの一覧を示します。 Microsoft はクラウド サービスとして、セキュリティの調査結果、内部セキュリティ レビュー、キーの強さに基づき、ハードウェアの進化などに対して暗号化を再評価し、改善します。

リソース

• Microsoft Service Trust ドキュメント
• Microsoft Azure のトラスト センター
• Microsoft Entra ID での削除からの回復

次のステップ

• Microsoft Entra ID とデータ所在地
• データ運用面の考慮事項
• データ保護に関する考慮事項 (表示中のページ)