ワークロード

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

シークレットスプロールのリスクを排除するために、Okta Privileged Accessは次の3つの認証アプローチを提供しています。

クラウドでホストされるワークロード：認証を静的APIキーから暗号技術証明に移行します。CircleCI、GitLab、GitHub Actions、Google Cloud Platform（GCP）などの信頼できるプロバイダーとのワークロード接続を確立することで、Okta Privileged Accessはランタイム時に署名済みJSON WebToken（JWT）を検証します。ワークロードは、静的資格情報をディスクに保存することなく、環境で提供された署名済みトークンを使用してアイデンティティを証明します。
Amazon Web Services（AWS）資格情報を使用するワークロード：Okta Privileged Access AWS IAM接続により、ワークロードはIAMロールなどの資格情報の背後にあるAWS IAMアイデンティティを使用して、自分のアイデンティティを証明できます。ワークロードをAWSで実行する必要はありませんが、有効なAWS資格情報が必要です。ワークロードは、AWS Security Token Service（STS）GetCallerIdentityリクエストにAWS資格情報を署名し、Okta Privileged AccessはAWS STSを使用してリクエストを検証します。ワークロードは、JWTまたはAPIキーを保管する必要はありません。
非クラウドまたはオンプレミスのワークロード：Okta Privileged Access APIキー接続により、セキュリティ管理者が制御する組み込みのローテーションおよび取り消し機能を備えた、管理された短時間のみ有効なシークレットを使用して安全な認証が可能になります。

主な機能とコンセプト

機能/コンポーネント	説明
ワークロード	自動化されたジョブまたはマシンエンティティ。特権リソースへのアクセスをリクエストするAnsibleコントローラーやCI/CDランナーなど。
ワークロードIDドキュメント	ワークロードが自身のIDを証明するために提示するIDドキュメント。JWT接続の場合、これはGitHub、GitLab、GCPなどの信頼できるサードパーティプロバイダーが署名したJSON Web Token（JWT）です。AWS IAM接続の場合、これはAWS STS `GetCallerIdentity`リクエストで、ワークロードはAWS資格情報で署名します。APIキー接続の場合、これはOktaによって管理されている、暗号的に署名されたAPIキーです。
ワークロードID	サーバー、コンテナ、仮想マシン、CI/CDパイプラインなどのシステムが、組織内の自動化されたタスクを認証し、認可を受けるためのデジタルアイデンティティ。
ワークロード認証	ワークロードがワークロードIDドキュメントを使用して、そのIDを証明するプロセス。
Okta Privileged Accessトークン	Okta Privileged Accessは、認証が成功した後、改ざん防止が施された安全なトークンをワークロードに発行します。ワークロードはこのアクセストークンを使用して、Okta Privileged Accessにより保護されたリソースにアクセスします。
ワークロード接続	中央構成では、外部ワークロードプロバイダ（JWT接続の場合）、AWSアカウントおよびオプションでAWSアイデンティティ（AWS IAM接続の場合）との信頼関係を定義するか、または管理対象APIキー認証をセットアップします（APIキー接続の場合）。JWT接続およびAWS IAM接続の場合、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トークンを発行します。セキュリティ管理者は、属性一致ブロックを含むワークロードロールを定義し、それをポリシーにバインドして、リソースおよびシークレットアクセスルールを設定します。

AWS IAM接続の場合（For AWS IAM connections）：セットアップは、JWT接続と同じ職務分掌プロセスに従います。DevOps管理者は、AWSアカウントを定義するドラフトのワークロード接続と、オプションでそのワークロードで使用する必要があるAWSアイデンティティを作成します。セキュリティ管理者は、接続をアクティブ化し、ワークロードロールを定義して、ポリシーにバインドします。

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

自動化された実行

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

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

AWS IAM接続の場合（For AWS IAM connections）：実行時に、ワークロードはAWS Security Token Service（STS）GetCallerIdentityリクエストにAWS資格情報を署名し、そのワークロード接続を参照します。Okta Privileged Accessは、署名済みリクエストをAWS STSに送信し、AWSから返されるAWSアカウントとアイデンティティをワークロード接続と比較します。一致すると、システムは短時間のみ有効なアクセストークンを発行します。このワークロードはこのトークンを使用して、保護されたリソースをリクエストし、そのロールを指定します。ポリシーエンジンはトークンを検証し、ロールの要件を確認します。承認されるとアクセス権が付与され、イベントがログに記録されます。

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

トピック

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

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