Microsoft Entra アプリケーション プロキシを使用したアプリへのリモート アクセス時のセキュリティに関する注意事項
この記事では、Microsoft Entra アプリケーション プロキシを使用する際にユーザーとアプリケーションを安全に保つために動作するコンポーネントについて説明します。
次の図は、Microsoft Entra ID によってオンプレミスのアプリケーションへの安全なリモート アクセスが実現されるしくみを示しています。
セキュリティ上の利点
Microsoft Entra アプリケーション プロキシには、多くのセキュリティ上の利点があります。 利点の一覧は次のとおりです。
- 認証済みのアクセス
- 条件付きアクセス
- トラフィックの終了
- すべての送信アクセス
- クラウド規模の分析と機械学習
- サービスとしてのリモート アクセス
- Microsoft による分散型サービス拒否 (DDoS) からの保護サービス
認証済みのアクセス
Microsoft Entra の事前認証を使用すると、認証された接続のみがネットワークにアクセスできます。
Microsoft Entra アプリケーション プロキシは、すべての認証に Microsoft Entra セキュリティ トークン サービス (STS) に依存します。 認証された ID のみがバックエンド アプリケーションにアクセスできるため、事前認証はその性質上多くの匿名の攻撃をブロックします。
事前認証方法としてパススルーを選択した場合、この利点は得られません。
条件付きアクセス
ネットワークへの接続が確立される前に、多数のポリシー制御を適用できます。
条件付きアクセスを使用すると、ユーザーがアプリケーションにアクセスするときの制限を定義できます。 場所、認証の強度、およびユーザーのリスク プロファイルに基づいてサインインを制限するポリシーを作成できます。
条件付きアクセスを使用して多要素認証ポリシーを構成することで、ユーザー認証にセキュリティ層を追加することもできます。 さらに、Microsoft Entra 条件付きアクセスを利用して、アクセスポリシーとセッションポリシーを通じて Microsoft Defender for Cloud Apps にアプリケーションをルーティングすることで、リアルタイムの監視と制御を提供することもできます。
トラフィックの終了
すべてのトラフィックがクラウドで終了します。
Microsoft Entra アプリケーション プロキシはリバース プロキシであるため、バックエンド アプリケーションへのトラフィックはすべて、このサービスで終了します。 バックエンド サーバーでのみセッションを再確立できます。つまり、HTTP トラフィックを送信するためにバックエンド サーバーが公開されることはありません。 この構成により、標的型攻撃に対する保護を強化できます。
すべてのアクセスが外向き
企業ネットワークへの受信接続を開く必要がありません。
プライベート ネットワーク コネクタは、Microsoft Entra アプリケーション プロキシ サービスへの送信接続のみを使用します。 受信接続用のファイアウォール ポートを開く必要はありません。 従来のプロキシでは、境界ネットワーク (DMZ、"非武装地帯"、"スクリーン サブネット" とも呼ばれます) が必要で、ネットワーク境界で認証されていない接続へのアクセスを許可する必要がありました。 アプリケーション プロキシでは、すべての接続が送信用で、セキュリティで保護されたチャネルで発生するため、境界ネットワークは不要です。
コネクタのメンテナンスについて詳しくは、「Microsoft Entra プライベート ネットワーク コネクタについて」を参照してください。
クラウド規模の分析と機械学習
最先端のセキュリティ保護を得ることができます。
アプリケーション プロキシは Microsoft Entra ID の一部であるため、Microsoft Entra ID Protection に加え、Microsoft Security Response Center と Digital Crimes Unit のデータを活用できます。 これらの組織は ID が攻撃されたアカウントを被害の発生前に特定し、危険性の高いサインインが実行されないように保護します。どのサインインの試みが高リスクであるかを判断するために、さまざまな要素が考慮されます。 要素としては、感染したデバイスのフラグ、ネットワークの匿名化、特殊な場所や可能性の低い場所などが含まれます。
これらのレポートとイベントの多くは、お客様のセキュリティ情報およびイベント管理 (SIEM) システムとの統合を可能にする API を通じて既に使用可能です。
サービスとしてのリモート アクセス
オンプレミス サーバーの保守やパッチの適用について心配する必要がありません。
パッチの適用されていないソフトウェアは、依然として多数の攻撃の的となっています。 Microsoft Entra アプリケーション プロキシは Microsoft によるインターネット規模のサービスであるため、常に最新のセキュリティ パッチとアップグレードを取得できます。
Microsoft Entra アプリケーション プロキシによって発行されたアプリケーションのセキュリティを強化するために、Web クローラー ロボットによるアプリケーションのインデックス作成およびアーカイブ操作はブロックされます。 Web クローラー ロボットが公開されたアプリのロボット設定を取得しようとするたびに、アプリケーション プロキシは User-agent: * Disallow: / が含まれる robots.txt ファイルで応答します。
Microsoft による分散型サービス拒否 (DDoS) からの保護サービス
アプリケーション プロキシ経由で公開されたアプリケーションは、分散型サービス拒否 (DDoS) 攻撃から保護されます。 Microsoft はすべてのデータセンターでこの保護を自動的に有効化します。 Microsoft による DDoS からの保護サービスによって、トラフィックを常時監視し、一般的なネットワーク レベル攻撃をリアルタイムで軽減できます。
しくみ
Microsoft Entra アプリケーション プロキシは、以下の 2 つで構成されています:
- クラウドベースのサービス: このサービスは Microsoft Cloud 内で稼働し、外部のクライアントまたはユーザーとの接続が行われる場所で機能します。
- オンプレミスのコネクタ: オンプレミスのコンポーネント。コネクタは、Microsoft Entra アプリケーション プロキシ サービスからの要求をリッスンし、内部アプリケーションへの接続を処理します。
コネクタとアプリケーション プロキシ サービスの間でフローが確立されるのは以下の場合です。
- コネクタの最初の設定時。
- コネクタはアプリケーション プロキシ サービスから構成情報を取得します。
- 公開されたアプリケーションにユーザーがアクセスする。
注意
すべての通信は TLS 経由で発生し、常にコネクタで生成され、アプリケーション プロキシ サービスに送られます。 このサービスは送信専用です。
コネクタはクライアント証明書を使用して、ほぼすべての呼び出しに対してアプリケーション プロキシ サービスを認証します。 このプロセスの唯一の例外は、クライアント証明書が確立される最初のセットアップ手順です。
コネクタのインストール
コネクタの初回セットアップ時に、次のフロー イベントが発生します。
- サービスへのコネクタの登録は、コネクタのインストールの一環として発生します。 ユーザーは、Microsoft Entra 管理者の資格情報の入力を求められます。 この認証から取得されたトークンが、Microsoft Entra アプリケーション プロキシ サービスに提示されます。
- アプリケーション プロキシ サービスがトークンを評価します。 ユーザーがテナントの全体管理者であるかどうかを確認します。 ユーザーが管理者でない場合、このプロセスは終了します。
- コネクタはクライアント証明書要求を生成し、トークンと共にアプリケーション プロキシ サービスに渡します。 次に、サービスがトークンを検証し、クライアント証明書要求に署名します。
- コネクタは、アプリケーション プロキシ サービスとのその後の通信の際にこのクライアント証明書を使用します。
- コネクタはクライアント証明書を使用して、サービスからのシステム構成データの初回の収集を実行します。これで要求を受け入れる準備ができました。
構成の設定の更新
アプリケーション プロキシ サービスが構成の設定を更新するたびに、次のフロー イベントが発生します。
- コネクタはクライアント証明書を使用して、アプリケーション プロキシ サービス内の構成のエンドポイントに接続します。
- クライアント証明書が検証されます。
- アプリケーション プロキシ サービスはコネクタに構成データ (そのコネクタが含まれている必要があるコネクタ グループなど) を返します。
- 現在の証明書が生成されてから 180 日以上経っている場合は、コネクタが新しい証明書要求を生成します。
発行済みアプリケーションへのアクセス
発行されたアプリケーションにユーザーがアクセスすると、アプリケーション プロキシ サービスとプライベート ネットワーク コネクタとの間で次のイベントが発生します。
- サービスは、アプリケーションのユーザーを認証します。
- サービスがコネクタのキューに要求を配置する
- コネクタがキューの要求を処理する
- コネクタが応答のために待機する
- サービスがユーザーにデータをストリーミングする
これらの各手順の詳細について、この後説明します。
1.サービスは、アプリケーションのユーザーを認証します。
アプリケーションが事前認証方法としてパススルーを使用する場合は、このセクションの手順はスキップされます。
Microsoft Entra ID を使用して事前認証するようにアプリを構成した場合、ユーザーは認証のために Microsoft Entra STS にリダイレクトされます。 次の手順が発生します。
- アプリケーション プロキシが、条件付きアクセス ポリシーの要件を確認します。 この手順により、ユーザーがアプリケーションに割り当てられていることを確認します。 2 段階検証が必要な場合は、認証シーケンスでユーザーに第 2 認証方式が要求されます。
- Microsoft Entra STS はアプリケーションに署名済みトークンを発行し、ユーザーをアプリケーション プロキシ サービスにリダイレクトします。
- アプリケーション プロキシは、トークンが正しいアプリケーションに発行され、署名済みで、有効であることを確認します。
- アプリケーション プロキシは暗号化された認証 Cookie を設定して、アプリケーションへの認証が成功したことを示します。 Cookie には、Microsoft Entra ID のトークンに基づく有効期限のタイムスタンプが含まれます。 また、この Cookie には認証の対象となるユーザー名も含まれます。 この Cookie は、アプリケーション プロキシ サービスのみで認識される秘密キーを使用して暗号化されます。
- アプリケーション プロキシは、ユーザーを最初に要求された URL にリダイレクトします。
事前認証の手順の一部が失敗した場合は、ユーザーの要求が拒否され、ユーザーに問題の原因を示すメッセージが表示されます。
2.サービスがコネクタのキューに要求を配置する
コネクタは、アプリケーション プロキシ サービスへの送信接続を開いたままにします。 要求を受信すると、サービスは開いている接続のいずれかでキューに要求を配置し、コネクタが処理できるようにします。
この要求には、要求ヘッダー、暗号化された Cookie のデータ、要求を作成したユーザー、要求 ID が含まれます。 要求と共に暗号化された Cookie のデータが送信されますが、認証 Cookie 自体は送信されません。
3.コネクタがキューの要求を処理する
アプリケーション プロキシは、要求に基づいて次のアクションのいずれかを実行します。
要求が単純な操作 (本文にデータがない RESTful API
GET要求など) の場合、コネクタがターゲットの内部リソースに接続した後、応答のために待機します。関連付けられたデータが本文に含まれている要求 (RESTful API
POST操作など) の場合、コネクタはアプリケーション プロキシ インスタンスへのクライアント証明書を使用して、送信接続を行います。 この接続は、データを要求し、内部リソースへの接続を開くために確立されます。 アプリケーション プロキシ サービスはコネクタからの要求を受信すると、ユーザーからのコンテンツの受け入れを開始し、データをコネクタに転送します。 そしてコネクタが内部リソースにデータを転送します。
4.コネクタが応答のために待機する
バックエンドへのすべてのコンテンツの要求および送信が完了すると、コネクタは応答を待機します。
コネクタは応答を受け取ると、アプリケーション プロキシ サービスへの送信接続を行うことで、ヘッダーの詳細情報を返し、返されるデータのストリーミングを開始します。
5.サービスがユーザーにデータをストリーミングする
この時点で、アプリケーションの何らかの処理が発生します。 たとえば、アプリケーション プロキシはヘッダーまたは URL を変換します。