Successfully reported this slideshow.
Your SlideShare is downloading. ×

金融APIセキュリティの動向・事例と今後の方向性

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 44 Ad
Advertisement

More Related Content

More from Tatsuo Kudo (20)

Recently uploaded (20)

Advertisement

金融APIセキュリティの動向・事例と今後の方向性

  1. 1. 金融APIセキュリティの動向・事例と 今後の方向性 工藤達雄 Authlete, Inc.
  2. 2. 2 • 「オープンAPI」の現在 • FAPI&CIBA: 注目すべき技術標準 • 国内外の事例 • 進化するアイデンティティアーキテクチャ Agenda
  3. 3. 3 • サン・マイクロシステムズ、 野村総合研究所、NRI セキュアを 経て、2018年 Authlete に入社 • デジタルアイデンティティを 中心とするプリセールス・ コンサルティング・事業開発・ エバンジェリズムに従事 About Me
  4. 4. 「オープンAPI」の現在
  5. 5. • 例: 銀行 – 「オープンデータ」の提供 • 支店の住所情報など – コア機能のホワイトレーベル提供 • “Bank as a Service” – お客さまに関わるデータ・機能の 提供 • 口座情報・契約情報・取引履歴な どのデータ、取引の実行機能など 金融サービスにおける「オープンAPI」とは 約2.5万API中、Bankingカテゴリに登録されているのは607種類 Source:https://www.programmableweb.com/category/banking 5
  6. 6. 6 • APIとして提供された 金融機能 (finance) が 事業者のサービスに 埋め込まれる (embedded) – 「保険機能」が 「ECサイト」に – 「ローン機能」が 「高価な買い物」に – 「送金機能」が 「B2B SaaS事業者」に オープンAPIが実現する “Embedded Finance” Source:三井物産戦略研究所 https://www.mitsui.com/mgssi/ja/report/detail/__icsFiles/afieldfile/2021/03/16/2103i_onishi.pdf
  7. 7. 7 Embedded Finance エコシステムの例 Source:NTTデータ経営研究所 https://www.meti.go.jp/meti_lib/report/2021FY/000116.pdf
  8. 8. 8 • 国内のほぼすべての銀行がAPIを準備済み – ほとんどの銀行がAPIまたは暫定スクレイピング契約締結 済み(2020年9月末時点) – 約8割の銀行がAPI提供中もしくは準備段階(2021年度) • しかしサードパーティからのAPI接続は低調 (2020年9月 末時点) – 88電代業者中、APIまたは暫定スクレイピング契約締結済 みは39社(約45%) – 契約締結済みであっても、1~2銀行としか締結していない 電代業者が過半数 • 更新系APIの提供は限定的(2021年度) – 提供中と回答した金融機関は個人更新系は全体の10.1%、 法人更新系は7.1% 国内のオープンAPIは “Embeddable” か? Source:金融庁 https://www.fsa.go.jp/status/keiyakujoukyou_api/index.html, FISC https://www.fisc.or.jp/document/fintech/file/FinTech_20220225_05.pdf
  9. 9. 9 現時点では「機能」と「チャネル」が不足 機能 チャネル Embedded Finance • 参照系中心 • オンライン限定
  10. 10. 10 「更新系」と「オフライン」 機能 チャネル Embedded Finance • 参照系中心 • オンライン限定 更新系の拡充 オフラインへの拡大
  11. 11. 11 セキュリティの “FAPI” とモバイルの “CIBA” 機能 チャネル Embedded Finance FAPI Financial-grade API 高付加価値APIに必要な セキュリティ基準 CIBA Client Initiated Backchannel Authentication モバイルによるオンライン・ オフラインの融合
  12. 12. FAPI&CIBA: 注目すべき技術標準
  13. 13. 13 • アクセストークンによる API 認可 – ユーザーのID/パスワードや “APIキー” の流出を防止 • エンドユーザーによる同意確 認 – ユーザーがクライアントにアク セス範囲・期限を許諾 • ”OpenID Connect” への拡張 – API認可とID連携を同時に処理 APIセキュリティに欠かせない “OAuth 2.0” エンドユーザー API サーバー API クライアント 4. アクセストークン を含むAPIリクエスト 3. アクセス トークンを 発行 2. ユーザー認証と APIアクセス認可 1. 認可プロセス開始
  14. 14. 14 • オープンAPIのあり方に関する検討会報告書 (2017年7月13日) https://www.zenginkyo.or.jp/abstract/council/openapi/ – “「認可プロトコル」として、OAuth2.0 認可フレームワーク(以下「OAuth2.0」 という。)を推奨する。なお、金融分野における API への OAuth2.0 の適用に 関する詳細仕様は、2017 年6月現在、OpenID Foundation Financial API WG(FAPI WG)において、セキュリティ水準を確保する観点から、標準化作業が実施さ れている。同団体で OAuth2.0 適用の詳細仕様が発行された際には、各銀行にお いて同仕様への準拠や準拠に向けた方針等が検討されることが望ましい。” • 金融機関とAPI接続先のためのAPI接続チェックリスト(2019年9月27日一部改訂) https://www.fisc.or.jp/document/fintech/004194.php – “通番 36: 認証認可に関する機密情報の漏洩対策を実施する。[…] 本項目に関連して 実施する手法例は、以下が考えられる。<トークンの適切な管理>1.利用する API のセキュリティリスクに応じた適切なトークンの管理を実施している。 […]” – “通番 37: API の想定外利用を回避する。 […] 利用する API の範囲や、取得するトー クンによって実現できる機能を理解している。 […] OAuth2.0の仕組みを理解してお り、それに関連する項目の意味を説明することができる。” OAuth 2.0の利用を全銀協やFISCが推奨・前提化
  15. 15. 15 • 高いセキュリティが求められる(”金融グレード” の) API向けのOAuth 2.0詳細仕様 – アクセストークンの授受・利用にかかるセキュリティ対策を 標準化 – 2021年3月にFAPIバージョン1が確定 • 金融機関における FAPI 採用の利点 – 独自詳細仕様の開発・運用に費やすコストの削減 – 高度な OAuth 2.0 セキュリティの担保 – FAPI 実装の「認定プログラム」を活用可能 • FAPI 準拠の有無をソフトウェア調達にて評価 • 認定テストスイートを用いて自行の FAPI 実装を継続的にテスト し、機能低下(デグレ)を防止 FAPI (ファピ)
  16. 16. FAPI による不正なトークン授受・利用の防止 Fintech事業者 攻撃者 金融機関 OAuth2 アクセス認可リクエスト 認可レスポンス・トークン付与 トークン付きAPIリクエスト(参照・更新) r電子署名により真正性を担保し 不正なトークン授受を防止 トークン窃取 相互TLSにより リクエスト送信者を特定し トークンの不正利用を防止 窃取したトークンを用いた 「なりすましアクセス」を 検知しリクエストを拒否 16
  17. 17. 17 • さまざまな局面でのユーザー認証・同意確認を 「金融機関公式モバイルアプリ」を用いて直接実施 するためのサービス連携のしくみ CIBA (シーバ)
  18. 18. デバイス 従来の一般的な認証・認可フロー 2つのサービスが、ユーザー起点で、ブラウザのリダイレクトによって連携する Source: HubSpot and Google API ブラウザ API クライアント 認証・認可 / API サーバー 18 1. サービス利用試行 2. 認証・認可 リクエスト 3. ログイン ユーザー
  19. 19. デバイスを “API利用側” と ”認証・認可側” に分離 「ブラウザのリダイレクト」が無くなり、分離されたデバイス同士は直接連携しない 1. サービス利用試行 2. 認証・認可 リクエスト API クライアント スマート スピーカー スマート フォン ユーザー 認証・認可 / API サーバー 太郎さんに 5,000円 送金して 3. 銀行Appにて ユーザー認証・ 取引承認 19 デバイスを分離
  20. 20. デバイス デバイス ユーザーが所有しないデバイスと連携 ショッピングセンターのPOS端末に会員証をかざすと、ユーザーの手元の銀行Appが取引承認を求める POS端末 1. サービス利用試行 2. 認証・認可 リクエスト API クライアント 認証・認可 / API サーバー 3. 銀行Appにて ユーザー認証・ 取引承認 ユーザー 会員証 提示 お支払合計 ¥1,234 20 スマート フォン
  21. 21. ユーザー以外の誰かがサービスを利用 コールセンターのオペレーターに購入を伝えると(カード情報等は教えない)、ユーザーの手元の銀行Appが取引承認を求める コールセンター端末 テレフォン オペレーター 1. サービス利用試行 2. 認証・認可 リクエスト API クライアント 認証・認可 / API サーバー 3. 銀行Appにて ユーザー認証・ 取引承認 スマート フォン ユーザー TVショッピングを 観て購入の電話 21
  22. 22. 22 • 金融機関自らが確実にユーザー認証・認可を実施 – サードパーティではなく「銀行公式アプリ」を使用するため、金融グレードの認証・認可ができる • オフラインとオンラインを融合 – さらに、オフライン側のデバイスやそれを操作する人間はエンドユーザーから離れていても良い セキュリティを担保しつつ適用分野を拡大 ユーザー ユーザー認証・ API認可デバイス 利用 認証 API 利用デバイス ユーザー or 第三者 認証・認可 リクエスト クライアント (リライング・ パーティ) 認可・APIサーバー (アイデンティティ・ プロバイダー)
  23. 23. 国内外の事例
  24. 24. 24 • 英国Open Banking – 上位9行に、FAPIを基盤とする共通APIを義務 化。他の銀行も自発的に採用し、APIの統一 が実現 • 米国 & カナダ – 業界団体のFinancial Data Exchange がセキュ リティプロファイルとしてFAPIを採用 • 豪州 Consumer Data Right – 銀行だけではなく通信やエネルギー分野まで 含めた統一的なAPIの基盤としてFAPIを採用 • ブラジルOpen Banking – (次ページ) • その他 – Nigeria – New Zealand – Russia – ISO TC68 SC9 WG2 - WAPI グローバルに進む FAPI (& CIBA) 採用 Source: OpenID Foundation https://openid.net/wordpress-content/uploads/2022/03/OIDF-Whitepaper_Open-Banking-Open-Data-and-Financial-Grade-APIs_2022-03-16.pdf, Platformable https://platformable.com/open-banking/trends/
  25. 25. 25 • 2019年、ブラジル中央銀行がオープンバンキングプロジェクトを承認 – The Open Banking implementation in Brazil is inserted in the BCB's institutional mission: "to foster a sound, efficient, and competitive financial system, and to promote the economic well-being of society” • 規制主導モデル – In order to ensure compliance with the regulation and the achievement of the Open Banking's objectives, the BCB has been coordinating the initial self-regulatory efforts by approving decisions and revisions, as well as exercising the veto power, imposing restrictions or regulating nonagreed aspects. • 段階的にオープン化 – 2021年2月 (フェーズ1): オープンデータ(金融機関自身のデータ共有) – 2021年後半 (フェーズ2): ユーザー自身のデータ(アカウント、カー ド、クレジット業務に関する登録・取引データ)共有 – 2021年10月 (フェーズ3): Pixによる決済指図サービスの開始 – 2022年初頭~: 既存フェーズの修正・拡張を実施中 • 2022年3月、”Open Banking” から ”Open Finance” へ変更決定 – 銀行だけではなく、保険、年金、資本金、外国為替、投資データも対 象に ブラジル Open Banking → Open Finance Source: Banco Central Do Brasil https://www.bcb.gov.br/en/financialstability/open_banking, Open Banking Brasil https://openbankingbrasil.org.br/relatorio-semestral-agosto-2022/ • 2022年3月以降に27億回以上、直近の4週間では8億回の APIコールを実行 • API連携の同意確認数は670万件以上 • 参加機関ディレクトリに登録された組織は800以上 • 参加コングロマリット150社(うち13社には参加義務) • 複数の機関から1日あたり600人がOpen Financeに貢献
  26. 26. 26 • 2013年ブラジルにて創業。現在メキシコ・コロン ビアにも進出 • モバイルアプリ前提の年会費無料クレジットカー ドからスタートし、有効期限のないポイントプロ グラム、維持費不要のデジタル口座、デビット カード、個人向けローン、保険、ネット証券、決 済などに事業範囲を拡大 • 物理的な拠点を持たず、AIや顧客とのデジタル対 話を多用し、顧客満足度を重視した非常に身軽な 運営モデル • 2022年Q2時点のブラジルの顧客数は6,530万人(成 人人口の1/3)、うち5,230万人がアクティブに利用 • 2021年度に黒字化 Nubank: 世界最大のデジタルバンク Source: 日本総研 https://www.jri.co.jp/MediaLibrary/file/report/researchfocus/pdf/13154.pdf, HBS https://digital.hbs.edu/platform-digit/submission/nubank-building-a-usd-10-billion-fintech-in-6-years/, Nubank https://api.mziq.com/mzfilemanager/v2/d/59a081d2-0d63-4bb5-b786-4c07ae26bc74/793c035c-9294-c868-bc21-167f5dd529d3?origin=1,
  27. 27. 27 • 内製化 (in-house) – モバイルクレジットカードサービスをスク ラッチから開発し、7カ月でローンチ – “わたしたちはすべてのテクノロジーを内 製化しています。それが自身の競争優位性 のひとつだからです。” • 正規性 (canonicity) – 技術スタックをできるだけシンプルに維持 し、効率を高める – 同時に、もしそれらのツールが理想的では なかったり、より良い選択肢があったり、 全く役に立たなかったりした場合には、別 の解決方法を探る • ときには言語の開発元を買収 – Cognitect社 (Clojure), Plataformatec社 (Elixir) テック企業としてのNubank Source: AWS https://aws.amazon.com/jp/solutions/case-studies/nubank/, Nubank https://building.nubank.com.br/nubank-culture-and-values/, https://building.nubank.com.br/the-value-of-canonicity/
  28. 28. 28 Nubankとオープンバンキング
  29. 29. 29 2017: Adapt • 既存のインターネット バンキングサービスに API認可基盤を追加 • 参照系APIがターゲット 2019: Build • スクラッチから構築する デジタルバンキング基盤の コアにAPI認可機能を包含 • 野心的なアーキテクチャ 2021: Evolve • 参照系API基盤の老朽化を 契機とし、更新系APIに 耐えうる基盤への刷新 • 比較的大規模 国内のオープンAPI基盤整備の進展
  30. 30. 自社アプリ&Fintech 企業向け銀行API基盤を 短期間に構築 30 • Azureを採用し、短期間・低コストな オープンAPI基盤を構築 – 3カ月でAPIプラットフォームを構築 • AuthleteがAzureのAPI認可機能を代替 – セキュリティ強化のためのOAuth拡張 仕様に対応 – オンラインバンキングの既存認証シス テムをそのまま活用 – FAPI等の新しい仕様にも将来的に対応 可能 セブン銀行 Azure PaaS API Management Web Apps Jobs Push Notification Hub App Services HTTPS/JSON Online Banking System Ledger System Other Banks SOAP/SFTP on cloud
  31. 31. • 本人確認済みIDを発行する 認証認可基盤サービス • API認可基盤にAuthleteを採 用しFAPI/CIBAを実装 SBI デジトラスト“Trust Idiom” Source: NEC https://wisdom.nec.com/ja/feature/digitalfinance/2021121001/index.html FAPIとCIBAに準拠した 本人確認済みID発行 & 多要素認証基盤 31 金融 API を中核とする新サービスの展開にあたり、業界の標準仕様である FAPI と CIBA の採用は必然と言えます。それら標準技術への迅速な対応、 自社サービス基盤への統合の容易性、そして OAuth 2.0 (OAuth) および OpenID Connect (OIDC) の高い知見を評価し、Authlete を選択しました。 (SBIデジトラスト社 代表 バスケス・カオ・フェルナンド・ルイス氏)
  32. 32. モバイル向けAPI認可 基盤を構築。FAPI準拠の オープンAPIへ拡張 • ゼロベースで設計された 次世代のデジタルバンク • OAuth/FAPIの進化に適応 可能な基盤を構築 みんなの銀行 32 構築開始から 2 年弱でのサービスインを実現するというスケジュールの 下、 API セキュリティ機能は、預金や振込などの基本機能と共に、 最初の MVP (Minimum Viable Product) に含まれていました。 与えられた開発期間 は約 7 ヶ月です。この中で、OAuth 2.0 をベースとする API 認可基盤と、 銀行としての勘定系システムを、同時に実装する必要がありました。 (株式会社みんなの銀行 デジタルサービスマネジメントグループ 稲倉直也氏)
  33. 33. 進化するアイデンティティアーキテクチャ
  34. 34. サービス事業者 2000s: 独立した「アイデンティティ基盤」 自社サービスとは別のやりかたで開発・運用。UIやAPIエンドポイントも独自のアーキテクチャに基づく サービス基盤 サービス サービス サービス サービス サービス サービス APIゲート ウェイ / UI ユーザー APIクライアント アイデンティティ基盤 • ユーザーインターフェイス • APIエンドポイント • アイデンティティデータと ビジネスロジック • … 34
  35. 35. 2010s: 「アイデンティティ基盤」のクラウド 運用の手間は軽減されたものの、これまで以上に別個の基盤となり、自社サービスとの調和を取るのがますます困難に サービス事業者 サービス基盤 ユーザー APIクライアント APIゲート ウェイ / UI IDaaS • ユーザーインターフェイス • API エンドポイント • アイデンティティデータと ビジネスロジック • … サービス サービス サービス サービス サービス サービス 35
  36. 36. サービス事業者 サービス基盤 サービス 2020s: アイデンティティサービスの内包化 アイデンティティを基盤ではなく自社サービスとして位置づけ、他のサービスと同様、自分自身で完全にコントロールする APIゲート ウェイ / UI サービス サービス サービス サービス サービス アイデンティティサービス アイデン ティティ データ ビジネス ロジック ユーザー 認証 OAuth/OIDC プロトコル 処理 トークンライフ サイ クル管理 同意管理 権限管理 … ユーザー APIクライアント 36
  37. 37. サービス事業者 サービス基盤 サービス サービス サービス サービス サービス APIゲート ウェイ / UI アイデンティティ部品のサービス化 アイデンティティサービスの構成要素をWeb APIとして提供する“Identity Component as a Service (ICaaS)” の登場 アイデンティティ コンポーネント API API API API API API ユーザー認証 … OAuth/OIDC プロトコル処理 同意管理 権限管理 トークンライフ サイクル管理 ユーザー APIクライアント アイデンティティサービス アイデン ティティ データ ビジネス ロジック ユーザー 認証 OAuth/OIDC プロトコル 処理 トークンライフ サイ クル管理 同意管理 権限管理 … アイデンティティサービス アイデン ティティ データ ビジネス ロジック ユーザー 認証 OAuth/OIDC プロトコル 処理 トークンライフ サイ クル管理 同意管理 権限管理 … 37
  38. 38. Authlete: OAuth/OIDC Component as a Service KYC情報を 当人の同意に 基づき共有 更新系を含む オープンAPI の提供 業界標準の API認可と ID連携 自社アプリ & Webサイト Fintech 事業者 他社 サービス OAuth 2.0 & OpenID Connect プロトコル処理 アクセストークン ライフサイクル管理 OAuth 2.0 & OpenID Connect FAPI & CIBA OIDC4IDA OAuth 2.0 & OpenID Connect プロトコル処理 アクセストークン ライフサイクル管理 最先端の業界標準API仕様に準拠 特定ソリューションに依存せず自由にUX設計が可能 OAuth 2.0 & OpenID Connect に関する複雑な実装・運用を外部化 サービス事業者 銀行・Fintech・メディア・SaaS・ ヘルスケア・エンタメ・ECなど 柔軟な開発・運用が可能 38
  39. 39. 金融サービスを中心に多数の事業者が採用 Awards 金融 KYC システム・インテグレーション B2B / B2E 教育 EC / 小売 *1 LINE Bank設立準備株式会社 ヘルスケア IoT NTT Docomo Nubank 楽天銀行 LINE Bank *1 DPG Media メディア 39 セブン&アイ
  40. 40. Authlete を活用した認可サーバーの構築 API認可・公開基盤 APIクライ アント 既存システム Webサイト 携帯端末 ネットワーク デバイス 認可サーバー 認可ロジック (認可判定) ユーザー 認証 同意確認 権限管理 APIサーバー・ゲートウェイ /data /function /transaction Authlete 認可 バックエンド API トークン管理 データベース OAuth/OIDCリクエスト (トークン取得) APIリクエスト (トークン利用) 認可状態確認 (トークン検証など) OAuth/OIDC処理リクエスト(プロトコル処理とトークン管理) 認可 フロント エンド ユーザー管理・ 認証と認可 サーバーを分離 Authleteに依存せず自由に 認可ロジックを実装・配備 APIサーバーと 認可サーバーの 構築・運用を分離 OAuth/OIDCプロトコル処理 とトークン管理を外部化 /… 様々な言語向けの Authlete API ライブラリで開発 40
  41. 41. 認可リクエスト 認可レスポンス トークン リクエスト トークン レスポンス API リクエスト API レスポンス ユーザー認証・ アクセス承認 エンド ユーザー ユーザー エージェント クライアント OAuth/OIDC サーバー リソース サーバー Authlete と OAuth/OIDC サーバーの連携フロー 認可リクエストを 「そのまま」転送 エンドユーザーに ひもづく認可コード の発行を依頼 トークンリクエストを 「そのまま」転送 イントロス ペクション を依頼 Authlete Authlete OAuth/OIDC サーバーが次に することをAuthlete API が指示 { "parameters": "response_type=code& client_id=57297408867& redirect_uri=https%3A%2F%2F client.example.org%2Fcb" }' { ”action”: ”INTERACTION”, ”ticket”: ”c4iy3TWUzV9axH-9Q” ... } https://as.example.com/authorize? response_type=code& client_id=57297408867& redirect_uri=https%3A%2F%2F client.example.org%2Fcb リクエストを 検証・解析 /auth/authorization POST 41
  42. 42. まとめ
  43. 43. 43 • オープンAPIの提供状況と “Embedded Finance” が目指す 世界との間には依然としてギャップが存在 • 更新系APIに欠かせない “FAPI” とオフライン連携を実現 する “CIBA” に注目 • Nubankをはじめとする国内外の先進的な金融機関は オープンバンキングに向けてシステムを確立 • アイデンティティアーキテクチャは “単一の基盤” から “コンポーネントを活用したサービス” に進化 まとめ
  44. 44. Thank You tatsuo.kudo@authlete.com www.linkedin.com/in/tatsuokudo

×