RADIUS展開アーキテクチャ

以下のセクションでは、一般的に推奨されるRADIUSデプロイメントのアーキテクチャを説明します。

Cisco ASAなど、VPNの背後でのアクティブ-パッシブフェイルオーバー

これは最も単純な展開モデルです。単一のアクティブなOkta RADIUSサーバーエージェントが提供できる以上の高いスループット要件がない環境の場合、このモデルで十分です。

このアプローチでは、1つのOkta RADIUSサーバーエージェントをVPNデバイスのアクティブサーバーとして構成し、別のOkta RADIUSサーバーをパッシブフェイルオーバーとして構成します。総スループットは、単一のRADIUS Serverエージェントの能力によって異なります。

アクティブ-パッシブアプローチを実装する場合、フェイルオーバーはクライアントの責任です。何らかの理由でアクティブRADIUS Serverエージェントに到達できない場合は、パッシブRADIUS Serverエージェントインスタンスを指すようにクライアントを再構成できる必要があります。

ロードバランサーの背後でのアクティブ-アクティブ（高スループット）

このセクションで使用する一部の例と用語では、Cisco ASA VPNクライアントを使用するF5ロードバランサーを想定しています。

最高のスループットと可用性を実現するには、ロードバランサーの背後に2つ以上のOkta RADIUS Server Agentを展開することをお勧めします。このアプローチでは、負荷分散プールに追加のRADIUS Server Agentを追加し、トラフィック負荷をエージェント間で均等に分散することで、水平方向のスケーリングが可能です。RADIUS Server Agentの数は、予想されるボリュームと、ピーク時の1分あたりのトランザクションによって異なります。

  • 仮想ネットワーク

    RADIUS要求を送信するデバイスごとに個別の仮想サーバーを設定します。仮想サーバーごとに個別のサーバープールを作成します。

  • セッション永続化

    パフォーマンスを最適化するため、負荷分散はエンドユーザーのVPNクライアントまたはIPに基づくセッション永続化（スティッキーセッション）を使用して行う必要があります。これは、二要素認証チャレンジへのユーザー入力の待機がオフバンド（Okta Verify with pushなど）で行われる状況で特に重要です。Okta RADIUS Serverエージェントは、発信元のRADIUSクライアントからのリクエストの重複を解決します。ただし、リクエストが複数のエージェントに分散している場合、重複はOktaサービス側で解決されるため、不要な負荷がかかります。

    永続化の構成として、通常はCalling-Station-IDとFramed-IPを組み合わせて使用することを推奨しています。多くのVPNでは、Calling-Station-IDは発信元のクライアントIPアドレスになります。別のRADIUS属性がクライアントIPアドレスを格納している場合、代わりにその属性を使用するようにロードバランサーを構成します。

  • 負荷分散方法

    アクティブなRADIUS Server Agentに負荷を分散できる場合は、最小接続の負荷分散方法を設定することをお勧めします。

  • ヘルスチェック

    合成サインインでロードバランサーのヘルスチェック機能を使用して、RADIUS Serverエージェントの問題が発生した場合にフェイルオーバーがユーザーへの影響を最小限に抑えながらシームレスに行われるようにします。各仮想サーバーは、それぞれのポートで独自のヘルスチェックを行う必要があります。ヘルスチェックを実行するようにロードバランサーまたはRADIUSクライアントを構成するには、この目的にのみ使用するユーザーアカウントを作成します。次の手順を実行することをお勧めします：

    1. 割り当てられたグループや、アプリケーションへのアクセス権がなく、基本的なユーザーアカウント以上の権限を持たないユーザーを作成します。
    2. ヘルスチェック用のユーザーアカウントには、一意の強力なパスワードを作成します。

      注：パスワードおよびユーザー名にハッシュ（#）文字を含めることはできません。

    3. このインバウンドヘルスチェックをトリアージするためのカスタムRADIUSアプリケーションを作成します。
    4. このユーザーをRADIUSアプリケーションに割り当てます（これによりアクセスが許可されます）。

    このアカウントの目的は、RADIUSクライアントがOktaサービスにアクセスし、認証要求を適切に処理できることを検証することです。第2要素のトランザクションは通常、何らかのユーザー入力または動的応答を必要とするため、通常、ヘルスチェックにはプライマリ認証のみを含める必要があります。

    2回連続して失敗した後、RADIUSサーバーをローテーションから外すようにロードバランサーを設定します。サーバーからの応答が1回成功した後、サーバーをローテーションに戻すようにロードバランサーを設定します。

  • ロードバランサーの高可用性

    • システム全体の可用性を最大限に高めるため、単一障害点を回避できるようにロードバランサーの冗長システムを構成することを検討してください。推奨事項については、ロードバランサーベンダーのドキュメントを参照してください。

RADIUSの負荷分散に関するF5の全体的な推奨事項については、RADIUSの負荷分散に関するF5のドキュメントを参照してください。F5はRADIUSボリュームを管理するためのiAppをサポートしています。このiAppは、エンドユーザーが確実に認証できるようにするための代理トランザクションによる自動ヘルスチェックもサポートしています。