Oktaでスーパー管理者を削減する7つの方法

このブログはこちらの英語ブログ（2024年9月2日公開）の参考和訳です。

Oktaはこの数か月間で、Okta管理者のゼロスタンディング特権を実現する取り組みで大きな進歩を遂げました。

このブログのシリーズ第1回で説明したように、ゼロスタンディング特権は「最小権限アクセス」の概念を大幅に前進させるものです。Oktaでは、非インタラクティブなユーザーアカウント（人間が直接操作するアカウント）が、高い特権を持つ管理者ロールや許可に継続的かつ永続的にアクセスできないようにし、必要に応じて必要な権限をジャストインタイムで期限付きで付与する運用モデルを提供することを目指しています。

この権限付与のモデルにより、組織の攻撃対象領域が大幅に縮小します。攻撃者が万が一ユーザーやサービスアカウントに不正にアクセスした場合でも、その権限を悪用する能力は大幅に限定されます。

現在、多くの管理アカウントの許可は惰性で存在している傾向があります。ある時点では特定のタスクを実行するために必要であったロールを、継続的にアカウントが必要とする適切な許可レベルのロールに戻すための仕組み（ガバナンス）が存在しなかったのです。 

すでにブログで解説したように、ゼロスタンディング特権を実現するための最初のステップは、組織が高い特権付きのロールのユースケースを特定することです。一部のユースケース（緊急用アカウントなど）では、スタンディング権限が必要となります。また、ユーザーが管理タスクを頻繁に実行するときに、毎回許可を要求するのは現実的ではない場合もあります。

しかし、（a）許可が攻撃者にとって重要な標的となる、（b）許可が必要とされる機会がほとんど、または間欠的にしか使用されない、という条件が揃う場合、Govern Okta Admin RolesというOktaの機能で、ジャストインタイム（JIT）で一定期限のみ利用できるカスタム管理者ロールを使用する理想的なケースとなります（備考：Govern Okta Admin Rolesは、Okta Workforce Identityのすべてのお客様が利用できる新機能です。お使いのコンソールでこの機能が見つからない場合は、アカウント担当者にお問い合わせください。）

最初のステップとして、Oktaはこのようないくつかのタスクや「実行すべきジョブ」に対して特定の許可を作成し、特定のロールに割り当てることができるようにしました。

特定の許可を使用してカスタム管理者ロールを作成することで、高い特権へのスタンディングアクセスを持つアカウント数を大幅に削減できます。

次のステップとして、Oktaのガバナンス機能を使用し、使用頻度が低く高い特権を持つ許可がアクセスリクエストフローを経由するように制限します。これらの機能を使用する場合、管理ユーザーは、特権付きの許可を必要とするタスクを実行するために、二重の認可プロセスを経て要求が承認される必要があります。承認されると、ユーザーは一定期間のみ特権付きの許可を使用でき、その後アカウントは元の役割に戻ります。

このブログでは、このプロセスの最初のステップである、Oktaで最も高い特権付きのロールであるスーパー管理者ロールの使用を減らすため、許可を特定する方法について説明します。

1 - アイデンティティプロバイダーを変更するためのJIT許可 

サードパーティのアイデンティティプロバイダーを作成または変更する機能は、「高い特権を持ち、間欠的にしか実行されない管理タスク」の条件に完全に一致します。最近までは、このタスクにはスーパー管理者またはOrg管理者のロールを持つアカウントが必要でした。 

したがって、このタスクは、Okta管理者ロールを制御するユースケースとして理想的な候補です。ダウンストリームアプリケーションで信頼関係を悪用してユーザーになりすます攻撃への対策として、この許可を制限することは特に効果的です。

この場合、アイデンティティプロバイダーを管理する許可（okta.identityProviders.manage）をスコープとし、JITベースで利用でき、承認ワークフローの対象となり、数時間で有効期限切れになるカスタム管理者ロールを作成することをお勧めします。

さらに、保護されたアクションを有効にして、アイデンティティプロバイダーのライフサイクルイベント（アイデンティティプロバイダーの追加や変更）が最初にステップアップ認証のチャレンジをトリガーするように設定することをお勧めします。

2 - AD/LDAPエージェントを変更するためのJIT許可

Okta orgを最初に設定した後には、管理者は新しいディレクトリエージェントを頻繁に作成または変更する必要はなくなります。ADエージェントまたはLDAPエージェントの自動更新を有効にしている場合、Okta Admin Consoleまたは管理APIを使用してエージェントを保守する必要は限られます。

これまでエージェントを作成または変更するには、スーパー管理者ロールを持つアカウントが必要でした。

スーパー管理者の使用を避けるには、次の方法を取り入れます。

• エージェント管理の許可（okta.agents.manage）をスコープとするカスタム管理者ロールを作成します。
• このロールをJITベースで提供し、承認ワークフローに従い、数時間後に有効期限が切れるアクセスリクエストフローを作成します。
• このアクセスを要求および承認する信頼できる管理者のグループを割り当てます。

重要：Active Directoryを引き続き使用する場合は、AD Agentのバージョン3.18にアップグレードするだけで、スーパー管理者ロールを使用するサービスアカウントの数を（少なくとも1つ）減らすことができます。バージョン3.18以降のAD Agentは、OAuth 2.0 DPoP（Demonstrated Proof of Possession）を使用してOktaと通信するようになり、特定の管理ユーザーアカウントに紐付けられることがなくなりました。

3 - ワークフローを変更するためのJIT許可

Oktaのノーコード自動化ツールであるOkta Workflowsは、管理者がコードを書かずにアイデンティティ関連の操作を自動化できる強力なアプリケーションであり、一度使ってみるとその便利さを手放せなくなるはずです。管理ユーザーがOkta Workflowsで自動化できるタスクは広範に及ぶことから、ワークフローを作成および変更するには、これまではスーパー管理者ロールが必要でした。

しかし、この操作でスーパー管理者ロールが不要になりました。

Okta Workflowsのロールベースのアクセス制御（現在早期アクセス中）では、Okta Workflowsアプリ専用の3つのロールを選択できます。

• Okta Workflows管理者はOkta Admin Consoleで割り当てられ、Okta Workflowsで管理機能を実行できます。このロールは、Govern Okta Admin RolesというOktaの機能を使用して要求できます。
• Workflows Connection Managerは、Okta Workflowsで割り当てられる許可であり、接続を作成または変更する能力を付与します。これは、接続を認可するために必要なすべてのサービスアカウントで役立ちます。
• Workflows Auditorは、Okta Workflowsで割り当てられる許可であり、Okta Workflowsのすべてを表示する「読み取り専用」（変更は不可）の許可を付与します。

話のついでですが、Okta Workflowsアプリの認証ポリシーは、少なくともOkta Admin Consoleへのアクセスに必要なポリシーと同程度に強力である必要があります。

Okta Workflowsに対する最小権限のアプローチを以下に示します。

• プレビューorgまたはテストorgでOkta Workflowsを作成してテストします。
• 本番環境向けのフローの準備ができたら、.flowまたは.folderファイルとしてエクスポートします。
• 本番orgでGovern Okta Admin Rolesを使用して、Okta Workflows管理者ロールへのJITアクセスを要求します。 
• .flowまたは.folderファイルをインポートして、必要な接続を構成します。
• 本番用のOkta Workflowsアプリに、フローに必要なOAuthスコープのみが付与されていることを確認します。

4 - アクセス要求を管理するためのカスタム管理者ロール

Okta Identity Governanceは、アプリケーションにアクセスするためのユーザーからの要求の管理や、そのアクセスに対するガバナンスレイヤーとしてユーザーアクセスレビュー（アクセス認定）の定期的な実行などの複雑なタスクを軽減するためのシンプルで便利なツールを提供します。

セキュリティの観点からは、アクセスリクエストフローを作成し、その条件を変更する能力は高い特権を必要とします。Okta orgでは、この操作を実行できる以下の2つのロールをすぐに選択できます。

• スーパー管理者ロールを持つユーザー、または
• アクセス要求管理者ロールおよびフローがアクセスするアプリケーションのアプリケーション管理者ロールを持つユーザー

2番目のオプションでカスタム管理者ロールを作成すると、スーパー管理者の過剰な許可を付与することなく、アクセス要求を作成および変更するために必要なすべてが提供されます。 

これに対する例外の1つは、ダウンストリームアプリケーションのユーザーロールではなく、アクセス要求を使用してOkta管理者ロールへのアクセスを管理している場合です。ここからは、やや自己参照的な状況になります。つまり、管理者としてのユーザーが、管理許可を持つロールへのアクセスを要求できる条件を設定できる場合、特権を直接付与できる管理者と実質的に同じレベルの特権を持つことになります。したがって、Okta管理者ロールのアクセス要求を作成および変更するユーザー自身がスーパー管理者でなければなりません。

5 - Okta Workflowsを読み取りまたは呼び出す許可の委任

さらなる朗報として、Okta Workflowsを単に呼び出し（実行）するときに、スーパー管理者の許可やWorkflows RBACの許可も不要になりました。 

より低い許可を持つ管理者は、委任フローと呼ばれる機能を使用してフローを呼び出し（実行）できます。サービスデスクの担当者はこの機能を使用して、Okta Workflowsアプリに直接アクセスすることなく、Okta Admin Consoleへの制限されたアクセスを使用して特定のフローを開始できます。サービスデスクの担当者は、割り当てられたフローを変更することも、表示することもできませんが、設定された制限内でフローとやり取りできます。サービスデスクのケース以外にも、委任フローを応用できるユースケースはいくつもあります。

6 - APIサービス統合の使用

スーパー管理者ロールの使用を避ける別の方法は、特にセキュリティのユースケースでAPIサービス統合を採用することです。

APIサービス統合を使用すると、アクセスを付与するときに、ユーザーが作成した高い特権付きのサービスアカウントのロールが不要になります。APIサービス統合は、OAuth 2.0クライアントの認証情報フローを使用して、アプリケーションのコンテキストでOkta APIにアクセスします。 

これにより、セキュリティが強化される理由がいくつかあります。各アクセストークンにより、トークン所持者は、ロールの下で使用可能なアクションの代わりに、特定のOktaエンドポイントで特定のアクションを実行できるようになります。

通常、セキュリティベンダーがどのように最小特権に取り組んでいるかは、APIサービス統合が利用可能かどうかで判断できます。Sysdig、Datadog、Kandji、Palo Alto、Elastic、Wizなど、この優れた取り組みを早期に実現したベンダーに、大きな敬意を表したいと思います。 

7 - 特権付きユーザーを読み取るための許可の委任

Oktaの最小権限アクセスへの取り組みでは、他のOkta管理者に関する情報を表示または変更するには、スーパー管理者の許可を持つアカウントが必要となります。 

そのため、Oktaの標準の読み取り専用管理者ロールでは、一般的なユーザーアカウントに関する情報を表示できますが、管理許可があるアカウントに関する情報（割り当てられたロール、リソース、許可など）は表示できません。

前述したように、サードパーティのセキュリティプロバイダーは、アプリケーションのコンテキストで許可を設定し、サービスアカウントを必要としないOAuthを利用したAPIサービス統合を使用する必要があります。APIサービス統合は、このブログで概説しているように、APIトークンが窃取された場合の影響範囲を縮小するための多くの利点をもたらします。

しかし、ほかのサードパーティのセキュリティツール（セキュリティ態勢管理や「ITDR」アプリなど）がOktaのお客様に対して、スーパー管理者ロールが割り当てられたサービスアカウントを作成し、このアカウントを使用して静的なAPIトークンを作成し、継続的にアクセスするためにトークンをサードパーティに渡すように要求するのを見かけたことがあるのではないでしょうか。このような統合のパターンでは、多くの場合、アカウントに過剰な特権が付与されることになります。こうした方法を利用する必要性はまったくありません。

ベンダーがAPIサービス統合を構築しておらず、静的ベアラートークンを使用するように引き続き要求している場合は、アプリにカスタム管理者ロールを付与し、スーパー管理者ロールの使用を避けることができる可能性が高まります。たとえば、アイデンティティとアクセス管理の許可（okta.iam.read）を標準の読み取り専用管理者ロールに追加することを検討できます。IAM許可により、ロール、リソースセット、および管理者割り当てに読み取り専用でアクセスでき、攻撃対象領域を広げることがありません。

次のステップ 

これで、多くのタスクでスーパー管理者ロールが不要になったことがわかりました。 

ただし、管理許可を割り当てたり、管理者アカウントを変更したりするには、引き続きスーパー管理者が必要です。そのため、スーパー管理者ロールそのものが、信頼できる管理者グループ内で複数のユーザーがGovern Okta Admin Rolesを使用してアクセスを承認した後に、オンデマンドで利用できる有効期限付きロールの最有力候補になります。

次のタスクは、組織の管理者グループに付与するベースラインの許可について検討することです。管理グループが頻繁に実行するタスクは何か、毎回何らかの形でアクセスを要求しなければならないのは非現実的かを検討してください。標準ロール、カスタムロール、リソースを関連付けて、組織の構造とリスク選好レベルに最適なベースラインのロールを作成できることを常に念頭に置いてください。

アイデンティティガバナンスに関する次回のブログでは、Govern Okta Admin Rolesを使用したアクセス要求の作成について詳しく説明します。

以上の内容は、原文（英語）の参考和訳であり、原文と内容に差異がある場合は、原文が優先されます。