ワークロード

Okta Privileged Accessは、サービスアカウントやCI/CDランナーなどの非人間アイデンティティ（NHI）を人間のユーザーと同じ厳格さで管理する、統合されたIDセキュリティアーキテクチャを提供します。サービスユーザーと静的APIキーに代わる手段を提供することで、Okta Privileged Accessワークロード認証は、Orgがプラットフォーム署名されたフェデレーションID（JWT/OIDC）または安全なAPIキーを使用してシークレットゼロリスクなしで信頼を証明できるようにします。この一元化されたポリシーレイヤーにより、マシンが使用するシークレットからIDが切り離されます。これにより、静的資格資格情報の保管から、サーバー、データベース、エフェメラルシークレットへのジャストインタイムアクセスの提供にシームレスに移行できます。

シークレットスプロールのリスクを排除するために、Okta Privileged Accessは2つの認証アプローチを提供しています。*クラウド上でホストされるワークロードでは、認証が静的APIキーから暗号技術証明に移行されます。CircleCI、GitLab、GitHub Actions、Google Cloud Platform（GCP）などの信頼できるプロバイダーとのワークロード接続を確立することで、Okta Privileged Accessはランタイム時に署名済みJSON WebToken（JWT）を検証します。ワークロードは、環境から提供される署名済みトークンを使用して、静的な資格情報をディスクに保存することなくIDを証明します。*非クラウドまたはオンプレミスのワークロードでは、Okta Privileged Access APIキー接続により、セキュリティ管理者が制御する組み込みのローテーションおよび取り消し機能を備えた、管理された短期間のシークレットを使用して安全な認証が可能になります。

主な機能とコンセプト

機能/コンポーネント	説明
ワークロード	自動化されたジョブまたはマシンエンティティ。特権リソースへのアクセスをリクエストするAnsibleコントローラーやCI/CDランナーなど。
ワークロードIDドキュメント	ワークロードが自身のIDを証明するために提示するIDドキュメント。JWT接続の場合、これはGitHub、GitLab、GCPなどの信頼できるサードパーティプロバイダーが署名したJSON Web Token（JWT）です。APIキー接続の場合、これはOktaによって管理されている、暗号的に署名されたAPIキーです。
ワークロードID	サーバー、コンテナ、仮想マシン、CI/CDパイプラインなどのシステムが、組織内の自動化されたタスクを認証し、認可を受けるためのデジタルアイデンティティ。
ワークロード認証	ワークロードがワークロードIDドキュメントを使用して、そのIDを証明するプロセス。
Okta Privileged Accessトークン	Okta Privileged Accessは、認証が成功した後、改ざん防止が施された安全なトークンをワークロードに発行します。ワークロードはこのアクセストークンを使用して、Okta Privileged Accessにより保護されたリソースにアクセスします。
ワークロード接続	中央構成では、外部ワークロードプロバイダーとの信頼関係を定義するか（JWT接続の場合）、またはManagement APIキー認証をセットアップします（APIキー接続の場合）。JWT接続の場合、DevOps管理者がそれらの接続をドラフト（Draft）ステータスで作成します。トークンの発行者を有効にするには、セキュリティ管理者がそれらの接続をアクティブ（Active）に昇格させます。APIキー接続の場合、セキュリティ管理者が接続を作成および管理します。注: ドラフト（Draft）ステータスのJWTワークロード接続ではJWT検証テストは許可されますが、リソースアクセス向けの機能アクセストークンは発行されません。また、任意のワークロードロールに一致させることもできないため、テスト中の意図しないアクセスを防ぎます。APIキー接続は、ドラフトフェーズなしでセキュリティ管理者が排他的に管理します。
ワークロードロール	Okta Privileged Accessポリシーでプリンシパルとして機能する重要な認可エンティティ。これらのロールは、作業負荷属性を論理セキュリティグループにマッピングすることで、ポリシー管理を簡略化します。
ワークロードプリンシパルのポリシーバインディング	セキュリティ管理者は、ワークロードロールをプリンシパルとして使用してリソースを保護するポリシーを定義します。ポリシーの適用は、プラットフォーム統合からの詳細な属性情報に依存します。
クライアントツールの拡張	Okta Privileged AccessクライアントCLIが自律型で非インタラクティブな使用をサポートするようになり、人間のプロンプトが不要になりました。
プリンシパルSSHアクセス	ワークロードロールから自動的に取得されたシステム管理対象のUnix/Linuxユーザー名（プレフィックスが`wl_`）を使用して、ワークロードがサーバーに直接サインインするようにします。このメカニズムはマシンのIDを確認し、短時間のみ有効なSSH証明書を動的に発行するため、安全なゼロスタンディング権限のマシンツーマシン接続が可能になります。「自動化されたワークロード向けのプリンシパルSSHアクセス」を参照してください。

自動アクセスのワークロードプロセス

自動化されたワークロード保護のためのOkta Privileged Accessワークフローは、管理者によるセットアップと自動実行の2つのフェーズに分かれます。この分離により、人間の管理者は厳格な監視とガバナンスを維持し、マシンIDが実行時に自律的に動作することが保証されます。

管理セットアップ

管理フェーズでは、信頼の確立と、自動化のためのセキュリティ境界の定義に重点が置かれます。このプロセスでは、DevOpsチームとセキュリティチームの強力が必要です。

JWT接続の場合（For JWT connections）DevOps管理者はドラフトワークロード接続を作成し、外部プロバイダーのJWKS検証ソースと検証クレームを定義します。管理者は、ドラフト接続に対してCLIコマンドを準備してテストし、構文とJWT検証を確認します。セキュリティ管理者が接続を有効にすると、接続はドラフトからアクティブに変わり、DevOps管理者は更新アクセスを失います。その後、接続は有効なOkta Privileged Accessトークンを発行します。セキュリティ管理者は、属性一致ブロックを含むワークロードロールを定義し、それをポリシーにバインドして、リソースおよびシークレットアクセスルールを設定します。

APIキー接続の場合（For API key connections）：セキュリティ管理者が、アクティブなステータスでAPIキーワークロード接続を作成します（ドラフトフェーズは不要です）。管理者はAPIキーを生成し、安全な帯域外チャネルを通じてDevOpsチームに配信します。セキュリティ管理者は、属性一致ブロックを含むワークロードロールを定義し、それをポリシーにバインドして、リソースおよびシークレットアクセスルールを設定します。

自動化された実行

このフェーズでは、ワークロードが特権リソースへのアクセスを必要とするたびに発生するリアルタイムのプロセスについて詳しく説明します。セットアップ後、ワークロードがアクセスをリクエストするたびに、自動実行フェーズが実行されます。

JWT接続の場合（For JWT connections）実行時に、ワークロードはJWTを提示し、ワークロード接続を参照して認証を行います。システムがJWTの検証に成功すると、短時間のみ有効なアクセストークンを発行して、ワークロードのセッションIDを確立します。ワークロードはアクセストークンを使って保護されたリソースをリクエストし、そのロールを指定します。ポリシーエンジンはトークンを検証し、ロールの要件を確認します。承認された場合、最小権限のアクセスを強制し、イベントをログに記録します。その後、ワークロードは資格情報を使って接続し、タスクを完了します。

APIキー接続の場合（For API key connections）：実行時に、ワークロードはAPIキーを提示し、ワークロード接続を参照します。システムがAPIキーの検証に成功すると、短時間のみ有効なアクセストークンを発行します。このワークロードはこのトークンを使用して、保護されたリソースをリクエストし、そのロールを指定します。ポリシーエンジンはトークンを検証し、ロールの要件を確認します。承認されるとアクセス権が付与され、イベントがログに記録されます。

トピック

APIキーの生成、ローテーション、取り消し

自動化されたワークロード向けのプリンシパルSSHアクセス