API Shield を始める

API Shield は、エンドポイントの検出、リクエストスキーマの検証、不正利用パターンの検知で API を保護します。このガイドでは、セッション識別子の設定から高度な保護の有効化まで、初期セットアップを進めます。

必須ではありませんが、API Shield を始めるときは セッション識別子 の設定を推奨します。Cloudflare が API トラフィックを個々のセッション単位で検査できると、可視化、管理、制御のためのツールをより多く提供できます。

API が使うセッション識別子が不明な場合は、開発チームに確認してください。

セッション識別子は、API クライアントを一意に識別する必要があります。API トラフィックでよく使われるセッション識別子は Authorization ヘッダーです。クライアント認証に JSON Web Token（JWT） を使う場合、その値は時間とともに変わることがあります。時間をまたいでセッションを一意に識別するには、JWT 内の sub や email などのクレーム値をセッション ID として使えます。

ゾーンへの成功リクエストの 1% 超で API が Authorization ヘッダーを使っている場合、Cloudflare はそれを API Shield のセッション識別子として自動設定します。

セッション識別子、または識別子としての Cookie を設定するには、Enterprise サブスクリプションなどの特定のエンタイトルメントが必要です。API Discovery、Sequence Mitigation、レート制限の推奨 などの機能、および Sequence Analytics と Authentication Posture での結果確認に使います。

セッション識別子を設定し、Cloudflare がトラフィックパターンを学習する時間を置いたあと、エンドポイントごと・セッションごとのレート制限の推奨値を確認できます。新しいルールを作成して、エンドポイントごと・セッションごとのレート制限を適用することもできます。セッション識別子を設定すると、セッション ID ベースの検出による API Discovery の結果と、Sequence Analytics でのセッショントラフィックパターンを確認できます。

Application Profiles は、2 つのソースを持つ Schema Profile を 1 つ提供します。Schema Learning はトラフィックからプロファイルを導出し、Schema Validation はアップロードした OpenAPI スキーマ を使います。

どちらのソースも、プロファイルが利用可能になると 常時検出 を提供します。緩和には、別途 WAF Custom Rule が必要です。

OpenAPI スキーマを管理している場合は、Schema Validation のアップロード手順 に従ってください。OpenAPI の互換性、スキーマのガバナンス、自動化の参照先は、引き続き API Shield です。

API Shield は Cloudflare WAF の Sensitive Data Detection ルールセットと連携し、社会保障番号やクレジットカード番号など、機密データを HTTP レスポンスで返す API エンドポイント を特定します。これらのエンドポイントを確認し、機密データが想定どおりの場所でのみ返されているかを検証してください。

行のパスの横にあるアイコンを選択すると、機密データを返すエンドポイントを識別できます。エンドポイントを展開すると、どのルールがトリガーされたかを確認できます。Firewall Events でイベントを調べると、さらに情報が表示されます。

Web Assets は、トラフィックからオペレーションを継続的に検出します。オペレーションは、HTTP メソッド、ホスト名パターン、パスパターンでエンドポイントを表します。

Web Assets > Operations から、オペレーションを手動で追加することもできます。検出と手動作成は、インベントリへの登録だけを行います。

Schema Learning を始めるには、オペレーションのオーバーフローメニューから Learn profile を選択します。学習したスキーマは View details > Security overview で確認します。

完全なワークフローとトラフィックのしきい値は、Application Profiles を始める を参照してください。

レート制限ルール では、式に一致するリクエストのレート制限を定義し、制限に達したときのアクションを選べます。

API Shield は、セッション識別子に基づいて各エンドポイントのレート制限の推奨値を生成します。この推奨は、サイト全体や IP アドレス単位ではなく、エンドポイントごと、セッションごとにスコープされます。

セッション単位のレート制限は、個々の訪問者がセッション中に特定のエンドポイントへ送るトラフィックを追跡します。広く適用したルールによる誤検知を減らしつつ、不正なトラフィックは制限できます。

学習済みスキーマには、ホスト名、ホスト・メソッド・パスごとの全エンドポイント、検出されたパス変数（例: /users/{id}）が含まれます。検出されたクエリパラメーターとその形式も含められます。レート制限しきい値の推奨を、任意で含められます。

学習済みスキーマは、Cloudflare ダッシュボード または API からエクスポートできます。

エクスポートすると、OpenAPI v3.0.0 ファイルが作成されます。固定プロファイルとして使うには、そのファイルを Schema Validation からアップロードします。

Sequence Analytics は、API リクエストのよくあるパターンを特定します。たとえば、ユーザーが資金移動の前に口座残高を確認する、といった流れです。

シーケンスは precedence score（優先度スコア）で順位付けされます。優先度スコアは、特定の API リクエストが一定の順序で一緒に発生しやすさを測ります。高スコアのシーケンスには、シーケンス内の他のオペレーションの後に続きやすい API リクエストが含まれます。

Sequence mitigation では、認証済みクライアントが API と通信するときのリクエストパターンを強制できます。Sequence Analytics で API クライアントがたどるシーケンスを特定し、スコアの高いシーケンス内のエンドポイントに API Shield の保護（レート制限、スキーマ検証、JWT 検証、mTLS）を適用します。想定するエンドポイントの順序は、開発チームと確認してください。

詳細は、ブログ記事 Detecting API abuse automatically using sequence analysis ↗ を参照してください。

JSON Web Tokens（JWT）検証 は、クライアントが送ったトークンが改ざんされておらず、期限切れでもないことを検証します。JWT 検証は、Cloudflare ダッシュボードまたは API で設定します。

オリジンが GraphQL を使う場合は、GraphQL クエリのサイズと深さに上限を設けることを検討してください。

GraphQL malicious query protection は、過剰な入れ子やサイズのクエリを GraphQL トラフィックからスキャンします。こうしたクエリはオリジンに過負荷をかけ、サービス拒否につながる可能性があります。最大クエリ深さとサイズを設定するルールを作成し、オリジンに届く前にブロックできます。

詳細は ブログ記事 ↗ を参照してください。

追加の保護層が必要な API、またはその恩恵を受ける API を運用している場合は、相互 TLS（mTLS）の利用を検討してください。

相互 TLS（mTLS）認証 では、クライアントとサーバーの双方が証明書で互いの身元を検証します。標準の TLS では、サーバーだけが身元を証明します。mTLS はクライアント検証を追加します。ID プロバイダーで認証しない IoT ハードウェアなどのデバイスに有用です。