Edge を使用した OWASP 保護 - 多重防御

概要

API エコシステムは、外部クライアントと内部クライアントの両方からさまざまな攻撃を受けます。API の提供と使用は、サービス プロバイダに大きなチャンスをもたらしますが、セキュリティ リスクももたらします。デベロッパーは、API を作成して使用するときに、このような課題を認識して、それらに対処する必要があります。

OWASP は、信頼できるアプリケーションと API の開発、購入、メンテナンスを支援する組織専用のオープン コミュニティです。OWASP Top 10 プロジェクトを通じて、OWASP はウェブ アプリケーションと REST API にとって最も重要なセキュリティ リスクを公開し、それらのリスクに対処するための推奨事項を提供しています。

Apigee を使用すると、バックエンド システムでリクエストが処理される前に、API プロキシレイヤがクライアントからの不正な API リクエストを検出、ブロック、報告できるため、リスクを軽減しサービスを保護できます。不正なリクエストには、HTTP アプリケーション レベルのプロトコルを構成する次のコンポーネントが含まれることがあります。

  • URL
  • ヘッダー
  • パス
  • ペイロード

不正な API リクエストは、外部デベロッパー、内部デベロッパー、または悪意のあるボットによって開発された既知または未知のクライアントから送られてくる場合があります。この種のリクエストが OWASP の脅威の大部分を占めていますが、リスクを軽減することが可能な、データ マスキング、ロギング、管理などの基礎となる API プロキシレイヤの追加コンポーネントが用意されています。

Apigee のインテリジェントな API 管理プラットフォームを使用すると、API の設計および API とバックエンド システムとの接続に対する消費に焦点を当てたアプローチを採用することになり、上位の OWASP API セキュリティの脆弱性にシームレスに対処できます。Apigee が上位の REST OWASP の脅威に対して推奨しているポリシーと構成のリストを以下に示します。

2017 OWASP Top 10 に対する Apigee ソリューション

ウェブ アプリケーションの構築と保護に関しては、セキュリティ上の懸念が多くあります。OWASP は、ウェブ アプリケーションに関する Top 10 OWASP Security Threats 2017 のリストを公開しました。ウェブ アプリケーションは多くの部分から構成されていますが、最新のウェブアプリのほとんどが REST API に大きく依存しています。Apigee は、ウェブ アプリケーションのすべてのセキュリティ ニーズを処理するようには設計されていませんが、REST API の保護において極めて重要な役割を果たすことができます。OWASP の主要なセキュリティの脅威と、Apigee を使用してこれらの脅威に対処する方法の説明を以下に示します。

A1:2017 - インジェクション

意図されていないコマンドの実行や不正なデータアクセスを引き起こす可能性がある SQL、NoSQL、LDAP、JavaScript などの信頼できないデータ インジェクションから保護するために、Apigee は複数の入力検証ポリシーを提供することで、さらなる処理を許可する前に、クライアントから提供された値が期待値と一致するかどうかを検証します。受信 API リクエスト用のサーバーとして機能する Apigee Edge は、ペイロード構造が許容範囲内に収まっていることを確認して保証します。これは制限チェックとも呼ばれます。入力検証ルーチンで入力を変換して危険な文字シーケンスを削除し、安全な値に置き換えるように、API プロキシを構成できます。

Apigee プラットフォームで入力を検証するためのアプローチがいくつか用意されています。

コンテンツ タイプを検証します。

A2:2017 - 不完全な認証とセッション管理

攻撃者は、アプリケーションの実装欠陥を利用して、パスワード、セッション トークン、キーにアクセスし、他のユーザーになりすますことができます。これは、プロダクトの問題ではなく、実装の問題です。Apigee は、VerifyApiKey、OAuth、JSON Web Token(JWT)ポリシーを提供しており、これらはこの脆弱性に対する保護に役立ちます。

API キー検証

API キー検証は、API 用に構成可能なアプリベースのセキュリティの中で最も簡単な方法です。クライアント アプリはリクエストと一緒に API キーを提供し、Apigee Edge は API プロキシに関連したポリシーにより、リクエストされたリソースに対して API キーが承認状態かどうかをチェックします。

Apigee は、API キーの生成と検証のサポートを提供します。1 つ以上の API プロダクトにリンクされたデベロッパー アプリが作成および承認されると、API キーとシークレットを生成します。

「API キー」という用語は、別のことを意味する場合があります。Apigee では、アプリとプロダクトの関係が構築されると、クライアント ID とクライアント シークレットが生成されます。ID とシークレットの両方を API キーと呼ぶ場合もあれば、クライアント ID のみを API キーと呼ぶ場合もあります。Edge UI には、「コンシューマ キー」と「コンシューマ シークレット」と表示されます。

VerifyAPIKey ポリシーでは、クライアント ID、つまり、「コンシューマ キー」のみが検証されます。デベロッパーは、アプリを Apigee に登録して API プロダクトに関連付けると、コンシューマ キーを受け取ります。そして、アプリが API プロダクトにバンドルされた API プロキシに対して行う呼び出しにコンシューマ キーを含めます。

Apigee は、外部ソースから既存の API キーをインポートする機能もサポートしています。

OAuth 権限付与タイプでは、クライアント ID とシークレットの両方が使用されます。

OAuth 2.0

OAuth 2.0 認可フレームワークは、サードパーティのアプリケーションによる HTTP サービスへの限定的なアクセスを可能にします。サードパーティ アプリケーションがアクセス権を取得する際に、リソース所有者と HTTP サービスの間の承認のためのやり取りをリソース所有者に代わってオーケストレートして行う場合と、サードパーティ アプリケーションが自らの権限においてアクセス権を取得できるようにする場合があります。

Apigee の OAuth 2.0 ポリシーを使用すれば、4 つの OAuth 2.0 権限付与タイプを実装してカスタマイズすることができます。OAuthv2 ポリシーを使用して、OAuth アクセス トークンの適用を実施することができます。コンシューマは、登録されて、API へのアクセス権が付与されるようにアプリが承認される必要があります。その際に、API クライアント ID とクライアント シークレットを受け取ります。コンシューマは、認証対象の OAuth 権限付与のいずれかを通過する必要があります。これにより、専用のアクセス トークンが付与されます。このトークンを使用して、API へのアクセスを制御できます。

JWT

JSON Web Token(JWT)は一般的に、接続されているアプリケーション間でクレームやアサーションを共有するために使用されます。Apigee は、次の 3 つのポリシーを使用して JWT サポートを提供します。

  • GenerateJWT トークン(HS256 署名と RS256 署名をサポート)
  • ValidateJWT トークン
  • 検証なしの DecodeJWT トークン

A3:2017 - 機密データの漏洩

攻撃者は、クレジット カード情報、社会保障番号、ログイン資格情報、個人を特定できる情報(PII)、納税者番号などの機密データを標的にして、個人情報の盗難、金銭の盗難、不正行為、その他の犯罪を犯します。ウェブ アプリケーションは、保存時と転送時の両方で暗号化を実装し、機密データの保護を保証するためのその他の戦略を実装する必要があります。

TLS(Transport Layer Security、前身は SSL)は、ウェブサーバーとウェブ クライアント(ブラウザやアプリなど)の間で、暗号化されたリンクを確立するための標準的なセキュリティ テクノロジーです。Apigee は、一方向 TLS と双方向 TLS の両方をサポートしています。

上り方向 TLS(サーバーとして機能する API に接続するクライアント)は、仮想ホスト構成の使用を通してサポートされます。仮想ホストは、一方向 TLS 用または双方向 TLS 用に構成できます。

下り方向 TLS(バックエンド サービスに接続するクライアントとしての Apigee)は、ターゲット サーバー構成の使用を通してサポートされます。ターゲット サーバーは、一方向 TLS 用または双方向 TLS 用に構成できます。

Apigee は、さまざまな TLS 構成オプションをサポートしています。

双方向 TLS を適用すれば、クライアントが Apigee にオンボードされた証明書を使用していることが保証されます。OWASP は、TLS ベスト プラクティスも提供しています。

Apigee Hybrid では、ホスト エイリアス経由の入り口で TLS を使用できます。これは、仮想ホストと同様のコンセプトです。

機密データを保護するためのガイドラインを以下に示します。

  • プロトコル レベルで保護する一方向 TLS と双方向 TLS をサポートするプラットフォームを使用します。
  • AssignMessage ポリシーJavaScript ポリシーなどのポリシーを使用して、クライアントに返される前に機密データを削除します。
  • 標準の OAuth 手法を使用し、HMAC、ハッシュ、ステート、ノンス、PKCE、またはその他の手法を追加して、各リクエストの認証レベルを高めることを検討します。
  • データ マスキング設定を使用して、Edge Trace ツールにおいて機密データをマスクします。
  • キャッシュに機密データを格納する場合には注意して行います(またはキャッシュに格納される機密データは暗号化します)。Edge では、Key-Value マップに保存される機密データを暗号化できます。

A4:2017 - XML 外部エンティティ

XML を処理するシステムまたはアプリケーションは、XML 内の「外部エンティティ参照」、つまり、XML 処理中に実際のデータに置き換えられるファイルまたはデータへの参照を処理する必要があります。アプリケーションまたは XML プロセッサが古いか実装が不十分な場合は、攻撃者がデータをハッキングして、それを利用して情報を盗んだり、サービス拒否攻撃などのシステムに対するさまざまな攻撃を仕掛けたりすることができます。

Apigee の ExtractVariables ポリシーを使用すれば、リクエストまたはレスポンスからコンテンツを抽出して、そのコンテンツを変数に割り当てることができます。ヘッダー、URI パス、JSON ペイロード、XML ペイロード、フォーム パラメータ、クエリ パラメータなど、メッセージの任意の部分を抽出できます。このポリシーは、メッセージ コンテンツにテキスト パターンを適用し、一致するものを見つけると、変数を設定し、指定されたメッセージ コンテンツを代入するという仕組みになっています。

Apigee には、プラットフォームの一部として、XPath を使用してデータを抽出する XML パーサーが組み込まれています。また、悪意のある XML ペイロードから保護するための XMLThreatProtection ポリシーもあります。

A5:2017 - 不完全なアクセス制御

ユーザーがログインしてシステムにアクセスしたら、そのユーザーが許可されていることだけを表示して実行できるように、適切な承認制御を実施する必要があります。強力なアクセス制御がないと、攻撃者は無許可で機密性の高いデータを表示したり、データやシステムの動作を悪意を持って操作したりできます。

Apigee は、悪意のある人物が不正な変更を行ったりシステムにアクセスしたりするのを防ぐために、アクセス制御を実装する階層化アプローチをサポートしています。

Edge UI 用のアクセス制御

Apigee デベロッパー ポータル用のアクセス制御

  • 会社の ID プロバイダを使用したシングル サインオンを構成します。
  • 役割ベースのアクセス制御(RBAC)を構成して、ユーザーが Drupal ベースのデベロッパー ポータルで必要な機能と構成にのみアクセスできるようにします。
  • ユーザー役割に応じて特定の API プロダクトを表示するようにデベロッパー ポータルを構成します。
  • ユーザー役割に基づいてコンテンツを表示または非表示にするようにポータルを構成します。

Apigee ランタイム API アクセス用のアクセス制御

  • API へのアクセスは、API キー、OAuth トークン、OAuth スコープ、証明書、その他の手法を通して実施できます。
  • API プロバイダは、API プロダクトを定義することにより、使用可能なリソースを構成します。アクセス権は、UI で手動で、管理 API を介して、またはデベロッパー ポータルを介して付与されます。デベロッパーのアプリに API プロダクトへのアクセス権が付与されると、認証プロセスで使用されるクライアント ID とシークレットを受け取ります。
  • Apigee は、任意の ID プロバイダと統合して OAuth を実行できます。
  • Apigee は、JWT トークンまたはその他の手法を生成して、ユーザー ID をターゲット サービスに送信できます。ターゲット サービスは、必要に応じて、その ID を使用して、サービスとデータへのアクセスを制限できます。

A6:2017 - セキュリティの構成ミス

多くの管理者とデベロッパーが、使用しているシステムが本質的に安全であると誤って信頼しているために、セキュリティの構成ミスが簡単に見落とされています。セキュリティの構成ミスは、デフォルトの構成を信頼したり、安全でない可能性があるにもかかわらず部分的な構成を行ったり、エラー メッセージに機密情報を含めたり、適切なセキュリティ制御なしでクラウドにデータを保存したり、HTTP ヘッダーを誤って構成したりするなど、さまざまな方法で発生します。Apigee プラットフォームには、再利用可能な共有フローなど、セキュリティ構成を制御、管理、モニタリングできるメカニズムが多数用意されています。

共有フローを使用すれば、API デベロッパーは、ポリシーとリソースを再利用可能なグループにまとめることができます。再利用可能な機能を 1 か所に集約することにより、共有フローは整合性を保証し、開発時間を短縮して、コードをより簡単に管理するのに役立ちます。個々の API プロキシ内に共有フローを含めることも、さらに進んでフローフックに共有フローを配置して、共有フローと同じ環境にデプロイされたすべての API プロキシの共有フローロジックを自動的に実行することもできます。

Apigee プロダクト リリースは、脆弱性のあるライブラリに対する保護を保証します。Apigee は、新しい脆弱性が見つかった場合に、追加のパッチまたはアップデートをリリースする可能性があります。Edge for Public Cloud には自動的にパッチが適用されます。Edge for Private Cloud(オンプレミス)のお客様は、プロダクト パッチをご自身で適用する必要があります。

A7:2017 - クロスサイト スクリプティング(XSS)

クロスサイト スクリプティング(XSS)を使用すれば、攻撃者は、ユーザーのウェブブラウザでスクリプトを実行して、ユーザー セッションを制御したり、ウェブサイトを操作したり、その他の方法でユーザーに悪影響を及ぼしたりすることができます。XSS の問題は必ずしも API に関連するわけではありませんが、Apigee は API の XSS を防ぐために活用できる脅威保護ポリシーを提供しています。RegularExpressionProtection ポリシーまたは JavaScript ポリシーで正規表現を使用して、JavaScript やその他のインジェクション型攻撃のペイロード値とパラメータ値をチェックしてください。

CORS は、すべてのブラウザによって適用される同一オリジン ポリシーに対して一般的に実装されるソリューションの 1 つであり、AssignMessage ポリシーを使用して実装できます

A8:2017 - 安全でない逆シリアル化

攻撃者は、リプレイ、権限昇格、インジェクションなどのさまざまなタイプの攻撃に逆シリアル化の欠陥を利用できます。安全でない逆シリアル化は、リモートコード実行を可能にする場合もあります。

Apigee では、逆シリアル化を推奨していません。ただし、JSONThreatProtection ポリシーRegularExpressionProtection ポリシーが悪意のある JSON ペイロードに対する保護に役立つ場合があります。JavaScript ポリシーを使用して、ペイロードに悪意のあるコンテンツがないかスキャンすることもできます。キャッシュとその他のポリシーを使用して、リプレイ攻撃から保護することができます。インフラストラクチャ レベルで、Apigee プラットフォームには、実行中のプロセスを保護するためのガードレールも組み込まれています。

A9:2017 - 機知の脆弱性のあるコンポーネントの使用

フレームワーク、ライブラリ、モジュールはフル実行と CRUD アクセスで動作するため、攻撃者はコンポーネントの脆弱性を利用してシステムを攻撃できます。

Apigee の定期的なプロダクト リリースでは、特に、特定の脆弱性が発見された場合に、コンポーネントの脆弱性に対する保護が保証されます。Apigee Public Cloud は自動的にパッチが適用され、Edge for Private Cloud のお客様にはオンプレミス パッチがインストール可能になった時点で通知が送られます。

A10:2017 - 不十分なロギングとモニタリング

システムでロギング、モニタリング、インシデント管理が適切に実行されていない場合は、攻撃者がデータとソフトウェアに対してより深い攻撃を長期にわたって加えることができます。

Apigee では、ロギング、モニタリング、エラー処理、監査ロギングを実行するいくつかの方法を用意しています。

ロギング

  • ログメッセージは、MessageLogging ポリシーを使用して、Splunk やその他の syslog エンドポイントに送信できます。
  • API 分析データは、Analytics API を介して pull し、他のシステムとの間でインポートまたはエクスポートすることができます。
  • Edge for Private Cloud では、MessageLogging ポリシーを使用してローカル ログファイルに書き込むことができます。実行中のコンポーネントごとのログファイルも利用できます。
  • JavaScript ポリシーを使用して、ログメッセージを REST ロギング エンドポイントに同期的または非同期的に送信できます。

モニタリング

  • API Monitoring UI または API を使用して、API とバックエンドを定期的にモニタリングして、アラートをトリガーします。
  • ヘルス モニタリングを使用して、ターゲット サーバーのバックエンドを定期的にモニタリングします。
  • Apigee は、Edge for Private Cloud をモニタリングするための推奨事項を提供しています。
  • また、Apigee は、チームが API プログラムのモニタリングに活用可能なベスト プラクティスも提供しています。

エラー処理

Apigee は、API プロキシ用の強力で汎用性の高い障害処理メカニズムを提供しています。Java プログラムが例外をキャッチする方法と同様に、API プロキシは障害をキャッチして、クライアントに適切なレスポンスを返す方法を決定できます。Apigee のカスタム障害処理を使用すれば、エラーが発生したらいつでもメッセージログを記録する機能などを追加できます。

監査ログ

Apigee プラットフォームは、API プロキシ、プロダクト、組織履歴に対する変更を追跡する監査ログを保持します。このログは、UI を介してまたは Management API を介して入手できます。

2013 OWASP 脆弱性に対する Apigee ソリューション

OWASP が 2017 年にリストを更新したときに、2013 年のリストに掲載されていた脆弱性の一部が除外されました。それらは現在も有効な脅威です。以降のセクションでは、これらの脅威を Apigee で処理する方法について説明します。

A8:2013 - クロスサイト リクエスト フォージェリ(CSRF)

クロスサイト リクエスト フォージェリを使用すれば、攻撃者は HTTP を介してユーザーの認証詳細、セッション Cookie、その他のデータを脆弱なウェブ アプリケーションに転送し、ウェブ アプリケーションにユーザーからの正当なリクエストであると信じ込ませることができます。

ガイドライン:

  • これは、API プロダクトの問題ではなく、ブラウザの問題です。この脆弱性は、OpenID Connect や OAuth などの手法で対処できます。
  • HMAC、ステート、ハッシュ、ノンス、または PKCE 手法を使用して、フォージェリ攻撃とリプレイ攻撃を防止することを検討してください。

A10:2013 - 未検証のリダイレクトと転送

ウェブ アプリケーションがリダイレクトを実行する場合、そのリダイレクトによってユーザーが信頼できる意図されたウェブサイトに送信されることを検証しないと、攻撃者はユーザーを悪意のある宛先に送信して、フィッシングやマルウェア実行などの攻撃を実施できます。

ガイドライン:

  • OAuth を使用して、リクエストごとに検証を実施します。
  • API プロキシ ロジックでレスポンス コードをチェックし、リダイレクトを適切に処理することにより、予期せぬ 302 リダイレクトを阻止します。