Azure AD アプリケーション プロキシによるリモート アクセスの保護

Azure AD アプリケーション プロキシによるリモート アクセスの保護

2025 年 3 月 14 日

この技術的および教育的な記事は、セキュリティ アナリスト、IT 管理者、およびシステム エンジニアがオンプレミス Web アプリケーションへのリモート アクセスをセキュリティで保護するために Azure AD アプリケーション プロキシを実装および構成する方法をガイドすることを目的としています。ユーザーがどこからでも内部リソースにアクセスする必要があるハイブリッド作業環境では、このアクセスのセキュリティが不可欠です。 Azure AD アプリケーション プロキシは、複雑な VPN や DMZ を必要とせずに、オンプレミスの Web アプリケーションをリモート ユーザーに公開するための安全で簡素化されたソリューションを提供します [1]。

はじめに

従来、内部アプリケーションへのリモート アクセスには、仮想プライベート ネットワーク (VPN) を設定するか、アプリケーションを境界ネットワーク (DMZ) に公開する必要があり、複雑さが増し、攻撃ベクトルが増加する可能性がありました。リモートおよびハイブリッド ワーク モデルの採用が増えるにつれ、組織は依然としてオンプレミスに存在するレガシー アプリケーションへのアクセスを提供する、より安全かつ効率的な方法を必要としています [2]。

Azure AD アプリケーション プロキシは、ユーザーがどこからでもオンプレミス Web アプリケーションに安全にアクセスできるようにする Azure Active Directory (現在は Microsoft Entra ID) の機能です。これはリバース プロキシとして機能し、内部アプリケーション トラフィックを Azure AD 経由でルーティングし、認証と承認を処理します。これは、多要素認証 (MFA) や条件付きアクセスなどの Azure AD セキュリティ機能を活用して、オンプレミス アプリケーションに SaaS アプリケーションのようにアクセスできることを意味します [3]。

この実用的なガイドでは、前提条件、アプリケーション プロキシ コネクタのインストールと構成、さまざまな種類のアプリケーション (Web アプリ、リモート デスクトップ Web クライアント、SharePoint) の公開、条件付きアクセス ポリシーとの統合、リモート アクセスのテストと検証の方法について説明します。読者がこれらの機能を実装、テスト、検証できるように、段階的な手順、実践的な例、および簡潔な説明が提供されます。さらに、自律的、専門的かつ確実に安全かつ効率的なリモート アクセスを確保するための、セキュリティのヒント、コンプライアンス チェック、ベスト プラクティスについても説明します。

Azure AD アプリケーション プロキシがリモート アクセスに重要なのはなぜですか?

  • 強化されたセキュリティ: Azure AD で認証と承認を一元化し、オンプレミス アプリケーションで MFA、条件付きアクセス、Identity Protection などのセキュリティ機能を使用できるようにします。
  • 簡素化されたアクセス: オンプレミス アプリケーションにシングル サインオン (SSO) エクスペリエンスを提供し、ユーザーのアクセスを容易にします。
  • 複雑さの軽減: リモート アクセスのための VPN や DMZ の必要性を排除し、ネットワーク アーキテクチャを簡素化し、攻撃対象領域を削減します。
  • コスト効率が高い: リモート アクセス用の追加のハードウェアやソフトウェアを必要とせず、既存の Azure AD インフラストラクチャを使用します。
  • 柔軟な公開: ヘッダーベースのアプリケーション、SharePoint、リモート デスクトップ Web クライアント、その他のカスタム Web アプリケーションを含む、幅広い Web アプリケーションの公開をサポートします。

前提条件

Azure AD アプリケーション プロキシを構成するには、次のものが必要です。

  1. ライセンス: Azure AD Premium P1 または P2 サブスクリプション (または Microsoft 365 E3/E5 など、これらの機能を含むライセンス) [4]。
  2. 管理アクセス: Azure portal (https://portal.azure.com) の「グローバル管理者」または「アプリケーション管理者」のロールを持つアカウント。
  3. コネクタ用 Windows Server: 公開するアプリケーションおよび Azure AD に接続できる、オンプレミス ネットワーク内の Windows Server (2012 R2 以降) サーバー。このサーバーには、送信インターネット アクセス (Azure AD の場合はポート 80 と 443、Azure AD アプリケーション プロキシ サービスの場合は 443) が必要です [5]。
  4. オンプレミス Web アプリケーション: リモートからアクセスできるようにする内部 Web アプリケーション。
  5. カスタム ドメイン (オプション): 公開アプリケーションにわかりやすい URL を使用する場合、Azure AD で検証されたカスタム ドメイン。

ステップバイステップ: Azure AD アプリケーション プロキシの構成

アプリケーション プロキシを構成してアプリケーションを公開しましょう。

1. アプリケーション プロキシ コネクタのインストールと構成

コネクタは、接続する軽量のエージェントです。Azure AD とオンプレミス アプリケーションに。

  1. ブラウザーを開き、Azure portal: https://portal.azure.com に移動します。
  2. 必要な権限を持つアカウントでログインします。
  3. 上部の検索フィールドに「Azure Active Directory」と入力し、結果からそれを選択します。
  4. 左側のナビゲーション ウィンドウで、[管理] の下の [アプリケーション プロキシ] を選択します。

  5. 「コネクタ サービスのダウンロード」をクリックします。

  6. コネクタ用に指定したオンプレミス Windows サーバー上で、次の操作を行います。

    • コネクタ インストーラー (AADApplicationProxyConnectorInstaller.exe) をダウンロードして実行します。
    • インストール ウィザードの指示に従ってください。インストール中に、Azure AD グローバル管理者の資格情報を使用してログインするように求められます。
    • インストールが成功すると、コネクタ サービスが自動的に開始されます。

  7. Azure portal に戻り、アプリケーション プロキシ ページで、新しくインストールされたコネクタが「コネクタ」リストにステータス「アクティブ」で表示されていることを確認します。

    • 説明: 高可用性と負荷分散のために、少なくとも 2 つのコネクタをインストールすることをお勧めします。コネクタは自動的に更新されるため、常に最新バージョンを利用できます。

2. オンプレミス Web アプリケーションの公開

社内 Web アプリケーションを公開してみましょう。この例では、「http://minhaappinterna.local:8080」でアクセスできる「MinhaAppInterna」という内部 Web アプリケーションがあると想像してください。

  1. Azure Active Directory の左側のナビゲーション ペインで、「管理」の下の エンタープライズ アプリケーション を選択します。
  2. 「+ 新しいアプリケーション」をクリックします。
  3. 「ギャラリーにない他のアプリケーションを統合する (ギャラリー以外)」をクリックします。
  4. 基本:
    • 名前: 意味のある名前を付けます (例: MyInternal-ProxyApp)。
    • アプリケーション タイプ: 「オンプレミス アプリケーション」を選択します。

  5. 「追加」をクリックします。

  6. アプリケーションを作成すると、アプリケーション管理ページにリダイレクトされます。左側のナビゲーション ウィンドウで、「管理」の下にある アプリケーション プロキシ を選択します。

  7. 基本設定:

    • 内部 URL: アプリケーションの内部 URL を入力します (例: http://minhaappinterna.local:8080)。コネクタがこの URL を解決してアクセスできることを確認してください。
    • 外部 URL: この URL は、デフォルトの Azure AD ドメインに基づいて自動的に生成されます (例: myappinternal-proxy.msappproxy.net)。カスタム ドメインをお持ちの場合は、それをセットアップできます。
    • 事前認証方法: 「Azure Active Directory」を選択します (セキュリティを最大限に高めるために推奨)。
    • コネクタ グループ: デフォルトのコネクタ グループを選択するか、複数のコネクタがある場合はカスタム グループを選択します。

  8. [保存] をクリックします。

  9. 左側のナビゲーション ペインで、[管理] の下の [ユーザーとグループ] を選択します。

  10. 「+ユーザー/グループの追加」をクリックし、このアプリケーションへのアクセスを許可する Azure AD ユーザーまたはグループを割り当てます。

    • 説明: ユーザーとグループの割り当ては、公開アプリケーションにアクセスできるユーザーを制御するために重要です。 Azure AD アプリケーション プロキシにより、認証および承認されたユーザーのみが内部アプリケーションにアクセスできるようになります。

3. 公開アプリケーションの条件付きアクセスの構成

条件付きアクセスを使用すると、アプリケーション アクセスに対して MFA などの追加のセキュリティ ポリシーを適用できます。

  1. Azure Active Directory の左側のナビゲーション ペインで、セキュリティ > 条件付きアクセス を選択します。
  2. 「+ 新しいポリシー」をクリックします。
  3. 基本:
    • 名前: 意味のある名前を付けます (例: MFA_para_MinhaAppInternal)。
  4. 責任:
    • ユーザーまたはワークロードの識別: ポリシーの影響を受けるユーザーとグループを選択します (例: Grupo_Usuarios_MinhaAppInterna)。
    • クラウド アプリケーションまたはアクション: 「MyAppInternal-Proxy」を選択します。
  5. アクセス制御:
    • 許可: 「アクセスを許可する」と「多要素認証を要求する」を選択します。
  6. ポリシーを有効にする: 「有効」を選択します。

  7. [作成] をクリックします。

    • 説明: このポリシーにより、オンプレミス アプリケーションがネイティブで MFA をサポートしていない場合でも、「MyInternal-ProxyApp」にアクセスしようとするユーザーは多要素認証を実行するように求められます。

4. 他の種類のアプリケーションの公開

アプリケーション プロキシは、リモートなどの他の種類のリソースを公開するために使用できます。デスクトップ Web クライアントと SharePoint。

4.1.リモート デスクトップ Web クライアントの公開

  1. セクション 2 の手順に従って、新しいエンタープライズ アプリケーションを作成します。
  2. アプリケーション プロキシ構成で次のようにします。
    • 内部 URL: リモート デスクトップ Web クライアント サーバーの URL を入力します (例: 「https://rdweb.contoso.com/RDWeb」)。
    • 外部 URL: 自動的に生成されます。
    • 事前認証方法: Azure Active Directory。
    • URL 変換ヘッダー タイプ: バックエンド URL ヘッダー。
  3. ユーザー/グループを割り当てます。

4.2. SharePoint オンプレミスでの公開

  1. セクション 2 の手順に従って、新しいエンタープライズ アプリケーションを作成します。
  2. アプリケーション プロキシ構成で次のようにします。
    • 内部 URL: SharePoint サイトの URL を入力します (例: https://sharepoint.contoso.local)。
    • 外部 URL: 自動的に生成されます。
    • 事前認証方法: Azure Active Directory。
    • URL 変換ヘッダー タイプ: バックエンド URL ヘッダー。
  3. ユーザー/グループを割り当てます。

検証とテスト

リモート アクセスをテストして、アプリケーションに安全にアクセスできることを確認することが重要です。

1. 公開アプリケーションへのアクセスのテスト

  1. シナリオ: 企業ネットワークの外側のコンピューター (例: 自宅) からブラウザーを開き、MinhaAppInternal-Proxy の 外部 URL (例: https://minhaappinterna-proxy.msappproxy.net) に移動します。
  2. 予想されるアクション: Azure AD ログイン ページにリダイレクトされるはずです。 Azure AD 資格情報を入力し、構成されている場合は MFA を完了すると、オンプレミスの MyApp にリダイレクトされます。
  3. 検証:
    • アプリケーションが正しくロードされ、操作できることを確認します。
    • Azure AD ログイン ログを確認して、アプリケーション プロキシ経由でアクセスが認証され、MFA が適用されていることを確認します。

2. Azure AD ログイン ログの確認

  1. Azure portal で、Azure Active Directory > 監視 > 受信ログ に移動します。
  2. 「Application」 (「MyAppInternal-Proxy」) でログをフィルタリングします。
  3. 「条件付きアクセス ステータス」を含むログインの詳細を確認します (「成功」と表示され、MFA が適用されていることを示す必要があります)。

セキュリティのヒントとベスト プラクティス

  • 常に Azure AD 事前認証を使用する: Azure AD 事前認証は、認証され承認されたユーザーのみが内部ネットワークにアクセスできるようにするため、最も安全な方法です。事前認証を処理できないアプリケーションで厳密に必要な場合を除き、「パススルー」は避けてください。
  • 条件付きアクセス: 条件付きアクセスを使用して、アプリケーション プロキシ経由で公開されるすべてのアプリケーションに対して MFA、場所制限、デバイス コンプライアンスなどの追加のセキュリティ ポリシーを適用します。
  • コネクタ グループ: コネクタをグループに編成してアプリケーションを分離したり、コネクタを特定のアプリケーションに近づけてパフォーマンスを向上させたりできます。
  • 高可用性: 高可用性と復元性を確保するために、少なくとも 2 つのコネクタを別々のサーバーにインストールします。必要に応じて、別のリージョンまたはアベイラビリティ ゾーンにインストールすることを検討してください。
  • コネクタのメンテナンス: コネクタは自動的に更新されますが、Azure portal でステータスを監視して、コネクタが常にアクティブで正常であることを確認します。
  • コネクタ サーバー セキュリティ: コネクタがインストールされているサーバーを保護します。常に最新の状態に保ち、最小特権の原則を適用し、不審なアクティビティがないか監視してください。
  • パフォーマンスの最適化: トラフィックが多いアプリケーション、または低遅延を必要とするアプリケーションの場合は、アプリケーション サーバーおよび利用可能な帯域幅との関係でコネクタの位置を考慮してください。
  • 監視: Azure AD ログイン ログとコネクタ ログを監視して、不審なアクティビティやアクセスの問題を検出します。

一般的なトラブルシューティング

  • アクセス エラー (404、500 など):
    • 内部 URL を確認してください: アプリケーション プロキシで構成された内部 URL が正しいこと、およびコネクタがインストールされているサーバーから内部 URL に直接アクセスできることを確認してください。
    • コネクタを確認してください: Azure portal でコネクタが「アクティブ」であることを確認します。サーバー上のコネクタ サービスを再起動します。
    • コネクタ グループを確認してください: アプリケーションに割り当てられているコネクタ グループが少なくとも 1 つのアクティブなコネクタが必要です。
    • ローカル ファイアウォール: コネクタ サーバーまたはアプリケーション サーバー上のファイアウォールがトラフィックをブロックしていないかどうかを確認します。
  • アプリケーションが正しく読み込まれない (レンダリングの問題):
    • ヘッダー変換: 一部のアプリケーションでは、アプリケーション プロキシ設定の「URL 変換ヘッダー タイプ」を「バックエンド URL ヘッダー」または「フロントエンド URL ヘッダー」に調整する必要がある場合があります。
    • エンコードされたリンク: 内部 URL へのハードコードされたリンクを持つアプリケーションでは問題が発生する可能性があります。可能であれば、アプリケーション プロキシの「リンク変換」を使用するか、アプリケーションを再構成することを検討してください。
  • SSO の問題:
    • SSO 構成: エンタープライズ アプリケーションの SSO 設定を確認します。フェデレーションされていないアプリケーションの場合は、「パスワードベースの SSO」または「ヘッダー SSO」の構成が必要になる場合があります。
    • Kerberos 制約付き委任 (KCD): 統合 Windows 認証 (IWA) を使用するアプリケーションの場合、KCD がコネクタの Active Directory で正しく構成されていることを確認します。
  • 条件付きアクセスによる正規ユーザーのブロック:
    • 条件付きアクセス ポリシーを慎重に確認してください。ユーザーまたはグループが正しく含まれているか除外されていることを確認します。
    • 条件付きアクセスの「What If」ツールを使用してアクセスをシミュレートし、ポリシーが強制またはブロックされる理由を理解します。
  • オフライン コネクタ:
    • コネクタ サーバーの Azure AD (送信ポート 80 および 443) およびアプリケーション プロキシ サービス (送信ポート 443) へのネットワーク接続を確認します。
    • コネクタ サーバー上の Windows イベント ログでサービス関連のエラーを確認してください。
    • 「Microsoft AAD Application Proxy Connector」サービスが実行されていることを確認してください。

結論

Azure AD アプリケーション プロキシは、ゼロ トラスト モデルの原則に沿って、オンプレミス Web アプリケーションへのアクセスをリモート ユーザーに拡張するための強力で安全なツールです。 Azure AD で認証と承認を一元化し、複雑なリモート アクセス インフラストラクチャの必要性を排除することで、組織は脅威からの保護を強化しながらセキュリティ アーキテクチャを簡素化できます。セキュリティ上のメリットを最大化し、流動的なユーザー エクスペリエンスを確保するには、慎重な実装、条件付きアクセスとの統合、継続的な監視が不可欠です。この実践的なガイドにより、セキュリティ専門家と IT 管理者は、Azure AD アプリケーション プロキシの構成、検証、管理を行うための十分な準備を整え、重要なアプリケーションへのリモート アクセスを保護し、組織のセキュリティ体制を強化できます。

参考文献:

[1] Microsoft Learn。 Microsoft Entra Application Proxy を使用してローカル アプリを公開します。入手可能場所: https://learn.microsoft.com/pt-br/entra/identity/app-proxy/overview-what-is-app-proxy [2] Microsoft Learn。 Microsoft Entra Application Proxy を介したリモート アクセス用のローカル アプリケーションを追加します。入手可能場所: https://learn.microsoft.com/pt-br/entra/identity/app-proxy/application-proxy-add-on-premises-application [3] Microsoft Learn。 Microsoft Entra アプリケーション プロキシを使用してリモート デスクトップを公開。入手可能場所: https://learn.microsoft.com/pt-br/entra/identity/app-proxy/application-proxy-integrate-with-remote-desktop-services [4] Microsoft Learn。 Microsoft Entra ID ライセンス。入手可能場所: https://learn.microsoft.com/pt-br/entra/identity/licensing-azure-active-directory [5] Microsoft Learn。 Microsoft Entra アプリケーション プロキシ コネクタ。入手可能場所: https://learn.microsoft.com/pt-br/entra/identity/app-proxy/application-proxy-connectors [6] Microsoft Learn。 Microsoft Enter ID での条件付きアクセス。入手可能場所: https://learn.microsoft.com/pt-br/entra/identity/conditional-access/overview [7] Microsoft Learn。 Microsoft Entra アプリケーション プロキシ コネクタのトラブルシューティング。入手可能場所: https://learn.microsoft.com/pt-br/entra/identity/app-proxy/application-proxy-troubleshoot-connectors