【Okta】Okta Privileged Access による安全な SSH サーバアクセス（基本編）

はじめに

ネクストモードのゆきなわです。

本記事では、まず Okta Privileged Access の全体像を紹介します。その後、Okta Privileged Access の主要な機能の一つである SSH サーバへのリモートアクセス管理に焦点を当て説明します。さらに、実践的な理解を深めるため、ユーザ端末から外部公開された踏み台 SSH サーバへのアクセスというベーシックなユースケースを取り上げ、基本的な構築手順と利用方法を紹介します。

※本記事は2024年9月末の情報に基づいて作成しています。本記事の内容は今後のアップデートや変更により異なる場合がありますので、最新情報については Okta 社公式サイトや関連ドキュメントをご確認ください。

目次

• Okta Privileged Access とは
  • Okta Privileged Access の概要
  • Okta Privileged Access の構成要素
    • 全体システム構成
    • Okta Privileged Access プラットフォームの管理要素
• SSH サーバアクセスの典型的課題と Okta Privileged Access の関連機能
  • SSH サーバアクセスとその課題
  • Okta Privileged Access が提供する SSH サーバアクセス関連機能
• ユースケース
  • ゴールと前提条件
  • 構築手順
    1. アプリ統合の作成
    2. ユーザとグループの設定
    3. プロビジョニング設定
    4. グループプッシュとロールの設定
    5. リソースの設定
    6. ポリシーとルールの設定
  • ユーザ利用方法
    1. ユーザ端末へのクライアントソフトウェアのインストールと登録
    2. サーバへの接続
• 参考ドキュメント
• まとめ

具体的な使い方をすぐに知りたい方は、「ユースケース」からお読みいただくことをお勧めします。また、「Okta Privileged Access の構成要素」と「Okta Privileged Access が提供する SSH サーバアクセス関連機能」も併せてお読みいただくと、より理解しやすくなると思います。

Okta Privileged Access とは

Okta Privileged Access の概要

Okta Privileged Access は、Okta Workforce Identity Cloud (Okta WIC) が提供するマネージドプラットフォームの一つです。アプリケーション開発・運用保守に使用するサーバなど、組織の重要なリソースに対する特権アクセス管理（Privileged Access Management; PAM）を実現します。対象リソースとして、本記事のテーマである SSH サーバ、RDP サーバ、パスワードや API キーなど任意の文字列からなるシークレット、Kubernetes (K8s) クラスタ（現在2024年9月末時点、ベータ提供）、クラウドインフラ (IaaS) をカバーしています。

Okta Privileged Access の主な特徴は以下の通りです。

リソースに対するポリシーベースの特権アクセス管理

Okta Privileged Access を利用することで、サーバ、シークレット、K8s クラスタを含むリソースへのアクセス管理を Okta WIC 上で一元化できます。具体的には、いつ（期間）、誰が（対象ユーザ）、どのように（対象デバイス、接続環境など）、どの権限で（一般ユーザかあるいは管理者ユーザか、また、サーバ上の既存ユーザなど）リソースへのアクセスを許可するかについて、セキュリティポリシーの設定により柔軟に制御することができます。

また、Okta System Log と統合された監査イベントのログ収集と、ゲートウェイを設置することで、サーバのアクセス時のログインセッションの記録が可能です。

Okta MFA / Identity Governance との連携によるセキュリティ強化オプション

サーバアクセス時に、Okta の強力なシングルサインオン (SSO) と 多要素認証 (MFA) と連携したセキュアな追加ユーザ認証、Identity Governance (弊社久住によるブログ記事) の Access Requests とシームレスに統合された承認フローを導入することが可能です。これにより、セキュリティ運用要件に応じた、より安全な特権アクセス管理を実現することが出来ます。

パブリッククラウドのエンタイトルメント管理

クラウドインフラに対しては、クラウドエンタイトルメント管理 (Cloud Infrastructure Entitlement Management; CIEM) 機能を提供しています。ただし、2024年9月末時点では、AWS クラウドアカウントにおける Amazon RDS へのアクセス権の分析 (Entitlement Analysis) によるリスク評価のみの提供となっています。

このように、現時点では Okta Privileged Access の CIEM 機能は限定的であり、今後の機能追加が期待されます。一方で、Okta WIC では、AWS クラウドへのきめ細かなアクセス管理については、Okta Integration Network で提供されているアプリ統合である AWS Account Federation や AWS IAM Identity Center を通じて実現できます。こうしたことを踏まえると、Okta Privileged Access は、これらの既存機能を補完し、さらに強化する役割を果たす方向で発展していくものと考えられます。

Okta Privileged Access の構成要素

Okta Privileged Access の構成要素を、筆者の解釈も踏まえ、システム構成とプラットフォームの管理要素という二つの側面から紹介します。
後述するユースケースでの構築手順をより理解しやすくする目的も兼ねています。

※Kubernetes クラスタの管理機能についてベータ提供のため、スコープアウトしている点、ご了承ください。

全体システム構成

システムの構成要素を大まかに分類すると、1) 個別の Okta org テナントとそれに紐づけられた Okta Privileged Access アプリケーション、2) サーバ、シークレット、クラウドインフラを含む各種リソース、3) 管理者端末、4) リソースへアクセスするエンドユーザ端末、5) Okta Privileged Access ソフトウェア群となります（下図: システム概念図）。

1. Okta Privileged Access アプリケーション

   Okta Admin Console、Okta Dashboard とは独立した Okta WIC のアプリケーションとして提供されます (Okta Workflows、Okta Access Requests などと同様)。 Okta org ごとに個別の環境が払い出されます。Okta org のドメインが hoge.okta.com の場合、アプリケーションのドメインは hoge.pam.okta.com となります。

   本アプリケーションを通じ、管理者・ユーザは Okta Privileged Access プラットフォームへアクセスし、各種操作を実行します。

2. リソース

   SSH/RDP サーバ、シークレット、クラウドインフラ (AWS アカウント)、ゲートウェイサーバ（設置はオプション）が含まれます。これらは Okta Privileged Access アプリケーションを通じて、管理者やユーザーの操作により同プラットフォームに登録・管理されます。

3. 管理者端末

   管理者はこの端末を通じて Okta Privileged Access アプリケーションにアクセスし、割り当てられている管理者ロールの権限に従い、各種リソースの登録やセキュリティポリシーの設定、後述する各種管理要素に関する管理操作を実施します。

   また、セキュリティポリシーでリソースへのアクセスで Okta Access Requests による承認フローを有効化しており、承認者を兼ねている場合、ユーザからのアクセスリクエストの承認・否決などの操作を行います。

4. ユーザ端末

   ユーザはこの端末を通じて Okta Privileged Access アプリケーションにアクセスし、アクセス権限のあるシークレットの確認、サーバへのアクセスのためのショートカットの起動などの操作を行います。また、後述する Okta Privileged Access クライアントソフトウェアを利用して、プラットフォームへの端末登録を行います。

   登録済みのユーザ端末は、SSH/RDP クライアントと Okta Privileged Access クライアントソフトウェアを利用し、セキュリティポリシーに基づいたサーバアクセスを行います。セキュリティポリシーで承認フローが有効化されている場合、サーバへのアクセス時に自動的にアクセスリクエストが発行されます。また、MFA が有効な場合は、追加認証が要求されます。

5. Okta Privileged Access ソフトウェア群

   ユーザ端末やサーバリソースを Okta Privileged Access プラットフォームに登録し、連携を行うために必要なソフトウェア群となり、クライアント、ゲートウェイ、サーバエージェントより構成されています。

   それぞれ、リソースにアクセスするユーザ端末、ゲートウェイサーバ、SSH/RDP サーバにてダウンロード・インストールを行い、Okta Privileged Access アプリケーションに表示される情報を元に登録 (enrollment) の操作を行います。クライアントは端末からプラットフォームを利用するためのコマンドライン・インタフェースを備えています。

   各ソフトウェアがサポートする OS プラットフォームの情報ついては、下記の公式ドキュメントを参照してください。

   • Supported operating systems | Okta

Okta Privileged Access プラットフォームの管理要素

Okta Privileged Access プラットフォーム内で管理される要素について、下記公式ドキュメントの記述を参考に、筆者の解釈も踏まえ、管理要素のグルーピングと要素間の関係、Okta Universal Directory (UD) との連携も含めた概念図を以下にまとめます。

• Components | Okta

※本記事では重要と考えられる管理要素は記載していますが、セキュリティの管理要素である「ラベル」など、Okta Privileged Access の全ての管理要素を網羅するものではない点、ご了承ください。

上記ドキュメントの内容と一部重複しますが、管理要素のグルーピング 1) チーム、2) ディレクトリ、3) リソース、4) セキュリティごとにより詳しく見ていきます。

※本記事のグルーピングのディレクトリ、リソース、セキュリティについては、Okta Privileged Access アプリケーションの UI 上のメニュー大項目における名称 (Directory, Resource Administration, Security Administration) を元にしています。これらは後述するロールの権限で操作できる範囲とも一致するものとなっています。

1. チーム

   チームは最上位の管理要素です。個別の管理要素の設定はこのチーム内で行われます。複数のチームの作成により、組織ごと、開発プロジェクトごとに独立した環境を構成するなど、要件に応じた柔軟な運用ができます。

2. ディレクトリ

   ユーザは管理者・一般ユーザを含む Okta Privileged Access の利用者です。Okta Universal Directory（UD）上のユーザを Okta Admin Console で Okta Privileged Access アプリケーションに割り当てることで、Privileged Access にプロビジョニングされ、連携されます。

   グループは Okta Privileged Access 上でローカルグループとして作成できるほか、UD 上のグループをプッシュすることで連携することも可能です。

   ロールは一般ユーザ権限、細分化された管理者権限を規定しており、グループへの割当を通じてユーザの権限を制御します。

   ロールと権限の詳細は、下記の公式ドキュメントを参照してください。

   • Roles and permissions | Okta

   サービスユーザは前述のユーザとは別個に存在する内部ユーザで、Okta WIC からのユーザのプロビジョニングなど、外部システムから API を介してプラットフォームを操作する際などに使用します。

   クライアントについては、前述の「全体システム構成 4. ユーザ端末」と同等の内容となるため、ここでは省略します。

   ディレクトリの管理には、PAM 管理者 (PAM Administrator) ロールが割り当てられたグループに属するユーザが必要です。また、Okta UD から連携されているユーザ・グループの管理については、Okta org 上でグループ管理者・アプリ管理者のロールを持つユーザが必要です。

   ただし、クライアントについては例外があり、登録ポリシー (Enrollment Policy) で自己登録 (Self Enrollment) を有効にしている場合、管理者ロールを持たない一般ユーザの操作のみで登録が可能です。なお、自己登録にはオプションで管理者の承認を要求することもできます。

3. リソース

   リソースグループはリソースを管理する最上位の管理要素で、複数のリソースグループの作成が可能です。

   プロジェクトは、サーバ、シークレット、サーバ内のローカルアカウントなどの個別リソースを登録して管理する上位要素です。リソースグループ内に複数のプロジェクトを作成でき、きめ細かなリソース管理が可能となります。

   個別のリソースである、サーバ、シークレットについては前述の「全体システム構成 2. リソース」で説明済みのため割愛します。ローカルアカウントは、サーバ内のローカルユーザであり、Okta Privileged Access サーバエージェントをサーバに導入することで自動的に連携されます。

   ゲートウェイはサーバサーバ、シークレット、ローカルアカウントとは異なり、リソースグループ外の管理要素となります。登録したゲートウェイはプロジェクト単位でサーバに割り当てて利用します。

   リソースの管理には、リソース管理者 (Resource Administrator) ロール、または、リソースグループ単位で割り当てる代理リソース管理者 (Delegated Resource Administrator) ロールが割り当てられたグループに属するユーザが必要です。

4. セキュリティ

   ポリシーはリソースに対するアクセス権限を規定する管理要素です。複数のポリシーを作成でき、各ポリシーはリソースグループ単位で適用されます。また、各ポリシーには対象ユーザが所属するグループを割り当てます。

   こうしてポリシーの割当により特定のリソースアクセス権限を持ったグループ（およびそれに所属するユーザ）のことをプリンシパルと呼びます。

   各ポリシーでは、リソースグループ内の個別プロジェクトに含まれるリソースに対して、詳細なアクセス制御を定義する複数のルールを設定できます。

   セキュリティの管理には、セキュリティ管理者 (Security Administrator) ロールが割り当てられたグループに属するユーザが必要です。または、各ポリシーの適用単位であるリソースグループごとに割り当てる、代理セキュリティ管理者 (Delegated Security Administrator) ロールを持つユーザが個別に管理することも可能です。

各管理要素の上限数など、制限の詳細は下記の公式ドキュメントを参照してください。

• Requirements and limitations | Okta

SSH サーバアクセスの典型的課題と Okta Privileged Access の関連機能

ここではまず、SSH サーバアクセスに関する典型的な課題を示します。次いで、Okta Privileged Access の関連機能を紹介し、これらの課題をどのように解決できるか、また、独自の利点についてまとめます。

SSH サーバアクセスとその課題

①資格情報等の運用管理

SSH サーバアクセスの前提として、まず、サーバ上のユーザアカウントの継続的なライフサイクル管理（作成・削除など）が必要となります。LDAP などのディレクトリサービスと連携する場合でも、その構築と継続的な運用が求められます。

また、SSH サーバアクセス時の一般的なログイン方法として、1) 公開鍵認証、2) 証明書認証、3) （セキュリティ上、非推奨としているケースは多いですが）パスワード認証があります。1は端末側での秘密鍵の安全な保管、サーバへの公開鍵の設置、定期的なキーペアのローテーション、2は認証局 (Certificate Authority; CA) を含む署名用システムの構築と運用管理、3は複雑度の高いパスワードの徹底と安全な保管などが求められます。

このように、認証に必要な機密性の高い資格情報等の運用管理が、管理者・ユーザの双方に求められる課題となります。さらに、情報漏えいへの対策・準備も常に必要となります。そのため、管理対象となるユーザやサーバリソースの規模が大きくなるほど、運用が煩雑化する傾向にあります。

②コンプライアンスの確保

SSH サーバへのアクセスにおいて、組織が定めたコンプライアンスの遵守は情報セキュリティの観点から重要な課題です。組織のガバナンスを強化し、コンプライアンスを実現するためのシステム面でのアプローチには、主に次の2点があります。

1. アクセス制御と認証の強化
   • root ログインの制限、root 権限利用の制限
   • 多要素認証 (MFA) の導入
   • 安全な認証方法（公開鍵認証・証明書認証）の利用
   • 接続元端末の制限（デバイス、通信環境など） など
2. 監査ログの管理と監視
   • 接続ログの収集・管理
   • 接続時の端末の操作ログの収集・管理
   • 収集したログの定期的なレビュー など

しかし、これらの実現には SSH サーバ周りの設定だけでなく、個別の機能を持つ外部ソリューションとの組み合わせが必要な場合もあり、統合的な管理が課題となります。また、資格情報等の運用管理と同様に、組織やリソースの規模に応じた運用のスケーリングが課題となります。

Okta Privileged Access が提供する SSH サーバアクセス関連機能

Okta Privileged Access が提供する主要な SSH サーバアクセス関連機能について、その概要と前述の課題解決への効果・利点を以下の表にまとめます。「Okta Privileged Access の概要」で触れた内容と一部重複しますが、SSH サーバアクセスに焦点を当てて改めて整理しています。

※全ての機能を網羅するものではない点、ご了承ください。課題番号は上述の「SSH サーバアクセスとその課題」のものに対応しています。

これらの機能により、Okta Privileged Access が SSH サーバアクセスの典型的な課題に対して包括的なソリューションを提供していることがおわかりいただけるかと思います。

ユースケース

AWS 上の踏み台 SSH サーバへの接続というベーシックなユースケースを取り上げ、構築手順とユーザ側の利用方法を具体的に紹介します。

ゴールと前提条件

まず、今回のユースケースにおける全体の構成図を以下に示します。

ここでのゴールは、ユーザが Okta Privileged Access プラットフォームを使用して、AWS の EC2 インスタンスで構築された、インターネットからパブリックアクセス可能な踏み台 SSH サーバに個人アカウントを用いてオンデマンドでログイン、また、ログイン時に MFA を要求することとします。

本ユースケースを通じて、前述の「Okta Privileged Access が提供する SSH サーバアクセス関連機能」で紹介した機能のうち、「資格情報等の管理の自動化」、「個人アカウントでのログイン」、「個人アカウントの root 昇格権限の制御」、「サーバアクセス時の MFA の要求」の概要をご理解いただけるかと思います。

構築手順の説明に入る前に、サーバ、ユーザ端末、Okta org に関する前提条件を示します。

サーバ

• OS: Amazon Linux 2023 (x86_64) （Amazon Linux 2023 AMI よりインスタンスを作成）
• ネットワーク: パブリック IPv4 アドレスを割り当て、セキュリティグループで TCP ポート 22（SSH）および 4421（Okta Privileged Access サーバエージェントによるプロビジョニング等の制御に使用）へのインバウンド通信を許可、全てのアウトバウンド通信を許可（デフォルト）

Okta Privileged Access の通信ポート要件の詳細については以下の公式ドキュメントを参照してください。

• Okta Privileged Access port requirements | Okta

ユーザ端末

• OS: WSL2 上の Ubuntu 22.04.5 LTS (x86_64)

Okta org

• Okta org で管理者とユーザのアカウントを作成・アクティベーション済み
• アプリ統合の作成など Okta org 上の作業のため、管理者には Okta org 上のスーパー管理者 (Super Admin) ロールを割り当て済み
• Okta Privileged Access プラットフォームにプッシュするための各所属グループを作成、ユーザに割り当て済み

上記の設定を以下の表にまとめます。

ユーザ・グループ・ロールをより細分化した運用も可能ですが、今回のユースケースでは条件を単純化するため、ユーザは管理者とサーバにアクセスするユーザの2アカウントのみとし、グループもそれぞれに対応した2グループのみの構成としました。

構築手順

構築は 1) アプリ統合の作成、2) ユーザとグループの設定、3) プロビジョニング設定、4) グループプッシュとロールの設定、5) リソースの設定、6) ポリシーとルールの設定の流れで実施します。 以下は全て管理者による操作となります。

1. アプリ統合の作成

   【Okta Admin Console での操作】
   Applications > Browse App Catalog から “Okta Privileged Access” を検索し、Add Integration ボタンを押下します。

   General Settings の画面で、Application label と Team Name を適宜入力し Done ボタンを押下します。
   ここでは Team Name の値を myfirstteam とします。これにより Okta Privileged Access 上にチーム myfirstteam が作成されます。

   

   ※この時点で、裏側では、アプリ統合を作成した管理者のユーザアカウントに対応するユーザが Okta Privileged Access 上で自動的に作成され、PAM Administrator ロールを持つ owners グループに割り当てられます。

2. ユーザとグループの設定

   【Okta Admin Console での操作】
   Applications から 1 で作成したアプリ統合を開き、Assignments タブから事前に作成済みの Okta Privileged Access 管理者、ユーザそれぞれのグループに対応する OPA Administrators、OPA Users をアサインします。

   

3. プロビジョニング設定

   【Okta Admin Console での操作】
   アプリ統合の Provisioning タブを開き、Settings > Integration 画面の Configure API integration ボタンを押下します。
   Enable API integration チェックを入れ、Authenticate with Okta Privileged Access ボタンを押下します。
   Import Groups のチェックはデフォルトのオンとします。

   【Okta Privileged Access アプリケーションでの操作】
   Okta Privileged Access アプリケーションの画面が開きチームを問われるので、1 で設定した Team Name の値 myfirstteam を入力して、→ボタンを押下します。

   

   Okta Privileged Access アプリケーションへの SSO 認証画面に遷移します。
   認証完了後、サービスユーザの作成画面が開きますので、Username を設定し、Approve ボタンを押下します。
   Username は任意ですが、ここでは、opaserviceuser とします。

   

   【Okta Admin Console での操作】
   Okta Admin Console に戻り、Save ボタンを押下します。
   サイドメニューから To App を開き、Create Users、Update User Attributes、Deactivate Users それぞれの Enable にチェックを入れ、Save ボタンを押下します。

   

   サイドメニュー To Okta については特に設定項目はないため、以上でプロビジョニング設定は完了です。

4. グループプッシュとロールの設定

   グループプッシュにより Okta org グループと Okta Privileged Access のグループを連携し、Okta Privileged Access 上でグループにロールを付与して権限を割り当てていきます。

   ■グループプッシュの設定

   【Okta Admin Console での操作】
   アプリ統合の Push Groups タブを開きます。Push Groups > Find groups by name を押下し、管理者のグループ OPA Administrators を選択し、他はデフォルトの設定値のまま Save & Add another ボタンを押下します。 

   

   この操作により、Okta Privileged Access 上に Okta org と同名のグループが作成され、同期されます。
   同様に、ユーザのグループ OPA Users についても設定を行います。
   設定後、下図のように、各グループの Push Status が Active になっていることを確認してください。

   

   ■ロールの設定

   【Okta Privileged Access アプリケーションでの操作】 管理者の Okta Dashboard から Okta Privileged Access アプリケーションを開きます。サイドメニューから DIRECTORY > Groups を開きます。 これまでの設定により、Okta org からグループが同期されていることが確認できます。

   

   次に画面の OPA Administrators を押下し、グループに対してロールを付与します。ここでは管理者に全権限を一任するため、PAM Administrator、Resource Administrator、Security Administrator すべてをチェックし、Update Roles ボタンを押下します。

   

   以上の操作により管理者に新たな権限が付与され、Okta Privileged Access アプリケーションの画面をリロードすると、サイドメニューに RESOURCE ADMINISTRATION と SECURITY ADMINISTRATION が追加されます。 これにより、以降のリソースとポリシーの管理が可能となります。

5. リソースの設定

   アクセス対象となるリソースの設定・登録を行います。

   ■リソースグループの作成

   サイドメニューから RESOURCE ADMINISTRATION > Resource Management を開き、まずリソースグループを作成します。
   Create Resource Group ボタンを押下し、Resource Group Name の値を適宜入力し、また、Delegated Resource Admins のグループ（複数可）を設定します。
   ここでは、前者のリソースグループ名として resourcegroup1 を、後者については OPA Administrators を設定し、Save ボタンを押下します。

   

   ※前述の通り、本記事では管理者グループを OPA Administrators のみとしており、すでに Resource Administrator ロールを付与しています。
   しかし、リソースグループごとに Delegated Resource Administrator の設定が別途必須となるため、同グループに本ロールを設定しています。
   なお、以降のリソースグループの管理画面では Delegated Security Administrators の設定も可能ですが、こちらは必須ではないため本記事では設定しません。

   ■プロジェクトの作成

   【Okta Privileged Access アプリケーションでの操作】
   作成したリソースグループ resourcegroup1 の設定画面が開くので、Create Project ボタンを押下してプロジェクトを作成します。Project Name を入力して Save ボタンを押下します。本例では、project1 とします。

   

   ■プロジェクトの設定

   【Okta Privileged Access アプリケーションでの操作】
   作成したプロジェクト project1 の設定画面（Settings タブ）が開きます。各設定項目の説明を画像中に記載しました。
   本ユースケースでは、ローカルアカウントやチェックアウト機能を利用しない基本的な接続パターンを想定しています。
   そのため、サーバ登録に必要な Enrollment Tokens のみを設定し、他の項目はすべてデフォルト値のままとします。

   

   ■サーバ登録用トークンの作成

   【Okta Privileged Access アプリケーションでの操作】
   上記画面の Enrollment Tokens で View を押下し、Create Enrollment Token ボタンを押下します。
   ポップアップで Description の入力を求められるので、適切な説明を入力し Save を押下します。本例では、project1_token としています。

   

   以下のようにトークンが生成されるので、次に示すサーバの登録時に使用します。

   

   ■サーバの登録

   AWS Systems Manager のセッションマネージャーなどを使用して EC2 インスタンスに接続し、Okta Privileged Access サーバエージェントをインストールしサーバを登録します。

   【EC2 インスタンスでの操作】
   RPM キーを追加します。

   $ sudo rpm --import https://dist.scaleft.com/GPG-KEY-OktaPAM-2023

   下記内容でファイル /etc/yum.repos.d/oktapam-stable.repo を作成します。

   [oktapam-stable]
name=Okta PAM Stable - amazonlinux 2023
baseurl=https://dist.scaleft.com/repos/rpm/stable/amazonlinux/2023/$basearch
gpgcheck=1
repo_gpgcheck=1
enabled=1
gpgkey=https://dist.scaleft.com/GPG-KEY-OktaPAM-2023

   パッケージ情報をアップデートし、必要パッケージをインストールします。

   $ sudo dnf update
   $ sudo dnf install scaleft-server-tools

   以上の操作が完了すると、サーバエージェントのデーモン sftd が自動的に起動します。
   Okta Privileged Access のサーバエージェントの設定はカスタマイズ可能ですが、本ユースケースではデフォルトのままとします。

   サーバエージェントの詳細設定については、下記公式ドキュメントをご参照ください。

   • Configure the Okta Privileged Access server agent | Okta

   また、Amazon Linux 2023 以外のプラットフォームを含めた Okta Privileged Access サーバエージェントのインストール方法の詳細については下記公式ドキュメントを参照してください。

   • Install the Okta Privileged Access server agent | Okta

   次に、ファイル /var/lib/sftd/enrollment.token を作成し、前項で作成したサーバ登録用のトークンの文字列をコピーして保存します。デーモンの再起動は特に不要です。

   【Okta Privileged Access アプリケーションでの操作】
   サーバの登録が完了すると、プロジェクトの Servers タブに登録したサーバの情報が表示されます。
   ※ネットワークなどの状況によっては表示までに遅延が生じることがあります。

   

   また、サーバ名を押下するとサーバの詳細情報を確認することができます。

   

   以上でリソースの設定は完了です。

6. ポリシーとルールの設定

   ■ポリシーの作成

   【Okta Privileged Access アプリケーションでの操作】
   サイドメニューから SECURITY ADMINISTRATION > Policies を開き Create Policy ボタンを押下して、ポリシー作成画面を表示して以下の通り設定を行います。

   Policy information の Name を入力しポリシー名を決めます。本例では、Policy for resourcegroup1 とします。
   Resource group information では、ポリシーを割り当てるポリシーグループを選択するため Specify a resource group を選択し、下部の Select a resource group で作成済みの resourcegroup1 を指定します。
   Add principals で Add Principals ボタンを押下し、プリンシパルとしてリソースにアクセスするユーザのグループである OPA Users を選択して Save ボタンを押下します。

   

    一旦ここで画面上部の Save Policy を押下し、ポリシーの作成を完了します。

   次にポリシーにルールを追加していきます。

   ■ルールの作成

   【Okta Privileged Access アプリケーションでの操作】
   作成したポリシー Policy for resourcegroup1 の画面右上のボタンメニューから Actions > Edit を押下します。
   ポリシーが再度編集可能になるので、画面下部の Add rule to policy のボタンメニューから Add Rule > Server Rule を押下します。

   ルールの編集画面が開くので、上部から順に設定していきます。

   まず、基本情報として Rule name と Session type を設定します。本例では、それぞれ Rule #1 と Server SSH session とします。

    

   次に、アクセス対象とするサーバとアクセス方法（アカウント）を設定します。

   Select servers by label を有効化し、Add resources でラベルを指定します。
   ラベルはプロジェクトに登録したサーバの情報から自動的に生成される、サーバに関する情報の断片です。ホスト名や OS バージョンなどが抽出されて登録されます。本例では全てのラベルを選択しています。
   本ユースケースでは登録済みのサーバが一台のためラベルの有効性が分かりにくいですが、複数のサーバに一括してルールを適用したいときに威力を発揮します。

   本ユースケースでは個人アカウントでのサーバアクセスを想定しているため、Access method の access resources by individual account にチェックを入れます。
   また、サーバ上のユーザ権限は、User-level permissions を選択し、一般ユーザとしてアクセスします。なお、この設定を変更することで、管理者権限でのアクセスも可能です。
   今回はローカルアカウントでのアクセスは行わないため、その他の項目はデフォルト値とします。

   

   続いて残りの項目を設定します。
   今回は Multifactor authentication 以外の設定項目はデフォルト値のままとします。

   本ユースケースではログイン時の MFA 要求を有効化するため、Enable MFA を有効にします。
   Authenticator assurance level requirement は Any two factor types を、Reauthentication frequency は Every SSH or RDP connection attempt を選択します。
   以上により、サーバへの接続試行ごとに二要素認証が要求される設定となります。

    

   以上の操作が完了したら画面上部に戻り、Save Rule を押下します。
   ポリシーの編集画面に戻るので、Save Policy を押下します。さらに画面上部の Publish Policy のスイッチを有効化します。

    

   以上でポリシーとルールの設定は完了です。

   ポリシーとルール設定の詳細については、下記公式ドキュメントを参照してください。

   • Security policy | Okta

ユーザ利用方法

SSH サーバへのアクセスは、1) ユーザ端末へのクライアントソフトウェアのインストールと登録、2) サーバへの接続の流れで行います。全てユーザ端末側の操作となります。

1. ユーザ端末へのクライアントソフトウェアのインストールと登録

   ■Okta Privileged Access クライアントのインストール

   【端末での操作】
   Okta Privileged Access のリポジトリキーを追加します。

   $ curl -fsSL https://dist.scaleft.com/GPG-KEY-OktaPAM-2023 | gpg --dearmor | sudo tee /usr/share/keyrings/oktapam-2023-archive-keyring.gpg > /dev/null

   パッケージリストの項目を作成します。

   $ echo "deb [signed-by=/usr/share/keyrings/oktapam-2023-archive-keyring.gpg] https://dist.scaleft.com/repos/deb jammy okta" | sudo tee /etc/apt/sources.list.d/oktapam-stable.list

   パッケージ情報を更新し、必要パッケージをインストールします。

   $ sudo apt-get update
   $ sudo apt-cache search scaleft
   $ sudo apt-get install scaleft-client-tools scaleft-url-handler

   Ubuntu 以外のプラットフォームを含むクライアントのインストール方法の詳細については、以下の公式ドキュメントを参照してください。

   • Install the Okta Privileged Access client | Okta

   以上の操作により、Okta Privileged Access クライアントのインストールが完了し、端末で sft コマンドが使用可能になります。
   次の「ユーザ端末の Okta Privileged Access プラットフォームへの登録」と「2. サーバへの接続」で、実際に sft コマンドの一部の機能を用いて、Okta Privileged Access プラットフォームへのアクセスとサーバへの接続を行います。

   Okta Privileged Access クライアント sft のコマンドラインリファレンスについては、以下のドキュメントを参照してください。

   • Use the Okta Privileged Access client | Okta

   （トラブルシューティング）
   【端末での操作】
   sft コマンドを実行して端末登録、プラットフォームへのログイン、またはサーバへの接続を行う際、認証のためにブラウザが開くことがあります。本ユースケースで想定している WSL2 上の Ubuntu 環境で、"failed to open default browser: exec: "xdg-open": executable file not found in $PATH" のエラーでブラウザが正常に開かない場合は、以下のようにパッケージ xdg-utils を追加インストールしてください。

   $ apt-get install xdg-utils

   ■ユーザ端末の Okta Privileged Access プラットフォームへの登録

   【端末での操作】
   下記コマンドを実行し、ユーザ端末を Okta Privileged Access のチーム myfirstteam に登録します。
   hoge はご利用の Okta org のドメインに置き換えてください。

   $ sft enroll --url https://hoge.pam.okta.com --team myfirstteam

   【ブラウザでの操作】
   ここで Waiting on browser… のメッセージが表示されWeb ブラウザが開きます。Okta Privileged Access アプリケーションへの認証が求められるので、ユーザの Okta org のアカウントでログインします。認証が完了すると、Okta Plivileged Access アプリケーションのクライアント設定画面が開くので、Client Name を適宜設定して Approve ボタンを押下します。

   

   端末の登録が完了すると、サーバと同様にサイドメニュー DIRECTORY > Clients に端末情報が表示されます。

   

   クライアント名を押下すると端末の詳細情報を表示することが可能です。

   

   以上でユーザ端末の設定は完了です。

2. サーバへの接続

   sft コマンドを用いた端末からの接続例を下図に示します。

   

   ①端末上で sft list-servers コマンドを実行し、ユーザが利用可能なサーバのホスト名を表示します。

   ※この時点でクライアントの認証が切れている場合、ブラウザが開き Okta Privileged Access アプリケーションへのログインが要求されます。

   ②sft ssh コマンドでホスト名を指定して接続を試みます。すると、管理者が作成したポリシー Policy for resourcegroup1 のルール Rule #1 で設定したアクセス条件（個人アカウントと MFA）が番号付きでリストアップされます。

   ③アクセス方法1を入力して Enter キーを押すと、サーバへの接続が開始されます。本例では MFA を有効化しているため、ブラウザが開き追加認証が求められます。認証が完了すると、ログインセッションが開始します。

   ④id コマンドでユーザ情報を確認してみます。自動的にサーバ上で利用者の個人ユーザがプロビジョニングされていることが確認できます。

   ※サーバ上のユーザ名は、Okta 上のユーザ名（本例では opa-user@test.local）に基づき自動的に作成されますが、Okta Universal Directory から特定のユーザ名にカスタマイズすることも可能です。
   ホームディレクトリ等も自動的に作成されます。

   簡単なデモとなりましたが、サーバ接続例は以上となります。 

参考ドキュメント

記事中で紹介したものも含まれますが、記事作成にあたり参考としたドキュメントのポインタを改めて以下に紹介します。

Okta Privileged Access 製品情報

• Okta Privileged Access | Okta
• Okta Privileged Accessの紹介 | Okta

Okta Docs・ナレッジベース

• Okta Privileged Access | Okta
• Okta Privileged Access Frequently Asked Questions

まとめ

本記事では、Okta Privileged Access の概要から基本的な SSH 接続のユースケースまで一気に紹介しました。
今回は基本編ということで、まだまだ説明しきれていない機能が多くありますが、Okta Privileged Access の名前を聞いたことはあっても具体的な機能や利用方法を知らなかった方や、これから実際に構築を始めようと考えている方にとってのたたき台としてご参考になれば幸いです。

Okta についてのお問い合わせ

Okta Privileged Access の導入に関心をお持ちの方、本記事では紹介できていない、詳細なライセンス体系や価格などをお知りになりたい方は、ぜひ弊社窓口までお問い合わせください。

• お問い合わせ | ネクストモード株式会社

弊社サービス「Okta ライセンス＆サポート」では、Okta をはじめとする各種 SaaS、AWS に精通したプロフェッショナルが、お客様の Okta 導入・運用を密にサポートいたします。

• Oktaライセンス＆サポート | ネクストモード株式会社