APIセキュリティとは?

現代のインターネットの多くは、APIに依存して機能しています。APIセキュリティとは、APIを攻撃やデータ漏えいから保護するプロセスです。

学習目的

この記事を読み終えると、以下のことができるようになります。

  • 一般的なAPIセキュリティの脅威を理解する
  • APIの認証と認可について説明する
  • APIを安全に保つための技術について説明する

記事のリンクをコピーする

APIセキュリティとは?

アプリケーションプログラミングインターフェース(API)は、あるソフトウェアが別のソフトウェアとやりとりするための仕様です。プログラムまたはアプリケーションにAPIがあれば、外部のクライアントがそのプログラムに対してサービスを要求することができます。

APIセキュリティとは、APIを攻撃から守るためのプロセスです。アプリケーション、ネットワーク、サーバーが攻撃の対象になり得るのと同様に、APIもさまざまな脅威の犠牲になる可能性があります。

APIセキュリティは、Webアプリケーションセキュリティの中核となる要素です。現代のほとんどのWebアプリケーションは機能するためにAPIを使用しており、APIは外部からアプリケーションにアクセスすることを可能にすることで、アプリケーションにさらなるリスクを生み出しています。例えるなら、オフィスを一般に公開している企業のようなものです。同様に、APIは部外者がプログラムを使用することを可能にするため、APIサービスのインフラストラクチャにさらなるリスクをもたらします。

一般的なAPIのセキュリティリスクにはどのようなものがあるか?

  • 脆弱性攻撃:脆弱性攻撃とは、攻撃者が特別に細工したデータ、つまり標的にある構造上の欠陥を利用したデータを標的に送信することです。これらの欠陥は「脆弱性」と呼ばれ、攻撃者によってAPIやそれに対応するアプリケーションに対する意図しない様々な形式でアクセスされる可能性があります。 Open Web Application Security Project(OWASP)は、SQLインジェクション、セキュリティの設定ミスなどを含むAPIの脆弱性トップ10リストを管理しています。まだ把握されていない悪用可能な脆弱性がある場合、これはゼロデイ脅威と呼ばれます。このような脅威を阻止することは非常に困難です。
  • 認証ベースの攻撃:クライアントは、APIサーバーが不明または不正なソースからのリクエストを受け入れないようにAPIリクエストを行う前に認証を行う必要があります。これを行うにはいくつかの方法があるが、どの方法も侵害される可能性があります。例えば、正規のクライアントの認証情報が攻撃者の手に渡ったり、APIキーが盗まれたり、認証トークンが傍受されて使用されるなどの可能性があります。
  • 認証エラー:認証によって各ユーザーが持つアクセスのレベルが特定されます。認可が慎重に管理されていない場合、APIクライアントは本来利用できないはずのデータにアクセスすることができる可能性があり、データ漏えいの可能性が高まります。
  • DoS攻撃とDDoS攻撃:過剰なリクエストがAPIに向けられると、他のクライアントのサービスを遅くしたり停止させてしまうことがあります。サービス拒否(DoS)または分散サービス妨害(DDoS)攻撃を使用して、意図的にAPIに大量のリクエストを向ける攻撃者もいます。

APIセキュリティ対策は、これらのリスクやその他のリスクの軽減にも役立ちます。

強力な認証・認可対策により、データの漏洩を防ぎ、許可されたクライアントのみがAPIリクエストを行うことが保証されます。DDoS攻撃対策とレート制限により、DDoS攻撃をシャットダウンすることができます。スキーマの検証とWeb アプリケーションファイアウォール(WAF)を使用することで、脆弱性の悪用をブロックすることができます。

レート制限とDDoS軽減は、APIの保護にどのように役立つか?

レート制限は、個人が特定の時間枠の中でアクションを繰り返すことができる回数に上限を設定します。APIクライアントが許可されたリクエストの数を超えた場合、レート制限は一定期間、そのクライアントからの更なるリクエストを破棄またはブロックします。

DDoS軽減は、DoS攻撃やDDoS攻撃を阻止するのに役立ちます。DDoS攻撃は、攻撃者は短時間に大量のリクエストでAPIを圧倒しようとします。多くの場合、これらのリクエストは複数の異なる送信元ソースからやってきます。

レート制限とDDoSの軽減は、いくつかの理由からAPIにとって非常に重要です。

  1. DoS攻撃およびDDoS攻撃の阻止。レート制限とDDoS軽減によって過剰なリクエストをブロックまたは破棄することで、APIは過剰な負荷から保護されます。レート制限だけではローアンドスローDDoS 攻撃を阻止することはできない場合もありますが、DDoS軽減はそれに関係なく過剰なトラフィックを吸収することができます。
  2. 意図的な攻撃以外では、単純に一部のクライアントがAPIを使い過ぎている場合があります。これはAPIサービスにとって演算処理能力のコストが増加し、他のクライアントのサービスを低下させる可能性があります。レート制限によって、APIサーバーが過負荷になるのを防止することができます。

脆弱性の悪用をブロックする方法は?

脆弱性を悪用するには、悪意のあるAPIリクエストが、設計者が意図していない方法でAPIを応答させるように構成されている必要があります。API開発者がそのような悪意のあるリクエストをブロックする方法はいくつかあります。その中でも特に知っておくべき重要なものは、以下の2つです。

  1. スキーマの検証
  2. WAFルール

スキーマの検証

APIのスキーマには、APIがどのようなリクエストを受け、どのようなレスポンスを返すべきかといった、APIに期待される振る舞いが記述されています。このスキーマに従わない無効なリクエストは、APIに予期せぬ振る舞いをさせ、データ漏洩を引き起こす可能性があります。スキーマの検証によって、無効なリクエストとレスポンスが特定されます。無効なレスポンスをブロックすることで、API開発者はある種の攻撃を回避し、データ漏えいを防ぐことができます。

Webアプリケーションファイアウォール(WAF)ルール

WAFは、従来のファイアウォールと同様に、一部のネットワークリクエストとレスポンスをブロックし、それ以外を許可することで機能します。これは一連のルールに基づいて行われ、リクエストやレスポンスがルールに違反する場合(またはルールに適合する場合)にブロックされます。WAFは、APIやWebアプリケーションの前衛に設置されてHTTPトラフィックを監視します。

脆弱性を狙ったリクエストやレスポンスのパターンをブロックするWAFルールを設定することが可能です。また、WAFルールは、特定のIP アドレスからのリクエストをブロックすることができ、bot攻撃などを阻止することができます。

APIセキュリティで認証と認可が重要な理由は?

認証により、APIリクエストが正当なソースから来たものであることが保証されます。認証によって、リクエストしたクライアントに要求されたデータを取得する権限があるかどうかがAPIサーバーに伝えられます。

アリスがAPIを構築し、ボブがアリスのAPIを利用するWebアプリケーションを構築したとします。ボブのアプリケーションがアリスのAPIにAPI リクエストを送る際に、ボブはリクエストに「this is from Bob」というラベルを付けます。これによりボブのリクエストが認証され、アリスの API サーバーがそのリクエストを正当なものとして扱うことができるようになります。

また、アリスのAPIサーバは、ボブがどのような権限を持っているかもチェックします。もしボブのリクエストが、アリスのAPIに「Bob can see this」と表示されているデータに対するものであれば、サーバーはそのリクエストに応えます。しかし、アリスの API に「not for Bob」というラベルのついたデータセクションがあり、リクエスト者がボブである場合、サーバーはこのデータに対するリクエストには応えません。これが認可が重要な理由です。

(実際には、ボブはAPIリクエストに「this is from Bob」というラベルだけでなく、キーや他の認証形式も付加します)

APIの認証方法にはいくつかあります。最も一般的なものには以下のものがあります。

1. APIキー

クライアントには、クライアントとAPIサービスだけが知っている一意の文字列であるキーが割り当てられます。このキーは、各APIリクエストに付加されます。APIサーバーはAPIリクエストを受け取ると、それが認証されたクライアントからのものであるかどうかを確認するために、このキーをチェックします。

この認証方式の欠点は、キーが盗まれた場合、攻撃者はそれを使用して正規のクライアントになりすまし、さまざまな攻撃を仕掛けることができてしまうことです。Transport Layer Security(TLS)のような暗号化プロトコルを使用して、APIへのリクエストとレスポンスを暗号化することが重要になります。こうすることで、キーがインターネット上を行き来する際に平文でさらされることはありません。

2. ユーザー名とパスワード

APIリクエストでは、一般的なユーザー名とパスワードの認証情報を使用するHTTP認証と呼ばれる方法を用いることができます。HTTP認証では、ユーザー名とパスワードがエンコードされ、すべてのAPIリクエストのHTTPヘッダーに追加されます。サーバーは、これらの資格情報を、許可されたクライアントの資格情報と照合して、リクエストを認証することができます。

この方法は、一般的なパスワードに関連するあらゆる課題(紛失、漏えい、盗難、推測、信頼できない相手との共有など)を含んでいます。また、パスワードはクレデンシャルスタッフィングブルートフォース攻撃などの対象になります。

3. OAuthトークン

APIサーバーは、クライアントから直接認証を要求する代わりに、OAuthプロトコルを使用して、信頼できる認証サーバーから認証トークンを取得することができます。APIを利用するために、ユーザーはAPIに直接ログインするのではなく、サードパーティのサービスにログインします。ユーザー名とパスワードによるアプローチと同様に、この認証方法は、クレデンシャルスタッフィングやその他の攻撃に対して脆弱性があります。

4. 相互認証TLS(mTLS)

TLSは、Webページを読み込む際にクライアントとサーバーの間に暗号化された認証済みの接続を作成するための暗号化プロトコルです。また、TLSはAPI接続の両端を検証して認証することができます。

相互TLS認証(mTLS)では、クライアントとサーバーの両方がTLS証明書を持ちます。これらの証明書を使用してお互いを認証し、パスワードや他の認証方法に依存することなく、両者が主張する人物であることを確認します。

しかし、mTLSは実装が難しい場合があります。すべてのAPIエンドポイントとクライアントには正規のTLS証明書が必要ですが、これを適用・維持するのは困難な場合があります。

API Shieldとは?

Cloudflare API Shieldは、一般的なAPIセキュリティリスクから保護するために、1つのダッシュボードから複数のAPIセキュリティ機能を使用できるようにしています。API Shieldには以下のような機能があります。

  • APIエンドポイント認証用のmTLS
  • APIのスキーマに準拠したリクエストのみを許可する、ポジティブセキュリティモデルを使用したスキーマの検証
  • データ損失防止(DLP)で、APIから発信されるトラフィックをスキャンして、機密データをチェックする
  • レート制限とDDoS軽減により、APIに過剰な負荷がかからないようする

API Shieldの詳細についてご覧ください