アプリケーションプログラミングインターフェイス (API) セキュリティの初心者ガイド

この記事では、API の開発の歴史、その基本概念、機能、関連プロトコル、使用シナリオを簡単に概説し、さまざまなセキュリティ要素、脅威、認証方法、および API に関連する 12 の優れた実践例に焦点を当てます。

記録された歴史によると、最初の Web API は 1990 年後半、Salesforce のセールスオートメーションソリューションの導入とともに登場しました。当時、これは誰もがアクセスできるオープンリソースでした。Salesforce の自動化ツールは XML によって駆動されます。ツールの情報を交換するために使用されるデータ形式は、後に SOAP API 標準として認識されました。これには、コード固有のルールだけでなく、さまざまなリクエストの許可または不許可に関連するメッセージ形式の仕様も含まれています。つまり、ほとんどの開発者は、API の開発と作成に必要な SOAP 処理に加えて、RPC で XML ドキュメントを手動で使用する必要があります。その後、開発者は API のエンドポイントを解釈し、SOAP スイートをそのエンドポイントに公開する必要があります。これは API の誕生であるだけでなく、SaaS の概念の始まりでもあります。

最新の API を形成した主な出来事は、Flicker API と Facebook API の導入でした。Flicker は、クラウドを通じてデジタル画像を保存するためのプラットフォームを開発しました。これは、API の開発により異なるプラットフォーム間での画像共有をサポートし、さまざまな写真共有施設の新しいサービスを統合します。

2008 年までに、API は独立して動作し、相互接続された膨大な量の情報を処理できるように進化しました。API を起動することで、Twilio は通話やテキストメッセージなど、製品全体のさまざまな部分をユーザーが簡単に接続できるようにします。

APIとは何ですか?

まず、API とは、2 つの異なるアプリケーション間の流動的な通信を可能にするように設計されたアプリケーションプログラミングインターフェイスを指します。アプリケーションの「仲介者」と呼ばれることがよくあります。ユーザーが保持するデータとアプリケーション自体の整合性を保護する必要があるため、API セキュリティは「必要不可欠」です。

開発者にとって、API は優れたツールです。マイクロサービスとコンテナーの間で情報を交換し、高速な通信を可能にします。統合と相互接続がアプリケーション開発にとって重要であるのと同様に、API はある意味でアプリケーション設計を推進し、強化します。

API がインターネットを席巻

インターネットの初期の頃、API は独自のプロトコルとして、ネットワーク内の制限された領域、目的、または組織でよく使用され、さまざまなネットワークアーキテクチャでの通信とコンピューティングを可能にしました。Web 2.0 の出現後、Web ベースのツールが広く登場し、人々はコミュニティ開発仕様である REST (REpresentational State Transfer Framework) を使用して、共通の OpenAPI などの実用的なアプリケーション用の API インターフェイスを構築し始めました。

今日の Web 3.0 時代では、API は IoT と AI 搭載デバイス間の通信において重要な役割を果たしています。API の通常のリクエストとレスポンスのパラダイムも、イベント駆動型のアプローチに移行しました。

APIの使用例

API は情報交換を容易にするための基本要素として、Web アプリケーション開発の分野で広く使用されています。現在、業界で最も一般的に使用され、最も重要な API の使用例は次のとおりです。

シングルページアプリケーション (SPA)

REST API は、シングルページアプリケーションの開発を高速化するだけでなく、アプリケーションがすべてのコンテンツを 1 ページに配置して完全なユーザーエクスペリエンスを提供するのにも役立ちます。アプリケーション開発中に、プログラマは事前定義された CSS、JavaScript、および HTML ファイルを使用して、Web サーバー間の通信を開始できます。REST フレームワークは、サーバー側の通信や、特定の種類のフレームワークのクライアント側の情報交換によく使用されることに注意してください。

SPA 開発に一般的に使用される REST API フレームワークには、NancyFx、Express.js、ASP.Net WebAPI などがあります。ステートレスフレームワークである REST API は、クライアントがリクエストごとに 1 つ以上のサーバーを呼び出すことに煩わされません。したがって、SPA 開発に REST API を使用すると、アプリケーションのスケーラビリティを向上させることができます。これにより、開発者がアプリケーションを拡張するコストが削減されるだけでなく、アプリケーションが特定のリソースにアクセスする必要がなくなることは明らかです。

SPA 開発では、REST API ドキュメントを除けば、他の要素はクライアントとサーバーにバインドされません。したがって、この独立性により、アプリケーションの開発、テスト、展開における柔軟性が促進されます。そして、これはまさに動的 Web フレームワークでは達成できないことです。

パブリック API、エンタープライズレベルの B2B

電話、ファックス、電子メールは長い間、B2B 業務の主要なコミュニケーション手段でした。ただし、IoT ベースの情報交換のニーズを満たすために、RESTful API はエンタープライズレベルの B2B 通信の自動化において重要な役割を果たすことができます。

顧客の観点から見ると、パブリック API を公開することで、企業は消費者向けアプリケーションを作成し、外部世界とのコミュニケーションを最大限に高めることができます。同時に、パブリック API により B2B クライアントはさまざまなユーザーベースの動作を拡張できるため、コスト負担を増やすことなくビジネスプロセスを完全に分離し、マシンベースの相互運用性を強化します。

プライベート API と内部 API サービス

プライベート API を使用すると、B2B 顧客は市場投入までの時間を短縮し、既存のワークフローをボトルネックにすることなく新しいアプリケーションやツールのオンボーディングを加速できます。内部ワークフローを管理する場合、プライベート API は企業が再構築および最新化するための構成可能な領域を特定できます。また、創造的なプロセスとして、コンポーザブルビジネスモデルは、複雑な機能を管理可能なマイクロパーツに分解できます。プライベート API は、組織内のすべてのレベルで効率的なコミュニケーションを可能にすることで、リソースの戦略的な使用を促進します。

内部 API が運用障害の考えられるさまざまな原因に関する詳細な情報を提供し、システムコンポーネントの応答時間を改善するため、ビジネスインテリジェンス分析の結果がより正確になります。また、プライベート API を使用すると、アプリケーションのコラボレーション機能と情報交換機能がより高速かつ安全になります。

サービスメッシュ

インフラストラクチャ層のコンポーネントとして、サービスメッシュは高度に構成可能で、遅延が低くなります。通常、大規模な内部通信を処理するためにネットワーク構造で使用されます。グリッドを賢明に使用することにより、開発者は、さまざまなコンテナ化された一時的なアプリケーションに対して、高速、安全、信頼性の高い情報交換を保証できます。

API は、サービスメッシュでの情報交換に使用できます。しかし、メッシュのデータプレーンがシステムを通過するすべてのパケットまたはリクエストと通信する場合、事態はさらに複雑になります。したがって、ユニバーサルデータプレーンや xDS などの API を使用すると、この種の作業を簡素化できます。システムの健全性をチェックし、そのパフォーマンスを監視し、さまざまな受信または送信リクエストをルーティングし、負荷分散方式でシステムトラフィックのバランスをとり、サービスディスカバリを通じてユーザー認証関連の誤操作を検出できます。

モバイルバックエンド

モバイルバックエンドは、新しいサービス配信モデルとして、モバイル最適化ソリューションの開発でよく使用されます。Mobile Backend as a Service (MBaaS) として知られるこの開発モデルにより、開発者は、ユーザー管理、プッシュ通知、ソーシャルログインプラグインなどのコンポーネントを含むサーバーおよびサーバー関連ツールを自由に保守できるようになります。

MBaaS の各リソースは、柔軟な SDK を使用して API のエンドポイントに接続します。たとえば、MBaaS は、Flutter、Unity、Iconic、React Native などのテクノロジーを使用して、Android および iOS オペレーティングシステム用のフロントエンドアプリケーションを開発します。同時に、MBaaS プラットフォームのさまざまな API により、ワークフロー管理、通知更新、タスク計画などの面で開発者の自動化を実現できます。

さらに、これらの API は、使用されるさまざまなシステムやサービス間でのシームレスな情報交換を可能にするアプリケーション層を生成できます。開発者は、新しく追加されたユーザークラスター向けに、ニーズに基づいたさまざまなサービスを設計することもできます。

モノのインターネット (IoT)

IoT デバイスは、情報交換を行うために他のネットワークユーザーのクライアントまたはデバイスに接続する必要があるため、API を使用する場合、交換された情報の公開が避けられないことがよくあります。これを行うには、開発者は、外部と対話するために UI を直接使用しない、十分に安全なコンテキストベースのアプリケーションを作成する必要があります。

REST API は現在、IoT デバイスの実世界のシナリオで使用される最も一般的な API であり、インターネットプロトコルを介して情報を交換します。さらに、REST API を使用すると、開発者は認証および認可戦略を強制することもできます。

さまざまな人々から見た API

API の多様性はさまざまなアプリケーションシナリオで使用されることが多く、役割が異なる開発者は API についての理解も異なります。

バックエンド開発:

フレームワーク: 運用とプロセスがどのように機能するかを定義する、よく構造化された計画または戦略。
仕様: REST や OpenAPI などの機能を説明する Swagger ベースのドキュメント。たとえば、Geo PC コンテンツに関連するある種の GraphQL スキーマ。
データとビジネスロジック: バックエンド開発者は、クライアント (モバイルアプリやブラウザーなど) 間でデータとロジックを分離することを好みます。これは、独自のコードやデータにメリットをもたらします。たとえば、シングルページアプリケーションとモバイルアプリケーションは、同じデータと API を使用してさまざまなカスタム統合を処理できます。
統合されたモバイル、Web、および統合バックエンドにより、同期プロセスが改善および簡素化されます。

DevOps：

運用環境の仕様を満たす: たとえば、エンドポイントが 502 エラーを頻繁に返す場合は、API を使用して修正することを検討する必要があります。
スケーラビリティ: 504 エラーを解決するためにエンドポイントをスケーリングする必要がある場合は、これに関連するマイクロサービス、最適なフロー、問題を解決する方向 (たとえば、GraphQL の REST API) を把握する必要があります。

API の動作のフローチャート

安全性：

新しいプロトコル: アップグレードを停止するファイアウォール、スキャナー、その他のレガシーツールにどう対処するか?
東西 (東西、つまり、さまざまなバックエンドアプリケーションとデータベースの間であり、よく言われる南北のセキュリティとは異なります) セキュリティ: ネットワーク内の通信の適切な監視が不足しています。
新しいセキュリティ、ネットワーク、またはその他の IT コンポーネントのコンプライアンス要件。

API セキュリティの重要性

前述したように、API と API セキュリティは密接に関連しています。セキュリティが不十分な API は、ハッカーによって公開され、攻撃されることがよくあります。また、API は主に情報の交換、サービスの接続、データの送信に使用されるため、ひとたびデータ漏洩が発生すると企業に多大な損失をもたらします。

APIの各種認証方法

API の不適切な使用を防ぐために、ユーザーにアクセスを許可する前に、API リソースを表示または編集しているユーザーの実際の身元を確認する必要があります。

1. ホストベースの認証

このプロセスにより、ホストまたはサーバーを認証することで、認証されたユーザーのみがサーバーにデプロイされたリソースにアクセスできるようになります。プロセスを開始するためにキーなどは必要ありません。ただし、サーバーには、DNS スプーフィング、ルーティングスプーフィング、IP スプーフィングなどのイベントを制御するために、ログインキーをリアルタイムで検証する機能が必要です。

ホストベースの認証は、プロセスと実装において RSA と非常によく似ています。デフォルトでは、パラメータを設定する必要はありません。ホストベースのユーザー認証は、管理者がローカルホストの秘密キーを作成するか、ローカルホストの公開キーを抽出することによって実行できます。

2.ベーシック認証

これは、最も簡単な API 認証スキームの 1 つです。クライアントは事前に構築されたヘッダーを含む HTTP 要求を送信するため、このメソッドは HTTP プロトコルとプロセスを使用して、ユーザー名やパスワードなどの資格情報を要求および検証します。このようなチェックは多くの場合、ブラウザ主導の環境で行われます。

このタイプの認証に使用される資格情報の詳細は、ほとんどのブラウザーとサーバーでサポートされているため、ネットワーク上でクリアテキストで共有することも、base64 を使用して単純にエンコードすることもできます。さまざまなプロキシサーバー上で実行できるだけでなく、IIS サーバー上でホストされていないリソースへのアクセスを許可することもできます。暗号化された保護がないため、リプレイなどの攻撃に対して脆弱です。

3、OAuth

OAuth は、カスタマイズ可能なオープン API 認証テクノロジとして、ユーザー ID を検証し、認可標準を定義することにより、アプリケーション、サーバー、ストレージ API 間の対話を実現できます。

誰かがシステムにログインすると、トークンを要求してユーザーを認証します。これを行うには、リクエストの作成者または作成者は、リソースへのアクセスリクエストを認証サーバーに転送する必要があります。サーバーは検証結果に応じてリクエストを受け入れるか拒否します。

OAuth は他のプロセスよりも安全であるため、多くのユーザーにとって最初の選択肢となっています。OAuth の 3 つの主要な要素には、OAuth プロバイダー (Google や Facebook など)、OAuth クライアント (情報をホストする Web サイト/ページを指します)、および所有者 (アクセス要求を行うユーザーを指します) が含まれます。

4、OAuth 2.0

OAuth の更新バージョンである OAuth 2.0 は、広く使用されている API アクセス管理プロトコルです。その機能には、HTTP サービスを使用してクライアントアプリケーションを起動することにより、API クライアントのアクセスを制限することが含まれます。GitHub と Facebook はどちらも、主要な HTTP サービスの認証コードでこのプロトコルを使用し、ユーザーの資格情報を排除しています。

OAuth 2.0 の 3 つの重要な要素は、データを所有するユーザー、アプリケーション、および API 自体です。この方法では、認証プロセス中に、異なるリソースを使用するようにユーザーデータを簡単に解決できます。認証目的で、Web、モバイル、デスクトップベースのアプリケーションやデバイスに導入できます。

5、SAML

Security Assertion Markup Language (SAML) は、シングルサインオンテクノロジを使用した認証のための標準化された API プロセスです。ユーザーが提供した詳細に基づいて検証が行われます。認証されると、ユーザーにはさまざまなアプリケーションまたはリソースへのアクセスが許可されます。現在、SAML 2.0 が一般的に使用されているバージョンです。これは ID に非常に似ており、ユーザーのアイデンティティの評価に役立ちます。

API のセキュリティとは何を意味しますか?

API セキュリティは、ユーザーに直接または間接的に公開される API の保護に重点を置くだけでなく、スロットリングやレート制限、ID ベースのセキュリティ分析、次の主要なセキュリティ制御概念などのネットワークセキュリティの原則も含みます。

APIプロトコル

API は、さまざまなニーズに応じてさまざまな形式やスタイルで使用できます。さまざまな使用方法によっても、API 実装のセキュリティが決まります。

石鹸

シンプルオブジェクトアクセスプロトコル (SOAP) は、XML ベースのメッセージングおよび通信プロトコルです。このプロトコルは HTTP を拡張し、Web サービスにデータ転送を提供します。このプロトコルを使用すると、すべてを含むファイルを簡単に交換したり、プロシージャをリモートで呼び出したりすることができます。CORB、DCOM、Java RMI などの他のフレームワークとは異なり、SOAP のメッセージ全体は XML で記述されるため、言語に依存しません。

休む

HTTP プロトコルに基づく Web 標準アーキテクチャである REST は、保留中の HTTP リクエストごとに 4 つの動詞 (GET、POST、PUT、および DELETE) を使用できます。開発者にとって、RESTful アーキテクチャは、API の機能と動作を理解するための最も簡単なツールの 1 つです。これにより、API アーキテクチャの保守と拡張が容易になるだけでなく、内部および外部の開発者が API にアクセスしやすくなります。

gRPC

gRPC は、オープンソースの高パフォーマンスフレームワークとして、古いリモートプロシージャコール (RPC) プロトコルを改良したものです。バイナリフレーム転送プロトコルである HTTP/2 を使用し、クライアントとバックエンドサービス間の通信およびメッセージングプロセスを簡素化します。

完全に軽量な gRPC は、JSON より 8 倍以上高速です。オープンソーステクノロジプロトコルを通じてバッファを呼び出すことができ、構造化メッセージに対してプラットフォームに依存しないシリアル化形式を採用します。API を使用すると、開発者は呼び出す必要があるさまざまなプロシージャを見つけて、gRPC を通じてパラメータ値を評価できます。

Webhook

Webhook は、自動的に生成されたメッセージをあるアプリケーションから別のアプリケーションに送信できます。言い換えれば、2 つのアプリケーション間の更新された通信をリアルタイムで確立、送信、取得できます。

Webhook には重要な情報が含まれており、それがサードパーティのサーバーに送信される可能性があるため、Webhook で基本的な HTTP 認証または TLS 認証を実行することで、API の関連セキュリティ慣行を確保できます。

ウェブソケット

WebSocket は、クライアントとサーバーの間に成熟した双方向通信チャネルを提供できる双方向通信プロトコルであり、それによって HTTP プロトコルの制限を補います。

アプリケーションクライアントは、WebSocket を使用して HTTP 接続リクエストを作成し、それをサーバーに送信できます。最初の通信接続が確立されると、クライアントとサーバーの両方が現在の TCP/IP 接続を使用して、基本的なメッセージフレームワークプロトコルに従ってデータと情報を送信できます。

XML-RPC

XML-RPC は、標準化された通信プロセスを通じて WordPress と他のシステムの間で通信できます。トランスポートとして HTTP を使用し、エンコードプロセスとして XML を使用します。その動作コードは、Web サイトのルートディレクトリにある xmlrpc.php ファイルに保存されています。WordPress バージョン 3.5 のデフォルトオプションとして利用可能な XML-RPC を使用すると、モバイルアプリが Web ベースの WordPress インストールプロセスとシームレスに対話できるようになります。

ただし、xmlrpc.php はアクセス要求ごとに認証の詳細を共有できるため、ブルートフォース攻撃や DDoS 攻撃の可能性が高くなります。この点で、XML-RPC API を採用する場合は、関連するセキュリティ慣行を強化する必要があります。

JSON-RPC

初心者のために説明すると、JSON-RPC は、Ethereum ブロックチェーンに基づく API の開発に使用できる超軽量 RPC プロトコルです。基本データ形式として JSON (RFC4627) を使用し、複数のデータ構造とルールを解釈して処理する機能を備えています。このプロトコルは、同じソケット上で繰り返し使用できます。

MQTT

MQTTは、IoTデバイスやツール開発の分野で広く使われているOASISが承認したメッセージプロトコルで、HTTP型の情報交換を実現します。非常に軽量なので、開発者は一度に数百万台のデバイスに拡張できます。API セキュリティに関して言えば、MQTT はメッセージの暗号化に役立つだけでなく、TLS と認証の適用も簡単にします。

AMQP

オープンプロトコルであるアドバンストメッセージキュープロトコル (アドバンストメッセージキュープロトコル、AMQP) は、メッセージプロバイダーの動作プロセスを規定しており、これをアプリケーション層に適用して相互運用可能なシステムを作成できます。このプロトコルはバイナリで実装されているため、さまざまなメッセージ指向のミドルウェア通信をサポートするだけでなく、メッセージの完全な配信を保証できます。

XMPP

無料のソーステクノロジのセットとして、XMPP を使用して、マルチパーティコラボレーション、インスタントメッセージング、マルチパーティチャット、ビデオ通話、および軽量ミドルウェアを開発できます。その 4 つの主要コンポーネントには、PHP、MySQL、Apache、および Perl が含まれます。

CoAP

RFC 7252 で定義された IETF 標準である CoAP は、IoT デバイス上のアプリケーションを制限するための標準化された API セキュリティプロトコルとして使用できます。CoAP は LPWAN 経由の通信をサポートできるため、単純なマイクロコントローラーノードを保護する場合に最適です。CoAP は TCP/IP 層で動作し、基本的なトランスポートプロトコルとして UDP を使用します。

クラウド、オンプレミス、ハイブリッド展開における API セキュリティ

クラウドサービス、統合プラットフォーム、API ゲートウェイなどのテクノロジーの進歩により、API プロバイダーはさまざまな方法で API を保護できるようになりました。API を構築するために選択されたテクノロジースタックのタイプが、API のセキュリティに直接影響を与えると言えます。たとえば、大規模な組織では、自社開発の API を備えた複数のアプリケーションを使用する場合があります。そして、さまざまなアプリケーションをマージする過程で、さまざまな API アイランドが出現する可能性があります。多くの場合、これらのサイロにはセキュリティリスクが潜んでいます。

異種エコシステムでは、API アイランド全体にわたる特定の API セキュリティインフラストラクチャをサイドカーエージェントおよびサイドバンドエージェントとして構成し、クラウドとローカルデプロイメントの間に埋め込むことができます。このようなセキュリティ構成は移植性が高いため、将来性のあるテクノロジーで API を簡単に転送または抽出できます。

APIセキュリティ層

API セキュリティ層は多層である必要があります。各層は独自の役割を実行して、最大限のセキュリティ保護を提供します。

API ディスカバリ

API セキュリティの最初の層は API ディスカバリです。結局のところ、ターゲットと脅威を知らなければ自分自身を守ることはできません。前述したように、API サイロは、セキュリティ担当者による API の発見を妨げる最大の問題です。API の可視性が欠如しているため、API アクセス権の管理が直接的に妨げられます。

シャドウ API は、API の可視性に対する 2 番目に大きな障壁です。API がアプリケーションの一部として開発される場合、その API は開発チームのメンバーのみに知られることが多く、セキュリティ担当者はそのような「シャドウ API」の実装の詳細については知りません。

3 番目のハードルは API のバージョン管理です。ソフトウェアアプリケーションのライフサイクル中、その API は継続的に反復される必要があることがよくあります。ただし、多くの場合、API の新しいバージョンは古いバージョンをすぐに包括的に置き換えることはできません。クライアントのアプリケーションのバージョンは同じではないため、下位互換性の要件に従って、古いバージョンの API を一定期間実行し続ける必要があります。そして、それらは徐々に開発チームの視野から外れ、あるいは忘れ去られていきます。これらすべては静かに起こった。

したがって、API の検出は、実際には API プロバイダーと攻撃者との間の競争になります。プロバイダーが攻撃者よりも前に上記の種類の API を発見できれば、API ゲートウェイ、ロードバランサー、ダイレクトインラインネットワークトラフィックから API トラフィックメタデータを抽出し、専用のエンジンを通じて、利用可能な API カタログと比較するための効果的な API リストレポートを作成できます。 API 管理層で。

OWASP API セキュリティに対するトップ 10 のセキュリティ脅威

API1:2019 オブジェクトレベルの認可の欠陥

通常、API エンドポイントは、処理されたオブジェクトの識別子を検出することによってアクセスコントロールプレーンを利用します。クライアントから提供された情報を一つ一つ確認する必要があります。

API2:2019 ユーザー認証の欠陥

攻撃者は、取得したトークンや検証システムの実行欠陥を利用して、正規のユーザーになりすまして不正な操作を行うことがよくあります。

API3:2019 過剰なデータ露出

攻撃者は、API 呼び出しや合法的に取得したデータを通じて一部のアイテムの関連属性を推測し、さまざまな有用な情報を除外する可能性があります。

API4:2019 リソース不足と現在の制限

一般に、API は呼び出されるデータにフローや量の制限を課しません。これにより、攻撃者がサービス拒否 (DoS) などのリソース奪取攻撃を開始する機会が残されます。

API5:2019 関数レベルの認可の欠陥

一部の API には、複雑なアクセス制御ポリシーが不完全であり、認可上の欠陥さえあります。これにより、攻撃者は、他のユーザーが関数呼び出しを通じて呼び出すことができるリソースを取得できるようになります。

API6:2019 バッチ割り当て

JSON形式でユーザーに情報を提供するモデルでは、効率性を高めるため、特定の権限リストに基づく法的属性の選別を行わずに一括割り当て（Mass Assignment）を提供することがよくあります。これに基づいて、攻撃者はサポートドキュメントを注意深く読んでオブジェクトのプロパティを推測したり、さまざまな API エンドポイントを見つけたり、リクエストペイロード内の追加プロパティを発見したりして、それらを改ざんする可能性があります。

API7:2019 セキュリティ構成エラー

セキュリティ構成エラーは、多くの場合、不完全なデフォルト設計、無計画なオーケストレーション、オープン分散ストレージ、HTTP ヘッダーの不一致、クロスオリジン資産共有 (クロスオリジン資産共有、CORS)、および長いエラーメッセージプロンプトなどの機密性の高い側面の組み込みによって発生します。データ。

API8:2019 インジェクション

攻撃者の悪意のある情報は、入力チェックを欺いたり、SQL または NoSQL の欠陥を悪用したり、悪意のあるコマンドを実行したり、適切な検証なしに情報を取得したりする可能性があります。

API9:2019 不適切な資産管理

API は通常の Web アプリケーションよりも多くのエンドポイントを検出できることが多いため、付属のドキュメントが適切に更新されることがさらに重要になります。この点に関して、API の関連テーブルを改善し続け、時間内に記録されていないエンドポイントを発見する必要があります。

API10:2019 のロギングとモニタリングが不十分

ログ記録と検査が不足していることと、インシデント対応機能が不十分な場合、API 呼び出しが攻撃の危険にさらされる可能性があります。

侵入テスト

開発者は、Postman エージェントの事前構築された API テストデータを使用して API と直接通信することを検討できます。APIの侵入テストを迅速かつ繰り返し実施することで、テストコストを削減しながら詳細なレポートを取得できます。

侵入テストにはターゲット API、さらにはシステム全体の習熟度が必要なため、熟練したセキュリティチームを雇用するか、オープンソースツールを使用して API に対する攻撃をシミュレートすることが最善です。定期的かつ継続的な侵入テストを通じて、開発者は API 保護レベルに応じた修復策をタイムリーに見つけることができます。

API セキュリティに関する 12 のベストプラクティス

上記の説明から、API のセキュリティはデータ中心のアプリケーション開発にとって非常に重要であることがわかります。さまざまな種類と段階の API に対するセキュリティのベストプラクティスについて説明します。

1. 暗号化を使用する

クラッキング攻撃を防ぐには、内部および外部通信に使用される API に TLS 暗号化プロトコルを使用し、エンドツーエンドの暗号化を導入する必要があります。

2. API認証

前述したように、認証により、見知らぬ人が API を直接使用できないことが保証されます。同時に、API キーまたはアクセス認証を通じて、API リソースの呼び出しを追跡できます。もちろん、このようなセキュリティ対策により、システムの実装の難易度も高まります。

3. OAuthとOpenID Connectを最大限に活用する

OAuth と OpenID Connect を組み合わせることで、API の認証および/または認可をすべて担うことができます。たとえば、認可プロセスでは、API のコンシューマとプロバイダの両方が認可操作を直接実行しませんが、OAuth を委任プロトコルとして使用して API に基本的な保護層を追加し、これに基づいて OpenID Connect 標準を使用します。 ID トークンを使用して OAuth2.0 を拡張する追加の ID レイヤー。

4. セキュリティの専門家

非常に多くの API セキュリティ手法から選択できるため、「選択症候群」に悩まされる可能性があります。この時点で、経験豊富なセキュリティ専門家が、適切なウイルス対策システムと ICAP (Internet Content Adaptation Protocol) サーバーを使用して強固な API セキュリティ体制を構築するよう指導します。

5. 継続的な監視、監査、ログ記録

ことわざにもあるように、予防は治療よりも優れています。API 設計の開始時に監視および記録する指標を設定でき、アプリケーションサービスの使用中に、適切なダッシュボードを通じて API のインタラクションを追跡し、関連する記録とエラーメッセージをタイムリーに確認できます。同時に、その後のデバッグおよびバージョン更新プロセスでは、すべての API を同期することを忘れないでください。

6. 限られた情報のみを共有する

API を通じて共有する情報が少なければ少ないほど、API 自体がもたらすセキュリティリスクも少なくなることに注意してください。同時に、エラーメッセージで開示される情報をできる限り少なくする必要もあります。

さらに、IP アドレスのホワイトリストとブラックリストを使用することは、API リソースへのアクセスを制限する優れた方法です。これにより、許可された担当者またはアプリケーションのみが API リソースへのアクセスを制限され、インターフェイス上の重要な情報が隠蔽された状態に保つことができます。

7. 電流制限とクォータ保護

DDoS 攻撃の脅威を効果的に防止するために、バックエンドシステム、実際の帯域幅、サーバー容量に応じて、特定の API にアクセスするメッセージの制限数を合理的に制限してください。

8. 有効データ

サーバーは、受信したすべてのコンテンツを 2 回チェックして検証する必要があります。新しいコンテンツ、膨大なデータセット、消費者が共有する情報はすべて検証される必要があります。現在、JSON と XML 検証は、パラメーターのセキュリティをチェックするために最も広く使用されている 2 つのツールです。同時に、SQL インジェクションや XML ボムなどのイベントも制御できます。

9. 強力なインフラストラクチャ

最新の安全なネットワークテクノロジー、新しいサーバー、負荷分散ソフトウェアを実装することで、API をインフラストラクチャレベルで安全に保ち、大量のデータの漏洩攻撃に対する耐性を高めることができます。

10. OWASP トップ 10 をフォローする

上記の分析を通じて、OWASP によってリストされ解釈された上位 10 の API 脆弱性脅威が、最も一般的な攻撃の影響の一部であることが簡単にわかります。これらは Web ページだけでなく、API のさまざまな脆弱性にとっても非常に有害です。したがって、事前にコードレベルでの防止を適切に行う必要があります。

11. API ファイアウォールを使用する

API 用のファイアウォールを構築すると、次の 2 つの目的があります。

メッセージのサイズ、SQL インジェクションの可能性、攻撃を即座にブロックできるかどうかのチェックなど、基本的なセキュリティチェックを実行するために使用できます。
LAN 内の既存の保護システムに統合して、全体的なセキュリティ状況を共同で改善できます。

12. APIゲートウェイのデプロイ

イントラネットでの使用であれ、外部ネットワーク呼び出しであれ、API が配置される環境は多くの場合複雑で危険です。したがって、API 管理のプレッシャーを軽減するために、API ゲートウェイを導入することで API 関連のトラフィックの包括的な制御、監視、保護を実装できます。