Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
プロダクト成長に対応するプラットフォーム戦略:Authleteによる共通認証基盤の移行事例 /...
Search
KAKEHASHI
PRO
October 30, 2024
Technology
1
930
プロダクト成長に対応するプラットフォーム戦略:Authleteによる共通認証基盤の移行事例 / Building an authentication platform using Authlete and AWS
OAuth & OpenID Connect 勉強会 ー 認可サーバーの作りかた(AWS編)
https://authlete.connpass.com/event/333513/
での登壇資料です
KAKEHASHI
PRO
October 30, 2024
Tweet
Share
More Decks by KAKEHASHI
See All by KAKEHASHI
ユーザー課題を愛し抜く――AI時代のPdM価値
kakehashi
PRO
1
150
「AIと一緒にやる」が当たり前になるまでの奮闘記
kakehashi
PRO
3
200
みんなのSRE 〜チーム全員でのSRE活動にするための4つの取り組み〜
kakehashi
PRO
2
180
医療系のプロダクト開発における生産性向上と高信頼性を両立させる生成AI活用
kakehashi
PRO
1
120
完璧を目指さない小さく始める信頼性向上
kakehashi
PRO
0
210
ユーザー理解の爆速化とPdMの価値
kakehashi
PRO
1
170
スプリントゴール未達症候群に送る処方箋
kakehashi
PRO
2
780
安定した基盤システムのためのライブラリ選定
kakehashi
PRO
3
240
"SaaS is Dead" は本当か!? 生成AI時代の医療 Vertical SaaS のリアル
kakehashi
PRO
4
1.1k
Other Decks in Technology
See All in Technology
ZOZOTOWNフロントエンドにおけるディレクトリの分割戦略
zozotech
PRO
13
4.2k
第4回 関東Kaggler会 [Training LLMs with Limited VRAM]
tascj
11
1.5k
信頼できる開発プラットフォームをどう作るか?-Governance as Codeと継続的監視/フィードバックが導くPlatform Engineeringの進め方
yuriemori
1
400
[CV勉強会@関東 CVPR2025 読み会] MegaSaM: Accurate, Fast, and Robust Structure and Motion from Casual Dynamic Videos (Li+, CVPR2025)
abemii
0
180
OpenAPIから画面生成に挑戦した話
koinunopochi
0
130
S3のライフサイクル設計でハマったポイント
mkumada
0
100
Preferred Networks (PFN) とLLM Post-Training チームの紹介 / 第4回 関東Kaggler会 スポンサーセッション
pfn
PRO
1
130
kintone開発チームの紹介
cybozuinsideout
PRO
0
73k
歴代のWeb Speed Hackathonの出題から考えるデグレしないパフォーマンス改善
shuta13
6
580
[CVPR2025論文読み会] Linguistics-aware Masked Image Modelingfor Self-supervised Scene Text Recognition
s_aiueo32
0
210
開発と脆弱性と脆弱性診断についての話
su3158
1
1.1k
はじめての転職講座/The Guide of First Career Change
kwappa
5
4.5k
Featured
See All Featured
Gamification - CAS2011
davidbonilla
81
5.4k
Raft: Consensus for Rubyists
vanstee
140
7.1k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Statistics for Hackers
jakevdp
799
220k
Intergalactic Javascript Robots from Outer Space
tanoku
272
27k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Adopting Sorbet at Scale
ufuk
77
9.5k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Navigating Team Friction
lara
188
15k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
1k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.4k
Transcript
プロダクト成長に対応するプラットフォーム戦略: Authleteによる共通認証基盤の移行事例 2024/10/30 OAuth & OpenID Connect 勉強会 ー 認可サーバーの作りかた(AWS編)
1
© KAKEHASHI Inc. 自己紹介 2 岩佐 幸翠 (@kosui_me) 2019年にエンジニアとしてのキャリアを開始し、認証認可基盤の開発に従事。
2022年に カケハシへ入社し、社内プラットフォームの開発を担う。 すてにゃん (@stefafafan) 2024年にカケハシへ入社し、プラットフォームチームのテックリードを引き継ぐ。
© KAKEHASHI Inc. カケハシのビジョン 明日の医療の基盤となる、エコシステムの実現。 3 患者さん 薬局 医薬品発注・管理最適化
© KAKEHASHI Inc. カケハシのマルチプロダクトSaaS 4
© KAKEHASHI Inc. 目次 • カケハシのビジネスと顧客要求の変化 • カケハシの認証基盤とその課題 • カケハシの認証基盤刷新プロジェクト
◦ 技術選定 Authleteを選んだ理由 ◦ システム構成 AWSとAuthleteを利用した認可サーバー ◦ 移行戦略 プロダクトチームとの連携 • 今後の展望 5
カケハシのビジネスと 顧客要求の変化 6
© KAKEHASHI Inc. カケハシのビジネスの変化 薬局向けSaaSから「多様な顧客と協業する多面的な医療プラットフォーム」へ ▶ 機能・品質の両面で顧客のニーズが高度化 7 背景 マルチプロダクト
SaaS 創業期 成長期 転換期 単一プロダクト SaaS 中堅・中小企業に加え 大手薬局チェーン 中堅・中小企業 全国の薬局に加え 製薬企業・医薬品卸 など 多面的 プラットフォーム プロダクト 顧客 フェーズ
© KAKEHASHI Inc. カケハシの顧客ニーズの変化 医療情報システム向けに省庁が定める「3省2ガイドライン」は年々厳格化 エンタープライズ顧客を中心にガイドラインの厳格な遵守への期待が高まる 8 背景 監査ログ 患者の病歴などの個人情報が不正に持ち出されていないか
BCP (事業継続計画) 自然災害時・サイバーテロ時も業務を継続できるか 二要素認証 薬局の執務室はスマホの持ち込みが禁止の場合も多い セキュリティ コンプライアンス
© KAKEHASHI Inc. カケハシの従来の認証基盤 • AWS Cognito ユーザープールを使用 • 認証機能はプロダクトごとに開発・運用
9 ⋯ プロダクト 認証基盤 認証機能 認証機能 認証機能 プロダクトA プロダクトB プロダクトH Cognito API 主な責務はプロダクトへ 認証成功/失敗を返すのみ プロダクトごとに開発・運用 😥 • ログイン画面 • アカウント状態の検証 • 監査ログ • 二要素認証 • ディザスタリカバリ 背景
© KAKEHASHI Inc. カケハシの認証システムの課題 コンプライアンス & セキュリティ 顧客体験 プロダクトによってログイン画面が全く異なる
SSOを導入し顧客体験を統一したい 各プロダクトの開発者は認証の専門家ではない 運用負荷が高く、セキュリティ上の懸念も残る 運用負荷 10 大手薬局チェーンでも利用される医療システムとして 二要素認証・監査ログ・BCPなど高い品質が要求される 背景
カケハシの認証基盤 刷新プロジェクト 11
プロダクト運用負荷の低減 統一認証基盤が認証の関心事を 一手に引き受ける プロダクトチームは 本来の機能開発に集中できる 一貫した品質の提供 セキュリティ&コンプライアンス品質を 高い水準で全てのプロダクトへ 認証基盤の刷新 12
プロダクトA プロダクトB プロダクトH ⋯ 統一認証基盤 OAuth/OIDC 認証機能 認証機能 認証機能 下記を一任💪 • ログイン • アカウント状態の検証 • 監査ログ • 二要素認証 • BCP
© KAKEHASHI Inc. 認証基盤の刷新プロジェクト 1. 技術選定 Authleteを選んだ理由 2. アーキテクチャ AWSとAuthleteを利用した認可サーバーのシステム構成
3. 移行戦略 プロダクトチームとの連携 13
技術選定 Authleteを選んだ理由 14
© KAKEHASHI Inc. 新認証基盤の要件 15 医療SaaSでは「認証基盤の障害」は顧客業務と患者の生命に関わる 重要な要件 (優先度順) 移植性 認証基盤は事業継続の要である
OpenID Connectに基づき移植性を最大化する セキュリティ 患者の個人情報(要配慮個人情報)を扱うシステムとして必須 可用性 深夜・休日や災害時にも稼働し続ける必要がある 運用コスト カケハシの将来の事業状況に関わらず 半恒久的に小規模なチームで運用が可能 技術選定
統一認証基盤の運用負荷 16 多様化し続ける要件 統一認証基盤は OAuth/OIDCをサポートした上で 多様化する要件に応える必要がある OAuth/OIDC対応の外部化 ➡中長期運用を見据え OAuth/OIDC対応を外部化したい
• IDaaS (Identity as a Service) • BaaS (Backend as a Service) 統一認証基盤 BCP ログイン 監査ログ 二要素認証 SSO OAuth/OIDC プロダクトA プロダクトB プロダクトH ⋯ ⋯ 技術選定
© KAKEHASHI Inc. OAuth/OIDCプロバイダの完全内製の難しさ 17 現在だけでなく「数年後も運用し続けられるか?」という視点が重要 満たさない要件 運用コスト 初期開発時だけでなく運用時も、半恒久的に高度な対応が必要 •
RFCやプラクティスと照らし合わせながら改修 • 認可コード・トークンの適切な管理と破棄 • キーペアのローテーションなどを自前で管理 セキュリティ 各種攻撃手法を理解した上で 新しい仕様やプラクティスを追随する必要がある 技術選定
© KAKEHASHI Inc. IDaaS (Identity as a Service) の活用
18 IDaaSは認証の関心ごとをUI含め丸ごと提供するクラウドサービスの総称 丸ごと提供 UI 認証認可 サービス ユーザー情報 API グループ情報 技術選定 利点 必要なものが一通り揃っているため 認証機能の必要なプロダクトを ゼロから迅速に提供するには便利
既存システム IDaaS (Identity as a Service) の採用見送り 19 ②カスタマイズ性 独自のカスタマイズが必要な場合
柔軟性が一般的にBaaSより低い • 独自の認証方式の追加 例) 顧客のICカードによる認証 ①データベースの移行コスト 認証基盤とデータベースの同時移行は 時間を要する & 障害発生リスクが高い UI 認証認可 サービス ユーザー情報 API グループ情報 既存データの移行が必要 API依存の削除が必要 技術選定
© KAKEHASHI Inc. BaaS(Backend as a Service) の採用 自前実装やIDaaSではなくBaaSがユースケースにフィット
20 既存システム Authlete UI 認証認可 サービス API OAuth/OIDCの 継続的なサポートを 専門家へ委託 既存のデータや システムは そのまま活用 技術選定
© KAKEHASHI Inc. 高い専門性と継続的なサポート • OpenID Foundation (https://openid.net/certification/) より認証済み •
FAPIなど最新仕様の迅速なサポート • 日本語での充実した運用サポート 運用コストの低減 OAuth/OIDCを適切な粒度で抽象化 • トークン・認可コードの管理や鍵の管理が不要 • state・nonce・PKCEなどの実装や状態管理が不要 BaaSの中でもなぜAuthlete? 21 技術選定
アーキテクチャ AWSとAuthleteを利用した 認可サーバーのシステム構成 22
認証基盤システムの構成 23 以下の要素で構成 • Amazon ECS (Fargate) Remixで実装 •
Amazon DynamoDB セッション管理に利用 低い運用コストで高可用性 アクセスパターンが限定されている • Amazon Cognitoユーザープール 既存のデータをそのまま活用し シームレスな移行を実現 アーキテクチャ WAF CloudFront ALB S3 Cognito ユーザープール ECS (Fargate) DynamoDB Authlete Google Cloud - Authlete様管理 (カケハシ専用アカウント) AWS - カケハシ管理
© KAKEHASHI Inc. BCP (事業継続計画) 24 BCP(Business Continuity Plan) とは
自然災害・サイバーテロなどの危機に瀕した場合に 企業が中核となる業務を継続・早期復旧するための計画 介護や医療の領域で行政からBCPの策定が義務化 認証基盤の災害対策 (ディザスタリカバリ) [予定] • マルチリージョン化 • Authleteの災害対策機能の活用 アーキテクチャ
認証基盤(AWS)側 マルチリージョン化し 災害発生時にDNSの向き先を切替 Authlete(Google Cloud)側 Authleteが提供する災害対策機能は 災害時に自動でリージョンを切替 • 金融機関のオープン API
の信頼性を高める 災害対策機能を強化 - Authlete https://www.authlete.com/ja/news/20191 024_failover/ 災害対策: マルチリージョン構成による可用性の担保 [予定] 25 アーキテクチャ Authlete(Google Cloud) 東京リージョン 大阪リージョン 認証基盤(AWS) 東京リージョン 大阪リージョン DNS レプリケーション レプリケーション
課題: Cognitoユーザープールのバックアップ Cognitoユーザープールは パスワードなどの同期に非対応 • AWSのリファレンスアーキテクチャに 「機密情報は同期できない」と明記 • BCPの発動時はユーザーが
パスワードを再設定する必要がある 急がば回れ Authleteにより認証基盤を統一すれば 認証情報のデータ移行も視野に入る 26 アーキテクチャ 大阪リージョン 東京リージョン エクスポーター DynamoDB グローバル テーブル Cognito ユーザープール インポーター Cognito ユーザープール パスワードが エクスポートできない
27 移行戦略 認証基盤の移行のための プロダクトチームとの連携
© KAKEHASHI Inc. プロダクトチームとの連携における課題 28 移行時の課題 プロダクトチームから短期的に見れば... 移行のコスト > メリット
戦略的な移行支援のススメ 単に共通認証基盤を作るだけでは誰も使わないため 既存基盤から移行するための戦略も必要 ➡「プラットフォームエンジニアリング」のプラクティスを活用 移行戦略
© KAKEHASHI Inc. プラットフォームチームとして意識するサポート体制 プロダクトチームに寄り添って基盤の移行・導入支援を意識する必要がある 実際に実施中・実施予定のサポート • レビューよりも前に介入する ライブラリの選定や設計から積極的にコミットし伴走する •
参考実装と社内向けドキュメントの整備 開発ポータルを用意・提供 • アクティブサポート SlackでのQ&A対応 29 移行戦略
今後の展望 30
© KAKEHASHI Inc. 今後の展望 • 道半ばなので、1プロダクトずつ移行スケジュールを調整しながらできる限りサポー トをしていきます • プロダクトごとの要件に柔軟にサポートできるように継続的に共通基盤を改善して いく予定です
31