目次
AzureAD Application Proxyを使って、社内リソースへVPNを使わずにアクセスする方法
急遽リモートワーク環境を整えないと行けなくなった物の、社内からしか接続できないWEBアプリ、基盤システムにアクセスさせる方法が無い・・・
とか、全社員を収容できるVPNをすぐに用意できないといったケースって非常に多いのではないでしょうか。
仮に新規VPN構築の予算を付けたとしても、軒並み国内ベンダーの在庫は無し、今から発注すると6月以降納品になってしまうような異常事態。
しかしながら、事業継続性の観点から何とかして外部から社内リソースへのアクセス手段を早く用意しなければ・・・
そんな窮地に立たされている企業の方へぜひとも「AzureAD Application Proxy Server」を検討頂きたいのです。
AzureAD Application Proxyって?
AzureAD Application Serverとは、AzureADを介してオンプレミスアプリ(社内リソース)へアクセスできるようにする物で、以下のような特徴を備えています。
- ユーザはブラウザでアクセスするだけ
- オンプレミスアプリの改修が不要
- AzureADによる認証認可、セキュリティ分析が利用可能
- VPNやリバースプロキシなどのインフラ整備が不要
AzureAD Application Proxyでは以下のようなオンプレミスアプリに対応しています。
- 認証に統合Windows認証を使用するWebアプリ
- フォームベースまたはヘッダーベースのアクセスを使用するWebアプリ
- リモートデスクトップゲートウェイの裏でホストされているアプリ
- Active Directory Authentication Library(ADAL)と統合されるリッチクライアントアプリ
AzureAD Application Serverのしくみ
AzureAD Application Serverのしくみについて簡単に見てみましょう。
AzureAD Application Serverを利用して、インターネット越しに社内リソースへアクセスする際の処理手順をまとめたものが上図です。
- あらかじめ生成したURLエンドポイントにユーザがアクセスすると、AzureADのサインイン画面にリダイレクトされます。
- サインインに成功すると、AzureADがクライアントデバイスへアクセストークンを送信します。
- 受け取ったアクセストークンをAzure上にあるApplication Proxy Serviceへ送信します。受け取ったトークンからUPNとSPNを取得し、オンプレミス環境に構築しているApplication Proxy Connectorに送信します。
- シングルサインオンを構成している場合、コネクタがオンプレミスADに対して認証を実行します。
- コネクタがオンプレミスアプリに対してリクエストを送信します。
- オンプレミスアプリのレスポンスを、Application Proxy ConnectorとApplication Proxy Serviceを介してユーザに送信します。
簡単にまとめると、ユーザからのアクセスをオンプレミス環境に構築しているコネクタサーバが肩代わりしてアクセスしてくれます。
コネクタサーバがユーザのアクセスを代替するので、コネクタサーバが対象のオンプレミスアプリにアクセスできない場合、AzureAD Application Proxyからオンプレミスアプリへのアクセスに失敗します。
特に、コネクタサーバのIPアドレスまたはサブネットが、対象のオンプレミスアプリの許可IP一覧に追加することを忘れるケースが多いので注意が必要です。
AzureAD Appication Proxy環境を構築してみる
説明はこれくらいにしておいて、早速AzureAD Application Proxy環境を構築してみましょう。
もし、まだAzureAD環境を構築していない場合は、弊ブログが執筆した同人誌、「ゼロからはじめる Azure Active Directory ハイブリッド環境の構築」をご参照ください。
Pixiv BOOTHにて1000円でお求めになれます。
今回のテスト環境では、ローカルに構築したZabbixへ、AzureAD Applicationを介してインターネット越しからアクセスできるよう設定を行います。
Application Proxy Connectorの準備
図にもあったとおりオンプレミス環境または、オンプレミス環境とリーチャビリティのあるAzure IaaS等の上にコネクタサーバを構築する必要があります。
今の時点であれば、ドメインに参加したWindows Server 2016またはWindows Server 2019をあらかじめ構築しておきます。
Azureポータルへログインし、AzureADのブレード->「アプリケーションプロキシ」をクリックします。
続いて、「コネクタサービスのダウンロード」をクリックします。
サービス利用規約を確認し、問題ないことを確認したら「規約に同意してダウンロード」をクリックします。
※今回はWindowsServer 2016にインストールを行っています。
コネクタサーバにダウンロードしてきたインストーラを保存してから実行します。
インストールの途中でコネクタサーバをAzureADテナントへ紐付けるために、Microsoft Azureへのサインイン画面が表示されます。
このサインインは、AzureADテナントのグローバル管理者権限が付与されたアカウントで行います。
問題なくAzureADテナントとの紐付けが完了すれば、インストールが続行されます。
AzureADでアプリケーションプロキシの有効化を行う
コネクタサーバのインストールが完了したら、再度Azureポータルに戻り、「AzureAD」->「アプリケーションプロキシ」をクリックします。
すると、コネクタの「Default」グループに先ほどコネクタサーバをインストールしたサーバがリストアップされています。
リストアップされていることを確認したら、「アプリケーションプロキシの有効化」をクリックします。
すると、確認画面が表示されるので「はい」をクリックします。
「アプリケーションプロキシの有効化」と表示されていたボタンが「アプリケーションプロキシの無効化」に変わっていれば完了です。
エンタープライズアプリケーションの準備
アプリケーションプロキシの準備は完了したので、次はアプリケーションプロキシを経由して利用するオンプレミスアプリの準備を行います。
といっても、オンプレミスアプリ側で何か設定が必要、というわけではなくこちらもAzureポータルで設定を行います。
「AzureAD」->「エンタープライズアプリケーション」をクリックします。
続いて「新しいアプリケーション」をクリックします。
続いて「オンプレミスのアプリケーション」をクリックします。
するとオンプレミスアプリの設定画面が表示されるので、下記の通り設定を行います。
項目 | 設定値 |
---|---|
名前 | 任意のアプリケーション名を入力します。 |
内部URL | オンプレミスアプリのURLを入力します。 |
事前認証 | こちらはデフォルトのAzure Active Directoryを指定します。 |
コネクタグループ | こちらはデフォルトのDefaultを指定します。 |
それ以外については基本的に全てデフォルトのままで問題ありません。
設定値の入力が完了したら「追加」をクリックします。
また、内部URLは必ず「/」で終わらせる必要があります。
ですので、例えば「?」などでパラメータ渡しを行うアプリには対応できないため注意が必要です。
コネクタグループについては、先ほどのアプリケーションプロキシの準備で、コネクタグループを別途作成している場合は変更が必要です。
認可設定
エンタープライズアプリケーションの作成は完了したので、続いては認可設定を行います。
「AzureAD」->「エンタープライズアプリケーション」->「先ほど作成したアプリ(例ではZabbix Test)」->「ユーザーとグループ」をクリックします。
「ユーザーの追加」をクリックします。
※ユーザーもしくはグループの追加はAzureADの基本動作ですので、本記事では説明を省きます。
Zabbix Testの利用を認可するユーザを追加します。
動作の確認を行う
動作の確認を行うため、「AzureAD」->「エンタープライズアプリケーション」->「先ほど作成したアプリ(例ではZabbix Test)」->「アプリケーションプロキシ」をクリックします。
外部URL欄の右にコピーボタンがありますので、そちらをクリックします。
コピーしたURLをブラウザのアドレスバーに貼り付けてアクセスすると、上図の通りMicrosoftのサインイン画面が表示されます。
こちらに先ほど認可設定したAzureADのユーザー名を入力してログインを行います。
すると、本来であれば外部からアクセスする事ができないオンプレミスアプリにアクセスすることができました。
設定コストも非常に低く、ユーザ側もそこまで意識しなくても利用できるのが高ポイントですね。
アクセスする際はアプリケーションパネルから
設定は完了したわけですが、ユーザにURLをいちいち伝えるのもナンセンス。
それを解決するために、AzureAD標準機能のアプリケーションパネルを活用しましょう。
https://account.activedirectory.windowsazure.com/r#/applicationsへアクセスすると、Microsoftアカウントのログイン画面が表示されるので、AzureADアカウントでログインします。
するとアクセス権限のアプリが一覧で表示されるので、こちらから追加したオンプレミスアプリへログインが可能となります。
Chromeを使っているなら、拡張機能がおすすめ
Chromeを利用しているのであれば、Microsoftが用意している拡張機能「My Apps Secure Sign-in Extension」を利用するのがオススメ。
拡張機能を利用すれば、このようにアプリケーションパネルに簡単にアクセスできるようになります。
アプリケーションプロキシを有効化した状態で、社内から本来のURLにアクセスすると、問答無用でアプリケーションプロキシのエンドポイントURLにリダイレクトされてしまいます。
社内ではAzureAD認証を通さずに利用したい、ということであればこの拡張機能が必須となります。
拡張機能をインストールした後、歯車アイコンをクリックし、「Company internal URL redirection」を「Off」に設定してください。
認可されていないユーザがURLを叩くとどうなる?
それでは認可されていないユーザが、アプリケーションプロキシのエンドポイントURLにアクセスし、ログインした場合どうなるのか気になりますよね。
その点についてはご安心ください。
Microsoftアカウントのログイン画面は出てきますが、認可されていないユーザアカウントでサインインしても、上図の通りアクセスを遮断してくれます。
よりセキュアにアクセスさせたいのであれば、条件付きアクセスにもちろん対応していますので、ポリシーを定めればOKです。
まとめ
社内リソース(オンプレミスアプリ)への外部からのアクセス手段として、VPNではなくAzureAD Application Proxyを利用する方法を解説してみました。
実際に設定してみると、設定コストは非常に少ないですし、ユーザ側の操作コストもオンプレミスアプリの時とほぼ変わらず(AzureADアカウントでのサインインは必要)外部から社内リソースへアクセスすることができました。
VPNを用意するよりリードタイムは劇的に短いですし、インフラの管理コストも圧縮できるので大変良い選択肢かと思われます。
活用例を1つ上げるとすると、例えばオウンドブログを運用されている会社で、社内にCMSのステージング環境がある、といった場合でもわざわざVPNを用意しなくても、AzureAD Application Proxyでサクッとセキュアにアクセスできますね。
ある程度知見はありますので、お困りの際はお問い合わせ頂ければ幸いです(必ずしも解決するとはかぎりませんが・・・)
Source: Microsoft
おまけ
さすがにデフォルトのアイコンだと、そのアプリが何なのかすぐに判断できないので、エンタープライズアプリケーションの「プロパティ」からアイコンを別途指定することができます。