見出し画像

オンプレミスで稼働している Web アプリケーションを、受信ポートの開放なしにインターネットから安全に使用する!


はじめに

こんにちは、SHIFTの秋吉です。

Azure のサービスに Azure Active Directory アプリケーション プロキシというのがあります。
このアプリケーション プロキシを使用すると、ネットワークの侵入方向の通信ポートを全く開けることなしに、つまり外部からのアクセスができない状態であるにも関わらず、プライベートネットワーク内(イントラネット内)で稼働している Web アプリケーションへ、パブリック インターネットから安全にアクセスさせることができます。

セキュリティの利点から理解する、アプリケーション プロキシとは何ぞや?

アプリケーション プロキシとは、ヒトコトで言うと、外部インターネットからイントラネット(企業内)のアプリケーションを「安全に」使うことが出来る「仕組み」と言えると思います。
次のようなセキュリティ上の利点があります。

  • すべてのアクセスが外向き
    一番の特徴でありメリットは、アプリケーション プロキシ は、イントラネットから ポート 80 と 443 を経由するアウトバウンド接続のみを使用します。インバウンド接続がないので、DMZ で着信接続またはコンポーネント用にファイアウォール ポートを開く必要はありません。すべての接続は外向きであり、しかも、セキュリティで保護されたチャネル経由で行われます。(もともとのアプリは(https ではない)httpで動作していても、通信が http で露出することはない、という意味です。)

  • 認証済みのアクセス
    アプリケーション プロキシは、認証された接続のみがオンプレミスのアプリケーションにアクセスできるようにできます(※パススルーすることもできます)。事前認証を利用するアプリケーションでは、有効なトークンがないと、トラフィックがアプリケーション プロキシ サービスを通過してオンプレミス環境に到達することはできません。 事前認証はその性質上、認証された ID のみにバックエンド アプリケーションへのアクセスを許可するため、多数の標的型攻撃がブロックされます。
    特筆すべきは、これらの事前認証の利用や、特定のユーザー、グループにアプリケーションを割り当てるために、既存のアプリケーションを変更する必要はない ことです。

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

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

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

  • サービスとしてのリモート アクセス
    リモート アクセスを実現するために、追加のサーバーリソースを追加する必要はありません。これは、サーバーの保守やパッチの適用についても必要がないことを意味します。アプリケーション プロキシは Microsoft によるインターネット規模のサービスであるため、常に最新のセキュリティ パッチとアップグレードを取得できます。

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

前提環境

オンプレミスのアプリケーションを Azure AD に追加するには、次が必要です。

  • Microsoft Azure AD の Premium サブスクリプション

  • アプリケーション管理者アカウント

また、

  • 認証のために、各ユーザーのアカウントが AAD で管理されている
    これは、AAD 上のユーザーアカウントが必要ですが、オンプレミス ディレクトリから同期しているか、Azure AD テナント内だけの新規作成かどうかは問わないという意味になります。
    ID をオンプレミスと同期した場合は、シングル サインオン (SSO) が可能となります。

検証用の環境

Azure上に、仮想ネットワークと、仮想マシンを作成します。
仮想マシンは、Windows Serverで、IISを有効化します。 この Server に後続のステップで、アプリケーション プロキシ コネクタをセットアップします。

アプリケーション プロキシのセットアップ

アプリケーションプロキシは、次の手順でセットアップします。

  1. アウトバウンド トラフィック用のポートを開き、特定の URL へのアクセスを許可する

  2. Windows サーバーにコネクタをインストールし、アプリケーション プロキシに登録します

  3. コネクタが正しくインストールおよび登録されていることを確認します

  4. Azure AD テナントにオンプレミスのアプリケーションを追加します

  5. テスト ユーザーが Azure AD アカウントを使用してアプリケーションにサインオンできることを確認します

この手順は、実はマイクロソフト社提供の チュートリアル そのものであり、この手順の詳細については、本家チュートリアルを参照していただくとして、この記事では、私なりに補足が必要と感じたところを適宜フォローアップしていくこととします。

1. アウトバウンド トラフィック用のポートを開き、特定の URL へのアクセスを許可する

アウトバウンドの通信を制限している場合には、いくつか(結構たくさん!)通信を行えるようにする必要があります。

2. Windows サーバーにコネクタをインストールし、アプリケーション プロキシに登録します

アプリケーションの登録に先駆けて、アプリケーション プロキシ コネクタを AAD に登録する必要があります。「登録」といっても、明示的な登録作業はなく、公開したいオンプレミスのアプリケーションにアクセスできる Windows サーバーに コネクタ(と呼ばれるソフトウェア)をインストールすると、そのインストールの過程で、AAD にコネクタが登録されます。
このコネクタが、オンプレミスからアプリケーション プロキシ サービスへの外向き通信経路をあらかじめ確保しておき、利用者がアプリケーション プロキシ サービスで定義しているエンドポイントにアクセスに来ると、この通信経路を逆向きに利用してアプロケーションへのリクエストをコネクタが受信し、アプリケーションからのレスポンスを返す動作をするものです。
ポイントは2つあります。

  • このインストール作業中に AAD への登録処理も走るため、「どの」AAD (テナント) に登録するのか、という情報をこのインストール中で与える必要があります。(実際には、アプリケーション管理者の資格情報を提供することで、その管理者アカウントの属する AAD テナントにコネクタを登録することになります。)

  • その登録作業を行うアカウントに、AAD 上でのアプリケーション管理者権限が必要です。

なお、コネクタは、Azure ポータルで、Azure Active Directory から、管理 -> アプリケーション プロキシ と進み、このページ内からダウンロードすることができます。

3. コネクタが正しくインストールおよび登録されていることを確認します

コネクタのインストールと AAD の登録がうまくいくと、コネクタ グループ に、セットアップしたコネクタが表示されます。コネクタ グループには複数のコネクタが登録でき、高可用性と負荷分散が実現されます。
留意点としては、コネクタを登録(セットアップ)すると、必ず Default という名前のグループに登録されてしまうため、これを必ず別のグループに移動させておきます。その後、次のステップのAAD へのアプリケーション追加を行います。
Default グループのまま次のステップのアプリケーション登録を行った場合、後日、別のアプリケーション用のコネクタをセットアップした時点で、そのコネクタが、稼働中の Default グループに混入してしまい、アプリケーショントラフィックが誤ってルーティングされてしまうことになるからです。

4. Azure AD テナントにオンプレミスのアプリケーションを追加します

いよいよ、オンプレミスアプリケーション自体を登録して、パブリック インターネットから使えるようにします。
アプリケーション登録する前に、必ず前述のように、コネクタ グループを Default 以外 に移動しておくことを忘れないでください。

内部 URL に、実際のプライベート ネットワーク内のアプリケーション URL を指定します。 このパスには、アプリケーションに必要な画像、スクリプト、スタイル シートのすべてが含まれている必要があります。逆に、この URL は、ユーザーに表示されるランディング ページである必要はありません。たとえば、アプリが https://yourapp/app にあり、 https://yourapp/media にあるイメージを使用している場合、 https://yourapp/ をパスとして発行する必要があります。

外部 URL に、実際にユーザーがネットワークの外部からアプリにアクセスするためのアドレスを指定します。ここで、https://hhhh.sdsadasd.azureapp.net/ 設定して、ユーザーが、https://hhhh.sdsadasd.azureapp.net/app/default.aspx にアクセスした場合、実際には、https://yourapp/app/default.aspx からレスポンスを受け取ることになります。

応用例

Windows Server の リモートデスクトップサービス (RDS) は、RDP over HTTPS により、RDPだけでなく、HTTPS通信でもアクセスさせることができます。(ブラウザでリモートデスクトップが使えるというだけでなく、HTTPS通信のみで、リモートデスクトップ アプリケーション クライアントも使えます。)
オンプレミスの RDS と、今回の アプリケーション プロキシを組み合わせることにより、オンプレミスで利用しているリモートデスクトップサービスを外部パブリック インターネットから利用することが可能になります。

まとめ

セキュリティとパフォーマンス

アプリケーション プロキシを利用することによって、インバウンドの 通信ポートを全く開けることなく、アウトバウンドの http/https 通信のみで、パブリック インターネットから企業ネットワーク内のアプリケーションを使用することができます。この時、Azure AD を利用して、アプリケーションにアクセスするユーザーを制御する(外部の人間を門前払いする)こともできます。しかもこのとき、アプリケーションのほうに手を加えることなく、です。

このように、アプリケーション プロキシは、セキュリティ的に優れた機能を提供しますが、その構造上、パフォーマンスは決してよくありません。
企業内ネットワークからのアクセスもパブリック インターネットからのアクセスと統合することも考えられますが、性能上の理由から、企業内ネットワークからアプリケーション プロキシを利用することはおすすめいたしません。

参考

《この公式ブロガーの他の記事》



執筆者プロフィール:秋吉 利彰
"IT" と呼ばれる前から、この業界に身を置き早やうん十年。
PC 上で動作するニッチなプログラミングから クラウド (Azure) でのアーキテクチャまで、これまでの経験で得られた、Tipsや "てみた" 的な記事を書いていこうと思います。

お問合せはお気軽に
https://service.shiftinc.jp/contact/

SHIFTについて(コーポレートサイト)
https://www.shiftinc.jp/

SHIFTのサービスについて(サービスサイト)
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/