プロダクト成長に対応するプラットフォーム戦略:Authleteによる共通認証基盤の移行事例 / Building an authentication platform using Authlete and AWS

OAuth & OpenID Connect 勉強会 ー 認可サーバーの作りかた（AWS編）
https://authlete.connpass.com/event/333513/
での登壇資料です

Transcript

1. プロダクト成長に対応するプラットフォーム戦略: Authleteによる共通認証基盤の移行事例 2024/10/30 OAuth & OpenID Connect 勉強会 ー 認可サーバーの作りかた（AWS編）
 1
2. © KAKEHASHI Inc.
 自己紹介 
 2 岩佐 幸翠 (@kosui_me) 2019年にエンジニアとしてのキャリアを開始し、認証認可基盤の開発に従事。 2022年に カケハシへ入社し、社内プラットフォームの開発を担う。 
 すてにゃん (@stefafafan) 2024年にカケハシへ入社し、プラットフォームチームのテックリードを引き継ぐ。 

3. © KAKEHASHI Inc.
 カケハシのビジョン 明日の医療の基盤となる、エコシステムの実現。 3 患者さん 薬局 医薬品発注・管理最適化
4. © KAKEHASHI Inc.
 カケハシのマルチプロダクトSaaS
 
 4
5. © KAKEHASHI Inc.
 目次 • カケハシのビジネスと顧客要求の変化
 • カケハシの認証基盤とその課題
 • カケハシの認証基盤刷新プロジェクト
 ◦ 技術選定
 Authleteを選んだ理由
 ◦ システム構成
 AWSとAuthleteを利用した認可サーバー 
 ◦ 移行戦略
 プロダクトチームとの連携 
 • 今後の展望
 5
6. カケハシのビジネスと 顧客要求の変化 6
7. © KAKEHASHI Inc.
 カケハシのビジネスの変化 薬局向けSaaSから「多様な顧客と協業する多面的な医療プラットフォーム」へ
 ▶ 機能・品質の両面で顧客のニーズが高度化
 7 背景 マルチプロダクト SaaS 創業期 成長期 転換期 単一プロダクト SaaS 中堅・中小企業に加え 大手薬局チェーン 中堅・中小企業 全国の薬局に加え 製薬企業・医薬品卸 など 多面的 プラットフォーム プロダクト 顧客 フェーズ
8. © KAKEHASHI Inc.
 カケハシの顧客ニーズの変化 医療情報システム向けに省庁が定める「3省2ガイドライン」は年々厳格化
 エンタープライズ顧客を中心にガイドラインの厳格な遵守への期待が高まる
 8 背景 監査ログ 患者の病歴などの個人情報が不正に持ち出されていないか
 BCP (事業継続計画)
 自然災害時・サイバーテロ時も業務を継続できるか
 二要素認証 薬局の執務室はスマホの持ち込みが禁止の場合も多い
 セキュリティ コンプライアンス
9. © KAKEHASHI Inc.
 カケハシの従来の認証基盤 • AWS Cognito ユーザープールを使用
 • 認証機能はプロダクトごとに開発・運用
 9 ⋯ プロダクト
 認証基盤
 認証機能
 認証機能
 認証機能
 プロダクトA
 プロダクトB
 プロダクトH
 Cognito API
 主な責務はプロダクトへ 
 認証成功/失敗を返すのみ
 プロダクトごとに開発・運用 😥
 • ログイン画面
 • アカウント状態の検証 
 • 監査ログ
 • 二要素認証
 • ディザスタリカバリ
 背景
10. © KAKEHASHI Inc.
 
 カケハシの認証システムの課題 コンプライアンス
 & セキュリティ
 顧客体験
 プロダクトによってログイン画面が全く異なる
 SSOを導入し顧客体験を統一したい
 各プロダクトの開発者は認証の専門家ではない
 運用負荷が高く、セキュリティ上の懸念も残る
 運用負荷
 10 大手薬局チェーンでも利用される医療システムとして
 二要素認証・監査ログ・BCPなど高い品質が要求される
 背景
11. カケハシの認証基盤 刷新プロジェクト 11
12. プロダクト運用負荷の低減 統一認証基盤が認証の関心事を
 一手に引き受ける
 プロダクトチームは
 本来の機能開発に集中できる
 一貫した品質の提供 セキュリティ&コンプライアンス品質を
 高い水準で全てのプロダクトへ
 認証基盤の刷新 12 
 プロダクトA
 プロダクトB
 プロダクトH
 ⋯ 統一認証基盤 OAuth/OIDC
 認証機能
 認証機能
 認証機能
 下記を一任💪
 • ログイン
 • アカウント状態の検証 
 • 監査ログ
 • 二要素認証
 • BCP

13. © KAKEHASHI Inc.
 認証基盤の刷新プロジェクト 1. 技術選定
 Authleteを選んだ理由
 2. アーキテクチャ
 AWSとAuthleteを利用した認可サーバーのシステム構成
 3. 移行戦略
 プロダクトチームとの連携
 
 13
14. 技術選定 Authleteを選んだ理由
 14
15. © KAKEHASHI Inc.
 新認証基盤の要件 15 医療SaaSでは「認証基盤の障害」は顧客業務と患者の生命に関わる
 重要な要件 (優先度順)
 移植性 認証基盤は事業継続の要である
 OpenID Connectに基づき移植性を最大化する
 セキュリティ 患者の個人情報(要配慮個人情報)を扱うシステムとして必須
 可用性 深夜・休日や災害時にも稼働し続ける必要がある
 運用コスト カケハシの将来の事業状況に関わらず
 半恒久的に小規模なチームで運用が可能
 技術選定
16. 統一認証基盤の運用負荷 16 
 多様化し続ける要件 統一認証基盤は
 OAuth/OIDCをサポートした上で
 多様化する要件に応える必要がある
 OAuth/OIDC対応の外部化 ➡中長期運用を見据え
 OAuth/OIDC対応を外部化したい
 • IDaaS (Identity as a Service)
 • BaaS (Backend as a Service)
 統一認証基盤 BCP
 ログイン 監査ログ 二要素認証 SSO
 OAuth/OIDC
 プロダクトA
 プロダクトB
 プロダクトH
 ⋯ ⋯ 技術選定
17. © KAKEHASHI Inc.
 OAuth/OIDCプロバイダの完全内製の難しさ 17 現在だけでなく「数年後も運用し続けられるか？」という視点が重要
 満たさない要件 運用コスト 初期開発時だけでなく運用時も、半恒久的に高度な対応が必要
 • RFCやプラクティスと照らし合わせながら改修
 • 認可コード・トークンの適切な管理と破棄
 • キーペアのローテーションなどを自前で管理
 セキュリティ 各種攻撃手法を理解した上で
 新しい仕様やプラクティスを追随する必要がある
 技術選定
18. © KAKEHASHI Inc.
 
 IDaaS (Identity as a Service) の活用 18 IDaaSは認証の関心ごとをUI含め丸ごと提供するクラウドサービスの総称
 丸ごと提供 UI
 認証認可
 サービス
 ユーザー情報
 API
 グループ情報
 技術選定 利点 必要なものが一通り揃っているため
 認証機能の必要なプロダクトを
 ゼロから迅速に提供するには便利

19. 既存システム
 IDaaS (Identity as a Service) の採用見送り 19 ②カスタマイズ性 独自のカスタマイズが必要な場合
 柔軟性が一般的にBaaSより低い
 • 独自の認証方式の追加
 例) 顧客のICカードによる認証
 
 ①データベースの移行コスト 認証基盤とデータベースの同時移行は
 時間を要する & 障害発生リスクが高い
 UI
 認証認可
 サービス
 ユーザー情報
 API
 グループ情報
 既存データの移行が必要
 API依存の削除が必要
 技術選定
20. © KAKEHASHI Inc.
 BaaS(Backend as a Service) の採用 自前実装やIDaaSではなくBaaSがユースケースにフィット
 
 20 既存システム
 Authlete
 UI
 認証認可
 サービス
 API
 OAuth/OIDCの
 継続的なサポートを 
 専門家へ委託
 既存のデータや
 システムは
 そのまま活用
 技術選定
21. © KAKEHASHI Inc.
 高い専門性と継続的なサポート • OpenID Foundation (https://openid.net/certification/) より認証済み
 • FAPIなど最新仕様の迅速なサポート
 • 日本語での充実した運用サポート
 運用コストの低減 OAuth/OIDCを適切な粒度で抽象化
 • トークン・認可コードの管理や鍵の管理が不要
 • state・nonce・PKCEなどの実装や状態管理が不要
 BaaSの中でもなぜAuthlete？ 21 技術選定
22. アーキテクチャ AWSとAuthleteを利用した
 認可サーバーのシステム構成
 22
23. 
 認証基盤システムの構成 23 以下の要素で構成
 • Amazon ECS (Fargate)
 Remixで実装
 • Amazon DynamoDB
 セッション管理に利用
 低い運用コストで高可用性
 アクセスパターンが限定されている
 • Amazon Cognitoユーザープール 既存のデータをそのまま活用し
 シームレスな移行を実現
 アーキテクチャ WAF
 CloudFront
 ALB
 S3
 Cognito
 ユーザープール
 ECS (Fargate)
 DynamoDB
 Authlete
 Google Cloud - Authlete様管理
 (カケハシ専用アカウント) AWS - カケハシ管理
24. © KAKEHASHI Inc.
 BCP (事業継続計画)
 24 BCP(Business Continuity Plan) とは 自然災害・サイバーテロなどの危機に瀕した場合に
 企業が中核となる業務を継続・早期復旧するための計画
 介護や医療の領域で行政からBCPの策定が義務化
 認証基盤の災害対策 (ディザスタリカバリ) [予定]
 • マルチリージョン化
 • Authleteの災害対策機能の活用
 アーキテクチャ
25. 認証基盤(AWS)側
 マルチリージョン化し
 災害発生時にDNSの向き先を切替
 Authlete(Google Cloud)側 Authleteが提供する災害対策機能は
 災害時に自動でリージョンを切替
 • 金融機関のオープン API の信頼性を高める 災害対策機能を強化 - Authlete https://www.authlete.com/ja/news/20191 024_failover/ 
 災害対策: マルチリージョン構成による可用性の担保 [予定] 25 アーキテクチャ Authlete(Google Cloud)
 東京リージョン 大阪リージョン 認証基盤(AWS)
 東京リージョン 大阪リージョン DNS
 レプリケーション レプリケーション
26. 課題: Cognitoユーザープールのバックアップ Cognitoユーザープールは
 パスワードなどの同期に非対応
 • AWSのリファレンスアーキテクチャに
 「機密情報は同期できない」と明記 
 • BCPの発動時はユーザーが
 パスワードを再設定する必要がある 
 急がば回れ Authleteにより認証基盤を統一すれば
 認証情報のデータ移行も視野に入る
 26 アーキテクチャ 大阪リージョン 東京リージョン エクスポーター
 DynamoDB
 グローバル
 テーブル
 Cognito
 ユーザープール
 インポーター
 Cognito
 ユーザープール
 パスワードが
 エクスポートできない 

27. 27 移行戦略 認証基盤の移行のための
 プロダクトチームとの連携

28. © KAKEHASHI Inc.
 プロダクトチームとの連携における課題 28 移行時の課題 プロダクトチームから短期的に見れば... 移行のコスト > メリット 戦略的な移行支援のススメ 単に共通認証基盤を作るだけでは誰も使わないため
 既存基盤から移行するための戦略も必要
 ➡「プラットフォームエンジニアリング」のプラクティスを活用
 移行戦略
29. © KAKEHASHI Inc.
 プラットフォームチームとして意識するサポート体制 プロダクトチームに寄り添って基盤の移行・導入支援を意識する必要がある
 実際に実施中・実施予定のサポート • レビューよりも前に介入する
 ライブラリの選定や設計から積極的にコミットし伴走する
 • 参考実装と社内向けドキュメントの整備
 開発ポータルを用意・提供
 • アクティブサポート
 SlackでのQ&A対応
 29 移行戦略
30. 今後の展望 30
31. © KAKEHASHI Inc.
 今後の展望 • 道半ばなので、1プロダクトずつ移行スケジュールを調整しながらできる限りサポー トをしていきます
 • プロダクトごとの要件に柔軟にサポートできるように継続的に共通基盤を改善して いく予定です
 31