2024.12.24
ビジネスが急速に変化する現代は「OODAサイクル」と親和性が高い 流通卸売業界を取り巻く5つの課題と打開策
銀行事業のサーバーサイド開発について(全1記事)
提供:LINE株式会社
リンクをコピー
記事をブックマーク
Robert Mitchell氏(以下、Mitchell):サーバーサイドチームのMitchell Robertと申します。本日、野田さんと一緒に、LINEの銀行サービスの開発について発表したいと思います。よろしくお願いします。
今日の内容ですが、以下の通りになります。まずはLINEの銀行サービスとはなにかついて、軽く説明したいと思います。その後、システムアーキテクチャと開発フローについて話したいと思います。最後は、認証と認可で、これは私たちが担当している部分です。これに関連するスペックや、セキュリティの仕組み、フローについて話したいと思います。
じゃあ、LINEの銀行サービスとは何かを簡単に言うと、新しいスマホ銀行です。みずほ銀行と手を組んで、LINE Bank設立準備株式会社を立ち上げました。現在、開業に向け準備を進めています。
LINEが世界中の人と人、人と情報、サービスとの距離を縮めてきたように、お金との距離を縮めていく。CLOSING THE DISTANCE。そして、スマホアプリで、どこでもバンキング。これは銀行の支店でできるようなことが、アプリでもできます。あとは、APIの提供も検討しています。これはOAS、OpenAPI Specificationの定義でドキュメンテーションを生成します。
実はもっとすごい機能も含まれる予定ですが、これ以上言ったら怒られそうなので、遠慮しておきます。
次に、システムアーキテクチャに移りたいと思います。まず技術スタックなんですが、サーバーアプリ側は言語がJavaです。なぜかというと、安定していて、LINEで共通言語になっているためです。特にチームが多いため、これは重要な点です。そして標準のSpring Bootなどを使っています。
インフラの環境については、専用のデータセンターで提供する予定です。その他は、Data Storeの話なんですが、Redis, MySQL, Kafkaなどを全部使っています。
あとはソースコントロールとCI/CDの役割には、GitLab + Ansible Towerを使用しています。
次は開発フローについてお話ししたいと思います。開発フローは、だいたいこのような流れになります。まず要件の仕様を読みます。もちろん、ミーティングなどで話し合う場合もあります。そしてOpenAPI Spec(OAS)でAPIを定義します。OASは、以前Swaggerと呼ばれていて、けっこう有名な技術なので、みなさんもご存じかと思います。
そして、その後YAMLでコード自動生成が行われます。このコードはJavaのインターフェイスになります。そして、このJavaコードの中にルートやURLも含まれているで、コードがスペックからズレることはほぼありません。
そしてCI/CDで、自動的にJavaにパッケージして、そのJavaファイルをGitLabのパッケージレジストリに載せます。このコード自動生成が終わったら、私たちのサーバー開発チームが、そのインターフェイスを実装します。実装が終わったら、マージリクエストを送ってコードレビューを行います。これが終わるまで繰り返します。
こういうフローを単純なアクティビティ・ダイアグラムにすると、このようになります。とりあえず要件が入ってきて、こういう要件を検討してからAPIをYAMLで定義します。
GitLabのOpenAPIビューワーでYAMLをHTMLに変換します。これはSwaggerUIを用いていますが、こういう定義が終わったら、コードを自動生成します。これをYAMLの修正をプッシュすると、GitLab CI/CDで自動的に動きます。
この自動生成が終わったら、実装の段階に入ります。実装が終わったら、コードビューを行います。もちろんこれで終わる時もありますが、もし開発の誤解があったり、もしくは修正が必要な場合は、左のほうに戻っていって、もしAPIの定義が必要だったらこのGitLabの定義の段階に戻って直して、コード自動生成を行なって、実装、コードビューとなります。こういう順番を終わるまでにくるくる回っていくみたいな感じになります。実は開発フェーズが終わったことはなかなかないんですけど。
はい。で、これは本番の例ですが、この左上のAPIをYAMLで定義して、この定義から右のドキュメンテーションと真下にあるJavaのコード生成できます。
次に、先ほど言ったフローをエクスポートするためのツールをリストアップしました。まず、OS用のエディターはStoplight Studioか、VS Code plus Open API Pluginのどちらかを使っています。
そしてドキュメンテーションの生成はSwagger UIを使っていますが、これはGitLabで自動的に動くので、全部やってくれるんです。
あとはコードの自動生成。これはOpenAPI generatorを使っていて、Javaだけではなく多数の言語対応しているので、けっこう便利なツールです。
そしてソースコントロールとCI/CDは、先ほども言ったとおり、GitLabになります。みなさんぜひお試しください。本当に便利なツールなのでおすすめです。
次は認証と認可になりますが、野田さん、引き継ぎをよろしくお願いします。
野田誠人氏(以下、野田):はい、では認証と認可について説明いたします。とは言っても、残念ながらまだLINEの銀行サービスはリリースされているわけではないので、具体的にどう実装をしているかはちょっと現在まだお話できません。
ということで、認証と認可に関する技術的なお話を紹介しようと思っています。
まず認証ですが、中でも一番有名なのはOpenID Connectだと思います。順番が前後しますすが、後に出てくる認可のOAuth2.0のフローに載せてこれはJWTと呼ばれるIDトークンを発行して、この人はどういう認証方法で私たちのプラットフォームが認証した正式なユーザーです、というのを証明するトークンを発行する技術です。
だいぶメジャーになってきていると思います。いろいろなところで見られます。LINEなら、LINEログインはOpenIDのConnectのIDトークン発行しているので、もし興味があれば、そちらの資料もデベロッパーズ向けに資料公開されていますので、ご覧ください。
次のFIDO2は、最近いろいろな銀行アプリで採用されてきていてる、生体認証などを使うというものです。その中のWebAuthnは、Mozillaなどのブラウザーに搭載されている機能で、ブラウザーなどいろいろ構成されている技術として公開されています。
FIDO2には、「FIDOアライアンス」という団体があって、LINEもサービス事業会社として世界初の「FIDO ユニバーサルサーバー」の認証を取得しています。先日、OSS として公開されました。LINEの場合は、現在LINEで生体認証を使ったリモートログインが実装されています。
ちょっとこれは未来の話ですが、DIDというのもあって、これについてサラッとお話しします。これは特定のベンダーに認証情報を集めるんじゃなくて、各々のデバイスなどに自分のIDを持たせて、それで起動しようという技術です。
まだ議論の途中で、実現するのはだいぶ先の話になりそうですが、おもしろいので、興味があればぜひ追ってみてください。
次に、認可についてお話しします。認可と認証というのは、似ているようで違うということが、だいぶ昔から言われてきていますが、銀行のシステムでも、これらをしっかり区別してやろうとしています。
現在の定番はOAuth2.0が有名ですが、このように「RFC6749」といったいろいろなベースがあって、時代の流れに乗って、これはセキュリティ的にちょっと危険なのでドロップしようとか、こういう機能を追加しようといったようなものが、どんどんどんどんRFC化されて追加されています。
それをまとめようとして再編集されたのが、まだドラフトのOAuth2.1です。今後はこちらが主流になってくると思います。その上にOpenID Connectが載って、さらにFAPIというものがありまして。
FinancialGradeAPI( Part 1: Baseline / Part 2: Advanced )、これもOpenID Connectの団体から出ているんですが、まさに銀行や金融サービスのためのOpenID Connectのプロファイルです。
プロファイルといっても、何か新しいものはありません。すでに出された技術に対して、このセキュリティを高めるためにこれをしてくださいといったチェックリストのようなものが定義されているものです。それを図にしたものがこんな感じです。
現在、これらの技術は、ほとんどドラフトのものが多いです。私たちは、最新のセキュリティである、こういった事柄を、勉強しながらできる限り取り入れていって、システムを作り上げようと、開発しているところです。
その中で、セキュリティの仕組みとして、「認可フロー」「クライアントの認証」「トークンバインディング」「認可コードの保護」のところを、ちょっと上げてみます。
それと他に「CIBA」と呼ばれる認可フローもあって、こちらは、後で出てきますが、要は手元のデバイスで認証するということです。ブラウザの中でポチポチッとボタンを押して、そしたら手元のスマートフォンに「これ本当にあなたがやったものですか」っていうのが出て、はい・いいえと認証するようなものを正式にスペック化、仕様化したものが「CIBA」です。
新しいものだけでなく古くからある技術がうまく利用されることもあります。例えば、RFC 8705は、昔からあるクライアント認証で互いのクライアント証明書を認証時に確認する mTLS という仕組みを、OAuth におけるクライアントの認証やトークンの所持証明に利用しようというものです。
Private Key JWTは、秘密鍵、公開鍵を作成して、公開鍵を登録しておいて、秘密鍵で生成したJWTを検証することによって、正規のクライアントと認証するクライアント認証の技術です。
OAuthのクライアント認証は、昔からクライアントIDとシークレットキーとなっていたのですが、最近はもうシークレットを使わないもののほうがセキュリティが高いということで、これからそちらが主流になってくると思います。
現在のOAuth2.0では、トークンを知っていれば誰でもリソースにアクセスできたのですが、このトークンの正常な持ち主がアクセスしているかどうかまでちゃんと確認しようというのが、トークンバインディングです。
それにはDPoPや、先ほども出てきたmTLSを使ってトークンを事前に発行する時に「この情報を持った人じゃないと使ってはダメですよ」って登録するようなものです。
銀行などの場合は、トークンを盗まれてアクセスさせるわけにはいかないので、認証と紐づいて、こういうトークンバインディングの機能も検討しています。
これが先ほど紹介した「CIBA」ですね。通常のOAuthというのは、フロントチャネルといいますか、ブラウザ上で動くのが前提となっていたんですが、もう最近はブラウザ上ではなくてサーバー上の通信で、非同期に認証していこうというのが主流になると思っています。
ちょっといろいろ文字ばっかりで説明しましたが、私たちはこういった技術を日頃取り入れて、よりよい銀行システムをみなさんにお送りできるようにと開発しています。興味がある方は、ぜひ一緒に開発してくれたらと思います。
以上で、銀行事業の開発チームからの紹介を終わります。
LINE株式会社
2025.01.16
社内プレゼンは時間のムダ パワポ資料のプロが重視する、「ペライチ資料」で意見を通すこと
2025.01.15
若手がごろごろ辞める会社で「給料を5万円アップ」するも効果なし… 従業員のモチベーションを上げるために必要なことは何か
2025.01.20
組織で評価されない「自分でやったほうが早い病」の人 マネジメント層に求められる「部下を動かす力」の鍛え方
2025.01.14
目標がなく悩む若手、育成を放棄する管理職… 社員をやる気にさせる「等級制度」を作るための第一歩
2025.01.09
マッキンゼーのマネージャーが「資料を作る前」に準備する すべてのアウトプットを支える論理的なフレームワーク
2025.01.14
コンサルが「理由は3つあります」と前置きする理由 マッキンゼー流、プレゼンの質を向上させる具体的Tips
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.01.21
言われたことしかやらないタイプの6つの言動 やらされ感が強く他人任せなメンバーを見極めるチェックリスト
2017.03.05
地面からつららが伸びる? 氷がもたらす不思議な現象
2015.11.24
人は食事をしないとどうなるか 餓死に至る3つのステップ
チームの生産性を上げるマネジメント術
2024.12.11 - 2024.12.11
特別対談「伝える×伝える」 ~1on1で伝えること、伝わること~
2024.12.16 - 2024.12.16
安野たかひろ氏・AIプロジェクト「デジタル民主主義2030」立ち上げ会見
2025.01.16 - 2025.01.16
国際コーチング連盟認定のプロフェッショナルコーチ”あべき光司”先生新刊『リーダーのためのコーチングがイチからわかる本』発売記念【オンラインイベント】
2024.12.09 - 2024.12.09
NEXT Innovation Summit 2024 in Autumn特別提供コンテンツ
2024.12.24 - 2024.12.24