ワークロード
Okta Privileged Accessは、サービスアカウントやCI/CDランナーなどの非人間アイデンティティ（NHI）を人間のユーザーと同じ厳格さで管理する、統合されたIDセキュリティアーキテクチャを提供します。サービスユーザーと静的APIキーに代わる手段を提供することで、Okta Privileged Accessワークロード認証は、Organizationがプラットフォーム署名されたフェデレーションID（JWT/OIDC）を使用してシークレットゼロリスクなしで信頼を証明できるようにします。この一元化されたポリシーレイヤーにより、マシンが使用するシークレットからIDが切り離されます。これにより、静的資格資格情報の保管から、サーバー、データベース、エフェメラルシークレットへのジャストインタイムアクセスの提供にシームレスに移行できます。
シークレットゼロスプロールのリスクを排除するために、Okta Okta Privileged Accessはワークロード認証を静的APIキーから暗号技術証明に移行します。CircleCI、GitLab、GitHub Actions、Google Cloud Platform（GCP）などの信頼できるプロバイダーとのワークロード接続を確立することで、Okta Privileged Accessはランタイム時に署名済みJSON Web Token（JWT）を検証します。ワークロードは、環境で提供された署名済みトークンを使用してIDを証明し、静的資格情報をディスクに保存することなく、自動化されたリクエストを認証します。
主な機能とコンセプト
| 機能/コンポーネント | 説明 |
|---|---|
| ワークロード |
自動化されたジョブまたはマシンエンティティ。特権リソースへのアクセスをリクエストするAnsibleコントローラーやCI/CDランナーなど。 |
|
ワークロードIDドキュメント |
ワークロードが自身のIDを証明するために提示するIDドキュメント。このドキュメントは、GitHub、GitLab、GCPなどの信頼できるサードパーティプロバイダーが署名したJSON Web Token（JWT）です。 |
|
ワークロードID |
サーバー、コンテナ、仮想マシン、CI/CDパイプラインなどのシステムが、組織内の自動化されたタスクを認証し、認可を受けるためのデジタルアイデンティティ。 |
|
ワークロード認証 |
ワークロードが、静的APIキーの代わりにワークロードIDドキュメントを使用して、そのIDを証明するプロセス。 |
|
Okta Privileged Accessトークン |
Okta Privileged Accessは、認証が成功した後、改ざん防止が施された安全なトークンをワークロードに発行します。ワークロードはこのアクセストークンを使用して、Okta Privileged Accessにより保護されたリソースにアクセスします。 |
|
ワークロード接続 |
一元化された構成では、外部のワークロードプロバイダーとの信頼関係を定義します。DevOps管理者が［Draft（ドラフト）］ステータスの接続を作成します。トークンの発行者を有効にするには、セキュリティ管理者がそれらを［Active（アクティブ）］に昇格させる必要があります。 ［Draft（ドラフト）］ステータスのワークロード接続では、JWT検証テストを行うことができますが、リソースアクセス向けの機能アクセストークンは発行されません。また、任意のワークロードロールに一致させることもできないため、テスト中にワークロードが誤ってアクセスを獲得することを防ぎます。 |
|
ワークロードロール |
Okta Privileged Accessポリシーでプリンシパルとして機能する重要な認可エンティティ。これらのロールは、作業負荷属性を論理セキュリティグループにマッピングすることで、ポリシー管理を簡略化します。 |
|
ワークロードプリンシパルのポリシーバインディング |
セキュリティ管理者は、ワークロードロールをプリンシパルとして使用してリソースを保護するポリシーを定義します。ポリシーの適用は、プラットフォーム統合からの詳細な属性情報に依存します。 |
|
クライアントツールの拡張 |
Okta Privileged AccessクライアントCLIが自律型で非インタラクティブな使用をサポートするようになり、人間のプロンプトが不要になりました。 |
|
プリンシパルSSHアクセス |
ワークロードロールから自動的に取得されたシステム管理対象のUnix/Linuxユーザー名（プレフィックス wl_）を使用して、ワークロードがサーバーに直接サインインするようにします。このメカニズムはマシンのIDを確認し、短時間のみ有効なSSH証明書を動的に発行するため、安全なゼロスタンディング権限のマシンツーマシン接続が可能になります。「自動化されたワークロード向けのプリンシパルSSHアクセス」を参照してください。 |
自動アクセスのワークロードプロセス
自動化されたワークロード保護のためのOkta Okta Privileged Accessワークフローは、管理者によるセットアップと自動実行の2つのフェーズに分かれます。この分離により、人間の管理者は厳格な監視とガバナンスを維持し、マシンIDがランタイム時に自律的に動作します。
管理セットアップ
管理フェーズでは、信頼の確立と、自動化のためのセキュリティ境界の定義に重点が置かれます。このプロセスでは、DevOpsチームとセキュリティチームの強力が必要です。
DevOps管理者はドラフトワークロード接続を作成し、外部プロバイダーのJWKS URLと検証クレームを定義します。管理者は、ドラフト接続に対してCLIコマンドを準備してテストし、構文とJWT検証を確認します。セキュリティ管理者が接続を有効にすると、接続はドラフトからアクティブに変わり、DevOps管理者は更新アクセスを失います。その後、接続は有効なOkta Privileged Accessトークンを発行します。セキュリティ管理者は、属性一致ブロックを含むワークロードロールを定義し、それをポリシーにバインドして、リソースおよびシークレットアクセスルールを設定します。
自動化された実行
このフェーズでは、ワークロードが特権リソースへのアクセスを必要とするたびに発生するリアルタイムのプロセスについて詳しく説明します。セットアップ後、ワークロードがアクセスをリクエストするたびに、自動実行フェーズが実行されます。
実行時に、ワークロードはJWTを提示し、ワークロード接続を参照して認証を行います。システムがJWTの検証に成功すると、短時間のみ有効なアクセストークンを発行して、ワークロードのセッションIDを確立します。ワークロードはアクセストークンを使って保護されたリソースをリクエストし、そのロールを指定します。ポリシーエンジンはトークンを検証し、ロールの要件を確認します。承認された場合、最小権限のアクセスを強制し、イベントをログに記録します。その後、ワークロードは資格情報を使って接続し、タスクを完了します。