質問: API ベースの攻撃の増加に直面して、組織はどのようにして API が侵害に対して耐性があることを確認できますか?
Gravitee の創設者兼 CEO である Rory Blundell 氏は、次のように述べています。 あらゆる規模のあらゆる業界の企業が、日常的に内部 API を使用して基幹業務アプリを統合し、外部 API を使用してデータやサービスをベンダー、顧客、またはパートナーと共有しています。 XNUMX つの API が複数のアプリケーションまたはサービスにアクセスできる可能性があるため、API を侵害することは、最小限の労力で幅広いビジネス資産を侵害する簡単な方法です。
API は一般的な攻撃ベクトルになり、API 攻撃の頻度は驚くほど増加しています。 視聴者の３８%が、最近によると Salt Labs の研究. API を保護するための最初のステップは、OWASP などのベスト プラクティスに従うことです。 一般的な API セキュリティ リスクから保護することをお勧めします.
ただし、基本的な API セキュリティ プラクティスは、IT リソースを安全に保つには十分ではありません。 企業は、API を保護するために次の追加の手順を実行する必要があります。
1. リスクベース認証を採用する
企業はリスクベースの認証ポリシーを採用する必要があります。これにより、リスクが高まった場合にセキュリティ保護を実施できます。 たとえば、予測可能なパターンに従って正当なリクエストを発行してきた長い実績を持つ API クライアントは、以前に接続したことのない新しいクライアントと同じレベルの認証をリクエストごとに行う必要がない場合があります。 しかし、長年の API クライアントのアクセス パターンが変化した場合 (たとえば、クライアントが突然別の IP アドレスからリクエストを発行し始めた場合) は、より厳密な認証を要求することが、侵害されたクライアントからのリクエストではないことを保証する賢明な方法です。
2. 生体認証を追加する
トークンは、クライアントとリクエストを認証する基本的な手段として依然として重要ですが、 盗まれる. そのため、トークンベースの認証と生体認証を組み合わせることは、API セキュリティを強化するスマートな方法です。 開発者は、API トークンを所有するすべてのユーザーが有効なユーザーであると想定するのではなく、少なくともリスクの高いコンテキストでは、ユーザーが指紋、顔スキャン、または同様の方法を使用して認証する必要があるようにアプリケーションを設計する必要があります。
3. 認証を外部に強制する
API 認証方式が複雑になるほど、アプリケーション自体にセキュリティ要件を適用することが難しくなります。 そのため、開発者は API セキュリティ ルールをアプリケーション ロジックから分離するよう努め、代わりに API ゲートウェイなどの外部ツールを使用してセキュリティ要件を適用する必要があります。 このアプローチにより、API セキュリティ ポリシーは、アプリケーション ソース コードではなく、API ゲートウェイ内で簡単に実装および更新できるため、よりスケーラブルで柔軟になります。 そして最も重要なことは、さまざまなリスク プロファイルに基づいて、さまざまなユーザーまたは要求にさまざまなルールを適用できることです。
4. API セキュリティと使いやすさのバランスを取る
セキュリティが使いやすさの敵にならないようにすることが重要です。 API の認証手段を押し付けすぎたり負担が大きすぎたりすると、ユーザーが API を放棄する可能性があり、これは望んでいることとは正反対です。 不必要な要件を課すことなく、API セキュリティ ルールを厳格にする必要がある場合は、厳格にすることでこれを回避します。
API を標的とする攻撃は、減速する兆しを見せていません。 API を設計して保護する場合、開発者は OWASP の推奨事項を超えて、API の悪用をより困難にする必要があります。
