最大公約数的アーキテクチャで個別実装から脱却する～認証認可基盤の共通化に向けた取り組み～

最大公約数的アーキテクチャで個別実装から脱却する ～認証認可基盤の共通化に向けた取り組み～ アーキテクチャConference 2024 Takamasa Saichi / Koki Imanaka © 2024 Finatext Holdings Ltd.

株式会社 Finatext Finatext グループ ● グループのミッション "金融を "サービス" として再発明する" ○ 事業領域ごとにグループ会社やチームを設立してサービスを展開 ○ 国内のメンバー数 300 人弱, うちエンジニア 100 人程度 フィンテックソリューション 事業領域 データ &AIソリューション 事業領域 データ 事業領域 証券 事業領域 保険 事業領域 クレジット 事業領域 金融インフラストラクチャ領域 © 2024 Finatext Holdings Ltd. 3

株式会社 Finatext 金融インフラストラクチャ領域の展開 ● 金融領域ごとにマルチテナントな事業をマルチプロダクトで展開 ○ 証券・保険・クレジット（貸金）の基幹システムを SaaS として提供しつつ その上で実現された toC 向けのプロダクトも協業で開発・運用している フロントサー ビス A フロントサー ビス B フロントサー ビス C フロントサー ビス D フロントサー ビス E フロントサー ビス F パートナー 企業A パートナー 企業B パートナー 企業C パートナー 企業D パートナー 企業E パートナー 企業F 協業 協業 協業 証券事業領域 SaaS 保険事業領域 SaaS クレジット事業領域 SaaS © 2024 Finatext Holdings Ltd. 4

株式会社 Finatext プロダクト例の紹介 ● 金融領域ごとにマルチテナントな事業をマルチプロダクトで展開 ○ 証券・保険・クレジット（貸金）の基幹システムを SaaS として提供しつつ その上で実現された toC 向けのプロダクトも協業で開発・運用している © 2024 Finatext Holdings Ltd. 5

登壇者紹介 ● 齋地 崇大（Takamasa Saichi) ○ 株式会社 Finatext ○ Platform team エンジニア ○ 筑波大学→Cookpad inc.→現職 ○ X: @s4ichi ● 今中 公紀（Koki Imanaka） ○ 株式会社 Finatext ○ InsureTech team エンジニア ○ 東京大学大学院 → H.I.S. →現職 © 2024 Finatext Holdings Ltd. 7

本日の発表について ● 金融に関わる情報を取り扱う Finatext では認証認可の領域において 「車輪の再発明」「サイロ化するナレッジ」 「専門性の希薄化」「技術的負債の蓄積」 が将来的に課題となり、会社の成長を阻害する可能性があった ● 金融サービスの業界における競争優位性を保ち続けるためにも 認証認可の技術領域で専門性を育てて適用する Enabling team が発足 ● 各事業領域に適用が可能な認証認可の基盤について 最大公約数的なアーキテクチャを選択して課題へ向き合う選択 ● チャレンジングな取り組みをアーキテクチャ選定の参考事例として紹介 © 2024 Finatext Holdings Ltd. 8

Finatext と認証認可 「車輪再発明」「サイロ化するナレッジ」「技術的負債の蓄積」「専門性の希薄化」 © 2024 Finatext Holdings Ltd. 9

Finatext と認証認可 プロダクトごとの技術スタック・開発チーム ● Finatext で展開しているプロダクトは領域ごとに複数の開発・運用チーム ○ セルフサービス化が進んでおり、チームや領域ごとに権限管理なども独立 ○ 認証認可もプロダクトや領域共通で要件ベースの技術選定・開発がされている 事業領域A 開発チーム1 事業領域A 開発チーム2 事業領域B 開発チーム1 事業領域C 開発チーム1 フロントエンド バックエンド フロントエンド バックエンド フロントエンド バックエンド フロントエンド バックエンド インフラ インフラ インフラ インフラ 認証認可 認証認可 認証認可 Platform team（共通ツール開発やガードレール整備など） © 2024 Finatext Holdings Ltd. 10

Finatext と認証認可 例えば、「あるプロダクトで OAuth 2.0 の Authorization code フローを提供したい」 ● 再利用が難しい ○ 先行導入事例が別のプロダクトにあったとしても共通化の難易度が高い ■ 「先行事例の要件専用の個別実装なので似てるけどそのまま導入ができない」 ■ 「領域違いで開発チームが異なるから共通化に踏み出しにくい」 ■ 「マルチテナント化の拡張が難しいので環境を複製して対応する」 ○ 個別の実装が増えることで "車輪の再発明", "サイロ化するナレッジ" ● 一定期間で開発してリリースするスタイルが標準的 ○ 要件をダイレクトに実現する開発 ■ 「汎用的な仕組み化よりもリリースを優先した開発スケジュール」 ■ 「既存仕組みや技術を（時には無理に）拡張することで実現していく」 ○ 認証認可領域も例外ではなく "技術的負債の蓄積", "専門性の希薄化" © 2024 Finatext Holdings Ltd. 11

Finatext と認証認可 成長速度と将来の負債化への懸念 ● 新規のパートナー獲得からプロダ クトの提供は今後も主力事業であ り、物凄い勢いで成長 ● 金融商品及びセンシティブな情報 を扱う Finatext のプロダクトに おいて認証認可機能の品質は重要 認証認可領域の負債化による アジリティやセキュリティの低下は 会社の信用に関わる課題 2024.11.14 決算説明資料より © 2024 Finatext Holdings Ltd. 12

認証認可領域への組織的アプローチ 問題解決のための組織構造のアーキテクチャ © 2024 Finatext Holdings Ltd. 13

認証認可領域への組織的アプローチ Enabling team の発足 ● Enabling team が発足（2023.12） ○ それぞれの技術分野における 競争優位性 を生み出すためのチーム ● 事業領域横断で技術検証・開発・導入支援まで実施 ○ 特定領域に知見が偏らないよう各領域から1~2人を兼任でアサイン ■ ナレッジのサイロ化を防ぎ、再利用性を高める目的 ○ 個別要件や締切に左右されずアーキテクチャを突き詰めて考える ■ 柔軟な開発スタイルの適用、専門性の強化 イネイブリングチームは、特定のテクニカル（プロダクト）ドメインのスペシャリストから構成され、能力ギャップ を埋めるのを助ける。複数のストリームアラインドチームを横断的に支援し、適切なツール、プラクティス、フ レームワークなどアプリケーションスタックのエコシステムに関する調査、オプションの探索、正しい情報に基 づく提案を行う。 マシュー・スケルトン,マニュエル・パイス. チームトポロジー 価値あるソフトウェアをすばやく届ける適応型 組織設計 (Japanese Edition) (p. 151). Kindle Edition. © 2024 Finatext Holdings Ltd. 14

認証認可領域への組織的アプローチ 認証認可 Enabling team の挑戦: 新認証認可基盤の開発 ● Enabling team が主導となり "新認証認可基盤" の開発を推進 ○ より低い開発コスト・より高い品質の基盤構築とその導入支援が主務 ○ 将来的に見込まれる要件や既存の課題感を解決して競争優位性へ貢献 ● マルチテナントな事業をマルチプロダクトで提供する環境への適応が必要 ○ 領域ごとにデプロイメントを配置してカスタム可能な自由度が求められる 事業領域A 開発チーム1 事業領域A 開発チーム2 新認証認可基盤 事業領域B 開発チーム1 事業領域C 開発チーム1 新認証認可基盤 新認証認可基盤 開発・導入支援とナレッジの提供 Enabling team: 新認証認可基盤の実装提供 , 基盤の運用は各種チームで実施 © 2024 Finatext Holdings Ltd. 15

認証認可領域への組織的アプローチ 最大公約数的アーキテクチャで実現する新認証認可基盤 ● 「要件を徹底的に汎用化して実装」を繰り返すことで再利用性を担保する ○ 世の中に標準化された仕様に当てはめ直して実現可能性を検討 ■ e.g., テナントAをサービスBでログインさせたい → テナントごとに OpenID Connect の連携として設定させる方針 ○ セキュアに実現するためのガードレールの役割も担う ■ "なんでも" 実現できる必要はないのでセキュアに提供できる枠組みを提供 ■ 実現に制約を課しておくことで運用の認知負荷を下げる目的 ● 既存のプロダクトの要件をまとめて "最大公約数的" 機能を導き出す ○ 複数のプロダクトにある機能を集約して互換性を担保した設計の検証・模索 ■ 機能理解から標準化、比較検討のちに実装の繰り返しで実現 ○ これまで実現されてきた多様な要件を集約するのはかなりのチャレンジ © 2024 Finatext Holdings Ltd. 16

新認証認可基盤の設計 技術的アーキテクチャの選択 © 2024 Finatext Holdings Ltd. 17

新認証認可基盤の設計 技術選定の条件 ● 標準的な認証認可プロトコル（OAuth/OIDC）をサポートできること ● 認証対象 ○ ユーザー認証（toC, toB） ○ M2M 認証 ● 様々な認証方法に対応することができる ○ ID/Pass、マジックリンク、WebAuthn など ○ OIDC, SAML 連携 ○ MFA ● マルチテナントのユーザー管理、権限管理ができること ● 将来的に Financial-grade API (FAPI) にも対応したい ● セキュリティと信頼性 ○ Finatext が提供しているのは金融機関向けの基幹システムで、個人情報が関わる 部分には一定の水準が求められる © 2024 Finatext Holdings Ltd. 18

新認証認可基盤の設計 技術選定 ● 認証系 SaaS が作りたいわけではないので、要件を満たした上でできるだけ開発・ 運用コストが低い仕組みにしたい→まずは SaaS を検討 ● 実績とセキュリティを考えて以下を候補として調査 ○ 海外 IDaaS A社 ■ 認証、ユーザー管理までオールインワンの IDaaS ■ 標準として提供されている認証方法や機能が豊富 ■ カスタマイズ性も高い ○ Amazon Cognito ■ AWS が提供しているマネージドな IDaaS ■ 標準でサポートされている認証方法や機能に一定の制限がある ■ マルチテナントには対応してないが、テナントごとにユーザープールを分けること で要件には対応できる © 2024 Finatext Holdings Ltd. 19

新認証認可基盤の設計 比較検討 ● 海外 IDaaS A社は最低限の実装で実現できる ○ ただ、求める機能を使うために必要な契約プラン・ MAU 数で見積もるとコストが アンマッチ ○ オールインワンが故にベンダーロックインの懸念もある ● Cognito のコストは非常に安いため問題なかったが機能的な制約があり、単独で 使用するのは難しそう ○ Hosted UI のカスタマイズ性が低く、日本語対応が難しい ○ 独自UIを実装することもできるが、OAuth/OIDC を実現するのに一部独自実装が 必要になる ○ そもそも SaaS を利用するのはコストを下げたいのが目的だったので OAuth/OIDC が独自実装になるのは避けたい © 2024 Finatext Holdings Ltd. 20

新認証認可基盤の設計 比較検討 ● Cognito + 認可フレームワークのサービスを組み合わせることを検討 ○ 国内 SaaS A社 ■ OAuth, OpenID Connect の準拠に必要な API を提供している SaaS ■ RFCへの追従が早く、FAPI にも対応している ○ Ory Hydra ■ OAuth, OpenID Connect に準拠した OSS ■ Go 言語で書かれており、クラウドネイティブな環境を前提に作られている 実装のイメージ © 2024 Finatext Holdings Ltd. 21

新認証認可基盤の設計 比較結果 ● 結果としては「 Ory Hydra 」を採用 ○ 両方ともで PoC を実施したところ必須要件は実現できることがわかった ○ どちらも開発が必要でインフラ、運用コストがかかるが国内 SaaS の方はプラスで 利用料がかかるため、コストメリットは Ory Hydra ○ また、金融機関向けの基幹システムを開発しているためセキュリティチェックシー ト対応を考えると国内 SaaS を標準で搭載するのが厳しそう ● 将来的に FAPI やそのほか最新の RFC への準拠が必要であれば国内 SaaS A社を採 用することも選択肢として残したい © 2024 Finatext Holdings Ltd. 22

新認証認可基盤の設計 最終的な構成 ● OAuth2.0/OIDC 系のリクエストは Ory Hydra で処理 ● それ以外の認証系のようなリクエストは自社開発のサーバーで処理 ● 実際の認証は Cognito で処理するためセキュリティ面は AWS で担保される © 2024 Finatext Holdings Ltd. 23

新認証認可基盤の設計 最終的な構成 ● Cognito は自社開発したサーバーでラップして使い、Cognito の Admin 系の API を使って操作 ● これにより Cognito では対応していない機能を柔軟に実装できるように構成 ○ メールアドレスが使用済みかどうかの隠蔽 ○ クライアント単位で認証方法を管理 ○ ユーザーのログイン履歴、変更履歴などを保存 ● フロントから直接アクセスされないようにするため、Cognito のクライアント （開発したサーバー）はパスワードを設定して Cognito のアクセストークンはパ ブリックなところに出さないようにしている © 2024 Finatext Holdings Ltd. 24

新認証認可基盤の設計 最終的な構成 ● テナント管理 ○ テナントごとの設定や使用する Cognito の情報を格納 ● ユーザーデータのキャッシュ ○ CSV のエクスポート機能などバルクで取得するユースケースがあるのでユーザー テーブルをキャッシュとして保持し、バルクはキャッシュから返す © 2024 Finatext Holdings Ltd. 25

新認証認可基盤の設計 最終的な構成 ● Cognito で対応できてない認証はカスタム認証を使って Lambda に実装 ○ AWS 側で実装のサンプルを提供しており、WebAuthn やマジックリンクは比較的 簡単に対応できる ○ https://github.com/aws-samples/amazon-cognito-passwordless-auth © 2024 Finatext Holdings Ltd. 26

• https://github.com/aws-samples/amazon-cognito-passwordless-auth

新認証認可基盤の設計 認証フロー © 2024 Finatext Holdings Ltd. 27

新認証認可基盤の設計 最終的な構成 ● M2M の認証は Ory Hydra の OAuth の API でクライアントクレデンシャルズフ ローで対応 ○ Hydra で scope 管理もできるので許可されている権限管理が可能 © 2024 Finatext Holdings Ltd. 28

新認証認可基盤の設計 事業依存の要件 ● 事業横断の基盤として使えるようにするため、認証と関係のないロジックは入れな いように設計を行った ● ただ、ユーザーの作成は既存ロジックとも密接に関係しており完全に分離させられ ないケースもあるので Webhook を実装して対応 ○ Cognito にもトリガーがあるが、Admin API 経由だと一部のトリガーが呼ばれな い © 2024 Finatext Holdings Ltd. 29

新認証認可基盤の設計 逆にCognitoに依存したくないところ ● ユーザーの識別子（sub）が Cognito によって自動採番される ○ ユーザーの識別子は重要な情報でそれを外部に依存してしまうことになる ○ 万が一 Cognito ではない別のサービスを利用したくなった時に採番ロジックが変 わってしまうリスクがある ○ Cognito はテナントごとに分ける必要があり、グローバルにユニークである保証が できない ● Cognito は作成時のみ設定可能なパラメーターがあり、変更したくなると新規作 成とデータ移行が必要 ○ Cognito で sub を採番する都合上、データ移行で sub が変わってしまう ○ サービスで利用しているユーザーの識別子を全て書き換えるのは不可能 ● ユーザーの識別子のみ独自実装側で採番して、Cognito の sub とのマッピングを 持たせるように実装 © 2024 Finatext Holdings Ltd. 30

新認証認可基盤の設計 最終的な構成 ● ロックインを避けるためヘキサゴナルアーキテクチャを採用しできるだけ切り替え時 の影響範囲を小さくするように実装 ○ Cognito 以外の認証基盤に切り替えかあるいは、テナント単位で切り替えたいケース ○ FAPI 対応が必要なテナントでは Ory Hydra ではなく、国内 SaaS A社の利用した いケース Hydra © 2024 Finatext Holdings Ltd. 31

新認証認可基盤のプロダクト展開 © 2024 Finatext Holdings Ltd. 32

新認証認可基盤のプロダクト展開 既存プロダクトへの導入: 保険事業 ● ● ● マルチテナントの SaaS なのでテナントごとの { 可視性の制御は非常に重要な問題 "scp": [ tenant_id というカスタムクレームを設定し、 "app.user.read", どのテナントで認証されたユーザーかを識別 "app.user.write", トークンを引き回すことで認証されたユー ], ザー、テナントに応じた可視性制御を実装 "sub": "01HX8BES45YZK3A9XP7FXXZQHS", "tenant_id": "01HT7P4XHW40SM7AXJPCQDYCR5", … } クライアントの アクセストークン アクセストークン クライアント BFF © 2024 Finatext Holdings Ltd. SaaS Core 33

新認証認可基盤のプロダクト展開 既存プロダクトへの導入: 証券事業 ● 既に10数個のプロダクトで認証認可の仕組みが実現されている ○ Cognito をベースにした Authorization code flow + 独自拡張 ■ JWT を使った AccessToken による認可処理をリソースサーバーで実現 ○ 認証認可の仕組みをテナント単位で構築・運用していた テナントA プロダクト1 client for Cognito ・・・ テナントA プロダクト8 テナントB プロダクト1 テナントB プロダクト2 client for Cognito client for Cognito client for Cognito 認証, Access token 発行, etc. Amazon Cognito User Pool（for テナントA） Amazon Cognito User Pool（for テナントB） © 2024 Finatext Holdings Ltd. 34

新認証認可基盤のプロダクト展開 既存プロダクトへの導入: 証券事業 ● 展開にあたって必要な機能を全部実装すると永遠に終わらないので、 全体像を把握後、個別の機能を汎用化して実装 → 導入を繰り返す ○ 旧来の認証認可の仕組みと新しい認証認可の仕組みが意図的に混在する状態 ● リソースサーバー側は新旧両方の Access token を許容する実装にスイッチ テナントA プロダクト1 client for Cognito ・・・ テナントA プロダクト8 テナントB プロダクト1 テナントB プロダクト2 client for Cognito client for Cognito client for 新認証認可基盤 認証, Access token 発行, etc. 特定プロダクト単位 の段階的な導入 新認証認可基盤 Amazon Cognito User Pool（for テナントA） Amazon Cognito User Pool（for テナントB） © 2024 Finatext Holdings Ltd. 35

新認証認可基盤のプロダクト展開 既存プロダクトへの導入: 証券事業 ● 展開にあたって必要な機能を全部実装すると永遠に終わらないので、 全体像を把握後、個別の機能を汎用化して実装 → 導入を繰り返す ○ 旧来の認証認可の仕組みと新しい認証認可の仕組みが意図的に混在する状態 ● リソースサーバー側は新旧両方の Access token を許容する実装にスイッチ テナントA プロダクト1 ・・・ client for 新認証認可基盤 テナントA プロダクト8 テナントB プロダクト1 テナントB プロダクト2 client for 新認証認可基盤 client for 新認証認可基盤 client for 新認証認可基盤 認証, Access token 発行, etc. 新認証認可基盤 Amazon Cognito User Pool（for テナントA） Amazon Cognito User Pool（for テナントB） © 2024 Finatext Holdings Ltd. 36

成果・今後の展望 © 2024 Finatext Holdings Ltd. 37

成果と今後の展望 再実装やナレッジのサイロ化が減少 ● 実装済の機能が再利用できるのでプロダクトへの適用やその提供速度が向上 ○ e.g., 外部 ID 連携機能の実装を他領域でのユースケースに適用 ○ 実装工数や開発リソースの大幅な削減が可能になっている ● 特定領域起因の機能に関するナレッジが共通のものになる ○ 同じ実装をベースにした議論を Enabling team 主体で実施可能 ○ メンバーを介して領域を横断した知見交流が容易になっている ● 「他領域で実装されたものがある」認識を共通化して適用可能性を議論可能に ○ パートナー企業様への機能提案やプロダクト開発の進行 ○ より直接的な価値・売上貢献の可能性も拡大 © 2024 Finatext Holdings Ltd. 38

成果と今後の展望 今後の展望とさらなる改善点 ● Finatext で展開する主要なプロダクトの認証認可を差し替えていく ○ まだ個別実装が必要な機能や領域も存在している段階である ○ 導入支援によって蓄積されたナレッジをより広げていくことも実施 ● 競争優位性を拡大するための機能開発・取り組みが次のチャレンジ ○ Passkey 対応や外部 ID 連携実績の拡大、FAPI のサポートなど ● Enabling team 無しでの完全な導入・運用を視野に入れたサポート ○ 社内 OSS 化や導入・運用ドキュメントの拡充 ○ 認証認可基盤をより身近な共有資産として共有できるように © 2024 Finatext Holdings Ltd. 39

まとめ © 2024 Finatext Holdings Ltd. 40

まとめ Finatext で取り組んでいる認証認可領域のアーキテクチャ ● Enabling team よる最大公約数的アーキテクチャでの基盤提供体制の確立 ○ 各領域から代表兼任メンバーを収集した Enabling team による専任の取り組み ■ 開発スケジュールに左右されない状況で専門性を育み強みにする ○ 組織が急激に成長していく中で適用範囲の広い認証認可基盤を提供し 会社の強みでもあるアジリティ・セキュリティを更に強化した ● マルチテナントの認証認可基盤として「Cognito + Ory Hydra」を採用 ○ IDaaS, OSS の力を借りてできるだけ自前実装をなくして 運用コストやかかる工数をできるだけ抑えることができた ○ Ory Hydra で OAuth/OIDC といった標準仕様に準拠した基盤に ○ Cognito を利用することで重要なセキュリティ部分について マネージドサービスを用いる信頼性の高い構成とした © 2024 Finatext Holdings Ltd. 41