Okta Privileged Accessに関するよくある質問

Oct 14, 2024

Okta Classic Engine

Privileged Access

Okta Identity Engine

内容

この記事では、Okta Privileged Access（OPA）に関するよくある質問への回答を説明します。

Okta Privileged Accessとは何ですか？
Okta Privileged Accessの価格に関する詳細情報はどこで確認できますか？
Okta Privileged Accessはどのような認定を受けていますか？
Okta Privileged AccessはFedRampの承認を受けていますか？
Okta Privileged AccessとAdvanced Server Access（ASA）の違いは何ですか？
Okta Privileged Accessはカスタムドメインをサポートしていますか？
Okta Privileged Accessではどのようなロールを使用できますか？
Okta Privileged Accessは世界中で利用できますか？

一般

Okta Privileged Accessとは何ですか？

Okta Privileged Accessは、Oktaの新しい特権アクセス管理（PAM）製品です。すべての特権リソースへのアクセスを管理する統合アプローチを提供し、ユーザーエクスペリエンスを損なうことなく、可視性、コンプライアンス、セキュリティの向上を実現します。

Okta Privileged Accessは、インフラストラクチャへのアクセス、特権アクセスのガバナンス、資格情報の保管、およびコンプライアンスのレポートを含む重要なPAM機能を、コアのWorkforce IDおよびアクセス管理ソリューションに組み込むことで、組織のリスクを低減させます。

Okta Privileged Accessの価格に関する詳細情報はどこで確認できますか？

Okta Privileged Accessの価格については、アカウントチームにお問い合わせください。

Okta Privileged Accessはどのような認定を受けていますか？

Oktaでは、この新製品のコンプライアンス認証を積極的に取得しようとしています。まずはSoc 2タイプ1を取得し、将来的にはほかの認証も取得する予定です。Okta Privileged Accessは、Soc 2タイプ1、Soc 2、Soc 3、ISO 27001+、CSA STARレベル2を取得したOktaのAdvanced Server Accessを基盤とし、進化させた製品です。これらには今後、順次対応していく予定です。

Okta Privileged AccessはFedRampの承認を受けていますか？

現時点ではまだです。このプロセスはFY25後半に開始される予定です。

Okta Privileged AccessとAdvanced Server Access（ASA）の違いは何ですか？

Advanced Server Accessは、サーバーインフラストラクチャへのゼロトラスト、最小特権アクセスというPAMの重要なユースケースを解決します。
Okta Privileged Accessは、ASAの機能を拡張および深化させて、以下のような多くの新機能を含む、包括的な特権アクセス管理ソリューションを実現します。

ゼロトラスト、最新のインフラストラクチャへの最小特権アクセス。
高度な特権を持つ共有ローカルアカウントの検出、ローテーション、保管、監視。
セキュリティ要件とコンプライアンス規制を満たす制御とガバナンスのレイヤーを備えたシークレットvault。
Okta Identity Governanceの機能を活用した、特権リソースのアクセスリクエスト承認フロー。
PAMリソースの条件付きアクセスポリシーとトランザクション型MFA保護。
AWSリソースのクラウドインフラストラクチャ資格の検出と分析（CIEM）。
DevOpsワークフローとの簡単な統合。

Okta Privileged Accessはカスタムドメインをサポートしていますか？

お客様はカスタムドメインを使用してOkta orgにログインできます。これらのOkta orgにリンクされているPAMチームは、*.pam.okta.comドメインでホストされます。

Okta Privileged Accessではどのようなロールを使用できますか？

Okta Privileged Accessには、お客様が最小権限のベストプラクティスを適用できるよう支援するロールが多数用意されています。さまざまな管理者ロールが使用可能で、たとえば、リソースを管理するロールと特権リソースへのアクセスを構成するロールを分離することができます。また、リソースの委任管理もサポートされています。これは特定のリソース（Linux管理用の管理者グループなど）の管理に使用できます。管理者以外は管理ビューを表示できず、アクセス権が付与されている特権リソースのみが表示されるよう制限されます。詳細はこちらを参照してください。

Okta Privileged Accessは世界中で利用できますか？

Okta Advanced Server Accessとは異なり、Okta Privileged Accessは対応するOkta orgにバインドされます。購入すると、Okta orgと同じOktaセルにプロビジョニングされます。

Okta Privileged Accessは現在、北米とEMEAのFedRamp以外のすべてのプレビューセルと本番セルで利用できます。

現在、次のセルでは利用できません。

OP2 - EMEAのプレビューセル。
OK8 - APACの本番セル（シドニー/シンガポール）。FY25第4四半期に提供開始予定。
OK16 - 日本の本番セル（東京/大阪）。

ポリシーエンジン

Okta Privileged Accessの条件付きアクセスの仕組みを教えてください

Okta Privileged Accessは堅牢なポリシーエンジンを備えており、管理者はアクセスリクエスト、承認フロー、トランザクション型MFAなど、さまざまな条件付きアクセスポリシーをセットアップできます。この幅広い機能をさまざまな方法で活用することで、組織は動的なポリシーを作成し、組織固有のアクセスガバナンスのニーズに対応できます。

インフラストラクチャのアクセス

Okta Privileged Accessはどのオペレーティングシステムに対応していますか？

対応しているオペレーティングシステムについては、こちらを参照してください。

個別アカウントとは何ですか？また、サーバー上でどのような権限を持ちますか？

Okta Privileged Accessは、各Oktaユーザーのアクセス許可されているすべてのLinux/Windowsサーバー上の個別プリンシパルアカウントを管理することで、OktaユーザーがSSHまたはRDPでサーバーにアクセスする権限を取得できるようにします。これは、JITベースで個別アカウントを作成/削除するか、永続的なローカルアカウントを作成することで自動的に行われます。詳細については、こちらを参照してください。

Okta Privileged Accessセキュリティ管理者は、サーバー上のこれらの個別アカウントに対する権限を次のように構成できます。

ユーザーレベルの権限、
sudoレベルの権限（Linuxシステムの場合）、または
管理者レベルの権限

特権昇格を利用すると、Oktaユーザーがタスクを完了するために必要な昇格権限のみを適切なサーバー上で持つようにすることで、最小特権のサーバーアクセスモデルを適用できます。

Okta Privileged AccessはSSHキーを管理しますか？

Okta Privileged AccessのSSHセッション確立アプローチでは、お客様によるSSHキーの管理は一切不要です。代わりに、Okta Privileged Accessは、認証用に短時間のみ有効なSSH証明書を使用します。

Okta Privileged Accessでは新しいvault機能も導入されており、特権アクセスのユースケースに合わせてシークレットを保存および管理したり、シークレットにアクセスしたりできます。この機能は当初、管理対象サーバーからの共有アカウントの管理を対象としていました。製品の一般提供リリースでは、これがOkta Privileged Accessに接続されていないシステムのシークレット管理にまで拡張される予定です。

Okta Privileged Accessのゲートウェイの目的は何ですか？

ゲートウェイは次のような複数のニーズに対応できる透過的なプロキシコンポーネントです。

サーバーエージェントをクライアントに公開させないためのネットワークルーティング
短時間のみ有効なクライアント認証証明書をゲートウェイ暗号化キーで暗号化し、クライアントが認証証明書に直接アクセスできないようにすることで、資格情報のセキュリティを向上させる
SSH/RDPセッションの記録の有効化
将来リソースの種類を増やす際にゲートウェイコンポーネントが必要になる

Okta Advanced Server Accessとは異なり、Okta Privileged AccessはBastion（踏み台）をサポートしません。Bastion（踏み台）と同等のネットワークプロキシ/ルーティングを実装するには、ゲートウェイを使用します。

Okta Privileged Accessはセッションの記録を行いますか？

Okta Privileged Accessでは、ゲートウェイ（この機能の要件）を利用して、SSH/RDPセッションをゲートウェイにローカルに記録します。

改ざんができないように記録されたセッションはゲートウェイに保存され、NASストレージにマウントしたり、AWS S3バケットに転送したりして、後で確認することができます。セッションは、SSHの場合はasciinema、RDPの場合はMKVファイルで記録されます。セッション終了後、最終的なセッションログは、ゲートウェイにローカルに保存するか、Amazon Web Services（AWS）S3やGoogle Cloud Storage（GCS）などのリモートプラットフォームにアップロードできます。「セッションキャプチャのオプション」をご覧ください。

Okta Privileged Accessは、管理対象サーバーにおけるローカルアカウントの帯域外のパスワード変更を検出しますか？

Okta Privileged Accessの管理対象となったアカウントは、ポリシーエンジンによって管理され、改ざんができないロギングによって追跡されます。Okta Privileged AccessのイベントはOktaにログ記録されるため、帯域外のパスワード変更もログ記録され、パスワードがローテーションされます。そして、そのイベントをSIEMやチケットソリューションで利用することで、誰が、何を、いつ、どこでパスワード変更したかを調査するためのアクションを立てることができます。

Okta Privileged Accessではsudoルールをどのように管理しますか？

Okta Advanced Server Accessと同様に、Okta Privileged AccessではLinuxサーバーのsudoルールを一元的に管理できます。ただし、実装は少し異なります。

まず、sudoルールは、メニューシステムとは別の項目である、［RESOURCE ADMINISTRATION（リソース管理）］配下の［Sudo commands（sudoコマンド）］で管理されます。つまり、システム全体のリソース管理者ロールの管理対象となります。これらは「コマンドバンドル」と呼ばれ、名前と説明、およびコマンドで構成されます。

sudoコマンドバンドルは、ポリシーを介してユーザーとサーバーに適用されます。サーバーに割り当てられると、個々のアクセスに関連付けられます。コマンドバンドルは異なるポリシー間で再利用し、さまざまなサーバーに適用できます。

ポリシーがポリシー内の各ユーザーに適用され、そのユーザーがポリシー内のサーバーに接続すると、ユーザーはサーバー上でジャストインタイムで作成されるため、関連するsudoers.dルールが作成されます。/etc/sudoers.d/ディレクトリのこのルールは、ユーザーの個人グループに関連付けられます。ファイル名はsudoコマンドバンドル名、ユーザー名、および一意の識別子で構成されます。

たとえば、larry.linuxadminがサーバーに接続した場合、larryの個人グループへのコマンドエイリアスのマッピングを含むsudoers.dファイルが作成されます（例： %larry_linuxadmin ALL= NOPASSWD: ...）。ユーザーがセッションから切断されると、このファイルは削除されます。

詳細については、「sudoコマンドバンドル」を参照してください。また、「Centrally Managing SUDO Rules with Okta Privileged Access」のiamse.blog記事でもこれについて詳しく説明しています。

内容

目次