所有権チャレンジは、Cloudflare がログをプッシュする前に、送信先バケットへの読み取りアクセスがあることを証明する 1 回限りの確認です。この仕組みは、自分で管理していないバケットへデータを送る Logpush ジョブを、誤って設定するのを防ぎます。
ストレージ送信先向けの Logpush ジョブを作成するとき、Cloudflare はその送信先の所有を証明するよう求めます。
destination_confに対する所有権チャレンジをリクエストします。- Cloudflare は、バケット内の
ownership-challenge.txtファイルに JWT を書き込みます。 - バケットからトークンを読み取り、ジョブ作成リクエストと一緒に送信します。
- Cloudflare がトークンを検証し、ジョブを作成します。
手順の詳細は cURL で Logpush を管理する を参照してください。
所有権チャレンジの主目的は、誤設定の防止です。この確認がないと、意図していないバケットへプッシュするジョブを誤って設定できます。たとえば、実際には他人が所有するバケットへ送ってしまう場合です。
チャレンジは、次のような悪意のあるシナリオも防ぎます。
- 別の顧客のバケットへ Logpush ジョブを向ける
- そのバケットへ偽のログや悪意のあるログデータを送る
- 被害者のログ保存領域を汚染・破壊する
所有権チャレンジは JSON Web Token(JWT)で、特定の文脈に結び付けるクレームを含みます。トークンには次が含まれます。
- オブジェクトタイプ - ジョブがゾーンスコープ、アカウントスコープ、テナントスコープのいずれであるか
- オブジェクト ID - 特定のゾーンまたはアカウントの識別子
- 送信先構成 - 送信先構成文字列全体
- 送信先フィンガープリント - バケット名とパス / プレフィックスのハッシュ
- 有効期限 - トークンは 7 日後に期限切れになります
チャレンジトークンを送信すると、Cloudflare はすべてのクレームがジョブ作成リクエストと一致するかを検証します。これにより、別のアカウント、ゾーン、送信先へのトークン再利用を防ぎます。
実際には、漏洩した所有権チャレンジトークンを使った攻撃は非常に起きにくいです。攻撃者には次が必要です。
- あなたの Cloudflare アカウントへのアクセス(トークン内のオブジェクト ID と一致させるため)
- 正確なバケット名とパス / プレフィックスの知識(送信先フィンガープリントと一致させるため)
- 7 日以内の実行(チャレンジの期限切れ前)
主なセキュリティ層は、所有権チャレンジトークンではなく、バケットの IAM / アクセス制御と Cloudflare アカウントのセキュリティです。
- ジョブ作成後にチャレンジファイルを削除する - Logpush ジョブを作成したら、バケットから
ownership-challenge.txtを安全に削除できます。 - バケット権限を制限する - 書き込みアクセスは Cloudflare のサービスアカウントだけに付与します。AWS S3 では、
arn:aws:iam::391854517948:user/cloudflare-logpushにPutObject権限を付与します。GCS では、logpush@cloudflare-data.iam.gserviceaccount.comにStorage Object Adminを付与します。 - Logpush ジョブを監視する - Logpush ヘルスダッシュボード でジョブの状態を監視し、異常を検知します。
| 送信先 | 所有権チャレンジが必要 |
|---|---|
| AWS S3 | はい(またはアクセスキー / シークレットキーを使う) |
| Google Cloud Storage | はい |
| Azure Blob Storage | はい |
| Sumo Logic | はい |
| S3 互換ストレージ | いいえ |
| HTTP エンドポイント | いいえ |
| Datadog | いいえ |
| Splunk | いいえ |
| New Relic | いいえ |
所有権チャレンジが不要な送信先では、Cloudflare は API キーやトークンなどの別の認証方法を使います。