Kerberosクラスターアプリケーションのリファレンスアーキテクチャ
KerberosクラスターAccess Gatewayアーキテクチャは、Access Gatewayおよび冗長Kerberosクラスターを使用してKerberosベースの認証および承認に必要なコンポーネントのセットを表します。このアーキテクチャは、Access GatewayとKerberosの両方にフォールトトレランスを提供する環境を表します。
このアーキテクチャは、以下の要件を満たすように設計されています。
- Kerberos(Windows IIS)ベースのサービスを保護する。
- Access Gatewayの基本的なフォールトトレランスと高可用性のニーズを満たす。
- Kerberosドメインとキーディストリビューションセンター(KDC)の基本的なフォールトトレランスと高可用性を満たす。
利点と欠点
利点 | 欠点 |
---|---|
|
|
アーキテクチャ
コンポーネント
ロケーション |
コンポーネント | 説明 |
---|---|---|
外部インターネット | Webクライアント |
従来のクライアントブラウザで、[appN|consumer-app1].example.com URLとして認識されるAccess Gatewayにアクセスします。 |
consumer-app1.example.com URLは非表示 | 外部WebクライアントがAccess Gatewayによって保護対象アプリケーションの1つにアクセスするために入力するアプリケーションを表すURL。通常、この性質のすべてのURLは、Access Gatewayインスタンスによってサービスされ、解決されます。 | |
Okta org |
Okta orgは、アイデンティティサービスを提供しています。 |
|
Okta org Universal Directory |
Okta orgでホスティングされるOkta Universal Directoryには、その他のLDAPまたはActive Directory実装の外部のユーザーが含まれます。通常、これにはその他のカスタマーアカウントやパートナーアカウントなどが含まれます。 |
|
ファイアウォール | 外部インターネットからDMZ | 外部インターネットとDMZホスティングAccess Gatewayの間の従来のファイアウォール。 |
DMZ | Access Gateway前のロードバランサー | ロードバランサー前 クライアントとクラスター間の負荷分散を行います。クライアントとクラスターの間に配置されます。 |
Access Gateway | DMZ内に配置されるAccess Gatewayクラスターは、外部インターネットクライアントが使用するアプリケーションへのアクセスを提供するために使用されます。 Kerberosサービスとキータブを含みます。 キータブの作成の詳細については「キータブを作成する」を参照してください。 Access Gateway Kerberosサービスの定義についての詳細は、「Kerberosサービスを追加する」を参照してください。 通常、Amazon Web Services、MS Azure、Orace OCIなどの仮想環境でホスティングされます。「Access Gatewayのデプロイメントを管理する」を参照してください。 |
|
ファイアウォール | DMZから内部ファイアウォール | DMZと内部ネットワーク間の従来のファイアウォール。 |
内部ネットワーク | サービス/保護対象アプリケーション |
保護対象Webリソースのセット(この場合はMicrosoftサービス)で、consumer-app1.internal-example.com URLを使用してアクセスされます。
サポート対象バージョン:
|
内部前Kerberosドメイン負荷分散 | Kerberosドメインサービスクラスター用のロードバランサー。 | |
キーディストリビューションセンターを含むMicrosoftドメインサービスクラスター |
キーディストリビューションセンター(KDC)を含むドメインサービスクラスター。 このアーキテクチャにおいて、ドメインサービス/KDCは、クラスターとして作用する複数のインスタンスを表します。 |
その他の考慮事項
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自体にアクセスします。これは、他のアーキテクチャで示されています。