こんにちは！たつみんです。
本日はOktaのIdentity Governance & Administration（以降：IGA）として新しく登場したOkta Identity Governance（以降：OIG）について検証をしたのでそのご紹介です。
はじめに
一般的にIGAが担う役割は以下のようなものです。
- 権限のプロビジョニング
- ライフサイクル管理
- アクセス権の要求と承認
- ポリシーやロールの管理
- 棚卸
- 職務分掌（SoD:Separation of Duties）
- 分析やレポーティング
IGAについては以前、私と同じIDチームの五戸が公開した以下のブログ記事もご参照ください。
現時点ではOIGではアクセス権の要求と承認（以降：Access Requests）,棚卸（以降：Access Certifications）,レポーティング（以降：Governance Reports）が対応しています。それぞれについてブログ記事にします。今回はAccess Requestsについての記事です。
Access Requestsの概要
Access Requestsはユーザー自身がOktaに登録済みのSaaSやOktaグループについて利用申請を行い、上長やIT管理者などのあらかじめて定義された承認者が承認を行うことができる機能です。申請時には理由やいつまで利用するかなどを記入することができるため、一時的なアクセス権の付与にも活用ができます。
以下のOkta公式ドキュメントもご参照ください。
事前準備
Access Requestsの設定を行う前に、まず検証のためにOktaに以下のユーザーやグループ、アプリケーションを作成しました。
ユーザー
requester_test@example.com- アクセス要求を行う人
- 上長としてmanagerIdにapprover_test@example.comを指定
approver_test@example.com- requester_test@example.comの上長として承認を行う人
itadmin_test@example.com- IT管理者として承認を行う人
グループ
OIG Access Requester Group- 作成するAccess Requestsを利用できるユーザーを管理するためのグループ
- メンバーにrequester_test@example.comを指定
- Okta Access RequestsのPush GroupsであらかじめOktaからグループの同期を実施
アプリケーション
OIG Access Requests Test App- 検証用としてブックマークアプリを作成
- URLにはhttps://blog.cloudnative.co.jp/を指定
Access Requestsの設定
チームの確認
今回はデフォルトチームに対してitadmin_test@example.comを追加し、承認フローの中で最終承認者として指定できるようにします。
- デフォルトでは以下のようにITチームが作成されています。
- ITチームを開き、Add memberをクリックし、
itadmin_test@example.comを追加します。
- ITの隣の…をクリックし、Editをクリックします。
- Auto-assignが有効になっており、Assignment styleがRotate through team membersとなっています。
この状態はITチームメンバが複数名いる場合に自動的にアサインがローテーションされます。
- 今回は検証のためにTo a specific userを選択し、
itadmin_test@example.comを指定し、Save teamをクリックします。
こうすることでアサインが固定されるようになります。
リソースの定義
申請の中でユーザーに項目を選択をさせたり、承認後の処理を行う際に利用する項目を事前にリスト形式のリソースとして定義することができます。定義できるリソースにはアプリケーションとグループがあります。
以下の例ではアプリケーションリソースを作成する方法をご紹介します。
- SettingsからResourcesタブへ移動します。アプリケーション一覧で必要な項目が表示されていることを確認します。もし表示されていない場合はUpdate nowをクリックします。
- Configuration listsタブに移動し、Create new listをクリックします。
- List Nameを入力し、TeamsでITを選択します。List typeはResource listを選択し、Resource typeでApplicationsを選択します。
- Add itemをクリックし、アプリケーションの検索を行い選択します。
ここでは作成済みの検証用アプリケーションOIG Access Requests Test Appのみを選択しましたが、もちろん複数のアプリケーションを選択しリストを作成することができます。
- 反映されたらCreate listをクリックします。
申請フローの設定
- Access RequestsのCreate request typeをクリックします。
- NameとDescriptionを入力し、Team（申請を管理するチーム）にはITを指定します。 Audience（申請を行えるユーザー）にはOkta Groupを選択し、Push GroupsでOktaから同期したグループ
OIG Access Requester Groupを指定します。
- この時点ではMark as done automatically?はOnにできませんが、このままConituneをクリックします。
- 以下のように承認フローのどのようなステップを追加するかの選択肢が表示されます。最初は申請理由を入力してもらいたいのでQuestionのAdd to request typeをクリックします。
- 画面の右側に追加されたステップの詳細を設定する領域が表示されます。Textにはユーザーへの質問となる文章を入力します。 Typeは質問に対する答えを入力するための型を指定します。今回はTextを選択します。Assigned toはこのステップを対応する人物としてRequesterを指定します。
- 画面下のApprovalをクリックしステップを追加します。以下のようにDetailsのTextには上長承認とし、Assigned toでRequester’s managerを指定します。
- 同様にApprovalステップを追加し、DetailsのTextにはIT管理者承認とし、Assigned toではA member ofからITを指定し、Edit logicをクリックします。
- LogicタブでAlways show this taskから、Only show this task ifに変更します。
- Field or taskで上長承認を選択し、is approvedを選択します。
- 画面下のActionをクリックし、Assign individual app to userをクリックします。
- DetailsのTextを入力し、Run automaticallyをOnにします。Email addressはRequester emailとし、Select the applicationをA resourceを選択後に事前定義したリソースである
OIG Access Requests Test Appを指定し、Edit logicをクリックします。
- Logicタブで以下のように上長承認とIT管理者承認が両方ともis approvedとなるように設定し、Publishをクリックします。
- Publish後にタイトルにある鉛筆マークをクリックし、以下の画面でMark as done automatically?をOnにします。
- 最後にUpdateをクリックします。
申請から承認までの確認
申請者の操作
requester_test@example.comのアカウントでOktaにアクセスします。- OktaダッシュボードにあるOkta Access Requestsをクリックします。
- 以下のようにApp Catalogとして作成したAccess Requestsが表示されているのでRequest accessをクリックします。
- 申請理由を入力し、Submit new requestをクリックします。
- 以下のように申請した内容がチャット画面のように表示されます。
承認者操作
上長承認
- 上長アカウント
approver_test@example.comでOkta Access Requestsを開くと以下のように申請を確認できます。
- 画面右側のTasksから上長承認部分をクリックし、承認する場合はApproveを、拒否する場合はDenyをクリックします。
- Approveすると以下のように次の承認者にタスクが移ったことが表示されます。
IT管理者承認
- IT管理者アカウント
itadmin_test@example.comでOkta Access RequestsTasksから承認作業を行います。
- すべての承認が完了すると自動的にアプリケーションへのアサインがされます。
承認完了後の確認
- 申請者のOktaダッシュボードをリロードするとアプリケーションが割り当てされていることが確認できます。
- クリックすることでブックマークアプリとして機能し、https://blog.cloudnative.co.jp/が表示されました。
チャットツールを利用した申請から承認まで
Access RequestsはSlackもしくはTeamsと連携することで申請から承認までの作業をすべてチャットツールの中で完結することができます。ここではSlackとの連携について記載します。
事前準備
- SettingsからIntegrationsタブを開き、SlackのConnectをクリックします。
- Add to Slackをクリックします。
- 連携するワークスペースを確認し、許可するをクリックします。
申請者の操作
スラッシュコマンドを利用する方法とSlackアプリとのチャット形式による方法の2通りありますが、ここではSlackアプリとのチャット形式による申請方法についてご紹介します。
- SlackアプリのOktaを開き、[アプリケーション名]を利用したいのようにチャットします。
- すぐにリアクションがあり、該当する申請フローを提案してきます。間違いがなければContinueをクリックします。もし、別の申請フローを確認したい場合はI need something elseをクリックします。
- Continueをクリックした場合は申請理由を記入するモーダルが表示されるため、入力後にSubmitをクリックします。
承認者操作
上長承認
- 上長のSlackにもSlackアプリから承認依頼が通知されます。
- Questionsをクリックすることで申請理由が確認できます。
- Approve or denyをクリックし、承認もしくは拒否を選択します。
- Approveを行うとモーダルの表示が変わり次のステップに移ったことがわかります。
IT管理者承認
- 上長承認と同様にSlackアプリから承認依頼が通知されます。
- スレッド表示となっているので確認すると上長承認がされたことが確認できます。
- Approve or denyをクリックし、承認もしくは拒否を選択します。
- Approveを行うとモーダルの表示が変わります。
- 自動的にアプリケーションへのアサインがされたことがスレッド内にも記載されます。
一時的なアクセス権の付与
期限を設定し、アクセス権を付与したい場合は以下のどちらかの方法で対応します。
- 申請者にいつまで利用するか記入させる方法
- あらかじめ日数などを設定しアクセス権付与から起算して自動的に期限を設定をする方法
設定方法
これまでに作成したAccess Requestsに対して次の処理を追加します。
- Questionをクリックし、Textを設定し、TypeはDateを選択します。
- アプリへのアサインのステップを選択し、Details内のAdd a time limitをクリックします。
- Timer typeをEnd on dateとし、How long should this user have access?を追加したQuestionを指定し、Continueをクリックします。
- 自動的にWait untilとRevokeのステップが追加されたことを確認し、Updateをクリックします。
これにより、Wait untilで申請者が回答した期限まで待ち、その後にRevokeでアプリケーションからのアサインを外す処理を自動的に行います。
申請者に期限を設定させるのでなく承認完了後1日だけ権限を付与するような場合は1.のQuestionの追加は行わずに、以下のように3.でEnd after durationを選択することで1日、1時間、1分のように指定することができます。
最後に
このブログ記事の例のようにAccess Requestsではアプリケーションに対して申請を行い、承認を経てアクセス権を付与できるため、アプリケーションがProvisioningに対応している場合はかなりの省力化ができるのではないかと思います。
また、アプリケーションへのアサインではなくグループへのアサインという観点ではAssignmentsやPush Groupsで利用しているグループなどに対して活用すれば権限管理やライセンス管理にも応用できます。
期限を設けることもできるため、例えば以下のようなOkta管理者権限が紐づいたグループに対する申請を作成することで1時間だけ権限付与を行うなどのAzure ADのPIMのような利用もできます。
Access Requestsは今後も進化をする予定があるそうなのでもっとできることが増えていくのではないかと思います。個人的にはSlackで完結できる世界観も非常にいいなと思います。
それでは次回はAccess CertificationsとGovernance Reportsについての記事でお会いしましょう！
