Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
そのAPIはセキュアですか?
Search
RyuSA
January 20, 2021
Technology
2
810
そのAPIはセキュアですか?
Financial Grade な API のセキュリティ
#webapilt
RyuSA
January 20, 2021
Tweet
Share
More Decks by RyuSA
See All by RyuSA
Java屋だってOperatorが作りたい!
ryusa
1
570
Visual Studio Codeとコンテナでいい感じのRe:View執筆環境
ryusa
1
1.5k
JavaScriptと歩くポリシーエンジン jsPolicy
ryusa
1
560
TextAlive App APIと夢見る新しいUX
ryusa
1
400
Gitlab Operatorと夢見るGitlab自動化の旅
ryusa
2
1k
AccessPoint Operator on Raspberry Pi
ryusa
1
1.2k
Serviceをたずねて3000行 - Kubernetesコードリーディングの旅 -
ryusa
2
850
「L3以下は魔法で動いている!」と言いながらiptablesとkube-proxyを読んでみた話
ryusa
1
140
「〇〇完全に理解したったww」から始めるエンジニア生活
ryusa
2
4.3k
Other Decks in Technology
See All in Technology
自動テストのコストと向き合ってみた
qa
0
200
職種別ミートアップで社内から盛り上げる アウトプット文化の醸成と関係強化/ #DevRelKaigi
nishiuma
2
160
PLaMo2シリーズのvLLM実装 / PFN LLM セミナー
pfn
PRO
2
1k
LLM時代にデータエンジニアの役割はどう変わるか?
ikkimiyazaki
6
1.1k
動画データのポテンシャルを引き出す! Databricks と AI活用への奮闘記(現在進行形)
databricksjapan
0
160
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
20k
【Kaigi on Rails 事後勉強会LT】MeはどうしてGirlsに? 私とRubyを繋いだRail(s)
joyfrommasara
0
170
能登半島地震で見えた災害対応の課題と組織変革の重要性
ditccsugii
0
170
ガバメントクラウド(AWS)へのデータ移行戦略の立て方【虎の巻】 / 20251011 Mitsutosi Matsuo
shift_evolve
PRO
2
170
空間を設計する力を考える / 20251004 Naoki Takahashi
shift_evolve
PRO
4
440
プロポーザルのコツ ~ Kaigi on Rails 2025 初参加で3名の登壇を実現 ~
naro143
1
160
Escaping_the_Kraken_-_October_2025.pdf
mdalmijn
0
150
Featured
See All Featured
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
The Cost Of JavaScript in 2023
addyosmani
53
9k
The Invisible Side of Design
smashingmag
301
51k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
54
3k
Building Adaptive Systems
keathley
43
2.8k
Context Engineering - Making Every Token Count
addyosmani
5
210
A Modern Web Designer's Workflow
chriscoyier
697
190k
Speed Design
sergeychernyshev
32
1.1k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
Building an army of robots
kneath
306
46k
Statistics for Hackers
jakevdp
799
220k
Transcript
そのAPIはセキュアですか? Financial Grade な API のセキュリティ RyuSA
RyuSA Financial Service Engineer Java & SpringBoot / Typescript &
React Docker / Kubernetes : RyuSA : ryusa_eng
全国銀行協会より オープンAPI ≠ OpenAPI (Swagger) なんだぜ、ググラビリティがあかん >
たぶんこんな世界になる……?
※注 あくまでも登壇者の妄想です < サービスしてちょ まいどー > < Aくんの口座情報教えてー あの……焼肉屋さんが…… >
< 口座情報教えていいですよー < はいどうぞ
知ってる! これ、OAuth2.0で実装できる!
落ち着け、OAuth2.0はシルバーバレットにあらず
• OAuth2.0はリソース制御のための「フレームワーク」 • OAuth2.0で認可を実装した ≠ セキュアなAPI • SNSの認可に要求されるセキュリティレベル ≠ 銀行や証券の認可に要求されるセキュリティレベル
• 近年はオープンAPIも叫ばれており、金融向けのセキュアな認可の整備が急がれている • 一方で「セキュアな認証認可」をどこまでやるべきかのガイドラインが必要 そして究極のセキュリティ「APIを公開しない」が生まれる 認可に困ったらOAuth2.0に頼ろうとしてない?
Financial Grade API 略して”FAPI” 読み方は「ふぁぴ」だって、かわいいね >
• FinTechサービスにOAuthプロファイルを導入するためのガイドライン • Part1/Part2/Part3の3部作で構成されており「ReadOnly API」「Read&Write API」 などについてそれぞれ実装すべき項目が記載されている • 金融に限らず、高いセキュリティが要求される認可システムの管理者・実装者は参照す べきドキュメント
• チェックリスト方式になっている • 実装すべきこと、設定すべきことが一覧化 • たまに「実装すべきでない」ことも書いてある • CIS Benchmarkのような感じ FAPIは”OAuth2.0実装のガイドライン”
• Part1 (Read Only) • 認可サーバは LoA 2 相当のユーザ認証を実装しなければならない •
ClientはResource Ownerとのセッション中はredirect_uriを保存し、認可レスポン スを受け取った際のredirect_uriと比較しなければならない(5.2.3) • Native Appはカスタムスキーマによるリダイレクトを実装してはいけない(7.5) • HTTPSによるリダイレクトを利用しましょう • Part2 (Read & Write) • 認可サーバは LoA 3 相当のユーザ認証を実装しなければならない • ClientはHolder-of-Key Tokenと実装しなければならない • OAuth 2.0 Token Binding か mTLSかで実装しましょう 具体例
• オープンAPI という世界とその認可のガイドラインFAPI • みなさんの身近に迫ってきています • 「認可システムを作る / 設計する」ということがあれば、FAPIを覗いてみては? •
「あ、この設定した方がいいかも」等の思わぬ発見があると思います • セキュリティレベルをビジネスKPIに沿って決定 • 焼肉食べたい • コロナで外出・外食がめっきり減ってしまって、正直口元が少しさびしい…… まとめ