メルカリグループの認証基盤における、理想と現状、今後の取り組み / The Ideal and Actual Situation of Mercari Group’s Authentication Foundations and Our Future Initiatives

認証認可はどのサービスにおいても必要になる基本的な機能です。一方で、非常にクリティカルな機能であるために、より標準的・より汎用的に作ることで、どのProject・どのProduct Teamでも共通して利用できることが重要だと考えています。メルカリの認証基盤を管理するIDPチームでは、メルカリの関連サービスにおける認証認可を責務として持っており、いろいろなプロダクトチームに対して機能を提供しています。この発表では、現状がどういう仕組みになっていて、どのような問題があるのか、何を理想として、現在何をしようとしているのか、そのあたりを紹介しようと思います。
------
Merpay Tech Fest 2022は3日間のオンライン技術カンファレンスです。
IT企業で働くソフトウェアエンジニアおよびメルペイの技術スタックに興味がある方々を対象に2022年8月23日（火）から8月25日（木）までの3日間、開催します。 Merpay Tech Festは事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知れるお祭りです。 セッションでは事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介予定です。お楽しみに！

■イベント関連情報
- 公式ウェブサイト：https://events.merpay.com/techfest-2022/
- 申し込みページ：https://mercari.connpass.com/event/249428/
- Twitterハッシュタグ： #MerpayTechFest
■リンク集
- メルカリ・メルペイイベント一覧：https://mercari.connpass.com/
- メルカリキャリアサイト：https://careers.mercari.com/
- メルカリエンジニアリングブログ：https://engineering.mercari.com/blog/
- メルカリエンジニア向けTwitterアカウント：https://twitter.com/mercaridevjp
- 株式会社メルペイ：https://jp.merpay.com/

Transcript

1. メルカリグループの認証基盤における理 想と現状、今後の取り組み @kokukuma 株式会社メルペイ Software Engineer(IDP)
2. @kokukuma 2019年頃から認証・認可をやり始める。楽しい。日々 RFCを漁りつつ、メルカリのID関連の話題に首を突っ込 んでいる。今後も暫くこの方向でやっていく予定。早く一人 前になりたい。IDPチーム所属。 株式会社メルペイ Software Engineer(IDP)
3. IDPチームの目的 メルカリグループのサービスに 適切な認証・アクセス制御・Data Protectionを 標準的な形で導入する
4. 適切・標準的 「適切な」の意味 • 認証 … 必要十分に強固な認証 • アクセス制御 … 最小権限の原則 • Data Protection … データの最小化/Unlinkability 「標準的な」の理由 • 認証認可は、どのサービスでも使う基本的な機能。汎用性。 • 認証認可は、Security incidentに直結する重要な機能。安全性。
5. メルカリグループのサービス分類
6. 目次 01 1st party Clientにおける認証 02 Relying Partyへのアクセス制御・Data Protection 03 Resource Serverへのアクセス制御・Data Protection
7. 1st party Clientにおける認証
8. どこの話か？
9. 現状はどうなっているか？ ログイン 追加認証
10. 課題 「適切な認証」を提供出来ているか？ • ユーザ体験の課題 ◦ 追加認証の発動条件が、ユーザフレンドリーではない ◦ 何度も追加認証を要求される • 認証強度の課題 ◦ 強い認証・phishing耐性がある認証を提供できてない ◦ 将来的な攻撃の高度化に対応する必要がある
11. 強い認証・phishing耐性がある認証 - FIDO 好ましい特徴 • Phishing耐性がある認証要素 • ユーザフレンドリーな認証要素 • 標準化されている 懸念すること • FIDO鍵紛失時のリカバリにおける安全性・利便性 • 複数のFIDO鍵登録における安全性・利便性
12. プロダクトそれぞれに合った柔軟な追加認証 Context base Authentication Product毎の条件変更
13. Relying Partyへの アクセス制御・Data Protection
14. どこの話か？
15. Server内のリクエストの流れ 現状はどうなっているか？
16. 現状はどうなっているか？ メルカリの機能を使った新しいサービスの追加
17. 「適切なData Protection」を提供できているか？ • Microservice向けのInterface / 外向けのInterface • user_idが外部に対して露出する可能性がある 「適切なアクセス制御」を提供できているか？ • 粒度が粗いアクセス制限 (Client/Gateway単位) • 同じAPI GWを使おうとしたときに問題になる 課題
18. • 不特定多数のRPが利用可能なAPIを提供する • 外部向けAPIとして意識する 共通のAPI 利用可能なAPI Gateway/ APIの制限 内部のuser idの隠蔽 利用可能なResourceの制限
19. IDPチームとして提供すること 利用可能なAPI Gateway/APIの制限 • Audience(for GW制限)、Scope(for API制限)の付与方法 • 各API - Scopeの定義方法(GWに閉じた形式) 内部のuser idの隠蔽 • 内部のuser_idとPPID(pairwise pseudonymous identifier)の変換 利用可能なResourceの制限 • 定義したScopeのMicroserviceまでPropagate • GW/Authority上でresponseをfiltering (未定)
20. Resource Serverへの アクセス制御・Data Protection
21. どこの話か？
22. 現状はどうなっているか？ Network Policyによる制限 Service間認証による制限 PATのClaimsによる制限 Server内のアクセス制御
23. 課題 アクセス制限の粒度が細かすぎる Microservice向けの Interface 同一のuser_id メルカリの機能を使った新しいサービスの追加
24. • 異なる内部トークン(JWT)を利用することで分離する Resource Serverの分離
25. • relying partyに提供している共有のAPIを使う • 適切なアクセス制限・Data Protection Resource Server間での通信
26. Resource Server間のuser_idの分離 • Client-Trust Domain/Trust Domain間の通信にはPPIDを利用 • 内部で利用するIDは、内部で発行し、外には出さない
27. まとめ 01 1st party Clientにおける認証 02 Relying Partyへのアクセス制御・Data Protection 03 Resource Serverへのアクセス制御・Data Protection