使用の開始

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：Governance	セキュリティ管理者	接続をレビューして、［Draft（ドラフト）］から［Active（アクティブ）］へ昇格させます。「ワークロード接続を管理する」を参照してください。 アクティブ化されると、DevOps管理者はワークロード接続への書き込みアクセス権を失います。
フェーズ3：ロジック	セキュリティ管理者	ワークロードロールを作成し、ロールの適格者を決定する属性ベースの条件を定義します。「ワークロードロールを構成する」を参照してください。 ポリシーを作成または更新し、新しいワークロードロールをプリンシパルとして選択します。「セキュリティポリシーを作成または更新する」を参照してください。
フェーズ4：デプロイ	DevOps管理者	sft wl authをワークロードのCI/CDパイプラインに挿入します。 自動化されたワークロードは、アクティブなワークロード接続名を参照して、拡張されたOkta Privileged Accessクライアントコマンドを実行します。アクセスイベントはOkta System Logに記録されます。