Microsoft Entra アプリケーション プロキシのデプロイを計画する

Microsoft Entra アプリケーション プロキシは、オンプレミスのアプリケーションのための安全でコスト効率の高いリモート アクセス ソリューションです。 これによって、最新のプロトコルをまだ使用できない従来のオンプレミス アプリケーションに対するアクセスを管理するためにすぐに移行できるパスがクラウド ファーストの組織に提供されます。 その他の概要については、「アプリケーション プロキシとは」をご覧ください。

リモート ユーザーが内部リソースにアクセスできるようにするには、アプリケーション プロキシをお勧めします。 このようなリモート アクセスのユース ケースでは、アプリケーション プロキシを使うと、VPN またはリバース プロキシは必要なくなります。 これは、企業ネットワーク上のユーザーを対象としていません。 これらのユーザーがイントラネット アクセス用にアプリケーション プロキシを使うと、望ましくないパフォーマンス上の問題が発生する可能性があります。

この記事には、Microsoft Entra アプリケーション プロキシの計画、操作、管理を行うのに必要なリソースが含まれています。

実装の計画

次のセクションでは、効率的なデプロイ エクスペリエンスに向けて準備する重要な計画要素の概要を説明します。

前提条件

実装を開始する前に次の前提条件を満たしている必要があります。 これらの前提条件を含め環境の設定について詳しくは、このチュートリアルをご覧ください。

• コネクタ:コネクタは、以下の上にデプロイできる軽量エージェントです。

  • オンプレミスの物理ハードウェア
  • 任意のハイパーバイザー ソリューション内でホストされている VM
  • アプリケーション プロキシ サービスへの送信接続を有効にする、Azure でホストされている VM。

• より詳しい概要については、「Microsoft Entra プライベート ネットワーク コネクタについて」を参照してください。

  • コネクタ コンピューターは、コネクタをインストールする前に TLS 1.2 に対して有効にしておく必要があります。

  • 可能であれば、バックエンド Web アプリケーション サーバーと同じネットワークとセグメント内にコネクタをデプロイします。 アプリケーションの検出を完了した後でコネクタをデプロイすることをお勧めします。

  • 高可用性とスケールを実現するために、各コネクタ グループには少なくとも 2 つのコネクタを用意することをお勧めします。 任意の時点でコンピューターにサービスを提供する必要がある場合は、3 つのコネクタを用意するのが最適です。 コネクタ キャパシティ テーブルを参照すれば、コネクタのインストール先とするコンピューターの種類を容易に決定できます。 コンピューターが大きくなればなるほど、コネクターはより大きなバッファーとなり、より高いパフォーマンスを発揮します。

• ネットワーク アクセスの設定: Microsoft Entra プライベート ネットワーク コネクタは HTTPS (TCP ポート 443) および HTTP (TCP ポート 80) を介して Azure に接続します。

  • コネクタ TLS トラフィックの終了はサポートされておらず、これによってコネクタが個々の Microsoft Entra アプリケーション プロキシ エンドポイントを使用して安全なチャネルを確立することが阻害されます。

  • コネクタと Azure の間の送信 TLS 通信に対してすべての形式のインライン検査を行わないでください。 コネクタとバックエンド アプリケーション間の内部検査は可能ですが、ユーザー エクスペリエンスを低下させることがあるためお勧めしません。

  • また、コネクタそのものの負荷分散はサポートされません。不必要な場合さえあります。

Microsoft Entra アプリケーション プロキシを構成する前の重要な考慮事項

Microsoft Entra アプリケーション プロキシを構成して実装するには、以下のコア要件を満たす必要があります。

• Azure オンボード: アプリケーション プロキシをデプロイする前に、ユーザー ID をオンプレミス ディレクトリから同期するか、Microsoft Entra テナント内で直接作成する必要があります。 ID 同期によって、Microsoft Entra ID は、アプリケーション プロキシによって発行されたアプリケーションへのアクセス権をユーザーに付与する前にユーザーを事前認証し、シングル サインオン (SSO) を実行するために必要なユーザー ID 情報を取得することができます。

• 条件付きアクセスの要件: 待ち時間が長くなってユーザーに影響を与えるため、イントラネット アクセスにはアプリケーション プロキシを使わないことをお勧めします。 アプリケーション プロキシは、インターネットからのリモート アクセスのための事前認証と条件付きアクセス ポリシーと共に使うことをお勧めします。 イントラネットの使用のために条件付きアクセスを提供するアプローチは、アプリケーションが Microsoft Entra ID を使用して直接認証を行えるようにアプリケーションを最新化することです。 詳細については、「アプリケーションを Microsoft Entra ID に移行するためのリソース」を参照してください。

• サービスの制限: 個々のテナントによるリソースの過剰消費から保護するために、アプリケーションおよびテナントごとにスロットリングの制限が設定されています。 これらの制限について確認するには、「Microsoft Entra サービスの制限と制約」を参照してください。 このようなスロットルの制限は、通常の使用量をはるかに超えるベンチマークに基づいて行われます。これにより、ほとんどのデプロイに十分なバッファーが提供されます。

• 公開証明書:カスタム ドメイン名を使用している場合は、SSL 証明書を取得する必要があります。 組織の要件によって異なりますが、証明書の入手には時間がかかることがあります。できるだけ早くこのプロセスを開始することをお勧めします。 Azure アプリケーション プロキシでは、標準、ワイルドカード、または SAN ベースの証明書がサポートされます。 詳細については、「Microsoft Entra アプリケーション プロキシを使用したカスタム ドメインの構成」を参照してください。

• ドメインの要件:Kerberos 制約付き委任 (KCD) を利用してご自分の発行済みアプリケーションにシングル サインオンするには、コネクタを実行するサーバーとアプリを実行するサーバーがドメインに参加し、かつ同じドメインまたは信頼する側のドメインに属していることが必要です。 このトピックについて詳しくは、アプリケーション プロキシでのシングル サインオンのための KCD に関する記事をご覧ください。 コネクタ サービスはローカル システムのコンテキストで実行します。カスタム ID を使用するように構成しないでください。

• URL の DNS レコード

  • アプリケーション プロキシでカスタム ドメインを使う前に、パブリック DNS で CNAME レコードを作成する必要があります。これにより、クライアントは、カスタム定義された外部 URL を、事前定義済みのアプリケーション プロキシ アドレスに解決できるようになります。 カスタム ドメインを使用するアプリケーションのために CNAME レコードを作成できないと、リモート ユーザーがアプリケーションに接続できなくなります。 CNAME レコードを追加するために必要な手順は DNS プロバイダーごとに異なる可能性があるため、Microsoft Entra 管理センターを使用して DNS レコードおよびレコード セットを管理する方法を確認してください。

  • 同様に、コネクタ ホストは、発行されるアプリケーションの内部 URL を解決できる必要があります。

• 管理者権限とロール

  • コネクタのインストールでは、インストール先の Windows サーバーに対するローカル管理者権限が必要です。 コネクタ インスタンスを Microsoft Entra テナントに対する認証と登録を行うためには、最低限 "アプリケーション管理者" ロールも必要となります。

  • アプリケーションの発行と管理には、"アプリケーション管理者" ロールが必要です。 アプリケーション管理者は、登録、SSO 設定、ユーザーとグループの割り当てとライセンス、アプリケーション プロキシの設定、同意など、ディレクトリ内のすべてのアプリケーションを管理できます。 条件付きアクセスの管理権限は付与されません。 "クラウド アプリケーション管理者" ロールは、アプリケーション プロキシの設定を管理できないことを除き、アプリケーション管理者と同じことをすべてできます。

• ライセンス: アプリケーション プロキシは、Microsoft Entra ID の P1 または P2 サブスクリプションを通して利用できます。 ライセンス オプションと機能の完全な一覧については、Microsoft Entra の価格ページを参照してください。

アプリケーションの検出

以下の情報を収集して、アプリケーション プロキシ経由で発行されているすべてのスコープ内アプリケーションのインベントリをまとめます。

このアプリケーション インベントリ スプレッドシートをダウンロードして、アプリケーションのインベントリを管理できます。

組織の要件を定義する

以下に示すのは、組織のビジネス要件を定義する必要がある区分です。 各区分には要件の例が含まれています。

アクセス

• ドメイン参加または Microsoft Entra 参加デバイスを持つリモート ユーザーは、シームレス シングル サインオン (SSO) を使用して発行済みプリケーションに安全にアクセスできます。

• 承認済みの個人用デバイスを利用するリモート ユーザーが MFA に登録され、携帯電話上の Microsoft Authenticator アプリを認証方法として登録している場合は、発行済みのアプリケーションに安全にアクセスできます。

ガバナンス

• 管理者は、アプリケーション プロキシを介して発行されたアプリケーションに対するユーザー割り当てのライフサイクルを定義して監視できます。

Security

• グループ メンバーシップで、または個別にアプリケーションに割り当てられたユーザーのみが、それらのアプリケーションにアクセスできます。

パフォーマンス

• 内部ネットワークからのアプリケーションへのアクセスに比較してアプリケーションのパフォーマンスが低下しません。

ユーザー エクスペリエンス

• ユーザーは、任意のデバイス プラットフォームで使い慣れた会社の URL を使用することにより、アプリケーションにアクセスする方法を認識します。

監査

• 管理者はユーザーのアクセス アクティビティを監査できます。

パイロットのベスト プラクティス

シングル サインオン (SSO) を使用したリモート アクセスのために 1 つのアプリケーションを完全に作動させるために必要な時間と労力を確認します。 このためには、初期の検出、発行、および一般的なテストを検討するパイロットを実行します。 統合 Windows 認証 (IWA) が既に構成されている単純な IIS ベースの Web アプリケーションを使用すると、基準計画の確立に役立ちます。この設定ではリモート アクセスと SSO のパイロットを成功させるために最小の労力しか必要としないためです。

以下の設計要素によって、パイロットを運用環境テナントに直接実装する成功率が高まります。

コネクタの管理:

• コネクタは、オンプレミス コンジットをアプリケーションに提供するために重要な役割を果たします。 既定コネクタ グループの使用が、運用環境で動作させる前の発行済みアプリケーションの最初のパイロット テストに適しています。 この後、テストが成功したアプリケーションを運用環境のコネクタ グループに移すことができます。

アプリケーション管理:

• 従業員は外部 URL に慣れて関連性が高いものとしてそれを記憶する可能性が高くなります。 事前定義済みの msappproxy.net または onmicrosoft.com サフィックスを使用してアプリケーションを発行しないでください。 代わりに、intranet.<customers_domain>.com のように、使い慣れた最上位レベルの確認済みドメインの前に論理的なホスト名を指定します。

• 起動アイコンを Azure MyApps ポータルでは表示せず、パイロット アプリケーションのアイコンの表示をパイロット グループのみに制限します。 運用の準備が整ったら、アプリのスコープをそれぞれの対象ユーザーに設定できます。これは、同じ実稼働前テナント内で行うか、ご使用の運用環境テナントでアプリケーションを発行します。

シングル サインオンの設定:一部の SSO 設定には、設定に時間がかかる固有の依存関係があるため、依存関係を事前に対処しておくことで、変更制御の遅延を回避します。 これには、Kerberos 制約付き委任 (KCD) を使用し、時間のかかる他のアクティビティを処理して SSO を実行する、ドメイン参加コネクタ ホストが含まれます。

コネクタ ホストとターゲット アプリケーションの間の TLS:セキュリティは非常に重要であるため、コネクタ ホストとターゲット アプリケーション間の TLS は常に使用する必要があります。 Web アプリケーションでフォームベース認証 (FBA) が構成されている場合は、ユーザー資格情報が効率よくクリア テキストで送信されるため特に当てはまります。

段階的な実装と手順ごとのテスト 以下の指示に従い、アプリケーションの発行後に基本的な機能テストを実施して、すべてのユーザーとビジネスの要件が満たされていることを確認します。

1. 事前認証が無効になっている Web アプリケーションへの一般的なアクセスをテストして検証します。
2. 成功した場合は、事前認証を有効にし、ユーザーとグループを割り当てます。 アクセスをテストおよび検証します。
3. 次に、アプリケーションの SSO 手法を追加し、再びテストしてアクセスを検証します。
4. 必要に応じて条件付きアクセスおよび MFA ポリシーを適用します。 アクセスをテストおよび検証します。

トラブルシューティング ツール:トラブルシューティングの際には、常に最初にコネクタ ホスト上のブラウザーから発行済みアプリケーションへのアクセスを検証して、アプリケーションが予期されるとおりに機能していることを確認します。 セットアップが単純であるほど根本原因の判別が容易になります。このため、SSO は使用せずに 1 つのコネクタのみを使用するなど、最小の構成で問題を再現することを検討してください。 場合によっては、プロキシによってアクセスされるアプリケーションのアクセスまたはコンテンツの問題をトラブルシューティングするために Telerik Fiddler などの Web デバッグ ツールが不可欠と判明することがあります。 Fiddler はプロキシとしても作動し、iOS や Android などモバイル プラットフォームのトラフィックとプロキシ経由でルーティングするように構成できる実質的にすべてのトラフィックをトレースしてデバッグするときに役立ちます。 詳細については、トラブルシューティング ガイドを参照してください。

ソリューションを実装する

アプリケーション プロキシをデプロイする

アプリケーション プロキシをデプロイする手順は、こちらのリモート アクセスのためのオンプレミス アプリケーションの追加に関するチュートリアルで説明されています。 インストールが正常に終了しない場合は、ポータルで [アプリケーション プロキシのトラブルシューティング] を選ぶか、アプリケーション プロキシ エージェント コネクタのインストールに関する問題のトラブルシューティング ガイドを使ってください。

アプリケーション プロキシを介してアプリケーションを発行する

アプリケーションの発行では、すべての前提条件が満たされていることと、いくつかのコネクタがアプリケーション プロキシのページで登録済みかつアクティブとして示されていることが想定されています。

PowerShell を使用してアプリケーションを発行することもできます。

アプリケーションを発行するときに従ういくつかのベスト プラクティスを次に示します。

• コネクタ グループの使用:それぞれのアプリケーションを発行するために指定されているコネクタ グループを割り当てます。 高可用性とスケールを実現するために、各コネクタ グループには少なくとも 2 つのコネクタを用意することをお勧めします。 任意の時点でコンピューターにサービスを提供する必要がある場合は、3 つのコネクタを用意するのが最適です。 さらに、Microsoft Entra プライベート ネットワーク コネクタ グループについてに関する記事を参照して、コネクタ グループを使用してネットワークまたは場所によってコネクタをセグメント化する方法を確認してください。

• バックエンド アプリケーションのタイムアウトの設定:この設定は、アプリケーションがクライアント トランザクションを処理するために必要な時間が 75 秒を超える可能性があるシナリオで役立ちます。 たとえば、データベースに対するフロント エンドとして動作する Web アプリケーションにクライアントがクエリを送信するときです。 フロント エンドはこのクエリをバックエンド データベース サーバーに送信して応答を待機しますが、応答を受信するまでに会話のクライアント側がタイムアウトします。タイムアウトを [長] に設定すると、長いトランザクションが完了できるように 180 秒が指定されます。

• 適切な Cookie タイプの使用

  • HTTP 専用 Cookie: アプリケーション プロキシで set-cookie HTTP 応答ヘッダーに HTTPOnly フラグを含めることで、追加のセキュリティを提供します。 この設定は、クロスサイト スクリプティング (XSS) などの悪用の軽減に役立ちます。 セッション Cookie へのアクセス権が必要なクライアント/ユーザー エージェントの場合は、この設定を [いいえ] にしておきます。 たとえば、アプリケーション プロキシ経由で発行されたリモート デスクトップ ゲートウェイに接続する RDP/MTSC クライアントです。

  • セキュリティで保護された Cookie:Secure 属性を使用して Cookie を設定すると、ユーザー エージェント (クライアント側アプリ) が Cookie を HTTP 要求に含めるのは要求が TLS セキュリティ チャネルを介して送信される場合のみです。 これにより、クリア テキスト チャネル上で cookie が危害を受けるリスクが軽減するため、有効にする必要があります。

  • 永続 Cookie: アプリケーション プロキシのセッション Cookie を、期限切れになるか削除されるまで有効にしておくことで、ブラウザーをクローズした後でも永続化できます。 ユーザーが認証を再度求められずに、Office などの多機能アプリケーションが発行済み Web アプリケーション内のドキュメントにアクセスするというシナリオで使用されます。 ただし、有効にするときは慎重に行います。永続 Cookie は、他の補完コントロールと組み合わせて使用しないと、最終的にサービスを未承認アクセスのリスクにさらす可能性があるためです。 この設定は、プロセス間で Cookie を共有できない古いアプリケーションにのみ使用する必要があります。 この設定を使用するのではなく、プロセス間での Cookie の共有を処理するようにアプリケーションを更新する方が適切です。

• ヘッダーの URL の変換:これは、組織のパブリック名前空間と一致するように内部 DNS を構成できないシナリオ (分割 DNS) で有効にします。 アプリケーションがクライアント要求内の元のホスト ヘッダーを必要とする場合を除き、この値の設定は [はい] のままにします。 代わりに、コネクタが、実際のトラフィックのルーティングに内部 URL の FQDN を使用し、ホストヘッダーとして外部 URL の FQDN を使用するようにします。 ほとんどのケースで、リモートからアクセスしたとき、この代替方法によってアプリケーションが正常に作動しますが、内部と外部の URL が一致するというユーザーのメリットは失われます。

• アプリケーション本文の URL を変換する:クライアントへの応答で、そのアプリからのリンクを変換したい場合に、アプリのアプリケーション本文のリンク変換をオンにします。 この機能は、有効化されると、クライアントに返される HTML および CSS 応答内でアプリケーション プロキシが検出するすべての内部リンクの変換をベスト エフォートで試行します。 これは、ハードコーディングされた絶対リンクまたは NetBIOS 短縮名リンクをコンテンツに含むアプリを発行するとき、または他のオンプレミス アプリケーションにリンクするコンテンツを含むアプリを発行するときに役立ちます。

発行済みアプリが他の発行済みアプリにリンクするシナリオでは、各アプリケーションのリンクの変換を有効にして、各アプリ レベルでのユーザー エクスペリエンスを制御できるようにします。

たとえば、すべてが相互にリンクする、アプリケーション プロキシ経由で公開された 3 つのアプリケーション (福利厚生、経費、出張) に加えて、アプリケーション プロキシ経由で公開されていないフィードバックという 4 番目のアプリがあるとします。

福利厚生アプリのリンク変換を有効にすると、経費と出張へのリンクは、それらのアプリの外部 URL にリダイレクトされるため、企業ネットワークの外部からアプリケーションにアクセスしているユーザーがアクセスできます。 経費と出張のアプリに対してはリンク変換が有効になっていないため、この 2 つのアプリから福利厚生へのリンクは機能しません。 外部 URL がないため、フィードバックへのリンクはリダイレクトされません。したがって、福利厚生アプリを使用するユーザーは、企業ネットワークの外部からフィードバック アプリにアクセスすることはできません。 リンク変換とその他のリダイレクト オプションについて詳しくは、こちらをご覧ください。

アプリケーションにアクセスする

アプリケーション プロキシによって発行されたリソースへのアクセスを管理する方法はいくつかあるため、自分のシナリオとスケーラビリティのニーズにとって最適なものを選択してください。 一般的なアプローチには、Microsoft Entra Connect を介して同期されるオンプレミス グループの使用、ユーザー属性に基づいた Microsoft Entra ID の動的グループの作成、リソース所有者によって管理されるセルフサービス グループの使用、またはこれらすべての組み合わせが含まれます。 それぞれの利点についてはリンクされたリソースを参照してください。

アプリケーションにユーザー アクセスを割り当てる最もわかりやすい方法は、発行済みアプリケーションの左側のウィンドウの [ユーザーとグループ] オプションに移動し、グループまたはユーザーを直接割り当てることです。

また、ユーザーが現在メンバーになっていないグループを割り当て、セルフサービス オプションを構成することで、ユーザーがアプリケーションにセルフサービスでアクセスできるようにすることもできます。

有効にすると、ユーザーは MyApps ポータルにログインして、アクセスを要求できるようになります。自動承認されて既に許可されたセルフサービス グループに追加されるか、指定された承認者からの承認を必要とします。

ゲスト ユーザーを、Microsoft Entra B2B を通じてアプリケーション プロキシ経由で発行された内部アプリケーションにアクセスするように招待することもできます。

通常匿名でアクセスでき、認証が不要なオンプレミス アプリケーションの場合には、アプリケーションの [プロパティ] にあるオプションを無効にすることをお勧めします。

このオプションを "いいえ" に設定したままにすると、ユーザーがアクセス許可なしで Microsoft Entra アプリケーション プロキシを介してオンプレミス アプリケーションにアクセスできるため、慎重に使用してください。

アプリケーションがいったん発行されると、外部 URL をブラウザーに入力するか https://myapps.microsoft.com のアイコンを使用してアクセスできます。

事前認証を有効化する

アプリケーションに、外部 URL 経由でそれにアクセスするアプリケーション プロキシを介してアクセスできることを確認します。

1. [ID]>[アプリケーション]>[エンタープライズ アプリケーション]>[すべてのアプリケーション] の順に移動し、管理するアプリを選択します。

2. [アプリケーション プロキシ] を選びます。

3. [事前認証] フィールドで、ドロップダウン リストを使用して [Microsoft Entra ID] を選択し、[保存] を選択します。

事前認証が有効にされている場合、まずは Microsoft Entra ID がユーザーに認証を要求します。シングル サインオンが構成されている場合は、その後にバックエンド アプリケーションもアプリケーションへのアクセスが許可される前にユーザーの検証を行います。 また、事前認証モードをパススルーから Microsoft Entra ID に変更すると、外部 URL が HTTPS で構成されるため、最初は HTTP 用に構成されていたすべてのアプリケーションが HTTPS でセキュリティ保護されるようになります。

シングル サインオンの有効化

SSO では、ユーザーは Microsoft Entra ID にアクセスするときに 1 回だけサインインすればよいため、最適なユーザー エクスペリエンスとセキュリティが提供されます。 ユーザーが事前認証されると、プライベート ネットワーク コネクタがユーザーのために SSO を実行し、オンプレミス アプリケーションに対して認証します。 バックエンド アプリケーションが、ユーザーそのものであるかのようにログインを処理します。

パススルー オプションを選択すると、ユーザーは Microsoft Entra ID に対して認証する必要は一切なく、発行済みアプリケーションにアクセスできます。

SSO の実行が可能なのは、Microsoft Entra ID が、リソースへのアクセスを要求しているユーザーを識別できる場合のみです。したがって、SSO が機能するには、アクセス時に Microsoft Entra ID を使用してユーザーを事前認証するようにアプリケーションを構成する必要があります。そうしないと、SSO オプションが無効になります。

「Microsoft Entra ID 内のアプリケーションへのシングル サインオン」を読むと、アプリケーションを構成するときに最適な SSO の手法の選択に役立ちます。

他の種類のアプリケーションを操作する

Microsoft Entra アプリケーション プロキシは、Microsoft 認証ライブラリ (MSAL) を使用するように開発されたアプリケーションもサポートできます。 これは、クライアント要求のヘッダー情報で受け取った Microsoft Entra ID 発行トークンを使用してユーザーの代理で事前認証を実行することで、ネイティブ クライアント アプリをサポートします。

アプリケーション プロキシの利用できる構成については、ネイティブとモバイルのクライアント アプリの発行やクレームベースのアプリケーションに関するページをご覧ください。

条件付きアクセスを使用してセキュリティを強化する

アプリケーションのセキュリティでは、オンプレミスおよびクラウドでの複雑な脅威から保護して対応できる、一連の高度なセキュリティ機能が必要です。 条件付きアクセス ポリシーを使用して、場所、リスク、デバイスの種類、デバイス コンプライアンスなどのさまざまな条件に基づいてアプリケーションへのアクセスを制御します。 展開する可能性があるポリシーの例については、「条件付きアクセス テンプレート」を参照してください。

Microsoft Entra アプリケーション プロキシをサポートするために以下の機能を使用できます。

• ユーザーおよびロケーションベースの条件付きアクセス:ロケーションベースの条件付きアクセス ポリシーでは、地理的な場所や IP アドレスに基づいてユーザー アクセスを制限することで機密データを保護します。

• デバイスベースの条件付きアクセス:デバイスベースの条件付きアクセスでは、登録され承認された準拠デバイスのみが会社のデータにアクセスできます。

• アプリケーションベースの条件付きアクセス:会社のネットワークに接続していないときでも、仕事を中断するわけにはいきません。 企業クラウドおよびオンプレミス アプリへのアクセスを保護し、条件付きアクセスによる制御を管理します。

• リスクベースの条件付きアクセス:リスクベースの条件付きアクセス ポリシーを使用し、悪意のあるハッカーからデータを保護しましょう。これらのポリシーは、オンプレミスかクラウドかにかかわらず、すべてのアプリとすべてのユーザーに適用できます。

• Microsoft Entra マイ アプリ: アプリケーション プロキシ サービスがデプロイされ、アプリケーションが安全に発行されて、ユーザーにすべてのアプリケーションを検出してアクセスするための単純なハブを提供します。 マイ アプリを使用すると、ユーザーが新しいアプリやグループへのアクセスを要求したり、他のユーザーに代わってこれらのリソースへのアクセスを管理したりする機能などのセルフサービス機能を使用して生産性が向上します。

実装を管理する

必要なロール

Microsoft は、Microsoft Entra ID を使用して必要なタスクを実行するための最小限の特権の付与の原則を提唱しています。 使用可能なさまざまな Azure ロールを確認し、個々のニーズに対処できる適したものを選択します。 場合によっては、一部のロールは、一時的に適用してデプロイが完了した後で削除する必要があります。

セキュリティで保護された情報またはリソースへのアクセス権を持つユーザーの数を最小限に抑えると、悪意のあるアクターが許可されていないアクセス権を手にしたり、許可されているユーザーの不注意で機密性の高いリソースに影響が及んだりする可能性が抑えられます。

しかし、それでもユーザーは日々の特権操作を実行する必要があるため、効果的な管理アクセスの管理と監査へのアプローチとしては、Just-In-Time (JIT) ベースの Privileged Identity Management ポリシーを適用して、Azure リソースおよび Microsoft Entra ID へのオンデマンドの特権アクセスを提供することをお勧めします。

レポートと監視

Microsoft Entra ID は、監査ログとレポートを通して組織のアプリケーション使用状況と操作の正常性に関する追加の分析情報を提供します。 また、アプリケーション プロキシを使うと、Microsoft Entra 管理センターと Windows イベント ログからのコネクタの監視が非常に簡単になります。

アプリケーションの監査ログ

これらのログでは、アプリケーション プロキシで構成されたアプリケーションへのログインと、アプリケーションにアクセスしているデバイスとユーザーに関する、詳細な情報が提供されます。 監査ログは Microsoft Entra 管理センター内にあり、エクスポート用は Audit API にあります。 また、使用状況と分析情報のレポートもアプリケーションで利用できます。

プライベート ネットワーク コネクタの監視

コネクタとサービスは、高可用性のすべてのタスクに対処します。 Microsoft Entra 管理センターのアプリケーション プロキシのページから、コネクタの状態を監視できます。 コネクタのメンテナンスについて詳しくは、「Microsoft Entra プライベート ネットワーク コネクタについて」をご覧ください。

Windows イベント ログおよびパフォーマンス カウンター

コネクタには管理者ログとセッション ログがあります。 管理者ログには主要なイベントとそのエラーが含まれます。 セッション ログには、すべてのトランザクションとその処理の詳細が含まれます。 ログとカウンターは Windows イベント ログにあります。詳しくは、「Microsoft Entra プライベート ネットワーク コネクタについて」をご覧ください。 Azure Monitor でイベント ログのデータ ソースを構成するにはこのチュートリアルに従ってください。

トラブルシューティングのガイドと手順

一般的な問題や、それらの問題を解決するためにエラー メッセージをトラブルシューティングする方法について学びます。

次の記事では一般的なシナリオが説明されています。これらを使用してサポート組織のために独自のトラブルシューティング ガイドを作成することもできます。

• アプリケーション ページ上のリンクが動作しない
• アプリに対して開く必要のあるポート
• アプリに対するシングル サインオンの構成
• Kerberos の制約付き委任を構成する
• PingAccess を使用した構成
• "この企業アプリケーションにアクセスできない" というエラー
• アプリケーション プロキシ エージェント コネクタのインストールに関する問題
• サインインの問題