FinTech時代の銀行に求められるSoE/SoRアーキテクチャとAPI管理とは：FinTech時代、銀行系システムはどうあるべきか（3）（3/4 ページ）

本連載では、銀行系システムについて、その要件や歴史を整理しつつ、スマートフォンを使う銀行取引やブロックチェーンなど、新しい技術が及ぼす影響を考察していきます。今回は、FinTech時代に求められる銀行業務のシステム要件として、Systems of EngagementとSystems of Record、API連携基盤（API管理）に必要な機能や課題、OpenAPIの在り方などについて考察。

[鎌田美樹夫（日本アイ・ビー・エム株式会社）, 秋元毅彦（日本アイビーエム・ソリューション・サービス株式会社），＠IT ]

API連携基盤（API管理）に必要な機能や課題

APIのアクセス制御

　顧客保護やセキュリティの観点からいうと、銀行が外部に開放するAPIを誰でも自由に使用できることはあり得ません。未知の多様なスマートフォンアプリケーションがAPIを使用して直接銀行システムに自由にアクセスすることは大きなセキュリティのリスクになります。銀行との契約に基づいてAPIの使用を許可されたアプリケーションサーバが、利用者に許可された資源に対してのみアクセスできるようにする必要があります。

　ここでは、APIのアクセス制御について以下の観点で説明します。

• アプリケーションの登録
• 取引の許可
• アクセストークンの管理

アプリケーションの登録

　APIを発行するアプリケーションは、事前に銀行システムのAPIゲートウェイに登録します。登録時に、アプリケーションに対してClient IDとClient Secretを発行します。これは、APIを発行するアプリケーションに対するユーザーIDとパスワードのようなものです。

　アプリケーションがAPIを発行するときは、Client ID（必要に応じてClient Secretも）も併せて送信します。これにより、銀行システムはAPIを発行したアプリケーションを判別できます。さらにアプリケーションごとのAPIアクセス数などの統計情報の取得、アクセス数の制限、許可していないアプリケーションのブロックが可能になります。

取引の許可

　インターネットバンキングでは、ユーザーIDとパスワードによって本人を認証して取引を行います。では、「銀行外部のアプリケーション」がAPIを使用して、銀行システム内の資源にアクセスする場合は、銀行外部のアプリケーションにインターネットバンキングのユーザーIDとパスワードを渡して取り引きさせても、セキュリティ上問題はないのでしょうか。

　この問題を解決する手段として、標準的に用いられている方法がOAuth 2.0です。OAuth 2.0を使用した取引認可の概要を図6に示します。

図6　OAuth 2.0を使用した取引認可の概要

　FinTechアプリケーションに対して銀行との連携を要求すると銀行に許可をもらうように応答されます（図6の1、2）。本人認証と取引の許可に成功する（図6の3、4）と銀行システムが銀行外部のアプリケーションに対して、アクセストークンと呼ばれるトークンを発行します（図6の5）。銀行外部のアプリケーションは、アクセストークンを保管し、APIを発行するときにアクセストークンも併せて送信します（図6の6）。銀行システムは、アクセストークンを確認してAPIで要求された資源へのアクセスを許可します（図6の7）。

　このような処理フローにすることで、銀行システムのユーザーIDとパスワードを銀行外部のアプリケーションに渡すことなく、銀行システムの資源にアクセスを許可します。

アクセストークンの管理

　アクセストークンは、銀行外部のアプリケーションサーバで保管されます。情報漏えいなど万一の事態に備えて、アクセストークンには通常、有効期間を設定します。有効期間を越えた場合は、再度ユーザー認証と取引許可のプロセスを行うか、リフレッシュトークンを使用して再度アクセストークンを取得します。

　リフレッシュトークンは、ユーザー認証と取引許可のプロセスなしにアクセストークンを再取得できます。有効期間の長さ、およびリフレッシュトークンによるアクセストークンの再取得を許可するか否かは、利便性とセキュリティ要件を勘案して設定します。

　設定には、「参照系取引と更新系取引の違い」や「アクセストークンの失効管理」について考慮する必要があるでしょう。

・参照系取引と更新系取引の違い

　残高照会などの参照系取引は、利便性を重視してアクセストークンの有効期間を、例えば1時間に設定し、リフレッシュトークンの使用を許可します。振込など更新系取引は、利便性よりセキュリティを重視して、「有効期間を、例えばインターネットバンキングのワンタイムパスワードと同等の3分間、リフレッシュトークンなしに設定する」といったことが考えられます。

　さらに更新系取引では、アクセストークンの有効期間を短縮するだけではなく、インターネットバンキングで使用されている第2パスワード、乱数表、ワンタイムパスワードや指紋などの生体認証を組み合わせることで、より厳格に本人認証を行うことも必要になるでしょう。

・アクセストークンの失効管理

　利用者保護の観点から考えると、「アクセストークンの有効期限による管理」だけではなく、「銀行のお客さまの操作や申し込みを契機に有効期間内のアクセストークンを失効させる」機能も必要です。例えば、アクセストークンを失効させる対象として下記表に示すようなものが考えられます。

表　アクセストークン失効対象（例）

	失効対象	失効後の対応
1	IDまたはパスワード変更	アクセストークンの再取得
2	パスワード無効化（リボーク）	パスワード再設定後、アクセストークンを再取得
3	解約	アクセストークン取得不可

　「アクセストークン失効事象が起きていないか」を確認するため、銀行外部からAPIが呼び出される都度、APIゲートウェイは「アクセストークンが有効であるか」をアクセストークン失効管理コンポーネントに問い合わせます。アクセストークン失効管理コンポーネントは、「銀行システム側で失効対象となる操作が行われていないか」を問い合わせます。パスワード変更などアクセストークンの失効対象となる操作が行われていた場合は、アクセストークンが失効していることをAPIゲートウェイに応答します。

図7　アクセストークン失効管理の概要

マルチテナント管理の必要性

　現在の金融機関とFinTechアプリケーションとの接続形態で実績があるのは、「単独金融機関が単一数のFinTechアプリケーションと接続する」「数種類のFinTechアプリケーションと接続する」の2種類で、かつおおむねWebスクレイピングが使用されているのが一般的です。今後API連携が普及してAPIエコノミーが発展し始めると、複数のFinTech企業と複数の金融機関が接続する「N：N接続」が実現され、図8のようにマルチテナント管理が必要となってきます。

図8　APIマルチテナント管理のイメージ

　この場合、多くの考慮事項があります。例えば、ある金融機関が、複数のAPIを準備し、FinTechアプリケーションごとに開示するAPIが異なる場合が想定されます。またFinTechアプリケーション側から、銀行ごとに利用したいAPIが異なる場合もあります。

　さらに、同じFinTechアプリケーションでも、参照系サービスのみ提供する場合と、参照＋更新系サービスを提供する場合が想定されます。この場合は、サービス内容によってユーザーに課金することも考えられます。一方、金融機関によっては参照系サービスのみAPIを提供する場合や参照＋更新系サービス双方提供する場合があります。

　このためAPI管理層には、FinTech企業ごと、金融機関ごとに、サービスに応じて利用可能となるAPIのみを連携させる機能が必要となります。API開示の運用についても、多くの考慮が必要です。図8では、API提供企業がFinTech企業に対し、用途や課金単位でAPIをパッケージングして、プランとして提供する運用を例示しています。プランに自由度を持たせ過ぎて種類が増えてくると、運用面に大きな負担が生じる可能性が大きくなります。

APIのバージョン管理

　外部にAPIを開放していくとなると、APIは容易にはバージョンアップできません。なぜなら、API接続先にもバージョンアップ対応が必要となり、複数のFinTech企業と接続している場合、FinTech企業ごとに対応スピードが異なることが想定されるからです。

　加えて、全てのFinTech企業が新バージョンに移行するまで、現バージョンと新バージョンを並行稼働させる必要があり、相応にシステム運用負担が継続することになります。例えば、さまざまなAPIを開放しているGoogleやFacebookでも、バージョンアップする際は相当期間、現バージョンと新バージョンの並行稼働を行って新バージョンに移行していくのが普通です。

アクセス履歴管理

　API接続を行えば、FinTechアプリケーション／エンドユーザーごとのアクセス履歴の取得が容易になります。Webスクレイピングの場合は不正アクセスとの区別が付きにくいですが、API接続だと「どのFinTechアプリケーションからのアクセスか」を判別でき、不正アクセスの防止やセキュリティの向上にも寄与します。

　ただし、不正アクセスの可能性はゼロではなく、そのような事象が発生した場合の金融機関およびFinTech企業間での取り決めや連絡体制も十分に考慮しておく必要があります。

流量管理

　流量管理も大きな課題になると考えられます。人気FinTechアプリケーションが大幅にユーザー数を増やし、銀行システムへの想定外のアクセスがあった場合の制御も考慮する必要があります。

　また、アクセス想定数もFinTech企業と調整しておくことが必要です。先ほど「プランを作成してFinTechサービスごとにAPI管理をする」例を提示しましたが、そのプランには、月間アクセス数の取り決めを行い、「アクセス数をオーバーした場合は、システムリソースを考慮して流量制限、あるいは流量操作を行う」などの対応を含める必要があります。

課金管理

　APIでマネタイズする場合もあり得ます。使用量に応じて課金できれば大きなビジネスとなる可能性があるため、課金管理を実現する仕掛け作りも考慮しておく必要があります。