Azure AD アプリケーション プロキシを使用してリモート ユーザー向けにオンプレミス アプリを発行する

Azure Active Directory (Azure AD) には、クラウドとオンプレミスのユーザー、アプリ、およびデータを保護するための機能が数多く用意されています。 特に Azure AD アプリケーション プロキシ機能は、オンプレミス Web アプリケーションを外部に発行したい IT プロフェッショナルによって実装されます。 これにより、内部アプリケーションにアクセスする必要があるリモート ユーザーが、安全にそれらにアクセスできるようになります。

最新の職場環境では、ネットワークの外部から内部アプリケーションに安全にアクセスできるようにすることが、よりいっそう重要になります。 BYOD (Bring Your Own Device) やモバイル デバイスなどのシナリオで、IT プロフェッショナルは次の 2 つの目標を達成することを求められます。

  • エンド ユーザーが場所や時間を問わず効率的に働けるようにすること
  • 企業の資産を常に保護すること

多くの組織は、リソースが企業ネットワークの境界内にある限り、すべてが管理下にあり、安全であると考えています。 しかし、今日のデジタル ワークプレースにおいて、その境界はマネージド モバイル デバイスやクラウド上のリソースやサービスにまで広がっています。 そこで、ユーザーの ID と、彼らのデバイスやアプリに格納されたデータを保護するという、複雑な管理タスクが生じます。

お客様は既に Azure AD を使用して、Microsoft 365 や他の SaaS アプリケーション、さらにはオンプレミスでホストされている Web アプリケーションにアクセスする必要があるクラウド ユーザーを管理しているかもしれません。 既に Azure AD がある場合は、それを 1 つのコントロール プレーンとして利用して、オンプレミス アプリケーションへのシームレスかつ安全なアクセスを実現できます。 または、クラウドへの移行をまだ検討中かもしれません。 その場合は、アプリケーション プロキシを実装し、強力な ID 基盤を構築する最初の一歩を踏み出すことで、クラウドへの移行を開始できます。

次の一覧は、包括的なものではありませんが、ハイブリッド共存シナリオでアプリケーション プロキシの実装によって実現することを示しています。

  • DMZ を使用しない簡単な方法でオンプレミス Web アプリケーションを外部に発行する
  • クラウドとオンプレミスのデバイス、リソース、アプリ全体でシングル サインオン (SSO) をサポートする
  • クラウドとオンプレミスのアプリケーションに対する多要素認証をサポートする
  • Microsoft Cloud のセキュリティを備えたクラウド機能をすぐに活用する
  • ユーザー アカウントを一元的に管理する
  • ID とセキュリティを一元的に制御する
  • グループ メンバーシップに基づいてアプリケーションへのユーザー アクセスを自動的に追加または削除する

この記事では、Azure AD とアプリケーション プロキシを使用して、リモート ユーザーにシングル サインオン (SSO) エクスペリエンスを提供する方法について説明します。 VPN またはデュアル ホーム サーバーとファイアウォール規則を使用しなくても、ユーザーはオンプレミス アプリケーションに安全に接続します。 この記事は、アプリケーション プロキシがどのようにしてオンプレミス Web アプリケーションにクラウドの機能とセキュリティ上の利点をもたらすかを理解するのに役立ちます。 また、使用可能なアーキテクチャとトポロジについても説明しています。

過去のリモート アクセス

以前は、リモート ユーザーによるアクセスを支援しながら内部リソースを攻撃者から保護する場合、そのコントロール プレーンは DMZ (境界ネットワーク) がすべてでした。 しかし、外部クライアントが企業リソースにアクセスするために使用する、DMZ にデプロイされた VPN やリバース プロキシ ソリューションは、クラウドの世界には適していません。 通常は、次のような問題に悩まされることになります。

  • ハードウェアのコスト
  • セキュリティの維持 (修正プログラムの適用、ポートの監視など)
  • エッジでのユーザーの認証
  • 境界ネットワーク内で Web サーバーに対してユーザーを認証する
  • VPN クライアント ソフトウェアの配布と構成により、リモート ユーザーの VPN アクセスを維持する。 また、DMZ 内でドメインに参加しているサーバーを保持する (外部攻撃に対して脆弱になる可能性があります)。

今日のクラウド ファーストの世界で、ネットワークにアクセスする人や物を制御するには、Azure AD が最適です。 Azure AD アプリケーション プロキシは、最新の認証およびクラウドベースのテクノロジ (SaaS アプリケーションや ID プロバイダーなど) と統合されます。 この統合により、ユーザーはどこからでもアプリケーションにアクセスできます。 アプリケーション プロキシは、今日のデジタル ワークプレースにより適しているだけでなく、VPN やリバース プロキシ ソリューションよりも安全であり、より簡単に実装できます。 リモート ユーザーは、Microsoft や Azure AD に統合された他の SaaS アプリにアクセスするのと同じように、オンプレミスのアプリケーションにアクセスできます。 アプリケーション プロキシを使用するためにアプリケーションを変更または更新する必要はありません。 さらに、アプリケーション プロキシでは、ファイアウォールを介したインバウンド接続を開く必要がありません。 アプリケーション プロキシは、一度設定すれば後は放っておけばよいのです。

リモート アクセスの未来

今日のデジタル ワークプレースでは、ユーザーはさまざまな場所で複数のデバイスやアプリケーションを使用します。 唯一変わらないのは、ユーザー ID です。 それが、今日のネットワーク保護の最初の手順として、Azure AD の ID 管理機能をセキュリティ コントロール プレーンとして使う理由です。 ID をコントロール プレーンとして使用するモデルは、通常は次のコンポーネントで構成されます。

  • ユーザーおよびユーザーに関連する情報を追跡する ID プロバイダー。
  • 企業リソースへのアクセス権を持つデバイスの一覧を保持するデバイス ディレクトリ。 このディレクトリには、対応するデバイス情報 (デバイスの種類、整合性など) が含まれています。
  • ユーザーとデバイスが、セキュリティ管理者によって設定されたポリシーに準拠していることを確認するポリシー評価サービス。
  • 組織のリソースへのアクセスを許可または拒否する権限。

Azure AD はアプリケーション プロキシを使用して、オンプレミスとクラウドに発行された Web アプリケーションにアクセスする必要があるユーザーを追跡します。 これは、これらのアプリケーションの一元管理ポイントを提供します。 Azure AD の条件付きアクセスは必須ではありませんが、有効にすることをお勧めします。 ユーザーを認証してアクセス権を付与する条件を定義することで、より確実に、適切なユーザーだけにアプリケーションへのアクセス権を持たせることができます。

注: Azure AD アプリケーション プロキシは、内部リソースへのアクセスが必要なローミング (リモート) ユーザー向けの VPN やリバース プロキシに代わるものであることを理解しておく必要があります。 企業ネットワーク上の内部ユーザー用ではありません。 内部ユーザーがアプリケーション プロキシを不必要に使用すると、予期せず、望ましくないパフォーマンスの問題が発生する可能性があります。

Azure Active Directory とすべてのアプリ

アプリケーション プロキシのしくみの概要

アプリケーション プロキシは、Azure portal で構成する Azure AD サービスです。 これを使用して、Azure Cloud に外部のパブリック HTTP/HTTPS URL エンドポイントを発行し、それを組織の内部アプリケーション サーバーの URL に接続することができます。 これらのオンプレミス Web アプリケーションは、シングル サインオンをサポートするために Azure AD と統合することができます。 これによりエンド ユーザーは、Microsoft 365 や他の SaaS アプリケーションにアクセスするのと同じように、オンプレミスの Web アプリケーションにアクセスすることができます。

この機能のコンポーネントには、クラウドで実行するアプリケーション プロキシ サービス、オンプレミスのサーバーで実行する軽量エージェントのアプリケーション プロキシ コネクタ、および ID プロバイダーの Azure AD が含まれます。 これら 3 つのコンポーネントがすべて連携し、オンプレミス Web アプリケーションにアクセスするためのシングル サインオン エクスペリエンスがユーザーに提供されます。

外部ユーザーは、サインイン後、使い慣れた URL を使用するか、自分のデスクトップまたは iOS/MAC デバイスのマイ アプリから、オンプレミス Web アプリケーションにアクセスできます。 たとえば、アプリケーション プロキシでは、リモート デスクトップ、SharePoint サイト、Tableau、Qlik、Outlook on the web、および基幹業務 (LOB) アプリケーションへのリモート アクセスとシングル サインオンを提供できます。

Azure AD アプリケーション プロキシのアーキテクチャ

認証

シングル サインオン用にアプリケーションを構成する方法は複数あります。アプリケーションで使用する認証に適した方法を選んでください。 アプリケーション プロキシでは、次の種類のアプリケーションがサポートされています。

  • Web アプリケーション
  • さまざまなデバイスの豊富なアプリケーションに公開する Web API
  • リモート デスクトップ ゲートウェイの背後でホストされているアプリケーション
  • Microsoft Authentication Library (MSAL) と統合されるリッチ クライアント アプリ

アプリケーション プロキシは、次のネイティブ認証プロトコルを使用するアプリで動作します。

  • 統合 Windows 認証 (IWA) 。 IWA の場合、アプリケーション プロキシ コネクタは、Kerberos アプリケーションに対して Kerberos 制約付き委任 (KCD) を使用し、ユーザーを認証します。

サード パーティ統合または特定の構成のシナリオでは、アプリケーション プロキシは次の認証プロトコルもサポートしています。

  • ヘッダーベースの認証。 このサインオン方法は、PingAccess というサード パーティの認証サービスを使用し、アプリケーションがヘッダーを使って認証する場合に使用されます。 このシナリオでは、認証は PingAccess によって処理されます。
  • フォームまたはパスワード ベースの認証。 この認証方法では、ユーザーは初回アクセス時にユーザー名とパスワードを使用してアプリケーションにサインオンします。 最初のサインイン後は、Azure AD がユーザー名とパスワードをアプリケーションに提供します。 このシナリオでは、認証は Azure AD によって処理されます。
  • SAML 認証。 SAML ベースのシングル サインオンは、SAML 2.0 または WS-Federation のいずれかのプロトコルを使用するアプリケーションでサポートされます。 SAML によるシングル サインオンでは、ユーザーの Azure AD アカウントを使用して、Azure AD がアプリケーションに対して認証を行います。

サポートされている方法の詳細については、「シングル サインオンの方法の選択」を参照してください。

セキュリティ上の利点

アプリケーション プロキシと Azure AD によって提供されるリモート アクセス ソリューションには、お客様にとって次のようなセキュリティ上の利点があります。

  • 認証済みのアクセス。 アプリケーション プロキシは、認証された接続のみがネットワークにアクセスできるようにする、事前認証を使ったアプリケーションの発行に最も適しています。 事前認証を利用して発行されるアプリケーションでは、有効なトークンがないと、トラフィックがアプリケーション プロキシ サービスを通過してお客様のオンプレミス環境に到達することはできません。 事前認証はその性質上、認証された ID のみにバックエンド アプリケーションへのアクセスを許可するため、多数の標的型攻撃がブロックされます。

  • 条件付きアクセス。 ネットワークへの接続が確立される前に、多数のポリシー制御を適用できます。 条件付きアクセスを使用すると、自分のバックエンド アプリケーションにアクセスできるトラフィックの制限を定義できます。 場所、認証の強度、およびユーザーのリスク プロファイルに基づいてサインインを制限するポリシーを作成します。 条件付きアクセスの進化に伴い、Microsoft Cloud App Security (MCAS) との統合など、追加のセキュリティを提供するさまざまなコントロールが追加されています。 MCAS の統合により、条件付きアクセス ポリシーに基づいてセッションをリアルタイムで監視および制御する条件付きアクセスを活用して、リアルタイム監視用にオンプレミス アプリケーションを構成することができます。

  • トラフィックの終了。 バックエンド アプリケーションへのトラフィックはすべて、クラウド上のアプリケーション プロキシ サービスで終了し、セッションはバックエンド サーバーで再確立されます。 この接続戦略では、HTTP トラフィックを送信するためにバックエンド サーバーが公開されることはありません。 ファイアウォールが攻撃を受けないため、標的型 DoS (サービス拒否) 攻撃に対して優れた保護を実現します。

  • すべてのアクセスが外向き。 アプリケーション プロキシ コネクタは、ポート 80 と 443 を経由する、クラウド上のアプリケーション プロキシ サービスへのアウトバウンド接続のみを使用します。 インバウンド接続がないので、DMZ で着信接続またはコンポーネント用にファイアウォール ポートを開く必要はありません。 すべての接続は外向きであり、セキュリティで保護されたチャネル経由で行われます。

  • セキュリティ分析と機械学習 (ML) ベースのインテリジェンス。 アプリケーション プロキシは、Azure Active Directory の一部であるため、Azure AD Identity Protection (Premium P2 ライセンスが必要です) を利用できます。 Azure AD Identity Protection は、Microsoft の Digital Crimes Unit および Microsoft Security Response Center からのデータ フィードと機械学習セキュリティ インテリジェンスを組み合わせて、侵害されたアカウントをプロアクティブに特定します。 Identity Protection は、危険度の高いサインインからリアルタイムで保護します。感染したデバイスからのアクセス、匿名ネットワークを通じたアクセス、通常とは異なる場所からのアクセスなどの要因も考慮して、セッションのリスク プロファイルを拡大します。 このリスク プロファイルが、リアルタイムの保護に使用されます。 これらのレポートとイベントの多くは、お客様の SIEM システムとの統合を可能にする API を通じて既に使用可能です。

  • サービスとしてのリモート アクセス。 リモート アクセスを可能にするために、オンプレミス サーバーの保守やパッチの適用について心配する必要がありません。 アプリケーション プロキシは Microsoft によるインターネット規模のサービスであるため、常に最新のセキュリティ パッチとアップグレードを取得できます。 パッチの適用されていないソフトウェアは、依然として多数の攻撃の的となっています。 国土安全保障省によれば、標的型攻撃の 85% は可避することができます。 このサービス モデルを使用すれば、エッジ サーバーの管理という重荷から解放され、必要に迫られてパッチを適用する必要もなくなります。

  • Intune の統合。 Intune では、企業のトラフィックは個人のトラフィックとは別にルーティングされます。 アプリケーション プロキシにより、企業のトラフィックが確実に認証されるようになります。 アプリケーション プロキシと Intune Managed Browser の機能を併用し、リモート ユーザーが iOS および Android デバイスから内部 Web サイトに安全にアクセスできるようにすることも可能です。

クラウドへのロードマップ

アプリケーション プロキシを実装するもう 1 つの大きなメリットは、Azure AD をオンプレミス環境に拡張できる点にあります。 実際、アプリケーション プロキシの実装は、組織とアプリケーションをクラウドに移行するための重要なステップです。 クラウドに移行してオンプレミスの認証から解放されることで、オンプレミスのフットプリントを削減し、Azure AD の ID 管理機能をコントロール プレーンとして使用することができます。 既存のアプリケーションへの更新は最小限または一切なしで、シングル サインオン、多要素認証、一元管理などのクラウド機能を利用できます。 アプリケーション プロキシに必要なコンポーネントをインストールすることは、リモート アクセス フレームワークを確立するための簡単なプロセスです。 また、クラウドに移行することで、高可用性やディザスター リカバリーなど、Azure AD の最新の機能や更新プログラムを利用することができます。

Azure AD へのアプリの移行の詳細については、Azure Active Directory へのアプリケーションの移行に関する記事を参照してください。

Architecture

次の図は、Azure AD 認証サービスとアプリケーション プロキシがどのように連携して、オンプレミス アプリケーションへのシングル サインオンをエンド ユーザーに提供するかを示します。

Azure AD アプリケーション プロキシの認証フロー

  1. エンドポイントを介してアプリケーションにアクセスしたユーザーは、Azure AD のサインイン ページにリダイレクトされます。 条件付きアクセス ポリシーが構成済みであれば、この時点で特定の条件がチェックされ、組織のセキュリティ要件に準拠していることが確認されます。
  2. サインインに成功すると Azure AD はユーザーのクライアント デバイスにトークンを送信します。
  3. クライアントはここでアプリケーション プロキシ サービスにトークンを送信します。アプリケーション プロキシ サービスは、そのトークンからユーザー プリンシパル名 (UPN) とセキュリティ プリンシパル名 (SPN) を取得します。
  4. アプリケーション プロキシが要求を転送し、それをアプリケーション プロキシ コネクタが受信します。
  5. このコネクタは、ユーザーの代わりに必要なその他の認証を実行し ("認証方法によっては省略可能")、アプリケーション サーバーの内部エンドポイントを要求し、オンプレミス アプリケーションに要求を送信します。
  6. アプリケーション サーバーからの応答は、アプリケーション プロキシ サービスへのコネクタ経由で送信されます。
  7. 応答はアプリケーション プロキシ サービスからユーザーに送信されます。
コンポーネント 説明
エンドポイント エンドポイントは、URL またはエンド ユーザー ポータルです。 ユーザーは、外部 URL にアクセスすることによって、ネットワークの外部にいてもアプリケーションに到達できます。 ネットワーク内のユーザーは、URL またはエンド ユーザー ポータルからアプリケーションにアクセスできます。 ユーザーは、これらのエンドポイントの 1 つに移動すると、Azure AD で認証され、コネクタを介してオンプレミスのアプリケーションにルーティングされます。
Azure AD Azure AD は、クラウドに格納されているテナント ディレクトリを使用して認証を実行します。
アプリケーション プロキシ サービス このアプリケーション プロキシ サービスは、Azure AD の一部としてクラウドで実行されます。 これは、ユーザーからアプリケーション プロキシ コネクタにシングル サインオン トークンを渡します。 アプリケーション プロキシは、要求のすべてのアクセス可能なヘッダーを、そのプロトコルに従って設定し、クライアント IP アドレスに転送します。 プロキシへの着信要求に既にそのヘッダーがある場合、ヘッダーの値であるコンマ区切りリストの末尾にクライアント IP アドレスが追加されます。
アプリケーション プロキシ コネクタ コネクタは、ネットワーク内の Windows Server 上で実行する軽量エージェントです。 コネクタは、クラウド内のアプリケーション プロキシ サービスとオンプレミス アプリケーション間の通信を管理します。 コネクタは発信接続のみ使用するため、受信ポートを開いたり、DMZ に配置したりする必要はありません。 コネクタはステートレスで、必要に応じて情報がクラウドから取得されます。 負荷分散や認証の方法など、コネクタについて詳しくは、「Azure AD アプリケーション プロキシ コネクタを理解する」をご覧ください。
Active Directory (AD) Active Directory はオンプレミスで実行され、ドメイン アカウントの認証を行います。 シングル サインオンが構成されている場合、コネクタは必要な追加認証を実行するために AD と通信します。
オンプレミスのアプリケーション 最終的にユーザーは、オンプレミス アプリケーションにアクセスできます。

Azure AD アプリケーション プロキシは、クラウドベースのアプリケーション プロキシ サービスとオンプレミス コネクタで構成されます。 コネクタは、アプリケーション プロキシ サービスからの要求をリッスンし、内部アプリケーションへの接続を処理します。 すべての通信は TLS 経由で発生し、常にコネクタで生成されて、アプリケーション プロキシ サービスに送られる点に注意することが重要です。 つまり、外向きの通信のみです。 コネクタはクライアント証明書を使用して、すべての呼び出しに対してアプリケーション プロキシ サービスを認証します。 接続のセキュリティの唯一の例外は、クライアント証明書が確立される最初のセットアップ手順です。 詳しくは、アプリケーション プロキシの「コネクタの性能」をご覧ください。

アプリケーション プロキシ コネクタ

アプリケーション プロキシ コネクタは、オンプレミスにデプロイされている軽量エージェントで、クラウド上のアプリケーション プロキシ サービスへのアウトバウンド接続を容易にします。 コネクタは、バックエンド アプリケーションへのアクセス権を持つ Windows Server にインストールする必要があります。 ユーザーは、コネクタを通じてアプリケーションにトラフィックをルーティングするアプリケーション プロキシ クラウド サービスに接続します (次の図を参照)。

Azure AD アプリケーション プロキシのネットワーク接続

コネクタとアプリケーション プロキシ サービス間のセットアップと登録は、次のように行われます。

  1. IT 管理者は、外向きのトラフィックに対してポート 80 と 443 を開き、コネクタ、アプリケーション プロキシ サービス、および Azure AD で必要とされる複数の URL へのアクセスを許可します。
  2. 管理者は、Azure portal にサインインし、実行可能ファイルを実行してオンプレミスの Windows Server にコネクタをインストールします。
  3. コネクタは、アプリケーション プロキシ サービスの "リッスン" を開始します。
  4. 管理者は、Azure AD にオンプレミス アプリケーションを追加し、ユーザーがアプリケーションに接続するために必要な設定 (URL など) を構成します。

詳しくは、「Azure AD アプリケーション プロキシのデプロイ計画」をご覧ください。

冗長性とスケーラビリティのため、常に複数のコネクタをデプロイすることをお勧めします。 コネクタは、サービスと共に、高可用性のすべてのタスクを処理します。また、動的に追加または削除することができます。 新しい要求を受信するたびに、使用できるコネクタのいずれかにルーティングされます。 コネクタが動作してサービスに接続すると、アクティブな状態が保たれます。 コネクタは、一時的に使用できない場合はトラフィックに応答しません。 使用していないコネクタは非アクティブとしてタグ付けされ、非アクティブな状態が 10 日間続くと削除されます。

また、コネクタはサーバーをポーリングして、新しいバージョンのコネクタがあるかどうかを調べます。 コネクタは手動更新できますが、Application Proxy Connector Updater サービスを実行している限りは自動更新されます。 複数のコネクタを持つテナントの場合、環境でのダウンタイムを避けるために、自動更新では各グループで一度に 1 つのコネクタが対象となります。

注意

アプリケーション プロキシのバージョン履歴ページを監視して RSS フィードに登録することで、更新がリリースされたときに通知を受け取ることができます。

各アプリケーション プロキシ コネクタは、コネクタ グループに割り当てられます。 同じコネクタ グループに属するコネクタは、高可用性と負荷分散のために単一のユニットとして動作します。 Azure portal で新しいグループを作成し、コネクタをそれらに割り当てたら、特定のアプリケーションに対応する特定のコネクタを割り当てることができます。 高可用性のためには、各コネクタ グループに少なくとも 2 つのコネクタを割り当てることをお勧めします。

コネクタ グループは、次のシナリオをサポートする必要がある場合に役立ちます。

  • 地理的なアプリの発行
  • アプリケーションのセグメント化と分離
  • クラウドまたはオンプレミスで実行されている Web アプリの発行

コネクタのインストール場所の選び方とネットワークの最適化について詳しくは、「Azure Active Directory アプリケーション プロキシを使用する場合のネットワーク トポロジに関する注意事項」をご覧ください。

その他のユース ケース

ここまでは、主にクラウドとオンプレミスのすべてのアプリケーションへのシングル サインオンを有効にしながら、アプリケーション プロキシを使用してオンプレミス アプリケーションを外部に発行する方法について説明してきました。 ただし、アプリケーション プロキシには他にも重要なユース ケースがあります。 具体的な内容を次に示します。

  • REST API の安全な発行。 ビジネス ロジックや API をオンプレミスで実行しているか、クラウド上の仮想マシンでホストしている場合、アプリケーション プロキシによって API アクセス用のパブリック エンドポイントが提供されます。 API エンドポイント アクセスでは、着信ポートを必要とせず、認証と認可を制御できます。 Azure AD Premium の機能を通じて追加のセキュリティが提供されます (多要素認証や、Intune を使用したデスクトップ、iOS、MAC、および Android デバイス向けのデバイス ベースの条件付きアクセスなど)。 詳しくは、「ネイティブ クライアント アプリケーションからプロキシ アプリケーションを操作できるようにする方法」および「Azure Active Directory と API Management で OAuth 2.0 を使用して API を保護する」をご覧ください。
  • リモート デスクトップ サービス (RDS) . RDS の標準的なデプロイでは、インバウンド接続を開く必要があります。 ただし、アプリケーション プロキシを使用した RDS デプロイには、コネクタ サービスを実行しているサーバーからの永続的なアウトバウンド接続があります。 これにより、リモート デスクトップ サービスを通じてオンプレミスのアプリケーションを発行し、エンド ユーザーにより多くのアプリケーションを提供することができます。 RDS に対する 2 段階認証と条件付きアクセス制御の限定的なセットを使用して、デプロイの攻撃対象領域を減らすこともできます。
  • Websocket を使用して接続するアプリケーションの発行Qlik Sense のサポートはパブリック プレビュー段階にあり、今後他のアプリに展開されます。
  • ネイティブ クライアント アプリケーションからプロキシ アプリケーションを操作できるようにする。 Azure AD アプリケーション プロキシは、Web アプリを発行するために使用できますが、Azure AD Authentication Library (ADAL) で構成されたネイティブ クライアント アプリケーションの発行にも使うことができます。 ネイティブ クライアント アプリケーションはデバイスにインストールされる点が Web アプリとは異なり、Web アプリはブラウザーからアクセスされます。

まとめ

働き方やツールは急速に変化します。 より多くの従業員が職場に自分のデバイスを持ち込むようになり、サービスとしてのソフトウェア (SaaS) アプリケーションが広く利用されるようになった今、組織がデータを管理および保護する方法にも進化が求められています。 安全な企業ネットワークの境界内から出ることなくビジネスを営むことは、もはや不可能です。 データはオンプレミスとクラウドの両環境にまたがり、かつてないほど多くの場所に移動するにようになっています。 このような進化は、ユーザーの生産性向上や共同作業の効率化に貢献してきましたが、それと同時に、機密性の高いデータの保護をより困難なものにしています。

現在ハイブリッド共存シナリオで Azure AD を使用してユーザーを管理している場合でも、クラウドへの移行を始めようとしている場合でも、Azure AD アプリケーション プロキシを実装することで、サービスとしてのリモート アクセスが提供され、オンプレミスのフットプリント サイズの削減につながります。

今すぐアプリケーション プロキシの利用を開始して、次のような利点を活用してください。

  • 従来の VPN やその他のオンプレミス Web 発行ソリューションと DMZ アプローチを維持することによって生じるオーバーヘッドを伴わずに、オンプレミス アプリケーションを外部に発行する
  • すべてのアプリケーション (Microsoft 365、オンプレミス アプリケーション、その他の SaaS アプリ) へのシングル サインオン
  • 未承認のアクセスを防ぐために Azure AD で Microsoft 365 のテレメトリを活用する、クラウド スケールのセキュリティ
  • 企業のトラフィックを確実に認証する Intune 統合
  • ユーザー アカウント管理の一元化
  • 最新のセキュリティ パッチを確実に適用する自動更新
  • リリースされる新機能 (直近では SAML シングル サインオンのサポートとアプリケーション Cookie の詳細な管理)

次のステップ