アプリケーション プログラミング インターフェイス (API) の使用は急増しています。組織は現在、複数の API に依存して日々の業務を効率的に遂行しています。API の使用が拡大したことで、API はハッカーの標的となり、API の脆弱性を悪用する革新的な方法が考案されています。
API のセキュリティが重要なのはなぜでしょうか。また、API セキュリティのリスクを管理するためにできることは何でしょうか。詳しく見ていきましょう。
API セキュリティに注力すべき理由
API は、現代のモバイル、SaaS、Web アプリケーションにおいて不可欠な存在です。組織は、顧客向け、パートナー向け、および社内アプリケーションで API を使用しています。API は、個人を特定できる情報 (PII) などのアプリケーション ロジックや機密データを公開しているため、ハッカーは常に API へのアクセスを試みています。API がハッキングされると、データ侵害が発生し、組織の財務的および評判上の損害につながることがよくあります。
Palo Alto Networks と ESG の調査によると、調査対象の企業の 92 パーセントが 2022 年に API 関連のセキュリティ インシデントを経験しました。これらの企業のうち、57 パーセントの企業が複数の API 関連のセキュリティ インシデントを経験しています。つまり、API 攻撃を防ぐために API セキュリティを強化することが重要です。
一般的な API セキュリティのリスクを最小限に抑え、機密データを保護するための方法をいくつか紹介します。
1. セキュアな認証と認可を実装する
認証とは、API リソースへのアクセス要求が正当なユーザーから発信されたものであることを意味し、認可とは、ユーザーが要求された API リソースへのアクセスを許可されていることを保証します。
セキュアな API 認証と認可を実装することは、API リソースへの不正アクセスに対する第一の防衛線です。
API の認証に不可欠な方法を次に示します。
API キー
この認証方法では、クライアントはクライアントと API サーバーだけが知っている API キーを持ちます。クライアントが API リソースへのアクセスを要求すると、そのキーが要求に添付されて、要求が正当であることを API に知らせます。
API キー認証方式には問題があります。ハッカーは API キーを入手できれば、API リソースにアクセスできます。そのため、ハッカーが API キーを盗むのを防ぐために、API リクエストと API レスポンスを暗号化することが重要です。
ユーザー名とパスワード
ユーザー名とパスワードの方法を実装して、API リクエストを認証できます。ただし、ハッカーはさまざまなトリックを使ってパスワードをハッキングすることに注意してください。また、API クライアントは、ユーザー名とパスワードを信頼できない相手に共有することもできます。そのため、ユーザー名とパスワードの方法では、最適なセキュリティが得られません。
相互 TLS (mTLS)
相互 TLS 認証方法では、API エンドポイントとクライアントの両方に TLS 証明書があります。そして、これらの証明書を使用して相互に認証します。TLS 証明書の維持と適用は困難であるため、この方法は API リクエストの認証には広く使用されていません。
JWT 認証 (JSON Web Token)
この API 認証方法では、JSON Web トークンを使用して API クライアントを認証および認可します。クライアントがユーザー名、パスワード、またはその他のタイプのログイン資格情報を含むログイン要求を送信すると、API は暗号化された JSON Web トークンを作成し、そのトークンをクライアントに送信します。
次に、クライアントは以降の API リクエストでこの JSON Web トークンを使用して、自分自身を認証および認可します。
OpenID Connect を使用した OAuth2.0
OAuth は、ユーザーがパスワードを共有することなく自分自身を認証できるようにする認証サービスを提供します。OAuth2.0 はトークンの概念に基づいており、OpenID Connect 認証メカニズムとともに使用されることがよくあります。この API 認証および認可方法は、API を保護するために一般的に使用されています。
2. ロールベースのアクセス制御を適用する
最小権限のセキュリティ原則を使用するロールベースのアクセス制御 (RBAC) は、ユーザーのロールに基づいてリソースへのアクセス レベルを決定します。
ロールベースのアクセス制御を実装すると、承認されたユーザーのみが自分のロールに従ってデータにアクセスできるようになります。誰もがすべての API リソースに制限なくアクセスすることはありません。
3. すべてのリクエストとレスポンスを暗号化する
API トラフィックには、資格情報やデータなど、機密情報が含まれることがよくあります。すべてのネットワーク トラフィック (特にすべての受信 API リクエストとレスポンス) が SSL/TSL 暗号化を使用して暗号化されていることを確認してください。データ暗号化により、ハッカーがユーザーの資格情報やその他のタイプの機密データを公開することを防ぐことができます。
4. API ゲートウェイを使用する
API ゲートウェイを使用しない場合は、アプリが API 呼び出しを処理する方法をアプリに伝えることができるように、コードをアプリ内に埋め込む必要があります。しかし、このプロセスには開発作業がさらに必要であり、API セキュリティのリスクが高まる可能性があります。
API ゲートウェイを使用することで、企業はアプリケーション プログラミング インターフェイスの外にある中央ゲートウェイを介して外部システムからの API 呼び出しを管理できます。
さらに、API ゲートウェイは API の管理を容易にし、API セキュリティを強化し、スケーラビリティと可用性を向上させます。
人気の API ゲートウェイには、Amazon API ゲートウェイ、Azure API ゲートウェイ、Oracle API ゲートウェイ、Kong ゲートウェイなどがあります。
5. レート制限を適用する
API レート制限により、クライアントが API に対して行うことができる API リクエストまたは呼び出しに制限を設定できます。API レート制限を適用すると、分散型サービス拒否 (DDoS) 攻撃を防ぐことができます。
API リクエストは、1 秒、1 分、1 時間、1 日、または 1 か月ごとに制限できます。また、API レート制限を実装するためのオプションはさまざまです。
ハード ストップを実装すると、クライアントは制限に達するとエラー 429 を受け取ります。ソフト ストップでは、クライアントは API レート制限が終了した後、API 呼び出しを行うための猶予期間が短くなります。スロットル ストップを実装して、クライアントが制限を超えた後でも API リクエストを行えるようにすることもできますが、速度は遅くなります。
API レート制限により、API セキュリティの脅威が最小限に抑えられ、バックエンド コストが削減されます。
6. データの漏洩を制限する
API リクエストに対するレスポンスには、関連性のあるデータや必要なデータを超えるデータが返されないようにします。API 呼び出しが郵便番号の場合、完全な住所ではなく郵便番号のみを提供する必要があります。
API レスポンスで可能な限り少ない情報を表示すると、レスポンス時間も短縮されます。
7. パラメータを検証する
API リクエストには、多数の入力パラメータが必要です。すべての API リクエストについて、API ルーチンは各パラメータの存在と内容を検証する必要があります。これにより、API の整合性が保護され、悪意のある入力や不正な入力の処理が防止されます。
パラメータの検証チェックをバイパスすることは決してありません。
8. API アクティビティを監視する
API アクティビティを監視してログに記録する計画を立てます。これにより、API サーバーや API クライアントに悪影響を及ぼす前に、脅威アクターの疑わしいアクティビティを検出できます。すべての API 呼び出しとレスポンスのログを記録することから始めます。
Sematext、Dotcom-Monitor、Checkly などのさまざまなツールを使用すると、API をリアルタイムで監視できます。
9. API セキュリティを定期的にチェックする
API セキュリティ テストを API 開発プロセスのほんの一部にしないでください。その代わりに、稼働中の API のセキュリティを常にチェックしてください。これにより、セキュリティ チームは、開発チームが API 実装フェーズで逃した可能性のあるセキュリティの誤設定や API の脆弱性を特定できます。
また、セキュリティ チームは、API セキュリティ インシデントを処理するためのインシデント対応計画を作成する必要があります。
API セキュリティのリスクを管理して貴重なデータを保護する
組織がデジタル トランスフォーメーション プロセスで API をますます実装するにつれて、脅威アクターは常に悪用する API の脆弱性を求めています。API にアクセスすると、機密データを盗むことができます。そのため、API セキュリティを強化して API セキュリティのリスクを最小限に抑える必要があります。
コメントする