Microsoft Entra アプリケーション プロキシは、オンプレミスのアプリケーションのための安全でコスト効率の高いリモート アクセス ソリューションです。 "Cloud First" 組織は、最新のプロトコルをまだ使用できない従来のオンプレミス アプリケーションへのアクセスを管理するための即時移行パスを提供します。 概要については、「 アプリケーション プロキシとは」を参照してください。
リモート ユーザーが内部リソースにアクセスできるようにするには、アプリケーション プロキシをお勧めします。 このようなリモート アクセスのユース ケースでは、アプリケーション プロキシを使うと、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) を実行するために必要なユーザー識別子情報を取得できます。
条件付きアクセスの要件: イントラネット アクセスにアプリケーション プロキシを使用することはお勧めしません。ユーザーに影響を与える待機時間が増えるためです。 インターネットからのリモート アクセスには、事前認証ポリシーと条件付きアクセス ポリシーでアプリケーション プロキシを使用することをお勧めします。 イントラネットの使用のために条件付きアクセスを提供するアプローチは、アプリケーションが Microsoft Entra ID を使用して直接認証を行えるようにアプリケーションを最新化することです。 詳細については、「 アプリケーションを Microsoft Entra ID に移行するためのリソース」を参照してください。
サービスの制限: 個々のテナントによるリソースの過剰な消費から保護するために、アプリケーションとテナントごとに調整制限が設定されています。 これらの制限について確認するには、「Microsoft Entra サービスの制限と制約」を参照してください。 これらの調整制限は、一般的な使用ボリュームを超えるベンチマークに基づいており、ほとんどのデプロイに十分なバッファーを提供します。
パブリック証明書: カスタム ドメイン名を使用している場合は、TLS 証明書を調達する必要があります。 組織の要件によって異なりますが、証明書の入手には時間がかかることがあります。できるだけ早くこのプロセスを開始することをお勧めします。 Azure アプリケーション プロキシでは、標準、ワイルドカード、または SAN ベースの証明書がサポートされます。 詳細については、「 Microsoft Entra アプリケーション プロキシを使用してカスタム ドメインを構成する」を参照してください。
ドメイン要件: シングル サインオンに Kerberos 制約付き委任 (KCD) を使用するには、コネクタ サーバーとアプリケーション サーバーの両方がドメインに参加していて、同じドメインまたは信頼されたドメインに存在することを確認します。 コネクタ サービスはローカル システム アカウントで実行され、カスタム ID を使用しないでください。 詳細については、 シングル サインオンの KCD を参照してください。
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)、Apache on Linux、Tomcat、NGINX |
| ドメイン メンバーシップ | Web サーバーの完全修飾ドメイン名 (FQDN) |
| アプリケーションの場所 | インフラストラクチャ内で Web サーバーまたはファームがある場所 |
| 内部アクセス | 内部でアプリケーションにアクセスするときに使用される正確な URL。 ファームでどの種類の負荷分散が使用されているか。 アプリケーションがそれ自体以外のソースのコンテンツを描画するかどうか。 アプリケーションが WebSocket で動作するかどうかを決定します。 |
| 外部アクセス | 外部からアプリケーションが既に公開されている可能性があるベンダー ソリューション。 外部アクセス用に使用する URL です。 SharePoint の場合は、ガイダンスに従って代替アクセス マッピングが構成されていることを確認 します。 そうでない場合は、外部 URL を定義する必要があります。 |
| 公開証明書 | カスタム ドメインを使用している場合は、対応するサブジェクト名の証明書を取得します。 証明書が存在する場合は、そのシリアル番号と取得できる場所をメモします。 |
| 認証の種類 | アプリケーションによってサポートされる認証の種類では、Basic、Windows 統合認証、フォームベース、ヘッダーベース、要求などがサポートされます。 特定のドメイン アカウントで実行するようにアプリケーションが構成されている場合は、サービス アカウントの完全修飾ドメイン名 (FQDN) をメモします。 SAML ベースの場合は、識別子と応答 URL。 ヘッダーベースの場合は、ベンダー ソリューションと認証の種類を処理するための特定の要件。 |
| コネクタ グループ名 | バックエンド アプリケーションにコンジットと SSO を提供するように指定されたコネクタのグループの論理名。 |
| ユーザー/グループのアクセス | アプリケーションへの外部アクセスが許可されているユーザーまたはユーザー グループ。 |
| その他の要件 | アプリケーションの発行に組み込む必要があるリモート アクセスまたはセキュリティ要件に注意してください。 |
アプリケーション インベントリ スプレッドシートをダウンロードして、アプリのインベントリを作成できます。
組織の要件を定義する
以下に示すのは、組織のビジネス要件を定義する必要がある区分です。 各区分には要件の例が含まれています。
アクセス
ドメイン参加または Microsoft Entra 参加デバイスを持つリモート ユーザーは、シームレス シングル サインオン (SSO) を使用して発行済みプリケーションに安全にアクセスできます。
承認された個人デバイスを持つリモート ユーザーは、MFA に登録され、認証方法として携帯電話に Microsoft Authenticator アプリを登録していれば、公開されたアプリケーションに安全にアクセスできます。
ガバナンス
- 管理者は、アプリケーション プロキシを介して発行されたアプリケーションに対するユーザー割り当てのライフサイクルを定義して監視できます。
セキュリティ
- グループ メンバーシップで、または個別にアプリケーションに割り当てられたユーザーのみが、それらのアプリケーションにアクセスできます。
パフォーマンス
- 内部ネットワークからアプリケーションにアクセスする場合と比較して、アプリケーションのパフォーマンスが低下しません。
ユーザー エクスペリエンス
- ユーザーは、任意のデバイス プラットフォームで使い慣れた会社の 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 の無効化など、問題を分離するためにセットアップを簡略化します。 Telerik の Fiddler などのツールは、iOS や Android などのモバイル プラットフォームを含むトラフィックをトレースすることで、アクセスやコンテンツの問題をデバッグするのに役立ちます。 詳細については、トラブルシューティング ガイドを参照してください。
ソリューションを実装する
アプリケーション プロキシをデプロイする
アプリケーション プロキシをデプロイする手順については、 リモート アクセス用のオンプレミス アプリケーションを追加するためのチュートリアルで説明します。 インストールが正常に終了しない場合は、ポータルで [アプリケーション プロキシのトラブルシューティング] を選ぶか、アプリケーション プロキシ エージェント コネクタのインストールに関する問題のトラブルシューティング ガイドを使ってください。
アプリケーション プロキシを介してアプリケーションを発行する
アプリケーションの発行では、すべての前提条件を満たしていること、およびアプリケーション プロキシ ページに登録済みでアクティブなコネクタがいくつか表示されていることを前提としています。
PowerShell を使用してアプリケーションを発行することもできます。
アプリケーションを発行するときに従うベスト プラクティス:
[コネクタ グループの使用]: それぞれのアプリケーションを発行するために指定されたコネクタ グループを割り当てます。 高可用性とスケールを実現するために、各コネクタ グループには少なくとも 2 つのコネクタを用意することをお勧めします。 任意の時点でマシンにサービスを提供する必要がある場合は、3 つのコネクタが最適です。 さらに、Microsoft Entra プライベート ネットワーク コネクタ グループについてに関する記事を参照して、コネクタ グループを使用してネットワークまたは場所によってコネクタをセグメント化する方法を確認してください。
バックエンド アプリケーションのタイムアウトの設定: この設定は、アプリケーションでクライアント トランザクションの処理に 75 秒以上かかる場合に便利です。 たとえば、クライアントがデータベースのフロントエンドとして機能する Web アプリケーションにクエリを送信する場合などです。 フロントエンドはクエリをバックエンド データベース サーバーに送信し、応答を待機しますが、応答を受信するまでに、会話のクライアント側はタイムアウトします。タイムアウトを Long に設定すると、長いトランザクションが完了するまでに 180 秒かかります。
適切な Cookie タイプの使用
HTTP-Only Cookie: アプリケーション プロキシを set-cookie HTTP 応答ヘッダーに HTTPOnly フラグを含めることで、追加のセキュリティを提供します。 この設定は、クロスサイト スクリプティング (XSS) などの悪用を軽減するのに役立ちます。 セッション Cookie へのアクセスが必要なクライアント/ユーザー エージェントの場合は、[いいえ] に設定したままにします。 たとえば、アプリケーション プロキシ経由で発行されたリモート デスクトップ ゲートウェイに接続する RDP/MTSC クライアントです。
セキュリティで保護された Cookie: Secure 属性を使用して Cookie が設定されている場合、ユーザー エージェント (クライアント側アプリ) は、要求が TLS で保護されたチャネル経由で送信される場合にのみ、HTTP 要求に Cookie を含めます。 この設定は、クリア テキスト チャネルで Cookie が侵害されるリスクを軽減するのに役立ちます。そのため、有効にする必要があります。
永続 Cookie: アプリケーション プロキシのセッション Cookie を、期限切れになるか削除されるまで有効にしておくことで、ブラウザーをクローズした後でも永続化できます。 Office などのリッチ アプリケーションが発行された Web アプリケーション内のドキュメントにアクセスするシナリオで、ユーザーが認証を再開しない場合に使用されます。 ただし、永続的な Cookie を使用すると、他の補正制御で使用されていない場合、最終的にサービスが不正アクセスのリスクにさらされる可能性があるため、注意して有効にしてください。 この設定は、プロセス間で Cookie を共有できない古いアプリケーションにのみ使用する必要があります。 設定を使用する代わりに、プロセス間での Cookie の共有を処理するようにアプリケーションを更新することをお勧めします。
ヘッダー内の URL を変換する: 組織のパブリック名前空間 (分割 DNS など) と一致するように内部 DNS を構成できないシナリオの設定を有効にします。 アプリケーションがクライアント要求で元のホスト ヘッダーを必要とする場合を除き、値は [はい] に設定したままにします。 代わりに、コネクタが、実際のトラフィックのルーティングに内部 URL の FQDN を使用し、ホストヘッダーとして外部 URL の FQDN を使用するようにします。 ほとんどの場合、代替策によって、リモートアクセスした際にもアプリケーションが通常どおり機能することが可能ですが、ユーザーは内部と外部のURLが一致することによる利点を失うことになります。
アプリケーション本文の URL を変換する:クライアントへの応答で、そのアプリからのリンクを変換したい場合に、アプリのアプリケーション本文のリンク変換をオンにします。 この関数を有効にすると、アプリケーション プロキシが HTML および CSS 応答で見つけたすべての内部リンクをクライアントに変換するためのベスト エフォート試行が提供されます。 これは、ハードコーディングされた絶対リンクまたは NetBIOS shortname リンクをコンテンツに含むアプリ、または他のオンプレミス アプリケーションにリンクするコンテンツを含むアプリを発行する場合に便利です。
発行済みアプリが他の発行済みアプリにリンクするシナリオでは、各アプリケーションのリンクの変換を有効にして、各アプリ レベルでのユーザー エクスペリエンスを制御できるようにします。
たとえば、すべてが相互にリンクする、アプリケーション プロキシ経由で公開された 3 つのアプリケーション (福利厚生、経費、出張) に加えて、アプリケーション プロキシ経由で公開されていないフィードバックという 4 番目のアプリがあるとします。
特典アプリでリンク変換が有効になっている場合、Expenses アプリと Travel アプリへのリンクが外部 URL にリダイレクトされ、外部ユーザーがアクセスできるようになります。 ただし、これらのアプリに対してリンク変換が有効になっていない限り、Expenses と Travel から Benefits へのリンクは機能しません。 フィードバック アプリのリンクは、外部 URL がないためリダイレクトされず、外部ユーザーが特典アプリを介してアクセスできなくなります。 詳細については、 リンク変換とリダイレクトのオプションを参照してください。
アプリケーションにアクセスする
シナリオとスケーラビリティの要件に最も適したアプローチを選択して、アプリケーション プロキシが発行したリソースへのアクセスを管理します。 一般的な方法としては、Microsoft Entra Connect を介したオンプレミス グループの同期、ユーザー属性に基づく Microsoft Entra ID での動的グループの作成、リソース所有者が管理するセルフサービス グループの有効化、またはこれらの戦略の組み合わせなどがあります。 リンクされたリソースを調べて、各方法の利点を理解します。
アプリケーションにユーザー アクセスを割り当てる最もわかりやすい方法は、発行済みアプリケーションの左側のウィンドウの [ユーザーとグループ] オプションに移動し、グループまたはユーザーを直接割り当てることです。
また、ユーザーが現在メンバーになっていないグループを割り当て、セルフサービス オプションを構成することで、ユーザーがアプリケーションにセルフサービスでアクセスできるようにすることもできます。
有効にした場合、ユーザーは MyApps ポータルにサインインしてアクセスを要求します。 これらは自動的に承認され、セルフサービス グループに追加されるか、指定された承認者からの承認が必要です。
ゲスト ユーザーを、Microsoft Entra B2B を通じてアプリケーション プロキシ経由で発行された内部アプリケーションにアクセスするように招待することもできます。
通常は匿名でアクセス可能で、認証を必要としないオンプレミス アプリケーションの場合は、アプリケーションの プロパティにあるオプションを無効にすることをお勧めします。
[いいえ] に設定したままにすると、ユーザーはアクセス許可なしで Microsoft Entra アプリケーション プロキシ経由でオンプレミス アプリケーションにアクセスできます。そのため、注意して使用してください。
アプリケーションがいったん発行されると、外部 URL をブラウザーに入力するか https://myapps.microsoft.com のアイコンを使用してアクセスできます。
事前認証を有効にする
アプリケーションに、外部 URL 経由でそれにアクセスするアプリケーション プロキシを介してアクセスできることを確認します。
Entra ID>Enterprise アプリ>すべてのアプリケーションを参照し、管理するアプリを選択します。
[アプリケーション プロキシ] を選びます。
[事前認証] フィールドで、ドロップダウン リストを使用して [Microsoft Entra ID] を選択し、[保存] を選択します。 事前認証が有効になっている場合、Microsoft Entra ID は最初にユーザーを認証します。 シングル サインオンが設定されている場合、バックエンド アプリケーションはアクセス権を付与する前にユーザーも確認します。 事前認証モードをパススルーから Microsoft Entra ID に切り替えると、外部 URL が HTTPS で保護され、最初に HTTP を使用するすべてのアプリケーションが HTTPS 経由で動作するようになります。
シングル サインオンの有効化
SSO では、ユーザーが Microsoft Entra ID を使用して 1 回サインインできるようにすることで、ユーザー エクスペリエンスとセキュリティが向上します。 事前認証後、プライベート ネットワーク コネクタはユーザーのオンプレミス アプリケーションにサインインし、ユーザーが直接サインインしたかのように表示されます。
パススルー オプションを選択すると、ユーザーは Microsoft Entra ID に対して認証する必要は一切なく、発行済みアプリケーションにアクセスできます。
SSO を有効にするには、アプリケーションで Microsoft Entra ID を使用してユーザーを事前認証する必要があります。 事前認証がないと、SSO オプションは使用できません。
「Microsoft Entra ID 内のアプリケーションへのシングル サインオン」を読むと、アプリケーションを構成するときに最適な SSO の手法の選択に役立ちます。
他の種類のアプリケーションを操作する
Microsoft Entra アプリケーション プロキシは、 Microsoft Authentication Library (MSAL) を使用して構築されたアプリケーションをサポートします。 クライアント要求ヘッダーで Microsoft Entra ID トークンを使用してネイティブ クライアント アプリを処理し、ユーザーを事前認証します。
アプリケーション プロキシの使用可能な構成について説明します。 ネイティブ クライアント アプリとモバイル クライアント アプリの発行とクレーム ベース アプリケーションを読みます。
条件付きアクセスによるセキュリティの強化
アプリケーションのセキュリティでは、オンプレミスおよびクラウドでの複雑な脅威から保護して対応できる、一連の高度なセキュリティ機能が必要です。 条件付きアクセス ポリシーを使用して、場所、リスク、デバイスの種類、デバイスコンプライアンスなどの多くの条件に基づいてアプリケーションへのアクセスを制御します。 展開する可能性があるポリシーの例については、「条件付きアクセス テンプレート」を参照してください。
Microsoft Entra アプリケーション プロキシをサポートするために以下の機能を使用できます。
ユーザーおよびロケーションベースの条件付きアクセス:ロケーションベースの条件付きアクセス ポリシーでは、地理的な場所や IP アドレスに基づいてユーザー アクセスを制限することで機密データを保護します。
デバイスベースの条件付きアクセス:デバイスベースの条件付きアクセスでは、登録され承認された準拠デバイスのみが会社のデータにアクセスできます。
アプリケーションベースの条件付きアクセス:会社のネットワークに接続していないときでも、仕事を中断するわけにはいきません。 企業クラウドおよびオンプレミス アプリへのアクセスを保護し、条件付きアクセスによる制御を管理します。
リスクベースの条件付きアクセス:リスクベースの条件付きアクセス ポリシーを使用し、悪意のあるハッカーからデータを保護しましょう。これらのポリシーは、オンプレミスかクラウドかにかかわらず、すべてのアプリとすべてのユーザーに適用できます。
Microsoft Entra マイ アプリ: アプリケーション プロキシ サービスがデプロイされ、アプリケーションが安全に発行されて、ユーザーにすべてのアプリケーションを検出してアクセスするための単純なハブを提供します。 マイ アプリを使用すると、ユーザーが新しいアプリやグループへのアクセスを要求したり、他のユーザーに代わってこれらのリソースへのアクセスを管理したりする機能などのセルフサービス機能を使用して生産性が向上します。
実装を管理する
必要なロール
Microsoft は、Microsoft Entra ID を使用して必要なタスクを実行するための最小限の特権の付与の原則を提唱しています。 使用可能なさまざまな Azure ロールを確認し、個々のニーズに対処できる適したものを選択します。 一部のロールは、デプロイの完了後に一時的に適用して削除する必要があります。
| ビジネス ロール | ビジネス タスク | Microsoft Entra ロール |
|---|---|---|
| ヘルプ デスク管理者 | パスワードのリセット、更新トークンの無効化、サービスの正常性の確認などの基本的なユーザー サポート タスクを処理します。 | ヘルプデスク管理者 |
| ID 管理者 | Microsoft Entra サインイン レポートおよび監査ログを読み、アプリケーション プロキシ関連の問題をデバッグします。 | セキュリティ閲覧者 |
| アプリケーションの所有者 | エンタープライズ アプリケーション、アプリケーション登録、アプリケーション プロキシの設定の全側面を作成して管理します。 | アプリケーション管理者 |
| インフラストラクチャ管理者 | 証明書のロールオーバー所有者 | アプリケーション管理者 |
セキュリティで保護された情報またはリソースへのアクセス権を持つユーザーの数を最小限に抑えることで、悪意のあるアクターが不正アクセスを取得したり、承認されたユーザーが誤って機密性の高いリソースに影響を与えたりする可能性を減らすことができます。
管理アクセスを効果的に管理し、適切な監査を確保するには、 Privileged Identity Management で Just-In-Time (JIT) アクセスを使用することをお勧めします。 この方法では、必要な場合にのみ、Azure リソースと Microsoft Entra ID へのオンデマンド特権アクセスが提供されます。
レポートと監視
Microsoft Entra ID は、 監査ログとレポートを使用して、組織のアプリケーションの使用状況と運用の正常性に関するより多くの分析情報を提供します。 アプリケーション プロキシを使用すると、Microsoft Entra 管理センターと Windows イベント ログからコネクタを簡単に監視できます。
アプリケーションの監査ログ
これらのログでは、アプリケーション プロキシで構成されたアプリケーションへのログインと、アプリケーションにアクセスしているデバイスとユーザーに関する、詳細な情報が提供されます。 監査ログは Microsoft Entra 管理センター内にあり、エクスポート用は Audit API にあります。 また、使用状況と分析情報のレポートもアプリケーションで利用できます。
プライベート ネットワーク コネクタの監視
コネクタとサービスは、高可用性のすべてのタスクに対処します。 Microsoft Entra 管理センターのアプリケーション プロキシのページから、コネクタの状態を監視できます。 コネクタのメンテナンスの詳細については、「 Microsoft Entra プライベート ネットワーク コネクタについて」を参照してください。
Windows イベント ログおよびパフォーマンス カウンター
コネクタには管理者ログとセッション ログがあります。 管理者ログには主要なイベントとそのエラーが含まれます。 セッション ログには、すべてのトランザクションとその処理の詳細が含まれます。 ログとカウンターは、Windows イベント ログにあります。 詳細については、「 Microsoft Entra プライベート ネットワーク コネクタについて」を参照してください。 チュートリアルに従って 、Azure Monitor でイベント ログ データ ソースを構成します。
トラブルシューティングのガイドと手順
一般的な問題や、それらの問題を解決するためにエラー メッセージをトラブルシューティングする方法について学びます。
関連コンテンツ
次の記事では一般的なシナリオが説明されています。これらを使用してサポート組織のために独自のトラブルシューティング ガイドを作成することもできます。