Okta Privileged Accessゲートウェイ

ゲートウェイは、独自のインフラストラクチャにデプロイされる軽量のサーバーまたは仮想マシンで、Okta Privileged Accessと管理するリソースをブリッジします。各ゲートウェイは、登録に使用するセットアップトークンの作成時に割り当てた、2つのロールのいずれかで動作します。

ゲートウェイロール

サーバーアクセスプロキシゲートウェイ

高可用性

ゲートウェイは、高可用性を保証するメカニズムを複数備えており、単一障害点のリスクのないBastion（踏み台）ホストの機能性として機能できます。ゲートウェイは、標準の負荷分散に加え、サーバーへの常時アクセスを確保するためのさまざまなメカニズムを備えています。これらのメカニズムには、組み込みのステータスチェックと、複数のゲートウェイが同じラベルで登録されている場合の自動負荷分散が含まれます。「 Okta Privileged Accessゲートウェイの高可用性」を参照してください。

そのトピックで説明されている接続ルーティングと負荷分散の動作は、サーバーアクセスプロキシロールのゲートウェイに適用されます。インフラストラクチャオーケストレーターロールのゲートウェイは、代わりにオーケストレーショングループメンバーシップを通じて冗長性を提供します。「オーケストレーショングループ」を参照してください。

セキュリティ

以下の特徴では、SSH Bastion（踏み台）を置き換えるか補完する、サーバーアクセスプロキシロール内のゲートウェイについて説明します。Okta Privileged Accessゲートウェイは、以下の設計により、SSH Bastion（踏み台）よりも安全です。

• ゼロトラスト
• 論理的アクセス管理
• ネイティブIDプロバイダー（IdP）の統合

ゼロトラスト

標準のSSH接続では、なんらかの秘密の資格情報（パスワード、キー、証明書など）を使ってサーバーに接続します。これらの資格情報は短時間のみ有効である可能性はあるものの、クライアントまたはエッジデバイスが侵害された場合、攻撃者がターゲットサーバーに直接アクセスできるようになることがあります。

SSH接続にOkta Privileged Accessゲートウェイを使用する場合、クライアントは、サーバーとの直接SSH接続に利用できる資格情報を受け取りません。クライアントが代わりに受け取るのは、ゲートウェイに転送され、ゲートウェイのみが復号できる暗号化されたペイロードです。このアプローチには次のような利点があります。

• 侵害されたクライアントデバイスが、ターゲットサーバーに直接SSH接続するための資格情報を攻撃者に与えてしまうことがありません。
• アクセスはゲートウェイを通過しなければならないため、侵入検知システム（IDS）やその他のモニタリングツールを使ってアクセス試行を監視する方が簡単です。

論理的アクセス管理

適切なアクセス制御を維持することは、SSH Bastion（踏み台）を使用している場合でも、困難な可能性があります。ユーザーのアクセス許可を記録しておき、どのBastion（踏み台）がどのサーバーにアクセス可能であるかの記録を保持しておくことが重要です。各Bastion（踏み台）のセキュリティ要件がアクセス可能なサーバーに応じて異なる場合は、さらに複雑になります。

Okta Privileged Accessゲートウェイは、この複雑さをラベルによって軽減します。ラベルによって、あるプロジェクトでどのゲートウェイを使ってサーバーへの接続をルーティングするかが決まります。ラベルを使用することで、クラウドリージョン、コンプライアンス認定、オペレーティングシステム、ユーザーが選択するキーと値のペアなどに基づいてゲートウェイをスライスできます。プロジェクトで使用するラベルとラベルセレクターが正確であれば、ターゲットサーバーへのアクセスに使用されるゲートウェイが要件を満たすことに確信を持てます。

たとえば、データが特定の国の国境を越えてはならないと規定するデータの局所要件について考えてみましょう。従来のBastion（踏み台）環境では、すべてのターゲットサーバーとBastion（踏み台）サーバーを監査し、国内のBastion（踏み台）サーバーを経由しないとサーバーにアクセスできないことを確認する必要がありました。ゲートウェイを使用する場合、ゲートウェイの動作リージョン（例：AWSリージョン）に基づいてゲートウェイにラベルを付けることができます。個々のサーバーを監視する必要はなくなり、このようなアクセス制限を必要とするサーバーのプロジェクトにゲートウェイセレクターとしてリージョンを追加します。

ゲートウェイは、特にOkta Privileged Accessグループと組み合わせてユーザーの管理に使用する場合、コンプライアンス要件を満たすための強力なツールとなります。

ネイティブIDプロバイダー（IdP）の統合

SSHはサーバーへのアクセスを保護するための素晴らしいプロトコルですが、フェデレーションIDプロバイダーが登場する以前に設計されたものです。そのため、認可スキームは人間のアイデンティティではなく、マシンのアイデンティティを中心としています。SSHは、組織や会社の部署、職務ではなく、サーバーやキー、証明書に応じてユーザーに対処します。

このため、SSH Bastion（踏み台）は各種形式のサイドチャネル攻撃に対して無防備です。十分なアクセス権を持つユーザーがBastion（踏み台）またはターゲットサーバーの構成を変更できるとしましょう。その場合、そのようなユーザーはターゲットサーバーにアクセスしてIDプロバイダーをバイパスできます。たとえば、サーバーに管理者としてアクセスできるユーザーがsshd構成を変更し、アクセスがログに記録されないように公開鍵をインストールしたなら、どうなるでしょうか。

ゲートウェイは、SSHなどの汎用プロトコルになるのではなく、Okta Privileged Accessと深く結びつくことでこの問題に対応します。ゲートウェイを通過するには、ユーザーはOkta Privileged Accessクライアントを実行し、Oktaによって認証される必要があります。これにより、ゲートウェイの背後にあるサーバーへのすべてのアクセスがOktaによって保護されることが保証されます。

インフラストラクチャオーケストレーターゲートウェイ

データベース統合は、インフラストラクチャのオーケストレーション用に構成されたセットアップトークンを使って登録されるゲートウェイによりサービスされます。ゲートウェイは、データベースインスタンスとのすべての直接の通信を処理します。ユーザーに代わってアカウントの検出とパスワードのローテーションを行うため、Okta Privileged Accessがデータベースインスタンスに直接接続することはありません。独自のインフラストラクチャでゲートウェイを実行するため、そのトラフィックは環境内に留まります。

インフラストラクチャオーケストレーションは、デフォルトでは有効化されていません。セットアップトークンにインフラストラクチャオーケストレーター（Infrastructure orchestrator）ロールを割り当てた上で、ゲートウェイ構成ファイルでオーケストレーションを有効にします。「データベース統合用にゲートウェイを構成する」を参照してください。

データベース統合を追加する前に、ゲートウェイをセットアップします。ゲートウェイがデータベースインスタンスにアクセスできない場合は、統合の作成は失敗します。すべてのシーケンスについては、「最初のデータベース統合をセットアップする」を参照してください。

オーケストレーショングループ

オーケストレーショングループは、インフラストラクチャオーケストレーション用に構成されるゲートウェイの名前が付いたセットです。各セットアップトークンにより、1つのオーケストレーショングループが作成されます。インフラストラクチャオーケストレーター（Infrastructure orchestrator）セットアップトークンの作成時にグループを指定すると、そのトークンで登録されたすべてのゲートウェイがそのグループに参加します。「セットアップトークンを作成する」を参照してください。

データベース統合を追加する際には、その統合で使用されるオーケストレーショングループを指定します。そのグループのゲートウェイは、その統合向けのアカウント検出とパスワードローテーション作業を実行します。

各登録ゲートウェイでプロジェクトがラベルによりゲートウェイにリンクされるサーバーアクセスプロキシゲートウェイとは異なり、データベース統合は、指定した単一のオーケストレーショングループによってそのゲートウェイにリンクされます。

冗長性を追加するには、同じオーケストレーショングループで2つ以上のゲートウェイを登録します。グループ内の任意のゲートウェイが割り当てられた統合の作業を実行できるため、1つのゲートウェイが利用できなくなる場合でも統合は動作し続けます。グループ内のすべてのゲートウェイは、そのグループに割り当てられた統合が使用する各データベースインスタンスにアクセスできなければなりません。ゲートウェイがすべてのターゲットインスタンスにアクセスできないグループでは、統合の正常性が低下します。「データベース統合の正常性ステータス」を参照してください。

オーケストレーターゲートウェイのネットワーク要件

インフラストラクチャオーケストレーターロールのゲートウェイには、次のネットワークアクセスが必要です。

• ポート443でのOkta Privileged Accessへのアウトバウンドアクセス。これは、特定のIPアドレスへのアクセスではなく、DNS名による本番およびプレビューのOkta Privileged Accessドメインへのアクセスを意味します。ドメインについては、「Okta Privileged Accessポート要件」を参照してください。

• インスタンスのリスナーポートで、サービスを行う各データベースインスタンスへのアウトバウンドアクセス。たとえば、PostgreSQLの場合はポート5432、MySQLの場合はポート3306です。

データベースは、オンプレミス、クラウドインフラストラクチャ、またはサービスとしてのプラットフォーム（PaaS）サービスのいずれにデプロイされているかに関係なく、常にゲートウェイを必要とします。「サポートされているデータベースのタイプ、バージョン、デプロイメントオプション」および「環境別のネットワークアクセス」を参照してください。