Access Gatewayシングルサーバーアーキテクチャ
Access Gatewayシングルサーバーアーキテクチャは、Access Gatewayを使用してWebリソースを保護するために最低限必要なコンポーネントを表します。このシンプルなアーキテクチャでは、保護対象Webリソースと呼ばれるアプリケーションセットを、Access Gatewayを使用してリクエストをするクライアントに提供されます
これは一般的に情報提供目的で使用される最小アーキテクチャです。
- 外部インターネットから内部ネットワーク内に格納されているアプリケーションセットへのアクセスを安全に提供します。
利点と欠点
利点 | 欠点 |
---|---|
|
|
アーキテクチャ
コンポーネント
ロケーション | コンポーネント | 説明 |
---|---|---|
外部インターネット | Webクライアント |
従来のクライアントブラウザで、[appN|consumer-app1].example.comとして知られるURLを使ってAccess Gatewayにアクセスします。 |
appN.example.com | 外部WebクライアントがAccess Gatewayによって保護対象アプリケーションの1つにアクセスするために入力するアプリケーションの1つを表すURL。通常、この性質のすべてのURLは、Access Gatewayインスタンスによってサービスされ、解決されます。 | |
Okta org |
Okta orgは、アイデンティティサービスを提供しています。 |
|
ファイアウォール | 外部インターネットからDMZ | 外部インターネットとDMZホスティングAccess Gatewayの間の従来のファイアウォール。 |
DMZ | Access Gateway | DMZ内に配置されるAccess Gatewayインスタンスは、外部インターネットクライアントが使用するアプリケーションへのアクセスを提供するために使用されます。 通常、Amazon Web Services、MS Azure、Orace OCIなどの仮想環境でホスティングされます。「Access Gatewayのデプロイメントを管理する」を参照してください。 |
ファイアウォール | 内部インターネットへのDMZ | Access Gatewayが参照する保護対象WebリソースをホスティングするDMZと内部ネットワーク間の従来のファイアウォール |
内部ネットワーク | appN.example.com | Access Gatewayによって保護されたアプリケーションの1つにアクセスするために、Webクライアントが入力するアプリケーションの1つを表すURL。通常、この性質のすべてのURLは、Access Gatewayインスタンスによってサービスされ、解決されます。 |
保護されたアプリケーション | 保護対象Webリソースのセットは、protd-N.internal-example.com URLを使用してアクセスされます。従来のアプリケーションであり、Access Gatewayが、各アプリケーションの定義内で保護対象Webリソースフィールドを使用して対話します。 Access Gatewayがロードバランサーとして前面に配置されている可能性があります。「負荷分散」をご参照ください。 |
その他の考慮事項
DNSは通常、外部ドメインと内部ドメインの間で分割されます。[appN|consumer-app1].example.comなどの外部URLはすべて外部で使用され、Access Gatewayインスタンスを指し示します。[protd-N|consumer-app1].internal-example.comなどのAccess Gatewayで使用される内部URLは、内部DNSで提供されます。
ほとんどのアーキテクチャは、ログイベントを外部のsyslogコンポーネントに転送します。Oktaは、すべてのAccess Gateway環境にログサーバーを設定することを強く推奨します。詳しくは、「ログフォワーダーを設定する」を参照してください。
さらに、Access Gateway自体は、通常、内部アクセスを介してのみ管理されます。つまり、管理者は通常、ファイアウォールの内側からAccess Gateway自体にアクセスします。これは、他のアーキテクチャで示されています。