保護されたアプリケーションのリファレンスアーキテクチャ

アプリケーションをAccess Gatewayと統合する場合、バックエンドリソースが保護されているだけでなく、通常の外部インターネットからアクセスできないようにする方法がいくつかあります。以下のアーキテクチャでは、保護対象Webリソースにインターネットからアクセスできないようにするために使用できる、さまざまな方法について説明します。

アプローチ

アプリケーションをAccess Gatewayに統合する場合は、以下の点を考慮する必要があります。

  • DNS - Access GatewayへのDNSの提供方法は？
  • ファイアウォールの実装方法。
  • 具体的なIPアドレスの制限はあるか？
  • その他の統合固有の要件はあるか？

保護済みのアプリケーションのアーキテクチャ

Access Gatewayアプリケーション統合インストールは、さまざまな組み合わせでデプロイできます。全てのアーキテクチャで、アプリケーションへのアクセスに使用されるURLは同じです。つまり、内部ネットワークと外部ネットワークの両方のアクセスが同じアプリケーション名（app.example.com）に依存ているということです。

一般的なアプリケーション統合保護アーキテクチャには、以下のものがあります。

保護対象外 保護対象Webアプリケーションアーキテクチャの最初の開始点。定義上、保護対象Webリソースへの外部アクセスに対する保護はほとんど、またはまったく提供されません。
マスクされたDNS アーキテクチャなしの状態の拡張で、Access Gatewayで使用される、保護対象Webリソースの名前を解決するが、外部アプリケーションのURLとは異なる、セカンダリ内部DNSサーバーを追加します。
ファイアウォール 分割DNSアーキテクチャを拡張したもので、ファイアウォールを戦略的な場所に配置し、内部使用インターネット上のIPアドレスに対するリクエストのルーティングを拒否します。
保護対象IP ファイアウォールアーキテクチャの拡張である保護対象（または制限された）IPでは、リクエスターのIPアドレスに基づきリソースへのアクセスを許可または拒否するIPアドレスベースの制限が追加されます。
証明書チャレンジ ファイアウォールまたは保護対象IPアドレスアーキテクチャの拡張である証明書チャレンジアーキテクチャは、リクエスターが証明書チャレンジに正常に応答できるかどうかに基づき、保護対象Webリソースへのアクセスを許可または拒否するために使用されるカスタム証明書をインストールします。

アーキテクチャの機能領域の内訳

アーキテクチャは、次の機能領域に分類されます。

外部インターネット 外部インターネットは、Okta Orgを含むアプリケーションにアクセスするクライアントを表します。
DMZ DMZは、外部インターネットからアプリケーションにアクセスできるように、Access Gatewayクラスターと関連コンポーネントが格納されています。
内部 内部ネットワークには、Access Gatewayによって保護されているアプリケーションと、これらのアプリケーションを広く利用できるようにするために必要なその他のコンポーネントが配置されています。

全てのアーキテクチャ図において、点線は拒否されることを意味するAccess Gateway周辺のパスを表していることに注意してください。各アーキテクチャは、これらのパスを拒否するために使用されるプロセスの詳細を説明します。