Azure AD Applicaiton Proxyを利用してオンプレミスアプリケーションへアクセスする

AzureAD Application ProxyはMicrosoft Azure ActiveDirectory P1(有料)に付随するセキュアなリバースプロキシサービスです。
Application Proxyを利用することにより、AzureADユーザー(Office365ユーザー)に対して社内のWebアプリケーションを社外からアクセス可能な仕組みを提供することが可能になります。

Azure AD Application Proxyを用いたオンプレミスアプリケーションの公開手法を記載します。

Application Proxy構成図

Application Proxyを用いることで、Azure上のエンドポイントにアクセスすると対応するオンプレミスの業務アプリケーションに対してアクセスすることが可能です。

下図において、 site1-iotaker.msapproxy.net へアクセスし、Azure ADの認証をクリアするとオンプレミスのみで利用可能な業務アプリケーション site1.intra.iotaker.jp へアクセスできます。

Application Proxyが他のリバースプロキシと異なるのは、認証をAzure ADに任せ条件付きアクセスを用いた柔軟かつセキュアなアクセス制御を提供できる点にあります。
Application Proxyへのアクセスに対して多要素認証やIntuneによるポリシー準拠などを条件にすることでユーザーにVPN不要かつセキュアなアクセスを提供します。

Application Proxyの設定

Application Proxy コネクタのインストール

Applicaiton Proxyを利用するためにはオンプレミスネットワークにWindows Serverを設置し、Application Proxyコネクタをインストールすることが必要です。

コネクタをインストールするWindows Serverの要件は以下の通りです。

Windows Server 2012 R2以降のOS
Azureに対する80/443ポートのOutBoundトラフィック
オンプレミスアプリに対するアクセス

注目する点として、インターネットからApplication Proxyサーバに対するInboundのトラフィックの許可は不要です。そのため、DMZにサーバを設置する必要はありません。

Application ProxyコネクタはAzure ADポータルへアクセスし、「アプリケーションプロキシ」から「コネクタサービスのダウンロード」を選択してダウンロードし、サーバへインストールします。

ダウンロードしたインストーラを実行し、Azure ADの管理者アカウントでログインをすることでApplication ProxyサーバとAzure ADテナントが紐づけされ、オンプレミスアプリへのアクセス準備が整います。

プロキシアプリの構成

Application Proxy コネクタサーバの構築が終わったら、外部からアクセスするためのプロキシアプリを作成します。
Azure ADポータルへアクセスし、「アプリケーションプロキシ」から「アプリの構成」を選択します。

プロキシアプリには複数の設定項目があるのですが、今回はシンプルな静的ページでのテストをするため他の設定はいじらず「名前」、「内部URL」、「外部URL」のみを編集します。

「名前」はあとで管理するためにわかりやすい名称をつければ問題ありません。
「内部URL」には、Application Proxyサーバからアクセス可能な内部のURLを指定します。
「外部URL」にはインターネットからアクセスする際のURLを指定します。カスタムドメインを用いない場合はURLの頭の文字列だけを指定し、[ <CustomStirng>-<TenantName>.msappproxy.net ] というURLになります。

構成を保存すると「エンタープライズアプリケーション」の一覧に作成したコネクタアプリが表示されるようになるため、アクセス可能なユーザーを適切に設定します。

これでApplication Proxyの最低限の設定が終わったため、先ほど設定した外部URLへアクセスし、Azure ADの認証を行うとオンプレミス業務アプリがVPNを接続しなくてもインターネットから利用することが可能になりました。

コンテンツ内部URLの変換問題

Application Proxyサーバを用いて業務アプリ1 へのアクセスは提供できましたが、あくまで業務アプリ1のみに対してのアクセス提供であり、業務アプリ2へのアクセスは提供されていません。
業務アプリ2にも同様に site2-iotaker.msappproxy.net を構成したとしても、業務アプリ1のページ内に記載されているリンクは site2.intra.iotaker.jp となっているため、ページ内リンクが期待した動作をしない状態になってしまいます。

業務アプリ1内の業務アプリ2へのリンクは site2.intra.iotaker.jp で記載されており、Application Proxy経由のアクセスでは業務アプリ1経由で業務アプリ2へアクセスできない

インターネットからのアクセスなので、オンプレミスネットワークの名前が解決できない

Apache HTTP Serverを用いたコンテンツ内URLの変換

上記の問題を解決するため、Application Proxyサーバと業務アプリの間にURL変換のためのリバースプロキシを設置してURLを変換を実施します。

必要パッケージのインストール

今回の例としてはUbuntu22.04及びApache HTTP Server 2.4.52を用います。
※URLの変換という目的においてはApacheでもnginxでもIISでも問題ないですが、個人的に手馴れていてWSL2で簡単に構成できたためUbuntu+Apacheでの例としています

必要パッケージは以下コマンドでインストールし、サービスを起動しておきます。

apt install apache2
systemctl enable apache2
systemctl start apache2

ApacheのConfig

Apacheのsites-availableディレクトリで以下のconfファイルを作成します。

site1-rp.intra.iotaker.jp という名前でリクエストをsite1.intra.iotaker.jpへリダイレクトしながらHTMLコンテンツ内の “site1.intra.iotaker.jp” を “site1-iotaker.msappproxy.net” へ、 “site2.intra.iotaker.jp” を “site2-iotaker.msapproxy.net” へ変換するWebサーバを設置するConfigです。

##/etc/apache2/sites-available/site1-rp.conf

<VirtualHost *:80>
        ServerName site1-rp.intra.iotaker.jp
        ProxyRequests Off
        RequestHeader unset Accept-Encoding

        ErrorLog ${APACHE_LOG_DIR}/site1-rp.error.log
        CustomLog ${APACHE_LOG_DIR}/site1-rp.access.log combined

        <Location />
                ProxyPass http://site1.intra.iotaker.jp/
                ProxyPassReverse http://site1.intra.iotaker.jp/

                FilterDeclare SITE1 CONTENT_SET
                FilterProvider SITE1 SUBSTITUTE "%{Content_Type} = 'text/html'"
                FilterChain SITE1

                Substitute "s|site1.intra.iotaker.jp|site1-iotaker.msappproxy.net|n"
                Substitute "s|site2.intra.iotaker.jp|site2-iotaker.msappproxy.net|n"
        </Location>

</VirtualHost>

configを保存したら以下コマンドで必要なモジュールとサイトを有効化し、コンフィグの記載に異常がないことを確認したら、最後にApache HTTP Serverを再起動します。
※必要モジュールはUbuntuの標準リポジトリからApache2をインストールした場合は追加インストールは不要だと思いますが、足りなければ別途apt installしてください

a2enmod headers proxy proxy_http filter substitute
a2ensite site1-rp
apahcectl configtest
# Syntax OK なら大丈夫
apachectl restart

プロキシアプリの再構成

最後に、Azure AD上のプロキシアプリの構成を変更します。

Azure ADポータルへアクセスし、「エンタープライズアプリケーション」の中からプロキシアプリを選択、「アプリケーションプロキシ」の項目からプロキシ構成の変更が可能です。

「内部URL」の欄を先ほど作成したApache HTTP Serverで構成した site1-rp.intra.iotaker.jp へ変更して保存します。

構成がすべて正常に機能している場合、この状態で site1-iotaker.msappproxy.net へアクセスすると業務アプリ1のページが表示され、アプリ内の業務アプリ2へのリンクはイントラのURLではなく、別途構築した業務アプリ2のApplication ProxyのエンドポイントURLが表示されています。

業務アプリ2についても正しくApplicaiton Proxyが構成されている場合、該当リンクから業務アプリ2へアクセスしてページを表示することが可能です。

これでApplicationProxyを経由した場合でもイントラネット内部からアクセスしたときと似たようなアクセス導線を提供することができ、ユーザーの利便性を維持することが可能になります。

Apacheの追加Config

今回の検証ではシンプルな静的ページの表示のみだったためConfigの記載事項はシンプルな内容となっています。

実際のアプリで動かしてみると上記Configだけでは動かず追加の設定を入れる必要がある場合も多いかと思います。必要な設定は実際のアプリケーションの挙動に依存するため都度Configをいじりながら挙動を確認しましょう。

後段のリバースプロキシを設置することの問題

こういった回りくどい構成を取らずとも、オンプレミスのドメインをカスタムドメインとしてAzure ADに登録し、プロキシアプリの外部URLをオンプレミスのURLと一致させることができる場合、URL変換用のリバースプロキシサーバを設置する必要はありません。

システムの構成要素が増える以上障害ポイントが増え、今回のシンプルな構成だと冗長化も考えていないため稼働率が下がります。可用性を上げるためにはより複雑な構成をとる必要が出てきます。

ただ、企業によってはイントラドメインを外部には公開しておらず、今後も外部からイントラドメインを検索させたくないという需要からカスタムドメインを用いたApplication Proxyの構成ができない場合があります。
そういった際には迂遠な手法ではありますがURL変換用のリバースプロキシを設置する構成を検討してもよいのではないでしょうか。

まとめ&補足

Application Proxyを設置することで外部からオンプレミスのアプリケーションへのアクセス経路を提供でき、VPNへの接続に依存する業務を一つ減らすことができます。

ただし、Application Proxyはあくまでオンプレミスネットワークへの入り口を提供する手法であるため、直アクセスと比較した場合どうしてもレスポンスや利便性が低下します。

可能であればApplication Proxyは業務アプリケーションの再構成の間のつなぎのアクセス手段として提供し、業務アプリケーションを特定のネットワークに依存しない場所に設置したうえでクラウドの強力な認証基盤を用いる構成として展開するよう変えていけると従業員の働き方がより柔軟に対応できるようになるでしょう。

Pocket