Best Practices for Secure API Design

安全なAPI設計の重要性

APIセキュリティのベスト プラクティスは、従来の Web アプリケーションのベスト プラクティスとは異なります。 API設計では、API 特有の課題が生じます。

• 一般に公開され、アクセスしやすいエンドポイントであること
• これはステートレス（ REST API ）であり、リクエストごとに認証と承認を必要とする。
• 内部ネットワークへの直接のゲートウェイとして機能するため、単一の脆弱性が複数のシステムを侵害する可能性がある。
• 頻繁に更新されるため、安全な API 設計原則から逸脱したドリフトや予期しない動作が発生する

安全な API 設計のベスト プラクティスは、進化する脅威に対してプロアクティブな保護を提供しながら、悪用される可能性のある脆弱性を最小限に抑えます。これにより、API 攻撃の成功率が制限されるとともに、サイバー犯罪者が自身の利益のために API 機能を操作できた場合の影響も最小限に抑えられます。

Best Practices for Secure API Design

以下に、すべての組織が開発プロセスに統合する必要がある、安全な API 設計に関する 9 つのベスト プラクティスを示します。

これらのベスト プラクティスは安全な API 設計に不可欠ですが、設計はより広範なAPI ポスチャ管理の一部であることを覚えておくことが重要です。一般的なAPIセキュリティのベスト プラクティスは、設計を超えて、API を識別および監視する方法、疑わしい動作を検出して脅威に対応する方法なども含まれます。

以下で説明する安全な API 設計のベスト プラクティスは、次のカテゴリに分類できます。

• アクセスとアイデンティティセキュリティ: API を使用できるユーザーとアクセスできる内容を制御する

• • データ漏洩防止:保管時と転送時の両方で機密情報を保護します。
  • 入力と出力の検証: API 呼び出しと応答が意図したとおりに動作することを確認する

• トラフィック管理:過負荷や悪用を防ぐために API の使用を管理する

• 開発プラクティス:機密性の高いビジネスデータとシステムを保護するための API セキュリティ制御のテスト

#1. 堅牢な認証メカニズムによる安全なAPIアクセス

認証では、API を呼び出すユーザーの ID を検証し、API にアクセスするための適切な資格情報を持っていることを確認します。API を開発するときは、信頼できるクライアントのみが接続できるように、OAuth 2.0、OpenID Connect、署名された JWT などの実績のある認証標準を使用する必要があります。

また、ハードコードされた資格情報を避け、API キーを定期的にローテーションしてください。たとえば、強力な認証メカニズムでは、有効期間の短い JWT を使用してトークンの誤用を減らし、より厳密なアクセス制御を可能にする場合があります。重要な操作のために、認証を IP 許可リストやデバイス フィンガープリンティングなどの追加の ID チェックと組み合わせることもできます。

#2. API最小権限認証で攻撃対象領域を減らす

認証では誰が API を呼び出しているかを確認し、承認ではそのユーザーが API で何ができるかを制御します。セキュリティの観点から見ると、API の最小権限制御を実装し、アクセス パスを最小限に抑えることで、攻撃対象領域が縮小されます。さらに、特権アカウントが侵害された場合でも、アクセスできる内容は制限されます。

ただし、API の最小権限アクセス制御によって正当なユーザーが妨げられないようにするには、定期的にロールと権限を確認し、ユーザーが必要なものにアクセスできることを確認する必要があります。

#3. 暗号化を使用して機密データを保護する

暗号化により、API によって処理されるデータの機密性と整合性が保護されます。データ保護を維持するには、すべてのリクエストとレスポンスに TLS を使用した HTTPS API セキュリティを使用する必要があります。安全なデータ処理 API 戦略を導入することで、攻撃者は API トラフィックを傍受したり変更したりできなくなります。

転送中のデータを暗号化するだけでなく、AES などの実績のある標準を使用して保存中のデータを保護する必要があります。たとえば、 APIアクセス トークンや、API がアクセスできるデータベースに保存されている個人識別情報 (PII) を暗号化します。 さらに、暗号化キーを保護対象のデータとは別に保存したり、定期的にローテーションしたりするなど、暗号化キーを管理するための安全な手順を実装します。

＃4。リクエストに要求されたものだけを返す

API リクエストを補足する追加情報を返すのは簡単です。ただし、API が公開する情報が増えるごとに、操作されるリスクが高まります。API 応答内の不要なデータ（PII を含む）はマスクまたは省略する必要があります。たとえば、アプリでユーザーの表示名のみが必要な場合は、メールアドレスや内部識別子を含めないでください。

#5. 厳格な入力制御を実施する

攻撃者は、呼び出しに予期しないコードを追加して API をテストします。API を保護するには、処理前にすべての入力を検証し、期待どおりに一致するかどうかを確認する必要があります。たとえば、タイプ、形式、長さなどです。

不適切に検証された入力は、セキュリティの脆弱性の最も一般的な原因の 1 つです。入力検証 API ルールは、SQL インジェクションなど、これを悪用する多くの API 脅威に関連するリスクを最小限に抑えるために不可欠です。

＃6。一貫性のある安全なエラーメッセージを返す

エラーが適切に処理されないと、攻撃者が悪用できる重要なシステムの詳細が明らかになる可能性があります。API エラー メッセージは、システムの詳細や内部ロジックを明らかにせずにクライアントに通知する必要があります。トラブルシューティングのために詳細を内部的に記録しながら、汎用の標準化されたメッセージを使用する一貫したアプローチと安全なエラー処理戦略を採用します。これにより、正当なデバッグは可能でありながら、攻撃者が試行錯誤を通じて収集できる情報が削減されます。

#7. APIレート制限でクライアントリクエストを管理する

API レート制限は、DDoS 攻撃から保護するために、定義された期間内にクライアントが実行できるリクエストの数を制御します。ハードキャップを設定するか、以前のクライアントの動作などのコンテキスト情報に基づいて、より洗練されたアプローチを採用した動的 API レート制限を実装します。動的 API レート制限により、不正使用を防ぎながら正当なユーザーがアクセスを維持できるようになります。API レート制限を実施するための一般的なツールは、 API ゲートウェイです。

#8. APIゲートウェイを使用してトラフィックを一元化し、セキュリティ ポリシーを適用する

API ゲートウェイは API トラフィックを集中管理し、リクエストの単一のエントリ ポイントを提供します。これにより、認証、レート制限、入力検証、API ログ監視などの API セキュリティのベスト プラクティスと制御を一貫して実装しやすくなります。API ゲートウェイは、正当なリクエストのみが通過して処理されるようにするのに役立ちます。リクエストをフィルタリングし、セキュリティ制御を適用することで、攻撃者が API エンドポイントを悪用する方法を制限します。

API ゲートウェイは安全な API 設計における重要なベストプラクティスですが、完全なセキュリティソリューションではありません。たとえば、安全でないバックエンドの脆弱性、論理上の欠陥、または不十分な認証および承認メカニズムから保護することはできません。

#9. APIセキュリティテストで弱点を特定する

開発ライフサイクル全体にわたる API セキュリティ テストにより、脆弱性をできるだけ早く検出できます。定期的に侵入テストを実行して攻撃をシミュレートし、自動脆弱性またはコード レビューを実行して新たな脆弱性をチェックする必要があります。 これには、内部コードおよびサードパーティ コードの潜在的な脆弱性が含まれます。定期的なセキュリティ テストと監査により、関連するコンプライアンス標準に準拠していることも保証されます。