Microsoft Entra アプリケーション プロキシは、オンプレミスのWebアプリをVPNや従来型リバースプロキシに頼らず、Microsoft Entra IDの認証・条件付きアクセス・多要素認証の管理下で外部公開するための仕組みです。
今回の公式情報で管理者が最初に確認すべき点は、既存のオンプレミスアプリを「外部から安全に使えるようにする」だけでなく、コネクタの冗長化、事前認証、SSO方式、DNS・証明書、ユーザー割り当て、監視ログまでを含めて再点検することです。特に、受信ポートを開けずにコネクタからの送信接続で構成する点、Microsoft Entra 条件付きアクセスを前段に置ける点、内部ネットワーク上のユーザー向け用途ではない点は、設計段階で誤解しやすいポイントです。(Microsoft Learn)
Microsoft Entra アプリケーション プロキシとは
Microsoft Entra アプリケーション プロキシは、社内ネットワークにあるオンプレミスWebアプリケーションを、Microsoft Entra IDと連携して外部ユーザーに公開するサービスです。ユーザーは外部URLやマイアプリポータルからアクセスし、Microsoft Entra IDで認証された後、オンプレミス側のアプリに接続します。対象例としては、SharePoint、リモートデスクトップ、Outlook on the web、Tableau、Qlik、社内の基幹業務アプリなどが挙げられています。(Microsoft Learn)
従来のVPNやリバースプロキシでは、境界ネットワーク、エッジサーバー、VPNクライアント、パッチ適用、ポート監視などの運用負荷が増えがちです。Microsoft Entra アプリケーション プロキシは、IDを中心にアクセスを制御するため、リモートアクセスの入口をMicrosoft Entra側に寄せられます。
ただし、「社内にあるすべての通信を置き換える万能プロキシ」ではありません。公式情報でも、企業ネットワーク上の内部ユーザー向けには設計されておらず、内部ユーザーが不要にアプリケーション プロキシを経由するとパフォーマンス問題が起こる可能性があると説明されています。(Microsoft Learn)
今回の公式情報で押さえるべき変更点と確認ポイント
今回の公式情報は、特定の緊急パッチや破壊的変更の告知というより、Microsoft Entra アプリケーション プロキシのアーキテクチャ、コネクタ、認証方式、セキュリティ上の利点を整理した内容です。そのため、既存環境の管理者にとっての実務上のポイントは「今すぐ全設定を変更する」ことではなく、「現在の展開がMicrosoftの想定する構成に沿っているか」を確認することです。
| 確認テーマ | 公式情報で重要な点 | 管理者が確認すべきこと |
|---|---|---|
| コネクタ | オンプレミス側にはプライベート ネットワーク コネクタを配置する | コネクタが複数台あるか、適切なコネクタ グループに分けているか |
| 通信経路 | コネクタは送信接続のみを使用し、受信ポートを開ける必要がない | ファイアウォール、送信プロキシ、DNS解決が要件を満たしているか |
| 事前認証 | Microsoft Entra IDによる事前認証を使うと条件付きアクセスやMFAを適用できる | パススルー認証を安易に使っていないか |
| SSO方式 | IWA、フォームベース、ヘッダーベース、SAML、パスワードベース、MSAL統合アプリなどを扱える | アプリごとに最適なSSO方式を選定しているか |
| セキュリティ | 条件付きアクセス、Defender for Cloud Apps、ID Protectionなどと組み合わせられる | 高リスクサインイン、端末準拠、場所ベースの制御を設計しているか |
| 運用監視 | Microsoft Entra管理センター、監査ログ、Windowsイベントログで状態を確認できる | 障害時に見るログと担当者を決めているか |
特に既存のAzure AD Application Proxy時代から運用している組織では、名称変更だけでなく、Microsoft Entra Private Accessと同じコネクタを使う点や、Microsoft Entra全体のゼロトラスト設計に組み込む考え方を改めて整理しておくとよいでしょう。(Microsoft Learn)
影響範囲はオンプレミスアプリ、ID管理、ネットワーク設計にまたがる
Microsoft Entra アプリケーション プロキシの影響範囲は、単なるアプリ公開設定に留まりません。ID管理、ネットワーク、アプリケーション、セキュリティ運用の複数チームが関わります。
| 担当領域 | 主な影響 | 確認すべき具体例 |
|---|---|---|
| ID管理者 | Microsoft Entra IDでの認証、ユーザー割り当て、条件付きアクセス | 対象ユーザー、グループ、MFA、端末準拠条件 |
| ネットワーク管理者 | コネクタからMicrosoft Entra側への送信通信 | 80/443番ポート、送信プロキシ、DNS、TLS検査 |
| アプリ管理者 | 内部URL、外部URL、SSO方式、証明書 | アプリの認証方式、URLパス、Cookie、カスタムドメイン |
| 開発者 | アプリ内リンク、認証ヘッダー、API連携、リダイレクト | 絶対URLのハードコード、WebSocket、CORS、MSAL対応 |
| セキュリティ担当 | 事前認証、ログ監視、リスクベース制御 | サインインログ、監査ログ、Defender for Cloud Apps連携 |
| ヘルプデスク | ユーザーのアクセス障害対応 | My Apps、割り当て不足、MFA未登録、証明書エラー |
導入時に失敗しやすいのは、アプリ担当者だけで設定を進めてしまい、ネットワーク側の送信プロキシやDNS解決、ID側の条件付きアクセス、証明書更新運用が後回しになるケースです。PoCの段階から各担当を巻き込むことで、展開後の手戻りを減らせます。
アーキテクチャの基本は「クラウドサービス」と「オンプレミスコネクタ」
Microsoft Entra アプリケーション プロキシは、大きく分けてクラウド側のアプリケーション プロキシ サービスと、オンプレミス側のプライベート ネットワーク コネクタで構成されます。Microsoft Entra IDはIDプロバイダーとして認証を担当します。(Microsoft Learn)
基本的な通信フローは次の通りです。
| 手順 | 処理内容 |
|---|---|
| 1 | ユーザーが外部URLまたはポータルからアプリにアクセスする |
| 2 | Microsoft Entra IDのサインインページにリダイレクトされる |
| 3 | 認証成功後、ユーザーのクライアントにトークンが発行される |
| 4 | クライアントがトークンをアプリケーション プロキシ サービスに送る |
| 5 | アプリケーション プロキシ サービスが要求をコネクタに転送する |
| 6 | コネクタが必要なSSO処理を行い、オンプレミスアプリへ接続する |
| 7 | アプリの応答がコネクタ、クラウドサービスを経由してユーザーへ返る |
重要なのは、外部ユーザーからオンプレミスのWebサーバーへ直接HTTP通信が届くわけではない点です。ユーザートラフィックはクラウド側のアプリケーション プロキシ サービスで終端され、オンプレミス側ではコネクタが通信を処理します。コネクタは送信接続のみを使うため、インターネット向けに受信ポートを開ける必要はありません。(Microsoft Learn)
この構造により、DMZ上のリバースプロキシサーバーを増やすよりも、IDベースのアクセス制御に寄せた設計がしやすくなります。一方で、オンプレミスアプリそのものの脆弱性対策、認可設計、ログ管理が不要になるわけではありません。
コネクタ設計で確認すべき設定
Microsoft Entra アプリケーション プロキシの安定性は、コネクタ設計に大きく左右されます。公式のデプロイ計画では、可能であればバックエンドWebアプリケーションサーバーと同じネットワーク、同じセグメントにコネクタを配置すること、可用性とスケールのために各コネクタ グループに少なくとも2つのコネクタを用意することが示されています。3つのコネクタを持つ構成も、任意の時点でサービスを提供するうえで望ましい選択肢として説明されています。(Microsoft Learn)
| 確認項目 | 推奨される対応 | 放置した場合のリスク |
|---|---|---|
| コネクタ台数 | 本番環境ではコネクタ グループごとに複数台を配置 | 1台障害でアプリにアクセスできなくなる |
| 配置場所 | アプリサーバーに近いネットワークへ配置 | レイテンシ増加、認証遅延、タイムアウト |
| TLS 1.2 | コネクタマシンでTLS 1.2を有効化 | コネクタ登録や通信に失敗する可能性 |
| TLS検査 | コネクタとAzure間の送信TLS通信へのインライン検査を避ける | セキュアチャネル確立を阻害する可能性 |
| 送信通信 | TCP 443と80の送信通信を確認 | コネクタがクラウドサービスへ接続できない |
| 送信プロキシ | プロキシ経由かバイパスかを設計 | 認証プロキシやDNS解決で障害が起きる |
| DNS | CNAMEチェーンを解決できるようにする | 外部URLやMicrosoft側エンドポイントを解決できない |
| コネクタ グループ | アプリ、拠点、用途ごとに分ける | 本来別管理すべきアプリが同一経路になる |
特にDNSと送信プロキシは見落とされやすい項目です。Microsoft Entra アプリケーション プロキシのエンドポイントでは、CNAMEレコードがAレコードを指すチェーン構造になる場合があり、チェーン内のDNSレコードは変わる可能性があります。固定IPリストに依存した許可設定ではなく、名前解決と必要な送信通信を正しく処理できる構成にしておく必要があります。(Microsoft Learn)
認証方式はアプリごとに選ぶ
Microsoft Entra アプリケーション プロキシでは、アプリが使っている認証方式に応じてSSOの設計を変える必要があります。公式情報では、統合Windows認証、フォームベース、ヘッダーベース、Web API、Remote Desktop Gateway配下のアプリ、MSAL統合のリッチクライアントアプリなどが対象として整理されています。(Microsoft Learn)
| アプリの認証方式・種類 | 選択肢 | 設計時の注意点 |
|---|---|---|
| 統合Windows認証（IWA） | Kerberos制約付き委任（KCD） | コネクタサーバーとアプリサーバーのドメイン参加、SPN、委任設定を確認 |
| フォームベース認証 | パスワードベースSSOなど | パスワード管理、初回サインイン、認証失敗時の運用を確認 |
| ヘッダーベース認証 | PingAccessなどのパートナー連携 | ヘッダーの信頼境界、アプリ側の受け取り仕様を確認 |
| SAML / WS-Federation | SAMLベースSSO | 識別子、応答URL、証明書、クレーム設計を確認 |
| Web API | Microsoft Entra IDによる認可と連携 | クライアントアプリ、トークン、API保護方式を整理 |
| Remote Desktop Gateway配下のアプリ | RDS公開 | RDS固有のCookie設定やMFA適用範囲を確認 |
| MSAL統合のリッチクライアント | ネイティブクライアント連携 | クライアントID、テナントID、トークン処理を確認 |
実務では、最初に「そのアプリが現在どの認証方式で動いているか」を棚卸ししてください。IWAのアプリをSAMLのように扱おうとしたり、フォーム認証のアプリにKCDを前提にした設計を当てたりすると、設定画面上は進められてもSSOが成立しません。
管理者が最初に確認すべき設定チェックリスト
Microsoft Entra アプリケーション プロキシを既に使っている組織も、これから展開する組織も、次の項目を順番に確認すると抜け漏れを防げます。
ライセンスと権限
オンプレミスアプリを追加するには、Microsoft Entra ID P1またはP2サブスクリプション、アプリケーション管理者アカウント、オンプレミスディレクトリと同期されたユーザーIDまたはMicrosoft Entraテナント上のIDが必要です。(Microsoft Learn)
本番運用では、常時強い権限を持つアカウントを使い続けるのではなく、Privileged Identity ManagementによるJust-In-Timeアクセスなど、最小特権を前提にした管理を検討してください。公式のデプロイ計画でも、必要なタスクに応じた適切なMicrosoft Entraロールの選定が示されています。(Microsoft Learn)
アプリケーション プロキシ設定
オンプレミスアプリを追加する際は、Microsoft Entra管理センターからエンタープライズアプリケーションに移動し、オンプレミスアプリケーションを追加します。設定時には、名前、内部URL、外部URL、事前認証、コネクタ グループ、追加設定を確認します。(Microsoft Learn)
| 設定項目 | 確認ポイント |
|---|---|
| 名前 | My Appsや管理センターで利用者・管理者が識別しやすい名称にする |
| 内部URL | 社内ネットワーク内から到達できるURLを指定する |
| 外部URL | 利用者が外部からアクセスするURLを決める |
| 事前認証 | 原則としてMicrosoft Entra IDを選び、条件付きアクセスやMFAを使える状態にする |
| コネクタ グループ | アプリの拠点、ネットワーク、用途に合ったグループを選ぶ |
| バックエンドタイムアウト | 認証や接続が遅いアプリに限ってLongを検討する |
| HTTP-Only Cookie | 通常は有効化を検討し、RDSでは要件に応じて確認する |
| 永続的なCookie | 必要なアプリに限って使用する |
| URL変換 | アプリ内リンクの構造やカスタムドメイン利用有無を確認する |
| バックエンドTLS証明書検証 | HTTPSの内部接続を適切に検証したい場合に有効化する |
内部URLでパスを指定する場合は注意が必要です。たとえばアプリが https://yourapp/app にあり、画像やCSSが https://yourapp/media にある場合、/app だけを公開すると画面が崩れる可能性があります。公式チュートリアルでも、必要な画像、スクリプト、スタイルシートが公開パスに含まれることを確認するよう説明されています。(Microsoft Learn)
URLと証明書
アプリ作成時のURLは、httpまたはhttpsで始まり、ドメイン名を使う必要があります。IPアドレスをURLとして扱う設計は避けましょう。また、カスタムドメインを使う場合は、対応するTLS証明書を準備する必要があります。証明書の有効期限切れ、自己署名証明書、秘密キー不足は、アップロード時の典型的なエラー要因です。(Microsoft Learn)
証明書更新は、アプリ公開後に忘れられやすい運用項目です。証明書管理をアプリ担当に任せきりにせず、更新期限、所有者、通知先、更新手順を台帳化しておくことをおすすめします。
ユーザーとグループ割り当て
アプリを公開しただけでは、安全な運用とは言えません。誰がそのアプリにアクセスできるかを、ユーザーまたはグループで明確に管理する必要があります。
実務では、個人単位での直接割り当てよりも、業務ロールに対応したMicrosoft Entraグループを使う方が管理しやすくなります。たとえば「経理請求システム外部アクセス可」「営業CRMリモート利用可」のように、アプリと権限の意味が分かるグループ名にすると、監査時にも説明しやすくなります。
注意したいのは、ユーザー割り当てを不要にした場合の影響です。アプリケーションのプロパティでユーザー割り当てが不要な状態のままだと、想定より広いユーザーが公開アプリに到達できる可能性があります。匿名アクセスが前提のアプリなど、明確な理由がある場合に限って慎重に使うべき設定です。(Microsoft Learn)
条件付きアクセスで「公開してから守る」ではなく「接続前に絞る」
Microsoft Entra アプリケーション プロキシの大きな利点は、オンプレミスアプリへの接続が確立される前に、Microsoft Entra 条件付きアクセスで制御できる点です。場所、認証の強度、ユーザーリスク、デバイス状態などを条件にして、アクセス許可やブロック、多要素認証要求を設計できます。(Microsoft Learn)
おすすめの初期ポリシー例は次の通りです。
| シナリオ | 条件付きアクセスの例 |
|---|---|
| 全リモートユーザー | MFAを必須にする |
| 機密性の高い業務アプリ | 準拠済みデバイスまたはハイブリッド参加デバイスのみ許可 |
| 海外からのアクセス | 信頼済み国・地域以外はブロックまたは追加認証 |
| 高リスクサインイン | アクセスブロックまたはパスワード変更を要求 |
| 管理者 | フィッシング耐性の高い認証方法を要求 |
| ゲストユーザー | 対象アプリ、期間、承認者を限定する |
条件付きアクセスは強力ですが、いきなり全社適用すると業務停止を招くことがあります。最初はパイロットグループでレポート専用モードや限定適用を使い、サインインログを確認してから段階的に広げるのが現実的です。
開発者とアプリオーナーが確認すべきポイント
Microsoft Entra アプリケーション プロキシの導入では、インフラ側の設定だけでなく、アプリケーション側の実装や設計も影響します。
アプリ内リンクが外部公開後も正しく動くか
古い社内アプリでは、HTML内に内部FQDNやIPアドレスがハードコードされていることがあります。外部URLからアクセスしたユーザーの画面に http://intranet-server.local/image/logo.png のようなリンクが返ると、画像やスクリプトが読み込めず、ログイン後に画面が崩れます。
この場合は、アプリ側で相対パスに修正する、公開パスを見直す、URL変換を検討する、カスタムドメインを使うなどの対応が必要です。まずはブラウザーの開発者ツールで、外部アクセス時に404、混在コンテンツ、内部URL参照が出ていないか確認してください。
認証ヘッダーやクライアントIPの扱いを確認する
アプリケーション プロキシ サービスは、要求ヘッダーを転送し、プロトコルに従ってクライアントIPアドレスに関するヘッダーを設定することがあります。既存アプリがクライアントIPや独自ヘッダーに強く依存している場合は、外部公開後の値をログで確認してください。(Microsoft Learn)
特に、IPアドレスだけでアクセス制御している古いアプリは、Microsoft Entra IDによるユーザー認証・条件付きアクセス・アプリ側の認可に移行する余地があります。アプリケーション プロキシ導入を機に、IPベースの信頼からIDベースの制御へ移すことを検討しましょう。
WebSocketやリッチクライアントを使うアプリは事前検証する
WebSocketを使うアプリやMSAL統合のリッチクライアントアプリは、通常のブラウザー完結型Webアプリより検証項目が増えます。オンプレミスアプリ追加チュートリアルでは、WebSocketを使うアプリの場合、グループ内のすべてのコネクタがバージョン1.5.612.0以降である必要があると説明されています。(Microsoft Learn)
このようなアプリは、ログイン可否だけでなく、画面更新、リアルタイム通知、ファイルアップロード、API呼び出し、長時間セッションの挙動まで確認してください。
移行・展開は小さく始めて段階的に広げる
Microsoft Entra アプリケーション プロキシを展開する際は、いきなり重要な基幹システムを公開するのではなく、低リスクなアプリから段階的に進めるのが安全です。
| フェーズ | 実施内容 | 成功条件 |
|---|---|---|
| 1. 棚卸し | 対象アプリ、URL、認証方式、利用者、証明書、依存リソースを整理 | 公開候補と除外対象が分かれている |
| 2. 分類 | すぐ公開できるアプリ、SSO調整が必要なアプリ、刷新すべきアプリに分ける | 優先順位が明確になっている |
| 3. PoC | 低リスクアプリでコネクタ、事前認証、ユーザー割り当てを検証 | パイロットユーザーが外部から利用できる |
| 4. セキュリティ設計 | 条件付きアクセス、MFA、ログ監視、ゲスト制御を設計 | 過剰許可やロックアウトがない |
| 5. 本番展開 | グループ単位で利用者を広げる | サインインログと問い合わせが安定している |
| 6. 既存経路の整理 | VPNや旧リバースプロキシの例外設定を見直す | 不要な公開経路が減っている |
棚卸しでは、サービス種別、アプリ基盤、FQDN、内部URL、外部URL、証明書、認証方式、コネクタ グループ、利用ユーザー・グループ、追加のセキュリティ要件を記録しておくと、後続作業がスムーズになります。公式のデプロイ計画でも、アプリケーション インベントリの作成が推奨されています。(Microsoft Learn)
セキュリティ上のメリットと過信してはいけない点
Microsoft Entra アプリケーション プロキシのセキュリティ上のメリットは明確です。事前認証により有効なトークンを持たないトラフィックをブロックでき、条件付きアクセスを使ってネットワーク接続前に制御できます。また、バックエンドアプリへのトラフィックはクラウド側のアプリケーション プロキシ サービスで終端され、オンプレミス側のコネクタは送信専用接続を使います。(Microsoft Learn)
一方で、次のような過信は避けるべきです。
| 誤解 | 正しい考え方 |
|---|---|
| アプリケーション プロキシを使えばアプリ側の脆弱性対策は不要 | アプリ本体、OS、ミドルウェア、認可処理の対策は引き続き必要 |
| 事前認証を有効にすれば誰に公開しても安全 | ユーザー割り当て、条件付きアクセス、最小権限が必要 |
| VPNをすべて即時廃止できる | 対象は主にWebアプリや対応シナリオ。非Web通信は別途検討が必要 |
| 内部ユーザーにも同じ経路を使わせれば統一できる | 内部ユーザー用途ではパフォーマンス問題が起きる可能性がある |
| コネクタは1台で十分 | 本番では複数台構成を前提に可用性を確保する |
| パススルーでもバックエンド認証があるから十分 | Entra側の条件付きアクセスやMFAを活かすには事前認証を重視する |
特にパススルー認証は慎重に扱う必要があります。ユーザーはMicrosoft Entra IDで認証されずにアプリへ到達できるため、条件付きアクセスやMFAを前段で効かせたい場合には適していません。公開アプリの性質上どうしても必要な場合を除き、Microsoft Entra IDによる事前認証を基本に設計してください。
トラブルを減らすための運用監視
展開後は、コネクタの状態、アプリのサインイン状況、認証エラー、ユーザー割り当て、証明書期限を定期的に確認します。Microsoft Entra IDでは監査ログやレポートを利用でき、アプリケーション プロキシではMicrosoft Entra管理センターとWindowsイベントログからコネクタを監視できます。(Microsoft Learn)
障害時に見るべき場所は、あらかじめ運用手順に入れておきましょう。
| 症状 | 主な確認先 |
|---|---|
| アプリに到達できない | コネクタの稼働状態、送信通信、DNS、内部URL |
| ログインできない | Microsoft Entraサインインログ、条件付きアクセス結果、MFA状態 |
| SSOだけ失敗する | KCD設定、SPN、委任、アプリ側認証方式 |
| 画面が崩れる | アプリ内リンク、公開パス、URL変換、ブラウザー開発者ツール |
| 一部ユーザーだけ使えない | ユーザー・グループ割り当て、ライセンス、条件付きアクセス |
| 証明書エラーが出る | カスタムドメイン証明書、有効期限、秘密キー、証明書チェーン |
| レスポンスが遅い | コネクタ配置、バックエンド応答、リージョン、内部ネットワーク遅延 |
Microsoft Entra管理センターの「テスト アプリケーション」機能や診断レポートも、初期展開時の確認に役立ちます。問題が発生したときは、利用者の画面だけで判断せず、サインインログ、監査ログ、コネクタイベントログを組み合わせて原因を切り分けることが重要です。(Microsoft Learn)
よくある失敗例と回避策
コネクタを1台だけで本番運用する
PoCでは1台でも動きますが、本番では障害点になります。最低でもコネクタ グループごとに複数台を用意し、メンテナンスやOS更新時にもサービスを継続できる構成にしましょう。
内部URLのパスを狭くしすぎる
/app だけを公開した結果、画像やJavaScriptが別パスから読み込めず、画面が崩れることがあります。アプリの静的ファイル、API、リダイレクト先を確認してから内部URLを決めてください。
事前認証をパススルーにしたまま公開する
バックエンド側のログイン画面があるから安全、という判断は危険です。Microsoft Entra側の条件付きアクセスやMFAを活かしたい場合は、Microsoft Entra IDによる事前認証を基本にします。
カスタムドメイン証明書の更新担当が不明
証明書期限切れは、ある日突然アクセス障害として表面化します。証明書の所有者、更新期限、更新手順、緊急連絡先を運用台帳に入れておきましょう。
条件付きアクセスを一括適用して業務停止する
セキュリティ強化を急ぎすぎて、全ユーザーに強い制御を一括適用すると、MFA未登録ユーザーや非準拠端末の利用者が業務アプリに入れなくなることがあります。最初は限定グループで検証し、サインインログを見ながら展開してください。
旧VPN経路を残したままにする
アプリケーション プロキシで安全に公開しても、旧VPNや古いリバースプロキシ経路が残っていると、攻撃面が減りません。移行後は既存経路の例外設定、公開ポート、ファイアウォールルールを見直しましょう。
管理者が次に取るべき行動
Microsoft Entra アプリケーション プロキシは、オンプレミスアプリをMicrosoft Entra IDの認証基盤に組み込み、リモートアクセスを安全に整理するための有力な選択肢です。最初に行うべきことは、新しい設定を急いで追加することではなく、現在外部公開しているアプリ、VPN経由で使っているアプリ、将来廃止できる公開経路を棚卸しすることです。
次の順番で進めると、現実的に移行できます。
- 外部アクセスが必要なオンプレミスアプリを一覧化する
- 各アプリの認証方式、内部URL、利用者、証明書、依存リソースを記録する
- コネクタを複数台で構成し、ネットワークとDNSを確認する
- 低リスクなアプリでMicrosoft Entra ID事前認証を有効化する
- 条件付きアクセスとMFAをパイロット適用する
- サインインログ、監査ログ、コネクタイベントログで安定性を確認する
- 成功したパターンを標準手順化し、他のアプリへ段階展開する
オンプレミスアプリの公開は、単なるネットワーク設定ではなく、ID、認証、アプリ設計、運用監視をまとめて見直す作業です。Microsoft Entra アプリケーション プロキシを導入する際は、「公開できたか」だけで終わらせず、「誰が、どの条件で、どのアプリに、どの経路でアクセスしているか」を継続的に管理できる状態を目標にしてください。
コメント