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
October 30, 2024
Technology
1
220
プロダクト成長に対応するプラットフォーム戦略:Authleteによる共通認証基盤の移行事例 / Building an authentication platform using Authlete and AWS
OAuth & OpenID Connect 勉強会 ー 認可サーバーの作りかた(AWS編)
https://authlete.connpass.com/event/333513/
での登壇資料です
kakehashi
October 30, 2024
Tweet
Share
More Decks by kakehashi
See All by kakehashi
適材適所の技術選定 〜GraphQL・REST API・tRPC〜 / Optimal Technology Selection
kakehashi
1
160
誰も全体を知らない ~ ロールの垣根を超えて引き上げる開発生産性 / Boosting Development Productivity Across Roles
kakehashi
1
220
スプリントゴールにチームの状態も設定する背景とその効果 / Team state in sprint goals why and impact
kakehashi
2
150
見えづらい活動の成果の伝え方は日頃からめちゃくちゃ悩んでるけど、実際こんな取り組みをしな がら温度感を合わせにいってるよ / Conveying Hard-to-See Results
kakehashi
4
2.3k
Evolving DevOps Teams and Flexible Organizational Culture
kakehashi
1
1.3k
難しいから面白い!医薬品×在庫管理ドメインの複雑性と向き合い、プロダクトの成長を支えるための取り組み / Initiatives to Support Product Growth
kakehashi
3
300
日本の医療システムの再構築を目指すスタートアップ「カケハシ」のフロントエンド領域でのチャレンジ / Challenges in the frontend domain at “Kakehashi”
kakehashi
3
2.3k
そのデータ連携、ホントにそれでいいの? 〜データモデル分析の重要性を説く〜 / How to analyse data integration
kakehashi
2
770
プロポーザル出しまくり芸人が教える、プロポーザルを採択してもらう技術 / Techniques for Getting Proposal Accepted
kakehashi
7
11k
Other Decks in Technology
See All in Technology
強いチームと開発生産性
onk
PRO
33
11k
信頼性に挑む中で拡張できる・得られる1人のスキルセットとは?
ken5scal
2
530
Security-JAWS【第35回】勉強会クラウドにおけるマルウェアやコンテンツ改ざんへの対策
4su_para
0
170
【Pycon mini 東海 2024】Google Colaboratoryで試すVLM
kazuhitotakahashi
2
490
Why does continuous profiling matter to developers? #appdevelopercon
salaboy
0
180
TypeScriptの次なる大進化なるか!? 条件型を返り値とする関数の型推論
uhyo
2
1.6k
[CV勉強会@関東 ECCV2024 読み会] オンラインマッピング x トラッキング MapTracker: Tracking with Strided Memory Fusion for Consistent Vector HD Mapping (Chen+, ECCV24)
abemii
0
220
第1回 国土交通省 データコンペ参加者向け勉強会③- Snowflake x estie編 -
estie
0
120
Why App Signing Matters for Your Android Apps - Android Bangkok Conference 2024
akexorcist
0
120
ノーコードデータ分析ツールで体験する時系列データ分析超入門
negi111111
0
410
New Relicを活用したSREの最初のステップ / NRUG OKINAWA VOL.3
isaoshimizu
2
580
VideoMamba: State Space Model for Efficient Video Understanding
chou500
0
190
Featured
See All Featured
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
What's in a price? How to price your products and services
michaelherold
243
12k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
24k
Designing the Hi-DPI Web
ddemaree
280
34k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Bash Introduction
62gerente
608
210k
Happy Clients
brianwarren
98
6.7k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Designing Experiences People Love
moore
138
23k
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