Okta CIC Actionを活用した独自の認証関連機能の移行方法、およびログやメトリクスの監視手法について実例紹介

2024年7月11日にOkta Japanが主催するCIC (Customer Identity Cloud) Meetupで「Okta CIC Actionを活用した独自の認証関連機能の移行方法、およびログやメトリクスの監視手法について実例紹介」と題して発表した登壇資料です。
登壇者：株式会社kubell プロダクト開発ユニット 認証グループ 山下 賢治
ブログ：https://creators-note.chatwork.com/entry/2024/07/31/100000

Transcript

1. Okta CIC Actionを活用した独自の認証関連機能の移行方法 およびログやメトリクスの監視手法について実例紹介 山下 賢治 2024年07月11日 Okta CIC カスタマーミートアップ
2. 目次 CONTENTS 01 | 会社概要 02 | Okta CICの導入背景について 03 | Okta CICへどう移行していったのか 04 | 日々の運用監視について
3. 自己紹介 3 • 山下 賢治 ◦ 2022年4月に入社 3年目 ◦ 株式会社kubell コミュニケーションプラットフォーム部 ▪ プロダクト開発ユニット プロダクト開発部 ▪ 認証チーム ◦ GitHub: yamakenji24
4. 会社名 株式会社kubell 代表取締役CEO 山本 正喜 グループ従業員数 465名（2024年3月末日時点） 所在地 東京、大阪 設立 2004年11月11日 会社概要
5. 2024年7月1日よりChatwork株式会社は、株式会社kubell（読み：クベル）に社名変更しました。 株式会社kubellは、誰もが使いやすく、社外のユーザーとも簡単につながることができる 日本最大級のビジネスチャット「Chatwork」を運営しています。 また、チャット経由で会計、労務、総務など様々なバックオフィス業務をアウトソースできる 「Chatwork アシスタント」などのBPaaSサービスを幅広く展開。 ビジネスチャットの会社から、BPaaSで「働く」を変えるプラットフォームを提供する会社へ事業領域を拡張します。
6. Okta CICを導入するに至った背景 6 課題 - 「Chatwork」は、導入当時400万以上（現在680万以上 2024.03末時点）の登録アカウントを抱える”ビジネスインフラ” ➢ 登録アカウントのセキュリティを業界最高級水準で維持し続ける必要 がある - 一方、「Chatwork」の中核機能は「ビジネスチャット」 ➢ セキュリティはコアドメインではない 解決策として、 - 日々推移するセキュリティ課題への対応、追従については、専門のIDaaSにお任せする判断 ➢ 「ハイトラフィックなビジネスチャット」という中核機能に開発リソースを集中できる状態を目指した 加えて、 - 「BPaaS」という新規事業展開 ➢ 「Chatwork」登録ユーザーへ、ビジネスチャット以外のプロダクトの提供を実現できる必要 ➢ 認証系を、業界標準（OIDC）に準拠させながら、「Chatwork」本体から分離させ、他プロダクトの認証機能としても運用で きる状態を目指した
7. Okta CIC導入のための移行戦略 7 Okta CICを導入していくにあたり、全体の基本構成を設計 - Okta CICへ認証サーバーを任せること - 「Chatwork」側(kubell共通認証・ID基盤側)にアカウントマスターを残すこと - 既存のアカウントを事前にOkta CICへ移行しない - 初回ログイン時にOkta CICのAutomatic Migrationを活用する 課題 - 「Chatwork」では、現在ログインしてきたユーザーをIDトークンから取得する必要がある - 「Chatwork」はOIDCクライアントとして振る舞うため - 「Chatwork」では、「account_id」で一意にアカウントを識別している 解決策として - Okta CIC Actionsを活用してアカウントを連携する
8. Okta CIC Actionsを活用したアカウントの連携 8 ユーザーのプロビジョニングとIDトークンの生成をOkta CIC Actionsでカスタマイズする - 初回ログイン時に「account_id」をアカウントマスターから取得しmetadataへセットする - metadataから「account_id」を取得し、IDトークンに付与する ⇨ 「Chatwork」はIDトークンからaccount_idを取得し、一意にアカウントを識別できる
9. Okta CIC Actionsを活用したアカウントの連携
10. Okta CIC Actionsを活用したアカウントの連携
11. Okta CIC Actionsを活用したアカウントの連携
12. Okta CIC導入するために、既存の認証要素を移行する 12 Okta CIC移行にあたって、主に以下の3つに分類できた - Okta CICの機能としてそのままOkta CIC側へ持っていけたもの - Okta CIC Actionsを利用して移行したもの - 「Chatwork」に残したもの
13. Okta CIC導入にあたって、認証要素を分類 13 Okta CICの機能を利用している認証要素 - Okta CICが提供している機能を利用する - 「Chatwork」をOIDCクライアントとして扱いOkta CICをOIDC認証サーバーとして扱う Okta CIC Actionsを利用して移行した認証要素 - 認証の共通基盤として「Chatwork」以外のアプリへも認証機能を提供したいもの 「Chatwork」側に残した認証要素 - 「Chatwork」固有の機能 - 認証の共通基盤として持っておきたい機能というわけではない
14. Okta CIC 導入後にどうなったか 14
15. Okta CIC 導入後にどうなったか 15
16. Okta CIC 導入後にどうなったか 16
17. Okta CIC 導入後にどうなったか 17
18. Okta CIC移行にあたって、認証要素を分類 18 Okta CICの機能を利用している認証要素 - Okta CICが提供している機能を利用する - 「Chatwork」をOIDCクライアントとして扱いOkta CICをOIDC認証サーバーとして扱う Okta CIC Actionsを利用して移行した認証要素 - 認証の共通基盤として「Chatwork」以外のアプリへも認証機能を提供したいもの 「Chatwork」側に残した認証要素 - 「Chatwork」固有の機能 - 認証の共通基盤として持っておきたい機能というわけではない
19. 既存のChatworkの認証要素を移行するためのOkta CIC Actionsの活用 追加認証を行うOkta CIC Actions - 「kubell共通認証・ID基盤」における追加の認証を行う - 共通の認証基盤として追加認証を実施できるので、3rd-Partyクライアントを想定した場 合もこの方式を採用できる。 - 追加認証の一つとして、2段階認証を行っている - 2段階認証はOkta CICの機能を使わず「kubell共通認証・ID基盤」独自に行っている - 2段階認証設定の有無を確認 - Redirect With Actionsを使用して「kubell共通認証・ID基盤」側で処理 - 詳細は後述
20. ２段階認証に関しては、画面含めてOkta CICに移行せず、「kubell共通認証・ID基盤」側で実装をしている - 元々「Chatwork」として２段階認証を提供していた - その時の仕様とOkta CICとの仕様の差分についてユーザーコミュニケーションが発生する - 「Chatwork」では、バックアップコードは同時に10個発行される - Okta CICは一つずつ発行される - 「Chatwork」のバックアップコードをOkta CICへ移行することができない - バックアップコードをOkta CIC側で再生成する必要がある - 「Chatwork」ではメインのTOTP/SMSとは別にセカンダリーのSMSを設定が可能 - ２段階認証設定時のUXを変更する必要がある ⇨ これらの仕様変更をOkta CICリリース時に含めるのは、ユーザーの負担が大きい ⇨ Okta CIC導入時は２段階認証をOkta CIC側に移行せず、既存の仕様を通すことでユーザー負担を減らす Okta CIC導入時の２段階認証の移行について
21. Okta CIC導入時の２段階認証の移行の実現方法について
22. Okta CIC Actionsの活用 「メール認証」 先日、「長期間利用がないアカウントを保護するためのメール認証 」をリリースした - Okta CIC Actions内で長期間利用がないアカウントかどうかの判別を行うことができる - 追加認証の仕組みを載せることができ、既存の認証フローに乗っかかることができた https://go.chatwork.com/ja/news/info/202401.html
23. Okta CIC Actionsの活用 「メール認証」
24. ここまでがどうやって Okta CICを導入していったか
25. では、実際Okta CIC導入後 安定して動作しているのか？ ログやメトリクスを 監視しているので見ていきましょう
26. 日々の運用監視について 「Chatwork」の特性上、朝イチに一番のログインピークが発生する その後は定期的なリクエストの波がある 680万以上の登録アカウント（※2024.03末）を抱える”ビジネスインフラ”たるサービスとして - いつでもログインすることができる - セキュリティを担保し、ユーザーの情報を保護する必要がある そのためのログ活用を行っている
27. ログで確認していること - Okta CICのログをEventBridge経由でDatadogに流してDashboardで日々確認している - Okta CICのログの保存期間が最大30日であるため - ログイン成功数/失敗数 - 定期的に数を確認している - 異常なログイン成功数、失敗数がないか
28. Okta CICのSecurity Center確認していること - Bot Detectionが異常に跳ねていないか - Suspicious IP Throttlingが発生していないか - Brute-Force Protectionが跳ねていないか - Breached Password Detectionが異常に跳ねていないか
29. ログで確認していること - Okta CICが提供しているログ以外にも独自に仕込んでる - /oauth/tokenに対するリクエスト数やstatus - エラー数やレート、レイテンシーなど
30. ログで確認していること ユーザーのログイン種類別のログも確認している - Okta CIC Actionsでログイン種類について取得している - Event Objectのconnection.strategyで認証にどのconnectionを使用したかの情報が入ってる - IDトークンにその情報を含めて、Chatwork側でログを出力している これにより以下のようなことが可能となる - 異常なログインパターンやトラブルシューティングに早期検知 - ユーザー行動の理解の促進 - ログイン種別のパフォーマンスの最適化
31. ログで確認していること
32. まとめ 導入背景 - 日々セキュリティ対応への追従と新規事業展開のためにOkta CICを導入 導入戦略 - Okta CICへ認証サーバーを任せること - Chatwork側でマスターデータを持たせること - Okta CIC ActionsとRedirect With Actionsを活用し、アカウント連携と認証機能を移行 日々の運用監視 - Bot DetectionやBrute-Forceなど、Okta CICのSecurity Centerを活用 - それ以外にログインメトリクスなどを独自に取得し、Dashboardで監視している ⇨ 安定した認証基盤を提供するために日々改善して行ってます！
33. 働くをもっと楽しく、創造的に