使用の開始

Okta Privileged Accessを構成することで自動化されたワークロードを認証し、ワークロードが特権リソースに安全にアクセスできるようにします。

このプロセスには、次の2つの管理者ロールのコラボレーションが必要です。

DevOps管理者：マシンのID構成を作成、テストし、ソースシステムに精通しています。
セキュリティ管理者：アクセスを管理し、本番環境で使用するID構成を承認し、認可ポリシーを定義します。

フェーズ	ロール	アクション
フェーズ1：接続	DevOps管理者	ワークロード接続をドラフト（Draft）ステータスで作成します。ドラフト（Draft）モードでは、CLIによって検証の成功メッセージが返されますが、使用可能なトークンは発行されません。そのため、アクセスを付与せずにクレームロジックを検証できます。「ワークロード接続を構成する」を参照してください。自動化スクリプトで使用される非インタラクティブコマンド（`sft workload authenticate`）をテストします。これにより、CLI構文が検証され、ワークロードのJWTがドラフト接続に対する検証に合格することが確認されます。「ワークロード認証のCLIコマンド」を参照してください。注: ドラフト（Draft）状態で`sft workload authenticate`を実行した場合、アクティブ（Active）に切り替えてから改ざん防止Okta Privileged Accessトークンが発行されるまでに約5分かかります。システムによってワークロードの接続詳細が更新されるためです。
フェーズ2：ガバナンス	セキュリティ管理者	ドラフト（Draft）からアクティブ（Active）への接続をレビューし、昇格させます。「ワークロード接続を管理する」を参照してください。アクティブ化されると、DevOps管理者はワークロード接続への書き込みアクセス権を失います。
フェーズ3：ロジック	セキュリティ管理者	ワークロードロールを作成し、ロールの適格者を決定する属性ベースの条件を定義します。「ワークロードロールを構成する」を参照してください。ポリシーを作成または更新し、新しいワークロードロールをプリンシパルとして選択します。セキュリティポリシーを作成または更新するを参照してください。
フェーズ4：デプロイ	DevOps管理者	ワークロードのCI/CDパイプラインに`sft wl auth`を挿入します。自動化されたワークロードは、アクティブなワークロード接続名を参照して、拡張されたOkta Privileged Accessクライアントコマンドを実行します。アクセスイベントは、Okta System Logに記録されます。