ブログ

ビジネスを保護するということは API を保護するということです

ロリ・マクヴィッティ サムネイル
ロリ・マクヴィッティ
2019年11月4日公開

API は、アプリケーション層で抽象化する機能を通じて価値を生み出します。 たとえば、API を使用して内部システムやデータへのアクセスを抽象化すると、従来の IT システムへのアクセスを簡素化および自動化できるようになります。 API は、エコシステムへの統合やパートナーとの統合を実現する手段でもあります。 API は今日、自動化とオーケストレーションの主な手段でもあり、デジタル変革を成功に導くための重要なテクノロジーの 1 つとなっています。 したがって、API はイノベーション、効率的な実行、収益化の源として企業にとって戦略的なものになっています。

収益化 

デジタル経済では、収益を生み出すものはすべて最終的に収益化されます。 これは特に API に当てはまり、調査によると API エコノミーは強力であることがわかっています。

  • 企業の 10 社中 1 社以上 (11%) が、収益の半分以上を API および API 関連の実装から得ています。 ( API のビジネス価値) 
  • 驚くべきことに、59% の企業が組織の収益の 26% ～ 50% を API から生み出しています。 ( API のビジネス価値)

統合

API は、ESB や Web ベースのポータルに代わって、ビジネス間統合の主な手段として使われるようになりました。 デジタル経済におけるビジネスの成功のための戦略的要素としての API への依存は、十分に文書化されています。

    o 60% 以上が、API 統合がビジネス戦略にとって重要であることに同意しています。 ( API 統合の現状 2018 )

    o すべての B2B コラボレーションの 50% 以上が API 統合を介して行われます。 ( API 統合の現状 2018 )

    o 51% が、API 開発の決定における主な原動力として「外部組織との提携」を挙げています。
        ( 2019 年の API の現状) 

ビジネスやマイクロサービスなどの最新のアプリケーション アーキテクチャは API に依存しているため、これらのエンドポイントへのアクセスや制御の価値を理解している攻撃者にとって、特に魅力的なターゲットとなります。 このリスクは、API レイヤー、特にそれらが表すビジネス機能へのアクセスのセキュリティ保護にさらに注意を払う必要があることを意味します。

認証は必須です

API のセキュリティはアクセスから始まります。 それは認証を意味します。 オープン API は、API アクセス モデルの説明ではありません。 これは、API が適切に文書化されており、標準に準拠していることを意味する属性です。 API の呼び出しには常に認証が必要であり、最適には承認も必要です。

利用できるオプションはいくつかありますが、選択する前に、それぞれの機能と制限を理解しておく必要があります。

  • 良い： HTTP 基本
    HTTP 基本認証がデフォルトです。 これは、今日のほとんどの API など、HTTP ベースのトラフィックの認証を強制する最も簡単で一般的な方法です。 Basic Auth の欠点は、資格情報が必要になることです。周知のとおり、資格情報は複数のアプリケーション間で共有されることがよくあります。 盗まれた（または公開された）資格情報は、攻撃者がシステムにアクセスするために使用する手段になりつつあります。 パスワードの強度と保存場所/方法も、この方法の全体的なセキュリティに影響します。 何もしないよりはましだ。
  • より良い： APIキー
    API キーは発行者によって発行される (そして追跡されると思われる) ため、HTTP 基本認証よりも一歩進んだものです。 API キーは配布され、計測や課金など、セキュリティ以外のさまざまな目的で使用されます。 ただし、これらは一般的に静的であるため、第三者が抽出して、正当なユーザーになりすますために使用される可能性があります。 キーの共有も現実的な問題です。 資格情報と同様に、キーは同僚や家族と共有できます。 そして、それらが広まれば広がるほど、悪意を持った誰かに拾われて使用される可能性が高くなります。
  • 最高： 期限切れトークン
    API の数が増えるにつれて、トークンの使用がより一般的になりました。 現在最も人気があるのは、OAuth トークン (API 専用) と JWT (JSON Web トークン) の 2 つです。 HTTP ベースのリソースへのアクセスに関するクレームを交換するための標準形式として JSON が使用され、API 外での適用が可能になったことで、JWT は現在、認証と承認のための最も一般的なメカニズムの 1 つになりました。 RFC (7519)もあります。 XML の兄弟である SAML と同様に、認証されたユーザーのアクセス範囲と役割を記述する JSON アサーションが発行されます。 移植性が高く、重要な点として有効期限が設定されているため、認証されたユーザーになりすますのに簡単に使用することはできません。 欠点は、トークンを統合するにはより多くの作業が必要であり、必ずしもネイティブでサポートされているわけではないことです。 これにより、実装時にミスが発生し、意図せずして悪用される可能性が生じる可能性があります。

API セキュリティはアプリケーション内に直接実装できますが、API ゲートウェイ内に実装する方がよいでしょう。 API ゲートウェイは、レート制限 (偶発的または意図的なサービス拒否攻撃を防ぐため) や承認などの機能を使用して、API をさらに保護できます。 承認は、通常はトークンまたは API キーによって識別される指定されたクライアントのみに特定の API 呼び出しへのアクセスを許可することで、API へのアクセスを絞り込みます。 API ゲートウェイは、使用される HTTP メソッドを制限し、他のメソッドを悪用する試みをログに記録して、攻撃の試みを認識できるようにすることもできます。

アプリケーションに依存しているということは、アプリケーションが依存する API も保護する必要があることを意味します。 まだ基礎から始めていないなら、今すぐ始めましょう。 ビジネスを保護したい場合は、安全な API が必要になります。