Zendeskは、すべてのZendeskインスタンスとプラットフォーム全体の安定性を保護する、高度な不正利用防止システムを備えています。Zendeskのお客様とそのカスタマー(エンドユーザー)のほとんどは、インターネット経由でZendeskに直接アクセスします。Zendeskはこの標準的な設定を前提としています。この標準から外れたお客様は、Zendeskに接続する際に問題が発生する可能性があります。
たとえば、ある組織で、エージェントとエンドユーザーがZendeskにアクセスする際に、リバースプロキシを設定して、単一のアクセスポイントまたは独自のCDNからアクセスできるようにしているとします。リバースプロキシは、ZendeskにアクセスしようとするWebクライアントからのリクエストを横取りして、Zendeskに転送します。WebクライアントはZendeskと直接通信することはなく、プロキシだけがZendeskと直接通信を行います。
このようなアクセス方法をZendeskが止めることはできません。しかし、これは標準を外れた使用例であり、以下のような好ましくない動作が発生する可能性があります。
- ボットの管理上の問題(CAPTCHA):すべてのリクエストが単一のIPまたはASN経由で送信される場合、正当なユーザーであってもボットとして識別される可能性が高くなります。プロキシやCDNが何らかの方法でHTTPヘッダを変更している場合は、さらにその可能性が高くなります。
- 検索エンジンのクローラーやその他の「善良な」ボットの拒否:Cloudflareは、リクエストIPやASN経由の善良なボットを一部しか識別しません。たとえば、Googlebot User Agentを持つリクエストのリクエストIPがGoogleの登録IPと異なる場合、Cloudflareはそのリクエストを拒否します。
- 間違ったページのインデックス化:Cloudflareによって拒否されていない場合、検索クローラーはおそらくZendeskサイトのメタデータタグによって提供される正規URLを使おうとするでしょう。その結果、検索エンジンが実際にプロキシされたサイトをクロールする場合、非プロキシのURLを持つページのインデックスが作成される可能性があります。
- API制限:API制限は、リクエストIPに基づいて適用されます。カスタマーのリクエストがすべて単一または少数のIPアドレスを経由する場合、API制限が適用される可能性が高くなります。
- キャッシュの問題:プロキシやCDNに独自のキャッシュロジックがある場合、Zendeskはこのキャッシュの完全性を保証することはできません。たとえば、削除された記事がヘルプセンターよりもプロキシでの表示が長く残る可能性があります。権限の変更もすぐに反映されない可能性があります。
リバースプロキシを使用する前に、それが本当に必要なのかどうかを検討してください。ヘルプセンターのURLを変更する必要がある場合は、リバースプロキシの代わりに、ホストマッピングを使用することができます。「ホストマッピング - ヘルプセンターのURLの変更」を参照してください。
ガイドライン
やむを得ずリバースプロキシを使ってZendeskにアクセスする場合は、以下のガイドラインに留意してください。
-
API制限を回避し、ボットのように見えることを防ぐために、プロキシ経由で送信されるトラフィックはすべて、出力に複数のIPを使用する必要があります。
-
リバースプロキシは透過的である必要があり、ヘッダーを編集してユーザーエージェントを上書きするなどしてはなりません。
それでも、トラフィックはZendeskシステムによってボットトラフィックとして振り分けられてしまう場合があります。これらのガイドラインに従っても問題が発生する場合は、自社のIT部門に相談してください。
0件のコメント