
Web APIの公開はセキュリティが不安…安全にAPIを公開する方法とは?
APIとセキュリティ
Webサービスは、人間が使うためのユーザインターフェースに加えて、外部システムと連携するための機能をAPIとして公開することで、さらにサービスの可能性を広げ、新たなイノベーションを呼び込むことが可能です。さまざまなWebサービスが次々とAPI連携を行い、モバイルアプリなどを通じて便利なサービスを消費者に提供する「APIエコノミー」の世界は年々拡大しています。
しかし、APIを公開すれば自社サービスの利便性は高まりそうだけど、セキュリティが不安でなかなか公開に踏み切れない…。
そのような悩みを抱える方が、多くいらっしゃるようです。
実際に、API公開の課題に「セキュリティの担保」を挙げる企業が多いことが、総務省の調査結果(平成30年「ICTによるイノベーションと新たなエコノミー形成に関する調査研究」)で明らかになっています。
本記事では、APIのセキュリティについて解説します。
APIセキュリティで欠かせない「OAuth2.0」
APIのセキュリティを語る上で欠かせないのが、API連携のオープンスタンダードである「OAuth2.0」(オーオース2.0)です。
OAuth2.0は、API連携を安全に行うための「認可フレームワーク」として、さまざまなWebサービスで活用されています。
次のイラストは、OAuth2.0を活用したAPI連携の標準的な流れを表したものです。
「API提供事業者」とは、AmazonやGoogle、Facebookなどのメガクラウドサービスや、銀行などのAPIを公開している事業者のことを指し、API利用サービスとは、それらのAPIを利用してモバイルアプリケーションなどを提供するサービスのことを指します。
API提供事業者は、API利用サービスへのデータ提供に先立ち、まずサービス利用者のログインによって利用者を認証します。次に、利用者に対して、利用者のデータをAPI利用サービスへ提供してよいかどうかの同意確認を行います。この記事をご覧の皆様も、スマートフォンをお使いであれば、一度ぐらいは、アプリケーションに対する情報提供の同意確認画面をご覧になったことがあるのではないでしょうか。この同意確認に基づいて、API利用サービスに対して、サービス利用者のデータへアクセスする権限を与えることを「認可」と呼びます。
そして、認可コードと呼ばれるAPIアクセスのための許可証を受け取ったAPI利用サービスは、APIコールによって受け取ったサービス利用者に関するデータを使用して、最終的に利用者に対するサービスを提供します。
この手順を踏むことにより、サービス利用者はAPI利用サービスに対して、クレデンシャル情報(ID/パスワードなどのユーザ認証に関わる情報)を渡すことなく、サービス利用に必要なデータのみを、自らの意思に基づいて提供することで、安全にサービスを使うことができます。
OAuth2.0は、暗号化や電子署名などの技術を組み合わせて、データの改ざんやなりすましを防いだうえで安全に認可を行うための手続きを標準化したものであり、このような安全でオープンな技術の存在は、これまでのAPIエコノミーの発展に大きく貢献してきました。
金融分野のAPIはOAuth2.0だけでは不十分
ところが近年、ある分野のAPI連携において、OAuth2.0よりさらに高いレベルのセキュリティ標準を採用する動きが広がっています。その分野は、銀行などの金融分野です。
近年銀行では、APIを公開する「オープンAPI」が急速に進んでいます。ターニングポイントとなったのは、2017年5月に成立した「銀行法等の一部を改正する法律(改正銀行法)」です。
この法律の目的は、利用者の保護を前提に、金融機関とフィンテック企業の連携によるオープンイノベーションを促すことです。政府目標である「2020年6月までに、80行程度以上の銀行におけるオープンAPIの導入」をもとに、都市銀行、地方銀行、第二地銀は全行、信託銀行は6割弱が、オープンAPIに対応する方針であることを表明しました。
次のイラストは、銀行とフィンテック企業のAPI連携の仕組みを表したものです。
こうして銀行とフィンテック企業のAPI連携が進むなか、銀行側はまず口座残高の取得など、資金移動を伴わない「参照系API」の公開が広く進みました。続いて、振込や振替などの資金移動を伴う「更新系API」も順次公開が予定されています。
更新系APIにより、預金口座間の資金移動が可能となり、より高度なサービスの提供が期待されますが、その一方でより高いセキュリティ強度が求められます。
そこでセキュリティ強度をはかる“物差し”となるのが、FISC(公営財団法人 金融情報システムセンター)が公表している「API接続チェックリスト」です。
API接続チェックリストは全44項目あり、以下の表は、チェックリストの中でも特にAPIのセキュリティ機能に特化した項目について抜粋したものです。この中には、OAuth2.0では十分に対処しきれない項目も含まれています。
通番 | セキュリティ対応目標 |
---|---|
36 | 認証認可に関する機密情報の漏洩対策を実施する。 |
37 | APIの想定外利用を回避する。 |
38 | 利用者が認識していないところで、利用者のアカウントがAPI接続に使用されないようにする。 |
39 | 利用者の利便性と、リスクに見合った利用者保護を実現する認証強度とする。 |
40 | 脆弱性への攻撃に対する多層防御を図る。 |
41 | 認証の悪用リスクを可能な限り低減させる。 |
42 | API接続先を含めた全体の認証強度をもって、利用者保護を図る。 |
出典:FISC「API接続チェックリスト」
このような金融機関レベルの高いセキュリティ基準を満たすためには、具体的にどのような実装が求められるのでしょうか?
OAuth2.0+FAPIへの準拠
全国銀行協会が事務局を務める「オープンAPIのあり方に関する検討会」は、金融分野でのAPIセキュリティについて、OAuth2.0に加え、FAPIへの準拠が望ましいという報告書を作成しました。
FAPIとは、Financial-grade APIの略称で、金融API向けのセキュリティ標準です。
FAPIに準拠することで、次のような対策が可能となり、セキュリティ強度を高めることができます。
【FAPI対応の主な内容】
- トークンの暗号化
- セッション横取り関連の攻撃への対策
- 強固なユーザ認証の要求(生体認証など)
- クライアントなりすまし対策
- トークン削除APIの提供
今後は、銀行による更新系APIの提供が広がっていくことにより、OAuth2.0に加えてFAPI仕様へ準拠することが、金融分野における安全なオープンAPIのスタンダードとして定着していくことが予想されます。
まとめ
以上がAPI連携におけるセキュリティの説明です。OAuth2.0が果たす役割や、金融APIにはFAPI対応が欠かせないことがおわかりいただけたでしょうか。
NTTテクノクロスの「TrustBind」は、OAuth2.0対応でセキュアなオープンAPI基盤を実現でき、金融機関などの導入実績も多数ございます。認証・認可プラットフォームの構築をお考えの際は、ぜひNTTテクノクロスまでご相談ください。