CDN:アクセス制御の問題のトラブルシューティング

• 原因：CDN で URL 認証が有効になっていますが、実際にアクセスされた URL には署名パラメーターが含まれていません。

• 解決策：「URL 署名の設定」に従って、リクエストに正しい署名パラメーターを生成して付与してください。認証機能が不要な場合は、CDN コンソールにログインし、ドメイン名の URL 認証を無効にしてください。

• 原因：URL には署名パラメーターが含まれていますが、署名パラメーター内のタイムスタンプが期限切れになっています。署名付き URL の有効期間は、設定した有効期間によって決まります。有効期間が経過すると、署名は無効になります。

• 解決策：「URL 署名の設定」を参照して、署名付き URL を再生成してください。ビジネスページの読み込みに時間がかかる場合は、署名の有効期間を適宜延長することができます。

• 原因：署名パラメーターの MD5 値が誤って計算されています。これは通常、署名コードの署名アルゴリズムが CDN 認証方式の要件と一致しないことが原因です。

• 解決策：まず、CDN コンソールの URL ジェネレーターを使用して署名付き URL を生成し、独自の署名コードで生成された URL とフィールドごとに比較して、署名の違いを特定することを推奨します。各認証方式の署名アルゴリズムについては、「タイプ A 署名」をご参照ください。署名コードの例については、「URL 署名の例」をご参照ください。

• 原因：リクエストに含まれる Referer がホワイトリストに含まれていないか、ブラックリストに一致しています。これは一般的に、ホワイトリストにリソースを実際に参照しているサイトのドメイン名が省略されている場合に発生します。

• 診断：CDN コンソールで、高速化ドメイン名の Referer ブラックリスト/ホワイトリストの設定を確認し、ブロックされたリクエストの Referer がルールに一致するかどうかを判断します。CDN ログをダウンロードして、対応するアクセスレコードの Referer ヘッダーを見つけることもできます。

• 解決策：ブロックされた Referer をホワイトリストに追加します (またはブラックリストから削除します)。設定方法については、「Referer ブラックリストまたはホワイトリストの設定」をご参照ください。

• 原因：次のシナリオのリクエストは Referer を含みません (空の Referer)：ブラウザのアドレスバーからリソース URL に直接アクセスする場合、アプリやクライアントプログラムで Referer ヘッダーを設定せずにリクエストを構築する場合、HTTPS ページが HTTP リソースを参照する場合 (この場合、ブラウザはデフォルトの Referrer-Policy に基づいて Referer を送信しません)、ページが明示的に Referrer-Policy: no-referrer を設定している場合、および curl や wget などのコマンドラインツールを使用する場合 (これらはデフォルトで Referer を含みません)。Referer ブラックリスト/ホワイトリスト設定で [ブラウザのアドレスバーからリソース URL への直接アクセスを許可する] が選択されていない場合、Referer が空のリクエストはブロックされます。

• 解決策：ビジネスで空の Referer によるアクセスを許可する必要がある場合は、Referer ブラックリスト/ホワイトリスト設定で [ブラウザのアドレスバーからリソース URL への直接アクセスを許可する] を選択してください。トラフィックの盗用を防ぐために意図的に Referer が空のリクエストをブロックする場合は、それらを許可せず、「トラフィックの異常と悪意のあるトラフィックの盗用」を参照して、より詳細な緩和ポリシーを設定してください。設定方法については、「Referer ブラックリストまたはホワイトリストの設定」をご参照ください。

IP ブラックリスト/ホワイトリストを設定した後、クライアントの IP アドレスがブラックリストに一致するか、ホワイトリストに含まれていない場合、CDN ノードはリクエストを拒否し、403 エラーを返します。レスポンスヘッダー X-Tengine-Error: denied by IP ACL = blacklist は IP アドレスが IP ブラックリストに一致したことを示し、X-Tengine-Error: denied by IP ACL = not in whitelist は IP アドレスが IP ホワイトリストに含まれていないことを示します。

• 診断：まず、クライアントの実際のパブリック IP アドレスを確認します (curl ifconfig.me または curl myip.ipip.net を実行して照会できます)。リクエストがプロキシまたはロードバランサーを通過する場合、CDN が取得するクライアント IP アドレスはエンドユーザーの IP アドレスではなくプロキシの IP アドレスである可能性があり、CDN ノードが実際に識別するクライアント IP アドレスを確認する必要があります。CDN コンソールで、ドメイン名の IP ブラックリスト/ホワイトリスト設定を確認し、IP アドレスがルールに一致するかどうかを確認します。

• 解決策：まず、ブロックが意図したものであるかどうかを確認します。IP アドレスを許可する必要がある場合は、CDN コンソールの [ドメイン名] ページで、対象ドメイン名の [管理] をクリックします。左側メニューで [アクセス制御] をクリックし、[IP ブラックリスト/ホワイトリスト] セクションでルールを調整します。設定方法については、「IP ブラックリストまたはホワイトリストの設定」をご参照ください。IP ブラックリスト内の IP アドレスがまだリソースにアクセスできる場合は、「ブラックリスト内の IP アドレスがリソースにアクセスできるのはなぜですか？」をご参照ください。

UA ブラックリスト/ホワイトリストを設定した後、リクエストの User-Agent が UA ブラックリストに一致するか、UA ホワイトリストに含まれていない場合、CDN ノードはリクエストを拒否し、403 エラーを返します。レスポンスヘッダー X-Tengine-Error: black ua は User-Agent が UA ブラックリストに一致したことを示し、X-Tengine-Error: not in white ua は User-Agent が UA ホワイトリストに含まれていないことを示します。

• 診断：curl -v <高速化リソースの URL> を実行してリクエストが実際に送信する User-Agent の値を確認するか、ブラウザの開発者ツールでリクエストヘッダーを確認します。CDN コンソールで、ドメイン名の UA ブラックリスト/ホワイトリストのルールを確認し、User-Agent が一致するかどうかを確認します。UA ブラックリスト/ホワイトリストはワイルドカードマッチングをサポートしているため、User-Agent がワイルドカードルールによって予期せず一致していないかを確認してください。

• 解決策：まず、ブロックが意図したものであるかどうかを確認します。リクエストを許可する必要がある場合は、CDN コンソールの [ドメイン名] ページで、対象ドメイン名の [管理] をクリックします。左側メニューで [アクセス制御] をクリックし、[UA ブラックリスト/ホワイトリスト] タブでルールを調整します。設定方法については、「User-Agent ブラックリストまたはホワイトリストの設定」をご参照ください。

リモート認証を有効にすると、CDN ノードはリクエストを指定した認証サーバーに転送して検証します。次の 2 つの場合にリクエストがブロックされ、403 エラーが返されます。

• 認証サーバーが設定で定義された [認証失敗ステータスコード] (例：403) を返した場合、CDN は認証が失敗したと判断し、リクエストを拒否します。

• 認証がタイムアウトし (CDN ノードと認証サーバー間の対話が設定されたタイムアウト期間内に完了しない)、[認証タイムアウト後のアクション] が [拒否] に設定されている場合。

• 診断：403 エラーが上記の URL 認証、Referer、IP ACL、または UA ACL のいずれにも該当しない場合 (レスポンスヘッダーの X-Tengine-Error の値がそれらのいずれにも一致しない場合)、かつドメイン名でリモート認証が有効になっている場合は、まずリモート認証のトラブルシューティングを行う必要があります。CDN コンソールで、ドメイン名のリモート認証設定にある [認証失敗ステータスコード]、[認証タイムアウト設定]、および [認証タイムアウト後のアクション] を確認し、次に認証サーバーのアクセスログを確認して、認証サーバーが実際に返したステータスコードとタイムアウトが発生したかどうかを確認します。

• 解決策：ブロックが意図したものでない場合は、認証サーバーの検証ロジックまたは認証失敗ステータスコードの設定を調整します。認証が頻繁にタイムアウトする場合は、認証サーバーのパフォーマンスのトラブルシューティングを行うか (タイムアウト期間は最大 3,000 ミリ秒まで設定可能)、ビジネスリスク評価に基づいて [認証タイムアウト後のアクション] を [許可] に設定します。設定方法については、「リモート認証の設定」をご参照ください。

403 エラーは OSS オリジンサーバーから返されます。一般的なエラーメッセージは 3 つあります。

• エラー You have no right to access this object because of bucket acl：バケットの読み取り権限がプライベートであり、CDN のオリジンフェッチリクエストが OSS 認証をパスしていません。CDN コンソールでプライベート OSS バケットのオリジンフェッチ認証を有効にすることを推奨します。設定方法については、「プライベート OSS バケットからのオリジンフェッチの設定」をご参照ください。

• エラー You are denied by bucket referer policy：バケットに Referer ブラックリスト/ホワイトリストが設定されており、CDN のオリジンフェッチリクエストの Referer がバケットのルールに一致しません。OSS コンソールでバケットの Referer ブラックリスト/ホワイトリスト設定を確認し、CDN のオリジンフェッチリクエストからのアクセスを許可します (例：空の Referer を許可する、または CDN のオリジンフェッチリクエストに含まれる Referer をホワイトリストに追加する)。

• エラー You are forbidden to list buckets：CDN のプライベートバケットオリジンフェッチと OSS の静的ウェブサイトホスティングが同時に有効になっており、2 つの機能が互いに競合しています。どちらか一方を無効にしてください：CDN で設定したプライベートバケットへのオリジンフェッチ認証を無効にするか、OSS の静的ウェブサイトホスティング機能を無効にします。競合の説明については、「プライベート OSS バケットへのアクセスと静的ウェブサイトホスティングを有効にした後にエラーが発生した場合の対処法」をご参照ください。

• 原因：CDN がオリジンフェッチを実行する際、オリジンホストはオリジンフェッチリクエストがオリジンサーバーの IP アドレス上のどのサイトにアクセスするかを決定します。オリジンホストが誤って設定されている場合、リクエストはサービスを提供していないサイトやオリジンサーバー上でアクセス制限のあるサイトに振り分けられ、オリジンサーバーは 403 エラーを返す可能性があります。さらに、オリジンサーバー自体のファイアウォールルール、WAF ポリシー、またはアプリケーション層のアクセス制御も、CDN のオリジンフェッチリクエストをブロックする可能性があります。

• 診断：hosts ファイルを編集して高速化ドメイン名をオリジンサーバーの IP アドレスにマッピングし、オリジンサーバーに直接アクセスして、同様に 403 エラーが返されるかどうかを検証します。CDN コンソールでオリジンホストの設定を確認し、それがオリジンサーバー上で実際にサービスを提供しているサイトを指していることを確認します。

• 解決策：オリジンホストの設定を修正し、オリジンホストがオリジンサーバー上で実際にサービスを提供しているサイトを指すようにします。オリジンサーバーのファイアウォールまたは WAF が CDN のオリジンフェッチリクエストをブロックする場合は、CDN のオリジンフェッチ IP アドレス範囲をオリジンサーバーのホワイトリストに追加します。オリジンサーバー側の一般的なトラブルシューティング方法については、「オリジンフェッチに関するトラブルシューティングガイド」をご参照ください。

次の方法で確認できます。

• CDN コンソールにログインし、[監視レポート] でドメイン名の帯域幅とトラフィックの傾向を確認し、営業時間外に異常なピークが発生していないかを確かめます。

• ドメイン名の CDN アクセスログをダウンロードし、アクセス元の IP アドレス分布、Referer 分布、User-Agent 分布を分析し、異常に高頻度の IP アドレス範囲、異常な Referer ソース、またはクローラーのような User-Agent を特定します。

• [CloudMonitor] で帯域幅またはトラフィックのアラートがトリガーされているかどうかを確認します。

事前に保護措置を講じることを推奨します。アラーム設定機能を通じてピーク帯域幅とダウンストリームトラフィックのアラームルールを設定し、しきい値に達したときに速やかに通知されるように設定します。また、攻撃の特性に基づいて IP ブラックリスト、Referer ブラックリスト、UA ブラックリスト、URL 認証などのアクセス制御ポリシーを設定して攻撃をブロックします。トラフィックの盗用シナリオに対するブロッキングソリューションについては、「トラフィックの不正利用の防止」をご参照ください。

ドメイン名がすでにサンドボックスに移動されている場合は、攻撃トラフィックが収まるのを待ってから、チケットを送信してサンドボックスからの削除をリクエストしてください。再度トリガーされるのを避けるために、削除前にアクセス制御ポリシーを設定することを推奨します。