開閉ボタン
ユーザーメニュー
ユーザーメニューコンテンツ
ログイン

  • 会員限定
  • 2018/07/25

APIのセキュリティ対策をガートナーが解説、具体的に押さえるべき3つのポイントとは

企業にとってAPIは、開発者、モバイル・ユーザー、B2Bパートナーなどと連携するためのカギだ。ただし、APIの使用に当たっては、その価値ある情報を保護するセキュリティ対策が不可欠となる。ガートナー リサーチのバイス プレジデント、パオロ・マリンベルノ氏がAPIセキュリティ対策を検討する際のポイント、戦略・アーキテクチャの選び方、具体的にどの部分にどのような対策を講じるべきかを解説する。

photo
API活用の動きは広がっているがセキュリティ対策は不十分だ
(©photon_photo - Fotolia)

「オープンさ」と「保護」のバランスが肝

 APIセキュリティ対策における最も重要なキーワードは「バランスを取ること」だ。価値ある情報は保護する必要がある。しかし、同時にアクセスが必要な人がアクセスできるようにしなければならない。それと同時にオープン性も重要で、システムとしてそのバランスを保つことが必要になる。

 「現在、セキュリティのハッキングで盗まれるものの多くはサーバにあるデータだ。APIや認証情報(ID)を盗もうという人はあまりいない」と、マリンベルノ氏はAPIセキュリティの現状について話す。

 さらに、「現在、APIは何らかの形でセキュリティを実装しているが、十分ではない。ほとんどの従来型のWebトラフィックのセキュリティはWebアプリケーション・ファイアウォールを使うことが多いが、それも不十分。さらに暗号鍵管理、またはTLSも十分ではない」と指摘する。

攻撃者は認証情報を盗み、権限あるユーザーへの“なりすまし”を狙う

 一般的に“攻撃者”は、最も守りが甘い経路をたどる。つまり、セキュリティを固めていけば、それ以外の場所が狙われていくということだ。したがって攻撃をさせないことも、完全に固めることも無理で、「より攻撃しにくくする」のが現実的な解となる。

 世の中にはコネクテッドカー、スマートデバイス、IoTデバイスなどさまざまなデバイスがあり、これらがAPIをコールすることで、デバイスがデータにアクセスしていく。

 そのデータというものは一般的に大きなサーバが会社などの中にあり、そこに保存されている。基本的にサーバに保存されていれば、いろいろなセキュリティ策が施されているので安全、保護された状態になっていると考える。

 ハッカーは通常、その保護されているデータに価値を見い出し、アクセスしようとする。そのため彼らは、それらデータにアクセスできる「認証されたデバイス」のふりをしようとする。そうすれば、システムから「有効なユーザーである」と認識され、データにアクセスが可能となるからだ。そのためハッカーはウイルスを使って認証情報を盗み出し、それを使ってデータの保存場所にアクセスしようとする。

画像
認証情報が盗まれればAPIの先にあるデータにアクセス可能

 たとえば、ある人が銀行の自分の口座の情報、残高や入出金の記録などモバイルデバイスから見ようとする場合、口座の持ち主、エンドユーザーが銀行にアクセスできる認証情報を持っている。このエンドユーザーは、その時に使うアプリケーションに対して認証情報を入力する。

 そのアプリケーションは、多くの場合、銀行自体がこのユーザーに与えたアプリケーションであり、安全なものだ。そのアプリケーションに対して、ユーザーは認証情報を入力し、銀行側に認証され、情報を取得することが可能になる。

 しかし、たとえばモバイルデバイスで認証が行われる場合に、そのデバイスが認証情報を持つことは、セキュリティ上好ましくない。またアプリケーションが銀行から提供されたアプリケーションなら信頼できるが、銀行が提供したものではない可能性もある。その場合、認証情報がアプリケーションに残っていると盗まれる可能性があり、これも好ましいとは言えない。そのため、適切な認証のやり方に変える必要がある。

 現在では「OAuth(オーオース)」が銀行のアプリケーションでは使われており、方法として有効である。エンドユーザーがOAuthを使う場合、認証に際してユーザーは銀行の認証情報を入力しないため、デバイスに認証情報は残らない。また、デバイス自体が他のやり方でユーザーの認証をするとリスクは小さくなる。具体的には、指紋認証や網膜認証といった生体認証が挙げられるだろう。

 デバイスはサードパーティー・アプリとして認証される。この際、実際の認証情報の代わりにトークンをやり取りすれば、認証情報が流出しなくて済む。ここでの考え方として重要なのは、信頼できないかもしれないサードパーティー・アプリに認証情報が流れることを防止することだ。

 「他にも認証のメカニズムはあるが、現時点では、Webアプリケーション・ファイアウォールなどのアプリケーション・セキュリティ・ツールに搭載されているAPIセキュリティ機能には限界がある。また、ボット対策ソリューションが提供するAPI異常検知も、ある程度はセキュリティを担保するが、API特有の脆弱性があるため悪用の脅威は残る」とマリンベルノ氏は指摘する。

適切な戦略とアーキテクチャを選定するには

 APIセキュリティを担保していく上では、適切な戦略と、適切なアーキテクチャ選びが必要だ。マリンベルノ氏は、3つのステップでAPIを保護することを提唱した。

 1つ目のステップは「発見」。提供済みのAPIまたは開発中のAPIを棚卸し、すべて洗い出す。それには、サードパーティから使用されるAPIも含める。

 2つ目のステップは「監視」。洗い出したAPIに関して、セキュリティ対策を一度講じるだけでなく、継続的に「監視」していく必要がある。誰がこのAPIをコールしているのか、頻度はどのくらいなのかなど、APIの「通常」の挙動を把握することで、異常を検知できるようにする。何が正常で何が異常か、どうなれば疑わしい状態なのかを定義して、ゲートウェイにそれらのポリシーを設定する。

 3つ目のステップが「セキュリティ保護」。セキュリティは、継続的に実行されるべきもので、一度対策したらそれで完了というものではない。十分なAPIセキュリティ保護を実現するには、開発サイクル全体の変更が必要になる。

具体的に、どの部分に対策を施していくのか

 今、世の中にはさまざまなデバイスが存在しており、それぞれAPIを使っている。

 その次に、論理的なAPI仲介レイヤーがある。たとえばAPIゲートウェイやESB、iPaaSなどがここに実装される。デバイスからのリクエストが送られてくると、API仲介レイヤーを経由してSoR(System of Record)へとAPI接続していく。

 その次のレイヤー、アプリケーション・サービスは、従来型のWebサービスの場合もあれば、マイクロサービスが入っている場合もある。

画像
対策を施すのは論理的なAPI仲介レイヤー

 「そこでよくされる質問は、『どこに対してセキュリティ対策を施したらいいのか』というもの。それに対して私は、『論理的なAPI仲介レイヤーにセキュリティ対策を講じるべき』と答えている」とマリンベルノ氏はいう。

 その理由は、この仲介レイヤーが中心となってやり取りが生じるからだ。APIコールのトラフィック管理、オーケストレーション、監視、収益化、開発者サポートなどがなされる箇所にこそセキュリティ対策を講じることが必要となる。

 そこで重要なのは、「認証」「承認」「API保護」を、この論理的なAPI仲介レイヤーで実行することである。APIにはいろいろな種類があり、APIによって、またユーザーによっても返すデータが異なる。それら異なるデータには、異なるセキュリティポリシーを設定しなければならず、場合によっては認証のやり方を変えることもある。

【次ページ】APIセキュリティを実践するための3つのポイント

開発ツール・開発言語 ジャンルのトピックス

開発ツール・開発言語 ジャンルのIT導入支援情報

PR

ビジネス+IT 会員登録で、会員限定コンテンツやメルマガを購読可能、スペシャルセミナーにもご招待!