はじめに

今回は、Oktaに追加された新機能「Okta Identity Governance(以下OIG)」の内、Access Requestについて、実際の利用イメージと合わせて解説します。

本記事から、認証以外の部分についてもOktaの柔軟性が伝わればと思います。

OIGとは

OIGとは、Oktaが今までカバーしてきたIAMとは別の、IGA(Identity Governance and Administration)の機能です。
IGAは、誰に対して、どのシステムの、どのレベルの権限を持たせるかを重視しています。

OIGは大きく3つの機能があります。

• Access Request：アプリケーション/グループの利用申請、承認(承認ワークフロー)
• Access Certification：アプリケーション/グループの棚卸
• Reporting：アプリケーションへのユーザーアサイン状況/棚卸結果に関するサポート

今回はAccess Requestに注目し、解説していきます。

実際の利用イメージ

◆権限に沿った承認フロー

各SaaSには様々な権限が存在するため、それぞれの権限に沿った承認フローを定義することがガバナンスの強化につながります。

ユーザーがSaaS A/Bのアカウントを利用する際に申請することを想定し、利用イメージをみていきましょう。

①SaaS Aの利用申請

1-1.一般アカウントの利用申請を行う場合

• ユーザーがSaaS Aの一般アカウントを申請
• 承認者：上長が妥当性をチェックし、承認
• ユーザーはSaaS Aを一般アカウントで利用可能

1-2.特権アカウントの利用申請を行う場合

• ユーザーがSaaS Aの特権アカウントを申請
• 承認者①：上長が申請の妥当性をチェックし、承認
• 承認者②：SaaS A管理者が申請内容をチェックし、承認（二段階承認)
• ユーザーはSaaS Aを特権アカウントで利用可能

②SaaS Bの利用申請の場合

2-1.一般アカウント/特権アカウントの利用申請を行う場合

• ユーザーAが一般アカウント/特権アカウントのどちらかを申請
• 承認者：SaaS B管理者が申請の妥当性をチェックし、承認
• ユーザーはSaaS Bを一般アカウント/特権アカウントで利用可能

※特権アカウントの承認フローについては、OktaからSaaSへの権限付与が可能な場合のみ利用可能

◆時限性アカウントの作成

Okta Access Requestは、単にアカウントを払い出すだけにとどまりません。

ユーザー自身に利用期限を決定させ、期限満了後にユーザーの権限を自動的に削除することもできます。

• ユーザーがAppの利用を申請
  申請内容：利用理由、必要な権限、利用期限など 　※項目は自由に設定可能
• 承認者が確認・承認後、ユーザーはOkta上のアプリケーション/グループに追加され、利用可能
• 期限をOktaが自動でチェックし、アプリケーション/グループからユーザーを除外、アクセス権限がなくなる

おわりに

今回は、Okta Access Requestの概要について解説しました。
次回は、Access Requestの構築手順をご紹介しますのでお楽しみに！

Oktaでは、OIG機能に関わらず多くの機能がありますので、ご興味がございましたら是非弊社までお問い合わせください。