Okta Privileged Accessゲートウェイの容量計画

ゲートウェイに割り当てるリソースは、ゲートウェイが実行するロールによって異なります。Okta Privileged Accessゲートウェイは、次のいずれかのロールを実行できます。

• サーバーアクセスプロキシ（Server access proxy）：ゲートウェイは、SSHおよびRDPセッションとサーバーを仲介します。ゲートウェイは、処理する同時セッション数と保存するセッション記録に合わせてサイズを指定します。
• インフラストラクチャオーケストレーター（Infrastructure orchestrator）（データベース）：ゲートウェイは、統合されたデータベースに対してアカウント検出とパスワードローテーションのタスクを実行します。サービスを行うデータベース全体のユーザー総数に合わせてゲートウェイのサイズを指定します。

以下の各セクションのガイダンスでは、1つのロールを実行するゲートウェイを想定しています。Oktaでは、両方のロールを実行するゲートウェイをテストしていないため、そのようなゲートウェイに必要なリソースについて推奨することはできません。

サーバーアクセスプロキシの容量計画

ゲートウェイがSSHおよびRDPセッションを仲介する場合、必要な処理とメモリは同時セッション数によって決まります。セッションキャプチャを有効にすると、必要なストレージは保持するセッション記録の量によって決まります。

処理とメモリ

Okta Privileged Accessゲートウェイのホスティングに使用するサーバーまたはインスタンスのタイプは、利用するプロバイダーによって異なります。

2つのvCPUと4 GBのRAMを備えたゲートウェイは、120の同時SSHセッションを処理します。CPUの使用はセッション数に応じて増減し、メモリの使用は低い状態で維持されます。

Amazon Web Services（AWS）（AWS）では、このサイズの現行世代のバースト可能なインスタンスがこの要件を満たしています。たとえば、EBSボリュームを持つt3.mediumやt4g.mediumインスタンスです。元のテストは、同じサイズの前世代である、t2.mediumインスタンスで実行されました。

ストレージ

Okta Privileged Accessゲートウェイを使ってSSHセッションキャプチャをデプロイする場合は、必要なストレージのタイプと容量の両方を慎重に検討してください。

最適なストレージソリューションはSSD（ソリッドステートドライブ）です。ゲートウェイに接続する専用SSDや、Amazon Elastic Block StoresなどのSSDベースのストレージとして使用できます。

必要なストレージの容量は、ユーザーのワークロードによって異なります。たとえば、ディレクトリリスティングを5秒おきに実行する30分間の対話型セッションをキャプチャすると、約150キロバイトのサイズのバイナリファイルが保存されます。

セッションの記録が有効に設定されていても、セッションログの保存に利用できるゲートウェイのストレージが不十分な場合、ゲートウェイはセキュリティ上の理由から接続を阻止します。この状況を回避するには、ログに利用できるストレージ容量が十分であるかを確認するために、ゲートウェイのストレージ使用率を監視することをお勧めします。

セッションログのストレージ容量を十分に確保する方法の1つとして、利用できるクラウドストレージを格納先として使用することが挙げられます。進行中のセッションが格納される一時ディレクトリ（ほとんどのシステムでは/tmp）に、予想されるセッションのログを保存するのに十分な容量があることを確認してください。

インフラストラクチャオーケストレーターの容量計画

オーケストレーターゲートウェイは、統合されたデータベースに対してアカウントの検出とパスワードのローテーションを実行します。必要な処理とメモリは、それらのデータベース全体での総ユーザー数によって決まります。

ゲートウェイがサービスを行うすべてのデータベースでユーザーを合計します。統合数はプライマリ要素ではないため、各100人のユーザーを持つ10個の統合には、1,000人のユーザーを持つ1個の統合とほぼ同じ容量が必要になります。

検出で返されるすべてのユーザー（管理していないユーザーおよびパスワードで認証しないユーザーも含む）をカウントします。それらすべてをカウントすると、推定値を控えめにできます。

総ユーザー数に一致する行を見つけます。開始点としてこれらのサイズを使用します。要件は、データベースのタイプ、統合数、ワークロードによって異なる可能性があります。

vCPUとRAMの値は要件として、インスタンス名はそれを満たす例として扱います。一部の例では、最小よりも多くのRAMを提供します。

オーケストレーターゲートウェイは、検出とローテーションの実行の間にCPUをほとんど使用せず、タスクの実行中に短時間のみ使用します。バースト可能なインスタンスは、低いベースラインで実行され、バースト中に累積されたクレジットを利用するため、このパターンに適しています。

独自の仮想マシンまたは物理ハードウェアでゲートウェイを実行する場合、バーストクレジットの動作が生じないため、テーブル内のvCPUとRAMを固定リソースとしてプロビジョニングします。汎用的な例では、同等のバースト可能でないサイズを示しています。

高可用性

Oktaでは、各オーケストレーショングループに2つのゲートウェイを推奨しています。1つのゲートウェイが利用不可になった場合でも検出とローテーションを維持し、タスクの負荷が共有されます。

オーケストレーショングループの全ユーザー数に合わせて、両方のゲートウェイのサイズを指定します。いずれかのゲートウェイが独自で負荷全体を処理できる必要があるため、それらの間で数を分割しないでください。

サイズ指定の例

次の例は、統合数ではなく、総ユーザー数が推奨事項を推進する仕組みを示しています。

検出パフォーマンス

検出は高速です。2つのvCPUと4 GBのRAMを備えたゲートウェイでは、検出は、最大1,500人までの各ユーザー数に対して1秒以内で完了します。

検出タスクは連続して実行され、スケジュールされた実行は統合全体でランダム化されているため、オーケストレーショングループ内の統合がすべて同時に検出を開始するわけではありません。手動で開始した検出は1回限りです。総ユーザー数が推奨範囲内にある場合は、複数の統合でオーケストレーショングループを共有することをおすすめします。

すでに負荷がかかるデータベースに対する検出には時間がかかる可能性があります。これは、必要なゲートウェイのサイズではなく、検出時間に影響します。

ローテーションパフォーマンス

ローテーションは検出よりも時間がかかりますが、使用するCPUは少ないです。ローテーションは連続して処理されるため、1つバッチの合計時間はローテーションするユーザー数に応じて増加します。

1つのユーザーローテーションは約4秒で完了します。より大きなバッチは、1秒あたり2.5～5人のユーザーの一定レートで処理します。そのレートでは、100人のユーザーをローテーションするのに約20～40秒かかり、1,000人のユーザーをローテーションするには約3～7分かかります。