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

[アーティクル]
02/09/2024

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 の価格ページを参照してください。

アプリケーションの検出

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

情報の種類	収集する情報
サービスの種類	次に例を示します。SharePoint、SAP、CRM、カスタム Web アプリケーション、API
アプリケーションプラットフォーム	次に例を示します。Windows IIS、Linux 上の Apache、Tomcat、NGINX
ドメインメンバーシップ	Web サーバーの完全修飾ドメイン名 (FQDN)
アプリケーションの場所	インフラストラクチャ内で Web サーバーまたはファームがある場所
内部アクセス	内部でアプリケーションにアクセスするときに使用される正確な URL。ファームでどの種類の負荷分散が使用されているか。アプリケーションがそれ自体以外のソースのコンテンツを描画するかどうか。アプリケーションが WebSocket で動作するかどうかを決定します。
外部アクセス	既にアプリケーションが外部に公開されている場合のあるベンダーソリューション。外部アクセス用に使用する URL です。 SharePoint の場合は、このガイダンスに従って代替アクセスマッピングを構成してください。それ以外の場合、外部 URL を定義する必要があります。
公開証明書	カスタムドメインを使用している場合は、対応するサブジェクト名の証明書を取得します。証明書が存在する場合は、そのシリアル番号と取得できる場所をメモします。
認証の種類	アプリケーションによってサポートされる認証の種類では、Basic、Windows 統合認証、フォームベース、ヘッダーベース、要求などがサポートされます。特定のドメインアカウントで実行するようにアプリケーションが構成されている場合は、サービスアカウントの完全修飾ドメイン名 (FQDN) をメモします。 SAML ベースの場合は、識別子と応答 URL。ヘッダーベースの場合は、ベンダーソリューションと認証の種類を処理するための特定の要件。
コネクタグループ名	このバックエンドアプリケーションにコンジットと SSO を提供するように指定されたコネクタグループの論理名。
ユーザー/グループのアクセス	アプリケーションへの外部アクセスが許可されるユーザーまたはユーザーグループ。
その他の要件	アプリケーションの発行に組み込む必要があるその他のリモートアクセスまたはセキュリティの要件に注意してください。

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

組織の要件を定義する

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

アクセス

ドメイン参加または 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) が構成されている場合は、ユーザー資格情報が効率よくクリアテキストで送信されるため特に当てはまります。

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

事前認証が無効になっている Web アプリケーションへの一般的なアクセスをテストして検証します。
成功した場合は、事前認証を有効にし、ユーザーとグループを割り当てます。アクセスをテストおよび検証します。
次に、アプリケーションの SSO 手法を追加し、再びテストしてアクセスを検証します。
必要に応じて条件付きアクセスおよび 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 経由でそれにアクセスするアプリケーションプロキシを介してアクセスできることを確認します。

[ID]>[アプリケーション]>[エンタープライズアプリケーション]>[すべてのアプリケーション] の順に移動し、管理するアプリを選択します。
[アプリケーションプロキシ] を選びます。
[事前認証] フィールドで、ドロップダウンリストを使用して [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 ロールを確認し、個々のニーズに対処できる適したものを選択します。場合によっては、一部のロールは、一時的に適用してデプロイが完了した後で削除する必要があります。

ビジネスロール	ビジネスタスク	Microsoft Entra ロール
ヘルプデスク管理者	通常、エンドユーザーが報告した問題の特定、ユーザーのパスワード変更、リフレッシュトークンの無効化、サービスヘルスの監視といった限られたタスクの実行に限定されます。	ヘルプデスク管理者
ID 管理者	Microsoft Entra サインインレポートおよび監査ログを読み、アプリケーションプロキシ関連の問題をデバッグします。	セキュリティ閲覧者
アプリケーションの所有者	エンタープライズアプリケーション、アプリケーション登録、アプリケーションプロキシの設定の全側面を作成して管理します。	アプリケーション管理者
インフラストラクチャ管理者	証明書のロールオーバー所有者	アプリケーション管理者

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

しかし、それでもユーザーは日々の特権操作を実行する必要があるため、効果的な管理アクセスの管理と監査へのアプローチとしては、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 でイベントログのデータソースを構成するにはこのチュートリアルに従ってください。

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

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

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

次の方法で共有

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

実装の計画

前提条件