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

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

メルカリグループの認証基盤における、理想と現状、今後の取り組み / 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/

mercari
PRO

August 25, 2022
Tweet

More Decks by mercari

Other Decks in Technology

Transcript

  1. メルカリグループの認証基盤における理
    想と現状、今後の取り組み
    @kokukuma
    株式会社メルペイ Software Engineer(IDP)

    View Slide

  2. @kokukuma
    2019年頃から認証・認可をやり始める。楽しい。日々
    RFCを漁りつつ、メルカリのID関連の話題に首を突っ込
    んでいる。今後も暫くこの方向でやっていく予定。早く一人
    前になりたい。IDPチーム所属。
    株式会社メルペイ Software Engineer(IDP)

    View Slide

  3. IDPチームの目的
    メルカリグループのサービスに
    適切な認証・アクセス制御・Data Protectionを
    標準的な形で導入する

    View Slide

  4. 適切・標準的
    「適切な」の意味
    ● 認証 … 必要十分に強固な認証
    ● アクセス制御 … 最小権限の原則
    ● Data Protection … データの最小化/Unlinkability
    「標準的な」の理由
    ● 認証認可は、どのサービスでも使う基本的な機能。汎用性。
    ● 認証認可は、Security incidentに直結する重要な機能。安全性。

    View Slide

  5. メルカリグループのサービス分類

    View Slide

  6. 目次
    01 1st party Clientにおける認証
    02 Relying Partyへのアクセス制御・Data Protection
    03 Resource Serverへのアクセス制御・Data Protection

    View Slide

  7. 1st party Clientにおける認証

    View Slide

  8. どこの話か?

    View Slide

  9. 現状はどうなっているか?
    ログイン 追加認証

    View Slide

  10. 課題
    「適切な認証」を提供出来ているか?
    ● ユーザ体験の課題
    ○ 追加認証の発動条件が、ユーザフレンドリーではない
    ○ 何度も追加認証を要求される
    ● 認証強度の課題
    ○ 強い認証・phishing耐性がある認証を提供できてない
    ○ 将来的な攻撃の高度化に対応する必要がある

    View Slide

  11. 強い認証・phishing耐性がある認証 - FIDO
    好ましい特徴
    ● Phishing耐性がある認証要素
    ● ユーザフレンドリーな認証要素
    ● 標準化されている
    懸念すること
    ● FIDO鍵紛失時のリカバリにおける安全性・利便性
    ● 複数のFIDO鍵登録における安全性・利便性

    View Slide

  12. プロダクトそれぞれに合った柔軟な追加認証
    Context base Authentication Product毎の条件変更

    View Slide

  13. Relying Partyへの
    アクセス制御・Data Protection

    View Slide

  14. どこの話か?

    View Slide

  15. Server内のリクエストの流れ
    現状はどうなっているか?

    View Slide

  16. 現状はどうなっているか?
    メルカリの機能を使った新しいサービスの追加

    View Slide

  17. 「適切なData Protection」を提供できているか?
    ● Microservice向けのInterface / 外向けのInterface
    ● user_idが外部に対して露出する可能性がある
    「適切なアクセス制御」を提供できているか?
    ● 粒度が粗いアクセス制限 (Client/Gateway単位)
    ● 同じAPI GWを使おうとしたときに問題になる
    課題

    View Slide

  18. ● 不特定多数のRPが利用可能なAPIを提供する
    ● 外部向けAPIとして意識する
    共通のAPI
    利用可能なAPI Gateway/
    APIの制限
    内部のuser idの隠蔽
    利用可能なResourceの制限

    View Slide

  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 (未定)

    View Slide

  20. Resource Serverへの
    アクセス制御・Data Protection

    View Slide

  21. どこの話か?

    View Slide

  22. 現状はどうなっているか?
    Network Policyによる制限
    Service間認証による制限
    PATのClaimsによる制限
    Server内のアクセス制御

    View Slide

  23. 課題
    アクセス制限の粒度が細かすぎる
    Microservice向けの
    Interface
    同一のuser_id
    メルカリの機能を使った新しいサービスの追加

    View Slide

  24. ● 異なる内部トークン(JWT)を利用することで分離する
    Resource Serverの分離

    View Slide

  25. ● relying partyに提供している共有のAPIを使う
    ● 適切なアクセス制限・Data Protection
    Resource Server間での通信

    View Slide

  26. Resource Server間のuser_idの分離
    ● Client-Trust Domain/Trust Domain間の通信にはPPIDを利用
    ● 内部で利用するIDは、内部で発行し、外には出さない

    View Slide

  27. まとめ
    01 1st party Clientにおける認証
    02 Relying Partyへのアクセス制御・Data Protection
    03 Resource Serverへのアクセス制御・Data Protection

    View Slide

  28. View Slide