【Okta】Okta Privileged Access で実現する SaaS 特権アカウント管理

はじめに

こんにちは、ネクストモード株式会社 テクニカルサポート担当です。

今回は、Okta Privileged Access ライセンスで実現できる SaaS の特権アカウント管理についてご紹介します。特に Google Workspace や Slack などの特権アカウントが SSO 対象外となるようなケースで利用ごとのパスワード変更や同時利用を制御するなどセキュアな認証情報の管理を行えます。

この記事でわかること

• Okta Privileged Access を使った SaaS 特権アカウント(Google Workspace、Slack など)の管理方法
• 利用申請から承認、パスワード自動ローテーションまでの具体的な設定手順
• Checkout 機能による特権アカウントの同時利用制御とセキュリティ強化の実現方法

Okta Privileged Access の概要

Okta Privileged Access は、SSH サーバー、RDP サーバー、シークレット、Kubernetes クラスタ、クラウドインフラなど、組織の重要なリソースに対する特権アクセス管理を実現します。主な特徴は以下の通りです。

• ポリシーベースのアクセス制御
• Okta MFA との連携によるセキュリティ強化
• 監査ログとセッション記録による透明性の高い運用

SSH サーバーについては、ゆきなわさんが以下のブログ記事で詳しく解説していますので、ぜひご参照ください。

現在では、SSH サーバーや RDP サーバーに加えて、Okta 上のサービスアカウントや SaaS 特権アカウントにも対応しています。

Okta Privileged Access で実現できる体験

以下は、Okta Privileged Access で管理された SaaS 特権アカウントを Okta Identity Governance(以下、OIG)の Access Request と組み合わせて利用する場合のユーザー体験です。利用申請から承認、一定期間の利用までの流れを説明します。

1. ユーザーが Google Workspace の特権アカウント利用を申請する

「Privileged Access」 > 「SaaS Apps」へ移動し、「Google Workspace」から特権アカウントの「Request credentials」をクリックします。

2. 承認者が Access Request を確認し、承認する

3. ユーザーが利用を開始する

「Show credentials」をクリックすると、特権アカウントの認証情報が表示されます。

今回は検証のため、わかりやすく最大15分間のみ利用できる設定にしています。

4. 利用期間が経過する、またはユーザーが利用を終了する

最大利用期間が経過するか、その前にユーザーが「Check in」ボタンから利用を終了することができます。

設定方法

ここでは Google Workspace 上に存在する特権アカウントを活用するシナリオで設定を進めます。

設定の流れ

1. 特権アカウントの登録
2. Okta Privileged Access アプリへの割り当て
3. Okta Privileged Access ユーザーグループの作成と権限設定
4. Okta Privileged Access リソース管理(Resource Group と Project の作成)
5. プロジェクトに特権アカウントを紐づける
6. ポリシー作成
7. ルール作成

特権アカウントの登録

Okta Admin Console から「Directory」 > 「Service accounts」に移動し、「Create account」をクリックします。

「Application instance」から「Google Workspace」を選択します。

必要な情報を入力し、「Create」をクリックします。

Okta Privileged Access アプリへの割り当て

Okta Admin Console から「Applications」 > 「Applications」に移動します。

Okta Privileged Access アプリに設定作業者と利用を想定するユーザーを割り当てます。

Okta Privileged Access ユーザーグループの作成と権限設定

Okta ダッシュボードから「Okta Privileged Access」にアクセスします。

「Okta Privileged Access」内の「Directory」 > 「Groups」へ移動し、「Create Group」をクリックします。

「Group Name」 を入力し、「Team Roles」 を選択します。ここでは検証のため、PAM Administrator / Resource Administrator / Security Administrator のすべての権限を付与しますが、本番環境では権限を分離することを検討しましょう。

グループ作成後、「Users」タブからユーザーを追加します。

Okta Privileged Access リソース管理

ここでは、リソースを管理するためのグループと、それに紐づくプロジェクトを作成します。

「Resource Administration」 > 「Resource Management」から「Create Resource Group」をクリックします。

「Resource Group Name」 を入力します。使用できる文字は英数字、ハイフン(-)、アンダースコア(_)、ピリオド(.)のみです。スペースは使用できないため注意が必要です。

「Delegated Resource Admins」 では、作成済みの Okta Privileged Access ユーザーグループを指定します。

プロジェクト作成

「Create Project」をクリックし、「Project Name」を入力します。ここでも使用できる文字は Resource Group Name と同じ条件です。

プロジェクトの詳細設定画面が表示されます。

「Resource Type」 を 「SaaS App Service Accounts」 を選択し、「Settings」 タブをクリックします。

「Checkout」 で 「Enable Checkout for」 を 「All account that support checkout」 を選択し、 「Select the maximum checkout time」 は今回の検証では15分となるように設定し、 「Save」 をクリックします。

プロジェクトに特権アカウントを紐づける

「Resource Administration」 > 「Resource assignment」 へ移動すると 「Okta Universal Directory」 の 「Unassigned accounts」 として 特権アカウントの登録 で作成した Google Workspace アカウントが表示されています。

「Assign account 」 をクリックし、 「Resource group」 および  「Project」 を指定し、 「Assign」 をクリックします。

「Resource Administration」 > 「Resource Management」から作成した Resource Group と Resource Project を選択します。

次に「Resource Type」で「SaaS App Service Accounts」を選択します。すると、先ほど紐づけた Google Workspace アカウントが表示されていることが確認できます。

ポリシー作成

「Security Administration」 > 「Policies」 へ移動し 「Create Policy」 をクリックし、 「Default」 をクリックします。

「Policy Name」 を入力します。「Resource group information」 では全てのリソースグループを指定することもできますが、今回の検証では 「Specify a resource group」 を選択し、明示的にリソースグループを選択しました。

「Add principals」 では Okta Privileged Access ユーザーグループを選択します。

ルール作成

ポリシーにはルールが必要なため、「Add rule」をクリックし、「SaaS App Service Account Rule」をクリックします。

「Rule name」 を入力します。

「Password update method」は「Automated」を選択します。

「Approval requests」では OIG の Access Request を呼び出すことができます。ここではあらかじめ作成しておいた「Access Request」を選択します。Access Request での設定は別途ブログ記事を作成予定です。

「Multifactor authentication」では特権アカウント利用時に MFA を求める設定を行えます。

「Maximum Checkout time」では特権アカウントの最大利用時間を指定することができます。この設定は Resource Management の Project で設定した値を上書きしてしまうので注意が必要です。

「Save Rule」と「Save Policy」の順番にクリックし、最後に「Publish Policy」をクリックします。

これで設定はすべて完了しました。

Checkoutについて

今回の設定では「Checkout」を有効化しているため、あるユーザーが特権アカウントを利用中は他のユーザーはその特権アカウントを利用することができません。この時に他ユーザーが利用しようとしても以下のようにステータスが「CHECKED OUT BY SOMEONE ELSE」と表示されています。

一方で利用中のユーザーではステータスが「CHECKED OUT」と表示され、「Check in」ボタンが表示されています。

「Check in」ボタンをクリックすると以下のダイアログが表示されます。「Check in」後にパスワードが自動でローテーションされる旨が記載されています。

まとめ

本記事では、Okta Privileged Access を使った SaaS 特権アカウント管理の設定手順と利用方法を解説しました。設定箇所が多く全体像の把握に時間がかかりましたが、以下のようなメリットにより、セキュリティリスクを抑えながら効率的なアクセス管理を実現できます。

Okta Privileged Access の主なメリット

• 特権アカウントの一元管理により、アカウントの可視化と管理が容易になる
• パスワードの自動ローテーションで、手動管理の負担を軽減し、セキュリティを強化できる
• 承認ワークフローにより、アクセスの透明性と統制を確保できる
• Checkout 機能により特権アカウントの同時利用を防ぎ、利用状況の可視化や SaaS 側のログを明確化できる
• Check in 時の自動パスワードローテーションで、アカウントのセキュリティをさらに強化できる

これらの機能を適切に活用することで、組織のセキュリティ強化と運用効率化に大いに役立つと感じました。この記事が特権アカウントの管理でお困りの方や、Okta Privileged Access の導入を検討されている方の参考になれば幸いです。