Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

kakehashi
October 30, 2024

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

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

kakehashi

October 30, 2024
Tweet

More Decks by kakehashi

Other Decks in Technology

Transcript

  1. © KAKEHASHI Inc. 目次 • カケハシのビジネスと顧客要求の変化 • カケハシの認証基盤とその課題 • カケハシの認証基盤刷新プロジェクト

    ◦ 技術選定 Authleteを選んだ理由 ◦ システム構成 AWSとAuthleteを利用した認可サーバー ◦ 移行戦略 プロダクトチームとの連携 • 今後の展望 5
  2. © KAKEHASHI Inc. カケハシのビジネスの変化 薬局向けSaaSから「多様な顧客と協業する多面的な医療プラットフォーム」へ 機能・品質の両面で顧客のニーズが高度化 7 背景 マルチプロダクト SaaS

    創業期 成長期 転換期 単一プロダクト SaaS 中堅・中小企業に加え 大手薬局チェーン 中堅・中小企業 全国の薬局に加え 製薬企業・医薬品卸 など 多面的 プラットフォーム プロダクト 顧客 フェーズ
  3. © KAKEHASHI Inc. カケハシの従来の認証基盤 • AWS Cognito ユーザープールを使用 • 認証機能はプロダクトごとに開発・運用

    9 ⋯ プロダクト 認証基盤 認証機能 認証機能 認証機能 プロダクトA プロダクトB プロダクトH Cognito API 主な責務はプロダクトへ 認証成功/失敗を返すのみ プロダクトごとに開発・運用 • ログイン画面 • アカウント状態の検証 • 監査ログ • 二要素認証 • ディザスタリカバリ 背景
  4. © KAKEHASHI Inc. カケハシの認証システムの課題 コンプライアンス & セキュリティ 顧客体験 プロダクトによってログイン画面が全く異なる SSOを導入し顧客体験を統一したい

    各プロダクトの開発者は認証の専門家ではない 運用負荷が高く、セキュリティ上の懸念も残る 運用負荷 10 大手薬局チェーンでも利用される医療システムとして 二要素認証・監査ログ・BCPなど高い品質が要求される 背景
  5. プロダクト運用負荷の低減 統一認証基盤が認証の関心事を 一手に引き受ける プロダクトチームは 本来の機能開発に集中できる 一貫した品質の提供 セキュリティ&コンプライアンス品質を 高い水準で全てのプロダクトへ 認証基盤の刷新 12

    プロダクトA プロダクトB プロダクトH ⋯ 統一認証基盤 OAuth/OIDC 認証機能 認証機能 認証機能 下記を一任 • ログイン • アカウント状態の検証 • 監査ログ • 二要素認証 • BCP
  6. © KAKEHASHI Inc. 新認証基盤の要件 15 医療SaaSでは「認証基盤の障害」は顧客業務と患者の生命に関わる 重要な要件 (優先度順) 移植性 認証基盤は事業継続の要である

    OpenID Connectに基づき移植性を最大化する セキュリティ 患者の個人情報(要配慮個人情報)を扱うシステムとして必須 可用性 深夜・休日や災害時にも稼働し続ける必要がある 運用コスト カケハシの将来の事業状況に関わらず 半恒久的に小規模なチームで運用が可能 技術選定
  7. 統一認証基盤の運用負荷 16 多様化し続ける要件 統一認証基盤は OAuth/OIDCをサポートした上で 多様化する要件に応える必要がある OAuth/OIDC対応の外部化 中長期運用を見据え OAuth/OIDC対応を外部化したい •

    IDaaS (Identity as a Service) • BaaS (Backend as a Service) 統一認証基盤 BCP ログイン 監査ログ 二要素認証 SSO OAuth/OIDC プロダクトA プロダクトB プロダクトH ⋯ ⋯ 技術選定
  8. © KAKEHASHI Inc. OAuth/OIDCプロバイダの完全内製の難しさ 17 現在だけでなく「数年後も運用し続けられるか?」という視点が重要 満たさない要件 運用コスト 初期開発時だけでなく運用時も、半恒久的に高度な対応が必要 •

    RFCやプラクティスと照らし合わせながら改修 • 認可コード・トークンの適切な管理と破棄 • キーペアのローテーションなどを自前で管理 セキュリティ 各種攻撃手法を理解した上で 新しい仕様やプラクティスを追随する必要がある 技術選定
  9. © KAKEHASHI Inc. IDaaS (Identity as a Service) の活用 18

    IDaaSは認証の関心ごとをUI含め丸ごと提供するクラウドサービスの総称 丸ごと提供 UI 認証認可 サービス ユーザー情報 API グループ情報 技術選定 利点 必要なものが一通り揃っているため 認証機能の必要なプロダクトを ゼロから迅速に提供するには便利
  10. 既存システム IDaaS (Identity as a Service) の採用見送り 19 ②カスタマイズ性 独自のカスタマイズが必要な場合

    柔軟性が一般的にBaaSより低い • 独自の認証方式の追加 例) 顧客のICカードによる認証 ①データベースの移行コスト 認証基盤とデータベースの同時移行は 時間を要する & 障害発生リスクが高い UI 認証認可 サービス ユーザー情報 API グループ情報 既存データの移行が必要 API依存の削除が必要 技術選定
  11. © KAKEHASHI Inc. BaaS(Backend as a Service) の採用 自前実装やIDaaSではなくBaaSがユースケースにフィット 20

    既存システム Authlete UI 認証認可 サービス API OAuth/OIDCの 継続的なサポートを 専門家へ委託 既存のデータや システムは そのまま活用 技術選定
  12. © KAKEHASHI Inc. 高い専門性と継続的なサポート • OpenID Foundation (https://openid.net/certification/) より認証済み •

    FAPIなど最新仕様の迅速なサポート • 日本語での充実した運用サポート 運用コストの低減 OAuth/OIDCを適切な粒度で抽象化 • トークン・認可コードの管理や鍵の管理が不要 • state・nonce・PKCEなどの実装や状態管理が不要 BaaSの中でもなぜAuthlete? 21 技術選定
  13. 認証基盤システムの構成 23 以下の要素で構成 • Amazon ECS (Fargate) Remixで実装 • Amazon

    DynamoDB セッション管理に利用 低い運用コストで高可用性 アクセスパターンが限定されている • Amazon Cognitoユーザープール 既存のデータをそのまま活用し シームレスな移行を実現 アーキテクチャ WAF CloudFront ALB S3 Cognito ユーザープー ル ECS (Fargate) DynamoDB Authlete Google Cloud - Authlete様管理 (カケハシ専用アカウント) AWS - カケハシ管理
  14. © KAKEHASHI Inc. BCP (事業継続計画) 24 BCP(Business Continuity Plan) とは

    自然災害・サイバーテロなどの危機に瀕した場合に 企業が中核となる業務を継続・早期復旧するための計画 介護や医療の領域で行政からBCPの策定が義務化 認証基盤の災害対策 (ディザスタリカバリ) [予定] • マルチリージョン化 • Authleteの災害対策機能の活用 アーキテクチャ
  15. 認証基盤(AWS)側 マルチリージョン化し 災害発生時にDNSの向き先を切替 Authlete(Google Cloud)側 Authleteが提供する災害対策機能は 災害時に自動でリージョンを切替 • 金融機関のオープン API

    の信頼性を高める 災害対策機能を強化 - Authlete https://www.authlete.com/ja/news/20191 024_failover/ 災害対策: マルチリージョン構成による可用性の担保 [予定] 25 アーキテクチャ Authlete(Google Cloud) 東京リージョン 大阪リージョン 認証基盤(AWS) 東京リージョン 大阪リージョン DNS レプリケーション レプリケーション
  16. 課題: Cognitoユーザープールのバックアップ Cognitoユーザープールは パスワードなどの同期に非対応 • AWSのリファレンスアーキテクチャに 「機密情報は同期できない」と明記 • BCPの発動時はユーザーが パスワードを再設定する必要がある

    急がば回れ Authleteにより認証基盤を統一すれば 認証情報のデータ移行も視野に入る 26 アーキテクチャ 大阪リージョン 東京リージョン エクスポーター DynamoDB グローバル テーブル Cognito ユーザープール インポーター Cognito ユーザープール パスワードが エクスポートできない
  17. © KAKEHASHI Inc. プロダクトチームとの連携における課題 28 移行時の課題 プロダクトチームから短期的に見れば... 移行のコスト > メリット

    戦略的な移行支援のススメ 単に共通認証基盤を作るだけでは誰も使わないため 既存基盤から移行するための戦略も必要 「プラットフォームエンジニアリング」のプラクティスを活用 移行戦略