APIセキュリティとは

英語によるオリジナルはこちらでご覧いただけます。

APIは企業のデータにアクセスするための入口です。API経由でデータにアクセスするユーザーやサービスは増えています。ユーザーが増えるのは喜ばしいことですが、残念ながら多くの場合は、ユーザーの数に比例してセキュリティリスクも高まります。

だからこそ、APIを提供するすべての企業にとって、APIセキュリティは重要な検討事項です。不正なユーザーからのデータアクセスや、システム全体の乗っ取りによって、何億ドルもの罰金を科されるのは避けなくてはなりません。しかしAPIセキュリティは複雑です。攻撃者がAPIへのアクセス権を手に入れる方法は数多くありますし、セキュリティ戦略にもさまざまなバリエーションがあります。データを守るために、まず何から始めればよいのでしょうか。そのような疑問を解決するために、この記事では、APIセキュリティとは何なのか、APIとAPI攻撃の種類など、APIの安全を守るために知っておくべき基礎知識を解説します。

APIセキュリティとは

APIセキュリティとは、APIが攻撃者から不正アクセスを受けるのを防ぐためにAPI提供者が講じる防御策や対策手順を指します。APIのアーキテクチャの選択から、特定のAPI攻撃に的を絞った防御策の構築に至るまで、APIセキュリティの要素の一つひとつが、ハッカーに対する防御のレイヤーとなります。

ハイレベルな視点で見ると、APIセキュリティには次のような要素があります。

• APIで使用するアーキテクチャとプロトコルの選択
• リスクの特定
• 特定したリスクに対する防御

APIセキュリティの最初の選択項目は、SOAPとREST APIのどちらで行くかという基本的な選択です。

REST APIとSOAPのセキュリティの違い

APIに関する説明でよく目にする言葉に、RESTとSOAPの2つがあります。どちらも通信やデータ転送の手段を表しており、データの作成、更新、削除に使用できますが、この2つには違いがあります。

SOAP（Simple Object Access Protocol）はプロトコルですので、使用方法を定めた正式な仕様が策定されています。SOAPはRESTよりも歴史があって複雑ですが、セキュリティに関する仕組みを備えていることから、パフォーマンスよりもセキュリティが最優先事項となる状況においては現在も有益です。SOAPはHTTPとXMLの仕様のもとでのみ動作します。

REST（Representational State Transfer）はプロトコルではなく、APIを構築するためのアーキテクチャです。プロトコルでない分、仕様という面ではSOAPよりも柔軟です。RESTのアーキテクチャにSOAPのプロトコルを組み合わせて使うこともできます。また、RESTは使用するリソースがSOAPよりも少なく、ペイロードのサイズも小さいことから、一般的にはSOAPよりもパフォーマンスに優れています。

RESTとSOAPにはそのほかに技術的な違いもありますが、要するに最優先事項がセキュリティならSOAPを、パフォーマンスならRESTを使うとよい、ということになります。

RESTful APIを開発するかどうかと、SOAPのプロトコルを使うかどうかを決定したら、あとは攻撃に対する防御に意識を向けていきます。

APIのセキュリティ脅威の種類

攻撃者がAPIへのアクセス権を取得する方法は数多くあります。しかも、APIのさまざまな種類のセキュリティ脅威は、互いの定義が重なり合っている場合があるため、それぞれの内容を理解したり、対処に向けた計画を考えたりするのは簡単ではありません。対策を講じておいた方がよい6つの主な懸念と、それぞれの関係について、以下に説明します。

• • 悪意ある攻撃：悪意ある攻撃とは、意図的な損害を引き起こす行為のことです。例えば、システム内のすべてのデータの改変や破損、削除などの行為が考えられます。

• • 不正アクセス：攻撃者の狙いはデータの破壊とは限りません。外部に漏れてはならない機密データにハッカーがアクセスする不正アクセスも、APIのセキュリティ脅威の1つです。こうしたデータは見られるだけでも重大な損害が生じかねません。

• • インジェクション攻撃：インジェクション攻撃は、悪意ある攻撃か不正アクセス攻撃の少なくとも一方（場合によっては両方）に該当する攻撃です。攻撃者はデータベースに情報を渡すことによって、本来は意図していないアクセス権を取得し、あるいは本来は実行できないデータ追加や削除を実行します。例えば、GETリクエストのパラメータに「OR 1=1」という文字列を付加することで、テーブル内のすべてのデータを取得するという攻撃手法が考えられます。

• • サービス拒否（DoS）攻撃：サービス拒否（DoS）攻撃は、システムへの不正アクセスを許す類の攻撃ではなく、APIに大量のリクエストを送信することによる攻撃です。攻撃者の狙いは、システムに大きな負荷を与え、正規のユーザーがログインできない状態にすることにあります。したがって、この攻撃は悪意ある攻撃の一種にあたります。

• • 認証とセッション管理の不備：認証とセッション管理の不備では、ブルートフォース攻撃によるユーザーのパスワードの推測や、ユーザーの認証情報の傍受、セッション情報の偽造に端を発する攻撃によって、不正アクセスを受けることになります。攻撃者はアクセス権を取得した後、悪意ある攻撃を実行する場合もあります。

• • 暗号化の欠如：APIが暗号化を取り入れていない場合、攻撃者は前述のいずれの手法でも攻撃を成功させやすくなります。また、中間者攻撃を誘導し、APIとクライアントの間のデータのやり取りが攻撃者に傍受される恐れも生じます。

 APIのセキュリティ侵害の影響

APIのセキュリティ脆弱性を見過ごした結果、データ侵害が発生し、それが大々的なニュースになるという悪夢のシナリオは、近年たびたび繰り返されてきました。こうしたデータ侵害では、何百万人ものユーザーのPII（個人情報）が流出し、それにより会社の信用は一夜にして失墜し、収益が大幅に失われる恐れが生じます。

収益が大幅に失われると聞くと、具体的にどの程度の額なのか、気になる人もいるかもしれません。その答えは、流出したデータの種類や状況によって変わってきます。データ流出の結果、プライバシー規約の違反や、HIPAA法（医療保険の携行性と責任に関する法律）などの法令の違反となった場合には、数百万ドルの損失となる場合も考えられます。

2022年現在で我々が把握している範囲で、特に巨額の損失が生じたAPIセキュリティ侵害には、例えば次のようなものがあります。

1. X (Twitter) のAPIセキュリティ侵害 : Xのデータベースに保存されていたユーザーデータ540万件が、APIの脆弱性によって不正なユーザーの手に渡った事例です（他のユーザーのPIIを参照するための認可を得られないはずの認証ユーザーが、PIIの参照に成功していました）。流出したデータはその後ダークウェブで販売されました。Xはこの事例で、ユーザープライバシー規約を遵守しなかったとして1億5000万ドルの罰金を科されました。
2. OptusのAPIセキュリティ侵害: オーストラリアの通信会社Optusの顧客情報1000万人分を人質にとった攻撃者が、同社に100万米ドルの支払いを要求した恐喝の事例です。このセキュリティ侵害が生じた原因は、パブリックAPIのセキュリティの不備にありました。Optusはこの事例で、問題に対処するための費用として1億4000万豪ドルを計上しました。内訳は、対象となった顧客向けの信用監視サービスや代替IDの費用、第三者レビューの費用などです。
3. Beetle EyeのAPIセキュリティ侵害: メールマーケティングキャンペーン企業のBeetle Eyeで、700万人の顧客の個人情報が流出したデータ侵害の事例です。AWS S3のバケットの設定ミスにより、暗号化が適用されていなかったことが原因でした。同社が受けた影響はまだ完全には明らかになっていませんが、Data Breach Todayの記事では研究者の話として、「米国の消費者データの取り扱いを誤った場合の罰金は最高1億ドルで、責任者の逮捕もあり得る」と説明しています。

これらの事例が示すように、APIの侵害により、企業はきわめて深刻で実際的な影響を被る恐れがあるのです。しかし幸いなことに、こうした事態を防ぐための手段はあります。

APIセキュリティのフレームワーク

セキュリティ脅威の種類には重複する部分がありますが、それと同様に、APIのセキュリティ対策にも重複する部分があります。それがこの問題のややこしいところです。APIセキュリティの選択肢と、それぞれの関係を見ていきましょう。

APIのアーキテクチャ（REST）やプロトコル（SOAP）とは別に、APIセキュリティのフレームワークを選ぶことができます。取り入れるセキュリティ機能は、そのフレームワークを参考にして判断していくことになります。セキュリティフレームワークというのは、APIセキュリティに対する大局的なアプローチだと考えてください。フレームワークを選ぶことによって、そのフレームワークを遵守し続けるために必要なセキュリティ対策についての指針が得られます。

背景を理解するために例を見てみましょう。APIセキュリティで特に広く用いられているフレームワークには、ゼロトラストとOWASP Top 10という2つがあります。

ゼロトラストセキュリティモデル

ゼロトラストセキュリティモデルとは、APIがユーザーやデバイスを信用しないことを前提として成り立っている一連の原則です。ネットワークの内部か外部かを問わず、APIとの認証が完了していないユーザーやデバイスを一切信用してはならないとし、有害と証明されるまでは無害とみなすという考え方の真逆です。

ゼロトラストでは、社内ユーザーからの攻撃や、社内ユーザーになりすました攻撃者からの攻撃を防御できます。クラウドで事業を展開する場合でも、あるいはオンプレミスネットワークで業務を進める場合でも、優れた戦略となります。

ゼロトラストはセキュリティフレームワークですので、どちらかと言えば、APIセキュリティについての意思決定の際に従うべき一連の指針や原則という存在です。したがって、ゼロトラストセキュリティモデルの実装には、OAuthやトークン認証（詳しくは後述）など、一般的なセキュリティ手法の多くを取り入れることができます。

OWASP Top 10

OWASP Top 10とは、APIのセキュリティ脆弱性のトップ10をまとめたものです。OWASP Top 10を軸とするフレームワークを採用する場合には、OWASPがAPIセキュリティの最優先事項と認定した分野に関して、セキュリティを強化していくことになります。そのためには、トップ10の脆弱性の説明を理解したうえで、その防御のために実装できるセキュリティ対策をピックアップしていきます。

OWASP Top 10の最新版である2023年版で選出された脆弱性は次のとおりです。

1. オブジェクトレベルの認可の不備

2. ユーザー認証の不備

3. オブジェクトプロパティレベルの認可の不備

4. 制限のないリソース消費

5. 機能レベルの認可の不備
6. 機密性の高いビジネスフローに対する制限のないアクセス
7. サーバーサイドリクエストフォージェリ
8. セキュリティの設定ミス

9. 不適切なアセット管理

10. APIの安全でない使用

これらの脆弱性には、この記事でこれまでに出てきた種類の攻撃と同じ意味を持つものが多くあります。OWASPは、この10項目の脆弱性のそれぞれに対して、わかりやすい具体例を示しています。以下は、オブジェクトレベルの認可の不備として出ている例です。

ある自動車メーカーが、運転手のスマートフォンと通信するためのモバイル向けAPIを使用して車のリモート制御機能を実現しました。このAPIにより、運転手はエンジンの始動・停止やドアの解錠・施錠を遠隔地から行うことを可能にしました。その過程で、ユーザーは車両識別番号（VIN）をAPIに送信します。このAPIは、送られてきたVINがログインユーザーの所有する車両に合致するかどうかを検証できず、オブジェクトレベルの認可の不備の脆弱性（BOLA脆弱性）につながります。これにより、攻撃者は自らが所有していない車両にアクセスできます。

またOWASPは、それぞれの脆弱性を緩和するためのヒントも示しています。このヒントはAPIセキュリティ戦略を構築するうえで役立ちます。

強固なAPIセキュリティ戦略

APIセキュリティフレームワークの種類を検討した後は、そのフレームワークを自分で導入する方法が気になってくるかもしれません。導入にあたっては、選択したフレームワークの要素に照準を合わせた、強固なAPIセキュリティ戦略を確立するとよいでしょう。

ゼロトラストの場合は、信用を一切前提としない最先端の認証に照準を合わせます。OWASP Top 10の場合は、先ほど挙げた脆弱性に照準を合わせます。

APIに新たなセキュリティのレイヤーを加えつつ、APIセキュリティのフレームワークの指針を満たすことのできる構成要素は数多くあります。特に広く使われているのは次のような要素です。

• APIゲートウェイ

• OAuthとOpenID Connect

• トークンと暗号化

• スロットリングとクォータ

これらを1つずつ見ていき、APIをどのように防御できるかを理解しましょう。

APIゲートウェイ

当社はAPIゲートウェイを専門としていますので、多少ひいき目があるかもしれませんが、APIのセキュリティを強化できる多目的ツールがご希望なら、APIゲートウェイを利用するとよいでしょう。

APIゲートウェイはクライアントとAPIの間に位置するツールで、バックエンドの複数のシステムにわたってAPIマネジメントのルールを適用します。APIゲートウェイを使用して、広く利用されている他のセキュリティレイヤー（認証／OAuth／トークン認証）やアクセス制限（スロットリング／レート制限）をいくつか導入し、多数のセキュリティ機能に1つのツールで対応できます。APIゲートウェイをうまく選べば、複数のプロトコル、テクノロジ、言語への対応も可能です。

APIを提供しているエンタープライズレベルの企業の多くは、APIゲートウェイを利用しています。その理由は、単にセキュリティが向上するだけでなく、複数のサービスからのレスポンスを集約してワンストップで提供することで、ユーザー体験も向上するからです。

以下に示す残りの防御策は、必要に応じて個別に導入することも可能ですが、APIゲートウェイを使ってまとめて導入できます。

OAuthとOpenID Connect

OAuthはユーザーを認可するためのオープンソース標準です。アクセストークンを使って、APIにアクセスするユーザーを認可します。その際、本人のIDの証明には、別のサービスによる認証（例えばGoogle経由でのログイン）を利用します。この仕組みによって、不正アクセス攻撃や、認証の不備に伴う攻撃を防ぎます。

OAuthは認可のレイヤーについて規定しているのに対し、OpenID Connectは認証のレイヤーについて規定しており、ログインユーザーに関する追加のIDとプロフィール情報を提供します。OAuthとOpenID Connectを組み合わせると、シングルサインオン（SSO）を活用できるようになります。ユーザー側はログインがしやすくなり、API側はセキュリティを確保できます。

OAuthとOpenID Connectは、ベーシック認証をはじめとする他の手法に比べて、はるかにセキュアです。さまざまな種類の認証と認可について詳しくは、APIの認証と認可の解説記事をご覧ください。

トークンと暗号化

トークン認証というのは、OAuthのアクセストークンとは別の話です。トークン認証では、APIトークンを使って、ユーザーがAPIに対する認証をSSOなしで行うことができます。APIトークンによって、APIへのアクセスが限られた時間内だけ認められ、その後はアクセスが取り消されます。セキュリティを確保するために、トークンは暗号化する必要があります。つまり、宛先に届くまでは判読できないようにしておき、キーを使って復号します。このような仕組みにすることで、不正アクセスや、暗号化の欠如に伴う攻撃を防いでいます。

スロットリングとクォータ

スロットリングとクォータは、APIとの間で送受信可能なデータの量と伝送速度に制限を設けるものです。このような制限があると、攻撃者が過剰なリクエストを送信してシステムに過大な負荷を与えようとしても、自動的にストップがかかります。サービス拒否（DoS）攻撃を防ぐためにはスロットリングとクォータを使用するとよいでしょう。スロットリングとクォータの導入にはAPIゲートウェイを使うのが最も簡単かつ安全です。

まとめ

ここまで見てきたように、APIのセキュリティ確保に関しては、選択すべき点が数多くあります。まとめると、APIセキュリティの基本となるのは次のような要素です。

1. アーキテクチャとプロトコルの決定（RESTとSOAP）

2. APIセキュリティ攻撃の種類と、それらが組織に与える影響についての理解

3. セキュリティフレームワークの選択

4. APIセキュリティ戦略の構築

しかし、ここまでに取り上げなかった要素がもう1つあります。それは、自社にとっての最優先事項を特定することです。そうすることで、一連のセキュリティ対策のうちで採用の緊急性が特に高いのはどれなのかを判断しやすくなります。

作業に取りかかるうえでの一般的な指針は次のとおりです。

• エンタープライズレベルの企業や、非常に機密性が高いPII／PHI（個人健康情報）を取り扱う企業は、この記事で取り上げた防御策をできるだけ多く取り入れましょう。特にSOAPは、高度なセキュリティを備えており、うまく適合することが考えられます。またAPIゲートウェイは、多面的なセキュリティフレームワークを実践するうえで必要な処理を統合できます。
• 規模が小さい企業で、APIのパフォーマンスを最適化する必要がある場合や、機密性が高いデータをあまり扱わない場合には、REST APIと、トークン認証またはOAuthの採用を検討します。

迷ったときは、高いセキュリティを備える方を選びましょう。APIのセキュリティを確保することは、その労力に十分見合うだけの価値があります。今回取り上げたAPIセキュリティの基礎知識があれば、独自のセキュリティ戦略の構築に取りかかることができます。

一方、厄介な作業を任せられるAPIセキュリティチームをお探しであれば、ぜひチャットでご相談ください。KongのAPIゲートウェイは、あなたの企業のAPIセキュリティを強化します。

社内のAPIとマイクロサービスを管理しましょう。Kongの統合プラットフォームをぜひお試しください。

製品のお問い合わせやデモのご依頼はこちらから