次の方法で共有


アプリケーションの登録

Microsoft ID プラットフォーム アプリ登録ポータルは、プラットフォームを認証と関連ニーズに使用することを目的としたアプリケーションのプライマリ エントリ ポイントです。 開発者がアプリを登録して構成する際に行う選択によって、アプリケーションがゼロ トラストの原則をどの程度満たすかが左右されます。 効果的なアプリの登録では、特に最低特権アクセスを使用して侵害を想定する原則が考慮されます。 この記事では、アプリケーションの登録プロセスとその要件について説明し、アプリがセキュリティに対するゼロ トラストアプローチに従っていることを確認します。

Microsoft Entra ID でのアプリケーション管理 (Microsoft Entra ID) は、クラウドでアプリケーションの作成、構成、管理、監視を行うプロセスです。 Microsoft Entra テナントにアプリケーションを登録するときは、セキュリティで保護されたユーザー アクセスを構成します。

Microsoft Entra ID は、アプリケーション オブジェクトサービス プリンシパルでアプリケーションを表します。 一部の例外を除き、アプリケーションはアプリケーション オブジェクトです。 サービス プリンシパルは、アプリケーション オブジェクトを参照するアプリケーションのインスタンスと考えてください。 ディレクトリ間の複数のサービス プリンシパルによって、1 つのアプリケーション オブジェクトを参照できます。

Microsoft Entra ID を使用するようにアプリケーションを構成するには、Visual Studio、Microsoft Graph API、または PowerShell の 3 つのメソッドを使用します。 Azure と API エクスプローラーには、デベロッパー センター間で開発者エクスペリエンスがあります。 Microsoft ID プラットフォームでセキュリティで保護されたアプリケーションを構築して展開するために、開発者と IT Pro の役割に必要な決定とタスクを参照します。

アプリケーションを追加および登録できるユーザー

管理者およびユーザーと開発者 (テナントで許可されている場合) は、Azure portal でアプリケーションを登録することでアプリケーション オブジェクトを作成できます。 既定では、ディレクトリ内のすべてのユーザーが開発したアプリケーション オブジェクトを登録できます。 アプリケーション オブジェクトの開発者は、どのアプリケーションが共有するかを決定し、同意を通じて組織データへのアクセス権を付与します。

ディレクトリ内の最初のユーザーがアプリケーションにサインインし、同意を付与すると、システムは、すべてのユーザーの同意情報を格納するサービス プリンシパルをテナントに作成します。 Microsoft Entra ID は、ユーザーが認証する前に、テナントに新しく登録されたアプリのサービス プリンシパルを自動的に作成します。

少なくともアプリケーション管理者ロールまたはクラウド アプリケーション管理者ロールが割り当てられているユーザーが、特定のアプリケーション タスク (アプリ ギャラリーからのアプリケーションの追加や、アプリケーション プロキシを使用するためのアプリケーションの構成など) を実行できます。

アプリケーション オブジェクトを登録する

開発者は、Microsoft ID プラットフォームを使用するアプリを登録します。 Azure portal で、または Microsoft Graph アプリケーション API を呼び出して、アプリを登録します。 登録の済んだアプリは、エンドポイントに要求を送信して、Microsoft ID プラットフォームと通信します。

アプリケーションの登録を作成または変更するアクセス許可がない可能性があります。 管理者がアプリケーションを登録するアクセス許可を付与しない場合は、必要なアプリの登録情報をユーザーに伝える方法を尋ねます。

アプリケーション登録プロパティには、以下のコンポーネントを含めることができます。

  • 名前、ロゴ、発行元
  • リダイレクト用 Uniform Resource Identifier (URI)
  • シークレット (アプリケーションの認証に使用される対称キーまたは非対称キー)
  • API の依存関係 (OAuth)
  • 発行済みの API/リソース/スコープ (OAuth)
  • ロールベースのアクセス制御の アプリ ロール
  • シングル サインオン (SSO)、ユーザー プロビジョニング、プロキシのメタデータと構成

アプリの登録に必要な部分は、サポートされているアカウントの種類を選択して、ユーザー アカウントの種類に基づいてアプリを使用できるユーザーを定義することです。 Microsoft Entra 管理者は、アプリケーション モデルに従って、アプリの登録エクスペリエンスを使用して Azure portal でアプリケーション オブジェクトを管理し、アプリケーションにトークンを発行する方法をサービスに指示するアプリケーション設定を定義します。

登録時に、アプリケーションの ID であるアプリケーション (クライアント) ID を受信します。 アプリは、Microsoft ID プラットフォームを介してトランザクションを実行するたびに、そのクライアント ID を使用します。

アプリの登録のベスト プラクティス

ビジネス上の重要な部分として Microsoft Entra ID にアプリケーションを登録する場合は、アプリケーション プロパティのセキュリティのベスト プラクティスに従ってください。 組織全体に影響を与える可能性があるダウンタイムや侵害を防ぐことを目的としています。 次の推奨事項は、ゼロ トラストの原則に基づき、セキュリティで保護されたアプリケーションを開発するのに役立ちます。

  • Microsoft ID プラットフォーム統合チェックリストを使用して、高品質で安全な統合を確認します。 アプリの品質とセキュリティを維持します。
  • リダイレクト URL を正しく定義します。 互換性とセキュリティの問題を回避するには、「リダイレクト URI (応答 URL) の 制約と制限」を参照してください。
  • 所有権のドメイン引き継ぎを回避するために、アプリの登録のリダイレクト URI を確認します。 リダイレクト URL は認識し所有しているドメインである必要があります。 不要な URI と未使用の URI を定期的に確認して削除します。 運用アプリでは https 以外の URI を使用しないでください。
  • テナントに登録されているアプリに対して、アプリとサービス プリンシパルの所有者を必ず定義および管理します。 孤立したアプリ (所有者が割り当てられていないアプリとサービス プリンシパル) を防止します。 IT 管理者が緊急時にアプリの所有者を簡単かつ迅速に識別できることを確認します。 アプリ所有者の数を少なくします。 侵害されたユーザー アカウントが複数のアプリケーションに影響を与えにくくします。
  • 複数のアプリに対して同じアプリ登録を使用しないでください。 アプリの登録を分離することで、最低特権アクセスを有効にし、侵害時の影響を軽減できます。
    • API を介してデータと操作を公開するユーザーとアプリをサインインさせるアプリには、個別のアプリの登録を使用します (密接に結合されている場合を除く)。 この方法では、サインインしてユーザーと対話するアプリから離れた場所で、Microsoft Graph や認証情報 (シークレットや証明書など) などの高い権限を持つ API のアクセス許可を付与できます。
    • Web アプリと API には個別のアプリの登録を使用します。 この方法は、Web API のアクセス許可セットが高い場合に、クライアント アプリがそれらを継承しないようにするのに役立ちます。
  • 必要な場合にのみ、アプリケーションをマルチテナント アプリとして定義しますマルチテナント アプリでは自分のテナント以外のテナントでのプロビジョニングが可能です。 不要なアクセスをフィルター処理するには、より多くの管理オーバーヘッドが必要です。 アプリをマルチテナント アプリとして開発したい場合以外は、AzureADMyOrg を SignInAudience 値にします。

次のステップ