はじめに

こんにちは、IT本部IT戦略部テクニカルオペレーショングループの利根川です。
DeNAではIdP（アイデンティティプロバイダー）としてOktaを長く利用しており、現在400ほどのアプリがOktaと連携しています。
Oktaの利用規模拡大に比例して管理者あての依頼も増加するため「運用担当者の工数軽減」が運用上の課題になります。
今回は「Okta Workflowsによるアカウントロック監視の自動化」により「運用の効率化」と「ユーザー体験の向上」を実現した事例を紹介します。
（前回記事はこちら）
https://engineering.dena.com/blog/2023/07/okta_samlcertificate

この記事の流れ

• Okta運用において管理者に依頼される内容
• アカウントロック対応を効率化できないか？
• なぜアカウントがロックされるのか？
• Okta Workflowsの活用
• Okta Workflowsの構築
• 注意事項
• まとめ
• 最後に

Okta運用において管理者に依頼される内容

Okta運用においてユーザーから管理者に依頼される「よくある案件」以下のパターンに分類できます。

• Okta連携アプリの追加/編集/削除
• アカウントの操作（登録/編集など）
• アカウントロックの解除

それぞれのケースごとに内容を見ていきましょう

Okta連携アプリの追加/編集/削除

1つ目はOktaでSSO連携するシステム追加や変更に関する依頼です。
Oktaの管理者において連携先システム（サービスプロバイダ）との連携作業が必要になります。 DeNAでは「Find out」という社内ヘルプリクエストシステムがあり、Oktaの連携アプリに関する依頼もシステムを通して依頼されます。
実運用として月に数件程度の依頼であり、大きな負担ではありません。

アカウントの操作（登録/編集など）

DeNA環境の「Oktaアカウント」は上位システムからのデータ連携により自動更新され、常に最新の情報が維持されています。
また、Oktaの個人設定や利用アプリの一部は「セルフサービス」で操作可能とし、管理工数の低減とユーザーの待ち時間短縮を両立する運用をしています。
「設定の代行」や「設定に関する問い合わせ」の依頼をいただくこともありますが、都度対応で解決するため、大きな負担ではありません。

アカウントロックの解除

最後、3つ目は「アカウントロックの解除」です。
Oktaのセキュリティ機能として「アカウントロック」の仕組みがあり、DeNAの環境でも有効化しています。 ロックされたアカウントはOktaにログインできなくなり、「管理者のみロック解除が可能」です。
アカウントロックは不正アクセスやアカウントへの攻撃が発生した場合に有効ですが、解消には必ず管理者の対応が必要です。
ユーザーからすると【Oktaに入れず仕事ができない　→　早く解消してほしい】状況です。
そのため他の案件より優先度が高く、Okta管理者の負担が大きくなっていました。

アカウントロック対応を効率化できないか？

「アカウントロックの対応」はユーザーの影響度・運用負荷どちらも高いことがわかり、Okta運用チームの取組として「アカウントロック対応の効率化」を進めることにしました。
検討にあたり、まずは従来の対応プロセスを確認します。
プロセスは「アカウントロックしたユーザーがOkta管理者に相談→管理者がアカウントの状態を確認→ロックされたログを確認→原因を特定し安全性を確認したらロック解除」となります。

続いて、「そもそもなぜアカウントロックが起きているか？」をOktaのログをもとに紐解きます。

なぜアカウントがロックされるのか？

ログの調査

ロックが発生したアカウントに「どんなログが残るのか」調査を行います。
Okta管理者機能の「System Log」からGUI上でログ調査が可能です。
公式FAQ：システムログ
ログを以下の2軸で検索します。

• アプリやユーザー/グループ等のリソース内部ID（OktaではGlobal IDと呼ぶユニークなID）
• イベント（操作や操作の結果起きたこと）

公式FAQ：システムログのフィルターと検索
アカウントロックの調査においては、以下条件で検索を実施しました。
“actor.id” eq “Okta管理者ID” and “target.id” eq “ロックされたアカウントID” and eventType eq “user.lifecycle.suspend”（ロックされた際のイベント）
結果が以下のように表示されます。

ログからアカウント停止の原因を探る

ログを見ていくと、ログイン失敗回数の蓄積によりアカウントがロックされた経過を確認することができます。

Okta Workflowsの活用

ここまでの調査内容を考慮し、効率的な運用を探る中で「Okta Workflows」が活用できるのではないか？との仮説に至りました。
Okta Workflowsを使用した新たな運用フローを考えてみます。
【これまでの運用フロー】

• 「アカウントにログインできない」とユーザーからヘルプリクエストが届く。
• ログを調査し、何が起きているか調べる。
• アカウントロックまでの履歴に不審な点が無いか確認する。
• 問題ないと判断した場合、アカウントロックを解除する。

【新たな運用フロー】

• Okta Workflowsで「アカウントがロックされたら管理者に通知する」
• 先行してログ調査を行い、不審な点が無いか確認する。
• ユーザー本人に対して「アカウントがロックされていますが、解除しますか？」と連携する。

とすることで「先回り対応」が可能になるのではないか？との仮説に基づいています。
【先回り対応のメリット】
ユーザー：これまでよりも速くアカウントが復旧できる。
管理者側：ユーザーの問い合わせ起点ではなく、通知ベースで作業を開始できる。

Okta Workflowsの構築

メンバー内で相談し、期待効果が明確であり、開発工数もかからないことから、Okta Workflowsでの構築を進めることを決定しました。
構築したワークフローは以下の通りとなります。
1.アカウント停止を検知する
2.管理者へ通知するSlackメッセージを生成する
3.Slackへメッセージを送信する
※Slackへの送信では「options」項目により投稿先のチャンネルや投稿方法を定義できます。

Okta Workflows構築時の事前準備

構築にあたり、以下の事前準備を行いました。

• 対象のアカウントを特定する。
  • 機能構築にあたり、運用対象アカウントを限定しました。
  • これまでの対応履歴から「ユーザーサポート」等のお客様対応を行う部門が「ロックする件数が多く、業務影響も大きい」ことから対象として決定しました。
• Slackワークスペースに「Okta Workflows:Slack」アプリをインストールする。
  • 事前にSlack側にアプリインストールが必要です。
  • ワークフロー設定時の困りごととして「投稿先Slackチャンネルが選択できない」トラブルがありました。
  • 選択可能なチャンネルはブラウザキャッシュを見ているようで、対象チャンネルをブラウザ版Slackで開いたところ選択できるようになりました。
• ワークフローの実行ユーザーを作成する
  • Okta Workflowsの動作は「ユーザー操作」と同様にみなされるため、ワークフローを利用するアカウントに「管理権限」もたせる必要がありました。

（参照したドキュメント） Okta Docs>標準的な管理者ロールと権限>ユーザー管理

導入効果・まとめ

アカウントロックの解除は管理者権限が必要であることから、相談から解消までの時間がまばらでした。
Okta Workflowsの導入によって、発生を検知し、先回り対応を取ることができることで応答時間を短縮することができました。
【導入前】
実際にロックされてから管理者が検知するまで（ログやユーザーとのやり取り履歴から算出）：30分～2時間
管理者がログを確認し、ロックを解除するまで：15～30分
【導入後】
アカウントロックの検知：リアルタイム（数分以内）
ログ確認及びロック解除：30分以内
上記のように高い導入効果を発揮しています。
各種システムのログは調査のために存在するだけではなく、上手に分析・活用することで今回のように「ユーザー体験の向上」にもつなげることができます。
システム管理者として「ログを調査し原因を特定する」スキルや「システムの機能を把握・活用につなげる」スキルを持つことが、効率的なオペレーションを実現する重要な要素と改めて感じました。

最後に

私の所属するテクニカルオペレーショングループでは新しい仲間を募集しています。
当グループでは、今回紹介した取組のように、DeNAグループ全社IT環境の運用管理にとどまらず「業務改善や効率化・省力化」を目的としたなチャレンジを行っています。
ご興味がある方はぜひ下記リンクから内容をご覧ください。