web-dev-qa-db-ja.com

API GatewayとWebサービスにはどのようなセキュリティコントロールを含める必要がありますか？

最近ではWebサービスが多用されており、「新しい」種類の製品であるAPI Gatewayが登場しています。このソリューションはインターネットに公開され、外部のパーティやモバイルアプリからWebサービスのリクエストを受信し、セキュリティ（認証、承認、一部の製品は入力の検証、XMLおよびJSONセキュリティなど）を実行してから、リクエストが内部ウェブサービス。

API Gatewayで実行する必要があるセキュリティ制御とWebサービスで実行する必要があるセキュリティ制御

例えば、

  • 入力の検証はどこで行う必要がありますか？

  • 認証？

  • 認可？ビジネスロジックのセキュリティ？

さらに、DMZのWebアプリケーションと内部バスの間にAPI Gatewayを配置する必要があるかどうか、今日1人の人から尋ねられました...このシナリオでは、必要なすべてのセキュリティを実行する必要があると答えましたWebアプリケーションによってAPI GWは必要ありません...私は正しいですか？

web-serviceapiapi-gateway
3
Eloy Roldán Paredes

API Gatewayは、外部の顧客に提示されるパブリックインターフェイスの管理を担当します。次のような低レベルの問題を処理する必要があります。

  • プロトコルコンプライアンス
  • ブラックリスト
  • レート制限
  • クォータ
  • バージョン管理
  • 正規化をリクエスト

それはとインターフェースすることができます：

  • どの内部Webサービスがどのパブリックエンドポイントを処理する必要があるかを知るための検出システム
  • パブリックルートを内部ルートに変換する方法を知るルーティングシステム
  • 外部APIトークンを内部認証資格情報に変換する方法を知るための認証システム。これにより、個々のWebサービスが繰り返し認証を要求する必要がなくなります。

要するに、それはAPIのパブリックサーフェスエリア全体の一般的な問題を処理する必要があります。特定のWebサービスまたは特定のルートの特定のビジネスロジックの詳細についての知識があってはなりません。

個々のWebサービスは、独自の入力を検証する必要があります。個々のサービスだけが、有効なパラメーターとそれらのパラメーターが想定できるタイプを知っています。ただし、WebサービスがJSONペイロードを使用する場合、API Gatewayは基本的なJSON検証を実行でき、URLごとにペイロードをJSONスキーマに対してチェックすることもできます。

API Gatewayは、通常はIDプロバイダーに接続でき、さまざまな認証プロトコルの知識があり、承認トークンをプロビジョニングするように構成できるため、認証を処理できます。ただし、多くの場合、APIゲートウェイが提供する機能を超える独自の認証スキームとワークフローがあります。

APIゲートウェイは、外部の呼び出し元から提供された認証トークンを確実に検証し、認証トークンが付与されているロールまたは権限でペイロードを拡張することにより、個々のWebサービスが直面するアクセス制御のいくつかの側面を簡素化するのに役立ちます。ただし、個々のサービスは、これらの役割の詳細なチェックとビジネスロジックのセキュリティを担当します。

APIゲートウェイは、信頼できないトラフィックに直面し、それをより構文的に正規化された形式に変換する責任があるため、エッジまたはDMZで構成されることがよくあります。 Webサービスはまだセマンティクスを担当しています。

HTMLを生成するWebアプリケーションがAPIを使用する場合、そのアプリケーションが公開APIのみを使用するか、内部Webサービスから直接内部APIを使用できるかについてのポリシー決定があります。双方の長所と短所があります。アーキテクチャはその決定から生まれます。

5
Jonah Benton