今回の「はじめてのOkta Workflowsシリーズ」では、特定のアプリケーションを一定期間利用していないユーザーを抽出し、棚卸し対象として整理する方法をご紹介します。
以前ご紹介した「第３回 長期間利用されていないアカウントの洗い出し」では、「利用されていないOktaアカウント」をリスト化する方法を解説しました。対して今回は、「Oktaにはログインしているが、一部のアプリを全く使っていないアカウント」が対象です。その特定にとどまらず、Okta Identity Governanceによる棚卸しや、Slack連携といった様々なユースケースを合わせて自動化します。
このワークフローを活用することで、「使われていない個別アプリのライセンス削減」や「不要なアクセス権の整理」といった、よりピンポイントで実用的なコスト最適化・セキュリティ対策が可能になります。
※ その他の「はじめてのOkta Workflowsシリーズ」はこちらをご覧ください。
非アクティブなアプリケーション利用者を見つける理由
退職・異動・プロジェクト終了などにより、実際には使われていないアプリのアクセス権が残り続けることがあります。この状態は、主に以下のようなセキュリティリスクを大きくします。
不正利用の検知遅延: 普段利用されていないアカウントは、第三者による不正アクセスが発生しても本人が気づかないため、異変の発見が遅れ、被害が長期化・深刻化しやすくなります。
情報漏洩リスクの継続: 組織変更やプロジェクトから離れたメンバーが、本来閲覧権限のない機密情報や個人データにアクセスできる状態が維持され、不適切な情報持ち出しのリスクを高めます。
被害の連鎖: 特定のアプリケーションがセキュリティ侵害を受けた場合、それを契機に、連携する他の社内システムやデータ基盤へと不正アクセスが拡大する要因となります。
また、有償SaaSでは、利用していないユーザーにライセンスが割り当てられたままになっていることがあります。定期的に棚卸しすることで、ライセンスの回収や再割り当てにつなげられます。
しかし、管理者がアプリごとにユーザー一覧を開き、最終利用日を確認し、対象者をまとめる作業は手間がかかります。そこでOkta Workflowsを使い、この確認作業を自動化します。
今回ご紹介する方法は、Oktaが公式に提供しているOkta Workflowsテンプレート「非アクティブなサードパーティアプリ利用者の特定(Identify inactive third party app users)」を扱うことで、自らフローを構築することなく、すぐにご活用いただくことが可能です。
なお、このOkta Workflowsテンプレートは全て英語で書かれており、英語に慣れていない方にとって学習コストがかかります。そこで、このテンプレートを日本語化したテンプレートを作成しました。ダウンロードはこちらから可能です。
日本語版テンプレートをダウンロードしたら、こちらの手順を参考にOkta Workflowsにインポートしてください。
ただし、あくまでサンプルですので、動作の保証をするものではなく、フロー全体としての動作やロジックはサポート対象にはなりません。理解を進める上での参考としてご活用ください。
このテンプレートでできること
このテンプレートは、指定したアプリについて、一定期間サインインしていないユーザーをOktaのシステムログから特定し、レビュー用のOktaグループに追加します。すなわちこのグループは、アプリケーションの割り当てが不要な可能性の高いユーザー一覧ということになります。
その後、Okta Identity GovernanceのAccess Certificationsキャンペーンで、そのグループをレビュー対象に指定します。レビュー担当者は、ユーザーごとにアクセスを継続するか、失効するかを判断できます。
テンプレートのセットアップ
Okta Workflowsを実行するためには、テンプレートの状態から自身のOktaテナントに合わせたセットアップが必要です。セットアップが完了すると、以下の画像の赤枠で囲ったスイッチをオンにすることが可能になります。
以下に、各フローごとの事前セットアップが必要なカードを整理します。
フロー名 > カード名 | 手順 |
1.0 - 非アクティブユーザーの検出とレビュー | ここに、検出対象としたいアプリケーション名を入力してください。 サンプルフロー (日本語)では、例として以下のように入力してあります。
|
1.0 - 非アクティブユーザーの検出とレビュー | Choose Connectionを選択して自身のOktaテナントと接続してください。 
Oktaとのコネクション設定に必要なClient IDとClient Secretは、Okta管理コンソール > アプリケーション > Okta Workflows OAuthから取得することが可能です。 まず、Okta Workflows から Okta へのコネクション設定の手順です。   |
1.0 - 非アクティブユーザーの検出とレビュー | このカードがConnection successfulとなっていることを確認してください。 > Okta Search Applications」のコネクション設定と連動して、コネクション設定が完了済みになっているはずです。 
|
1.0 - 非アクティブユーザーの検出とレビュー | このカードがConnection successfulとなっていることを確認してください。
また、アプリケーションの指定が必要な箇所があります。ここでは、非アクティブな利用者を特定したいアプリを指定してください。 私の場合は、Okta Workflowsを指定しました。 
|
1.1.0 - 最終ログインの確認 | Choose Connectionをクリックしてください。 
これまでのOktaコネクション設定と連動して、設定済みのコネクション名「🟢Okta」が表示されます。 
「🟢Okta」をクリックすると、Connection successfulが表示されます。 
|
1.1.0 - 最終ログインの確認 | このカードがConnection successfulとなっていることを確認してください。 
|
2.0 - グループ割り当てユーザーの失効検出 > Okta Assign Certification Decision Submitted | Choose Connectionをクリックしてください。 
これまでのOktaコネクション設定と連動して、設定済みのコネクション名「🟢Okta」が表示されます。 
「🟢Okta」をクリックすると、Connection successfulが表示されます。 
|
2.0 - グループ割り当てユーザーの失効検出 > Flow Control Assign | 自社Okta orgのサブドメインと、環境種別を設定します。たとえばexample.oktapreview.comの場合、oktaOrgには”example”、Preview or Prodにokta.comか、oktapreview.comを入れます。 
|
2.0 - グループ割り当てユーザーの失効検出 > Slack Send Message to Channel | Slackとのコネクション設定を行います。 ※ Slackをお使いでない場合、Teamsなどの別のチャットツールと置き換えていただくことも可能です。 また、今回のブログでまず理解を優先する場合、このカードを削除した上で、動いたものとして読み進めていただければ幸いです。 
New ConnectionをクリックするとSlackコネクションポップアップが立ち上がります。 
「Create」をクリックすると、Slack OAuthの画面に遷移して、ご自身が利用中のSlackテナントと接続できます。 |
2.1.0 - ユーザーのグループ判定フロー > Okta List Groups Assigned to Application | Choose Connectionをクリックしてください。 
これまでのOktaコネクション設定と連動して、設定済みのコネクション名「🟢Okta」が表示されます。 
「🟢Okta」をクリックすると、Connection successfulが表示されます。 
また、アプリケーションの指定が必要な箇所があります。ここでは、非アクティブな利用者を特定したいアプリを指定してください。 私の場合は、Okta Workflowsを指定しました。 ※ 1.0 - 非アクティブユーザーの検出とレビュー > Flow Control Assignで指定したアプリケーション名(App Name:)と一致している必要があります。 
|
2.1.0 - ユーザーのグループ判定フロー > Okta Get Users Groups | このカードがConnection successfulとなっていることを確認してください。
 |
2.1.1 - グループ名の取得 > Read Group | Choose Connectionをクリックしてください。 
これまでのOktaコネクション設定と連動して、設定済みのコネクション名「🟢Okta」が表示されます。 「🟢Okta」をクリックすると、Connection successfulが表示されます。
|
コネクション設定が完了すると、全てのフローを有効化状態にすることができます。
ワークフロー全体の流れ
ここからは実際に、テンプレートの中身の詳細を解説します。
このテンプレートには、2つのメインフローと3つのヘルパーフローがあります。
種別 | フロー名 | 日本語訳 |
メインフロー | 1.0 - Discover and review inactive users. | 1.0 - 非アクティブユーザーの検出とレビュー |
ヘルパーフロー | 1.1.0 - Check Last Logged In | 1.1.0 - 最終ログインの確認 |
メインフロー | 2.0 - Detect Group-Assigned Revocation | 2.0 - グループ割り当てユーザーの失効検出 |
ヘルパーフロー | 2.1.0 - User Group Flow | 2.1.0 - ユーザーのグループ判定フロー |
ヘルパーフロー | 2.1.1 - Get Group Names | 2.1.1 - グループ名の取得 |
なお、以下の記事ではわかりやすさのためにフロー名を日本語訳で呼称します。
テスト方法
1.0 - 非アクティブユーザーの検出とレビューフローを手動実行して確認します。
Runボタンを押すと処理が開始します。
対象アプリに割り当てられていて、指定期間内のサインインがないユーザーがいれば、非アクティブユーザー用グループに追加されます。
その後、Okta管理コンソールから非アクティブユーザー用グループを対象に、Access Certificationsキャンペーンを開始することが可能です。
※ Access Certificationsキャンペーンは、アクセス権の棚卸しを行うためのOkta Identity Governanceの機能の一つです。本記事ではこの機能自体の紹介は割愛いたします。
これにより、非アクティブなユーザーを棚卸しして、権限を維持するのか剥奪するのか整理するための運用を仕組み化することができるようになりました。
これだけではありません。
アプリケーションに対する割り当てが、グループルールにより自動化されているなどの理由で、Access Certificationによって権限を剥奪したとしても適切に失効できない場合があります。そのような権限の剥奪漏れを防ぐために、グループに所属することでアクセス権を付与されていたユーザーがいた場合、追加判断のために通知を出すための仕組みとして、2.0 - グループ割り当てユーザーの失効検出がAccess Certificationをトリガーにして実行されるようになっています。
全体の流れを簡単に表すと、次のようになります。
管理者が、対象アプリ名、非アクティブユーザー用グループ名、何日前までを確認するかを設定します。
スケジュールに従ってOkta Workflowsが起動します。
対象アプリに割り当てられているユーザーを取得します。
ユーザーごとにSystem Logを検索し、指定期間内のアプリ認証イベントがあるかを確認します。
認証イベントが見つからないユーザーを非アクティブとみなします。
非アクティブユーザーをレビュー用グループに追加します。
そのグループをAccess Certificationsキャンペーンの対象としてレビューします。
グループ経由で割り当てられたユーザーについては、必要に応じてSlackで管理者に通知します。
各フローの中身の詳細
メインフロー1.0: 非アクティブユーザーの検出とレビュー
対象アプリのユーザー一覧を取得し、ユーザーごとの確認処理を開始します。
このフローに含まれる主なカードを、実行順に見ていきます。
やりたいことは明確なので作業に取り掛かります。「イメージ」列を削除し、各行の画像を2列目のテキストの下に移動した2列構成のテーブルにします。
カード | 役割 |
Scheduled Flow | このフローの開始点です。毎月、四半期ごとなど、決めたタイミングで自動実行します。手動実行でテストすることもできます。
|
Assign | 管理者が変更する値をまとめて持つカードです。対象アプリ名、非アクティブユーザーを入れるグループ名、最終ログインからの日数をここで指定します。
|
Clear Table | 前回実行時に残っているグループ割り当てユーザーの記録を削除します。毎回新しい結果で判定するための初期化処理です。
|
Now | フロー実行時点の現在日時を取得します。非アクティブ判定の基準日を作るために使います。
|
Subtract | Nowで取得した日時から、Days since last loginで指定した日数を差し引きます。たとえば90日なら、「90日前の日時」を作ります。
|
Search Applications | App Nameで指定したアプリ名をもとに、Okta内のアプリケーションを検索します。人が読む名前ではなく、後続処理で使うアプリケーションIDを取得するためのカードです。
|
Search Groups | Inactive Groupで指定したグループ名をもとに、Oktaグループを検索します。非アクティブユーザーを追加する先のグループIDを取得します。
|
If/ElseIf | アプリやグループの検索結果に応じて、次に進むか、別の処理に進むかを分けます。たとえばグループが存在しない場合に作成処理へ進めるための分岐です。
|
List Users Assigned to Application | 対象アプリに割り当てられているユーザーを一覧で取得します。ここで得られたユーザーが、非アクティブ判定の対象になります。 さらに、ユーザー一人ずつについて、ヘルパーフロー「1.1.0 - 最終ログインの確認」を呼び出しています。
|
このフローでは、まず現在日時を取得し、そこから指定日を差し引いて「確認する期間の開始日」を作ります。その後、入力されたアプリ名からアプリケーションIDを取得し、入力されたグループ名からグループIDを取得します。また、グループが存在しない場合はOkta Workflowsがグループの作成を行います。
次に、対象アプリに割り当てられているユーザーを一覧化します。ここから先は、ユーザー一人ずつに対してヘルパーフローを呼び出し、「このユーザーは最近アプリにサインインしているか」を確認します。
ここでのポイントは、管理者が毎回手でユーザー一覧を確認するのではなく、Okta Workflowsが同じ確認作業を定期実行できることです。月次、四半期ごと、半期ごとなど、自社のアクセスレビュー運用に合わせてスケジュールできます。
ヘルパーフロー1.1.0: 最終ログインの確認
このフローは、対象ユーザーと対象アプリの組み合わせでOkta System Logを検索します。
指定した期間内に、そのユーザーが対象アプリへサインインしたログが見つかれば「アクティブ」とみなします。ログが見つからなければ「非アクティブ」とみなし、レビュー用グループに追加します。
1.1.0フローのカードごとの役割は以下です。
カード | 役割 |
Helper Flow | 親フローから呼び出される開始点です。対象ユーザー、対象アプリ、確認期間、非アクティブグループなどの情報を受け取ります。
|
Compose | System Logを検索するための条件文を組み立てます。対象ユーザーIDと対象アプリIDを使い、「このユーザーがこのアプリにサインインしたログ」を探せる形にします。
|
Search System Logs | Okta System Logを検索します。検索範囲は、メインフローで作成した「何日前から現在まで」の期間です。
|
List Length | System Logsで見つかったログ件数を数えます。ログが0件か、1件以上あるかで判定が変わります。
|
Continue If | ログ件数が0件の場合だけ先に進めます。ログが1件以上あれば、そのユーザーは指定期間内にアプリを使っているため、ここで処理を止めます。
|
Add User to Group | ログが見つからなかったユーザーを、非アクティブユーザー用グループに追加します。Access Certificationsキャンペーンでは、このグループをレビュー対象として使います。
|
Continue If | グループ経由の割り当てだった場合だけ、テーブル記録などの追加処理へ進めます。個別割り当てであれば、ここで処理を終えます。
|
Create Row | グループ経由で割り当てられているユーザーの情報をOkta Workflowsテーブルに保存します。後でAccess Certificationsの失効判定が出たときに、この記録を参照します。
|
この処理を日常業務に置き換えると、次のような作業を自動化しているイメージです。
対象ユーザーの名前を確認する
対象アプリの利用履歴を探す
最近使っていれば何もしない
最近使っていなければレビュー対象リストに入れる
さらに、このフローでは「そのユーザーがアプリに直接割り当てられているのか、グループ経由で割り当てられているのか」も確認します。
直接割り当てとは、ユーザー個人に対してアプリが割り当てられている状態です。一方、グループ割り当てとは、「営業部」や「Zoom利用者」のようなグループにアプリが割り当てられ、そのグループに所属するユーザーがアプリを使える状態です。
この違いは、アクセス失効時に重要です。グループ経由でアプリに割り当てられている場合、レビューで「失効」と判断しても、元のグループルールやグループ割り当てが残っていると、アクセスが自動的には消えないことがあります。そのため、このテンプレートではグループ経由のユーザーをOkta Workflowsのテーブルに記録し、後続のフローで通知できるようにしています。
メインフロー2.0: グループ割り当てユーザーの失効検出
このフローは、Access Certificationsキャンペーンでレビュー担当者が「アクセス失効」と判断したときに動きます。
ここでの目的は、グループ経由でアプリに割り当てられているユーザーについて、管理者に追加対応が必要であることを知らせることです。
カード | 役割 |
Access Certification Decision Submitted | Access Certificationsでレビュー担当者が判定を送信したときに起動するイベントカードです。誰が、どのアプリについて、どのような判定をしたかを受け取ります。
|
Assign | 自社Okta orgのサブドメインと、環境種別を設定します。たとえばexample.oktapreview.comの場合、oktaOrgには”example”、Preview or Prodにoktapreview.comを入れます。後続で管理コンソールへのリンクを作るための値です。
|
| Continue If | Access Certificationsの判定がREVOKE、つまり失効判定かどうかを確認します。失効以外の判定であれば、この時点で処理を終了します。
|
Get | イベントデータから、判定対象ユーザーのIDを取り出します。後続のテーブル検索で、過去にグループ割り当てユーザーとして記録されたユーザーかを調べるためです。
|
| Search Rows | Okta Workflowsテーブルを検索します。1.1.0フローで保存しておいた「グループ経由で割り当てられていたユーザー」の記録を、ユーザーIDをキーにして探します。
|
| Continue If | テーブル検索結果が空でない場合だけ先に進みます。つまり、失効判定されたユーザーがグループ経由でアプリに割り当てられていた場合だけ、通知処理へ進みます。
|
| Call Flow | 2.1.0 - ユーザーのグループ判定フローを呼び出し、どのグループがそのユーザーに対象アプリを付与している可能性があるかを取得します。
|
List to Text | 取得したグループ名のリストを、Slack通知に入れやすい文字列へ変換します。複数グループがある場合は区切り文字でまとめます。
|
Parse | Slackメッセージ用の区切り線など、JSONで書かれたブロック定義をオブジェクトに変換します。
|
Compose | Slack通知の1つ目のブロックを作ります。たとえば「追加レビューが必要です」といった見出し部分を組み立てます。
|
Parse | 直前のComposeで作ったJSON文字列を、Slackコネクタに渡せるオブジェクトに変換します。
|
Compose | Slack通知の2つ目のブロックを作ります。対象アプリ、レビュー担当者、判定理由、グループ名など、詳細情報の本文を組み立てます。
|
Parse | 直前のComposeで作った詳細情報ブロックを、Slackコネクタに渡せるオブジェクトに変換します。
|
Concatenate | 対象ユーザーのOkta管理コンソールURLを組み立てます。https://、org名、環境ドメイン、ユーザーIDをつなげます。
|
Concatenate | 対象アプリのOkta管理コンソールURLを組み立てます。アプリタイプとアプリIDを使って、管理者が該当アプリを開けるリンクを作ります。
|
Concatenate | Okta管理コンソールのグループ一覧URLを組み立てます。グループ割り当ての確認先としてSlack通知のボタンに使います。
|
Compose | Slack通知のボタンブロックを作ります。ユーザー、アプリ、グループ確認画面へ移動するためのボタンを含めます。
|
Parse | 直前のComposeで作ったボタンブロックを、Slackコネクタに渡せるオブジェクトに変換します。
|
Construct | ここまでに作ったSlackブロックを、1つのリストにまとめます。見出し、詳細、区切り線、ボタンを順番に並べる処理です。
|
| Send Message to Channel | Slackチャンネルへ通知を送信します。管理者やアプリオーナーが、グループ割り当てによる追加対応を把握するための最終カードです。
|
ヘルパーフロー2.1.0: ユーザーのグループ判定フロー
アプリに割り当てられているグループ一覧と、ユーザーが所属しているグループ一覧を比較します。両方に含まれるグループがあれば、そのユーザーはグループ経由でアプリにアクセスしていると判断できます。
このフローは、グループ割り当ての突き合わせを担当します。カードごとに見ると、次のような処理です。
カード | 役割 |
Helper Flow | 親フローから呼び出される開始点です。対象ユーザーIDと対象アプリIDを受け取ります。
|
List Groups Assigned to Application | 対象アプリに割り当てられているOktaグループを取得します。たとえばZoomが「営業部」グループに割り当てられていれば、そのグループが一覧に含まれます。
|
Pluck | 取得したアプリ割り当てグループ一覧から、グループIDだけを取り出します。後で比較しやすくするためです。
|
Get Users Groups | 対象ユーザーが所属しているOktaグループを取得します。ユーザーが「営業部」と「東京オフィス」に所属していれば、その両方が一覧に含まれます。
|
Pluck | ユーザー所属グループ一覧から、グループIDだけを取り出します。
|
Intersection | アプリに割り当てられたグループID一覧と、ユーザーが所属するグループID一覧を比較し、両方に存在するIDだけを取り出します。これが「このユーザーにアプリを付与しているグループ」です。
|
Map | 一致したグループIDごとに、2.1.1 - グループ名の取得を呼び出します。Slack通知などで人が読めるように、IDを名前へ変換します。
|
Return | 判定結果を呼び出し元のフローへ返します。グループ経由だったか、該当するグループ名は何かを後続処理で使えるようにします。
|
ヘルパーフロー2.1.1: グループ名の取得
グループIDからグループ名を取得する小さな補助フローです。Slack通知など、人が読むメッセージではIDだけではわかりにくいため、グループ名に変換します。
カード | 役割 |
Helper Flow | 呼び出し元からグループIDを受け取ります。
|
Read Group | Oktaから該当グループの詳細情報を取得します。グループ名やプロファイル情報がここで取得されます。
|
Return | 取得したグループ名を呼び出し元へ返します。
|
利用時の注意点
このテンプレートには注意点があります。
1つ目は、同名アプリの扱いです。Okta org内に同じ名前のアプリケーションが複数ある場合、意図しないアプリが対象になってしまう可能性があります。対象アプリ名は、管理者が識別しやすい名前にしておくことをおすすめします。
2つ目は、サインイン履歴の見え方です。アプリやセッション設定によっては、ユーザーが長期間セッションを維持しているため、System Log上の認証イベントだけでは実利用状況を完全には表せない場合があります。非アクティブ判定の日数は、アプリの特性に合わせて調整してください。
最後に
非アクティブなアプリ利用者を特定して棚卸しをする運用を手作業で継続するには負荷が高く、その運用が形骸化してしまうことも少なくありません。
Okta Workflowsを使えば、対象アプリのユーザー一覧取得、System Logの確認、レビュー用グループへの追加、Access Certificationsとの連携、Slack通知までを一連の流れとして自動化できます。
また、このテンプレートの一部を活用・応用して、貴社のやりたい運用に沿ったフローを柔軟に作ることも可能です。
ぜひ、Okta Workflowsを活用して貴社のアイデンティティ管理の効率化を目指してみてはいかがでしょうか？
