APIセキュリティについての最新記事

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

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

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

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

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

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

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

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

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


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

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

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

　現在では「OAuth（オーオース）」が銀行のアプリケーションでは使われており、方法として有効である。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セキュリティを実践するための3つのポイント