Okta Workflows の活用例 - 退職者のアクセスを柔軟に制御してリスクとコストを削減

ご提案やイベントの場でお客様からお話を伺っていると、退職される方への対応について関心をお持ちの方が多いと感じています。この記事では、Oktaの機能を活用して退職される方への対応を効率化し、リスクやコストを抑える方法をご紹介します。

退職者対応の関心が高い背景

まずは、退職者への対応に関心をお持ちになる方が多い理由を考えてみます。退職日以降、理論上は退職者と会社の関係はなくなりますが、実務上はそう単純ではありません。

例えば、退職後も以下のようなやりとりが必要になります。
・未払いの給与支払いや源泉徴収票授受のためのやりとり
・しばらくの間、取引先からの重要なメールが引き続き退職者宛に届く
・ファイル共有サービスで退職者の権限下にあるファイルやフォルダを整理する必要がある

これらの対応には事務的な作業負担や、予定された日に特定の作業をするためのスケジュール調整のコストなどが伴います。それぞれ例を挙げると
・源泉徴収票を必要なタイミングでメールで送付する。そのためのメールアドレスを予め聞き取り管理する。全て必要な手続きが完了した後に口座情報などの個人情報を削除する。
・一定期間メールを上司など別の社員に転送し、期間経過後はメールアドレスを削除する。
・後日、退職者の権限下にあるファイルを整理し、一定期限が過ぎたら削除する。
などの対応が必要になってきます。

また、成長中の企業では人材の出入りが多くなりますし、成熟企業でも社会全体として雇用の流動性が高まりつつありますので、これらの作業に伴うコストは日々増加していく傾向にあります。

理想的な退職者対応の運用

では、退職者対応が以下のようになったとしたらどうでしょうか？
・退職者はしばらくの間、給与支払い関連のシステムに限り以前通りアクセスできる。
・最終出社日に自動的に上司にメールの転送設定が行われ、メールアドレスは維持される。
・ファイル共有サービスのアカウントは維持されるが、その間退職者によるアクセスは禁止される。
・それら全てにおいて、必要な期間の経過後に自動的にアカウントが無効化される。

これらにより、前述したような作業負担やスケジュール管理から解放され、コスト効率と生産性が高まります。そして、確実にアカウントが抹消されるのでアプリのライセンス費用の無駄遣いがなくなるだけでなく、潜在的なセキュリティリスクの低下にもつながります。生産性、コスト、セキュリティの３つが大きく改善する理想の運用というわけです。

阻害要因と課題 

理想的な運用のうちの一部は、退職者にはOktaのような認証サービスを使わず、アプリの提供するIDとパスワードによるログイン画面を利用してもらうことで実現可能なように見えます。しかし、これには以下のような問題点があります。
・ひとたび認証サービスと連携させると、アプリの提供するログイン画面が利用できない実装のアプリがあり、解決策としてそもそも適用できない。
・事前にパスワードを設定する必要があり、パスワードを忘れるとサポート対応が必要
・多要素認証など十分にセキュアな認証を行うことができない
・それにより攻撃の対象となりやすい
・最終的なユーザーの無効化／削除などの管理作業は手作業で行う必要がある

Okta Workflowsを活用した解決策

Okta の特徴の一つが、理想的な退職者対応の運用であげたような柔軟かつ高度な自動化を実現できるという点です。そして、その中心となるのが Okta Workflows です。Okta Workflows を利用するとお客様独自にカスタマイズされたアイデンティティ管理の自動化を実現することが可能です。

Okta Workflows はスケジュールやOkta上のイベントなどをきっかけに動作させ、Okta の管理操作や外部アプリのAPIを使って任意の処理を実行させるなどの処理をさせることができます。それでは、実際に退職者の対応の自動化の例をみていきます。

退職者情報の取得：

まず、退職者の情報はID源泉から同期によって取得します。画一的なライフサイクル管理の場合、この時点で退職者のOktaアカウントは停止しアプリからもアカウントが無効化します。もちろん、この対応で十分という場合もあると思いますが、今回実現したいのはもっと柔軟な体験です。そのためここでは、この処理を行わないように設定し、退職したという情報を受け取るだけにします。その後の処理をOkta Workflowsで行うことで柔軟な体験を実現します。

以下がID源泉設定の該当部分です。

Okta Workflows の実行：
ここからお話しする一連の処理で利用するOkta Workflowsのフローは２つのフローでできています。1つはメインフローで今からご説明するものです。もう１つはヘルパーフローと呼ばれメインフローから呼び出されて繰り返し処理などを行うものです。これは少し後の方でお話しします。

OktaがID源泉から退職情報を受け取ると、そのユーザーは自動的にOkta上のID源泉アプリから割り当てが解除されます。Okta Workflowsはこの「ユーザーがアプリから割り当てを解除された」というイベントをきっかけにして自動実行することができます。このためには、User Unassigned from Application というイベントカードを用います。このカードを指定したのちに表示されるOption設定で、ID源泉を指定しておけば、ID源泉から退職の情報を受け取った際にこのフローが自動で実行されます。以下の画像の例では対象としてActive Directoryを指定しています。

グループの割り当て状態を変更する：

Okta Workflowsは柔軟性に優れ、様々なことが実行できる機能ですが、あらゆる処理を実行させるよりもOktaが具備している機能で実現できる部分はそちらに任せる方が効率も信頼性も高まります。ここではOktaのグループ割り当てを自動化する機能であるグループルールを組み合わせて利用します。通常、グループルールは「ユーザー属性の部署名が営業部だったら、Oktaの営業グループに所属させる」といった設定で利用されています。ここにあらかじめ一つ工夫を施し「退職者グループに所属していないユーザーだったら」を条件に追加します。もちろん、予め退職者グループは作成しておく必要があります。

その上で先ほど退職者情報を受け取ることで開始したOkta Workflowsでは、退職者を退職者グループに所属させる処理を行います。グループルールの設定は「退職者グループに所属していないユーザー」が条件になっているため、退職者は以前自動で割り当てられていたグループ（例えば営業グループ）から割り当てを解除されます。

以下はグループルールの設定例です。IF の部分が条件で、!isMemberOfGroupName(“退職者”) の部分が退職者グループのメンバーではないという条件です。(isMemberOfGroupName部分はカッコ内のグループのメンバーであることを意味しますが、その前にあるエクスクラメーションマークによって逆の意味になります。）user.department == ”営業部” の部分がユーザーのdepaprtment属性が営業部であるという条件になります。これらがANDでつながれているため両方の条件を満たすことが条件となります。

退職者グループに退職者を割り当てるフローの実例をみてみましょう。メインフローの続きです。

ユーザーをグループに所属させる処理はAdd User to Groupカード（③）で行うことができます。このカードの処理には、入力情報として対象ユーザーのIDと所属させるグループのIDが必要になります。これらはそれぞれ User Unassigned from Application カード（①）、Search Groups カード（②）から取得しています。

①のカードは一つ前のセクションで説明したフローの実行条件を示すイベントカードです。このイベントの情報には、アプリ（ここではID源泉）から解除されたユーザー情報、つまり今回のケースでは退職者の情報が含まれており、Okta User > ID がユーザーIDです。
Search Groupsカード（②）で退職者グループを名称で検索してグループIDが得られます

残りのグループの割り当て解除：

実際には Group Rule 以外の方法、例えば手動による割り当てやOkta Identity Governance の機能を利用して申請・承認により都度割り当てされたグループがあるかもしれません。これらはリストアップしてグループを解除していきます。

なぜ全てをこの方法で行わずに、グループルールを工夫して解除したかには実は訳があります。グループルールには、ルールで割り当てられたグループからユーザーを手動やOkta Workflowsで個別に解除すると、ルールによって再度割り当てられてしまわないように、ルール除外リストにユーザーが自動登録される仕組みがあります。これ自体はよくできているのですが、除外リストには100エントリまでという制限があります。運用の仕方にもよりますが、組織によってはこの数では不足してしまい、運用上の問題となる場合があります。単純にグループルールによって非該当になった場合は除外リストが使われることはないため、この問題を無視することができます。

こちらもフローをみてみましょう。つながりが分かりやすいようにメインフローの続きとそこから呼び出されるヘルパーフローの画像を繋ぎ合わせてあります。

先ほどまで見てきたメインフローの続きは左側のGet User Groupsカード（④） のみです。これは任意のユーザーが所属しているグループのリストを取得するためのカードです。当然ここでは退職者のユーザーIDを与えて、退職者が所属しているグループのリストを取得しています。カードの中にStreamingというセクションがありますが、これはカードの結果として得られた（グループの）リストをヘルパーフローに１件ずつ渡して処理させるモードです。リスト全件について処理が完了すると、このカードの処理は終了しメインフローの次のカードへ進んでいきます。

画像では名前が途中までしか表示されていませんが、 “[helper 1.1] グループ割り当ての解除” が受け渡し先のフローであり、画像右方の４つのカード（A~D）で構成されています。Helper Flow（A）カードで始まっていますが、これはイベントカードです。メインフローから呼び出された際に動作します。このフローでは最終的に退職者をグループから割り当て解除したいので、退職者のユーザーID(userId)を受け渡します。(上の矢印）

また、さきほど割り当てた退職者グループから解除してしまっては意味がないので、退職者グループはこの処理から除外するために、退職者グループのID(excludeGroups)も受け渡しています。（下の矢印）

このように追加で必要な情報をヘルパーフローに受け渡すことで処理に利用することができます。受け渡しを行わない場合はカードで実行された結果（本例の場合は Get User Groups カードで得られる、ユーザーが所属中のグループの情報）だけが受け渡されます。

続く Contiue If カードは、条件が一致した場合は次のカードへ進み、不一致の場合はフロー内の処理はそこで完了します。

１つ目の Continue If カード（B）は、退職者グループのID(excludeGroups)を使って退職者グループを処理の対象外としています。（excludeGroupsと今処理しようとしているグループのIDが異なれば継続、という条件）

２つ目のContinue if カード（C）はエラーを回避するためのものです。EveryoneなどのOktaのビルトイングループに対してはユーザーの割り当て状態を変更できないので、それらを処理から除外しています。（グループのタイプがOKTA_GROUPだった場合に処理を継続、という条件。OKTA_GROUPはOktaに管理者が任意に作成したグループを意味するタイプです。）

これらの条件にマッチすれば、グループからユーザーを割り当て解除します。（D）
つまり、退職者グループ以外のOKTA_GROUPからユーザーは割り当て解除されます。
先ほど説明した通り、Streamingモードによりグループは全件順々に処理されていきますので、最終的にユーザーが所属するグループは退職者グループ（及びビルトインのグループ）のみになり、この部分の処理は完了します。

アプリの解除：

さて本来の目的であるアプリの解除です。通常、アプリはグループを介して割り当てられているので、ここまでのグループの割り当て解除によってアプリの解除はすでに完了しています。（なお、Everyone グループにアプリが割り当てられていると解除されないため、アプリの割り当てに利用しないようにします。）

予め退職者グループに割り当てているアプリのみ、割り当て解除の対象外になります。
ここでは扱いませんが、手動割り当てされたアプリなどがある場合に備えてユーザーに割り当てられているアプリを走査して解除する処理を組み込んでも良いでしょう。

アクセスを制御する：

退職ユーザーに対する割り当てを維持するアプリには、退職後もアクセス許可するアプリと、退職日以降はアクセスを拒否したいアプリがあると思います。冒頭の例でいえば、給与支払いのアプリは前者、後者はメールやファイル共有サービスのアプリになるでしょう。このコントロールは、Oktaのアクセスポリシーで行うことができます。

後者に該当するアプリに対して、「退職者グループに所属していたらアクセスを拒否する」というポリシーを追加するだけです。ポリシーには優先順位があり、整合性が取れるように配置する必要がありますが上記のルールであれば最優先(1番目)に配置しておけば確実です。

アクセスを引き続き許可するアプリについては特別な設定をする必要はありません。（要求する多要素認証を在籍時とは異なるものにしたい場合などは、上図のような別のポリシーを作り、退職者グループに対して要求する要素を指定することで対応できます。）

最終処理のための準備：

ここまでで、退職イベントに合わせて退職後もアカウントを残すアプリを維持し、アクセスの可否もコントロールができました。最後の処理は一定期間経過後のユーザーの最終的な無効化です。自動化された処理にするため、ユーザー無効化処理のスケジュール予約をしておきます。予約処理はいくつかの方法が考えられますが、今回はOkta Workflowsのテーブル機能を利用しています。

メインフローの続きはこちらです。

まず時刻を取得（⑤）し、そこに最終処理を行うまでの日数(ここでは45日）を足しています。（⑥）

日付は協定世界時（UTC）になっているので日本標準時（JST）に直しつつ、深夜0時に時刻を変更しています。（⑦）この日時が退職者のアカウントが完全に無効化されるタイミングです。

最後はこうして計算した日付と、ユーザーの情報をテーブルに保存しています。（⑧）
このメインフローの処理はここまでです。

最終処理：

最終的にユーザーを無効化する処理です。毎日夜間にOkta Workflowsで予約をチェックし、予約日であればそのユーザーを無効化する処理を行います。ユーザーが無効化されるとアプリに対するアカウントの無効化もデプロビジョニングにより自動的に実行されます。

こちらはここまで紹介してきたフローとは異なる独立したメインフローです。

最初のカード（I）は、このフローがスケジュール実行であることを示すものです。例えば毎日午前2時に実行などに設定しておきます。次に Now カード（II）で現在時刻を取得し、最終処理予約テーブルに登録された日時が現在時刻よりも過去になっているユーザーを、テーブル検索のための Search Rows カード（III）で抽出します。抽出されたユーザーのリストは For Each カード（IV）に受け渡され、カード名の通り全件完了するまで一件ずつ指定されたフローでの処理を実行します。”[helper 2.1] ユーザーの… ”となっているのがそのフローで以下の画像です。

呼び出される際に、ユーザーID（Id）とテーブルの行ID（rowId）を受け取っています。（a)どちらも呼び出し元のフローでテーブルから読み取ったものです。

ユーザーID（Id） を使って、Deactivate Userカード（b）で退職者をOktaから無効化し、ユーザーの情報を Delete Rowカード（c）でテーブルから削除します。行を削除するためにはテーブルの行ID（rowId）が必要ですが、これはメインフローから与えられています。

自動化による便利で安全な対応

Oktaの持つ機能とOkta Workflowsを活かして、退職者にまつわるアイデンティティの運用を自動化することができました。

本記事ではアプリへのアクセス部分についての自動化に留めましたが、例に挙げた退職者宛のメールの転送設定などもOkta Workflowsからメールサービスの API を利用することで実現できますし、必要な人に、最適な手段で(ビジネスチャットなど)、最良の時間に通知するなどの自動化を盛り込むことも可能です。

こうした自動化はIT部門の作業やスケジュール負担などが減るだけでなく、ミスなども抑えられることでセキュリティ上の効果にもつながります。さらに冒頭で例に挙げたような業務部門の作業を圧縮することにつながるケースもあります。ぜひビジネスに役立つ自動化の活かし方を見つけてご活用ください。